DE112012002631T5

DE112012002631T5 - Stream-Verarbeitung unter Verwendung einer Client-Server-Architektur

Info

Publication number: DE112012002631T5
Application number: DE112012002631.4T
Authority: DE
Inventors: Yoonho Park; Kenneth S. Sabir
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2011-08-18
Filing date: 2012-08-20
Publication date: 2014-04-17
Also published as: US20160055034A1; WO2013023306A1; US9277030B2; US20140115045A1; GB2508123A8; US9191463B2; US20140115046A1; CN103733568A; GB2508123A; US9043383B2; US8655955B2; CN103733568B; US20130046811A1; GB2508123B; US20140115043A1; GB201404461D0; US8655956B2; US9043382B2; US20140115044A1; US20130046859A1

Abstract

Ein Verfahren zum Antworten auf Anforderungen unter Verwendung von Stream-Verarbeitung kann Empfangen einer Server-Anforderung von einem Server, wobei der Server so konfiguriert ist, dass er die Server-Anforderung in Reaktion auf eine Client-Anforderung erzeugt und Erzeugen einer Anforderungskennung, die zu der Server-Anforderung gehört, aufweisen. Das Verfahren kann in Reaktion auf die Server-Anforderung Senden einer von der Server-Anforderung hergeleiteten Anforderung zur Stream-Verarbeitung an einen ersten Stream-Verarbeitungsknoten aufweisen. Die Anforderung zur Stream-Verarbeitung kann die Anforderungskennung aufweisen. In Reaktion auf Empfangen einer Mitteilung zum Erstellen einer Antwort, die ein Stream-Verarbeitungsergebnis und die Anforderungskennung von einem zweiten Stream-Verarbeitungsknoten aufweist, kann das Stream-Verarbeitungsergebnis mit der Server-Anforderung korreliert werden. Eine Mitteilung zum Schreiben einer Antwort, die das Stream-Verarbeitungsergebnis spezifiziert, kann an den Server gesendet werden.

Description

HINTERGRUND
Eine oder mehrere in dieser Patentschrift offenbarte Ausführungsformen betreffen die Stream-Verarbeitung („stream processing”).
Bei der herkömmlichen Datenanalyse werden Anfragen auf statische Daten angewendet. Im Allgemeinen bezieht sich Stream-Verarbeitung auf ein Datenverarbeitungsverfahren, bei dem sich verändernde Daten, die als Datenstrom oder Strom („stream”) bezeichnet werden, bewertet werden können. Ein Datenstrom kann bewertet werden, indem im Großen und Ganzen statische Daten auf den sich verändernden Datenstrom angewendet werden, obgleich die Anfragen im Verlauf der Zeit modifiziert oder aktualisiert werden können. In einigen Fällen kann sich der Datenstrom, auf den die Anfrage erfolgt, schnell verändern. Ein Datenstrom, der bewertet werden soll, kann beispielsweise als konstanter Datenfluss wie beispielsweise Echtzeit- oder Beinahe-Echtzeit-Daten erachtet werden. Die die Stream-Verarbeitung implementierenden Knoten können im Gegensatz zum Arbeiten an statischen Daten, die innerhalb einer Datenbank oder einem anderen Datenspeichersystem gespeichert werden können, an dem Datenstrom arbeiten.
KURZDARSTELLUNG
Eine oder mehrere in dieser Patentschrift offenbarte Ausführungsformen, betreffen Stream-Verarbeitung; und insbesondere Stream-Verarbeitung unter Verwendung einer Art von Client-Server-Architektur.
Eine Ausführungsform kann ein Verfahren zum Antworten auf Anforderungen unter Verwendung von Stream-Verarbeitung aufweisen. Das Verfahren kann Empfangen einer Server-Anforderung von einem Server, wobei der Server so konfiguriert ist, dass er die Server-Anforderung in Reaktion auf eine Client-Anforderung erzeugt, und Erzeugen einer Anforderungskennung, die zu der Server-Anforderung gehört, aufweisen. In Reaktion auf die Server-Anforderung kann eine von der Server-Anforderung hergeleitete Anforderung zur Stream-Verarbeitung an einen ersten Stream-Verarbeitungsknoten gesendet werden. Die Anforderung zur Stream-Verarbeitung kann die Anforderungskennung aufweisen. In Reaktion auf Empfangen einer Mitteilung zum Erstellen einer Antwort, die ein Stream-Verarbeitungsergebnis und die Anforderungskennung aufweist, von einem zweiten Stream-Verarbeitungsknoten, kann das Stream-Verarbeitungsergebnis unter Verwendung eines Prozessors mit der Server-Anforderung korreliert werden. Eine Mitteilung zum Schreiben einer Antwort, die das Stream-Verarbeitungsergebnis aufweist, kann an den Server gesendet werden.
Eine weitere Ausführungsform kann ein Verfahren zum Antworten auf Anforderungen unter Verwendung von Stream-Verarbeitung aufweisen. Das Verfahren kann in Reaktion auf eine Client-Anforderung Zuweisen eines Verarbeitungs-Threades zum Bearbeiten der Client-Anforderung und Einrichten einer Rückverbindung in dem Verarbeitungs-Thread aufweisen. Eine von der Client-Anforderung hergeleitete Server-Anforderung kann an einen Stream-Server gesendet werden. Der Stream-Server kann so konfiguriert sein, dass er mit einer Vielzahl von Stream-Verarbeitungsknoten interagiert. Die Server-Anforderung kann eine Thread-Kennung aufweisen, die den Verarbeitungs-Thread spezifiziert. Der Verarbeitungs-Thread zum Bearbeiten der Client-Anforderung kann in einem Leerlauf kurz vor einer Mitteilung zum Schreiben einer Antwort von dem Stream-Server gehalten werden. In Reaktion auf Empfangen der Mitteilung zum Schreiben einer Antwort, die ein Stream-Verarbeitungsergebnis und die Thread-Kennung von dem Stream-Server aufweist, kann der durch die Thread-Kennung identifizierte Verarbeitungs-Thread unter Verwendung eines Prozessors in einen aktiven Zustand zurückgesetzt werden. Eine Client-Antwort, die das Stream-Verarbeitungsergebnis aufweist, kann über die Rückverbindung an den Client gesendet werden.
Eine weitere Ausführungsform kann ein System zum Antworten auf Anforderungen unter Verwendung von Stream-Verarbeitung aufweisen. Das System kann ein computerlesbares Speichermedium mit einem darin enthaltenen computerlesbaren Programmcode und einen Prozessor aufweisen, der mit dem computerlesbaren Speichermedium verbunden ist. In Reaktion auf Ausführen des computerlesbaren Programmcodes kann der Prozessor so konfiguriert sein, dass er ausführbare Operationen durchführt. Zu den ausführbaren Operationen können Empfangen einer Server-Anforderung von einem Server, wobei der Server so konfiguriert ist, dass er die Server-Anforderung in Reaktion auf eine Client-Anforderung erzeugt, Erzeugen einer zu der Server-Anforderung gehörenden Anforderungskennung, und, in Reaktion auf die Server-Anforderung, Senden einer von der Server-Anforderung hergeleiteten Anforderung zur Stream-Verarbeitung an einen ersten Stream-Verarbeitungsknoten gehören. Die Anforderung zur Stream-Verarbeitung kann die Anforderungskennung aufweisen. In Reaktion auf Empfangen der Mitteilung zum Erstellen einer Antwort, die ein Stream-Verarbeitungsergebnis und die Anforderungskennung aufweist, von einem zweiten Stream-Verarbeitungsknoten, kann das Stream-Verarbeitungsergebnis mit der Server-Anforderung korreliert werden. Eine Mitteilung zum Schreiben einer Antwort, die das Stream-Verarbeitungsergebnis aufweist, kann an den Server gesendet werden.
Eine weitere Ausführungsform kann ein System zum Antworten auf Anforderungen unter Verwendung von Stream-Verarbeitung aufweisen. Das System kann ein computerlesbares Speichermedium mit einem darin enthaltenen computerlesbaren Programmcode und einen Prozessor aufweisen, der mit dem computerlesbaren Speichermedium verbunden ist. In Reaktion auf Ausführen des computerlesbaren Programmcodes kann der Prozessor so konfiguriert sein, dass er ausführbare Operationen durchführt. Zu den ausführbaren Operationen können, in Reaktion auf eine Client-Anforderung, Zuweisen eines Verarbeitungs-Threads zum Bearbeiten der Client-Anforderung und Einrichten einer Rückverbindung in dem Verarbeitungs-Thread sowie Senden einer von der Client-Anforderung hergeleiteten Server-Anforderung an einen Stream-Server, der so konfiguriert ist, dass er mit einer Vielzahl von Stream-Verarbeitungsknoten interagiert, gehören. Die Server-Anforderung kann eine Thread-Kennung aufweisen, die den Verarbeitungs-Thread spezifiziert. Zu den ausführbaren Operationen kann auch Halten des Verarbeitungs-Threads in einem Leerlauf kurz vor einer Mitteilung zum Schreiben einer Antwort von dem Stream-Server, und, in Reaktion auf Empfangen der Mitteilung zum Schreiben einer Antwort, die ein Stream-Verarbeitungsergebnis und die Thread-Kennung aufweist, von dem Stream-Server, Zurücksetzen des von der Thread-Kennung identifizierten Verarbeitungs-Threads in einen aktiven Zustand gehören. Eine Client-Antwort, die das Stream-Verarbeitungsergebnis aufweist, kann über die Rückverbindung an den Client gesendet werden.
Eine weitere Ausführungsform kann ein Computerprogrammprodukt zum Antworten auf Anforderungen unter Verwendung von Stream-Verarbeitung aufweisen. Das Computerprogrammprodukt kann ein computerlesbares Speichermedium mit einem darin enthaltenen computerlesbaren Programmcode aufweisen. Der computerlesbare Programmcode kann einen computerlesbaren Programmcode aufweisen, der so konfiguriert ist, dass er eine Server-Anforderung von einem Server empfängt, wobei der Server so konfiguriert ist, dass er die Server-Anforderung in Reaktion auf eine Client-Anforderung erzeugt und der computerlesbare Programmcode so konfiguriert ist, dass er eine Anforderungskennung erzeugt, die zu der Server-Anforderung gehört. Der computerlesbare Programmcode kann des Weiteren einen computerlesbaren Programmcode aufweisen, der so konfiguriert ist, dass er, in Reaktion auf die Server-Anforderung, eine von der Server-Anforderung hergeleitete Anforderung zur Stream-Verarbeitung an einen ersten Stream-Verarbeitungsknoten sendet. Die Anforderung zur Stream-Verarbeitung kann die Anforderungskennung aufweisen. Der computerlesbare Programmcode kann einen computerlesbaren Programmcode aufweisen, der so konfiguriert ist, dass er, in Reaktion auf Empfangen einer Mitteilung zum Erstellen einer Antwort, die ein Stream-Verarbeitungsergebnis und die Anforderungskennung aufweist, von einem zweiten Stream-Verarbeitungsknoten, das Stream-Verarbeitungsergebnis mit der Server-Anforderung korreliert. Der computerlesbare Programmcode kann des Weiteren einen computerlesbaren Programmcode aufweisen, der so konfiguriert ist, dass er eine Mitteilung zum Schreiben einer Antwort, die das Stream-Verarbeitungsergebnis aufweist, an den Server sendet.
KURZBESCHREIBUNG DER MEHREREN ANSICHTEN DER ZEICHNUNGEN
1 ist ein erstes Blockschaubild, das ein beispielhaftes Datenverarbeitungssystem veranschaulicht.
2 ist ein Blockschaubild, das ein System zur Stream-Verarbeitung gemäß einer in dieser Patentschrift offenbarten Ausführungsform veranschaulicht.
3 ist ein Blockschaubild, das ein System zur Stream-Verarbeitung gemäß einer weiteren in dieser Patentschrift offenbarten Ausführungsform veranschaulicht.
4 ist ein Ablaufplan, der ein Verfahren zum Antworten auf Anforderungen unter Verwendung von Stream-Verarbeitung gemäß einer weiteren in dieser Patentschrift offenbarten Ausführungsform veranschaulicht.
5 ist ein Ablaufplan, der ein Verfahren zum Antworten auf Anforderungen unter Verwendung von Stream-Verarbeitung gemäß einer weiteren in dieser Patentschrift offenbarten Ausführungsform veranschaulicht.
AUSFÜHRLICHE BESCHREIBUNG
Wie Fachleuten ersichtlich ist, können Aspekte der vorliegenden Erfindung als System, Verfahren oder Computerprogramm ausgebildet sein. Dementsprechend können Aspekte der vorliegenden Erfindung vollständig als Hardware-Ausführungsform, vollständig als Software-Ausführungsform (einschließlich Firmware, residenter Software, Mikro-Code usw.) oder als eine Ausführungsform ausgebildet ein, die Software- und Hardware-Aspekte kombiniert, die hierin allesamt im Allgemeinen als „Schaltung”, „Modul” oder ”System” bezeichnet werden können. Des Weiteren können Aspekte der vorliegenden Erfindung als Computerprogrammprodukt ausgebildet sein, das in einem oder mehreren computerlesbaren Medium oder Medien mit einem darin ausgebildeten z. B. darauf gespeicherten computerlesbaren Programmcode ausgebildet ist.
Es kann jede beliebige Kombination aus einem oder mehreren computerlesbaren Medium (Medien) verwendet werden. Bei dem computerlesbaren Medium kann es sich um ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium handeln. Ein computerlesbares Speichermedium kann zum Beispiel ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem, solche Vorrichtung oder Einheit oder jede beliebige geeignete Kombination der vorstehend Genannten sein, ohne darauf beschränkt zu sein. Zu konkreteren Beispielen (eine ergänzbare Liste) des computerlesbaren Speichermediums würden die Folgenden gehören: eine elektrische Verbindung mit einem oder mehreren Kabeln, eine tragbare Computerdiskette, eine Festplatte, ein Arbeitsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM oder Flash-Speicher), ein Lichtwellenleiter, ein tragbarer CD-Nur-Lesespeicher (CD-ROM), eine optische Speichereinheit, eine magnetische Speichereinheit oder jede beliebige geeignete Kombination der vorstehend Genannten. Im Kontext dieses Dokumentes kann es sich bei einem computerlesbaren Speichermedium um jegliches materielle Medium handeln, das ein Programm zur Verwendung durch ein oder im Zusammenhang mit einem Befehlsausführungssystem, einer solchen Vorrichtung oder Einheit enthalten oder speichern kann.
Ein computerlesbares Signalmedium kann ein weitergegebenes Datensignal mit einem darin enthaltenen, computerlesbaren Programmcode, beispielsweise im Basisband oder als Teil einer Trägerwelle sein. Solch ein weitergegebenes Signal kann jede beliebige einer Reihe verschiedener Formen, einschließlich elektromagnetischer, optischer oder jeder beliebigen geeigneten Kombination daraus, jedoch nicht darauf beschränkt, umfassen. Ein computerlesbares Signalmedium kann jegliches computerlesbare Medium sein, das kein computerlesbares Speichermedium ist und das ein Programm zur Verwendung durch oder im Zusammenhang mit einem Befehlsausführungssystem, solcher Vorrichtung oder Einheit ein Programm übertragen, weitergeben oder senden kann.
Der in einem computerlesbaren Medium enthaltene Programmcode kann unter Verwendung eines jeden beliebigen geeigneten Mediums, unter anderem kabellos, kabelbasiert, Lichtwellenleiter, HF usw. oder jeder beliebigen geeigneten Kombination der vorstehend Genannten, jedoch nicht darauf beschränkt, übertragen werden.
Der in einem computerlesbaren Medium enthaltene Programmcode kann unter Verwendung eines jeden beliebigen geeigneten Mediums, unter anderem kabellos, kabelbasiert, Lichtwellenleiter, HF usw. oder jeder beliebigen geeigneten Kombination der vorstehend Genannten, jedoch nicht darauf beschränkt, übertragen werden. Der Computerprogrammcode zum Durchführen der Operationen für Aspekte der vorliegenden Erfindung kann in jeder beliebigen Kombination einer oder mehrerer Programmiersprachen unter anderem einer objektorientierten Programmiersprache wie beispielsweise Java, Smalltalk, C++ oder Ähnlichen oder herkömmlichen prozeduralen Programmiersprachen wie beispielsweise der Programmiersprache „C” oder ähnlichen Programmiersprachen geschrieben werden. Der Programmcode kann vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als ein Stand-Alone-Softwarepaket, teilweise auf dem Computer des Benutzers und teilweise auf einem fernen Computer oder vollständig auf dem fernen Computer oder Server ausgeführt werden. In dem letzten Szenarium kann der ferne Computer über jeden beliebigen Typ von Netzwerk, unter anderem einem lokalen Netz (LAN), oder einem Weitverkehrsnetz (WAN) mit dem Computer des Benutzers verbunden sein, oder die Verbindung kann zu einem externen Computer (z. B. über das Internet unter Verwendung eines Internet-Dienstanbieters) hergestellt werden.
Aspekte der vorliegenden Erfindung werden vorstehend in Bezug auf Veranschaulichungen in Ablaufplänen und/oder Blockschaubildern zu Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es ist offensichtlich, dass jeder Block der Ablaufplanveranschaulichungen und/oder der Blockschaubilder sowie Kombinationen von Blöcken in den Ablaufplanveranschaulichungen und/oder den Blockschaubildern von Computerprogrammanweisungen implementiert werden können. Diese Computerprogrammanweisungen können einem Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung zum Herstellen einer Maschine auf eine Weise bereitgestellt werden, dass die Anweisungen, die über den Prozessor des Computers oder der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, Mittel zum Implementieren der Funktionen/Schritte erstellen, die in dem Block oder den Blöcken der Ablaufpläne und/oder der Blockschaubilder spezifiziert werden.
Diese Computerprogrammanweisungen können auch auf einem computerlesbaren Medium gespeichert werden, das einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten anweisen kann, auf eine bestimmte Weise so zu funktionieren, dass die auf dem computerlesbaren Medium gespeicherten Anweisungen einen Herstellungsartikel produzieren, der Anweisungen aufweist, welche die Funktion/den Schritt implementieren, die oder der in dem Block oder den Blöcken der Ablaufpläne und/oder der Blockschaubilder spezifiziert ist.
Die Computerprogrammanweisungen können auch auf einen Computer, andere programmierbare Datenverarbeitungsvorrichtungen oder andere Einheiten geladen werden, um eine Reihe von Arbeitsschritten zu veranlassen, die auf dem Computer, anderen programmierbaren Datenverarbeitungsvorrichtungen oder Einheiten auszuführen sind, um ein computerimplementiertes Verfahren so zu schaffen, dass die Anweisungen, die auf dem Computer oder anderen programmierbaren Vorrichtungen ausgeführt werden, Prozesse zum Implementieren der in dem Ablaufplan und/oder dem oder den Block oder Blöcken des Blockschaltbildes spezifizierten Funktionen/Schritte bereitstellen.
Der Ablaufplan und die Blockschaubilder in den Figuren veranschaulichen die Architektur, Funktionalität und Funktionsweise möglicher Implementierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedener Ausführungsformen der vorliegenden Erfindung. In dieser Hinsicht kann jeder Block in dem Ablaufplan oder den Blockschaubildern ein Modul, Segment oder einen Codeabschnitt darstellen, der eine oder mehrere ausführbare Anweisungen zum Implementieren der spezifizierten logischen Funktion(en) aufweist. Es sollte darüber hinaus beachtet werden, dass in einigen alternativen Implementierungen die in den Blöcken angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren angegeben auftreten. So können beispielsweise zwei nacheinander auftretend dargestellte Blöcke tatsächlich auch im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal auch in umgekehrter Reihenfolge je nach der beteiligten Funktion ausgeführt werden. Es ist des Weiteren zu beachten, dass jeder Block der Blockschaubilder und/oder der Ablaufplanveranschaulichungen und Kombinationen aus Blöcken in den Blockschaubildern und/oder den Ablaufplanveranschaulichungen von speziellen hardwarebasierten Systemen oder Kombinationen aus speziellen hardwarebasierten Systemen und Computeranweisungen implementiert werden können, die die spezifizierten Funktionen oder Schritte durchführen.
Eine oder mehrere in dieser Patentschrift offenbarten Ausführungsformen betreffen die Stream-Verarbeitung und insbesondere Stream-Verarbeitung unter Verwendung einer Art von Client-Server-Architektur. Gemäß der einen oder der mehreren hierin offenbarten Ausführungsformen kann ein System implementiert werden, das eine Funktionalität eines Hypertext-Transfer-Protocol(HTTP)-Servers innerhalb eines Stream-Verarbeitungssystems aufweist. Die Einbeziehung der HTTP-Server-Funktionalität gemäß dieser Patentschrift ermöglicht die Verwendung einer Datenverarbeitungstechnologie innerhalb von herkömmlicheren Systemen, ohne dass bereits vorhandene HTTP-Server umgestaltet werden müssen. Das Stream-Verarbeitungssystem kann als ein Web-Service arbeiten, der für Dienstanforderungen verfügbar ist, die über eine Art von Client-Server-Architektur ausgegeben werden.
1 ist ein erstes Blockschaubild, das ein beispielhaftes Datenverarbeitungssystem (System) 100 veranschaulicht. Das System 100 kann wenigstens einen Prozessor 105 aufweisen, der über einen Systembus 115 mit Speicherelementen 110 verbunden ist. Als solches kann das System 100 einen Programmcode in den Speicherelementen 110 speichern. Der Prozessor 105 kann den Programmcode ausführen, auf den von den Speicherelementen 110 über den Systembus 115 zugegriffen wird. In einem Aspekt kann das System 100 beispielsweise als Computer implementiert sein, der zum Speichern und/oder Ausführen des Programmcodes geeignet ist. Es sollte jedoch beachtet werden, dass das System 100 auch in Form eines jeden beliebigen Systems, das einen Prozessor und einen Speicher aufweist, implementiert werden kann, das zum Durchführen der in dieser Patentschrift beschriebenen Funktionen geeignet ist.
Zu den Speicherelementen 110 können eine oder mehrere physische Speichereinheiten wie beispielsweise ein lokaler Speicher 120 sowie eine oder mehrere Massenspeicher 125 gehören. Der lokale Speicher 120 bezieht sich auf einen Arbeitsspeicher oder (eine) andere flüchtige Speichereinheit(en), die im Allgemeinen während der Ausführung des Programmcodes verwendet werden. Die Massenspeichereinheit 125 kann als Laufwerk oder eine andere nichtflüchtige Datenspeichereinheit implementiert werden. Das System 100 kann des Weiteren einen oder mehrere Cachespeicher (nicht dargestellt) aufweisen, die vorübergehendes Speichern von wenigstens irgendeinem Programmcode gewährleisten, um die Anzahl an Malen zu verringern, mit denen der Programmcode während der Ausführung von der Massenspeichereinheit 125 abgerufen werden muss.
Eingabe/Ausgabeeinheiten (E/A), die als Eingabeeinheit 130 und Ausgabeeinheit 135 dargestellt sind, können optional mit dem System 100 verbunden sein. Zu Beispielen der Eingabeeinheit 130 können beispielsweise eine Tastatur, eine Zeigeeinheit wie beispielsweise eine Maus oder Ähnliches, jedoch nicht darauf beschränkt, gehören. Zu Beispielen der Ausgabeeinheit 135 können beispielsweise ein Monitor oder ein Display, Lautsprecher oder Ähnliches, jedoch nicht darauf beschränkt, gehören. Die Eingabeeinheit 130 und/oder die Ausgabeeinheit 135 können entweder direkt oder indirekt über Zwischenschalten von E/A-Controllern mit dem System 100 verbunden sein. Es kann auch ein Netzwerkadapter 140 mit dem System 100 verbunden sein, so dass das System 100 mit anderen Systemen, Computersystemen, fernen Druckern und/oder fernen Speichereinheiten über das Zwischenschalten privater oder öffentlicher Netzwerke verbunden werden kann. Modems, Kabelmodems und Ethernet-Karten sind Beispiele verschiedener Typen von Netzwerkadaptern 140, die mit dem System 100 verwendet werden können.
Wie dies in 1 dargestellt ist, können Speicherelemente 110 eine Anwendung 145 speichern. Hierbei sollte beachtet werden, dass das System 100 des Weiteren ein Betriebssystem (nicht dargestellt) ausführen kann, das die Ausführung der Anwendung 145 ermöglicht. Die Anwendung 145, die in Form eines ausführbaren Programmcodes implementiert ist, kann von dem System 100 beispielsweise von dem Prozessor 105 ausgeführt werden. In Reaktion auf Ausführen der Anwendung 145 kann das System 100 so konfiguriert sein, dass es eine oder mehrere von hierin in weiteren Einzelheiten beschriebenen Operationen ausführt.
In einem Aspekt kann das System 100 beispielsweise ein Client-Datenverarbeitungssystem darstellen. In diesem Fall kann die Anwendung 145 eine Client-Anwendung darstellen, die bei ihrer Ausführung das System 100 so konfiguriert, dass es die verschiedenen Funktionen durchführt, die hierin in Bezug auf einen „Client” beschrieben werden. Zu Beispielen eines Client können ein Personalcomputer, ein tragbarer Computer, ein Mobiltelefon oder Ähnliches, jedoch nicht darauf beschränkt, gehören.
In einem weiteren Aspekt kann das System 100 einen Server darstellen. So kann das System 100 beispielsweise einen HTTP-Server darstellen, wobei die Anwendung 145 bei ihrer Ausführung das System 100 so konfigurieren kann, dass es HTTP-Server-Operationen durchführt. In einem weiteren Aspekt kann das System 100 einen Stream-Verarbeitungsknoten eines Stream-Verarbeitungssystems wie beispielsweise einen Stream-Verarbeitungsknoten oder einen HTTP-Stream-Server darstellen, die in weiteren Einzelheiten in dieser Patentschrift beschrieben werden. Dementsprechend kann die Anwendung 145 bei ihrer Ausführung das System 100 so konfigurieren, dass es Verarbeitungsknoten-Operationen jeweils in einem HTTP-Stream-Server- und/oder einem Stream-Server durchführt.
2 ist ein Blockschaubild, das ein System 200 zur Stream-Verarbeitung gemäß einer in dieser Patentschrift offenbarten Ausführungsform veranschaulicht. Im Allgemeinen kann ein Stream-Verarbeitungssystem wie das System 200 einen oder mehrere Datenströme empfangen und verarbeiten.
Ein Datenstrom kann sich auf einen Datenfluss beziehen, bei dem es sich um einen konstanten oder nahezu konstanten Datenfluss handelt. In einigen Fällen kann es sich bei dem Datenstrom um einen Echtzeitdatenfluss handeln, da Daten von einem Sensor empfangen werden können, der so konfiguriert ist, dass er kontinuierlich Ergebnisse oder Messreihen ausgibt. In einem weiteren Beispiel kann es sich bei einem Datenstrom um Marktdaten handeln, die in Echtzeit oder Beinahe-Echtzeit aktualisiert und gesendet werden, welche Preise von Wertpapieren angeben. Zu weiteren Beispielen von Datenströmen können Nachrichtenmeldungen, ungeachtet ob als Text, Audio, in visueller oder audiovisueller Form, Diagnostikdaten, Wetterdaten usw. gehören. Ein Datenstrom stellt im Allgemeinen einen relativ konstanten Datenfluss dar, der nicht der herkömmlichen Art von Datenfluss einer Antwort auf eine Client-Server-Anforderung entspricht oder konform mit ihr ist, der normalerweise auf internetbasierten Webseiten vorzufinden ist beziehungsweise implementiert wird. Im Allgemeinen verläuft ein Datenstrom in eine Richtung und aus dem bestimmten Knoten heraus, der den Datenstrom erzeugt.
Wie dies dargestellt ist, kann das System 200 eine Vielzahl von Stream-Verarbeitungsknoten 205, 210, 215, 220 und 225 aufweisen. Jeder der Stream-Verarbeitungsknoten 205 bis 225 kann mittels Datenübertragung über ein Netzwerk verbunden sein. Die Stream-Verarbeitungsknoten 205 und 210 können so konfiguriert sein, dass sie jeweils die Datenströme 230 und 235 empfangen. In einem Aspekt können die Datenströme 230 und/oder 235 von außerhalb des Systems 200 stammen. Im Allgemeinen können die Stream-Verarbeitungsknoten wie beispielsweise die Stream-Verarbeitungsknoten 205 und 210, die Datenströme von Quellen außerhalb des Systems empfangen, als Quellen („sources”) bezeichnet werden. Jeder der Stream-Verarbeitungsknoten 205 bis 225 kann so konfiguriert sein, dass er asynchron arbeitet. So kann beispielsweise jeder der Stream-Verarbeitungsknoten 205 bis 225 so konfiguriert sein, dass er einen separaten Prozessor und eine separate Arbeitswarteschlange aufweist.
Der Stream-Verarbeitungsknoten 205 kann ein Datenverarbeitungsverfahren auf den Datenstrom 230 anwenden, um eine oder mehrere Messgrößen zu ermitteln oder Daten aus dem Datenstrom zu extrahieren. Die resultierenden Messgrößen und/oder extrahierten Daten können an jeden der Stream-Verarbeitungsknoten 215 und 220 weitergeleitet werden, wie dies in Form von ausgegebenen Datenströmen dargestellt ist. Auf ähnliche Weise können die Stream-Verarbeitungsknoten 210 ein Datenverarbeitungsverfahren auf den Datenstrom 235 anwenden, um eine oder mehrere Messgrößen zu ermitteln oder Daten aus dem Datenstrom 235 zu extrahieren. Die resultierenden Messgrößen und/oder extrahierten Daten können an jeden der Stream-Verarbeitungsknoten 215 und 220 weitergeleitet werden, wie dies in Form der ausgegebenen Datenströme dargestellt ist.
Der Stream-Verarbeitungsknoten 215 kann ein Datenverarbeitungsverfahren auf die ausgegebenen Datenströme anwenden, die von den Stream-Verarbeitungsknoten 205 und 210 empfangen werden und die einen oder mehrere ermittelte Messgrößen und/oder extrahierte Daten in Form eines weiteren ausgegebenen Datenstroms an den Stream-Verarbeitungsknoten 225 ausgeben. Auf ähnliche Weise kann der Stream-Verarbeitungsknoten 220 ein Datenverarbeitungsverfahren auf die von den Stream-Verarbeitungsknoten 205 und 210 empfangenen Datenströme anwenden und eine oder mehrere Messgrößen und/oder extrahierte Daten in Form eines weiteren Datenstroms an den Stream-Verarbeitungsknoten 225 ausgeben.
Der Stream-Verarbeitungsknoten 225 kann eine endgültige Entscheidung treffen oder ein Endergebnis auf der Grundlage von von jedem der Stream-Verarbeitungsknoten 215 und 220 empfangenen Daten ermitteln. Der Stream-Verarbeitungsknoten 225 kann des Weiteren so konfiguriert sein, dass er Informationen, z. B. ein Ergebnis an einen Bestimmungsort oder ein anderes Datenverarbeitungssystem sendet. Ein Stream-Verarbeitungsknoten eines Stream-Verarbeitungssystems, der zum Senden von Informationen außerhalb des Systems konfiguriert ist, kann als „Datensenke” (sink) bezeichnet werden.
In einer Ausführungsform kann das System 200, bei dem es sich um ein Stream-Verarbeitungssystem handelt, dadurch charakterisiert sein, dass wenig, wenn überhaupt irgendwelche Daten, die von den Stream-Verarbeitungsknoten 205 bis 225 verarbeitet werden, gespeichert werden müssen. In einem herkömmlichen System, das einer Client-Server-Architektur entspricht, können große Mengen an Daten empfangen und gespeichert werden. Normalerweise werden Daten in einer Datenbank gespeichert. Anfragen können anschließend an der Datenbank ausgeführt werden, wodurch der/die Server große Mengen an langfristigen oder feststehendem Speicherplatz aufweisen muss/müssen.
Im Vergleich dazu kann das System 200 an den empfangenen Datenströmen 230 und 235 arbeiten, ohne dass Daten von den Datenströmen 230 und/oder 235 gespeichert werden müssen. Jeder der Stream-Verarbeitungsknoten 205 bis 225 kann so konfiguriert sein, dass er einen Datenstrom empfängt, Verarbeitung an diesem Datenstrom ausführt und einen ausgegebenen Datenstrom erzeugt, der einem oder mehreren weiteren Knoten gesendet oder diesen bereitgestellt wird. Dennoch sollte beachtet werden, dass ein oder mehrere Zwischenergebnisse und/oder endgültige Ergebnisse in ihrer von einem oder mehreren der Stream-Verarbeitungsknoten 205 bis 225 ermittelten Form bei entsprechendem Wunsch gespeichert werden können.
Die verschiedenen von den Stream-Verarbeitungsknoten 205 bis 225 erzeugten Datenströme können Anforderungen oder andere Mitteilungen innerhalb eines jeden jeweiligen Datenstroms, der ausgegeben wird, aufweisen. Die Mitteilungen ermöglichen den Stream-Verarbeitungsknoten 205 bis 225 beispielsweise die Datenübertragung bestimmter funktionsrelevanter Daten und/oder von Anweisungen in Bezug auf Systemebenenfunktionen oder Betriebszuständen der Stream-Verarbeitungsknoten 205 bis 225.
In einem Aspekt kann jeder der Stream-Verarbeitungsknoten 205 bis 225 in einem unterschiedlichen Datenverarbeitungssystem implementiert werden. Es besteht jedoch nicht die Absicht, dass die eine oder mehreren Ausführungsformen in dieser Patentschrift in dieser Hinsicht beschränkt sind. In einem weiteren Aspekt können beispielsweise ein oder mehrere Stream-Verarbeitungsknoten 205 bis 225 in demselben Datenverarbeitungssystem implementiert sein. So können beispielsweise zwei oder mehr Stream-Verarbeitungsknoten wie beispielsweise Stream-Verarbeitungsknoten 215 und Stream-Verarbeitungsknoten 220 in einem einzigen Datenverarbeitungssystem implementiert sein.
Wie dies in 2 dargestellt ist, kann das System 200 Datenströme in den Stream-Verarbeitungsknoten 205 und 210 (Quellen) empfangen und ein Ergebnis von dem Stream-Verarbeitungsknoten 225 (Senke) senden. Das System 200 unterscheidet sich von herkömmlichen Client-Server-Systemen, bei denen die Anforderung von einem Client von einem Knoten empfangen wird, der gleichzeitig auch dem Client eine Antwort zurück bereitstellt. Durch Bereitstellen der Antwort an den Client von demselben Knoten, der die Anforderung empfängt, kann Affinität in Form einer Verbindung oder einer Datenübertragungsverbindung zwischen Client und Server aufrechterhalten werden. In einem herkömmlichen Stream-Verarbeitungssystem fließen die Daten, wie dies in Bezug auf 2 dargestellt ist, in einen oder mehrere Stream-Verarbeitungsknoten und treten aus einem oder mehreren Stream-Verarbeitungsknoten heraus. Dementsprechend ist das Aufrechterhalten von Affinität mit einem Client zum Unterstützen eines Transaktionsmodells des Anforderungs-Antwort-Typs, das in Client-Server-Systemen verwendet wird, in herkömmlichen Stream-Verarbeitungssystemen nicht machbar.
Damit sich ein Stream-Datenverarbeitungssystem wie ein Web-Service verhalten kann, der das Client-Server-Modell oder solch eine Architektur befolgen kann, muss Affinität zwischen Client und Quelle sowie zwischen Client und Senke des Stream-Verarbeitungssystems so aufrechterhalten werden, dass die Senke den bestimmten Client kennt, an den das Ergebnis gesendet werden soll. In einer Ausführungsform kann Affinität mit einem anfordernden Client dadurch aufrechterhalten werden, dass Client-Kontextinformationen zwischen den Stream-Verarbeitungsknoten so weitergegeben werden, dass die Zugehörigkeit zwischen den Stream-Verarbeitungsknoten und dem Client und/oder der Client-Anforderung nicht verloren geht. Um beispielsweise die Fähigkeit aufrechtzuerhalten, einem anfordernden Client eine Antwort bereitzustellen, kann die von einem jeden der Stream-Verarbeitungsknoten 205 bis 225 erzeugte Ausgabe Kontextinformationen für die bestimmte Client-Anforderung aufweisen, die die Durchführung der Stream-Verarbeitung initiiert hat. Wird Affinität, z. B. Kontextinformationen für eine empfangene Client-Anforderung, die den Client sowie den Ort identifiziert, an den eine Antwort gesendet werden soll, aufrechterhalten, kann das Stream-Verarbeitungssystem ermitteln, wohin die Client-Antwort gesendet werden soll.
3 ist ein Blockschaubild, das ein System 300 zur Stream-Verarbeitung gemäß einer in dieser Patentschrift offenbarten Ausführungsform veranschaulicht. Wie dies dargestellt ist, kann das System 300 einen HTTP-Server 305, einen HTTP-Stream-Server (Stream-Server) 310 und einen oder mehrere Stream-Verarbeitungsknoten mit der Bezeichnung 1 bis N aufweisen, wobei „N” ein Ganzzahlwert größer als Eins oder gleich Eins ist. Hierbei sollte beachtet werden, dass, obgleich das System 300 mit drei enthaltenen Stream-Verarbeitungsknoten dargestellt ist, z. B. den Stream-Verarbeitungsknoten 1, 2, .... N, das System 300 auch weniger Stream-Verarbeitungsknoten, z. B. 1 oder 2 oder mehr Stream-Verarbeitungsknoten aufweisen kann, die zur Stream-Verarbeitung gemäß Beschreibung in Bezug auf 2 konfiguriert sind. Der HTTP-Server 305, der Stream-Server 310 und die Stream-Verarbeitungsknoten 1, 2, ..., N können mittels Datenübertragung über ein Netzwerk verbunden sein.
Im Allgemeinen veranschaulicht das System 300 eine Ausführungsform bei der Client-Kontextinformationen zum Aufrechtherhalten von Affinität zwischen einem anfordernden Client (nicht dargestellt), z. B. dem Client, der die Client-Anforderung ausgibt, und der Quelle und Senke des Systems 300 verwendet werden. In dem System 300 kann der Stream-Server 310 so konfiguriert sein, dass er sowohl als Quelle als auch als Senke zur Unterstützung beim Verarbeiten von HTTP-Anforderungen fungieren kann. Durch Weiterreichen der Client-Kontextinformationen von dem HTTP-Server 305 an den Stream-Server 310 und zwischen den Stream-Verarbeitungsknoten 1, 2, ..., N des Systems 300 während des Auftretens von Stream-Verarbeitung können die Stream-Verarbeitungsergebnisse mit der ursprünglichen Client-Anforderung korreliert und wieder dem Client bereitgestellt werden. Wie dies beschrieben wurde, kann jeder der Stream-Verarbeitungsknoten 1, 2, ..., N so konfiguriert sein, dass er asynchron arbeitet. Durch eine kooperative Arbeitsweise von HTTP-Server 305 und Stream-Server 310 kann das System 300 wenigstens gegenüber externen Systemen wie beispielsweise dem Client als synchrones System erscheinen.
Der HTTP-Server 305 kann so konfiguriert sein, dass er eine Client-Anforderung 315 von dem Client empfängt. Die Client-Anforderung 315 kann anfordern, dass Daten von einem Stream-Verarbeitungssystem wie beispielsweise System 300 berechnet oder ermittelt werden. In einem Aspekt kann der HTTP-Server 305 einen Verarbeitungs-Thread zuweisen, um die Verarbeitung der Client-Anforderung 315 zu bearbeiten. Der Verarbeitungs-Thread zum Bearbeiten der Client-Anforderung 315 kann durch eine Thread-Kennung in dem HTTP-Server 305 identifiziert werden.
In dem Verarbeitungs-Thread kann der HTTP-Server 305 eine Rückverbindung 320 zu dem Client erstellen. So kann der HTTP-Server 305 beispielsweise so konfiguriert sein, dass er eine Rückverbindung 320 in Form eines TCP/IP-Socket zum Senden einer Client-Antwort 375 von dem HTTP-Server 305 an den Client erstellt. Der HTTP-Server 305 kann beispielsweise die Rückverbindung unter Verwendung der Client-Adresse und des Client-Anschlusses erstellen. Hierbei sollte beachtet werden, dass der Thread zum Bearbeiten der Client-Anforderung 315, der zudem für das Erstellen der Rückverbindung 320 zuständig ist, die Rückverbindung 320 auch effektiv speichert. So kann der Verarbeitungs-Thread in dem HTTP-Server 305 beispielsweise die Rückverbindungsinformationen, z. B. die Informationen, die zum Erstellen der Rückverbindung 320 erforderlich sind, speichern oder einfügen.
Der HTTP-Server 305 kann des Weiteren dem Stream-Server 310 eine Server-Anforderung 325 unterbreiten. Die Server-Anforderung 325 kann Client-Kontextinformationen aufweisen. In einer Ausführungsform können die von der Server-Anforderung 325 spezifizierten Kontextinformationen einige oder alle der Client-Anforderung 315 aufweisen. In einem Aspekt können die Client-Kontextinformationen auch die Rückverbindungsinformationen, z. B. eine Rückverbindungsreferenz oder sonstige Informationen aufweisen, die die Rückverbindung 320 zu dem Client identifizieren. In einem Beispiel können die Rückverbindungsinformationen als Thread-Kennung spezifiziert werden oder als solche gesendet werden, die den Verarbeitungs-Thread in dem HTTP-Server 305 spezifiziert, der die Client-Anforderung 315 bearbeitet. Dadurch, dass der HTTP-Server 305 die Client-Kontextinformationen bereitstellt, kann der Stream-Server 310 Affinität mit dem Client aufrechterhalten, obwohl er keinerlei Client-Anforderungen direkt von dem Client empfängt.
In einem Beispiel kann die Server-Anforderung 325 in Form eines ”Handle”-Verfahrens implementiert sein. Der HTTP-Server 305 kann ein Anforderungsobjekt und ein Antwortobjekt erstellen, die die Client-Kontextinformationen spezifizieren. So kann das Anforderungsobjekt beispielsweise die gesamte Client-Anforderung, einen Abschnitt der Client-Anforderung, einen oder mehrere Parameter der Client-Anforderung wie beispielsweise Cookies und/oder weitere damit zusammenhängende Client-Informationen aufweisen. Das Antwortobjekt kann die Rückverbindungsinformationen für die Client-Anforderung spezifizieren. So kann das Antwortobjekt beispielsweise die Client-Adresse und den Anschluss des Return-TCP/IP-Socket spezifizieren. In einem weiteren Beispiel kann, wie dies bereits angemerkt wurde, das Antwortobjekt die Thread-Kennung spezifizieren.
Das Anforderungsobjekt und das Antwortobjekt können von dem HTTP-Server 305 an einen oder mehrere andere Verarbeitungsknoten, z. B. den Stream-Server 310 weitergeleitet werden. Der HTTP-Server 305 kann das Handle-Verfahren aufrufen und dem Stream-Server in Reaktion auf die Client-Anforderung 315 und die Erstellung der Rückverbindung 320 ein oder mehrere Argumente weiterleiten, z. B. das Anforderungsobjekt und das Antwortobjekt. In einer Ausführungsform kann der HTTP-Server 305 so konfiguriert sein, dass er das Handle-Verfahren so lange blockiert, bis das Handle-Verfahren zurückkehrt. So kann beispielsweise der Verarbeitungs-Thread, in dem das Bearbeitungsverfahren ausgeführt wird, in einen Leerlauf versetzt werden.
Der Verarbeitungs-Thread in dem HTTP-Server 305 kann unter Verwendung eines beliebigen von einer Reihe verschiedener bekannter Programmierungsverfahren in einen Leerlauf versetzt werden. Beispielsweise können Bedingungsvariablen verwendet werden, um einen Verarbeitungs-Thread in den Leerlauf zu versetzen. Der Verarbeitungs-Thread, der in den Leerlauf versetzt wird, wartet effektiv darauf, dass sich der Wert einer Bedingungsvariablen ändert, womit der Eintritt in einen Ruhe- oder Leerlaufzustand erfolgt. Tritt ein Ereignis wie beispielsweise die Rückkehr des Handle-Verfahrens im Hinblick auf das Empfangen des Stream-Verarbeitungsergebnisses von dem Stream-Server 310 auf, kann ein weiterer Verarbeitungs-Thread, der aktiv ist, dem sich im Leerlauf befindlichen Verarbeitungs-Thread, der darauf wartet, dass sich die Bedingungsvariable ändert, signalisieren, aktiv zu werden. Dementsprechend kann der in den Leerlauf versetzte Thread „erwachen” und seine Aktivität wiederaufnehmen.
Der Stream-Server 310 kann so konfiguriert sein, dass er das von dem HTTP-Server 315 empfangene Antwortobjekt als Teil der Server-Anforderung 325 mit Daten füllt. Kehrt das Handle-Verfahren zurück, z. B. wenn der Stream-Server 310 das mit Daten gefüllte Antwortobjekt zurück an den HTTP-Server 305 sendet, kann der HTTP-Server 305 so konfiguriert sein, dass er eine Client-Antwort 375 zurück an den Client 375 sendet.
Weiterhin kann der Stream-Server 310, in Reaktion auf die Server-Anforderung 325, eine Operation zum Erstellen einer Anforderungskennung 330 durchführen, die eine Anforderungskennung erstellt. Der Stream-Server 310 kann beispielsweise eine Anforderungskennung erstellen, die eindeutig die Server-Anforderung 325 identifiziert, beziehungsweise ihr und demzufolge der Client-Anforderung 315 entspricht. In einer Ausführungsform kann die Anforderungskennung, bei der es sich um einen Ganzzahlwert handeln kann, unter Verwendung einer Hash-Funktion erzeugt werden. So kann der Stream-Server 310 Client-Kontextinformationen zerlegen (hash), die beispielsweise von dem Anforderungsobjekt, dem Antwortobjekt oder von sowohl dem Anforderungsobjekt als auch dem Antwortobjekt hergeleitet wurden.
Der Stream-Server 305 kann eine Speicheroperation 335 durchführen, bei der der Stream-Server 310 die Anforderungskennung, die zu den in der Server-Anforderung 325 empfangenen Client-Kontextinformationen gehört, speichert. Beispielsweise kann der Stream-Server 310 die Client-Kontextinformationen oder einen Abschnitt davon in dem in dem Arbeitsspeicher gespeicherten Kontextwörterbuch speichern. Das Kontextwörterbuch kann entsprechend der Anforderungskennung verschlüsselt werden. Dementsprechend kann die Anforderungskennung verwendet werden, um eine Indexierung zu dem Kontextwörterbuch bereitzustellen, um bei Bedarf die dazugehörigen Kontextinformationen abzurufen. Die gespeicherten Client-Kontextinformationen können das Antwortobjekt und/oder die Thread-Kennung aufweisen. In Reaktion auf das Empfangen irgendwelcher Stream-Verarbeitungsergebnisse von den Stream-Verarbeitungsknoten 1, 2, ..., N, die beispielsweise eine Anforderungskennung aufweisen, kann der Stream-Server 310 die empfangenen Stream-Verarbeitungsergebnisse mit den geeigneten Informationen zu Server-Anforderung, Client, Client-Anforderung und/oder Rückverbindung auf der Grundlage der Anforderungskennung in den Stream-Verarbeitungsergebnissen korrelieren.
Nachdem die Anforderungskennung erzeugt und gespeichert worden ist, kann der Stream-Server 310 so konfiguriert sein, dass er eine Anforderung zur Stream-Verarbeitung 340 an den Stream-Verarbeitungsknoten 1 sendet. In einem Beispiel kann es sich bei der Anforderung zur Stream-Verarbeitung 340 um ein „Wiedergabe”-(render)Verfahren handeln, das von dem Stream-Server 310 zwischen den Stream-Verarbeitungsknoten 1, 2, ..., N weitergeleitet wird. Das Wiedergabeverfahren kann eine Vielzahl von Parametern aufweisen, einschließlich einer universellen Ressourcenkennung (URI, universal resource identifier) oder eines universellen Quellenanzeigers (URL, universal ressource locator), einer Client-Anforderung 315 oder eines Abschnittes davon (z. B. Parameter der Client-Anforderung 315 wie beispielsweise Cookies) und der von dem Stream-Server 310 erzeugten Anforderungskennung.
Wie dies dargestellt ist, kann der Stream-Verarbeitungsknoten 1 so konfiguriert sein, dass er einen Datenstrom empfängt, der als „anderer Datenstrom” bezeichnet wird, um zu veranschaulichen, dass zusätzlich zu dem Erzeugen von Datenströmen zwischen den Stream-Verarbeitungsknoten 1, 2, ..., N. ein oder mehrere der Stream-Verarbeitungsknoten 1, 2, ..., N einen Datenstrom von einem externen Knoten, z. B. einem anderen System, Sensor oder Ähnlichem empfangen kann. Auf jeden Fall kann jeder der Stream-Verarbeitungsknoten 1, 2, ..., N so konfiguriert sein, dass er wenigstens einen ausgegebenen Datenstrom von einem anderen Stream-Verarbeitungsknoten des Systems 300 verarbeiten kann.
In Reaktion auf Empfangen der Anforderung zur Stream-Verarbeitung 340 kann der Stream-Verarbeitungsknoten 1 so konfiguriert sein, dass er eine oder mehrere Stream-Verarbeitungsfunktionen durchführt und eine Teilantwort erzeugt. Die Teilantwort von dem Stream-Verarbeitungsknoten 1, die als Teilantwort 1 bezeichnet wird, kann in eine weitere Anforderung zur Stream-Verarbeitung 345 eingesetzt werden, die erzeugt und von dem Stream-Verarbeitungsknoten 1 an den Stream-Verarbeitungsknoten 2 gesendet werden kann. So kann der Stream-Verarbeitungsknoten 1 beispielsweise die Anforderung zur Stream-Verarbeitung 345 erzeugen und senden. Die Anforderung zur Stream-Verarbeitung 345 kann in Form eines weiteren Wiedergabeverfahrens, das Argumente wie beispielsweise die URI oder die URL des Stream-Servers 310 aufweist, als Client-Anforderung 315 oder ein Abschnitt davon, als die von dem Stream-Server 310 erzeugte Anforderungskennung und als Teilantwort 1 implementiert sein.
In Reaktion auf Empfangen der Anforderung zur Stream-Verarbeitung 345 kann der Stream-Verarbeitungsknoten 2 so konfiguriert sein, dass er eine oder mehrere Stream-Verarbeitungsfunktionen durchführt und eine Teilantwort erzeugt. Die Teilantwort von dem Stream-Verarbeitungsknoten 2, die als Teilantwort 2 bezeichnet wird, kann in eine weitere Anforderung zur Stream-Verarbeitung 350 eingesetzt werden, die erzeugt und in diesem Beispiel von dem Stream-Verarbeitungsknoten 2 an den Stream-Verarbeitungsknoten N gesendet wird. So kann der Stream-Verarbeitungsknoten 2 beispielsweise die Anforderung zur Stream-Verarbeitung 350 erzeugen und senden. Die Anforderung zur Stream-Verarbeitung 350 kann in Form eines weiteren Wiedergabeverfahrens, das Argumente wie beispielsweise die URI oder die URL des Stream-Servers 310 aufweist, als Client-Anforderung 315 oder ein Abschnitt davon, als die von dem Stream-Server 310 erzeugte Anforderungskennung und als Teilantwort 2 implementiert sein.
In Reaktion auf das Empfangen der Anforderung zur Stream-Verarbeitung 350 kann der Stream-Verarbeitungsknoten N so konfiguriert sein, dass er eine oder mehrere Stream-Verarbeitungsfunktionen durchführt und eine Teilantwort erzeugt. Die Teilantwort von dem Stream-Verarbeitungsknoten, die als Teilantwort N bezeichnet wird, kann in eine Mitteilung zum Erstellen einer Antwort 355 eingesetzt werden, die von dem Stream-Verarbeitungsknoten N an den Stream-Server 310 gesendet werden kann. Die Mitteilung zum Erstellen einer Antwort 355 kann beispielsweise die Anforderungskennung und einen Antwortkörper aufweisen beziehungsweise spezifizieren. Der Antwortkörper kann als eine vollständige Antwort, z. B. ein Stream-Verarbeitungsergebnis in einer Antwort auf die Client-Anforderung 315 erachtet werden. Genauer gesagt kann der Antwortkörper die Teilantwort 1, die Teilantwort 2, ...., die Teilantwort N aufweisen, womit das Stream-Verarbeitungsergebnis gebildet wird.
In einer weiteren Ausführungsform muss nicht jeder Knoten eine Teilantwort beisteuern, die in das Stream-Verarbeitungsergebnis eingesetzt wird. So können beispielsweise ein oder mehrere Stream-Verarbeitungsknoten so konfiguriert sein, dass sie Zwischenergebnisse erzeugen, die von anderen nachgeschalteten („downstream”) Stream-Verarbeitungsknoten verwendet oder verbraucht werden. Die Zwischenergebnisse müssen nicht in das Stream-Verarbeitungsergebnis eingesetzt werden. In dieser Hinsicht kann jedoch immer noch davon ausgegangen werden, dass solch ein Stream-Verarbeitungsknoten dennoch eine Teilantwort zu dem Stream-Verarbeitungsergebnis beigesteuert hat.
Hierbei sollte beachtet werden, dass die verschiedenen Knoten des Systems 300 wie beispielsweise der Stream-Verarbeitungsknoten 1, der Stream-Verarbeitungsknoten 2 bis Stream-Verarbeitungsknoten N so konfiguriert oder programmiert sein können, dass sie eine Ausgabe an einen bestimmten anderen Knoten leiten. So kann der Stream-Verarbeitungsknoten 1 beispielsweise so konfiguriert sein, dass er einen ausgegebenen Datenstrom, der die Anforderung zur Stream-Verarbeitung 345 aufweist, an den Stream-Verarbeitungsknoten 2 leitet. Der Stream-Verarbeitungsknoten 2 kann so konfiguriert sein, dass er einen ausgegebenen Datenstrom, der die Anforderung zur Stream-Verarbeitung 350 aufweist, an den Stream-Verarbeitungsknoten N leitet. Der Stream-Verarbeitungsknoten N kann als letzter der Stream-Verarbeitungsknoten konfiguriert werden und als solcher so konfiguriert sein, dass er eine Mitteilung zum Erstellen einer Antwort 355 an den Stream-Server 310 sendet.
Weiterhin kann der Stream-Server 310 in Reaktion auf Empfangen der Mitteilung zum Erstellen einer Antwort 355 so konfiguriert sein, dass er eine Operation zum Abrufen einer Antwort 360 durchführt. Die Operation zum Abrufen einer Antwort 360 kann die vorher gespeicherten Client-Kontextinformationen abrufen. Wie dies beschrieben wurde, kann die Mitteilung zum Erstellen einer Antwort 355 die Anforderungskennung spezifizieren, die für eine Indexierung zum Kontextwörterbuch verwendet werden kann, um die gespeicherten Client-Kontextinformationen abzurufen.
Der Stream-Server 310 kann des Weiteren eine Mitteilung zum Schreiben einer Antwort 365 erzeugen und an den HTTP-Server 305 senden. Der Stream-Server 310 kann eine Mitteilung zum Schreiben einer Antwort 365 erzeugen, die abgerufene Client-Kontextinformationen, z. B. die Thread-Kennung und den Antwortkörper spezifizieren. So kann der Stream-Server 305 beispielsweise das Stream-Verarbeitungsergebnis gemäß Spezifizierung in dem von dem Stream-Verarbeitungsknoten N empfangenen Antwortkörper in dem Antwortobjektabschnitt der Client-Kontextinformationen mit Daten füllen, die von dem Kontextwörterbuch abgerufen wurden und die resultierende Mitteilung in Form der Mitteilung zum Schreiben einer Antwort 365 an den HTTP-Server 305 weiterleiten. Wie dies beschrieben wurde, kann die Mitteilung zum Schreiben einer Antwort 365 des Weiteren die Thread-Kennung spezifizieren. In einer Ausführungsform kann die Thread-Kennung in dem Antwortobjekt enthalten sein, das in dem Kontextwörterbuch gespeichert ist. In dieser Hinsicht kann die Thread-Kennung in dem Antwortobjekt bereits vor dem Füllen des Antwortkörpers mit Daten enthalten sein.
In einer Ausführungsform kann die Mitteilung zum Schreiben einer Antwort 365 als Rückkehr des Handle-Verfahrens an den HTTP-Server 305 erachtet werden. In Reaktion auf das Empfangen der Mitteilung zum Schreiben einer Antwort 365 kann der HTTP-Server 305 so konfiguriert sein, dass das Handle-Verfahren blockiert und der Betrieb fortgesetzt wird, um auf die Client-Anforderung 315 zu antworten. Wie dies beschrieben wurde, kann der HTTP-Server 305 beispielsweise den in Leerlauf versetzten Verarbeitungs-Thread gemäß Festlegung anhand der Thread-Kennung erwecken, die in der Mitteilung zum Schreiben einer Antwort 365 empfangen wurde. Der HTTP-Server 305 kann nach dem Erwecken des durch die Thread-Kennung spezifizierten Verarbeitungs-Threads das Verarbeiten der Client-Anforderung 315 fortsetzen, um eine Client-Antwort 375 zu erzeugen und an den Client zu senden. Wie dies beschrieben wurde, weist der Verarbeitungs-Thread Informationen zur Rückverbindung 320 auf oder spezifiziert diese, über die der HTTP-Server 305 die Client-Antwort 375 senden kann. Die Client-Antwort 375 kann das Stream-Verarbeitungsergebnis gemäß Festlegung durch das System 300, z. B. durch den Stream-Verarbeitungsknoten N aufweisen.
In 3 zeigen die rechteckigen Kästchen, die sich unter jedem Knoten nach unten hin erstrecken, den Zeitabschnitt an, in dem dieser Knoten an der Transaktion beteiligt ist oder diese verarbeitet. Wie dies dargestellt ist, ist der HTTP-Server 305 von dem Zeitpunkt an beteiligt, zu dem die Client-Anforderung 315 empfangen wird, bis zu dem Zeitpunkt, zu dem die Client-Antwort 375 gesendet wird. Der Stream-Server 310, der mit den Stream-Verarbeitungsknoten 1, 2, ..., N interagiert, ist nicht so lange Zeit beteiligt, wie der HTTP-Server 305. Keiner der Stream-Verarbeitungsknoten 1, 2, ..., N ist so lange Zeit wie der Stream-Server 310 beteiligt.
4 ist ein Ablaufplan, der ein Verfahren 400 zum Antworten auf Anforderungen unter Verwendung von Stream-Verarbeitung gemäß einer in dieser Patentschrift offenbarten Ausführungsform veranschaulicht. Das Verfahren 400 kann von einem System gemäß Beschreibung in Bezug auf die 1 bis 3 implementiert werden. Genauer gesagt veranschaulicht das Verfahren 400 ein Verfahren zum Verarbeiten, das von dem in Bezug auf 3 beschriebenen HTTP-Server implementiert werden kann.
Das Verfahren 400 kann in Schritt 405 beginnen, in dem der HTTP-Server eine Client-Anforderung von einem Client empfangen kann. In Schritt 410 kann der HTTP-Server ermitteln, ob eine Anzahl an aktuell verwendeten Verarbeitungs-Threads eine Schwellenwertanzahl von Verarbeitungs-Threads übersteigt. Übersteigt die Anzahl an aktuell verwendeten Verarbeitungs-Threads die Schwellenwertanzahl an Verarbeitungs-Threads, kann das Verfahren 400 in Schritt 415 übergehen. In Schritt 415 kann der HTTP-Server die eingehende Client-Anforderung ablehnen oder einfach nicht beantworten. Durch Begrenzen der Anzahl an verfügbaren Verarbeitungs-Threads kann der HTTP-Server ein Überlaufen (flooding) des Stream-Verarbeitungssystems vermeiden. Nach Schritt 415 kann das Verfahren 400 eine Schleife zurück zu Schritt 405 nehmen, um die Client-Anforderung weiter zu verarbeiten. Übersteigt die Anzahl an aktuell verwendeten Verarbeitungs-Threads nicht die Schwellenwertanzahl an Verarbeitungs-Threads, kann das Verfahren in Schritt 420 übergehen.
In Schritt 420 kann der HTTP-Server in Reaktion auf die Client-Anforderung einen Verarbeitungs-Thread zum Bearbeiten der Client-Anforderung zuweisen. In einem Aspekt kann der HTTP-Server einen neuen Verarbeitungs-Thread erstellen und den neu erstellten Verarbeitungs-Thread zum Bearbeiten der Client-Anforderung bereitstellen. In einem weiteren Aspekt kann der HTTP-Server einen verfügbaren Verarbeitungs-Thread zum Bearbeiten der Client-Anforderung zuweisen.
In Schritt 425 kann der HTTP-Server in Reaktion auf die Client-Anforderung eine Rückverbindung zu dem Client einrichten. Der HTTP-Server kann die Rückverbindung in dem zugewiesenen Verarbeitungs-Thread erstellen. Wie dies beschrieben wurde, kann der Verarbeitungs-Thread durch die Thread-Kennung spezifiziert werden. In Schritt 430 kann der HTTP-Server eine Server-Anforderung an den Stream-Server senden. So kann der HTTP-Server beispielsweise ein Handle-Verfahren implementieren, das an dem zugewiesenen Verarbeitungs-Thread ausgeführt wird. Die Server-Anforderung kann beispielsweise die Client-Anforderung oder einen Abschnitt davon sowie die Thread-Kennung aufweisen.
In Schritt 435 kann der HTTP-Server das Warten auf ein Ergebnis von dem Stream-Server beginnen. In einer Ausführungsform kann der HTTP-Server den der Client-Anforderung zugewiesenen Verarbeitungs-Thread in einen Leerlauf setzen. Wie dies in Bezug auf 3 beschrieben wurde, kann der HTTP-Server beispielsweise auf ein Stream-Verarbeitungsergebnis, z. B. eine Rückkehr des Handle-Verfahrens von dem Stream-Server warten, bevor dem Client geantwortet wird. Dementsprechend kann der HTTP-Server in einen Wartezustand eintreten, wenigstens in Bezug auf die Client-Anforderung, wobei der der Client-Anforderung zugewiesene Verarbeitungs-Thread so lange in einem Leerlaufzustand gehalten wird, bis eine Antwort von dem Stream-Server empfangen wird. Der HTTP-Server kann jedoch das Bedienen anderer empfangener Client-Anforderungen fortsetzen, während er auf die Antwort von dem Stream-Server wartet.
In Schritt 440 kann der HTTP-Server in Reaktion auf die Mitteilung zum Schreiben einer Antwort von dem Stream-Server, die die Thread-Kennung spezifiziert, den durch die Thread-Kennung spezifizierten Verarbeitungs-Thread, z. B. den Verarbeitungs-Thread, der in einen Leerlauf gesetzt wurde, in einen aktiven Zustand zurücksetzen. Wie des beschrieben wurde, kann die Mitteilung zum Schreiben einer Antwort das Antwortobjekt aufweisen, das auch das Stream-Verarbeitungsergebnis von den Stream-Verarbeitungsknoten und die Thread-Kennung aufweisen kann. Der HTTP-Server kann den durch die Thread-Kennung spezifizierten und in den Leerlauf versetzten Thread zurück in einen aktiven Zustand versetzen. Hierbei sollte beachtet werden, dass, da der HTTP-Server eine Vielzahl von Client-Anforderungen gleichzeitig bedienen und eine Vielzahl von ausstehenden Server-Anforderungen aufweisen kann, der HTTP-Server mehr als einen sich im Leerlauf befindlichen Verarbeitungs-Thread zur gleichen Zeit aufweisen kann. Dementsprechend kann der HTTP-Server einen der Vielzahl der sich im Leerlauf befindlichen Verarbeitungs-Threads gemäß Spezifizierung durch die Thread-Kennung in der Mitteilung zum Schreiben einer Antwort auswählen. Der HTTP-Server kann den ausgewählten sich im Leerlauf befindlichen Verarbeitungs-Thread in Reaktion auf das Empfangen der Stream-Verarbeitungsergebnisse für diesen Verarbeitungs-Thread zurück in einen aktiven Zustand versetzen. In Schritt 445 kann der HTTP-Server die Client-Antwort, die die Stream-Verarbeitungsergebnisse spezifiziert, in ihrer von den Stream-Verarbeitungsknoten ermittelten Form über die in dem aktivierten Verarbeitungs-Thread spezifizierten Rückverbindung an den Client senden.
Hierbei sollte beachtet werden, dass beim Auftreten eines Fehlers, z. B. wenn eine Mitteilung zum Schreiben einer Antwort nicht innerhalb einer vorgegebenen Mindestzeitdauer von dem Stream-Server empfangen wird, der HTTP-Server so konfiguriert sein kann, dass er den zum Bearbeiten der Client-Anforderung zugewiesenen Verarbeitungs-Thread freigibt, so dass der Verarbeitungs-Thread für andere Verarbeitungsaufgaben verfügbar ist. So kann der HTTP-Server beispielsweise nach Ablauf der Mindestzeitdauer von der Annahme ausgehen, dass ein Fehler in dem Stream-Server und/oder einem oder mehreren Stream-Verarbeitungsknoten aufgetreten ist, so dass eine Mitteilung zum Schreiben einer Antwort von dem Stream-Server nicht ankommen wird.
5 ist ein Ablaufplan, der ein Verfahren 500 zum Antworten auf Anforderungen unter Verwendung von Stream-Verarbeitung gemäß einer weiteren in dieser Patentschrift offenbarten Ausführungsform veranschaulicht. Das Verfahren 500 kann von einem System wie dem in Bezug auf die 1 bis 3 beschriebenen implementiert werden. Genauer gesagt veranschaulicht das Verfahren 500 ein Verfahren zum Verarbeiten, das von dem in Bezug auf 3 beschriebenen Stream-Server implementiert werden kann. Das Verfahren 500 kann beispielsweise gleichzeitig mit Verfahren 400 durchgeführt werden. Genauer gesagt kann das Verfahren 500 beispielsweise durchgeführt werden, während sich der Verarbeitungs-Thread im Leerlauf befindet oder während das Handle-Verfahren in dem HTTP-Server blockiert ist.
Das Verfahren 500 kann in Schritt 505 beginnen, in dem der Stream-Server die Server-Anforderung von dem HTTP-Server empfängt. Der Stream-Server kann beispielsweise so konfiguriert sein, dass er an einem Anschluss auf die Server-Anforderungen von dem HTTP-Server hört. In Schritt 510 kann der Stream-Server ermitteln, ob eine Anzahl von Einträgen in dem Kontextwörterbuch kleiner ist als die Schwellenwertanzahl von Einträgen. Ist die Anzahl von Einträgen in dem Kontextwörterbuch kleiner als die Schwellenwertanzahl von Einträgen, kann das Verfahren 500 in Schritt 515 übergehen. Ist die Anzahl an Einträgen in dem Kontextwörterbuch nicht kleiner als die Schwellenwertanzahl von Einträgen, kann das Verfahren 500 in Schritt 520 übergehen.
In Schritt 515 kann der Stream-Server die von dem HTTP-Server empfangene Server-Anforderung ablehnen. Das Begrenzen der Anzahl von Einträgen in dem Kontextwörterbuch kann dabei helfen, ein Überladen des Stream-Verarbeitungssystems mit Client-Anforderungen zu verhindern. Nach Schritt 515 kann das Verfahren eine Schleife zurück zu Schritt 505 nehmen, um die Verarbeitung weiterer Server-Anforderungen von dem HTTP-Server fortzusetzen.
In Schritt 520 kann der Stream-Server eine Anforderungskennung in Reaktion auf die Server-Anforderung anhand der hierin spezifizierten Kontextinformationen erzeugen. In Schritt 525 kann der Stream-Server die Anforderungskennung sowie die Client-Kontextinformationen speichern. Wie dies beschrieben wurde, kann der Stream-Server beispielsweise die Client-Kontextinformationen in dem Kontextwörterbuch als einen Eintrag speichern, der unter Verwendung der Anforderungskennung verschlüsselt oder indexiert werden kann.
In Schritt 530, kann der Stream-Server eine Anforderung zur Stream-Verarbeitung erzeugen. Der Stream-Server kann die Anforderungskennung in der Anforderung zur Stream-Verarbeitung aufweisen. Die Anforderungskennung kann in dem ausgegebenen Datenstrom, der von jedem Stream-Verarbeitungsknoten erzeugt wird, enthalten sein. Durch das Weitergeben von identifizierenden Informationen können die Stream-Verarbeitungsergebnisse mit der Client-Anforderung korreliert werden und des Weiteren das Stream-Verarbeitungssystem Affinität mit dem Client aufrechterhalten.
In Schritt 535 kann der Stream-Server die Anforderung zur Stream-Verarbeitung an einen ersten Stream-Verarbeitungsknoten senden. In Schritt 540 kann der Stream-Server eine Mitteilung zum Erstellen einer Antwort als Teil des ausgegebenen Datenstroms von einem letzten oder endgültigen Stream-Verarbeitungsknoten, der in der Stream-Verarbeitung beteiligt ist, die in Reaktion auf die Client-Anforderung durchgeführt wird, empfangen. Wie dies beschrieben wurde, kann die Mitteilung zum Erstellen einer Antwort die Anforderungskennung und das Stream-Verarbeitungsergebnis von den Stream-Verarbeitungsknoten spezifizieren.
In Schritt 545 kann der Stream-Server die Client-Kontextinformationen abrufen. So kann der Stream-Server beispielsweise die Client-Kontextinformationen aus dem Kontextwörterbuch unter Verwendung der Anforderungskennung anhand der Mitteilung zum Erstellen einer Antwort abrufen. In Schritt 550 kann der Stream-Server eine Mitteilung zum Schreiben einer Antwort zurück an den HTTP-Server senden. Wie dies beschrieben wurde, kann der Stream-Server die Client-Kontextinformationen, die aus dem Kontextwörterbuch abgerufen wurden, verwenden, um zu ermitteln, wo die Mitteilung zum Schreiben einer Antwort hinzuleiten ist. Die Client-Kontextinformationen können die Thread-Kennung aufweisen, die der Stream-Server in der Mitteilung zum Schreiben einer Antwort aufweisen kann, die an den HTTP-Server gesendet wurde. Dementsprechend kann der HTTP-Server eine Client-Antwort, die das Stream-Verarbeitungsergebnis von dem Stream-Verarbeitungssystem gemäß Spezifizierung in dem Antwortobjekt aufweist, zurück an den Client senden.
In Schritt 555 kann der Stream-Server den Eintrag in dem Kontextwörterbuch entsprechend der Anforderungskennung, die verarbeitet wurde, löschen und dadurch die Anzahl an Einträgen in dem Kontextwörterbuch verringern. Hierbei sollte beachtet werden, dass, obgleich dies in 5 nicht dargestellt ist, auch weitere Fehlerbearbeitungsvorgehensweisen in dem Stream-Server durchgeführt werden können. So können beispielsweise in einem Aspekt Einträge in dem Kontextwörterbuch nach einer vorgegebenen oder einer Mindestzeitdauer gelöscht oder gestrichen werden. Nach Ablauf dieser Mindestzeitdauer kann der Stream-Server davon ausgehen, dass ein Fehler in einem oder mehreren der Stream-Verarbeitungsknoten aufgetreten ist und dass eine Mitteilung zum Erstellen einer Antwort nicht weitergeleitet werden wird.
Die hierin verwendete Terminologie dient lediglich dem Zwecke der Beschreibung bestimmter Ausführungsformen und beabsichtigt keine Beschränkung der Erfindung. In ihrer hierin verwendeten Form umfassen die Singularformen „ein”, „eine”, und „der(/die/das)” ebenso die Pluralformen, es sei denn, der Kontext gibt eindeutig etwas Anderes vor. Des Weiteren ist offensichtlich, dass die Begriffe „weist auf” und/oder „aufweisend”, wenn sie in dieser Patentschrift verwendet werden, das Vorhandensein von dargestellten Merkmalen, Ganzzahlen, Schritten, Operationen, Elementen und/oder Komponenten angeben, jedoch nicht das Vorhandensein oder die Hinzufügung einer oder mehrerer weiterer Merkmale, Ganzzahlen, Schritte, Operationen, Elemente, Komponenten und/oder Gruppen davon ausschließen.
Die entsprechenden Strukturen, Materialien, Schritte und Entsprechungen aller Mittel oder Schritte plus Funktionselemente in den folgenden Ansprüchen beabsichtigen die Einbeziehung jeglicher Struktur, jeglichen Materials oder Schrittes zum Ausführen der Funktion in Kombination mit anderen beanspruchten Elementen in ihrer im Speziellen beanspruchten Form. Die Beschreibung der vorliegenden Erfindung wurde zum Zwecke der Veranschaulichung und Beschreibung dargestellt, sie erhebt jedoch weder Anspruch auf Vollständigkeit, noch stellt sie eine Beschränkung auf die Erfindung in ihrer offenbarten Form dar. Fachleuten sind viele Modifizierungen und Varianten offensichtlich, ohne vom Schutzumfang und Geist der Erfindung abzuweichen. Die Ausführungsform wurde ausgewählt und beschrieben, um am besten die Prinzipien der Erfindung und die praktische Anwendung zu erläutern und um andere Fachleute dazu zu befähigen, die Erfindung für verschiedene Ausführungsformen mit verschiedenen Modifizierungen zu verstehen, die für die bestimmte angestrebte Verwendung geeignet sind.

Claims

Verfahren zum Antworten auf Anforderungen unter Verwendung von Stream-Verarbeitung, wobei das Verfahren aufweist: Empfangen einer Server-Anforderung von einem Server, wobei der Server so konfiguriert ist, dass er die Server-Anforderung in Reaktion auf eine Client-Anforderung erzeugt; Erzeugen einer Anforderungskennung, die zu der Server-Anforderung gehört; in Reaktion auf die Server-Anforderung, Senden einer aus der Server-Anforderung hergeleiteten Anforderung zur Stream-Verarbeitung an einen ersten Stream-Verarbeitungsknoten, wobei die Anforderung zur Stream-Verarbeitung die Anforderungskennung aufweist; in Reaktion auf Empfangen einer Mitteilung zum Erstellen einer Antwort, die ein Stream-Verarbeitungsergebnis und die Anforderungskennung aufweist, von einem zweiten Stream-Verarbeitungsknoten, Korrelieren des Stream-Verarbeitungsergebnisses mit der Server-Anforderung unter Verwendung eines Prozessors; und Senden einer Mitteilung zum Schreiben einer Antwort, die das Stream-Verarbeitungsergebnis aufweist, an den Server.
Verfahren nach Anspruch 1, des Weiteren aufweisend: in Reaktion auf Empfangen der Mitteilung zum Schreiben einer Antwort, Senden einer Client-Antwort, die das Stream-Verarbeitungsergebnis aufweist, an den Client.
Verfahren nach Anspruch 1, wobei das Verfahren des Weiteren aufweist: Verbreiten der Anforderung zur Stream-Verarbeitung zwischen dem ersten und dem zweiten Stream-Verarbeitungsknoten, wobei jeder Stream-Verarbeitungsknoten, der die Anforderung zur Stream-Verarbeitung bearbeitet, eine Teilantwort beisteuert.
Verfahren nach Anspruch 1, wobei die Server-Anforderung Client-Kontextinformationen aufweist, wobei das Verfahren des Weiteren aufweist: Korrelieren der Anforderung zur Stream-Verarbeitung mit der Server-Anforderung durch Erzeugen der Anforderungskennung anhand der Client-Kontextinformationen; und Speichern der Anforderungskennung, die zu den Client-Kontextinformationen gehört.
Verfahren nach Anspruch 4, wobei die Client-Kontextinformationen eine Thread-Kennung aufweisen, die einen Verarbeitungs-Thread in dem Server spezifiziert, der die Client-Anforderung bearbeitet.
Verfahren nach Anspruch 5, des Weiteren aufweisend: in Reaktion auf Empfangen der Mitteilung zum Erstellen einer Antwort von dem zweiten Stream-Verarbeitungsknoten, Korrelieren des Stream-Verarbeitungsergebnisses mit der Server-Anforderung entsprechend der Anforderungskennung, die in der Mitteilung zum Erstellen einer Antwort enthalten ist, und der gespeicherten Client-Kontextinformationen; und Bereitstellen des Stream-Verarbeitungsergebnisses und der Thread-Kennung an den Server in der Mitteilung zum Schreiben einer Antwort.
Verfahren nach Anspruch 1, des Weiteren aufweisend: Auswählen des Servers als einen mittels Hypertext Transfer Protocol (HTTP) aktivierter Server.
Verfahren nach Anspruch 1, des Weiteren aufweisend: in Reaktion auf die Client-Anforderung, Zuweisen eines Verarbeitungs-Threads zum Bearbeiten der Client-Anforderung; Einrichten einer Rückverbindung mit einem Client, der die Client-Anforderung gesendet hat, wobei die Rückverbindung zu dem Verarbeitungs-Thread gehört; und Senden der Server-Anforderung, die wenigstens einen Abschnitt der Client-Anforderung und eine Thread-Kennung aufweist, die den Verarbeitungs-Thread spezifiziert.
Verfahren nach Anspruch 8, des Weiteren aufweisend: in Leerlauf setzen des Verarbeitungs-Threads so lange bis die Mitteilung zum Schreiben einer Antwort empfangen wird.
Verfahren nach Anspruch 9, des Weiteren aufweisend: in Reaktion auf Empfangen der Mitteilung zum Schreiben einer Antwort, wobei die Mitteilung zum Schreiben einer Antwort die Thread-Kennung aufweist, Korrelieren des Stream-Verarbeitungsergebnisses mit der Client-Anforderung entsprechend der Thread-Kennung; und Aktivieren des von der Thread-Kennung spezifizierten Verarbeitungs-Threads, um auf die Client-Anforderung zu antworten.
Verfahren zum Antworten auf Anforderungen unter Verwendung von Stream-Verarbeitung, wobei das Verfahren aufweist: in Reaktion auf eine Client-Anforderung, Zuweisen eines Verarbeitungs-Threads zum Bearbeiten der Client-Anforderung; Einrichten einer Rückverbindung in dem Verarbeitungs-Thread; Senden einer von der Client-Anforderung hergeleiteten Server-Anforderung an einen Stream-Server, der so konfiguriert ist, dass er mit einer Vielzahl von Stream-Verarbeitungsknoten interagiert, wobei die Server-Anforderung eine Thread-Kennung aufweist, die den Verarbeitungs-Thread spezifiziert; Halten des Verarbeitungs-Threads zum Bearbeiten der Client-Anforderung in einem Leerlaufzustand vor der Mitteilung zum Schreiben einer Antwort von dem Stream-Server; in Reaktion auf Empfangen der Mitteilung zum Schreiben einer Antwort, die das Stream-Verarbeitungsergebnis und die Thread-Kennung aufweist, von dem Stream-Server, Zurücksetzen des von der Thread-Kennung spezifizierten Verarbeitungs-Threads in einen aktiven Zustand unter Verwendung eines Prozessors; und Senden einer Client-Antwort, die das Stream-Verarbeitungsergebnis aufweist, über die Rückverbindung.
Verfahren nach Anspruch 11, des Weiteren aufweisend: Einsetzen von wenigstens einem Abschnitt der Client-Anforderung in die Server-Anforderung.
Verfahren nach Anspruch 12, des Weiteren aufweisend: Auswählen des Verarbeitungs-Threads, der in einen aktiven Zustand zurückgesetzt werden soll, aus einer Vielzahl von sich im Leerlauf befindlichen Verarbeitungs-Threads entsprechend der Thread-Kennung.
Verfahren nach Anspruch 12, wobei der Stream-Server eine Anforderung zur Stream-Verarbeitung initiiert, die zwischen einer Vielzahl von Stream-Verarbeitungsknoten verbreitet wird, und wobei jeder Stream-Verarbeitungsknoten identifizierende Informationen für die Client-Anforderung empfängt.
Verfahren nach Anspruch 14, wobei jeder Stream-Verarbeitungsknoten asynchron arbeitet und eine Teilantwort zum Erzeugen des Stream-Verarbeitungsergebnisses beisteuert, das an den Stream-Server zurückgegeben wird.
System zum Antworten auf Anforderungen unter Verwendung von Stream-Verarbeitung, wobei das System aufweist: ein computerlesbares Speichermedium mit einem darin ausgebildeten computerlesbaren Programmcode; und einen Prozessor, der mit dem computerlesbaren Speichermedium verbunden ist, wobei in Reaktion auf das Ausführen des computerlesbaren Programmcodes der Prozessor so konfiguriert ist, dass er ausführbare Operationen durchführt, aufweisend: Empfangen einer Server-Anforderung von einem Server, wobei der Server so konfiguriert ist, dass er die Server-Anforderung in Reaktion auf eine Client-Anforderung erzeugt; Erzeugen einer Anforderungskennung, die zu der Server-Anforderung gehört; in Reaktion auf die Server-Anforderung, Senden einer von der Server-Anforderung hergeleiteten Anforderung zur Stream-Verarbeitung an einen ersten Stream-Verarbeitungsknoten, wobei die Anforderung zur Stream-Verarbeitung die Anforderungskennung aufweist; in Reaktion auf Empfangen einer Mitteilung zum Erstellen einer Antwort, die ein Stream-Verarbeitungsergebnis und die Anforderungskennung aufweist, von einem zweiten Stream-Verarbeitungsknoten, Korrelieren des Stream-Verarbeitungsergebnisses mit der Server-Anforderung; und Senden einer Mitteilung zum Schreiben einer Antwort, die das Stream-Verarbeitungsergebnis aufweist, an den Server.
System nach Anspruch 16, wobei der Prozessor des Weiteren so konfiguriert ist, dass er eine ausführbare Operation durchführt, aufweisend: in Reaktion auf Empfangen der Mitteilung zum Schreiben einer Antwort, Senden einer Client-Antwort, die das Stream-Verarbeitungsergebnis aufweist, an den Client.
System nach Anspruch 17, wobei der Prozessor des Weiteren so konfiguriert ist, dass er eine ausführbare Operation durchführt, aufweisend: Verbreiten der Anforderung zur Stream-Verarbeitung zwischen dem ersten und dem zweiten Stream-Verarbeitungsknoten, wobei jeder Stream-Verarbeitungsknoten, der die Anforderung zur Stream-Verarbeitung bearbeitet, eine Teilantwort beisteuert.
System nach Anspruch 17, wobei die Server-Anforderung Client-Kontextinformationen aufweist, wobei der Prozessor des Weiteren so konfiguriert ist, dass er eine ausführbare Operation durchführt, aufweisend: Korrelieren der Anforderung zur Stream-Verarbeitung mit der Server-Anforderung durch Erzeugen der Anforderungskennung anhand der Client-Kontextinformationen; und Speichern der Anforderungskennung, die zu den Client-Kontextinformationen gehört.
System zum Antworten auf Anforderungen unter Verwendung von Stream-Verarbeitung, wobei das System aufweist: ein computerlesbares Speichermedium mit einem darin ausgebildeten computerlesbaren Programmcode; und einen Prozessor, der mit dem computerlesbaren Speichermedium verbunden ist, wobei, in Reaktion auf das Ausführen des computerlesbaren Programmcodes, der Prozessor so konfiguriert ist, dass er ausführbare Operationen durchführt, aufweisend: in Reaktion auf eine Client-Anforderung, Zuweisen eines Verarbeitungs-Threads zum Bearbeiten der Client-Anforderung; Einrichten einer Rückverbindung in dem Verarbeitungs-Thread; Senden einer von der Client-Anforderung hergeleiteten Server-Anforderung an einen Stream-Server, der so konfiguriert ist, dass er mit einer Vielzahl von Stream-Verarbeitungsknoten interagiert, wobei die Server-Anforderung eine Thread-Kennung aufweist, die den Verarbeitungs-Thread spezifiziert; Halten des Verarbeitungs-Threads zum Bearbeiten der Client-Anforderung in einem Leerlaufzustand vor einer Mitteilung zum Schreiben einer Antwort von dem Stream-Server; in Reaktion auf das Empfangen der Mitteilung zum Schreiben einer Antwort, die das Stream-Verarbeitungsergebnis und die Thread-Kennung aufweist, von dem Stream-Server, Zurücksetzen des durch die Thread-Kennung spezifizierten Verarbeitungs-Threads in einen aktiven Zustand; und Senden einer Client-Antwort, die das Stream-Verarbeitungsergebnis aufweist, über die Rückverbindung an den Client.
System nach Anspruch 20, wobei der Prozessor des Weiteren so konfiguriert ist, dass er eine ausführbare Operation durchführt, aufweisend: Einsetzen wenigstens eines Abschnittes der Client-Anforderung in die Server-Anforderung.
System nach Anspruch 21, wobei der Prozessor des Weiteren so konfiguriert ist, dass er eine ausführbare Operation durchführt, aufweisend: Auswählen des Verarbeitungs-Threads, der in einen aktiven Zustand zurückgesetzt werden soll, aus einer Vielzahl von sich im Leerlauf befindlichen Verarbeitungs-Threads entsprechend der Thread-Kennung.
Computerprogrammprodukt zum Antworten auf Anforderungen unter Verwendung von Stream-Verarbeitung, wobei das Computerprogrammprodukt aufweist: ein computerlesbares Speichermedium mit einem darauf ausgebildeten computerlesbaren Programmcode, wobei der computerlesbare Programmcode aufweist: computerlesbaren Programmcode, der so konfiguriert ist, dass er eine Server-Anforderung von einem Server empfängt, wobei der Server so konfiguriert ist, dass er die Server-Anforderung in Reaktion auf eine Client-Anforderung erzeugt; computerlesbaren Programmcode, der so konfiguriert ist, dass er eine Anforderungskennung erzeugt, die zu der Server-Anforderung gehört; computerlesbaren Programmcode, der so konfiguriert ist, dass er in Reaktion auf die Server-Anforderung eine von der Server-Anforderung hergeleitete Anforderung zur Stream-Verarbeitung an einen ersten Stream-Verarbeitungsknoten sendet und wobei die Anforderung zur Stream-Verarbeitung die Anforderungskennung aufweist; computerlesbaren Programmcode, der so konfiguriert ist, dass er in Reaktion auf Empfangen einer Mitteilung zum Erstellen einer Antwort, die ein Stream-Verarbeitungsergebnis und die Anforderungskennung aufweist, von einem zweiten Stream-Verarbeitungsknoten, das Stream-Verarbeitungsergebnis mit der Server-Anforderung korreliert; und computerlesbaren Programmcode, der so konfiguriert ist, dass er eine Mitteilung zum Schreiben einer Antwort, die das Stream-Verarbeitungsergebnis aufweist, an den Server sendet.
Computerprogrammprodukt nach Anspruch 23, wobei der computerlesbare Programmcode des Weiteren aufweist: computerlesbaren Programmcode, der so konfiguriert ist, dass er die Anforderung zur Stream-Verarbeitung zwischen dem ersten und dem zweiten Stream-Verarbeitungsknoten verbreitet, wobei jeder Stream-Verarbeitungsknoten, der die Anforderung zur Stream-Verarbeitung bearbeitet, eine Teilantwort beisteuert.
Computerprogrammprodukt nach Anspruch 23, wobei die Server-Anforderung Client-Kontextinformationen aufweist, wobei der computerlesbare Programmcode des Weiteren aufweist: computerlesbaren Programmcode, der so konfiguriert ist, dass er die Anforderung zur Stream-Verarbeitung mit der Server-Anforderung korreliert, durch Erzeugen der Anforderungskennung anhand der Client-Kontextinformationen; und computerlesbaren Programmcode, der so konfiguriert ist, dass er die Anforderungskennung speichert, die zu den Client-Kontextinformationen gehört.