You may have noticed that there are a lot of request-reply message pairs where the
[local name] of /s:Envelope/s:Body/* is the last
path segment of the SOAPAction HTTP header. You know, where there's a RequestPurchaseOrder element as the child of the Body of the request, and the SOAPAction HTTP header has a value ending in /RequestPurchaseOrder.
This is just a convention and nothing more.
WS-Addressing does not require this convention. It doesn't even describe how the convention would be extended from SOAPAction to the wsa:Action SOAP Header block. (Though it does use it in
an example.)
Why isn't this convention baked in? Well, here are four cases where a lexical relationship between wsa:Action and /s:Envelope/s:Body/* would be awkward to impossible:
- When you want to do half-a-dozen things with a purchase order, e.g., quote, request status, log, notarize, etc. why should you be forced to wrap the purchase order in another XML element (or forced to explain to yet another vertical standards org why this must be done)?
- When you don't really even need a child of Body, i.e., count(/s:Envelope/s:Body/*) = 0. For example, WS-Transfer Get. Even procedural programming languages find void useful.
- When you need > 1 child of Body, i.e., count(/s:Envelope/s:Body/*) > 1.
- When you need to do late binding on the message content, i.e., when the child of /s:Envelope/s:Body varies from one message to the next. For example, WS-Transfer GetResponse.
The lexical convention between wsa:Action (or SOAPAction) and the child of /s:Envelope/s:Body is just that, a convention. Don't bake it into a spec or a profile. It just paints us into a corner.
Posted
Oct 20 2004, 04:23 AM
by
jeffrey-schlimmer