Scénarios d'échange de messages pris en charge

Les services de workflow prennent en charge un sous-ensemble de scénarios d'échange de messages défini dans Windows Communication Foundation (WCF). Les deux scénarios pris en charge sont de type envoi unidirectionnels et de demande/réponse. Dans un scénario d'envoi unidirectionnel, le client n'attend pas de réponse lors de l'appel d'une opération sur le service de workflow. Il appelle simplement l'opération et poursuit le reste de son exécution. Dans un scénario de demande/réponse, le client attend une réponse du service de workflow et bloque le thread d'exécution principal jusqu'à ce que cette réponse soit reçue. Comme indiqué dans ces scénarios, le client initialise tous les échanges de messages avec le service de workflow.

La communication duplex peut être accomplie de deux manières. La première consiste à utiliser des contrats duplex comme un service WCF normal pour établir des ID de session qui seront utilisés pour la communication asynchrone. Malheureusement, du fait que les ID de session sont attachés directement au canal duplex, à chaque fois que le canal est détruit, il n'est plus possible d'utiliser l'ID de session comme moyen d'établir un contexte entre le client et le service. La deuxième méthode consiste à activer la communication duplex à l'aide de contrats corrélés qui communiquent à travers des canaux indépendants. Ces contrats passent des informations d'ID de contexte dans leur appel d'opération initial et l'état d'opération peut être rendu persistant comme tout autre service de workflow. En utilisant des contrats unidirectionnels corrélés, l'ID de contexte est stocké dans la couche de l'application ; par conséquent, si le client ou le service a été redémarré, ils peuvent reprendre à partir de leur dernier état persistant. Il s'agit de la méthode de communication duplex recommandée pour les services de workflow.

Il est recommandé d'effectuer une opération de demande/réponse synchrone avec le service avant de prendre part à la communication asynchrone. Cet échange permettra au client et au service d'établir un contexte qui peut être utilisé dans les futurs appels d'opération.

Échange de contexte

Cette section décrit comment le workflow et les services fiables utilisent les contextes pour corréler les messages entre les services et les clients. Après une opération de demande/réponse initiale, le client reçoit un contexte du service et fournit celui-ci à tous les futurs messages envoyés au service pour la durée de vie de cet échange de messages. Le contexte est opaque pour le client et est fourni uniquement en vue de maintenir des communications avec un échange de messages établi et une instance de service donnée. Après avoir établi le contexte, il peut être modifié uniquement par un message entrant du service.

Remarque :
Dans le cas de scénarios duplex, le service renvoie le contexte en guise d'en-tête de contexte au client dans le cadre du premier message envoyé du service au client et pas nécessairement en tant que réponse à la première demande du client.

Du côté du service, une instance du canal est chargée de convertir le contexte fourni par le client dans le formulaire d'en-tête SOAP pour les messages entrants dans un type ContextMessageProperty. Puis le ContextMessageProperty peut être consommé par la couche d'application ou les canaux en haut de la pile. Les canaux du côté du service permettent également à la couche d'application de spécifier une nouvelle valeur de contexte à propager à nouveau au client.

En maintenant ce contexte à la couche d'application, le canal d'origine peut être détruit et un nouveau canal établi. Pendant que le mécanisme d'échange du contexte est fourni par le canal, le contexte réel peut être fourni et récupéré par la couche d'application (à la fois sur le client et le service).

Pour les points de terminaison de service utilisant un transport HTTP et les clients qui consentent à autoriser l'utilisation de cookies HTTP, le mécanisme de HttpCookie peut être utilisé pour échanger le contexte d'application. Le protocole d'échange du contexte permet au canal du client d'accepter un contexte fourni par un service et de l'appliquer à toutes les demandes suivantes afin que le service puisse recevoir des demandes envoyées sur la même instance de canal du client. Le protocole d'échange de contexte fournit également un équivalent (basé sur SOAP) de la fonctionnalité que les cookies HTTP offrent à la couche de transport.

Remarque :
Les clients qui sont basés sur un workflow et utilisent une activité SendActivity pour communiquer avec un service fiable ou un service de workflow doivent utiliser une liaison qui contient ContextBindingElement pour échanger le contexte entre le client et le service ou fournir un autre canal de corrélation qui s'intègre avec ContextMessageProperty.

L'en-tête SOAP est un en-tête SOAP de wsc:Context utilisé pour représenter les informations de contexte. Le schéma d'en-tête du contexte autorise un nombre illimité d'éléments enfants, chacun avec du contenu de chaîne. Cela permet à la propriété de message correspondante qui représente le contexte d'utiliser un dictionnaire facilitant le mappage d'un nom qualifié XML (le nom de l'élément enfant et l'espace de noms de l'en-tête wsc:Context) à une valeur de chaîne (la valeur texte de l'élément enfant de l'en-tête wsc:Context). L'en-tête wsc:Context est donc requis pour être signé numériquement soit au niveau SOAP, soit au niveau du transport, lorsque la liaison assure une fonction de protection des messages.

Obtention et définition du contexte

Le ContextMessageProperty décrit dans la section précédente est une propriété de message utilisée pour communiquer le contexte entre la couche d'application et la couche du canal du côté du client ou du service. Si le contexte est établi au niveau de la couche du canal, le canal de contexte joindra cette propriété de contexte à tous les messages entrants sur le client et sur le service. Si le contexte est joint à un message sortant sur le client ou le service dans la couche d'application, le contexte stocké dans la couche du canal sera remplacé par le celui représenté par le ContextMessageProperty.

Outre le ContextMessageProperty qui peut être utilisé du côté du client ou du service, le contexte actuel, du côté client, peut être obtenu ou un nouveau contexte peut être défini sur l'instance de canal à l'aide de IContextManager comme indiqué dans les exemples suivants :

IDictionary<XmlQualifiedName, string> context;
IContextManager cm = ClientProxy.InnerChannel.GetProperty<IContextManager>();
if (cm != null)
    context = cm.GetContext();

IContextManager cm = ClientProxy.InnerChannel.GetProperty<IContextManager>();
if (cm != null)
    context = cm.SetContext();

Remarque :
L'objet ClientProxy est un exemple d'instance de la classe proxy générée par svcutil pour effectuer des appels d'opération sur un service.

Voir aussi

Concepts

Styles de création de services de workflow

Autres ressources

Création de services de workflow et de services fiables

Copyright ©2007 par Microsoft Corporation. Tous droits réservés.