Glossaire Windows Communication Foundation

Les termes suivants sont définis pour Windows Communication Foundation (WCF).

Termes

Terme	Définition
Adresse (address)	L'adresse spécifie l'emplacement de messages de réception. Elle est indiquée comme un URI (Uniform Resource Identifier). La partie schématique de l'URI nomme le mécanisme de transport à utiliser pour atteindre l'adresse, tel que HTTP et TCP. La partie hiérarchique de l'URI contient un emplacement unique dont le format dépend du mécanisme de transport. L'adresse de point de terminaison vous permet de créer des adresses uniques pour chaque point de terminaison d'un service, ou dans certaines conditions, de faire partager une adresse à plusieurs points de terminaison.
Application cliente (client application)	Une application cliente est un programme qui échange des messages avec un ou plusieurs points de terminaison. L'application cliente commence par créer l'instance d'un client WCF et appelle les méthodes de ce client. Il est important de noter qu'une même application peut être à la fois un client et un service.
Canal (channel)	Un canal est une implémentation concrète d'un élément de liaison. La liaison représente la configuration, et le canal est l'implémentation associée à cette configuration. Par conséquent, un canal est associé à chaque élément de liaison. Les canaux s'empilent les uns sur les autres pour créer l'implémentation concrète de la liaison : la pile de canaux.
Client WCF (WCF client)	Un client WCF est une construction d'application cliente qui expose les opérations de service en tant que méthodes dans le langage de programmation .NET Framework de votre choix, tel que Visual Basic ou Visual C#. N'importe quelle application peut accueillir un client WCF, y compris une application hébergeant un service. Par conséquent, il est possible de créer un service qui inclut des clients WCF d'autres services. Vous pouvez utiliser Service Model Metadata Tool (Svcutil.exe) pour créer automatiquement un client WCF et pour le faire pointer vers un service en cours qui publie des métadonnées.
Codage (coding)	Permet au développeur de conserver un contrôle étroit sur tous les composants du service ou client, et tous les paramètres définis par la configuration peuvent être inspectés et, au besoin, être remplacés par le code. Le contrôle d'une application peut être réalisé par le codage, par la configuration, ou par les deux.
Comportement (behavior)	Un comportement est un composant qui contrôle plusieurs aspects de l'exécution d'un service, d'un point de terminaison, d'une opération particulière ou d'un client. Les comportements sont groupés en fonction de leur portée : les comportements courants affectent tous les points de terminaison globalement, les comportements de service affectent uniquement des aspects relatifs à un service, les comportements de point de terminaison affectent uniquement des propriétés connexes à un point de terminaison, et les comportements au niveau de l'opération affectent des opérations particulières.
Configuration	La configuration a l'avantage de permettre à quelqu'un d'autre que le développeur (par exemple, un administrateur réseau) de définir les paramètres de client et de service après que le code a été écrit et sans devoir le recompiler. La configuration vous permet non seulement de définir des valeurs comme des adresses de point de terminaison, mais aussi de procéder à un contrôle approfondi en vous permettant d'ajouter des points de terminaison, des liaisons et des comportements. Le contrôle d'une application peut être réalisé par la configuration, par le codage, ou par les deux.
Contrat (contract)	Un contrat est une spécification de support correspondant au type de contrat impliqué. Par exemple, un contrat de service est une spécification correspondant à un groupe d'opérations. Dans WCF, les contrats sont répertoriés selon une hiérarchie qui est également indiquée dans les objets de description se trouvant dans l'espace de noms System.ServiceModel.Description. Dans WCF, un contrat de service a l'étendue la plus importante. Chaque opération de service d'un contrat de service dispose d'un contrat d'opération qui indique les messages (messages d'erreur compris) pouvant être échangés lors de l'opération, ainsi que la direction utilisée. Chaque message d'une opération dispose d'un contrat de message et d'une spécification correspondant à la structure d'enveloppe pour message SOAP. Chaque contrat de message dispose d'un contrat de données qui spécifie les structures de données contenues dans les messages.
Contrat de données (data contract)	Les types de données qu'un service utilise doivent être décrits dans les métadonnées afin de permettre à d'autres personnes d'interagir avec ce service. Les descriptions des types de données sont connues comme le contrat de données, et les types peuvent être utilisés dans toute partie d'un message, par exemple comme paramètres ou types de retour. Si le service n'utilise que des types simples, l'utilisation explicite des contrats de données est inutile.
Contrat de message (message contract)	Un contrat de message décrit le format d'un message. Par exemple, il déclare si les éléments du message doivent se trouver dans les en-têtes au lieu du corps, quel niveau de sécurité doit être appliqué à quels éléments du message, et ainsi de suite.
Contrat de service (service contract)	Le contrat de service joint plusieurs opérations connexes dans une unité fonctionnelle unique. Il peut définir des paramètres au niveau du service, tels que l'espace de noms du service, un contrat de rappel correspondant et d'autres paramètres de ce type. Dans la plupart des cas, le contrat est défini par la création d'une interface dans le langage de programmation de votre choix et par l'application de l'attribut T:System.ServiceModel.ServiceContractAttribute à cette interface. Le code de service réel résulte de l'implémentation de l'interface.
Contrat d'erreur (fault contract)	Un contrat d'erreur peut être associé à une opération de service pour désigner des erreurs qui peuvent être renvoyées à l'appelant. Une opération peut être associée à plusieurs erreurs ou n'être associée à aucune erreur. Il s'agit d'erreurs SOAP modélisées comme des exceptions dans le modèle de programmation. L'exception est convertie en une erreur SOAP qui peut ensuite être envoyée au client.
Contrat d'opération (operation contract)	Un contrat d'opération définit les paramètres et le type de retour d'une opération. Lorsque vous créez une interface qui définit le contrat de service, vous indiquez un contrat d'opération en appliquant l'attribut T:System.ServiceModel.OperationContractAttribute à chaque définition de méthode qui fait partie du contrat. Les opérations peuvent être conçues de manière à prendre un message unique et à renvoyer un message unique, ou à prendre un jeu de types et à renvoyer un type. Dans ce dernier cas, le système détermine le format des messages qui sont échangés lors de cette opération.
Élément de liaison (binding element)	Un élément de liaison représente un composant particulier de la liaison, tel qu'un transport, un codage, une implémentation d'un protocole au niveau de l'infrastructure (comme WS-ReliableMessaging) ou tout autre composant de la pile de communication.
Hébergement (hosting)	Un service doit être hébergé dans un processus. Un hôte est une application qui contrôle la durée de vie du service. Les services peuvent être auto-hébergés ou gérés par un processus d'hébergement existant.
Liaison (binding)	Une liaison définit la façon dont un point de terminaison communique avec le monde. Elle est construite à l'aide d'un ensemble de composants appelés éléments de liaison qui "s'empilent" les uns sur les autres pour créer l'infrastructure de communication. Au minimum, une liaison définit le transport (HTTP ou TCP par exemple) et le codage utilisés (tel que texte ou binaire). Une liaison peut contenir des éléments de liaison qui spécifient des informations détaillées comme les mécanismes de sécurité utilisés pour sécuriser les messages, ou le modèle de message utilisé par un point de terminaison.
Liaisons fournies par le système (system-provided bindings)	WCF inclut plusieurs liaisons fournies par le système. Il s'agit de collections d'éléments de liaison optimisés pour des scénarios spécifiques. Par exemple, T:System.ServiceModel.WSHttpBinding a été conçu à des fins d'interopérabilité avec les services qui implémentent les diverses spécifications WS-*. Ces liaisons permettent de gagner du temps car elles présentent uniquement les options pouvant être appliquées correctement au scénario spécifique. Si aucune ne répond pas à vos critères, vous pouvez créer votre propre liaison personnalisée.
Message	Un message est une unité autonome de données qui peut se composer de plusieurs parties, y compris d'un corps et d'un en-tête.
Métadonnées (metadata)	Les métadonnées d'un service décrivent les caractéristiques du service qu'une entité externe doit comprendre pour communiquer avec ce service. Elles peuvent être utilisées par Service Model Metadata Tool (Svcutil.exe) afin de créer un client WCF et de le configurer de sorte qu'une application cliente puisse utiliser cette configuration pour interagir avec le service. Les métadonnées exposées par le service incluent des documents de schéma XML qui définissent le contrat de données du service, et des documents WSDL qui décrivent les méthodes du service. En cas d'activation, les métadonnées du service sont générées automatiquement par WCF par inspection du service et de ses points de terminaison. Pour publier les métadonnées d'un service, vous devez explicitement activer le comportement des métadonnées.
Mode de sécurité du message (message security mode)	Le mode de sécurité du message indique que la sécurité est assurée par implémentation d'une ou de plusieurs des caractéristiques de sécurité. Chaque message contient les mécanismes nécessaires pour assurer la sécurité pendant son transfert et permettre aux récepteurs de détecter toute falsification et de déchiffrer le message. En ce sens, la sécurité est encapsulée dans chaque message, en assurant la sécurité de bout en bout sur des sauts multiples. Étant donné que les informations de sécurité deviennent une partie du message, il est également possible d'inclure plusieurs types d'informations d'identification dans le message (connus sous le nom de revendications). Cette approche a également l'avantage de permettre au message de voyager en toute sécurité sur n'importe quel transport, y compris les transports multiples, entre son origine et sa destination. L'inconvénient de cette approche réside dans la complexité des mécanismes de chiffrement employés, ce qui affecte les performances.
Mode de sécurité du transport (transport security mode)	La sécurité peut être fournie par l'un de ces trois modes : le mode de transport, le mode de sécurité du message et le mode de transport avec informations d'identification dans le message. Le mode de sécurité du transport spécifie que la confidentialité, l'intégrité et l'authentification sont assurées par les mécanismes de la couche de transport (telle que HTTPS). Lors de l'utilisation d'un transport comme le HTTPS, ce mode a l'avantage d'être efficace en termes de performances, et d'être bien compris grâce à sa prédominance sur Internet. L'inconvénient est que ce type de sécurité est appliqué séparément sur chaque saut dans le chemin de communication, et expose la communication à des attaques de type "homme du milieu".
Mode de sécurité du transport avec informations d'identification dans le message (transport with message credential security mode)	Ce mode utilise la couche de transport pour assurer la confidentialité, l'authentification et l'intégrité des messages, tandis que chacun des messages peut contenir plusieurs informations d'identification (revendications) requises par les récepteurs du message.
Modèle d'instanciation (instancing model)	Un service dispose d'un modèle d'instanciation. Il existe trois modèles d'instanciation : "unique", dans lequel un objet CLR unique prend en charge tous les clients ; "par appel", dans lequel un nouvel objet CLR est créé pour gérer chaque appel du client ; et "par session", dans lequel un ensemble d'objets CLR est créé, un pour chaque session. Le choix d'un modèle d'instanciation dépend des spécifications de l'application et du modèle d'utilisation attendu du service.
Opération de service (service operation)	Une opération de service est une procédure définie dans le code d'un service qui implémente les fonctionnalités d'une opération. Cette opération est exposée aux clients de la même manière que le sont les méthodes sur un client WCF. La méthode peut renvoyer une valeur et prendre un nombre facultatif d'arguments, ou ne prendre aucun argument et renvoyer une réponse négative. Par exemple, une opération qui fonctionne comme un simple "Bonjour" peut être utilisée comme notification de la présence d'un client et pour commencer une série d'opérations.
Opération de terminaison (terminating operation)	Opération appelée comme dernier message dans une session existante. Par défaut, WCF recycle l'objet du service et son contexte après la fermeture de la session à laquelle le service a été associé.
Opération d'initialisation (initiating operation)	Opération appelée comme opération initiale d'une nouvelle session. Vous devez appeler au moins une opération d'initialisation avant de pouvoir appeler d'autres opérations.
Point de terminaison (endpoint)	Un point de terminaison est une construction à laquelle les messages sont envoyés ou de laquelle ils sont reçus (ou les deux). Il comprend un emplacement (une adresse) qui définit où les messages peuvent être envoyés, une spécification du mécanisme de communication (une liaison) qui décrit la façon dont les messages doivent être envoyés, ainsi qu'une définition de l'ensemble de messages pouvant être envoyés ou reçus (ou les deux) à cet emplacement (un contrat de service) et qui décrit les messages pouvant être envoyés. Un service WCF est exposé au monde extérieur comme une collection de points de terminaison.
Point de terminaison d'application (application endpoint)	Point de terminaison exposé par l'application et qui correspond à un contrat de service implémenté par l'application.
Processus d'hébergement (hosting process)	Un processus d'hébergement est une application conçue pour héberger des services. Ces derniers incluent les services IIS (Internet Information Services), les services WAS (Windows Activation Services) et les services Windows. Dans ces scénarios hébergés, l'hôte contrôle la durée de vie du service. Par exemple, vous pouvez installer un répertoire virtuel qui contient l'assembly de service et le fichier de configuration à l'aide d'IIS. Lorsqu'un message est reçu, IIS démarre le service et contrôle sa durée de vie.
Sécurité (security)	La sécurité dans WCF inclut la confidentialité (le chiffrement des messages pour éviter l'espionnage), l'intégrité (la détection de la falsification des messages), l'authentification (la validation des serveurs et des clients) et l'autorisation (le contrôle de l'accès aux ressources). Ces fonctions sont fournies en tirant parti de mécanismes de sécurité existants, tels que le protocole TLS sur HTTP (également connu sous le nom de HTTPS), ou en implémentant une ou plusieurs spécifications de sécurité WS-*.
Service	Un service est une construction qui expose un ou plusieurs points de terminaison, chacun de ces derniers exposant une ou plusieurs opérations de service.
Service auto-hébergé (self-hosted service)	Un service auto-hébergé s'exécute dans une application de processus créée par le développeur. Ce dernier définit les propriétés du service, contrôle sa durée de vie, ouvre le service (ce qui le définit en mode d'écoute) et le ferme.
WS-*	Abrégé pour l'ensemble croissant des spécifications de services Web (WS), telles que WS-Security, WS-ReliableMessaging et ainsi de suite, implémentées dans WCF.