In fast allen DMS-Projekten wird die Frage der richtigen Client-Architektur diskutiert. Es geht um die Vor- und Nachteile von Thick Client (oder Fat bzw. Rich Client) versus Thin Clients. Oder vereinfachend und vermeintlich: Performanz und umfangreiche Funktionalität, aber schwierige Administrierbarkeit bei Fat Clients gegen einfache Administration und Multi-Plattform-Fähigkeit aber eingeschränkte Funktionalität und Ergonomie bei Thin Clients. Im ersten Teil wurden Fat Clients und Terminalserver-Konzepte dargestellt. Der vorliegende Beitrag behandelt Web-Clients und das Fazit.

Thin-Client Variante II: Web-Client

Hierbei geht es um Anwendungen, die auf Web-Servern bzw. Application Servern ablaufen. Der Präfix „Web“ kann irreführend sein: bei manchen Anbietern haben Web-Clients bereits als angeblich vollwertiger Ersatz die Fat Clients abgelöst. Größter Vorteil: sie lassen sich in allen drei Einsatzfeldern Internet, Extranet und Intranet ohne Architekturwechsel einsetzen, was mit Fat Client nicht funktioniert. Die Vorteile Plattformunabhängigkeit, Nutzung universal verfügbarer Infrastrukturen wie http-Protokoll und sichere Verfügbarkeit einer Laufzeitumgebung [1] beim Endbenutzer (HTML-Browser und Java-Client) sorgen für hohe Akzeptanz und schnelle Verbreitung dieser Architektur. Die Anbieter sind allerdings gezwungen, ihre Client-Anwendungen komplett neu zu schreiben und dabei stellt sich die Frage nach der Wahl der richtigen Technologie. Auf dem Client existiert eine Vielzahl unterschiedlicher, teilweise miteinander nicht kompatibler Optionen:

Diese Client-Technologien müssen mit der Tier-2, also der Middle-Tier der neuen Architekturen zusammenarbeiten und das bedeutet wiederum die Wahl der richtigen Technologie aus einer noch größeren Vielfalt: Java Server Pages, CGI/PerlScript, Servlets, J2EE Enterprise Beans, ActiveServer Pages, IISAPI/NSAPI etc. sind nur einige Bezeichnungen für miteinander meistens nicht kompatibler Application Server Technologien. Da sich manche Anwender hier bereits festgelegt haben grenzt ein ECM/DMS-Anbieter automatisch Marktpotenzial aus, wenn er sich festlegt. Für die Anwender sollten aber neben der Konformität der Middle-Tier mit der eigenen Infrastruktur auch die funktionalen und ergonomischen Aspekte eine Rolle spielen. Lässt man diese außer Acht, droht eine architektonisch korrekte, aber für den Anwender unzumutbare Anwendung. Die häufigsten Probleme sind:

Schlechte Performanz der Anwendung und des GUI. Hierbei geht es darum, dass in einer Web-Architektur in der Regel mehr Hintergrundprozesse involviert sind, wenn auf dem Client eine Aktion initiiert wird, was häufig mit einer Laufzeitverlängerung verbunden ist. Dies mag in manchen Anwendungen so gering sein, dass sie vernachlässigt werden kann. Für DMS-Anwendungen gibt es aber zahlreiche Beispiele, wo diese Verzögerungen unakzeptabel werden. Wenn beispielsweise eine Trefferliste in einer reinen DMS-Anwendung neu sortiert werden soll, dann löst dieses Kommando folgende Reaktionen aus:

Prinzipiell besteht auch die Möglichkeit, die Neusortierung lokal durch massiven Einsatz von JavaScript durchzuführen, um die Performance-Probleme zu umgehen. Damit entstehen aber wiederum Einschränkungen bei der Multi-Plattform-Fähigkeit.

Aufgrund solcher Nachteile wurden einige spezifische Anwendungen in DMS-Projekten vom Thin Client auf Fat Client zurückmigriert: So zum Beispiel bei einer Indexieranwendung, in der die verschiedenen Indexformularfenster ständig im niedrigen Sub-Sekundenbereich schnell wechseln müssen, was mit dem Web-Client des Anbieters auch nach mehrfacher Nachbesserung nicht möglich war.

Werden im Web-Client Inhalte wie PDF, TIFF oder JPEG-Objekte (also Nicht-HTML-Objekte) angezeigt, muss der Browser entsprechend angefettet werden, d.h. er lädt eine Anwendung in Form einer Komponente, eines Applets, eines Plug-Ins oder eines ActiveX Controls, die diese Aufgabe übernimmt und dabei die lokale Verarbeitungsintelligenz des PCs nutzt. Hierbei sollte der Anwender darauf achten, dass diese Komponenten auf seinen Client-Plattformen einsetzbar sind. ActiveX Controls beispielsweise laufen nur auf Windows und sind bei manchen Unternehmen auch auf Windows-PCs aus Sicherheitsgründen nicht installierbar. Sehr viele DMS-Anbieter nutzen aber die in ihren Fat-Clients verwendeten Viewing Controls auch im Web-Client, was eine Nutzung in Internet- oder Extranet Anwendungen in der Regel ausschließt.

Ein weiterer Nachteil in der Praxis ist die Tatsache, dass die Übertragung von PDF- oder TIFF-Dokumenten zu einem Browser bei vielen Anbietern dazu führt, dass die Annotationsfunktionen verloren gehen, die man von den fetten Clients mancher Hersteller kennt. Gerade bei Anwendungen mit frühem Scannen und aktenorientierter Arbeitsweise sind solche Annotationen aber gewünscht [2]. Anwender sollten diese Funktionen daher auf alle Fälle auch für den Web-Client abfragen und nicht als selbstverständlich voraussetzen.

Ebenfalls geprüft werden sollte, wann die Web-Anwendung die Seite mit dem GUI-Code oder dem Control neu lädt. Während der Fat Client den Code im Hauptspeicher halten kann, muss die Web-Anwendung bewusst so gestaltet werden, dass die aktive Web-Anwendung mit Viewern und anderen bereits geladenen Objekten nicht jedes Mal durch eine andere GUI-Seite überschrieben und dann wieder über das Netz neu geladen werden muss. Wer einmal die Sekunden zählt bis das kostenlose PDF-Control im Browser lädt, dem wird klar, dass diese Ladezeit nicht jedes Mal, wenn die Anwendung wieder aktiv wird, akzeptiert werden kann.

Ergonomie. Ergonomisch weisen Web-Clients und hierbei vor allem reine HTML-Clients erhebliche Unterschiede zu Fat Clients auf, was zu neuem Lernaufwand bei den Anwendern führt. Aber nicht jede Funktion sieht einfach nur anders aus, manche Funktionen fehlen komplett. Beispiele sind:

• Obwohl technisch möglich, ist die personenindividuelle Einrichtung der Oberfläche in vielen Fällen nicht implementiert oder sehr viel umständlicher
• Drag & Drop häufig nicht möglich (Ausnahmen existieren)
• Browsen in hierarchischen Strukturen wie Windows Explorer fehlt oft (auch hier gibt es aber Ausnahmen, die der Anwender abfragen sollte)
• Integration der Desktop-Anwendungen wie MS Office ist umständlicher, falls überhaupt möglich
• GUI-Performanz in vielen Fällen schlechter als in Windows
• Elektronische Annotationen nur selten möglich
• Sehr selten: Tastatur-Shortcuts (häufiges MUSS für Power-User)
• Web-Clients sind weniger konform zum Windows-Style-Guide, was höhere Trainingsaufwendungen nach sich zieht. Das gilt aber generell für Web-Anwendungen und ist nicht DMS/ECM-spezifisch zu tun.

Durch die Wegnahme von Papier und den gewohnten Werkzeugen (Annotation, Ordner, Register etc.) werden dem Endanwender vor allem bei aktenorientieren Anwendungen und bei Postkorbanwendungen ergonomische Kompromisse abverlangt. Anwender sollten dies nicht überstrapazieren und die Besonderheit von Web-Clients bei der Neugestaltung der Anwendungen berücksichtigen.

Integration

Die Integration eines DMS mit anderen Anwendungssystemen gehört zu den am häufigsten unterschätzten Aufgaben. Integrationsbeispiele sind:

• Übergabe von Indexwerten aus der Capture-Anwendung nicht nur in die DMS-Datenbank, sondern auch (oder ausschließlich) in die Datenbank-Anwendungen der führenden Systemen
• Retrievalautomation, also der Aufruf des zu bearbeitenden Dokumentes aus der führenden Anwendung heraus
• die Synchronisation mit Terminverwaltung und Wiedervorlagen, die auf anderen Systemen liegen
• die Indexierung von Content-Objekten, die dem DMS aus den führenden Systemen  übergeben werden. Beispiele sind Drucklisten- und Ausgangspostarchivierung, Mail-Archivierung usw. Hierbei müssen die Indexwerte der Dokumente/Dateien ausgelesen, die Objekte selbst ggf. konvertiert werden (Bsp: 1403-TIFF-Konvertierung) und die Originale müssen nach einer bestimmten Regel behandelt werden (Löschen, im Falle von Mail Löschen der Anhänge etc.)

Einige dieser Integrationsaufgaben wurden in der Vergangenheit Client-basiert vorgenommen. Klassische Beispiele sind der Aufruf einer DMS-Recherche- und Viewing-Applikation aus der Windows-Anwendung der führenden Applikation heraus.

Diese Client-Integration funktioniert mit Web-Clients nicht mehr. Makros, ODMA, DDE/OLE, COM-Objekte und andere Technologien, die die Entwickler in den letzten 20 Jahren zur Verbindung zweier Systeme erlernt haben, funktionieren jetzt nicht mehr in einer HTML- oder Java-Umgebung. Die Lernkurve von Entwicklern und Anwendern setzt wieder von vorne an. Hinzu kommen die Integrationsaufgaben mit den Middle-Tier-Infrastrukturen auf Basis vorhandener Application Server, die Aufgaben wie Rechteverwaltung, Session Handling, Transaktionssicherung etc. ganz oder teilweise übernehmen. Ggf. müssen auch die bisherigen Integrationswerkzeuge gegen neue Werkzeuge ausgetauscht werden.

Ein weiteres aktuelles Thema sind die Sicherheitsthemen und die zahlreichen Gegenmaßnahmen der Anwender rund um Web-Clients, die in der Konsequenz dazu führen, dass manche Browser-Erweiterungen auf einmal nicht mehr funktionieren, weil der Anwender Sperrmechanismen gegen Pop-Up Fenster und dergleichen eingerichtet hat. Browser-Technologie entwickelt sich sehr rasch weiter, der Anbieter muss sicherstellen, dass seine Anwendung deswegen nicht temporär (bis zum Patch) oder dauerhaft unbrauchbar wird.

Fazit 

Wir glauben, dass der Trend in Richtung dünner Clients geht. Die Vorteile überwiegen in vielen, aber nicht in allen Fällen. Anwender sollten nicht religiös mit diesem Thema umgehen, sonst droht dem Projekt das Risiko, architektonisch korrekt zu sterben. Gerade wenn es wie bspw. bei der Posteingangserfassung, bei der Dokumentenerstellung, und andere GUI-intensive Anwendungen mit hoher Änderungsfrequenz und hohen Anforderungen bzgl. individueller und situativer Anpassungen geht, sind fette Clients ihren Web Clients häufig noch überlegen. Eine Alternative wären Terminalserver-Konzepte, wenn die genannten Risiken nicht relevant sind. Risikofrei sind auch Terminalserver nicht. Auch hier gilt, dass nicht jede Anwendung gleich gut geeignet ist. Die Anwender sollten die Clients so dünn wie möglich konzipieren, aber – wenn sie die architektonische Freiheit haben – sich nicht der Chance berauben mit Fat-Client Konzepten bessere Lösungen zu schaffen, wo die dünnen Clients Probleme bereiten.