Messaging vs. RPC

darrint asks: "I'm about to write yet another application with parts on different boxes and OS's and languages. Some of my server apps need to be fault tolerant and/or support load balancing. I've worked so far with CORBA and have also looked at the features of XML-RPC and Ensemble. I see two different approaches: remote procedure calls and messaging. Can anyone enlighten me as to the less obvious consequences of choosing one approach over the other? I'm particularly interested in how the approaches support fault tolerance."

Comments

Far as I can tell

[bluGill]

As far as I can see, they are different schemits of doing the same thing. That is with messaging you have to parse your own messages and then call the correct function, while with RPC the correct function is called.

RPC tends to be a little slower then customer written parsers, but it makes up for that by being eaiser to write to, more features (error handeling especcially). You can of course get all those advatnages with custom written message passing, it just requires more work.

Message passing also works well when you have a lot of data to pass between two host which both of a byte order different from network, if your RPC protocol translate everything to network order. (Sun RPC did by default, others don't)

In general RPC is quick and easy, and normally good enough. Message passing is harder, but you have more controll. If you need every last ounce of proformance, message passing will get it, but you have to do all the dirty work yourself, expect to spend a lot longer on in. RPC will take care of a lot of hard problems, including many that you don't anticipate having.

Asynchronous vs Synchronous execution

[MemRaven]

I think someone pointed out the queueing nature of messaging as opposed to RPC, but let me point it out here. There are multiple ways of doing RPC, some of which encapsulate your parameters in some kind of abstract notion of a "message" or "packet" (such as XML-RPC). However, they all have one thing in common: they're synchronous protocols at their core. You make a function call, the parameters are marshalled on the client, transmitted to the server, unmarshalled, the function is executed, and the result is marshalled and unmarshalled. This all happens in one thread of execution on the client, it seems like you called a local function.

Messaging, on the other hand, is typically asynchronous. You prepare a message, and then pass it off to your client-based message handler. Then, at some point in the future, it's guaranteed to be executed. You might say you want an asynchronous notification of when it executes, you might be able to poll at a later time for the result, or you might just trust that the system is going to handle the situation appropriately. But the moment the parameters are marshalled on the client, the client can and will continue with its work.

It's a fundamentally different model for many cases, and sometimes is NOT appropriate for application logic. And at its core, you can implement RPC over some kind of messaging system (in which case the client libraries will just not return from the "enqueue" call until they've gotten the "executed" event back from the server), but that's not what people use it for.

There are a couple of things which messaging then gives you which conventional RPC does not:

• You can very easily scale out your number of servers with messaging. While with XML-RPC or SOAP you could in theory just stick a load balancer in front of your server farm and scale out that way, enterprise messaging is more designed for the case where you have multiple servers handling multiple clients, and enterprise systems will make this very easy to handle.
• You can pass the same message to multiple servers, thus allowing you to update multiple systems at the same time if it's an update type of message.
• Messaging typically involves transactional semantics. Once you marshall the parameters on the client, the underlying system will guarantee that the message gets delivered, assuming the system doesn't explode (for example, if the server happens to be down, when it comes up the system will deliver your message, but if it never comes up the system will just hold your message forever unless you have an expiration).
• Enterprise messaging systems are designed to integrate with transactional environments very well, while RPC is not. (you're doing a transactional call with RPC where the transaction began on the client. Who owns the transaction now? Big question with RPC. For most messaging systems, it's clear that it's all just one transaction).

In short, the primary difference is that RPC typically connotes synchronous execution, while messaging is typically asynchronous execution.

They're different layers

[K-Man]

RPC, CORBA, etc. and messaging are obviously related, but in some sense it's like comparing sockets and UDP. I was working on this conundrum a year or two ago, and eventually I decided to build a model with separate layers similar to OSI.

You have several goals that you want to serve: reliable delivery, clean interface, type checking, load balancing, crash recovery, extensibility, and so on. If you can lay out the layers so that each goal is handled at some level, without requiring much intervention at a higher level, then your architecture will work.

IIRC, this is what I came up with:

object level (eg CORBA, database, web "shopping cart"):
instance/state management (new, destroy, etc.)
persistent connections/sessions/transactions/data
type definition and inheritance
interface (method) definition
call level (eg RPC):
marshalling (based on interface definition)
call/return functionality
object exception delivery (bad params, etc.)
messaging level (eg UDP, message queues):
reliable one-way delivery
performance monitoring (queue sizes, etc.)
network exceptions (eg unreachable host)
queue management - restarting, rehosting, etc.

This breaks the system into layers where each layer has a definite scope. Messaging only cares about the life cycle of each message; call level only cares about the duration of one call/return round trip (based on a single interface), and the object level worries about more persistent things and their lifecycles.

Re:They're different layers

[K-Man]

Don't misunderstand me, I wasn't defending monolithic ORB's, or over-upholstered development environments. In fact, the original goal of my work was to break down the ORB idea into smaller, separate, manageable pieces, and assess how well our legacy stuff (a high-volume website) was fitting into the puzzle. The target architecture that seemed most practical is like your "New Model"; the layers use XML to exchange data, clients are thin (http), and manual coordination of interfaces is sufficient for most uses.

The "object layer" is a design abstraction, and I honestly haven't implemented an ORB ever. Many of the services needed to manage complicated object lifecycles can be supplied by simpler tools, like transaction managers, or cookies. The trick is to know what functionality you want, and compare alternatives.