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

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

Anish,
  You might be right that its too
soon to close this issue.  Reading your note it
scares me a bit.  While I agree
all of the questions you mentioned need to be
answered by whatever solution WSA/WSRM/XMLP
decide to put in their
various specs - I just hope that the
solution(s) are not so focused on our current
needs that the next time something new
comes along it would require these
various specs to change yet again.  Chris
already has a bottled up "I told you
so" for the BP related to this
- let's avoid another one  :-)
<totallyBiasedOpinion>
  Ignoring whether or not current
implementations of WSA and WSRM adhere
to the various defined MEPs and Profiles
- I do believe that their current behavior
is correct.  Questions like "is
the ack the 1st reply" worry me since it implies there
might be quite a different outcome from
these discussions.  I think the current
behavior of using wsa:RelatesTo on the
'real' reply (or replies) and not on the
ack is correct.  The current implementations
work and I haven't really heard
any complaints about it, aside from
non-adherence to BP, and is really quite
simple (IMO) so I hope the redesign
by committee of these things doesn't end up 
making things worse.
</totallyBiasedOpinion>
thanks
-Doug

Anish Karmarkar <Anish.Karmarkar@oracle.com>

12/07/2005 04:47 AM

To	Doug Davis/Raleigh/IBM@IBMUS
cc	ws-rx@lists.oasis-open.org
Subject	Re: [ws-rx] [i061] Anonymous AcksTo

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