Re: Action Item

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

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.

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

Received on Tuesday, 6 December 2005 17:08:59 UTC