Question

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.

Answer 1

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 c++ and java (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