Oh, the irony, the Microsoft folks are busy singing the praises of WS-Addressing, for its transport independentness whilst their primary web services stack is for all practical purposes hopelessly tied to HTTP.
[Simon Fell > Its just code]

As of WS-I Basic Profile 1.0, Web Services are “hopelessly tied to HTTP”. It isn’t until you add in all the GXA Specifications that you start breaking up the marriage to HTTP (and the RPC Processing Model). Quoting from the WS-I spec:

SOAP 1.1 defines a single protocol binding, for HTTP. The Profile mandates the use of that binding

R2702 : A DESCRIPTION MUST use HTTP transport protocol with SOAP binding. Specifically, the transport attribute of soapbind:binding element MUST have the value “http://schemas.xmlsoap.org/soap/http”.

For interoperability the transport protocol is limited to HTTP. To permit secure transfers at the HTTP level use of HTTP(S) is allowed.

[WS-I Basic Profile v1.0 Working Group Approval Draft]

Additionally, the WSE toolkit is NOT tied to HTTP. One of the more interesting classes in the toolkit is SoapEnvelope. It’s an extension to XmlDocument that adds all the SOAP specific logic. So if you want to do web services w/o being tied to HTTP, WSE provides all the plumbing you need – just add the transport.

I think one of the reasons that the RPC model still dominates many people’s thinking is that we really haven’t gone beyond the HTTP binding defined in the first SOAP spec. For better or worse, as long as we are focused on a client-initiated request/response model, developers are going to think of it as RPC (even though HTTP deals in streamed bytes, not callstacks). WS-Addressing opens the door to other possibilities – like sending response messages to places other than the implicit port at the other end of the HTTP connection.

With a standard way to describe where messages are supposed to go, what their intent is, and how they relate to one another, we can start building systems that use SOAP messages in other ways (without the complexities of WS-Routings message paths). That in turn will start to influence WSDL. In short, WS-Addressing may be the forcing function we need to really start moving away from the the current RPC-centric view of the world into more interesting areas.
[Tim Ewald’s Spoutlet: Pushing the Envelope]

I’ve expressed my frustration with WSDL’s special treatment of HTTP with regard to the Action attribute before. If WS-Addressing can help move WSDL in the right direction, I’m all for it.

My only concern is that there seems to be a lot of overlap with WS-Routing. Both specs define an Action element that corresponds to the WSDL soapAction attribute. Both specs define Message ID and RelatesTo elements. Both specs define from and to addresses, though WS-Routing’s message paths are much more flexible (and complex). Does WS-Addressing imply WS-Routing is in for a major change?

Nothing like a 16 hour day to remind you what it’s like to travel for a living. I’m used to getting up at 4am – I’m just used to going back to sleep after the feeding. The only good thing was that I got some work done on my new article on the flight home.