Oracle ADF

Oracle ADF
Basisdaten
Entwickler	Oracle
Aktuelle Version	12.2.1.3 (31. August 2017)
Betriebssystem	plattformunabhängig
Programmier­sprache	Java
Kategorie	Jakarta EE Framework
Lizenz	Oracle-Lizenz
Oracle ADF

Oracle Application Development Framework, kurz Oracle ADF, ist ein kommerzielles Jakarta EE-Framework, das sich zum Ziel gesetzt hat, auf einfache, visuelle, deklarative und effiziente Art und Weise Java-Enterprise-Anwendungen zu entwickeln. ADF bietet mit einem Spektrum an Komponenten und einem Zusammenschluss an Frameworks (wie z. B. TopLink, JSF und Struts) einen ganzheitlichen Ansatz auf Basis des Model-View-Controller-Prinzips (MVC). Durch den Einsatz von bewährten Designmustern, metadatengesteuerten Komponenten und visuellen Tools wird Rapid Application Development unterstützt.

Eigenschaften

Die Grundlage dieses Frameworks basiert auf einer strikten Trennung zwischen Daten (Model), die durch die Geschäftslogik gekapselt werden und grafischer Darstellungsschicht (View) sowie der zur Darstellungsschicht gehörenden Steuerungseinheit (Controller). Ein wichtiger zentraler Bestandteil stellt das Binding (JSR-227) dar. In der nachfolgenden Abbildung ist die Architektur im Überblick dargestellt:

Zu erkennen sind 4 Schichten (Layers), die kurz von unten nach oben erläutert werden:

• Business Services Layer – beinhaltet die Zugriffsschicht auf die Daten aus verschiedenen Quellen und die eigentliche Geschäftslogik (Data Services)
• Model Layer – stellt eine Abstraktionsschicht auf den Business Services Layer dar, um den darüberliegenden Schichten (View, Controller) in konsistenter Weise mit den verschiedenen Business Services die Arbeit zu ermöglichen.
• Controller Layer – ist die Steuerungseinheit für die Navigation innerhalb der Webanwendung
• View Layer – beschreibt die Nutzeroberfläche der Anwendung (Webclient, Fat Client oder Mobile Client).

Das Binding zwischen Data Services von View- bzw. Controller Layer erfolgt im Model Layer. Grundsätzlich besteht es aus zwei Komponenten:

• Data Controls
• Data Bindings

die durch Metadaten beschrieben werden. Data Controls abstrahieren die Implementierungsdetails des Business Services. Wohingegen die Data Bindings die Methoden des Data Controls sowie Attribute in den UI Komponenten exponieren, um eine saubere Trennung zwischen View und Controller sicherzustellen. Die Metadaten Architektur schafft für den Entwickler eine einheitliche Vorgehensweise jeglichen Business Services mit der View und Controller Layer zu verbinden. Der JSR-227 (A Standard Data Binding & Data Access Facility for J2EE) hat sich die Standardisierung des Data Binding zum Ziel gesetzt.

Komponenten

ADF Faces

Das ADF Faces Framework bietet dem Entwickler die Möglichkeit, visuell und deklarativ, moderne webbasierte, dynamische und interaktive Benutzeroberflächen (UIs) zu realisieren. Dabei können die UI Komponenten zur Laufzeit durch client- und serverseitige Technologien (AJAX bzw. Server Push Technologien) im Browser aktualisiert werden, ohne die Webseite komplett neu zu laden. Die ADF Faces Komponentenbibliothek erweitert die Apache-MyFaces-Trinidad-Komponenten, um verschiedene Rich-Client UI- und Datenvisualisierungskomponenten (z. B. Maps, Gantt, Hierarchy Viewer). Das ADF Faces Framework unterstützt:

• Partial Page Rendering (PPR)
• Data Streaming
• ADF Data Binding Support
• Dialog-, Popup- und Menü-Funktionalitäten
• Drag- & Drop Features
• vollständige JavaScript API
• Templating
• Skinning via CSS
• Mehrsprachigkeit
• Expression Language Support
• verschiedene Jakarta EE Container

Die Daten werden in den UI Komponenten clientseitig als DOM und serverseitig als In-Memory Tree gehalten. Der Renderer ermöglicht die Darstellung der UI-Komponenten für verschiedene Endgeräte (mobile devices, browser).

ADF Taskflow

In der obigen Abbildung stellt ADF Taskflow die Controller-Komponente dar und erweitert den JSF Controller um wiederverwendbare Steuerungsablaufkomponenten (task flow components). Anstatt in einer Webanwendung einen einzelnen, großen Seitenablauf (Page-Flow) zu repräsentieren, helfen die Task Flows die komplette Webseitensteuerung in kleinere Einheiten zu unterteilen. Zudem wird nicht nur der Seitenaufruf/-ablauf gesteuert, sondern weitere, verschiedene Codeblöcke können in einem Ablauf ausgeführt werden. Die Task Flows werden in 2 Kategorien unterteilt:

• unbounded task flow
• bounded task flow.

Ein Unbounded Task Flow dient als Einstiegspunkt zu einer Webanwendung und wird als Top-Level Flow bzw. äußerer Task Flow betrachtet. Die Grenzen sind im Gegensatz zum Bounded Task Flow nicht wohldefiniert. Bounded Task Flows sind geprägt durch ihre wohldefinierten Grenzen mit einem einzigen Einstiegspunkt (single point of entry), eigenem Speicherbereich (Page Flow Scope) und dem deklarativen Transaktionsmanagement. Folglich stellen sie eigenständige Abläufe dar, die auf verschiedenen Seiten oder Regionen auf einer Seite (ADF Regions) wiederverwendet werden können. Sicherheits-, Kontroll-, Steuerungs-, Transaktionsmanagement- und Exception-Mechanismen runden den ADF-Controller ab.

ADF Model und Data Binding

Das ADF Model ist der Kern von Oracle ADF. Es stellt eine Abstraktionsschicht zwischen der Business-Service-Schicht und dem User Interface dar und wurde erstmals mit dem Oracle JDeveloper 9.0.5 eingeführt. Davor war jeder Entwickler für die Verbindung zwischen der Oberfläche (zum Beispiel Swing, JSP oder JSF) und dem Business Service verantwortlich (data binding). So mussten beispielsweise JSP Tags verwendet werden, um ein Textfeld in der Oberfläche mit einem Attribut des Business Service zu verbinden. Mit dem ADF Model wird eine zusätzliche Abstraktionsschicht eingeführt: der Entwickler verbindet nun die Oberfläche mit dem Model und das Model mit dem Business Service. Dieses Konzept wurde in der Spezifikation JSR-227 beschrieben und zur Standardisierung eingereicht. Das ADF Model stellt damit eine einheitliche Programmierschnittstelle für die unterschiedlichsten Business Services (Webservice, Enterprise JavaBeans, Java, JDBC etc.) zur Verfügung. Neben einer höheren Komplexität bietet diese Architektur einige Vorteile:

• Der Oberflächen-Entwickler kann sich auf die Entwicklung der Benutzeroberfläche konzentrieren, ohne den darunterliegenden Business Service zu kennen.
• Ein Business Service kann ausgetauscht werden, ohne dass die Oberfläche der Applikation davon betroffen ist. Es sind lediglich Anpassungen im ADF Model notwendig.
• Alle Applikationen verwenden die gleiche Programmierschnittstelle (API) und das gleiche Metadaten-Format zur Beschreibung des Data Binding.

In der Entwicklung mit ADF sieht dies konkret so aus, dass der Entwickler des Business Service sogenannte Data Controls zur Verfügung stellt. Die Data Controls umfassen alle jene Daten und Methoden des Business Service, die der Oberfläche zur Verfügung gestellt werden sollen. Der Oberflächen-Entwickler verbindet diese Data Controls mit Komponenten in der Oberfläche und erzeugt damit das sogenannte Data Binding. Zur Definition des Data Binding wird die Syntax der JSTL Expression Language (EL) benutzt. Oracle ADF enthält für die verbreitetsten Business-Service-Technologien vordefinierte Implementierungen der Data Controls.

ADF Business Components

ADF Business Components (ADF BC) stellen die Daten-/Persistenzschicht auf relationale DB mit den zugehörigen Transaktions- und Locking-Mechanismen dar (?) und tauchen in der obigen Architekturabbildung als Business Services auf. Zusätzlich bieten ADF Business Components einen einzigartigen Aspekt des Software Engineerings, den Event Driven Model Ansatz an. ADF BC Objekte beinhalten Ankerpunkte (hook points) zur Injektion selbstgeschriebenen Java Codes für die Erweiterung spezifischer Operationen. Ähnlich wie bei den Events in Oracle Forms stellt ADF BC Methoden bereit, die überschrieben werden und das Verhalten im Einzelnen ändern können, z. B. pre und post commit, DML Ausführung, neuen Datensatz anlegen u. a. Zu den wesentlichen Komponenten von ADF BC zählen:

1. Entity Objects
2. View Objects
3. Associations und Viewlinks.
4. Application Modules (AMs)
5. Business Component Tester

Ein Entity Object (EO) repräsentiert in einfacher Art und Weise eine Tabelle in einer relationalen Datenbank. Es definiert den Datentyp der Tabellenattribute, Validierungsregeln bezüglich des Datentyps, Primärschlüssel und zusätzlich Hilfskonstrukte (Businesslogik), um Daten in die Zieltabelle zu schreiben. Folglich dient das EO als direkte Datenzugriffs-/Validierungsmaschine (Unterstützung der CRUD-Operationen) auf die Datenbanktabellen.

Das View Object (VO) lässt sich als Datenquelle oder als spezifische Datensicht auffassen, das mit ein oder mehreren Entity Objects interagiert. VOs können auf EOs basieren, die vergleichbar mit SQL Anfragen sind und für Datenextraktion bzw. programmatisch Datenzusammenfassung oder statische Listen von Daten verwendet werden. In meisten Fällen werden VOs basierend auf EOs verwendet. Das View Object fragt nach Daten und stellt diese als Datenquelle zur Verfügung. Während einige Validierungsmöglichkeiten auch für View Objects zur Verfügung stehen, wird in der Praxis empfohlen, spezielle Logik in den Entity Objects abzulegen, weil diese Logik innerhalb einer Entity für alle View Objects gecacht wird. Mehrere View Objects teilen sich den gleichen Speicher (Cache). Zur Laufzeit werden bei Ausführung einer Query auf ein View Object bezogenen Daten in die verantwortlichen Entity Object Records aufteilen und in den Entity Cache abgelegen. Diese Vorgehensweise unterstützt verschiedene View Objects Zugriff auf das gleiche Datenset zu gewährleisten, unter der Prämisse, die Speicherbelegung und die unterschiedlichen Validierungsregeln für alle Entity Objects zu reduzieren. Das ist ähnlich der Normalisierung auf DB-Ebene.

Association und Viewlink definieren die Verknüpfungen zwischen EOs und VOs. Associations im Detail stellen Beziehungen zwischen EOs dar. Sie werden als PrimaryKey/ForeignKey Beziehungen zwischen Tabellen betrachtet. Viewlinks verweisen auf die Beziehungen zwischen den View Objects und definieren Join-Bedingungen. Ein Viewlink kann auf Assoziation oder auf Attributen basieren. Basierende Viewlinks auf Assoziationen haben den gleichen Vorteil des Entity Cache.

Das Application Modul fasst die VOs zusammen und dient als Data Control. Es erstellt und verwaltet Datenbanktransaktionen. Für die ADF Model Schicht stellt es die Daten und Methoden, die der Client benötigt, zur Verfügung. Aus Endanwendersicht werden die Interaktionsmöglichkeiten und transaktionalen Fähigkeiten durch das Application Module geliefert.

Der Business Component Tester ist das gebräuchlichste Testwerkzeug, um die Business Components auszuführen und das implementierte Datenmodell zu überprüfen. Es dient als erste Verteidigungslinie zur Prüfung der Datenbereitstellung und des Datenmodells, so wie es benötigt wird, ohne eine eigene Oberfläche (user interface) zu erstellen.

ADF Metadata Services

Ein wichtiger Bestandteil für die deklarative Entwicklung von Enterprise Anwendungen mit ADF ist Metadata Services (MDS). Mit MDS werden Anwendungen mandantenfähig und für einzelne Identitäten (roles, site user, user) dynamisch anpassbar. Die gespeicherten Metadaten für jede einzelne Identität werden in einem Repository (datei- und RDBMS basierend) gehalten. Die Anpassungsfähigkeit ist bis auf ADF Komponentenebene herunter definierbar. In der Entwicklung wird ein Basis Set an Metadaten (base document) im Repository als Dokument (XML-Repräsentation) geschaffen. Zusätzliche Anpassungen, die auf verschiedene Seitensichten und Nutzersichten beruhen, werden als jeweilige einzelne Layer betrachtet und die Differenz jeweils zum Base Document bzw. dem darüberliegenden Layer als weiteres Dokument im Repository gespeichert. Jedes einzelne Dokument im Repository ist versionierbar.

ADF Mobile

ADF Mobile basiert auf dem Application Development Framework und erweitert dieses um eine mobile Komponente. Es ermöglicht, mobile Applikationen weitestgehend plattformunabhängig zu entwickeln, um diese im weiteren Verlauf ohne bedeutenden Mehraufwand auf unterschiedlichen Geräteplattformen ablaufen zu lassen. Um dieses Ziel zu erreichen, werden zwei Ansätze verfolgt. So bietet das Framework an, Anwendungen zum einen für den Ablauf in einem mobilen Browser zu entwerfen, zum anderen als lokal installierten Client (inkl. lokalem MVC-Stack und Datenbank) zu implementieren. Beide Varianten sollen nun beschrieben werden.

ADF Mobile Browser

Applikationen, die später auf mobilen Browsern angezeigt werden sollen, werden im JDeveloper ähnlich entwickelt, wie man es von Webanwendungen für normale Webbrowser gewohnt ist. Die Verwandtschaft zu herkömmlichen Webanwendungen ermöglicht Webprogrammierern einen relativ zeitnahen Einstieg in die Technologie. Einen Unterschied stellt allerdings die Anzeigeschicht dar. Wo gängige Webapplikationen mit Java Server Pages (JSP) bzw. Java Server Faces (JSF; erweitert um ADF Faces) umgesetzt werden, wird bei der Entwicklung für den mobilen Browser eine eigene Technologie verwendet. Hier kommt die Apache MyFaces Trinidad-Bibliothek zum Einsatz. Dies ist technisch notwendig, um die gewünschte Plattformunabhängigkeit zu erreichen – den Inhalt auf vielen heterogenen Handy-Browsern korrekt darstellen zu können. Mit der Entwicklungsumgebung können Oberflächen komplett deklarativ erstellt werden, die Seitenerstellung erfolgt im visuellen Baukastenprinzip. Eine Stärke die herausgestellt werden muss, ist die zur Laufzeit erfolgende Browserweiche. Die zur Laufzeit erfolgende Unterscheidung des anfragenden Browsers hat den Vorteil, plattformspezifisches Layout auszuliefern. Handelt es sich hierbei um den Safaribrowser eines iPhones, kann die entsprechende Browserpage im Design einer nativen iPhone App gestaltet werden. Hierzu ist es notwendig, für jede der unterstützten Plattformen, eine eigene CSS-Datei anzulegen. Einen guten Einblick hierzu gibt der Skinning Guide von Oracle.

Der mobile Browser eignet sich gut dafür, bestehenden Webanwendungen eine mobile Komponente zuzufügen. Gängige Situation ist daher eine bereits vorhandene Applikation. Das ADF Framework bietet die Möglichkeit, diese zu exportieren und als .Jar-Datei in das mobile Entwicklungsprojekt einzubinden. Dies hat den Vorteil, dass Datenbankverbindungen und -objekte, Views, Businesslogik etc. nicht neu erstellt werden, sondern nur erneut zusammengefügt werden müssen. Einzig, wie bereits beschrieben, gilt es, die Oberflächen mit Trinidad-Komponenten neu zu gestalten. Diese Tatsache wirft zunächst die Frage auf, warum dies notwendig ist, wäre es doch eleganter, die komplette Webanwendung zu übernehmen. Dagegen spricht der Punkt, dass die von ADF verwendete ADF Faces Technologie nicht von mobilen Browsern gerendert werden kann. Darüber hinaus ist es ohnehin nicht unbedingt sinnvoll, Oberflächen, entworfen für den großen Webbrowser, ohne Anpassung zu übernehmen. Das spärliche Platzangebot eines Handydisplays erfordert neue angepasste Oberflächen.

ADF Mobile Client

Oracle ADF Mobile stellt neben der Browserlösung auch eine Client-Variante zur Verfügung. Es ist eines der wenigen Frameworks, die beide Ansätze verfolgen. Im Gegensatz zum Browser, der die Gesamtheit des Inhaltes über das Netz von einem Applikations-Server empfängt, ist der Client mitsamt der notwendigen Businesslogik direkt auf dem mobilen Gerät vorhanden – ein MVC-Paradigma läuft also direkt auf dem Handy. Grundlage ist eine Java-Runtime. Stellt ein Zielgerät diese bereit oder ist es möglich eine Runtime zu installieren, so ist das Gerät eine potenzielle Zielplattform für ADF Mobile Client. Das Credo Write once – deploy everywhere ist somit erfüllt. Bei der Komponentenanzeige zur Laufzeit wie Buttons etc. ist ein signifikanter Unterschied zu beachten. Während man Look-And-Feel im Browser mittels CSS-Datei vorgibt, also zur Design-Zeit festlegen muss, wird das Design einer Clientapplikation im JDeveloper lediglich auf einer Metaebene festgehalten. Zur Laufzeit, wenn dem Gerät beispielsweise mitgeteilt wird, dass an einer gewissen Stelle ein Button gezeichnet werden soll, so ist dies ebenfalls eine Metainformation. Der Button selber wird daraufhin jedoch nativ aus der eigenen Gerätebibliothek angezogen. Somit wird das exakt gleiche Oberflächen-Design wie bei einer nativen App erzielt.

ADF Mobile Database

Benötigt die mobile Clientapplikation eine lokale Datenbank, so wird auch diese einmalig auf dem Gerät installiert (via Developer). Primärer Vorteil einer lokalen Datenbank ist die Tatsache, auch in Situationen, in denen kein Netz zur Verfügung steht, Daten auszulesen, zu ändern oder einzupflegen. Hieraus ergibt sich die Herausforderung, zu einem späteren Zeitpunkt dafür zu sorgen, die Datenbasis wieder auf einen synchronen Stand zu bringen. Hierfür sieht Oracle den Mobile Server vor. Diese Software ist Vermittler zwischen lokaler Datenbank und zentralem Datenbankserver und erreicht konsistente Datenhaltung durch den sogenannten MGP (Message Generator and Processor). Wird dieser Prozess angestoßen, lädt der Client die geänderten Informationen in eine "In Queue" des Mobile Servers. Hierauf erfolgt der MGP, sozusagen das Merging der Daten. Hierfür können über die Administrations-Oberfläche des Mobile Servers eine Vielzahl an Einstellungen vorgenommen werden (Server wins / Client wins etc.). Fehlerhafte Vorgänge werden in einer Error Queue gespeichert, neuere Daten, die auf dem Gerät aktualisiert werden müssen, werden über eine "Out Queue" an das Gerät übermittelt.

Geschichte

Einige Komponenten von ADF wurden von Oracle bereits 1999 veröffentlicht, wie z. B. ADF Business Components — damals als "JBO" (Java Business Objects) und später als "BC4J" ("Business Components for Java") bekannt. Das aktuelle generische Model/Binding Layer in der ADF-Architektur wurde mit dem JDeveloper 9.0.5 miteingeführt. Im Juni 2006 spendete Oracle einen großen Teil der ADF-Faces-Komponentenbibliothek (Oracles JSF-Implementierung mit über 100 Komponenten) dem Open-Source-Projekt Apache Trinidad.

Lizenzierung

Details zur Lizenzierung sind auf dem Oracle Technology Network (OTN) beschrieben.

Literatur

• Frank Nimphius und Lynn Munsinger: Oracle Fusion Developer Guide. ISBN 0-07-162254-3.
• Duncan Mills, Peter Koletzke, Avrom Roy-Faderman: Oracle JDeveloper 11g Handbook – A Guide to Oracle Fusion Web Development, ISBN 0-07-160238-0.
• Ronald Grant: Quick Start Guide to Oracle Fusion Development. ISBN 0-07-174428-2.
• Sten E. Vesterli: Oracle ADF Enterprise Application Development – Made Simple. ISBN 1-84968-188-0.
• Nick Haralabidis: Oracle JDeveloper 11g R2 Cookbook. ISBN 1-84968-476-6.

Weblinks

• offizielle Website
• JSR-227
• ADF/JDeveloper Blog