Pattern 07: Service-enable Non-service-oriented Legacy
Enable service-oriented systems to access existing functionality.
Relationships
Main Description

Context

SOA is a relatively new way of building software systems. All enterprises have a large amount of legacy systems, application, or solutions that are not service-oriented (SO).

Problem

There is no clear way to achieve effective application or method level integration with non-SO legacy.

Forces

  • The communication technology options for integrating with these systems can differ wildly, and using these technologies requires specialist development skills.
  • Building point-to-point integrations with these systems from each of the service components that have to integrate with them is inefficient because integration code is duplicated.

Solution

Service-enable non-SO legacy using a special kind of service-Integration services.  Integration services are specified using the same kind of artifacts as other services. However:

  • The service specification for an integration service needs to be a service-based interpretation of a distinguishable interface (or similar) that exists on the non-SO system.
  • This interpretation needs to be as literal as possible. It should be as similar to the existing interface as is possible.
  • The implementation of the integration service uses an appropriate communication technology to talk to the non-SO system (for example, CICS). This is hidden from consumers of the service who only have to deal with the service using the standard service communications technology in use.
  • Position these integration services in the Operational Systems layer of the SOA Solution Stack reference architecture.  These integration services are called from atomic services in the Services layer of that reference architecture.
  • The data owned by the non-SO system needs to be owned by an atomic business application service provider. This means that the integration service itself becomes part of the implementation of the atomic business application service provider that owns its data

Rationale

Wrapping non-SO legacy using integration services allows us to:

  • Isolate the areas in our software that are implemented using the kind of specialist communication technologies required to integrate with non-SO systems. Even if these technologies are not specialist as such, most are different from the ones used to communicate inside your service architecture between your service consumers and providers.
  • Define clear reuse points for integration logic.

Important Note

This pattern only talks about one way of "service-enabling" non "service-oriented" legacy: Using integration services. There are other patterns and techniques to go about this, such as Enterprise Service Bus (ESB) architectural patterns and enterprise modernization techniques.

More Information