[ Content | View menu ]

Message Oriented Architecture

Mark Mzyk | October 5, 2008

Neal Ford has a recent post called Sidekick Oriented Architecture.  I recommend reading it for the stories he tells, but the point he makes is a good one:

Service Oriented Architecture is only achievable through message passing.

It’s a simple concept that makes sense when it is articulated, but unless you consciously think about it is easy to miss.

Often, when different services are built for an application, they end up sharing the same database.  While this might seem like a good initial idea, ultimately it becomes a single point of failure as well as a bottle neck for the entire system.  The only way to avoid this is to split the application into two entire different systems that communicate through message passing, not through the database layer.

There are other benefits to this approach.  When each service is entirely separate from any other, then no service is bound by the technological decisions made for the others.  The development team is free to explore different technologies and options for each service.  The only requirement is that each service be able to talk to the the others, and protocols like HTTP make this easy, if not entirely trivial.

There is also the benefit that by decoupling services to the point that all that is needed is message passing, more creative ways to leverage the entire system might be found.  Each time a new service is incorporated, the only technical hurdle preventing it from talking to any other service is enabling it to pass the right messages.  This makes for a modular and reusable design at the service level, a further abstraction up from the code and library levels.

The proof that message passing works can been seen in languages such as Erlang.  Erlang nodes only communicate through message passing, not through shared memory, enabling Erlang’s exceptional concurrency handling.  Message passing at the service layer also provides the same benefits that Erlang enjoys at the language layer; redundancy, concurrency, and stability are all made easier by message passing.

The end lesson is this: Service Oriented Architecture is Message Oriented Architecture.

2 Comments

  1. Comment by Kevin Lloyd:

    Interesting presentation about Dopplr and their use of internal messaging:

    http://blog.dopplr.com/2008/10/10/dopplr-for-developers-its-made-of-messages/

    October 10, 2008 @ 10:57
  2. Comment by Mark:

    Thanks Kevin – that post and accompanying slides are really interesting and I think it points to the way to build a system so that it can easily scale (or as easy as it can be).

    October 10, 2008 @ 12:15