ASP-Komponentenrichtlinien

  • Artikel

Veröffentlicht: 08. Nov 2001 | Aktualisiert: 08. Nov 2004

Von J.D. Meier

In diesem Artikel biete ich Ihnen einige allgemeine Richtlinien, die auf Erfahrungswerten basieren und die dazu beitragen, dass Sie bessere komponentenbasierte ASP-Lösungen erstellen.

Auf dieser Seite

 Einführung
  Sinn und Zweck der Verwendung von Komponenten
  Statusverwaltung
 Bereich
 Partitionseinteilungsdienste
 Threadingmodelle
 Sicherheit
 "Server.CreateObject" oder "CreateObject"?
 Übergeben von Parametern
 Ereignisse
 "OnStartPage/OnEndPage" oder "ObjectContext"?
 Fehlerbehandlung
 Globale Variablen
 Komponentenverteilung
 Schlussfolgerung

Wenn Sie die hier genannten Entwicklertasks ausführen, ist dieser Artikel für Sie interessant:

  • Sie rufen Komponenten über ASP-Code auf (ASP steht für Active Server Pages)

  • Sie entwerfen Komponenten, die über ASP-Code aufgerufen werden

  • Sie möchten über ASP-Code mit Komponenten arbeiten

Einführung

Komponenten... Einige lieben sie, andere fürchten sie. Diejenigen, die Komponenten fürchten, können Ihnen meist eine Horrorgeschichte erzählen, die sie mit Komponenten erlebt haben. Lassen Sie es uns doch so sagen: Wenn Sie mit Komponenten unter ASP arbeiten sollen, kann sich alles, was Sie nicht beachten oder wissen, negativ für Sie auswirken. Sollten Sie in eine solche Falle geraten, rappeln Sie sich wieder auf, sammeln Sie Ihren Mut, und lesen Sie weiter.

 

Sinn und Zweck der Verwendung von Komponenten

Bevor ich mit der Beschreibung der Komponentenrichtlinien beginne, ist es sicherlich gut zu wissen, welchen Nutzwert Komponenten für ASP-Anwendungen haben. Viele Entwickler, die noch nicht mit der Komponentenstrategie vertraut sind, wundern sich vielleicht, warum soviel Aufhebens um Komponenten gemacht wird. Das hat folgenden Grund, wie Sie an den Vorteilen für Ihre ASP-Anwendung sehen werden:

  • Kapselung von Funktionalität und Ausblendung von Implementierungsdetails

  • Wiederverwendbarkeit (einschließlich der Wiederverwendung durch verschiedene Clientanwendungen)

  • Schutz von geistigem Eigentum

  • Skalierbarkeit (indem Sie Ihre Anwendung auf mehrere Computer verteilen können)

  • Konfigurations- und Weitergabeflexibilität

  • Leistung (besonders, wenn frühes Binden ein entscheidender Faktor ist)

  • Systemzugriff, z.B. auf Win32-API-Aufrufe oder andere, maschinenorientierte Features von Programmiersprachen

  • Starke Typisierung (Visual Basic Scripting Edition [VBScript] ist schwach typisiert, JScript ist auch nicht viel besser)

  • Trennung der Geschäftslogik von der Benutzeroberfläche bzw. Trennung der Arbeit des Webdesigners von der Arbeit des Webentwicklers

Diese Vorteile können kostspielig sein. Das Erstellen einer Komponentenlösung kann teurer sein, da der gesamte Entwicklungsprozess komplexer wird. Weitergabe und Fehlerbehandlung können u.U. auch sehr schwierig sein; dies sind realistische Faktoren. Lassen Sie sich jedoch nicht durch diese kurzfristigen Hindernisse von Ihrem langfristigen Investitionsvorhaben abbringen. Woher wissen Sie, ob die Kosten gerechtfertigt sind? Stellen Sie sich dazu die folgenden Fragen:

  • Wie sieht die vorhandene Codebasis aus?

  • Über welche Expertise verfügt das Entwicklungsteam?

  • Inwieweit können Sie die Hostserver steuern?

  • Welche Auswahl an Tools und Sprachen steht für die verschiedenen Tasks zur Verfügung?

  • Welche Interoperabilitätsprobleme liegen vor?

  • Gibt es Leistungs- und Skalierbarkeitsfaktoren?

  • Wie ist der Zeitrahmen für das Projekt?

  • Wer pflegt die Anwendung und leistet den zukünftigen Anwendungssupport? Kann ein Entwicklungsteam diese Aufgaben übernehmen?

Nachdem Sie die o.g. Fragen in Ihre Überlegungen einbezogen haben, sollten Sie Ihre Annahmen prüfen. Mit einem Prototyp können Sie schnell die Spreu vom Weizen trennen.

Jetzt, wo die Vorteile der Komponentennutzung deutlicher sind, können wir mit unserer Strategie fortfahren. Wenn Sie die u.g. Richtlinien einhalten, erhalten Sie den maximal möglichen Nutzen aus diesen Vorteilen. Betrachten Sie diese Richtlinien als Sprungbrett für eine Anwendungsentwicklung, die stabilere, höher skalierbarere und leistungsstärkere ASP-Komponentenanwendungen hervorbringt.

 

Statusverwaltung

Im Allgemeinen sollten Sie – wo anwendbar – statusfreie Komponenten und statusfreie ASP-Seiten verwenden. Komponenten sollten von einem Methodenaufruf zum nächsten keinen Status anfordern. Speichern Sie komplexe Status in einer Datenbank. Bei simplen Daten, die Sie über Seiten weiterleiten möchten, sollten Sie Cookies, das QueryString-Objekt oder ausgeblendete Formularfelder wieder verwenden.

Gründe

Die Serverressourcen sind beschränkt. Wenn Sie den Status in Ihren Komponenten beibehalten, bedeutet das, dass Sie wertvolle Ressourcen verbrauchen und Ihre Anwendung dabei Ressourcenkonflikt- und -gleichzeitigkeitsproblemen aussetzen. Mit statusfreien Komponenten können Sie diese Probleme vermeiden. Durch statusfreie Komponenten haben Sie außerdem mehr Optionen für die Weitergabe und bessere Möglichkeiten, Ressourcen über mehrere Clients gemeinsam nutzen zu können.

Häufige Fehler

Ein Fallstrick, über den Entwickler häufig stolpern, ist der Entwurf oder die Verwendung einer Komponente, die den Status beibehalten muss. Diese "Desktopmentalität" ist mit Vorsicht zu genießen. In der Regel sind es Entwickler aus dem Desktopbereich, die solche statusbehafteten Komponenten entwerfen.

Weitere Informationen

Durch die Vermeidung von ASP-Sitzungen wird die Leistung des Servers verbessert, da der Codepfad verkürzt und der Verbrauch von Serverressourcen reduziert wird. Wenn Sie keine ASP-Sitzungen verwenden, müssen Sie die Option Sitzungszustand aktivieren über den Internetdienste-Manager deaktivieren (Näheres in der Internet-Informationsdienste-Dokumentation). Sie können den Status auch seitenweise deaktivieren, indem Sie das folgende Tag in den ASP-Seiten verwenden, die keine Sitzung benötigen:

<%@ENABLESESSIONSTATE=False %>

Eine flexible Weitergabe ist ebenfalls sehr wichtig – besonders, wenn Sie Ihre Webanwendung in einer Serverfarm ausführen. Wenn Sie auf ASP-Sitzungen vertrauen, sind die Anforderungen eines bestimmten Benutzers an einen bestimmten Webserver gebunden, da der Sitzungsstatus serverspezifisch ist. Dadurch, dass Sie einen Status in Ihrer Middle-tier und dem Webserver vermeiden und eine Datenbank verwenden, können Ihre ASP-Anforderungen von jedem der verfügbaren Webserver in der Farm verarbeitet werden. Sie minimieren daher Konflikte, bieten eine bessere Redundanz und ermöglichen mehr Verteilungsoptionen.

Alternativen zur Übergabe von Daten über Seiten ohne Verwendung von ASP-Sitzungen finden Sie in den folgenden Artikeln der Knowledge Base (KB):

Weitere Einblicke in die Statusverwaltung im Hinblick auf MTS erhalten Sie in Don Box' Artikel "ActiveX Q&A" (in Englisch).

 

Bereich

Im Allgemeinen sollten Sie Ihre Komponenten im Seitenbereich verwenden. "Seitenbereich" bedeutet, dass Sie ein Objekt auf ein und derselben Seite erstellen, verwenden und freigeben.

Komponenten mit der Kennzeichnung Beide bzw. Apartment funktionieren gut innerhalb des Seitenbereichs. Verwenden Sie Komponenten, die das Apartment-Modell nutzen (z.B. Visual Basic-Komponenten), nur im Seitenbereich. Wenn Sie eine Komponente in einem Anwendungs- oder Sitzungsobjekt speichern müssen, empfehlen wir Ihnen die Option Beide. Sie können Komponenten mit der Kennzeichnung Beide sowohl im Sitzungs- als auch im Anwendungsbereich speichern; für Ihre Komponente muss allerdings Threadsicherheit garantiert sein.

Gründe

Durch die Verwendung von Komponenten im Seitenbereich können Serverressourcen freigegeben werden. Mit der Freigabe der Ressourcen werden Gleichzeitigkeitskonflikte minimiert. Außerdem können poolfähige Ressourcen gemeinsam von mehreren Clients genutzt werden. Darüber hinaus werden mit Komponenten im Seitenbereich Threadingprobleme vermieden, denen Objekte im Sitzungs- oder Anwendungsbereich ausgesetzt sind. Die Threadingprobleme werden ausführlich unter dem nachfolgenden Abschnitt "Threadingmodelle" beschrieben.

Häufige Fehler

Eines der am häufigsten vorkommenden Probleme ist das Speichern von Visual Basic-Objekten oder anderen Apartment-Modellobjekten im Anwendungsbereich. Wenn Sie versuchen, ein mithilfe von Server.CreateObject erstelltes Objekt des Apartmentmodells innerhalb des Anwendungsbereichs zu speichern, tritt folgender Fehler auf:

Anwendungsobjektfehler 'ASP 0197: 80004005' 
  Unzulässige Objektverwendung 
  /VirDir/global.asa, line 7 
  Ein Objekt, das sich dem Apartmentmodell entsprechend verhält, kann nicht zum Anwendungsobjekt hinzugefügt werden.

Wenn Sie jedoch das <OBJECT>-Tag zum Speichern eines Objekts des Apartmentmodells im Anwendungsbereich verwenden, erhalten Sie keinen Laufzeitfehler. Stattdessen wird das Objekt in einem besonderen STA-Thread (STA = Singlethread-Apartment) erstellt, und alle Aufrufe werden an diesen Thread gemarshallt – und serialisiert. Der Grund liegt darin, dass das Threadingmodell der Komponente nicht geprüft wird. Unglücklicherweise tritt der Fehler dann während der Laufzeit auf.

Ein weiteres gängiges Problem ist das Speichern von Objekten, die das Apartmentmodell verwenden, im Sitzungsbereich. Dadurch wird die Sitzung des Benutzers an einen bestimmten Thread gebunden. Dieses Verhalten kann die Serverleistung nachhaltig beeinträchtigen. Im Kern eliminiert es den Zweck eines Threadpools, da alle Aufrufe an den Thread serialisiert werden, durch den das Objekt erstellt wurde.

Weitere Informationen

Weitere Informationen finden Sie in den folgenden KB-Artikeln:

 

Partitionseinteilungsdienste

Empfehlungen

Trennen Sie die Darstellungs-, Geschäfts- und Datendienste voneinander. Ihre Geschäftskomponenten sollten Geschäftsregeln durchsetzen. In den Geschäftskomponenten darf die Datenzugriffstechnologie nicht eingebunden sein. Das ist Aufgabe der Komponenten der Datenebene. Ihre Geschäftskomponenten dürfen keine Verweise auf ASP-Objekte enthalten.

ASP bieten Darstellungsdienste. Objekte, die auf ASP verweisen, sollten HTML darstellen können. Diese Objekte könnten wiederum Geschäftskomponenten aufrufen, die mit MTS/COM+ registriert wurden.

Gründe

Durch das Einteilen Ihrer Anwendung in getrennte und klar abgegrenzte Dienstpartitionen können Sie von den folgenden Vorteilen profitieren:

  • Bessere Komponentenwiederverwendung

  • Unterstützung des Windows DNA-Modells (in Englisch)

  • Bessere Isolation zur Fehlerbehandlung

  • Flexiblere Weitergabeoptionen (durch das Abkoppeln der Dienste können Sie Ihre Anwendung auf mehrere Computer verteilen)

Häufige Fehler

Eine übliche Fehlerquelle ist die Komponente, die wir als "Schweizer Armeemesser" bezeichnen. Wie bei einem Schweizer Armeemesser mit seinem Korkenzieher, seinem Zahnstocher und seinen anderen 17 Werkzeugen sind bei dieser Komponente alle Dienste in einem Objekt zusammengefasst. Das Gruppieren nichtverwandter Dienste in einer Komponente macht diese Komponente schwierig zu handhaben, zu verstehen und zu pflegen.

Eine weitere Falle, in die Sie leicht geraten können, ist der Verweis auf ASP aus Ihren Geschäftskomponenten. Wenn Sie ASP mit der Geschäftslogik koppeln (indem Sie Request- oder Response-Objekte verwenden oder HTML darin einbauen), schränken Sie sowohl die Wiederverwendbarkeit Ihrer Komponenten durch unterschiedliche Clients als auch die horizontale Skalierbarkeit ein. Objekte, die auf integrierte ASP-Objekte verweisen, sollten in derselben Funktionsebene wie der Webserver angesiedelt sein. Idealerweise können Ihre Geschäftskomponenten auf mehrere Funktionsebenen verteilt werden, um dem Anspruch der horizontalen Skalierung gerecht zu werden. Stellen Sie die Darstellungsdienste entweder direkt im ASP-Skript zur Verfügung, oder erstellen Sie Komponenten zur HTML-Darstellung, die auf integrierte ASP-Objekte verweisen, und bewahren Sie diese Komponenten in der IIS-Funktionsebene auf.

Weitere Informationen

Erfolgreiche Entwurfsmuster können als Modelle dafür dienen, wie Sie gängige Geschäftsprobleme angehen. Sie können z.B. mit Mustern zur Behandlung von CRUD-Operationen (CRUD = Create Read Update Delete, Erstellen-Lesen-Aktualisieren-Löschen) die Anwendung einfacher in gesonderte logische Dienstpartitionen für die Darstellung, die Geschäftsregeln und den Datenzugriff einteilen.

Weitere Informationen sowie detailliertere Beispiele für Entwurfsmuster, auf denen Sie in Ihren eigenen Anwendungen aufbauen können, finden Sie in den folgenden Artikeln.

  • Scalable Design Patterns (in Englisch)

  • Simplify MTS Apps with a Design Pattern (in Englisch)

  • FMStocks Application: Start Here (in Englisch)

 

Threadingmodelle

Was hat Priorität? Die Wahl eines Bereichs für Ihre Komponente oder die Wahl eines Komponententhreadingmodells? Egal, welche Entscheidung Sie zuerst treffen: Sie müssen bedenken, dass Änderungen am Threadingmodell erforderlich sind, es sei denn, Sie bleiben im Seitenbereich bei Komponenten mit dem Modell Apartment bzw. Beide. (Wenn Sie in Visual Basic programmieren und nicht wissen, welches Threadingmodell Ihre Anwendung verwendet: Es ist immer Apartment.)

Wenn Ihre Objekte in einem Application- oder Session-Objekt gespeichert werden müssen, müssen Sie Komponenten verwenden, die mit Beide gekennzeichnet sind, und den Free-threaded Marshaller (FTM) aggregieren.

Verwenden Sie keine Singlethread-Komponenten, und vermeiden Sie die Verwendung von Freethread-Komponenten über ASP.

Anmerkung: Visual Basic kann Singlethread-Komponenten anlegen, wenn Sie nicht sorgfältig vorgehen. Stellen Sie sicher, dass Sie auf der Registerkarte Allgemein in den Projekteigenschaften die Option Threading-Modell auf Apartment Threaded setzen. Außerdem sollten Sie die Optionen Unbeaufsichtigte Ausführung und In Speicher erhalten aktivieren, die sich auf der gleichen Registerkarte befinden.

Gründe

Wenn Sie Visual Basic verwenden, ist dies kein Thema. In Visual Basic sind Sie auf das Apartmentmodell beschränkt. Ich sehe dies jedoch nicht als allzu große Einschränkung an, da auch Visual Basic-Apartmentmodellobjekte im Seitenbereich extrem gute Leistungen erzielen können. Die Beispielanwendung Fitch and Mathers Stock 2000 hat in Bezug auf Leistungsabstriche alle Bedenken aus dem Weg geräumt. Darüber hinaus beweisen viele aktive Sites, die mit ASP, SQL und Visual Basic erstellt wurden, täglich, dass Apartmentmodellkomponenten im Seitenbereich sowohl skalierbar als auch leistungsstark sind.

Wenn Sie den FTM an Ihrer mit Beide gekennzeichneten Komponente aggregieren, können Sie Aufrufe zwischen Threads herstellen, ohne Marshalling oder Threadschalter einsetzen zu müssen. Wenn eine mit Beide gekennzeichnete Komponente nicht den FTM aggregiert, behandelt ASP diese Komponente als Apartmentthread-Objekt – genau wie eine Visual Basic-Komponente. Beachten Sie Folgendes: Sollten Sie die Vorteile des Objektpooling in COM+ in Anspruch nehmen wollen, dürfen Sie den FTM nicht aggregieren. Richtlinien zum Objektpooling können Sie der Dokumentation zum Plattform-SDK entnehmen.

Singlethread- und Freethread-Komponenten werden unter dem Systemsicherheitskontext ausgeführt. Was noch viel schlimmer ist: Singlethread-Komponenten unterliegen Deadlocks.

Häufige Fehler

Der möglicherweise häufigste Fehler besteht in der Verwendung einer Komponente, die nicht für die Ausführung unter ASP konzipiert ist, z.B. eine Singlethread-Komponente. Die meisten Entwickler werden mit diesem Problem konfrontiert, wenn sie eine Desktopanwendung auf ASP portieren oder mit dem Steuerelement eines Drittanbieters arbeiten. Wenn Sie nicht genau wissen, welches Threadingmodell die Komponente verwendet, können Sie den Registrierungseintrag für die Komponente überprüfen (diese Methode bietet jedoch keine Garantie auf Richtigkeit).

Weitere Informationen

Die folgenden Artikel zu Threadingmodellen und ihrem Einfluss auf ASP sind besonders empfehlenswert:

Weitere Informationen zu Threadingproblemen finden Sie in den folgenden KB-Artikeln:

 

Sicherheit

Die Komponente darf keine Annahmen in Bezug auf den Benutzerkontext machen, in dem sie ausgeführt werden soll. Greifen Sie nicht auf benutzerspezifische Informationen zu (z.B. auf die Ressource HKEY_CURRENT_USER oder desktopspezifische Ressourcen), da diese für Ihre Komponente nicht zur Verfügung stehen. Ihre Anwendung darf keine Aktionen durchführen, die i.d.R. eine Interaktion über den Desktop erfordern (z.B. der Aufruf von Dialogfeldern, die Verwendung von SendKeys oder der Aufruf von Komponenten, die über eine Benutzeroberfläche verfügen).

Gründe

Ihre Komponente wird unter einem anderen, geschützten Desktop ausgeführt. Dies bringt zunächst mit sich, dass Ihre Anwendung keine Dialogfelder aufrufen kann und nicht mit anderen Entitäten der grafischen Benutzeroberfläche in Dialog tritt (z.B. über SendKeys). Standardmäßig darf Inetinfo.exe nicht mit dem Desktop kommunizieren. Der andere Benutzerkontext verhindert außerdem, dass Ihre Komponente auf bestimmte Ressourcen zugreift. Vorwiegend ist damit der HKEY_CURRENT_USER-Abschnitt der Registrierung gemeint.

Häufige Fehler

Häufig ist es falsch, auf Schlüssel unter HKEY_CURRENT_USER zu verweisen. Die Visual Basic-Funktionen GetSetting und SaveSetting schlagen z.B. unter ASP fehl, weil sie auf Schlüssel unter der HKEY_CURRENT_USER-Struktur zugreifen. Im folgenden KB-Artikel wird dieses Verhalten erörtert:

Druckereinrichtungen, MAPI-Informationen und Netzwerkfreigaben gehen i.d.R. "verloren", wenn eine Komponente statt über einen Desktopclient über eine ASP aufgerufen wird.

Weitere Informationen finden Sie in den folgenden KB-Artikeln:

Weitere Informationen

Es gibt mehrere Sicherheitsaspekte, die berücksichtigt werden sollten:

  • Welche Authentifizierungsmethoden sind in IIS aktiviert?

  • Erstellen Sie eine In-Process- oder eine Out-Of-Process-Webanwendung?

  • Wenn Ihre Komponente mit MTS oder COM+ registriert wird: Befindet sie sich in einem Server- oder in einem Bibliothekspaket?

  • Rufen Sie eine lokale DLL, eine Remote-DLL, eine lokale EXE oder eine Remote-EXE auf?

Eine ausführliche Erläuterung der Sicherheitsaspekte würde den Rahmen dieses Artikels sprengen. Angesichts der Komplexität dieser Thematik empfiehlt es sich jedoch, die folgenden Artikel als Einstiegspunkte für eine Vertiefung zu verwenden. Sie beschäftigen sich mit den Problemen "aus der Sicht" der ASP-Komponenten.

Im folgenden Artikel finden Sie einen ausgezeichneten Überblick über die Angriffspunkte der Sicherheit in IIS:

 

"Server.CreateObject" oder "CreateObject"?

Verwenden Sie Server.CreateObject. Wenn Sie MTS/COM+-Bibliothekspakete verwenden, sollten Sie Server.CreateObject verwenden, um das Sperren von Threads zu vermeiden.

Gründe

CreateObject entspricht dem Aufruf von CoCreateInstance über das Skriptmodul. Wenn Sie CreateObject anstelle von Server.CreateObject verwenden, passiert Folgendes:

  • ASP erkennt das Objekt nicht mehr.

  • Die Seitenmethoden OnStartPage bzw. OnEndPage werden nicht aufgerufen.

  • ASP kennt das Threadingmodell des Objekts nicht.

Server.CreateObject entspricht dem Aufruf von GetObjectContext.CreateInstance. Das bedeutet, dass ASP das Objekt erkennt und weiß, welches Threadingmodell es verwendet. Zudem wird die Komponente durch den Aufruf von Server.CreateObject in die gleiche Transaktion wie die ASP-Seite eingetragen, sofern Ihre ASP-Seite Transaktionen unterstützt. (Beachten Sie hierbei bitte lediglich, dass eine transaktionsunterstützende Seite eine vermeidbare Kopplung von Geschäftsregeln und der Darstellungsschicht mit sich bringt.)

Häufige Fehler

Wenn ein Objekt hinter einem Firewall positioniert ist, müssen Sie u.U. CreateObject aufrufen. Weitere Informationen finden Sie unter "Q193230 PRB: Server.CreateObject Fails when Object is Behind Firewall (in Englisch)".

Weitere Informationen

Während unter IIS 4.0 CreateObject schneller ist als Server.CreateObject, gibt es unter IIS 5.0 keine Leistungsunterschiede. Wenn Sie MTS/COM+-Bibliothekspakete oder -Anwendungen verwenden, verhindert Server.CreateObject außerdem ein Sperren der Threads.

 

Übergeben von Parametern

Deklarieren Sie Out-Parameter als Variant-Datentypen. In Visual Basic heißt das, dass By Reference-Parameter den Variant-Datentyp haben sollten. Parameter, die By Value (nach Wert) (In-Parameter) übergeben werden, sind nicht auf den Variant-Datentyp beschränkt, müssen aber kompatibel mit Variant sein.

Gründe

Skriptclients "verstehen" Variant. Von COM-Servern können spezifische Datentypen verstanden werden. Wenn Sie spezifische Datentypen By Value an den COM-Server übergeben, kann der COM-Server diese ohne Probleme empfangen. Aber sofern es sich nicht um einen Variant-Datentyp handelt, schlägt ein By Reference-Argument fehl und kann nicht mehr an das ASP-Skript "zurückgesendet" werden.

Häufige Fehler

Unter den Fehlern kommen immer häufiger Nichtübereinstimmungen von Typen vor. Dies liegt i.d.R. daran, dass eine Variable By Reference (nach Verweis) an ein COM-Objekt übergeben wird und dabei einen anderen als den Variant-Datentyp hat. Eine gängige Problemkorrektur besteht darin, die Parameter By Value zu übergeben oder den Parameter in einen Variant zu ändern.

Weitere Informationen

Wenn Sie Ihre Komponenten computerübergreifend verteilen oder out-of-process ausführen, erleben Sie evtl. einige bedeutsame Leistungssteigerungen, wenn Sie Parameter By Value übergeben. Die Übergabe By Reference würde zu einem erhöhten, prozess- bzw. computerübergreifendem Overhead beim Marshalling führen, da die Daten hin und her gesendet werden müssten. Auch die Richtigkeit und Effizienz der Daten wird positiv beinflusst, wenn Sie Parameter By Value anstatt unnötigerweise By Reference übergeben.
Anmerkung: In Visual Basic werden Parameter standardmäßig By Reference übergeben.

Weitere Informationen zur Übergabe von Parametern an COM-Objekte über ASP finden Sie in den folgenden KB-Artikeln:

 

Ereignisse

Vermeiden Sie es, Komponenten aufzurufen, die auf die Rückgabe von Ereignissen durch andere Komponenten warten.

Komponentenmethoden sollten die Ausführungssteuerung so bald wie möglich an ASP zurückgeben. Greifen Sie u.U. auf MSMQ oder COM+ Queued Components zurück, um asynchrone Aufrufe bereitzustellen. Diese können auch nützlich sein, wenn die zu erledigenden Operationen lange für die Ausführung benötigen und nicht notwendigerweise online durchgeführt werden müssen.

Wenn Sie in ASP nicht so lange warten möchten, bis ein ausführungsintensiver Prozess abgeschlossen ist, können Sie den Arbeitsaufwand asynchron verteilen. Sie geben dann über ASP eine Antwort an den Client zurück. Sobald der Arbeitsaufwand abgeschlossen ist, können Sie den Client per E-Mail oder auf andere Weise benachrichtigen (siehe unten).

Gründe

ASP kann keine Ereignisse bearbeiten. Geben Sie die Antworten auf Ihre HTTP-Anforderungen so schnell wie möglich zurück, um eine optimale Serverleistung zu erzielen.

Häufige Fehler

Die Ausführung einer Serverschleife zum Überprüfen des Statusflags ist keine für den Server geeignete Methode, um Browserbenachrichtigungen bereitzustellen.

Weitere Informationen

Entwickler verwenden häufig Ereignisse, weil sie den Browser über die Arbeit benachrichtigen möchten, die auf dem Server verarbeitet wird. Sie können zwar ein ausgeklügeltes Browserbenachrichtungssystem entwickeln, z.B. das Ansprechen eines anderen Anschlusses auf dem Server über Sockets; viele Entwickler bevorzugen aber andere Techniken, um Benachrichtigungen abzuwickeln. Beispiele:

  • Verwenden von E-Mail-Benachrichtigungen.

  • Hinzufügen eines

    <meta http-equiv="refresh">

    \-Tags zur Seite, um den Server abzurufen.

  • Senden einer Verknüpfung an der Browser und manuelle Überprüfung des Status einer ausstehenden Anforderung auf dem Client.

Weitere Informationen finden Sie in den folgenden KB-Artikeln:

 

"OnStartPage/OnEndPage" oder "ObjectContext"?

Verwenden Sie in IIS 4.0 und höher ObjectContext, um auf integrierte ASP-Objekte zuzugreifen (d.h. Response, Request, Server usw.). Vermeiden Sie die Verwendung des ScriptingContext-Objekts und der Methoden OnStartPage sowie OnEndPage, wann immer es geht.

Gründe

OnStartPage, OnEndPage und das ScriptingContext-Objekt wurden zur Legacyunterstützung bereitgestellt.

Häufige Fehler

Der ATL-Assistent verwendet OnStartPage und OnEndPage, wenn Sie ein ASP-Objekt einfügen.

Weitere Informationen

Sie erhalten ObjectContext mit den Komponenten der Threadingmodelle Beide bzw. Apartment, ohne diese mit MTS/COM+ registrieren zu müssen. Für lokale ActiveX-EXE-Dateien können Sie ObjectContext nicht verwenden, so dass Sie also OnStartPage und OnEndPage verwenden müssen. Wenn Sie Kontext für Freethread- und Singlethread-Komponenten verwenden möchten, müssen Sie diese Komponenten mit MTS/COM+ registrieren. Andernfalls müssen Sie OnStartPage verwenden.

 

Fehlerbehandlung

Ihr Fehlerhandler sollte vom Schlimmstmöglichen ausgehen. Zeichnen Sie Fehler in allen Teilen Ihrer Anwendung auf, und protokollieren Sie sie so vollständig wie möglich. Gute Protokolle sind unverzichtbar für die Ablaufverfolgung, Isolation und Fehlerbehandlung in anormalen und evtl. sporadischen Situationen. Diese Protokolle können als Textdateien oder durch Schreibvorgänge in das NT-Ereignisprotokoll implementiert werden. In den meisten Fällen können Sie die Fehlerereignisse "wie Blasen aufsteigen" lassen, während Sie Informationen hinzufügen. Dies ist eine effektive Möglichkeit, den Aufrufer darauf hinzuweisen, dass ein Fehler auftrat. Dieser Blaseneffekt bietet dem Aufrufer die Chance, in gezielter Weise auf spezifische Fehler zu reagieren.

Beim Aufzeichnen der Fehler ist es wichtig, so viele nützliche Informationen wie möglich bereitzustellen. Nehmen Sie Folgendes auf jeden Fall auf:

  • Den aktuellen Benutzerkontext (rufen Sie die Win32-API auf – per GetUserName)

  • Die ID des aktuellen Threads (rufen Sie die Win32-API auf – per GetCurrentThreadId bzw. App.ThreadId in Visual Basic)

  • Die aktuelle Uhrzeit (rufen Sie mit der Win32-GetTickCount-API die Millisekunden ab)

  • Die Argumente, die an die Methode übergeben wurden

  • Die Fehlerquelle und den Methodennamen

Gründe

Die Erfahrung zeigt, dass eine gute Fehlerbehandlung und -protokollierung das effektivste Verfahren ist, um Probleme zur Laufzeit zu isolieren und diagnostizieren.

Häufige Fehler

Erinnern Sie sich an den Fehler ASP 0115? Hoffentlich arbeiten Sie nicht gerade an seiner Beseitigung. Falls doch, schlage ich vor, Sie lesen "Troubleshooting with the IIS Exception Monitor (in Englisch)".

Der Fehler ASP 0115 ("Abfangbarer Fehler in einem externen Objekt.") konnte nicht immer vom Entwickler behoben werden – aber in vielen Fällen hätte das Auftreten dieses Fehlers durch eine Fehlerbehandlung verhindert werden können. Außerdem hätte die Fehlerbehandlung auch nach dem Auftreten des Fehlers noch zur Behebung beigetragen.

Mit einem Wort, der größte Fehler, den Entwickler machen können, ist, die Fehlerbehandlung völlig zu übergehen oder es zu versäumen, wertvolle Diagnoseinformationen aufzunehmen.

In COM ist es schlechter Stil, Ausnahmen komponentengrenzenüberschreitend zu verbreiten. Zeichnen Sie Ausnahmen auf, aber geben Sie HResults zurück, um dem Aufrufer den Fehler mitzuteilen.

Weitere Informationen

Die folgenden Artikel enthalten praktische Beispiele zu einer effektiven Fehlerbehandlung:

  • Bulletproofing Your ASP Components (in Englisch), von Charles Alexander

  • Fitch & Mather Stocks: Web Application Design (in Englisch)

 

Globale Variablen

Empfehlungen

Vermeiden Sie globale Variablen in Ihren Komponenten. In Visual Basic bedeutet das, dass Sie keine Public- oder Global-Variablen in Standard-BAS-Modulen deklarieren dürfen.

Gründe

Globale Variablen sind nicht wirklich global. Jeder Thread hat seine eigene Kopie. Falls Methoden zufällig im selben Thread ausgeführt werden, sehen sie dieselben Variablen; andererseits greifen sie auf unterschiedliche Kopien dieser Variablen zu. Im Klartext heißt das: Sie schreiben u.U. einen Wert in eine globale Variable (und befinden sich in Thread A), aber ein anderer Benutzer (der sich in Thread B befindet) kann diesen Wert niemals sehen.

Dies kommt daher, dass Visual Basic intern den TLS (threadlokalen Speicher) verwendet, um auf globale Variablen zu verweisen. Das heißt, dass jeder Thread seine eigene Kopie von Public-Variablen besitzt und dass die globalen Daten nicht wirklich "global" sind, da es mehrere Kopien davon gibt. Es heißt auch, dass Benutzer, die sich zufällig auf demselben Thread befinden, Zugriff auf dieselben Variablen haben – ob sie möchten oder nicht.

Häufige Fehler

Die Verwendung von Public-Variablen in einem Standard-BAS-Modul kann zu einer Beschädigung von Daten führen, wenn die verschiedenen Threads verschiedene Benutzeranforderungen bedienen, die dieselben Daten noch einmal erwarten.

Weitere Informationen

Die folgenden Artikel von Matt Curland in der Ausgabe vom Juni 99 des Visual Basic Programmer's Journal (in Englisch) müssen Sie unbedingt gelesen haben:

  • Black Belt Programming - Create Worker Threads in DLLs

  • COMponent Builder - Create Efficient Multithreaded Apps

Darüber hinaus bietet der folgende Artikel von Daniel Appleman einen interessanten Überblick über die Funktionsweise von Multithreading in Visual Basic: A Thread to Visual Basic (in Englisch)

 

Komponentenverteilung

Die Komponentenverteilung hat Leistungs-, Skalierbarkeits- und Sicherheitsprobleme zur Folge. Unterschiedliche Verteilungen der gleichen Komponenten können zu Konfigurationen führen, die leistungsfähiger, skalierbarer oder einfacher zu verwalten sind.

Die folgenden Richtlinien haben sich bei der Verteilung von Komponenten auf mehrere Computer bewährt und zu einer Steigerung der Leistung und Skalierbarkeit geführt:

  • Führen Sie Komponenten aus, die auf integrierte ASP-Objekte in der gleichen Funktionsebene wie IIS verweisen.

  • Führen Sie die Datenbankkomponente(n) auf dem Anwendungsserver aus.

  • Führen Sie die Geschäftskomponenten auf den Computern aus, die Ihnen am sinnvollsten erscheinen. Vorausgesetzt, dass Sie Ihre Geschäftskomponenten von allen ASP abgekoppelt haben, sollten Sie diese Entscheidungen eigentlich allein basierend auf dem Anwendungsentwurf, der Computerverfügbarkeit und der Testumgebung treffen können.

Natürlich gibt es auch hier Ausnahmen. Aber diese Richtlinien sind gute Einstiegspunkte.

Gründe

Durch das Verteilen von Komponenten auf Computer können Sie die Skalierbarkeitsanforderungen Ihrer Anwendung erfüllen. Indem Sie den o.g. Richtlinien folgen, machen Sie es sich leichter, die für Ihre Anwendung gesetzten Ziele in Bezug auf Leistung und Skalierbarkeit zu erreichen.

Objekte, die auf integrierte ASP-Objekte verweisen, kommunizieren viel mit Ihrem Webserver. Da sie Teil der Darstellungsschicht sind, gehören sie deshalb auch auf den Server.

Datenbanklogik oder extrem datenintensive Logik gehört möglicherweise in gespeicherte Prozeduren Ihrer Datenbank. Wenn Sie Ihre Datenzugriffskomponente auf dem Anwendungsserver und nicht in der Datenbank platzieren, vermeiden Sie teure DCOM-Aufrufe zwischen den Komponenten. Stattdessen kommuniziert Ihre Datenzugriffskomponente auf effizientere Weise mit der Datenbank, z.B. unter Verwendung von SQL Server-Kommunikationsprotokollen wie TCP/IP.

Häufige Fehler

Die folgende Aufstellung enthält einige Fehler, die Sie vermeiden können:

  • Verfolgen des Ziels der vertikalen Skalierbarkeit Ihrer Computer, wenn die horizontale Skalierbarkeit geeigneter ist

  • Übersehen von Firewallüberlegungen (Tun Sie sich einen Gefallen. Wenn es einen Firewall zwischen den Computern der Produktionsumgebung gibt, fügen Sie für die Testfälle einen Firewall hinzu.)

  • Platzieren von Komponenten, die auf integrierte ASP-Objekte verweisen, auf einem anderen als dem IIS-Servercomputer (Rückrufe und Marshalling der integrierten ASP-Objekte ist teuer.)

  • Verwenden von spätem Binden in den Komponenten (Führt zu einem zusätzlichen Aufruf von GetIdsOfNames, was bei einer verteilten Anwendung teuer sein kann. Verwenden Sie frühes Binden, wo möglich.)

  • Übergeben von Parametern By Reference (Erstellt weiteren Marshallingoverhead. Übergeben Sie Parameter By Value, wo möglich.)

Der erfolgreiche Aufruf von MTS-Komponenten aus IIS kann ebenfalls sehr heikel sein. Eine einfache und doch effektive Lösung, wie sowohl die Leistung als auch die Sicherheit verbessert werden kann, besteht darin, ein temporäres MTS/COM+-Paket (bzw. eine temporäre MTS/COM+-Anwendung) aufzurufen. Durch frühes Binden werden Netzwerkhops reduziert, was somit die Leistung verbessert. Wenn Sie ein Serverpaket (bzw. eine Serveranwendung) verwenden, können Sie eine Identität einstellen, unter der das Paket bzw. die Anwendung ausgeführt werden soll. Diese Technik wird ausführlich im KB-Artikel "Q159311 Instantiating Remote Components in Microsoft Transaction Server and Internet Information Server (in Englisch)" erläutert.

Weitere Informationen

Wenn Sie Ihre Dienste abgekoppelt und, was noch wichtiger ist, die Geschäftskomponenten ohne ASP entworfen haben, sollte das Verteilen relativ flexibel funktionieren. Es sollte möglich sein, dass Sie Probleme mit besseren Mitteln einkreisen und Ihre Komponenten bei Bedarf verbreiten, um auftretende Skalierbarkeits- und Leistungsprobleme zu handhaben. Wie gelangen Sie an das probateste Mittel? Testen Sie es. Wie testen Sie? Dazu gibt es allgemeine Richtlinien:

  • Wenn Sie die Zuverlässigkeit einer Webserverfarm testen möchten, nehmen Sie Computer aus der Umgebung heraus, und prüfen Sie deren Fehleranfälligkeit.

  • Wenn Sie die Leistung testen möchten, bringen Sie in Erfahrung, wie viele ASP-Anforderungen pro Sekunde bedient werden können.

  • Wenn Sie die Skalierbarkeit testen möchten, legen Sie anhand eines Limits fest, wie viele ASP-Anforderungen pro Sekunde bedient werden müssen. Bearbeiten Sie die Anwendung mit einem Belastungstool – es fügt solange Benutzer hinzu, bis die Leistung inakzeptabel wird.

  • Es ist unbedingt notwendig, dass Sie Ihre Anwendungen Belastungstests unterziehen, da Sie sehen müssen, wie sich Ihre Anwendung unter "Wettkampfbedingungen" verhält. Auch werden dabei Probleme sichtbar, die sich beim Testen in einer Browserumgebung nicht offenbaren.

Weitere Informationen zum Testen der Anwendungen unter Belastung finden Sie in dem Artikel "I Can't Stress It Enough -- Load Test Your ASP Application (in Englisch)".

 

Schlussfolgerung

Wie Sie sehen, gibt es eine Reihe von Dingen, die Sie im Verlauf der entsprechenden Entwicklungszyklen berücksichtigen müssen. Faktorisieren Sie so viele der hier dargestellten Anwendungsrichtlinien wie möglich im Voraus, denn sie können Sie vor kostspieligen Fehlern während der Entwicklung schützen. Indem Sie die wenigen in diesem Artikel beschriebenen Richtlinien einhalten, können Sie nicht nur verhindern, dass Sie u.U. alles noch einmal machen müssen, sondern auch sicherstellen, dass Sie skalierbare, zuverlässige und ASP-komponentenbasierte Hochleistungslösungen liefern.