... das neue, das überall ist.
Angefangen hat es vor 8 Jahren als eine Service Plattform Spezifikation für embedded und network devices. Nun gehen immer mehr Middleware Frameworks, Produkte, etc. OSGi. IBM liebt OSGi.
z.B. Eclipse, Geronimo aka Websphere Application Server Community Edition, die nächste Version von Websphere Application Server classic, verschiedene der neuen Lotus Produkte, das Spring-Framework und eine Menge andere Sachen.
So richtig greifbar ist es für mich immer noch nicht.
Es geht um Modularisierung. Also um die übersichtlichere Aufteilung von komplexen Anwendungen. Bestimmte Dinge können für die Aussensicht eines Moduls unsichtbar gemacht werden (Übersichtlichkeit).
Ausserdem können die Module unabhängig voneinander neu geladen werden (hot deployment, d.h. Teile der Anwendung auszutauschen, ohne die ganze Anwendung oder gar den Server neu zu starten).
Versionierung: verschiedene Module einer Anwendung können für sich jeweils unterschiedliche Versionen z.B. eines jars verwenden -> das kann mit dem jetzigen Stand der Technik echt nervig sein.
Wenn man in die neuen Lotus Technologien wie Quickr, Expeditor, etc. will, kann es nicht schaden, darüber einen gewissen Überblick zu gewinnen.
Der letztes Jahr von IBM zu Interface21 gewechselte Adrian Coyler (bekannt von AspectJ) gibt in diesem Interview die für mich bislang schlüssigste Einführung.
http://www.infoq.com/interviews/osgi-adrian-colyerEs ist zugegeben ziemlich abstrakt, aber ich denke auch wichtig. Im Eclipse Umfeld ist OSGi ziemlich fortgeschritten und für mein Gefühl entsteht bei Anfängern in Eclipse-plug-in Entwicklung viel Verwirrung, dass sie sich zu wenig mit den Modularisierungskonzept plug-in aka bundle beschäftigen.
Wenn man natürlich nicht weiss, dass Versionierung, hot deployment und Modularisierung wichtige Mittel sein können, um sich realen Ärger zu ersparen, wird man das vermutlich schnell abschalten.
Zunehmend abstraktere Werkzeuge helfen immens, um übersichtlicheren und leichter zu wartenden Code zu erzeugen. Auf der anderen Seite leckt jede Abstraktion. Für mich hab ich festgestellt, dass mir ein Überblick über neue Abstraktionen helfen kann, um reale Probleme zu lokalisieren. Auch wenn ich die innere Wirkungsweise der Abstraktion nicht völlig verstanden habe. Z.B. fror letztens mein schöner JSF Layer nach dem 12. bis 15. Seitenaufruf gegen Tomcat regelmässig ein. Ich konnte das dann aber beheben. Und zwar nicht, weil ich den Fehler wirklich low level gefunden hätte, sondern einfach indem ich in meinem Code recht zielgenau nach den dieses Problem verursachende Unreinheiten fahnden konnte.
Pepe Carvalho
