API d'appel asynchrone sur Liberty

Utilisez l'interface API d'appel asynchrone pour transférer des événements à traiter dans une session d'application SIP (Session Initiation Protocol) vers l'un des serveurs d'un cluster, d'après un identificateur de session d'application.

L'interface API d'appel asynchrone, également désignée répartiteur de travaux asynchrones, peut transférer des événements à traiter dans une session d'application SIP vers l'un des serveurs d'un cluster, d'après l'identificateur de session d'application associé. Ces transferts sont généralement déclenchés par des événements qui provoquent une modification d'état des sessions SIP résidant sur un autre serveur. Le répartiteur de travaux asynchrones transfère la tâche d'événement au serveur approprié en vue de son exécution.

Dans Liberty, tous les messages SIP connexes sont livrés sur le même serveur dans le cluster, et les sessions sont toujours dans le même conteneur SIP. Pour éviter les problèmes de synchronisme et de verrouillage, les tâches d'une même session d'application ne peuvent pas être traitées simultanément (c'est-à-dire, sur des unités d'exécution ou des processus différents), ce qui limite le traitement de certains types d'événement.

Pour plus de détails sur les sessions SIP et les sessions d'application SIP, voir la section 6 de Java™ Specification Request (JSR) 289.

Les deux scénarios ci-après sont résolus par l'implémentation de l'interface API d'appel asynchrone.
  1. Deux demandes qui sont associées à la même session d'application SIP sont exécutées simultanément sur deux unités d'exécution différentes.

    Par exemple, une application Java Platform, Enterprise Edition qui fonctionne avec un bean géré par message peut extraire un événement pour envoyer un message SIP sur un session d'application SIP spécifique. En même temps, le conteneur SIP reçoit un message SIP entrant sur une autre session connectée à la même session d'application et le traite sur une autre unité d'exécution. Il est nécessaire de synchroniser l'accès de session afin d'éviter des conditions d'indétermination et de garantir que tous les attributs de session sont synchronisés. Dans ce cas, l'emploi du dispositif de verrouillage n'est pas efficace, car la session d'application SIP peut contenir plusieurs sessions SIP.

  2. Un serveur sans session d'application SIP déterminée reçoit, par un protocole non SIP, une demande d'envoi d'un message dans le contexte de cette session.

    Par exemple, un service Web qui initie des dialogues SIP peut être sur un serveur différent de celui qui est propriétaire de la session d'application SIP qu'il doit utiliser.

L'interface API d'appel asynchrone permet de s'assurer que le code d'application spécifique est exécuté sur le serveur et l'unité d'exécution appropriés, d'après l'identificateur de session d'application SIP.

L'interface API d'appel asynchrone offre les avantages suivants :
  1. Deux serveurs au maximum sont impliqués dans le processus d'appel asynchrone : le premier est le serveur qui extrait la tâche et le second est le serveur cible qui traite la session d'application SIP pour cette tâche et sur lequel la tâche est transférée.
  2. L'appel asynchrone autorise les unités d'exécution multiples. Cette approche garantit qu'une seule unité d'exécution traite les messages qui sont associés à la session d'application SIP ; vous n'avez donc pas à synchroniser l'accès à la session.
  3. L'appel asynchrone fournit une solution évolutive de sorte que les performances ne soient pas dégradées lorsque plusieurs serveurs sont ajoutés au cluster.
  4. L'appel entre serveurs n'est utilisé qu'en cas de nécessité, ce qui optimise les performances.

Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: Tuesday, 6 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwlp_sip_asynchinvo_api
Nom du fichier : cwlp_sip_asynchinvo_api.html