Adopting, designing, and governing SOA well

SOA Best Practices Digest

Subscribe to SOA Best Practices Digest: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get SOA Best Practices Digest: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


SOA Best Practices Authors: Jason Bloomberg, Hollis Tibbetts, Pat Romanski, Liz McMillan, Lori MacVittie

Related Topics: SOA Best Practices Digest, SOA & WOA Magazine

SOA Best Practices: Article

SOA Patterns: Basic Structural Patterns – Part 2

The Transactional Service Pattern

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.

More Stories By Arnon Rotem-Gal-Oz

For the past 10 years Arnon Rotem-Gal-Oz has been an architecture and system designer of large distributed systems including C4ISR systems, IP customer care and billing systems, and BI engines. He has experience with a variety of technologies (.Net, J2EE, CORBA, COM+, X-Windows) on diverse platforms (Unix, Windows, Dos, AS/400). He currently works for Rafael as the Biometric line development manager.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.