Schnell mal eine Anwendung mit Zugriff auf eine (Oracle-)Datenbank realisieren: Was sich zunächst nach einer Standardanforderung anhört, kann bereits bei der Auswahl der einzusetzenden Tools und Programmiersprachen eine Menge Arbeit bedeuten. Zunächst muss dazu eine Grundsatzentscheidung getroffen werden, nämlich, ob die Anwendungslogik innerhalb oder außerhalb der Datenbank laufen soll. Während innerhalb der Datenbank mit PL/SQL und Java in der Datenbank zunächst nur zwei Alternativen zur Verfügung stehen, sieht dies bei datenbankexternen Techniken schon ganz anders aus. Im Folgenden werden einige der verfügbaren Techniken und Tools vorgestellt. Die vollständige Auswahl steht aber meist nur in Projekten zur Verfügung, die „auf der grünen Wiese“ starten, d.h., bei denen keine Abhängigkeiten zu bereits bestehenden Projekten oder Anwendungen beachtet werden müssen. In den meisten Projekten ist dies aber nicht der Fall. Steht eine Erweiterung einer bestehenden Anwendung an oder müssen in einem neuen Projekt Komponenten aus anderen Projekten wiederverwendet werden, so fallen einige der vorgestellten Techniken aus der Auswahl heraus. In solchen Fällen stellt sich dann schon eher die Frage, ob die bereits bestehende Technik komplett übernommen werden soll oder inwieweit eine neue Technik in die bestehenden Komponenten integriert werden kann. Eine Migration der Altanwendung auf die neue Technik dagegen ist zwar technisch unter Einsatz entsprechender Tools möglich, wird aber von Projektverantwortlichen häufig wegen Bedenken bezüglich Investitionsschutz und Sicherung des Entwickler-Know-hows kritisch betrachtet.

PL/SQL

Wer an Applikationsentwicklung mit bzw. in der Oracle-Datenbank denkt, dem wird sicherlich als erstes PL/SQL einfallen. PL/SQL wird von Oracle bereits seit vielen Versionen als prozedurale Erweiterung von SQL und zentraler Bestandteil jeder Datenbankinstallation angeboten. Wie im Abschnitt über die PL/SQL-Alternative „Java in der Datenbank“ noch näher erläutert wird, liegt einer der Vorteile von PL/SQL in der Tatsache, dass Applikationen direkt mit den SQL-Datentypen arbeiten und zur Laufzeit unmittelbar im Datenbankkernel ablaufen können. Ein wichtiges Einsatzgebiet von PL/SQL sind Trigger, die unmittelbar vor oder nach Datenbankänderungen automatisch vom Datenbanksystem ausgeführt werden. Der Einsatz von PL/SQL ist aber nicht nur auf solche klassischen Datenbankgebiete beschränkt. Über das mod_plsql -Modul beispielsweise können auch Webapplikationen mit PL/SQL realisiert werden. Webanfragen werden in dieser Konstellation vom Apache- mod_plsql -Modul an die entsprechend konfigurierte Oracle-Datenbank weitergeleitet, indem dort eine PL/SQL-Prozedur aufgerufen wird, in der dann die Ergebnis-HTML-Seite erstellt wird. Datenbankintensive Webabfragen können so unmittelbar dort beantwortet werden, wo auch die Daten liegen. Allerdings ist im Vergleich zu anderen Möglichkeiten wesentlich mehr Handarbeit bei der Erstellung der Prozeduren bzw. der von Ihnen erzeugten HTML-Seiten erforderlich.

Java in der Datenbank

Wenn die Entscheidung, die Anwendungslogik innerhalb der Oracle-Datenbank zu implementieren, getroffen ist, dann ist PL/SQL aber nicht die einzige Alternative. Seit Version 8.1.5 bietet Oracle durch die Integration einer Java Virtual Machine (JVM) innerhalb der Datenbank auch die Möglichkeit, Java-Programme in der Datenbank laufen zu lassen. Wer also entweder aufgrund persönlicher Präferenzen oder wegen einer für das Projekt relevanten Java-API lieber auf Java als Entwicklungsumgebung zurückgreift, kann dies auch innerhalb der Datenbank tun. Abbildung 1 zeigt den Weg, auf dem Java-Programme in die Datenbank gelangen: Zentrales Tool dafür ist das loadjava-Skript, mit dem Jar-Archive, außerhalb der Datenbank kompilierte Java-Klassen, aber auch Java-Sourcen in die Datenbank übertragen werden können. Aufgerufen werden Methoden aus Java-Klassen dann über so genannte Java Stored Procedures. Dies sind PL/SQL-Wrapper (ganz ohne PL/SQL geht es also auch bei dieser Architekturalternative nicht), bei denen über den Zusatz as language java der Aufruf einer bestimmten Java-Methode initiiert wird:

1. create or replace procedure start_helloworld
2. as language java
3. name 'HelloWorld.test()';

Selbstgeschriebene Java-Klassen sowie die J2SE- und andere benötigte Jar-Archive werden innerhalb der Datenbank als Schema-Objekte abgelegt. Dementsprechend befindet sich das „Gegenstück“ zum Java-CLASSPATH außerhalb der Datenbank und enthält eine Liste von Dateien und Verzeichnissen. Und innerhalb der Datenbank besteht es aus einer Liste von Datenbank-Schemata, in denen in der angegebenen Reihenfolge nach benötigten Klassen gesucht wird. Jeder Aufruf einer Java Stored Procedure erfolgt in einer eigenen JVM sowie einer eigenen Datenbank-Session. Von mehreren Clients gemeinsam genutzter Code sowie Read-Only-Daten werden im Java-Pool innerhalb des Datenbankspeicherplatzes abgelegt, der über eigene Administrationsbefehle ebenso konfiguriert werden kann wie die Zugriffsrechte aus Java-Klassen auf externe Ressourcen, beispielsweise der Zugriff auf externen Speicherplatz. Wann sollte man nun PL/SQL und wann die datenbankinterne JVM benutzen? Der entscheidende Vorteil von PL/SQL ist die Tatsache, dass PL/SQL direkt mit den datenbankeigenen Datentypen arbeitet. Beim Einsatz von Java müssen dagegen zur Laufzeit die Java-Datentypen in die entsprechenden SQL-Datentypen umgewandelt werden. Datenintensive Berechnungen innerhalb der Datenbank werden daher in der Regel direkt in PL/SQL implementiert. Wer allerdings aus der zu erstellenden Anwendung heraus häufig auf externe Ressourcen zugreifen muss, der stößt bei den entsprechenden PL/SQL-APIs schnell an deren Grenzen. Beispiele dafür sind Mailversand, Dateizugriffe oder XML-Parsing. Hierfür gibt es zwar entsprechende PL/SQL-APIs, die allerdings mit den „konkurrierenden“ Java-APIs bezüglich Funktionsumfang in der Regel nicht mithalten können, sodass bei solchen Anforderungen eher die Wahl auf Java fällt. Zu klären ist dann nur noch die Frage, ob Java innerhalb oder außerhalb der Datenbank eingesetzt wird. Während bei „Java außerhalb der Datenbank“ und intensiven Datenbankzugriffen über JDBC oder fortgeschrittenere Techniken der Netzwerkzugriff vom Applikationsserver auf den Datenbankserver zum Performance-Engpass werden kann, bietet PL/SQL in bestimmten Konstellation nicht genügend Möglichkeiten zum Zugriff auf externe Ressourcen. Java in der Datenbank kann hier also ein „goldender Mittelweg“ sein, mit dem die Möglichkeiten von Java genutzt werden können und das Programm trotzdem da ablaufen kann, wo sich auch die Daten befinden, nämlich direkt in der Datenbank.

ADF

Wer aus der Java-Welt kommt, wird bei der Erstellung von größeren Anwendungen automatisch an die Realisierung in Form einer Java-Enterprise-Anwendung mittels Java-EE-Techniken denken. Oracle bietet für Java-EE-Entwickler u.a. das Oracle Application Development Framework (ADF) an. Unter dem Oberbegriff ADF findet man u.a. die aus der Oracle-Welt bekannten Frameworks Business Components for Java (BC4J), UIX und JClient wieder. Die grundlegende ADF-Architektur orientiert sich an bekannten JEE-Design-Pattern. Entwickler finden bei Einsatz der Oracle-Entwicklungsumgebung JDeveloper eine Reihe von hilfreichen Tools, mit denen ADF-basierte Applikationen erstellt werden können. Wer seine Webapplikation gemäß der aufstrebenden „Java Server Faces“-Technologie entwickeln möchte, wird bei Oracle ebenfalls unter dem Stichwort „ADF Faces“ fündig. Oracle ADF steht zusammen mit dem JDeveloper inzwischen zum freien Download zur Verfügung. Wer ADF-Komponenten allerdings mit Applikationsservern einsetzen will, die nicht aus dem Hause Oracle kommen, sollte bezüglich Lizensierung unbedingt die entsprechende „JDeveloper& ADF Pricing FAQ“-Liste [1] beachten.

Oracle Developer Suite

Der „Klassiker“ für die Entwicklung einer Client-Server-Oracle-Anwendung ist Oracle Forms. Bereits seit vielen Jahren bzw. vielen Oracle-Versionen werden solche Anwendungen mit diesem Tool erstellt, sodass sowohl in Form von Altanwendungen als auch innerhalb der Oracle-Entwickler-Gemeinde viel Forms-Know-how verfügbar ist. Aber auch in der Forms-Welt hat die Zeit nicht still gestanden. Klassische Client-Server-Anwendungen sind in vielen Bereichen durch „moderne“ Web-3-Schichten-Anwendungen abgelöst worden, bei denen die Applikationslogik nicht mehr wie in der ursprünglichen Forms-Welt in einer Datei zusammen mit den GUI- und den Datenbank-Komponenten gespeichert wird, sondern zentral auf einem Application Server. Gemäß dieser technischen Weiterentwicklung ist das klassische Client/Server Forms 6i inzwischen von Oracle auch desupported worden. Forms selber hat aber überlebt und ist inzwischen zusammen mit den folgenden Tools Bestandteil der Oracle Developer Suite:

• Oracle JDeveloper
• Oracle Reports
• Oracle Designer
• Oracle Discoverer
• Oracle Warehouse Builder
• Oracle Software Configuration Manager
• Oracle Business Intelligence Beans

Forms-Applikationen können nun direkt im Application Server installiert werden. Die eigentliche Forms-Entwicklungsumgebung bietet weiterhin das aus Vorgängerversionen bekannte Bild, sodass an dieser Stelle Investitionsschutz bezüglich des Entwickler-Know-hows gegeben ist. Trotzdem stellt sich natürlich in der heutigen „Java-Zeit“ die Frage nach der Zukunft von Oracle Forms. Sollten neue Anwendungen noch in Forms erstellt werden bzw. alte Forms-Anwendungen im Rahmen von Erweiterungsprojekten zunächst mittels eines der zahlreichen für diese Zwecke verfügbaren Tools in die Java-Welt migriert werden? Antworten auf diese Fragen hängen von den speziellen Gegebenheiten eines Projektes sowie dem zur Verfügung stehenden Zeit- und Kostenbudget ab. Die Frage „Forms oder Java“ kann aber auch mit „Forms und Java“ beantwortet werden, da Forms die Möglichkeit bietet, beide Welten durch die Integration von Java-Komponenten in die Forms-Entwicklungsumgebung zu verbinden. Wie oben bereits bei der Alternative zwischen PL/SQL und Java in der Datenbank beschrieben, lässt sich also auch die Erstellung bzw. Erweiterung von Forms-Applikationen durch den Einsatz eines der zahlreichen Java-APIs für Spezialanforderungen vereinfachen. Auch eine langsame Migration von Forms in Richtung Java ist auf diesem Wege möglich.

Oracle Application Express

Ein Artikel über Oracle-Anwendungsentwicklung muss sich natürlich auch mit der Oracle HTML-DB beschäftigen, mit der Oracle ursprünglich die schnelle Erstellung von einfachen Formularanwendungen auf der Basis eines bestehenden Datenbankmodells anbieten und somit den für solche Zwecke in Unternehmen häufig noch vorzufindenden Microsoft-Access-Datenbanken Konkurrenz machen wollte. Die Entwicklungsumgebung HTML-DB existiert auch weiterhin, allerdings nicht mehr unter ihrem ursprünglichen Namen. Sie gehört seit kurzem zur neuen „Express-Produktfamilie“ von Oracle und wird unter dem Namen „Oracle Application Express“ [2] zusammen mit der Datenbankversion Oracle Express Edition (XE) vertrieben. Die XE-Datenbank wird von Oracle als kostenlose Starter Edition der hauseigenen Datenbank hauptsächlich für die Zielgruppen Entwickler, Studenten, Schulungsanbieter etc. angeboten. Sie basiert auf dem gleichen Code wie die „normale“ Datenbank und kann auch zur Laufzeit unter eingeschränkten Bedingungen (maximal 4 GB Benutzerdaten, maximal 1 GB Speicher sowie maximal eine CPU für den Datenbankserver) frei verwendet werden. Wer mehr Ressourcen und den dazugehörigen Oracle-Support benötigt, kann bzw. muss auf eine der anderen kostenpflichtigen Datenbankversionen wechseln. Zusammen mit Oracle Application Express als Entwicklungsumgebung positioniert sich Oracle also mit der XE-Version der Datenbank auf dem wachsenden Markt der freien Datenbanken für kleine und mittlere Projekte, die als Türöffner für die großen - und damit für den Tool-Hersteller gewinnbringenderen - Projekte dienen sollen.

XML

Enthält die zu realisierende Anwendung auch Anforderungen, die mit XML-Techniken realisiert werden können bzw. sollen, so sollten die Oracle-eigenen Tools XML Developer's Kit (XDK) sowie Oracle XML DB als Alternative betrachtet werden. Das XML Technology Center auf den OTN-Webseiten [3] enthält Informationen zu diesen Themen. Während das XDK eine Sammlung von (Java- und C++-)Klassen ist, mit denen außerhalb der Datenbank entsprechende XML-Applikationen sowie Mapping-Operationen zwischen der XML- und der SQL-Welt durchgeführt werden können, ist Oracle XML-DB ein Marketing-Oberbegriff für eine Reihe von Möglichkeiten, XML-Applikationen innerhalb der Datenbank zu realisieren. Oracle XML-DB ist also kein eigenständiges Produkt, sondern Bestandteil der normalen Oracle-Datenbank. Wie aus Abbildung 2 ersichtlich ist, sind zentrale Bestandteile der Oracle XML DB der Oracle-eigene Datentyp XMLType sowie das XML-Repository, mit dem eine virtuelle Verzeichnisstruktur innerhalb der Datenbank angelegt werden kann. Auf dieses Verzeichnis bzw. die darin enthaltenen virtuellen Dateien kann dann extern über Standardprotokolle (z.B. FTP, WebDAV) zugegriffen werden, sodass Anwender in ihrer gewohnten Umgebung (beispielsweise mit dem Windows Explorer) arbeiten und dabei bequem auf Datenbankinhalte zugreifen können. Inhalte der virtuellen Dateien sind entweder relational gespeicherte Daten, die innerhalb des XML-Repository in XML-Format umgewandelt werden, oder XML-Daten, die über den XMLType-Datentyp direkt in XML-Format gespeichert sind. Bei der Speicherung solcher XML-Daten besteht neben einer Binärspeicherung auch die Möglichkeit, durch Angabe einer passenden XML-Schema-Definition ein Mapping auf (objekt-)relationale Bestandteile durchzuführen.

Fazit

Steht eine Neuentwicklung einer Oracle-Anwendung an, bei der man noch nicht durch Wiederverwendung bestehender Komponenten und damit automatisch auch durch den weiteren Einsatz der Tools, mit denen sie erstellt worden sind, gebunden ist (Stichwort Investitionsschutz, auch bei Entwicklungstools), so stehen eine Reihe von verschiedensten Architekturalternativen und damit auch Entwicklungstools zur Verfügung. Insbesondere in größeren Projekten wird aber die Wahl nicht unbedingt auf genau eine Technik fallen. Vielmehr macht es Sinn, für verschiedene Teile einer Anwendung unterschiedliche Tools und damit auch Entwickler mit entsprechendem Spezial-Know-how einzusetzen. Eine Datenvalidierung ist zum Beispiel am besten direkt in der Datenbank aufgehoben, damit sie unabhängig von der Art des Datenbankzugriffs in jedem Fall durchgeführt wird. Somit ist der Bereich Validierung beispielsweise über Trigger oder Constraints ein typisches Einsatzgebiet für PL/SQL. Komplexe Anwendungslogik, die möglicherweise auch auf andere Systeme zugreifen muss, wird meist als Java-EE-Anwendung implementiert, für die Oracle rund um den hauseigenen Oracle Application Server einiges im Angebot hat. Und wer bei der Entwicklung von GUI-Applikationen früher bereits auf Oracle Forms in der klassischen Client/Server-Variante zurückgegriffen hat, der kann dies auch weiterhin in der heutigen Webanwendungswelt tun.

Links & Literatur

• [1]: ADF-Lizensierung: www.oracle.com/technology/products/jdev/htdocs/jdevpricefaq.html
• [2] Oracle Application Express: www.oracle.com/technology/products/database/application_express/
• [3]: XML Technology Center: www.oracle.com/technology/tech/xml/