Transaction Services with JTA and JTS

The Xid interface is an identifier for a distributed transaction specified in X/Open standard parlance. The standard X/Open format identifier, global transaction identifier bytes, and branch identifier bytes may all be retrieved from the Xid interface. Additionally, two static constants define characteristics of a transaction.

The XAResource interface is a Java mapping of the standard X/Open interface between a transaction manager and a resource manager. A resource manager's resource adapter must implement the XAResource interface to enable a resource to participate in a distributed transaction. A sample resource manager is a DBMS and a sample resource adapter is the JDBC interface to a DBMS. A transaction manager obtains an XAResource handle for every resource that participates in a distributed transaction.

The XAResource.start() method is used to associate a distributed transaction with a resource. In addition to the Xid, one of the XAResource static constant flags TMJOIN, TMRESUME, or TMNOFLAGS is used to, respectively, indicate whether the caller is joining an existing transaction, the caller is resuming a suspended transaction, or no flags are to be set. The XAResource.end() method is called to disassociate the resource from the transaction. In addition to an Xid, the end() call uses a flag TMSUSPEND, TMRESUME, TMFAIL, or TMSUCCESS to, respectively, indicate whether the transaction is suspended, is resumed, is to be rolled back, or is to be committed. The XAResource also provides methods to commit, prepare for a commit, rollback, recover, and forget about distributed transactions. The transaction timeout can also be set and retrieved from the XAResource.

Java Transaction Service

Figure 14.18 presents the system context
in which the JTS architecture operates. JTS (http://java.sun.com/products/jts/)
is a Java mapping of the OTS. Therefore, the JTS API is by and large defined
by the org.omg.CosTransactions and org.omg.CosTSPortability
packages. Java-based applications and Java-based application servers access
transaction management functionality via the JTA interfaces. The JTA interacts
with a transaction management implementation via JTS. Similarly, the JTS can
access resources via the JTA XA interfaces or can access OTS-enabled non-XA
resources. JTS implementations can interoperate via CORBA OTS interfaces. JTS
supports a flat transaction model. JTS can support, but is not required to support,
a nested transaction model.

There is no specified mechanism for an OTS-based transaction manager and an ORB to locate one another. The javax.jts.TransactionService interface is provided to facilitate a transaction manager and an ORB being able to locate one another, and is the only non-OTS standard interface defined by JTS.

The TransactionService.identifyORB() method is called by an ORB during initialization to let a transaction manager be aware of the ORB identity and attributes. The TSIdentification interface defined as an extension to the standard CORBA framework by the OTS is used by a JTS implementation to register Sender and Receiver objects with an ORB. Sender objects are registered with an ORB during initialization so that the ORB can issue a callback on the transaction service during the propagation of a transaction context from the transaction service. Receiver callback objects are also registered with the ORB to receive propagated transaction contexts. A Sender can also receive context propagation replies, and a Receiver can send propagation replies.

Web Services Transactions

In a Web services environment, many remote Web services communicate in a loosely coupled and widely distributed environment. Although use of OTS is the current recommended means by the J2EE standards for enhancing the interoperability of transaction context propagation, OTS and its dependence on IIOP are catered more for closely coupled albeit distributed environments. Furthermore, the strict adherence to ACID principles by mechanisms such as OTS do not map well to all Web service communication scenarios. Because of these reasons, a new set of standards needs to be crafted for the broader transaction interoperability needs of Web services.

The bad news is that at the time of this writing, there was no widely adopted standard means for incorporating transaction context into Web service communications. However, standards bodies such as the W3C and OASIS were working toward defining such a standard. Their aim is to ensure that the needs of Web services are met to enable loosely coupled transactional behavior as well as both strict and relaxed requirements for adhering to ACID principles. The good news is that there is a Java Specification Request (JSR) that is actively working on the incorporation of such standards into Java-based Web services when such standards become final.

The XML Transactioning API for Java (JAXTX), http://www.jcp.org/en/jsr/ detail?id=156, is being created to define a standard Java API for creating, parsing, and exchanging transactional information in a Web services communication paradigm. Thus, JAXTX largely focuses on defining how standard transaction context information can be read from and written to SOAP message headers. The JAXTX specification members are closely in tune with the W3C and OASIS standards bodies that are defining the general way for encapsulating transactional information inside of SOAP message headers. When such standard bodies converge on a solution, the intention is that JAXTX will incorporate such standards.

Additionally, another JSR called is being created and intended to be utilized by JAXTX to further broaden the scope for how transactions are managed in loosely coupled distributed environments. The J2EE Activity Service for Extended Transactions, http://jcp.org/en/jsr/detail?id=9, is being created to provide Java support for the OMG's Activity Service standard (http://cgi.omg.org/cgi-bin/doc?orbos/2000-06-19), which is an extension to the OTS. Such a standard and associated Java API will provide support for allowing long-running business transactions to be implemented more efficiently. That is, if a transaction spans a long amount of time and perhaps crosses multiple system boundaries, such as can be the case for Web services, then a more efficient means is needed to decompose the transaction into shorter running transactions. This is accomplished to prevent the locking up of all involved resources for the entire duration of the long-running transaction.

So stay tuned to the Web sites mentioned previously and keep an eye out for when a standard means for Web service transaction context propagation is defined and for when the Java APIs implementing such standards become available.

Conclusions

The need for transaction semantic support in distributed enterprise applications very frequently arises in the context of managing transactions that involve DBMS resources. There is a distinct and standard model for providing transaction service support to Java enterprise applications. The transaction services model available to Java enterprise applications revolves around the standard CORBA OTS and X/Open DTP models. The OTS is a CORBAservice for transactions, and the JTS is the Java mapping of this standard model. The JTA defines standard interfaces with the OTS/JTS, between applications and the transaction service, between transaction managers and application servers, and between transaction managers and X/Open XAcompliant resource managers. Finally, a set of standards and associated Java APIs are now brewing to enable interoperability in the Web services world.

Transaction services in Java are thus one of the J2EE components perhaps most in sync with other industry-standard transaction models. Because transaction services are one of the core components of a middle-ware architecture, many vendors will be able to better support the J2EE standard. Furthermore, interoperability with other DTP frameworks is better enabled. As you'll discover later in the book, interfacing with such transaction services is tremendously simplified for the application programmer when the J2EE declarative model for component transaction specification is used.

About the Authors

Paul J. Perrone is the Founder, President, and CTO at Assured Technologies, Inc. Through Assured Technologies (www.assuredtech.com), Paul provides software architecture and development consulting, mentoring, and training related to J2EE, XML, Web services, and object-oriented technologies. Paul has been involved with the architecture, design, and development of numerous large-scale enterprise systems and products for both Fortune 500 and medium-sized organizations. Paul also has co-authored Building Java Enterprise Systems with J2EE and the Java Security Handbook, has published articles on Java, and has spoken at conferences such as JavaOne and Web Services Edge. He has an MS from the University of Virginia and a BS from Rutgers University. He is a member of the IEEE and ACM, has served as chapter chair for the Northern Virginia IEEE Computer Society, has helped in the startup of the Northern Virginia Java User's Group (NOVAJUG), and chairs the NOVAJUG's enterprise SIG. Paul is also an avid Java-based robot and AI tinkerer. Paul can be reached at pperrone@assuredtech.com.

Venkata S. R. "Krishna" R. Chaganti is a senior software-engineering consultant and has been developing commercial applications software for the past 12 years. Krishna has cross-platform background in designing and developing Internet-based distributed systems across wide range of technologies, including DCE, CORBA, EJB, Web Services using Java and C/C++ programming languages. Krishna's experience also includes development of GUI based applications using Swing, JSP, Servlets, etc. Krishna has also been teaching and speaking Java and related technologies for five years. He has an MSEE in Computer Engineering and an MSEE in Electrical Engineering from the University of Alabama in Huntsville. He also has a B.Tech in Electronics and Communications Engineering from Nagarjuna University, A.P., India. Krishna can be reached at chaganti@erols.com.

Tom Schwenk is a Senior Software Consultant with Assured Technologies, Inc. Since 1995, he has been working with Java, specializing in highly scalable, distributed application design and development. He has been involved in the design and implementation of Java enterprise and e-commerce applications for both Fortune 500 and smaller size companies. He holds a BS in Electrical Engineering and an ME in Biomedical Engineering, both from the University of Virginia. Tom can be reached at tschwenk@assuredtech.com.

Source of this material

This material is from Chapter 14, Transaction Services with JTA and JTS , from the book J2EE Developer's Handbook (ISBN: 0-672-32348-6) written by Paul J. Perrone, Venkata S.R. "Krishna" R. Chaganti, and Tom Schwenk, published by Sams Publishing.