As a J2EE application server, WAS for z/OS supports the Java Messaging Service (JMS). There are three choices for JMS providers in WAS for z/OS V5.x: WebSphere MQ (WMQ), Embedded Messaging (EM) JMS provider, or a third-party product.

The EM JMS provider is a simplified WMQ. It provides an isolated messaging environment in WAS for z/OS that can't be used to interoperate with any other messaging systems. Obviously the JMS support in WAS for z/OS was a temporary solution. Now it's been deprecated in WAS for z/OS V6. Instead a new JMS provider named Service Integration Bus (SIB) has been introduced. SIB is part of IBM's Enterprise Services Bus (ESB) infrastructure solution, which isn't just a simple JMS provider. I'll discuss WAS for z/OS and SIB in a separate article.

There are few third-party messaging products that run on z/OS. So this article will focus on discussing WMQ JMS provider connectivity architecture and Java messaging development. If you'd like use a third-party product as the JMS provider, all the messaging resource definitions in WAS for z/OS are indirections to the provider's resource. You should refer to the third-party product's document for details.

If not mentioned specifically, this article refers to WAS for z/OS V5 (or later) and WMQ for z/OS V5.3 (or later).

To make the article self-contained, I'll start with some zSeries terminology even though most appeared in my previous articles. If you're familiar with them, you can directly jump to the WAS for z/OS WMQ Connectivity Architectures section.

z/OS Concepts and Terminology
zSeries hardware can allocate resources to multiple logical partitions (LPARs) in a single zSeries machine, with each partition supporting a single z/OS image.

A SysPlex is a collection of LPARs joined together to form a single logical entity or view to an external observer.

A Coupling Facility (CF) is a zSeries machine with microcode that permits high-speed communication between LPARs in a SysPlex as well as a common repository for sharing data by subsystems like DB2 and WMQ that are in different LPARs in the SysPlex.

Resource Recovery Service (RRS) is a z/OS component that can do transaction management for multiple subsystems such as CICS, DB2, WebSphere, and WMQ on the same LPAR.

Workload Manager (zWLM) uses installation-defined policies and service-level commitments to govern workload performance in the system.

Dynamic Virtual IP Address (DVIPA) is a common external IP address for an application residing or executing on different LPARs in the SysPlex.

Sysplex Distributor (SD) is a z/OS component (part of the TCP/IP stack) that consults zWLM to distribute inbound DVIPA requests to the best suitable LPAR in the SysPlex.

Automatic Restart Management (ARM) is a z/OS component that will try to restart a job or task after a failure.

The Batch Adapter is the interface between WAS for z/OS and WMQ on the same z/OS image. It lets applications in WAS for z/OS use the MQI (the de facto WMQ programming interface). A connection thread is provided from an application task control block (TCB) to WMQ.

Queue-sharing group (QSG) lets a group of queue managers access the same shared queues. Only WebSphere MQ for z/OS has the queue-sharing group feature.

WAS for z/OS WMQ Connectivity Architectures
There are two basic connection modes from WAS for z/OS to WMQ: binding mode and client mode. To exploit the scalability and availability features provided by SysPlex on the zSeries platform, the connectivity architecture with WMQ queue-sharing group has to be considered. Different architecture options are discussed as follows.

Non-QSG Local Connectivity Solution
In Figure 1, WAS for z/OS and WMQ coexist on the same z/OS image. Applications in WAS for z/OS communicate with WMQ through a cross-memory mechanism provided by the Batch Adpater. This transport type for JMS is called a binding mode. The architecture discussed is called Basic Non-QSG Local Connectivity Solution in this article.

Binding mode is the best performance option because of its memory-to-memory communication mechanism. The basic binding mode depicted in Figure 1 doesn't provide failover solutions for the WMQ queue manager. (You wouldn't add more WMQ queue managers because that would cause application code changes.) ARM can be used to decrease the WMQ queue manager's outage time.

System automation tools like Netview can be used to stop the application server whenever the WMQ queue manager fails. So the storm drain risk could be reduced.

Let's take a look at the WAS for z/OS. As long as the control region is up, zWLM will always make sure that there are enough servant regions handling workloads. Should a servant region fail, zWLM will start a new servant region. From this perspective, a single WAS for z/OS server has better availability than distributed platforms.

To scale WMQ, more zSeries resources should be allocated or added.

There are two ways to scale the application server: adding more servant regions to the single server or creating a vertical application server cluster by adding new servers. Creating a vertical server cluster doesn't offer better performance. It consumes even more resources than adding more servant regions to the single server. However, it does provide better availability because the vertical cluster removes the single point of failure (SPOF) - the control region.

The basic binding mode's level of security is good. When a user attempts to access a WMQ resource, SAF security checks the relevant user ID or IDs to see if the access to the resource is allowed. You may still need the authorization control for WMQ resources.

The WAS for z/OS' thread identity function is available in this solution. The user identity can be passed to WMQ and the RMF audit trail records are cut. This security option is available in WAS for z/OS exclusively. Most z/OS customers would like to use this feature to make their applications more accountable.

The Batch Adapter supports single-phase commit. To support two-phase commit protocols, a WAS for z/OS stub, CSQBWSTB, which leverages the RRS facility, should be used.

The architecture can be expanded to achieve better availability and scale out. As shown in Figure 2, the revised architecture is called Advanced Non-QSG Local Connectivity Solution in this article. In this solution architecture, a cross-LPAR horizontal server cluster is configured. Each server in the cluster connects to the corresponding WMQ queue manager in binding mode.

The user requests are distributed to the most suitable application server in the cluster by SD (consulting with zWLM) via DVIPA. If one of the application servers fails or one of the LPARs goes down, the requests will be routed to the server running on different LPARs for processing. The best application server availability can be achieved when the LPARs reside on separate physical machines.

If the WMQ queue manager fails, a storm drain is possible (for WMQ outbound workloads). Similar to the basic binding mode solution, Netview can be considered as avoiding the storm drain. For fast recovery, a z/OS facility like ARM should be used.

To failover and balance WMQ inbound workloads, it's recommended that a WMQ queue manager cluster be set up as part of the solution. Should any one of the WMQ queue managers fail in the cluster, the new inbound messages would be routed to other available WMQ queue managers in the cluster using certain load-balancing algorithms. In the meantime, there's no need for a message producer to know which queue manager a message is sent to. However, the WMQ cluster doesn't solve the message availability problem. The messages sitting in the queue that belongs to the failed WMQ queue manager can't be processed until the failed WMQ queue manager comes back up. This might be a big problem especially for time-critical transactions.