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

It's time to stop

[Anonymous Coward]

And ask yourself, "What am I really trying to do?"

Re:It's time to stop

[mystran]

Well, I've done CORBA for work, play'ed around with all kinds of other RPC systems, programmed with a quite a lot of languages, and after some hobby research and all kinds of strange projects, I've come to the following conclusion personally:

There is one good RPC system, and it's called HTTP. It works wonderfully when you can generate stuff from a database into some text-representation.

There are a lot of bad ones, which mostly have the same thing in common: It is NOT a good idea to make a remote resource act like an object. It just doesn't work well. To get an impression that it works well, you need a huge bloated library, so you can pretend that everything works, until your network breaks and you have to deal with all the shit yourself anyway, but now add the complexity of the RPC system to the mix.

The thing is, when you design to work with a very simple system, either HTTP or something similar built on top of TCP directly, you end up with design, where the network is a natural part of the system. When you build something on top of a generic RPC system, you just add a layer of indirectness, which makes a good design much harder to get. In addition, when you restructure your data into text-representation (or other simple representation), you usually end up doing it in the right place, because it's usually the only place where such representation can be handled in a sane way.

That's my 1 cent about RPC. The other 1 cent deals with objects. Objects are nice, if you don't have 1) database or 2) proper functions. When you have a (relational) database, you end up with something like objects anyway, when you build a good database access layer. For many things this is what you would want to do anyway, with the added benefit that you never need to care about object references. You just tell the system how to find/alter what you need.

For the functions, as soon as you have first-class functions, objects no longer make much sense, as it takes about 15 seconds to build an object system on top of these functions. Most of the time you don't want object anyway, as you usually want functions and data instead. Learn LISP. It is more useful today than ever before. If there's something wrong with existing dialects, then help build a better one.

As for your requirements: You could use TCP directly, but you need encryption, so add ssl or something. Authenticate the connection or something, the encryption should handle rest of the integrity (this is pretty much a cipher question). Build a simple protocol with no tweaks and leave the extensibility there. If you want, you could send XML anyway, if you use zlib or something to compress it. Depending on your data, it might be the easiest thing to parse anyway. Separate the protocol layer, have it timeout and catch TCP failures, and automatically reconnect (same or other server), and you have the time-sensitivity. If you need more, send requests to multiple servers, and handle them with the one that answers first. Aim for stateless protocol, and it becomes easier. TCP and SSL are pretty platform independent, so unless your protocol is really bad that shouldn't be a problem. Now, you basicly want this all for every application in existence.

Forget the objects, they just make life a lot harder. Use cookies and numerical identifiers if you really need to. A lot of things look like they needed OO-RPC, but to this day I've not seen a single one where it really made sense. Doesn't even speedup development in the long run..

Re:It's time to stop

[duffbeer703]

The AC speaks the truth.

A million years ago, a caveman spent alot of time developing the wheel. Don't replicate his work. You're likely to make lots of mistakes when you reimplement RPC or yet another master framework product, particularly with the encryption and signing part.

I know of people working on a similar project using Java Jini. Check it out.

Also, base your decision on the actual architecture of your application, not the buzzword-compliance of the glossy brochure or website.

Does 7 really rule out XML?

[forsetti]

How much overhead do you expect XML to incur? Or more importantly, what do you expect your data/(data + XML) ratio to be? With large amounts of data, the relative amount of XML is relatively small.

Of course, if you are sending many packets, each with small amounts of data, perhaps strewn across many XML tag sets, then the XML "noise" ratio may be high. How about gzipped XML-RPC ?

Re:Does 7 really rule out XML?

[RevAaron]

I concurr- I never saw what was wrong with just using gzipped XML-RPC or SOAP. Apache mod and everything, almost no setup involved.

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

[ZeroLogic]

What you are looking for is more along the lines of an asynchronous publish subscribe style architecture such as JMS, MQSeries, or Tibco.

SOAP is designed for easy synchronous communication, and while you can fake synchronous over asynchronous, it can be more challenging to go the other way.

Clue

[Markus Registrada]

The number of different RPC mechanisms extant should be a clue that

• none of them are really satisfactory (else people wouldn't feel compelled to keep inventing new ones), and
• they don't really work out, in practice (else people would be satisfied with one of them).

The problem with RPC is that, to be useful at all, it has to be used where the function-call abstraction fails. In inter-process communication and (more so) in network communications, there are too many failure modes that just don't fit that abstraction, but that a reliable application needs to handle anyway.

The whole point of RPC is supposed to be that the code invoking them looks just like regular function calls. To be reliable, though, they need to be decorated with so much error handling junk that any such benefit is usually lost. You're better off with explicit message passing and a documented wire protocol. You need the latter anyway to have a debuggable application.

#6

[sohp]

Effective dead connection detection and failover is a Hard Problem in general. Asking for a general-purpose RPC mechanism that solves this problem is asking quite a lot. Perhaps it would be worth re-examining the requirements for the system that lead to asking for failover, and considering what other solutions to those requirement there might be other than robust failover.

The problem is your requirements

[mnmn]

RPCs are inherently insecure and introduces a balancing act of keeping the algorithms secure while keeping an eye on inputs and making sure nothing gets memory-leaked.

All this overhead also will take resources. So whats is it exactly youre working on that needs RPCs? Most networked applications Ive seen doesnt need RPCs, especially ones that are secure and efficient.