[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] [i061] Anonymous AcksTo
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]