This article is based on the book SOA Patterns (http://www.manning.com/rotem) scheduled to print February 2009. This article is courtesy of Manning Publications (http://www.manning.com). The ebook is available and sold exclusively through Manning Publications.

Another important attribute of service construction is: How do we handle messages once we get them either on the edge component or in the service? The Transactional Service Pattern allows for solving this problem while also dealing with reliability problems.

Transactional Service
The nominal scenario of SOA is for a service to get a request to do something from a service consumer, the service then handles the request, maybe asking other services to do some stuff as well, and then produces one or more reactions for the consumer that initiated the request. Figure 6 shows such a nominal scenario in an e-commerce system. A front end talks to an ordering service. The ordering service then registers the order, sends the order out to suppliers, and notifies a billing service. When everything is done, it sends a confirmation to the e-commerce front-end application. The nominal scenario looks very assuring, but what if something goes wrong?

The Problem
Let's consider what might happen if the Ordering Service crashes between acknowledging receipt of the order and processing it - for instance between steps 1.1 and 2.0 in Figure 6. I can imagine our customer sitting comfortably on her favorite sofa, waiting for the postman to deliver whatever it is she ordered. Well, for all I know, she is sitting there still - as the order was lost forever.

What will happen if the service fails just before requesting the billing to process the order -before step 2.3. In this case, the order is lost again - unless the ordering system doesn't wait for the billing and processes the order, which is unlikely. What's more worrying is that we already placed an order with our suppliers and they have a bill coming as well as merchandize we have to store somewhere.

The handling of messages in services is filled with situations like the ones mentioned earlier. We can probably comfort ourselves that most of the time things will work just fine, however, as Murphy will have it - our service will crash eventually and naturally that would happen on that million dollar order. The question is then:

How can a service handle requests reliably?

One approach to solving the reliability problem is to push the responsibility to the service consumer. In the scenario above that would mean that if the service consumer doesn't get the order confirmation in step 2.5, the consumer can assume that the order failed. For one this approach is not very robust and decreases the service's autonomy - the service doesn't have any control over its consumers and they may or may not handle problems. Also it only solves some of the problems - those that have to do with the service consumer. What happens to the interactions the service makes? For instance, in the ordering scenario mentioned above - you can still be in trouble if you fail after step 2.1 of sending an order to the supplier.