Distributed Architecture Philosophy

1. Distributed Architecture Philosophy Why asynchronous messaging?

2. 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

3. 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…

4. 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

5. 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

6. 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

7. 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

8. Author: Roger Voss August 14, 2006