WSIFOperation - Référence des interactions asynchrones
La structure WSIF (Web Services Invocation Framework) prend en charge l'opération asynchrone. Dans ce mode de fonctionnement, le client émet le message de demande dans le cadre d'une première transaction, puis il poursuit le traitement avec l'unité d'exécution. Le message de réponse est ensuite pris en charge par une unité d'exécution différente, avec une transaction distincte.
L'opération asynchrone est prise en charge par les fournisseurs WSIF pour SOAP via JMS et JMS natif.
La classe WSIFPort utilise la méthode supportsAsync pour tester si l'opération asynchrone est prise en charge.
Une opération asynchrone est initiée avec la méthode executeRequestResponseAsync de l'interface WSIFOperation. Cette méthode permet à une méthode RPC (Remote Procedure Call) d'être appelée de manière asynchrone. Son retour d'exécution a lieu avant que l'opération ne soit terminée, et l'unité d'exécution poursuit son traitement.
La réponse à la demande asynchrone est traitée par la méthode fireAsyncResponse ou processAsyncResponse de l'interface WSIFOperation.
public WSIFCorrelationId executeRequestResponseAsync (WSIFMessage input, WSIFResponseHandler handler)
public WSIFCorrelationId executeRequestResponseAsync (WSIFMessage input)
- executeRequestResponseAsync(WSIFMessage input, WSIFResponseHandler handler)
Cette méthode comporte un message d'entrée et un gestionnaire WSIFResponseHandler. Le gestionnaire est appelé sur une autre unité d'exécution lorsque l'opération se termine. Lors de l'utilisation de cette méthode, le programme d'écoute client appelle la méthode fireAsyncResponse, laquelle appelle ensuite la méthode executeAsyncResponse de l'interface WSIFResponseHandler.
- executeRequestResponseAsync(WSIFMessage input)
- Cette méthode comporte uniquement un message d'entrée et n'utilise pas de gestionnaire de réponses. L'écouteur client traite la réponse en appelant la méthode processAsyncResponse de l'interface WSIFOperation. Ce processus met à jour la sortie WSIFMessage et les messages d'erreur avec le résultat de la demande.
WSIF prend en charge la corrélation entre la demande et la réponse asynchrone. Lorsque la demande est envoyée, l'objet WSIFOperation est sérialisé dans l'objet WSIFCorrelationService. Les méthodes executeRequestResponseAsync renvoient un objet WSIFCorrelationId qui identifie l'objet WSIFOperation sérialisé. L'écouteur client peut alors utiliser cet ID pour faire concorder une réponse avec une demande particulière.
Le service de corrélation est localisé à l'aide de la méthode getCorrelationService() de la classe WSIFCorrelationServiceLocator du package org.apache.wsif.utils.
Dans un conteneur géré, un service de corrélation par défaut est défini, dans l'espace de nom JNDI (Java™ Naming and Directory Interface) par défaut sous le nom java:comp/wsif/WSIFCorrelationService. Si ce service de corrélation n'est pas disponible, WSIF utilise WSIFDefaultCorrelationService.
Pour plus d'informations sur l'interface WSIFCorrelationService, voir la documentation sur l'API générée fournie avec WSIF.
Voici l'ID du corrélateur :
public interface WSIFCorrelator extends Serializable {
public String getCorrelationId();
}
Le client doit implémenter son propre écouteur (listener) de messages de réponse ou sa propre base de données de messages afin qu'il puisse reconnaître l'arrivée des messages de réponse. Cette implémentation client gère la corrélation entre le message de réponse et la demande et appelle une des deux formes de la méthode de traitement des réponses asynchrones. Comme exemple de condition requise pour un programme d'écoute client, le fragment de code suivant montre les éléments pouvant figurer dans la méthode onMessage d'un programme d'écoute JMS (Java Message Service) :
public void onMessage(Message msg) {
WSIFCorrelationService cs = WSIFCorrelationServiceLocator.getCorrelationService();
WSIFCorrelationId cid = new JmsCorrelationId( msg.getJMSCorrelationID() );
WSIFOperation op = cs.get( cid );
op.fireAsyncResponse( msg );
}