Communications asynchrones avec les services Web XML
Cette rubrique est spécifique à une technologie existante. Les services Web XML et les clients du service Web XML doivent à présent être créés à l'aide de Windows Communication Foundation.
La communication asynchrone avec un service Web suit les deux modèles de conception d'appel de méthode asynchrone spécifiés par le .NET Framework. Avant d'en venir à ces détails, toutefois, il est important de noter qu'un service Web n'a pas à être écrit spécialement pour gérer des demandes asynchrones à appeler de façon asynchrone.
Wsdl.exe et le modèle de conception asynchrone .NET Framework
Lorsque l'outil Web Services Description Language (Wsdl.exe) génère une classe proxy cliente pour accéder à un service Web spécifié, il fournit la classe proxy avec deux mécanismes pour communiquer de façon asynchrone avec chaque méthode de service Web. Le premier mécanisme est le modèle de Begin/End. Le deuxième mécanisme est le modèle de programmation asynchrone événementiel disponible dans la version 2.0 du .NET Framework. Pour une brève description de l'utilisation des modèles avec les services Web, consultez les sections suivantes. Pour plus de détails sur les deux modèles, consultez Asynchronous Programming Design Patterns.
Modèle d'appel Begin/End
Wsdl.exe crée automatiquement trois méthodes pour chaque opération (une méthode de service Web dans ASP.NET) publiée dans le service Web. Une méthode est pour l'accès synchrone ; les deux autres sont pour l'accès asynchrone. C'est le cas même si la méthode de service Web est implémentée de façon synchrone uniquement. Le tableau suivant décrit ces trois méthodes :
| Nom de la méthode dans la classe proxy | Description |
|---|---|
<NameOfWebServiceMethod> |
Envoie un message pour la méthode de service Web nommée <NameOfWebServiceMethod> de façon synchrone. |
Begin<NameOfWebServiceMethod> |
Commence la communication de message asynchrone avec une méthode de service Web nommée <NameOfWebServiceMethod>. Le client ordonne à la méthode Begin de commencer à traiter l'appel de service, mais retourne immédiatement. La valeur de retour n'est pas le type de données spécifié par la méthode de service Web, mais plutôt un type qui implémente l'interface IAsyncResult. |
End<NameOfWebServiceMethod> |
Termine une communication de message asynchrone avec une méthode de service Web nommée <NameOfWebServiceMethod>, en retournant une valeur qui est le résultat de l'appel de méthode de service Web. |
Les méthodes Begin et End suivent la convention d'affectation de noms pour le modèle de conception asynchrone du .NET Framework. Le modèle de conception prévoit deux méthodes asynchrones nommées ainsi pour chaque méthode synchrone.
Par exemple, prenez une classe de service Web PrimeFactorizer dont la méthode de service Web recherche des facteurs premiers, avec la signature suivante :
public long[] Factorize(long factorizableNum)
Une telle méthode peut prendre beaucoup de temps pour terminer le traitement, selon l'entrée. C'est donc un bon exemple de cas où votre client de service Web devrait appeler la méthode de service Web de façon asynchrone.
Si Wsdl.exe utilisait ce service Web comme entrée pour générer le code proxy client (à l'aide de la chaîne de requête ?wsdl pour un service Web ASP.NET), il générerait des méthodes avec les signatures suivantes :
public long[] Factorize(long factorizableNum)
public System.IAsyncResult BeginFactorize(long factorizableNum, System.AsyncCallback callback, object asyncState)
public long[] EndFactorize(System.IAsyncResult asyncResult)
Implémentation d'un client de service Web faisant un appel de méthode asynchrone à l'aide du modèle Begin/End
Comment un client sait-il quand appeler la méthode End ? Il y a deux techniques d'implémentation d'un client permettant de le déterminer, comme défini par le .NET Framework :
Technique d'attente : utilisez l'une des méthodes de la classe WaitHandle pour qu'un client attende la fin de l'exécution de la méthode.
Technique de rappel : passez une fonction de rappel dans la méthode Begin, qui est alors appelée pour récupérer les résultats lorsque la méthode a terminé le traitement.
Remarque : quelle que soit celle de ces deux techniques qu'un client choisisse pour communiquer de façon asynchrone avec un service Web, les messages SOAP envoyés et reçus sont identiques aux messages SOAP générés par la méthode de proxy synchrone. Autrement dit, il n'y a toujours qu'une demande SOAP et une réponse SOAP envoyées et reçues via le réseau. Pour ce faire, la classe proxy gère la réponse SOAP à l'aide d'un thread différent du thread que le client a utilisé pour appeler la méthode Begin. Par conséquent, le client peut continuer à exécuter d'autres tâches sur son thread pendant que la classe proxy assure la réception et le traitement de la réponse SOAP.
Technique d'attente à l'aide du modèle Begin/End
La classe WaitHandle implémente des méthodes qui prennent en charge l'attente pour les objets de synchronisation à signaler : WaitOne, WaitAnyet WaitAll. La signalisation d'un objet de synchronisation consiste à indiquer que les threads qui attendent la ressource spécifiée peuvent ensuite accéder à la ressource. Le client de service Web accède à un objet WaitHandle via la propriété AsyncWaitHandle de l'objet IAsyncResult retournée par la méthode Begin.
Pour voir un exemple de cette technique, consultez Comment : implémenter un client de service Web asynchrone à l'aide de la technique d'attente.
Technique de rappel à l'aide du modèle Begin/End
Avec la technique de rappel, une fonction de rappel implémente le délégué AsyncCallback, qui applique la signature :
public void MethodName(IAsyncResult ar)
Pour voir un exemple de cette technique, consultez Comment : implémenter un client de service Web asynchrone à l'aide de la technique de rappel.
Si le rappel requiert un contexte synchronisé/d'affinité de thread, il est réparti via l'infrastructure du répartiteur de contexte. En d'autres termes, le rappel peut s'exécuter de façon asynchrone vis-à-vis des appelant dans de tels contextes. C'est précisément la sémantique du qualificateur unidirectionnel sur les signatures de méthode. Cela signifie qu'un tel appel de méthode peut s'exécuter de façon synchrone ou asynchrone en fonction de l'appelant distant. Ce dernier ne peut faire aucune supposition quant à l'achèvement d'un tel appel lorsque le contrôle d'exécution lui est retourné.
L'appel de la méthode End avant l'achèvement de l'opération asynchrone bloquera l'appelant. Le comportement pour l'appeler une deuxième fois avec le même IAsyncResult retourné par la méthode Begin est indéfini.
Clients de service Web asynchrones utilisant le modèle asynchrone événementiel
Multithreaded Programming with the Event-based Asynchronous Pattern introduit un nouveau modèle de programmation asynchrone qui utilise les événements pour gérer des rappels, facilitant ainsi la création d'applications multithread sans nécessité d'implémenter soi-même le code multithread complexe. Pour une vue d'ensemble du nouveau modèle asynchrone événementiel, consultez Event-based Asynchronous Pattern Overview. Pour plus d'informations sur les implémentations clientes à l'aide du nouveau modèle, consultez How to: Implement a Client of the Event-based Asynchronous Pattern.
Pour voir comment générer un service Web à l'aide du modèle événementiel, consultez Comment : implémenter un client de service Web asynchrone axé sur les événements à l'aide d'ASP.NET 2.0.
Voir aussi
Tâches
Comment : implémenter un client de service Web asynchrone à l'aide de la technique d'attente
Comment : implémenter un client de service Web asynchrone à l'aide de la technique de rappel
Comment : procéder à un appel asynchrone d'un client de service Web
Concepts
Création de clients de service Web XML
Règles de conception pour les services Web XML créés à l'aide d'ASP.NET