5

Use case : one Java process with one or two C++ processes, always on the same machine. Bidirectional, binary, non-persistent communication is required. One of the C++ process is responsible for instantiating the other processes.

I have given a look around, seeing things like XML/JSON-RPC, Protocol Buffers, Thrift, zeromq, etc.

If possible, portability would be nice, but Windows XP/7 is required.

Rhangaun
  • 1,430
  • 2
  • 15
  • 34
  • depends on what kind of data (text/binary) you going to transmit, the desired throughput of the system and what kind of API you wish to use (high-level, such as SOAP or low-level, such as protocol buffers/zeromq). – Victor Sorokin May 08 '12 at 20:29
  • @Skeptic additionally, do you need persistence for your transport layer or will persistence be provided by end-points? If former, you will need something like JMS. – Victor Sorokin May 08 '12 at 20:36

2 Answers2

13

In general you should separate message transport and message de-/serialization in your design, and keep them as orthogonal as possible. In short, decouple the data (message) flow behavior from your message content.

  1. There are several message oriented transport frameworks, that allow to send and receive neutral payload data (messages) for certain behavioral patterns of client/server communication (request/reply, publish/subscribe, push/pull, ...) between threads, processes and network services as client and server instances.
  2. There are a number frameworks that provide de-/serialization of your payload (message) data in a transport neutral (e.g. providing a wire format for exchanging native integer data independent of machine endianess) manner.

  3. What's the best combination choice for your particular use case, depends on a number of requirements and constraints you have for your design decisions:

    • Scalability over client/sever processing units as threads, processes or servers/processes
    • Overall performance and message latency
    • Processing units resource requirements (e.g. heap memory or code size)
    • Network resource impact (what's sent via the network interfaces)
    • etc. ...

Possible Solution:
I think the ZMQ messaging framework in combination with the Google Protobuf message framwework could offer a viable solution for your use case. There are language bindings for and (see ZMQ Java binding) and you'll have have the optimized implementations for inter-process and inter-thread communications. ZMQ connections are designed in a socket like manner, that support bi-directional (request/reply) communication patterns as well as uni-directional (publish/subscribe, push/pull).

As mentioned, the message content's format is up to you, but Google Protobuf might be appropriate for internally defined message protocols, that are supported for C++ and Java language bindings. Google Protobuf also provides a mechanism to define RPC service interfaces, but you must provide the concrete message transport protocols for client/server implementations. I have never implemented this by means of a ZMQ transport, but it should be possible if necessary.

XML/JSON-RPC might be considered for published (e.g. via REST services) protocols (bridging is considerably easy with ZMQ).

Considering your requirements, I'd guess the latter protocol format options aren't required, but might be useful though, depending on the frameworks you'll intend to use with the Java/C++ participants.

AFAIK ZMQ matches your portability constraints about Windows XP/7 platforms. Not sure, but there might be restrictions for inter-thread communication on Windows systems. But that doesn't seem to apply to the scenario you have described.

Alternate transport frameworks:

  1. ActiveMQ
  2. Boost asio (C++ wrapped native sockets, I don't know about the java side feel free to enhance this info)

Alternate message en-/decoding frameworks:

  1. XML-RPC C++/java (usually assumes HTTP transport)
  2. JSON
πάντα ῥεῖ
  • 1
  • 13
  • 116
  • 190
  • How "production-ready" are ZMQ Java bindings ? The GitHub page is not convincing at first sight. – Rhangaun Jan 26 '13 at 04:26
  • Don't know much details about java bindings, but there are seemingly people using it (I'm reading the mailing list frequently). – πάντα ῥεῖ Jan 26 '13 at 09:15
  • What exactly are you referring to when you say _not convincing_. The latest additions are some time ago, but the [list of issues](https://github.com/zeromq/jzmq/issues) doesn't seem to be very long. I have also put a link to the doc main page in my answer, may be this helps you to find out more. – πάντα ῥεῖ Jan 26 '13 at 10:12
  • @Skeptic Because I know it, and I know that it works well together with Google Protobuf. ActiveMQ will fit as well for your use case, you could even do it with native sockets. ZMQ seems to be a bit less weight than ActiveMQ for me, but that impression might be wrong ... – πάντα ῥεῖ Jan 28 '13 at 18:40
  • @Skeptic BTW, I think the main design decision is to separate the transport mechanism from the protocol content en-/decoding at 1st place, as I mentioned. The concrete frameworks used depend on what fits best for your needs and available (necessary) programming language and OS environments. – πάντα ῥεῖ Jan 28 '13 at 19:05
1

According to info from question's comments, I guess protocol buffers is something to consider -- it has binary format on the wire, has simple API and does not provide any redundant stuff, such as persistence.

Victor Sorokin
  • 11,878
  • 2
  • 35
  • 51