Architektur des Portal Managers

Technische Komponenten

Der Portal Manager ist eine standardkonforme Servlet-Applikation, die in einen Servlet-Container (wie unseren Trifork Application Server) deployed wird. Er besteht aus Filtern, Servlets und Beans sowie einigen weiteren unterstützenden Komponenten.

Filter

Filter analysieren und modifizieren eingehende Requests. Sie sind in einer so genannten Filter Chain organisiert. Jeder Request durchläuft vor der Beantwortung der Reihe nach einige oder alle Filter. Die Response durchläuft auf dem Weg zurück zum Benutzer noch einmal alle Filter in umgekehrter Reihenfolge. Die Filter können den Request und die Response je nach Aufgabe geeignet ergänzen, verändern oder gar blockieren. Je nach benötigter Funktionalität können Filter ausgetauscht, entfernt oder ergänzt werden. Die wichtigsten im Lieferumfang des Portal Managers enthaltenen Filter sind:

  • NTLMFilter
  • AuthenticationFilter
  • PortletFilter
  • ContentFilter
  • PermissionFilter

Servlets

Servlets dienen dazu, die Inhalte auszuliefern. Es gibt im Portal Manager ein Servlet für statische Inhalte (Binärdateien) und dynamische Inhalte, das ContentServlet.

Filter und Servlets werden – wie bei Java-Webanwendungen üblich – über die Datei web.xml konfiguriert.

Beans

Beans sind austauschbare Module, die Filtern und Servlets bestimmte Funktionen zur Verfügung stellen. Sie werden über die Datei pm.xml definiert und konfiguriert. Wichtige Beans sind beispielsweise userManager, portletContainer, documentManager, permissionManager.

Portal Manager und HTTP-Server

Prinzipiell ist jeder Servlet-Container auch ein Webserver. Dennoch ist es derzeit empfehlenswert, einen HTTP-Server vor den Trifork zu schalten. Wir empfehlen aus Gründen des hohen Bekanntheitsgrades und der Stabilität, den Apache HTTP-Server einzusetzen. Einen HTTP-Server zu verwenden, hat folgende Vorteile:

  • Es wird möglich, privilegierte Ports wie 80 oder 443 zu nutzen, ohne den Webserver als Superuser starten zu müssen. Dies ist gegenwärtig nur mit einem HTTP-Server möglich.
  • Um existierende Logdatei-Analysetools unverändert weiter nutzen zu können, benötigt man Logdateien im commons-logging-Format, die der Apache HTTP-Server erzeugt. Diese Dateien kann der Trifork Application Server derzeit nicht erzeugen. Ab Version 6.5 von CMS Fiona verfügt der Portal Manager über einen entsprechenden LoggingFilter.
  • Über den Apache HTTP-Server ist eine schnelle HTTPS-Verschlüsselung zu erreichen.

Gelegentlich gibt es weitere Gründe dafür, einen HTTP-Server vor den Trifork zu schalten:

  • Authentifizierung: Über den HTTP-Server können beliebige weitere Authentifizierungsmechanismen einen RemoteUser setzen, der dann vom PM ausgewertet wird.
  • Weitere Module wie zur URL-Manipulation, Response-Komprimierung, Bandbreitenbeschränkung o.ä. sind in Verbindung mit dem Portal Manager nutzbar.

Ablauf bei der Beantwortung eines Requests

Im Folgenden wird die Beantwortung eines typischen Requests bei der oben beschriebenen Konfiguration (HTTP-Server, Trifork, Portal Manager) erläutert. Es wird eine HTML-Datei angefordert, in der ein Portlet enthalten ist.

Die obige schematische Darstellung zeigt den Ablauf auch für JSPs und binäre Inhalte.

  • Ein Website-Besucher schickt über einen Browser einen HTTP-Request an Port 80 des Webservers.
  • Ein Apache nimmt den Request entgegen und leitet ihn über mod_jk weiter an Trifork.
  • Der Trifork ruft der Reihe nach folgende Filter für den Request auf:
    • Identification beispielsweise via NTLMFilter. Dieser ermittelt die Identität des Besuchers und setzt den RemoteUser.
    • Der AuthenticationFilter erzeugt unter Verwendung des RemoteUser mit Hilfe eines Zugriffs auf das ADS ein User-Objekt.
    • Der PortletFilter prüft, ob der eingehende Request ein PortletRequest ist und leitet ihn gegebenenfalls an den Portlet-Container weiter.
    • Der PermissionFilter prüft, ob es Zugriffsbeschränkungen für die angeforderte Datei gibt. Wenn ja, prüft er, ob der Besucher die Datei erhalten darf und bricht die Request-Bearbeitung ab, falls dies nicht der Fall ist.
  • Anhand der Konfiguration in der web.xml ermittelt der Trifork, dass für den Request das ContentServlet zuständig ist.
    • Das ContentServlet fordert die Datei vom DocumentManager an.
    • Der DocumentManager holt sie im Live-Betrieb über die FileDocumentSource aus dem Online-Verzeichnisbaum, den die Template-Engine erzeugt hat
    • Das ContentServlet ermittelt den MIME-Typ des Dokumentes und liefert den Inhalt statisch oder dynamisch aus, in Abhängigkeit vom MIME-Typ.
    • Eine HTML-Datei wird dynamisch ausgeliefert. Das ContentServlet verarbeitet das Dokument als Velocity-Template.
    • Die Velocity-Engine erkennt ein Kommando, mit dem ein Portlet eingefügt wird, und reicht die Anfrage an den PortletContainer weiter.
    • Der PortletContainer schickt einen Render-Request an das angegebene Portlet und liefert den in der Response enthaltenen HTML-Code zurück.
    • Das ContentServlet liefert die zusammengefügte Seite aus.
  • Alle Filter haben nun in umgekehrter Reihenfolge noch die Möglichkeit, die ausgehende Antwort zu modifizieren. Der AuthenticationFilter nutzt die Gelegenheit und fügt einen Cookie an, der die Authentifizierung beim nächsten Request erleichtert.