[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Async-Methods

Hi Eugen and all,

As Markus correctly indicated, it's not necessary to create a second service registration for asynchronous remote access. For everyone's reference, there is some example code and preliminary explanation of the asynchronous remote services support here [1].

All that's necessary for consumers to use the asynchronous support to declare a well-formed <service>Async interface...e.g. like Eugen has done with IExampleServiceAsync (Markus is correct that currently it must be in same package and bundle as the IExampleService). And Markus is also quite right that if the original service method is (e.g.):

public String getName();

then the correct form for the asynchronous callback method is:

public void getNameAsync(IAsyncCallback<String> callback);

Alternatively if the original form for the method has parameters...e.g.

public String getName(String param);

Then the async callback form would be:

public void getNameAsync(String param, IAsyncCallback<String> callback);

The general rule for the IAsyncCallback is that it is assumed to be the last parameter...i.e. after any existing ones.

Note also that there are *two* forms supported for async method access...the IAsyncCallback is one, and IFuture is the other...so for example the IExampleServiceAsync can also have:

public IFuture getNameAsync();

This doesn't have to be present in the IExampleServiceAsync interace, however. But if either form or both are present, they can be used.

Note that the returned type of IFuture.get() will be the same as the return value for getName() in the original service interface (String in this case). I'm trying to get the addition of generics to the graduated concurrent API [2] (I'm the author/contributor of the Equinox concurrent API...but I need to get the Equinox committers to actually apply the desired changes...thus the bug [2]). With a graduated concurrent API, one would be able to write declarations like this:

IFuture<String> getNameAsync();

and call

String result = future.get();

I think this would make the IFuture a little more usable/more accessible.

There is also some blog postings by me about asynchronous remote services [3] (which is cool if you ask me). More docs and examples are certainly needed...please join and contribute to the ECF documentation project [4].

One final thing...I've started but not yet completed an Eclipse plugin that uses annotations to automatically create the <service>Async interface. For example, you could do something like this:

@AsyncService
public interface IExampleService {

public String getName();

}

and Eclipse and the java6 annotation processor would/will create the IExampleService async class (and all methods) for you. The bundle is in the incubation area here [5]. If others would like to contribute to this annotation processor please open an enhancement request and we'll coordinate on finishing it (what's there barely works).

Thanks,

Scott

[1] http://wiki.eclipse.org/Asynchronous_Proxies_for_Remote_Services
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=309247
[3] http://eclipseecf.blogspot.com/2010/09/asynchronous-remote-services-choices.html


http://eclipseecf.blogspot.com/2010/04/asynchronous-remote-services-future-or.html

http://eclipseecf.blogspot.com/2010/04/asynchronous-remote-services-part-2.html
[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=329124
[5] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/incubation/bundles/org.eclipse.ecf.remoteservice.apt.java6