Jump to content

WebSphere Optimized Local Adapters

Add links
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Kku (talk | contribs) at 22:59, 5 August 2010 (→Current Support: l). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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. It was first made available as part of the 7.0.0.4 maintenance release for WAS z/OS Version 7.

Because it avoids the overhead of other communication mechanisms, it is capable of high volume exchange of messages.

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:

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 propegation 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," an 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.

Components

The Optimized Local Adapters may be categorized into the following components:

  • Interface Modules -- provide the programmatic access to the OLA interface and the OLA APIs
  • CICS Task Related User Exit, Link Task Server and control transaction -- provides a simplified mechanism for supporting outbound calls to program assets in CICS.
  • JCA Resource Adapter -- provides the interface between the Java environment and the external environment
  • Development Tooling Support -- provides the supporting classes for developing OLA-enabled applications
  • Samples -- a set of C/C++, COBOL and Java samples that illustrate the use of the programming model

Programming Considerations

Inbound to WAS z/OS

The external address space access the OLA mechanism through the supplied interface modules and documented APIs. There are 13 APIs at the present time. They are categorized below.

Java programs running in the WAS z/OS environment wishing to be the target of an invocation from outside must implement the OLA interface in a stateless session bean using the OLA class files supplied in the development tooling support.

Outbound from WAS z/OS

A Java program wishing to initiate a OLA call outbound may be implemented as either a servlet or EJB. The Java program codes to the supplied JCA resource adapter (ola.rar) using the class files supplied in the development tooling support.

External address spaces that are the target of the outbound call must be in a state ready to accept the call. Two basic models exist:

  • If the external address space is CICS, then the user has the option to employ the supplied Link Server Task to act as the receiving agent on behalf of existing CICS program assets. The Link Server task (BBO$ by default) receives the call and issues an EXEC CICS LINK of the program named on interactionSpecImpl.setServiceName(). No changes to the existing CICS program is necessary provided it supports either COMMAREA or Channels/Containers.
  • If the external address is something other than CICS, then the program needs to "host a service" using one of the supplied APIs. That puts the program in a state ready to receive a call from the Java program in WAS z/OS. When the call is received it may then process the request and supply a response back to the Java program in WAS z/OS

Synchronous and Asycnhronous Operations

The APIs support both modes. Synchronous provides a simpler programming model because program control is not returned to the calling program until a response has been received. Asynchronous provides the architect with an opportunity process other work without having to wait on a response coming back from a long running target process.

Modular Design

It is possible to design the OLA-specific programming artifacts to serve as "bridges" between the OLA interace and existing assets. That serves to minimize impact to existing programming assets and limits the degree of "platform lock in."

  • Outbound to CICS—use the provided Link Server implementation; no changes to your CICS programs at all.
  • Inbound to WAS—construct an EJB that takes the OLA call, then turns and calls the specified EJB. If the target EJB is in the same JVM then it can be highly efficient. If the target EJB is in the same cell on the same LPAR then the previously mentioned "local communications" function is used.

APIs

There are 13 APIs, categoried into the following categories:

  • General Setup and Teardown -- BBOA1REG (register) and BBOA1URG (unregister)
  • Inbound Basic -- BBOA1INV (invoke with automatic get response)
  • Inbound Advanced -- BBOA1CNG (get connection), BBOA1SRQ (send request), BBOA1GET (get response), BBOA1RCL (get response length), BBOA1CNR (release connection)
  • Outbound Basic -- BBOA1SRV (host a service), BBOA1SRP (send response)
  • Outbound Advanced -- BBOA1RCA (receive on connection any), BBOA1RCS (receive on connection specific), and BBOA1SRX (send an exception)

The InfoCenter has a full write-up of each along with parameter lists and return code (RC) and reason codes (RSN). Search on cdat_olaapis.

Illustrations of Common API Patterns

A common inbound API usage model would be:

Simple

In this case the BBOA1REG API is used to register into the WebSphere Application Server for z/OS Daemon group (the cell short name), and multiple invocations of BBOA1INV are used to invoke the target EJB. BBOA1INV is synchronous so program control is held until the EJB returns a response. When the program determines it is done, it uses BBOA1URG to unregister from the Daemon group.

If the target Java program has a longer response interval then an asynchronous model is better. The following picture illustrates how that would be done using what is known as the primitive API: BBOA1SRQ with the async=1 parameter set:

As the picture illustrates, the asynchronous mode allows the non-Java program to get control and do other processing. That implies checking for a response at some future point. BBOA1RCL is used for that purpose. In this example BBOA1RCL is issued synchronously (parameter async=0). If a response is available BBOA1RCL will provide the length and program control returns to the program. If no response is available BBOA1RCL holds program control until one is available. BBOA1RCL with async=1 will return x'FFFFFFFF' if no response is available; program control is returned immediately.

Other illustrations for outbound may be found in the WP101490 document found on the IBM Techdocs website.

Note: Outbound from WAS to CICS would not require API coding. In that case the supplied BBO$/BBO# link server transactions would do that processing. Those link server transactions "host a service" using the internal constructs similar to the BBOA1SRV API. Outbound to a batch program would require the use of the APIs to "host a service."

Transactionality

The Optimized Local Adapters support two-phase commit (2PC) processing from CICS inbound to WAS.

They do not at present support two-phase commit outbound from WAS to CICS. That is due to a present limitation in the Task Related User Exit (TRUE) infrastructure of CICS on which the OLA implementation for CICS is built. At the present time only "sync on return" is supported.

Transactional propegation is not supported inbound or outbound to batch, USS or Airlines Line Control.

Security

The Optimized Local Adapters are capable of asserting identity in the following circumstances:

  • WAS --> CICS : The identity on the WAS thread used to call the WOLA API will be used to assert identity into CICS.
  • WAS --> Batch, USS or ALCS : no attempt to assert identity is made. The target process runs under the identity used when it was started.
  • CICS --> WAS : CICS can assert its region ID or the application user ID
  • Batch, USS or ALCS : The external process will attempt to assert its identity into WAS z/OS.

Limitations

The WAS z/OS Optimized Local Adapters can be used only within a given LPAR. It is a cross-memory mechanism and can not go between LPARs or off the machine.


Retrieved from "https://en.wikipedia.org/w/index.php?title=WebSphere_Optimized_Local_Adapters&oldid=377385642"