Canonical Resources

How can unnecessary service resource design disparity be avoided?

Problem Service implementation designs can be supported by a range of disparate resources and extensions, leading to the risk of bloated technology architectures and inconsistent service designs.
Solution The supporting infrastructure and architecture can be equipped with common resources and extensions that can be repeatedly utilized.
Application Enterprise design standards are defined to formalize the required use of standardized architectural resources.	Impacts Dependency on shared architectural resources can decrease service autonomy and mobility.
Principles Service Autonomy	Architecture Inventory

Table 6.3 – Profile summary for the Canonical Resources pattern.

Problem

Services delivered without architectural design standards or if developed outside of an organization (as part of an outsourced project, for example), run the risk of implementing fundamental processing functions in a non-standard manner.

Although service contracts may be standardized and common utility services may be consistently used, there is still the danger of building additional service logic (not encapsulated by centralized services) redundantly and differently across service implementations. This approach can lead to service designs that are out of alignment with others in the same inventory as well as with the technology architecture as a whole.

Figure 6.15 – Services use different resources or architectural extensions for the same purpose, resulting in inconsistent architectural dependencies.

Solution

Standardized infrastructure and architecture extensions are established. These extensions are capable of providing common forms of processing in a consistent and generic manner.

Examples of these types of extensions include:

•     state deferral extensions (such as a standard state database or standard tables within a database used for temporary storage of state data)

•     security processing extensions (such as a central directory or a standardized set of security technologies and/or processing agents)

•     activity management extensions (such as context and transaction management frameworks)

•     reliability extensions (such as a sequence-based messaging framework)

Many enterprise resources can be encapsulated by and accessed via the utility service layer. The resources referred to by this pattern are those for which service encapsulation is not possible or impractical. As a result, these resources need to be accessed directly by the underlying solution logic.

Figure 6.16 – Services use a standardized architectural extension for the same purpose.

Application

The required usage of these extensions can form the basis for an enterprise design standard that should be applied to all services (within a given inventory or beyond). Generally, these extensions will be consistently incorporated into service designs, unless some unique circumstances require otherwise.

Each standardized extension must be designed to accommodate a range of service requirements in order to avoid the development of redundant processing logic. However, there are times when a service needs to be deliberately designed differently from the architecture to fulfill unique requirements or maintain mobility or facilitate different types of consumers (like external users).

Impacts

Depending on the nature of logic provided, service designs that utilize extensions can form tight dependencies on their surrounding architecture. Often the extensions are shared, which can lower the runtime autonomy of each service. Furthermore, opportunities to relocate or redundantly implement services in other physical environments will be lowered because these architectural dependencies decrease overall service mobility.

Relationships

This pattern relates to others primarily as a regulatory influence. Design patterns that implement new architectural extensions or components are encouraged to avoid introducing disparate products or technologies that fulfill the same purpose. This relates to all of the patterns listed at the top of Figure 6.x.

The effect of applying the Canonical Resources pattern is very similar to enforcing an enterprise design standard, which is why Protocol Standardization can be viewed as a variation of this pattern focused only on communication technologies.

Figure 6.17 – The Canonical Resources pattern helps standardize the underlying inventory architecture and therefore influences the application of several other architectural patterns.

A key relationship worth noting is the potential negative effect that this pattern can have on the goals of the Vendor-Agnostic Context pattern. By mandating that certain architectural extensions be standardized, some of the freedom advocated by Vendor-Agnostic Context to allow an enterprise to diversify its vendor technologies is lost. Therefore, it is recommended that Canonical Resources be applied with the flexibility required to continue to maintain a vendor-neutral context throughout the service inventory.

Case Study Example

Case study content is not available on this Web site.