OSGi Community Event 2014 Abstract: This presentation tells how OSGi can help developing a distributed and cloud ready Internet of Things platform. IoT brings unprecedented complexity both in terms of technological variety and new development paradigms. Modularity offered by OSGi is the key concept to build maintainable and robust IoT platforms. OSGi declarative services and dependency injection mechanism allow service producers and service consumers to interact with full respect of mutual component boundaries: this is the fundamental requirement to enable important aspects of an IoT platform like multi-tenancy, separation of concerns between M2M protocols management and application development and dynamic services management. Plat.One IoT platform revolves around the OSGi technology: this presentation describes our lesson learnt during several years of “hands-on OSGi activities” and development. Speaker Bio: After graduating in Physics with specialisation in High Energy Physics, he started working in industrial automation and machine to machine applications. Since 2006 he joined Abo Data and he started the development of PLAT.ONE IoT and M2M platform. Currently, he is leading the PLAT.ONE development team. PLAT.ONE has already been adopted by major telco operators and system integrators to enable a new breed of cloud-based IoT applications and services

1. Many
Bundles
of
Things
How
OSGi
can
help
developing
a
distributed
and
cloud
ready
IoT
pla>orm
Ma@eo
Rulli,
PLAT.ONE
Development
ABO
DATA

2. Overview
• Internet
of
Things
and
OSGi
• PLAT.ONE:
a
IoT
OSGi
pla>orm
• Hands
on
OSGi
from
PLAT.ONE
standpoint
• Lesson
learnt
2
/
23

3. IoT
Reduc*onism
Scien&fic
reduc&onism
is
the
idea
of
reducing
complex
interacOons
and
enOOes
to
the
sum
of
their
consOtuent
parts,
in
order
to
make
them
easier
to
study
and
model
3
/
23

4. ReducOonism
needs
boundaries
EffecOve
development
of
IoT
verOcals
and
applicaOons
needs
well
defined
boundaries
A
clear
definiOon
of
boundaries
enables
the
reducOonist
approach
and
reduces
the
impact
of
complexity
and
technological
heterogeneity
4
/
23

5. More
intelligence
at
the
edge
Isolated
and
loosely
coupled
services
are
more
easily
distributable
across
different
execuOon
contexts:
no
just
JARs
but
services
This
enables
to
re-­‐use
and
install
sw
modules
at
the
edges
of
the
IoT
infrastructure
when
needed,
pushing
intelligence
in
proximity
of
data
sources
5
/
23

6. 6
PLAT.ONE
Service
Enablement
Data
AcquisiOon
Device
Management
Data
Storage
Service
Systems
IntegraOon
Device
IntegraOon
PLAT.ONE
Data
Management
Data
Tagging
Data
AugmentaOon
Data
Security
Structured
Data
Un-­‐structured
Data
Streaming
Data
…
Plat
Energy
Plat
City
Domain
Specific
Pla@orm
Smart
City
Smart
Metering
AutomoOve
Healthcare
Smart
Food
...
Domain
Specific
Kits
/
23

7. Boundaries
define
modularity
that
in
turns
lets
services
pla:orms
to
emerge
The
noOon
of
pla>orm
fosters
the
growth
of
IoT
communiOes
7
IoT
solu-ons
S1
S2
S3
...
OSGi
PLAT.ONE
IoT
Pla>orm
S1
S2
...
S1
S2
...
S1
...
devices
integra-on
services
IoT
applica-on
services
/
23

8. OSGi-­‐based
IoT
pla>orm
Modularity
lies
at
the
foundaOonal
levels
of
OSGi
This
is
why
we
choose
to
adopt
OSGi
as
the
execuOon
environment
for
PLAT.ONE
IoT
pla>orm
8
/
23

9. OSGi
benefits
Lightweight
improvement
of
IoC
principle
through
DeclaraOve
Service
and
Dependency
InjecOon
mechanism
9
No
more
violaOon
of
the
module
boundaries:
Service
srv
=
new
ServiceImpl(arg1,arg2,...);
/
23

10. OSGi
benefits
(conOnued)
• Easily
embeddable
in
hw
constrained
environments
• Solve
JAR
hell
• Dynamic
updates
and
lifecycle
managment
of
bundles
and
services
• DS
fits
the
concept
of
management
M2M
protocol
drivers
10
/
23

11. OSGi
is
mature
11
Technology
Scope
Maintained
by
AcOveMQ
Message
Queueing
System
ASF
Camel
Enterprise
IntegraOon
Pa@erns
ASF
Cayenne
ORM
ASF
CXF
WS-­‐Stack,
REST
and
more
ASF
DBCP
DB
connecOon
mngmt
ASF
Groovy
Dynamic
Language
for
the
Java
pla>orm
Groovy
community
Hazelcast
Distributed
Caching
Hazelcast
community
Ne@y
TCP/UDP
sockets
Ne@y
community
Quartz
Scheduling
library
Quartz
community
Swagger
Framework
for
describing,
producing,
consuming,
and
visualizing
RESTful
web
services
Reverb
and
the
Swagger
Community
...
/
23

12. IDE
Support
12
• We
found
Eclipse
RCP
a
great
IDE
to
develop
OSGi
bundles
and
services
and
to
create
bundles
out
of
third
party
libraries
• PDE
comprehensive
OSGi
tooling
is
a
great
technology
to
undertake
OSGi-­‐based
SW
development:
real-­‐Ome
compilaOon,
cycles
detecOon,
bundle
resoluOon
validaOon,
etc.
/
23

13. OSGi
Deployment
Eclipse
RCP
makes
the
deployment
of
OSGi-­‐
based
products
easy
thanks
to
feature
and
products
configuraOon
13
You
can
use
the
launch
config
to
automaOcally
generate
the
products
and
feature
definiOon
/
23

14. OSGi
Deployment
Features
projects
define
all
the
bundles
required
by
the
OSGi
product
Also
feature
projects
can
be
built
from
launch
configuraOons
14
/
23

15. 15
Products
and
features
collect
all
pieces
of
informaOon
needed
by
Eclipse
to
export
a
standalone
OSGi-­‐based
product

16. • Deltapack
can
be
used
to
generate
OSGi
products
for
target
pla>orms
other
than
the
one
running
your
Eclipse
instance
– It
is
enough
to
download
the
deltapack
from
eclipse
site
and
unpack
within
your
local
eclipse
folder
– Than
you
can
configure
the
delta
pack
target
pla>orm
with
Windows→Preferences→Plug-­‐in
Development→Target
Pla:orm
16
OSGi
Deployment
/
23

17. Headless
Builds
Features,
products
files
and
deltapack
enable
headless
builds:
OSGi
products
can
be
automaOcally
built
overnight
ANT
command
to
launch
PDE
build
engine
is
quite
simple:
<exec
dir="${buildDirectory}pluginscom.abodata.plat1.${serverid}.build"
executable="cmd"
failonerror="true">
<arg
value="/c"/>
<arg
value="${buildDirectory}eclipse.exe"/>
<arg
value="-­‐nosplash"/>
<arg
value="-­‐application"/>
<arg
value="org.eclipse.ant.core.antRunner"/>
<arg
value="-­‐buildfile"/>
<arg
value="productBuild.xml"/>
<arg
value="-­‐DbuildDirectory=${buildDirectory}"/>
<arg
value="-­‐vm"/>
<arg
value="${java.path}"/>
</exec>
17
/
23

18. Lesson
Learnt
• Interface-­‐based
programming
and
Dependency
InjecOon
– Always
declare
interfaces
in
a
separate
bundle
with
respect
interface
providers
and
consumers
– To
keep
under
control
bundles
number,
package
similar
providers
together
and
declare
more
component.xml
files
in
OSGI-­‐INF
folder,
one
per
provider
– Reduce
the
exported
packages
through
the
Dependency
InjecOon
mechanism
– Strive
to
avoid
explicit
wiring
between
bundles
18
/
23

19. Lesson
Learnt
• When
on-­‐boarding
third-­‐party
projects
through
the
Eclipse
feature,
avoid
including
unnecessary
project
dependencies
• It
is
a
good
pracOce
to
turn
projects
dependencies
into
self-­‐standing
bundles
19
/
23

20. Lesson
Learnt
• ImporOng
the
exported
bundles
and
uses
direcOve
can
help
resolving
obnoxious
ClassCastExcep*on.
See
for
instance
– OSGi
In
AcOon,
R.S.
Hall
and
others,
Manning
2011
–
Chapter
5
20
/
23

21. Lesson
Learnt
• Not
everything
can
be
dynamic:
core
components
of
the
pla>orm
cannot
come
and
go
without
disrupOve
effects.
OSGi
does
not
mean
dynamicity
for
free
21
/
23

22. Lesson
Learnt
• DynamicImport-­‐Package
is
not
as
evil
as
everyone
suggests:
as
an
example,
Hibernate,
CXF,
Hazelcast
bundles
need
this
in
their
manifest
in
order
to
resolve
interfaces
at
run-­‐
Ome
to
publish
WS,
perform
ORM
mapping
and
to
marshall
objects
• Yet,
dynamic
imports
should
only
be
used
in
«sealed»
bundles:
do
not
use
this
direcOve
in
development
bundles
22
/
23

23. Thanks!
ma@eo.rulli@abodata.com
h@ps://twi@er.com/PlatOneIOT
h@p://www.platone.io/
23
/
23