Re: [ws-rx] PR issue 1 - WS-Addressing comment on ws-rm related to use ofextended anonymous uri

[Doug Davis <dug@us.ibm.com>]

Just a couple of comments inline
-Doug
Paul Fremantle <paul@wso2.com> wrote on 09/29/2006
05:06:23 AM:
> 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.

Let's not forget about needing to get back non-RM-enabled
app messages 
(such as Close, Terminate or a new CreateSequence).
 I know you don't
like these scenarios but I do believe enabling the
full support for RM
should be a goal of the RM spec  :-)    There's
also the case of
RM being optional.  By that I mean, thru policy
the RMS trying to send
messages to the non-addressables endpoint may be allowed
to optionally
use RM or not (perhaps thru some policy exchange).
 In these cases the
non-addressable endpoint does not know if RM is going
to be used.  So,
what kind of solution would we propose?  Sending
both an RM MC and a
generic-polling (e.g. ws-polling) version of MC each
time?  Doesn't
seem very optimal to me when sending just one of them
can get the job
done.  As I mentioned in a previous note, the
solution was developed
to satisfy the RM requirements - the fact that it
also satisfies
additional ones should be viewed as a positive thing
(IMO).

> 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.

408 seems like an odd choice since it means [1]:
10.4.9 408 Request Timeout
The client did not produce a request within the time
that the server was 
prepared to wait. The client MAY repeat the request
without modifications
at any later time. 

This would seem to imply that the server never got
the request which
may not be true.  202 (in terms of what 202 means)
would be a more
logical choice.  Force-fitting (or overloading)
some other code
seems like a hack.

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

> > 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/>
> >>>>>
> >>>
> >