Oct 2 ’07
Mainframe SOA Performance and TCO: Exploiting zIIP/zAAP Specialty Engines Through Next-Generation Mi
Rapid adoption of Service-Oriented Architecture (SOA) is altering the perception and role of the mainframe in modern business computing, making it much more capable of participation in loosely coupled, standards-based, cross-platform environments. To be more competitive and adaptable to change, organizations with enormous investments in legacy mainframe systems are turning to SOA to provide more infrastructure flexibility with reduced development cycles and lower costs. However, there are right and wrong ways to go about mainframe SOA enablement.
In an ideal SOA implementation, leveraging assets is a bidirectional affair. That is, mainframe strengths—transactional processing and data storage— aren’t merely subsumed into the advantageous characteristics of a standards- based distributed platform, but the distributed platform also partakes in advantageous characteristics associated with the mainframe platform. Traditionally, mainframes’ advantages have included rock-solid stability and reliability, a high degree of security, and unsurpassable horsepower for processing high-volume transactions.
It isn’t uncommon today to find mainframe integration middleware that enables mainframe data sources to be virtually extended to support composite application development or provide SOAP wrappers for mainframe transactions to participate in a SOA. However, there’s a new generation of mainframe middleware emerging that cunningly exploits IBM’s latest System z architecture to provide significant performance enhancements for SOA, while simultaneously reducing hardware usage costs.
According to IBM, the new specialty engines are processors that can help users expand the use of the mainframe for new workloads, while helping lower Total Cost of Ownership (TCO). The new System z specialty engines are:
• System z9 Integrated Information Processor (zIIP): the zIIP’s execution environment that accepts eligible work from z/OS, which will manage and direct the work between the generalpurpose processor and the zIIP • System z Application Assist Processor (zAAP): specialized processing engines that provide a strategic z/OS Java execution environment • Integrated Facility for Linux (IFL): a processor dedicated to Linux workloads • Internal Coupling Facility (ICF): allows multiple z/OS Logical Partitions (LPArs) to share, cache, update, and balance data access.
This article focuses on the zIIP and zAAP specialty engines and explores the opportunities they provide for mainframe middleware. Unless thoroughly versed in the workings of IBM's System z and its latest advances, enterprise architects developing SOAs may overlook integration middleware that exploits these specialty engines, limiting the full potential for mainframe involvement, and saddling their organizations with less than optimal performance and value.
Evolution: Getting the Most Out of the CPU
Mainframe systems still have a reputation as being expensive; the common tendency is to attribute this to hardware pricing. However, most of us know that, today, it’s mainframe software costs that have the potential to break the bank, with the battle in most mainframe shops being managing the cascade of incremental software charges from their Independent Software Vendors (ISVs) tied to MSU increases. An organization might project doubling its mainframe MSUs in five years only to find the rate of business growth varied from expectations. If they pre-purchased the MSUs to handle projected growth, they’d immediately incur software maintenance charges from all the ISVs.
IBM first attempted to address this aspect of mainframe TCO by designing the means to electronically govern MSU capacity using microcode to “throttle” the actual full processing capacity of a mainframe computer. This approach let IBM sell a customer a CPU that can run at, say, 5,000 MSUs and set it to run at 224. That customer could later purchase upgrades at incremental rates on an asneeded basis as business growth required or budgetary constraints allowed. IBM received additional revenue, and its customers benefited from non-disruptive upgrades that let them keep a tight rein on software charges.
With the new architecture facilities available on the System z platform, IBM has provided another way to improve mainframe TCO. These specialized processing units—the zIIP and zAAP— partly arose out of the realization that certain types of workloads could be more effectively handled outside the General Purpose Processor (GPP). running Java on the mainframe is highly processor-intensive. Having a specialty engine dedicated to this type of workload is strategic to IBM and its ability to reinforce WebSphere, its Javabased enterprise platform suite. In a similar vein, the zIIP specialty engine plays a role in IBM’s DB2 strategy, making it easier, and considerably more cost-effective for data-intensive applications such as Enterprise resource Planning (ErP), Business Intelligence (BI), and Customer relationship Management (CrM) to have portions of their queries directed to the zIIP.
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