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=""

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.


no comment until now

Add your comment now