Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #11736 > unrolled thread

Re: Interplatform (interprocess, interlanguage) communication

Started by"Jeffrey H. Coffield" <jeffrey@digitalsynergyinc.com>
First post2012-02-04 08:50 -0800
Last post2012-02-04 18:29 -0500
Articles 2 — 2 participants

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Interplatform (interprocess, interlanguage) communication "Jeffrey H. Coffield" <jeffrey@digitalsynergyinc.com> - 2012-02-04 08:50 -0800
    Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-04 18:29 -0500

#11736 — Re: Interplatform (interprocess, interlanguage) communication

From"Jeffrey H. Coffield" <jeffrey@digitalsynergyinc.com>
Date2012-02-04 08:50 -0800
SubjectRe: Interplatform (interprocess, interlanguage) communication
Message-ID<jgjnjq$qsm$1@dont-email.me>

On 02/03/2012 11:52 AM, Stefan Ram wrote:

>    Sockets
>
>    This is slightly less transparent than files, but has the
>    advantage that it becomes very easy to have the two
>    processes running on different computers later, if this
>    should ever be required. Debugging should be possible
>    by a man-in-the-middle proxy that prints all information
>    it sees or by connecting to the server with a terminal.

SOAP has been mentioned, but I would also look at REST. An http post 
with an XML response although less powerful, has a wider range of 
support. Using port 80/443 to get to a server also greatly simplifies 
firewall issues when the systems are remote.

>
>    JNI
>
>    JNI might be used to access code written in C or
>    ABI-compatible languages. This should be fast, but I heard
>    that it is error prone to write JNI code and needs some
>    learning (code less maintainable)?
>
The biggest drawback to JNI (I feel) is that it opens up all the 
disadvantages of C in a Java environment. It is difficult (for me) at 
times to determine exactly where an error actually is as I use C only 
when forced to.

Jeff Coffield
www.digitalsynergyinc.com

[toc] | [next] | [standalone]


#11744

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-02-04 18:29 -0500
Message-ID<4f2dbf48$0$290$14726298@news.sunsite.dk>
In reply to#11736
On 2/4/2012 11:50 AM, Jeffrey H. Coffield wrote:
> On 02/03/2012 11:52 AM, Stefan Ram wrote:
>> Sockets
>>
>> This is slightly less transparent than files, but has the
>> advantage that it becomes very easy to have the two
>> processes running on different computers later, if this
>> should ever be required. Debugging should be possible
>> by a man-in-the-middle proxy that prints all information
>> it sees or by connecting to the server with a terminal.
>
> SOAP has been mentioned, but I would also look at REST. An http post
> with an XML response although less powerful, has a wider range of
> support. Using port 80/443 to get to a server also greatly simplifies
> firewall issues when the systems are remote.

That is given by the HTTP transport more than the RPC style SOAP
vs RESTful POX.

Arne

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.java.programmer


csiph-web