Related Links

Web Seminars

Rob would like to thank Brian Anderson, director of product management, GT Software, for his contribution to this month’s column.

Over the past five years, there has been significant discussion in the marketplace regarding mainframe Web services. Mainframe Web services have been a major force in eliminating old stereotypes regarding the demise of the mainframe. Media pundits and industry analysts are no longer talking about a diminished role, in the future, for the mainframe platform. IBM and independent software vendors helped shape a new role for the mainframe in enterprise computing. Where the mainframe was previously locked away in the ivory towers of the enterprise data center, it is now at the forefront of the services revolution. Simply put, the mainframe is the driving force for service-oriented architecture (SOA) projects around the globe.

Enterprises with significant investments in mainframe computing - both hardware and applications - will immediately benefit from service-enabling their mainframe. The 40 years of work and effort tied up in thousands of mainframe applications have become accessible to the rest of an organization’s architecture. The mainframe now seamlessly integrates with Windows and Web-based applications. These diverse technologies can interact and feed off of one another in a symbiotic relationship, which maximizes value for the enterprise and builds a competitive advantage against less nimble companies.

The advent of SOA to mainframe enterprises has not been without concern. Experienced mainframe executives and technical managers have voiced several concerns. There’s always the skills gap issue – The question of how to reuse the existing common business-oriented language (COBOL) and Assembler talent that has been the core of IT staff. Will they be able to make the transition to services? Will the tooling facilitate this change? A bigger issue for mainframe management is how to maintain current performance and service levels that application users are accustomed to. How will security be addressed outside of the protection of mainframe resources access control facility (RACF) or top secret? In a services environment, it is not enough to simply “Web service enable” a transaction.

As mainframes take center stage in one’s SOA, it is critical that a business unit of work is exposed at the proper level of granularity from the mainframe, possibly spanning multiple subsystems. How is this accomplished? How is it possible to expose business logic, application logic and data that more than likely will cross multiple systems - CICS, IMS, DB2, VSAM and even technologies like CA-IDMS or Natural? A skilled programmer could expose functionality from different subsystems by hand. But, manually identifying and attempting to build business services is a tedious, time-consuming effort fraught with risks. This approach adds complexity and increases the risks of not delivering the right granularity service required. The only way to accomplish this is with the right tooling. It’s essential to expose what is known as a “composite service.” This facilitates rapid response to business change – the goal of every organization.

So, what is a composite service? My favorite description of composite services is from Roger Sippl, the founder of Informix software and co-founder of The Vantive Corporation. Sippl described composite services as “a transactional application consisting of business functionality and information from varied information sources. Composite applications are both a form of integration and application development. They are designed to support a company's business processes and map them to underlying information resources.”¹

Unlike simply service-enabling underlying transactions, composite services allow the development of business services that encompass mainframe transaction, data and application logic. Too often, developers on the mainframe side identify nine or 10 transactions and decide to wrap them as Web services, throw them over the wall and see if anyone will use them. Instead of this scattered approach, I suggest always starting by identifying the underlying requirements. Ask key questions: What are we trying to accomplish? Who is the intended audience? Is this an internal or external application?

For example, let's say I'm putting up a portal where people retrieve their financial details, including their credit history. The mainframe developer needs to create a service that might be called “get customer info” and, in most enterprises with legacy systems, a composite service would be the best way to go. Perhaps the salient details are found in two transactions. To get those transactions, you need to go through 10 green screens, make three database calls and send a Web service off to the credit bureau to get your rating. All of that should be done with a single service call and orchestrated together.