Asynchronous Invocation API on Liberty

Use the Asynchronous Invocation API to transfer events that require processing in a Session Initiation Protocol (SIP) application session to any server in a cluster based on an application session ID.

The Asynchronous Invocation API, also referred to as the asynchronous work dispatcher, can transfer events that require processing in the context of a SIP application session to any server in a cluster, using the related application session ID. These transfers are usually triggered by events that cause a state change to SIP sessions on another server. The asynchronous work dispatcher transfers the event task to the correct server to be run.

On Liberty, all related SIP messages are delivered to the same server in the cluster, and sessions are always in the same SIP container. To prevent synchronicity issues and locking, tasks in the same application session cannot be processed simultaneously (that is, on different threads or processes), which limits handling of certain types of events.

For more in-depth information about SIP sessions and SIP application sessions, see Section 6 of Java™ Specification Request (JSR) 289.

The following two scenarios are resolved by implementing the Asynchronous Invocation API.
  1. Two requests that are related to the same SIP application session are simultaneously run on two different threads.

    For example, a Java Platform, Enterprise Edition. application that works with a message-driven bean (MDB) can retrieve an event to send a SIP message on a certain SIP application session. At the same time, the SIP container receives an incoming SIP message on another session that is connected to the same application session and handles that on a different thread. It is necessary to synchronize the session access to avoid race conditions and to ensure that all session attributes are synchronized. To employ the locking mechanism in this case would not be effective, because the SIP application session might contain multiple SIP sessions.

  2. A server that does not own a certain SIP application session receives a request, through non-SIP protocol, to send a message in the context of that session.

    For example, a web service that initiates SIP dialogs can be in a server different from the server that owns the SIP application session it must use.

The Asynchronous Invocation API ensures that the specific application code is run on the correct server and correct thread according to the SIP application session ID.

The Asynchronous Invocation API provides the following benefits:
  1. No more than two servers are involved in the asynchronous invocation process: one is the server that retrieves the work task, and the other is the target server that handles the SIP application session for that task and to which the task is transferred.
  2. The asynchronous invocation allows working in a thread-safe manner. This approach ensures that only one thread processes the messages that are related to the SIP application session, so you do not need to synchronize access to the session.
  3. The asynchronous invocation provides a scalable solution so performance is not affected when more servers are added to the cluster.
  4. Cross-server invocation is used only when required, which results in better performance.

Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: Monday, 5 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-libcore-mp&topic=cwlp_sip_asynchinvo_api
File name: cwlp_sip_asynchinvo_api.html