Databases Reference
In-Depth Information
Validation within a composite
A composite service exposes one or more operations. These operations provide
the entry point for the outside world, so it provides the obvious starting point for
implementing validation in our composite. However, we also need to consider the
validation requirements of other messages exchanged within our composite as
well as messages exchanged with external services, as illustrated in the
following diagram:
If we look at the preceding diagram, we can see that there are up to eight messages
exchanged, each of which imposes its own requirements in terms of validation.
The first message is the one the composite receives through an
Exposed Service
.
From a data quality perspective, we are likely to have little or no knowledge of the
client invoking the composite, thus we need to validate the content of the incoming
message before we process it any further.
The second message (as well as the fifth) represents an internal exchange of messages
between components within the same composite. In this case, we should have
absolute confidence in the quality of the messages exchanged, so no validation is
required here.
The third and fourth messages are exchanged between our composite and what we
have labeled as
Internal Service
. What we mean here is that this is another service,
which is part of our overall solution (for example, another composite) or at least
part of a portfolio of services under our control, and thus, again we should have
confidence in the quality of the messages exchanged, so typically validation is not
required here.
However, the reality is that the
Internal Service
may be called by a variety of
consumers, if not now, then possibly in the future. So the
Internal Service
would
typically implement validation against the incoming message in much the same way
that our composite would validate message number one.
