osgi patterns v1.0.11
DESCRIPTION
OSGi bundles implementing the most famous patterns for providing and requesting services, producing and consuming dataTRANSCRIPT
2012/1.0.11 C. St-Marcel - @VELOSSITY
OSGi, Maven, Hudson
Best practises
OSGi Patterns v. 1.0.11
22012/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”
* Naming and classification are our own view
32012/1.0.11 C. St-Marcel - @VELOSSITY
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/
42012/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).
52012/1.0.11 C. St-Marcel - @VELOSSITY
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
62012/1.0.11 C. St-Marcel - @VELOSSITY
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?”
72012/1.0.11 C. St-Marcel - @VELOSSITY
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
Component Java Interface
Notifies
Handle(ServiceAPI)
Requester “Which service(s) do I handle?”
Provider “Who is interested by my service(s)?”
82012/1.0.11 C. St-Marcel - @VELOSSITY
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
92012/1.0.11 C. St-Marcel - @VELOSSITY
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
Component Java Interface
Publishes
ServiceAPI
Implements
Requester “How may I be extended, what are my extensions points?”
Provider “What will I extend?”
102012/1.0.11 C. St-Marcel - @VELOSSITY
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.
112012/1.0.11 C. St-Marcel - @VELOSSITY
Produce & Consume Pattern
Wire Admin Pattern Event Admin Pattern
Instantiation
Instantiation
White Board Pattern
Instantiation
Produce & Consume Patterns
122012/1.0.11 C. St-Marcel - @VELOSSITY
Service registry
EventHandler
DataConsumer
DataProducer
Requests
Binds
Publishes
Component Java Interface
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?”
132012/1.0.11 C. St-Marcel - @VELOSSITY
Service registry
DataHandler API
DataConsumer
DataProducer
Requests
Binds
Publishes
Component Java Interface
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)?”
142012/1.0.11 C. St-Marcel - @VELOSSITY
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
Component Java Interface
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?”
152012/1.0.11 C. St-Marcel - @VELOSSITY
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
162012/1.0.11 C. St-Marcel - @VELOSSITY
Produce & Consume Anti-Pattern
Polling Pattern
InstantiationInstantiation
Event Listener Pattern
Produce & Consume Anti-Patterns
172012/1.0.11 C. St-Marcel - @VELOSSITY
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
182012/1.0.11 C. St-Marcel - @VELOSSITY
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
Component Java Interface
Adapted
Adapter
Tracks PublishesPublishes
192012/1.0.11 C. St-Marcel - @VELOSSITY
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
202012/1.0.11 C. St-Marcel - @VELOSSITY
Loose Coupling Pattern
Instantiation
Layers Pattern
Architectural Patterns
212012/1.0.11 C. St-Marcel - @VELOSSITY
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