tags:

views:

51

answers:

1

Can you please advice with an example of using SoapRMI-C++ to send/receive objects between C++(top) and Java(bottom) layers of an application.

Please let me know its feasibility and implementation complexities.

Thanks, Gtk

A: 

Don't. Use something like Protocol Buffers.

Soap is verbose and slow. And RMI leads to poor program design when messages that would've taken nanoseconds to send instead become messages that take microseconds (if the two programs are on the same box, or maybe on the same LAN) or even milliseconds to send. And it's imperative nature also tends to encourage designs in which the client and server depend on each other's state in a fairly intertwined way, just like the caller and callee do when making an ordinary method call. It encourages the size of the state horizon to encompass the end-to-end latency of the client talking to the server which can greatly slow it down and lead to errors.

Use techniques in which the message passing is explicit and that encourage you to focus on the data being passed over the operation that is to be performed by the remote side. Again, this points to a solution like Protocol Buffers.

I wrote a paper a long time ago on why RPC (and by extension RMI) was a bad idea. In it I single out CORBA, but most of my arguments apply to almost any form of RPC.

Additionally, the existence and popularity of languages like Erlang show that explicit message passing is good even for communications between different threads on the same CPU where latency and network delays are not an issue. This is because it greatly decreases the coupling between threads. Threads no longer have to agree to always acquire a mutex before doing certain things or anything like that. An individual thread's state horizon no longer encompasses that of the other threads on the system. It also reduces synchronous behavior in which several threads want control over the same mutex or piece of shared state.

Omnifarious