Eager to prove wrong those who have a hard time picturing a January face to face meeting in Australia as little more than an excuse for some scuba diving, the WS-A working group is cranking through its issues list. One of the outcomes is that issue #8 is now resolved. The issue is about identifying which headers in a SOAP message are there because the EPR used to address the SOAP message required it. This problem is familiar to anyone who has ever been the victim of the common joke that consists in tricking someone who doesn’t speak a certain language into memorizing and later repeating a sentence in that language while misleading them on the meaning of the sentence. And waiting for them to embarrass themselves in public at the worst time.
The group closed this issue by introducing an attribute that can be added to these headers (wsa:type). Yes, the world really needed another type of “type”. BTW, the resolution will need to be tweaked as a result of another decision: issue #1 was resolved by getting rid of reference properties, leaving only reference parameters. More on this in a future post, but at least this gives an opportunity to replace wsa:type=”parameter” with wsa:parameter=”true” and avoid yet-another-type.
Going back to issue #8, I am glad the group somewhat acknowledged the problem but this doesn’t solve it. For two reasons:
- The schema of the header element might not allow this attribute to be added
- Even if the attribute is present, the recipient of the SOAP message can pretend to not understand it (“I don’t care about this attribute and all the other WS-A crap, all I know is that you sent me the ‘I owe you $1,000’ header and you signed it so now pay up!”)
The way to solve both of these problems was to create one additional SOAP header (in the WS-A namespace) that could be marked mustUnderstand=”true” and points to all the headers in the message that are there because “the EPR told me so”. I proposed this (the wsa:CoverMyRearside approach) in the one and only message I have sent to the WS-A WG, but obviously I wasn’t very convincing. Since I don’t participate in the WG I might never understand what is wrong with this approach. What really surprises me is that it wasn’t even considered. The issues list shows only 3 proposals but the minutes of the face to face show that there was a 4th option considered, which comes a bit closer. Basically, it is the same as the adopted solution with the addition of a WS-A-defined header (that could be marked mustUnderstand=”true”) which states that “by processing this header you agree that you understand the wsa:type attribute when present in other headers”. This is not very elegant in my mind and doesn’t solve (1) but it does solve (2).
Interestingly, even though the wsa:CoverMyRearside header approach was not chosen by the WG, nothing stops me from using this approach: I can defined and use a header in my namespace that I’ll mark mustUnderstand=”true” and that will point to the headers that are there only because “the EPR told me so”. The problem of course is that my namespace is not going to be nearly as well-known as the WS-A namespace and most people will fail on processing my messages because it contains a mustUnderstand=”true” header they do not understand. So in practice I can’t do this. That being said, I wouldn’t be surprised if some spec somewhere one day decided that the mechanism in WS-Addressing is not good enough and that they should take on the task to define such a header because they need this protection.