You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2010/11/19 16:31:42 UTC
Async infrastructure improvements
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
Re: Async infrastructure improvements
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Dec 7, 2010 at 10:42 PM, Raymond Feng <cy...@gmail.com> wrote:
> I found out the interface names very confusing. Can we rename them first?
> For example,
> InvokerAsync --> AsyncInvoker
> InvokerAsyncResponse --> AsyncResponseInvoker
> InvokerAsyncRequest --> AsyncRequestInvoker
Sounds OK to me.
> The other thing is that we now have so many different flavors of the message
> handlers. Maybe we can find ways to consolidate/simplify them:
> Interceptor/Invoker (dealing with request/response/fault in the sync
> fashion)
> RequestProcessor/ResponseProcessor/FaultProcessor (dealing with
> request/response/fault in the async fashion)
I agree it's pretty complex at the moment. The new async stuff has
purposely been kept separate from the existing interface to 1/ allow
for improvement without breaking the existing sync code 2/ allow for
improvement without breaking the existing, but separate, async code.
So I think the the thing to do is give it a few more days and then
take a step back, see what's working, and then we can decide how we
actually want to factor it.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Async infrastructure improvements
Posted by Raymond Feng <cy...@gmail.com>.
I found out the interface names very confusing. Can we rename them first? For example,
InvokerAsync --> AsyncInvoker
InvokerAsyncResponse --> AsyncResponseInvoker
InvokerAsyncRequest --> AsyncRequestInvoker
The other thing is that we now have so many different flavors of the message handlers. Maybe we can find ways to consolidate/simplify them:
Interceptor/Invoker (dealing with request/response/fault in the sync fashion)
RequestProcessor/ResponseProcessor/FaultProcessor (dealing with request/response/fault in the async fashion)
Thanks,
Raymond
________________________________________________________________
Raymond Feng
rfeng@apache.org
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
________________________________________________________________
On Dec 6, 2010, at 1:30 AM, Simon Laws wrote:
> A quick update.
>
> On Friday I checked some changes in as a first pass of an
> implementation of the 2nd option in my previous mail to this thread.
> I.e. making the forward reference responsible for installing a
> response listener and updating the EndpointReference and Endpoint, and
> the associated invocation chains, to make them responsible for
> processing any asynchronous responses along the response part of the
> forward chain (on both reference and service side).
>
> There are some new implementation and binding provider interfaces for
> creating an AsyncResponseInvoker on the service and reference sides.
> I'm updating the wiki page [1] to show the service side as well as the
> reference side.
>
> The status of the changes is that they are currently very rough with
> lots of outstanding issues (i'll post separately on them) and the
> updated implementation sample demonstrates the native async operation
> with binding.sca. The limited nature of this though means that the
> databinding interceptor doesn't get invoked. So my next steps at to
> improve the sample to prove that the approach will really work and,
> assuming that it does, start improving the code to fix all the issues
> I'm aware of. I'd also like to convert a remote binding to demonstrate
> native async operation.
>
> [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/
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Async infrastructure improvements
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Dec 6, 2010 at 10:40 AM, ant elder <an...@gmail.com> wrote:
> I'd like to start merging the changes i have to support choosing the sca
> binding impl on a per service/reference basis (binding-sca-runtime2 + some
> local changes) into binding-sca-runtime, if i do that now is it going to get
> in the way of what you're doing?
>
> ...ant
>
Not sure. I'm not planning any big changes to the SCA binding so I'd
say go for it. As I said the next challenge for me is to get a remote
binding working. That could be done independently of the SCA binding
initially if needs be.
Simon
Re: Async infrastructure improvements
Posted by ant elder <an...@gmail.com>.
I'd like to start merging the changes i have to support choosing the sca
binding impl on a per service/reference basis (binding-sca-runtime2 + some
local changes) into binding-sca-runtime, if i do that now is it going to get
in the way of what you're doing?
...ant
On Mon, Dec 6, 2010 at 9:30 AM, Simon Laws <si...@googlemail.com>wrote:
> A quick update.
>
> On Friday I checked some changes in as a first pass of an
> implementation of the 2nd option in my previous mail to this thread.
> I.e. making the forward reference responsible for installing a
> response listener and updating the EndpointReference and Endpoint, and
> the associated invocation chains, to make them responsible for
> processing any asynchronous responses along the response part of the
> forward chain (on both reference and service side).
>
> There are some new implementation and binding provider interfaces for
> creating an AsyncResponseInvoker on the service and reference sides.
> I'm updating the wiki page [1] to show the service side as well as the
> reference side.
>
> The status of the changes is that they are currently very rough with
> lots of outstanding issues (i'll post separately on them) and the
> updated implementation sample demonstrates the native async operation
> with binding.sca. The limited nature of this though means that the
> databinding interceptor doesn't get invoked. So my next steps at to
> improve the sample to prove that the approach will really work and,
> assuming that it does, start improving the code to fix all the issues
> I'm aware of. I'd also like to convert a remote binding to demonstrate
> native async operation.
>
> [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/
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Re: Async infrastructure improvements
Posted by Florian MOGA <mo...@gmail.com>.
I'm seeking to have multiple response capabilities inside Tuscany for some
time now. This behavior meets some limitations at the moment but not in the
reference - service communication (as there are protocols which enable that
natively). The problem is how Tuscany makes the call to the service
implementation which is made via reflection (receives a single response per
request).
Are there other mechanisms to do the call to the service implementation so
that multiple responses can be received?
Will the changes to the async infrastructure enable or facilitate this type
of communication? Or is it single response oriented?
I've tried to simulate a callback mechanism between the Tuscany service and
the actual service implementation for the comet binding but didn't succeed
(fails with some strange errors on startup). The mechanism consists in
declaring callbacks with the @Callback annotation between the Tuscany
service and the service implementation which looks like trying to start up
Tuscany in Turscany :) You can check out my experiment here [1] (the
modified runtime and sample). Any advice is welcome.
[1] http://svn.apache.org/repos/asf/tuscany/sandbox/fmoga/
On Mon, Dec 6, 2010 at 1:05 PM, Simon Laws <si...@googlemail.com>wrote:
> On Mon, Dec 6, 2010 at 10:55 AM, ant elder <an...@apache.org> wrote:
> >
> >
> > On Mon, Dec 6, 2010 at 10:50 AM, Simon Laws <si...@googlemail.com>
> > wrote:
> >>
> >> >
> >> > If you don't have any other preference how about using the hazelcast
> >> > binding
> >> > so that the async invocations work across the distributed domain? See
> >> >
> >> >
> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/domain-hazelcast/src/main/java/org/apache/tuscany/sca/binding/hazelcast/
> >> >
> >> > ...ant
> >>
> >> I'll take a look.
> >>
> >> Simon
> >>
> >
> > Actually, right after i posted that i remembered TUSCANY-3792 about the
> > distributed domain being broken, so if you want to avoid getting tangled
> up
> > in that it might not be the best one to use first.
> >
> > ...ant
> >
> >
>
> Ok, understood, thanks for the warning.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Re: Async infrastructure improvements
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Dec 6, 2010 at 10:55 AM, ant elder <an...@apache.org> wrote:
>
>
> On Mon, Dec 6, 2010 at 10:50 AM, Simon Laws <si...@googlemail.com>
> wrote:
>>
>> >
>> > If you don't have any other preference how about using the hazelcast
>> > binding
>> > so that the async invocations work across the distributed domain? See
>> >
>> > https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/domain-hazelcast/src/main/java/org/apache/tuscany/sca/binding/hazelcast/
>> >
>> > ...ant
>>
>> I'll take a look.
>>
>> Simon
>>
>
> Actually, right after i posted that i remembered TUSCANY-3792 about the
> distributed domain being broken, so if you want to avoid getting tangled up
> in that it might not be the best one to use first.
>
> ...ant
>
>
Ok, understood, thanks for the warning.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Async infrastructure improvements
Posted by ant elder <an...@apache.org>.
On Mon, Dec 6, 2010 at 10:50 AM, Simon Laws <si...@googlemail.com>wrote:
> >
> > If you don't have any other preference how about using the hazelcast
> binding
> > so that the async invocations work across the distributed domain? See
> >
> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/domain-hazelcast/src/main/java/org/apache/tuscany/sca/binding/hazelcast/
> >
> > ...ant
>
> I'll take a look.
>
> Simon
>
>
Actually, right after i posted that i remembered TUSCANY-3792 about the
distributed domain being broken, so if you want to avoid getting tangled up
in that it might not be the best one to use first.
...ant
Re: Async infrastructure improvements
Posted by Simon Laws <si...@googlemail.com>.
>
> If you don't have any other preference how about using the hazelcast binding
> so that the async invocations work across the distributed domain? See
> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/domain-hazelcast/src/main/java/org/apache/tuscany/sca/binding/hazelcast/
>
> ...ant
I'll take a look.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Async infrastructure improvements
Posted by ant elder <an...@gmail.com>.
On Mon, Dec 6, 2010 at 9:30 AM, Simon Laws <si...@googlemail.com>wrote:
> I'd also like to convert a remote binding to demonstrate
> native async operation.
>
>
If you don't have any other preference how about using the hazelcast binding
so that the async invocations work across the distributed domain? See
https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/domain-hazelcast/src/main/java/org/apache/tuscany/sca/binding/hazelcast/
...ant
Re: Async infrastructure improvements
Posted by Simon Laws <si...@googlemail.com>.
A quick update.
On Friday I checked some changes in as a first pass of an
implementation of the 2nd option in my previous mail to this thread.
I.e. making the forward reference responsible for installing a
response listener and updating the EndpointReference and Endpoint, and
the associated invocation chains, to make them responsible for
processing any asynchronous responses along the response part of the
forward chain (on both reference and service side).
There are some new implementation and binding provider interfaces for
creating an AsyncResponseInvoker on the service and reference sides.
I'm updating the wiki page [1] to show the service side as well as the
reference side.
The status of the changes is that they are currently very rough with
lots of outstanding issues (i'll post separately on them) and the
updated implementation sample demonstrates the native async operation
with binding.sca. The limited nature of this though means that the
databinding interceptor doesn't get invoked. So my next steps at to
improve the sample to prove that the approach will really work and,
assuming that it does, start improving the code to fix all the issues
I'm aware of. I'd also like to convert a remote binding to demonstrate
native async operation.
[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/
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Async infrastructure improvements
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Nov 19, 2010 at 3:31 PM, Simon Laws <si...@googlemail.com> 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