Die drei gebräuchlichsten Muster sind die folgenden:
Thin Web-Client - Dieses Muster wird hauptsächlich für Internet-basierte Anwendungen verwendet, in denen es nur
wenig Steuerelemente für die Konfiguration des Clients gibt. Der Client benötigt lediglich einen Standard-Web-Browser
(der Formulare unterstützt). Die gesamte Geschäftslogik wird auf dem Server ausgeführt.
Thick Web-Client - Bei diesem Muster wird ein für die Architektur wichtiger Teil der Geschäftslogik auf der
Clientmaschine ausgeführt. In der Regel verwendet der Client dynamisches HTML, Java-Applets oder
ActiveX-Steuerelemente, um die Geschäftslogik auszuführen. Die Kommunikation mit dem Server erfolgt über HTTP.
Bereitstellung im Internet - Zusätzlich zum HTTP-Protokoll für die Client- und Serverkommunikation können andere
Protokolle wie IIOP oder DCOM für die Unterstützung eines verteilten Objektsystems verwendet werden. Der Web-Browser
fungiert hauptsächlich als Bereitstellungs- und Containereinheit für ein verteiltes Objektsystem.
Diese Liste erhebt nicht den Anspruch, vollständig zu sein, insbesondere in einer Branche, in der praktisch jährlich
technologische Revolutionen vorkommen. Sie enthält eine Zusammenfassung der gebräuchlichsten Architekturmuster für
Webanwendungen. Es ist möglich, mehrere Muster auf eine Architektur anzuwenden.
Das Architekturmuster Thin Web-Client ist hilfreich für Internet-basierte Anwendungen, in denen lediglich eine minimale
Konfiguration des Clients möglich ist. Die gesamte Geschäftslogik wird während der Bearbeitung von Seitenanforderungen
für den Client-Browser auf dem Server ausgeführt.
Dieses Muster eignet sich für Internet-basierte Webanwendungen und solche Umgebungen, in denen der Client nur minimale
Rechenkapazität bzw. gar keine Steuerung über seine Konfiguration hat.
Die meisten Internet-Anwendungen für E-Commerce verwenden dieses Muster, da es geschäftlich nicht sehr sinnvoll ist,
Kundenkreise auszuschließen, nur weil sie nicht über genügend Clientmerkmale verfügen. Eine typische
E-Commerce-Anwendung versucht, so viele Kunden wie möglich anzusprechen, denn schließlich ist das Geld eines
Commodore-Amiga-Benutzers genauso gut wie das eines Windows-NT-Benutzers.
Die Hauptkomponente des Architekturmusters Thin Web Client befinden sich auf dem Server. In vielerlei Hinsicht stellt
diese Architektur die minimale Webanwendungsarchitektur dar. Die Hauptkomponenten sind im Folgenden aufgelistet:
Client-Browser - Alle Standard-HTML-Browser, die Formulare unterstützen. Der Browser fungiert als
generalisierte Benutzerschnittstelleneinheit. In einer schlanken Web-Client-Architektur verwendet bietet der
Client-Browser nur die Möglichkeit, Cookies zu akzeptieren und zurückzugeben. Der Anwendungsbenutzer verwendet den
Browser, um Webseiten anzufordern: HTML oder Server. Die zurückgegebene Seite enthält eine vollständig formatierte
Benutzerschnittstelle mit Text- und Eingabesteuerelementen, die der Browser in der Clientanzeige wiedergibt. Alle
Benutzerinteraktionen mit dem System erfolgen über den Browser.
Web-Server - Der Hauptzugriffspunkt für alle Client-Browser. Client-Browser in der schlanken
Web-Client-Architektur greifen nur über den Web-Server auf das System zu. Der Web-Server akzeptiert
Anforderungen für Webseiten, die statische HTML- oder Serverseiten sein können. Je nach Anforderung kann der
Web-Server verschiedene serverseitige Verarbeitungsschritte einleiten. Wenn die Seitenanforderung für eine
scriptgesteuerte Serverseite, ein CGI-, ISAPI- oder NSAPI-Modul bestimmt ist, delegiert der Web-Server die
Verarbeitung an den entsprechenden Scriptinterpreter oder an das ausführbare Modul. In jedem Fall ist das
Ergebnis eine HTML-formatierte Seite, die in einem HTML-Browser angezeigt werden kann.
HTTP-Verbindung - HTTP ist das am häufigsten verwendete Protokoll für die Kommunikation
zwischen Client-Browsern und Web-Servern. Dieses Architekturelement stellt eine verbindungsunabhängige Art der
Kommunikation zwischen Client und Server dar. Jedes Mal, wenn Client und Server Informationen an den jeweils
anderen senden, wird eine neue und separate Verbindung zwischen den beiden Partnern eingerichtet. Eine Variante
von HTTP-Verbindungen sind sichere HTTP-Verbindungen über Secure Sockets Layer (SSL). Bei diesem Typ von
Verbindung werden die zwischen Client und Server übertragenen Daten unter Verwendung von
Verschlüsselungstechnologien mit öffentlichem und privatem Schlüssel verschlüsselt.
HTML-Seite - Eine Webseite mit Benutzerschnittstelle und Inhaltsinformationen, die serverseitig nicht
verarbeitet werden. In der Regel enthalten diese Seiten erläuternden Text wie Anleitungen oder Hilfetext oder
HTML-Eingabeformulare. Wenn ein Web-Server eine Anforderung für eine HTML-Seite empfängt, ruft der Server
einfach die Datei ab und sendet sie ohne Filterung an den anfordernden Client zurück.
Serverseite - Webseiten, die serverseitig verarbeitet werden. In der Regel werden diese Seiten auf dem
Server als scriptgesteuerte Seiten (Active Server Pages, Java Server Pages, Cold Fusion Pages) implementiert,
die durch einen Filter im Anwendungsserver oder durch ausführbare Module (ISAPI oder NSAPI) verarbeitet werden.
Diese Seiten haben potenziell Zugriff auf alle serverseitigen Ressourcen einschließlich der
Geschäftslogikkomponenten, Datenbanken, traditionellen Systeme und Händlerkontosysteme.
Anwendungsserver - Die primäre Engine für die Ausführung der serverseitigen Geschäftslogik. Der
Anwendungsserver ist für die Ausführung des Codes in den Serverseiten verantwortlich. Er kann sich auf
derselben Maschine wie der Web-Server befinden und kann selbst in demselben Prozessbereich wie der Webserver
ausgeführt werden. Der Anwendungsserver ist logisch gesehen ein gesondertes Architekturelement, der er
ausschließlich mit der Ausführung der Geschäftslogik beschäftigt ist und eine vollständig andere Technologie
als der Web-Server verwenden kann.
Die folgende Abbildung zeigt ein Diagramm der logischen Sicht auf die schlanke Web-Client-Architektur.
Minimale schlanke Web-Client-Architektur
In der minimalen schlanken Web-Client-Architektur fehlen einige optionale Komponenten, die normalerweise in
Webanwendungen zu finden sind, z. B. die Datenbank. Die meisten Webanwendungen verwenden eine Datenbank, um die
Geschäftsdaten persistent zu speichern. In manchen Fällen können in der Datenbank auch die Seiten selbst gespeichert
werden (diese Verwendung einer Datenbank stellt jedoch ein anderes Architekturmuster dar). Da Webanwendungen eine
beliebige Anzahl von Technologien verwenden können, um Geschäftsdaten persistent zu speichern, wird die
Architekturkomponente mit dem eher generischen Begriff Persistenz bezeichnet. Die Komponente Persistenz umfasst auch
die mögliche Verwendung eines Transaktionsverarbeitungsmonitors.
Eine Datenbank lässt sich am einfachsten mit dem System verbinden, indem den Scripts in den Serverseiten der direkte
Zugriff auf die Komponente Persistenz ermöglicht wird. Selbst bei diesem direkten Zugriff werden
Standarddatenzugriffsbibliotheken wie RDO, ADO, ODBC, JDBC, DBLib usw. verwendet, die die niederen Arbeiten
durchführen. In dieser Situation kennen die Serverseiten das Datenbankschema. Für relationale Datenbanksysteme
erstellen und führen Sie die erforderlichen SQL-Anweisungen aus, um auf die Daten in der Datenbank zuzugreifen. In
kleineren und weniger komplexen Webanwendungen kann dies ausreichend sein. Für größere und leistungsfähigere Systeme
wird jedoch die Verwendung einer vollständigen Geschäftsobjektschicht empfohlen.
Eine Geschäftsobjektkomponente kapselt die Geschäftslogik. Diese Komponente wird normalerweise im Anwendungsserver
kompiliert und ausführt. Eine Geschäftsobjektkomponente hat unter anderem den Vorteil, dass andere Web- oder
Client/Server-Systeme dieselben Komponenten verwenden können, um dieselbe Geschäftslogik aufzurufen. Beispielsweise ist
es möglich, dass ein Internet-basiertes Schaufenster Serverseiten und das Architekturmuster Thin Web-Client für alle
Konsumentenaktivitäten verwendet, die Abteilung für Rechnungsstellung aber einen komplexeren Zugriff auf die Daten und
die Geschäftslogik erfordert und deshalb einem Client/Server-System den Vorzug vor einem webbasierten System gibt. Das
System der Abteilung für Rechnungsstellung kann dieselben Geschäftskomponenten in demselben Anwendungsserver als
Webfront, aber trotzdem ihre eigene und komplexe Clientsoftware verwenden.
Da relationale Datenbanken der am häufigsten verwendete Datenbanktyp in etablierten Geschäften ist, existiert
normalerweise eine zusätzliche Architekturkomponente zwischen Anwendungsserver und Datenbank. Diese Komponente stellt
einen Zuordnungsservice für Objekte und relationale Datenbanken bereit. Diese Zuordnungsschicht selbst kann auf
verschiedene Arten implementiert werden. Eine detaillierte Beschreibung dieser Komponente würde den Rahmen dieser Seite
sprengen.
Weitere Optionen, die diesem Architekturmuster häufig hinzugefügt werden, sind die Integration mit traditionellen
Systemen und für E-Commerce-Anwendungen ein Händlerkontosystem. Der Zugriff auf beide Systeme erfolgt über die
Geschäftsobjekte (oder den Anwendungsserver für Systeme ohne formale Geschäftsobjektkomponente). Traditionelle Systeme
sind beispielsweise ein Buchungssystem oder ein System für Fertigungsplanung. Das Händlerkontosystem ermöglicht einer
Internet-Webanwendung, Zahlungen per Kreditkarte zu akzeptieren und zu verarbeiten. Es gibt zahlreiche
Händlerkontosysteme für kleine Unternehmen, die in den Onlinemarkt einsteigen möchten. Bei größeren Unternehmen wird
eher eine Schnittstelle zu einem bereits vorhandenen System verwendet, das Kreditkartenanforderungen verarbeiten kann.
Mit diesen optionalen Komponenten wird die logische Sicht auf das Architekturmuster Thin Web-Client ein wenig
vollständiger. Die logische Sicht ist in der folgenden Abbildung dargestellt.
Logische Sicht auf den Thin Web-Client
Viele Serverkomponenten einer Webanwendung finden sich auch in nicht webbasierten Anwendungen. Das Design und die
Architektur des Backend einer Webanwendung ist dem Design eines Mainframe- oder Client/Server-Systems nicht unähnlich.
Webanwendungen setzen Datenbanken und Transaktionsverarbeitungsmonitore aus denselben Gründen wie andere Systeme ein.
Enterprise Java Beans (EJB) und Microsoft Transaction Server (MTS) sind neue Tools und Technologien, die zwar für
Webanwendungen eingeführt wurden, aber gleichermaßen für andere Anwendungsarchitekturen geeignet sind.
Die Architektur und das Design der serverseitigen Komponenten einer Webanwendung werden genau wie die jedes
Client/Server-Systems behandelt. Da sich dieses Architekturmuster auf das Web und die für Webanwendungen spezifischen
Komponenten konzentriert, würde eine detaillierte Beschreibung möglicher Backend-Serverarchitekturen über den Rahmen
dieses Musters hinausgehen.
Das der Dynamik dieses Architekturmusters zugrunde liegende Prinzip ist, dass die Geschäftslogik nur als Reaktion auf
eine Webseitenanforderung durch den Client ausgeführt wird. Clients verwenden das System, indem Sie über das
HTTP-Protokoll Webseiten vom Web-Server anfordern. Wenn die angeforderte Seite eine HTML-Seite im Dateisystem des
Web-Servers ist, wird diese einfach abgerufen und an den anfordernden Client gesendet.
Wenn es sich bei der Seite um eine scriptgesteuerte Seite handelt, d. h. eine Seite mit interpretierbarem Code, der
zuerst verarbeitet werden muss, damit er an den Client zurückgegeben werden kann, delegiert der Web-Server diese Aktion
an den Anwendungsserver. Der Anwendungsserver interpretiert die Scripts in der Seite und interagiert auf entsprechende
Anweisung mit den serverseitigen Ressourcen wie Datenbanken, E-Mail-Services, traditionellen Systemen usw. Der
scriptgesteuerte Code hat über die Anwendung und den Web-Server Zugriff auf spezielle Informationen, die diese
Seitenanforderung begleiten. Zu diesen Informationen gehören Werte, die vom Benutzer in die Formularfelder eingegeben
werden, sowie Parameter, die der Seitenanforderung angefügt werden. Das Endergebnis ist eine ordnungsgemäß formatierte
HTML-Seite, die an den Client zurückgesendet werden kann.
Die Seite kann auch ein ausführbares Modul wie eine ISAPI- oder NSAPI-DLL sein. Eine DLL oder Dynamic Link Library ist
eine kompilierte Bibliothek, die zur Laufzeit vom Anwendungsserver geladen und ausgeführt werden kann. Das Modul hat
Zugriff auf dieselben Details zur Seitenanforderung (Werte in Formularfeldern und Parameter) wie scriptgesteuerte
Seiten.
Der Schlüsselfaktor des dynamischen Verhaltens dieses Musters ist der, dass die Geschäftslogik nur während der
Verarbeitung einer Seitenanforderung aufgerufen wird. Sobald die Seitenanforderung verarbeitet wurde, wird das Ergebnis
an den anfordernden Client zurückgesendet, und die Verbindung zwischen dem Client und dem Server wird beendet. Es ist
zwar möglich, dass der Geschäftsprozess nach der Verarbeitung der Anforderung noch etwas länger existiert, aber dies
ist nicht die Norm.
Dieser Typ von Architektur eignet sich für Anwendungen, in denen die Antwort des Servers in einer für den Benutzer
angemessenen Zeit (und innerhalb des vom Client-Browser zulässigen Zeitlimits) zurückgegeben werden kann. Normalerweise
handelt sich hier um nicht mehr als wenige Sekunden. Dies ist möglicherweise nicht das geeignetste Architekturmuster,
wenn die Anwendung dem Benutzer das Starten und Überwachen eines Geschäftsprozesses mit langer Laufzeit gestatten muss.
Mit Push-Technologien kann dem Client die Überwachung von Prozessen mit langer Laufzeit ermöglicht werden. Bei den
meisten Push-Technologien wird der Server lediglich in regelmäßigen Abständen abgefragt.
Eine weitere wichtige Auswirkung dieses Architekturmusters ist die beschränkte Möglichkeit, komplexe
Benutzerschnittstellen einzusetzen. Da der Browser als Bereitstellungsmechanismus für die gesamte Benutzerschnittstelle
dient, müssen alle Fensterobjekte und Steuerelemente der Benutzerschnittstelle über den Browser verfügbar sein. In den
meisten bekannten Browsern und in den HTML-Spezifikationen sind diese auf einige Texteingabefelder und Schaltflächen
beschränkt. Auf der andere Seite könnte argumentiert werden, dass eine solch eingeschränkte Benutzerschnittstelle ein
Pluspunkt ist. Eine spärlich ausgestattete Benutzerschnittstelle verhindert, dass das Entwicklungsteam zu viel Zeit
damit verbringt, "coole" und "adrette" Schnittstellen zu erstellen, wenn auch einfachere genügen.
Das Architekturmuster Thick Web-Client erweitert das Muster Thin Web-Client um die Verwendung clientseitiges Scripting
und benutzerdefinierter Objekte wie ActiveX-Steuerelementen und Java-Applets. Der Name des Musters Thick Web-Client ist
von der Tatsache abgeleitet, dass der Client tatsächlich einen Teil der Geschäftslogik des Systems ausführen kann und
deshalb mehr als nur ein generalisierter Container für die Benutzerschnittstelle ist.
Das Architekturmuster Thick Web Client eignet sich für Webanwendungen, in denen eine bestimme Clientkonfiguration und
Browser-Version vorausgesetzt werden kann, eine komplexe Benutzerschnittstelle erwünscht ist und/oder ein gewisser Teil
der Geschäftslogik auf dem Client ausgeführt werden kann. Ein Hauptunterscheidungsmerkmal der Muster Thin Web-Client
und Thick Web-Client liegt in der Rolle, die der Rolle bei der Ausführung der Geschäftslogik des Systems spielt.
Die beiden starken Motivationsgründe für die Verwendung von Thick Web-Client sind das erweiterte Leistungsspektrum der
Benutzerschnittstelle und die Ausführung von Geschäftslogik durch den Client. Mit einer komplexen Benutzerschnittstelle
könnten beispielsweise dreidimensionale Modelle angezeigt und geändert oder ein Finanzgraph animiert werden. In einigen
Fällen kann die ActiveX-Steuerung verwendet werden, um mit clientseitigen Überwachungseinrichtungen zu kommunizieren.
Beispielsweise könnte eine Einrichtung, die Patienten an einem anderen Ort täglich überwachen muss, medizinische
Geräte, die den Blutdruck, Blutzucker oder andere vitale Funktionen messen können, einsetzen und damit in der Lage
sein, persönliche Besuche auf zwei Mal die Woche herunterzuschrauben.
In einigen Fällen kann Geschäftslogik ausschließlich auf dem Client ausgeführt werden. Hierfür müssen alle Daten, die
für die Ausführung des Prozesses erforderlich sind, auf dem Client verfügbar sein. Es kann sich dabei um so einfache
Logik wie das Überprüfen eingegebener Daten handeln. Datumsangaben können auf Genauigkeit geprüft oder mit anderen
Datumsangaben verglichen werden (z. B., dass das Geburtsdatum vor dem Einlieferungsdatum in das Krankenhaus liegt). Je
nach Geschäftsregeln des Systems und den eingegebenen Werten können einige Felder aktiviert oder inaktiviert sein.
Nahe liegt, dass clientseitige Scripts, Applets, Steuerelemente und Plug-ins im Internet eingesetzt werden und zwar in
Form erweiterter Schnittstellen. Java-Scripts werden häufig verwendet, um die Farbe oder Darstellung einer Schaltfläche
oder Menüpunkts in HTML-Seiten zu ändern. Java-Applets und ActiveX-Steuerelemente werden verwendet, um Steuerelemente
für komplexe hierarchische Baumstruktursichten zu erstellen.
Das ActiveX-Steuerelement und Plug-in Shockwave ist eine der bekanntesten Benutzerschnittstellenkomponenten, die
derzeit im Internet verwendet werden. Es unterstützt interaktive Animationen und wird in erste Linie verwendet, um
Internet-Sites mit attraktiven Grafiken aufzupeppen, wird aber auch eingesetzt, um Simulationen anzuzeigen und
Sportereignisse zu überwachen.
Microsoft Agent Control wird von mehreren Internet-Sites verwendet, um Sprachbefehle und Aktionsausführungen in dem
Browser zu unterstützen, in dem der Benutzer in der Website navigiert.
Außerhalb des Internet hat ein Unternehmen im Gesundheitswesen eine webbasierte Intranet-Anwendung für die Verwaltung
von Patientenunterlagen und Abrechnung entwickelt. Die webbasierte Benutzerschnittstelle nutzt das clientseitige
Scripting stark, um Datenprüfungen durchzuführen, und als Unterstützung des Benutzers bei der Navigation in der Site.
Außer Scripts verwendet die Anwendung mehrere ActiveX-Steuerelemente, um XML-Inhalt zu verwalten, der als primäres
Codierungsschema für Informationen verwendet wird.
Die gesamte Kommunikation zwischen Client und Server erfolgt wie im Muster Thin Web-Client über HTTP. Da HTTP einer
"verbindungsunabhängige" Protokolltyp ist, ist die meiste Zeit keine Verbindung zwischen Client und Server geöffnet.
Nur während Seitenanforderungen sendet der Client Informationen. Das bedeutet, dass das clientseitige Scripting,
ActiveX-Steuerelemente und Java-Applets auf die Interaktion mit Objekten auf dem Client ausschließlich beschränkt sind.
Das Muster Thick Web-Client nutzt bestimmte Browser-Funktionen wie ActiveX-Steuerelemente oder Java-Applets, um
Geschäftslogik auf dem Client auszuführen. ActiveX-Steuerelemente sind kompilierte, ausführbare Binärprogramme, die mit
HTTP auf den Client heruntergeladen werden können und vom Browser aufgerufen werden. Da ActiveX-Steuerelemente im
Wesentlichen COM-Objekte sind, haben sie vollständige Kontrolle über die clientseitigen Ressourcen. Sie können mit dem
Browser und mit dem Clientsystem selbst interagieren. Aus diesem Grund werden ActiveX-Steuerelemente, insbesondere die
im Internet, normalerweise von einem vertrauenswürdigen Dritten "authentifiziert".
Die neuesten Versionen bekannter HTML-Browser unterstützen jetzt auch clientseitiges Scripting. HTML-Seiten können mit
Scripts eingebettet werden, die in Java Script oder VB Script geschrieben sind. Diese Scripting-Fähigkeit ermöglicht
dem Browser, selbst einen Teil des Codes auszuführen (oder vielmehr zu interpretieren), der zur Geschäftslogik des
Systems gehören kann. Es wird "kann" gesagt, weil Clientscripts sehr häufig nur zusätzliche Aspekte zur
Benutzerschnittstelle beisteuern und kein eigentlicher Teil der Geschäftslogik sind. In jedem Fall gibt es potenziell
wichtige Elemente (d. h. Scripts) für die Architektur, die in HTML-Seiten eingebettet sind und als solche ausgedrückt
werden müssen.
Da das Muster Thick Web-Client wirklich nur eine Erweiterung des Musters Thin Web-Client ist, sind die meisten für die
Architektur relevanten Elemente dieselben. Im Folgenden sind die zusätzlichen Elemente beschrieben, die das Muster
Thick Web-Client einbringt:
Clientscript - JavaScript- oder Microsoft®-VisualBasic®-Script, das in HTML-formatierte Seiten
eingebettet ist. Der Browser interpretiert das Script. W3C (ein Internet-Standardisierungsgremium) hat HTML-
und DOM-Schnittstelle (Document Object Model), die der Browser für Clientscripts anbietet, definiert.
XML-Dokument - Ein mit eXtensible Markup Language (XML) formatiertes Dokument. XML-Dokumente stellen
Inhalt (Daten) ohne Benutzerschnittstellenformatierung dar.
ActiveX-Steuerelement - Ein COM-Objekt, das in einem Clientscript referenziert und bei Bedarf auf den
Client "heruntergeladen" werden kann. Wie jedes andere COM-Objekt hat dieses Objekt vollständigen Zugriff auf
die Clientressourcen. Der grundsätzliche Sicherheitsmechanismus für den Schutz der Clientmaschinen sind
Authentifizierung und Signatur. Internet-Browser können so konfiguriert werden, dass sie keine
ActiveX-Steuerelemente akzeptieren bzw. den Benutzer warnen, wenn ActiveX-Steuerelemente auf den Client
heruntergeladen werden. Die Authentifizierungs- und Signaturmechanismen stellen über einen vertrauenswürdigen
Dritten lediglich die Identität des Autors des Steuerelements sicher.
Java-Applet - Eine in sich geschlossene und kompilierte Komponente, die im Kontext eines Browsers
ausgeführt wird. Aus Sicherheitsgründen hat ein Java-Applet nur beschränkten Zugriff auf clientseitige
Ressourcen. Java-Applets werden als Elemente für komplexe Benutzerschnittstellen und für andere, nicht
schnittstellenbezogene Zwecke wie die Syntaxanalyse von XML-Dokumenten oder zum Kapseln komplizierter
Geschäftslogik verwendet.
Java-Bean - Eine Java-Komponente, die eine bestimmte Gruppe von Schnittstellen implementiert, die eine
problemlose Integration der Komponente in größere und komplexere Systeme ermöglicht. Der Begriff Bean (engl.
für Bohne) drückt aus, dass die Komponente von Natur aus klein ist und einen einzigen Zweck hat. Für eine volle
Tasse Kaffee wird in der Regel mehr als eine Bohne benötigt. ActiveX ist die Entsprechung zu Java-Bean in
Microsoft-orientierter Architektur.
Die folgende Abbildung zeigt ein Diagramm der logischen Sicht auf die Thick-Web-Client-Architektur.
Logische Sicht auf das Architekturmuster Thick Web-Client
Die grundsätzliche Dynamik des Musters Thick Web-Client entspricht im Wesentlichen der des Musters Thin Web-Client.
Zusätzliches bietet dieses Muster die Möglichkeit, Geschäftslogik auf dem Client auszuführen. Wie beim Muster Thin
Web-Client findet die gesamte Kommunikation zwischen Client und Server nur während Seitenanforderungen statt. Die
Geschäftslogik hingegen kann jedoch mit Scripts, Steuerelementen und Applets teilweise auf dem Client ausgeführt
werden.
Wenn eine Seite an einen Client-Browser gesendet wird, kann diese Scripts, Steuerelemente und Applets enthalten. Diese
Scripts, Steuerelemente und Applets können einfach zur Erweiterung der Benutzerschnittstelle dienen oder ein Beitrag
zur Geschäftslogik sein. Die einfachste Form von Geschäftslogik sind Überprüfungen von Feldern. Mit Clientscripts kann
geprüft werden, ob die Eingabe gültig ist, und das nicht nur in einem Feld, sondern in allen Feldern einer bestimmten
Webseite. Eine E-Commerce-Anwendung, die Benutzern die Konfiguration Ihrer Computersysteme ermöglicht, kann
beispielsweise Scripts verwenden, um zu verhindern, dass inkompatible Optionen ausgewählt werden.
Damit Java-Applets und ActiveX-Steuerungen verwendet werden können, müssen sie im Inhalt der HTML-Seite angegeben
werden. Diese Steuerelemente und Applets können unabhängig von den Scripts in der Seite arbeiten oder von Scripts in
der Seite gesteuert werden. Scripts in einer HTML-Seite können auf besondere Ereignisse reagieren, die vom Browser
gesendet werden. Diese Ereignisse können anzeigen, dass der Browser soeben das Laden der Webseite abgeschlossen hat,
oder dass die Maus des Benutzers gerade über einen bestimmten Bereich der Seite bewegt wurde.
Die Elemente haben Zugriff auf die DOM-Schnittstelle des Browsers. Diese Schnittstelle ist ein W3C-Standard, mit dem
Scripts, Steuerelementen und Applets Zugriff auf den Browser und auf HTML-Inhalt in Seiten erteilt werden kann. Die
entsprechende Implementierung von Microsoft und Netscape für dieses Modell ist Dynamic HTML (DHTML). DHTML ist mehr als
nur eine Implementierung der DOM-Schnittstelle. DHTML enthält Ereignisse, die während der Erstellung dieser
Dokumentation noch nicht in die Spezifikation DOM Level 1 aufgenommen waren.
Im Kern des Document Object Model befindet sich eine Gruppe von Schnittstellen, die speziell für die Bearbeitung von
XML-Dokumenten bestimmt sind. XML ist eine flexible Sprache, mit der Designer eigene Tags für spezielle Zwecke
schreiben können. Die DOM-Schnittstelle ermöglicht Clientscripts den Zugriff auf XML-Dokumente.
Die Verwendung von XML als Standardmechanismus für den Austausch von Informationen zwischen Client und Server wird
durch die Verwendung spezieller Komponenten auf dem Client ermöglicht. ActiveX-Steuerelemente oder Java-Applets können
auf den Client kopiert werden, um unabhängig XML-Dokumente anzufordern und zu senden. Beispielsweise könnte ein in eine
HTML-Seite eingebettetes Java-Applet über HTTP ein XML-Dokument vom Web-Server anfordern. Der Web-Server sucht und
verarbeitet die angeforderten Informationen und sendet kein HTML-Dokument, sondern ein mit XML formatiertes Dokument
zurück. Das Applet, das immer noch in der HTML-Seite auf dem Client ausgeführt wird, akzeptiert das XML-Dokument,
analysiert es und interagiert dann mit dem aktuellen HTML-Dokument im Browser, um dessen Inhalt für den Benutzer
anzuzeigen. Der gesamte Ablauf erfolgt im Kontext einer einzigen HTML-Seite im Client-Browser.
Die bei weitem größte Auswirkung dieses Musters ist die Portierbarkeit auf andere Browser-Implementierungen. Nicht alle
HTML-Browser unterstützen Java Script oder VisualBasic Script. Außerdem können nur Microsoft-Windows-basierte Clients
ActiveX-Steuerelemente verwenden. Selbst wenn ausschließlich eine bestimmte Marke von Client-Browser verwendet wird,
gibt es geringfügige Unterschiede in den Implementierungen des Document Object Model.
Wenn clientseitige Scripts, Steuerelemente oder Applets verwendet werden, muss das Testteam die vollständige Reihe von
Testszenarios für jede zu unterstützende Clientkonfiguration ausführen. Da kritische Geschäftslogik auf dem Client
ausgeführt wird, ist ein konsistentes und korrekte Verhalten für alle betroffenen Browser von entscheidender Bedeutung.
Gehen Sie niemals davon aus, dass sich alle Browser gleich verhalten. Es ist nicht nur möglich, dass unterschiedliche
Browser sich mit demselben Quellcode unterschiedlich verhalten, sondern auch, dass derselbe Browser auf
unterschiedlichen Betriebssystemen ein abweichendes Verhalten aufweist.
Das Architekturmuster Bereitstellung im Internet hat diesen Namen, weil hauptsächlich das Internet als
Bereitstellungsmechanismus für ein ansonsten traditionelles verteiltes, objektorientiertes Client/Server-System
verwendet wird. Einerseits ist dieser Typ von Anwendung eine echte verteilte, objektorientierte
Client/Server-Anwendung, die zufälligerweise einen Web-Server und einen Client-Browser als relevante
Architekturelemente enthält. Egal ob ein solches System eine Webanwendung mit verteilten Objekten oder ein verteiltes
Objektsystem mit Webelementen ist, das System ist letztendlich dasselbe. Die Tatsache, dass diese beiden Sichtweisen
auf dasselbe System beziehen und verteilte Objektsysteme immer als Systeme eingestuft wurden, die eine sorgfältige
Modellierung erfordern, betont einmal mehr das Thema dieser Seite, nämlich dass Webanwendungen wie jedes andere
Softwaresystem modelliert und entworfen werden müssen.
Das Architekturmuster Bereitstellung im Internet eignet sich, wenn Client- und Netzkonfigurationen streng kontrolliert
werden. Dieses Muster eignet sich besonders gut für Internet-basierte Anwendungen, in denen Clientkonfiguration nur
wenig oder gar nicht kontrollierbar sind oder wenn die Netzkommunikation nicht zuverlässig ist.
Die Hauptstärke dieser Architektur liegt in ihrer Fähigkeit, vorhandene Geschäftsobjekte im Kontext einer Webanwendung
nutzen zu können. Durch eine direkte und permanente Kommunikation zwischen Client und Server können die Einschränkungen
der beiden zuvor vorgestellten Webanwendungsmuster überwunden werden. Der Client kann genutzt werden, um wesentlich
mehr relevanter Geschäftslogik auszuführen.
Es ist unwahrscheinlich, dass dieses Architekturmuster isoliert verwendet wird, sondern mit einem der beiden zuvor
beschriebenen Muster kombiniert wird. Das typische System verwendet mindestens eines der ersten Architekturmuster für
die Teile des Systems, die keine komplexe Benutzerschnittstelle erfordern, oder wenn Clientkonfigurationen für die
Unterstützung einer großen Clientanwendung nicht stabil genug sind.
Die Website CNN Interactive ist eine der aktivsten Websites im Internet. Die meisten öffentlichen Zugriffe erfolgen
über konventionelle Browser und direkter HTML 3.2. Hinter der Website befindet sich jedoch ein komplexes
CORBA-basiertes Netzwerk mit Browsern, Servern und verteilten Objekten. Eine Fallstudie dieses Systems wurde in
Distributed Computing veröffentlicht.
Ein Unternehmen im Gesundheitswesen hat eine Webanwendung für die Verwaltung von Patienten, Patientenakten und für die
Abrechnung erstellt. Die Abrechnungsaspekte des Systems werden nur von einem relativ kleinen Teil der Benutzergemeinde
verwendet. Ein Großteil des traditionellen Abrechnungssystems wurde in FoxPro geschrieben. Das neue webbasierte System
nutzt den alten FoxPro-Code und erstellt mit Hilfe verschiedener Konvertierungsprogramme ActiveX-Dokumente für die
Benutzerschnittstelle und die Geschäftslogik. Das endgültige System ist eine webbasierte Thick-Web-Client-Anwendung für
Patienten und Patientenakten mit einer integrierten Webanwendung für Abrechnungsoperationen, die auf der Architektur
Bereitstellung im Internet basiert.
Die Hauptunterschied zwischen dem Webarchitekturmuster Bereitstellung im Internet und anderen Architekturmustern für
Webanwendungen ist die Kommunikationsmethode zwischen Client und Server. In den anderen Mustern ist der
Hauptmechanismus HTTP, ein verbindungsunabhängiges Protokoll, das den Designer erheblich einschränkt, was die
interaktiven Aktivitäten zwischen Benutzer und Server anbelangt. Die für die Architektur relevanten Elemente im Muster
Bereitstellung im Internet sind alle die Elemente, die im Muster Thin Web-Client angegeben, und zusätzlich die
folgenden:
DCOM - Distributed COM ist das Microsoft-Protokoll für verteilte Objekte. Mit diesem Protokoll können
Objekte auf einer Maschine mit Methoden für Objekten auf anderen Maschinen interagieren.
IIOP - Internet Inter-ORB Protocol ist das CORBA-Protokoll von OMG für die Interaktion mit verteilten
Objekten im Internet (oder in jedem TCP/IP-basierten Netz).
RMI (JRMP) - Remote Method Invocation ist die Java-Methode für die Interaktion mit Objekten auf anderen
Maschinen. JRMP (Java Remote Method Protocol) ist das native Protokoll für RMI, aber nicht das einzige
Protokoll, das verwendet werden kann. RMI kann mit dem IIOP von CORBA implementiert werden.
Die folgende Abbildung zeigt ein Diagramm der logischen Sicht auf das Architekturmuster Bereitstellung im Internet.
Logische Sicht auf das Architekturmuster Bereitstellung im Internet
Die grundsätzliche Dynamik des Architekturmusters Bereitstellung im Internet liegt in der Verwendung des Browsers als
Bereitstellungsmechanismus für ein verteiltes Objektsystem. Der Browser enthält eine Benutzerschnittstelle und
verschiedene Geschäftsobjekte, die unabhängig vom Browser mit Objekten auf der Serverschicht kommunizieren. Die
Kommunikation zwischen Client- und Serverobjekten erfolgt über die Protokolle IIOP, RMI oder DCOM.
Die Verwendung eines Web-Browsers in diesem ansonsten verteilten Client/Server-System hat den Vorteil, dass der Browser
über integrierte Funktionen verfügt, mit denen die erforderlichen Komponenten vom Server heruntergeladen werden können.
Ein brandneuer Computer im Netz muss lediglich einen kompatiblen Web-Browser installiert haben, um die Anwendung
verwenden zu können. Auf dem Client muss keine spezielle Software manuell installiert werden, da der Browser diese
Aufgabe für den Benutzer übernimmt. Komponenten werden nur bei Bedarf auf den Client heruntergeladen und installiert.
Java-Applets und ActiveX-Steuerelemente können automatisch an den Client gesendet und dort zwischengespeichert werden.
Wenn diese Komponenten aktiviert werden (z. B. wenn die entsprechende Webseite geladen wird), können sie die asynchrone
Kommunikation mit Serverobjekten übernehmen.
Die bei weitem größte Auswirkung dieses Musters ist die Portierbarkeit auf andere Browser-Implementierungen. Die
Verwendung dieses Musters setzt ein solides Netzwerk voraus. Verbindungen zwischen Client- und Serverobjekten dauern
viel länger als HTTP-Verbindungen. Zeitweilige Verbindungsunterbrechungen zum Server, die bei den anderen beiden
Architekturen kein Problem sind, stellen dieses Muster vor ein schwerwiegendes Problem.
|