[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
| Re: [ecf-dev] [Gsoc] - Remote serice Testing TooL | 
Hi Salinda,
On 7/10/2013 11:19 AM, Salinda Jayawardana wrote:
Hi Markus and all
I am bit confused about the actual usecase when I start coding So 
please help me to verify the requirement correctly
According  to my understanding I am trying to crate a tool which can 
be use for following use case
user create  a Interface called Ical
public Interface Ical{
int add(int a, int b);
}
Then user create another interface Iacal (advance cal)
public interface Iacal extends IAsyncRemoteService{
  double funcA(int a, IAsyncCallaback<Double> callback);
}
Let me explain a little bit.
On a remote service consumer, when a remote service is discovered, ECF 
remote services creates a proxy for accessing that service. That proxy 
is required by the OSGi spec to implement all of the service interfaces 
that are expored by the remote service host.  For example,  if the 
remote service host exports com.me.lcal as the service interface, the 
proxy must also implement the same version of com.me.lcal...so that this 
code will work on the client:
com.me.lcal lcalService = (com.me.lcal) proxy;
// make a synchronous call
int result = lcalService.add(1,2);
This is all just 'normal'/specified OSGi remote services.
ECF's proxy creation has another capability, however, and that's the use 
of an 'asynchronous' version of the service interface.  When ECF creates 
the proxy *iff* there is another service interface available...in either 
the same package (or some other package specified via an ecf-specific 
service property), ECF will create the proxy so that it *also* 
implements the asynchronous version of the interface.
Now...the ECF-specific conventions that have been set up are that this 
asynchronous version of the service interface must:
1) extend IAsyncRemoteService
2) have a class name that ends with 'Async'...e.g. lcalAsync extends 
IAsynchRemoteService
3) Have methods with signatures...e.g. for lcal:
public void addAsync(int a, int b, IAsyncCallback<Integer> callback);
public IFuture<Integer> addAsync(int a, int b);
So that the consumer of the remote service can do this:
com.me.lcalAsync lcalAsyncService = (com.me.lcalAsync) proxy;
// then make a call like this
IFuture<Integer> lcalFuture = lcalAsyncService.addAsync(1,2);
// do something with future
This is explained in more detail with examples here [1].
Now...why go through all that explanation?   Well, mainly because I 
wanted to say:  although Salinda is right that the user *can* create 
the  asynchronous version of the service interface (i.e. 
com.me.lcalAsync) by hand...i.e. by typing it out in a new .java 
file...*another* way to get/create this interface would be to use 
annotations and *generate* the async interface with tooling.  For 
example, it would be very possible to define an annotation...and use the 
Eclipse Annotation Processing API (apt) and when the following was 
created in an editor, have the tooling/apt *create/generate* the 
lcalAsync interface:
public interface lcal {
@AsyncMethod
public int add(int a, int b);
}
This would result (by default) in the creation of a file: 
lcalAsync.java...and the compiler would/could automatically create with 
contents (for example):
public interface lcalAsync extends IAsyncRemoteService {
public void addAsync(int a, int b, IAsyncCallback<Integer> callback);
public IFuture addAsync(int a, int b);
}
I started some work on just such an annotation processing tool (built on 
Eclipse apt)...but didn't finish it.  The code is in this project [2].  
Salinda...you should probably take a look at this to see what you 
think.   It's not done yet, but it was beginning to function...and you 
might want to use this as the basis for further work on annotations and 
tooling for asynchronous remote services development.
Then user Implement above 2interfaces in a class
Then user create Test Class to test above service ,But current test 
fream-work(done at last gsoc project)  cannot test Aysncronus  service
So my task here is to modify the test framework run both type service 
,user can category service using annotation
According to the my proposal i was planing to use a service interface 
define both type of service ,service type will be identifyign  using 
annotation but I was cording I feel this is wrong since Aysnc service 
need new interface which extends from IAsyncRemoteService.
Could you please guid me to identify the real requirement of this new tool
The requirements are kind of up to you.   I think that there are some 
nice things to do with with (e.g.) generating async services 
interfaces...as per above.  OTOH, there is also a strong need for 
tooling *just for OSGi [synchronous] remote services*. E.g...perhaps if 
someone annotated a service interface like this
@RemoteService
public interface IMyService {
public int add(int a, int b);
}
Some java could be generated that setup the proper OSGi-standardized 
remote service properties...with an appropriate ecf discovery and 
distribution provider (maybe such providers could be optionally 
specified in the annotation, etc).
In any event...I think there's a lot of potential for simplifying the 
creation, registering, etc of remote services using annotations...and/or 
the creation/use of ECF's asynchronous proxies.   Where you decide to 
put emphasis is up to you.  From my chair both are needed/important.
Also I have develop some code How can i share that code (since I 
cannot commit elf location)
 So...do you mean where/what repo?  During the Google summer of 
code...I'm not sure...but I had thought that Google provided either an 
svn or git server for project source...but if that's not the case 
perhaps you could create/use a github account?  If that doesn't work out 
for whatever reason, we could probably add you as a committer to the ECF 
github repo [3].   In any event...We should try to get a new repo 
together for you.  Let us know if either SOC or github doesn't have what 
you need.
Thanks,
Scott
[1] http://wiki.eclipse.org/ECF/Asynchronous_Remote_Services
[2] 
http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/incubation/bundles/org.eclipse.ecf.remoteservice.apt.java6
[3] http://github.com/ECF