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