[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)

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