Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Ce document fournit une vue générale de l’architecture Windows Communication Foundation (WCF). Il est destiné à expliquer les concepts clés et comment ils s’intègrent ensemble. Pour obtenir un didacticiel sur la création de la version la plus simple d’un service WCF et d’un client, consultez didacticiel de prise en main. Pour découvrir la programmation WCF, consultez Programmation WCF de base.
Notions de base de WCF
WCF est un runtime et un ensemble d’API permettant de créer des systèmes qui envoient des messages entre les services et les clients. La même infrastructure et les mêmes API sont utilisées pour créer des applications qui communiquent avec d’autres applications sur le même système informatique ou sur un système qui réside dans une autre entreprise et qui est accessible via Internet.
Messagerie et points de terminaison
WCF est basé sur la notion de communication basée sur les messages, et tout ce qui peut être modélisé en tant que message (par exemple, une requête HTTP ou un message Message Queuing (également appelé MSMQ) peut être représenté de manière uniforme dans le modèle de programmation. Cela permet une API unifiée entre différents mécanismes de transport.
Le modèle fait la distinction entre les clients, qui sont des applications qui initient la communication et les services, qui sont des applications qui attendent que les clients communiquent avec eux et répondent à cette communication. Une application unique peut agir à la fois comme un client et un service. Pour obtenir des exemples, consultez Les services Duplex et la mise en réseau d’égal à égal.
Les messages sont envoyés entre les points de terminaison. Les points de terminaison sont des emplacements où les messages sont envoyés ou reçus (ou les deux) et définissent toutes les informations requises pour l’échange de messages. Un service expose un ou plusieurs points de terminaison d’application (ainsi que zéro ou plusieurs points de terminaison d’infrastructure) et le client génère un point de terminaison compatible avec l’un des points de terminaison du service.
Un point de terminaison décrit de manière standard où les messages doivent être envoyés, comment ils doivent être envoyés et ce à quoi les messages doivent ressembler. Un service peut exposer ces informations en tant que métadonnées que les clients peuvent traiter afin de générer les clients WCF et les piles de communication appropriés.
Protocoles de communication
L’un des éléments requis de la pile de communication est le protocole de transport. Les messages peuvent être envoyés via des intranets et Internet à l’aide de transports courants, tels que HTTP et TCP. D'autres transports inclus prennent en charge la communication avec les applications et les nœuds Message Queuing sur une maille de réseau homologue. D’autres mécanismes de transport peuvent être ajoutés à l’aide des points d’extension intégrés de WCF.
Un autre élément requis dans la pile de communication est l’encodage qui spécifie la façon dont un message donné est mis en forme. WCF fournit les encodages suivants :
Encodage de texte, encodage interopérable.
Encodage MTOM (Message Transmission Optimization Mechanism), qui est un moyen interopérable d’envoyer efficacement des données binaires non structurées vers et depuis un service.
Encodage binaire pour un transfert efficace.
D’autres mécanismes d’encodage (par exemple, un encodage de compression) peuvent être ajoutés à l’aide des points d’extension intégrés de WCF.
Modèles de message
WCF prend en charge plusieurs modèles de messagerie, notamment la requête-réponse, la communication unidirectionnelle et duplex. Les différents transports prennent en charge différents modèles de messagerie et affectent ainsi les types d’interactions qu’ils prennent en charge. Les API WCF et le runtime vous aident également à envoyer des messages de manière sécurisée et fiable.
Termes WCF
D’autres concepts et termes utilisés dans la documentation WCF sont les suivants :
Message Unité autonome de données qui peut se composer de plusieurs parties, y compris un corps et des en-têtes.
Service Construction qui expose un ou plusieurs points de terminaison, avec chaque point de terminaison exposant une ou plusieurs opérations de service.
Extrémité Construction à laquelle les messages sont envoyés ou 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 et une définition d’un ensemble de messages qui peuvent être envoyés ou reçus (ou les deux) à cet emplacement (un contrat de service) qui décrit le message qui peut être envoyé.
Un service WCF est exposé au monde sous la forme d’une collection de points de terminaison.
Point de terminaison d’application Point de terminaison exposé par l’application et qui correspond à un contrat de service implémenté par l’application.
Point de terminaison d’infrastructure Point de terminaison exposé par l’infrastructure pour faciliter les fonctionnalités nécessaires ou fournies par le service qui n’est pas lié à un contrat de service. Par exemple, un service peut avoir un point de terminaison d’infrastructure qui fournit des informations de métadonnées.
Adresse Spécifie l’emplacement où les messages sont reçus. Il est spécifié en tant qu’URI (Uniform Resource Identifier). La partie schéma URI nomme le mécanisme de transport à utiliser pour atteindre l’adresse, par exemple 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 de point de terminaison uniques pour chaque point de terminaison d’un service ou, dans certaines conditions, de partager une adresse entre les points de terminaison. L’exemple suivant montre une adresse utilisant le protocole HTTPS avec un port non par défaut :
HTTPS://cohowinery:8005/ServiceModelSamples/CalculatorService
Configuration de liaison Définit la façon dont un point de terminaison communique avec l'extérieur. Il est construit d’un ensemble de composants appelés éléments de liaison qui « empilent » l’un sur l’autre pour créer l’infrastructure de communication. Au moins, une liaison définit le transport (tel que HTTP ou TCP) et l’encodage utilisé (par exemple, du texte ou du binaire). Une liaison peut contenir des éléments de liaison qui spécifient des détails tels que 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. Pour plus d’informations, consultez Configuration des services.
Élément de liaison Représente un élément particulier de la liaison, tel qu'un transport, un encodage, une implémentation d'un protocole au niveau de l'infrastructure (par exemple, WS-ReliableMessaging) ou un composant quelconque de la pile de communication.
Comportements Composant qui contrôle différents aspects d’exécution d’un service, d’un point de terminaison, d’une opération particulière ou d’un client. Les comportements sont regroupés en fonction de l’étendue : les comportements courants affectent tous les points de terminaison globalement, les comportements de service affectent uniquement les aspects liés au service, les comportements de point de terminaison affectent uniquement les propriétés liées aux points de terminaison et les comportements au niveau de l’opération affectent des opérations particulières. Par exemple, un comportement de service est la régulation, qui spécifie comment un service réagit lorsqu'un excès de messages menace de surcharger ses capacités de traitement. En revanche, un comportement de point de terminaison contrôle uniquement les aspects pertinents pour les points de terminaison, tels que la façon et l’emplacement de recherche d’informations d’identification de sécurité.
Liaisons fournies par le système WCF inclut un certain nombre de 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, WSHttpBinding est conçu pour l’interopérabilité avec les services qui implémentent différentes spécifications WS-*. Ces liaisons prédéfinies gagnent du temps en présentant uniquement les options qui peuvent être appliquées correctement au scénario spécifique. Si une liaison prédéfinie ne répond pas à vos besoins, vous pouvez créer votre propre liaison personnalisée.
Configuration et codage Le contrôle d’une application peut être effectué via le codage, la configuration ou une combinaison des deux. La configuration présente l’avantage d’autoriser quelqu’un d’autre que le développeur (par exemple, un administrateur réseau) à définir des paramètres client et de service une fois le code écrit et sans avoir à recompiler. La configuration vous permet non seulement de définir des valeurs telles que des adresses de point de terminaison, mais également de contrôler davantage en vous permettant d’ajouter des points de terminaison, des liaisons et des comportements. Le codage permet au développeur de conserver un contrôle strict sur tous les composants du service ou du client, et tous les paramètres effectués via la configuration peuvent être inspectés et, si nécessaire, remplacés par le code.
Opération de service 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 en tant que méthodes sur un client WCF. La méthode peut retourner une valeur et peut prendre un nombre facultatif d’arguments, ou ne prendre aucun argument, et retourner aucune réponse. Par exemple, une opération qui fonctionne comme un simple « Hello » peut être utilisée comme notification de la présence d’un client et pour commencer une série d’opérations.
Contrat de service Associe plusieurs opérations associées à une seule unité fonctionnelle. Le contrat 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 en créant une interface dans le langage de programmation de votre choix et en appliquant l’attribut ServiceContractAttribute à l’interface. Le code de service réel résulte de l'implémentation de l'interface.
Contrat d’opération Un contrat d’opération définit les paramètres et le type de retour d’une opération. Lors de la création d’une interface qui définit le contrat de service, vous signifiez un contrat d’opération en appliquant l’attribut OperationContractAttribute à chaque définition de méthode qui fait partie du contrat. Les opérations peuvent être modélisées comme prenant un seul message et retournant un seul message, ou comme prenant un ensemble de types et renvoyant un type. Dans ce dernier cas, le système détermine le format des messages qui doivent être échangés pour cette opération.
Contrat de message Décrit le format d’un message. Par exemple, elle déclare si les éléments de message doivent figurer dans des en-têtes par rapport au corps, quel niveau de sécurité doit être appliqué aux éléments du message, et ainsi de suite.
Contrat d’erreur Peut être associé à une opération de service pour indiquer les erreurs qui peuvent être retournées à l’appelant. Une opération peut avoir zéro ou plusieurs erreurs associées. Ces erreurs sont des erreurs SOAP qui sont modélisées en tant qu’exceptions dans le modèle de programmation.
Contrat de données Descriptions dans les métadonnées des types de données qu’un service utilise. Cela permet aux autres utilisateurs d’interagir avec le service. Les types de données peuvent être utilisés dans n’importe quelle partie d’un message, par exemple, en tant que paramètres ou types de retour. Si le service utilise uniquement des types simples, il n’est pas nécessaire d’utiliser explicitement des contrats de données.
Hébergement 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.
Service auto-hébergé Service qui s’exécute dans une application de processus créée par le développeur. Le développeur contrôle sa durée de vie, définit les propriétés du service, ouvre le service (qui le définit en mode d’écoute) et ferme le service.
Processus d’hébergement Application conçue pour héberger des services. Il s’agit notamment d’Internet Information Services (IIS), des services d’activation Windows (WAS) et des services Windows. Dans ces scénarios hébergés, l’hôte contrôle la durée de vie du service. Par exemple, à l’aide d’IIS, vous pouvez configurer un répertoire virtuel qui contient l’assembly de service et le fichier de configuration. Lorsqu’un message est reçu, IIS démarre le service et contrôle sa durée de vie.
Instanciation Un service a un modèle d’instanciation. Il existe trois modèles d’instanciation : « single », dans lequel un seul objet CLR services tous les clients ; » par appel », dans lequel un nouvel objet CLR est créé pour gérer chaque appel client ; et « par session », dans lesquels un ensemble d’objets CLR est créé, un pour chaque session distincte. Le choix d’un modèle d’instanciation dépend des exigences de l’application et du modèle d’utilisation attendu du service.
Application cliente Programme qui échange des messages avec un ou plusieurs points de terminaison. L’application cliente commence par créer une instance d’un client WCF et appeler des méthodes du client WCF. Il est important de noter qu’une seule application peut être à la fois un client et un service.
Canal 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, il existe un canal 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 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, comme Visual Basic ou Visual C#). Toute application peut héberger un client WCF, y compris une application qui héberge un service. Par conséquent, il est possible de créer un service qui inclut des clients WCF d’autres services.
Un client WCF peut être généré automatiquement à l’aide de l’outil utilitaire de métadonnées ServiceModel (Svcutil.exe) et le pointer vers un service en cours d’exécution qui publie des métadonnées.
Métadonnées Dans un service, décrit les caractéristiques du service qu’une entité externe doit comprendre pour communiquer avec le service. Les métadonnées peuvent être consommées par l’outil Utilitaire de métadonnées ServiceModel (Svcutil.exe) pour générer un client WCF et la configuration associée à laquelle une application cliente peut utiliser 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.
Lorsque cette option est activée, les métadonnées du service sont générées automatiquement par WCF en inspectant le service et ses points de terminaison. Pour publier des métadonnées à partir d’un service, vous devez activer explicitement le comportement des métadonnées.
Sécurité Dans WCF, inclut la confidentialité (chiffrement des messages pour empêcher l’écoute électronique), l’intégrité (les moyens de détection de falsification du message), l’authentification (les moyens de validation des serveurs et des clients) et l’autorisation (contrôle de l’accès aux ressources). Ces fonctions sont fournies en tirant parti des mécanismes de sécurité existants, tels que TLS sur HTTP (également appelé HTTPS), ou en implémentant une ou plusieurs des différentes spécifications de sécurité WS-*.
Mode de sécurité du transport Spécifie que la confidentialité, l’intégrité et l’authentification sont fournies par les mécanismes de couche de transport (tels que HTTPS). Lorsque vous utilisez un transport comme HTTPS, ce mode présente l’avantage d’être efficace dans ses performances et bien compris en raison de sa prévalence sur Internet. L'inconvénient est que ce type de sécurité est appliqué séparément à chaque étape du chemin de communication, ce qui rend la communication susceptible à une attaque de type ‘homme du milieu’.
Mode de sécurité des messages Spécifie que la sécurité est fournie en implémentant une ou plusieurs spécifications de sécurité, telles que la spécification nommée Sécurité des services Web : SOAP Message Security. Chaque message contient les mécanismes nécessaires pour assurer la sécurité pendant son transit et permettre aux destinataires de détecter la falsification et de déchiffrer les messages. Dans ce sens, la sécurité est encapsulée dans chaque message, fournissant une sécurité de bout en bout sur plusieurs tronçons. Étant donné que les informations de sécurité font partie du message, il est également possible d’inclure plusieurs types d’informations d’identification avec le message (elles sont appelées revendications). Cette approche présente également l’avantage de permettre au message de voyager en toute sécurité sur n’importe quel transport, y compris plusieurs transports entre son origine et sa destination. L’inconvénient de cette approche est la complexité des mécanismes de chiffrement utilisés, ce qui entraîne des implications sur les performances.
Transport avec le mode de sécurité des informations d’identification du message Spécifie l’utilisation de 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.
WS-* Raccourci pour l’ensemble croissant de spécifications de service web (WS), telles que WS-Security, WS-ReliableMessaging, etc., qui sont implémentées dans WCF.