DE10351739A1 - Ein System und Verfahren zum Liefern von Informationen bezüglich Serververkehr - Google Patents

Ein System und Verfahren zum Liefern von Informationen bezüglich Serververkehr Download PDF

Info

Publication number
DE10351739A1
DE10351739A1 DE10351739A DE10351739A DE10351739A1 DE 10351739 A1 DE10351739 A1 DE 10351739A1 DE 10351739 A DE10351739 A DE 10351739A DE 10351739 A DE10351739 A DE 10351739A DE 10351739 A1 DE10351739 A1 DE 10351739A1
Authority
DE
Germany
Prior art keywords
request
servlet
response
search
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE10351739A
Other languages
English (en)
Inventor
Joseph J. Snyder
Jason Kinner
Richard Friedman
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Development Co LP
Original Assignee
Hewlett Packard Development Co LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Development Co LP filed Critical Hewlett Packard Development Co LP
Publication of DE10351739A1 publication Critical patent/DE10351739A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/34Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Ein Serversystem zum Liefern von Informationen bezüglich Serververkehr umfaßt ein Servlet, das sich in einem Servletbehälter befindet, der konfiguriert ist, um eine Anforderung zu empfangen, die Anforderung zu verarbeiten und eine Antwort entsprechend der Anforderung zu formulieren, und eine Logik, die in dem Servletbehälter enthalten ist, die konfiguriert ist, um die Anforderung zu empfangen und die Anforderung zu indexieren, wobei die Logik konfiguriert ist, um die Anforderungen von dem Serlvetbehälter zu empfangen.

Description

  • 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.

Claims (26)

  1. Serversystem zum Liefern von Informationen bezüglich Serververkehr, das folgende Merkmale umfaßt: ein Servlet (220), das sich in einem Servletbehälter (214) befindet, wobei das Servlet konfiguriert ist, um eine Anforderung (106) zu empfangen, die Anforderung zu verarbeiten und eine Antwort (120) entsprechend der Anforderung zu formulieren; und eine Logik (218), die in dem Servletbehälter (214) enthalten ist, wobei die Logik konfiguriert ist, um die Anforderung (106) von dem Servletbehälter (214) zu empfangen und konfiguriert ist, um Daten zu indexieren, die die Anforderung anzeigen.
  2. Serversystem gemäß Anspruch 1, bei dem die Daten, die die Anforderung (106) anzeigen, einen Abschnitt der Anforderung (106) umfassen.
  3. Serversystem gemäß Anspruch 2, bei dem der Teil der Anforderung (106) ein HTML-Dateiname ist.
  4. Serversystem gemäß einem der Ansprüche 1 bis 3, das ferner eine Logik (219) in dem Servletbehälter (214) umfaßt, die konfiguriert ist, um die formulierte Antwort (120) zu empfangen, und konfiguriert ist, um Daten zu indexieren, die die formulierte Antwort (120) anzeigen.
  5. Serversystem gemäß Anspruch 4, bei dem die Daten, die die Antwort (120) anzeigen, einen Teil der Antwort (120) umfassen.
  6. Serversystem gemäß Anspruch 5, bei dem der Teil der Antwort (120) eine HTML-Datei ist.
  7. Serversystem gemäß einem der Ansprüche 4 bis 6, bei dem die Logik, die konfiguriert ist, um die Daten, die die formulierte Antwort (120) anzeigen, zu empfangen und zu indexieren, mit einer servletbasierten Anwendungsprogrammschnittstelle (API) (116) implementiert ist.
  8. Serversystem gemäß Anspruch 7, bei dem die servletbasierte Anwendungsprogrammschnittstelle (116) eine Lucene-API ist.
  9. Serversystem gemäß einem der Ansprüche 4 bis 8, bei dem die Logik (218), die konfiguriert ist, um die Anforderung zu empfangen und die Logik (219), die konfiguriert ist, um die Antwort zu empfangen, ferner konfiguriert sind, um die indexierten Daten, die die Anforderung anzeigen, und die indexierten Daten, die die Antwort anzeigen, in einem Depot (221) zu speichern.
  10. Serversystem gemäß Anspruch 9, bei dem das Depot (221) ein servletbasiertes Depot ist.
  11. Serversystem gemäß Anspruch 9 oder 10, bei dem der Servletbehälter (214) konfiguriert ist, um die Anforderung (106) zu empfangen und die Anforderung mit einer Konfigurationsdatei zu vergleichen, wobei der Servletbehälter (214) ferner konfiguriert ist, um die Anforderung (106) an die Logik (218) zu senden, die konfiguriert ist, um die Anforderung zu empfangen, falls die Konfigurationsdatei anzeigt, daß die Anforderung der Logik (219) zugeordnet ist, die konfiguriert ist, um die Daten, die die Anforderung anzeigen, zu empfangen und zu indexieren.
  12. System gemäß einem der Ansprüche 9 bis 11, bei dem der Servletbehälter (214) konfiguriert ist, um die Antwort (120) zu empfangen und die Antwort (120) mit einer Konfigurationsdatei zu vergleichen, wobei der Servlet behälter (214) ferner konfiguriert ist, um die Antwort an die Logik (219) zu senden, die konfiguriert ist, um die Antwort zu empfangen und zu indexieren, falls die Konfigurationsdatei anzeigt, daß die Antwort der Logik zugeordnet ist, die konfiguriert ist, um die Daten, die die Antwort anzeigen, zu empfangen und zu indexieren.
  13. Serversystem gemäß einem der Ansprüche 9 bis 12, bei dem das Serversystem einen Webserver (152) umfaßt.
  14. Serversystem gemäß Anspruch 13, bei dem der Servletbehälter (214) ferner konfiguriert ist, um die Antwort an den Webserver (152) zu senden, falls die Konfigurationsdatei nicht anzeigt, daß die Antwort der Logik (219) zugeordnet ist, die konfiguriert ist, um die Antwort zu empfangen und zu indexieren.
  15. System gemäß Anspruch 14, das ferner einen Client umfaßt, der einen Webbrowser aufweist, wobei der Webbrowser konfiguriert ist, um eine URL-Eingabe zu empfangen, wobei der Client ferner konfiguriert ist, um die URL-Eingabe in die Anforderung einzubauen.
  16. System gemäß Anspruch 15, bei dem der Webbrowser konfiguriert ist, um eine Suchseite zu speichern, wobei die Suchseite ein Textfeld zum Eingeben einer Textzeichenfolge umfaßt, wobei der Client ferner konfiguriert ist, um eine Textzeichenfolge zu empfangen und die Anforderung zum Durchführen einer Suche in dem Depot (221) von Anforderungen und Antworten zusammenzustellen.
  17. System gemäß Anspruch 16, bei dem das Servlet (220) ferner konfiguriert ist, um eine Suche in dem Depot (221) durchzuführen, ansprechend auf eine Anforderung von einem Client, der eine Suche anfordert, wobei das Servlet (220) ferner konfiguriert ist, um eine Antwort zusammenzustellen, die einen Satz von Übereinstimmungen mit der Suchzeichenfolge umfaßt, und den Satz von Übereinstimmungen an den Client zu senden.
  18. Verfahren für die Verwendung in einem Webserver (213), das folgende Schritte umfaßt: Empfangen einer Anforderung (106) in einem Servletbehälter (214) des Webservers, wobei die Anforderung von einem Client (102) an den Webserver (213) gesendet wird; Indexieren der Anforderung (106); Speichern von Daten, die die Anforderung anzeigen, in einem Depot (221); Formulieren einer Antwort (120) auf die Anforderung; und Senden der Antwort (120) an den Client.
  19. Verfahren gemäß Anspruch 18, bei dem das Depot (221) ein servletbasiertes Depot ist.
  20. Verfahren gemäß Anspruch 19, bei dem das Senden ferner folgende Schritte umfaßt: Empfangen der formulierten Antwort von einem Servlet (220); Indexieren der Antwort (120); und Speichern der Antwort (120) in dem Depot (221).
  21. Verfahren gemäß Anspruch 20, bei dem das Empfangen ferner folgenden Schritt umfaßt: Bestimmen, ob ein Suchfilter des Webservers (213) einem Anforderungstyp zugeordnet ist, der in der Anforderung (106) angezeigt ist.
  22. Verfahren gemäß Anspruch 20 oder 21, bei dem das Empfangen der formulierten Antwort ferner folgenden Schritt umfaßt: Bestimmen, ob es ein Suchfilter des Webservers (213) gibt, das einem Antworttyp zugeordnet ist, der in der Antwort (120) angezeigt ist.
  23. Webserver (213) zum Liefern von Informationen bezüglich Serververkehr, der folgende Merkmale umfaßt: einen Servletbehälter (214), der sich in einem Webserver befindet, wobei der Webserver konfiguriert ist, um eine Anforderung von einem Client zu empfangen und die Anforderung an den Servletbehälter (214) zu senden; ein Servlet (220), das sich in dem Servletbehalter befindet, wobei das Servlet konfiguriert ist, um eine Antwort zu formulieren, die der Anforderung entspricht, wobei der Servletbehälter (214) konfiguriert ist, um die Anforderung an das Servlet zu senden, und die Antwort von dem Servlet (220) zu empfangen; und ein Suchanforderungsfilter (218), das sich in dem Servletbehälter befindet, wobei das Suchanforderungsfilter konfiguriert ist, um die Anforderung von dem Servletbehälter (214) zu empfangen, wobei das Suchanforderungsfilter ferner konfiguriert ist, um Daten, die die Anforderung anzeigen, in einem Depot (221) zu indexieren und zu speichern; ein Suchantwortfilter (219), das sich in dem Servletbehälter (214) befindet, wobei das Suchantwortfilter konfiguriert ist, um die Antwort von dem Servletbehäl ter (214) zu empfangen, wobei das Suchantwortfilter ferner konfiguriert ist, um Daten, die die Antwort anzeigen, in einem Depot (221) zu indexieren und zu speichern.
  24. System gemäß Anspruch 23, bei dem der Servletbehälter (214) ferner konfiguriert ist, um die Anforderung und/oder die Antwort an das Suchfilter zu senden, falls der Servletbehälter bestimmt, daß die Anforderung und/oder die Antwort dem Filter zugeordnet ist.
  25. Server zum Liefern von Informationen bezüglich Serververkehr, der folgende Merkmale umfaßt: eine Einrichtung zum Empfangen von Anforderungen von zumindest einem Client; eine Einrichtung zum Empfangen von Antworten von einem Servlet (220); eine Sucheinrichtung zum Indexieren und Speichern von Daten, die die Anforderungen (106) anzeigen, in einem servletbasierten Depot (221); und eine Sucheinrichtung zum Indexieren und Speichern von Daten, die die Antworten (120) anzeigen, in einem servletbasierten Depot (221).
  26. Computerprogramm, das in einem computerlesbaren Medium verkörpert ist, zum Liefern von Informationen bezüglich Serververkehr, wobei das Computerprogramm folgende Merkmale umfaßt: eine Logik zum Empfangen einer Anforderung in einem Servletbehälter (214) des Webservers, wobei die Anforderung von einem Client an den Webserver gesendet wird; eine Logik zum Indexieren von Daten, die die Anforderung (106) anzeigen; eine Logik zum Speichern von Daten, die die Anforderung anzeigen, in einem Depot (221); eine Logik zum Formulieren einer Antwort auf die Anforderung (106); eine Logik zum Indexieren von Daten, die die Antwort (120) anzeigen; eine Logik zum Speichern von Daten, die die Antwort (120) anzeigen, in einem Depot (221); und eine Logik zum Senden der Antwort (120) an den Client.
DE10351739A 2003-02-21 2003-11-06 Ein System und Verfahren zum Liefern von Informationen bezüglich Serververkehr Withdrawn DE10351739A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/371734 2003-02-21
US10/371,734 US20040205764A1 (en) 2003-02-21 2003-02-21 System and method for providing information regarding server traffic

Publications (1)

Publication Number Publication Date
DE10351739A1 true DE10351739A1 (de) 2004-09-16

Family

ID=32868401

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10351739A Withdrawn DE10351739A1 (de) 2003-02-21 2003-11-06 Ein System und Verfahren zum Liefern von Informationen bezüglich Serververkehr

Country Status (2)

Country Link
US (1) US20040205764A1 (de)
DE (1) DE10351739A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080249885A1 (en) * 2007-04-03 2008-10-09 Yahoo! Inc. Systems and methods for providing an internet asset marketplace
US9032087B2 (en) * 2007-07-13 2015-05-12 International Business Machines Corporation Providing a fine-grained response from a coarse-grained service object

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6169985B1 (en) * 1998-05-29 2001-01-02 Epiphany, Inc. Method and apparatus for determining a set of database entries
US20020002563A1 (en) * 1999-08-23 2002-01-03 Mary M. Bendik Document management systems and methods
US6442748B1 (en) * 1999-08-31 2002-08-27 Accenture Llp System, method and article of manufacture for a persistent state and persistent object separator in an information services patterns environment
AU2001271763A1 (en) * 2000-06-30 2002-01-14 Zinio Systems, Inc. System and method for encrypting, distributing and viewing electronic documents
AU2001288854A1 (en) * 2000-09-07 2002-03-22 Daniel D. Briere Marketing collateral repository and supporting data management and communication environment
US20020168139A1 (en) * 2001-03-30 2002-11-14 Clarkson William Andrew Optical fiber terminations, optical couplers and optical coupling methods

Also Published As

Publication number Publication date
US20040205764A1 (en) 2004-10-14

Similar Documents

Publication Publication Date Title
DE60028561T2 (de) Bereitstellung von kundendiensten, die daten aus datenquellen abrufen, wobei die datenquellen die vom kunden geforderten formate nicht notwendigerweise unterstützen
DE60126016T2 (de) Serverseitige Kontrollobjekte zur Verarbeitung von kundenseitigen Benutzerschnittstellenelementen
DE69832786T2 (de) Vorrichtung und verfahren zur identifizierung von klienten die an netzwer-sites zugreifen
US7680672B2 (en) Event collection architecture
DE69837508T2 (de) Verfahren zum Inhaltswiederauffinden über ein Netzwerk
DE60125913T2 (de) Datenübertragungsverfahren und vorrichtung
DE69931256T2 (de) Verfahren und system zum zurückholen einer elektronischen akte
DE60127795T2 (de) System und Verfahren zur Metrik- und Statusdarstellung
US20070226612A1 (en) Server-side html customization based on style sheets and target device
DE10050172A1 (de) Systeme, Verfahren und Computerprogrammprodukte zur Überprüfung eines für die Anzeige in pervasive Computereinheiten angepassten Web-Inhaltes
EP1097428A2 (de) System und verfahren zum prüfen von netzwerk-anwendungen
DE60101668T2 (de) Verfahren und gerät zum erzeugen eines auf einer formatvorlage basierten index für ein strukturiertes dokument
DE10296648T5 (de) Methode für die Integration der elektronischen Post und der Web-Kommunikationen mit einem Benutzer
DE69933435T2 (de) Apparat und verfahren zum übermitteln von dokumenten zwischen einem server-rechner und einem benutzer-rechner
DE10352400A1 (de) Netzwerkdienst-Abfangvorrichtung
DE112012004301T5 (de) Erzeugen einer vorhersagenden Datenstruktur
DE10118064B4 (de) Erweiterung Browser-bezogener Internetseiteninhaltskennzeichen und Kennwortüberprüfung auf Kommunikationsprotokolle
EP1303819A1 (de) System und verfahren zur generierung eines xml-basierten fehlermodells
EP1030254B1 (de) Verfahren und System zum Verwalten von Dokumenten
DE102006027664B4 (de) Kommunikationssystem zum Verarbeiten von Daten
WO2010060541A1 (de) Verfahren und vorrichtung zur verteilten konfiguration von telematik-diensten in kraftfahrzeug-systemen
DE10351739A1 (de) Ein System und Verfahren zum Liefern von Informationen bezüglich Serververkehr
DE60216356T2 (de) Verfahren und Vorrichtung zum automatischen Suchen von Hypertext-Strukturen
DE10393809T5 (de) Datenstruktur zum Analysieren von Anwendersitzungen
EP1094405A2 (de) Verfahren zum Erzeugen einer dynamischen Auswahlmaske für den Abruf von Daten aus einer Datenbank

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8130 Withdrawal