Other Web Services Transaction Protocols

Though BTP is the predominant transaction protocol for Web services today, it is by no means the only proposed solution. Even now, there are other implementation options that we can use to build transactions into Web services and there are other specifications that are being proposed as supplicants or replacements for BTP. While the new specifications are interesting, let's first delve into the other practical, implemented alternatives we can use today.

Microsoft .Net

Microsoft's .Net platform provides a rich set of building blocks from which developers can build Web services through its ASP.Net technology. Using ASP.Net, developers can create Web services and hook those services directly into back-end technologies developed on the same .Net platform.

What this means to the Web services developer is that, if it is appropriate, protocols like BTP can be forsaken and instead the facilities of the underlying platform can be applied to support Web services. This is possible because Microsoft's Transaction Server, COM+, and the .Net common language runtime all support the same transaction model, to which ASP.Net Web services have access, as shown in Figure 7-43.

Figure 7-43. Microsoft.Net Stack: A transaction-oriented perspective.

In ASP.Net, we can apply almost the same declarative transaction demarcation attributes to Web services that we can to standard .Net components. We do this by providing the option to run the service within the context of what Microsoft refers to as an Automatic Transaction, where distributed transaction management is automatically delegated to the underlying OS platform.

While the process of adding transaction support to an ASP.Net Web service is straightforward, from a Web services perspective there is an important limitation inherent in this model in that it effectively exposes lockable resources to the Web because the transactions it runs are classical two-phase commit and possess the ACID properties. However, if the Web services that we are going to expose are to work within a particular domain of trust (and not the public Web) then we might be prepared to use this technology, trading off simplicity for scalability, as pictured in Figure 7-44.

Figure 7-44. ASP.Net transactions.

For a Web service the possible transaction semantics that we can apply are as follows:

• Disabled Transaction context will be ignored by ASP.Net and the Web service will not under any circumstances itself create work within the scope of a transaction.

• Not Supported Indicates that the service does not execute within the scope of a transaction. When a service invocation is processed, it is not associated with a transaction, regardless of whether there is a transaction active at the time.

• Supported Indicates that a service will run in the context of an existing transaction, but if no transaction exists then no transaction will be created and the service's work will run outside of the scope of a transaction.

• Required Indicates that a service will run within the context of an existing transaction, or if no transaction currently exists, a new one will be created.

• Requires New A new transaction will be created for each service invocation.

In order to use these declarations and therefore take advantage of the underlying transaction processing infrastructure, it is simply a matter of adding the appropriate attributes to your source code, as shown in Figure 7-45.

Figure 7-45. A .Net Taxi Service Implemented in C#.

 using System; using System.Web.Services; using System.Web.Util; public class TaxiService : WebService {   [WebMethod     (TransactionOption=TransactionOption.RequiresNew)]   public bool BookTaxi(string from, string to, int month,                        int day, int hour, int mins)   {         // Business logic and database interactions   } } 

In the C# class shown in Figure 7-45, the skeleton of a sample taxi booking service is shown, and the TransactionOption field of the WebMethod^[4] attribute is set to RequiresNew indicating that a new back-end transaction will be created for each service invocations which will be used to scope the work that the service will undertake across its back-end databases.

^[4] The WebMethod attribute is a simple means of exposing a method via ASP.Net.

J2EE and Enterprise Java Beans

The Enterprise Java Beans or EJB part of the J2EE specification provides a rich component model where various aspects of component management can be delegated to the server within which the EJBs are hosted. Of particular interest to us here is the fact that, like the .Net framework, the EJB container provides ACID transactional support to its hosted components in a similar declarative fashion, but on a per Bean basis.

When working with EJBs exposed via a SOAP server, it simply becomes a matter of delegating work from the front-end Web service to the back-end EJBs and allowing the EJB infrastructure to manage transactionality on behalf of those components, as shown in Figure 7-46.

Figure 7-46. Delegating transactional work to EJBs from a Web service.

The pattern exemplified in Figure 7-46 is somewhat crude and has the effect of exposing an EJB, or parts of an EJB, to the Web services network. Once again, like the .Net solution, this approach effectively exposes lockable resources to the Web and is a pattern that should only be used within trusted domains^[5].

^[5] It is noteworthy that a similar delegation pattern can also be used to expose other J2EE components like Message Driven Beans over SOAP.

WS-Coordination and WS-Transaction

Web Services Coordination (WS-Coordination) and Web Services Transactions (WS-Transaction) are part of a recent trio specifications published jointly by BEA, IBM, and Microsoft as an alternate way of addressing the problems of generic coordination, and transacting over Web services. The proposed architecture is interesting since it relies on a generic coordination mechanism (whose behavior is specified in WS-Coordination) on which specific coordination protocols are layered. An architectural of this coordination stack overview is presented in Figure 7-47.^[6]

^[6] Source: WS-Coordination specification, http://dev2dev.bea.com/techtrack/ws-coordination.jsp

Figure 7-47. WS-Coordination architecture.

Web services can use the Activation service part of the coordinator to create the coordination context for a particular activity using a specific supported protocol (like WS-Transaction). Once a coordination context has been received by an application, it can then be propagated around that application's Web services, in much the same way as BTP-aware Web services propagate transaction contexts. The context contains the necessary information to register with the activity and dictate how the application will immediately be coordinated.

Though WS-Coordination defines a generic and reusable Web services coordination architecture, at the moment the only such coordination protocol that has been suggested is WS-Transaction. WS-Transaction in some respects shares many of the same goals and the same general style as BTP.

WS-Transaction is built on two distinct transaction models that the authors of the specification believe to be suitable for the kinds of situations that will arise when transacting across a Web services environment. The two transaction models it supports (based on the transaction model developer for Microsoft's BizTalk server) are:

• Atomic Transaction

• Business Activity

An atomic transaction is essentially an XML marked-up version of the classical all-or-nothing atomic transaction. Atomic transactions are meant to underpin activities that last for short periods of time, where the locks necessary to maintain consistency will not be held for so long that performance will not be degraded, and should be run in trusted environments to prevent denial-of-service. The WS-Transaction specification is quite clear in the fact that it should be used in conjunction with the WS-Security specification to ensure that transactions only span trusted domains.

An atomic transaction essentially consists of five distinct activities that various actors in the system may instigate:^[7]

^[7] Based on the WS-Transaction specification, http://dev2dev.bea.com/techtrack/ws-transaction.jsp#ws-transaction__toc16503456.

• Completion One the application that created the transaction registers for the completion protocol, so it can tell the coordinator to either try to commit the transaction or force a rollback. A status is returned to indicate the final transaction outcome.

• CompletionWithAck Same as Completion, but the coordinator must remember the outcome until receipt of an acknowledgment notification.

• PhaseZero The Phase Zero message is sent to interested participants to inform them that the two-phase commit protocol is about to begin. This message allows those participants to synchronize any persistent data to a durable store prior to the actual two phase commit algorithm being executed.

• 2PC A participant registers for these messages for a particular transaction, so that the coordinator can manage a commit-abort decision across all the participants (i.e., this is analogous to the BTP enroll). If more than one participant is involved, both phases of 2PC are executed. If only one participant is involved, a One Phase Commit (a 2PC performance optimization used in the case of a single participant) is used to communicate the commit-abort decision to the participant.

• OutcomeNotification A participant that wants to be notified of the commit-abort decision registers to receive this "third-phase" message. Applications use outcome notifications to release resources or perform other actions after commit or abort of a transaction.

Although some of the language used to describe atomic transactions differs from that used to describe BTP atoms because of WS-Transaction's reliance on the underlying coordination framework, the semantics of many of the messages are similar.

On the other hand, business activities bear little resemblance to any mechanism in BTP. Business actions are designed for use in long-running transactions and ensure that any updates to state in a system are made immediately, thus significantly reducing the period of time for which locks need to be held (and reducing the window of opportunity for denial-of-service). That is, there is no notion of a two-phase commit for a business action because updates are committed immediately on receipt of their associated messages, and it is only in the case where a failure occurs later in an activity that participants are re-contacted. In the failure case, compensating actions are run to restore the data housed within a participant to a consistent form.

Of course, the identification of what constitutes a "short-lived" transaction from one with greater longevity is subjective, and opinions and practices will differ from architecture to architecture. The WS-Transaction spec offers a possible taxonomy^[8] to clarify to developers which kind of transaction should be used in a particular use-case, as shown in Figure 7-48.

^[8] Source: WS-Transaction specification, http://dev2dev.bea.com/techtrack/ws-transaction.jsp#ws-transaction__toc16503466.

Figure 7-48. WS-Transaction atomic transaction/business activity taxonomy.

To date, there are no available implementations of the WS-Coordination or WS-Transaction specifications, and so at best we can only imagine its deployment and use patterns. However, WS-Coordination and WS-Transaction have the backing of several important Web services vendors and it will only be a matter of time before implementations are made available to the developer community.