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
Expose the service capabilities via a common, reusable technical service contract that provides a set of abstract, multi-purpose methods that allow service-specific capability logic to be chosen at runtime. The service consumer can be designed to use a specific service capability or can discover the service capability at runtime. The reusable service contract defines only high-level data exchange requirements via each abstract method. This way, the logic that invokes the generic method does not need to be modified. |
|
|
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. |
|
|
|
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 most valuable contracts have many orders of magnitude with more services using the contract than there are versions of the contract.
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.
|
|
|
|
|
|
|
|
| |
|
|
|
In this example, the reusable contract introduces an overarching business context of Tax Rules. The method exposed by the reusable contract further specifies this context as calculateTaxes. The resulting service capabilities inherent this context and combine it with their own identifiers. The result is three service capabilities that can be read as "calculate taxes for the US," "calculate taxes for the UK," and "calculate taxes for a future jurisdiction."
|
|
|
Arcitura IT Certified Professionals (AITCP)
Arcitura IT Certified Professionals (AITCP)
Arcitura IT Certified Professionals (AITCP)
Arcitura YouTube Channel
