|
Unter Anwendungsmigration versteht man eine grundsätzliche Umgestaltung der Anwendung im Sinne der Nutzung neuer Technologien, bei der die Anwendung zumindest im Kern noch erhalten bleibt. Von Interesse sind dabei erst einmal hauptsächlich die Dialoganwendungen.
Das Aufsetzen neuer Benutzeroberflächen durch eine “GUIfizierung” oder sogar die Transformation der Oberfläche in eine Web-Anwendung mit Java Server Pages mittels WebFacing Tool gilt “nur” als Refacing, obwohl mit diesem eine echte Client/Server-Anwendung entsteht. Bei dieser wird der 5250-Datenstrom abgegriffen und dann aus Java Server Pages als HTML-Anzeigen über das Web gesendet.
Die Grenze zur Migration wird dann überschritten, wenn neue Komponenten hinzu kommen oder in die Anwendung eingegriffen wird. Obwohl die Grenzen manchmal fließend sind, spricht man von Anwendungsmigration, wenn mindestens eine der folgenden Umgestaltungen vorgenommen wird.
- neue Komponenten in “modernen” Programmiersprachen (i. A. Java)
- Neuer Quellkode wie bei einer neuerdings möglichen Kode-Umetzung von RPG nach EGL
- Aufteilung in Client- und Server-Komponenten
- Transformation in “echte” Web-Anwendung mit Java Servlets, Java Server Pages und/oder Enterprise Java Beans.
- Portierbarkeit zumindest von Teilen der Anwendung
Die Migration bewahrt meist den Kern der Business Logik. Das bedeutet dann eine mehr oder weniger konsequente Umgestaltung der Anwendung nach folgendem Prinzip:
- Die primäre Sprache wird Java oder EGL als Makro-Sprache über Java. Alter 3GL-Code wird mit Java gekapselt, was durch die IBM Toolbox für Java unterstützt wird.
- Der Client-Teil besteht aus einer Java GUI (Rich Client) oder Browser-Anzeige von Java Server Pages (Thin Client), wobei Letzteres sich in der letzten Zeit durch die Rich Internet Applications Technologien in puncto Komfort sich dem Rich Client angenähert haben.
- Der Rest der Anwendung läuft unter Steuerung von Servern ab:
- Im einfachsten Fall ist das ein Programm oder Service-Programm der nativen Anwendung unter Hostserver-Steuerung.
- Bei einer Web-Anwendung läuft die Anwendungssteuerung in einem Servlet, das von einem Application Server gehostet wird. Die Business Logik ist gekapselt in einer Java Bean (läuft innerhalb des Servlets) oder separat als EJB in einem EJB-Container eines (möglicherweise anderen) Application Servers.
- Bei einer EJB-Anwendung kommuniziert der Java Client direkt mit der EJB über den Application Server.
- Die Datenbank, sofern der Zugriff via JDBC erfolgt, läuft auch wieder unter Steuerung eines Datenbank-Servers.
- Die Business Logik bleibt erhalten, die Logik wird in Modulen (nicht unbedingt im Sinne von ILE), die parallel ausführbar sein müssen, neu “verpackt”.
- Der Aufruf dieser Module erfolgt aus einer völlig neugestalteten Controller-Ebene (entspricht der Logik um das ehemalige Hauptmenü).
- Je nach Typ der Anwendung - Java Servlet/JSP oder Java GUI Client - sind dann die entsprechenden Designpattern umzusetzen.
- Wenn möglich oder sinnvoll, werden die nativen DB-Zugriffe durch SQL-Zugriffe ersetzt.
- Die Oberflächen werden völlig neu entwickelt. Bei einem Java GUI Client geschieht dies mit Java GUI-Tools oder fortschrittlicherweise XML-basiert. Für JSP gibt es den Page Designer von der WebSphere Tools, der das Layout einschließlich Java Tags und beschränkt auch JavaScript für die GUI-Logik unterstützt.
Die IBM bietet Ihnen unter dem Markennamen WebSphere Java/XML-basierte Techologien und Produkte an, die eine auf die Gegebenheiten Ihres Unternehmens angepasste Migration der Anwendung unterstützen. Dabei werden nur dort zusätzliche maschinelle Ressourcen verbraucht, wo es neue Funktionen der Anwendung erfordern.
Mit etwas Geschick lässt sich meist diese Migration in einen kontinuierlichen Prozess einbetten, so dass gleitend eine Komponente nach der anderen migriert oder ersetzt wird oder auch neue Komponenten hinzu kommen.
UBHartung erarbeitet mit Ihnen zusammen das Konzept für den Migrationsprozess und die Migration der Komponenten sowie führt die Migration, z. B. zusammen mit Ihren Entwicklern, durch.
|