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)
|
|
|
Uniform Contract (candidate)
|
Home > Candidate Patterns List > Uniform Contract
|
|
How can a service composition be reconfigured at run-time to take advantage of evolving alternative service endpoints?
|
|
|
|
|
Problem
Accessing services that provide variations of similar functionality requires a service consumer to invoke capabilities expressed in individual service contracts. Composition arrangements are unnecessarily rigid at run-time. As this set of alternative services evolves, the consumer needs ongoing modification to be kept up to date with the changing set of individual contracts.
|
|
|
Solution
Develop a uniform technical contract across the alternative endpoints that is abstract enough to express the capabilities of the individual alternative services. Endpoints either use the uniform contract directly or extend upon it.
|
|
|
Application
Alternative service endpoints conform to or extend a common reusable uniform technical contract. Other aspects of the contract may also be uniform, or may be negotiated at run-time through contract methods and operations. Service consumers avoid design-time coupling to a specific service and send messages at runtime conforming to the uniform contract. The service endpoint is selected an may be discovered at runtime.
|
|
|
|
Impacts
Sharing the same contract across several services increases the importance of getting the contract right both initially, and over the contract lifetime. Governance effort required over the uniform contract is increased compared to service-specific contracts, however fewer contracts are required overall.
Due to its generality, the uniform contract may lack sufficient meta-data to effectively discover and exploit a given service. Service-specific meta-data may need to be maintained separately from the uniform contract definition.
|
|
|
|
|
|
|
|
Status
Under Review
|
|
|
|
Contributors
Raj Balasubramanian, Jim Webber, Thomas Erl, David Booth
|
|
|
|
| |
Exposing a uniform technical contract between service endpoints allows a service consumer to select a specific variant at run-time. A composition controller can be passed a service endpoint identifier as part of its own capability invocations, and makes use of the uniform contract to compose request messages to existing and to new alternative services.
|
|
|
|
|
