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 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.