|
Developer WEB SERVICES
Who Needs Web Services Transactions?
By Mike Lehmann
Transaction support emerges in Web services standards.
Think of transactions in business applications, and you immediately think of banking, stock exchanges, and airline reservation systems: classic large-scale,
high-value enterprise systems where incorrectly captured information can have serious consequences.
Strangely, when you try building your first application using Web
services, you'll find there's a dearth of information about Web services transactions. Look through your vendor's documentation, and you probably won't find anything on it.
Surely somewhere in Web services—the biggest technology trend in the last five years—there should be lots of information about service-oriented transactions. This column will look at the past, present, and future of Web services transactions specifications.
Web Services Transaction History
It's not as if the industry forgot about transactions as soon as Web services came along. Rather, transactions haven't been fundamental to the success of those applications that
have used Web services so far.
Many early Web services projects focused on repurposing already proven request/response Web architectures, where transactional support was either explicitly coded into the application layer using classic Web techniques such as HTTP sessions or cookies, or explicitly avoided by having the application simply provide read-only access to back-end business systems. But more developers are creating projects that test the limits of simple Web
services, prompting several standards efforts to bring transactional semantics to Web services.
In 2000, a number of vendor heavyweights wrote a specification called Transaction Authority Markup Language. In 2001, BEA created a specification called Business Transaction Protocol.
In 2002, IBM and Microsoft created WS-Transaction and WS-Coordination as part of the Business Process Execution Language
for Web Services (BPEL4WS). And, in August 2003, a vendor consortium that includes Oracle presented the Web Services Composite Application Framework
(WS-CAF) as a superset of these
previous efforts.
Transactions: Needed or Not?
In traditional applications, most transactions tend to be short-running and synchronous and involve small numbers of players: a customer debiting a bank account, a traveler reserving a plane seat, or a stock trader completing a buy transaction. These are atomic transactions. This space is well understood; what has been missing is simply a Web services layer on top of these transactional semantics.
Integrating transactional semantics with Web services becomes more complex in the area of business processes. Here, the Web services interactions tend to be long-running and asynchronous, involving many parties. For example, a traveler planning a business trip through a travel agent illustrates the complexity of a typical business process. Such a business trip transaction based on Web services could require the agent to interact with an airline reservation system, a hotel booking system, and a car rental system. Figure 1 illustrates this scenario.
Figure 1: A business traveler using a travel agent to book a trip
This scenario presents a number of issues:
If any of the interactions fails, the traveler may need to work with the travel agent to rethink the entire business trip transaction, perhaps changing not only the failed transaction but related transactions as well.
Unlike traditional atomic transactions, it would be difficult to lock all the participating resources while waiting for the others to complete. The airline and hotel reservation systems could not be kept waiting, for example, for an action in the car rental system to complete.
Each subtransaction has to complete on its own and then somehow be related back to the larger, long-running business trip transaction. In real life as well, the business trip transaction is often part of an even larger transaction. For example, the traveler might want to combine the business trip with a vacation.
This style of transaction is called a business activity. Business activities often have some characteristics derived from traditional atomic transactions (for example, each step may have atomic characteristics), but because they are long-running, sometimes spanning many minutes, hours, or even days, a new set of semantics has to be created to deal with these differences.
Mapping Transactions to Web Services
When an intermediary such as a travel agent manages these interactions, each issue can be dealt with by human intervention. In Web services, however, these steps are often automated to reduce the need for human intervention.
Most of the proposed Web services transaction specifications tackle both atomic and business activity transactions, because they inevitably go hand in hand in Web services scenarios. In fact, BPEL4WS was released in conjunction with the WS-Transaction and WS-Coordination specifications because of the clear relationship of transactions to business processes.
A defining piece of Web services transactions is a distributed transaction coordinator. Somewhat analogous to the travel agent in our scenario, the transaction coordinator acts as an intermediary, tracking all interactions with the underlying services and, upon notification from the traveler—through the business application—coordinating the acceptance or "commit" of the transaction.
Unlike the classic distributed transaction coordinator in atomic transaction implementations such as Oracle Database, the Web services transaction coordinator itself is a Web service that receives communications via SOAP messages. Acting as a transaction coordinator does not, however, define what the transaction protocol itself will be. That is usually defined by complementary specifications to the coordination specifications—for example, WS-Transaction and WS-Transaction Management. These specifications outline how Web services implementations describe common transactional operations such as "begin," "commit," and "rollback" in the context of both atomic and business activity transactions.
Rounding out the requirements to implement Web services transactions, the transaction protocol does not, on its own, define a shared context that identifies a particular atomic or business activity transaction uniquely among concurrent interactions. WS-Context, from the WS-Composite Application Framework, outlines how to create a common shared context that can be used to carry this information between participating Web services. Figure 2 shows these moving parts in the original business trip scenario.
Figure 2: Web services transactions for a business trip
Business Activities and Compensating Transactions
So far, Web services transactions don't appear to be much different from ordinary transactions, with the exception of a Web services layer. Where they really differ, however, is in business activities. In particular, all of the Web services transaction specifications define a compensating transaction where, rather than rolling back transactions when an abort condition occurs, a set of undo actions can be specified to be applied to one or more Web services interactions.
To revisit our travel scenario, imagine if a direct flight between San Francisco and Vancouver were no longer available. A compensating transaction could be executed to try to book an alternative time and route with a stopover in Seattle. This might affect the matching hotel booking, requiring another compensating transaction to accommodate different hotel arrival and departure times.
Compensating transactions are so fundamental to automating business processes that BPEL4WS includes an explicit declarative mechanism to embed them for failed Web services activities, such as in this scenario.
How Long Until they're
Standards-Based?
You may have noticed that this article refers to WS-Transaction/WS-Coordination and WS-CAF as specifications, not standards. At the time that this article is being completed, however, WS-CAF has been submitted to OASIS, which bodes well for organizations that are ready to move Web services from a basic foundation technology to a mission-critical technology they depend on for enterprise application development and integration.
Keep your eyes on Oracle Technology Network as Oracle not only continues
to help shape Web services standards such as WS-CAF but also starts providing preview implementations of Web services transaction support in Oracle Application Server 10g.
Mike Lehmann (mike.lehmann@oracle.com) is a principle product manager for Oracle Application Server Containers for J2EE 10g.
| 
Bookmark
