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

Groups > comp.lang.java.programmer > #11732 > 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 Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-02-04 02:24 -0600

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

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
 
>  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.)

Other options:

* Use a message broker such as CORBA or MQ. Perhaps the cleanest
 solution code-wise, but requires more infrastructure and gives you a
 more complicated installation.

* Communicate through a shared database. Fiddly, but can be convenient
  if the programs share a database anyway.

* REST -- have an HTTP servlet running in one program and make RESTful
  calls to it from the other. (Roughly the same as a SOAP approach,
  but if the communication is mostly command and control messages, it
  might be more convenient.)

* JNI wrapper around shared memory / memory mapped files. Very fiddly,
  very system specific, but potentially very high performance.
  (There's a discussion on using memory mapped files with java here:
  http://tinyurl.com/6oa3wej  )

* The presence of trigger / lock files in a directory. Quick and easy,
  but limited.

* Use a shared web resource / whiteboard. Quick and convenient if your
  programs do HTTP calls anyway, but requires the shared web resource
  to be in place and there's performance and latency to take into
  account.

-- 
Leif Roar Moldskred

[toc] | [standalone]

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

csiph-web