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

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.