Thin Client vs. Fat Client – Teil 2

http://www.contentmanager.de/magazin/artikel_1241_thin_client_fat_client.html

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 kompatible 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:


Reiner HTML-Client: 5 Schritte

Fat Client: 3 Schritte

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, eine Plug-Ins oder eines ActiveX Controls, die diese Aufgabe übernimmt und dabei die lokale Verarbeitungsintelligenz des PC 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:

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:

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.


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

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

Erschienen: 11/2006
Autor: Bernhard Zöller




Nach langjähriger Tätigkeit als Berater im Bereich Dokumenten-Management gründete er Anfang 1997 die Zöller&Partner GmbH als neutrale, produkt- und anbieterunabhängige Beratungsfirma. Bernhard Zöller ist langjähriges Mitglied der AIIM und Vorstand im VOI.

Zöller & Partner GmbH

© 1999-2010 | Home | Fenster schliessen