Re: [ws-rx] PR issue 1 - WS-Addressing comment on ws-rm related touse of extended anonymous uri

[Paul Fremantle <paul@wso2.com>]

Anish

Comments inline.

> There are two problems with this:
> 1) This specifically disallows sending a 202 using SOAP 1.1 ROR HTTP 
> Binding addendum note. This is a problem for WS-RM, if you want to 
> send message and poll for a response later.
Forget about RM for a second. The client sends an anon request, and 
expects the answer to come back on the response channel. Add in RM and 
the client still expects the response to come back on the response channel.

I think we have begun to lose sight of the origin aims of the polling 
work and how it fits into our charter. The "extended use cases" that 
drove much of the work on the URI based approach seem to be satisfying a 
general polling model. The scenario you describe is exactly that - a 
generic polling model where the client is expecting polling behaviour 
specifically rather than simply composing reliability over the existing 
behaviour. Our aim in RX is to provide a way of composing reliability to 
existing exchanges.

So to be specific, I agree that returning a 202 in this case is probably 
against the specs.
I think the correct HTTP response should either be to return the message 
right then, or to 408 Timeout.

> 2) It does not say anything beyond the SOAP/HTTP binding "MEPs". What 
> is the semantics when used in AcksTo? What does it mean when used in 
> an EPR that is not replyTo/Faulto? It is not defined.
Maybe we need to add words to say exactly what anon means for acksTo. It 
seems like we have a specific meaning (piggyback acks onto existing 
backchannels), and while that is a good logical assumption for the 
meaning, it wouldn't hurt to spell it out.
> 2) remove WSRM anon URI and reuse WS-Addr anon uri. And use refps. 
> Define a specific ref property including comparison rules. That is 
> what refps were meant for. The reason for not using these were cause 
> of trepidations around WS-Addr issue 1, web arch issue and all that 
> good stuff.
+1 I am very strongly pro this option. As regards what the WS-A WG does 
with wsaw:Anon - it would take the pressure off that WG and allow them 
to make the decision based on a clear view uninfluenced by our pressing 
needs.
> If we use option (2), the issue we'll have to tackle is the fact that 
> the SOAP/HTTP binding does change when you use the refp in the 
> replyTo/FaultTo to allow 202. 
-1
> OR say that when used in replyTo/FaultTo the reply/fault must be sent 
> in the back-channel of *that* connection except when there is a 
> failure (in which case there is no change to the SOAP/HTTP binding as 
> WS-A stipulates).
+1

Thanks for taking the time to work through this..... these issues were 
at the back of my head as well, and I don't think we had called them 
out. Perhaps we should raise a new issue to cope with them.

Paul
>
> Paul Fremantle wrote:
>> Anish
>>
>> I'm not clear exactly which interaction you are talking about. Any 
>> chance you can give a scenario and explain exactly which anon URI in 
>> which interaction *may* be at fault.
>>
>> Paul
>>
>> Anish Karmarkar wrote:
>>> Paul,
>>>
>>> The replyTo/FaultTo was just an example. What I was trying to convey 
>>> was that, during the MakeConnection discussion there was point made 
>>> that we *may* not be able to use the WS-A 'anon' URI because that 
>>> particular URI identifies the back-channel (in the case of 
>>> soap/http) for a particular connection, whereas an ws-rm 'anon' URI 
>>> identifies any back-channel of a connection created by the 
>>> MakeConnection message containing the right/same UUID.
>>>
>>> -Anish
>>> -- 
>>>
>>> Paul Fremantle wrote:
>>>> Anish
>>>>
>>>> I don't agree with this point. RM is composing with the existing 
>>>> flow to *add* reliability. There are many reasons that the server 
>>>> cannot reply on the backchannel - network failures, timeouts, etc. 
>>>> In those cases the original contract for delivery is over, since 
>>>> WS-A and SOAP have no inherent retry or retransmission model. WS-A 
>>>> does not and should not say what goes on beyond that original 
>>>> request/response. If or how the reply gets returned beyond that 
>>>> point is not WS-A's concern. That is when RM should kick in. At no 
>>>> point was it the intention or the result of WS-A to prevent the 
>>>> composability with reliability with the existing URI schemes.
>>>>
>>>> I suggest anyone who has any doubt about this carefully rereads the 
>>>> distinction between "response" and "reply" in the WS-A spec.
>>>>
>>>> Paul
>>>>
>>>> Anish Karmarkar wrote:
>>>>> Doug Davis wrote:
>>>>>>
>>>>>> IIRC there were some other reasons as well.  
>>>>>
>>>>> Another reason that was discussed was:
>>>>> is it even valid to use the WS-A 'anon' URI for this?
>>>>> WS-A 'anon' URI in a ReplyTo/FaultTo says, send the reply/fault in 
>>>>> the HTTP-response (back-channel) of *this* connection (in the 
>>>>> SOAP/HTTP binding case), whereas the WS-RM 'anon' URI in a 
>>>>> ReplyT/FaultTo means send the reply/fault in the HTTP-response of 
>>>>> this connection (in the SOAP/HTTP binding case) or *any* 
>>>>> HTTP-response of a connection created using the 
>>>>> wsrm:MakeConnection message with the correct/same UUID.
>>>>>
>>>>> -Anish
>>>>> -- 
>>>>>
>>>>> <snip/>
>>>>>
>>>
>