Notes on improving the Tuscany async invocation infrastructure. See https://issues.apache.org/jira/browse/TUSCANY-3783^{Image Removed}.

Separating Infrastructure from Java specifics

...

I've copied samples\extending-tuscany\implementation-sample to unreleased\samples\implementation-sample-async as a new and neutral implementation type where we can look at what this separation means.

Non-Native Asynchronous Reference Bindings

Here's how I think the separation pans out on the reference side

...

public interface ImplementationAsyncProvider extends ImplementationProvider {

    /**
     * Create an invoker for the asynchronous responses in the invocation
     * chain. The invoker will be responsible for processing the async
     * response including correlating it with the forward call using
     * the MESAGE_ID that appears in the message header. 
     * 
     * @param service The component service
     * @param operation The operation that the interceptor will handle
     * @return An AsyncResponseHandler<T> instance
     */
    Invoker createAsyncResponseInvoker(RuntimeComponentService service, Operation operation);
}

Non-Native Asynchronous Service Bindings

Here's how I think the separation pans out on the service side

Image Added

Doing this has made me ask a rather fundamental question though. We don't take account of the fact that some bindings are naturally asynchronous, I.e. there is no service exposed with a response interface to which asynchronous response are sent.

...

And then implement this with any inteceptors we expect to use on async wires (eventually all interceptors). In this way the separate sides of the chain can be invoked independently. We may also need to give the chain the ability to read the chain backwards for when we want to process the async response.

Native Asynchronous Service Bindings

And here's the same thing but on the service side.

Image Added