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 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:
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 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
.
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:
LoggingFilter
.Gelegentlich gibt es weitere Gründe dafür, einen HTTP-Server vor den Trifork zu schalten:
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.
mod_jk
weiter an Trifork.NTLMFilter
. Dieser
ermittelt die Identität des Besuchers und setzt den
RemoteUser
.AuthenticationFilter
erzeugt unter
Verwendung des RemoteUser
mit Hilfe eines Zugriffs auf das
ADS ein User-Objekt.PortletFilter
prüft, ob der eingehende Request ein
PortletRequest
ist und leitet ihn gegebenenfalls an den
Portlet-Container weiter.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.web.xml
ermittelt der
Trifork, dass für den Request das ContentServlet
zuständig ist.
ContentServlet
fordert die Datei vom
DocumentManager
an.DocumentManager
holt sie im Live-Betrieb über die
FileDocumentSource
aus dem Online-Verzeichnisbaum, den die
Template-Engine erzeugt hatContentServlet
ermittelt den MIME-Typ des Dokumentes und liefert
den Inhalt statisch oder dynamisch aus, in Abhängigkeit vom MIME-Typ.ContentServlet
verarbeitet das Dokument als Velocity-Template.PortletContainer
weiter.PortletContainer
schickt einen Render-Request an das
angegebene Portlet und liefert den in der Response enthaltenen HTML-Code
zurück.ContentServlet
liefert die zusammengefügte Seite aus.AuthenticationFilter
nutzt die Gelegenheit und fügt einen
Cookie an, der die Authentifizierung beim nächsten Request erleichtert.