Clements talks about implementing two way gate keepers:
"What I see less often is a gatekeeper on outbound channels
that verifies whether the currently executing local service
adheres to the agreed communication contract. Validation on
outbound messages is a proactive action taken in order to
create trust with partners about the local service's ability
to adhere to a contract. Furthermore, validation on outbound
messages is quite often the last chance action before a
well-known point of no return: the transaction boundary. If
a service is faulty, for whatever reason, it needs to
consistently fail and abort transactions instead of emitting
incorrect messages that are in violation of the contract. If
the service is faulty, it must consequently be assumed that
compensating recovery strategies will not function properly
and with the desired result." [1]
This is quite an interesting idea... though I'm not sure how
much it really solves. For one, validating against a schema
only ensures that your data is semantically correct... whether
it is logically consistant or correct is a whole different
story. So, even if you do implement a gatekeeper, you still
have to implement long running transactions (you can't assume
that just because you send a "valid" message to an external WS
that it is actually going to get there and the call is going
to complete w/o errors). By implementing a gatekeeper, you
might be able to stop a transaction before the local commit,
but that doesn't really gain you much (besides a little
performance if you are sending out lots of invalid messages
for some strange reason). Additionally, the only way you can
really validate that message is by getting the WSDL of the
service or some type of XSD contract, and if for some reason
the format of acceptable messages is going to change between
the time you write your app (during which you hopefully design
it to output valid messages), what is to stop it from changing
between the time you request the WSDL and the time you make
the call? Nothing. So, you still have to handle that case
anyway. So again, all you get is the performance benefit of
not having to go any further... worth the extra effort?
Probably not (unless, you or your service provider is
horrendously inconsistant in message creation).
[1]
SOA: Checking postconditions is more important than
checking preconditions. Clemens Vasters.
http://staff.newtelligence.net/clemensv/PermaLink.aspx?guid=278c5ee8-2dcb-4010-ac8c-9e54dcd05b61