Anwendungsprogrammierschnittstelle für asynchrone Aufrufe
Verwenden Sie die Anwendungsprogrammierschnittstelle 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 Anwendungsprogrammierschnittstelle 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 zu ü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 WebSphere Application Server 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-Anwendungen und ihrer Beziehung zueinander finden Sie in Abschnitt 6 von Java™ Specification Request (JSR) 289.
- Zwei Anforderungen, die sich auf dieselbe SIP-Anwendungssitzung beziehen, werden gleichzeitig in zwei verschiedenen Threads ausgeführt. Eine J2EE-Anwendung (Java EE), 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 gleichen Zeit empfängt der SIP-Container eine eingehende SIP-Nachricht in einer anderen Sitzung, die mit derselben Anwendungssitzung verbunden ist und diese in einem anderen Thread verarbeitet. Der Sitzungszugriff müsste 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 mehrere SIP-Sitzungen enthalten kann.
- 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 einleitet, kann sich beispielsweise in einem anderen Server als dem befinden, der Eigner der zu verwendenden SIP-Anwendungssitzung ist.
Die Anwendungsprogrammierschnittstelle für asynchrone Aufrufe stellt sicher, dass der spezifische Anwendungscode entsprechend der ID der SIP-Anwendungssitzung im richtigen Server und Thread ausgeführt wird.
- 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.
- Durch den asynchronen Aufruf ist ein thread-sicheres Arbeiten möglich. Dieser Ansatz gewährleistet, dass nur ein einziger Thread die Nachrichten verarbeitet, die sich auf die SIP-Anwendungssitzung beziehen. Deshalb muss der Zugriff auf die Sitzung nicht synchronisiert werden.
- Der asynchrone Aufruf ist eine skalierbare Lösung. Es ist kein Leistungseinfluss zu verzeichnen, wenn dem Cluster weitere Server hinzugefügt werden.
- Ein serverübergreifender Aufruf wird nur bei Bedarf verwendet, was zu einer besseren Leistung führt.