Blog Enterprise OSGi bei n-design - Vorteile modularer Anwendungen für Unternehmen & Herausforderungen bei der Entwicklung

Enterprise OSGi bei n-design - Vorteile modularer Anwendungen für Unternehmen & Herausforderungen bei der Entwicklung

Unternehmensanwendungen erreichen heute schnell einen Grad an Komplexität, der eine große Herausforderung für die Software-Entwicklung darstellt. Um langfristig wartbare Systeme zu entwickeln, ist ein hohes Maß an Modularisierung der Anwendung notwendig. Nur so können große Unternehmensanwendungen in überschaubare Einheiten zerlegt werden. Java bietet bezüglich der Beschreibung von Modulen nur unzureichende Möglichkeiten. OSGi stellt ein Modularisierungssystem mit dynamischer Service-Orientierung dar, das den Anforderungen der Strukturierung von Unternehmensanwendungen gerecht werden kann.

Java EE – Standard der Unternehmensanwendungen

Mittels Java implementierte Unternehmensanwendungen werden heute in der Regel nach der Spezifikation der Java Enterprise Edition (Java EE) entworfen. Diese beinhaltet eine Fülle von Programmierschnittstellen (APIs), die im wesentlichen der Ausführung von Webanwendungen, dem Definieren von Transaktionen und dem Zugriff auf die Datenhaltung innerhalb einer Anwendung dienen. Java EE-Anwendungen werden dabei in einem Application Server ausgeführt, der die Gesamtheit der Java EE-APIs bereitstellt. Alternativ können sie in einem separaten Servlet Container unter zusätzlicher Verwendung von Frameworks, die einzelne Java EE-APIs implementieren, betrieben werden.

Die neueren Versionen der Java EE sind heute weitaus komfortabler zu handhaben als die Versionen bis J2EE 1.4. Dies ist zu einem erheblichen Teil der Integration von Konzepten aus der Open Source Community zu verdanken (z.B. Spring für Kontexte und Dependency Injection (CDI) oder Hibernate für die Java Persistence API (JPA). Aktuelle Java EE-Anwendungen können so deutlich leichtgewichtiger, im Sinne von geringer Kopplung an die Laufzeitumgebung, entwickelt werden.

Java kennt keine Kapselung auf Modul-Ebene – Verbergen von Schnittstellen-Interna

Ein wesentliches Strukturierungselement für die Architektur komplexer Softwaresysteme fehlt jedoch in Java EE: Das Modul. Java bietet generell durch die Objektorientierung, die Gliederung in Packages und Java Archive (JAR) die Möglichkeit, eine modulare Architektur umzusetzen. Packages, ursprünglich als Module einer Java-Anwendung vorgesehen, erweisen sich jedoch als zu feingranulare Strukturen für die Implementierung eines Moduls. Daher ist es üblich, Module als JAR-Dateien abzubilden. Den JARs wiederum fehlt ein wesentlicher Bestandteil objektorientierter Entwicklung, nämlich die Kapselung, d.h. der Zugriff auf alle öffentlichen Klassen und deren Methoden ist möglich. Dies verhindert das Bereitstellen einer klar definierten API eines Moduls und das Verbergen von Implementierungsdetails zugunsten einer wartungsfreundlichen Schnittstelle.

OSGi – Module für Java

Die OSGi-Spezifikationen definieren ein dynamisches Komponentensystem für Java. Ursprünglich für „Embedded“ Anwendungen vornehmlich im Automotivbereich konzipiert, wird OSGi zunehmend auch zur Modularisierung von Unternehmensanwendungen verwendet.

Ein Modul wird in OSGi durch ein JAR-File (Bundle) abgebildet, welches zusätzliche Informationen in seinem Manifest enthält. Diese beschreiben im Kern die für andere Module sichtbaren Bestandteile in Form exportierter Packages. Gleichzeitig werden hier die zu importierenden Packages anderer Module deklariert. Damit sind die versionierbaren Abhängigkeiten zwischen Modulen vollständig beschreibbar und können auf das Nötigste reduziert werden. Dadurch gewinnt das Modul einen hohen Grad an Wiederverwendbarkeit, da die Kopplung zwischen den Modulen verringert wird. Erreicht wird diese Form der Kapselung durch eine wohldefinierte Struktur von Classloadern bei der jedes Bundle seinen eigenen Classloader verwendet.

Micro Services – Kommunikation zwischen Modulen

In einer OSGi-Laufzeitumgebung können Module Exemplare von Klassen anderer Module erzeugen, wenn die entsprechenden Packages in das Modul importiert werden. Eine Variante, die die Wartbarkeit eines komplexen Systems deutlich erhöht, ist die Verwendung von Services. Der Service-Layer ist ein weiterer Kernbestandteil der OSGi-Spezifikationen. Es ist ein leichtgewichtiger Mechanismus zur Registrierung und zur Verwendung von Services innerhalb einer Java Virtual Machine (JVM). Hierdurch werden zwei wesentliche Aspekte bedient: Zum einen wird durch die Verwendung eines Services die Nutzung einer Funktion vollständig von ihrer Implementierung entkoppelt. So können Wartungen ohne Änderungen der Service-Klienten durchgeführt werden. Zum anderen wird hierdurch die Dynamik innerhalb einer OSGi-Laufzeitumgebung ermöglicht.

Module und Services können in OSGi dynamisch gestartet und beendet sowie installiert werden. Dies ermöglicht einen ununterbrochenen Betrieb einer Anwendung bei einem Austausch von Modulen und Services zur Laufzeit. Nutzt eine Unternehmensanwendung den Service-Layer von OSGi, ist so z.B. das Einspielen eines Bugfixes für einen Service zur Laufzeit möglich, ohne dass hierfür die komplette Anwendung heruntergefahren wird und während der Setup-Phase nicht zur Verfügung steht. Dies bedeutet einen enormen Vorteil für den Nutzer und auch für den administrativen  Betrieb der Software.

Enterprise OSGi – Komplexität Handhaben

n-design sieht sich stetig wachsender Mengen zu verarbeitender Daten und den Abhängigkeiten zwischen Systemen gegenüber. Auch mit Java EE ist es möglich, der steigenden Komplexität mit gut strukturierten Anwendungen zu begegnen. OSGi bietet uns jedoch zusätzlich die oben angerissenen Eigenschaften und damit deutlich mehr Möglichkeiten, die Abhängigkeiten zu strukturieren. Unsere Kunden erhalten besser konzipierte Anwendungen, die sich perfekt an die Bedürfnisse der Einsatzumgebung im Unternehmen anpassen.
Die Spezifikationen im Bereich „Enterprise OSGi“ integrieren nun die Java EE-APIs in das Modul- und Service-System. Diese Adaption ist notwendig, da sich die Java EE-APIs nicht ohne weiteres in einer OSGi-Laufzeitumgebung betreiben lassen. Dies liegt in der Regel daran, dass einzelne Java EE-APIs ein eigenes System zur losen Kopplung oder Separation von Modulen beschreiben, wie etwa die Kontexte in einem Servlet-Container. Die unterschiedlichen Konzepte in Einklang zu bringen, ist Ziel der Enterprise OSGi Spezifikationen.

Designen mit Modulen und Services – Umdenken

Die Strukturierung einer Anwendung in Module erfordert eine serviceorientierte Architektur, da Services ideal sind, um die Dynamik in einer modularisierten Umgebung zu handhaben. Hat man als Software-Ingenieur bisher „Modularisierung“ nur auf Objektebene betrieben, so ist ein Umdenken erforderlich, da ein Modul-System weitere Strukturelemente für das Design zur Verfügung stellt. Auch bei unmittelbarer Einsicht bezüglich der Vorteile von OSGi, braucht es doch einige Erfahrung, bis ein Micro-Service-orientiertes Design routiniert entworfen werden kann. Dann jedoch lernt man Module und Services schnell schätzen und setzt sie intuitiv ein, da sich Änderungen im Code dann in der Regel nur begrenzt auf das Gesamtsystem auswirken. Damit sind Wartungsarbeiten leichter durchführbar und bergen ein geringeres Fehlerrisiko bei gleichzeitiger Verfügbarkeit der Anwendung.

OSGi und der Rest der Welt – Bibliotheken verwenden

Nachdem wir bei n-design unsere ersten Erfahrungen mit OSGi gesammelt haben war klar: Module und Services brauchen wir, das Integrieren von nicht auf OSGi abgestimmten Bibliotheken brauchen wir nicht!
Viele in Standard-Java selbstverständlich verwendete Bibliotheken und Frameworks lassen sich nicht ohne weiteres in einer OSGi-Laufzeitumgebung verwenden. Dies liegt in der Regel daran, dass diese Bibliotheken Annahmen über das Classloading machen, die unter OSGi nicht zutreffen (z.B. bei der Verwendung eines Thread Context Classloaders) oder der Dynamik der Laufzeitumgebung nicht gerecht werden. Hierbei sind immer wieder Hürden zu nehmen.
Mit der zunehmenden Verbreitung von OSGi und vor allem mit der Implementierung der OSGi Enterprise Spezifikationen hat sich hier allerdings viel getan. Mittlerweile basieren alle großen Enterprise Application Server auf OSGi. Diese bieten zunehmend OSGi-Features für die darin auszuführenden Applikationen an. n-design haben die Vorteile von Enterprise OSGi für die Entwicklung anspruchsvoller Unternehmensanwendungen überzeugt. Die Vorteile für Kunden durch unterbrechungsfreie Updateprozesse, komfortable Erweiterungen der Funktionalität sowie die Plattformunabhängigkeit zur Ausführung, ermöglichen aktuelle Bedürfnisse bestens abzubilden.

 

Kommentar schreiben

Sicherheitscode
Aktualisieren

Mutation Testing
Marco Oetz
Überlegungen zu...
Alexander Krumeich
Testen im Team mit OpenSSL
Alexander Krumeich
Testen im Team
Alexander Krumeich
TIY - Test it yourself
Stephan Hoffmann-Emden
Mocking Frameworks...
Andreas Klotz
Docbook - Integration in...
Thomas Spadzinski
Docbook - Dokumentieren...
Thomas Spadzinski
Chaos bei privaten...
Mandy Boujatouy
Smart Home statt Altenheim!
Albert Holtmüller
WEB oder APP in der...
Dominic Sommer