Master SOA Design
Pattern Catalog
|
|
|
|
Decoupled Validation Logic (Balasubramanian, Carlyle, Pautasso)
|
Home >
Candidate Patterns List
>Decoupled Validation Logic
|
|
How can a service designed to validate an input document avoid rejecting future versions of the media type?
|
|
|
|
|
Problem
Service consumers often need to validate documents received as part of response messages against a pre-defined schema. However, strict validation logic can inadvertently reject messages to which new versions of a media type are applied.
|
|
|
Solution
The validation logic is physically decoupled from the service logic. Explicit extension points are used where parsers ignore media types that need to support new message content.
|
|
|
Application
Media types support explicit extension points where old parsers must ignore new content they do not understand. When the new version of a media type is defined, the new information is added with the understanding that old processors will ignore it and will need to rely on the old information.
New validation logic replaces the old logic when a new media type version is introduced. This replacement occurs automatically without modifying other service or message-processing logic within services and consumers. The mix of new validation logic and old processing logic will strictly validate a new document, accept it, and correctly ignore content that is new.
Validation logic that can be entirely contained within a generic schema may be executed by services and consumers alike. More complex logic can require a dedicated virtual machine environment to be included, as per the Code-On-Demand [SDP]. Complex validation logic could be processed by the validation logic service itself; however this configuration can result in a performance bottleneck.
| |
|
|
Impacts
Strict validation is supported in order to quickly diagnose faults. Changes to the media type are automatically supported by the newly deployed validation logic without changing other aspects of service or consumer processing. This allows new services and consumers to take advantage of the extensions without disrupting old services or consumers.
Media types must be carefully managed to ensure appropriate extension points are present, that new information can be safely ignored by old processors and that old processors relying upon previous, existing information do not have that information suddenly removed. Changes that require must-understand semantics or that break backwards-compatibility in any other way can still require a new media type to be defined.
|
|
|
|
|
|
|
|
| |
|
|
One way to apply this pattern is to create a Validation Logic utility service that provides up-to-date logic for other services. For example, combining Version 2 validation logic with Version 1 data transformation logic validates incoming documents correctly, but extracts only Version 1 information. A special case of the Decoupled Validation Logic pattern is to actually remove all strict validation logic, as per Validation Abstraction. This approach is common on the Web, where acceptance of documents with irregular content is often more important than schema compliance.
|
|
|
|
Arcitura IT Certified Professionals (AITCP)
Arcitura IT Certified Professionals (AITCP)
Arcitura IT Certified Professionals (AITCP)
Arcitura YouTube Channel
