Viele Wege führen nach Rom

Entwicklung von Oracle-Anwendungen

Rudolf Jansen

Wer die Aufgabe erhält, eine Anwendung zur Verarbeitung von Daten aus einer Oracle-Datenbank zu erstellen, hat bei der Wahl der Architektur sowie der einzusetzenden Entwicklungswerkzeuge die Qual der Wahl. Sowohl Oracle-eigene Frameworks als auch einige bereits aus anderen Nicht-Oracle-Anwendungen bekannten Techniken stehen zur Verfügung. Vorgestellt werden in diesem Artikel einige der zur Wahl stehenden Techniken sowie Kriterien, die bei der Auswahl behilflich sein können.

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:

create or replace procedure start_helloworld
as language java
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.

Abb. 1: Java in der Datenbank

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.

Abb. 2: Oracle XML-DB
Geschrieben von
Rudolf Jansen
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.