distributed architecture philosophy l.
Skip this Video
Loading SlideShow in 5 Seconds..
Distributed Architecture Philosophy PowerPoint Presentation
Download Presentation
Distributed Architecture Philosophy

Loading in 2 Seconds...

play fullscreen
1 / 8

Distributed Architecture Philosophy - PowerPoint PPT Presentation

  • Uploaded on

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:

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Distributed Architecture Philosophy' - arnaud

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
distributed architecture philosophy

Distributed Architecture Philosophy

Why asynchronous messaging?

as selected from the ten fallacies of enterprise computing
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
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
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
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
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
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