WebSphere Optimized Local Adapters


IBM WebSphere Optimized Local Adapters 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. Functional enhancements have appeared in subsequent fixpacks as documented in this article.

History

The WebSphere Optimized Local Adapters for WAS z/OS 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:
The programming languages supported in the external address spaces are:
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

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

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 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
  • 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:
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 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
  • 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 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. 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.