[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[ecf-dev] asynchronous remote services tooling
|
Hi Folks,
Last week, I did some work on asynchronous remote services...i.e.
accessing remote services asynchronously/via asynchronous messaging. I
made a couple of blog postings about this:
http://eclipseecf.blogspot.com/2010/04/asynchronous-remote-services-part-2.html
http://eclipseecf.blogspot.com/2010/04/osgi-remote-services-from-ecf.html
And there's a new wiki page describing this work, which I intend to add
to over time (with some help).
http://wiki.eclipse.org/Asynchronous_Remote_Services
This work allows the service interface creator to define a type-safe
asynchronous interface...that will be *guaranteed* not to block...and
with ECF remote services the consumer of that remote service will have a
proxy made available to them at remote service discovery time that
*implements* that type-safe asynchronous interface. All the consumer
has to do is to cast the proxy to the asynchronous service interface and
call the methods.
The additional work here belongs with the service interface designer.
In addition to the regular/synchronous service interface, the service
interface designer *can* create another service interface that defines a
consumer's asynchronous interaction with the same remote service.
So, for example, let's say that the service interface for the remote
services is this:
public interface IFoo {
public String foo(String bar);
}
*Now* a second (asynchronous) service interface can be created in the
same package as IFoo:
import org.eclipse.ecf.remoteservice.IAsyncCallback;
import org.eclipse.ecf.remoteservice.IAsyncRemoteServiceProxy;
public interface IFooAsync extends IAsyncRemoteServiceProxy {
public void fooAsync(String bar, IAsyncCallback<String> callback);
}
And then at consumer discovery/use time, the ECF distribution system
with create an implementation of IFooAsync (as well as IFoo). The
consumer can call fooAsync if they want to have the foo method
asynchronously invoked...and this method invocation will *not* block.
Further the callback.onSuccess/onFailure methods will be invoked when
the result is asynchronously received. The service implementer *only
has to declare this IFooAsync interface*...they do not have to provide
any implementation *at all*. The ECF remote services code will add the
implementation of IFooAsync to the consumer's proxy at remote service
discovery time.
But, you might say...isn't it sort of a pain to create this IFooAsync
interface? Answer: yes it is a little bit of extra work for the
service creator (although none for the service consumer). To make this
even easier/automate it I've started some work to use java 5 annotations
to allow annotations to lead to the automated creation/generation of the
IFooAsync interface class.
With these annotations, the idea is that you could annotate the service
interface like this:
import org.eclipse.ecf.remoteservice.AsyncService;
@AsyncService
public interface IFoo {
public String foo(String bar);
}
And with a new annotation processor, based upon the Eclipse APT tool an
asynchronous service interface is *generated* by Eclipse as the IFoo
interface is created/edited. So the following IFooAsync interface
declaration gets automatically generated for you as you edit the IFoo
service interface:
import org.eclipse.equinox.concurrent.future.IFuture;
import org.eclipse.ecf.remoteservice.IAsyncCallback;
public interface IFooAsync extends
org.eclipse.ecf.remoteservice.IAsyncRemoteServiceProxy {
public void barAsync(java.lang.String bar,
IAsyncCallback<java.lang.String> callback);
}
I've just started this annotation processor (based upon java6
annotations), and I've released the annotation processor bundle to the
ECF incubation area for the time being for further development:
path: /cvsroot/rt
module:
org.eclipse.ecf/incubation/bundles/org.eclipse.ecf.remoteservice.apt.java6
And I've created this enhancement request for this work:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=309732
Please join this enhancement request, and consider contributing to this
tooling effort.
Thanks,
Scott