For several years now there has been a discussion on transactional processing in SOA. Despite the fact that several standards, including BTP, WS-BusinessActivity, WS-AtomicTransaction, WS-Coordination have been proposed to solve this problem, there is still no widely accepted solution. In his new post, Arnon Rotem-Gal-Oz presents an excerpt from his upcoming book - Practical SOA - Reservations pattern.
Arnon describes the problem with SOA transactions as following:
... in a distributed world, SOA or otherwise, it is rarely a good idea to use atomic short lived transactions... the fact that cross service transactions are discourages is one of the main reasons we would to consider using the Saga pattern... One of the obvious shortcomings of Sagas is that you cannot perform rollbacks... Still, since interactions, and especially long running ones, can fail or be canceled Sagas offer the notion of Compensations. Compensations are cool; we can’t have rollbacks so instead we will reverse the interaction’s operation and have a pseudo rollback... Unfortunately, there are a number of problems with compensations. These problems come from the fact that, unlike ACID transactions, the changes made by the Saga activities are not isolated. The lack of isolation means that other interactions with the service may operate on the data that was modified by an activity of other sagas, and render the compensation impossible.
Arnon also mentions another limitation of compensations and the Saga pattern itself - a requirement for an external coordinator which might introduce unwanted coupling of services to the external coordinator.
In his post Arnon proposes the pattern, which tries to answer the question:
How can we efficiently provide a level of guarantee in a loosely coupled manner while maintaining services’ autonomy and consistency ?
The solution, the Reservation pattern, requires the introduction of an internal service component handling reservations. The responsibilities of the component include:
- Reservation - making the reservation when a message that is deemed "reserving" arrives. For instance when an order arrives, in addition to updating some durable storage (e.g. database) on the order it needs to set a timer or an expiration time for the order confirmation alternatively it can set some marker that the order is not final.
- Validation - making sure that a reservation is still valid before finalizing the process. In the ordering scenario mentioned before that would be making sure the items designated for the order were not given to someone else.
- Expiration - marking invalid reservation when the conditions changed. E.g. if a VIP customer wants the item I reserved, the system can provision it for her. It should also invalidate my reservation so when I finally try to claim it the system will know it’s gone. Expiration can also be timed, as in, |we’re keeping the book for you until noon tomorrow.
This pattern enables managing the resource allocation process in an orderly manner by implementing a two pass protocol (somewhat similar to a two phase commit). During the first pass, the initiator asks each participant to reserve itself. If the initiator gets an OK from all the involved services (within a timeout) it will start the second pass, confirming reservation to all the participants.
Unlike many other SOA patterns, the Reservation is more a business pattern than a technological one. This means there isn’t a straight one-to-one technology mapping to make it happen. Arnon also describes a possible pattern’s implementation based on EJB 3.0.
Considering that transaction processing is the cornerstone of today’s software technology that makes distributed computing reliable and manageable and it is used by large enterprises in transportation, finance, insurance, telecommunications, manufacturing, etc. depending on transactional processing for funds transfer, payments processing, electronic communications, inventory control and other processing, it is extremely important to implement some form of transactions in SOA. The Reservation pattern, as defined in Arnon’s post, is an important tool in SOA architect’s toolbox.
But then there is the question: should services invoke each other, or there should be a process orchestrating service invocation? In the latter case such process is effectively a coordinator and if services interfaces support both actions and compensations then the Saga pattern might be a simpler solution.