Die OSGi-Framework-Technologie wird mehr und mehr populärer. Unser Autor und Fachmann im Bereich OSGi Sven Haiges nutzte die Möglichkeit, ein Interview mit Peter Kriens zu führen, dem neu ernannten OSGi Evangelist und seit Beginn des Frameworks maßgeblich an dessen Entwicklung beteiligt.

Peter, du bist vor kurzem zum OSGi Evangelist ernannt worden – wie fühlst du dich in dieser Rolle und welche Ziele möchtest du erreichen?
Peter Kriens: Es ist eine spannende Aufgabe, die Technologie zu fördern, mit der ich seit 1998 arbeite. Mit den besten Java-Experten der Welt zu arbeiten und die Spezifikationen zu schreiben war bereits eine aufregende Sache, nun ist es jedoch an der Zeit, dem Werk den Erfolg zu verschaffen, den es verdient. Für 2006 haben wir viel vor, einiges davon ist schon im Gange. Erstens wird der OSGi-Blog – zusätzlich zu meinem privaten Blog auf www.aQute.biz – zweimal pro Woche einen neuen Artikel zur OSGi-Technologie erhalten. In den kommenden Monaten werde ich den Blog nutzen, um zu zeigen, wie der eigene OSGi-Server auf dem PC all die nützlichen Tasks ausführt und man gleichzeitig von vielen R4-Features profitiert.
Wir werden außerdem ein Bundle Repository auf bundles.osgi.org betreiben. Gemeinsam mit Olivier Gruber, Jeff McAffer und Richard S. Hall (der mit dem Oscar Bundle Repository Pionierarbeit geleistet hat) baue ich eine Federated Database of Bundles auf. Ob kommerziell oder Open Source: Wer sich professionell mit Bundles beschäftigt, wird sich in diesem Projekt engagieren können. Daraus wird hoffentlich ein Markt für Bundles entstehen.
Für den Embedded-Markt werden wir eine Demonstrationsplattform, die auf NSLU2 von Linksys basiert, zur Verfügung stellen. NSLU2 ist mit 80 US-Dollar sehr günstig und läuft auf OSGi. Ich möchte dafür mehrere Bundles entwickeln, um zu zeigen, dass OSGi nicht nur auf kleiner Hardware brauchbar ist, sondern auch ein einwandfreies Management-Modell mitbringt.
Auf der ApacheCon habe ich mit einigen Köpfen von OSGi darüber gesprochen, wie man mit dem Fehlen einer guten OSGi-Programmierdokumentation umgehen sollte. Ein Inhaltsverzeichnis zu erstellen und die Autoren zu Beiträgen zu bewegen ist von höchster Priorität für mich. Wir hoffen, ein solches Buch noch vor Sommerbeginn zu veröffentlichen. Die frohe Botschaft werde ich natürlich auf vielen Konferenzen verkünden müssen. Ich werde auf der JavaOne, EclipseCon und vielen weiteren Veranstaltungen anwesend sein.
Es verspricht also ein geschäftiges Jahr zu werden, auch weil wir immer noch an den Mobile and Vehicle OSGi Service Platforms arbeiten und ich von diesen Verpflichtungen noch nicht befreit worden bin.

Die OSGi R4 Core-Spezifikation ist seit dem OSGi-Kongress im Oktober 2005 veröffentlicht. Welche sind die wichtigsten Verbesserungen gegenüber R3?
Kriens: Declarative Services, Event Admin und die neuen Modul-Features. Declarative Services vereinfachen das Programmieren von OSGi Bundles. Es ist schon erschreckend, dass die Idee der Service Binder von Außenstehenden (Humbert Cervantes und Richard Hall) an uns herangetragen werden musste. Wir hätten uns eine Menge Ärger ersparen können, wenn wir dies schon in R3 gehabt hätten. Ich habe immer gehofft, dass wir gegen diese Form von Blindheit immun sind, aber was soll's.
Event Admin stellt ein zentrales Publish/Subscribe-Event-Modell bereit. Wir haben in der Expert Group lange darüber gesprochen, aber diesmal hat die Mobile Expert Group uns einen Schubs gegeben. Event Admin verringert die Anzahl der benötigten Listeners, indem es einen zentralen Punkt für das gesamte Event Management anbietet. Dies vereinfacht viele Programme erheblich.
Die mit Abstand wichtigste Korrektur im R4 betrifft den Module Layer. Der neue Module Layer unterstützt nun mehrere Versionen desselben Package. R3 Class Sharing war dafür gedacht, Spezifikationen zu teilen, aber nicht Implementierungen. R4 unterstützt Implementation Sharing voll.

Welche frei verfügbaren OSGi R4 Frameworks gibt es? Auf welchem Stand ist die Standard-Services-Implementierung?
Kriens: Meines Wissens nach existieren die folgenden Open-Source-Implementierungen: Apache Felix (ehemals Oscar), Eclipse und Knopflerfish. Alle drei arbeiten derzeit hart daran, Standard-Services zur Verfügung zu stellen, aber ich vermute, dass es noch eine Weile dauern wird, bis spezialisierte Services verfügbar sein werden. Knopflerfish hat jedoch R3 voll implementiert und sie arbeiten nun daran, es R4-kompatibel zu machen. Diese Bundles müssen auf den anderen Frameworks ebenfalls funktionieren. Die größte Lücke sind leider die Declarative Services. Nur Eclipse hat bislang eine Implementierung. Declarative Services benötigen bedauerlicherweise eine Hintertür zum Framework, sodass ihre Verwendung in anderen Frameworks ausgeschlossen ist, des Weiteren bieten Unternehmen wie IBM, Espial, Atinav, ProSyst, Gatespace Telematics und andere kommerzielle Implementierungen der Services an.

Das Mobile Experts Group Framework (bekannt als OSGi Mobile Framework) soll bis Ende des ersten Quartals 2006 abgeschlossen sein. Was haben Mobile-Entwickler davon zu erwarten und werden die großen Hersteller es unterstützen?
Kriens: Mobile-Entwickler können sich nun endlich aus dem Sandkasten befreien, in dem MIDP sie gefangen hält. Das OSGi-Framework ist eine viele reifere und systemorientiertere Umgebung, die sich nicht wie MIDP auf Spiele konzentriert. OSGi-fähige Mobiltelefone können für Enterprise Applications und System Services verwendet werden. Die serviceorientierte Architektur des OSGi-Frameworks erlaubt es Applikationen, ihre Umgebung zu teilen, sich ihr anzupassen und zusammenzuarbeiten. Essenziell ist auch, dass Java auf dem System-Level eine Rolle spielen kann: Die Mobile-Platform-Spezifikation ermöglicht es, Systemkomponenten in Java zu schreiben, zum Beispiel Screen Managers, OMA DM Node-Implementierungen, Deployment Resource Type Processors und vieles andere mehr.
Mir wurde ein Nokia-Handy mit einer vorläufigen Version der Mobile Service Platform versprochen (es hat Vorteile, Evangelist zu sein!). Es versteht sich von selbst, dass es auf die Reaktion der Anbieter ankommt. Um Erfolg zu haben, brauchen wir einen Anbieter, der die Geschäftsmöglichkeiten OSGi-fähiger Mobilteile erkennt. Kann ein Anbieter erst einmal mit Erfolgsgeschichten aufwarten, werden Hersteller und Anbieter bald um einen Platz auf diesem neuen Mobile-Enterprise-Software-Markt kämpfen. Einige der Großen im Enterprise-Markt lassen Interesse verlauten; es würde mich nicht verwundern, wenn Nokia damit ein gutes Geschäft machen wird.

Wenn wir das Rad der Zeit zur Gründung der OSGi Alliance 1999 zurückdrehen könnten, welchen Fehler würdest du nicht mehr begehen?
Kriens: Zu glauben, wir würden über Nacht Erfolg haben. Ich glaube, unser Anspruch, die Softwarewelt zu verändern, war ein wenig zu ehrgeizig.
OSGi-Programmierung hat eine Menge Vorteile und ich glaube immer noch an die Dynamik, jedoch war das Programmiermodell für Einsteiger nicht leicht.
Declarative Services haben das nun geändert, aber ich denke, wir hätten mit einem Modell anfangen sollen, das keine ganz neue Denkweise erforderte. Ich habe naiverweise geglaubt, dass wir die Welt ändern können, als IBM, Sun, Ericsson, Motorola, Oracle, Nortel und Hundert weitere große Unternehmen hinter uns standen. Nun bin ich klüger.

Was können wir von R5 erwarten? Hat die Arbeit bereits begonnen?
Kriens: Der Vorstand hat entschieden, die Hauptarbeit an R5 noch nicht zu starten und sich stattdessen auf die breite Akzeptanz von R4 zu konzentrieren. Dennoch haben wir eine Reihe von Dingen auf dem Plan, die wir gerne bearbeiten würden. 2006 sollte aber das Jahr der Einführung sein. Mit Blick auf Apache glaube ich, dass wir gute Aussichten auf Erfolg haben.

Vielen Dank für das Gespräch, Peter!

Die Fragen stellte Sven Haiges.