Here’s a simple question for WS-* advocates; how does one take a SOAP envelope/infoset generated by the WS-Addressing SOAP binding, and send it via the SOAP 1.2 default HTTP binding? Should be trivial, right? Let’s see. Here’s an example envelope (from the WS-A spec);

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
           xmlns:wsa="http://www.w3.org/2005/08/addressing">
  <S:Header>
   <wsa:MessageID>http://example.com/6B29FC40-CA47-1067-B31D-00DD010662DA</wsa:MessageID>
   <wsa:ReplyTo>
     <wsa:Address>http://example.com/business/client1</wsa:Address>
   </wsa:ReplyTo>
   <wsa:To>http://example.com/fabrikam/Purchasing</wsa:To>
   <wsa:Action>http://example.com/fabrikam/SubmitPO</wsa:Action>
  </S:Header>
  <S:Body>
    ...
  </S:Body>
</S:Envelope>

That envelope contains both a wsa:To and wsa:Action header, which are, respectively, where the message is to be sent, and the action that is requested be done. Now, off in SOAP/HTTP land, we have a set of properties of the default binding which are required in order to construct a SOAP/HTTP message. Amoungst these properties are ImmediateDestination – “where the envelope is to be sent” – and then either Action or Web-Method (or both – who knows?!) which define the – you guessed it – “the action that is requested be done”. So, you’d think that WS-Addressing would have to define how to populate those properties from a WS-A infoset, ideally as a function of things like wsa:To and wsa:Action. AFAICT, it doesn’t.

And to think this think got to CR?! Egads.

The concept of a “SOAP binding” is prima facie broken because it necessarily requires treating underlying protocols as transport protocols, as if the SOAP envelope was actually a SOAP message (hint: it isn’t). WS-Addressing should either a) map the relevant part of its infoset to the property model of the default SOAP/HTTP binding (e.g. wsa:To -> SOAP’s ImmediateDestination), or b) define a new SOAP/HTTP binding that does the same thing, should problems be found reusing the default binding.