Databases Reference
In-Depth Information
The final callback operation (highlighted in the preceding code), is the equivalent of
the fault defined within our synchronous service.
Layered validation considerations
Within a single composite application, we have a certain amount of control over
what validation to put in the schema, Schematron, and the underlying services. This
allows us to design and implement these in a coordinated fashion, so that they can
work in synergy with one another.
However, once we start assembling services from other composite applications, then
the lines of demarcation, and thus which service is responsible for which validation,
becomes less clear.
There are a number of potential strategies which can be adopted, but each has its
own strengths and weaknesses. We examine some of these below, but in reality,
there is not always a simple answer and it really comes down to good design and
being aware of the issues.
Dangers of over validation
Probably the "safest" approach is to make each service fully responsible for its own
validation, and thus perform whatever validation is required, regardless of what
validation is performed by any other service in the chain.
However, this could have potential performance implications. Apart from the
obvious overhead of performing the same work several times, it could introduce
potential points of contention within the system.
If we take the
updateCreditCard
operation, at some point our application will
need to fully validate the card. To do this, it will need to call out to an external web
service. If we follow the approach of performing this validation in every service
involved in the operation, and the request has to go through N layers of services,
then that would require N callouts to the external service with the implied latency of
making N callouts. Not to mention that the card company might wonder why this
card is being validated so many times!
Another issue with this approach is that the validation may be implemented several
times, not always identically, resulting in inconsistent validation that is hard to
change. This can be addressed by using shared XML Schema, Schematron, and
Business Rules validation.
