On Fri, Nov 19, 2010 at 3:31 PM, Simon Laws <[email protected]> wrote:
> I'm looking at the current infrastructure that supports asynchronous
> invocation. We pass the OASIS tests but there are a number of
> improvements I think we could/should make. I've raised TUSCANY-3783
> [1] with sub-tasks to track. The most difficult issue I see at the
> moment is TUSCANY-3786 [2] which is the way that the Java and
> infrastructure parts are a bit intermingled. This makes it tricky to
> re-use the infrastructure for other implementation types. To start
> looking at this I've made a copy of
> samples\extending-tuscany\implementation-sample at
> unreleased\samples\implementation-sample-async. I plan to start this
> by trying to apply the async infrastructure to this new implementation
> type to see what doesn't work.
>
> I've also created a wiki page [3] to capture any thoughts from the ML
> and included a diagram of how I think it looks now. Any thoughts
> and/or help are most welcome.
>
> [1] https://issues.apache.org/jira/browse/TUSCANY-3783
> [2] https://issues.apache.org/jira/browse/TUSCANY-3786
> [3]
> https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Asynch+Infrastructure
>
> Regards
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Apologies for the length of the post. What with the holidays and some
issues I have in getting a clean build I've been saving up a few
thoughts.
Yesterday I checked in some initial changes to start separating the
async infrastructure from the Java specific async features. I've
updated the wiki [1] with some diagrams and notes about what the
change is.
It's primarily focused on the reference side at the moment and
basically involves a couple of new interfaces.
public interface InvokerAsync {
/**
* Process an asynchronous wire
*
* @param msg The request Message for the wire
*
*/
void invokeAsync(Message msg) throws Throwable;
}
Which is implemented by the EndpointReference so that the
implementation provider and initiate and asynchronous invocation.
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);
}
Which is implemented by the implementation provider so that it can
create a separate invoker to handles the future asynchronous response.
I've updated the "unreleased" sample I'm using [2] to take account of
these changes.
Doing this work though has raised a big issue in my mind. The work to
date is based on our existing async programming model support which
assumes no native async support in the binding. In this case we have
to start an async response service with a suitable (generic) interface
so that there is an endpoint that can receive async responses in the
future. This is great for giving us consistent support across bindings
that don't support async operation natively, like RMI or HTTP, but it
doesn't allow for the technologies that can support async operation
natively such as JMS.
I've raised TUSCANY-3801 [3] for this and started thinking about how
we might achieve it. Two approaches come to mind.
1 - we process the forward interface to construct a reference specific
response interface and use this as the interface of the responser
service. This sounds fiddly but might be possible.
2 - we create a new "AsynResponseProvider" that bindings can implement
in order to do the native async response listening.
I'm leaning toward 2 because it doesn't involve re-writing service
interfaces. However there are some implications, the main one being
that we'd need to be able to break open the invocation chains to be
able to process the async response along the response part of the
forward chain. This doesn't seem to hard to arrange but it's different
from what we support in the infrastructure today. The big advantage is
that all the chain set up is already done based on the forward
interfaces and the return types they naturally express.
I'm going to start fiddling to see how hard it is to make 2 work. I'm
already thinking of changing the InvokerAsync interface from the start
of this post to accommodate this behaviour. If anyone has thought
about this before then I'm more than happy to take input. Particularly
if it either stops me from going down a dead end or points me toward
existing code that solves this problem.
[1]
https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Asynch+Infrastructure
[2]
http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/implementation-sample-async/
[3] https://issues.apache.org/jira/browse/TUSCANY-3801
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
