Software-Upgrade: Migration von Hibernate nach EclipseLink

Transkript

1 c't ix Technology Review Mac & i mobil Security Netze Download Telepolis Resale Foto Autos Preisvergleich Marco Sebastiao Software-Upgrade: Migration von Hibernate nach EclipseLink Programmieren, modellieren, konvertieren 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[1], 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 1 von :10

2 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 Das Werkzeug ist in Eclipse integriert und unterstützt simultanes Arbeiten an Modell und Quelltext; Änderungen werden in die jeweils andere Sicht übertragen. Sowohl Abstraktion des Modells als auch Details im Quelltext bleiben durch Template-basiertes Reverse Engineering erhalten (Abb. 1). 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. 2 von :10

3 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. Upgrade auf Basis von Modellen Ein Upgrade darf keinesfalls die Semantik der Applikation verändern. Die Logik des Modells muss folglich unangetastet bleiben. Deshalb ist es wünschenswert, ein System zu haben, das den Code, im konkreten Fall den von JPA 1, in ein Modell einliest, um hieraus wiederum Quelltext in JPA 2 zu erzeugen. Beim Generieren von Quelltexten aus Modellen spielen herkömmliche UML-Werkzeuge ihre Stärke aus. Über Templates kann man für jegliche Aspekte der UML eine Repräsentation im Quelltext definieren. Da die Logik der zu konvertierenden Applikation aber nicht modelliert, 3 von :10

4 sondern programmiert wurde, muss die Software das Modell aus dem bestehenden Quelltext erzeugen. Die Unterstützung von Modellierungswerkzeugen für die Rückgewinnung eines Modells aus handgeschriebenem Quelltext ist jedoch unzureichend. Gewöhnliche Reverse-Engineering-Techniken bieten keine Möglichkeit, über Templates auf die Generierung des Modells Einfluss zu nehmen, womit sie unflexibel und nicht an eigene Bedürfnisse (wie sie gerade bei gewachsenen Legacy-Systemen regelmäßig vorkommen) anpassbar sind. Außerdem abstrahieren diese Techniken nicht in hinreichendem Maß, sodass das resultierende Modell von rein technisch motivierten Implementierungsdetails überfrachtet wird. Die Migration auf einen neuen technischen Standard wäre somit genauso umfangreich wie diese direkt im Quelltext selbst vorzunehmen. Dadurch waren die Anforderungen an ein Tool für das Projekt klar definiert: Der Quelltext war in ein Modell einzulesen, dem ein allgemeines Datenbankmetamodell zugrunde liegt. Es musste im Modell von Implementierungsdetails abstrahieren können, um im Anschluss aus dem Modell den Quelltext für die Zieltechnik zu generieren. Das ist ein Anwendungsfall für UML Lab, eine in Eclipse integrierte Modeling IDE, die einen automatischen Abgleich zwischen Quelltext und Modell ermöglicht. Yatta Solutions bezeichnet die Technik als Round-Trip Engineering. Beim Reverse Engineering wird anders als bei anderen Tools ein Template-Ansatz verfolgt. Dabei kommen dieselben Templates, die üblicherweise bei der Codegenerierung (Forward Engeneering) genutzt werden, auch für das Reverse Engineering zum Einsatz. Der Vorteil hierbei ist, dass Konzepte aus dem Modell, die die Templates auf vielen Quelltextfragmenten (auch über Dateigrenzen hinweg) abbilden, beim Einlesen wieder als einzelnes Konzept erkannt werden. Ein Beispiel hierfür ist ein Datenbankobjekt. Modellseitig handelt es sich um eine einfache Klasse, die durch einen UML-Stereotyp als Entität qualifiziert ist. In Java stößt man für diese Klasse jedoch auf mehrere Repräsentationen. Zunächst gibt es neben der DO- auch drei weitere DTO-Klassen, mit entsprechenden Konstruktoren und Transformations-Factories. Auch innerhalb der DO-Klasse finden sich rein technisch motivierte Aspekte wieder: Neben den Annotationen an der Klasse selbst gibt es weitere Methoden wie tostring(), hashcode() und equals() sowie Factory-Methoden zum Erstellen der beiden DTOs. Diese Implementierungsdetails sind immer wiederkehrende Muster, die sich in allen DOs der Applikation wiederfinden. Durch Template-basiertes Reverse Engineering werden die Details als ein zusammenhängendes Konzept erkannt und modellseitig durch die einzelne Klasse mit Entitätsstereotyp repräsentiert ganz so, wie man es erwarten würde. Soll man also einen Implementierungsstil (hier JPA 1) in einen anderen (JPA 2) umwandeln, sind entsprechende Templates zu erstellen, sofern sie nicht im Lieferumfang von UML Lab enthalten sind. Nach dem Reverse Engineering wird dann im Modell für die betroffenen Elemente der Code-Stil geändert. Nach erneuter Generierung liegt der Quelltext anschließend gemäß dem neuen Implementierungsstil vor. Als Templatesprache verwendet UML Lab das aus dem Eclipse-Projekt M2T bekannte Xpand. Somit lassen sich auch Xpand-Templates für das Round-Trip Engineering verwenden. 4 von :10

5 Round-Trip-Engineering verwendet Templates (Mitte), um Modelle (links) mit beliebigen Text (rechts) zu synchronisieren. UML Lab liefert Templates für diverse Java-Implementierungsstile mit, eigene Stile und Templates sind einfach und flexibel anzulegen (Abb. 2). Die Aufgabe von Micromata war es nun, Xpand-Templates zu entwickeln, mit deren Hilfe UML Lab das Modell der zu überarbeitenden Software erstellt. Um im Anschluss Quelltext mit den für JPA 2 benötigten Implementierungsdetails zu generieren, erzeugten die Entwickler hierfür entsprechende Templates. UML an eigene Bedürfnisse anpassen Die UML (Unified Modeling Language) hat sich als Beschreibungssprache für die Softwareentwicklung etabliert. Um sie an eigene Bedürfnisse anzupassen, stehen sogenannte UML-Profile zur Verfügung. Damit lassen sich Konzepte der UML einschränken oder erweitern. Im konkreten Micromata-Projekt musste ein abstraktes Modell den mit JPA 1 konformen Quelltext repräsentieren. Hieraus sollte der JPA-2-konforme Quelltext generiert werden. Dazu war es erforderlich, die UML an Anforderungen aus der Datenbank-Mapping-Domäne anzupassen. Das erfolgte mit einem UML-Profil. Im Profil ist beispielsweise ein Stereotyp Entity definiert, der modellseitig eine Datenbank-Entität repräsentiert. Mit zusätzlichen Attributen wie entityname oder cacheable lassen sich auch weitere Details der Datenbankdomäne modellieren. Abbildung 3 zeigt einen Auszug aus dem resultierenden UML-Profil zur Modellierung der Datenbank-Entitäten. Ausschnitt aus dem finalen UML-Profil zur Modellierung der Datenbank-Entitäten. Die unterschiedlichen Stereotypen ergänzen das UML-Metamodell um domänenspezifische Eigenschaften. Außerdem kann man neue Metaklassen und Assoziationen nach Bedarf einfügen (im Ausschnitt die Klasse Override). Die Erstellung des Profils selbst erfolgt ebenfalls mit UML Lab (Abb. 3). 5 von :10

6 Fazit Durch den Techniksprung der modellgestützten Quelltextmigration ergeben sich neue Freiheiten in der Implementierung. Das betrifft zum Beispiel das Erstellen von Blueprints, da es nun möglich ist, die Software wahlweise zu modellieren oder zu programmieren, ohne dabei zwischen diesen beiden Entwicklungsmethoden einen Bruch oder einen aufwendigen manuellen Abgleich in Kauf nehmen zu müssen. Der Screenshot zeigt einen Ausschnitt des Datenmodells in UML Lab. Rechts sieht man einen Auszug des eingelesenen Quellcodes. Im Modell werden nur fachliche Informationen der Anwendungsdomäne repräsentiert. Die Abstraktion von Implementierungsdetails erfolgt durch die Templates. Es lässt sich wie gewohnt im Quelltext, aber auch im Modell weiterarbeiten (Abb. 4). In Fragen der Effizienz schneidet ein modellgetriebenes Softwareupgrade auch deshalb gut ab, weil das von UML Lab verwendete Template-basierte Round-Trip Engineering mühsame und zeitraubende Handarbeit durch den wechselseitigen automatischen Abgleich von altem und neuem Quelltext ersetzt. Durch das synchrone Arbeiten an zwei Entwicklungssträngen der Applikation kommt es zu keinen unnötigen Zeitverlusten. Trotzdem bleibt den Entwicklern mit UML Lab ihre gewohnte Entwicklungsdomäne ob Modellierung oder Programmierung erhalten. Darüber hinaus verändern sich Patterns und Best Practices, weil die Applikation im Gegensatz zu anderen Upgrade-Prozessen jetzt von den neuen Funktionen der verbesserten Komponentenversion, hier JPA 2, profitieren kann. Denn dank seiner Transformationsregeln berücksichtigen die entwickelten Templates diese neuen Features bei der Konvertierung mit den daraus resultierenden Möglichkeiten. Dem "natürlichen" Alterungsprozess einer Software wird damit erfolgreich entgegengewirkt. (ane) Marco Sebastiao ist freier Softwareentwickler und hat sich im Rahmen seiner Tätigkeit für die Micromata GmbH mit dem hier beschriebenen Round-Trip Engineering befasst. Als Doktorand an der Universität Kassel beschäftigt er sich mit Compilerbau und ausfallsicheren Betriebssystemen. URL dieses Artikels: 6 von :10

7 Links in diesem Artikel: [1] Copyright 2012 Heise Zeitschriften Verlag Content Management by InterRed International: The H, The H Security, The H Open Source 7 von :10