Extreme Web Services: Transactions
This chapter is from the book
This chapter is from the book
This chapter is from the book
Over the last several years, transactional programming has regained momentum because developers have recognized its importance in Internet computing. You can see this re-emergence in the products that you use. Microsoft released MTS and eventually COM+, both providing a robust environment for transactional computing. Even Java2 Enterprise Edition (J2EE) supports transactions through mechanisms such as entity beans. Transactions simply make systems more dependable, and that's certainly a goal that we all try to achieve.
So how do transactions fit into the Web Service paradigm? This section takes a look at two opposing approaches to distributing transactions over the Web.
Transaction Authority Markup Language (XAML)
Traditional transactions use a Transaction Authority (TA) to coordinate the orchestration of committing data changes or rolling back data to its original state. This is a common design pattern that has existed for many years.
Extending this functionality to the Web Service model presents several challenges. The most significant challenges are these:
A mixed-vendor environment
Distribution across the Web
Nonstandard, non–Web-based protocols
XAML intends to solve these problems by defining a transactional language, interface, and semantics using XML and other industry-accepted protocols such as SOAP.
At this time, the XAML specification is not currently available, but you can find a whitepaper on the topic at http://www.xaml.org.
The opposing methodology to XAML is based on data reconciliation using messages and validation, as presented in the next section.
Applying Transactions to Web Services
The idea is simple: Because developers currently use transactions to improve software dependability, it makes perfectly good sense that you would try to apply transactions in applications that are distributed across the Web, where potential for failure is extremely high.
Unfortunately, there is one difference—the issue of trust. Do you want your Web Service to be dependent upon some code that you know very little about?
Anyone who was fortunate enough to see the "Autonomous Computing" presentation by Pat Helland (an architect on the SQL Server team and transaction expert) at Microsoft TechEd 2001 is probably rethinking his stance on Web transactions.
The basic premise is: Independently controlled systems cannot and will not trust outside systems. Yet independent systems make up the fabric of the Internet. So how can you possibly manage transactions across Internet-distrusted systems? The proposal is that you can't!
Consider the case of a travel agency portal. The agency's system is designed to schedule airline and hotel reservations for a customer. The standard approach is to design the system so that an airline ticket and a hotel room are booked either successfully or not at all. One without the other is probably of little use to the customer. But to coordinate a transaction across the travel agency, airline, and hotel, they all need to trust one another.
Autonomous computing defines a design pattern that suggests that each independent entity in a computing relationship has private data that cannot be directly manipulated by other entities. Instead, outside entities must request that data be changed. Each request is authenticated, carefully validated, and either used or rejected. Remember that transactions increase the coupling between systems, and Web Services, by nature, should represent very loosely coupled systems.
Your service might choose to use standard transactions internally, but these transactions should never leave the walls of your system. When your service wants to share information to an outside entity, a snapshot of your data can be timestamped and then shipped out. By timestamping, you have stabilized the data, thus guaranteeing the accuracy of the data at some particular instant in time. Realize, of course, that snapshots of data increase in their staleness as time goes on. In other words, it will be easier to process requests that are based on fresh snapshots rather than to process those requests that are based on old snapshots.
The final piece to the puzzle is that your service also must provide ways to undo any changes that were made in previous requests. In the travel agency portal case, the airline and hotel services might each provide a way for reservations to be canceled. So, if a hotel room cannot be found, the customer would have the choice of keeping the flight and finding alternate housing or simply canceling the airline reservations.
The moral of the story is this: If you are building a service that will be used only within a trusted environment, you might have good reason to extend transactions to clients of your service. But any service that will be used on the Web should avoid exposing transactions and follow the stated guidelines.
Transactions are a hot topic in the Web Service arena, and they play an essential part in building dependable systems. This is clearly an area of Web Services that needs more thought.