DE69723612T2 - Datenbanknetzwerk - Google Patents

Datenbanknetzwerk Download PDF

Info

Publication number
DE69723612T2
DE69723612T2 DE69723612T DE69723612T DE69723612T2 DE 69723612 T2 DE69723612 T2 DE 69723612T2 DE 69723612 T DE69723612 T DE 69723612T DE 69723612 T DE69723612 T DE 69723612T DE 69723612 T2 DE69723612 T2 DE 69723612T2
Authority
DE
Germany
Prior art keywords
event
hub
database
connection device
events
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
DE69723612T
Other languages
English (en)
Other versions
DE69723612D1 (de
Inventor
Rafael Cupertino Bracho
Tilman San Jose Sporkert
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.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems Inc
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 Sun Microsystems Inc filed Critical Sun Microsystems Inc
Publication of DE69723612D1 publication Critical patent/DE69723612D1/de
Application granted granted Critical
Publication of DE69723612T2 publication Critical patent/DE69723612T2/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
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/275—Synchronous replication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99944—Object-oriented database structure
    • Y10S707/99945—Object-oriented database structure processing

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

  • Anhänge
  • Der Anhang A, der ein Teil dieser Beschreibung ist und durch den Hinweis hierin aufgenommen wird, enthält eine Zusammenfassung von beispielhaften Systemereignissen, die zwischen Hubs in einem bevorzugten Ausführungsbeispiel der vorliegenden [Erfindung] übergeben werden können.
  • Hintergrund der Erfindung
  • Diese Anmeldung betrifft ein Informationsveröffentlichungssystem und insbesondere ein Verfahren zum Verbinden einer veralteten Datenbank mit einem Informationsveröffentlichungssystem.
  • Bestimmte herkömmliche Systeme verwenden ein "Transaktions"-Modell zum Austauschen von Information zwischen Knoten eines Datenverarbeitungssystems. In einem herkömmlichen Transaktionsmodell leiten zwei Anwendungen eine synchrone "Transaktion" ein, die solange aufrechterhalten wird, wie eine Information zwischen den Knoten ausgetauscht wird. Das Transaktionsmodell erfordert, dass eine Transaktion für jede Geschäftsaktivität festgelegt wird. Wenn Knoten in weitgehend ungleichen Teilen eines Netzwerks versuchen, über das Transaktionsmodell zu kommunizieren, ist es häufig schwierig, eine Transaktion festzulegen, die in allen Teilen des Systems gut funktioniert. Überdies kann eine Transaktion nur die Knoten beinhalten, die die Transaktion begonnen haben. Ein weiterer Knoten kann sich der Transaktion nicht in der Mitte anschließen. Dieses Schema ist für ein System, in dem Knoten über alle anderen Knoten im System nichts wissen, ungeeignet.
  • Die veröffentlichte Europäische Patentanmeldung mit dem Titel "Redundant Networked Database System", EP-A-0 593 062 (Siemens Industrial Automation), 20. April 1994, eingereicht am 14. Oktober 1993, richtet sich auf ein redundantes vernetztes Datenbanksystem. Gemäß der Zusammenfassung sind "Steuersystemcomputer für primäre und Sicherungsdatenbankoperationen ausgelegt, wobei Anwendungen entweder als primär oder Sicherung eingebbar sind. Bei Änderungen an der Datenbank kommunizieren die primären und Sicherungskommunikationsagenten miteinander und aktualisieren die Sicherung automatisch. In dieser Weise werden die primären und Sicherungsdatenbanken automatisch ohne manuellen Eingriff oder den Bedarf zur erneuten Eingabe der Änderungen in die Sicherungsdatenbank synchronisiert".
  • Viele kommerziellen Unternehmen verwenden immer noch Software, die vor langem entwickelt wurde und nicht mehr von ihrem Hersteller unterstützt wird. Eine solche Software wird "veraltete Software" genannt. Außerdem verwenden viele kommerziellen Unternehmen kommerzielle Softwareprodukte. Es ist nicht immer möglich oder erwünscht, eine existierende kommerzielle Software und veraltete Software zu modifizieren, damit sie mit einem neuen vernetzten System arbeitet. Die kommerzielle Software und veraltete Software kann sehr komplex sein, was sie schwierig und teuer zu modifizieren macht. Eine Firma kann sich davor hüten, Modifikationen an einem stabilen System vorzunehmen, das konsistent arbeitet. Überdies können keine Computerprogrammierer in einer Firma vorhanden sein, die das veraltete System ausreichend genau verstehen, damit sie an diesem Modifikationen vornehmen können. Schließlich kann eine Firma nicht den Quellencode für eine veraltete Anwendung haben, wenn sie die Anwendung von einem kommerziellen Verkäufer erworben hat. Eine Firma kann auch nicht ein legales Recht haben, eine kommerzielle Datenbanksoftware zu modifizieren. Was erforderlich ist, ist eine Art und Weise zum Integrieren einer kommerziellen und veralteten Datenbanksoftware in ein vernetztes System, ohne die Datenbanksoftware selbst modifizieren zu müssen.
  • Zusammenfassung der Erfindung
  • Die vorliegende Erfindung beseitigt die Probleme und Nachteile des Standes der Technik durch Bereitstellung eines "Datenbank-Verbindungsvorrichtungs"-Elements, das entweder als Anbieter oder Teilnehmer im Netzwerk wirken kann.
  • Die vorliegende Erfindung wird als Art "Middleware" implementiert. Middleware ist eine Software, die sich zwischen einem Anwendungsprogramm und einem Steuerebenenprogramm befindet. Die Middleware ist "netzwerkzentrisch" und konzentriert sich nicht auf eine spezifische Benutzerschnittstelle oder die Organisation einer spezifischen Datenbank. Das beschriebene Ausführungsbeispiel umfasst eine Vielzahl von "Anbieter"-Objekten, die Information veröffentlichen, und eine Vielzahl von "Teilnehmer"-Objekten, die die Information anfordern und verwenden. Anbieter und Teilnehmer sind durch ein Netzwerk miteinander verbunden. Das Netzwerk ist ein Netzwerk zum "Speichern und Weiterleiten", dessen Leitweglenkung "auf dem Inhalt basiert". In einem Leitwegsystem auf Inhaltsbasis wird die Information auf der Basis des Inhalts der Information und nicht der Adressen von Anbietern oder Teilnehmern in dem System geleitet. Im beschriebenen Ausführungsbeispiel wird die Information zu vielen Teilnehmern parallel verteilt.
  • Im beschriebenen Ausführungsbeispiel wird die Basismenge an Information "Ereignis" genannt. Anbieter veröffentlichen Ereignisse und Teilnehmer nehmen an Ereignissen teil, die vom Teilnehmer definierten Kriterien entsprechen. Im beschriebenen Ausführungsbeispiel werden Ereignisse durch Datenstrukturen in der C-Programmiersprache dargestellt, obwohl eine beliebige geeignete Darstellung verwendet werden kann.
  • Die Veröffentlichung und die Teilnahme werden asynchron durchgeführt. Anbieter und Teilnehmer haben keine direkte Kenntnis voneinander. Das System empfängt ein veröffentlichtes Ereignis von einem Anbieter und leitet das Ereignis zu allen geeigneten Teilnehmern weiter. Jedem Teilnehmer wird garantiert, alle im System veröffentlichten Ereignisse zu empfangen, wenn und nur wenn sie den Teilnahmekriterien, die vom Teilnehmer festgelegt werden, entsprechen.
  • Das beschriebene Ausführungsbeispiel umfasst eine Anwendungsprogrammschnittstelle (API) für Anbieter und für Teilnehmer. Die API legt eine Vielzahl von Prozeduren fest, die ermöglichen, dass jeweilige Anbieter und Teilnehmer mit dem System koppeln. Somit können verschiedene Arten von Anbietern und Teilnehmern mit dem System verbunden werden, solange sie die gemäß der API festgelegten Schnittstellenprozeduren verwenden. Das beschriebene Ausführungsbeispiel umfasst auch eine Unterstützung für eine Vielzahl von Softwareelementen, wie z. B. gemeinsamen Datenbanken, Installations- und Verwaltungswerkzeugen und Protokollleistungsmerkmalen. Somit wird das beschriebene Ausführungsbeispiel als "Unternehmenssystem" bezeichnet, da es in der ganzen Gesamtheit eines kommerziellen Unternehmens verwendet werden kann.
  • Das beschriebene Ausführungsbeispiel der vorliegenden Erfindung macht es leicht, veraltete Systeme, veraltete Anwendungen und veraltete Hardware in das System zu integrieren, und versucht, die Menge an Information, die ein Benutzer lernen muss, um das System zu verwenden, zu minimieren. Da die Kommunikation innerhalb des Systems auf asynchronen "Ereignissen" basiert, kann die vorliegende Erfindung in einem heterogenen Netzwerk implementiert werden, das sowohl PCs als auch Großrechner umfasst, die unter verschiedenen Betriebssystemen arbeiten und verschiedene Arten von Anwendungen abarbeiten. Das beschriebene Ausführungsbeispiel verwendet eine Umgebung mit verteilten Objekten und ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung implementiert den Standard des gemeinsamen Objektanforderungs-Informationsvermittlers (CORBA).
  • Gemäß dem Zweck der Erfindung, wie hierin verkörpert und grob beschrieben, betrifft die Erfindung ein Verfahren zum Verbinden einer Datenbank mit einem Anbieter/Teilnehmer-Netzwerk, so dass die Datenbank Ereignisse im Netzwerk veröffentlichen kann, wobei das Verfahren die vom Datenverarbeitungssystem durchgeführten Schritte umfasst: Vorsehen einer Übertragungsstrecke, so dass die Datenbank mit einem Computerprogramm einer Datenbank-Verbindungsvorrichtung durch ein Computerprogramm einer Transaktions-Überwachungseinrichtung kommunizieren kann; Einrichten der Datenbank-Verbindungsvorrichtung als Anbieterhub im Netzwerk; Empfangen eines Eingangssignals durch die Datenbank von einem Benutzer, der Daten in der Datenbank ändert; Informieren der Transaktions-Überwachungseinrichtung, dass die Daten geändert wurden; Empfangen eines Eingangssignals vom Benutzer, das angibt, dass die geänderten Daten übergeben werden sollten; Informieren der Transaktions-Überwachungseinrichtung, dass die geänderten Daten übergeben werden; und Senden eines veröffentlichten Ereignisses durch die Datenbank-Verbindungsvorrichtung gemäß einer Meldung von der Transaktions-Überwachungseinrichtung, dass die Daten übergeben werden, zum Netzwerk gemäß den geänderten Daten.
  • Die Aufgaben und Vorteile der Erfindung werden teilweise in der Beschreibung, die folgt, dargelegt und sind teilweise aus der Beschreibung offensichtlich oder können durch Ausführung der Erfindung gelernt werden. Die Aufgaben und Vorteile der Erfindung werden durch die Elemente und Kombinationen, auf die in den beigefügten Ansprüchen und Äquivalenten speziell hingewiesen wird, realisiert und erreicht.
  • Kurzbeschreibung der Zeichnungen
  • Die zugehörigen Zeichnungen, die in diese Beschreibung integriert sind und einen Teil von dieser bilden, stellen verschiedene Ausführungsbeispiele der Erfindung dar und dienen zusammen mit der Beschreibung zum Erläutern der Prinzipien der Erfindung.
  • 1 ist ein Blockdiagramm eines vernetzten Computersystems gemäß einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung.
  • 2 ist ein Ablaufplan, der Schritte zeigt, die zum Installieren einer Anwendung wie z. B. eines Anbieters an einem Hub von 1 durchgeführt werden.
  • 3 ist ein Ablaufplan, der Schritte zeigt, die von einem Anbieter von 1 durchgeführt werden, um Ereignisse zu veröffentlichen.
  • 4 ist ein Ablaufplan, der Schritte zeigt, die von einem Teilnehmer von 1 durchgeführt werden, um an Ereignissen teilzunehmen.
  • 5 ist ein Blockdiagramm, das Einzelheiten eines Hubs von 1 zeigt.
  • 6(a) ist ein Diagramm, das Datenstrukturen zeigt, die in einem Speicher des Hubs von 5 gespeichert sind.
  • 6(b) ist eine Auflistung von Details der Datenstrukturen von 6(a).
  • 7 ist ein Diagramm von zusätzlichen Datenstrukturen, die im Speicher des Hubs von 5 für den Zweck des Speicherns von Information über Kunden des Hubs gespeichert sind.
  • 8 zeigt ein Format einer Hüllkurvendatenstruktur eines Ereignisses.
  • 9 zeigt ein Format eines Leitwegblocks eines Ereignisses.
  • 10 ist ein Ablaufplan, der Details von Schritten zeigt, die von den Hubs von 1 durchgeführt werden, um die Datenstrukturen von 6(a) zu bestücken.
  • 11 ist ein Diagramm, das Beispiele der Datenstrukturen von 6(a) zeigt, die mit Daten bestückt sind.
  • 12 ist ein Ablaufplan, der Details von Schritten zeigt, die von den Hubs von 1 durchgeführt werden, um veröffentlichte Ereignisse zu Teilnehmern zu senden.
  • 13 ist ein Blockdiagramm einer Datenbankanwendung, die in das Netzwerk von 1 integriert ist.
  • 14 ist ein Ablaufplan, der Schritte zeigt, die durchgeführt werden, wenn die Datenbank ein Teilnehmer ist.
  • 15 ist ein Ablaufplan, der Schritte zeigt, die durchgeführt werden, wenn die Datenbank ein Anbieter ist.
  • Ausführliche Beschreibung der bevorzugten Ausführungsbeispiele
  • Nun wird im einzelnen auf die bevorzugten Ausführungsbeispiele der Erfindung Bezug genommen, von welchen Beispiele in den zugehörigen Zeichnungen dargestellt sind. Wann immer es möglich ist, werden in den gesamten Zeichnungen für die Bezugnahme auf die gleichen oder ähnliche Teile dieselben Bezugsziffern verwendet.
  • 1. Überblick
  • 1 ist ein Blockdiagramm eines vernetzten Computersystems 100 gemäß einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung. Das vernetzte Computersystem 100 umfasst eine Vielzahl von Anbietern 102, 110 und 116 und eine Vielzahl von Teilnehmern 104, 112 und 118. Der Anbieter 102 und der Teilnehmer 104 sind über einen Hub 106 mit einem Netzwerk 120 verbunden. Der Anbieter 110 und der Teilnehmer 112 sind über einen Hub 108 mit dem Netzwerk 120 verbunden. Der Anbieter 116 und der Teilnehmer 118 sind über einen Hub 114 mit dem Netzwerk 120 verbunden. Der Hub 106 und seine angeschlossenen Anbieter und Teilnehmer befinden sich in einem ersten Gebiet 130. Die Hubs 108 und 114 und ihre angeschlossenen Anbieter und Teilnehmer befinden sich in einem zweiten Gebiet 140. Weitere Gebiete (nicht dargestellt) existieren ebenfalls im Netzwerk 120. "Hubs", "Anbieter", "Teilnehmer" und "Gebiete" werden der Reihe nach nachstehend erörtert.
  • Wie durch gestrichelte Linien in 1 angegeben, können sich jeder Anbieter, Teilnehmer und Hub in separaten Computern (102, 104 und 106), im gleichen Computer (108, 110 und 112) oder in einer gewissen Kombination von separaten Computern und dem gleichen Computer (114, 116 und 118) befinden. Die Hubs können null oder mehr Anbieter und null oder mehr Teilnehmer aufweisen. Die Hubs können auch direkt mit anderen Hubs verbunden sein.
  • Es ist für Fachleute selbstverständlich, dass jeder Computer (in 1 durch gestrichelte Linien dargestellt) eine CPU, einen Speicher und Eingabe/Ausgabe-Leitungen umfasst. Diese Elemente sind in der Figur der Deutlichkeit des Beispiels halber nicht dargestellt. Jeder Computer kann auch zahlreiche andere Elemente umfassen, wie z. B. Plattenlaufwerke, Tastaturen, Anzeigevorrichtungen, Netzwerkverbindungen, einen zusätzlichen Speicher, zusätzliche CPUs usw. Die Anbieter, Teilnehmer und Hubs werden vorzugsweise als Softwarebefehle implementiert, die in einem Speicher gespeichert sind und von einem Prozessor eines Computersystems ausgeführt werden. Gewöhnlich wird die Anbieter-, Teilnehmer- und Hub-Software von einem Prozessor des Computers ausgeführt, in dem die Software gespeichert ist, obwohl ein Prozessor eines anderen Computersystems auch die Software ausführen könnte.
  • Ein bevorzugtes Ausführungsbeispiel der Erfindung läuft unter dem Solaris-Betriebssystem, Version 2.4. Solaris ist eine Handelsmarke einer eingetragenen Handelsmarke von Sun Microsystems, Inc. in den Vereinigten Staaten und anderen Ländern und basiert auf dem Unix-Betriebssystem. Unix ist eine eingetragene Handelsmarke in den Vereinigten Staaten und anderen Ländern, die ausschließlich durch X/OPEN, Ltd. lizenziert ist. Das vernetzte Computersystem 100 verwendet ein Netzwerkkommunikationsprotokoll wie z. B. TCP/IP, obwohl ein beliebiges geeignetes Protokoll verwendet werden kann, um die vorliegende Erfindung zu implementieren.
  • Im beschriebenen Ausführungsbeispiel veröffentlicht ein "Anbieter" Ereignisse bestimmter Arten im Netzwerk 120 und ein "Teilnehmer" nimmt an Ereignissen bestimmter Arten teil. Der Anbieter und der Teilnehmer arbeiten asynchron und sind sich der gegenseitigen Existenz nicht bewusst. die Verwendung eines Modells zum "Veröffentlichen und Teilnehmen" isoliert Anwendungen vom Netzwerk und voneinander. Die Veröffentlichung kann man sich als Senden eines Ereignisses vorstellen. Die Ereignisart ist analog zu einer Radiostation. Anwendungen, die an einer speziellen Station interessiert sind, nehmen an einer speziellen Ereignisart teil (oder schalten diese ein). Genau wie beim Radiorundfunk, bei dem sich alle beteiligten Parteien im voraus auf einen Satz von möglichen Frequenzen einigen müssen, müssen sich Anwendungen im beschriebenen Ausführungsbeispiel im voraus auf einen vorbestimmten Satz von Ereignisarten einigen.
  • Das beschriebene Ausführungsbeispiel der vorliegenden Erfindung verwendet "Teilnahme nach Inhalt". Die Teilnehmer legen auf der Basis einer Ereignisart und des Inhalts des Ereignisses fest, was sie wollen. Das beschriebene Ausführungsbeispiel macht von Verfahren zum "Speichern und Weiterleiten" für Ereignisse Gebrauch. Dieser Begriff bedeutet, dass das System ein Ereignis puffert, so dass, selbst wenn ein Anbieter offline ist, ein Teilnehmer immer noch Ereignisse abrufen kann. Ebenso kann ein Anbieter Ereignisse veröffentlichen, selbst wenn ein Teilnehmer offline ist.
  • Das beschriebene Ausführungsbeispiel wird in Einheiten von Hubs verwaltet. Ein Hub wie z. B. der Hub 106 ist ein lokaler Verbindungspunkt für einen Anbieter und/oder einen Teilnehmer. Sowohl Anbieter als auch Teilnehmer werden "Kunden" von Hubs genannt. Ein Anbieter verwendet eine "Anzeige", um dem System mitzuteilen, welche Arten von Ereignissen es veröffentlichen soll und wie es sie veröffentlichen soll (z. B. täglich, wenn jeder Ereignisauslöser auftritt usw.). Anzeigen werden am Hub, der mit dem Anbieter verbunden ist, während der Installation des Anbieters registriert. Eine Anzeige muss einen eindeutigen Namen aufweisen. Zusätzlich dazu, dass sie einen Namen einer zu veröffentlichenden Ereignisart enthält, enthält eine Anzeige eine weitere Information über den Anbieter. Diese Information kann das Prioritätsniveau für die veröffentlichten Ereignisse, für wie lang die Ereignisse gültig sind, usw. umfassen. Hubs übertragen Anzeigen zu allen potentiellen Teilnehmern. Hubs übertragen veröffentlichte Ereignisse zu allen Teilnehmern, die sich Ereignissen derjenigen Art angeschlossen haben, deren Inhalt der Teilnahme des Teilnehmers entspricht.
  • II. Anbieter und Teilnehmer
  • Die folgenden Absätze beschreiben die Schritte, die erforderlich sind, um eine Anwendung (entweder einen Anbieter oder einen Teilnehmer) zu erzeugen und sie an einem Hub zu installieren. Die folgenden Absätze beschreiben ferner die Schritte, die von einem Beispielanbieter zum Veröffentlichen von Ereignissen und von einem Beispielteilnehmer zum Teilnehmen an Ereignissen durchgeführt werden. Das beschriebene Ausführungsbeispiel ermöglicht einem Programmierer, eine Software für Anwendungen (Anbieter und Teilnehmer) in einer problemorientierten Sprache zu schreiben und unter Verwendung von Routinen, die in einer API festgelegt sind, und unter Verwendung von Ereignisbehandlungsroutinen, die für jede vom Benutzer festgelegte Ereignisart erzeugt werden, mit dem Hub zu koppeln.
  • 2 ist ein Ablaufplan, der Schritte zeigt, die durchgeführt werden, um eine Anwendung, z. B. einen Anbieter, an einem Hub zu installieren. 3 ist ein Ablaufplan, der Schritte zeigt, die von einem installierten Anbieter durchgeführt werden, um ein Ereignis zu veröffentlichen. 4 ist ein Ablaufplan, der Schritte zeigt, die von einem Teilnehmer von 1 durchgeführt werden, um an Ereignissen bestimmter Art und bestimmten Inhalts teilzunehmen. Wie vorstehend erörtert, werden sowohl Anbieter als auch Teilnehmer vorzugsweise als Softwareprogramme, die von einem Prozessor ausgeführt werden, implementiert.
  • Das beschriebene Ausführungsbeispiel ist um das Senden (Veröffentlichung) und Empfangen (Teilnehmen) von Ereignissen zentriert. Bevor ein Anbieter Ereignisse veröffentlichen kann, muss der Anbieter die Ereignisse festlegen und ausschreiben, die er veröffentlichen will. Damit die Ereignisse Sinn machen, müssen Anbieter und Teilnehmer einander verstehen. Aus diesem Grund verwendet das beschriebene Ausführungsbeispiel eine Standardspezifikationssprache, um Ereignisse festzulegen. In Schritt 202 von 2 legt der Anbieter ein oder mehrere Ereignisse fest, die von diesem Anbieter veröffentlicht werden können. Das beschriebene Ausführungsbeispiel des beschriebenen Ausführungsbeispiels ermöglicht die Festlegung von Ereignissen unter Verwendung einer Industriestandard-Schnittstellendefinitionssprache (IDL). IDL ist eine Standardschnittstelle, die von der Objektverwaltungsgruppe (OMG) verbreitet wurde, obwohl eine beliebige anwendbare Syntax zum Beschreiben der Struktur des Ereignisses in Verbindung mit dem beschriebenen Ausführungsbeispiel verwendet werden könnte. In Schritt 204 werden die OMG-IDL-Definitionen der Ereignisse in Datenstrukturen in der C-Programmiersprache übersetzt.
  • Man nehme beispielsweise an, dass eine Anwendung "Verkaufsbestellungs"-Ereignisse veröffentlicht. Bevor die Anwendung zum System hinzugefügt werden könnte, und unter der Annahme, dass keine weiteren Anwendungen, die sich mit Verkaufsbestellungs-Ereignissen befassen, bereits existieren würden, würde ein Programmierer ein "Verkaufsbestellungs"-Ereignis unter Verwendung von OMG IDL folgendermaßen definieren:
    Figure 00130001
  • Die obige Syntax definiert ein Ereignis als "Schnittstelle" und definiert die Datenelemente in dem Ereignis als "Attribute".
  • Nachdem ein oder mehrere Ereignisse definiert wurden, werden die Ereignisse in Strukturdefinitionen der C-Programmiersprache übersetzt. Vorzugsweise wird diese Übersetzung von einem OMG-IDL-Kompilierer durchgeführt, der eine Kopfdatei und eine Codedatei für jedes Ereignis erzeugt. Die erzeugte Kopfdatei enthält einfache C-Sprachstrukturen, die die Ereigniserklärungen für die in der Codedatei definierten Artfunktionen darstellen. Die C- Strukturdefinition, die für das obige Beispielereignis der Art Verkaufsbestellung erzeugt wird, ist:
    Figure 00140001
  • Ein üblicher Fachmann wird leicht verstehen, wie die IDL des Beispiels in die vorstehend gezeigten C-Programmiersprachen-Strukturdefinitionen übersetzt.
  • Die von der Ereignisdefinition erzeugte Codedatei enthält Prozeduren zum Behandeln von Ereignissen der definierten Art (hier für das Verkaufsbestellungs-Ereignis). Die Prozeduren führen zumindest die folgenden Operationen durch:
  • Zur Verwendung von einem Anbieter:
  • Erzeugen eines Ereignisses der Art Verkaufsbestellung,
    Veröffentlichen eines Ereignisses der Art Verkaufsbestellung,
    Löschen eines Ereignisses der Art Verkaufsbestellung.
  • Zur Verwendung von einem Teilnehmer:
  • Drucken des Inhalts des Ereignisses der Art Verkaufsbestellung,
    Registrieren der Teilnahme für ein Ereignis der Art Verkaufsbestellung.
  • Ein üblicher Fachmann wird verstehen, dass, obwohl die obige Vielzahl von Prozeduren für jedes definierte Ereignis erzeugt wird, die Operation der Prozeduren sich aufgrund der Unterschiede in den Strukturen des Ereignisses unterscheidet. Die Prozeduren unterscheiden sich auch aufgrund der Tatsache, dass das beschriebene Ausführungsbeispiel eine Artfunktion verwendet, um Programmierfehler zu verhindern.
  • Der Prozess der Installation einer Prozessanwendung in einem Hub umfasst das Speichern von einer oder mehreren Anzeigen in dem Hub, wie in Schritt 206 gezeigt. Diese Anzeigen definieren Arten von Ereignissen, die der Hub kennt. Eine Anzeige umfasst den Namen der Anzeige, eine Beschreibung des Ereignisses, das ein Anbieter veröffentlicht (z. B. ein Verkaufsbestellungs-Ereignis), eine Beschreibung, wie der Anbieter seine Ereignisse veröffentlicht (z. B. täglich, wenn ein Ereignisauslöser auftritt usw.), den Namen der Ereignisart, das Prioritätsniveau der Ereignisse und die Ablaufzeit der Ereignisse (auch "Lebenszeit" genannt). Obwohl in der Figur nicht dargestellt, ermöglicht das beschriebene Ausführungsbeispiel auch Zugriffssteuergenehmigungen für die verschiedenen festzulegenden Ereignisarten.
  • Das beschriebene Ausführungsbeispiel umfasst auch vordefinierte Routinen in einer API, die für die Anbieter- und Teilnehmersoftware zur Verfügung stehen und die Routinen umfassen, um zumindest die folgenden Funktionen durchzuführen:
    Registrieren eines Kunden,
    Wiederherstellen eines Kunden bei einer existierenden Sitzung,
    Austragen eines Kunden,
    Registrieren der Absicht zum Veröffentlichen,
    Austragen einer Veröffentlichung,
    Veröffentlichen eines Ereignisses,
    Teilnehmen an einem Ereignis,
    Reaktivieren einer aktiven Teilnahme an einem Ereignis, und Abbrechen einer Teilnahme.
  • Andere erfindungsgemäße APIs können etwas andere API-Funktionen umfassen. Außerdem umfasst die API vorzugsweise eine Routine "can_subscribe " und eine Routine "can_publish", die einen Booleschen Wert zurückgeben, der angibt, ob die aufrufende Anwendung an Ereignissen einer bestimmten Art teilnehmen oder diese veröffentlichen kann. Die API umfasst auch eine Routine "get_current_envelope", die eine Information über den Anbieter eines Ereignisses, und wie das Ereignis veröffentlicht wurde, zurückgibt. (Diese Routine kann nur von der Rückruf-Prozedur aufgerufen werden.) Eine Rückruf-Prozedur wird z. B. aufgerufen, wenn ein Teilnehmer ein Ereignis empfängt. 8 zeigt ein Format einer Hüllkurvendatenstruktur für ein Ereignis, die nachstehend in Verbindung mit der Ereignisleitweglenkung erörtert wird.
  • Es ist selbstverständlich, dass, wenn die Ereignisbeschreibung für einen Anbieter oder einen Teilnehmer anfänglich z. B. in C übersetzt wird, die Ereigniskopfdatei, deren Erzeugung vorstehend erörtert wurde, innerhalb des Anwendungssoftware-Quellencodes enthalten ist. In dem Beispiel hat der Anbieter folglich Zugriff auf die Definition des Verkaufsbestellungs-Ereignisses. Die Übersetzung verknüpft auch die Ereignisbehandlungsroutinen und die API-Routinen zu diesem Zeitpunkt mit der Anwendung. Der Hub überträgt zusammen mit anderen Hubs eine Mitteilung der Anzeigenexistenz zu potentiellen Teilnehmern, wie nachstehend erörtert.
  • Sobald ein Anbieter in einem Hub installiert ist, kann er Anzeigen und Ereignisse frei veröffentlichen. 3 ist ein Ablaufplan, der Schritte zeigt, die von einem Anbieter von 1 während der Operation des Anbieters durchgeführt werden. Die Schritte, die einen Aufruf der Ereignisbehandlungsroutinen beinhalten, die durch Kompilieren der IDL erzeugt werden, sind in der Figur durch einen Stern gekennzeichnet.
  • Wie in Schritt 302 von 3 gezeigt, registriert sich der Anbieter zuerst als Kunde am Hub, mit dem er verbunden ist. Der Anbieter verständigt als nächstes den Hub darüber, welche "Anzeige" er bei der Veröffentlichung verwenden will. Eine Anzeige stellt eine "Absicht zum Veröffentlichen" dar und teilt dem Hub mit, welche Art Ereignis der Anbieter veröffentlicht. Um den Hub in Schritt 302 zu verständigen, teilt der Anbieter dem Hub den Namen einer Anzeige mit, die vorher im Hub installiert wurde (siehe 2).
  • In Schritt 304 wartet der Anbieter, bis es Zeit ist, ein Ereignis zu veröffentlichen. Einige Anbieter wie z. B. im obigen Beispiel veröffentlichen jedes Ereignis zu dem Zeitpunkt, zu dem es auftritt. Andere Anbieter warten bis zu einem festgelegten Zeitpunkt, wie z. B. einmal am Tag, und veröffentlichen alle unveröffentlichten Ereignisse zu diesem Zeitpunkt. Ein erster Anbieter kann beispielsweise ein Ereignis veröffentlichen, sobald ein menschlicher Operator eine Verkaufsbestellung in das System eingibt. Ein zweiter Anbieter kann dieselbe Art Ereignis auf einer stündlichen Basis veröffentlichen. Sobald der Anbieter feststellt, dass ein Ereignis erzeugt werden soll, ruft er (in Schritt 306) eine der Ereignisbehandlungsroutinen auf, die eine C-Struktur mit dem korrekten Format für das zu veröffentlichende Ereignis erzeugt.
  • In Schritt 308 ruft der Anbieter eine der Ereignisbehandlungsroutinen auf, um unveröffentlichte Ereignisse zu veröffentlichen, wie nachstehend genauer erörtert. In Schritt 310 ruft der Anbieter eine der Ereignisbehandlungsroutinen auf, um das veröffentlichte Ereignis zu löschen. (Welches Objekt auch immer für das Zuweisen eines Ereignisses verantwortlich ist, ist im Allgemeinen im beschriebenen Ausführungsbeispiel auch für das Löschen dieses Ereignisses verantwortlich.)
  • In Schritt 312 stellt der Anbieter fest, ob er die Ausführung beenden sollte. wenn nicht, kehrt die Steuerung zu Schritt 304 zurück. Wenn ja, trägt sich der Anbieter in Schritt 314 aus dem Hub aus und hält die Ausführung an. Anzeigen werden im Hub beibehalten, um anzuzeigen, dass ein Anbieter diese Ereignisse ausführen und senden könnte. Diese Information ist erforderlich, um Leitwege zu Teilnehmern aufzubauen, wie nachstehend beschrieben. Obwohl in der Figur nicht gezeigt, können andere Anbieter, die mit demselben Hub verbunden sind, asynchron mit den Schritten von 3 arbeiten.
  • Teilnehmer nehmen an Ereignissen von speziellen Ereignisarten teil. 4 ist ein Ablaufplan, der Schritte zeigt, die von einem Teilnehmer von 1 während der Operation des Teilnehmers durchgeführt werden. Der Teilnehmer registriert sich zuerst als Kunde des Hubs. Dann registriert er für jede Teilnahme eine "Rückruf"-Prozedur.
  • Wie in Schritt 402 gezeigt, registriert sich der Teilnehmer als nächstes als Kunde am Hub, mit dem er verbunden ist. Der Teilnehmer registriert dann eine "Teilnahme" für die Ereignisart, die er über den Hub empfangen will. (Der Teilnehmer kann den Hub betrachten, um zu sehen, welche Arten von Ereignissen ausgeschrieben sind.) Eine Teilnehme legt eine Art Ereignis fest und kann ferner ein "Filter" festlegen, das anzeigt, dass der Teilnehmer nur Ereignisse einer bestimmten Art empfangen will, die auch bestimmte Werte in bestimmten Feldern aufweisen.
  • In Schritt 404 definiert der Anbieter für jede Teilnahme eine vorbestimmte "Rückruf"-Prozedur. Die Rückruf-Prozedur wird vom Hub eingeleitet, sobald der Hub feststellt, dass der Teilnehmer ein Ereignis einer bestimmten Art empfangen hat. Das Format des Rückrufs kann für jedes Betriebssystem, auf dem die vorliegende Erfindung implementiert wird, unterschiedlich sein und die Rückruf-Prozedur kann praktisch eine beliebige Prozedur sein, die durchgeführt wird, wenn ein Ereignis empfangen wird. In Schritt 406 von 4 könnte die Rückruf-Prozedur beispielsweise den Inhalt des Ereignisses ausdrucken (unter Verwendung von einer der Ereignisbehandlungsprozeduren, die dazu ausgelegt sind, ein Ereignis dieser Art auszudrucken). Da eine Rückruf-Prozedur für jede Teilnahme definiert wird, muss eine Rückruf-Prozedur für jede Art Ereignis definiert werden, an dem der Teilnehmer plant teilzunehmen. Im beschriebenen Ausführungsbeispiel wird ein in eine Rückruf-Prozedur weitergeleitetes Ereignis gelöscht, wenn die Rückruf-Prozedur zurückkehrt. Wenn der Teilnehmer irgendeine Information des Ereignisses behalten will, sollte die Information folglich aus dem Ereignis innerhalb der Rückruf-Prozedur kopiert werden.
  • Der Teilnehmer durchläuft eine Schleife, bis es Zeit ist, die Ausführung zu beenden (siehe Schritt 408). Die Rückruf-Prozedur kann nullmal, einmal oder viele Male während dieser Schleife aktiviert werden, wenn Ereignisse der festgelegten Art und Werte vom Hub empfangen werden. Wenn ein Ereignis, an dem der Teilnehmer teilnimmt, empfangen wird, werden die Rückruf-Prozeduren in Schritt 406 ausgeführt. Wenn der Teilnehmer in Schritt 408 feststellt, dass es für ihn Zeit ist zu beenden, trägt der Teilnehmer wahlweise seine Teilnahme aus, trägt sich aus dem Hub aus und beendet die Ausführung. Teilnahmen können auch im Hub beibehalten werden, um zukünftige Ereignisse während der Trennung zu empfangen. Der Hub stellt Ereignisse, die für die Teilnahmen ankommen, in eine Warteschlange. Obwohl in der Figur nicht dargestellt, können andere Teilnehmer, die mit demselben Hub verbunden sind, Schritte asynchron mit den Schritten von 4 durchführen.
  • Die folgenden Beispiele sind in der C-Programmiersprache geschrieben und zeigen eine Beispielsoftware für einen Anbieter und Teilnehmer.
  • Figure 00200001
  • Figure 00210001
  • Figure 00220001
  • III. Hubs
  • 5 ist ein Blockdiagramm, das Details des Hubs 106 von 1 zeigt. Die Hubs 108 und 114 von 1 und tatsächlich alle anderen Hubs im beschriebenen Ausführungsbeispiel weisen eine ähnliche Struktur auf. Der Hub 106 ist mit entfernten Hubs 108 und 114 über ein Netzwerk 120 (oder direkt) und mit null oder mehr Anbietern 102 und null oder mehr Teilnehmern 104 verbunden. Der Hub 106 empfängt auch eine Information 530, die die Hubverwaltung betrifft, eine Information 532, die die Verwaltung seiner Kunden (Anbieter und Teilnehmer) betrifft, und eine Information 536, die die Systemereignisverwaltung betrifft.
  • Jegliche Eingabe und Ausgabe in den und aus dem Hub 106 wird in eine Warteschlange gestellt. Ereignisse, die durch den Hub 106 vom entfernten Hub 108 und vom Anbieter 102 empfangen werden, werden beispielsweise in der Ereignisprioritätsreihenfolge in jeweiligen Ereignisschlangen 502, 504 gespeichert, bis der Hub 106 Zeit hat, sie zu verarbeiten. Als weiteres Beispiel werden vom Hub 106 zum entfernten Hub 114 und zum Teilnehmer 104 zu sendende Ereignisse in der Ereignisprioritätsreihenfolge in jeweiligen Ereignisschlangen 506, 508 im Speicher gespeichert, bis der Hub 106 Zeit hat, sie zu senden. Die Hubs verteilen die Ereignisse unter Verwendung eines FIFO- Grundsatzes (zuerst eingehende Daten werden zuerst ausgelesen). Dies bedeutet, dass alle Ereignisse mit demselben Prioritätsniveau vom Hub 106 in der Reihenfolge geliefert werden, in der sie vom Anbieter angenommen werden. Alle Ereignisse mit einem höheren Prioritätsniveau werden früher geliefert als wartende Ereignisse mit einem niedrigeren Prioritätsniveau. Das beschriebene Ausführungsbeispiel garantiert, die Reihenfolge von gleichen Ereignissen von einem einzelnen Anbieter aufrechtzuerhalten, wenn sich die Ereignisse durch das System bewegen. Dies ist beispielsweise bei einer Transaktionsverarbeitung wichtig, bei der eine Reihenfolge von Aktualisierungen aufrechterhalten werden muss. Die Reihenfolge unter den Anbietern wird nicht garantiert, da sie von Leitweglenkungs- und Verfügbarkeitsproblemen abhängt.
  • 5 zeigt auch die folgenden Funktionsblöcke innerhalb des Hubs 106: Kundenverwaltungsblock 510, Ereignisverwaltungsblock 512, Vorprozessorblock 514, Speicherblock 516, Vergleichsblock 518 und Fernverwaltungsblock 520. Der Kundenverwaltungsblock 510 befasst sich mit der Registrierung und Austragung von Kunden. Der Ereignisverwaltungsblock 512 befasst sich mit der Verwaltung von Systemereignissen, wie z. B. Empfang von neuen Verbindungen, Arten, Leitwegen, Anzeigen und Teilnahmen. Der Vorprozessorblock 514 führt Aufgaben durch, wie z. B. Hinzufügen einer Hüllkurveninformation zu einem Ereignis. Der Speicherblock 516 ist ein Speicher des Hubs. Der Vergleichsblock 518 fügt eine Leitweginformation zu Ereignissen hinzu, filtert Ereignisse in einer nachstehend in Verbindung mit der Ereignisleitweglenkung beschriebenen Weise und leitet Ereignisse zu entsprechenden anderen angeschlossenen Hubs. Der Fernverwaltungsblock 520 führt Systemverwaltungsaufgaben durch.
  • 7 ist ein Diagramm von Datenstrukturen, die in einem Speicher 690 des Hubs 106 von 1 gespeichert sind, der für alle Funktionsblöcke von 5 zugänglich ist. Die Datenstrukturen umfassen eine Tabelle von installierten Anzeigen 700, eine Tabelle von registrierten Kunden 730, eine Tabelle von registrierten Veröffentlichungen 760 und eine Tabelle von registrierten Teilnahmen 770. Die Daten werden in die Datenstrukturen von 7 gesetzt, wenn der Anbieter und der Teilnehmer die verschiedenen Schritte von 2, 3 und 4 folgendermaßen durchführen.
  • Schritt 202 von 2 füllt Einträge der Tabelle 700 von installierten Anzeigen.
  • Die Schritte 302 und 402 von 3 und 4 füllen Einträge der Tabelle 730 von registrierten Kunden. Das Benutzernamenfeld 734 und das Benutzerpasswortfeld 736 können einen NULL-Wert aufweisen, um anzuzeigen, dass die aktuelle Benutzer-ID verwendet werden sollte. Der Hubname 737 und der Gebietsname 740 können auf NULL gesetzt werden, um die Verwendung eines Vorgabehubs und -gebiets anzuzeigen. Die Kennzeichen 742 umfassen beispielsweise einen Booleschen Wert "Rückruf bei beliebiger Befehlsfolge", der anzeigt, dass Ereignisrückrufe bei neuen Befehlsfolgen auftreten.
  • Schritt 302 von 3 füllt auch Einträge der Tabelle 760 von registrierten Veröffentlichungen.
  • Der Anzeigenname 764 ist der Name einer Anzeige, die im Hub installiert wurde. Schritt 404 von 4 füllt auch Einträge der Tabelle 770 von registrierten Teilnahmen. Die Inhaltsfilter 774 werden nachstehend erörtert. Ein Name einer Rückruf-Prozedur wird lokal im Teilnehmer (durch die C-API) gehalten. Die API findet den Rückruf aus der Teilnahme-ID. Ein Kundendatenfeld, das auch von der API gehalten wird, ermöglicht, dass eine Information, die der Teilnahme zugeordnet ist, mit jedem Ereignisrückruf zurückgeleitet wird. Die Information, die zurückgeleitet wird, hat eine Bedeutung für die Teilnahmeanwendung.
  • Die folgenden Abschnitte beschreiben die verschiedenen Arten von Inhaltsfiltern, die von einem Teilnehmer festgelegt werden können, wenn er eine Teilnahme registriert. Wie in dem obigen Beispiel gezeigt, können Teilnehmer anfordern, dass der Hub den eingehenden Fluss von Ereignissen filtert und nur Ereignisse zu den Teilnehmern weiterleitet, die bestimmten Kriterien entsprechen. Ein Filter wird vorzugsweise als Ausdruckszeichenfolge festgelegt, die vom Teilnehmer als Parameter zur Routine zum Registrieren von Teilnahmen gesandt wird. Die Ausdruckszeichenfolgesyntax für ein Inhaltsfilter im beschriebenen Ausführungsbeispiel ist folgendermaßen. (Natürlich könnte eine beliebige geeignete Syntax verwendet werden):
    Figure 00250001
  • Ereignisattributnahmen werden verwendet, um zu kennzeichnen, welches Feld im Ereignis verglichen werden sollte. Unterfelder (jene innerhalb von Strukturen) werden unter Verwendung einer Punkt-Schreibweise festgelegt. Namen können auch aufgezählte Arten sein, wie Personen bekannt ist, die mit der C-Programmiersprache vertraut sind. Sobald ein Inhaltsfilter festgelegt wurde, wird er während der Ereignisleitweglenkung verwendet, wie nachstehend in Verbindung mit 8–12 beschrieben. Eine Information, die jedes Inhaltsfilter für eine Teilnahme beschreibt, wird im Feld 774 von 7 gespeichert.
  • 6(a) ist ein Diagramm, das Datenstrukturen zeigt, die in einem Speicher 690 des Hubs 106 von 5 gespeichert sind. Alle Hubs enthalten ähnliche Datenstrukturen. Die beschriebene Implementierung verwendet ein Modell mit verteilten Objekten, aber eine beliebige geeignete Organisationsstruktur könnte verwendet werden. Die Details der Datenstrukturen von 6(a) sind in 6(b) aufgelistet. Idealerweise beschreiben die Datenstrukturen von 6(a) alle Anzeigen in dem System und geben einen Nachbarhub an, zu dem der aktuelle Hub Ereignisse bestimmter Arten senden sollte. 10 bzw. 12 beschreiben die Schritte zum Bestücken der Datenstrukturen von 6(a) und zum Verwenden der Datenstrukturen von 6(a), um Ereignisse unter den Hubs zu leiten. 11 zeigt ein Beispiel der mit Daten bestückten Datenstrukturen.
  • Der Hub 106 (der "aktuelle Hub") umfasst Datenobjekte, die folgendes darstellen: jeden Kunden des aktuellen Hubs, der ein Teilnehmer ist (durch "Kunde" 684 und "S" 695 angegeben), und jeden benachbarten Hub, der mit dem aktuellen Hub verbunden ist ("Nachbar A" 696 und "Nachbar B" 697). Der aktuelle Hub verfolgt die Teilnahmeobjekte seiner Nachbarhubs. Die Teilnahmeobjekte "S" 650 stellen alle Teilnehmer dar, die durch die jeweiligen Nachbarn erreicht werden können. Jedes Nachbarobjekt weist zwei zugehörige Kostenwerte auf: "mycost" und "theircost". "Mycost" stellt Kosten zum Senden einer Information vom aktuellen Hub zum Nachbarn dar. "Theircost" stellt Kosten zum Senden einer Information vom Nachbarn zum aktuellen Hub dar. "Theircost" wird zum Festlegen eines Leitwegs, wie nachstehend beschrieben, verwendet. Der Teilnahmehub bittet den "veröffentlichenden" Hub mit den niedrigsten "theircost", die Ereignisse weiterzuleiten. "Mycost" wird vorzugsweise nur verwendet, um die Nachbarn darüber zu informieren, wie viel es den aktuellen Hub kosten würde, eine Information über diese Übertragungsstrecke zu senden. "Kosten" kann man sich in einer Anzahl von Weisen vorstellen. Kosten können beispielsweise finanzielle Kosten, Kosten in Zeiteinheiten, Kosten als Maß der Bequemlichkeit oder irgendwelche anderen geeigneten Kosten darstellen.
  • Der Hub 106 enthält ein ("RemoteAd") Objekt für jede Anzeige, die in dem System registriert wurde (d. h. für jede Absicht zum Veröffentlichen, Schritt 202 von 2). Jedes RemoteAd-Objekt zeigt auf ein oder mehrere "AdSource"-Objekte, von denen jedes einen Pfad zwischen dem aktuellen Hub und dem Hub, an dem sich der Anbieter der Anzeige befindet, darstellt. Jedes AdSource-Objekt speichert seinem Pfad zum ursprünglichen Anbieter der Anzeige zugehörige Kosten. Somit enthält der "Kosten"-Wert für jede AdSource die Gesamtkosten zum Senden eines Ereignisses von seiner Quelle zum Nachbarn des aktuellen Hubs oder alternativ zum aktuellen Hub.
  • Jedes AdSource-Objekt weist eine zugehörige Liste von "Senkenobjekten" auf. (SinkCa und sinkNb befinden sich vorzugsweise in einer einzelnen Liste, obwohl nicht in dieser Weise in der Figur dargestellt.) Jedes Senkenobjekt weist eine zugehörige Liste von Teilnahmen auf. SinkCa weist beispielsweise eine Liste 505 aller Teilnahmen des Kunden 694 auf, die der Anzeige der RemoteAd 510 entsprachen. Ebenso weist SinkNb eine Liste 515 aller Teilnahmen des Nachbarn B (und aller Teilnahmen, die über den Nachbarn B erreicht werden können) auf, die der Anzeige der RemoteAd 510 entsprachen.
  • Jedes Nachbarobjekt weist auch eine zugehörige AdSourceRef-Liste auf, die auf AdSources für alle Pfade zwischen einem Anbieter und dem Nachbarn zeigt. Die Pfade werden zum Leiten von Systemereignissen zwischen Hubs verwendet, wie nachstehend beschrieben.
  • IV. Ereignisleitweglenkung zwischen Hubs
  • 10 ist ein Ablaufplan, der Details von Schritten zeigt, die von den Hubs 106, 108 und 114 von 1 durchgeführt werden, um die Datenstrukturen von 6(a) zu bestücken. Diese Schritte werden beispielsweise durchgeführt, wenn das Netzwerk zuerst initialisiert wird. Anschließend können verschiedene Hubs "Systemereignisse" ausgeben, um anderen Hubs mitzuteilen, dass Änderungen in Hubverbindungen, Ereignisarten, Anzeigen, Leitwegen, Teilnahmen usw. aufgetreten sind. Der Anhang A, der ein Teil dieser Beschreibung ist und durch den Hinweis hierin aufgenommen wird, enthält eine Zusammenfassung von beispielhaften Systemereignissen, die zwischen Hubs im beschriebenen Ausführungsbeispiel geleitet werden können.
  • In 10 ist der Name des Systemereignisses des Anhangs A, das einen Schritt im Ablaufplan beeinflusst, neben dem Schritt gezeigt. In Schritt 1002 senden die Hubs Systemereignisse zueinander, um die physikalischen Verbindungen zwischen Hubs in dem Netzwerk zu definieren. Jeder Hub erzeugt Nachbarobjekte, die physikalische Verbindungen mit seinen Nachbarhubs darstellen (siehe 6(a)). In Schritt 1004 senden die Hubs Systemereignisse zueinander, um die Arten von Ereignissen zu definieren, für die Anzeigen veröffentlicht werden können. Jeder Hub stellt sicher, dass er alle Ereignisse kennt. Dieser Schritt wird durchgeführt, wenn ein Hub zu einem Gebiet hinzugefügt wird. In Schritt 1006 senden Hubs, die mit einem Anbieter verbunden sind, Systemereignisse zu anderen Hubs, welche unter den Hubs weitergeleitet werden, um die Anzeigen unter dem Hub zu verteilen. Das Systemereignis NXS_SYS_EVENT_CREATE_NEW_ADVERTISEMENT von Anhang A bewirkt beispielsweise die Erzeugung von RemoteAd-Objekten in den Hubs (siehe 6(a)).
  • In Schritt 1008 senden Hubs, die mit einem Anbieter verbunden sind, Systemereignisse zu anderen Hubs. Die Systemereignisse werden unter den Hubs weitergeleitet, um Leitwege vom Hub des Anbieters zu anderen Hubs festzulegen. (Das Systemereignis NXS_SYS_EVENT_NEW_ROUTES bewirkt die Erzeugung von AdSource-Objekten in den Hubs (siehe 6(a)). Um die Existenz eines Leitweges zu registrieren, sendet ein anfänglicher Hub ein Systemereignis zu seinen Nachbarn, das einen Anzeigennamen/ID, seinen Namen und sein Gebiet (des veröffentlichenden Hubs) und Kosten, die mit dem Senden eines Ereignisses vom veröffentlichenden Hub zum aktuellen Hub verbunden sind, enthält. In der beschriebenen Implementierung werden die Kosten anfänglich auf Null gesetzt. Jeder Nachbarhub wiederholt diesen Prozess, wobei er die Kosten der Verbindung addiert, über die dieser Hub das Ereignis empfangen hat. Wenn dies der erste Leitweg zum Hub ist, dann werden in jedem Hub die lokalen Kunden auf Teilnahmeübereinstimmungen geprüft (Diese Handlung kann zu einem Systemereignis NEW_SUBSCRIPTION für den Sender von NEW_ROUTES führen). Jeder Leitweg wird zum Weiterleiten separat betrachtet. Der Leitweg wird nicht zum Hub, von dem es empfangen wurde, zum Ursprungshub oder zu einem Hub, der das Ereignis bereits gesehen hat, weitergeleitet (aus der Leitwegliste ermittelt, wie nachstehend erörtert). Der Leitweg wird nur zu anderen Hubs weitergeleitet, wenn er der erste Leitweg für die RemoteAd ist oder wenn er der zweite Leitweg ist und der Zielhub der aktuelle Leitweganbieter ist.
  • In Schritt 1010 senden mit einem Teilnehmer verbundene Hubs Systemereignisse zu anderen Hubs, um eine Teilnahme gegen eine Anzeige zu registrieren, die die anderen Hubs kennen. (Das Systemereignis NXS_SYS_EVENT_NEW_SUBSCRIPTIONS sendet Teilnahmen zu anderen Hubs, siehe 6(a)). Ein das Systemereignis empfangender Hub erzeugt ein Teilnahmeobjekt (siehe 6(a)) und teilt der RemoteAd dies mit. Eine AdSource mit einem kostengünstigsten Pfad wird die aktuelle AdSource genannt. Die RemoteAd teilt dies der aktuellen AdSource mit, die eine Senke und ein Teilnahmeobjekt des Nachbarobjekts erzeugt (wenn eine Senke und ein Teilnahmeobjekt nicht existieren). Die Senke fügt dann einen SubscriptionRef-Eintrag (z. B. 505, 512) für das Teilnahmeobjekt hinzu. Wenn die Anzeige von einem anderen Hub empfangen wurde, leitet der aktuelle Hub ein Systemereignis für die neue Teilnahme zu dem Nachbarn weiter, der ein Teil des aktuellen kostengünstigsten Leitwegs ist.
  • Diese Weiterleitung von Teilnahmen zu anderen Hubs ist ein wichtiger Aspekt der vorliegenden Erfindung. Sie erzeugt im Wesentlichen eine Kette von Teilnahmen von einem Hub eines Teilnehmers zurück zum Hub des Anbieters. Diese Kette folgt dem kostengünstigsten Leitweg zwischen dem Anbieter und dem Teilnehmer.
  • 11 zeigt ein Beispiel der Erzeugung einer Kette von Teilnahmen von einem Hub eines Teilnehmers zu einem Hub eines Anbieters. 11 zeigt fünf Hubs A, B, C, D und E. Mit dem Hub A ist ein Anbieter P verbunden. Mit dem Hub C ist ein Teilnehmer S verbunden. In dem Beispiel weist jede Verbindung Kosten von "1" auf. Somit befindet sich beispielsweise ein Leitweg mit Gesamtkosten = 2 zwischen dem Hub A und C und ein Leitweg mit Gesamtkosten = 3 zwischen dem Hub A und C.
  • 11 zeigt den Zustand der Hubs nach Schritt 1010 von 10. Verbindungen, Ereignisarten und Leitwege wurden unter den Hubs verteilt und die RemoteAd-, AdSource-, Nachbar- und AdSourceRef-Objekte wurden in jedem Hub erzeugt.
  • In dem Beispiel registriert der Teilnehmer S eine Teilnahme am Hub C. (Der Hub C hatte vorher ein Teilnahmeobjekt 1102 erzeugt, als sich S als Kunde registrierte, was anzeigt, dass der Teilnehmer S ein Kunde des Hubs C ist.) Der Hub C leitet dann ein "neues Teilnahmesystemereignis" (eine "Teilnahme") zu einem Nachbarhub, der sich auf einem kostengünstigsten Pfad zum Anbieter der Anzeige für das Ereignis befindet. In dem Beispiel leitet der Hub C die Teilnahme zum Hub B, da die Kosten vom Hub B zum Anbieterhub A "1" sind. Wenn der Hub B die Teilnahme empfängt, fügt er ein Teilnahmeobjekt 1104 hinzu, das mit einem Nachbarobjekt für den Hub C verbunden ist, das anzeigt, dass der Teilnehmer über den Hub C erreicht werden kann.
  • Der Hub B leitet dann eine Teilnahme zu einem Nachbarhub, der sich auf einem kostengünstigsten Pfad zum Anbieter der Anzeige für das Ereignis befindet. In dem Beispiel leitet der Hub B die Teilnahme zum Hub A, da die Kosten vom Hub A zu sich selbst "0" sind. Wenn der Hub A die Teilnahme empfängt, erzeugt er ein Teilnahmeobjekt 1106, das mit einem Nachbarobjekt für den Hub B verbunden ist, welches anzeigt, dass der Teilnehmer über den Hub B erreicht werden kann. Der Hub A leitet die Teilnahme nicht weiter, da er der ursprüngliche Hub für die Anzeige ist, an der teilgenommen wird.
  • Sobald die Datenstrukturen von 11 erstellt wurden, wird ein vom Anbieter P veröffentlichtes Ereignis Hub zu Hub entlang des von den Teilnahmeobjekten 1106, 1104 und 1002 definierten Pfades gesandt, bis es den Teilnehmer S erreicht.
  • 12 ist ein Ablaufplan, der Details von Schritten zeigt, die von den Hubs von 1 durchgeführt werden, um veröffentlichte Ereignisse durch Leiten der Ereignisse durch die Hubs des Systems zu Teilnehmern zu senden. Die Schritte von 12 werden durch 1) einen Hub, der ein Ereignis von seinem angeschlossenen Anbieter empfängt (Schritt 1202), oder 2) einen Hub, der ein Ereignis von einem benachbarten Hub empfängt (Schritt 1203), durchgeführt. Die Schritte von 12 werden von verschiedenen Hubs durchgeführt, wenn jedes Ereignis durch das System geleitet wird. In den folgenden Absätzen wird der Hub, der die Schritte von 12 durchführt, "aktueller Hub" genannt.
  • Wenn der aktuelle Hub ein Ereignis von einem seiner angeschlossenen Anbieter empfängt (Schritt 1202), fügt der Vorprozessor 514 des aktuellen Hubs anfänglich eine "Hüllkurve" zum Ereignis hinzu (Schritt 1204). Ein Format einer Ereignishüllkurve wird nachstehend in Verbindung mit 8 beschrieben. Der Vorprozessor 514 stellt dann in Schritt 1204 fest, ob die Ereignisart des Ereignisses im Hub registriert ist. Wenn nicht, kann der Anbieter das Ereignis nicht veröffentlichen. wenn ja, setzt der Hub in Schritt 1206 das Ereignis in die Schlange eingehender Ereignisse des Hubs für die weitere Verarbeitung. Im beschriebenen Ausführungsbeispiel verwirft die Ereignisschlange doppelte Ereignisse (wie durch eine Sequenznummer oder Zeitmarke der Ereignishüllkurve festgestellt).
  • Wenn der aktuelle Hub das Ereignis von einem benachbarten Hub empfängt (Schritt 1203), setzt der benachbarte Hub das Ereignis in die Schlange eingehender Ereignisse des aktuellen Hubs.
  • In Schritt 1208 erhält das Filter 518 des aktuellen Hubs das Ereignis von der Schlange eingehender Ereignisse des aktuellen Hubs. Das Filter 518 inkrementiert dann das Feld der verbrachten Zeit der Hüllkurve, das eine Menge an in der Schlange verbrachter Zeit angibt. In Schritt 1210 fügt das Filter 518 einen Leitwegblock zum Ereignis hinzu. Jeder Hub, der das Ereignis leitet, fügt einen weiteren Leitwegblock zum Ereignis hinzu. Ein Format von zwei Leitwegblöcken ist in 9 dargestellt.
  • In Schritt 1212 findet der aktuelle Hub ein "aktuelles" AdSource-Objekt auf, das alle Teilnehmer darstellt, die an dem Ereignis, das von dieser speziellen AdSource kommt, interessiert sind. Dies stellt gewöhnlich einen kostengünstigsten Pfad zwischen dem aktuellen Hub und den Teilnehmern dar (man beachte, dass das beschriebene Ausführungsbeispiel nicht umleitet, sobald eine AdSource-Datenstruktur erstellt ist. Das AdSource-Objekt wird entweder durch Durchsuchen aller RemoteAds nach dem aktuellen Hub (wenn das Ereignis von einem Anbieter kam, der mit dem aktuellen Hub verbunden ist) oder durch Durchsuchen der AdSourceRef-Liste nach dem benachbarten Hub (wenn das Ereignis von einem benachbarten Hub kam) aufgefunden. Die Schritte 1216–1222 senden das Ereignis zu einem oder mehreren Teilnehmern. Die Schritte 1216–1222 werden für jedes Senkenobjekt durchgeführt, das mit der AdSource verbunden ist. Somit werden die Schritte 1216–1222 für jeden Teilnehmer durchgeführt, der darum gebeten hat, Ereignisse der geleiteten Art zu empfangen.
  • Wenn in Schritt 1216 die Lebenszeit für das Ereignis geringer ist als das Feld der verbrachten Zeit der Hüllkurve, dann ist das Ereignis abgelaufen und wird vom aktuellen Hub nicht weiter geleitet (Schritt 1218). Ansonsten stellt das Filter 518 in Schritt 1220 fest, ob das Ereignis einen Inhalt aufweist, der innerhalb Parameter fällt, die vom Teilnehmer festgelegt werden. Der Teilnehmer hat das Inhaltsfilter zu dem Zeitpunkt festgelegt, zu dem er sich der Ereignisart angeschlossen hat (siehe Feld 774 von 7). Ein Teilnehmer kann beispielsweise angefordert haben, nur jene Verkaufsereignisse zu empfangen, die dort stattfinden, wo der Kunde in Los Angeles lebt. Wenn das Ereignis Werte in dem Bereich aufweist, der vom Teilnehmer festgelegt wird, dann wird das Ereignis in Schritt 1222 zum Teilnehmer gesandt (entweder direkt oder durch seinen Hub, wie nachstehend beschrieben). Jeder Teilnehmer kann ein anderes Inhaltsfilter (oder kein Inhaltsfilter) festgelegt haben. Ein erster Teilnehmer kann beispielsweise festgelegt haben, dass er Verkaufsereignisse empfangen will, wo der Kunde in Los Angeles lebt, und ein zweiter Teilnehmer kann festgelegt haben, dass er Verkaufsereignisse empfangen will, wo der Kunde in San Francisco lebt. In diesem Beispiel ist es möglich, dass das Ereignis dem ersten Teilnehmer entspricht, aber nicht dem zweiten Teilnehmer.
  • In Schritt 1222 sendet das Filter 518 das Ereignis zum entsprechenden Teilnehmer. Der Teilnehmer kann ein Kunde des aktuellen Hubs sein, wobei in diesem Fall das Ereignis direkt zum Teilnehmer gesandt wird. Alternativ kann der Teilnehmer mit einem benachbarten Hub entweder direkt oder indirekt verbunden sein. Wenn ein entsprechender Teilnehmer mit einem benachbarten Hub verbunden ist, leitet der aktuelle Hub das Ereignis zum benachbarten Hub (wenn nicht der benachbarte Hub der das Ereignis verursachende Hub ist, wie aus dem Feld 802 der Hüllkurve festgestellt, siehe 8). Der aktuelle Hub leitet das Ereignis auch nicht zu einem Hub, der das Ereignis bereits gesehen hat (wie aus den mit dem Ereignis verbundenen Leitwegblöcken festgestellt, siehe 9).
  • Im beschriebenen Ausführungsbeispiel leitet der aktuelle Hub das Ereignis nur ein einziges Mal zu einem benachbarten Hub, selbst wenn der benachbarte Hub mehr als eine entsprechende Teilnahme aufweist. Wenn das Teilnahmeobjekt 651 von 6(a) dem Ereignis entspricht, wird das Ereignis folglich zum benachbarten Hub B weitergeleitet.
  • Wenn das Teilnahmeobjekt 652 auch dem Ereignis entspricht, ist es nicht erforderlich, das Ereignis ein zweites Mal zum benachbarten Hub B weiterzuleiten. Wenn der benachbarte Hub B das Ereignis empfängt, führt er auch die Schritte von 12 durch, um festzustellen, ob irgendeiner seiner Kundenteilnehmer dem Ereignis entspricht.
  • 8 zeigt ein Format einer Hüllkurvendatenstruktur eines Ereignisses. Der Vorprozessor von 5 fügt eine Hüllkurve zu einem Ereignis hinzu, das von seinem Teilnehmer empfangen wird, bevor das Ereignis veröffentlicht wird. Eine Hüllkurve wird jedem Ereignis zugeordnet und umfasst einen Ursprungshub 802, einen Anzeigennamen 804, einen Anbieternamen 806, einen Gebietsnamen 808, eine anfängliche Zeitmarke 810, eine Lebenszeit 812, eine Priorität 814, Kennzeichen 816 und ein Feld 822 der verbrachten Zeit. Die Kennzeichen 816 werden im beschriebenen Ausführungsbeispiel nicht verwendet. In einem alternativen Ausführungsbeispiel können die Kennzeichen z. B. angeben, ob ein Ereignis "beständig" oder "vorübergehend" ist.
  • 9 zeigt ein Beispielformat von zwei Leitwegblöcken eines Ereignisses. Jeder Hub fügt einen Leitwegblock zu einem Ereignis hinzu, den er durch sich selbst leitet. Die API umfasst auch eine Routine get_current_route_info, die eine Information über den aktuellen Leitweg zurückgibt, den ein Ereignis nahm, um einen bestimmten Teilnehmer zu erreichen. Die Leitweginformation wird vom System als verkettete Liste, einen Eintrag für jeden besuchten Hub, gespeichert. Jeder Eintrag umfasst: eine Ausgangszeitmarke für den aktuellen Hub, einen Hubnamen des aktuellen Hubs und einen Gebietsnamen des aktuellen Hubs. Die Leitweginformation umfasst wahlweise eine Sequenznummer aus vierundsechzig Bits, die anfänglich vom Anbieter dem Ereignis zugewiesen wird.
  • V. Gebiete
  • Jedes Gebiet 130 und 140 von 1 ist eine Sammlung von Hubs mit einem gemeinsamen Ereignisverzeichnis. Gebiete spiegeln die Organisation wider und sind nicht notwendigerweise an die Geographie oder direkte physikalische Verbindungsfähigkeit gebunden. Im beschriebenen Ausführungsbeispiel müssen alle Hubs innerhalb eines Gebiets vollständig verbunden sein, da die Anzeigeninformation nicht über Gebiete weitergeleitet wird. Somit besteht immer ein gewisser Pfad, obwohl er indirekt sein kann, zwischen zwei Hubs innerhalb eines Gebiets, ohne das Gebiet verlassen zu müssen. In einem bevorzugten Ausführungsbeispiel existieren Hierarchien von Gebieten, in denen Gebiete niedrigerer Ebene die Ereignisverzeichnisse ihres Muttergebiets übernehmen. Eine Gesellschaft kann beispielsweise wählen, für jede Tochtergesellschaft ein Gebiet zu haben, wobei alle von ihnen bestimmte "Firmenereignisse" verstehen.
  • Ein Hub kann vorzugsweise zu nur einem Gebiet gehören. wenn ein Kunde (ein Anbieter oder ein Teilnehmer) mit einem Hub eine Verbindung eingeht, legt er fest, zu welchem Gebiet oder welchen Gebieten er gehört. Ein Kunde muss zu einem Gebiet gehören, da die Bedeutung eines Ereignisses, beispielsweise einer Verkaufsbestellung, in verschiedenen Gebieten unterschiedlich sein kann. Im beschriebenen Ausführungsbeispiel weist jeder Hub ein vorbestimmtes Vorgabegebiet auf, das verwendet wird, wenn der Anwendungsentwickler kein Gebiet festlegt.
  • In einem alternativen Ausführungsbeispiel sind Hubs mehrerer Gebiete insbesondere für die Kommunikation zwischen Firmen nützlich. Zwei Firmen, die entscheiden, unter Verwendung des beschriebenen Ausführungsbeispiels der vorliegenden Erfindung zu kommunizieren, können ein gemeinsames Gebiet festlegen, wobei sie sich auf einige Ereignisarten und ein gemeinsam zu nutzendes Format einigen. Die Hubs, die die zwei Firmen verbinden, leiten nur Ereignisse dieses gemeinsamen Gebiets weiter, da die Gebietsinformation als Teil der Anzeige beibehalten wird, wie nachstehend in Verbindung mit der Ereignisleitweglenkung beschrieben.
  • VI. Datenbank-Verbindungsfähigkeit
  • 13 ist ein Blockdiagramm einer Datenbankanwendung 1302, die in das Netzwerk 120 von 1 integriert ist. Die Datenbankanwendung 1302, die eine Datenbankbibliothek mit Schnittstellenroutinen 1304 umfasst, ermöglicht Benutzern, auf eine Information in der Datenbank 1308 zuzugreifen. Die Datenbank 1308 kann eine Datenbank sein, die beispielsweise von Oracle, Sybase oder Informix hergestellt wird. Die Erfindung kann unter Verwendung einer beliebigen geeigneten Datenbank implementiert werden, die in der Lage ist, in Verbindung mit einer Transaktions-Überwachungseinrichtung zu arbeiten.
  • 13 umfasst auch eine Transaktions-Überwachungseinrichtung 1306. Die Transaktions-Überwachungseinrichtung 1306 ist vorzugsweise die Encina-Transaktions-Überwachungseinrichtung, die von Transarc Corporation hergestellt wird. Sie kann beispielsweise auch die Tuxedo-Transaktions-Überwachungseinrichtung sein, die von Novell hergestellt wird. Alternativ kann eine beliebige geeignete Transaktions-Überwachungseinrichtung verwendet werden, um die vorliegende Erfindung zu implementieren. Eine Datenbank-Verbindungsvorrichtung 1310 mit einer Datenbankbibliothek 1304 steht mit dem Netzwerk 120 in Verbindung, um Daten vom Netzwerk 120 zu senden und zu empfangen. Die Datenbank-Verbindungsvorrichtung 1310 kann eine Software umfassen, die Hubfunktionen durchführt, oder kann mit einem separaten Hub in Verbindung stehen. In 13 sendet die Datenbankanwendung 1302 eine Information zur Datenbank 1308. Die Datenbankanwendung 1302 fordert auch eine Information von der Datenbank 1308 an und zeigt diese Information in einer für den Menschen lesbaren Form an.
  • Die Datenbank-Verbindungsvorrichtung 1310 kann ein Anbieter, ein Teilnehmer oder beides sein. Wenn die Datenbank-Verbindungsvorrichtung 1310 ein Anbieter ist, kann er beispielsweise jedes Mal, wenn in der Datenbank 1302 ein Wert geändert wird, ein Ereignis veröffentlichen. Er könnte beispielsweise auch Ereignisse in regelmäßigen Zeitintervallen veröffentlichen, die die Daten widerspiegeln, die in der Datenbank seit der letzten Veröffentlichung aktualisiert wurden. Wenn die Datenbank 1302 ein Teilnehmer ist, speichert er die Information von Ereignissen, die er empfängt, in der Datenbank 1302. Das beschriebene Ausführungsbeispiel umfasst eine Konfigurationsdatei (nicht dargestellt) für die Datenbank-Verbindungsvorrichtung 1310. Die Konfigurationsdatei legt beispielsweise fest, ob die Datenbankverbindung ein Anbieter, ein Teilnehmer oder beides ist. Die Konfigurationsdatei umfasst beispielsweise auch eine Beschreibung von Ereignissen zum Veröffentlichen und/oder zum Teilnehmen an diesen. Die Konfigurationsdatei legt auch eine Information hinsichtlich der Anordnung der Datenbank 1308 fest.
  • 14 ist ein Ablaufplan 1400, der Schritte zeigt, die durchgeführt werden, wenn die Datenbank ein Teilnehmer ist. Wenn Ereignisse vom Netzwerk 120 empfangen werden, werden Daten von den Ereignissen beispielsweise zur Datenbank 1302 hinzugefügt. Der Ablaufplan 1400 nimmt an, dass die Datenbank-Verbindungsvorrichtung 1310 sich und ihre Teilnahme(n) bereits registriert hat, wie vorstehend beschrieben. Wenn ein Ereignis von der Datenbank-Verbindungsvorrichtung 1310 in Schritt 1402 empfangen wird, bildet die Datenbank-Verbindungsvorrichtung die Daten im Ereignis in die Datenbank 1306 ab und speichert sie in dieser. Die Daten werden nicht an die Datenbank "übergeben", bis die Daten vollständig in der Datenbank gespeichert wurden. "Übergabe" bedeutet, dass die Daten tatsächlich in die Datenbank eingegeben werden. Bis die Änderungen an den Daten übergeben werden, werden sie in einer vorübergehenden Speicherstelle gehalten. Somit kann die Datenbank, an die nicht übergeben wurde, "zurückgeführt" werden und die Datentransaktion zu einem beliebigen Zeitpunkt, bis die "Übergabe"-Operation durchgeführt wird, abgebrochen werden. Während einer "Rückführung" werden die Änderungen in den Daten im vorübergehenden Speicher verworfen und die Datenbank wird in ihrem Zustand, bevor die Änderungen vorgenommen wurden, gehalten. Unter bestimmten Umständen gibt die Datenbank-Verbindungsvorrichtung 1310 keinen "Übergabe"-Befehl aus, bis ein bestimmtes Ereignis empfangen wird.
  • 15 ist ein Ablaufplan 1500, der Schritte zeigt, die durchgeführt werden, wenn die Datenbank ein Anbieter ist. Wenn ein menschlicher Benutzer Daten in der Datenbank 1302 beispielsweise hinzufügt, löscht und modifiziert, sendet die Datenverbindungsvorrichtung 1310 periodische Ereignisse zum Netzwerk 120. In Schritt 1502 wird die Transaktions-Überwachungseinrichtung 1306 informiert, dass die Datenbank-Verbindungsvorrichtung 1310 ein "Knoten" ist. Die exakte Art und Weise, in der dieser Schritt durchgeführt wird, variiert in Abhängigkeit vom Hersteller der Transaktions-Überwachungseinrichtung 1306, aber der Schritt ist üblichen Fachleuten im Allgemeinen gut bekannt. In Schritt 1504 registriert sich die Datenbank-Verbindungsvorrichtung 1310 und ihre Anzeige(n), wie vorstehend beschrieben.
  • Schritte 1506–1512 zeigen Schritte, die z. B. durchgeführt werden, wenn der Benutzer Änderungen an der Datenbank 1308 vornimmt. Wenn in Schritt 1506 eine Datenbanktransaktion beginnt, informiert die Datenbank 1308 die Transaktions- Überwachungseinrichtung, dass eine Transaktion begonnen hat, unter Verwendung z. B. des XA-Protokolls von X/Open. Die Transaktions-Überwachungseinrichtung 1306 informiert die Datenbank-Verbindungsvorrichtung 1310, dass eine Transaktion stattfindet, und die Datenbank-Verbindungsvorrichtung 1310 nimmt die Transaktion zur Kenntnis. In Schritt 1508 werden vom Benutzer Änderungen an der Datenbank vorgenommen, aber der Benutzer hat die Änderungen nicht übergeben).
  • Wenn der Benutzer (oder eine Software, die Änderungen vornimmt) in Schritt 1507 anzeigt, dass die Transaktion übergeben sollte, wird diese Tatsache in Schritt 1510 an die Transaktions-Überwachungseinrichtung 1306 übertragen. Die Transaktions-Überwachungseinrichtung 1306 informiert die Datenbank-Verbindungsvorrichtung 1310, die die übergebenen Daten von der Datenbank 1308 zieht und ein Ereignis, einschließlich der übergebenen Daten, veröffentlicht. Ereignisse werden, wie in 12 gezeigt, veröffentlicht. Wenn der Benutzer (oder eine Software, die Änderungen vornimmt) in Schritt 1512 anzeigt, dass die Transaktion zurückgeben sollte, wird diese Tatsache zur Transaktions-Überwachungseinrichtung 1306 übertragen. Die Transaktions-Überwachungseinrichtung 1306 informiert die Datenbank-Verbindungsvorrichtung 1310, die die Änderungen von Schritt 1506 "vergisst" und kein Ereignis veröffentlicht. Somit berücksichtigt das beschriebene Ausführungsbeispiel die Übergabe- und Rückgabeoperationen, die mit der kommerziellen Datenbankoperation gemeinsam sind.
  • In einem alternativen Ausführungsbeispiel, in dem das verwendete Datenbankprodukt 1302 keine Transaktions-Überwachungseinrichtung umfasst, kann die Datenbank-Verbindungsvorrichtung 1310 als Transaktions-Überwachungseinrichtung wirken, wenn sie mit der Datenbank 1308 in Verbindung steht. Die Datenbank- Verbindungsvorrichtung 1310 wirkt in dieser Konfiguration immer noch als Anbieter und/oder Teilnehmer. Die Datenbank 1308 denkt, dass sie mit einer Transaktions-Überwachungseinrichtung verbunden ist, wenn sie in Wirklichkeit mit der Datenbank-Verbindungsvorrichtung 1310 verbunden ist.
  • VII. Zusammenfassung
  • Zusammengefasst umfasst ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung eine Vielzahl von "Anbieter"-Objekten, die eine Information veröffentlichen, und eine Vielzahl von "Teilnehmer"-Objekten, die die Information anfordern und verwenden. Anbieter und Teilnehmer sind über ein Netzwerk miteinander verbunden. Das Netzwerk ist ein Netzwerk zum "Speichern und Weiterleiten", dessen Leitweglenkung "auf dem Inhalt basiert".
  • Im beschriebenen Ausführungsbeispiel der vorliegenden Erfindung wird die Grundmenge einer Information "Ereignis" genannt. Anbieter veröffentlichen Ereignisse und Teilnehmer nehmen an Ereignissen teil, die vom Teilnehmer definierten Kriterien entsprechen. Die Veröffentlichung und Teilnahme werden asynchron durchgeführt. Die Anbieter und Teilnehmer haben keine direkte Kenntnis voneinander. Das System empfängt ein veröffentlichtes Ereignis von einem Anbieter und leitet das Ereignis zu allen entsprechenden Teilnehmern. Jedem Teilnehmer wird garantiert, alle Ereignisse zu empfangen, die im System veröffentlicht werden, wenn und nur wenn sie den vom Teilnehmer festgelegten Teilnahmekriterien entsprechen.
  • Das beschriebene Ausführungsbeispiel der vorliegenden Erfindung macht es leicht, veraltete Systeme, veraltete Anwendungen und veraltete Hardware in das System zu integrieren, und versucht, die Menge an Information, die ein Benutzer lernen muss, um das System zu verwenden, zu minimieren. Eine veraltete Datenbank kann zum Netzwerk durch eine Datenbank-Verbindungsvorrichtung, die ein Anbieter, ein Teilnehmer oder beides sein kann, hinzugefügt werden.
  • Weitere Ausführungsbeispiele sind für Fachleute aus der Betrachtung der Beschreibung und der Ausführung der hierin offenbarten Erfindung ersichtlich. Es ist vorgesehen, dass die Beschreibung und die Beispiele nur als beispielhaft betrachtet werden, wobei ein wahrer Schutzbereich der Erfindung durch die folgenden Ansprüche angegeben wird.
  • Anhang A
  • ......das Aussehen, gelöscht zu werden (alle IDL-Operationen werfen OBJECT_NOT_EXIST weg), selbst wenn die Bereinigung eine Weile fortbestehen kann.
  • Während des Löschens wird der Hubdatenspeicher in einem konsistenten Zustand gehalten. Wenn der Server während der Mitte des Löschens abgeschaltet wird, kann er erfassen, wo er aufgehört hat, wenn der Server reaktiviert.
  • Die Reihenfolge des Objektlöschens ist wichtig. Zuerst wird das Filter von der eingehenden Ereignisschlange getrennt und das Vorprozessorobjekt wird gelöscht. Das Ziel besteht darin, die Anzahl von Aufrufen in den Hub zu verringern, so dass sie leicht deaktivieren. Als nächstes wird das Objekt Nexus:Hub gelöscht. Da keine Löschoperation an diesem Objekt stattfindet, wird ein kleiner Hieb verwendet (siehe Nexus::Hub::name()). Ein weiteres Löschen des Hubs muss warten, bis diese Objekte gelöscht sind, da sie Befehlsfolgen aufweisen können, die Clientobjekte verwenden.
  • Nachdem CORBA-Objekte gelöscht sind, werden die restlichen C++-Objekte und der beständige Speicher gelöscht. Schließlich wird der Hub vom Hubserververwalter entfernt.
  • 6.0 Die Systemereignisse
  • Dreiundzwanzig Systemereignisse werden verwendet, um zwischen Hubs zu kommunizieren. Sie teilen sich einiges der Kopfstruktur von normalen Ereignissen, sind jedoch ansonsten vollständig unterschiedlich und werden außerhalb des normalen Ereigniscodepfads verarbeitet.
  • Die Systemereignisstruktur ist in include/nxs_syspackP.hh: definiert:
    Figure 00440001
  • Die Werte für sys_event_type können in transport/hub/sysevent.hh gefunden werden. Der ganze Systemereignis-Verarbeitungscode wird in nexushub.hh erklärt (als Verfahren von NexusHub) und in sysevent.cc. definiert.
  • Die Systemereignisdaten sind eine Zeichenfolge, die aus beabstandeten getrennten Tokens besteht. Die möglichen Tokens sind:
    string Zeichenfolge von beliebigen Zeichen außer <leer> und <nnl>
    /string/ eine Zeichenfolge von beliebigen Zeichen außer ^_(/037), umgeben von ^_(/037)
    long ein 32-Bit-Wert mit Vorzeichen
    ulong ein 32-Bit-Wert ohne Vorzeichen
  • Objektreferenzen werden in Zeichenfolgeform übertragen.
  • Systemereignisse werden für verschiedene Kommunikationsstile verwendet. Während der Verbindungsherstellung werden Systemereignisse als Meldungen zwischen gleichrangigen Geräten verwendet. Diese Ereignisse werden von anderen Hubs nicht gesehen. Die meisten anderen Ereignisse beeinflussen den Zustand des Gebiets und können durch die gesamte Gebietskurve weitergeleitet werden. Einige Ereignisse können von einem Hub zu sich selbst gesandt werden. NXS_SYS_EVENT_CONNECT_HUB
    /string/ Senden von Hubname
    /string/ Senden von Hubgebiet
    string Senden von eingehender Ereignisschlange von Hub::PushConsumer
    ulong Kosten von Hub empfangen
    ulong Kosten von Hub senden
  • Dieses Ereignis wird infolge eines Aufrufs an NexusAdmin::HubAdmin::connectHub gesandt. Der sendende Hub hat bereits den Nachbarn und die Ereignisschlange für die Verbindung erzeugt. Der empfangende Hub tut dasselbe, wenn er das Systemereignis empfängt. Man beachte, dass der sendende Hub bereits die eingehende Ereignisschlange::PushConsumer des empfangenden über ein Argument für NexusAdmin::HubAdmin::connectHub hat. Wenn dies die erste Verbindung für den empfangenden Hub ist (er schließt sich einem Gebiet an), dann muss er die gemeinsam genutzten Daten des Gebiets (Ereignisarten usw.) erhalten. Systemereignisse werden zum Anfordern dieser Information vom sendenden Hub verwendet; NXS_SYS_EVENT_REQUEST-EVENTTYPES und NXS_SYS_EVENT_REQUEST_ADVERTISEMENTS. Wenn der Hub bereits ein Element des Gebiets ist, sendet er seine Leitwege zum Sender mit NXS_SYS_EVENT_NEW_ROUTES. Der empfangende Hub fordert immer Leitwege vom Sender mit NXS_SYS_EVENT_REQUEST_ROUTES an. Wenn die Verbindung nicht erzeugt werden kann, beispielsweise der Gebietsname falsch ist, sendet der Empfänger ein NXS_SYS_EVENT_CONNECT_FAILED. NXS_SYS_EVENT_CONNECT_FAILED
    /string/ Senden von Hubname
    /string/ Senden von Hubgebiet
    /string/ Grund für Verbindungsfehlschlag
  • Gesandt, wenn Verbindungsherstellung fehlgeschlagen ist. Bereinigen von Datenstrukturen. NXS_SVS_EVENT_DISCONNECT_HUB
    /string/ Senden von Hubname (oder Nachbarname)
    /string/ Senden von Hubgebiet
  • Dieses Systemereignis kann zum gleichen oder zu einem anderen Hub gesandt werden. Zum gleichen infolge eines Aufrufs an NexusAdmin::HubAdmin::disconnectHub gesandt. In diesem Fall ist das erste Argument der Name des Nachbarhubs. Der Hub sendet ein ähnliches Ereignis zum Nachbarn (das den Namen des sendenden Hubs enthält) und führt eine Verbindungsabschaltung durch. Dies kann verursachen, dass die folgenden Systemereignisse gesandt werden:
    NXS_SYS_EVENT_FAIL_SUBSCRIPTIONS,
    NXS_SYS_EVENT_DELETE_ROUTES und
    NXS_SYS_EVENT_DELETE_ADVERTISEMENTS. Bei der Verbindung werden Bereinigungsereignisse gesandt, ein
    NXS_SYS_EVENT_END_OF_STREAM wird geliefert.
  • Die Folge von Ereignissen ist am Nachbarhub, der NXS_SYS_EVENT_DISCONNECT_HUB empfängt, dieselbe. NXS_SYS_EVENT_END_OF_STREAM
    /string/ Senden von Hubname
    /string/ Senden von Hubgebiet
  • Gibt das letzte an einer Verbindung zu sehende Ereignis an. Bereinigen von Datenstrukturen. NXS_SYS_EVENT_REQUEST_EVENTTYPES
    /string/ Senden von Hubname
    /string/ Senden von Hubgebiet
  • Senden von Ereignisarten zum Sender mit NXS_SYS_EVENT_NEW_EVENTTYPE FILES. NXS_SYS_EVENT_NEW_EVENTTYPE_FILES
    long Anzahl von Dateien F
    long Anzahl von Arten T F-mal wiederholt:
    /string/ .nexus-Dateiinhalt
    /string/ .ifr-Dateiinhalt T-mal wiederholt:
    string Ereignisartname
  • Laden der IFR- und Nexus-Dateien in die IFR und Erzeugen der gegebenen Ereignisarten. Das Ereignis wird zu allen angeschlossenen Nachbarn außer dem Sender und Nachbarn, die das Ereignis bereits gesehen haben, weitergeleitet. NXS_SYS_EVENT_FORWARD_EVENTTYPE_FILE
    ulong Adresse von Ereignisartdatei-Zustand
    long Anzahl von Ereignisarten T T-mal wiederholt:
    string Ereignisartname
  • Senden der Ereignisartdatei und Ereignisarten zu allen angeschlossenen Nachbarn. Nur zum gleichen gesandt, wenn Ereignisarten erzeugt oder aktualisiert werden. NXS_SYS_EVENT_REQUEST_ADVERTISEMENTS
    /string/ Senden von Hubname
    /string/ Senden von Hubgebiet
  • Liefern aller Anzeigen zum sendenden Hub mit NXS_SYS_EVENT_NEW_ADVERTISEMENTS. NXS_SYS_EVENT_NEW_ADVERTISEMENTS
    long Anzahl von Anzeigen A A-mal wiederholt:
    /string/ Anzeigenname
    /string/ Ereignisartname
    long Priorität
    string Speichermodus; "p" oder "t" für beständig oder vorübergehend
    ulong Lebenszeit (Sekunden)
    /string/ Ursprungshubname
    /string/ Ursprungshubgebiet
  • Erzeugen von RemoteAds für die aufgelisteten Anzeigen. Der Ursprungshub befindet sich dort, wo die Anzeige erzeugt wurde. Das Systemereignis wird zu allen angeschlossenen Nachbarn außer dem Sender und Nachbarn, die das Ereignis bereits gesehen haben, weitergeleitet. NXS_SYS_EVENT_CONNECTION_READY
    /string/ Senden von Hubname
    /string/ Senden von Hubgebiet
  • Der sendende Hub ist bereit, die Verbindung zu verwenden. Wenn der Empfänger auch bereit ist, antwortet er mit NXS_SYS_EVENT CONNECTION_READY. Wenn die Verbindung bereits hergestellt ist, wird das Systemereignis ignoriert. NXS_SYS_EVENT_FORWARD_ADVERTISEMENT
    string Anzeigenname
  • Senden der benannten Anzeige zu allen angeschlossenen Nachbarn. Nur zum gleichen gesandt, wenn Anzeigen erzeugt werden. NXS_SYS_EVENT_CHANGE_ADVERTISEMENT
    /string/ Anzeigenname
    /string/ Ursprungshubname
    /string/ Ursprungshubgebiet
    long Priorität
    string Speichermodus; "p" oder "t" für beständig oder vorübergehend
    ulong Lebenszeit
  • Aktualisieren der entsprechenden RemoteAd mit den gegebenen Werten. Das Systemereignis wird zu allen angeschlossenen Nachbarn außer dem Sender und Hubs, die das Ereignis bereits gesehen haben, weitergeleitet. NXS_SYS_EVENT_DELETE_ADVERTISEMENTS
    long Anzahl von Anzeigen A A-mal wiederholt:
    /string/ Anzeigenname
    /string/ Ursprungshubname
    /string/ Ursprungshubgebiet
  • Löschen der zugehörigen RemoteAds und zugehöriger Datenstrukturen. Durch den Ursprungshub gesandt, wenn eine Anzeige gelöscht wird. Das Systemereignis wird zu allen angeschlossenen Nachbarn außer dem Sender und Hubs, die das Ereignis bereits gesehen haben, weitergeleitet. NXS_SYS_EVENT_REQUEST_ROUTES
    /string/ Senden von Hubname
    /string/ Senden von Hubgebiet
  • Liefern von jeglicher Leitweginformation zum Sender mit NXS_SYS_EVENT_NEW_ROUTES. NXS_SYS_EVENT_NEW_ROUTES
    long Anzahl von Leitwegen R R-mal wiederholt:
    /string/ Anzeigenname
    /string/ Ursprungshubname
    /string/ Ursprungshubgebiet
    long Kosten
  • Aufzeichnen der Existenz eines Leitweges vom Sender zu den gegebenen Anzeigen mit den gegebenen Kosten. AdSource-Objekte werden erzeugt, und wenn dies der erste Leitweg zur Anzeige ist, werden die lokalen Kunden auf Teilnahmeübereinstimmungen geprüft. Dies kann zu einem NXS_SYS_EVENT_NEW_SUBSCRIPTIONS für den Sender von NXS_SYS_EVENT_NEW_ROUTES führen. Jeder Leitweg wird für das Weiterleiten separat betrachtet. Der Leitweg wird nicht zum Sender, zum Ursprungshub oder zu einem Hub, der das Ereignis bereits gesehen hat, weitergeleitet. Der Leitweg wird nur weitergeleitet, wenn er der erste Leitweg für die RemoteAd ist oder er der zweite Leitweg ist und der Zielhub der aktuelle Leitweganbieter ist. Das Kostenfeld des weitergeleiteten Ereignisses wird durch die Kosten der Verbindung, über die das Ereignis empfangen wurde, inkrementiert.
  • Dieses Systemereignis kann das Ende der Verbindungseinrichtung kennzeichnen. Wenn das Ereignis von einem Nachbarn kam, der noch nicht vollständig angeschlossen ist, wird NXS_SYS_EVENT_CONNECTION_READY zum Nachbarn gesandt. NXC_SYS_EVENT_CHANGE_ROUTES
    long Anzahl von Leitwegänderungen R
    /string/ Ursprungshubname
    /string/ Ursprungshubgebiet R-mal wiederholt:
    /string/ Anzeigenname
    long Kosten
  • Ändern der Kosten eines Leitweges. Auffinden der entsprechenden RemoteAd und AdSource und Aktualisieren ihres Kostenwerts. Das Systemereignis wird zu allen angeschlossenen Nachbarn außer dem Sender und dem Nachbarn, die das Ereignis bereits gesehen haben, weitergeleitet. NXS_SYS_EVENT_DELETE_ROUTES
    long Anzahl von Leitwegen R R-mal wiederholt:
    /string/ Anzeigenname
    /string/ Ursprungshubname
    /string/ Ursprungshubgebiet
  • Löschen der Leitwege (AdSource) für die gegebenen Anzeigen (RemoteAd). Jegliche Teilnahmen, die durch diesen Leitweg zugeführt wurden, sind fehlgeschlagen. Dies kann zu NXS_SYS_EVENT_FAIL SUBSCRIPTIONS führen, das zu Nachbarn gesandt wird, die Teilnahmen für die Anzeigen registriert haben. Das Weiterleiten jedes gelöschten Leitwegs wird separat betrachtet, und nur wenn der letzte Leitweg zur Anzeige gelöscht wurde. Das Systemereignis wird nicht zum Sender oder zum Ursprungshub weitergeleitet. NXS_SYS_EVENT_CHANGE_CONNECTION
    /string/ Senden von Hubname
    /string/ Senden von Hubgebiet
    long Delta zu Verbindungskosten des sendenden Hubs
  • Aktualisieren ihrer Kosten für die Verbindung. NXS_SYS_EVENT_NEW_SUBSCRIPTION
    long Anzahl von Teilnahmen S S-mal wiederholt:
    /string/ Anzeigenname
    /string/ Anzeigenhubname
    /string/ Anzeigenhubgebiet
    /string/ Filterausdruck
    ulong Inhaber-ID im Sender
    ulong Teilnahme-ID im Sender
  • Registrieren von Teilnahmen vom Sender gegen die gegebenen Anzeigen. Erzeugen einer Teilnahme am sendenden Nachbarn und Verständigen der RemoteAd darüber. Die RemoteAd verständigt die aktuelle AdSource, die eine Senke für den Nachbarn erzeugt (wenn noch keine existiert). Die Senke fügt eine SubscriptionRef für die Teilnahme hinzu.
  • Wenn die Anzeige von einem anderen Hub ist, Weiterieiten eines Systemereignisses für die neue Teilnahme zum Nachbarn, der den aktuellen Leitweg liefert.
  • Die Inhaber- und Teilnahme-IDs werden verwendet, um die Teilnahme aufzufinden, wenn sie abgebrochen wird, und sie zu identifizieren, wenn sie fehlschlägt.
  • Wenn ein Fehlschlag während der Teilnahmeregistrierung stattfindet, wird ein NXS_SYS_EVENT_FAIL_SUBSCRIPTIONS an den Sender zurückgegeben. NXS_SYS_EVENT_CANCEL_SUBSCRIPTION
    long Anzahl von Teilnahmen S S-mal wiederholt:
    ulong Inhaber-ID im Sender
    ulong Teilnahme-ID im Sender
  • Abbrechen der aufgelisteten Teilnahmen. Dieses Ereignis kann vom gleichen oder einem Nachbarn gesandt werden. Entfernen aller Bezugnahmen auf die Teilnahme von allen aktuellen AdSources. Dies sollte jegliche Bezugnahme auf die Teilnahme durch senkeneigene SubscriptionRefs löschen. Der Abbruch wird zu allen Nachbarn weitergeleitet, die die Teilnahme möglicherweise zuführen könnten. NXS_SYS_EVENT_FAIL_SUBSCRIPTIONS
    long Anzahl von Fehlschlägen S S-mal wiederholt:
    ulong Inhaber-ID im Empfänger
    ulong Teilnahme-ID im Empfänger
    /string/ Hubname, an dem Fehlschlag aufgetreten ist
    /string/ Gebiet, in dem Fehlschlag aufgetreten ist
    /string/ Fehlschlaggrund
  • Entfernen der Bezugnahme auf die Teilnahmen von AdSources. Die Teilnahme selbst wird vom Fehlschlag nicht beeinflusst. Wenn die Teilnahme von einem Nachbarn war, wird der Fehlschlag zum Ursprungshub zurückgeleitet. NXS_SVS_EVENT_FORWARD_SUBSCRIPTION
    ulong Kunden-ID
    ulong Teilnahme-ID
  • Weiterleiten der neuen Teilnahme zu Nachbarn, die sie zuführen können. Verständigen aller entsprechenden RemoteAds über die Teilnahme. Jede RemoteAd verständigt ihre aktuelle AdSource, die eine Senke für den Kunden erzeugt (wenn noch keine existiert). Die Senke fügt eine SubscriptionRef für die Teilnahme hinzu. Senden von NXS_SYS_EVENT_NEW_SUBSCRIPTIONS zur aktuellen Quelle für jede nicht-lokale RemoteAd. NXS_SYS_EVENT_DELETE_EVENTTYPE
    string Ereignisartname
  • Löschen der Ereignisart. Das Systemereignis wird zu allen angeschlossenen Nachbarn außer dem Sender und den Hubs, die das Ereignis bereits gesehen haben, weitergeleitet.
  • 7.0 Verschiedenes
  • 7.1 Ereignisinhaltsfilterung
  • Der Hub verwendet denselben Filtercode und dieselbe API wie die Nexus-Clientschnittstelle. Wenn eine Teilnahme registriert wird, wird der zugehörige Filterausdruck nxsCreateFilter durchlaufen lassen, um ein Inhaltsfilter zu erzeugen. Der Hub wird mit einer Version der Filterbibliothek kompiliert, die Filter von PHeap anstatt malloc zuweist. Das Inhaltsfilter wird im Teilnahmezustand aufgezeichnet. Wenn eine potentielle Übereinstimmung zwischen einem Ereignis und der Teilnahme besteht, wird nxsFilterEvent aufgerufen, um auf eine Übereinstimmung zu prüfen. Ein leerer Filterausdruck entspricht allen Ereignissen.

Claims (8)

  1. Von einem Datenverarbeitungssystem (100) durchgeführtes Verfahren zum Verbinden einer Datenbank (1308) mit einem Netzwerk (120), wobei das Verfahren umfasst: Vorsehen einer Übertragungsstrecke, so dass die Datenbank (1308) mit einem Computerprogramm einer Datenbank-Verbindungsvorrichtung (1310) durch ein Computerprogramm einer Transaktions-Überwachungseinrichtung (1306) kommunizieren kann; Einrichten der Datenbank-Verbindungsvorrichtung (1310) als Anbieterhub (11, Teil A) im Netzwerk (120), so dass das Netzwerk (120) ein Anbieter/Teilnehmer-Netzwerk ist und so dass die Datenbank (1308) Ereignisse (308) im Netzwerk (120) veröffentlichen kann; Empfangen eines Eingangssignals durch die Datenbank (1308) von einem Benutzer, der Daten in der Datenbank (1308) ändert; Informieren der Transaktions-Überwachungseinrichtung (1306), dass die Daten geändert wurden; Empfangen eines Eingangssignals vom Benutzer, das angibt, dass die geänderten Daten übergeben werden sollten; Informieren der Transaktions-Überwachungseinrichtung (1306), dass die geänderten Daten übergeben werden; und Senden eines veröffentlichten Ereignisses durch die Datenbank-Verbindungsvorrichtung (1310) gemäß einer Meldung von der Transaktions-Überwachungseinrichtung (1306), dass die Daten übergeben werden, zum Netzwerk (120) gemäß den geänderten Daten.
  2. Verfahren nach Anspruch 1, welches ferner umfasst: Empfangen eines Eingangssignals vom Benutzer, das angibt, dass die geänderten Daten zurückgegeben werden sollten; Informieren der Transaktions-Überwachungseinrichtung (1306), dass die geänderten Daten zurückgegeben werden; und Unterlassen, durch die Datenbank-Verbindungsvorrichtung (1310), die geänderten Daten zum Netzwerk (120) zu senden, gemäß der Rückgabe.
  3. Von einem Datenverarbeitungssystem (100) durchgeführtes Verfahren zum Verbinden einer Datenbank (1308) mit einem Netzwerk (120), wobei das Verfahren umfasst Vorsehen einer Übertragungsstrecke, so dass ein Computerprogramm einer Datenbank-Verbindungsvorrichtung (1310) mit der Datenbank (1308) kommunizieren kann; Einrichten der Datenbank-Verbindungsvorrichtung (1310) als Teilnehmerhub (11, Teil C) im Netzwerk (120), so dass das Netzwerk (120) ein Anbieter/Teilnehmer-Netzwerk ist und so dass die Datenbank (1308) an Ereignissen (308) des Netzwerks (120) teilnehmen kann; Empfangen eines Ereignisses vom Netzwerk (120) durch die Datenbank-Verbindungsvorrichtung (1310); Senden von Daten gemäß dem empfangenen Ereignis durch die Datenbank-Verbindungsvorrichtung (1310) zur Datenbank (1308); und Übergeben der Daten in der Datenbank durch die Datenbank-Verbindungsvorrichtung (1310).
  4. Verfahren nach Anspruch 1, welches ferner umfasst: Empfangen eines Ereignisses durch die Datenbank-Verbindungsvorrichtung (1310); Feststellen durch die Datenbank-Verbindungsvorrichtung (1310) gemäß einer Datenstruktur der Datenbank-Verbindungsvorrichtung (1310), dass die Datenbank (1308) an dem Ereignis teilgenommen hat; und Senden des Ereignisses durch die Datenbank-Verbindungsvorrichtung (1310) zur Datenbank (1308).
  5. Verfahren nach Anspruch 1, wobei das Senden umfasst: Senden eines Ereignisses durch die Datenbank-Verbindungsvorrichtung (1310) zu einem ihrer Nachbarhubs (696, 697), wenn eine Datenstruktur in der Datenbank-Verbindungsvorrichtung (1310) angibt, dass die Datenbank (1308) an Ereignissen mit der Art des Ereignisses teilnimmt.
  6. Verfahren nach Anspruch 1, wobei das Senden umfasst: Senden eines Ereignisses durch die Datenbank-Verbindungsvorrichtung (1310) zu einem ihrer Nachbarhubs (696, 697), wenn ein Inhaltsfilter in einer Datenstruktur der Datenbank-Verbindungsvorrichtung (1310) angibt, dass die Datenbank (1308) an Ereignissen mit Werten, die im Ereignis zu finden sind, teilnimmt.
  7. Verfahren nach Anspruch 1, welches ferner den Schritt umfasst: Senden des Ereignisses durch die Datenbank-Verbindungsvorrichtung (1310) zu einem ihrer Nachbarhubs (696, 697), wenn eine Datenstruktur in der Datenbank-Verbindungsvorrichtung (1310) angibt, dass sich der Nachbarhub auf dem kostengünstigsten Weg zu einem Teilnehmer für das Ereignis befindet.
  8. Verfahren nach Anspruch 1, welches ferner die Schritte umfasst: Feststellen durch die Datenbank-Verbindungsvorrichtung (1310) gemäß einer Datenstruktur der Datenbank-Verbindungsvorrichtung (1310), dass ein Nachbarhub entweder direkt oder indirekt auf dem kostengünstigsten Weg mit einem Teilnehmer für das Ereignis verbunden ist; und Senden des Ereignisses durch die Datenbank-Verbindungsvorrichtung (1310) zu ihrem Nachbarhub, so dass das Ereignis zum Teilnehmer weitergeleitet werden kann.
DE69723612T 1996-01-18 1997-01-17 Datenbanknetzwerk Expired - Fee Related DE69723612T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US588142 1996-01-18
US08/588,142 US5873084A (en) 1996-01-18 1996-01-18 Database network connectivity product

Publications (2)

Publication Number Publication Date
DE69723612D1 DE69723612D1 (de) 2003-08-28
DE69723612T2 true DE69723612T2 (de) 2004-06-09

Family

ID=24352651

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69723612T Expired - Fee Related DE69723612T2 (de) 1996-01-18 1997-01-17 Datenbanknetzwerk

Country Status (4)

Country Link
US (2) US5873084A (de)
EP (1) EP0806731B1 (de)
JP (1) JPH1027121A (de)
DE (1) DE69723612T2 (de)

Families Citing this family (117)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2345157B (en) 1998-12-23 2003-06-18 Ibm Publish and subscribe data processing apparatus, method and computer program product with declaration of a unique publisher broker
US5873084A (en) * 1996-01-18 1999-02-16 Sun Microsystems, Inc. Database network connectivity product
US6704785B1 (en) * 1997-03-17 2004-03-09 Vitria Technology, Inc. Event driven communication system
US6256712B1 (en) 1997-08-01 2001-07-03 International Business Machines Corporation Scaleable method for maintaining and making consistent updates to caches
US6026413A (en) * 1997-08-01 2000-02-15 International Business Machines Corporation Determining how changes to underlying data affect cached objects
US7076784B1 (en) * 1997-10-28 2006-07-11 Microsoft Corporation Software component execution management using context objects for tracking externally-defined intrinsic properties of executing software components within an execution environment
US6216132B1 (en) 1997-11-20 2001-04-10 International Business Machines Corporation Method and system for matching consumers to events
US6310888B1 (en) * 1997-12-30 2001-10-30 Iwork Software, Llc System and method for communicating data
US6510429B1 (en) * 1998-04-29 2003-01-21 International Business Machines Corporation Message broker apparatus, method and computer program product
US6148301A (en) * 1998-07-02 2000-11-14 First Data Corporation Information distribution system
JP2002528813A (ja) 1998-10-23 2002-09-03 ユニシス コーポレイシヨン ソフトウェアの、コード化されたアプリケーションのための自動化されたウェブインターフェイス生成
US7370102B1 (en) 1998-12-15 2008-05-06 Cisco Technology, Inc. Managing recovery of service components and notification of service errors and failures
US6718376B1 (en) 1998-12-15 2004-04-06 Cisco Technology, Inc. Managing recovery of service components and notification of service errors and failures
US7143093B1 (en) * 1998-12-17 2006-11-28 Webmethods, Inc. Enterprise computer system
GB2345158A (en) * 1998-12-23 2000-06-28 Ibm Publish and subscribe data processing with ability to specify a local publication/subscription
US6366926B1 (en) * 1998-12-31 2002-04-02 Computer Associates Think, Inc. Method and apparatus for the dynamic filtering and routing of events
US6446136B1 (en) * 1998-12-31 2002-09-03 Computer Associates Think, Inc. System and method for dynamic correlation of events
US6718332B1 (en) * 1999-01-04 2004-04-06 Cisco Technology, Inc. Seamless importation of data
US6871224B1 (en) * 1999-01-04 2005-03-22 Cisco Technology, Inc. Facility to transmit network management data to an umbrella management system
US6772207B1 (en) * 1999-01-28 2004-08-03 Brocade Communications Systems, Inc. System and method for managing fibre channel switching devices
US6829770B1 (en) * 1999-02-23 2004-12-07 Microsoft Corporation Object connectivity through loosely coupled publish and subscribe events
US7596606B2 (en) * 1999-03-11 2009-09-29 Codignotto John D Message publishing system for publishing messages from identified, authorized senders
IL135156A0 (en) * 1999-03-19 2001-05-20 Ibm Message broker providing a publish/subscribe service and method of processing messages in a publish/subscribe environment
GB2348025A (en) * 1999-03-19 2000-09-20 Ibm Message broker providing a publish/subscribe service and method of processing messages in a publish/subscribe environment
GB2350758A (en) * 1999-06-04 2000-12-06 Ibm Message broker providing a publish/subscribe sevice and method of processing messages in a publish/subscribe environment
US7050432B1 (en) * 1999-03-30 2006-05-23 International Busines Machines Corporation Message logging for reliable multicasting across a routing network
US6405191B1 (en) * 1999-07-21 2002-06-11 Oracle Corporation Content based publish-and-subscribe system integrated in a relational database system
GB2354847A (en) * 1999-09-28 2001-04-04 Ibm Publish/subscribe data processing with subscription points for customised message processing
GB2354913B (en) * 1999-09-28 2003-10-08 Ibm Publish/subscribe data processing with publication points for customised message processing
US6434543B1 (en) * 1999-11-01 2002-08-13 Sun Microsystems, Inc. System and method for reliable caching of database connections in a distributed application
US6970945B1 (en) 1999-11-01 2005-11-29 Seebeyond Technology Corporation Systems and methods of message queuing
EP1287439A2 (de) * 1999-11-01 2003-03-05 Seebeyond Technology Corporation Systeme und verfahren zum reihen von nachrichten
US6920636B1 (en) 1999-12-15 2005-07-19 Microsoft Corporation Queued component interface passing for results outflow from queued method invocations
US6507847B1 (en) 1999-12-17 2003-01-14 Openwave Systems Inc. History database structure for Usenet
US7051118B2 (en) * 1999-12-22 2006-05-23 Tibo Software, Inc. Method and apparatus for anonymous subject-based addressing
US7136860B2 (en) 2000-02-14 2006-11-14 Overture Services, Inc. System and method to determine the validity of an interaction on a network
AU2001250006A1 (en) * 2000-02-25 2001-09-03 Voip Group, Inc. Internet accessible database with telephone entry capability
US6728715B1 (en) 2000-03-30 2004-04-27 International Business Machines Corporation Method and system for matching consumers to events employing content-based multicast routing using approximate groups
US20030037181A1 (en) * 2000-07-07 2003-02-20 Freed Erik J. Method and apparatus for providing process-container platforms
GB2366160B (en) 2000-08-09 2004-03-17 Michaelhouse Man Ltd Information routing
US7216179B2 (en) * 2000-08-16 2007-05-08 Semandex Networks Inc. High-performance addressing and routing of data packets with semantically descriptive labels in a computer network
US6728922B1 (en) * 2000-08-18 2004-04-27 Network Appliance, Inc. Dynamic data space
CA2432141C (en) 2000-12-18 2010-02-09 Cora Alisuag Computer oriented record administration system
US7181490B1 (en) * 2001-02-14 2007-02-20 Cisco Technology, Inc. Method and apparatus for mapping network events to names of network devices
EP1370965A4 (de) * 2001-03-14 2007-03-07 Microsoft Corp Dienst-zu-dienst-kommunikation für netzwerkdienste
US7302634B2 (en) 2001-03-14 2007-11-27 Microsoft Corporation Schema-based services for identity-based data access
US7024662B2 (en) 2001-03-14 2006-04-04 Microsoft Corporation Executing dynamically assigned functions while providing services
WO2002075573A1 (en) 2001-03-19 2002-09-26 Microsoft Corporation System and method for communications management and data exchange
US7149783B2 (en) * 2001-04-12 2006-12-12 Hewlett-Packard Development Company, L.P. Delivery of sequential information
US7433957B2 (en) * 2001-04-30 2008-10-07 International Business Machines Corporation Group access privatization in clustered computer system
US7797375B2 (en) 2001-05-07 2010-09-14 International Business Machines Corporat System and method for responding to resource requests in distributed computer networks
US20020165948A1 (en) 2001-05-07 2002-11-07 International Business Machines Corporation Scalable resource discovery and reconfiguration for distributed computer networks
US8868659B2 (en) * 2001-05-15 2014-10-21 Avaya Inc. Method and apparatus for automatic notification and response
CN1547719A (zh) * 2001-07-05 2004-11-17 确定并产生商业事件的系统和方法
US7765557B2 (en) * 2001-07-05 2010-07-27 Computer Associates Think, Inc. System and method for analyzing business events
KR20040024864A (ko) * 2001-07-05 2004-03-22 컴퓨터 어소시에이츠 싱크, 인코포레이티드 비지니스 이벤트를 생성하고 전파하기 위한 시스템 및 방법
US7057591B1 (en) 2001-07-11 2006-06-06 Nokia Corporation Advertising using an eBook with a bistable display
US7110406B1 (en) * 2001-07-27 2006-09-19 Ciena Corporation Mechanism for facilitating broadcast in a communication system
US7356529B1 (en) * 2001-07-27 2008-04-08 Ciena Corporation Mechanism for facilitating subscription in a publish/subscribe communication system
US6961740B2 (en) 2001-08-01 2005-11-01 Valaran Corporation Method and system for multimode garbage collection
US7411954B2 (en) * 2001-10-17 2008-08-12 Precache Inc. Efficient implementation of wildcard matching on variable-sized fields in content-based routing
WO2003017562A1 (en) * 2001-08-15 2003-02-27 Precache Inc. Packet routing via payload inspection and subscription processing in a publish-subscribe network
US7545805B2 (en) * 2001-08-15 2009-06-09 Precache, Inc. Method and apparatus for content-based routing and filtering at routers using channels
US20030165139A1 (en) * 2001-08-15 2003-09-04 Tsu-Wei Chen Packet routing via payload inspection
WO2003034255A1 (en) * 2001-10-15 2003-04-24 Semandex Networks, Inc. Dynamic content based multicast routing in mobile networks
EP1440367B1 (de) * 2001-10-29 2014-11-26 Accenture Global Services Limited Verbindung einer anwendung mit einem enterprise java bean (ejb) konformen application programming interface (api) durch einen konnektor
US7406537B2 (en) * 2002-11-26 2008-07-29 Progress Software Corporation Dynamic subscription and message routing on a topic between publishing nodes and subscribing nodes
US20220286415A1 (en) * 2001-11-30 2022-09-08 Aurea Software, Inc. Dynamic Subscription and Message Routing on a Topic Between Publishing Nodes and Subscribing Nodes
US7668908B2 (en) * 2001-12-14 2010-02-23 Microsoft Corporation System and method for generalized and distributed scalable eventing system
US20030149740A1 (en) * 2002-02-04 2003-08-07 Wookey Michael J. Remote services delivery architecture
US20030163544A1 (en) * 2002-02-04 2003-08-28 Wookey Michael J. Remote service systems management interface
US20030149889A1 (en) * 2002-02-04 2003-08-07 Wookey Michael J. Automatic communication and security reconfiguration for remote services
US7167448B2 (en) * 2002-02-04 2007-01-23 Sun Microsystems, Inc. Prioritization of remote services messages within a low bandwidth environment
US20030177259A1 (en) * 2002-02-04 2003-09-18 Wookey Michael J. Remote services systems data delivery mechanism
US20030149771A1 (en) * 2002-02-04 2003-08-07 Wookey Michael J. Remote services system back-channel multicasting
US7110991B2 (en) * 2002-03-07 2006-09-19 International Business Machines Corporation IDE integration with JDBC
US7627603B2 (en) * 2002-03-28 2009-12-01 Precache Inc. Method and apparatus for implementing query-response interactions in a publish-subscribe network
US20030208539A1 (en) * 2002-05-02 2003-11-06 Gildenblat Ilya G. Event-driven information publication
US20030212738A1 (en) * 2002-05-10 2003-11-13 Wookey Michael J. Remote services system message system to support redundancy of data flow
US7127467B2 (en) * 2002-05-10 2006-10-24 Oracle International Corporation Managing expressions in a database system
US8495163B2 (en) * 2004-03-18 2013-07-23 Avaya, Inc. Method and apparatus for a publish-subscribe system with templates for role-based view of subscriptions
US8266239B2 (en) * 2002-06-27 2012-09-11 Oracle International Corporation Remote services system relocatable mid level manager
US7240109B2 (en) * 2002-06-27 2007-07-03 Sun Microsystems, Inc. Remote services system service module interface
US7260623B2 (en) * 2002-06-27 2007-08-21 Sun Microsystems, Inc. Remote services system communication module
US7181455B2 (en) * 2002-06-27 2007-02-20 Sun Microsystems, Inc. Bandwidth management for remote services system
US9886309B2 (en) * 2002-06-28 2018-02-06 Microsoft Technology Licensing, Llc Identity-based distributed computing for device resources
EP1535157A4 (de) * 2002-07-08 2010-09-08 Precache Inc Paket-routing über nutzsignaluntersuchung für warndienste für die ablieferung von digitalem inhalt und für die verwaltung der dienstqualität und cache-speicherung mit selektivem multicasting in einem publish-subscribe-netzwerk
US7568148B1 (en) 2002-09-20 2009-07-28 Google Inc. Methods and apparatus for clustering news content
US20040172336A1 (en) * 2003-02-27 2004-09-02 Peter Forsell Method and apparatus for advertising objects
US20040230618A1 (en) * 2003-05-12 2004-11-18 Wookey Michael J. Business intelligence using intellectual capital
US20050128995A1 (en) * 2003-09-29 2005-06-16 Ott Maximilian A. Method and apparatus for using wireless hotspots and semantic routing to provide broadband mobile serveices
US20050222996A1 (en) * 2004-03-30 2005-10-06 Oracle International Corporation Managing event-condition-action rules in a database system
US20050251556A1 (en) * 2004-05-07 2005-11-10 International Business Machines Corporation Continuous feedback-controlled deployment of message transforms in a distributed messaging system
US20050251811A1 (en) * 2004-05-07 2005-11-10 International Business Machines Corporation Distributed messaging system supporting stateful
US7886180B2 (en) * 2004-05-14 2011-02-08 International Business Machines Corporation Recovery in a distributed stateful publish-subscribe system
WO2005125070A2 (en) * 2004-06-14 2005-12-29 Semandex Networks, Inc. System and method for providing content-based instant messaging
US8477627B2 (en) * 2004-07-19 2013-07-02 Solace Systems, Inc. Content routing in digital communications networks
US7895158B2 (en) * 2004-12-27 2011-02-22 Solace Systems Inc. Data logging in content routed networks
US7849199B2 (en) 2005-07-14 2010-12-07 Yahoo ! Inc. Content router
US7631045B2 (en) 2005-07-14 2009-12-08 Yahoo! Inc. Content router asynchronous exchange
US7623515B2 (en) 2005-07-14 2009-11-24 Yahoo! Inc. Content router notification
US8521763B1 (en) 2005-09-09 2013-08-27 Minnesota Public Radio Computer-based system and method for processing data for a journalism organization
US7533128B1 (en) * 2005-10-18 2009-05-12 Real-Time Innovations, Inc. Data distribution service and database management systems bridge
US8065680B2 (en) 2005-11-15 2011-11-22 Yahoo! Inc. Data gateway for jobs management based on a persistent job table and a server table
US8146100B2 (en) 2006-03-21 2012-03-27 Sap Ag System and method for event-based information flow in software development processes
US7580917B2 (en) * 2006-03-22 2009-08-25 Prolific Publishing, Inc. System and method for brokering information between a plurality of commercially distinct clients
US8131696B2 (en) * 2006-05-19 2012-03-06 Oracle International Corporation Sequence event processing using append-only tables
US8762395B2 (en) 2006-05-19 2014-06-24 Oracle International Corporation Evaluating event-generated data using append-only tables
US20090164387A1 (en) * 2007-04-17 2009-06-25 Semandex Networks Inc. Systems and methods for providing semantically enhanced financial information
US8041743B2 (en) * 2007-04-17 2011-10-18 Semandex Networks, Inc. Systems and methods for providing semantically enhanced identity management
US7958155B2 (en) * 2007-04-17 2011-06-07 Semandex Networks, Inc. Systems and methods for the management of information to enable the rapid dissemination of actionable information
US20090144385A1 (en) * 2008-03-03 2009-06-04 Harry Gold Sequential Message Transmission System
US20120047223A1 (en) * 2010-08-20 2012-02-23 Nokia Corporation Method and apparatus for distributed storage
US9319362B1 (en) * 2012-01-25 2016-04-19 Solace Systems, Inc. Messaging system with distributed filtering modules which register interests, remove any messages that do not match the registered interest, and forward any matched messages for delivery
US10372706B2 (en) 2015-07-29 2019-08-06 Oracle International Corporation Tracking and maintaining expression statistics across database queries
US10204135B2 (en) 2015-07-29 2019-02-12 Oracle International Corporation Materializing expressions within in-memory virtual column units to accelerate analytic queries
US11226955B2 (en) 2018-06-28 2022-01-18 Oracle International Corporation Techniques for enabling and integrating in-memory semi-structured data and text document searches with in-memory columnar query processing

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS5992654A (ja) * 1982-11-09 1984-05-28 インタ−ナショナル　ビジネス　マシ−ンズ　コ−ポレ−ション 電子文書配送システム
US4559614A (en) * 1983-07-05 1985-12-17 International Business Machines Corporation Interactive code format transform for communicating data between incompatible information processing systems
JPS60218142A (ja) * 1984-04-13 1985-10-31 Hitachi Ltd デ−タの動的型変換方式
US4975904A (en) * 1984-06-01 1990-12-04 Digital Equipment Corporation Local area network for digital data processing system including timer-regulated message transfer arrangement
US5058108A (en) * 1984-06-01 1991-10-15 Digital Equipment Corporation Local area network for digital data processing system
US4823122A (en) * 1984-06-01 1989-04-18 Digital Equipment Corporation Local area network for digital data processing system
US4975905A (en) * 1984-06-01 1990-12-04 Digital Equipment Corporation Message transmission control arrangement for node in local area network
CA1252903A (en) * 1985-06-11 1989-04-18 Frank D. Bartocci Dynamic update of database directories using directed or undirected mechanisms
US4714995A (en) * 1985-09-13 1987-12-22 Trw Inc. Computer integration system
US4745559A (en) * 1985-12-27 1988-05-17 Reuters Limited Method and system for dynamically controlling the content of a local receiver data base from a transmitted data base in an information retrieval communication network
US4751635A (en) * 1986-04-16 1988-06-14 Bell Communications Research, Inc. Distributed management support system for software managers
US4750135A (en) * 1986-05-01 1988-06-07 Reuters Limited Method for dynamically creating a receiver definable local trading instrument displayable record from a remotely transmitted trading instrument common data stream
US4815030A (en) * 1986-09-03 1989-03-21 Wang Laboratories, Inc. Multitask subscription data retrieval system
US5151989A (en) * 1987-02-13 1992-09-29 International Business Machines Corporation Directory cache management in a distributed data processing system
US4897781A (en) * 1987-02-13 1990-01-30 International Business Machines Corporation System and method for using cached data at a local node after re-opening a file at a remote node in a distributed networking environment
GB2205018B (en) * 1987-05-21 1992-01-02 Reuters Ltd Method and system for dynamically controlling the content of a local receiver data base from a transmitted data base in an information retrieval communication
CA1337132C (en) * 1988-07-15 1995-09-26 Robert Filepp Reception system for an interactive computer network and method of operation
DE3923125A1 (de) * 1989-07-13 1991-01-24 Standard Elektrik Lorenz Ag Universelle isdn-teilnehmeranschlussbaugruppe
US5339392A (en) * 1989-07-27 1994-08-16 Risberg Jeffrey S Apparatus and method for creation of a user definable video displayed document showing changes in real time data
US5257369A (en) * 1990-10-22 1993-10-26 Skeen Marion D Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes
US5557798A (en) * 1989-07-27 1996-09-17 Tibco, Inc. Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes
US5187787B1 (en) * 1989-07-27 1996-05-07 Teknekron Software Systems Inc Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes
JPH05307556A (ja) * 1992-04-30 1993-11-19 Olympus Optical Co Ltd 統合データベースを用いた情報処理装置
US5426781A (en) * 1992-04-30 1995-06-20 International Business Machines Corporation Computerized report-based interactive database query interface
EP0593062A3 (en) * 1992-10-16 1995-08-30 Siemens Ind Automation Inc Redundant networked database system
JPH06161862A (ja) * 1992-11-18 1994-06-10 Oki Electric Ind Co Ltd トランザクション制御装置
US5491818A (en) * 1993-08-13 1996-02-13 Peoplesoft, Inc. System for migrating application data definition catalog changes to the system level data definition catalog in a database
US5513126A (en) * 1993-10-04 1996-04-30 Xerox Corporation Network having selectively accessible recipient prioritized communication channel profiles
US5625818A (en) * 1994-09-30 1997-04-29 Apple Computer, Inc. System for managing local database updates published to different online information services in different formats from a central platform
US5873084A (en) * 1996-01-18 1999-02-16 Sun Microsystems, Inc. Database network connectivity product

Also Published As

Publication number Publication date
JPH1027121A (ja) 1998-01-27
DE69723612D1 (de) 2003-08-28
US5974417A (en) 1999-10-26
EP0806731B1 (de) 2003-07-23
EP0806731A3 (de) 1998-12-09
US5873084A (en) 1999-02-16
EP0806731A2 (de) 1997-11-12

Similar Documents

Publication Publication Date Title
DE69723612T2 (de) Datenbanknetzwerk
DE69727438T2 (de) Zwischenspeicher-Protokoll für verbesserte Webleistung
DE602005000635T2 (de) Verfahren und Netzknoten zum Konfigurieren der Topologie eines Netzwerks
DE69533838T2 (de) Verfahren und System zur Aktualisierung der nachgebildeten Datenbanken in Fernsprechnetzen
DE69730056T2 (de) Routen von duplikaten
DE60008102T2 (de) Verfahren und vorrichtung zur mehrfachsendung
DE60133648T2 (de) System und verfahren zum führen von laufzeitdaten in einem server-netzwerk
DE69628718T2 (de) Netzwerk - Topologie-Verwaltungssystem
DE69929095T2 (de) Verwaltung eines durch eine Mehrzahl von Knoten benutzten Betriebsmittels
DE69837010T2 (de) System und verfahren zum steuern des zugriffs auf eine vermittlungsdatenbank
DE69720857T2 (de) Systeme und Verfahren zum Betrieb einer Netzwerk-Verwaltungsstation
DE10049569B4 (de) Zugriff und Aktualisierung einer Konfigurationsdatenbank von verteilten physischen Orten innerhalb eines Prozeßsteuerungssystems
DE69834807T2 (de) System und verfahren zum auswählen und laden verschiedener typen von videodaten in einem computernetzwerk
DE60038705T2 (de) Verfahren und vorrichtung für die aktivitäts-basierte zusammenarbeit eines rechnersystems, ausgestattet mit einem kommunikations-manager
DE69909839T3 (de) Optimierte Lokalisierung von Netzwerkbetriebsmittel
US6510429B1 (en) Message broker apparatus, method and computer program product
EP0849666B1 (de) Verfahren zum Instantiieren einer versionsbehafteten Klasse
DE69733266T2 (de) Ausfallsicheres und ereignisgesteuertes transaktions-system und verfahren
DE69832002T2 (de) Übertragungssystem und Übertragungsverfahren,Empfangssystem und Empfangsverfahren
DE19747583B4 (de) Kommunikationssystem und Verfahren
DE10311082B4 (de) Elektronikdokumentmanagementverfahren
DE69938122T2 (de) Verfahren und System zur Softwareverteilung
DE19607149A1 (de) Verfahren zum rechnergestützten Abgleich mehrerer, in mindestens einem Rechner gespeicherten Dateikopien einer gespeicherten Datei
DE60131047T2 (de) Verwaltung von Protokollinformationen in hierarchischen PNNI-Netzen
DE10392438T5 (de) Vorrichtung und Verfahren zur zentralen Überwachung und Steuerung von Anlagen

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee