JCA Architecture and Scaleability

Introduction

Elastic COBOL transactions containing calls to IBM CICS services are packaged as Enterprise Java Beans (EJB) and execute under control of the Elastic Transaction Platform (ETP) within a JEE Application Server.  There are several ways to access these transactions,

• From other transactions running in the same EJB or "CICS region" with EXEC CICS LINK TRANSID ... service call
• From other transactions running in a different EJB on the same or different JEE server wtih EXEC CICS LINK TRANSID SYSID... service call
• From a Web browser connected to the BMS MAP transaction defined servlet name and sysID of the region
• From an HTTP client that references the (BMS or non-BMS) transaction through RESTful Web Services that include in the URL the servlet name, system ID, transaction ID and, optionally, input COMMAREA
• From a COBOL program running stand-alone or as a JCL batch job step running under the Elastic Batch Platform
• From a Java program running stand-alone or in another Java subsystem, and finally
• From a JEE Application using the Heirloom ETP JCA connector
• Equivalent to the IBM CICS Transaction Gateway (CTG) for Heirloom Elastic Transaction Platform.  In other words, programs that are written to use CTG today to access transaction on CICS can use this JCA to access the same transactions running under ETP.

Connecting through the ETP JCA connector is the subject of this article. Java EE applications often connect to other JEE applications using standard JEE mechanisms such as EJB client communications.  Java Communication Architecture was designed to connect to legacy enterprise systems that are not part of the Java infrastructure.  Typically, Oracle financial applications, Siebel applications, SAP applications and IBM mainframe CICS applications.  For the latter IBM has created the CICS Transaction Gateway JCA connector.  Since many Elastic COBOL programs and ETP transactions have been migrated from the mainframe it is sensible to invoke the ETP transactions in a similar way, through a JCA connection.  Heirloom JCA connector can be installed in JEE Application Servers such as IBM Websphere in the same manner as the IBM CICS Transaction Gateway and be invoked by those client Websphere applications.

Architecture

The Heirloom ETP JCA connector follows the JCA 1.5 Architecture Specification. 

Scaleability

JCA Connection Pooling

The Heirloom ETP JCA connector 1.0 connects 1-1 with an ETP system ID. Each JCA connection is defined to connect to a single ETP or "CICS Region." JCA connector pools can be defined within the Web service to achieve concurrency such that multiple transactions can be connected from multiple users running under the JEE application server.  The endpoint connection information is specified in the connection pool custom properties as hostname, portnumber and sysid.

JCA Clustering

The Heirloom ETP JCA connector 1.1 has the ability to scale across multiple ETP systems running on the same or multiple systems.  This is called a cluster of ETP systems.  This increases the transaction performance and high availability aspects of the overall system.  For most client applications to perform correctly the same transaction definitions and the resources they rely upon must be defined on all the ETP systems within a cluster.  Instead of a single ETP endpoint, multiple nodes are listed in the hostname setting within the connection pool custom properties.

The HCI JCA connector makes a determination as to which endpoint to use for each new connection that it sees.  It will choose an endpoint from the nodes listed.  Connections remain open by the client applications and all subsequent traffic for that connection is routed to the same endoint. 

One additional setting determines the type of clustering:

• Round Robin - New connections are assigned an endpoint in the order in which they were defined. If there are 3 endpoints in the HCI_POOL then user or connection 1 would be routed to endpoint 1, connection 2 routed to endpoint 2, connection 3 to endpoint 3, connection 4 to endpoint 1 and so on.
• Session Balanced - New connections are assigned an endpoint based on the number of connections that are currently active.  The node with the least number of connections will be chosen for the new connection.
• Performance Balanced - Network packet round-trip time is measured between the JCA and each endpoint and averaged over a period of time.  New connections are assigned to the endpoint with the fastest response time.

An endpoint that is unavailable is taken out of the pool until it returns to service.  The endpoint connection is tested every few new connections.

Round-Robin clustering mode is best for a pool of similar ETP systems.  Session Balanced is a good choice when nodes are being taken out-of-service (quiesced) and returned to service over time.  Performance Balanced is the best choice when the cluster is made of up nodes of different capacities (e.g., numbers of CPUs, memory speed, network connection speed, distributed network).

The ETP JCA connection does not implement transaction-replay on a surviving node when a node fails because the application must be responsible for controlling recovery.  Of course, standard transaction roll-back will occur when ETP or database nodes fail during a transaction.  Should the client recognize the failure (communication failure from the JCA connector) it can make a new connection request and the JCA connector will connect to a different node.  In this sense the end-user or end-application can be made appear to be failure-resistant.