Re: [ws-rx] [i061] Anonymous AcksTo

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

So, would WSA mandate that a non-anonymous
ReplyTo MUST result in a 202 on the http response flow?  I would hope
that they wouldn't make the same mistake as the BP and not allow for a
more dynamic model, one where a response can go over a new connection and
still allow some other messages to flow back to the original client.
-Doug


Anish Karmarkar <Anish.Karmarkar@oracle.com>
wrote on 12/06/2005 02:28:51 PM:

> Doug,
> 
> I will try to send my suggested changes (editorial) by EOB today.
> 
> But, I think this issue is a little premature to decide on.
> This issue was discussed on the WS-A WG call yesterday (as it was
> brought up by bunch of folks who are on both WSRX and WS-A). WS-A
WG, at 
> this point is discussing how the anon/non-anon replyTo works (in the
> context of async request-response) when using SOAP 1.1/WSDL 1.1 over
> HTTP. I would like to wait to resolve this issue (and see where WS-A
WG 
> ends up on this).
> 
> Comments?
> 
> -Anish
> --
> 
> Doug Davis wrote:
> > 
> > Anish - did you want to offer up some suggested changes?
> > thanks
> > -Doug
> > 
> > 
> > 
> > *Doug Davis/Raleigh/IBM@IBMUS*
> > 
> > 10/27/2005 12:43 PM
> > 
> >    
> > To
> >    ws-rx@lists.oasis-open.org
> > cc
> >    
> > Subject
> >    [ws-rx] [NEW ISSUE] Anonymous AcksTo  and my
AI
> > 
> > 
> >    
> > 
> > 
> > 
> > 
> > 
> > 
> > Per my AI[1] and after reading the changes to WS-Addressing w.r.t.
the 
> > anonymous URI[2] I think it might be good for the RM spec to
add some 
> > additional text to help readers understand exactly how the sending
of 
> > Acks can greatly impact their soap stack implementations.  In
particular 
> > I think the text needs to make it clear that:
> > 
> >     * An anonymous AcksTo means SeqAcks need to flow
back on the
> >       appropriate protocol binding-specific channel
- e.g. on HTTP its
> >       the HTTP response
> >     * However, this doesn't mean *any* HTTP response
flow, rather just
> >       ones that are in some way related to the
sequence.  For example,
> >       the HTTP request included an AckRequested
or a Sequence header
> >       referring to the sequence in question.
> >     * In cases when there is no message flowing on
the HTTP response
> >       then using an anonymous AcksTo could change
current transport
> >       processing logic.  In particular, a
single HTTP request message
> >       with a non-anonymous wsa:ReplyTo could still
cause a message (an
> >       Ack) to flow back on the HTTP response flow.
> > 
> > 
> > to that end....a new issue:
> > 
> > Title: Anonymous AcksTo
> > 
> > Descripton: Add text, similar to above, to the spec.  It
should be 
> > placed in the Sequence Ack section.
> > 
> > Justification: see above
> > 
> > Target: core
> > 
> > Proposal:
> > After the first paragraph in the SeqAck section (currently section
3.2) 
> > add something like:
> > ----
> > Sending Sequence Acknowledgement Header blocks back to the AcksTo
EPR 
> > could have an impact on current SOAP implementations.  While
this 
> > specification discusses the ability to add, or piggy-back, a
Sequence 
> > Acknowledgement Header block to a message that is targetted to
the 
> > AcksTo EPR, the precise mechanism for determining when any particular
> > message is targetted, or not, to the AcksTo EPR is out of scope
for this 
> > specification.  However, WS-Addressing does give some guidance
on EPR 
> > comparision.
> > 
> > Using the WS-Addressing's anonymous IRI in the AcksTo EPR may
further 
> > impact implementations. When the AcksTo EPR uses the anonymous
IRI, 
> > Sequence Acknowledgements MUST be sent on the appropriate protocol
> > binding-specific channel.  For example, in the HTTP case,
Sequence 
> > Acknowledgements would be expected to flow on the HTTP response
flow. 
> >  It is worth noting that this may result in new SOAP messages
being 
> > generated and sent in certain situations.  For example,
if on an HTTP 
> > request flow the SOAP message contained a wsa:ReplyTo that didn't
use 
> > the anonymous IRI, then it is possible to a new SOAP message
may need to 
> > flow back on the HTTP response flow for the sole purpose of carrying
a 
> > Sequence Acknowledgement.  Because the anonymous IRI is
a general 
> > purpose IRI that can be used by many concurrent RM Sequences,
Sequence 
> > Acknowledgements that are sent to the AcksTo EPR using these
protocol 
> > binding-specific channels SHOULD only be sent when it can be
determined 
> > that the channel is related to the RM Sequence.  For example,
Sequence 
> > Acknowledgements should only be piggy-backed on HTTP response
flows 
> > where the message that was sent on the HTTP request flow referenced
the 
> > Sequence in question through the use of a Sequence or AckRequested
> > Header block.
> > 
> > -----
> > Maybe we should say that they should compare EPRs per WSA's rules?
> >  thoughts?
> > Another option for the anon AcksTo is to encourage people to
use ref-p's 
> > to disamiguate anonymous EPRs - but I still like the idea of
restricting 
> > back-channel flows.
> > 
> > thanks
> > -Doug
> > 
> > [1] 
> > http://www.oasis-open.org/apps/org/workgroup/ws-
> rx/members/action_item.php?action_item_id=1049 
> > 
> > [2] 
> > http://www.oasis-open.org/apps/org/workgroup/ws-
> rx/email/archives/200510/msg00169.html 
> >