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-basierte Methodenaufrufe mit der Serverschicht kommuniziert. 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 Dokumenten etc.?

In Teil 2, der im nächsten ECM-Newsletter veröffentlicht wird, 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.