API de invocación asíncrona

Puede utilizar la API de invocación asíncrona para transferir sucesos que requieren un proceso en una sesión de aplicación SIP (Session Initiation Protocol) para cualquier servidor de un clúster basado en el ID de sesión de aplicación.

La API de invocación síncrona, a la que también se hace referencia como asignador de trabajos síncrono, puede transferir sucesos que requieren un proceso dentro del contexto de una sesión de aplicación SIP con cualquier servidor de un clúster, utilizando el ID de sesión de aplicación relacionado. Generalmente, estas transferencia se activan mediante sucesos que generan un cambio de estado en las sesiones SIP que residen en otro servidor. El asignador de trabajos asíncrono transfiere la tarea de suceso al servidor correcto que se ha de ejecutar.

En Websphere Application Server, todos los mensajes SIP se entregan al mismo servidor del clúster, y las sesiones siempre residen en el mismo contenedor SIP. Para impedir problemas de sincronicidad y bloqueo, las tareas de la misma sesión de aplicación no se pueden procesar simultáneamente (esto es, en diferentes hebras o procesos), lo cual limita el manejo de determinados tipos de sucesos.

Para obtener una información más detallada acerca de las sesiones SIP y de las sesiones de aplicaciones SIP y sus relaciones, consulte la Sección 6 de la especificación JSR (Java™ Specification Request) 289.

Los siguientes dos escenarios se resuelven implementando la API de invocación síncrona.
  1. Dos solicitudes relacionadas con la misma sesión de aplicación SIP se ejecutan de forma simultánea en dos hebras diferentes. por ejemplo, una aplicación J2EE (Java EE) que trabajan con un bean controlado por mensajes MDB pueden recuperar un suceso para enviar un mensaje SIP en una sesión de aplicación SIP determinada. Al mismo tiempo, el contenedor SIP recibe un mensaje SIP de entrada en otra sesión que está conectada a la misma sesión de aplicación y lo maneja en una hebra diferente. Para evitar condiciones de contienda será necesario sincronizar el acceso a la sesión y así garantizar que todos los atributos de sesión están sincronizados. En este caso no resultará eficaz emplear el mecanismo de bloqueo ya que la sesión de aplicación SIP puede contener varias sesiones SIP.
  2. Un servidor que no posee una sesión de aplicación SIP concreta recibe una solicitud, mediante un protocolo no de SIP, para enviar un mensaje dentro del contexto de dicha sesión. Por ejemplo, un servicio WEB que inicia diálogos SIP puede residir en un servidor diferente del servidor que posee la sesión de aplicación SIP que debe utilizar.

La API de invocación asíncrona garantiza que el código de aplicación específico se ejecute en el servidor correcto y la hebra en función del ID de sesión de aplicación SIP.

La API de invocación asíncrona proporciona las ventajas siguientes:
  1. En el proceso de invocación asíncrona no participan más de dos servidores: uno es el servidor que recupera la tarea de trabajo y el otro es el servidor de destino que maneja la sesión de aplicación SIP para dicha tarea y a la que se transferirá la tarea.
  2. La invocación asíncrona permite trabajar de un modo seguro para las hebras. Este método garantiza que sólo una hebra procesa los mensajes relacionados con la sesión de aplicación SIP. De este modo, no es necesario sincronizar el acceso a la sesión.
  3. La invocación asíncrona proporciona una solución escalable. No se produce un impacto en el rendimiento cuando se añaden más servidores al clúster.
  4. La invocación entre servidores sólo se utiliza cuando es necesario, lo que genera un mejor rendimiento.

Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=ccea_asynch_invocation_api
File name: ccea_asynch_invocation_api.html