DE602005005613T2

DE602005005613T2 - Überprüfen und Aufrechterhalten der Lebhaftigkeit einer Verbindung in einer Web Services Umgebung mit zuverlässiger Nachrichtenübermittlung

Info

Publication number: DE602005005613T2
Application number: DE602005005613T
Authority: DE
Inventors: Michael J. Redmond Moroney; Richard D. Redmond Hill; Rodney T. Redmond Limprecht; Shy Redmond Cohen; Stefan R. Redmond Batres; Margaret J. Redmond Lye
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2004-12-08
Filing date: 2005-11-09
Publication date: 2008-07-17
Anticipated expiration: 2025-11-10
Also published as: EP1670213A1; KR101169086B1; JP2006164252A; KR20060064517A; CN1787497A; DE602005005613D1; CN1787497B; JP4972304B2; US7899921B2; US20060123119A1; ATE390793T1; EP1670213B1

Description

QUERVERWEISE ZU VERWANDTEN ANMELDUNGEN

Nicht verfügbar

HINTERGRUND DER ERFINDUNG
1. Das Feld der Erfindung
Die vorliegende Erfindung bezieht sich generell auf verlässliche Nachrichtenprotokolle für Netzdienste. Mehr spezifisch stellt die vorliegende Erfindung einen Mechanismus zur Verfügung, der die Charakteristiken von zuverlässigen Nachrichtenprotokollen für Netzdienste (Reliable Messaging protocols for Web Services, RM-WS) zum Verifizieren und Aufrechterhalten einer Verbindungslebendigkeit in einer Sequenzsitzung verstärkt.
2. Hintergrund und verwandte Technik
Computernetzwerke haben unsere Fähigkeiten zum Kommunizieren und den Zugang zur Information verbessert, indem es einem Computer oder einer Vorrichtung zur Kommunikation erlaubt ist, über ein Netzwerk mit anderen Computersystemen unter Verwendung von elektronischen Nachrichten zu kommunizieren. Wenn eine elektrische Nachricht zwischen Computersystemen übertragen wird, wird die elektronische Nachricht oft durch einen Protokollstapel geschickt, der Operationen mit den Daten in der elektronischen Nachricht durchführt (z. B. Parsen, auf einen Weg leiten (Routing), Flusskontrolle usw.). Das offene Systemverbindungsmodell (Open System Interconnect, OSI) ist ein Beispiel eines Netzwerkrahmens zur Implementierung eines Protokollstapels.
Das OSI-Modell bricht die Operationen zum Übertragen einer elektronischen Nachricht in sieben verschiedene Stufen bzw. Schichten herunter, wobei jede dazu vorgesehen ist, eine bestimmte Operation in dem Datentransferprozess durchzuführen. Während Protokollstapel potenziell jede der Ebenen implementieren können, implementieren viele Protokollstapel nur ausgewählte Ebenen zum Transferieren von Daten durch ein Netzwerk. Wenn Daten von einem Computersystem übertragen werden, entstehen sie auf der Anwen dungsebene und werden zu dazwischenliegenden niedrigeren Ebenen und dann in ein Netzwerk heruntergereicht. Wenn Daten von einem Netzwerk empfangen werden, treten sie in die physikalischen Ebenen ein und werden dann an die höheren dazwischenliegenden Ebenen weitergereicht und dann eventuell auf dieser Applikationsebene empfangen. Die Applikationsebene bzw. Anwendungsebene – die am höchsten liegende Ebene – ist verantwortlich für eine Unterstützung der Anwendung und eine Entnutzerverarbeitung. Des Weiteren können sich in der Anwendungsebene mehrere andere Ebenen befinden (z. B. eine einfache Protokollebene mit einfachem offenem Zugang, Simple Open Access Protocol (SOAP) Layer). Eine weitere Ebene, die von den meisten Protokollstapeln mit aufgenommen wird, ist die Transportebene. Ein Beispiel für die Transportebene ist das Übertragungskontrollprotokoll (Transmission Control Protocol, TCP).
Netzdienste (Web Services, WS) waren die treibende Kraft beim Verbessern der Kommunikation zwischen Computersystemen und drehen die Art und Weise mit der wir Software aufbauen und verwenden von innen nach außen. Netzdienste lassen Anwendungen Daten tauschen bzw. teilen und – noch leistungsfähiger – rufen Fähigkeiten von anderen Anwendungen auf, ohne in Betracht zu ziehen, wie diese Anwendungen aufgebaut wurden; auf welchen Betriebssystemen oder Plattformen diese laufen; und welche Vorrichtungen zu ihrem Zugang verwendet werden. Netzdienste werden über das Internet mittels industrieller Standardprotokolle inklusive SOAP, XML (eXtensible Markup Language), UDDI (Universal, Description, Discovery and Integration), WSDL (Web Service Description Language) usw. aufgerufen. Obwohl die Netzdienste unabhängig voneinander bleiben, können sie sich lose mit einer mitarbeitenden Gruppe verbinden, die eine bestimmte Aufgabe ausführt.
Derzeitige WS-Technologien bieten eine direkte SOAP-Nachrichtenkommunikation zwischen einem Initiator (z. B. einem Klienten (Client)) und einem Empfänger (z. B. einem Dienst (Service)). In dem allgemeinen Fall bidirektionaler Nachrichten wird eine SOAP-Nachfragenachricht von dem Initiator an den Empfänger (Acceptor) gesendet und eine SOAP-Antwortnachricht wird darauf als Antwort gesendet. Eine weitere Kommunikationsvariante zwischen Endpunkten ist ein unidirektionaler Nachrichtenaustausch, worin der Initiator eine Nachricht an den Empfänger ohne Antwort sendet.
Ein wesentlicher Vorteil der aufkommenden WS-Architektur ist die Fähigkeit, integrierte, übergreifend tätige Lösungen zu liefern. Weil Netzdienste jedoch verschiedenartige Dienste aus verschiedenen Geschäfts-, Organisations- und anderen Dienstleistern über unverlässliche Kommunikationswege, so wie das Internet, zur Verfügung stellen, wird die Zuverlässigkeit des WS zu einem zunehmend wichtigen Faktor. Die Zuverlässigkeit von WS wird durch mehrere Faktoren beeinflusst, die beinhalten, aber nicht beschränkt sind auf: die Zuverlässigkeit des Netzdienstes an Endpunkten; die Zuverlässigkeit der Charakteristiken der Kommunikationswege über welche auf die Netzdienste zugegriffen wird; Leistungs- und Fehlertoleranzcharakteristiken; und das Ausmaß, in welchem die Netzdienste gleichzeitig auftretenden Benutzerzugang (Client Access) händeln können.
Es gab viele Versuche, verlässliche Nachrichtenübermittlung von Netzdiensten durch die Auswahl eines verlässlichen Transportprotokolls, durch das die Nachrichten (z. B. SOAP-Nachrichten) zwischen Endpunkten ausgetauscht werden, zu erreichen. Zum Beispiel kann ein verlässlicher Nachrichtentransport, so wie Nachrichtenaneinanderreihungen, verwendet werden, um Nachrichten zuverlässig zwischen Initiatoren und Empfängern zu übertragen. Technologien zur Kommunikation von Nachrichtenaneinanderreihungen (message-queuing) ermöglichen es den Anwendungen, auf verschiedenen Systemen miteinander zu kommunizieren, indem Nachrichten zu Aneinanderreihungen (queues) gesendet werden und Nachrichten von den Aneinanderreihungen gelesen werden, die zur Zuverlässigkeit unbeirrt über Fehler fortgeführt werden.
Obwohl Aneinanderreihungssysteme einen Transport zur Verfügung stellen, welcher zum verlässlichen Übertragen von SOAP-Nachrichten verwendet werden kann, sind da mehrere Nachteile in einem solchen System. Zum Beispiel stellen diese Systeme Lösungen für einen asynchronen Betrieb zur Verfügung, wobei die Nachfragen (und möglicherweise ihre Antworten) isoliert übertragen und bearbeitet werden. Dementsprechend sind diese Systeme typischerweise in Bezug auf Ressourcen schwergewichtig, beinhalten eine Vielzahl von Vermittlungsstellen mit andauernd durchgeführten Nachrichtenspeicherungen und mit einer womöglich höheren Komplexität in der Einrichtung, den Programmierungsmodellen und dem Management. All dies ist unnötig für eine verlässliche direkte Kommunikation und lenkt von dem Ziel ab, Latenzen zu minimieren. Des Weiteren unterstützt das Programmmodell nicht direkt die Programmierung oder Sitzungen (Sessions) im Nachfrage- und Antwortstil. Dementsprechend unterscheidet sich das Modell aneinandergereihter Kommunikationen von dem unmittelbaren "interaktiven" Netzdienstmodell und ist nicht auf kritische "verbundene" Szenarios und "interaktive" Anwendungen gerichtet. Zum Beispiel ist es nicht gut für Fälle geeignet, in denen eine Antwort auf pünktliche Weise erwartet wird, oder für Fälle, in denen verteilte Transaktionsinhalte (distributed-transaction-context) zwischen einem Initiator und einem Empfänger getauscht bzw. geteilt werden.
Es gab auch Versuche, verlässliche Transferebenen über grundsätzlich unverlässliche Transportprotokolle zu definieren, z. B. verlässliche HTTP oder HTTPR. Ein allgemeines Problem, das diese Lösungen – sowie die Aneinanderreihungslösungen – plagt, ist allerdings, dass verlässliche Nachrichtenübermittlung nur erreicht werden kann, wenn das spezifische verlässliche Transportprotokoll für die Kommunikation zwischen dem Initiator und dem Empfänger verwendet wird. Die fundamentale Natur von Netzdiensten verlangt nach Unabhängigkeit von den Plattformen verschiedener Anbieter, Implementierungssprachen und spezifischen Transportprotokollen. In einem gattungsgemäßen (generischen) Fall könnte ein Initiator nicht dazu fähig sein, eine Nachricht unter Verwendung eines bestimmten Protokolls (z. B. der Empfänger unterstützt das Protokoll nicht) zu übertragen oder die Nachricht müsste womöglich eine Vielzahl von Sprüngen (hops) passieren, nachdem sie den versendenden Knotenpunkt (node) verlassen hat und bevor sie in dem Zielknotenpunkt ankommt. Abhängig von der Natur der Konnektivität zwischen den zwei Knotenpunkten, die in einem bestimmten Sprung enthalten sind, könnte ein passendes Transportprotokoll, das nicht verlässliche Nachrichtencharakteristiken zur Verfügung stellt, gewählt worden sein.
Vermittler könnten auch auf verschiedenen Ebenen in dem Protokollstapel existieren; und deswegen nicht eine vollkommene End-zu-End Zuverlässigkeit bieten. Zum Beispiel können Transportprotokolle Verlässlichkeit über Vermittler niedrigerer Ebenen bieten (z. B. IP-Ebenevermittler – z. B. IP-Router). Das Transportprotokoll könnte allerdings an einem SOAP-Vermittler oder einer Anwendungsebene enden. Dementsprechend könnte das Transportprotokoll nicht dazu fähig sein, eine Zuverlässigkeit über diesen Vermittler zu bieten, d. h. keine End-zu-End Zuverlässigkeit über die Anwendungsebene.
In jüngster Zeit bieten verschiedene verlässliche Nachrichtenprotokolle für Netzdienste (im Folgenden als "RM-WS-Protokolle" bezeichnet), z. B. WS-verlässliche Nachrichtenübertragung (WS-ReliableMessaging), Lösungen zu den oben identifizierten Unzulänglichkeiten von aktuellen verlässlichen Nachrichtenübertragungssystemen. Diese Protokolle sind transportagnostisch verbundene Protokolle (transport agnostic connected protocols) die es erlauben, Nachrichten zuverlässig zwischen Endpunktanwendungen in Anwesenheit von Softwarekomponenten-, System- oder Netzwerkfehlern zu übertragen. Dementsprechend bieten RM-WS-Protokolle Lösungen für eine zuverlässige, sitzungsorientierte End-zu-End Kommunikation zwischen einem Initiator und einem Empfänger.
Diese RM-WS-Protokolle sind TCP dahingehend ähnlich, dass TCP verlässlich exakt einmal eine geordnete Lieferung eines Stromes von Bytes von einem TCP-Sender zu einem TCP-Empfänger über nach Internet-Protokoll (IP) arbeitende Verteiler (Router) und eine Vielzahl von Netzwerken bietet. Verlässliche Nachrichtenprotokolle für WS bieten das gleiche und mehr für Nachrichten (beachte: die Transfereinheit ist eine Nachricht, nicht ein Byte oder eine Ansammlung von Bytes, so wie es für TCP der Fall ist, worin die Größe der Bytes durch den verfügbaren nutzbaren Platz in dem IP-Paket bestimmt wird) über eine Vielzahl von Vermittlern (inklusive SOAP-Ebenenvermittler), Transporte und Verbindungen. Obwohl TOP und RM-WS-Protokolle beide "verlässliche" Protokolle sind, weil RM-WS auf der Anwendungs- oder SOAP-Ebene in dem OSI-Modell liegt, sorgen RM-WS-Protokolle für eine verlässliche Benachrichtigung, unbeachtet des Transportprotokolls, das zum Transfer der Daten verwendet wird. Dementsprechend sind RM-WS-Protokolle nicht an ein bestimmtes Transport- oder anderes Protokoll gebunden, das zum Transfer von Nachrichten zwischen Endpunkten benutzt wird.
Obwohl ein paar wenige RM-WS-Protokolle schon einige Zeit lang zur Verfügung stehen, bestehen immer noch mehrere Nachteile und Unzulänglichkeiten bei diesen Protokollspezifikationen. Zum Beispiel stellen diese RM-WS-Protokolle keinen Weg zur Verifizierung der Verbindungseigenschaften für eine eingerichtete Sequenzsitzung zur Verfügung. Des Weiteren stellen diese Spezifikationen keinen Weg zur Aufrechterhaltung der Lebendigkeit einer Verbindung und/oder zur Verlängerung der Sequenzsitzung in Abwesenheit eines Nachrichtenaustausches über eine inaktive Auszeitperiode zur Verfügung. Dementsprechend existiert ein Bedürfnis, eine Verbindungslebendigkeit für Systeme zu verifizieren und aufrechtzuerhalten, die ein RM-WS-Protokoll verwenden.
Die EP 1 463 249 A2 von R. D. Hill et al. offenbart eine Nachrichtenübertragung mit konfigurierbaren Absicherungen und Merkmalen zwischen zwei Endpunkten.
KURZE ZUSAMMENFASSUNG DER ERFINDUNG
Die oben erwähnten Unzulänglichkeiten und Nachteile von aktuellen verlässlichen Nachrichtenprotokollen für Netzdienste werden durch beispielhafte Ausführungsformen der vorliegenden Erfindung überwunden. Zum Beispiel sorgt die vorliegende Erfindung für Mechanismen zum Verifizieren der Existenz einer Sequenzverbindung und zum Aufrechterhalten der Verbindungslebendigkeit zwischen Endpunkten durch die Verwendung eines verlässlichen Nachrichtenprotokolls für Netzdienste (RM-WS-Protokoll).
Wenn eine Verbindungslebendigkeit zum Beispiel an einem Initiatorendpunkt aufrechterhalten wird, besorgt die vorliegende Erfindung zur Einrichtung einer Sequenzsitzung, die durch einen einzigartigen Sequenzidentifizierer auf einer Anwendungsebene zwischen zwei Endpunkten in Übereinstimmung mit einem RM-WS-Protokoll identifiziert wird. Basierend auf der Nachfrage, eine Sequenzsitzung aufzubauen, wird ein einzigartiger Sequenzidentifizierer kreiert, der zu der Sequenzsitzung gehört. Danach oder zu jeder anderen Zeit wird eine inaktive Auszeitperiode für die Sequenzsitzung identifiziert, die eine obere Grenze für die Zeit darstellt, die verstreichen darf, ohne dass eine Nachricht für die Sequenzsitzung erhalten wird. In Übereinstimmung mit einem Algorithmus, der auf der inaktiven Auszeitperiode basiert, wird eine Lebenserhaltungsablaufauszeit berechnet. Basierend auf der berechneten Lebenserhaltungsablaufauszeit wird eine Nachricht gesendet, die den einzigartigen Sequenzidentifizierer beinhaltet. Danach wird vor der Inaktivitätsauszeitperiode eine Nachricht erhalten, die den einzigartigen Sequenzidentifizierer beinhaltet, so dass die Verbindungslebendigkeit aufrechterhalten wird. Basierend auf der erhaltenen Nachricht wird ein Inaktivitätszeitgeber für die Inaktivitätsauszeitperiode zurückgesetzt, so dass die Sequenzsitzung am Leben gehalten bzw. aufrechterhalten wird.
In einem Ausführungsbeispiel zum Verifizieren der Verbindungslebendigkeit wird eine durch einen einzigartigen Sequenzidentifizierer identifizierte Sequenzsitzung auf einer Anwendungsebene zwischen zwei Endpunkten in Übereinstimmung mit einem RM-WS-Protokoll eingerichtet. Nämlich wie oben wird eine Inaktivitätauszeitperiode identifiziert, die eine obere Zeitgrenze für die Zeit darstellt, die verstreichen darf, ohne dass zwischen den Endpunkten für die Sequenzsitzung eine Nachricht ausgetauscht wird. Bevor die Inaktivitätsauszeitperiode abläuft wird eine Nachricht zum Verifizieren der Verbindung erhalten, die einen einzigartigen Sequenzidentifizierer enthält, der zu der Sequenzsitzung gehört. Basierend auf der erhaltenen Nachricht wird ein Inaktivitätszeitgeber für die Inaktivitätsauszeitperiode zurückgesetzt, so dass die Sequenzsitzung am Leben gehalten wird.
Zusätzliche Merkmale und Vorteile der Erfindung werden in der nachfolgenden Beschreibung fortgeführt und werden in Teilen aus der Beschreibung offensichtlich oder können bei der Ausführung der Erfindung erlernt werden. Die Merkmale und Vorteile der Erfindung können mittels der Instrumente und Kombinationen, die insbesondere in den angefügten Ansprüchen dargelegt werden, realisiert und erhalten werden. Diese und andere Merkmale der vorliegenden Erfindung werden aus der nachfolgenden Beschreibung und den angehängten Ansprüchen noch vollständiger offensichtlich oder können durch die Ausführung der Erfindung erlernt werden, so wie hierin anschließend fortgeführt.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Um die Art und Weise zu beschreiben, in der die oben genannten und anderen Vorteile und Merkmale der Erfindung erlangt werden können, wird eine eingehendere Beschreibung der oben kurz beschriebenen Erfindung mit Bezug auf die spezifischen Ausführungsformen dieser durchgeführt werden, die in den beigefügten Zeichnungen dargestellt sind. Im Verständnis dessen, dass die Zeichnungen nur typische Ausführungsformen der Erfindung aufzeigen und deshalb nicht als ihren Umfang begrenzend betrachtet werden sollten, wird die Erfindung mit zusätzlicher Spezifizierung und Detaillierung durch die Verwendung der begleitenden Zeichnungen beschrieben und erklärt werden, in denen:
1A ein Computersystem zum Verifizieren und Aufrechterhalten der Verbindungslebendigkeit durch ein Verbessern von Merkmalen von einem RM-WS-Protokoll in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung darstellt;
1B eine Zeitlinie für einen Algorithmus darstellt, der zum Berechnen der Intermittiertheit oder Periodizität zum Senden von RM-WS-Protokollinfrastrukturnachrichten zum Aufrechterhalten der Verbindungslebendigkeit in Übereinstimmung mit beispielhaften Ausführungsformen der vorliegenden Erfindung verwendet werden kann;
2 ein Beispielsystem darstellt, das eine passende Betriebsumgebung für die vorliegende Erfindung zur Verfügung stellt;
3 ein Flussdiagramm eines Verfahrens zum Aufrechterhalten der Verbindungslebendigkeit in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung darstellt; und
4 ein Flussdiagramm eines Verfahrens zum Verifizieren der Verbindungslebendigkeit in Übereinstimmung mit Ausführungsbeispielen der vorliegenden Erfindung darstellt.
DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
Die vorliegende Erfindung erstreckt sich über Verfahren, Systeme und Computerprogrammprodukte für Mechanismen, welche verlässliche Nachrichtenprotokolle für Netzdienste (RM-WS) verbessern, um eine Verbindungslebendigkeit in einer Sequenzsitzung zu verifizieren und aufrechtzuerhalten. Die Ausführungsformen der vorliegenden Erfindung können einen Computer für einen speziellen Zweck oder einen Allzweckcomputer umfassen, der verschiedene Computerhardware beinhalten kann, was untenstehend detailliert diskutiert wird.
Die vorliegende Erfindung ist auf Erweiterungen von verlässlichen Nachrichtenprotokollen für Netzdienste (hierin anschließend als "RM-WS-Protokolle" bezeichnet), d. h. WS-verlässliche Nachrichtenübertragung (WS-ReliableMessaging (WS-RM)) gerichtet, die Spezifikationen beschreiben, welche es erlauben, dass eine Nachricht zuverlässig zwischen verteilten Anwendungen in der Anwesenheit von Softwarekomponenten-, System- oder Netzwerkfehlern geliefert wird. Verlässliche Nachrichtenprotokolle für Netzdienste vereinfachen die erfolgreiche Übertragung von Nachrichten von einer Quelle (hierin im Folgenden "ein Initiator") zu einem Ziel, d. h. einem Dienst (hierin nachfolgend "ein Annehmer" – "acceptor"), und stellen sicher, dass Fehlerzustände erkennbar sind. Diese Protokolle sind transportagnostisch, was ihnen erlaubt, unter Verwendung verschiedener Netzwerkübertragungstechnologien implementiert zu werden. Des Weiteren verbergen Implementierungen von verlässlichen Nachrichtenprotokollen intermittierende Kommunikationsfehler vor den Anwendungen und können im Falle von Systemfehlern für eine Wiederherstellbarkeit sorgen.
Die vorliegende Erfindung überwacht die Aktivität einer eingerichteten Sequenzsitzung zwischen zwei Endpunkten, welche als die Handlung des Empfangens von Nachrichten für diese Sequenz definiert ist. Die erhaltenen Nachrichten können Anwendungs- oder Infrastrukturnachrichten sein (d. h. Bestätigungsnachrichten in Übereinstimmung mit einem RM-WS-Protokoll). Des Weiteren definiert die vorliegende Erfindung eine Inaktivitätsauszeitperiode (Inactivity Timeout – IT), die derjenigen Zeit eine Obergrenze setzt, die ver streichen kann, ohne dass Nachrichten erhalten werden (entweder Anwendungen oder Infrastruktur) bezüglich der Sequenzsitzung. Wenn die obere Zeitgrenze erreicht wird, wird angenommen, dass der andere Endpunkt nicht vorhanden ist, und es wird angenommen, dass die Sequenz verloren ist oder verlassen wurde. Wenn eine Nachricht andererseits empfangen wird, bevor die IT abläuft, wird ein IT-Zeitgeber zurückgesetzt und die Verbindung wird verifiziert bzw. bestätigt. In einer anderen auch verwandten Ausführungsform, die auf einer identifizierten IT basiert, berechnet die vorliegende Erfindung eine Anfangszeit und eine Periodizität für das Versenden von idempotenten RM-WS-Protokoll Infrastrukturnachrichten zwischen den Endpunkten in einem Versuch, die Verbindungslebendigkeit aufrechtzuerhalten.
1A stellt ein verteiltes Computersystem 100 dar, das zur Ausübung einiger der oben beschriebenen Ausführungsbeispiele verwendet werden kann. Eine Sequenzsitzung kann zwischen einem Initiator 120 und einem Annehmer 125 in Übereinstimmung mit einem RM-WS-Protokoll eingerichtet werden. Die eingerichtete Sequenzsitzung kann mehrere oder nicht aktuelle Netzwerkverbindungen überspannen, was von dem verwendeten Transport abhängt. Des Weiteren können die Verbindungen über die Zeit unterschiedlich sein (d. h. verwende eine Verbindung jetzt und eine unterschiedliche später) und können in der Topologie unterschiedlich sein (d. h. verschiedene Transporttypen für jeden Sprung). Wenn die Nachrichten z. B. ausgetauscht werden, indem die Nachrichten auf eine Diskette (floppy disk) kopiert werden und die Disketten zwischen dem Initiator 120 und dem Annehmer 125 ausgetauscht werden, besteht keine echte physikalische Verbindung zwischen den Computern und durch eine Verbesserung der Charakteristiken von einem RM-WS-Protokoll kann die vorliegende Erfindung dennoch eine Sitzung zwischen den kommunizierenden Parteien, d. h. dem Initiator 120 und dem Annehmer 125, aufbauen.
Beachte, dass das Diskettenbeispiel für Zwecke der Darstellung gegeben wurde und kein typischer Anwendungsfall ist. Ein typischerer Anwendungsfall für "interaktive Anwendungen" ("interactive applications") wäre die Verwendung von TCP/IP, HTTP (möglicherweise überlagert über TCP/IP), UDP/IP, Leitungen oder andere Echtzeittransportmechanismen.
Ausführungsbeispiele sorgen dafür, dass der Initiator 120 vorrangig für das Aufrechterhalten der Verbindungslebendigkeit verantwortlich ist. Dementsprechend unterstützt diese Ausführungsform einen nicht adressierbaren (d. h. anonymen) Initiator 120 sowie ei nen Klienten (Client) hinter einer Schutzwand (firewall), der mit dem Annehmer 125 über Nachfrage-Antwortprotokolle, so wie SOAP über HTTP, kommuniziert. Beachte allerdings, dass in dem Fall, dass der Initiator 120 nicht adressierbar (und in einigen Fällen sogar wenn anonym) ist, entweder der Endpunkt (d. h. Initiator 120 oder Annehmer 125) die Verbindungslebendigkeit verifizieren kann, wie unten beschrieben ist. Obwohl sich die folgenden Beispiele typischerweise auf den Initiator 120 als den die Verbindungslebendigkeit aufrechterhaltenden und verifizierenden beziehen, wird dementsprechend so ein Bezug für Darstellungszwecke verwendet, der nicht dazu gedacht ist, den Umfang der vorliegenden Erfindung zu begrenzen oder auf eine andere Art und Weise einzuengen, sofern dies nicht explizit beansprucht wird.
Unbeachtet dessen, ob der Initiator 120 anonym ist oder nicht, verwendet der Initiator 120 ein Verbindungsverifikationsmodul 105, das einen Zeitgeber 110 beinhaltet, um zu verhindern, dass eine eingerichtete Sequenzsitzung wegen einer Inaktivität in der Abwesenheit von Nachrichten der Anwendung 135 oder der Infrastruktur 130 beendet wird. Basierend auf einer identifizierten Inaktivitätsauszeit (IT) zum Beispiel verwendet das Verbindungsverifikationsmodul 105 einen Algorithmus zum Initiieren eines RM-WS-Infrastrukturnachrichten-Austausches zum Verhindern einer Inaktivitätsauszeit auf beiden Seiten der Verbindung. Zum Beispiel bestimmt das Verbindungsverifikationsmodul 105 eine Zeitperiode zum Senden einer ersten Bestätigungsnachfrage-Nachricht 115 (auch bekannt als und hierin austauschbar "Lebenserhaltungs" nachricht 115 genannt) zu der anderen Seite, was die RM-WS-Bestätigungsnachfrage-Nachricht 115 verbessert (beachte, dass in dem Fall von WS-RM die Bestätigungsnachfrage-Nachricht – Ack Request verwendet werden kann) und zu einem Verwenden eines eigens angefertigten Algorithmus führt.
Beachte, dass es die Ausführungsbeispiele der IT erlauben, auf der Anwendungsebene basiert auf Dingen wie Latenzfragen, Zuverlässigkeit des Netzwerks und andere Betrachtungen einstellbar zu sein. Im Falle des obengenannten Diskettenbeispiels würde die Inaktivitätsauszeitperiode in ihrer Dauer relativ groß sein müssen, um die durch das Kommunikationsmedium eingebrachte Latenz zuzulassen, wobei andere Systeme möglicherweise relativ kurze Zeitdauern erfordern, um eine Sitzung offen zu halten, ohne Nachrichten von dem Annehmer 125 zu erhalten. Dementsprechend kann die IT auf Basis der Verbindung einstellbar sein und kann zwischen dem Initiator 120 und dem Annehmer 125 ausgehandelt werden, bevor die Sequenzsitzung eingerichtet wird und/oder kann dynamisch modifiziert werden, nachdem die Sitzung eingerichtet wurde.
Unbeachtet des IT-Wertes setzt der Annehmer 125 seinen Inaktivitätszeitgeber (nicht gezeigt) zurück, wenn der Annehmer 125 eine Bestätigungsnachfrage-Nachricht 115 erhält. Beachte, dass unbeachtet dessen, ob der Annehmer 125 eine Infrastruktur 130 (d. h. Bestätigungsnachfrage 115) oder Anwendungsebene 135 Nachricht erhält, der Inaktivitätszeitgeber zurückgesetzt werden wird. An diesem Punkt kann der Annehmer 125 die Verbindungslebendigkeit verifizieren.
Um die Verbindungslebendigkeit bei dem Initiator 120 zu verifizieren, wird der Initiator 120 es ebenso benötigen, Nachrichten für die Sequenzsitzung zu erhalten (entweder Anwendung 135 oder Infrastruktur 130). Wenn der Annehmer 125 eine Bestätigungsnachfrage-Nachricht 115 empfängt (d. h. im Falle von WS-RM sendet der Annehmer 125 eine Bestätigungsnachricht – Ack message), antwortet er dementsprechend typischerweise durch ein Versenden einer RM-WS-Bestätigungsantwort-Nachricht – Ack Response 130. Auf den Erhalt einer Bestätigungsantwort oder Bestätigung 130 hin validiert der Initiator 120 die Verbindungslebendigkeit und setzt den Inaktivitätszeitgeber 110 auf der Seite des Initiators 120 zurück und die Verbindungslebendigkeit wird aufrechterhalten. Beachte, dass, wie oben erwähnt, eine Anwendungsnachricht 135, die von dem Initiator 120 vor dem Ablauf der Inaktivitätsauszeit empfangen wird, auch den Zeitgeber 110 zurücksetzen wird. In solch einem Fall wird das Verbindungsverifikationsmodul 105 zurückgesetzt und führt eine Wiederberechnung der ursprünglichen bzw. anfänglichen Periode zum Versenden einer Bestätigungsnachfrage-Nachricht 115 durch.
Beachte des Weiteren, dass unbeachtet dessen, ob eine Nachricht (entweder Anwendung 135 oder Infrastrukturnachricht 130) von dem Initiator 120 empfangen wird oder nicht, die Sequenzsitzung wenigstens auf der Seite des Annehmers 125 verlängert wird. In dem Fall, dass der Initiator 120 anonym ist (oder unter einigen Umständen, unter denen der Initiator 120 adressierbar ist), kann es dementsprechend keine Inaktivitätsauszeit für den Initiator 120 geben. Das periodische Versenden von Bestätigungsnachfrage-Nachrichten 115 kann dementsprechend die Verbindungslebendigkeit beim Annehmer 125 verifizieren, ungeachtet dessen, ob Nachrichten von dem Initiator 120 empfangen werden oder nicht. In der Tat ist das Umgekehrte der Fall, wobei der Annehmer 125 nicht die Inaktivitätsauszeit antreibt, aber die Verbindung des Initiators 120 verlängert wird, wenn Nachrichten erhalten werden.
Es ist auch wichtig zu beachten, dass die Infrastrukturnachrichten während des Austausches nicht zuverlässig übertragen werden und zu jedem Zeitpunkt verloren gehen können. Dementsprechend kann die Bestätigungsnachfragenachricht 115 von dem Initiator 120 zu dem Annehmer 125 verloren werden. Genauso gut kann die Bestätigungsantwort 130 auf dem Weg vom Annehmer 125 zum Initiator 120 verloren werden. In solchen Fällen sorgen Ausführungsbeispiele für einen speziell eingestellten Algorithmus, der auf der Inaktivitätsauszeitperiode für das periodische Versenden der Bestätigungsfrage 115 zu dem Annehmer 125 basiert. Beachte, dass die Infrastrukturnachrichten 115, 135 idempotent sind, so dass keine Duplikationserkennung benötigt wird und eine Reihenfolge nichts ausmacht.
Das Verbindungsverifikationsmodul 105 verwendet die oben benannten speziell oder spezifisch angefertigten Algorithmen zum Auswählen der Zeiten für erstmalige oder nachfolgende periodische Versuche zum Initiieren eines Austausches, wie oben beschrieben. 1B zeigt eine beispielhafte Zeitstrahldarstellung eines möglichen Algorithmus, der zum Versenden der Lebenserhaltungs- oder Bestätigungsnachfrage-Nachrichten 115 verwendet werden kann. Wie in 1B gezeigt ist, basiert der Zeitstrahl bzw. die Zeitlinie des Algorithmus auf einem oder mehreren aus wenigstens drei Werten. Erstens die oben erwähnte Inaktivitätsauszeit (IT) 140, welche festlegt, wie lange der Initiator 120 warten wird, ohne Nachrichten von dem Annehmer 125 zu erhalten, bevor die Sequenzsitzung fehlschlägt oder verlassen wird. Als Nächstes die maximale Anzahl von Wiederholungsversuchen (Maximum Retry Count – MRC) 155, welche die Anzahl von Malen ist, die der Initiator 120 versuchen wird, eine Nachricht wieder zu versenden, bevor er aufgibt. Dies ist sowohl auf Anwendungs- als auch Infrastrukturnachrichten (d. h. Lebenserhaltungsnachrichten 115) anzuwenden. Drittens die Lebenserhaltungsablaufauszeit (Keep-Alive Expiration Timeout – KAET) 150, die als das Intervall definiert wird, das der Initiator 120 abwarten wird, ohne eine Nachricht von dem Annehmer 125 zu bekommen, bevor er damit beginnt, Lebenserhaltungsnachrichten 125 zu versenden – d. h. die KAET 150 ist ein Bruchteil (N) von der IT 140, der die ursprüngliche Zeit festlegt, Lebenserhaltungsnachrichten 115 zu versenden. In den nachfolgenden Beispielen ist N auf einen Ursprungswert von 0,5 gesetzt. Dementsprechend wird der Initiator 120 mit dem Versenden von Lebenserhaltungsnachrichten 115 beginnen, nachdem die Hälfte der IT 140 vergangen ist, ohne dass von dem Annehmer 125 eine Aktivität ausging.
Basierend auf diesen drei Werten kann ein Lebenserhaltungsintervall (Keep-Alive Interval – KAI) 145 berechnet werden – d. h. das Intervall zwischen einem sukzessiven oder periodischen Versenden von Lebenserhaltungsnachrichten 115. Zum Beispiel kann das Lebenserhaltungsintervall 145 unter Verwendung des Algorithmus KAI = IT·(1–N)/MRC berechnet werden. Die Beziehung zwischen der IT 140, der KAET 150, der MRC 155 und der KAI 145 ist dargestellt, wie in 1B gezeigt ist. Beachte, dass, obwohl ein spezifischer Algorithmus zum Definieren der KAET 150 und KAI 145 verwendet wurde, der vorliegenden Erfindung andere Algorithmen und Wege zur Verfügung stehen, um festzulegen, wann eine Bestätigungsnachfrage-Nachricht oder Lebenserhaltungsnachricht 115 zu versenden ist. Zum Beispiel kann die Periodizität (d. h. KAI 145) zum Versenden der Lebenserhaltungsnachrichten 115 beliebig gewählt werden. Dementsprechend wird die Verwendung des oben spezifizierten Algorithmus zum Festlegen dieser Werte nur für Darstellungszwecke verwendet und ist nicht dazu gedacht, das Ziel oder den Umfang der vorliegenden Erfindung zu begrenzen oder auf eine andere Art und Weise zu schmälern, solange dies nicht explizit beansprucht wird.
Trotzdem wird typischerweise der Initiator 120 die IT 140, die KAET 150 und die KAI 145 im Sinne eines periodischen Zeitgeberintervalls berechnen. Zum Beispiel, wenn die IT 140 zwei Stunden war, war die MRC 155 fünf und das periodische Zeitgeberintervall war zwei Sekunden, dann würde die KAET 150 unter Verwendung der obigen Gleichungen und Annahmen (d. h. N = 0,5) gleich einer Stunde sein und die KAI würde gleich zwölf Minuten sein. Ein Konvertieren der Werte zu Sekunden und Teilen durch das Zeitgeberintervall führt zu dem Folgenden: IT/(Zeitgeberintervall) = 7200/2 = 3600 Zeitgeberschritte bzw. -schläge (timer ticks); KAET/(Zeitgeberschritte) = 3600/2 = 1800 Zeitgeberschritte; und KAI/(Zeitgeberintervall) = 720/2 = 360 Zeitgeberschritte. Dementsprechend wird der Initiator 120 in diesem Fall nach 1800 Zeitgeberschritten mit dem Versenden von Lebenserhaltungsnachrichten 115 beginnen. Der Initiator 120 wird auch alle 360 Zeitgeberschritte eine Lebenserhaltungsnachricht versenden, bis insgesamt 3600 Schritte vergangen sind. Wenn der Initiator 120 keine Nachricht von dem Annehmer 125 während dieser Dauer erhalten hat (d. h. über das IT-Intervall), wird der Initiator 120 die Sequenzsitzung fehlschlagen lassen.
In einem alternativen Ausführungsbeispiel kann die obige Implementierung unter Verwendung von zwei Zeitgebern erreicht werden. Ein erster Zeitgeber wird mit einem Zeitintervall festgelegt, das der IT 140 gleicht. Dieser erste Zeitgeber wird zurückgesetzt, wann immer eine Nachricht von dem Annehmer 125 empfangen wird. Wenn der erste Zeitgeber bzw. -messer ohne eine Aktivität des Annehmers 125 abläuft, wird der Initiator 120 die Sequenzsitzung beenden bzw. terminieren. Der zweite Zeitgeber wird mit einem Zeitintervall festgelegt, das der KAET 150 gleicht. Wenn dieser zweite Zeitgeber abläuft, wird der Initiator 120 eine Lebenserhaltungsnachricht 115 zu dem Annehmer 125 senden und wird den zweiten Zeitgeber mit einem Zeitgeberintervall der KAI 145 zurücksetzen. Des Weiteren wird der zweite Zeitgeber mit einem Zeitintervall der KAI 145 auf die Ab- bzw. Ausläufe der nachfolgenden zweiten Zeitgeber hin zurückgesetzt (d. h. nach jedem Verstreichen der KAI 145 – Zeitintervalle ohne dem Erhalten einer Nachricht). Wann immer eine Nachricht 130, 135 von dem Annehmer 125 empfangen wird, wird der Initiator 120 den zweiten Zeitgeber mit einem Zeitintervall, das der KAET 150 gleicht, zurücksetzen und der Prozess wird wiederholt.
Beachte, dass während des Wartens auf ein Senden einer Lebenserhaltungsnachricht 115 eine Anwendungsnachricht für den Initiator 120 zum Versenden zur Verfügung gestellt werden kann. Dies kann auftreten, weil die Anwendung des Initiators 120 eine Nachricht versendet hat oder weil der Algorithmus für einen Wiederholungsversuch des Initiators 120 bestimmt hat, dass es Zeit war, eine gepufferte Anwendungsnachricht wieder zu versenden. Wenn dies auftritt, sorgen die Ausführungsbeispiele dafür, dass der Initiator 120 ein KAI 145 – Intervall (oder möglicherweise die KAET 150) neu starten wird. In anderen Worten wird der Initiator 120 eine weitere Lebenserhaltungsnachricht 115 nicht senden, bis ein Intervall der KAI 145 (oder KAET 150) vergangen ist, seitdem die Anwendungsnachricht versandt wurde. Dementsprechend wird der Initiator 120 wenigstens jedes KAI 145-Intervall irgendeine Form von Nachricht versenden, entweder Anwendung- oder Infrastrukturnachricht. Des Weiteren werden Lebenserhaltungsnachrichten 115 typischerweise sogar dann versendet, wenn Anwendungsnachrichten aus irgendeinem Grund, d. h. Netzwerkstau, blockiert werden.
Beachte, dass andere Ausführungsformen es einer Bestätigungsnachfrage-Nachricht 115 erlauben, einer gesendeten Anwendungsnachricht hinzugefügt zu werden. Diese Ausführungsform kann z. B. verwendet werden, wenn die IT 140 im Begriff ist abzulaufen, um den Annehmer 125 zu benachrichtigen, ein Versenden einer Bestätigungsant wort oder Bestätigung 130 eher zu beschleunigen als abzuwarten, eine Ladung oder einen Stapel von Nachrichten zu bestätigen. In diesem Falle würde die Bestätigungsnachfrage 115 im Allgemeinen als ein Protokollelement dargestellt werden (z. B. eine Überschrift oder ein anderer Indikator, der durch ein RM-WS-Protokoll definiert ist, z. B. WS-RM), das mit der Anwendungsnachricht 135 beinhaltet ist. Als solches sollte eine "Bestätigungsnachfragenachricht 115'' weit ausgelegt oder interpretiert werden, um Fälle miteinzuschließen, in denen die Bestätigungsnachfrage 115 ein oben beschriebenes Protokollelement ist.
Andere Ausführungsformen lassen es zu, für jede aus einer Vielzahl von Sequenzsitzungen in einer einzelnen Nachricht eine Bestätigungsnachfrage 115 entsprechend des RM-WS-Protokolls zu beinhalten (z. B. eine Anwendung oder Infrastruktur, z. B. Bestätigungsnachfrage-Nachrichten 115). Ebenso lassen andere Ausführungsformen es zu, eine Bestätigungsantwort 130 für jede aus einer Vielzahl von Sequenzsitzungen in einer einzelnen Nachricht entsprechend des RM-WS-Protokolls in einer einzelnen Nachricht zu beinhalten (z. B. Anwendung 135 oder Infrastrukturnachrichten, z. B. Bestätigungsnachricht 130). Dies erlaubt es, auf den Empfang einer einzelnen Nachricht hin die Lebendigkeit einer Vielzahl von Sequenzen zu verifizieren, wodurch die Anzahl der Nachrichten reduziert wird, die dazu benötigt werden, die Lebendigkeit einer Vielzahl von Sequenzen zwischen den gleichen Endpunkten 120, 125 aufrechtzuerhalten.
Die vorliegende Erfindung kann auch mit Begriffen von Verfahren beschrieben werden, die funktionelle Schritte und/oder nicht funktionelle Aktionen umfassen. Das Nachfolgende ist eine Beschreibung von Schritten und/oder Aktionen, die bei der Anwendung der vorliegenden Erfindung ausgeführt werden können. Üblicherweise beschreiben funktionelle Schritte die Erfindung im Sinne der Ergebnisse, die erreicht werden, wohingegen nicht funktionelle Aktionen eher spezifische Aktionen zum Erreichen eines bestimmten Ergebnisses beschreiben. Obwohl die funktionellen Schritte und/oder nicht funktionellen Aktionen in einer bestimmten Abfolge beschrieben oder beansprucht werden können, ist die vorliegende Erfindung nicht nötigerweise beschränkt auf eine bestimmte Abfolge oder Kombination von Schritten und/oder Aktionen. Des Weiteren werden die Anwendung der Schritte und/oder Aktionen in der Rezitierung der Ansprüche und der folgenden Beschreibung für die Flussdiagramme der 3 und 4 benutzt, um die gewünschte spezifische Verwendung von solchen Begriffen aufzuzeigen.
3 und 4 stellen Flussdiagrammbeispiele für verschiedene beispielhafte Ausführungsformen der vorliegenden Erfindung dar. Die folgende Beschreibung der 3 und 4 wird gelegentlich auf die entsprechenden Elemente aus den 1A und 1B Bezug nehmen. Obwohl auf ein spezifisches Element aus diesen Figuren Bezug genommen werden kann, werden solche Elemente nur für illustrative Zwecke verwendet und sind nicht dazu gedacht, den Umfang der vorlegenden Erfindung zu begrenzen oder auf eine andere Art und Weise einzuschränken, wenn dies nicht ausdrücklich beansprucht wird.
3 stellt ein Flussdiagrammbeispiel eines Verfahrens 300 zum Verifizieren der Verbindungslebendigkeit für eine Sequenzsitzung zwischen Endpunktanwendungen dar, wobei ein RM-WS-Protokoll verwendet wird. Das Verfahren 300 beinhaltet einen Schritt des Einrichtens 305 einer Sequenzsitzung zwischen zwei Endpunkten. Zum Beispiel kann eine Sequenzsitzung zwischen einem Initiator 120 und einem Annehmer 125 in Übereinstimmung mit einem RM-WS-Protokoll (z. B. WS-verlässliche Benachrichtigung) eingerichtet werden. Das Verfahren 300 beinhaltet des Weiteren einen Schritt des Identifizierens 310 einer Inaktivitätsauszeit. Zum Beispiel kann ein Verbindungsverifikationsmodul 105 verwendet werden, um die Inaktivitätsauszeit (IT) 140 zu erkennen, wobei die Inaktivitätsauszeitperiode eine obere Zeitgrenze darstellt, die vergehen kann, ohne dass eine Nachricht zwischen dem Initiator 120 und dem Annehmer 125 für die Sequenzsitzung ausgetauscht wird. Diese IT 140 kann einstellbar sein, um solche Dinge wie die durch das Kommunikationsmedium oder das Wissen um die Zuverlässigkeit des zugrundeliegenden Netzwerkes eingebrachte Latenz zuzulassen.
Bevor eine Inaktivitätsauszeitperiode abläuft, beinhaltet das Verfahren 300 einen Schritt bzw. eine Aktion des Empfangens 315 einer Nachricht, die einen einzigartigen Sequenzidentifizierer enthält. Zum Beispiel kann entweder der Initiator 120 oder der Annehmer 125 eine Nachricht zum Verifizieren der Verbindungslebendigkeit erhalten, wobei die Nachricht einen einzigartigen Sequenzidentifizierer enthält, der zu der Sequenzsitzung gehört. Die empfangene Nachricht, die den einzigartigen Sequenzidentifizierer enthält, kann eine Anwendungsnachricht 135 sein. Alternativ kann die empfangene Nachricht eine Infrastrukturnachricht 115, 130 sein. Zum Beispiel wenn die Nachricht von dem Initiator 120 empfangen wird, kann die Nachricht eine Bestätigung 130 als Antwort auf eine Bestätigungsanfrage 115 sein, die zuvor von dem Initiator 120 versendet wurde. Wenn die Nachricht von dem Annehmer 125 empfangen wird, dann kann die Nachricht eine Sequenzbestätigungsnach frage 115 sein. Unbeachtet dessen, ob die Nachrichten Anwendungsebene- oder Infrastrukturnachrichten sind, erlauben es andere Ausführungsformen einer einzelnen Nachricht, Bestätigungsnachfragen (z. B. Bestätigungsnachfrage 115) oder Bestätigungen (z. B. Bestätigung 130) für eine Vielzahl von Sequenzsitzungen zu beinhalten. Zusätzlich wird die Bestätigungsnachfrage 115 typischerweise in ein Protokollelement mitaufgenommen, z. B. eine Überschrift oder ein anderes Feld der Nachricht, im Falle, dass die Bestätigungsnachfrage 115 in einer Nachricht auf Anwendungsebene enthalten ist.
Basierend auf der empfangenen Nachricht beinhaltet das Verfahren 300 des Weiteren einen Schritt des Zurücksetzens 320 eines Inaktivitätszeitgebers. Zum Beispiel kann der Initiator 120 den Zeitgeber 110 innerhalb des Verbindungsverifikationsmoduls 105 zurücksetzen, wenn die Nachricht im Initiator empfangen wird. Eine Inaktivitätsauszeitperiode kann dann erneut bzw. wiederholt berechnet werden und der Prozess wird wiederholt. Wenn keine Anwendungs- oder Infrastrukturnachrichten nach dem Zurücksetzen des Inaktivitätszeitgebers empfangen werden, kann die Sequenzsitzung vor dem Ablauf der Inaktivitätsauszeitperiode verlassen werden.
Die 4 zeigt ein Flussdiagramm eines Verfahrens 400 zum Aufrechterhalten einer Verbindungslebendigkeit durch einen Initiator für eine Sequenzsitzung zwischen Endpunkten, wobei ein RM-WS-Protokoll verwendet wird. Das Verfahren 400 beinhaltet einen Schritt des Einrichtens 305 einer Sequenzsitzung zwischen zwei Endpunkten. Zum Beispiel kann eine durch einen einzigartigen Sequenzidentifizierer identifizierte Sequenzsitzung zwischen einem Initiator 120 und einem Annehmer 125 in Übereinstimmung mit einem RM-WS-Protokoll (z. B. WS-verlässliches Benachrichtigen) errichtet werden. Um die Sequenzsitzung zu errichten, wird der Initiator 120 typischerweise eine Nachfrage zur Einrichtung von einer oder mehreren Sequenzsitzungen in Übereinstimmung mit einem RM-WS-Protokoll an den Annehmer 125 senden. Basierend auf dieser Nachfrage kann der Annehmer 125 einen oder mehrere einzigartige Sequenzidentifizierer generieren (z. B. einen globalen einzigartigen Identifizierer, Global Unique Identifier – GUID), der dazu verwendet werden wird, die erschaffene Sequenzsitzung bzw. die Sitzungen zu identifizieren.
Auch ist zu beachten, dass andere Wege des Errichtens einer Sequenzsitzung der vorliegenden Erfindung zur Verfügung stehen. Zum Beispiel kann der Initiator 120 den oder die einzigartigen Sequenzidentifizierer generieren und sie in der Nachfrage zum Erschaffen der Sequenzsitzung bzw. der Sitzungen an den Annehmer 125 senden. In der Tat gibt es viele andere wohlbekannte Wege zum Einrichten einer Sequenzsitzung, die der vorliegenden Erfindung zur Verfügung stehen. Dementsprechend wird jeder spezifische Bezug darauf, wie eine Sequenzsitzung errichtet wird, nur für Darstellungszwecke verwendet und ist nicht dazu gedacht, den Umfang der vorliegenden Erfindung zu begrenzen oder anderweitig zu schmälern, soweit dies nicht ausdrücklich beansprucht wird.
Unbeachtet dessen, wie die Sequenzsitzung eingerichtet wurde, beinhaltet das Verfahren 400 des Weiteren einen Schritt des Identifizierens 415 einer Inaktivitätsauszeitperiode für die Sequenzsitzung. Zum Beispiel kann ein Verbindungsverifikationsmodul 105 eine Inaktivitätsauszeit (IT) erkennen, die eine obere Zeitgrenze für die Zeit darstellt, die vergehen darf, ohne dass eine Nachricht für die Sequenzsitzung empfangen wird. Diese IT 140 kann basierend auf solchen Dingen wie der Zuverlässigkeit des Transportnetzwerkes oder anderen Berücksichtigungen, so wie eine minimale erwartete Latenz zum Empfangen einer Bestätigung, einstellbar sein.
Das Verfahren 400 beinhaltet des Weiteren einen Schritt des Berechnens 417 einer Lebenserhaltungsablaufauszeit. Zum Beispiel kann das Verbindungsverifikationsmodul 105 einen Algorithmus verwenden, der auf der Inaktivitätsauszeitperiode 140 zum Berechnen einer Lebenserhaltungsablaufauszeit 150 (keep alive expiration time – KAET) basiert, die typischerweise ein Bruchteil einer Intervallauszeit 140 ist. Basierend auf der berechneten Lebenserhaltungsablaufauszeit beinhaltet das Verfahren 400 des Weiteren einen Schritt des Versendens einer Nachricht, die einen einzigartigen Sequenzidentifizierer beinhaltet. Die Nachricht kann eine Infrastrukturnachricht (z. B. Bestätigungsnachfrage 115) oder eine Anwendungsnachricht 135 sein. Zum Beispiel kann ein Initiator 120 auf den Ablauf der KAET 150 hin eine Bestätigungsnachfragenachricht 115 verwenden, die eine idempotente Infrastrukturnachricht ist, die durch das RM-WS-Protokoll definiert ist. Unbeachtet dessen, ob die gesendete Nachricht eine Nachricht auf Anwendungsebene oder eine Infrastrukturnachricht ist, lassen andere Ausführungsformen es zu, dass die Nachricht Bestätigungsnachfragen (z. B. Bestätigungsnachfrage 115) für eine Vielzahl von Sequenzsitzungen beinhaltet.
Als Nächstes beinhaltet das Verfahren 400 den Schritt des Empfangens 422 einer Nachricht, die einen einzigartigen Sequenzidentifizierer beinhaltet. Das heißt, dass der Initiator 120 eine Bestätigungsantwort 130 oder eine Anwendungsnachricht 135 von dem Annehmer 125 erhält, die einen einzigartigen Sequenzidentifizierer beinhaltet. Wenn die Nachricht (Infrastruktur- oder Anwendungsnachricht, z. B. 130, 135) vor der Inaktivitätsaus zeitperiode 140 empfangen wird, wird die Verbindungslebendigkeit der Sequenzsitzung aufrechterhalten. Basierend auf der empfangenen Nachricht beinhaltet das Verfahren 400 des Weiteren einen Schritt des Zurücksetzens 425 eines Inaktivitätszeitgebers. Das heißt, basierend auf der erhaltenen Bestätigungsantwort 130 oder Anwendungsnachricht 135 kann der Inaktivitätszeitgeber 110 innerhalb des Verbindungsverifikationsmoduls 105 für die Inaktivitätsauszeit 140 zurückgesetzt werden, so dass die Sequenzsitzung am Leben gehalten wird.
Es ist auch zu beachten, dass die empfangene Nachricht eine Nachricht auf Anwendungsebene sein könnte. In solch einem Fall kann eine Bestätigungsantwort 130 in der Nachricht auf Anwendungsebene enthalten sein. Unbeachtet dessen, ob die erhaltene Nachricht eine Nachricht auf Anwendungsebene oder Infrastrukturebene ist, können andere Ausführungsformen es zulassen, dass die Nachricht Bestätigungen (z. B. Bestätigung 130) für eine Vielzahl von Sequenzsitzungen beinhaltet.
Es ist auch zu beachten, dass die Bestätigungsnachfrage-Nachricht 115 zu Nachrichten gehören kann, die bereits bestätigt wurden, als sie vom Annehmer 125 empfangen wurden. In anderen Worten kann die Bestätigungsnachfrage-Nachricht 115 sogar dann gesendet werden, wenn alle Nachrichten als empfangen bestätigt wurden. Des Weiteren können zu dem Annehmer zu versendende Anwendungsnachrichten blockiert werden, aber die Bestätigungsnachfrage-Nachricht 115 sollte sowieso gesendet werden.
Es ist weiter zu beachten, dass der Algorithmus zum Berechnen der KAET 150 auf einem Bruchteil (N) der Inaktivitätsauszeit 140 basiert ist. Zum Beispiel kann der Bruchteil der Inaktivitätsauszeit 140, der zum Berechnen der KAET 150 verwendet wird, eine Hälfte der Inaktivitätsauszeit 140 sein, so dass eine ursprüngliche Bestätigungsnachfrage- oder Lebenserhaltungsnachricht 115 verwendet wird, wenn ein Inaktivitätszeitgeber 110 eine Hälfte der IT 140 erreicht. Des Weiteren sorgen Ausführungsbeispiele für eine Erkennung einer maximalen Wiederholungsversuchszählung (Maximum Retry Count – MRC) 155, die eine maximale Anzahl von Malen darstellt, die Anwendungs- und Infrastrukturnachrichten 115 noch einmal versendet werden. Basierend auf der maximalen Wiederholungsversuchszählung 155 kann ein Lebenserhaltungsintervall (keep alive interval – KAI) 145 berechnet werden, das die Zeitperiode zum Versenden von Nachrichten darstellt. Dementsprechend werden eine oder mehrere Nachrichten versendet, die auf der berechneten KAI 145 basieren, wobei die versendeten Nachrichten die Bestätigungsnachfrage-Nachricht 115 beinhal ten sollten. Selbstverständlich können die versendeten, auf der KAI 145 basierenden Nachrichten, wie oben beschrieben ist, Anwendungsnachrichten sein. Des Weiteren ist zu beachten, dass die Inaktivitätsauszeit 140 basierend auf einer festgelegten Zuverlässigkeit eines Transportnetzwerkes oder anderen Überlegungen einstellbar ist.
Ausführungsformen innerhalb des Umfanges der vorliegenden Erfindung enthalten auch computerlesbare Medien zum Tragen oder zum Speichern von computerausführbaren Instruktionen oder Datenstrukturen, die darauf gespeichert sind. Solche computerlesbaren Medien können jegliche verfügbaren Medien sein, die einem Allzweckcomputer oder einem Computer für spezielle Zwecke zugänglich sind. Zum Zwecke eines Beispiels, aber nicht als Einschränkung, können solche computerlesbaren Medien ein RAM, ROM, EEPROM, eine CD-ROM oder andere optische Speicherplatten (optical discs), magnetische Speicherplatten (magnetic disc storage) oder andere magnetische Speichervorrichtungen oder irgendein anderes Medium, das zum Tragen oder Speichern von gewünschten Mitteln eines Programmcodes in der Form von computerausführbaren Instruktionen oder Strukturen sein, die für einen Allzweckcomputer oder Computer für spezielle Zwecke zugänglich sein können. Wenn Informationen über ein Netzwerk oder andere Kommunikationsverbindungen (entweder kabelgebunden, kabellos oder eine Kombination von kabelgebundenen oder kabellos) zu einem Computer übertragen oder ihm zur Verfügung gestellt werden, betrachtet der Computer diese Verbindung eigentlich als computerlesbares Medium. Folglich wird jede einer solcher Verbindungen eigentlich als ein computerlesbares Medium bezeichnet. Kombinationen des Obengenannten sollten auch innerhalb des Umfangs von computerlesbaren Medien enthalten sein. Computerausführbare Instruktionen beinhalten zum Beispiel Instruktionen und Daten, die einen Allzweckcomputer, einen Computer für spezielle Zwecke oder Vorrichtungen für spezielle Verarbeitungen dazu veranlassen, eine bestimmte Funktion oder eine Gruppe von Funktionen auszuführen.
Die 2 und die folgende Diskussion sind dazu gedacht, eine kurze, generelle Beschreibung einer passenden Computerumgebung zur Verfügung zu stellen, in der die Erfindung implementiert werden kann. Obwohl dies nicht benötigt wird, wird die Erfindung in dem allgemeinen Kontext computerausführbarer Instruktionen, so wie Programmmodulen, die von Computern in einer Netzwerkumgebung ausgeführt werden, beschrieben werden. Generell beinhalten Programmmodule Routinen, Programme, Objekte, Komponenten, Datenstrukturen etc., die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Computerausführbare Instruktionen, assoziierte Datenstrukturen und Programmmodule repräsentieren Beispiele von Programmiercodemitteln zum Ausführen von Schritten von den hierin offenbarten Verfahren. Die bestimmte Sequenz bzw. Abfolge von solchen ausführbaren Instruktionen oder assoziierten Datenstrukturen repräsentiert Beispiele von korrespondierenden Schritten oder Aktionen zum Implementieren der Funktionen, die in solchen Schritten beschrieben sind.
Fachmänner werden Verständnis dafür haben, dass die Erfindung Computernetzwerkumgebungen mit vielen Arten von Computersystemkonfigurationen ausgeführt werden kann, die Personalcomputer, in der Hand gehaltene Vorrichtungen (hand-held devices), Multiprozessorsysteme, mikroprozessorbasierte oder programmierbare Konsumentenelektronik, Netzwerk PCs, Minicomputer, Mainframe-Computer bzw. Haupt- oder Großrechner oder Ähnliches sein können. Die Erfindung kann auch in einer verteilten Computerumgebung angewendet werden, wobei die Aufgaben bei lokalen und abseits liegenden Bearbeitungsvorrichtungen durchgeführt werden können, die durch ein Kommunikationsnetzwerk verbunden sind (entweder durch Kabelverbindung, kabellose Verbindungen oder durch eine Kombination von kabelgebundenen- und kabellosen Verbindungen). In einer verteilten Computerumgebung können sich Programmmodule sowohl in lokalen als auch abseits liegenden Speichervorrichtungen befinden.
Mit Bezug auf die 2 beinhaltet ein beispielhaftes System zur Implementierung der Erfindung eine Computervorrichtung für allgemeine Zwecke in Form eines konventionellen Computers 220, der eine Prozessoreinheit 221, einen Systemspeicher 222 und eine Systemdatenübertragungseinrichtung (system bus) 223 beinhaltet, die verschiedene Systemkomponenten miteinander verbindet, was eine Verbindung des Systemspeichers 222 mit der Prozessoreinheit 221 beinhaltet. Die Datenübertragungseinrichtung 223 kann eine von mehreren verschiedenen Datenübertragungsstrukturen sein, was eine Speicherübertragungseinrichung (memory bus) oder eine Speicherkontrolleinrichtung, eine periphere Datenübertragungseinrichtung und eine lokale Datenübertragungseinrichtung unter Verwendung einer Vielzahl von Datenübertragungseinrichtungsarchitekturen (Bus-Architekturen) beinhaltet. Der Systemspeicher beinhaltet einen nur lesbaren Speicher (Read Only Memory – ROM) 224 und einen Speicher für beliebige Zugriffe (Random Access Memory – RAM) 225. Ein Basisein- und Ausgabesystem (Basic Input/Output System – BIOS) 226, das die Basisroutinen beinhaltet, die zum Transfer von Informationen zwischen den Elementen in nerhalb des Computers 220 verhilft, so wie während des Startprozesses, der in dem ROM 224 gespeichert sein kann.
Der Computer 220 kann auch einen magnetischen Festplattenspeicher 227 beinhalten, von dem auf einer magnetischen Festplatte 239 gelesen und gespeichert werden kann, so wie ein magnetischen Laufwerk 228, um von entnehmbaren magnetischen Scheiben bzw. Platten 229 zu lesen oder diese zu beschreiben und ein optisches Laufwerk 30, um auf entnehmbaren optischen Scheiben 231 so wie CD-ROMs oder anderen optischen Medien zu lesen oder diese zu beschreiben. Das magnetische Festplattenlaufwerk 227, das magnetische Laufwerk 228 und das optische Laufwerk 30 sind mit der Systemdatenübertragungseinrichtung 223 jeweils über eine Festplattenschnittstelle 232, eine Magnetscheibenlaufwerksschnittstelle 233 und eine optische Laufwerksschnittstelle verbunden. Die Laufwerke und die assoziierten computerlesbaren Medien sorgen für eine nicht flüchtige Speicherung von von einem Computer ausführbaren Instruktionen, Datenstrukturen, Programmmodulen und anderen Daten für den Computer 220. Obwohl das Ausführungsbeispiel, das hierin beschrieben wird, eine magnetische Festplatte 239, eine entnehmbare magnetische Scheibe 229 und entnehmbare optische Scheiben 231 verwendet, können andere Typen von computerlesbaren Medien zum Speichern von Daten verwendet werden, die magnetische Kassetten, Flash-Speicherkarten, digital vielseitig einsetzbare Scheiben (digital versatile disks – DVD), Bernoulli Magazine (Bernoulli cartridges), RAMs, ROMs und Ähnliches beinhalten.
Programmcodemittel umfassen ein oder mehrere Programmmodule, die auf der Festplatte 239, der magnetischen Scheibe 229, der optischen Scheibe 231, dem ROM 224 oder RAM 225 gespeichert sein können und beinhalten ein Betriebssystem 235, ein oder mehrere Anwendungsprogramme 236, andere Programmmodule 237 und Programmdaten 238. Ein Anwender kann Befehle und Informationen über eine Tastatur 240, eine Anzeigevorrichtung 242 oder andere Eingabevorrichtungen (nicht gezeigt), so wie ein Mikrofon, einen Steuerknüppel, eine Spielesteuerungsvorrichtung (game pad), eine Satellitenschüssel, einen Scanner oder Ähnliches in den Computer eingeben. Diese und andere Eingabevorrichtungen sind oft durch eine mit der Systemdatenübertragungseinrichtung 223 verbundene serielle Anschlussschnittstelle (serial Port) 246 mit der Prozessoreinheit 221 verbunden. Alternativ können die Eingabevorrichtungen bzw. Geräte über andere Schnittstellen, so wie einen parallelen Anschluss (parallel port), einen Spieleanschluss (game port) oder eine uni verselle serielle Datenübertragungseinrichtung (Universal Serial Bus – USB) verbunden sein. Ein Monitor 247 oder andere Anzeigevorrichtungen sind auch mit der Systemdatenübertragungseinrichtung 223 über eine Schnittstelle, so wie einem Videoadapter 248, verbunden. Zusätzlich zu dem Monitor, erhalten Personalcomputer typischerweise andere periphere Ausgabegeräte (nicht gezeigt), so wie Lautsprecher und Drucker.
Der Computer 220 kann in einer Netzwerkumgebung betrieben werden, die logische Verbindungen zu einem oder mehreren fernabliegenden (remote) Computern, so wie der fernabliegende Computer 249a und 249b, verbunden sein. Fernabliegende Computer 249a und 249b können jeweils ein anderer Personalcomputer, ein Server, ein Verteiler (Router), ein Netzwerk-PC, ein gleichrangiger Verbindungspartner (peer device) oder andere allgemeine Netzwerkknoten sein und beinhalten typischerweise viele oder alle von den Elementen, die oben mit Bezug auf den Computer 220 beschrieben wurden, obwohl nur Speichervorrichtungen 250a und 250b und ihre assoziierten Anwendungsprogramme 236a und 236b in der 2 dargestellt wurden. Die logischen Verbindungen, die in 2 dargestellt sind, beinhalten ein lokales Netzwerk (Local Area Network – LAN) 251 und ein weiträumiges Netzwerk (Wide Area Network – WAN) 252 und sind hier beispielhaft und nicht limitierend dargestellt. Solche Netzwerkumgebungen sind alltäglich in büroweiten oder betriebsweiten Computernetzwerken, internen Netzwerken (Intranets) und dem Internet.
Wenn der Computer 220 in einer LAN-Netzwerkumgebung verwendet wird, ist der Computer mit dem lokalen Netzwerk 251 über eine Netzwerkschnittstelle oder einen Adapter 253 verbunden. Wenn der Computer in einer WAN-Netzwerkumgebung verwendet wird, kann der Computer ein Modem 254, eine kabellose Verbindung oder andere Mittel zur Errichtung einer Kommunikation über ein weitflächiges Netzwerk 252, so wie das Internet, beinhalten. Das Modem 254, das intern oder extern sein kann, ist mit der Systemdatenübertragungseinrichtung 223 über die serielle Anschlussschnittstelle 246 verbunden. In einer vernetzten Umgebung können als zu dem Computer 220 gehörende oder als Teile davon dargestellte Programmmodule in der fernabliegenden Speichervorrichtung gespeichert sein. Es wird offensichtlich sein, dass die gezeigten Netzwerkverbindungen beispielhaft sind und dass andere Mittel zur Errichtung einer Kommunikation über ein großflächiges bzw. weiträumiges Netzwerk 252 verwendet werden können.
Die vorliegende Erfindung kann in anderen spezifischen Formen ausgeführt werden, ohne von ihren essentiellen Charakteristiken abzuweichen. Die beschriebenen Ausfüh rungsformen sind in allen Bezügen nur als darstellend und nicht als einschränkend zu betrachten. Der Umfang der Erfindung ist dementsprechend mehr durch die angehängten Ansprüche als durch die vorangegangene Beschreibung dargestellt. Alle Veränderungen, die innerhalb der Bedeutung und in die Reichweite des Äquivalenzbereichs der Ansprüche kommen, sind in ihren Umfang mitaufzunehmen.

Claims

Verfahren zum Aufrechterhalten einer Verbindungslebendigkeit für eine Sequenzsitzung zwischen Endpunkten durch Verwenden eines verlässlichen Nachrichtenprotokolls (RM) für Netzdienste (WS), im Folgenden RM-WS-Protokoll genannt, bei einem Initiator-Computersystem in einer WS-Umgebung, das Verfahren umfassend die Schritte: Einrichten einer Sequenzsitzung, die durch einen einzigartigen Sequenzidentifizierer identifiziert wird, auf einer Anwendungsebene zwischen zwei Endpunktanwendungen in Übereinstimmung mit einem RM-WS-Protokoll; Identifizieren einer Inaktivitätsauszeitperiode für die Sequenzsitzung, wobei die Inaktivitätsauszeitperiode eine obere Zeitgrenze für die Zeit darstellt, die ohne ein Empfangen einer Nachricht für die Sequenzsitzung vergehen darf; Empfangen einer Nachricht, die den einzigartigen Sequenzidentifizierer beinhaltet, vor der Inaktivitätsauszeitperiode, die die Verbindungslebendigkeit aufrechterhält; und basierend auf der empfangenen Nachricht, Zurücksetzen eines Inaktivitätszeitgebers für die Inaktivitätsauszeitperiode, so dass die Sequenzsitzung am Leben gehalten wird, gekennzeichnet durch ein Berechnen einer Lebenserhaltungsablaufauszeit in Übereinstimmung mit einem Algorithmus, der auf der Inaktivitätsauszeitperiode basiert; ein Versenden einer Nachricht basierend auf der berechneten Lebenserhaltungsablaufauszeit, die den einzigartigen Sequenzidentifizierer beinhaltet.
Das Verfahren nach Anspruch 1, worin die empfangene Nachricht, die den einzigartigen Sequenzidentifizierer beinhaltet, eine Applikationsebenennachricht ist.
Das Verfahren nach Anspruch 2, worin die Applikationsebenenachricht Bestätigungsantworten für eine oder mehrere Sequenzsitzungen beinhaltet.
Das Verfahren nach Anspruch 1, worin die versendete Nachricht, die den einzigartigen Sequenzidentifizierer beinhaltet, eine Bestätigungsnachfragenachricht ist, die eine durch das RM-WS-Protokoll definierte infrastruktur-idempotente Nachricht ist, und worin die empfangene Nachricht eine Infrastrukturbestätigungsnachricht als Antwort auf die Bestätigungsnachfragenachricht ist.
Das Verfahren nach Anspruch 4, worin die Bestätigungsnachfragenachricht zu einer oder mehreren Nachrichten entspricht, die bereits von einem Annehmer als empfangen bestätigt wurden.
Das Verfahren nach Anspruch 4, worin die Bestätigungsnachfragenachricht Bestätigungsnachfragen für eine Vielzahl von Sequenzsitzungen beinhaltet, und worin die empfangene Nachricht eine Vielzahl von Bestätigungsantworten für die Vielzahl von Sequenzsitzungen beinhaltet.
Das Verfahren nach Anspruch 1, worin der Initiator nicht adressierbar ist und der Initiator mit einem Annehmer durch SOAP über HTTP kommuniziert.
Das Verfahren nach Anspruch 1, worin die versendete Nachricht, die den einzigartigen Sequenzidentifizierer beinhaltet, eine Bestätigungsnachfragenachricht ist, die eine durch das RM-WS-Protokoll definierte idempotente Infrastrukturnachrichten ist, und worin zu einem Annehmer zu versendende Anwendungsnachrichten blockiert werden, aber die Bestätigungsnachfragenachrichten trotzdem versendet wird.
Das Verfahren nach Anspruch 1, worin der Algorithmus zum Berechnen der Lebenserhaltungsablaufauszeit des Weiteren auf einem Bruchteil der Inaktivitätsauszeitperiode basiert.
Das Verfahren nach Anspruch 9, worin die versendete Nachricht, die den einzigartigen Sequenzidentifizierer beinhaltet, eine Bestätigungsnachfragenachricht ist, der eine durch das RM-WS-Protokoll definierte infrastruktur-idempotente Nachricht ist, und worin der Bruchteil der Inaktivitätsauszeitperiode, der zum Berechnen der Lebenserhaltungsablaufauszeit verwendet wird, eine Hälfte der Inaktivitätsauszeitperiode ist, so dass die Bestätigungsnachfragenachricht gesendet wird, wenn der Inaktivitätszeitgeber eine Hälfte der Inaktivitätsauszeitperiode erreicht.
Das Verfahren nach Anspruch 9, des Weiteren beinhaltend die Schritte: Identifizieren einer maximale Wiederholungsversuchsanzahl, die eine maximale Anzahl von Malen ist, die Applikations- und Infrastrukturnachrichten versendet werden; und Berechnen eines Lebenserhaltungsintervalls, basierend auf der maximalen Wiederholungsversuchsanzahl, wobei das Lebenserhaltungsintervall eine Zeitperiode zum Versenden von Nachrichten repräsentiert; und Versenden einer oder mehrerer Nachrichten, die den einzigartigen Sequenzidentifizierer beinhalten, basierend auf dem berechneten Lebenserhaltungsintervall, worin die eine oder die mehreren versendeten Nachrichten wenigstens eine von einer Applikationsebenenachricht oder einer Bestätigungsnachfragenachricht beinhalten.
Das Verfahren nach Anspruch 11, worin die Inaktivitätsauszeitperiode einstellbar ist, um eine durch das Kommunikationsmedium auferlegte Latenz zuzulassen.
Das Verfahren nach Anspruch 11, worin das RM-WS-Protokoll WSReliableMessaging ist.
Das Verfahren nach Anspruch 1, worin die versendete Nachricht eine Anwendungsebenennachricht ist.
Das Verfahren nach Anspruch 14, worin eine Bestätigungsnachfragenachricht mit der Anwendungsebenenachricht versendet wird, wobei die Bestätigungsnachfragenachricht eine durch das RM-WS-Protokoll definierte Infrastruktur-idempotente Nachricht ist und dazu verwendet wird, die Bestätigungsantwort von einem Annehmer voranzutreiben.
Das Verfahren nach Anspruch 1, worin nach dem Ablauf der Inaktivitätsauszeitperiode keine Anwendungs- oder Infrastrukturnachricht erhalten wird und die Sequenzsitzung verlassen wird.
Ein Verfahren zum Verifizieren einer Verbindungslebendigkeit für eine Sequenzsitzung zwischen Endpunktanwendungen durch ein Verwenden eines verlässlichen Nachrichtenprotokolls (RM) für Netzdienste (WS), im Folgenden als RM-WS-Protokoll bezeich net, auf einem Computersystem in einer WS-Umgebung, das Verfahren umfassen die Schritte: Einrichten einer Sequenzsitzung, die durch einen einzigartigen Sequenzidentifizierer identifiziert wird, auf einer Anwendungsebene zwischen zwei Endpunktanwendungen in Übereinstimmung mit einem RM-WS-Protokoll; Identifizieren einer Inaktivitätsauszeitperiode, wobei die Inaktivitätsauszeitperiode eine obere Zeitgrenze für die Zeit darstellt, die vergehen darf, ohne dass eine Nachricht für die Sequenzsitzung zwischen den beiden Endpunkten ausgetauscht wird; Erhalten einer Nachricht zum Verifizieren der Verbindungslebendigkeit bevor die Inaktivitätsauszeitperiode abläuft, wobei die Nachricht einen einzigartigen Sequenzidentifizierer beinhaltet, der zu der Sequenzsitzung gehört; und basierend auf der erhaltenen Nachricht, Zurücksetzen eines Inaktivitätszeitgebers für die Inaktivitätsauszeitperiode beinhaltet, so dass die Sequenzsitzung am Leben gehalten wird.
Das Verfahren nach Anspruch 17, worin die erhaltene Nachricht, die den einzigartigen Sequenzidentifizierer beinhaltet, eine Anwendungsnachricht ist.
Das Verfahren nach Anspruch 18, worin die Anwendungsnachricht Bestätigungsantworten für eine oder mehrere Sequenzsitzungen beinhaltet, die zu dem einzigartigen Sequenzidentifizierer gehörende Sequenzsitzung miteingeschlossen.
Das Verfahren nach Anspruch 17, worin die erhaltene Nachricht von einem Initiator der Sequenzsitzung erhalten wird, und worin die erhaltene Nachricht eine Infrastrukturbestätigungsnachricht als Antwort auf die zuvor von dem Initiator versendete Bestätigungsnachfragenachricht ist.
Das Verfahren nach Anspruch 20, worin die Infrastrukturbestätigungsnachricht Bestätigungen für eine Vielzahl von Sequenzsitzungen zwischen dem Initiator und dem Annehmer beinhaltet.
Das Verfahren nach Anspruch 20, worin der Initiator nicht adressierbar ist und der Initiator mit einem Annehmer durch SOAP über HTTP kommuniziert.
Das Verfahren nach Anspruch 17, worin die erhaltene Nachricht von einem Annehmer von der Sequenzsitzung erhalten wird, und wobei die erhaltene Nachricht eine Sequenzbestätigungsnachfrage ist.
Das Verfahren nach Anspruch 17, worin die Inaktivitätsauszeitperiode einstellbar ist, um eine von dem Kommunikationsmedium auferlegte Latenz zuzulassen.
Das Verfahren nach Anspruch 17, worin nach dem Zurücksetzen des Inaktivitätszeitgebers nach dem Ablauf der Inaktivitätsauszeitperiode keine Anwendungs- oder Infrastrukturnachrichten empfangen werden und die Sequenzsitzung verlassen wird.
Ein Computerprogrammprodukt zum Implementieren eines Verfahrens zum Aufrechterhalten einer Verbindungslebendigkeit für eine Sequenzsitzung zwischen Endpunkten durch das Verwenden eines verlässlichen Nachrichtenprotokolls (RM) für Netzdienste (WS), im Folgenden RM-WS-Protokoll genannt, auf einem Initiatorcomputersystem in einer WS-Umgebung, wobei das Computerprogrammprodukt ein oder mehrere computerlesbare Medien umfasst, die computerausführbare Anweisungen auf sich gespeichert haben, die, wenn sie durch einen Prozessor ausgeführt werden, das Benachrichtigungssystem veranlassen, das Folgende auszuführen: Einrichten einer Sequenzsitzung, die durch einen einzigartigen Sequenzidentifizierer identifiziert wird, auf einer Anwendungsebene zwischen zwei Endpunktanwendungen in Übereinstimmung mit einem RM-WS-Protokoll; Identifizieren einer Inaktivitätsauszeitperiode für die Sequenzsitzung, wobei die Inaktivitätsauszeitperiode eine obere Zeitgrenze für die Zeit darstellt, die ohne ein Empfangen einer Nachricht für die Sequenzsitzung vergehen darf; Empfangen einer Nachricht, die den einzigartigen Sequenzidentifizierer beinhaltet, vor der Inaktivitätsauszeitperiode, wobei die Nachricht die Verbindungslebendigkeit aufrechterhält; und basierend auf der empfangenen Nachricht, Zurücksetzen eines Inaktivitätszeitgebers für die Inaktivitätsauszeitperiode, so dass die Sequenzsitzung am Leben gehalten wird, gekennzeichnet durch Berechnen einer Lebenserhaltungsablaufauszeit in Übereinstimmung mit einem Algorithmus, der auf der Inaktivitätsauszeitperiode basiert; basierend auf der berechneten Lebenserhaltungsablaufauszeit, Versenden einer Nachricht, die den einzigartigen Sequenzidentifizierer beinhaltet.
Das Computerprogrammprodukt nach Anspruch 26, worin die empfangene Nachricht, die den einzigartigen Sequenzidentifizierer beinhaltet, eine Applikationsebenennachricht ist.
Das Computerprogrammprodukt nach Anspruch 26, worin die versendete Nachricht, die den einzigartigen Sequenzidentifizierer beinhaltet, eine Bestätigungsnachfragennachricht ist, die eine durch das RM-WS-Protokoll definierte infrastruktur-idempotente Nachricht ist, und worin die empfangene Nachricht eine Infrastrukturbestätigungsnachricht als Antwort auf die Bestätigungsnachfragenachricht ist.
Das Computerprogrammprodukt nach Anspruch 26, worin die Bestätigungsnachfragenachricht zu einer oder mehreren Nachrichten gehört, die bereits von einem Annehmer als empfangen bestätigt wurden.
Das Computerprogrammprodukt nach Anspruch 26, worin der Initiator nicht adressierbar ist und mit dem Annehmer durch SOAP über HTTP kommuniziert.
Das Computerprogrammprodukt 26, worin die versendete Nachricht, die den einzigartigen Sequenzidentifizierer beinhaltet, eine Bestätigungsnachfragenachricht ist, die eine durch das RM-WS-Protokoll definierte infrastruktur-idempotente Nachricht ist, und worin zu einem Annehmer zu versendende Anwendungsnachricht blockiert werden, aber die Bestätigungsnachfragenachricht trotzdem versendet wird.
Das Computerprogrammprodukt nach Anspruch 26, worin der Algorithmus zum Berechnen der Lebenserhaltungsablaufauszeit des Weiteren auf einem Bruchteil der Inaktivitätsauszeitperiode basiert.
Das Computerprogrammprodukt nach Anspruch 32, worin die versendete Nachricht, die den einzigartigen Sequenzidentifizierer beinhaltet, eine Bestätigungsnachfragenachricht ist, die eine durch das RM-WS-Protokoll definierte infrastruktur-idempotente Nachricht ist, und worin der Bruchteil der Inaktivitätsauszeitperiode, die zum Berech nen der Lebenserhaltungsablaufauszeit verwendet wird, eine Hälfte der Inaktivitätsauszeitperiode ist, so dass die Bestätigungsnachfragenachricht gesendet wird, wenn der Inaktivitätszeitgeber eine Hälfte der Inaktivitätsauszeitperiode erreicht.
Das Computerprogrammprodukt nach Anspruch 32, das des Weiteren von einem Computer ausführbare Instruktionen beinhaltet, die das Benachrichtigungssystem veranlassen können, das Folgende durchzuführen: Identifizieren einer maximalen Wiederholungsversuchsanzahl, die eine maximale Anzahl von Malen ist, die Applikations- und Infrastrukturnachrichten versendet werden; und Berechnen eines Lebenserhaltungsintervalls, basierend auf der maximalen Wiederholungsversuchsanzahl, wobei das Lebenserhaltungsintervall eine Zeitperiode zum Versenden von Nachrichten repräsentiert; und Versenden einer oder mehrerer Nachrichten, die den einzigartigen Sequenzidentifizierer beinhalten, basierend auf dem berechneten Lebenserhaltungsintervall, worin die eine oder die mehreren versendeten Nachrichten wenigstens eine von einer Applikationsebenenachricht oder einer Bestätigungsnachfragenachricht beinhalten.
Das Computerprogrammprodukt nach Anspruch 34, worin die Inaktivitätsauszeitperiode einstellbar ist, um eine durch das Kommunikationsmedium auferlegte Latenz zuzulassen.
Das Computerprogrammprodukt nach Anspruch 34, worin das RM-WS-Protokoll WSReliableMessaging ist.
Das Computerprogrammprodukt nach Anspruch 26, worin nach dem Ablauf der Inaktivitätsauszeitperiode keine Anwendungs- oder Infrastrukturnachricht erhalten wird und die Sequenzsitzung verlassen wird.
Das Verfahren nach Anspruch 1, worin die versendete Nachricht eine Anwendungsebenennachricht ist.
Das Computerprogrammprodukt nach Anspruch 38, worin eine Bestätigungsnachfragenachricht mit der Anwendungsebenennachricht versendet wird, wobei die Bestäti gungsnachfragenachricht eine durch das RM-WS-Protokoll definierte infrastrukturidempotente Nachricht ist und dazu verwendet wird, die Bestätigungsantwort von einem Annehmer voranzutreiben.
Ein Computerprogrammprodukt zum Implementieren eines Verfahrens zum Verifizieren einer Verbindungslebendigkeit für eine Sequenzsitzung zwischen Endpunktanwendungen durch ein Verwenden eines verlässlichen Nachrichtenprotokolls (RM) für Netzdienste (WS), im Folgenden als RM-WS-Protokoll bezeichnet, auf einem Computersystem in einer WS-Umgebung, wobei das Computerprogrammprodukt ein oder mehrere computerlesbare Medien umfasst, die auf sich von einem Computer ausführbare Instruktionen gespeichert haben, die, wenn sie von einem Prozessor ausgeführt werden, das Benachrichtigungssystem veranlassen können, das Folgende durchzuführen: Einrichten einer Sequenzsitzung, die durch einen einzigartigen Sequenzidentifizierer identifiziert wird, auf einer Anwendungsebene zwischen zwei Endpunktanwendungen in Übereinstimmung mit einem RM-WS-Protokoll; Identifizieren einer Inaktivitätsauszeitperiode, wobei die Inaktivitätsauszeitperiode eine obere Zeitgrenze für die Zeit darstellt, die vergehen darf, ohne dass eine Nachricht für die Sequenzsitzung zwischen den beiden Endpunkten ausgetauscht wird; Erhalten einer Nachricht zum Verifizieren der Verbindungslebendigkeit bevor die Inaktivitätsauszeitperiode abläuft, wobei die Nachricht einen einzigartigen Sequenzidentifizierer beinhaltet, der zu der Sequenzsitzung gehört; und Zurücksetzen eines Inaktivitätszeitgeber für die Inaktivitätsauszeitperiode, basierend auf der erhaltenen Nachricht, so dass die Sequenzsitzung am Leben gehalten wird.
Das Computerprogrammprodukt nach Anspruch 40, worin die erhaltene Nachricht, die den einzigartigen Sequenzidentifizierer beinhaltet, eine Anwendungsnachricht ist.
Das Computerprogrammprodukt nach Anspruch 40, worin die erhaltene Nachricht von einem Initiator der Sequenzsitzung erhalten wird, und worin die erhaltene Nachricht eine Infrastrukturbestätigungsnachricht als Antwort auf die zuvor von dem Initiator versendete Bestätigungsnachfragenachricht ist.
Das Computerprogrammprodukt nach Anspruch 42, worin der Initiator nicht adressierbar ist und der Initiator mit einem Annehmer durch SOAP über HTTP kommuniziert.
Das Computerprogrammprodukt nach Anspruch 40, worin die erhaltene Nachricht von einem Annehmer von der Sequenzsitzung erhalten wird, und wobei die erhaltene Nachricht eine Sequenzbestätigungsfrage ist.
Das Computerprogrammprodukt nach Anspruch 40, worin die Inaktivitätsauszeitperiode einstellbar ist, um eine von dem Kommunikationsmedium k auferlegte Latenz zuzulassen.
Das Computerprogrammprodukt nach Anspruch 40, worin nach dem Zurücksetzen des Inaktivitätszeitgebers nach dem Ablauf der Inaktivitätsauszeitperiode keine Anwendungs- oder Infrastrukturnachrichten empfangen werden und die Sequenzsitzung verlassen wird.