OSGi und das Schweizer Sackmesser

Transkript

1 OSGi und das Schweizer Sackmesser Bernd Weber Trivadis GmbH München Schlüsselworte: OSGi, SOA, Java, Architektur, PAX Tools Einleitung: Die OSGi Service Plattform gewinnt als eines der modernsten Komponentensysteme für Java zunehmend an Bedeutung und hat nach den Embedded Systemen inzwischen praktisch alle Java Application Server infiltriert. Die Plattform reduziert durch systematische Modularität die Komplexität in der Anwendungsentwicklung und bietet ein hohes Maß an Flexibilität und Dynamik. Klingt toll? Ist es auch, allerdings verbunden mit einigem Umdenken - der Dienstgedanke ist allgegenwärtig, und gerade am Anfang sollten einige Weichen richtig gestellt werden. Die PAX Tools helfen einem hier über die ersten Hürden und stehen auch bei Projekt-Migrationen zur Verfügung. Dieser Vortrag vermittelt das nötige Rüstzeug für einen erfolgreichen Start in die OSGi-Welt. Herausforderungen Heutige Software-Systeme bestehen regelmäßig aus komplexen, oft über viele Jahre gewachsenen Strukturen. Zyklische und/oder ungewollte Abhängigkeiten zwischen den einzelnen Bestandteilen und Schichten sind ebenso oft anzutreffen wie heterogene Technologien, verstreut über das Gesamtsystem. Die Heilsversprechen der Objektorientierung, insbesondere die Wiederverwendung lose gekoppelter Klassen und Teilsysteme, sind vielfach ein Wunschtraum geblieben, da es ihr an einem Standard für Modularität und Dynamik auf der Ebene von Komponenten gebricht. Trotzdem steigt die Zahl produktiver Softwaresysteme seit Jahren exponentiell mit immer wieder neuen Ansätzen zur Bewältigung echter Dynamik; deren Pflege und Wartung allerdings krankt oft an unvorhersehbaren Seiteneffekten schon bei kleinsten Änderungen, und wirklich portabel sind solche Systeme eher selten. Architektur-Überblick Die OSGi-Spezifikation nimmt sich dieser Herausforderungen an; als eine Plattform für Dienste spezifiziert sie eine mehrschichtige Architektur für dynamische, Komponentenbasierte Systeme. Diese Spezifikation beschreibt alle wesentlichen Aspekte eines Software- Systems und bleibt dabei trotzdem einfach zu verstehen. OSGi-basierte Systeme zeichnen sich durch das dynamische Zusammenspiel einzelner Komponenten aus, deren gegenseitige Verwendbarkeit, Lebenszyklus und Verwaltung klar geregelt sind. Insgesamt beschreibt

2 OSGi eine universelle Middleware, die die Modularität - schwache Kopplung bei starker Kohäsion zum Prinzip erklärt, jede Komponente (Bundle) als eine vollständig beschriebene Einheit definiert und dadurch auch komplexe Systeme beherrschbar macht. Dienst nach Vorschrift Die Dienstschicht (Service Layer) unterscheidet zwischen der Definition von Diensten und deren Implementierungen, wodurch alternative Implementierungen eines Dienstes auch zur Laufzeit möglich sind. Dienste werden als Java-Interface definiert, in einer spezifischen Form implementiert und der Dienstregistratur (Service Registry) des Frameworks bekannt gegeben. Die Dienstregistratur verwaltet selbige und bietet verschiedene Abfragemöglichkeiten an. Hat man darüber den passenden Dienst gefunden, kann dieser wie eine lokale Klasse verwendet werden. Da Dienste zur Laufzeit kommen und gehen können, bietet das Framework Hilfsklassen wie den ServiceTracker, die dieses dynamische Verhalten weitgehend von der Verwendung des Dienstes trennen und so die Programmierung mit Diensten vereinfachen. Dieses Dienstmodell entspricht den Kernelementen einer Dienst-orientierten Architektur (SOA), ohne auf die dort dominierenden Protokolle HTTP/SOAP festgelegt zu sein. OSGi ist mit Version 4.1 zwar noch auf eine Java Virtual Machine eingeschränkt, doch der kommende Standard 4.2 verwischt diese Grenze mit der Einführung von Distributed OSGi. Modularität ist Pflicht OSGi erhebt die Modularität zum Paradigma und konkretisiert dies in der Pflicht, alle für das Funktionieren einer Komponente notwendigen Bestandteile wie Code, Resourcen oder Fremdbibliotheken in Form eines sogenannten Bundles selbst mitzubringen oder als Abhängigkeit von Java-Packages oder anderen Bundles samt deren Version explizit zu benennen. Dadurch ergibt sich ein Klassenraum je Bundle, der von einem Bundlespezifischen Classloader verwaltet wird und der Implementierung zur Verfügung steht. Dieses

3 Vorgehen erschlägt gleich mehrere Herausforderungen: zum Einen werden Abhängigkeiten überhaupt erst einmal sichtbar, zum Anderen werden die beliebten Spaghetticode-Strukturen wirksam unterbunden und die Komponenten bleiben lose gekoppelt, und zum Dritten ist das parallele Vorhalten verschiedener Versionen einer Bibliothek problemlos möglich. Die in Java-Archiv-Dateien (JARs) stets vorhandene Datei META-INF/MANIFEST.MF wird genutzt, um diese Informationen abzulegen. Neben den zur Bundle-Identifikation stets notwendigen Einträgen Bundle-SymbolicName und Bundle-Version sind dies allen voran die Einträge Import-Package zur Beschreibung von Abhängigkeiten auf Java-Package-Ebene, Require-Bundle zur Angabe von Abhängigkeiten zu anderen Bundles, und Export-Package zur Freigabe eigener Packages für den Import durch andere Bundles. Als Schmankerl können diese Abhängigkeiten mit Versions-Intervallen eingeschränkt werden, die wie in der Mathematik mit offenen oder einschließenden Klammern versehen sein können. Ring des Lebens Der Lebenszyklus (Life Cycle) eines Dienstes ist mit demjenigen des implementierenden Bundles untrennbar verbunden. Enthält ein Bundle die Implementierung eines Dienstes und hat diese Kombination aus API und Implementierung beim Framework registriert, so wird diese spezifische Dienstausprägung automatisch deregistriert, wenn das umgebende Bundle angehalten oder entfernt werden soll. Die Verwender von Diensten tun daher gut daran, sich erst unmittelbar vor Aufruf einer Dienst-Methode die Referenz auf diesen Dienst zu besorgen. Nutzt ein Bundle mittels Import-Package Klassen eines anderen Bundles, so sorgt das Framework dafür, dass dieses Bundle erst gestartet werden kann, wenn ihm die importierten Packages zur Verfügung stehen. Ein einmal gestartetes Bundle kann sich darauf verlassen, dass ihm Dank des in der Spezifikation definierten Bundle-Caches die importierten Abhängigkeiten zur Verfügung stehen, bis es angehalten und seine Abhängigkeiten neu aufgelöst wurden. Insgesamt kann ein Bundle folgende Zustände annehmen: installed (steht dem Framework für weitere Aktionen zur Verfügung) resolved (Abhängigkeiten konnten vom Framework aufgelöst werden) starting (Aufruf von BundleActivator.start bzw. Component.activate) active (das Bundle wurde erfolgreich gestartet und nutzt/bietet Dienste) stopping (Aufruf von BundleActivator.stop bzw. Component.deactivate bis Rückkehr) uninstalled (Bundle wurde deinstalliert, kann keinen anderen Status mehr annehmen) Java Execution Environment Über den Manifest-Eintrag Bundle-RequiredExecutionEnvironment kann ein Bundle festlegen, welche Mindestmenge an Klassen zur Laufzeit vorhanden sein müssen. Damit lassen sich sehr kleine Virtuelle Maschinen definieren, wie sie im Mobilfunk- und Embedded- Bereich eingesetzt werden. Gültige Werte sind z.b. OSGi/Minimum-1.1 (minimal set that allows the implementation of an OSGi Framework)

4 J2SE-1.4 (Java 2 SE 1.4.x ) JavaSE-1.6 (Java SE 1.6.x ) Alle Werte: OSGi Service Platform Core Specification, 3.3 Execution Environment Framework-Implementierungen OSGi-Frameworks gibt es in drei Geschmacksrichtungen: kommerziell, OpenSource und zertifiziert. Zertifizierte OSGi-Implementierungen sind vorwiegend kommerzieller Natur; angesichts der notwendigen Vollmitgliedschaft in der Allianz und der damit verbundenen personellen und finanziellen Aufwendungen verwundert dies nicht. Einzig die nach einem ähnlichen Modell wie die OSGi Alliance finanzierte Eclipse Foundation schickt mit Equinox 3.2 einen prominenten, wenn auch nicht mehr ganz taufrischen OpenSource-Vertreter in's Rennen. Die OSGi Alliance hat derzeit folgende Service-Plattformen als OSGi R4-konform zertifiziert: Makewave Knopflerfish Pro 2.0 ( ProSyst Software mbedded Server 6.0 ( Eclipse Equinox 3.2 ( Samsung OSGi R4 Solution ( HitachiSoft SuperJ Engine Framework ( OpenSource-Implementierungen Frei verfügbare OpenSource-Implementierungen der OSGi-Plattform verhelfen ihr zu ungeahnter Verbreitung. Waren in den angestammten Bereichen Mobiltelefonie, Heimautomatisierung und Fahrzeugelektronik die großen Industriekonzerne mit ihren Produkten noch weitgehend unter sich, tummeln sich inzwischen verschiedene ausgereifte OpenSource-Implementierungen im aufstrebenden Enterprise-Segment. Deren wichtigste Vertreter sind: Eclipse Equinox ( auf der Eclipse und dessen Derivate basieren, Makewaves Knopflerfish ( der interessanteste Name im Feld, und Apache Felix ( u.a. Default-OSGi-Container des PAX Runners.

5 Empfehlungen Die richtige OSGi-Framework-Implementierung gibt es nicht. Wie so oft entscheidet auch hier der künftige Verwendungsrahmen und die bisherige Software-Landschaft. Der Einsatz von Eclipse als Entwicklungsumgebung ist jedenfalls noch kein Grund, ausschließlich mit Equinox zu liebäugeln. Vielmehr existieren Eclipse-Plugins wie Pax Runner, die die Auswahl zwischen verschiedenen Framework-Implementierungen und -Versionen als Laufzeitumgebung des OSGi-Containers in Eclipse ermöglichen. Muss ein bestimmter Grad an Verlässlichkeit der OSGi-Plattform garantiert werden, z.b. im Rahmen eines Service Level Agreements (SLA), sollten die zertifizierten Produkte näher betrachtet werden. Bei ihnen gibt es die Gewähr dafür, dass aufwendige Tests durchgeführt und erfolgreich bestanden wurden, dass die Interoperabilität genauso geprüft wurde wie die Realisierung aller definierten Schnittstellen. Die Menge an zertifizierten Produkten ist zwar überschaubar, aber trotzdem vielfältig genug, um in verschiedenen OSGi-Kernbereichen zu überzeugen. Einige Hersteller zertifizierter Produkte bieten sogar SLAs dafür an, was die zu erwartende Zuverlässigkeit nochmals erhöht. Equinox ist eine gute Wahl, wenn man sich Eclipse zum Vorbild genommen und einen Rich Client zum Ziel hat; auch Server-seitig kann diese Framework-Implementierung überzeugen und verfügt mit der Version 3.2 sogar über ein OSGi-Zertifikat. Wer sich auf der Kommandozeile nicht wohl fühlt oder die vielen Zusatzangebote der Eclipse Foundation nutzen möchte, dürfte mit der Kombination aus Equinox und Eclipse als IDE glücklich werden. Knopflerfish und Felix haben gegenüber Equinox zwar eher den Charme von Außenseitern, weisen aber ebenfalls eine große Vielfalt an über den Standard hinausgehender Technologie auf und lassen sich von der Kommandozeile aus erstellen, konfigurieren und bedienen. Mit beiden Implementierungen können Rich Clients ebenso gut erstellt werden wie Server- oder Web-Applikationen. Und im Gegensatz zur Kombination aus Eclipse und Equinox wird man nicht dazu verführt, Bundle-Abhängigkeiten durch die IDE-Brille zu betrachten. Wichtiger als die Wahl der persönlichen OSGi-Geschmacksrichtung ist das Vermeiden von Abhängigkeiten. Wer sich nicht auf eine Framework-Implementierung festlegen muss, sollte deren Eigenheiten vermeiden, um die OSGi-Plattform austauschen zu können. Hier helfen automatisierte Integrationstests, die etwa mittels Maven-Profilen den Tests verschiedene OSGi-Implementierungen zugrundelegen und Spezifika schnell aufdecken helfen. Noch weniger Abhängigkeiten hat, wer reine POJOs ohne Verwendung der OSGi-API erstellt und sie mittels IoC-Frameworks wie OSGi Declarative Services, OSGi Blueprint Services, Spring DM oder Felix ipojo anspricht. Deklarative Ansätze Reine OSGi APIs sind mächtig, aber nicht immer einfach zu verwenden. Am Besten schreibt man daher POJOs (Plain Old Java Objects) ohne Bezug zu einem Framework. Vorsichtig muss man lediglich bei extrem Performance-kritischen Bereichen wie Embedded Devices

6 sein, da ein geringer Teil der Performance durch die Indirektionen verloren geht. Es gibt einige deklarative Applikationsmodelle für OSGi, allen voran die Declarative Services aus dem OSGi Service Compendium sowie die ebendort ab Version 4.2 befindlichen Blueprint Services. Letztere bilden die weitgehend baugleichen Spring Dynamic Modules aus dem Hause SpringSource in die OSGi-Spezifikation ab und sorgen für einige Umbenennungen, bleiben aber inhaltlich nahe beieinander. Diese drei Varianten verfolgen ein deklaratives Modell, welches auf XML-Dateien beruht, in denen die Komponenten, deren Eigenschaften und Abhängigkeiten deklariert und von einer Laufzeitkomponente ausgelesen und angewandt werden. Apache ipojo hingegen verfolgt einen anderen Ansatz: es setzt auf Annotations, was eventuelle Nutzer zwar mindestens zu Java 1.5 zwingt, aber andererseits den Vorteil hoher Geschwindigkeit und guter Lesbarkeit von Deklaration und betroffener Komponente aufweist. ipojo hat sich inzwischen zur Plattform vieler Erweiterungen entwickelt, so z.b. zur Nutzung mittels JMX oder zur Konfiguration per ConfigurationAdmin aus dem OSGi Standard. Welcher der deklarativen Ansätze sich letztlich durchsetzen wird, ist derzeit nicht abzusehen. Sinnvoll ist der Einsatz einer dieser Varianten im Vergleich zur programmierten Verwendung von Referenzen und Diensten allemal, da die Laufzeitumgebung automatisch für die richtige Verkabelung sorgt. Einzig Kleingeräte mit sehr begrenzten Resourcen dürften damit weniger gut zurechtkommen. Die PAX Tools Gab es anfangs als Werkzeuge im unmittelbaren OSGi-Umfeld lediglich das BND-Tool von Peter Kriens (Cheftechnologe der OSGi Alliance) sowie mit Abstrichen das Eclipse Plugin Development Environment (PDE), so hat sich auf der Plattform Open Participation Software for Java ( ein ganzer Zoo an OSGi-Hilfsmitteln aller Art entwickelt, der meist unter dem Begriff PAX Tools oder auf (süd-)deutsch unter Schweizer Sackmesser für OSGi firmiert. Die wichtigsten Vertreter der PAX Tools sind: PAX Construct (Skript-Sammlung zur Erzeugung und Verbindung von OSGi-Maven- Projekten) PAX Runner (Werkzeug zur Herstellung einer weitgehend konfigurierbaren Laufzeitumgebung) PAX Exam (Erweiterung von JUnit4 zur Erstellung von OSGi-Integrationstests) PAX Web (Erweiterung des OSGi HTTP Service um besseren Servlet-Support, Filter, Listener, Fehlerseiten und JSPs zur Abdeckung der Servlet Spezifikation) Fazit OSGi ist den Kinderschuhen längst entwachsen und durch die Java Application Server heutiger Bauart auch im Enterprise-Umfeld präsent. Die Nutzung dieser Technologie empfiehlt sich überall dort, wo mehr als ein kurzes Hallo Welt auf der Konsole verlangt wird.

7 Die quasi erzwungene Modularität wirkt sich vor allem in großen Systemen schnell vorteilhaft aus, da Abhängigkeiten sichtbar sind, einzelne Komponenten unabhängig entwickelt und mittels Integrationstests sehr gut getestet werden können. Die Open-Source- Implementierungen der OSGi Service Platform sind ausgereift, Entwickler werden durch die PAX Tools sehr gut in ihrer Arbeit unterstützt. Und der moderne Ansatz der Inversion of Control durch Dependency Injection wird gleich mehrfach angeboten. Damit dürften es auch hartgesottene Konservative schwer haben, den Einzug von OSGi in ihr konkretes Umfeld zu verhindern. Kontaktadresse: Bernd Weber Trivadis GmbH Lehrer-Wirth-Straße 4 D München Telefon: +49(0) Fax: +49(0) Bernd.Weber@trivadis.com Internet: