Validation Abstraction

How can service contracts be designed to more easily adapt to validation logic changes?

Problem Service contracts that contain detailed validation constraints become more easily invalidated when the rules behind those constraints change.
Solution Granular validation logic and rules can be abstracted away from the service contract thereby decreasing constraint granularity and increasing the contractÕs potential longevity.
Application Abstracted validation logic and rules needs to be moved to the underlying service logic, a different service, a service agent, or elsewhere.	Impacts This pattern can somewhat decentralize validation logic and can also complicate schema standardization.
Principles Standardized Service Contract, Service Loose Coupling, Service Abstraction	Architecture Service

Table 8.14 – Profile summary for the Validation Abstraction pattern.

Problem

When building services as Web services, a great deal of validation logic can be expressed using the XML Schema and WS-Policy languages. These standards provide a comprehensive range of features that allow for the definition of very precise and sophisticated validation rules and constraints.

By deferring the majority of validation constraints to the service contract the underlying service logic is alleviated from having to concern itself with the validity and legitimacy of incoming message contents.

As part of the technical service contract, this validation logic expresses fixed terms of engagement to which all potential consumer programs need to comply. The day the underlying business rules or requirements (upon which some of the validation constraints may be based) change, it may not be possible to make the corresponding changes to the established contract without releasing a new version. New contract versions introduce governance burden, especially with agnostic services that have many consumers.

Figure 8.51 – Many validation constraints that find their way into contract schemas are tied directly back to business rules and policies that may be subject to change. (In this figure, the dark green squares represent constraints based on business rules and policies.)

Solution

Depending on the nature of the message data being exchanged, there may be opportunities to decrease the constraint granularity of contract capabilities. This leads to a reduction in the quantity and restrictiveness of validation logic embedded in the service contract by deferring select validation constraints elsewhere.

The less validation logic in the contract, the lower the risk of the contract being impacted by overarching business changes. Therefore, the potential longevity of a service contract is extended.

Figure 8.52 – By reducing the overall quantity of constraints and especially filtering out those more prone to change, the longevity of a service contract can be extended.

Application

This is an example of a pattern that supports service design but imposes change upon the underlying schema and policy definitions. In other words, it asks that schemas and policies be somewhat more conservatively designed in support of service longevity.

Examples of the types of validation constraints that may be suitable include:

•     Detailed and granular validation constraints that express very specific conditions.

•     Constraints based upon precise value characteristics (such as null values or the minimum or maximum allowable length of a document value).

•     Constraints based on embedded enumeration values or code lists.

•     Policy expressions that define specific conditions derived from business rules.

Another area in which this pattern can be effectively applied is the actual typing of message data. Instead of tuning data types to current document definition requirements, an approach can be adopted whereby more lenient data types are employed. This especially affects the simple types used within XML schemas to represent specific document values. Furthermore, attachments can even be utilized to bypass contract-level typing altogether.

As with the other deferred constraints, the actual validation of the affected values occurs within the underlying solution logic. For validation and policy-based constraints that still need to be communicated to consumer program designers, descriptions of the constraints can be added to supplemental service contract documentation, such as the SLA.

Impacts

One of the benefits of decoupled service contracts is that they provide a central location for the placement of validation logic. All of the constraints messages need to comply to can be enforced at the outer rim of the service boundary so that only valid messages make their way through to the underlying service logic.

Applying this pattern removes validation logic from the contract layer decentralizing it and thereby requiring it to be maintained in different locations. Although this increases maintenance effort, this increase is generally not equivalent with the governance impact of having to introduce a new version of a service contract or a new capability.

Relationships

When applying Validation Abstraction, it is important to take into the related Policy Centralization and Schema Centralization patterns into account, because when contracts use centralized policies or schemas their validation logic may not be able to be abstracted as much as this pattern may intend to.

One of the major types of logic this pattern looks to remove or hide from the service contract is business rules. Therefore, the Rules Centralization pattern is related, as is the Entity Abstraction pattern due to the fact that it produces services that encapsulate business entity logic (which generally includes associated business rules) and also posses contracts with multiple capabilities which may be affected by this pattern.

Where exactly abstracted validation logic goes is not dictated by this pattern, which is why Service Agent and Rules Centralization provide possible alternatives. Furthermore, for situations where different contracts need to exist for the same service (as per Concurrent Contracts), this pattern can be used to customize each contract to facilitate different consumer requirements.

Figure 8.53 – The Validation Abstraction patternÕs goal of streamlining service contract content can directly tie into the application of some patterns, while also meeting resistance from others.

Case Study Example

Case study content is not available on this web site.