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)
|
|
|
Content Negotiation (candidate)
|
Home > Candidate Patterns List > Content Negotiation
|
|
How can services support old and new service consumers or consumers with differing requirements without changing the service contract?
|
|
|
|
|
|
Problem
Media types accepted or returned by service capabilities can evolve over time. If these changes are backwards-compatible, the changes can be accommodated easily. However, if the change is incompatible then a new variant of each capability needs to be introduced to support consumers of old and new versions simultaneously. More generally there may be requirements to return different content to different types of consumer, or to work around problems encountered in specific consumer implementations.
|
|
|
Solution
The media type and specific content to be accepted or returned by a service capability is negotiated as part of its invocation.
|
|
|
Application
Media type and schema references are decoupled from the service capabilities that use them. Capabilities are modified to negotiate and select the media type to use at run-time from the set allowed by the contract. Media types are still kept to a defined, centralized set but are able to evolve separately to the set of capabilities.
Different types of consumers of the same age can be accommodated by including information about the consumer as part of requests.
|
|
|
|
Impacts
Media types and schemas can evolve more freely than if they had been referred to directly by service capabilities.
Old versions of media types continue to be understood by new service providers and consumers. Legacy media types can be difficult to retire and may increase the governance burden of the inventory.
|
|
|
|
|
|
|
|
Status
Under Review
|
|
|
|
Contributors
Balasubramanian, Carlyle, Pautasso
|
|
|
|
| |
Incorporating content negotiation into the service contract allows a service to be compatible with old and new consumers without introducing new service capabilities to its contract.
The envelope combining a media type identifier, a block of data, and associated meta-data elements is called a "representation" in REST. This generic parcel of data remains the same, even as new media types are introduced to the service inventory. This permits generic components to deal with the data in various ways without having to have any deep understanding of the media type semantics. For example, caches can be introduced within the service inventory without needing to be aware of the specific media types in use.
|
|
|
