Migration - Java EE Applikationen, von Oracle WebLogic nach Apache Tomcat
Im Laufe der Jahre wurden für unsere Kunden aus der Pharmabranche neben Großprojekten auch viele kleine und mittlere Java EE Anwendungen umgesetzt. Diese werden produktiv mit komplexen WebLogic Server-Clustern betrieben.
Dieser Blogpost beschäftigt sich mit einigen Problematiken in der genannten Situation, den Anforderungen und mit der technischen Umsetzung.
Problematik und der Wunsch nach einem Plattformumzug
Im Vergleich zu Apache Tomcat ist Oracle WebLogic ein Applikationsserver mit einem großen Funktionsumfang und hohem Konfigurationsaufwand. Insbesondere für kleine und mittlere Applikationen sind die beiden folgenden wirtschaftlichen Faktoren interessant:
- Lizenzkosten: Während bei WebLogic Servern Lizenzkosten für Development-, QA-, Test- und Produktionsumgebung zu zahlen sind, ist Tomcat ein Open-Source Produkt und damit überall kostenfrei verfügbar.
- Wartungsaufwände: Das Deployment, die Bereitstellung und Zuweisung von System-Ressourcen und die Vorgehensweise bei der Konfiguration ist bei WebLogic in der Regel umfangreicher, aber gleichzeitig auch komplexer und zeitintensiver als bei Tomcat.
Für unsere Kunden waren wir die Problemstellungen angegangen und haben dabei für jedes einzelne Projekt die Machbarkeit eines Umzuges geprüft, Lösungsvarianten bewertet und ggf. umgesetzt.
Anforderungen
Die wohl größte Anforderung an die Migration waren WebLogic-Container spezifische Implementierungen und Konfigurationen. Während die Konfigurationen mit überschaubaren Aufwänden angepasst werden konnten, mussten für die Container-spezifischen Implementierungen einige Code-Änderungen eingebaut werden.
Eine Anwendung ist auch dann nur Bedingt für eine Migration geeignet, falls sie z.B. EJBs verwendet. Tomcat selbst ist ein schlanker Servlet-Container ohne EJB-Unterstützung. Damit EJBs auch unter Tomcat funktionieren, muss mindestens eine weitere Komponente, wie Apache TomEE, aufgesetzt werden.
Technische Umsetzung
Der IIS Server nimmt die Requests entgegen und leitet die Informationen über den aktuell angemeldeten Windows-User an den Servlet-Container weiter. Falls diese Informationen aus irgendeinem Grund nicht weitergeleitet werden können, so wird der Nutzer auf eine Login-Seite weitergeleitet. Dort kann er sich mit seinem vertrauten Windows-Login und Passwort anmelden.
Damit der geschilderte Vorgang auch unter Tomcat funktioniert, müssen in den Anwendungen vorhandene Implementierungen überarbeitet. Dazu gehören z.B. die Erweiterung des Spring Security Moduls mit Anbindung des Windows Active Directory Services.
Die WebLogic Login API für die Authentifizierung mit Login/Password wurde ebenfalls durch äquivalente Funktionen mit Spring Security ersetzt.
Des Weiteren müssen auf die Unterschiede in der Bereitstellung des JDBC-Treibers und Java Mail Abhängigkeiten beachtet werden. So dürfen Anwendungen, die eine Tomcat Mail-Session verwenden, keine mail.jar und activation.jar im Verzeichnis WEB-INF/lib enthalten. Stattdessen sollten die Bibliotheken in das Verzeichnis $CATALINA_HOME/lib kopiert werden.
Fazit
Auch wenn die zu migrierenden Anwendungen einige Container-spezifische Abhängigkeiten enthalten, kann es unter Umständen Sinn machen, eine Anpassung (nicht nur Migration) durchzuführen.
Die Kunden sparen nicht nur Betriebskosten durch entfallende Lizenzkosten. Durch einheitliche, projektübergreifende Konfigurationen und Deploymentprozesse lassen sich auch Synergieeffekte erzielen. Auch die größere Unabhängigkeit von einem einzelnen Plattform-Hersteller kann als Vorteil gewertet werden.