OSGi 4.2 - JAXenter

Was ist neu in der OSGi-Spezifikation 4.2?

OSGi 4.2

OSGi erfreut sich in den letzten Jahren als Modularisierungsinfrastruktur für Java-basierte Anwendungen zunehmender Popularität. Seit dem 24. September ist die Version 4.2 der OSGi-Spezifikation verfügbar und kann auf den Seiten der OSGi Alliance heruntergeladen werden (http://www.osgi.org/Specifications/HomePage). Anlass genug, einen genaueren Blick auf die Änderungen bzw. Neuerungen zu werfen, die in die neue Version Einzug gehalten haben.

Erweiterungen in der Frameworkspezifikation

Die OSGi-Spezifikation besteht aus der Spezifikation des OSGi-Frameworks sowie der Spezifikation verschiedener, auf dem Framework aufbauender Standardservices (dem so genannten Service Compendium). Auch wenn der Versionssprung nur kleinere Änd

erungen vermuten lässt, enthält die Version 4.2 der Frameworkspezifikation neben verschiedenen, kleinen Anpassungen auch eine ganze Reihe von Erweiterungen, die die Entwicklung von Anwendungen auf Basis des OSGi-Frameworks vereinfachen sollen:

  • Der Bundle Tracker (RFC 121) vereinfacht die Entwicklung von Bundles, die auf Statusänderungen anderer Bundles reagieren und in Abhängigkeit bestimmter Eigenschaften zusätzliche Aktionen ausführen sollen (so genannte Extender Bundles). Bislang mussten solche Bundles unter Verwendung von Bundle Listenern implementiert werden, was allerdings recht codeintensiv ist.
  • Service Registry Hooks (RFC 126) ermöglichen das „Abfangen“ von Serviceregistrierungen bzw. Serviceabfragen. Auf diese Art wird die Implementierung von generischer Funktionalität wie Remote- oder Proxy-Services ermöglicht. Service Registry Hooks bilden auch die Grundlage für die Spezifikation der Remote Services, die in der Version 4.2 des Service Compendiums definiert sind.
  • Der neue Framework Launching API (RFC 132) stellt eine einheitliche Schnittstelle für das Erzeugen, Konfigurieren und Verwalten von Instanzen des OSGi-Frameworks bereit. Da diese API bislang nicht spezifiziert war, realisierten in der Vergangenheit die verschiedenen OSGi-Frameworkimplementierungen eigene Mechanismen zum Erzeugen und Verwalten von Instanzen. Durch das neue API ist das nun unabhängig von der konkreten OSGi-Frameworkimplementierung möglich.
  • Erweiterungen des Conditional Permission Admin Service (RFC 120) ermöglichen es, Berechtigungen für bestimmte Bundles zu erlauben oder zurückzuweisen und vereinfachen die Anwendung des Conditional Permission Service für den Entwickler zusätzlich.
Erweiterungen in der Standard Servicespezifikation

Neben den Frameworkerweiterungen hat auch das Service Compendium einige Erweiterungen bzw. Neuerungen erfahren:

  • Die Remote-Service-Spezifikation (RFC 119) definiert, wie OSGi Services auch außerhalb einer JVM konsumierbar bzw. wie entfernte Services lokal verfügbar gemacht werden können. Dazu müssen beim Im- bzw. Export eines OSGi Service lediglich zusätzliche Service Properties eingetragen werden. Diese Properties beschreiben sowohl das Interface, unter dem der Service zugänglich gemacht wird oder konsumiert werden kann als auch so genannte Intents. Intents sind Anforderungen, die an einen Service gestellt werden. Diese Anforderungen müssen entweder vom Service Provider oder vom Distribution Provider erfüllt werden. Die Distribution Provider sind für den Im- bzw. Export eines Service unter einem oder mehreren Protokollen verantwortlich. Distribution Provider sind in der Remote-Services-Spezifikation nicht näher spezifiziert. Eine mögliche Implementierung aus dem Equinox-Umfeld bietet das Eclipse Communication Framework (ECF).
  • Der so genannte Blueprint Service (RFC 124) wird Entwicklern, die bereits Erfahrung mit dem Spring Framework und insbesondere mit Spring Dynamic Modules haben, recht vertraut vorkommen. Der Blueprint Service ist aus dem Spring-Dynamic-Modules-Projekt hervorgegangen und definiert den so genannten Blueprint Container, der XML-Definitionen innerhalb von Bundles benutzt, um Anwendungsobjekte über ein Dependency-Injection-Framework zu erzeugen und zu verknüpfen. Dabei wird insbesondere der potenziellen Dynamik von (OSGi) Services Rechnung getragen. Durch die Verwendung des Blueprint Service können die zu entwickelnden Anwendungs-Bundles frei von OSGi-spezifischem Code gehalten werden, was die Verwendbarkeit in Nicht-OSGi-Anwendungen und die Testbarkeit der Bundles deutlich verbessert. Darüber hinaus hat auch die Declarative-Service-Spezifikation verschiedene Erweiterungen und Verbesserungen bekommen, um die Entwicklung von Service Components weiter zu vereinfachen.
Wie geht es weiter?

Für das nächste Jahr hat die OSGi Alliance ein zugeschnittenes Release des OSGi Service Compendiums u. a. für den Bereich der Unternehmensanwendungen angekündigt. Die entsprechenden Standards werden derzeit von der Enterprise Expert Group (EEG) erarbeitet und umfassen unter anderem Standardservices für Integration von Webanwendungen und Persistenz-techniken.

Gerd Wütherich arbeitet als freiberuflicher Softwarearchitekt und -berater. Er verfügt über langjährige Erfahrung im Entwurf und in der Realisierung großer, Java-basierter Anwendungssysteme, die er in unterschiedlichen Projekten im Finanz- und Logistikbereich gesammelt hat. Darüber hinaus ist er regelmäßiger Referent auf Konferenzen, Autor verschiedener Fachartikel und Koautor des Buchs „Einführung in die OSGi Service Platform“. Weitere Informationen unter http://www.gerd-wuetherich.de.
Bernd Kolb ist selbstständiger Berater und Coach mit Schwerpunkt auf Plug-in-Architekturen für und mit Eclipse sowie modellgetriebener Softwareentwicklung. Er ist Co-Autor eines Buches und von Artikeln sowie Sprecher auf Konferenzen. Bernd ist unterwww.kolbware.de oder b.kolb[at]kolbware.de zu erreichen.
Geschrieben von
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.