Do We Need Another OO RPC Mechanism?

Paul68 queries: "I am looking for an RPC mechanism for a project. Granted, there are many to choose from, yet there seem none that meet my requirements! When one has toyed with the requirements the solution generaly becomes obvious. So, yeah sure, I can set out and create the next RPC mechanism, but it is a lot of hassle. But does the world need yet another OORPC, or have I simply not looked in the right corners?"

"My requirements are:

1. object oriented
2. extensible
3. platform independent
4. supports signatures for integrity and sender checking
5. supports privacy of the message contents (i.e. encryption)
6. time sensitive: I should be able to detect a dead server and do failover while the user is waiting for the response
7. bandwidth efficient, as I am looking to deploy it in wireless environments

Now #1-3 are no problem, #4 and #5 can be found, and #7 rules out anything XML-based. #6 seems to be the killer, as this rules out anything over TCP, and at that point the list gets pretty short.

Does anyone have any options that I may have missed?"

Comments

Something XML-RPC (SOAP) doesn't have

[SteveX]

...that bugs me is that there's no way to make a call that will return multiple pieces of data over a long period. Like, I want to connect to a server and say "tell me every time the price of IBM stock changes". I can use SOAP for most of a trader type UI but for streaming the data back to the client, you have to use another protocol (unless I'm missing something).

The dude asking the quesiton here is, I think, a little too worried about overhead - the overhead of XML is fairly tiny, and the overhead of TCP/IP isn't that great either - if both of those really are too much then you're probably on your own as there isn't likely to be a "general purpose" solution that will work for you.

- Steve

Re:Something XML-RPC (SOAP) doesn't have

[ThenAgain]

I once implemented a web interface that used XML-RPC to communicate with a search engine back-end. Each request lived in a state machine on the server. When the server received a request it would start processing and if it took more than a few seconds it would return an object with a status report and a request ID. The client would send a browser meta-refresh that would check on the status of the request every few seconds until it was done or returned an error.

If you're looking for something closer to real-time (a way for the server to initiate contact with the client) check out the BEEP protocol.

From the BEEP web page:
BEEP is a turbocharger for Internet applications that offers advanced features such as:

• a standard application layer that supports dynamic, pluggable application "profiles" (protocols)
• peer-to-peer, client-server, or server-to-server capabilities
• multiple channels over a single authenticated session
• support for arbitrary MIME payloads, including XML

You don't mention...

[ThenAgain]

what you've already looked at. Whenever I've been tempted to implement my own RPC mechanism I've found that XML-RPC meets my needs perfectly.

It's easily capable of representing objects, platform independent, encryptable (via SSL), compressable (via gzip [and probably SSL as well]), and textual.

The advantages of being textual in your protocols is well laid out in Eric Raymond's book The Art of Unix Programming. He even treats it as a case study.

NML

[kinema]

You might want to take a look at the Neutral Message Language, NML. Developed at the Intelligent Systems Division of the National Instute of Standards and Technology is was intended from the start for use in real-time/time critical situations. I know that it currently has support cor C, C++ and Java.

Re:Does 7 really rule out XML?

[noselasd]

When I experimented with SOAP, it was around 60% metadata, and the bytes sent by the protocol were 600% more than the equivialent done with SunRPC.
(That was for one particular application, others will vary.)