DE69733266T2

DE69733266T2 - Ausfallsicheres und ereignisgesteuertes transaktions-system und verfahren

Info

Publication number: DE69733266T2
Application number: DE69733266T
Authority: DE
Inventors: A. Kevin KEARNS; R. Teresa JAHANIAN; E. Raymond JEFFREY
Original assignee: Electronic Data Systems LLC
Current assignee: Hewlett Packard Development Co LP
Priority date: 1996-10-29
Filing date: 1997-10-29
Publication date: 2006-01-19
Also published as: DE69733266D1; DE69733266T8; AU5195998A; CN1244268A; HK1024760A1; US5805798A; WO1998019262A1; CA2270112C; ATE295574T1; EP0935786A1; EP0935786B1; CN1187700C; AU718006B2; CA2270112A1

Description

Technisches Fachgebiet der Erfindung
Die vorliegende Erfindung bezieht sich allgemein auf das Gebiet der Computersysteme. Insbesondere bezieht sich die Erfindung auf ein ausfallsicheres, Ereignis-gesteuertes System und Verfahren der Transaktionsverarbeitung.
Bezugs-Patentanmeldungen
Die vorliegende Patentanmeldung steht in Beziehung zu US-Patent Nr. 5,964,831 mit dem Titel „Verteiltes Online-Datenkommunikationssystem und Verfahren„, veröffentlicht am 12. Oktober 1999.
Hintergrund der Erfindung
1 ist ein vereinfachtes Blockdiagramm eines herkömmlichen elektronischen Geld- und Informationsübertragungssystems (EFIT) 10 unter Verwendung eines herkömmlichen zentralisierten Kommunikationssystems 11, das es einer Anzahl von Anwendungsprogrammen 12 erlaubt, mit äußeren Vorrichtungen 14 zu kommunizieren, die davon entfernt sind. Äußere Vorrichtungen 13 können zum Beispiel eine oder mehrere automatisierte Geldautomaten (ATMs) 14 und Finanzinstitutionen 15 in einem elektronischen Geld- und Informa tionsübertragungssystem (EFIT) einschließen, das über ein zentralisiertes Kommunikationssystem 11 mit einem Weiterleitungsanwendungsprogramm 16, einem Vorrichtungshandlerprogramm 17 und einem Geldübertragungs-Autorisierungsprogramm (AUTH) 18 verbunden ist. Das zentralisierte Kommunikationssystem 11 kann auch mit einem Journalprogramm und einer Datenbank 19 zum Protokollieren jeder Transaktion und einem Host-Schnittstellenprozess 20 zum Kommunizieren mit den Finanzinstitutionen 15 gekoppelt sein.
In Betrieb, wenn zum Beispiel eine Transaktionsbotschaft über eine Bargeldentnahme an einem Geldautomaten 14 erzeugt wird, gelangt sie zu dem zentralisierten Kommunikationssystem 11, welches die Transaktionsbotschaft zu dem Vorrichtungshandlerprogramm 17 sendet. Das Vorrichtungshandlerprogramm 17 extrahiert dann die Information aus der Transaktionsbotschaft und baut eine Botschaft mit einem vorbestimmten inneren Format auf, das von dem Anwendungsprogramm 12 und von dem zentralisierten Kommunikationssystem 11 verstanden wird. Diese neu formatierte Botschaft wird dann zu dem zentralisierten Kommunikationssystem 11 zurückgesendet, welches dann die Botschaft zu einem Leitwegprogramm 16 weiterleitet. Das Leitwegprogramm 16 bestimmt das Ziel für die Botschaft und sendet sie zu dem zentralisierten Kommunikationssystem 11 für die Auslieferung an das Ziel. Das Ziel kann ein Autorisierungsprogramm 18 sein, das auf eine Datenbank 21 zugreifen kann, um zu bestimmen, ob die Transaktion autorisiert ist. Die in der Rückkehrbotschaft enthaltene Autorisierung wird dann zu dem zentralisierten Kommunikationssystem 11 für die Lieferung zu dem Journal 19 gesendet, um die Transaktion aufzuzeichnen und sie wird dann, wiederum über das zentralisierte Kommunikationssystem 11 zu dem Vorrichtungshandlerprogramm 17 zurückgeleitet. Das Vorrichtungshandlerprogramm 17 wandelt dann die Autorisierungsbotschaft in ein äußeres Format um und leitet sie zu dem Geldautomaten, von dem die Transaktion über das zentralisierte Kommunikationssystem 11 ausgelöst wurde. Der Geldautomat 14 gibt dann je nach der in der Autorisierungsbotschaft enthaltenen Informati on den angeforderten Geldbetrag frei oder verweigert die Transaktion.
Wenn gefordert ist, dass eine Transaktion von einer Finanzinstitution 15 zu autorisieren ist, würde das Autorisierungsprogramm 18 die Transaktionsbotschaft über das zentralisierte Kommunikationssystem 11 zu dem Schnittstellenprogramm 20 senden. Das Schnittstellenprogramm 20 formatiert dann die Botschaft in eine, die von dem Autorisierungssystem bei der Finanzinstitution 15 verstanden wird und sendet die neu formatierte Botschaft zu dem zentralisierten Kommunikationssystem 11 für die Lieferung zu der Ziel-Finanzinstitution zur Autorisierung. Die Finanzinstitution erzeugt dann eine Autorisierungsbotschaft und sendet sie zu dem zentralisierten Kommunikationssystem 11, welches sie an das Schnittstellenprogramm 20 zur Rückwandlung in das innere Format weiterleitet, das von den Anwendungsprogrammen 12 und von dem zentralisierten Kommunikationssystem 11 verstanden wird. Die umformatierte Autorisierungsbotschaft wird dann über das zentralisierte Kommunikationssystem 11 an das Vorrichtungshandlerprogramm 17 geleitet, welches dann die Botschaft in das äußere Format umwandelt, wie es vorher beschrieben ist, um die Autorisierungsbotschaft dem Geldautomaten zur Verfügung zu stellen, der die Transaktion ausgelöst hat.
Aus den vorhergehenden Ausführungen ist ersichtlich, dass alle Botschaften zwischen den Anwendungsprogrammen 12 und den äußeren Vorrichtungen 13 über das zentralisierte Kommunikationssystem 11 laufen müssen, welche die zentrale Steuerungseinrichtung ist. Da das elektronische Geld- und Informationsübertragungssystem größer und größer wird und immer mehr Geldautomaten und Finanzinstitutionen aufnehmen muss, wird das zentralisierte Kommunikationssystem 11 zu einem Engpass, welches die Ablieferung der Botschaft und die Reaktionszeit der Transaktion verlangsamt. Das ist ein kritisches Problem, weil Transaktionen dieser Art normalerweise eine fast sofortige Reaktionszeit erfordern. Bankkunden möchten nicht länger als dreißig Sekunden nach ihren Bargeldabhebungsforderungen auf die Reaktion des Geldautomaten warten. Weil weiterhin die gesamte Kommunikation über das zentralisierte Kommunikationssystem 11 laufen muss, also über eine einzige Stelle, würde ein Ausfall des Systems 11 für das gesamte elektronische Geld- und Informationsübertragungssystem katastrophal sein und alle Geldautomaten in dem System außer Betrieb setzen.
Das zentralisierte Kommunikationssystem 11 hat einen weiteren Nachteil, weil es das Format der Botschaft erkennen muss, um für Weiterleitungszwecke das Ziel der Botschaft zu bestimmen. Daher kann das Format der Botschaft nicht einfach gewechselt werden, ohne sich auf die Hauptfunktionen des Systems 11 auszuwirken.
Der zentralisierte Aufbau des Systems bedeutet weiterhin, dass sein Wachstum durch die Kapazität des Systems 11 begrenzt ist. Das System kann ohne das teure Hinzufügen von Rechnerplattformen und anderen Hardwarekomponenten nicht einfach erweitert werden, um eine Größenordnung mehr Benutzer aufzunehmen. In der Computerindustrie wird dieses Merkmal der Erweiterbarkeit als „Skalierbarkeit„ bezeichnet. Weiterhin ist ein zentralisiertes System, wie das System 11, nicht auf andere Rechnerplattformen übertragbar, so dass seine Verwendung auf eine einzige Plattform begrenzt ist.
WO 96/27157 A1 offenbart ein Transaktionssystem, bei dem eine Anzahl von Servern eine verteilte Verarbeitung von Transaktionen durchführt. Bei einem Ausfall führt das System eine Wiederherstellungsprozedur durch. Der Server, in dem ein Ausfall aufgetreten ist, erhält, nachdem er nach dem Ausfall wiederhergestellt ist, Journaldaten, die sich auf die ausgefallene Transaktion beziehen, aus dem Journal des Servers und aktualisiert seine eigene Datenbank auf der Basis der Journaldaten. Diese Bezugsquelle liefert nicht die Fähigkeit für seinen Anwendungsprozess, mit anderen Anwendungsprozessen zu kommunizieren. Was allein bleibt, ist seine eigene Sicht der anderen Anwendungsprozesse, mit denen er kommuniziert. Die durchgeführte Kommunikation besteht lediglich darin, die Ressourcen, die über das System verteilt sind, zu aktualisieren.
EP-A-0 652 519 offenbart ein System und ein Verfahren für das Überwachen von Datenstromverbindungen in einem parallelen Servernetzwerk, das aus vielen Arbeitsstationen zusammengesetzt ist. Ein Überwachungsprozess sammelt regelmäßig Statusinformationen von den anderen Arbeitsstationen und fasst sie zu einer Statustabelle zusammen. Die Arbeitsstationen der vorliegenden Bezugsquelle verstehen jedoch nicht den Status der anderen Arbeitsstationen in dem Netzwerk. Die erzeugte Statustabelle wird nur an der koordinierenden Arbeitsstation erhalten und nicht an den untergeordneten Arbeitsstationen. Somit verstehen die untergeordneten Arbeitsstationen nicht den Status der anderen Arbeitsstationen.
Zusammenfassung der Erfindung
Es besteht daher ein Bedarf für ein Ereignis-gesteuertes Transaktionsverarbeitungssystem, welches die Nachteile überwindet, die mit dem System verbunden sind, das auf dem vorher beschriebenen zentralisierten Kommunikationssystem basiert.
Somit bezieht sich die Erfindung auf ein ausfallsicheres, Ereignisgesteuertes Transaktionsverarbeitungssystem, wie es in Anspruch 1 beansprucht ist und auf ein Verfahren zum Betreiben eines solchen Systems, wie es in Anspruch 13 beansprucht ist.
Kurzbeschreibung der Zeichnungen
Zum besseren Verständnis der vorliegenden Erfindung wird Bezug auf die beigefügten Zeichnungen genommen, die zeigen in
1 ein vereinfachtes Blockdiagramm eines herkömmlichen elektronischen Online-Kommunikationssystems unter Verwendung eines zentralisierten Kommunikationssystems;
2 eine vereinfachte Blockdiagrammdarstellung eines verteilten Online-Datenkommunikationssystems, aufgebaut gemäß den Merkmalen der vorliegenden Erfindung;
3 ein Blockdiagramm eines Beispiels der äußeren Schnittstellen des Systemmonitors mit einem Steuerpunkt, dem Betriebssystem und Anwendungen;
4 ein Diagramm eines Beispiels der Aufzeichnungsstruktur in der Systemkonfigurationsdatei;
5 ein Diagramm eines Beispiels der Kommunikationskonfiguration;
6 ein vereinfachtes Diagramm eines verteilten Online-Datenkommunikationssystems, das in einem Beispiel einer elektronischen Geld- und Informationsübertragungsanwendung verwendet wird;
7 ein Diagramm, welches die Architektur und den Prozessfluss von Leitungshandlerprogrammen gemäß den Merkmalen der vorliegenden Erfindung darstellt;
8 ein Diagramm eines Beispiels der mehrschichtigen Architektur des verteilten Online-Datenkommunikationssystems der vorliegenden Erfindung;
9 ein Diagramm eines Beispiels des Systembotschaftsformats gemäß den Merkmalen der vorliegenden Erfindung;
10A und 10B Diagramme von Beispielen der Botschaftsstrukturen, die zwischen einem Steuerpunkt und anderen Prozessen verwendet werden;
11 ein Diagramm eines Beispiels einer Botschaftsstruktur, die zwischen Leitungshandlerprogrammen und Anwendungen verwendet wird;
12 ein Blockdiagramm, welches einen Datenbanksynchronisationsprozess gemäß den Merkmalen der vorliegenden Erfindung darstellt;
13 ein Blockdiagramm, welches ein Beispiel eines Prozesses für das Erkennen und das Behandeln eines allgemeinen Ausfalls an einem Knoten darstellt; und
14 ein Blockdiagramm, welches ein Beispiel eines Prozesses für die Datensicherungsverarbeitung und Wiederherstellung des Primärknotens darstellt.
Ausführliche Beschreibung der Erfindung
Die bevorzugte(n) Ausführung(en) der vorliegenden Erfindung ist (sind) in den 2 bis 14 dargestellt.
Bezug auf 2 nehmend, ist dort ein vereinfachtes Blockdiagramm eines verteilten Online-Datenkommunikationssystems 22 dargestellt. Das verteilte Online-Datenkommunikationssystem 22 realisiert eine Vielzahl von Ereignis-gesteuerten Anwendungen, einschließend ein elektronisches Geld- und Informationsübertragungssystem (EFIT), einen Verkaufsort (POS), elektronische Gesundheitsfürsorge- und Sozialfürsorge-Transaktionen oder jede auf Botschaften basierende Transaktionsverarbeitungsanwendung. Das System 22 weist eine Anzahl von Prozessen auf, einschließlich eines Systemmonitors und seiner Datensicherung 24, einem Steuerpunkt 26, einer Befehlseinrichtung 28, Leitungshandlern 30, einer Ereignisprotokolleinrichtung 32 und einer Diagnoseablauffolgeeinrichtung 34. Das System 22 weist weiterhin eine Systembibliothek 35 auf, die einen Satz von Routinen enthält, der für alle System- und Anwendungsprozesse 36 verwendet wird.
Die Systembibliotheksroutionen 35 liefern Schnittstellenprozeduren zum Ausführen von Basisfunktionen und sie sind vorzugsweise verknüpft oder kompiliert mit System- und Anwendungsprozessen. 2 stellt diese Kopplung zwischen den Systembibliotheksroutinen 35 und den Systemmonitoren 24, dem Steuerpunkt 26, den Leitungshandlern 30, der Protokolleinrichtung 32, der Ablauffolgeeinrichtung 34 und den Anwendungsprozessen 36 als eine offene Fließbandbefehlsverarbeitung (Pipeline) dar, um sie von der Eingabe/Ausgabe, wie sie in dem zentralisierten Kommunikationssystem 11 vorher beschrieben ist, zu unterscheiden. Die Systembibliotheksfunktionen beinhalten das Absenden, Empfangen, Weiterleiten, die Warteschlangenbildung, das Protokollieren und das Verfolgen von Botschaften. Die Systembibliothek 35 ermöglicht, dass die Anwendungsprozesse 36 miteinander und mit der Außenwelt kommunizieren können. Die Systembibliothek 35 hält vorzugsweise eine private Datenstruktur im Speicher, welche die Informationen enthält, die erforderlich sind, um die Weiterleitungs- und Empfangsdienste für die Anwendungsprozesse durchzuführen. Jeder Anwendungsprozess hat seine eigene Kopie der Bibliotheksdaten. Daher hat jeder Anwendungsprozess auch seine eigne Sicht auf die Prozesse, mit denen er kommuniziert. Diese Bibliotheksdaten sind dynamisch und hängen von den Verknüpfungen mit anderen Prozessen ab, welche die Anwendung erzeugt und ablegt. Die Bibliotheksdaten können Umfeldvariable, Puffer für das Einlesen von Botschaften und eine Tabelle enthalten, die alle offenen Prozesse auflistet, die Botschaften senden und/oder empfangen können.
Das System 22 ist für Ereignis-gesteuerte Anwendungen besonders wertvoll. Die Ankunft einer Botschaft, eine Unterbrechung, ein Botschaftsausfall, ein Abschluss einer Eingabe/Ausgabe sind Beispiele von Ereignissen. Um ein Ereignis zu erkennen, ruft eine Anwendung eine Systembibliotheksprozedur RECEIVE (EMPFANGEN) auf. Die Systembibliothek 35 führt Umgebungs- und Betriebssystem-spezifische Aufgaben durch, um zu bestimmen, was das Ereignis ist und gibt dann einen Wert für die Art des Ereignisses und die Daten, die dem Ereignis zugehörig sind, an die Anwendung aus. Der nachfolgende Algorithmus zeigt ein Beispiel einer Hauptschleife eines Anwendungsprogramms, welche die vorliegende Methode verwendet:
Solange keine Zeit zum Abbrechen vorgesehen ist
Rufe RECEIVE (Empfangen) auf
Schalte auf EVENT-TYPE (Ereignisart)
wenn MESSAGE (Botschaft), verarbeite die Botschaft
wenn COMPLETION (Abschluss), verarbeite Abschluss
wenn FAILURE (Ausfall), verarbeite Ausfall
wenn TIMEOUT (Unterbrechung), verarbeite Zeitprogrammgeber
Sonstiges, verarbeite unbekanntes Ereignis
Beende Schalte
Beende Solange
Umfeldspezifische Aufgaben können das Aufheben der Blockierung einer Botschaft oder das Prüfen der Warteschlangen auf weitere zu sendende Botschaften sein. Betriebssystem-spezifische Aufgaben können das Kommunizieren mit dem Betriebssystem, um Botschaften von einem anderen Programm zu empfangen oder das Interpretieren eines Betriebssystemfehlers sein. Diese Aufgaben werden transparent für die Anwendungen 36 durchgeführt.
Der Systemmonitor 24 ist ein Prozess ohne Unterbrechungen, um alle Systemprozesse zu überwachen und jeden Prozess wieder anlau fen zu lassen, der abgeschaltet wurde, einschließlich dem Steuerpunkt 26. Der Systemmonitor 24 kann Prozesse seiner Monitore auf den Informationsstatus abfragen und Bestätigungen von dort empfangen. Wie auch in 3 dargestellt ist, greift der Systemmonitor 24 über Systembibliotheksaufrufe 48 zur Information über die Prozesskonfiguration auf eine Systemkonfigurationsdatenbank 37 zu. Damit der Systemmonitor 24 ohne Unterbrechungen betrieben wird, ist ein Datensicherungsprozess 24' vorgesehen, welcher parallel zu dem Systemmonitor 24 läuft. Der Systemmonitor 24 verwendet auch die Betriebssystemaufrufe 49, um neue Beispiele von Anwendungsprozessen zu erzeugen, einen Anwendungsfall zu stoppen und um Ausfallbenachrichtigungen von den Anwendungsfällen zu empfangen. Der Systemmonitor 24 überprüft vorzugsweise kritische Informationen und Transaktionen auf ihren Datensicherungsprozess 24'. Wenn der Primärsystemmonitor ausfällt, übernimmt der Datensicherungsprozess und setzt von dem letzten Prüfpunkt an fort. Die Benutzer können den Systemmonitor 24 über den Steuerpunkt 26 und die Befehlseinrichtung 28 steuern. Der Systemmonitor 24 ist konfiguriert, alle Prozesse an allen Knoten in dem System in Abhängigkeit von der Anwendung zu steuern.
Wie in 2 dargestellt ist, enthält die Systemkonfigurationsdatenbank 37 die Daten aller Prozesse in dem System 22, die ihre logischen Namen, die physikalischen Adressen, die Datensicherungsprozessidentitäten und andere Eigenschaften beinhalten können. Die Inhalte der Systemkonfigurationsdatenbank 37 können durch Befehle von der Befehlseinrichtung 28 modifiziert werden. Auf die Systemkonfigurationsdatenbank 37 kann je nach Bedarf der Anwendung von fern zugegriffen werden, sie kann an anderen Orten reproduziert werden oder kann auf eine Vielzahl von Orten verteilt sein.
Die Systemkonfigurationsdatenbank 37 enthält mehrere Datensätze, wobei jeder Datensatz Informationen über ein Objekt in dem System 22 enthält. Wie in 4 dargestellt, können die Informationen in einem Datensatz über ein Objekt eine Objektart 23, einen logischen Namen 25, einen physikalischen Namen 27 und Eigenshaften 29, die auf die Objektart zutreffen, enthalten. Die Objektart 23 ist die Art des Datensatzes oder des Objektes, der logische Name 25 ist der Name, mit dem die Anwendungen auf dieses Objekt zugreifen, der physikalische Name 27 ist der Systemname und der Ort des Objektes und die Eigenschaften 29 sind spezifische Informationen für die in dem Datensatz definierte Objektart. Wenn es erwünscht ist, können die Eigenschaften 29 Informationen über die Objekte enthalten, die als Datensicherungen für jedes Objekt dienen.
In dem System 22 gibt es verschiedene Objektarten, einschließend, jedoch nicht darauf beschränkt: SYSTEM, PROCESS, LOGICAL UNIT (logische Einheit), PHYSICAL UNIT (physikalische Einheit), LINE (Leitung), USER (Benutzer), TERM (Term), FILE (Datei), ROUTE (Leitweg), NETWORK (Netzwerk), COMMAND (Befehl), NODE (Knoten), GROUP (Gruppe), PARAMETER und ASSIGN (Zuordnung). Jede Objektart wird nachfolgend ausführlicher beschrieben.
Das System-Objekt enthält Informationen, die auf einen Standort oder einen Knoten in dem System bezogen sind. Daher kann die Systemkonfigurationsdatenbank 37 mehrere System-Objektdatensätze einschließen, die Kommunikationswege und andere Informationen enthalten, die auf alle Knoten in dem System bezogen sind, die miteinander kommunizieren können.
Das PROCESS-Objekt enthält Informationen, die einen Prozess für das verteilte Online-Datenkommunikationssystem definieren. Auf eine Anwendung, die auf der Plattform läuft, wird durch ihren logischen Namen Bezug genommen. Der physikalische Name enthält den Identifikator des laufenden Prozesses. Der Eigenschaftsbereich definiert den Standort des Objektes und die Ressourcen, welche ein Prozess nutzt und verwendet Informationen, die es erlauben, den laufenden Prozess zu erzeugen.
Das LOGICAL UNIT (LU)-Objekt ist die elementarste Form einer Kommunikationsschaltung. Es beschreibt den Endausgang einer speziellen Vorrichtung. Wenn ein Prozess auf eine LU durch ihren logischen Namen Bezug nimmt, wird die Botschaft zu ihrem Leitungshandler 30 weitergeleitet. Die LU weist über die wählbaren PHYSICAL UNIT (PU)-Objekte Verknüpfungen auf, die an einem LINE (L)-Objekt enden, wie es in 5 dargestellt ist. Der Leitungshandler 30 (2) verwendet die hierarchischen Informationen von LU, PU, LINE, um die Adresse der Zielvorrichtung zu erhalten. Der physikalische Standort ist durch die physikalischen Namen der LU-, PU- und LINE-Objekte beschrieben, die miteinander verknüpft sind. Daher beinhalten die Eigenschaften der LU den Namen des Leitungshandlers und die Verknüpfungen. Andere Eigenschaften des LU-Objektes definieren das Protokoll der LU und Protokolloptionen. Eine LU kann verwendet werden, um einen Kommunikationsweg zu einer externen Quelle definieren, beispielsweise zu den Institutionen 45 und den Geldautomaten (ATMs) 44 oder zu anderen Knoten 40 des verteilten Online-Datenkommunikationssystems ( 2).
Das PHYSICAL UNIT-Objekt (PU) ist ein Objekt, welches einem Netzwerkdesigner erlaubt, eine Kollektion von einem oder mehreren LUs zu erzeugen. Es handelt sich dabei um das logische Teilen eines LINE-Objektes. Die Konfiguration der Kommunikationen folgt naturgemäß oft der in 5 dargestellten Hierarchie. Ein PU-Objekt ist ein Mittel, um die Hierarchie anzuzeigen, welche die verfügbare Bandbreite in den Kommunikationen nutzt. Der logische Name der PU ist so spezifiziert, um Zugriff darauf zu erhalten (beispielsweise auf eine Verknüpfungskette von LUs). Der physikalische Name enthält die Weiterleitungsinformationen für das Zugreifen auf eine LU (eine partielle Adresse). Die Eigenschaften enthalten das Protokoll und eine Verknüpfung mit anderen Objekten, die weitere PUs sein könnten, die jedoch an einem LINE-Objekt enden müssen.
Das LINE-Objekt definiert einen Port (Eingang) an der physikalischen Ausrichtung, von dem aus über eine Kommunikationsschaltung ein Mehrfachzugriff auf eine oder mehrere Vorrichtungen erfolgen kann. Der logische Name eines LINE-Objektes ist durch die LUs und PUs definiert, die mit ihm über das Verknüpfungsfeld verknüpft sind. Der physikalische Name beschreibt den Portnamen der Maschine oder der Kommunikationsvorrichtung. Die Eigenschaften schließen das Leitungshandlerprogramm, das Protokoll und Protokolloptionen ein.
Wenn ein Leitungshandler 30 eine Botschaft für eine LU empfängt, hat er bereits die Objektinformationen miteinander verkettet. Ein allgemeiner Algorithmus für das Weiterleiten wird verwendet, um auf den in dem LINE-Datensatz beschriebenen Port zuzugreifen und das Leitungssegment, das durch den PU-Datensatz (wenn vorhanden) beschrieben ist und die Adresse an dem LU-Datensatz zu nutzen, um die Botschaft zu der Vorrichtung am Ende der Schaltung zu übertragen.
Das USER-Objekt beschreibt einen zulässigen Benutzer des verteilten Online-Datenkommunikationssystems 22. Es funktioniert hauptsächlich als eine Sicherheitsmaßnahme für den geschützten Zugriff auf das System. Für Terminals in einem sicheren Bereich kann es so ausgestaltet sein, dass jeder Benutzer zulässig ist. Diese Terminals sind in der Systemkonfigurationsdatenbank 37 als TERM-Objekte definiert.
Das FILE-Objekt definiert eine Datei für das System 22 und ihre Anwendungen. Es hat weiterhin einen logischen Namen und einen physikalischen Standort. Das Zugreifen auf eine Datei über einen logischen Namen verleiht der Maschine und dem Standort für ein verteiltes System Transparenz. Eine Anwendung greift auf eine Datei durch Spezifieren ihres logischen Namens zu, die Systembibliothek 35 (2) bestimmt dann den physikalischen Namen und stellt der Anwendung die Zugriffsdienste und die Informationen zur Verfügung.
Das ROUTE-Objekt ist ein generisches Objekt, das von dem System 22 bereitgestellt wird, um durch die Anwendungsbibliothek (die nachfolgend in Verbindung mit 6 beschrieben wird) oder die Anwendungen 36 genutzt zu werden. In dieser Datensatzart sind ein logischer Name und ein „Bezugs-Handler„ spezifiziert. Der Handler (Programm für die Steuerung von Vorgängen im Rechner) ist ein Prozess-Objekt. Der Handlerprozess ist eine Anwendung, die programmiert ist, eine Botschaft von der ROUTE-Quelle zu erkennen und sie entsprechend zu verarbeiten. Wenn eine Anwendung ein ROUTE-Objekt als ein Ziel anzeigt, leitet die Systembibliothek 35 es automatisch zu dem Handlerprozess weiter. Dieses Merkmal ist nützlich, wenn eine Anwendung einen gekennzeichneten Befehl hat, der für alle Prozesse in dem System Gültigkeit hat. Diese Implementierung eines umfassenden Ziels (durch Verwendung eines ROUTE-Objektes), hält das System generisch, so dass das System 22 nicht die spezifischen Merkmale einer Anwendung kennen muss und erlaubt Flexibilität in der Anwendung.
Das NETWORK-Objekt ist ein geeignetes Mittel zur Beschreibung des physikalischen Netzwerks, das die Kommunikationen für ein System realisiert. Es beeinflusst nicht die Weiterleitung, beschreibt jedoch die Hardware, die das verteilte System bildet.
Das COMMAND-Objekt erlaubt es einem Benutzer, die Benutzerschnittstelle kundengerecht auf die Anwendung spezifischer Befehle zuzuschneiden. Ein COMMAND-Objekt besteht aus einem logischen Namen und einem physikalischen Namen (welcher der Text des Befehls ist) und aus dem Ziel für den Befehl. Ein Beispiel für einen solchen Befehl ist, wenn eine Anwendung neue Sicherheitsschlüssel erhalten muss. Ein mit KEYS benanntes COMMAND-Objekt ist in der Systemkonfigurationsdatei 37 definiert und wird durch einen Benutzer verwendet, um den Anwendungsprozess über das Erhalten neuer KEYS zu informieren.
Das NODE-Objekt ist als ein Berechnungsknoten in dem System 22 definiert. Ein Berechnungsknoten ist ein Satz von einem oder mehr eng gekoppelten physikalischen Prozessoren. Die Konfiguration eines Knotens ist von der Hardware unabhängig, so dass er an einem Satz von Zentraleinheiten (CPUs) oder an einer Arbeitsstation eingerichtet werden kann. Daher kann eine Anwendung durch Zuordnen des logischen Namens des Knoten davon befreit werden, die Hardware zu kennen. Die Eigenschaften eines Knotens beinhalten eine Anzeige des ein- oder ausgeschalteten Status dieses Knotens. Das NODE-Objekt ist in dem SYSTEM-Objekt als ein Zeitsynchronisierungsknoten spezifiziert. Auf diese Art und Weise können alle Transaktionen in dem System 22, selbst wenn sie auf mehrere Knoten verteilt sind, auf den gleichen Taktgeber synchronisiert werden. Die Taktsynchronisierung durch Kombination des Konfigurierens des SYSTEM-Datensatzes mit einem Zeitsynchronisierungsknoten und mit einer Systembibliotheksprozedur wird als SYSTEM TIME (Systemzeit) bezeichnet.
Das GROUP-Objekt erlaubt das logische Gruppierungen der Objekte in der Systemkonfigurationsdatenbank 37. Es liefert eine erforderliche Eignung für das Überwachen und Betreiben eines großen verteilten Systems. Wenn für eine Operation ein Gruppenname angezeigt wird, werden alle Objekte in dieser Gruppe betrieben.
Das PARAM-Objekt erlaubt es, Umfeldvariable für Anwendungsprogramme außerhalb des Programms zu definieren, so dass sie modifiziert werden können. Ein PARAM besteht aus einem logischen Namen und einem Wert. Wenn ein Anwendungsprogramm eine Umfeldvariable benötigt, ruft es eine Prozedur aus der Systembibliothek 35 auf, welche den Wert des Parameters zurücksendet. Ein Beispiel wäre ein PARAM mit dem logischen Namen SECURITY (Sicherheit) und dem Wert ON (Ein).
Das ASSIGN-Objekt wird auch verwendet, um das Umfeld für Anwendungsprogramme zu beschreiben. Es definiert Dateien außerhalb des Programms, so dass sie modifiziert werden können. Ein ASSIGN-Objekt besteht aus einem logischen Namen und einem Dateinamen oder FILE-Objekt. Wenn ein Anwendungsprogramm eine Datei für die Verarbeitung benötigt, ruft es eine Prozedur aus der Systembibliothek 35 auf, welche den Dateinamen oder das FILE-Objekt zurücksendet.
Weiterhin sind in 2 eine Befehlseinrichtung 28, eine Schnittstelle zu dem (den) Benutzer(n) und ein Steuerpunkt 26 dargestellt, der eine Steuer- und Überwachungseinrichtung des jeweiligen Standorts oder Knotens des Systems 22 ist. Die Befehlseinrichtung 28 kann mit einer Dateneingabe und mit einer Anzeigevorrichtung 42, beispielsweise mit einem Terminal, einem Computer oder einer Arbeitsstation, kommunizieren und sie kann über Telekommunikationsleitungen oder Computernetzwerke mit dem Steuerpunkt 26 verbunden sein. Die Befehlseinrichtung 28 kann eine graphische oder Text-Benutzerschnittstelle zum Empfangen von Befehlen und Anzeigen des Systemstatus aufweisen.
Die Hauptfunktion des Steuerpunktes 26 ist das Handhaben von Anforderungen von der Befehlseinrichtung 28, um die Objekte in dem lokalen Knoten zu konfigurieren, zu überwachen und zu steuern. Er ist die einzige Einrichtung für die Pflege der Systemkonfigurationsdatenbank 37. Der Steuerpunkt 26 befindet sich in Kommunikation mit allen Prozessen an dem örtlichen Knoten und ist der zentrale Übermittler von Befehlen und Sammler von Informationen, die zur Anzeige an die Befehlseinrichtung 28 zurückgesendet werden. Der Steuerpunkt 26 kommuniziert mit allen Prozessen über einen flexiblen, erweiterbaren, Token-orientierten Nachrichtenstandard, wie er in den 10A und 10B dargestellt ist und nachfolgend ausführlich beschrieben wird, und er kann somit Schnittstelle zu Befehlseinrichtungen an Mehrfachplattformen sein. Die Befehlseinrichtung 28 ist für das Formatieren und die Bereitstellung von Informationen verantwortlich, die durch den Steuerpunkt 26 in einer Art und Weise in einem grafischen und/oder Textanzeigeformat weitergegeben werden, die für die gewählte Plattform geeignet ist. Die Befehlseinrichtung 28 und der Steuerpunkt 26 wirken weiterhin zusammen, um Sicherheit gegenüber unbefugtem Zugriff zu dem System zu gewährleisten, wie es durch USER-Objekt-Datensätze definiert ist, die in der Systemkonfigurationsdatenbank 37 enthalten sind.
Leitungshandler 30 sind Prozesse, die für die Datenkommunikation mit externen Vorrichtungen verantwortlich sind, beispielsweise, aber nicht darauf eingeschränkt, mit Geldautomaten 44, Bankinstitutionen 45 und anderen Knoten 40 des verteilten Online-Datenkommunikationssystems 22. Ein Geldautomat 44 ist für den Zweck der vorliegenden Erfindung als ein zweckbestimmtes Terminal mit einer Dateneingabevorrichtung und einem Anzeigebildschirm definiert, das Transaktionsanforderungen von Bankkunden, beispielsweise Bargeldabhebungen, Einzahlungen, Abfragen des Kontenstandes usw., empfängt und verarbeitet. Der Leitungshandler 30 kann darauf spezialisiert sein, in Übereinstimmung mit spezifischen Kommunikationsprotokollen, beispielsweise Bisync, X.25, TCP/IP, SNA und anderen zu arbeiten. Ferner können die Leitungshandler 30 Brückenprozesse für fremde Systeme einschließen. Es kann mehr als ein Leitungshandlerprozess 30 gleichzeitig ablaufen, um Kommunikation mit einer großen Anzahl von externen Vorrichtungen zu sichern.
Ein Ereignisregistrierer 32 ist ein Registrierprozess, der Botschaften empfängt, die für eine Registrierdatei 46 bestimmt sind und er kann einige Filterfunktionen ausführen. Die registrierten Botschaften können durch Eingabe entsprechender Befehle an der Befehlseinrichtung 28 oder auf der Ebene des Betriebssystems wieder aufgefunden werden. Ein Systembibliotheksprozess ist vorgesehen, um die registrierten Botschaften zu formatieren.
Der Tracer (Programmüberwacher) 34 ist ein Prozess, der Botschaften sammelt, die zwischen ausgewählten Prozessen in dem System übertragen werden und sie in einer Ablaufverfolgungsdatei 47 speichert. Ein Benutzer kann über die Befehlseinrichtung 28 oder auf der Ebene des Betriebssystems das Verfolgen des Ablaufes auslösen und die Prozesse, die Art von Botschaften und andere Ablaufverfolgungsparameter auswählen. Ein Systembibliotheksprozess steht zur Verfügung, um die verfolgte Datei zu formatieren. Ferner können die gespeicherten Botschaften durch an der Befehlseinrichtung 28 eingegebene Befehle aus der Datei 47 wieder aufgefunden werden.
Bezug auf 6 nehmend, ist dort ein vereinfachtes Blockdiagramm dargestellt, welches den Prozessfluss eines Beispiels eines ausfallsicheren, Ereignis-gesteuerten Transaktionsverarbeitungssystems erläutert. 6 zeigt spezifisch den Prozessfluss für ein Beispiel einer elektronischen Geld- und Informationsübertragungsanwendung (EFIT), das auf einem verteilten Online-Datenkommunikationssystem 50 gemäß den Merkmalen der vorliegenden Erfindung basiert. Das verteilte Online-Datenkommunikationssystem 50 kann mehrere Knoten aufweisen, die voneinander im Land, im Erdteil und oder weltweit voneinander entfernt sind. In einem System mit zwei Knoten kann sich zum Beispiel der Knoten A in Chicago, Illinois und der Knoten B in Plano, Texas befinden. In einem EFIT-System können die Knoten A und B regionale Verarbeitungszentren darstellen.
In Anwendung auf EFIT kann eine Transaktion durch eine Erfassungseinrichtung für eine Transaktion beispielsweise durch einen Geldautomaten 52 ausgelöst werden, der durch einen Bankkunden zum Beispiel dort, wo der Geldautomat direkt mit dem Knoten A des verteilten Online-Datenkommunikationssystems 50 gekoppelt ist, betätigt wird. Der Kunde kann zum Beispiel die Transaktion durch Einführen einer von einer Bankinstitution herausgegebenen Karte, die eine eindeutige Kartennummer und Daten enthält, die dem Konto des Kunden zugehörig sind, auslösen. Der Kunde gibt weiterhin die Art der gewünschten Transaktion ein, beispielsweise Einzahlung, Abhebung, Abfrage des Kontostandes und den zugehörigen Dollarbetrag, wenn erforderlich, ein. Die gewünschte Transaktion, die Kartennummer und Leitungs- und Vorrichtungsnamen/-nummern des Geldautomaten werden in einer Transaktionsbotschaft zusammengepackt, die ein erstes vorbestimmtes Format hat und an einen Leitungshandler (LH) 54 übertragen.
Mit dem Leitungshandler 54 ist ein Satz von Systembibliotheksprozeduren (SL) 60 verbunden. Das System 50 kann man sich als eine Mehrebenenarchitektur 70 vorstellen, wie sie in 8 dargestellt ist. Die unterste Ebene, die Kommunikationsebene 72, stellt die Datenkommunikationsausrüstung, die Leitungen und Protokolle dar, die von den Leitungshandlern 54 benutzt werden, um mit externen Vorrichtungen zu kommunizieren. Über der Kommunikationsebene 72 befindet sich eine Systembibliotheksebene 74, die den Funktionen entspricht, die von dem Satz der Systembibliotheksprozeduren 60 und den von ihnen genutzten Datenbanken ausgeführt werden. Die Systembibliotheksebene 74 stellt Nachrichtendienste bereit, die von der Hardware und von dem Kommunikationsprotokoll in der Kommunikationsebene 72 unabhängig sind. Über der Systembibliotheksebene 74 befindet sich eine Anwendungsbibliotheksebene 76, welche zusätzliche anwendungsspezifische Nachrichtendienste und Datenbanken enthält. Die oberste Ebene ist eine Anwendungsebene 78, welche die Anwendungsprogramme zur Ausführung von spezifischen Funktionen, beispielsweise EFIT enthält. Es ist zu erkennen, dass die Systembibliotheksebene 74 die Anwendungsebenen 76 und 78 vom Vertrauen auf und der engen Kopplung mit der Hardware und den Protokollen der Kommunikationsebene 72 befreit, um eine transportable und Hardware-unabhängige Schnittstelle bereitzustellen. Bezug auf 6 nehmend, ist die Systembibliotheksebene 74 als die Systembibliotheksprozeduren (SL) 60, enthaltend, gebündelt mit allen Prozessen, einschließlich der Pro zesse in der Anwendungsbibliotheksebene 76 sowie der Prozesse in der Anwendungsebene 78 dargestellt. Die Systembibliotheksprozeduren 60 können einen Code haben, der mit dem Code jedes Prozesses kompiliert ist. Alternativ können die Systembibliotheksprozeduren 60 in einer Laufzeitbibliothek enthalten sein, die durch alle Prozesse aufgerufen werden kann.
In 6 empfängt ein Leitungshandler 54 eine Transaktionsbotschaft von dem Geldautomaten, wenn der Kunde eine Transaktion auslöst. Bezug auf 7 nehmend, sind zusätzliche Einzelheiten des Handlerprozesses 54 dargestellt. In 7 zeigen die Pfeile den Prozessfluss in einem allgemeinen Code (Kernprogramm) 31 und in einem Kundencode 33 des Leitungshandlerprozesses 54. Zuerst wird einen Aufforderung erhalten, um mit einer LU (logischen Einheit) zu operieren, beispielsweise starte, stoppe oder übertrage. Der Leitungshandler arbeitet mit dem allgemeinen LU-Code 31, indem er zuerst die LU in einer Statustabelle findet und dann den Kundencode 33 aufruft, um die Protokoll-abhängigen Funktionen an entsprechenden Stellen in der Verarbeitung auszuführen. Die Statustabelle stellt Statusinformationen über die LUs und Objekte (eingeschaltet/ausgeschaltet/stillgelegt) bereit und ist Bestandteil eines globalen Satzes von Informationen, die durch den allgemeinen Code 31 gespeichert gehalten werden. Der Kundencode 33 des Leitungshandlers modifiziert dann (wenn es erforderlich ist) die Verarbeitung der Botschaft auf der Basis des Protokolls gibt zur Kontrolle eine Rückmeldung an den allgemeinen Code 31. Der allgemeine Code des Leitungshandlers 31 führt dann die Eingabe/Ausgabe in die/aus der Vorrichtung, beispielsweise ein Geldautomat, bei der berechneten Adresse durch. Alternativ kann die Eingabe/Ausgabe in die/aus der Vorrichtung durch den Kundencode 33 durchgeführt werden. Der spezielle Geldautomat, von dem die Transaktion erzeugt wird, hat ein vorherbestimmtes Ziel oder einen vorher bestimmten Vorrichtungshandler (DH) 80 für alle seine Transaktionsbotschaften, die in der in 2 dargestellten Systemkonfiguration 37 vorbestimmt sind. Der Vorrichtungshandler 80 empfängt die Botschaft und formatiert sie in ein zweites vorherbestimmtes Format um, das für das System 50 gültig und in 9 dargestellt ist.
9 zeigt ein Beispiel eines Formats 90 für Botschaften, die in verteilten Online-Datenkommunikationssystemen 50 übertragen werden. Das Botschaftsformat 90 weist ein Block-Kopffeld 92 auf, das Informationen über den nachfolgenden Datenblock enthalten kann, beispielsweise über die Anzahl der Botschaften in dem Block, den relativen Versatz zu dem Beginn der ersten Botschaft in dem Block und über die Gesamtanzahl von Bytes der Botschaften in dem Block. Das Block-Kopffeld 92 kann auch einen Identifikator aufweisen, der die Daten als eine Botschaft identifiziert, die ein von dem System 50 erkennbares Format haben. Dem Block-Kopf-Feld 92 folgt ein System-Kopffeld 94, das mehrere Felder enthalten kann. Das System-Kopffeld 94 kann Informationen enthalten, wie zum Beispiel einen Identifikator, der die Art der Botschaft, den Namen eines Quellenobjekts und den Namen eines Zielobjekts anzeigt. Alle Prozesse und Datenbanken in dem System 50 sind einem einzigem logischen Identifikator oder Namen zugeordnet. Der logische Idenfikator ist der Systembibliothek 60 zugeordnet und wird verwendet, um alle Botschaften zu adressieren und um die Quelle und das Ziel der Botschaften zu identifizieren. Das System-Kopffeld 94 enthält ferner eine Erweiterungsgröße, eine Anwendungs-Kopffeldgröße und eine Anwendungsdatengröße. Die Erweiterungsgröße sichert die Flexibilität zum Erweitern der Größe des System-Kopffeldes durch ein optimales Erweiterungsfeld 96, wenn es erforderlich ist. Die Anwendungs-Kopffeldgröße zeigt die Größe des Anwendungs-Kopffeldes 98 an, das durch Verwendung der Anwendungsbibliotheks- und Anwendungsebenen 76 und 78 (8) in jeder Art und Weise verwendet werden und optional sein kann. Das Botschaftsformat 90 weist ebenfalls ein optionales Anwendungsdatenfeld mit variabler Länge auf. Die Sternchen (*), die in 9 den Botschaftsfeldern hinzugefügt sind, zeigen an, ob die Felder optional sind. Es ist zu erkennen, dass das Bei spiel des Botschaftsformats generisch ist und verschiedene andere Anwendungsarten für die Systemnutzung erlaubt.
10A ist ein Beispiel einer Botschaft unter Verwendung des in 9 dargestellten Formats für die Steuerung von Punkt-Anwendungsdaten. Die Botschaft kann ein Feldblock-Kopffeld 92, ein System-Kopffeld 94, eine optionale Erweiterung 96, ein optionales Anwendungs-Kopffeld 98 und optionale Anwendungsdaten 100 enthalten. Weiterhin können die Steuerpunkt-Anwendungsdaten eine Anzahl von Token-Identifikatoren (TKN ID), ihre jeweiligen Längen (LEN) und zugehörige Daten enthalten. Die Botschaft endet mit einem End-Token (END TKN) und mit der Länge 0, um das Ende der Botschaft anzuzeigen. In der Praxis kann, wie es in 10B dargestellt ist, die Botschaft, um einen neuen Prozess zu starten, einen Befehls-Token (CMD TKN) mit seiner Länge und seinen zugehörigen Daten aufweisen, welcher der Startprozessbefehl (STRT CMD) ist. Der nächste Token-Identifikator ist der Objekt-Token (ENTITY TKN), seine Länge und die Systemkonfigurationsdatenbank-Datensatzinformation bezogen auf das Objekt oder den Prozess, der gestartet wird. Der Befehls-Token, der Startbefehl und der Objekt-Token können ganzzahlige Werte, alphanumerische Datenketten oder jede andere Darstellung sein. Es ist zu bemerken, dass in 10B die optionalen Felder 92 bis 98 weggelassen sind.
Bezogen auf 11 ist dort ein Beispiel einer Botschaftsstruktur dargestellt, die für Kommunikationen zwischen den Leitungshandlern und den Anwendungsprozessen verwendet werden. In dem Anwendungs-Kopffeldteil des Leitungshandlers wird eine Anzahl von Feldern verwendet, um Daten in der Botschaft bereitzustellen. So kann zum Beispiel das Anwendungs-Kopffeld des Leitungshandlers einen Botschaftsart-Feld enthalten, um anzuzeigen, ob die in der Botschaft enthaltenen Daten Daten oder Informationen sind, die sich auf einen Befehl beziehen. Eine Zeitmarkierung oder mehrere Zeitmarkierungen können für die statistische Analyse und Zeitsteuerungszwecke ebenfalls vorgesehen sein. In dem Anwendungs- Kopffeld des Leitungshandlers kann auch ein Fehlercode enthalten sein, um die Art eines aufgetretenen Fehlers anzuzeigen. Weiterhin kann auch ein interner Identifikator, der verwendet wird, um das Ziel der Botschaft zu identifizieren, vorgesehen sein.
Den in 6 dargestellten Prozessfluss weiter verfolgend, ruft der Leitungshandler 80 eine mit SYSTEM SEND bezeichnete Systembibliotheksprozedur auf, um die von dem Leitungshandler 54 empfangene Transaktionsbotschaft zu einem Prozess, dem Ablaufverfolger (RTR) 110 zu übertragen. Der Ablaufverfolger 110 kann auf eine Geldautomaten-Datenbank 112 zugreifen, die Informationen über den Netzwerkbereitsteller, die Geldautomaten-Kartennummern und die jeweiligen Besitzer der Bankkarten der Finanzinstitution und die Geldkarten-Netzwerke, auf welche die jeweiligen Bankkarten Zugriffserlaubnis haben, enthält. Somit sucht der Ablaufverfolger 110 die in der Botschaft enthaltene Kartennummer auf und legt fest, dass der Kunde Zugriff zu diesem speziellen Geldautomaten-Netzwerk haben kann und erhält ferner den logischen Identifikator des Prozesses, AUTH01, der die betreffende Transaktion autorisiert. Nach dem Erhalten des logischen Identifikators einer Zugriffsberechtigung (AUTH) 116 ruft der Ablaufverfolger 110 APP SEND auf und spezifiziert in der Botschaft, dass das Ziel der Zugriffsberechtigung (AUTH_DEST) AUTH01 ist. APP SEND kann Teil der Anwendungsbibliotheksebene 76 (8) sein, die einen Satz von Anwendungsbibliotheksprozeduren 114 liefert. Die Anwendungsbibliothek 114 empfängt dann die Botschaft und ruft SYSTEM SEND mit dem Ziel AUTH01 auf. SYSTEM SEND erkennt AUTH01 als ein lokales Zugriffsberechtigungsprogramm 116 und liefert die Botschaft an das Programm für die Zugriffsberechtigung 116. Die Botschaft kann dann in eine Warteschlange eingeordnet werden, bis das Zugriffsberechtigungsprogramm 116 sie aus der Warteschlange herauszieht, um sie zu empfangen. Die Warteschlange befindet sich in dem Privatspeicher der Systembibliothek des Absenders des Prozesses.
Das Programm für die Zugriffsberechtigung 116 überprüft dann die Botschaft und greift auf eine Datenbankdatei oder auf eine Kartendefinitionsdatei 118 zu, um Informationen zu erhalten, die erforderlich sind, um zu bestimmen, ob die angeforderte Transaktion zugriffsberechtigt ist. Das Programm für die Zugriffsberechtigung 116 erzeugt dann eine Zugriffsberechtigungsbotschaft und ruft PP SEND auf, um die Botschaft zu liefern. Das Programm für die Zugriffsberechtigung 116 kann in der Botschaft ein Ziel oder mehrere Ziele für die Botschaft spezifizieren, beispielsweise RETURN_AND-JOURNAL_DEST, wodurch spezifiziert wird, dass die Botschaft zu dem Erzeuger zurückzuleiten und durch den entsprechenden Journal-Prozess zu protokollieren ist. In einem vorbestimmten Feld in dem Botschaftsformat (5) können zusätzliche logische Zielobjektnamen spezifiziert werden. Daher kann das Programm für die Zugriffsberechtigung 116 ein Journal (JRNL) 120 als ein erstes Ziel und den Erzeuger der Botschaft als das zweite oder nächste Ziel der Botschaft einschließen. Die Anwendungsbibliothek (AL) 114 entscheidet nach dem Prüfen der Botschaft, dass das erste Ziel (JOURNAL_DEST) das Journal 120 ist und schreibt die Botschaft an dieses Ziel. Das Journal 120 zeichnet dann die Transaktion in einer festgelegten Datei in einer Datenbank 122 auf und ruft APP SEND mit dem, was in der Botschaft als nächstes Ziel (NEXT_DEST) bezeichnet ist, auf. Die Anwendungsbibliothek 114 entscheidet, dass das nächste Ziel der Erzeuger der Transaktionsbotschaft oder das Rückleitungsziel (RETURN_DEST) ist, welches der Vorrichtungs-Handler 80 ist. Die Anwendungsbibliothek ruft dann SYSTEM SEND auf, um die Botschaft zu dem Vorrichtungs-Handler 80 zu übertragen. Der Vorrichtungs-Handler 80 sendet die Botschaft zu dem Leitungs-Handler 54, der sie dann zu dem Geldautomaten 52 überträgt. Der Geldautomat reagiert dann auf die empfangene Botschaft entweder durch Ausführen der angeforderten Transaktion oder durch Verweigern der angeforderten Transaktion.
In dem vorher angeführten Szenarium ist eine angeforderte Transaktion örtlich an demselben Knoten A zugriffsberechtigt. Eine Transaktion, die an dem Knoten A angefordert ist, kann jedoch alternativ an einem entfernten Knoten, dem Knoten B, durch Übertragen der Transaktionsbotschaft zu dem Knoten B zugriffsberechtigt sein. Wenn zum Beispiel der Ablaufverfolger 110 die Botschaft von dem Vorrichtungs-Handler 80 empfängt und die Kartennummer in seiner Datenbank 112 aufsucht, erhält der Ablaufverfolger 110 von der Datenbank 112 einen logischen Identifikator des Prozesses, zum Beispiel NODEB.AUTH01, welcher die Transaktion autorisieren kann. Der Ablaufverfolger 110 ruft dann APP SEND auf, um die Botschaft zu liefern. Die Anwendungsbibliothek 114 erhält dann NODEB.AUTH01 von der Botschaft und ruft SYSTEM END mit seinem Parameter auf. Die Systembibliothek 60 zeichnet den fremden Systemnamen auf, sucht durch Aufrufen einer Systembibliotheksroutine den Systemnamen in einer Systemkonfigurationsnamendatenbank 130 auf, die zum Erzielen von Effizienz und Leistungsfähigkeit gespeichert gehalten wird und erhält die logische Adresse des Kommunikationseingangs zum Knoten B und seinem Leitungshandler 132. Die Konfigurationsdatenbank 130 speichert vorzugsweise die logischen Namen und die entsprechenden physikalischen Namen aller Systemprozesse und der Hardware. In dieser Art und Weise arbeitend, brauchen die Prozesse nur die logischen Namen von anderen Prozessen, mit denen sie zusammenwirken und ihre Bibliotheksfunktion kennen, um den entsprechenden physikalischen Ort oder die Adressen zu verfolgen und die korrekte Lieferung der Botschaften zu sichern.
Die Systembibliothek 60 fügt dann die reale oder physikalische Zieladresse an das System-Kopffeld 94 (9) in der Botschaft als ein nächstes Ziel (NEXT_DEST) an und bringt die Botschaft zu dem Leitungshandler 132, der die Botschaft zu einem Leitungshandler 132' am Knoten B passieren lässt, in eine Warteschlange. Es ist zu erkennen, dass die Botschaften zwischen den Handlern 132 und 132' über Computernetzwerke, Telekommunikationsnetzwerke, Funknetzwerke, Satellitenkommunikation und Ähnliches übertragen werden können.
Am Knoten B erhält der Leitungshandler 132' die Botschaft und sendet sie zu dem nächsten in der Botschaft festgelegten Ziel (NEXT_DEST), welches NODEB.AUTH01 oder das Programm für die Zugriffsberechtigung 116' ist. Das Programm für die Zugriffsberechtigung 116' erteilt der Transaktion die Zugriffsberechtigung und ruft APP SEND auf, um eine Zugriffsberechtigungsbotschaft zurückzuleiten und die Transaktion in einer oder mehreren Datenbanken aufzuzeichnen (RETURN_AND_JOURNAL_DEST). Die Anwendungsdatenbank 114' legt das Journal Ziel (JOURNAL-DEST) als den Journalprozess fest und bezeichnet weiterhin den Erzeuger der Botschaft als Knoten A, so dass das SYSTEM SEND aufgerufen wird, welches das Ziel als NODEA.JOURNAL festlegt. SYSTEM END bringt dann die Botschaft in eine Warteschlange und schreibt sie an das Journal 120 am Knoten A. Die Systembibliothek 60' zeichnet den fremden Systemnamen von NODEA auf, sucht das System auf und bestimmt den logischen Namen des Kommunikationseingangs zu dem Knoten A. Die Systembibliothek 60' fügt dann die reale Zieladresse des Journals 120 am Knoten A an das System-Kopfeld 94 in der Botschaft als nächstes Ziel (NEXT_DEST) an. Die Systembibliothek 60' sucht weiterhin den Leitungshandler 132' für den Kommunikationseingang zu dem Knoten A auf und bringt die Botschaft in eine Warteschlange zu diesem. Der Leitungshandler 132 erhält die Botschaft und sendet sie an NODEA.JOURNAL 120, das als nächstes Ziel festgelegt ist. Das Journal 120 empfängt dann die Botschaft und schreibt sie in ihre Datenbank oder in die Transaktionsjournaldatei 122. Das Journal 120 ruft weiterhin APP SEND auf und legt ein nächstes Ziel (NEXT_DEST) fest. Die Anwendungsbibliothek 114 erkennt das nächste Ziel als das Rückleitungsziel (RETURN_DEST), das in der Botschaft als Vorrichtungshandler 80 spezifiziert ist. SYSTEM SEND bringt dann die Botschaft in eine Warteschlange und schreibt sie an den Vorrichtungshandler 80, welcher die Zugriffsberechtigungsentscheidung an den Geldautomaten 52 überträgt. Der Geldautomat führt dann je nach der Autorisierung in der Botschaft entweder die angeforderte Transaktion durch oder verweigert sie.
Es gibt viele mögliche Szenarien im Zusammenhang mit verschiedenen Anwendungen, beispielsweise EFIT, in denen das verteilte Online-Datenkommunikationssystem und das Verfahren 50 gleichermaßen anwendbar sind. So kann zum Beispiel ein Host (nicht dargestellt), beispielsweise eine Bankinstitution erforderlich sein, um die Zugriffsberechtigung für die Transaktion zu erteilen. Eine Host-Schnittstelle kann verwendet werden, um mit dem Host zu kommunizieren. Weiterhin kann ein Karteninhaber auf das Geldautomatenkartennetzwerk an einem ersten Knoten Zugriff haben, wobei die Transaktion an dem Host an einem zweiten Knoten zu autorisieren ist, die Host-Schnittstelle jedoch an einem dritten Knoten vorhanden sein kann. Daher muß die Transaktionsbotschaft von dem ersten Knoten zu dem zweiten Knoten über den dritten Knoten übertragen werden. Ähnliche Systembibliotheks- und Anwendungsbibliotheksprozesse können verwendet werden, um diese Transaktion abzuschließen.
Das verteilte Online-Datenkommunikationssystem und das Verfahren 50 gemäß den Merkmalen der vorliegenden Erfindung sind so aufgebaut, dass bei einem Systemausfall an einem oder an mehreren Knoten eine Datenbankdopplung bereitgestellt wird. Bezug auf 12 nehmend, ist dort ein Beispiel einer Datenbankdopplung- oder Datenbanksynchronisierung des Systems und Prozesses 200 dargestellt. Wiederum wird eine EFIT-Anwendung verwendet, um das System 200 zu erläutern. Wenn ein bestimmtes Ereignis eine Veränderung in einer ausgewählten Anzahl von Dateien und Datenbanken bewirkt, wird diese Veränderung zu der Datensicherungsdatenbank geleitet, um ihre Datensätze auf den neuesten Stand zu bringen. Wenn zum Beispiel ein Programm für die Zugriffsberechtigung 202 eine Transaktion autorisiert, welche den Kontostand eines Kontos verändert, der in einer Datei für einen positiven Konstostand (PBF) 204 gespeichert ist, wird die Veränderung in eine Botschaft verpackt und an einen DB_SYNC-Prozess 306 gesendet. Wenn ein Datensatz einer Kundenkontodatei (CAF) 206 aktualisiert wird, sendet das Programm für die Zugriffsberechtigung 202 ebenfalls die aktualisierte Information in einer Botschaft an den DB_SYNC-Prozess 306. Gleichermaßen wird eine Veränderung an einer Datei für beanstandete Konten (AEF) durch einen Dateiserverprozess, CAD SVR 302, an den DB_SYNC-Prozess 306 gesendet.
Die Bereitstellung der Botschaft über die aktualisierten Daten erfolgt durch Aufrufen der Systembibliotheksroutine, SYSTEM SEND. Die Botschaft kann eine logische Identität des Datensicherungssystems oder des Knotens, des Datensatztyps und der veränderten Daten enthalten. Der DB_SYNC-Prozess 306 schreibt dann die Botschaft an eine DB_SYNC-Speicherdatei 308 und verwendet ebenfalls SYSTEM SEND, um die Botschaft zu einem DB_SYNC-Prozess 320 an dem benannten Datensicherungssystem, Knoten A, zu leiten. Es wird daran erinnert, dass die Systembibliothek 60 auf die Systemkonfigurationsdatenbank 130 zugreifen kann, um die physikalische Adresse des Zielsystems zu bestimmen. Ein Zeitgeber 310 kann gestartet werden, um die abgelaufene Zeit zu verfolgen. Die DB_SYNC-Speicherdatei 308 funktioniert als zeitweiliger Speicher für Transaktionsdaten, die eine Dopplung an dem Datensicherungsknoten erfordern. Es ist zu erkennen, dass ein ähnlicher Leitungshandlerprozess, wie er in 3 dargestellt ist, verwendet werden kann, um die Botschaft an entfernte Knoten zu liefern.
Der DB_SYNC-Prozess 320 am Knoten A empfängt die Botschaft und sendet sie an den Server, der durch die Datensatzart angezeigt wird, die in der Botschaft enthalten ist, einschließend PBF SVR 322, AUTH 324 oder CAF SVR 326. Der entsprechende Server speichert dann die Transaktionsdaten in der Botschaft in die jeweilige Datei oder Datenbank 330 bis 334. Der DB_Sync-Prozess 320 an dem Knoten A kann eine Bestätigungsbotschaft an den DB_Sync-Prozess 306 an dem Knoten B bei Empfang der Botschaft oder nachdem die Transaktionsdaten in der korrekten Datei gespeichert sind, senden. Nach dem Empfang der Bestätigungsbotschaft löscht der DB_Sync-Prozess 306 die entsprechende Botschaft aus dem DB_Sync-Speicher 308. Wenn zu der Zeit, zu der der Zeitgeber 310 abgelaufen ist, die Bestätigungsbotschaft noch nicht durch den DB_Sync-Prozess 306 von dem Datensicherungssystem empfangen worden ist, kann der DB_Sync-Prozess 306 die in der DB_Sync-Speicherdatei 308 gespeicherte Botschaft wiederauffinden und sie an das Datensicherungssystem zurück übertragen. Die zurück übertragene Botschaft kann ein Feld enthalten, um anzuzeigen, dass das eine zweite Übertragung einer vorher gesendeten Botschaft ist.
In dieser Art und Weise aufgebaut, ist jedes System an einem Knoten einem Datensicherungssystem oder einer Mehrfachdatensicherung an einem anderen Knoten zugeordnet und die in der Datenbank gespeicherten Daten, die sich auf Transaktionen beziehen, sind gedoppelt. Daher sind ausgewählte Dateien oder Datenbanken zwischen dem Primär- und dem Datensicherungssystem so synchronisiert, dass sie im Wesentlichen die gleichen Daten enthalten. Es kann festgelegt werden, dass bestimmte Transaktionen für die Systemoperationen wesentlich sind, zum Beispiel Bargeldabhebungen, so dass nur Datenbanken und Dateien, die mit dieser Transaktion im Zusammenhang stehen, gedoppelt werden. Die Datei für beanstandete Konten 208 kann zum Beispiel gedoppelt werden, weil sie Geldautomatenkarten aufzeichnet, die verloren oder gestohlen wurden und unberechtigt verwendet werden. Die Datei für einen positiven Kontostand 204 stellt Konten bereit, die einen ausreichenden Kontenstand aufweisen, um Bargeldabhebungen zu unterstützen und die Kundenkontodatei 206 enthält Kundenkonteninformationen. Es ist zu erkennen, dass die Datenbanksynchronisierung nicht auf die in 6 dargestellten Dateien eingeschränkt ist.
Bezug auf 13 nehmend, ist dort ein vereinfachtes Blockdiagramm gezeigt, das ein Beispiel eines Prozesses für das Erkennen und das Handhaben allgemeiner Ausfälle eines Knotens zeigt. Ein verteiltes Online-Datenkommunikationssystem 400 weist im vorliegenden Fall drei Knoten A, B und C auf. Die Kommunikation zwi schen den Knoten erfolgt durch die Leitungshandler 402 bis 406, die miteinander so verbunden sind, wie es in der Systemkonfigurationsdatenbank 130 (3) jedes Knotens spezifiziert ist. Es ist zu erkennen, dass zwischen den Leitungshandlern 402 bis 406 auch eine Datensicherungsverbindung (dargestellt in gestrichelten Linien) vorgesehen ist. Jede Verbindung, die Primärverbindung und die Datensicherungsverbindung, wird durch eine logische Einheit dargestellt. Wenn Botschaften, die zwischen den Leitungshandlern 402 bis 406 übertragen werden, nicht innerhalb der vorgeschriebenen Zeitbegrenzungen empfangen werden, wird die Datensicherungsverbindung für die Kommunikation zwischen den Leitungshandlern verwendet. Wenn sowohl die Primär- als auch die Datensicherungsverbindungen ausfallen und weiterhin abgeschaltet sind, können die Steuerpunkte 412 bis 416 der Knoten über eine Verbindung 420 bis 424, die dazwischen gekoppelt sind, weiter kommunizieren, um den Benutzern, die sich an jedem Knoten befinden, Zugriff zu den anderen Knoten, einschließlich den ausgefallenen Knoten zu gewähren.
Jeder Knoten weist weiterhin einen Systemmonitor 426 bis 430 auf, der ein Handshake-Protokoll mit den Systemmonitoren der anderen Knoten ausführt. Jeder Systemmonitor sendet eine Handshake-Botschaft zu allen anderen Systemmonitoren in dem System. Die Handshake-Botschaft beinhaltet vorzugsweise die Ansicht des Sende-Monitors über den Status aller Knoten in dem System. Wenn ein Systemmonitor eine Handshake-Botschaft von einem anderen Knoten empfängt, vergleicht er den in der Botschaft enthaltenen Status mit seinen eigenen Daten über den Status aller Knoten. Die Systemmonitore von zwei oder mehr Knoten müssen darin übereinstimmen, dass ein Knoten möglicherweise abgeschaltet ist, bevor dieser Knoten als abgeschaltet erklärt wird. Wenn zum Beispiel die Botschaft von dem Systemmonitor 426 des Knotens A den Knoten B als möglicherweise abgeschaltet gekennzeichnet hat und die Botschaft von dem Systemmonitor 430 des Knotens C den Knoten B ebenfalls als möglicherweise abgeschaltet gekennzeichnet hat, ist eine Übereinstimmung über den Status des Knotens B erreicht und er wird als abgeschaltet gekennzeichnet. Ein Systemmonitor kennzeichnet einen Knoten als möglicherweise abgeschaltet, wenn er über die Primärverbindung und die Datensicherungsverbindung Kommunikationsprobleme mit diesem Knoten hat, wenn er beim Austausch von Handshake-Botschaften mit dem Monitor an diesem Knoten erfolglos ist oder wenn er eine Handshake-Botschaft von diesem Knoten mit einer Aufforderung „Kennzeichne mich als abgeschaltet„ erhält. Dieses letzte Szenarium kann vorliegen, wenn ein Knoten für die Wartung durch einen Benutzer zeitweise außer Betrieb gesetzt worden ist.
Der Handshake-Prozess wird nun ausführlicher beschrieben. Der Systemmonitor 426 an dem Knoten A liest aus der Systemkonfigurationsdatenbank die logischen Namen für die Systemmonitoren an den anderen Knoten des Systems aus, welche als Systemmonitore 428 und 430 erkannt werden. Der Systemmonitor 426 sendet dann eine Handshake-Botschaft an den Systemmonitor 428 an dem Knoten B. Die Handshake-Botschaft enthält ihren eigenen Status, jedoch keinen Standort-Token. Die Standort-Token werden verwendet, um den Status der anderen Knoten zu übertragen. Gleichzeitig sendet der Systemmonitor 426 die Handshake-Botschaft an den Knoten B und stellt weiterhin einen Intervallzeitgeber ein. Der Systemmonitor 426 sendet auch eine Handshake-Botschaft an das System 430 des Knotens C, die ebenfalls seinen eigenen Status, jedoch keinen Standort-Token enthält. Ein Intervallzeitgeber wird ebenfalls eingestellt. Der Systemmonitor 426 des Knotens A empfängt dann die Handshake-Botschaft von dem Systemmonitor 428 des Knotens B, welcher den Status des Knotens B enthält. Diese Information wird verwendet, um eine Statustabelle im Knoten A auf den neuesten Stand zu bringen. Der Systemmonitor 426 empfängt weiterhin von dem Systemmonitor 430 eine Handshake-Botschaft, die den Status des Knotens C enthält und verwendet die Daten darin, um die Statustabelle auf den neuesten Stand zu bringen.
Wenn der Intervallzeitgeber, der für den Knoten B eingestellt ist, abläuft, sendet der Systemmonitor 426 erneut eine Handshake-Botschaft an den Systemmonitor 428 des Knotens B mit dem Status des Knotens A und einem Standort-Token, der den Status des Knotens C, wie er in der Statustabelle protokolliert ist, enthält. Ebenso wird, wenn der zweite Intervallzeitgeber abgelaufen ist, weiterhin eine Handshake-Botschaft an den Knoten C mit dem Status des Knotens A und einem Standort-Token, der den Status des Knotens B enthält, abgesendet. Der Systemmonitor 428 im Knoten B antwortet dieses Mal auf die Handshake-Botschaft des Knotens A mit einer Handshake-Botschaft, die in einem Standort-Token sein eigenes Verständnis des Status des Knotens C enthält. Der Systemmonitor 426 des Knotens A vergleicht dann den Status des Knotens C, der von dem Knoten B empfangen wurde, mit dem Eintrag des Status des Knotens C in seine Statustabelle. Es ist zu bemerken, dass die Statustabelle des Knotens A den Knoten C als abgeschaltet auflisten kann, wenn eine der vorher an den Knoten C abgesendeten Handshake-Botschaften unbestätigt oder unbeantwortet bleibt. Daher wird, wenn sowohl die Statustabelle und die Handshake-Botschaft des Knotens B anzeigen, dass der Knoten C abgeschaltet ist, die Systemkonfigurationsdatenbank des Knotens A aktualisiert, um den Knoten C als abgeschaltet zu kennzeichnen. Der Knoten B, der genau den gleichen Prozess ausführt, wie er vorher beschrieben ist, erkennt ebenfalls den abgeschalteten Status des Knotens C und bringt seine Systemkonfigurationsdatenbank entsprechend auf den neuesten Stand.
Darauf beginnt die Übernahmeverarbeitung unter Verwendung eines Datensicherungsknotens, um die Transaktionslast des ausgefallenen Knotens zu übernehmen. Um Prozesse in dem Datensicherungsknoten zum Beginn der Verarbeitungstransaktionen des ausgefallenen Knotens anzusprechen, kann der Systemmonitor des Datensicherungsknotens eine Befehlsbotschaft an den Steuerpunkt desselben Knotens senden, die dazu auffordert, dass die Systemkonfigurationsdatenbank zu aktualisieren ist, um den Knoten als abgeschaltet zu kennzeichnen, wie es vorher beschrieben ist und dass eine Rundrufbotschaft an alle Prozesse an dem Datensicherungsknoten zu senden ist, dass die Übernahmeverarbeitung zu beginnen hat.
Während der Übernahmeverarbeitung, wenn ein oder mehr Knoten abgeschaltet sind, wird der Verkehr zu dem (den) ausgefallenen Knoten zu seinem (ihren) Datensicherungsknoten weitergeleitet. So ist zum Beispiel in 14 der Knoten B abgeschaltet und der Knoten A wurde vorher als sein Datensicherungssystem festgelegt. Jedes Prozessobjekt in dem System weist ebenfalls mindestens einen bezeichneten Datensicherungsprozess auf und der Verkehr wird zu den Datensicherungsobjekten weitergeleitet. So zeichnet zum Beispiel eine Terminaldefinitionsdatei die Netzwerkszugehörigkeitsdaten jedes Geldautomatenterminals auf und jede Terminaldefinitionsdatei kann einen Primärknotennamen und mindestens einen Datensicherungsknotennamen haben, der in der Systemkonfigurationsdatenbank gespeichert gehalten wird.
Wenn an dem Geldautomaten 52', der während der Übernahmeoperations-Betriebsart direkt mit dem Knoten B gekoppelt ist, eine Transaktion ausgelöst wird, wird sie zu dem Vorrichtungshandler 80 und zu dem Ablaufverfolger 110 des Knotens A zur Verarbeitung übertragen. Der Ablaufverfolger 110 stellt fest, dass für diese Transaktion während der Übernahmebetriebsart sein System das Datensicherungssystem ist und sendet die Transaktionsbotschaft zu dem Programm für die Zugriffsberechtigung 116. Das Programm für die Zugriffsberechtigung 116 stellt weiterhin fest, dass dies für die laufende Transaktion der Datensicherungsprozess für den Datensatz der speziellen Kartendefinitionsdatei (CDF) 118 ist und erteilt die Zugriffsberechtigung für die Transaktion. Das Programm für die Zugriffsberechtigung 116 kann während der Übernahmebetriebsart einen anderen Satz von vorher festgelegten Transaktions-Zugriffsberechtigungsbeschränkungen verwenden. Das Programm für die Zugriffsberechtigung 116 sendet dann die Botschaft zur Aufzeichnung der Transaktion an die Transaktionsjournaldatei (TJF) 122 und schreibt die Transaktion weiter in eine Speicher- und Weiterleitungsdatei (SAF) 432.
Wenn der Knoten B betriebsbereit wird, überträgt ein Wiederherstellungsprozess 434 die Datenbankaktualisierungen an die Kundenkontodatei (CAF) 436 und die Datei für positive Konten (PBF) 438, so dass sie aktualisiert werden und die Transaktionen, die während der Übernahmeperiode ablaufen, wiedergeben.
Die vorherige Beschreibung der vorliegenden Erfindung erfolgte allgemein im Zusammenhang mit der elektronischen Geld- und Informationsübertragung als ein Beispiel. Die vorliegende Erfindung ist jedoch auf alle Anwendungsprogramme anwendbar, die Online-Verbindungen mit externen Vorrichtungen oder Systemen erfordern. Andere Beispiele beinhalten die Anwendung für ein elektronisches Übertragungssystem auf dem Gebiet des Gesundheits- und Sozialwesens, den automatisierten Verkauf von Fahrscheinen und Verkaufs-Transaktionen über Kreditkarten. Der Schutzumfang der Erfindung ist durch die beigefügten Ansprüche definiert.

Claims

Ausfallsicheres, Ereignis-gesteuertes Transaktionsverarbeitungssystem (22) umfassend: eine Mehrzahl von Systemknoten (A, B, C) mit einer Mehrzahl von Anwendungsprozessen (36) zum Verarbeiten von Transaktionen, die durch eine Mehrzahl von äußeren Vorrichtungen (40, 44, 45) ausgelöst werden; ein Datenkommunikationssystem (30, 35), das eine Mehrzahl von Benachrichtigungsobjekten und Diensten für die Mahrzahl von Anwendungsprozessen (36) zum Weiterleiten, Senden und Empfangen von Botschaften zu und voneinander bereitstellt, wobei jeder Anwendungsprozess (36) seine eigene Ansicht von den anderen Anwendungsprozessen hat, mit denen er kommuniziert; eine Systemkonfigurationsdatenbank (37), die jedes Objekt und jeden Prozess und deren entsprechende Datensicherungsobjekte und -prozesse speichert, wobei die Systemkonfigurationsdatenbank (37) einen primären Knoten und Datensicherungsknoten jedem der Mehrzahl von äußeren Vorrichtungen (40, 44, 45) zuordnet, wobei das Datenkommunikationssystem (30, 35) betrieben werden kann, um Botschaften an geeignete Anwendungsprozesse an einen bestimmten Datensicherungsknoten weiterzuleiten als Antwort auf einen Fehler eines zugeordneten Knotens für diejenigen äußeren Vorrichtungen, die den fehlerhaften Knoten als den primären Knoten haben; und einen Systemmonitor (24), der an jedem Systemknoten (A, B, C) angeordnet ist, zum Überwachen des Betriebsstatus von jedem Systemknoten (A, B, C) und zum Kommunizieren des Betriebsstatus von jedem Systemknoten (A, B, C) zu einem anderen.
System nach Anspruch 1, wobei jeder Systemknoten (A, B, C) weiter umfasst: wenigstens eine Anwendungsdatenbank (300), die bei der Verarbeitung der Transaktionen verwendet wird; und wenigstens eine Datensicherungsanwendungsdatenbank (308).
System nach Anspruch 2, wobei die Anwendungsprozesse (36) weiter einen Datenbank-Synchronisationsprozess (306) zum Senden von Modifikationen an die Anwendungsdatenbank (300) und an ihre Datensicherungsanwendungsdatenbank umfassen.
System nach Anspruch 2, wobei die Anwendungsprozesse (36) weiter einen Datenbank-Wiederherstellungsprozess (434) umfassen zum Senden von Transaktionen, die von einem Datensicherungssystemknoten (A) verarbeitet wurden, zu einer Anwendungsdatenbank (300), die in einem abgeschalteten Systemknoten (B) angeordnet ist, nachdem dieser abgeschaltete Systemknoten (B) den Betrieb wieder aufnimmt.
System nach Anspruch 4, wobei die Transaktionen, die durch den Datensicherungssystemknoten (A) verarbeitet wurden, in einer vorher definierten Datenbank in dem Datensicherungssystem gespeichert werden, bis der abgeschaltete Systemknoten (B) den Betrieb wieder aufnimmt und der Datenbank-Wiederherstellungsprozess (434) die gespeicherten Transaktionen erfolgreich dahin sendet.
System nach Anspruch 1, wobei der Systemmonitor (24), der an jedem Knoten (A, B, C) angeordnet ist, ein Handshake-Protokoll umfasst zum Abfragen von an anderen Systemknoten (A, B, C) angeordneten Systemmonitoren (24) nach dem Status der anderen Systemknoten (A, B, C).
System nach Anspruch 1, das weiter eine Statustabelle umfasst, die für den Systemmonitor (24) zugänglich ist, zum Aufzeichnen des Status von jedem Systemknoten (A, B, C).
System nach Anspruch 1, wobei die Anwendungsprozesse (36) einen Autorisierungsprozess (116) zum Empfangen einer Botschaft, die eine Anfrage für eine Transaktion enthält, und zum Autorisieren der Anfrage enthalten.
System nach Anspruch 1, wobei die Anwendungsprozesse (36) einen Weiterleitungsprozess (110) zum Empfangen einer Botschaft, die eine Anfrage für eine Transaktion enthält, und zum Bestimmen eines Ziels für die Botschaft enthalten.
System nach Anspruch 1, wobei die Anwendungsprozesse (36) einen Journal-Prozess (120) zum Aufzeichnen jeder Transaktion enthalten.
System nach Anspruch 1, weiter umfassend: eine primären Kommunikationsverbindung zwischen jedem Systemknoten (A, B, C) und wenigstens einem anderen Systemknoten (A, B, C); und eine Datensicherungskommunikationsverbindung zwischen jedem Systemknoten (A, B, C) und wenigstens einem anderen Systemknoten (A, B, C), wobei die Datensicherungskommunikationsverbindung betriebsbereit ist, wenn die primäre Kommunikationsverbindung ausfällt.
System nach Anspruch 11, das weiter eine Steuerungskommunikationsverbindung (420, 422, 424) zwischen jedem Systemknoten (A, B, C) zum Kommunizieren von Steuerungsbotschaften umfasst.
Verfahren zum Betreiben eines ausfallsicheren, Ereignis-gesteuerten Transaktionsverarbeitungssystems umfassend die folgenden Schritte: Aufzeichnen eines logischen Identifikators, einer physikalischen Adresse und eines Status für jeden Knoten (A, B, C) in dem System in eine Systemkonfigurationsdatenbank (37), wobei jeder Knoten eine Mehrzahl von Anwendungsprozessen (36) zum Verarbeiten von Transaktionen hat, die von einer Mehrzahl von äußeren Vorrichtungen (40, 44, 45) ausgelöst werden; Zuordnen eines primären Knotens und eines Datensicherungsknotens in der Systemkonfigurationsdatenbank (37) für jede aus der Mehrzahl von äußeren Vorrichtungen (40, 44, 45); an jedem Knoten Abfragen aller Knoten (A, B, C) in dem System nach dem Knoten-Status und nach dem Verständnis des Status aller anderen Knoten (A, B, C) in dem System; und Weiterleiten von Verarbeitungsbotschaften zu einem Datensicherungsknoten (A) als Antwort auf die Bestimmung eines Knotens (B) als abgeschaltet für diejenigen der äußeren Vorrichtungen, die den abgeschalteten Knoten (B) als primären Knoten zugeordnet haben.
Verfahren nach Anspruch 13, wobei der Abfrage-Schritt die folgenden Schritte umfasst: Senden einer Handshake-Botschaft von jedem Knoten (A) zu jedem anderen Knoten (B) in dem System, wobei die Handshake-Botschaft den Status des Sender-Knotens (A) enthält; Empfangen der Handshake-Botschaft, auf den neuesten Stand Bringen eines Eintrages des Status des Sender-Knotens in einer Status-Tabelle und Antworten durch Senden einer Handshake-Botschaft zu dem Sender-Knoten (A), wobei die Handshake-Botschaft den Status des Empfänger-Knotens (B) enthält; wiederum Senden einer Handshake-Botschaft von jedem Knoten (A) zu jedem anderen Knoten (B) in dem System, wobei die Handshake-Botschaft den Status des Sender-Knotens (A) und aller Knoten (A, B, C) in dem System enthält, die von dem beabsichtigten Empfänger der Handshake-Botschaft abweichen; und Empfangen der Handshake-Botschaft, Vergleichen des Status aller Knoten (A, B, C) in der Botschaft mit den entsprechenden Einträgen in der Status-Tabelle.
Verfahren nach Anspruch 14, wobei der Abfrage-Schritt weiter die folgenden Schritte umfasst: Markieren eines Knotens (B) als abgeschaltet, wenn sowohl die Status-Tabelle als auch eine vorgegebene Zahl von Knoten (A, C) ebenfalls in der Handshake-Botschaft in dem Vergleichsschritt anzeigen, dass der Knoten (B) abgeschaltet ist; und Benachrichtigen eines Knotens (A), bezeichnet als Datensicherungsknoten, mit der Übernahme der Verarbeitung der Prozess-Belastung des abgeschalteten Knotens zu beginnen.
Verfahren nach Anspruch 13, weiter die folgenden Schritte umfassend: Durchführen einer Übernahme-Verarbeitung der Prozess-Belastung des abgeschalteten Knotens; Speichern der Transaktionen, die während der Übernahme-Verarbeitung durchgeführt werden; Weiterleiten der gespeicherten Transaktionen an den abgeschalteten Knoten (B), wenn dieser den Betrieb wieder aufnimmt; und auf den neuesten Stand bringen der Datenbank des abgeschalteten Knotens, um die während der Übernahme-Verarbeitung durchgeführten Transaktionen zu spiegeln.
Verfahren nach Anspruch 16, wobei der Transaktionsspeicherschritt den Schritt des Speicherns von Modifikationen an einem ausgewählten Satz von Datenbanken, die in der Übernahme-Verarbeitung verwendet werden, umfasst.
Verfahren nach Anspruch 13, weiter die folgenden Schritte umfassend: Vermerken von Modifikationen an Daten in wenigstens einer ausgewählten Anwendungsdatenbank (300); Weiterleiten der Modifikationen zu einer Datensicherungsanwendungsdatenbank (308); Durchführen derselben Modifikationen an den Daten, die in einer Datensicherungsanwendungsdatenbank (308) gespeichert sind.
Verfahren nach Anspruch 18, wobei die Schritte des Vermerkens, Weiterleitens und Durchführens der Modifikationen periodisch durchgeführt werden, um die Daten, die in der ausgewählten Datenbank (300) gespeichert sind, und ihre Datensicherungsanwendungsdatenbank (308) zu synchronisieren.