DaveO: Ruminations ...

Dave has been ruminating. I hope it doesn't mean he's been chewing his cud:-)

In all seriousness, as usual, he's on to something.

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.

Let's examine this further.

First, I think that w/r/t #1 and #2, these aren't so much an issue for WS-Addressing as much as for WS-Transfer. However, I agree. If the Action is a WS-Transfer action URI, then it could be mapped directly to the corresponding HTTP method for at least GET, PUT and DELETE. WS-Transfer also provides for a CREATE action. This could be mapped to a POST with a Content-Location HTTP header field returning the URI of the created resource.

Of course, the interesting bits come further when we need to factor in WS-Addressing EPR reference properties/parameters, as Dave points out.

With regards to MessageId, I agree that duplicate detection is best handled by WS-RM and that MessageId and RelatesTo are most interesting for correlation in cases where the values cannot be implied (as in the case of HTTP request/response). However, I was struck by the idea that one could define a URI scheme in which the components were:

     <scheme>:<sequence id>:<message number>

which would map directly to WS-RM's Sequence header block expressed as a URI. Hmmm... but, I digress.

With regards to mapping refps, I agree that mapping Reference Parameters to HTTP Cookies is probably the way to go. As for Reference Properties, that gets a little trickier, I agree. Will definitely need some thought. He wraps up with the following:

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.

Personally, I find myself in the "you got your chocolate bar in my peanut butter" camp.