IBM WebSphere Optimized Local Adapters (OLA or WOLA) is a functional component of IBM's WebSphere Application Server for z/OS that provides an efficient cross-memory mechanism for calls both inbound to WAS z/OS and outbound from z/OS. Because it avoids the overhead of other communication mechanisms, it is capable of high volume exchange of messages. WOLA is an extension to the existing cross-memory exchange mechanism of WAS z/OS, with WOLA providing an external interface so z/OS address spaces outside the WAS z/OS server may participate in cross-memory exchanges. WOLA supports connectivity between a WAS z/OS server and one or more of the following: CICS, IMS, Batch, UNIX Systems Services and ALCS. WOLA was first made available in WAS z/OS Version 7, Fixpack 4 (7.0.0.4). Functional enhancements have appeared in subsequent fixpacks as documented in this article.
History
The WebSphere Optimized Local Adapters for WAS z/OS (WOLA or OLA for short) has its origins in a desire to provide an efficient inbound calling mechanism; that is, from outside the Java EE environment into it to exercise Java EE assets. This requirement was particularly pronounced on z/OS where traditional batch processing sought the use of a growing base of programming assets based on Java EE and EJB technology.
Other inbound solutions existed, for example: Messaging, such as Websphere MQ or other JMS providers. RMI/IIOP Web Services
While each had its respective strengths; each also had its particular shortcomings: overhead and latency; difficulty in construction; or deficiencies in the security or transaction propagation model.
This was the original design point for the Optimized Local Adapters. The architects of the solution extended the design to include bi-directional invocations: inbound to WAS z/OS from an external address space, and outbound from WAS to an external address space.
Technical Foundation
The architects of this solution chose to leverage an existing element of the WAS z/OS design called "local communications," a cross-memory mechanism used by WebSphere Application Server for z/OS since the V4.x days that optimized IIOP traffic between application servers on the same LPAR. OLA is essentially an externalization of that existing cross-memory mechanism so that address spaces outside WAS z/OS may connect and exchange messages across a shared memory space.
External address space programs access the OLA interface using a set of supplied APIs. Java programs running in WAS z/OS access the OLA interface through an implementation packaged as a standard JCA resource adapter.
Current Support
The currently supported external address spaces supported for WAS z/OS OLA are: IBM CICS Batch Jobs UNIX System Services (USS) Airline Control System (ALCS) IMS (support started with maintenance 7.0.0.12)
The programming languages supported in the external address spaces are: C/C++ COBOL High Level Assembler PL/I
Java is the programming language used to access WAS z/OS OLA from inside the Java EE containers of WAS z/OS.
Function Update History
IBM WebSphere Optimized Adapters function support has been updated as new versions or fixpacks are released. The function was first made available in WAS z/OS Version 7 Release 0 Fixpack 4 level (7.0.0.4).
7.0.0.4 WOLA was introduced with Fixpack 4 to the WAS z/OS Version 7 Release 0 product. Application of maintenance resulted in a new directory in the product file system that provided the WOLA modules, shared objects, JCA resource adapter and development class libraries. A shell script (olaInstall.sh) created the necessary UNIX symbolic links from the runtime environment to product install file system.
The functional supported offered in the 7.0.0.4 release was:
Support for CICS, Batch, USS, and ALCS One-phase commit for outbound WAS into CICS (2PC into CICS TS 4.1 provided with 7.0.0.12) Two-phase commit for inbound CICS into WAS Native APIs JCA resource adapter
7.0.0.12 Fixpack 12 to WAS z/OS Version 7 Release 0 provided two updates to the WOLA support:
Support for WOLA and IMS Two-phase commit transaction processing from WAS outbound to CICS TS 4.1
8.0.0.0 WebSphere Application Server for z/OS Version 8 Release 0 continued support for WebSphere Optimized Local Adapters. WOLA was shipped incorporated into the product, which meant running the olaInstall.sh was no longer required to create UNIX symbolic links to the product files. In addition the following function updates were provided:
Multi-segment large message support (greater than 32K in size) for work with IMS Support for inbound transaction classification of WOLA calls separate from IIOP calls Identification within the SMF 120.9 record for WOLA calls as WOLA rather than IIOP Resource failure identification and alternative JNDI failover
Resource Failover and Failback This function provides a means of detecting the loss of a data resource attached to a JCA connection factory and automatically failing over to a defined alternate JNDI. Detection of primary data resource recovery and failback is also an element of this functional design. The resource failover design is present in WebSphere Application Server Version 8 across all platforms for JDBC and JCA. WAS z/OS Version 8 provides support for WOLA resource failover as part of the general support for JCA resource failover. Invocation of the failover occurs when a configurable threshold number of () failures occur. After failover is invoked, all new () requests are routed to the alternate connection factory connection pool. Failback occurs when WAS z/OS determines the failed primary data resource has returned. New () requests are processed against the primary connection factory.
A common usage pattern for this function is outbound to CICS where the target CICS region is a routing region. This failover function provides the ability to architect multiple routing regions so that the loss of any single routing region does not affect the overall availability of CICS overall.
Several connection pool custom properties were added to support this resource failover and failback mechanism: failureThreshold - the number of consecutive () failures that must occur before automatic failover is invoked alternateResourceJNDIName - the JNDI name of the alternate connection factory to use if automatic failover is invoked resourceAvailabilityTestRetryInterval - the interval in seconds WAS employs to test for return of primary resource
Note: other connection pool custom properties exist for this function. Search on string "cdat_dsfailover" in the WAS z/OS InfoCenter for a complete listing.
8.0.0.1 / 8.5.0.0 Note: WAS z/OS 8.5.0.0 provides WOLA support functionally identical to 8.0.0.1
Fixpack 1 to WebSphere Application Server for z/OS Version 8 provided the following functional updates to WOLA:
64-bit callable native APIs for C/C++ programs operating in 64-bit mode SMF 120 subtype 10 records for WOLA outbound calls from WAS (SMF 120 subtype 9 captures inbound call information) Work Distribution - the ability to round-robin outbound calls across multiple external registrations of the same name Proxy support for remote access - this takes two forms: inbound and outbound
64-bit Callable Native API Modules Prior to 8.0.0.1 the native API modules were supplied in 31-bit callable format only. These modules had the four-character prefix BBOA* associated with each module name.
With 8.0.0.1 both 31-bit and 64-bit callable API modules are provided. The 31-bit modules retain the four-character prefix BBOA* for each module name. The 64-bit modules carry the four-character prefix BBGA* for each module name.
The number of APIs remains the same as before: 13 specific APIs. Usage is the same as before.
InfoCenter Search: cdat_olaapis
SMF 120.10 for WOLA Outbound Calls In WAS z/OS V7 the WOLA support for SMF was limited to inbound calls only. Inbound WOLA calls to target EJBs in the WAS z/OS container were identified as IIOP calls and captured by SMF as IIOP calls, indistinguishable from any other IIOP call. The normal WAS z/OS SMF 120 subtype 9 record (or 120.9 in shorthand notation) was used to capture the inbound call information.
With WAS z/OS 8.0.0.0 the SMF 120.9 record and capture function was modified to identify inbound WOLA calls separate from inbound IIOP calls.
With WAS z/OS 8.0.0.1 the SMF 120.10 record was created to capture information about outbound calls from WAS z/OS. The SMF 120.10 record has eight sections:
Platform neutral server information section z/OS server information section Outbound Request information section WOLA Outbound Request type specific section Outbound Request transaction context section Outbound Request security context section Outbound Request CICS context section OTMA Outbound Request type specific section
One record is created for each outbound request.
InfoCenter Search: rtrb_SMFsubtype10
Work Distribution This functional update provides the ability to distribute outbound calls across multiple external address spaces registered into a given WAS z/OS server using the same registration name. A common usage pattern for this would multiple CICS regions with the same stateless target program service deployed. A new environment variable was created to indicate the type of work distribution desired. The following illustrates the usage of this function:
InfoCenter Search: cdat_olacustprop
Proxy Support: Inbound and Outbound The cross-memory nature of WOLA communications implies the WAS z/OS server and the external address space must be on the same z/OS logical partition (LPAR). WAS z/OS 8.0.0.1 provides a proxy function to allow WOLA callers and WOLA targets to be located separately. This includes location on operating system instances other than z/OS. This function has two formats: proxy support for outbound calls, and proxy support for inbound calls.
Proxy Support for Outbound Calls This provides a mechanism by which Java applications may use the supplied WOLA JCA resource adapter to access a target address space on remote z/OS. An example usage pattern would be development or test of a proposed an application. Access to the cross-memory WOLA connection on the target z/OS system is provided by a supplied WOLA proxy application installed in a WAS z/OS server enabled for WOLA. The following picture illustrates the topology:
The network flow from the application to the WAS z/OS system is by way of IIOP. The WOLA connection factory is informed of this IIOP flow to the proxy by way of several new custom properties to the connection pool. The proxy application on WAS z/OS receives the call and forwards it over an actual cross-memory WOLA connection to the named target service.
This topology has limitations compared to outbound WOLA calls on the same z/OS LPAR: global transactions requiring two-phase commit can not be propagated across the IIOP connection to the WOLA proxy, and the user identity on the WAS thread can not be asserted into the target service on z/OS.
Proxy Support for Inbound Calls This provides a mechanism by which non-Java applications in an external address space may make inbound calls to a target WOLA-enabled EJB in a remote WAS instance, either on another z/OS LPAR or a distributed WAS platform. The same supplied WOLA proxy application installed in a local WAS z/OS instance is required to handle the initial cross-memory WOLA call and forward that to the named target EJB on the remote WAS instance. The following picture illustrates the topology: