Enterprise OSGi: The Big Picture

Resümee

Wir haben gelernt, dass es sehr wohl möglich ist, eine Enterprise-Anwendung modular aufzubauen. Eine wichtige Grundlage dafür ist der OSGi-Enterprise-Standard. OSGi ist also durchaus etwas für Enterprise-Anwendungen – und wir müssen nicht auf das Modulsystem Jigsaw aus dem JDK warten, das mit Java 9 kommen soll (zumindest laut aktueller Planung).

Mit Eclipse Gemini haben wir eine stabile und ausgereifte Implementierung der wichtigsten Bestandteile der OSGi-Enterprise-Spezifikation kennen gelernt. Insbesondere das Dependency-Injection-Framework Gemini Blueprint ist eine echte Bereicherung für OSGi. Gemini Blueprint ist die ideale Wahl für Spring-Anhänger oder um bestehende Spring-Anwendungen mit OSGi zu modularisieren. Es verbindet Spring mit OSGi und ist der Türöffner in die Spring-Welt. Wenn schon Spring im Spiel ist, dann können wir von weiteren Frameworks aus dem Spring-Okösystem profitieren: von Spring Data JPA, Spring Security, Spring Batch und vielen mehr. Damit bleiben kaum noch Wünsche offen.

Aber wir wollen nichts beschönigen: Die Enterprise-Frameworks für OSGi sind noch lange nicht so ausgereift wie für JEE oder Spring. Das haben wir bei gleich bei der Persistenzschicht gemerkt, wo die Unterstützung für wichtige Datenbanktreiber fehlt – oder auch bei den Transaktionen. Wo es für JEE etablierte Best Practices gibt, braucht es für Enterprise OSGi hin und wieder etwas Pioniergeist. Aber es lohnt sich. Wir erhalten dafür echte Modularität. Jedes Bundle ist ein eigenständiges Modul mit klaren Grenzen und Verantwortlichkeiten. OSGi stellt sicher, dass niemand diese Grenzen übertritt. Das ist wichtig. Warum nicht einmal kurz aus dem UI eine SQL Query absetzen? Schließlich muss es schnell gehen, und wir haben keine Zeit, es „richtig“ zu machen. Mit OSGi sind Sie zumindest gezwungen, im UI Bundle die Datasource und JDBC Bundles zu importieren. Und damit würde auffliegen, dass gerade die oberste Schicht (das User Interface) mit der untersten Schicht (der Persistenzschicht) verkoppelt wird. Das widerspricht fundamental der Schichtentrennung der Anwendung.

Auch beim Ausliefern von Bugfixes sind wir mit OSGi im Vorteil. Eine JEE-Anwendung wird als EAR-File ausgeliefert, die Code und abhängige Libraries enthält. Bei OSGi können wir unsere Anwendung als Menge von Bundles ausliefern. So besteht bei JEE unsere Auslieferung beispielsweise aus einem 45 MB großen EAR-File und bei OSGi aus 45 MB OSGi Bundles. Wenn wir im ersten Fall, bei JEE, einen Bugfix liefern – also ein 45 MB-EAR-File -, versichern wir dem Kunden hoch und heilig, dass wir nur einen Bug in dem UI gefixt haben, der Rest der Anwendung aber unverändert ist. Bei OSGi hingegen genügt es, dem Kunden das aktualisierte, 0.8 MB große UI Bundle mit dem Bugfix auszuliefern. Welche Auslieferung wird der Kunde als riskanter empfinden?

Ob es sich lohnt, für eine Enterprise-Anwendung OSGi zu verwenden, muss jedes Projekt für sich entscheiden. Auf jeden Fall gehört OSGi bei der Entscheidung mit auf den Tisch. Für viele Projekte ist sicherlich auch die Kombination von Spring mit OSGi interessant. Also halten wir uns ran, denn es wartet noch viel Arbeit auf uns. Unser Kunde verlangt schon nach einem Web Service, das Marketing fragt nach, ob unsere Enterprise-Anwendung auch Cloud-fähig ist. Und, ach ja, wie sieht es mit LDAP aus? Aber Android können wir doch auch, oder?

Jan Stamer ist Senior Software Engineer beim Sustainability Experten PE INTERNATIONAL. Er ist dort verantwortlich für weltweit führende Softwarelösungen, um Produkte und Unternehmen nachhaltiger zu gestalten.
Kommentare

Schreibe einen Kommentar

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