IT Management

Gateways allow you to get an application into the Web services mix, but screen scraping creates performance bottlenecks and multiple points of failure between the legacy application and the Web service. For this reason, gateways are probably best for short-term projects, either as a transition to using adapters or as a stopgap measure during application reengineering or platform migration.

Figure 6 shows the basic model for accessing legacy applications indirectly using a gateway technology such as a screen scraper.

Again, the diagram in Figure 6 illustrates a Web services architecture: a Provider that supplies the Web service, a Requester that uses a Web service, and a Broker that finds Providers for Requesters. The legacy application itself is not a Web service, but is accessed by an off-host Provider. The following steps represent how to find and use a Web service gateway (steps 1 through 3 are optional):

  1. The Provider uploads a WSDL specification to publish its Web service with a Broker.
  2. The Requester (usually a Java or .NET application) queries the Broker for a Web service by name or category.
  3. The Broker selects a Provider and returns the Provider information to the Requester.
  4. The Requester uses the information from the Broker to format and send a SOAP message to the Provider.
  5. The Provider starts an emulation session and conducts a series of transactions with the legacy application to collect the requested data.
  6. The Provider converts the legacy datastream into an appropriate format and returns a SOAP/XML response to the Requester with the legacy application data enclosed.

Dynamic Adapters vs. Code Generators

As we have seen, adapters provide several advantages over gateways when it comes to Web services integration. How those adapters operate can be just as important. Products that implement the adapter model for Web services usually fall into two camps: those that use code generation and those that are dynamic. Code generators have been around for some time and require developers to adhere to a fairly structured process. In the case of CICS applications, a scenario similar to the following occurs:

  1. Download program source code, copybook or screen maps to workstation running proprietary tool.
  2. Use a proprietary tool to generate Web services wrapper code.
  3. Upload generated code to mainframe.
  4. Compile, install and test generated code.
  5. Repeat process for each program and whenever the programs change.

While generated adapters can jumpstart the initial development process, they create several maintenance problems. First, the integration developer is generating code off the host and uploading the code to the mainframe. In most cases, this developer will know a lot about Web services and XML, but will know little about the mainframe. Thus, any changes to the mainframe application require coordination between the Web developer, the application developer, and the CICS administrator. Second, generated adapters create “net new code” that must be managed. Changes to either the legacy application or to the Web service will require repetition of the code generation process to keep the generated code in sync with the integrated application. Without proper management, you are likely to drown in a sea of generated code.

These issues led to the development of dynamic adapters. Dynamic adapters operate with little or no configuration, and changes to legacy applications are automatically incorporated into the SOAP/XML output. In many cases, there is no configuration required, while some cases may require a single-step process to specify Web service information for each application. As a result, there is no generated code and there is a clear division of labor: The CICS administrator installs the adapter and the Web developer simply invokes the adapter as a Web service.


As we have seen, one problem with traditional integration techniques is the proliferation of point-to-point communication and data conversions that must change as new applications are integrated or data formats change. The problem quickly becomes complicated when you add business partners, subsidiaries, mergers or acquisitions into the integration mix. Web services reduce the costs and complexities of integrating applications. By using standards-based technologies and widely available skillsets, Web services allow companies to develop flexible integration solutions that can evolve as their needs change.

The subsystem under which your legacy application runs determines your top-level integration choices. IMS provides limited facilities to create integration adapters, so IMS shops are often relegated to using screen scrapers and gateways. CICS Transaction Server includes facilities that allow third-party vendors to create adapters that can immediately enable legacy applications as Web services. These facilities also provide additional benefits over gateways, such as improved performance and increased stability vs. their screen scraping counterparts. By using the same industry standard technologies as Web services, some adapters make it possible for applications to transparently invoke CICS transactions within a Web services architecture and receive the resulting data as well-formed XML. For organizations that want to retain the value of their CICS applications, the combination of XML-enabling adapters and Web services offers a practical and powerful integration solution.

Web services are not a trend, but an industry-wide movement that can provide a long-term solution for companies that want to integrate legacy applications and data with new e-business processes. In the end, companies need to assess the value of the data contained in their legacy applications. Most companies have already determined that such data is highly valuable and they are looking for ways to preserve their investments. Given that recent surveys show the top strategic priorities of CIOs and CTOs is integrating systems and processes, the use of Web services will grow rapidly and you need to be ready for them.

5 Pages