Legacy system modernization
Over time, large organizations in many industries develop large and potentially complex IT systems. The challenge for many companies is how to adopt these new opportunities while leveraging prior investments in existing infrastructure components. Some examples include iSeries Mainframes, EDI messaging standards, custom integration scripts, or flat file interfaces over legacy transports such as FTP or file-based interactions.
Implementation
There has been much written on this topic under the heading of “Service Oriented Architecture” (SOA), but even SOA doesn't fully address the need to have a communication layer in place. This communication layer is responsible for exposing legacy systems with their legacy data formats and legacy transport protocols to new consumers.
SOAP Web services
Provides a well-defined and loosely coupled service interface to a file-based mainframe application.
XSLT data transformation
Converts the SOAP/XML request into a format consumable by the mainframe system.
File endpoint
This is the communication channel to the mainframe system.
Integration core principles
An ESB implementation for a legacy modernization use case typically involves the following:
| Orchestration | Composing several fine grained legacy components into a single higher order composite service. This can be done to achieve appropriate granularity of services and promote reuse and manageability of the underlying components. |
|---|---|
| Data transformation | Transformation between legacy data formats and standards-based data formats. An example of this would be transforming between CSV, Cobol copybook or EDI formats to either SOAP/XML or JSON. |
| Transport protocol negotiation | Transport protocol negotiation between legacy transports such as file-based applications, FTP, traditional email (SMTP) or proprietary messaging formats and contemporary Internet-based HTTP protocols. |
| Mediation | Providing support for multiple interfaces for the purpose of a) supporting multiple versions of a service for backwards compatibility, or alternatively b) to allow for multiple channels to the same underlying component implementation. This second requirement may involve providing multiple interfaces to the same component, one legacy interface (flat file) and one standards compliant (SOAP/XML) interface. |
| Non-functional consistency | In legacy modernization projects this can involve providing a new secure channel (including authentication and authorization) for external consumers of legacy components that were originally designed with only internal consumers in mind. |
Mule integration components
In the following example, an existing component reads files that are placed in a particular directory where each file is composed of fixed length records and we want to expose that application as a SOAP-based Web service.
Legacy Modernization - Web service wrapper for file-based service in Mule
Summary
If we look at what we've achieved here in relation to our original objective, we've been able to leverage our investment in an existing system by taking a file-based application unchanged and exposing it as a Web service.
This design furthermore promotes loose coupling since consumers are now interfacing with Mule instead of invoking the component directly. In this way, Mule dramatically simplifies the process of on-boarding additional requirements around transformations, transports, orchestrations, service mediation, and even non-functional requirements based upon the integration principles outlined above.
