Re: Action Item

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDleGVmNJiOOM57NMRAtcqAKDEBHuCmpG6nKCKNIqOVFeraP6wwwCdF7sc
O0ecgqDUKFjnixMslr7J5tA=
=JXE2
-----END PGP SIGNATURE-----

Received on Tuesday, 6 December 2005 19:08:47 UTC