OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

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