Re: WSDL Binding Feedback

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