Grundlagen von Smart Clients

Thin Clients, Fat Clients, Web Clients, Rich Clients: Wer heute eine Anwendung implementiert, kann aus einer Vielzahl von Clientarten eine Auswahl treffen. Jeder Clienttyp hat seine besonderen Vor- und Nachteile. In der letzten Zeit hat sich aber zu den oben genannten Varianten eine neue dazugesellt: der Smart Client. Was ist aber an diesem Client so besonders, dass heute jeder davon spricht?

Im Grunde genommen muss ein Smart Client die Vorteile der Thin- und Fat-Clients vereinen. Doch was sind die Vor- und Nachteile, dieser beider Client-Typen? Wie der Name bereits sagt, ist ein Thin Client besonders «dünn», was im Klartext bedeutet, dass im Layer der UI (User Interface) nur sehr wenig Code und auch Business-Logik vorhanden ist. Ein typischer Thin Client ist beispielsweise eine Web-Anwendung auf der Basis von ASP.NET. Hier wird der UI-Teil mit Hilfe von HTML umgesetzt und in der Codebehind-Datei gibt es im Ideal-fall ein wenig .NET Code. Die eigentliche Business Logik (Berechnungen, Logiken, Ablaufsteuerungen usw.) wird aber in einer separaten Schicht, dem so genannten Business-Logical-Layer implementiert. Der grosse Vorteil dieses Clients ist natürlich das Deployment, da hier nur ein zentraler Web Server notwendig ist, der den Web Client hostet. Thin-Client-Anwendungen müssen daher gar nicht erst auf die Clients verteilt werden, weil sich diese direkt zum Web Server verbinden. Thin Clients bringen auch eine Reihe von Nachteilen mit sich.

So verlangen die leichtgewichtigen Front-Ends nach einer permanent stehenden Netzwerkverbindung und warten wegen ihren Einschränkungen bezüglich der User-Interface-Gestaltung mit einer nur mässigen User Experience auf.

Das pure Gegenteil zum Thin Client ist der Fat Client. Hier ist ein Grossteil der Programmlogik im UI-Layer untergebracht. Typische Fat Clients sind beispielsweise die Programme der Office-Suite, oder auch die Vielzahl von Programmen, die unter Visual C++ 6.0 mit der MFC (Microsoft Foundation Classes) implementiert wurden. Fat Clients verfügen meist über eine ansprechend gestaltete Oberfläche (Rich UI) und können auch offline genutzt werden. Der Nachteil dieser Clientart ist, dass hier meistens keine saubere Schichtentrennung durchgeführt wurde - mit dem Argument, dass ja eh alles am Client installiert werden muss. Das bedeutet im Endeffekt, dass man hier genau wissen muss, wie die Konfiguration des Clients aussieht, welche Service Packs vorhanden sind oder welche anderen Produkte installiert sind. Hier muss man sich also ganz gezielt um Installations- und Update-Strategien kümmern, damit eine sauber funktionierende Installation gewährleistet ist. Diese aufwändige Art des Deployments ist denn auch der grösste Nach-teil des Fat Clients. Ein bekanntes Stichwort dazu ist sicherlich auch die altbekannte DLL-Hölle, die mit dem allmählichen Übergang in die .Net-Welt endlich zur Geschichte gehören wird.

Beim Smart Client Konzept geht es im Prinzip darum, das Beste aus beiden Welten zu vereinen und gleichzeitig die Nachteile möglichst auszuräumen (siehe dazu Diagramm «Das-Smart-Client-Konzept». Doch wie wird nun dieses Konzept technisch umgesetzt?

Ein Irrglaube vieler Entwickler ist, dass es sich bei einem Smart Client um ein SDK (Software Development Kit) handelt mit dem ein paar Schnittstellen implementiert werden müssen, damit aus einer normalen Windows-Anwendung ein Smart Client entsteht. Vielmehr ist es aber so, dass das Smart-Client-Konzept nur auf architektonischen und designtechnischen Konzepten und Richtlinien beruht, die bei der Implementierung beachtet und umgesetzt werden müssen.

Eine dieser Richtlinien ist, dass ein Smart Client auch ohne Verbindung zum Netzwerk (Intranet, Internet) funktionieren sollte, so dass mit der Anwendung auch offline gearbeitet werden kann. Ein weiteres Charakteristikum ist, dass Smart Clients via Web Services auch Business Logik aus anderen Anwendungen oder Schichten nutzen können. Einerseits ist dadurch die Interoperabilität mit anderen Plattformen wie J2EE gewährleistet, andererseits lassen sich Smart Clients ideal als Front-end in Service-orientierte Architekturen (SOA) integrieren. In einer SOA-Umgebung bieten Anwendungen ihre Dienste unter anderem in Form von Web Services an, die direkt von Smart Clients konsumiert werden können.

Wichtig ist auch, dass Smart Clients die lokalen Geräteeigenschaften des Clients ausnutzen. Ein typisches Beispiel sind etwa die verschiedenen Eingabemöglichkeiten unterschiedlicher Gerätetypen. So könnte auf einem Pocket PC ein Stylus unterstützt, auf einem Tablet PC Digital Ink und auf einem Notebook die Spracheingabe unterstützt werden. Dank der Nutzung der lokalen Geräteeigenschaften machen Smart Clients auch eine Rich User Experience möglich.

Wer schon mal probiert hat eine Web Anwendung so zu programmieren, dass sie in punkto der User Experience an eine Windows-Anwendung herankommt, weiss, dass dies auch mit hohem Aufwand praktisch unmöglich ist. Mit einem Smart Client lässt sich eine Rich UI aber ohne grossen Aufwand realisieren.

Die Ausnutzung lokaler Ressourcen ist ebenfalls ein designtechnisches Konzept eines Smart Clients. Man denke nur einmal an typische grosse Client/Server-Anwendungen, bei der auf den Clients ein Web Client eingesetzt wird. Der Server muss leistungsstark sein, damit er überhaupt eine grosse Zahl von Clients bedienen kann. Der Client hingegen muss im Prinzip nur minimale Anforderungen erfüllen, weil er bloss die HTML-Ergebnisse des Servers zu rendern braucht. Allerdings werden auch die Client PCs von Jahr zu Jahr leistungsfähiger. Dadurch steht auch clientseitig immer mehr Rechenleistung zur Verfügung, die im Falle der genannten Client/Server-Anwendung einfach brach liegt. Genau diesem Umstand will das Smart-Client-Konzept Rechnung tragen, indem gewisse Arbeiten clientseitig durchgeführt werden und so die vorhandene Rechenleistung effektiver genutzt werden kann.

Ein weiteres Prinzip, das der Smart Client unterstützen muss, ist ein automatisches Deployment. Das klingt jetzt sehr mystisch, funktioniert aber schon heute in Form des XCOPY Deployments beim .NET Framework 1.1. Das .NET Framework 2.0 bietet uns zusätzlich das Click-Once-Deployment an (Nachfolger des XCOPY-Verfahrens), mit dem Windows-Forms-Anwendungen ohne Zutun des Benutzers automatisch installiert werden können. Zu diesem Zweck wird die komplette Anwendung durch einen Deployment-Server zur automatischen Ins-tallation auf dem Client bereitgestellt. Zudem kann die Client-Anwendung beim Aufstarten prüfen, ob eine aktuellere Version verfügbar ist. Falls das der Fall ist, wird das Update automatisch auf dem Client eingerichtet.

Wie man sieht, handelt es sich bei einem Smart Client um kein verworrenes Konzept, sondern einfach um eine Reihe von Designrichtlinien, die man bereits bei nächsten Projekten beachten kann. Dass Microsoft kein eigentliches SDK für die Smart-Client-Entwicklung anbietet, bedeutet aber noch lange nicht, dass keine entsprechenden Technologien zur Verfügung stehen. Das .NET Framework 2.0 bietet uns beispielsweise das bereits erwähnte ClickOnce für die vereinfachte Installation von WinForms-Anwendungen. Ein Smart Client muss aber nicht unbedingt in Form einer «gewöhnlichen» Windows-Anwendung daherkommen. Mit VSTO (Visual Studio Tools for Office) bietet Microsoft Managed Erweiterungen an, mit denen Smart Clients auch auf der Basis von Microsoft Office implementiert werden können. Mit .NET 2.0 und dem parallel dazu erscheinenden VSTO 2005 wird es erstmals möglich sein, auch Offline-Anwendungen und Outlook-2003-Add-ons zu programmieren. Die Smart-Client-Funktionalität des Office Systems wird mit dem Office Information Bridge Framework (IBF) abgerundet, mit dessen Hilfe Daten von Business-Applikationen und Legacy-Systemen in Office-Anwendungen integriert werden können. Sobald Longhorn verfügbar sein wird, wird auch Avalon, Microsofts neue Technologie für die Präsentationsschicht, für die Entwicklung von Smart Client herangezogen werden. Mehr zu VSTO und Avalon in den Artikeln auf Seite 53 und 60.

Der Autor:
Klaus Aschenbrenner ist Software-Architekt und technischer Berater bei Anecon, Wien.