DE60211254T2

DE60211254T2 - Fernereignis Behandlung in ein Paketnetzwerk

Info

Publication number: DE60211254T2
Application number: DE60211254T
Authority: DE
Inventors: Scott D. Bellevue Guthrie; Dmitry Bellevue Robsman
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2001-06-29
Filing date: 2002-06-14
Publication date: 2006-09-14
Anticipated expiration: 2022-06-15
Also published as: PT1271883E; DE60211254D1; EP1271883A3; JP2003076560A; US7162723B2; US20030018827A1; JP4302942B2; DK1271883T3; EP1271883A2; EP1271883B1; ES2263707T3; ATE326106T1; US7603676B2; US20070174845A1

Description

HINTERGRUND DER ERFINDUNG
Ein Teil der Offenbarung dieser Patentschrift enthält Material, das einem Copyright-Schutz unterliegt. Der Copyright-Besitzer hat nichts einzuwenden gegenüber einer originalgetreuen Reproduktion der Patentschrift oder der Patentoffenbarung durch irgendjemanden, solange es in den Patentakten oder Aufzeichnungen des Patent- und Schutzrechtsamtes passiert, aber behält sich andernfalls alle möglichen Copyright-Rechte vor.
Gebiet der Erfindung
Die Erfindung bezieht sich auf die Bearbeitung von Hypertext-Transfer-Protocol-Anfragen (HTTP-Anfragen). Spezieller gesagt, bezieht sich die vorliegende Erfindung auf ein System und Verfahren zum Bearbeiten einer HTTP-Anfrage.
Hintergrund des Standes der Technik
2 zeigt ein funktionelles Blockdiagramm einer Webseitenanwendung, die eine HTTP-Anfrage in konventioneller Weise bearbeitet. Ein Webbrowser 201, der sich in einem Client Computer 202 befindet, sendet eine HTTP-Anfrage für eine ausgewählte URL 205 über ein Computernetzwerk 203, wie z.B. das Internet, in einer allgemein bekannten Weise zu einem Host Server Computer 204. Der Host Server Computer 204, auf dem eine Anwendung 206 läuft, die speziell für den Host Computer 204 ist, empfängt die HTTP-Anfrage, und greift auf den Inhalt der angefragten Webseite 205 basierend auf den Inhalten der Anfrage und der Bearbeitung durch die Anwendung 206 zu. Bevor die Antwort auf die HTTP-Anfrage zu dem Webbrowser 201 durch einen Webserver 207 gesendet wird, erzeugt die Anwendung 206 die angefragte Webseite 205 unter Verwendung einer Software, die auf dem Host Server Computer 204 läuft, und abhängig von dem Inhalt der Webseite 205 eines Web Services 208, wie z.B. einem Web Service Proxy.
Die Anwendung 206 kann die Anfrage auch in einer ausgewählten Art und Weise bearbeiten, bevor und/oder nachdem die Software, die auf dem Host Server Computer 204 läuft, die angefragte Seite durch Verwendung von Funktionsmodulen erzeugt hat, wobei die Funktionsmodule z.B. zum Authentifizieren des anfragenden Benutzers, zum Ermitteln, ob der anfragende Benutzer autorisiert ist, auf die angefragte Webseite zuzugreifen, zum Verschlüsseln der Antwort, etc sind. Die Funktionsmodule 209, wie z.B. JAVA Servlets, bearbeiten eine HTTP-Anfrage in einer sequentiellen Weise. D.h., dass das Funktionsmodul 209a ausgewählt wurde, um die Anfrage zu beantworten, bevor Funktionsmodul 209b die Anfrage bearbeitet, und das Funktionsmodul 209c wiederum ausgewählt ist, um die Anfrage nach dem Funktionsmodul 209b zu bearbeiten. Z.B. könnte Funktionsmodul 209a eine Benutzerauthentifizierung für die Anwendung 206 zur Verfügung stellen. Sobald sich der Benutzer authentifiziert hat, könnte das Funktionsmodul 209b Benutzerberechtigung zur Verfügung stellen. Anschließend könnte Funktionsmodul 209c eine Werbungsfunktionalität zur Verfügung stellen, die auf der authentifizierten Identifikation des anfragenden Benutzers basiert.
Wenn ein Entwickler für HTTP-Anwendungen die Funktionalität der Anwendung 206 durch Ändern der Funktionalität der Module 209 verändern muss, um kundenspezifische Merkmale einzubauen, so wie z.B. kundenspezifische Protokollierung, internetskalierte Sicherheit, oder Datenzwischenspeicherung, müsste der Entwickler das Funktionsmodul kundenspezifisch erzeugen und/oder ein passendes Funktionsmodul verwenden, das durch einen Dritten entwickelt worden ist.
Ein Problem dieser herkömmlichen Vorgehensweise ist, dass ein Anwendungsentwickler die Verarbeitung aller anderen Funktionsmodule vollständig verstanden haben muss, so dass ein neues Funktionsmodul nicht im Widerspruch zu den anderen bereits vorhandenen Funktionsmodulen steht. Weiter ist es für den Anwendungsentwickler schwierig, genau zu wissen, wo in der Bearbeitungsabfolge ein neues oder verbessertes Funktionsmodul einzufügen ist. Des Weiteren präsentiert ein Funktionsmodul in bestimmten Situationen einem anfragenden Benutzer Inhalt und/oder Headers, bevor die Software, die auf dem Host Server Computer 204 läuft, die angefragte Webseite erzeugt, so dass die Webseite bei dem Benutzer den Anschein macht, eine relativ schnelle Webseite zu sein. Irgendeine Anfragebearbeitung, die von einem Funktionsmodul ausgeführt wird, das später in der herkömmlichen Bearbeitungsabfolge steht, kann nicht mehr länger ausgeführt werden, weil der Inhalt und/oder die Headers nicht mehr länger zur Bearbeitung zur Verfügung stehen.
Was gebraucht wird, ist ein Weg für einen HTTP-Anwendungsentwickler, um einfach eine Funktionalität zu einer HTTP-Anwendung hinzuzufügen. Was zusätzlich gebraucht wird, ist ein Weg, um wiederverwendbare Funktionalität zwischen Anwendungen zu erzeugen, so dass HTTP-Module, die von verschiedenen Modulentwicklern entwickelt wurden, zusammen in vielen HTTP-Anwendungen coexistieren können. Was außerdem gebraucht wird, ist ein Verfahren zum Anbieten einer HTTP-Anfragebearbeitung, die eine sequenzielle Anordnung von Funktionsmodulen vermeidet, die möglicherweise im Widerspruch zu anderen Funktionsmodulen stehen.
EP 1 156 429 A2 ist ein nachveröffentlichtes Dokument, das die serverseitig zusammengehörige Erzeugung (cogeneration) aus einer Inhaltsdatei für dynamischen Webseiten beschreibt.
M. M. Moore et al., „Migrating legacy user interfaces to the internet: shifting dialogue initiative", IEEE, 23. November 2000, Seiten 52 bis 58 beschreibt einen modellorientierten Überarbeitungsprozess für Mensch-Computer Schnittstellentechnik und Hilfsmittelsatz, die entwickelt worden sind, um alte, Schriftzeichen-orientierte Anwendungen zu grafischen User Interfaces zu überarbeiten. Die Technik führt User Interface Überarbeitung in einer Serie von drei Schritten durch: Erfassen, Umformen und Erzeugen. Der Umformungsschritt dient zum Bilden von Kartierungen zwischen den User Interface Abstraktionen, die in altem Code ermittelt wurden, und deren vorgeschlagenem Ersatz aus einem speziellen GUI Werkzeugsatz. Der Erzeugungsschritt dient zum Austauschen des schriftzeichenorientierten Codes aus dem ursprünglichen System durch Implementierungen seiner Entsprechungen aus dem GUI Werkzeugsatz, die in dem Umformungsschritt vorgeschlagen wurden. Es wird beschrieben, dass ein ereignisorientiertes Programm aus einer Reihe von Ereignis-Handlern besteht, die durch Ereignisse aufgerufen werden, die in dem User Interface passieren.
KURZFASSUNG DER ERFINDUNG
Es ist die Aufgabe der Erfindung ein Laufzeitsystem zur Behandlung von HTTP-Anfragen und ein Verfahren zum Bearbeiten einer HTTP-Anfrage anzubieten, die es einem Entwickler für HTTP-Anwendungen ermöglichen, auf einfache Weise Funktionalität zu einer HTTP-Anwendung hinzuzufügen.
Diese Aufgabe wird durch die Erfindung, wie in den unabhängigen Ansprüchen beansprucht, gelöst.
Bevorzugte Ausführungsformen werden in den abhängigen Ansprüchen beschrieben.
Die vorliegende Erfindung stellt ein Verfahren für einen Entwickler von HTTP-Anwendungen zur Verfügung, um auf einfache Weise Funktionalität zu einer HTTP-Anwendung hinzuzufügen. Zusätzlich bietet die vorliegende Erfindung ein Verfahren zum Erzeugen von Funktionalität, die zwischen Anwendungen wiederverwendbar ist, so dass diese HTTP-Module, die von verschiedenen Modulentwicklern entwickelt wurden, zusammen in vielen HTTP-Anwendungen coexistieren können. Die vorliegende Erfindung bietet auch ein Verfahren, um die Bearbeitung einer HTTP-Anfrage zur Verfügung zu stellen, die eine sequenzielle Anordnung von Funktionsmodulen, die möglicherweise mit anderen Funktionsmodulen im Widerspruch stehen, zu vermeiden.
Um diese Vorteile umzusetzen, bietet die vorliegende Erfindung eine Laufzeitanwendung zur Beantwortung einer HTTP-Anfrage durch Darlegung einer objektorientierten, ereignisorientierten Infrastruktur, so dass HTTP-Anwendungen und HTTP-Module während verschiedener Stufen des Anfrage/Antwort Zyklusses beteiligt sein können. D.h. Verfahren sind für einen Rückruf registriert, wenn entweder ein synchrones oder ein asynchrones Anfrageereignis während der Lebensdauer einer HTTP-Anfrage eintritt.
Gemäß der Erfindung schließt eine Laufzeit zur Bearbeitung einer HTTP-Anfrage ein Kontextobjekt und eine Ereignispipeline ein. Das Kontextobjekt wird erzeugt durch analysieren einer HTTP-Anfrage, die bei einer Host Anwendung von einer Client Anwendung empfangen wurde, und die die HTTP-Anfrage logisch repräsentiert. Das Kontextobjekt verkapselt vorzugsweise die Eigenschaften zugehörig zu der empfangenen HTTP-Anfrage. Das Kontextobjekt wird durch die Ereignispipeline bearbeitet, welche eine Vielzahl von Anfrageereignissen einschließt. Die Pipeline bearbeitet eine HTTP-Anfrage nach der anderen, und wenn die Pipeline mit der Bearbeitung einer HTTP-Anfrage fertig ist, bearbeitet sie eine andere HTTP-Anfrage. Jedes Anfrageereignis hat ein entsprechendes Ereignis und erzeugt einen Rückruf, wenn das Ereignis entsprechend dem Anfrageereignis eintritt, und wenn mindestens eine Anwendung oder ein Modul zugehörig zu dem Anfrageereignis registriert ist. Jeder Rückruf instanziiert jedes Modul, das zugehörig zu dem Anfrageereignis zur Bearbeitung des Kontextobjekts registriert ist. Vor zugsweise schließt die Vielzahl von Anfrageereignissen Ereignisse ein, die entweder synchron und/oder asynchron in einer deterministischen Reihenfolge sind. Des Weiteren kann die Vielzahl von Anfrageereignissen mindestens ein Anfrageereignis einschließen, das eine nicht-deterministische Reihenfolge hat, so wie z.B. ein Fehlerereignis. Gemäß der Erfindung kann ein Modul mit einer Vielzahl von Anfrageereignissen registriert sein.
KURZE BESCHREIBUNG DER FIGUREN
Die vorliegende Erfindung wird als Beispiel und nicht Einschränkung in den beiliegenden Figuren erläutert, in welchen gleiche Bezugszeichen gleichartige Elemente angeben und in welchen:
1 ein schematisches Diagramm einer herkömmlichen, Allzweck-Umgebung zur digitalen Verarbeitung zeigt, die verwendet werden kann, um verschiedene Aspekte der vorliegenden Erfindung zu implementieren;
2 ein funktionelles Blockdiagramm einer Webseitenapplikation zeigt, die eine HTTP-Anfrage in herkömmlicher Weise bearbeitet; und
3 ein funktionelles Blockdiagramm einer Webseitenanwendung zeigt, die eine HTTP-Anfrage unter Verwendung einer ASP.NET HTTP-Laufzeit gemäß der vorliegenden Erfindung bearbeitet.
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
Die vorliegende Erfindung kann in Bezug auf die 1 und 3 leichter beschrieben werden. 1 stellt ein schematisches Diagramm einer herkömmlichen Allzweck-Umgebung zur digitalen Verarbeitung dar, die verwendet werden kann, um verschiedene Aspekte der vorliegenden Erfindung zu implementieren. In 1 schließt ein Computer 100 eine Prozessoreinheit 110, einen Systemspeicher 120, und einen Systembus 130 ein, der verschiedene Systemkomponenten koppelt, einschließlich dem Systemspeicher mit der Verarbeitungseinheit 110. Systembus 130 kann irgendeiner von verschiedenen Busstrukturtypen sein, einschließlich einem Speicherbus oder Speichercontroller, einem Peripheriebus und einem Lokalbus unter Verwendung irgendeiner aus einer Vielfalt von Busarchitekturen. Systemspeicher 120 schließt read only memory (ROM) 140 und random access memory (RAM) 150 ein.
Ein Basic Input/Output System 160 (BIOS), das die elementaren Routinen enthält, die helfen, Information zwischen Elementen innerhalb des Computers 100 zu transferieren, so wie z.B. während des Hochfahrens, ist im ROM 140 gespeichert. Der Computer 100 enthält auch ein Festplattenlaufwerk 170 zum Lesen von und Schreiben zu einer Festplatte (nicht gezeigt), ein magnetisches Disklaufwerk 180 zum Lesen von oder Schreiben zu einer entfernbaren magnetischen Disk 190, und ein optisches Disklaufwerk 191 zum Lesen von oder Schreiben zu einer entfernbaren optischen Disk 192, wie z.B. einer CD-ROM oder einem anderen optischen Medium. Das Festplattenlaufwerk 170, magnetische Disklaufwerk 180, und optische Disklaufwerk 191 sind mit dem Systembus 130 jeweils über eine Festplattenlaufwerksschnittstelle 192, eine magnetische Disklaufwerksschnittstelle 193, bzw. eine optische Disklaufwerksschnittstelle 194 verbunden. Die Laufwerke und ihre zugehörigen computerlesbaren Medien stellen nicht-flüchtigen Speicher für computerlesbare Instruktionen, Datenstrukturen, Programmmodule und andere Daten für Personalcomputer 100 zur Verfügung. Es wird durch Fachleute anerkannt, dass andere Typen von computerlesbaren Medien, die Daten speichern können, die durch einen Computer abrufbar sind, wie z.B. magnetischen Kassetten, Flash Memory Karten, digitalen Videodisks, Bernoulli Cartridges, Random Access Memorys (RAMs), Read Only Memorys (ROMs), und ähnlichem, ebenso in der beispielhaften Arbeitsumgebung verwendet werden können.
Etliche Programmmodule können auf dem Festplattenlaufwerk 170, der magnetischen Disk 190, der optischen Disk 192, dem ROM 140 oder RAM 150 gespeichert werden, einschließlich einem Betriebssystem 195, einem oder mehreren Anwendungsprogrammen 196, anderen Programmmodulen 197, und Programmdaten 198. Ein Benutzer kann Kommandos und Informationen in den Computer 100 durch Eingabegeräte, wie z.B. ein Keyboard 101 und Zeigergerät 102 eingeben. Andere Eingabegeräte (nicht gezeigt) schließen ein Mikrofon, Joystick, Gamepad, Satellitenschüssel, Scanner oder ähnliches ein. Diese und andere Eingabegeräte sind oft mit der Verarbeitungseinheit 110 durch eine serielle Portschnittstelle 106 verbunden, die mit dem Systembus gekoppelt ist, aber können auch durch andere Schnittstellen verbunden sein, wie z.B. einem Parallelport, Gameport oder Universal Serial Bus (USB). Des Weiteren können diese Geräte dennoch direkt mit dem Systembus 130 über eine geeignete Schnittstelle (nicht gezeigt) gekoppelt sein. Ein Monitor 107 oder anderer Typ von Anzeigegerät ist auch mit dem Systembus 130 über eine Schnittstelle verbunden, so wie z.B. einem Videoadapter 108. Zusätzlich zu dem Monitor, schließen Personalcomputer üblicherweise andere Peripherie-Ausgabe-Geräte (nicht gezeigt) ein, so wie z.B. Lautsprecher und Drucker.
Computer 100 kann in einer Netzwerkumgebung unter Verwendung von logischen Verbindungen zu einem oder mehreren Remote Computern arbeiten, so wie z.B. einem Remote Computer 109. Remote Computer 109 kann ein Server, ein Router, ein Netzwerk PC, ein Peer-Gerät oder anderer bekannter Netzwerkknoten sein, und schließt üblicherweise viele oder alle der oben in Bezug auf Computer 100 beschriebenen Elemente ein, obwohl nur ein Speichergerät 111 in 1 dargestellt ist. Die logischen Verbindungen, die in 1 gezeigt werden, schließen ein, Local Area Network (LAN) 112 und ein Wide Area Network (WAN) 113 ein. Solche Netzwerkumgebungen sind alltäglich in Büros, unternehmensweiten Computernetzwerken, Intranets und dem Internet.
Wenn er in einer LAN Netzwerkumgebung verwendet wird, ist der Computer 100 mit dem Local Area Network 112 durch eine Netzwerkschnittstelle oder -adapter 114 verbunden. Wenn er in einer WAN Netzwerkumgebung verwendet wird, enthält der Personalcomputer 100 üblicherweise ein Modem 115 oder anderes Gerät zum Herstellen einer Kommunikation über das Wide Area Network 113, wie z.B. dem Internet. Modem 115 welches intern oder extern sein kann, ist mit dem Systembus 130 über die serielle Portschnittstelle 106 verbunden. In einer Netzwerkumgebung können Programmmodule, die in Bezug auf Personalcomputer 100 gezeigt werden, oder Teile davon, in einem Remote Speichergerät gespeichert sein.
Es wird begrüßt, dass die gezeigten Netzwerkumgebungen exemplarisch sind und andere Techniken zum Herstellen einer Kommunikationsverbindung zwischen den Computern verwendet werden kann. Das Vorhandensein irgendeines von verschiedenen wohlbekannten Protokollen, so wie z.B. TCP/IP, Ethernet, FTP, HTTP- und ähnlichem, wird vorausgesetzt, und das System kann in einer Client-Server Konfiguration verwendet werden, um es einem Benutzer zu erlauben, Webseiten von einem webbasierten Server abzurufen. Es kann irgendeiner von verschiedenen herkömmlichen Webbrowsern verwendet werden, um Daten auf Webseiten anzuzeigen und zu manipulieren.
Ein primärer Aspekt der Erfindung bietet eine ereignisbasierte Anwendungslaufzeit zum Beantworten einer HTTP-Anfrage. Spezieller gesagt, bietet die ASP.NET HTTP-Laufzeit der vorliegenden Erfindung eine objektorientierte-ereignisorientierte Infrastruktur für Anwendungsentwickler, zum Erzeugen von erweiterten Anwendungen, die während verschiedener Stufen des Anfrage/Antwortzyklusses beteiligt sind. Z.B. ermöglicht die ASP.NET HTTP-Laufzeit der vorliegenden Erfindung es einem Anwendungsentwickler, eine HTTP-Anwendung zu entwickeln und/oder einem Modulentwickler ein wieder verwendbares HTTP-Modul zum Abfangen, Beteiligen und/oder Modifizieren jeder einzelnen HTTP-Anfrage, unter Verwendung von Anwendungen, die in irgendeiner der .NET Sprachen geschrieben sind, zu entwickeln. Um dies zu erreichen befähigt die vorliegende Erfindung einen HTTP-Anwendungsentwickler und/oder einen HTTP-Modulentwickler Methoden zu registrieren, die zu bestimmten Stufen während der Lebensdauer einer HTTP-Anfrage in einer Anwendung aufgerufen werden. Die Infrastruktur, in welcher Methoden registriert werden, ist der logische .NET Austausch für einen herkömmlichen Webserver Application Program Interface (API) Filter. Außerdem erlaubt die vorliegende Erfindung, dass die Funktionalität von ASP.NET verändert werden kann. Z.B., wenn ASP.NET nicht ausreichend Funktionalität in einem bestimmten Gebiet zur Verfügung stellt, kann ein Entwickler die zugrunde liegende Anwendungsinfrastruktur in einer Ebene ändern, die ehemals reserviert war für eine ausgewählte Gruppe von Entwicklern, die mehr Wissen über die zugrunde liegende Infrastruktur haben.
3 zeigt ein funktionelles Blockdiagramm einer Webseiten Anwendung, die eine HTTP-Anfrage unter Verwendung von ASP.NET HTTP-Laufzeit gemäß der vorliegenden Erfindung bearbeitet. Die Architektur der ASP.NET HTTP-Anfragebearbeitungslaufzeit bietet eine Anwendung, die ein HTTP-Kontextobjekt aus einer HTTP-Anfrage und eine Ereignispipeline erzeugt, die Rückrufe während der Lebensdauer des HTTP-Kontextobjekts (d.h. der Lebensdauer der HTTP-Anfrage) generiert. Das HTTP-Kontextobjekt stellt eine empfangene HTTP-Anfrage logisch dar, in dem alle der Eigenschaften, die mit der empfangenen HTTP-Anfrage assoziiert sind und die für die Bearbeitung der Anfrage notwendig sind, verkapselt werden. Die Rückrufe werden von HTTP-Anwendungen und HTTP-Modulen verwendet, die sich für Ereignisse registrieren, wenn die Module initiiert werden. Ein GLOBAL.ASAX wird nicht für die Registrierung von Ereignissen benötigt, weil das GLOBAL.ASAX Anwendungscode enthält, der "on the fly" kompiliert wird, der Ereignishandler für irgendein Pipelineereignis einschließt. Die Ereignishandler werden automatisch über Namenskonventionen eingehakt. Z.B., wenn An wendungscode (der in GLOBAL.ASAX oder vorkompiliert sein kann) eine Methode namens Application_BeginRequest enthält, wird der Anwendungscode automatisch an das BeginRequest Ereignis angeschlossen. Deshalb können Ereignisse entweder in Modulen oder Anwendungscode gehandhabt werden. Vorzugsweise werden Module verwendet, weil Module wieder verwendbar zwischen mehreren Anwendungen sind. Die vorliegende Erfindung generiert eine Instanziierung der Ereignispipeline zum Bearbeiten einer Vielzahl von HTTP-Anfragen, die empfangen werden.
Die Ereignispipeline stellt eine ereignisbasierte Architektur zur Verfügung, die eine Vielzahl von Anfrageereignissen zum Erzeugen eines Rückrufs einschließt, wenn das Anfrageereignis eintritt. Jedes HTTP-Modul, das mit einem oder mehreren Anfrageereignissen registriert ist, wird instanziiert, wenn die Pipeline instanziiert wurde. Deshalb kann ein Anwendungsentwickler eine Anwendung entwickeln, die eine Anfrage bei einem ausgewählten Ereignis während der Lebensdauer der Anfrage abfängt, mit beteiligt ist oder modifiziert. Ebenso kann ein HTTP-Modulentwickler ein HTTP-Modul entwickeln, das eine Anfrage bei einem ausgewählten Ereignis während der Lebensdauer der Anfrage abfängt, mit beteiligt ist oder modifiziert. Außerdem kann eine Anwendung die weitere Bearbeitung der Anfrage durch Aufrufen einer Response.End() Methode abbrechen, abhängig von dem Anfrageereignis, das eingetreten ist. Das zuletzt ausgeführte Ereignis ist immer ein EndRequest Ereignis, so dass ein Modul eine Aufräumfunktion ausführen kann.
Wieder Bezug nehmend auf 3, empfängt ein Host, auf welchem z.B. IIS (Internet Information Server) 5 oder IIS6 läuft, eine HTTP-Anfrage (nicht gezeigt in 3). die empfangene Anfrage wird an die ASP.NET Laufzeit der vorliegenden Erfindung weitergegeben, wo die Anfrage in einer gut bekannten Weise analysiert wird, um ein HTTP-Kontextobjekt zu erzeugen, das alle Eigenschaften verkapselt, die mit der empfangenen HTTP-Anfrage verbunden sind, die zum Bearbeiten der Anfrage gebraucht werden. Eine Anwendung wird instanziiert, und die Bearbeitung der Anfrage geht weiter „zu" dem HTTP-Handler durch die Ereignispipeline (dargestellt durch Anfrageereignisse 301 und 302). Während die Lebensdauer der Anfrage durch die Ereignispipeline fortschreitet, tritt jedes der deterministischen Anfrageereignisse ein. HTTP-Module, die mit einem bestimmten Anfrageereignis registriert sind, oder die Ereignissinks in der GLOBAL.ASAX enthalten, werden aufgerufen, wenn das bestimmte Anfrageereignis eintritt. Nachdem der HTTP-Handler die angefragte Webseite generiert hat, geht die Bearbeitung durch die Ereignispipeline weiter. Wenn alle Anfrageereignisse eingetreten sind, und alle HTTP-Module die Anfrage bearbeitet haben, antwortet der Host auf die Anfrage durch das Senden der angefragten (und bearbeiteten) Webseite.
Es sollte verstanden sein, dass während nur drei Anfrageereignisse 301, 302 und 303 und drei HTTP-Module 304, 304 und 306 in 3 gezeigt sind, weniger oder mehr Anfrageereignisse und weniger oder mehr HTTP-Module verwendet werden können. Es sollte verstanden sein, dass mehr als ein HTTP-Modul mit einem bestimmten Anfrageereignis registriert sein kann. 3 zeigt eine beispielhafte Registrierung der HTTP-Module 304 bis 306 mit den Anfrageereignissen 301 bis 303. Eine Linie, die sich zwischen einem HTTP-Modul und einem Anfrageereignis erstreckt, stellt eine Registrierung dar. In 3 sind drei beispielhafte HTTP-Module 304, 305 und 306 jeweils mit dem Anfrageereignis 302 registriert, so dass alle drei Module 304 bis 306 eine HTTP-Anfrage basierend auf demselben Rückruf, der durch Anfrageereignis 302 verursacht wird, bearbeiten. HTTP-Modul 305 ist so gezeigt, dass es mit nur einem Anfrageereignis registriert ist. Ein HTTP-Modul kann auch mit mehr als einem Anfrageereignis registriert sein, so dass das HTTP-Modul so viele Rückrufe erhält, wie es Module gibt, mit denen es registriert ist. Z.B., zeigt 3, dass HTTP-Modul 304 mit Anfrageereignissen 301 und 302 registriert ist. Ebenso ist HTTP-Modul 306 mit Anfrageereignissen 302 und 303 registriert.
Gemäß der Erfindung schließt die Ereignispipeline vorzugsweise 10 deterministische Anfrageereignisse und drei nicht deterministische Anfrageereignisse ein. Außerdem können die deterministischen Anfrageereignisse synchrone oder asynchrone Anfrageereignisse sein. Die (synchronen) deterministischen Ereignisse schließen in bevorzugter Reihenfolge ein:
BeginRequest
AuthenticateRequest
AuthorizeRequest
ResolveRequestCache
AcquireRequestState
PreRequestHandlerExecute
PostRequestHandlerExecute
ReleaseRequestState
UpdateRequestCache
EndRequest
Natürlich kann die Reihenfolge der deterministischen Anfrageereignisse abhängig von den Erfordernissen der Anwendung umgeordnet werden. Die nicht deterministischen Anfrageereignisse schließen ein:
Error
PreSendRequestContent
PreSendRequestContent
Es sollte auch verstanden sein, dass weniger, mehr und/oder andere deterministische und nicht-deterministische Anfrageereignisse in der Ereignispipeline zum Erzeugen von Rückrufen eingeschlossen sein können.
Das BeginRequest Ereignis tritt ein, wenn die Bearbeitung einer HTTP-Anfrage beginnt. Das AuthenticateRequest Ereignis tritt an einem Punkt während der Lebensdauer der HTTP-Anfrage ein, an dem die Anwendung es erfordert, einen Benutzer zu authentifizieren. Das AuthorizeRequest Ereignis tritt ein, wenn die Anwendung ermitteln muss, ob ein Benutzer autorisiert ist, eine Antwort auf eine bestimmte Anfrage zu erhalten. Das ResolveRequestCache Ereignis tritt ein, wenn die Anwendung es erfordert, zu ermitteln, ob die gesamte Antwort auf die Anfrage zwischengespeichert worden ist, und dabei möglicherweise die Zeit reduziert wird, die benötigt wird, um die angefragte Seite zu erzeugen und eine Antwort an den anfragenden Benutzer zurückzuschicken. An diesem Punkt wird der HTTP-Handler erzeugt. Das AcquireRequestState Ereignis tritt ein, um einen zusätzlichen Status zu erfassen, der mit der Client-Verbindung assoziiert ist, listet ASP.NET Sitzungsstatus. Personalisierungsmodule können z.B. das AcquireRequestState Ereignis benutzen. Das AcquireRequestState Ereignis tritt ein, nachdem der HTTP-Handler erzeugt wurde, so dass ein Modul den HTTP-Handler prüfen kann und entscheiden, welche Statusart benötigt wird. Das PreRequestHandlerExecute Ereignis tritt ein, bevor der Anfragehandler die angefragte Webseite erzeugt. In ähnlicher Weise tritt das PostRequestHandlerExecute Ereignis ein, wenn der Anfragehandler das Erzeugen der angefragten Webseite abgeschlossen hat. Das ReleaseRequestState Ereignis tritt ein, um einem Modul die Möglichkeit zu geben, irgendwelche Statusänderungen zu speichern, die in AcquireRequestState ermittelt wurden. Z.B. kann ein Sitzungsstatusmodul das ReleaseRequestState Ereignis verwenden, um Sitzungsdaten zu speichern. Das UpdateRequestCache Ereignis tritt während der Verarbeitung einer Anfrage ein, wenn der Zwischenspeicher auf den neuesten Stand gebracht werden sollte, um die Antwort zu speichern, so dass die Antwort später (für nachfolgende HTTP-Anfragen für dieselbe Seite) im Zwischenspeicher (ResolveRequestCache) gefunden werden kann, wenn die Antwort zwischenspeicherbar ist. Letztlich tritt das EndRequest Ereignis ein, wenn die Bearbeitung der Anfrage vollständig ist.
Das nicht deterministische Error Ereignis tritt ein, wenn eine fehlerhafte Gegebenheit eintritt, beispielsweise wenn eine Ausnahmegegebenheit erzeugt wird, die z.B. nicht von dem Anwendungscode aufgefangen wird. Das PreSendRequestContent Ereignis tritt ein, wenn begonnen wird, Inhalt zu dem anfragenden Benutzer zu senden bevor der HTTP-Handler die Anfrage bearbeitet. Ebenso tritt das PreSendRequestHeaders Ereignis ein, wenn begonnen wird Header (Köpfe) zu dem anfragenden Client zu senden, bevor der HTTP-Handler die Anfrage bearbeitet. Das Ziel der PreSendRequestContent und Pre-SendRequestHeader Anfrageereignisse ist es, dass andere Methoden den Inhalt und/oder Header bearbeiten können, bevor der Inhalt und/oder Header zu der anfragenden Client-Anwendung gesendet werden. Wie vorher schon erwähnt, wird in Situationen, in denen ein funktionales Modul Inhalt und/oder Headers präsentiert, bevor der HTTP-Handler die angefragte Webseite erzeugt, jede Bearbeitung nicht ausgeführt, die durch ein funktionelles Modul ausgeführt wird, das in einer herkömmlichen Bearbeitungssequenz später liegt, weil der Inhalt und/oder die Headers nicht mehr länger zur Bearbeitung verfügbar ist.
Überwachungsereignisse können effektiv zum Einhüllen einer Anwendung mit intelligentem Fehlerbehandlungscode verwendet werden. In Situationen, in denen etwas unerwartetes in einer Anwendung passiert und das Error Ereignis eintritt, bietet die vorliegende Erfindung einem Entwickler die Flexibilität, zu entscheiden, wie die unerwartete Bedingung gehandhabt wird. Z.B. könnte, zusätzlich zum Protokollieren des Fehlers und Benachrichtigen eines Systemadministrators, der aktuelle Status von allen gerade eingeloggten Benutzern in eine XML Datei protokolliert werden. Wenn die Fehlergegebenheit berichtigt ist, und die Anwendung beginnt, normal abzulaufen, kann die Anwendung so designt sein, jeden Endbenutzer unter Verwendung der XML Datei zu kontaktieren, der wegen der Fehlerbedingung herausfiel.
Überwachungsereignisse können entweder durch Verwenden der GLOBAL.ASAX Anwendungsdatei oder vorkompilierten Komponenten entwickelt werden, die die IHttpModule-Schnittstelle implementieren. Der folgende Pseudocode stellt basierend auf der Microsoft VISUAL BASIC Markenprogrammiersprache ein beispielhaftes GLOBAL.ASAX dar:
HTTP-Module werden als Klassen erzeugt, die die System.Web.IHttpModule-Schnittstelle implementieren, und die Init() Methode zum Synchronisieren zu irgendeinem HTTP-Anwendungsereignis verwenden. Der folgende Pseudocode ist ein Beispiel für ein HTTP-Modul:
Ein HTTP-Modul wird kompiliert und eine .Net Library DLL (Bibliothek) wird innerhalb des „bin" Verzeichnisses unter dem vroot der Anwendung genutzt. Das HTTP-Modul ist in config.web unter Verwendung des folgenden exemplarischen Pseudocodes registriert:
Innerhalb des Prozesses zum Ablaufenlassen von ASP.NET-Prozessen werden Threads zum Ausführen von Code verwendet. Ein Thread ist eine Ressource, und es gibt eine endliche Anzahl von Threads, die ASP.NET verwenden kann.
Gemäß der Erfindung erzeugt und managed ASP.NET einen Thread-Pool, der die Anzahl von Threads während der Lebensdauer einer Anwendung unter der Kontrolle eines Anwendungsentwicklers erweitert und verkleinert.
In manchen Fällen kann Anwendungscode, so wie z.B. Netzwerk I/O einen Thread in einem Prozess blockieren, weil der Thread warten muss (d.h. der Thread ist blockiert), bis diese relativ langsamere Netzwerk I/O Funktion fertig ist. Wenn ein Thread blockiert ist, kann der Thread nicht zum Unterstützen einer Anfrage verwendet werden und resultiert dabei in einem Schlangestehen von Anfragen und im Herabsetzen der Leistung einer Anwendung, weil alle Threads blockiert sind, während sie warten, anstatt dass sie beschäftigt sind ihre Arbeit zu machen. Um solch eine Situation zu vermeiden, bietet die vorliegende Erfindung Unterstützung für asynchrone Ereignisse, und Unterstützung für synchrone Ereignisse. Folglich unterstützt die vorliegende Erfindung eine Anwendung, die eine Funktion über ein Netzwerk ausführt, in welchem die Netzwerkklasse zum ermöglichen von asynchronen IOs IO-Completion-Ports unterstützt, wie z.B. ein Webservice Proxy.
Die vorliegende Erfindung unterstützt auch zehn asynchrone Anfrageereignisse, die jeweils jedem der synchronen deterministischen Anfrageereignisse entsprechen. Die asynchronen Anfrageereignisse treten in folgender Reihenfolge ein:
AddOnBeginRequestAsync
AddOnAuthenticateRequestAsync
AddOnAuthorizeRequestAsync
AddOnResolveRequestCacheAsync
AddOnAcquireRequestStateAsync
AddOnPreRequestHandlerExecuteAsync
AcidOnPostRequestHandlerExecuteAsync
AddOnReleaseRequestStateAsync
AddOnUpdateRequestCacheAsync
AddOnEndRequestAsync
Um asynchrone Ereignisse innerhalb von GLOBAL.ASAX zu verwenden, muss der Ereignisprototyp manuell in der Ereignispipeline durch Aufheben der Init() Methode, die als virtuell in einer HTTP-Anwendung markiert ist, erzeugt werden, oder mit fest zugeordnetem Code darin verdrahtet sein. Z.B., um das AddOnBeginRequestAsync-Ereignis fest zu verdrahten, welches die asynchrone Version des OnBeginRequest-Ereignisses ist, würde die AddOnBeginRequestAsync-Methode der Anwendungsinstanz aufgerufen werden, um zwei Ereignishandler einzuleiten. Der folgende exemplarische Pseudocode stellt dies dar:
In dem oberen exemplarischen Pseudocode werden ein neuer BeginEventHandler und ein neuer EndEventHandler durch das Einleiten von zwei Mitgliedsmethoden (Begin und End) erzeugt, die aufgerufen werden, wenn das Ereignis abläuft. Ein Anwendungsentwickler müsste auch beide Ereignishandler implementieren. Z.B., verwendet der Begin()-Handler eine Instanz einer kundenspezifischen Klasse, die, wie in dem folgenden exemplarischen Pseudocode gezeigt, als SimpleAsyncResult definiert ist, das auf einem anderen Thread ausgeführt würde:
Eine beispielhafte Implementierung einer Klasse, die die IASyncResult Schnittstelle implementiert, ist in dem folgenden Pseudocode gezeigt:
Das End-Ereignis kann verwendet werden, um irgendwelche offenen Ressourcen, falls notwendig, aufzuräumen, wie durch den folgenden exemplarischen Pseudocode dargestellt:
Weil ASP.NET beides unterstützt, synchrone und asynchrone Anwendungsereignisse, hat ein Anwendungsentwickler mehr Optionen zum Erstellen einer Anwendung. Wenn ein Ereignis als asynchron programmiert wird, gibt es den ASP.NET Worker Thread frei, um andere Anfragen zu unterstützen, bis der Code, der von dem asynchronen Thread ausgeführt wird, fertig ist, und dabei in einer besseren Skalierbarkeit resultiert, weil ASP.NET Threads, die zur Unterstützung von Anfragen verwendet werden, nicht blockiert sind.
Während die Erfindung bezüglich bestimmter Beispiele beschrieben worden ist, einschließlich derzeit bevorzugter Modi zum Ausführen der Erfindung, werden Fachleute es begrüßen, dass es zahlreiche Varianten und Umsetzungen der oben beschriebenen Systeme und Techniken gibt, die in den Umfang der Erfindung, wie in den anhängigen Ansprüchen dargelegt, fallen.

Claims

Laufzeitsystem zur Behandlung einer Hypertext-Transfer-Protokoll-Anfrage (HTTP-Anfrage), umfassend: ein Kontextobjekt, das eine HTTP-Anfrage logisch repräsentiert, die bei einer Host-Anwendung von einer Client-Anwendung empfangen wurde, wobei das Kontextobjekt mindestens eine Eigenschaft, die im Zusammenhang mit der HTTP-Anfrage steht, verkapselt; und eine dem Kontextobjekt zugehörige Ereignispipeline, wobei die Ereignispipeline eine Vielzahl von Anfrageereignissen (301–303) aufweist, wobei jedes Anfrageereignis (301–303) ein zugehöriges Ereignis hat und einen Rückruf erzeugt, wenn das dem Anfrageereignis zugehörige Ereignis eintritt und wenn mindestens eine Anwendung und/oder ein Modul (304–306) im Zusammenhang mit dem Anfrageereignis (301–303) registriert ist, wobei jeder Rückruf jede Anwendung und jedes Modul (304–306), die im Zusammenhang mit dem Anfrageereignis (301–303) registriert sind, veranlasst, das Kontextobjekt auszuführen, wobei die Vielzahl der Anfrageereignisse (301–303) eine deterministische Reihenfolge haben.
Laufzeitsystem zur Behandlung einer HTTP-Anfrage gemäß Anspruch 1, wobei mindestens eines der Vielzahl von Anfrageereignissen (301–303) ein synchrones Anfrageereignis ist.
Laufzeitsystem zur Behandlung einer HTTP-Anfrage gemäß Anspruch 1, wobei mindestens eines der Vielzahl von Anfrageereignissen (301–303) ein asynchrones Anfrageereignis ist.
Laufzeitsystem zur Behandlung einer HTTP-Anfrage gemäß Anspruch 1, wobei die Vielzahl von Anfrageereignissen (301–303) des Weiteren mindestens ein Anfrageereignis einschliessen, das eine nicht-deterministische Reihenfolge hat.
Laufzeitsystem zur Behandlung einer Hypertext-Transfer-Protokoll-Anfrage (HTTP-Anfrage), umfassend: ein Kontext objekt, das eine HTTP-Anfrage logisch repräsentiert, die bei einer Host-Anwendung von einer Client-Anwendung empfangen wurde, wobei das Kontextobjekt mindestens eine Eigenschaft, die im Zusammenhang mit der HTTP-Anfrage steht, verkapselt; und eine dem Kontextobjekt zugehörige Ereignispipeline, wobei die Ereignispipeline eine Vielzahl von Anfrageereignissen (301–303) aufweist, wobei jedes Anfrageereignis (301–303) ein zugehöriges Ereignis hat und einen Rückruf erzeugt, wenn das dem Anfrageereignis (301–303) zugehörige Ereignis eintritt und wenn mindestens eine Anwendung und/oder ein Modul (304–306) im Zusammenhang mit dem Anfrageereignis (301–303) registriert ist, wobei jeder Rückruf jede Anwendung und jedes Modul (304–306), die im Zusammenhang mit dem Anfrageereignis (301–303) registriert sind, veranlasst, das Kontextobjekt auszuführen; wobei die Vielzahl der Anfrageereignisse (301–303) eine nicht-deterministische Reihenfolge haben.
Laufzeitsystem zur Behandlung einer HTTP-Anfrage gemäß Anspruch 5, wobei die Vielzahl der Anfrageereignisse (301–303) mit nicht-deterministischer Reihenfolge ein Fehlerereignis einschliessen.
Laufzeitsystem zur Behandlung einer HTTP-Anfrage gemäß Anspruch 1 oder 5, wobei ein Modul (304–306) im Zusammenhang mit einer Vielzahl von Anfrageereignissen (301–303) registriert ist.
Laufzeitsystem zur Behandlung einer HTTP-Anfrage gemäß Anspruch 1 oder 5, wobei die Ereignispipeline für jede HTTP-Anfrage, die bei der Host-Anwendung von einer Client-Anwendung empfangen wurde, eine getrennte Instanz der Ereignispipeline ist.
Laufzeitsystem zur Behandlung einer HTTP-Anfrage gemäß Anspruch 1 oder 5, wobei eine HTTP-Anfrage-Laufzeit die empfangene HTTP-Anfrage analysiert, um das Kontextobjekt, das die HTTP-Anfrage logisch repräsentiert, zu bilden.
Verfahren zum Verarbeiten einer Hypertext-Transfer-Protokoll-Anfrage (HTTP-Anfrage), welches die Schritte umfasst: Bilden eines Kontextobjekts, das eine HTTP-Anfrage logisch repräsentiert, die bei einer Host-Anwendung von einer Client-Anwendung empfangen wurde, wobei das Kontextobjekt mindestens eine Eigenschaft, die im Zusammenhang zu der HTTP-Anfrage steht, verkapselt; Bilden einer dem Kontextobjekt zugehörigen Ereignispipeline, wobei die Ereignispipeline eine Vielzahl von Anfrageereignissen (301–303) aufweist, und jedes Anfrageereignis ein zugehöriges Ereignis hat; Erzeugen eines Rückrufs, wenn das einem Anfrageereignis (301–303) zugehörige Ereignis eintritt und wenn mindestens eine Anwendung und/oder ein Modul (304–306) im Zusammenhang mit dem Anfrageereignis (301–303) registriert ist; und Veranlassen, dass jede Anwendung und jedes Modul (304–306), die im Zusammenhang mit dem Anfrageereignis (301–303) registriert sind, das Kontextobjekt als Antwort auf den Rückruf ausführen, wobei die Vielzahl der Anfrageereignisse eine deterministische Reihenfolge hat.
Verfahren gemäß Anspruch 10, des Weiteren einen Schritt zum Registrieren eines Moduls (304–306) im Zusammenhang mit mindestens einem ausgewählten Anfrageereignis (301–303) umfassend.
Verfahren gemäß Anspruch 10, des Weiteren einen Schritt zum Registrieren einer Vielzahl von Modulen (304–306) im Zusammenhang mit einem ausgewählten Anfrageereignis (301–303) umfassend.
Verfahren gemäß Anspruch 10, wobei mindestens eines der Vielzahl von Anfrageereignissen (301–303) ein synchrones Anfrageereignis (301–303) ist.
Verfahren gemäß Anspruch 10, wobei mindestens eines der Vielzahl von Anfrageereignissen (301–303) ein asynchrones Anfrageereignis (301–303) ist.
Verfahren gemäß Anspruch 10, wobei die Vielzahl von Anfrageereignissen (301–303) des Weiteren mindestens ein Anfrageereignis (301–303) einschliesst, das eine nicht-deterministische Reihenfolge hat.
Verfahren zum Verarbeiten einer Hypertext-Transfer-Protokoll-Anfrage (HTTP-Anfrage), welches die Schritte umfasst: Bilden eines Kontextobjekts, das eine HTTP-Anfrage logisch repräsentiert, die bei einer Host-Anwendung von einer Client-Anwendung empfangen wurde, wobei das Kontextobjekt mindestens eine Eigenschaft, die im Zusammenhang zu der HTTP-Anfrage steht, verkapselt; Bilden einer dem Kontextobjekt zugehörigen Ereignispipeline, wobei die Ereignispipeline eine Vielzahl von Anfrageereignissen (301–303) aufweist, und jedes Anfrageereignis (301–303) ein zugehöriges Ereignis hat; Erzeugen eines Rückrufs, wenn das einem Anfrageereignis (301–303) zugehörige Ereignis eintritt und wenn mindestens eine Anwendung und/oder ein Modul (304–306) im Zusammenhang mit dem Anfrageereignis (301–303) registriert ist; und Veranlassen, dass jede Anwendung und jedes Modul (304–306), die im Zusammenhang mit dem Anfrageereignis (301–303) registriert sind, das Kontextobjekt als Antwort auf den Rückruf ausführen, wobei die Vielzahl der Anfrageereignisse (301–303) eine nicht-deterministische Reihenfolge hat.
Verfahren gemäß Anspruch 16, wobei die Vielzahl der Anfrageereignisse (301–303) mit nicht-deterministischer Reihenfolge ein Fehlerereignis einschliessen.
Verfahren gemäß Anspruch 10 oder 16, wobei der Schritt des Bildens der Ereignispipeline zugehörig zu dem Kontextobjekt die Ereignispipeline als eine getrennte Instanz für jede HTTP-Anfrage, die bei der Host-Anwendung von einer Client-Anwendung empfangen wurde, bildet.
Verfahren gemäß Anspruch 10 oder 16, wobei der Schritt des Bildens eines Kontextobjekts einen Schritt zum Analysieren der empfangene HTTP-Anfrage einschliesst, um das Kontextobjekt zu bilden.
Computer-lesbares Medium, das computer-ausführbare Instruktionen zum Ausführen des Verfahrens von einem der Ansprüche 10 bis 19 hat.