I see quite a few models for Service Oriented Architectures that employ pipelines with validating "gatekeeper" stages that verify whether inbound messages are valid according to an agreed contract. Validation on inbound messages is a reactive action resulting from distrust of the communication partner's ability to adhere to the contract. Validation on inbound messages shields a service from invalid input data, but seen from the perspective of the entire system, the action occurs too late.

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.

Exception information that is generated on an inbound channel, especially in asynchronous one-way scenarios, vanishes into a log file at a location/organization that may not even own the sending service that's in violation of the contract. The only logical place to detect contract violations in order to isolate and efficiently eliminate problems is on the outbound, not on the inbound channel. Eliminating problems may mean to fix problems in the software, allow manual correction by an operator/clerk or an automatic rejection/rollback/retry of the operation yielding the incorrect result. None of these corrective actions can be done in a meaningful way by the message recipient. The recipient can shield itself, and that is and remains very important. However, it's just a desperate act of digging oneself in when the last line of defense did already fall.

Tuesday, October 07, 2003 9:56:35 PM UTC
Good point.

BizTalk Server seems especially usefull in these kinds of solutions. Verifying a message against the schema does not take more effort than checking a checkbox. I must admit though that we usually more sceptical of the stuff coming in than the stuff going out. Maybe we can learn to distrust our own code enough to turn the validation on.
Alex Keizer
Wednesday, October 08, 2003 12:32:07 AM UTC
I share your point of view. But I disagree on a particular (notational) aspect: IMHO outbound message compliance to a contract is not a postcondition. Postconditions (at least in the axiomatic semantics vocabulary) are conditions on the results of a calculation. So checking the postcondition would mean making sure that the reply from a service has the expected (probably semantic) relation with the request, which is not your point.
Nicolas Kicillof
Friday, October 17, 2003 11:43:39 PM UTC
Great point, I used to call it "offensive programming", but for some reason that phrase never caught on. :)

When dealing with software fortresses, checking preconditions is usually the "only" way to catch content errors early enough, because most SOA gatekeepers usually don't/can't inspect at a low enough level.
Friday, November 07, 2003 10:45:46 AM UTC
Hi:

ebXML BPSS architecture (and it Business Service Interface component) has been suggesting just that since about 3 years ago. This is particularly useful in B2B scenario and if you are a large company, you may never completely be sure if something that has just changed in your IT is not breaking an outgoing message (both from a format and a sequence point of view).

JJ-
ebXML BPSS 1.1 editor.
Comments are closed.