[Bernstein09] 10.8. TP Standards

10.8. TP Standards

Historically, standardization has been very challenging for TP technologies, due to the broad variety of implementation architectures, programming models, communications protocols, and integration points among modern and legacy products. The main goals of TP standardization are:

• Portability: Allowing the same transaction program to run on different transactional middleware products

• Interoperability: Allowing multiple transactional middleware products to exchange data or control information while executing within the same transaction

• Integration: Allowing components from multiple transactional middleware products that perform different functions to work in combination

We will focus primarily on standards pertinent to the .NET Framework and Java EE transactional middleware and touch only briefly on other related standardization efforts. The primary standard for transactional interoperability is defined by the Web Services transactions set of specifications. We describe the following standards:

• The Web Services Transactions (WS-Transactions) set of specifications from OASIS

• The XA protocol from the Open Group

• The Object Transaction Service (OTS) from the Object Management Group

• The Java Transaction API (JTA) from the Java Community Process

These last three standards are related. The XA protocol is incorporated into OTS, and both XA and OTS are incorporated into JTA. The XA protocol is perhaps the most successful TP standard. Most transactional resource managers support it for two-phase commit, including relational database systems and asynchronous message queues.

We also briefly mention the emerging Service Component Architecture (SCA), OSGi enterprise edition, and Advanced Message Queuing Protocol (AMQP) specifications since they support transactions.

WS-Transactions

WS-Transactions is a set of transactional interoperability specifications standardized by OASIS. It extends basic Web Services (i.e., SOAP and WSDL) by including a transaction context in a SOAP header and defining a protocol for transactional interoperability across Web Services. Both vendor and open source products implement it, including Microsoft’s Windows Communications Framework, IBM’s WebSphere Application Server, Red Hat’s JBoss Application Server, Progress Software’s Artix ESB, Sun’s Metro, and Apache’s Kandula2.

WS-Transactions includes three specifications:

• WS-Coordination (WS-C) is the core specification, defining a generic state machine coordinator that supports pluggable protocols for various transaction models, such as WS-AT and WS-BA.

• WS-AtomicTransactions (WS-AT) defines a durable and volatile variation of the classic two-phase commit protocol that plug into WS-C.

• WS-BusinessActivity (WS-BA) defines an “open nested” transaction protocol with compensation actions that plugs into WS-C. It can be used with long running transaction flows such as those defined using WS-BPEL.

An implementation of WS-C is a prerequisite for WS-AT and/or WS-BA. However, it is also possible to implement WS-C without implementing either WS-AT or WS-BA, for example by defining a new protocol to plug into WS-C, such as a notification, publish/subscribe, consensus, or three-phase commit protocol.

The WS-C specification defines how a Web Service implementation interacts with a transaction coordinator to obtain and manage the context for a given transaction type. The WS-AT and WS-BA specifications define specific context formats for WS-C to manage. The context is obtained from WS-C and passed from a Web Service requester to a Web Service provider using SOAP headers. A WS-Policy assertion can be attached to the Web Service’s WSDL interface to advertise its transactional requirements.

For example, in Figure 10.52 the .NET client obtains a WSDL interface from the Java EE application server that includes a policy requiring WS-AT. It therefore knows it has to start a transaction and obtain a WS-AT context for propagation to the remote service. The context is included in the header of the SOAP message that invokes the remote EJB server. When the service provider receives the SOAP header it recognizes the WS-AT context and registers the transaction with a WS-C coordinator—either a local coordinator that contacts the remote coordinator on its behalf, or directly with the remote coordinator.

Figure 10.52. The .NET Client Obtains a WSDL Interface Requiring WS-AT. The example illustrates a transactional Web Service invocation that coordinates Java EE and NET Framework resources.

Figure 10.53 shows an example of the context structure for WS-AT. It includes URIs that identify the coordination (i.e., context) type, the coordinator, and the address of the coordinator with which to register the context.

Figure 10.53. WS-Transactions Context for WS-Atomic Transactions. The context type for WS-AT is included in the SOAP header along with the URL for the coordinator.

Code View: Scroll / Show All <SOAP11:Envelope xmlns:S11="http://www./2003/05/soap-envelope"> <SOAP11:Header> ... <wscoor:CoordinationContext ... <wscoor:Identifier> uuid:1234567890 </wscoor:Identifier> ... <wscoor:CoordinationType> http://docs./ws-tx/wsat/2006/06 </wscoor:CoordinationType> <wscoor:RegistrationService> <wsa:Address> http://WWW.MyLargeBank.com/CoordinationService/registration </wsa:Address> </wscoor:RegistrationService> </SOAP11:Header> ... </SOAP11:Envelope>

The two-phase commit protocol includes volatile and durable variations. The open nested model defined in WS-BA allows a nested transaction to commit without requiring the top-level or root transaction to commit. However, if the top-level transaction aborts, a compensation action must be applied to any subtransaction that previously committed. WS-BA includes two variations: one for participant completion and the other for coordinator completion.

WS-Transactions uses the Web Services Policy (WS-Policy) Framework as the format for the policies it defines for association with a WSDL interface. In WS-Policy the policy items, called assertions, are used to advertise the transactional capabilities of a Web Service. For example, an assertion can tell the service requester whether or not a transaction context is required in order to invoke the service. Each WSDL operation can have its own policies.

For example, Figure 10.54 defines the transacted policy for the Transfer operation. It indicates that a transaction context, such as the WS-AT context, is required in order to request this service. If a SOAP message arrives for the Transfer operation without a transaction context an exception will be generated.

Figure 10.54. Policy Assertion Requiring a Transaction for the Transfer Operation. The Transfer operation has a reference to a wsp:Policy element that contains a wsat:ATAssertion indicating that a transaction context is required for this operation.

<wsdl:operation name="Transfer"> <wsp:PolicyReference URI-"#TransactedPolicy" wsdl:required="true" /> <!-- omitted elements --> </wsdl:operation> <wsp:Policy wsu:Id="TransactedPolicy" > <wsat:ATAssertion/> </wsp:Policy>

The XA Interface

The XA specification originally was developed by X/Open in 1991 as part of a family of specifications defining a complete distributed transaction processing environment. XA is supported by most relational database products, including Oracle, Sybase, IBM’s DB2, Microsoft’s SQL Server, and Sun’s MySQL. XA is also supported by most asynchronous message queuing products, including IBM’s WebSphere MQ, TIBCO Software’s Enterprise Message Service, Progress Software’s SonicMQ, and the Apache Foundation’s ActiveMQ.

X/Open was established to define portability and interoperability standards for UNIX. X/Open is now part of The Open Group, Inc., which was formed in 1994 by combining X/Open with the Open Software Foundation. X/Open’s original goal was to promote application portability through the development of API standards for UNIX. In fact, The Open Group owns the UNIX brand.

Although the complete family of X/Open specifications failed to gain adoption, the X/Open Distributed Transaction Processing (DTP) model remains a good framework for identifying both the components involved in a distributed transaction and the appropriate areas for standardization (see Figure 10.55). It divides a distributed TP system into three major components—transaction manager, resource manager, and application—and defines the interfaces between them.

Figure 10.55. X/Open DTP Model. In the X/Open DTP model an application program typically uses the TX API to access transaction management services and SQL to access a resource manager. The XA standard allows different vendors’ transactional middleware and resource managers to interoperate.

Within the X/Open DTP model, the XA specification defines a bidirectional interface between the transaction manager (TM) and the resource manager (RM). Today it’s common to think of the .NET Framework or Java EE defining the transaction demarcation API instead of the TX API. SQL is the most widely-used API for RM access, but there are others for access to queues and other nonrelational resources. XA is intended primarily for transactions that span multiple resource managers. For example, a common application of XA is to coordinate a transaction that includes a database and a message queue.

The XA specification defines the protocol to allow the transactional work of an RM to be externally coordinated by a TM in a distributed transaction. XA is a presumed-abort, two-phase commit protocol with optimizations that enable a TM to chose a one-phase commit when there is only a single RM involved in the transaction. When an application starts a transaction the TM creates a new transaction and assigns it a global transaction ID (which XA calls an XID). When the application calls the RM (for example, using an SQL statement), the runtime hosting the application passes the ID it obtained from the TM to the RM. The RM’s transaction manager recognizes the ID as coming from an independent TM (i.e., it’s not a transaction that the RM initiated) and enlists its transaction with the TM’s transaction using the address of the TM, which is passed as part of the transaction context. At termination, the TM notifies all registered participants of the transaction outcome.

Object Transaction Service

The Object Transaction Service (OTS) was defined in 1994 by the Object Management Group (OMG), an industry consortium. OMG was founded to develop the Common Object Request Broker Architecture (or CORBA) specifications and now is responsible for a variety of standards, including the well-known Unified Modeling Language (UML). OTS is one of the CORBA services that extend the core interfacing and interoperability technology for use in enterprise applications such as transaction processing.

OTS is incorporated into Java EE as the interoperable format for transaction context propagation on remote EJB requests. JTA provides the local Java interfaces in Java EE for TX and XA protocols. Implementations of CORBA and OTS include Progress Software’s Orbix, Borland Software’s VisiBroker, Oracle’s Tuxedo, HP’s NonStop Kernel, and Hitachi’s TP Broker. OTS often is mapped to Java Transaction Service (JTS) implementations. And the WS-Transactions approach is derived from the OMG’s Additional Structuring Mechanisms for the OTS Specification, which first included the concept of separating the coordinator from the transaction protocol.

The OTS model (as of V1.4) includes a transactional server and recoverable server, which correspond to the request controller and transaction server in our multitier model (see Figure 10.56).

Figure 10.56. Object Transaction Service Architecture. The ORB provides the communication among objects participating in an OTS transaction while the transaction service provides transaction coordination.

Objects in the transactional clients and servers communicate with each other using the ORB. They also access the transaction service to initiate and terminate a transaction and to register resources for a transaction. The transactional server does not directly interact with persistent resources, but calls one or more objects in the recoverable server to do so.

In XA terms, the transactional client, transactional server, and recoverable server comprise the application (AP) and the transaction service implements the transaction manager (TM). The RM is the same as in XA and, in fact, interacts with the TM using the XA protocol.

OTS supports both implicit and explicit programming models. The implicit programming model uses an object called current to associate a context with the execution thread. The begin command initializes the current context. Once a context is associated with the execution thread, it can be automatically propagated to any other transactional object invoked from that thread, depending on the transactional policy associated with the target object. The scope of a transaction is determined by the extent of the context sharing among objects, whether explicit or implicit.

The following properties can be associated with an object’s interoperable object reference (IOR) to define whether or not it will accept implicit context propagation:

• REQUIRES: A transaction context must be present when the object is invoked.

• FORBIDS: A transaction context must not be present when the object is invoked.

• ADAPTS: The object can be invoked whether or not a transaction context is present.

Properties cannot be set on individual methods in an object. A transactional object can perform both transactional and nontransactional work.

The explicit programming model uses the complete set of methods on the current object to explicitly start a transaction, get a context object, control the transaction through the methods on the object, and propagate the context to other transactional objects.

Transaction semantics in OTS are compatible with XA, and transactions can be exported and imported between the two environments. OTS supports subtransactions but they are not widely implemented in resource managers.

An OTS coordinator can become a resource to another coordinator. This is called interposition, in which a coordinator acts as a resource to the root coordinator. Interposition was designed for network efficiency. When multiple remote resources are included in the transaction, it’s more efficient for the root coordinator to exchange remote messages with an interposed coordinator than it would be with all the remote resources individually. The interposed coordinator receives messages from the root coordinator and passes them along to the local resources enrolled with it. An interposed coordinator can also reduce the number of sessions a given resource manager has to support, and can help enforce security for a given domain. This is essentially the tree-of-processes model discussed in Section 8.5.

JTA

The Java Transaction API (JTA) defines the Java interfaces for the TX and XA protocols. JTA originally was defined in 1999 and joins OTS and XA within a common Java programming environment. JTA is used in JCA, JDBC, and JMS, and is included in any Java-EE-compliant application server product. See Section 10.4, The Explicit Programming Model for additional examples.

JTA consists of three main parts:

• An interface that allows an application to explicitly initiate, propagate, and terminate a transaction

• A Java language mapping of the XA interface (XAResource)

• An interface between the TM and other application server components such as containers and cache managers to support enlistment of durable and volatile resources (XAResources and Synchronizations).

The javax.transaction.UserTransaction interface defines an explicit transaction programming model that can be used by Java clients and EJBs.

The javax.transaction.TransactionManager interface defines a programming model for the application server vendor to control transactions that use the implicit programming model. When an EJB container manages the transaction state for a transactional EJB, the container uses the TransactionManager interface to create, manage, and propagate a transaction context for a given thread of execution.

The javax.transaction.xa.XAResource interface is a Java mapping of the industry standard XA interface. As of JTA 1.1, the javax.transaction.TransactionSynchronizationRegistry interface defines a distinct set of operations for components such as persistence managers that typically would not have access to the full TransactionManager interface.

Service Component Architecture

The OASIS Service Component Architecture (SCA) defines a set of metadata for identifying services for an SOA, mapping them into a component model for deployment, and assembling them into various applications. SCA also includes a mechanism for attaching policies to the components and identifies a way in which Java programs can include SCA metadata as annotations.

Transactions are incorporated into SCA components using extended policy information incorporating the WS-Policy specification from W3C. For example, when deploying an SCA component or assembly of components into a Java EE runtime environment, the transaction policies attached to the SCA components are translated into Java EE transaction attributes. See the Section 10.4, The Implicit Programming Model, for information on Java EE transaction attributes. When SCA components are deployed onto other runtimes, the policies are mapped into WS-Policy elements as defined in the WS-TX set of specifications, described earlier in this section.

OSGi Alliance

The OSGi Alliance creates and maintains the OSGi specifications, which define a core framework for Java modularization and an associated set of framework services for discovery, security, logging, and so on. The OSGi Alliance was created as the Open Server Gateway initiative in 1998 based on Java Specification Request 8. Its original goal was to modularize Java for embedded devices, such as those intended for home automation, allowing the dynamic loading and unloading of selected sets of Java libraries needed to support the device’s resource constraints and capability requirements. OSGi technology had mixed early adoption in various embedded applications, including automotive and mobile telephone application.

Following the adoption of the OSGi platform by the Eclipse Foundation in 2004, the OSGi framework became popular as a deployment mechanism for Java-based products such as IBM’s WebSphere Application Server, Oracle’s WebLogic, Red Hat’s JBoss, Spring Source’s dm Server, and the Apache Foundation’s ServiceMix, among others.

The OSGi framework defines a dynamic component model for Java, and addresses other shortcomings of the standalone Java virtual machine environment, such as improved classloading, versioning, and lifecycle control. Applications can be defined as a set of cooperating components that can be remotely installed, started, stopped, updated, and uninstalled dynamically (i.e., without requiring application reboot). A service registry allows modules to detect the addition of new services or the removal of services, and to adapt dynamically, including the automatic installation of new components as required by the application.

The enterprise release of the OSGi specifications, R 4.2, extends the OSGi framework to meet the requirement of enterprise Java applications, including components for distributed computing, extensions to the component model itself (based on the Spring Framework’s component model), and a mapping of various Java EE components such as JTA, JDBC, JPA, JNDI, and Web applications. The Java EE and other enterprise components are accessible from application code using the OSGi service model. That means web applications, transaction, persistence abstractions, and other enterprise components are available as dynamically-loadable services for OSGi-compliant applications.

Advanced Message Queuing Protocol

The Advanced Message Queuing Protocol (AMQP) is an open standard originally defined by JP Morgan Chase and then submitted to an independent consortium, which maintains and improves it. AMQP focused initially on defining a wire format interoperability standard for asynchronous messaging systems, such as JMS-based message queues.

JMS defines a standard API for message queuing, but it does not define a data format. Among the goals of the AMQP Working Group is achieving interoperability across multiple asynchronous message queuing technologies and products. AMQP supports XA transactions for coordinating queue operations with operations on another resource. Current implementations include Red Hat’s Enterprise MRG, Apache Qpid, iMatix’s OpenAMQ, and Cohesive FT and LShift’s RabbitMQ.

Members of the AMQP Working Group consortium include Cisco Systems; Credit Suisse; Deutsche Borse Systems; Envoy Technologies; Goldman Sachs; iMatix Corporation; JP Morgan Chase Bank & Co.; Microsoft Corporation; Novell; Progress Software; Rabbit Technologies (a joint venture of CohesiveFT and LShift); Red Hat, Inc.; Twist Process Innovations; WSO2, Inc.; and 29West, Inc.