W3C home > Mailing lists > Public > public-ws-addressing-comments@w3.org > April 2006

Re: WSDL Binding Feedback

From: Todd Wolff <twolff@bluestemsoftware.com>
Date: Tue, 4 Apr 2006 13:09:33 -0500
Message-ID: <001601c65812$ee480230$6601a8c0@LatitudeD500>
To: "Jonathan Marsh" <jmarsh@microsoft.com>
Cc: <public-ws-addressing-comments@w3.org>


So that we can better understand one another, I assume 'programming model'
implies the mechanics by which message exchanges are handled within the
'application layer.'  If this is the case, then I understand
that the value of the 'anonymous' element, which is a binding artifact,
cannot be used, as it is currently designed, to indicate the programming
model employed, i.e. sync or async.  This, I believe, is exactly the

Allow me to explain. Lets assume that only a single binding is provided for
a service, i.e. a soap/http binding and the binding binds an interface with
a single 'In-Out' operation named 'echo'.  If the value of the anonymous
element defined on the binding is 'optional', how/where is the decision made
to insert an anonymous URI vs. a non-anonymous URI into the wsa:ReplyTo
header of a request sent to this operation?

It would appear to me, that this decision should be made within the
application layer.  The only way that this would be possible is if:

1.  The 'optional' value were removed from the spec, or
2.  The 'anonymous' element were removed and a new binding type created,
i.e. 'soap/http non-anon.'

Either solution would allow the WSDL author to create two soap/http
bindings. One that requires that all requests sent to the 'echo' operation
contain an anonymous ReplyTo URI and one that prohibits all requests sent to
the 'echo' operation from using an anonymous ReplyTo URI. The decision then
COULD be made within the application layer via endpoint assignment, i.e. by
selecting either the SoapHttpAnon endpoint or by selecting the
SoapHttpNonAnon endpoint.

Perhaps a non-normative example presenting a use-case which rationalizes the
need for an 'optional' value is warranted - specifically one that explains
how/where within an implementation the decision to populate the ReplyTo
header in a request with an anonymous vs. a non-anonymous URI is made.



----- Original Message ----- 
From: "Jonathan Marsh" <jmarsh@microsoft.com>
To: "Todd Wolff" <twolff@bluestemsoftware.com>
Cc: <public-ws-addressing-comments@w3.org>
Sent: Monday, April 03, 2006 8:14 PM
Subject: 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 18:10:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:49:00 UTC