DE102016103733B4

DE102016103733B4 - Kanaleigentum in einem Veröffentlichungs-/Abonnier-System

Info

Publication number: DE102016103733B4
Application number: DE102016103733.8A
Authority: DE
Inventors: Kanak B. Agarwal; Patrick J. Bohrer; Ahmed Gheith; Michael Kistler; Ramakrishnan Rajamony
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2015-03-05
Filing date: 2016-03-02
Publication date: 2021-08-19
Anticipated expiration: 2036-03-03
Also published as: US20160261395A1; CN105939335A; US10063623B2; US20180262555A1; CN105939335B; DE102016103733A1; US9800648B2; US20170257421A1; US10158697B2

Abstract

Verfahren zum Verwalten von Kanaleigentum in einer Veröffentlichungs-/ Abonnier-Datenverarbeitungsumgebung, wobei das Verfahren aufweist:Ermitteln auf einem ersten Server (314) mithilfe eines Prozessors (206) und eines Speichers (208), dass sich eine Abonnementanforderung (320) von einem Client (306) auf einen Kanal bezieht (604), wobei der Kanal eine Kanalkennung aufweist;Bewirken an einer Vermittlungskomponente (324) in einer Messaging-Middleware, dass eine Sitzungswarteschlange (426), die dem Client (306) zugehörig ist, an den Kanal gebunden wird;Konfigurieren, dass eine obligatorische Übermittlungsnachricht mithilfe (320) einer Veröffentlichungskomponentenkennung durch die Vermittlungskomponente (324) weitergeleitet wird, wobei die Veröffentlichungskomponentenkennung mit der Kanalkennung in Beziehung steht;Kommunizieren der obligatorischen Übermittlungsnachricht (320) von dem ersten Server zu der Vermittlungskomponente (324) so, dass eine Absicht des ersten Servers (314) angegeben wird, zu einer Veröffentlichungskomponente des Kanals zu werden, wobei die obligatorische Übermittlungsnachricht (320) bewirkt, dass das Kanaleigentum des Kanals auf eine einzige Veröffentlichungskomponente beschränkt wird,Empfangen einer Abbruchnachricht an dem ersten Server (314) von einem zweiten Server (314), wobei die Abbruchnachricht entsprechend einer Veröffentlichungskomponentenkennung weitergeleitet wird und eine Rangangabe aufweist, die dem zweiten Server entspricht, und wobei sowohl der erste Server als auch der zweite Server versuchen, zu Veröffentlichungskomponenten von Inhalt in dem Kanal zu werden;Ermitteln, ob der erste Server (314) die Veröffentlichungskomponente des Kanals bleibt, durch Vergleichen der Rangangabe, die dem zweiten Server (314) entspricht, aus der Abbruchnachricht mit einer Rangangabe, die dem ersten Server (314) entspricht; undin Reaktion darauf, dass der zweite Server (314) einen höheren Rang als der erste Server (314) hat, der nicht die Veröffentlichungskomponente des Kanals bleibt, Aufheben der Bindung einer Server-Instanzenwarteschlange, die dem ersten Server (314) zugehörig ist, an die Vermittlungskomponente (324, 524).

Description

TECHNISCHES GEBIET
Die vorliegende Erfindung bezieht sich allgemein auf ein Verfahren, System und Computerprogrammprodukt zum Verwalten von Datenanforderungen und -antworten. Im Besonderen bezieht sich die vorliegende Erfindung auf ein Verfahren, System und Computerprogrammprodukt für Kanaleigentum (channel ownership) in einem Veröffentlichungs-/Abonnier-System (publish-subscribe system).
HINTERGRUND
Die meisten Datenübertragungen zwischen zwei Datenverarbeitungssystemen gehen mit einer Anforderung von Daten und einer Antwort einher, die die angeforderten Daten enthält. Beispielsweise fordert ein Client-Datenverarbeitungssystem Daten durch Senden einer Anforderungsnachricht mithilfe eines Hypertext-Übertragungsprotokolls (HyperText Transfer Protocol, http oder HTTP) an ein Server-Datenverarbeitungssystem an. Der Server sendet mithilfe von HTTP eine Antwortnachricht an den Client, die die Daten enthält.
Ein Client kann fortlaufend Datenaktualisierungen anfordern. In einer Client-/Server-Umgebung, in der Anforderungen vom Typ einer aktiven Abfrage eingesetzt werden, abonniert ein Client zum Beispiel im Wesentlichen eine fortlaufende Zuführung von Datenaktualisierungen von einer Server-seitigen oder Back-End-Datenverarbeitungsumgebung. Bei einer aktiven Abfrage, die auch als dynamische Abfrage oder kontinuierliche Abfrage bezeichnet wird, handelt es sich um ein Verfahren, durch das ein Client fortlaufende Aktualisierungen über ein Ereignis oder einen Zustand von etwas anfordert.
Ein einfaches Beispiel für eine aktive Abfrage ist eine Anforderung eines aktuelten Aktienkurses eines Börsentickers von einem Browser, wobei ein Server in Reaktion auf eine solche Abfrage den Browser mit fortlaufenden Aktualisierungen des sich ändernden Aktienkurses dieses Tickers versorgt. Um fortlaufende Aktualisierungen in Reaktion auf eine Abfrage bereitzustellen, überwacht ein Server üblicherweise die Änderungen in einer Datenbank oder die Änderungen in dem Zustand eines Ereignisses. Der Server kann diese Änderungen überwachen, indem er die Datenbank abfragt oder das Ereignis regelmäßig auf Änderungen gegenüber vorherigen Daten in der Datenbank oder gegenüber dem vorherigen Zustand des Ereignisses hin beobachtet.
Das HTTP-Protokoll unterstützt lediglich ein Anforderungs-/Antwort-Modell, bei dem Clients die Anforderungen initiieren und die Server auf die Client-Anforderungen antworten. Bei dem Standard-HTTP-Modell kann ein Server Antworten nicht mit einer Push-Operation an einen Client zurückübertragen, ohne dass eine entsprechende Anforderung des Clients ansteht. Bei einem Veröffentlichungs-/Abonnier-System des Typs einer aktiven Abfrage übertragen Server den Inhalt mit einer Push-Operation direkt zurück an Clients. Dieser Operationstyp kann durch ein Protokoll wie zum Beispiel Websockets erzielt werden, das eine bidirektionale Datenübertragung zwischen Client und Server unterstützt.
Bei einem Client-/Server-Modell, in dem Clients eine solche dynamische Zuführung von Inhalt abonnieren, die durch die Server erzeugt wird, können zum Lastausgleich mehrere Server verwendet werden. Eine Form des Lastausgleichs zum Unterstützen einer horizontalen Skalierung besteht darin, unabhängige Server zu verwenden, wobei die Server keine Kenntnis darüber haben, was andere Server für denselben Client oder für andere Clients ausführen. In einer Server-seitigen Datenverarbeitungsumgebung, in der mehrere unabhängige Server ohne gemeinsam genutzte Zustandsdaten übereinander so zusammenarbeiten, dass sie zahlreiche Anforderungen von zahlreichen Clients bedienen, kann eine eingehende Anforderung von einem Client, das Empfangen solcher Datenaktualisierungen zu abonnieren oder abzubestellen, zum Verarbeiten an einen beliebigen Server weitergeleitet werden.
Es sind bereits folgenden Dokumente in diesem Kontext bekannt: Das Dokument US 7 139 792 B1 beschreibt ein Verfahren zum Einbinden aller Client-Aufrufe, die den gleichen Session-Identifikator ausweist, um sichere e-Commerce-Anwendungen zu ermöglichen. Außerdem ist aus dem Dokument US 6,226,684 B1ein Verfahren zum Routing von Nachrichten von einem Client an einen Server bekannt, wobei der Router umgangen wird. Dabei weist der Router eine Tabelle auf, die angibt, dass der Client-Kommunikation bereits früher den Router umgangen hat.
KURZDARSTELLUNG
Die veranschaulichenden Ausführungsformen stellen ein Verfahren, System und Computerprogrammprodukt für Kanaleigentum in einem Veröffentlichungs-/Abonnier-System bereit. Eine Ausführungsform beinhaltet ein Verfahren zum Verwalten von Kanaleigentum in einer Veröffentlichungs-/Abonnier-Datenverarbeitungsumgebung. Die Ausführungsform ermittelt auf einem ersten Server mithilfe eines Prozessors und eines Speichers, dass sich eine Abonnementanforderung von einem Client auf einen Kanal bezieht, wobei der Kanal eine Kanalkennung aufweist. Die Ausführungsform bewirkt an einer Vermittlungskomponente (exchange component) in einer Messaging-Middleware (Zwischenanwendung für Nachrichtenübermittlung), dass eine Sitzungswarteschlange, die dem Client zugehörig ist, an den Kanal gebunden wird. Die Ausführungsform führt eine Konfigurierung so durch, dass eine obligatorische Übermittlungsnachricht mithilfe einer Veröffentlichungskomponentenkennung durch die Vermittlungskomponente weitergeleitet wird, wobei die Veröffentlichungskomponentenkennung mit der Kanalkennung in Beziehung steht. Die Ausführungsform tauscht die obligatorische Übermittlungsnachricht von dem ersten Server zu der Vermittlungskomponente so aus, dass eine Absicht des ersten Servers angegeben wird, eine Veröffentlichungskomponente (publisher) des Kanals zu werden, wobei die obligatorische Übermittlungsnachricht bewirkt, dass das Kanaleigentum des Kanals auf eine einzige Veröffentlichungskomponente beschränkt wird.
Eine weitere Ausführungsform beinhaltet ein computerverwendbares Programmprodukt, das eine computerlesbare Speichereinheit aufweist, die computerverwendbaren Code zum Verwalten von Kanaleigentum in einer Veröffentlichungs-/Abonnier-Datenverarbeitungsumgebung beinhaltet.
Eine weitere Ausführungsform beinhaltet ein Datenverarbeitungssystem zum Verwalten von Kanaleigentum in einer Veröffentlichungs-/Abonnier-Datenverarbeitungsumgebung.
Figurenliste
Die neuartigen Merkmale, die als charakteristisch für die Erfindung erachtet werden, werden in den beigefügten Ansprüchen erläutert. Die Erfindung selbst wie auch eine bevorzugte Verwendungsweise, weitere Ziele und Vorteile davon sind jedoch durch Bezugnahme auf die folgende ausführliche Beschreibung der veranschaulichenden Ausführungsformen am besten zu verstehen, wenn sie zusammen mit den beigefügten Zeichnungen gelesen werden, in denen:

1 ein Blockschaubild eines Netzwerks von Datenverarbeitungssystemen darstellt, in dem veranschaulichende Ausführungsformen implementiert werden können;
2 ein Blockschaubild eines Datenverarbeitungssystems darstellt, in dem veranschaulichende Ausführungsformen implementiert werden können;
3 ein Blockschaubild einer beispielhaften Konfiguration zum fortlaufenden Veröffentlichen von Inhalt in einer Veröffentlichungs-/Abonnier-Client-/ Server-Umgebung gemäß einer veranschaulichenden Ausführungsform darstellt;
4 ein Blockschaubild einer Bedingung bei einem Kanaleigentum in einem Veröffentlichungs-/Abonnier-System gemäß einer veranschaulichenden Ausführungsform darstellt;
5 ein Blockschaubild einer Konfiguration zum Lösen eines Problems bei Kanaleigentum in einem Veröffentlichungs-/Abonnier-System gemäß einer veranschaulichenden Ausführungsform darstellt;
6 einen Ablaufplan eines beispielhaften Prozesses für Kanaleigentum in einem Veröffentlichungs-/Abonnier-System gemäß einer veranschaulichenden Ausführungsform darstellt;
7 einen Ablaufplan eines beispielhaften Prozesses zum gleichzeitigen oder nahezu gleichzeitigen Auflösen einer Konkurrenzsituation mit mehreren Veröffentlichungskomponenten gemäß einer veranschaulichenden Ausführungsform darstellt; und
8 einen Ablaufplan eines beispielhaften Prozesses zum Beseitigen einer doppelten Veröffentlichungskomponente gemäß einer veranschaulichenden Ausführungsform darstellt.

AUSFÜHRLICHE BESCHREIBUNG
Die veranschaulichenden Ausführungsformen erkennen, dass in einer Client-/Server-Umgebung, in der Clients Datenzuführungen abonnieren, letzten Endes möglicherweise mehrere Server doppelte Arbeit durchführen, wodurch Ressourcen verschwendet werden. In solchen Umgebungen ist es zum Beispiel wahrscheinlich, dass mehrere Server eine Verarbeitung für dieselben Daten oder Ereignisse so durchführen, dass dieselben Datenaktualisierungen oder -zuführungen in Reaktion auf ähnliche Anforderungen von verschiedenen Clients veröffentlicht werden.
Die veranschaulichenden Ausführungsformen erkennen des Weiteren, dass die doppelte Arbeit auf der Server-Seite auch auf der Client-Seite zu Verwirrung führt. In manchen Fällen ist es zum Beispiel auch möglich, dass derselbe Client eine Anforderung und eine erneute Anforderung für dieselbe Abfrage sendet und letzten Endes verschiedene Server die Anforderung und die erneute Anforderung verarbeiten. Auf diese Weise kann mehr als ein Server damit beginnen, doppelte Datenzuführungen zu veröffentlichen, was eine Operation auf der Client-Seite durcheinanderbringen oder unterbrechen kann.
Die veranschaulichenden Ausführungsformen, die dazu verwendet werden, die Erfindung zu beschreiben, gehen die oben beschriebenen Probleme und sonstige Probleme, die mit einem Verwalten von Datenanforderungen und -antworten in Beziehung stehen, allgemein an und lösen diese. Die veranschaulichenden Ausführungsformen stellen ein Verfahren, System und Computerprogrammprodukt für eine skalierbare Architektur mit automatischer Fehlerbehebung für Kanaleigentum in einem Veröffentlichungs-/Abonnier-System bereit.
Die hierin beschriebenen Ausführungsformen sind an sonstige Typen oder Anforderungen und Antworten mithilfe von HTTP oder sonstigen Protokollen anpassbar. Die hierin beschriebenen Ausführungsformen sind außerdem zur Verwendung nicht nur mit mobilen Einheiten, sondern auch mit einem sonstigen Datenverarbeitungssystem und sonstigen Datenverarbeitungsumgebungen anpassbar, in denen das Veröffentlichungs-/Abonnier-Modell für Client-/Server-Datenübertragungen verwendet werden kann.
Bei solchen Ausführungsformen wird ein Anforderersystem als Client beschrieben, und ein antwortendes System wird als Server beschrieben, ohne dass eine bestimmte Client-/Server-Konfiguration oder -Architektur impliziert wird. Bei einem Client handelt es sich einfach um einen Nutzer (consumer) von Daten und bei einem Server einfach um einen Bereitsteller (supplier) von Daten, und ein System, das bei einer Vermittlung ein Client ist, könnte bei einer weiteren Vermittlung sehr wohl der Server (oder das Back-End) sein und umgekehrt. Üblicherweise arbeiten Server in einer Back-End-Datenverarbeitungsumgebung, und es wird über ein Datennetzwerk von Anwendungen auf sie zugegriffen, die auf Client-Systemen ausgeführt werden. Die Back-End-Datenverarbeitungsumgebung - die hierin auch als Server-seitige Datenverarbeitungsumgebung bezeichnet wird - weist Anwendungen und Systeme zum Empfangen der Datenanforderungen, Datenablagen, aus denen Daten in Reaktion bereitgestellt werden, Anwendungen, deren Dienste in einigen Anforderungen angefordert werden, Sicherheitsanwendungen, Middleware-Anwendungen und Plattformen und viele sonstige Systeme und Anwendungen auf.
Eine Ausführungsform kann als Anwendung so in Software, Hardware oder Firmware implementiert werden, dass sie in der Back-End-Datenverarbeitungsumgebung arbeitet. Einige Operationen einiger Ausführungsformen, die hierin beschrieben werden, können auf einem Server implementiert werden, beispielsweise durch Modifizieren einer Server-Anwendung so, dass sie diese Operationen durchführt. Im Allgemeinen können die Operationen und Funktionen einer Ausführungsform innerhalb des Umfangs der veranschaulichenden Ausführungsformen eigenständig oder zusammen mit sonstigen Anwendungen implementiert werden, die in der Back-End-Datenverarbeitungsumgebung ausgeführt werden. Eine Anwendung, die eine Ausführungsform implementiert, kann zum Beispiel so konfiguriert werden, dass sie als Modifizierung eines Servers, als Modifizierung einer Messaging-Middleware, als eigenständige Anwendung, die durch einen Server verwendbar ist, als eigenständige Anwendung, die durch eine Messaging-Middleware verwendbar ist, oder als beliebige Kombination davon arbeitet.
Im Betrieb stellen üblicherweise mehrere Server in einer Lastverteilungskonfiguration denselben Diensttyp für zahlreiche Clients bereit. Gemäß einer Ausführungsform ist jeder Lastverteilungs-Server, der in einer solchen Veröffentlichungs-/Abonnier-Client-/Server-Architektur arbeitet, in der Lage, einen Kanal zu erstellen, Inhalt - einschließlich fortlaufender Aktualisierungen - in diesem Kanal zu veröffentlichen und Clients so zu binden, dass sie den Inhalt überwachen, der in dem Kanal veröffentlicht wird.
Der Server erstellt den Kanal auf Grundlage der Abfrage oder des Typs der Anforderung (im Folgenden als „Abfrage“ bezeichnet) von dem Client. Im Wesentlichen handelt es sich innerhalb des Umfangs der veranschaulichenden Ausführungsformen bei einem Kanal einfach um eine Weise, eine Entsprechung zwischen einer Abfrage und dem veröffentlichten Inhalt herzustellen. Beispielsweise werde angenommen, dass die Abfrage eine Kennung aufweist. Ein Server verwendet die Abfragekennung als Kanalkennung. Zu einem Veröffentlichen von Inhalt in dem Kanal gehört ein Kennzeichnen des Inhalts mit der Kennung in einer Weise, dass ein Client, der den Kanal überwacht, die Entsprechung zwischen der Abfrage und dem Inhalt herstellen kann.
Bei einer Ausführungsform gibt die Anforderungsnachricht die Abfragekennung an, und der Server verwendet die angegebene Kennung der angegebenen Abfrage als Kanalkennung. Bei einer weiteren Ausführungsform gibt die Anforderungsnachricht die Abfrage an, und der Server verwendet ein geeignetes Verfahren zum Ermitteln einer Kennung der angegebenen Abfrage, wie zum Beispiel ein Erzeugen eines Hash-Wertes der Abfrage oder ein Nachschlagen der Abfrage in einem Katalog. Anschließend verwendet der Server die ermittelte Abfragekennung als Kanalkennung.
Ein Server kann dann den anfordernden Client so binden, dass er Aktualisierungen überwacht, die in dem Kanal veröffentlicht werden. Ein Client, der an einen Kanal gebunden ist, empfängt den Inhalt, der in diesem Kanal veröffentlicht wird, ohne dass er eine Abfrage durch Polling durchführen oder eine Anforderung des Inhalts senden muss. Wie in dieser Offenbarung beschrieben wird, führt eine Messaging-Middleware eine Sitzungswarteschlange für einen Client. Das Binden des Clients an einen Kanal weist ein Konfigurieren eines Pfades in der Middleware so auf, dass Inhalt, der mit der Kanalkennung veröffentlicht wird, in der Sitzungswarteschlange des Clients platziert werden kann.
Ein Client initiiert eine Datenübertragungssitzung durch Senden einer Handshake-Nachricht an eine Back-End-Datenverarbeitungsumgebung. Die Back-End-Datenverarbeitungsumgebung implementiert eine oder mehrere Agent-Anwendungen, von denen eine eine Sitzungskennung für die Sitzung erstellt und auf die Handshake-Nachricht des Clients antwortet. Für die verbleibenden Datenübertragungen zwischen dem Client und dem Back-End wird erwartet, dass der Client die Sitzungskennung verwendet.
Mithilfe der Sitzungskennung sendet der Client eine Anforderung wie zum Beispiel eine Anforderung von Daten und fortlaufenden Aktualisierungen an die Back-End-Datenverarbeitungsumgebung. Ein Agent ermittelt aus dem Nachrichtenkopf die Abfrage in der Anforderung. Eine Anforderung kann zum Beispiel einen Datenbankdienst anfordern, wobei eine Datenbank in Reaktion Aktualisierungen an einigen sich ändernden Daten bereitzustellen hat. Als weiteres Beispiel kann eine weitere Anforderung einen Nachrichten- oder Aktienzuführungsdienst anfordern, wobei eine Server-Anwendung so Zugriff auf eine Datenquelle haben kann, dass sie die Daten und die Aktualisierungen bezieht und bereitstellt. Als weiteres Beispiel kann eine Anforderung einen Benachrichtigungsdienst anfordern, wobei eine Back-End-Anwendung Daten über ein Ereignis bereitzustellen hat, wenn Änderungen in dem Ereignis erkannt werden. Zahlreiche sonstige Diensttypen können in ähnlicher Weise Gegenstand der Abfrage in einer Anforderungsnachricht sein.
Bei einer Messaging-orientierten Middleware handelt es sich um eine beliebige geeignete Anwendung, die zwei oder mehr Anwendungen in die Lage versetzt, Daten über Nachrichtenwarteschlangen (message queues, MQ) miteinander auszutauschen. Eine Vielfalt von Messaging-orientierter Middleware, die hierin auch als Messaging-Middleware oder als MQ-Middleware bezeichnet wird, ist derzeit verfügbar und wird in Back-End-Datenverarbeitungsumgebungen verwendet. Bei MQ-Series und RabbitMQ handelt es sich um einige Beispiele für im Handel erhältliche Messaging-Middleware, die solche Datenübertragungen zwischen Anwendungen erleichtern (MQ-Series ist eine Marke von International Business Machines Corporation in den Vereinigten Staaten und sonstigen Ländern, RabbitMQ ist eine Open-Source-Software, die durch Pivotal Software, Inc., unter Mozilla Public License vertrieben wird).
Eine Messaging-Middleware ermöglicht, dass eine oder mehrere Anwendungen eine oder mehrere Nachrichten für eine oder mehrere sonstige Anwendungen in einer Nachrichtenwarteschlange veröffentlichen. Die sonstigen Anwendungen abonnieren die Warteschlange. Wenn eine Nachricht in der Warteschlange veröffentlicht wird, können sämtliche Abonnenten oder ein Teilsatz der Abonnenten der Warteschlange die veröffentlichte Nachricht empfangen. Der Teilsatz der Abonnenten, die eine Nachricht empfangen, wird durch eine Kombination der Richtlinien, die der Warteschlange zugeschrieben werden, und durch die Nachrichteninhalte selbst ermittelt.
Der Satz aus einer oder mehreren Agent-Anwendungen führt einen Satz von Dienstwarteschlangen. Eine Dienstwarteschlange des Satzes von Dienstwarteschlangen ist so konfiguriert, dass sie Veröffentlichungen von Anforderungen empfängt, die nur eine spezifische Abfrage aufweisen. Beispielsweise kann eine Dienstwarteschlange einem Überwachen von bestimmten Daten in einer Datenbank zugehörig sein, eine weitere Dienstwarteschlange kann einem Nachrichtenzuführungsdienst zugehörig sein, und eine weitere Dienstwarteschlange kann einem Überwachen eines Ereignisses zugehörig sein.
Abhängig von dem Dienst, der in einer Anforderungsnachrichtenabfrage angefordert wird, veröffentlicht ein Agent die Anforderung in der Dienstwarteschlange, die diesem Dienst zugehörig ist. Diejenigen Server oder Back-End-Anwendungen, die den angeforderten Dienst anbieten, abonnieren die Dienstwarteschlange für diesen Dienst. Eine der Abonnenten-Back-End-Anwendungen übernimmt die Anforderung aus der Dienstwarteschlange. Diese Abonnenten-Back-End-Anwendung verarbeitet die Anforderung und erzeugt eine Antwort mit dem angeforderten Inhalt.
Ein Agent ermittelt, ob in der Messaging-Middleware bereits eine Sitzungswarteschlange für den Anforderer-Client erstellt worden ist. Eine Sitzungswarteschlange ist durch einen Server dazu verwendbar, Antworten zu veröffentlichen, die an den Client zu übermitteln sind. Immer, wenn ein Server oder eine Back-End-Anwendung Daten an den Client senden muss, veröffentlicht der Server oder die Back-End-Anwendung diese Daten in der Sitzungswarteschlange für den Client. Der Client ist der letztendliche Abonnent der Sitzungswarteschlange, wobei ein Agent als Vermittler dient, der die Nachricht weiterleitet. Wenn Daten in der Sitzungswarteschlange veröffentlicht werden, empfängt der abonnierende Client die Daten über einen Agent.
Unter bestimmten Umständen kann ein Server eine Sitzungswarteschlange erstellen und die Antwort in der Warteschlange zur Übermittlung an einen Client veröffentlichen. Um zu vermeiden, dass mehrere Sitzungswarteschlangen für dieselbe Sitzung für denselben Client erstellt werden, überprüft ein Agent, ob bereits eine Sitzungswarteschlange für den Client und die Sitzung vorhanden ist, bevor der Agent eine Sitzungswarteschlange erstellt. Wenn bereits eine Sitzungswarteschlange vorhanden ist, stellt der Agent einfach eine Bindung an die vorhandene Sitzungswarteschlange her.
Auf diese Weise können mehrere Agents eine Bindung an dieselbe Sitzungswarteschlange herstellen. Wenn durch einen Server oder eine Back-End-Anwendung eine Antwort in die Sitzungswarteschlange eingestellt wird, kann ein beliebiger der Agents, die an die Warteschlange gebunden sind, die veröffentlichte Antwort an den abonnierenden Client senden.
Wenn ein abonnierender Client während eines Warteschlangen-Zeitlimitintervalls nicht auf eine Sitzungswarteschlange zugreift, löscht eine Ausführungsform die Warteschlange und die darin verbliebenen Nachrichten. Wenn eine Nachricht in eine Sitzungswarteschlange eingestellt wird und ein abonnierender Client die eingestellte Nachricht nicht abholt oder empfängt, löscht ein Nachrichtzeitlimit-Zeitgeber diese eingestellte Nachricht aus der Sitzungswarteschlange.
Innerhalb der Messaging-Middleware führt jeder Server auch eine Server-Instanzenwarteschlange. Die Server-Instanzenwarteschlangen werden für Datenübertragungen zwischen den Servern verwendet. Solche internen Datenübertragungen zwischen Servern führen keine Zustandsdaten übereinander.
In der oben beschriebenen Architektur handelt es sich bei einer Vermittlungskomponente um eine Funktion einer Messaging-Middleware. Eine Vermittlungskomponente weist eine Logik zum Weiterleiten von Nachrichten an Warteschlangen auf. Ein Server veröffentlicht eine Nachricht gegenüber der Vermittlungskomponente, damit die Nachricht in einer oder mehreren Warteschlangen veröffentlicht wird.
Ein Server veröffentlicht zum Beispiel einen Inhalt in einem Kanal, indem er den Inhalt mit den Kanaldaten gegenüber der Vermittlungskomponente veröffentlicht, und die Vermittlungskomponente leitet den Inhalt des Kanals an diejenigen Sitzungswarteschlangen weiter, die an die Vermittlungskomponente gebunden sind, damit Nachrichten für diesen Kanal genutzt werden. Als weiteres Beispiel kennzeichnet ein Server sich selbst als Veröffentlichungskomponente eines Kanals, indem er eine Veröffentlichungskomponentennachricht mit den Kanaldaten gegenüber der Vermittlungskomponente veröffentlicht, und die Vermittlungskomponente leitet die Veröffentlichungskomponentennachricht, die mit dem Kanal in Beziehung steht, an die Server-Instanzenwarteschlangen weiter, wie in dieser Offenbarung beschrieben. Als weiteres Beispiel versucht ein Server sich selbst zur alleinigen Veröffentlichungskomponente oder zu der führenden Veröffentlichungskomponente eines Kanals zu machen, indem er eine Abbruchnachricht mit den Kanaldaten gegenüber der Vermittlungskomponente veröffentlicht, und die Vermittlungskomponente leitet die Abbruchnachricht, die mit dem Kanal in Beziehung steht, an die Server-Instanzenwarteschlangen weiter, wie in dieser Offenbarung beschrieben.
Nachdem diese Architektur eingerichtet ist, empfängt eine Ausführungsform eine Abonnementanforderung von einem Client. Die Ausführungsform ermittelt, dass die Anforderung einen bestimmten Kanal betrifft, z.B. einen Kanal Z. Wenn mehrere Clients dieselbe Abfrage anfordern, könnten mehrere Clients auf diese Weise ein Abonnement des Kanals Z anfordern.
Ein Agent stellt die Anforderung entsprechend der Abfrage in der Anforderung in eine geeignete Dienstwarteschlange ein. Aus einem Satz von Servern, die diese Abfrage verarbeiten, holt eine Server-Instanz - z.B. Server 10 - die Anforderung aus der Dienstwarteschlange ab. Der Server 10 bindet die Sitzungswarteschlange des anfordernden Client an die Vermittlungskomponente für den Kanal Z. Mit anderen Worten, wenn der Server 10 einen Inhalt in dem Kanal Z gegenüber der Vermittlungskomponente veröffentlicht, leitet die Vermittlungskomponente den Inhalt des Kanals Z weiter und speichert ihn in der Sitzungswarteschlange des Clients. Wenn mehr als ein Client den Kanal Z abonniert hätten, würde die Vermittlungskomponente den Inhalt, der in dem Kanal Z veröffentlicht ist, in ähnlicher Weise an die Sitzungswarteschlangen jedes abonnierenden Clients weiterleiten und dort speichern.
Eine Ausführungsform funktioniert des Weiteren so, dass sichergestellt wird, dass es sich bei dem Server 10 um den alleinigen oder den führenden Server handelt, der in dem Kanal Z veröffentlicht, sodass das zuvor beschriebene Problem doppelter Versuche vermieden wird. Wenn mehr als ein Server in demselben Kanal zu veröffentlichen scheint, funktioniert eine weitere Ausführungsform so, dass sie einen führenden Server aus den mehreren veröffentlichenden Servern auswählt, sodass das Problem doppelter Versuche vermieden wird.
Ein Verfahren einer hierin beschriebenen Ausführungsform bedeutet, wenn es so implementiert wird, dass es auf einer Einheit oder in einem Datenverarbeitungssystem ausgeführt wird, eine erhebliche Weiterentwicklung der Funktionalität dieser Einheit oder dieses Datenverarbeitungssystems beim Verwalten von Datenanforderungen und - antworten. Um Client-/Server-Datenübertragungen zu verwalten, lässt der Stand der Technik zum Beispiel die Möglichkeit von doppelten und unwirtschaftlichen Versuchen auf der Server-Seite zu. Demgegenüber konfiguriert und betreibt eine Ausführungsform eine Veröffentlichungs-/Abonnier-Client-/Server-Architektur, bei der die Lastverteilungs-Server doppelte Versuche auf der Server-Seite vermeiden können und ein gleichzeitiges Veröffentlichen von doppeltem Inhalt gegenüber Clients vermeiden können, wobei sie im Verhältnis zueinander zustandslos bleiben. Eine solche Art einer Datenanforderungsverwaltung in Veröffentlichungs-/Abonnier-Umgebungen ist in gegenwärtig erhältlichen Einheiten oder Datenverarbeitungssystemen nicht verfügbar. Folglich ermöglicht eine erhebliche Weiterentwicklung solcher Einheiten oder Datenverarbeitungssysteme durch Ausführen eines Verfahrens einer Ausführungsform eine skalierbare, zustandslose Back-End-Umgebung, die eine unwirtschaftliche, doppelte Inanspruchnahme von Server-Ressourcen für ein Veröffentlichen von Daten und Datenaktualisierungen gegenüber Clients erheblich verringert.
Die veranschaulichenden Ausführungsformen werden im Hinblick auf bestimmte Architekturen, Middleware, Protokolle, Nachrichten, Kennungen, Netzwerke, Parameter, Zeitlimits, Bedingungen, Einheiten, Datenverarbeitungssysteme, Umgebungen, Komponenten und Anwendungen lediglich als Beispiele beschrieben. Jegliche spezifische Ausprägungen dieser und sonstiger ähnlicher Artefakte sollen die Erfindung nicht beschränken. Jegliche geeignete Ausprägung dieser und sonstiger ähnlicher Artefakte kann innerhalb des Umfangs der veranschaulichenden Ausführungsformen gewählt werden.
Des Weiteren können die veranschaulichenden Ausführungsformen im Hinblick auf einen beliebigen Typ von Daten, Datenquellen oder Zugriff auf eine Datenquelle über ein Datennetzwerk implementiert werden. Jeglicher Typ von Datenspeichereinheit kann die Daten innerhalb des Umfangs der Erfindung für eine Ausführungsform der Erfindung bereitstellen, entweder lokal in einem Datenverarbeitungssystem oder über ein Datennetzwerk. Wenn eine Ausführungsform mithilfe einer mobilen Einheit beschrieben wird, kann ein beliebiger Typ einer Datenspeichereinheit, der zur Verwendung mit der mobilen Einheit geeignet ist, innerhalb des Umfangs der veranschaulichenden Ausführungsformen die Daten für eine solche Ausführungsform bereitstellen, entweder lokal auf der mobilen Einheit oder über ein Datennetzwerk.
Die veranschaulichenden Ausführungsformen werden mithilfe von spezifischem Code, spezifischen Ausgestaltungen, Architekturen, Protokollen, Layouts, Schemata und Werkzeugen lediglich als Beispiele beschrieben und bedeuten keine Beschränkung auf die veranschaulichenden Ausführungsformen. Des Weiteren werden die veranschaulichenden Ausführungsformen in einigen Fällen mithilfe bestimmter Software, Werkzeuge und Datenverarbeitungsumgebungen lediglich als Beispiel zur deutlichen Beschreibung beschrieben. Die veranschaulichenden Ausführungsformen können zusammen mit sonstigen vergleichbaren oder für ähnliche Zwecke bestimmten Strukturen, Systemen, Anwendungen oder Architekturen verwendet werden. Beispielsweise können sonstige vergleichbare mobile Einheiten, Strukturen, Systeme, Anwendungen oder Architekturen davon innerhalb des Umfangs der Erfindung zusammen mit einer solchen Ausführungsform der Erfindung verwendet werden. Eine veranschaulichende Ausführungsform kann in Hardware, Software oder einer Kombination davon implementiert werden.
Die Beispiele in dieser Offenbarung werden lediglich der Deutlichkeit der Beschreibung halber verwendet und bedeuten keine Beschränkung auf die veranschaulichenden Ausführungsformen. Zusätzliche Daten, Operationen, Vorgänge, Aufgaben, Aktivitäten und Manipulationen werden aus dieser Offenbarung ersichtlich, und dieselben werden innerhalb des Umfangs der veranschaulichenden Ausführungsformen in Betracht gezogen.
Jegliche Vorteile, die hierin aufgeführt werden, dienen lediglich als Beispiele und sollen keine Beschränkung auf die veranschaulichenden Ausführungsformen bedeuten. Zusätzliche oder unterschiedliche Vorteile können durch spezifische veranschaulichende Ausführungsformen umgesetzt werden. Des Weiteren kann eine bestimmte veranschaulichende Ausführungsform einige, alle oder keine der oben aufgeführten Vorteile aufweisen.
Unter Bezugnahme auf die Figuren und insbesondere unter Bezugnahme auf die 1 und 2 sind diese Figuren beispielhafte Schaubilder von Datenverarbeitungsumgebungen, in denen veranschaulichende Ausführungsformen implementiert werden können. Die 1 und 2 dienen lediglich als Beispiele und sind nicht dazu bestimmt, eine Einschränkung in Bezug auf die Umgebungen, in denen verschiedene Ausführungsformen implementiert werden können, geltend zu machen oder zu implizieren. Eine bestimmte Implementierung kann auf Grundlage der folgenden Beschreibung zahlreiche Modifizierungen an den dargestellten Umgebungen vornehmen.
1 stellt ein Blockschaubild eines Netzwerks von Datenverarbeitungssystemen dar, in dem veranschaulichende Ausführungsformen implementiert werden können. Bei einer Datenverarbeitungsumgebung 100 handelt es sich um ein Netzwerk von Computern, in dem die veranschaulichenden Ausführungsformen implementiert werden können. Die Datenverarbeitungsumgebung 100 beinhaltet ein Netzwerk 102. Bei dem Netzwerk 102 handelt es sich um das Medium, das zum Bereitstellen von Datenübertragungsverbindungen zwischen verschiedenen Einheiten und Computern verwendet wird, die innerhalb der Datenverarbeitungsumgebung 100 miteinander verbunden sind. Das Netzwerk 102 kann Verbindungen wie zum Beispiel drahtgebundene und drahtlose Datenübertragungsverbindungen oder Lichtwellenleiterkabel beinhalten.
Bei Clients oder Servern handelt es sich lediglich um beispielhafte Rollen bestimmter Datenverarbeitungssysteme, die mit dem Netzwerk 102 verbunden sind, und sie sollen sonstige Konfigurationen oder Rollen für diese Datenverarbeitungssysteme nicht ausschließen. Ein Server 104 und ein Server 106 sind zusammen mit einer Speichereinheit 108 mit dem Netzwerk 102 verbunden. Software-Anwendungen können auf einem beliebigen Computer in der Datenverarbeitungsumgebung 100 ausgeführt werden. Außerdem sind Clients 110, 112 und 114 mit dem Netzwerk 102 verbunden. Ein Datenverarbeitungssystem wie zum Beispiel der Server 104 oder 106 oder der Client 110, 112 oder 114 kann Daten enthalten, und es können Software-Anwendungen und Software-Werkzeuge darauf ausgeführt werden.
Lediglich als Beispiel und ohne jegliche Beschränkung einer solchen Architektur zu implizieren, stellt 1 bestimmte Komponenten dar, die in einer beispielhaften Implementierung einer Ausführungsform verwendbar sind. Beispielsweise werden die Server 104 und 106 und die Clients 110, 112, 114 nur beispielhaft als Server und Clients dargestellt und nicht, um eine Beschränkung einer Client-/Server-Architektur zu implizieren. Als weiteres Beispiel kann eine Ausführungsform innerhalb des Umfangs der veranschaulichenden Ausführungsformen über mehrere Datenverarbeitungssysteme und ein Datennetzwerk hinweg verteilt sein, wie dargestellt, wohingegen eine weitere Ausführungsform in einem einzigen Datenverarbeitungssystem implementiert sein kann. Die Datenverarbeitungssysteme 104, 106, 110, 112 und 114 stellen außerdem beispielhafte Knoten in einem Verbund, Partitionen und sonstige Konfigurationen dar, die zum Implementieren einer Ausführungsform geeignet sind.
Bei einer Einheit 132 handelt es sich um ein Beispiel für eine hierin beschriebene Einheit. Beispielsweise kann die Einheit 132 die Form eines Smartphones, eines Tablet-Computers, eines Laptop-Computers, eines Clients 110 in einer ortsgebundenen oder einer mobilen Form, einer tragbaren Datenverarbeitungseinheit oder einer beliebigen sonstigen geeigneten Einheit annehmen. Jegliche Software-Anwendung, die in 1 so beschrieben wird, dass sie in einem weiteren Datenverarbeitungssystem ausgeführt wird, kann so konfiguriert werden, dass sie in ähnlicher Weise in der Einheit 132 ausgeführt wird. Jegliche Daten oder Informationen, die in 1 in einem weiteren Datenverarbeitungssystem gespeichert oder erzeugt werden, können so konfiguriert werden, dass sie in ähnlicher Weise in der Einheit 132 gespeichert oder erzeugt werden. Eine Back-End-Anwendung 105 auf dem Server 104 weist eine beliebige Anwendung auf, darunter eine Server-Anwendung oder eine Dienstanwendung, die auf eine Anforderung von einer Client-Anwendung antwortet, ohne auf diese beschränkt zu sein. Bei der Einheit 132 handelt es sich um ein nicht beschränkendes Beispiel für einen Client, und bei einem Browser 134 in der Einheit 132 handelt es sich um ein nicht beschränkendes Beispiel für eine Client-Anwendung. Eine Anfordereranwendung 115 in dem Client 114 ist ein weiteres Beispiel für eine Client-Anwendung. Die Anfordereranwendung 115 oder der Browser 134 sendet eine Anforderung, auf die die Back-End-Anwendung 105 antwortet. Eine oder mehrere Agent-Anwendungen 107 auf dem Server 106 empfangen die Anforderung von der Client-Anwendung 115 oder 134, stellen die Anforderung entsprechend dem Typ des angeforderten Dienstes in eine Warteschlange ein, erstellen Sitzungswarteschlangen und übergeben Antworten an die Client-Anwendung 115 oder 134, wie an anderer Stelle in dieser Offenbarung beschrieben. Eine Messaging-Middleware 111 stellt die Steuerung der Warteschlangen und die Veröffentlichungs-/Abonnier-Funktionalität in der in dieser Offenbarung beschriebenen Weise bereit. Beispielsweise vereinfacht die Messaging-Middleware 111 die Erstellung und den Betrieb von Warteschlangen 113. Bei einer Warteschlange der Warteschlangen 113 kann es sich um eine (nicht dargestellte) Dienstwarteschlange handeln, eine weitere Warteschlange der Warteschlangen 113 kann eine (nicht dargestellte) Sitzungswarteschlange sein, und eine weitere Warteschlange der Warteschlangen 113 kann eine (nicht dargestellte) Server-Instanzenwarteschlange sein. Die Messaging-Middleware 111 implementiert außerdem eine (nicht dargestellte) Vermittlungsfunktion, die in der in dieser Offenbarung beschriebenen Weise verwendbar ist. Innerhalb des Umfangs von veranschaulichenden Ausführungsformen weist ein Server oder eine Server-Instanz, die zusammen mit einer Ausführungsform arbeitet, die Back-End-Anwendung 105 auf. Eine Ausführungsform kann innerhalb oder zusammen mit der Back-End-Anwendung 105, innerhalb oder zusammen mit der Messaging-Middleware 111, als weitere (nicht dargestellte) Anwendung oder als eine Kombination davon implementiert werden.
Die Server 104 und 106, die Speichereinheit 108 und die Clients 110, 112 und 114 können mithilfe von drahtgebundenen Verbindungen, drahtlosen Datenübertragungsprotokollen oder einer sonstigen geeigneten Datenkonnektivität eine Verbindung mit dem Netzwerk 102 herstellen. Bei den Clients 110, 112 und 114 kann es sich zum Beispiel um Personalcomputer oder Netzwerkcomputer handeln.
In dem gezeigten Beispiel kann der Server 104 den Clients 110, 112 und 114 Daten wie zum Beispiel Boot-Dateien, Betriebssystemabbilder und Anwendungen bereitstellen. In diesem Beispiel kann es sich bei den Clients 110, 112 und 114 um Clients des Servers 104 handeln. Die Clients 110, 112, 114 oder eine Kombination davon können ihre eigenen Daten, Boot-Dateien, Betriebssystemabbilder und Anwendungen beinhalten. Die Datenverarbeitungsumgebung 100 kann zusätzliche Server, Clients und sonstige Einheiten beinhalten, die nicht dargestellt sind.
In dem dargestellten Beispiel kann es sich bei der Datenverarbeitungsumgebung 100 um das Internet handeln. Das Netzwerk 102 kann einen Bestand von Netzwerken und Gateways darstellen, die das Transmission-Control-Protocol/Internet-Protocol (TCP/IP) und sonstige Protokolle dazu verwenden, Daten miteinander auszutauschen. Im Kern des Internet befindet sich eine Zentralverbindung aus Datenübertragungsverbindungen zwischen Hauptknoten oder Host-Computern, die Tausende von kommerziellen, behördlichen, Bildungs- und sonstigen Computersystemen beinhalten, die Daten und Nachrichten weiterleiten. Selbstverständlich kann die Datenverarbeitungsumgebung 100 auch als eine Reihe verschiedener Netzwerktypen wie zum Beispiel ein Intranet, ein lokales Netzwerk (local area network, LAN) oder ein Weitverkehrs-Netzwerk (wide area network, WAN) implementiert werden. 1 ist als Beispiel gemeint und nicht als architektonische Einschränkung der verschiedenen veranschaulichenden Ausführungsformen.
Neben sonstigen Verwendungen kann die Datenverarbeitungsumgebung 100 zum Implementieren einer Client-/Server-Umgebung verwendet werden, in der die veranschaulichenden Ausführungsformen implementiert werden können. Eine Client-/Server-Umgebung ermöglicht, dass Software-Anwendungen und Daten so über ein Netzwerk hinweg verteilt werden, dass eine Anwendung mithilfe der Interaktivität zwischen einem Client-Datenverarbeitungssystem und einem Server-Datenverarbeitungssystem funktioniert. Die Datenverarbeitungsumgebung 100 kann auch so betrachtet werden, dass sie eine Service-orientierte Architektur einsetzt, in der funktionell aufeinander abgestimmte Software-Komponenten, die über ein Netzwerk hinweg verteilt sind, als zusammenhängende Geschäftsanwendungen gebündelt werden können.
Unter Bezugnahme auf 2 stellt diese Figur ein Blockschaubild eines Datenverarbeitungssystems dar, in dem veranschaulichende Ausführungsformen implementiert werden können. Bei einem Datenverarbeitungssystem 200 handelt es sich um ein Beispiel für einen Computer wie etwa den Server 104 oder den Client 110 in 1 oder um einen weiteren Typ von Einheit, in dem sich computerverwendbarer Programmcode oder Anweisungen, die die Prozesse implementieren, für die veranschaulichenden Ausführungsformen befinden können.
Das Datenverarbeitungssystem 200 ist außerdem repräsentativ für ein Datenverarbeitungssystem oder eine Konfiguration darin wie zum Beispiel die Einheit 132 in 1, in der sich computerverwendbarer Programmcode oder Anweisungen befinden können, die die Prozesse der veranschaulichenden Ausführungsformen implementieren. Das Datenverarbeitungssystem 200 wird lediglich als Beispiel als Computer beschrieben, ohne darauf beschränkt zu sein. Implementierungen in Form sonstiger Einheiten wie zum Beispiel der Einheit 132 in 1 können das Datenverarbeitungssystem 200 modifizieren, wie etwa durch Hinzufügen einer Berührungsschnittstelle, und sogar bestimmte dargestellte Komponenten aus dem Datenverarbeitungssystem 200 entfernen, ohne von der allgemeinen Beschreibung der Vorgänge und Funktionen des hierin beschriebenen Datenverarbeitungssystems 200 abzuweichen.
In dem dargestellten Beispiel verwendet das Datenverarbeitungssystem 200 eine Hub-Architektur, die einen North-Bridge- und Speichersteuereinheiten-Hub (NB/MCH) 202 und einen South-Bridge- und Eingabe/Ausgabe(E/A)-Steuereinheiten-Hub (SB/ICH) 204 beinhaltet. Eine Verarbeitungseinheit 206, ein Hauptspeicher 208 und ein Grafikprozessor 210 sind mit dem North-Bridge- und Speichersteuereinheiten-Hub (NB/MCH) 202 verbunden. Die Verarbeitungseinheit 206 kann einen oder mehrere Prozessoren enthalten und kann mithilfe eines oder mehrerer heterogener Prozessorsysteme implementiert werden. Bei der Verarbeitungseinheit 206 kann es sich um einen Mehrkernprozessor handeln. Der Grafikprozessor 210 kann bei bestimmten Implementierungen durch einen Accelerated Graphics Port (AGP) mit dem NB/MCH 202 verbunden sein.
In dem dargestellten Beispiel ist ein Adapter 212 für ein lokales Netzwerk (LAN) mit dem South-Bridge- und E/A-Steuereinheiten-Hub (SB/ICH) 204 verbunden. Ein Audioadapter 216, ein Tastatur- und Mausadapter 220, ein Modem 222, ein Festwertspeicher (read only memory, ROM) 224, Anschlüsse für universelle serielle Busse (USB) und sonstige Anschlüsse 232 und PCI/PCle-Einheiten 234 sind durch einen Bus 238 mit dem South-Bridge- und E/A-Steuereinheiten-Hub 204 verbunden. Ein Festplattenlaufwerk (hard disk drive, HDD) oder Solid-State-Laufwerk (SSD) 226 und ein CD-ROM-Laufwerk 230 sind durch einen Bus 240 mit dem South-Bridge- und E/A-Steuereinheiten-Hub 204 verbunden. Zu den PCI/PCIe-Einheiten 234 können zum Beispiel Ethernet-Adapter, Erweiterungskarten und PC-Karten für Notebook-Computer gehören. Im Gegensatz zu PCle verwendet PCI eine Kartenbus-Steuereinheit. Bei dem ROM 224 kann es sich zum Beispiel um ein binäres Eingabe/Ausgabe-Flash-System (binary input/output system, BIOS) handeln. Das Festplattenlaufwerk oder das Solid-State-Laufwerk 226 und das CD-ROM-Laufwerk 230 können zum Beispiel eine Integrated-Drive-Electronics(IDE)- oder eine Serial-Advanced-Technology-Attachment(SATA)-Schnittstelle oder Varianten wie zum Beispiel external-SATA (eSATA) und micro-SATA (mSATA) verwenden. Eine Super-E/A- (super I/O, SIO-) Einheit 236 kann durch den Bus 238 mit dem South-Bridge- und E/A-Steuereinheiten-Hub (SB/ICH) 204 verbunden sein.
Speicher wie etwa der Hauptspeicher 208, der ROM 224 oder ein (nicht dargestellter) Flash-Speicher sind einige Beispiele für computerverwendbare Speichereinheiten. Das Festplattenlaufwerk oder das Solid-State-Laufwerk 226, das CD-ROM-Laufwerk 230 und sonstige in ähnlicher Weise verwendbare Einheiten sind einige Beispiele für computerverwendbare Speichereinheiten, die ein computerverwendbares Speichermedium beinhalten.
Ein Betriebssystem wird auf der Verarbeitungseinheit 206 ausgeführt. Das Betriebssystem koordiniert eine Steuerung verschiedener Komponenten innerhalb des Datenverarbeitungssystems 200 in 2 und stellt sie bereit. Bei dem Betriebssystem kann es sich um ein im Handel erhältliches Betriebssystem wie zum Beispiel AIX® (AIX ist eine Marke von International Business Machines Corporation in den Vereinigten Staaten und sonstigen Ländern), Microsoft® Windows^® (Microsoft und Windows sind Marken von Microsoft Corporation in den Vereinigten Staaten und sonstigen Ländern), Linux^® (Linux ist eine Marke von Linus Torvalds in den Vereinigten Staaten und sonstigen Ländern), iOS™ (iOS ist eine Marke von Cisco Systems, Inc. mit Lizenz an Apple Inc. in den Vereinigten Staaten und sonstigen Ländern) oder Android™ (Android ist eine Marke von Google Inc. in den Vereinigten Staaten und sonstigen Ländern) handeln. Ein objektorientiertes Programmiersystem wie zum Beispiel das Programmiersystem Java™ kann zusammen mit dem Betriebssystem ausgeführt werden und Aufrufe an das Betriebssystem von Java™-Programmen oder-Anwendungen bereitstellen, die in dem Datenverarbeitungssystem 200 ausgeführt werden (Java und alle auf Java beruhenden Marken und Logos sind Marken oder eingetragene Marken von Oracle Corporation und/oder seinen verbundenen Unternehmen).
Anweisungen für das Betriebssystem, das objektorientierte Programmiersystem und Anwendungen oder Programme wie zum Beispiel die Agents 107, die Back-End-Anwendung 105 oder die Messaging-Middleware 111 in 1 befinden sich auf Speichereinheiten wie zum Beispiel dem Festplattenlaufwerk 226 oder einer Halbleiter-Datenspeichereinheit und können zur Ausführung durch die Verarbeitungseinheit 206 in zumindest einen von einem oder mehr Speichern wie zum Beispiel den Hauptspeicher 208 geladen werden. Die Prozesse für veranschaulichende Ausführungsformen können durch die Verarbeitungseinheit 206 mithilfe von computerimplementierten Anweisungen durchgeführt werden, die sich in einem Speicher wie beispielsweise dem Hauptspeicher 208, dem Festwertspeicher 224 oder in einer oder mehreren Peripherieeinheiten befinden können.
Die Hardware in den 1 bis 2 kann abhängig von der Implementierung variieren. Sonstige interne Hardware oder Peripherieeinheiten wie zum Beispiel ein Flash-Speicher, ein gleichwertiger nichtflüchtiger Speicher oder optische Plattenlaufwerke und dergleichen können zusätzlich oder anstelle der in 1 bis 2 dargestellten Hardware verwendet werden. Darüber hinaus können die Prozesse der veranschaulichenden Ausführungsformen auf ein Mehrprozessor-Datenverarbeitungssystem angewendet werden.
Bei einigen veranschaulichenden Beispielen kann es sich bei dem Datenverarbeitungssystem 200 um eine mobile Datenverarbeitungseinheit handeln, die im Allgemeinen mit einem Flash-Speicher so eingerichtet ist, dass sie einen nichtflüchtigen Speicher zum Speichern von Betriebssystemdateien und/oder vom Benutzer erzeugten Daten bereitstellt. Ein Bussystem kann einen oder mehrere Busse wie zum Beispiel einen Systembus, einen E/A-Bus und einen PCI-Bus aufweisen. Das Bussystem kann selbstverständlich mithilfe eines beliebigen Typs einer Datenübertragungsstruktur oder Architektur umgesetzt werden, der eine Übertragung von Daten zwischen verschiedenen, mit der Struktur oder Architektur verbundenen Komponenten oder Einheiten bereitstellt.
Eine Datenübertragungseinheit kann eine oder mehrere Einheiten beinhalten, die zum Übertragen und Empfangen von Daten verwendet werden, wie zum Beispiel einen Modem oder einen Netzwerkadapter. Bei einem Speicher kann es sich zum Beispiel um den Hauptspeicher 208 oder um einen Cache wie etwa den Cache handeln, der in dem North-Bridge- und Speichersteuereinheiten-Hub 202 zu finden ist. Eine Verarbeitungseinheit kann eine(n) oder mehrere Prozessoren oder CPUs beinhalten.
Die in den 1 bis 2 dargestellten Beispiele und die oben beschriebenen Beispiele sind nicht dazu bestimmt, der Architektur Beschränkungen aufzuerlegen. Beispielsweise kann es sich bei dem Datenverarbeitungssystem 200 zusätzlich dazu, dass es die Form einer mobilen oder tragbaren Einheit annimmt, auch um einen Tablet-Computer, einen Laptop-Computer oder um eine Telefoneinheit handeln.
Unter Bezugnahme auf 3 stellt diese Figur ein Blockschaubild einer beispielhaften Konfiguration zum fortlaufenden Veröffentlichen von Inhalt in einer Veröffentlichungs-/Abonnier-Client-/Server-Umgebung gemäß einer veranschaulichenden Ausführungsform dar. Die gestrichelte Linie, die eine Client-Seite 302 und eine Server-Seite 304 unterteilt, stellt ein Datennetzwerk wie zum Beispiel das Netzwerk 102 in 1 dar. Die Client-Seite 302 stellt Datenanforderer wie zum Beispiel eine Client-Anwendung 306 dar (die Client-Anwendung wird hierin auch austauschbar als „Client“ bezeichnet). Die Client-Anwendung 306 ist ein Beispiel für den Browser 134 oder die Anfordereranwendung 115 in 1.
Die Server-Seite 304 stellt die Server-seitige Datenverarbeitungsumgebung dar, in der Back-End-Anwendungen und Server, die auf Abfragen in Client-Anforderungen antworten, und sonstige Server-seitige Architekturkomponenten zum Unterstützen ihrer Funktionen arbeiten. Ein Satz aus mehreren Agents 308 wird als Beispiel dargestellt. Eine Instanz des Agents 308 ist ein Beispiel für den Agent 107 in 1. Optional kann eine (nicht dargestellte) Einrichtung für den Lastausgleich oder ein weiteres geeignetes Verteilungsverfahren so eingesetzt werden, dass die eingehenden Anforderungen von der Client-Seite 302 unter mehreren Agents 308 verteilt werden.
Eine Messaging-Middleware 312 ist ein Beispiel für die Messaging-Middleware 111 in 1. Server 314 weisen einen Satz von Servern, Server-Anwendungen oder Back-End-Anwendungen auf, die einen bestimmten Dienst bereitstellen, der in einigen Client-Anforderungen angefordert wird. Als nicht beschränkendes Beispiel kann der Server 314 so als redundanter oder Lastverteilungs-Server arbeiten, dass er einen Datenbankdienst zum Verarbeiten eines bestimmten Typs von Abfrage bereitstellt, der dem Kanal Z zugehörig ist. Sonstige (nicht dargestellte) Sätze von Servern können in ähnlicher Weise so auf der Server-Seite 304 konfiguriert sein, dass sie in ähnlicher Weise sonstige Dienste bereitstellen, die sonstigen Abfragen und Anforderungen zugehörig sind.
Eine Dienstwarteschlange 316 enthält diejenigen Client-Anforderungen, die den Dienst anfordern, der durch eine Server-Instanz der Server 314 bereitgestellt wird. Beispielsweise können die Client-Anwendung 306 und sonstige (nicht dargestellte) Client-Anwendungen eine Abonnementanforderung über bestimmte Daten aus einer Datenbank senden. Ein Agent der Agents 308 empfängt eine solche Anforderung, identifiziert den angeforderten Dienst, ermittelt, dass die Dienstwarteschlange 316 dem angeforderten Dienst zugehörig ist, und stellt die Anforderung in die Dienstwarteschlange 316 ein. Die Server 314 abonnieren die Dienstwarteschlange 316. Ein Server der Server 314 erkennt das Einstellen der Abonnementanforderung in die Dienstwarteschlange 316 und entfernt diese Anforderung zum Verarbeiten aus der Dienstwarteschlange 316.
Es ist zu beachten, dass jeder der Server 314 zustandslos arbeitet. Mit anderen Worten, ein Server der Server 314 führt keine Sitzungs- oder Zustandsdaten, die einen besonderen Bezug zu einer bestimmten Client-Anwendung oder einem weiteren Server haben. Ein Server der Server 314 empfängt einfach eine Abonnementanforderung von der Dienstwarteschlange 316 und verarbeitet die Anforderung. Die empfangene Anforderung kann von einer beliebigen Client-Anwendung stammen, die in einem beliebigen Client-Datenverarbeitungssystem ausgeführt wird.
Im Betrieb beginnt die Client-Anwendung 306, indem sie eine Abonnementanforderung 320 an die Server-Seite 304 sendet. Die Abonnementanforderung 320 fordert eine Abfrage an, die einem Kanal, z.B. dem Kanal Z, entspricht. Der Agent 308 stellt die Anforderung 320 in die Dienstwarteschlange 316 ein. Die Server-Instanz 10 der Server 314 empfängt die Anforderung 320.
In einer Nachricht 318 veröffentlicht der Server 10 einen Inhalt gegenüber der Vermittlungskomponente 324 mit dem Kanal Z und bindet darüber hinaus die Sitzungswarteschlange 326 des Clients 306 an die Vermittlungskomponente 324 als Nutzer des Kanals Z. Beispielsweise veröffentlicht der Server 10 die Nachricht 318 gegenüber der Vermittlungskomponente 324 unter Verwendung eines Weiterleitungsschlüssels mit der Nachricht 318, wobei der Weiterleitungsschlüssel auf die Kanalkennung festgelegt wird, die in dem vorliegenden Beispiel Z lautet.
Angenommen, die Sitzungswarteschlange 326 ist dem Client 306 zugehörig. Die Vermittlungskomponente 324 bindet die Sitzungswarteschlange 326 an den Kanal Z. Die Vermittlungskomponente 324 kann die Sitzungswarteschlange 326 in ähnlicher Weise an eine beliebige Anzahl unterschiedlicher Kanäle für den Client 306 binden. Ähnlich kann die Vermittlungskomponente 324 in ähnlicher Weise eine beliebige Anzahl von Sitzungswarteschlangen, die einer beliebigen Anzahl verschiedener Clients zugehörig sind, an den Kanal Z und/oder an eine beliebige Anzahl unterschiedlicher Kanäle binden.
Im Rahmen von 3 werde angenommen, dass der Server 10 die einzige Veröffentlichungskomponente in dem Kanal Z ist und der Server 10 einen Inhalt in Kanal Z veröffentlicht oder fortfährt, einen Inhalt darin zu veröffentlichen, Die Vermittlungskomponente 324 leitet den veröffentlichten Inhalt von Kanal Z an die Sitzungswarteschlange 326 weiter, den ein Agent der Agents 308 als veröffentlichten Inhalt 322 an den Client 306 übermittelt.
Unter Bezugnahme auf 4 stellt diese Figur ein Blockschaubild einer Bedingung bei einem Kanaleigentum in einem Veröffentlichungs-/Abonnier-System gemäß einer veranschaulichenden Ausführungsform dar. Bei dargestellten Artefakten mit Bezugszeichen, die aus 3 wiederverwendet werden, handelt es sich um dieselben Artefakte, wie sie im Hinblick auf 3 beschrieben worden sind.
Wie im Hinblick auf 3 beschrieben, ist der Server 10 zu einem Zeitpunkt zu einer Veröffentlichungskomponente in dem Kanal Z geworden, und der Client 306 hat den Kanal Z über die Sitzungswarteschlange 326 abonniert. Nun werde angenommen, dass ein weiterer Client, ein Client 406, eine Abonnementanforderung 420 sendet. Ein Agent der Agents 308 stellt die Anforderung 420 in die Dienstwarteschlange 316 ein, damit einer der Server 314 sie abholt. Da potenziell ein beliebiger der Server 314 die Anforderungen aus der Dienstwarteschlange 316 abholen und verarbeiten kann, werde angenommen, dass die Server-Instanz I1 die Anforderung 420 empfängt und sie aus der Dienstwarteschlange 316 entfernt.
Um ein mögliches Problem bei Kanaleigentum in einem Veröffentlichungs-/Abonnier-System zu veranschaulichen, werde angenommen, dass die Anforderung 420 sich auch auf dieselbe Abfrage bezieht wie in der Anforderung 320 von dem Client 306 in 3. Daher entspricht die Anforderung 420 auch dem Kanal Z. Da die Server 314 zustandslos sind, hat der Server I1 keine Kenntnis darüber, dass der Server 10 aufgrund der Nachricht 320 bereits eine Veröffentlichungskomponente des Kanals Z ist. Daher veröffentlicht der Server I1 in einer Nachricht 418 einen Inhalt gegenüber der Vermittlungskomponente 324 für den Kanal Z und bindet darüber hinaus eine Sitzungswarteschlange 426 des Clients 406 an die Vermittlungskomponente 324 für den Kanal Z. Als Beispiel veröffentlicht der Server 11 die Nachricht 418 gegenüber der Vermittlungskomponente 324 mithilfe eines Weiterleitungsschlüssels mit der Nachricht 418, wobei der Weiterleitungsschlüssel auf die Kanalkennung festgelegt ist, die in dem vorliegenden Beispiel Z lautet. Dementsprechend bindet die Vermittlungskomponente 324 die Sitzungswarteschlange 426 an den Kanal Z.
Nun sind die Sitzungswarteschlangen 326 und 426 an den Kanal Z gebunden. Da der Server 10 zuvor aufgrund der Client-Nachricht 320 zu der Veröffentlichungskomponente des Kanals Z geworden ist, fährt der Server 10 fort, in dem Kanal Z zu veröffentlichen, und die Abonnenten des Kanals Z empfangen Veröffentlichungen des Servers 10 in dem Kanal Z. Da der Server l1 aufgrund der Client-Nachricht 320 zu der Veröffentlichungskomponente des Kanals Z geworden ist, fährt der Server 11 ebenfalls fort, in dem Kanal Z zu veröffentlichen, und die Abonnenten des Kanals Z empfangen Veröffentlichungen des Servers 11 in dem Kanal Z.
Wie ersichtlich wird, wenden beide Server Ressourcen zum Berechnen der Abfrage des Kanals Z und zum Veröffentlichen desselben resultierenden Inhalts in dem Kanal Z auf, ohne dass die Server 10 oder 11 Kenntnis darüber haben. Die Abonnenten des Kanals Z empfangen daher einen doppelten Inhalt - einen, der durch den Server 10 veröffentlicht worden ist, und einen weiteren, der durch den Server 11 veröffentlicht worden ist.
Unter Bezugnahme auf 5 stellt diese Figur ein Blockschaubild einer Konfiguration zum Lösen eines Problems bei Kanaleigentum in einem Veröffentlichungs-/Abonnier-System gemäß einer veranschaulichenden Ausführungsform dar. Bei dargestellten Artefakten mit Bezugszeichen, die aus den 3 und 4 wiederverwendet werden, handelt es sich um dieselben Artefakte, wie sie im Hinblick auf 3 beschrieben worden sind.
Gemäß einer Ausführungsform weist jeder der Server 314 eine entsprechende Server-Instanzenwarteschlange von Server-Instanzenwarteschlangen 502 auf. Beispielsweise entspricht eine Server-Instanzenwarteschlange 504 dem Server 10.
Eine Vermittlungskomponente 524 arbeitet in der Weise der Vermittlungskomponente 324 und des Weiteren wie im Hinblick auf 5 beschrieben. Wenn der Server 10 zu der Veröffentlichungskomponente des Kanals Z wird, bindet (506) der Server 10 auch die Server-Instanzenwarteschlange 504 so an die Vermittlungskomponente 524, dass sie Nachrichten empfängt, die die Veröffentlichungskomponente(Z) als Schlüssel aufweisen. Veröffentlichungskomponente(Z) steht einfach für eine bekannte Server-seitige Funktion, die auf die Kanalkennung Z angewendet wird, z.B. so, dass eine Kennung Z' resultiert. Z' entspricht dem Kanal Z durch eine Funktion „Veröffentlichungskomponente“. Wenn der Server 10 eine Nachricht mit einem Weiterleitungsschlüssel Z an die Vermittlungskomponente 524 sendet, leitet die Vermittlungskomponente 524 diese Nachrichten im Wesentlichen an jegliche Sitzungswarteschlangen abonnierender Clients weiter, die mit dem Bindungsschlüssel Z an die Vermittlungskomponente 524 gebunden sind. Wenn der Server 10 eine Nachricht mit einem Weiterleitungsschlüssel Z' an die Vermittlungskomponente 524 sendet, leitet die Vermittlungskomponente 524 diese Nachrichten an jegliche Instanzenwarteschlangen abonnierender Server weiter, die mit dem Bindungsschlüssel Z' an die Vermittlungskomponente 524 gebunden sind. Die Veröffentlichungskomponente(Z) wird hierin auch als „Veröffentlichungskomponente einer Kanalkennung Z'' oder Z' bezeichnet, wenn sie in einem Zusammenhang einer Weiterleitung von einem beliebigen der Server 314 an die Vermittlungskomponente 524 verwendet wird.
Nun weist die Vermittlungskomponente 524 infolge des Bindens 506 zumindest eine Server-Instanzenwarteschlange der Warteschlangen 502 auf, die Nachrichten abonniert hat, die als Schlüssel die Veröffentlichungskomponente der Kanalkennung Z, das heißt Z', aufweisen und wo bestimmte obligatorische Übermittlungsnachrichten, die Z' als Schlüssel aufweisen, wie hierin beschrieben, übermittelt werden können. Bei einer obligatorischen Übermittlungsnachricht handelt es sich um eine Nachricht, die an zumindest eine Empfänger- oder Abonnentenwarteschlange des Kanals übermittelt werden muss oder die anderenfalls durch eine Messaging-Middleware an den Sender zurückgesendet werden muss.
Ein Typ einer obligatorischen Übermittlungsnachricht ist eine Nachricht mit der „Absicht, Veröffentlichungskomponente zu werden“ (hierin auch als „Veröffentlichungskomponentennachricht“ bezeichnet) mit Z' als Weiterleitungsschlüssel, die eine Server-Instanz der Server 314 an eine Vermittlungskomponente senden kann. Wenn eine beliebige Server-Instanzenwarteschlange das Empfangen von Nachrichten abonniert hat, die Z' als Weiterleitungsschlüssel aufweisen, wird die Veröffentlichungskomponentennachricht an diese andere Server-Instanzenwarteschlange übermittelt, anderenfalls wird die Veröffentlichungskomponentennachricht an die Server-Instanz des Senders zurückgesendet.
Wenn der Server 10 zum Beispiel ermittelt, dass der Server 10 zu der Veröffentlichungskomponente des Kanals Z werden sollte, sendet der Server 10 eine Nachricht mit der Absicht, Veröffentlichungskomponente zu werden, mit dem Weiterleitungsschlüssel Z', und die Vermittlungskomponente übermittelt die Nachricht an jegliche sonstige Server-Instanzenwarteschlangen, die das Empfangen von Nachrichten abonniert haben, die Z' als Weiterleitungsschlüssel aufweisen. Wenn keine solche sonstige Server-Instanzenwarteschlange mit dem Bindungsschlüssel Z' an die Vermittlungskomponente gebunden ist, sendet die Vermittlungskomponente die Nachricht mit der Absicht, Veröffentlichungskomponente zu werden, an den Server 10 zurück.
Wenn die Nachricht mit der Absicht, Veröffentlichungskomponente zu werden, an eine Abonnentenwarteschlange übermittelt wird, dient die Übermittlung als Hinweis an den Server 10, dass ein weiterer Server vorhanden ist, der eine Veröffentlichungskomponente des Kanals Z ist. Der Server 10 lässt dann dem vorhanden Veröffentlichungskomponenten-Server den Vortritt.
Wenn die Nachricht mit der Absicht, Veröffentlichungskomponente zu werden, nicht an eine beliebige Abonnentenwarteschlange übermittelt wird, sendet die Vermittlungskomponente 524 die Veröffentlichungskomponentennachricht an den Server 10 zurück. Die fehlgeschlagene Übermittlung dient als Hinweis an den Server 10, dass kein weiterer Server vorhanden ist, der eine Veröffentlichungskomponente des Kanals Z ist. Der Server 10 bindet dann mithilfe des Bindungsschlüssels Z' die Server-Instanzenwarteschlange 504 des Servers 10 als Veröffentlichungskomponente des Kanals Z an die Vermittlungskomponente 524 und aktualisiert darüber hinaus eine interne Anzeige in dem Server 10 so, dass angegeben wird, dass es sich bei dem Server 10 um die Veröffentlichungskomponente für den Kanal Z handelt.
Die Nachricht mit der Absicht, Veröffentlichungskomponente zu werden, versucht, einen Konflikt zwischen einem vorhandenen Veröffentlichungskomponenten-Server eines Kanals und einem weiteren Server zu lösen, der versucht, Veröffentlichungskomponenten-Server desselben Kanals zu werden. In einigen Fällen kann jedoch eine Konkurrenzsituation entstehen, wenn kein bestehender Veröffentlichungskomponenten-Server vorhanden ist, jedoch zwei oder mehr Server gleichzeitig oder nahezu gleichzeitig versuchen, Veröffentlichungskomponenten desselben Kanals zu werden. Ein solcher Konflikt durch Gleichzeitigkeit oder nahezu Gleichzeitigkeit wird nur durch Nachrichten mit der Absicht, Veröffentlichungskomponente zu werden, nicht wirksam gelöst.
Ein weiterer Typ einer obligatorischen Übermittlungsnachricht ist eine Abbruchnachricht mit einer Veröffentlichungskomponente der Kanalkennung, z.B. Z', als Weiterleitungsschlüssel, die eine Server-Instanz der Server 314 an eine Vermittlungskomponente senden kann. Die Abbruchnachricht beinhaltet außerdem einige Daten über den Sender-Server, sodass der Vorrang des Sender-Servers im Verhältnis zu dem Rang eines Empfänger-Servers festgestellt werden kann. Wenn eine beliebige Server-Instanzenwarteschlange das Empfangen von Nachrichten abonniert hat, die diese Veröffentlichungskomponente der Kanalkennung, z.B. Z', als Weiterleitungsschlüssel aufweisen, wird die Abbruchnachricht an diese andere Server-Instanzenwarteschlange übermittelt, anderenfalls wird die Abbruchnachricht an die Server-Instanz des Senders zurückgesendet. Wenn der Server 10 zum Beispiel eine Abbruchnachricht mit Z' als Weiterleitungsschlüssel sendet, übermittelt die Vermittlungskomponente die Nachricht an jegliche Server-Instanzenwarteschlangen, die das Empfangen von Nachrichten abonniert haben, die Z' als Weiterleitungsschlüssel aufweisen. Wenn keine solche sonstige Server-Instanzenwarteschlange mit dem Bindungsschlüssel Z' an die Vermittlungskomponente gebunden ist, sendet die Vermittlungskomponente die Abbruchnachricht an den Server 10 zurück.
Innerhalb des Umfangs der veranschaulichenden Ausführungsformen können beliebige geeignete Daten über einen Server, die dazu verwendbar sind, die relativen Ränge von zwei Servern festzustellen, in einer Abbruchnachricht verwendet werden. Beispielsweise und ohne jegliche Beschränkung daran zu implizieren, kann es sich bei solchen Daten um die Kennungen der Server handeln. Unterschiedliche Server weisen unterschiedliche Kennungen auf, und ein Anordnen der Server-Kennungen kann dazu verwendet werden zu ermitteln, dass z.B. ein Server 1 einen höheren Rang als ein Server 2 aufweist, da 1 eine kleinere Zahl als 2 ist, oder umgekehrt. In ähnlicher Weise können unterschiedliche Server unterschiedliche Ränge, Alter, Positionen in einer Datenverarbeitungsumgebung, verfügbare Kapazitäten, Nutzungen und viele sonstige Typen von Daten aufweisen, die zwischen zwei Servern verglichen werden können, um zu ermitteln, welcher Server zu einem jeweiligen Zeitpunkt einen höheren Rang hat. Jegliche Daten, die für einen Server spezifisch sind und dazu verwendbar sind, den Rang des Servers im Verhältnis zu einem weiteren Server festzustellen, sind innerhalb des Umfangs der veranschaulichenden Ausführungsformen verwendbar.
Nachdem ein Server zu einer Veröffentlichungskomponente eines Kanals geworden ist, besteht eine Möglichkeit, dass ein weiterer Server gleichzeitig ebenfalls zu einer Veröffentlichungskomponente desselben Kanals wird, wie oben beschrieben. Um einen solchen Konflikt durch Gleichzeitigkeit zu vermeiden, sendet der Veröffentlichungskomponenten-Server eine Abbruchnachricht.
Angenommen, sowohl der Server 10 als auch der Server 11 versuchen gleichzeitig oder nahezu gleichzeitig, zu Veröffentlichungskomponenten des Kanals Z zu werden. Sowohl der Server 10 als auch l1 hatten nahezu gleichzeitig Nachrichten mit der Absicht, Veröffentlichungskomponente zu werden, an die Vermittlungskomponente gesendet. Diese Nachrichten wurden an die entsprechenden Server mit dem Hinweis zurückgesendet, dass keine bestehende Veröffentlichungskomponente des Kanals vorhanden ist. Sowohl der Server 10 als auch 11 haften daraufhin ihren internen Zustand so aktualisiert, dass sie sich selbst als Veröffentlichungskomponente des Kanals angaben. Bevor sie die Rolle der Veröffentlichungskomponente übernehmen und die eigentliche Aufgabe eines Veröffentlichens in dem Kanal beginnen, senden der Server 10 und der Server 11 Abbruchnachrichten, um das Problem einer Konkurrenzsituation zu vermeiden. Der Server 10 sendet eine Abbruchnachricht K0 mit Z' als Weiterleitungsschlüssel und zum Beispiel einer Kennung 0 des Servers 10. Der Server 11 empfängt die Abbruchnachricht K0. In ähnlicher Weise sendet der Server 11 eine Abbruchnachricht K1 mit Z' als Weiterleitungsschlüssel und zum Beispiel einer Kennung 1 des Servers 11. Der Server 10 empfängt die Abbruchnachricht K1.
Mithilfe von K0 vergleicht der Server 11 die eigene Kennung „1“ des Servers l1 mit der Kennung des Senders von K0 - „0“. Angenommen, dass in dem Kennungsordnungsschema, das in der Datenverarbeitungsumgebung verwendet wird, der Rang umso höher ist, je kleiner die Zahl ist, schließt der Server 11, dass der Server 10 gegenüber dem Server 11 Vorrang hat. Dementsprechend hebt der Server 11 die Bindung seiner Server-Instanzenwarteschlange mit der Vermittlungskomponente 524 in Bezug auf Z' auf und aktualisiert seinen internen Zustand dahingehend, dass er aufhört, eine Veröffentlichungskomponente des Kanals Z zu sein. In ähnlicher Weise vergleicht der Server 10 mithilfe von K1 die eigene Kennung „0“ des Servers 10 mit der Kennung des Senders von K1 - „1“. Der Server 10 schließt, dass der Server 10 gegenüber dem Server 11 Vorrang hat. Dementsprechend behält der Server 10 die Bindung seiner Server-Instanzenwarteschlange 504 an die Vermittlungskomponente 524 mit dem Bindungsschlüssel Z' bei und erhält seinen internen Zustand als Veröffentlichungskomponente des Kanals Z aufrecht.
Sowohl der Server 10 als auch der Server I1 überprüfen ihren internen Zustand nach einer konfigurierten Zeitspanne. Der interne Zustand des Servers 10 zeigt, dass er noch immer die Veröffentlichungskomponente für den Kanal Z ist, wohingegen der interne Zustand des Servers 11 zeigt, dass er nicht mehr die Veröffentlichungskomponente des Kanals Z ist. Folglich übernimmt der Server 10 die Rolle der Veröffentlichungskomponente für den Kanal Z und beginnt zu veröffentlichen, wohingegen der Server 11 dies nicht tut. Auf diese Weise wird sogar ein Konflikt unter Veröffentlichungskomponenten durch Gleichzeitigkeit gelöst.
Unter Bezugnahme auf 6 stellt diese Figur einen Ablaufplan eines beispielhaften Prozesses für Kanaleigentum in einem Veröffentlichungs-/Abonnier-System gemäß einer veranschaulichenden Ausführungsform dar. Der Prozess 600 kann auf einem Server wie zum Beispiel dem Server 10 in den 3, 4 oder 5 implementiert werden, wobei der Server entweder so modifiziert wird, dass er eine hierin beschriebene Operation durchführt, oder der Server zusammen mit einer Anwendung arbeitet, die eine hierin beschriebene Operation implementiert.
Der Server, z.B. die Server-Instanz 10, empfängt eine Abonnementanforderung von einem Client (Block 602). Der Server ermittelt, dass die Anforderung lautet, einen Kanal zu abonnieren, z.B. den Kanal Z (Block 604). Der Server bindet die Sitzungswarteschlange des Clients mithilfe von Z als Bindungsschlüssel an die Vermittlungskomponente (Block 606).
Für alle anderen Server-Instanzenwarteschlangen veröffentlicht der Server gegenüber der Vermittlungskomponente zur obligatorischen Übermittlung eine Veröffentlichungsabsichtsnachricht mithilfe der Veröffentlichungskomponente(Z), das heißt Z', als Weiterleitungsschlüssel (Block 608). Der Server ermittelt, ob die Veröffentlichungsabsichtsnachricht an jegliche Server-Instanzenwarteschlangen übermittelt wurde, oder alternativ, ob die Veröffentlichungsabsichtsnachricht nicht als nicht übermittelt zurückgesendet worden ist (Block 610). Wenn die Veröffentlichungsabsichtsnachricht übermittelt, d.h. nicht zurückgesendet wurde (der Pfad „Ja“ des Blocks 610), beendet der Server den Prozess 600 anschließend.
Wenn die Veröffentlichungsabsichtsnachricht nicht übermittelt, d.h. zurückgesendet wurde (der Pfad „Nein“ des Blocks 610), bindet der Server seine Server-Instanzenwarteschlange mit dem Schlüssel Z' an die Vermittlungskomponente (Block 612). Der Server speichert Daten wie zum Beispiel Daten über den internen Zustand über sich selbst, die angeben, dass der Server 10 die Veröffentlichungskomponente des Kanals Z ist (Block 614). Der Server beendet den Prozess 600 anschließend oder geht zu einem Prozess 700 in 7 über.
Unter Bezugnahme auf 7 stellt diese Figur einen Ablaufplan eines beispielhaften Prozesses zum Auflösen einer Konkurrenzsituation mit mehreren Veröffentlichungskomponenten durch Gleichzeitigkeit oder nahezu Gleichzeitigkeit gemäß einer veranschaulichenden Ausführungsform dar. Der Prozess 700 kann auf einem Server wie zum Beispiel dem Server 10 in den 3, 4 oder 5 implementiert werden, wobei der Server entweder so modifiziert wird, dass er eine hierin beschriebene Operation durchführt, oder der Server zusammen mit einer Anwendung arbeitet, die eine hierin beschriebene Operation implementiert.
Der Server, z.B. die Server-Instanz 10, veröffentlicht gegenüber der Vermittlungskomponente für jegliche sonstige Abonnenten-Server-Instanzenwarteschlangen eine Abbruchnachricht, die die Rangangabe der Veröffentlichungskomponente enthält, mit der Veröffentlichungskomponente(Z), z.B. Z', als Weiterleitungsschlüssel (Block 702). Der Server empfängt und verarbeitet jegliche Abbruchnachrichten von jeglichem sonstigem Server, der eine Veröffentlichungskomponente des Kanals Z ist (Block 704). Nachdem ein Zeitraum verstrichen ist, wie zum Beispiel ein Zeitraum, in dem der Server alle Abbruchnachrichten empfangen haben sollte, die eintreffen könnten, und der Server seinen eigenen relativen Rang unter allen Sendern von Abbruchnachrichten festgestellt hat, ermittelt der Server, ob der Server noch die Veröffentlichungskomponente des Kanals Z bleibt (Block 706).
Wenn der Server noch die Veröffentlichungskomponente für den Kanal Z ist, d.h. der Server 10 den höchsten relativen Rang von allen gleichzeitig bestehenden Veröffentlichungskomponenten des Kanals Z hat (der Pfad „Ja“ des Blocks 706), beginnt der Server in dem Kanal Z zu veröffentlichen (Block 708). Anschließend beendet der Server den Prozess 700.
Wenn der Server nicht mehr die Veröffentlichungskomponente für den Kanal Z ist, d.h. der Server 10 nicht den höchsten relativen Rang von allen gleichzeitig bestehenden Veröffentlichungskomponenten des Kanals Z hat (der Pfad „Nein“ des Blocks 706), aktualisiert der Server Daten über den eigenen Zustand des Servers so, dass er angibt, dass der Server nicht die Veröffentlichungskomponente des Kanals Z ist (Block 710). Anschließend beendet der Server den Prozess 700.
Unter Bezugnahme auf 8 stellt diese Figur einen Ablaufplan eines beispielhaften Prozesses zum Beseitigen einer doppelten Veröffentlichungskomponente gemäß einer veranschaulichenden Ausführungsform dar. Der Prozess 800 kann auf einem Server wie zum Beispiel dem Server 10 in den 3, 4 oder 5 implementiert werden, wobei der Server entweder so modifiziert wird, dass er eine hierin beschriebene Operation durchführt, oder der Server zusammen mit einer Anwendung arbeitet, die eine hierin beschriebene Operation implementiert.
Der Server, z.B. die Server-Instanz 10, bei dem es sich um eine Veröffentlichungskomponente eines beispielhaften Kanals Z handelt, empfängt eine Abbruchnachricht von einem weiteren Server, der ebenfalls eine Veröffentlichungskomponente desselben Kanals ist, z.B. dem Server 11 (Block 802). Der Server löst in einer zuvor beschriebenen Weise, welcher von dem Server 10 und dem Server 11 übergeordnet ist oder im Verhältnis zueinander Vorrang hat (Block 804).
Wenn der Server ermittelt, dass 10 Vorrang hat (der Pfad „10“ des Blocks 806), legt der Server einen internen Zustand so fest, dass angegeben wird, dass der Server 10 die Veröffentlichungskomponente des Kanals Z ist (Block 808). Der Server veröffentlicht gegenüber der Vermittlungskomponente für jegliche sonstige Abonnenten-Server-Instanzenwarteschlangen eine Abbruchnachricht, die die Rangangabe der Veröffentlichungskomponente enthält, mit der Veröffentlichungskomponente(Z), z.B. Z', als Weiterleitungsschlüssel (Block 810). Anschließend beendet der Server den Prozess 800. Die Abbruchnachricht wird in der Weise des Prozesses 700 in 7 verarbeitet.
Wenn der Server ermittelt, dass 11 Vorrang hat (der Pfad „11“ des Blocks 806), hebt der Server die Bindung der Server-Instanzenwarteschlange des Servers an die Vermittlungsungskomponente als Veröffentlichungskomponente des Kanals Z auf (Block 812). Der Server aktualisiert einen internen Zustand so, dass er angibt, dass der Server 10 nicht die Veröffentlichungskomponente des Kanals Z ist (Block 814). Anschließend beendet der Server den Prozess 800.
Die veranschaulichenden Ausführungsformen sind mithilfe bestimmter beispielhafter Nachrichten lediglich zur Deutlichkeit der Beschreibung und nicht als Beschränkung der veranschaulichenden Ausführungsformen beschrieben worden. Aus dieser Offenbarung erkennen Fachleute, dass die hierin beschriebenen veranschaulichenden Ausführungsformen keine Kenntnis von dem spezifischen Transportprotokoll haben, das zum Übertragen von Anforderungen und Antworten zwischen Clients und Servern verwendet wird, und so gestaltet werden können, dass sie mit HTTP oder sonstigen Protokollen arbeiten, und dasselbe wird innerhalb des Umfangs der veranschaulichenden Ausführungsformen in Betracht gezogen.
Folglich werden in den veranschaulichenden Ausführungsformen für Kanaleigentum in einem Veröffentlichungs-/Abonnier-System ein(e) computerimplementierte(s) Verfahren, System oder Vorrichtung und ein Computerprogrammprodukt bereitgestellt. Wo eine Ausführungsform oder ein Abschnitt davon im Hinblick auf einen Typ einer Einheit beschrieben wird, werden das/die computerimplementierte Verfahren, System oder Vorrichtung, das Computerprogrammprodukt oder ein Abschnitt davon zur Verwendung mit einer geeigneten und vergleichbaren Ausprägung dieses Typs einer Einheit gestaltet oder konfiguriert.
Bei der vorliegenden Erfindung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt handeln. Das Computerprogrammprodukt kann ein computerlesbares Speichermedium (oder -medien) beinhalten, auf denen sich computerlesbare Programmanweisungen befinden, die bewirken, dass ein Prozessor Aspekte der vorliegenden Erfindung ausführt.
Bei dem computerlesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Anweisungen zur Verwendung durch eine Anweisungsausführungseinheit aufrechterhalten und speichern kann. Bei dem computerlesbaren Speichermedium kann es sich zum Beispiel um eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiter-Speichereinheit oder um eine beliebige geeignete Kombination aus Obigen handeln, ohne auf diese beschränkt zu sein. Eine nicht erschöpfende Liste konkreterer Beispiele für das computerlesbare Speichermedium beinhaltet folgende: eine tragbare Computerdiskette, eine Festplatte, einen Direktzugriffsspeicher (random access memory, RAM), einen Festwertspeicher (read-only memory, ROM), einen löschbaren, programmierbaren Festwertspeicher (erasable programmable read-only memory, EPROM oder Flash-Speicher), einen statischen Direktzugriffsspeicher (static random access memory, SRAM), einen tragbaren Compact-Disk-Festwertspeicher (CD-ROM), eine digitale, vielseitige Scheibe (digital versatile disk, DVD), einen Speicher-Stick, eine Diskette, eine mechanisch codierte Einheit wie zum Beispiel Lochkarten oder erhöhte Strukturen in einer Nut, auf denen Anweisungen aufgezeichnet sind, oder eine beliebige geeignete Kombination aus Obigen. So, wie dieser Begriff hierin verwendet wird, ist ein computerlesbares Speichermedium nicht als per se transitorische Signale auszulegen, wie zum Beispiel Funkwellen oder sonstige sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder sonstige Übertragungsmedien ausbreiten (z.B. Lichtimpulse, die ein Lichtwellenleiterkabel durchlaufen) oder elektrische Signale, die durch eine Leitung übertragen werden.
Die hierin beschriebenen computerlesbaren Programmanweisungen können von einem computerlesbaren Speichermedium über ein Netzwerk, zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrs-Netzwerk und/oder ein drahtloses Netzwerk auf jeweilige Datenverarbeitungs-/Verarbeitungseinheiten oder auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenübertragungsleiter, drahtlose Übertragungssysteme, Router, Firewalls, Switches, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder eine Netzwerkschnittstelle in jeder Datenverarbeitungs-/
Verarbeitungseinheit empfängt computerlesbare Programmanweisungen von dem Netzwerk und leitet die computerlesbaren Programmanweisungen zum Speichern in einem computerlesbaren Speichermedium innerhalb der jeweiligen Datenverarbeitungs-/Verarbeitungseinheit weiter.
Bei computerlesbaren Programmanweisungen zum Ausführen von Operationen der vorliegenden Erfindung kann es sich um Assembler-Anweisungen, Anweisungen einer Anweisungssatzarchitektur (instruction-set-architecture, ISA), Maschinenanweisungen, maschinenabhängige Anweisungen, Microcode, Firmware-Anweisungen, Zustandseinstelldaten oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination einer oder mehrerer Programmiersprachen geschrieben sind, darunter in einer objektorientierten Programmiersprache wie zum Beispiel Smalltalk, C++ oder dergleichen und in herkömmlichen verfahrensorientierten Programmiersprachen wie etwa der Programmiersprache „C“ oder ähnlichen Programmiersprachen. Die computerlesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, zum Teil auf dem Computer des Benutzers, als eigenständiges Software-Paket, zum Teil auf dem Computer des Benutzers und zum Teil auf einem entfernt angeordneten Computer oder vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. In letzterem Szenario kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch jede Art von Netzwerk verbunden sein, zum Beispiel durch ein lokales Netzwerk (LAN) oder ein Weitverkehrs-Netzwerk (WAN), oder die Verbindung kann mit einem externen Computer (zum Beispiel über das Internet mithilfe eines Internet-Diensteanbieters) hergestellt werden. Bei einigen Ausführungsformen können elektronische Schaltungen wie zum Beispiel programmierbare Logikschaltungen, feldprogrammierbare Gate-Arrays (FPGA) oder programmierbare Logik-Arrays (PLA) die computerlesbaren Programmanweisungen durch Einsetzen von Zustandsdaten der computerlesbaren Programmanweisungen zum Anpassen der elektronischen Schaltungen so ausführen, dass Aspekte der vorliegenden Erfindung durchgeführt werden.
Aspekte der vorliegenden Erfindung werden hierin unter Bezugnahme auf Ablaufpläne und/oder Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es versteht sich, dass jeder Block der Ablaufpläne und/oder Blockschaubilder und Kombinationen von Blöcken in den Ablaufplänen und/oder Blockschaubildern durch computerlesbare Programmanweisungen implementiert werden kann/können.
Diese computerlesbaren Programmanweisungen können für einen Prozessor eines Universalcomputers, eines Spezialcomputers oder einer sonstigen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, sodass die Anweisungen, die über den Prozessor des Computers oder einer sonstigen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, ein Mittel zum Implementieren der Funktionen/Vorgänge erzeugen, die in dem Block oder den Blöcken der Ablaufpläne und/oder der Blockschaubilder angegeben sind. Diese computerlesbaren Programmanweisungen können auch in einem computerlesbaren Speichermedium gespeichert werden, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder sonstige Einheiten so steuern kann, dass sie in einer bestimmten Weise funktionieren, sodass das computerlesbare Speichermedium, in dem Anweisungen gespeichert sind, einen Herstellungsgegenstand (article of manufacture) aufweist, der Anweisungen beinhaltet, die Aspekte der/des Funktion/Vorgangs implementieren, die/der in dem Block oder den Blöcken der Ablaufpläne und/oder der Blockschaubilder angegeben ist.
Die computerlesbaren Programmanweisungen können außerdem so auf einen Computer, eine sonstige programmierbare Datenverarbeitungsvorrichtung oder eine sonstige Einheit geladen werden, dass sie bewirken, dass eine Reihe von Schritten eines Vorgangs auf dem Computer, einer sonstigen programmierbaren Vorrichtung oder einer sonstigen Einheit so ausgeführt wird, dass ein computerimplementierter Prozess erzeugt wird, sodass die auf dem Computer, einer sonstigen programmierbaren Vorrichtung oder einer sonstigen Einheit ausgeführten Anweisungen die in dem Block oder den Blöcken des Ablaufplans/der Ablaufpläne und/oder der Blockschaubilder angegebenen Funktionen/Vorgänge implementieren.
Die Ablaufpläne und Blockschaubilder in den Figuren veranschaulichen die Architektur, Funktionalität und Arbeitsweise möglicher Implementierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaubildern ein Modul, ein Segment oder einen Abschnitt von Anweisungen darstellen, der eine oder mehrere ausführbare Anweisungen zum Implementieren der angegebenen logischen Funktion(en) aufweist. Bei einigen alternativen Implementierungen können die in dem Block vermerkten Funktionen in einer anderen Reihenfolge als in den Figuren vermerkt auftreten. Beispielsweise können je nach einbezogener Funktionalität zwei nacheinander dargestellte Blöcke sogar im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können bisweilen in der umgekehrten Reihenfolge ausgeführt werden. Es ist ferner zu beachten, dass jeder Block der Blockschaubilder und/oder der Ablaufpläne und Kombinationen von Blöcken in den Blockschaubildern und/oder in den Ablaufplänen durch Spezialsysteme auf Grundlage von Hardware implementiert werden können, die die angegebenen Funktionen oder Vorgänge ausführen oder Kombinationen von Spezial-Hardware und Computeranweisungen ausführen.

Claims

Verfahren zum Verwalten von Kanaleigentum in einer Veröffentlichungs-/ Abonnier-Datenverarbeitungsumgebung, wobei das Verfahren aufweist: Ermitteln auf einem ersten Server (314) mithilfe eines Prozessors (206) und eines Speichers (208), dass sich eine Abonnementanforderung (320) von einem Client (306) auf einen Kanal bezieht (604), wobei der Kanal eine Kanalkennung aufweist; Bewirken an einer Vermittlungskomponente (324) in einer Messaging-Middleware, dass eine Sitzungswarteschlange (426), die dem Client (306) zugehörig ist, an den Kanal gebunden wird; Konfigurieren, dass eine obligatorische Übermittlungsnachricht mithilfe (320) einer Veröffentlichungskomponentenkennung durch die Vermittlungskomponente (324) weitergeleitet wird, wobei die Veröffentlichungskomponentenkennung mit der Kanalkennung in Beziehung steht; Kommunizieren der obligatorischen Übermittlungsnachricht (320) von dem ersten Server zu der Vermittlungskomponente (324) so, dass eine Absicht des ersten Servers (314) angegeben wird, zu einer Veröffentlichungskomponente des Kanals zu werden, wobei die obligatorische Übermittlungsnachricht (320) bewirkt, dass das Kanaleigentum des Kanals auf eine einzige Veröffentlichungskomponente beschränkt wird, Empfangen einer Abbruchnachricht an dem ersten Server (314) von einem zweiten Server (314), wobei die Abbruchnachricht entsprechend einer Veröffentlichungskomponentenkennung weitergeleitet wird und eine Rangangabe aufweist, die dem zweiten Server entspricht, und wobei sowohl der erste Server als auch der zweite Server versuchen, zu Veröffentlichungskomponenten von Inhalt in dem Kanal zu werden; Ermitteln, ob der erste Server (314) die Veröffentlichungskomponente des Kanals bleibt, durch Vergleichen der Rangangabe, die dem zweiten Server (314) entspricht, aus der Abbruchnachricht mit einer Rangangabe, die dem ersten Server (314) entspricht; und in Reaktion darauf, dass der zweite Server (314) einen höheren Rang als der erste Server (314) hat, der nicht die Veröffentlichungskomponente des Kanals bleibt, Aufheben der Bindung einer Server-Instanzenwarteschlange, die dem ersten Server (314) zugehörig ist, an die Vermittlungskomponente (324, 524).
Verfahren nach Anspruch 1, das des Weiteren aufweist: in Reaktion darauf, dass die obligatorische Übermittlungsnachricht (320) an jegliche Server-Instanzenwarteschlangen (504) in der Messaging-Middleware (312) nicht übermittelbar ist, Binden (612) einer Server-Instanzenwarteschlange, die dem ersten Server (314) zugehörig ist, so, dass sie jegliche Nachrichten empfängt, die mithilfe der Veröffentlichungskomponentenkennung durch die Vermittlungskomponente (324) weitergeleitet werden; und Aktualisieren eines Indikators so, dass angegeben wird, dass es sich bei dem ersten Server um die Veröffentlichungskomponente des Kanals handelt (614).
Verfahren nach Anspruch 1, das des Weiteren aufweist: Ableiten der Veröffentlichungskomponentenkennung mithilfe der Kanalkennung als Parameter einer Funktion.
Verfahren nach Anspruch 1, das des Weiteren aufweist: Konfigurieren, dass eine Abbruchnachricht mithilfe einer Veröffentlichungskomponentenkennung durch die Vermittlungskomponente (324, 524) weitergeleitet wird; Kommunizieren der Abbruchnachricht von dem ersten Server (314) zu der Vermittlungskomponente (324, 524); und in Reaktion auf das Kommunizieren der Abbruchnachricht Bewirken, dass die Vermittlungskomponente (324, 524) die Abbruchnachricht an einen Satz von Server-Instanzenwarteschlangen (504) weiterleitet, die einem Satz sonstiger Server entsprechen; nach einem Zeitraum im Anschluss an das Kommunizieren der Abbruchnachricht Ermitteln, ob der erste Server (314) die Veröffentlichungskomponente des Kanals bleibt; und in Reaktion darauf, dass der erste Server die Veröffentlichungskomponente des Kanals bleibt, Beginnen, Inhalt von dem ersten Server (314) in Reaktion auf die Abonnementanforderung zu veröffentlichen.
Verfahren nach Anspruch 4, das des Weiteren aufweist: Konfigurieren der Abbruchnachricht mit einer Rangangabe, die dem ersten Server (314) entspricht, wobei die Rangangabe Server-Instanzendaten aufweist, die dazu verwendbar sind, einen Rang des ersten Servers (314) im Verhältnis zu einem zweiten Server (314) für den Kanal festzustellen, wobei sowohl der erste Server (314) als auch der zweite Server (314) versuchen, zu Veröffentlichungskomponenten von Inhalt in dem Kanal zu werden.
Verfahren nach Anspruch 5, das des Weiteren aufweist: Ableiten der Rangangabe, die dem ersten Server (314) entsprechen, aus den Server-Instanzendaten und der Kanalkennung.
Verfahren nach Anspruch 1, das des Weiteren aufweist: Konfigurieren, dass eine Abbruchnachricht mithilfe einer Veröffentlichungskomponentenkennung durch die Vermittlungskomponente (324, 524) weitergeleitet wird; Kommunizieren einer Abbruchnachricht von dem ersten Server zu der Vermittlungskomponente; und in Reaktion auf das Kommunizieren der Abbruchnachricht Bewirken, dass die Vermittlungskomponente (324, 524) die Abbruchnachricht an einen Satz von Server-Instanzenwarteschlangen weiterleitet (504), die einem Satz sonstiger Server (314) entsprechen; nach einem Zeitraum im Anschluss an das Kommunizieren der Abbruchnachricht Ermitteln, ob der erste Server (314) die Veröffentlichungskomponente des Kanals bleibt; und in Reaktion darauf, dass der erste Server (314) nicht die Veröffentlichungskomponente des Kanals bleibt, Aktualisieren eines Indikators so, dass angegeben wird, dass es sich bei dem ersten Server (314) nicht um die Veröffentlichungskomponente des Kanals handelt.
Verfahren nach Anspruch 1, das des Weiteren aufweist: Empfangen einer Abbruchnachricht an dem ersten Server (314) von einem zweiten Server (314), wobei die Abbruchnachricht entsprechend einer Veröffentlichungskomponentenkennung weitergeleitet wird und eine Rangangabe aufweist, die dem zweiten Server entspricht, und wobei sowohl der erste Server (314) als auch der zweite Server (314) versuchen, zu Veröffentlichungskomponenten von Inhalt in dem Kanal zu werden; Ermitteln, ob der erste Server (314) die Veröffentlichungskomponente des Kanals bleibt, durch Vergleichen der Rangangabe, die dem zweiten Server (314) entspricht, aus der Abbruchnachricht mit einer Rangangabe, die dem ersten Server (314) entspricht; und in Reaktion darauf, dass der erste Server (314) einen höheren Rang als der zweite Server (314) hat, Aktualisieren eines Indikators so, dass angegeben wird, dass es sich bei dem ersten Server (314) um die Veröffentlichungskomponente des Kanals handelt.
Verfahren nach Anspruch 1, das des Weiteren aufweist: Konfigurieren, dass eine zweite Abbruchnachricht mithilfe einer Veröffentlichungskomponentenkennung durch die Vermittlungskomponente (324, 524) weitergeleitet wird; Konfigurieren der zweiten Abbruchnachricht mit der Rangangabe, die dem ersten Server (314) entspricht; Kommunizieren der zweiten Abbruchnachricht von dem ersten Server (314) zu der Vermittlungskomponente; und in Reaktion auf das Austauschen der zweiten Abbruchnachricht Bewirken, dass die Vermittlungskomponente (324, 524) die zweite Abbruchnachricht an einen Satz von Server-Instanzenwarteschlangen weiterleitet, die einem Satz sonstiger Server (314) entsprechen.
Verfahren nach Anspruch 1, das des Weiteren aufweist: Empfangen der Abonnementanforderung an dem ersten Server (314); und Ermitteln, dass die Abonnementanforderung einen Typ aufweist, wobei der Typ dem Kanal entspricht.
Verfahren nach Anspruch 1, das des Weiteren aufweist: Empfangen der Abonnementanforderung an dem ersten Server (314); und Durchführen einer Hash-Funktion an einer Abfrage in der Anforderung so, dass ein Hash-Wert gewonnen wird, wobei der Hash-Wert dem Kanal entspricht, und wobei der Typ dem Kanal entspricht.
Verfahren nach Anspruch 1, wobei die Sitzungswarteschlange (326) eindeutig dem Client (306) in einer Messaging-Middleware (312) zugehörig ist, wobei die Sitzungswarteschlange (326) mithilfe der Kanalkennung als Bindungsschlüssel an die Vermittlungskomponente (324, 524) gebunden ist, wobei die Veröffentlichungskomponentenkennung einen Weiterleitungsschlüssel ausbildet, und wobei die Vermittlungskomponente (324, 524) die obligatorische Übermittlungsnachricht mithilfe des Weiterleitungsschlüssels weiterleitet.
Computerverwendbares Programmprodukt, das eine computerlesbare Speichereinheit aufweist, die computerverwendbaren Code zum Verwalten von Kanaleigentum in einer Veröffentlichungs-/Abonnier-Datenverarbeitungsumgebung aufweist, wobei der computerverwendbare Code aus Ausführung des Verfahrens gemäß einem der Ansprüche 1 bis 12 aufweist;
Datenverarbeitungssystem zum Verwalten von Kanaleigentum in einer Veröffentlichungs-/Abonnier-Datenverarbeitungsumgebung, wobei das Datenverarbeitungssystem aufweist: eine Speichereinheit (208), wobei die Speichereinheit (208) computerverwendbaren Programmcode speichert; und einen Prozessor (206), wobei der Prozessor den computerverwendbaren Programmcode ausführt, und wobei der computerverwendbare Programmcode zur Ausführungdes Verfahrens gemäß einem der Ansprüche 1 bis 12 ausführt.