Building Flexible Telemonitoring Software with OSGi

Using OSGi to Build Better Software
Lessons from a Telemedicine Software for Smartphones and
Desktop Systems
Doreen Seider (DLR - German Aerospace Center)
ApacheCon NA 2011 (Vancouver, 11/11/2011)

Slide 1
ApacheCon 2011 > Doreen Seider> Using OSGi to Build Better Software > 11.11.2011

Outline

What software did we want to have?
How did we develop it with OSGi?
What did we learn?

Slide 2

What kind of software did we want to have?

Slide 4

Telemonitoring Software

Supports remote monitoring of patients (e.g. in rural areas)
Captures vital sign of patients from medical devices
Sends measurements to doctors sitting in a medical service center
Executable on mobile devices and desktop systems
Supports any kind of medical device and medical service center

Slide 5

In Comparison to That: Flexible Telemonitoring
Software

Slide 8

Flexible Telemonitoring Software Technology

Plug&Care Connector

Slide 9

Plug&Care Connector
Requirements

1. Both on smartphones (like Android or Windows Mobile) and on desktop
system executable

2. Support of any device and service center – even later on – without
modification of the Plug&Care Connector

Slide 10

How did we develop it with OSGi?

Slide 11

Plug&Care Connector‘s Architecture

Slide 12

OSGi Principles: Bundles and Services

OSGi is specification of a modular service platform written in Java

„modular“
It is a module layer above the Java package layer
Classes are assembled to packages  packages are assembled to
bundles (modules)  bundles are assembled to applications

Slide 13


By default bundles are totally encapsulated
Bundles can make use of each other by explicit exports and imports of
packages

Slide 14


OSGi is specification of a modular service platform written in Java

„service“
In a perfect world bundles make use of each other via services
Eliminates direct dependencies to each others implementation

Slide 15


Slide 16


Service definition and implementation are separated to each other
No direct implementation dependencies
Enables loose coupling
Important for assembling bundles (jars) to applications

Slide 17


Slide 18

OSGi Principles: Declarative Services (DS)

OSGi Runtime calls the bundle and not other way around

Slide 19


Bundles provide a set of so called component descriptions
A component is a Java class
Each describes which services a component provides and consumes
OSGi runtime injects all required services at start up

Slide 20


Benefits of Declarative Services
Less complexity in own code
Better testing (no mock up of OSGi runtime needed)

Slide 21

Fulfilling Requirements with the help of OSGi

system executable
Platform independency by realizating it as OSGi application
OSGi serves as an abstraction layer of underlying diversity
Using different implementations of OSGi for different platforms
Assembling bundles to the Plug&Care Connector application
according to its deployment platform

Slide 22

Used OSGi Implementations: Equinox

For desktop
Eclipse Software Foundation
OSGi implementation under Eclipse

Decision was made due to experiences from other software we develop

Slide 23

Used OSGi Implementations: mBS Mobile

For Smartphones
ProSyst company (http://prosyst.com)
Android, Windows Mobile, Nokia S60
http://dz.prosyst.com/mbsmobile/

Decision was made due to supported platforms at that time and due to
development status

Slide 24

Integration in Android

Slide 25

OSGi Management on Android

Slide 26

OSGi Applications on Android

Slide 27

OSGi-Stack: mBS Mobile
Development Environment in Eclipse

Slide 28

OSGi-Stack: mBS Mobile
Development Environment in Eclipse

Slide 29

Designing Plug&Care Connector
Abstraction with the use of Console

OSGi comes with a console for management purposes
It is useful for testing i.e. interacting with the application if no GUI is
available yet
Own commands can be provided
Different OSGi implementations might have different console APIs
Abstraction of console APIs is needed to hide them for the underlying
application layers writing to the console

Slide 30

Abstraction with the use of Console

Layered architecture of affected bundles

Slide 31

Abstraction with the use of Device Communication

Measurements are captured via Bluetooth
There are different bluetooth implementations on different devices
Later on not only Bluetooth, but USB should be supported as well
Abstraction of communication layer and Bluetooth implementations is
needed to ensure driver implemenentation must not be changed

Slide 32

Abstraction with the use of Device Communication

Layered architecture of affected bundles

Slide 33

Abstraction with the use of Console and Device Communication

Deployment

Slide 34

Fulfilling Requirements with the help of OSGi

system executable
Platform independency by realizating it as OSGi application
OSGi serves as an abstraction layer of underlying diversity
Using different implementations for different platforms

2. Support of any device and service center – even later on – without
modification of the Plug&Care Connector
Establish plugin concept
Get plugins with help of modularity of OSGi
Handle plugins (registration) by the use of dependency injection
provided by OSGi (Declarative Services)

Slide 35

Plugin and Registry Concept using the Example of Driver

How did we realize it?

Slide 37


Slide 38


What does a driver developer need to do?

Implement the driver interfaces provided by Plug&Care Connector
Provide a component description like that:

<component name=„Driver A“>
<implementation class="de.pncc.plugins.drivers.DriverA"/>
<service>
<provide interface="de.pncc.drivers.Driver"/>
</service>
</component>

Slide 39


What does the Plug&Care Connecor do?

Provides component description like that:

<component name=„Driver Registry„
<reference name="de.pncc.driver„
interface="de.pncc.drivers.Driver„
bind="addDriver„
unbind="removeDriver
</component>

Implements bind and unbind method to e.g., store the driver in a list

Slide 40


What does OSGi do?

Everything else
like listen to new driver bundles, retrieving there provided driver
services, inject them to the right place, handles uninstalled driver
bundles, …

Slide 41

What did we learn?

Slide 44

What did We Learn?

Living out OSGi principles is a good base for building better software (in
terms of maintance and deployment).

Slide 45

Living out OSGi Principles
Services

Use services
Seperate service interface and service implementation
Allows abstraction and loose coupling
Makes application
More robust against changes
Deployable in different environments just by assempling different
kind of jar files

Slide 46

Declarative Services

Prerequisite is usage of services
Make use of dependency injection
Let other maintain the code for dependency handling
Get your code free from OSGi API
Makes application
Easier to test by injecting stub or mock objects
More robust because fewer lines of code (every reduced line of
code, reduces the chance for a bug)
Easier to understand and use by third party developers knowing
nothing about OSGi

Slide 47

Encapsulation

Make only those code public which is really intended to be public
Hide as much as possible from the outer world
In perfect word only the (service) interfaces are public
Makes application
More robust against changes because third party code can only be
depend on a little part of your applications‘s implementation
Architecture smarter, because you need to think about it in more
detail

Slide 48

Building Flexible Telemonitoring Software with OSGi

Recommended

Recommended

More Related Content

What's hot

What's hot (16)

Similar to Building Flexible Telemonitoring Software with OSGi

Similar to Building Flexible Telemonitoring Software with OSGi (20)

Recently uploaded

Recently uploaded (20)

Building Flexible Telemonitoring Software with OSGi