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