OSGi ist heute nach vielen Jahren stillen Engagements in aller Munde. Nun hat sich in Deutschland das OSGi User Forum gegründet; wir haben Kai Hackbarth, Mitbegründer des User Forums, ein paar Fragen gestellt.

Derzeit vergeht kaum eine Woche ohne OSGi-News. Ist 2008 das Jahr von OSGi?

Kai Hackbarth: Davon bin ich überzeugt. Viele Unternehmen beschränken sich nicht mehr auf das Reden über OSGi, sondern setzen die OSGi-Technologie mittlerweile auch ein. Auf dem ersten Treffen des deutschsprachigen OSGi-Userforums im Juni in Berlin hatten wir auf Anhieb 60 Teilnehmer. Ich denke dies zeigt deutlich, wie groß das Interesse an OSGi ist.

Die nächste große Ankündigung wird zweifelsohne die für September geplante Gründung des deutschen OSGi-Userforums sein. Was ist das OSGi-Userforum und welche Ziele werden damit verfolgt?

KH: Das OSGi-Userforum hat insbesondere das Ziel, die OSGi-Technologie im deutschsprachigen Raum bekannt zu machen und einen Erfahrungsaustausch im Umgang mit der Technologie zu ermöglichen. Darüber hinaus bildet das Userforum eine Schnittstelle zur OSGi Alliance und anderen nationalen Userforen.

Wer gehört zu den Gründungsmitgliedern?

KH: Zu den Gründungsmitgliedern gehören bekannte OSGi-Protagonisten und Interessierte wie CAS AG, Deutsche Telekom Labratories, Eclipse Foundation, FH Hannover, MicroDoc GmbH, ProSyst Software GmbH und die PTV AG. Weitere Unternehmen und Universitäten haben bereits ihr Interesse bekundet, sich als Gründungsmitglied zu beteiligen.

Im Vergleich zu anderen Ländern hat die Gründung des deutschen Userforums etwas länger gedauert. Was hat die Gründung verzögert?

KH: Deutschland hat sicherlich eine der größten OSGi Communities weltweit. Ich kann mir das nur so erklären, dass durch die an sich schon sehr starke Community ein Austausch im Rahmen anderer Events und Konferenzen stattfand und damit das Interesse anfänglich etwas verhalten war. Mit dem Enterprise-Java-Bereich, der die Vorteile von OSGi jetzt auch für sich entdeckt hat, haben wir eine viel größere Community, die auch bezüglich OSGi sehr engagiert in Foren, Konferenzen etc. vertreten ist.

Wer sollte sich im OSGi-Userforum engagieren? Müssen Interessierte bestimmte Voraussetzungen erfüllen?

KH: Das Userforum heißt jeden willkommen, der an der OSGi-Technologie interessiert ist. Bis auf einen zu zahlenden Jahresbeitrag müssen keine Voraussetzungen erfüllt werden. Der Jahresbeitrag wird voraussichtlich bei 200 Euro liegen - bei Universitäten, Non-Profit-Organisationen und Privatpersonen bei 25 Euro. Wir freuen uns natürlich über jede aktive Beteiligung.

Obwohl die Industrie seit vielen Jahren auf OSGi setzt, hat die breite Java Community die Plattform scheinbar erst kürzlich entdeckt. Wie ist das mittlerweile spürbar stärkere Interesse an OSGi zu erklären?

KH: OSGi hat wegen des ursprünglichen Fokus auf Embbeded-Systeme und der Segmentierung zwischen Java ME, SE und EE nicht die breite Java Community angesprochen. Das stärkere Interesse, das wir in den letzten zwei Jahren erfahren haben, hängt unter anderem damit zusammen, dass mit der Eclipse-Entwicklungsumgebung die erste bekannte Anwendung außerhalb des Embedded-Umfelds auf OSGi gesetzt hat. Mit BEA microService Architecture, GlassFish, IBM Websphere und SpringSource Application Platform setzen nun weitere bekannte Java-EE-Produkte bzw. -Projekte auf OSGi, die jeweils über eine große Community verfügen.

Was sind heute die klassischen Einsatzgebiete von OSGi?

KH: Im Embedded-Umfeld wird OSGi überwiegend in Smart-Home Gateways, Telematiksystemen und Smartphones eingesetzt. Das klassische Einsatzgebiet gibt es aber nicht, OSGi kann in so vielen vertikalen Märkten eingesetzt werden. OSGi-Implementierungen werden beispielsweise in Züge eingebaut, in Healthcare-Geräte, Router, Mobiltelefone, Haushaltsgeräte, Gebäudeautomatisierungssysteme aber auch in Parkhausschrankensysteme von Flughäfen. Es gibt auch Projekte wie die Vernetzung aller japanischen Erdbebenwarnsysteme und beim amerikanischen Militär die Aufspürung von Massenvernichtungswaffen mittels mobiler Endgeräte.

Interessant ist, dass in jüngster Zeit Produkthersteller auf OSGi setzen. Als Beispiel sei hier ein CMS-Produkt genannt, das seine modulare Erweiterungsfähigkeit OSGi verdankt. Gibt es noch andere Beispiele für Produkte, die die Stärken von OSGi nutzen, um klassische Produktanforderungen wie leichte Anpassbarkeit, Erweiterungsfähigkeit und Systemintegration zu ermöglichen?

KH: Open eXchange hat kürzlich bekannt gegeben, dass die neueste Version ihrer Groupware-Software auch auf OSGi basiert. Leider erfährt man nur selten, ob und wie genau OSGi eingesetzt wird, da es im Wesentlichen nur für den Softwareentwickler von Interesse ist.

Das klingt nach einer Menge Arbeit für die OSGi Alliance und die nationalen Userforen, hier für die notwendige Transparenz zu sorgen.

KH: Auf jeden Fall. Dennoch wird es deutlich leichter werden, im Enterprise-Umfeld für mehr Transparenz und einen gesunden Erfahrungsaustausch zu sorgen als im Embedded Bereich, der erfahrungsgemäß etwas verschlossener agiert.

Unbestritten hat Eclipse einen wesentlichen Anteil an der Bekanntheit von OSGi. Ist Equinox und die Art und Weise, wie in Eclipse OSGi eingesetzt wird, ein klassisches und zeitgemäßes Einsatzgebiet?

KH: Durchaus. Eclipse demonstriert sehr schön alle Vorteile von OSGi. Sei es die Erweiterbarkeit durch Plug-ins (OSGi Bundles), das Überprüfen von Abhängigkeiten zu anderen Plug-ins, das Lifecycle-Management etc. Unter anderem konnte dank der OSGi-Technologie die Eclipse Foundation ein Ökosystem rund um die Eclipse-Entwicklungsumgebung mit weit mehr als 1000 Plug-ins aufbauen. Wegen des generischen Designs der OSGi Middleware gibt es natürlich viele andere zeitgemäße Einsatzgebiete, die sich in Details unterscheiden.

Mit der Spring Application Platform setzt ein weiterer populärer Vertreter der Java Community auf OSGi. Wie ist dieser Schritt von Spring zu bewerten?

KH: Auch bei der Entwicklung von Enterprise-Applikationen spielen Modularität und Versionierung eine immer größere Rolle. Mit SpringSource hat sich nach IBM, Bea/Oracle nun ein weiterer Infrastrukturanbieter für OSGi und somit für eine standardisierte und bereits bewährte Lösung entschieden. Die Enterprise Expert Group spezifiziert zurzeit ein an Spring Dynamic Modules angelehntes Komponentenmodell für OSGi. Diese ist optional, da es auch weitere Komponentenmodelle im Enterprise- und insbesondere im Embedded-Umfeld gibt.

Was sind die nächsten großen (technologischen) Herausforderungen für OSGi?

KH: Die OSGi Expert Groups arbeiten gerade sehr aktiv am OSGi-Spezifikation-Release 4.2, das im zweiten Quartal 2009 erscheinen soll. Die Enterprise Expert Group beschäftigt sich derzeit u.a. mit dem bereits beschriebenen Komponentenmodell und mit verteilten OSGi-Anwendungen. Die Residential Expert Group fokussiert sich auf Remote-Management von OSGi Frameworks und arbeitet aufgrund der immer größeren Bedeutung von OSGi in Smart-Home Gateways auch mit anderen Organisationen zusammen. Des Weiteren gibt es ein großes Interesse an Universal OSGi. Hier geht es darum, ein gleichwertiges OSGi Framework für C++ zu spezifizieren. Das C++ Framework soll das Java Framework nicht ersetzen, sondern ergänzen. Insbesondere für Telematiksysteme ist dies sehr wichtig, da man durchaus die Vorteile von Java und OSGi nutzen möchte, aber bei zeit- und sicherheitskritischen Anwendungen Java nicht überall nutzen kann. Die Vehicle Expert Group beschäftigt sich gerade mit diesem Thema.

Bleibt zu hoffen, dass hier kein erneuter Religionskrieg ausgefochten wird.

KH: Den klassischen C++- versus Java-Religionskrieg erwarte ich an dieser Stelle nicht. Vielmehr zeigt das große Interesse wichtiger Player im Telematikbereich, dass die OSGi-Technologie etablierte Konzepte und Ansätze bietet, die es zu "portieren" lohnt. Die Devise heißt ganz klar: Miteinander statt gegeneinander.

Bekanntermaßen genießen Technologien mit 1000 Seiten Spezifikation in der Java Community keinen wirklich guten Ruf. Was unterscheidet OSGi von EJB?

KH: Der eigentliche Kern der OSGi-Spezifikation, die Middleware, beträgt genau 274 Seiten. Der Rest der Spezifikation sind optionale domänenspezifische Erweiterungen. Aufgrund dieser domänenspezifischen Aufteilung (Enterprise, Mobile, Residential, Vehicle) müssen nur wenige Firmen bzw. Entwickler die komplette Spezifikation kennen. Zum Unterschied zu EJBs: EJBs haben eine starke Abhängigkeit an ihre Laufzeitumgebung, die vollständig verstanden sein muss. Vollständig heißt hier aber neben der eigentlichen EJB-Spezifikation auch zahlreiche andere Java-EE-Spezifikationen, die zusammengenommen 1000 Seiten um ein Vielfaches überschreiten. OSGi-Komponenten entsprechen dagegen mehr dem "leichgewichtigen Ansatz", was z.B. durch die hohe Adaptionsrate im Enterprise-Bereich bewiesen wird.

Wie sollte dann der Einstieg in OSGi erfolgen?

KH: Man muss sich mit den Konzepten der OSGi-Spezifikation, insbesondere mit Bundles und Services vertraut machen. Neben zahlreichen Artikeln und Blog-Einträgen fehlt es leider noch an Dokumentationen für Programmierer. Mir ist derzeit nur ein einziges Buch bekannt, dass sich ausschließlich der OSGi-Technologie widmet. Mit der wachsenden Anzahl der OSGi-Entwickler wird sich dies bestimmt in naher Zukunft ändern. Hier soll das deutschsprachige OSGi-Userforum als Plattform zum Informations- und Erfahrungsaustausch dienen und somit den Einstieg in die OSGi-Technologie vereinfachen.

Wann bzw. warum sollte man den Einsatz von OSGi in Erwägung ziehen?

KH: Wenn man sich für Java entschieden hat, dann ist der Einsatz von OSGi der nächste logische Schritt. Jede vernünftige Architektur sollte auf Komponenten und einer modularen Einteilung aufbauen. OSGi ist das beste Komponentensystem im Java-Umfeld. Mithilfe von serviceorientierten Architekturen, wie OSGi eine ist, kann der Entwicklungs-, Integrations- und Wartungsaufwand von Softwarekomponenten um 40% reduziert werden. Auf lange Sicht sogar noch mehr, da auch die Wiederverwendbarkeit von Modulen ein erhebliches Einsparungspotenzial bietet.

Der Lackmus-Test heißt also: Wenn eine Architektur Komponenten verwendet, dann ist OSGi die passende architektonische Antwort?

KH: Definitiv "Ja" für Java-Anwendungen.

Was sind die größten Fallstricke für einen klassischen Enterprise-Java-Entwickler?

KH: Bei Enterprise-Systemen werden fast ausschließlich Open-Source-OSGi-Implementierungen eingesetzt. Die Middleware allein hilft einem Enterprise-Entwickler nicht wirklich weiter. Da Technologien wie Hibernate und ein Web-Framework in der Spezifikation fehlen, muss zurzeit der gesamte Stack vom Programmierer selbst zusammengestellt werden. Mit dem ModuleFusion-Projekt versucht ProSyst die Community hierbei zu unterstützen.

Nun schlägt der eine oder andere Embedded-Entwickler die Hände über dem Kopf zusammen, wenn er das erste Mal mit einem Enterprise-Entwickler zu tun hat, der dank OSGi seine ersten Gehversuche im Embedded-Umfeld startet. Woran liegt das?

KH: Mit OSGi hat Java zum ersten Mal ein domänen- und technologieübergreifendes Komponentenmodell. Es ist doch schon zu sehen, dass nun Programmier aus den verschiedenen Bereichen zusammenarbeiten können. OSGi stellt hier den gemeinsamen Nenner. Außerdem kommen doch Enterprise und Embedded in vielen Bereichen zusammen. Nehmen Sie den Bereich Mobile Devices. Sind Enterprise-Anwendungen auf dem Handy jetzt Enterprise oder Embedded? Ein bisschen von beidem, und OSGi kann den idealen gemeinsamen Nenner stellen.

Als größtes OSGi Anti-Pattern wird die Verwendung von Class.forName() genannt. Was ist hier das Problem?

KH: Class.forName() war eine beliebte Methode von Legacy-Anwendungen, die zur Laufzeit Module nachladen mussten. OSGi bietet dagegen den umfangreicheren Bundle-Mechanismus, der in der Regel vorzuziehen ist. Falls der Programmierer ein noch feineres Class Loading benötigt, bietet OSGi eine umfangreiche API an, die die OSGi-Metadaten wie Versionierung berücksichtigt.

Nun starten Softwareprojekte selten auf der grünen Wiese. Wie migriere ich eine bestehende Softwarelandschaft nach OSGi?

KH: Dies hängt sicherlich sehr stark von dem existierenden Projekt ab. Oft lässt sich ein Zusammenhang zwischen den existierenden Jar-Dateien und zukünftigen Bundles herstellen. Im nächsten Schritt könnte nun die Kommunikation zwischen den Bundles mit der Hilfe der OSGi-Service-Registry umgesetzt werden. Existierende Abhängigkeiten zwischen Klassen und Methodenaufrufen funktionieren natürlich wie gehabt.

Seit einiger Zeit hat Sun einen Teilaspekt von OSGi, die Modularisierung, verstärkt im Focus. Was sagt die OSGi Community zu den Initiativen von Sun, wie zum Beispiel JSR 277 (Java Module System)?

KH: Die OSGi - aber auch die Java Community - ist sehr verwundert, das Sun dieses JSR ins Leben gerufen hat, da es mit OSGi bereits einen in der breiten Java Community akzeptierten Standard gibt. Darüber hinaus gibt es auch keine klare Position, ob man OSGi adaptiert oder nicht. Man tut der Java Community mit zwei verschiedenen Komponentenmodellen sicherlich keinen Gefallen. Sun war eines der Gründungsmitglieder der OSGi Alliance und ist jetzt auch wieder ein Mitglied. Bei GlassFish setzt man bereits auf die OSGi-Technologie, insofern gehe ich davon aus, dass wir gemeinsam eine sinnvolle Lösung finden werden.

Welches Ergebnis würden Sie sich wünschen?

KH: Das ideale Ergebnis wäre ein klares Bekenntnis zur OSGi-Technologie.

Ich danke für das Gespräch.

Das Interview führte Jens Schumann.

Kai Hackbarth ist einer der Initiatoren des deutschsprachigen OSGi-Userforums. Er arbeitet seit mehr als sieben Jahren bei der ProSyst Software GmbH und ist seit dem auch in die Standardisierungsaktivitäten der OSGi Alliance eingebunden, bei der er das OSGi Requirements Working Committee sowie die Vehicle und Residential Expert Group leitet.