Re: Clarification for WS-RX

Since there have been misunderstandings over this sort of thing in the
past, let me be clear here.  I agree that we should focus narrowly on
WS-A issues, particularly at this late stage of the game.  We should not
try to define new semantics to directly handle use cases from another group.

That said, we do have an open issue to ensure that WS-RX's needs for
addressing are met.  This pretty clearly fits under the provision in the
charter (under "Out of Scope" :-) that "While the definition of new WSDL
MEPs, composition of MEPs, or interaction patterns, such as pub-sub,
callback or notification mechanisms, is outside the scope of the Web
Services Addressing Working Group, the Working Group shall accommodate
the use of the addressing mechanism in the context of such scenarios.
The Working Group should coordinate with other groups wishing to define
such interaction patterns."

We are also required to produce components that are "extensible to
enable other mechanisms such as new kinds of relationships between
correlated
<http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#correlation> messages,
policies <http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#policy>, or
service semantics
<http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#service_semantics> to
be built upon Web Services Addressing."

I would think that WS-RX's requirement of sending acks in response to
messages received falls pretty squarely under this.  So I don't believe
we can push WS-RX issues completely out of scope (though I would prefer
to at this point).

On the other hand, we have a problem because WS-RX's needs for anonymous
AcksTo are not clearly defined (this is what I've been pushing on in the
recent thread).  To the extent that WS-RX's needs are defined, they
appear to revolve around using the response message of a
request-response exchange, but they are clearly not the same as those
for anonymous response endpoints or the use of [destination] in
anonymous responses.  We've carefully hammered out the rules for those
cases and we can't change them unless there are specific issues for
those cases, which there aren't.

So that leaves us with the status quo: anonymous is not defined outside
a handful of specific cases in the SOAP binding.  We decided quite a
while ago that our extensibility mechanism was simply SOAP extensibility
and if you wanted to define a new header with functionality building on
WSA, you could go ahead and do it.  As I recall, the group was quite
adamant on this point.  The specific discussion at the time revolved
around things like "alternate reply" or "logging", but "acks" is clearly
another (and more relevant) example.

Putting it all together, it seems our main obligation here is to
"accommodate the use of the addressing mechanism".  We do this now,
first by providing EPRs, second by providing a well-known "anonymous"
URI for cases where a destination is not directly referenceable, and
third by demonstrating how to tie the definition of anonymous to SOAP
1.1/HTTP and to SOAP 1.2.  It might be nice to do more, and IMHO it
would certainly be nice to rephrase the existing SOAP text so that one
could say "underlying response message" instead of the equivalent "HTTP
response if you're using SOAP 1.1/HTTP or response message of a SOAP 1.2
request-response message exchange", but given our time frame I don't
think we can do more.


paul.downey@bt.com wrote:

>  
>
>>I'm a bit loath to send this to the whole WS-RX list, and I think there
>>are enough WS-RXperts here to answer, so ...
>>    
>>
>
>but this is Web service addressing and I'm bothered that we do seem
>to keep descending into glorious detail on how WS-RX may or may not 
>work, rather than answering tractable LC and CR comments from that 
>WG wrt our specifications.
>
>Paul
>
>  
>