Software-Upgrade: Migration von Hibernate nach EclipseLink

Inhaltsverzeichnis

Auch Software ist einem Alterungsprozess ausgesetzt. Techniken, die heute angesagt sind, können morgen von gestern sein. Für Softwarebetreiber ist es deshalb ratsam, ihre Applikationen gut zu pflegen und sie regelmäßig der neuesten technischen Entwicklung anzupassen. Wie das gelingen kann, zeigt eine im Rahmen eines Kooperationsprojekts migrierte Enterprise-Java-Applikation.

Enterprise-Java-Systeme bestehen aus vielen standardisierten Komponenten. Diese in sogenannten "Java Specification Requests" des Java Community Process (JCP) beschriebenen Standards werden in der Regel in einem Rhythmus von zwei bis fünf Jahren erneuert. Der Betreiber einer Java-EE-Applikation (Java Enterprise Edition) steht also regelmäßig vor der Frage, ob er die Teilkomponenten seiner Software auf den jeweils neuesten Standard umstellen soll. Oft findet man jedoch nur wenige Argumente für ein solches Update, weil die Applikation im Regelfall nur den Funktionsumfang der alten Komponentenversion nutzen kann und die Features der neuen Variante zudem häufig ungenutzt bleiben. Ein Mehrwert der Umstellung ist deshalb für den Betreiber in vielen Fällen nicht erkennbar.

Dennoch ist aus technischer Sicht ein Upgrade empfehlenswert. Schließlich kann der Softwarehersteller die Pflege alter Komponenten auf lange Sicht einstellen und die Aufrechterhaltung von Sicherheit, Konvergenz und Kompatibilität der Applikation mit geringerem Aufwand sicherstellen. Die gesamte Software wäre früher oder später überholt. Ein Komponenten-Upgrade ist daher zu befürworten.

Wie man dieses umsetzen und die Applikation gleichzeitig für die neuen Funktionen der verbesserten Komponente öffnen kann, erprobten erstmals 2009/10 die zwei Softwarehäuser Micromata und Yatta Solutions in Kooperation mit der Universität Kassel bei einem Softwaresystem der K+S AG. Das Projekt wurde im LOEWE-Förderprogramm unter der Projektnummer 168/08-30 von der Hessen Agentur gefördert.

Die Aufgabe

Im Rahmen einer laufenden Applikation sollte Micromata die Persistenztechnik JPA 1/Hibernate nach JPA 2/EclipseLink migrieren, ohne dafür den Betrieb der Software zu unterbrechen. Zu diesem Zweck verwendete Micromata UML Lab, ein Tool von Yatta Solutions. Das Werkzeug überträgt Quelltext in eine Modellansicht, in der sich das Softwareprojekt gemäß den Anforderungen der neuen Version übersichtlich und effizient anpassen lässt. Ein wesentliches Merkmal von UML Lab stellt das Template-basierte Reverse Engineering dar. Das hierdurch gewonnene Modell abstrahiert von Implementierungsdetails und lässt sich für Weiterentwicklungen verwenden (Round-Trip Engineering). Anschließend generierter Quelltext unterscheidet sich ohne Zutun des Entwicklers nicht vom ursprünglichen Quelltext; selbst Whitespaces und Kommentare erhält UML Lab.

Persistenzvorgeschichte

Etwa ab 2004 entwickelte sich Hibernate zum Liebling unter den als Open-Source-Software verfügbaren objektrelationalen Mappern (ORM). Das Team um Gavin King schrieb bereits früh wegweisende Konzepte wie die Hibernate Query Language (HQL) oder die Criteria API. Der JCP-Standardisierungsprozess der Java Persistence API (JPA) hinkte indes der Entwicklung immer ein bis zwei Jahre hinterher. Durch die Mitarbeit von Gavin King im JSR 220 (Enterprise JavaBeans 3.0) konnten sich beide Konzepte dann weitgehend annähern.

Nach Kings Rückzug als "First Class Contributor" im Hibernate-Projekt verlor die ORM-Technik ab 2008 allerdings an Schwung. In der Folge wurde vermehrt die Referenzimplementierung von JPA 2 (EclipseLink) (ehemals TopLink) als alternativer ORM herangezogen.

Das "K+S GeoBASE II"-Projekt bei Micromata

Für das Bergbauunternehmen K+S AG sollten im Projekt GeoBASE II alle Daten der nationalen und internationalen Standorte in einer einzigen zentralen Datenbank in der Kasseler Unternehmensleitung zusammenlaufen. Hierzu wurden alle Werke auf einen einheitlichen datentechnischen Stand gebracht. Dass allein das Verbundbergwerk Werra des DAX30-Unternehmens eine größere Gesamtfläche als die Stadt München hat, verdeutlicht die Dimension des Projekts.

Bei GeoBASE II handelt es sich um eine klassische, geschäftskritische Client-Server-Anwendung. Deshalb sind die Informationen möglichst performant an den Client zu übertragen. Vor allem beim Enterprise Information System (EIS) besteht die Herausforderung, dass auf der einen Seite große Datenmengen an den Client weitergeleitet werden, die diesem auf der anderen Seite möglichst zügig zur Verfügung stehen müssen. Aus diesem Grund existieren im Projekt verschiedene Arten von DTOs (Data Transfer Objects), die dazu dienen, alle Informationen aus der Datenbank vom Server an die Clients zu übertragen. Von diesen DTOs gibt es drei Arten:

• eine, die alle Informationen aus der Datenbank überträgt,
• eine, die alle Referenzen an andere Datenbankobjekte anhängt und nur die zugehörigen Primary Keys der referenzierten Objekte enthält, und
• eine, die eine Untermenge der eigentlichen Informationen überträgt und dazu dient, dem Client eine Vorschau des eigentlichen Objekts zur Verfügung zu stellen.

Bei GeoBASE II hat man also für jede Datenbank-Entity bis zu vier zu implementierende Klassen, zuzüglich der Konvertierungsmethoden, die nötig sind, um zwischen den Datenbankobjekten und den Datenbanktransferobjekten zu konvertieren.

Der konventionelle Weg

Der traditionelle Weg zum Upgrade einer Anwendung besteht darin, sämtliche Datenbankobjekte (Database Objects, DO) von Hand anzupassen. Bei großen Projekten ist das zwangsläufig eine langwierige und mühsame Fleißaufgabe. Eine manuelle Konvertierung bringt zudem die Gefahr überflüssiger Flüchtigkeitsfehler mit sich. Alternativ lassen sich die Datenbankobjekte mit einfachen Textersetzungen anpassen. Dieses Vorgehen aber birgt den Nachteil, dass sich neue Programmierparadigmen, die in der Welt von JPA 2 inzwischen Einzug gehalten haben, in der Transformation keine Berücksichtigung finden. Für solche Transformationen ist in der Regel ein tieferes Verständnis des Modells notwendig.

Beide Wege erfordern darüber hinaus die Unterbrechung sämtlicher anderer Entwicklungstätigkeiten an der Software, da die Modifikation des Quelltexts Konsequenzen nach sich zieht, die bei der weiteren Programmierung zu berücksichtigen und deshalb abzuwarten sind. Die Herausforderung aber bestand darin, weder den laufenden Betrieb der Software noch ihre Weiterentwicklung in anderen Teilbereichen zu unterbrechen. Gewünscht war daher ein automatisierter Prozess, der ein sukzessives Upgrade von Komponenten erlaubt, ohne den (Entwicklungs-)Betrieb zu verzögern oder zu beeinträchtigen.