I've been thinking a fair bit about how WS-Addressing *could* make use of HTTP as a transfer protocol. There would be 2 main different scenarios: 1) to bring all the HTTP services into the WS-Addressing realm; 2) to enable WS-Addressing software to utilize Web based software like intermediaries.
I've been saying for a while now that I think it's a shame that SOAP 1.2 didn't define a general SOAP to HTTP binding that used HTTP as a transfer protocol, for the previous 2 reasons.
This is the crux of the first problem facing WS-Addressing making use of HTTP as a transfer protocol. If SOAP 1.2 didn't do it, why should WS-A? If SOAP 1.2 didn't provide the hypothetical "SOAP HTTP Transfer binding", why should WS-A create such a thing?
The problem argument for why WS-A should do it is because it should have been done, and WS-A does define a simple binding of abstract properties to SOAP Headers so why not define abstract properties to HTTP?
This relationship between WS-A and HTTP would show up in pretty much all the WS-A properties: Action, To, From, ReplyTo, FaultTo, Message-Id, RelatesTo. I wonder what a strawman would look like. Note, I had proposed a WS-REST binding to the WS-RF last April..
Action
The design for Action would have to be something like:
1. WS-Addressing defines/refers to 4 Transfer operations (ooh, kind of like HTTP or WS-Transfer). I had proposed that WSDL 2.0 define 4 different transport independent operations, but they didn't want that so WS-Transfer is better.
2. When these operations are the Action, then a sender can be configured to map directly to the Web Method Property (ie the transfer verb)
3. The receiver of an HTTP Operation will create an Action property from the Protocol operation, or the Action Header. Probably the Action header over-rides the protocol to avoid the "POST" Action problem.
The problem is what to do with the rest of the properties, and let's look at them
MessageId
Message Ids are very useful for correlation and comparison for duplicates. The duplicate detection is probably best handled outside the scope of WS-A, such as WS-ReliableMessaging. OTOH, correlation for an asynchronous callback is definitely useful for WS-A. HTTP has a built in correlation mechanism that is the HTTP Connection and the request-response. Some possible design alternatives are:
1. If the WS-Addressing MEP is request-response AND it is bound to a single HTTP Connection, then the MessageId and RelatesTo are anonymous values.
2. The MessageId/RelatesTo properties are serialized as HTTP Header
ReplyTo
It gets harder to use HTTP as a transfer with WS-Addressing with ReplyTo. The common ReplyTo scenario is an asynchronous callback. Now what would it mean to use an HTTP GET with an asynch callback? What about PUT or DELETE? These don't seem very callback-ish. Would GET be more useful for Polling solutions instead of callbacks?
If we squint hard enough, we could see that an asynchronous GET operation could look like:
1. If Action is GET and there is a ReplyTo, then serialize the request as an HTTP GET with a x-ReplyTo header.
2. The service responds with a 200 OK response
3. The service then responds with the callback. Presumably this isn't another GET but would more likey be a POST.
This just seems strange. HTTP doesn't really work well with ReplyTo kinds of oeprations. It does work well for asynch access to the HTTP Resource. The HTTP PUT/POST can return a Content-Location HTTP header that would be useful for the client to call to.
So HTTP is designed for origin server-side asynchronous access, but not client side asynch. Which is absolutely no suprise, but makes it harder to do server-server asynch.
Reference Properties and Parameters
And then we really throw ourselves off the cliff when we come to mapping WS-Addressing RefPs to HTTP. We can either map the RefP to the callback URI or to an HTTP header like Cookies. The best that I can think of for this would be to layer WS-Addressing to HTTP Cookies, and any RefPs are eched back in the HTTP Cookie header. Then the receiver casts the Cookie header into SOAP header blocks (which is very similiar to what we had to do for the WSDL 2.0 Abstract Data Feature when binding Application data to either SOAP or HTTP).
I've thought a lot about how RefPs could be mapped to URIs, and there's lots of ways to do it. The idea would be that a client would get a RefP, then binding the RefP to the URI it uses for the callback. Maybe if RefPs were constrained a bunch of ways - only 1 refP and a particular QName to URI mapping is defaulted - then it could work. It certainly requires some rules
NetNet
I've looked at 4 areas of WS-Addressing and how they could be designed to work with HTTP as a Transfer protocol. It's not pretty, it's hard, it's possible, but I'm not sure the value of it. WS-Addressing focuses a lot on asynchronous communication, which seems to require some heavy squinting to get working with HTTP. Let's say the WS-A group undertook to do the "WS-A HTTP Transfer Binding", it would have to do all the previous work.
Would WS-Addressing software be able to access Web resources? Would WS-Addressing software use HTTP as a Transfer protocol and thus integrate better into the Web? I'm not so sure.
Here's a test case: Would the Atom protocol switch to using WS-Addressing and then use the HTTP as Transport binding(s) and HTTP as Transfer binding? Seems to me not likely. The Atom folks that want to use HTTP as Transfer have baked the verbs into their protocol, and they won't want to switch away from being HTTP-centric. And same as I don't see the SOAP centric folks wanting to "pollute" their operations and bindings with HTTP-isms.
I would love it if there was a reasonable way to bridge the SOAP/WS-Addressing world and the HTTP Transfer protocol world, but I just don't see that each side really want the features of the other side. The SOAP/WSA folks want the SOAP processing model for Asynch, and don't care about the underlying protocol. The Web folks want their constrained verbs and URIs and don't care about SOAP processing model.
At any rate, this is a strawman analysis of the costs and benefits of WS-Addressing using HTTP as a transfer protocol, and will hopefully help spark some discussion.
