Master SOA Design
Pattern Catalog
|
|
"Introducing SOA Design Patterns", SOA World Magazine (PDF)
"The Case for Single-Purpose Services: Understanding the Non-Agnostic Context and a Strategy for Implementation", SOA Magazine (HTML)
"REST-Inspired SOA Design Patterns", SOA Magazine (HTML)
"Service-Orientation and Object-Orientation Part I: A Comparison of Goals and Concepts", SOA Magazine (HTML)
"Service-Orientation and Object-Orientation Part II: A Comparison of Design Principles", SOA Magazine (HTML)
"Service Facade", InformIT (HTML)
"Non-Agnostic Context", InformIT (HTML)
"Domain Inventory", InformIT (HTML)
"Service Normalization", InformIT (HTML)
"Service Decomposition", InformIT (HTML)
"Canonical Schema", InformIT (HTML)
"Policy Centralization", InformIT (HTML)
|
|
|
Intermediary Contract (candidate)
|
Home > Candidate Patterns List > Intermediary Contract
|
|
How can a service consumer be presented with a broader or different range of connection options to a service provider than the set of options provided for by the (original) service contract?
|
|
|
|
Problem
A service provider (in particular the ultimate service provider) of a specific service usually offers a limited set of connection options in the published service contract for that specific service. If another service or application wants to consume that specific service it may not be able to consume that service using the published service contract (e.g. no suited protocol or data format available).
|
|
|
Solution
Use the capabilities of an intermediary to modify or extend the service contract to include connection options that allow service consumers to consume the service directly, that is without additional effort (preferably) or with less effort at their end. Publish this new contract as a separate contract, the Intermediary Contract; the corresponding intermediary service can then be directly consumed.
|
|
|
Application
Streamline an externally provided service for internal use, streamline a service in a domain inventory for use in another domain. Also, when appropriate, expose internal service streamlined to external consumers. In all cases, the (usually) ultimate service provider is abstracted away for the service consumer. Streamline here means (try to) adapt to the needs of the consumer.
|
|
|
|
Impacts
ncreasing the set of connection options increases the size and governance effort of the service contract. Modifying connection options requires additional processing capacity to bridge the differences (between what is provided by the ultimate provider to the intermediary service and what is offered by the intermediary service to the service consumer). Performance overhead is also induced by the inclusion of the intermediary service.
Requires an infrastructure (e.g. an ESB or Broker) that supports the capabilities needed to bridge the differences, in particular protocol bridging, data format transformation and data model transformation.
The service consumer must consume the intermediary service.
|
|
|
|
|
|
|
|
Status
In Development
|
|
|
|
Contributor
Baptist Eggen
|
|
|
|
| |
One of the goals of SOA is intrinsic interoperability. This goal is the better achievable the more control a party has over all the services that have to interoperate. However, a party usually has no control over the service contract of externally provided services or the way its own services are consumed externally, when made available to the outside world.
Forcing the bridging of differences behind the service contract, and exposing a service contract more in line with the requirements of a consumer of the exposed service may contribute again to intrinsic interoperability.
To bridge differences for the service consumer, this pattern essentially needs the Service Broker pattern (itself a compound pattern consisting of data model transformation, data format transformation and protocol bridging) to provide the basic capabilities to extend and/or modify the connection options to be made available to the service consumer. It also is supported by the ESB pattern (which itself as compound pattern encompasses the Service Broker pattern) for its actual implementation. In addition the ESB pattern can be used to influence SLA aspects as well as composability characteristics. Their effects will be made visible in the new contract as well.
This pattern is sort of orthogonal to the Concurrent Contracts pattern. The latter pattern can be considered as a separation of options from the perspective of the service provider, whereas the Intermediary Contract pattern is a combination of options to be presented to the service consumer in a single service contract.
It also relates in a fairly similar manner to the Service Façade pattern: the façade pattern focuses on shielding the implementation logic of a service (from the perspective of the service provider), while the Intermediary Contract pattern is concerned with the messaging logic and in particular exposing changes thereto (from the perspective of the consumer).
Furthermore, there is some commonality with the Decoupled Contract pattern, as far as this pattern and the Intermediary Contract pattern shield the service consumer from the service provider implementation details.
This difference between focus on implementation logic (e.g. service capabilities) and messaging logic is also what sets the Intermediary Contract pattern apart from the Inventory Endpoint pattern.
In a sense the core quality of this pattern is that it acknowledges the real world fact that not always standardization can be enforced, yet differences can be bridged and abstracted away to a certain extent.
Although it can be applied in its own right, the Intermediary Contract pattern will more frequently be applied in combination with, or more specifically repeatedly in support of, the Intermediary Inventory pattern.
|
|
|
