Databases Reference
In-Depth Information
Dangers of under validation
An alternate approach is to push the responsibility of validation down to the lowest
service in the chain on the basis that if an error occurs, it will catch the error which
will then be propagated up the chain and returned to the original consumer of
the service.
Again, on the surface, this approach seems fine. However, the main issue here is
whether we have to undo any work as a result of the error, which we could have
avoided if we had caught it earlier. For example, if we have a service A, which is a
composite of service B and service C, the call to service B may succeed but if just the
call to C fails, we may need to undo any work carried out by service B.
Negative coupling of validation
Another issue that arises with service composition is that a high level component,
which calls other components effectively "inherits" the validation of the lower
level components.
The strategy we recommend here is that we put the minimal amount of validation in
the lower level component and put the more restrictive constraints in the higher
level components.
Assuming the service is only designed for internal use, that is, via other components
within our control, this approach works well. As we can mandate that any additional
validation that is required is applied in a higher level component.
For those components that we need to expose directly to external consumers, we can
still follow this approach by implementing a wrapper component with the required
validation and then expose this externally.
This approach allows us to develop more generic lower level components, which are
easier to reuse while at the same time minimizing over and under validation.
