OSGi: Grundlagen und Konzepte
Upcoming SlideShare
Loading in...5
×
 
  • 1,847 views

 

Statistics

Views

Total Views
1,847
Views on SlideShare
1,837
Embed Views
10

Actions

Likes
0
Downloads
9
Comments
0

1 Embed 10

http://www.iks-gmbh.com 10

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

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: Grundlagen und Konzepte OSGi: Grundlagen und Konzepte Presentation Transcript

  • OSGi Konzepte Thementag OSGi 03.11.2009 Autor:Christoph Schmidt-Casdorff
  • Agenda Modularisierung OSGi – ein Einstieg OSGi-Architektur – Modularisierung – Dynamik von Bundles – Servicekonzept ZusammenfassungOSGi Konzepte Seite 3 / 38
  • Agenda Modularisierung OSGi – ein Einstieg OSGi-Architektur – Modularisierung – Dynamik von Bundles – Servicekonzept ZusammenfassungOSGi Konzepte Seite 4 / 38
  • AgendaQuelle : http://techdistrict.kirkk.com/2009/08/13/modularity-by-exampleOSGi Konzepte Seite 5 / 38
  • Modularität – „Teile und Herrsche“ Prinzip „Teile und Herrsche“ Bausteine eines Softwaresystems sind Softwareeinheiten (Module), die – einen möglichst großen Grad an Isolierung/Unabhängigkeit zum Systemkontext besitzen – definierte Abgrenzungen zum Systemkontext und anderen Modulen besitzen Kann ein Modul in Java formuliert werden?OSGi Konzepte Seite 6 / 38
  • Modularität in Java Sichtbarkeit von Klassen Package – Einzige Strukturierung jenseits der Klassen – Hat Sichtbarkeitsregeln – Sichtbarkeiten sind nicht hierarchisch • Sichtbarkeiten sind nur innerhalb eines Packages eingeschränkt JAR – Ist eine auslieferbare Ansammlung von Klassen/Ressourcen – Keine Sichtbarkeiten auf dieser Ebene – Wäre Kandidat für Modul Java bietet keine Unterstützung zur Modularisierung – Es muss etwas getan werdenOSGi Konzepte Seite 7 / 38
  • Module Module – Sind Softwareeinheiten (physisch) – Können Abhängigkeiten untereinander definieren • Veröffentlichung für andere Module • Import von Veröffentlichung anderer Module – Können unabhängig voneinander de-/installiert werden Ein Modul kann aktiv bestimmen, welche Teile von ihm privat und welche öffentlich sindOSGi Konzepte Seite 8 / 38
  • Komponentenmodelle Komponentenmodelle sind gelebte Modularität – Liefern ein(e) Verfahren / Modell / Spezifikation zur Modularisierung Komponentenmodelle definieren Verträge, – wie eine Komponente aufgebaut ist – wie Abhängigkeiten zwischen Komponenten beschrieben werden • welche Klassen exportiert / importiert werden – welche Anforderungen eine Komponente an den Systemkontext stellen kann Begriffe Modul und Komponente verwenden wir synonym – Module zielen mehr auf physische Struktur ab – Komponenten sind allgemeiner (auch auf logische Strukturen)OSGi Konzepte Seite 9 / 38
  • Komponentenframework Komponentenframework – Laufzeitumgebung für Module – Implementierung des Vertragwerks Dirigent im Orchester der Module – De-/Installation von Modulen – Auflösung der Abhängigkeit zwischen den Modulen – Integration der Module in das GesamtsystemOSGi Konzepte Seite 10 / 38
  • Warum Komponenten? Komponenten – Komponenten sind ‚missing link‘ zwischen Architektur und OO-Design – Wichtige Strukturierungsebene für den Übergang Management von Abhängigkeiten – Unnötige Abhängigkeiten • Erhöhen Komplexität der Anwendung • Sind Haupttreiber von ‚rotten design‘ Isolierte Entwicklung – Anwendung ist eine Zusammenstellung von Komponenten – Geschieht erst auf Integrationsplattform – Idee: Anwendungsentwicklung als BaukastenOSGi Konzepte Seite 11 / 38
  • Agenda Modularisierung OSGi – ein Einstieg OSGi-Architektur – Modularisierung – Dynamik von Bundles – Servicekonzept OSGi Compendium Services ZusammenfassungOSGi Konzepte Seite 12 / 38
  • Modularisierung und Java Java besitzt keine Unterstützung zur Modularisierung Bietet aber technologische Vorrausetzungen für Modularisierung – Classloader-KonzeptOSGi Konzepte Seite 13 / 38
  • OSGi OSGi – Modularisierung mittels JavaOSGi Konzepte Seite 14 / 38
  • OSGi – historischer Abriss Open Gateway Service initiative OSGi ist eine Spezifikation – Durch OSGi Alliance organisiert – Gegründet 1999 Wurzeln von OSGi liegen in Anwendungen für Mobile Endgeräte Mittlerweile engagiert sich OSGi im Bereich der Java Middleware – Aktuelle Version der Spezifikation ist 4.1OSGi Konzepte Seite 15 / 38
  • Agenda Modularisierung OSGi – ein Einstieg OSGi-Architektur – Modularisierung – Dynamik von Bundles – Servicekonzept OSGi Compendium Services ZusammenfassungOSGi Konzepte Seite 16 / 38
  • OSGi-Architektur - ModularisierungOSGi Konzepte Seite 17 / 38
  • OSGi-Architektur - Modularisierung Module heißen in OSGi Bundle Bundle sind normale jar-Dateien Enthalten aber selbstbeschreibende Informationen – Ablage als Manifest-Datei – Vertrag des Bundles mit dem OSGi FrameworkOSGi Konzepte Seite 18 / 38
  • Bundle-Selbstbeschreibung Bundle-beschreibende Informationen sind beispielsweise – Name, Identifikation, Version – Angabe der zu veröffentlichen Klassen/Ressourcen • Auf Ebene von java-Packages • Versioniert – Angabe von zu importierenden Klassen/Ressourcen • Auf Ebene von java-Packages • Versioniert – Angabe von zu importierenden Bundles • VersioniertOSGi Konzepte Seite 19 / 38
  • Beispiel einer Manifest-DateiVersion: 1.0Bundle-ManifestVersion: 2Bundle-Name: HelloWorldBundle-Version: 1.0Bundle-SymbolicName:sample.HelloWorldBundle-ClassPath: ., target/dependency/junit-3.8.1.jarBundle-Activator:sample.internal.ActivatorExport-Package:sampleImport-Package: common.commons,sample; version="[3.0.0, 4.0.0)", org.osgi.frameworkRequire-Bundle:com.sample.chess, com.sample.chess.core;version="2.0"OSGi Konzepte Seite 20 / 38
  • Sichtbarkeiten von Ressourcen Die Modularisierung bedingt Sichtbarkeiten von Ressourcen – Private Ressourcen müssen vor anderen Bundles versteckt werden – Öffentliche Ressourcen müssen anderen Bundles zugänglich gemacht werden (Export) – Angeforderte Ressourcen müssen bereitgestellt werden (Import) OSGi löst Sichtbarkeiten über eine komplexe Classloader-Hierarchie – Jedes Bundle hat seinen eigenen Classloader – Ein Bundle wird durch die von ihm angeforderten Bundles (transitiv) erweitertOSGi Konzepte Seite 21 / 38
  • Sichtbarkeiten von Ressourcen Bundles können in unterschiedlichen Versionen koexistieren Die Konsistenz eines Bundles beeinflusst den Zustand anderer Bundles – Export / ImportOSGi Konzepte Seite 22 / 38
  • OSGi-Architektur – Life CycleOSGi Konzepte Seite 23 / 38
  • Life Cycle Layer - Dynamik von Bundles Offene Fragen – Ist in OSGi die Abhängigkeit zwischen Bundles statisch? NEIN – Welche Folgen hat die De-/ Installation eines Bundles ? • Imports sind womöglich nicht mehr aufzulösen – Wo wird denn die eigentliche Logik angestoßen? • Wo geht eine OSGi-Anwendung los? Mit diesen Fragen beschäftigt sich der Life Cycle LayerOSGi Konzepte Seite 24 / 38
  • Laufzeitzustände von Bundles Start des Bundles Importe korrekt aufgelöst Stop des BundlesOSGi Konzepte Seite 25 / 38
  • Dynamik von Bundles OSGi Framework – Ist für die Zustände der Bundles verantwortlich • Genauer gesagt : management agent – Prüft die Zustände dynamisch • Selbstheilung des OSGi Frameworks Bundle kann spezifischen Code ausführen – Während der Aktivierungsphase (start) – Während der Deaktivierungsphase (stop) – Methoden des Bundles werden durch OSGi Framework gerufen – Methoden Bundle Activator bereitgestelltOSGi Konzepte Seite 26 / 38
  • OSGi-Architektur - ServicesOSGi Konzepte Seite 27 / 38
  • OSGi Services Services – Sind Java Objekte – Bieten Dienste an, die für andere Bundles interessant sein könnten – Werden i.d.R. beim Start eines Bundles erzeugt OSGi bietet eine zentrale Service-Registratur an, bei der – sich Services eintragen können • Mit Kriterien, unter denen sie gefunden werden • Qualitative Beschreibung des Service – Servicenutzer suchen nach bestimmten Kriterien Services Keine direkte Beziehung zwischen Serviceanbieter und –Nutzer – Implementierungen können wechseln – Mehrere Implementierungen können pro Service angeboten werdenOSGi Konzepte Seite 28 / 38
  • OSGi Service Virt ual Machine Grenze Service Regist rierung Service Beschreibungen veröffent lichen finden Service Service Benut zer benut zenOSGi Konzepte Seite 29 / 38
  • Dynamik von Services Anbieter können ihre Services beliebig an- und abmelden – Situation für den Servicenutzer kann sich jederzeit ändern – Dynamik von Services OSGi bietet Bordmittel auf unterschiedlichen Leveln an – low level: Nutzung von Verwaltungsmechanismen des Frameworks • Sehr komplex und sehr aufwendig – medium level: Sogenannte Service Tracker, die im Hintergrund die Situation für den Nutzer aktuell halten • Komplex und aufwendig – high level: (Service Component) Modelle, die diese Dynamik im Hintergrund abhandeln • Spring DM, OSGi Declarative Services, iPOJO …. • Neue ProgrammiermodelleOSGi Konzepte Seite 30 / 38
  • Agenda Modularisierung OSGi – ein Einstieg OSGi-Architektur – Modularisierung – Dynamik von Bundles – Servicekonzept OSGi Compendium Services ZusammenfassungOSGi Konzepte Seite 31 / 38
  • OSGi Compendium Services OSGi standardisiert eine Reihe von Querschnittservices – Logging – Eventhandling – Integration von Fremdanwendungen – Monitoring – Konfiguration – ... OSGi Compendium Services – Sind (i.d.R.) normale Services – Setzen auf OSGi auf Jede standardkonforme Implementierung läuft auf jedem OSGi FrameworkOSGi Konzepte Seite 32 / 38
  • Agenda Modularisierung OSGi – ein Einstieg OSGi-Architektur – Modularisierung – Dynamik von Bundles – Servicekonzept OSGi Compendium Services ZusammenfassungOSGi Konzepte Seite 33 / 38
  • Architektur reloaded Modularisierung – Definiert Vertrag zwischen Bundles und ihrer Umgebung – Definiert, wie dieser Vertrag umzusetzen ist – Definiert, welche Aufgaben das OSGi Framework zu übernehmen hat Life Cycle Layer – Definiert Zustände von Bundles und deren Übergängen – Bildet Modularisierung auf Zustände ab – Bietet den Einstiegspunkt zu eigener Programmlogik Service Layer – Definiert das Servicekonzept von OSGi – Beschreibt die Dynamik von Services und deren Konsequenzen – Beschreibt den Umgang mit dynamischen ServicesOSGi Konzepte Seite 34 / 38
  • OSGi Rekapitulation Modularisierung – Statische Sicht auf die Auslieferungseinheiten – Reduziert Abhängigkeiten der Module • Ausufernde Abhängigkeiten sind auschlaggebend für ‚rotten design‘ Life Cycle Layer – Module können zur Laufzeit de-/installiert werden – Dynamische Funktionalität – Selbstheilung des Systems Services – Korrespondenz der Funktionalität via Service-Registry – SOA lightOSGi Konzepte Seite 35 / 38
  • Zusammenfassung Modularisierung und Komponentenmodelle Ansatz von OSGi Architektur von OSGi – Modularisierung – Dynamik von Bundles – ServicekonzeptOSGi Konzepte Seite 36 / 38
  • Referenzen[CBSD] http://en.wikibooks.org/wiki/Computer_programming/Component_based_ software_developmentOSGi Konzepte Seite 37 / 38
  • Weiterführende Literatur Gerd Wütherich, Nils Hartmann, Bernd Kolb , Matthias Lübken Die OSGI Service Platform - Eine Einführung mit Eclipse Equinox , dpunkt Verlag; Auflage: 1 (18. April 2008) ISBN-13: 978-3898644570 OSGi In Practice von Neil Bartlett http://neilbartlett.name/blog/osgibook/OSGi Konzepte Seite 38 / 38
  • Fragen?
  • www.iks-gmbh.com