Forms und Java Integration oder Migration

Transkript

1 Mittwoch, 9. November h00, Variohalle 5 Forms Forms und Java Integration oder Migration Stephan La Rocca TEAM GmbH, Paderborn Schlüsselworte: Oracle-Forms Builder, Java, Architektur, Software-Entwicklung Einleitung Die Entwicklungsplattform Java kam langsam aber unaufhörlich in die Welt der Forms-Entwickler. Waren es am Anfang nette Schmankerl, die durch die Offenheit zur Java-Entwicklung genutzt werden konnten, kam die Erkenntnis recht schnell, dass es bei konkreten Aufgabenstellungen mehr als hilfreich ist, auf diese Technologie zurückzugreifen. Einmal mit der Materie beschäftigt, zeigt sich eine Vielzahl von Möglichkeiten und Anwendungsbeispielen der Integration von Java in Oracle-Forms. Ein weiterer Aspekt, der unmittelbar im Zusammenhang steht, ist die Frage, ob nicht eine Migration nach Java eine zu betrachtende Alternative darstellt. Immer mehr Kunden, die Oracle-Forms noch in der Client-Server-Architektur einsetzen, stellen sich die Frage, ob sie die Migration auf den Applikation-Server finanzieren, oder in andere Architekturmodelle investieren sollen. Mit dem JDeveloper und ADF besteht mittlerweile eine gewisse Produktivität und ein sich zu etablieren scheinendes Framework, doch noch haben diese Tools nicht die Effizienz von Oracle-Forms Entwicklungen erreicht. Bei der Entscheidung einer Migration stellt sich die Frage, welche Investitionen geschützt werden können. Wie sind Applikationslogiken, Modelle und Frameworks innerhalb der Forms-Applikationen auf ADF übertragbar und wie können sie projektunterstützend geleistet werden. Diese Punkte sollen in dem vorliegenden Beitrag beleuchtet werden. Anforderung Im Rahmen unserer Produktentwicklung wurden wir von Kunden angesprochen, die Anmeldung an die Applikation so zu erweitern, dass die Authentifizierung durch einen Chipkartenleser ermöglicht wird. Die Applikation lief bei dem Kunden im Umfeld des Applikation-Servers als Forms-Service. Somit hatte der einzelne Anwender einen Web-Browser; die Software musste allerdings auf die serielle Schnittstelle des Kartenlesegerätes zugreifen. Die Wahl der Werkzeuge ließ nur eine Integration von Java innerhalb der Forms-Anwendung zu. Der Zugriff auf die Informationen wurde durch eine JAVA-API des OpenCard-Consortium sichergestellt. Im Rahmen der Produktentwicklung wurde darauf aufbauend eine eigene Java-Klasse erstellt, die eine Integration als Java-Bean ermöglichte. Abb. 1: Integration einer Java-Bean in Forms

2 Benefit einer Forms-Integration Im Laufe der Produktentwicklung haben wir weitere Integrationsmöglichkeiten von Java genutzt: Cursorpositionierung bei Dossierfeldern: In Freitextfeldern ist es hilfreich, wenn bei der Navigation in das Feld die Eingabemarke am Ende des Textes erscheint, damit der Anwender seinen Text unmittelbar erfassen kann. Dazu wurde die Möglichkeit genutzt, eine bereits vorhandene Implementierungsklasse zu überschreiben. Integration von neuen Oberflächenelementen: Da die Sourcen bereits im Rahmen eines anderen Projektes vorhanden waren, konnten wir einen hierarchischen Baum, der seine Informationen aus unterschiedlichen Datenquellen bezieht, in die Oberfläche der Forms-Anwendung integrieren. Ersatz der Graphics-Komponenten: Auf Grund des Desupports für Oracle-Graphics innerhalb der Webreleases von Oracle-Forms haben wir die Grafiken, z. B. vom dispositiven Verlauf eines Artikelbestandes, auf die BI-Beans von Oracle umgeschrieben. Integration in CMSDK: Um die beiden Welten der PL/SQL-Entwicklung unter Oracle-Forms und die JAVA-API vom Oracle-CMSDK zusammenzubringen, wurde der Ansatz verfolgt, einige Grundfunktionalitäten des CMSDK in eigene Java-Klassen zu kapseln, um sie im Anschluss über den Java-Importer innerhalb von Forms mit einem PL/SQL-Mantel zu umschließen. Integration von WebServices: Als klassisches Beispiel wird hier die Integration eines Online-Währungsumrechners von Oracle benannt, der in Forms integriert werden kann. Mit Hilfe des JDevelopers wird aus dem WebService ein Java-Stub erstellt, der dann auf dem zuvor beschriebenen Wege in Forms integriert wird. Integration oder Migration Nach all diesen Möglichkeiten stellt sich die Frage nach dem richtigen Weg. Sollten alle neueren Entwicklungen durch Java implementiert und dann in Forms integriert werden? Sollte statt der Einführung des Applikation-Servers das Budget für eine Migration der kompletten Anwendung nach Java genutzt werden? Fragen, die zur Zeit sicherlich keine eindeutige Antwort ermöglichen, zumal folgende Abhängigkeiten nicht außer Acht gelassen werden dürfen: Besteht ein Handlungsbedarf innerhalb der aktuellen Applikation? Sind Funktionalitäten gefordert, die zur Zeit durch die Software nicht abgedeckt sind? Migriert mit der Applikation auch das Wissen der Entwickler? Welchen Fokus hat die Anwendung? Eine transaktionslastige Inhouse-Lösung oder eine smarter Webshop für meine Kunden? Welche Interaktionen existieren mit anderen Anwendungen? Können modulare Komponenten genutzt werden? Ist meine Anwendung Dienstleister oder Konsument? Es gibt noch eine Vielzahl weiterer Faktoren, die durchaus sehr projektspezifisch sein können und eigene Gründe mitbringen, ob eine Migration der bessere Weg ist oder nicht. Integration Fällt die Entscheidung zu Gunsten der Integration, so sind in der Systemlandschaft folgende Komponenten zu berücksichtigen: Abb. 2: Komponenten einer Koexistenz Synergie-Effekte liegen hier darin, dass auf gemeinsame Daten zugegriffen werden kann. Logik (stored procedures und packages) innerhalb der Datenbank als WebServices gekapselt auch für Java-Programme zur Verfügung gestellt werden können. Webservices von beiden Welten genutzt werden können. modulare Java-Komponenten von beiden Welten genutzt werden können.

3 Migration Fällt die Entscheidung auf eine Migration, so sind zunächst die unterschiedlichen Architekturen zu beleuchten. Um einen Vergleich zielgerichtet an einer späteren alternativen Entwicklungsumgebung zu führen, wird das Framework ADF innerhalb des JDevelopers betrachtet. Forms Gewachsen aus einer Client-Server-Landschaft Greift direkt auf das Datenbankmodell zu Nutzt PL/SQL-Packages für die Applikationslogik Nutzt Forms-Bibliotheken für modulare Client-Implementierung Layout, Navigation, Logik und Interaktionen werden in einer Datei beschrieben ADF Modulares Framework innerhalb des JDevelopers gewachsen Datenmodell unabhängig von der Datenbank ADF-BC für die Applikationslogik ADF-Controller und Struts ADF-UIX, JSF, etc. für die Gestaltung der Oberflächen Die größte Hürde neben der syntaktischen Übersetzung von Logiken in eine andere Software-Philosophie ist die Tatsache, dass bei einer Forms-Applikation die Elemente unterschiedlichster Aufgabenstellung in einer Datei gebündelt werden. Abb. 3: Hürden einer Migration Eine in diesem Umfeld unstrukturierte Software kann durch einen automatischen Migrationsprozess nicht besser werden. M?... Müll migriert zu Müll Eine Strukturierung der Forms-Applikation lässt sich erreichen, indem versucht wird, einzelne Querschnittsfunktionalitäten zu identifizieren und die passenden Pendants in der ADF-Entwicklung zu betrachten. Zu den Querschnittsfunktionalitäten gehören: Layout-Definitionen Controller Benutzerberechtigung Fehlerbehandlung Mehrsprachigkeit Layout-Definitionen Layout-Definitionen werden in Forms durch Properties an den Items und durch Layout-Objekte beschrieben. Properties können zur Laufzeit gelesen und geschrieben werden (Team-StyleGuide nutzt diese Möglichkeit, um z. B. den Anwendern ein dynamisches und individuelles Layout pro Dialog speichern zu können) Das komplette Layout eines Dialoges kann durch die Java-API oder den XML-Export ausgelesen werden.

4 In der J2EE-Entwicklung können identische Daten und identische Applikationslogiken auf unterschiedlichen Oberflächen ausgegeben werden. Präsentationslayer werden für den Entwickler zweitrangig bei Verwendung von JSF. Die Verwendung von MVC-Design-Pattern legt eine klare Trennung und Beschreibung fest. Layout-Regeln können via XML-Notationen beschrieben werden. Controller Aktionen werden direkt den grafischen Objekten zugeordnet. (z. B. der WHEN-BUTTON-PRESSED-Trigger einer Befehlsfläche. Navigationen werden durch Objektnavigator und Forms-Built-Ins bestimmt. Modularisierung durch ProTools (Menü, Button, Tastatur). Eine Möglichkeit, datengesteuert Funktionen zuzuordnen. Modularisierung durch strikte Trennung zwischen Client- und Server -Programmierung. Was gehört in ein Datenbank-Package, was in eine Forms-Bibliothek und was in ein Forms-Modul. Struts oder andere Controller übernehmen deklarativ die Zuordnung von Aktionen und Reaktionen. Benutzerberechtigung Kombination aus Rollenkonzept in der Datenbank und Benutzerberechtigung auf Menü/Funktionsebene in Forms. Es sollte eine zentrale Verwaltung der Benutzerberechtigung geben. Wird in Forms durch Menü-Sicherheit oder Trigger implementiert. Können in der J2EE-Entwicklung durch Frameworks wie JAZN implementiert werden. Optimalerweise beruhen die Methoden auf der gleichen Datenquelle (Datenbankrollen, XML, etc.) Fehlerbehandlung In der Datenbankentwicklung In den PLSQL-Blöcken In den Forms ON-ERROR-Triggern Java Exception Handling Bedürfen einer Kapselung in den Methoden und Klassen Bedürfen einer Abgrenzung zwischen den Schichten der Software-Architektur Mehrsprachigkeit Oracle-Translation-Manager (erzeugt unterschiedliche FMX) Dynamische Ersetzung zur Laufzeit (Team StyleGuide unter Berücksichtigung von Sprachtabellen.) Werden im J2EE-Umfeld in der Regel durch Resource-Bundles abgebildet. Für eine Migration einer Forms-Applikation gilt es, eine Migration der bestehenden Querschnittsfunktionalitäten zu betrachten, denn nur eine sinnvolle Umsetzung der einzelnen Punkte ergibt eine Software, die auch nach der Migration noch pfleg- und erweiterbar ist. Eine gute Struktur der Forms-Applikation erleichtert hier die Migration. Eine Vorbereitung sollte dabei folgende Punkte berücksichtigen: Klare Trennung der Applikationslogik zwischen Datenbank, PL/SQL-Bibliothek und Forms-Modul Aufruf aller applikationsspezifischen Funktionen über USER-DEFINED-Trigger Dialogwechsel-Definitionen in der Datenbank Zentrale Benutzerberechtigung und globale Umsetzung in den Dialogen Zentrale Fehlerbehandlung Datengetriebene Mehrsprachigkeit

5 Sind diese Voraussetzungen gegeben, können durch den Einsatz vorhandener Tools oder eigener Entwicklungen eine Migration der Dialoge vorangetrieben werden. Es existieren eine Reihe von Tools auf dem Markt, die eine Migration von Forms automatisieren, aber es gilt zu prüfen, ob das Ergebnis dieser Tools den Ansprüchen einer modalen J2EE-Entwicklung entspricht. Schließlich darf nicht das Ziel aus den Augen verloren werden, was durch die Migration gewonnen werden soll. Ist das Ergebnis nach dem Projekt das gleiche wie zuvor, stellt sich die Frage nach dem Sinn der Investitionen. Durch eine Integration von Java-Komponenten in die Forms-Entwicklungsumgebung geben Sie auch Ihren Entwicklern die Möglichkeit, langsam in die Java-Welt vorzustoßen. Die Projekte können klein beginnen und können mit dem Skill der Mitarbeiter wachsen. Ein Weg dahin ist auch die Möglichkeit, neue Anforderungen in Java zu entwickeln und möglicherweise Querschnittsfunktionen gemeinsam zu nutzen. Einen Aspekt möchte ich Ihnen zum Schluss noch auf den Weg geben: Auch eine Migration ist nicht mehr oder weniger als ein Projekt. Kontaktadresse: Stephan La Rocca Manager Business Development Hermann-Löns-Str. 88 D Paderborn Telefon: +49(0) Fax: +49(0) Internet: