RE: WSDL Binding Feedback -- possible solution

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: public-ws-addressing-comments-request@w3.org
[mailto:public-ws-addressing-comments-request@w3.org] On Behalf Of David
Hull
	Sent: Wednesday, Apr 05, 2006 1:24 PM
	To: Todd Wolff
	Cc: Jonathan Marsh; public-ws-addressing-comments@w3.org
	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