Hi Mike I just checked in (r989157) the changes to-date in this area. Comments in-line
Simon >> > Simon, > > Let me deal with the question of when a client reference should follow the > asynchronous service pattern - ie when the client should treat the server as > if there is going to be a long delay between making a request and getting > the response back. > > First, there is the case where the client reference or its binding is marked > with "asyncInvocation" intent. In this case, the binding should react as if > the service is asynchronous. > > Second there is the case where there is NO asyncInvocation intent on the > reference, but there is a wire to a service to which "asyncInvocation" is > applied (either directly or from the interface of the service > implementation). This second case can only occur when there is no explicit > binding on the reference - and in this case the binding is being "inherited" > from the service which is the target of the wire. > > In BOTH of these cases, the reference binding should be treated as if > "asyncInvocation" is applied to the reference - and the result is that the > binding must behave as if the request message transmission is completely > separate from the response message - ie things are treat as if there were > two one-way operations, one in the forward direction and one in the reverse > direction. > > I note that the current client code does not do this checking at the moment > - some extra up-front work is required to test for the presence of the > asyncInvocation intent in the relevant locations. I believe that, now that the AsyncJDKInvocationHandler is always used (see below), both EPR and EP intents are checked when deciding if the async or synch pattern should be used. > > > On the client reference side, the reference itself can have one of two forms > - either the standard "synchronous" form of a Java interface (simple > request/response operarations) or the JAXWS async form of a Java interface > (3 forms for each operation - sync, polling, callback). The client can use > either, whether the service is synchronous or asynchronous. It is clearly > unwise to choose the synchronous forms of a method in the case where the > service is async, but I don't think that it is SCA's job to police that. I agree, and this implies that we need to be ready to do async invocation regardless of how the reference is marked. We don't know until EPR/EP bind time what the binding will be so we need to add the AsyncJDKInvocationHandler at proxy creation time. The async/sync pattern determination is them done a run time. > > It is pragmatic perhaps to choose to use the "async" client code that is > currently in the codebase, whether the client is using the sync or the async > forms of the Java interface. The async code can in principle cope with > either sync or async services - it may need some optimisation, but I think > that it should work very much as it is. This is a change from the current > code, but I think it is the right way forward for getting all the behaviour > that we need. +1. This is the foundation of the code I just committed. This is a "doing the right thing before doing it right" approach. There are several improvements/optimizations we could/should make. For example, - Sort out the use of WS_MESSAGE_ID - Check that we can use binding.ws under binding.sca successfully in async mode. - Look to defer to bindings that naturally support async operation. To do this we need to review how our invocation chains work. Currently they combine request and response processing. We'd have to split this up
