DOAG News Q4-2008 | 43

Entwicklung

Im zweiten Beitrag der Artikelserie wer-den die Technologien aus ADF vorge-stellt, die sich besonders gut für Ent-wickler eignen, die bisher mit Oracle Forms gearbeitet haben. Im Zentrum steht das Framework ADF Business Components (ADF BC), das viele Ge-meinsamkeiten mit Oracle Forms auf-weist. Für eine Migration von Forms-Modulen nach Oracle ADF bietet das Framework Oracle JHeadstart eine gute Unterstützung. So können mit dem JHeadstart Forms2ADF Genera-tor Forms-Module direkt in eine ADF-Struktur transformiert werden.

Oracle Forms Roadmap und ADF

In Unternehmen existieren heutzutage viele Applikationen, die auf Basis von Oracle Forms entwickelt wurden, und

Oracle ADF – der Einstieg in die J2EE-Welt für Forms-EntwicklerKersten Mebus und Jürgen Menge, ORACLE Deutschland GmbH

Oracle Application Development Framework (ADF) wurde mit dem Ziel der einfachen Anwendbarkeit, Integration und Erweiterbarkeit unter Verwendung moderner Technologien auf Basis von JEE entworfen. Die Hauptzielgruppe von Oracle ADF sind Entwickler, die bisher mit Oracle Forms gearbeitet haben und von einer Java-Entwicklungsumgebung eine ver-gleichbar einfache Bedienbarkeit und Produktivität erwarten.

die sowohl als Client-Server- als auch als Web-basierte Dialoganwendun-gen betrieben werden. Obwohl Oracle bis mindestens 2017 den Support für das Produkt Oracle Forms garantiert (siehe www.oracle.com/technology/products/forms/pdf/10g/ToolsSOD.pdf), steht mit dem Oracle Application Development Framework (ADF) eine ergänzende und alternative Entwick-lungsplattform zur Verfügung. Beide Technologien laufen in der aktuellen Version auf Basis des Oracle Applica-tion Servers, was die Integration zwi-schen Forms und ADF auf verschie-denen Ebenen (Desktop, Middle Tier, Datenbank) erleichtert. Über den Weg der Integration ist sowohl eine Moder-nisierung als auch eine schrittweise, sanfte Migration bestehender Forms-Applikationen möglich.

Für die Entwicklungsteams erfordert dies die Einarbeitung in neue Bereiche (Java, XML etc.). Allerdings gibt es auch viele Gemeinsamkeiten zwischen der 4GL-Entwicklung mit Forms und der Arbeit mit ADF, die die Einarbei-tung erleichtern. Solche Gemeinsam-keiten bestehen unter anderem in der weitgehend deklarativen und visuellen Arbeitsweise sowie in der Verwendung von Komponenten für die Entwick-lung der Oberfläche.

Oracle ADF für Forms-Entwickler

Im ersten Teil der Artikelserie (DOAG News Q3/08, Seite 13) wurde Oracle ADF als eine Zusammenführung von mehreren Frameworks vorgestellt. Dies wirft natürlich die Frage auf, welche der Frameworks sich besonders für Entwicklungsteams eignen, die bisher vorwiegend mit Oracle Forms gearbei-tet haben. Oracle gibt dazu folgende Empfehlung, die im Developer’s Guide For Forms/4GL Developers detailliert beschrieben ist (siehe Abbildung 1).

Im Zentrum der Empfehlung steht das Framework „ADF Business Compo-nents“ (ADF BC), das auf die typische Situation von Forms-Kunden zuge-schnitten ist:

Es existiert bereits ein Datenmodell, •

das in der Datenbank relational im-plementiert ist. Häufig soll das be-stehende Datenmodell der Forms-Anwendung unverändert weiter ge-nutzt werden.Mit ADF BC wird ein relational-ori-•

entiertes Vorgehen praktiziert, das heißt, der Entwickler der Business-Abbildung 1: ADF-Empfehlung für Forms- und 4GL-Entwickler

44 | www.doag.org

Entwicklung

Service-Schicht arbeitet in seiner An-wendung nicht mit komplexen Da-tenobjekten, sondern mit einfachen Abbildungen relationaler Tabellen oder Views aus der Datenbank.

Gegenüberstellung von Oracle Forms und ADF

Wird die Architektur von Forms- und ADF-Anwendungen miteinander ver-glichen, so gibt es in beiden Architek-turen bestimmte Funktionsblöcke, die zwar unterschiedliche Bezeichnungen tragen aber eine ähnliche Funktion er-füllen (siehe Abbildung 2).

Der entscheidende Unterschied besteht darin, dass bei einer Forms-Anwendung alle Funktionsblöcke in einem Forms-Modul (und eventu-ell zugehörigen Bibliotheken) phy-sisch zusammengefasst sind. In der ADF-Anwendung verteilen sich die-se Funktionsblöcke auf verschiedene Architektur-Ebenen und damit auf eine Vielzahl von Dateien. Dies hat den Vorteil, dass einzelne Funktions-blöcke innerhalb der Gesamt-Archi-tektur ausgetauscht oder zusätzlich eingefügt werden können (beispiels-weise GUI für den mobilen Zugriff). Während die Navigation innerhalb der Forms-Applikation durch den Aufruf bestimmter Routinen (zum Beispiel CALL_FORM) ausgelöst wird, ist in der ADF-Architektur der ADF Faces Con- troller dafür verantwortlich, der mit-

tels einer speziellen Konfigurationsda-tei (faces-config.xml) den Seitenfluss der Anwendung steuert. Bei einer Än-derung der Navigation muss also nur diese Datei modifiziert werden, wäh-rend in der Forms-Anwendung die entsprechenden Aufrufe gesucht und angepasst werden müssen.

Die ADF Business Components (ADF BC)

Das Framework ADF BC wird bereits seit vielen Jahren unter anderem in der Oracle E-Business Suite verwen-det und gehört zu den ausgewählten Technologien, die im Rahmen des Projektes Fusion bei der Modernisie-rung der Standard-Software von Oracle zum Einsatz kommen. Das Framework

ist für die Persistenzierung der Daten in der Datenbank verantwortlich, im-plementiert Geschäftslogik sowie Vali-dierungen und sorgt für die Kontrolle der Transaktionen. Im Unterschied zu Oracle Forms enthält ADF BC aller-dings keinerlei Oberflächen-Elemente. In ADF BC sind drei Arten von Objek-ten wesentlich:

Entity-Objekte (EO) 1:1-Abbildung von Tabellen oder Views in der Datenbank

View-Objekte (VO) Sicht auf Entity-Objekte, die als SQL-Abfrage formuliert ist

Applikationsmodule (AM) Fassen mehrere View-Objekte zu einer Applikation zusammen; ver-antwortlich für Transaktions-Steue-rung, Locking und Pooling

Darüber hinaus können benutzerde-finierte Datentypen durch Domänen (Domains) beschrieben werden.

Mit Wizards können diese Objekte im Oracle JDeveloper aus existieren-den Tabellen oder Views in der Da-tenbank generiert werden. VO sollten allerdings jeweils für den spezifischen Anwendungsfall innerhalb einer Ap-plikation, sprich „maßgeschneidert“, erzeugt werden. So ist beispielsweise in der Reisebuchungs-Applikation eine Anzeige der bereits gebuchten Plätze erforderlich. Abbildung 3 zeigt die für das VO „Gebuchte Reisen“ erforderli-

Abbildung 2: Funktionsblöcke in Oracle Forms und ADF-Applikationen

Abbildung 3: Wesentliche Objekte der ADF Business Components

DOAG News Q4-2008 | 45

Entwicklung

che Kombination aus den EO-Buchun-gen, Katalog und Abbildung 4 die zu-gehörige SQL-Abfrage. Da die Daten in der Anwendung nur angezeigt werden sollen, wurde ein VO vom Typ Read-Only erzeugt. Diese Variante ist sehr performant, da die Abfrage (Join) ohne Nutzung der EO direkt in der Daten-bank ausgeführt wird.

Eine Validierung der Daten kann auf verschiedenen Ebenen (Domain, EO, Attribute des EO) implementiert werden. Standard-Validierungen (etwa gegen statische Wertelisten) können auf deklarativem Wege definiert wer-den. Spezielle Validierungen erfordern eine Programmierung von zusätzli-chen Java-Methoden. Für jedes EO und VO können optional folgende Ja-va-Klassen im JDeveloper erzeugt und anschließend erweitert werden:

Entity Class (EntityImpl.java)•

Entity Definition Class (Entity •

DefImpl.java)View Object Class (ViewImpl.java)•

View Row Class (ViewRowImpl.java)•

Soll zum Beispiel die E-Mail-Adresse des Kunden auf gültige Syntax überprüft werden, muss eine Methode validate-Email() in der Implementierungsklasse des EOs KundenImpl.java hinzugefügt werden.

Anschließend kann diese Methode de-klarativ beim Attribut Email des Eos-Kunden als MethodValidator ausge-wählt werden (siehe Abbildung 5).

Zusätzliche Methoden, die die VOs eines AM manipulieren, können der Implementierungsklasse des AM hinzu-gefügt werden. So wird beispielsweise durch eine Methode die Where-Klausel eines VOs zur Laufzeit modifiziert.

Data Binding

Die ADF Model-Schicht und das Data Binding wurden bereits im ersten Ar-tikel dieser Serie vorgestellt. Bei der Verwendung der ADF BC gibt es hier die Besonderheit, dass die Konfigura-tionsdateien von ADF BC direkt für das Data Binding genutzt werden und damit keine Datei DataControls.dcx existiert. Damit entfällt der sonst erfor-derliche Arbeitsschritt des Publizierens von Attributen und Methoden als Data Controls.

Entwicklung einer Oberfläche mit ADF Faces

Für die Oberflächenentwicklung ste-hen Oracle ADF Faces zur Verfügung,

Abbildung 4: View-Objekt (VO) für gebuchte Reisen

Abbildung 5: Validierungs-Methode für Attribut eines EOs

public boolean validateE-mail (String value) { return (value.inde-xOf (‚@‘) != -1 ); }

46 | www.doag.org

Entwicklung

die auf dem Standard JSF (JSR-127) ba-sieren. Die Arbeit mit Komponenten ist eine dem Forms-Entwickler vertrau-te Arbeitsweise. Zunächst werden die Komponenten deklarativ bearbeitet, erst in einer zweiten Phase sind eine Programmierung von Events oder spezifische Anpassungen notwendig. Die vereinfachte Darstellung einer JSF/ADF Faces-Architektur (siehe Abbil-dung 6) enthält grafische Komponen-ten (UI Components), die in einem bestimmten Ausgabegerät (Device) angezeigt werden können. Für die Anzeige von Anwendungen in einem Browser oder auf einem mobilen End-gerät werden unterschiedliche Device Renderer verwendet. JSF werden in der Regel durch eine JSP Page bzw. durch ein JSP-Dokument (XML Repräsentati-on einer JSP Page) dargestellt. Hierbei wird die JSF standardisiert durch ein View Tag (<f:view> ... </f:view>) be-schrieben. Die ADF-Modell-Schicht, bestehend aus ADF Binding und ADF Data Controls, sorgt innerhalb einer JSF- bzw. ADF Faces-Komponente für die automatisierte Integration der da-tengebundenen Objekte (Bindings Object). Der Zugriff auf diese Datenob-jekte wird durch die JSP Standard Tag Library (JSTL) Expression Language beschrieben, hier zum Beispiel durch #{kunde.name}. Ohne die Verwen-dung des ADF-Modells müsste die Da-tenintegration (Darstellungsansicht) programmatisch umgesetzt werden.

ADF Faces bietet eine größere Aus-wahl an Komponenten als JSF. So enthält ADF Faces zum Beispiel hier-archische Tabellen, Baum-Navigation, Tabellen mit integrierter Sortierung, partielle Seitenwiedergabe, clientsei-tige Validierungen oder Skins, um das Look und Feel einer Anwendung zu definieren. ADF Faces lassen sich weitestgehend in folgende Kompo-nententypen klassifizieren, die mit Drag & Drop in die Designoberfläche des JDevelopers gezogen werden kön-nen:

Datenkomponenten•

Komponenten für die Anzeige und Verwaltung von hierarchischen und nicht-hierarchischen Daten sowie eines Datensatz-Bereichs Eingabekomponenten•

Komponenten für die Eingabe und Auswahl von Input, Auswahllisten-Komponenten, Shuttle-Komponen-ten, Farb- und Datumsauswahl und eine Komponente für das Hochla-den von DateienLayoutkomponenten•

Komponenten für die Erstellung von Seitenlayouts (mithilfe unter-geordneter Komponenten oder ei-nes Menümodells), Panel-Kom-ponenten für das Layout anderer Komponenten oder das Ausrichten von Eingabe-Komponenten in einer Form sowie interaktive Komponen-ten, mit denen der Benutzer Inhal-te ein- oder ausblenden oder andere Komponenten auswählen und an-zeigen kann Navigationskomponenten•

Schaltflächen- und Link-Kompo-nenten für die Navigation zu einer anderen Position (mit oder ohne serverseitige Aktionen), Menü-Komponenten für das Layout und die Navigation in Menühierarchi-en sowie Prozess-Komponenten für das Vor- und Zurücknavigieren in

Abbildung 6: JSF-Architektur mit Oracle ADF

Abbildung 7: JSF-Layout-Seite für die Kundenverwaltung

DOAG News Q4-2008 | 47

Entwicklung

einem Prozess, der mehrere Schritte oder Seiten umfasst Ausgabekomponenten•

Komponenten für die Anzeige von Meldungen, Labels, formatiertem Text, HTML-formatierter Ausgabe, Objekten wie Symbole, Bilder oder Trennlinien sowie Objektmedien-Ressourcen wie Video oder Audio

Abbildung 7 zeigt beispielhaft die Ver-wendung von Layoutkomponenten. In dieser Abbildung wird für die Erstellung des Seitenlayouts eine ADF Faces Core Layoutkomponente panelPage verwen-det, die eine JSF-Seite mit vordefinier-ten Komponenten wie Menüs, Bildern, Dateninhaltsbereich etc. beschreibt. Die Dateninhalte werden, wie im Teil 1 unserer Serie erläutert, aus der Data Control Palette mittels Drag & Drop, hier als Form, in die Designoberfläche des JDevelopers gezogen (grüne Um-randungen). Einzelnen Attribut-Kom-ponenten kann innerhalb der Form ein neues Layout zugewiesen werden. So könnte zum Beispiel der Ort (#bin-dings.Ort.inputValue) nicht als Einga-betextfeld, sondern als Listbox (List of Values) dargestellt werden.

Die roten Umrandungen verdeut-lichen, wie einfach es ist, mittels der visuellen und deklarativen Möglich-keiten Mehrsprachigkeit in eine Ober-fläche zu integrieren. In sogenannten Properties-Files (Resource Bundles) wird zu einem Begriff (Schlüsselwert) der Text in der jeweiligen Sprache hinterlegt. Über eine JSF-Komponente Load Bundle (f:loadBundle) wird eines der übersetzen Resource Bundles gela-den (für Deutsch zum Beispiel: Messa-ges_de. properties). Welches Resource Bundle zur Laufzeit verwendet wird, hängt von der jeweiligen Sprachein-stellung des Browsers ab. Der Zugriff auf die übersetzten Komponenten er-folgt über die Expression Language. So bedeutet der Wert #{msg[‚pages.tab1‘]} im rot markierten TabWriter, dass der Schlüsselwert pages.tab1 aus einem Re-source Bundle verwendet werden soll. Das Resouce Bundle wird durch die Variable msg in den Eigenschaften des Load Bundles definiert. Weitere Bei-spiele für die Verwendung von Kom-ponenten stehen unter http://www.

oracle.com/technology/products/adf/adffaces/index.html.

Migration von Forms nach ADF – Oracle JHeadstart

Obwohl bei einer Modernisierung von Forms-Anwendungen die Migrati-on nicht im Fokus steht, ist die Frage nach den Möglichkeiten einer Trans-formation bestehender Forms-Modu-le, die von Werkzeugen unterstützt wird, nach ADF von großem Interesse. Allerdings sollte Klarheit über die Ziel-stellungen einer solchen Migration bestehen. Da beiden Technologien un-terschiedliche Paradigmen zugrunde liegen, gibt es auch grundlegende Un-terschiede in der Architektur der Ap-plikationen (siehe Abbildung 2). Hier liegen auch die Grenzen von Migra-tions-Werkzeugen, die den Programm-code von Forms-Modulen automatisch in Java-Klassen umsetzen. Im Ergebnis einer solchen Umsetzung entstehen Applikationen, die sowohl J2EE- als auch Forms-Kenntnisse voraussetzen – und kaum noch zu warten sind.

Einen anderen Weg geht Oracle JHeadstart, ein Framework von Oracle Consulting, zur Generierung von ADF-Applikationen. Anstelle einer Migra- tion auf der Ebene des Programmcodes wird hier die Struktur eines Forms-Moduls analysiert und in eine adäqua-

te Applikationsstruktur von Oracle ADF transformiert. JHeadstart wird als Plugin für den Oracle JDeveloper zur Verfügung gestellt, eine Testversion kann über die Check for Update-Funk-tion des JDevelopers kostenlos instal-liert werden. Aktuell generiert JHead-start folgende Bestandteile von Oracle ADF:

ADF Business Components•

ADF Binding•

ADF Faces und ADF Mobile•

Bestehende Forms-Module lassen sich auf ADF migrieren. Anstelle einer Code-Transformation wird bei JHead-start jedoch die Struktur der Forms-Module in eine adäquate ADF-Struktur umgesetzt (siehe Abbildung 8). Diese Struktur bildet eine sauber strukturier-te Basis für die Weiterentwicklung der Applikation auf der ADF-Seite. Vorhan-dener PL/SQL-Code wird als Kommen-tar in die Definition der ADF-Applika-tion übernommen und kann optional in die Datenbank generiert werden. In früheren Versionen von JHeadstart war eine Migration von Forms-Modu-len nur möglich, wenn diese im Oracle Designer als Applikations-Module defi-niert waren (JHeadstart Designer Forms Migrator). Inzwischen gibt es einen di-rekten Weg der Migration von Forms-Modulen (*.fmb) über das XML-Format

Abbildung 8: Migrations- und Generierungsprozess Oracle JHeadstart

48 | www.doag.org

Entwicklung

der Module (JHeadstart Forms2ADF Generator). Erste Tests haben erfolg-versprechende Ergebnisse gezeigt.

Bei der Migration von Forms-Modu-len auf ADF werden folgende Umset-zungen vorgenommen (siehe oben).

Fazit

Oracle ADF stellt eine Ergänzung und Alternative zur traditionellen Forms-Entwicklung dar. Werden in der Busi-ness-Service-Schicht die ADF Business Components (ADF BC) eingesetzt, er-leichtert dies dem mit Forms vertrauten Entwickler die Einarbeitung, da die ADF

BC viele Gemeinsamkeiten zu Forms aufweisen. Gegenüber Forms bietet ADF unter anderem folgende Vorteile:

Zur Laufzeit sind keine speziellen •

Voraussetzungen auf der Client-Seite erforderlichEs können Oberflächen für mobile •

Endgeräte entwickelt werdenADF beruht auf offenen Standards •

und ist in höherem Grad erweiterbar

Bestehende Forms-Module lassen sich mithilfe von Oracle JHeadstart auf ADF transformieren. Durch die automati-sierte Transformation kann der Einsatz

Oracle Forms ADF Business Components JHeadstart Application Definition

Table/View Entity Object (EO)

Column EO Attribute

Constraint Entity Constraint

Foreign Key Entity Association

Block View Object (VO) Group

Item VO Attribute Item

LOV / Record Group Read-only View Object LOV Group

Position of Items Region

Relationship View Link

Module Application Module (AM) Hierarchy of Groups

Set of Modules Nested Appl. Modules (AM) Application Definition (Service)

Checkbox Domain (Allowable Values) Domain (Allowable Values)

List Item Domain (Allowable Values) Domain (Allowable Values)

Radio Group Domain (Allowable Values) Domain (Allowable Values)

PL/SQL Logic Kommentar

des JHeadstart Forms2ADF Generators bei der Umsetzung einer großen Zahl einfacher Datenpflegemasken (CRUD-Funktionalität) aus Forms auf ADF sehr produktiv sein. In der nächsten Folge der Artikelserie werden weitere Kom-ponenten aus Oracle ADF vorgestellt, die als Alternative zu den ADF Business Components zum Einsatz kommen können und für die Persistenz inner-halb einer Anwendung sorgen.

Nützliche Links:J2EE for Forms Developers (OTN): •

http://www.oracle.com/technolo-gy/products/jdev/collateral/4gl/formsdesignerj2ee.htmlDeveloper’s Guide For Forms/4GL •

Developers: http://download.orac-le.com/docs/pdf/B25947_01.pdfOracle JHeadstart (OTN): http://•

www.oracle.com/technology/pro-ducts/jheadstartJHeadstart Step-by-Step (Tutorial): •

http://www.oracle.com/technolo-gy/products/jdev/tips/muench/jh-stutorialDeutsche ADF Community (ADF •

für Forms-Entwickler): http://www.oracle.com/global/de/community/adf/adf_forms.html

Kontakte:Michael Bräuer

michael.braeuer@oracle.comKersten Mebus

kersten.mebus@oracle.comJürgen Menge

juergen.menge@oracle.comDetlef Müller

detlef.mueller@oracle.com

Regionalgruppe NRW zu Gast bei Bayer

Beflügelt durch das herausragende Regionaltreffen im letzten Jahr in der BayArena lud Bayer Business Services auch in diesem Jahr wieder die Regionalgruppe NRW ein. Hauptthema des Abends waren die Erfahrungen bei den ersten 11g-Produktions-Datenbanken bei der Bayer AG. Andreas Stephan, Bayer Business Services, stellte die Neuerungen in 11g im Umfeld vor und gab sehr kompe-tent seinen Eindruck der Features wieder. Im Anschluss gab es noch ein Novum: Das Ehepaar Henriette und Michael Cebulla stellte Duplicate Database vor. Henriette Cebulla (Trivadis) erklärte und demonstrierte das Verhalten unter den Versionen 9i und 10g. Ihr Mann Michael (Oracle) zeigte dann ebenfalls sehr anschaulich, wie die Funktion unter 11g noch mächtiger geworden ist. Insgesamt 79 Teilnehmer freuten sich über einen sehr kurzweiligen Abend auf hohem Niveau und nutzten die Gelegenheit zum intensiven Erfahrungsaustausch. Bayer Business Services verwöhnte die Anwesenden mit einem tollen Ambiente im „Daylis“ in Langenfeld, einem sehr schönen Buffet und einer tollen Organisation vor Ort. Im Namen der Regionalgruppe NRW noch mal ein ganz herzliches Dankeschön bei den Referenten für die gelungenen Vorträge und bei Bayer BBS für die Gastfreundlichkeit.

Kontakt: Stefan Kinnen, regio-nrw@doag.org

DOAG intern