Choosing an RPC Mechanism

In my opinion it's always worth separating components on an application level. Rather than developing libraries to be used locally in an application domain, I imagine software to be built up of many "serverclients" communicating over TCP/IP. There are some pretty compelling benefits in "serving" this functionality instead:

• You can scale particular parts of the overall application as required.
• You can plug and unplug components without too much hassle.
  
• You can genuinely use disparate platforms (as opposed to when you're really compiling them all to the same low level language).
• You have separation, isolation and decoupling built into your design and implementation.

Of course none of this comes for free - the main drawback come with the implicit use of some kind of remote procedure call, or RPC, mechanism. RPC is a generic term describing the manner in which these components would talk to each other and since it's inherently something not "native", it generally brings with it issues of interoperability (you can't use a language feature of a remote API if you don't support it yourself) and overhead (due to the transporting of the actual procedure call and its results).

Still, I think it's worth looking into anyway for the benefits. For my current project I've looked at a few RPC mechanisms:

• Java RMI. Nails the remoting bit on the head but at the cost of interoperability. Although I'm coding most of my components in Java I feel RMI doesn't help with what I want RPC for. It would require the least amount of effort though since RMI would know exactly how to serialise and transport my Java classes. Everything else will need to be told.
  
• CORBA. Standard, established and interoperable. But totally nasty, so no.
  
• Webservices. Promising: again established across mutliple platforms, but not really lightweight though - it requires a webserver for a start and further uses XML (something I've never really seen the advantages of in cases like these) resulting in lots of traffic for the simplest of things.
• JSON-RPC. An RPC mechanism based on the relatively lightweight data-interchange format JSON. This solves the XML problem seen in webservices, and since it can run over a tcp socket it should be pretty quick too. It's new (and thus cool) so there's lacking support for it so far.

I've chosen JSON-RPC and am using the jAbsorb library to implement it. I've ended up using it over HTTP though and this requires a webserver (which I wanted to avoid having to use) but the embedded jetty webserver isn't too bad. As mentioned I'll have to create some custom serialisers to transform my classes into JSON (and back again) but that shouldn't be too difficult.