WSDL Binding Feedback

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

WSDL Binding Feedback

twolff
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
Reply | Threaded
Open this post in threaded view
|

Re: WSDL Binding Feedback

Jonathan Marsh

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 <[hidden email]>
Date: Thu, 30 Mar 2006 14:08:58 -0600
To: <[hidden email]>

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


Reply | Threaded
Open this post in threaded view
|

Re: WSDL Binding Feedback

twolff

Jonathan,

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

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.

Thanks,

Todd


----- Original Message -----
From: "Jonathan Marsh" <[hidden email]>
To: "Todd Wolff" <[hidden email]>
Cc: <[hidden email]>
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 <[hidden email]>
> Date: Thu, 30 Mar 2006 14:08:58 -0600
> To: <[hidden email]>
>
> 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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: WSDL Binding Feedback

David Hull
Comments inline.

Todd Wolff wrote:
Jonathan,

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

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.
  
If you want to define an endpoint that requires anonymous (i.e., doesn't support "async" responses), use wsaw:Anonymous="required".  If you want to define an endpoint that prohibits anonymous (i.e. only supports "async" responses), use wsaw:Anonymous="prohibited".  Otherwise, by default or by explicitly using wsaw:Anonymous="optional" the WSDL advertises that the endpoint will accept either form.

The existing SOAP 1.1/HTTP binding, together with the very brief note describing the use of status 202, supports this as-is. XMLP is currently hammering out the analogous case for SOAP 1.2, but the results for HTTP will be essentially the same.  For example, with wsaw:Anonymous="optional"
  • If the request has wsa:ReplyTo anonymous, the reply will come back as usual with a 200 status.  Similarly, if wsa:FaultTo is anonymous (or missing and ReplyTo is), a fault will come back as usual with a 5xx (or was it 4xx?) status.
  • If the request has wsaw:ReplyTo non-anonymous, the HTTP response will have a 202 response code.  The sender then knows to expect a response elsewhere.  More precisely, the sender will already know what to expect unless it included an anonymous wsaw:ReplyTo and a non-anonymous wsaw:FaultTo or vice-versa.  In this "split" case, the response code will disambiguate.  In the more common case, it will confirm what the sender already knows and distinguish replies from faults as usual.
Knowing this, the sender can use anonymous endpoints or not as it sees fit, according to its own circumstances.

In general, the WSDL describes what the receiver will accept and what it will do in response to a message, in terms of the facilities defined in the core and the SOAP binding (or whatever other binding is relevant).  The sender may do with that information what it likes.

In the case of anonymous optional, the receiver is saying "[from the WSDL binding] You may send me messages with any mix of anonymous and non-anonymous response endpoints. [from the core and SOAP binding] If I use an anonymous endpoint for a fault or response, that fault or response will be sent via the HTTP response.  Otherwise, it will be sent according to the relevant binding."

If the sender wants to receive responses via the HTTP response, it should use anonymous.  If not, it should use something else.  There is no way for the receiver's WSDL to signal what the sender should do. This is completely up to the sender.

This is really no different from the case with "none", except that none is always available and so doesn't need to be mentioned in the WSDL at all.  The receiver MUST support none (as per the Core).  The sender can use it or not as it sees fit.

Hope this helps.

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.

  
See above.  This decision is out of our scope.  That said, non-normative use cases might well make things clearer.

Reply | Threaded
Open this post in threaded view
|

Re: WSDL Binding Feedback

twolff
Hi David,
 
Thanks for the response.  When viewed from the perspective of the receiver, the mechanics of how an implementation would manage exchanges delivered to an endpoint whose binding indicates wsa:Anonymous='optional' is very clear.
 
What my issue attempts to address, however, is how the exchange is handled from the sender's point of view.  Lets assume that an application generates an abstract message instance, adds content to the payload and invokes an In-Out operation on the receiving service all using some application specific API.  Life is good.
 
Now it is up to the binding to take the abstract message instance, convert it into a protocol specific message instance, i.e. SOAP in this case, set the relevant ws-addressing headers and submit it via HTTP.  My question is this.  How does an implementer determine what value to set on the ReplyTo header if the receiver allows you the choice of using an anonymous URI or a non-anonymous URI?  And ... what use-case necessitates that this decision must exist?
 
 
Thanks,
 
Todd
 
 
----- Original Message -----
Sent: Tuesday, April 04, 2006 2:01 PM
Subject: Re: WSDL Binding Feedback

Comments inline.

Todd Wolff wrote:
Jonathan,

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

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.
  
If you want to define an endpoint that requires anonymous (i.e., doesn't support "async" responses), use wsaw:Anonymous="required".  If you want to define an endpoint that prohibits anonymous (i.e. only supports "async" responses), use wsaw:Anonymous="prohibited".  Otherwise, by default or by explicitly using wsaw:Anonymous="optional" the WSDL advertises that the endpoint will accept either form.

The existing SOAP 1.1/HTTP binding, together with the very brief note describing the use of status 202, supports this as-is. XMLP is currently hammering out the analogous case for SOAP 1.2, but the results for HTTP will be essentially the same.  For example, with wsaw:Anonymous="optional"
  • If the request has wsa:ReplyTo anonymous, the reply will come back as usual with a 200 status.  Similarly, if wsa:FaultTo is anonymous (or missing and ReplyTo is), a fault will come back as usual with a 5xx (or was it 4xx?) status.
  • If the request has wsaw:ReplyTo non-anonymous, the HTTP response will have a 202 response code.  The sender then knows to expect a response elsewhere.  More precisely, the sender will already know what to expect unless it included an anonymous wsaw:ReplyTo and a non-anonymous wsaw:FaultTo or vice-versa.  In this "split" case, the response code will disambiguate.  In the more common case, it will confirm what the sender already knows and distinguish replies from faults as usual.
Knowing this, the sender can use anonymous endpoints or not as it sees fit, according to its own circumstances.

In general, the WSDL describes what the receiver will accept and what it will do in response to a message, in terms of the facilities defined in the core and the SOAP binding (or whatever other binding is relevant).  The sender may do with that information what it likes.

In the case of anonymous optional, the receiver is saying "[from the WSDL binding] You may send me messages with any mix of anonymous and non-anonymous response endpoints. [from the core and SOAP binding] If I use an anonymous endpoint for a fault or response, that fault or response will be sent via the HTTP response.  Otherwise, it will be sent according to the relevant binding."

If the sender wants to receive responses via the HTTP response, it should use anonymous.  If not, it should use something else.  There is no way for the receiver's WSDL to signal what the sender should do. This is completely up to the sender.

This is really no different from the case with "none", except that none is always available and so doesn't need to be mentioned in the WSDL at all.  The receiver MUST support none (as per the Core).  The sender can use it or not as it sees fit.

Hope this helps.

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.

  
See above.  This decision is out of our scope.  That said, non-normative use cases might well make things clearer.

Reply | Threaded
Open this post in threaded view
|

Re: WSDL Binding Feedback

David Hull
Todd Wolff wrote:
Hi David,
 
Thanks for the response.  When viewed from the perspective of the receiver, the mechanics of how an implementation would manage exchanges delivered to an endpoint whose binding indicates wsa:Anonymous='optional' is very clear.
 
What my issue attempts to address, however, is how the exchange is handled from the sender's point of view.  Lets assume that an application generates an abstract message instance, adds content to the payload and invokes an In-Out operation on the receiving service all using some application specific API.  Life is good.
 
Now it is up to the binding to take the abstract message instance, convert it into a protocol specific message instance, i.e. SOAP in this case, set the relevant ws-addressing headers and submit it via HTTP.  My question is this.  How does an implementer determine what value to set on the ReplyTo header if the receiver allows you the choice of using an anonymous URI or a non-anonymous URI?  And ... what use-case necessitates that this decision must exist?
First, the use case is easy.  If I'm providing an operation through an endpoint, some of my clients might want synchronous replies and some might want asynchronous (or the same client might want one for one invocation and the other for another).  In the (now) typical case that I'm using HTTP, anonymous is always there for free.  If I support non-anonymous, I automatically support both.  That is, I have the capability to send a response back on the HTTP response, or through some other means and all I need is for the sender to tell me which it wants.  For HTTP, the expected scenarios are "prohibited" and "optional".  The wsaw:Anonymous just tells the rest of the world which one I'm doing, that is, whether a sender has the option of using non-anonymous.

As for what the sender does, that depends on the sender, that is, the sender's tooling.  A sender might simply always use anonymous without consulting anyone else.  This will produce the usual behavior, and all the sender has to do is include the appropriate wsaw:Action and hardwire wsa:ReplyTo to anonymous.  In fact, if wsaw:UsingAddressing isn't wsa:required, it doesn't even have to do this.

Only if the sender wants an asynchronous response does it have to do anything special at runtime.  In this case, the tooling will most likely have to have an extra parameter indicating where to send responses (or at least, telling it to ensure that there is an endpoint listening for responses).  Exactly how this happens is up to the tooling and outside our scope.

Put another way, having wsaw:Anonymous="optional" for an endpoint doesn't require the sender to do anything more than having wsaw:Anonymous="required".  The sender may choose to take advantage of non-anonymous replies with an "optional" endpoint, but it doesn't have to.  By hardwiring wsa:ReplyTo to anonymous (and either omitting wsa:FaultTo or hardwiring it the same way), it can pretend that such an endpoint said "required".

By contrast, if wsaw:Anonymous is "prohibited", the sender will have to set up a listener if it wants to interact with that endpoint.

 
 
Thanks,
 
Todd
 
 
----- Original Message -----
Sent: Tuesday, April 04, 2006 2:01 PM
Subject: Re: WSDL Binding Feedback

Comments inline.

Todd Wolff wrote:
Jonathan,

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

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.
  
If you want to define an endpoint that requires anonymous (i.e., doesn't support "async" responses), use wsaw:Anonymous="required".  If you want to define an endpoint that prohibits anonymous (i.e. only supports "async" responses), use wsaw:Anonymous="prohibited".  Otherwise, by default or by explicitly using wsaw:Anonymous="optional" the WSDL advertises that the endpoint will accept either form.

The existing SOAP 1.1/HTTP binding, together with the very brief note describing the use of status 202, supports this as-is. XMLP is currently hammering out the analogous case for SOAP 1.2, but the results for HTTP will be essentially the same.  For example, with wsaw:Anonymous="optional"
  • If the request has wsa:ReplyTo anonymous, the reply will come back as usual with a 200 status.  Similarly, if wsa:FaultTo is anonymous (or missing and ReplyTo is), a fault will come back as usual with a 5xx (or was it 4xx?) status.
  • If the request has wsaw:ReplyTo non-anonymous, the HTTP response will have a 202 response code.  The sender then knows to expect a response elsewhere.  More precisely, the sender will already know what to expect unless it included an anonymous wsaw:ReplyTo and a non-anonymous wsaw:FaultTo or vice-versa.  In this "split" case, the response code will disambiguate.  In the more common case, it will confirm what the sender already knows and distinguish replies from faults as usual.
Knowing this, the sender can use anonymous endpoints or not as it sees fit, according to its own circumstances.

In general, the WSDL describes what the receiver will accept and what it will do in response to a message, in terms of the facilities defined in the core and the SOAP binding (or whatever other binding is relevant).  The sender may do with that information what it likes.

In the case of anonymous optional, the receiver is saying "[from the WSDL binding] You may send me messages with any mix of anonymous and non-anonymous response endpoints. [from the core and SOAP binding] If I use an anonymous endpoint for a fault or response, that fault or response will be sent via the HTTP response.  Otherwise, it will be sent according to the relevant binding."

If the sender wants to receive responses via the HTTP response, it should use anonymous.  If not, it should use something else.  There is no way for the receiver's WSDL to signal what the sender should do. This is completely up to the sender.

This is really no different from the case with "none", except that none is always available and so doesn't need to be mentioned in the WSDL at all.  The receiver MUST support none (as per the Core).  The sender can use it or not as it sees fit.

Hope this helps.

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.

  
See above.  This decision is out of our scope.  That said, non-normative use cases might well make things clearer.


Reply | Threaded
Open this post in threaded view
|

Re: WSDL Binding Feedback

twolff
David,
 
I'm not suggesting that the committee remove the ability to specify an anonymous URI vs. a non-anonymous URI within ReplyTo at runtime.  Standardizing this behavior by formally defining a binding extension is a wonderful thing (see my original message.)
 
What I am suggesting is that for an HTTP binding, the allowable values for the anonymous element, when wsaw:UsingAddressing is 'required', should be 'required', 'prohibited.'  Binding behavior (from the perspective of the sender) will then be predictable across all implementations. The runtime decision as to whether the reply should be received synchronously or asynchronously could then be deferred to the application (where, IMO, the decision belongs.)
 
 
----- Original Message -----
Sent: Tuesday, April 04, 2006 3:59 PM
Subject: Re: WSDL Binding Feedback

Todd Wolff wrote:
Hi David,
 
Thanks for the response.  When viewed from the perspective of the receiver, the mechanics of how an implementation would manage exchanges delivered to an endpoint whose binding indicates wsa:Anonymous='optional' is very clear.
 
What my issue attempts to address, however, is how the exchange is handled from the sender's point of view.  Lets assume that an application generates an abstract message instance, adds content to the payload and invokes an In-Out operation on the receiving service all using some application specific API.  Life is good.
 
Now it is up to the binding to take the abstract message instance, convert it into a protocol specific message instance, i.e. SOAP in this case, set the relevant ws-addressing headers and submit it via HTTP.  My question is this.  How does an implementer determine what value to set on the ReplyTo header if the receiver allows you the choice of using an anonymous URI or a non-anonymous URI?  And ... what use-case necessitates that this decision must exist?
First, the use case is easy.  If I'm providing an operation through an endpoint, some of my clients might want synchronous replies and some might want asynchronous (or the same client might want one for one invocation and the other for another).  In the (now) typical case that I'm using HTTP, anonymous is always there for free.  If I support non-anonymous, I automatically support both.  That is, I have the capability to send a response back on the HTTP response, or through some other means and all I need is for the sender to tell me which it wants.  For HTTP, the expected scenarios are "prohibited" and "optional".  The wsaw:Anonymous just tells the rest of the world which one I'm doing, that is, whether a sender has the option of using non-anonymous.

As for what the sender does, that depends on the sender, that is, the sender's tooling.  A sender might simply always use anonymous without consulting anyone else.  This will produce the usual behavior, and all the sender has to do is include the appropriate wsaw:Action and hardwire wsa:ReplyTo to anonymous.  In fact, if wsaw:UsingAddressing isn't wsa:required, it doesn't even have to do this.

Only if the sender wants an asynchronous response does it have to do anything special at runtime.  In this case, the tooling will most likely have to have an extra parameter indicating where to send responses (or at least, telling it to ensure that there is an endpoint listening for responses).  Exactly how this happens is up to the tooling and outside our scope.

Put another way, having wsaw:Anonymous="optional" for an endpoint doesn't require the sender to do anything more than having wsaw:Anonymous="required".  The sender may choose to take advantage of non-anonymous replies with an "optional" endpoint, but it doesn't have to.  By hardwiring wsa:ReplyTo to anonymous (and either omitting wsa:FaultTo or hardwiring it the same way), it can pretend that such an endpoint said "required".

By contrast, if wsaw:Anonymous is "prohibited", the sender will have to set up a listener if it wants to interact with that endpoint.

 
 
Thanks,
 
Todd
 
 
----- Original Message -----
Sent: Tuesday, April 04, 2006 2:01 PM
Subject: Re: WSDL Binding Feedback

Comments inline.

Todd Wolff wrote:
Jonathan,

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

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.
  
If you want to define an endpoint that requires anonymous (i.e., doesn't support "async" responses), use wsaw:Anonymous="required".  If you want to define an endpoint that prohibits anonymous (i.e. only supports "async" responses), use wsaw:Anonymous="prohibited".  Otherwise, by default or by explicitly using wsaw:Anonymous="optional" the WSDL advertises that the endpoint will accept either form.

The existing SOAP 1.1/HTTP binding, together with the very brief note describing the use of status 202, supports this as-is. XMLP is currently hammering out the analogous case for SOAP 1.2, but the results for HTTP will be essentially the same.  For example, with wsaw:Anonymous="optional"
  • If the request has wsa:ReplyTo anonymous, the reply will come back as usual with a 200 status.  Similarly, if wsa:FaultTo is anonymous (or missing and ReplyTo is), a fault will come back as usual with a 5xx (or was it 4xx?) status.
  • If the request has wsaw:ReplyTo non-anonymous, the HTTP response will have a 202 response code.  The sender then knows to expect a response elsewhere.  More precisely, the sender will already know what to expect unless it included an anonymous wsaw:ReplyTo and a non-anonymous wsaw:FaultTo or vice-versa.  In this "split" case, the response code will disambiguate.  In the more common case, it will confirm what the sender already knows and distinguish replies from faults as usual.
Knowing this, the sender can use anonymous endpoints or not as it sees fit, according to its own circumstances.

In general, the WSDL describes what the receiver will accept and what it will do in response to a message, in terms of the facilities defined in the core and the SOAP binding (or whatever other binding is relevant).  The sender may do with that information what it likes.

In the case of anonymous optional, the receiver is saying "[from the WSDL binding] You may send me messages with any mix of anonymous and non-anonymous response endpoints. [from the core and SOAP binding] If I use an anonymous endpoint for a fault or response, that fault or response will be sent via the HTTP response.  Otherwise, it will be sent according to the relevant binding."

If the sender wants to receive responses via the HTTP response, it should use anonymous.  If not, it should use something else.  There is no way for the receiver's WSDL to signal what the sender should do. This is completely up to the sender.

This is really no different from the case with "none", except that none is always available and so doesn't need to be mentioned in the WSDL at all.  The receiver MUST support none (as per the Core).  The sender can use it or not as it sees fit.

Hope this helps.

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.

  
See above.  This decision is out of our scope.  That said, non-normative use cases might well make things clearer.


Reply | Threaded
Open this post in threaded view
|

Re: WSDL Binding Feedback

twolff
David,
 
(My Comments are In Line )
 
Unless I've missed something, the runtime decision as to whether the reply should be received sync or async can be deferred to the application even if wsaw:Anonymous is "optional".  I don't think I (or the rest of the committee) understand what case breaks if Anonymous is "optional".
 
Comment: By 'application layer' I mean business logic, which works at the abstract level, and has no visibility/notion of binding related artifacts, which includes ws-addressing message headers. Using BPEL as an example, the only way a BPEL application, i.e. process, can influence the manner in which a service is invoked is via endpoint assignment.  If anonymous is 'optional' and only one endpoint is supplied, the application has no control over the sync vs. async decision. The decision is instead up to the binding or as you call it, the 'tooling.'

If you define two separate endpoints, one "required" and one "prohibited", then the sender can select sync or async behavior by choosing which endpoint to send to.  But it seems much easier just to define one optional, and let the sender select based on how it sets the response endpoints as opposed to which endpoint it sends to and how it sets the response endpoints.
 
Comment: I agree that it is easier to gen the wsdl, if only one binding and endpoint is required, but the logic within the binding layer, i.e. the tooling is more complicated. If anonymous is 'optional' every vendor must come up with their own algorithm to determine when to set an anon ReplyTo URI vs. a non-anon ReplyTo URI within request.  I am arguing that bindings across all implementations should behave predictably.  If each vendor uses their own algorithm this will not be the case.

Suppose I have two endpoints defined or an operation: endpoint R is required and endpoint P is prohibited.  If I want sync behavior, I tell my tooling I'm sending to endpoint R and it has to know to set the response endpoints to anonymous.  If I want async behavior, I send to endpoint P and the tooling has to know not to use anonymous (and it either has to establish a listener or get one from me).  In general, I'll want to use one API call to send to R and a different one to send to P.
 
Comment: this is exactly what I am proposing. The application, i.e. business logic, via some application specific API indicates to the tooling which behavior it wants by selecting endpoint R or endpoint P.  The tooling then has no decision to make, it is made by the application.  If anonymous='optional'i.e. only a single endpoint O exists, then this isn't possible.

On the other hand, with a single endpoint, O optional, I say I'm sending to that endpoint and say whether I want sync or async behavior, and the tooling sets the endpoints based on that.  If I want sync, I use the sync API call to send to O.  If I want async, I use the Async call to send to O.
 
Comment: when you say API at this level, you mean the tooling API, i.e. something that isn't accessible from application logic.  Again, this implies that the binding, i.e. tooling must make the sync vs. async decision which will be different for every implementation.

The exact same information is being conveyed in either case, just in different ways.

We're also being a bit loose here with the term "application level".  If "application level" means "business logic", then the question of whether the behavior on the wire is sync or async is orthogonal.  If the wire is async and the business logic wants sync, spawn a thread to send the request while the main thread sleeps and have the response listener wake the main thread when the response arrives (I'll also want to set a timeout in case it doesn't arrive in time).  On the other hand, if the wire is sync and the business logic wants async, send the request, block for the response and send the response to the business logic's listener.
 
Comment: I understand.  The application shouldn't be concerned with the underlying transmission protocol. The application either decides to block for a response, or not to block, and the tooling can emulate either, regardless of whether it's HTTP, JMS, etc ... I think this still remains true, the difference being that we no longer need this 'mess' under the covers to emulate async behavior over a synchronous transmission protocol, i.e. HTTP. When the application decides to block for a response, it selects endpoint R otherwise it selects endpoint P.  No emulation on behalf of the tooling is required.

The point being that the "application level" that would be selecting whether to use anonymous or not (whether by selecting between two endpoints or just using one) is most likely going to be an intermediate layer of tooling sitting between the business logic and the wire.  This level of tooling shouldn't be bothered by having to know about things like anonymous addresses.
 
Comment:  I agree.  The application shouldn't be concerned with ws-addressing at all, including anon URI's.  This is binding related logic, i.e. the tooling's responsibility.  The application is, however, as is the case with BPEL, capable of understanding and manipulating endpoints.

If none of this seems to apply to your situation, maybe we should try working through an an example with hypothetical API calls and wire messages.
 
Comment:  I think we are both on the same page as far as the mechanics are concerned.  Where we differ is, where the sync vs. async invocation decision is made.  I contend that if anonymous is 'optional' and the decision is made by the tooling using some proprietary algorithm, then every implementation will behave differently. 
 
Shouldn't a SOAP/HTTP binding behave similarly across all implementations? And if it doesn't, will application portability be a problem?  If the answer to both questions is 'no', then this is a non-issue.  If the answer to either question is a 'maybe' then it should be addressed.
 
 
Todd
 
Reply | Threaded
Open this post in threaded view
|

Re: WSDL Binding Feedback

David Hull
If there are two endpoints (one sync and one async), how does the business logic know which one it wants?

Todd Wolff wrote:
David,
 
(My Comments are In Line )
 
Unless I've missed something, the runtime decision as to whether the reply should be received sync or async can be deferred to the application even if wsaw:Anonymous is "optional".  I don't think I (or the rest of the committee) understand what case breaks if Anonymous is "optional".
 
Comment: By 'application layer' I mean business logic, which works at the abstract level, and has no visibility/notion of binding related artifacts, which includes ws-addressing message headers. Using BPEL as an example, the only way a BPEL application, i.e. process, can influence the manner in which a service is invoked is via endpoint assignment.  If anonymous is 'optional' and only one endpoint is supplied, the application has no control over the sync vs. async decision. The decision is instead up to the binding or as you call it, the 'tooling.'

If you define two separate endpoints, one "required" and one "prohibited", then the sender can select sync or async behavior by choosing which endpoint to send to.  But it seems much easier just to define one optional, and let the sender select based on how it sets the response endpoints as opposed to which endpoint it sends to and how it sets the response endpoints.
 
Comment: I agree that it is easier to gen the wsdl, if only one binding and endpoint is required, but the logic within the binding layer, i.e. the tooling is more complicated. If anonymous is 'optional' every vendor must come up with their own algorithm to determine when to set an anon ReplyTo URI vs. a non-anon ReplyTo URI within request.  I am arguing that bindings across all implementations should behave predictably.  If each vendor uses their own algorithm this will not be the case.

Suppose I have two endpoints defined or an operation: endpoint R is required and endpoint P is prohibited.  If I want sync behavior, I tell my tooling I'm sending to endpoint R and it has to know to set the response endpoints to anonymous.  If I want async behavior, I send to endpoint P and the tooling has to know not to use anonymous (and it either has to establish a listener or get one from me).  In general, I'll want to use one API call to send to R and a different one to send to P.
 
Comment: this is exactly what I am proposing. The application, i.e. business logic, via some application specific API indicates to the tooling which behavior it wants by selecting endpoint R or endpoint P.  The tooling then has no decision to make, it is made by the application.  If anonymous='optional'i.e. only a single endpoint O exists, then this isn't possible.

On the other hand, with a single endpoint, O optional, I say I'm sending to that endpoint and say whether I want sync or async behavior, and the tooling sets the endpoints based on that.  If I want sync, I use the sync API call to send to O.  If I want async, I use the Async call to send to O.
 
Comment: when you say API at this level, you mean the tooling API, i.e. something that isn't accessible from application logic.  Again, this implies that the binding, i.e. tooling must make the sync vs. async decision which will be different for every implementation.

The exact same information is being conveyed in either case, just in different ways.

We're also being a bit loose here with the term "application level".  If "application level" means "business logic", then the question of whether the behavior on the wire is sync or async is orthogonal.  If the wire is async and the business logic wants sync, spawn a thread to send the request while the main thread sleeps and have the response listener wake the main thread when the response arrives (I'll also want to set a timeout in case it doesn't arrive in time).  On the other hand, if the wire is sync and the business logic wants async, send the request, block for the response and send the response to the business logic's listener.
 
Comment: I understand.  The application shouldn't be concerned with the underlying transmission protocol. The application either decides to block for a response, or not to block, and the tooling can emulate either, regardless of whether it's HTTP, JMS, etc ... I think this still remains true, the difference being that we no longer need this 'mess' under the covers to emulate async behavior over a synchronous transmission protocol, i.e. HTTP. When the application decides to block for a response, it selects endpoint R otherwise it selects endpoint P.  No emulation on behalf of the tooling is required.

The point being that the "application level" that would be selecting whether to use anonymous or not (whether by selecting between two endpoints or just using one) is most likely going to be an intermediate layer of tooling sitting between the business logic and the wire.  This level of tooling shouldn't be bothered by having to know about things like anonymous addresses.
 
Comment:  I agree.  The application shouldn't be concerned with ws-addressing at all, including anon URI's.  This is binding related logic, i.e. the tooling's responsibility.  The application is, however, as is the case with BPEL, capable of understanding and manipulating endpoints.

If none of this seems to apply to your situation, maybe we should try working through an an example with hypothetical API calls and wire messages.
 
Comment:  I think we are both on the same page as far as the mechanics are concerned.  Where we differ is, where the sync vs. async invocation decision is made.  I contend that if anonymous is 'optional' and the decision is made by the tooling using some proprietary algorithm, then every implementation will behave differently. 
 
Shouldn't a SOAP/HTTP binding behave similarly across all implementations? And if it doesn't, will application portability be a problem?  If the answer to both questions is 'no', then this is a non-issue.  If the answer to either question is a 'maybe' then it should be addressed.
 
 
Todd
 

Reply | Threaded
Open this post in threaded view
|

Re: WSDL Binding Feedback -- possible solution

David Hull
In reply to this post by twolff
I think I may finally understand the issue.  If I understand correctly, it's not about what policies or processes a sender might use to decide whether it wants sync or async behavior, but that a WSDL endpoint description with wsaw:Anonymous="optional" does not by itself provide enough information to determine whether the operation with be sync or async.

If this is the point, then it's correct as far as it goes.  To know whether a particular operation is sync or async you look at the response endpoints, not the WSDL description.  That's by design and highly unlikely to change.  If you want to know what modes an endpoint supports, you can look in the WSDL.  If an endpoint can support both, it will say so by having wsaw:Anonymous optional.  This is also by design and highly unlikely to change.

However, neither the WSDL endpoint description nor the response endpoints is what the sender is likely to be looking at when it sends a message.  It will likely see an EPR, that is, an endpoint reference.  Such a reference can carry anything at all in its metadata.  In particular, it can contain a flag saying which mode to use.  E.g. if ServerEndpoint is an EPR,
<ServerEndpoint>
  <wsa:Address>http://www.example.com/AnEndpoint</wsa:Address>
  <wsa:Metadata>
    <ns:Mode>sync</ns:mode><!-- must use anonymous -->
  </wsa:Metadata>
</ServerEndpoint>
could indicate synchronous operation while
<ServerEndpoint>
  <wsa:Address>http://www.example.com/AnEndpoint</wsa:Address>
  <wsa:Metadata>
    <ns:Mode>async</ns:mode><!-- must not use anonymous -->
  </wsa:Metadata>
</ServerEndpoint>
could indicate async.  If the mode marker is missing, you'll have to know some other way, perhaps because the WSDL for the endpoint says "required" or "prohibited".

One interesting candidate for the mode marker would be wsaw:Anonymous.  For example, if you want to use an "optional" endpoint synchronously, you refer to it by an endpoint with wsaw:Anonymous="required" in its metadata.  Effectively, the value provided in the metadata overrides the WSDL.  This overriding is only sensible if the WSDL says "optional" or if the WSDL and metadata say the same thing.

I believe we've deliberately shied away from defining a general rule for this sort of thing, and I can't find anything in section 2 either to support or prohibit this overriding semantic.

Personally, I'm still not convinced this is necessary, but perhaps it addresses the problem at hand.


Todd Wolff wrote:
David,
 
(My Comments are In Line )
 
Unless I've missed something, the runtime decision as to whether the reply should be received sync or async can be deferred to the application even if wsaw:Anonymous is "optional".  I don't think I (or the rest of the committee) understand what case breaks if Anonymous is "optional".
 
Comment: By 'application layer' I mean business logic, which works at the abstract level, and has no visibility/notion of binding related artifacts, which includes ws-addressing message headers. Using BPEL as an example, the only way a BPEL application, i.e. process, can influence the manner in which a service is invoked is via endpoint assignment.  If anonymous is 'optional' and only one endpoint is supplied, the application has no control over the sync vs. async decision. The decision is instead up to the binding or as you call it, the 'tooling.'

If you define two separate endpoints, one "required" and one "prohibited", then the sender can select sync or async behavior by choosing which endpoint to send to.  But it seems much easier just to define one optional, and let the sender select based on how it sets the response endpoints as opposed to which endpoint it sends to and how it sets the response endpoints.
 
Comment: I agree that it is easier to gen the wsdl, if only one binding and endpoint is required, but the logic within the binding layer, i.e. the tooling is more complicated. If anonymous is 'optional' every vendor must come up with their own algorithm to determine when to set an anon ReplyTo URI vs. a non-anon ReplyTo URI within request.  I am arguing that bindings across all implementations should behave predictably.  If each vendor uses their own algorithm this will not be the case.

Suppose I have two endpoints defined or an operation: endpoint R is required and endpoint P is prohibited.  If I want sync behavior, I tell my tooling I'm sending to endpoint R and it has to know to set the response endpoints to anonymous.  If I want async behavior, I send to endpoint P and the tooling has to know not to use anonymous (and it either has to establish a listener or get one from me).  In general, I'll want to use one API call to send to R and a different one to send to P.
 
Comment: this is exactly what I am proposing. The application, i.e. business logic, via some application specific API indicates to the tooling which behavior it wants by selecting endpoint R or endpoint P.  The tooling then has no decision to make, it is made by the application.  If anonymous='optional'i.e. only a single endpoint O exists, then this isn't possible.

On the other hand, with a single endpoint, O optional, I say I'm sending to that endpoint and say whether I want sync or async behavior, and the tooling sets the endpoints based on that.  If I want sync, I use the sync API call to send to O.  If I want async, I use the Async call to send to O.
 
Comment: when you say API at this level, you mean the tooling API, i.e. something that isn't accessible from application logic.  Again, this implies that the binding, i.e. tooling must make the sync vs. async decision which will be different for every implementation.

The exact same information is being conveyed in either case, just in different ways.

We're also being a bit loose here with the term "application level".  If "application level" means "business logic", then the question of whether the behavior on the wire is sync or async is orthogonal.  If the wire is async and the business logic wants sync, spawn a thread to send the request while the main thread sleeps and have the response listener wake the main thread when the response arrives (I'll also want to set a timeout in case it doesn't arrive in time).  On the other hand, if the wire is sync and the business logic wants async, send the request, block for the response and send the response to the business logic's listener.
 
Comment: I understand.  The application shouldn't be concerned with the underlying transmission protocol. The application either decides to block for a response, or not to block, and the tooling can emulate either, regardless of whether it's HTTP, JMS, etc ... I think this still remains true, the difference being that we no longer need this 'mess' under the covers to emulate async behavior over a synchronous transmission protocol, i.e. HTTP. When the application decides to block for a response, it selects endpoint R otherwise it selects endpoint P.  No emulation on behalf of the tooling is required.

The point being that the "application level" that would be selecting whether to use anonymous or not (whether by selecting between two endpoints or just using one) is most likely going to be an intermediate layer of tooling sitting between the business logic and the wire.  This level of tooling shouldn't be bothered by having to know about things like anonymous addresses.
 
Comment:  I agree.  The application shouldn't be concerned with ws-addressing at all, including anon URI's.  This is binding related logic, i.e. the tooling's responsibility.  The application is, however, as is the case with BPEL, capable of understanding and manipulating endpoints.

If none of this seems to apply to your situation, maybe we should try working through an an example with hypothetical API calls and wire messages.
 
Comment:  I think we are both on the same page as far as the mechanics are concerned.  Where we differ is, where the sync vs. async invocation decision is made.  I contend that if anonymous is 'optional' and the decision is made by the tooling using some proprietary algorithm, then every implementation will behave differently. 
 
Shouldn't a SOAP/HTTP binding behave similarly across all implementations? And if it doesn't, will application portability be a problem?  If the answer to both questions is 'no', then this is a non-issue.  If the answer to either question is a 'maybe' then it should be addressed.
 
 
Todd
 

Reply | Threaded
Open this post in threaded view
|

RE: WSDL Binding Feedback -- possible solution

Yalcinalp, Umit
David,
 
I see where you are going. However, as you have made the observation that we have not made any provision (or even recommendation) of the utility of such a flag so far, although we have not prohibited such a use.
 
--umit
 
 
 


From: [hidden email] [mailto:[hidden email]] On Behalf Of David Hull
Sent: Wednesday, Apr 05, 2006 1:24 PM
To: Todd Wolff
Cc: Jonathan Marsh; [hidden email]
Subject: Re: WSDL Binding Feedback -- possible solution

I think I may finally understand the issue.  If I understand correctly, it's not about what policies or processes a sender might use to decide whether it wants sync or async behavior, but that a WSDL endpoint description with wsaw:Anonymous="optional" does not by itself provide enough information to determine whether the operation with be sync or async.

If this is the point, then it's correct as far as it goes.  To know whether a particular operation is sync or async you look at the response endpoints, not the WSDL description.  That's by design and highly unlikely to change.  If you want to know what modes an endpoint supports, you can look in the WSDL.  If an endpoint can support both, it will say so by having wsaw:Anonymous optional.  This is also by design and highly unlikely to change.

However, neither the WSDL endpoint description nor the response endpoints is what the sender is likely to be looking at when it sends a message.  It will likely see an EPR, that is, an endpoint reference.  Such a reference can carry anything at all in its metadata.  In particular, it can contain a flag saying which mode to use.  E.g. if ServerEndpoint is an EPR,
<ServerEndpoint>
  <wsa:Address>http://www.example.com/AnEndpoint</wsa:Address>
  <wsa:Metadata>
    <ns:Mode>sync</ns:mode><!-- must use anonymous -->
  </wsa:Metadata>
</ServerEndpoint>
could indicate synchronous operation while
<ServerEndpoint>
  <wsa:Address>http://www.example.com/AnEndpoint</wsa:Address>
  <wsa:Metadata>
    <ns:Mode>async</ns:mode><!-- must not use anonymous -->
  </wsa:Metadata>
</ServerEndpoint>
could indicate async.  If the mode marker is missing, you'll have to know some other way, perhaps because the WSDL for the endpoint says "required" or "prohibited".

One interesting candidate for the mode marker would be wsaw:Anonymous.  For example, if you want to use an "optional" endpoint synchronously, you refer to it by an endpoint with wsaw:Anonymous="required" in its metadata.  Effectively, the value provided in the metadata overrides the WSDL.  This overriding is only sensible if the WSDL says "optional" or if the WSDL and metadata say the same thing.

I believe we've deliberately shied away from defining a general rule for this sort of thing, and I can't find anything in section 2 either to support or prohibit this overriding semantic.

Personally, I'm still not convinced this is necessary, but perhaps it addresses the problem at hand.


Todd Wolff wrote:
David,
 
(My Comments are In Line )
 
Unless I've missed something, the runtime decision as to whether the reply should be received sync or async can be deferred to the application even if wsaw:Anonymous is "optional".  I don't think I (or the rest of the committee) understand what case breaks if Anonymous is "optional".
 
Comment: By 'application layer' I mean business logic, which works at the abstract level, and has no visibility/notion of binding related artifacts, which includes ws-addressing message headers. Using BPEL as an example, the only way a BPEL application, i.e. process, can influence the manner in which a service is invoked is via endpoint assignment.  If anonymous is 'optional' and only one endpoint is supplied, the application has no control over the sync vs. async decision. The decision is instead up to the binding or as you call it, the 'tooling.'

If you define two separate endpoints, one "required" and one "prohibited", then the sender can select sync or async behavior by choosing which endpoint to send to.  But it seems much easier just to define one optional, and let the sender select based on how it sets the response endpoints as opposed to which endpoint it sends to and how it sets the response endpoints.
 
Comment: I agree that it is easier to gen the wsdl, if only one binding and endpoint is required, but the logic within the binding layer, i.e. the tooling is more complicated. If anonymous is 'optional' every vendor must come up with their own algorithm to determine when to set an anon ReplyTo URI vs. a non-anon ReplyTo URI within request.  I am arguing that bindings across all implementations should behave predictably.  If each vendor uses their own algorithm this will not be the case.

Suppose I have two endpoints defined or an operation: endpoint R is required and endpoint P is prohibited.  If I want sync behavior, I tell my tooling I'm sending to endpoint R and it has to know to set the response endpoints to anonymous.  If I want async behavior, I send to endpoint P and the tooling has to know not to use anonymous (and it either has to establish a listener or get one from me).  In general, I'll want to use one API call to send to R and a different one to send to P.
 
Comment: this is exactly what I am proposing. The application, i.e. business logic, via some application specific API indicates to the tooling which behavior it wants by selecting endpoint R or endpoint P.  The tooling then has no decision to make, it is made by the application.  If anonymous='optional'i.e. only a single endpoint O exists, then this isn't possible.

On the other hand, with a single endpoint, O optional, I say I'm sending to that endpoint and say whether I want sync or async behavior, and the tooling sets the endpoints based on that.  If I want sync, I use the sync API call to send to O.  If I want async, I use the Async call to send to O.
 
Comment: when you say API at this level, you mean the tooling API, i.e. something that isn't accessible from application logic.  Again, this implies that the binding, i.e. tooling must make the sync vs. async decision which will be different for every implementation.

The exact same information is being conveyed in either case, just in different ways.

We're also being a bit loose here with the term "application level".  If "application level" means "business logic", then the question of whether the behavior on the wire is sync or async is orthogonal.  If the wire is async and the business logic wants sync, spawn a thread to send the request while the main thread sleeps and have the response listener wake the main thread when the response arrives (I'll also want to set a timeout in case it doesn't arrive in time).  On the other hand, if the wire is sync and the business logic wants async, send the request, block for the response and send the response to the business logic's listener.
 
Comment: I understand.  The application shouldn't be concerned with the underlying transmission protocol. The application either decides to block for a response, or not to block, and the tooling can emulate either, regardless of whether it's HTTP, JMS, etc ... I think this still remains true, the difference being that we no longer need this 'mess' under the covers to emulate async behavior over a synchronous transmission protocol, i.e. HTTP. When the application decides to block for a response, it selects endpoint R otherwise it selects endpoint P.  No emulation on behalf of the tooling is required.

The point being that the "application level" that would be selecting whether to use anonymous or not (whether by selecting between two endpoints or just using one) is most likely going to be an intermediate layer of tooling sitting between the business logic and the wire.  This level of tooling shouldn't be bothered by having to know about things like anonymous addresses.
 
Comment:  I agree.  The application shouldn't be concerned with ws-addressing at all, including anon URI's.  This is binding related logic, i.e. the tooling's responsibility.  The application is, however, as is the case with BPEL, capable of understanding and manipulating endpoints.

If none of this seems to apply to your situation, maybe we should try working through an an example with hypothetical API calls and wire messages.
 
Comment:  I think we are both on the same page as far as the mechanics are concerned.  Where we differ is, where the sync vs. async invocation decision is made.  I contend that if anonymous is 'optional' and the decision is made by the tooling using some proprietary algorithm, then every implementation will behave differently. 
 
Shouldn't a SOAP/HTTP binding behave similarly across all implementations? And if it doesn't, will application portability be a problem?  If the answer to both questions is 'no', then this is a non-issue.  If the answer to either question is a 'maybe' then it should be addressed.
 
 
Todd
 

Reply | Threaded
Open this post in threaded view
|

Re: WSDL Binding Feedback -- possible solution

twolff
In reply to this post by David Hull
Hi David,
 
Your last paragraph summed it up pretty well for me.  Now I feel comfortable that you and the rest of the committee understand the issue/non-issue.  My concern is based more on intuition than on any concrete example demonstrating interoperability.  You are right in saying that on the wire, there is no ambiguity.  The ambiguity exists instead within the sender's binding.
 
Again, I'm just happy we now, at long last, have a standard for async messaging over HTTP using an In-Out MEP.  It's a huge improvement over having to declare 'callback' operations on a separate interface.
 
The committee is doing a great job.  Thanks for all the hard work.
 
 
Todd
 
 
----- Original Message -----
Sent: Thursday, April 06, 2006 12:18 PM
Subject: Re: WSDL Binding Feedback -- possible solution

Todd,

First, thanks for your input.  It's always good to have a fresh set of eyes in order to check our assumptions and be sure we haven't missed the obvious (or not-so-obvious).  Also, thanks for your patience in explaining your viewpoint.  I'm pretty sure I understand it now, but only now that I've tried to reply to your latest message explaining why there is no issue :-).  I also understand your need to bow out.  Fortunately, I think I can now explain why the WG has acted as it has.  I no longer feel I'm missing something basic, which I did at the start of f this thread.  I hope that what follows will be enough to close out the issue.

I was going to say that, if the business logic makes a synchronous call to the binding API, i.e., it says something like result=getResponse(endpoint, request), then the binding will know to use anonymous, and conversely if the business logic makes an async call, i.e. getResponse(endpoint, request, callback), the binding will know to use non-anonymous.

But while that certainly seems like a natural way to do things, it's still a heuristic.  The binding could instead decide to use a listener with the sync call (and block until the listening thread completes) or it could use anonymous with an async call (and call the callback when the response comes back).  The type of call used does not say unambiguously which way to go, and neither does anything else.  Each binding implementation will have to decide on its own how to make the decision for "optional" endpoints.

If that's the issue, I can appreciate it, but I'm very sure that the WG does not see this as a problem and will be comfortable closing the issue with no action.

First, there is no interoperability problem on the wire.  The endpoint has advertised that it can handle either option, so it doesn't need clients to behave uniformly, any more than it needs all clients to send the same request message.  The endpoint will behave differently depending on what the sender sends; In particular, it will use a second message exchange to deliver the response in the async case.  Again, there is no interop problem.  The service endpoint is obligated to follow the sender's instructions.  If the sender includes a non-anonymous response endpoint, the service endpoint does not have the option to send the response back on the HTTP response instead.  If it did have such an option, there would indeed be an interop problem, since some service endpoints might do this and some might not.

If there were some third party expecting the endpoint always to send a response on the HTTP response or always to use a second message exchange, then that party would not know which to expect based on the WSDL alone.   It would also have to look at the request.  If you can name such a party, then I believe you would have an interesting issue.  But this party would have access to the WSDL (that's what's confusing it) and the network traffic with the endpoint (that's what it has expectations about), so it's difficult to see how it wouldn't have enough information to know what was going to happen.

If there's no interop problem on the wire, then the remaining problem is that bindings don't know what to do.  I believe the WG sees this as flexibility, not ambiguity.  A naive binding can simply choose always (or never) to use anonymous and everything will interop just fine.  More sophisticated bindings can compete on how well they choose when to go sync and when to go async.  Again everything will be fine.  Those bindings don't have to interop with each other, only with the service endpoints, and the service endpoints have advertised that they're fine either way.

Todd Wolff wrote:
Hi David,
 
My point is that there should be NO heuristic involved when determining whether to invoke an operation synchronously or asynchronously from the perspective of the sender. If the 'optional' value is removed, then the binding's job is straightforward.  If the value is 'required', an anonymous URI is set on ReplyTo.  If it's 'prohibited', a non-anonymous URI is set on ReplyTo. 
 
IMO, a SOAP/HTTP binding where wsa:UsingAddressing is 'required' should behave similarly across all implementations (which, after all, is one of the objectives behind the ws-i basic profile.)
 
Thanks for all your replies.  I'm going to 'bow out' of the conversation for now and concentrate on my 'paid work' :-)  Hopefully the committee has enough information to discuss this issue further, if it so desires.
 
 
Thanks again,
 
Todd
----- Original Message -----
Sent: Wednesday, April 05, 2006 3:23 PM
Subject: Re: WSDL Binding Feedback -- possible solution

I think I may finally understand the issue.  If I understand correctly, it's not about what policies or processes a sender might use to decide whether it wants sync or async behavior, but that a WSDL endpoint description with wsaw:Anonymous="optional" does not by itself provide enough information to determine whether the operation with be sync or async.

If this is the point, then it's correct as far as it goes.  To know whether a particular operation is sync or async you look at the response endpoints, not the WSDL description.  That's by design and highly unlikely to change.  If you want to know what modes an endpoint supports, you can look in the WSDL.  If an endpoint can support both, it will say so by having wsaw:Anonymous optional.  This is also by design and highly unlikely to change.

However, neither the WSDL endpoint description nor the response endpoints is what the sender is likely to be looking at when it sends a message.  It will likely see an EPR, that is, an endpoint reference.  Such a reference can carry anything at all in its metadata.  In particular, it can contain a flag saying which mode to use.  E.g. if ServerEndpoint is an EPR,
<ServerEndpoint>
  <wsa:Address>http://www.example.com/AnEndpoint</wsa:Address>
  <wsa:Metadata>
    <ns:Mode>sync</ns:mode><!-- must use anonymous -->
  </wsa:Metadata>
</ServerEndpoint>
could indicate synchronous operation while
<ServerEndpoint>
  <wsa:Address>http://www.example.com/AnEndpoint</wsa:Address>
  <wsa:Metadata>
    <ns:Mode>async</ns:mode><!-- must not use anonymous -->
  </wsa:Metadata>
</ServerEndpoint>
could indicate async.  If the mode marker is missing, you'll have to know some other way, perhaps because the WSDL for the endpoint says "required" or "prohibited".

One interesting candidate for the mode marker would be wsaw:Anonymous.  For example, if you want to use an "optional" endpoint synchronously, you refer to it by an endpoint with wsaw:Anonymous="required" in its metadata.  Effectively, the value provided in the metadata overrides the WSDL.  This overriding is only sensible if the WSDL says "optional" or if the WSDL and metadata say the same thing.

I believe we've deliberately shied away from defining a general rule for this sort of thing, and I can't find anything in section 2 either to support or prohibit this overriding semantic.

Personally, I'm still not convinced this is necessary, but perhaps it addresses the problem at hand.


Todd Wolff wrote:
David,
 
(My Comments are In Line )
 
Unless I've missed something, the runtime decision as to whether the reply should be received sync or async can be deferred to the application even if wsaw:Anonymous is "optional".  I don't think I (or the rest of the committee) understand what case breaks if Anonymous is "optional".
 
Comment: By 'application layer' I mean business logic, which works at the abstract level, and has no visibility/notion of binding related artifacts, which includes ws-addressing message headers. Using BPEL as an example, the only way a BPEL application, i.e. process, can influence the manner in which a service is invoked is via endpoint assignment.  If anonymous is 'optional' and only one endpoint is supplied, the application has no control over the sync vs. async decision. The decision is instead up to the binding or as you call it, the 'tooling.'

If you define two separate endpoints, one "required" and one "prohibited", then the sender can select sync or async behavior by choosing which endpoint to send to.  But it seems much easier just to define one optional, and let the sender select based on how it sets the response endpoints as opposed to which endpoint it sends to and how it sets the response endpoints.
 
Comment: I agree that it is easier to gen the wsdl, if only one binding and endpoint is required, but the logic within the binding layer, i.e. the tooling is more complicated. If anonymous is 'optional' every vendor must come up with their own algorithm to determine when to set an anon ReplyTo URI vs. a non-anon ReplyTo URI within request.  I am arguing that bindings across all implementations should behave predictably.  If each vendor uses their own algorithm this will not be the case.

Suppose I have two endpoints defined or an operation: endpoint R is required and endpoint P is prohibited.  If I want sync behavior, I tell my tooling I'm sending to endpoint R and it has to know to set the response endpoints to anonymous.  If I want async behavior, I send to endpoint P and the tooling has to know not to use anonymous (and it either has to establish a listener or get one from me).  In general, I'll want to use one API call to send to R and a different one to send to P.
 
Comment: this is exactly what I am proposing. The application, i.e. business logic, via some application specific API indicates to the tooling which behavior it wants by selecting endpoint R or endpoint P.  The tooling then has no decision to make, it is made by the application.  If anonymous='optional'i.e. only a single endpoint O exists, then this isn't possible.

On the other hand, with a single endpoint, O optional, I say I'm sending to that endpoint and say whether I want sync or async behavior, and the tooling sets the endpoints based on that.  If I want sync, I use the sync API call to send to O.  If I want async, I use the Async call to send to O.
 
Comment: when you say API at this level, you mean the tooling API, i.e. something that isn't accessible from application logic.  Again, this implies that the binding, i.e. tooling must make the sync vs. async decision which will be different for every implementation.

The exact same information is being conveyed in either case, just in different ways.

We're also being a bit loose here with the term "application level".  If "application level" means "business logic", then the question of whether the behavior on the wire is sync or async is orthogonal.  If the wire is async and the business logic wants sync, spawn a thread to send the request while the main thread sleeps and have the response listener wake the main thread when the response arrives (I'll also want to set a timeout in case it doesn't arrive in time).  On the other hand, if the wire is sync and the business logic wants async, send the request, block for the response and send the response to the business logic's listener.
 
Comment: I understand.  The application shouldn't be concerned with the underlying transmission protocol. The application either decides to block for a response, or not to block, and the tooling can emulate either, regardless of whether it's HTTP, JMS, etc ... I think this still remains true, the difference being that we no longer need this 'mess' under the covers to emulate async behavior over a synchronous transmission protocol, i.e. HTTP. When the application decides to block for a response, it selects endpoint R otherwise it selects endpoint P.  No emulation on behalf of the tooling is required.

The point being that the "application level" that would be selecting whether to use anonymous or not (whether by selecting between two endpoints or just using one) is most likely going to be an intermediate layer of tooling sitting between the business logic and the wire.  This level of tooling shouldn't be bothered by having to know about things like anonymous addresses.
 
Comment:  I agree.  The application shouldn't be concerned with ws-addressing at all, including anon URI's.  This is binding related logic, i.e. the tooling's responsibility.  The application is, however, as is the case with BPEL, capable of understanding and manipulating endpoints.

If none of this seems to apply to your situation, maybe we should try working through an an example with hypothetical API calls and wire messages.
 
Comment:  I think we are both on the same page as far as the mechanics are concerned.  Where we differ is, where the sync vs. async invocation decision is made.  I contend that if anonymous is 'optional' and the decision is made by the tooling using some proprietary algorithm, then every implementation will behave differently. 
 
Shouldn't a SOAP/HTTP binding behave similarly across all implementations? And if it doesn't, will application portability be a problem?  If the answer to both questions is 'no', then this is a non-issue.  If the answer to either question is a 'maybe' then it should be addressed.
 
 
Todd