WebSphere Liberty Profile 9 for z/OS: Java EE 7 on the Big Iron - up to 141 Processors and 10 TB of Memory

Abstract

In the article, I wish to tell you how to implement all Java EE 7 capabilities on the Big Iron, IBM Mainframes and WebSphere Liberty Profile work together providing up to 141 5 GHz processors an 10 TB of the main memory for your Java EE based applications.

• WebSphere Liberty Profile for z/OS installation
  
  
• Using JCL procedures to start WLP on z/OS
  
  
• Enabling z/OS authorized services on Liberty for z/OS
  
  
• Using the JDBC Type 2 driver
  
  
• JMS 2.0 and IBM MQ BINDINGS
  
  
• Accessing z/OS security resources from Java EE applications
  
  
• Java thread identity to z/OS and DB2 threads identity propagation
  
  
• Native z/OS workload management (WLM) services for your applications
  
  
• Java EE 7
  
  
• Summary

WebSphere Liberty Profile for z/OS installation

There are a few of simple steps, which are totally enough to become familiar with WebSphere Liberty Profile 9 for z/OS:

1. Download WAS Liberty for z/OS Beta by clicking Download on the WAS Dev website, today the July 2016 version is in account.
   
   
2. Run the following command in OMVS:
   
   cat wlp-beta-zos-2016.7.0.0.pax | pax -r -ppx
   
   
3. Create the server running the following command inside the wlp/bin sub-directory:
   
   server create demoServer
   

A server instance has been created after successful execution of the command. By default, there isn't the host="*" attribute for the httpEndpoint tag in the server configuration file - server.xml. The attribute should be added and the server will be accessible from any client machines.

The server tasks can be used to start or stop a server. The wlp/bin directory contains a script that is called server to help with controlling the server process. The syntax of this script is as follows:

server start demoServer

But if the server is started using the script, the z/OS advantages aren't available for the server, so the server wont be able to leverage System Authorization Facility (SAF) for authentication/authorization as well as JDBC Type 2 and RRS to make connections to the database and manage transactions, WLM for workload dispatching and the killer feature of WebSphere Application Server for z/OS, WebSphere z/OS Optimized Local Adapters (WOLA) make connections to CICS and IMS without touching any heavyweight protocols like SOAP. So, JCL procedures do matter to be used for starting.

Using JCL procedures to start WLP on z/OS

For the WebSphere Liberty Profile runtime environment on z/OS, there are two types of process: the server process and the angel process.

The server process is a Java virtual machine (JVM) running the Liberty code in much the same way as it does on any other operating system. You can start the server process either from the MVS operator console by using the angel process or from the shell.

The angel process runs in an authorized key and provides facilities to the server process to load and access system services in a way that protects the integrity of the operating system. You start the angel process from the MVS console by using a procedure. The angel does not need any configuration and exists independently of the server. All Liberty servers that are running on a z/OS image can share a single angel, regardless of the level of code that the servers are running.

Use the MODIFY command to give a list of all the servers that are using the angel process.

MODIFY [jobname.]identifier,display,servers

No angel process has to run in a z/OS image if no authorized services are enabled for any server on the system.

Two JCL procedure templates are available in the wlp/templates/zos/procs directory. The bbgzsrv template for Liberty has to be copied into the PROCLIB library:

cp wlp/templates/zos/procs/bbgzsrv.jcl "//'WASPRF.PROCLIB(WLPZSRV)'"

The bbgzangl template for the angel process also has to be copied to the same library:

cp wlp/templates/zos/procs/bbgzangl.jcl "//'WASPRF.PROCLIB(WLPZANGL)'"

The Liberty template must be customized: the INSTDIR parameter, which contains the path to the WebSphere Liberty installation, and the USERDIR parameter, which contains the path to the WebSphere Liberty user area. The following dataset definitions should be taken into account: DD WLPUDIR, which contains a PATH DD that points to Liberty's "user" directory. If the DD is not allocated, the user directory location defaults to the wlp/usr directory in the install tree. And the DD STDENV points to the file or dataset of the environment, i.e. JAVA_HOME.

//STDENV DD PATH='&INSTDIR./etc/system.env',PATHOPTS=(ORDONLY)

Only the ROOT parameter must be changed on the actual value, the path to the WebSphere Liberty installation in the template for the angel process.

More information about the JCL procedures could be found on the Administering Liberty on z/OS page.

Two z/OS users, for example WLPSERV for Liberty and WLPANGL for the angel process, have to be created and stored in the RACF (or any other security product) database. Administrator has to associate these user IDs with the corresponding JCL procedures.

ADDGROUP WLPGROUP OMVS(GID(2667))

ADDUSER WLPSERV DFLTGRP(WLPGROUP) OMVS(UID(2778) HOME(/u/wlpserv) 
    PROGRAM(/bin/sh)) NAME('WLP USER') NOPASSWORD NOOIDCARD

ADDUSER WLPANGL DFLTGRP(WLPGROUP) OMVS(UID(2779) HOME(/u/wlpangl) 
    PROGRAM(/bin/sh)) NAME('WLP ANGEL USER') NOPASSWORD NOOIDCARD

RDEFINE STARTED WLPZSRV.* STDATA(USER(WLPSERV) GROUP(WLPGROUP) TRACE(YES))
RDEFINE STARTED WLPZANGL.* STDATA(USER(WLPANGL) GROUP(WLPGROUP) TRACE(YES))
SETROPTS RACLIST(STARTED) GENERIC(STARTED) REFRESH

After the changes are committed, the servers can be started using the following MVS commands.

The angel process:

/s wlpzangl

The Liberty server:

/s wlpzsrv,parms='demoServer'

Enabling z/OS authorized services on Liberty for z/OS

WebSphere Liberty on z/OS offers the ability for your applications to take advantage of z/OS authorized services for System Authorization Facility (SAF) authorization, Workload Manager (WLM), Resource Recovery services (RRS), and SVCDUMP. If an application requires these services, set up a Liberty angel process and grant access for your Liberty server to use these services. To use the authorized services, the following types of profiles by using a SAF security product such as RACF can be set up.

RDEFINE SERVER BBG.ANGEL UACC(NONE)
PERMIT BBG.ANGEL CLASS(SERVER) ACCESS(READ) ID(<serverUserId>)
SETROPTS RACLIST(SERVER) GENERIC(SERVER) REFRESH

The following action enables a Liberty server to use the z/OS authorized services.

RDEFINE SERVER BBG.AUTHMOD.BBGZSAFM UACC(NONE)
PERMIT BBG.AUTHMOD.BBGZSAFM CLASS(SERVER) ACCESS(READ) ID(<serverUserId>)
SETROPTS RACLIST(SERVER) GENERIC(SERVER) REFRESH

Using the JDBC Type 2 driver

For z/OS it's usual to execute an application server and a database in the same image of the operating system. The application server makes connections to the database using the JDBC Type 2 driver. The driver leverages the native for the operating system libraries and touches the database using the cross-memory services, just a few of assembler instructions. This way relieves the application server from any TCP/IP and the loop-back interface related pitfalls as well as from the overhead from a usual (like in Linux/Unix) IPC stack.

Resource recovery services (RRS) provides a set of services that implement the two-phase commit protocol, and this set is used to apply coordinated changes across multiple mission-critical resources on the z/OS platform. To enable the RRS transaction services (TXRRS) for the user associated with the started task for Liberty, the following RACF commands should be issued.

RDEFINE SERVER BBG.AUTHMOD.BBGZSAFM.TXRRS UACC(NONE)
PERMIT BBG.AUTHMOD.BBGZSAFM.TXRRS CLASS(SERVER) ACCESS(READ) ID(<serverUserId>)
SETROPTS RACLIST(SERVER) GENERIC(SERVER) REFRESH

The following server.xml fragment describes the driver configuration:

<?xml version="1.0" encoding="UTF-8" ?>
<server description="JDBC Type 2 DataSource definition">
    <featureManager>
        <feature>jdbc-4.1</feature>
        <feature>zosTransaction-1.0</feature>
    </featureManager>

    <nativeTransactionManager shutdownTimeout="20s" 
                              resourceManagerNamePrefix="DEMOS"/>

    <library id="DB2T2LibRef">
        <fileset dir="/usr/lpp/db2b10/jdbc/classes"/>
        <fileset dir="/usr/lpp/db2b10/jdbc/lib"/>
    </library>

    <jdbcDriver id="DB2T2" libraryRef="DB2T2LibRef"/>

    <dataSource id="jdbc/test" jndiName="jdbc/test" jdbcDriverRef="DB2T2" 
                type="javax.sql.ConnectionPoolDataSource">
        <connectionManager maxPoolSize="10" minPoolSize="0" connectionTimeout="10s" />
        <properties.db2.jcc driverType="2" databaseName="DB0A" />
    </dataSource>
</server>

There are a number of the important configuration elements.

The jdbc-4.1 feature provides basic interfaces from the JDBC 4.1 (a part of Java EE 7) specification and the zosTransaction-1.0 feature exploits RRS, this component is mandatory while JDBC Type 2 is used.

The nativeTransactionManager configuration element controls (1) the time to wait for transactions actively by using native contexts to complete when the server is stopped or the zosTransaction-1.0 feature is no longer needed. This can be done by using his shutdownTimeout attribute. Also the element helps (2) a system administrator to restrict user authority for performing any transactional work that involves RRS capable resources, for example DB2 JDBC Type 2, on a particular server. This can be done by using his resourceManagerNamePrefix attribute, which specifies a 1-8 alphanumeric (A-Z, a-z, 0-9) and national (@,#,$) only character prefix to be used as part of the server generated resource manager name that is registered with RRS. The prefix "DEFAULT" is a reserved prefix that identifies a default server configuration and should not be used for securing server access. If the configured prefix does not follow the name, length, and character requirements, the DEFAULT prefix name is used. The prefix is intended for system administrators to enable only authorized users to perform transactional work (normal and recovery) involving RRS capable resources. System administrators must define a BBG.RMNAME.<PREFIX>.RRS resource under the SERVER class, and give the required users READ authority.

RDEFINE SERVER BBG.RMNAME.DEMOS.RRS UACC(NONE)
PERMIT BBG.RMNAME.DEMOS.RRS CLASS(SERVER) ACCESS(READ) ID(<serverUserId>)
SETROPTS RACLIST(SERVER) GENERIC(SERVER) REFRESH

The library configuration element specifies the path to the DB2 for z/OS JDBC drivers. Because the JDBC Type 2 driver is taken into account, the native libraries must be added to the resource's <library> configuration element.

The jdbcDriver configuration element specifies the driver and references on the defined above library element.

The dataSource configuration element specifies an available from deployed applications datasource. The element can include a child element named properties.db2.jcc. Attributes that are supplied in the properties.db2.jcc element are passed directly to the DB2 JCC Driver. The driverType attribute is required and must be set to 2. The databaseName attribute is also required. The ssid attribute is not required, but can be used to control which DB2 for z/OS subsystem this data source connects to if there are multiple DB2 subsystems on the LPAR.

JMS 2.0 and IBM MQ BINDINGS

There are two transport types that supported by IBM MQ: CLIENT means a TCP/IP connection between a queue manager and a client, and BINDINGS means no any remoting between a queue manager and a client, so a client must be running on the same LPAR as the queue manager the client is connected to.

The following server.xml fragment describes the BINDINGS configuration:

<?xml version="1.0" encoding="UTF-8" ?>
<server description="JMS MQ configuration">
    <featureManager>
        <feature>wmqJmsClient-2.0</feature>
        <feature>jndi-1.0</feature>
    </featureManager>

    <variable name="wmqJmsClient.rar.location"
              value="/u/pavel/java/wlp/lib/mq/wmq.jmsra.rar"/>

    <wmqJmsClient nativeLibraryPath="/usr/lpp/mq/java/lib"/>    

    <jmsConnectionFactory jndiName="jms/mqzos-connection-factory">
        <properties.wmqJms transportType="BINDINGS" 
                           queueManager="QMSP"/>

        <connectionManager maxPoolSize="10"/>
    </jmsConnectionFactory>

    <jmsQueue id="CICSQueue" jndiName="jms/cicsqueue">
        <properties.wmqJms baseQueueName="CICS01.INITQ"
                           baseQueueManagerName="QMSP"/>
    </jmsQueue>

    <jmsActivationSpec id="sync-to-os-thread-demo-1.0-SNAPSHOT/MessageListenerActivationSpec">
        <properties.wmqJms
            destinationRef="CICSQueue"
            transportType="BINDINGS"
            queueManager="QMSP"/>
    </jmsActivationSpec>
</server>

There are a number of the important configuration elements.

The wmqJmsClient-2.0 feature enables MQ leveraging while the jndi-1.0 one starts up a JNDI registry, which is able to contain defined connection factories, queues, and activation specification. The ejbLite-3.2 and jmsMdb-3.2 features are necessary to meet any Message-Driven Beans (MDB).

The JCA 1.7 adapter wmqJmsClient.rar is exploited to establish communication with IBM MQ. The JMS 2.0 compatible version (8.x) of the adapter is available on IBM FixCentral.

The wmqJmsClient configuration element specifies the path to the IBM MQ client native libraries, which are necessary for taking the BINDINGS transport type.

The jmsConnectionFactory configuration element describes a connection factory. The factory is registered in the JNDI registry by the assigned name. There are two child elements, the first one named properties.wmqJms specifies a used transport type as well as a queue manager for the factory, the second one named connectionManager is a definition for the connection pool properties, in the above example, an up to 10 concurrent connections pool is defined.

The jmsQueue configuration element describes a message queue. The queue is registered in the JNDI registry by the assigned name. There is a child element specifies an MQ queue and a queue manager are available for deployed applications.

The jmsActivationSpec configuration element describes an activation specification, which is necessary for deployed message-driven beans (MDBs). The value of the id attribute must match the corresponding component name, in this example this name is a concatenation of a WAR-module full name and the component name specified as a value of the name parameter in the @MessageDriven annotation.

Accessing z/OS security resources from Java EE applications

The System authorization facility (SAF) provides a system interface that conditionally directs control to the Resource Access Control Facility (RACF), if RACF is present, and/or a user-supplied processing routine when receiving a request from a resource manager. Another external security product may be substituted for RACF. SAF does not require any other program product as a prerequisite, but overall system security functions are greatly enhanced and complemented by the concurrent use of an external security product.

WebSphere Liberty Profile is able to leverage SAF for authentication and authorization. If the server is configured for SAF using, the Java thread identity to z/OS and DB2 threads identity propagation becomes available for the server. How does it look like? A user is submitting a logon form and is being authenticated in the application server instance, so, user's credentials are being propagated to the DB2 subsystem, and if an SQL query is executed in the subsystem, the query is executed with the permissions granted for the user that authenticated on the WebSphere Liberty server. Also, a started from the application server working in the operating system, for example, a JOB submit, will be executed under the same user ID.

To enable the SAF authorized user registry services and SAF authorization services for a Liberty server, the following RACF commands should be issued.

RDEFINE SERVER BBG.AUTHMOD.BBGZSAFM.SAFCRED UACC(NONE)
PERMIT BBG.AUTHMOD.BBGZSAFM.SAFCRED CLASS(SERVER) ACCESS(READ) ID(<serverUserId>)
SETROPTS RACLIST(SERVER) GENERIC(SERVER) REFRESH

For application security these two features have to be enables in the server.xml file: appSecurity-2.0 and zosSecurity-1.0.

Authentication

Configure the SAF registry by adding a safRegistry element in the server.xml file:

<safRegistry id="saf" realm="myrealm" />

The attributes of the safRegistry element are detailed described on the Activating and configuring the SAF registry on z/OS.

The server authenticates users to a particular SAF domain that is configured by defining a resource, which is referred to as the APPLID in the APPL class. In order to authenticate a user to the domain, the user must have READ access to the APPLID resource in the APPL class. In addition, whenever the APPL class is active, the unauthenticated user ID (which is WSGUEST by default) also requires READ access to the APPLID resource in the APPL class.

The APPLID resource name used by the server is specified by the profilePrefix attribute in the safCredentials configuration element. If you do not specify this element, then the default profilePrefix of BBGZDFLT is used.

<safCredentials profilePrefix="CBS390"/>

The following example shows how to use RACF commands to configure the APPLID as CBS390 (so, the definitions carried out for WAS Traditional still control the security):

// Define CBS390 APPLID in RACF.
RDEFINE APPL CBS390 UACC(NONE)

// Activate the APPL class
// If not active, the domain is not restricted , which means anyone can authenticate to it 
SETROPTS CLASSACT(APPL)

// All users to be authenticated by the server must have READ access to the APPLID in the APPL class:
PERMIT CBS390 CLASS(APPL) ACCESS(READ) ID(<serverUserId>)

// The unauthenticated user ID requires READ access to the APPLID in the APPL class:
PERMIT CBS390 CLASS(APPL) ACCESS(READ) ID(WSGUEST)

SETROPTS RACLIST(APPL) REFRESH

In addition, the server must be granted some permissions to make authentication calls in the given APPLID domain. This prevents an unauthorized user from leveraging the server's use of authorized SAF services to discover information about which APPLIDs can and cannot be authenticated. To grant the server permission to authenticate in a particular APPLID domain, the started task ID of the Liberty server must be granted READ access to the BBG.SECPFX.<APPLID> profile in the SERVER class:

RDEFINE SERVER BBG.SECPFX.CBS390 UACC(NONE)
PERMIT BBG.SECPFX.CBS390 CLASS(SERVER) ACCESS(READ) ID(<serverUserId>)
SETROPTS RACLIST(SERVER) GENERIC(SERVER) REFRESH

Authorization

It is very important! For SAF-authorization, the server.xml configuration file must contain the following configuration element:

<safAuthorization id="saf"/>

The server authorizes a subject against a Java EE application security role name by checking whether the subject is authorized to a SAF resource profile defined in the EJBROLE class. The SAF resource profile name is mapped from the application role name via the SAF role mapper. The SAF role mapper generates a SAF profile name for a given application role name and application resource name. By default, it generates the SAF profile name using the pattern {profilePrefix}.{resource}.{role}. For example:

profilePrefix="BBGZDFLT"

Application resource name = "MYAPP"

Application role name = "ADMIN"

Mapped profile name = "BBGZDFLT.MYAPP.ADMIN", and an authenticated user has to have READ access to the BBGZDFLT.MYAPP.ADMIN resource in the EJBROLE class.

The server isn't allowed to perform authorization against each SAF profile in the EJBROLE class. This prevents an unauthorized user from leveraging the server's use of authorized SAF services to discover information about which EJBROLE profiles can or cannot be authorized to. The server must be granted permission to run authorization checks against the HLQ (the first segment of the profile name, up to but not including the first '.') of the EJBROLE profile name. If the SAF role mapper sets the HLQ of the mapped profile to the profilePrefix, the same profile BBG.SECPFX.BBGZDFLT governs both the APPLID authentication permissions, and the EJBROLE profile authorization permissions.

Let's assemble the configuration fragment for users authentication and authorization:

<?xml version="1.0" encoding="UTF-8" ?>
<server description="SAF security definition">
    <featureManager>
        <feature>appSecurity-2.0</feature>
        <feature>zosSecurity-1.0</feature>
    </featureManager>

    <safRegistry id="saf" />

    <safAuthorization id="saffer"/>

    <!-- trying to use WAS Classic granted permissions -->
    <safCredentials unauthenticatedUser="CZGUEST" profilePrefix="CBS390"/>

Controlling how roles are mapped to SAF Profiles

The System Authorization Facility (SAF) role mapper determines how EJBROLE profile names are generated from application-defined role names. The mapper is invoked whenever SAF authorization is performed for an application role. The authorization check for the application role is made against the underlying SAF security product using the mapped profile name generated by the SAF role mapper. If the default behaviour of the SAF role mapper doesn't meet your requirements, it can be configured by using the safRoleMapper configuration element.

<safRoleMapper profilePattern="myprofile.%resource%.%role%" toUpperCase="true" />

Where profilePattern means the pattern used to map application roles to profile names, %role% is substituted at run time with the value of the application role and %resource% is substituted with the resource name. If not specified, the default is profilePattern="%profilePrefix%.%resource%.%role%". The toUpperCase="true|false" attribute indicates whether the mapped profile name must be folded to uppercase. If not specified, the default is false.

The SAF role mapper will automatically substitute any wildcard characters (%&*) and whitespaces in the mapped profile name with the '#' character.

<safRoleMapper profilePattern="myprofile.%resource%.%role%" 
               toUpperCase="true" />

The user has to have access to the MYPROFILE.SYNC-TO-THREAD.PRIVATEZONE resource in RACF (sync-to-thread is the application name, privatezone the reference on the application-defined role, upper case is on):

RDEFINE EJBROLE MYPROFILE.SYNC-TO-THREAD.PRIVATEZONE UACC(NONE)
PERMIT MYPROFILE.SYNC-TO-THREAD.PRIVATEZONE CLASS(EJBROLE) ID(ROOT) ACCESS(READ)
SETROPTS RACLIST(EJBROLE) GENERIC(EJBROLE) REFRESH

Java thread identity to z/OS and DB2 threads identity propagation

Setting the OS identity thread synchronizes the Java EE role identity and OS thread (SyncToOSThread). This means that the OS thread identity is associated with the Java EE role identity during the EJB or Servlet method invocation. This association means that the caller or security role identity (rather than the server region identity which is switched on by default) is used for z/OS system service requests such as access to files and database management systems. The WebSphere Liberty Profile for z/OS server can be configured to enable or disable this association (or synchronization).

Enabling syncToOSThread for J2C connections

Enabling syncToOSThread support for J2C connections requires the appSecurity-2.0 and zosSecurity-1.0 features. The syncToOSThread configuration element must be defined, the j2cEnabled attribute must be set to "true". In addition, you must use the SAF registry for authentication, and authorized SAF services must be available.

Because syncToOSThread support requires authorized SAF services the angel process must be up and running and the server must be connected to it.

Enabling syncToOSThread for applications

Enabling syncToOSThread support requires the appSecurity-2.0 and zosSecurity-1.0 features. The syncToOSThread configuration element must be defined, the appEnabled attribute must be set to "true". In addition, you must use the SAF registry for authentication, and authorized SAF services must be available.

Because syncToOSThread support requires authorized SAF services, the angel process must be up and running and the server must be connected to it.

Each application, which will exploite syncToOSThread support, must be configured by adding the following env-entry to application's deployment descriptor:

<env-entry>
    <env-entry-name>com.ibm.websphere.security.SyncToOSThread</env-entry-name>
    <env-entry-type>java.lang.Boolean</env-entry-type>
    <env-entry-value>true</env-entry-value>
</env-entry>

To perform syncToOSThread (either of J2C or applications) operations must be granted the server permission by configuring the SAF product with either of the following profiles:

RDEFINE FACILITY BBG.SYNC.<profilePrefix> UACC(NONE)
PERMIT BBG.SYNC.<profilePrefix> ID(<serverUserId>) ACCESS(CONTROL) CLASS(FACILITY)
SETROPTS RACLIST(FACILITY) GENERIC(FACILITY) REFRESH

This allows the server to sync any RunAs identity with the OS identity.

...or...

RDEFINE FACILITY BBG.SYNC.<profilePrefix> UACC(NONE)
PERMIT BBG.SYNC.<profilePrefix> ID(<serverUserId>) ACCESS(READ) CLASS(FACILITY)
SETROPTS RACLIST(FACILITY) GENERIC(FACILITY) REFRESH

Additionally, let's grant the userid of the server READ access to one or more BBG.SYNC.<runAsUserId> profiles in the SURROGAT class, one for each RunAs identity to be synchronized with the OS identity:

RDEFINE SURROGAT BBG.SYNC.<runAsUserId> UACC(NONE)
PERMIT BBG.SYNC.<runAsUserId> ID(<serverUserId>) ACCESS(READ) CLASS(SURROGAT)
SETROPTS RACLIST(SURROGAT) GENERIC(SURROGAT) REFRESH

The <profilePrefix> is by default "BBGZDFLT" and can be configured by using the <safCredentials profilePrefix="xx"> element in the Liberty configuration file (exactly as described above).

Native z/OS workload management (WLM) services for your applications

Modern mainframes have up to 141 processors, ten terabytes of the main memory and a large number of I/O channels. Hundreds and even thousands address spaces (processes) run on a mainframe at the same time. Each workload is designed to meet concrete business requirements, and running for its own purposes (i.e. a production application, a tested one or just a debug version). Also, there are a two different data processing styles: batch processing or transactional, so workloads have different and competing completion and resource requirements, and the requirements must be balanced in order to make the best use of the resources of an installation, maintain the highest possible throughput and achieve the best possible system responsiveness. The function that makes this possible is dynamic workload management, which is implemented in the Workload Management component of the z/OS operating system.

With z/OS Workload Management (WLM), an administrator defines performance goals and assign a business importance to each goal. The goals are defined for work in business terms, and the system decides how many resources, such as CPU or storage, should be given to it to meet the goal. Workload Management will constantly monitor the system and adapt processes to meet the goals.

To enable the WLM services, the started task ID of the Liberty server must be granted READ access to the BBG.AUTHMOD.BBGZSAFM.ZOSWLM profile in the SERVER class:

RDEFINE SERVER BBG.AUTHMOD.BBGZSAFM.ZOSWLM UACC(NONE)
PERMIT BBG.AUTHMOD.BBGZSAFM.ZOSWLM ID(<serverUserId>) ACCESS(READ) CLASS(SERVER)
SETROPTS RACLIST(SERVER) GENERIC(SERVER) REFRESH

The zoswlm-1.0 feature with additional configuration is used to enable access to z/OS WLM services for the applications running on Liberty.

A WLM enclave is associated with the thread that the request is dispatched on. It is also associated with a WLM Service Class. A WLM Service Class is assigned to the WLM enclave by WLM, based on rules that you define in the WLM configuration. The WLM Service Class indicates the WLM goals for each class of client work, for example, 95% complete in 1 second or less. The WLM Service Class also indicates the importance of the goals relative to other work on the system. WLM uses information that is provided by the Liberty server during classification to assign a WLM Service Class. The classification is specified in the wlmClassification element contained in the server.xml configuration file.

<?xml version="1.0" encoding="UTF-8" ?>
<server description="WLM configuration">
    <featureManager>
        <feature>zoswlm-1.0</feature>
    </featureManager>

    <wlmClassification>
        <httpClassification transactionClass="DBMTRAT2" resource="/sync-to-thread/dbtest/t2" />
        <httpClassification transactionClass="DBMTRAT4" resource="/sync-to-thread/dbtest/t4" />
        <httpClassification transactionClass="DBMDTRAN" />
    </wlmClassification>

    <zosWorkloadManager collectionName="CZSR01" />
</server>

Three main parameters help WLM to classify the work: Subsystem Type is CB for WebSphere Application Server as well as for Liberty Profile, Collection Name is name of the server that is running the work, mixed case is supported but only the first 18 characters are used, and Transaction Class is determinated from classification of work within Liberty code. Transaction Class is based on the Liberty configuration that you provide for the request that is being dispatched. You can assign different Transaction Classes to different applications within the same server, and thus different WLM Service Classes (see the example above).

Five cents about the Collection Name. By default the vaule ${wlp.server.name} is used, this is the directory name of the server. This value is very difficult for mainteinance and support. The Collection Name for the server could be exactly specified as a value of the collectionName attribute of the zosWorkloadManager configuration element in the server.xml file.

If the classification is configured and the started task ID of the Liberty server is granted the permission, a number of WLM enclaves will be associated with the thread that the user's request is dispatched on.

Java EE 7

What about Java EE 7? Let's checkout an easy application developed by Adam Bien, an independent Java EE evangelist. Server Smoke is a JSF 2.2 based smoke test for Java EE application servers, which actively uses EJB, CDI and provides a JAX-RS web-service. The application is available by the link. You can just download the application and put it in the apps directory of the application server installation. The next step is to register the application in the server.xml configuration file:

<application context-root="server-smoke" type="war" id="server-smoke" 
             location="server-smoke.war" 
             name="server-smoke"/>

The following features from the Java EE 7 WebProfile have to be enabled: cdi-1.2, jaxrs-2.0, jsonp-1.0 and jsf-2.2. So, the server can tell you he doesn't smoke:

Summary

Long long time ago, Mainframes was able to execute only COBOL, PL/1 or ASSEMBLER applications. The modern mainframes are a computing platform provides the exceptional capabilities in the performance and high-availability terms for your Java 8 and Java EE 7 based applications.

WebSphere Liberty Profile as opposite to the WebSphere Traditional does not require a number of gigabytes of a DASD for her installation and deployment, the application server topology has no profiles and node agents, the wasadmin tool and the administration console are not necessary for application deployment and so, the server requires less efforts from the operational staff. The archive that contains the application server takes about 160 MB and does it only since all provided components ('features') are included here. The server runtime includes only required for your application's features and takes much less time for starting and memory for running. Less memory means less GC pressure and less long pauses during application execution.

To be deployed, an application just should be moved to the server apps catalog and be registered once in the server.xml file. All changes committed into the server.xml is taken into account without any server restarts.

All advantages provided by the z/OS platform are available for the application server: SAF based authentication and authorization, database and the application server in one operating system image collocation, the fastest in the World cross-memory services for data accessing, workload classification and rules-based prioritization and some other capabilities.

WebSphere Application Server is a base for WebSphere Optimized Local Adapters (WOLA) is a high-speed memory-to-memory transfer technology function provided with WebSphere Application Server for z/OS. It provides an excellent mechanism for communicating between WAS z/OS and other systems such as CICS, IMS and Batch programs. Another IBM WebSphere Liberty Profile based product, z/OS Connect Enterprise Edition (EE) unleashes the value of applications and data on z/OS in the API economy and opens your data for the modern mobilized and APIzed World.

Read more about Java EE and WebSphere Application Server

• Java EE as a Platform for Enterprise Application Integration
  
  
• Collection-based DAO on bare JDBC and Java 8 without JPA or Hibernate. Do you wish a piece of functional magic?
  
  
• Why can't my DMGR see a successful federated ex-standalone node?
  
  
• Phantom conflicts while WebSphere Application Server's NodeAgent is starting: A conflicting IP address and port

Would you like to give a 'Like'? Please follow me on Twitter!