Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder2.hal-mli.net!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Interplatform (interprocess, interlanguage) communication Date: Sat, 04 Feb 2012 13:59:29 +0100 Lines: 93 Message-ID: <9p4odoFj5lU1@mid.individual.net> References: <9p32qmFcrnU1@mid.individual.net> <4f2c6626$0$287$14726298@news.sunsite.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: individual.net 4IYZHVZ3LMWr0K1dPtiJqAHD+4P/wNNfaf8Uwhm5Rqm5W0BkU= Cancel-Lock: sha1:YFmBspCNGaEseweo8Xamku+hNd0= User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 In-Reply-To: <4f2c6626$0$287$14726298@news.sunsite.dk> Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:11735 On 03.02.2012 23:56, Arne Vajh=F8j wrote: > On 2/3/2012 4:44 PM, Robert Klemme wrote: >> On 02/03/2012 08:52 PM, Stefan Ram wrote: >>> =BBX=AB 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. >>> >>> =BBReliability=AB means little risk of creating problems, little >>> risk of failure at run-time. (It might help when the client >>> [=3DJava 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 =BBproc=AB with =BBexec=AB and then use >>> >>> BufferedWriter out =3D new BufferedWriter(new >>> OutputStreamWriter(proc.getOutputStream())); >>> BufferedReader in =3D 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,=20 depending on platform. Also, this approach only works if the Java=20 process always starts the other process. Alternatively the other=20 process would start the Java process this way and we can read from=20 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 netwo= rk >> transport) >> >> Advantage: you can focus on definition of the API and need not take ca= re >> of all the nifty details. Choice should also depend on the availabilit= y >> 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 --=20 remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/