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.
USING WEB SERVICES ON THE MAINFRAME
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