Im Gespräch mit Raymond Augé

Arkadiko: Brückenschlag zwischen Spring und OSGi

Die Vorteile von OSGi genießen, ohne das Risiko einer kompletten Refaktorisierung einzugehen, dieser Aufgabe hat sich das Projekt Arkadiko verschrieben. Arkadiko ist landläufig als Name der ältesten Brücken aus dem antiken Griechenland bekannt – und so will auch das Arkadiko-Projekt eine Brücke schlagen zwischen existierenden Spring-Anwendungen und OSGi. JAXenter sprach mit Brückenbauer Raymond Augé von Liferay.

JAXenter: Worin liegen die Schwierigkeiten beim Portieren bestehender Java-Enterprise-Anwendungen auf OSGi?

Raymond Augé: Der OSGi-Standard sieht eine recht „puritanische“ Java-Architektur vor. Man kann auch sagen, dass die Strenge von OSGi es viel schwieriger macht, schlechte Programmierpraktiken auf niedriger Ebene aufzulösen, die sogenannten Classloader Hacks. Solche Hacks sind aber leider ein weit verbreitetes Problem in heutigen Java-Projekten. Um bestehenden Code also auf OSGi übertragen zu können, müssen diese Kunstfehler beseitigt werden – und das kann eine sehr teure und schwierige Angelegenheit werden. Wenn Code von Anfang an gut geschrieben ist, dann ist die Portierung auf OSGi eigentlich eine relativ einfache Sache. Der Aufwand wäre dann schlicht abhängig von der Größe und der Natur der Anwendung.

Die Portierung großer Teile gut geschriebenen Codes wird zwar immer noch einige Zeit in Anspruch nehmen. Dennoch wird die Portierung angenehmer sein als bei kleineren Mengen schlecht geschriebenen Codes. Andere Probleme erweisen sich oft als Nebeneffekte von schlecht geschriebenem Code, denn oft funktionieren die Abhängigkeiten in solchen Anwendungen in OSGi nicht. Dafür gibt es zwar Lösungen, allerdings machen diese zusätzliche Arbeitsschritte bei der Migration des eigenen Codes notwendig. Zum Beispiel könnte man das Entwickler Team dazu anhalten, Wrapper Bundles von Bibliotheken anzulegen, die noch keine OSGi Bundles anbieten.

JAXenter: Wie kann das neue Arkadiko Projekt helfen?

Raymond Augé: Wir wurden uns bewusst, dass die Kosten für eine OSGi-Portirung zu hoch sein könnten für Projekte, die über eine signifikante Menge von Code verfügen und/oder nicht die nötigen Ressourcen aufbringen können, um sich der Aufgabe voll zu widmen. Gleichzeitig bietet OSGi aber sehr große Vorteile bereits bei einer relativ oberflächlichen und frühen Integrationen. Als Plug-in-Mechanismus ist OSGi bereits sehr wertvoll. Es schien also logisch, dass die Einführung von OSGi so früh wie möglich passieren sollte. Doch es gab keine bewährte Praxis, wie wir das Potential maximieren und gleichzeitig das Risiko möglichst niedrig halten konnten.

Das Ziel von Arkadiko war es deshalb, einen möglichst großen Korpus bestehender Projekte so nah wie möglich an OSGi heranzubringen, ohne dafür auch nur eine Codezeile ändern zu müssen. Dieser große Korpus besteht natürlich aus dem Spring Framework. Wie die meisten Entwickler wissen, ist Spring das vermutlich am weitesten verbreitete Java Framework der Branche. Die Möglichkeiten und die Flexibilität von Spring sind quasi legendär, und ich denke, dass nur wenige, heute aktive Java-Entwickler noch nie mit Spring in Berührung gekommen sind. Vor diesem Hintergrund war es klar, dass es große Vorteile bringen würde, eine Brücke zwischen dem Spring Framework und OSGi zu schlagen. Das würde es möglich machen, früh von den Vorteilen von OSGi zu profitieren und gleichzeitig das Risiko effektiv zu senken, um einen langfristigen Ansatz zur Portierung oder Migration von Code nach OSGi zu verfolgen.

JAXenter: Was sind die Unterschiede zwischen Arkadiko und dem Ansatz von µservices von Peter Kriens.

Raymond Augé: µservices sind ideal, um Code-Teile voneinander zu entkoppeln. Ob nun innerhalb oder außerhalb von OSGi, µservices erlauben es dem Entwickler, die logischen Komponenten einer Applikation zu isolieren und eine lose Koppelung zu erreichen. Wenn diese Abgrenzung einmal erfolgt ist, ist es wirklich einfach, die Komponenten in OSGi abzubilden. Spring Beans sind sehr eng mit µservices verwandt, und man könnte sogar behaupten, dass Spring Beans idealerweise Implementierungen von µservices sein sollten. Der Ablauf der Migration von vorhandenem Code nach OSGi sollte immer dem Pfad eines Redesigns hin zu µservices folgen. Doch schon vor Erreichen dieses Ziels kann man die vorhandenen einzelnen Spring Beans in OSGi veröffentlichen, damit sie innerhalb von OSGi genutzt oder durch µservices ersetzt werden können – bis sie sich irgendwann in voll ausgereifte μservices entwickelt haben, paketiert und vollständig nach OSGi gebracht werden können. In diesem Sinne ist Arkadiko ein Verbündeter der µservices und bietet ihnen den Nährboden, auf dem sie wachsen und sich entwickeln können, bis die Ressourcen für eine Migration vorhanden sind. Zudem wird das Risiko bei einer Migration großer Anwendungen auf OSGi verringert.

JAXenter: Können Sie uns ein wenig über die Hintergründe des Projekts erzählen?

Raymond Augé: Arkadiko ist sehr neu, und nicht alle geplanten Features wurden bisher umgesetzt oder haben sich bewährt. Ich selbst habe Arkadiko im letzten Jahr konzipiert – ungefähr seit Anfang 2011 -, als mein Wunsch nach einer OSGi-Integration unserer eigenen, sehr großen Anwendung wuchs, um die Erweiterbarkeit zu verbessern und, was vielleicht noch wichtiger ist, die Wartbarkeit der Anwendung zu erleichtern.

Ich beziehe mich dabei auf das Liferary Portal, ein in der Industrie führendes Open-Source-Java-Portal für Enterprise Anwender (www.liferay.com).

Das Liferay Portal ist eine sehr große und technisch komplexe Anwendung mit vielen Erweiterungsmöglichkeiten. Allerdings verfügt die Anwendung über eine Plug-in-Architektur, die komplett auf den Web-Applikation/ Servlet-Spezifikationen basiert. Unser Versprechen, kompatibel mit praktisch jedem Servlet Container und App Server auf dem Markt zu sein, ob kommerziell oder Open Source, bedeutet, dass unsere Plug-in-Architektur vom jeweils unterliegenden Container abhängig ist. Das lässt uns mit der undankbaren Aufgabe zurück, uns mit der großen Anzahl der einzelnen Spezifikationen jedes Containers herumzuschlagen, was wirklich einen Wartungsalptraum darstellt.

Wenn unsere Plug-in-Architektur vollkommen unserer Kontrolle unterliegen würde, könnten viele, wenn nicht sogar alle diese Probleme verschwinden. Wir könnten die Strategie des „kleinsten gemeinsamen Nenners“ für die Eckdaten des Containers unserer Anwendung fahren. Wenn man zudem sieht, dass Liferay stark vom Spring-Framework Gebrauch macht, versteht man, was uns motivierte, Arkadiko ins Leben zu rufen.

Meine Absicht war es, einen möglichst risikofreien Weg zur Weiterentwicklung unserer Architektur nach OSGi zu finden. Es war klar, dass die Lösung der Aufgabe aufgrund der Größe und Komplexität unserer Anwendung mehrere Generationen des Produkts in Anspruch nehmen würde. Wir wollen das Produkt weiterhin vorantreiben und um zusätzliche Features ergänzen. Gleichzeitig wollen wir aber die Möglichkeit haben, einzelne Komponenten in eine modularere und wartungsfreundlichere Architektur zu integrieren. So ist schließlich Arkadiko entstanden!

Kommentare

Schreibe einen Kommentar

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