Databases Reference
In-Depth Information
Combined approach
Rather than using one approach exclusively, the key here is to strike the right balance
and use schema validation to provide at least an initial sanity check of the data, that
is, that the data is of the correct type (for example, integer, date, and so on) and that
the size of the data is within reasonable limits.
For example, with the loosely-coupled schema definition, all our fields could be of
any length. Often, this data will, at some point, be persisted in a database. If a service
consumer issued a request with elements containing data larger than the underlying
data stored, then this could cause the service to fail.
These types of validations can easily be overlooked by developers, yet cause problems
which are hard to diagnose at runtime. By ensuring that we perform some level of
sanity checking at the service entry point we can prevent these issues from occurring.
This also prevents services being called with significantly oversized payloads, which
could have performance implications for the system if allowed to permeate through
the application.
For elements which are far less prone to change, we can define tighter constraints
around the content of those elements, to remove as much validation as possible from
the underlying service implementation.
However, we would still like to extract as much of the validation logic from the
underlying service as possible. This not only makes the service simpler to implement,
it also makes the service more reusable, as we could potentially provide different
validation depending on the context in which it is used. Fortunately, this is where
Schematron comes in.
Schema validation within the Mediator
Schema validation of
incoming
messages is configured for each operation
implemented by the Mediator. To enable schema validation for an operation, in
the Mediator Editor select the option
Validate Syntax (XSD)
as we have for the
activateUser
operation.
