Mainframe applications continue to govern and automate core business processes of many of the world’s largest organizations. These systems have evolved and proven highly dependable in supporting immense processing demands. However, as line-of-business groups demand more operational flexibility, it falls to the development team to adapt and integrate their mainframe applications with other computing environments. For instance, the organization may require a system to allow clients to seamlessly pass information from a browser-based front-end through to the mainframe for processing.
Service-Oriented Architecture (SOA) has been increasingly viewed as the best approach to reuse mainframe-based processes and expose them for integration. With its broad acceptance, SOA offers a path to integrate a single company’s applications as well as heterogeneous applications built in various environments by different companies.
While new applications can be readily developed to be “SOA-ready,” the question remains of how to bring legacy applications into the SOA world. The first choice you must make is between enabling and re-writing. A re-write is an opportunity to modernize the application, improving performance and flexibility. However, it may not be economically feasible to replicate a large production application representing a multi-million dollar investment. Enabling the legacy application to run in an SOA architecture can be a more affordable option that preserves prior investments.
The most common method of SOA enabling is to employ “wrappers,” which permit communication with legacy components and expose their functionality as Web Services. Many vendors and in-house development teams have developed wrapping technologies to extend the reach of mainframe-based processes. While some SOA infrastructure vendors offer basic connectivity software that makes the exposure of mainframe services to the outside world possible, others offer sophisticated tools to help define and build the services. Three effective wrapping methods are:
- Screen wrapping, which allows for the creation of services that communicate with legacy applications via their User Interfaces (UIs). The external application and users see a Web Service that’s actually a collection of programs that receive screens from or send screens to the legacy application. From the legacy application’s perspective, users appear to behave as normal users.
- Commarea wrapping, which creates services that communicate directly with existing programs, but not via UIs. From the legacy application’s perspective, the wrapped programs are called in the same way as when the application is used in its native environment. The supporting infrastructure understands which components are to be called and how to convert the program input/output into correctly formatted XML messages for consumption in an SOA architecture.
- Database wrapping, which creates basic services for read, update, insert or delete operations against database tables or files. Such services access the data and may be without any existing business logic.
Each of these methods has pros and cons, depending on the organization’s needs (see Figure 1). Some specific issues must be addressed to fully leverage the value of commarea wrapping as a solution for SOA enablement while avoiding unexpected mishaps. The primary challenge stems from the nature of mainframe applications. Because these applications typically weren’t developed with an SOA model in mind, they often contain architectural traps that can cause the services to be inefficient or even fail.
Clearing the Hurdles
In a typical SOA implementation, the issue of preparing a legacy application is often delayed. Projects generally begin by establishing an architectural framework that addresses the higher layers of the architecture while the lower layers, where legacy comes into play, are addressed last. However, the challenges of the legacy application’s architectural hurdles should be a priority. The development team should richly understand and prepare the targeted application to expose the correct component, in the correct fashion, as a service.
The first and most obvious hurdle is how to determine which programs encapsulate the functionality to be exposed as a service. For example, in a banking application, the development team may intend to expose a service that helps to open a new account. The application that contains this function may be quite large, containing hundreds or thousands of programs. Which of these programs implements the opening of an account? It’s not necessarily a simple exercise since the functionality may be spread over multiple programs and often lacks a single entry point to perform the operation. Moreover, some of the programs involved may operate for historical reasons with several parameters that are superfluous and would complicate the service. Also, access rights to the application are sometimes handled by the application itself. So, exposing a component to a direct invocation from outside its original environment may create a serious security exposure.
The magnitude of this first hurdle depends on the initial architecture of the legacy application. In some cases, architects have adhered to a strict layered architecture; in many other cases, the application grew organically without a clear demarcation of layers. A well-layered application would resemble Figure 2, where the programs of the second layer would offer the best candidates for exposure as Web Services.