DEFREN

Login und Suche



CH Open Sponsoren

snowflake productions gmbh - /ch/open-Sponsor
Erfahrungsbericht einer Java EE Migration

Erfah­rungs­be­richt einer Java EE Migration

von Domi­nic Brüg­ger | 05.11.2013

Für einen Kun­den durfte Puz­zle ITC eine Java Anwen­dung auf JBoss EAP 6 por­tie­ren. Domi­nic Brüg­ger zeigt im fol­gen­den Bei­trag auf, wie die Appli­ka­tion schritt­weise von Drittanbieter-​Bibliotheken gelöst und zu einer Stan­dard Java EE 6 Anwen­dung migriert wird.

Zu Beginn stellt sich die Frage, ob eine sol­che Migra­tion sinn­voll und wirt­schaft­lich ist. Die Ant­wort hängt von den Rah­men­be­din­gun­gen des Pro­jek­tes ab und kann nicht gene­rell auf andere Fälle über­tra­gen wer­den. In unse­rem Fall haben zwei wesent­li­che Fak­to­ren die Ent­schei­dung für eine Migra­tion begünstigt:

1.) Der Auf­trag­ge­ber hat sich stra­te­gisch für JBoss EAP 6 als Platt­form für Java Geschäfts­ap­pli­ka­tio­nen ent­schie­den. Bereits sind meh­rere Anwen­dun­gen auf die­ser Umge­bung pro­duk­tiv im Ein­satz. Mit der Migra­tion wird die Soft­ware Archi­tek­tur und das Deploy­ment an die beste­hen­den Anwen­dun­gen ange­gli­chen. Mit­tel­fris­tig ver­spricht man sich dadurch eine Reduk­tion der Betriebs– und Wartungskosten.

2.) Mit der Migra­tion wer­den gleich­zei­tig Ver­bes­se­run­gen an der Soft­ware­ar­chi­tek­tur umge­setzt. Die­ses Thema wer­den wir im nächs­ten Abschnitt erörtern.

Ver­ein­fa­chend kommt hinzu, dass das Benut­zer­in­ter­face aus einem Swing Thin Cli­ent besteht und somit von der Migra­tion aus­ge­schlos­sen wer­den kann. Die Umset­zung der Migra­tion haben wir schliess­lich in drei auf­ein­an­der auf­bau­en­den Schrit­ten geplant. Diese Stra­te­gie stellt sicher, dass die Appli­ka­tion zu jedem Zeit­punkt lauf­fä­hig bleibt und die ein­zel­nen Schritte iso­liert getes­tet wer­den können.

1. Schritt: Anpas­sen der Architektur

Im ers­ten Migra­ti­ons­schritt pas­sen wir die beste­hende Appli­ka­tion so an, dass sie opti­mal auf einem Java EE 6 Con­tai­ner deployed wer­den kann. Aus­gangs­lage ist eine Soft­ware­ar­chi­tek­tur beste­hend aus einem Thin Cli­ent, einem Schnitt­stel­len­mo­dul und einem Ser­ver­mo­dul. Das Schnitt­stel­len­mo­dul stellt dem Thin Cli­ent eine REST-​Schnittstelle zur Ver­fü­gung. Die Aus­füh­rung der eigent­li­chen Geschäfts­lo­gik wird über eine RMI-​Schnittstelle an das Ser­ver­mo­dul dele­giert. Das Deploy­ment der Schnitt­stel­len­schicht auf einem dedi­zier­ten Ser­ver bringt weder tech­ni­sche noch fach­li­che Vor­teile und wird bei der neuen Archi­tek­tur weg­ge­las­sen. Die REST– Schnitt­stelle inte­grie­ren wir in das Ser­ver­mo­dul und erset­zen die RMI-​Schnittstelle durch direkte Service-​Aufrufe. Das zuvor als Stan­da­lone Java-​Anwendung kon­zi­pierte Ser­ver­mo­dul packen wir neu als WAR-​Datei.

Mit dem Zusam­men­le­gen der ser­ver­sei­ti­gen Module über­ar­bei­ten wir eben­falls das Kon­fi­gu­ra­ti­ons­ma­nage­ment. Die gesamte Appli­ka­tion wird neu auf dem App­li­ca­ti­on­ser­ver durch Sys­tem Pro­per­ties kon­fi­gu­riert. Gegen­über den bis­he­ri­gen ver­teil­ten Kon­fi­gu­ra­ti­ons­da­teien ist dies ein wesent­li­cher Vorteil.

Nach dem ers­ten Migra­ti­ons­schritt kann die Appli­ka­tion bereits auf JBoss EAP 6 aus­ge­führt und getes­tet wer­den. Die Geschäfts­kom­po­nen­ten basie­ren jedoch wei­ter­hin auf dem alten Tech­no­lo­gie­stack und schöp­fen das Poten­tial des App­li­ca­ti­on­ser­vers nicht aus. Als nächs­ten Migra­ti­ons­schritt wer­den wir des­halb die Per­sis­tenz­schicht auf den JPA Stan­dard migrieren.

2. Schritt: Migra­tion Persistenzschicht

In der beste­hen­den Appli­ka­tion ist der Daten­zu­griff mit Kodo JDO umge­setzt. Im zwei­ten Migra­ti­ons­schritt lösen wir die­ses pro­prie­täre objekt­re­la­tio­nale Frame­work durch den JPA Stan­dard ab und kön­nen somit den Per­sis­tenz­dienst vom Java EE Con­tai­ner nutzen.

Als Ers­tes müs­sen wir die Map­ping­de­fi­ni­tio­nen umschrei­ben, das heisst die Defi­ni­tio­nen aus den Kodo Kon­fi­gu­ra­ti­ons­da­teien als JPA Anno­ta­tio­nen abbil­den. Das stellt sich als grös­sere Her­aus­for­de­rung dar, da die Map­pings kom­plex sind und das beste­hende Daten­bank­de­sign nicht immer opti­mal für JPA aus­ge­legt ist. Nach den Mapping-​definitionen migrie­ren wir sämt­li­che Abfra­gen. Kodo Que­ries schrei­ben wir zu JPQL Que­ries um. Ein gros­ser Teil der Abfra­gen besteht aus nati­ven SQL Que­ries, wel­che mit weni­gen Anpas­sun­gen über­nom­men wer­den kön­nen. Das Tes­ting und das anschlies­send nötige Per­for­mance­tu­ning ent­pup­pen sich als weit­aus gröss­ter Auf­wand. Es muss auf jeden Fall sicher­ge­stellt wer­den, dass sich das Lauf­zeit­ver­hal­ten der Appli­ka­tion nicht verändert.

Nach die­sem Umbau ver­wen­den wir mit JPA das Per­sis­tenz­frame­work des Application-​servers. Die JPA Enti­ty­Ma­na­ger­Fac­tory und die Trans­ak­tio­nen wer­den aber immer noch vom Spring Frame­work und nicht vom Con­tai­ner ver­wal­tet. Diese Bau­stelle gehen wir im nächs­ten und letz­ten Migra­ti­ons­schritt an.

3. Schritt: Spring durch EJB und CDI ersetzen

Die beste­hende Anwen­dung ver­wen­det das Spring Frame­work für Depen­dency Injec­tion und Trans­ak­ti­ons­ma­nage­ment. Im letz­ten Migra­ti­ons­schritt lösen wir Spring Beans und Aspekte durch das Java EE Kom­po­nen­ten­mo­dell ab. Das geht rela­tiv gerad­li­nig von­stat­ten, indem wir Spring Beans ent­we­der durch Sta­te­l­ess Ses­sion Beans oder durch CDI Beans erset­zen. Grob gesagt wer­den jene Beans, die mit dem Spring Trans­ak­ti­ons­as­pekt aus­ge­stat­tet waren, zu Ses­sion Beans migriert.

Diese sind als EJBs stan­dard­mäs­sig trans­ak­tio­nal (Con­tai­ner Mana­ged Tran­sac­tion). Alle ande­ren Spring Beans erset­zen wir durch CDI Beans. Bei die­ser Arbeit tau­chen als ein­zige kleine Über­ra­schung zir­ku­läre Abhän­gig­kei­ten zwi­schen Spring Beans auf. Spring scheint in die­sem Fall tole­ran­ter zu sein als der Java EE Con­tai­ner, wes­halb diese Zyklen noch berei­nigt wer­den müssen.

Erfreu­li­cher­weise kön­nen einige Hin­ter­grund­tasks, wel­che zuvor auf Spring Sche­du­ling und Quartz basier­ten, sehr ein­fach mit dem EJB Timer Ser­vice umge­setzt wer­den. Ein Vor­teil dabei ist, dass die Task Thre­ads vom App­li­ca­ti­on­ser­ver ver­wal­tet wer­den und sich somit bes­ser kon­trol­lie­ren und über­wa­chen las­sen. Am Ende die­ses Migrations-​schrittes kann das Spring Frame­work ent­fernt wer­den. Die Ser­ver­seite der Anwen­dung basiert nun voll­stän­dig auf Java EE Standardtechnologien.

Eine Erfolgs­ge­schichte

Im Gros­sen und Gan­zen dür­fen wir mit dem Resul­tat zufrie­den sein. Die meis­ten Migra­ti­ons­schritte konn­ten zügig und ohne Über­ra­schun­gen umge­setzt wer­den. Die grösste Her­aus­for­de­rung war die Migra­tion der Per­sis­tenz­schicht. Das JPA-​Mapping für das beste­hende Daten­bank­mo­dell zu defi­nie­ren war schwie­ri­ger als erwar­tet. Als wesent­li­che Ver­bes­se­rung sehen wir das Deploy­ment und die Kon­fi­gu­ra­tion der Anwen­dung. Zuvor war dies ein feh­ler­an­fäl­li­ger Pro­zess mit einem Instal­ler­pro­gramm, wel­cher auf meh­re­ren Ser­vern aus­ge­führt wer­den musste. Neu lie­fern wir dem Betrieb eine WAR-​Datei und ein doku­men­tier­tes Set von Sys­tem Pro­per­ties. Um die Ver­tei­lung der Appli­ka­tion küm­mert sich JBoss EAP 6.

Durch die Ver­wen­dung von Stan­dards gewäh­ren wir unse­rem Kun­den einen hohen Inves­ti­ti­ons­schutz. Java EE ist die bewährte Platt­form für kom­plexe Geschäftsanwendungen.


her­un­ter­la­den (PDF 182.8 KB)


Weiterführende Informationen aus dem OSS Directory

Puzzle ITC GmbH

puzzle.ch | 100 Mitarbeitende | 12 Referenzen | 1 Produkt


Puzzle ITC ist spezialisiert auf interdisziplinäre Lösungen vom Betriebssystem bis zur Anwendung für Endbenutzer, zugeschnitten auf Ihre Bedürfnisse.
Im Jahr 1999 als Software- und T...

» Mehr
Letzte Aktualisierung: 06.04.2018  -  Anzahl Ansichten seit dem 01. April 2013: 1551
Erstellt: 29.09.2012

Java (Programming language)

Software-Entwicklung / Programmiersprachen
19 Firmen, 28 Referenzen


Die Programiersprache Java ist eine objektorientierte Programmiersprache und eine eingetragene Marke des Unternehmens Sun Microsystems (2010 von Oracle aufgekauft). Die Programmiersprache ist ...

» Mehr
Letzte Aktualisierung: 30.11.2016  -  Anzahl Ansichten seit dem 01. April 2013: 206
Erstellt: 25.09.2012

Mitgliedschaft bei /ch/open

Der Vorstand der /ch/open wird jährlich an der Mitgliederversammlung gewählt und arbeitet vorwiegend ehrenamtlich. Werden Sie Mitglied des Vereins /ch/open und unterstützen Sie die Förderung von Open Source Software in der Schweiz.

Einzelmitgliedschaft
Für alle, die persönlich die Anliegen und Aktivitäten von /ch/open unterstützen und kostenlos an Abendveranstaltungen und am Open Business Lunch teilnehmen möchten.
CHF 100.– pro Jahr

Einzelmitgliedschaft für Personen in Ausbildung
Personen in Ausbildung erhalten eine Ermässigung des Mitgliederbeitrags.
CHF 20.– pro Jahr

Kollektivmitgliedschaft
Für Unternehmen, öffentliche Verwaltung, Schulen und andere juristische Personen: Alle Mitarbeiter solcher Organisationen geniessen die gleichen Möglichkeiten und Vergünstigungen wie Einzelmitglieder. Eine definierte Kontaktperson erhält alle Korrespondenz.
CHF 450.– pro Jahr

Sponsormitgliedschaft
Für Mitglieder, welche die Anliegen der /ch/open besonders unterstützen möchten: Sponsormitglieder können Anfang Jahr am /ch/open Sponsoren-Dinner teilnehmen, werden auf der /ch/open Website und dem Portal www.opensource.ch mit Logo aufgeführt, in allen Mailings namentlich mit Link erwähnt und können beliebig viele Projekte und Referenzen im OSS Directory verlinken.
CHF 1000.– pro Jahr

Die Anmeldung für die Mitgliedschaft, die Vereinsstatuten sowie viele weitere Informationen sind auf der Website zu finden:
http://www.ch-open.ch/anmeldeformular_mitgliedschaft/

Twitter Feed







Links

Über unsNewsletterKontaktNutzungsbedingungenCH Open Initiativen