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