The context
When an enterprise architecture moves towards a service-oriented architecture, it is often necessary to accommodate existing legacy systems that run large parts of the business, but that do not have a service capability. These applications often use functions that must be accessible to newer service-enabled software packages, but that offer access only through adapters, messaging, or other non-service-oriented integration techniques.
The problem
Legacy applications do not fit naturally into a service-oriented architecture (SOA) environment and changes to such systems are expensive and require scarce skills. The problem is to find a way of integrating such systems with newer service-oriented packages and applications. In particular, it is necessary to create a bridge between the synchronous HTTP protocol that is generally used with web services, and the messaging protocols that are often used by legacy applications.
Selection guidance
This pattern is appropriate when an enterprise wants to present a service interface to requesting clients as part of an SOA environment, but provider applications cannot easily be upgraded to provide service interfaces.
This pattern is used where provider applications provide an XML interface and client applications support calls to web services. The pattern can be extended with transforms to support a service facade to applications with non-XML interfaces over WebSphere MQ.