Home 
ORDIX News 3/2005
ORDIX News 3/2005
ORDIX News 3/2005
u. a. um damit unabhängiger von der Datenbank zu werden.
Bei einer herkömmlichen JVM-Umgebung werden alle abhängigen Java-Klassen in Verzeichnissen ermittelt, die sich in der Umgebungs-variable CLASSPATH befnden. In der Oracle-JVM-Umgebung werden dagegen alle Klassen, die mit dem loadjava Kommando in die Datenbank geladen wurden, als Datenbankobjekte innerhalb eines Datenbankschemas abgelegt. Aus diesem Grund verfügt die OracleJVM-Umgebung über ein sogenanntes "Resolving-Konzept".
Resolving kann als eine Alternative zum CLASSPATH-Konzept verstanden werden und dient dem Auffnden aller von einer Klasse benötigten Klassen innerhalb der Datenbank.
Standardmäßig wird bei dem Resolving-Konzept im Schema des Datenbankbenutzers nach den abhängigen Klassen gesucht. War die Recherche erfolglos, so wird zusätzlich noch das Schema SYS durchsucht.
Soll das oben beschriebene Verhalten geändert werden, so kann eine sogenannte "Resolving-Liste" beim Laden der Klassen in die Datenbank festgelegt werden. Eine Resolving-Liste kann bei dem loadjava Kommando mit Hilfe der -resolver Option bestimmt werden. Mit der folgenden Syntax wird festgelegt, dass zuerst im Schema BK, danach im Schema MF und schließlich im Schema PUBLIC nach abhängigen Java-Klassen gesucht werden soll:
loadjava -resolver ((*BK)(*MF)(*PUBLIC)) ...
|
Des Weiteren kann eine Resolving-Liste auch beim direkten Erstellen einer Java-Klasse in der Datenbank mit dem Kommando CREATE JAVA festgelegt werden. Auch bei diesem Kommando kann die Resolving-Liste mit der Option -resolver bestimmt werden. Das in Abbildung 1 dargestellte Beispiel legt eine StartProg Klasse im Datenbankschema MF an. Diese StartProg Klasse referenziert auf eine MITARBEITER Klasse, die sich im Schema BK befndet.
Damit der Datenbankbenutzer MF auf die Klasse MITARBEITER im Schema BK zugreifen kann, muss der Datenbankbenutzer BK dem Datenbankbenutzer MF folgendes Recht erteilen:
GRANT EXECUTE ON "MITARBEITER" TO MF;
Soll eine Resolving-Liste zu einer Klasse geändert werden, so muss die Klasse entweder mit dem loadjava Kommando neugeladen oder mit dem CREATE JAVA Kommando neu erstellt werden. Eine Übersicht über die vorhandenen Resolving-Listen kann über die DBA_JAVA_RESOLVERS View ermittelt werden.
Wichtigster Punkt hierbei ist, dass sich eine Resolving-Liste, im Gegensatz zum CLASSPATH-Konzept, immer nur auf eine Java-Klasse bezieht. Beim CLASSPATH-Konzept wird die Suchreihenfolge der Klassen für den gesamten Rechner und somit für alle Java-Anwendungen, die auf dem Rechner ablaufen, festgelegt.
Nachdem die Java-Klassen in die Datenbank geladen wurden, müssen die Signaturen der Java-Klassen im "Data Dictionary" veröffentlicht werden. Für die Veröffentlichung von Java-Klassen werden die sogenannten PL/SQL-Wrapper verwendet. Mit Hilfe von PL/SQL-Wrappern werden die Java-Methoden und Parametertypen auf die Prozeduren und Parametertypen in der Datenbankprogrammiersprache PL/SQL abgebildet.
Die PL/SQL-Wrapper werden auch als Aufrufspezifkationen, Call Specs oder Java Stored Procedures bezeichnet. Aufrufspezifkationen können auf folgende Art und Weise defniert werden:
|
Das in Abbildung 2 dargestellte Beispiel zeigt eine Aufrufspezifkation (Java Stored Procedure) rechne_java, die auf der höchsten Ebene deklariert wird. Die rechne_java Aufrufspezifkation startet eine statische Methode rechne aus der Klasse Test und gibt den Parameter bis an die Java-Methode rechne weiter.
In der Datenbankprogrammiersprache PL/SQL können die Parameter einer Prozedur mit folgenden Modi defniert werden:
Bei der Programmiersprache Java dagegen werden die einfachen, primitiven Datentypen wie z. B. int oder char als Wert an eine Methode übergeben. Eine Übergabe als Wert bedeutet, dass bei einem Methodenaufruf der Parameterwert übergeben beziehungsweise kopiert wird.
Änderungen eines derartigen Parameters innerhalb einer aufgerufenen Methode haben somit keine Auswirkungen auf die aufrufende Methode. Die primitiven Java-Datentypen können dadurch als IN Parameter in der Datenbankprogrammiersprache PL/SQL abgebildet werden.
Java-Objekte werden dagegen als Referenz an eine Methode übergeben. Wird eine derartige Objektreferenz innerhalb einer Methode verändert, so hat dies Auswirkungen auf die aufrufende Methode. Demzufolge können Java-Objekte als IN OUT Parameter in PL/SQL abgebildet werden.
Java Stored Procedures können ähnlich einer PL/SQL Stored Procedure sowohl aus SQL als auch aus PL/SQL heraus aufgerufen werden. Abbildung 3 zeigt, wie Java Stored Procedures in einer Oracle Datenbank von externen Client-Anwendungen aufgerufen werden können.
|
Die Ausgabe von Java Stored Procedures wird standardmäßig in eine Trace-Datei unter dem USER_DUMP_DEST Verzeichnis auf dem Datenbankserver geschrieben. Damit die Ausgabe z. B. im SQL*Plus auf dem Bildschirm erscheint, müssen folgende Kommandos abgesetzt werden:
set serveroutput on
exec dbms_java.set_output(10000)
Die erste Anweisung legt fest, dass die Ausgaben von PL/SQL-Programmen ausgegeben werden sollen. Mit dem zweiten Kommando wird die Java-Ausgabe aktiviert. Die Prozedur dbms_java.set_output erwartet als Parameter die Größe des Ausgabebuffers in Bytes. Der Ausgabebuffer kann auf eine Größe zwischen 2000 Bytes und 1.000.000 Bytes gesetzt werden.
In der Datenbankprogrammiersprache PL/SQL besteht die Möglichkeit, mittels des UTL_FILE Packages auf Dateien, die sich auf dem Datenbankrechner befnden, zuzugreifen. Das UTL_FILE Package stellt allerdings nur eine sehr begrenzte Funktionalität zur Verfügung.
Java dagegen verfügt über eine weitaus umfangreichere Schnittstelle (API), wie z. B. das java.io Paket, um auf Dateien des Datenbankrechners zuzugreifen. Mit der Java-Schnittstelle ist es unter anderem möglich, Verzeichnisse auf dem Datenbankrechner anzulegen und diese zu entfernen.
Eine weitere praktische Anwendungsmöglichkeit von Java Stored Procedures in einer Datenbank ist die Verwendung des java.util.zip Paketes. Mit Hilfe des java.util.zip Paketes können Dateien im ZIP-Format komprimiert werden. Sollen Dateien komprimiert in der Datenbank abgelegt werden, so kann das Paket java.util.zip in einer Java Stored Procedure verwendet werden, die wiederum von einem
INSERT-Trigger aufgerufen wird.
Weiterhin können Java Stored Procedures für die Integration verschiedener IT-Systeme untereinander verwendet werden. Dabei können die verschiedenen IT-Systeme mit Hilfe der Java Stored Procedures z. B. eine gemeinsame Geschäftslogik nutzen oder untereinander Daten austauschen. Das Schaubild in Abbildung 4 zeigt, wie Java Stored Procedures und externe IT-Systeme miteinander kommunizieren können.
Stored Procedures.. |
Sollen in einer Programmeinheit viele rechenintensive Operationen ohne Datenbankzugriff durchgeführt werden, so ist die Programmiersprache Java mit Java Stored Procedures der Datenbank- programmiersprache PL/SQL vorzuziehen.
Der Grund hierfür liegt in der Eigenschaft der Programmiersprache Java, die für derartige rechenintensive Operationen optimiert ist. Erfolgen in einer Programmeinheit dagegen viele Datenbankzugriffe, so ist die für den Datenbankzugriff optimierte Datenbankprogrammiersprache PL/SQL zu empfehlen.
Im Rahmen dieser Ausarbeitung wurde aufgezeigt, wie Java-Programme in eine Oracle Datenbank geladen und in einer OracleJVM ausgeführt werden können. Dabei wurde dargelegt, wie Java-Klassen für die Ausführung im OracleJVM angepasst werden müssen.
Es ist deutlich geworden, dass mit Java Stored Procedures die Funktionalität einer Datenbank deutlich erweitert werden kann. Java-Funktionsbibliotheken können in die Datenbankprogrammiersprache PL/SQL mit Hilfe der Java Stored Procedures ohne großen Aufwand integriert und verwendet werden.
Damit sinkt der Programmieraufwand, da viele vorhandene Java-Funktionsbibliotheken, wie z. B. Logging-Mechanismen oder Assertions, eingebunden werden können, ohne diese in PL/SQL neu entwickeln zu müssen.
Ein weiterer Vorteil von Java Stored Procedures ist die Datenbankunabhängigkeit. Die Java Stored Procedures werden in der Programmiersprache Java erstellt und können auf jedem Rechnersystem mit Hilfe einer Java Virtual Machine interpretiert und ausgeführt werden.
Zudem wird der Datenbankzugriff einer Java Stored Procedure mit einem JDBC-Datenbanktreiber sichergestellt. Dieser ist für alle herkömmlichen Datenbanksysteme verfügbar.
Im Verhältnis zu einer herkömmlichen Java-Webanwendung sinkt bei der Verwendung von Java Stored Procedures die Programmausführungszeit. Denn die Java Stored Procedures sind in der Datenbank abgelegt und es ist ein direkter Datenzugriff innerhalb der Datenbank möglich. Damit wird die Netzlast minimiert und demzufolge eine gute Performance erzielt.
Abschließend lässt sich feststellen, dass die Programmiersprache Java zusätzlich zu der traditionellen und anerkannten Datenbankprogrammiersprache PL/SQL für die serverseitige Datenbankprogrammierung genutzt werden kann.
Diese beiden Programmiersprachen schließen sich für die serverseitige Datenbankprogrammierung nicht aus, sondern können sich ergänzen.
Markus Fiegler (info@ordix.de).
