Executing individual pieces of software to perform as one unit of work is an area consistently tackled by many software platforms and an issue that is central to many business processes. The all encompassing term for this subject is named "transactions." In the upcoming paragraphs, we will address many of the issues and approaches to working with transactions in the context of Web services.
The importance of dealing appropriately with transactions in Web services arises from the same cross-platform manner in which Web services operate. Since transactions offer an "all or nothing" contract for executing a unit of work, bridging the disparities that might exist between platform specific transaction mechanisms is a necessity in many SOAP-based applications.
Take the Java platform, while JTA (Java Transaction API) provides extensive support for dealing with many transaction scenarios within Java applications, as soon as transaction integrity is required outside the boundaries of any non-Java applications -- such as .NET or PHP -- transaction support generally entails ad-hoc techniques with very strict limitations.
Web services, being a technology used to bridge disparate platforms, has a series of specifications designed to deal with the intricacies of transactions.
Developed by heavyweight industry players like IBM, BEA and Microsoft,
Web services transactions specifications are currently split into three major working groups: WS-Coordination, WS-Atomic Transaction and WS-Business Activity.
WS-Coordination defines the underlying foundations for any transactional process taking place between Web services. Used in conjunction with either WS-Atomic Transaction or WS-Business Activity, WS-Coordination is used to define the mechanism by which Web services register and coordinate themselves to take part in a transaction.
In transactional speak, what WS-Coordination achieves is setting up a context under which to execute and manage the different units -- Web services -- that will take part in a transaction. But while WS-Coordination forms the foundation for transactions, it leaves the transaction protocol details to the two complementary specifications: WS-Atomic Transaction and WS-Business Activity.
WS-Atomic Transaction is actually closely pegged to an existing and widely known protocol in enterprise software: the two-phase commit protocol. While delving into details of this protocol would go beyond the scope of Web services, the basics behind its operation consist of synchronizing an all or nothing task between two resources in order to ensure a consistent outcome.
Generally speaking, the use of a two-phase commit, and hence WS-Atomic Transaction, centers around short-lived operations, or in other words, processes were the success or failure of a transaction is needed to be known rapidly.
WS-Business Activity on the other hand is designed with longer running transactions in mind. The other major difference being the robustness with which it can handle transactional scenarios when compared to WS-Atomic Transaction.
While WS-Atomic Transaction provides an all or nothing solution to transactions -- either success or failure -- WS-Business Activity has provisions for such things as exception handling with the capacity to execute compensatory tasks.
Now that we have covered the conceptual part of Web services transactions, you may be asking yourself how to put transactions together in real world Web services applications. For this, like any other specification, you need an implementation and one such project is Kandula , produced by the Apache Software Foundation.
Being an Apache project, the transactional facilities in Kandula are closely pegged to Axis, which is the de-facto Web services platform developed by Apache. Since this last project is focused on Java, the WS-* transaction support in Kandula plays into Java transactional facilities.
The simplest manner to exemplify the use of Kandula is observing a code snippet, listing 1.1 illustrates what a Web services class using Kandula WS-Atomic Transaction would look like.
Listing 1.1 WS-Atomic Transaction usage in Java using Kandula
import org.apache.kandula.coordinator.at.TransactionManagerImpl;
public class Fullfilment {
public void order(int orderId) {
// More Business Logic
Inventory inventory = new Inventory().getInventory();
TransactionManagerImpl tm =
TransactionManagerImpl.getInstance();
tm.begin();
try {
inventory.ship(orderId);
inventory.deduct(orderId);
}catch (Exception e) {
tm.rollback();
}
tm.commit();
// More Business Logic
}
}
Although the code is Java specific, notice that the calls nested within the try/catch block are making a call to the Inventory class, which in itself is nested between the begin and commit methods of the Kandula TransactionManager. You might also notice the in case an error occurs, a call to the rollback method in the same TransactionManager class is invoked.
Now, as far as the actual methods calls in the Inventory class -- ship() and deduct() -- which form the transaction, even though they form part of the Inventory Java class it is assumed they are in themselves part of a stub class generated from a WSDL contract which is communicating to a remote Web service written in Java or any other Web services supported platform.
By nesting in this manner, Kandula via Axis is propagating transactional information to the Inventory class that is later wrapped in the corresponding SOAP payload for later consumption and coordination by the service end points.
While transactions are often an afterthought for many software projects, when the need arises to manage them explicitly they provide a critical role in fulfilling a software's business functions. The specifications we just covered provide this pivotal role in the still emerging world of service-oriented architecture.
About the Author
Daniel Rubio is an independent technology consultant specializing in enterprise and Web-based software, He blogs regularly on these and other software areas at http://www.webforefront.com.
