Re: Action Item

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

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

iD8DBQFDlbx/mNJiOOM57NMRAj6AAJ4puV5oxfudxo/tAwGN8IQqOnf7SACgpRzl
kXRtdcD53jv/K6UvcKFASjk=
=/E8R
-----END PGP SIGNATURE-----

Received on Tuesday, 6 December 2005 16:31:28 UTC