|  |
Thin Client vs. Fat Client – Teil 2
 
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
- 1. Aufruf des Befehls durch Klicken eines Button (= Link zu einer URL, Übergabe von
Parametern zum Anstoß des Vorgangs). HTML-Client kommuniziert mit http-Server, nicht
direkt mit dem DMS-Server. Ausnahme: wenn die DMS-Logik direkt auf dem Application-Server
programmiert ist. Bei den meisten DMS ist dies aber nicht der Fall.
- 2. Tier-2 nimmt Aufruf und Parameter entgegen, interpretiert und übergibt in manchen
Implementierungen den Befehl an DMS-Server bzw. Datenbank statt sie auf dem
Application-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 über
das Netz geschickt werden.
Fat Client: 3 Schritte
- 1. Aufruf des Befehls durch Klicken eines Buttons (exekutiert ein API auf dem Client). API
kommuniziert 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 dar
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:
- Obwohl technisch möglich, ist die personenindividuelle Einrichtung der Oberfläche ist 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.
[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.11/2006, Bernhard Zöller
Kommentare zu diesem Beitrag | | |
Weitere Beiträge zu diesem Thema | | |
|  | | Anwender haben ein sehr unterschiedliches Verständnis von Dokumenten und Content Management. Die Spanne reicht von der einfachen MS Office-Dateiverwaltung bis hin zur Prozessunterstützung... | |  | | PDF als Format für Dokumente und Flash als papierlose Technologie können sich gut ergänzen. Zum Teil unterstützt die aktuelle Version von Flash schon jetzt Adobe-Technologien... | |  | | 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... | |  | | Auf Grundlage einer webbasierten Befragung von Mittelstands- und Großunternehmen liefert vorliegendes Studienprodukt Informationen zu Voraussetzungen, Erfahrungen und Trends der Nachfrage... | |  | | Nachdem die Integrationsmöglichkeiten auf Client-Ebene im ersten Teil geklärt wurden, geht es nun weiter mit den Server-basierten Schnittstellen, die vor allem für den Abgleich von Massendaten benötigt werden... | |
Beiträge aus anderen Themenbereichen | | |
|  | | Im Interview spricht der Schirmherr der Initiative Prof. Dieter Spath über "Das Konstruktionsbüro für Dienstleistungen" und vieles mehr. Am 12. Oktober eröffnet Prof. Dieter Spath den VOICE Days plus Kongress... | |  | | Die Gestattung der privaten Nutzung der betriebseigenen IT-Infrastruktur durch die Mitarbeiter bringt nicht zu unterschätzende rechtliche Komplikationen mit sich – gerade was auch die Archivierung von E-Mails anbelangt... | |  | | Datenschutz spielt auch im eCommerce eine große Rolle. So müssen z.B. für den Betrieb eines Onlineshops die gesetzlichen Vorschriften zum Datenschutz eingehalten werden... | |
| | | |
