JAXenter.de

Das Portal für Java, Architektur, Cloud & Agile
X

Heute im W-JAX Countdown: Mike Wiesner über Spring vs. Java EE

Viele Neuerungen durch OSGi 4.2

Quantensprung für Equinox

Während die vergangenen Eclipse-Releases für Equinox eher geringfügige Änderungen brachten, so gibt es beim neuen Galileo-Release eine Vielzahl von neuen Features zu bestaunen, die überwiegend der neuen Version 4.2 von OSGi zu verdanken sind.

Der Name Galileo steht für bahnbrechende Neuerungen, und das gilt auch im Hinblick auf die neue Version 3.5 von Equinox, der OSGi-Implementierung von Eclipse. Galileo bringt hier im Wesentlichen die folgenden Neuerungen bzw. Änderungen:

  • Erweiterungen des Conditional Permission Admin Service, u.a. um Blacklists (RFC 120)
  • Erweiterungen der Service Registry als Grundlage für Remote Services (RCF 126)
  • Neu: Einheitliches Framework Launching (RFC 132)
  • Neu: Vorläufige Implementierung von Composite Bundles (RFC 138)
  • Kleine Änderungen am Framework API
  • Update Declarative Services auf 1.1 (RFC 134)

Davon dürften Framework Launching, Composite Bundles und Declarative Services 1.1 für die meisten von uns die größte direkte Bedeutung haben, sodass wir uns nachfolgend etwas detaillierter damit befassen werden.

Framework Launching

Bis dato definierte die OSGi-Spezifikation nur die Interaktion des "eigenen" Codes mit einem gestarteten OSGi Framework. Nun kommt mit dem Framework Launching ein API hinzu, mit dem beliebige OSGi Frameworks auf standardisierte Weise gestartet werden können. D.h. man kann auf ein und dieselbe Weise Equinox, Felix etc. starten, sofern diese die neue OSGi-Spezifikation 4.2 erfüllen.

Composite Bundles

Besonders im Enterprise-Umfeld zeigt sich die Notwendigkeit, bestimmte Bundles zu Gruppen bzw. Applikationen zusammenzufassen und gegenüber anderen Gruppen abzuschotten. Man denke z.B. an Fragen der Sicherheit, wenn mehrere Applikationen in einem OSGi Framework installiert werden. Dann kann es durchaus erforderlich sein, den Zugriff auf die öffentlichen Schnittstellen der Bundles nur aus der eigenen Applikation heraus zu erlauben.

Die OSGi-Spezifikation adressiert dieses wichtige Thema mit dem RFC 138. Dabei wird die Abschottung konzeptionell durch so genannte Composite Bundles und Child Frameworks erzielt. D.h. es ist möglich, eigenständige OSGi Frameworks innerhalb des eigentlichen Frameworks zu installieren und zu starten. Ein Composite Bundle "lebt" in einem solchen Child Framework, umfasst eine bestimmte Menge an Bundles und spezifiziert analog zu "normalen" Bundles die Abhängigkeiten sowie die öffentliche Schnittstelle "nach draußen".

Declarative Services 1.1

Declarative Services befindet sich zwar in der OSGi Compendium Specification, gehört aber seit Galileo zum "Standardumfang" von Equinox und Eclipse. Unter den inzwischen zahlreichen Service Component Models war Declarative Services bislang das einzige standardisierte, aber die "Konkurrenz" wie z.B. Spring Dynamic Modules und Felix iPOJO hatte z.T. frischere Ansätze. Ein besonders schwerwiegender Nachteil von Declarative Services war die Tatsache, dass es mit Ausnahme von einfachen Fällen nicht möglich war, POJOs als Service Components zu verwenden, u.a. weil die Aktivierung der Service Components und die Nutzung der Properties referenzierter Services nur mittels OSGi API möglich war. Declarative Services 1.1 behebt diese Schwächen und bringt weitere Flexibilität.

Die Methoden zur Aktivierung und Deaktivierung können nun beliebig benannt werden, die Spezifikation erfolgt über optionale Attribute des component Elements in der Component Description. Hinsichtlich der Signaturen gibt es verschiedene Alternativen, wobei bestimmte Parameter-Typen beliebig kombiniert werden können. Besonders wichtig hierbei ist die "POJO-Variante", welche die Component Properties in einer Map transportiert.

Analog dazu können nun die Methoden zum Binden der referenzierten Services verschiedene Signaturen aufweisen, wobei auch hier mittels einer Map die Service Properties übergeben werden können. Auf diese Weise kann die Implementierungsklasse insgesamt frei vom OSGi API bleiben, was mit Sicherheit ein Plus für die Testbarkeit darstellt.

All diese Methoden werden nun mittels Reflection auch innerhalb der Klassenhierarchie gesucht, sodass u.a. private Methoden in der Implementierungsklasse oder sichtbare Methoden in einer Superklasse möglich sind.

Um Equinox mitzuteilen, dass die Version 1.1 von Declarative Services verwendet werden soll, ist es erforderlich, in der Component Description den folgenden Namespace anzugeben:

http://www.osgi.org/xmlns/scr/v1.1.0

Fazit

Die hier im Detail vorgestellten Features stellen nur einen Teil der Neuerungen dar, die Equinox mit Galileo bringt. Aber sie werden uns Entwickler bei der täglichen Arbeit mit hoher Wahrscheinlichkeit früher oder später begegnen. Abschließend sei noch erwähnt, dass die Erweiterungen an der Service Registry im Rahmen von RCF 126 zwar kaum von unmittelbarer Bedeutung für Otto-Normal-Programmierer sein werden, aber die Grundlage für Remote Services darstellen, einer weiteren sehr interessanten Neuerung in der OSGi-Welt. Wir dürfen sehr gespannt sein.

 

Kommentare

Ihr Kommentar zum Thema

Als Gast kommentieren:

Gastkommentare werden nach redaktioneller Prüfung freigegeben (bitte Policy beachten).