WS-Addressing support [SWS-84]

[gregturn]

Arjen Poutsma opened SWS-84 and commented

This will be implemented as a EndpointMapping + EndpointInterceptor. The only issue is that there are five different, incompatible versions of WS-Addressing in use today (see http://blog.springframework.com/arjen/archives/2006/07/22/ws-addressing-needs-a-phone-book/). We will probably go for the August 2004 and May 2006 (final) version, but make it pluggable so that other version can be added later.

---

Sub-tasks:

• Server-side support for WS-Addressing [SWS-297] #454 Server-side support for WS-Addressing

• Client-side support for WS-Addressing [SWS-298] #385 Client-side support for WS-Addressing

• WS-Addressing Documentation [SWS-299] #455 WS-Addressing Documentation

Issue Links:

• Add Interceptor functionality to WebServiceTemplate [SWS-194] #346 Add Interceptor functionality to WebServiceTemplate
  ("depends on")

5 votes, 2 watchers

[gregturn]

Magnus Heino commented

Does this mean that SoapHeaderElements will be able to have children so it's possible to generate xml like

wsa:From
wsa:Addressfoobar</wsa:Address>
</wsa:From>

[gregturn]

Arjen Poutsma commented

Adding children to soap header elements already works. You can add any XML to the header or header element by transforming to the Results they expose.

[gregturn]

Magnus Heino commented

Ok, thats what I'm doing. But what about when I want to parse that same xml? What if wsa:Address has setMustUnderstand=true? Should I then leave the spring-ws abstraction, take the header xml as a string, and parse it on my own?

[gregturn]

Arjen Poutsma commented

You can access the mustUnderstand attribute with the mustUnderstand property on SoapHeaderElement.

[gregturn]

Arjen Poutsma commented

Closing issues for 1.5.