This post is part of a series exploring the unique aspects and capabilities of WebSphere Liberty when running on z/OS.
We'll also explore considerations when moving from WebSphere traditional on z/OS to Liberty on z/OS.

The next post in the series is here.

To start at the beginning, follow this link to the first post.

---------------

This is yet another thing carried over from WebSphere traditional.  WOLA, or WebSphere Optimized Local Adapters is known in Liberty as the zosLocalAdapters feature.  That’s because the Liberty rules say we can’t use a non-industry standard acronym (i.e. WOLA) in a feature name. 

WOLA has been described in detail elsewhere as part of the WAS traditional function and is largely the same in Liberty.  In short, WOLA provides a way for applications to communicate cross-memory between a WebSphere server and a non-WebSphere server address space co-located on the same z/OS image.  The non-WebSphere address space can ‘be’ something else, like CICS, or it can just be a ‘regular old address space’, like a JES initiator running a COBOL batch program.

WOLA is bi-directional so you can initiate the communication from either side.  Being WebSphere-centric we tend to think of WOLA communication originating outside of WAS as being ‘inbound’ and WOLA communication that is initiated from inside of WAS going to something else as being ‘outbound’. 

When going outbound from WAS to CICS or IMS there are certainly other ways to do that, some of which work even when the target is on another z/OS image.  And if you are running your Liberty inside of CICS then you should just use JCICS to drive CICS transactions.  But there are instances where WOLA might be faster or more efficient.  And if your target is something else (a home-grown server written in C perhaps) then WOLA can be a good way to have WebSphere act as a ‘front end’ for your server accepting REST requests or messages and in-turn driving work into your server in a quick, efficient manner that doesn’t require your C server to deal with encryption etc.  There’s no reason to encrypt anything because it isn’t going anywhere (just direct between one address space and another).

Inbound to WAS is another common model.  Here you have some non-WebSphere thing and you want to drive work into WAS.  Sometimes this is because the non-WAS thing isn’t in Java and you want to get ‘into’ Java without starting your own JVM.  WOLA provides a handy way to do that without having to get tangled up (again) in encryption/authentication issues of a REST request.  WOLA will simply lift the identity of the client and carry it into WAS to be used as the identity to dispatch the request.  That is done using authorized code so it is safe and secure. 

There are certainly other ways to do this, and z/OS has introduced capabilities to make going back and forth between COBOL and Java in the same address space easier.  But WOLA is still worth a look, if for nothing else than its ability to run requests asynchronously and in a multi-threaded environment (one single-threaded COBOL program can launch multiple concurrent WOLA requests dispatched into WAS at the same time).

I should mention that some of the capabilities of WOLA in WAS traditional are not present in WAS Liberty at the moment.  Most notable is the transaction propagation feature.  But that said, the programming model (the APIs) are all exactly the same, so a COBOL program using WOLA to communicate with WAS traditional can run unchanged to communicate with WAS Liberty, for example.  You just need to define a 3-part name for the Liberty server (traditional just used the cell/node/server name).