-
Typischerweise verwendet ein Internetnutzer
einen Webbrowser, um mit einem Webserver zu kommunizieren. Beim
Verwenden des Webbrowsers gibt der Benutzer einen Einheitsressourcenlokator
(URL = Universal Resource Locator) ein. Danach sammelt der Computer
des Benutzers, der manchmal auch als „der Client" bezeichnet wird,
Anforderungen, die zu dem Webserver kommuniziert werden sollen,
und der Webbrowser sendet solche Anforderungen unter Verwendung
des URL, der durch den Benutzer eingegeben wird, an den Webserver.
Ein in der Technik gut akzeptierter Anforderungs- und Antwortformatierstandard
ist das Hypertextübertragungsprotokoll
(HTTP = Hypertext Transfer Protocol).
-
Auf den Empfang einer Anforderung
von dem Webbrowser hin verarbeitet der Webserver die Anforderung
und überträgt dann
eine Antwort zurück
an den Client. Es ist anzumerken, daß der Inhalt der Anforderung dem
Informationstyp entspricht, nach dem der Client sucht, und dadurch
die Schritte definiert, die durch den Webserver durchgeführt werden,
wenn er auf die Anforderung antwortet. Falls der Benutzer beispielsweise
einen spezifischen URL eingibt, der nur ein Bild oder eine HTML-Datei
anfordert (HTML = Hypertext Markup Language), sucht der Webserver
das Bild oder die Datei und sendet das Bild oder die Datei zurück an den
Client.
-
Zusätzlich zum Finden eines Bildes
oder einer Datei und Zurücksenden
desselben an den Client können
viele Anforderungen von Clienten den Webserver anweisen, eine andere
Aktion durchzuführen.
Beispielsweise kann eine Anforderung den Webserver anweisen, eine
Suche in einer Datenbank durchzuführen, und die Suchergebnisse
können
dann durch den Webbrowser angezeigt werden, der dem Client zugeordnet
ist. Traditionell verwendet ein Webserver eine CGI (CGI = Common
Gateway Interface = Gemeinsame Gateway-Schnittstelle), die Skripte
implementiert, die in Softwaresprachen geschrieben sind, beispielsweise
Perl oder C Programme. Mit dem Aufkommen von Java verarbeiten jedoch
kleine Programme, die auf dem Webserver laufen, die in der Technik
als „Servlets" bzw. serverseitige
Programme bezeichnet werden, Clientanforderungen, die zusätzliche
Aufgaben erfordern und senden Ergebnisse zurück an den Client.
-
Ein Servlet ist im allgemeinen eine
standardisierte Funktion, die Clientanforderungen empfängt und verarbeitet
und dadurch Antworten auf die Clientanforderungen erzeugt. Typischerweise
sind Servlets in JavaTM geschrieben, gemäß einem
Standard, der durch den JCP veröffentlicht
wird (JCP = Java Community Process), und dieselben sind entworfen,
um auf einem Webserver zu laufen. Der vorhergehende Servletstandard definiert
einfach eine einheitliche Grundlage, auf der Servlets zu entwerfen
und zu schreiben sind. Im allgemeinen ist es hauptsächlich die
Funktion von Servlets, eine Antwort auf eine Clientanforderung zu
erzeugen. Für
Webserver, die nicht entworfen sind, um Servlets laufen zu lassen,
gibt es Servletmaschinen, die heruntergeladen werden können, um
als ein Plug-In bzw. eine Programmerweiterung zu dienen, um es solchen
Servern zu ermöglichen,
Servlets laufen zu lassen. Somit können beinahe alle Webserver
Servlets laufen lassen oder können
modifiziert werden, um Servlets laufen zu lassen, um eine Webclient-/Serverkommunikation
zu ermöglichen.
-
Ein Servlet befindet sich typischerweise
in einem Servletbehälter,
der als eine Schnittstelle für
alle Servlets dient, die durch denselben umgeben sind. Ein Servletbehälter, beispielsweise
ein Apache Tomcat, ist typischerweise ein Programm, der ein Tor
einer Internetprotokolladresse (IP-Adresse) überwacht. Beim Überwachen
des Tors empfängt
der Servletbehälter
eine Anforderung für
das Servlet, die durch den Client gesendet wird. Bevor die Anforderung
zu dem Servlet weitergeleitet wird, analysiert der Servletbehälter die
Anforderung syntaktisch und bringt die syntaktisch analysierten
Informationen in ein Format, das mit dem Servlet kompatibel ist.
Der Servletbehälter
empfängt
auch eine Antwort, die durch das Servlet erzeugt wird und formatiert
die Antwort für
eine Rückübertragung
zu dem Client.
-
Die einheitlichen Charakteristika
des Servletbehälterstandards
und des Servletstandards liefern eine vorhersagbare Umgebung, in
der servletbasierte Anwendungen geschrieben werden. Genauer gesagt,
in der Technik gibt es zahlreiche Webserver, die sehr unterschiedlich
entworfen sind. Heute verwenden jedoch die meisten Webserver die
JavaTM-basierten Servletbehälter und
Servletstandards. Daher liefern die Servletbehälterschnittstelle und ihre
Interaktion mit dem Servlet unabhängig von dem verwendeten Webservertyp
eine Umgebung, die es ermöglicht,
daß Anwendungen
mit den meisten Webservern verwendet werden können.
-
Darüber hinaus bestehen in der
Technik auch Offenequellen-Such/Indexmaschinen,
wie z. B. die Lucene-Anwendungsprogrammschnittstelle (API = Application
Program Interface). Eine API ist im allgemeinen eine Zusammenstellung
von Tools, die ein Programmierer verwenden kann, um eine Anwendung
zu erzeugen, die über
einen großen
Bereich von Plattformen und Webservern verwendet werden kann. Daher
liefert die Lucene-API einem Programmierer Tools zum Erstellen eines
Datendepots durch Indexieren der Daten und Tools zum Durchsuchen
des Depots. Als solches kann ein Programmierer eine Anwendung erzeugen,
die datenspezifisch ist. Der Programmierer kann beispielsweise ein
Depot von Produkten erzeugen, einschließlich Produktbeschreibungen
und Preisen und der Programmierer kann dann eine Anwendung erzeugen
zum Liefern einer effizienten Suche in dem Produktdepot, beispielsweise
wenn ein Webnutzer einen Onlinekatalog betrachtet.
-
Es ist anzumerken, daß das Indexieren
ein Begriff der Technik ist, der sich auf Datendepotentwurf bezieht
und sich allgemein auf das Liefern einer Liste von Schlüsseln bezieht,
die verwendet werden, um Daten zu sortieren, von denen jede eine
eindeutige Aufzeichnung identifiziert. Eine Aufzeichnung bezieht
sich auf eine Sammlung von Daten, die in einem Depot gespeichert
werden soll. Die Indizes ermöglichen
es einer Anwendung, Daten, die in dem Depot gespeichert sind, auf
effizientere Weise zu finden.
-
Es ist die Aufgabe der vorliegenden
Erfindung, ein Serversystem, einen Webserver und einen Server zum
Liefern von Informationen bezüglich
von Serververkehr, ein Verfahren für die Verwendung in einem Webserver
und ein Computerprogramm mit verbesserten Charakteristika zu schaffen.
-
Diese Aufgabe wird durch ein System
gemäß Anspruch
1, ein Verfahren gemäß Anspruch
18, einen Webserver gemäß Anspruch
23, einen Server gemäß Anspruch
25, sowie ein Computerprogramm gemäß Anspruch 26 gelöst.
-
Im allgemeinen liefern Ausführungsbeispiele
der vorliegenden Erfindung ein System zum Liefern von Informationen
bezüglich
Serververkehr, das ein Servlet umfaßt, das sich in einem Servletbehälter befindet,
der konfiguriert ist, um eine Anforderung zu empfangen, die Anforderung
zu verarbeiten und ansprechend auf die Anforderung eine Antwort
zu formulieren, und eine Logik, die in dem Servletbehälter enthalten
ist, die konfiguriert ist, um die Anforderung zu empfangen und zu
indexieren, wobei die Logik konfiguriert ist, um die Anforderungen
von dem Servletbehälter
zu empfangen.
-
Ein Ausführungsbeispiel der vorliegenden
Erfindung kann ferner konzeptionell als ein Verfahren entworfen
sein, das die Schritte des Empfangens einer Anforderung in einem
Servletcontainer des Webservers, des Sendens der Anforderung von
einem Client zu einem Webserver, des Indexierens der Anforderung,
des Speicherns der Anforderung in einem Depot, des Formulierens
einer Antwort auf die Anforderung und des Sendens der Antwort an
den Client umfaßt.
-
Bevorzugte Ausführungsbeispiele der vorliegenden
Erfindung werden mit Bezugnahme auf die beiliegenden Zeichnungen
näher erläutert. Es
zeigen:
-
1 ein
Blockdiagramm, das ein Client-/Serversystem gemäß einem darstellenden Ausführungsbeispiel
der vorliegenden Erfindung darstellt;
-
2 ein
Blockdiagramm, das ein beispielhaftes Ausführungsbeispiel eines Serversystems
von 1 darstellt;
-
3 ein
Blockdiagramm, das ein detaillierteres Ausführungsbeispiel des Serversystems
von 2 darstellt; und
-
4 ein
Flußdiagramm,
das eine beispielhafte Architektur und Funktionalität eines
Serversystems darstellt, das in 2 dargestellt
ist.
-
Im allgemeinen beziehen sich die
Ausführungsbeispiele
der vorliegenden Erfindung auf ein webbasiertes Serversystem, das
ein Datendepot von Clientanforderungen und Serverantworten für automatische
oder manuelle Interaktionen liefert. Ein webbasiertes Serversystem
gemäß einem
beispielhaften Ausführungsbeispiel
der vorliegenden Erfindung umfaßt
ein Suchanforderungsfilter und ein Suchantwortfilter, die nicht
zwischen Webserver und Servletcontainer unterscheiden. Diesbezüglich können das
Suchanforderungsfilter und das Suchantwortfilter durch verschiedene
Typen von Webservern verwendet werden (d. h. Microsoftwebserver,
IBM-Webserver, kundenspezifische Webserver, usw.).
-
1 stellt
ein Client-/Serversystem 78 dar, das eine servletbasierte
Architektur verwendet, um eine Internetkommunikation zu ermöglichen.
Wie es in 1 angezeigt
ist, umfaßt
der Client 80 einen bekannten oder in der Zukunft entwickelten
Webbrowser 82, wie z. B. Netscape oder Internet Explorer.
Ein Benutzer (nicht gezeigt) gibt über ein Eingabegerät (nicht
gezeigt) einen URL in das Web 82 ein, oder ein automatischer
Mechanismus spezifiziert einen spezifischen URL, beispielsweise
in einem Hypertext-Link, der in einer HTML-Datei enthalten ist.
Der Client 80 sendet eine Anforderung 84, die
den spezifischen URL umfaßt,
an einen Webserver 90.
-
Der Webserver 90 umfaßt typischerweise
einen Servletbehälter 92,
der ein Servlet 94 umfaßt. Wie es hierin oben beschrieben
ist, bezieht sich ein Servlet auf ein Programm, das Clientanforderungen
empfängt,
die Anforderungen verarbeitet und Antworten bezüglich der Anforderungen zurück an den
anfordernden Client sendet. Der Webserver 90 in 1 umfaßt ferner die Lucene-API 96,
die sich in dem Servletbehälter 92 befindet
und verwendet werden kann, um Datendepots zu erzeugen, die über Anforderungen
durch das Servlet 94 durchsucht werden können.
-
Ein webbasiertes Serversystem gemäß einem
beispielhaften Ausführungsbeispiel
der vorliegenden Erfindung ist in 2 dargestellt,
und wird im allgemeinen hierin als Clientserversystem 150 bezeichnet.
Das System 150 von 2 umfaßt einen
Client 102 und einen Webserver 152, die durch
das Netzwerk 103 kommunizieren. Der Client 102 umfaßt einen
Webbrowser 104, und der Webserver 152 umfaßt einen
Servletbehälter 114,
der eine Lucene-API 116, ein Servlet 118 und ein
Anforderungs-/Antwortdepot 122 umfaßt.
-
Die Lucene-API 116 von 2 liefert einen Mechanismus,
durch den ein Datensatz, beispielsweise Produktdaten, die einem
Onlinekatalog zugeordnet sind, in eine suchbare Form umgewandelt
werden können und
in einem Depot 122 gespei chert werden können. Das Depot 122 kann
eine strukturierte Datenbank umfassen, oder in dem Fall der Lucene-API 116 kann
das Depot 122 ein Verzeichnis sein, das Dateien enthält, die
die gespeicherten Daten anzeigen.
-
Sobald Daten gespeichert werden,
können
die Daten durch den Client 102 gesucht und von dem Depot 122 wiedergewonnen
werden. Diesbezüglich
kann ein Benutzer (nicht gezeigt) eine Suche und Wiedergewinnung
einleiten, über
ein Suchformular, das durch den Webbrowser 104 angezeigt
wird oder eine Suche und Wiedergewinnung kann durch eine andere
Suchmaschine oder durch eine Anforderung von einem Hyperlink, der
in einer Webseite enthalten ist, automatisch durchgeführt werden.
Es ist anzumerken, daß ein
Datendepot 122 verschiedene Formen annehmen kann. Ein Depot
kann beispielsweise eine strukturierte Datenbank sein oder es könnte eine
Dateistruktur sein, die auf einem Server gespeichert ist.
-
Bei dem beispielhaften Ausführungsbeispiel
von 2 stellt der Client 102 eine
Anforderung zusammen und sendet die Anforderung 106 über das
Netzwerk 103 an den Webserver 152. Der Client 102 kann
die Anforderung auf der Basis eines URL zusammenbauen, der in den
Webbrowser 104 eingegeben wird, oder der Client 102 kann
die Anforderung auf der Basis eines automatischen Prozesses zusammenstellen,
beispielsweise kann ein Hyperlink in einem HTML-Dokument, der durch
einen Benutzer ausgewählt
wird, auch bewirken, daß der
Client 102 eine Anforderung zusammenstellt und die Anforderung
an den Webserver 152 sendet.
-
Der Webserver 152 empfängt die
Anforderung von dem Client 102 und sendet die Anforderung
an den Servletbehälter 114.
Der Servletbehälter 114 analysiert
die Anforderung syntaktisch, bringt die Anforderung in ein Format,
das mit dem Servlet 118 kompatibel ist, und dann sendet
der Servletbehälter 114 die
Anforderung an das Servlet 118. Das Servlet 118 verarbeitet
die Anforderung und sendet eine Antwort an den Servletbehälter 114.
Der Servletbehälter 114 sendet
die Anforderung an den Webserver 152, der die Antwort 120 an
den Client 102 sendet.
-
Während
dem Prozeß des
Empfangens der Anforderung, des Verarbeitens der Anforderung und
Sendens einer Antwort zurück
an den Client ist der Webserver 152 konfiguriert, um ein
Depot 122 zu erzeugen, das eine durchsuchbare Zusammenstellung
von Daten umfaßt,
die Anforderungen anzeigen, die durch das Servlet 118 empfangen
werden und Antworten anzeigt, die durch das Servlet 118 formuliert
werden. Es ist anzumerken, daß die
Daten, die die Anforderungen und Antworten anzeigen, verschiedene
Formen annehmen können.
Diesbezüglich
kann die Zusammenstellung von Daten Aufzeichnungen umfassen, die
alle Daten enthalten, die in der Anforderung oder der Antwort enthalten
sind, oder die Zusammenstellung von Daten kann Aufzeichnungen umfassen,
die nur einen ausgewählten
Teil der Antwort enthalten (d. h. eine Aufzeichnung in dem Depot
kann nur eine ausgewählte
Anzahl von Feldern von der Antwort mit ihren entsprechenden Werten umfassen).
Der Webserver 152 kann konfiguriert sein, um eine Zusammenstellung
aller Anforderungen und Antworten zu erzeugen, die auf dem Webserver 152 verarbeitet
werden, oder er kann konfiguriert sein, um ein Depot 122 von
nur einem speziellen Typ von Anforderung oder Antwort zusammenzustellen.
Beispielsweise kann eine HTTP-Anforderung einen GET-Befehl oder
einein PUT-Befehl umfassen, und der Webserver 122 kann
nur konfiguriert sein, um ein Depot 122 der Daten zusammenzustellen,
die die Anforderungen anzeigen, die einen GET-Befehl umfassen. Bei
anderen Ausführungsbeispielen
kann der Webserver 152 konfiguriert sein, um ein Depot 122 der
Daten zusammenzustellen, die die Anforderungen anzeigen, die von
einer speziellen Quell- oder IP-Adresse
stammen.
-
Die Daten, die durch den Webserver 152 in
dem Depot 122 zusammengestellt werden, können dann durchsucht
werden und durch den Client 102 präsentiert werden. Es ist anzumerken, daß die Präsentation
in jedem bekannten Format sein könnte
(d. h. HTML oder XML (Extensible Markup Language)). Somit wird eine Interaktion
sowohl durch Mensch als auch Maschine vorzugsweise vermieden. Solche
Zugriffs- und Suchefähigkeiten
geben einem Benutzer die Fähigkeit,
Informationen zu entdecken, die sich auf den Webserververkehr beziehen,
wie z. B. Informationen, die die Webserverleistungsfähigkeit
oder andere Informationen von Benutzerinteresse anzeigen. Die Suche
und Präsentation
wird vorzugsweise durch einen Such/Indexmechanismus geliefert, beispielsweise
die Lucene-API 116.
Als ein Beispiel können
Clientanforderungen Informationen oder Daten enthalten, die eine
spezielle HTML-Datei
identifizieren, die durch einen Benutzer angefordert wurde, wobei
das Depot 122 konfiguriert sein kann, um dieselbe beizubehalten.
Der Benutzer könnte
dann die Informationen verwenden, die sich auf eine spezifische
HTML-Datei beziehen,
die angefordert wurde, um die Verkehrsmenge bezüglich einer einzigen HTML-Datei
zu bestimmen.
-
Um auf die Daten zuzugreifen, die
in dem Depot 122 enthalten sind, kann der Webserver 152 eine Suchseite
an den Client 102 senden, die in dem Webbrowser 104 angezeigt
wird. Die Suchseite umfaßt
vorzugsweise zumindest ein Textfeld zum Eingeben einer Suchzeichenfolge,
die sich auf den Datentyp bezieht, auf das ein Benutzer in dem Depot
eventuell zugreifen möchte.
Wenn ein Benutzer eine Suchzeichenfolge eingibt, stellt der Client 102 vorzugsweise
eine Anforderung zusammen und sendet die Anforderung an den Webserver 152.
Die Suchzeichenfolge kann dann durch das Servlet 118 verwendet
werden, um von dem Depot 122 die Aufzeichnungen wiederzugewinnen,
die mit der Zeichenfolge übereinstimmen,
die durch den Benutzer eingegeben wurde, und die Antwort zu formulieren,
die der Webserver 152 an den Client 102 sendet.
Beispielsweise kann ein Systemadministrator daran interessiert sein,
die Anzahl von Malen zu bestimmen, die eine spezielle HTML-Datei,
die eine spezielle Seite definiert, von dem Webserver 152 angefordert
wird. Um diese Informationen zu entdecken, kann der Systemadmini strator
den Namen der HTML-Datei in eine Suchseite eingeben, die in dem
Webbrowser 104 angezeigt ist. Der Webserver 122 durchsucht
dann das Depot 122 und sendet Ergebnisse zurück an den
Client 102.
-
23 stellt
ein beispielhaftes Ausführungsbeispiel
eines Computersystems 200 dar, das verwendet werden kann,
um den Webserver 213 zu implementieren, und den Servletbehälter 214,
der sich in demselben befindet. Wie es durch 3 gezeigt ist, umfaßt das System 200 ein
Suchanforderungsfilter 218 und ein Suchantwortfilter 219 und
wird insgesamt im allgemeinen als ein „Webserversystem 200" bezeichnet. Es ist anzumerken,
daß das
Suchanforderungsfilter 218, das Suchantwortfilter 219,
das Servlet 220 und das Lucene-Filter 222 vorzugsweise in
Software implementiert sind und im Speicher 212 gespeichert
sind, wie es in 3 gezeigt
ist. Die vorhergehenden Komponenten können jedoch auch in Hardware,
Software oder einer Kombination derselben implementiert sein.
-
Wenn die Komponenten des Webservers 213 in
Software implementiert sind, ist anzumerken, daß dieselben auf jedem computerlesbaren
Medium gespeichert und transportiert werden können, für die Verwendung durch oder
in Verbindung mit einem Befehlsausführungssystem, einer solchen
Vorrichtung oder einem solchen Gerät, wie z. B. einem computerbasiertem
System, einem prozessorenthaltenden System oder einem anderen System,
das die Befehle von dem Befehlsausführungssystem, der Befehlsausführungsvorrichtung
oder dem Befehlsausführungsgerät abrufen
kann und die Befehle ausführen
kann. Im Zusammenhang dieses Dokuments kann ein „computerlesbares Medium" jede Einrichtung
sein, die das Programm enthalten, speichern, kommunizieren, ausbreiten
oder befördern
kann, für
die Verwendung durch oder in Verbindung mit dem Befehlsausführungssystem,
der Vorrichtung oder dem Gerät.
Das computerlesbare Medium kann beispielsweise, ist aber nicht darauf
beschränkt,
ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder
Halbleitersystem, eine solche Vorrichtung, ein solches Gerät oder ein
solches Ausbreitungsmedium sein. Es ist anzumerken, daß das computerlesbare
Medium selbst Papier oder ein anderes geeignetes Medium sein kann,
auf dem das Programm gedruckt wird, da das Programm elektronisch
erfaßt
werden kann, beispielsweise über
optisches Abtasten des Papiers oder anderen Mediums, dann zusammengestellt,
interpretiert oder anderweitig verarbeitet auf geeignete Weise,
falls dies notwendig ist, und dann in einem Computerspeicher gespeichert
werden. Als ein Beispiel können
die Komponenten des Webservers 213 auf einer herkömmlichen tragbaren
Computerdiskette magnetisch gespeichert und befördert werden.
-
Das beispielhafte Ausführungsbeispiel
des Webserversystems 200 von 2 umfaßt zumindest
ein Verarbeitungselement 202, wie z. B. einen Digitalsignalprozessor
(DSP) oder eine zentrale Verarbeitungseinheit (CPU), die in dem
System 200 über
eine lokale Schnittstelle 204, die einen oder mehrere Busse
umfassen kann, mit den anderen Elementen kommuniziert und dieselben
treibt. Das System 200 kann auch ein Eingabegerät 206 umfassen,
beispielsweise eine Tastatur oder eine Maus, die verwendete werden
kann, um Daten von einem Benutzer des Systems 200 einzugeben,
und ein Ausgabegerät 208,
beispielsweise eine Bildschirmanzeige oder ein Drucker, kann verwendet
werden, um Daten an den Benutzer auszugeben. Das System 200 ist
vorzugsweise mit einer Netzwerkschnittstelle 210 verbunden,
die es dem System 200 ermöglicht, Daten mit einem Client 102 über ein
Netzwerk 103 (2),
wie z. B. dem Internet, auszutauschen.
-
Das Computersystem 200 ist
konfiguriert, um über
ein Netzwerk 103 (2) über die
Netzwerkschnittstelle 210 mit einem Client 102 (2) zu kommunizieren. Ein
Benutzer des Client 102 kann einen URL eingeben oder anderweitig
liefern, der durch den Webbrowser 104 (2) empfangen wird, der auf dem Client 102 installiert
ist. Es ist anzumerken, daß der
Webbrowser verschiedene Typen bekannter oder in Zukunft entwickelter
Webbrowser umfassen kann, einschließlich Netscape oder Explorer.
Es ist ferner anzumerken, daß die
Plattform, auf der der Client implementiert ist, ein Macintosh-Betriebssystem,
ein Windows-Betriebssystem, ein
UNIX-System, ein LINUX-System oder einen anderen Betriebssystemtyp
umfassen kann. Wenn der Benutzer einen URL eingibt, stellt der Client 102 typischerweise
eine Anforderung zusammen und sendet die Anforderung über das
Netzwerk 103 an das System 200, durch die Netzwerkschnittstelle 210.
Die Netzwerkschnittstelle 210 kann eine Wählleitung,
eine ISDN-Leitung (ISDN = Integrated Services Digital Network =
integriertes digitales Fernmeldenetz), eine DSL-Leitung (DSL = Digital
Subscriber Line = digitale Teilnehmerleitung) oder jeden anderen
Netzwerkschnittstellentyp umfassen, der in der Technik bekannt ist
oder in Zukunft entwickelt wird.
-
Der Webserver 213 empfängt die
Anforderung und sendet die Anforderung, vorzugsweise gemäß dem Servletstandard,
der durch JCP definiert ist, an den Servletbehälter 214. Der Servletbehälter 214 analysiert dann
syntaktisch die Anforderung, zum Bestimmen, welcher Typ von Befehlsanforderung
empfangen wurde. Wie es hierin angezeigt wurde, umfassen Anforderungen
vorzugsweise vorhersagbare Daten, die Befehle, beispielsweise GET
und PUT, eine IP-Adresse des Client oder andere Daten, die die Anforderung
anderweitig beschreiben, umfassen können. Dieser Datentyp ist typischerweise
in einem Anfangsblock enthalten, der Teil der Anforderung bildet,
die durch den Client 102 gesendet wird. Als solches ist
der Servletbehälter 214 vorzugsweise
konfiguriert, um Konfigurationsdaten beizubehalten, die ein Suchfilter
einem speziellen Datenstück zuordnet.
Der Servletbehälter 214 kann
beispielsweise Konfigurationsdaten umfassen, die anzeigen, daß alle Anforderungen,
die GET-Befehle enthalten, an das Suchanforderungsfilter 218 gesendet
werden. Wenn daher der Servletbehälter 214 von dem Webbrowser 213 eine
Anforderung empfängt,
die einen GET-Befehl enthält, sendet
der Servletbehälter 214 die
Anforderung an das Suchanforderungsfilter 218.
-
Diesbezüglich vergleicht der Servletbehälter 214 vorzugsweise
ausgewählte
Stücke
von syntaktisch analysierten Daten mit den Konfigurationsdaten,
um zu bestimmen, ob ein Datenstück
dem Suchanforderungsfilter 218 zugeordnet ist. Falls der
Servletbehälter 214 bestimmt,
daß die
Daten dem Suchanforderungsfilter 218 zugeordnet sind, dann
sendet der Servletbehälter 214 die
Anforderung an das Suchanforderungsfilter 218.
-
Auf das Empfangen der Anforderung
von dem Servletbehälter 214 hin
kann das Suchanforderungsfilter 218 die Daten in ein Format
umwandeln, das mit dem verwendeten API-Typ kompatibel ist, falls
beispielsweise die Lucene-API verwendet wird, und dann wandelt das
Suchanforderungsfilter 218 die Daten vorzugsweise in ein
Dokument um, das eine Mehrzahl von Feldern aufweist. Ferner ist
jedem Feld ein Wert zugeordnet. Das Suchanforderungsfilter 218 kann
beispielsweise die Anforderungsdaten in ein Dokument umwandeln, das
zwei Felder aufweist, ein Befehlsfeld und ein IP-Adreßfeld. Das
Suchanforderungsfilter 218 ordnet dann dem Feld den speziellen
Wert zu, der sich in der Anforderung befindet, der Befehl kann beispielsweise
GET sein und die IP-Adresse kann 123.45.5.67 sein.
-
Das Suchanforderungsfilter 218 indexiert
das Dokument gemäß der API,
die verwendet wird. Wie es hierin angezeigt ist, wenn ein Dokument
für Wiedergewinnungszwecke
in einem durchsuchbaren Depot indexiert wird, werden Feldern in
dem Dokument Schlüssel
zugeordnet. Die Schlüssel
werden dann während
einer Suche verwendet, um Dokumente wiederzugewinnen, bei denen
die gesuchten Werte den Feldern zugeordnet sind.
-
Das Suchanforderungsfilter 218 kann
dann eine Lucene-API 222 verwenden, um die Informationen
in einem Depot beizube halten. Es ist anzumerken, daß die Lucene-API 222 bei
diesem beispielhaften Ausführungsbeispiel
verwendet wird, um das Depot der Anforderungen und Antworten zu
erzeugen, das nachfolgend näher
erörtert
wird. Es könnte
jedoch jede Indexier- und Suchschnittstelle bei der Implementierung
eines Ausführungsbeispiels
verwendet werden.
-
Die Dokumente, die die Anforderungen
anzeigen, die durch das Suchanforderungsfilter 218 umgewandelt
werden, sind in dem Depot 221 gespeichert. Wie es hierin
angemerkt ist, kann das Depot 221 eine strukturierte Datenbank
von Aufzeichnungen umfassen, die die Anforderung darstellt, oder
ein Verzeichnis, das Dateien enthält, die die umgewandelten Dokumente
anzeigen.
-
Nachdem das Suchanforderungsfilter 218 das
Speichern der Anforderung in dem Depot 221 abgeschlossen
hat, signalisiert dasselbe dem Servletbehälter 214, daß es seine
Aufgabe abgeschlossen hat. Der Servletbehälter 218 sendet dann
die Anforderung zum Verarbeiten an das Servlet 220. Das
Servlet 220 verarbeitet die Anforderung, formuliert eine
Antwort gemäß dem Typ
der empfangenen Anforderung und sendet dann die Antwort an den Servletbehälter 214.
-
Der Servletbehälter 214 analysiert
dann die Antwort syntaktisch, um zu bestimmen, welcher Antworttyp
gesendet wird. Wie bei den HTTP-Anforderungen, die hierin beschrieben
sind, umfassen Antworten typischerweise vorhersagbare Daten, die
Befehle umfassen können,
beispielsweise eine OK-Anzeige
oder eine Fehleranzeige oder andere Daten, die die Antwort anderweitig
beschreiben. Typischerweise ist dieser Datentyp in einem Anfangsblock
enthalten, der Teil der Antwort bildet, die durch das Servlet 220 formuliert
wird. Als solches ist der Servletbehälter vorzugsweise konfiguriert,
um Konfigurationsdaten beizubehalten, die ein Suchfilter einem speziellen
Datenstück
zuordnet. Der Servletbehälter 114 kann
beispielsweise Konfigurationsdaten umfassen, die anzeigen, daß alle Antworten,
die „OK"-Anzeigen enthalten,
an das Suchantwortfilter 219 gesendet werden. Wenn daher
der Servletbehälter 114 von
dem Servlet 220 eine Antwort empfängt, die eine OK-Anzeige enthält, sendet
der Servletbehälter 214 die
Antwort an das Suchantwortfilter 219.
-
Diesbezüglich vergleicht der Servletbehälter 214 vorzugsweise
ausgewählte
syntaktisch analysierte Datenstücke
mit den Konfigurationsdaten, um zu bestimmen, ob ein Datenstück dem Suchantwortfilter 219 zugeordnet
ist. Falls der Servletbehälter 214 bestimmt,
daß die
Daten dem Suchantwortfilter 219 zugeordnet sind, sendet
der Servletbehälter 214 die
Anforderung an das Suchantwortfilter 219. Andernfalls sendet
der Servletbehälter 214 die
Antwort an den Webserver 213 für eine Übertragung an den Client 102.
-
Auf das Empfangen der Anforderung
von dem Servletbehälter 214 hin
kann das Suchantwortfilter 219 die Daten in ein Format
umwandeln, das mit dem verwendeten API-Typ kompatibel ist, falls
beispielsweise die Lucene-API verwendet wird, wandelt das Suchantwortfilter 219 die
Daten vorzugsweise in ein Dokument um, das eine Mehrzahl von Feldern
aufweist. Ferner ist jedem Feld ein Wert zugeordnet. Das Suchantwortfilter 218 kann
die angeforderten Daten beispielsweise in ein Dokument umwandeln,
das ein Statusfeld aufweist, das anzeigt, ob das Verarbeiten der
Anforderung erfolgreich war oder fehlgeschlagen hat. Das Filter 219 ordnet dann
dem Feld den speziellen Wert zu, der in der Anforderung gefunden
wird. Beispielsweise kann ein OK-Befehl
in der Antwort dem Statusfeld zugeordnet sein.
-
Das Suchantwortfilter 219 indexiert
das Dokument gemäß der verwendeten
API. Wie es hierin angezeigt ist, wenn ein Dokument für Wiedergewinnungszwecke
in einem durchsuchbaren Depot indexiert wird, sind den Feldern in
dem Dokument Schlüssel
zugeordnet. Die Schlüssel
werden dann während
einer Suche verwendet, um Dokumente wiederzugewinnen, bei denen
die gesuchten Werte den Feldern zugeordnet sind.
-
Das Suchantwortfilter 219 kann
dann eine Lucene-API 222 verwenden, um die Information
in einem Depot 221 beizubehalten. Es ist anzumerken, daß bei diesem
beispielhaften Ausführungsbeispiel
die Lucene-API 222 verwendet wird, um das Depot 221 für die Anforderungen
und Antworten zu erzeugen. Bei der Implementierung eines Ausführungsbeispiels
der Erfindung kann jedoch jeder Typ von servletbasierter Indexier-
und Suchschnittstelle verwendet werden.
-
Die Dokumente, die die Antworten
anzeigen, die durch das Suchantwortfilter 219 umgewandelt
werden, werden in dem Depot 221 gespeichert. Wie es hierin
angemerkt wurde, kann das Depot 221 eine strukturierte
Datenbank von Aufzeichnungen umfassen, die die Anforderung darstellen,
oder ein Verzeichnis, das Dateien enthält, die die umgewandelten Dokumente
anzeigen.
-
Als ein Beispiel kann die folgende
beispielhafte Anforderung von dem Client
102 über die
Netzwerkschnittstelle
210 übertragen werden:
GET
/text/servlet/helloworld.htm HTTP/1.1 | A.1 |
Host:
123.4.56.789 | B.1 |
User-Agent:
Mozilla/5.0 | C.1 |
Accept:
*/* | D.1 |
Accept-Encoding:
gzip, deflate compress, identity | E.1 |
Host:
localhost: 8080 | F.1 |
Accept-Language:
en | G.1 |
Keep-Alive:
3000 | H.1 |
Connection:
keep-alive | I.1 |
-
Die beispielhafte Anforderung ist
im HTTP-Format, das ein Standardformat für eine Antwort ist, wie es hierin
oben beschrieben ist. Die HTTP-Beispielanforderung ist eine einfache
HTTP-Anforderung, die dem Servletbehälter 214 anzeigt,
daß der
Client 102 eine HTML-Datei mit dem Titel „Helloworld" wünscht. Genauer gesagt,
die erste Zeile A.1 ist die tatsächliche
Anforderung und die folgenden Zeilen sind einfach zusätzliche Informationen,
die durch den Webserver verwendet werden, um die Verbindung mit
dem Client 102 herzustellen und mit demselben zu kommunizieren.
Die gelieferten Zeilen sind Anfangsblöcke und als solche vorhersehbar,
wie es hierin beschrieben ist. Daher ist das Suchantwortfilter 218 vorzugsweise
entworfen und konfiguriert in Erwartung des gelieferten Anfangsblocks
in der HTTP-Antwort. Der Webserver 213 empfängt die oben
detailliert dargestellte Anforderung und sendet die Anforderung
an den Servletbehälter 214.
Der Servletbehälter 214 vergleicht
den Anforderungstyp, der ein GET-Anforderungstyp ist mit denjenigen,
die der Servletbehälter 214 dem
Suchantwortfilter 218 zuordnet. Falls der Servletbehälter 214 findet,
daß eine
GET-Anforderung eine ist, die dem Suchanforderungsfilter 218 zugeordnet
ist, dann sendet er die Anforderung an das Suchanforderungsfilter 218.
-
Das Suchanforderungsfilter 218 analysiert
dann die Anforderung syntaktisch und gewinnt von der Anforderung
die Informationen wieder, die das Suchanforderungsfilter 218 bei
seinem Indexierschema für
zukünftige
Suche und Wiedergewinnung verwendet. Das Suchanforderungsfilter 218 kann
beispielsweise konfiguriert sein, um einfach in dem Depot die tatsächliche
Anforderung (d. h. die Zeile A.1 bei dem vorliegenden Beispiel) wiederzugewinnen
und zu indexieren. Das Suchanforderungsfilter 218 kann
jedoch ferner konfiguriert sein, um die Hostidentifikationsnummer
B.1 oder die Sprache, die durch die unterschiedlichen Client angefordert
wird, G.1, wiederzugewinnen und zu indexieren.
-
Nach dem syntaktischen Analysieren
der Anforderung zum Wiedergewinnen der Daten zum Indexieren verwendet
das Suchanforderungsfilter 218 die Lucene-API 222,
um ein erzeugtes Depot zu indexieren und/oder zu durchsuchen. Es
ist anzumerken, daß die
Verwendung der Lucene-API 222 lediglich ein Beispiel ist
und andere Softwarepakete oder APIs bei der Implementierung der
darstellenden Ausführungsbeispiele verwendet
werden könnten.
-
Sobald das Suchanforderungsfilter 218 sein
syntaktisches Analysieren und Indexieren der Anforderungsdaten abgeschlossen
hat, informiert es den Servletbehälter 214, daß es seine
Aufgabe abgeschlossen hat. Der Servletbehälter 214 verlegt dann
die Anforderung auf das Servlet 220. Das Servlet 220 empfängt die Anforderung,
verarbeitet die Anforderung, formuliert eine Antwort, und sendet
dann die Antwort an den Servletbehälter 214.
-
Es folgt eine beispielhafte Antwort,
die durch das Servlet ansprechend auf die vorher erwähnte Anforderung
erzeugt wurde, und diese Antwort kann von dem Servlet
220 über die
Netzwerkschnittstelle
210 an den Client
102 gesendet
werden:
HTTP/1.0
200 OK | A.2 |
Server:
Webstar 1.2 /ID CGI | B.2 |
MIME-Version:
1.0 | C.2 |
Content-type:
text/htm | D.2 |
-
Die Beispielantwort ist eine HTTP-Antwort,
die eine HTML-Datei
an den Client 102 sendet, mit einer Erfolgsanzeige, Linie
A.2, die „200
OK" sendet. Genauer
gesagt, die erste Linie A.1 ist ein „200 OK"-Anfangsblock, der anzeigt, daß die Antwort
erfolgreich war. Die HTTP-Antwort, die an den Client gesendet wurde,
umfaßt
eine HTML-Datei, wie es in Linie B.4 angezeigt ist. Wie es hierin
beschrieben ist, umfaßt
die HTTP-Antwort einen formatierten Anfangsblock, der definierte
Datenteilfelder umfaßt,
daher ist der Datentyp, der in dem Anfangsblock enthalten ist, vorhersagbar.
Daher ist das Suchantwortfilter 219 vorzugsweise in Erwartung
des gelieferten Anfangsblocks in der HTTP-Antwort entworfen und
konfiguriert. Der Servletbehälter 214 vergleicht den
Antworttyp, der ein „200
OK"-Antworttyp ist,
mit denjenigen, die der Servletbehälter 214 dem Suchant wortfilter 219 zuordnet.
Falls der Servletbehälter 214 herausfindet,
daß eine „200 OK"-Antwort eine ist,
die dem Suchantwortfilter 219 zugeordnet ist, sendet derselbe
die Antwort an das Suchantwortfilter 219.
-
Das Suchantwortfilter 219 analysiert
die Antwort dann syntaktisch und gewinnt von der Antwort die Informationen
wieder, die das Suchantwortfilter 219 bei seinem Indexierungsschema
für eine
zukünftige
Wiedergewinnung verwendet. Das Suchantwortfilter 218 kann
beispielsweise konfiguriert sein, um in dem Depot die HTML-Datei
wiederzugewinnen und zu indexieren, die in der Linie D.2 angezeigt
ist.
-
Nach dem syntaktischen Analysieren
der Antwort zum Wiedergewinnen der Daten zum Indexieren verwendet
das Suchantwortfilter 219 die Lucene-API 222,
um das erzeugte Depot 221 zu indexieren und/oder zu durchsuchen.
Es ist anzumerken, daß die
Verwendung der Lucene-API 222 lediglich ein Beispiel ist,
und bei anderen Ausführungsbeispielen
andere Softwarepakete oder APIs verwendet werden könnten.
-
Die Architektur und Funktionalität eines
beispielhaften Ausführungsbeispiels
eines Webservers 200 wird nun mit Bezugnahme auf 4 erörtert, und ist überall allgemein
als Verfahren 300 bezeichnet.
-
Der Webserver 213 (2) empfängt eine Anforderung, beispielsweise
eine HTTP-Anforderung, von einem Client 102 (2), wie es in Schritt 304 angezeigt
ist. Der Servletbehälter 214 bestimmt,
ob der Anforderung ein Suchfilter gibt zugeordnet ist, wie es in
Schritt 306 angezeigt ist. Falls dem Typ der Anforderung, die
durch den Client durchgeführt
wird, kein Suchfilter zugeordnet ist, dann verarbeitet das Servlet 220 die
Anforderung und formuliert eine Antwort, wie es in Schritt 308 bzw. 310 angezeigt
ist. Der Servletbehälter 214 bestimmt
dann, ob der formulierten Antwort ein Suchfilter zugeordnet ist,
wie es in Schritt 318 angezeigt ist. Falls der Antwort
kein Filter zugeordnet ist, dann sendet der Servletbehälter 214 die
Antwort, wie es in Schritt 322 angezeigt ist. Falls der
Antwort ein Filter zugeordnet ist, wie es in Schritt 318 angezeigt
ist, indexiert das Suchantwortfilter 219 die Antwort, wie
es in Schritt 320 angezeigt ist, und der Servletbehälter 214 sendet
dann die Antwort an den anfordernden Client 102 (2), wie es in Schritt 322 angezeigt
ist.
-
Falls der Anforderung in Schritt 306 ein
Suchfilter zugeordnet ist, indexiert das Suchanforderungsfilter 218 die
Anforderung, wie es in Schritt 312 angezeigt ist. Nachdem
die Anforderung indexiert ist, verarbeitet das Servlet 220 die
Anforderung, wie es in Schritt 314 angezeigt ist, und formuliert
eine Antwort, wie es in Schritt 316 angezeigt ist.
-
Der Servletbehälter 214 bestimmt
dann, ob der Antwort, die durch das Servlet 220 formuliert
wird, ein Suchantwortfilter zugeordnet ist, wie es in Schritt 318 angezeigt
ist. Falls dem Typ der Antwort, der durch das Servlet 220 gesendet
wird, ein Suchfilter zugeordnet ist, indexiert das Suchantwortfilter 219 die
Antwort in Schritt 320. Nachdem die Antwort indexiert ist,
sendet der Servletbehälter 220 die
Antwort in Schritt 322 an den Client 102.
-
Falls dem Antworttyp, der in Schritt 318 durch
das Servlet 220 gesendet wird, kein Suchfilter zugeordnet
ist, sendet der Servletbehälter
die Antwort an den anfordernden Client 102, wie es in Schritt 322 angezeigt ist.