IBM System z™ mainframe computers can be a powerful hardware platform for Service-Oriented Architecture (SOA) system deployment, especially for mission-critical applications demanding high performance. Learn some options for getting the most out of SOA applications by running them on z/OS®.

Tilak Mitra (tmitra@us.ibm.com), Executive IT Architect, EMC

Tilak MitraTilak Mitra works as an executive IT architect in IBM. He specializes in Service-Oriented Architectures (SOAs), helping IBM in its business strategy and direction in SOA. He also works as an SOA subject matter expert, helping clients in their SOA-based business transformation, with a focus on complex and large-scale enterprise architectures. He lives in sunny south Florida, and while not at work, is often engrossed in the games of cricket and table tennis. Tilak was awarded his Bachelor's degree in Physics from Presidency College, Calcutta, India, and then received an Integrated Bachelor's and Master's in Electrical Engineering from Indian Institute of Science, Bangalore, India. You can blog with him, and you can also reach him at tmitra@us.ibm.com.


developerWorks Contributing author
        level

23 August 2006

Introduction: The intersection of mainframes and SOA

The IBM mainframe is one of the world's oldest and most-proven platforms. It represents both a hardware architecture and an application style, and it operates many mission-critical, industrial-strength applications around the world. However, the democratization of IT, as delivered by both the PC platform and many middle-tier environments, has resulted in a proliferation of computing choices. These options have come predominately at the expense of the mainframe platform.

Service-Oriented Architecture (SOA) has been one of the latest IT architectural trends. It has demonstrated the benefits that can be harnessed by aligning IT initiatives with the business goals of an enterprise. Many small, medium, and large enterprises, across all the vertical market sectors, have implemented and deployed SOA successfully and enjoyed its benefits, which have been ably backed up by impressive return on investment (ROI) numbers.

While SOA is more of a functional architectural paradigm with various competing methodologies for its implementation, one aspect of an SOA-based application that is often ignored is its ability to meet high service-level agreement (SLA) requirements. The inability of many SOA initiatives to meet SLA requirements, such as performance, availability, and security (to name a few), has resulted in the questioning of SOA as an efficient way of buttressing an enterprise and taking it to the next generation of business agility. The failure stories have, more often than not, stemmed from the inability for an SOA-based deployment to outperform, or even to equal, the performance of existing systems that were chosen in the first place for service enablement.

The main SOA constructs include the following:

  1. A service
  2. A composition of services
  3. A service orchestration

These compose additional layers of abstraction, each of which introduces run time overhead that might be construed as a necessary evil. The hardware infrastructure on which an SOA is deployed plays a critical role in bolstering the performance and throughput and other SLA capabilities of the run time, thereby offsetting (and sometimes more than offsetting) the overhead (from increased abstraction) associated in an SOA-based system.

For the last four decades, IT departments and enterprises have enjoyed the unique workload management capabilities of the IBM System z™ and z/OS® architectures. z/OS has been proved to deliver unsurpassed availability and reliability. Scalability with z/OS mainframes has met and often surpassed future transaction throughput requirements. It is practically impossible to ask IT shops accustomed to these kind of performance benefits to forfeit their legacy systems, which have been instrumental to make their IT run their businesses with a very high level of satisfaction.

This article describes a variety of ways that technologies running on the IBM System z computer can be used to meet the requirements of modernizing existing systems and applications through an SOA transition.


Customer Information Control System applications and SOA

The IBM Customer Information Control System® (CICS®) is a transaction processing (TP) monitor that was originally developed for IBM mainframes. It controls the interaction between applications and users and lets programmers develop screen displays without detailed knowledge of the terminals being used. CICS provides industrial strength, online transaction management, and connectivity for mission-critical applications.

CICS transactions fall in two categories: visual and non-visual. End users interact with visual transactions through terminal emulators and green screens. Non-visual transactions provide no end-user interaction and they are invoked by other system programs. Non-visual transactions are also called COMMAREA transactions, since the invocation parameters and output data use a mainframe storage area called the communication area.

COMMAREA transactions follow the request-response paradigm. Although services in an SOA can be asynchronous, they are most commonly developed and used according to a synchronous request-response invocation mechanism. The COMMAREA transactions can be exposed as a service (in an SOA), which provide access to data. The non-visual transactions go through a data translation layer called basic mapping support (BMS) that encapsulates the terminal-based data formats into a technology-neutral format called application data structure (ADS). ADS-formatted data can be easily translated into XML to be subsequently used in a service-based invocation.

With the above in mind, it is realistic to think that one can build an SOA system on legacy CICS-based applications and not rip the existing systems apart and start from scratch. The advancements of the capabilities and the richness of the new feature set of z/OS helps make achieving a true SOA on System z a reality. The rest of the article tries to identify some of the key features of z/OS that can be leveraged while designing a robust infrastructure around which to build an SOA system.


WebSphere Application Server for z/OS

IBM WebSphere® Application Server (WebSphere Application Server) Version 6.1 for z/OS is the premier Java™ 2 Platform, Enterprise Edition (J2EE) and Web services application server for the mainframe, delivering a transaction engine bestowed with unique platform differentiators that enable the highest levels of system workload. WebSphere Application Server for z/OS is built on a code base that is common with the rest of the WebSphere Application Server family, and it brings in all the WebSphere Application Server capabilities to provide a middleware execution run time for SOA-based applications and systems. WebSphere Application Server for z/OS provides capabilities for seamless connectivity to CICS applications and can also connect to various z/OS assets required by the application. For example, unique connections are available to DB2® Universal Database™ (DB2 UDB) for z/OS that simplify the architecture and enhance performance.

WebSphere Application Server for z/OS provides various connectivity options to CICS applications. Some of them are loosely coupled interactions, whereas others can be tightly coupled communications. Both of these might be required based on how much flexibility the application needs and on the SLA criteria that need to be met.

All the SOA capabilities built into the WebSphere Application Server have been made available on the z/OS. Those capabilities, together with the scalability, robustness, and high performance characteristics of the IBM Z Series platform is a big step in realizing the true potential of an SOA system.


Leveraging IBM System z Application Assist Processor

The IBM System z Application Assist Processor (zAAP) feature of the zSeries® model 990 (z990) and 890 (z890) servers is a specialized processing unit that provides a dedicated z/OS Java-only execution runtime. Think of it as a parallel processor that is dedicated to run only Java-based applications, systems, and middleware. The configuration allows for a zAAP to coexist with the general central processors (CPs) of System z, with the ability to add multiple zAAPs on demand based on workload requirements. Java-based application invocations can be all configured on one or more zAAPs and it can be offloaded by the general CPs, thereby managing increased workloads.

WebSphere Application Server for z/OS versions 5.1 and 6 can run on one, or more, dedicated zAAPs, providing an environment that combines the capabilities of the WebSphere Application Server middleware with the quality of service (QoS) advantages of System z. This even enables z/OS to run an Enterprise Service Bus (ESB). zAAPs provide the infrastructure for deploying an SOA implementation on System z.

zAAPs can be used in innovative ways to manage applications, along with mission-critical data in situations calling for a tightly integrated, highly secure, and extremely efficient SOA-based implementation. It is wise to keep in mind that SOA is not always about loose coupling: SLA requirements direct how much loose coupling is realistic. Loose coupling is almost always antithetical to the requirements of mission-critical systems. One innovative way to use a zAAP in an SOA deployment is to execute new applications within the same z/OS logical partitioning (LPAR) as their associated database subsystems. This simplifies server infrastructure and improves operational efficiency by reducing the latency associated with a distributed configuration.

In general, zAAPs cost less than their general CP counterparts. Service requests can easily be offloaded to the lower-cost, Java-attuned zAAP to provide a significant savings for an SOA deployment. Adding the lower cost zAAP's on demand and on top of the existing general purpose CP's can reduce the cost of ownership of an SOA infrastructure.

A zAAP helps run Java-based SOA implementations on System z and it can also significantly reduce the total cost of ownership of an SOA implementation. This is a big advantage of deploying an SOA on z/OS.


CICS Transaction Server

The CICS Transaction Server Version 3.1 exposes CICS-based applications as Web services, as well as integrates the applications into an SOA-based system. The CICS Transaction Server also allows CICS applications to act as both a service provider and a service requestor, thereby simplifying integration of CICS applications into a modern business-to-business (B2B) and service-based environment.

The CICS Transaction Server can modernize CICS applications using either of the two architectural patterns: loose coupling or tight coupling. Each of these integration architecture forms is realized through specific features and capabilities of the CICS Transaction Server. SOA can be realized through both architectural forms. Which one to use is an architecture decision, one of the main deciding factors of the SLA requirements for the system. The rest of this section explores the key features of the CICS Transaction Server that enables CICS applications to be made participants in an SOA. Let's explore three architecture scenarios, one for the loosely coupled pattern and two for the tightly coupled pattern.

Loosely coupled -- using Web services

The CICS Transaction Server 3.1 provides Web service support and hence supports loosely coupled integration between CICS applications on z/OS and external systems and applications. The support is through the provision of a number of standards, for example Simple Object Access Protocol (SOAP) 1.1 and 1.2, WS-Security, WS-AtomicTransactions, and WS-I Basic Profile. The CICS Transaction Server 3.1 has the capability to provide a Web Services Description Language (WSDL) definition of an existing COMMAREA program. The reverse process of creating a COMMAREA program stub from a WSDL definition is also possible.

The basic architecture of how the CICS Transaction Server provides Web services support is depicted in Figure 1.

Figure 1. CICS Transaction Server Web service support
CICS Transaction Server Web service support

Depending on the transport protocol, the Web client request can be intercepted either by a HTTP listener or a WebSphere MQ trigger monitor. In both cases, the request is passed to the SOA-aware pipeline component, which strips the SOAP headers and extracts relevant information, such as security. The pipeline sets up the transaction and security context in the CICS environment. An optional custom data mapping component is used if the XML data needs to be translated into other languages or data structures, such as COBOL records. Business logic in the CICS application is invoked and, from there on, it is business as usual, meaning that there is not a change to any downstream CICS application operation or functionality. The response is passed back to the pipeline, where it is wrapped in a SOAP header and then returned to the invoking client.

In this access mechanism, the existing CICS application is virtually untouched and components in the CICS Transaction Server are leveraged to provide a Web service facade on top of the existing business logic. If there is room to incur the latency that tends to be associated with today's service-based modernization while still being able to meet the required QoS requirements, this form of service-orientation (loosely coupled) is the best approach to modernizing existing CICS applications running on z/OS.

Tightly coupled -- using Java Connector Architecture

Some key advantages of loosely coupled systems are flexibility, adaptability, and less maintenance. Mission-critical applications cannot afford to enjoy these advantages of loosely coupled systems, because they often come with a performance cost. In cases where J2EE-based applications running on middleware, such as WebSphere Application Server for z/OS, need to integrate with CICS applications running on System z mainframes and where the end-to-end systems are mission critical in nature, it is a better architectural decision to use a tightly coupled approach.

The Java Connector Architecture (JCA) defines a standard for connecting from the J2EE-based applications to heterogeneous Enterprise Information Systems (EIS), such as the CICS Transaction Server. The CICS Transaction Gateway is a high-performing, highly secure, and scalable access option for building a tight integration to existing CICS applications.

The CICS Transaction Gateway runs on WebSphere Application Server for z/OS. It provides a JCA connector for CICS Transaction Server that acts as a resource adapter, providing connectivity between a J2EE application server (such as WebSphere Application Server for z/OS) and the CICS Transaction Server. Think of the JCA as a bridge that connects J2EE components running on a J2EE application server to the CICS applications through the CICS Transaction Server.

Figure 2. Using JCA on z/OS
JCA on z

As shown in Figure 2, JCA provides a Common Client Interface (CCI) that provides a technology agnostic interface that the J2EE components (servlets, Enterprise Java Beans (EJBs), and so forth) can invoke. The CICS Transaction Gateway provides a resource adapter specific to the CICS Transaction Server that provides the connectivity to the CICS Transaction Server. The J2EE application components can invoke the CICS business logic program directly if no message transformation is required. A message adapter in the CICS Transaction Server is required only if the message is to be transformed, for example, if the request is in XML and the CICS business logic program requires a COBOL record format.

This mode of communication between J2EE components running on WebSphere Application Server for z/OS and CICS applications provide for a strict and tight coupling. SOA deployments on WebSphere Application Server for z/OS can integrate with CICS applications and enable the latter to take part in a overall SOA.

Tightly Coupled -- EJB and JCA

The CICS Transaction Server also contains a Java Virtual Machine (JVM) with provisions to run EJBs. In this scenario, a stateless session bean is used as a facade to the JCA. Contrary to the previous scenario where the resource adapter was running inside the CTG, the JCA and the resource adapter run inside the CICS Transaction Server, as shown in Figure 3. The resource adapter functions in exactly the same way as it does in the previous scenario.

Figure 3. J2EE runtime capability of CICS Transaction Server
J2EE on CICS Transaction Server

The message adapter is optional and is only required if a data format translation needs to be made before invoking the CICS applications. The message adapter provides capability to support any implementation language and data formats that might be used in the business logic layer.

The capability of the CICS Transaction Server to provide a Java runtime and host EJBs allows for the modernization of CICS applications using J2EE technology. Session EJB services can be accessed through an open standards protocol, such as RMI-IIOP. The EJBs can also be exposed as Web services and made available through SOAP over any supported transport. This CICS Transaction Server feature helps in modernizing CICS applications running on z/OS so that they can take part in a service-oriented ecosystem.


Using the ESB on System z

Both the CICS Transaction Server and WebSphere Application Server running on System z opens up a lot of possibilities to build an SOA on z/OS. Additionally, the ESB is another key infrastructure element that helps in realizing a loosely coupled SOA. An ESB provides, at the very least, protocol translation, mediation, and intelligent routing (between service providers and requesters).

It is not a surprise that enterprise clients use an ESB to access business services hosted in the WebSphere Application Server environment. If the CICS applications are Web service-enabled, the JCA connectivity between WebSphere Application Server for z/OS and CICS can be replaced by Web services. In this scenario, the J2EE business logic does not change, nor does the CICS business logic. Only the nature of the interface code changes. This interface code is now the standard Java API for XML-based RPC (JAX-RPC), and it's just like what would be used to invoke any other Web service. The developer does not need any specialized JCA skills or any knowledge of CICS COMMAREA transactions. The COMMAREA transactions have been converted into SOAP messages.

One additional effect of this service enablement is that an ESB can be used to broker communications between WebSphere Application Server for z/OS and CICS (through CICS Transaction Server). This also means that the communication between the clients and WebSphere Application Server uses the same infrastructure as the communication between WebSphere Application Server and CICS, thereby simplifying administration.

Figure 4 depicts a high-level architectural view of how an ESB can be used to modernize legacy applications on System z so that they might become part of an SOA environment.

Consumers (for example, business partners and Java/.NET clients) use the ESB to access the business services that are exposed by an enterprise. The same ESB might be used by the EJBs running in WebSphere Application Server on z/OS to invoke the service-enabled CICS business applications running on the System z. The CICS applications can also leverage the ESB to invoke the business services that are exposed by WebSphere Application Server. This way the same ESB can be used for service invocation across heterogeneous applications and platforms, thereby leveraging a common infrastructure.

Figure 4. Modernizing legacy System z applications to make them participants of an SOA
Modernizing legacy for SOA

Using the Web Service Gateway on z/OS

In the previous sections, I discussed options that you can use to expose both the CICS applications and J2EE applications on WebSphere Application Server for z/OS as Web services. With multiple possible Web services deployed on z/OS, centralized management of how services are invoked and used becomes imperative. The Web Services Gateway is an IBM product that provides for centralized management and administration of Web services. The gateway acts as a single point of control for incoming service requests. The possible benefits of using Web Services Gateway as a part of the SOA run time are the following:

  1. It decouples the physical endpoint of the target service from the client by providing a gateway endpoint to the client. The gateway endpoint does the routing of the service request to the actual target service. This decoupling helps in changing the target service endpoint without any change in the client invocation mechanism.
  2. It provides the ability to switch from one kind of transport and security model to another, in other words, between the incoming request and gateway and also between the gateway and the service provider.
  3. It provides pre-processing and post-processing filters for the target services. The gateway filters are implemented as JAX-RPC handlers, which is the preferred approach for filtering service requests and responses. An example of a filter is the implementation of auditing capabilities for each service requests that arrive at the gateway.

Although the Web Services Gateway can be deployed in a non-z/OS environment, an SOA infrastructure will gain much by deploying the Web Services Gateway with WebSphere Application Server for z/OS, which can thereby leverage the native workload management capabilities of the System z mainframe. Significant performance gains are achieved in a topology where the Web Services Gateway and WebSphere Application Server for z/OS are collocated in the same z/OS instance. The performance gains come from passing the service requests by reference, which decreases CPU consumption significantly.


Conclusion

Leveraging the power of z/OS to run mission-critical applications and systems with the capabilities of the middleware products and solutions, such as WebSphere Application Server for z/OS, is a compelling combination. Combining these technologies can help realize much-needed business agility in today's enterprise (through service orientation) by building on top of existing legacy applications. The promises of truly realizing the business benefits of legacy modernization can become a reality.

Rip and replace is not always the best solution for modernizing IT. Enterprise assets, both business functionalities and infrastructure capabilities, that are provided by existing legacy systems running on z/OS have been tested over time and proven to overachieve the requirements of performance, availability, throughput, and security of mission-critical business applications. The value proposition of SOA can be easily extended to modernize such existing systems. This article tries to point out some capabilities of z/OS as well as the middleware running on the System z mainframe that make SOA-based deployments a reality on System z.

Resources

Learn

Get products and technologies

  • IBM trial software: Build your next development project with software for download directly from developerWorks.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=155713
ArticleTitle=Make SOA happen on z/OS
publish-date=08232006