APEX-Webserver: Apache, Embedded Gateway oder J2EE Listener

Seit der Freigabe von APEX 4.0 gibt es drei Alternativen für den Betrieb des APEX-Webservers.

In diesem Tipp stellen wir Ihnen die drei Varianten mitsamt ihrer Besonderheiten bei der Installation vor. Bevor man jedoch mit dem Einrichten startet, stellt sich natürlich die Frage, welchen Webserver man nutzen sollte.

Bei Nutzung des PL/SQL Embedded Gateway wird die Aufgabe des Webservers von der Datenbank und dem Listener selbst übernommen - auf dem Datenbankrechner werden also keine weiteren Prozesse benötigt. Insofern ist der Setup sehr einfach und die Administration des Webservers ist mit der normalen Datenbankadministration abgedeckt. Allerdings bietet das Embedded Gateway nicht so viele Webserver-Features wie ein Apache - so gibt es kein URL Rewriting, keine virtuellen Hosts, keine Proxy- und keine speziellen Authentifizierungsmodule. Insofern eignet sich das Embedded Gateway vor allem für Entwicklermaschinen und kleinere Intranet-Umgebungen. Aus Lizenzsicht ist das Embedded Gateway mit der Datenbanklizenz abgedeckt. Für SSL-Zugriff ist allerdings eine Lizenz sowohl der Enterprise Edition der Datenbank als auch der Advanced Security Option erforderlich.

Architektur von Application Express mit dem PL/SQL Embedded Gateway

Abbildung 1: Architektur von Application Express mit dem PL/SQL Embedded Gateway

Der Apache Webserver mit mod_plsql ist vor allem für APEX-Installationen mit Zugriff aus dem Internet oder für solche mit höheren Anforderungen an die Möglichkeiten des Webservers geeignet. So können mit URL Rewriting des Apache Webservers "sprechende URL" eingerichtet werden, virtuelle Hosts, Proxy-Server und andere Optionen sind kein Thema. Allerdings ist das mod_plsql, welches die eigentliche Verbindung zwischen APEX und dem Apache Webserver herstellt, nur im Apache-Server von Oracle (Oracle HTTP Server, OHS) verfügbar - es kann nicht in eine andere Apache-Variante integriert werden. Insbesondere bei standardisierten Infrastrukturen wird daher vielfach ein zweiter Webserver benötigt, da für den OHS keine Betriebskonzepte vorliegen. Solange der OHS nur für APEX genutzt wird und auf der gleichen Maschine läuft, sind keine separaten Lizenzen erforderlich. Wird der OHS dagegen auf einem anderen Rechner installiert, so sind für diesen Rechner Oracle Fusion Middleware-Lizenzen erforderlich.

Architektur von Application Express mit dem Apache Webserver und mod_plsql

Abbildung 2: Architektur von Application Express mit dem Apache Webserver und mod_plsql

Der APEX J2EE Listener ist eine vollständig auf Java basierende Implementierung des mod_plsql. Es wird als WAR-Archiv zur Verfügung gestellt - dieses Format ist für J2EE-Anwendungen üblich. Und wie andere J2EE-Anwendungen kann auch der APEX Listener in unterschiedliche Application Server installiert werden - der Installation Guide erwähnt Tomcat, Oracle Weblogic Server und Oracle OC4J. Andere Application Server sind ebenso denkbar. Interessant sind die zusätzlichen Features des APEX Listeners. So bietet er einen erweiterten Datei-Upload an; Excel-Dateien können automatisch und ohne zusätzliches Coding direkt in APEX-Collections hochgeladen werden. Der APEX-Listener selbst muss nicht lizensiert werden. Der Betrieb des APEX Listeners auf einem freien Applikationsserver wie Tomcat ist demnach lizenzkostenfrei - wird er auf lizenzpflichtiger Software wie Oracle Weblogic betrieben, so muss diese lizensiert werden.

Architektur von Application Express mit dem APEX J2EE Listener

Abbildung 3: Architektur von Application Express mit dem APEX J2EE Listener

PL/SQL Embedded Gateway

Das PL/SQL Embedded Gateway ist ein eigener HTTP-Server direkt in der Datenbank. Technische Grundlage sind die Protokollserver der XML DB. Der HTTP-Endpoint wird durch den normalen Oracle Listener bereitgestellt, die HTTP-Anfragen der Browser werden durch Shared Server Prozesse der Datenbank bearbeitet. Mehr zur Architektur der XML DB Protokollserver findet sich im XML DB Developers' Guide der Oracle-Dokumentation.

Das Embedded Gateway wird mit Hilfe des PL/SQL-Pakets DBMS_EPG eingerichtet. Für APEX müssen Sie aber gar nicht mit diesem Paket arbeiten - es sind fertige Konfigurationsskripte vorhanden.

  1. Starten Sie als SYS das Skript $ORACLE_HOME/apex/apxconf.sql. Es fragt Sie nach dem HTTP-Port, den Sie für Application Express verwenden möchten, und führt dann die nötigen Konfigurationsschritte durch.
  2. Starten Sie im APEX-Verzeichnis als SYS das Skript apex_epg_config.sql. Als Parameter geben Sie das Verzeichnis, in das Sie das heruntergeladene APEX-Archiv ausgepackt haben, an.
  3. Entsperren Sie den Datenbanknutzer ANONYMOUS. Geben Sie dazu als (ebenfalls als SYS) folgendes Kommando ein: 
    alter user ANONYMOUS account unlock

Auch hierzu finden sich ausführliche Hinweise in der Oracle Dokumentation zu Application Express.

Oracle HTTP Server (Apache mit mod_plsql)

Der Apache Webserver wird separat heruntergeladen und installiert. Der Download-Link ist auf der OTN-Seite der Oracle-Datenbank enthalten. Abbildung 4 zeigt den Link für den Oracle HTTP Server auf der Download-Seite von Oracle11g Release 2 für Windows. Allerdings ist die OHS-Version von der Datenbankversion völlig unabhängig, da er in ein eigenes ORACLE_HOME installiert wird. Sie können also durchaus den OHS, den Sie von der Oracle11g-Seite heruntergeladen haben, mit einer Oracle10g-Datenbank verwenden.

Download Oracle HTTP Server (Apache mit mod_plsql)

Abbildung 4: Download Oracle HTTP Server (Apache mit mod_plsql)

Zur Installation des OHS rufen Sie das Installationsprogramm (runInstaller oder setup.exe) auf. Nach der Installation

  • Für Application Express wird von Oracle nun auch die Apache-Version 2.0 ausgeliefert. Und diesen Apache 2.0 können Sie nicht nur mit Oracle11g, sondern auch mit Application Express auf einer Oracle10g-Datenbank nutzen.
  • Für Oracle11g gibt es keine Companion CD mehr, der Apache 2.0 steht demnach als separater Download im Oracle Technet zur Verfügung.

Die Konfiguration des mod_plsql im Apache 2.0 erfolgt wie gehabt und ohne Unterschiede zu früheren Versionen. Sie ist in der Dokumentation zu Application Express im Installation Guide beschrieben.

Architektur von Application Express mit dem Apache Webserver und mod_plsql

Abbildung 1: Architektur von Application Express mit dem Apache Webserver und mod_plsql

PL/SQL Embedded Gateway

Das PL/SQL Embedded Gateway ist ein eigener HTTP-Server direkt in der Datenbank. Technische Grundlage sind die Protokollserver der XML DB . Der HTTP-Endpoint wird durch den normalen Oracle Listener bereitgestellt, die HTTP-Anfragen der Browser werden durch Shared Server Prozesse der Datenbank bearbeitet. Mehr zur Architektur der XML DB Protokollserver findet sich im XML DB Developers' Guide der Oracle-Dokumentation.

Architektur von Application Express mit dem PL/SQL Embedded Gateway

Abbildung 2: Architektur von Application Express mit dem PL/SQL Embedded Gateway

Das Embedded Gateway wird mit Hilfe des PL/SQL-Pakets DBMS_EPG eingerichtet. Wenn Sie eine Oracle11g-Datenbank installiert und aufgesetzt haben, müssen Sie das Paket jedoch nicht bemühen; es ist alles vorbereitet. Es sind nur zwei Schritte nötig:

  1. Starten Sie als SYS das Skript $ORACLE_HOME/apex/apxconf.sql. Es fragt Sie nach dem HTTP-Port, den Sie für Application Express verwenden möchten, und führt dann die nötigen Konfigurationsschritte durch.
  2. Entsperren Sie den Datenbanknutzer ANONYMOUS. Geben Sie dazu als (ebenfalls als SYS) folgendes Kommando ein: 
    alter user ANONYMOUS account unlock

Auch hierzu finden sich ausführliche Hinweise in der Oracle Dokumentation zu Application Express.

Bevor wir nun zu einer Gegenüberstellung von Apache und PL/SQL Embedded Gateway und zu konkreten Empfehlungen kommen, lesen Sie im folgenden noch einige Informationen zum Umgang mit dem Embedded Gateway.

Performance-Optimierungen für das Embedded Gateway

Nach der Standardeinrichtung durch das Skript apxconf.sql funktioniert das Embedded Gateway; allerdings sind die Einstellungen nicht unbedingt optimal. Mit den folgenden Tipps lässt sich die Performance durchaus noch verbessern:

  • Setzen Sie (als DBA) die Parameter shared_servers und max_shared_servers so, dass Serverprozesse (Shared Server) in hinreichender Anzahl bereitstehen: 
    alter system set shared_servers=5 scope=both
alter system set max_shared_servers=20 scope=both
    Im Serverbetrieb können Sie als "Daumenregel" annehmen, dass ein Shared Server Prozeß 10 Datenbankverbindungen betreiben kann. Mit 5 Shared Server-Prozessen kommen Sie normalerweise also problemlos aus.
  • Auch die Anzahl der Dispatcher ist von Bedeutung; diese nehmen die Browser-Anfragen entgegen - auch hier ist es meist sinnvoll, mehr als einen Dispatcher zu starten. Der Parameter dispatchers ist bei Ihnen schon gesetzt, wir ändern nur die Anzahl - es kommt auf den rot markierten Teil an: 
    alter system set dispatchers='(PROTOCOL=TCP) (SERVICE=[Hier Datenbank-SID einsetzen]XDB) (DISPATCHERS=3)' scope=both
    Wenn die SID Ihrer Datenbank also orcl ist, sieht der Parameter so aus: 
    alter system set dispatchers='(PROTOCOL=TCP) (SERVICE=orclXDB) (DISPATCHERS=3)' scope=both

Image Caching sicherstellen

Die Bilder, welche im Rahmen der Application Express Benutzeroberfläche dargestellt werden, ändern sich bekanntlichermaßen erst mit dem nächsten APEX Release - es ist also in jedem Fall sinnvoll, diese im Browser-Cache zu halten.

In Application Express 3.1 ist dies auch völlig unproblematisch. Der Browser und die Application Express Engine kommunizieren entsprechend miteinander so dass der Browser, wenn er das Bild schon im Cache hat, dieses nicht mehr vom Server anfordert. Mit APEX 3.0 oder auf einer XE-Datenbank funktioniert dies allerdings nicht immer wie gewünscht. Wenn Sie feststellen, dass die Bilder bei Ihnen mit jedem Seitenaufbau (F5) stets neu vom Server geladen werden (Abbildung 3), kann folgende Anweisung (als DBA ausführen) Abhilfe schaffen. 

BEGIN  
  DBMS_EPG.SET_DAD_ATTRIBUTE (   
    dad_name    => 'APEX',   
    attr_name   => 'cgi-environment-list',   
    attr_value  => 'HTTP_IF_NONE_MATCH'
  );   
  DBMS_EPG.SET_DAD_ATTRIBUTE (  
     dad_name    => 'APEX',  
     attr_name   => 'cgi-environment-list',  
     attr_value  => 'IF_MODIFIED_SINCE'
  );  
END;   
/

Auf einer APEX 3.1-Umgebung ist das normalerweise nicht erforderlich.

Firebug-Ausgabe: Bilder wurden vom Server geladen und nicht aus dem Cache geholt

Abbildung 3: Test mit dem Firebug-Plugin: Bilder wurden vom Server geladen und nicht aus dem Cache geholt

Den HTTP Port nachträglich ändern

Um den HTTP Port des Embedded PL/SQL Gateway nachträglich zu ändern, benötigen Sie nur einen PL/SQL Aufruf: 

begin
  dbms_xdb.sethttpport(8080);
end;

Wenn Sie auf einem Unix oder Linux-System einen Port unter 1024 nutzen möchten, müssen Sie ein wenig mehr tun - eine Beschreibung der nötigen Schritte finden Sie in der Dokumentation zur Oracle XML DB.

Embedded Gateway und sichere Verbindungen (SSL)

Das PL/SQL Embedded Gateway kann auch im SSL-Modus betrieben werden. Dabei sind jedoch zwei Voraussetzungen zu beachten:

  • Diese Funktionalität ist Teil der Advanced Security Option
  • Sie benötigen ein Server Zertifikat, mit welchem sich die Datenbank gegenüber dem Webbrowser "ausweist".

Genaue Anweisungen zur Konfiguration des PL/SQL Embedded Gateway mit SSL finden Sie im Handbuch zur Oracle XML DB.

Logging

Verwendet man den Apache, ist alles ganz einfach. Wenn es ein Zugriffsproblem gibt und auf dem Bildschirm nur die berühmte HTTP 404 oder HTTP 500-Meldung erscheint, schaut man am besten in die Datei error_log hinein - dort findet man dann in aller Regel einen ORA-Fehlercode, der beim Analysieren des Problems weiterhilft.

Standardmäßig findet beim PL/SQL Embedded Gateway keinerlei Logging statt. Auch im Fehlerfall sieht man außer der HTTP Fehlermeldung oder einem ggfs. leeren Bildschirm nichts. Bei Problemen sollte also zunächst das Logging aktiviert werden - und zwar wie folgt: 

/*
 * Log levels for the global attribute "log-level"
 *
 * LOG_EMERG   CONSTANT PLS_INTEGER := 0;
 * LOG_ALERT   CONSTANT PLS_INTEGER := 1;
 * LOG_CRIT    CONSTANT PLS_INTEGER := 2;
 * LOG_ERR     CONSTANT PLS_INTEGER := 3;
 * LOG_WARNING CONSTANT PLS_INTEGER := 4;
 * LOG_NOTICE  CONSTANT PLS_INTEGER := 5;
 * LOG_INFO    CONSTANT PLS_INTEGER := 6;
 * LOG_DEBUG   CONSTANT PLS_INTEGER := 7;
 */

begin
  dbms_epg.set_global_attribute(
    attr_name  => 'log-level',
    attr_value => dbms_epg.log_debug
  );
end;
/

commit
/

Von nun an werden Debugging-Informationen in die Datenbank-Tracedateien geschrieben (user dump destination). Der Loglevel LOG_DEBUG führt zu recht umfangreichen Informationen. Aus Performancegründen sollten Sie das Logging (wie immer) nur einschalten, wenn Sie es tatsächlich benötigen - es kostet ebenfalls Ressourcen. 

Embedded PL/SQL Gateway: (wpdenv.c,681) script_name='/apex' path_info='/apex'script_prefix='' dad_name='apex'
Embedded PL/SQL Gateway: (wpdenv.c,795) User-Agent is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv ...
Embedded PL/SQL Gateway: (wpdenv.c,1415) dadname = 'apex', path_info = 'apex'
Embedded PL/SQL Gateway: (wpdenv.c,1454) Service will NOT use dynamic auth
Embedded PL/SQL Gateway: (wpx.c,394) Initialized successfully 0
Embedded PL/SQL Gateway: (wpx.c,316) SetRemoteUser : Remote User set to ANONYMOUS for this request.
Embedded PL/SQL Gateway: (wpx.c,480) Auth info from .APP file is being used
Embedded PL/SQL Gateway: (wpd.c,1729) Attempting to logon with '(unknown)'
Embedded PL/SQL Gateway: (wpu.c,1500) DBCharSet=>AMERICAN_AMERICA.AL32UTF8 OWAVersion=10.1.2.0.8 (101208) OWAMatch=>1 (rc=0)
Embedded PL/SQL Gateway: (wpd.c,1763) Logged in as (unknown)
Embedded PL/SQL Gateway: (wpx.c,593) Going to select...
Embedded PL/SQL Gateway: (wpx.c,647) Have been asked to execute a request
:

Mit Hilfe des Loggings können Sie auch eine weitere Eigenheit des Embedded Gateways ergründen - dazu der nächste Abschnitt.

Eigene PL/SQL Prozeduren direkt per URL aufrufen

Im Gegensatz zum Apache erlaubt das Embedded Gateway den direkten Aufruf von eigenen PL/SQL-Prozeduren nicht. Wenn Sie also als Beispiel im Parsing Schema Ihrer APEX-Anwendung die folgende Prozedur erzeugen und die Ausführungsprivilegien an alle vergeben ... 

create or replace procedure testhtp 
is 
begin 
  htp.p('TEST'); 
end;
/

grant execute on testhtp to public
/

... und diese Prozedur dann im Browser aufrufen ...

1. Versuch: Direkter Aufruf einer eigenen PL/SQL Prozedur mit dem Embedded Gateway

Abbildung 4: 1. Versuch: Direkter Aufruf einer eigenen PL/SQL Prozedur mit dem Embedded Gateway"

... stellen Sie fest, dass dies offensichtlich nicht erlaubt ist. Verwendet man den Apache, funktioniert es ohne Probleme. Woran liegt das? Ein Blick in die Logging-Informationen gibt Auskunft: 

Embedded PL/SQL Gateway: (wpd.c,2536) attempt to call forbidden procedure!
Embedded PL/SQL Gateway: /apex/PARTNER.TESTHTP HTTP-403 It is forbidden to call this procedure directly from the browser!
Embedded PL/SQL Gateway: (wpu.c,626) longjumping back to the beginning
Embedded PL/SQL Gateway: (wpu.c,488) cleaning up before longjmp
Embedded PL/SQL Gateway: (wpu.c,492) doing a rollback
Embedded PL/SQL Gateway: (wpcs.c, 76) Executed 'rollback' (rc=0)
Embedded PL/SQL Gateway: (wpcs.c, 76) Executed 'begin dbms_session.reset_package; end;' (rc=0)
Embedded PL/SQL Gateway: (wpd.c,1818) Going to close cursor

Das PL/SQL Embedded Gateway erlaubt das direkte Aufrufen nur für die Prozeduren der APEX-Engine. Möchte man (wie im Beispiel) auch andere Prozeduren aufrufen, müssen diese freigeschaltet werden. Dir Prüfung erfolgt, indem das Embedded Gateway die Prozedur wwv_flow_epg_include_mod_local im Schema der APEX-Engine (hier: FLOWS_030100) aufruft. Standardmäßig liefert diese stets false zurück. Spielen Sie also als SYS folgende Prozedur ein. 

alter session set current_schema=FLOWS_030100
/

CREATE OR REPLACE function wwv_flow_epg_include_mod_local(
  procedure_name in varchar2
) return boolean
is
begin
  --
  -- Administrator note: the procedure_name input parameter may be in the format:
  --
  --    procedure
  --    schema.procedure
  --    package.procedure
  --    schema.package.procedure
  --
  -- If the expected input parameter is a procedure name only, the IN list code shown below
  -- can be modified to itemize the expected procedure names. Otherwise you must parse the
  -- procedure_name parameter and replace the simple code below with code that will evaluate
  -- all of the cases listed above.
  --
  if upper(procedure_name) in ('PARTNER.TESTHTP') then
      return TRUE;
  else
      return FALSE;
  end if;
end wwv_flow_epg_include_mod_local;
/

Ein neuer Versuch mit dem Browser funktioniert nun. Natürlich können Sie die Namen der Prozeduren auch in einer Tabelle speichern und im PL/SQL Code anhand dieser Tabelle prüfen, ob das Aufrufen der Prozedur erlaubt ist. Das einfachste denkbare Beispiel wäre, stets true zurückzugeben - damit würde sich das Embedded Gateway genauso wie der Apache verhalten.

Direkter Aufruf einer eigenen PL/SQL Prozedur mit dem Embedded Gateway nach Freischaltung

Abbildung 5: Direkter Aufruf einer eigenen PL/SQL Prozedur mit dem Embedded Gateway nach Freischaltung

Pro und Kontra ...

Nun stellt sich natürlich die Frage, ob man Application Express wie bisher mit dem Apache Webserver oder mit dem PL/SQL Embedded Gateway betreiben soll. Performance ist in aller Regel kein Kriterium - beide Varianten lassen sich so einrichten, dass man performant damit arbeiten kann.

Zwar nutzt die "ready to use"-Installation von Application Express in Oracle11g das Embedded Gateway - daraus kann aber keine generelle Empfehlung abgeleitet werden. Vorteile hat sowohl das Embedded Gateway ...

  • Das Aufsetzen ist wesentlich leichter. Es muss kein DAD für das mod_plsql eingerichtet werden und nach dem Starten der Datenbank kann Application Express sofort genutzt werden.
  • Alle statischen Dateien (Bilder, JavaScript) und alle Konfigurationsdetails befinden sich in der Datenbank - sind also ohne weiteres Zutun in jedem Datenbank-Backup enthalten.

... als auch der Apache Webserver:

  • Mit dem Apache kann der Webserver auf eine andere Maschine verlagert werden. So kann eine Application Express-Anwendung auch ins Internet gestellt werden. Der Webserver befindet sich dann außerhalb, die Datenbank (selbstverständlich) innerhalb der Firewall. Man kann sogar noch weiter gehen und einen Apache ohne mod_plsql außerhalb und einen Apache mit mod_plsql innerhalb der Firewall platzieren. Das Apache-Modul "mod_proxy" leitet die Anfragen dann von einem Webserver zum anderen.
  • Statische Dateien können ins Dateisystem gelegt werden; dies nimmt in stark beanspruchten Systemen Last von der Datenbank.
  • Der Apache erlaubt dank seiner Module eine umfassendere und ausgefeiltere Konfiguration des Systems - dazu zwei Beispiele:

    • Das Einrichten von sprechenden URL für bestimmte Anwendungen ist nur mit dem Apache möglich, da das Apache mod_rewrite hierfür genutzt wird.
    • Das Modul mod_proxy erlaubt das Weiterleiten von bestimmten Anfragen an andere Server; für den Browser sieht es jedoch so aus, als ob alle Anfragen vom Apache bedient werden.

Schlußfolgerungen

Das PL/SQL Embedded Gateway eignet sich gut für kleinere Einzelplatz- oder Abteilungssysteme. So ist es eine gute Wahl für einen Entwickler-Arbeitsplatz. Die Administration und Wartung ist wesentlich einfacher - man startet die Datenbank und kann Application Express sofort nutzen.

Für größere Installationen, bspw. für unternehmensweite Installationen oder Hosting-Systeme, ist das PL/SQL Embedded Gateway wahrscheinlich nicht geeignet. Für solche Systeme reichen die Möglichkeiten des Gateways nicht aus; Apache-Module werden für URL-Rewriting, Log-Mechanismen, Proxy-Server und andere Funktionen benötigt, so dass am Apache Webserver kein Weg vorbeiführt.

Zurück zur Community-Seite