OSGi patterns v1.0.11

OSGi Patterns v. 1.0.11

OSGi, Maven, Hudson
Best practises

2012/1.0.11 C. St-Marcel - @VELOSSITY

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”
2 * Naming and classification are our own view 2012/1.0.11 C. St-Marcel - @VELOSSITY

Continuous Integration

 OSGi pattern build chain reference is
maintained at Sourceforge:
svn co https://osgipatterns.svn.sourceforge.net/svnroot/osgipatterns/multi-
modules/tags/patterns.aggregator-1.0.11 osgipatterns

 Continuous Integration is done with Jenkins:
http://velossity.zapto.org:8080/

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

3 2012/1.0.11 C. St-Marcel - @VELOSSITY

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

Provide & Request family

Provide & Request Pattern

Instantiation
Instantiation Instantiation

Inversion Of
Control
Extender Pattern Service Model Pattern White Board Pattern

Factory Pattern Listener Pattern

Refinement Transformation
Refinement

Eclipse Extension Dynamic Binding Framework
Service Deployment Pattern
(A. Bottaro / Fred Rivard)


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

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

 The service is defined by a contract
(the Service API)
 The Provider publishes the Service Component Java Interface

in the registry
 The service has its own lifecycle,
e.g. it can come and go Service registry
 The Requester is requesting the Service API
registry for the existing service, it
can also be notified when the Publishes
Notifies
Requests
service is appearing Binds
Service Service
 The requester binds to the provider, Provider Requester
it invokes the service at the end Invoke


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

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

 The White Board pattern is just an
inversion of control
 The Requester is now publishing a Component Java Interface

handler of service and the Provider
is requesting it
 The Provider can bind to the Service registry
Requester, it invokes the handle
ServiceHandler API
method with the service as
parameter Requests Publishes
Notifies
Binds
Service Service
Provider Requester
Handle(ServiceAPI)


Service Deployment
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

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


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

Extender Provider “What will I extend?”

 The Extender Pattern main idea is
to extend the semantics of bundles
by adding custom manifest headers
Component Java Interface
 Extended bundles can react if
bundles with these headers come
and go dynamically
Service registry
 In our case, the Requester is
viewed as an extension for the BundleListener ServiceAPI
Provider
Publishes Implements

Service Load Service
Provider Requester


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 Patterns

Produce & Consume Pattern

Instantiation
Instantiation
Instantiation

Event Admin Pattern White Board Pattern Wire Admin Pattern


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

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

 The Event Admin Service provides
a standard way for working with
events in the OSGi Environment Component Java Interface
using the publish/subscribe model.
It was introduced in the R4
specifications
 the EventAdmin is like a mediator Service registry
between producers and consumers EventAdmin EventHandler
of events. It is using itself the
White-Board pattern to transfer
Requests
events to components which have Publishes
Requests Publishes
registered Binds
Data Data
 The graph of dependencies Producer
EventAdminImpl
Consumer
between producers and consumers postEvent(Event) handleEvent(Event)
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 handle?”

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

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

 Do not use the Listener pattern DataHandler API
anymore, apply the White Board
Requests Publishes
pattern instead Notifies
Binds
Data Data
Producer Consumer
NewData(Data)


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

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

 Release 3 of OSGi introduced a
very flexible way to connect Component Java Interface
producers and consumers to
each other.
 It can be viewed as “The Service registry
optimal low coupling scenario
… when the consumer only Producer Consumer

knows what type of data it
Publishes Requests Publishes
wants to consume, the producer Requests

knows what type of data it Data Data
WireAdminImpl
produces, but neither of them Producer Consumer

know anything about the consumersConnected( Wire[] wires ) producersConnected( Wire[] wires )

other”*.

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

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
15 Admin pattern

Produce & Consume Anti-Patterns

Produce & Consume Anti-Pattern

Instantiation Instantiation

Polling Pattern Event Listener Pattern


Event Listener

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

 As demonstrated*, this pattern “is Observable Observer
considered harmful” in OSGi
Publishes Tracks Implements

Data AddListener Data
Producer Consumer
NewData(Data)

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


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.

Component Java Interface

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

Adapter Adaptee provider


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


Architectural Patterns

Loose Coupling Pattern

Instantiation

Layers Pattern


Functional component

Bundle Service API

Layers Pattern Dependency

Layer 1 Layer 2
Layer 2
compendium

Service 1 API Service 2 API Service m API Layer n
Layer n compendium

Service 1 Service 2 Service m

EventAdmin LogService ConfigAdmin OSGi Services Layer
OSGi services compendium

Knopflerfish Felix Felix
LogService EventAdmin ConfigAdmin


OSGi patterns v1.0.11

More Related Content

What's hot (20)

Similar to OSGi patterns v1.0.11 (20)

More from Velossity (6)

Recently uploaded (20)

OSGi patterns v1.0.11