[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] remote services in java applications (no OSGi framework)

Hi Folks,

Progress to report on this.

I've created a new repo on ECF's github site entitled 'ServiceRegistry' [1]. Currently in this repo are the following java projects:

1) org.eclipse.ecf.osgi.serviceregistry. This project declares a top-level interface: org.eclipse.ecf.osgi.serviceregistry.ServiceRegistry [2]. Instances of this interface may be used by java application to register services, lookup/get/use services and service references, etc. Note that most of the methods on this interface essentially mimic those available in OSGi via a valid BundleContext. Also present is a ServiceRegistryFactory interface, that can be used to create/configure ServiceRegistry instances via the java ServiceLoader. Also present are a few classes in the launch sub-package, that allows the launching to be configured (i.e. what bundles are included).

2) org.eclipse.ecf.osgi.serviceregistry.equinox. This project provides an Equinox-based implementation of the ServiceRegistry interface.

3) org.eclipse.ecf.test.osgi.serviceregistry. This is a test project that uses the Equinox-based implementation to test the ServiceRegistry API.

4) org.eclipse.ecf.osgi.serviceregistry.pojo. This provides a PojoSR-based implementation of the ServiceRegistry interface.

Note that all of the above are pure java projects, not plugin/osgi projects.

I've tested the PojoSR-based implementation with ECF RS/RSA...and it works! What this means is that for RS/RSA either hosts (servers) and/or consumers (clients), the same code that exposes and uses Remote Services in OSGi can now work in a java-only environment (i.e. without the OSGi framework). This makes possible a number of very interesting Remote Services/RSA use cases...e.g. Java-based clients with OSGi Servers, Java Servers with OSGi Clients (e.g. Eclipse/RCP), and etc, all with RS/RSA discovery and/or whatever distribution provider, DS, ServiceTrackers, etc as desired. The utility of Remote Services for Internet of Things....where a full OSGi framework may not be assumed/present...is pretty obvious.

My next intention is to create a small example...perhaps creating a java8-only client for the TimeService. If people have other examples that they are interested in, or would like to collaborate on testing and/or examples, please let me know.

Scott

[1] https://github.com/ECF/ServiceRegistry
[2] https://github.com/ECF/ServiceRegistry/blob/master/projects/org.eclipse.ecf.osgi.serviceregistry/src/org/eclipse/ecf/osgi/serviceregistry/ServiceRegistry.java


On 4/22/2015 9:42 AM, Scott Lewis wrote:
Hi Folks,

Some of you may be aware of pojosr: https://code.google.com/p/pojosr/

It's an implementation of the OSGi service registry that does not require running a complete OSGI framework.

Something I've been thinking about for some time, and have now acted upon is that ECF's impl of OSGi Remote Services can/could use pojosr...rather than only running on an 'real' OSGi framework (equinox, eclipse, felix, karaf, etc). What this would allow would be that people could host and/or consume remote services...with exactly the same service registration (host) and lookup/injection (consumer) API, and all the other advantages of RS (e.g. dynamics, versioning, etc)...as plain-ol java applications.

There are significant limitations, of course (no dynamic bundle install, update), but for some use cases this would allow people to create smaller java apps, with no OSGI framework, but that host and/or consume Remote Services.

I have done/am doing some of this work, and will soon make what I've done available on our github location [1]. I just wanted to find out if there was interest from this community, and see if others have other use cases, and/or might want to contribute to such an effort.

Scott

[1] https://github.com/ECF




_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev