Opérations synchrones et asynchrones

Article
02/27/2011

Décrit les implémentations et appels asynchrones locaux ainsi que l'utilisation synchrone d'échanges de messages asynchrones.

De nombreuses applications appellent des méthodes de façon asynchrone car elles peuvent ainsi continuer à effectuer un travail utile pendant que l'appel de méthode s'exécute. Les services et clients Windows Communication Foundation (WCF) peuvent participer à des appels d'opération asynchrones à deux niveaux distincts de l'application, qui procurent aux applications WCF plus de souplesse pour optimiser le débit en fonction de l'interactivité.

Types d'opérations asynchrones

Tous les contrats de service dans WCF, indépendamment des types de paramètres et des valeurs de retour, utilisent des attributs WCF pour spécifier un modèle d'échange de messages SOAP particulier entre le client et le service. WCF route automatiquement les messages SOAP entrants et sortants vers l'opération de service appropriée ou le code client exécuté.

Le client possède uniquement le contrat de service qui spécifie le modèle d'échange de messages pour une opération particulière. Les clients peuvent offrir au développeur un modèle de programmation de leur choix, tant que le modèle d'échange de messages sous-jacent est respecté. De même, les services peuvent implémenter des opérations de quelque manière que ce soit, à condition que le modèle de message spécifié soit respecté.

L'indépendance du contrat de service vis à vis de l'implémentation du service ou du client autorise les types d'exécutions asynchrones suivants dans les applications WCF :

Les clients peuvent appeler de façon asynchrone des opérations de demande/réponse à l'aide d'un échange de messages synchrone.
Les services peuvent implémenter de façon asynchrone une opération de demande/réponse à l'aide d'un échange de messages synchrone.
Les échanges de messages peuvent être unidirectionnels, indépendamment de l'implémentation du client ou service.

Scénarios asynchrones suggérés

Utilisez une approche asynchrone dans une implémentation de l'opération de service si celle-ci passe un appel bloquant, par exemple une tâche en E/S. Lorsque vous êtes dans une implémentation d'opération asynchrone, essayez d'appeler des méthodes et des opérations asynchrones pour étendre le chemin d'appel asynchrone aussi loin que possible. Par exemple, appelez BeginOperationTwo() à partir d'un BeginOperationOne().

Utilisez une approche asynchrone dans une application cliente ou appelante dans les cas suivants :
Si vous appelez des opérations à partir d'une application intermédiaire. (Pour plus d'informations sur le sujet suivant ces scénarios, consultez Applications clientes de niveau intermédiaire.)
Si vous appelez des opérations à partir d'une page ASP.NET, utiliser des pages asynchrones.
Si vous appelez des opérations à partir de n'importe quelle application monothread, telle que Windows Forms ou Windows Presentation Foundation (WPF). Lorsque vous utilisez le modèle d'appel asynchrone basé sur des événements, l'événement résultant est déclenché sur le thread d'interface utilisateur, ce qui accroît la réactivité de l'application sans exiger la gestion de plusieurs threads.
En général, si vous avez le choix entre un appel synchrone et asynchrone, choisissez l'appel asynchrone.

Appels asynchrones côté client

Une application cliente WCF peut utiliser un des deux modèles d'appel asynchrone décrits dans Asynchronous Programming Design Patterns :

Opérations asynchrones qui utilisent des événements.
Opérations asynchrones qui utilisent des objets System.IAsyncResult.

La première approche, le modèle asynchrone basé sur des événements, est recommandée pour appeler des applications car elle ne nécessite que l'ajout d'un gestionnaire d'événements pour recevoir une notification de la réponse, et l'événement résultant est déclenché automatiquement sur le thread d'interface utilisateur. Pour utiliser cette approche, spécifiez les options de commande /async et /tcv:Version35 avec Outil Service Model Metadata Tool (Svcutil.exe), comme illustré dans l'exemple suivant.

svcutil https://localhost:8000/servicemodelsamples/service/mex /async /tcv:Version35

Au terme de cette opération, l'outil Svcutil.exe génère une classe cliente WCF avec l'infrastructure d'événement qui permet à l'application appelante d'implémenter et d'affecter un gestionnaire d'événements de recevoir la réponse et prendre la mesure appropriée. Pour obtenir un exemple complet, consultez Comment : appeler des opérations de service WCF de façon asynchrone.

Cependant, le modèle asynchrone basé sur les événements n'est disponible que dans le .NET Framework version 3.5. De plus, il n'est pas pris en charge dans le .NET Framework 3.5 lorsqu'un canal client WCF est créé à l'aide d'un System.ServiceModel.ChannelFactory. Avec les objets de canal client WCF, vous devez utiliser des objets System.IAsyncResult pour appeler vos opérations de manière asynchrone. Pour utiliser cette approche, spécifiez l'option de commande /async avec Outil Service Model Metadata Tool (Svcutil.exe), comme illustré dans l'exemple suivant.

svcutil https://localhost:8000/servicemodelsamples/service/mex /async

Vous générez ainsi un contrat de service dans lequel chaque opération est modelée comme une méthode <Begin> et où la propriété AsyncPattern a la valeur true et une méthode correspondante <End>. Pour obtenir un exemple complet à l'aide d'un ChannelFactory, consultez Comment : appeler des opérations de façon asynchrone à l'aide d'une fabrication de canal.

Dans l'un ou l'autre cas, les applications peuvent appeler une opération de façon asynchrone même si le service est implémenté de façon synchrone, de la même façon qu'une application peut utiliser le même modèle pour appeler une méthode synchrone locale de façon asynchrone. La méthode d'implémentation de l'opération n'a pas d'importance pour le client ; lorsque le message de réponse arrive, son contenu est distribué à la méthode <End> asynchrone du client et ce dernier récupère les informations.

Implémentations d'opérations asynchrones

De même, une opération de service peut être implémentée de manière asynchrone à l'aide du modèle de programmation asynchrone .NET Framework et en marquant la méthode <Begin> avec la propriété AsyncPattern ayant la valeur true. Dans ce cas, l'opération asynchrone est exposée dans les métadonnées sous la forme d'une opération synchrone: Elle est exposée comme une seule opération avec un message de demande et un message de réponse corrélé. Les modèles de programmation clients doivent ensuite choisir entre deux options. Ils peuvent représenter ce modèle comme une opération synchrone ou asynchrone, tant qu'un échange de messages de réponse-demande a lieu lorsque le service est appelé.

En général, avec la nature asynchrone des systèmes, vous ne devez pas exploiter de dépendance sur les threads. La méthode la plus fiable pour transmettre des données à différentes étapes du traitement de la distribution des opérations consiste à utiliser les extensions.

Pour obtenir un exemple, consultez Comment : implémenter une opération de service asynchrone.

Pour définir une opération de contrat X exécutée de façon asynchrone quelle que soit la manière dont elle est appelée dans l'application cliente :

Définissez deux méthodes à l'aide du modèle BeginOperation et EndOperation.
La méthode BeginOperation inclut les paramètres in et ref pour l'opération et retourne un type IAsyncResult.
La méthode EndOperation inclut un paramètre IAsyncResult ainsi que les paramètres out et ref et elle retourne le type de retour des opérations.

Par exemple, reportez-vous à la méthode suivante :

int DoWork(string data, ref string inout, out string outonly)

Function DoWork(ByVal data As String, ByRef inout As String, _
out outonly As out) As Integer

Voici les deux méthodes pour créer une opération asynchrone :

[OperationContract(AsyncPattern=true)]
IAsyncResult BeginDoWork(string data, 
                          ref string inout, 
                          AsyncCallback callback, 
                          object state);
int EndDoWork(ref string inout, out string outonly, IAsyncResult result);

<OperationContract(AsyncPattern := True)>  _
Function BeginDoWork(ByVal data As String, _
                 ByRef inout As String, _
                 ByVal callback As AsyncCallback, _
                 ByVal state As Object) _
As IAsyncResult 

Function EndDoWork(ByRef inout As String, _
        ByRef outonly As String, _
        ByVal result As IAsyncResult) _
As Integer

Remarque :
L'attribut OperationContractAttribute est appliqué uniquement à la méthode `BeginDoWork`. Le contrat obtenu a une opération WSDL nommée `DoWork`.

Modèles d'échange de messages unidirectionnels

Vous pouvez également créer un modèle d'échange de messages asynchrone dans lequel les opérations unidirectionnelles (les opérations pour lesquelles System.ServiceModel.OperationContractAttribute.IsOneWay a la valeur true n'ont aucune réponse corrélée) peuvent être envoyées dans chaque direction par le client ou le service, indépendamment du côté opposé. (Cette méthode utilise le modèle d'échange de messages duplex avec des messages unidirectionnels.) Ainsi, le contrat de service spécifie un échange de messages unidirectionnels que chaque côté peut mettre en œuvre comme des appels ou implémentations asynchrones, ou synchrones, selon le cas. En général, lorsque le contrat est un échange de messages unidirectionnels, les implémentations sont en grande partie synchrones car, après l'envoi d'un message, l'application n'attend pas de réponse et peut continuer à effectuer d'autres tâches.

Contrats de message et clients asynchrones basés sur les événements

Les règles de conception pour le modèle asynchrone basé sur les événements stipulent que si plusieurs valeurs sont retournées, une valeur est retournée comme la propriété Result et les autres sont retournées comme les propriétés sur l'objet EventArgs. Il en découle que si un client importe des métadonnées à l'aide des options de commande asynchrone basées sur les événements et que l'opération retourne plusieurs valeurs, l'objet EventArgs par défaut retourne une valeur comme la propriété Result et le reste sont des propriétés de l'objet EventArgs.

Pour recevoir l'objet message comme propriété Result et pour que les valeurs retournées sur cet objet soient des propriétés, utilisez l'option de commande /messageContract. Cette opération génère une signature qui retourne le message de réponse comme la propriété Result sur l'objet EventArgs. Toutes les valeurs de retour internes sont ensuite des propriétés de l'objet de message de réponse.

Voir aussi

Référence

IsOneWay
AsyncPattern

Partager via