Choisir un encodeur de message

Cet article décrit les critères de choix parmi les encodeurs de messages inclus dans Windows Communication Foundation (WCF) : binaire, texte et MTOM (Message Transmission Optimization Mechanism).

Dans WCF, vous spécifiez comment transférer des données sur un réseau entre des points de terminaison à l’aide d’une liaison, qui est constituée d’une séquence d’éléments de liaison. Un encodeur de message est représenté par un élément de liaison d’encodage de message dans la pile de liaison. Une liaison inclut des éléments de liaison de protocole facultatifs, tels qu’un élément de liaison de sécurité ou une liaison de messagerie fiable, un élément de liaison d’encodage de message requis et un élément de liaison de transport requis.

L’élément de liaison d’encodage de message se trouve sous les éléments de liaison de protocole facultatifs et au-dessus de l’élément de liaison de transport requis. Sur le côté émetteur, un encodeur de message sérialise le message sortant Message et le transmet au transport. Sur le côté entrant, un encodeur de message reçoit la forme sérialisée d’un Message depuis le transport et la transmet à la couche de protocole supérieure, le cas échéant, ou à l’application, sinon.

Lorsque vous vous connectez à un client ou un serveur préexistant, vous n’avez peut-être pas le choix d’utiliser un encodage de message particulier, car vous devez encoder vos messages d’une manière attendue par l’autre côté. Toutefois, si vous écrivez un service WCF, vous pouvez exposer votre service via plusieurs points de terminaison, chacun utilisant un encodage de message différent. Cela permet aux clients de choisir le meilleur encodage pour communiquer avec votre service sur le point de terminaison qui leur convient le mieux, ainsi que de donner à vos clients la possibilité de choisir l’encodage le mieux adapté à ces derniers. L’utilisation de plusieurs points de terminaison vous permet également de combiner les avantages de différents encodages de messages avec d’autres éléments de liaison.

Encodeurs fournis par le système

WCF inclut trois encodeurs de messages, qui sont représentés par les trois classes suivantes :

• TextMessageEncodingBindingElement, l’encodeur de sms prend en charge l’encodage XML brut et l’encodage SOAP. Le mode d’encodage XML brut de l’encodeur de message texte est appelé « XML ancien brut » (POX) pour le distinguer de l’encodage SOAP basé sur du texte. Pour activer POX, définissez la MessageVersion propriété sur None. Utilisez l’encodeur de sms pour interagir avec des points de terminaison non WCF.

• BinaryMessageEncodingBindingElement, l’encodeur de message binaire, utilise un format binaire compact et est optimisé pour la communication WCF vers WCF, et n’est donc pas interopérable. Il s’agit également de l’encodeur le plus performant de tous les encodeurs WCF.

• MtomMessageEncodingBindingElement, l’élément de liaison, spécifie l’encodage de caractères et le contrôle de version des messages pour les messages à l’aide de l’encodage MTOM. MTOM est une technologie efficace pour transmettre des données binaires dans des messages WCF. L’encodeur MTOM tente de créer un équilibre entre efficacité et interopérabilité. L’encodage MTOM transmet la plupart des données XML sous forme textuelle, mais optimise les grands blocs de données binaires en les transmettant as-is, sans conversion en texte. En termes d’efficacité, parmi les encodeurs fournis par WCF, MTOM se situe entre le texte (le plus lent) et le binaire (le plus rapide).

Comment choisir un encodeur de message

Le tableau suivant décrit les facteurs courants utilisés pour choisir un encodeur de message. Hiérarchiser les facteurs importants pour votre application, puis choisir les encodeurs de messages qui fonctionnent le mieux avec ces facteurs. Veillez à prendre en compte tous les facteurs supplémentaires non répertoriés dans ce tableau et les encodeurs de messages personnalisés qui peuvent être requis dans votre application.

Remarque : Lors de l’utilisation de l’encodeur binaire, l’utilisation du paramètre IgnoreWhitespace lors de la création d’un XMLReader n’aura aucun effet. Par exemple, si vous effectuez les opérations suivantes dans une opération de service :

public void OperationContract(XElement input)
{
    Console.WriteLine("{0}", input.Value);
    int counter = 0;
    var xreader = input.CreateReader();
    var reader = XmlReader.Create(xreader, new XmlReaderSettings() { IgnoreWhitespace = true });
    while (reader.Read())
    {
        counter++;
    }

    Console.WriteLine("Read {0} lines with reader", counter);
}

Le paramètre IgnoreWhitespace est ignoré.

Compression et encodeur binaire

À compter de WCF 4.5, l’encodeur binaire WCF ajoute la prise en charge de la compression. Cela vous permet d’utiliser l’algorithme gzip/deflate pour envoyer des messages compressés à partir d’un client WCF et répondre également avec des messages compressés à partir d’un service WCF auto-hébergé. Cette fonctionnalité permet la compression sur les transports HTTP et TCP. Un service WCF hébergé par IIS peut toujours être activé pour envoyer des réponses compressées en configurant le serveur hôte IIS. Le type de compression est configuré avec la BinaryMessageEncodingBindingElement.CompressionFormat propriété. Cette propriété est définie sur l’une des System.ServiceModel.Channels.CompressionFormat valeurs d’énumération :

• Deflate
• GZip
• None

Étant donné que cette propriété n’est exposée que sur binaryMessageEncodingBindingElement, vous devez créer une liaison personnalisée comme celle-ci pour utiliser cette fonctionnalité :

<customBinding>
  <binding name="BinaryCompressionBinding">
    <binaryMessageEncoding compressionFormat ="GZip" />
    <httpTransport />
 </binding>
</customBinding>

Le client et le service doivent accepter d’envoyer et de recevoir des messages compressés. Par conséquent, la propriété compressionFormat doit être configurée sur l’élément binaryMessageEncoding sur le client et le service. Une exception ProtocolException est levée si le service ou le client n’est pas configuré pour la compression, mais l'autre partie l'est. L’activation de la compression doit être soigneusement étudiée. La compression est principalement utile si la bande passante réseau est un goulot d’étranglement. Dans le cas où le processeur est le goulot d’étranglement, la compression diminue le débit. Les tests appropriés doivent être effectués dans un environnement simulé pour déterminer si cela profite à l’application

Voir aussi

• Liaisons