Messaging vs. RPC 6
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."
my experience (Score:1)
Far as I can tell (Score:4)
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 (Score:5)
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:
In short, the primary difference is that RPC typically connotes synchronous execution, while messaging is typically asynchronous execution.
They're different layers (Score:3)
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 (Score:1)
Re:They're different layers (Score:2)
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.