A colleague recently informed me that doing validation in a web service was a bad idea and should be avoided. I think his reasoning was that in systems requiring massive throughput performing validation at a web service entry point would be a blocking operation that would hold resources and impact negatively on overall system performance. Sorry, but the idea of not validating a request to a web service struck me as stupid. Anyway, I like to get my ducks in a row so I thought I’d take the opportunity to revisit some SOA concerns around validation.
My usual source of reference on matters pertaining to SOA is Thomas Erl. So, I dug out my copy of “SOA – Principles of Service Design” and had a look at what it had to say on the matter.
“Regardless of the extent of indirect coupling a service contract imposes, there will always be the requirement for the consumer program to comply to the data model defined in the technical service contract definitions.
In the case of a Web service, this form of validation coupling refers to the XML schema complex types that represent individual incoming and outgoing messages. Schemas establish data types, constraints, and validation rules based on the size and complexity of the information being exchanged as well as the validation requirements of the service itself.” [1]
So, in the case of a SOAP-based XML Web service the schema specifies the nature and format of the data contained in the request. A Web service will perform validation against the schema and reject the request if it does not comply. Erl goes on to say,
“The extent of validation coupling required by each individual service capability can vary dramatically and is often tied directly to the measure of constraint granularity of service capabilities. As per the validation-related design patterns, each contract can be individually assessed as to the quantity of actual constraints required to increase its longevity.” [2]
When Erl refers to the constraint granularity he is talking about “the amount of detail which a particular constraint is expressed” [3]. Erl provides the example of a constraint to be applied to a product code; you could mandate that it is a string value between 1 and 4 characters (a course grained constraint) or that it is 4 characters with each character being numeric (a fine grained constraint).
Erl’s concern about service longevity appears to be that if constraint granularity is high so is the validation coupling. Changes to validation rules could pose a threat to service longevity because they would require a change to the service contract. As Erl puts it, “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.” [4]
Erl offers the Validation Abstraction pattern to help alleviate this issue.
So, does all of this mean that performing validation in a Web service is a bad idea. No, of course it doesn’t. What this means is that by reducing the validation detail within the schema can help increase the longevity of service contracts.
However, if you do this you must defer more detailed validation to the underlying service logic, not ignore it altogether. It is worthy of note that some validation logic may be better suited to being performed within the processing boundary of a business service (i.e. moving the validation logic closer to where specific business processing takes place). Use of a dedicated validation service is also an option so validation logic can be maintained on a single location and managed separately.
What I take away from this:
- Validation rules are expressed for service contracts using schema.
- Keeping validation constraints course grained can help extend service contract longevity.
- Consideration should be given to move detailed validation logic into the underlying service logic.
- Moving some validation logic within the business process boundary should be considered.
- Use of an external validation service is an option.
As for my colleague’s original assertion, I think I’ll stick to performing validation in my Web services as and when required.
References
[1] “SOA – Principles of Service Design”, Thomas Erl, pp190-191
[2] “SOA – Principles of Service Design”, Thomas Erl, p191
[3] “SOA – Principles of Service Design”, Thomas Erl, p117
[4] http://www.soapatterns.org/validation_abstraction.php
See also
http://searchsoa.techtarget.com/answer/Validation-abstraction