ESB as a Strategy for SOA Migration

Practical considerations often dictate that an organization migrate to a service-oriented architecture in stages, rather than as a monolithic project. Usually, this requires that the service-oriented architecture serve as the scaffolding for progressive re-engineering of a legacy application as well as serving as the infrastructure for new applications and extensions.

One strategy that can meet this need is to use an Enterprise Service Bus (ESB) to implement the service-oriented architecture. Assuming the required capabilities in the ESB, an architect might approach the SOA migration in several general stages.

Situation Overview

Legacy applications are usually based on COBOL programs running on a mainframe such as the z-Series or iSeries. A control program (for example, CICS) drives the flow of online programs, while command scripts (for example, JECL or CL) drive the flow of batch programs. Data interfaces are implemented through a number of means, including direct use of protocol APIs, use of message middleware, and as web services. User interfaces are generally implemented as data terminal screens, although some systems use Visual Basic or even web application interfaces.

Service Enablement and Mediation

In the first phase, the architect chooses a suitable ESB platform and the team migrates existing web services to this platform. To break the migration into manageable chunks, the architect should probably choose a functional subset of the legacy application and the team should restructure the online programs in this subset to service enable them. If appropriate, the architect might choose a commercial integration adapter technology to service enable existing programs without re-engineering them. The service-enabled existing programs needed for the selected subset would be abstracted general application services resident in the ESB. The resulting web services, however derived, would be composed under process service and business service layers resident in the ESB.

Migration and Extension

In the second phase, the team migrates the user interfaces to a suitable web application platform and migrates the external interfaces to the ESB. Any application services needed for these migrations would be composited from existing programs service-enabled by means of the integration adapter. Where necessary to satisfy performance or functional requirements, existing programs would be re-engineered to be modular and directly service-enabled. New applications and extensions to existing applications should be implemented under the SOA platform, using redesigned data schemas wherever possible.

Reengineering

In the third phase, we would redesign the core data schemas of the application and re-engineer the systems dependent on those schemas behind the interface contract established at the application services layer.

Service Composition in the Enterprise Service Bus

An approach to constructing composite service-oriented applications by service-enabling existing programs will impose certain requirements on the infrastructure supporting the application. These requirements are part of the value proposition for an Enterprise Service Bus (ESB) and should be part of the architect's evaluation and proof-of-concept work for all ESB products.

• The ESB should provide process orchestration features
• The ESB should provide service discovery and metadata repository features
• The ESB should provide a performant and scalable runtime layer for the process, business entity and application services
• The ESB should provide quality-of-service features for the application services and service-enabled programs
• The ESB should provide transaction management features for the application services
• The ESB should readily integrate with infrastructure for connectivity and messaging between the application services and the service-enabled programs