Entwicklung einer Strategie zur Migration einer Anwendung von.net nach Java

Transkript

1 Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Softwaretechnik Warburgerstr Paderborn Entwicklung einer Strategie zur Migration einer Anwendung von.net nach Java Bachelorarbeit zur Erlangung des Grades Bachelor of Computer Science für den Studiengang Informatik von David Beisel Am Asterstein Koblenz vorgelegt bei Prof. Dr. Wilhelm Schäfer und Prof. Dr. Johannes Blömer Paderborn, den 19. Oktober 2007

2 ii

3 Ehrenwörtliche Erklärung Hiermit versichere ich, die vorliegende Arbeit ohne Hilfe Dritter und nur mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus den Quellen entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen. Paderborn, den 19. Oktober 2007 David Beisel iii

4 iv

5 Danksagung An dieser Stelle danke ich allen, die mich bei und während der Erstellung meiner Bachelorarbeit unterstützt haben. Besonders danken möchte ich meinen Betreuern, Dietrich Travkin von der Universität Paderborn, und Karsten Priemer von der Siemens AG, die mir beide jederzeit (sogar im Urlaub) mit Rat und Tat zur Seite standen und für mich die wichtigsten Ansprechpartner bei der Erstellung dieser Bachelorarbeit waren. Schließlich danke ich Helmut Beck, Elisabeth Wagner sowie meinen Eltern Barbara und Götz Beisel für ihre große und schnelle Hilfe beim Korrekturlesen. v

6 vi

7 Inhaltsverzeichnis 1 Einleitung Motivation Ziel dieser Arbeit Struktur dieser Arbeit Grundlagen Begriffsabgrenzung Praktische Grundlage der Arbeit Inhalt des Kundenauftrages ESRI ArcGIS Anforderungen an die Migration der ArcGIS-Erweiterung Migrationsstrategien Kriterien zur Bewertung von Migrationsstrategien Migrationsaufwand Wartungsaufwand Effizienz der migrierten Anwendung Plattformunabhängigkeit Erhalt der Benutzerschnittstelle Strategie Cross Compiler Ansatz Umsetzung Erfüllung der Kriterien Weitere positive und negative Aspekte Fallstudie aus der Praxis Strategie Cross Plattform Ansatz Umsetzung Erfüllung der Kriterien Weitere positive und negative Aspekte Fallstudie aus der Praxis Strategie Schnittstellen Ansatz Umsetzung Erfüllung der Kriterien vii

8 Inhaltsverzeichnis Weitere positive und negative Aspekte Strategie Manuelle Migration Ansatz Umsetzung Erfüllung der Kriterien Weitere positive und negative Aspekte Entscheidungsprozess Analyse der Strategien Rahmenbedingungen der Strategien Bewertung der Strategien Allgemeine Vorgehensweise Praktische Anwendung des Entscheidungsprozesses Verwandte Arbeiten 59 6 Zusammenfassung und Ausblick Zusammenfassung Ausblick A Praxiserfahrungen bei der Anwendung von Migrationswerkzeugen 63 A.1 Proxygen A.2 Mainsoft for UNIX And Linux A.3 Mainsoft for Java EE Literaturverzeichnis 69 Abbildungsverzeichnis 73 viii

9 1 Einleitung Softwareentwurf gestaltet sich im Allgemeinen als aufwendiger Prozess. Lange Entwicklungsprozesse sind dabei mit großen Investitionen verbunden, weswegen versucht wird, den Entwicklungsaufwand zu minimieren. Aufgrund der hohen Entwicklungskosten wird Software über mehrere Jahre gepflegt und erweitert. Da Wartungsaufwand über die Nutzungsjahre der Software oft mehr Kosten hervorruft als die ursprünglichen Entwicklungskosten, ist es wichtig, die Entwurfsentscheidungen so zu treffen, dass auch die Wartungskosten minimiert werden. Aus unterschiedlichen Gründen kann der Bedarf entstehen, eine entwickelte Software in einer neuen Soft- oder Hardware-Umgebung zu nutzen, z.b. aufgrund strategischer Entscheidungen eines Unternehmens, um mehr Kunden zu erreichen. Dies würde eine Migration der ursprünglichen Software auf die neue Umgebung notwendig machen. 1.1 Motivation Ein Kundenauftrag bei dem in dieser Arbeit kooperierenden Unternehmen Siemens IT Solutions diente als Motivation zum Thema dieser Arbeit. Der Kunde nutzt eine auf Basis des Microsoft.NET-Frameworks implementierte Softwarekomponente auf einem Windows-Rechner. Diese Softwarekomponente soll nun zusätzlich auf einem Rechner mit einem Solaris-Betriebssystem ausgeführt werden können. Dabei ist die Zielarchitektur, die durch die Solaris-Umgebung festgelegt ist, eine nicht änderbare Anforderung des Kunden. Das Solaris-Betriebssystem basiert auf UNIX. Die Bibliotheken des.net- Frameworks sind bisher nicht unter UNIX-Systemen nutzbar. Es muss also eine Möglichkeit gefunden werden, die von.net-bibliotheken abhängige Softwarekomponente auf ein Solaris-System zu migrieren. Eine weit verbreitete und weitestgehend plattformunabhängige Programmiersprache ist Java (insbesondere Solaris wird unterstützt). Die Software, innerhalb der die zu migrierende Softwarekomponente auf dem Zielrechner genutzt werden soll, ist in Java programmiert. Es ist also notwendig, die auf Basis des.net- Frameworks entwickelte Softewarekomponente in einer Java-Umgebung nutzen zu 1

10 1 Einleitung können. Genauere Inhalte des Kundenauftrags werden in Abschnitt 2.2 Praktische Grundlage beschrieben. Es ergibt sich die Problemstellung, dass zum einen keine Anwendungen, die in einer der im.net-framework verwendeten Programmiersprachen (z.b. C#, C++, Visual Basic) implementiert wurde, aus Java heraus aufgerufen werden kann. Zum anderen werden keine oder nur unvollständige.net-bibliotheken für UNIX- Plattformen - wie Solaris - angeboten, was die Ausführung einer.net-anwendung auf UNIX-Plattformen erschwert. 1.2 Ziel dieser Arbeit Im Rahmen dieser Arbeit besteht das Hauptziel darin, Verfahren zu finden oder Ideen zu entwickeln, die eine Nutzung von.net-basierender Software in einer Java-Umgebung und ihre Weiterentwicklung ermöglichen. Dabei sollen Werkzeuge vorgestellt werden, die eine Migration ermöglichen und automatisieren. Es sollen verschiedene Migrationsansätze vorgestellt und anhand eines Kriterienkatalogs beurteilt werden. Durch eine Analyse sollen Stärken und Schwächen der Verfahren herausgestellt werden und ihre Einschränkungen verdeutlicht werden. Auf Basis der gewonnenen Erkenntnisse soll ein möglichst allgemein anwendbarer Entscheidungsprozess beschrieben werden, der dabei helfen soll, die bestmögliche Strategie für eine gegebene Problemstellung (bestimmt durch Quell-, Zielplattform, Rahmenbedingungen und Anforderungen) zu finden. Dadurch soll es einem Entwickler mit Migrationsaufgabe vereinfacht werden, auf schnelle Art und Weise eine geeignete Strategie für sein individuelles Migrationsszenario zu finden. Da diese Arbeit in Kooperation mit der Siemens AG erstellt wird, ist es ein zusätzliches Ziel, dass alle Darstellungen und Erkenntnisse dieser Arbeit sowohl die Anforderungen von Seiten der Siemens AG erfüllen als auch möglichst allgemein anwendbar sind. 1.3 Struktur dieser Arbeit Nach dem Einleitungskapitel werden in Kapitel 2 die Grundlagen der Thematik vorgestellt und erläutert. In Kapitel 3 werden unterschiedliche Verfahren vorgestellt und beurteilt, die eine Migration einer Anwendung von.net nach Java ermöglichen. Zu diesem Zweck wird ein Kriterienkatalog eingeführt und beschrieben, auf dessen Basis die Migrationsverfahren bewertet werden. Im darauf folgenden Kapitel 4 werden die Verfahren und zugehörige Werkzeuge genauer in übersichlicher Form analysiert, um dann einen Prozess zu beschreiben, der die Wahl eines geeigneten Migrationsverfahrens für eine gegebene Problemstellung ermöglicht. Anschließend wird am Beispiel des Auftrags der Siemens AG eine Wahl für ein 2

11 1.3 Struktur dieser Arbeit Migrationsverfahren getroffen. In Kapitel 5 werden verwandte Arbeiten vorgestellt. Das abschließende Kapitel 6 bietet eine Zusammenfassung der Arbeit und einen Ausblick, welche Punkte noch offen geblieben sind und an welchen Stellen weiter geforscht werden könnte. Im Anhang der Arbeit werden praktischen Erfahrungen bei der Anwendung von Migrationswerkzeugen genannt. Aufgrund der Komplexität der Werkzeuge sowie diverser Schwierigkeiten bei ihrer Installtion und Anwendung konnte keine beispielhafte Migration einer Software vollständig durchgeführt werden. Im Anhang werden diese Probleme erläutert. 3

12 1 Einleitung 4

13 2 Grundlagen In diesem Kapitel werden Grundlagen vermittelt, die für das korrekte Verständnis der gesamten Arbeit wichtig sind. Im ersten Unterkapitel 2.1 findet eine Definition und Abgrenzung von Begriffen statt, die im Zusammenhang mit der Migration stehen. Im zweiten Unterkapitel 2.2 wird die praktische Grundlage dieser Arbeit, auf Basis des Siemens Kundenauftrags, vermittelt. Darin wird der konkrete Auftrag beschrieben und die für die Migration vorgesehene Software vorgestellt. Außerdem werden die genauen Anforderungen dieses Kundenauftrags an die Migration erläutert. 2.1 Begriffsabgrenzung Im Folgenden wird der Begriff der Migration erläutert und von den verwandten Begriffen Portierung und Integration abgegrenzt. In der Fachliteratur, z.b. Lexika der Informatik, sind diese Begriffe nur sehr kurz oder gar nicht erwähnt, zum Teil auch in unterschiedlicher Auslegung. Die folgenden Erläuterungen geben deshalb wieder, was innerhalb dieser Arbeit und im Arbeitsumfeld der kooperierenden Siemensabteilung unter den Begriffen verstanden wird. Migration Der Begriff der Migration leitet sich von dem lateinischen Nomen migratio ab und bedeutet wörtlich übersetzt (Aus)Wanderung [Kra07]. Migration im Sinne der Informatik wird laut dem Computer-Fachlexikon [Mic00] wie folgt definiert: Der Entwicklungsprozess für vorhandene Anwendungen und Daten, so dass diese auf einem anderen Computer- oder Betriebssystem ausgeführt werden können. Ebenfalls kann der Hardware-Umstieg von einer alten Technologiekomponente zu einer neuen, unter Beibehaltung des umgebenden Systems, als Migration verstanden werden (vgl. [Wik]). In der Informatik gibt es drei Arten der Migration (vgl. [Jee05], [Wik]), die je nach Art und Umfang des Problems angewendet und häufig kombiniert werden: 5

14 2 Grundlagen Datenmigration: Die Migration von Daten kann sowohl die Dateiformate als auch die internen Strukturen (Schemata, formale Beschreibung der Struktur) betreffen. Im ersten Fall spricht man bei der Migration auch von Konvertierung, im zweiten Fall müssen die internen Strukturen manuell migriert werden oder es ist eine Form von Schema-Matching notwendig (vgl. [Wik]). Schema-Matching ist eine automatisierte Methode, inhaltliche Zusammenhänge zwischen zwei Schemata zu finden und in Beziehung zu setzen. Durch die Identifikation der Zusammenhänge können dann die internen Strukturen in eine neue Form migriert werden. Dabei ändern sich die beinhalteten Daten nicht, es ändert sich nur die Struktur. Bei der Konvertierung werden die Daten selber migriert, indem sie in ein neues Format gebracht werden. Ein Beispiel für die Konvertierung wäre eine Umwandlung einer Tabelle in einer xls-datei (Microsoft Excel) zu einem Text in einer CSV-Datei (Comma Separated Values). Hardwaremigration: Die Migration der Hardware bedeutet den Wechsel einer oder mehrerer Hardwarekomponenten unter Beibehaltung des umgebenden Systems der Komponenten (vgl. [Wik]). Die Migration eines Systems auf neue Hardware ist durch den meist notwendigen Wechsel von Treibern auch mit einer gewissen Softwaremigration verbunden. Ein einfaches Beispiel für Hardwaremigration wäre der Wechsel eines Mainboards in einem beliebigen Rechner unter Beibehaltung der restlichen Hardwarekomponenten des Rechners (Festplatte, Prozessor, etc.). Softwaremigration: Die Migration von Software bedeutet einen Umstieg von einer Software zu einer Neuen. Dabei geht die Migration über ein einfaches Update hinaus und bezeichnet vielmehr einen Wechsel der Software-Infrastruktur (vgl. [Wik]). Die Anwendung kann auch an eine neue Umgebung angepasst werden, indem die Programmiersprache, in der die Anwendung implementiert wurde, gewechselt wird (zum Beispiel von Visual Basic nach C++). Der Aufwand einer solchen Migration ist eng gekoppelt mit dem Umfang der Software und dem Ähnlichkeitsgrad zwischen alter und neuer Software. Ein kurzes Beispiel für eine Softwaremigration: Wir nehmen an, es existiere ein Programmmodul in C++ und eine Anwendung, die in Java programmiert wurde. Jetzt soll dieses C++-Programmmodul in der Java-Anwendung nutzbar sein. Eine Umwandlung des C++-Quellcodes in Java-Zielcode, so dass die Java- Anwendung das umgewandelte Programmmodul nutzen kann, wäre eine Migration. 6

15 2.1 Begriffsabgrenzung Im Zuge dieser Arbeit wird der Schwerpunkt auf der Softwaremigration liegen. Dabei wird, ähnlich dem vorherigen Beispiel, kein Umstieg von einer Software zu einer vollkommen neuen betrachtet, sondern der Wechsel einer Programmierumgebung hinter einer Anwendung. Die Arbeit betrachtet also nur einen Teil der Vielzahl von Migrationsszenarien in der Informatik. Auf weitere Szenarien wird im Kapitel Verwandte Arbeiten hingewiesen. Im weiteren Verlauf dieser Arbeit wird der Begriff Migration immer für die Softwaremigration stehen. Portierung Die Portierung wird von Fachleuten oft in einem Atemzug mit der Migration verwendet, ohne einen Unterschied zwischen Portierung und Migration zu formulieren. In dem Buch Java EE and.net Interoperability [FLSM06] heißt es z.b. in einem Auszug [... ]want to size and price what it would take to migrate their existing.net application to Java EE. As such, the focus of this chapter is to look at how to port existing.net applications to Java,[... ] [Seite 557 und 558]. Laut dem Computer-Fachlexikon [Mic00] ist die Portierung wie folgt definiert: Der Vorgang, bei dem ein in einer bestimmten Programmiersprache formuliertes Programm in eine andere Programmiersprache übersetzt wird. Die Definition des Verbs portieren zeigt noch mehr die Ähnlichkeit zur Migration: In der Programmierung die Anpassung eines Programms, damit es auf anderen Computersystemen lauffähig ist. [Mic00] Die Migration kann, wenn man die Definitionen der Portierung und Migration vergleicht, als allgemeinerer Begriff verstanden werden. Die Portierung beschäftigt sich ausschließlich mit Anwendungen (Softwaremigration), wobei der Begriff der Migration auch Daten- und Hardwarewechsel betreffen kann. In dieser Arbeit werden die Begriffe Migration und Portierung synonym verwendet. Integration Die Integration lässt sich wie folgt definieren: Die Zusammenfassung von unterschiedlichen Programmkomponenten zu einer funktionierenden Einheit. [Mic00] Man schafft also aus einzelnen Teilen ein Ganzes (Integration: lat. integratio zu Deutsch Herstellung eines Ganzen [Kra07]). Dazu ein kurzes Beispiel: Angenommen, ein C++-Programmmodul soll in einer Java-Anwendung genutzt werden. Die Integration beschreibt die Möglichkeiten, diese beiden Teile zu einer funktionsfähigen Anwendung zu verbinden. Dies wird üblicherweise durch eine neue Schnittstelle zwischen den beiden Programmen 7

16 2 Grundlagen realisiert. Bei der Ausführung ruft das Java-Programm das C++-Programm über die Schnittstelle auf. Das geschieht vom Nutzer unbemerkt, da der Zugriff während der Laufzeit im Hintergrund erfolgt. Für ihn ist - um die Begriffsdefinition aufzugreifen - die Anwendung ein Ganzes, das aus zwei Teilen geschaffen wurde. Im Gegensatz zur Migration und Portierung wird das C++-Programmmodul nicht in eine neue Sprache (Java) überführt. Stattdessen ermöglicht eine Brücke zwischen C++ und Java den Aufruf von C++-Code aus einem Java-Programm. 2.2 Praktische Grundlage der Arbeit Die praktische Grundlage dieser Arbeit ist der bereits in der Motivation angesprochene Kundenauftrag bei Siemens. Dabei befasst sich die gewünschte Migration mit einem Teil der Anwendung ESRI ArcGIS. Um den Kundenauftrag genauer zu erläutern wird im nächsten Abschnitt der Inhalt beschrieben. Abschnitt liefert die Verständnisgrundlage für ESRI ArcGIS und führt wichtige Begriffe ein. Eine Auflistung der genauen Anforderungen an eine Migration durch den Kundenauftrag wird im Abschnitt dargestellt Inhalt des Kundenauftrages Die Software ESRI ArcGIS in der Server-Version soll inklusive einer von Kunden entwickelten individuellen Softwareerweiterung auf einem Solaris-Server ausgeführt werden. Abbildung 2.1: Architektur des Kundenauftrages Die Problemstellung ergibt sich dabei ausschließlich aus der Erweiterung, da ArcGIS bereits in der Serverversion auf Solaris lauffähig ist. Die Softwareerweiterung, die 8

17 2.2 Praktische Grundlage der Arbeit nach Kundenwunsch ebenfalls für Solaris umgesetzt werden soll, ist in C++ implementiert und basiert auf der.net-bibliothek. Solaris ist ein UNIX-Betriebssystem und bietet daher keine.net-bibliotheken an. Somit ist Solaris nicht fähig, die individuelle.net/c++-erweiterung für ArcGIS nativ auszuführen. Da es sich bei der individuellen Softwareerweiterung des Kunden um eine aufwendig entwickelte Software handelt, besteht ein hohes Interesse an einer Migration. Die Architektur dieses Kundenauftrags ist in Abbildung 2.1 dargestellt. Die Programmiersprache Java ist auch auf UNIX-Plattformen wie Solaris lauffähig. Weiterhin ist der einzusetzende ArcGIS-Server auf Java EE aufgebaut. Daher soll die Erweiterung von.net nach Java migriert werden, um so die Erweiterung auf dem ArcGIS-Server bzw. auf Solaris ausführen zu können. Die genauen Rahmenbedingungen dieser Migration werden im Abschnitt aufgeführt ESRI ArcGIS Geographisches Informationsmanagement hält verstärkt Einzug in Industrieunternehmen und bei öffentlichen Auftraggebern. Mittels eines geographischen Informationssystems (GIS) können Aufgaben wie raumbezogene Analysen, Visualisierung von Geoinformationen und geographische Datenverarbeitung vorgenommen werden. Eine der weltweit erfolgreichsten Firmen im Bereich der GIS ist das US- Amerikanische Unternehmen ESRI [ESRb]. Die Software von ESRI findet in den unterschiedlichsten Bereichen ihre Verwendung. Zum Beispiel in Unternehmen wie New Zealand Post, um Postadressen besser zu organisieren (vgl. [ESR05a]), oder bei dem Zeitungsunternehmen Washington Times, um ihre Abonnenten geografisch zu erfassen (vgl. [ESR05b]). Neben Unternehmen greifen auch andere Institutionen wie Krankenhäuser, Schulen oder Stadtverwaltungen auf ESRI- Software zurück. Ein lokales und gerade aktuelles Beispiel ist die Stadt Paderborn, die seit diesem Jahr ArcGIS nutzt, um alle Stände und Veranstaltungsflächen auf dem jährlichen Volksfest Libori geografisch effektiver zu organisieren (vgl. [Dre07]). Auch das bei dieser Bachelorarbeit kooperierende Unternehmen Siemens beschäftigt sich auf Grund verschiedener Kundenaufträge mit der Produktfamilie ArcGIS von ESRI. ArcGIS setzt sich aus sich ergänzenden GIS-Softwareprodukten zusammen. Mit ArcGIS können GIS-Funktionen und -Daten in verschiedener Form angeboten werden: Am Desktop, via Server, im Web oder als Anwendung auf einem mobilen PC (PDA). Dabei bietet ArcGIS ein umfangreiches Developer Kit an, mit dem ArcGIS nach eigenen Anforderungen modifiziert und erweitert werden kann. Zu diesem Zweck lassen sich unter anderem Erweiterungen (im ArcGIS-Fachjargon Extensions genannt), die ArcGIS um eigene Funktionen ausbaut, oder individuelle 9

18 2 Grundlagen Anwendungen entwickeln. Diese Softwareerweiterungen ergänzen also eine bestehende Anwendung um eine zusätzliche Komponente. Eine solche Softwareerweiterung für ArcGIS bildet das zentrale Interesse des, dieser Arbeit als Ideengrundlage dienenden, Kundenauftrags Anforderungen an die Migration der ArcGIS-Erweiterung In diesem Abschnitt werden die Anforderungen des Kunden an die Migration der ArcGIS-Erweiterung von.net nach Java vorgestellt, die im späteren Verlauf der Arbeit wieder aufgegriffen werden, um unter diesen speziellen Rahmenbedingungen den Entscheidungsprozess für eine Strategie zur Migration zu verdeutlichen. Die Zielplattform, auf der die migrierte Anwendung ausgeführt werden soll, ist eine 64-bit Version eines SPARC-Rechners mit einem Solaris 9-Betriebssystem. Auf diesem Solaris Rechner ist bereits ESRI ArcGIS Server 9.2 mit Service Pack 2 vorinstalliert. Die Basis der Migration ist eine Softwareerweiterung, die für die aus der Produktfamilie ArcGIS stammende Anwendung ArcEditor in der Programmiersprache C++ entwickelt wurde. Die Strategie zur Migration soll vor allem eine kurze Migrationszeit aufweisen. Es sollen weiterhin sowohl die Windows-Variante(.NET) als auch die durch die Migration erstellte Solaris-Variante(Java) der Erweiterung parallel genutzt werden. Eine weitere Anforderung des Kunden ist daher, möglichst eine gemeinsame Code-Basis für beide Varianten zu haben (Single-Source-Basis genannt), um eine weitestgehend äquivalente Softwareerweiterung auf beiden Plattformen zu haben und eine einheitliche Wartung zu ermöglichen. Dadurch würde der Wartungsaufwand entscheidend verringert werden, da beide Varianten nicht separat gewartet werden müssen. 1 Infos zu ArcEditor auf: 10

19 3 Migrationsstrategien Dieses Kapitel beschäftigt sich mit Verfahren, die eine Migration von.net nach Java ermöglichen. Da diese Aufgabe sehr schwer zu bewältigen ist, sind zu diesem Thema sehr wenige Quellen vorhanden. Trotzdem konnten, unter anderem mit Hilfe des Internets, verschiedene Ansätze gefunden werden, die eine solche Migration auf unterschiedliche Weise ermöglichen. Diese Ansätze wurden in vier verschiedenen Strategien zusammengefasst und kategorisiert. Um die Auswahl eines geeigneten Verfahrens zu vereinfachen, wird eine Bewertung jeder Strategie vorgenommen. Zu diesem Zweck werden in dem ersten Unterkapitel 3.1 Bewertungskriterien formuliert. In vier weiteren Unterkapiteln wird jeweils eine Strategie vorgestellt. Dabei sind diese alle gleich gegliedert. Zuerst wird im Abschnitt Ansatz die konzeptionelle Idee hinter der Strategie beschrieben. Als Nächstes wird der Ansatz im zweiten Abschnitt Umsetzung weiter vertieft und es wird erläutert, wie die Strategie in der Praxis umgesetzt werden kann. Im Abschnitt Erfüllung der Kriterien wird untersucht, inwiefern die im Unterkapitel 3.1 vorgestellten Bewertungsgrundlagen für die jeweilige Strategie erfüllt werden. Eine genauere Bewertung der Strategien nach den Kriterien findet im Kapitel 4.1 statt. Der darauf folgende Abschnitt Weitere positive und negative Aspekte stellt dann noch individuelle Vor- und Nachteile jeder Strategie heraus, die durch die Kriterien nicht abgedeckt werden. Optional wird bei manchen Strategien in dem Abschnitt Fallstudie aus der Praxis ein publizierter Erfahrungsbericht über die Anwendung der jeweiligen Strategie beschrieben. Eine erfolgreiche Migration konnte in der Praxis, aufgrund verschiedener Probleme bei Installation und Ausführung der im Folgenden vorgestellten Migrationswerkzeugen, nicht durchgeführt werden. Diese praktischen Erfahrungen sind im Kapitel A im Anhang beschrieben. 3.1 Kriterien zur Bewertung von Migrationsstrategien In dieser Arbeit werden verschiedene Strategien untersucht, die eine Softwaremigration von einer Windows-Plattform auf.net-basis auf eine plattformunabhängige Umgebung, basierend auf Java, ermöglichen. Zur Beurteilung von Migrationsstra- 11

20 3 Migrationsstrategien tegien werden im Folgenden Kriterien vorgestellt, die als Bewertungsgrundlage dienen sollen. Die Kriterien können sich gegenseitig beeinflussen und oft muss entschieden werden, welche Kriterien für eine Migration besonders wichtig sind. In dieser Arbeit wird besonderen Wert auf Migrations- und Wartungsaufwand gelegt, da diese Kriterien die Kosten außerordentlich stark beeinflussen. Die im Folgenden aufgeführten Kriterien sind zum Teil auf Grundlage von Anforderungen entstanden, die von dem Kunden an Siemens für die Migration der ArcGIS-Erweiterung gestellt wurden (siehe Kapitel 2.2.3). Durch die Abstraktion aus diesem konkreten Fall wurden allgemeinere Bewertungskriterien für Migrationsstrategien abgeleitet. Darüber hinaus wurden weitere Kriterien formuliert, die den Vergleich der untersuchten Migrationsstrategien ermöglichen oder vereinfachen sollen Migrationsaufwand Zu Migrationsaufwand zählen alle Faktoren, die einen Einfluss auf die für die Migration benötigte Zeit und Kosten haben. Der Aufwand ergibt sich hauptsächlich aus dem Umfang und der Komplexität der zu migrierenden Anwendung. Je nach Strategie kann der Migrationsaufwand stark variieren. Zum Beispiel hat die Entscheidung, ob manuell oder (halb-)automatisch migriert wird, einen ausschlaggebenden Einfluss auf die Migrationszeit. Innerhalb der verschiedenen (halb-)automatischen Vorgänge kann dann wiederum differenziert werden, wie zeitaufwändig der jeweilige Vorgang ist. Im Extremfall, insbesondere bei sehr großen Anwendungen, kann ein Migrationsprozess sogar mehrere Jahre dauern (vgl. [Inc07]) Wartungsaufwand Auch nach der Migration entstehen Kosten. Die migrierte Anwendung muss gewartet werden. Zum Beispiel kann ein Anpassen an neue Anforderungen notwendig werden oder es müssen entdeckte Fehler behoben werden. Da die Wartung über die gesamte Zeitspanne der Anwendungsnutzung andauert, nimmt der dazugehörige Aufwand einen großen Stellenwert in der Planung ein. Wie eine Migrationsstrategie den Wartungsaufwand beeinflussen kann, soll das folgende Beispiel verdeutlichen: Angenommen, eine C++-Anwendung stellt anderen C++-Anwendungen bestimmte Funktionen bereit. Diese sollen auch in einer Java-Anwendung zusätzlich verwendet werden, weshalb die gesamte C++-Anwendung in Java re-implementiert wurde (dies wäre eine von vielen Migrationsstrategien). Nun verlangt eine neue Anforderung die Anpassung der Anwendung. Bei der beschriebenen Migrationsstrategie müssen die Änderungen sowohl an der C++- als auch an der Java-Version der Anwendung durchgeführt 12

21 3.1 Kriterien zur Bewertung von Migrationsstrategien werden, was doppelten Aufwand bedeutet. Andere Strategien ermöglichen die Wiederverwendung der C++-Anwendung, ohne sie in Java neu zu implementieren Effizienz der migrierten Anwendung Wird eine Anwendung auf eine neue Plattform migriert, kann die Ausführungszeit durch den Migrationsprozess erhöht werden. Da der Quellcode der ursprünglichen Anwendung häufig für die ursprüngliche Plattform optimiert wurde, kann bei der Migration auf eine neue Plattform ein gewisser Effizienzverlust auftreten. Dieser Effizienzverlust soll möglichst gering gehalten werden. Im Idealfall wird die Ausführungszeit durch die Migration verringert und ein Effizienzgewinn erzielt Plattformunabhängigkeit Da Quell- und Zielplattform in vielen Fällen nicht wählbar sind, soll eine Anwendung, die mit einer Migrationsstrategie erstellt wurde, möglichst flexibel genug sein, um bei beliebigen Quell- und Zielplattformen eingesetzt werden zu können. Als Plattform kann Hardware (z.b. Mac, PC), ein spezielles Betriebssystem wie Windows oder Solaris oder eine andere Art von Software-Umgebung (z.b. bei der Unterscheidung zwischen Desktop- und Webanwendungen) angesehen werden. Plattformunabhängigkeit bei einer Strategie erhöht die Wiederverwendbarkeit und macht die Strategie so über den speziellen Auftrag hinaus attraktiv Erhalt der Benutzerschnittstelle Sind die Betriebssysteme von Quell- und Zielplattform unterschiedlich oder soll eine Desktopanwendung zu einer Webanwendung werden, so kann die grafische Benutzeroberfläche der Anwendung nach der Migration anders aussehen als zuvor. Wenn diese Änderungen größere Ausmaße haben und so den Wiedererkennungswert der Anwendung stark beeinflussen, kann das zu Fehlbedienung bzw. zu damit verbundenen Schulungsaufwänden führen. Die Schnittstelle zum Benutzer dieser Anwendung sollte deswegen möglichst erhalten bleiben. 13

22 3 Migrationsstrategien 3.2 Strategie Cross Compiler Die Strategie Cross Compiler beschreibt, dem Namen entsprechend, die Möglichkeit bei der Migration einen Cross-Compiler zu nutzen. Im nächsten Abschnitt wird dieser Ansatz genauer erläutert. Der darauf folgende Abschnitt beschreibt dann, wie der Ansatz mit einem Migrationswerkzeug umgesetzt werden kann Ansatz Der Kernpunkt der Strategie ist die Verwendung eines Cross-Compilers. Ein Cross- Compiler erzeugt aus Dateien einer Plattform oder Programmierumgebung eine ausführbare Anwendung für eine neue Plattform oder Umgebung. In diesem Fall wird der Cross-Compiler aus einer.net-programmierumgebung aufgerufen und eine Java-Anwendung erstellt. Der Kompilierungsprozess mit einem Cross-Compiler geschieht, wie bei normalen Compilern, vollautomatisch Umsetzung Ein Softwareprodukt, welches die Umsetzung des Ansatzes ermöglicht, wird von der amerikanischen Firma Mainsoft angeboten. Die Firma Mainsoft [Cor] hat sich auf die Migration zwischen.net und Java (bzw. UNIX-Plattformen) spezialisiert. Die Software, die als Migrationswerkzeug zur Anwendung dieser Strategie gewählt wurde, nennt sich Mainsoft for Java EE 1 (früher bekannt unter dem Namen Visual MainWin for J2EE). Um den Cross-Compiler von Mainsoft for Java EE anwenden zu können, wird der zu migrierende.net-quellcode zuerst in eine allgemeine Zwischensprache übersetzt, aus der es einfacher ist, nach Java zu migrieren. Als diese allgemeine Zwischensprache wird die im.net-framework vorhandene Microsoft Intermediate Language (kurz: MSIL) verwendet. Die MSIL ist ein wichtiger Bestandteil des.net-frameworks, da bei einer Kompilierung in.net der Quellcode nicht direkt in systemeigenen Programmcode, sondern zuerst in die MSIL übersetzt wird. Aus dem übersetzten MSIL-Code wird dann im nächsten Schritt der ausführbare Maschinencode erzeugt. Auch das hier vorgestellte Migrationswerkzeug nutzt diesen Zwischenschritt. So wird bei der Migration von.net-quellcode zuerst in die MSIL übersetzt. Aus dem Code der allgemeinen Zwischensprache MSIL erstellt dann der Cross-Compiler von Mainsoft for Java EE ausführbaren Java-Bytecode. Die durch die Migration erstellte Java-Anwendung wird bei der Ausführung von zusätzlichen von Mainsoft for Java EE erstellten.net-laufzeitkomponenten

23 3.2 Strategie Cross Compiler unterstützt. Die zusätzlichen Laufzeitkomponenten sind deswegen notwendig, da die erstellte Java-Anwendung aus.net-quellcode entstanden ist und nicht alle Methoden aus.net-bibliotheken in Java umgesetzt werden können. Da viele mögliche Zielplattformen mit Betriebssystemen, wie zum Beispiel Solaris, zwar Java unterstützen, aber keine.net-bibliotheken anbieten, müssen beim Migrationsprozess zusätzliche.net-laufzeitkomponenten für Java erstellt werden, um die Java-Anwendung auch auf diesen Plattformen ausführen zu können. Bei der Durchführung einer Migration ist zu beachten, dass Mainsoft for Java EE ausschließlich für Web- und Serveranwendungen entwickelt wurde und deswegen für Desktopanwendungen nur sehr beschränkt anwendbar ist. Es können zum Beispiel keine Desktopanwendungen mit der Software migriert werden, die Windows.Forms verwenden, da Windows.Forms nicht von Mainsoft umgesetzt wurde (aufgrund von rechtlichen und kommerziellen Gründen, mehr dazu in Kapitel 4.1.1). Windows.Forms beinhaltet die Komponenten, die unter.net für die grafische Benutzeroberfläche (kurz: GUI) zuständig sind. Daher bezieht sich diese Beschreibung der Umsetzung einer Migration mit Strategie Cross Compiler und dem Migrationswerkzeug Mainsoft for Java EE auf Web- und Serveranwendungen. Mainsoft for Java EE kann über die Mainsoft-Homepage [Cor] bestellt werden. Die wichtigste Voraussetzung für eine Installation von Mainsoft for Java EE ist, dass sie auf einem Windows-Rechner (XP, Vista oder 2003 Server) geschieht, auf dem Visual Studio 2005 mit Service Pack 1 installiert ist. Visual Studio ist eine Entwicklungsumgebung für.net, die von Microsoft entwickelt wurde und besonders verbreitet ist. Für eine Installation ist Visual Studio deswegen wichtig, weil Mainsoft for Java EE als Erweiterung von Visual Studio installiert wird. Durch die Installation wird Visual Studio um Mainsoft-Komponenten erweitert. Unter anderem werden zwei neue Projekttypen in Visual Studio integriert. So können nach der Installation neben den Standardprojekten, wie zum Beispiel ein C#-Projekt, auch die beiden Projekte Visual Basic for Java EE und Visual C# for Java EE ausgewählt werden. Dies zeigt eine weitere Einschränkung des Migrationswerkzeugs. Anwendungen, die in C++ geschrieben wurden, der dritten großen Programmiersprache im.net-framework neben C# und Visual Basic (kurz: VB), können nicht mit Mainsoft for Java EE migriert werden. Durch die Erweiterung von Visual Studio werden allerdings viele neue Funktionen angeboten. Zum einen wird der Build-Prozess erweitert, der dafür zuständig ist, aus dem Quellcode eine ausführbare Anwendung zu erstellen. Der Build-Prozess besteht aus der Code-Kompilierung und dem Binden des kompilierten Codes an 15

24 3 Migrationsstrategien Bibliotheken. Bei den beiden Mainsoft-Projekttypen wird beim Ausführen des Build-Prozesses zuerst der Standard Visual Studio-Compiler aufgerufen. Dieser erstellt MSIL-Dateien. In diesen Dateien werden alle Programmbefehle des ursprünglich zu migrierenden Quellcodes als eine Folge von Bytewerten angegeben. Nachdem die Kompilierung in die MSIL erfolgreich war, ruft der Build-Prozess automatisch den von Mainsoft in Visual Studio eingebetteten Mainsoft for Java EE Compiler auf. Diese Schritte sind in Abbildung 3.1 dargestellt. Der Mainsoft for Java EE Compiler ist das Kernstück des Werkzeugs und ist der bereits beschriebene Cross-Compiler der Strategie. Dabei ist der Mainsoft Cross-Compiler fähig, auch.net-spezifische Programmiersprachenkonstrukte in Java umzusetzen. Abbildung 3.1: Technischer Ablauf der Strategie Cross Compiler aus [Cor07a] Der ausgeführte Build-Prozess ruft also, nachdem der Quellcode in die MSIL übersetzt wurde, den Cross-Compiler von Mainsoft auf und erzeugt aus den MSIL- Dateien Java-Bytecode. Die so erstellten ausführbaren Java-Dateien werden dann in einem WAR-Archiv (WAR-Dateien sind Web Archive die eine Java-Webanwendung enthalten) gepackt und auf dem vorher eingestellten Java EE-Applikationsserver ausgeführt. Dabei werden Fehler und Fortschritte während des Build-Prozesses genauso im Statusfenster von Visual Studio angezeigt, wie bei einem Build-Prozess einer normalen.net-anwendung, die unter Windows ausgeführt werden soll. Ebenfalls kann der ganze Prozess auch im Debug-Modus ausgeführt werden, da die Mainsoft Installation die Debug-Funktionen in Visual Studio mit eigenen Komponenten erweitert. So können bei der Erstellung von Java EE-Anwendungen aus Visual Studio die gleichen komfortablen Kontrollfunktionen genutzt werden. Auch nach einer erfolgreichen Migration von.net nach Java besteht weiterhin eine Abhängigkeit von.net-bibliotheken. Es gibt spezielle.net-funktionen, die nicht äquivalent in Java umgesetzt werden können. Aus diesem Grund müssen auf Zielrechnern mit Betriebssystemen, auf denen das.net-framework nicht lauffähig ist, wie zum Beispiel Solaris oder Linux, zusätzliche.net-laufzeitkomponenten 16

25 3.2 Strategie Cross Compiler zur Verfügung gestellt werden, um die erstellte Java-Anwendung auszuführen. Diese.NET-Komponenten müssen so umgesetzt sein, dass sie auch auf den Plattformen lauffähig sind, die normalerweise kein.net unterstützen. Zu diesem Zweck hat sich seit Jahren das Open-Source Projekt Mono [Nov] bewährt. Mono ermöglicht,.net-anwendungen unter Linux, Solaris oder auch Mac OS X auszuführen oder auch zu entwickeln. Die nötige Entwicklungs- und Laufzeitumgebung wird dabei von Mono zur Verfügung gestellt. Mono ist allerdings nur eine Technologie von.net und ist unvollständig. Mainsoft arbeitet seit Jahren in enger Kooperation mit dem Mono-Entwicklerteam zusammen. So war es auch Mainsoft möglich, für ihre Software Mainsoft for Java EE zusätzliche.net-laufzeitkomponenten für die mit der Software erstellten Java-Anwendungen zur Verfügung zu stellen. Dabei basieren die Mainsoft.NET-Laufzeitkomponenten auf Mono, wurden aber angepasst, um die speziellen Zwecke von Mainsoft zu erfüllen. Die jeweils nötigen.net-laufzeitkomponenten werden dabei automatisch beim Build-Prozess von Mainsoft for Java EE zusätzlich zum Java-Bytecode in dem durch die Migration erstellten Java-Archiv (WAR-Archiv) zur Verfügung gestellt (siehe Abb. 3.1). So wird die Ausführung des Java-Bytecodes möglich, obwohl.net-bibliotheken auf der Zielplattform fehlen. Damit diese zusätzlichen.net-laufzeitkomponenten keine neuen Anforderungen an den Zielrechner hervorrufen, werden sie von Mainsoft for Java EE in Java umgesetzt. Dabei wurden in Java unter anderem die kompletten Funktionen der.net-pakete ASP.NET (ASP = Active Server Pages, serverseitige Technologie in.net zum Erstellen von Webanwendungen) und ADO.NET (ADO = ActiveX Data Objects, in.net Sammlung von Klassen, die den Zugriff auf relationale Datenbanken ermöglichen) umgesetzt. Nachdem alle installierten Komponenten von Mainsoft for Java EE erläutert wurden, wird nun beschrieben, wie eine Migration durchgeführt werden kann. Dabei werden im Zuge dieser Arbeit nur die wichtigsten Vorgänge dargestellt. Eine detailliertere Dokumentation mit ausführlichen Tutorials und Beispielanwendungen ist auf der Developer-Seite 2 von Mainsoft einzusehen. Wie bereits erläutert kann zur Migration nur eine Web- oder Serveranwendung gewählt werden, die in C# oder VB implementiert ist. Entspricht die zu migrierende Anwendung diesen Anforderungen, so kann die Anwendung als Erstes in Visual Studio geladen werden. In der Menüleiste von Visual Studio sollte nun unter dem Menüpunkt Project die Funktion Generate Java EE Project angeklickt

26 3 Migrationsstrategien werden. Durch die Ausführung dieser Funktion werden für alle Komponenten des.net-quellcodes korrespondierende Java-Komponenten gesucht. Danach erstellt die Generate Java EE Project -Funktion aus dem.net-quellcode ein neues Java EE-Projekt in Visual Studio, welches zunächst die gleichen Bibliotheken nutzt wie der.net-quellcode. Über den Visual Studio Menüpunkt Build muss nun zum Cross-Kompilieren die Funktion Build-Solution ausgeführt werden. Nach erfolgreicher Ausführung ist die Portierung nach Java abgeschlossen und die Anwendung kann ausgeführt werden. Abbildung 3.2: Zielarchitektur der Strategie Cross Compiler Das Ergebnis aus der Migration mit der Strategie Cross Compiler (mit der Verwendung von Mainsoft for Java EE) ist in Abbildung 3.2 skizziert. Als einzige Anforderung muss auf dem Zielrechner die Java-Laufzeitumgebung (Java Virtual Machine, kurz: Java VM) lauffähig sein. Auf dem Zielrechner liegen außerdem der durch die Migration erstellte Java-Bytecode und die zusätzlichen.net-laufzeitkomponenten. Anmerkung: Alle folgenden Analysen und Bewertungen der Strategie Cross Compiler beziehen sich auf die Umsetzung der Strategie mit dem Migrationswerkzeug Mainsoft for Java EE um eine genauere Analyse und Bewertung zu ermöglichen. 18

27 3.2 Strategie Cross Compiler Erfüllung der Kriterien Migrationsaufwand Die einzigen immer vorhandenen manuellen Vorgänge sind beim Migrationsprozess das Laden der zu migrierenden Anwendung in Visual Studio, die Ausführung der Generate Java EE Project und Build Funktionen unter Visual Studio und das Ausführen der migrierten Anwendung. Daher ist das Kriterium Migrationsaufwand als eine der Stärken der Strategie zu betrachten. Durch die wenigen manuellen Vorgänge hat der Migrationsprozess einen hohen Automatisierungsgrad. Da automatische Prozesse immer eine große Aufwandseinsparung bedeuten, im Vergleich zu einem gleichwertigen manuellen Vorgang, wird mit der Strategie Cross Compiler, durch einen fast komplett automatischen Migrationsprozess, der Migrationsaufwand gering gehalten. So können viele Kosten und Zeit eingespart werden. Praktische Erfahrungen haben allerdings gezeigt, dass der Migrationsprozess von Mainsoft for Java EE Schwierigkeiten beinhaltet, die den Migrationsaufwand negativ beeinflussen (siehe Kapitel A.3). Wartungsaufwand Der schnelle Migrationsprozess wirkt sich auch positiv auf den Wartungsaufwand aus. Die gewünschten Änderungen können am.net-quellcode vorgenommen werden. Nachdem die Änderungen erfolgreich durchgeführt wurden, kann dann erneut mit der Software Mainsoft for Java EE nach Java migriert werden. So lassen sich ohne großen Zusatzaufwand die.net- und die Java-Versionen der Anwendung synchron halten, ohne die Wartung manuell auf zwei Quellcode- Versionen durchführen zu müssen. Man erhält also die Möglichkeit mit einer Single-Source-Basis (.NET) zu warten, dabei die Anwendung aber auf mehreren Plattformen (.NET- und Java-fähige Plattformen) anzubieten (siehe 3.2.5). So bietet die Wartung viele Möglichkeiten und ist trotzdem vom Aufwand her gering. Daher ist auch der Wartungsaufwand als positiver Aspekt der Strategie zu bewerten. Effizienz der migrierten Anwendung In einer Performance-Studie von Mainsoft [Cor07c] wurde ein Vergleich der Durchsatzrate zwischen der.net-variante und der durch Mainsoft for Java EE erstellten Java-Variante einer Anwendung durchgeführt. Dabei wurde in der Studie gezeigt, dass die Java-Variante nicht an Effizienz verloren hat und äquivalente Performancewerte aufweist. In einer Multi-CPU Umgebung hat die Java-Variante sogar bessere Werte als die.net-variante dieser Anwendung. 19

28 3 Migrationsstrategien Plattformunabhängigkeit Durch die Zielsprache Java sind die erstellten Java-Binaries auf allen Plattformen lauffähig, die eine Java Virtual Machine installiert haben. Die durch den Migrationsprozess erstellte Anwendung kann so auf verschiedenen Plattformen angeboten werden, ohne individuelle Änderungen vornehmen zu müssen. Erhalt der Benutzerschnittstelle Durch die genaue Umsetzung der.net-funktionalität in Java, unterstützt von den.net-laufzeitkomponenten, funktioniert die Anwendung nach der Migration für den Benutzer in gleicher Form (bezogen auf Web- und Serveranwendungen). So ist der Wiedererkennungswert der migrierten Anwendung für den Benutzer groß. Die Oberfläche der zu migrierenden Anwendung wird sich allerdings durch die Unterschiede bei der Oberflächengestaltung von Java und.net nach der Migration leicht ändern, was den Wiedererkennungswert negativ beeinflussen kann Weitere positive und negative Aspekte Ein großer Vorteil bei der Anwendung der Strategie Cross Compiler ist, dass nicht zwingend Java-Kenntnisse vorhanden sein müssen, um eine Java-Anwendung zu erstellen. Selbst bei einer Neuentwicklung kann der gesamte Quellcode innerhalb des.net-frameworks implementiert werden und dann mit Hilfe von Mainsoft for Java EE nach Java portiert werden. So können auch Programmierer, die auf.net spezialisiert sind und keine Java-Kenntnisse besitzen, Java-Anwendungen erstellen. Ein Nachteil ist hingegen die Abhängigkeit der erstellten Anwendung von den zusätzlichen Mainsoft.NET-Laufzeitkomponenten. Die migrierte Anwendung ist bei der Ausführung abhängig von einer korrekten vollständigen Laufzeitumgebung. Bei der Software Mainsoft for Java EE sind nur die.net-komponenten ADO.NET, ASP.NET und eine Unterstützung für Web Services umgesetzt. Andere.NET-Funktionen können mit dem Werkzeug von Mainsoft nicht migriert werden. Welche Anwendungen migriert werden können, hängt immer davon ab, was mit den.net-laufzeitkomponenten für die Zielplattform abgedeckt ist. Außerdem werden sich das.net-framework und auch die.net-komponenten ASP.NET und ADO.NET über die Jahre wahrscheinlich weiterentwickeln. Sollen dann Anwendungen mit neuen Funktionen aus dem.net-framework mit Mainsoft for Java EE migriert werden, ist man davon abhängig, dass auch Mainsoft die Laufzeitkomponenten aktualisiert. 20

29 3.2 Strategie Cross Compiler Fallstudie aus der Praxis Im Folgenden wird eine im Internet publizierte Fallstudie 3 über die Nutzung von Mainsoft for Java EE beschrieben. Die Studie zeigt, warum sich ein Unternehmen für die Durchführung ihrer Migration für Mainsoft for Java EE entschieden hat und wie die Migration verlaufen ist. Die israelische Firma Comtec ist eines der führenden Unternehmen, die informationstechnologische Anwendungen für Versicherungen anbieten. Ihre Software Total Insurance System (kurz: TIS) bietet alle wichtigen Funktionen für Versicherungen an, wie die Generierung von Versicherungspolicen oder Risikoeinschätzung. Die Anwendungslogik von TIS ist in COBOL implementiert und die Browser-basierte GUI in.net umgesetzt. Um den Kundenkreis zu erweitern, entschied das Unternehmen TIS auch auf Java EE Servern anzubieten. Dazu sollte die auf.net basierende GUI nach Java EE migriert werden. Comtec schätzte, dass ein manuelles Neuschreiben ungefähr 6 Monate dauern würde. Da ihre Softwareentwickler sowohl in.net als auch Java geschult sind, wären auch keine Umschulungen oder Anstellungen neuer Mitarbeiter notwendig gewesen. Das Management war allerdings besorgt, dass die durch ein manuelles Neuschreiben nötige separate Wartung der.net- und Java-Anwendung langfristig die Kosten der Wartung im großen Ausmaß erhöhen würde. Daher entschied man sich gegen die manuelle Neuimplementierung und für die Verwendung von Mainsoft for Java EE. Durch die Migration in Kompilierungszeit bietet die Mainsoft-Anwendung die Möglichkeit, alle Wartungsvorgänge nur am.net-quellcode vorzunehmen, um dann nach erfolgreicher Wartung die Java-Variante von TIS in schneller Art und Weise wieder neu zu erstellen. So kann trotz Single-Source-Basis eine Multi-Plattform-Lösung angeboten werden. Mit der Migrationslösung von Mainsoft wurden von Comtec so Zeilen C#-Quellcode und Zeilen VB-Quellcode zu Java-Bytecode portiert. Inzwischen wird daher von Comtec eine Java EE-Version von TIS angeboten

30 3 Migrationsstrategien 3.3 Strategie Cross Plattform Die Strategie Cross Plattform ermöglicht die Ausführung einer.net-anwendung auf einer neuen Zielplattform. Der Name Cross Plattform bezieht sich auf spezielle an die Zielplattform angepasste Bibliotheken, die zur Ausführung der.net- Anwendung auf der Zielplattform installiert werden Ansatz Bei der normalen Kompilierung von.net-quellcode werden ausführbare Dateien (Binaries) der Anwendung für Windows erstellt. Der Ansatz der Strategie Cross Plattform sieht hingegen vor, den Compiler so zu modifizieren, dass aus dem.net-quellcode Binaries für die gewünschte UNIX-Zielplattform erstellt werden können. Auf der Zielplattform müssen zusätzliche Laufzeitkomponenten (die so genannten Cross-Plattform-Bibliotheken) installiert werden, um die Ausführung der.net-anwendung auf einer UNIX-Plattform zu ermöglichen. Nach der Modifikation des Compilers und der Installation der Laufzeitkomponenten auf der Zielplattform kann die.net-anwendung auf einer Windows-Plattform cross-kompiliert werden, um dann die erstellten UNIX-Binaries auf der UNIX-Zielplattform mit Hilfe der Laufzeitkomponenten auszuführen. Bei diesem Ansatz ist zu beachten, dass keine Java-Anwendung erstellt wird. Allerdings kann in vielen Fällen die Zielsetzung einer Migration auch ohne eine Java-Umsetzung erreicht werden. Wenn das Ziel einer Migration ist, eine.net- Anwendung auf einer UNIX-Plattform lauffähig zu machen, kann dies auch durch die Cross Plattform -Strategie erreicht werden, ohne die Anwendung nach Java zu migrieren. Soll die mit der Strategie Cross Plattform erstellte Anwendung jedoch zwingend in einer Java-Anwendungsumgebung eingesetzt werden, so ist man darauf angewiesen, dass das Migrationswerkzeug eine Integrationslösung anbietet oder eine externe Lösung angeboten wird. Das im folgenden Abschnitt Umsetzung vorgestellte Migrationswerkzeug ermöglicht diese Integration Umsetzung Wie schon bei der Strategie Cross Compiler, wird auch bei dieser Strategie als Migrationswerkzeug ein Softwareprodukt der Firma Mainsoft gewählt. Dieses Produkt nennt sich Mainsoft for UNIX and Linux 4 (früher bekannt unter dem Namen Visual MainWin for UNIX and Linux)

31 3.3 Strategie Cross Plattform Die Installation dieses Migrationswerkzeugs ist in zwei Komponenten aufgeteilt. Die erste Komponente ist für die erweiterte Kompilierung zuständig (auch als Software Development Kit bezeichnet, kurz: SDK) und auf dem Windows-Startrechner zu installieren. Die zweite Komponente ist für die Laufzeitumgebung auf der UNIX- Zielplattform zuständig. Dabei werden die folgenden UNIX-Plattformen von Mainsoft for UNIX and Linux unterstützt: Sun Solaris mit SPARC (32 und 64 bit Edition) IBM AIX mit POWER (32 bit Edition) HP-UX mit PA-RISC (32 bit Edition) HP-UX mit Itanium 2 (32 bit Edition) Linux (32 und 64 bit Edition) Die erweiterten Kompilierungskomponenten werden auf dem Windows-Rechner, von dem aus der Migrationsprozess gestartet werden soll, in Visual Studio eingebettet. Unterstützt werden die Versionen Visual Studio 2005, Visual Studio.NET 2003 und Visual Studio 6. Die Build-Komponente in Visual Studio, die für das Abbildung 3.3: Technischer Ablauf der Strategie Cross Plattform aus [Cor07b] Erstellen einer ausführbaren Anwendung aus vorhandenem Quellcode zuständig ist, wird wie bei der Strategie Cross Compiler um zusätzliche Funktionen erweitert. Vor der Installation des Mainsoft SDK war es nur möglich, Windows-Binaries zu erstellen. Nachdem die Build-Komponente modifiziert wurde, wird die Liste der möglichen Zielplattformen der Binaries um die oben genannten Plattformen erweitert (siehe Abb. 3.3). 23

32 3 Migrationsstrategien Auf der Zielplattform (UNIX-basiert) werden die Laufzeitkomponenten installiert. Diese können in zwei große Pakete eingeteilt werden. Zum einen die Komponenten, die dafür zuständig sind, eine Windows-Laufzeitumgebung zu schaffen ( Windows Runtime genannt) und zum anderen die Komponenten, die die Ausführung der speziellen Mainsoftfunktionen ( Mainsoft Core Services genannt) unterstützen sollen. Zusammen erlauben sie, Windows-Applikationen nativ auf UNIX auszuführen. Zu den Windows-Funktionalitäten, die durch die Windows Runtime zur Verfügung gestellt werden, zählen unter anderem Dienste wie MSXML (Microsoft XML Core Services), SSL (Secure Sockets Layer), MSHTML (Microsoft Hypertext Markup Language Services), WinSock (Windows Sockets API), COM/DCOM (Component Object Model/Distributed Component Object Model) und ATL (Active Template Library). Die Windows-Runtime basiert auf der ursprünglichen Implementierung von Microsoft, die von Mainsoft für UNIX angepasst wurde. Abbildung 3.4: Zielarchitektur der Strategie Cross Plattform Die Mainsoft Core Services beinhalten unter anderem die Mainsoft RP- CSS (Mainsoft Remote Procedure Call System Services) und Registry Services. Diese bieten eine robuste Infrastruktur an, um parallel eine große Anzahl von Mainsoft for UNIX and Linux-Prozessen auf dem gleichen Rechner laufen zu lassen. 24

33 3.3 Strategie Cross Plattform Nach erfolgreicher Installation kann dann der Migrationsprozess beginnen. Dabei ist als negatives Detail zu erwähnen, dass nur.net-anwendungen, die in C++ verfasst wurden, als Migrationsobjekt dienen können. Alle anderen.net-programmiersprachen werden in der aktuellen Version der Software nicht unterstützt. Soll eine Anwendung migriert werden, muss auf einem Windows-Rechner über Visual Studio die C++-Anwendung geladen werden. Im Menü von Visual Studio kann dann der Befehl Build ausgewählt werden. Da dieser durch Mainsoft- Komponenten erweitert wurde, kann nun die gewünschte UNIX-Zielplattform selektiert werden. Nach dieser Selektion werden anschließend nicht wie üblich die Windows-Binaries erstellt, sondern die Binaries der entsprechenden Zielplattform. Diese Binaries können mit Hilfe der Windows-Runtime und den Mainsoft Core Services auf der Zielplattform ausgeführt werden. Zur Integration der durch die Migration erstellten Anwendung in eine Java EE-Anwendungsumgebung, wird das Java EE Intergration Package (JIP) angeboten. Das JIP ermöglicht eine übergangslose Interoperabilität einer mit Mainsoft portierten Anwendung mit einem Java EE Server. So ist es möglich, Java- und Microsoft-Technologien auf einer UNIX-Plattform zu kombinieren, obwohl die.net-anwendung nicht direkt nach Java migriert wird. Aus den installierten Komponenten und einer mit Mainsoft for UNIX and Linux migrierten Anwendung ergibt sich eine Zielarchitektur, die in Abbildung 3.4 dargestellt ist. Anmerkung: Alle folgenden Analysen und Bewertungen der Strategie Cross Plattform beziehen sich auf die Umsetzung der Strategie mit dem Migrationswerkzeug Mainsoft for UNIX and Linux um eine genauere Analyse und Bewertung zu ermöglichen Erfüllung der Kriterien Migrationsaufwand Die Strategie Cross Plattform benötigt in der Durchführung sehr wenige manuelle Schritte. Dadurch hat die Migration einen sehr hohen Automatisierungsgrad und ist damit schnell und einfach durchzuführen. Der Migrationsaufwand ist so denkbar gering und ein markanter positiver Aspekt der Strategie. Die wenigen manuellen Schritte sind das Laden des Quellcodes in Visual Studio, das Cross-Kompilieren mit der erweiterten Build-Funktion und das Ausführen auf der Zielplattform. Alles andere wird automatisch von dem Migrationswerkzeug Mainsoft for UNIX and Linux übernommen. Bei der praktischen Anwendung des Werkzeugs hat 25

34 3 Migrationsstrategien sich aber gezeigt, dass trotzdem verschiedene Probleme entstehen können, die den Migrationsaufwand negativ beeinflussen (siehe Kapitel A.2). Wartungsaufwand Auch der geringe Wartungsaufwand fällt positiv auf. Alle Wartungsarbeiten, die nach der Migration erfolgen sollen, können am ursprünglichen.net-quellcode vorgenommen werden, um dann daraus wieder den migrierten Code zu erstellen. Da der Migrationsvorgang schnell und einfach ist, entsteht dadurch kein schwerwiegender Zusatzaufwand. So kann zur Wartung die Programmierumgebung von Visual Studio genutzt werden und dann schnell zur Zielplattform migriert werden. Wie auch bei der Strategie Cross Compiler kann also die Wartung mit einer Single-Source-Basis (.NET) geschehen (vgl ). Effizienz der migrierten Anwendung Mainsoft hat gerade für eine effiziente Ausführung auf der Zielmaschine viele Funktionen für die Windows-Runtime und die Mainsoft Core Services umgesetzt. So wurde zum Beispiel für die Windowsprozesse auf UNIX Multi-Thread- und Multi-Prozess-Unterstützung für die Windows-Runtime entwickelt. Auch die ebenfalls in der Windows-Runtime enthaltenen COM/DCOM Transport-Layer sorgen für eine effiziente Kommunikation innerhalb des Zielrechners zwischen COM-Objekten bei der Ausführung der migrierten Anwendung. Diese und viele weitere Umsetzungen innerhalb der Windows-Runtime und der Mainsoft Core Services sorgen dafür, dass die Anwendung nach der Migration keinen wesentlichen Effizienzverlust aufweist. Nach Angaben von Mainsoft wird eine nachhaltige Durchsatzrate von Transaktionen pro Sekunde erreicht [Cor07b]. Plattformunabhängigkeit Das Kriterium Plattformunabhängigkeit ist der größte Schwachpunkt der Strategie. Es wird nicht wie in der Strategie Cross Compiler Java-Bytecode erstellt, der auf allen Plattformen lauffähig ist, die eine Java VM haben. Es werden Binaries für die gewünschte Zielplattform erstellt. Da die erstellen Binaries immer nur auf einer bestimmten Plattform laufen, ist die migrierte Anwendung nicht plattformunabhängig. Außerdem werden nicht alle Plattformen als mögliche Zielplattform unterstützt, was weitere Einschränkungen bedeutet. Erhalt der Benutzerschnittstelle Der Erhalt der Benutzerschnittstelle ist positiv zu bewerten. Der.NET-Quellcode wird auf der Zielplattform in gleicher Form umgesetzt. Dies ist durch die zusätzlichen.net- und Windows-Laufzeitkomponenten möglich, die auf der Zielplattform installiert werden. So kann der Wiedererkennungswert bewahrt werden. Die Oberfläche bleibt in gleicher Form unverändert, wie auch die Funktionalitäten der Anwendung. 26

35 3.3 Strategie Cross Plattform Weitere positive und negative Aspekte Der bei der Strategie Cross Compiler bereits erwähnte negative Aspekt, die Abhängigkeit von den zusätzlichen Mainsoft-Laufzeitkomponenten, betrifft auch die hier beschriebene Strategie (vgl ). Bei der Migration mit Mainsoft for UNIX and Linux ist die Ausführung abhängig von vollständigen und aktuellen zusätzlichen Laufzeitkomponenten. Das betrifft sowohl die Windows-Runtime als auch die Mainsoft Core Services. Diese Abhängigkeit ist gerade für eventuell in der Zukunft auftretende Probleme und damit verbundene Kosten ein klarer Nachteil Fallstudie aus der Praxis Im Folgenden wird eine im Internet publizierte Fallstudie 5 über die Nutzung von Mainsoft for UNIX and Linux beschrieben. Die US-Amerikanische Firma PTC ist eine der weltgrößten Softwarefirmen. Sie unterstützt große Unternehmen mit Software für alle Phasen einer Produktentwicklung, wie Produktplanung und Konstruktion. Um eine große Kundenanfrage zu erfüllen, stand PTC vor der Herausforderung, eine Windowsapplikation (mit fast zwei Millionen Zeilen C++-Quellcode) auf schnelle und zuverlässige Art und Weise von Windows nach Solaris und andere Betriebssysteme zu portieren. PTC entschied sich, die Migrationslösung Mainsoft for UNIX and Linux für diese Portierung zu verwenden. Die Migration mit Hilfe der Mainsoft-Anwendung dauerte ca. sechs Monate. So wurden geschätzte zwei Jahre gespart im Vergleich zu einem kompletten Neuschreiben der zu migrierenden Anwendung für die neuen Betriebssysteme. Außerdem wurde durch Mainsoft for UNIX and Linux ermöglicht, als Codebasis für Entwicklung und Wartung weiterhin innerhalb von Visual Studio zu arbeiten und eine Single-Source-Basis zu nutzen und trotzdem eine Version für verschiedene Betriebssysteme anzubieten. So konnten Entwicklungs- und Wartungskosten verringert werden. Mit Hilfe der von Mainsoft für andere Betriebssysteme umgesetzten Windows- Runtime konnte, trotz der erreichten nativen Ausführung in einer neuen Betriebssystemumgebung, die Windowsfunktionalität erhalten bleiben. Mittels der effektiven Migration erreichte PTC einen großen Wettbewerbsvorteil durch die schnellstmögliche Erfüllung des Kundenauftrags

36 3 Migrationsstrategien 3.4 Strategie Schnittstellen Die Strategie Schnittstellen beschreibt die Idee, eine.net-anwendung aus einer Java-Anwendung heraus über eine Schnittstelle anzusprechen. Diese Idee ist ursprünglich der Integration zuzuordnen, kann allerdings unter bestimmten Rahmenbedingungen die Zielsetzung einer Migration erfüllen. Es gibt verschiedene Softwareprodukte, die mit unterschiedlichen Vorgehensweisen eine Schnittstelle zwischen.net und Java herstellen können Ansatz Der Ansatz der Strategie Schnittstellen sieht die Erstellung einer Schnittstelle zwischen Java und.net vor. Eine solche Schnittstelle können z.b. Proxy-Dateien bilden. Proxy-Dateien sind Stellvertreterobjekte, die Informationen über die betreffende Anwendung gespeichert haben, aus der sie erstellt wurden. Um von Java auf.net zugreifen zu können, müssen Proxy-Dateien aus einer.net-anwendung heraus für Java erstellt werden. Diese Proxyobjekte können dann im Java-Zielcode integriert werden. Wird die Java-Anwendung ausgeführt, so greift Java über die erstellten Schnittstellen in Form der Proxyobjekte auf den.net-quellcode zu und liefert die angefragten Daten. So können Funktionen aus dem.net-quellcode innerhalb von Java genutzt werden. Dabei ist der Ansatz eher der Integration und nicht direkt der Migration zuzuordnen. Anstatt den Quellcode von.net nach Java zu übersetzen, werden nur Werte über die Schnittstelle zwischen.net und Java übergeben. Daher können mit dieser Strategie nur Teile einer.net-anwendung aus Java über die Schnittstelle angesprochen werden. Die Oberfläche der zu migrierenden.net-anwendung kann nicht über eine Schnittstelle innerhalb von Java genutzt werden. Die durch die Strategie Schnittstellen erstellten Proxyobjekte brauchen eine durch eine andere Strategie erstellte Java-Zielcodeumgebung, in der sie eingebettet werden können. Diese kann manuell oder mit Hilfe eines anderen Verfahrens erstellt werden. Durch einen solchen kombinierten Einsatz kann folglich auch das Ziel einer Migration erreicht werden Umsetzung Für die Umsetzung dieser Strategie wurden exemplarisch das Open-Source-Projekt IIOP.NET [Elc] der Firma ELCA und die Anwendung Proxygen, die Bestandteil des SDK s von ESRI ArcGIS ist, ausgewählt. Weitere mögliche Varianten zur Umsetzung des vorgestellten Ansatzes wären unter anderem Ja.NET [Int] von der Firma Intrinsyc und Janeva [Bor] von der Firma Borland. IIOP.NET wurde gewählt, da es sich als einzige der oben beschriebenen Produkte um eine kostenlose Software handelt. Die Anwendung Proxygen wurde 28

37 3.4 Strategie Schnittstellen von ESRI entwickelt und bietet sich daher als vielversprechende Option zur Erfüllung des Kundenauftrags an. Zuerst wird die Durchführung einer Migration mit der Software Proxygen beschrieben und anschließend folgt die Beschreibung der Umsetzung mit IIOP.NET. Proxygen Proxygen ist eine von ESRI entwickelte Software und Teil des Java-SDK s von ArcGIS (siehe auch 2.2.2). Proxygen wird automatisch bei der Installation von ArcGIS Java SDK mitinstalliert. Dabei wird die Software in ein Unterverzeichnis von ArcGIS abgelegt (ArcGIS-Installationsverzeichnis\java\tools\proxygen). Proxygen ist zwar für ArcGIS entwickelt worden, kann aber genauso bei anderen Anwendungen genutzt werden. Zur Erstellung der Proxyobjekte müssen als Erstes die notwendigen Informationen der zu migrierenden.net-anwendung angegeben werden. Dazu befindet sich in dem Proxygenverzeichnis die Textdatei typelib.txt. Diese muss geöffnet und per Hand Informationen über die zu migrierende.net-anwendung eingegeben werden. Die anzugebenden Informationen betreffen die Dateipfade der Typbibliotheken (*.tlb, *.olb oder *.dll Dateiendungen) der zu migrierenden.net- Anwendung. Jede Typbibliothek muss dabei in einer eigenen Zeile und jeweils durch drei mit, getrennte Informationen beschrieben werden. Die erste Information ist der absolute Dateipfad der Typbibliothek. Die zweite Information ist der Name des Java-Pakets, in welches die Proxyobjekte integriert werden sollen. Die dritte Information ist der absolute Dateipfad, in dem die erstellten Proxyobjekte gespeichert werden sollen (zum Beispiel: C:\AgsExtension\AgsExtension.tlb,agsext,C:\AgsExtension\agsext). Als Nächstes kann Proxygen ausgeführt werden. Dazu werden die vorherigen Eingaben aus der Datei typelib.txt gelesen und die angegebenen Typbibliotheken analysiert. Dabei erhält Proxygen Informationen über Ein- und Ausgabeparameter (Parametername, Dateityp, etc.) der zu migrierenden.net-anwendung aus den Typbibliotheken. Mit diesen Informationen werden dann die Stellvertreterobjekte für die Zielsprache Java in dem in der Datei typelib.txt angegebenen Ordner erzeugt. Die erzeugten Proxy-Dateien haben die Dateiendung.java und können so in das jeweilige Java-Paket der Zielanwendung integriert werden. Aus Java können dann über die Stellvertreterobjekte Funktionen der.net-anwendung aufgerufen und Parameter in beide Richtungen übergeben werden. 29

38 3 Migrationsstrategien IIOP.NET Die Open-Source-Lösung IIOP.NET wurde im Zuge einer Diplomarbeit an der ETH Zürich entwickelt. Um Java und.net zu verbinden, nutzt IIOP.NET, wie der Name vermuten lässt, das Internet Inter-ORB Protocol (kurz: IIOP). Das ORB in dem Namen steht dabei für einen Object Request Broker, eine Software-Komponente, die Aufrufe von und zu verteilten Objekten vermittelt. Für die Kommunikation der verteilten Objekte nutzt ein ORB dann das auf TCP/IP basierende IIOP(vgl. [SPR04]). Dabei ist durch IIOP.NET sowohl der Zugriff von Java auf.net als auch umgekehrt möglich. In dieser Arbeit wird auf Grund der Thematik nur der Zugriff von Java auf eine.net-anwendung betrachtet. Da IIOP.NET eine Open-Source-Lösung ist, steht die aktuellste Version (Stand 10/07: Version 1.9.0) der Software kostenfrei auf der Produkthomepage 6 zum Download bereit. Dabei enthält das Download-Paket kein Installationsprogramm. Vielmehr beinhaltet der Download den gesamten Quellcode der Software. Die Software muss daher zuerst kompiliert werden, bevor sie ausgeführt werden kann (siehe auch [SPR04]). Durch die Kompilierung werden verschiedene Komponenten erzeugt. Die Datei IIOP-Channell.dll erweitert die Funktionen des.net-remoting um IIOP. Java braucht nicht um IIOP-Komponenten erweitert werden, da in Java standardmäßig RMI/IIOP vorhanden ist. RMI steht für Remote Method Invocation und ermöglicht Java, Methoden von entfernten Objekten aufzurufen. RMI/IIOP ist dabei eine Sammlung von Klassen, die RMI auf Basis von IIOP implementieren. Abbildung 3.5: Technischer Ablauf der Strategie Schnittstellen Weiterhin wichtig für einen Zugriff von Java auf Klassen einer.net-anwendung ist das Werkzeug CLSIDLGenerator, mit dessen Hilfe aus.net-klassen IDL-Dateien erzeugt werden können. Diese IDL-Dateien (IDL = Interface Definition Language, zu deutsch: Schnittstellenbeschreibungssprache) beinhalten von

39 3.4 Strategie Schnittstellen Programmiersprachen unabhängige Beschreibungen der.net-klassen sowie deren Methoden und Attribute (vgl. [SPR04]). IDL-Dateien haben außerdem den großen Vorteil, dass innerhalb der Java-SDK s standardmäßig das Werkzeug idlj enthalten ist. Mit idlj können Java-Stellvertreterklassen der IDL-Dateien erzeugt werden. Zu diesem Zeitpunkt zeigt sich die Ähnlichkeit zu Proxygen. Wie bei der Ausführung von Proxygen erhält man auch nach der Ausführung von idlj Stellvertreterobjekte der ursprünglichen.net-klassen, die in eine Java-Anwendung eingebunden werden können. Der technische Ablauf bei der Erstellung von Stellvertreterklassen ist in Abbildung 3.5 dargestellt. Sind die Stellvertreterklassen in die Java-Zielanwendung der Migration eingebunden, können die Methoden der ursprünglichen.net-klassen genutzt werden. Wird bei der Ausführung der Java-Anwendung eine solche Methode aufgerufen, wird über die Stellvertreterobjekte per IIOP auf die.net-klassen zugegriffen und die angeforderten Werte übergeben. Wenn mittels IIOP.NET erfolgreich IDL-Dateien und Java-Stellvertreterklassen erzeugt wurden und die Stellvertreterobjekte in die Java-Zielanwendung eingebunden wurden, ergibt sich eine Zielarchitektur, die in Abbildung 3.6 dargestellt ist. Abbildung 3.6: Zielarchitektur der Strategie Schnittstellen (IIOP.NET) Dabei ist die Architektur zweigeteilt. Zum einen der.net-teil, bei dem die Anforderung besteht, dass die.net-anwendung auf einem Windows-Rechner ausgeführt werden muss. Zum anderen der Java-Teil, der auf einem Rechner mit 31

40 3 Migrationsstrategien installierter Java VM ausgeführt werden soll. Dabei können diese beiden Teile auf einem einzigen Rechner realisiert werden oder über ein lokales Netzwerk bzw. per Internet mittels IIOP kommunizieren und so auf zwei verschiedenen Rechnern laufen. Da der Java-Teil Informationen von dem.net-teil anfordert, können die beiden Teile auch als Java-Client und.net-server bezeichnet werden. Der.NET-Server besteht aus drei Komponenten. Die erste Komponente, die IIOP.NET-Bibliotheken, erweitern das.net-framework um die notwendigen IIOP-Funktionen. Die zweite Komponente stellt die Implementierung der zu migrierenden Anwendung dar. Die dritte Komponente bezeichnet die Implementierung der Serverinformationen innerhalb von.net, die zur Kommunikation mit dem Java-Client notwendig sind, wie z.b. eine Portnummer. Auf der Java-Clientseite steht dem entsprechend als erste Komponente die Implementierung der Clientinformationen, die notwendige Anweisungen zur Kommunikation über IIOP zum.net-server beinhalten. Zudem liegen auf dem Java-Client die erstellten Stellvertreterobjekte aus den Klassen der zu migrierenden.net-klassen, in der Architektur als Proxy-Dateien bezeichnet. Die letzte Komponente des Java-Clients ist die umgebende Java-Applikation, in der die Proxy-Dateien eingebettet werden. Anmerkung: Alle folgenden Analysen und Bewertungen der Strategie Schnittstellen beziehen sich auf die Umsetzung der Strategie mit dem Migrationswerkzeug IIOP.NET, um eine genauere Analyse und Bewertung zu ermöglichen. IIOP.NET wurde Proxygen vorgezogen, da eine ausführlichere Dokumentation und somit eine genauere Beurteilung möglich ist. Außerdem hat die praktische Anwendung von Proxygen viele Probleme aufgezeigt (siehe Kapitel A.1) Erfüllung der Kriterien Migrationsaufwand Die Erstellung der Java-Stellvertreterklassen geschieht durch die Werkzeugunterstützung sehr schnell und einfach ohne nennenswerten manuellen Aufwand. So kann durch die Erstellung mit einem automatischen Prozess Migrationsaufwand im Vergleich zu einer manuellen Neuimplementierung gespart werden. Zur Verwendung der Stellvertreterklassen müssen allerdings manuelle Rahmenbedingungen geschaffen werden. Die Aufrufe der Methoden aus den Klassen müssen in der Java-Zielapplikation manuell implementiert werden. Für die Kommunikation per IIOP ist die manuelle Implementierung von Server- und Clientanweisungen notwendig. Diese manuellen Implementierungen erhöhen wiederum den Migrationsaufwand. Außerdem kann die Strategie nur für Teile einer zu migrierenden Anwendung genutzt werden. So müssen Anwendungsteile, wie zum 32

41 3.4 Strategie Schnittstellen Beispiel die Oberflächengestaltung oder Benutzereingaben, mit anderen Strategien (im Notfall manuell) migriert werden. Wartungsaufwand Der Wartungsaufwand ist verhältnismäßig groß. Es muss sowohl der Java-Teil als auch der.net-teil separat gewartet werden, da beides Teile der gesamten Anwendung sind. So besteht keine Möglichkeit auf Single-Source-Basis zu warten. Erschwerend kommt auch die Mitwartung der Schnittstellen hinzu. Werden Änderungen an den.net-klassen vorgenommen, so müssen auch die Java-Stellvertreterklassen neu erstellt und integriert werden. Es exisitieren dementsprechend drei verschiedene Wartungsstellen, die einen großen Wartungsaufwand hervorrufen. Effizienz der migrierten Anwendung Durch die Verwendung von Proxyobjekten und der Kommunikation mit den.net- Klassen kommen zu der normalen Ausführung der Java-Zielanwendung zusätzliche Prozesse hinzu, die die Effizienz der migrierten Anwendung negativ beeinflussen. Wird bei der Ausführung der Java-Anwendung eine Methode aufgerufen, die aus einem Proxyobjekt stammt, muss per entferntem Aufruf diese Methode in einer.net-laufzeitumgebung ausgeführt werden. Im Vergleich zu einer Ausführung einer Methode, die direkt in Java umgesetzt wird, verlangsamt dieser Prozess die Ausführung. Je nach gewählter Zielarchitektur kann diese Kommunikation auch zwischen zwei Rechnern geschehen, was ebenfalls die Ausführung verlangsamt. Plattformunabhängigkeit Der Java-Teil der Zielarchitektur (rechts in Abbildung 3.6) hat eine Java VM als einzige Anforderung an die Plattform, auf der er ausgeführt wird. Daher kann dieser Teil auf jeder Plattform, die Java-fähig ist, ausgeführt werden. Da der.net-teil per lokalem Netzwerk oder Internet aus Java heraus auf einem anderen Rechner aufgerufen werden kann, bleibt diese Plattformunabhängigkeit der Java-Zielanwendung erhalten. Der.NET-Teil der Zielarchitektur (links in Abbildung 3.6) ist hingegen nicht Plattformunabhängig, da der Einsatz auf einem Windows-Rechner gefordert ist. Erhalt der Benutzerschnittstelle Da mit der Strategie Schnittstellen keine Oberflächen migriert werden können, ist dieser Punkt nicht für die Strategie bewertbar. Der Erhalt der Benutzerschnittstelle hängt immer davon ab, mit welcher anderen Strategie die Strategie Schnittstellen kombiniert wird. 33

42 3 Migrationsstrategien Weitere positive und negative Aspekte Ein weiterer positiver Aspekt der Strategie Schnittstellen ist die Existenz von kostenfreien Lösungen, wie das Open-Source-Projekt IIOP.NET. So können teure Lizenzgebühren gespart werden. Ein negativer Aspekt ist die Zielarchitektur. Da bei der Ausführung der Zielanwendung weiterhin.net-methoden ausgeführt werden müssen, muss in der Zielarchitektur berücksichtigt werden, dass die Ausführung von.net- Anwendungsteilen möglich ist. Dabei gibt es zwei Varianten, die beide negative Aspekte beinhalten. Die erste Variante ist die Realisierung des Java-Clients und.net-servers auf zwei verschiedenen Rechnern. Diese müssen durch eine beliebige Netzwerkarchitektur verbunden sein, um miteinander kommunizieren zu können. Durch die Verwendung von zwei Rechnern und der dadurch benötigten Netzwerkumgebung, wird aber der Hardwareaufwand erhöht. Die andere Variante wäre die Verwendung von nur einem Rechner für.net-server und Java-Client. Dadurch ist der Hardwareaufwand zwar geringer, aber die Tatsache, dass.net und Java auf demselben Rechner ausgeführt werden sollen, verringert die Auswahlmöglichkeiten der Zielplattform und damit die Plattformunabhängigkeit. Soll eine Plattform verwendet werden die keine.net-unterstützung anbietet, muss zur Ausführung eine zusätzliche.net-laufzeitumgebung organisiert werden (wie z.b. Mono [Nov]). Durch diese externe Laufzeitumgebung können neue Probleme der Interoperabilität und Kosten entstehen. 34

43 3.5 Strategie Manuelle Migration 3.5 Strategie Manuelle Migration Die Strategie Manuelle Migration sieht eine von Grund auf manuelle Neuimplementierung des Quellcodes in der neuen Zielsprache vor. Bei der Migration von.net zu Java würde das bedeuten, dass der.net-quellcode analysiert wird, um dann äquivalent in Java geschrieben zu werden. Bevor automatisierte Unterstützungen für Migrationen auf den Markt kamen, war die manuelle Migration die einzige Möglichkeit Software zu migrieren Ansatz Die Idee der manuellen Migration ist eine komplette Neuimplemetierung der zu migrierenden Anwendung. Da keine automatische Migration stattfindet, ist es für die manuelle Umsetzung einer bestehenden Anwendung in einer neuen Programmierumgebung wichtigste Voraussetzung, die Inhalte des Quellcodes der zu migrierenden Anwendung verstehen zu können. Um eine exakte Umsetzung in der Zielsprache zu gewährleisten, ist es unausweichlich, dass der Quellcode bis ins kleinste Detail richtig interpretiert wird. Wenn die ursprünglichen Programmierer der zu migrierenden Anwendung unterstützend bei der manuellen Migration mitwirken oder die Migration selber durchführen, ist eine korrekte Interpretation des Quellcodes meist sicher gestellt. Ist diese Unterstützung jedoch nicht gegeben, ist man auf andere Hilfsmittel angewiesen. Im bestmöglichen Fall ist eine gute Dokumentation des Quellcodes vorhanden. Nur dann kann das Verständnis des Quellcodes schnell angeeignet werden. Ist keine ausreichende oder eine unklare Dokumentation vorhanden, muss mit anderen Mitteln versucht werden, das notwendige Verständnis zu schaffen, um Missinterpretationen des Quellcodes vorzubeugen. Nur bei strukturiert verfassten kleineren Anwendungen kann dieses Wissen auch intuitiv angeeignet werden. Steckt hinter der zu migrierenden Anwendung aber ein umfangreicher unstrukturierter Quellcode, ist es schwer, ohne Hilfestellung ein vollständiges Verständnis zu erlangen. In allen diesen Fällen wird Reverse Engineerings betrieben. Reverse Engineering versucht, mit bewährten Methodiken den Quellcode zu analysieren, um eine Struktur- und Verhaltensbeschreibung auf höherem Abstraktionslevel zu erhalten. Beschreibungen von Reverse Engineering-Ansätzen können der Fachliteratur entnommen werden ([Ing94], [Hos96] und [LH94]). Unter anderem wurde auch ein Ansatz an der Universität Paderborn entwickelt (vgl. [NSW + 02]). Es wurde eine Werkzeug erstellt, welches den Anwender dabei unterstützt, Quellcode zu verstehen. Mit dem Werkzeug werden halb- 35

44 3 Migrationsstrategien automatisch Ausprägungen von zuvor spezifizierten Design Patterns im Quellcode erkannt und ausgewertet Umsetzung Die Umsetzung einer manuellen Migration ist mit verschiedenen Vorgehensweisen möglich. So kann z.b. unterschieden werden, ob die Struktur der zu migrierenden Anwendung für die Zielanwendung erhalten bleiben oder eine neue Struktur gewählt werden soll. Die beiden Kernpunkte sind jedoch bei jeder manuellen Migration gleich. Als Erstes muss der zu migrierende Quellcode verstanden werden und als Zweites in der Zielsprache manuell implementiert werden. Zur Unterstützung des manuellen Migrationsprozesses können z.b. Modellbasierte Verfahren eingesetzt werden, die das Generieren von Quellcode aus Modellen möglich machen und die Entwicklung eventuell beschleunigen können. Abbildung 3.7: Zielarchitektur der Strategie Manuelle Migration Wenn die manuelle Migration erfolgreich abgeschlossen ist, erhält man als Resultat Java-Quellcode. Dieser erfüllt in der Ausführung die gleichen Funktionen, wie die ursprünglich zu migrierende.net-anwendung. Der Java-Quellcode kann dann auf jeder Plattform ausgeführt werden, die eine Java-Laufzeitumgebung besitzt. Die daraus resultierende Zielarchitektur ist in Abbildung 3.7 dargestellt. 36

45 3.5 Strategie Manuelle Migration Erfüllung der Kriterien Migrationsaufwand Im Vergleich zu automatisierten Methoden hat die manuelle Migration einen sehr hohen Migrationsaufwand. Durch die großen Differenzen zwischen.net und Java gestaltet sich die manuelle Migration sehr schwierig. Außerdem dauert ein manueller Prozess verständlicherweise länger als ein äquivalenter automatischer Prozess. Die Anzahl der Mannjahre kann bei entsprechend großem Quellcode in die Jahrzehnte gehen. Die Firma Sun nimmt in einer Publikation an, dass ein normaler Entwickler Zeilen Programmcode am Tag schreiben kann, abhängig von der Komplexität. Will man nun eine typische Enterprise-Applikation mit Zeilen Programmcode manuell neu schreiben, werden dazu 40 Mannjahre oder mehr benötigt [Inc07]. Der enorm hohe Migrationsaufwand ist der größte Nachteil der Strategie. Wartungsaufwand Der Wartungsaufwand nach der manuellen Migration kann aus zwei Perspektiven betrachtet werden. Möchte man nach der Migration nur noch die Java-Variante der Anwendung nutzen, kann diese standardmäßig gewartet werden. Dabei fällt normaler Wartungsaufwand an. Sollen jedoch die.net- und die Java-Variante weiterhin genutzt werden, so entsteht ein doppelter Wartungsaufwand. Im Gegensatz zu den Strategien Cross Compiler und Cross Plattform kann keine Single-Source-Basis zur Wartung dienen, sondern es ist zwingend notwendig, mit einer Multi-Source-Basis (.NET und Java) zu warten. Daher müssen alle gewünschten Änderungen sowohl am.net-quellcode als auch am Java-Quellcode vorgenommen werden. Daraus entsteht zusätzlicher Aufwand in der Beibehaltung der Äquivalenz zwischen den zwei Varianten der Anwendung. Es muss darauf geachtet werden, dass die beiden Anwendungsvarianten sich gleich verhalten bzw. die gleiche Funktionalität bieten. Effizienz der migrierten Anwendung Die durch die manuelle Migration erstellte Java-Anwendung ist in keiner Weise mehr von.net abhängig und kann so auf zusätzliche.net- oder sonstige Laufzeitkomponenten verzichten. Die erstellte Anwendung ist eine unabhängige Java-Anwendung und verhält sich wie alle Anwendungen, die in einer Java- Programmierumgebung erstellt wurden. Java-Anwendungen haben allerdings, da sie von der VM interpretiert werden, in den meisten Fällen längere Laufzeiten als 37

46 3 Migrationsstrategien Anwendungen im nativen Binärcode (wie z.b. innerhalb vom.net-framework erstellte Binaries). Plattformunabhängigkeit Durch die Erstellung einer reinen Java-Anwendung erhält man eine Lösung mit hohem Grad an Plattformunabhängigkeit. Die einzige Anforderung an die Zielplattform ist die Lauffähigkeit einer Java VM. Da diese Eigenschaft auf sehr viele Plattformen zutrifft, sind die Einsatzmöglichkeiten der migrierten Anwendung sehr groß. Erhalt der Benutzerschnittstelle Die Umsetzung der Benutzeroberfläche der zu migrierenden Anwendung wird auf Grund der Unterschiede der Programmierumgebungen.NET und Java nicht exakt möglich sein. Trotzdem lassen sich die für den Endnutzer gewohnten Strukturen der Oberflächen ähnlich in Java nachbilden. Somit wird die Benutzerschnittstelle zumindest in Teilen erhalten Weitere positive und negative Aspekte Als einzige der hier vorgestellten Strategien ist die Strategie Manuelle Migration in jedem Fall frei von Abhängigkeiten zusätzlicher Laufzeitkomponenten. Die erstellte Java-Anwendung hat keinen Bezug mehr zu.net und ist daher auf keine zusätzliche.net-unterstützung angewiesen. Das erleichtert die Wahl der Zielplattform und vermeidet die Gefahr, dass die Laufzeitumgebung nicht alle für die Ausführung der Anwendung nötigen Funktionen zur Verfügung stellt. Diese Unabhängigkeit ist ein weiterer positiver Aspekt der Strategie. Ein negativer Aspekt der Strategie ist die bereits erwähnte Abhängigkeit vom detaillierten Verständnis des zu migrierenden Quellcodes. Bei den Strategien mit automatisierten Migrationsmethoden ist kein vollständiges Verständnis des Quellcodes notwendig. Für eine manuelle Migration muss jedoch jeder einzelne Befehl im Kontext der Anwendung verstanden werden. Ist der Quellcode einer Anwendung durch schlechte oder nicht vorhandene Dokumentation schwer nachzuvollziehen, kann dies zu Missinterpretationen und somit einer falschen Umsetzung in der Zielsprache führen. Außerdem ist bei der Durchführung der manuellen Migration Expertenwissen notwendig, zum einen von der Programmiersprache, in der die zu migrierende Anwendung implementiert ist, als auch der Java-Programmierung. So sind die Anforderungen an die Personen, die eine solche Migration durchführen können, größer als bei den Strategien, die ohne erweiterte Java-Kenntnisse auskommen. 38

47 4 Entscheidungsprozess Im folgenden Kapitel wird ein Prozess beschrieben, wie die bestmögliche Strategie bei definierten Rahmenbedingungen gefunden werden kann. Zuerst werden die bisherigen Erkenntnisse aus dem letzten Kapitel, die eine Entscheidung beeinflussen, in übersichtlicher Form dargestellt und zusammengefasst. Dadurch sind ein Vergleich und eine Abwägung zwischen den Strategien möglich. Im Anschluss wird ein allgemeiner Weg aufgezeigt, wie bei einem Entscheidungsprozess vorgegangen werden sollte. An Hand der praktischen Grundlage dieser Arbeit (siehe 2.2) wird dann ein Entscheidungsprozess für eine gegebene Ausgangslage und Zielvorstellung aufgezeigt. 4.1 Analyse der Strategien In diesem Unterkapitel werden die vier vorgestellten Strategien (mit der Umsetzung der vorgestellten Migrationswerkzeuge) noch einmal kurz aufgeführt, miteinander verglichen und in tabellarischer Form aufbereitet. Dabei werden die bedeutensten Punkte des Kapitels 3 herausgestellt, um eine Übersicht über die wichtigsten Einschränkungen und Möglichkeiten der Strategien zu geben. Der erste Unterabschnitt beschäftigt sich mit den verschiedenen Rahmenbedingungen, unter denen die Strategien angewendet werden können. Im zweiten Unterabschnitt werden die Kriterien zur Bewertung von Migrationsstrategien (vgl. 3.1) für jede Strategie nach einer Bewertungsskala beurteilt Rahmenbedingungen der Strategien Da für die Strategien in den meisten Fällen bestimmte Anforderungen erfüllt sein müssen, um sie anwenden zu können, kann so die Entscheidung, welche Strategie zur Migration gewählt wird, beeinflusst werden. Diese Rahmenbedingungen werden in einer Tabelle dargestellt (Abbildung 4.1). Dabei wird zwischen notwendig, nicht notwendig, anwendbar und nicht anwendbar unterschieden. So können der Tabelle Informationen entnommen werden, unter welchen Rahmenbedingungen Strategien angewendet werden können und welche Aspekte nicht unterstützt werden. Dies sind wichtige Hilfen für eine erste Vorentscheidung bei der Strategieauswahl. 39

48 4 Entscheidungsprozess 40 Abbildung 4.1: Tabellarische Übersicht Rahmenbedingungen der vier Strategien Abbildung 4.2: Tabellarische Übersicht Bewertung der vier Strategien

49 4.1 Analyse der Strategien Programmiersprache der zu migrierenden Anwendung Als erste Rahmenbedingung wird die Programmiersprache unterschieden, in der die zu migrierende Anwendung implementiert ist. Die wichtigen Erkenntnisse sind dabei bei den Strategien Cross Compiler und Cross Plattform zu betrachten. Bei der Strategie Cross Compiler werden nur die Programmiersprachen C# und VB von dem bei der Strategie genutzten Migrationswerkzeug Mainsoft for Java EE unterstützt. Eine Migration mit einer C++-Anwendung ist nicht möglich. Bei der Strategie Cross Plattform ergibt sich das umgekehrte Szenario. Das in der Strategie verwendete Migrationswerkzeug Mainsoft for UNIX and Linux unterstützt nur die Programmiersprache C++. Für die Strategien Schnittstellen und Manuelle Migration ist die Art der Programmiersprache im.net-framework nicht von Bedeutung, da sie alle unterstützen. Mit der Strategie Schnittstellen können aus jeder in.net erstellten Anwendung Stellvertreterklassen erzeugt werden. Die manuelle Migration kann für jede Programmiersprache angewendet werden, da kein Werkzeug verwendet wird und somit keine Einschränkungen bei der Programmiersprachenwahl existieren. Art der zu migrierenden Anwendung Als zweite Rahmenbedingung wird bei der Art der Anwendung zwischen Webund Serveranwendungen (in der Tabelle unter Webanwendungen zusammengefasst) sowie Desktopanwendungen unterschieden. Desktopanwendungen decken dabei alle Anwendungen ab, die keine Web- oder Serveranwendungen sind. Einschränkungen sind nur bei der Strategie Cross Compiler vorhanden. Die drei anderen Strategien unterstützen beide Varianten von Anwendungsarten. Das Migrationswerkzeug Mainsoft for Java EE, welches bei der Strategie Cross Compiler genutzt wird, ist für Web- und Serveranwendungen konzipiert. Desktopanwendungen nutzen gerade bei der Benutzeroberfläche eine andere.net- Funktionalität als Web- und Serveranwendungen. Da dieses Migrationswerkzeug ausschließlich für Web- und Serveranwendungen konzipiert wurde, werden unter anderem die.net-funktionen für Desktopanwendungsoberfächen nicht unterstützt. Das bedeutet, dass Mainsoft for Java EE keine vollständige Migration einer Desktopanwendung ermöglicht. Es können jedoch Teile einer Desktopanwendung mit dem Werkzeug migriert werden, da.net-funktionalitäten von Web- und Serveranwendungen auch bei Desktopanwendungen vorkommen können. Aus diesem Grund wurde das betroffene Feld in der Tabelle mit nur begrenzt anwendbar ausgefüllt. Die Gründe, warum es mit Mainsoft for Java EE im Gegensatz zu Mainsoft for UNIX and Linux nicht möglich ist, vollständig eine Desktopanwendung zu migrieren, sind kommerzieller und rechtlicher Natur. Für Mainsoft for UNIX 41

50 4 Entscheidungsprozess and Linux kaufte Mainsoft tausende Zeilen Windows-Quellcode und das Recht diese zu nutzen, um die Migration einer Desktopanwendung zu ermöglichen (z.b. durch die Umsetzung von.net-gui-komponenten für die angebotenen Zielplattformen) [Cor]. Für Mainsoft for Java EE wurden offensichtlich nicht die notwendigen Rechte erkauft, um eine Desktopanwendung vollständig zu migrieren. Nur die.net-bibliotheken ASP.NET und ADO.NET sind für die Migration verfügbar. Notwendigkeit von zusätzlichen Laufzeitkomponenten Bei dieser Rahmenbedingung wird unterschieden, ob zusätzliche Laufzeitkomponenten notwendig sind. Diese Laufzeitkomponenten stellen auf den Zielplattformen.NET-Dienste zur Verfügung, die für eine Ausführung der migrierten Anwendung auf der Zielplattform nötig sind. Nur bei der Manuellen Migration kann davon ausgegangen werden, dass keine zusätzlichen Laufzeitkomponenten benötigt werden. Bei den beiden Mainsoft- Strategien Cross Compiler und Cross Plattform, sind definitiv Laufzeitkomponenten notwendig. Allerdings sind diese im Softwarepaket der Migrationswerkzeuge der jeweiligen Strategie integriert. Bei der Schnittstellen -Strategie ist das Szenario ein anderes. Die Notwendigkeit von Laufzeitkomponenten hängt von der gewählten Zielarchitektur ab, bzw. von dem gewählten Werkzeug, um die Schnittstellen umzusetzen. Es soll zum Beispiel bei Verwendung von IIOP.NET der.net- und der Java-Teil der Anwendung auf zwei verschiedenen Rechnern ausgeführt werden und zwischen beiden Teilen per Netzwerk kommuniziert werden. In diesem Fall sind keine zusätzlichen Laufzeitkomponenten notwendig, solange der Rechner, auf dem der.net-teil ausgeführt wird, auch ein Windowsrechner ist. Sieht die Zielarchitektur allerdings vor, beide Teile auf einem Rechner auszuführen, der keine.net-unterstützung hat, müssen zusätzliche Laufzeitkomponenten organisiert werden, die dann auf dem Zielrechner installiert werden müssen. Möglichkeit der Wartung mit Single-Source-Basis Die nächste Rahmenbedingung, bei der sich die Strategien unterscheiden, ist die Art der Wartung. Bei dem Wunsch der Beibehaltung, sowohl der.net-variante als auch die durch die Migration erstellte Java-Variante der Anwendung, müssen beide Varianten gewartet werden. Um eine doppelte Wartung und den damit verbundenen doppelten Wartungsaufwand für beide Varianten zu vermeiden, ist die Wartung mit Single-Source-Basis die bestmögliche Wartungslösung. Bei der Wartung mit Single-Source-Basis muss nur eine Variante manuell gewartet werden. Die zweite Variante ist automatisch aktuallisiert, wenn die Migration erneut durchgeführt wird. 42

51 4.1 Analyse der Strategien Eine solche Wartung ist mit den Strategien Cross Compiler und Cross Plattform möglich. Beide können per Single-Source-Basis innerhalb von.net gewartet werden, um dann per Migrationswerkzeug automatisch die gewartete Java-Zielanwendung zu erstellen. Die beiden anderen Strategien können nicht mit einer Single-Source-Basis arbeiten, da sie nicht die nötige Werkzeugunterstützung anbieten. So müssen.net- und Java-Teile separat gewartet werden. Anforderung an die Zielplattform Als letzte Rahmenbedingung werden die Möglichkeiten bei der Zielplattformwahl in der Tabelle aufgezeigt. Eine Sonderstellung nimmt bei dieser Anforderung nur die Strategie Cross Plattform ein. Die drei anderen Strategien stellen an die gewünschte Zielplattform nur die Anforderung, dass die Java Virtual Machine lauffähig ist. Die Strategie Cross Plattform unterstützt, wie schon im Unterkapitel 3.3 beschrieben, nur bestimmte Plattformen. Daher ist die Auswahl der Zielplattform auf die angebotenen eingeschränkt. Eine Liste der möglichen Zielplattformen kann im Abschnitt eingesehen werden Bewertung der Strategien In Unterkapitel 3.1 wurden Kriterien zur Bewertung von Migrationsstrategien vorgestellt. Für diese Kriterien wurde für jede vorgestellte Strategie beschrieben, in welchem Maße sie erfüllt werden (vgl , 3.3.3, und 3.5.3). In diesem Unterkapitel wird nun eine eindeutige Benotung dargestellt. Die Kriterien werden für jede Strategie mit einer Anzahl von + und - bewertet, von der positivsten Variante ++, über eine neutrales o, bis hin zur negativsten Variante - -. Im Folgenden werden die Bewertungen vorgestellt und die Entscheidung begründet. Dabei sind die gewählten Bewertungen nur eine erste Einschätzung aufgrund der Gegebenheiten der Strategien. Sie sind aus keinen ausführlichen Tests entstanden und sind somit keineswegs als definitive Aussage anzusehen. Alle Bewertungen sind in einer Tabelle in Abbildung 4.2 übersichtlich dargestellt. Da Lizenzkosten, gerade bei Migrationen im Privatbereich oder bei kleinen Unternehmen, einen großen Stellenwert einnehmen, sind der Tabelle Informationen über den Aufwand für Lizenzen bei jeder Strategie hinzugefügt. 43

52 4 Entscheidungsprozess Migrationsaufwand Das erste Kriterium ist der Migrationsaufwand. Die Strategien Cross Compiler und Cross Plattform benötigen bei der Durchführung jeweils nur wenige manuelle Anweisungen und unterstützen so fast den gesamten Migrationsprozess automatisch. Da der Migrationsaufwand so denkbar gering ist, wird das Kriterium Migrationsaufwand bei beiden Strategien jeweils mit ++ bewertet. Bei der Strategie Schnittstellen wird der Migrationsprozess nur noch halbautomatisch unterstützt. Der Anteil der manuellen Anweisungen ist dementsprechend höher und der Migrationsaufwand damit größer. Aus diesem Grund wird die Strategie mit 0 bewertet. Bei der Manuellen Migration wird die zu migrierende Anwendung von Grund auf neu implementiert. Welchen enormen Zeitaufwand eine solche Migration hervorrufen kann, wurde im Unterabschnitt der Strategie beschrieben. Auf Grund dieses enormen Aufwands wird die negativste Bewertung - - vergeben. Wartungsaufwand Die Strategien Cross Compiler und Cross Plattform sind beide per Single-Source- Basis von.net aus wartbar. So kann, falls die.net-variante der Anwendung auch weiterhin genutzt werden soll, die Äquivalenz zwischen der.net- und der Java-Variante der Anwendung mit geringem Aufwand erhalten werden. Daher wurden beide mit + bewertet. Die Strategie Schnittstellen weist dagegen einen höheren Migrationsaufwand auf, da drei verschiedene Wartungsstellen vorhanden sind. Der.NET- und der Java-Teil der Anwendung müssen separat gewartet werden, ebenso die Schnittstellen zwischen.net und Java. Die Schnittstellen können jedoch automatisch erzeugt werden, was den Migrationsaufwand etwas minimiert. Für die Strategie Schnittstellen wurde bei Wartungsaufwand ein 0 notiert. Bei der manuellen Migration muss im Gegensatz zu den anderen drei Strategien ohne automatische Unterstützung gewartet werden. Sollen die.net- und die Java-Variante der Anwendung weiter genutzt werden, so müssen beide separat gewartet werden. Dabei ist darauf zu achten, dass die Äquivalenz zwischen den beiden Varianten nicht verloren geht. Aufgrund der vollständig manuellen Wartung ohne automatische Unterstützung wird ein - für die manuelle Migration notiert. 44

53 4.1 Analyse der Strategien Effizienz der migrierten Anwendung Im Unterabschnitt der Strategie Cross Compiler wurde durch eine Performance-Studie gezeigt, dass die migrierte Anwendung, trotz der zusätzlichen Laufzeitkomponenten, ähnlich schnell ausgeführt werden kann wie die ursprüngliche Anwendung. Daher wird dieses Kriterium für die Strategie Cross Compiler mit einem + bewertet. Auch bei der Strategie Cross Plattform wurden im Unterabschnitt Methoden beschrieben, die eine effiziente Ausführung der migrierten Anwendung unterstützen. Aus diesem Grund wird auch die Strategie Cross Plattform mit einem + bewertet. Die Strategie Schnittstellen büßt im Vergleich zu der ursprünglichen.net- Anwendung, durch das Hinzukommen von Schnittstellen und der damit verbundenen Kommunikation zwischen.net und Java, Effizienz ein. Da die hinzukommende Kommunikation der einzige negative Einfluss auf die Effizienz ist und der.netund Java-Teil mit normaler Effizienz ausgeführt werden können, wird dieses Kriterium mit 0 bewertet. Nach der Durchführung der manuellen Migration erhält man eine Java-Anwendung, die von keinen zusätzlichen Komponenten abhängig ist. Sie wird wie jede andere in Java geschriebene Anwendung ausgeführt und weist daher keine großen Effizienzverluste auf. Aus diesem Grund wurde die Manuelle Migration mit einem + bewertet. Plattformunabhängigkeit Die Strategie Cross Compiler weist aufgrund der geringen Anforderung an eine Zielplattform einen hohen Grad an Plattformunabhängigkeit auf. Die einzige Anforderung ist die Lauffähigkeit der Java VM. Daher wurde das Kriterium für die Cross Compiler -Strategie mit + bewertet. Auch die Strategie Manuelle Migration stellt nur die Lauffähigkeit der Java VM als Anforderung an die Zielplattform und wird dementsprechend auch mit + bewertet. Bei der Strategie Cross Plattform tritt hingegen der erste negativ bewertete Punkt auf. Da nur Zielanwendungen für eine jeweils festgelegte Plattform erstellt werden können, kann die erstellte Anwendung nicht auf verschiedenen Plattformen ausgeführt werden. Da allerdings gängige Plattformen unterstützt werden, kann zumindest separat für verschiedene Plattformen die Zielanwendung erstellt werden. Dieses Kriterium wird deshalb mit - bewertet. Die Strategie Schnittstellen hat zwar an die Zielplattform, auf der der Java-Teil 45

54 4 Entscheidungsprozess der Anwendung ausgeführt werden soll, nur die Anforderung einer Java VM, allerdings muss der.net-teil auf einem Windows-Rechner ausgeführt werden, was die Plattformunabhängigkeit einschränkt. Daher wird dieses Kriterium mit - bewertet. Erhalt der Benutzerschnittstelle Bei den Strategien Cross Compiler und Manuelle Migration wird die grafische Benutzeroberfläche der zu migrierenden.net-anwendung in Java umgesetzt. Auf Grund der Unterschiede zwischen.net und Java können die.net-oberflächenkomponenten nicht exakt umgesetzt werden, was den Wiedererkennungswert negativ beeinflusst. Alle sonstigen Funktionen der Benutzerschnittstelle, wie zum Beispiel Eingabeaufforderungen, bleiben dagegen auch nach der Migration in gleicher Form erhalten. Bei beiden Strategien wird Erhalt der Benutzerschnittstelle mit 0 bewertet. Bei der Strategie Cross Plattform werden alle Teile, inklusive der Benutzeroberfläche, der zu migrierenden.net-anwendung in gleicher Form bei der Zielanwendung umgesetzt. Dies ist durch die zusätzlichen Microsoft- und Mainsoft-Laufzeitkomponenten möglich. Durch die exakte Umsetztung wird der Wiedererkennungswert bewahrt. Daher wird mit ++ bewertet. Die Strategie Schnittstellen kann keine Benutzeroberflächen migrieren und ist daher für dieses Kriterium nicht bewertbar. Fazit Die hier vorgestellten Bewertungen sollten als Entscheidungshilfe zur Auswahl einer optimalen Strategie dienen. Dabei haben sich die Strategien Cross Compiler und Cross Plattform durch geringen Migrations- und Wartungsaufwand besonders positiv hervorgehoben. Leider hat der vorherige Abschnitt aufgezeigt, dass genau diese beiden Strategien den größten Einschränkungen unterliegen. In vielen Fällen können die Strategien also nicht angewendet werden. Das führt zu dem Fazit, dass es nicht möglich war, eine optimale Strategie festzulegen, die sowohl immer anwendbar als auch positiv bewertet ist. Aus diesem Grund wird im nächsten Unterkapitel 4.2 eine allgemeine Vorgehensweise beschrieben, die helfen soll, die bestmögliche Strategie für eine gegebene Ausgangslage und Zielvorstellung bei Berücksichtigung der Rahmenbedingungen und Bewertungen zu finden. 46

55 4.2 Allgemeine Vorgehensweise 4.2 Allgemeine Vorgehensweise Im vorherigen Unterkapitel 4.1 wurden Rahmenbedingungen herausgestellt, die gerade bei den beiden nach den Kriterien am besten bewerteten Strategien Cross Compiler und Cross Plattform immense Einschränkungen bedeuten. Das erschwert den Prozess, eine geeignete Migrationsstrategie für eine definierte Problemstellung zu finden. In diesem Unterkapitel wird deswegen eine allgemeine Vorgehensweise vorgestellt, die eine Entscheidungsfindung erleichtern soll. Es ist eine Anleitung, bei der Schritt für Schritt vorgegangen wird und je nach Problemstellung Entscheidungen getroffen werden müssen. Je nachdem wie entschieden wird, entwickelt sich der Prozess der Entscheidungsfindung in unterschiedliche Richtungen. Dabei wird die allgemeine Vorgehensweise in Textform präsentiert, bei der auf Grund der Entscheidungen auch im Text gesprungen werden kann. Zum besseren Verständnis und zur Übersicht wurde der Prozess auch in einem Aktivitätendiagramm in Abbildung 4.3 zusammengefasst. Die Wahl einer geeigneten Strategie wird erschwert durch die Tatsache, dass es vorkommen kann, dass eine Strategie alleine nicht angewendet werden kann. Dies wäre zum Beispiel der Fall, wenn die zu migrierende Anwendung eine Desktopanwendung ist (Strategie Cross Compiler nur eingeschränkt anwendbar), in VB implementiert ist (Strategie Cross Plattform nicht anwendbar) und eine GUI enthält (Strategie Schnittstellen nicht für GUI anwendbar). Es bleibt zwar die manuelle Migration, mit der komplett migriert werden könnte, allerdings sollte, wie bereits im Verlaufe der Arbeit dargestellt, wegen des immensen Migrationsaufwands auf die Anwendung der manuellen Migration möglichst verzichtet werden. Daraus ergibt sich die Situation, dass keine werkzeuggestützte Strategie alleine angewendet werden kann. Um trotzdem einen möglichst hohen Automatisierungsgrad zu erreichen bietet es sich an, verschiedene Strategien zu kombinieren, zum Beispiel Teile der Anwendung mit der Strategie Cross Compiler und andere Teile mit der Strategie Schnittstellen zu migrieren. Die Möglichkeit der Kombination wird im Folgenden berücksichtigt und weiter erläutert. Schritt 1: Strategie Cross Plattform anwendbar und ausreichend? Im ersten Schritt wird überprüft, ob die Strategie Cross Plattform geeignet ist und die Problemstellung löst. Dabei werden zuerst die in Unterkapitel vorgestellten Anforderungen an die Strategie überprüft. Entsprechen diese den Rahmenbedingungen der geplanten Migration, so ist die Strategie Cross Plattform prinzipiell anwendbar. Können Anforderungen an die Strategie nicht erfüllt werden, 47

56 4 Entscheidungsprozess 48 Abbildung 4.3: Aktivitätendiagramm zur allgemeinen Vorgehensweise bei einer Strategienauswahl

57 4.2 Allgemeine Vorgehensweise so kann Cross Plattform nicht angewendet werden und es kann bei Schritt 2 weitergemacht werden. Sind alle Rahmenbedingungen erfüllt, so muss als Nächstes überlegt werden, ob eine komplette Migration mit der Strategie Cross Plattform durchgeführt werden kann, und ob das Ergebnis daraus den eigenen Zielvorstellungen entsprechend ausreichend ist. Zum Beispiel, ob damit eine individuelle Anforderung eines Kunden erreicht werden kann. Wird eine Umsetzung der Migration mit Cross Plattform als ausreichend angesehen, so kann direkt bei Schritt 11 weitergemacht werden. Ist das Ergebnis nicht ausreichend, muss der Entscheidungsprozess bei Schritt 2 fortgesetzt werden. Schritt 2: Strategie Cross Compiler anwendbar und ausreichend? Im zweiten Schritt werden die gleichen Überprüfungen, die in Schritt 1 beschrieben wurden, für die Strategie Cross Compiler durchgeführt. So erfolgt zuerst die Überprüfung, ob die Strategie anwendbar ist. Da sich die Strategien Cross Compiler und Cross Plattform wegen der Rahmenbedingungen gegenseitig ausschließen ( Cross Compiler migriert nur C#- und VB-Quellcode und Cross Plattform nur C++-Quellcode), besteht nicht die Gefahr, dass auf Grund der Schrittreihenfolge Cross Plattform für eine Anwendung gewählt wird, die am effektivsten mit der Strategie Cross Compiler migriert werden könnte. Ist die Strategie nicht anwendbar, kann bei Schritt 3 weitergemacht werden. Im anderen Fall muss geprüft werden, ob eine Umsetzung auch den Zielvorstellungen entsprechend ausreichend ist. Wenn die Strategie als ausreichend angesehen wird, kann der Prozess in Schritt 11 fortgesetzt werden, sonst muss bei Schritt 3 weitergemacht werden. Schritt 3: Aufteilung des Quellcodes in Komponenten? Da dieser Schritt nur erreicht werden kann, wenn in den ersten beiden Schritten festgestellt wurde, dass weder die Strategie Cross Plattform noch die Cross Compiler -Strategie komplett angewendet werden kann (vgl. Abb. 4.3), sollte eine Kombinierung von Strategien in Erwägung gezogen werden. Um eine Kombination verschiedener Strategien bei einer Migration leichter zu ermöglichen, muss der zu migrierende Quellcode in verschiedene Komponenten eingeteilt werden. Diese Einteilung ermöglicht auch erst die Anwendung der Strategie Schnittstellen, da diese nicht alle Teile einer Anwendung migrieren kann und so mit anderen Verfahren kombiniert werden muss, um eine vollständige Migration zu ermöglichen. Die im Folgenden vorgestellte Komponenteneinteilung 49

58 4 Entscheidungsprozess basiert auf dem Internetartikel Best Practices in Migrating from.net to Linux von Laurence Moroney [Mor05]. Sollte der zu migrierende Quellcode bereits in diese Komponenten eingeteilt sein, kann direkt bei Schritt 4 weitergemacht werden. Der zu migrierende Quellcode sollte nach Laurence Moroney als lose gekoppelte Softwarearchitektur mit multiplen Komponenten umgesetzt sein. Diese Architektur wurde in Abbildung 4.4 dargestellt. Dabei soll der zu migrierende Quellcode in vier Bereiche eingeteilt werden, die jeweils einer Komponente entsprechen. Der erste Bereich der Anwendung betrifft alle Daten, auf die eine Anwendung zugreift. Dieser Bereich wird als Komponente Daten bezeichnet. In der Komponente Daten können zum Beispiel Datenbanken oder einzelne Dateien enthalten sein. Der zweite Bereich umfasst die Klassen im Quellcode, die dafür sorgen, dass die Daten innerhalb der Anwendung angesprochen werden können. Dieser Bereich wird als Komponente Datenbereitstellung bezeichnet. Ein Beispiel wären Zugriffsmethoden für eine Datenbank oder Dateien. Abbildung 4.4: Aufbau einer lose gekoppelten Softwarearchitektur mit multiplen Komponenten (vgl. [Mor05]) Der dritte Bereich des Quellcodes umfasst alle Methoden, die Berechnungen, Analysen oder Bearbeitung von Daten betreffen. Diese Komponente wird als Anwendungslogik bezeichnet. Ein einfaches Beispiel wäre die Sortierung von Werten. 50