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:
Datei:ADF11g architecture.png
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:
Entity Objects View Objects Associations und Viewlinks. Application Modules (AMs) 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