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/
>