Peter Holditch

As I understand Western ideas about the world, there seem to have been three distinct phases through which they have passed. In the beginning, people believed that the world was flat, and at the center of the universe.

Eventually, this view was confounded by the likes of Christopher Columbus discovering the New World while singularly failing to sail off the edge, as many were convinced he would do. So the world was spherical, and in the center of the universe. Then Galileo spent a long time in a David and Goliath-type battle with the Church, trying to tell everyone that the world revolved around the Sun, not the other way around. Eventually, he prevailed and now nobody doubts that the world is a spherical planet revolving around the Sun. Throughout this, people have always used the word "world" to refer to the planet (which has remained untrammelled by the debate as to its nature) while the word conjured different pictures in their mind's eyes, depending on the age in which they lived.

So what's a transaction? The definition of a transaction, unlike the definition of the world, changes in two dimensions, both over time, like the definition of the world, and depending on who the observer is. If you ask a bank teller what a transaction is, the answer will probably be that it's a debit or a credit; a salesman will view it as a purchase of his wares, while a techie propeller-head may well start talking in a speedy staccato mumble about two-phase commits and heuristics.

So which of them is right? Of course, they all are. They just look at the question from a different background. Wherever there is a difference between how a user and a techie view a concept, code is written to bridge the gap. It is that gap that is filled by the application server, whose intent is to provide an environment to the app. Designer that is more closely related to the business problem they are asked to solve and less related to the idiosyncrasies of how computer systems work.

Web Services! Where Did They Come From?
The latest attempt to move the bar between technology and users is Web services. The concept is that atomic-style business functions, implemented using various technologies, can be advertised via a repository to be assembled together into useful systems by a 'drag and drop'-type business person, rather than by a 'lines of code'-type technical person. The other promise that Web services offers is that the atomic functions that are composed together into 'business transactions' can potentially be geographically dispersed in nature. Note well that you have just seen a sentence with the "transaction" word in it coupled with components that are potentially dispersed. I didn't just introduce Web services as a red herring; there is really a relationship between them and transactions. In fact, both could even be called transactions. Web services are what the user community might call transactions - debit, credit, transfer, etc. - while their realization will require what the technical community would call a transaction (two-phase commit and all that jazz) since a piece of architecture is needed to provide some level of consistency between the atomic operations that have been composed together.

Quick, Show Me!
So let's take an example. A manufacturer needs to procure 30,000 widgets to complete an order for 300 of their new best-of-breed whatsits. They have three suppliers with whom they regularly deal - electronically of course - via Web services. So the Web service within the manufacturer is called "procure parts" and someone duly calls that with the necessary parameters, the required delivery date, and the number and type of parts required.

The implementation of this Web service calls the "supply parts" Web service of each of the suppliers, selects the most competitive quote, and then calls the "order parts" service of the successful supplier.

On the face of it, this seems like something that could easily be implemented using Enterprise Java Bean components, called using RMI with data updates coordinated using Java Transaction APIs (JTAs). On closer inspection, however, the impedance mismatch between the low-level technical view of a transaction and the business level view of a transaction is revealed.

For a start, the JTA model of a two-phase commit transaction assumes that a transaction can complete successfully if and only if all the component parts of it succeed. In our example, we can successfully complete the business level transaction if any of the three suppliers can fulfill the order, so the model is already different. Secondly, let's look at the physical distribution of the systems and the length of the operations. It's likely that producing a quote will not necessarily be instantaneous - for instance, it may involve a manual step such as management approval. If you read last month's column, you'll think that the wide distribution of the three suppliers and the potential length of time to respond to a quote could present a problem in using two-phase commit-type transactions. You'd be right, since other assumptions made by the two-PC model are that each transaction is of short duration and the resources are relatively close together.

So in the Earth-centric world of that article, you would be using Java Message Service (JMS), to decouple the systems and writing application logic that could cope with multiple updates and compensating transactions. This month, however, the Sun is at the center of the universe

Welcome to the Oasis
It's clear that when no one organization has end-to-end control over a business transaction, and that transaction could well be long-lived, a new model of a technical transaction is needed. This model is known as the "saga" (or sometimes, cohesion) A saga is like a JTA in the sense that it ties a set of related actions together, allowing a system to effect rollbacks, commits, and so on. However, it differs from the JTA view of a transaction in that it makes no assumptions about being able to hold data in a locked state, due to the potential length of time it may be active. A saga can succeed even if some operations within it should fail. To achieve this, the xa_start, xa_end, xa_prepare, and xa_commit operations are replaced by prepare, cancel, confirm, vote, enroll, and resign, allowing updates to be associated and disassociated with a saga as well as expressing their wish as to the outcome. The final say as to the outcome, however, lies with the coordinator, who can selectively choose to ignore no votes according to the business semantics.

Using this transaction model, reliability can be brought to highly distributed transactional systems. The other distinction between JTA/XA and sagas is that where XA provides a programmatic API for the transaction manager to call because they are closely coupled, sagas are widely distributed and a network protocol is needed rather than an API.

Since sagas are intended to span Web services, XML is a natural representation of the protocol elements needed to propagate them and their XML tags are added to business messages by transactional infrastructure, avoiding the need for application-level coding for transactional semantics. Since we are talking about interoperability here, there needs to be a standard for this protocol, and there is.

BEA's implementation of the saga concept is in the business-to-business component of the WebLogic Integration product. This supports a protocol, called XOCP, invented by BEA just for the purpose of propagating sagas. As well as implementing it in a product, BEA has submitted the specification to the Oasis standards body (www.oasis-open.org) where it is known as Business Transaction Protocol (BTP) and will soon be ratified as a release 1.0 standard (if it hasn't happened already).

In Conclusion...
Today there are two choices for implementing widely distributed transactional systems. On one hand you can take the 'tried and trusted' Earth-centric approach and use application-level technologies like JMS, JTA, and compensating transactions to avoid closely coupling unrelated businesses' systems together. On the other hand, you can revolve around the Sun and use the new generation of infrastructure support for sagas and allow the infrastructure bar to be raised again to gain more business value, more quicklys, from your technology deployments.

Either way, as always, technology is only a small piece of the battle. It was hard enough getting inter-departmental agreement within a company, now imagine that problem spread over multiple organizations. In the end, however, the business drivers for agreement and standardization - reduced cost and increased efficiency - will become irresistible, and that is the beauty of building on an app server - your logic is built and deployed now, and at the same time positioned for the future.