Using Java EE Connector architecture

Introduction

The CICS application has the same meaning as the service quality of the transaction; Integrating these applications with mainstream Java components is a common challenge for many enterprises today. You can use the Java Connector Architecture (JCA) and CICS Transaction Gateway to provide CICS applications and Java EE components deployed in WebSphere application Server Transaction integration.

To show you how to implement this integration, we'll start with an overview of the basic transaction concepts, and then describe the transactional environment in the following software: IBM WebSphere application Server, CICS Transaction server for z/os™ ( CICS TS) and CICS Transaction Gateway (CICS TG), which includes CICS TG V6.1 for new XA two phase commit support for z/OS. We will analyze the transaction control of the Servlet and EJB components in the WebSphere application server in detail, and explain how to use these controls to provide the applications deployed in the WebSphere Application server and CICS Different levels of transactional integration between.

The target audience for this article is the application designers and architects who need to understand the nature of the transactions that are used with JCA and CICS. This article assumes that you understand the basics of CICS and JCA.

What is a business?

In the Java-EE world, transactions are active units, which, within the active cell, take multiple updates of recoverable resources as atomic (or, more precisely, an indivisible unit of work) so that either all updates are made or none are updated. However, in the CICS world, a transaction is a work done by a CICS program (or a series of programs) that is invoked by a particular transaction identifier (Transaction-identifier) and runs under a specific CICS task. The CICS task itself consists of several recoverable units of work (also known as logical units of work), which are differentiated by synchronization points. These work units are some recoverable atomic units, so they are similar to the world of Java-EE transactions.

Basic components

In a transactional environment, all participants are divided into resource managers or transaction managers. The resource Manager is responsible for managing recoverable data, such as files or queues. The transaction manager is responsible for the transaction response and coordinates the results of the transaction among multiple resource managers. Between them, the transaction manager and the resource manager are responsible for reliably coordinating updates to recoverable resources in order to maintain transaction rules such as atomicity, consistency, isolation, and persistence. To achieve this goal, it is necessary to implement a common architectural standard for each participant. In the following sections, we will briefly describe the following criteria and protocols:

Java EE Connector Architecture (JCA)

Two-stage commit.

JCA is part of the Java Standard and specifies the system contract implemented by the resource adapter. These system contracts define the quality of service provided by the resource adapter for transaction management, connection management, and security (Figure 1).

Figure 1. JCA System Contract

In the Java EE architecture, distributed transactions are called global transactions, and systems that manage recoverable resources are called resource managers, with the examples of CICS, ims™, and db2®. These resource managers are based on the transaction classifications they support, either to support two-stage collaboration (by providing a XAResource interface), to support only one-phase collaboration (through the Localtransaction interface), or to be non-transaction managers.

For transaction management, the resource adapter needs to implement one of the following contracts, which is defined in the deployment descriptor for the resource adapter (ra.xml file):

XA transactions-A resource adapter that can fully participate in the two-phase commit process, which can affect the outcome of the global transaction.

localtransaction--can participate in the resource adapter for the local transaction of the resource Manager (the CICS region in our example), but the resource adapter does not have any two-phase commit transaction functionality. For clarity, in this article (as well as in other WebSphere-related publications and papers), we use the term Explorer local transaction (RMLT) to represent a transaction that is local to a single resource manager.

notransaction--refers to a resource adapter that has no transaction attributes; It can participate in the transaction context but is not affected by the outcome of the transaction (nor does it affect the outcome of the transaction).

The WebSphere application Server transaction supports collaboration for any number of resource managers with two-phase functionality (XA transactions) in a transaction. It also allows a single-phase (local transaction) resource Manager to be used without any other resource managers in the transaction.