|  |
Thin Client vs. Fat Client – Teil 1
 
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.
Direkt betroffen sind IT-Abteilungen und Endanwender. Erstere müssen die Infrastruktur zur
Verfügung stellen, wobei sich die Aufwendungen je nach gewählter Architektur erheblich
unterscheiden. Die Endanwender dagegen müssen mit den in vielen Fällen gravierend anderen
Funktionalitäten, sowie ergonomischen und leistungsmäßigen Konsequenzen klar kommen.
Wäre die Wirklichkeit so idealtypisch, wie die Verfechter der Thin Clients sie darstellen,
wäre die Entscheidung einfacher. Man würde die notwendige Anwendung nur einmal zentral auf
der Middle-Tier installieren, die Clients laden sich die jeweils aktuelle
Anwendungsoberfläche auf das mehr oder weniger dumme Endgerät, aufwendige
Softwareverteilsysteme wären nicht notwendig. Gleichzeitig würde man sich
Inkompatibilitäten auf der Client-Seite ersparen, die durch unterschiedliche
Client-Betriebssysteme, Konfigurationen und Releases entstehen.
Weitere Vorteile einer
echten Thin Client-Architektur wären: einheitliche Ausstattung bei Dauer- und
Gelegenheitsanwendern, höhere Skalierbarkeit und technische Stabilität durch echte
3-tier-Architektur.
Die Realität sieht aber anders aus. Den unbestreitbaren Vorteilen stehen je nach
Architektur und je nach Art der Anwendung auch Nachteile gegenüber, die häufig zu spät
erkannt werden. Um diese Nachteile bewerten zu können, ist es nötig, die verschiedenen
Architekturen kurz gegenüber zu stellen.
Fat Client - Rich Client
Vor der Verbreitung der Thin Clients basierten die im DMS-Markt verfügbaren
Architekturkonzepte ausnahmslos auf Fat Client-Anwendungen, wobei sehr grob unterschieden
werden muss zwischen:
A) Kein eigener Client: Der DMS-Anbieter stellt keine eigenen Client-Anwendungen zur
Verfügung. Die Anwendung wird individuell auf dem Client programmiert und auf Basis einer
schlanken Client-API mit dem Repository-Server integriert. Einige Komponenten wie Viewer
oder Scan-Anwendung sind Fat Client Komponenten und kommen von Drittanbietern. Funktionen
wie Postkorb- und Aktenfunktionen werden individuell programmiert (und bei genügend großer
repetitiver Absatzmenge zum Produkt erklärt).
B) Eigener Client, schlanker Server: Der DMS-Hersteller stellt DMS-Client Funktionen in
Form von fertigen Anwendungen (oder eines programmierbaren Komponentenmodells auf
Client-Basis) zur Verfügung. Der Server verfügt manchmal nicht über echte Multi-User
Datenbankanwendungen, sondern dient nur als Repository mit einer häufig sehr skalierbaren
Objektverwaltung, die für große Archivanwendungen notwendig ist. Die eigentliche
Datenbankanwendung wird in diesen Fällen individuell auf dem Client programmiert und
kommuniziert via ODBC mit der Datenbank auf dem Server [1].
C) Eigener Client, "fetter" Server: In sprachlicher Abwandlung der Variante B könnte man
solche Lösungen, bei denen der Client direkt mit einer Datenbankanwendung auf dem Server
kommuniziert als "fetter Server" bezeichnen, ohne dass damit eine Wertung verbunden ist.
Die Funktionalität ist hier häufig sehr viel ausgeprägter, eine Reihe fertiger Funktionen
ist bereits im Basissystem verfügbar und muss nur angepasst werden. Der Nachteil dieser
Variante ist die in der Regel eingeschränkte Anzahl Datenbanken und Server-Plattformen.
Die Grenzen zwischen diesen prototypischen Konzepten sind verschwimmend. Allen drei
Konzepten ist aber gemeinsam, dass die Client-Anwendung fast immer eine Windows-Anwendung
ist, die über bestimmte Client-basierten Methodenaufrufe mit der Serverschicht
kommunizieren. Den Vorteilen dieser Fat Client/2-tier Architektur wie beispielsweise
- Ausnutzung der lokalen Leistung eines PC
- GUI-Elemente in Windows-Anwendungen häufig ähnlich zu bedienen.
- Lokale Nutzung ohne Netzverbindung möglich (wenn Dokumente lokal gespeichert sind)
stehen gewichtige Nachteile gegenüber:
- Hoher Administrationsaufwand und Inkompatibilitäten bei unterschiedlichen Releaseständen
des Client-Betriebssystems und unterschiedlichen Hard- und Software-Ausstattungen der PCs
- Anwendung muss auf dem Client installiert werden, auch bei nur gelegentlicher Installation
- Internet-/Extranet-Nutzung nicht möglich oder nicht praktikabel
- Belastung PC (benötigte HW-Ausstattung, ggf. Zusatzhardware)
Thin-Client Variante I: Terminalserver
Eine elegante Variante, diese Fat-Client Probleme zu lösen stellen die sogenannten
Terminalserver-Konzepte dar. Diese werden von verschiedenen Anbietern angeboten wie Citrix
mit Metaframe, Microsoft mit dem Windows Terminalserver (der auf der Citrix-Technologie
basiert) oder Tarantella mit dem Secure Global Desktop.
Terminalserver für Fat-Client-Anwendungen basieren im wesentlichen darauf, dass
Client-Anwendungen auf einem Server exekutieren und den Clients-Workstations nur die
Videodaten der jeweiligen Anwendungsoberfläche zugeschickt werden. MS Office oder der
DMS-Viewer "laufen" also auf dem Server, die Dokumentensicht und die Menüs werden dem
Benutzer via LAN/WAN übertragen und "angezeigt".
Die Client-Workstations können
Standard-PCs sein, die mit einer Terminalserver-Anwendung laufen oder es können die
"echten" Thin Terminals sein, die nur soviel Hardware umfassen, wie für Ausführung der
Terminalserver-Anwendung notwendig ist, also wenig mehr als Netzteil, Bildschirm,
Tastatur, Maus, Betriebssystem und LAN-Schnittstelle.
Für den Benutzer sieht eine Terminalserver-Anwendung so aus wie eine normale
Windows-Applikation, die er auch bedient wie gewohnt. In Wirklichkeit schickt er aber
lediglich über den Rückkanal für Tastatur und Maus Kommandos an den Server, der diese
Kommandos durchführt: Blättern einer Wordseite, Speichern eines Objektes, Öffnen einer
Mail durch Doppelklick, Zoomen eines Bildes, Einbuchen eines Buchungssatzes etc. Die
Übertragungsprotokolle der Terminalserver komprimieren diese Videoraten sehr effizient,
sodass auch schon Lösungen mit einer dünnen ISDN-Leitung für das Einzeldokumentretrieval
ausreichend sein können. Für den Anwender bieten die Terminalserverkonzepte daher
wesentliche Vorteile:
- Zentrale Administration der Client-Anwendungen, keine dezentrale Installation und Updates
notwendig.
- Auch seltene Gelegenheitsnutzer können preiswerten Zugriff auf selten benötigte Fat-Client
Anwendungen erhalten
- Manche Terminalserverkonzepte erlauben die Nutzung von Windows-Anwendungen auf anderen
Plattformen (Mac, Linux) unter Umgehung der Emulationsprobleme.
- Endgeräte können sehr preiswert ausgestattet werden und haben längere Nutzungsdauern als
die schnell veraltenden PCs. Eventuelle notwendige Leistungsverbesserungen werden auf den
Servern und in den Netzen realisiert.
- Einfacher Remote-Zugang, da der Terminalserver sowieso als allgemeiner Remote-Zugangsweg
für andere Anwendungen genutzt wird.
- Trotz geringer Bandbreite kann hohe Performance erzielt werden
- Schnelle Programmladezeiten, weil zumeist leistungsfähige Server
Diesen unbestreitbaren Vorteilen stehen aber in manchen Projekten auch Nachteile
gegenüber:
- Nicht jede Anwendung ist konform programmiert. Die Anwender sollten sich vom Anbieter die
Konformität zu dem eingesetzten Terminalserver-Produkt zusichern lassen. Häufige Probleme
machen TEMP- oder Registry-Bereiche.
- Bei Terminalservern gilt die Grundregel: je häufiger sich der Inhalt des Bildschirms
ändert, und je mehr Pixel von dieser Änderung betroffen sind, desto mehr Last haben Server
und Leitungsnetz zu bewältigen. Es macht daher einen Unterschied ob der Inhalt eines SVGA-
oder eines UXGA Bildschirmes komprimiert und übertragen werden muss. Es macht außerdem
einen Unterschied ob die Grafikkarte 256 Farben (8 Bit für jedes zu übertragende Pixel)
oder 16 Mio Farben (24 Bit für jedes Pixel) darstellen soll. Für viele DMS-Anwendungen, z.
B. wenn mit einem elektronischen Postkorb gearbeitet wird, ist ein großer Bildschirm aber
obligatorisch.
- Manche Anwendungsfunktionen wie zum Beispiel Scrollen in Dokumenten erzeugen eine
signifikant höhere Last auf dem Terminalserver als beispielsweise eine Datenbankanwendung,
deren Erfassungsmaske sich kaum ändert.
- Da die eigentlich für einen Fat Client entwickelten Anwendungen nun alle auf einem
Terminal Server ablaufen, wird eine entsprechend hohe Rechenleistung benötigt. Dies führt
in der Praxis schnell zur Notwendigkeit des Einsatzes von Terminalserver-Farmen, um
mittlere und große Benutzerzahlen bedienen zu können.
- Weitere Stolpersteine können lokales Drucken, Scannen, Integration von Desktop-Anwendungen
sein. Im letzteren Fall können Probleme auftreten, wenn eine Terminalserver-Farm
installiert ist und die zu integrierenden Anwendungen auf unterschiedlichen
Terminalservern laufen.
Der Anwender sollte beim Einsatz von Terminalservern daher auf alle Fälle im Vorfeld
klären:
- Unterstützt der EMS-/ECM-Hersteller überhaupt den zum Einsatz kommenden Terminalserver?
- Werden auch Funktionen wie OCR, Renditioning, Archivieren von Dokumenten aus Mail und
Office-Anwendungen etc. unterstützt? In diesem Zusammenhang: welche Belastung entsteht auf
dem Server, wenn n Anwender gleichzeitig rendern?
- Hat der Hersteller Referenzen mit einem vergleichbaren Anwendungsprofil: d.h.
vergleichbare Aktenstrukturen/Dokumentenphysik, vergleichbare Endbenutzeraktionen auf den
Dokumente etc.?
Im zweiten Teil des Artiekls, der nächste Woche im Magazin erscheint, werden Vor- und Nachteile
von Web-Clients dargestellt.
[1] Einige Anwendungen basieren auf nicht-relationalen Datenbanken wie
Volltextdatenbanken, Btrieve oder Eigengewächsen. Für diese Systeme gilt das hier Gesagte
nur mit Einschränkungen. Die Nutzung von ODBC ist bei diesen Beispielen nicht möglich, die
Anzahl der unterstützten Plattformen daher vom Anbieter der Datenbank abhängig.11/2006, Bernhard Zöller
Kommentare zu diesem Beitrag | | |
Weitere Beiträge zu diesem Thema | | |
|  | | 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... | |  | | Im ersten Teil wurden Fat Clients und Terminalserver-Konzepte dargestellt. Der vorliegende Beitrag behandelt Web-Clients und das Fazit... | |  | | 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... | |  | | Obwohl seit fast 20 Jahren Archiv- bzw. Dokumenten Management Lösungen in Unternehmen eingerichtet werden, stellt auch heute noch die Verbindung von Fachanwendung und ECM-System in Projekten eine Herausforderung dar... | |
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... | |
| | | |
