• Like
OSGi: Grundlagen und Konzepte
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,326
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
9
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. OSGi Konzepte Thementag OSGi 03.11.2009 Autor:Christoph Schmidt-Casdorff
  • 2. Agenda Modularisierung OSGi – ein Einstieg OSGi-Architektur – Modularisierung – Dynamik von Bundles – Servicekonzept ZusammenfassungOSGi Konzepte Seite 3 / 38
  • 3. Agenda Modularisierung OSGi – ein Einstieg OSGi-Architektur – Modularisierung – Dynamik von Bundles – Servicekonzept ZusammenfassungOSGi Konzepte Seite 4 / 38
  • 4. AgendaQuelle : http://techdistrict.kirkk.com/2009/08/13/modularity-by-exampleOSGi Konzepte Seite 5 / 38
  • 5. 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
  • 6. 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
  • 7. 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
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. Agenda Modularisierung OSGi – ein Einstieg OSGi-Architektur – Modularisierung – Dynamik von Bundles – Servicekonzept OSGi Compendium Services ZusammenfassungOSGi Konzepte Seite 12 / 38
  • 12. Modularisierung und Java Java besitzt keine Unterstützung zur Modularisierung Bietet aber technologische Vorrausetzungen für Modularisierung – Classloader-KonzeptOSGi Konzepte Seite 13 / 38
  • 13. OSGi OSGi – Modularisierung mittels JavaOSGi Konzepte Seite 14 / 38
  • 14. 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
  • 15. Agenda Modularisierung OSGi – ein Einstieg OSGi-Architektur – Modularisierung – Dynamik von Bundles – Servicekonzept OSGi Compendium Services ZusammenfassungOSGi Konzepte Seite 16 / 38
  • 16. OSGi-Architektur - ModularisierungOSGi Konzepte Seite 17 / 38
  • 17. 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
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. 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
  • 22. OSGi-Architektur – Life CycleOSGi Konzepte Seite 23 / 38
  • 23. 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
  • 24. Laufzeitzustände von Bundles Start des Bundles Importe korrekt aufgelöst Stop des BundlesOSGi Konzepte Seite 25 / 38
  • 25. 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
  • 26. OSGi-Architektur - ServicesOSGi Konzepte Seite 27 / 38
  • 27. 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
  • 28. 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
  • 29. 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
  • 30. Agenda Modularisierung OSGi – ein Einstieg OSGi-Architektur – Modularisierung – Dynamik von Bundles – Servicekonzept OSGi Compendium Services ZusammenfassungOSGi Konzepte Seite 31 / 38
  • 31. 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
  • 32. Agenda Modularisierung OSGi – ein Einstieg OSGi-Architektur – Modularisierung – Dynamik von Bundles – Servicekonzept OSGi Compendium Services ZusammenfassungOSGi Konzepte Seite 33 / 38
  • 33. 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
  • 34. 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
  • 35. Zusammenfassung Modularisierung und Komponentenmodelle Ansatz von OSGi Architektur von OSGi – Modularisierung – Dynamik von Bundles – ServicekonzeptOSGi Konzepte Seite 36 / 38
  • 36. Referenzen[CBSD] http://en.wikibooks.org/wiki/Computer_programming/Component_based_ software_developmentOSGi Konzepte Seite 37 / 38
  • 37. 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
  • 38. Fragen?
  • 39. www.iks-gmbh.com