SOA Patterns > REST-inspired Patterns > Reusable Contract
Reusable Contract (Balasubramanian, Carlyle, Pautasso)
How can multi-purpose service logic be made effectively consumable and composable? How can service consumers compose services without having to couple themselves to service-specific contracts?
Problem
To access a service capability of a service with a service-specific contract, the service consumer must be designed to couple itself to the service contract. When the service contract changes, the service consumer is no longer functional. To access a new version of the service contract or to access other service contracts in order to compose other services the service consumer must be subjected to additional development cycles, thereby adding incurring time, effort, and expense.
Solution
Limit tight coupling to a common, reusable technical contract that is shared by multiple services. The technical contract provides only generic, high-level functions that are less likely to be impacted when service logic changes.
Application
A reusable service contract can provide abstract and agnostic data exchange methods, none of which are related to a specific business function. Methods within a reusable contract are typically focused on types of information rather than on the business context of the information.
Whatever context is established by a reusable contract method reappears within and forms part of an individual service capability. A service consumer selects the correct capability at runtime and this selection provides the business context for the invocation of the reusable contract method.
HTTP provides a reusable contract via common methods, such as GET, PUT, and UPDATE, which allow consumer programs to access Web-based resources by further providing resource identifiers. The combination of the resource identifier and the HTTP method can comprise a service capability.
A reusable contract can also be created using a centralized WSDL definition, as long as the operations defined are sufficiently generic.
Impacts
Sharing the same contract across services increases the importance of getting the contract right both initially, and over the contract lifetime. Reusable contracts can therefore require increased governance effort compared to service-specific contracts.
The reusable contract may still need to change if new services with new high-level data exchange requirements are introduced into the service inventory.
The reusable contract can lack sufficient metadata to effectively enable a service to be discovered. Service-specific metadata may need to be maintained separately from the reusable contract definition to ensure that service consumers are able to select the correct service capability with which to interact.
Principles
Standardized Service Contract, Service Loose Coupling, Service Abstraction, Service Reusability, Service Discoverability, Service Composability
Architecture
Inventory, Composition, Service
This page contains excerpts from:
SOA with REST: Principles, Patterns & Constraints
by Raj Balasubramanian, Benjamin Carlyle, Thomas Erl, Cesare Pautasso
(ISBN: 0137012510, Hardcover, 400+ pages)
For more information about this book, visit www.arcitura.com/books.