Getting Synergy from Java on Mainframes

by Anura Guruge,
the editor at large for IT In-Depth

V6.0.1 for z/OS, unveiled on March 22, 2005 (and ready for shipment within that week), is the latest release of the mainframe-specific version of IBM’s market-leading Java app. server.  WebSphere Application Server (WAS) for z/OS is the crème de la crème of app. servers in that IBM goes to great lengths to ensure that it gainfully exploits the unparalleled scalability, reliability, security and resilience attributes of mainframes.  WAS for z/OS is for the large enterprises that need a mission-critical Java execution environment with guaranteed high-availability, plenty of brawn (with additional capacity on-demand) and exceptional defenses to thwart malicious intruders.

Though not the only way to run Java applications on a mainframe (as explained below) this, however, is the app. server you want if you really want synergy from a mainframe deployment.  It also happens to be the only Java app. server that runs on z/OS.

V6.0.1 supports the intriguing zAAP Java-accelerating mainframe processors as well as a new, autonomic computing related feature referred to as Enterprise Workload Manager (eWLM) which sets out to deliver dynamic workload management across a multi-tired, distributed environment made up of disparate IBM servers!  It also empowers SOA-based solutions by enabling an Enterprise Service Bus (ESB) implementation realized using Java Message Service (JMS) 1.1 and XML Web services.

The key new features in WAS for z/OS V6.0.1 can be summarized as follows:

Jockeying for 1.4 Leadership

WAS V6 is J2EE 1.4 compliant.  WAS V5 (introduced in mid-2002) was based on J2EE 1.3 but was touted to be ‘1.4 ready’ when it started shipping in November 2002.  Since each new iteration of J2EE adds a slew of new backbone services, the version of J2EE supported by an app. server sets the baseline as to the amount of ‘standards-based’ services it provides.  Hence the intense competition to have an app. server that supports the latest version of the J2EE spec. – which at present is 1.4.

WAS 5.1, that was announced in November 2003, included full support for the J2EE Software Development Kit (SDK) 1.4, and thus put the 1st stake in the ground when it came to J2EE 1.4 support.  The z/OS version of 5.1, available as of June 2004, included support for SDK 1.4 (which is significant because SDK 1.4 is a prerequisite if one intends to exploit the zAAPs).

Just a few years ago, there should be an intense tussle between IBM and BEA as to see who could be the first to support the latest J2EE – with BEA, in the beginning, invariably beating IBM to the post (to affirm their then stature as the market leader).  Things have changed and BEA doesn’t have the resources that IBM has.  Hence, BEA’s current version of the WebLogic Server, viz. 8.1, is still only supports J2EE 1.3.  1.4 support, at present [i.e. mid-April 2005], is only available in beta form with the provocatively titled ‘Diablo’ release of WebLogic – which will be released as 9.0.  It should, however, be noted that both Sun and JBoss also now have support for 1.4.

<<The Java logo and the above J2EE diagram belongs to Sun while the Diablo logo is the property of BEA.>>

The Mainframe as a Java App. Server

WAS for z/OS is not the only option for running mission-critical Java applications on a mainframe.  For a start the CICS Transaction Server for z/OS supports Java applications.  The other option, which may not be immediately obvious unless you ask yourself the question “why not”, is to run a Linux Java app. server on the mainframe.  Both IBM and BEA, or to be more pedantic, Red Hat and Novell SuSE, provide support for WAS and WebLogic on mainframes – thought it might not the latest release (even though Red Hat already has a WAS V6.0 for z/OS).

This time lag when it comes to mainframe (and iSeries) versions of app. servers is, however, the norm and even applies to WAS.  Hence why WAS for z/OS in invariably at a ‘dot’ release ahead of the other platforms; e.g. V6.0.1 versus V6.0.  This is meant to compensate for the delay.  What we typically end-up with is this ‘leap-frog’ sequence where the ‘delayed’ z/OS version, when released, includes a few new function ahead of the other (‘earlier’) platforms with IBM then getting around, a few months later bringing the functionality of the other platforms to match those on z/OS.

WAS (or WebLogic) on z/Linux does enjoy the yet unsurpassed scalability, reliability and resilience of mainframes.  But z/Linux isn’t z/OS and that is the crux of the issue.  To get all of the high-end mainframe benefits like WLM with the Intelligent Resource Director (IRD) and zAAP you (at least at present) need to use z/OS.  Hence the significance and importance of WAS on z/OS.

[Talking of the zAAP in this context, it would be remiss, if I did not point out at this juncture, that at least per IBM’s own documentation it should be possible to exploit zAAP with WAS V5.1, without having to upgrade to V6.0.1.  This has to do with the fact that zAAP support per se became available with SDK 1.4 – and V5.1 supports SDK 1.4, though it is not J2EE 1.4 compliant.  But to be honest, if you really have your heart set on exploiting a zAAP, and have already decided to invest the $125,000 to get one, then the safest bet would be to also get V6.0.1.]

Enterprise Workload Manager (eWLM) for z/OS

This, even more so that the zAAP, is the most beguiling features of V6.0.1.  eWLM is a core component of IBM’s Virtualization Engine technology for z/OS announced at the end of 2004.  eWLM allows system administrators to define business-oriented performance objectives for workloads running across disparate platforms, and then view actual performance compared to those objectives.  This technology, on z/OS, is nascent to say the least.  One could even say embryonic.  Current support, from what I can see, just enables the z/OS to monitor overall performance.  But this is a start.

To appreciate eWLM potential promise we need to step back for a second and think about how WLM has evolved.  WLM, which has now been around for awhile, can dynamically adjust and balance mainframe workloads to achieve desired performance expectations based on predefined business policies.  Traditional WLM, however, worked within the confines of each LPAR utilizing the hardware resources previously allocated to that LPAR.  Then came IRD with the introduction of the z900 and z/OS in October 2000.

IRD enabled processor and channel capacity to be dynamically switched between LPARs to best meet the business objectives of the entire mainframe – thus giving or taking away resources from each LPAR.  It is easy to appreciate the role of IRD if you think of a very basic mainframe configuration consisting of a production LPAR and a test LPAR.  When the production LPAR is experience heavy loads, IRD (provided that the policies approve it) will dynamically switch resources from the test LPAR to the production LPAR so that the WLM in that mission-critical LAPR can continue to satisfy the performance expectations.

eWLMs eventual long-term goal is to extend this type of dynamic workload balancing to extend across multiple platforms – across a network.  This, if IBM manages to get it right, would be a HUGE breakthrough vis-à-vis distributed processing.  So watch this space.  I am on top of eWLM.

  More on WAS for z/OS V6.0.1 in another posting shortly.