API für asynchrone Aufrufe in Liberty

Verwenden Sie die API für asynchrone Aufrufe, um Ereignisse, die in einer SIP-Anwendungssitzung (Session Initiation Protocol) verarbeitet werden müssen, basierend auf einer Anwendungssitzungs-ID an einen Server in einem Cluster zu übertragen.

Die API für asynchrone Aufrufe, die auch als Dispatcher für asynchrone Anforderungen bezeichnet wird, kann Ereignisse, die im Kontext einer SIP-Anwendungssitzung verarbeitet werden müssen, unter Verwendung der zugehörigen Anwendungssitzungs-ID an einen Server in einem Cluster übertragen. Diese Übertragungen werden gewöhnlich von Ereignissen ausgelöst, die eine Statusänderung für SIP-Sitzungen auf einem anderen Server bewirken. Der Dispatcher für asynchrone Anforderungen überträgt die Ereignistask zur Ausführung an den richtigen Server.

In Liberty werden alle zugehörigen SIP-Nachrichten demselben Server im Cluster zugestellt und Sitzungen befinden sich immer in demselben SIP-Container. Zur Vermeidung von Synchronitätsproblemen und Sperren können Tasks in derselben Sitzung nicht gleichzeitig (d. h. in verschiedenen Threads oder Prozessen) verarbeitet werden, was die Handhabung bestimmter Typen von Ereignissen einschränkt.

Detaillierte Informationen zu SIP-Sitzungen und SIP-Anwendungssitzungen finden Sie in Abschnitt 6 von Java™ Specification Request (JSR) 289.

Die folgenden beiden Szenarien werden durch die Implementierung der API für asynchrone Aufrufe aufgelöst:
  1. Zwei Anforderungen, die sich auf dieselbe SIP-Anwendungssitzung beziehen, werden gleichzeitig in zwei verschiedenen Threads ausgeführt.

    Eine Java EE-Anwendung (Java Platform, Enterprise Edition), die mit einer Message-driven Bean (MDB) arbeitet, kann beispielsweise ein Ereignis abrufen, um eine SIP-Nachricht an eine bestimmte SIP-Anwendungssitzung zu senden. Zur selben Zeit empfängt der SIP-Container eine eingehende SIP-Nachricht in einer anderen Sitzung, die mit derselben Anwendungssitzung verbunden ist, und verarbeitet diese in einem anderen Thread. Der Sitzungszugriff muss synchronisiert werden, um Konkurrenzsituationen zu vermeiden und sicherzustellen, dass alle Sitzungsattribute synchronisiert werden. Die Verwendung des Sperrmechanismus wäre in diesem Fall nicht effektiv, weil die SIP-Anwendungssitzung möglicherweise mehrere SIP-Sitzungen enthält.

  2. Ein Server, der nicht der Eigner einer bestimmten SIP-Anwendungssitzung ist, empfängt eine Anforderung über ein anderes Protokoll als SIP, um eine Nachricht im Kontext dieser Sitzung zu senden.

    Ein Web-Service, der SIP-Dialoge initialisiert, kann sich beispielsweise auf einem anderen Server als dem befinden, der Eigner der zu verwendenden SIP-Anwendungssitzung ist.

Die API für asynchrone Aufrufe stellt anhand der SIP-Anwendungssitzungs-ID sicher, dass der spezifische Anwendungscode im richtigen Server und Thread ausgeführt wird.

Die API für asynchrone Aufrufe bietet die folgenden Vorteile:
  1. Es sind nicht mehr als zwei Server am asynchronen Aufrufprozess beteiligt: Der eine Server ruft die Anforderungstask ab und der andere Server ist der Zielserver, der die SIP-Anwendungssitzung für diese Task verarbeitet und an den die Task übertragen wird.
  2. Durch den asynchronen Aufruf ist ein threadsicheres Arbeiten möglich. Dieser Ansatz gewährleistet, dass nur ein einziger Thread die Nachrichten verarbeitet, die sich auf die SIP-Anwendungssitzung beziehen. Aus diesem Grund müssen Sie den Zugriff auf die Sitzung nicht synchronisieren.
  3. Ein asynchroner Aufruf ist eine skalierbare Lösung, sodass die Leistung nicht beeinträchtigt wird, wenn dem Cluster weitere Server hinzugefügt werden.
  4. Ein serverübergreifender Aufruf wird nur bei Bedarf verwendet, was zu einer besseren Leistung führt.

Symbol das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 01.12.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-libcore-mp&topic=cwlp_sip_asynchinvo_api
Dateiname: cwlp_sip_asynchinvo_api.html