Thin Client vs. Fat Client – Teil 2

• Home
• Magazin
• Know How
• Web Development

Im ersten Teil wurden Fat Clients und Terminalserver-Konzepte dargestellt. Dervorliegende 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. DerPräfix "Web" kann irreführend sein: bei manchen Anbietern haben Web-Clients bereits alsangeblich vollwertiger Ersatz die Fat Clients abgelöst. Größter Vorteil: sie lassen sichin allen drei Einsatzfeldern Internet, Extranet und Intranet ohne Architekturwechseleinsetzen, was mit Fat Client nicht funktioniert. Die Vorteile Plattformunabhängigkeit,Nutzung universal verfügbarer Infrastrukturen wie http-Protokoll und sichere Verfügbarkeiteiner Laufzeitumgebung [1] beim Endbenutzer (HTML-Browser und Java-Client) sorgen für hoheAkzeptanz und schnelle Verbreitung dieser Architektur.

Die Anbieter sind allerdingsgezwungen, ihre Client-Anwendungen komplett neu zu schreiben und dabei stellt sich dieFrage nach der Wahl der richtigen Technologie. Auf dem Client existiert eine Vielzahlunterschiedlicher, teilweise miteinander nicht kompatibler Optionen:

Diese Client-Technologien müssen mit der Tier-2, also der Middle-Tier der neuenArchitekturen zusammenarbeiten und das bedeutet wiederum die Wahl der richtigenTechnologie aus einer noch größeren Vielfalt: Java Server Pages, CGI/PerlScript, Servlets,J2EE Enterprise Beans, ActiveServer Pages, IISAPI/NSAPI etc. sind nur einige Bezeichnungenfür miteinander meistens nicht kompatible Application Server Technologien.

Da sich mancheAnwender hier bereits festgelegt haben grenzt ein ECM/DMS-Anbieter automatischMarktpotenzial aus, wenn er sich festlegt. Für die Anwender sollten aber neben derKonformität der Middle-Tier mit der eigenen Infrastruktur auch die funktionalen undergonomischen Aspekte eine Rolle spielen. Lässt man diese außer Acht, droht einearchitektonisch korrekte, aber für den Anwender unzumutbare Anwendung. Die häufigstenProbleme sind:

Schlechte Performanz der Anwendung und des GUIHierbei geht es darum, dass in einerWeb-Architektur in der Regel mehr Hintergrundprozesse involviert sind, wenn auf dem Clienteine Aktion initiiert wird, was häufig mit einer Laufzeitverlängerung verbunden ist. Diesmag in manchen Anwendungen so gering sein, dass sie vernachlässigt werden kann.

FürDMS-Anwendungen gibt es aber zahlreiche Beispiele, wo diese Verzögerungen unakzeptabelwerden. Wenn beispielsweise eine Trefferliste in einer reinen DMS-Anwendung neu sortiertwerden soll, dann löst dieses Kommando folgende Reaktionen aus:

Reiner HTML-Client: 5 Schritte

• 1. Aufruf des Befehls durch Klicken eines Button (= Link zu einer URL, Übergabe vonParametern zum Anstoß des Vorgangs). HTML-Client kommuniziert mit http-Server, nichtdirekt mit dem DMS-Server. Ausnahme: wenn die DMS-Logik direkt auf dem Application-Serverprogrammiert ist. Bei den meisten DMS ist dies aber nicht der Fall.
• 2. Tier-2 nimmt Aufruf und Parameter entgegen, interpretiert und übergibt in manchenImplementierungen den Befehl an DMS-Server bzw. Datenbank statt sie auf demApplication-Server selbst durchzuführen.
• 3. Server bzw. Datenbank führt aus und übergibt Resultat
• 4. Web-Server interpretiert Resultat und übersetzt in eine neue HTML-Seite
• 5. Client stellt neue HTML-Trefferliste dar. Entscheidend ist, dass die Daten immer überdas Netz geschickt werden.Fat Client: 3 Schritte
• 1. Aufruf des Befehls durch Klicken eines Buttons (exekutiert ein API auf dem Client). APIkommuniziert direkt mit DMS-Server
• 2a. Client sortiert lokale gespeicherte Ressourcen neu. Fertig, oder
• 2b: Server bzw. Datenbank führt aus und übergibt Resultat
• 3. Client stellt neue Trefferliste darPrinzipiell besteht auch die Möglichkeit, die Neusortierung lokal durch massiven Einsatzvon JavaScript durchzuführen, um die Performance-Probleme zu umgehen. Damit entstehen aberwiederum Einschränkungen bei der Multi-Plattform-Fähigkeit.

Aufgrund solcher Nachteile wurden einige spezifische Anwendungen in DMS-Projekten vom ThinClient auf Fat Client zurückmigriert: So zum Beispiel bei einer Indexieranwendung, in derdie verschiedenen Indexformularfenster ständig im niedrigen Sub-Sekundenbereich schnellwechseln müssen, was mit dem Web-Client des Anbieters auch nach mehrfacher Nachbesserungnicht 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 inForm einer Komponente, eines Applets, eine Plug-Ins oder eines ActiveX Controls, die dieseAufgabe übernimmt und dabei die lokale Verarbeitungsintelligenz des PC nutzt.

Hierbeisollte der Anwender darauf achten, dass diese Komponenten auf seinen Client-Plattformeneinsetzbar sind. ActiveX Controls beispielsweise laufen nur auf Windows und sind beimanchen Unternehmen auch auf Windows-PCs aus Sicherheitsgründen nicht installierbar. Sehrviele DMS-Anbieter nutzen aber die in ihren Fat-Clients verwendeten Viewing Controls auchim Web-Client, was eine Nutzung in Internet- oder Extranet Anwendungen in der Regelausschließt.

Ein weiterer Nachteil in der Praxis ist die Tatsache, dass die Übertragung von PDF- oderTIFF-Dokumenten zu einem Browser bei vielen Anbietern dazu führt, dass dieAnnotationsfunktionen verloren gehen, die man von den fetten Clients mancher Herstellerkennt. Gerade bei Anwendungen mit frühem Scannen und aktenorientierter Arbeitsweise sindsolche Annotationen aber gewünscht [2]. Anwender sollten diese Funktionen daher auf alleFä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 oderdem Control neu lädt.

Während der Fat Client den Code im Hauptspeicher halten kann, mussdie Web-Anwendung bewusst so gestaltet werden, dass die aktive Web-Anwendung mit Viewernund 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 dieSekunden zählt bis das kostenlose PDF-Control im Browser lädt, dem wird klar, dass dieseLadezeit nicht jedes Mal, wenn die Anwendung wieder aktiv wird, akzeptiert werden kann.

Ergonomie

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

• Obwohl technisch möglich, ist die personenindividuelle Einrichtung der Oberfläche ist invielen 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 esaber Ausnahmen, die der Anwender abfragen sollte)
• Integration der Desktop-Anwendungen wie MS Office ist umständlicher, falls überhauptmö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 Trainingsaufwendungennach sich zieht. Das gilt aber generell für Web-Anwendungen und ist nichtDMS/ECM-spezifisch zu tun.Durch die Wegnahme von Papier und den gewohnten Werkzeugen (Annotation, Ordner, Registeretc.) werden dem Endanwender vor allem bei aktenorientieren Anwendungen und beiPostkorbanwendungen ergonomische Kompromisse abverlangt. Anwender sollten dies nichtüberstrapazieren und die Besonderheit von Web-Clients bei der Neugestaltung derAnwendungen berücksichtigen.

Integration

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

• Übergabe von Indexwerten aus der Capture-Anwendung nicht nur in die DMS-Datenbank sondernauch (oder ausschließlich) in die Datenbank-Anwendungen der führenden Systemen
• Retrievalautomation, also der Aufruf des zu bearbeitenden Dokumentes aus der führendenAnwendung heraus
• die Synchronisation mit Terminverwaltung und Wiedervorlagen, die auf anderen Systemenliegen
• die </b>Indexierung von Content-Objekten</b>, die dem DMS aus den führenden Systemen übergebenwerden. 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 einerbestimmten 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 derWindows-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 zurVerbindung 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 Basisvorhandener Application Server, die Aufgaben wie Rechteverwaltung, Session Handling,Transaktionssicherung etc. ganz oder teilweise übernehmen. Ggf. müssen auch die bisherigenIntegrationswerkzeuge gegen neue Werkzeuge ausgetauscht werden.

Ein weiteres aktuelles Thema sind die Sicherheitsthemen und die zahlreichen Gegenmaßnahmender Anwender rund um Web-Clients, die in der Konsequenz dazu führen, dass mancheBrowser-Erweiterungen auf einmal nicht mehr funktionieren, weil der AnwenderSperrmechanismen 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 unbrauchbarwird.

Fazit

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

[1] Allerdings mit der Einschränkung, dass die Java Virtual Machine im neuen MS IE nichtmehr standardmäßig vorhanden ist.

[2] Wobei wir uns meistens und wenn funktional/ergonomisch möglich gegen Annotationen undfür alternative Notizfunktionen in Form von Datenbankfeldern aussprechen, weilAnnotationen immer proprietär sind.