Oracle APEX: "Rapid Application Development"-Werkzeug für Webanwendungen
Es gibt viele Frameworks, die Entwicklern Arbeit abnehmen und helfen, Fehler zu vermeiden. Doch fällt auf, dass die Umsetzung von Datenbankanwendungen zur Datenerfassung oder für einfaches Reporting aufwendig ist. Hier setzt Oracle Application Express an.
- Carsten Czarski
- Alexander Neumann
Nahezu jede Unternehmensanwendung ist eine mit einer Datenbank – schließlich arbeiten alle mehr oder weniger intensiv mit Daten. Zur Entwicklung verwendet man normalerweise Techniken wie Java (Java EE), .Net und PHP. Zwar gibt es viele Frameworks, die Entwicklern häufig Arbeit abnehmen und helfen, Fehler zu vermeiden, doch fällt auf, dass die Umsetzung vergleichsweise einfacher Datenbankanwendungen zur Datenerfassung oder für einfaches Reporting verhältnismäßig aufwendig ist: So muss vielfach zunächst ein objektrelationales Mapping (ORM) stattfinden, obwohl die "Geschäftsobjekte" kaum eigene Logik besitzen und nur zum "Durchreichen" der Daten an die Datenbank dienen. An diesem Punkt setzt Oracle Application Express (APEX) an.
APEX ist eine Entwicklungs- und Laufzeitumgebung für datenbankbasierte Webanwendungen. Der Entwickler erhält durch sie Komponenten wie Formulare, Berichte oder Diagramme im "Baukastensystem" – so besteht ein APEX-Bericht aus einer SQL-Abfrage als Datenquelle, einer Layoutvorlage und diversen Einstellungen zur Druckausgabe, zum Blättern oder zur Sicherheit.
Es ist Bestandteil aller Oracle-Editionen – zusätzliche Lizenzkosten fallen nicht an. Seit Anfang März 2009 liegt APEX in Version 3.2 vor. Es lässt sich aus dem Oracle Technet herunterladen und in jede Oracle-Datenbank ab Version 9.2 installieren.
APEX verbindet die Vorteile einer Einzelplatzdatenbank wie schnelle, einfache und unabhängige Entwicklung von Anwendungen mit denen einer zentralen Datenbank wie einheitliches Backup & Recovery, Multiuserfähigkeit oder Hochverfügbarkeit. Anwender können Anwendungen ähnlich schnell entwickeln wie in Microsoft Access, die Anwendungen laufen aber auf einem zentralen Server.
Architektur und Installation
Die Entwicklungsumgebung läuft vollständig in der Oracle-Datenbank ab. Der Webserver reicht die HTTP-Anfragen lediglich an die Datenbank durch. Die Verarbeitung der Anfrage sowie das Rendering der HTML-Seite als Antwort auf die Anfrage finden in der Datenbank statt (dennoch gibt es eine klare Trennung zwischen Daten und Anwendungen, mehr dazu im Abschnitt "Workspaces").
APEX selbst ist in der Oracle-Programmiersprache PL/SQL implementiert. Es "besteht" aus Tabellen und PL/SQL-Paketen. In den Tabellen speichert man die Details (Metadaten) der entwickelten APEX-Anwendungen – die PL/SQL-Pakete generieren mit diesen Daten die Anwendungsseiten und stellen die Infrastruktur für Webanwendungen (insbesondere Websession-Handling) bereit. APEX ist metadatengetrieben und generiert zu keinem Zeitpunkt Code. Die jüngste Version residiert im Datenbankschema APEX_030200. Pro Datenbankinstanz kann es nur eine aktive APEX-Installation geben.
In einer Oracle-11g-Datenbank ist APEX vorinstalliert, allerdings nur in der veralteten 3.0-Version. Es empfiehlt sich die Neuinstallation der Umgebung in die jeweilige Datenbank. Dazu lädt man das aktuelle APEX-Paket aus dem Oracle Technet herunter und spielt es gemäß der beiliegenden Dokumentation (Installation Guide) ein.
Da APEX (und damit jede APEX-Anwendung) vollständig in der Datenbank abläuft, entfällt die Notwendigkeit für ein ORM. PL/SQL verwendet die Datentypen der Datenbank, man braucht also keine Konvertierungen zwischen Datenbank und Anwendungsschicht. Die Datenbanksitzung ist schon eingerichtet. Alles in allem bemerkt man beim Entwickeln mit APEX recht schnell, dass die datenbanktypischen Arbeiten mit Tabellen, Views oder Stored Procedures gut funktionieren – schließlich fällt eine Menge "Overhead" weg.
So kann APEX das Websession-Handling ohne Performanceeinbußen komplett tabellenbasiert durchführen: Es verwaltet alle Session-Variablen in einer Datenbanktabelle; die Zuordnung erfolgt, wie bei vielen Webanwendungen, mit einem nichtpersistenten Cookie und einer Session-ID in der URL. Das führt zum Effekt, dass man, solange der Anwender den Browser geöffnet hält, die Datenbank im Hintergrund herunter- und wieder hochfahren kann, ohne die Sitzungen zu zerstören. Schließt der Anwender dagegen den Browser, zerstört dies das Session-Cookie und so die APEX-Sitzung. Damit die Datenbanktabellen für das Session-Handling nicht überlaufen (APEX bekommt vom abrupten Schließen des Browsers nichts mit), löscht ein asynchroner Hintergrundprozess alle Details zu Sessions, die für eine bestimmte Zeit inaktiv sind; der Administrator kann dafür die Zeitspanne festlegen.
