OSGi patterns v1.0.11

2012/1.0.11 C. St-Marcel - @VELOSSITY

OSGi, Maven, Hudson

Best practises

OSGi Patterns v. 1.0.11


Introduction

Velossity proposes a family of well known OSGi patterns*

Velossity is a small French company focusing on OSGi since many years

It is specialized on industrial projects for embedded platforms (Home automation, energy gateways)

This work is part of trainings called:

“Embedding OSGi in your Devices, Continuous Integration with Maven”

* Naming and classification are our own view


Continuous Integration

OSGi pattern build chain reference is maintained at Sourceforge:

Continuous Integration is done with Jenkins:

OSGi bundles are deployed in the Maven central under the groupId “fr.velossity.osgi”

svn co https://osgipatterns.svn.sourceforge.net/svnroot/osgipatterns/multi-modules/tags/patterns.aggregator-1.0.11 osgipatterns

http://velossity.zapto.org:8080/


The basics of OSGi

Motivation

The strength of OSGi is to merge OO concepts generally used for reuse in a unique manner which is the service. Lot of solutions were emerging to deal with service communication and low coupling, trying to answer to the question: “How can I connect my services?”.

Solution

Provide & Request patterns exchange services, that is functions or some processing logic or business processing offered by a Service Provider and used by a Service Requester. Examples of services are monitoring, posting, logging, etc. In OSGi the service is represented by a POJI (a Plain Old Java Interface).

Produce & Consume patterns exchange data, that is information created and published by a Data Producer and read by a Data Consumer. Examples of data are measures, letters, logs, etc. In OSGi a data is represented by a POJO (a Plain Old Java Object).


Factory Pattern Listener Pattern

Provide & Request Pattern

Service Model Pattern Extender Pattern

Service Deployment Pattern(A. Bottaro / Fred Rivard)

Refinement

InstantiationInstantiation

Eclipse Extension

Refinement

White Board Pattern

Inversion Of Control

Dynamic Binding Framework

Transformation

Instantiation

Provide & Request family


Service Model

The service is defined by a contract (the Service API)

The Provider publishes the Service in the registry

The service has its own lifecycle, e.g. it can come and go

The Requester is requesting the registry for the existing service, it can also be notified when the service is appearing

The requester binds to the provider, it invokes the service at the end

Service registry

Service API

ServiceRequester

ServiceProvider

Requests

Invoke

Publishes

Component Java Interface

Notifies

Binds

Requester “Which service(s) do I require?”

Provider “Which service(s) do I provide?”


White Board

The White Board pattern is just an inversion of control

The Requester is now publishing a handler of service and the Provider is requesting it

The Provider can bind to the Requester, it invokes the handle method with the service as parameter

Service registry

ServiceHandler API

ServiceRequester

ServiceProvider

Requests

Binds

Publishes


Notifies

Handle(ServiceAPI)

Requester “Which service(s) do I handle?”

Provider “Who is interested by my service(s)?”


Service Deployment

From F. Rivard and A. Bottaro at OSGi Community Event - 2010

The Service Deployment pattern strengthens the Service Model pattern as it defines constraints on the deployment itself. It guaranties a strict separation of service interfaces and service implementations using three isolate bundles, one for the API and two for the implementations of the Requester and the Provider


Extender

The Extender Pattern main idea is to extend the semantics of bundles by adding custom manifest headers

Extended bundles can react if bundles with these headers come and go dynamically

In our case, the Requester is viewed as an extension for the Provider

Service registry

BundleListener

ServiceRequester

ServiceProvider

Load


Publishes

ServiceAPI

Implements

Requester “How may I be extended, what are my extensions points?”

Provider “What will I extend?”


Extensions or services

The Extender pattern is designed for extensions. The requester point of view is privileged, it is one-to-many relationship between a requester and many providers. In Eclipse this relation is private, i.e. you develop extensions for a unique extension point. This is a natural way of thinking for this platform which , incidentally, provides an extensible container supporting new views, new projects, new languages, etc.

The Service Model and White Board are designed for a truly service approach where the contract is public and is not privileging any point of view. It is potentially a many-to-many relationship between requesters and providers

The Extender Pattern is very useful and natural for extension (quite natural for an extender) whereas two others are powerful for reuse of services. That is why they are complementary.


Produce & Consume Pattern

Wire Admin Pattern Event Admin Pattern

Instantiation

Instantiation

White Board Pattern

Instantiation

Produce & Consume Patterns


Service registry

EventHandler

DataConsumer

DataProducer

Requests

Binds

Publishes


postEvent(Event)

EventAdmin

EventAdminImpl

handleEvent(Event)

Requests Publishes

Event Admin

The Event Admin Service provides a standard way for working with events in the OSGi Environment using the publish/subscribe model. It was introduced in the R4 specifications

the EventAdmin is like a mediator between producers and consumers of events. It is using itself the White-Board pattern to transfer events to components which have registered

The graph of dependencies between producers and consumers is more difficult to maintain when using the Event Admin. You have to define and manage a strict policy of events

Consumer “Which type of data(s) do I subscribe?”

Producer “Which type of data(s) do I publish?”


Service registry

DataHandler API

DataConsumer

DataProducer

Requests

Binds

Publishes


Notifies

NewData(Data)

White Board

The whiteboard approach means that a consumer registers itself when it wants to consume. It will be notified by the producers when new data are available. Producers know all their consumers, but consumers have no connection with producers.

Do not use the Listener pattern anymore, apply the White Board

pattern instead

Consumer “Which type of data(s) do I handle?”

Producer “Who is interested by my data(s)?”


Wire Admin

Release 3 of OSGi introduced a very flexible way to connect producers and consumers to each other.

It can be viewed as “The optimal low coupling scenario … when the consumer only knows what type of data it wants to consume, the producer knows what type of data it produces, but neither of them know anything about the other”*.

Service registry

Consumer

DataConsumer

DataProducer

Publishes Requests


consumersConnected( Wire[] wires )

Producer

WireAdminImpl

producersConnected( Wire[] wires )

Requests Publishes

*in the paper proposed at OOPSLA 2003 by N. Nilson, a great source of inspirationfor our works on Produce & Consume

Consumer “Which type of data(s) do I consume?”

Producer “Which type of data(s) do I produce?”


A story of control

Use the White Board wherever you usually used a Listener. Use the Event Admin when you want to distribute your producers and

consumers on several platforms. Reserve the Wire Admin usage to a single layer. Originally, the Wire Admin was

designed for sensors layer, it could be a good solution to manage them on your platforms in a coherent and flexible way.

Let producers choose their consumers: the White board pattern

Let consumers choose their producers: the Event Admin pattern

Let a third party choose for you: the Wire Admin pattern


Produce & Consume Anti-Pattern

Polling Pattern

InstantiationInstantiation

Event Listener Pattern

Produce & Consume Anti-Patterns


Event Listener

The Event Listener is the original java way to handle producer data (pattern introduced by the gang of 4)

As demonstrated*, this pattern “is considered harmful” in OSGi

*Listeners Considered Harmful: The “Whiteboard” Pattern, Peter Kriens BJ Hargrave

Service registry

ObserverObservable

Tracks ImplementsPublishes

DataProducer

DataConsumer

NewData(Data)

AddListener


Adapter [GOF]

The adapter pattern originally proposed by the gang of four can be easily realized using the OSGi principles

The main motivation is to wrap a low OSGi service to a high level one. This pattern is very useful when working with drivers and devices: a new low-

end device is adapted to an abstract device hiding field bus dependencies.

Two implementations proposed, one with iPOJO and the other with the native OSGi API.The native solution is an adapter of the one originally proposed in:http://njbartlett.name/2010/08/05/when-servicetrackers-trump-ds.html

Service registry

Adaptee

Adaptee provider


Adapted

Adapter

Tracks PublishesPublishes


Maven multi-modules organization| aggregator -- Run multi-modules build| parent -- Parent of all modules| distribution -- Generation of a zip containing all patterns| tests| -- integration -- Integration tests with Pax-Exam| step-3-notifications| -- ServiceModelPattern -- Service Model| -- WhiteBoardPattern -- White Board| step-1-provide-request| -- ExtenderPattern -- Extender| step-4-produce-consume| -- WhiteBoardPattern -- White Board| -- EventAdminPattern -- Event Admin| -- WireAdminPattern -- Wire Admin| adapter| -- native -- Adapter implementation using native OSGi| -- iPOJO -- Adapter implementation with iPOJO

svn co https://osgipatterns.svn.sourceforge.net/svnroot/osgipatterns/multi-modules/tags/patterns.aggregator-1.0.11 osgipatterns


Loose Coupling Pattern

Instantiation

Layers Pattern

Architectural Patterns


Layer 1 Layer 2

Layer n

OSGi Services Layer

Service 1 API Service 2 API Service m API

Layer n compendium

Layer 2compendium

EventAdmin LogService ConfigAdmin

OSGi services compendium

Service 1 Service 2 Service m

KnopflerfishLogService

FelixEventAdmin

FelixConfigAdmin

Functional component

Bundle

DependencyLayers PatternService API

Technology

OSGi patterns v1.0.11