Problem solve Get help with specific problems with your technologies, process and projects.

Validation abstraction

Thomas Erl discusses validation abstraction, a common optimization technique associated with SOA.

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?

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.

Dig Deeper on Topics Archive

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.