Message-Driven SOA = Robustness

I love Bill Poole's blog - In a post last year, Bill describes a service model that is built around cohesive business areas/capabilities and along the following principles: large grain services; asynchronous reliable communication; no centralized data; no cross-service transactions.

In the past I've worked as architect on an eGovernment project that followed just these same architectural principles. That was by design and also by necessity -- since the underlying product (SonicESB) naturally guided developers into modelling services as entities with a purely message-oriented interface (of course, that was putting the horse before the cart). Services in SonicESB aren't really services in the conventional sense -- they are written against an API and can communicate with other Sonic services only using that API. The API binds onto a JMS abstraction layer that exercises the underlying MOM implementation. However, some queues that drive services may be exposed via Web service interfaces to the external world. Sonic also offers a light-weight process construct: itinerary-based routing includes a routing slip with every message and describes which queues/services must be traversed in what order.

The project team really bought into the benefits of temporal decoupling and came to see it as godsend -- they also came to accept the unusual asynchronous communication style that goes with it.

• individual service may be taken down for maintenance without negatively affecting the rest of the system -- messages simply get buffered until the service comes up again
• as a corollary to the above: services do not need to handle peak loads -- just the average load. When bursts of messages arrive they are simply backlogged in the queue until the service can process them.
• non-blocking for the message producer: fire-and-forget with reliable messages; producers "know" that messages eventually arrive - SLA of the recipient is can help in giving a deterministic timeframe
• monitoring of queues: analyze queue utilization over time; detect usage patterns and adapt to and/or predict load situations;
• inspection of in-flight messages: analysis of messages; remove and store individual messages; replay them at a later stage (or for testing); isolate poison messages and use them for failure analysis

While this particular system was built on top of Sonic, the general principles can be carried over onto any technology that supports reliable asynchronous messaging. Examples are JMS, AMQP, XMPP, WS-Notification, and others. The problem here is: how do you schema-describe your messages? This can be done by out-of-bounds mechanisms, albeit unsatisfactorily.