Distributed Architecture Philosophy

Why asynchronous messaging?

As selected from the ten fallacies of enterprise computing:

The network is reliableLatency is zeroTopology doesn’t changeThe network is homogeneousThe system is finished

From Ted Neward’s book:Effective Enterprise Java

Ted Neward’s Item 19:Prefer data-driven communication over

behavior-driven communicationThis 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