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 services share a common and standardized contract?
|
|
|
|
Problem
Custom contract design can be burdensome and risky when the contract content is subject to change.
|
|
|
Solution
A simple and highly generic contract is established and shared by a collection of services, thereby placing the design emphasis on the structure of the input and output message data.
|
|
|
Application
The most common implementation of this pattern is via a REST implementation that enables services to share the standard HTTP method contract provided by Web servers.
|
|
|
|
Impacts
Validation logic that is commonly located in the contract layer must now be moved into the core service logic, and an absence of customized contract content introduces a reliance on supplementary human-readable content in order to discover and understand available services.
|
|
|
|
|
|
|
|
Status
Under Review
|
|
|
|
Contributors
Raj Balasubramanian, Jim Webber, Thomas Erl, David Booth
|
|
|
|
| |
Problem
Designing customized service contracts that contain validation logic can lead to a variety of challenges:
|
•
|
Developers may be required to learn new technology languages.
|
|
•
|
The overall development effort of services increases due to the extra stage of having to custom build the contract content.
|
|
•
|
The contract design and validation logic can become outdated or can be subject to change, thereby risking dependencies formed on the contract by service consumers.
|
Furthermore, once changes to already-implemented service contracts are made, versioning responsibilities enter the picture, thereby increasing the governance burden of services.
Solution
An existing, pre-defined, and generic service contract is used by all services. This simplifies the overall service inventory architecture and alleviates service designers from having to create individual contracts for services. It further shifts the customization to the data being passed to and from the uniform service contract.
Application
The primary application option for this pattern is HTTP method interface provided by all Web servers. Using this generic and prevalent contract, HTTP listeners can receive messages containing one of a number of pre-specified method verbs, such as GET, PUT, POST, DELETE, and HEAD.
The notion of Uniform Contract is a core tenet of the REST architectural style and therefore, when applying this pattern using REST, services must support some or all of the possible HTTP methods:
|
•
|
GET method - performs a read-only function that requires the service to be in the same state after the function is completed
|
|
•
|
PUT method - creates new data or data records within the service using the content provided in the HTTP Body field
|
|
•
|
HEAD method - carries out an inquiry about a given service without providing the entire response data
|
|
•
|
DELETE method - removes a specific body of data
|
|
•
|
POST method - can be used to selectively modify or create new data records
|
NOTE: Although this pattern is most commonly associated with REST, it can theoretically be applied through other mediums. For example, a single canonical WSDL definition can be established by defining key Web service operations and using a generic XML schema for message types. However, it is debatable as to whether it makes sense to apply this pattern when working with Web services because it leads to a service contract architecture that does not leverage the intended richness of Web service technologies.
Impacts
Due to the simplicity of the multi-service contract established by this pattern, the richness of defining custom capabilities that semantically define related business tasks as desired by some service developers is lost. Because the single interface established by Uniform Contract is rigid, it can lead to
|
•
|
creative use of service definitions - by allocating service functionality to inappropriate operations
|
|
•
|
extensions of intended service operations - by creating variants of service operations from Uniform Contract (as illustrated by the invention of new verbs in the WebDAV protocol)
|
...both of which might undermine the goals of this pattern.
Case Study Example
Alleywood architects identify a set of services that will be published for use by external partners to facilitate simple reporting functions for statistical reports that are now only available as static content on their Web site. First, though, they decide to create a pilot implementation based on Uniform Contract.
They begin by documenting the specific characteristics of their planned service architectures, as follows:
|
•
|
The services can support some or all of the HTTP GET, PUT, POST and HEAD.
|
|
•
|
All services should send a HTTP Response 405 ˇ§Method Not Allowedˇ¨ if HTTP DELETE is invoked.
|
|
•
|
The services must implement the HTTP OPTIONS header to allow consumers to query the service for allowed methods.
|
Because they have an existing Java platform, they decide to standardize this new environment on the Restlet Java framework. They also publish a list of recommended frameworks that the external consumers can use to access these services.
|
|
|
