Historically,standardization has been very challenging for TP technologies, due tothe broad variety of implementation architectures, programming models,communications protocols, and integration points among modern andlegacy 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
Wewill focus primarily on standards pertinent to the .NET Framework andJava EE transactional middleware and touch only briefly on otherrelated standardization efforts. The primary standard for transactionalinteroperability is defined by the Web Services transactions set ofspecifications. 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
Theselast three standards are related. The XA protocol is incorporated intoOTS, and both XA and OTS are incorporated into JTA. The XA protocol isperhaps the most successful TP standard. Most transactional resourcemanagers support it for two-phase commit, including relational databasesystems and asynchronous message queues.
Wealso briefly mention the emerging Service Component Architecture (SCA),OSGi enterprise edition, and Advanced Message Queuing Protocol (AMQP)specifications since they support transactions.
WS-Transactionsis a set of transactional interoperability specifications standardizedby OASIS. It extends basic Web Services (i.e., SOAP and WSDL) byincluding a transaction context in a SOAP header and defining aprotocol for transactional interoperability across Web Services. Bothvendor and open source products implement it, including Microsoft’sWindows 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.
Animplementation of WS-C is a prerequisite for WS-AT and/or WS-BA.However, it is also possible to implement WS-C without implementingeither WS-AT or WS-BA, for example by defining a new protocol to pluginto WS-C, such as a notification, publish/subscribe, consensus, orthree-phase commit protocol.
TheWS-C specification defines how a Web Service implementation interactswith a transaction coordinator to obtain and manage the context for agiven transaction type. The WS-AT and WS-BA specifications definespecific context formats for WS-C to manage. The context is obtainedfrom WS-C and passed from a Web Service requester to a Web Serviceprovider using SOAP headers. A WS-Policy assertion can be attached tothe Web Service’s WSDL interface to advertise its transactionalrequirements.
For example, in Figure 10.52the .NET client obtains a WSDL interface from the Java EE applicationserver that includes a policy requiring WS-AT. It therefore knows ithas to start a transaction and obtain a WS-AT context for propagationto the remote service. The context is included in the header of theSOAP message that invokes the remote EJB server. When the serviceprovider receives the SOAP header it recognizes the WS-AT context andregisters the transaction with a WS-C coordinator—either a localcoordinator that contacts the remote coordinator on its behalf, ordirectly with the remote coordinator.
Figure 10.53shows an example of the context structure for WS-AT. It includes URIsthat identify the coordination (i.e., context) type, the coordinator,and the address of the coordinator with which to register the context.
| Code View: Scroll / Show All <SOAP11:Envelope xmlns:S11="http://www.w3.org/2003/05/soap-envelope"> |
Thetwo-phase commit protocol includes volatile and durable variations. Theopen nested model defined in WS-BA allows a nested transaction tocommit without requiring the top-level or root transaction to commit.However, if the top-level transaction aborts, a compensation actionmust be applied to any subtransaction that previously committed. WS-BAincludes two variations: one for participant completion and the otherfor coordinator completion.
WS-Transactionsuses the Web Services Policy (WS-Policy) Framework as the format forthe policies it defines for association with a WSDL interface. InWS-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 nota transaction context is required in order to invoke the service. EachWSDL operation can have its own policies.
For example, Figure 10.54 defines the transacted policy for theTransferoperation. It indicates that a transaction context, such as the WS-ATcontext, is required in order to request this service. If a SOAPmessage arrives for theTransfer operation without a transaction context an exception will be generated.
<wsdl:operation name="Transfer"> |
TheXA specification originally was developed by X/Open in 1991 as part ofa family of specifications defining a complete distributed transactionprocessing environment. XA is supported by most relational databaseproducts, including Oracle, Sybase, IBM’s DB2, Microsoft’s SQL Server,and Sun’s MySQL. XA is also supported by most asynchronous messagequeuing products, including IBM’s WebSphere MQ, TIBCO Software’sEnterprise Message Service, Progress Software’s SonicMQ, and the ApacheFoundation’s ActiveMQ.
X/Openwas established to define portability and interoperability standardsfor UNIX. X/Open is now part of The Open Group, Inc., which was formedin 1994 by combining X/Open with the Open Software Foundation. X/Open’soriginal goal was to promote application portability through thedevelopment of API standards for UNIX. In fact, The Open Group owns theUNIX brand.
Althoughthe complete family of X/Open specifications failed to gain adoption,the X/Open Distributed Transaction Processing (DTP) model remains agood framework for identifying both the components involved in adistributed transaction and the appropriate areas for standardization(see Figure 10.55).It divides a distributed TP system into three majorcomponents—transaction manager, resource manager, and application—anddefines the interfaces between them.
Withinthe X/Open DTP model, the XA specification defines a bidirectionalinterface between the transaction manager (TM) and the resource manager(RM). Today it’s common to think of the .NET Framework or Java EEdefining the transaction demarcation API instead of the TX API. SQL isthe most widely-used API for RM access, but there are others for accessto queues and other nonrelational resources. XA is intended primarilyfor transactions that span multiple resource managers. For example, acommon application of XA is to coordinate a transaction that includes adatabase and a message queue.
TheXA specification defines the protocol to allow the transactional workof an RM to be externally coordinated by a TM in a distributedtransaction. XA is a presumed-abort, two-phase commit protocol withoptimizations that enable a TM to chose a one-phase commit when thereis only a single RM involved in the transaction. When an applicationstarts a transaction the TM creates a new transaction and assigns it aglobal transaction ID (which XA calls an XID).When the application calls the RM (for example, using an SQLstatement), the runtime hosting the application passes the ID itobtained from the TM to the RM. The RM’s transaction manager recognizesthe ID as coming from an independent TM (i.e., it’s not a transactionthat the RM initiated)and enlists its transaction with the TM’s transaction using the addressof the TM, which is passed as part of the transaction context. Attermination, the TM notifies all registered participants of thetransaction outcome.
TheObject Transaction Service (OTS) was defined in 1994 by the ObjectManagement Group (OMG), an industry consortium. OMG was founded todevelop 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 ofthe CORBA services that extend the core interfacing andinteroperability technology for use in enterprise applications such astransaction processing.
OTSis incorporated into Java EE as the interoperable format fortransaction context propagation on remote EJB requests. JTA providesthe 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 TransactionService (JTS) implementations. And the WS-Transactions approach isderived from the OMG’s Additional Structuring Mechanisms for the OTS Specification, which first included the concept of separating the coordinator from the transaction protocol.
TheOTS model (as of V1.4) includes a transactional server and recoverableserver, which correspond to the request controller and transactionserver in our multitier model (see Figure 10.56).
Objectsin the transactional clients and servers communicate with each otherusing the ORB. They also access the transaction service to initiate andterminate a transaction and to register resources for a transaction.The transactional server does not directly interact with persistentresources, but calls one or more objects in the recoverable server todo so.
In XAterms, the transactional client, transactional server, and recoverableserver comprise the application (AP) and the transaction serviceimplements the transaction manager (TM). The RM is the same as in XAand, 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. Thebegin command initializes the current context. Once a context is associated with the execution thread, itcan be automatically propagated to any other transactional objectinvoked from that thread, depending on the transactional policyassociated with the target object. The scope of a transaction is determined by the extent of the context sharing among objects, whether explicit or implicit.
Thefollowing properties can be associated with an object’s interoperableobject reference (IOR) to define whether or not it will accept implicitcontext 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.
Propertiescannot be set on individual methods in an object. A transactionalobject can perform both transactional and nontransactional work.
Theexplicit programming model uses the complete set of methods on thecurrent object to explicitly start a transaction, get a context object,control the transaction through the methods on the object, andpropagate the context to other transactional objects.
Transactionsemantics in OTS are compatible with XA, and transactions can beexported and imported between the two environments. OTS supportssubtransactions but they are not widely implemented in resourcemanagers.
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 remoteresources are included in the transaction, it’s more efficient for theroot coordinator to exchange remote messages with an interposedcoordinator than it would be with all the remote resourcesindividually. The interposed coordinator receives messages from theroot coordinator and passes them along to the local resources enrolledwith it. An interposed coordinator can also reduce the number ofsessions a given resource manager has to support, and can help enforcesecurity for a given domain. This is essentially the tree-of-processesmodel discussed in Section 8.5.
TheJava Transaction API (JTA) defines the Java interfaces for the TX andXA protocols. JTA originally was defined in 1999 and joins OTS and XAwithin 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).
Thejavax.transaction.UserTransaction interface defines an explicit transaction programming model that can be used by Java clients and EJBs.
Thejavax.transaction.TransactionManagerinterface defines a programming model for the application server vendorto control transactions that use the implicit programming model. Whenan EJB container manages the transaction state for a transactional EJB,the container uses theTransactionManager interface to create, manage, and propagate a transaction context for a given thread of execution.
Thejavax.transaction.xa.XAResource interface is a Java mapping of the industry standard XA interface. As of JTA 1.1, thejavax.transaction.TransactionSynchronizationRegistryinterface defines a distinct set of operations for components such aspersistence managers that typically would not have access to the fullTransactionManager interface.
TheOASIS Service Component Architecture (SCA) defines a set of metadatafor identifying services for an SOA, mapping them into a componentmodel for deployment, and assembling them into various applications.SCA also includes a mechanism for attaching policies to the componentsand identifies a way in which Java programs can include SCA metadata asannotations.
Transactionsare incorporated into SCA components using extended policy informationincorporating the WS-Policy specification from W3C. For example, whendeploying an SCA component or assembly of components into a Java EEruntime environment, the transaction policies attached to the SCAcomponents 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 componentsare deployed onto other runtimes, the policies are mapped intoWS-Policy elements as defined in the WS-TX set of specifications,described earlier in this section.
TheOSGi Alliance creates and maintains the OSGi specifications, whichdefine a core framework for Java modularization and an associated setof framework services for discovery, security, logging, and so on. TheOSGi Alliance was created as the Open Server Gateway initiative in 1998based on Java Specification Request 8. Its original goal was tomodularize Java for embedded devices, such as those intended for homeautomation, allowing the dynamic loading and unloading of selected setsof Java libraries needed to support the device’s resource constraintsand capability requirements. OSGi technology had mixed early adoptionin various embedded applications, including automotive and mobiletelephone application.
Followingthe adoption of the OSGi platform by the Eclipse Foundation in 2004,the OSGi framework became popular as a deployment mechanism forJava-based products such as IBM’s WebSphere Application Server,Oracle’s WebLogic, Red Hat’s JBoss, Spring Source’s dm Server, and theApache Foundation’s ServiceMix, among others.
TheOSGi framework defines a dynamic component model for Java, andaddresses other shortcomings of the standalone Java virtual machineenvironment, such as improved classloading, versioning, and lifecyclecontrol. Applications can be defined as a set of cooperating componentsthat can be remotely installed, started, stopped, updated, anduninstalled dynamically (i.e., without requiring application reboot). Aservice registry allows modules to detect the addition of new servicesor the removal of services, and to adapt dynamically, including theautomatic installation of new components as required by the application.
Theenterprise release of the OSGi specifications, R 4.2, extends the OSGiframework to meet the requirement of enterprise Java applications,including components for distributed computing, extensions to thecomponent model itself (based on the Spring Framework’s componentmodel), and a mapping of various Java EE components such as JTA, JDBC,JPA, JNDI, and Web applications. The Java EE and other enterprisecomponents are accessible from application code using the OSGi servicemodel. That means web applications, transaction, persistenceabstractions, and other enterprise components are available asdynamically-loadable services for OSGi-compliant applications.
TheAdvanced Message Queuing Protocol (AMQP) is an open standard originallydefined by JP Morgan Chase and then submitted to an independentconsortium, which maintains and improves it. AMQP focused initially ondefining a wire format interoperability standard for asynchronousmessaging systems, such as JMS-based message queues.
JMSdefines a standard API for message queuing, but it does not define adata format. Among the goals of the AMQP Working Group is achievinginteroperability across multiple asynchronous message queuingtechnologies and products. AMQP supports XA transactions forcoordinating 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.
Membersof the AMQP Working Group consortium include Cisco Systems; CreditSuisse; Deutsche Borse Systems; Envoy Technologies; Goldman Sachs;iMatix Corporation; JP Morgan Chase Bank & Co.; MicrosoftCorporation; Novell; Progress Software; Rabbit Technologies (a jointventure of CohesiveFT and LShift); Red Hat, Inc.; Twist ProcessInnovations; WSO2, Inc.; and 29West, Inc.
联系客服
