ECF is of course a long time consumer
of the OSGi framework...specifically for our impl of the OSGi
Remote Services specification [1]. And for what are obvious
reasons we have been using Equinox as the primary implementation.
For our RS/RSA impl, however, our consumers have asked to run
RS/RSA on other frameworks...e.g. Felix, Concierge, etc. That's
one major reason why we've gone through considerable trouble to
allow our consumers to do so [2].
OSGi Remote Services/RSA is relevant to the IoT world, as of
course these 'things' frequently need to communicate with each
other...aka provide and use services to/from each other...as well
as use/consume services...via servers on the Internet. The
protocol-and-mechanism-independence of OSGi Remote Services spec
provides integration, portability, and interoperability (as well
as versioning, security, management and other features for
RS/RSA). I'm currently working on, for example, a remote
services demo/tutorial for the Raspberry Pi... that uses the Pi
both as remote service host (provider of remote services) and
consumer.
To produce this demo/tutorial I'm looking for:
1) Smallest disk and memory footprint possible
2) Install/configure/start a subset of OSGi bundles and services
(e.g. EventAdmin - yes, DS - no/maybe, jobs yes, extension
registry no/maybe, gogo console yes, httpservice/jetty maybe, etc)
3) Use a launcher that is small code...and allows the use of
multiple framework impls
4) Allow consumers to make their own choices...of framework impl
and individual standard service impls (e.g. Equinox EventAdmin vs.
Felix EventAdmin, DS, etc)
5) Be able to fully support OSGi Remote Services...e.g. through
using framework-provided service hooks as well as EventAdmin,
concurrent
One thing that occurred to me is that the current Equinox (or
Concierge) implementations can/could easily address the above very
well...if it was possible to launch the framework, and then
configure the framework (2) without necessarily pulling in the
launcher, p2, extension registry and dependencies, etc. I
suspect that something like this is what Pascal may mean by
'modularizing the Equinox code base'.
My idea would be to add a minimal starter class that does
something conceptually similar to the EclipseStarter class in
Equinox...but *only* supports the most minimal functionality (not
all that the EclipseStarter can do)
a) launching the framework itself (via standard
FrameworkFactory...which would allow use of any standard framework
impl)
b) configuring and starting an arbitrary set of bundles (and
setting start level, autostart/not)
For ECF's Raspberry Pi remote services demo the above would/will
be used to run only the framework (Equinox, Concierge, Felix or
other selected at start time), the set of hooks and services
(service hooks, wiring api, EventAdmin, jobs others) needed by ECF
RS, ECF RS itself, and any service and app functionality desired.
It occurred to me that something that did a and b might be useful
for other EF/IoT projects...and Jochen and others like
him...because it would enable other IoT use cases...e.g. using
Equinox, Concierge or something else, and using only
necessary/appropriate additional infrastructure as needed to
support the IoT app (RS, DS, p2, jobs, etc) in relatively
constrained environments.
I'm going to be working on a starter that does a and b for ECF's
Raspberry Pi remote service tutorial/example/demo. If others are
interested...and the appropriate committers will
contribute/collaborate...perhaps it could be opened as a
enhancement request/bug...to either Equinox or Concierge...or
both...I suppose.
Regards,
Scott
[1]
https://wiki.eclipse.org/ECF#OSGi_Remote_Services
[2]
https://wiki.eclipse.org/EIG:Install_into_Apache_Karaf
https://bugs.eclipse.org/bugs/show_bug.cgi?id=421569
On 4/24/2014 2:12 AM, Hiller, Jochen wrote:
Hi all,
As Kai just said below: it is important to be
able to run Eclipse SmartHome on “any” OSGi framework, to
benefit from optimizations for restricted/embedded
environments.
I am just trying to run Eclipse SmartHome on
Concierge to see about dependencies. Until now it seems that
the OSGi framework is more or less fine (I raised some minor
bugs to Concierge, https://bugs.eclipse.org/bugs/buglist.cgi?quicksearch=concierge
). The question is more about the OSGi compendium services
on top.
As a sample I am trying to run Equinox DS and
EventAdmin on Concierge. This is NOT working actually as
Equinox-DS is referring to some internal Equinox Framework
impl classes, e.g. excerpt from Manifest:
org.eclipse.osgi.framework.log;version="1.0.0",
org.eclipse.osgi.service.debug;version="1.0",
org.eclipse.osgi.service.environment;version="1.2.0",
org.eclipse.osgi.util,
On the other hand it was very easy just to
install Apache Felix SCR from http://artfiles.org/apache.org//felix/org.apache.felix.scr-1.8.2.jar
into Concierge without any issues.
Regarding footprint of these services: Equinox
is definitely NOT bad, just comparing DS and EventAdmin as a
sample:
82934
org.eclipse.osgi.services_3.3.100.v20130513-1956.jar
(includes all compendium service classes)
106701
org.eclipse.equinox.common_3.6.200.v20130402-1505.jar
194441
org.eclipse.equinox.ds_1.4.101.v20130813-1853.jar
32690
org.eclipse.equinox.event_1.3.0.v20130327-1442.jar
77932
org.eclipse.equinox.util_1.0.500.v20130404-1337.jar
Compared to Apache Felix:
216530
org.apache.felix.eventadmin-1.3.2.jar (includes compendium
service classes for DS)
267629
org.apache.felix.scr-1.8.2.jar (includes compendium service
classes for EventAdmin)
I see these options for further work:
1. Equinox services will be refactored to run
on ANY OSGi framework, in first case on Concierge
2. Add (selected ?) OSGi service
implementations (e.g. DS) from Concierge project with goal
of small footprint (see IoT minutes at https://wiki.eclipse.org/IoT/M2MIWG/Weekly_call_minutes#Update_on_Concierge)
3. We may think about a small “compatibility”
framework extension to Concierge to provide the missing
services for Equinox services. This should definitely be
optional, to let Concierge as small as possible
4. We do not use Equinox services on Concierge
and use others (Apache Felix ?) instead
Any thoughts?
Bye, Jochen
Hi Pascal,
Now, claiming that Equinox is not
suitable for IoT usage is erroneous and misleading.
After all it has been used by Kura, SmartHome and
others for years so it has to be good enough :)
Right, but „good enough“ is relative.
For SmartHome, we have an overall OSGi startup time of
at least 2 minutes on a RaspberryPi and a usual heap
size of > 100MB. I cannot exactly split this up
between the OSGi fw itself and the application on top of
it. Nonetheless, for an embedded device this is quite
huge and if there are possibilities to improve it, we
are looking at it. Especially if you hear all the NodeJS
folks talking about startup times on RasPis of only a
few seconds…
So this is why Eclipse SmartHome is
interested in Concierge. Not because it is a better
solution than Equinox, but because it promises to reduce
the footprint. If this is really the case and what
compromise might come with that is something that we
will find out on the way.
Another point why I think it is good
to have a second OSGi fw at Eclipse is that the projects
are forced to be put focus on compatibility with the
OSGi spec. There are MANY projects that have a hard
dependency on Equinox (e.g. EMF or Equinox DS), while
they should only have a dependency on „some“ OSGi
framework. This artificially reduces the popularity of
these projects as they can only run on Equinox, but not
anywhere else. This is something that the Felix guys do
much better - most of their libs also run nicely on
Equinox (and on Concierge!).
Equinox and Concierge have been
designed with different goals in mind.
Equinox has been designed to handle systems made of
a very large number of bundles (like we have in IDE
or RCP apps) which resulted in a number of caching
strategies to be implemented to improve startup
time, careful implementation of the service
registry, all of which increased the footprint of
the fwk. Also equinox has a number of extensibility
mechanisms (e.g. interception of resource loading,
pluggable storage formats) and additional services
like Location.
As for Concierge, since its inception, it has been
designed with the goal of being the smallest OSGi
implementation available.
Could those differences be dealt with by
modularizing the Equinox code base such that one
could build a framework a la carte and thus have a
right-sized fwk ? Most likeky but who wants to pay
for this ? :)
Now, claiming that Equinox is not suitable for IoT
usage is erroneous and misleading. After all it has
been used by Kura, SmartHome and others for years so
it has to be good enough :) Of course it is probably
not as good as commercial implementations but I'm
also wondering about Concierge's suitability and
this is why I initiated this discussion. I want to
understand the motivation, goals and expectations of
the projects trying to use concierge, and also
because as a community, Eclipse we will have to
position the two implementations wrt to each others,
as well as evaluate and evolved the ecosystem around
it (e.g. launching, building, testing, etc.)
Pascal
On 23/04/2014 4:06 PM, Doug Schaefer wrote:
What do we mean by "optimised"?
Couldn't we not go through and do that
optimization to address the size of Equinox? Or
are there big architectural differences that makes
it harder to do with Equinox?
(BTW, had the same question since I heard of
Concierge).
On Wed, Apr 23, 2014 at 2:23
PM, Thomas Eichstädt-Engelen <te@xxxxxxxxxxxxxx>
wrote:
Hi Pascal,
if “size” is equal to “resources” than this the
argument for Eclipse SmartHome for example.
Since Equinox is not really “optimised" for low
budget embedded devices (like Raspberry Pi)
Concierge seems to be a promising approach.
Best, Thomas E.-E.
_______________________________________________
iot-wg mailing list
iot-wg@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/iot-wg
_______________________________________________
iot-wg mailing list
iot-wg@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/iot-wg
_______________________________________________
iot-wg mailing list
iot-wg@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/iot-wg
