-
Gebiet der Erfindung
-
Die
Erfindung betrifft Echtzeit-Kommunikationsszenarien, welche mit
Computernetzwerken verknüpft
sind. Insbesondere betrifft die Erfindung Echtzeit-Nachrichtenübertragungs-Mechanismen
für kollaborative
(bzw. gemeinschaftliche) Netzwerkumgebungen, wie zum Beispiel elektronische
Konferenzen, Livechat-Foren und elektronische Online-Auktionen.
-
Hintergrund der Erfindung
-
Als
Folge der Allgegenwärtigkeit
von Computernetzwerken nehmen Computer in zunehmendem Maße an komplexen,
verteilten Communities (bzw. Gemeinschaften) von Personen und Systemen teil,
anstatt als abgeschlossene, von einer einzelnen Person verwendete
Einrichtungen betrieben zu werden. Diese bedeutende Verschiebung
in der Art, in der Computer verwendet werden, hat zu Computersystemen
geführt,
die in der Lage sind, tatsächlich
als Mitglieder einer kollaborativen Netzwerk-Community zu handeln.
-
Kollaborative
Netzwerk-Communities enthalten eine oder mehrere Datenquellen und
eine oder mehrere Datenempfänger.
Eine Besonderheit kollaborativer Netzwerk-Communities ist der Umstand, dass wenigstens
einige der Datenquellen üblicherweise
auch als Empfänger
von Daten agieren und dass wenigstens einige der Datenempfänger auch die
Rolle von Datenquellen spielen können.
Kollaborative Netzwerk-Communities
können über lange Zeiträume fortbestehen,
sich spontan für
eine einzelne Gruppenaktivität
bilden oder wiederholt zusammenkommen.
-
In
der Vergangenheit wurden kollaborative Aufgaben üblicherweise hintereinander
durchgeführt. Ein
typisches Beispiel ist die kollaborative Dateiverarbeitung. Eine
Datei wird von einer Datenquelle an einen Datenempfänger gesendet.
Der Datenempfänger ändert die
Datei und sendet sie an einen weiteren Datenempfänger oder zurück zur Datenquelle,
welche dann als Datenempfänger
agiert, und so weiter. In solchen konventionellen kollaborativen
Szenarien spielt die Transferzeit einer Datei von einer Netzwerk-Komponente
zu einer anderen keine große
Rolle, da sie vernachlässigbar im
Vergleich zu der Zeit ist, die benötigt wurde, die Datei zu erstellen,
zu verändern,
zu bearbeiten etc..
-
Gleichzeitig
mit dem Einsatz zunehmend leistungsfähigerer Computer und Netzwerk-Infrastruktur in
den letzten Jahren haben sich kollaborative Netzwerk-Communities
gebildet, die Echtzeit-Informationsaustausch erfordern. Als Beispiele
für derartige
kollaborative Echtzeit-Netzwerk-Communities können verschiedene Online-Anwendungen, wie Livechat-Foren,
elektronische Konferenzen und elektronische Online-Auktionen, erwähnt werden.
Es ist offensichtlich, dass für
solche Online-Anwendungen die Übermittlungszeit
für Informationen
von Bedeutung ist, da jede Übermittlungsverzögerung von
einem Teilnehmer, der auf bestimmte Informationen wartet, als verschwendete
Zeit empfunden wird.
-
Informationsaustausch
zwischen den einzelnen Teilnehmern einer kollaborativen Echtzeit-Netzwerkumgebung
wird sehr oft von einer zentralen Netzwerk-Komponente mit Fähigkeiten
zum Nachrichtenaustausch gesteuert. Eine solche zentrale Netzwerk-Komponente empfängt Informationen
von einer Datenquelle, bearbeitet die Informationen falls erforderlich
und erstellt entsprechende Nachrichten, die an einen oder mehrere
Datenempfänger
gesendet werden. Die an die Empfänger
versandten Nachrichten können
die von der Datenquelle empfangenen Informationen, daraus abgeleitete
Informationen oder einfach eine spezielle Benachrichtigung enthalten.
Nachrichten können
von der zentralen Netzwerk-Komponente auch auf ein internes Ereignis
hin versendet werden, beispielsweise um die kollaborative Community
von eine neuen Sitzung oder von technischen Problemen zu benachrichtigen.
-
Üblicherweise
werden Nachrichten von der zentralen Netzwerk-Komponente einfach
als Rundsendungen an die kollaborative Community übertragen.
Das Rundsenden von Nachrichten hat den Vorteil, dass keine komplizierten
Adressierungsaufgaben durchgeführt
werden müssen,
was ein schnelles Erstellen und Übermitteln
von Nachrichten erlaubt. Rundsendungs-Ansätze haben jedoch den Nachteil, dass
es allgemein nicht möglich
ist, Informationen, die an einen einzelnen Empfänger gerichtet sind, zu übermitteln,
wie vertrauliche oder persönliche
Informationen. Andererseits sind zahlreiche Ansätze, die eine derartige individualisierte Übertragung
von Nachrichten an einzelne Teilnehmer ermöglichen, von immanenten Verarbeitungsverzögerungen
begleitet, die mit dem Erstellen, Adressieren und Versenden individualisierter
Nachrichten einher gehen.
-
Die
EP 1 199 652 A1 lehrt
eine E-Mail-Verarbeitungstechnik. Die Technik enthält das Ausliefern einer
von einem E-Mail-Server empfangenen E-Mail an eine Mailablagesteuerung,
von welcher sie dann in einen Mailablagespeicher abgelegt wird,
wobei mögliche
Anhänge
der E-Mail an einem anderen Ablage-Ort abgelegt werden. Die Anhänge werden dann
einer Verarbeitungsoperation unterzogen. Schließlich ruft eine Serversteuerung
die Nachricht und die Anhänge
ab und liefert sie an die Mailablagesteuerung, welche sie an den
E-Mail-Server zur darauffolgenden Auslieferung an einen Empfänger weiterleitet.
-
Die
U.S. 2002/0073158 offenbart
ein Online-Auktionssystem, in welchem Benachrichtigungen an Benutzer
auf einer Kontaktliste versandt werden, wenn sie durch einen anderen
Benutzer überboten wurden.
-
Die
der Erfindung zugrunde liegende Aufgabe ist daher, einen Ansatz
für Echtzeit-Nachrichtenaustausch
für eine
kollaborative Netzwerkumgebung bereitzustellen, der einen individualisierten
Nachrichtenaustausch zulässt
und gleichzeitig Verzögerungen,
die mit einer solchen individualisierten Nachrichtenübermittlung
einher gehen, vermeidet oder wenigstens reduziert.
-
Zusammenfassung der Erfindung
-
Diese
Aufgabe wird durch ein Echtzeit-Nachrichtenaustausch-Verfahren nach
Anspruch 1, ein Computerprogrammprodukt nach Anspruch 14 und eine
Echtzeit-Nachrichtenaustausch-Komponente nach
Anspruch 16 gelöst.
-
Nach
einem Aspekt der Erfindung wird ein Echtzeit-Nachrichtenaustausch-Verfahren
für kollaborative
Kommunikationsszenarien bereitgestellt, in welchen Nachrichten,
welche sich auf Informationen beziehen, die von einer oder mehreren
Datenquellen empfangen wurden, an einen oder mehrere Nachrichtenempfänger übermittelt
werden, welche selbst als Datenquellen agieren können. Das Verfahren umfasst
ein Einreihen der an die Empfänger
zu sendenden und Verweise auf die Inhaltsdaten enthaltenden Nachrichten
in eine Warteschlange, ein Auslesen von Nachrichten aus der Nachrichten-Warteschlange,
ein Anfordern der Inhaltsdaten, auf die in den Nachrichten verwiesen
wird, und ein Einfügen
der angeforderten Inhaltsdaten in die aus der Nachrichten-Warteschlange
ausgelesenen Nachrichten. Nach dem Verfahren werden die Nachrichten
auf eine Auslese-Anforderung eines bestimmten Empfängers gelesen und
die Nachrichten für
den Empfänger
werden in der Warteschlange fortlaufend nummeriert.
-
Die
Verwendung einer Nachrichten-Warteschlange erlaubt prinzipiell einen
individualisierten Nachrichtenaustausch. Um mit den immanenten Nachrichten-Übermittlungsverzögerungen,
mit denen das Einreihen von Nachrichten in die Warteschlange verbunden
ist, zurecht zu kommen, können einige
oder alle der eingereihten Nachrichten inhaltsleer sein. Dieser
Ansatz ermöglicht
die Implementierung einer schlanken Nachrichten-Warteschlange, welche
ein schnelleres Abwickeln der in die Warteschlange eingereichten
Nachrichten zulässt.
-
Die
Inhaltsdaten können
zentral oder auf eine verteilte Weise abgelegt werden. Dazu kann
wenigstens eine Inhaltsdatenbank bereitgestellt werden, aus der
die angeforderten Inhaltsdaten, auf die aus in einer in der Warteschlange
eingereihten Nachrichten verwiesen wird, abgerufen werden können. Die
Inhaltsdatenbank kann eine dedizierte, einer Nachrichtenaustausch-Komponente
zugewiesene Datenbank oder eine gemeinsam benutzte Datenbank sein,
welche gemeinsam von der Nachrichtenaustausch-Komponente und einer
oder mehreren weiteren Komponenten benutzt wird. Die eine oder mehreren
weiteren Komponenten, die auch die gemeinsam benutzte Inhaltsdatenbank
benutzen, können
eine kollaborative Anwendungskomponente enthalten. Die kollaborative
Anwendungskomponente kann programmiert sein, eine kollaborative
Sitzung, wie eine elektronische Auktion und/oder eine elektronische
Konferenz und/oder eine elektronische Chat-Umgebung, zu steuern.
Im Rahmen der vorliegenden Erfindung bezieht sich der Begriff "Komponente" auf Software, Hardware
oder eine Kombination davon.
-
Daten,
die von der einen oder den mehreren Datenquellen empfangen wurden,
oder daraus abgeleitete Daten, können
als Inhaltsdaten in der einen oder den mehreren Inhaltsdatenbanken
abgelegt werden. Vorzugsweise wird die eine oder werden die mehreren
Inhaltsdatenbanken der kollaborative Anwendungskomponente zugewiesen
und von dieser verwaltet. In solch einem Fall kann die kollaborative Anwendungskomponente
für das
Abwickeln von Inhaltsdaten-Anforderungen zuständig sein, welche beispielsweise über eine
dedizierte Schnittstelle von der Nachrichtenaustausch-Komponente
empfangen werden.
-
Die
Implementierung einer schlanken Nachrichten-Warteschlange, welche
Nachrichten enthält, welche
nicht die Inhaltsdaten als solche, sondern lediglich Verweise auf
Inhaltsdaten enthalten, lässt eine
effiziente Abwicklung von Nachrichten zu. Insbesondere können Mechanismen
bereitgestellt werden, um die Zeit zu minimieren, die zum Abrufen
angeforderter Inhaltsdaten, auf die in einer eingereihten Nachricht verwiesen
wird, aus der Inhaltsdatenbank erforderlich ist. Solche Mechanismen
können
beispielsweise in Abhängigkeit
des Volumens der abzurufenden Inhaltsdaten optimiert werden. Ein
solcher Ansatz ist insbesondere in den Fällen vorteilhaft, in denen
das in die eingereihten Nachrichten einzufügende Datenvolumen stark variiert,
beispielsweise von wenigen Kilobyte bis zu vielen Gigabyte.
-
Die
in der Nachrichten-Warteschlange enthaltenen Nachrichten können an
einzelne bzw. individuelle Nachrichten-Empfänger adressiert sein. Die Adressierung
von Nachrichten lässt
die Erzeugung von Nachrichten zu, welche empfänger-spezifische Daten enthalten
oder darauf verweisen. Es ist jedoch auch möglich, alternativ oder zusätzlich hierzu
generische Inhaltsdaten in adressierte Nachrichten aufzunehmen.
Adressierte Nachrichten können
an einzelne, an einer kollaborativen Sitzung teilnehmende Komponenten
oder nach einem Rundruf-Verfahren an alle teilnehmenden Komponenten
versandt werden.
-
Es
können
verschiedene Mechanismen zum Auslesen von Nachrichten aus der Nachrichten-Warteschlange
implementiert werden. Eine Nachrichtenübermittlung kann auf interne
oder externe Ereignisse hin ausgelöst werden. Die eine oder mehreren Nachrichten,
die für
einen bestimmten Nachrichtenempfänger
eingereiht sind, können
beispielsweise als Antwort auf ein externes Ereignis, wie ein Empfangen
einer Nachrichten-Abruf-Anforderung von dem bestimmten Nachrichtenempfänger, gelesen werden.
Die Nachrichtenempfänger
können
programmiert sein, Nachrichten-Abruf-Anforderungen in regelmäßigen Zeitintervallen
oder auf eine Benutzer-Interaktion hin zu senden. Alternativ oder
zusätzlich
dazu können
Nachrichtenübermittlungen
als Antwort auf interne Ereignisse hin (wie ein bestimmtes, beispielsweise
durch die Nachrichtenaustausch-Komponente durchgeführtes Nachrichten-Abruf-Verfahren)
und unabhängig
vom Empfangen einer Nachrichten-Abruf-Anforderung von einem Teilnehmer
einer kollaborativen Sitzung implementiert werden.
-
Die
in die Warteschlange eingereihten Nachrichten können Verweise auf Systemdaten
enthalten. Systemdaten, auf die in einer eingereihten Nachricht verwiesen
wird, können
sich beispielsweise auf einen Text beziehen, der einen Nachrichtenempfänger auf eine
standardisierte Weise über
ein bestimmtes Ereignis, wie zum Beispiel das Anmelden oder Abmelden
eines einzelnen Teilnehmers einer kollaborativen Sitzung, informiert.
Die Systemnachrichten können
in einer Systemnachrichten-Datenbank abgelegt sein. Die Systemnachrichten-Datenbank
kann eine dedizierte Datenbank der Nachrichtenaustausch-Komponente
sein.
-
Die
in der Inhaltsdatenbank gespeicherten Inhaltsdaten können auf
vielfältige
Weise verwaltet werden. Nach einem exemplarischen Ansatz sind die in
die eingereihten Nachrichten einzufügenden Inhaltsdaten in Datenobjekten
enthalten. In diesem Fall kann sich der in der eingereihten Nachricht
enthaltene Verweis auf ein bestimmtes Datenobjekt oder einen Teil
davon beziehen. Verschiedene Arten von Datenobjekten (Objektklassen)
können
in Abhängigkeit
von den typischen Informationen, die im Kontext mit dieser Anwendung übermittelt
werden müssen, für eine bestimmte
kollaborative Anwendung definiert sein.
-
Einzelne
Empfänger
können
einzelnen Datenobjekten zugewiesen werden und umgekehrt. Dies lässt beispielsweise
zu, alle Teilnehmer einer bestimmten Sitzung, wie einer elektronischen
Auktion, einer Konferenz oder einem Chat, für welche das Datenobjekt definiert
wurde, zu bestimmen. Die Zuweisung kann auch verwendet werden, um
Nachrichten für
alle einem bestimmten Datenobjekt zugeordneten Empfänger auf
ein internes oder externes, in Beziehung mit dem bestimmten Datenobjekt
stehenden Ereignis hin zu erzeugen.
-
Der
in den eingereihten Nachrichten enthaltene Verweis auf Inhaltsdaten
kann unterschiedliche Formate aufweisen. Nach einem Beispiel enthält der Verweis
auf Inhaltsdaten einen Datenobjekt-Identifikator. Datenobjekt-Identifikatoren
können
der Vielzahl von Datenobjekten, in denen Inhaltsdaten, auf die verwiesen
wird, abgelegt sind, eindeutig zugewiesen werden. Der Datenobjekt-Identifikator
kann sich daher beispielsweise auf eine bestimmte, von der kollaborativen
Anwendungskomponente verwaltete Sitzung beziehen.
-
Zusätzlich oder
als eine Alternative zu dem Datenobjekt-Identifikator kann der Verweis
auf Inhaltsdaten Nachrichtentyp-Informationen enthalten, welche
allgemein die in eine in der Warteschlange eingereihte Nachricht
einzufügenden
Inhaltsdaten spezifizieren. Die Verbindung aus Datenobjekt-Identifikator
und Nachrichtentyp-Informationen
kann verwendet werden, um Inhaltsdaten eindeutig zu bezeichnen,
die in eine aus der Nachrichten-Warteschlange ausgelesene Nachricht
einzufügen
sind. Während
der Datenobjekt-Identifikator das bestimmte Datenobjekt angibt,
aus dem Inhaltsdaten gelesen werden müssen, definieren die Nachrichtentyp-Informationen, welche
bestimmten, in diesem Datenobjekt enthaltenen Inhaltsdaten aus diesem
Datenobjekt zu lesen sind. Die in einer eingereihten Nachricht enthaltenen
Informationen können
daher allgemein bestimmte Inhaltsdaten angeben, die anzufordern oder
aus dem Datenobjekt zu lesen sind, auf das durch den Datenobjekt-Identifikator
der eingereihten Nachricht verwiesen wird.
-
Um
den Verlust von Nachrichten zu bemerken und damit zurecht zu kommen,
können
die für
einen einzelnen Nachrichtenempfänger
erzeugten Nachrichten fortlaufend nummeriert und die entsprechenden
Nachrichtennummern in den Nachrichten enthalten sein, die für den einzelnen
Nachrichtenempfänger
in der Warteschlange eingereiht sind. Auf ein Empfangen einer Nachricht
hin kann jeder Nachrichtenempfänger
daher die Nachrichtennummer der neu empfangenen Nachricht mit der
Nachrichtennummer der letzten Nachricht vergleichen und bestimmen,
ob irgendwelche Nachrichten fehlen. Solch ein Nummerierungs-Ansatz
kann auch von Datenquellen verwendet werden. Dies bedeutet, dass
die Datenquellen ihre Übermittlungen
fortlaufend nummerieren und die entsprechenden Übermittlungsnummern in ihre Übermittlungen
einfügen
können. Dies
erlaubt es der Nachrichtenaustausch-Komponente zu bestimmen, ob Übermittlungen
verloren gingen.
-
Weiterhin
können
die Nachrichtennummern für
die Implementierung effizienter Aktualisierungs-Ansätze verwendet
werden. Falls die Nummer der letzten Nachricht, die aus der Nachrichten-Warteschlange
zum Zweck des Einfügens
von Inhaltsdaten abgelegt wurde, gespeichert wurde, kann die nächste Leseoperation
derart gesteuert werden, dass nur Nachrichten mit Nachrichtennummern,
die größer als die
gespeicherte Nachrichtennummer sind, berücksichtigt werden. Somit können die
Nachrichtennummern zum Implementieren eines sogenannten Delta-Aktualisierungsansatzes
verwendet werden, was den Netzwerk-Verkehr stark reduziert.
-
Aus
verschiedenen Gründen,
beispielsweise um einzelne, in einer Nachrichten-Warteschlange aufgenommene Nachrichten
(aufgrund eines Nachrichtenverlusts) mehr als einmal an einen bestimmten
Empfänger
zu versenden oder um ein vollständiges
Aktualisieren eines bestimmten Empfängers zu ermöglichen,
ist es vorteilhaft, dass die in der Warteschlange eingereihten Nachrichten
in der Warteschlange verbleiben, nachdem sie gelesen wurden. Da
eine schlanke Nachrichten-Warteschlange
implementiert ist, müssen
selbst dann keine Speicherprobleme befürchtet werden, wenn alle Nachrichten während der
gesamten Lebensdauer einer kollaborativen Sitzung in der Nachrichten-Warteschlange
verbleiben. Die Nachrichten in einer Nachrichten-Warteschlange können erst
dann gelöscht
werden, nachdem eine bestimmte kollaborative Sitzung beendet wurde.
-
Die
vorliegende Erfindung kann als Software implementiert werden, als
eines oder mehrere Hardware-Teile oder als eine Kombination aus
beidem. Daher betrifft die Erfindung auch ein Computerprogrammprodukt
mit Programmcodeabschnitten zur Durchführung der einzelnen Schritte
der Erfindung, wenn das Computerprogrammprodukt auf einer oder mehreren
Komponenten eines Computernetzwerks abläuft. Das Computerprogrammprodukt
kann auf einem computerlesbaren Aufzeichnungsmedium gespeichert
sein.
-
Nach
einem weiteren Aspekt der Erfindung wird eine Echtzeit-Nachrichtenaustausch-Komponente für kollaborative
Kommunikationsszenarien bereit gestellt, in welchen Nachrichten,
die sich auf Informationen beziehen, die von einer oder mehreren Datenquellen
empfangen wurden, an einen oder mehrere Nachrichtenempfänger übermittelt
werden, die selbst als Datenquellen agieren können. Die Echtzeit-Nachrichtenaustausch-Komponente
umfasst einen Zugang zu bzw. Zugriff auf wenigstens eine Inhaltsdatenbank,
in welcher Inhaltsdaten abgespeichert sind, und eine Nachrichten-Warteschlange zum
Einreihen von Nachrichten, die an den einen oder mehreren Empfänger zu
senden sind. Die in die Warteschlange eingereihten Nachrichten enthalten Verweise
auf Inhaltsdaten in der Inhalts-Datenbank und fortlaufende Nachrichtennummern.
Die Echtzeit-Nachrichtenaustausch-Komponente umfasst ferner einen
Nachrichtenzusammensetzer zum Auslesen von in der Nachrichten-Warteschlange enthaltenen
Nachrichten, zum Anfordern der in den Nachrichten verwiesenen Inhaltsdaten
und zum Einfügen
der angeforderten Inhaltsdaten in die aus der Nachrichten-Warteschlange
ausgelesenen Nachrichten. Die Nachrichten-Komponente enthält ferner eine Schnittstelle
zum Empfangen einer ersten Nachricht und eine Komponente zum Neuerzeugen
einer oder mehrerer zweiter Nachrichten als Antwort auf ein Empfangen
der ersten Nachricht und einen Nachrichtenzusammensetzer zum Auslesen
der zweiten Nachrichten aus der Nachrichten-Warteschlange bei Erhalt
einer Nachrichtenabfrage-Anforderung.
-
Die
Echtzeit-Nachrichtenaustausch-Komponente kann mit einer Vielzahl
von dedizierten Schnittstellen für
verschiedene Kommunikationsaufgaben bereitgestellt sein, die im
Zusammenhang mit der bestimmten kollaborativen Anwendung, für die ein Nachrichtenaustausch
durchgeführt
wird, auftreten. Eine Nachrichtenaustausch-Schnittstelle kann für die Aufgabe des Empfangens
von Nachrichten-Abfrageanforderungen
von den Nachrichtenempfängern bereit
gestellt sein. Zusätzlich
oder alternativ dazu können
eine oder mehrere Anmelde- und Abmelde-Schnittstellen zum Empfangen und Senden
von Anmelde- oder Abmelde-Informationen
verwendet werden. Ferner kann die Echtzeit-Nachrichtenaustausch-Komponente eine Datenschnittstelle
zum Empfangen von Daten, wie Geboten oder Chat-Nachrichten von den
Datenquellen, enthalten.
-
Die
Aufgabe des Routens empfangener Informationen oder von Informationen,
die über
die passende Schnittstelle zu versenden sind, kann durch einen Nachrichtenaustausch-Server
gesteuert werden. Der Nachrichtenaustausch-Server kann als eine
Zwischenkomponente konfiguriert sein, welche zwischen der Nachrichtenaustausch-Komponente einerseits
und den als Datenquellen/Nachrichtenempfänger agierenden Netzwerk-Komponenten
andererseits angeordnet ist.
-
Die
Echtzeit-Nachrichtenaustausch-Komponente kann eine oder mehrere
dedizierte Datenbanken einschließlich der oben erwähnten Inhaltsdatenbank
enthalten. Zusätzlich
oder alternativ dazu kann eine Client-Registrierungs-Datenbank zum
Ablegen von Zuordnungen zwischen einzelnen Datenempfängern und
einzelnen Inhaltsdaten oder Datenobjekten, welche die Inhaltsdaten
enthalten, bereitgestellt sein.
-
Nach
noch einem weiteren Aspekt betrifft die Erfindung ein Nachrichtenaustausch-Netzwerk, welches
eine kollaborative Anwendungs-Komponente einschließlich der
Inhaltsdatenbank und die oben beschriebene Nachrichtenaustausch-Komponente
umfasst. Die Nachrichtenaustausch-Komponente kann eine Schnittstelle
zur kollaborativen Anwendungs-Komponente zum Anfordern und Empfangen von
Inhaltsdaten aufweisen. Vorzugsweise ist die Anwendungs-Komponente
als eine Online-Transaktionsorientierte-Ausführungs-Komponente
(OLTP) konfiguriert.
-
Zusätzlich zur
kollaborativen Anwendungs-Komponente und zur Nachrichtenaustausch-Komponente
kann das Nachrichtenaustausch-Netzwerk ferner eine kollaborative
Umgebung umfassen, welche verteilte Netzwerk-Komponenten enthält, die
mittels der Nachrichtenaustausch-Komponenten miteinander kommunizieren.
-
Kurze Beschreibung der Zeichnungen
-
Weitere
Details, Ausführungsformen,
Abwandlungen und Verbesserungen der vorliegenden Erfindung können durch
Studium der folgenden Beschreibung verschiedener veranschaulichender
Ausführungsformen
der Erfindung in Verbindung mit den Zeichnungen erhalten werden,
von denen:
-
1 eine
schematische Darstellung ist, die eine exemplarische technische
Verwirklichung einer kollaborativen Netzwerkumgebung darstellt,
die eine Echtzeit-Nachrichtenaustausch-Komponente
nach der vorliegenden Erfindung enthält;
-
2 eine
schematische Darstellung ist, die eine hardware-orientierte Ansicht
einer mehrstufigen Serverkonfiguration des Echtzeit-Nachrichtenaustausch-Netzwerks
nach der vorliegenden Erfindung dargestellt;
-
3 eine
schematische Darstellung ist, welche eine software-orientierte funktionale
Ansicht einer Anmeldeprozedur dargestellt, welche die Nachrichtenaustausch-Komponente der vorliegenden
Erfindung involviert;
-
4 eine
schematische Darstellung ist, welche die Datenbankstruktur einer
zentralen Netzwerk-Komponente der vorliegenden Erfindung einschließlich der
Echtzeit-Nachrichtenaustausch-Komponente
und einer Anwendungs-Komponente dargestellt;
-
5 eine
schematische Darstellung ist, die eine software-orientierte funktionale
Ansicht einer Gebots-Einreichprozedur dargestellt, welche die Nachrichtenaustausch-Komponente der vorliegenden
Erfindung involviert;
-
6 eine
schematische Darstellung ist, die eine software-orientierte funktionale
Ansicht einer Nachrichten-Abholprozedur dargestellt, welche durch
die Nachrichtenaustausch-Komponente der vorliegenden Erfindung durchgeführt wird;
-
7 eine
schematische Darstellung einer software-orientierten funktionalen
Ansicht einer Abmeldeprozedur dargestellt, welche die Nachrichtenaustausch-Komponente
der vorliegenden Erfindung involviert;
-
8 eine
schematische Darstellung ist, die eine grafische Benutzerschnittstelle
einer Netzwerk-Komponente eines ersten Typs dargestellt, die mit
der Nachrichtenaustausch-Komponente der vorliegenden Erfindung kommuniziert;
und
-
9 eine
schematische Darstellung ist, die eine grafische Benutzerschnittstelle
einer Netzwerk-Komponente eines zweiten Typs dargestellt, der mit
der Nachrichtenaustausch-Komponente der vorliegenden Erfindung kommuniziert.
-
Detaillierte Beschreibung
bevorzugter Ausführungsformen
-
Wo
es angebracht ist, werden im Rahmen dieser detaillierten Beschreibung
in Verbindung mit den Zeichnungen die selben Bezugszeichen verwendet,
um auf die selben oder ähnliche
Elemente zu verweisen.
-
1 veranschaulicht
ein vereinfachtes Blockdiagramm einer kollaborativen Netzwerkumgebung
nach der vorliegenden Erfindung, welche eine Echtzeit-Nachrichtenaustausch-
und Anwendungs-Komponente 100 und eine Vielzahl weiterer Netzwerk-Komponenten 101, 102,
etc., die als Teilnehmer einer kollaborativen Netzwerk-Community agieren,
enthält.
Die Netzwerk-Komponenten 100, 101, 102,
etc. sind mittels eines Netzwerks 190 gekoppelt und können beispielsweise
als Clients, Server, Router, Peer-Gerät oder als jedes andere gebräuchliche
Netzwerkgerät
realisiert sein.
-
Jede
Netzwerk-Komponente 100, 101, 102, etc.
umfasst einen Prozessor 110, einen Speicher 120,
einen Bus 130 und optional eines oder mehrere als Benutzerschnittstelle 160 agierende
Eingabegeräte 140 und
Ausgabegeräte 150 (I/O-Geräte), die
in einer herkömmlich
bekannten Weise zusammenwirken. Die vorliegende Erfindung kann in
einem Computerprogrammprodukt (nachfolgend CPP genannt) ausgeführt sein,
welches sich auf einem Programmträger 170 und/oder in
dem Speicher 120 befinden kann und Programmsignale 180 erzeugt,
welche in ihrer Gesamtheit ein „Programm" genannt werden.
-
Die
Netzwerk-Komponenten 101, 102, etc. umfassen typischerweise
viele oder alle der mit Bezug auf die Netzwerk-Komponente 100 beschriebenen
Elemente. Daher stellen die Elemente 110–180 in
der Netzwerk-Komponente 100 in ihrer Gesamtheit auch entsprechende
Elemente in den anderen Netzwerk-Komponenten 101, 102,
etc. des Netzwerks 190 dar.
-
Obwohl
der Speicher 120 zweckmäßigerweise
als Teil der Netzwerk-Komponente 100 dargestellt ist, kann
eine Speicherfunktion auch als ein unabhängiger Knoten in dem Netzwerk 190 implementiert werden
oder in den anderen Komponenten des Netzwerks, in dem Prozessor 110 selbst
(zum Beispiel Cache, Register) oder anderswo. Bereiche des Speichers 120 können bezüglich einer
bestimmten Netzwerk-Komponente
entfernbar oder nicht entfernbar sein. Der Speicher 120 kann
Software-Programm-Unterstützungsmodule
speichern, wie beispielsweise ein Basic Input Output System (BIOS), ein
Betriebssystem (OS), eine Programmbibliothek, einen Übersetzer,
einen Interpreter, Kommunikationsprogramme, Treiber, Protokollumsetzer,
Software-Anwendungsprogramme, (Internet-)Browser oder Datenbank-Applikationen. Obwohl
das CPP als im Speicher 120 gespeichert dargestellt ist,
kann das CPP auch woanders vorgesehen sein. Beispielsweise kann
das CPP auch auf dem Programmträger 170 ausgeführt sein.
-
Das
CPP umfasst Programmanweisungen und – optional – Daten oder Variablen, die
den Prozessor 110 dazu veranlassen, die Schritte auszuführen, welche
die Methodologie der vorliegenden Erfindung bilden. Die Verfahrensschritte
werden unten genauer erklärt.
Das CPP definiert und steuert den Betrieb der Netzwerk-Komponente 100 und
ihre Interaktion in dem Netzwerksystem 190. Beispielsweise
und ohne einschränkende
Absicht kann das CPP als Quellcode in einer beliebigen Programmiersprache und
als Objektcode („Binärcode") in einer übersetzten
Repräsentation
verfügbar
sein. Ein Fachmann kann das CPP in Verbindung mit einem beliebigen der
oben erwähnten
Unterstützungsmodule
verwenden. Die Funktionalitäten
einer oder mehrerer der Netzwerk-Komponenten 100, 101, 102 etc.
und des CPP sind eng verwandt. Ausdrücke wie zum Beispiel: „Der Computer
stellt bereit" oder „Das Programm stellt
bereit” werden
im Folgenden verwendet, um Aktivitäten eines oder mehrerer Netzwerkknoten
auszudrücken,
der/die von dem CPP gemäß der Erfindung gesteuert
ist/sind.
-
Der
Programmträger 170 ist
als außerhalb der
Netzwerk-Komponente 100 vorgesehen dargestellt. Um das
CPP der Netzwerk-Komponente 100 zu übermitteln, wird der Programmträger 170 zweckmäßigerweise
in das Eingabegerät 140 eingelegt. Der
Träger 170 ist
als ein beliebiges computerlesbares Medium implementiert. Allgemein
ist der Programmträger 170 ein
fabrikmäßig hergestellter
Artikel, der ein computerlesbares Medium umfasst, welches darauf
verkörperte
computerlesbare Programmcodemittel zum Ausführen des Verfahrens der vorliegenden
Erfindung aufweist. Ferner können auch
die Programmsignale 180 das CPP verkörpern. Die Signale 180 laufen
auf dem Computernetzwerk 190 von und zu der Netzwerk-Komponente 100.
Die Schritte des Computerprogrammprodukts (CPP) können ausschließlich in
der Netzwerk-Komponente 100 ausgeführt werden, im welchem Fall
das Computernetzwerk 190 weggelassen werden kann, oder können auf
eine verteilte Weise auf einer oder mehrerer der Komponenten des
Computernetzwerks 190 ausgeführt werden.
-
Der
Bus 130 und das Computernetzwerk 190 stellen logische
und physische Verbindungen bereit, indem sie Anweisungen und Datensignale
befördern. Während Verbindungen
und Kommunikationen innerhalb der Netzwerk-Komponente 100 zweckmäßigerweise
von dem Bus 130 abgewickelt werden, werden Verbindungen
und Kommunikationen zwischen unterschiedlichen Netzwerk-Komponenten
durch das Netzwerk 190 abgewickelt. Optional umfasst das Netzwerk 190 Gateways
und Router, die dediziert programmierte Computer sind, um Datenübermittlung
und Protokollumsetzung zu bewirken. Die Eingabe-/Ausgabe-Geräte 140 und 150 sind
mit der Netzwerk-Komponente 100 durch den Bus 130 (wie dargestellt)
oder durch das Netzwerk 190 (optional) verbunden. Während die
Signale innerhalb der Netzwerk-Komponente 100 hauptsächlich elektrische
Signale sein können,
können
die Signale in dem Netzwerk elektrische, magnetische, optische oder
drahtlose (Funk-)Signale sein.
-
Das
Netzwerk 190 kann eine oder mehrere büro-weite Computer-Netzwerke
enthalten, ein firmen-weites Computer-Netzwerk, ein Intranet oder das
Internet (d. h. das World Wide Web). Das World Wide Web (WWW) repräsentiert
all die Computer im Internet, die Benutzern mittels interaktiver
Dokumente oder Web-Seiten Zugriff auf Internet-Informationen anbieten.
Web-Informationen befindet sich auf Web-Servern im Internet oder
innerhalb von Firmen- oder Community-Netzwerken (Intranets). Das
Netzwerk 190 kann ein kabelgebundenes oder kabelloses Netzwerk
enthalten, wie beispielsweise ein lokales Netzwerk (LAN), ein Weitverkehrsnetz
(WAN), ein drahtloses LAN (WLAN), ein öffentliches, vermitteltes Telefonnetzwerk
(PSTN), ein Integrated Services Digital Network (ISDN), eine Infrarot-(IR)
oder Bluetooth-Verbindung, eine Funkverbindung, beispielsweise nach
dem Universal Mobile Telecommunications System (UMTS), dem globalen
System für
mobile Kommunikation (GSM), einem Code Division Multiple Access(CDMA)-System,
oder eine Satellitenverbindung.
-
Übermittlungs-Protokolle,
-Mechanismen und -Datenformate zur Realisierung von Kommunikation
zwischen Netzwerk-Komponenten, die mit dem und durch das Netzwerk 190 verbunden
sind, sind beispielsweise bekannt als Transmission Control Protocol/Internet
Protocol (TCP/IP), Hypertext Transfer Protocol (HTTP), Secure HTTP,
Wireless Application Protocol (WAP), Unique Resource Locator (URL),
Unique Resource Identifier (URI), Hypertext Markup Language (HTML),
Extensible Markup Language (XML), Extensible Hypertext Markup Language
(XHTML), Wireless Application Markup Language (WML), Electronic
Data Interchange (EDI), bei dem es sich um einen elektronischen
Austausch von Geschäftsinformationen
in einem strukturierten Format zwischen oder innerhalb von Organisationen
und ihrer Informationstechnologie(IT-)Infrastruktur handelt, Remote
Function Call (RFC) oder mittels einer Anwendungsprogramm-Schnittstelle
(API) etc..
-
Schnittstellen,
welche zwischen einzelne Elemente und Komponenten gekoppelt sind,
sind ebenfalls wohlbekannt in der einschlägigen Technik. Zur Vereinfachung
sind Schnittstellen nicht dargestellt. Eine Schnittstelle kann beispielsweise
ein Port einer seriellen Schnittstelle, ein Port einer parallelen Schnittstelle,
ein Game-Port, eine Universal Serial Bus(USB)-Schnittstelle, ein
internes oder externes Modem, ein Videoadapter oder eine Soundkarte
sein.
-
Das
CPP nach der vorliegenden Erfindung kann Teil eines komplexen, in
eine Hardware-Anordnung eingebetteten Software-Systems sein. Das
Zusammenwirken des Software-Systems mit der Hardware-Anordnung wird
manchmal als IT-Backbone-System
bezeichnet. Das Backbone-System kann eine geschichtete Anordnung
mit einzelnen Software-Komponenten sein, die nach dem Client-Server-Konzept
als Dienstanbieter, Dienstanforderer oder beides agieren. Beispielsweise
kann eine Anwendungssoftware Software-Komponenten enthalten, die
Präsentationsdienste
bereitstellen, und als Server agieren. Gleichzeitig kann die Anwendungssoftware
jedoch auch als Dienstanforderer von Datenbankdiensten agieren,
die von einer tiefer gelegenen Schicht bereitgestellt werden. Die
geschichteten Komponenten können
miteinander mittels vordefinierter (Hardware- und Software-)Schnittstellen kommunizieren.
-
Was
eine mögliche
Implementierung einer geschichteten Software-Anordnung betrifft,
kann eine untere Schicht netzwerkbezogene Funktionalitäten enthalten,
eine physische Datenbank und ein Betriebssystem für die Netzwerk-Komponenten.
Eine mittlere Schicht, die eine Schnittstelle mit der unteren Schicht
bildet, integriert Software-Anwendungen in der oberen Schicht über ihr.
Diese mittlere Schicht kann Komponenten wie Software-Werkzeuge,
Systemadministrations-Werkzeuge, Datenabwicklungs-Werkzeuge, Autorisierungs-
und Sicherheits-Verwaltungs-Werkzeuge,
anwendungsübergreifende
Module und einen System-Kernel enthalten. Der System-Kernel kann
Kommunikations- und Anwendungsprogramm-Schnittstellen verwenden, um
auf Komponenten wie Anwendungssoftware in der oberen Schicht oder
das Betriebssystem, die Datenbank und das Netzwerk in der unteren
Schicht zuzugreifen. Dieser System-Kernel kann unabhängig von
den Anwendungen betrieben werden und ist „unter" der Anwendungssoftware und den Datenschichten
des Software-Systems angeordnet. Die obere Schicht enthält die unterschiedlichen
Software-Anwendungen zum Steuern und Überwachen von Prozessen, die
sich beispielsweise auf die Verwaltung von Personal, Verkauf und
Distribution, Finanzen, Materialien, Herstellung, elektronisches
Beschaffungswesen etc. beziehen.
-
Eine
mögliche
Client-/Server-Konfiguration, in der die vorliegende Erfindung ausgeführt werden kann,
ist eine sogenannte mehrstufige bzw. Multi-Tier-Netzwerk-Architektur, welche
die Komponenten eines Netzwerksystems in einzelne funktionale Gruppen,
wie Darstellung (bzw. Präsentation),
Kommunikation, Anwendung und Datenbank, unterteilt. Dies ist in 2 in
einer hardware-bezogenen Ansicht dargestellt. Wie in 2 zu
sehen ist, umfasst die mehrstufige Architektur einen oder mehrere
Datenbank-Server 10, einen oder mehrere Anwendungs-Server 12 und einen
oder mehrere Darstellungs-Server 14. Kommunikation zwischen
den Schichten kann beispielsweise unter Verwendung der oben erwähnten Standard-Protokolldienste
erzielt werden, wie zum Beispiel derjenigen, die durch TCP-IP oder
CPIC bereitgestellt sind. CPIC steht für Common Programming Interface
Communication und enthält
Standardfunktionen und Dienste für
die Kommunikation von einem Programm zum anderen.
-
Mit
der in 2 gezeigten mehrschichtigen Architektur kann jede
Hardware-Gruppe aufgesetzt werden, um Anforderungen seiner Funktionen
zu unterstützen.
Der eine oder die mehreren Datenbank-Server 10 enthalten
die Datenquellen. Anwendungs-Server 12,
die zu den Datenbank-Servern 10 eine Schnittstelle aufweisen,
enthalten die Hauptverarbeitungslogik bezüglich des Nachrichtenaustauschs
und der bestimmten durchzuführenden
kollaborativen Anwendung. Die Aufgaben, die sich auf Datendarstellung
beziehen, werden von den Darstellungs-Servern 14 abgewickelt,
welche typischerweise Personal Computer oder Arbeitsstationen sein können. Externe
Darstellungs-Server 14 können mittels des Internets
und Web-Servern/Internet-Transaktions-Servern 16 mit
den Anwendungs-Servern 12 verbunden sein. Sowohl die externen
als auch die internen Darstellungs-Server 14 sind Teilnehmer
einer kollaborativen Sitzung, die von der kollaborativen Anwendung
gesteuert werden, die auf den Anwendungs-Servern 12 abläuft. Im
vorliegenden Fall können
die Darstellungs-Server 14 als Datenquellen, Nachrichtenempfänger oder
beides fungieren.
-
Im
Folgenden wird eine Ausführungsform der
Erfindung mit Bezug auf eine kollaborative Anwendung in Form einer
elektronischen Online-Auktion beschrieben. Natürlich können die Prinzipien der vorliegenden
Erfindung auch in Verbindung mit anderen kollaborativen Anwendungen,
wie dem Abhalten elektronischer Konferenzen, dem elektronischen
Online-Chatting und Ähnlichem
praktiziert werden.
-
Elektrische
Online- (oder Live-)Auktionen werden verwendet, um eine Echtzeit-Umgebung zu erstellen,
die einerseits einen von einem Verkäufer (konventionelle Auktion)
oder von einem Käufer
(umgekehrte Auktion) betriebenen Darstellungs-Server und andererseits eine Vielzahl
von Darstellungs-Servern, die von den einzelnen Bietern betrieben
wird, enthält.
Solche kollaborativen Netzwerk-Communities bestehen über einen
bestimmten, üblicherweise vordefinierten
Zeitraum. Häufig
wird eine Vielzahl von einzelnen Auktionen (auch Sitzungen genannt) gleichzeitig
durchgeführt.
Dementsprechend kann jeder Teilnehmer gleichzeitig an zwei oder
mehr Sitzungen teilnehmen.
-
Vom
Standpunkt eines von einem Bieter betriebenen Darstellungs-Servers
aus beginnt eine Sitzung mit einer Sitzungsanmeldung und endet mit
einer Sitzungsabmeldung. Zwischen der Sitzungsanmeldung und der
Sitzungsabmeldung werden Daten, die sich beispielsweise auf Gebote
oder Chat-Nachrichten beziehen, eingereicht und zugeordnete Nachrichten,
wie Gebotsbestätigungen
oder Gebotsinformationen über
von anderen Bietern eingereichte Gebote, werden empfangen.
-
Eine
beispielhafte mehrstufige Netzwerkarchitektur zur Steuerung einer
Nachrichtenübermittlung
in einer elektronischen Online-Auktion ist in 3 in
einer softwarebezogenen Ansicht gezeigt. Aus 3 wird klar,
dass die mehrstufige Netzwerkarchitektur vier verschiedene Schichten
umfasst und dass zwei einzelne Software-Komponenten die unterschiedlichen Schichten
umspannen und zu einem großen
Teil unabhängig
voneinander ablaufen. Die verschiedenen Schichten enthalten eine
Datenbank- (oder Persistenz-)Schicht 10 als unterste Schicht,
einer Anwendungsschicht 12, die zu der Datenbankschicht 10 eine
Schnittstelle aufweist, eine Kommunikations-/Web-Schicht 16 über der
Anwendungsschicht 12 und eine Darstellungsschicht (oder ein
Browser) 14 als oberste Schicht auf der Kommunikations-/Web-Schicht 16.
Natürlich
könnte
die Erfindung auch mit weniger oder mehr Software-Schichten praktiziert
werden. Beispielsweise können
die Datenbankschicht 10 und die Anwendungsschicht 12 in
einer einzigen Schicht kombiniert werden.
-
Was
die einzelnen Software-Komponenten betrifft, enthält die vorliegende
Ausführungsform
sowohl eine Echtzeit-Nachrichtenaustausch-Komponente 20 als
auch eine kollaborative Anwendungskomponente 22. Die Echtzeit-Nachrichten-austausch-Komponente 20 umspannt
die Datenbankschicht 10, die Anwendungsschicht 12,
die Kommunikations-/Web-Schicht 16 und die Darstellungsschicht 14,
während
die Anwendungskomponente 22 in der vorliegenden Ausführungsform
nur die Datenbankschicht 10 und die Anwendungsschicht 12 umspannt.
Obwohl in der vorliegenden Ausführungsform
die Echtzeit-Nachrichtenaustausch-Komponente 20 und die
Anwendungskomponente 22 als zwei einzelne Komponenten beschrieben
sind, die zueinander eine Schnittstelle aufweisen, können sie
auch in einer einzelnen Komponente kombiniert werden.
-
Die
Echtzeit-Nachrichtenaustausch-Komponente 20 enthält eine
Vielzahl von Teil-Komponenten, die
auf verschiedenen Servern der kollaborativen Netzwerkumgebung ablaufen.
Insbesondere enthält die
Echtzeit-Nachrichtenaustausch-Komponente 20 eine Vielzahl
von Darstellungs-Teilkomponenten 24, die auf verteilten
Darstellungs-Servern
ablaufen, eine Kommunikations-Teilkomponente 26, die auf
einem Web- Server/Internettransaktions-Server
abläuft,
eine Anwendungs-Teilkomponente 28, die auf einem Anwendungs-Server
abläuft,
sowie eine Datenbank-Teilkomponente 30, die auf einem oder
mehreren Datenbank-Servern abläuft.
Vom Standpunkt der Echtzeit-Nachrichtenaustausch-Komponente 20 agieren
die verteilten Darstellungs-Teilkomponenten 24 als
Clients, die von den Anwendungs-Teilkomponenten 28 bedient
werden. Daher werden die Darstellungs-Teilkomponenten 24 im
Folgenden auch als Clients bezeichnet, und die Anwendungs-Teilkomponente 28 wird
auch als Server bezeichnet.
-
Die
verschiedenen Darstellungs-Teilkomponenten 24 enthalten
jeweils eine Benutzerschnittstelle 32, die unten mit Bezug
auf die 8 und 9 detaillierter
beschrieben wird, sowie einen Nachrichtenaustausch-Client 34.
Der Nachrichtenaustausch-Client 34 ermöglicht es
den verteilten, von dem Käufer/Verkäufer und
den Bietern betriebenen verteilten Computern, Daten in Form neuer
Gebote oder Chat-Nachrichten
an die Anwendungskomponente 22 einzureichen und Nachrichten
von der Nachrichtenaustausch-Komponente 20 abzurufen. Der
Nachrichtenaustausch-Client 34 kann
beispielsweise als ein Java-Applet konfiguriert sein und kann auf
einen Benutzer und seine Rolle als Bieter oder Käufer/Verkäufer abgebildet sein.
-
Die
Kommunikations-Teilkomponente 26 der Echtzeit-Nachrichtenaustausch-Komponente 20 enthält eine
Benutzerverwaltung 36 zum Authentifizieren des Benutzers
und zum Durchsetzen einer Single Sign On-Strategie, sowie einen
Nachrichtenaustausch-Server 38. Die Hauptaufgabe des Nachrichten-Servers 38 ist
es, die passende Backend-Schnittstelle der Anwendungs-Teilkomponente 28 in
der Anwendungsschicht 12 aufzurufen. Die verschiedenen Funktionalitäten der
Anwendungs-Teilkomponente 28 werden
unten detaillierter beschrieben.
-
Die
Datenbank-Teilkomponente 30 der Nachrichtenaustausch-Komponente 20 enthält eine oder
mehrere Datenbanken, welche sich auf Aufgaben der Clientregistrierung,
der Datenobjekt-Registrierung und der Einreihung von Nachrichten
in eine Warteschlange beziehen. In der vorliegenden Ausführungsform
enthält
die Datenbank-Teilkomponente 30 drei
Hauptdatenbanktabellen 40, 42, 44, welche sich
aufeinander beziehen, wie in der oberen Hälfte von 4 gezeigt
ist. Insbesondere sind eine Client-Registrierungstabelle 40,
eine Datenobjekt-Registrierungstabelle 42 und eine Nachrichten-Einreihungstabelle 44 bereitgestellt.
-
Die
Client-Registrierungstabelle 40 weist ein Schlüsselfeld
auf, welches sich auf einen Client-Identifikator bezieht. Der Client-Identifikator
ist ein eindeutiger Identifikator, welcher einem bestimmten Client
zugewiesen ist, während
der Client angemeldet ist. Jeder Client kann auf einen bestimmten
Benutzer und einen vom Client während
des Anmeldens empfangenen Benutzer-Identifikator abgebildet werden. Die
Client-Registrierungstabelle 40 enthält ferner
Datenfelder, die sich auf den Verbindungsstatus eines einzelnen
Clients, den Client-Typ (beispielsweise Bieter, Käufer oder
Verkäufer),
eine Client-Nachrichten-Sequenznummer (z. B. 1 für die erste von dem Client
empfangene Nachricht) sowie einen Zeitstempel beziehen.
-
Die
Datenobjekt-Registrierungstabelle 42 weist ein Schlüsselfeld
auf, welches sich auf einen Registrierungs-Identifikator bezieht.
Der Registrierungs-Identifikator ist eine fortlaufende, zugewiesene Nummer,
welche auf eine einzige Zuweisung zwischen einem bestimmten Client
und einem bestimmten Datenobjekt hinweist. In der vorliegenden Ausführungsform
wird ein datenobjektorientierter Ansatz zum Ablegen von sich auf
eine bestimmte Sitzung (z. B. Auktion) beziehenden Inhaltsdaten
verfolgt. Verschiedene Typen (oder Klassen) von Datenobjekten können für eine bestimmte
Sitzung definiert sein. Im Auktionsumfeld sind einzelne Datenobjekttypen
für Auktionen,
Gebotslisten und Chat-Nachrichten definiert.
-
Die
Datenobjekt-Registrierungstabelle 42 wird verwendet, um
die einzelnen Beziehungen zwischen Clients (Client-Identifikator)
und Datenobjekten wie Auktionen (ein Client kann eine oder mehrere Auktionen
abonnieren) abzulegen. Eine (1) Datenobjekt-Registrierung
wird für
jede Auktion durchgeführt, der
ein Client zugewiesen ist.
-
Die
Nachrichten-Warteschlangentabelle 44 weist ein Schlüsselfeld
auf, welches sich auf einen eindeutigen Nachrichten-Identifikator
bezieht. Zusätzlich
wird für
jede eingereihte Nachricht der Empfänger-Client-Identifikator für Adressierungszwecke abgelegt.
Die Nachrichten-Warteschlangentabelle 44 enthält ferner
einen Verweis auf Inhaltsdaten, die in eine bestimmte Nachricht
einzufügen
sind, die vor der Nachrichtenübermittlung
aus der Nachrichten-Warteschlange gelesen wurde. Dies bedeutet, dass,
im Unterschied zu konventionellen Nachrichtensystemen, die Nachrichteninhalte
nicht innerhalb der Nachrichten-Warteschlange abgelegt sind. Die eingereihten
Nachrichten, die in der Nachrichten-Warteschlange abgelegt sind,
können
daher als „inhaltslos" betrachtet werden.
Stattdessen ist ein Verweis auf ein bestimmtes Datenobjekt „Datenobjek-Identifikator" sowie eine Nachrichtentypinformation,
die angibt, welcher Informationsteil des identifizierten Datenobjekts
in die bestimmte Nachricht eingefügt werden soll, für jede in
die Warteschlange eingereihte Nachricht abzulegen. Die Nachrichten-Warteschlangentabelle 44 enthält eine
Vielzahl weiterer Datenfelder, die unten im Zusammenhang mit dem Schreiben
von Informationen in die Nachrichten-Warteschlangentabelle und dem
Lesen eingereihter Nachrichten beschrieben wird.
-
Wie
aus oben Gesagtem ersichtlich wurde, werden die Nachrichten nicht
innerhalb einer Nachrichten-Warteschlange in Form einer langen Zeichenkette
oder eines XML-Dokuments
abgelegt. Stattdessen wird eine schlanke Nachrichten-Warteschlange verwendet,
in welcher die eingereihten Nachrichten einen Link auf in einem
bestimmten Datenobjekt oder einem Teil davon enthaltene Inhaltsdaten
enthält. Eine
solche schlanke Nachrichten-Warteschlange hat enorme Vorzüge in der
Leistungsfähigkeit,
insbesondere dann, wenn das Volumen der in die eingereihten Nachrichten
einzufügenden
Inhaltsdaten stark variiert. Ein Datenobjekt kann in viele Tabellen strukturiert
sein (Kopfzeile, Betreff, Text, Anhänge etc.) und kann daher eine
bis viele tausend oder Millionen Datenzeilen, Datenfelder oder Einzelposten enhalten.
Dementsprechend kann die Größe einer einzelnen
Nachricht typischerweise zwischen einem Kilobyte und vielen Gigabyte
variieren. Die Nachrichten-Warteschlange muss prinzipiell in der
Lage sein, sowohl die kleinste als auch die größte mögliche Datenobjektgröße abzuwickeln.
Solche Größenvariationen
führen
zu Abwicklungsproblemen, falls die gesamte Nachricht in die Warteschlange
eingereiht wird. Indem eine schlanke Nachrichten-Warteschlange implementiert
wird, die nur einen Verweis auf Inhaltsdaten speichert, wird das
Abwickeln von Nachrichten im Vergleich zu konventionellen Nachrichten-Warteschlangen
bis zu 200 Mal schneller. Dieser Zugewinn an Leistungsfähigkeit
ist insbesondere vorteilhaft im Umfeld von kollaborativen Echtzeit-Anwendungen, wie
elektronischen Online-Auktionen.
-
Gleichzeitig,
und im Gegensatz zu einfachen Rundrufmechanismen, lässt die
Nachrichten-Warteschlange eine vergleichsweise einfache Implementierung
von Client-Adressierungs-Mechanismen
zu. Daher können
Client-spezifische Nachrichten, das heißt, Nachrichten mit einem Client-spezifischen
Inhalt, auf einfache Weise verwaltet werden. Dies lässt es zu,
an jede Systemnachricht eine zugehörige Client-spezifische Nachricht
anzuhängen.
Wenn zum Beispiel ein Client ein neues Gebot für eine bestimmte Auktion einreicht,
empfängt
er eine Systemnachricht mit dem aktualisierten Preis und Ranginformationen
(welche auch an die anderen an der elektronischen Online-Auktion
teilnehmenden Client übermittelt
wird) und empfängt
zusätzlich
eine Client-spezifische Nachricht, welche den Erhalt des neuen Gebotes
bestätigt.
-
Nachdem
die Datenbanken-Teilkomponente 30 der Nachrichtenaustausch-Komponente 20 beschrieben
wurde, wird jetzt Bezug genommen auf die in 3 gezeigte
Anwendungskomponente 22. Wie aus 3 ersichtlich
ist, überspannt
in der vorliegenden Ausführungsform
die Anwendungskomponente 22 die Anwendungsschicht 12 und
die Datenbankschicht 10. Die Anwendungskomponente 22 enthält eine
Teilkomponente 44 auf der Anwendungsschicht 12,
welche hauptsächlich
die auktionsbezogene Geschäftslogik
enthält,
sowie eine Inhaltsdatenbank 48, welche zur Datenbankschicht 10 gehört.
-
Die
Struktur der Inhaltsdatenbank 48 ist auf der unteren Hälfte von 4 detaillierter
gezeigt. Wie man sehen kann, ist die Inhaltsdatenbank 48 als
eine relationale Datenbank konfiguriert, die eine Vielzahl von zugewiesenen
Tabellen enthält.
Insbesondere enthält
die Inhaltsdatenbank 48 eine Auktions-Kopfzeilentabelle 50,
eine Auktions-Postentabelle 52, eine Bietertabelle 54 sowie
eine Gebotshistorientabelle 56. Die Inhaltsdatenbank 48 dient
dazu, Datenobjekte abzulegen, die von Datenobjektklassen, wie Auktion,
Gebotshistorie, Chat etc. abgeleitet sind.
-
Im
Folgenden werden verschiedene Nachrichtenaustausch-Szenarien und
die darin involvierten Bestandteile der Nachrichtenaustausch-Komponente 20 beispielhaft
beschrieben. Die Nachrichtenaustausch-Szenarien beziehen sich auf
den Nachrichtenaustausch beim Anmelden (3), auf
das Empfangen von neuen Nachrichten eines Clients (5),
auf das Empfangen von eingereihten Nachrichten (6)
und den Nachrichtenaustausch beim Abmelden (7).
-
Nun
wird Bezug genommen auf 3, welche eine Anmeldungsprozedur
veranschaulicht. Während
des Anmeldens wird ein Benutzer authentifiziert, ein neuer Client-Identifikator
wird erstellt und der neu erstellte Client-Identifikator wird in
der Client-Registrierungstabelle 40 eingetragen. Dann werden
spezifische Auktionsdaten ausgewählt
und eine entsprechende Nachricht, welche die Auktionsdaten enthält, wird
direkt (das heißt,
ohne Verwenden der Nachrichten-Warteschlange) an den Client gesendet.
-
Die
Anmeldeprozedur beginnt mit einem Universal Ressource Locator (URL),
der einen bestimmten Auktions-Identifikator und möglicherweise
einen Benutzer-Identifikator
enthält.
Aus diesen Informationen erstellt der Nachrichtenaustausch-Client 34 eine Anmeldenachricht,
die den Benutzer-Identifikator, den Auktions-Identifikator, der für die Auktion charakteristisch
ist, für
die eine Anmeldung angefordert wird, einen Zeitstempel und eine
Client-Nachrichten-Sequenznummer umfasst. Die Client-Nachrichten-Sequenznummer
ist eine fortlaufend zugewiesene Nummer, die in der Nachricht enthalten
ist, die von dem Nachrichtenaustausch- Client 34 versendet wird. Da
die Anmeldenachricht die erste Nachricht ist, erhält sie die
Client-Nachrichten-Sequenznummer 1.
-
In
Schritt 1 wird die vom Nachrichtenaustausch-Client 34 erstellte
Anmeldungsnachricht mittels des Hypertext Transfer Protocol (HTTP)
an die Kommunikations-Teilkomponente 26 versandt.
Die Benutzerverwaltung 36 authentifiziert den Benutzer und
stellt sicher, dass das Single Sign On funktioniert. Wenn der Benutzer
gültig
ist, so wird die Anmeldenachricht an den Nachrichtenaustausch-Server 38 weitergeleitet
(Schritt 2).
-
Der
Nachrichten-Server 38 identifiziert den Nachrichteninhalt
(Anmeldenachricht) und ruft die passende Backend-Schnittstelle der
Anwendungs-Teilkomponente 28 auf. Im vorliegenden Fall ist
dies die Schnittstelle für
eingehende Anmeldungen 60 (Schritt 3).
-
Von
der Schnittstelle für
eingehende Anmeldungen 60 wird die Anmeldenachricht an
eine Client-Registrierungseinheit 62 weitergeleitet (Schritt 4).
Die Client-Registrierungseinheit 62 weist
dem Client einen eindeutigen Client-Identifikator zu. Dieser Client-Identifikator
bleibt zugewiesen, bis sich der bestimmte Client wieder abmeldet.
-
In
Schritt 5 werden der neu zugewiesene Client-Identifikator,
der in der Anmeldenachricht enthaltene Client-Identifikator, der
von der Client-Registrierungseinheit 62 bestimmte Client-Typ
(beispielsweise Bieter oder Käufer),
die Client-Nachrichten-Sequenznummer
(1 für
die Anmeldenachricht) und der in der Anmeldenachricht enthaltene
Zeitstempel in der Datenbanktabelle 40, das heißt, in die
Client-Registrierungstabelle,
die oben im Zusammenhang mit 4 beschrieben
wurde, eingetragen.
-
In
Schritt 6 wird der Link zwischen dem bestimmten, eine Anmeldung
anfordernden Client und dem Datenobjekt (wie eine bestimmte umgekehrte Auktion),
für welche
eine Anmeldung angefordert wird, bestätigt. Dann wird die Beziehung
zwischen einem Client, einem bestimmten Datenobjekt-Identifikator
(z. B. eine eindeutige Zahl) und dem Datenobjekttyp (Auktion) in
der Datenobjekt-Registrierungstabelle 42 eingetragen (Schritt 7).
Zusätzlich
werden alle für
die bestimmte Auktion derzeitig angemeldeten Clients (Client-Identifikator)
mittels der zugeordneten, in der Datenobjekt-Registrierungstabelle 42 enthaltenen
Verknüpfungsinformation
ausgewählt.
-
In
Schritt 8 wird eine Nachricht für jeden angemeldeten Client
erstellt. Die Nachricht, die erstellt wird, ist eine generische
und standardisierte Systemnachricht, welche alle derzeit teilnehmenden
Clients benachrichtigt, dass ein neuer Client online ist. Somit entspricht
die Anzahl neu generierter Nachrichten der Anzahl Clients, die vor
dem Anmelden des neuen Clients mit der bestimmten Auktion verknüpft waren. Für jede Nachricht
wird ein neuer Nachrichten-Identifikator erstellt und mit den einzelnen,
in Schritt 7 bestimmten Identifikatoren der empfangenden
Clients verknüpft.
-
Für jede neu
erstellte Nachricht werden die Datenfelder der in 4 gezeigten
Nachrichten-Warteschlangentabelle 44 wie folgt ausgefüllt. Der
Datenobjekt-Identifikator wird auf den Auktions-Identifikator gesetzt.
Die Nachrichtenart wird auf „Anmeldenachricht" gesetzt, der Informationstyp
wird auf „Auktion" gesetzt, der Informations-Identifikator wird
auf „Informationsnachricht" gesetzt, die Informationszahl verweist
auf einen internationalisierten Text mit dem Inhalt „X ist
Auktion Y beigetreten",
die Informationsvariablen 1 und 2 werden auf X und Y gesetzt. Zusätzlich wird
eine Servernachrichten-Sequenznummer der letzten Nachricht an einen
bestimmten Nachrichtenempfänger
bestimmt, um eins erhöht
und in dem passenden Datenfeld abgelegt, die Rangnummer verbleibt
auf ihrem ursprünglichen
Wert (weil nur eine Nachricht abgelegt ist) und der Zeitstempel
wird auf die aktuelle Zeit des Datenbank-Servers gesetzt. In Schritt 9 werden
die neu erstellten Nachrichten in der Nachrichten-Warteschlangentabelle
gespeichert.
-
Die
Einträge
der in der Nachrichten-Warteschlangentabelle enthaltenen Spalten
Informationstyp, Informations-Identifikator, Informationsnummer etc.
können
als Verweise auf in einer Nachrichten-Datenbank auf einem getrennten
System (nicht gezeigt) der Datenbanken-Teilschicht 30 abgelegte Systemdaten
betrachtet werden. Während
die Inhaltsdaten also durch die Anwendungskomponente 22 gespeichert
und verwaltet werden, werden die Systemdaten von der Nachrichtenaustausch-Komponente 20 gespeichert
und verwaltet.
-
In
Schritt 10 fordert die Anwendungs-Teilkomponente 28 bestimmte
Inhaltsdaten (Auktionsdaten) von der Anwendungskomponente 22 durch
Aufrufen einer passenden Schnittstelle in der Anwendungsschicht 12 an.
In Schritt 11 wird die Anforderung an die Anwendungskomponente übergeben, und
in Schritt 12 werden die angeforderten Daten gesammelt,
das heißt,
aus den einzelnen, mit den bestimmten Datenobjekten (Auktion) verknüpften Datenbanktabellen
ausgewählt.
-
In
Schritt 13 werden die Auktionsdaten dann an eine Schnittstelle
für ausgehende
Anmeldungen 64 weitergeleitet. Die Schnittstelle für ausgehende Anmeldungen 64 verpackt
die Auktionsdaten neu und sendet sie an den Nachrichten-Server 38 in
der Kommunikations-/Web-Schicht 16 (Schritt 14).
Der Nachrichten-Server 38 verpackt die Daten wieder neu
und sendet eine entsprechende Nachricht an den Client, der die Anmeldung
angefordert hat. Dort werden die gesamten Auktionsdaten schließlich auf einer
grafischen Benutzerschnittstelle angezeigt, wie noch mit Bezug auf 8 erklärt werden
wird.
-
Im
Folgenden wird die Prozedur des Einreichens neuer Nachrichten mit
Bezug auf 5 erklärt. Eine neue Nachricht kann
durch den Client (z. B. ein neues Gebot oder eine Chat-Nachricht)
oder innerhalb des Nachrichtenaustausch-Servers (z. B. eine Nachricht,
die angibt, dass ein Auktionsstatus geändert wurde) erstellt werden.
Falls eine neue Nachricht vom Client empfangen wird, werden die
darin enthaltenen Daten verwendet, um die Inhaltsdatenbanken 48,
und insbesondere die zugeordneten Datenbankentabellen, zu aktualisieren.
Zum Beispiel wird ein neues Gebot in der Gebotshistorientabelle
gespeichert, während
eine Chat-Nachricht in einer Chat-Historientabelle gespeichert wird.
-
Die
Nachrichtenaustausch-Komponente bestimmt alle Clients, die online
sind und die das entsprechende Datenobjekt (z. B. Auktion oder Chat) abonniert
haben, und legt einen Verweis, wie z. B. einen Gebots-Identifikator
und einen Empfangender-Client-Identifikator
des oder der Clients, die davon zu unterrichten sind, in der Nachrichten-Warteschlangentabelle 44 ab.
Wie oben bereits angedeutet wurde, wird für jeden Nachrichtentyp eine
eindeutige Schnittstelle bereitgestellt. Zum Empfangen eines eingereichten
Gebotes und einer eingereichten Chat-Nachricht werden beispielsweise
zwei unterschiedliche Schnittstellen benutzt, und zwei unterschiedliche
Datenbankentabellen werden aktualisiert.
-
Im
Folgenden wird das Einreichen einer Nachricht, welche Daten bezüglich eines
neuen Gebots enthält,
mit Bezug auf 5 beschrieben.
-
Die
Schritte 1 und 2 sind identisch mit den oben im
Zusammenhang mit der Anmeldenachricht beschriebenen Schritten. In
Schritt 3 identifiziert der Nachrichten-Server 38 die
neu empfangene Nachricht als eine eingereichte Gebotsnachricht und
ruft eine Schnittstelle für
eingehende Gebote 66 der Anwendungs-Teilkomponente 28 auf.
In den Schritten 4 und 5 wird der Client-Identifikator
bezüglich
seines Datensatzes validiert, und der Zeitstempel in der Client-Registrierungstabelle
wird aktualisiert. In Schritt 6 werden alle Clients ausgewählt, die
derzeit für
die bestimmte Auktion angemeldet sind.
-
In
Schritt 7 wird das Gebot mittels einer spezifischen Geschäftslogik
validiert. Falls das Gebot zurückgewiesen
wird, erhält
der einreichende Client sofort eine Gebotszurückweisungsnachricht. Andernfalls
erhält
der einreichende Client eine Gebotsannahmenachricht. In diesem Fall
werden alle in Schritt 6 bestimmten Clients über das
neu abgegebene gültige
Gebot informiert. Das bedeutet, dass in Schritt 8 für diese
Clients entsprechende Nachrichten erstellt und in der Nachrichten-Warteschlangentabelle
gespeichert werden. Das Datenfeld „Datenobjekt-Identifikation" der Nachrichten-Warteschlangentabelle wird
auf das neue Gebot in der Gebotshistorientabelle gesetzt, falls
das neu eingereichte Gebot gültig
ist.
-
In
Schritt 9 wird eine Schnittstelle aufgerufen, um das neue
Gebot in der Inhaltsdatenbank 46 der Anwendungskomponente 22 abzuspeichern.
In Schritt 10 werden die entsprechenden Tabellen auf die
neu eingereichten Gebote gesetzt, und das neu eingereichte Gebot
wird an die Datenbankschicht 10 gesandt. Das neu eingereichte
Gebot wird dann in der Gebotshistorientabelle 56 (siehe 4)
der Inhaltsdatenbank 46 (Schritt 11) abgespeichert.
-
Parallel
zum Aufrufen der Schnittstelle zum Abspeichern des neu eingereichten
Gebots in der Inhaltsdatenbank 46 (Schritt 9)
wird innerhalb einer Schnittstelle für ausgehende Gebote (68)
eine Logik für
erhaltene Nachrichten aufgerufen (Schritt 12), um den Client,
der das Gebot eingereicht hat, darüber zu informieren, ob das
neu eingereichte Gebot angenommen oder zurückgewiesen wurde. Es sollte
beachtet werden, dass während
Nachrichten, welche die an einer bestimmten Auktion teilnehmenden
Clients über
das neu eingereichte Gebot informieren, in der Nachrichten-Warteschlange eingereiht
werden, die Nachrichten, die den bestimmten Client, der das Gebot
eingereicht hat, über
Annahme oder Zurückweisung
des Gebotes informieren, direkt an diesen Client gesendet werden,
das heißt,
nicht in die Nachrichten-Warteschlange
eingesetzt werden.
-
In
einem folgenden Schritt 13 ruft die Schnittstelle 68 für ausgehende
Gebote den Nachrichten-Server 38 auf. Der Nachrichten-Server 38 verpackt
die empfangenen Daten neu und sendet sie in Schritt 14 an
den bestimmten Client, welcher das Gebot eingereicht hat. Der Client
zeigt dann die Nachricht bezüglich
des angenommenen oder zurückgewiesenen
Gebots als Systemnachricht auf seiner grafischen Benutzer schnittstelle
an, wie im unteren Abschnitt 90 von 8 gezeigt
(„Gebot
erfolgreich eingereicht für
einen Einzelposten...").
-
Während in
der vorliegenden Ausführungsform
also die Nachrichten bezüglich
des angenommenen oder zurückgewiesenen
Gebotes an den Client mit einem sogenannten Push-Modell gesandt werden,
können
die in der Nachrichten-Warteschlange eingereihten Nachrichten von
dem Client gemäß einem
sogenannten Pull-Modell abgerufen werden. Selbstverständlich könnten die
Nachrichten bezüglich
der akzeptierten oder zurückgewiesenen
Gebote auch in der Nachrichten-Warteschlange aufgenommen und von
einem Pull-Mechanismus abgerufen werden. Der Abruf von Nachrichten
aus der Nachrichten-Warteschlange auf den Erhalt einer entsprechenden
Nachrichtenabrufaufforderung von einem Client hin wird nun mit Bezug
auf 6 beschrieben.
-
Die
einzelnen Clients sind konfiguriert, die eingereihten Nachrichten
in regelmäßigen Zeitintervallen
aus der Nachrichtenaustausch-Warteschlange zu ziehen ("Pull"; z. B. alle 1–20 Sekunden).
Zu diesem Zweck ruft ein Client eine dedizierte Schnittstelle auf,
um alle neuen Nachrichten innerhalb der Warteschlange zu bekommen,
welche seinen Client-Identifikator enthalten. Wie oben erklärt wurde,
enthalten die eingereihten Nachrichten nicht den Nachrichteninhalt
selbst, sondern nur einen Verweis auf ein bestimmtes Objekt und
einen Nachrichtentyp. Nachdem alle Nachrichten für einen bestimmten Client aus der
Nachrichten-Warteschlangentabelle ausgewählt wurden, ist daher ein weiterer
Schritt erforderlich, um das referenzierte Datenobjekt, zum Beispiel
die Auktion, das Gebot oder den Chat, zu lesen. Die Größe des Datenobjektes
kann stark variieren. Beispielsweise können Auktionen mehrere hundert
Einzelposten enthalten, während
Gebote üblicherweise
eher klein sind. Dementsprechend wird innerhalb der Anwendungskomponente 22 ein
Mechanismus bereitgestellt, um die Zeit zu optimieren, die erforderlich
ist, um ein Datenobjekt aus der Inhaltsdatenbank 48 in Abhängigkeit
von dem abzurufenden Datenvolumen auszuwählen.
-
Wie
in 6 gezeigt ist, sendet der Nachrichtenaustausch-Client 34 in
regelmäßigen Zeitintervallen
(oder auf eine spezifische Benutzeranforderung hin) Nachrichten-Abrufanforderungen über die Kommunikations-/Web-Schicht 16 an
die Anwendungs-Teilkomponente 28.
Zu diesem Zweck erstellt der Nachrichtenaustausch-Client eine Nachrichten-Abrufanforderung,
welche sowohl die Benutzer- und Client-Identifikatoren, als auch die in der
letzten erhaltenen Nachricht enthaltene Servernachrichten-Sequenznummer
enthält.
Die Nachrichten-Abrufanforderung wird an die Benutzerverwaltung 36 gesandt
(Schritt 1), welcher den Benutzer innerhalb der Kommunikationsschicht 16 authentifiziert.
Im Fall erfolgreicher Authentifikation wird die Nachrichten-Abrufanforderung
an den Nachrichten-Server 38 in Schritt 2 weitergeleitet.
In Schritt 3 ruft der Nachrichten-Server 38 eine
Schnittstelle für
eingehende Abrufe 70 auf. Dann wird der Zeitstempel für den aufrufenden
Client aktualisiert und der neue Zeitstempel wird eingetragen (Schritte 4 und 5).
-
In
den Schritten 6 und 7 wird die Nachrichten-Abrufanforderung
ausgewertet, und alle Nachrichten für den anfordernden Client,
die eine höhere Servernachrichten-Sequenznummer als
die in der Nachrichten-Abrufanforderung enthaltene Servernachrichten-Sequenznummer
aufweisen, werden aus der Nachrichten-Warteschlange gelesen. Die Nachrichten,
die von der Nachrichten-Warteschlange gelesen wurden, verbleiben
in der Nachrichten-Warteschlange, bis die Auktion beendet ist. In
Schritt 7 wird die Server-Nachrichtennummer in der Client-Registrierungstabelle 40 gesetzt.
-
Die
Verwendung der Servernachrichten-Sequenznummer hat zwei Vorteile:
Erstens ermöglicht sie
eine Implementierung eines so genannten Datenaktualisierungsansatzes.
Das bedeutet, dass nicht alle Nachrichten, die für den anfordernden Client in der
Nachrichten-Warteschlange enthalten sind, an den Client übermittelt
werden, sondern nur diejenigen Nachrichten, die eine Servernachrichten-Sequenznummer
haben, die höher
als die in der Nachrichtenabruf-Anforderung enthaltene Servernachrichten-Sequenznummer ist.
-
Zweitens
wird sichergestellt, dass, falls irgendwelche Nachrichten auf dem
Weg zum Client verlorengegangen wären, die verlorenen Nachrichten
als Antwort auf die nächste
Nachrichtenabruf-Anforderung gesendet würden.
-
Die
ausgewählten
Nachrichten werden in Schritt 8 an einen Nachrichten-Zusammensetzer 72 übermittelt,
der die Nachrichten auf der Basis der in den „rohen", von der Nachrichten-Warteschlange
gelesenen Nachrichten erstellt. Weil der Nachrichteninhalt nicht
innerhalb der in der Warteschlange gespeicherten Nachrichten, sondern
in Datenobjekten in der Inhaltsdatenbank 46 enthalten ist,
ruft der Nachrichten-Zusammensetzer 72 eine Schnittstelle
auf, um die Inhaltsdaten abzurufen, auf die in den eingereihten
Nachrichten aus der Inhaltsdatenbank 46 verwiesen wird.
Ein Abrufen von Inhaltsdaten aus der Inhaltsdatenbank 46 involviert
sowohl den Datenobjekt-Identifikator als auch den in einer bestimmten „rohen" Nachricht enthaltenen
Nachrichtentyp, wie oben erklärt
wurde.
-
Falls
zusätzlich
oder als eine Alternative zu den Inhaltsdaten die von der Nachrichten-Warteschlange gelesenen
Nachrichten Systemdaten enthalten, das heißt, falls die Datenfelder für Informationstyp,
Informations-Identifikator, Informationsnummer etc. für eine eingereihte
Nachricht ausgefüllt sind,
ruft der Nachrichten-Zusammensetzer 72 die referenzierten
Systemdaten aus der Systemnachrichten-Datenbank (nicht gezeigt)
in der Datenbank-Teilschicht 30 ab. Die Systemnachrichten
werden in unterschiedlichen Sprachen gespeichert, und der Verweis
auf eine in einer eingereihten Nachricht enthaltene Systemnachricht
zeigt auf die Systemnachricht in der passenden Sprache, die zuvor
in den Benutzereinstellungen eines bestimmten Clients gewählt wurde.
Entsprechende Informationen bezüglich der
Sprache können
von dem Client an die Nachrichtenaustausch-Komponente 20 mit
jeder Nachricht oder während
der Anmeldeprozedur gesendet werden.
-
In
Schritt 9 wird die Anwendungskomponente 22 aufgerufen,
um die Auktion, die Gebotshistorie oder die Chat-Einträge oder
Teile davon (beispielsweise nur einen Einzelposten), der/der den
referenzierten Inhaltsdaten entspricht, auf. Die passenden Inhaltsdaten
werden in Schritt 10 ausgewählt und von den geeigneten
Tabellen der Inhaltsdatenbank 46 empfangen.
-
Der
Nachrichten-Zusammensetzer 72 vervollständigt die eine oder mehreren
Nachrichten aus der Nachrichten-Warteschlange mit den angeforderten
Inhalten und/oder Systemdaten und ruft eine Schnittstelle für ausgehende
Abrufe 74 auf (Schritt 11). Die Schnittstelle
für ausgehende
Abrufe 74 verpackt die empfangenen Daten neu und sendet
sie in Schritt 12 an den Nachrichten-Server 38.
Der Nachrichten-Server 38 verpackt die Daten neu und leitet sie
in Schritt 13 über
HTTP an den anfordernden Client weiter. Der Client aktualisiert
dann seine Benutzerschnittstelle mit den neu empfangenen Daten. Wenn
sich beispielsweise seit der letzten Nachrichtenabruf-Anforderung nur ein
Einzelposten geändert hat,
wird nur dieser Einzelposten aktualisiert.
-
Falls
ein Client eine Auktion verlassen möchte (oder muss), wird eine
Abmeldeprozedur, wie in 7 gezeigt, eingeleitet. Die
Abmeldeprozedur involviert eine dedizierte Abmeldeschnittstelle,
die durch Benutzerinteraktion von dem Client oder durch einen getrennten
Prozess aufgerufen werden kann, der nach einer vorbestimmten Zeitüberschreitung
gestartet wird. Während
der Abmeldeprozedur werden alle Zeilen der in 4 gezeigten
Client-Registrierungstabelle 40, der Datenobjekt-Registrierungstabelle 42 und
der Nachrichten-Warteschlangentabelle 44 für den abgemeldeten
Client gelöscht.
Zusätzlich erhalten
alle anderen Clients, die derzeit für dasselbe Datenobjekt, zum
Beispiel eine Auktion oder eine Chat-Sitzung, registriert sind,
eine neue Nachricht in der Nachrichten-Warteschlange, um sicherzustellen, dass
sie darüber
informiert sind, dass ein Client offline gegangen ist.
-
Die
einzelnen Schritte der Abmeldeprozedur sind in 7 gezeigt.
Die Prozedur beginnt mit der Erstellung einer Abmeldenachricht durch
den Nachrichtenaustausch-Client 34.
Die Abmeldenachricht enthält
den Benutzer, die Auktion und den Client-Identifikator. In Schritt 1 sendet
der Nachrichtenaustausch-Client 34 die Abmeldenachricht
an die Benutzerverwaltung 36, welche den Benutzer validiert. Die
Abmeldenachricht wird dann in Schritt 2 an den Nachrichten-Server 38 weitergeleitet,
welcher eine Schnittstelle für
eingehende Abmeldungen 80 aufruft und die Abmeldenachricht
in Schritt 3 an die Schnittstelle für eingehende Abmeldungen weiterleitet.
Der Client wird dann de-registriert und eine Client-spezifische
Zeile in der Client-Registrierungsdatenbank 40 wird
gelöscht
(Schritte 4 und 5). Weiterhin wird die Client-Datenobjekt-Verknüpfung gelöscht und
die entsprechenden Zeilen in der Datenobjekt-Registrierungstabelle 42 werden
gelöscht
(Schritte 6 und 7).
-
In
Schritt 7 werden alle anderen Clients, die einem bestimmten
Datenobjekt zugewiesen sind, bestimmt, und die entsprechenden Informationen
werden dazu verwendet, um neue Nachrichten für jeden noch verbundenen Client
betreffs des Umstandes, dass sich einer der Clients abgemeldet hat,
erstellt (Schritte 8 und 9). In Schritt 10 wird
eine neue Nachricht, welche ein erfolgreiches Abmelden bestätigt, für den Client,
der eine Abmeldung angefordert hat, erstellt. Die Nachricht wird
in Schritt 11 an eine Schnittstelle für ausgehende Abmeldungen 82 gesendet
und mittels des Nachrichten-Servers 38 an den Client weitergeleitet,
der die Abmeldung angefordert hat (Schritte 12 und 13).
Die Sitzung für
den Client ist beendet.
-
8 zeigt
die grafische Benutzerschnittstelle eines bietenden Clients. Wie
aus 8 ersichtlich ist, enthält die grafische Benutzerschnittstelle
einen ersten Abschnitt 84 zur Darstellung allgemeiner Informationen über eine
bestimmte Auktion, wie den Auktionsnamen, den Auktions-Identifikator
(auch Auktionsnummer genannt), das Auktionsprofil etc.. In einem
weiteren Abschnitt 86 werden die Einzelposten der bestimmten
Auktion dargestellt. In der in 8 dargestellten
Ausführungsform
besteht die Auktion aus zwei Einzelposten. Für jeden der zwei Einzelposten
werden Datenfelder wie „Rang", „mein Gebot", „höchstes Gebot" etc. regelmäßig auf
der Basis von Informationen aktualisiert, die in aus der Nachrichten-Warteschlange
für den
bestimmten Client empfangenen Nachrichten enthalten sind. Ebenfalls
aktualisiert werden die zwei in Abschnitt 88 der grafischen
Benutzerschnittstelle gezeigten grafischen Schaubilder. Im unteren
Abschnitt 90 der grafischen Benutzerschnittstelle werden
Chat- und Systemnachrichten, die aus der Nachrichten-Warteschlange
abgefragt oder mittels eines Push-Mechanismus empfangen wurden,
angezeigt. Die Systemnachrichten betreffen beispielsweise Bestätigungen, dass
einzelne Gebote für
einzelne Einzelposten erfolgreich eingereicht wurden. Zusätzlich erlaubt
es die vorliegende Ausführungsform,
Chat-Nachrichten zwischen den teilnehmenden Clients einzureichen und
zu empfangen.
-
9 zeigt
die grafische Benutzerschnittstelle eines einem Käufer zugewiesenen
Clients. Die grafische Schnittstelle des Käufers ist in weiten Teilen identisch
mit der im Zusammenhang mit 9 beschriebenen
grafischen Benutzerschnittstelle des Bieters. Daher entfällt eine
detaillierte Beschreibung davon.
-
Wie
aus obiger Beschreibung einer bevorzugten Ausführungsform klar wurde, stellt
der Echtzeit-Nachrichtenaustausch-Ansatz eine zuverlässige, sichere
und schnelle Nachrichtenaustausch-Umgebung sicher. Dies wird hauptsächlich durch
die Entkopplung von Datenobjekten von Nachrichten erzielt. Ein weiterer
Vorzug der Erfindung ist der Umstand, dass die sich beispielsweise
auf neue Gebote, Chats etc. beziehenden Nachrichten in einer Datenbank
eingetragen werden und insbesondere in der als „Nachrichten-Warteschlange" bezeichneten Datenbanktabelle.
Dieser Ansatz stellt zusammen mit dem Sicherheitsmechanismus von
Server- und Client-Nachrichten-Sequenznummern
verlässlich
sicher, dass verloren gegangene Nachrichten auf einfache Weise während des
nächsten
Nachrichtenaustausch-Zyklus gesendet werden. Ein weiterer Vorteil der
Client und Servernachrichten-Sequenznummern ist die Tatsache, das
Delta-Nachrichten für
Veränderungen
erstellt werden können,
so dass allgemein kein vollständiges
Aktualisieren erforderlich ist. Dedizierte Schnittstellen innerhalb
der Anwendungs-Teilkomponente 28 ermöglichen es, unnötige Leseoperationen
zu vermeiden und die Client-Implementierung zu entkoppeln. Weiterhin
ermöglichen
die dedizierten Schnittstellen eine Verbindungs-Zusammenlegung zwischen
der Kommunikationsschicht 16 und der Anwendungsschicht 12.
Die Mehrschichten-Architektur sichert eine hohe Skalierbarkeit der
Netzwerkumgebung zu, weil sowohl die Kommunikationsschicht 16 als
auch die Anwendungsschicht 12 auf mehreren physischen Servern
aufgesetzt werden kann.