Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] [GSOC] ECF Tooling
Hi Sakith,

On 3/17/2014 6:55 AM, sakith indula wrote:
hi all,

last few days i was spending my time on researching how osgi remote services working and studying how eclipse based tooling woks by using and some other eclipse tools[1][2][3].i wold like to know that am i heading correct path on both osgi and eclipse tooling.

if i understand the requirements correctly i should do following things.
when user create OSGI remote service using ECF SDK without using any tool they should go through following steps

1) create a interface and include all the methods 
2) create a implementation for above interface
3) create a remote container
4) register the service

Yes...that's pretty much right.   The only reason I say 'pretty much' is that '3' isn't necessary...if the developer uses one of the existing providers...OR can be an area of customization (if the developer want's to create/use their own provider).

I would say this would be the sequence (assuming using an existing provider, as per the tutorial [A]):

1) Create a interface and include all the methods
2) Create an implementation for above interface
3) Register the service (as a remote service...by specifying the standardized remote service properties)

You will certainly notice that the above three steps are...except for the properties in 3...*exactly* the same as the workflow for creating/registering a local OSGi service.   Note that the 3 above...can all be done via any existing tooling and/or frameworks...e.g. Eclipse, bndtools, declarative services, blueprint, etc.   This is all 'pure' OSGi (will run on any spec-compliant framework+remote services implementation).

But, for remote services the *underlying effects* of the service registration (3) are more significant...because the service is made available for remote access instead of access only through the local OSGi service registry.   I'm going to describe these effects of (3) briefly...not because the remote service programmer must know about them for all use cases...but because sometimes it's important for the programmer to know about these effects...so that they can customize them, change them, etc. for their particular remote services.

3) Register the remote service (the following all happens as a result of bundleContext.registerService(<svc interface>,<service impl>,<osgi remote service properties>)

With ECF's RS/RSA impl install/in-place the following happens during 3

    3a) A remote service container is selected based upon the desired distribution provider via service.exported.configs (service.exported.configs is an OSGi-standard service property...details about it's effects/behavior exist in chap 100...the Remote Services specification).
    3b) The remote service is *exported* by the remote service container.  What this means is specific to the distribution provider, but generally what it means (and how it's implemented in ECF) is that the remote service container makes the service available for remote access...via a http, via some other protocol.
    3c) The meta-data about the exported remote service is *published* for discovery by consumers.  What this means for ECF is that a discovery provider(s) are used (e.g. zookeeper, zeroconf, slp, dnssd, custom/private discovery, file-based, etc) is used so that consumers can have a way to discover the now available remote service.
    3d) The call to register the remote service is finished and the calling thread returns

ECF RS/RSA provides the means to customize 3a-d:
I) It's possible to customize/replace the service that implements 3a...and replace it with your own.  
II) It's also possible to easily create a whole new distribution provider...so that it will be used for exporting the service (3b).  For example, this tutorial [B] shows how to create a simply rest-based distribution provider.
III) It's also possible to either use any/all/several discovery providers...and/or create/use your own...for publishing/discovery (3c)

When it comes to tooling for ECF's remote services/RSA impl, I think there are two main/important areas of focus:

i) Providing tooling for simplifying the creation and registration of OSGi Remote Services (1-3 above)
ii) Providing tooling for using ECF's flexibility/customization/provider creation (I - III above)


so by default  user have to do that manually by one step at a time.once we provide tool to create osgi remote service so then they could create osgi remote service projects by using  eclipse "New Project wizard". under new project wizard there should be "ecf-project" sub menu under "ecf-project" sub menu there will be a "OSGI remote service project" once we click on it, it should pop up "Create osgi remote service project" wizard. by using parameters we collect from that wizard we generate eclipse java project which include service interface, java class which implement that interface,activator that register the service(java class which import and uses org.osgi.framework.ServiceRegistration package to register the service),and other dependencies.

We already have a PDE project template that integrates with the New Project Wizard...that is at least one instance of doing what you describe...i.e. creating a project that already has new service interface (1), that has a trivial implementation (2), and has the code to register the service as a remote service (3).   If you install the ECF Eclipse SDK, you will get this plugin [C].    This plugin adds two new PDE example templates...so that when in Eclipse you choose 'New->Plugin Project->Next->Next there will be two remote service templates added (by [C]) for remote services.


is this the correct approach..? please advise me.

For your GSOC project you could focus on several things:

10) Adding/enhancing the existing PDE templates/examples [C].  There's lots of room for additional PDE templates...and these templates/examples could make things much easier for remote service developers.  This uses/depends upon PDE templates, however, so it's only usable with PDE specifically (not with bndtools or anything else)
11) Creation of *brand new* tooling...for either 1-3 (OSGi Remote Services...i above) AND/OR ECF customization (ii above).

IMHO both of the above (10 and/or 11) would be valuable...since IMHO there is lots of improvement to be made for tooling for OSGi (remote) services in general...i.e. making it easier to create/implement/register OSGi services...with standardized (and ECF-specific) properties (10), and there's also lots of room for making the ECF-customization (use of custom distribution providers, custom discovery providers, etc) easier, simpler, better tooling.

10 is more clear-cut...i.e. we have one PDE project template already...adding more won't be too difficult once you understand PDE templates.   To my mind this could be a pretty clearly-defined project, of relatively limited scope.
11 is more open-ended...and therefore more technically challenging...but of potentially much higher value IMHO

Does this help?   Hopefully it at least doesn't hurt :).   FWIW...I think you are on the right path...essentially looking at the developer workflow for remote services (definition/impl/registration/testing/deployment/etc) and trying to find ways to make that whole workflow easier/simpler/more understandable/more examples/more customizable by programmers.

Thanks,

Scott

[A] https://wiki.eclipse.org/Tutorial:_Building_your_first_OSGi_Remote_Service
[B] https://wiki.eclipse.org/Tutorial:_Creating_a_RESTful_Remote_Service_Provider
[C] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/tooling/plugins/org.eclipse.ecf.remoteservices.tooling.pde




Best Regards,
Sakith.


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

Back to the top