Re: WSDL Binding Feedback

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