Validation abstraction
We are implementing an SOA with many services composed to form various business processes. The consumers of these business processes are corporative transactional Web sites and systems used in distributed office locations. We produced an XML schema (XSD) for the entities in the message and are using the SOAP literal document. Some want to add a validation service for the received data (typically contract data), that would be invoked at the beginning of each business process. The validations that would take place there cannot easily be made in XSD since it is necessary for instance to verify in a database that the combination of the sold product codes is coherent. However some between us are really questioning if it is a good thing to have such validation service. Some say that it would break the concept of design by contract. Others say that each service would have to validate what must be validated. What do you think of this situation? Is a good practice to implement a validation service?

    Requires Free Membership to View

    Login

    When you register, you'll begin receiving targeted emails from my team of award-winning writers. Our goal is to keep you informed on recent service-oriented architecture (SOA) and SOA-related topics such as integration, governance, Web services, Cloud and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSOA.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSOA.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

One of the relatively common optimization techniques associated with SOA is that of validation abstraction; essentially the reduction of validation detail within a schema so as to reduce consumer coupling requirements and increase longevity of service contracts. To carry out this technique requires the deferral of some validation logic into the underlying service logic. So, what this means is that it is ok to move validation logic away from the contract layer, as long as there is a good reason to do so.

Often validation logic is associated with the business context of the service as a whole. For example, validation logic can be related to business rules that belong within the processing boundary of a business service (in the absence of decision services and business rules engines). Therefore, if you had an Underwriting Entity Service, it would make sense to place underwriting-related validation logic within this service (as part of the contract or embedded within the service logic).

I don't see anything wrong with a separate Validation Service, especially if it abstracts a great deal of reusable logic that can be applied to fulfill numerous validation requirements (in support of numerous services). However, if you are building an entity service layer and validation logic across these entities is distinct, then it might make more sense to contain them within the individual services so that they can be independently governed and evolved. It really comes down to the nature of the validation logic itself.

This was first published in January 2007

Back to top