Java-Datenbank-Integration via UTL_TCP

Transkript

1 Java-Datenbank-Integration via UTL_TCP Klaus Friemelt MT AG Ratingen Schlüsselworte: Oracle JVM, Oracle 11g, Java 1.5/1.6, UTL_TCP, Socketlistener, ACL Einleitung Es gibt zahlreiche Beispiele, in denen eine Datenbank-Anwendung um Java-Komponenten erweitert werden soll. Dies kann ein Mailversand mit Anhängen sein oder eine MQ-Series- Anbindung oder eine dynamische PDF-Dokumentenerzeugung mit dem itext-paket. Die Liste von Java basierten Lösungen lässt sich da beliebig erweitern. Generell besteht die Möglichkeit, die Oracle JVM der Datenbank zu verwenden. Dabei trifft man aber häufig auf zwei Probleme. Einerseits geht das Einspielen von großen Anwendungen mit Tausenden von Klassen in die Datenbank mit dem loadjava-utility auch nicht immer problemlos vonstatten. Andererseits hinkt die Javaversion der Oracle JVM dem aktuellen Java-Versionsstand 1.6 hinterher (RDBMS Oracle 10g entspricht Java 1.4, RDBMS Oracle 11g entspricht Java 1.5). Diese Einschränkungen lassen sich mit dem Datenbank-Package UTL_TCP und einer beliebigen Java-Runtime-Umgebung auf Serverebene umgehen. Im Folgenden werden zwei unterschiedliche Integrationsmöglichkeiten aufgezeigt. Konventionelle Integration Das seit Version 8i bekannte Beispiel für eine einfache Javaklasse, die man direkt mit SQL*Plus in die Datenbank bringt, ist die zum Ausführen beliebiger Programme. Siehe dazu: Um die entsprechende Javaklasse wird ein PL/SQL-Wrapper gelegt (hier: jex.exec), anschließend werden per dbms_java.grant_permission() die nötigen Privilegien vergeben, und schon lassen sich aus PL/SQL beliebige Betriebssystemkommandos, Shellskripte oder Programme aufrufen. Auch auf diese Weise kann man bereits das Problem der Javaversionen umgehen. Ist auf dem Datenbankserver ein aktuelles JRE installiert, kann man aus der Datenbank die Javaanwendung mit diesem externen JRE aufrufen: SQL> exec jex.exec('java -classpath /oracle/demo/itext jar: /oracle/demo itextdemo /oracle/demo/output/123.pdf "Das ist eine Demo"'); SQL> exec jex.exec('/bin/ls -l /oracle/demo/output');

2 -rw-r--r-- 1 oracle oinstall 947 Sep 8 23: pdf -rw-r--r-- 1 oracle oinstall 976 Sep 6 14:38 out.pdf Nachteil hier jedoch: die externe JVM wird bei jedem Aufruf neu gestartet, was zeitliche Verzögerungen mit sich bringt. Integration mit UTL_TCP und Java Socketlistener Das hier verwendete Beispiel zeigt die dynamische Erzeugung eines einfachen PDF- Dokumentes aus der Datenbank heraus mittels eines PL/SQL-Aufrufs. Die Kommunikation zwischen der Datenbank und Java erfolgt über UTL_TCP, Verbindungsparameter sind die IP-Adresse und die Portnummer. Javaseitig ist ein Socketlistener implementiert, der für jeden eingehenden Aufruf einen eigenen Thread startet. Die folgende Abbildung zeigt das komplette Listing: Abb. 1: Listing des Socketservers

3 Die Klasse SocketServerThread liest dann über socket.getinputstream() solange Daten ein, bis sie auf ein EOF trifft. Anschließend erfolgt die Verarbeitung, die hier aus dem Erzeugen eines PDF-Dokumentes mit itext besteht. Über den OutputStream erfolgt dann die Rückmeldung an den aufrufenden Prozess. Die Details zeigt das folgende kommentierte Listing. Abb. 2: Listing des Thread-Komponente

4 Hier die einfache PL/SQL-Prozedur, welche die Anfragen über UTL_TCP erzeugt: Abb. 3: Listing der PL/SQL-Prozedur Als Remote-Host wird hier mit der IP-Adresse der Datenbankserver selbst angegeben. Das muss aber nicht zwangsläufig so sein, beispielsweise könnten zur Lastverteilung komplexe Javaanwendungen auch auf einen separaten Server mit eigener IP- Adresse ausgelagert werden. Der Server wird unter nohup als eigenständiger Prozess gestartet, so dass er auch nach Schließen des Terminals weiterläuft. Dies erfolgt durch ein kurzes Shellskript (start_javademo_nohup.sh in der folgenden Abbildung). Die Ausgabe von nohup könnte noch

5 umgeleitet werden in eine dedizierte Datei, hier im Beispiel läuft sie standardmäßig nach nohop.out. Neben dem Serverstart zeigt die Abbildung den Aufruf der Prozedur TCP_DEMO in SQL*Plus und die Serverausgabe. Abb. 4: Starten des Socketservers, SQL*Plus-Aufruf und erzeugtes PDF im Überblick Bemerkenswert ist hier, dass der erste Aufruf noch 301 Millisekunden dauert, der zweite jedoch nur noch im Bereich von 6 Millisekunden liegt. Nachdem die benötigten Klassen (in diesem Beispiel itext jar) einmal geladen sind, werden erneute Anfragen entsprechend schneller verarbeitet. Verwendet übrigens ein über den Socketlistener angebundenes Javaprogramm ein System.exit(), ist das leider auch das Ende für den Socketlistener, da damit die JVM beendet wird. Regulär wird der Socketprozess auf Kommandozeilenebene mittels kill -9 und seiner PID beendet. Ruft man aus PL/SQL einen nicht-gestarteten oder unerwartet beendeten Socketprozess auf, so wird das quittiert mit der Fehlermeldung: ORA-29260: network error: TNS:no listener Hier hätte man jetzt die Möglichkeit, mit der zuvor beschriebenen konventionellen Methode das Shellskript zum Starten des Socketlistener aufzurufen.

6 Eine Besonderheit unter 11g: Access Control Lists (ACLs) Die erste Überraschung erfolgt unter der Datenbankversion 11g beim Aufrufen von UTL_HTTP, UTL_SMTP oder UTL_TCP: ORA-24247: network access denied by access control list (ACL) Wegen Sicherheitsproblemen in der Vergangenheit hat Oracle die Verwendung der netzwerknahen Packages drastisch abgesichert. Mittels ACL müssen Netzwerkresourcen jetzt erst dediziert freigegeben werden. Dazu sind im Wesentlichen drei Schritte nötig. Zunächst wird vom Benutzer SYS eine ACL als XML-Datei mit dem (frei wählbaren) Namen utltcp.xml angelegt und der Rolle CONNECT das Privileg connect gewährt: begin dbms_network_acl_admin.create_acl (acl => 'utltcp.xml', description => 'Normal Access', principal => 'CONNECT', is_grant => TRUE, privilege => 'connect', start_date => null, end_date => null ); end; Dem Benutzer JAVADEMO für die ACL das Privileg connect gewähren: begin dbms_network_acl_admin.add_privilege(acl => 'utltcp.xml', principal => 'JAVADEMO', is_grant => TRUE, privilege => 'connect' ); end; Jetzt noch die Resource (hier der localhost mit dem Portbereich ) zuweisen: begin dbms_network_acl_admin.assign_acl( acl => 'utltcp.xml', host => ' ', lower_port => 44440, upper_port => ); end; Das erfolgreiche Anlegen kann überprüft werden mit den Abfragen: SELECT any_path FROM resource_view WHERE any_path like '/sys/acls/%.xml'; SELECT * FROM dba_network_acls; Damit ist auch unter 11g der Netzwerkzugriff durch das Package UTL_TCP möglich.

7 Zusammenfassung Mit nur drei kurzen Javaklassen, bzw. PL/SQL-Prozeduren hat man die Möglichkeit, beliebige Programme direkt aus PL/SQL heraus zu starten. Damit kann man Probleme mit den Javaversionen umgehen, speziell wenn man Archive von Drittanbietern einbindet. Des Weiteren kann man eine Lastverteilung erreichen, in dem der Javaprozess auf einer anderen Maschine als der Datenbankserver läuft. Darüber hinaus bietet der Socketlistener mit seiner vorgestarteten JVM deutliche Zeitgewinne gegenüber der konventionellen Integration einer externen JVM. Ein wichtiger Aspekt ist die Sicherheit: während bei Java in der Datenbank immer das Sicherheitsmodell aktiv ist und jedes Privileg dediziert mit dbms_java.grant_permission() zugewiesen wird, läuft im externen JRE alles mit den Rechten desjenigen, der den Socketlistener startet. Hier muss man in der Implementierung auf PL/SQL- oder Javaseite gegebenenfalls entsprechende Schranken vorsehen. Unter der Datenbankversion 11g kommt beim Zugriff auf Netzwerkressourcen via UTL_TCP, UTL_HTTP und UTL_SMTP als zusätzlicher Sicherheitsaspekt das neue Feature der Access Control List (ACL) zum Tragen. Kontaktadresse: Klaus Friemelt MT AG Balcke-Dürr-Allee 9 D Ratingen Telefon: +49(0) Fax: +49(0) klaus.friemelt@mt-ag.com Internet: