Re: WSDL Binding Feedback

The Working Group was a little puzzled by your question.

One part may relate to generating synchronous or asynchronous
programming models from the WSDL.  Synchronous and "anonymous" are not
tied at this level - one could generate an asynchronous programming
model for "anonymous" exchanges, or a synchronous model for
non-anonymous exchanges.  The value of the wsaw:Anonymous element is not
a definitive hint for this purpose.  I note that WSDL 2.0 doesn't
provide hints for sync/async, though it does provide hints for rpc-style
programming models.  The Working Group has therefore punted on
sync/async and instead talks about anonymous/non-anonymous which is more
directly related to what appears on the wire and is testable within the
bounds of WS-Addressing.

With that in mind, are you asking that wsaw:Anonymous="optional" be
removed?  Or to have separate markers for the cases corresponding to
wsaw:Anonymous values instead of a single parameterized marker?  That we
(or someone) develop a usable sync/async programming model hint?  Or
something completely different?


--------------------------------
From: Todd Wolff <twolff@bluestemsoftware.com> 
Date: Thu, 30 Mar 2006 14:08:58 -0600
To: <public-ws-addressing-comments@w3.org>

Kudos to the committee for at long last standardizing asynchronous
messaging over a synchronous protocol, i.e. HTTP.  This 'last minute'
addition will perhaps do more to simplify the architecture of web
services based applications than anything else you have contributed.
Nice job.

One observation, and please forgive me if this has already been
addressed within the discussions following the release of the latest
working draft.  It would appear that by adding an extension element to
an existing binding rather than creating a new binding type, the choice
of whether to send a request synchronously or asynchronously, i.e.
assuming Anonymous is optional, will be impossible to make within the
'application layer.'

Using BPEL4WS as an example, an application, i.e. a process in this
case, indicates binding selection implicitly via endpoint assignment.
Unless I am missing something, how would a process designer choose to
invoke an in-out operation synchronously rather than asynchronously, and
vice versa, if the service invoked has only one endpoint, i.e. a
SOAP/HTTP endpoint?

BTW, assuming this is a valid problem, I understand that creating a new
binding type is not trivial and may not be an option at this stage in
the game.  If that's the case, I would MUCH rather keep the existing
solution as-is rather than remove it altogether. It is a HUGE
improvement over the current mess, i.e. request response using two one
way operations.


Todd Wolff
Bluestem Software LLC

Received on Tuesday, 4 April 2006 01:14:29 UTC