Using OSGi to Build Better Software

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

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)


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?

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

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

http://prosyst.com/

http://dz.prosyst.com/mbsmobile/


Used OSGi Implementations: mBS Mobile Integration in Android


Used OSGi Implementations: mBS Mobile OSGi Management on Android


Used OSGi Implementations: mBS Mobile OSGi Applications on Android


OSGi-Stack: mBS Mobile Development Environment in Eclipse


OSGi-Stack: mBS Mobile Development Environment in Eclipse


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


Designing Plug&Care Connector Abstraction with the use of Console

Layered architecture of affected bundles


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


Designing Plug&Care Connector Abstraction with the use of Device Communication

Layered architecture of affected bundles


Designing Plug&Care Connector Abstraction 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 Connector Plugin 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 else

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


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


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