[z/OS]

Optimized local adapters for z/OS usage scenarios

Optimized local adapters and the supporting native API callable services provide an alternative path for enterprise architecture and application development on the z/OS® platform.

Using optimized local adapters provides existing business and middleware applications that are written in native languages like Cobol, PL/I, C/C+, and high-level assembler, and running under environments such as z/OS batch, Customer Information Control System (CICS®), Information Management System (IMS), and UNIX System Services (USS), an alternative way to call Java™ applications that are implemented as Enterprise JavaBeans (EJB) applications on WebSphere® Application Server for z/OS.

Optimized local adapters support is also provided for calling from applications that are running on WebSphere Application Server to an external server program running locally or on the same logical partition (LPAR), using the Java EE Connect Architecture (JCA) programming model Version 1.5. The target external server programs might be business or middleware applications that are developed using Cobol, PL/I, C/C+, or high-level assembly languages.

A scenario where the optimized local adapters can provide increased performance is CICS or IMS support for the use of server and client Web services. The targeted backend applications can call business logic that is located elsewhere in a more efficient manner when using the optimized local adapters instead of XML and SOAP messaging technology. Web services is a scenario where you can improve efficiency by using optimized local adapters. The following hypothetical real-world scenarios describe how the optimized local adapters are useful in various business goals.

Financial services company scenario

An IBM® z/OS financial services customer that is running business applications under CICS must decide about purchasing a financial processing application, which provides new support for stock trade real-time reporting to the exchanges. The ability to do this style of real-time reporting can result in increasing revenue for the customer.

The application that does real-time reporting is developed as a Java Enterprise Edition (Java EE)-based application and deployed on WebSphere Application Server on a Windows XP platform. The application offers a set of enterprise beans and associated Web services interfaces that can be called for various kinds of interactions.

A test scenario is developed and successfully implemented to call the Java EE application from a CICS Cobol program. Therefore, the customer decides to move forward and do more rigorous testing. Further testing shows that when this mechanism is pressed by more than 50-100 requests per second, it begins to slow to the point where the response times do not meet the customer requirements. The effort is abandoned until a more realistic approach is available for exchanging information in real time between the CICS business application and the new vendor application.

The optimized local adapters can provide this CICS customer with an option to deploy WebSphere Application Server for z/OS and update the CICS application to use the optimized local adapters Invoke or Send Request API. These APIs provide a way to call EJB applications that are deployed on a local WebSphere Application Server for z/OS server, which calls the business logic for the Web service.

Insurance company scenario

An IBM z/OS insurance industry customer that is running a business application under CICS wants to provide customers with the ability to retrieve and update policy information in real time. This information must be gathered in various ways and from several places, including:
  • Information directly gathered from DB2®
  • Information gathered by calling a program in CICS
  • Information gathered by starting a Web service to communicate with a remote service provided by another company

The customer chooses to use a Java application for several reasons, but most importantly because most of their programming skills are Java-based. When the new application is tested, the customer experiences long response times when retrieving information. The slow response time is a result of WebSphere Application Server running on a distributed server and the latency involved with communicating remotely with DB2 while calling CICS using Web services and SOAP messages.

To fix the problem, the customer deploys multiple WebSphere Application Server in the same configuration to reduce the number of requests per second on any one of the servers and to spread the requests across separate network paths.

Using optimized local adapters gives the customer an alternative other than deploying multiple servers. The customer could install WebSphere Application Server for z/OS and install the new application on a server on z/OS, closer to the DB2 and CICS environments. For the calls to CICS from WebSphere Application Server, using the optimized local adapters APIs provides a significant boost over the Web services and SOAP solution. Consolidating like this on z/OS platforms reduces the need for more distributed servers that consume floor space, power, and resources to maintain. In this scenario, since the location of the data and applications is the gating factor, increasing the size of the remote server to the most robust one available does not necessarily solve the problem.

Migrating business logic to WebSphere Application Server for z/OS

A customer has years of application logic with Cobol running inside of CICS. They want to migrate some of these applications to WebSphere Application Server to take advantage of Java and Java EE technologies, and use other capabilities in the WebSphere stack.

One of the applications is too large to migrate in one piece, and they would like to gradually move portions of it to WebSphere Application Server. The transactional and security qualities of service provided by CICS must be maintained during the transition, and the performance impact of the transition must be minimal. Using optimized local adapters, portions of the application can be migrated to WebSphere Application Server and wrapped in a stateless session bean. The application logic written in Cobol can be modified to use the optimized local adapter to call the stateless session beans. These calls to WebSphere Application Server run under the same transaction and security contexts used by the Cobol programs running in the CICS region. There is a significant performance gain when compared to making similar calls using a Web service. The customer can continue to relocate portions of the application to WebSphere Application Server until the application is migrated.