Sep 1 ’03

Web Services & The Mainframe

by Editor in z/Journal

When Atlanta-based National Account Service Co. LLC (NASCO) needed to help its customers, large health insurers, provide their own customers with control of their benefits, it turned to Web services to provide everything from claim status information to personal healthcare spending accounts. Similarly, when MeadWestvaco, an $8 billion producer of packaging, specialty papers, consumer and office products, and chemicals, wanted to leverage its use of SAP to improve order management and achieve greater flexibility, it turned to Web services.

The Bekins Co., a 100-year old moving company, turned to Web services running on Windows servers and its z/Series mainframe to broadcast instant notification of the brokered shipping opportunities that meet each of its agent’s (independent third-party transportation companies) specific criteria.

After what has seemed like endless hype, companies are finally doing substantive things with Web services and reporting significant results. “It has taken a long time, but people are doing real, practical, worthwhile things with Web services today,” said Carol Baroudi, principal, Baroudi Bloor, a technology research and consulting firm based in Arlington, MA. As these IBM case studies illustrate, Web services technology can be used on mainframe platforms along with the organization’s most critical enterprise applications to produce business benefits.


There is nothing revolutionary about Web services. On the contrary, Web services are a further refinement of Remote Procedure Calls (RPCs), Common Object Request Broker Architecture (CORBA), and distributed component-based computing. “Web services technology is just another Application Programming Interface (API). It is a way to use a standard API for everything instead of lots of different APIs,” said Peter Rhys-Jenkins, principal architect, Candle Corp. Consulting Services. Web services also take advantage of the existing, standardized IP networking infrastructure. As a result, “Web services are much easier and much simpler,” he added.

Web services represent another way of writing applications. The application’s functionality, even the entire application itself, is delivered as a service. Usually combining application functionality and data, Web services perform some recognizable task, such as generating an invoice or checking inventory  availability. Entire applications, such as Customer Resource Management (CRM), can consist of Web services or be a Web service.

Most people think Web services are intended primarily for the distributed, open systems world in which application servers broker the Web services. The hardware platform, however, hardly matters. “z/OS is a great place to host Web services,” Rhys-Jenkins said. Although Web services often are written in Java, they can just as easily be written in COBOL. The only requirement is that they conform to the few standard interfaces: HyperText Transport Protocol (HTTP) for transport over the network, Simple Object Access Protocol (SOAP) as the message protocol, and XML as the data format.

Web services lie at the core of the services-based architecture where application functionality is made available as a service. To do their jobs, other applications will request the service, and a service may request services from other applications. An application can consist entirely of service requests. Intended for system-to-system interaction, Web services enable the application to invoke specific functionality simply by sending a standard service request — no custom coding or plumbing are required. The key is using a standard request and interface.

“With Web services, you can extend mainframe functionality, allowing it to be accessed by other systems, even a browser,” according to John Kiger, director of Web services strategy at BEA Systems. Early Web services adopters turned to the technology for fast, flexible application integration behind the corporate firewall. Mainframe and distributed open system applications could request processing and exchange data through a few basic protocols, effectively integrating the applications.


The payback from Web services is faster, easier, and therefore, lower cost integration and interoperability, Baroudi noted. It allows organizations to effectively leverage the functionality they have built into their existing applications, especially their extensive portfolios of mainframe applications, for new and innovative uses.

For example, the NASCO Web services infrastructure enables new products to be created and integrated quickly with its back-end claims processing system. This makes it possible for NASCO to help customers such as Blue Cross/Blue Shield better serve their own members’ needs while reducing the demands on their plans’ administrative personnel. The Web services, running on a mix of Unix and zSeries servers, save valuable time for both plan members and plan administrators.

At the Bekins Co., Web services allow the company to broker lower-margin shipping opportunities, enabling agents to view tenders by selected categories and register their acceptance of a tender immediately. For the shipper — Bekins’ customer — this means faster response to its shipping requests.

Web services enable MeadWestvaco to provide Web-based order entry and real-time access to information on product availability, customer-specific pricing, production schedules, product reservations, and order status. Through Web services, which directly link to the company’s back-end systems running on S/390 and AS/400 platforms, MeadWestvaco customers can view bills of lading, production documents, and invoices online.

What gives Web services technology an advantage over the other API-based technologies that preceded it is its reliance on a few basic protocols — HTTP, XML, and SOAP. There are a few more basic protocols, such as Universal Description, Discovery, and Integration (UDDI) and Web Services Description Language (WSDL), but they aren’t required. Using standard interfaces and standard networking, Web services are simpler to build and to deploy than proprietary API-based applications.

In a services environment, the service is requested and performed, and data is exchanged without having to program a link based on the particulars of the individual systems involved. “Web services is really about getting heterogeneous systems to communicate and interoperate,” Baroudi explained. Instead of painstakingly coding a connection between two systems and then recoding it every time something changes, the system simply presents (exposes) its standard Web service interface.

In addition, Web services are very reusable. Unlike objects, which are extremely granular and obscure, Web services deliver recognizable business tasks as large-grained functional pieces, making them easy to identify and to reuse with other applications. An inventory service, for example, can be built once and used unmodified with every application that needs inventory information or needs to update the inventory.


Although the technology first appeared in the open systems, distributed computing world, Web services work equally well with the mainframe. “There are a number of ways to expose mainframe applications to Web services,” according to Ian Schmidt, vice president, IONA Inc. Probably the simplest way is to add a middleware component in front of the mainframe. This component will take Web services requests, translate them into proper mainframe application-specific requests, and translate the returning results into standard Web services protocols.

A variation of this approach focuses on CICS. The ability to pull CICS into the Web services game is critical if Web services are to gain traction with the mainframe. Again, a middleware layer translates the Web services request into a CICS request and passes it on to the mainframe for standard CICS processing.

IBM appears ready to simplify this approach. It recently previewed SOAP software for the mainframe. According to initial published reports, this software allows existing CICS COBOL applications to be invoked as services through SOAP requests via either HTTP or WebSphere MQ messages. The result: You can trigger COBOL and PL/1 programs directly through SOAP messages, effectively bypassing the need for middleware.

IONA, too, recently introduced software, Orbix ASP Mainframe Edition v5.1, to enable companies to use mainframe applications as part of a services strategy. A full-featured mainframe integration solution, Orbix Mainframe allows mainframe engineers to expose mainframe functionality as services that can readily work with other mainframe- and non-mainframe-based business systems and applications. “In a services architecture, once you define the service interface, it is very reusable,” Schmidt explained. The trick lies in identifying chunks of mainframe functionality suitable as a Web service — pieces big enough to perform a recognizable business task — and encapsulating that functionality behind a well-defined service interface, specifically a Web services interface that uses SOAP for the message and XML for the data.

For example, IONA notes that GAD, a leading German banking services com technology to enable pieces of its existing mainframe systems to support new and different business initiatives as services. The company credits the effort with producing fast results and delivering an immediate and tangible return on investment.

BEA Systems also offers a middleware approach to mainframe Web services. In this case, BEA’s WebLogic application server initiates and fulfills Web services requests for an assortment of applications. WebLogic runs on a variety of platforms, including IBM S/390 and zSeries systems.

Similarly, WebSphere, IBM’s application server, sits at the heart of its Web services strategy. WebSphere acts as middleware, invoking and brokering Web services in response to the needs of applications distributed through the organization. The mainframe version of WebSphere supports XML, UDDI, and SOAP, making the mainframe a fully capable Web services player. According to published reports, in the upcoming release of WebSphere, IBM promises an open-source SOAP parser that will boost Web services request performance by a factor of four to five. In addition, the upcoming release will support Web Services Invocation Framework, an IBM technology that enables Web services to be deployed over networking protocols such as CORBA Internet Inter-ORB Protocol (IIOP), MQSeries, and Java Message Service (JMS).

“You don’t need WebSphere or any application server to turn CICS applications into Web services,” Rhys-Jenkins said. All that is required is the ability to write or generate SOAP messages and deliver them to CICS. In fact, COBOL programmers can write Web services as easily as Java or C++ developers. “All they need is a mini SOAP parser, which itself is pretty straightforward to write,” he noted.

Rather than WebSphere, Rhys-Jenkins’ preferred environment for Web services on the mainframe is M Q S e r i e s , n o w u n d e r t h e WebSphere umbrella. In other situations, he might take advantage of the CICS 3270 Bridge. In any event, according to him, a lot of activity on the mainframe goes away when you expose functionality as Web services. “IMS also can be exposed as a Web service and invoked through WebSphere MQ,” he added.

The decision facing mainframe managers today is not whether to deploy Web services, but where and how. The benefits in terms of simplified development, reuse, integration ease, responsiveness, and flexibility heavily favor the services-based approach, and software vendors already have begun to build Web services capabilities into their products. However, security remains an unresolved issue, so organizations clearly should be careful about deploying Web services outside the corporate firewall. Beyond that caution, Rhys-Jenkins recommends picking something simple to get started. “You don’t have to start with the most critical applications,” he said. That still leaves many less-critical applications to benefit from services on the mainframe. Z