OSGi – Nein danke! Zu komplex für Otto-Normal-Entwickler?

Hartmut Schlosser

OSGi ist eine großartige Spezifikation für Middleware-Anbieter – aber eine furchtbare für Endverbraucher. So lautet das Fazit von Ross Mason, Architekt des Enterprise Service Bus Mule, in seinem Blog „OSGi? No Thanks„, in dem er erläutert, warum die Einführung von OSGi für Mule zu einem Misserfolg wurde.

Nach der anfänglichen Begeisterung im Mule-Team für OSGi habe sich nach Monaten der Kämpfe mit Manifest-Dateien, Bundle-Paketierungen und Build-Problemen Ernüchterung eingestellt. Das endgültige K.o. für OSGi sei dann die Unmöglichkeit gewesen, die Komplexität vor dem Endverbraucher zu verbergen.

Während die Prinzipien hinter OSGi grundsolide seien und Modularisierung für die JVM dringend benötigt werde, sei das OSGi-Modell doch zu komplex für den Entwickler, meint Mason. Schlimm sei es dann, wenn nach all der Anstrengung bei der Einführung von OSGi nicht einmal das Versprechen der Wiederverwendbarkeit von Bundles in verschiedenen Containern erfüllt werde.

As if developers didn’t have enough to think about, OSGi adds another complexity to building applications. Furthermore, the promise of bundles working cross-container doesn’t always work, making re-use more painful too. Every developer-focused blog around-OSGi tends to be complex and steeped with technical detail that demonstrates that OSGi just isn’t ready for the developer yet. Ross Mason

Für Mason steht fest: Modularisierung und Hot Deployment kann auf der JVM auch ohne OSGi realisiert werden – derzeit rechtfertigt der erzielte Nutzen mit OSGi (noch) nicht den nötigen Aufwand. Nur bei einer Überarbeitung der OSGi-Spezifizierung würde das Mule-Team die Einführung von OSGi wieder in Betracht ziehen:

If the next revision of the OSGi specification made it easier for developers to work with OSGi bundles (maybe relying more on convention over configuration) the Mule team would be very happy to re-investigate. As it stands modularization and hot deployment is very possible on the JVM without OSGi and the pain of day-to-day development with OSGi out-weighs its benefits. Ross Mason

In der anschließenden Kommentar-Diskussion wirft OSGi-Befürworter Neil Bartlett ein, die OSGi-Komplexität sei am besten durch geeignetes Tooling in den Griff zu bekommen, das derzeit allerdings erst dabei ist, zu entstehen (als Beispiel nennt er das Werkzeug bnd). Zudem sei ein großes System wie Mule inhärent komplex – OSGi mache diese Komplexität nur deutlich, lasse sie aber nicht wie von Zauberhand verschwinden.

Modularity exposes complexity and allows it to be managed. Shoot the messenger if you like, but that complexity isn’t going to go away on its own. Neil Bartlett

Andere Kommentatoren berichten über ähnliche Erfahrungen mit der Komplexität von OSGi wie das Mule-Team – und von dem ewigen Gegenargument, wer OSGi nicht meistere, müsse sich nur besser mit der Materie auseinandersetzen.

Well said, though the OSGi thought police have noted your dissidence and will shortly be pointing out how it’s your ignorance that is to blame, since everyone knows OSGi is the perfect solution for everything vaguely related to modular Java. Hani Suleiman

Einen antwortenden Blogpost hat Dmitry Sklyut verfasst, in dem er argumentiert, dass nicht OSGi komplex sei, sondern das Problem der Modularisierung selbst. Zudem sei OSGi ein dynamisches Modulsystem und erfordere deshalb schlicht einen gewissen Grad an technologischer Exzellenz.

Properly drawing boundaries between components is hard. Getting communication protocols and APIs right is hard. Unlearning habits of the past is hard. Dmitry Sklyut

Dynamic is not something that a regular developer ever learned to deal with properly. Dmitry Sklyut

Dass OSGi nicht die einzige Technologie ist, die im Anfangsstadium einen gewissen Widerstand erfährt, bis sie zum Common Sense geworden ist und durch ein geeignetes Tooling beherrschbarer gemacht wird, ist ein weiteres Argument zugunsten von OSGi.

Every new technology have its own learning curve and troublesome until things become standart. It was same for Enterprise Java, web projects, or even midlets. However nobody is complaining on those today. Either you become an early adoptor and face those difficulties or wait until things become standardized and use it afterwards. Murat

Ist OSGi also noch nicht reif für den Otto-Normal-Entwickler?

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.