Tech Brief

Legacy Integration with SOA

Exposing mainframe resources with SOA within .NET.

• By John Billman
• 12/01/2007

With an estimated 200 billion lines of COBOL in production today, mainframe applications form the core of many financial and other services across the corporate world. These applications often encapsulate more than 20 years of business knowledge and embody the the distinctive competence of an organization.

By migrating to SOA, organizations can combine the value of proven business functionality with the agility of reusing services and the capabilities of .NET and other contemporary programming environments.

Building SOA from Mainframe Code
The first step in the migration to SOA can also be the most difficult -- you need to identify which parts of the app can, and indeed should, be exposed as reusable services. SOA enablement could, for example, follow an enterprise-wide assessment identifying systems for modernization; say, a business requirement for a new Web interface or an IT need for the integration of multiple systems across the enterprise.

For a non-mainframe programmer, it's easy to think of COBOL/CICS/IMS applications as monolithic, inaccessible entities. However, mainframe applications include a variety of interfaces such as CICS COMMAREA, BMS Screens, 3270 Workflow or IMS OTMA screen flows that provide distinct entry points into the existing application.

These interfaces are valuable, but not the complete story -- they represent the structure and design of the original application. To build a strategic SOA layer, it's critical not to just replicate legacy services, but to tailor and aggregate them in order to combine multiple transactions from the legacy system into the new business service.

Integrating .NET with Mainframe Services
There are a number of architectural choices for taking mainframe code into .NET. In many ways, perhaps the most obvious is an integration approach. Existing mainframe interfaces can be leveraged to build services. Those services can be deployed as SOAP-based Web services on a number of platforms, including .NET. The Web service runs under .NET (or the chosen application-server environment) but it accesses the existing back-end application, which remains unchanged and running on the mainframe (or, if preferred, migrated to Windows, Unix or Linux).

In many cases, this approach will provide the most pragmatic solution. It's very low risk to the existing applications and enables new applications written in .NET to simply consume the existing business functionality just like any other Web service.

[click image for larger view]

Many coders come from outside of the United States, where contest winnings can be substantially larger than the pay for typical programming work.

COBOL Inside .NET
The ability to port existing COBOL code -- including SQL or VSAM access code -- into .NET can provide a single development and deployment environment for COBOL, C# and VB.NET. COBOL running under .NET doesn't have to become object-oriented or event-driven, but it won't magically become service-oriented either.

The strength of COBOL as managed code is that it becomes a "first-class citizen" within .NET, with the same access to .NET Framework classes and features as other .NET languages. This means that exactly the same mechanisms can be used to build Web services in COBOL under .NET.

COBOL has direct access to .NET capabilities; yet at the same time, COBOL business logic, going as far back as the ANSI 68 COBOL standard, can be executed under .NET. It's this combination of proven business logic and new capability developed from the same Visual Studio IDE and built into the same project and solution that truly delivers the combination of reuse and agility.

Wrapping the Code
Both approaches -- integration and COBOL code inside .NET -- have a key common factor. In both cases, the code is wrapped, while the original business logic remains unchanged. With integration, the back-end application remains unchanged in every way. You're simply building a new interface into that application, and that new interface is essentially a layer into the existing CICS or IMS interfaces. However, using Web services enables you to transform this from a proprietary link to an open standards-based interface that can be consumed from .NET.

Taking COBOL code into .NET provides more options for architecting the app. The Web service itself is built using the System.Web.Service.classes exactly as it would be with C#, for example. This leaves two primary tasks: interfaces and data types. COBOL under .NET supports both equivalents of .NET data types and traditional COBOL data types (which will be used by the original business logic); therefore conversion between them is simple. Typically, the new service may invoke a small object COBOL interface layer that will call the original (procedural) business logic that's now running as managed code.

Whichever architecture is adopted, the core principle is clear. Existing mainframe code can be reused and extended to SOA, freeing up resources for new development while preserving long-proven business assets.