Partager via

Formateur d’opération et sélecteur d’opérations

L’exemple QueryStringFormatter montre comment les points d’extensibilité Windows Communication Foundation (WCF) peuvent être utilisés pour autoriser les données de message dans un format différent de ce que WCF attend. Par défaut, les formateurs WCF s’attendent à ce que les paramètres de méthode soient inclus dans l’élément soap:body . L’exemple montre comment implémenter un formateur d’opération personnalisé qui analyse les données de paramètre à partir d’une chaîne de requête HTTP GET à la place et appelle des méthodes à l’aide de ces données.

L’exemple est basé sur Getting Started, qui implémente le contrat de service ICalculator. Il montre comment ajouter, soustraire, multiplier et diviser des messages peuvent être modifiés pour utiliser HTTP GET pour les requêtes client à serveur et HTTP POST avec des messages POX pour les réponses serveur à client.

Pour ce faire, l’exemple fournit les éléments suivants :

  • QueryStringFormatter, qui implémente IClientMessageFormatter et IDispatchMessageFormatter pour le client et le serveur, respectivement, et traite les données dans la chaîne de requête.

  • UriOperationSelector, qui implémente IDispatchOperationSelector sur le serveur pour effectuer la répartition des opérations en fonction du nom de l’opération dans la requête GET.

  • EnableHttpGetRequestsBehavior comportement du point de terminaison (et configuration correspondante), qui ajoute le sélecteur d’opération nécessaire au runtime.

  • Montre comment insérer un nouveau formateur d’opération dans le runtime.

  • Dans cet exemple, le client et le service sont des applications console (.exe).

Remarque

La procédure d’installation et les instructions de génération de cet exemple se trouvent à la fin de cette rubrique.

Concepts clés

QueryStringFormatter - Le formateur d’opération est le composant dans WCF qui est chargé de convertir un message en tableau d’objets de paramètre et un tableau d’objets de paramètre en message. Cette opération est effectuée sur le client à l’aide de l’interface IClientMessageFormatter et sur le serveur avec l’interface IDispatchMessageFormatter . Ces interfaces permettent aux utilisateurs d’obtenir les messages de demande et de réponse à partir des méthodes Serialize et Deserialize.

Dans cet exemple, QueryStringFormatter implémente ces deux interfaces et est implémentée sur le client et le serveur.

Demande :

  • L’exemple utilise la TypeConverter classe pour convertir les données de paramètre dans le message de requête vers et à partir de chaînes. Si un TypeConverter n'est pas disponible pour un type spécifique, le formateur d'exemple génère une exception.

  • Dans la IClientMessageFormatter.SerializeRequest méthode du client, le formateur crée un URI avec l’adresse To appropriée et ajoute le nom de l’opération en tant que suffixe. Ce nom est utilisé pour acheminer vers l’opération appropriée sur le serveur. Il prend ensuite le tableau d’objets de paramètre et sérialise les données de paramètre dans la chaîne de requête URI à l’aide des noms de paramètres et des valeurs converties par la TypeConverter classe. Les propriétés To et Via sont ensuite définies sur cet URI. MessageProperties est accessible via la Properties propriété.

  • Dans la IDispatchMessageFormatter.DeserializeRequest méthode sur le serveur, le formateur récupère l’URI Via dans les propriétés du message de requête entrante. Il analyse les paires nom-valeur dans la chaîne de requête URI en noms de paramètres et valeurs et utilise les noms et valeurs des paramètres pour remplir le tableau de paramètres passé dans la méthode. Notez que la répartition des opérations s’est déjà produite. Par conséquent, le suffixe du nom de l’opération est ignoré dans cette méthode.

Réponse :

  • Dans cet exemple, HTTP GET est utilisé uniquement pour la requête. Le formateur délègue l’envoi de la réponse au formateur d’origine qui aurait été utilisé pour générer un message XML. L'un des objectifs de cet exemple est de montrer comment un tel formateur déléguant peut être implémenté.

Classe UriPathSuffixOperationSelector

L’interface IDispatchOperationSelector permet aux utilisateurs d’implémenter leur propre logique pour laquelle l’opération d’un message particulier doit être distribuée.

Dans cet exemple, UriPathSuffixOperationSelector doit être implémenté sur le serveur pour sélectionner l’opération appropriée. Cela est nécessaire car le nom de l’opération est inclus dans l’URI HTTP GET plutôt que dans un en-tête d’action dans le message. L'exemple est configuré pour des noms d'opération non sensibles à la casse uniquement.

La SelectOperation méthode prend le message entrant et recherche l’URI Via dans ses propriétés de message. Il extrait le suffixe du nom de l’opération à partir de l’URI, recherche une table interne pour obtenir le nom de l’opération vers lequel le message doit être distribué et retourne ce nom d’opération.

Classe EnableHttpGetRequestsBehavior

Le UriPathSuffixOperationSelector composant peut être configuré par programmation ou via un comportement de point de terminaison. L’exemple implémente le comportement, qui est spécifié dans le EnableHttpGetRequestsBehavior fichier de configuration de l’application du service.

Sur le serveur :

L'implémentation OperationSelector est définie comme IDispatchOperationSelector.

Par défaut, WCF utilise un filtre d’adresse de correspondance exacte. L’URI du message entrant contient un suffixe de nom d’opération suivi d’une chaîne de requête qui contient des données de paramètre. Par conséquent, le comportement du point de terminaison modifie également le filtre d’adresse pour qu’il s’agit d’un filtre de correspondance de préfixe. Il utilise WCFPrefixEndpointAddressMessageFilter à cet effet.

Installation des formatteurs d'opération

Les comportements d'opération qui spécifient des formateurs sont uniques. Un tel comportement est toujours implémenté par défaut pour chaque opération afin de créer le formateur d’opération nécessaire. Toutefois, ces comportements ressemblent à un autre comportement d’opération ; ils ne sont identifiables par aucun autre attribut. Pour installer un comportement de remplacement, l’implémentation doit rechercher des comportements de formateur spécifiques installés par le chargeur de type WCF par défaut et le remplacer ou ajouter un comportement compatible à exécuter après le comportement par défaut.

Ces comportements de formateur d’opération peuvent être configurés par programme avant d’appeler CommunicationObject.Open ou en spécifiant un comportement d’opération exécuté après celui par défaut. Toutefois, il ne peut pas être facilement configuré par un comportement de point de terminaison (et par conséquent par configuration), car le modèle de comportement n’autorise pas un comportement à remplacer d’autres comportements ou modifier l’arborescence de description.

Chez le client :

L’implémentation IClientMessageFormatter doit être implémentée afin qu’elle puisse convertir les requêtes en requêtes HTTP GET et déléguer au formateur d’origine pour les réponses. Pour ce faire, appelez la méthode d’assistance EnableHttpGetRequestsBehavior.ReplaceFormatterBehavior .

Cette opération doit être effectuée avant d’appeler CreateChannel.

void ReplaceFormatterBehavior(OperationDescription operationDescription, EndpointAddress address)
{
    // Remove the DataContract behavior if it is present.
    IOperationBehavior formatterBehavior = operationDescription.Behaviors.Remove<DataContractSerializerOperationBehavior>();
    if (formatterBehavior == null)
    {
        // Remove the XmlSerializer behavior if it is present.
        formatterBehavior = operationDescription.Behaviors.Remove<XmlSerializerOperationBehavior>();
        ...
    }

    // Remember what the innerFormatterBehavior was.
    DelegatingFormatterBehavior delegatingFormatterBehavior = new DelegatingFormatterBehavior(address);
    delegatingFormatterBehavior.InnerFormatterBehavior = formatterBehavior;
   operationDescription.Behaviors.Add(delegatingFormatterBehavior);
}

Sur le serveur :

  • L’interface IDispatchMessageFormatter doit être implémentée afin qu’elle puisse lire les requêtes HTTP GET et déléguer au formateur d’origine pour écrire des réponses. Pour ce faire, appelez la même EnableHttpGetRequestsBehavior.ReplaceFormatterBehavior méthode d’assistance que le client (consultez l’exemple de code précédent).

  • Cette opération doit être effectuée avant Open d’être appelée. Dans cet exemple, nous montrons comment le formatter est modifié manuellement avant d’appeler Open. Une autre façon d'obtenir la même chose est de dériver une classe à partir de ServiceHost qui effectue les appels à EnableHttpGetRequestsBehavior.ReplaceFormatterBehavior avant l'ouverture (veuillez consulter la documentation d'hébergement et les exemples pour plus d'informations).

Expérience utilisateur

Sur le serveur :

  • L’implémentation du serveur ICalculator n’a pas besoin de changer.

  • La App.config du service doit utiliser une liaison POX personnalisée qui définit l’attribut messageVersion de l’élément textMessageEncoding à None.

    <bindings>
  <customBinding>
    <binding name="poxBinding">
      <textMessageEncoding messageVersion="None" />
      <httpTransport />
    </binding>
  </customBinding>
</bindings>

  • Le App.config pour le service doit également spécifier le paramètre personnalisé EnableHttpGetRequestsBehavior, en l’ajoutant à la section des extensions de comportement et en l’utilisant.

    <behaviors>
  <endpointBehaviors>
    <behavior name="enableHttpGetRequestsBehavior">
      <enableHttpGetRequests />
    </behavior>
  </endpointBehaviors>
</behaviors>

<extensions>
  <behaviorExtensions>
    <!-- Enabling HTTP GET requests: Behavior Extension -->
    <add
      name="enableHttpGetRequests"           type="Microsoft.ServiceModel.Samples.EnableHttpGetRequestsBehaviorElement, QueryStringFormatter, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  </behaviorExtensions>
</extensions>

  • Ajoutez les formateurs d'opération avant d'appeler Open.

Chez le client :

  • L’implémentation du client n’a pas besoin de changer.

  • Le App.config pour le client doit utiliser une liaison POX personnalisée, qui définit l’attribut messageVersion de l’élément textMessageEncoding à None. À la différence du service, le client doit activer l'adressage manuel afin que l'adresse To sortante puisse être modifiée.

    <bindings>
  <customBinding>
    <binding name="poxBinding">
      <textMessageEncoding messageVersion="None" />
      <httpTransport manualAddressing="True" />
    </binding>
  </customBinding>
</bindings>

  • La App.config du client doit spécifier la même configuration personnalisée EnableHttpGetRequestsBehavior que le serveur.

  • Ajoutez les formateurs d'opération avant d'appeler CreateChannel().

Lorsque vous exécutez l’exemple, les demandes et réponses de l’opération s’affichent dans la fenêtre de la console cliente. Les quatre opérations (Ajouter, Soustraire, Multiplier et Diviser) doivent réussir.

Pour configurer, générer et exécuter l’exemple

  1. Assurez-vous d’avoir effectué la Procédure d’installation unique pour les exemples Windows Communication Foundation.

  2. Pour générer la solution, suivez les instructions de Création des exemples Windows Communication Foundation.

  3. Pour exécuter l’exemple dans une configuration à un ou plusieurs ordinateurs, conformez-vous aux instructions figurant dans la rubrique Exécution des exemples Windows Communication Foundation.

  • Last updated on