DE102006060037A1 - Verfahren zur paketorientierten Kommunikation asynchroner Ereignismeldungen - Google Patents

Abstract

Die Erfindung betrifft ein Verfahren zur paketorientierten Kommunikation asynchroner Ereignismeldungen zwischen einem Ereignismeldungskanal (EVTCH) und einem Ereignismeldungsbezieher (CLI). Durch einen erfindungsgemäßen Ereignisagenten (EVTBR) ist dabei eine Registrierung als ereignisbeziehende Instanz am Ereignismeldungskanal (EVTCH), ein Aufbau einer persistenten Transportebenenverbindung mit dem Ereignismeldungsbezieher (CLI) sowie ein Empfang mindestens einer Abonnementanforderung vom Ereignismeldungsbezieher (CLI) und Weitergabe der Abonnenmentanforderung an den Ereignismeldungskanal (EVTCH) vorgesehen. Eine für die Abonnementanforderung eingerichtete Anwendungsebenenverbindung wird dabei gehalten. Bei Auftreten eines abonnierten Ereignisses erfolgt eine Zustellung der mindestens einen Ereignismeldung durch den Ereignisagenten (EVTBR) über die gehaltene Anwendungsebeneverbindung.

Description

• Die Erfindung betrifft ein Verfahren zur Kommunikation asynchroner Ereignismeldungen nach einer Publish-Subscribe-Kommunikationsweise wobei die Ereignismeldungen in einem paketorientierten Netzwerk ausgetauscht werden.
• Im Stand der Technik ist eine als »Publish-Subscribe« bezeichnete Kommunikationsweise bekannt, die es mehreren abonnierenden Instanzen ermöglicht, Ereignismeldungen bzw. »Event Notifications« zu abonnieren (»Subscribe«).
• Bei einem Eintreten eines vorher festgelegten Ereignisses werden die auch als »Event Consumer« bezeichneten Ereignismeldungsbezieher von einem Ereignismeldungsgeber benachrichtigt (»Publish«). Der Ereignismeldungsgeber wird in der Fachwelt auch als »Event Supplier« bezeichnet. Ein Event Supplier wird dabei häufig in Form eines Ereignismeldungsdienstes bzw. »Event Channel Service« ausgeführt.
• Eine Zustellung von Ereignismeldungen zu den abonnierenden Instanzen soll üblicherweise asynchron, d. h. ohne ein festgelegtes zeitliches Protokoll und in möglichst unmittelbar zeitlicher Nähe zum Eintreten des Ereignisses erfolgen. Diese Asynchronität trifft auf mehrere Probleme, wenn als Ereignismeldungskanal (»Event Channel«) ein paketorientiertes Netzwerk, beispielsweise unter Verwendung der Protokollfamilie TCP/IP (Transport Control Protocol/Internet Protocol) verwendet werden soll. Einige dieser Probleme werden im Folgenden näher skizziert.
• Für eine Zustellung von Ereignismeldungen an die Ereignismeldungsbezieher wird üblicherweise ein so genannter »Server Port« zur Adressierung der Ereignismeldungsbezieher eingesetzt. Sofern sowohl die Ereignismeldungsbezieher als auch der Ereignismeldungskanal sich innerhalb der Grenzen (»Trust Boundary«) eines Netzwerksegments befinden, ist ein Öffnen eines Server Ports der abonnierenden Instanz zum Empfang von asynchronen Events unproblematisch. Probleme entstehen allerdings, wenn die Ereignismeldungsbezieher »reine Clients« sind, welche vom Netzwerksegment der Ereignismeldungsgeber durch eine Firewall oder einen ähnlichen netzwerkadressumsetzenden (Network Address Tranlaten bzw. NAT) Netzknoten getrennt sind. In diesem Fall wird eine Adressierung der Ereignismeldungsbezieher über deren Server Ports unmöglich. Als »reiner Client« ist insbesondere ein Ereignismeldungsbezieher zu verstehen, an welchen eine Ereignismeldung zu übermitteln ist, ohne dass hierzu eine vorausgehende Anforderung durch den Client erfolgt ist. Eine vorausgehende Anfrage hätte im netzwerkadressumsetzenden Netzknoten zu einer Bindung geführt, welche eine Zuordnung und Adressierung der die Anforderung beantwortende Meldung erlaubt. Bei einem reinen Client ist diese Bindung nicht vorhanden, damit ist eine Bestimmung eines dem reinen Client zugeordneten Server Ports von einem außerhalb der Trust Boundary lokalisierten Ereignismeldungsgeber nicht möglich.
• Ein weiteres Problem entsteht, wenn die Ereignismeldungsbezieher als so genannte »Thin Clients« ausgestaltet sind. Darunter versteht man Netzelemente mit einer minimalen Softwareausstattung, welche z. B. lediglich einen Browser umfasst. Zur Kommunikation mit den Ereignismeldungsgebern bzw. dem Ereignismeldungskanal stehen in diesem Fall vornehmlich die Protokolle HTTP (Hyper Text Transfer Protocol) bzw. HTTP-S(-Secure) zu Verfügung, welche keine oder zumindest nur eingeschränkte Möglichkeiten einer asynchronen Zustellung von Ereignismeldungen bieten.
• Aufgabe der Erfindung ist es, eine asynchrone Zustellung von Ereignismeldungen an abonnierende Instanzen in einer paketorientierten Kommunikationsweise zu gewährleisten, welche keine Vorsehung erweiterter Protokolle erfordert.
• Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1 sowie durch einen Ereignisagenten gemäß Anspruch gelöst.
• Das erfindungsgemäße Verfahren zur paketorientierten Kommunikation asynchroner Ereignismeldungen sieht einen Ereignisagenten bzw. »Event Broker« vor, welcher Ereignismeldungen zwischen einem Ereignismeldungskanal und einem Ereignismeldungsbezieher vermittelt.
• Hierzu wird in einem ersten Schritt der Ereignisagent als ereignisbeziehende Instanz am Ereignismeldungskanal registriert. Der Ereignisagent verhält sich also gegenüber dem Ereignismeldungskanal als stellvertretender Ereignismeldungsbezieher. Der Ereignismeldungkanal wird dabei als ein Dienst zur asynchronen Übermittlung von Ereignismeldungen verstanden. Üblicherweise wird ein solcher Dienst an einem Server bzw. Ereignisgeber zur Ausführung gebracht, bei dem von beliebigen Programmen Ereignisse gemeldet werden. Im Protokoll des Ereignismeldungskanals ist dabei auch ein Abonnement Subscription von Ereignismeldungen vorgesehen.
• In einem weiteren Schritt ist ein Aufbau einer persistenten Transportebenenverbindung zwischen dem Ereignisagenten und dem Ereignismeldungsbezieher vorgesehen. Durch den Aufbau dieser bidirektional nutzbaren Verbindung seitens des Ereignismeldungsbezieher werden auf einfache Weise trennende Netzwerkelemente wie NAT-Router und Firewalls traversiert, ohne dass ein dedizierter Rückkanal etabliert sein muss. Eine persistente, also gehaltene, Transportebenenverbindung unterstützt eine nachfolgende Übermittlung von asynchronen Ereignismeldungen auf der Ebene des Transportprotokolls. Als Transportprotokolle kommen in paketorientierten Netzwerken beispielsweise das TCP (Transport Control Protocol) oder TLS (Transport Layer Security) bzw. SSL (Secure Sockets Layer) zum Einsatz.
• In einem weiteren Schritt empfängt der Ereignisagent eine Abonnementanforderung vom Ereignismeldungsbezieher. Diese A bonnementanforderung ist gemäß einem Anwendungsprotokoll, vorzugsweise HTTP (Hypertext Transfer Protocol), gestaltet. Die Abonnementanforderung wird an den Ereignismeldungskanal weitergegeben, wobei die für die Abonnementanforderung eingerichtete Anwendungsebenenverbindung zwischen dem Ereignisagenten und dem Ereignismeldungsbezieher gehalten wird. Ein Halten bedeutet in Anwendung des Protokolls HTTP, dass die Verbindung auf der Anwendungsebene nicht unbedingt nach dem häufigen Anforderungs-Bestätigungs-Kommunikationsschema auch als Request/Reply bekannt beendet bzw. geschlossen wird. Bei Bedarf wird die Abonnementanforderung vor der Weitergabe an den Ereignismeldungskanal durch den Ereignisagenten so modifiziert, dass diese dem für den Ereigniskanal vorgesehenen Protokoll entspricht.
• Tritt ein zuvor abonniertes Ereignis ein, erfolgt eine Zustellung der Ereignismeldung durch den Ereignisagenten über die gehaltene Anwendungsebenenverbindung. Die Zustellung durch den Ereignisagenten erfolgt im Zuge einer Weiterleitung einer oder mehrerer vom Ereigniskanal ausgegebenen Ereignismeldungen. Das »abonnierte Ereignis« entspricht einem oder mehreren Ereignissen, für welche in der Abonnementanforderung eine Zustellung von Ereignismeldungen abonniert wurden. Diese Abonnementanforderung ist im übrigen nicht auf dem Ereignisbezieher von vorneherein bekannte Ereignisse beschränkt, statt dessen kann auch ein Filter für eine Mehrzahl von Ereignissen oder auch eine Anforderung, alle Ereignisse zu übersenden angefordert werden.
• Als besonderer Vorteil des erfindungsgemäßen Verfahrens ist die einfache Adressierung des Ereignisbeziehers zu nennen. Durch die gehaltene Verbindung auf der Transport- und Anwendungsebene ist keine Bestimmung und Öffnung von Server Ports des Ereignisbeziehers durch den Ereigniskanal oder durch einen sonstigen Dienst seitens eines Servers notwendig. Damit ist das erfindungsgemäße Verfahren in vorteilhafter Weise auch über Firewalls bzw. netzadressumsetzende Knoten einsatzfähig ist.
• In vorteilhafter Weise ist eine Zustellung mindestens einer, also insbesondere mehrerer Ereignismeldung in einer über die gehaltene Anwendungsebenenverbindung versendeten Nachricht (HTTP-Response) möglich.
• Ein weiterer Vorteil besteht darin, dass die einzige persistente Transportebenenverbindung für beliebig viel weitere Ereignismeldungsanwendungen nutzbar ist. Insbesondere ist damit auch eine Kommunikationsweise realisierbar, welche als Request/Multiple Reply-Kommunikationsweise bekannt ist. Bei einer solchen Kommunikationsweise ist ein Versenden mehrfacher Antworten auf eine Anforderung über die gehaltene Anwendungsebenenverbindung vorgesehen, wobei die Anforderung als Abonnementanforderung und die mehrfachen Antworten zur Übermittlung der Ereignismeldungen verwendet werden.
• Der erfindungsgemäße Einsatz eines Ereignisagenten entlastet in vorteilhafter Weise den Ereignismeldungskanal und damit einen Ereignismeldungsdienst eines Ereignisgebers.
• Ein Ausführungsbeispiel mit weiteren Vorteilen und Ausgestaltungen der Erfindung wird im Folgenden anhand der Zeichnung näher erläutert.
• Dabei zeigen:
• 1: ein Strukturbild zur schematischen Darstellung der zwischen den an der Kommunikation asynchroner Ereignismeldung beteiligten Funktionseinheiten ausgetauschten Nachrichten,
• 2A: ein Strukturbild zur schematischen Darstellung eines zeitlichen Ablaufs ausgetauschter Nachrichten für ein Request/Multiple Reply-Kommunikationsschema,
• 2B: ein Strukturbild zur schematischen Darstellung eines zeitlichen Ablaufs ausgetauschter Nachrichten für ein Request/Reply-Kommunikationsschema,
• Im Folgenden werden zunächst ohne Bezugnahme auf die Zeichnung einige Probleme einer paketorientierten Zustellung asynchroner Ereignismeldungen und mögliche Umgehungslösungen erläutert, deren von den Erfindern erkannte Unzulänglichkeiten schließlich zur erfindungsgemäßen Lösung geführt haben.
• Zur Umgehung der eingangs genannten, mit einer asynchronen Zustellung von Ereignismeldungen in paketorientierten Netzwerken auftretenden Problemen könnte ein aktives Abfragen bzw. »Polling« des Ereignisgebers seitens des Ereignisbeziehers implementiert werden, bei dem der Ereignisgeber in zyklischen Zeitabständen angefragt wird, ob ein bestimmtes Ereignis vorliegt. Diese Umgehungslösung würde jedoch der Maßgabe eines Publish-Subscribe-Kommunikationsprinzip zuwiderlaufen und die bekannten Nachteile eines Polling-Verfahrens beibehalten.
• Eine weitere mögliche Umgehungslösung wäre ein Einsatz eines separaten Protokolls zwischen Client und Server zum Austausch von Ereignismeldungen. Diese Umgehungslösung hätte allerdings den Nachteil, dass ein Server Port auf dem Client geöffnet werden muss, was wiederum zu den oben beschriebenen Problemen mit einer Firewall führt. Überdies verbietet eine oben beschriebenen »Thin Client«-Architektur eine Installation eines zusätzlichen Protokollstacks.
• Eine weitere Umgehungslösung wäre mittels einer auf Seiten des Ereignismeldungsgebers verzögerten Anfrage durch den Ereignismeldungsbeziehers zu realisieren, indem zukünftige Ereignismeldungen durch den Ereignisbezieher beispielsweise mittels eines HTTP-Requests angefordert werden, mit der Beantwortung der Anforderung auf Seiten des Ereignismeldungsgebers so lange gewartet wird, bis das Ereignis tatsächlich eingetreten ist und dessen Eintreten asynchron an den Ereig nismeldungsbezieher gemeldet wird. Diese Vorgehensweise weist jedoch einen Nachteil in der serverseitigen d. h. seitens des Ereignismeldungsgebers Bearbeitung des HTTP-Requests auf. Zur Bearbeitung dieses Requests wird nämlich bei üblichen Serverinstallationen in einem Servlet Container wie z. B. dem »Apache Tomcat« Servlet Container ein Thread zur Bearbeitung des HTTP-Requests angelegt. Bei der angewandten serverseitigen Blockade bis zum Eintreten des Ereignisses ergibt sich bei mehreren solcher Threads ein Skalierbarkeitsproblem, da für jeden Anforderung ein Thread vorgehalten werden muss, welcher einen zusätzlichen Speicherbedarf von mehreren Kilobyte auf Seiten des Servers erfordert.
• Das erfindungsgemäße Verfahren sieht stattdessen einen separaten Ereignisagenten vor, bei dem gehaltene Verbindungen nicht mit Threads verwaltet werden müssen. Der Einsatz eines Ereignisagenten stellt somit im Unterschied zur serverseitigen Verwaltung eine skalierbare Lösung da, da der Ereignisagent keine Threads für ein Blockieren der HTTP-Requests benötigt.
• Nach diesen einleitenden Vorbemerkungen erfolgt nun die Darstellung der erfindungsgemäßen Lösung anhand eines exemplarischen Ausführungsbeispiels.
• In 1 ist eine Mehrzahl von Ereignismeldungsbezieher CLI bzw. »Clients« dargestellt, die mit einem Ereignisagenten EVTBR verbunden ist. Der Ereignisagent EVTBR bzw. Eventbroker EVTBR ist wiederum mit einem Ereignismeldungskanal EVTCH verbunden, der mit dem eigentlichen Ereignismeldungsgeber EVTSUPP verbunden ist.
• Der Ereignismeldungsbezieher CLI verhält sich gegenüber dem Ereignisagenten EVTBR als »Event Consumer«. Der Ereignisagent EVTBR verhält sich gegenüber dem Ereignismeldungsbezieher CLI dementsprechend als »Eventsupplier« und gegenüber dem Ereignismeldungskanal EVTCH seinerseits als »Event Consumer«. Mit einer Anmelde-Anforderung 100 bzw. »Subscribe«-Meldung wird vom Ereignismeldungsbezieher CLI ein Abonnement für Ereignismeldungen vom Ereignisagenten EVTBR angefordert. Diese Abonnementanforderung 100 wird, optional in modifizierter Weise, vom Ereignisagenten EVTBR an den Ereignismeldungskanal EVTCH in Form der Meldung 102 weitergegeben.
• Mit einer weiteren Nachricht 104, auch als »Register«-Nachricht bezeichnet, wird die Abonnementanforderung vom Ereignismeldungskanal EVTCH an den eigentlichen Ereignismeldungsgeber EVTSUPP weitergeleitet.
• Bei Eintreten eines Ereignisses oder eines Bündels an Ereignissen wird das zugehörige Ereignis in Form einer Ereignismeldung 106 bzw. »Publish-Meldung« vom Ereignismeldungsgeber EVTSUPP an den Ereignismeldungskanal EVTCH gemeldet. Der Ereignismeldungskanal EVTCH reicht die Ereignismeldung 106 in Form einer weiteren Meldung 108 bzw. »Notify«-Meldung an den Ereignisagenten EVTBR weiter. Der Ereignismeldungs-Bezieher CLI erhält im Falle einer »getEvent«-Anforderung 110, welche vom Ereignismeldungsbezieher CLI an den Ereignisagenten EVTBR gesendet wird, eine – nicht dargestellte – Antwort in Form der Ereignismeldung.
• Der Ereignisagent EVTBR realisiert eine Zustellung der Ereignismeldungen zum Ereignismeldungsbezieher CLI, indem der Ereignismeldungsbezieher CLI eine persistente Transportebenenverbindung zum Ereignisagent EVTBR aufbaut. Als Transportprotokoll für die persistente Transportebenenverbindung wird in vorteilhafter Weise SSL/TLS (Transport Layer Security/Secure Sockets Layer) gewählt, welche neben einer verschlüsselten Datenübertragung eine Zustellung asynchroner Ereignismeldungen an den Ereignismeldungsbezieher CLI erlaubt, ohne dass seitens des Ereignismeldungsbezieher CLI ein Server Port geöffnet werden muss. Bei einem Transportprotokoll stellen sowohl der Sender als auch der Empfänger Endpunkte, auch »Sockets« genannt, bereit. Ein Socket umfasst eine Socketnummer bzw. -adresse, die aus einer IP-Adresse und einer Portnummer besteht.
• HTTP (Hypertext Transfer Protocol), welches im bevorzugten Ausführungsbeispiel als Anwendungsprotokoll eingesetzt ist, wird derzeit in zwei Protokollversionen, HTTP v1.0 und HTTP v1.1 betrieben. Bei der Version 1.0 von HTTP wird vor jeder Anfrage eine neue TCP-Verbindung aufgebaut und nach Übertragung der Antwort wieder geschlossen, während bei der Version 1.1 mehrere Anfragen und Antworten pro TCP-Verbindung gesendet werden können.
• In der Version 1.1 des HTTP wird in einem bevorzugten Ausführungsbeispiel vgl. Figurenbeschreibung anhand der 2B eine »Streaming«-Kommunikationsweise angewandt, welche das Senden eines HTTP-Requests mit dem Beantworten mehrerer HTTP-Responses zulässt. Die eigentlichen Nachrichten zwischen Client und Server werden beispielsweise in SOAP (ursprünglich für »Simple Object Access Protocol«) kodiert.
• In Richtung des Ereignismeldungskanal EVTCH verhält sich der Ereignisagent EVTBR wie ein »Event Consumer«, d. h. der Ereignisagent EVTBR legt ein »Consumer«-Objekt an und reicht die vom Ereignismeldungsbezieher CLI empfangenen Subskriptionen an diesen weiter. Der Ereignismeldungskanal EVTCH ist somit in der Lage, die Ereignismeldungen asynchron an den Server Port des Ereignisagenten EVTBR zu senden. Dieser sendet diese über die oben erwähnte vom Client vorab geöffnete persistente Verbindung als HTTP-Response Nachrichten an den Ereignismeldungsbezieher CLI direkt weiter.
• Die weitere Figurenbeschreibung erfolgt unter weiterer Bezugnahme auf die Funktionseinheiten von jeweils vorausgehenden Figuren. Identische Bezugszeichen in verschiedenen Figuren repräsentieren hierbei identische Funktionseinheiten.
• Der anhand von 1 grob dargestellte Nachrichtenaustausch wird im Folgenden in 2A anhand einer schematischen Darstellung eines zeitlichen Ablaufs ausgetauschter Nachrichten für ein Request/Multiple-Reply-Kommunikationsschema näher dargestellt.
• Die ausgetauschten Nachrichten sind in den folgenden 2A und 2B so dargestellt, dass eine Anforderungsnachricht mit einer durchgezogenen Linie und eine Bestätigungsnachricht mit einer strichlierten Linie versinnbildlicht sind.
• Zu einem ersten Zeitpunkt wird vom Ereignisagenten EVTBR eine Nachricht 200 an den Ereignismeldungskanal EVTCH gesendet, welche auch als allocateComsumer () bezeichnet wird. Durch diese Nachricht 200 wird das erwähnte »Consumer Object« eingerichtet. Die Einrichtung des Consumer Objects wird vom Ereignismeldungskanal EVTCH über eine strichliert dargestellte Meldung 202 bestätigt, welche eine consumerID zurückliefert.
• In einer vom Ereignismeldungsbezieher CLI an den Ereignisagenten EVTBR gesendeten Nachricht 204 »createConnection ()« wird eine persistente Verbindung zwischen dem Ereignismeldungszieher CLI und dem Ereignisagenten EVTBR eingerichtet, welche seitens des Ereignisagenten EVTBR mit einer Nachricht 206 »handle« bestätigt wird. Der Ereignismeldungskanal EVTCH ist somit in der Lage, die Ereignismeldungen asynchron an den Server Port des Ereignisagenten EVTBR zu senden. Dieser sendet diese über die oben erwähnte vom Client vorab geöffnete persistente Verbindung als HTTP-Response Nachrichten an den Ereignismeldungsbezieher CLI direkt weiter.
• Zur Einrichtung eines Abonnements sendet der Ereignismeldungsbezieher CLI im Folgenden eine Nachricht 208 »getEvents« an den Ereignisagenten EVTBR.
• Im Folgenden wird nun von einem geänderten Betriebszustand von nicht dargestellten Endgeräten mit einer Benutzeridentifikationsnummer »UserID1« bzw. »UserID2« ausgegangen. Diese Änderung des Betriebszustandes eines »Presence State« wird vom Ereignismeldungskanal EVTCH in Form der Nachrichten 210 und 214 an den Ereignisagenten EVTBR gemeldet, wobei der Ereignisagent EVTBR diese Meldungen 210, 214 in Form der Nachrichten 212, 216 an den Ereignismeldungsbezieher CLI weiterreicht.
• In der folgenden angenommenen Änderung im Anrufzustand bzw. »Call State« von Endgeräten mit den Benutzeridentifikationsnummern »UserID1« bzw. »UserID2« erfolgt analog zum Vorhergesagten eine Übermittlung von Nachrichten 218, 222 vom Ereignismeldungskanal EVTCH an den Ereignisagenten EVTBR und von dort eine entsprechende Weiterleitung an den Ereignismeldungsbezieher CLI in Form der Nachrichten 220, 224.
• Zur Beendigung des Abonnements an Ereignismeldungen sendet der Ereignismeldungsbezieher CLI eine Nachricht 226 »disconnect« an den Ereignisagenten EVTBR, welche von diesem in Form einer Bestätigungsnachricht 228 bestätigt wird.
• Zusammenfassend wird unter Anwendung des Request/Multiple-Reply-Kommunikationsschemas eine getEvent-Anforderung an den Ereignisagenten EVTBR zugestellt und diese Anforderung mit in Folge auftretenden Ereignismeldungen in Form mehrfacher »HTTP-Responses« beantwortet.
• Gemäß einem weiteren Ausführungsbeispiel werden Ereignismeldungen im Ereignisagenten EVTBR zwischengespeichert, falls noch keine Request/Multiple-Reply-Verbindung zwischen dem Ereignismeldungsbezieher CLI und dem Ereignisagenten EVTBR aufgebaut wurde.
• 2B zeigt eine schematische Darstellung eines Ablaufs ausgetauschter Nachrichten für ein Request/Reply-Kommunikationsschema. Im Unterschied zu dem anhand der 2A gezeigten Kommunikationsschema wird in diesem Request/Reply-Kommunikationsschema mit jeder Anforderungsnachricht ein stattgefundenes Ereignis nachgefragt, wobei die Nachfrage an den Ereignisagenten gesendet wird und das Ergebnis mittels einer HTTP-Antwort zugestellt wird. Hierbei wird mit jeder Request eine getEvent-Anforderung an den Ereignisagenten EVTBR gestellt und jeweils eine Ereignismeldung mittels HTTP-Response zugestellt. Der HTTP-Request wird auf Seiten des Ereignismeldungskanals EVTCH blockiert, bis ein Ereignis vorliegt. Wurde ein HTTP-Request durch den Ereignismeldungskanals EVTCH beantwortet, so muss der Ereignismeldungsbezieher CLI einen erneuten Request stellen, um die nächste Ereignismeldung vom Ereignismeldungskanals EVTCH abzuholen.
• In einem ersten Schritt wird mit den bereits aus 2A bekannten Nachrichten 200, 202 analog ein »Consumer Object« eines Ereignismeldungskanals EVTCH angelegt.
• Mit einer auch als »createEventSession« bezeichneten Anforderungnachricht 230 wird vom Ereignismeldungbezieher CLI eine Anmeldung für einen Bezug von Ereignissen durchgeführt. Die Anmeldung wird vom Ereignisagenten EVTBR mittels der Nachricht 232 beantwortet, welche gleichzeitig eine »SessionID« zur Charakterisierung der Kommunikationsbeziehung enthält.
• In einer Nachricht 234 fordert der Ereignismeldungsbezieher CLI einen Bezug einer Ereignismeldung bzw. einer Mehrzahl von Ereignismeldungen an, wobei die Auswahl der Ereignisse durch einen Filter charakterisiert wird. Die Nachricht »Subcribe (sessionID, filter1)« enthält neben dem spezifizierten Filter die vormals durch die Nachricht 232 bezogene sessionID.
• Vom Ereignisagenten EVTBR wird daraufhin eine Nachricht 236 an den Ereignismeldungskanal EVTCH weitergegeben, welche den spezifizierten Filter enthält.
• Bei Eintreten des Ereignisses wird vom Ereignismeldungskanal EVTCH eine Nachricht 238 an den Ereignisagenten EVTBR gesendet, welche das eingetretene Ereignis oder den Eintritt einer Mehrzahl von Ereignissen meldet. Diese Nachricht 238 wird in Form der Nachricht 240 an den Ereignismeldungsbezieher CLI weitergeleitet.
• In analoger Weise, jedoch mit einem anders gearteten Filter wird mit der Nachricht 240, 242, 244 und 246 verfahren.
• Mit den Nachrichten 248 bis 262 wird das jeweilige, voraus eingerichtete Abonnement seitens des Ereignismeldungsbeziehers CLI beendet. Schließlich wird mit einer Anforderungsnachricht 264, welche vom Ereignismeldungsbezieher CLI an den Ereignismeldungsagenten EVTBR gesendet wird, die Ereignismeldungssitzung beendet. Die Beendigung der mit der Nachricht 264 bzw. »closeEventSession (sessionID)« abgeschlossenen Kommunikationsbeziehung wird vom Ereignisagenten EVTBR mit Nachricht 266 bestätigt.
• Es versteht sich, dass die in 2A und 2B dargestellten Nachrichten auch überlappend, beispielsweise für unterschiedliche Ereignismeldungsbezieher CLI, erfolgen können.

Claims (5)

1. Verfahren zur paketorientierten Kommunikation asynchroner Ereignismeldungen zwischen einem Ereignismeldungskanal (EVTCH) und einem Ereignismeldungsbezieher (CLI), wobei auf einem Ereignisagenten (EVTBR) folgende Schritte zur Ausführung gebracht werden: a) Registrierung des Ereignisagenten (EVTBR) als ereignisbeziehende Instanz am Ereignismeldungskanal (EVTCH), b) Aufbau einer persistenten Transportebenenverbindung mit dem Ereignismeldungsbezieher (CLI), c) Empfang mindestens einer Abonnementanforderung vom Ereignismeldungsbezieher (CLI) und Weitergabe der Abonnementanforderung an den Ereignismeldungskanal (EVTCH), wobei eine für die Abonnementanforderung eingerichtete Anwendungsebenenverbindung gehalten wird, d) bei Auftreten eines abonnierten Ereignisses, Zustellung der mindestens einen Ereignismeldung durch den Ereignisagenten (EVTBR) über die gehaltene Anwendungsebenenverbindung.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die gehaltene Anwendungsebenenverbindung nach Zustellung einer Ereignismeldung gemäß Schritt d) gehalten wird.
3. Verfahren nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass für die Anwendungsebenenverbindung das an sich bekannte Protokoll HTTP in der Version 1.1 eingesetzt wird.
4. Verfahren nach einem der vorgenannten Ansprüche, dadurch gekennzeichnet, dass für die persistente Transportebenenverbindung das an sich bekannte Protokoll SSL/TLS eingesetzt wird.
5. Ereignisagent zur paketorientierten Kommunikation asynchroner Ereignismeldungen zwischen einem Ereignismeldungskanal (EVTCH) und einem Ereignismeldungsbezieher (CLI), mit a) Mittel zur Registrierung als ereignisbeziehende Instanz am Ereignismeldungskanal (EVTCH), b) Mittel zum Aufbau einer persistenten Transportebenenverbindung mit dem Ereignismeldungsbezieher (CLI), c) Mittel zum Empfang mindestens einer Abonnementanforderung vom Ereignismeldungsbezieher (CLI) und Weitergabe der Abonnementanforderung an den Ereignismeldungskanal (EVTCH), wobei eine für die Abonnementanforderung eingerichtete Anwendungsebenenverbindung gehalten wird, d) Mittel zur Zustellung mindestens einer Ereignismeldung bei Auftreten eines abonnierten Ereignisses über die gehaltene Anwendungsebenenverbindung.