[ecf-dev] asynchronous remote services tooling

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

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