Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

10.02.2005

Von Oracle Forms zu Java oder .NET

Von Marcel
Die technische Migration von Anwendungen, die mit "Oracle Forms" entwickelt wurden, auf moderne Plattformen hat ihre Tücken. Viele Projekte scheitern. Doch es gibt einen erfolgversprechenden Weg.

Ungewisse Zeiten für die Anwender von Oracle Forms: Die Meldungen über einen eingeschränkten Support lassen darauf schließen, dass das über 20 Jahre alte Produkt allmählich ausgemustert werden soll. Wer heute Forms produktiv einsetzt, hat somit die Qual der Wahl: In einigen Fällen dürfte es sinnvoll sein, möglichst lange an dem Entwicklungswerkzeug festzuhalten, für viele Benutzer bietet sich aber auch die Option, eine Technologie-Migration in Angriff zu nehmen. Doch wie ist ein Wechsel von Forms zu Java oder .NET am besten zu meistern?

Aus Sicht des Anwenders müsste es ganz einfach sein, schließlich gibt es eine exakte Vorlage: die bestehende Applikation. Sie steht seit geraumer Zeit produktiv im Einsatz, und man kennt ihre Eigenheiten, Stärken und Schwächen. Die neue Applikation soll im Wesentlichen gleich funktionieren, aber auf Basis einer anderen Softwaretechnik. Unter diesen Umständen sollte eine Migration eigentlich kein Problem darstellen.

Der Softwareentwickler sieht dies völlig anders. Java und .NET sind im Gegensatz zu Forms objektorientierte Techniken, die auf die heute üblichen Mehrschichtenarchitekturen ausgerichtet sind. Damit ändert sich so ziemlich alles, was den Aufbau und das Design der Applikation betrifft. Da aber die Investitionen, die in die bestehende Lösung eingeflossen sind, nicht einfach verloren gehen dürfen, muss möglichst viel der bestehenden Applikation in die neue Umgebung hinübergerettet werden. In der Konsequenz verfolgen viele Migrationsprojekte codegestützte Lösungsansätze. Man versucht, Teile der bestehenden Applikation zu extrahieren und zu übersetzen, so dass sie in die Zielapplikation integriert werden können.

Ein codebasierendes Migrationsprojekt verfolgt typischerweise einen Weg, auf dem lediglich die verwendete Softwaretechnik und die Architektur ersetzt werden. Die Funktionalität und die Konzeption der Applikation sowie das zugrunde liegende Datenmodell werden nicht verändert. Außerdem besteht die Absicht, die Migration möglichst nahe an der Technik, das heißt codeorientiert, vorzunehmen.

Zur Unterstützung solcher Projekte werden oft Transformationsroutinen eingesetzt. Einige solche Software-Tools sind sogar auf dem Markt erhältlich. So gibt es beispielsweise Produkte, die die Struktur von Oracle-Forms-Modulen in Oracle-ADF-Klassen überführen (ADF steht für Application Development Framework: eine Sammlung technischer Frameworks zur Unterstützung von Java-Applikationen. Sie werden zusammen mit Oracles Jdeveloper 10g zur Verfügung gestellt). Sie versprechen damit eine hohe Produktivität für die Migration von Forms in eine Oracle-orientierte Java-Applikation.

Codebasierende Migrationsprojekte sind jedoch nur selten erfolgreich. In vielen Fällen erweist sich schon nach kurzer Zeit, dass die Strategie des reinen Technik- und Architekturaustauschs nicht eingehalten werden kann. Erkennbar wird dies an einer zunehmenden Anzahl unvermeidlicher Ausnahmen und Kompromisse. Dazu gehören Änderungen der Funktionalität, der Konzeption oder des Datenmodells, also genau jener Stellen, die eigentlich unangetastet hätten bleiben sollen. Hinzu kommen Komponenten, bei denen eine codeorientierte Migration aufgrund der Komplexität nicht gelingt oder zu unsicher erscheint.

Problemen auf den Grund gehen

Oft sind Projektbeteiligte auch nach dem Scheitern solcher Vorhaben nicht in der Lage, die wahren Ursachen für die Probleme auszumachen. Damit dies gelingt, muss man sich zunächst ein klares Bild davon verschaffen, wie sich Applikationen konzeptionell zusammensetzen.

Forms-Lösungen sind üblicherweise Anwendungen, die man der Kategorie der betrieblichen Informationssysteme zuordnen kann. Das Spektrum dieser Anwendungen ist äußerst vielfältig. Grundsätzlich weisen sie aber einige in diesem Zusammenhang relevante Gemeinsamkeiten auf: Sie verwalten Datenbestände mit komplexen Strukturen, wobei für die Speicherung der Daten meist relationale Datenbanksysteme eingesetzt werden. Außerdem werden sie von mehreren Anwendern benutzt, die unter Umständen von unterschiedlichen Orten gleichzeitig auf die Applikation zugreifen. Schließlich umfassen sie eine große Anzahl an Benutzermasken und Auswertungen.

Die Logik eines betrieblichen Informationssystems lässt sich in vertikale und horizontale Funktionen aufteilen. Als vertikal bezeichnet man die Applikationslogik, die sich mit der konkreten Fachlichkeit des Systems befasst. Unter horizontale Funktionalität fällt hingegen alles, was als Applikationsinfrastruktur betrachtet werden kann. Dies sind Basis- und Querschnittsfunktionen wie Sicherheit, Konfiguration, Mehrsprachigkeit, Mandantenfähigkeit, Kontextvariablen, Historisierung und andere. Hinzu kommt Programmlogik, die ausschließlich aufgrund der eingesetzten Technik benötigt wird. In Oracle Forms wird zum Beispiel oft PL/SQL-Code gebraucht, um die korrekte Navigation zwischen Feldern, Blöcken, Bildschirmseiten und Fenstern sicherzustellen.

Die horizontale Funktionalität bildet eine Art Fundament für die Applikation. Aufgrund der beschriebenen Gemeinsamkeiten von betrieblichen Informationssystemen sind die horizontalen Funktionen verschiedener Systeme oft vergleichbar. Fasst man sie zusammen, lässt sich auch von einem Applikations-Framework sprechen.

Hier ein Beispiel dafür, wie vertikale Funktionen mit den horizontalen, also dem Applikations-Framework zusammenwirken: Angenommen, das Applikations-Framework enthält Komponenten für Konfigurationsdaten, Exception Handling, Zugriffskontrolle und Session-Variablen. Die Komponenten stellen ihre Dienste in Form von technischen Schnittstellen der restlichen Applikation zur Verfügung. Auf der fachlichen Seite enthält die Applikation eine Komponente für die Adressverwaltung. Diese muss neben der Fachlogik auch sicherstellen, dass die notwendige Querschnittslogik ausgeführt wird. Zu diesem Zweck ist sie auf die Dienste des Applikations-Frameworks angewiesen. Was für die Adressverwaltung gilt, gilt gleichermaßen für andere Fachkomponenten der Applikation.

Veraltete Querschnittsfunktionen

Die Unterscheidung von horizontaler und vertikaler Logik führt zu einer zentralen Erkenntnis in Bezug auf codebasierende Migrationen: Die Anforderungen an die Fachkomponenten werden vom Geschäftsprozess geprägt und ändern sich im gleichen Maß wie das geschäftliche Umfeld der Applikation. Hingegen werden die Anforderungen an das Applikations-Framework vor allem von technischen Rahmenbedingungen beeinflusst wie zum Beispiel der verwendeten Softwaretechnik oder dem Systemumfeld.

Ändern sich fachliche Anforderungen an ein produktives System, führt dies üblicherweise dazu, dass die betroffenen Fachkomponenten im Rahmen der Systemwartung angepasst werden. Horizontale Logik wird dagegen nach der Produktivsetzung einer Applikation nur selten geändert. Dies hat meistens zur Folge, dass eine abzulösende Forms-Applikation zwar fachlich Up to date ist, aber veraltete Querschnittsfunktionalität enthält, die nicht ohne weiteres in eine neue Technik überführt werden kann. Eine codebasierende Migration ist also in diesem Fall nicht realistisch.

Logische Schichten

Neben der eher konzeptionellen Gliederung in vertikale und horizontale Logik gibt es eine technische Sicht, die ebenfalls zur Erklärung der Migrationsprobleme beiträgt. Die Applikationslogik eines betrieblichen Informationssystems - unabhängig davon, ob vertikal oder horizontal - lässt sich technisch in verschiedene funktionale Schichten aufteilen. Man spricht dabei von Layer.

Eine häufig verwendete Sichtweise verwendet fünf Layer: Der Präsentations-Layer ist für die Darstellung der Daten auf der Benutzeroberfläche und die Kontrolle der Benutzereingaben verantwortlich, der Applikations-Layer steuert die Ablauflogik der Applikation, der Business-Layer enthält die objektbezogene Applikationslogik, der Datenzugriffs-Layer kapselt die Lese- und Schreiboperationen auf die Datenbank, und der Persistenz-Layer schließlich kontrolliert die Datenablage.

Die Layer eines Forms-Moduls

Ein Oracle-Forms-Modul deckt die ersten vier Layer ab. Für das Layout der Benutzermasken und die einfache Datenzugriffslogik stellt Forms deklarative Konzepte zur Verfügung. Deklarativ bedeutet, dass die betreffende Logik in der Forms-Entwicklungsumgebung mit Hilfe von Eingabemasken und Wizards beschrieben werden kann, an diesen Stellen also kein Programmcode benötigt wird. Die Layout-Definitionen werden als so genannte Canvases im Forms-Modul abgelegt, die einfachen Datenzugriffe als Data Blocks und LOVs (List of Values). Auf diese Weise werden Teile der Präsentations- und Datenzugriffs-Layer abgedeckt. Die restliche Logik wird in erster Linie prozedural, das heißt in Form von PL/SQL-Programmcode implementiert. Der PL/SQL-Code wird dabei auf Codefragmente an verschiedenen Stellen im Forms-Modul verteilt. Nicht selten enthält ein einzelnes PL/SQL-Fragment eine Mischung verschiedener Schichten und eine Mischung von vertikaler und horizontaler Applikationslogik.

Verglichen mit Oracle Forms wird die Applikationsschichtung in Java- oder .NET-Applikationen viel strikter vollzogen. Dies wird bei einer codebasierenden Migration zur Herausforderung, weil die betreffenden Programmteile analysiert, in entsprechende Teile zerlegt und dem korrekten Layer im Zielsystem zugeordnet werden müssen. Ohne Kenntnisse der inhaltlichen Programmlogik ist das kaum möglich. Für codebasierende Migrationen stellt dies ein ernst zu nehmendes Problem dar.

Betrachtet man die Schwierigkeiten, die mit einer codebasierenden Migration verbunden sind, stellt sich die Frage, ob nicht andere Vorgehensansätze mehr versprechen. Tatsächlich zeigt die Erfahrung, dass es in der Regel sinnvoller ist, wenn man die Migrationsstrategie anhand der konkreten Anforderungen an die vertikale und horizontale Applikationslogik bestimmt. Was bedeutet das in der Praxis?

Erinnern wir uns an einige Einsichten, die wir im Zusammenhang mit der horizontalen Applikationslogik gewonnen haben: Betriebliche Informationssysteme haben trotz ihres breiten fachlichen Spektrums viele Gemeinsamkeiten. Vor allem die horizontale Funktionalität lässt sich oft von System zu System vergleichen. Dies ist darauf zurückzuführen, dass sie nicht vom Geschäftsprozess, sondern von allgemeinen und technischen Anforderungen beeinflusst wird. Gerade deshalb trifft man bei abzulösenden Forms-Applikationen häufig auf veraltete Querschnittsfunktionalität, die in der neuen Lösung nicht wiederverwendet werden kann.

Aufgrund dieser Erkenntnisse erscheint es also sinnvoller, die Querschnittsfunktionalität einer modernen Applikation zu übernehmen und individuell anzupassen, anstatt die horizontale Logik der bestehenden Forms-Applikation zu migrieren. Die Voraussetzung dafür ist natürlich, dass eine entsprechende Applikationsvorlage verfügbar ist und weitgehend den systemtechnischen Anforderungen entspricht. Verfolgt man diesen Ansatz, wird ein erheblicher Teil der bestehenden Applikationssubstanz nicht mehr benötigt und die neue Applikation kann unmittelbar mit einem bereits funktionierenden Applikations-Framework starten. Je nach Applikationscharakter kann der Anteil horizontaler Logik durchaus 50 Prozent oder mehr betragen, wenn man den Anteil des PL/SQL-Codes dazuzählt, der nur in Oracle Forms benötigt wird (zum Beispiel PL/SQL-Triggers für die Navigation zwischen Feldern, Blocks, Pages etc.).

Migration der vertikalen Logik

Steht eine passende Applikationsvorlage zur Verfügung, bleibt noch die Frage, wie die vertikale Logik am besten migriert wird. Nach heutigen Erkenntnissen kann diese Frage nicht einheitlich beantwortet werden. In den meisten Fällen empfiehlt sich aber eine logische Migration. Dabei wird die vertikale Logik anhand der bestehenden Applikation konzeptionell aufgenommen und in geeigneter Form neu implementiert. Was zunächst nach einem beträchtlichen Aufwand klingen mag, hat sich in der Praxis als durchaus effizient erwiesen, sofern geeignete Verfahren eingesetzt werden. Außerdem bleibt bei diesem Ansatz Raum für neue oder geänderte Anforderungen, was erfahrungsgemäß gerne genutzt wird.

Eine Ausnahme bilden größere, fachlich orientierte PL/SQL-Blocks, die typischerweise in Stored Procedures oder Forms-Libraries abgelegt sind. Die Migrationsstrategie für Komponenten dieser Kategorie hängt davon ab, ob und in welcher Qualität die Anforderungen und die Konzeption dokumentiert sind. Bei mangelhafter Dokumentation empfiehlt es sich, den existierenden Code zu analysieren und gegebenenfalls zu transformieren. Dies kann allerdings recht anspruchsvoll sein und sollte deshalb auf keinen Fall unterschätzt werden.

Geeignetes Projektvorgehen

Mit einer geeigneten Applikationsvorlage und einem geeigneten Verfahren zur Übernahme der vertikalen Logik ist schon einiges erreicht. Der Projekterfolg ist damit aber noch nicht gesichert. Damit am Ende des Projekts die neue Lösung dem Betrieb übergeben werden kann, muss gewährleistet sein, dass sie die fachlichen und betriebstechnischen Anforderungen gleichermaßen erfüllt wie die existierende Applikation. Kurioserweise ist es im Detail nicht immer einfach, alle im bestehenden System umgesetzten Anforderungen vollständig zu erkennen. Deshalb muss im Rahmen eines Migrationsprojekts immer wieder mit Überraschungen gerechnet werden. Aus diesem Grund hat es sich in der Praxis bewährt, Migrationsprojekte auf der Basis einer agilen Vorgehensmethode zu betreiben. Die Spezialität agiler Methoden besteht darin, auf neue Erkenntnisse und sich ändernde Anforderungen optimal reagieren zu können, ohne die Kontrolle über die Erfolgsfaktoren des Projekts zu verlieren. Bekannte Vertreter agiler Methoden sind zum Beispiel Extreme Programming (XP) oder Scrum. Für Migrationsprojekte empfiehlt es sich, den Gedanken dieser Methoden in adaptierter Form einzusetzen.

Iterationszyklen führen zum Ziel

Der Einsatz einer agilen Methode führt unter anderem dazu, dass die Zielapplikation im Rahmen von Iterationszyklen schrittweise aufgebaut wird. Es werden immer nur die aktuell behandelten Systemteile übernommen. Dies erhöht die Übersichtlichkeit und verringert die Komplexität. Zu den betroffenen Applikationsteilen erfolgt jeweils eine Ist-Soll-Analyse. Eine Problemanalyse, wie sie bei Neuentwicklungen benötigt wird, erübrigt sich, weil ja die bestehende Applikation als Vorgabe verwendet werden kann. Bei der Ist-Soll-Analyse werden das zugrunde liegende Datenmodell, die verwendeten Forms- und Reports-Module mit der darin enthaltenen Business-Logik sowie andere betroffene Komponenten in einem Dokument festgehalten. Der Anwender prüft daraufhin die Vollständigkeit und Korrektheit der Angaben. Außerdem kann er bei dieser Gelegenheit Änderungswünsche anbringen.

Anhand dieser Grundlage wird die vertikale Funktionalität übernommen und in das vorhandene Applikations-Framework des Zielsystems integriert. Zudem werden die Daten vom bestehenden in das neue System migriert und begleitende Komponenten wie die Online-Hilfe oder die Installationsroutinen ausgebaut. Das Vorgehen führt dazu, dass viele Aspekte der neuen Applikation zu einem sehr frühen Zeitpunkt im Projekt sichtbar werden und somit ausreichend Reaktionszeit für Korrekturen bleibt.

Es hat sich gezeigt, dass die Kombination aus Applikationsvorlage, logischer Migration der vertikalen Logik und agiler Vorgehensmethode zu einer hohen Effizienz und zu einem geringen Risiko in Migrationsprojekten beiträgt. Eine Applikationsvorlage ermöglicht, dass bereits nach der ersten Iteration ein Release mit umfassender horizontaler Funktionalität bereitgestellt werden kann. Querschnittsfunktionen, die zu diesem Zeitpunkt noch nicht den eigentlichen Anforderungen entsprechen, lassen sich im Verlauf weiterer Iterationen mit genügend Zeitreserven modifizieren. Der schnelle Projekteinstieg, der mit Hilfe einer Applikationsvorlage möglich ist, gibt den Entwicklern sehr früh die Gelegenheit, sich mit der eigentlichen Aufgabe, der vertikalen Applikationslogik, zu befassen und zu identifizieren. Das zahlt sich aus: Denn das fachliche Verständnis der Entwickler ist eine zentrale Voraussetzung für den Projekterfolg. (ue)