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

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Doug,

This is a tricky issue with lots of opinions from various folks in 
WS-Addr/WS-Desc/XMLP. This has been discussed in the Async TF (joint TF 
between WS-A and WSD), WS-A and XMLP. It is filed as an errata issue 
(39Rec) in XMLP for SOAP 1.2. The reason it is tricky is because of 
interactions/requirements/restrictions emerging from various MEPs 
(SOAP/WSDL/Application) -- there are a lot of turtles going all the way 
down :-).

WS-Addressing with its replyTo EPR potentially changes the underlying 
SOAP MEP at runtime. Similarly, AcksTo EPR now may potentially change 
the underlying WSDL MEP at runtime. Some of the questions that have to 
be answered are : 1) where is this additional "ack" processed and by 
whom (and how does it fit in various models), 2) is the "ack" just an 
ack with the real "reply" going to replyTo EPR? OR is the "ack" the 1st 
reply with the 2nd reply going to the replyTo EPR? 5) what are the 
restrictions, if any, on this "ack" -- empty SOAP body, empty HTTP 
entity body or something else etc.

All of these affect SOAP bindings/SOAP MEPs/WSDL MEPs and requires 
behavior which at this point is not defined well. WS-Addr (for SOAP 1.1) 
and XMLP (for SOAP 1.2) are trying to nail down these issues/behavior. 
Therefore, I think it is premature to close this issue now.

-Anish
--

Doug Davis wrote:
> 
> 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
>  > >