.

h1. Separating Infrastructure from Java specifics

Here's a quick diagram on my understanding of the current code in trunk.

!current.png!

The bold green lines look at the kind of separation I think we should head for. The motivation for this is that we'll need to support this mode of operation from implementation types other than Java such as implementation.bpel.

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. 

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

!reference-nonnativeasync.png! 

There is a new operation on the EndPointReference that allows the implementation provides to make a async invocation:

{code}
endpointReference.invokeAsync(ops.get(op), message);
{code}

There's a new async implementation provider interface that allows the infrastructure to retrieve and invoker that knows how to deal with the async response:

{code}
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);
}

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. 

h2. Native Asynchronous Reference Bindings

I've drawn a picture of what this might look like.

!reference-nativeasync.png! 

Note that I imagine that it's the reference's responsibilty to look after processing the asynchronous response. There are some important implications her. Namely:

- The EndpointReference will need another new method, something like invokeAsyncResponse(Message), that will be called by the native async bindings async response listener. 
- The EndpointReference will need to be able to invoke just the response side of its forward chain. This means extending the invoker interface
- The EndpointRefereence will need to pass the response into the implementation provider. The async response invoker already described can be used here.