Distributed Architecture Philosophy Why asynchronous messaging?

As selected from the ten fallacies of enterprise computing:  The network is reliable  Latency is zero  Topology doesn’t change  The network is homogeneous  The system is finished From Ted Neward’s book: Effective Enterprise Java

Ted Neward’s Item 19:  Prefer data-driven communication over behavior-driven communication  This means is better to interact remotely by sending documents (data-driven) than it is to invoke methods (behavior-driven) remotely on a distributed object  Ted listed three primary reasons to prefer data-driven to behavior-driven – I’ve added several more…

Ted’s three reasons:  Evolution  distributed object interfaces are brittle because interface consuming code becomes very intimately intertwined with the details of the remote interface (i.e., very high coupling)  the two (interface provider and interface consumer) must carefully be evolved in lock step  XML documents in practice are easier to evolve so as to not break existing deployed code  whereas trying to manage versions of component interfaces over time can become intractable  Intermediaries  filtering, routing, bridging, transformation, processing hook points, etc., can be transparently interposed in the middle  Recoverable operations  easier to build auditing systems  reliable queued backing of messaging makes it easier to build multi- resource transactional systems that support roll-back

My additional reasons:  Less network chattiness  Ted Neward’s Item 18 – Prefer context-complete communication styles  sending context-complete documents evokes less chattiness than calling various methods on a remote interface (unfettered OOP design becomes a definite detriment here)  Non-programmer business analyst can understand XML documents and messaging  web services and other various distributed object RPC are for geeks only (and even they struggle with the complex ws* stack)  OOP approach offers no advantage across distributed computing boundaries  OOP is good for internal app design but offers no value to distributed systems

Still more reasons:  Publish/subscriber pattern is easy to implement with messaging approach  Messaging is symmetrically bi-directional  Event-driven distributed systems are thus readily possible  Messaging is loosely coupled  With RPC, every direct end-point to end-point coupling in the system introduces fragility/brittleness in the overall system topology design  It pays to be oblivious as to who is getting your messages and what they’re doing with them

Ted Neward’s Item 20:  Avoid waiting for remote service request to respond  Learn to build distributed components that behave asynchronously when interacting with the network  My embellishments:  Use a design that separates and centralizes the concern of communication layer exception handling from business logic processing (i.e., remote interface methods that throw RPC i/o related exceptions are bad and to be avoided)  Asynchronous RPC by itself can be semantically dangerous – prefer asynchronous queued messaging instead

Author: Roger Voss August 14, 2006