-
GEBIET DER
ERFINDUNG
-
Diese
Erfindung betrifft Server-Architekturen in vernetzten Computersystemen,
und insbesondere eine verteilte Architektur, welche ein dynamisches
Bedienen von Anwender-Anfragen über
verschiedene Maschinen hinweg ermöglicht.
-
HINTERGRUND
DER ERFINDUNG
-
Das
Welt-Weit-Netz ("World-Wide-Web") enthält ein Netzwerk
von Servern auf dem Internet, von denen jeder mit einer oder mehreren
HTML- (Hypertext-Markier-Sprache, "Hypertext Markup Language")-Seiten assoziiert
ist. Die mit einem Server assoziierten HTML-Seiten stellen Informationen
und Hypertext-Querverbindungen ("links") zu anderen Dokumenten
auf diesem beziehungsweise (üblicherweise)
einem anderen Server bereit. Server kommunizieren mit Client-Programmen [Deutsch: "Client-Programm"] unter Verwendung
des Hypertext-Transfer-Protokolls (HTTP). Die Server hören auf
Anfragen von Client-Programmen nach ihren HTML-Seiten, und werden
daher häufig
auch als "Hörer" ("listeners") bezeichnet.
-
Anwender
des World-Wide-Web verwenden ein als Browser bezeichnetes Client-Programm,
um bei Hörern
nach Informationen nachzufragen, diese zu dekodieren und darzustellen.
Wenn der Anwender einen Querverweis ("link")
auf eine HTML-Seite auswählt,
sendet der Browser, der diese Seite darstellt, über das Internet eine Anfrage
an den jeweiligen Hörer,
der mit dem in diesem Link spezifizierten Universelle-Ressource-Lokalisierer
("Universal Resource
Locator", URL) assoziiert
ist. In Antwort auf die Anfrage überträgt der Hörer die
angefragte Information zu dem Browser, der die Anfrage ausgegeben
hatte. Der Browser empfängt
die Information, präsentiert
die empfangene Information dem Anwender, und wartet auf die nächste Anwender-Anfrage.
-
Traditionellerweise
liegt die auf Hörern
gespeicherte Information in Form statischer HTML-Seiten vor. Statische
HTML-Seiten werden vor einer Anfrage eines Web-Browsers erzeugt
und auf dem Hörer
gespeichert. In Antwort auf eine Anfrage wird eine statische HTML-Seite
einfach aus dem Speicher ausgelesen und zu dem anfragenden Browser übertragen.
Es gibt zur Zeit einen Trend, Hörer
zu entwickeln, welche auf Hörer-Anfragen
mit Ausführen
dynamischer Vorgänge
antworten. Beispielsweise kann ein Hörer auf eine Anfrage durch
Ausgeben einer Anfrage an eine Datenbank antworten, wobei er eine
Web-Seite, welche die Ergebnisse der Anfrage enthält, dynamisch
aufbaut, und die dynamisch aufgebaute HTML-Seite zu dem anfragenden Browser überträgt. Um dynamische
Vorgänge
auszuführen,
muss die Funktionalität
des Hörers
verbessert oder vermehrt werden. Es sind verschiedene Ansätze entwickelt
worden, um Hörer
dahingehend zu erweitern, dass sie dynamische Vorgänge unterstützen.
-
Ein
Ansatz, als Antwort auf Anfragen von Web-Browsern dynamische Vorgänge bereitzustellen,
verwendet die Gemeinsame-Gateway-Schnittstelle ("Common Gateway Interface", CGI). CGI ist eine
Spezifikation zum Übertragen
von Information zwischen einem Hörer
und einem CGI-Programm.
Ein CGI-Programm ist ein Programm, welches dazu vorgesehen ist,
Daten anzunehmen und Daten, welche die CGI-Spezifikation erfüllen, zurückzusenden. Das Programm könnte in
irgendeiner Programmiersprache geschrieben sein, inklusive C, Perl,
oder Visual Basic.
-
Der
CGI-Ansatz leidet unter dem Nachteil, dass jedes Mal, wenn der Server
die spezifizierte Anfrage empfängt,
ein separater Prozess (eine separate Instanz des CGI-Programms) gestartet
wird. Ferner werden CGI-Programme auf der gleichen Maschine ausgeführt wie
der Hörer,
welcher die Browser-Anfrage empfangen hat. Daher wird das Empfangen
von tausend solchen Anfragen von verschiedenen Anwendern das Starten
von tausend Prozessen auf der Maschine, auf welcher der Hörer läuft, nach
sich ziehen, wodurch verwendbare Ressourcen auf dem Server verbraucht
werden.
-
Ein
zweiter Nachteil des CGI-Ansatzes ist, dass bei jeder Anfrage ein
separater Prozess gestartet, ausgeführt und beendet wird. Wenn
daher auf einen ersten Satz von zehn Anfragen ein zweiter Satz von
zehn Anfragen folgt, wird für
den ersten Satz von Anfragen ein erster Satz von zehn Prozessen
gestartet und beendet werden, und für den zweiten Satz von zehn
Anfragen wird ein zweiter Satz von zehn Prozessen gestartet und
beendet werden. CGI erlaubt es nicht, die gleichen zehn Prozesse,
welche für
die ersten zehn Anfragen verwendet werden, zum Verarbeiten der zweiten
zehn Anfragen zu verwenden, um mit dem Starten von Prozessen einhergehenden
Mehraufwand zu vermeiden.
-
Ein
alternativer Ansatz zum Bereitstellen dynamischer Antworten auf
Anfragen beinhaltet das Verwenden von Einschub-Erweiterungen ("plug-in extensions"). Eine Einschub-Erweiterung
fängt an
einen Server gesendete Nachrichten in verschiedenen Stadien ab,
um Anwendungsspezifisches Bearbeiten einer spezifischen Anwender-Anfrage
auszuführen.
Ein Server-seitiger Einschub wird im gleichen Adressraum wie der
Hörer,
und wie alle anderen Serverseitigen Einschübe ausgeführt. Daher muss ein Anwendungs-Entwickler, der einen
Einschub entwickelt, mit Betriebs-Details niederer Ebene des Hörers vertraut
sein. Darüber hinaus
setzt das Ausführen
von Einschüben
im gleichen Adressraum wie den Hörer,
den Hörer
Sicherheits- und Stabilitäts-Risiken
aus, wenn ein fehlerhafter Einschub andere Einschübe oder
den Hörer
selber abstürzen
lassen, oder sich in einer unvorhergesehenen Weise verhalten lassen
kann.
-
Ein
zweites Problem mit dem Einschub-Ansatz ist, dass ähnlich dem
CGI-Ansatz, alle Einschub-Vorgänge
auf der gleichen Maschine ausgeführt
werden, welche der Hörer
ausführt.
Da die durch die Einschub-Erweiterung ausgeführten Aufgaben ("tasks") nicht auf andere
Maschinen ausgelagert ("off-loaded") werden können, ist
die Skalierbarkeit des Einschub-Ansatzes wesentlich begrenzt.
-
Weitere
Details zu dem Hintergrund und zu den durch Ausführungsformen der vorliegenden
Erfindung gelösten
Problemen sind in einem Artikel von Nigel Edwards und Owen Rees
zu finden, welcher den Titel "High Security
Web-Servers and
Gateways" COMPUTER
NETWORKS AND ISDN SYSTEMS, 29, (1997) 927-938 trägt.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Es
wird ein Verfahren und ein System zum Behandeln von Browser-Anfragen
mit einem Verteilte-Web-Applikations-Server bereitgestellt. Die verteilte
Umgebung ermöglicht
es Prozessen (Kartusche-Instanzen, "cartridge instances"), welche die durch Browser-Spezifikationen
spezifizierten Vorgänge
ausführen, auf
anderen Maschinen zu laufen als die Hörer, welche die Anfragen empfangen,
und als die Browser, welche die Anfragen ausgeben. Da sich die Kartusche-Instanzen auf anderen
Maschinen als die Hörer
befinden, sind die Hörer
besser gegenüber
fehlerhaften Kartusche-Instanzen
geschützt,
wodurch die Zuverlässigkeit
und Sicherheit des Systems erhöht
wird. Darüber
hinaus ist die Skalierbarkeit des Systems durch Verteilen der Verarbeitungs-Last über viele
Maschinen, anstatt der einen Maschine, welche der Hörer ausführt, stark
erhöht. Die
Fähigkeit,
Kartusche-Instanzen-Ausführung über verschiedene
Maschinen zu verteilen, erlaubt das Anwenden vielfältiger Arten
von Last-Ausgleichs-Techniken beim Entscheiden darüber, wann
und wo neue Kartusche-Instanzen abgelegt werden.
-
Gemäß einem
Aspekt der Erfindung wird ein Vorgang unter Verwenden eines auf
einer ersten Maschine laufenden Versenders ("dispatcher") und eines auf einer zweiten Maschine
laufenden Ressourcen-Managers ausgeführt. Eine erste Nachricht wird
von dem Versender zu dem Ressourcen-Manager gesendet. Die erste Nachricht
identifiziert eine spezielle Kartusche, welche geeignet ist, den
Vorgang auszuführen.
Eine zweite Nachricht wird vom Ressourcen-Manager zum Versender gesendet. Die
zweite Nachricht identifiziert eine spezielle Instanz der speziellen
Kartusche. Die spezielle Instanz läuft auf einer dritten Maschine.
-
Eine
dritte Nachricht wird vom Versender zu der speziellen Instanz gesendet,
um die spezielle Instanz zu veranlassen, den Vorgang auszuführen. Wenigstens
zwei der ersten Maschine, zweiten Maschine und dritten Maschine
sind separate Maschinen.
-
Gemäß einem
anderen Aspekt der Erfindung wird ein System zum Durchführen von
mit Browser-Anfragen einhergehenden Vorgängen bereitgestellt. Das System
weist eine Mehrzahl von mit einer Mehrzahl von Web-Hörern verbundenen
Versendern auf. Jeder Versender aus der Mehrzahl von Versendern
empfängt
von einem zugehörigen
Web- Hörer aus
der Mehrzahl von Web-Hörern
Browser-Anfragen, welche von den zugehörigen Web-Hörern empfangen wurden.
-
Das
System weist ferner einen virtueller-Pfad-Manager und einen Ressourcen-Manager
auf. Der virtueller-Pfad-Manager
ist mit der Mehrzahl von Versendern durch einen Inter-Maschine-Kommunikationsmechanismus
verbunden. Der Virtueller-Pfad-Manager zeigt den Versendern an,
welcher aus einer Mehrzahl von Kartuschen mit der Web-Browser-Anfrage assoziiert
ist. Der Ressourcen-Manager ist mit der Mehrzahl von Versendern
durch den Inter-Maschine-Kommunikations-Mechanismus
verbunden. Der Ressourcen-Manager ist
derart konfiguriert, dass er als Antwort auf das Empfangen einer
Anforderung einer Instanz von dem Versender jedem Versender aus
der Mehrzahl von Versendern eine Instanz einer Kartusche aus der
Mehrzahl von Kartuschen zuordnet.
-
Die
Mehrzahl von Versendern ist derart konfiguriert, dass sie durch
den Inter-Maschine-Kommunikations-Mechanismus Nachrichten zu den Instanzen
sendet, welche durch den Ressourcen-Manager den Versendern zugeordnet
sind. Die Nachrichten veranlassen die Instanz zum Ausführen der
mit den Browser-Anfragen assoziierten Vorgängen.
-
KURZBESCHREIBUNG
DER ZEICHNUNGEN
-
Die
vorliegende Erfindung wird beispielhaft, aber nicht limitierend,
durch die Figuren der begleitenden Zeichnungen illustriert, in denen
gleiche Bezugszeichen sich auf ähnliche
Elemente beziehen.
-
1 ist
ein Blockdiagramm eines Computersystems, auf welchem eine Ausführungsform
der Erfindung implementiert werden kann;
-
2 ist
ein Blockdiagramm eines Verteilte-Anwendung-Servers gemäß einer
Ausführungsform
der Erfindung;
-
3A ist
ein Abschnitt eines Flussdiagramms, welches Schritte zum Behandeln
einer Browser-Anfrage gemäß einer
Ausführungsform
der Erfindung zeigt;
-
3B ist
ein anderer Abschnitt des Flussdiagramms, welches Schritte zum Behandeln
einer Browser-Anfrage gemäß einer
Ausführungsform
der Erfindung zeigt;
-
4 ist
ein Blockdiagramm einer Tabelle, welche von einem Versender gemäß einer
Ausführungsform
der Erfindung unterhaltene Informationen enthält;
-
5 ist
ein Blockdiagramm einer Tabelle, welche von einem Ressourcen-Manager
gemäß einer
Ausführungsform
der Erfindung unterhaltene Informationen enthält.
-
DETAILLIERTE
BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
-
Ein
Verfahren und eine Vorrichtung zum Durchführen von Vorgängen über ein
Netzwerk werden beschrieben. In der folgenden Beschreibung sind
zum Zwecke der Erklärung
viele spezifische Details angegeben, um ein gründliches Verständnis der
vorliegenden Erfindung zu erreichen. Es ist allerdings für einen
Fachmann offensichtlich, dass die vorliegende Erfindung ohne diese
speziellen Details ausgeführt
werden kann. In anderen Fällen
("instances") sind wohlbekannte
Strukturen und Vorrichtungen in Blockdiagramm-Form gezeigt, um ein
unnötiges
Verundeutlichen der vorliegenden Erfindung zu vermeiden.
-
HARDWARE-ÜBERSICHT
-
1 ist
ein Blockdiagramm, welches ein Computersystem 100 zeigt,
auf welchem eine Ausführungsform
der Erfindung implementiert werden kann. Computersystem 100 weist
auf: einen Bus 102 oder einen anderen Kommunikations-Mechanismus, zum
Kommunizieren von Informationen, und einen mit dem Bus 102 verbundenen
Prozessor 104 zum Verarbeiten von Information. Computersystem 100 weist
ferner einen Hauptspeicher 106, wie etwa einen Direktzugriffsspeicher
("random access
memory", RAM) auf,
oder eine andere, mit dem Bus 102 verbundene dynamische
Speicher-Vorrichtung zum Speichern von Information und von vom Prozessor 104 auszuführendenden
Befehlen. Der Hauptspeicher 106 kann ferner während dem
Ausführen
von durch Prozessor 104 auszuführenden Befehlen zum Speichern
temporärer
Variablen und anderer Zwischen-Informationen verwendet werden. Computersystem 100 weist
ferner einen Nur-Lese-Speicher ("read only
memory", ROM) 108 auf,
oder eine andere, an Bus 102 gekoppelte Speicher-Vorrichtung
zum Speichern von statischer Information und von Befehlen für Prozessor 104.
Eine Speicher-Vorrichtung 110 wie eine magnetische Platte
oder eine optische Platte, ist zum Speichern von Information und
Befehlen bereitgestellt und mit Bus 102 verbunden.
-
Computersystem 100 kann über Bus 102 mit
einer Anzeige 112 zum Anzeigen von Information für einen
Computer-Anwender,
wie etwa einer Kathodenstrahl-Röhre
("cathode ray tube", CRT) verbunden
sein. Eine Eingabe-Vorrichtung 114, welche alphanumerische
und andere Tasten aufweist, ist mit Bus 102 verbunden,
um Information und Befehls-Auswahlen an Prozessor 104 zu übermitteln.
Eine andere Art von Anwender-Eingabe-Vorrichtung
ist Cursor-Kontrolle 116, wie etwa eine Maus, ein Trackball
oder Cursor-Richtungs-Tasten zum Kommunizieren von Richtungs-Information
und Befehls-Auswahlen
an Prozessor 104 und zum Steuern von Cursor-Bewegung auf der
Anzeige 112. Diese Eingabe-Vorrichtung weist üblicherweise
zwei Freiheitsgrade in zwei Achsen auf, einer ersten Achse (beispielsweise
x) und einer zweiten Achse (beispielsweise y), wodurch es der Vorrichtung
möglich
ist, Positionen in einer Ebene festzulegen.
-
Die
Erfindung betrifft die Anwendung des Computersystems 100,
um in Antwort auf Nachrichten von Browsern spezifische Vorgänge auszuführen. Gemäß einer
Ausführungsform
der Erfindung werden die Vorgänge
von Computersystem 100 in Antwort auf das Ausführen von
einer oder mehrerer Sequenzen von einem oder mehreren im Hauptspeicher 106 enthaltenen
Befehlen durch Prozessor 104 ausgeführt. Solche Befehle können von
einem anderen Computer-lesbaren Medium, wie etwa Speicher-Vorrichtung 110 in
Hauptspeicher 106 eingelesen werden. Das Ausführen von
Sequenzen von im Hauptspeicher 106 enthaltenen Befehlen
veranlasst Prozessor 104 die hier beschriebenen Verfahrens-Prozess-Schritte
auszuführen.
Bei alternativen Ausführungsformen
können
hartverdrahtete Schaltungen anstelle von Software-Befehlen oder
in Kombination damit verwendet werden, um die Erfindung zu implementieren.
Daher sind die Ausführungsformen
der Erfindung nicht auf irgendeine spezielle Kombination von Hardware-Schaltungstechnik
und Software begrenzt.
-
Der
Term "Computer-lesbares
Medium", wie er
hier verwendet wird, bezieht sich auf irgendein Medium, welches
an der Bereitstellung von Befehlen zur Ausführung durch Prozessor 104 mitwirkt.
Solch ein Medium kann viele Formen annehmen, inklusive nicht-flüchtigen
Medien, flüchtigen
Medien und Übertragungs-Medien,
aber nicht auf diese beschränkt.
Nicht-flüchtige
Medien beinhalten beispielsweise optische oder magnetische Platten,
wie etwa Speicher-Vorrichtung 110. Flüchtige Medien beinhalten dynamische
Speicher, wie etwa Hauptspeicher 106. Übertragungs-Medien beinhalten
Koaxialkabel, Kupferdraht und Faseroptiken, inklusive den Drähten, welche
Bus 102 aufweisen. Übertragungsmedien
können
auch die Form von akustischen Wellen oder Lichtwellen annehmen,
wie etwa diejenigen, welche bei Radiowellen- beziehungsweise Infrarot-Datenkommunikationen
erzeugt werden.
-
Übliche Arten
von Computer-lesbaren Medien beinhalten beispielsweise eine Floppy-Disk,
eine flexible Platte, Festplatte, magnetisches Band oder irgendein
anderes magnetisches Medium, eine CD-ROM, irgendein anderes optisches
Medium, Lochkarten, Papierband oder irgendein anderes physisches
Medium mit Mustern aus Löchern,
ein RAM, ein PROM und EPROM, ein FLASH-EPROM, irgendeinem anderen
Speicher-Schaltkreis oder Kartusche, eine Trägerwelle, wie nachfolgend beschrieben,
oder irgendein anderes Medium, von welchem ein Computer lesen kann.
-
Es
können
verschiedene Formen von Computer-lesbaren Medien beteiligt sein,
um eine oder mehrere Sequenzen von einem oder mehreren Befehlen
an Prozessor 104 zur Ausführung zu übertragen. Beispielsweise können die
Befehle ursprünglich
auf einer magnetischen Platte eines entfernt angeordneten ("remote") Computer gehalten
sein. Der entfernt angeordnete Computer kann die Befehle in seinen
dynamischen Speicher laden und die Befehle mittels eines Modems über eine
Telefonleitung senden. Ein an Computersystem 100 lokal
vorhandenes Modem kann die Daten von der Telefonleitung empfangen
und einen Infrarot-Übertrager
verwenden, um die Daten in ein Infrarot-Signal zu übertragen.
Ein an Bus 102 angeschlossener Infrarot- Detektor kann die mit dem Infrarotsignal übertragenen
Daten empfangen und die Daten auf Bus 102 geben. Bus 102 trägt die Daten
zu Hauptspeicher 106, von welchem Prozessor 104 die
Befehle zurückgewinnt
und ausführt.
Die von Hauptspeicher 106 empfangenen Befehle können vor
oder nach Ausführen
durch Prozessor 104 auf Speichermedium 110 gespeichert
werden.
-
Computersystem 100 enthält ferner
eine mit Bus 102 verbundene Kommunikations-Schnittstelle 118. Kommunikations-Schnittstelle 118 stellt
eine zwei-Wege-Datenkommunikationsverbindung
bereit, welche mit einer Netzwerk-Verbindung ("network link") 120 verbindet, welche mit
einem lokalen Netzwerk 122 verbunden ist. Beispielsweise
kann die Kommunikations-Schnittstelle 118 eine "integrated services
digital network"(ISDN)-Karte
[Deutsch: "Dienste-integrierendes
digitales Nachrichtennetz"]
oder ein Modem zum Bereitstellen einer Datenkommunikations-Verbindung
mit einem zugehörigen
Typ von Telefonleitung sein. Als ein weiteres Beispiel kann Kommunikations-Schnittstelle 118 eine "local area network" (LAN)-Karte [Deutsch: "Lokal-Bereich-Netzwerk"] zum Bereitstellen
einer Datenkommunikations-Verbindung mit einem kompatiblen LAN sein.
Drahtlose Verbindungen ("links") können ebenfalls
implementiert werden. Bei einer solchen Implementierung sendet beziehungsweise
empfängt
Kommunikations-Schnittstelle 118 elektrische, elektromagnetische oder
optische Signale, welche Digital-Daten-Ströme tragen,
welche vielfältige
Arten von Information repräsentieren.
-
Netzwerk-Verbindung 120 stellt üblicherweise
durch ein oder mehrere Netzwerke Datenkommunikation zu anderen Datendiensten
bereit. Beispielsweise kann Netzwerk-Verbindung 120 durch das lokale
Netzwerk 122 eine Verbindung zu einem Host-Computer 124 oder
zu Daten-Ausrüstung herstellen,
welche von einem "internet
service provider" (ISP) 126 [Deutsch: "Internet-Dienste-Bereitsteller"] betrieben wird.
ISP 126 stellt seinerseits Datenkommunikationsdienste durch
das jetzt üblicherweise
als das "Internet" 128 bezeichnete
weltweite Paket-Datenkommunikations-Netzwerk
bereit. Das lokale Netzwerk 122 und das Internet 128 verwenden
beide elektrische, elektromagnetische oder optische Signale, welche
digitale Datenströme
tragen. Die Signale durch die verschiedenen Netzwerke und die über Netzwerk-Verbindung 120 und
durch Kommunikations-Schnittstelle 118 laufenden Signale,
welche die digitalen Daten zu Computersystem 100 und von
diesem weg tragen, sind beispielhafte Formen von Trägerwellen,
welche die Informationen tragen.
-
Computersystem 100 kann
durch das/die Netzwerk(e), Netzwerk-Verbindung 120 und
Kommunikations-Schnittstelle 118 Nachrichten versenden
und Daten, inklusive Programm-Code,
empfangen. Bei dem Internet-Beispiel könnte Server 130 einen
für ein
Anwendungs-Programm angefragten Code durch Internet 128, ISP 126,
lokales Netzwerk 122 und Kommunikations-Schnittstelle 118 übertragen.
-
Der
empfangene Code kann so wie er empfangen wurde durch Prozessor 104 ausgeführt werden und/oder
in der Speichervorrichtung 110 oder einem anderen nicht-flüchtigen
Speicher zum späteren
Ausführen
gespeichert werden. Auf diese Weise kann Computersystem 100 Anwendungs-Code
in Form einer Trägerwelle
erhalten.
-
FUNKTIONALE ÜBERSICHT ÜBER DEN
APPLIKATIONS-SERVER
-
2 ist
ein Blockdiagramm eines gemäß einer
Ausführungsform
der Erfindung eingerichteten Systems 200.
-
System 200 weist
eine Mehrzahl von Browsern 202, 204 und 206 auf,
welche gemäß einem HTTP-Protokoll über das
Internet 208 mit einer Mehrzahl von Hörern 210, 216 und 222 kommunizieren.
In Antwort auf Anfragen der Browser veranlassen die Hörer einen
Web-Applikations-Server 280, hier als Kartuschen bezeichnete
Software-Module aufzurufen. In der beschriebenen Ausführungsform
hat der Applikations-Server 280 die
Ausführung
von drei Kartuschen 230, 234 und 238 gestartet.
-
Der
Web-Applikationsserver 280 ist aus mehreren Komponenten
zusammengesetzt, inklusive Transport-Adaptern 212, 218 und 224,
Versendern 214, 220 und 226, einem Authentifizierungs-Server 252,
einem virtueller-Pfad-Manager 250,
einem Ressourcen-Manager 254, einem Konfigurations-Bereitsteller 256 und
einer Mehrzahl von Kartusche-Ausführwerkzeuge 228, 232 und 236.
Die verschiedenen Komponenten des Web-Applikations-Servers 280 werden
im Folgenden detaillierter beschrieben.
-
Im
Wesentlichen kommunizieren die vielfältigen Komponenten des Web-Applikations-Servers 280 durch
einen Inter-Maschine-Kommunikations-Mechanismus, wie etwa Objekt-Anfrage-Vermittler
("Object Request
Broker") 282.
Durch Verwenden eines Inter-Maschine-Kommunikations-Mechanismus
können
Kartusche-Instanzen, welche die in Browser-Anfragen spezifizierten
Vorgänge
ausführen,
auf anderen Maschinen laufen, als die Hörer ("listeners"), welche die Anfragen empfangen, und
als die Browser, welche die Anfragen ausgeben. Da die Kartusche-Instanzen
sich auf anderen Maschinen als die Hörer befinden, sind die Hörer besser
gegenüber
fehlerhaften Kartusche-Instanzen isoliert, wodurch sich die Zuverlässigkeit
und Sicherheit des Systems erhöht.
Darüber
hinaus wird die Skalierbarkeit des Systems wesentlich erhöht, indem
die Bearbeitungs-Last des Ausführens
der Kartusche-Instanzen auf mehrere Maschinen, anstatt nur auf die
gleiche Maschine, welche den Hörer
ausführt,
verteilt wird. Die Möglichkeit,
Kartusche-Instanzen-Ausführung über eine Mehrzahl
von Maschinen zu verteilen, erlaubt bei der Entscheidung darüber, wann
und wo neuen Kartusche-Instanzen abgelegt ("to spawn") werden, die Anwendung vielfältiger Arten
von Lastausgleichs-Techniken.
-
Ein üblicher
Vorgang innerhalb von System 200 weist im Allgemeinen die
folgenden Stadien auf:
Ein Browser überträgt eine Anfrage über das
Internet 208.
Ein Hörer empfängt die Anfrage, und reicht
sie durch einen Transport-Adapter an einen Versender weiter.
-
Der
Versender kommuniziert mit dem virtueller-Pfad-Manager 250, um die geeignete
Kartusche zum Behandeln der Anfrage zu bestimmen.
-
Jetzt
führt der
Versender eine von zwei Vorgängen
aus. Wenn der Versender von einer ungenutzten Instanz für diese
Kartusche weiß,
sendet der Versender die Anfrage zu dieser Instanz. Wenn es keine
ungenutzten Kartusche-Instanzen für diese Kartusche gibt, beauftragt
der Versender den Ressourcen-Manager 254, eine neue Kartusche-Instanz
zu erzeugen. Nachdem die Instanz erfolgreich hochläuft, benachrichtigt
die Kartusche den Ressourcen-Manager von ihrer Existenz. Der Ressourcen-Manager 254 benachrichtigt
daraufhin den Versender von der neuen Instanz. Der Versender erzeugt
eine auf der Browser-Anfrage basierende bearbeitete Anfrage, und
sendet die bearbeitete Anfrage an die neue Instanz.
-
Die
Kartusche-Instanz behandelt die bearbeitete Anfrage und sendet eine
Antwort an den Versender.
-
Der
Versender reicht die Antwort durch den Hörer zurück an den Client.
-
Diese
Stadien werden im Folgenden detaillierter beschrieben.
-
KARTUSCHEN
-
Kartuschen
sind Code-Module zum Ausführen
spezieller Applikations- oder System-Funktionen. Eine Kartusche
bildet die Basis-Verteilungs-Einheit im System 200. Gemäß einer
Ausführungsform
der Erfindung werden die Kartuschen unter Verwenden von Internet-Verweisadressen
("universal ressource
locators", URLs) mit
Namen versehen. Daher weist der Kartusche-Name zwei Teile auf: die
IP-Adresse des Servers, auf welchem die Kartusche angeordnet ist
und den virtuellen Pfad in der Server-Verzeichnis-Struktur des übersetzten ("compilierten") Kartusche-Codes.
Da Kartuschen unter Verwenden von URLs benannt sind, ist der Kartusche-Namen-Raum global,
und auf Kartuschen kann unter Verwenden der gleichen Benachrichtigungs-Techniken
("messaging techniques") zugegriffen werden,
welche zum Zugriff auf andere Web-Ressourcen, wie etwa auf Dokumente,
verwendet werden.
-
Gemäß einer
Ausführungsform
der Erfindung weist jede Kartusche eine Standard-Schnittstelle auf, welche
eine gemeinsame Gesamt-Struktur für alle Kartuschen zur Verfügung stellt.
Die Standard-Schnittstelle definiert die Schnittstelle aus Routinen,
welche unter speziellen Bedingungen von Web-Applikations-Server
280 aufgerufen
werden. Gemäß einer
Ausführungsform
ist die abstrakte Kartusche-Schnittstelle wie folgt definiert:
-
Die
init()-Routine ist für
das Initialisieren der Kartusche-Instanz verantwortlich. Dies kann
das Aufrufen der Konstruktoren von mehreren Unter-Objekten, das
Vor-Verzweigen ("preforking") von Threads und
das Verfügbarmachen
aller anderen benötigten
gemeinsam verwendeten Ressourcen beinhalten.
-
Die
shutdown()-Routine ist für
das Aufräumen
("cleaning up") aller Ressourcen
und das Herunterfahren ("shutting
down") der Kartusche-Instanz
verantwortlich. Sobald die shutdown()-Routine für eine Kartusche-Instanz aufgerufen
wird, wird sie sofort zum Bedienen nachfolgender Anfragen unerreichbar.
-
Die
authenticate()-Routine validiert, ob der Client, welcher die Dienste
der Kartusche anfragt, dazu autorisiert ist, diese Dienste zu verwenden.
-
Die
exec()-Routine ist der übliche
Weg, um alle Dienste-Anfragen der Kartusche abzufertigen.
-
BEISPIEL-KARTUSCHEN
-
Jede
Kartusche ist entweder als eine Kartusche konfiguriert, welche eine
wohldefinierte Funktion ausführt,
oder als eine programmierbare Kartusche, welche als ein Interpreter
agiert, oder als eine Routine-Umgebung für eine Applikation. Ein Beispiel
einer programmierbaren Kartusche ist eine PL/SQL-Laufzeit, welche derart
konfiguriert ist, dass sie Datenbank-Anfragen gemäß der Oracle-basierten
Programmiersprache unter Verwendung ("structured query language ", (PL/SQL)) verarbeitet.
Die PL/SQL-Laufzeit führt
eine Browser-Anfrage durch, welche eine Datenbank-Anfrage enthält. Die
PL/SQL-Laufzeit verarbeitet die Anfrage beispielsweise durch Zugreifen über eine
Daten-Verbindung
auf einen Datenbankserver in Kommunikation mit der Kartusche-Instanz.
-
Ein
anderes Beispiel einer programmierbaren Kartusche ist ein JAVA-Laufzeit-Interpreter.
Die JAVA-Laufzeit-Interpreter-Kartusche
ermöglicht
es Web-Applikations-Entwicklern,
Server-seitige JAVA-Applikationen zum Verarbeiten von Browser-Anfragen
zu schreiben. In ähnlicher
Weise kann ein maßgeschneiderter Server
als eine Kartusche konfiguriert werden, um dynamische Vorgänge, wie
beispielsweise das Zugreifen auf Prozesse zu ermöglichen, welche von einem Drittanbieter-Server
ausgeführt
werden.
-
VERSENDER
-
Versender
sind Software-Module, welche derart konfiguriert sind, dass sie
die von Hörern
empfangenen Anfragen zu den geeigneten Kartuschen zu verteilen ("to route"). Gemäß einer
Ausführungsform
der Erfindung sind Versender als Server-seitige Programm-Erweiterungen
(das heißt
Einschübe)
implementiert. Als solche werden die Versender in den gleichen Adressraum
geladen wie die Hörer,
zu denen sie gehören,
und auf diesen ausgeführt.
Die Versender können
beim Kompilieren mit dem Hörer-Code
gelinkt werden, oder zur Laufzeit dynamisch geladen werden.
-
In
der dargestellten Ausführungsform
sind Versender 214, 220 und 226 Hörern 210, 216 beziehungsweise 222 zugeordnet.
Versender 214, 220 und 226 verteilen
selektiv von Hörern 210, 216 beziehungsweise 222 empfangene
Browser-Anfragen
zu Kartuschen.
-
Beispielsweise
sei angenommen, dass Hörer 210 eine über das
Internet 208 gesendete Browser-Anfrage in Form eines "Uniform Resource
Locator" (URL) [Deutsch: "Internet-Verweisadresse"] empfängt. Die Browser-Anfrage
dient als ein Identifizierer für
ein Web-Objekt, beispielsweise eine HTML-Seite oder einen auszuführenden
Vorgang. Der Hörer 210 reicht
die Browser-Anfrage ohne irgendeinen Versuch, die Browser-Anfrage
zu interpretieren, an Versender 214 weiter. Auf das Empfangen
der Browser-Anfrage hin führt
der Versender 214 durch:
- (1) Kommunizieren
mit dem Virtueller-Pfad-Manager 250, um die durch die Browser-Anfrage
ausgewählte Kartusche
zu identifizieren, und um zu ermitteln, ob die Kartusche Authentifizierung
benötigt,
- (2) falls die Kartusche Authentifizierung benötigt, Kommunizieren
mit dem Authentifizierungs-Server 252, um zu bestimmen,
ob dem Browser der Zugriff auf die ausgewählte Kartusche erlaubt ist.
- (3) falls der Zugriff erlaubt ist, Kommunizieren mit dem Ressourcen-Manager,
um die spezifische Instanz für
die ausgewählte
Kartusche zu bestimmen, zu welcher die Browser-Anfrage gesendet werden soll, und
- (4) Erzeugen und Versenden einer bearbeiteten Browser-Anfrage zum Ausführen durch
die spezifizierte Kartusche-Instanz
der Kartusche.
-
Die
bearbeitete Browser-Anfrage packt die in der Original-Browser-Anfrage
empfangene Information neu. Die überarbeitete
Browser-Anfrage kann beispielsweise ein Kontext-Objekt enthalten,
welches für
das ordnungsgemäße Arbeiten
der Kartusche benötigte
Daten enthält.
Die für
das ordnungsgemäße Arbeiten
der Kartusche benötigten
Daten können
beispielsweise eine Transaktions-ID enthalten, welche eine Transaktion identifiziert,
mit welcher die Browser-Anfrage assoziiert ist.
-
Wenn
die Kartusche auf die Anfrage antwortet, sendet die Kartusche die
Antwort zu dem Versender, und der Versender reicht die Antwort zum Übertragen
an den Browser, der die Anfrage gestartet hat, an dem Hörer weiter.
-
KONFIGURATIONS-BEREITSTELLER
-
Gemäß einer
Ausführungsform
der Erfindung werden Kartuschen, welche zusammen mit Web-Applikations-Server 280 zu
verwenden sind, zuerst bei Web-Applikations-Server 280 registriert.
Während
des Registrier-Prozesses wird Information über die Kartuschen an den Konfigurations-Bereitsteller 256 geliefert.
Konfigurations-Bereitsteller 256 speichert die Information
als Metadaten 258 zum späteren Zugriff durch die Komponenten
des Web-Applikations-Servers 280.
-
Die
Metadaten 258 können
beispielsweise aufweisen:
- (1) den Kartusche-Name;
- (2) die Minimalzahl benötigter
Instanzen;
- (3) die Maximalzahl benötigter
Instanzen;
- (4) den Ort ("location") des Codes, welcher
die Instanz implementiert;
- (5) die von dem Kartusche-Ausführ-Werkzeug zum Ausführen der
Rückruf-Funktionen
("callback functions") (Initialisieren,
Anfrage-Behandler, Herunterfahren) verwendeten Programm-abhängigen Funktions-Namen;
- (6) die Liste der Maschinen zum Ausführen der Kartusche;
- (7) die Leerlauf-Zeit ("idle
time") für die Kartusche
(den Zeitraum, welchen Kartuschen im Leerlauf bleiben dürfen, bevor
sie heruntergefahren werden);
- (8) einen Objekt-Identifizierer; und
- (9) Daten, welche den Typ des mit der Kartusche zu verwendenden
Authentifikations-Dienstes angeben, falls ein solcher zu verwenden
ist.
-
Der
Objekt-Identifizierer spezifiziert die Daten, welche von einer Browser-Anfrage
zum Anfordern des Ausführens
eines Vorganges durch die zugehörige
Kartusche zur Verfügung
gestellt werden müssen.
Der Objekt-Typ kann ein spezifisches Wort sein, eine URL, oder kann
einen virtuellen Pfad enthalten, wie etwa "/java".
-
Sobald
der Konfigurations-Bereitsteller 256 die Konfigurations-Information
für eine
spezifische Kartusche in den Metadaten 258 gespeichert
hat, wird die Kartusche automatisch registriert, wenn Web-Applikations-Server 280 gestartet
wird.
-
Nachdem
die Kartusche beim Web-Applikations-Server 280 registriert
ist, startet Ressourcen-Manager 254 die Minimalzahl von
Instanzen für
die Kartusche. Sobald die Minimalzahl von Instanzen gestartet ist, ist
Web-Applikations-Server 280 darauf
vorbereitet, Browser-Anfragen
zu beantworten.
-
DER VIRTUELLER-PFAD-MANAGER
-
Wie
oben angegeben, kommunizieren Versender mit dem Virtueller-Pfad-Manager 250,
um zu bestimmen, wohin jede bearbeitete Browser-Anfrage geleitet
wird. Insbesondere enthält
jede Browser-Anfrage üblicherweise
eine URL. Auf das Empfangen einer Browser-Anfrage hin sendet der
Versender die URL aus der Anfrage zum Virtueller-Pfad- Manager 250.
Der Virtueller-Pfad-Manager 250 antwortet durch Senden
der Versender-Daten, welche die mit der URL assoziierte Kartusche – wenn es
eine solche gibt – identifizieren.
-
Um
die benötigte
Information an Versender zu liefern, konsultiert der Virtueller-Pfad-Manager 250 die Metadaten 258,
welche URLs an Kartuschen zuordnen. In Antwort auf das Empfangen
einer Browser-Anfrage verwendet der Virtueller-Pfad-Manager 250 die Zuordnungs-Daten,
um die Kartusche zu bestimmen, falls es eine solche gibt, welcher
die in den Browser-Anfragen enthaltene URL zugeordnet ist.
-
Wenn
beispielsweise die Browser-Anfrage eine mit dem virtuellen Pfad "/java" beginnende URL ist, kann
die Zuordnung anzeigen, dass die JAVA-Interpreter-Kartusche konfiguriert
ist, um Anfragen zu behandeln, welche den virtuellen Pfad "/java" aufweisen.
-
Gemäß einer
Ausführungsform
der Erfindung bestimmt der Virtueller-Pfad-Manager 250 auch,
ob die mit der Kartusche assoziierte URL Authentifizierung benötigt. Falls
die Kartusche Authentifizierung benötigt, zeigt der Virtueller-Pfad-Manager 250 in
der Antwort an, dass der Virtueller-Pfad-Manager 250 dem Versender mitteilt,
dass Authentifizierung benötigt
wird. Wenn Authentifizierung nicht benötigt wird, erzeugt und sendet der
Versender eine bearbeitete Browser-Anfrage an eine Instanz der Kartusche,
ohne den Authentifizierungs-Server 252 aufzurufen. Wenn
Authentifizierung benötigt
wird, sendet der Versender die bearbeitete Anfrage erst dann an
eine Instanz der Kartusche, wenn der Authentifizierungs-Server anzeigt,
dass die bearbeitete Anfrage an eine Instanz der Kartusche übermittelt
werden darf.
-
DER RESSOURCEN-MANAGER
-
Der
Ressourcen-Manager 254 des Web-Applikations-Servers 280 steuert
das Ausführen
jeder der Kartuschen durch Starten einer vorbestimmten Minimalzahl
von Instanzen für
die Kartuschen, Last-Ausgleichen zwischen den Instanzen jeder Kartusche
und, falls nötig,
Starten neuer Kartusche-Instanzen
der Kartuschen, bis zur vorbestimmten Maximalzahl von Instanzen
für eine
gegebene Kartusche.
-
Es
sei beispielsweise angenommen, dass die Metadaten für eine spezielle
Kartusche (C1) die folgende Information enthalten:
Name=C1
Instanzen-Minimalzahl=10
Instanzen-Maximalzahl=50
Host-Maschinen=M1,
M2, M3
Leerlauf-Zeit = 30 Sekunden
-
Wenn
Kartusche C1 basierend auf diesen Metadaten erstmals registriert
wird, wird der Ressourcen-Manager 254 zehn Instanzen von
C1 starten. Ressourcen-Manager 254 wird die zehn Instanzen
auf den mit den Markierungen ("labels") M1, M2 und M3 versehenen
Maschinen starten.
-
Auf
das Empfangen von Versender-Anfragen zum Zugriff auf C1 hin bestimmt
Ressourcen-Manager 254, ob irgendeine existierende Instanz
von C1 zum Verwenden verfügbar
ist. Wenn beim Empfangen einer Anfrage keine Instanz von C1 verfügbar ist,
bestimmt Ressourcen-Manager 254, ob bereits die Instanzen-Maximalzahl
von C1 läuft.
Wenn die Instanzen-Maximalzahl
noch nicht läuft,
startet der Ressourcen-Manager 254 eine
neue Instanz von C1 auf einer der zur Verfügung stehenden Host-Maschinen,
und übermittelt
eine Nachricht, welche die neue Instanz gegenüber dem Versender identifiziert,
welcher die Anfrage ausgegeben hatte. Wenn bereits die Maximalzahl
von C1-Instanzen läuft,
sendet Ressourcen-Manager 254 eine Nachricht an den Versender,
der die Anfrage ausgegeben hatte, um anzuzeigen, dass die Anfrage
derzeit nicht behandelt werden kann.
-
LAST-AUSGLEICHEN
-
Gemäß einer
Ausführungsform
der Erfindung wendet Ressourcen-Manager 254 einen Satz
von Last-Ausgleich-Regeln an, um zu bestimmen, wo Instanzen zu starten
sind, wenn es mehr als eine mögliche Host-Maschine
gibt. In dem obigen Beispiel sind daher M1, M2 und M3 alle in der
Lage, Instanzen von Kartusche C1 auszuführen. Wenn M1, M2 und M3 die
gleiche Verarbeitungs-Kapazität
aufweisen, kann es wünschenswert
sein, die Instanzen gleichmäßig auf
die drei Maschinen zu verteilen. Wenn allerdings M1 die zehnfache
Verarbeitungs-Leistung wie M2 und M3 aufweist, kann es wünschenswert
sein, alle Instanzen bis zu einem gewissen Punkt auf M1 zu starten,
und dann zusätzliche
Instanzen gleichmäßig über M1,
M2 und M3 zu verteilen.
-
Um
Ressourcen-Manager 254 beim Festlegen, wie der Last-Ausgleich zwischen
möglichen
Maschinen auszuführen
ist, zu unterstützen,
können
die für
jede Kartusche gespeicherten Metadaten zusätzliche Details enthalten.
Beispielsweise können
die Metadaten eine separate Minimum-Instanzenzahl und Maximum-Instanzenzahl
für jede
Maschine spezifizieren. Ressourcen-Manager 254 kann dann
basierend darauf, welche Maschine das niedrigste Verhältnis zwischen
aktuellen Instanzen und maximaler Instanzenzahl aufweist, neue Instanzen
unter den Maschinen aufteilen.
-
Die
Metadaten können
auch eine Reihenfolge für
die Maschinen spezifizieren, welche eine Kartusche laufen lassen
können.
Die Maschine an der Position (N+1) der Reihenfolge wird nur verwendet,
um Instanzen der Kartusche auszuführen, wenn die Maschinen an
der N-ten Position der Reihenfolge bereits ihre Instanzen-Maximalzahl
ausführen.
-
STATUS-NACHVERFOLGUNG
DER KARTUSCHE-INSTANZEN
-
Gemäß einer
Ausführungsform
der Erfindung unterhält
Ressourcen-Manager 254 Status-Information, um die erzeugten
Kartusche-Instanzen nachzuverfolgen. Die Status-Information enthält Daten,
welche die Instanz identifizieren, die die Instanz ausführende Maschine
identifizieren, und den Hörer
identifizieren, dem die Instanz zugeordnet worden ist.
-
5 zeigt
eine Tabelle 500, welche vom Ressourcen-Manager 254 unterhalten werden
kann, um diese Zustand-Information
zu speichern. Tabelle 500 enthält eine Instanz-Spalte 502,
eine Kartusche-Spalte 504, eine Hörer-Spalte 506 und
eine Maschine-Spalte 508. Jede Zeile von Tabelle 500 korrespondiert
zu einer gesonderten Kartusche-Instanz. Innerhalb der Zeile für eine gegebene
Kartusche-Instanz identifiziert Kartusche-Spalte 504 die
mit der Kartusche-Instanz
assoziierte Kartusche, und Instanz-Spalte 502 zeigt die
Instanz-Nummer der Kartusche-Instanz an. Beispielsweise korrespondiert
Zeile 510 mit einer Instanz von Kartusche C1. Daher zeigt
Kartusche-Spalte 504 von Zeile 510 Kartusche C1
an. Instanz-Spalte 502 von Zeile 510 zeigt an,
dass die mit Zeile 510 assoziierte Kartusche-Instanz die
Instanz 1 von Kartusche C1 ist.
-
Hörer-Spalte 506 bezeichnet
den Hörer,
welchem die mit einer Zeile assoziierte Kartusche-Instanz zugeordnet
ist.
-
Maschinen-Spalte 508 bezeichnet
die Maschine, auf der die mit einer Zeile assoziierte Kartusche-Instanz
ausgeführt
wird. Beispielsweise ist die mit Zeile 510 assoziierte
Kartusche-Instanz dem Hörer 210 zugeordnet,
und wird auf Maschine M1 ausgeführt.
-
Ähnlich zu
Ressourcen-Manager 254 unterhält jeder Versender Status-Information über die
Kartusche-Instanzen, welche dem Hörer zugeordnet sind, mit welchem
der Versender verbunden ist. Solche Zustand-Information kann beispielsweise
in einer Tabelle 400 unterhalten werden, wie sie in 4 gezeigt
ist. Ähnlich
zu Tabelle 500 enthält
Tabelle 400 eine Instanz-Spalte 402 und eine Kartusche-Spalte 404,
welche Instanz-Zahlen beziehungsweise Kartusche-Identifizierer halten.
Während
allerdings Tabelle 500 nur einen Eintrag für jede von
Ressourcen-Manager 254 zugewiesene Kartusche-Instanz aufweist,
enthält
Tabelle 400 nur Einträge
für Kartusche-Instanzen,
welche einem speziellen Hörer
zugeordnet worden sind. Beispielsweise enthält Tabelle 400 nur
für diejenigen
in Tabelle 500 aufgelistete Kartusche-Instanzen Einträge, die
dem Hörer 210 zugeordnet
worden sind.
-
Über Instanz-Spalte 402 und
Kartusche-Spalte 404 hinaus enthält Tabelle 400 eine
Status-Spalte 406. Für
jede Zeile hält
Status-Spalte 406 einen Wert, welcher den Status der mit
der Zeile assoziierten Instanz anzeigt. Beispielsweise zeigt die
Status-Spalte 406 von Zeile 408 an, dass Instanz
1 von Kartusche C1 derzeit beschäftigt
ist. In der dargestellten Ausführungsform
hält Status-Spalte 406 ein
Flag, welches anzeigt, dass eine Kartusche-Instanz entweder BESCHÄFTIGT ("BUSY") oder FREI ("FREE") ist. Die Bedeutung
des Kartusche-Status soll nun mit Bezug auf die Arbeitsweise des
Ressourcen-Managers 254 und der Versender 214 und 220 beschrieben
werden.
-
INTERAKTION
ZWISCHEN VERSENDERN UND DEM RESSOURCEN-MANAGER
-
Wie
oben beschrieben, kommunizieren die Versender mit Ressourcen-Manager 254,
wenn sie eine überarbeitete
Browser-Anfrage zu einer speziellen Kartusche senden müssen. Gemäß einer
Ausführungsform der
Erfindung bestimmen Versender zuerst, ob ihnen bereits eine Instanz
der geeigneten Kartusche (1) zugewiesen worden ist, und (2) verfügbar ist,
um die neue überarbeitete
Anfrage zu bearbeiten. Wenn dem Versender bereits eine geeignete
Kartusche-Instanz zugewiesen worden ist, und wenn diese derzeit
verfügbar
ist, um die neue, überarbeitete
Browser-Anfrage
zu verarbeiten, dann reicht der Versender die überarbeitete Browser-Anfrage
an die Kartusche-Instanz weiter, ohne mit Ressourcen-Manager 254 weiter
zu kommunizieren.
-
Es
sei beispielsweise angenommen, dass Hörer 210 eine Browser-Anfrage
empfängt,
welche gemäß dem Virtueller-Pfad-Manager 250 von
Kartusche C1 bearbeitet werden muss. Es sei ferner angenommen, dass
Tabelle 400 die derzeitige Liste und den derzeitigen Status
von dem Hörer 210 zugeordneten
Kartusche-Instanzen wiedergibt.
-
Auf
das Empfangen der Browser-Anfrage von Hörer 210 hin inspiziert
Versender 214 die Tabelle 400, um eine FREI-Instanz von C1 zu
lokalisieren. In der dargestellten Tabelle 400 gibt Zeile 410 an,
dass Instanz 3 von Kartusche C1 derzeit FREI ist. Daher reicht Versender 214 eine
bearbeitete Browser-Anfrage direkt an Instanz 3 von Kartusche C1
durch, ohne mit Ressourcen-Manager 254 weiter zu kommunizieren.
In Antwort auf das Senden der bearbeiteten Browser-Anfrage ändert Versender 214 den Status-Wert
in Status-Zeile 406 von Zeile 410 auf BESCHÄFTIGT ("BUSY").
-
Wenn
einem Hörer
noch keine geeignete, derzeit verfügbare Kartusche-Instanz zugewiesen
worden ist, fordert der mit der Kartusche assoziierte Versender
eine Kartusche-Instanz
vom Ressourcen-Manager 254 an. Wenn der Ressourcen-Manager 254 feststellt,
dass keine Instanz der benötigten
Kartusche verfügbar
ist, und wenn die Anzahl existierender Instanzen der benötigten Kartusche
unter dem Maximum liegt, dann startet der Ressourcen-Manager 254 eine
neue Kartusche. Auf das Starten einer neuen Kartusche hin fügt der Ressourcen-Manager 254 einen
Eintrag für
eine neue Kartusche-Instanz in Tabelle 500 ein.
-
Sei
beispielsweise angenommen, dass Hörer 210 eine Browser-Anfrage
empfängt,
welche von Kartusche C3 verarbeitet werden muss. Sei ferner angenommen,
dass Instanz 3 von Kartusche C3 noch nicht gestartet worden ist.
Unter diesen Bedingungen sendet Versender 214 an Ressourcen-Manager 254 eine
Anfrage nach einem Handle für
eine Instanz von Kartusche C3. In Antwort auf diese Anfrage startet
Ressourcen-Manager 254 Instanz 3 von Kartusche C3 auf Maschine
M3. Darüber
hinaus fügt
Ressourcen-Manager 254 in Tabelle 500 den in Zeile 512 gefundenen
Eintrag ein.
-
Nach
Einsetzen von Zeile 512 für Instanz 3 von Kartusche C3
in Tabelle 500 sendet Ressourcen-Manager 254 ein
Handle auf die neu erzeugte Instanz zurück an Versender 214.
In Antwort auf das Empfangen dieses Handles fügt Versender 214 einen
Eintrag (Zeile 412) für
die neue Instanz in seine Status-Tabelle 400 ein. Der Versender 214 überträgt dann
eine überarbeitete
Browser-Anfrage zu Instanz 3 von Kartusche C3.
-
FREIGEBEN
VON KARTUSCHE-INSTANZEN
-
Gemäß einer
Ausführungsform
der Erfindung geben Hörer
nicht automatisch die Verfügungsberechtigung
("ownership") über Kartusche-Instanzen
nach Beenden des Antwortens auf offenstehende Browser-Anfragen wieder
frei. Beispielsweise sei angenommen, dass Instanz 3 von Kartusche
C3 eine überarbeitete Browser-Anfrage
empfängt,
die überarbeitete
Browser-Anfrage bearbeitet und eine Antwort an Versender 214 zurücksendet.
Versender 214 reicht die Antwort zum Zurücksenden
an den Browser, welcher die Browser-Anfrage ausgegeben hatte an
Hörer 210 weiter.
-
Jetzt
benötigt
Hörer 210 die
Verfügungsberechtigung über Instanz
3 von Kartusche C3 nicht länger. Allerdings ändert Versender 214 nur
die Status-Zeile 406 von Zeile 412 von BESCHÄFTIGT in
FREI, anstatt die Verfügungsberechtigung
von Instanz 3 von Kartusche C3 an Ressourcen-Manager 254 zurück zu übertragen.
-
Wechseln
des Wertes in Status-Spalte 406 von Zeile 412 in
FREI zeigt an, dass Instanz 3 von Kartusche C3 nicht länger an
einer Anfrage arbeitet, und daher bereit ist, nachfolgende Anfragen
zu bearbeiten. Da allerdings Tabelle 400, welche anzeigt,
dass Instanz 3 von Kartusche C3 verfügbar ist, von Versender 214 lokal gepflegt
wird, ist Instanz 3 von Kartusche C3 nur für nachfolgende Browser-Anfragen, welche
an Hörer 210 ankommen,
verfügbar.
Zeile 512 von der von Ressourcen-Manager 254 unterhaltenen
Tabelle 500 zeigt weiterhin an, dass Hörer 210 verfügungsberechtigt über Instanz
3 von Kartusche C3 ist.
-
Da
Hörer nicht
automatisch Kartusche-Instanzen jedes Mal freigeben, wenn eine Anfrage
bedient worden ist, wird mit Kommunikation zwischen dem Ressourcen-Manager 254 und
den verschiedenen Versendern einhergehender Zusatzaufwand ("overhead") wesentlich reduziert.
Sei beispielsweise angenommen, dass ein Hörer 210 zehn aufeinanderfolgende
Anfragen empfängt,
welche zu Kartusche C3 übertragen
werden müssen.
Anstatt mit Ressourcen-Manager 254 für jede der zehn Anfragen zu
kommunizieren, kann Versender 214 mit Ressourcen-Manager 254 in
Antwort auf die erste Anfrage kommunizieren. Die nachfolgenden neun
Anfragen können
von Versender 214 behandelt werden, ohne mit Ressourcen-Manager 254 zu
kommunizieren, da der Versender 214 zum Bearbeiten der
neun nachfolgenden Anfragen die gleiche Instanz C3 verwendet, welche
die erste Anfrage verarbeitet.
-
Während das
nicht-automatische Freigeben der Hörer-Verfügungsberechtigung
von Kartusche-Instanzen nach Bedienen jeder Anfrage die Effizienz
von Web-Applikations-Server 280 erhöhen kann,
können Hörer die
Verfügungsberechtigung über Kartusche-Instanzen
nicht unendlich aufrechterhalten. Beispielsweise sollten Instanzen,
welche er über
lange Zeiträume
nicht benutzt hat, an Ressourcen-Manager 254 zurücküberwiesen
werden, so dass sie erneut de-allokiert werden können, um Ressourcen freizugeben.
Es ist darüber hinaus
für einen
Hörer nicht
effektiv, Verfügungsberechtigung über die
Instanz einer Kartusche zu behalten, welche für eine relativ lange Zeit nicht
verwendet worden ist, wenn andere Hörer-Instanzen diese Kartusche anfordern.
-
Konsequenterweise übermittelt
Ressourcen-Manager 254 jedem Hörer eine maximale Leerlauf-Zeit für jede an
den Hörer
weitergegebene Kartusche-Instanz. Die maximale Leerlauf-Zeit gibt
den maximalen Zeitraum an, über
den eine Kartusche-Instanz ungenutzt bleiben kann, bevor der Hörer die
Verfügungsberechtigung
der Kartusche-Instanz freigeben muss. Sei beispielsweise angenommen,
dass Ressourcen-Manager 254 dem
Hörer 210 anzeigt,
dass der maximale Leerlauf-Zeitraum für Instanz 3 von Kartusche C3
10 Minuten beträgt.
Hörer 210 kann
basierend auf dieser Information damit fortfahren, Instanz 3 von
Kartusche C3 zu verwenden, um Browser-Anfragen von Kartusche C3
zu bearbeiten, solange Instanz 3 von Kartusche C3 nicht für länger als
10 Minuten im Leerlauf bleibt.
-
Wenn
Instanz 3 von Kartusche C3 für
mehr als 10 Minuten im Leerlauf bleibt, entfernt Versender 214 Zeile 412 aus
Tabelle 400 und sendet eine Nachricht an Ressourcen-Manager 254,
dass Hörer 210 die
Verfügungsberechtigung über Instanz
3 von Kartusche C3 freigibt. In Antwort auf diese Mitteilung aktualisiert
Ressourcen-Manager 254 Zeile 512, um anzuzeigen,
dass kein Hörer
eine Verfügungsberechtigung über Instanz 3
von Kartusche C3 hat, und dass diese daher einem anderen Hörer neu
zugewiesen werden kann, oder dass sie beendet werden kann.
-
Bei
einer alternativen Ausführungsform
geben Versender nicht automatisch Kartusche-Instanzen frei, wenn
die Leerlauf-Zeit für
die Kartusche-Instanz überschritten
ist. Stattdessen sendet der Versender eine Nachricht an Ressourcen-Manager 254 mit
dem Angebot, die nicht mehr verwendete Instanz freizugeben. Ressourcen-Manager 254 kann
auf das Angebot dadurch reagieren, dass er das Freigeben der Kartusche-Instanz
durch den Hörer
fordert, oder indem er dem Hörer
erlaubt, die Verfügungsberechtigung über die
ausgelaufene Kartusche-Instanz zu behalten.
-
Gemäß einer
Ausführungsform
der Erfindung unterhält
Ressourcen-Manager 254 eine Warteschlange der Anfragen,
welche nicht unmittelbar bedient werden können. Wenn es möglich wird,
eine Warteschlangen-Anfrage zu bedienen, wird die Anfrage von der
Warteschlange entfernt und bearbeitet. Sei beispielsweise angenommen,
dass Hörer 222 eine
Browser-Anfrage empfängt,
welche von Kartusche C1 verarbeitet werden muss, und dass Hörer 222 keine
Instanz von Kartusche C1 zugewiesen worden ist. Versender 226 sendet
eine Anfrage nach einer C1-Instanz an Ressourcen-Manager 254. Sei ferner angenommen,
dass ein Maximum von 50 C1-Instanzen erlaubt ist, und dass 50 C1-Instanzen
an Hörer 210 zugewiesen
worden sind. Unter diesen Bedingungen kann Ressourcen-Manager 254 die
Anfrage von Hörer 222 nicht
bedienen. Daher gibt Ressourcen-Manager 254 die Anfrage
in eine Warteschlange. Sobald Hörer 210 eine
Instanz von C1 freigibt, benachrichtigt Ressourcen-Manager 254 den
Hörer 222,
dass eine Instanz von C1 verfügbar
ist.
-
Unter
bestimmten Bedingungen kann Ressourcen-Manager 254 bevorrechtigterweise
einen Hörer veranlassen,
eine Kartusche-Instanz freizugeben. Beispielsweise kann Ressourcen-Manager 254 eine
System-Überlastungs-Situation
feststellen, und entweder vor oder nach Informieren der Hörer, welchen
derzeit die Kartusche-Instanzen zugewiesen worden sind, dass die
Kartusche-Instanzen beendet werden werden, durch Beenden eines Satzes
von Kartusche-Instanzen beantworten.
-
Ressourcen-Manager 254 kann
auch bevorrechtigterweise Hörer
veranlassen, Kartusche-Instanzen freizugeben, um Fairness-Verfahrensweisen
zwischen Hörern
zu implementieren. Beispielsweise kann Ressourcen-Manager 254 einen
Hörer,
welcher die meisten Instanzen einer gegebenen Instanz hält veranlassen, eine
Instanz der Kartusche freizugeben, wenn ein anderer Hörer auf
eine Instanz der Kartusche für
länger
als einen bestimmten Schwell-Zeitraum gewartet hat. Wenn beispielsweise
Hörer 210 von
Kartusche C1 50 Instanzen zugewiesen bekommen hat, und wenn C1 ein
Maximum von 50 Instanzen aufweist, dann kann Ressourcen-Manager 254 Hörer 210 veranlassen,
eine Instanz von C1 zehn Sekunden nach Empfangen einer auf eine
Instanz von C1 gerichteten Anfrage eines anderen Hörers freizugeben.
-
KARTUSCHE-AUSFÜHRWERKZEUGE
-
Gemäß einer
Ausführungsform
der Erfindung ist jede Instanz aus einem Kartusche-Ausführwerkzeug und
einer Kartusche zusammengesetzt. Ein Kartusche-Ausführwerkzeug
ist ein Code-Modul, welches Kartuschen gegenüber den Komplexitäten des
Web-Applikations-Servers 280 und dem Inter-Modul-Kommunikationsmechanismus
isoliert. Eine Kartusche wird einem Kartusche-Ausführwerkzeug
durch Speichern von Zeigern auf die Kartusche-Funktionen in eine
Funktions-Tabelle verfügbar
gemacht. Gemäß einer
Ausführungsform
stellen alle Kartuschen die in der oben beschriebenen beispielhaften
Kartusche-Schnittstelle spezifizierten Funktionen bereit. Indem
alle Kartuschen die gleiche Schnittstelle unterstützen, kann
mit allen Kartuschen ein einzelnes Standard-Kartusche-Ausführwerkzeug
verwendet werden.
-
Gemäß einer
Ausführungsform
der Erfindung sind Kartuschen als gemeinsam genutzte Bibliotheken ("shared libraries") implementiert,
und Kartusche-Ausführwerkzeuge
sind ausführbare
Programme, welche die Routinen in den gemeinsam verwendeten ("shared") Bibliotheken unter
Verwendung der Standard-Kartusche-Schnittstellen aufrufen. Das Kartusche-Ausführwerkzeug
stellt die Schnittstelle zwischen Kartuschen und dem Versender bereit,
leitet den Kartusche-Steuer-Fluss, und stellt Dienste zum Verwenden
durch Kartuschen bereit.
-
Wenn
der Ressourcen-Manager 254 das Erzeugen einer neuen Kartusche-Instanz
benötigt,
veranlasst der Ressourcen-Manager 254 das Instanziieren
eines Kartusche- Ausführwerkzeuges.
Daraufhin veranlasst die dadurch erzeugte Instanz des Kartusche-Ausführwerkzeugs,
dass die geeignete Kartusche instanziiert wird. Der Ressourcen-Manager 254 kann
das Kartusche-Ausführwerkzeug
veranlassen, instanziiert zu werden, beispielsweise durch Aufrufen
einer "Kartusche-Ausführwerkzeug-Fabrik", welche auf der
Maschine liegt, auf welcher die Kartusche auszuführen ist. Die Instanz des Kartusche-Ausführwerkzeugs
kann das Instanziieren der Kartusche, beispielsweise durch Ausführen eines
Aufrufes von einer der Routinen der gemeinsam verwendeten Bibliothek,
welche die Kartusche bildet, veranlassen.
-
Wie
in 2 gezeigt, weist der Web-Applikations-Server 280 Kartusche-Ausführwerkzeuge 228, 232 und 236 für jede der
Kartuschen 230, 234 beziehungsweise 238 auf.
Die Kartusche-Ausführwerkzeuge
steuern das Ausführen
von Instanzen der zugehörigen
Kartuschen durch Ausführen
von Kartusche-Aufrufen durch die Standard-Kartusche-Schnittstelle. Durch
Etablieren von grundlegenden Rückruf-Funktionen ("callback functions") zwischen dem Kartusche-Ausführwerkzeug
und einer Kartusche kann eine Kartusche in den Web-Applikations-Server 280 integriert
werden, indem die Kartusche zum Antworten auf die Rückruf-Funktionen
konfiguriert wird, und indem die Kartusche anschließend wie
oben beschrieben in dem Konfigurations-Bereitsteller 256 registriert
wird.
-
Wenn
daher der Versender 214 feststellt, dass die PL/SQL-Laufzeit-Kartusche
die geeignete Kartusche zum Bearbeiten einer Anfrage ist, sendet
Versender 214 die Anfrage zu einer Kartusche-Instanz, welche ein
mit der PL/SQL-Laufzeit-Kartusche assoziiertes Kartusche-Ausführwerkzeug
aufweist. Wenn eine neue Instanz initiiert werden muss, erzeugt
der Ressourcen-Manager 254 eine neue Instanz der PL/SQL-Laufzeit-Kartusche
in einem separaten Adress-Raum und sendet die Anfrage zu dem Kartusche-Ausführwerkzeug 228 der neuen
Instanz. Der zum Ausführen
der Instanz des Programmes verwendete Adressraum kann innerhalb
von Speicher des Computer-Systems liegen, auf welchem eine oder
mehrere der Komponenten von Web-Applikations-Server 280 ausgeführt werden,
oder auf einem anderen Computersystem.
-
In
Antwort auf eine Nachricht von einem Versender gibt das Kartusche-Ausführwerkzeug
eine Anfrage-Behandler-Rückruf-Funktion
an die Kartusche, wodurch die Kartusche veranlasst wird, die Anfrage
zu bearbeiten. Die die Anfrage bearbeitende Kartusche gibt das Ergebnis
an das Kartusche-Ausführwerkzeug
zurück,
welches das Ergebnis zum Versender weiterreicht. Falls der Web-Applikations-Server 280 einen
Fehler in dem Vorgang bemerkt, gibt das Kartusche-Ausführwerkzeug
eine Herunterfahr-Funktion der Kartusche aus.
-
Daher
stellt das Kartusche-Ausführwerkzeug
eine Anwendungs-Programmier-Schnittstelle zum Web-Applikations-Server 280 bereit,
welche vorbestimmte auszuführende
Vorgänge
spezifiziert. Das Verwenden der Standard-Kartusche-Schnittstelle ermöglicht es
Programmierern von den Kartuschen, jede Kartusche unabhängig von
den Protokollen, welche von dem betreffenden Web-Hörer, mit
welchem die Kartusche verwendet werden wird, verwendet werden, für Hohe-Ebene
Integration ("high
level integration")
in den Web-Applikatikons-Server 280 zu konfigurieren.
-
TRANSPORT-ADAPTER
-
Hörer ermöglichen
das Verwenden von Server-seitigen Einschüben ("plug-ins") mittels Bereitstellen einer Programmier-Schnittstelle
und eines Protokolls zum Verwenden durch solche Einschübe. Leider
variieren die von Hörern
bereitgestellen Programmier-Schnittstellen und Protokolle von Hörer zu Hörer. Beispielsweise sind
Netscape Server Application Programming Interface(NSAPI), Internet
Server Application Programming Interface (ISAPI) und Application
Development Interface (ADI) drei Beispiele von derzeit von Hörern bereitgestellten
unterschiedlichen Programmier-Schnittstellen.
-
Transport-Adapter
isolieren Versender von den von Web-Hörern
verwendeten Schutzrecht-geschützten
Protokollen und Schnittstellen. Insbesondere ist jeder Transport-Adapter
konfiguriert zum Erkennen der Protokolle der verchiedenen Hörer und
zum Konvertieren von von Hörern
empfangenen Browser-Anfragen in konvertierte Browser-Anfragen, welche
ein Standard-Versender-Protokoll aufweisen, welches von dem Protokoll
des Hörers
unabhängig
ist. In ähnlicher
Weise konvertieren Transport-Adapter die Antworten von Versendern
in das Transport-Protokoll der Hörer.
-
Daher
ermöglicht
der Transport-Adapter, dass der Web-Applikations-Server 280 von
verschiedenen Anbietern verwendet wird. Darüberhinaus können Transport-Adapter dazu
konfiguriert werden, verschiedene Server-Architekturen und Betriebssysteme
zu aufzuweisen.
-
BETRIEB DES
WEB-APPLIKATIONS-SERVERS
-
3A und 3B sind
ein Flussdiagramm, welches ein Verfahren zum Beantworten einer Browser-Anfrage
gemäß einer Ausführungsform
der Erfindung erläutert.
Die Browser-Anfrage
wird in Schritt 350 von einem Hörer empfangen. Zu Zwecken der
Erklärung
soll angenommen werden, dass die Browser-Anfrage von Browser 202 ausgegeben
und von Hörer 210 empfangen
wurde.
-
Auf
das Empfangen der Browser-Anfrage hin reicht in Schritt 352 der
Hörer 210 die
Anfrage an Web-Applikations-Server 280 weiter.
Insbesondere reicht Hörer 210 die
Anfrage unter Verwendung der Schutzrecht-geschützten Programmier-Schnittstelle
des Hörers 210 an
den Transport-Adapter 212 weiter. Falls
nötig,
konvertiert Transport-Adapter 212 die
Anfrage an Versender 214 unter Verwendung einer Standard-Versender-Programmier-Schnittstelle.
-
Versender 214 identifiziert
in Schritt 354 basierend auf dem in der Browser-Anfrage
spezifizierten virtuellen Pfad durch Kommunizieren mit dem virtueller-Pfad-Manager 250 den
Anfrage-Objekt-Typ, welcher zu der Browser-Anfrage korrespondiert.
Der Versender 214 bestimmt in Schritt 356, ob
der Anfrage-Objekt-Typ zu einer identifizierbaren Kartusche korrespondiert.
Falls der Anfrage-Objekt-Typ nicht zu einer identifizierbaren Kartusche
korrespondiert, wird die Anfrage in Schritt 358 zum Hörer 210 zurückgegeben
(siehe 3B). Falls in Schritt 358 der
Hörer 210 die
Anfrage als eine Anfrage nach einer statischen HTML-Seite erkennt,
greift der Hörer
auf die statische HTML-Seite zu und sendet in Schritt 360 die
HTML-Seite an Browser 202. Falls die Browser-Anfrage von
Hörer 210 nicht
erkannt wird, wird in Schritt 360 die Antwort an Browser 202 gesendet, welche
anzeigt, dass die Anfrage nicht erkennbar war.
-
Wenn
in Schritt 356 der Versender 214 feststellt, dass
(1) die Anfrage zu einer Kartusche gesendet werden muss, und (2)
dass dem Hörer 210 keine
derzeit FREI-en Instanzen dieser Kartusche zugewiesen worden sind,
dann kommuniziert Versender 214 mit dem Ressourcen-Manager 254,
um eine Instanz der Kartusche 230 zugewiesen zu bekommen,
an welche eine Browser-Anfrage gesendet werden kann. Wie in 3B gezeigt,
bestimmt in Schritt 362 der Ressourcen-Manager 254,
ob eine Instanz der identifizierten Kartusche unter der existierenden
Zahl von Instanzen verfügbar
ist (mit noch freier Verfügungsberechtigung).
-
Für die Zwecke
der Erklärung
soll angenommen werden, dass die Anfrage mit Kartusche 230 assoziiert
ist, und dass Kartusche 230 eine PL/SQL-Laufzeit-Kartusche
ist.
-
Falls
in Schritt 362 der Ressourcen-Manager eine verfügbare Instanz,
beispielsweise Instanz 260 der PL/SQL-Laufzeit 230 identifiziert,
informiert der Ressourcen-Manager 254 den
Versender 214, dass die Anfrage an Instanz 260 gesendet
werden sollte. Der Versender 214 erzeugt dann eine bearbeitete
Browser-Anfrage, und sendet diese in Schritt 368 an Kartusche-Ausführwerkzeug 228 von
Instanz 260, um die verfügbare
Instanz 260 zu veranlassen, die Anfrage zu verarbeiten,
wie unten beschrieben.
-
Falls
allerdings in Schritt 362 keine Instanz der Kartusche 230 verfügbar ist,
bestimmt in Schritt 364 der Ressourcen-Manager 254,
ob die existierende Anzahl an Instanzen eine vorgeschriebene Maximalzahl überschreitet.
Falls die existierende Anzahl von Instanzen die in Schritt 364 vorgeschriebene
Zahl überschreitet,
zeigt der Ressourcen-Manager 254 dem Versender 214 an,
dass die Anfrage derzeit nicht bearbeitet werden kann. In Antwort
hierauf gibt der Versender 214 die Anfrage in Schritt 358 an
den Hörer 210 zurück, wonach
der Web-Hörer 210 in
Schritt 360 über
das Netzwerk eine Antwort an Browser 202 sendet, um anzuzeigen,
dass die Anfrage nicht bearbeitet wurde.
-
Alternativ
hierzu kann, wenn derzeit keine Kartusche-Instanz verfügbar ist, um eine Anfrage zu
behandeln, Hörer 210 die
Anfrage auf eine Warte-Liste für
diese Kartusche-Instanz
setzen. Wenn eine Kartusche-Instanz verfügbar wird, wird die überarbeitete
Browser-Anfrage von der Warteliste entfernt und an die Kartusche-Instanz
weitergegeben. Falls die bearbeitete Browser-Anfrage für länger als
einen vorbestimmten Zeitraum auf der Warteliste verbleibt, kann
Hörer 210 die
Anfrage von der Warteliste entfernen und eine Nachricht an Browser 202 senden,
um anzuzeigen, dass die Anfrage nicht bearbeitet werden konnte.
-
Falls
in Schritt 364 die existierende Instanzen-Anzahl nicht
die vorgeschriebene Maximalzahl übersteigt,
startet Ressourcen-Manager 254 eine neue Instanz des identifizierten
Programms, und informiert den Versender 214, dass eine
auf der Browser-Anfrage basierende bearbeitete Browser-Anfrage zu
der neuen Instanz gesendet werden sollte. Der Versender 214 sendet
dann eine bearbeitete Browser-Anfrage an das Kartusche-Ausführwerkzeug
der neuen Instanz.
-
Beispielsweise
sei angenommen, dass der Ressourcen-Manager 254 in Antwort auf
die Browser-Anfrage Instanz 260 gestartet hat. Während der
Initialisierung wird auf die gespeicherten Sequenzen von Anweisungen
für die
PL/SQL-Laufzeit
zugegriffen, um in einem Adressraum, welcher von dem Adressraum,
in dem der Versender 214 ausgeführt wird, verschieden ist,
eine neue Instanz 260 der Kartusche 230 zu erzeugen. Gemäß einer
Ausführungsform
wird das Initialisieren aufgeführt
durch Laden des Kartusche-Ausführwerkzeugs 228 und
Veranlassen, dass das Kartusche-Ausführwerkzeug
die Initialisier-Routine der Kartusche 230 aufruft.
-
Sobald
die neue Instanz 260 läuft,
sendet der Versender 214 in Schritt 368 die Anfrage
zu dem mit der neuen Instanz 260 assoziierten Kartusche-Ausführwerkzeug 228.
-
Das
Kartusche-Ausführwerkzeug 228 sendet
zum Anfordern des Ausführens
der Anfrage eine Rückruf-Nachricht
("callback message") zu der neuen Instanz 260.
In der Rückruf-Nachricht
reicht das Kartusche-Ausführwerkzeug 228 für die Instanz 260 zum
Verarbeiten der Anfrage notwendige Parameter weiter. Solche Parameter
können
beispielsweise Passwörter,
Datenbank-Such-Schlüssel
oder andere Argumente für eine
von der Instanz 260 ausgeführte dynamische Operation sein.
-
Die
Instanz 260 verarbeitet dann die Anfrage. Während des
Ausführens
der Anfrage durch die Instanz in Schritt 368 beobachtet
der Versender 214 in Schritt 370 die Instanz,
um das Auftreten eines Fehlers festzustellen. Falls in Schritt 370 der
Versender 214 einen Fehler entdeckt, ruft der Versender 214 in
Schritt 372 das zugehörige
Kartusche-Ausführwerkzeug 228 auf,
um die fehlerhafte Instanz 260 zu beenden. Das zugehörige Kartusche-Ausführwerkzeug 228 gibt
daraufhin einen Herunterfahr-Befehl über das API an die fehlerhafte
Instanz. Die Instanz wird in Antwort auf den Herunterfahr-Befehl
von dem Kartusche-Ausführwerkzeug 228 heruntergefahren,
ohne irgendeinen anderen Prozess in irgendeinen anderem Adressraum
zu beeinflussen.
-
Falls
in Schritt 370 kein Fehler detektiert wird, empfängt in Schritt 374 der
Versender 214 eine Antwort von der Instanz 260 bei
Beenden der Ausführung.
Der Versender 214 reicht in Schritt 376 die Antwort
an den Hörer 210 weiter,
welcher dem Browser mit der Antwort von der ausgeführten Instanz 260 antwortet.
Nach dem Ausführen
der Instanz 260 hält
der Versender 214 in Schritt 378 die Instanz im
Speicher, wie in Schritt 378 gezeigt, um das Bearbeiten
einer nachfolgenden Anfrage zu ermöglichen.
-
VERTEILTE
ARCHITEKTUR DES WEB-SERVERS
-
Im
Wesentlichen kommunizieren die verschiedenen Komponenten des Web-Applikations-Servers 280 miteinander
mittels eines Kommunikations-Mechanismus, welcher es nicht benötigt, dass
die Komponenten im gleichen Adressraum oder sogar auf der gleichen
Maschine ausgeführt
werden. In der dargestellten Ausführungsform sind die Komponenten
des Web-Applikations-Servers 280 dazu
konfiguriert, durch einen Objekt-Anfrage-Vermittler ("Object Request Broker", ORB) 282 zu
kommunizieren. Objekt-Anfrage-Vermittler sind in "Common Object Request
Broker: Architecture and Specification (CORBA)" detailliert beschrieben. Dieses Dokument
und andere Dokumente mit Bezug zu CORBA können im World-Wide-Web unter http://www.omg.org
gefunden werden.
-
Während die
Ausführungsformen
der vorliegenden Erfindung mit Bezug auf Kommunikation durch einen
CORBA-konformen
ORB beschrieben werden, können
andere plattformübergreifende
Kommunikations-Mechanismen verwendet werden. Beispielsweise können als
Alternative die Komponenten von Web-Applikations-Server 280 mittels "Remote Procedure
Calls" (RPC) [Deutsch: "Entfernte-Prozedur-Aufrufe"], einer UNIX-Pipe
oder Microsoft COM kommunizieren.
-
Da
die verschiedenen Komponenten des Web-Applikations-Servers 280 miteinander
mittels Maschine-unabhängigen
Kommunikations-Mechanismen kommunizieren, gibt es keine inhärenten Beschränkungen bezüglich der
Anordnung der Komponenten zueinander. Beispielsweise können die
Hörer 210, 216 und 222 auf
der gleichen Maschine ausgeführt werden,
oder auf drei vollständig
verschiedenen Maschinen, jede mit einem anderen Betriebssystem.
In ähnlicher
weise können
der Authentizitäts-Server 252,
der Virtueller-Pfad-Manager 250,
der Ressourcen-Manager 254 und der Konfigurations-Bereitsteller 256 auf
der gleichen Maschine oder auf vier verschiedenen Maschinen ausgeführt werden.
Ferner ist es möglich,
dass diese vier Maschinen keinerlei Überlapp mit den drei Maschinen
aufweisen, welche die Hörer 210, 216 und 222 ausführen. Die
Kartusche-Ausführwerkzeuge 228, 232 und 236 beinhalten
die gesamte notwendige Logik, um durch den Objekt-Anfrage-Vermittler 282 mit
den anderen Komponenten des Web-Applikations-Servers 280 zu
kommunizieren. Daher ist der Ort der Kartusche-Instanzen selber
nicht inhärent
durch den Kommunikations-Mechanismus beschränkt. Daher kann Instanz 260 auf
einer vollständig
anderen Maschine und unter einem vollständig anderen Betriebssystem
ausgeführt
werden, als die Versender, von denen sie Anfragen erhält. In gleicher
Weise kann Instanz 260 auf einer anderen Maschine und unter
einem anderen Betriebssystem laufen als der Ressourcen-Manager 254 oder
irgendeine der anderen Komponenten des Web-Applikations-Servers 280, inklusive
Instanzen von anderen Kartuschen, welche von dem gleichen Web-Applikations-Server 280 gesteuert
werden.
-
Im
Wesentlichen wird die Ort-Unabhängigkeit,
derer sich die von Web-Applikations-Server 280 verwendeten
Kartuschen erfreuen, durch die Kommunikations-Logik des Kartusche-Ausführwerkzeugs
erreicht, nicht durch irgendeine maßgeschneiderte Programmierung
in den Kartuschen selber. Daher müssen die Kartuschen nicht speziell
für ein
Ausführen
in einer verteilte-Anwendung-Server-Umgebung ausgelegt sein. Kartusche-Entwickler
sind daher von den Komplexitäten
eines verteilten Systems isoliert, und können ihre Bemühungen auf
die mit den Aufgaben, für
die die Kartuschen erzeugt wurden, verbundene Logik konzentrieren.
-
Wie
oben beschrieben, ist ein Web-Applikations-Server 280 bereitgestellt,
welcher mehrere Instanzen von verschiedenen Kartuschen steuert,
um eine Vielzahl von Anwender-Anfragen zu bearbeiten. Jede Kartusche-Instanz
wird in einem von dem Hörer
getrennten Speicher-Raum ausgeführt,
wodurch die mit Server-seitigen Einschüben einhergehende Sicherheits-Probleme
vermieden werden. Ferner können
die Kartusche-Instanzen, welche verwendet werden, um die von einem
Hörer empfangenen
Browser-Anfragen zu bearbeiten, auf vollständig anderen Maschinen als
der Hörer
ausgeführt
werden. Daher erhöht
sich die Skalierbarkeit des Systems, während die Belastung der einzelnen
Maschinen reduziert wird.
-
Web-Applikations-Server 280 steuert
darüber
hinaus auch die Instanzenzahl für
jede gegebene Kartusche. Serverseitige Ressourcen werden gesteuert,
um sicherzustellen, dass eine große Zahl von Anfragen nicht
irgendeine Maschine durch ein unkontrollierbares Erzeugen von Instanzen überlastet.
-
Ferner
ist durch das Aufrechterhalten einer Minimalzahl von zum Ausführen bereiten
Instanzen auch der Ausführ-Durchsatz ebenfalls
verbessert. Zusätzliche
Instanzen können
gestartet werden und im Speicher aufrechterhalten werden, um nachfolgende
Anfragen auszuführen,
im Gegensatz zum Beenden einer Instanz nach einer einzelnen Ausführung und
erneutem Laden der Kartusche in den Speicher zum erneuten Erzeugen einer
Instanz zum Ausführen
einer nachfolgenden Anfrage.
-
In
der vorhergehenden Spezifikation wurde die Erfindung mit Bezug auf
spezielle Ausführungsformen hiervon
beschrieben. Es wird allerdings offensichtlich sein, dass vielfältige Modifikationen
und Änderungen
daran ausgeführt
werden können,
ohne von dem breiteren Schutzbereich der Erfindung abzuweichen.
Die Spezifikation und die Zeichnungen sind daher in einem erläuternden
Sinne, und nicht in einem einschränkenden Sinne zu verstehen.