Freigeben über


Das .NET Framework und das Smart Client-Anwendungsmodell

Veröffentlicht: 23. Jul 2002 | Aktualisiert: 22. Jun 2004

Auf dieser Seite

 Einführung
 Das Ende von DLL-Versionskonflikten
 Bereitstellen von Smart Client-Assemblys von einem Webserver aus
 Beweisbasierte Sicherheit: Sicherheit bei der unbeaufsichtigten Bereitstellung
 Smart Client-Anwendungen im Vergleich zu browserbasierten Anwendungen
 Nachgewiesener Erfolg
 Zusammenfassung: Wann und wo bietet sich die Implementierung von Smart Clients an?

Einführung

Während der vergangen fünf Jahre wurden Softwareentwickler, die sich mit der Entwicklung von Anwendungen in Unternehmen beschäftigen, vor eine schwierige Wahl gestellt. Sie mussten sich entweder für das browserbasierte Thin Client-Anwendungsmodell oder für das Gegenstück des vielseitigen Clients entscheiden.

Browserbasierte Anwendungen können problemlos installiert und verwaltet werden, können auf unterschiedlichsten Desktops ausgeführt werden und haben keinerlei Auswirkungen auf den Zustand des Clientcomputers. Trotz dieser Vorzüge ist das browserbasierte Modell jedoch alles andere als perfekt. Vielseitige Clientanwendungen bieten eine vielseitigere Benutzeroberfläche sowie den Zugriff auf die lokale Festplatte und lokalen APIs (Application Programming Interfaces, Schnittstellen für Anwendungsprogrammierung), wodurch dem Entwickler zusätzliche Möglichkeiten zur Verfügung stehen und den Benutzern eine größere Funktionsvielfalt geboten werden kann. Da sie lokal auf dem Clientcomputer ausgeführt werden, können vielseitige Clientanwendungen zudem die verfügbaren Ressourcen besser nutzen, das Problem von Netzwerkwartezeiten vermeiden und dem Benutzer das Arbeiten im Offlinemodus ermöglichen.

Verglichen mit dem vielseitigen Client stellt das browserbasierte Modell insgesamt eine hervorragende Lösung für IT-Administratoren dar, lässt bei Entwicklern und Endbenutzern jedoch etliche Wünsche offen.

Das Microsoft .NET Framework dient den Interessen aller drei genannten Gruppen. Das Smart Client-Anwendungsmodell kombiniert die Leistungsfähigkeit und Flexibilität vielseitiger Clients mit der einfachen Bereitstellung und Stabilität des browserbasierten Modells.

Dieses Dokument bietet einen Überblick über das Smart Client-Anwendungsmodell des .NET Frameworks. Es beginnt mit einer anspruchsvollen allgemeinen Übersicht über die Funktionsweise, an die sich eine detailliertere Beschreibung der Architektur im Vergleich zum browserbasierten Modell anschließt.

 

Das Ende von DLL-Versionskonflikten

Durch das .NET Framework wird ein gängiges Szenario, die so genannten DLL-Versionskonflikte, beseitigt. Bislang traten derartige Konflikte auf, wenn eine neue Anwendung eine gemeinsam genutzte DLL (Dynamic Link Library) in der Systemregistrierung durch eine andere Version derselben Datei ersetzte, die neue Version jedoch mit einigen der anderen lokalen Anwendungen, die auf diese DLL verwiesen, inkompatibel war.

.NET Framework-Anwendungen sind standardmäßig eigenständig und isoliert, da Assemblys (die .NET-Version einer Komponente) im lokalen Anwendungsverzeichnis und nicht in einem globalen oder gemeinsam genutzten Speicherort aufgelöst werden. Bei diesem Ansatz können mehrere Versionen derselben Assembly gemeinsam auf demselben System installiert werden, ohne dass dies einen Konflikt auslöst. Darüber hinaus ist es nicht notwendig, die in einer Anwendung verwendeten Assemblys zu "registrieren", ein Verfahren, das als unbeaufsichtigte Bereitstellung (No-Touch Deployment) bezeichnet wird. Bei der unbeaufsichtigten Bereitstellung müssen Sie für die Installation einer Anwendung auf einem Computer lediglich XCOPY oder FTP (File Transfer Protocol) verwenden bzw. die Anwendung mittels Drag & Drop in den gewünschten Ordner auf der Festplatte ziehen. Dann ist die Anwendung sofort betriebsbereit. Die Deinstallation erfolgt, indem Sie das Anwendungsverzeichnis einfach löschen.

Mithilfe eines zentralen Speichers, des so genannten globalen Assemblycaches, ist die gemeinsame Nutzung von Assemblys jedoch weiterhin möglich. Jede Assembly, die hier registriert wird, wird einer interner starker Name zugewiesen, der aus dem Dateinamen, der Version, der Kultur (Englisch, Deutsch, Japanisch usw.), der digitalen Signatur und dem öffentlichen Schlüssel abgeleitet wird. Jede gemeinsam genutzte Assembly kann somit eindeutig identifiziert werden. Hierdurch können mehrere Versionen einer bestimmten Assembly gleichzeitig im globalen Assemblycache gespeichert sein und sogar gleichzeitig ausgeführt werden können, ohne dass dies zu Konflikten führt – ein Szenario, das parallele Ausführung (side-by-side execution) genannt wird.

Anwendungen stellen standardmäßig eine Bindung zu dem starken Namen der gemeinsam genutzten Komponente her, die beim Entwickeln der Anwendung verwendet wurde. Sollte ein Administrator diese Vorgabe jedoch ändern wollen, um z. B. einen Hotfix zu installieren, kann er dies tun, indem er eine einfache Veröffentlichungsrichtlinien-Konfigurationsdatei schreibt oder das .NET Framework-Konfigurationstool verwendet, das mit dem .NET Framework bereitgestellt wird.

 

Bereitstellen von Smart Client-Assemblys von einem Webserver aus

Das zuvor skizzierte Modell der Assemblyauflösung garantiert Anwendungsstabilität, Vorhersagbarkeit und eine einfache Installation – alles Aspekte, die zum Tragen kommen, sobald sich die Anwendung auf dem Clientcomputer befindet. Zunächst stellt sich jedoch die Frage, wie die Anwendung auf den Clientcomputer gelangt.

Wie bisher können auch Smart Client-Anwendungen mittels CD-ROM, DVD, Disketten oder einer Infrastruktur zur Anwendungsbereitstellung verteilt werden, wie z. B. Microsoft Systems Management Server oder IntelliMirror®-Verwaltungstechnologien. Dank der unbeaufsichtigten Bereitstellung gibt es jedoch noch eine weitere Möglichkeit: die Bereitstellung von einem Remotewebserver mittels HTTP (Hypertext Transfer Protocol).

Bei dieser Vorgehensweise wird im Prinzip der Ansatz der Bereitstellung browserbasierter Anwendungen nachgebildet. Mithilfe von Methoden, die in den .NET Framework-Klassenbibliotheken bereitgestellt werden, kann eine Anwendung so geschrieben werden, dass sie die benötigten Assemblys dynamisch von einem Remotewebserver downloadet. Wenn zum ersten Mal auf eine bestimmte Assembly verwiesen wird, wird sie auf den Clientcomputer gedownloadet und dort für den Einsatz geladen. Falls sich die erforderliche Assembly bereits auf dem Clientcomputer befindet und die Version auf dem Webserver nicht geändert wurde, wird die lokale Kopie geladen. Wenn die Version auf dem Webserver aktualisiert wurde, wird die neue Version gedownloadet und ausgeführt. Updates werden somit automatisch an den Client weitergegeben, aber das Netzwerk wird nicht mit überflüssigen Downloads überschwemmt.

Beachten Sie, dass Assembly dynamisch gedownloadet werden, d.h., der Download erfolgt nur bei einem Verweis auf die Assembly. Dies ermöglicht das schnelle Laden von Anwendungen, da kein langwieriges, etliche MB umfassendes Installationsverfahren zum Starten der Ausführung notwendig ist.

 

Beweisbasierte Sicherheit: Sicherheit bei der unbeaufsichtigten Bereitstellung

Damit Systemadministratoren und Benutzer Anwendungen gefahrlos von einem Remotewebserver downloaden und ausführen können, muss ein Sicherheitssystem verfügbar sein, dass Clientcomputer vor der Aktivierung eines Virus oder anderen gefährlichen Codes schützt. Deswegen unterstützt das .NET Framework das leistungsfähige und präzise steuerbare System der beweisbasierten Sicherheit. Dieses System ermöglicht, Code unterschiedlichen Vertrauensstufen zuzuordnen, und zwar in Abhängigkeit von seiner Herkunft und anderen Merkmalen wie der Identität des Autors. So kann Code, der von einem Internetwebserver geladen wird, nicht auf die Registrierung oder das Dateisystem des Clientcomputers oder auf andere Server im Netzwerk zuzugreifen, wohingegen Code, der von einem Server im Unternehmensintranet stammt oder der einen bestimmten starken Namen bzw. eine Authenticode-Signatur aufweist, über deutlich mehr Berechtigungen verfügen kann. Das .NET Framework enthält Standardsicherheitseinstellungen, die sicher sind und sich für die meisten Anwendungsszenarien eignen. Diese Einstellungen können anhand der Sicherheitsbedürfnisse des jeweiligen Systemadministrator geändert werden.

Zur Laufzeit führt die .NET Framework-CLR (Common Language Runtime) Dank einer als Codezugriffssicherheit bezeichneten Technologie einfache Sicherheitsprüfungen durch, um sicherzustellen, dass der Code nur die Operationen ausführt, die von den ihm zugewiesenen Sicherheitsrichtlinien zugelassen werden. Hierbei überprüft die CLR nicht nur die Berechtigungen der Assembly, die eine bestimmte Operation auszuführen versucht, sondern auch die Berechtigungen aller anderen Assemblys im Stack, die die aktive Assembly aufrufen könnten, damit diese an ihrer Stelle eine Operation ausführt. Es werden nur Operationen ausgeführt, die in diesem umfassenden Stackwalk genehmigt wurden. Falls Softwareentwickler bezüglich der ordnungsgemäßen Ausführung einer Anwendung Bedenken haben, wenn ein bestimmter Mindestsatz an Sicherheitsberechtigungen nicht verfügbar ist, können sie die jeweiligen Berechtigungen bereits im Vorfeld mithilfe von Attributen angeben, die in den Metadaten der Assembly enthalten sind. Falls diese Berechtigungen nicht erteilt werden, wird die Assembly nicht geladen.

Diese Sicherheitsarchitektur sorgt somit dafür, dass nicht autorisierter Code keinen Zugriff auf das lokale System erhält oder dieses anderweitig missbrauchen kann. Zudem können IT-Administratoren die Anwendungen, die auf ihren Systemen ausgeführt werden, genauer steuern. Im Sommer 2000 wurden Foundstone, Inc. und CORE Security Technologies, zwei führende Unternehmen im Bereich der Bewertung von Sicherheitaspekten in IT-Systeme, von Microsoft beauftragt, die oben beschriebene Sicherheitsarchitektur und ihre Implementierung zu beurteilen. Basierend auf diesen Features und weiteren Aspekten der Sicherheitsinfrastruktur des .NET Frameworks kamen beide Unternehmen zu dem Ergebnis, dass das .NET Framework bei ordnungsgemäßer Verwendung "eine der besten Plattformen für die Entwicklung von Unternehmens- und Webanwendungen mit strengen Sicherheitsvorgaben" darstellt.¹ (Auszug aus Security in the Microsoft .NET Framework (englischsprachig) von Foundstone, Inc. und CORE Security Technologies.)

 

Smart Client-Anwendungen im Vergleich zu browserbasierten Anwendungen

Bei den genannten Smart Client-Technologien ist ohne weiteres erkennbar, warum das Modell plattformspezifischer Anwendungen erneut einen geeigneten Ansatz im Rahmen der Softwareentwicklung darstellt. Wie fällt jedoch die Bewertung im Vergleich zum browserbasierten Modell aus? Bei der Beurteilung sollten die folgenden Punkte berücksichtigt werden:
Offlinenutzung

Ein offensichtlicher und dennoch wichtiger Vorteil von Smart Client-Anwendungen im Vergleich zu browserbasierten Anwendungen ist die Möglichkeit, eine Anwendung offline verwenden zu können, zumal akzeptable Internetverbindungen alles andere als allgegenwärtig sind. Von IDC wurde angenommen, dass gegen Ende des Jahres 2001 in ungefähr 37,1 Prozent der US-amerikanischen Haushalte die eine oder andere Form von Heimbüroarbeit stattfinden wird und dass zur selben Zeit vermutlich jedoch nur 13,1 Prozent dieser Haushalte über eine Hochgeschwindigkeitsverbindung zum Internet verfügen werden.² Das bedeutet , dass ein Benutzer, der in einem Heimbüro arbeitet und über Zugang zum Internet verfügt (nicht berücksichtigt die Personen, die sich auf Reisen befinden und vom Hotel oder vom Flughafen aus zu arbeiten versuchen), aller Wahrscheinlichkeit nach gezwungen sein wird, jedes Mal eine unerträglich langsame DFÜ-Verbindung in Kauf nehmen zu müssen, wenn er versucht, mithilfe einer browserbasierten Anwendung auf Daten zuzugreifen oder diese zu bearbeiten. Und selbst wenn eine Hochgeschwindigkeitsverbindung verfügbar ist – was geschieht, wenn der Server ausfällt? Mit Smart Client-Anwendungen können diese Probleme vermieden werden. Es werden nur die erforderlichen Assemblys auf die lokale Festplatte gedownloadet, und der Benutzer kann problemlos offline arbeiten.

Effiziente und sichere Nutzung der vollen Leistungsfähigkeit verfügbarer Ressourcen

Webbasierte Anwendungen sind häufig so konzipiert, dass die gesamte Verarbeitung durch die Server erfolgt. Wenn die gesamte Verarbeitungslast auf den Server beschränkt bleibt, kann eine Anwendung auf unterschiedlichen Clienttypen einfacher bereitgestellt werden. Der Nachteil ist jedoch, dass der clientseitige Benutzer selbst bei der einfachsten Anforderung sowohl Netzwerkwartezeiten als auch Wartezeiten, die sich dadurch ergeben, dass der Server die jeweilige Anforderung in eine Warteschlange einreiht und sie dann verarbeitet, erdulden muss. Indem ein Teil oder die gesamte Arbeit lokal durch Smart Client-Anwendungen erledigt wird, werden Antwortzeiten verkürzt und die Netzwerk- und Serverlast reduziert, was wiederum die Skalierbarkeit der Infrastruktur verbessert. Eine Smart Client-Anwendung kann ohne Interaktion mit dem Netzwerk oder dem Server ausgeführt werden, wodurch diese Infrastruktur entlastet wird, oder nach Bedarf eine Serververbindung herstellen, um eine Assembly dynamisch zu downloaden oder um einen XML-Webdienst (Extensible Markup Language) aufzurufen. Die Tatsache, dass zumindest ein Teil der Arbeit lokal erfolgt, z. B. das Laden und Implementieren der Steuerelemente der Benutzeroberfläche, führt zu einer dynamischeren und benutzerfreundlicheren Umgebung sowie zu einer effizienteren Nutzung sowohl der verfügbaren Client- als auch der Netzwerkinfrastruktur.

Webbasierte Anwendungen können so gestaltet werden, dass ein Teil der Verarbeitung mithilfe von Skripts oder Microsoft ActiveX®-Steuerelementen auf den Client verlagert wird; beiden Varianten sind jedoch im Vergleich zum Smart Client-Anwendungsmodell deutlich engere Grenzen gesetzt. Webbasierte Skripts werden vorzugsweise in einem "Sandkasten" ausgeführt, wodurch deren Zugriff auf lokale Ressourcen verhindert wird. Skriptbasierte Anwendungen können keine Daten von der lokalen Festplatte des Clientbenutzers einlesen oder Daten auf diese Festplatte schreiben; sämtliche Daten müssen daher auf einem Remoteserver gespeichert werden. Wie zuvor kann auch dies zu Problemen führen, wenn einem Benutzer nur eine langsame Internetverbindung zur Verfügung steht oder er offline arbeiten möchte. Skriptbasierte Anwendungen können ebenfalls mit Anwendungen kommunizieren, die sich auf dem Clientcomputer befinden, wie z. B. Microsoft Excel oder Microsoft Outlook®, der Client für Messaging und Zusammenarbeit (wie im nächsten Abschnitt erläutert wird). Natürlich ist es möglich, dass diese Anwendungen einen Teil der Arbeit vom Server weg verlagern; hinsichtlich der Interaktion mit dem lokalen Computer bieten sie jedoch nicht die bestechende Flexibilität von Smart Client-Anwendungen. Darüber hinaus ist das Entwickeln einer "ordentlichen" skriptbasierten Anwendung sehr schwierig und teuer. DHTML-Anwendungen (Dynamic Hypertext Markup Language) können das Aussehen und die Funktionalität einer Microsoft Windows®-basierten Anwendung in gewissen Grenzen nachbilden. Doch auch wenn viele Tools zum Erstellen einfacher HTML-Oberflächen zur Verfügung stehen, ist eine vernünftige toolseitige Unterstützung beim Entwickeln von leistungsfähigen DHTML-Anwendungen praktisch nicht vorhanden. Der Code für die Benutzeroberfläche muss von Hand geschrieben werden. Bei Smart Client-Anwendungen muss ein Entwickler lediglich in Microsoft Visual Studio® .NET die gewünschten Steuerelemente auf ein Formular ziehen; der zugehörige Code wird dann automatisch generiert.

Mit ActiveX-Steuerelementen können diese Schwierigkeiten bis zu einem gewissen Grad überwunden werden. Sie können in Tools, wie z. B. dem Visual Studio-Entwicklungssystem, entwickelt werden und ermöglichen, dass eine webbasierte Anwendung auf die Ressourcen des lokalen Systems zugreift. Ihre Sicherheitsarchitektur ist jedoch dem Sicherheitskonzept von Smart Client-Anwendungen nicht ebenbürtig. Die Benutzer müssen sich entscheiden, ob sie ein Steuerelement ausführen möchten. Sobald ein Steuerelement aktiviert wurde, kann der Zugriff, der ihm auf den lokalen Computer gewährt wird, nicht mehr eingeschränkt werden.

In Smart Client-Anwendungen, die auf dem .NET Framework aufbauen, sind sämtliche Vorteile der unterschiedlichen Lösungen in einer Lösung zusammengefasst. Die Windows Forms-Bibliotheken ermöglichen das schnelle und einfache Entwickeln einer Benutzeroberfläche im Windows-Stil; ihr Code kann entweder von Hand geschrieben oder mittels Drag & Drop in Visual Studio .NET implementiert werden. Diese Bibliotheken können auf das lokale System zugreifen, jedoch nur in dem Maße, wie es von den zuvor beschriebenen beweisbasierten Sicherheitsrichtlinien des .NET Frameworks ermöglicht wird. Hierbei handelt es nicht mehr um Alles-oder-Nichts-Sicherheitsentscheidungen, sondern um präzise, auf der Herkunft des Codes basierende Entscheidungen, durch die einige Operationen zugelassen, andere jedoch untersagt werden. Darüber hinaus wird dem Benutzer die Last dieser Entscheidung abgenommen und im Hintergrund von der CLR übernommen, wobei entweder die Standardsicherheitsrichtlinien oder die vom Systemadministrator konfigurierten Einstellungen zum Tragen kommen.

Zugriff auf die Funktionalität des Betriebssystems

Smart Client-Anwendungen können leistungsstarke Windows-basierte APIs nutzen, die browserbasierten Anwendungen ohne ActiveX nicht zur Verfügung stehen. So können Smart Client-Anwendungen z. B. die Grafikfunktionalität der GDI- und GDI+-Bibliotheken (Graphical Device Interface) nutzen. Smart Client-Anwendungen können eine Bindung zu den Microsoft Office-APIs herstellen, so dass es Entwicklern möglich ist, Word, Microsoft Access, Excel, Outlook und das Präsentationsprogramm Microsoft PowerPoint® aus ihren eigenen Anwendungen heraus zu bearbeiten. Smart Client-Anwendungen können zum Einrichten von Peer-zu-Peer-Verbindungen zudem auf die Windows-Netzwerkbibliotheken zugreifen. Insbesondere dieses Beispiel sollte im folgenden Abschnitt detaillierter behandelt werden.

Verwenden der Peer-zu-Peer-Technologie

Ein Peer-zu-Peer-Szenario ist, kurz gefasst, ein Szenario, bei dem ein Computer sowohl als Client als auch als Server fungieren kann und somit Anforderungen an andere Peercomputer ausgeben sowie auf Anforderungen antworten kann, die von diesen Computern an ihn gerichtet werden. Gemäß der Gartner Group wird es durch die Peer-zu-Peer-Technologie möglich: "spontan miteinander zu kommunizieren, Daten auszutauschen und Anwendungsprogramme gemeinsam auszuführen". ³ Ein Beispiel für dieses Szenario wäre ein System zur gemeinsamen Nutzung von Dateien, bei dem eine auf einem Computer ausgeführte Anwendung, die gewünschte Datei auf einem Peercomputer suchen und von dort abrufen kann, während die eigenen Dateien wiederum für die anderen Peers verfügbar gemacht werden. Ein weiteres Beispiel wäre eine auf einem Computer ausgeführte Anwendung, die diejenigen Computer ausfindig machen kann, die über freie Prozessorkapazitäten und Datenträgerkapazitäten verfügen, um dann diese nicht verwendeten Ressourcen für die eigenen Zwecke einzusetzen. Hierdurch kann ein Unternehmen die verfügbare Infrastruktur optimal nutzen.

Die Peer-zu-Peer-Technologie stellt ein leistungsfähiges und äußerst vielversprechendes Konzept dar, das jedoch nur mithilfe von Smart Client-Anwendungen implementiert werden kann. Webbrowser, die entwurfsbedingt vom Benutzer gesteuert werden, verfügen nicht über die notwendige Kapazität, um auf spontane Anforderungen anderer Clients im Netzwerk zu achten und darauf zu reagieren.

Nutzen von XML-Webdiensten

Genau wie browserbasierte Anwendungen können auch .NET Framework-basierte Smart Client-Anwendungen mithilfe einiger weniger Codezeilen die Funktionalität nutzen, die von XML-Webdiensten oder Anwendungen bereitstellt wird, die ihre Funktionalität programmgesteuert über das Internet oder ein Intranet zur Verfügung stellen. Da XML-Webdienste auf Standardprotokollen wie SOAP und HTTP aufbauen, ermöglichen sie die plattformübergreifende Interaktion von Anwendungen und bieten eine perfekte Möglichkeit, um neue Anwendungen und Legacycode aufeinander abzustimmen.

 

Nachgewiesener Erfolg

Zahlreiche Softwareentwickler, angefangen bei den IT-Abteilungen von Unternehmen über unabhängige Softwarehersteller bis hin zu professionellen IT-Serviceunternehmen, haben bereits erkannt, dass das Smart Client-Modell des .NET Frameworks eine geeignete Architektur für die von ihnen benötigten Lösungen darstellt.

Bei Credit Suisse First Boston (CSFB), einer führenden und weltweit tätigen Kapitalanlagegesellschaft, arbeiten die Entwickler in den Sicherheitsabteilungen an der Erstellung von Smart Client-Anwendungen, die von Webservern aus bereitgestellt werden und die es Händlern für festverzinsliche Wertpapiere ermöglichen, den Status ihrer Geschäfte anzuzeigen. "Die Smart Client-Technologie ermöglicht uns, die Kosten für die Bereitstellung von Anwendungen drastisch zu reduzieren und den für diese Anwendungen erforderlichen Support zu vereinfachen", so Andrew K. Smith, Vice President von CSFB, der die Coretech-Gruppe von CSFB mit Sitz in Londond leitet. "Diese Technologie ermöglicht uns darüber hinaus, die einfache Bereitstellung von HTML-Seiten mit der Funktionsvielfalt vielseitiger Clients zu kombinieren, die wir von auf Visual Basic-basierenden Oberflächen gewohnt sind." Nach Schätzungen von Smith kann die Bank durch diese Form der Bereitstellung von Desktopanwendungen von Webservern aus mehrere Millionen Dollar an Kosten im IT-Bereich einsparen.

Intuitive Manufacturing Systems, ein unabhängiger Softwarehersteller, der ERP-Software für kleine und mittlere produzierende Unternehmen in der ganzen Welt anbietet, zog für die nächste Version seiner Erfolgssoftware IntuitiveERP das Smart Client-Modell einer browserbasierten Architektur vor. Aufgrund der unbeaufsichtigten Bereitstellung von einem Webserver aus, gepaart mit der Aussicht auf eine ansprechendere sowie leistungsfähigere Benutzeroberfläche und die Nutzbarkeit der Verarbeitungsleistung und des Arbeitsspeichers des Clientcomputers, fiel den Entwicklern von Intuitive die Wahl nicht schwer.

Immedient, eine Unternehmens- und IT-Beratungsfirma mit einem weit verzweigten Netz an Niederlassungen in den USA stellte vor nicht allzu langer Zeit für ihren Kunden General Services Administration eine Anwendung zur Nachverfolgung fakturierter Forderungen auf das .NET Framework um. Ursprünglich wurde eine browserbasierten Architektur in Erwägung gezogen. Letztendlich stellte sich jedoch heraus, dass Windows Forms in Kombination mit der unbeaufsichtigten Bereitstellung von einem Webserver aus, eine leistungsfähigere und intuitivere Benutzeroberfläche, bessere Leistung und die Flexibilität der Offlineverwendung bot sowie gleichzeitig sämtliche Vorzüge aufzuweisen hatte, die die Bereitstellung und Wartung browserbasierter Anwendungen auszeichnen.

 

Zusammenfassung: Wann und wo bietet sich die Implementierung von Smart Clients an?

Die Smart Client-Architektur eignet sich nicht für jedes Szenario. Beispielsweise beim E-Commerce und in ähnlichen Szenarien, in denen die Benutzerplattformen nicht bekannt oder sehr unterschiedlich sind, stellt das browserbasierte Modell weiterhin den am besten umsetzbaren Ansatz dar. Innerhalb der IT-Umgebung eines Unternehmens, in der bekannt ist, dass Clients das .NET Framework unter einem Windows-Betriebssystem ausführen, stellt das Smart Client-Modell die Architektur der Wahl dar, da sie die Leistungsfähigkeit und Flexibilität vielseitiger Clientanwendungen mit der Stabilität und Einfachheit der Bereitstellung browserbasierter Anwendungen in sich vereinigt.

1 Security in the Microsoft .NET Framework: An Analysis by Foundstone, Inc. and CORE Security Technologies" (Foundstone, Inc., November 2001)
2 US Home Office Forecast and Analysis, 1999–2004" von Mary Porter und Ray Boggs (International Data Corporation, June 2000)
3 Seeking New Investment Opportunities: The Next Paradigm" von R. Batchelder, S. Hayward und A. Roussel (Gartner Group, September 2001)