Re: Action Item

John Kemp wrote:

> Hi David,
>
> ext David Hull wrote:
>
> >I think there may be some ambiguity as to the meaning of
> >"asynchronous".  In the context of WSA, asynchronous has specifically
> >meant "response sent on different channel from request."
>
>
> So using the anonymous [reply] endpoint to essentially turn on or off
> whether a message is handled synchronously or not seems a little at odds
> with this view. As far as I understand it, an anonymous [reply] endpoint
> means that the requester cannot provide a "meaningful" IRI (see my
> earlier reference below) for the response message. But, I can certainly
> see how the connection is made to the underlying transport.

The language of the spec has evolved on this point.  The December 2004
and February 2005 and March 2005 (LC) drafts of the Core read

    Due to the range of network technologies currently in wide-spread
    use (e.g., NAT, DHCP, firewalls), many deployments cannot assign a
    meaningful global URI to a given endpoint. To allow these
    "anonymous" endpoints to initiate message exchange patterns and
    receive replies, WS-Addressing defines the following well-known URI
    for use by endpoints that cannot have a stable, resolvable URI:
    |http://www.w3.org/2004/12/addressing|

    Requests whose [reply endpoint], [source endpoint] and/or [fault
    endpoint] use this address MUST provide some out-of-band mechanism
    for delivering replies or faults (e.g. returning the reply on the
    same transport connection). This mechanism may be a simple
    request/reply transport protocol (e.g., HTTP GET or POST). This URI
    MAY be used as the [destination] for reply messages and SHOULD NOT
    be used as the [destination] in other circumstances.

However, the CR draft of the Core reads (in the table entry for the
anonymous URI):

    Some endpoints cannot be located with a meaningful IRI; this URI is
    used to allow such endpoints to send and receive messages. The
    precise meaning of this URI is defined by the binding of Addressing
    to a specific protocol.

Along with that, the CR draft of the SOAP binding reads:

    When "http://www.w3.org/2005/08/addressing/anonymous" is specified
    as the address of the ReplyTo or FaultTo EPR, the underlying SOAP
    protocol binding provides a channel to the specified endpoint. Any
    underlying protocol binding supporting the SOAP request-response
    message exchange pattern provides such a channel. For instance, the
    SOAP 1.2 HTTP binding[SOAP 1.2 Part 2: Adjuncts
    <http://www.w3.org/TR/2005/CR-ws-addr-soap-20050817/#SOAP12-PART2>]
    puts the reply message in the HTTP response.

(earlier drafts didn't mention anonymous specifically).  The net effect
is to clarify the semantics for anonymous in the well-understood case of
SOAP request-response.  This makes more explicit the view above, which
had been implicit for quite a while.

>
>   Using the
>
> >anonymous endpoint means (more or less) "use the response channel of the
> >low-level request-response MEP in effect."  (i.e., don't use separate
> >connections) We are trying to keep our terminology in line with this
> >view.  In particular, the WSA Core specification does not use the term
> >"asynchronous", and our currently proposed WSDL markup for the
> >two-connection flavor of asynchrony refers to use of the anonymous
> >endpoint, without reference to the term "asynchronous".
>
>
> Understood.
>
> >In line with this, I would call the pattern you describe "polling".  WSA
> >itself neither specifically supports nor prohibits this pattern.  It's
> >an interesting question how best to model this.  There was some
> >discussion [1] of this case (or a similar one) on the async TF list, but
> >I don't believe there was a specific recommendation to WSA as to how to
> >handle it.
>
>
> I think that all I'm looking for is a URI for the [reply] endpoint that
> indicates more or less the polling case then.
>
> Thanks for the additional information.
>
> - JohnK
>
> >[1] http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Feb/0055
> >and following thread.
>
>
> >John Kemp wrote:
>
>
> >>Hello,
> >>
> >>I have a question regarding the use of the anonymous URI to determine
> >>whether a SOAP response should be sent asynchronously.
> >>
> >>As you know, in many cases, a SOAP requester cannot offer a meaningful
> >>IRI for a SOAP responder to send its response to. In a synchronous
> >>transaction, this is not a problem, and the requester can simply
> >>advertise http://www.w3.org/2005/08/addressing/anonymous as its [reply]
> >>endpoint.
> >>
> >>When submitting a message for potentially asynchronous processing, it
> >>would seem that the response message must come back on a different
> >>channel than that used to submit the request.
> >>
> >>I guess I see a couple of issues with the current async proposal:
> >>
> >>1) The current text does not seem to allow a requester who cannot *ever*
> >>provide a meaningful IRI (even if it wants asynchronous processing of a
> >>message) as a [reply] endpoint to submit a message for asynchronous
> >>processing. One could simply define another IRI to indicate  that not
> >>only can the client not provide a meaningful IRI as its [reply]
> >>endpoint, but it is also expecting an asynchronous response (which in
> >>this case would be provided by the client making a later connection to
> >>the same server). This also seems to me to perhaps overload the meaning
> >>of the anonymous URI (as written in [1]).
> >>
> >>Is it necessary to preclude requesters who can never offer a meaningful
> >>[reply] endpoint from asynchronous SOAP message processing? I hope not.
> >>
> >>2) Is it possible that the same endpoint might offer both synchronous
> >>and asynchronous processing of a message, again regardless of the value
> >>of the [reply] endpoint specified in the request? Imagine a client that
> >>submits a message with no knowledge of whether the message will be
> >>processed within the scope of the current HTTP transaction or at some
> >>later time. If the client receives an HTTP 202 status code, without a
> >>(WS-A correlated) SOAP response to its request, then it can expect that
> >>at some later time it could receive a response (perhaps when making
> >>another - unrelated - HTTP request to the same endpoint?).
> >>
> >>Both of these issues could be resolved by finding a different way than
> >>using the anonymous URI to indicate that a (potentially anonymous)
> >>client desires, requires or supports asynchronous processing of its
> >>request message.
> >>
> >>Cheers,
> >>
> >>- JohnK
> >>
> >>[1] http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/#eprinfomodel
> >>
> >>ext Yalcinalp, Umit wrote:
> >>
> >>
> >>>This completes my action item from last week [1].
> >>
> >>>Please find the updated writeup for the  option1 [2] named
> ProposalLast.
> >>>Purple is the changed/new text in comparison to the editor's draft [3].
> >>
> >>>Let me remind everyone that this writeup reflects the consensus
> point of
> >>>the f2f and past 2 weeks discussion in the tc to rewrite the agreed
> >>>semantics up to this point.
> >>
> >>>- We have two elements, UsingAddressing and Anonymous (changed from
> >>>AnonymousUse as suggested last week)
> >>>- UsingAddressing may appear in binding/endpoint. (as it is)
> >>>- I removed the default attribute, however UsingAddressing indicates
> >>>support for both anon and non-anon URIs as addresses as it was in the
> >>>previous writeup [2].
> >>>- Anonymous element uses required/prohibited/allowed as values. It can
> >>>only appear within a binding operation. The values are changed per the
> >>>decision last week [1].
> >>>- SOAP1.1/HTTP binding is described. I cleaned it up from the last
> >>>writeup [2].
> >>>- I deleted one of the examples.
> >>
> >>>David Hull, I did NOT include your suggestions to this as I have made
> >>>some changes to the current SOAP1.1/HTTP section (some
> >>>restructuring/simplification). Since you felt that your changes were
> >>>additive, my suggestion for you is to take the text and illustrate the
> >>>changes with this latest writeup.  I really do not have the cycles to
> >>>include your text and find the conflicts/synergy, at least not this
> >>>week, or whatever is left of it :-(
> >>
> >>>Marc, editorial comments are appreciated esp. with the last
> paragraph of
> >>>3.1 prior to 3.1.1 if we decide to use this writeup in the spec.
> >>
> >>>Thanks,
> >>
> >>>--umit
> >>
> >>
> >>
> >>>[1] http://www.w3.org/2002/ws/addr/5/11/28-ws-addr-minutes.html
> >>>[2]
> >>>http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/0084.ht
> >>>ml
> >>>[3]
> >>>http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html
> >>>?content-type=text/html;%20charset=utf-8
> >>
> >>
> >>>Ps. It feels like Jonathan is trying to take the wind from my sails
> with
> >>>the policy assertion debate :-D.
> >>><<ProposalLastWithoutDefaults.html>>
> >>>----------------------
> >>
> >>>Dr. Umit Yalcinalp
> >>>Standards Architect
> >>>NetWeaver Industry Standards
> >>>SAP Labs, LLC
> >>>umit.yalcinalp@sap.com
> >>>Tel: (650) 320-3095
> >>
> >>
> >>
>