By their very nature, Web services operate in a loosely-coupled, geographically-dispersed environ-ment. From an infrastructure perspective, what does this mean for transaction processing systems? Do the existing approaches to handling transactions through the use of an XA-compliant, two-phase commit transaction manager apply directly to Web services? Typical transaction manage-ment infrastructures have complete control over the resources that participate in a transaction: either every resource fully commits or fully rolls back.
In a Web services environment, however, the resources that need to participate in a business transaction need to be aligned, but not dictated to. The business actions of one service need to coordinate and align themselves with the business actions of another service. Even though each node or participant in a Web service can have an independent workflow that executes on its own business rules,
the entire business transaction still needs to behave as a single unit. In a loosely-coupled environment, there can't be a central transaction manager dictating all of the
rules, commits, and rollbacks. In many circumstances, the business rules of an individual participant may override the intentions of the business transaction. In a business world, transactions need to be coordinated with oversight while still providing voting privileges for the participants. Additionally, just because some participants may not favor the outcome of the business transaction and/or vote against it, the transaction may still continue to commit.
In a business environment, this is analogous to any negotiation. For example, when an author negotiates a new book contract, that author negotiates the terms and arrangements with multiple publishers. Some publishers may offer higher royalties while others may commit senior editors to oversee a project. The author and each of the publishers need to participate in a single business transaction. In this scenario, as long as the author and at least one publisher are still participating, the business trans-action can continue. The business transaction could still fully commit even though some of the publishers opt to roll back their individual participation. In an XA-compliant, two-phase commit transaction scenario, the flagging of rollback from any resource eventually causes the entire transaction to roll back.
As another example, a car manufacturer may only want a business transaction to fully commit if they can purchase 100,000 tires for less than $1,000,000 and subcontract the painting and detailing of their cars for less than $500 per car. If one of these conditions can't be met by either trading partner, then the entire transaction needs to roll back. To commit to delivering 100,000 tires, the tire manufacturer needs to lock up the resources necessary to produce the tires. Additionally, for the painting subcontractor to commit to the transaction, they need to ensure availability of supplies. At any given time, any participant can back out of the negotiation and the business transaction. And, based on the demands and rules of engagement, the transaction can continue or be cancelled.
Businesses naturally run this way, and
a technology infra-structure to support the same type of behavior is needed. A technology infrastructure is required to link business actions into a cohesive unit across departmental or corporate boundaries. This fall the OASIS Business Transactions technical committee (www.oasis-open.org/committees/business-transactions/) will adopt the Business Transaction Protocol (BTP) as an OASIS Committee Specification. The BTP extends the two-phase commit transaction management approach to address the needs of disparate trading partners that use XML to exchange data. This article provides some basic information about the BTP. Architects, developers, and businesses expecting to perform intra-enterprise or trading partner integration will find the BTP a critical component for their future projects.
The Basics of Business Transactions
At the lowest levels of the BTP, there are two types of work orders: atoms and cohesions. An atom is the simplest unit of work and behaves like existing XA-compliant, two-phase commit transactions. An atom of work follows the traditional ACID (Atomic, Consistent, Isolated, Durable) properties and must either fully commit or fully roll back. In a Web Services environment, the operations exposed by a single Web service and/or the internal processes of that Web service would usually make up a single atom. It's possible to have an atom that spans Web services, but there are many limitations to allowing that.
A cohesion is a set of atoms that can be manipulated by a business transaction's initiator. With a cohesion, an initiator is allowed to dictate whether each atom within the cohesion succeeds or fails, even if the atom is capable of succeeding. A cohesion is a transaction that is run by a voting/enrollment process where the initiator of the transaction has the final approval or rejection vote. The initiator can apply business rules to its decision-making process in full light of the recommendations made by all of the atoms in the transaction. Another way to view a cohesion is as a reduction process: when a cohesion begins, many atoms can be enlisted as part of the business transaction, but the cohesion provides a structured approach to reducing the choices available, with the intention of driving a single, successful outcome in the end.
A cohesion can easily be structured to be run by a program. For example, the sample code shown in Listing 1 demonstrates what creating an atom and cohesion may look like. Note that the BTP doesn't define a standard API and that this is purely for demonstration purposes.
The Roles in a Business Transaction
The BTP specification defines its scope based upon the actors that can be involved with a business transaction. There are a variety of roles defined in the specification:
Initiator: This is a software agent that initiates a business transaction. The initiator sends application messages to a Web service in order to invoke operations. The service responds to the initiator in kind. The initiator's organization is considered the Party and
the Web service's organization is considered
the Counterparty. In a business transaction, there can be a single Party and many Counterparties, each of which contain mult-iple Web services.
Coordinator: This is a software agent that can decide the outcome of a single atom. The coordinator tracks the set of participants that are enrolled in a single atom and has the same lifetime as an atom. A coordinator instructs participants to prepare, cancel, and/or confirm. The coordinator makes its decisions based upon input from participants and the initiator.
Participant: This is a software agent that is capable of executing prepare, cancel, and/or confirm commands issued by a coordinator. The participant has a designated business transaction protocol communication address where communication with the coordinator occurs. A participant is responsible for executing the termination protocol (i.e., if a confirm command is sent, then the results of all actions of the services contained within the participant must be made permanent; if a cancel command is sent then the actions of the services must be undone).
Service: A software agent that handles and responds to application messages. A service participates in a business transaction by way of a participant.
Figure 1 shows the relationships that the different actors can have. Even though there are four different relationships that can occur, the BTP specification only defines the coordination protocol between the Coordinator and the Participant and the operation invocation protocol between the Initiator and the Service. The definition of the demarcation and participant API is left to other bodies such as the Java Community Process. The code snippet provided in this article is a simple example of a demarcation API that may be created for cohesions and atoms.
It's important to understand that the operation invocation protocol isn't a competitor or likeness of SOAP. Rather, it defines extensions to existing XML-based interoperability standards to facilitate invocation operations under the context of an atomic or cohesive business transaction. Transaction ident-ifiers and other context inform-ation about entities participating in a business transaction must be relayed on every message passed between two processes. The operation invocation protocol defines the extensions necessary to facilitate this behavior.
Understanding the Protocol
The BTP is a protocol, but doesn't necessarily participate in a protocol stack. TCP/IP, RMI, DCOM, and SOAP are all protocols that operate as part of the wire protocol stack. They dictate the semantics of conversation between two nodes that are invoking services. The BTP isn't part of this protocol stack and should be considered an infrastructure support mechanism. (If the wire protocol were drawn as a top-down stack, the BTP would be a dotted line accessory.) You can liken BTP to other infrastructure technologies that are aligned with wire protocols, but aren't part of the stack, such as security, routing, reliability, and attachments.
Additionally, the BTP will occur behind the scenes from any developer. Developers will use a demarcation API, such as something similar to the Java Transaction Architecture (that hasn't yet been built) to control an Initiator of a business transaction, but not to create the BTP protocol messages. The BTP protocol messages will be sent between Initiator/Service and Coordinator/Participant transparently as the state of the system progresses.
Figure 2 shows a big-picture view of the actors and the invocations that they can make upon one another. There are a variety of invocations that can be done as part of the BTP, most of which take place behind the scenes in a typical application. The specification defines its scope based upon the actors that can be involved with a business transaction.
There are a variety of messages that are communicated between actors:
Operations: An initiator invokes the operations of a service using a BTP-supported operation invocation protocol. The BTP operation invocation protocol could work over SOAP or the ebXML TRP, for example.
prepare(): This message is sent from a coordinator to a participant. A participant returns successfully if the set of operations that's participating in the atom is capable of successfully canceling or confirming. It's similar to the first phase of a two-phase commit.
cancel(): Sent from a coordinator to a participant, this message instructs a participant to process a countereffect for the current effect of a set of procedures. It's essentially the rollback of an atom.
confirm(): This message is sent from a coordinator to a participant, and instructs a participant to ensure that the effect of a set of procedures is made permanent. It's the commit of an atom.
vote(): This message is sent from a participant to a coordinator. It can be either unsolicited or in response to a previous prepare() message. A participant can vote to cancel, ready, ready with inability to cancel after timeout, or ready with cancel after timeout. The participant uses these messages to inform the coordinator of the current and upcoming status of the participant.
enroll(): This message is sent from a participant to a coordinator when a participant has a set of services that want to participate in an atom. When an initiator first makes an invocation on a remote service, the invocation will have the atom identifier associated with it. The service will relay that identifier to a local participant that will contact the coordinator and ask to enroll in the atom.
resign(): This message is sent from a participant to a coordinator when the operations on the service have had no effect on the atom. It informs the coordinator that the service should no longer participate in the atom.
Where to Get the Protocol
Currently, there aren't any infrastructures that support BTP, but it should rapidly be adopted in the upcoming year. BEA Systems, HP, Choreology, Interwoven, AppliedTheory, IPNet, Bowstreet, Entrust, Sun Microsystems, and Talking Blocks are all members of the technical committee. Any of these vendors could provide a BTP infrastructure in the very near future. For example, BEA Systems, Inc. is already looking at how BTP will be incorporated into a near-release of the WebLogic Integration platform. Also, upon acceptance of the BTP within OASIS, Microsoft and the Java Community Process will likely follow suit by forming committees to create standard demarcation and participant APIs. Additionally, Choreology currently has a simple trading demo based upon the BTP. It can be downloaded from
www.choreology.com/.
Summary
The BTP specification provides a much-needed addition to the infrastructure community. Its support among transaction managers will provide flexibility not currently available within XA-compliant, two-phase commit transaction engines. The BTP specification provides participant autonomy so that the decisions of one participant mimic the behavior of a corporate negotiation. Corporate negotiation requires compen-sation-based reversals, coordination of cohesions, and participant-defined timeouts that can impact an atom, but not necessarily a cohesion. Additionally, the BTP allows for a transaction to operate with discontinuous services that may come and go. In a real organization, quotes and contract negot-iations can last milliseconds or years; the BTP allows for long-running transactions without limiting the scalability of any single participant (a participant is allowed to cancel based upon a timeout dependent on its business requirements). Also, the BTP is designed to be interoperable via XML across any number of communication wire protocols, allowing it to work with an application built on any popular platform.
For more information about the BTP or to see the latest draft, visit the OASIS Web site at
www.oasis-open.org.
Cloud computing is a game changer. The cloud ...
Subscribe to SOA World Magazine Email News Alerts
Subscribe via RSS
