6.6 Emerging Integration Technology

6.6.1 Java Connector Architecture

Java Connector Architecture (JCA) provides a standard architecture for connecting to Enterprise Information Systems such as mainframe legacy systems and Enterprise Resource Planning systems. Figure 6-2 shows a high-level architecture. Java Connector provides a Resource Adapter that enables J2EE application components to connect to Enterprise Information Systems (EIS) or legacy mainframe systems. Any J2EE application component needs to establish application contracts with the Resource Adapter. The Resource Adapter provides Common Client Interface (CCI) to connect the EIS. When an established system contracts with the J2EE application server and the application contracts with the J2EE application components , the Resource Adapter can ensure reliable data connectivity and messaging with the EIS. The Java Connector Architecture has been maturing since J2EE 1.3.

Figure 6-2. Java Connector Architecture Overview

A server-side SOAP component (SOAP tier or skeleton) can initiate service requests to the EIS via the relevant J2EE application component, which will create a connection with the EIS via the Resource Adapter. The Resource Adapter will also handle connection pooling and session failover. The business transaction result will be returned in a SOAP message to the SOAP client via the SOAP server. The JCA design can support both synchronous and asynchronous Web Services.

We also see growing numbers of commercial implementations , such as CICS and SAP. JCA 2.0 adds the features of asynchronous resource adapters (for example, supporting inbound and outbound directions for complex integration scenarios), Java Message Service API provider pluggability (that is, treating JMS API as a resource adapter), XML support in CCI (for example, JAXP and JAXB support), and CCI meta-data support (for example, providing meta information such as input and output record types). This has significantly enriched the legacy system integration.

The core component in JCA is the Resource Adapter. It provides connectivity to the Enterprise Information Systems where the client (J2EE application components) uses a Common Client Interface (CCI) to invoke enterprise system functionality or to retrieve customer information (using Enterprise Information System's input and output record types). The key benefits of the JCA Resource Adapter are to address previous integration issues of scalability, asynchronous communication between the client and Enterprise Information Systems, pluggability with a standard J2EE container, and transactions and security integration issues. One major implication is that the JCA Resource Adapter provides a "system contract" with the J2EE application server and an "application contract" with the J2EE application components. The contract denotes connection management, transaction management, and security management (refer to the next section on "Resource Adapter Architecture"). This allows a better quality of service and transaction integrity.

Resource Adapter Architecture

One key benefit of the Resource Adapter is the system contract between the J2EE application server and the Resource Adapter, which provides reliable connection management, transaction management, and security management. Figure 6-3 depicts the connection management process taking place in the Resource Adapter. The boxes denote the Java class objects (such as ConnectionFactory and ConnectionManager ) that need to be used for connection management. Figure 6-4 depicts the transaction management processes, where the TXManager object manages the business transactions using the LocalTransaction class as per the system contracts in the XAResource object.

Figure 6-3. JCA Connection Management

Figure 6-4. JCA Transaction Management

Common Client Interface

Figure 6-5 shows how Common Client Interface is being created for a legacy Enterprise Information System (CICS application). The ConnectionManager object initializes the connection, specifies the user id and password for security, sets the remote application id (in this case, CICS transaction id), and invokes the remote functionality. The InteractionSpec object denotes the remote CICS transaction id. The result is then returned at the end in the ResultSet object.

Figure 6-5. JCA Common Client Interface

Figure 6-6 shows a program excerpt using CCI to place an FX trade order by connecting to the back-end EIS. It invokes the remote CICS transaction "PHALL" by specifying the InteractionSpec object and initiating the method "execute" (as in ix.execute(ispec, custRec, resultRec) ). The transaction result is returned in the ResultSet object (as in resultRec ).

Figure 6-6 Sample CCI Program Excerpt

[View full width]

 import com.ibm.connector2.cics.*; import javax.naming.Context; import javax.resource.cci.*; ... public int placeFXTradeOrder(int accountNumber,String fxCode,int amount, String  homeCurrency, date valueDate) {  ECIConnectionSpec cspec =  new ECIConnectionSpec("myUserID", "myPassword");  //  ID and password for CICS sign-on //  Get a connection to CICS Context nc = new InitialContext(); ECIConnectionFactory cf  = (ECIConnectionFactory)nc.lookup( "java:comp/env/eis/ECIConnectionFactory");  // Java naming context lookup Connection cx = cf.getConnection(cspec); // Prepare for interaction CICS via ECI ECIInteractionSpec ixSpec = new ECIInteractionSpec();  ixSpec.setFunctionName("PHALL");  // PHALL is a CICS transaction id for processing FX  trade order ixSpec.setInteractionVerb(InteractionSpec.SYNC_SEND_RECEIVE); // Prepare records - custom records implement javax.resource.cci.Record CustomerInfoRecord custRec = new CustomerInfoRecord();  // Input ResultInfoRecord resultRec = new ResultInfoRecord();    // Result // specify any parameters for the CICS transaction function if necessary ... // Execute the remote CICS transaction  Interaction  ix = cx.createInteraction();   ix.execute(ispec, custRec, resultRec);  // Close the connection cx.close(); // Retrieve results from the result record int fxTradeStatus = resultRec.placeFXTradeOrder(); return fxTradeStatus; } 

Figure 6-7 shows a client proxy that the Java client needs to invoke. The service end-point "fxPlaceOrder" from the SOAP Router will invoke the method placeFXTradeOrder, which may be an EJB, Java bean, or a legacy system function from the legacy mainframe applications. The return code of the call is placed in the resp variable.

Figure 6-7 Sample Client Proxy for the FX Web Services Call

[View full width]

 import java.io.*; import javax.xml.soap.*; import javax.xml.messaging.*; import java.net.URL; import java.rmi.RemoteException; import java.util.*; ... public class fxTradingClientProxy {   private Call call = new Call();   private URL url = null;   private String SOAPActionURI = "";   private SOAPMappingRegistry smr = call.getSOAPMappingRegistry();   public fxTradingClientProxythrows MalformedURLException   {     call.setTargetObjectURI("urn:fxPlaceOrder");     call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC);     this.url = new URL("http://localhost:8080/test/servlet/rpcrouter");     this.SOAPActionURI = "urn:fxPlaceOrder";   }   // Customize here for your business services   public synchronized int  placeFXTradeOrder(int accountNumber,String fxCode,int amount, String homeCurrency,  date valueDate) throws Exception  {     if(url == null)     {      throw new SOAPException(Constants.FAULT_CODE_CLIENT,       "URL must be specified via " + "fxTradingClientProxy.setEndPoint(URL).");     }     call.setMethodName(  "placeFXTradeOrder"  ); call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC);     ...     // invoke Java Web services via SOAP here  Response resp = call.invoke(url, SOAPActionURI);  //Check the result     if (resp.generatedFault())     {       Fault fault = resp.getFault();       throw new SOAPException(fault.getFaultCode(), fault.getFaultString());     }     else     {       Parameter refValue = resp.getReturnValue();       return (refValue.getValue());     }   } } 

The Java client invoking the Web Services may look like this (see Figure 6-8):

Figure 6-8 Sample Java Client Invoking the FX Web Services Call

[View full width]

 import java.io.*; import java.net.URL; ... // Create an instance of the Java Web services client proxy fxTradingClientProxy myFxTradingWebServices = new fxTradingClientProxy(); // Invoke the Java Web Services method int fxTradeStatus =  myFxTradingWebServices.placeFXTradeOrder(accountNumber,fxCode,amount, homeCurrency,  valueDate);  

Commercial Implementation of Resource Adapter

With the growing implementation of J2EE-based technology, there are increasing numbers of commercial implementations of Resource Adapter for legacy mainframe systems and Enterprise Resource Planning. Figures 6-9 and 6-10 depict the Resource Adapter implementation for CICS and SAP R/3, respectively.

Figure 6-9. CICS Resource Adapter

Figure 6-10. SAP R/3 Resource Adapter

Figure 6-9 shows the components of a CICS Resource Adapter, which consists of an ECI Resource Adapter, an EPI Resource Adapter, and an ESI Resource Adapter. These adapters accommodate all types of CICS communication calls (that is, ECI, EPI, and ESI calls), depending on how the client invokes the back-end CICS transactions. The data result is placed in the common area COMMAREA. The CICS Resource Adapter currently comes with the CICS Transaction Gateway software package.

Figure 6-10 depicts the components of an SAP Resource Adapter. The back-end SAP resources and business functionality are currently accessible by a proprietary RFC library (RFC Lib). The SAP Resource Adapter provides an abstraction layer called JCo (Java Connector) to invoke RFC lib calls.

Wakelin et al. (2002, pp. 17 “32) have a detailed elaboration of the Java Connector for CICS. Juric and colleagues (2001) have a good summary of the SAP R/3 Resource Adapter with some code examples.

6.6.2 ebXML Business Process Management

Business Process Management is a key element in enterprise and cross-enterprise integration. It entails unified process automation and workflow models. It requires a direct model execution and manipulation. It should also support state management, time-based exception handling, robust process monitoring and analysis, nested model support, and concurrent model support. Architecturally, systems supporting Business Process Management should be highly reliable, highly available, and scalable. They should be also Open Standards compliant.

ebXML Web Services technology provides a good integration option to managing business processes. Please refer to Chapter 3, Web Services Technology Overview, for a brief description of ebXML. An example of Business Process Management using ebXML Web Services technology is Progress eXcelon's Business Process Manager (BPM). BPM is designed to support B2Bi using ebXML's Business Process Management. BPM has three key components: Process Flow Engine (business rules encapsulating event process flow and collaboration rules in CPP documents), Integration Framework (a set of adapters and listeners that connects system components and supports SOAP-JMS, as well), and Business Document Repository (a Service Registry and a directory of XML documents).

Figure 6-11 illustrates how BPM can be used to implement a Straight-through Processing presettlement matching solution using ebXML Web Services technology. Fund managers and traders initiate a trade order with the Business Process Manager (that is, BPM's Process Flow Engine). The Business Process Manager administers a series of business rules regarding how a trade order should be validated and processed. It then exchanges trade order information between the Portfolio Management System, the Trade Order Management System, and the Risk Management System from multiple parties via the Enterprise Service Interface (that is, BPM's Integration Framework). There will be a series of workflow events to be triggered and processed . The trade order documents are stored in XML within the BPM's Document Repository.

Figure 6-11. Using Progress eXcelon's Business Process Manager for Straight-through Processing (Courtesy of Progress eXcelon)

Web Services technology can be used as a better alternative to automate and exchange trade order information (such as order initiation, order, notice of execution [NOE], and matching trades) between different trading partners . The underlying messaging infrastructure adopts ebXML Message Service, which provides a reliable messaging for business transactions. In case of any system failure in the applications at the fund manager, trader , broker/ dealer , or custodian level, ebXML messaging is able to resend the business documents once it resumes operations. This is critical to the Straight-through Processing for capital market customers.

Upon a successful trade order execution, the Business Process Manager will initiate presettlement matching. This will require many interfaces between Broker/Dealer, the Virtual Matching Utility (or VMU; for example, GSTPA or Omgeo), and Custodian. The Business Process Manager will resolve any settlement exceptions based on the business rules defined in the Process Flow Engine.

6.6.3 SOAP-JMS Integration

Although Java Message Service (JMS) is a messaging standard for middleware products, developers cannot exchange data from one JMS to another because JMS depends on the underlying physical data transport. For example, data objects encapsulated by TIBCO JMS implementation will not be able to be exchanged with an IBM MQ JMS implementation. This is particularly significant for cross-enterprise integration when both trading partners claim to support JMS but technically cannot exchange data using a JMS implementation.

The alternatives include using a proprietary middleware bridge (such as TIBCO's TIB2MQ) and a JMS bridge. The JMS bridge is a generic term for integrating JMS together using a XML cache solution (for example, Progress eXcelon's XIS) or implementing a SOAP-JMS bridge to utilize SOAP messaging over different JMS implementations.

The SOAP-JMS bridge simply refers to extending the SOAPTransport class to customize a SOAP-to-JMS Transport class that can create a JMS queue session, create a queue message from the SOAP header, and extract and decode the SOAP message. Ahmed Kal and his colleagues have a working example in Professional Java XML (2001, pp. 831 “861).

6.6.4 Integrating Different Data Sources

Without XML support in the database, architects and developers need to write JDBC calls to encapsulate business data objects and extract and transform them into XML messages. They probably end up writing lengthy entity beans and complex data handling methods . The alternative may be using legacy database warehousing techniques to extract data into a data mart for processing. However, this will require off-line processing for data extraction, transformation, and database loading.

Major database vendors have now added SQL-to-XML mapping and native XML format storage support to their database technology. For example, developers can use an add-on utility (such as XML extender or servlet) to extract a relational database and transform into XML messages from DB2 or Oracle 8i. This has eased accessing and updating data from a real-time Web Services calls and reduced the development effort considerably.

Several XML- related database initiatives such as XQL (SQL-like XML query language) and DADX Web Services (Mapping SQL to DTD or XML Schema) are evolving. XQL is designed to be used as a query language in XML syntax. This reduces the development effort to parse relational database data results to XML and vice versa. Details of XQL can be referenced at http://www.w3.org/TandS/QL/QL98/pp/flab.txt and http://www. ibiblio .org/xql/xql-tutorial.html . DADX is a proprietary implementation to combine a SOAP service request with SQL calls. It is currently generated and managed from WebSphere Application Developer and can only work with DB2. Details of DADX Web Services can be referenced at http://www7b.software.ibm.com/dmdd/library/techarticle/0212yu/0212yu.html?t=gr,lnxw07=DB2-NET-WS . Some of these technologies are implemented with proprietary databases. Reed (2002) and Haggarty (2002) have some good examples of SQL queries rendering XML SQL queries and transforming them into XML messages.