Network Deployment (Distributed operating systems), v8.0 > Develop and deploying applications > Develop SIP applications > Develop SIP applications > Develop applications that use the Asynchronous Invocation API
Asynchronous Invocation API
Use the Asynchronous Invocation API to transfer events that require processing in a 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 that reside on another server. The asynchronous work dispatcher transfers the event task to the correct server to be run.
In Websphere Application Server, all related SIP messages are delivered to the same server in the cluster, and sessions always reside 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 and their relationship, see Section 6 of Java Specification Request (JSR) 289.
The following two scenarios are resolved by implementing the Asynchronous Invocation API.
- Two requests related to the same SIP application session are simultaneously run on two different threads. For example, a Java EE (J2EE) applications working 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 would be 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.
- 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 is initiating SIP dialogs can reside 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:
- 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 will be transferred.
- The asynchronous invocation allows working in a thread-safe manner. This approach ensures that only one thread processes the messages related to the SIP application session. Thus, there is no need to synchronize access to the session.
- The asynchronous invocation provides a scalable solution. There is no performance impact when more servers are added to the cluster.
- Cross-server invocation is used only when required, which results in better performance.
Develop applications that use the Asynchronous Invocation API