Registered: Aug, 2005
Re: Messaging is the Right Way to Build a Distributed System
Posted: Aug 14, 2005 10:55 PM
> I guess I should have missed something, but using web
> services (SOAP and etc) as a front-end to high-granularity
> services implemented by my Session EJB facades provides
> all the exposed benefits of messaging systems? Maybe using
> JMS as a buffer between the web services front-end and the
> EJB back-end?
> I don't think messaging is better or RPC-like systems are
> better. I just think people build too many inflexible
> systems or inefficient ones by choosing among the two.
> Tighy-coupled components should use RPC (and so EJB seems
> better than plain RPC, RMI or CORBA) but subsystems
> boundaries and integration points (to external systems)
> should use messaging.
When designing distributed apps a successful approach is to conceptualize a discreet node in the distributed system as a state machine. Messaging is thus the means for conveying events bidirectionally between state machine nodes. Messaging is more adept for this approach because of its intrinsically queued semantics. Also often times it is desirable to multi-cast events to multiple nodes. RPC is a highly coupled point-to-point communication mechanism that has none of these highly desirable characteristics.
Indeed RPC's lack of queued behavior is higly problematic in terms of attempting to use it in an asynchronous fashion (RPC neophytes like to think they're mimicing messaging when they use RPC asynchronously but they're not all - they've merely pushed RPC into an entirely different quagmire).
Though, I've cited some of the core fundamentals I've barely scratched the surface as to why messaging is several orders of magnitude superior to RPC. Here's a little snippet from one of my presentations on my real-world distributed applications that are messaging based:
Messages are discreet objects that can be arbitrarily manipulated at practically any stage of their existence.
This makes messaging a completely different paradigm relative to RPC.
Messages can be persisted, transacted, filtered, routed, duplicated, logged, bridged, archived, transformed, uni-cast, mutli-cast, etc., etc.
RPC data payloads, in comparison, are ephemeral
The loose coupling aspect is another highly beneficial characteristic of messaging. A given processing node doesn't care what is on the other side of a messaging queue - it could be a single node or it could be a high availability cluster doing round robin processing. It could be a middle-ware J2EE server or it could be a simple 2 tier topology that is serviced directly by a back-end client-server application. The administrative flexibilities due to messaging loose coupling are endless and in the real world of deployment issues - a vital tool in the arsenal.