Interface API d'appel asynchrone
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 de 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 WebSphere Application Server, tous les messages SIP associés sont distribués au même serveur du cluster, et les sessions résident 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 d'informations sur les sessions SIP et les sessions d'application SIP ainsi que leurs relations, voir Section 6 de la spécification JSR (Java™ Specification Request) 289.
- Deux demandes relatives à la même session d'application SIP sont simultanément exécutées sur deux unités d'exécution différentes. Par exemple, une application Java EE (J2EE) utilisant un bean géré par message (MDB) peut extraire un événement pour envoyer un message SIP à une session d'application SIP déterminée. 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 à la session pour éviter les conditions d'indétermination et 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.
- 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 à l'origine de dialogues SIP peut résider sur un serveur différent du serveur qui possède la session d'application SIP à 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.
- Deux serveurs au maximum participent au processus d'appel asynchrone : l'un extrait la tâche de travail et l'autre constitue le serveur cible qui traite la session d'application SIP pour la tâche transférée vers celui-ci.
- L'appel asynchrone autorise les unités d'exécution multiples. Cette approche garantit qu'une seule unité d'exécution traite les messages relatifs à la session d'application SIP. Par conséquent, la synchronisation de l'accès à la session n'est pas nécessaire.
- L'appel asynchrone fournit une solution évolutive. L'ajout de serveurs au cluster n'a aucun impact sur les performances.
- L'appel entre serveurs n'est utilisé qu'en cas de nécessité, ce qui optimise les performances.