Schema Centralization

How can service contracts be designed to avoid redundant data representation?

Problem Different service contracts often need to express capabilities that process similar data sets, resulting in redundant schema content that is difficult to govern.
Solution Select schemas that exist as physically separate parts of the service contract are shared across multiple contracts.
Application Upfront analysis effort is required to establish a schema layer independent of and in support of the service layer.	Impacts Governance of shared schemas becomes increasingly important as multiple services can form dependencies on the same schema definitions.
Principles Standardized Service Contract, Service Loose Coupling	Architecture Inventory, Service

Table 8.10 – Profile summary for the Schema Centralization pattern.

Problem

When building services for larger enterprise environments the context established by each service boundary will usually not be exclusive to one body of data. For example a Claims Service will represent a collection of claims-related functions and will therefore be primarily responsible for processing claims data. However, even though it will be positioned as a primary endpoint for that body of functionality, it will likely not be the only service to work with claims data.

As a result, the need for duplicate schema data models emerges, leading to the definition of service contracts with redundant content. Even if the data models across these contracts are standardized, the redundant and decentralized implementation of contract schemas introduces constant governance challenges primarily associated with keeping schema data models in synch.

Figure 8.36 A set of WSDL definitions for which a corresponding set of XML Schemas has been custom tailored. This has the appearance of a very clean contract architecture, but it actually can introduce significant schema redundancy as indicated by the shaded areas.

Solution

Schemas can be designed and implemented independently from the service capabilities that utilize them to represent the structure and typing of message content. As a result, a schema data model architecture can be established and standardized somewhat separately from the parent service layer. For example, if one schema representing claims data is defined, any service with a capability that needs to process claims data would use the same schema.

Figure 8.37 WSDL definitions that share common XML schemas end up sharing the same message data models. The reduction of redundant content also results in smaller sized schemas.

Application

What is primarily advocated by this pattern is the creation of an independent schema (or data representation) architecture. This architecture may already exist within an organization, especially if serious XML schema standardization efforts have already been carried out. However, if schemas need to be defined as part of the SOA initiative, then it is recommended that they be created prior to the completion of individual service contracts.

Ideally, the incorporation of the separate schema layer is taken into account subsequent to the completion of the service inventory blueprint, in preparation for the delivery of the physical service inventory.

 

Essentially, the following sequence is suggested:

1.     Complete a service inventory blueprint to establish a conceptual representation of planned services within an inventory.

2.     Determine the required centralized schema definitions to represent the common business entities and information sets likely to be processed by services in this inventory.

3.     Create the schema definitions by applying design standards to ensure consistency and normalization.

4.     Create the WSDL definitions using the standard schemas wherever appropriate, and supplementing the contract with any required service-specific schemas.

Impacts

Because of the dependencies formed on the shared schema definitions, their initial design is crucial. After multiple service contracts form links to a schema, the evolution of the schema definition thereafter becomes a key part of the overall service inventory governance. Any change to a centralized schema can affect numerous contracts.

For larger organizations, this level of data standardization can pose daunting challenges, many of which revolve around the maintenance of the shared schemas and the enforcement of associated design standards.

Relationships

The schema layer established by Schema Centralization can be built upon and further incorporated as part of a Contract Centralization effort and, due to its emphasis on reducing data model redundancy, also carries forward the goals of Service Normalization into the data tier.

An interesting relationship can exist between this pattern and Validation Abstraction in that the creation of official, centralized schemas can bring with it more detail than all services may actually require. This can end up countering some of the optimizing and information hiding goals of Validation Abstraction.

Figure 8.38 – The Schema Centralization pattern has few relationships because its scope is limited to an independent, underlying data model tier.

Case Study Example

Case study content is not available on this Web site.