OSGi bundles implementing the most famous patterns for providing and requesting services, producing and consuming data

1. OSGi Patterns v. 1.0.11
OSGi, Maven, Hudson
Best practises
2012/1.0.11 C. St-Marcel - @VELOSSITY

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

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

4. 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).
4 2012/1.0.11 C. St-Marcel - @VELOSSITY

5. 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)
5 2012/1.0.11 C. St-Marcel - @VELOSSITY

6. 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
6 2012/1.0.11 C. St-Marcel - @VELOSSITY

7. 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)
7 2012/1.0.11 C. St-Marcel - @VELOSSITY

8. 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
2012/1.0.11 C. St-Marcel - @VELOSSITY

9. “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
9 2012/1.0.11 C. St-Marcel - @VELOSSITY

10. 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.
10 2012/1.0.11 C. St-Marcel - @VELOSSITY

11. Produce & Consume Patterns
Produce & Consume Pattern
Instantiation
Instantiation
Instantiation
Event Admin Pattern White Board Pattern Wire Admin Pattern
11 2012/1.0.11 C. St-Marcel - @VELOSSITY

12. 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
12 2012/1.0.11 C. St-Marcel - @VELOSSITY

13. 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)
13 2012/1.0.11 C. St-Marcel - @VELOSSITY

14. 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
2012/1.0.11 C. St-Marcel - @VELOSSITY

15. 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
2012/1.0.11 C. St-Marcel - @VELOSSITY

16. Produce & Consume Anti-Patterns
Produce & Consume Anti-Pattern
Instantiation Instantiation
Polling Pattern Event Listener Pattern
16 2012/1.0.11 C. St-Marcel - @VELOSSITY

17. 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
17 2012/1.0.11 C. St-Marcel - @VELOSSITY

18. 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
18 2012/1.0.11 C. St-Marcel - @VELOSSITY

19. 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
19 2012/1.0.11 C. St-Marcel - @VELOSSITY

20. Architectural Patterns
Loose Coupling Pattern
Instantiation
Layers Pattern
20 2012/1.0.11 C. St-Marcel - @VELOSSITY

21. 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
21 2012/1.0.11 C. St-Marcel - @VELOSSITY