More on Validation
Does validation mean that interface and implementation are tightly coupled, making the service hard to maintain? Mark Baker posted some more questions on validation yesterday. Validation does have merits in some cases, and the bigger challenge is designing extensible interfaces.
His first comment is that
For an outsider/client, it does not matter whether a service failed due to validation error or some other failure. All that the client wants to know is whether the message was processed, and if not, why not. What difference does it make whether a scheme validator failed because “ABC123” is not a valid 5-digit number or some code block failed because it needs a valid ZIP code to proceed? In that sense, what is the difference between the a structural/value constraint in a schema or some error generated in code.
Another way to look at this is in terms of preconditions and post-conditions. As part of the interface design, it is sensible to express what the preconditions are and what the post-conditions are. Preconditions tell the client what needs to happen for the software to be able to process a request. Agreed that schema languages do not have the smartness to represent all possible preconditions, but they can simplify the effort required to implement certain preconditions in code. Let’s say, the software need to process a purchase order, and certain pieces of data are required to make a purchase order meaningful – for example, it may need certain product descriptions, some contact info etc. To verify these preconditions, the software needs to check that these elements are supplied, and that they make sense (i.e. the software understands those product descriptions and contact info). In most cases, it is possible to express these preconditions in a schema language, and let a validator assert some of the preconditions. This saves time and effort. As I argued in my previous post, upon a validation error, whether to fail immediately or continue is a use-case specific.
There is one particular case where I would consider validation dangerous. It some cases the same software may be described by multiple interfaces. In those case, it is better to keep the software itself decoupled from the interface description, i.e. from the schema language used for describing the interface, and verify the preconditions within code and not rely on a validator.
Preconditions are important to make an interface description useful. The key challenge here is specifying the preconditions such that they are extensible and not set in stone. The current version of the software may only be able to process locations expressed as <address><street></street><city></city></address>, but the next version may also be able to process a “street, city, zip” format, or even geo-coordinates. As the software gets smarter, it needs to be able to process more kinds of messages without significantly changing the interface itself. That is where the schema languages are lacking. It is true that schemas can be used to address extensibility – but in reality – the solutions are painful to implement – like versioning a schema, introducing extension points and so on. The must-ignore rule is easy enough to implement, but the rest of the schema extensibility solutions are not.