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.”1

 

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.

 

The alternative to the composite approach just described is to expose each individual transaction separately and attempt to orchestrate it all together off the mainframe to try and package a composite service. Even if the orchestration succeeds, you are still faced with a poor performing service with multiple points of failure.

 

Only composite services can deliver business value from mainframe assets. Composite services from the mainframe may even include Web services from external platforms. The key to success is identifying the true business service that is hidden beneath the green screen mainframe application. These business services must be understandable, not only to a COBOL developer, but to a business analyst and, more importantly, the end user of the service.

 

As SOA becomes more mature, the mainframe must continue to advance how it participates. Data services have become an important discussion point, but it is the composite service that truly engenders business value. With the right tooling and proper orchestration, mainframe developers can play a critical role in their enterprise’s SOA strategy. It’s important for the mainframe community to build and expose business services like they are doing elsewhere in the enterprise. Otherwise, they run the real risk of losing credibility with SOA architects and newer technology developers who don’t understand the mainframe and continue to stereotype the platform.

 

Simple Web services from a single transaction - whether application, business or data - are enough to show the promise of SOA. To truly deliver on those promises, orchestrating composite services from mainframe applications, transactions and data is required.

 

Reference:

  1. Colleen Frye. "The Role of Composite Applications in SOA." SearchWebServices.com, July 20, 2005.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access