[
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
