Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Interplatform (interprocess, interlanguage) communication

Reply
Thread Tools

Interplatform (interprocess, interlanguage) communication

 
 
Stefan Ram
Guest
Posts: n/a
 
      02-03-2012
»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()));

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.

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.

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

 
Reply With Quote
 
 
 
 
Robert Klemme
Guest
Posts: n/a
 
      02-03-2012
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


 
Reply With Quote
 
 
 
 
Arne Vajhřj
Guest
Posts: n/a
 
      02-03-2012
On 2/3/2012 2: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()));


That would require the client to start the server.

Does not look as a good solution.

> 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.
>
> 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«.


It should work, but it will be slow.

> 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.


That would be my choice.


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



JNI would mean single process.

It does fit with your problem description.

JNI is a bit tricky, but it is not more difficult than
many other things. But since Java programmers very rarely
use JNI, then most Java programmers never learn JNI properly
with the expected result. You could learn JNI if you need to.

Arne


 
Reply With Quote
 
Arne Vajhřj
Guest
Posts: n/a
 
      02-03-2012
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




 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      02-03-2012
On 12-02-03 03: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.

[ SNIP ]
>
> 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.
>
> 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«.

[ SNIP ]

A logical subset of files for IPC is database tables.

AHS
--
....wherever the people are well informed they can be trusted with their
own government...
-- Thomas Jefferson, 1789
 
Reply With Quote
 
Jeff Higgins
Guest
Posts: n/a
 
      02-03-2012
On 02/03/2012 02: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.
>

For Windows platform:
<http://msdn.microsoft.com/en-us/library/windows/desktop/aa365574%28v=vs.85%29.aspx>
Prune for Java/X support, prune again for your choice of protocol.

snip
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      02-04-2012
http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de (Stefan Ram) writes:
>Sockets


Thanks for the answers so far! So I might go for sockets,
because I like that fact that I do not need any additional
libraries under C (where one can use winsocks) and under
Java (where they are part of Java SE).

 
Reply With Quote
 
Jan Burse
Guest
Posts: n/a
 
      02-04-2012
I would add to the list:

Shared Memory

Stefan Ram schrieb:
> »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()));
>
> 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.
>
> 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.
>
> 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)?
>


 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      02-04-2012
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/

 
Reply With Quote
 
Jeffrey H. Coffield
Guest
Posts: n/a
 
      02-04-2012


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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
The Future of Voice Communication @ BonaFideReviews Silverstrand Front Page News 0 09-27-2005 01:47 PM
SystemVerilog Interprocess Communication - Project VeriPage Update Swapnajit Mittra VHDL 0 12-21-2004 05:11 PM
communication between processes john VHDL 10 11-30-2004 09:59 AM
PC communication on wireless network? Mervin Williams Wireless Networking 3 08-24-2004 06:32 PM
Communication between HttpApplication that run on the same server Sherif ElMetainy ASP .Net 7 11-06-2003 11:23 PM



Advertisments