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.
|