Some further news on this:
I've added a new implementation of the ServiceRegistry API. This
implementation uses the most recent release of the Apache Connect
project (0.1.0). Apache Connect is a Felix sub-project which was
started from the PojoSR codebase, and was recently re-energized.
The Connect-based ServiceRegistry implementation is here: [1].
To summarize: It's now possible to do Remote Services/RSA (host
and/or consumer) without running an OSGi Framework (i.e. Java
vm-only). There are now two functioning implementations here [2]:
1. An earlier one I created based upon Equinox (as an embedded
framework) [3], and
2. The one just created based upon Apache Connect [1].
I can also tell you that there does seem to be quite a lot of
interest among the EEG corporate members about standardizing a
ServiceRegistry API, so it does seem likely to me that some
standardization efforts will occur during the R7 spec effort, and I
will attempt to participate in them to the extent I can.
Scott
[1]
https://github.com/ECF/ServiceRegistry/tree/master/projects/org.eclipse.ecf.osgi.serviceregistry.connect
[2] https://github.com/ECF/ServiceRegistry
[3]
https://github.com/ECF/ServiceRegistry/tree/master/projects/org.eclipse.ecf.osgi.serviceregistry.equinox
On 5/16/2015 6:12 AM, Wim Jongman wrote:
>
> Great work Scott. Congratulations.
>
> Regards,
>
> Wim
>
> On May 15, 2015, at 20:34, Scott Lewis
<slewis@xxxxxxxxxxxxx
> <mailto:slewis@xxxxxxxxxxxxx>> wrote:
>
> 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
> <mailto: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
>
>
> -------------------------
>
> ecf-dev mailing list ecf-dev@xxxxxxxxxxx
> <mailto: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
>
>
>
> _______________________________________________ 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
|