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

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

Re: Interplatform (interprocess, interlanguage) communication

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 Robert Klemme <shortcutter@googlemail.com> - 2012-02-03 22:44 +0100
    Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-03 17:56 -0500
      Re: Interplatform (interprocess, interlanguage) communication Robert Klemme <shortcutter@googlemail.com> - 2012-02-04 13:59 +0100
        Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-04 18:35 -0500

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

On 02/03/2012 08:52 PM, Stefan Ram wrote:
>    »X« below is another language than Java, for example,
>    VBA, C#, or C.
>
>    When an X process and a Java process have to exchange
>    information on the same computer, what possibilites are
>    there? The Java process should act as a client, sending
>    commands to the X process and also wants to read answers
>    from the X process. So, the X process is a kind of server.
>
>    My criteria are: reliability and it should not be extremely
>    slow (say exchanging a string should not take more than
>    about 10 ms). The main criterion is reliability.
>
>    »Reliability« means little risk of creating problems, little
>    risk of failure at run-time. (It might help when the client
>    [=Java process] can reset the communication to a known and
>    sane start state in case of problems detected at run-time.)
>
>    The host OS is Windows, but a portable solution won't hurt.
>
>    A list of possibilities I am aware of now:
>
>    Pipes
>
>    I have no experience with this. I heard one can establish
>    a new process »proc« with »exec« and then use
>
> BufferedWriter out = new BufferedWriter(new
>    OutputStreamWriter(proc.getOutputStream()));
> BufferedReader in = new BufferedReader(new
>    InputStreamReader(proc.getInputStream()));

A pipes is just 1:1 communication and only in 1 direction.

>    Files
>
>    One process writes to the end of a file, the other reads
>    from the end of the file? - I never tried this, don't know
>    if it is guaranteed to work that one process can detect and
>    read, whether the other has just appended something to a file.

You can, but what do you do with the ever increasing file?  This is not 
reliable since the filesystem will fill up at some point.

>    What if the processes run very long and the files get too
>    large? But OTOH this is very transparent, which makes it easy
>    to debug, since one can open the files and directly inspect
>    them, or even append commands manually with »copy con file«.
>
>    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.

You can as well use a packet sniffer (Wireshark for example).  If you 
use a standard protocol you'll typically have encoding functionality in 
the tool.

>    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)?

That would be a clumsy approach IMHO.

I'd pick a higher level protocol such as

- SOAP (XML based, ubiquitous)
- CORBA (a little out of fashion but quite efficient in terms of network 
transport)

Advantage: you can focus on definition of the API and need not take care 
of all the nifty details.  Choice should also depend on the availability 
for language X, of course.

Kind regards

	robert

[toc] | [next] | [standalone]

#11728

On 2/3/2012 4:44 PM, Robert Klemme wrote:
> On 02/03/2012 08:52 PM, Stefan Ram wrote:
>> »X« below is another language than Java, for example,
>> VBA, C#, or C.
>>
>> When an X process and a Java process have to exchange
>> information on the same computer, what possibilites are
>> there? The Java process should act as a client, sending
>> commands to the X process and also wants to read answers
>> from the X process. So, the X process is a kind of server.
>>
>> My criteria are: reliability and it should not be extremely
>> slow (say exchanging a string should not take more than
>> about 10 ms). The main criterion is reliability.
>>
>> »Reliability« means little risk of creating problems, little
>> risk of failure at run-time. (It might help when the client
>> [=Java process] can reset the communication to a known and
>> sane start state in case of problems detected at run-time.)
>>
>> The host OS is Windows, but a portable solution won't hurt.
>>
>> A list of possibilities I am aware of now:
>>
>> Pipes
>>
>> I have no experience with this. I heard one can establish
>> a new process »proc« with »exec« and then use
>>
>> BufferedWriter out = new BufferedWriter(new
>> OutputStreamWriter(proc.getOutputStream()));
>> BufferedReader in = new BufferedReader(new
>> InputStreamReader(proc.getInputStream()));
>
> A pipes is just 1:1 communication and only in 1 direction.

That type of pipe is bidirectional.

And Windows named pipes are bidirectional as well.

>> Files
>>
>> One process writes to the end of a file, the other reads
>> from the end of the file? - I never tried this, don't know
>> if it is guaranteed to work that one process can detect and
>> read, whether the other has just appended something to a file.
>
> You can, but what do you do with the ever increasing file? This is not
> reliable since the filesystem will fill up at some point.

It would be possible to switchover to a new file and
delete the old file if he really wanted to go this route.

> I'd pick a higher level protocol such as
>
> - SOAP (XML based, ubiquitous)
> - CORBA (a little out of fashion but quite efficient in terms of network
> transport)
>
> Advantage: you can focus on definition of the API and need not take care
> of all the nifty details. Choice should also depend on the availability
> for language X, of course.

They will use socket as transport.

But if the X language has a good SOAP toolkit, then it would
certainly make things a lot easier.

Arne

[toc] | [prev] | [next] | [standalone]

#11735

On 03.02.2012 23:56, Arne Vajhøj wrote:
> On 2/3/2012 4:44 PM, Robert Klemme wrote:
>> On 02/03/2012 08:52 PM, Stefan Ram wrote:
>>> »X« below is another language than Java, for example,
>>> VBA, C#, or C.
>>>
>>> When an X process and a Java process have to exchange
>>> information on the same computer, what possibilites are
>>> there? The Java process should act as a client, sending
>>> commands to the X process and also wants to read answers
>>> from the X process. So, the X process is a kind of server.
>>>
>>> My criteria are: reliability and it should not be extremely
>>> slow (say exchanging a string should not take more than
>>> about 10 ms). The main criterion is reliability.
>>>
>>> »Reliability« means little risk of creating problems, little
>>> risk of failure at run-time. (It might help when the client
>>> [=Java process] can reset the communication to a known and
>>> sane start state in case of problems detected at run-time.)
>>>
>>> The host OS is Windows, but a portable solution won't hurt.
>>>
>>> A list of possibilities I am aware of now:
>>>
>>> Pipes
>>>
>>> I have no experience with this. I heard one can establish
>>> a new process »proc« with »exec« and then use
>>>
>>> BufferedWriter out = new BufferedWriter(new
>>> OutputStreamWriter(proc.getOutputStream()));
>>> BufferedReader in = new BufferedReader(new
>>> InputStreamReader(proc.getInputStream()));
>>
>> A pipes is just 1:1 communication and only in 1 direction.
>
> That type of pipe is bidirectional.

Well, that are actually two pipes aren't they?  Or it's a socketpair, 
depending on platform.  Also, this approach only works if the Java 
process always starts the other process.  Alternatively the other 
process would start the Java process this way and we can read from 
System.in and write to System.out.

> And Windows named pipes are bidirectional as well.

Oh, I didn't knew that.  Learn something new every day.  Thanks!

>>> Files
>>>
>>> One process writes to the end of a file, the other reads
>>> from the end of the file? - I never tried this, don't know
>>> if it is guaranteed to work that one process can detect and
>>> read, whether the other has just appended something to a file.
>>
>> You can, but what do you do with the ever increasing file? This is not
>> reliable since the filesystem will fill up at some point.
>
> It would be possible to switchover to a new file and
> delete the old file if he really wanted to go this route.

Well, yes, but that soon gets nasty because of file locking etc.

>> I'd pick a higher level protocol such as
>>
>> - SOAP (XML based, ubiquitous)
>> - CORBA (a little out of fashion but quite efficient in terms of network
>> transport)
>>
>> Advantage: you can focus on definition of the API and need not take care
>> of all the nifty details. Choice should also depend on the availability
>> for language X, of course.
>
> They will use socket as transport.
>
> But if the X language has a good SOAP toolkit, then it would
> certainly make things a lot easier.

Exactly.

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#11745

On 2/4/2012 7:59 AM, Robert Klemme wrote:
> On 03.02.2012 23:56, Arne Vajhøj wrote:
>> On 2/3/2012 4:44 PM, Robert Klemme wrote:
>>> On 02/03/2012 08:52 PM, Stefan Ram wrote:
>>>> »X« below is another language than Java, for example,
>>>> VBA, C#, or C.
>>>>
>>>> When an X process and a Java process have to exchange
>>>> information on the same computer, what possibilites are
>>>> there? The Java process should act as a client, sending
>>>> commands to the X process and also wants to read answers
>>>> from the X process. So, the X process is a kind of server.
>>>>
>>>> My criteria are: reliability and it should not be extremely
>>>> slow (say exchanging a string should not take more than
>>>> about 10 ms). The main criterion is reliability.
>>>>
>>>> »Reliability« means little risk of creating problems, little
>>>> risk of failure at run-time. (It might help when the client
>>>> [=Java process] can reset the communication to a known and
>>>> sane start state in case of problems detected at run-time.)
>>>>
>>>> The host OS is Windows, but a portable solution won't hurt.
>>>>
>>>> A list of possibilities I am aware of now:
>>>>
>>>> Pipes
>>>>
>>>> I have no experience with this. I heard one can establish
>>>> a new process »proc« with »exec« and then use
>>>>
>>>> BufferedWriter out = new BufferedWriter(new
>>>> OutputStreamWriter(proc.getOutputStream()));
>>>> BufferedReader in = new BufferedReader(new
>>>> InputStreamReader(proc.getInputStream()));
>>>
>>> A pipes is just 1:1 communication and only in 1 direction.
>>
>> That type of pipe is bidirectional.
>
> Well, that are actually two pipes aren't they? Or it's a socketpair,
> depending on platform.

The Java Process supports in and out.

Whether the OS does it via single bidirectional or two unidirectional
does not change the Java code.

Thinking of it then two sounds more likely as Java also need to
separate err and out - that would be a lot easier with two.

>                             Also, this approach only works if the Java
> process always starts the other process.

Yep.

>>>> One process writes to the end of a file, the other reads
>>>> from the end of the file? - I never tried this, don't know
>>>> if it is guaranteed to work that one process can detect and
>>>> read, whether the other has just appended something to a file.
>>>
>>> You can, but what do you do with the ever increasing file? This is not
>>> reliable since the filesystem will fill up at some point.
>>
>> It would be possible to switchover to a new file and
>> delete the old file if he really wanted to go this route.
>
> Well, yes, but that soon gets nasty because of file locking etc.

Some coding required.

Arne

[toc] | [prev] | [standalone]

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

csiph-web