SOA: Refactoring Mainframe Applications into Dynamic Web Applications, Part 1 : Page 2

The Integration Tier
The integration tier defines objects, components, and adapters that allow easy integration with enterprise information systems. The J2EE Connector Architecture lets mainframe system vendors and other Enterprise Information Systems (EIS) vendors develop resource adapters that can be deployed in any application server or framework supporting the J2EE Platform Specification, Version 1.3 and above. The J2EE Connector Architecture is centered on resource adapters. A resource adapter serves as the intermediary between the calling component and an EIS. Resource adapters expose native EIS components, routines, applications, etc. to the Java environment, letting an EIS plug into any framework or platform that supports the connector architecture. Resource adapters must adhere to guidelines defined by the connector architecture, called system-level contracts.

System-level contracts define standard functions that the J2EE application server or platform will handle. There are three major categories of system-level contracts:

Figure 2. The J2EE Connector Architecture Relationships: The figure shows the relationships between components in the J2EE Connector Architecture.

• Connection management—Allows applications to connect to an EIS.
• Transaction management—Allows the environment to manage and perform transactional access across EIS resource managers.
• Security—Provides support for secure access to the EIS.

The diagram in Figure 2 illustrates the relationships between components in the J2EE Connector Architecture.

Author's Note: You can find more information about resource adapters at Sun.

Integrating with Legacy Mainframe Systems
Typical mainframe systems expose information using a two-tier architecture consisting of dumb terminals that present the results of business logic executed by the mainframe. Most conventional integration efforts revolve around screen-scraping. Screen-scraping software electronically "reads" the information from a mainframe terminal screen, letting businesses replace hard-wired terminal interfaces with Web-enabled thin clients. However, that form of integration refactoring affects the presentation only, it doesn't help expose business logic in a form that can be easily reused and/or represented in different ways. A better way is to let the presentation tier handle application-specific UI generation and the business tier factor the legacy routines into logical business services.

Figure 3. Adapter and Mainframe Routine Relationships: As the figure shows, each adaptor may encapsulate multiple routines.

The first step in refactoring a legacy mainframe system is to separate the presentation logic from the business logic. You can refactor a COBOL system into special kinds of modules known as "service programs" to separate presentation logic from business logic.

The next step is to build resource adapters defining coarse-grained interfaces that encapsulate the desired business logic residing within the service programs or other accessible routines. As shown in Figure 3, a typical adapter implementation encapsulates a number of routines, depending on the desired functionality for the adapter:

Typically, you'd refactor a legacy mainframe system in several steps, as the need arises, allowing the system to evolve and improve naturally—and avoiding many potential mistakes that often arise in a wholesale refactoring effort.

Previous Page

Next Page

---

• Download The Code for this Article

---