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)
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".
