OSGi patterns v1.0.11
Upcoming SlideShare
Loading in...5
×
 

OSGi patterns v1.0.11

on

  • 3,240 views

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

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

Statistics

Views

Total Views
3,240
Views on SlideShare
3,114
Embed Views
126

Actions

Likes
2
Downloads
69
Comments
0

3 Embeds 126

http://osgipatterns.sourceforge.net 118
http://www.linkedin.com 7
http://pinterest.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    OSGi patterns v1.0.11 OSGi patterns v1.0.11 Presentation Transcript

    • 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).4 2012/1.0.11 C. St-Marcel - @VELOSSITY
    • 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
    • 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 Invoke6 2012/1.0.11 C. St-Marcel - @VELOSSITY
    • 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
    • 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 Provider8 From F. Rivard and A. Bottaro at OSGi Community Event - 2010 2012/1.0.11 C. St-Marcel - @VELOSSITY
    • “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 Requester9 2012/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.10 2012/1.0.11 C. St-Marcel - @VELOSSITY
    • Produce & Consume Patterns Produce & Consume Pattern Instantiation Instantiation Instantiation Event Admin Pattern White Board Pattern Wire Admin Pattern11 2012/1.0.11 C. St-Marcel - @VELOSSITY
    • 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 events12 2012/1.0.11 C. St-Marcel - @VELOSSITY
    • 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
    • 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 inspiration14 for our works on Produce & Consume 2012/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 Wire15 Admin pattern 2012/1.0.11 C. St-Marcel - @VELOSSITY
    • Produce & Consume Anti-Patterns Produce & Consume Anti-Pattern Instantiation Instantiation Polling Pattern Event Listener Pattern16 2012/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) 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 Hargrave17 2012/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. 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 provider18 2012/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 osgipatterns19 2012/1.0.11 C. St-Marcel - @VELOSSITY
    • Architectural Patterns Loose Coupling Pattern Instantiation Layers Pattern20 2012/1.0.11 C. St-Marcel - @VELOSSITY
    • 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 ConfigAdmin21 2012/1.0.11 C. St-Marcel - @VELOSSITY