Konzept: Web-Architekturmuster
Web-Architekturmuster stellen eine Anwendung oder einen Teil einer Anwendungsschnittstelle als allgemeine Muster dar, die wiederverwendbar sind.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Einführung

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.

Thin Web-Client

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.

Anwendbarkeit

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.

Bekannte Einsatzmöglichkeiten

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.

Struktur

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.

Abbildung ist im Inhalt beschrieben.

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.

Abbildung ist im Inhalt beschrieben.

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.

Dynamik

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.

Auswirkungen

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.

Thick Web-Client

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.

Anwendbarkeit

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.

Bekannte Einsatzmöglichkeiten

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.

Struktur

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.

Abbildung ist im Inhalt beschrieben.

Logische Sicht auf das Architekturmuster Thick Web-Client

Dynamik

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.

Auswirkungen

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.

Bereitstellung im Internet

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.

Anwendbarkeit

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.

Bekannte Einsatzmöglichkeiten

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.

Struktur

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.

Abbildung ist im Inhalt beschrieben.

Logische Sicht auf das Architekturmuster Bereitstellung im Internet

Dynamik

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.

Auswirkungen

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.