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

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

Using OSGi to Build Better SoftwareLessons from a Telemedicine Software for Smartphones and

Desktop Systems Doreen Seider (DLR - German Aerospace Center)

ApacheCon NA 2011 (Vancouver, 11/11/2011)


Outline

What software did we want to have?

How did we develop it with OSGi?

What did we learn?

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


In Comparison to That: Flexible Telemonitoring Software


Flexible Telemonitoring Software Technology

Plug&Care Connector


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

How did we develop it with OSGi?


Slide 11


Plug&Care Connector‘s Architecture


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



By default bundles are totally encapsulated

Bundles can make use of each other by explicit exports and imports of packages



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



Service definition and implementation are separated to each other

No direct implementation dependencies

Enables loose coupling

Important for assembling bundles (jars) to applications


OSGi Principles: Declarative Services (DS)

OSGi Runtime calls the bundle and not other way around



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



Benefits of Declarative Services

Less complexity in own code

Better testing (no mock up of OSGi runtime needed)


Fulfilling Requirements with the help of OSGi


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


Used OSGi Implementations: Equinox

For desktop

Eclipse Software Foundation

OSGi implementation under Eclipse

Decision was made due to experiences from other software we develop


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


Used OSGi Implementations: mBS MobileIntegration in Android


Used OSGi Implementations: mBS MobileOSGi Management on Android


Used OSGi Implementations: mBS MobileOSGi Applications on Android


OSGi-Stack: mBS MobileDevelopment Environment in Eclipse


Designing Plug&Care ConnectorAbstraction 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


Designing Plug&Care ConnectorAbstraction with the use of Console

Layered architecture of affected bundles


Designing Plug&Care ConnectorAbstraction 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


Designing Plug&Care ConnectorAbstraction with the use of Device Communication

Layered architecture of affected bundles


Designing Plug&Care ConnectorAbstraction with the use of Console and Device Communication

Deployment


Fulfilling Requirements with the help of OSGi


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)


Designing Plug&Care ConnectorPlugin and Registry Concept using the Example of Driver

How did we realize it?



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>



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



What does OSGi do?

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

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


Living out OSGi PrinciplesServices

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


Living out OSGi PrinciplesDeclarative 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


Living out OSGi PrinciplesEncapsulation

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 1 ApacheCon 2011 > Doreen Seider> Using OSGi to Build Better Software > 11.11.2011 Using OSGi...

Documents

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