Canonical Interface Expression

How can service contracts be consistently understood and interpreted?

Problem Service contracts may express similar capabilities in different ways, leading to inconsistency and risking misinterpretation.
Solution Service contracts are standardized using naming conventions.
Application Naming conventions are applied to service contracts as part of formal analysis and design processes.	Impacts The use of global naming conventions introduce enterprise-wide standards that need to be consistently used and enforced.
Principles Standardized Service Contract, Service Discoverability	Architecture Inventory, Service

Table 5.12 – Profile summary for the Data Expression Standardization pattern.

Problem

Each service offers a set of capabilities that are made available via a publicly available service contract. Service contracts delivered or extended by different projects and at different times are naturally shaped by the architects and developers that worked with them. The manner in which the service context and the serviceÕs individual capabilities are defined and expressed through the contract syntax can therefore vary. Some may use descriptive and verbose conventions, while others may use terse and technical formats. Furthermore, the actual terms used to express common or similar capabilities may range across services.

Because services are positioned as enterprise resources, it is fully expected that other project teams will need to discover and interpret the contract in order to be understand how the service can be used. Inconsistencies in how technical service contracts are expressed undermine these efforts by introducing a constant risk of misinterpretation (on a technical level). The proliferation of these inconsistencies furthermore places a convoluted face on a service inventory, increasing the effort to effectively navigate various contracts to study possible composition design options.

Solution

Standardized naming conventions can be applied to the delivery of all service contracts so as to ensure the consistent expression of service contexts and capabilities.

Figure 5.49 – The expression of service contracts is aligned across services.

The relevancy of this design pattern may at first appear trivial. However, when building a collection of services, especially within larger enterprise environments, a consistent functional expression significantly reduces tangible risk factors.

Figure 5.50 – With Web services, this pattern affects the design of service WSDL definitions.

Application

A set of naming and functional expression conventions needs to be established as formal design standards. The realization of consistent contract design is then attained via the disciplined use of these conventions within common analysis and design processes.

An example of a standard associated with expression standardization is the CRUD (create, read, update, delete) convention traditionally used to outfit components with a predictable set of methods. Entity services in particular often require these types of data processing functions and using standardized verbs to express them supports the application of this pattern.

Impacts

The relevance of this design pattern may at first appear trivial. However, when building a collection of services, especially within larger enterprise environments, a consistent functional expression significantly reduces tangible risk factors.

The primary requirement to successfully applying this pattern is the incorporation and enforcement of the required design standards. If a formal design process has already been established in support of the Decoupled Contract and Canonical Data Model patterns, then the effort to include a step dedicated to Canonical Interface Expression is usually minor.

Note also that unlike the Canonical Data Model pattern, which often must be limited to domain service inventories due to the governance impact, this pattern can more easily be positioned as an enterprise-wide standard. This benefits the enterprise as a whole as consistent expression is established across all domains.

Relationships

The naming conventions introduced by Canonical Interface Expression influence how several other patterns are applied (as listed at the top of Figure 5.x). This pattern fundamentally supports the goals of Contract Centralization and Capability Recomposition by enhancing the usability and intuitiveness of service endpoint layers.

Figure 5.51 – The Canonical Interface Expression pattern keeps the express of service contracts consistent, thereby affect several contract (and context) related patterns.

Case Study Example

Case study content is not available on this Web site.