DE60207251T2 - Verfahren zur sicherstellung des betriebs eines gruppierten nachrichtenvergebenden servers während knotenausfällen und netzwerkzuteilungen - Google Patents

Verfahren zur sicherstellung des betriebs eines gruppierten nachrichtenvergebenden servers während knotenausfällen und netzwerkzuteilungen Download PDF

Info

Publication number
DE60207251T2
DE60207251T2 DE60207251T DE60207251T DE60207251T2 DE 60207251 T2 DE60207251 T2 DE 60207251T2 DE 60207251 T DE60207251 T DE 60207251T DE 60207251 T DE60207251 T DE 60207251T DE 60207251 T2 DE60207251 T2 DE 60207251T2
Authority
DE
Germany
Prior art keywords
state
message
messages
manager
managers
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE60207251T
Other languages
English (en)
Other versions
DE60207251D1 (de
Inventor
Paul Giotta
Honig Jesper SPRING
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Softwired AG
Original Assignee
Softwired AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Softwired AG filed Critical Softwired AG
Publication of DE60207251D1 publication Critical patent/DE60207251D1/de
Application granted granted Critical
Publication of DE60207251T2 publication Critical patent/DE60207251T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/465—Distributed object oriented systems

Description

  • FELD DER ERFINDUNG
  • Die Erfindung befindet sich im Bereich von Methoden und Systemen von Nachrichtenlieferung zwischen Computerprogrammen über einen Nachrichtenserver. Diese Erfindung betrifft insbesondere das Feld der Nachrichtenorientierten Middleware (Message Oriented Middleware – MOM).
  • HINTERGRUND DER ERFINDUNG
  • MOM ermöglicht zahlreichen Computerprogrammen, diskrete Nachrichten miteinander über ein Kommunikationsnetz auszutauschen. MOM kennzeichnet sich durch eine „lose Kupplung" von Nachrichtenherstellern und Nachrichtenbenutzern, wobei der Hersteller einer Nachricht nicht braucht, die Identität, die Lokalisierung sowie die Anzahl von Benutzern dieser Nachricht zu kennen. Darüber hinaus, wenn ein vermittelnder Nachrichtenserver eingesetzt wird, kann die Nachrichtenlieferung sichergestellt werden, sogar wenn die endgültigen Benutzer der Nachricht in der Zeit deren Herstellung unerreichbar sind. Das kann der Verbindungsorientierten Middleware (Connection Oriented Middleware) entgegengestellt werden, wobei es erforderlich ist, dass ein Computerprogramm über Details der Identität und der Netzlokalisierung eines anderen Computers verfügt, um eine Verbindung mit diesem Computer erstellen zu können, bevor Daten mit ihm ausgetauscht werden. Um eine Verbindung zu erstellen, müssen beide Computer über die ganze Zeit, wenn die Verbindung aktiv ist, erreichbar und ansprechbar sein.
  • EP-A 0 853 277 beschreibt eine modulare Middleware/Anwendungssoftware zur Bereitstellung der nachrichtenorientierten Kommunikation zwischen Anwendungen. Sie besteht aus einem Cluster von individuellen, netzverbundenen Nachrichtenservern, die eine Vielfalt von Außenverbindungen umfassen, die den Anwendungen ermöglichen, miteinander zu verbinden und zu kommunizieren. Für die verbindende Anwendung ist der Cluster von Nachrichtenservern transparent, d.h. er scheint ein einzelner, zentralisierter Nachrichtenserver zu sein. Während des Empfangs von Nachrichten aus einer veröffentlichenden Anwendung über eine der Außenverbindungen selektiert die Nachrichtenmiddleware einen oder mehr Empfänger der Nachricht und bewirkt, dass die Nachrichten an eine oder mehr korrespondierende Anwendungen über die Verbindung, an der diese Anwendungen) angeschlossen ist/sind, geliefert werden. Die Nachrichtenmiddleware unterstützt die Veröffentlicher, die spezifizieren können, dass ihre veröffentlichten Nachrichten dauerhaft gespeichert werden, um der Speicher aus fehlertoleranten Gründen stabil zu machen. Sie ermöglicht auch einem Empfänger, Nachrichten zu empfangen, die während seiner vorübergehenden Abwesenheit gesendet worden sind. Die Nachrichtenmiddleware unterstützt auch atomare Veröffentlichung und/oder Empfangung von einem Nachrichtensatz im Rahmen von Transaktionen. Während einer Transaktion erfasst die Nachrichtenmiddleware Aktionen und kompensierende Aktionen für jede erfasste ungetane Aktion. Nachdem ein Fehler detektiert worden ist, wird die Transaktion gestoppt und die so weit ausgeführten Aktionen werden annulliert. Ereignisse (d.h. der Empfang einer Nachricht bzw. die Sendung einer Nachricht an eine Anwendung) innerhalb des Clusters von Nachrichtenservern sowie Ereignisse, die durch Verbindungen generiert werden, werden über den Cluster von Nachrichtenservern mittels eines unterliegenden, betriebssicheren Nachrichtensystems verteilt.
  • Diese Erfindung betrifft insbesondere den Fall, wenn ein vermittelnder Nachrichtenserver eingesetzt wird, um Nachrichten zu speichern und diese an Benutzer zu verteilen. Obwohl Hersteller und Benutzer (gemeinsam „Kunden" genannt) miteinander auf lose Weise während der Kommunikation über MOM gekuppelt sind, werden normalerweise die vermittelnden Nachritenserver zur Kommunikation mit diesen Kunden auf eine verbindungsorientierte Weise benötigt. Diese Ermöglichung, Absender und Empfänger miteinander zu kommunizieren, ohne dass beide zur gleichen Zeit erreichbar sind, setzt voraus, dass der Server ganze Zeit erreichbar ist. Darüber hinaus müssen alle Kunden, die beabsichtigen, Nachrichten auszutauschen, mit demselben Server bzw. mit verschiedenen Servern verbunden sein, die fähig sind bzw. zusammenarbeiten, um die äquivalente Funktionalität von einem Einzelserver zu erreichen. d.h. als ein einzelner logischer Server zu dienen. MOM wird oft bei Systemen verwendet, bei denen eine große Anzahl von Servern als ein logischer Server zu dienen hat. Ein der Gründe für den Einsatz von MOM besteht darin, dass die Anforderung erleichtert wird, um a priori zu definieren, welche Programme Daten miteinander austauschen dürfen. Das bedeutet, dass große Organisationen, die MOM bei den in der ganzen Organisation verbreiteten Computeranwendungen verwenden, bzw. Organisationen, die MOM verwenden, um Dienstleistungen der breiten Öffentlichkeit über Internet zur Verfügung zu stellen, bereit sein müssen, viele Tausende von Programmen, die über einen einzelnen logischen Server kommunizieren, zu berücksichtigen.
  • Diese Erfindung betrifft insbesondere den Fall, in welchem ein MOM-Server als ein Cluster von zahlreichen Computern realisiert wird. Im Kontext dieses Dokuments definieren wir einen Cluster als eine Gruppe von Computern, die zusammenarbeiten, um eine einzelne Dienstleistung mit einer höheren Kapazität und einer höheren Betriebssicherheit bereitzustellen, als diese, die unter Einsatz eines Einzelcomputers erreicht werden können. Um eine hohe Betriebssicherheit beim Ausfall von einem oder mehreren Maschinen im Cluster zu sichern, müssen die durch den Server gehaltenen Nachrichten und deren zugehörigen Zustandinformationen auf vielen Computern redundant gespeichert werden. Das stellt sicher, dass die Daten für den Cluster stets erreichbar sind, wenn ein Computer ausfällt.
  • Die Erfindung betrifft den betriebssicheren Cluster, der eine Haupt- und Backupmethode von der redundanten Speicherung verwendet. In diesem Fall ist ein Computer für eine Menge von Nachrichten, die durch den Nachrichtenservercluster ausgeführt werden, als der Hauptknoten tätig. Der Hauptknoten ist für Speicherung von Nachrichten und deren aktiven Lieferung an Nachrichtenbenutzer verantwortlich. Ein oder mehrere andere Computer sind als Backupknoten für den Hauptknoten tätig. Die Backupknoten sind für Speicherung von einer identischen Kopie der Daten, die im Hauptknoten gespeichert sind, verantwortlich, aber sie werden die aktive Lieferung von gespeicherten Nachrichten an Benutzer nicht vornehmen. Sollte der Hauptknoten ausfallen, so muss/müssen der/die Backupknoten diesen Ausfall detektieren und sicherstellen, dass exakt ein Backupknoten promoviert wird, um die Rolle des Hauptknotens abzuspielen, und beginnt, Nachrichten an Benutzer aktiv zu liefern. Der/die Backupknoten identifiziert/identifizieren den Ausfall des Hauptknotens durch die Tatsache, dass sie nicht länger fähig sind, mit diesem zu kommunizieren. Um das richtige Verhalten des Nachrichtensystems zu gewährleisten, ist es wichtig, dass exakt ein Knoten im Cluster als der Hauptknoten für eine gegebene Menge von Nachrichten jeweils tätig ist. Die exakte Bedeutung des „richtigen Verhaltens" wird unten beschrieben.
  • Zusätzlich zu dem Ausfall von individuellen Computern kann bei solchem Cluster eine andere Art des Ausfalls auftreten, d.h. eine Netzteilung. Der Begriff „Netzteilung" betrifft die Situation, in welcher das Datennetz, das die Computer im Cluster verbindet, in zwei oder mehrere getrennte Unternetze aufgeteilt wird. Jede dieser getrennten Unternetze wird „Partition" genannt. Jede Partition funktioniert richtig, ausgenommen der Tatsache, dass die Computer in einer Partition mit den Computern in anderer Partition nicht kommunizieren können. Das Symptom der Netzteilung ist dasselbe, wie bei dem Knotenausfall, und zwar werden ein oder mehrere Computer für die Kommunikation unerreichbar. Aus diesem Grunde ist generell nicht möglich, dass der Backupknoten zwischen dem Ereignis, in welchem sein korrespondierender Hauptknoten ausfällt, und dem Ereignis, in welchem das Netz aufgeteilt wird und der korrespondierende Hauptknoten weiter funktioniert, aber in einer differenten Partition, unterscheidet.
  • Es entsteht dabei ein fundamentales Dilemma im Bereich der Betriebssicherheit von Servern bei der Haupt- und Backupmethode. Wenn ein Hauptknoten von einem Backupknoten infolge einer Netzteilung getrennt wird, aber der korrespondierende Backupknoten geht davon aus, dass dieser ausfällt, so wird der der Backupknoten zu einem Hauptknoten. Das hat zur Folge, dass der Cluster über zwei Hauptknoten für denselben Nachrichtensatz gleichzeitig verfügt. Sollten beide dieser Hauptknoten im Kontakt mit Nachrichtenbenutzern sein, so wird nicht länger möglich, das richtige Verhalten des Nachrichtenservers zu gewährleisten. Anderseits, wenn der Hauptknoten nicht ausfällt, aber der korrespondierende Backupknoten geht davon aus, dass dieser sich in einer differenten Netzpartition befindet, so wird der Backupknoten nicht zu einem Hauptknoten und die Betriebssicherheit des Nachrichtenserverclusters wird nicht erreicht, d.h. Nachrichten werden dann nicht geliefert.
  • Die Implementierungen von Nachrichtenserverclustern gehen gemäß dem Stand der Technik davon aus, dass der Ausfall der Kommunikation mit einem oder mehreren Computern indiziert, dass diese Computer ausgefallen sind. Das ist verständlich, wenn man bedenkt, dass Computerausfälle häufiger als Netzteilungen auftreten. Im Fall des Haupt-/Backupschemas der Betriebssicherheit führt das zu einem unrichtigen Systemverhaltens während der Netzteilung wegen der Tatsache, dass zwei Computer zu einem Hauptknoten für denselben Nachrichtensatz gleichzeitig werden können. Diese Erfindung ist einzigartig dadurch, dass sie eine Maßnahme bereitstellt, um das richtige Verhalten des Nachrichtenclustersystems, das die Haupt-/Backupmethode der Betriebssicherheit verwendet, sogar während der Netzteilung zu gewährleisten. Sie kann das tun, ohne zu brauchen, zu entdecken, ob der Ausfall der Kommunikation infolge des Computerausfalls bzw. der Netzteilung aufgetreten ist. Diese Erfindung als solche stellt keine neuartige Maßnahme zur Entdeckung der Natur des Ausfalls bereit, sondern stellt eine Maßnahme zur Sicherstellung der hohen Erreichbarkeit im Rahmen der Haupt-/Backupmethode zur Verfügung, wobei das richtige Verhalten gewährleistet wird, ohne zu brauchen, beide Arten des Ausfalls auf differente Weise zu behandeln.
  • Es ist wichtig, das Verhalten zu definieren, das der Nachrichtenservercluster aufweisen muss, um als richtig betrachtet zu werden. Diese Erfindung gewährleistet das richtige Verhalten des Nachrichtensystems gemäß der Version 1.0.2 der Spezifikation der Programmierschnittstelle (API) Java Message Service (JMS), die von Sun Microsystems Inc. veröffentlicht worden ist. Die Definition dieser Schnittstelle ist unter http://java.sun.com/products/jms/docs.html zugänglich. Es gibt folgende Schlüsselaspekte dieses Verhaltens:
    • – Gewährleistete Nachrichtenlieferung: JMS definiert zwei Nachrichtenlieferungsmodi: beständig und unbeständig. Es ist zulässig, unbeständige Nachrichten beim Ereignis des Systemausfalls loszulassen. Ein JMS-verträgliches Nachrichtensystem muss jedoch gewährleisten, dass beständige Nachrichten immer nach dem Systemausfall wiederhergestellt werden können und dass diese eventuell an beabsichtigte Empfänger geliefert werden. Computerprogramme, die ein Nachrichtensystem mit einem beständigen Lieferungsmodus verwenden, um Nachrichten zu senden, sollten keine zusätzlichen Maßnahmen brauchen, um sicherzustellen, dass die Nachricht an einen entsprechenden Empfänger erfolgeich geliefert worden ist. Das Ziel dieser Erfindung ist es, eine gewährleistete, beständige Nachrichtenlieferung bereitzustellen, sogar im Fall der Netzteilung, die die Computer separiert, die den Nachrichtenservercluster bilden. (Die Erfindung verhindert auch den Verlust von unbeständigen Nachrichten beim Ereignis der Netzteilung, sogar wenn solcher Verlust aktuell zulässig ist).
    • – Gewährleistete Einmalige Lieferung: JMS definiert zwei Nachrichtendomänen: Punkt-zu-Punkt und Veröffentlichen/Subskribieren. Punkt-zu-Punkt-Nachrichten müssen exakt einmal exakt an einen infrage kommenden Empfänger geliefert werden. Das entspricht generell solchen Handlungen, wie Deponierung von Geld auf einem Bankkonto, was nicht mehr als nur einmal ausgeführt werden kann. Veröffentlichte/subskribierte Nachrichten müssen exakt einmal an jeden infrage kommenden Subskribenten geliefert werden. Solche Nachrichten enthalten Informationen, welche an eine beliebige Anzahl von Empfängern verbreitet werden dürfen, aber müssen exakt einmal an jeden Empfänger geliefert werden. (Bei beiden Lieferungsmodi hat der Kunde die Möglichkeit, zu spezifizieren, dass doppelte Lieferungen an einen Benutzer zulässig sind). Wenn der Nachrichtenbenutzer die Nachricht empfängt und dann unerwartet die Funktion abbricht, bevor der Empfang der Nachricht bestätigt wird, so wird die Nachricht gem. JMS als ungeliefert betrachtet. Ein weiteres Ziel dieser Erfindung ist es, sowohl richtige Punkt-zu-Punkt-Lieferung von Nachrichten, als auch richtige Lieferung von veröffentlichten/subskribierten Nachrichten trotz der Netzteilung, die die Computer separiert, die den Nachrichtenservercluster bilden, zu gewährleisten.
    • – Ordnungsmäßige Nachrichtenlieferung: Ein Kunde des JMS-Nachrichtensystems darf zahlreiche Hersteller und Benutzer haben. Diese Hersteller und Benutzer werden in eine oder mehrere Sessionen gruppiert, wobei jede Session keinen oder mehrere Hersteller bzw. keinen oder mehrere Benutzer enthält. Alle Nachrichten, die innerhalb einer Session hergestellt werden, müssen an Benutzer in derselben Ordnung geliefert werden, in welcher diese hergestellt worden sind. Die JMS-Spezifikation identifiziert deutlich Ausfallbedingungen, bei welchen es nicht möglich ist, beide gewährleistete Lieferungsarten sicherzustellen und ordnungsmäßig Nachrichten zu liefern, d.h. wenn eine Nachricht an einen Benutzer geliefert wird, und dieser Benutzer ausfällt, bevor der Empfang der Nachricht bestätigt wird, aber nachdem anschließende, in derselben Session hergestellte Nachrichten an andere Benutzer geliefert worden sind. In solchem Fall ist es zulässig, die fragliche Nachricht an andere Benutzer zu liefern, obwohl es nicht ordnungsmäßig ist.
    • – Transaktionen: Wie im vorigen Punkt erwähnt, darf eine beliebige Anzahl von Herstellern und Benutzern von einem Kunden zusammen in eine Session gruppiert werden. Jede Session darf optional als „transaktioniert" spezifiziert werden. Der Kunde muss eine Transaktionssession anweisen, alle Nachrichten, die seit der letzten Abwicklung hergestellt und benutzt worden sind, abzuwickeln, bevor die Lieferung dieser Nachrichten erfolgreich wird. Jegliche Herstellung und Benutzung von Nachrichten, die zwischen nacheinander folgenden Abwicklungen auftritt, muss als eine Einzeleinheit gelungen bzw. misslungen sein. Das bedeutet, dass es trotz irgendeines Systemausfalls, der auftreten kann, zwei mögliche Ergebnisse für den Satz von Nachrichten, die innerhalb einer Transaktionssession zwischen zwei nacheinander folgenden Abwicklungen hergestellt und benutz werden, gibt: 1) die Benutzung von allen empfangenen Nachrichten wird für das Nachrichtensystem zur Zeit der Abwicklung bestätigt und hergestellte Nachrichten werden für Lieferung an Benutzer zur Zeit der Abwicklung zugänglich, oder 2) alle hergestellten Nachrichten werden abgebrochen und alle benutzten Nachrichten werden verweigert, was die Session wirksam zu einem Zustand zurückbringt, der unmittelbar nach der vorigen Abwicklung war. Also, wenn zwei Nachrichten innerhalb derselben Transaktion erstellt werden, d.h. einerseits die Anordnung der Entnahme eines Geldbetrags aus einem Bankkonto und anderseits die Anordnung der Deponierung desselben Betrags in einem anderen Bankkonto, so ist es niemals möglich, dass die Entnahme ohne die korrespondierende Deponierung auftritt. Ein anderes Ziel der Erfindung ist es also, eine richtige Transaktionssemantik trotz der Netzteilung, die auftreten kann, bevor die Transaktion erfolgreich abgewickelt worden ist, bereitzustellen.
  • Zusätzlich zum Obigen beabsichtigen wir, dass diese Erfindung einen zusätzlichen Aspekt des Verhaltens bereitstellt, welcher von JMS nicht spezifiziert worden ist, aber für Erfüllung der grundsätzlichen Bestimmung eines Nachsichtensystems kritisch ist:
    • – Das Nachrichtensystem ist ganze Zeit zugänglich, um Nachrichten von Nachrichtenherstellern zu akzeptieren: JMS stellt deutlich keine Anforderungen hinsichtlich der Zugänglichkeit des Nachrichtensystems fest. Ein serverbasiertes Nachrichtensystem ist jedoch beabsichtigt, um bei Computerprogrammen den Bedarf für Implementierung der Nachrichtenspeicherung und -absendung zu verringern. Das Nachrichtensystem kann diese Beabsichtigung nicht erfüllen, ohne Zugänglichkeit zu gewährleisten. Die permanente Zugänglichkeit für Akzeptierung von Nachrichten von Nachrichtenherstellern ist in dieser Hinsicht mehr kritisch als die Zugänglichkeit für Verteilung von Nachrichten an Benutzer. Die JMS-Spezifikation sowie Nachrichtensysteme im Allgemeinen gewährleisten keine minimale Zeit der Lieferung von einem Hersteller an einen Benutzer. Das ist außerhalb der Kontrolle des Nachrichtensystems, weil man nicht voraussetzen kann, dass Benutzer ganze Zeit erreichbar sind, um Nachrichten zu empfangen. Aus diesem Grunde müssen sich Nachrichtenbenutzer dadurch kennzeichnen, dass sie hinsichtlich Verspätungen bei Nachrichtenlieferungen geduldig sind. Anderseits ist es zu beachten, dass ein einfacher Nachrichtenhersteller, der interaktiv Auftragsinformationen von menschlichen Benutzern versammelt, diese als eine Nachricht verpackt, an das Nachrichtensystem absendet, die Auftragsabwicklung an den Benutzer bestätigt, nur nach Erledigung dieser Tätigkeiten bereit ist, einen anderen Auftrag auszuführen. Wenn das Nachrichtensystem nicht bereit ist, die Verantwortlichkeit für die Nachricht während dieses Zyklus zu übernehmen, dann entweder: 1) muss der Benutzer eine unbestimmte Zeitmenge warten, bis das Nachrichtensystem zugänglich ist, bevor er eine Bestätigung empfängt, dass der Auftrag abgewickelt worden ist, oder 2) muss der Nachrichtenhersteller eine betriebssichere, wiederherstellbare Speicherung der Nachricht bereitstellen, bis das Nachrichtensystem zugänglich ist. Beide dieser Optionen vernichten die Nutzungsbestimmung eines Nachrichtensystems bei solchem Szenario. Deswegen setzen wir voraus, dass die Fähigkeit, hergestellte Nachrichten jederzeit zu akzeptieren, ein Kriterium für die Zugänglichkeit des Nachrichtenservers bildet. Ein anderes Ziel der Erfindung ist es also, sicherzustellen, dass ein Nachrichtenservercluster immer zugänglich ist, um Nachrichten von Nachrichtenherstellern zu akzeptieren und eine richtige Lieferung dieser Nachrichten zu gewährleisten, sogar wenn der Cluster der Netzteilung unterliegt.
  • Diese Erfindung stellt eine Beständigkeit gegen Netzteilung, insbesondere bei einem Nachrichtenservercluster gemäß der Patentanmeldung 09/750,009 „Scaleable Message System", bereit. Für Details über dieses Nachrichtensystem verweisen wir auf die Veröffentlichung dieser Anmeldung, wobei die Anmeldung hier als Referenzmaterial berücksichtigt wird. Es wird hier nur eine kurze Beschreibung präsentiert. Das skalierbare Nachrichtensystem ist in 1 dargestellt. Das skalierbare Nachrichtensystem besteht aus zwei oder mehreren logischen Knoten. Jeder Knoten kann auf einem getrennten Computer betrieben werden bzw. zahlreiche Knoten können auf demselben Computer betrieben werden. Es gibt zwei Knotenarten: Kundenmanager (Client Manager – CM) und Nachrichtenmanager (Massage Manager – MM). Nachrichtenmanagerknoten sind für Speicherung und Verteilung von Nachrichten verantwortlich. Sie sind nicht direkt für Kunden zugänglich. Kunden müssen sich mit Kundenmanagerknoten verbinden, und die Kundenmanagerknoten leiten Kundenanfragen an die Nachrichtenmanagerknoten über einen betriebssicheren, atomaren Multicast-Nachrichtenbus weiter. Der Nachrichtenbus ermöglicht, Daten aus einem Knoten an einzelne andere Knoten gleichzeitig zu übersenden, ohne mehr Netzressourcen zu benutzen, als bei Übersendung von denselben Daten nur an eine Maschine. Individuelle Kundenmanagerknoten enthalten keine Zustandinformationen, was für die kontinuierliche Funktion des Systems kritisch ist, sodass der Ausfall von einem oder mehreren Kundenmanagerknoten toleriert werden kann, ohne zu brauchen, einen Backupknoten einzusetzen. Wenn ein Kundenmanagerknoten ausfällt, verbinden sich die Kunden, die mit ihm verbunden waren, automatisch mit einem anderen Kundenmanagerknoten und setzen die normale Operation fort. 1 zeigt einen Cluster von zusammen verbundenen Kundenmanagern und Nachrichtenmanagern.
  • Nachrichtenmanagerknoten enthalten Zustandinformationen, die für die kontinuierliche Funktion des Systems kritisch sind. Aus diesem Grunde müssen ihre Zustandinformationen auf zahlreichen Knoten redundant gespeichert werden. Es gibt zwei Nachrichtenmanagerknotenarten: Haupt und Backup. Jederzeit ist jeder der Nachrichtenmanager-Hauptknoten für Speicherung und Verteilung von einem Nachrichten-Untersatz, der von dem Nachrichtensystem transferiert wird, verantwortlich. Zusammen sind alle Nachrichtenmanager-Hauptknoten für den kompletten Nachrichtensatz, der von dem Nachrichtensystem transferiert wird, jederzeit verantwortlich. Für jeden Nachrichtenmanager-Hauptknoten gibt es eine beliebige Anzahl von Nachrichtenmanager-Backupknoten. Jeder Nachrichtenmanager-Backupknoten ist für Aufbewahrung einer exakten Kopie von dem Zustand seiner korrespondierenden Nachrichtenmanager-Hauptknoten verantwortlich und muss bereit sein, die Rolle des Nachrichten-Hauptmanagers zu übernehmen, wenn der originelle Nachrichten-Hauptmanager ausfällt. Jeder Nachrichtenmanager-Hauptknoten wirkt eng mit seinem korrespondierenden Nachrichtenmanager-Backupknoten zusammen, aber weist eine geringe Interaktion mit anderen Nachrichtenmanagerknoten auf. Aus diesem Grunde wird jede Gruppe von einem Nachrichtenmanager-Hauptknoten und seinen Nachrichtenmanager-Backupknoten als Untercluster bezeichnet.
  • Der oben beschriebene Nachrichtenservercluster besteht aus zwei unterschiedlichen Knotenarten und es gibt ein paar Vorteile, um diese zwei Knoten auf zwei physisch unterschiedlichen Computern unterzubringen. Es ist wichtig, zu beachten, dass diese Art des Nachrichtenserverclusters mittels einer einzelnen Art des Knotens durch Kombinierung der Funktionalität des Kundenmanagers mit dem Nachrichtenmanager in eine einzelne Knotenart ausgeführt werden kann. Die Beschreibung dieser Erfindung wird jedoch durch Verwendung des Modells, in welchem diese Knotenarten physisch getrennt sind, erleichtert und deswegen wird dieses Modell in dem ganzen Dokument genutzt.
  • Die Erfindung beruht auf dem Konzept von einem synchronischen Netzsichtfeld. Das Sichtfeld ist eine Liste von Maschinen, mit welchen ein gegebener Knoten über das Datennetz zum bestimmten Zeitpunkt kommunizieren kann. Diese Erfindung setzt voraus, dass alle Knoten, die sich im Sichtfeld von einem gegebenen Knoten befinden, über dasselbe Sichtfeld verfügen; d.h.: wenn A im Sichtfeld von B, aber C nicht im Sichtfeld von B ist, dann ist C nicht im Sichtfeld von A. Also, wenn keine Netzteilung vorhanden ist, verfügen alle Knoten über alle anderen Knoten in ihrem Sichtfeld, und wenn das Netz aufgeteilt ist, verfügen alle der Knoten in einer Partition über dasselbe Sichtfeld, aber das Sichtfeld enthält keinen Knoten, der sich in einer anderen Partition befindet. Bei der bevorzugten Ausführungsform wird die Verantwortlichkeit für Detektierung des Sichtfelds und Anmeldung von Änderungen im Sichtfeld an den Nachrichtenbus delegiert, der die Multicastkommunikation innerhalb des Clusters bereitstellt. Die bevorzugte Ausführungsform benutzt dazu das Produkt Ibus//MessageBus der Fa. Softwired AG (www.softwired-inc.com), weil es sowohl eine betriebssichere, atomare, ordnungsmäßige Multicastkommunikation, als auch Sichtfeldmanagement zur Verfügung stellt.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Diese Erfindung stellt eine Maßnahme für einen Nachrichtenservercluster bereit, um Nachrichten von Nachrichten herstellenden Kunden zu akzeptieren und diese Nachrichten an Nachrichten benutzende Kunden zu verteilen, unter Berücksichtigung von Bedingungen der aktuellen JMS-Spezifikationsversion, wie die JMS-Spezifikationsversion 1.0.2 und folgende Versionen, und stellt sicher, dass der Cluster für zu akzeptierende Nachrichten hoch zugänglich ist, sogar wenn Computer im Cluster ausfallen oder das Datennetz, das die Computer verbindet, in einzelne Netzpartitionen aufgeteilt wird.
  • Diese Erfindung ist z.B. anwendbar für die Nachrichtenserverclusterart, die in der US-amerikanischen Patentanmeldung 09/750,009, „Scaleable Message System", spezifiziert und vorher in der Hintergrundsektion beschrieben worden ist. Die US-amerikanische Patentanmeldung 09/750,009 beschreibt die neue Art des Nachrichtenserverclusters ausführlicher und wird hier als Referenzmaterial berücksichtigt. Diese Art des Nachrichtenserverclusters wird als hoch zugänglich bezeichnet, weil alle Nachrichten und zugehörige Zustandinformationen, die der Server speichern muss, um den richtigen Betrieb sicherzustellen, auf vielen differenten Computern redundant gespeichert werden können. Das ermöglicht dem Nachrichtenservercluster, normale Operationen ohne Unterbrechungen sowie ohne Nachrichtenverlust fortzusetzen, falls ein oder mehrere Computer im Cluster unerwartet ausfallen.
  • Die Erfindung ist jedoch auch nutzbar für Nachrichtenclustersysteme mit einer Architektur, die von der Knotenarchitektur gem. der oben erwähnten US-amerikanischen Patentanmeldung 09/750,009 abweicht. Eine einzige Voraussetzung für den Cluster besteht darin, dass eine Vielzahl von Nachrichtenmanagern vorhanden ist. Die Nachrichtenmanager können grundsätzlich auch als Kundenmanager gleichzeitig funktionieren.
  • Bei Punkt-zu-Punkt-Nachrichten setzen die Anforderungen der Spezifikation voraus, dass jede beständige Nachricht exakt an einen der infrage kommenden Empfänger geliefert wird. Bei veröffentlichten/subskribierten Nachrichten setzen die Anforderungen der Spezifikation voraus, dass jede Nachricht exakt einmal an jeden infrage kommenden Subskribenten geliefert wird. Diese Anforderungen implizieren Handlungen, die zu zeitraubend sind, um zwischen Knoten auf vielen physischen Maschinen koordiniert zu werden. Diese Handlungen inkludieren die Entscheidung, welcher infrage kommende Empfänger eine Nachricht in der Punkt-zu-Punkt-Domäne empfangen soll, sowie wenn Nachrichten an alle Subskribenten geliefert worden sind und in der Veröffentlichungs-/Subskribierungsdomäne sicher gelöscht werden dürfen. Um diese Handlungen auf eine effiziente Weise zur gegebenen Zeit auszuführen, sollte nur ein Nachrichtenmanagerknoten im Cluster für die Lieferung der gegebenen Nachricht verantwortlich sein. Dieser wird als ein Nachrichtenmanager-Hauptknoten bezeichnet. Alle anderen Nachrichtenmanagerknoten, die dieselbe Nachricht speichern, sind Backupnachrichtenmanager und spielen eine passive Rolle ab. Das richtige Systemverhalten wird sichergestellt, wenn es nur ein Nachrichten-Hauptmanager für einen gegebenen Satz von Nachrichten jeweils besteht. Also, ein Backupnachrichtenmanager sollte zu einem Nachrichten-Hauptmanager nur dann werden, wenn es festgestellt worden ist, dass es kein Nachrichten-Hauptmanager aktuell besteht.
  • Das Haupt-/Backupschema kann nicht sicherstellen, dass es nur einen einzelnen Nachrichten-Hauptmanager gibt, wenn das Netz, das Computer verbindet, aufgeteilt wird. Daraus ergibt sich die Tatsache, dass die Computer in den Partitionen nicht wissen können, ob die Computer, mit welchen sie den Kontakt verloren haben, aufgehört haben zu operieren bzw. in einer anderen Netzpartition Operierung fortsetzen. Diese Erfindung stellt ein Schema bereit, in welchem jede Netzpartition einen Nachrichten-Hauptmanager für denselben Satz von Nachrichten enthalten darf, ohne die Anforderungen der JMS-Spezifikation zu verletzen sowie ohne Übersendung von neuen Nachrichten an den Nachrichtenservercluster zu verhindern.
  • Um jeder Netzpartition zu ermöglichen, einen Nachrichten-Hauptmanager zu haben, der für denselben Satz von Punkt-zu-Punkt-Nachrichten verantwortlich ist, wie Nachrichten-Hauptmanager in anderen Partitionen, definieren wir zwei Arten von Nachrichten-Hauptmanagern für die Punkt-zu-Punkt-Domäne: normal und beschränkt. Ein normaler Nachrichten-Hauptmanager ist berechtigt, den vollen Bereich von Funktionen auszuführen, die mit einem Nachrichten-Hauptmanager für Punkt-zu-Punkt-Nachrichten verbunden sind. Ein beschränkter Nachrichten-Hauptmanager ist nicht berechtigt, Punkt-zu-Punkt-Nachrichten zu erledigen, die gesendet worden waren, bevor der aktuelle Netzausfall entstanden ist. Es ist genügend, sicherzustellen, dass es nicht mehr als einen normalen (unbeschränkten) Nachrichten-Hauptmanager in einem Cluster gibt, um eine richtige JMS-Semantik in der Punkt-zu-Punkt-Domäne zu gewährleisten.
  • Bei der Veröffentlichungs-/Subskribierungsdomäne ist es nicht erforderlich, die Lieferung von Nachrichten durch Nachrichten-Hauptmanager zu beschränken. Es ist jedoch notwendig, sicherzustellen, dass veröffentlichte/subskribierte Nachrichten nicht aus den Nachrichtenmanagern gelöscht werden (ausgenommen wegen Nachrichtenverfallfrist), bis die Netzteilung bzw. den Computerausfall beseitigt wird, um sicherzustellen, dass eventuelle benutzende Kunden in anderen Partitionen alle für sie bestimmten Nachrichten ultimativ empfangen können. Bei diesem Operationsmodus muss der Nachrichten-Hauptmanager alle veröffentlichte/subskribierten Nachrichten und deren zugehörigen Lieferungszustand aufbewahren und wird als einen aufbewahrenden Nachrichten-Hauptmanager bezeichnet. Es ist zu beachten, dass immer, wenn eine Teilung Nachrichtenmanager aus demselben Untercluster separiert, alle Nachrichten-Hauptmanager aus diesem Untercluster beginnen, veröffentlichte/subskribierte Nachrichten aufzubewahren, während höchstens ein normaler Nachrichten-Hauptmanager für Punkt-zu-Punkt-Nachrichten vorhanden sein kann.
  • Nachdem die Netzteilung beseitigt ist, müssen zahlreiche Nachrichten-Hauptmanager, die vorher in unterschiedlichen Partitionen separiert waren, ihre Zustände synchronisieren, sodass alle aktualisiert sind, um die Aktivitäten, die in anderen Partitionen ausgeführt worden waren, zu widerspiegeln. Dann müssen alle Nachrichten-Hauptmanager, ausgenommen eines, zur Rolle des Backupnachrichtenmanagers zurückkehren und der einzelne, aufbewahrende Nachrichten-Hauptmanager übernimmt die volle Verantwortlichkeit für Nachrichten von diesem Untercluster.
  • Um zuverlässig zu bestimmen, wenn ein Ausfall aufgetreten ist und über welches Funktionalitätsniveau der Nachrichten-Hauptmanager in einer partikulären Partition verfügen kann (normal, aufbewahrend bzw. aufbewahrend beschränkt), müssen folgende Informationen für alle Knoten zugänglich sein:
    • – Clusterkonfiguration: Das ist die Konfiguration des Clusters, die von dem Systemverwalter definiert worden ist. Sie enthält die komplette Beschreibung, welche Knoten vorhanden sein können, welcher Art sie sind (Kundenmanager bzw. Nachrichtenmanager), wie diese in Untercluster gruppiert sind sowie auf welchen Computer sie betrieben werden sollten. Die Konfiguration ist gewöhnlich ganze Zeit dieselbe für alle Knoten.
    • – Netzsichtfeld (Sichtfeld): Das ist eine Liste von Computern, die über den Multicast-Nachrichtenbus erreichbar sind. Wenn kein Ausfall vorhanden ist, besitzen alle Computer dasselbe Sichtfeld und dieses sollte mit der Clusterkonfiguration übereinstimmend sein. Wenn ein Ausfall aufgetreten ist, dann ist das Sichtfeld mit der Clusterkonfiguration nicht übereinstimmend. Wenn der Ausfall durch die Netzteilung verursacht worden ist, dann besitzen die Computer innerhalb jeder Partition dasselbe Sichtfeld, aber das Sichtfeld ist natürlich unterschiedlich in jeder Partition.
  • Die Erfindung verwendet ein diskretes Zustandmodell, um zu bestimmen, ob der Nachrichten-Hauptmanager in einem partikulären Untercluster aufbewahrend und/oder beschränkt sein sollte. Dieser Partitionszustand hat vier mögliche Werte, welche mit den Buchstaben A, B, C und D kennzeichnet werden. Jederzeit, wenn eine Änderung des Sichtfelds auftritt, wird der Zustand des Knotens auf Basis von der Anzahl und dem vorherigen Partitionszustand von Kundenmanagern und Nachrichtenmanagern hinsichtlich sowohl des neuen Netzsichtfelds, als auch der beabsichtigen Clusterkonfiguration neu evaluiert. Zustand A repräsentiert den normalen Betrieb mit keinen Ausfällen bzw. nur mit Ausfällen von Kundenmanagern. Im Zustand B und C ist der Nachrichten-Hauptmanager „aufbewahrend", aber nicht „beschränkt". Im Zustand D ist der Nachrichten-Hauptmanager „aufbewahrend" und „beschränkt". Das Zustandmodell ermöglicht sowohl einen hohen Grad des kontinuierlichen Betriebs, als auch gewährleistet die JMS-Konformität, sogar wenn zahlreiche, sukzessive, komplexe Netzteilungen auftreten.
  • Bei veröffentlichten/subskribierten Nachrichten wird der aufbewahrende Nachrichten-Hauptmanager fast wie ein normaler Nachrichten-Hauptmanager funktionieren. Der einzelne Unterschied beruht darauf, dass der aufbewahrende Nachrichten-Hauptmanager nicht wissen kann, ob es Subskribenten in anderen Partitionen gibt, die noch eine gegebene Nachricht nicht empfangen haben, sodass dieser Nachrichten nicht löschen sollte, bis der Ausfall beseitigt wird und alle Nachrichten-Hauptmanager für diesen Untercluster ihren Zustand abstimmen können, ausgenommen im Fall, dass Nachrichten verfallen, bevor der Ausfall beseitigt wird.
  • Bei Punkt-zu-Punkt-Nachrichten wird ein beschränkter Nachrichten-Hauptmanager bei auszuführenden Handlungen im Vergleich zu einem unbeschränkten Nachrichten-Hauptmanager mehr limitiert. Ein beschränkter Nachrichten-Hauptmanager darf einkommende Nachrichten jederzeit akzeptieren. Er darf aber nur Nachrichten verteilen, die nach der letzten Änderung des Sichtfelds empfangen worden sind, weil es dann gewährleistet ist, dass diese Nachrichten in keiner anderen Partition vorhanden sind. Da alle Nachrichten, die durch eine einzelne Session hergestellt worden sind, ordnungsgemäß geliefert werden müssen, ist es möglich, dass Nachrichten, die durch eine Destination empfangen worden sind, im aktuellen Sichtfeld nach den Nachrichten aus derselben Kundensession, die während des vorigen Sichtfelds empfangen worden waren, rangiert werden und für Verteilung nicht zugänglich sind, bis die Teilung beseitigt wird.
  • Die Erfindung setzt nicht voraus, dass Änderungsereignisse des Sichtfelds unmittelbar nach der Auftretung des Ausfalls verwirklicht werden. Es gibt gewöhnlich eine Zeitverzögerung, bevor der Sichtfeldsmanager (der Multicast-Nachrichtenbus im Fall der bevorzugten Implementierung) schließlich bestimmen kann, dass ein Ausfall aufgetreten ist, ohne exzessive, falsche Alarme zu riskieren. Es ist möglich, dass nach der Auftretung der Netzteilung jede Partition den Ausfall zu einer unterschiedlichen Zeit detektiert. Daraus können sich gefährliche Szenarios ergeben, bei welchen eine Partition einen Backupnachrichtenmanager als einen unbeschränkten Nachrichten-Hauptmanager bereitstellt, bevor der Nachrichten-Hauptmanager in einer anderen Partition detektiert, dass er den beschränkten Betrieb anordnen muss.
  • Um die Lieferung von doppelten Nachrichten während des Intervalls zwischen der Auftretung eines Ausfalls und der Änderung des Sichtfelds zu verhindern, erfolgt eine extra Prüfung durch den Kundenmanager während der Absendung. Jederzeit wird eine Nachricht von einem Nachrichtenmanager an die Kundenmanager für Absendung gesendet. Jeder Kundenmanager, der die Nachricht empfängt, sendet an alle anderen Kundenmanager eine Bestätigung, die bestätigt, dass er die Nachricht gesehen hat. Der Kundenmanager, der aktuell für Weiterleitung der Nachricht an einen Kundenbenutzer verantwortlich ist, wird die Nachricht halten, bis er Bestätigungen von einer Mehrheit der anderen Kundenmanager in demselben Netzsichtfeld empfängt. Wenn ein Ausfall aufgetreten ist, der potentiell zur Lieferung von doppelten Nachrichten führen kann, bevor die Änderung des korrespondierenden Sichtfelds festgestellt wird, kann keine Mehrheit von Bestätigungen empfangen werden und die Nachricht wird durch den Kundenmanager zurückgewiesen.
  • Generell beruht eine wichtige Idee dieser Erfindung darauf, dass im Fall einer Netzteilung jeder Knoten Partitionszustandinformationen evaluiert. Es besteht eine wichtige Unterscheidung zwischen zwei operationellen Zuständen: „beschränkt" und „unbeschränkt". Das hat sicherzustellen, dass zwei Nachrichtenmanager dieselbe Punkt-zu-Punkt-Nachricht nicht absenden können. Also, ein Kriterium ist entstanden, um sicherzustellen, dass bei zwei Nachrichtenmanagern, die sich gegenseitig nicht „sehen", z.B. nicht fähig sind, wegen der fehlenden (Hardware- bzw. Software-) Netzverbindung zu kommunizieren, und für Absendung von denselben Punkt-zu-Punkt-Nachrichten verantwortlich sind, nur ein Nachrichtenmanager unbeschränkt sein kann. Nur Nachrichtenmanager mit dem unbeschränkten Zustand können Nachrichten absenden, die geschaffen worden waren, bevor die Netzteilung aufgetreten ist.
  • Es gibt unterschiedliche Möglichkeiten, um ein Kriterium zur Bestimmung festzustellen, ob ein Nachrichtenmanager in eine Kategorie „beschränkt" oder „unbeschränkt", d.h. in den beschränkten oder unbeschränkten operationellen Zustand, eingeschlossen werden sollte. Gemäß dem Vierzustandmodell, das oben erwähnt ist und im Folgenden ausführlicher dargestellt wird, beruht das Kriterium darauf, dass der Nachrichtenmanager den Partitionszustand A, B oder C haben sollte, um den unbeschränkten Zustand zu haben. Ob einem Server der Partitionszustand A, B oder C zugeschrieben wird, ist sowohl von der Anzahl und Art von Knoten, die für die Kommunikation zugänglich sind, als auch von der Geschichte, d.h. davon, welcher Partitionszustand vorhanden war, bevor das letzte Sichtfeld geändert worden ist, abhängig.
  • Das Vierzustandmodell oder seine vereinfachte bzw. sogar mehr komplizierte Version kann sowohl bei Architekturen mit zwei unterschiedlichen Knotenarten, d.h. Nachrichtenmanagern und Kundenmanagern, gemäß der oben erwähnten US-amerikanischen Patentanmeldung, als auch z.B. bei konventionellen Architekturen, wo jeder Server sowohl als Kundenmanager, als auch als Nachrichtenmanager agiert, eingesetzt werden. Ein weiteres mögliches Kriterium ist es, z.B. einen Serverknoten als einen partikulären (Alpha- bzw. Entscheidungs-)Server zu designieren. Alle Server, die in der Partition des Alphaservers enthalten sind, sind „unbeschränkt"; alle anderen Server sind dagegen „beschränkt". Weitere Kriterien können Informationen über partikuläre Kundenverbindungen etc. benutzen. Es ist jedoch wichtig, dass immer nur eine Partition unbeschränkt sein darf.
  • Eine zweite, wichtige Unterscheidung ist zwischen zwei operationellen Zuständen zu machen: aufbewahrend und nicht aufbewahrend. Gemäß dem Vierzustandmodell hat ein Nachrichtenmanager den „nicht aufbewahrenden" operationellen Zustand, wenn er den Partitionszustand A hat, sonst hat er den „aufbewahrenden" operationellen Zustand. Gemäß diesem Modell wird der Zustand A erreicht, wenn alle Nachrichtenmanager innerhalb des Unterclusters zugänglich sind und wenn wenigstens ein Kundenmanager zugänglich ist.
  • Bei einer speziellen Ausführungsform können eventuell weitere Partitionszuständen in Abhängigkeit von der Anzahl von zugänglichen Nachrichtenserverknoten entstehen. Diese Ausführungsform wird auch unter Bezugnahme von dem erwähnten Vierzustandmodell erklärt.
  • Diese Erfindung wird durch den Wunsch motiviert, eine Methode zu erhalten, die die JMS-Semantik während einer Netzteilung bzw. eines Knotenausfalls gewährleistet, in Betracht dessen, dass diese zwei Ereignisse durch einen Server des Clusters nicht unterschieden werden können. Die Erfindung eignet sich jedoch auch dafür, um den richtigen Betrieb zu gewährleisten, falls ein Netz eine differente Middleware, insbesondere eine nachrichtenorientierte Middleware, einsetzt. Der Fachmann erkennt sofort, dass das Konzept dieser Erfindung nicht auf einer spezifischen Computersoftware bzw. Computersprache basiert, aber eher sich auf Netzarchitekturen als solche bezieht.
  • KURZBESCHREIBUNG VON ABBILDUNGEN
  • 1 zeigt ein Nachrichtenübertragungsclustersystem.
  • 2 schildert ein Partitionszustand-Übergangsdiagramm, bestehend aus Knoten und unidirektionalen Pfeilen, die Knoten zusammen verbinden.
  • 3 zeigt ein Nachrichtenübertragungsclustersystem nach der Auftretung einer Netzteilung.
  • 4 schildert die Ausführung einer einfachen Transaktion in einem Nachrichtenübertragungsclustersystem.
  • 5 schildert die Ausführung einer Transaktion im Zeitablauf.
  • BESCHREIBUNG VON BEVORZUGTEN AUSFÜHRUNGSFORMEN
  • Im Folgenden sind bevorzugte Ausführungsformen der Erfindung unter Bezugnahme von Abbildungen beschrieben.
  • Der in 1 dargestellte Cluster enthält zwei Untercluster 1 und 2, die jeweils drei Nachrichtenmanager MM (Message Managers) und fünf Kundenmanager CM (Client Managers) enthalten. Jeder der fünf Kundenmanager verfügt über eine Anzahl von verbundenen Kunden. In jedem der Untercluster gibt es einen Nachrichten-Hauptmanager und zwei Backupnachrichtenmanager. Die Abbildung zeigt, wie die Knoten (Kundenmanager und Nachrichtenmanager) auf einem clusterweiten Nachrichtenbus verbunden sind.
  • Gemäß dem Modell, das in der 2 dargestellt ist, werden vier unterschiedliche, durch Knoten repräsentierte Zustände A, B, C und D vorausgesetzt. Jeder Knoten repräsentiert einen Partitionszustand und dieser Partitionszustand wird für jeden Untercluster in jeder Netzpartition unabhängig bestimmt. Unidirektionale Pfeile repräsentieren ein Ereignis, das sich aus dem Übergang von einem Partitionszustand zu einem anderem ergibt. Übergänge treten als ein Ergebnis von Änderungen des Sichtfelds auf. Im Folgenden wird jedes der Ereignisse, die zu einem Übergang von einem Partitionszustand zu einem anderem (oder zu demselben) Zustand führen, beschrieben:
    • – Spitze aa – Alle Nachrichtenmanager innerhalb desselben Unterclusters bleiben zugänglich sowie ein oder mehrere Kundenmanager sind für diese Nachrichtenmanager zugänglich.
    • – Spitze ab – Alle Nachrichtenmanager innerhalb des Unterclusters, ausgenommen eines, werden unzugänglich und eine Mehrheit von Kundenmanagern ist für den verbleibenden Nachrichtenmanager zugänglich.
    • – Spitze ba – Alle anderen Nachrichtenmanager innerhalb desselben Unterclusters sind zugänglich geworden sowie ein oder mehrere Kundenmanager sind für diese Nachrichtenmanager zugänglich.
    • – Spitze bd – Ein oder mehrere, aber nicht alle Nachrichtenmanager aus demselben Untercluster, die aktuell den Partitionszustand D haben, sind zusammen mit dem einzelnen Nachrichtenmanager aus diesem Untercluster (welcher vorher den Partitionszustand B hatte), der bereits in dieser Partition war, in dieser Partition zugänglich geworden sowie ein oder mehrere Kundenmanager sind für diese Nachrichtenmanager zugänglich.
    • – Spitze bb – Der einzelne Nachrichtenmanager aus diesem Untercluster (welcher vorher den Partitionszustand D hatte), der bereits in dieser Partition war, bleibt der einzige Nachrichtenmanager aus diesem Untercluster, der in dieser Partition zugänglich ist, sowie ein oder mehrere Kundenmanager sind für diesen Nachrichtenmanager zugänglich.
    • – Spitze ac – Zwei oder mehrere, aber nicht alle Nachrichtenmanager aus diesem Untercluster bleiben zugänglich sowie eine Mehrheit von Kundenmanagern ist für diese Nachrichtenmanager zugänglich.
    • – Spitze ca – Alle anderen Nachrichtenmanager innerhalb desselben Unterclusters sind zugänglich geworden sowie ein oder mehrere Kundenmanager sind für diese Nachrichtenmanager zugänglich.
    • – Spitze cb – Alle Nachrichtenmanager innerhalb des Unterclusters, ausgenommen eines, sind unzugänglich geworden sowie eine Mehrheit von Kundenmanagern ist für den verbleibenden Nachrichtenmanager zugänglich.
    • – Spitze cc – Zwei oder mehrere Nachrichtenmanager aus diesem Untercluster bleiben zugänglich, eine Mehrheit von Kundenmanagern bleibt für diese Nachrichtenmanager zugänglich sowie wenigstens ein Nachrichtenmanager aus diesem Untercluster bleibt unzugänglich.
    • – Spitze cd – Eine Mehrheit von Kundenmanagern ist unzugänglich geworden sowie wenigstens ein Nachrichtenmanager aus diesem Untercluster bleibt unzugänglich oder andere, aber nicht alle Nachrichtenmanager aus demselben Untercluster, die aktuell den Partitionszustand D haben, sind zugänglich geworden.
    • – Spitze ad – Eine Mehrheit von Kundenmanagern ist unzugänglich geworden sowie wenigstens ein Nachrichtenmanager aus diesem Untercluster ist unzugänglich geworden.
    • – Spitze da – Alle Nachrichtenmanager sind innerhalb des Unterclusters zugänglich sowie ein oder mehrere Kundenmanager sind für diese Nachrichtenmanager zugänglich.
    • – Spitze dd – Wenigstens ein Nachrichtenmanager aus diesem Untercluster bleibt unzugänglich.
  • Wie in der Abbildung dargestellt, kann eine Partition, die Nachrichtenmanager und Kundenmanager enthält, die den Partitionszustand A, B bzw. C haben, über einen Nachrichten-Hauptmanager verfügen, der im „unbeschränkten" Modus in Bezug auf Punkt-zu-Punkt-Nachrichten operiert und normal Punkt-zu-Punkt-Nachrichten absenden darf. Anderseits operiert ein Nachrichten-Hauptmanager beim Partitionszustand D in Bezug auf Punkt-zu-Punkt-Nachrichten im „beschränkten" Modus. Hinsichtlich veröffentlichter/subskribierter Nachrichten operiert der Nachrichten-Hauptmanager im „nicht aufbewahrenden" Modus und kann beim Partitionszustand A normal betrieben werden. Beim Partitionszustand B, C und D operiert der Nachrichten-Hauptmanager im „aufbewahrenden" Modus und darf Nachrichten nicht löschen, bevor diese verfallen.
  • Bei jeder Netzteilung wird eine Partition in den Partitionszustand B oder C und alle anderen Partitionen in den Partitionszustand D gebracht. Um aus dem Partitionszustand D zurückgezogen zu werden, müssen alle Nachrichtenmanager innerhalb derselben Partition zugänglich sen. Also, nur eine Partition kann den Partitionszustand B oder C jederzeit haben.
  • Gemäß einer weiteren, vereinfachten Ausführungsform der Erfindung darf ein Dreizustandmodell, das Zustände A, C und D kombiniert, eingesetzt werden. Analogisch zu dem obigen Modell wird dem Nachrichtenmanager ein „unbeschränkter" operationeller Zustand zugeschrieben, wenn dieser den Partitionszustand A oder C hat, und ein „beschränkter" operationeller Zustand, wenn dieser den Partitionszustand D hat. Dem Nachrichtenmanager wird auch ein „nicht aufbewahrender" operationeller Zustand zugeschrieben, wenn dieser den Partitionszustand A hat, und ein „aufbewahrender" operationeller Zustand in sonstigen Fällen. Gemäß diesem vereinfachten Modell entscheidet nur die Anzahl und Art von Knoten, die für die Kommunikation zugänglich sind, welcher Partitionszustand einem Server zugeschrieben wird, und nicht seine „Geschichte":
    • – Zustand A: alle Nachrichtenmanager innerhalb des Unterclusters sind zugänglich.
    • – Zustand C: nicht alle Nachrichtenmanager innerhalb des Unterclusters sind zugänglich, eine Mehrheit von Kundenmanagern ist zugänglich.
    • – Zustand D: nicht alle Nachrichtenmanager innerhalb des Unterclusters sind zugänglich sowie nicht eine Mehrheit von Kundenmanagern ist zugänglich.
  • Auch dieses vereinfachte Modell stellt die JMS-Semantik sicher. Das Vierzustandmodell enthält jedoch im Vergleich dazu mehr Situationen (siehe Spitze bb), wo dem Server ein „unbeschränkter" operationeller Zustand zugeschrieben wird.
  • Das ultimative Ziel des Vierzustandmodells oder dessen mehr komplizierten bzw. einfacheren Versionen ist die Fähigkeit, den Fall von zahlreichen, sukzessiven Netzteilungen zu behandeln. Das kann der Fall sein, wenn ein unerfahrener Techniker unrichtig versucht, die originelle Partition zu reparieren, oder wenn die Firmware in einem Switch verrückt wird und beginnt, Computer wahllos zu segregieren. Das Zustandmodell stellt einen sehr hohen Grad der Zuverlässigkeit bereit und verhütet, dass das System nicht durch einen totalen Ausfall gefährdet wird, nachdem die erste Teilung aufgetreten ist.
  • Analogisch zu dem in der 1 dargestellten Cluster enthält der Cluster aus der 3 zwei Untercluster 1 und 2, die jeweils drei Nachrichtenmanager und fünf Kundenmanager enthalten. Jeder der fünf Kundenmanager verfügt über eine Anzahl von verbundenen Kunden.
  • Die Abbildung zeigt, wie infolge einer Netzteilung die Untercluster aufgeteilt sind, sodass der Untercluster 1 durch die Teilung nicht beeinträchtigt ist, ausgenommen der Tatsache, dass zwei Kundenmanager unzugänglich sind. Die Knoten im Untercluster 1 haben stets den Partitionszustand A. Anderseits ist der Untercluster 2 auf solche Weise aufgeteilt geworden, dass der Nachrichten-Hauptmanager von seinen Backupnachrichtenmanagern abgetrennt worden war. Der originelle Nachrichten-Hauptmanager residiert innerhalb der Partition, die über eine Mehrheit von Kundenmanagern verfügt, während die andere zwei Nachrichtenmanager über eine Minderheit von Kundenmanagern verfügen. In Abwesenheit von einem Nachrichten-Hauptmanager hat die Partition des Unterclusters 2, der originell zwei Backupnachrichtenmanager hat, einen der Backupnachrichtenmanager zu einem Nachrichten-Hauptmanager promoviert.
  • Dieser neue Nachrichten-Hauptmanager hat jedoch den Partitionszustand D und ist damit „beschränkt" und „aufbewahrend". Der originelle Nachrichten-Hauptmanager hat den Partitionszustand B und ist „aufbewahrend".
  • 4 schildert die Ausführung einer einfachen Transaktion in einem Nachrichtenübertragungsclustersystem. Wie gesehen, umfasst die Transaktion zwei Untercluster, die durch Grautönung kenntlich gemacht sind, und besteht aus einer Nachricht, die gesendet wird, und einer Nachricht, die empfangen wird.
  • In der 4 hat ein Kunde, der mit dem Kundenmanager verbunden ist, eine Transaktionssession geschaffen. Der Kundenmanager agiert als ein Transaktionsmanager. Der Kunde sendet dann eine Nachricht, deren Destination sich im Untercluster 1 befindet, und empfängt eine Nachricht, die in einer Destination im Untercluster 2 lokalisiert ist. Der Kunde beantragt dann die Abwicklung der Transaktion, welche der Transaktionsmanager über den Multicastbus „multicastet", und erhält das Ergebnis dieser Operation zurück.
  • 5 schildert die Ausführung einer Transaktion im Zeitablauf. Die Nachrichten von einer Transaktion schließen Nachrichten ein, die in einer Transaktionssession ab dem letzten Abbruch/der letzten Abwicklung gesendet bzw. empfangen worden sind. Wie in der Abbildung dargestellt, umfasst die Transaktion drei Nachrichtenoperationen – die Seindung einer Nachricht und der Empfang von zwei Nachrichten – sowie eine Abwicklung.
  • Weder verhindert die Erfindung die Auftretung von Knotenausfällen und Netzteilungen, noch beseitigt diese. Stattdessen erkennt die Erfindung an, dass diese Ereignisse möglich sind, und präsentiert eine Lösung, die ermöglicht, dass der Cluster stets fähig ist, die JMS-Semantik sogar während der Periode nach der Auftretung von solchen Ereignissen zu gewährleisten, bevor diese beseitigt werden. Das wird dadurch gemacht, dass allen Kundenmanagern und Nachrichtenmanagern, und damit der ganzen Partition, ermöglicht wird, zu detektieren und zu identifizieren, wenn ein Cluster (bzw. eine Partition) in der Situation ist, wo die Ausführung von bestimmten Operationen zu einem Bruch in der JMS-Semantik führen könnte. Insbesondere, wenn solche Situation detektiert und identifiziert worden ist, ist jeder Knoten fähig zu konkludieren, ob eine gegebene Operation – in Bezug auf die Granularität von Nachrichten – dazu führen könnte, dass die JMS-Semantik verletzt wird, und hält also mit der Ausführung der Operation zurück, bis diese semantisch sicher ist, um gemacht zu werden.
  • Die Erfindung unterstützt den richtigen Betrieb, wenn der Cluster gleichzeitig in eine Anzahl von Netzpartitionen zersplittert. Die Erfindung setzt jedoch voraus, dass der Cluster auf solche Weise konfiguriert ist, dass alle Kundenmanager niemals von allen Nachrichtenmanagern abgetrennt werden können. Die Konsequenz davon wäre es, dass der Cluster stoppen würde, zu funktionieren. Das kann einfach durch gemeinsame Lokalisierung von Kundenmanagern und Nachrichtenmanagern auf denselben Maschinen gewährleistet werden.
  • Die Erfindung unterstützt auch die Unterclusterabstraktion, was bedeutet, dass der Cluster über einen oder mehrere Untercluster verfügen kann, die jeweils einen Nachrichten-Hauptmanager und keinen oder mehrere Backupnachrichtenmanager enthalten. Jeder Untercluster ist für Lieferung von einem disjunkten Untersatz von Nachrichten verantwortlich, wie es durch die Lastausgleichslogik bestimmt wird. Wenn ein Nachrichten-Hauptmanager sowie alle seine Backupnachrichtenmanager in einem einzelnen Untercluster lokalisiert sind, werden Knotenausfälle und Netzteilungen in jedem Untercluster getrennt behandelt. Der Fall, in welchem sich die Verantwortlichkeit für Nachrichten nicht über zahlreiche Untercluster erstreckt und alle Nachrichten durch einen einzelnen Cluster von Nachrichtenmanagern behandelt werden, ist ein besonderer Fall der Unterclusterabstraktion, in welchem die Anzahl von Unterclustern gleich eins ist.
  • Endlich unterstützt die Erfindung den Transaktionsprozess, d.h. die atomare Ausführung von zahlreichen Nachrichtenoperationen (Senden/Empfangen), und gewährleistet die JMS-Semantik sogar während Knotenausfälle und Netzteilungen bei der Ausführung von Transaktionen.
  • Die Erfindung beruht darauf, dass jeder Kundenmanager und Nachrichtenmanager in einem Cluster fähig ist, den Zustand des Clusters (oder einer Partition) zu detektieren und zu identifizieren, dadurch dass verschiedene Zustandinformationen gehalten werden. Diese Zustandinformationen werden benutzt, um jeden Knoten mit dem erwarteten und dem aktuellen Zustand des Clusters bekanntzumachen, was ein wichtiger Aspekt ist, um die Knoten darauf hinzuweisen, wenn semantische Fehler potentiell auftreten können, und ihnen zu ermöglichen, die Verletzung der JMS-Semantik zu verhindern. Es gibt folgende, für die Erfindung relevante Zustände, die von den Kundenmanagern und Nachrichtenmanagern aufbewahrt werden:
    • – Konfigurationszustand – definiert, wie der Cluster konfiguriert ist, d.h. wie viel Kundenmanager und Nachrichtenmanager es gibt, sowie definiert die Gruppierung in die Untercluster, welche der Verwalter im Rahmen des ganzen Clusters konfiguriert hat. Jederzeit, wenn der Verwalter einen Knoten addiert oder einen Knoten aus dem Cluster entfernt, ändert sich der Zustand. Der Zustand, der Informationen über Kundenmanager, Nachrichtenmanager und deren Gruppierung in einen oder mehrere Untercluster enthält, wird durch eine Zustandssequenzzahl identifiziert, welche jederzeit zunimmt, wenn der Zustand aktualisiert wird. Um richtig im Cluster funktionieren, müssen die Knoten über ein konsistentes Sichtfeld von dem Konfigurationszustand verfügen. Um das höchste Niveau der Flexibilität durch Ermöglichung dem Verwalter, den Zustand während Knotenausfälle und/oder Netzteilungen zu ändern, und gleichzeitig die Konsistenz bei Knoten sicherzustellen, wird einen Mehrheitsgrundsatz angewendet, wenn sich der Zustand ändert. Der Mehrheitsgrundsatz erlaubt dem Verwalter, den Konfigurationszustand zu ändern, insoweit eine Mehrheit von Knoten zugänglich ist. Knoten, die unzugänglich sind, wenn der Verwalter den Konfigurationszustand ändert, sind damit inkonsistent und werden aktualisiert, wenn sie mit dem Rest des Clusters abgestimmt werden.
    • – Sichtfeldzustand – definiert das aktuelle Sichtfeld des Clusters, wie dieses aus der grundlegenden Multicast-Ebene gesehen wird, d.h. wie der Cluster aktuell in Bezug auf Kundenmanager und Nachrichtenmanager sowie die Gruppierung in die Untercluster erscheint. Im Gegensatz zu dem Konfigurationszustand enthält der Sichtfeldszustand jedes Knotens nur diese Knoten, die aktuell für den Knoten über die Multicast-Schicht erreichbar sind. Der Zustand wird durch eine Zustandssequenzzahl identifiziert, welche eine Datenstruktur repräsentiert, die Informationen über Kundenmanager, Nachrichtenmanager und die Gruppierung in die Untercluster innerhalb des Sichtfelds enthält. Weil zwei Partitionen die gleiche Zustandssequenzzahl haben dürfen, aber der Kontext von dieser zwei Zustände unterschiedlich ist, widerspiegelt die Zustandssequenzzahl eine Datenstruktur eindeutig nicht. Der Zustand ändert sich jederzeit, wenn ein oder mehrere Knoten zugänglich bzw. unzugänglich für den Cluster werden. Der Sichtfeldszustand ändert sich sowohl infolge Knotenausfälle sowie Rückgewinnung, Teilung bzw. Sanierung des Netzes, als auch, wenn der Verwalter einen Knoten an den Cluster addiert oder aus dem Cluster entfernt, d.h. wenn er den Konfigurationszustand ändert.
    • – Partitionszustand – definiert die Partition – in Abhängigkeit davon, wie der Cluster/Untercluster aktuell gemäß dem Sichtfeldszustand im Vergleich zu dem Konfigurationszustand erscheint – oder den ganzen Cluster, wenn keine Ausfälle aufgetreten sind, in Bezug auf eine Nachricht, deren Behandlung erlaubt wird. Alle Knoten innerhalb eines Unterclusters haben denselben Partitionszustand, wenn keine Ausfälle aufgetreten sind. Es kann eventuell die Inkonsistenz zwischen den Knoten in Bezug auf den Partitionszustand bestehen, aber das wird aufgelöst, wenn sich ein Sichtfeldszustand ändert, was zu erfolgen hat, und sich Auslöser und Knoten miteinander synchronisieren. Während der Konfigurationszustand und der Sichtfeldszustand über unendliche Zustandssequenzzahlen verfügen, nimmt der Partitionszustand einen endlichen Wert A, B, C oder D, der von der Anzahl von Kundenmanagern sowie Nachrichtenmanagern im aktuellen Sichtfeldszustand im Vergleich zu dem aktuellen Konfigurationszustand abhängig ist. Eine Änderung von dem Partitionszustand wird durch eine Änderung im Sichtfeldzustand über die Multicast-Schicht ausgelöst. Weil die Kundenmanager mit zahlreichen Unterclustern geteilt werden und die Kundenmanager brauchen, den Partitionszustand von einem gegebenen Untercluster zu kennen, bedeutet das, dass die Kundenmanager fähig sein sollten, zahlreiche Partitionszustände, einen für jeden Untercluster, der im aktuellen Sichtfeldszustand repräsentiert wird, aufzubewahren. Der Grund, wofür Kundenmanager brauchen, den Partitionszustand zu kennen, ist es, dass diese fähig sein müssen, Nachrichten im Notfall gegen Sendung durch einen gegebenen Untercluster zu blockieren, was später beschrieben wird.
    • – Destinationszustand – definiert den internen Zustand jeder Destination per Nachrichtenmanager, wobei Nachrichten, die aktuell in der Destination gespeichert sind, mit ihrer globalen Identifikation, Priorität, Lieferungsmodus, Veröffentlichern, Lieferungszustand, Schlössern, Subskriptionsdefinitionen, individuellen Subskriptionszuständen etc. eingeschlossen werden. Ein Destinationszustand verfügt über keine identifizierende Sequenzzahl, aber wird durch seine Datenstruktur definiert, die die oben erwähnten Informationen repräsentiert.
  • Die Knoten im Untercluster tauschen die Informationen über den Zustand während der Sichtfeldänderungen aus. Bei so einer Auffassung werden die Zustandskonflikte, d.h. Situationen wo bei mehreren Knoten verschiedene Konfigurations-, Sichtfeld-. Partitions- bzw. Zielortszustände vorliegen, während einer Sichtfeldänderung erkannt. Ist eine Inkohärenz erkannt worden, wird sie durch die Zustandssynchronisierung laut nachstehender Beschreibung beseitigt.
  • Während des Lebenszyklus eines Clusters/Unterclusters kann sich der Zustand seiner Partition sowie der Zustand dessen Knoten infolge von Sichtfeldänderungen je nach Häufigkeit der Netzteilungen und der Knotenausfälle mehrmals verändern. Diese Erfindung nutzt den Zustandsmechanismus aus, um mögliche Zustandsübergänge für die Partitionszustände zu definieren. In der 2 werden die möglichen, als Knoten vertretenen Partitionszustände sowie die als Spitzen vertretenen potentiellen Übergangsereignisse dargestellt. Der Ausgangspunkt für den Übergangsgraph ist der Partitionszustand A, wo davon ausgegangen wird, dass alle Kundenmanager und Nachrichtenmanager anfangs bei dem Systemfunktionsantritt zugänglich sind. Wie aus der 2 ersichtlich ist, verfügt die die Kundenmanager und Nachrichtenmanager enthaltene Partition, welche sich im Partitionszustand A befinden, über einen Nachrichten-Hauptmanager, der normal funktioniert. Andererseits kann der Hauptmanager von Nachrichten in den Partitionszuständen B, C bzw. D kaum normal funktionieren, weil er:
    • – beschränkt in Bezug auf die Punkt-zu-Punkt-Nachrichten ist; der Hauptmanager ist beschränkt im Artbereich der Punkt-zu-Punkt-Nachrichten. Der Hauptmanager ist dabei beschränkt im Partitionszustand und/oder
    • – aufbewahrend in Bezug auf die veröffentlichte/subskribierte Nachrichten; der Hauptmanager muss die veröffentlichte/subskribierte Nachrichten aufbewahren, die in anderen Situationen beseitigt wären. Der Hauptmanager ist aufbewahrend in den Partitionszuständen B, C und D
  • Die Semantik des Beschränktseins und des Aufbewahrendseins wurde nachstehend beschrieben. Taucht eine beliebige Partition ohne Hauptmanager während der Übergänge zwischen allen Zuständen auf, wird der Nachrichten-Backupmanager zum neuen – und wahrscheinlich einen beschränkten/aufbewahrenden – Hauptmanager erhoben; kommt dagegen eine beliebige Partition vor, die einen ordentlichen Hauptmanager besitzt, wird dieser zum beschränkten Hauptmanager nach Eintreten des Partitionszustands D bzw. zum aufbewahrenden Hauptmanager nach Eintreten der Partitionszustände B, C bzw. D degradiert.
  • Eine andere wichtige Beobachtung aus 2 besteht darin, dass ein Cluster/Untercluster den Partitionszustand D ausschließlich verlassen kann, indem er in den Partitionszustand A übergeht. Diese Situation kann nur dann auftreten, wenn alle im Konfigurationszustand definierten Nachrichtenmanager innerhalb eines Clusters/Unterclusters zugänglich sind, was wiederum bedeutet, dass sich ein Cluster/Untercluster nach einer Netzteilung bzw. Knotenausfall völlig erholen soll. In Zustandskategorien bedeutet es, dass der aktuelle Sichtfeldzustand des Clusters/Unterclusters in Bezug auf die im Untercluster gruppierten Nachrichtenmanager mit der vom Verwalter festgelegten und im Konfigurationszustand dargestellten Konfiguration übereinstimmt.
  • Aus solcher Kategorisierung des Partitionszustands ergibt sich Folgendes: Erfolgt eine Netzteilung in zwei trennbaren Partitionen, muss eine davon den Partitionszustand D, und die andere den Partitionszustand B, C bzw. D übernehmen. Für die Übernahme des Partitionszustands B oder C spricht die Möglichkeit unnötige Beschränkungen bei weiteren Netzteilungen zu vermeiden. In der 3 ist ein geteilter Cluster/Untercluster mit bezeichneten Partitionszuständen beispielsweise dargestellt.
  • Nachstehend sind Folgen aus dem Bestehen eines beschränkten/aufbewahrenden Hauptmanagers im Partitionszustands D für die Warteschlangen- und die thematischen Zielorte dargestellt:
    Für die Punkt-zu-Punkt-Zielorte bedeutet es, dass der beschränkte Hauptmanager bezüglich Sendung der Nachrichten beschränkt ist, die in einem beliebigen vorherigen Sichtfeldzustand empfangen sind. Stattdessen werden die Punkt-zu-Punkt-Nachrichten gesperrt, denn es kann sich bei denen um potentielle vervielfältigte Nachrichten handeln. Dies ergibt sich aus der Tatsache, dass ein anderer, ordentlicher und dadurch unbeschränkter Hauptmanager innerhalb einer Netzposition handeln könnte, indem er möglicherweise Nachrichten senden würde. Außer von Sperrung der in einem beliebigen vorherigen Sichtfeldzustand empfangenen Punt-zu-Punkt-Nachrichten sperrt der beschränkte Hauptmanager auch Warteschlangen-Nachrichten, was in der Nachrichtensperrung am Zielort resultiert, soweit sie derselben Session entstammen. Auf diese Weise ist eine teilweise Durchordnung der Nachrichten sichergestellt. Die gesperrten Punkt-zu-Punkt-Nachrichten können solange nicht gesendet werden, bis sich der Untercluster nach erfolgter Netzteilung bzw. Knotenausfall soweit erholt hat, dass er in den Partitionszustand A übergeht.
    Sollte trotzdem der Nachrichtenmanager versuchen, eine wegen Zustandsinkoheränz während der Netzteilung potentiell vervielfältigende Nachricht abzusenden, wird dann die Nachricht dem Nachrichtenmanager vom Kundenmanager mit der Anmerkung zurückgesendet, dass der Hauptmanager es zu einstellen hat, Nachrichten vom vorherigen Sichtfeldzustand her zu senden. Solche Nachrichten werden zurückgesendet, weil der empfangende Kundenmanager es verlangt – als eine teilweise Prüfmaßnahme gegen Versendung potentiell vervielfältigender Nachrichten – eine Empfangsbestätigung zu bekommen, die er von den meisten sonstigen Kundenmanagern im aktuellen Sichtfeldzustand nicht erhalten wird, welcher eine Nachrichtensendung an den Kunden erlaubt. Er kann niemals eine Empfangsbestätigung von den meisten sonstigen Kundenmanagern im aktuellen Sichtfeldzustand bekommen, weil nur eine einzige Partition einen Nachrichtenmanager enthalten kann, welcher nicht im Zustand D ist. Ist diese Partition geteilt, kann dann höchstens eine der sich aus der Teilung ergebenden Partitionen die meisten Kundenmanager enthalten.
  • Enthält der Zielort in der Punkt-zu-Punkt-Kommunikation zum Zeitpunkt der Netzteilung keine zu verarbeitenden Nachrichten, erkennt der „beschränkte" Hauptmanager keine Einschränkungen in neuem Sichtfeldzustand. Unter solchen Umständen kann der beschränkte Hauptmanager weiterhin fungieren, ohne die JMS-Semantik zu brechen.
  • Für die Zielorte in der Veröffentlicher/Subskribent-Kommunikation sind die Auswirkungen des aufbewahrenden Hauptmanager-Seins anders, denn der Begriff Vermeidung der Nachrichtenvervielfältigung im Bereich Veröffentlicher/Subskribent keinen Sinn mehr hat. In Bezug darauf werden keine Nachrichten an Zielorte vom aufbewahrenden Hauptmanager in der Veröffentlicher/Subskribent-Kommunikation gesperrt. Die Semantikanforderung für die Zielorte in einer Veröffentlicher/Subskribent-Kommunikation spezifisiert, dass sämtliche an einen Zielort gesendeten Nachrichten an alle Subskribenten dieses Zielortes geliefert werden. Zum Zeitpunkt, wo eine veröffentlichte/subskribierte Nachricht (eine dauerhafte bzw. nicht dauerhafte) an alle interessierten Subskribenten angeliefert worden ist, kann diese vom Nachrichtenmanager beseitigt werden. Dies hat ein Problem bei der Netzteilung zur Folge, denn die Kunden (Subskribent) mit Anschluss an eine Partition können aufgrund der Aufteilung keine Nachrichten bekommen, die in einer anderen Partition gesendet wurden. Deswegen ist die Ermittlung kaum möglich, wann die betreffende veröffentlichte/subskribierte Nachricht an sämtliche Subskribent innerhalb des Clusters zugestellt wurde. Um dem abzuhelfen, schlägt die Erfindung vor, die Beseitigung sämtlicher veröffentlichter/subskribierter Nachricht in allen Nicht-A-Partitionszuständen einzustellen – es werden ausschließlich veröffentlichte/subskribierte Nachricht im Partitionszustand A beseitigt. Stattdessen werden die veröffentlichten/subskribierten Nachrichten an Zielorten bis zur Ausbesserung der Netzteilung so aufbewahrt, dass der gesamte Cluster wieder in den Partitionszustand A übergeht. Weil keiner der Hauptmanager, abgesehen von seinem Partitionszustand, wegen der Netzteilung imstande ist mit allen Subskribenten zu kommunizieren, müssen die veröffentlichten/subskribierten Nachrichten von allen aufbewahrt anstatt zu beseitigt werden. Ausgenommen davon ist Überfälligkeit der Nachricht. Die Erfindung setzt voraus, dass eine Überfälligkeit der Nachricht den Vorrang vor der Lieferung an alle Subskribenten während der Knotenausfälle und Netzteilungen hat, was mit der JMS-Semantik übereinstimmt.
  • Nach Ausbesserung der Netzteilung schließen sich die Cluster/Untercluster wieder zusammen, wobei ein Übergang des Partitionszustands aufgrund der Änderung des Sichtfeldzustands erfolgt. Eine Sichtfeldzustandsänderung findet auch dann statt, wenn auf eine Netzteilung unmittelbar die nächste Teilung folgt. In beiden Fällen können die Knoten verschiedene Konfigurations-, Partitions- und Sichtfeldzustände aufweisen, trotzdem bleiben diese Zustände im Partitionsrahmen kohärent. Voraussetzung für eine Abstimmung des Konfigurationszustands ist die Knotenmehrheit. Damit die Netzpartitionen zusammengeschlossen werden können, muss die neue Sequenznummer des Sichtfeldzustands für einen geteilten bzw. ungeteilten Cluster/Untercluster zuerst von allen Knoten im neuen Sichtfeld abgestimmt und festgelegt werden, die die höchste, im neuen Sichtfeld gefundene Sequenznummer des Sichtfeldzustands um 1 überragt, sowie der Datenaufbau des Sichtfeldzustands entsprechend aktualisiert werden.
  • Nach erfolgter Aktualisierung des Sichtfeldzustands tauschen alle Knoten im neuen Sichtfeld die Konfigurations- und Partitionszustände untereinander, welche sie vor der Sichtfeldänderung hatten, wie auch Informationen darüber, ob sie Hauptmanager sind oder nicht. Diese Zustandsmitteilung wird durch eine Nachrichtenveröffentlichung für den Empfang durch alle sonstigen Knoten ausgetauscht. Nach Empfang dieser Nachricht von allen sonstigen Knoten im neuen Sichtfeld aktualisiert jeder Knoten die ihm vorliegenden Zustandsinfos gemäß folgenden Regeln:
    • – Die höchste Sequenznummer des Konfigurationszustands unter allen Knoten im Sichtfeldzustand erhält den Vorrang vor den niedrigeren Sequenznummern des Konfigurationszustands. Die Knoten im neuen Sichtfeld eines geteilten bzw. ungeteilten Clusters stimmen die höchste Konfigurationszustandnummer unter allen Knoten ab und, soweit erforderlich, nehmen deren Konfigurationsaktualisierung gemäß dem neuen Konfigurationszustand vor.
    • – Aus dem aktuellen Partitionszustand sowie dem neuen Sichtfeldzustand, vergleichbar mit dem Konfigurationszustand ausgehend, wird der Partitionszustand nach dem Übergangszustandsgraph – siehe 2 – von jedem Knoten aktualisiert. Dies führt dazu, dass sämtliche Knoten im Sichtfeld den gleichen Partitionszustand aufweisen.
  • Sind diese Zustände synchronisiert worden, müssen die Nachrichtenmanager über geltenden Hauptmanager in jedem Cluster einig werden, in dem eine Zustandsänderung eingetreten ist. Aus der veröffentlichten Information kann jeder Nachrichtenmanager schließen, ob die anderen Nachrichtenmanager es angeben Hauptmanager zu sein. Gibt keiner der Nachrichtenmanager an, Hauptmanager innerhalb des Unterclusters zu sein, erhebt sich der jeweils höchstrangige Nachrichtenmanager in einem jeden Cluster zum Hauptmanager. Sollten mehrere Nachrichtenmanager angeben Hauptmanager zu sein, degradieren sich alle Hauptmanager außer von dem des höchsten Grades, wobei die Erfassungsfolge im Cluster für die Gradstufung maßgebend ist. Während dieser Aktion überprüft der Hauptmanager, in welchem Partitionszustand er sich befindet. Sollte der Partitionszustand B, C bzw. D bei ihm vorliegen, degradiert er sich ausschließlich zu der Stelle des aufbewahrenden Hauptmanagers und beim Vorliegen des Partitionszustands D stuft er sich sogar zum beschränkten Hauptmanager herab.
  • Nach erfolgter Abstimmung der Hauptmanager-Zuständigkeit in jedem Cluster synchronisieren die Nachrichtenmanager ihren jeweiligen Zielortzustand, um deren Kohärenz zu erreichen, d.h. sie tauschen die Infos über die Nachrichten aus, die in jeder Partition von den Nachrichtenherstellern empfangen bzw. an die Nachrichtenbenutzer während der Netzteilung bzw. des Knotenausfalls gesendet werden konnten. Dies wird nach einem Verfahren durchgeführt, welches auf dem Prinzip der Antientropie, d.h. durch Abstimmung von zwei Nutzeinheiten – in diesem Fall von Partitionen – beruht. Nach erfolgter Zustandssynchronisierung der Zielorte beurteilt der Hauptmanager in jedem Cluster, ob irgendwelche Warteschlangen- bzw. thematische Nachrichten vorliegen, die gesendet werden müssen. Der Hauptmanager in jedem Cluster beurteilt auch, ob irgendwelche gesperrte Nachrichten vorliegen und ob diese gesendet worden sind oder nicht und schließlich ob sie jetzt gesendet werden können. Zum Schluss beurteilt der Hauptmanager in jedem Cluster, ob thematische Nachrichten vorliegen, die bereits beseitigt werden können.
  • Die Knotenzustände und deren deterministisches Verhalten schafft solide Grundlagen dafür, dass die Funktion Nachrichtenlieferung auch während der Knotenausfälle bzw. Netzteilungen auf eine semantisch richtige Art und Weise umgesetzt werden kann. Damit dies jedoch erfolgreich wird, ist ein System der Nachrichtenlieferung anzunehmen und zu verwenden.
  • Im Allgemeinen erfolgt die Nachrichtenübermittlung auf dem Prinzip, dass die Nachricht an denjenigen Kundenmanager vom Kunden abgesendet wird, mit welchen er verbunden ist. Ist die Nachricht empfangen worden, wird sie mit der laufenden Sequenznummer des Sichtfeldzustands vom Kundenmanager gekennzeichnet. Zweck dieses Merkers ist, die während eines bestimmten Sichtfeldzustands empfangenen sowie die während eines anderen Sichtfeldzustands abgesendeten Nachrichten identifizieren zu können. Genau genommen handelt es sich dabei um potentiell sich vervielfältigende Nachrichten, weil die Hauptmanager in beiden Netzpartitionen nach einer Sichtfeldänderung aufgrund Netzteilung immer es versuchen werden dieselbe Nachricht abzusenden, indem sie davon ausgehen jeweils der einzige Sender zu sein. So kann man durch die Kennzeichnung der Nachrichten es möglich machen diese zu identifizieren und deren Vervielfältigung zu verhindern.
  • Danach sendet der Kundenmanager die Nachricht an ihren Zielort, d.h. an eine Warteschlange bzw. eine thematische Gruppe in den Nachrichtenmanagern ab. Sämtliche Kundenmanager kennen alle möglichen Zielorte, so stempeln sie die Nachricht mit dem gewählten Zielort ab, bevor sie diese an die Sendeschicht des Unterclusters versenden. Ist die Nachricht empfangen worden, wird der Empfang der Nachricht ausschließlich vom Hauptmanager bestätigt. Die Backup-Nachrichtenmanager geben keine Bestätigung ab, sie horchen dagegen, ob der Hauptmanager den Empfang bestätigt hat. Hat dies erfolgt, erfassen die Backupmanager diese Tatsache. Dies ist dann von Nutzen, wenn der Hauptmanager nach dem Nachrichtempfang, jedoch noch vor deren Bestätigung nicht erreichbar wurde; so kann der neue Hauptmanager wissen, ob die Nachricht doch noch einer Bestätigung für den Kundenmanager bedarf bzw. nicht mehr. Nach Erhalt der Empfangsbestätigung der Nachricht bestätigt der Kundenmanager den Empfang dem Kunden und löscht diese vom Speicher.
  • Der Hauptmanager wählt dann den einzelnen Kunden, der eine Warteschlangen-Nachricht bekommen soll bzw. mehrere Kunden für die betreffende thematische Nachricht. Ist diese Tätigkeit vollzogen, wird die Nachricht mit der Session-ID-Nummer vom Hauptmanager gestempelt und dann an den Unterclusterkanal gesendet, damit die Kundenmanager und die Nachrichtenmanager diese bekommen können. Ist die Nachricht gesendet worden, bekommen alle Nachrichtenmanager (Haupt- und Backup-Manager) die vom Hauptmanager gesendete Nachricht und dann wird bei allen registriert, dass die Nachricht vom Hauptmanager gesendet wurde. Noch bevor der Kundenmanager die tatsächliche Nachrichtensendung an den Kunden durchführt, muss er die Bestätigungen von den meisten Kundenmanagern im aktuellen Sichtfeldzustand bekommen. Jeder Kundenmanager, der die Nachricht zum Senden bekommen hat – einschließlich des für die tatsächliche Veröffentlichung verantwortlichen – bestätigt den Empfang durch Signalveröffentlichung an die Sendeschicht des Unterclusters. Die Bestätigung durch den für die Nachrichtsendung verantwortlichen Kundenmanager wird von allen Nachrichtenmanagern empfangen und erfasst. Hat der verantwortliche Kundenmanager die meisten Bestätigungen von den sonstigen Kundenmanagern- mit Berücksichtigung seiner eigenen Bestätigung – empfangen, wird die Nachricht an den Kunden gesendet und der Kundenmanager wird nunmehr auf die Bestätigung vom Kunden warten. So ein Bestätigungsablauf wurde dazu verwendet, damit die Nachricht nicht an die Partition mit der Minderheit der Kundenmanager im aktuellen Sichtfeldzustand, auch vor dessen Änderung, gesendet wird.
  • Nach Erhalt der Kundenbestätigung wird die Bestätigung vom Kundenmanager an die Sendeschicht veröffentlicht, damit sie von allen Kundenmanagern im Untercluster empfangen werden kann. Dann erfassen die Nachrichtenmanager und die sendenden Kundenmanager die Tatsache, dass die Nachricht vom Kunden empfangen worden ist, sie markieren auch die Nachricht für deren Beseitigung.
  • Ist die Kundensession zum Zeitpunkt der Nachrichtsendung durch den Hauptmanager beim Kundenmanager nicht mehr erreichbar, wird diese vom Kundenmanager mit entsprechender Mitteilung zurückgesendet, was darin resultiert, dass die Nachrichtenmanager die Kennzeichnung der Nachrichtensendung an den Kundenmanager zurücknehmen, wonach diese – bei einer Punkt-zu-Punkt-Nachricht – erneut versendet werden kann; bei einer unbeständigen veröffentlichten/subskribierten Nachricht wird die Nachricht von den Kundenmanagern mit der Anweisung schlicht zurückgeschickt, diese an einen bestimmten Kunden nicht mehr zu senden; keine zusätzliche Handlung wird vorgenommen. Bei beständigen [fixen) Subskribenten wird die Nachricht samt Mitteilung zurückgesendet, dass die Nachricht vom Kunden nicht empfangen wurde, so müsse sie mindestens bis zum Zeitpunkt der erneuten Verbindung des unbeständigen Subskribenten mit dem Nachrichtenservercluster aufbewahrt werden.
  • Aus verschiedenen Gründen können die Zielorte jederzeit Nachrichten aus einer bestimmten Kundensession reihenfolgewidrig bekommen. Einer der Gründe kann z.B. darin bestehen, dass die Session eine bzw. mehrere Nachrichten aus der Kundensession verliert. In einem Sonderfall könnte die Empfangsanmeldung einer Nachricht mit der Sequenznummer X+10 an den Zielort gesendet werden, während noch nicht alle vorherigen Nachrichten dort angelangt sind. So eine Situation wäre nur auf einen Clusterausfall zurückzuführen, währenddessen der über den Bestimmungsort in einem Untercluster informierende Kunde versetzt wurde, um über denselben Bestimmungsort in einem anderen Untercluster zu informieren. Dies könnte möglicherweise zu einer reihenfolgewidrigen Lieferung führen, falls der Hauptmanager die für einen Zielort in einem Untercluster bestimmte Nachricht X+10 an den Kunden senden würde, noch bevor der Hauptmanager die für denselben Zielort in einem anderen Untercluster bestimmte Nachricht X+9 gesendet hat.
  • So ein Vorfall kann dann auftreten, wenn der Kunde die Verbindung mit demjenigen Kundenmanager verloren hat, über welchen er Nachrichten für die Zielorte hergestellt hat, worauf er wieder mit dem Cluster von einem anderen Kundenmanager verbunden wird. Normalerweise ist das unproblematisch, weil der neue Kundenmanager aufgrund der Anforderung einer neuen Verbindung durchaus feststellen kann, über welchen Untercluster der Kunde an den Zielort gesendet hat. Dabei besteht jedoch die Gefahr einer semantischen Unstimmigkeit, vorausgesetzt der Cluster/Untercluster ist geteilt worden und der neue als Zugriffstelle zum Cluster/Untercluster benutzte Kundenmanager befindet sich in einer anderen Partition als der vorherige Kundenmanager. Das Problem besteht darin, dass die Nachrichtenlieferung innerhalb einer Session als teilweise geordnet gehalten werden muss. Dies ergibt sich aus der Tatsache, dass der Zielort in mehrere Untercluster eingeteilt werden kann, wobei jeder davon eine Teilmenge der gesamten Nachrichtenmenge enthält, so würden die Kundensessionen bei einem Ausfall an denselben Zielort in verschiedenen Unterclustern senden.
  • Aus der Kundenanforderung einer Neuverbindung kann man schließen, dass der Kunde seine Nachrichten an einen anderen Untercluster vorab gesendet hat. Trifft dies zu, versucht der Kundenmanager den Kunden mit dem vorherigen Untercluster zu verbinden, um jegliche Semantikprobleme zu vermeiden. Sollte dies nicht möglich sein, wird der Kundenmanager die Anforderung der erneuten Verbindung akzeptieren und diese an den Hauptmanager zwecks Beseitigung jeglicher Semantikprobleme weiterleiten.
  • Damit mögliche Semantikprobleme beseitigt werden können, ist jede vom Kunden an den Zielort gesendete Nachricht mit vom Kunden selbst zugeteilten Identifikationsdaten inkl. Bezeichnung der Session und des Zielortes sowie mit der Sequenznummer der Nachricht als Kombination von Zielort und Session versehen und zwar abgesehen davon, ob die Nachricht einen Teil der einzigartigen Identifikationsdaten darstellt oder nicht. Aufgrund dieser Informationen beurteilt der Hauptmanager, ob die Nachrichtenfolge für einen Zielort Lücken aufweist. Hat der Hauptmanager erkannt, dass irgendwelche Nachrichten von der betreffenden Session fehlen, werden die weiteren Nachrichten gesperrt, d.h. sie werden nicht vor der Synchronisierung der Zielorte versendet, was in kompletter Nachrichtenfolge sowie richtiger Reihenfolge am Zielort und demnach der Umsetzung der teilweisen Durchordnung resultiert.
  • Diese Erfindung garantiert auch eine semantisch ordnungsmäßige Verarbeitung von Transaktionen, d.h. atomare Vollziehung mehrmaliger Nachrichtenlieferungen während der Netzteilungen und Knotenausfälle. Die Erfindung unterstützt die Verarbeitung von Transaktionen, die mehrere Untercluster enthalten wie aus der Ab. 4 ersichtlich ist. Unter dem Gesichtspunkt der Transaktionsverarbeitung fungiert der Kundenmanager als Transaktionsmanager, wonach der Kundenmanager, mit dem der jeweilige Kunde verbunden ist, auch für die Koordinierung und Durchführung verschiedener Transaktionsetappen in diversen Unterclustern zuständig ist. Bei der Erfindung wird der Algorithmus der zweiphasigen Transaktionsdurchführung verwendet.
  • Damit die Transaktion zustande kommt, muss der Kunde seine zu unterstützende Session spezifizieren. Dazu muss der Kunde die komplette zu sendende bzw. vom Cluster erhaltene Nachrichtenmenge zu einem gewissen Zeitpunkt anvertrauen oder abbrechen. Der zweiphasige Durchführungsvorgang wird komplett vom Transaktionsmanager im Kundenmanager unterstützt und ist für den Kunden transparent. Es gibt keine Anforderung darüber, wie oft der Kunde eine Transaktion anvertrauen bzw. abbrechen kann. Weil der Kunde eine Transaktionsfolge mehrmals während der Lebenszyklus anvertrauen bzw. abbrechen kann, kann theoretisch angenommen werden, dass eine Transaktionssession mehrfache autonome Transaktionen enthält, die durch Kundenanweisungen Durchführung/Abbrechung getrennt werden. Wird eine Transaktion abgebrochen bzw. abgelehnt, beeinflusst dies keineswegs die vorhergehenden oder die nächsten Transaktionen. Die 5 zeigt eine Transaktion, die drei Nachrichten sowie einen innerhalb einer gewissen Zeit umgesetzten Durchführungsbefehl enthält. Nachdem die Transaktionssession definiert worden ist, kann der Kunde eine bestimmte Nachrichtenanzahl an den Transaktionsmanager senden bzw. Nachrichten empfangen, die vom Hauptmanager über den Transaktionsmanager gesendet wurden.
  • Zu einem gewissen Zeitpunkt sendet der Kunde den Durchführungsbefehl an den Transaktionsmanager. Nach Empfang der Durchführungsforderung wandelt der Transaktionsmanager diese in einen Bereitstellungsbefehl um, welcher dann in den an der Transaktion beteiligten Unterclustern veröffentlicht wird, worauf der nächste Durchführungs- bzw. Abbrechbefehl je nach dem Ergebnis der Bereitstellungsforderung folgt. Die Bereitstellungsforderung enthält die Identifikationsdaten aller abgesendeten und empfangenen Nachrichten, die unter die an der Transaktion beteiligten Untercluster eingeteilt sind. Nach Empfang der Bereitstellungsforderung prüfen die Nachrichtenmanager in den beteiligten Unterclustern nach, ob sie alle Nachrichten empfangen haben, die sie gemäß den in der Bereitstellungsforderung enthaltenen Nachrichten-ID-Daten zu empfangen hatten. Falls dies zutrifft, geben die Nachrichtenmanager dem Transaktionsmanager die positive und falls nicht – die negative Antwort ab.
  • Sollte auch nur noch einer der Nachrichtenmanager, sei es der Haupt-, sei es der Backupmanager, die Bereitstellungsforderung negativ beantwortet haben, bricht der Transaktionsmanager die Transaktion ab, indem er entsprechende Information an die Untercluster veröffentlicht und den Kunden über den Abbruch informiert. Sollten alle Nachrichtenmanager positiv beantwortet haben, veröffentlich der Transaktionsmanager den Durchführungsbefehl an die Nachrichtenmanager in den an der Transaktion beteiligten Unterclustern und informiert dann den Kunden, dass der Durchführungsbefehl zur Umsetzung angenommen wurde. Nach Erhalt des Durchführungsbefehls aktualisieren alle Nachrichtenmanager den Nachrichtenspeicher insoweit, dass die Sendebefehle offenbart und die erhaltenen Nachrichten als geliefert betrachtet werden.
  • Die durch Knotenausfälle und Netzteilungen herbeigeführten Zustandsänderungen gefährden die Durchführung von Transaktionen. Während der Zustandsänderungen kann sich das Umfeld der Transaktionsdurchführung insoweit verändern, dass die Semantik der Nachrichtenbearbeitung im Falle einer unsachgemäßen Handhabung zum Bruch gehen kann. Dies könnte z.B. dann vorkommen, wenn der Transaktionsmanager vom Cluster/Untercluster samt Hauptmanager abgetrennt würde, wobei der letztere zum beschränkten/aufbewahrenden Hauptmanager degradiert worden wäre. Um einen Semantikbruch zu vermeiden, löst eine Zustandsänderung im beteiligten Untercluster bzw. Gesamtcluster den Transaktionsabbruch durch die an der Transaktion beteiligten Nachrichtenmanager in folgenden Fällen aus:
    • – eine Zustandsänderung hat den Übergang der den Transaktionsmanager enthaltenden Partition in den Partitionszustand D zur Folge (auch wenn D bereits gewesen wäre) oder
    • – der Transaktionsmanager ist für den/die an der Transaktion beteiligten Cluster/Untercluster nicht zugänglich, d.h. er wird beschädigt bzw. einer anderen Partition angeschlossen.
  • In allen sonstigen Fällen wird die Transaktion ab der Übergangsstelle des Clusters bis zum neuen Zustand unabgebrochen fortgesetzt.
  • In jedem Nachrichtenmanager innerhalb des Clusters werden die empfangenen und die zu sendenden Nachrichten mit einem Etikett versehen, dass sie als ein Teil der Transaktionssession gesperrt sind und noch nicht durchgeführt wurden. Die angewendeten Transaktionen verursachen keine Sperren und die den vom Transaktionsmanager erhaltenen Nachrichten auferlegten Absicherungen werden zurückgenommen, sobald eine Zustandsänderung den Transaktionsabbruch erzwungen hat. Dies bedeutet, dass die an der Transaktion beteiligten Knoten sich durch eine gewisse Wartezeit auszeichnen, welche von der unterliegenden Sendeschicht zur Erkennung von Defekten verwendet wird. Es gibt jedoch keine andere Wartezeiten, die die Transaktionsumsetzung beeinflussen könnten.
  • Sollte der Transaktionsmanager beschädigt bzw. von den Nachrichtenmanagern während der Transaktion noch vor deren Abschluss bzw. Abbruch abgetrennt werden, brechen dann alle an der Transaktion beteiligten Nachrichtenmanager nach Erhalt der Information über das Ereignis durch eine Sichtfeldzustandsänderung die Transaktion ab. In einem Beschädigungsfall des Transaktionsmanagers erhält der die Transaktion einleitende Kunde die Absage samt Mitteilung über Verbindungsausfall mit dem Transaktionsmanager und über die Transaktionsscheiterung. Dasselbe erfolgt, wenn der die Transaktion einleitende Kunde vom Transaktionsmanager getrennt wird. Die Absage wird jeweils die Transaktionssequenznummer enthalten. Bei Anwendung der Transaktionssequenznummer wird der Kunde nach einer gewissen Zeit mit einem anderen Kundenmanager verbunden und leitet erneut seine Transaktion ein, die dann anhand von neuem Transaktionsmanager erneut gestartet wird.
  • Sollte der Transaktionsmanager sofort nach Erhalt des Durchführungsbefehls vom Kunden nicht zugänglich werden, bekommt der Kunde die Absage mit der Info über den Verlust der Verbindung mit dem Transaktionsmanager – dem Kundenmanager. Der Kunde weiß dann jedoch nicht, was aus der Transaktion geworden ist, ob sie zustande gekommen ist oder nicht. Durch den Aufbau einer neuen Verbindung mit einem anderen Kundenverwalter wird der Kunde versuchen die Transaktion wieder herzustellen. Der Kunde kann die Transaktion in dieser Etappe nicht abbrechen, weil die Nachrichten in der Öffentlichkeit zugänglich sein und z.B. von anderen Kunden ausgenutzt werden könnten, soweit der frühere Durchführungsbefehl nicht umgesetzt wurde. Vorausgesetzt dem Kunden ist nicht bekannt, ob der frühere Durchführungsbefehl umgesetzt wurde, wird er es versuchen, die Transaktionsdurchführung durch den neuen Transaktionsmanager -Kundenmanager einzuleiten. Zwecks Aufrecherhaltung der semantischen Gültigkeit ist der Durchführungsablauf idempotent, demnach besteht keine Gefahr, auch wenn der frühere Durchführungsbefehl tatsächlich umgesetzt wurde und dieselbe Transaktion wieder angewiesen wird.
  • Die erneute Einleitung des Durchführungsbefehls erfolgt, indem man zuerst die Transaktion und deren auszuführenden Teil, d.h. die ab dem letzten Durchführungsbefehl gesendeten und empfangenen Nachrichten identifiziert, damit der richtige Transaktionsteil ausgeführt wird. Der Grund weshalb jeder Teil Durchführung/Abbruch der Transaktion eindeutig identifizierbar sein muss, besteht in der notwendigen Sicherstellung, dass ein erneuter Durchführungsbefehl nicht dazu führen kann, einen falschen Transaktionsteilumzusetzen.
  • Nach Erhalt eines neuen Durchführungsbefehls wird er von neuem Transaktionsmanager in einen Bereitstellungsbefehl umgewandelt, der danach den Durchführungs- bzw. Abbruchsbefehl sendet. Diese Umwandlung ist mit der zweiphasigen Transaktionsumsetzung konform. Bei positivem Bereitstellungsbefehl, d.h. wenn alle an der Transaktion beteiligten Nachrichtenmanager- die Haupt- bzw. Backupmanager – den Bereitstellungsbefehl positiv beantwortet haben, wird bekannt, dass die vorherige Durchführung erfolgreich umgesetzt wurde. Wenn dagegen der Durchführungsbefehl von den an der Transaktion beteiligten Nachrichtenmanagern negativ beantworte wurde, bedeutet es, dass die vorhergehende Durchführung nicht umgesetzt wurde und die Aktion infolge einer Zustandsänderung aufgrund Beschädigung des vorherigen Transaktionsmanagers abgebrochen wurde. Das Obige betrifft auch den Fall, wo der Transaktionsmanager nach Erhalt des Abbruchbefehls vom Kunden beschädigt wird.
  • Damit diese Szenarios erfüllt werden können, muss jeder an der Transaktion beteiligte Nachrichtenmanager – so die Haupt- wie die Backupmanager – die Sequenznummer der zuletzt durchgeführten Transaktion sowie deren Ergebnis in Bezug auf jede Transaktionssession kennen. Diese Information wird von jedem Nachrichtenmanager – so die Haupt- wie die Backupmanager – aufrechterhalten.
  • Zusammenfassend weist die Erfindung folgende Vorteile auf
    • – Das Verfahren nach der Erfindung garantiert die JMS-Semantik während der Knotenausfälle und Netzteilungen eines Clustersystems der Nachrichtenübermittlung
    • – Die Erfindung garantiert insbesondere, dass jede Nachricht höchstens einmal an die Kundenapplikation während der Knotenausfälle bzw. Netzteilungen eines Clustersystems der Nachrichtenübermittlung, ausgenommen die in der JMS-Spezifikation angeführten Fälle, geliefert wird
    • – Die Erfindung garantiert insbesondere, dass keine Nachricht während der Knotenausfälle bzw. Netzteilungen eines Clustersystems der Nachrichtenübermittlung, ausgenommen die zulässigen, in der JMS-Spezifikation angeführten Fälle, verloren geht
    • – Die Erfindung garantiert insbesondere, dass alle thematischen Nachrichten zu einem gewissen Zeitpunkt an alle Kundenapplikationen während der Knotenausfälle bzw. Netzteilungen eines Clustersystems der Nachrichtenübermittlung geliefert wird, ausgenommen die Fälle wo thematische Nachrichten noch vor der Beseitigung der Knotenausfälle bzw. Netzteilungen überfällig werden
    • – Durch die Garantierung der JMS-Semantik stellt die Erfindung gleichzeitig sicher, dass ein Clustersystem der Nachrichtenübermittlung immer erreichbar ist, um die Nachrichten von den Nachrichtenherstellern zu empfangen, wobei auch eine ordnungsgemäße Lieferung dieser Nachrichten garantiert wird, auch wenn der Cluster von Netzteilung betroffen ist. Dabei wird selbstverständlich vorausgesetzt, dass nicht alle Knoten des Clustersystems der Nachrichtenübermittlung beschädigt wurden.
  • GLOSSAR
    • – Cluster: Eine Gruppe der an mehreren Computern umzusetzenden und derart voneinander abhängigen Aktionen, dass sie sich wie ein Einzelserver der Nachrichtenübermittlung jedoch mit erhöhter Leistung und Zuverlässigkeit verhalten. Unter dem Kundengesichtspunkt entspricht ein Cluster funktionsmäßig einem monolithischen Server und demnach erscheint er für den Kunden transparent.
    • – Knoten: Logische Einzelaktion innerhalb des Clusters. Öfters entspricht ein Knoten einem Einzelcomputer, dies trifft aber nicht ganz exakt zu. Zahlreiche an einem Computer laufende Knoten werden sich gegenseitig so beeinflussen, als befänden sie sich an separaten und nur durch ein Netz verkoppelten Computern.
    • – Monolithischer Server: Ein voller Nachrichtenserver, der wie ein Einzelknoten funktioniert.
    • – Server: Allgemeiner Begriff, der einen einzelnen logischen Nachrichtenserver bedeutet. Es kann sich dabei um einen monolithischen Server bzw. um einen Cluster nach der obigen Beschreibung handeln.
    • – Kunde: Eine an einen Clusterknoten angeschlossene Anwendung zwecks Nachrichtensendung (Veröffentlichung) bzw. Nachrichtenempfang (Benutzung) vom Server.
    • – JMS: (Java Message Service) – Standardschnittstelle von Applikationen (API) für die in der Java-Sprache erstellten Programme, sie wird zwecks Zugriff an die Dienstleistungen des Nachrichtensystems eingesetzt.

Claims (11)

  1. Verfahren zum Sicherstellen des Betriebs während Knotenausfällen und Netzwerkaufteilungen in einem Nachrichtensysteme zum Übertragen von Daten in Form von Nachrichten zwischen Nachrichten-Clients, dadurch gekennzeichnet, dass das Nachrichtensystem ein Server-Cluster aufweist, das eine Gruppe von Nachrichten-Manager-Knoten (MM) mit Mitteln zum Speichern und Verteilen von Nachrichten enthält, und dass das Verfahren die Schritte aufweist: – Unterhalten eines Clusterzustand-Datensatzes, der Informationen über die in dem Cluster vorhandenen Knoten aufweist, in jedem laufenden Nachrichten-Manager-Knoten (MM), – Wiederholtes Ermitteln, in jedem laufenden Nachrichten-Manager-Knoten (MM), eines Viewzustand-Datensatzes, der Informationen über die Serverknoten enthält, die mit dem Nachrichten-Manager-Knoten kommunizieren können, – Vergleichen des Clusterzustand-Datensatzes mit dem Viewzustand-Datensatz und Ermitteln, ob alle Nachrichten-Manager (MM) mit dem Nachrichten-Manager-Knoten (MM) kommunizieren können, und mit wenigstens einem der folgenden zwei Gruppen von Schritten: – und mit wenigstens einem der folgenden zwei Gruppen von Schritten: – wobei die erste Gruppe von Schritten besteht aus: wenn nicht alle Nachrichten-Manager (m) mit dem Nachrichten-Manager-Knoten (MM) kommunizieren können, Bestimmen eines Betriebszustands für Punkt-zu-Punkt-artige Nachrichtenübermittlung aus wenigstens zwei unterschiedlichen Zuständen (A, B, C, D), wobei ein erster der wenigstens zwei unterschiedlichen Zustände ein unbeschränkter Zustand (A, B, C) für normalen Betrieb ist, wobei die Nachrichten-Manager (MM), die sich in dem unbeschränkten Zustand (A, B, C) befinden, Punkt-zu-Punkt-Nachrichten senden dürfen, die sowohl vor als auch nach der letzten Viewzustands-Änderung des laufenden Netzwerk gesendet wurden, und ein zweiter der wenigstens zwei unterschiedlichen Zustände ein beschränkter Zustand (D) ist, wobei die Nachricthen-Manager (MM), die sich in dem beschränkten Zustand (D) befinden, keine Punkt-zu-Punkt-Nachrichten senden dürfen, die nach der letzten Viewzustands-Änderung des laufenden Netzwerk gesendet wurden, und wobei der Betriebszustand in einer Weise bestimmt wird, dass von jeweils zwei Nachrichten-Manager-Knoten (MM), die für die Absendung der gleichen Punkt-zu-Punkt- Nachrichten zuständig sind und nicht miteinander kommunizieren können, sich höchstens einer in einem unbeschränkten Betriebszustand (A, B, C) befinden kann, – wobei die zweite Gruppe von Schritten besteht aus: wenn nicht alle Nachrichten-Manager (MM) mit dem Nachrichten-Manager-Knoten (MM) kommunizieren können, Bestimmen eines Betriebszustands für publish/subscribe-artige Nachrichtenübermittlung aus wenigstens zwei unterschiedlichen Zuständen (A, B, C, D), wobei ein erster der wenigstens zwei unterschiedlichen Zustände ein nicht-zurückhaltender Zustand (A) ist, wobei die Nachrichten-Manager (MM), die sich in dem nicht-zurückhaltenden Zustand (A) befinden, publish/subscribe-Nachrichten löschen dürfen, sobald bestimmt worden ist, dass alle geeigneten Subscriber Kopien jener Nachrichten erhalten haben, und ein zweiter der wenigstens zwei unterschiedlichen Zustände ein zurückhaltender Zustand (B, C, D) ist, wobei die Nachrichten-Manager (MM), die sich in dem zurückhaltenden Zustand (B, C, D) befinden, publish/subscribe-Nachrichten nicht löschen dürfen vor dem Ende der einzelnen Nachrichten oder bevor der Nachrichten-Manager (MM) zu dem nicht-zurückhaltenden Zustand (A) wechselt und feststellt, dass alle geeigneten Subscriber Kopien jener Nachrichten erhalten haben, und wobei der Betriebszustand in einer Weise bestimmt wird, dass von jeweils zwei Nachrichten-Manager-Knoten (MM), die für die Absendung der gleichen publish/subscribe-Nachrichten zuständig sind und nicht miteinander kommunizieren können, beide sich in einem zurückhaltendne Zustand (B, C, D) befinden müssen.
  2. Verfahren nach Anspruch 1, bei dem das Server-Cluster ferner eine Gruppe von Client-Manager-Knoten (CM) aufweist, wobei die Client-Manager-Knoten (CM) anders programmiert sind als die Nachrichten-Manager-Knoten (MM), und wobei jedem Nachrichten-Manager-Knoten (MM) zu allen Zeiten ein Partitionszustand aus wenigstens drei unterschiedlichen Partitionszuständen (A, C, D) zugewiesen wird, wobei einem Nachrichten-Manager (MM) ein erster Partitionszustand (A) zugewiesen wird, wenn er mit allen anderen Nachrichten-Managern (MM), die für die Absendung der gleichen Nachrichten zuständig sind, kommunizieren kann, wobei ihm ein weiterer Partitionszustand (C) zugewiesen wird, wenn er nicht mit allen anderen Nachrichten-Managern (MM), die für die Absendung der gleichen Nachrichten zuständig sind, aber mit einer Mehrzahl der Client- Manager-Knoten (CM) kommunizieren kann, und wobei ihm ansonsten ein noch weiterer Partitionszustand (D) zugewiesen wird, und wobei der Nachrichten-Manager (MM) bestimmt wird, in einem unbeschränkten Betriebszustand (A, B, C) zu sein, wenn er sich in dem ersten oder in dem weiteren Partitionszustand (A, C) befindet, und er bestimmt wird, ansonsten in einem beschränkten Betriebszustand (D) zu sein, und wobei er bestimmt wird, in einem nicht-zurückhaltenden Betriebszustand (A) zu sein, wenn er sich in dem ersten Partitionszustand befindet, uns ansonsten in einem zurückhaltenden Betriebszustand (B, C, D) zu sein.
  3. Verfahren nach Anspruch 1, bei dem das Server-Cluster ferner eine Gruppe von Client-Manager-Knoten (CM) aufweist, die functional von den Nachrichten-Manager-Knoten (MM) verschieden sind, und wobei jedem Nachrichten-Manager-Knoten (MM) zu allen Zeiten ein Partitionszustand aus wenigstens vier unterschiedlichen Partitionszuständen (A, B, C, D) zugewiesen wird, wobei einem Nachrichten-Manager (MM) ein erster Partitionszustand (A) zugewiesen wird, wenn er mit allen anderen Nachrichten-Managern (MM) des Clusters, die für die Absendung des gleichen Nachrichtensatzes zuständig sind, kommunizieren kann, wobei ihm ein zweiter Partitionszustand (B) zugewiesen wird, wenn er entweder nicht mit einem weiteren Nachrichten-Manager (MM), der für die Absendung der gleichen Art von Nachrichten zuständig ist und mit einer Mehrzahl der Client-Manager (CM) kommunizieren kann, oder wenn sein Partitionszustand vor der letzten Viewzustands-Änderung der zweite Partitionsstatus war und er noch immer nicht mit irgendeinem anderen Nachrichten-Manager kommunizieren kann, der für die Absendung der gleichen Nachrichten zuständig ist, und mit wenigstens einem Client-Manager (CM) kommunizieren kann, wobei ihm ein dritter Partitionszustand (C) zugewiesen wird, wenn er sich nicht in dem ersten Partitionszustand (A) oder dem zweiten Partitionszustand (B) befindet, und wobei wenigstens ein weiterer Nachrichten-Manager-Knoten (MM) des Clusters, der für die Absendung des gleichen Nachrichtensatzes zuständig ist, entweder mit ihm und mit einer Mehrzahl der Client-Manager-Knoten (CM) kommunizieren kann, und wobei ihm ein vierter Partitionszustand (D) zugewiesen wird, wenn er sich nicht in dem ersten, zweiten oder dritten Partitionszustand befindet mit der zusätzlichen Beschränkung, dass ihm nicht der zweite Zustand (B) oder dritte Zustand (C) zugewiesen wird, wenn er sich vor der Viewzustands-Änderung in dem vierten Zustand befand, und wobei der Nachrichten-Manager (MM) bestimmt wird, in einem unbeschränkten Betriebszustand (A, B, C) zu sein, wenn er sich in dem ersten, zweiten oder dritten Partitionszustand (A, B, C) befindet, und er bestimmt wird, ansonsten in einem beschränkten Betriebszustand (D) zu sein, und wobei er bestimmt wird, in einem nicht-zurückhaltenden Betriebszustand (A) zu sein, wenn er sich in dem ersten Partitionszustand (A) befindet, und ansonsten in einem zurückhaltenden Betriebszustand (B, C, D) zu sein.
  4. Verfahren nach Anspruch 1, bei dem den Nachriten-Manager-Knoten (MM) ein Betriebszustand für Punkt-zu-Punkt-Nachrichtenübermittlung zu allen Zeiten zugewiesen wird, zu denen das Serversystem läuft.
  5. Verfahren nach Anspruch 1, bei dem den Nachriten-Manager-Knoten (MM) ein Betriebszustand für publish/subscribe-Nachrichtenübermittlung zu allen Zeiten zugewiesen wird, zu denen das Serversystem läuft.
  6. Verfahren nach Anspruch 1, bei dem der Server-Cluster in Untercluster aufgeteilt ist, die eine Gruppe von Nachrichten-Manager-Knoten (MM) enthalten, in jedem der Verfahrensschritte einen Unterclusterzustand-Datensatz als Clusterzustand-Datensatz verwenden und in dem Schritt des Vergleichens des Unterclusterzustand-Datensatzes mit dem Viewzustand-Datensatz ermitteln, ob alle Nachriten-Manager (MM) des Unterclusters mit den Nachrichten-Manager-Knoten (MM) kommunizieren können, und – wenn nicht alle Nachrichten-Manager (MM) des Unterclusters mit den Nachrichten-Manager-Knoten (MM) kkommunizieren könne, einen Punkt-zu-Punkt-Betriebszustand von wenigstens zwei unterschiedlichen Zuständen festlegen, wobei ein erster der wenistens zwei unterschiedlichen Zustände ein unbeschränkter Zustand (A, B, C) ist, wobei die Nachrichten-Manager (MM), die sich in dem unbeschränkten Zustand (A, B, C) befinden, Punkt-zu-Punkt-Nachrichten absenden dürfen, die vor und seit der letzten Viewzustands-Änderung des laufenden Netzwerkeds gesendet wurden, und ein zweiter der wenigstens zwei unterschiedlichen Zustände ein beschränkter Zustand (D) ist, wobei die Nachrichten-Manager (MM), die sich in dem beschränkten Zustand (D) befinden, keine Punkt-zu-Punkt-Nachrichten absenden dürfen, die vor der letzten Viewzustands-Änderung des laufenden Netzwerkes gesendet wurden, und wobei der Betriebszustand in einer Weise bestimmt wird, dass von zwei Nachrichten-Manager-Knoten (MM) des gleichen Unterclusters, die nicht miteinander kommunizieren können, sich höchstens einer in einem unbeschränkten Zustand (A, B, C) befinden kann.
  7. Verfahren nach Anspruch 6, ferner aufweisend für den Fall, dass nicht alle Nachrichten-Manager (MM) des Unterclusters mit dem Nachrichten-Manager-Knoten (MM) kommunizieren können, Bestimmen eines Betriebszustands für publish/subscribe-artige Nachrichtenübermittlung aus wenigstens zwei unterschiedlichen Zuständen, wobei ein erster der wenigstens zwei unterschiedlichen Zustände ein nicht-zurückhaltender Zustand (A) für normalen Betrieb ist, wobei die Nachrichten-Manager (MM), die sich in dem nicht-zurückhaltenden Zustand (A) befinden, publish/subscribe-Nachrichten löschen dürfen, sobald bestimmt worden ist, dass alle geeigneten Subscriber Kopien jener Nachrichten erhalten haben, und ein zweiter der wenigstens zwei unterschiedlichen Zustände ein zurückhaltender Zustand (B, C, D) ist, wobei die Nachrichten-Manager (MM), die sich in dem zurückhaltenden Zustand (B, C, D) befinden, publish/subscribe-Nachrichten nicht löschen dürfen vor dem Ende der einzelnen Nachrichten oder bevor der Nachrichten-Manager (MM) zu dem nicht-zurückhaltenden Zustand (A) wechselt und feststellt, dass alle geeigneten Subscriber Kopien jener Nachrichten erhalten haben, und wobei der Betriebszustand in einer Weise bestimmt wird, dass von jeweils zwei Nachrichten-Manager-Knoten (MM) des gleichen Unterclusters, die nicht miteinander kommunizieren können, beide sich in einem zurückhaltenden Zustand (B, C, D) befinden müssen.
  8. Nachrichtensystem zum Übertragen von Daten in Form von Nachrichten zwischen Nachrichten-Clients, mit einem Server-Cluster, das eine Gruppe von Nachrichten-Manager-Knoten (MM) mit Mitteln zum Speichern und Verteilen von Nachrichten enthält zum Sicherstellen des Betriebs während Knotenausfällen und Netzwerkaufteilungen, wobei jeder Nachrichten-Manager-Knoten (MM) Mittel aufweist zum – Unterhalten eines Clusterzustand-Datensatzes, der Informationen über die in dem Cluster vorhandenen Knoten aufweist, in jedem laufenden Nachrichten-Manager-Knoten (MM), – Wiederholtes Ermitteln, in jedem laufenden Nachrichten-Manager-Knoten (MM), eines Viewzustand-Datensatzes, der Informationen über die Serverknoten enthält, die mit dem Nachrichten-Manager-Knoten kommunizieren können, – Vergleichen des Clusterzustand-Datensatzes mit dem Viewzustand-Datensatz und Ermitteln, ob alle Nachrichten-Manager (MM) mit dem Nachrichten-Manager-Knoten (MM) kommunizieren können, – wenn nicht alle Nachrichten-Manager (MM) mit dem Nachrichten-Manager-Knoten (MM) kommunizieren können, Bestimmen eines Betriebszustands für punkt-zu-punkt-artige Nachrichtenübermittlung aus wenigstens zwei unterschiedlichen Zuständen (A, B, C, D), wobei ein erster der wenigstens zwei unterschiedlichen Zustände ein unbeschränkter Zustand (A, B, C) für normalen Betrieb ist, wobei die Nachrichten-Manager (MM), die sich in dem unbeschränkten Zustand (A, B, C) befinden, Punkt-zu-Punkt-Nachrichten senden dürfen, die sowohl vor als auch nach der letzten Viewzustands-Änderung des laufenden Netzwerk gesendet wurden, und ein zweiter der wenigstens zwei unterschiedlichen Zustände ein beschränkter Zustand (D) ist, wobei die Nachrichten-Manager (MM), die sich in dem beschränkten Zustand (D) befinden, keine Punkt-zu-Punkt-Nachrichten senden dürfen, die nach der letzten Viewzustands-Änderung des laufenden Netzwerk gesendet wurden, und wobei die Mittel zum Bestimmen eines aus wenigstens zwei Zuständen derart ausgebildet sind, dass von jeweils zwei Nachrichten-Manager-Knoten (MM), die für die Absendung der gleichen Punkt-zu-Punkt-Nachrichten zuständig sind und nicht miteinander kommunizieren können, sich höchstens einer in einem unbeschränkten Betriebszustand (A, B, C) befinden kann.
  9. System nach Anspruch 8, das ferner Mittel aufweist zum Bestimmen eines Betriebszustands für publish/subscribe-artige Nachrichtenübermittlung aus wenigstens zwei unterschiedlichen Zuständen (A, B, C, D), wenn nicht alle Nachrichten-Manager (MM) mit dem Nachrichten-Manager-Knoten (MM) kommunizieren können, wobei ein erster der wenigstens zwei unterschiedlichen Zustände ein nicht-zurückhaltender Zustand (A) für normalen Betrieb ist, wobei die Nachrichten-Manager (MM), die sich in dem nicht-zurückhaltenden Zustand (A) befinden, publish/subscribe-Nachrichten löschen dürfen, sobald bestimmt worden ist, dass alle geeigneten Subscriber Kopien jener Nachrichten erhalten haben, und ein zweiter der wenigstens zwei unterschiedlichen Zustände ein zurückhaltender Zustand (B, C, D) ist, wobei die Nachrichten-Manager (MM), die sich in dem zurückhaltenden Zustand (B, C, D) befinden, publish/subscribe-Nachrichten nicht löschen dürfen vor dem Ende der einzelnen Nachrichten oder bevor der Nachrichten-Manager (MM) zu dem nicht-zurückhaltenden Zustand (A) wechselt und feststellt, dass alle geeigneten Subscriber Kopien jener Nachrichten erhalten haben, und wobei die Mittel zum Bestimmen eines Betriebszustands derart programmiert sind, dass von jeweils zwei Nachrichten-Manager-Knoten (MM), die für die Absendung der gleichen publish/subscripe-Nachrichten zuständig sind und nicht miteinander kommunizieren können, beide sich in einem zurückhaltenden Zustand (B, C, D) befinden müssen.
  10. Computerprogrammprodukt mit einem computerverwendbaren Medium, in dem computerlesbare Programmcodemittel enthalten sind, um es einem Computer zu ermöglichen, als Nachrichten-Manager (MM) in einem Server-Cluster zu dienen, wobei das Programmprodukt computerlesbare Codemittel aufweist, um es dem Computer zu ermöglichen, – einen Clusterzustand-Datensatz zu unterhalten, der Informationen über die in dem Cluster vorhandenen Knoten aufweist, in jedem laufenden Nachrichten-Manager-Knoten (MM), – in jedem laufenden Nachrichten-Manager-Knoten (MM), einen Viewzustand-Datensatz wiederholt zu ermitteln, der Informationen über die Serverknoten enthält, die mit dem Nachrichten-Manager-Knoten kommunizieren können, – den Clusterzustand-Datensatz mit dem Viewzustand-Datensatz zu vergleichen und zu ermitteln, ob alle Nachrichten-Manager (MM) mit dem Nachrichten-Manager-Knoten (MM) kommunizieren können, – wenn nicht alle Nachrichten-Manager (MM) mit dem Nachrichten-Manager-Knoten (MM) kommunizieren können, einen Betriebszustand für punkt-zu-punkt-artige Nachrichtenübermittlung aus wenigstens zwei unterschiedlichen Zuständen (A, B, C, D) zu bestimmen, wobei ein erster der wenigstens zwei unterschiedlichen Zustände ein unbeschränkter Zustand (A, B, C) für normalen Betrieb ist, wobei die Nachrichten-Manager (MM), die sich in dem unbeschränkten Zustand (A, B, C) befinden, Punkt-zu-Punkt-Nachrichten senden dürfen, die sowohl vor als auch nach der letzten Viewzustands-Änderung des laufenden Netzwerk gesendet wurden, und ein zweiter der wenigstens zwei unterschiedlichen Zustände ein beschränkter Zustand (D) ist, wobei die Nachrichten-Manager (MM), die sich in dem beschränkten Zustand (D) befinden, keine Punkt-zu-Punkt-Nachrichten senden dürfen, die nach der letzten Viewzustands-Änderung des laufenden Netzwerk gesendet wurden, und wobei die Mittel zum Bestimmen eines Betriebszustand in einer Weise programmiert sind, dass von jeweils zwei Nachrichten-Manager-Knoten (MM), die für die Absendung der gleichen Punkt-zu-Punkt-Nachrichten zuständig sind und nicht miteinander kommunizieren können, sich höchstens einer sich in einem unbeschränkten Betriebszustand (A, B, C) befinden kann.
  11. Computerprogrammprodukt nach Anspruch 10, wobei die computerlesbaren Codemittel Mittel, die eine Bibliothek einsetzen, die in der Java-Sprache geschrieben ist und mit dem Java Message Service API konform ist.
DE60207251T 2001-07-05 2002-06-10 Verfahren zur sicherstellung des betriebs eines gruppierten nachrichtenvergebenden servers während knotenausfällen und netzwerkzuteilungen Expired - Fee Related DE60207251T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US899662 2001-07-05
US09/899,662 US6877107B2 (en) 2001-07-05 2001-07-05 Method for ensuring operation during node failures and network partitions in a clustered message passing server
PCT/CH2002/000304 WO2003005194A2 (en) 2001-07-05 2002-06-10 Method for ensuring operation during node failures and network partitions in a clustered message passing server

Publications (2)

Publication Number Publication Date
DE60207251D1 DE60207251D1 (de) 2005-12-15
DE60207251T2 true DE60207251T2 (de) 2007-05-16

Family

ID=25411353

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60207251T Expired - Fee Related DE60207251T2 (de) 2001-07-05 2002-06-10 Verfahren zur sicherstellung des betriebs eines gruppierten nachrichtenvergebenden servers während knotenausfällen und netzwerkzuteilungen

Country Status (6)

Country Link
US (1) US6877107B2 (de)
EP (1) EP1402363B1 (de)
CN (1) CN1552020A (de)
AT (1) ATE309571T1 (de)
DE (1) DE60207251T2 (de)
WO (1) WO2003005194A2 (de)

Families Citing this family (126)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7177917B2 (en) 2000-12-27 2007-02-13 Softwired Ag Scaleable message system
US7305450B2 (en) * 2001-03-29 2007-12-04 Nokia Corporation Method and apparatus for clustered SSL accelerator
US7685126B2 (en) * 2001-08-03 2010-03-23 Isilon Systems, Inc. System and methods for providing a distributed file system utilizing metadata to track information about data stored throughout the system
US7146524B2 (en) * 2001-08-03 2006-12-05 Isilon Systems, Inc. Systems and methods for providing a distributed file system incorporating a virtual hot spare
US7113980B2 (en) * 2001-09-06 2006-09-26 Bea Systems, Inc. Exactly once JMS communication
US20030088659A1 (en) * 2001-11-08 2003-05-08 Susarla Hanumantha Rao System and method for distributed state management
US20030115366A1 (en) * 2001-12-18 2003-06-19 Robinson Brian R. Asynchronous message delivery system and method
US7181489B2 (en) * 2002-01-10 2007-02-20 International Business Machines Corporation Method, apparatus, and program for distributing a document object model in a web server cluster
US7369808B2 (en) 2002-02-07 2008-05-06 Sap Aktiengesellschaft Instructional architecture for collaborative e-learning
US20030157470A1 (en) * 2002-02-11 2003-08-21 Michael Altenhofen E-learning station and interface
US20030152905A1 (en) * 2002-02-11 2003-08-14 Michael Altenhofen E-learning system
WO2003073311A1 (en) * 2002-02-21 2003-09-04 Bea Systems, Inc. System and method for message driven bean service migration
US7155438B2 (en) * 2002-05-01 2006-12-26 Bea Systems, Inc. High availability for event forwarding
US7222148B2 (en) * 2002-05-02 2007-05-22 Bea Systems, Inc. System and method for providing highly available processing of asynchronous service requests
US20040044892A1 (en) * 2002-09-03 2004-03-04 Elmar Dorner Content based messaging for e-learning
US7937421B2 (en) 2002-11-14 2011-05-03 Emc Corporation Systems and methods for restriping files in a distributed file system
US20040205770A1 (en) * 2003-02-11 2004-10-14 International Business Machines Corporation Duplicate message elimination system for a message broker
US7676580B2 (en) 2003-03-27 2010-03-09 Microsoft Corporation Message delivery with configurable assurances and features between two endpoints
US7702729B2 (en) * 2003-04-08 2010-04-20 Johanson Bradley E Event heap: a coordination infrastructure for dynamic heterogeneous application interactions in ubiquitous computing environments
US7526549B2 (en) * 2003-07-24 2009-04-28 International Business Machines Corporation Cluster data port services for clustered computer system
US7739541B1 (en) * 2003-07-25 2010-06-15 Symantec Operating Corporation System and method for resolving cluster partitions in out-of-band storage virtualization environments
US7644118B2 (en) 2003-09-11 2010-01-05 International Business Machines Corporation Methods, systems, and media to enhance persistence of a message
US20050071848A1 (en) * 2003-09-29 2005-03-31 Ellen Kempin Automatic registration and deregistration of message queues
US7287066B2 (en) * 2003-10-31 2007-10-23 Sap Aktiengesellschaft Publish-subscribe system having a reliability mechanism
US20050097343A1 (en) * 2003-10-31 2005-05-05 Michael Altenhofen Secure user-specific application versions
US7478400B1 (en) * 2003-12-31 2009-01-13 Symantec Operating Corporation Efficient distributed transaction protocol for a distributed file sharing system
US20050210152A1 (en) * 2004-03-17 2005-09-22 Microsoft Corporation Providing availability information using a distributed cache arrangement and updating the caches using peer-to-peer synchronization strategies
US7272634B2 (en) * 2004-03-18 2007-09-18 Sony Corporation System and method for integrating multiple messaging systems
US20050216506A1 (en) * 2004-03-25 2005-09-29 Wolfgang Theilmann Versioning electronic learning objects using project objects
CN1331042C (zh) * 2004-03-29 2007-08-08 联想(北京)有限公司 用于机群监控系统控制台的消息服务装置及其方法
US7664818B2 (en) * 2004-04-21 2010-02-16 Sap (Ag) Message-oriented middleware provider having multiple server instances integrated into a clustered application server infrastructure
US7512668B2 (en) * 2004-04-21 2009-03-31 Sap Ag Message-oriented middleware server instance failover
US7634550B2 (en) * 2004-04-21 2009-12-15 Sap Ag Message-oriented middleware provider having multiple server instances
US7983173B2 (en) * 2004-05-10 2011-07-19 Cisco Technology, Inc. System and method for detecting link failures
US7334154B2 (en) * 2004-06-18 2008-02-19 Microsoft Corporation Efficient changing of replica sets in distributed fault-tolerant computing system
US20060008789A1 (en) * 2004-07-07 2006-01-12 Wolfgang Gerteis E-learning course extractor
US8898246B2 (en) * 2004-07-29 2014-11-25 Hewlett-Packard Development Company, L.P. Communication among partitioned devices
US20080201403A1 (en) * 2004-09-29 2008-08-21 Telefonaktiebolaget Lm Ericsson (Publ) Maintaning a View of a Cluster's Membership
WO2006035266A1 (en) * 2004-09-29 2006-04-06 Telefonaktiebolaget L M Ericsson (Publ) Installing a new view of a cluster membership
US8055711B2 (en) 2004-10-29 2011-11-08 Emc Corporation Non-blocking commit protocol systems and methods
US8051425B2 (en) * 2004-10-29 2011-11-01 Emc Corporation Distributed system with asynchronous execution systems and methods
US8238350B2 (en) 2004-10-29 2012-08-07 Emc Corporation Message batching with checkpoints systems and methods
US7689655B2 (en) * 2004-12-06 2010-03-30 Aol Inc. Managing and collaborating with digital content using a dynamic user interface
JP2006260325A (ja) * 2005-03-18 2006-09-28 Fujitsu Ltd 障害の伝達方法
US8191078B1 (en) * 2005-03-22 2012-05-29 Progress Software Corporation Fault-tolerant messaging system and methods
US7747894B2 (en) * 2005-06-06 2010-06-29 Microsoft Corporation Transport-neutral in-order delivery in a distributed system
US8051433B1 (en) * 2005-09-20 2011-11-01 Savi Technology, Inc. Partially ordered queue for efficient processing of assets
US8200563B2 (en) * 2005-09-23 2012-06-12 Chicago Mercantile Exchange Inc. Publish and subscribe system including buffer
US7551572B2 (en) * 2005-10-21 2009-06-23 Isilon Systems, Inc. Systems and methods for providing variable protection
US7917474B2 (en) * 2005-10-21 2011-03-29 Isilon Systems, Inc. Systems and methods for accessing and updating distributed data
US7788303B2 (en) 2005-10-21 2010-08-31 Isilon Systems, Inc. Systems and methods for distributed system scanning
US7797283B2 (en) 2005-10-21 2010-09-14 Isilon Systems, Inc. Systems and methods for maintaining distributed data
US8077699B2 (en) * 2005-11-07 2011-12-13 Microsoft Corporation Independent message stores and message transport agents
US7739391B2 (en) * 2006-02-16 2010-06-15 Softwired Ag Gateway for wireless mobile clients
US7512408B2 (en) * 2006-02-16 2009-03-31 Softwired Ag Scalable wireless messaging system
US7848261B2 (en) * 2006-02-17 2010-12-07 Isilon Systems, Inc. Systems and methods for providing a quiescing protocol
JP5068023B2 (ja) * 2006-03-29 2012-11-07 株式会社日立製作所 計算機システム及び論理パス切替方法
US7756898B2 (en) 2006-03-31 2010-07-13 Isilon Systems, Inc. Systems and methods for notifying listeners of events
US8745503B2 (en) * 2006-04-20 2014-06-03 Hewlett-Packard Development Company, L.P. Graphical interface for managing server environment
GB0609997D0 (en) * 2006-05-19 2006-06-28 Ibm Method, apparatus and computer program for controlling retention of data messages
US20080005291A1 (en) * 2006-06-01 2008-01-03 International Business Machines Corporation Coordinated information dispersion in a distributed computing system
US7526543B2 (en) * 2006-07-24 2009-04-28 Raytheon Company Method of synchronizing execution of state transition commands in a cluster of message oriented middleware servers
US7680842B2 (en) * 2006-08-18 2010-03-16 Isilon Systems, Inc. Systems and methods for a snapshot of data
US7882071B2 (en) * 2006-08-18 2011-02-01 Isilon Systems, Inc. Systems and methods for a snapshot of data
US7899800B2 (en) * 2006-08-18 2011-03-01 Isilon Systems, Inc. Systems and methods for providing nonlinear journaling
US7680836B2 (en) * 2006-08-18 2010-03-16 Isilon Systems, Inc. Systems and methods for a snapshot of data
US7590652B2 (en) * 2006-08-18 2009-09-15 Isilon Systems, Inc. Systems and methods of reverse lookup
US7953704B2 (en) 2006-08-18 2011-05-31 Emc Corporation Systems and methods for a snapshot of data
US7822932B2 (en) * 2006-08-18 2010-10-26 Isilon Systems, Inc. Systems and methods for providing nonlinear journaling
US7770063B2 (en) * 2006-08-26 2010-08-03 International Business Machines Corporation Simulation of failure recovery within clustered systems
US8286029B2 (en) 2006-12-21 2012-10-09 Emc Corporation Systems and methods for managing unavailable storage devices
US7593938B2 (en) * 2006-12-22 2009-09-22 Isilon Systems, Inc. Systems and methods of directory entry encodings
US7509448B2 (en) * 2007-01-05 2009-03-24 Isilon Systems, Inc. Systems and methods for managing semantic locks
US7900015B2 (en) 2007-04-13 2011-03-01 Isilon Systems, Inc. Systems and methods of quota accounting
US20080255773A1 (en) * 2007-04-13 2008-10-16 Chao Yuan Machine condition monitoring using pattern rules
US7779048B2 (en) 2007-04-13 2010-08-17 Isilon Systems, Inc. Systems and methods of providing possible value ranges
US8966080B2 (en) 2007-04-13 2015-02-24 Emc Corporation Systems and methods of managing resource utilization on a threaded computer system
US8094669B2 (en) * 2007-04-24 2012-01-10 Oracle International Corporation System and method for store and forward routing for distributed destinations
US7877553B2 (en) * 2007-08-06 2011-01-25 Microsoft Corporation Sharing volume data via shadow copies using differential areas
US7882068B2 (en) 2007-08-21 2011-02-01 Isilon Systems, Inc. Systems and methods for adaptive copy on write
US7966289B2 (en) 2007-08-21 2011-06-21 Emc Corporation Systems and methods for reading objects in a file system
US7949692B2 (en) * 2007-08-21 2011-05-24 Emc Corporation Systems and methods for portals into snapshot data
US7856573B2 (en) * 2007-08-31 2010-12-21 International Business Machines Corporation WPAR halted attack introspection stack execution detection
US8954562B2 (en) * 2007-09-28 2015-02-10 Intel Corporation Entropy-based (self-organizing) stability management
US7996510B2 (en) * 2007-09-28 2011-08-09 Intel Corporation Virtual clustering for scalable network control and management
US8200836B2 (en) * 2007-11-16 2012-06-12 Microsoft Corporation Durable exactly once message delivery at scale
US8214847B2 (en) * 2007-11-16 2012-07-03 Microsoft Corporation Distributed messaging system with configurable assurances
US7870345B2 (en) 2008-03-27 2011-01-11 Isilon Systems, Inc. Systems and methods for managing stalled storage devices
US7949636B2 (en) 2008-03-27 2011-05-24 Emc Corporation Systems and methods for a read only mode for a portion of a storage system
US7984324B2 (en) * 2008-03-27 2011-07-19 Emc Corporation Systems and methods for managing stalled storage devices
US7953709B2 (en) * 2008-03-27 2011-05-31 Emc Corporation Systems and methods for a read only mode for a portion of a storage system
US9483911B2 (en) 2008-04-30 2016-11-01 Bally Gaming, Inc. Information distribution in gaming networks
US7543046B1 (en) * 2008-05-30 2009-06-02 International Business Machines Corporation Method for managing cluster node-specific quorum roles
WO2010006187A2 (en) * 2008-07-11 2010-01-14 Bally Gaming, Inc. Integration gateway
CN101668031B (zh) * 2008-09-02 2013-10-16 阿里巴巴集团控股有限公司 一种消息处理方法及系统
US8060773B1 (en) * 2009-12-16 2011-11-15 Symantec Corporation Systems and methods for managing sub-clusters within a multi-cluster computing system subsequent to a network-partition event
US8671306B2 (en) * 2010-12-21 2014-03-11 Microsoft Corporation Scaling out a messaging system
CN102137032B (zh) * 2011-03-24 2015-03-11 上海云高软件科技有限公司 一种云消息系统及云消息发送和接收方法
JP5579650B2 (ja) * 2011-04-28 2014-08-27 インターナショナル・ビジネス・マシーンズ・コーポレーション 監視対象プロセスを実行する装置及び方法
CN103178984B (zh) * 2011-12-26 2016-03-23 中国电信股份有限公司 一种通信设备及其异常处理方法
US8974305B2 (en) 2012-01-18 2015-03-10 Bally Gaming, Inc. Network gaming architecture, gaming systems, and related methods
AU2013245651B2 (en) * 2012-04-13 2016-06-16 Goldman Sachs & Co. LLC Systems and methods for scalable structured data distribution
US8990375B2 (en) 2012-08-31 2015-03-24 Facebook, Inc. Subscription groups in publish-subscribe system
EP2722345B1 (de) 2012-10-18 2018-12-05 Borealis AG Olefinpolymerisationskatalysator
EP2722346A1 (de) 2012-10-18 2014-04-23 Borealis AG Polymerisationsverfahren und Katalysator
EP2722344B1 (de) 2012-10-18 2017-03-22 Borealis AG Polymerisationsverfahren
US9189510B2 (en) 2013-02-26 2015-11-17 Facebook, Inc. System and method for implementing cache consistent regional clusters
US9419854B1 (en) * 2013-06-27 2016-08-16 The Boeing Company Methods and systems for shared awareness through local observations and global state consistency in distributed and decentralized systems
EP2829558B1 (de) 2013-07-24 2016-12-14 Borealis AG Verfahren
ES2607378T3 (es) 2013-07-24 2017-03-31 Borealis Ag Proceso
US9450992B2 (en) * 2013-10-23 2016-09-20 Facebook, Inc. Node properties in a social-networking system
US10044835B1 (en) 2013-12-11 2018-08-07 Symantec Corporation Reducing redundant transmissions by polling clients
FR3029643B1 (fr) * 2014-12-09 2017-01-13 ISKn Procede de localisation d'au moins un objet magnetique mobile, et systeme associe
CN104994168B (zh) * 2015-07-14 2018-05-01 苏州科达科技股份有限公司 分布式存储方法及分布式存储系统
CN105243012A (zh) * 2015-09-11 2016-01-13 浪潮电子信息产业股份有限公司 一种基于linux的集群网络性能评估方法
US9860311B1 (en) * 2015-09-17 2018-01-02 EMC IP Holding Company LLC Cluster management of distributed applications
US10210027B1 (en) 2015-09-17 2019-02-19 EMC IP Holding Company LLC Cluster management
US11157517B2 (en) * 2016-04-18 2021-10-26 Amazon Technologies, Inc. Versioned hierarchical data structures in a distributed data store
US10671639B1 (en) 2017-03-30 2020-06-02 Amazon Technologies, Inc. Selectively replicating changes to hierarchial data structures
EP3728342A1 (de) 2017-12-21 2020-10-28 Borealis AG Verfahren zur herstellung eines festen katalysators
JP2021508756A (ja) 2017-12-28 2021-03-11 ボレアリス エージー 触媒及びその調製
CN110502342B (zh) * 2019-08-16 2023-07-18 中科边缘智慧信息科技（苏州）有限公司 一种间歇网络环境下机动边缘信息服务网络
US10901820B1 (en) 2020-01-07 2021-01-26 International Business Machines Corporation Error state message management
CN111708668B (zh) * 2020-05-29 2023-07-07 北京金山云网络技术有限公司 集群故障的处理方法、装置及电子设备
CN112598052A (zh) * 2020-12-21 2021-04-02 中建八局第二建设有限公司 一种基于K-Means的机械姿态分析方法及系统
CN115379401A (zh) * 2022-08-05 2022-11-22 中国银行股份有限公司 一种异步银行消息的处理方法和装置

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5913061A (en) 1997-01-08 1999-06-15 Crossroads Software, Inc. Modular application collaboration
US6449734B1 (en) * 1998-04-17 2002-09-10 Microsoft Corporation Method and system for discarding locally committed transactions to ensure consistency in a server cluster
US6785678B2 (en) * 2000-12-21 2004-08-31 Emc Corporation Method of improving the availability of a computer clustering system through the use of a network medium link state function

Also Published As

Publication number Publication date
WO2003005194A2 (en) 2003-01-16
CN1552020A (zh) 2004-12-01
ATE309571T1 (de) 2005-11-15
US20030009511A1 (en) 2003-01-09
EP1402363B1 (de) 2005-11-09
EP1402363A2 (de) 2004-03-31
DE60207251D1 (de) 2005-12-15
WO2003005194A3 (en) 2003-12-11
US6877107B2 (en) 2005-04-05

Similar Documents

Publication Publication Date Title
DE60207251T2 (de) Verfahren zur sicherstellung des betriebs eines gruppierten nachrichtenvergebenden servers während knotenausfällen und netzwerkzuteilungen
DE69811148T2 (de) Mitgliedschaft in einem unzuverlässigen verteilten Rechnersystem
DE60312746T2 (de) Wiederherstellung nach fehlern in datenverarbeitungsanlagen
DE60030397T2 (de) Belastungsverteilung in einem Netzwerk
DE60013658T2 (de) Fehlertolerante virtuelle Javamaschine
DE10123067B4 (de) Synchrone Vervielfältigung von Transaktionen in einem verteilten System
DE69629630T2 (de) Struktur zur Gruppenzugehörigkeitsverwaltung in einem Mehrfachrechnersystem
DE69918467T2 (de) Servervorrichtung und Verfahren deren Verwendung
DE69923621T2 (de) Verfahren und Vorrichtung zu korrekten und vollständigen Übertragungen in einem fehlertoleranten verteilten Datenbanksystem
DE19836347C2 (de) Fehlertolerantes Computersystem
DE102005053727B4 (de) Verteilte Verriegelung
DE10134492B4 (de) Ausfallübernahme des Dateimanagementsystems in einem Rechnercluster
US10938662B2 (en) System and/or method for maintaining highly-available, consistent, partition-tolerant clusters using client voters
DE69832096T2 (de) Netzwerkverwaltung
EP0607493B1 (de) Realzeit-Steuerungssystem
EP0635784B1 (de) Multiprozessorsystem
DE69838506T2 (de) Verfahren für transaktionen zwischen verteilten datenbanken
Jiménez-Peris et al. Non-intrusive, parallel recovery of replicated data
DE112020005786T5 (de) Systeme und verfahren zum ermöglichen eines hochverfügbaren verwalteten ausfallsicherungsdienstes
EP1959639B1 (de) Ausfallsicheres System zum Verwalten von Client-Server-Kommunikation
WO2006040139A1 (de) Serverlose replikation von datenbanken
EP1231537A1 (de) Automatische Inbetriebnahme eines Clustersystems nach einem heilbaren Fehler
EP3152660A1 (de) Verfahren zur verteilung von tasks zwischen computersystemen, computernetz-infrastruktur sowie computerprogramm-produkt
DE19918896A1 (de) Logisches Netzwerksystem
EP1798892A1 (de) Verfahren zum Laden einer Liste von Alarmen durch eine Alarmapplikation

Legal Events

Date Code Title Description
8332 No legal effect for de
8370 Indication related to discontinuation of the patent is to be deleted
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee