Re: [ws-rx] alternate proposal for i061

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

Thought I sent this already but I didn't
see it in kavi....  Gil, for the most part this text says about the
same thing as the current proposal.  That part of this that  I
don't think is appropriate is the part about the use of the anon URI being
discouraged.  We have firm requirements from customers who want to
be able to send RM messages thru firewalls and would like to get Acks on
the http response flow.  Having RM RECOMMEND that such a critical
use-case not be supported is not something we can support - and to be honest,
there's even some desire to actually do the opposite and recommend it as
the suggested way to do it - but a middle of the road position of either
saying nothing at all or using the text from the other proposal (or your
newer text as long as its just a rewrite with the same meaning) would be
ok.  The spec is already very clear that the RMS should not use an
AcksTo EPR that would prevent Acks from being sent back - technically that
should be enough.
thanks,
-Doug

"Gilbert Pilz" <Gilbert.Pilz@bea.com>

01/26/2006 01:32 PM

To	<ws-rx@lists.oasis-open.org>
cc
Subject	[ws-rx] alternate proposal for i061

At the end of the explanation
of AcksTo in section 3.1 "Sequence Creation" (line 264 in wsrm-1.1-spec-cd-02):

Additionally use of the WS-Addressing defined "http://www.w3.org/2005/03/addressing/role/anonymous" (the anonymous IRI) may, under some circumstances, make it impossible for either the RM Destination to send or the RM Source to receive Sequence Acknowledgments.

After the first paragraph in section 3.6 "Sequence Acknowledgement" (line 521 in wsrm-1.1-spec-cd-02):

While this specification discusses the ability to add, or piggy-back, a Sequence Acknowledgment Header block to a message that is targeted to the AcksTo EPR, the precise mechanism for determining when any particular message is targeted, or not, to the AcksTo EPR is out of scope for this specification.

Using the WS-Addressing anonymous IRI in the AcksTo EPR may impact some implementations. When the AcksTo EPR contains the anonymous IRI, Sequence Acknowledgments MUST be sent on the appropriate protocol binding-specific channel. For example, in the HTTP case, Sequence Acknowledgments would be expected to flow on the HTTP response flow. It is worth noting that there are message interactions, such as WSDL 1.1 one-way operations, for which there may be no HTTP response flow (see section 4.7.9 of the WS-I Basic Profile 1.1 [WS-I Basic Profile 1.1] for details on why this might be the case). For this reason it is RECOMMENDED that the RM Source avoid the use of the anonymous IRI in the AcksTo EPR unless there exists a clear indication (from either the Application Source, via configuration, or by some other mechanism) that Sequence Acknowledgments will be able to flow across the protocol binding-specific back channel.

The successful use of the anonymous IRI in the AcksTo EPR in conjunction with one-way messages may result in new SOAP messages being generated and returned. With asynchronous, one-way usage it is possible that a new SOAP message may need to flow back on the HTTP response flow for the sole purpose of carrying a Sequence Acknowledgment. Because the anonymous IRI is a general purpose IRI that can be used by many concurrent RM Sequences, Sequence Acknowledgments that are returned to the AcksTo EPR using these protocol binding-specific channels SHOULD only be returned when it can be determined that the channel is related to the RM Sequence. For example, Sequence Acknowledgments should only be piggy-backed on HTTP response flows when 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.

Add the following reference to section 6.2 (Non-Normative References):

[WS-I Basic Profile 1.1]

<appropriate stuff>