Metadata Centralization

How can service metadata be centrally published and governed?

Problem Project teams, especially in larger enterprises, run the constant risk of building functionality that already exists or is already in development, resulting in wasted effort, service logic redundancy, and service inventory denormalization.
Solution Service metadata can be centrally published in a service registry so as to provide a formal means of service registration and discovery.
Application A private service registry needs to be positioned as a central part of an inventory architecture supported by formal processes for registration and discovery.	Impacts The service registry technology needs to be adequately mature and reliable and processes need to be consistently followed; otherwise, the registry runs the risk of being ineffective or becoming stale.
Principles Service Discoverability	Architecture Inventory

Table 6.15 – Profile summary for the Metadata Centralization pattern.

Problem

When growing a service inventory and fostering fundamental qualities such as those realized by the Service Normalization and Logic Centralization patterns, there is a constant risk of project teams inadvertently (or sometimes even intentionally) delivering new services or service capabilities that already exist or are already in development.

This leads to undesirable results, most notably:

•     the introduction of redundant service logic (which runs contrary to the Logic Centralization pattern)

•     the introduction of overlapping service contexts (which runs contrary to the Service Normalization pattern)

•     an overall less effective service inventory and technology architecture, bloated and convoluted by the added redundancy denormalization and in need of additional governance effort

All of these characteristics can undermine an SOA initiative by reducing its strategic benefit potential.

Figure 6.68 – Without an awareness of the full range of existing and upcoming services, there is a constant risk that project teams will deliver service logic that already exists or is already in development.

Solution

A service registry is established as a central part of the technology architecture and is used by service owners and designers to:

•     register existing services and capabilities

•     register services and capabilities in development

As emphasized in discovery-related governance patterns, the registration process requires that discovery information be recorded in a highly descriptive and communicative manner so that it can be used by project teams to:

•     locate and interpret existing services and learn about their functional contexts and boundaries

•     locate and interpret service capabilities and learn about their invocation and interaction requirements

By providing a current and well-maintained registry of service contexts and capabilities, effective service discovery can be achieved.

Figure 6.69 – The fundamental discovery process during which a human locates a potential service via a service registry representing the service inventory, and then interprets the service to determine its suitability.

Application

The application of this pattern requires the following common steps:

1.     Regularly apply the Service Discoverability principle to all service contracts being modeled and designed.

2.     Use service profiles and supporting processes to standardize the documentation of service and capability metadata. For example, a common part of service profiles is a standard vocabulary used for keywords that are attached to the service registry records. (

3.     Implement a reliable service registry product and position it as a standard part of the service-oriented technology architecture and perhaps as a common extension to the overall enterprise infrastructure.

Finally, formal processes for the registration and discovery of services and capabilities need to be established, as per related governance patterns.

Impacts

Service registration and discovery processes are key success factors for the effective governance of a service inventory. If the processes are not respected or followed consistently by project teams or if the registry is not kept current, then the value potential of service discovery will severely diminish.

From a design perspective, however, this pattern will introduce the need for metadata standardization, as per the Service Discoverability principle. It will further require that metadata documentation and registration become part of the standard service delivery lifecycles.

Additionally, it may be required to create a new role in support of realizing Metadata Centralization. A person or a group should act as service registry custodians and assume responsibility for collecting the required metadata and maintaining the registry.

Relationships

The Metadata Centralization pattern essentially establishes a service registry, which is key to ensuring the long-term successful application of the Logic Centralization and Contract Centralization pattern. If the correct services and their contracts can be effectively located (discovered), then the risk of inadvertently introducing redundant logic into an environment is reduced (further supporting Service Normalization).

Agnostic services represent the primary type of service for which metadata needs to be centralized for discovery purposes, which is why this pattern is especially relevant to services defined as a result of Entity Abstraction and Utility Abstraction patterns.

The design-time Service Recomposition potential is maximized because of the successful application of this pattern increases the likelihood that the correct service capabilities will be chosen to fulfill composition requirements.

Figure 6.70 – The Metadata Centralization pattern facilitates discovery and therefore relates to other patterns that rely on design-time awareness in order to be consistently applied.

Case Study Example

Case study content is not available on this Web site.