It is worth noting that in many cases, noninvasive modernization techniques are sufficient. However, a legacy system is not always well-suited for integration. It is not just a matter of adding an interface; in many cases, a large-scale transformation may be required. For example, the presentation logic is often intertwined and tightly coupled to the business logic, which makes it harder to create a service interface without refactoring. Another example is when the system uses an Online Entry/Batch Update pattern, in which an online inquiry and update program is used to capture data in a local database replica for subsequent batch update to the master database. Adding a straightforward service interface to the online program cannot provide a synchronous update to the master database. A transformation such as eliminating the local replica database and changing the online program to directly access the master database may be required.

Figure 3 shows a generic architectural model based on SOA that may be used to tackle legacy systems. In this architecture, legacy systems are exposed to other business applications using service wrappers that leverage a tool to perform the mapping between Web services and the native mainframe platform. This type of architecture may be used in the future to migrate away from the native legacy platform without adversely impacting other applications. The advantage of this model is that legacy applications may be rationalized based on the business use cases and exposed as coarse services that encapsulate specific legacy programs. The tools will handle the complexity of communicating the legacy platform and performing the transformation. Therefore, consumer applications, whether they are in J2EE or .NET technologies, only need to deal with SOAP and XML Schema.

Web Service-Based Legacy Enablement Using NEON Systems Shadow z/Services
As organizations move toward SOA, it becomes necessary for the mainframe applications to communicate with the entire enterprise. This can be achieved using the various mainframe Web service-enablement tools that are available such as NEON's Shadow z/Services, GT Software's Ivory, WRQ's Verastream, and Jacada. These tools offer an easy way of exposing mainframe CICS, IMS, and IDMS applications as Web services without writing any program code. These tools will enable the development of a complete Web services architecture that allows legacy mainframe application to communicate seamlessly with open system platforms such as Java or .NET. These tools typically have both resident mainframe program-server components and client-side components (see Figure 4).

NEON's Shadow technology provides a robust technical architecture to support the broad range of customer requirements for mainframe integration. Serving as both a development platform and a run-time environment for legacy integration, Shadow z/Services enables service-oriented development of applications by allowing enterprise developers to wrap existing legacy programs and transactions into ready-to-use .NET, Java, or COBOL components, as well as Web services. Shadow z/Services also provides bidirectional Web services support, not only with regard to publishing legacy transactions as Web services, but also for allowing mainframe programs to actually consume Web services. The Shadow z/Services development process is designed for ease of use - enabling developers to rapidly create enterprise components or Web services. The tool requires no prior knowledge of either the legacy system or of service-oriented development architectures. Shadow z/Services for CICS is the only run-time server in the marketplace that deploys natively on the mainframe within a CICS region. In NEON's Shadow z/Services, mainframe integration can be achieved using two major approaches: SLI (screen logic integration) or BLI (business logic integration). The SLI approach is also known as the FEPI (front-end programming interface) recording-based approach, whereas BLI is also known as the parsing-based approach.

FEPI is used as an API to access the CICS transactions on the mainframe. Shadow z/Services simulate a normal CICS terminal, which allows running a transaction or series of screens from the IDE. The FEPI interface performs the recording and playback of these screens. The next step requires identifying the input and output fields, because this approach simulates screen scraping to transform the application into a Web service.

The BLI parsing-based approach differs from the SLI in that it allows the user to import the COBOL file and define the input and output fields. In both the cases a WSDL file is generated that controls the invocation.

GT Software's Ivory is another mainframe integration tool that contains a studio and a server. The Ivory studio provides users with an environment that contains a drag-and-drop graphical modeler. It allows the user to represent the entire business logic in the form of a flow diagram. Like Shadow z/Services, Ivory requires no prior knowledge of the legacy system or SOA. The Ivory server processes the server instructions that are XML representations of the graphical data flow deployed on the server.

JCA-Based Enablement
Organizations that have an exclusive J2EE-based architecture and do not wish to use Web services for integration with legacy platforms may use JCA adaptors for integration. JCA (Java Connectivity Adapters) can be used for bidirectional communication between front-end Web-enabled applications and legacy components (such as mainframe-based applications). Since most of the business logic is already implemented on legacy components, all we need to do is use these applications from a Web-based front end to implement the business logic (see Figure 5). There are many vendor implementations for JCA to connect to different legacy components from different front ends. For example JAM (from Iway) provides communications between WebLogic-based Java applications and mainframe applications. This helps in reusing the existing code. For the Java developer it is almost like calling any other Java class, being unaware of the background implementation. The adapters have to be configured according to application before they can be used. These adapters have two components:

• A back-end component that lies on the back-end legacy system
• A front-end component that lies on the front-end application server

Back-End Component
The back-end component is installed on the legacy system. The specific product installation guide can be used for this purpose. Each product has a different installation, depending upon the legacy server application. It has to be configured to interact with legacy applications. Depending upon the requirements, we need to configure the adapter only for those applications that can be used by the front end. Once the adapter is configured to interact with a particular application, it can be called from the front end.

This component has two distinct functions:

• To send/receive request/response to/from the front-end component
• To send/receive request/response to/from the legacy applications

The back-end component has the responsibility of receiving a request from the front end through some network protocol and creating a request that can be understood by the legacy application (this is achieved during configuration), and receiving the response. Once it receives the response, it has to convert it into a message that is understood by the front-end component and send it back to the front-end component.

Front-End Component
The front-end component lies on the application server that hosts the Web-based components. It has to be configured to connect to the back-end component that is installed on the legacy system. The configuration parameters also depend on the configurations of the adapter's component on the legacy. Once the installation is complete, it is similar to calling another class. Every adapter provides an interface that can be invoked to use the legacy application. Once such a call is made, the adapter packs the message and sends it to the back-end component on the legacy system. After the processing of the message the response is again demarshaled and returned as an object to the calling class, so it completely encapsulates the complexity involved in creating a call to legacy.