Landesintranet Niedersachsen auf Linux/PHP-Basis

Aufgabe des Retrieval Managers ist mithin die Bestandsaufnahme der dezentralen Unternehmensdaten. Welche Datenquellen auf welchen Rechnern zu erfassen sind, wird von den Administratoren im webbasierten Backend des Dachportals konfiguriert. Als flexible Kommunikations- und Steuerungszentrale für den Informations- und Dokumentenfluss zwischen den verschiedenen Softwarebestandteilen, gibt der Retrieval Manager diese Quellenkonfigurationen an die eingesetzten Web- bzw. Filesystem-Crawler sowie andere Konnektoren weiter und startet die Crawlprozesse. Die Dokumente werden in eine Warteschlange (Queue) zurückgeliefert. Ein Queue-Plugin übernimmt die weitere Verarbeitung: Die Dokumente aus der Warteschlange werden mit einem Filterserver zunächst nach HTML gewandelt, dann mittels einer Klassifizierungssoftware den angelernten Rubriken des Webkatalogs zugeordnet und schließlich in einen (assoziativen) Volltextindex inseriert. Alle rechenintensiven Anwendungen werden konsequent über Webservices angebunden. Die Kommunikation ist dabei in der Regel asynchron, d.h. der Retrieval Manager selbst und die einzelnen Webservices besitzen jeweils SOAP Client und Server. So sind je nach Anwendung mindestens 6 SOAP Server aktiv, wobei 90% der Kommunikationslast in der gewählten Standardinstallation (alle Komponenten bis auf das Dachportal EIP selbst sind auf demselben Rechner installiert) auf localhost anfallen, also rein interne Kommunikation ist. Was sind Vorteile dieser aufwändigen und auf den ersten Blick mit viel Kommunikationsoverhead belasteten Architektur? Folgende Gründe waren für die Entwicklung ausschlaggebend:

Der Hauptgrund war allerdings unser Wunsch, die eigentliche Steuerungszentrale als möglichst flexible PHP-Applikation zu schreiben, um schnell auf die unterschiedlichen Gegebenheiten in verschiedenen Organisationen reagieren zu können. Damit auch sehr große Datenmengen (mehrere hunderttausend Dokumente bzw. mehrere GB an Daten) verarbeitet werden können, ist der Ablauf dieser Verteilungsprozesse - getrennt vom eigentlichen Crawlen - in eine zentrale Queueverwaltung eingebettet. Durch die gewählte Architektur ist diese mitunter komplexe Verteilerlogik jetzt als (PHP-)Queue-Plugin im Retrieval Manager programmiert und kann, da PHP Code, leicht geändert werden. Interessant zu erwähnen ist, dass unsere Performancetests ergeben haben, dass die starke Kommunikation der Webservices und die in PHP implementierten Programmteile (Retrieval Manager mit Queueverwaltung, PHP-Queue-Plugin) keine nennenswerte CPU-Zeit in Anspruch nehmen: 99% der CPU-Zeit wird in den einzelnen Komponenten wie Filtersoftware, Klassifikation oder Crawler verwendet. Auf PHP Seite wurde NuSOAP für die Implementation der Webservices eingesetzt.

Baut man mit dem eingesetzten ECMS "Powerslave" Webapplikationen wie z.B. ein Intranet mit Redaktionssystem auf, laufen im Hintergrund u.a. folgende Prozesse ab:

Die Grundidee bei der Umsetzung der zentralen Mandanten ist, dass alle zentralen Mandanten dieselben Powerslave-Module benutzen, i.e. dieselben Datenbanktabellen, Filesysteme und Templates. Die Trennung der Mandanten erfolgt auf der untersten SQL-Ebene durch Erweiterung der Datenbanktabellen um ein weiteres Attribut "MandantenID" und Modifikation des automatisch erzeugten Programmcodes um WHERE-Bedingungen, die alle Datenbankzugriffe auf den jeweiligen Mandanten einschränken.

Die nächst "dezentraleren" Lösungen bestehen darin, alle Module für jedes Intranet zu duplizieren bzw. neu aufzubauen. Entweder auf demselben Server mit denselben Datenbanken wie die zentralen Mandanten oder auf neuen virtuellen oder echten Servern, ggf. mit weiteren Liveservern und Datenbankservern (vergl. Bild3 ).

Aus den unterschiedlichen Varianten ergeben sich unmittelbar Vorteile und Grenzen der implementierten Lösungen. Als Vorteil der zentralen Variante kann die Tatsache gewertet werden, dass nicht für jeden Mandanten neue Tablespaces in der Datenbank oder neue virtuelle Server angelegt werden müssen. Fragen der Skalierbarkeit betreffen dann vorrangig die eingesetzte Datenbank. Mandanten mit Standardvorgaben (z.B. erste Navigationsebene automatisch importiert, Administratoren und Beispielnutzer des Mandanten mit Standardrechten automatisch erzeugt,...) können mit wenigen Mausklicks von den verantwortlichen Nicht-Technikern neu angelegt werden, wie in Bild4 gezeigt. Diese einfache Bedienbarkeit ist ein Grund, dieselbe Funktionalität auch für das Anlegen der eigenständigen Projektgruppen und Communities im Dachportal (s.o.) zu verwenden. Änderungen am Datenmodell, den Templates oder generelle Softwareupdates werden unmittelbar für alle Mandanten wirksam.

Bild4 - Mandantenverwaltung für zentrale Mandanten:

Jeder dieser Vorteile kann in anderem Kontext natürlich zum Nachteil werden: So möchten manche Dienststellen eigene Templates benutzen, eigene Applikationen entwickeln, die nicht von allen Behörden genutzt werden können/sollen/dürfen, Modifikationen im Datenmodell speziell für ihre Bedürfnisse vornehmen und echt getrennte Datenbanken, Filesysteme und Webserver verwenden. Deswegen ist es im Landesintranet Niedersachsen ebenfalls vorgesehen, zentrale Mandanten zu einem bestimmten Zeitpunkt abzukoppeln. Ab diesem Zeitpunkt müssen allerdings alle Änderungen an den zentralen Mandanten, die der dezentrale Mandant mitmachen möchte, manuell nachgezogen werden (Redundanz in den Templates, etc.). Wir erwarten derzeit, dass ca. 95% aller Mandanten im Behördennetz auf die zentrale Lösung setzen werden.

Neue Applikationen können vom Entwickler sehr schnell mit der grafischen Entwicklungsumgebung - der Powerslave Enterprise Workflow Engine - erstellt werden. Solche Applikationen können dann entweder im "normalen" Intranet erscheinen oder als Portlets auf dem persönlichen Desktop laufen. Im Landesintranet Niedersachsen sind u.a. folgende Portlets vorgesehen: Suche, Ergebnisdarstellung, Projekträume mit Dokumenten-Collections, 2D und 3D Visualisierungen des semantischen Kontextes von Suchanfragen, Kalenderblatt, ECMS inklusive WYSIWYG Editor.

Bild7 - Suchportlet in grafischer Entwicklungsumgebung:

Bild7 zeigt das Portlet für die Suche im grafischen Editor. Der Programmfluss der Applikation wird dabei wie es Workflows bekannt ist als Graph mit Knoten und Kanten modelliert, wobei der eigentliche (PHP-)Programmcode in diesen Elementen verborgen ist. Der Ablauf des Programms ist vollständig ereignisgesteuert. Ereignisse können z.B. im Frontend durch Klicken auf Links oder Formularaktionen ausgelöst werden. Jedem Ereignis kann ein beliebig komplexes (PHP-)Datenobjekt mitgegeben werden. Im graphischen Editor der Workflowengine werden solche und andere Objekte anspruchsvoll visualisiert und dem Administrator in einem Objektbrowser zur Entwicklung angeboten. Im Falle unseres Suchportlets enthält das Ereignisobjekt beispielsweise den Text der Suchanfrage und den gewünschten Zeitraum, auf den die Treffer eingeschränkt werden sollen. Das Frontend zu einem Portlet wird mit Hilfe von Templates realisiert, so dass die eigentliche Programmfunktionalität sauber vom grafischen Ein- und Ausgabefrontend getrennt ist. Das Wechselspiel von Events und templategesteuerter Ausgabe ist in Bild8 als Zeit-Sequenz-Diagramm verdeutlicht.

Bild8 - Zeit-Sequenz-Diagramm beim ereignisgesteuerten Aufbau einer Seite:

Festzuhalten bleibt, dass die Entwicklungsgeschwindigkeit durch die Einführung einer ereignisbasierten Vorgehensweise (statt mit URLs oder herkömmlichen Formularaktionen zu arbeiten) wesentlich beschleunigt wird. Die Workflowengine stellt dabei mehrere Client-Server-Eventhandler zur Verfügung, u.a. für HTML-Links und -Formulare, Javascript (z.B. für die Drag und Drop Funktionen), Actionscript/Flash und VMRL. Des Weiteren existieren bereits vordefinierte Portlets, die man wieder verwenden kann: Eine besondere Rolle spielt hier das so genannte "Browser-Portlet" zur Einbindung externer Webapplikationen (beispielsweise Lotus Notes) inklusive Single-Sign-On auf dem persönlichen Desktop.

Sollen viele solcher Portlets oder Applikationen auf einem personalisierten Desktop erscheinen, sind weitere Softwarekomponenten nötig: Die Desktop-Logik selbst ist dabei ebenfalls als Workflow umgesetzt. Dieser Workflow (genauer: eine Instanz dieses Workflows) wird dem eingeloggten Benutzer zugeordnet und verwaltet alle seine Portlets (in diesem Sinne ebenfalls Workflowinstanzen), die auf seinem persönlichen Desktop ausgeführt werden. Von dieser Desktop-Logik werden auch alle neue Portlets gestartet und Fensteroperationen zum Minimieren, Maximieren und Schließen von Applikationen ausgeführt. Vom Nutzer im Frontend ausgelöste Ereignisse werden auf das zugehörige Portlet auf seinem persönlichen Desktop eingeschränkt, was die Performance im Vergleich zu globalen Ereignissen, die an alle laufenden Portlets aller Nutzer gesendet werden, natürlich erheblich steigert. Bild9 zeigt die Möglichkeit, Ereignisse auf bestimmte Ressourcen (Personen, Datensätze, Portlets, Desktops, ...) einzuschränken. Der Desktop entspricht somit ungefähr den Portletcontainern in Java-Umgebungen. Da die Fenster mit Hilfe von Templates (mit Titelleiste, den Fensteroperationen, Drag und Drop Punkten...) ausgegeben werden, ist es ein Leichtes, das gesamte Corporate Design der Organisation anzupassen.

Bild9 - Eventhandler in der Workflowengine:

Wie findet nun der Informationsaustausch zwischen den Fenstern/ Portlets/ Applikationen/ Workflowinstanzen statt? Grundsätzlich kann jedes Portlet (bzw. jede Workflowinstanz) jedem anderen Portlet Nachrichten (d.h. Ereignisse mit zugehörigen Informationen im Ereignisobjekt, s.o.) schicken, wenn es von dessen Existenz (insbesondere die UniquePortletID) weiß. Besonders wichtig aber ist der Informationsaustausch zwischen den Portlets auf demselben Desktop. Zu diesen Zweck wurde ein umfangreiches Javascript Drag und Drop Framework entwickelt. So können beispielsweise Suchtreffer aus den Ergebnisportlets in Projekträume der Collectionportlets gezogen werden. Dokumente, Rubriken oder Suchanfragen können in die Portlets für die persönliche Zwischenablage oder für eigene Abonnements gezogen werden (vergl. Bild5 ). Nutzern aus dem LDAP-Portlet können per Drag und Drop Rechte aus dem Rechteportlet zugeordnet werden. Daten aus dem Kalenderblatt können in Suchformulare gedropt werden u.v.m. Solche Drag und Drop Aktionen lösen entsprechende Ereignisse aus, auf die betroffene Portlets dann reagieren können, indem sie z.B. zunächst prüfen, ob die Ressource, die gedropt werden soll, überhaupt kompatibel zu ihnen ist. So macht es keinen Sinn, Benutzer in Datumsfelder oder umgekehrt, Daten in Emailfelder zu ziehen. Anschließend arbeitet das Portlet mit der Information weiter, zeigt sie an (z.B. Einschränkung des Suchzeitraums) oder legt sie im Backend in einer Datenbank ab (z.B. Zuordnung von Rechten). Für jede Ressource (z.B. Dokument, Benutzer, Suchtreffer, Datum, Rubrik, Projektraum...) können zusätzlich umfangreiche Rechte vergeben werden. Dies geschieht im Portalframework durch einen so genannten "Ressourcenpersonalisierer".

In Tabelle1 werden abschließend nochmals die Funktionen des Desktops mit den Features eines Betriebssystems wie z.B. Windows verglichen.