Three inter-related factors make these new specialty engines special:

• The workload deployed on specialty engines is diverted from the GPP (depending on specialty engine availability), increasing the availability of the GPP to handle other workloads, reducing the need to purchase additional capacity. • Specialty engines also are exempt from the incremental microcode “throttling” imposed on the GPP. This means any workload running on a zIIP/zAAP can run at the full, unrestricted speed for higher performance. • The GPP no longer needs to perform work dispatched to a specialty engine, reducing the measured MSUs consumption charges and avoiding a cascade of associated ISV-related charges.

Applicability to SOA

The ideal middleware solution for integrating mainframe data and applications into a SOA environment will leverage the powerful characteristics inherent to the mainframe platform and factor in exploitation of the new specialty engines. IBM has dedicated the zAAP specialty engine for Java processing, which supports its SOA strategy for WebSphere. The zIIP specialty engine is focused on DB2 enablement. What if the middleware solution could be written to take advantage of both specialty engines to support SOA? The resulting middleware solution could deliver mainframe SOA enablement with more capabilities, lower costs, and increased performance.

SOA relies heavily on two industry standards—SOAP and the Web Services Description Language (WSDL)—to enable Web services and mainframe interoperability. Web services are all about XML— highly verbose, text-based messages that require significant XML parsing and XML navigation—and unfortunately, they’re mainframe CPU-intensive.

Let’s say an organization wants to use Web services to drive a mainframe-based airline reservation Web portal with a high transaction rate and sub-second response time requirement. The overhead imposed by the XML-based SOAP parsing associated with the mainframe Web services may actually prevent those transactions from occurring in less than a second. If successful, it most certainly won’t be elegant and no doubt costly from a MSU perspective. However, if that XML pro- cessing can be offloaded from the governed GPP to a zIIP or zAAP, it can now avail itself of the unchecked processing power of the specialty engine. Moreover, the XML workload now isn’t happening on the measurable GPP, which is subject to software per-MSU charges. This increases cost efficiency of the overall mainframe SOA solution.

Imagine if the airline reservation portal relied on Web services built on mainframe screen logic, which isn’t uncommon in legacy mainframe environments. In addition to the XML parsing, there also could be the requirement for mainframe screen orchestration. The Java platform is a primary platform of choice for running industry-standard Business Process Execution Language (BPEL) for Web Services 2.0, which is the preferred manner to orchestrate mainframe screenbased Web services and provides for a top-down, process-oriented approach to SOA. With middleware written to exploit these new specialty engines, organizations wanting to integrate mainframe assets into a SOA using BPEL orchestration (via a JVM) now have the ability to leverage the zAAP to run this critical component of the integration scheme.

Improved SOA enablement for the mainframe need not only be associated with the zAAP specialty engine. The zIIP also can be heavily exploited within a mainframe SOA scenario, though this requires still more sophisticated knowledge of both the System z hardware architecture and z/OS architecture. To understand how this is possible, let’s explore the multi-tasking environment of the mainframe in more detail.

Mainframe processes are dispatched as threads through Task Control Blocks (TCBs), but not all threads are created equal. Within z/OS, the Workload Manager (WLM) software prioritizes TCBs. WLM helps administrators control workloads according to such considerations as Quality of Service (QoS) and Service Level Agreement (SLA) goals. The z/OS also uses a lightweight, low overhead type of thread called an enclave Service request Block (SrB). The zIIP runs certain enclave SrBs that are zIIP-eligible. Those SrB workloads can run without the governing constraints put on the GPP and are free of the associated software charges. Most, if not all, middleware products that support mainframe SOA sold today weren’t written to run in enclave SrB mode; instead, they’re TCB-based products incapable of exploiting the zIIP.

Fortunately, the ability to run in both TCB mode as well as enclave SrB mode is possible, thanks to a new class of mainframe middleware software that provides the opportunity to build in features that enable zIIP and zAAP exploitation. A look at how this new class of software uses the zIIP engine may help illustrate the benefit of operating in enclave SrB mode. Consider the scenario of processing a mainframe Web service. When a request comes into the mainframe for a mainframe Web service, the first step will require translation of the Web service names and operations into WLM service classes. Newer, more evolved mainframe middleware can create an enclave SrB, which is eligible to be executed on the zIIP, while also providing the ability to designate the percentage of the SOA workload that’s off-loaded to the specialty engine.

Provided they understand z/OS and the nuances of WLM operations, developers working on next-generation mainframe middleware can take steps to ensure that many workload components of SOA also are made zIIP-eligible, including much of the XML/SOAP messaging processing, Open Database Connectivity (ODBC)/Java Database Connectivity (JDBC), ADO.NET processing, TCP/IP processing, tracing, and security. These types of CPU-intensive workloads are where the mainframe platform shines and, like the Java-specific workloads diverted to the zAAP, these can now enjoy the full unrestricted processing power of the zIIP.

The ability of newer mainframe middleware to use enclave SrBs allows for a considerable and immediate drop in software costs when WLM is used to transparently divert SOA-related workloads that have been running on the measured GPP to the unmeasured zIIP engine. It’s a double bonanza: The Web services perform better and cost less.

A New Future for Mainframe SOA

For organizations seeking the advantages of integrating their existing mainframe assets into a SOA, the benefits of IBM’s System z innovations shouldn’t be overlooked. IT architects and/or administrators for these organizations should watch for integration and middleware software vendors that have started adding new functionality to their products to leverage both the zIIP and zAAP specialty engines. A requirement has emerged for evaluating new mainframe SOA software that asks, “What is the percentage of SOA-related workload able to be run on a zIIP or zAAP engine?”

SOA provided the impetus for re-evaluating the mainframe, delivering industry- standard interoperability and ease of reuse for mainframe data and logic. These new mainframe architecture facilities provide an opportunity to change the workload characteristics of mainframe systems in an extremely beneficial way. Within the landscape of SOA, this new class of middleware can now further advance the value proposition of the mainframe platform, building on IBM’s own innovation with an alternative approach that benefits mainframe customers and expands the future and role of the mainframe across the service-enabled enterprise. Z  

2 Pages