Notes
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.
Cette section vous montre comment définir et implémenter des contrats WCF. Un contrat de service spécifie ce qu’un point de terminaison communique au monde extérieur. À un niveau plus concret, il s’agit d’une déclaration sur un ensemble de messages spécifiques organisés en modèles d’échange de messages de base (MEPS), tels que la demande/réponse, l’unidirectionnel et le duplex. Si un contrat de service est un ensemble logique d’échanges de messages, une opération de service est un seul échange de messages. Par exemple, une Hello opération doit évidemment accepter un message (de sorte que l’appelant peut annoncer le message d’accueil) et peut ou non retourner un message (selon la courtoisie de l’opération).
Pour plus d’informations sur les contrats et d’autres concepts de base de Windows Communication Foundation (WCF), consultez Concepts fondamentaux de Windows Communication Foundation. Cette rubrique se concentre sur la compréhension des contrats de service. Pour plus d’informations sur la création de clients qui utilisent des contrats de service pour se connecter aux services, consultez Vue d’ensemble du client WCF.
Aperçu
Cette rubrique fournit une orientation conceptuelle de haut niveau pour concevoir et implémenter des services WCF. Les sous-rubriques fournissent des informations plus détaillées sur les spécificités de la conception et de l’implémentation. Avant de concevoir et d’implémenter votre application WCF, il est recommandé de :
Comprenez ce qu’est un contrat de service, comment il fonctionne et comment en créer un.
Comprenez que les contrats précisent des exigences minimales que la configuration à l’exécution ou l’environnement d’hébergement peuvent ne pas prendre en charge.
Contrats de service
Un contrat de service spécifie les éléments suivants :
Les opérations exposées par un contrat.
Signature des opérations en termes de messages échangés.
Types de données de ces messages.
Emplacement des opérations.
Protocoles et formats de sérialisation spécifiques utilisés pour prendre en charge la communication réussie avec le service.
Par exemple, un contrat de bon de commande peut avoir une CreateOrder opération qui accepte une entrée de types d’informations de commande et retourne des informations de réussite ou d’échec, y compris un identificateur de commande. Il peut également avoir une GetOrderStatus opération qui accepte un identificateur de commande et retourne des informations d’état de commande. Un contrat de service de ce type spécifie :
que le contrat de commande fournisseur serait composé d'opérations
CreateOrderetGetOrderStatus;Que les opérations ont spécifié les messages d’entrée et les messages de sortie.
Données que ces messages peuvent contenir.
Instructions catégorielles sur l’infrastructure de communication nécessaire pour traiter correctement les messages. Par exemple, ces détails incluent si et quelles formes de sécurité sont requises pour établir une communication réussie.
Pour transmettre ce type d’informations à d’autres applications sur de nombreuses plateformes (y compris les plateformes non-Microsoft), les contrats de service XML sont exprimés publiquement dans des formats XML standard, tels que le langage WSDL ( Web Services Description Language ) et le schéma XML (XSD), entre autres. Les développeurs pour de nombreuses plateformes peuvent utiliser ces informations de contrat public pour créer des applications qui peuvent communiquer avec le service, à la fois parce qu’elles comprennent le langage de la spécification et parce que ces langues sont conçues pour permettre l’interopérabilité en décrivant les formulaires publics, les formats et les protocoles pris en charge par le service. Pour plus d’informations sur la façon dont WCF gère ce type d’informations, consultez Métadonnées.
Les contrats peuvent être exprimés de nombreuses façons, et bien que WSDL et XSD soient d’excellents langages pour décrire les services d’une manière accessible, ils sont difficiles à utiliser directement et sont simplement des descriptions d’un service, et non des implémentations de contrat de service. Par conséquent, les applications WCF utilisent des attributs managés, des interfaces et des classes pour définir la structure d’un service et l’implémenter.
Le contrat résultant défini dans les types managés peut être exporté en tant que métadonnées ( WSDL et XSD) lorsque nécessaire par les clients ou d’autres implémenteurs de service. Le résultat est un modèle de programmation simple qui peut être décrit (à l’aide de métadonnées publiques) à n’importe quelle application cliente. Les détails des messages SOAP sous-jacents, les informations relatives au transport et à la sécurité, et ainsi de suite, peuvent être laissés à WCF, qui effectue les conversions nécessaires vers et depuis le système de type de contrat de service vers le système de type XML automatiquement.
Pour plus d’informations sur la conception de contrats, consultez Conception de contrats de service. Pour plus d’informations sur l’implémentation de contrats, consultez Implémentation de contrats de service.
Messages au premier plan
L’utilisation d’interfaces gérées, de classes et de méthodes pour modéliser les opérations de service est simple lorsque vous êtes habitué aux signatures de méthode de style RPC (appel de procédure distante), dans lesquelles passer des paramètres à une méthode et recevoir des valeurs de retour est la forme normale de demande de fonctionnalités à un objet ou un autre type de code. Par exemple, les programmeurs utilisant des langages managés tels que Visual Basic et C++ COM peuvent appliquer leurs connaissances de l’approche de style RPC (que ce soit à l’aide d’objets ou d’interfaces) à la création de contrats de service WCF sans rencontrer les problèmes inhérents aux systèmes d’objets distribués de style RPC. La programmation orientée service présente les mêmes avantages que la programmation orientée message faiblement couplée tout en permettant aux développeurs de continuer à bénéficier de la convivialité de la programmation RPC.
De nombreux programmeurs sont plus à l’aise avec les interfaces de programmation d’applications orientées messages, telles que les files d’attente de messages telles que Microsoft MSMQ, les System.Messaging espaces de noms dans le .NET Framework ou l’envoi de xml non structuré dans les requêtes HTTP, pour en nommer quelques-uns. Pour plus d’informations sur la programmation au niveau du message, consultez Utilisation des contrats de message, du service Channel-Level programmation et de l’interopérabilité avec les applications POX.
Présentation de la hiérarchie des exigences
Un contrat de service regroupe les opérations ; spécifie le modèle d’échange de messages, les types de messages et les types de données que ces messages portent ; et indique les catégories de comportement d’exécution qu’une implémentation doit avoir à prendre en charge le contrat (par exemple, il peut exiger que les messages soient chiffrés et signés). Le contrat de service lui-même ne spécifie pas précisément la façon dont ces exigences sont remplies, seulement qu’elles doivent être. Le type de chiffrement ou la manière dont un message est inscrit est à la mise en œuvre et à la configuration d’un service conforme.
Remarquez la façon dont le contrat requiert certaines choses de l'implémentation de contrat de service et de la configuration à l'exécution pour ajouter un comportement. L'ensemble des exigences qui doivent être remplies pour exposer un service à utiliser s’appuie sur l'ensemble précédent d'exigences. Si un contrat établit des exigences de l’implémentation, une implémentation peut nécessiter davantage de configuration et de liaisons qui permettent au service d’exécuter. Enfin, l’application hôte doit également prendre en charge les exigences que la configuration et les liaisons de service ajoutent.
Ce processus d’exigence additif est important de garder à l’esprit lors de la conception, de l’implémentation, de la configuration et de l’hébergement d’une application de service Windows Communication Foundation (WCF). Par exemple, le contrat peut spécifier qu’il doit prendre en charge une session. Si c’est le cas, vous devez configurer la liaison pour prendre en charge cette exigence contractuelle, ou l’implémentation du service ne fonctionnera pas. Ou si votre service nécessite l’authentification intégrée Windows et est hébergé dans Internet Information Services (IIS), l’application web dans laquelle réside le service doit avoir l’authentification intégrée Windows activée et la prise en charge anonyme désactivée. Pour plus d’informations sur les fonctionnalités et l’impact des différents types d’applications hôtes de service, consultez Services d’hébergement.