ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

J2EE Transaction Frameworks: Building the Framework
Pages: 1, 2, 3, 4

Standards



The goal of transparency in a distributed TP environment demands interoperability between transaction managers and interoperability of TMs with resource managers. Currently, there are two open standards, namely, X/Open DTP Model & ISO TP Model. ISO TP protocol communicates between two distributed transaction managers possibly from different vendors in an open environment. ISO TP doesn't have many followers. On the other hand, X/Open Distributed Transaction Processing (DTP) is a distributed transaction-processing model proposed by the Open Group. This model is a standard among most of the commercial vendors providing transaction processing and relational database solutions. Some of the major elements of the model are

  • Application component that implements transactional operations.
  • Resource Managers that control resources.
  • Transaction Managers that coordinate with Resource Managers to make a global transaction happen.

The following are the major interfaces specified in the model:

  • TX Interface: This is the interface between the application and the transaction manager implemented within the transaction manager. It provides transaction demarcation services by allowing the application components to bind transactional operations within global transactions.
  • XA Interface: This defines the interface between resource managers and transaction manager. When both the transaction manager (or TP monitor) and resource managers of RDBMSs or EISs support the XA interface, they can be plugged together and transaction coordination can take place between them. This is the most important interface in the standard and has broad industry acceptance.

Diagram of the X/Open DTP standard
Figure 3. X/Open DTP standard

The X/Open DTP model is fairly well-established in the industry. Commercial transaction management products like TXSeries/Encina, Tuxedo, TopEnd, and AT&T GIS support the TX interface. Most of the commercial databases such as Oracle, Sybase, Informix and Microsoft SQL Server, and messaging middleware products like IBM's MQSeries and Microsoft's MSMQ Server, provide an implementation of the XA interface.

Some J2EE configurations

The Java 2 Enterprise Edition is a framework based on architecture. Support for transactions is a major element of the J2EE architecture. The component provider can use the Java Transaction API (JTA) to specify transaction boundaries in the component code. On the other hand, with declarative transaction specification support in enterprise beans, transactions are started and completed automatically by the container. The J2EE server implements the necessary low level transaction protocols between transaction manager and database systems supporting the JDBC API, including mechanisms for transaction context propagation and the optional distributed two-phase commit. The J2EE platform currently supports flat transactions that cannot have any nested transactions. It is possible to have a transactional application that uses a combination of servlets and JSP pages accessing multiple EJBs within a single transaction. Each component may acquire one or more connections to access one or more


Figure 4. Recommended J2EE configurations.

shared resource managers. It is important to emphasize that there are many different possibilities to choose from when it comes to architecting a solution for a specific application. However, out of all the possible configurations, only the following recommended ones are highlighted here.

  • Case I: Stand-alone Client <-> EJB Container <-> RDBMS/EIS Resources
    This configuration is the first step in the evolutionary migration from a two-tier client server system. In general there is a fat client probably written using Swing that communicates with the business logic residing in the EJBs in an EJB container of some application server.

  • Case II: Browser <-> Web Container <-> RDBMS/EIS Resources
    This configuration is popular in small scale web applications that are not supposed to serve an unpredictable number of users and is more appropriate for systems that reside within the intranet of an organization. This is suitable for applications where use of an application server is overkill.

  • Case III: Browser <-> Web Container <-> EJB Container <-> RDBMS/EIS Resources
    This configuration is the recommended full-blown architecture where the application has to be robust and scalable with a multitude of users demanding the maximum performance out of the system.

Dibyendu Baksi is a J2EE transactions systems and frameworks designer and developer for Sun Microsystems, Inc.


Return to ONJava.com.