Migrationsleitfaden Version 3.0

von .Net zur Java kann zum Beispiel das Open Source Projekt net2java 479 und für die
Migration von Java zu .Net der JLCA 480 (Java Language Conversion Assistant) von
Microsoft genutzt werden. Insbesondere JLCA ist inzwischen ein ausgereiftes Tool mit
umfangreicher Unterstützung von Microsoft, mit dem in der Regel ein Großteil des
Codes automatisiert konvertiert werden kann.
Komplizierter wird es bei Enterprise Anwendungen wie sie zum Beispiel über COM+ in
der .Net Welt und über EJBs in der J2EE Welt realisiert werden. Hier müssen die Entwickler
die Logik genau betrachten und den entsprechenden Code in der Zielsprache
neu schreiben. In der Regel ist jedoch die Migration von COM+ zu EJB problemloser als
die umgekehrte Migration, da der Funktionsumfang von COM+ eine Teilmenge der EJB
Funktionen bildet. Die Migration von EJB zu COM+ ist insbesondere dann deutlich
komplexer, wenn Funktionen verwendet werden, die in COM+ Technologie nicht enthalten
sind.
2.1.1.4 Datenzugriffsschicht
Bei der Migration der Datenzugriffsschicht werden zwei unterschiedliche Teile einer Anwendung
migriert: der Programmcode und die SQL Statements. Die Migration des Programmcodes
läuft ähnlich wie die Migration des Codes in der Logikschicht mit Hilfe von
entsprechenden Tools ab. Hier gibt es zwar Unterschiede bei den Zugriffen zwischen
ADO.NET und JDBC, diese sind jedoch nicht gravierend und bereiten in der Regel keine
größeren Schwierigkeiten. Die SQL-Abfragen bleiben unberührt, solange auf die gleiche
Datenbank zugegriffen wird. Falls auch die Datenbank migriert wird, müssen in jedem
Fall die SQL-Statements entsprechend der Syntaxunterschiede angepasst werden. Darüber
hinaus können weitere Aktivitäten notwendig sein (siehe Kapitel II.A).
Beim Einsatz von Persistenzframeworks, wie Hibernate, ist der Aufwand bei der Migration
entweder gering, falls es eine entsprechende Version dieses Frameworks auf der
anderen Plattform gibt, oder sehr hoch, falls es keine entsprechende Version gibt und
die Datenzugriffsschicht dadurch komplett neu entwickelt werden muss.
2.1.2 Migration einer verteilten Anwendung auf SOA Basis
Basiert die Anwendungslandschaft auf einer SOA Architektur, kann dies die Migration
zwischen den einzelnen Plattformen deutlich erleichtern. Falls die Anwendungen, wie für
eine SOA Archtitektur typisch, über Web Services implementiert sind, kann die Migration
in vielen kleinen Schritten erfolgen. So kann zum Beispiel ein einzelner .Net Web
Service durch einen J2EE Web Service ersetzt werden, ohne dass Änderungen in
anderen Anwendungen notwendig sind und diese entsprechend unbeeinflusst bleiben.
Die Anwendungsmodule können so nach und nach schrittweise ersetzt werden. Dadurch
erhöht sich zwar die Gesamtzahl der Migrationsprojekte, die Komplexität der einzelnen
Projekte wird jedoch deutlich reduziert. Außerdem wird das Migrationsrisiko minimiert,
indem zunächst Erfahrungen mit dem Betrieb einzelner, möglichst unkritischer Services
auf Basis der neuen Plattform gesammelt werden und diese Erfahrungen in die weiteren
479 siehe https://net2java.dev.java.net/
480 JLCA – Java Language Conversion Assistant -
http://msdn.microsoft.com/vstudio/java/migrate/jlca/default.aspx
Seite 484