Chapitre29 Visual C# 2010 etape par etape - Web Services SOAP .net

Partie 6 – Création de solutions professionnelles

© Dunod 2010 – Visual C#2010 Étape par étape – John Sharp

Chapitre 29

Création et utilisation d’un service Web

Au terme de ce chapitre, vous saurez :

■ Créer des services Web SOAP et REST qui exposent des méthodes Web simples.

■ Afficher la description d’un service Web SOAP en utilisant Internet Ex-plorer.

■ Concevoir des classes qui peuvent être passées en paramètre à une méthode Web et renvoyées à partir d’une méthode Web.

■ Créer des proxys pour des services Web SOAP et REST d’une applica-tion cliente.

■ Appeler une méthode Web REST en utilisant Internet Explorer.

■ Appeler des méthodes Web à partir d’une application cliente.

Les chapitres précédents vous ont montré comment construire des appli-cations bureautiques monopostes qui peuvent effectuer une grande varié-té de tâches. Cependant, très peu de systèmes opèrent aujourd’hui sans être connectés. Une entreprise effectue des opérations commerciales et possède en général des applications réseau qui prennent en charge ces activités. De plus, nous sommes maintenant à l’ère d’Internet et une entre-prise peut composer des solutions qui incorporent différents services tiers. Le défi est d’arriver à combiner ces morceaux ensemble pour leur permettre de communiquer et de coopérer d’une manière transparente.

Les services Web fournissent une solution à ce problème. Grâce à eux, vous pouvez générer des systèmes distribués à partir des éléments qui sont diffu-sés sur Internet (les bases de données, les services métiers, etc.). Les com-posants et les services sont hébergés par un serveur Web qui reçoit des

Chapitre 29 – Création et utilisation d’un service Web

©Dunod 2010 – Visual C#2010 Étape par étape – John Sharp

demandes d’une application cliente, les analyse, et envoie la commande correspondante au composant ou service. La réponse est routée via le ser-veur Web vers l’application cliente.

Le but de ce chapitre est de vous montrer comment concevoir, générer et tester des services Web qui peuvent être intégrés dans des applications dis-tribuées. Vous allez également apprendre à construire une application cliente qui utilise des méthodes exposées par un service Web.

Note Le but de ce chapitre est de fournir une introduction très sommaire aux services Web et à WCP (Windows Communication Foundation). Si vous souhai-tez des informations détaillées sur le fonctionnement de WCF et la manière de générer des services sécurisés avec WCF, vous devez consulter un ouvrage tel que Microsoft Windows Communication Foundation Step by Step, publié par Microsoft Press, 2007.

Qu’est-ce qu’un service Web ? Un service Web est un composant métier qui fournit des fonctionnalités utiles, réutilisables aux clients ou aux consommateurs. Un service Web peut être vu comme un composant avec une réelle accessibilité globale (si vous avez les droits d’accès appropriés, vous pouvez utiliser un service Web n’importe où dans le monde tant que votre ordinateur est connecté à In-ternet). Les services Web utilisent un protocole standard, accepté, et bien compris, HTTP (Hypertext Transfer Protocol), pour transmettre les données et un format de données portable qui est basé sur XML. HTTP et XML sont tous les deux des technologies standardisées qui peuvent être utilisées par d’autres environnements de programmation en dehors du Microsoft .NET Framework. Avec Microsoft Visual Studio 2010, vous pouvez concevoir des services Web avec Microsoft Visual C++, Microsoft Visual C#, ou Microsoft Visual Basic. Cependant, en ce qui concerne l’application cliente, le lan-gage utilisé pour créer le service Web, et même la manière dont le service Web effectue ses tâches, n’a pas d’importance. Les applications clientes s’exécutant dans un environnement totalement différent, comme Java, peuvent utiliser les services Web. L’inverse est également vrai : vous pouvez concevoir des services Web en utilisant Java et écrire des applications



clientes en C#.

Rôle de Windows Communication Foundation Windows Communication Foundation, ou WCF, a été introduit dans la ver-sion 3.0 du .NET Framework. Visual Studio fournit un ensemble de modèles que vous pouvez utiliser pour concevoir des services Web grâce à WCF. Cependant, les services Web ne sont qu’une des technologies que l’on peut employer pour créer des applications distribuées tournant sur les sys-tèmes d’exploitation Windows. Il en existe d’autres, comme Enterprise Ser-vices, .NET Framework Remoting, et Microsoft Message Queue (MSMQ). Si vous générez une application distribuée pour Windows, quelle technologie devez-vous utiliser, et sera-t-il difficile de changer de technologie plus tard si vous en avez besoin ? Le but de WCF est de fournir un modèle de pro-grammation unifié pour la plupart de ces technologies de manière à pou-voir générer des applications qui soient aussi indépendantes que possible du mécanisme sous-jacent utilisé pour se connecter aux services et aux applications (notez que WCF s’applique aussi bien aux services exploités dans des environnements non Web que sur le Web). Il est très difficile, sinon impossible, de séparer complètement la structure de programmation d’une application ou d’un service de son infrastructure de communica-tions, mais WCF permet d’approcher cet objectif la plupart du temps.

Pour résumer, si vous envisagez de concevoir des applications et des ser-vices distribués pour Windows, vous devez utiliser WCF. Les exercices de ce chapitre vous montreront comment faire.

Architectures de service Web Il existe deux architectures courantes que les entreprises utilisent pour im-plémenter des services Web : les services basés sur le modèle SOAP (Simple Object Access Protocol), et les services basés sur le modèle REST (Represen-tational State Transfer). Les deux architectures reposent sur le protocole HTTP omniprésent (le protocole utilisé par le Web pour envoyer et recevoir des pages HTML) et le schéma d’adressage utilisé par Internet, mais elles l’utilisent de manières différentes. Si vous concevez des solutions qui incor-



porent des services Web hébergés par des entreprises tierces, elles peuvent implémenter ces services Web en utilisant chacun de ces modèles, si bien que cela vous aidera d’avoir une bonne compréhension des deux archi-tectures qui sont décrites brièvement dans les sections suivantes.

Services Web SOAP Un service Web SOAP expose des fonctionnalités en utilisant le modèle procédural traditionnel ; la principale différence par rapport à une appli-cation de bureau ordinaire est que les procédures s’exécutent à distance sur un serveur Web. Une vue d’une application cliente d’un service Web est une interface qui expose un nombre de méthodes bien définies, con-nues en tant que méthodes Web. L’application cliente envoie des de-mandes à ces méthodes Web en utilisant les protocoles Internet standards, en transmettant des paramètres au format XML et en recevant des ré-ponses au format XML. Les méthodes Web SOAP peuvent interroger et modifier des données.

Rôle de SOAP SOAP est le protocole utilisé par les applications clientes pour envoyer des demandes et recevoir des réponses des services Web. SOAP est un proto-cole léger construit au sommet de HTTP. SOAP définit une grammaire XML pour spécifier les noms des méthodes Web que le client peut appeler sur un service Web, pour définir les paramètres et retourner des valeurs, et pour décrire les types des paramètres et retourner des valeurs. Lorsqu’un client appelle un service Web, il doit spécifier la méthode et les paramètres en utilisant cette grammaire XML.

SOAP est une norme industrielle dont la fonction est d’améliorer l’interopérabilité entre les plateformes. La force de SOAP est sa simplicité et aussi le fait qu’il soit basé sur d’autres technologies normalisées, comme HTTP et XML. La spécification SOAP définit notamment les éléments sui-vants :

■ Le format d’un message SOAP

■ La manière dont les données doivent être encodées



■ La manière dont les messages sont envoyés

■ La manière dont les réponses sont traitées

Les descriptions des détails exacts du fonctionnement de SOAP et le format interne d’un message SOAP dépassent le cadre de cet ouvrage. Il est très improbable que vous ayez un jour besoin de créer et de mettre en forme des messages SOAP manuellement car beaucoup d’outils de développe-ment, y compris Visual Studio 2010, automatisent ce traitement, en présen-tant une API simple aux développeurs construisant des services Web et des applications clientes.

Langage de description des services Web Le corps d’un message SOAP est un document XML. Lorsqu’une applica-tion cliente appelle une méthode Web, le serveur Web attend que le client utilise un ensemble de balises particulier pour encoder les paramètres de la méthode. Comment un client connaît-il les balises ou le schéma XML qu’il doit utiliser ? La réponse est qu’un service Web, quand il est sollicité, est censé fournir sa propre description. La réponse du service Web est un autre document XML qui décrit le service Web. Assez naturellement, ce docu-ment s’appelle la description du service Web. Le schéma XML utilisé pour ce document a été standardisé et se nomme WSDL (Web Services Descrip-tion Language, ou langage de description de services Web). Cette des-cription fournit assez d’informations pour qu’une application cliente puisse construire une demande SOAP dans un format susceptible d’être compris par le serveur Web. Encore une fois, les détails de WSDL dépassent le cadre de ce livre, mais Visual Studio 2010 contient des outils qui analysent le WSDL d’un service Web d’une manière automatique. Visual Studio 2010 utilise alors les informations pour définir une classe proxy qu’une application cliente peut utiliser pour convertir des appels ordinaires de méthode sur cette classe proxy en demandes SOAP que le proxy envoie sur le Web. C’est cette approche que vous allez utiliser dans les exercices de ce cha-pitre.



Exigences non fonctionnelles des services Web Les efforts initiaux pour définir les services Web et leurs standards associés se concentraient sur les aspects fonctionnels pour envoyer et recevoir des messages SOAP. Peu après que les services Web sont devenus une techno-logie courante pour intégrer des services distribués, il est apparu évident qu’il y avait des problèmes que SOAP et HTTP ne pouvaient pas traiter seuls. Ces problèmes concernent de nombreuses exigences non fonctionnelles qui sont importantes dans tout environnement distribué, mais bien plus en-core lorsqu’on utilise Internet comme base d’une solution distribuée. On peut notamment citer les éléments suivants :

■ Sécurité Comment s’assurer que les messages SOAP qui circulent entre un service Web et un client n’ont pas été interceptés et modifiés en chemin sur Internet ? Comment être sûr qu’un message SOAP a été envoyé réellement par le client ou par le service Web qui prétend l’avoir envoyé, et non pas par un faux site qui tente d’obtenir des in-formations frauduleusement ? Comment peut-on restreindre l’accès à un service Web à des utilisateurs spécifiques ? Il y a des problèmes d’intégrité de message, de confidentialité, et d’authentification et ce sont des questions fondamentales si l’on construit des applications dis-tribuées grâce à Internet.

Au début des années 1990, un certain nombre d’éditeurs fournissant des outils pour générer des systèmes distribués ont formé une organisation qui a pris plus tard le nom d’OASIS (Organization for the Advance-ment of Structured Information Standards). Quand les défauts de l’infrastructure des premiers services Web sont devenus apparents, les membres d’OASIS ont défini la spécification WS-Security. Cette spéci-fication décrit la manière de protéger les messages envoyés par les services Web. Les éditeurs qui souscrivent à WS-Security fournissent leurs propres implémentations respectant cette spécification, en utili-sant généralement des technologies comme le chiffrement et les cer-tificats.

■ Stratégie Bien que la spécification WS-Security définisse la manière d’améliorer la sécurité, les développeurs ont toujours besoin d’écrire du code pour l’implémenter. Les développeurs qui créent des services Web n’implémentent pas toujours très strictement le mécanisme de



sécurité. Par exemple, un service Web peut utiliser uniquement une forme relativement simple de chiffrement qui peut ainsi être facile-ment cassé. Un client envoyant des informations hautement confiden-tielles à ce service Web insistera probablement sur un niveau élevé de sécurité. Ceci est un exemple de stratégie, mais on peut citer aussi la qualité de service et la fiabilité du service Web. L’application cliente et le service Web peuvent négocier le niveau de service qu’ils souhai-tent utiliser en fonction des exigences et du coût. Cependant, cette négociation exige que le client et le service Web aient une compré-hension commune des stratégies disponibles. La spécification WS-Policy fournit un modèle générique et une syntaxe correspondante pour décrire et communiquer les stratégies qu’un service Web implé-mente.

■ Routage et adressage Il est utile pour un serveur Web d’être ca-pable de rediriger une demande de service Web vers une machine d’un groupe d’ordinateurs hébergeant des instances du service. Par exemple, de nombreux systèmes évolutifs utilisent l’équilibrage de charge, où les demandes envoyées à un serveur Web sont en fait re-dirigées par ce serveur vers d’autres ordinateurs pour répartir la charge sur ces ordinateurs. Le serveur peut utiliser n’importe quel al-gorithme pour essayer de répartir la charge. Le point important est que cette redirection est transparente pour le client effectuant la demande de service Web, et le serveur qui gère par la suite la de-mande doit savoir où envoyer les réponses qu’il génère. Rediriger les demandes de service Web est également utile si un administrateur a besoin d’arrêter un ordinateur pour effectuer de la maintenance. Les demandes qui ont été envoyées à cet ordinateur peuvent ainsi être redirigées vers une des machines du groupe. La spécification WS-Addressing décrit un système capable de rediriger les demandes de service Web.

Note Les développeurs parlent de spécifications WS-* pour faire référence aux spécifications WS-Security, WS-Policy et WS-Addressing.



Services Web REST À la différence des services Web SOAP, le modèle REST de services Web uti-lise un schéma navigationnel pour représenter les objets et les ressources métiers sur un réseau. Par exemple, une entreprise peut fournir l’accès aux informations des employés, en exposant les détails de chaque employé sous la forme d’une seule ressource, en utilisant un schéma similaire à celui-ci :

http://northwind.com/employees/7

L’accès à cette URL fait rechercher par le service Web les données de l’employé n° 7. Ces données peuvent être retournées dans de nombreux formats, mais pour des raisons de portabilité, les formats les plus courants sont XML (parfois appelé « Plain Old XML » ou POX) et JavaScript Object Notation (ou JSON). Si l’entreprise Northwind Traders choisit d’utiliser POX, le résultat retourné en interrogeant l’URL ci-dessus sera le suivant :

<Employee> <EmployeeID> 7 </EmployeeID> <LastName> King </LastName> <FirstName> Robert </FirstName> <Title> Sales Representative </Title> </Employee>

Pour concevoir une solution basée sur REST, vous devez bien comprendre comment il divise un modèle métier en un ensemble de ressources. Dans certains cas, tels que les employés, cela peut être simple, mais dans d’autres situations cela est un véritable défi.

Le modèle REST repose sur l’application qui accède aux données en en-voyant le verbe HTTP approprié dans la demande utilisée pour accéder aux données. Par exemple, la demande simple illustrée précédemment doit envoyer une demande HTTP GET au service Web. HTTP prend en charge bien d’autres verbes, tels que POST, PUT, et DELETE, que vous pou-



vez utiliser respectivement pour créer, modifier, et supprimer des ressources. En utilisant le modèle REST, vous pouvez exploiter ces verbes et concevoir des services Web qui peuvent mettre à jour les données.

À la différence de SOAP, les messages envoyés et reçus en utilisant le mo-dèle REST tendent à être bien plus compacts. Ceci s’explique principale-ment par le fait que REST ne fournit pas les mêmes facilités de routage, stra-tégie et de sécurité que les spécifications WS-*, et vous devez vous reposer sur l’infrastructure sous-jacente fournie par le serveur Web pour protéger les services Web REST. Cependant, cette approche minimaliste signifie qu’un service Web REST est habituellement bien plus efficace que le service Web SOAP équivalent lorsqu’il transmet et reçoit des messages.

Conception de services Web En utilisant WCF, vous pouvez concevoir des services Web qui suivent les modèles REST ou SOAP. Cependant, le mécanisme SOAP est le plus simple des deux schémas à implémenter avec WCF, et nous allons par consé-quent nous concentrer sur ce modèle pour les premiers exercices de ce chapitre. Ensuite, nous verrons comment concevoir un service Web REST.

Dans ce chapitre, vous allez créer deux services Web :

■ Le service Web InformationsProduit. C’est un service Web SOAP qui permet à l’utilisateur de calculer le coût d’achat d’une quantité spé-cifiée d’un produit particulier de la base de données Northwind

■ Le service Web DetailsProduit. C’est un service Web REST qui permet à l’utilisateur de récupérer les détails des produits de la base de don-nées Northwind.

Création du service Web SOAP InformationsProduit Dans le premier exercice, vous allez créer le service Web InformationsPro-duit et examiner le code généré par Visual Studio 2010 à chaque fois que vous créez un nouveau projet de service WCF. Dans les exercices suivants, vous allez définir et implémenter la méthode Web CombienCaCoutera



puis tester la méthode Web pour s’assurer qu’elle fonctionne comme pré-vu.

Important Vous ne pouvez pas concevoir des services Web en utilisant Micro-soft Visual C# 2010 Express. À la place, vous devez utiliser Microsoft Visual Web Developer 2010 Express. Vous pouvez télécharger Visual Web Developer 2010 Express gratuitement à partir du site Web de Microsoft.

Création du service Web SOAP, et examen du code d’exemple

1. Démarrez Visual Studio 2010 s’il n’est pas déjà ouvert, ou démarrez Visual Web Developer 2010 Express.

2. Si vous utilisez Visual Studio 2010, dans le menu Fichier, pointez Nou-veau, puis cliquez sur Site Web.

3. Si vous utilisez Visual Web Developer 2010 Express, dans le menu Fi-chier, cliquez sur Nouveau site Web. Assurez-vous que vous sélection-nez Visual C# sous Modèles installés dans le volet gauche.

4. Dans la boîte de dialogue Nouveau site Web, cliquez sur le modèle Service WCF. Sélectionnez Système de fichiers dans la zone de liste déroulante Emplacement, spécifiez le dossier \Visual C Sharp Etape par étape\Chapitre 29\ServiceInformationsProduit de votre dossier Documents, puis cliquez sur OK.

Visual Studio 2010 génère un site Web hébergé en utilisant le serveur Web de développement fourni par Visual Studio et Visual Web Deve-loper. Vous pouvez aussi héberger les services Web en utilisant Micro-soft Internet Information Services (IIS). Le site Web contient des dossiers appelés App_Code et App_Data, un fichier appelé Service.svc, et un fichier de configuration appelé Web.config. Le code d’un service Web d’exemple est défini dans la classe Service, stocké dans le fichier Service.cs du dossier App_Code, et affiché dans la fenêtre Code. La classe Service implémente une interface d’exemple appelée IService, qui est stockée dans le fichier IService.cs du dossier App_Code.

Note Le fichier de solution d’un projet de site Web est situé dans le dos-sier Visual Studio 2010\Projects de votre dossier Documents plutôt que



dans le dossier qui contient les fichiers du site Web. Vous pouvez ouvrir un projet de site Web existant soit en trouvant et en ouvrant le fichier de solution approprié, soit en utilisant la commande Ouvrir Site Web du me-nu Fichier puis en spécifiant le dossier qui contient les fichiers du site Web. Vous pouvez également copier le fichier de solution d’un site Web vers le dossier contenant les fichiers du site Web, mais ce n’est pas re-commandé dans un environnement de production, pour des raisons de sécurité.

5. Cliquez sur le projet C:\...\ServiceInformationsProduit\. Dans la fe-nêtre Propriétés, initialisez la propriété Utiliser des ports dynamiques à False et la propriété Numéro de port à 4500.

Note Il est possible que vous deviez attendre quelques secondes après avoir initialisé la propriété Utiliser des ports dynamiques à False avant de pouvoir initialiser la propriété Numéro de port.

Un port spécifie un emplacement où le serveur Web écoute les de-mandes entrantes des applications clientes. Par défaut, le serveur Web de développement fourni avec Visual Studio 2010 choisit un port aléatoirement pour réduire les chances de collision avec d’autres ports utilisés par d’autres services réseau s’exécutant sur votre ordina-teur. Cette fonctionnalité est utile si vous générez et testez des sites Web ASP.NET dans un environnement de développement avant de les copier vers un serveur de production comme IIS. Cependant, lors-que vous générez un service Web, il est plus utile d’utiliser un numéro de port fixe car les applications clientes ont besoin de pouvoir se connecter à celui-ci.

Note Lorsque vous fermez un site Web puis l’ouvrez à nouveau en utili-sant Visual Studio ou Visual Web Developer, la propriété Utiliser des ports dynamiques repasse fréquemment à True et la propriété Numéro de port est initialisée à un port aléatoire. Dans ce cas, réinitialisez ces pro-priétés aux valeurs décrites dans cette étape.

6. Dans l’Explorateur de solutions, développez le dossier App_Code s’il n’est pas déjà ouvert, faites un clic droit sur le fichier Service.cs, puis



cliquez sur Renommer. Modifiez le nom du fichier en InformationsPro-duit.cs.

7. En utilisant la même technique, modifiez le nom du fichier IService.cs en IInformationsProduit.cs.

8. Faites un double clic sur le fichier IInformationsProduit.cs pour l’afficher dans la fenêtre Code.

Ce fichier contient la définition d’une interface appelée IService. En haut de ce fichier IInformationsProduit.cs, vous trouverez des instruc-tions using faisant référence aux espaces de noms System, Sys-tem.Collections.Generic, et System.Text (que vous avez rencontrés auparavant), suivies par deux instructions supplémentaires faisant ré-férence aux espaces de noms System.ServiceModel et Sys-tem.Runtime.Serialization.

L’espace de noms System.ServiceModel contient les classes utilisées par WCF pour définir des services et leurs opérations. WCF utilise les classes de l’espace de noms System.Runtime.Serialization pour con-vertir les objets en un flux de données pour la transmission sur le réseau (traitement appelé sérialisation) et pour annuler cette conversion (dé-sérialisation). Vous en apprendrez davantage sur la façon dont WCF sérialise et désérialise les objets plus tard dans ce chapitre.

Le contenu principal du fichier IInformationsProduit se compose d’une interface appelée IService et d’une classe appelée CompositeType. L’interface IService est préfixée avec l’attribut ServiceContract, et la classe CompositeType est balisée avec l’attribut DataContract. En rai-son de la structure d’un service WCF, vous pouvez adopter une ap-proche « contract-first » (priorité au contrat) pour le développement. Lorsque vous effectuez du développement « contract-first », vous dé-finissez les interfaces, ou contracts, que le service implémentera, puis vous générez un service conforme à ces contracts. Ce n’est pas une nouvelle technique, et vous avez vu des exemples de cette stratégie tout au long de cet ouvrage. Le point important derrière l’utilisation du développement « contract-first » est que vous pouvez vous con-centrer sur la conception de votre service. Si nécessaire, il peut rapi-dement être revu pour assurer que votre conception n’introduit pas des dépendances à du matériel ou des logiciels spécifiques avant d’effectuer trop de développement ; rappelez-vous que dans de



nombreux cas les applications clientes pourraient ne pas être géné-rées avec WCF et pourraient même ne pas s’exécuter sous Windows.

L’attribut ServiceContract marque une interface comme définissant les méthodes que la classe qui implémente le service Web exposera en tant que méthodes Web. Les méthodes elles-mêmes sont balisées avec l’attribut OperationContract. Les outils fournis avec Visual Studio 2010 utilisent ces attributs pour aider à générer le document WSDL approprié pour le service. Toutes les méthodes de l’interface non marquées avec l’attribut OperationContract ne seront pas incluses dans le document WSDL et par conséquent ne seront pas accessibles aux applications clientes utilisant le service Web.

Si une méthode Web prend des paramètres ou retourne une valeur, les données de ces paramètres et de cette valeur doivent être con-verties en un format qui peut être transmis sur le réseau puis reconverti à nouveau en objets (c’est le traitement appelé sérialisation et désé-rialisation mentionné précédemment). Les différents standards de ser-vices Web définissent des mécanismes pour spécifier le format de types de données simples, comme les nombres et les chaînes, dans la description WSDL d’un service Web. Cependant, vous pouvez aussi définir vos propres types de données complexes basés sur des classes et des structures. Si vous utilisez ces types dans un service Web, vous devez fournir des informations sur la façon de les sérialiser et désériali-ser. Si vous regardez la définition de la méthode GetDataUsingData-Contract de l’interface IService, vous pouvez voir qu’elle attend un paramètre du type CompositeType. La classe CompositeType est marquée avec l’attribut DataContract, qui spécifie que la classe doit définir un type qui peut être sérialisé et désérialisé en tant que flux XML d’une demande SOAP ou d’un message de réponse. Chaque membre que vous souhaitez inclure dans le flux sérialisé envoyé sur le réseau doit être marqué avec l’attribut DataMember.

9. Faites un double clic sur le fichier InformationsProduit.cs pour l’afficher dans la fenêtre Code.

Ce fichier contient une classe appelée Service qui implémente l’interface IService et fournit les méthodes GetData et GetDataUsing-DataContract définies par cette interface. Cette classe est le service Web. Lorsqu’une application cliente appelle une méthode Web de



ce service Web, elle génère un message de demande SOAP et l’envoie au serveur Web hébergeant le service Web. Le serveur Web créé une instance de cette classe et exécute la méthode correspon-dante. Lorsque la méthode se termine, le serveur Web construit un message de réponse SOAP, qu’elle renvoie à l’application cliente.

10. Faites un double clic sur le fichier Service.svc pour l’afficher dans la fenêtre Code.

C’est le fichier de service du service Web ; il est utilisé par l’environnement hôte (IIS, dans ce cas) pour déterminer quelle classe charger lorsqu’il reçoit une demande de l’application cliente.

La propriété Service de la directive @ ServiceHost spécifie le nom de la classe du service Web, et la propriété CodeBehind spécifie l’emplacement du code source de cette classe.

Astuce Si vous ne souhaitez pas déployer le code source de votre ser-vice WCF vers le serveur Web, vous pouvez fournir à la place un assem-bly compilé. Vous pouvez ensuite spécifier le nom et l’emplacement de cet assembly en utilisant la directive @ Assembly. Pour plus d’informations, cherchez « directive @ Assembly » dans la documenta-tion fournie avec Visual Studio 2010.

Maintenant que vous avez vu la structure d’un service WCF, vous pouvez définir l’interface qui spécifie le contrat de service du service Web Informa-tionsProduit puis créer une classe qui implémente ce contrat de service.

Définition du contrat du service Web InformationsProduit

1. Affichez le fichier IInformationsProduit.cs dans la fenêtre Code.

2. Dans la ligne de code qui définit l’interface IService, faites un double clic sur le nom IService pour le surligner. Dans le menu Refactoriser, cliquez sur Renommer. Dans la boîte de dialogue Renommer, saisissez IInformationsProduit dans la zone de texte Nouveau nom, décochez la case Afficher un aperçu des modifications de la référence, puis cli-quez sur OK.

Cette action modifie le nom de l’interface de IService en IInforma-tionsProduit et modifie également toutes les références à IService en



IInformationsProduit dans tous les fichiers du projet. La ligne qui définit l’interface dans la fenêtre Code doit ressembler à ceci :

public interface IInformationsProduit { ... }

3. Dans l’interface IInformationsProduit, supprimez les définitions des mé-thodes GetData et GetDataUsingDataContract et remplacez-les par la méthode CombienCaCoutera illustrée en gras. Assurez-vous de conserver l’attribut OperationContract de la méthode Web.

[ServiceContract] public interface IInformationsProduit { [OperationContract] decimal CombienCaCoutera(int idProduit, int combien); }

La méthode CombienCaCoutera prend un ID produit et une quantité puis retourne une valeur decimal spécifiant ce que cette quantité coûtera.

4. Supprimez la classe CompositeType, en incluant l’attribut DataCon-tract, du fichier IInformationsProduit.cs. Le fichier doit contenir uni-quement la définition de l’interface IInformationsProduit.

La prochaine étape consiste à définir la classe InformationsProduit, qui im-plémente l’interface IInformationsProduit. La méthode CombienCaCoutera de cette classe récupèrera le prix du produit à partir de la base de don-nées en effectuant une requête ADO.NET simple.

Note Les services Web que vous concevez dans ce chapitre accèdent à la base de données Northwind. Si vous ne l’avez pas déjà fait, vous pouvez créer cette base de données en suivant les étapes de la section « Création de la base de données » du chapitre 25, « Recherche d'informations dans une base de données ».

Implémentation de l’interface IInformationsProduit

1. Affichez le code du fichier InformationsProduit.cs dans la fenêtre



Code.

2. Ajoutez les instructions using suivantes à la liste en haut du fichier :

using System.Data; using System.Data.SqlClient;

Vous devez vous souvenir (voir le chapitre 25) que ces espaces de noms contiennent les types nécessaires pour accéder à une base de données Microsoft SQL Server et interroger des données.

3. Dans la ligne de code qui définit la classe Service, faites un double clic sur le nom Service pour le surligner. Dans le menu Refactoriser, cli-quez sur Renommer. Dans la boîte de dialogue Renommer, saisissez InformationsProduit dans la zone de texte Nouveau nom puis cliquez sur OK.

Comme dans l’exercice précédent, cette action modifie le nom de la classe Service à InformationsProduit et modifie également toutes les références de cette classe en InformationsProduit dans tous les fichiers du projet. La ligne qui définit la classe dans la fenêtre Code doit res-sembler à ceci :

public class InformationsProduit : IInformationsProduit { ... }

4. Supprimez les méthodes GetData et GetDataUsingDataContract de la classe InformationsProduit.

5. Ajoutez la méthode CombienCaCoutera à la classe InformationsPro-duit, illustrée ici en gras :

public class InformationsProduit : IInformationsProduit { public decimal CombienCaCoutera(int idProduit, int combien) { SqlConnection connexionDonnees = new SqlConnection(); decimal coutTotal = 0; try { SqlConnectionStringBuilder generateur = new SqlConnectionStringBuilder(); generateur.DataSource = ".\\SQLExpress"; generateur.InitialCatalog = "Northwind";



generateur.IntegratedSecurity = true; connexionDonnees.ConnectionString = generateur.ConnectionString; connexionDonnees.Open(); SqlCommand commandeDonnees = new SqlCommand(); commandeDonnees.Connection = connexionDonnees; commandeDonnees.CommandType = CommandType.Text; commandeDonnees.CommandText = "SELECT UnitPrice FROM Products WHERE ProductID = @ProductID"; SqlParameter parametreIDProduit = new SqlParameter("@ProductID", SqlDbType.Int); parametreIDProduit.Value = idProduit; commandeDonnees.Parameters.Add(parametreIDProduit); decimal? prix = commandeDonnees.ExecuteScalar() as decimal?; if (prix.HasValue) { coutTotal = prix.Value * combien; } } finally { connexionDonnees.Close(); } return coutTotal; } }

Cette méthode se connecte à la base de données et exécute une requête ADO.NET pour récupérer le coût du produit correspondant à l’ID produit fourni à la base de données Northwind. Si le coût retourné n’est pas null, la méthode calcule le coût total de la requête et le re-tourne ; sinon, la méthode retourne la valeur 0. Le code est similaire à celui illustré au chapitre 25, excepté qu’il utilise la méthode ExecuteS-calar pour lire la valeur de la colonne UnitPrice (prix unitaire) de la base de données. La méthode ExecuteScalar fournit un mécanisme très efficace pour exécuter des requêtes qui retournent une seule va-leur scalaire (et bien plus efficace que d’ouvrir un curseur et de lire les données du curseur). La valeur retournée par ExecuteScalar est un object, si bien que vous devez le caster avec le type approprié avant de l’utiliser.



Important Cette méthode n’effectue aucune validation des para-mètres d’entrée. Par exemple, vous pouvez spécifier une valeur néga-tive pour le paramètre combien. Dans un service Web de production, vous intercepterez ce genre d’erreurs, les enregistrerez et retournerez une exception. Cependant, la transmission d’une exception à une ap-plication cliente a des implications sur la sécurité d’un service WCF. Ces détails dépassent le cadre de ce livre. Pour plus d’informations, voir Mi-crosoft Windows Communication Foundation Step by Step.

Avant de pouvoir utiliser le service Web, vous devez mettre à jour la confi-guration du fichier Service.svc pour faire référence à la classe Informations-Produit du fichier InformationsProduit.cs. Le serveur Web utilise les informa-tions du fichier Web.config créé avec le projet pour contenir des informa-tions sur la façon de publier le service et de le rendre disponible aux appli-cations clientes. Vous devez modifier le fichier Web.config et ajouter les dé-tails du service Web.

Configuration du service Web

1. Dans l’Explorateur de solutions, faites un double clic sur le fichier Ser-vice.svc pour l’afficher dans la fenêtre Code. Mettez à jour les attri-buts Service et CodeBehind de la directive ServiceHost, comme indi-qué en gras ici :

<%@ ServiceHost Language="C#" Debug="true" Service="InformationsProduit" CodeBehind="~/App_Code/InformationsProduit.cs" %>

2. Dans l’Explorateur de solutions, faites un double clic sur le fichier Web.config. Dans la fenêtre Code, recherchez l’élément <sys-tem.serviceModel>. On utilise cet élément pour spécifier la configura-tion d’un service WCF. Cet élément contient actuellement un élé-ment <behaviors>, que vous pouvez ignorer pour le moment.

3. Dans le fichier Web.config, ajoutez l’élément <services> et les élé-ments enfants illustrés en gras à l’élément <system.serviceModel>, avant l’élément <behaviors> :

<system.serviceModel> <services> <service name="InformationsProduit"> <endpoint address="" binding="wsHttpBinding" contract="IInformationsProduit"/>



</service> </services> <behaviors> ... </behaviors> </system.serviceModel>

Cette configuration spécifie le nom de la classe qui implémente le service Web (InformationsProduit). WCF utilise la notion de points de terminaisons pour associer une adresse réseau avec un service Web spécifique. Si vous hébergez un service Web en utilisant IIS ou le ser-veur Web de développement, vous devez laisser la propriété address de votre point de terminaison vide car ces serveurs écoutent les de-mandes entrantes sur une adresse spécifiée par leurs propres informa-tions de configuration. Vous pouvez générer vos propres applications hôtes personnalisées si vous ne voulez pas utiliser IIS ou le serveur de développement. Dans ce genre de situations, vous devez spécifier une adresse pour le service dans la définition du point de terminaison. Le paramètre binding indique le protocole réseau que le serveur uti-lise pour recevoir des demandes et transmettre des réponses.

Pour plus d’informations sur les points de terminaison, les hôtes person-nalisés, et les liaisons, reportez-vous à Microsoft Windows Communica-tion Foundation Step by Step, publié par Microsoft Press.

4. Dans le menu Fichier, cliquez sur Enregistrer tout.

5. Dans l’Explorateur de solutions, faites un clic droit sur Service.svc, puis cliquez sur Afficher dans le navigateur.

Internet Explorer démarre et affiche la page suivante, ce qui confirme que vous avez créé et déployé avec succès le service Web et fourni des informations utiles décrivant la manière de créer une application cliente simple pouvant accéder au service Web.



Note Si vous cliquez sur le lien indiqué sur la page Web (http://localhost:4500/ServiceInformationsProduit/Service.svc?wsdl), In-ternet Explorer affiche une page contenant la description WSDL du ser-vice Web. Il s’agit d’un code XML long et complexe, mais Visual Studio 2010 peut prendre les informations de cette description et les utiliser pour générer une classe qu’une application cliente peut employer pour communiquer avec le service Web.

6. Fermez Internet Explorer, et retournez dans Visual Studio 2010.

Services Web, clients et proxys Vous avez vu qu’un service Web utilise SOAP pour fournir un mécanisme pour recevoir des demandes et renvoyer les résultats. SOAP utilise XML pour mettre en forme les données transmises qui se situent au-dessus du proto-cole HTTP utilisé par les serveurs Web et les navigateurs. C’est ce qui rend les services Web si puissants. N’importe quelle application cliente qui « parle » SOAP peut communiquer avec un service Web. Dans ces condi-tions, comment un client peut-il « parler » SOAP ? Il y a deux façons de pro-céder : une difficile et une facile.



SOAP : la voie difficile L’application cliente effectue un certain nombre d’étapes :

1. Déterminer l’URL du service Web exécutant la méthode Web.

2. Effectuer une demande WSDL (Web Services Description Language) en utilisant l’URL pour obtenir une description des méthodes Web dis-ponibles, les paramètres utilisés, et les valeurs retournées. Vous avez vu comment effectuer ceci en utilisant Internet Explorer dans l’exercice précédent.

3. Analyser le document WSDL, convertir chaque opération en une de-mande Web, et sérialiser chaque paramètre dans le format décrit par le document WSDL.

4. Soumettre la demande, ainsi que les données sérialisées, à l’URL en utilisant HTTP.

5. Attendre que le service Web réponde.

6. En utilisant les formats spécifiés par le document WSDL, désérialiser les données retournées par le service Web en des valeurs significatives que votre application peut ensuite traiter.

Cela constitue beaucoup de travail pour appeler une seule méthode, et cela peut engendrer des erreurs.

SOAP : la voie facile La mauvaise nouvelle est que la manière facile d’utiliser SOAP n’est pas bien différente de la voie difficile. La bonne nouvelle est que le traitement peut être automatisé car il est largement mécanique. Comme mentionné précédemment, de nombreux éditeurs, y compris Microsoft, fournissent des outils qui peuvent générer une classe proxy basée sur une description WSDL. Le proxy masque la complexité de l’emploi de SOAP et expose une interface de programmation simple basée sur les méthodes publiées par le service Web. L’application cliente appelle les méthodes Web en appelant les méthodes avec le même nom dans le proxy. Le proxy convertit ces ap-pels de méthodes locales en demandes SOAP et les envoie au service Web. Le proxy attend la réponse, désérialise les données, puis les retrans-



met au client comme un retour de n’importe quel appel de méthode simple. C’est l’approche que vous allez adopter dans les exercices de cette section.

Consommation du service Web SOAP InformationsProduit Vous avez créé un appel de service Web SOAP qui montre une méthode Web appelée CombienCaCoutera pour déterminer le coût d’achat de n éléments de produit x de la base de données Northwind Traders. Dans les exercices suivants, vous allez utiliser ce service Web et créer une applica-tion qui se sert de cette méthode.

Ouverture d’une application cliente de service Web

1. Démarrez une autre instance de Visual Studio 2010. C’est important. Le Serveur de développement ASP.NET s’arrête si vous fermez le projet du service Web ServiceInformationsProduit, ce qui signifie que vous ne pourrez pas y accéder à partir du client (si vous exécutez Visual Studio 2010 et non pas Visual Web Developer 2010 Express Edition, vous pou-vez aussi créer l’application cliente comme un projet dans la même solution que le service Web). Lorsque vous hébergez un service Web dans un environnement de production en utilisant IIS, ce problème ne se produit pas car IIS s’exécute indépendamment de Visual Studio 2010.

Important Si vous avez utilisé Visual Web Developer 2010 Express Édition pour les exercices de cette partie de l’ouvrage, démarrez Visual C# 2010 Express Édition plutôt qu’une seconde instance de Visual Web De-veloper 2010 Express Édition (laissez Visual Web Developer 2010 Express Édition ouvert).

2. Dans la seconde instance de Microsoft Visual Studio 2010, ouvrez la solution ClientProduit du dossier \Visual C Sharp Etape par étape\Chapitre 29\ClientProduit de votre dossier Documents.

3. Dans l’Explorateur de solutions, faites un double clic sur le fichier



ClientProduit.xaml pour afficher le formulaire dans la fenêtre Concep-teur. Le formulaire ressemble à ceci :

Le formulaire permet à l’utilisateur de spécifier un ID produit et de ré-cupérer les détails du produit de la base de données Northwind. L’utilisateur peut aussi fournir une quantité et récupérer un prix d’achat pour cette quantité du produit. Actuellement, les boutons du formulaire ne font rien. Dans les étapes suivantes, vous allez ajouter le code nécessaire pour appeler les méthodes du service Web Informa-tionsProduit afin d’obtenir les données et les afficher.

Ajout du code pour appeler le service Web de l’application cliente

1. Dans le menu Projet, cliquez sur Ajouter une référence de service.

La boîte de dialogue Ajouter une référence de service s’ouvre. Dans cette boîte de dialogue, vous pouvez parcourir les services Web et examiner les méthodes Web qu’ils fournissent.

2. Dans la zone de texte Adresse, saisissez http://localhost:4500/ServiceInformationsProduit/Service.svc, puis cli-quez sur Aller à.

Le service InformationsProduit apparaît dans la zone Services.

3. Développez le service InformationsProduit, puis cliquez sur l’interface IInformationsProduit qui apparaît. Dans la zone de liste Opérations, vé-rifiez que les deux opérations, ObtenirInfoProduit et CombienCaCou-tera, apparaissent, comme l’illustre l’image suivante.



4. Modifiez la valeur dans la zone de texte Espace de noms à ServiceIn-formationsProduit puis cliquez sur OK.

Un nouveau dossier appelé Service References apparaît dans l’Explorateur de solutions. Ce dossier contient un élément appelé Ser-viceInformationsProduit.

5. Cliquez sur le bouton Afficher tous les fichiers dans la barre d’outils Explorateur de solutions. Développez le dossier ServiceInformations-Produit, puis développez le dossier Reference.svcmap. Faites un double clic sur le fichier Reference.cs et examinez son contenu dans la fenêtre Code.

Ce fichier contient plusieurs classes et interfaces, notamment une classe nommée InformationsProduitClient dans un espace de noms appelé ClientProduit.ServiceInformationsProduit. La classe Informa-tionsProduitClient est la classe proxy générée par Visual Studio 2010 à partir de la description WSDL du service Web InformationsProduit. Elle contient un certain nombre de constructeurs, mais aussi une méthode appelée CombienCaCoutera. Le code suivant montre quelques élé-ments importants de ce fichier qui a été remis en forme pour le rendre un peu plus lisible :

namespace ClientProduit.ServiceInformationsProduit { ... [System.ServiceModel.ServiceContractAttribute(...)] public interface IInformationsProduit {



[System.ServiceModel.OperationContractAttribute(...)] decimal CombienCaCoutera(int idProduit, int combien); } ... ... public partial class InformationsProduitClient : System.ServiceModel.ClientBase<ClientProduit.ServiceInformationsProduit.IInformationsProduit>, ClientProduit.ServiceInformationsProduit.IInformationsProduit { public InformationsProduitClient() { } public InformationsProduitClient(string endpointConfigurationName) : base(endpointConfigurationName) { } public InformationsProduitClient(string endpointConfigurationName, string remoteAddress) : base(endpointConfigurationName, remoteAddress) { } public InformationsProduitClient(string endpointConfigurationName, System.ServiceModel.EndpointAddress remoteAddress) : base(endpointConfigurationName, remoteAddress) { } public InformationsProduitClient(System.ServiceModel.Channels.Binding binding, System.ServiceModel.EndpointAddress remoteAddress) : base(binding, remoteAddress) { } public decimal CombienCaCoutera(int idProduit, int combien) { return base.Channel.CombienCaCoutera(idProduit, combien); } } }

L’interface InformationsProduit est similaire à l’interface que vous avez définie dans le service Web, excepté que certains attributs spécifient des paramètres supplémentaires (le but de ces paramètres dépasse le cadre de ce chapitre). La classe InformationsProduit implémente cette interface, mais hérite aussi de la classe générique ClientBase. La classe ClientBase de l’espace de noms System.ServiceModel fournit les fonctionnalités de communication de base dont une application cliente a besoin pour communiquer avec un service Web. Le para-



mètre de type spécifie l’interface que la classe implémente. La classe ClientBase fournit la propriété Channel, qui encapsule une connexion HTTP à un service Web. Les différents constructeurs de la classe Infor-mationsProduitClient configurent le canal pour la connecter au point de terminaison que le service Web écoute.

L’application cliente peut instancier la classe InformationsProduit-Client, en spécifiant le point de terminaison à connecter, puis appeler la méthode CombienCaCoutera. Lorsque cela arrive, le canal de la classe sous-jacente ClientBase empaquète les informations fournies comme paramètres dans un message SOAP qu’il transmet au service Web. Lorsque le service Web répond, les informations retournées sont désempaquetées à partir de la réponse SOAP et retransmises à l’application cliente. De cette façon, l’application cliente peut appe-ler une méthode d’un service Web exactement de la même façon qu’elle appellerait une méthode locale.

Note Vous avez peut-être remarqué que l’interface est marquée avec ServiceContractAttribute plutôt que simplement ServiceContract, et l’opération est marquée avec OperationContractAttribute plutôt que OperationContract. En fait, tous les attributs ont le suffixe Attribute avec leur nom. Le compilateur C# reconnaît cette convention de noms, et par conséquent il vous autorise à omettre le suffixe Attribute dans votre propre code.

6. Affichez le formulaire ClientProduit.xaml dans la fenêtre Concepteur. Faites un double clic sur le bouton Calculer le coût pour générer la méthode de gestionnaire d’événement calculerCout_Click de ce bouton.

7. Dans la fenêtre Code, ajoutez les instructions using suivantes à la liste en haut du fichier ClientProduit.xaml.cs :

using ClientProduit.ServiceInformationsProduit; using System.ServiceModel;

8. Dans la méthode calculerCout_Click, ajoutez le code suivant en gras :

private void calculerCout_Click(object sender, RoutedEventArgs e) {



InformationsProduitClient proxy = new InformationsProduitClient(); }

Cette instruction crée une instance de la classe InformationsProduit-Client que votre code utilisera pour appeler la méthode Web Com-bienCaCoutera.

9. Ajoutez le code en gras à la méthode calculerCout_Click. Ce code extrait l’ID produit et le nombre requis de la zone de texte Combien du formulaire, exécute la méthode Web CombienCaCoutera en utili-sant l’objet proxy, puis affiche le résultat dans le label coutTotal.

private void calculerCout_Click(object sender, RoutedEventArgs e) { InformationsProduitClient proxy = new InformationsProduitClient(); try { int idProd = Int32.Parse(idProduit.Text); int nombreRequis = Int32.Parse(combien.Text); decimal cout = proxy.CombienCaCoutera(idProd, nombreRequis); coutTotal.Content = String.Format("{0:C}", cout); } catch (Exception ex) { MessageBox.Show("Erreur en calculant le coût: " + ex.Message, "Erreur", MessageBoxButton.OK, MessageBoxImage.Error); } finally { if (proxy.State == CommunicationState.Faulted) proxy.Abort(); else proxy.Close(); } }

Vous savez probablement combien les réseaux sont imprévisibles, et ceci est valable deux fois plus pour Internet. Le bloc try/catch assure que l’application cliente intercepte toutes les exceptions réseau qui peuvent survenir. Il est également possible que l’utilisateur puisse ne pas saisir un entier valide dans la zone de texte ID Produit du formu-laire. Le bloc try/catch gère aussi cette exception.

Le bloc finally examine l’état de l’objet proxy. Si une exception est apparue dans le service Web (qui peut être provoquée par l’utilisateur fournissant un ID produit inexistant, par exemple), le proxy



sera à l’état Faulted. Dans ce cas, le bloc finally appelle la méthode Abort du proxy pour reconnaître l’exception et fermer la connexion ; dans le cas contraire, il appelle la méthode Close. Les méthodes Abort et Close ferment toutes les deux les canaux de communication avec le service Web et libèrent les ressources associées à cette ins-tance de l’objet InformationsClientProduit.

Test de l’application

1. Dans le menu Déboguer, cliquez sur Démarrer sans débogage.

2. Lorsque le formulaire Détails du produit apparaît, saisissez 3 dans la zone de texte ID Produit, saisissez 5 dans la zone de texte Combien, puis cliquez sur Calculer le coût.

Après un court délai pendant que le client instancie le proxy et gé-nère une demande SOAP contenant l’ID produit, le proxy envoie la demande au service Web. Le service Web désérialise la demande SOAP pour extraire l’ID produit, lit le prix unitaire du produit dans la base de données, calcule le coût total, l’encapsule en XML dans un message de réponse SOAP, puis renvoie ce message de réponse au proxy. Le proxy désérialise les données XML puis les transmet au code de la méthode calculerCout_Click. Le coût pour 5 unités du produit 3 apparaît dans le formulaire (50).

Astuce Si vous obtenez une exception avec le message « Erreur en cal-culant le coût : Il n’existait pas de point de terminaison à l’écoute sur http://localhost:4500/ServiceInformationsProduit/Service.svc pouvant accepter le message », le serveur de développement a probablement arrêté son exécution (il s’arrête s’il est inactif pendant un moment). Pour le redémarrer, basculez vers l’instance Visual Studio 2010 du service Web InformationsProduit, faites un clic droit sur Service.svc dans l’Explorateur de solutions, puis cliquez sur Afficher dans le navigateur. Fermez Internet Explorer lorsqu’il apparaît.

3. Faites des tests en saisissant les ID d’autres produits. Notez que si vous entrez un ID d’un produit qui n’existe pas, le service Web retourne la valeur 0 pour le coût total.

4. Lorsque vous avez fini, fermez le formulaire et retournez dans Visual



Studio.

Création du service Web REST DetailsProduit Dans la section précédente, vous avez construit et utilisé un service Web SOAP pour implémenter une petite partie d’une fonctionnalité procédu-rale. Dans le prochain ensemble d’exercices, vous allez concevoir le ser-vice Web DetailsProduit qui permet à un utilisateur de rechercher les détails des produits. Cette forme de service Web est naturellement navigation-nelle si bien que vous allez l’implémenter en utilisant le modèle REST. Vous allez commencer par créer un contrat de données pour transmettre des objets Produit sur le réseau.

Vous pouvez accéder à un service Web REST à partir d’une application cliente d’une manière similaire à un service Web SOAP (en utilisant un objet proxy qui cache la complexité d’envoi d’un message sur un réseau à partir d’une application cliente). Cependant, Visual Studio ne prend pas en charge actuellement la génération de classes proxy pour les services Web REST automatiquement, si bien que vous allez créer la classe proxy manuel-lement. Ce n’est pas nécessairement une bonne pratique de dupliquer du code comme les contrats de service à travers les services Web et les clients car cela rend difficile la maintenance. Pour ces raisons, vous allez adopter une approche un peu différente pour concevoir le service Web.

Création du contrat de données du service Web

1. Si vous utilisez Visual Studio 2010, effectuez les tâches suivantes pour créer un nouveau projet de bibliothèque de classes :

1.1. Dans l’instance de Visual Studio que vous utilisez pour éditer l’application cliente, dans le menu Fichier, pointez Nouveau, puis cliquez sur Projet.

1.2. Dans la boîte de dialogue Nouveau projet, dans le volet gauche, sous Visual C#, cliquez sur Windows.

1.3. Dans le volet du milieu, sélectionnez le modèle Bibliothèque de classes.



1.4. Dans la zone de texte Nom, saisissez ContratsDetailsProduit.

1.5. Dans la zone de texte Emplacement, spécifiez le dossier \Visual C Sharp Etape par étape\Chapitre 29 de votre dossier Docu-ments.

1.6. Cliquez sur OK.

2. Si vous utilisez Microsoft Visual C# 2010 Express, effectuez les tâches suivantes pour créer un nouveau projet de bibliothèque de classes :

2.1. Démarrez Visual C# 2010 Express s’il n’est pas déjà ouvert.

2.2. Dans le menu Fichier, cliquez sur Nouveau projet.

2.3. Dans la boîte de dialogue Nouveau projet, dans le volet du mi-lieu, sélectionnez le modèle Bibliothèque de classes.

2.4. Dans la zone de texte Nom, saisissez ContratsDetailsProduit.

2.5. Cliquez sur OK.

2.6. Dans le menu Fichier, cliquez sur Enregistrer ContratsDetailsPro-duit.

2.7. Dans la boîte de dialogue Enregistrer le projet, dans la zone de texte Emplacement, spécifiez le dossier \Visual C Sharp Etape par étape\Chapitre 29 de votre dossier Documents.

2.8. Cliquez sur Enregistrer.

3. Dans le menu Projet, cliquez sur Ajouter une référence.

4. Dans la boîte de dialogue Ajouter une référence, cliquez sur l’onglet .NET. Sélectionnez les assemblys System.Data.Linq, Sys-tem.ServiceModel, System.ServiceModel.Web, et Sys-tem.Runtime.Serialization puis cliquez sur OK.

5. Dans l’Explorateur de solutions, faites un clic droit sur le fichier Class1.cs puis cliquez sur Renommer. Modifier le nom du fichier à Pro-duit.cs. Autorisez Visual Studio à modifier toutes les références de Class1 à Produit lorsque cela apparaît.

6. Faites un double clic sur le fichier Produit.cs pour l’afficher dans la fenêtre Code s’il n’est pas déjà ouvert.

7. Dans le fichier Produit.cs, ajoutez les instructions using suivantes à la



liste en haut :

using System.Runtime.Serialization; using System.Data.Linq.Mapping;

8. Préfixez la classe Produit avec les attributs Table et DataContract, illustrés en gras :

[Table (Name="Products")] [DataContract] public class Produit { }

Vous allez utiliser LINQ to SQL pour récupérer les données de la base de données Northwind. Souvenez-vous (voir le chapitre 25) que l’attribut Table marque la classe comme une classe Entity. La table est appelée Products dans la base de données Northwind.

9. Ajoutez les propriétés en gras à la classe Produit. Assurez-vous de pré-fixer chaque propriété avec les attributs Column et DataMember. No-tez que certaines de ces propriétés sont nullable.

[DataContract] public class Produit { [Column] [DataMember] public int ProductID { get; set; } [Column] [DataMember] public string ProductName { get; set; } [Column] [DataMember] public int? SupplierID { get; set; } [Column] [DataMember] public int? CategoryID { get; set; } [Column] [DataMember] public string QuantityPerUnit { get; set; } [Column] [DataMember]



public decimal? UnitPrice { get; set; } [Column] [DataMember] public short? UnitsInStock { get; set; } [Column] [DataMember] public short? UnitsOnOrder { get; set; } [Column] [DataMember] public short? ReorderLevel { get; set; } [Column] [DataMember] public bool Discontinued { get; set; } }

La prochaine étape consiste à définir le contrat de service du service Web DetailsProduit.

Création du contrat de service du service Web REST

1. Dans le menu Projet, cliquez sur Ajouter une classe.

2. Dans la boîte de dialogue Ajouter une classe, dans le volet du milieu, sélectionnez le modèle Classe. Dans la zone de texte Nom, saisissez IDetailsProduit.cs, puis cliquez sur Ajouter.

3. Dans la fenêtre Code affichant le fichier IDetailsProduit.cs, ajoutez les instructions using suivantes à la liste en haut du fichier :

using System.ServiceModel; using System.ServiceModel.Web;

4. Modifiez la classe IDetailsProduit en une interface publique, et pré-fixez-la avec l’attribut ServiceContract, comme indiqué ici en gras :

[ServiceContract] public interface IDetailsProduit { }

5. Ajoutez la définition de la méthode TrouverProduit en gras à l’interface IDetailsProduit :

[ServiceContract]



public interface IDetailsProduit { [OperationContract] [WebGet(UriTemplate = "produits/{idProduit}")] Produit TrouverProduit(string idProduit); }

La méthode TrouverProduit prend un ID produit et retourne un objet Produit pour le produit qui possède cet ID. L’attribut OperationCon-tract indique que cette méthode doit être exposée comme une mé-thode Web (si vous omettez l’attribut OperationContract, la méthode n’est pas accessible aux applications clientes). L’attribut WebGet in-dique que c’est une opération de recherche logique, et le paramètre UriTemplate spécifie le format de l’URL que vous fournissez pour appe-ler cette opération, relative à l’adresse de base du service Web. Dans ce cas, vous pouvez spécifier l’URL suivante pour rechercher le pro-duit avec idProduit 7 :

http://host/service/produits/7

Les termes host et service représentent l’adresse de votre serveur Web et le nom du service Web. L’élément de UriTemplate entre accolades indique que les données sont transmises comme paramètre à la mé-thode TrouverProduit. L’identificateur entre accolades doit corres-pondre au nom du paramètre.

6. Dans le menu Générer, Cliquez sur Générer la solution et vérifiez que la bibliothèque de classes se compile sans erreur. Le projet crée un as-sembly appelé ContratsDetailsProduit.dll.

Maintenant que vous avez généré un assembly qui définit le contrat de données et le contrat de service du service Web, vous pouvez générer le service Web lui-même.

Création du service Web REST

1. Ouvrez une autre instance de Visual Studio ou de Visual Web Develo-per Express.



Important N’utilisez pas l’instance que vous avez utilisée pour créer le service Web SOAP car cette copie de Visual Studio doit continuer de tourner pour garder le serveur Web de développement hébergeant le service Web SOAP ouvert.

2. Si vous utilisez Visual Studio 2010, dans le menu Fichier, pointez Nou-veau, puis cliquez sur Site Web.

3. Si vous utilisez Visual Web Developer 2010 Express, dans le menu Fi-chier, cliquez sur Nouveau site Web.

4. Dans la boîte de dialogue Nouveau site Web, cliquez sur le modèle Service WCF. Sélectionnez Système de fichiers dans la zone de liste déroulante Emplacement, et spécifiez le dossier \Visual C Sharp Etape par étape\Chapitre 29\DetailsProduitService de votre dossier Documents puis cliquez sur OK.

5. Cliquez sur le projet C:\...\DetailsProduitService\. Dans la fenêtre Pro-priétés, initialisez la propriété Utiliser des ports dynamiques à False et la propriété Numéro de port à 4600.

Note Il est important de spécifier un port différent du service Web Servi-ceInformationsProduit ; sinon, les deux services Web entreront en conflit.

6. Dans le menu Site Web, cliquez sur Ajouter une référence. Dans la boîte de dialogue Ajouter une référence, cliquez sur l’onglet Parcourir. Dans la barre d’outils, cliquez sur le bouton Dossier parent, allez dans le dossier ContratsDetailsProduit\ContratsDetailsProduit\bin\Debug, sélectionnez l’assembly ContratsDetailsProduit.dll, puis cliquez sur OK.

7. Dans l’Explorateur de solutions, développez le dossier App_Code s’il n’est pas déjà ouvert, faites un clic droit sur le fichier Service.cs, puis cliquez sur Renommer. Modifiez le nom du fichier en DetailsProduit.cs.

8. Dans le dossier App_Code, supprimez le fichier IService.cs. Ce fichier n’est pas nécessaire au service Web.

9. Faites un double clic sur le fichier DetailsProduit.cs pour l’afficher dans la fenêtre Code.

10. Ajoutez les instructions using suivantes à la liste en haut du fichier :



using System.Data.Linq; using System.Data.SqlClient; using ContratsDetailsProduit;

11. Modifiez la définition de la classe Service, modifiez le nom en Details-Produit, et spécifiez qu’elle implémente l’interface IDetailsProduit, comme indiqué ici en gras. Supprimez les méthodes GetData et Get-DataUsingDataContract de la classe DetailsProduit :

public class DetailsProduit : IDetailsProduit { }

12. Ajoutez la méthode TrouverProduit (ici en gras) à la classe DetailsPro-duit :

public class DetailsProduit : IDetailsProduit { public Produit TrouverProduit(string idProduit) { int ID = Int32.Parse(idProduit); SqlConnectionStringBuilder generateur = new SqlConnectionStringBuilder(); generateur.DataSource = ".\\SQLExpress"; generateur.InitialCatalog = "Northwind"; generateur.IntegratedSecurity = true; DataContext contexteProduits = new DataContext(generateur.ConnectionString); Produit produit = (from p in contexteProduits.GetTable<Produit>() where p.ProductID == ID select p).First(); return produit; } }

L’ID produit est transmis à la méthode comme une chaîne, si bien que la première instruction la convertit en entier et stocke le résultat dans la variable ID. Le code crée alors un objet DataContext qui se con-necte à la base de données Northwind. La requête LINQ recherche toutes les lignes qui ont un ID produit qui correspond à la valeur de la variable ID. Il doit y avoir au moins un produit correspondant. Habi-tuellement, vous devez parcourir les résultats d’une requête LINQ to SQL pour récupérer chaque ligne tour à tour, mais s’il n’y a qu’une

seule ligne vous pouvez utiliser la méthode d’extension First pour ré-cupérer les données immédiatement. L’objet Produit récupéré par la requête est retourné comme résultat de la méthode.

La prochaine étape consiste à configurer le service Web REST pour fournir la chaîne de connexion que l’assembly ContratsDetailsProduit utilise pour se connecter à la base de données, puis spécifier le protocole et le point de terminaison que les applications clientes peuvent utiliser pour commu-niquer avec le service Web.

Configuration du service Web

1. Dans l’Explorateur de solutions, faites un double clic sur le fichier Web.config pour l’afficher dans la fenêtre Code.

2. Ajoutez l’élément <services> et les éléments enfants en gras à l’élément <system.serviceModel>, avant l’élément <behaviors>. Aussi, ajoutez l’élément <endpointBehaviors> en gras comme un enfant de l’élément <behaviors>. Notez que vous devez pleinement qualifier le nom de l’interface qui fournit le contrat de service avec l’espace de noms ContratsDetailsProduit.

<?xml version="1.0"?> <configuration> <system.web> <compilation debug="false" targetFramework="4.0" /> </system.web> <system.serviceModel> <services> <service name="DetailsProduit"> <endpoint address="" binding="webHttpBinding" contract="ContratsDetailsProduit.IDetailsProduit" behaviorConfiguration="WebBehavior"/> </service> </services> <behaviors> <endpointBehaviors> <behavior name="WebBehavior"> <webHttp/> </behavior> </endpointBehaviors> <serviceBehaviors> <behavior> <!-- To avoid disclosing metadata information, set the value below

to false and remove the metadata endpoint above before deployment --> <serviceMetadata httpGetEnabled="true"/>  <serviceDebug includeExceptionDetailInFaults="false"/> </behavior> </serviceBehaviors> </behaviors> </system.serviceModel> </configuration>

Ce service Web utilise une liaison différente du service Web Informa-tionsProduit Web (webHttpBinding). La liaison webHttpBinding et le comportement WebBehavior indiquent que le service Web attend que les requêtes soient envoyées en suivant le style REST, encodées dans l’URL, et doit retourner les messages de réponses au format POX (XML plein).

3. Dans l’Explorateur de solutions, faites un double clic sur le fichier Ser-vice.svc pour l’afficher dans la fenêtre Code. Mettez à jour les élé-ments Service et CodeBehind pour faire référence à la classe Details-Produits du fichier DetailsProduit.cs, comme ici en gras :

<%@ ServiceHost Language="C#" Debug="true" Service="DetailsProduit" CodeBehind="~/App_Code/DetailsProduit.cs" %>

4. Dans le menu Générer, cliquez sur Générer le site Web.

5. Dans l’Explorateur de solutions, faites un clic droit sur Service.svc, puis cliquez sur Afficher dans le navigateur.

Internet Explorer apparaît affichant la page du service DetailsProduit.

6. Dans la barre d’adresse, spécifiez l’URL suivante et appuyez sur la touche Entrée :

http://localhost:4600/DetailsProduitService/Service.svc/produits/5

Cette URL appelle la méthode TrouverProduit du service Web Details-Produit et spécifie le produit 5. La méthode TrouverProduit recherche les données du produit 5 de la base données Northwind et retourne les informations sous la forme d’un objet Produit, sérialisé en XML. In-ternet Explorer doit afficher la représentation XML de ce produit.



7. Fermez Internet Explorer.

Consommation du service Web REST DetailsProduit Vous avez vu comment appeler un service Web REST assez facilement à partir d’un navigateur Web en spécifiant simplement une URL appropriée. Pour appeler des méthodes d’un service Web REST à partir d’une applica-tion, vous pouvez construire une classe proxy, similaire à celle utilisée par une application cliente se connectant à un service Web SOAP. Comme mentionné précédemment, Visual Studio ne fournit pas de fonctionnalités qui peuvent générer une classe proxy pour un service Web REST. Heureu-sement, il n’est pas difficile de créer une simple classe proxy REST manuel-lement ; vous pouvez utiliser la même classe générique ClientBase que celle qu’emploie une classe proxy SOAP.

Dans le dernier exercice, vous allez retourner à l’application ClientProduit et ajouter les fonctionnalités pour appeler la méthode TrouverProduit du service Web REST.

Appel du service Web REST de l’application cliente

1. Retournez dans l’instance de Visual Studio ou Visual C# Express que vous avez utilisée pour créer le contrat de service du service Web REST.

2. Ouvrez la solution ClientProduit du dossier \Visual C Sharp Etape par étape\Chapitre 29\ClientProduit de votre dossier Documents. C’est l’application cliente que vous avez utilisée pour tester le service Web SOAP précédemment dans ce chapitre.

3. Dans le menu Projet, cliquez sur Ajouter une référence. Dans la boîte de dialogue Ajouter une référence, cliquez sur l’onglet Parcourir. Dans



la barre d’outils, cliquez sur Dossier parent deux fois, allez dans le dos-sier ContratsDetailsProduit\ContratsDetailsProduit\bin\Debug, sélec-tionnez l’assembly ContratsDetailsProduit, puis cliquez sur OK.

4. Dans le menu Projet, cliquez à nouveau sur Ajouter une référence. Dans la boîte de dialogue Ajouter une référence, cliquez sur l’onglet .NET. Sélectionnez l’assembly System.Data.Linq, puis cliquez sur OK.

5. Dans le menu Projet, cliquez sur Ajouter une classe. Dans la boîte de dialogue Ajouter un nouvel élément – ClientProduit, dans le volet du milieu, cliquez sur le modèle Classe. Dans la zone de texte Nom, saisis-sez ProxyClientProduit.cs, puis cliquez sur Ajouter.

6. Dans la fenêtre Code affichant le fichier ProxyClientProduit.cs, ajoutez les instructions using suivantes à la liste en haut du fichier :

using System.ServiceModel; using ContratsDetailsProduit;

7. Modifiez la définition de la classe ProxyClientProduit de manière à ce qu’elle hérite de la classe générique ClientBase et implémente l’interface IDetailsProduit. Spécifiez l’interface IDetailsProduit comme paramètre de type de la classe ClientBase. La classe ProxyClientPro-duit doit ressembler à ceci :

class ProxyClientProduit : ClientBase<IDetailsProduit>, IDetailsProduit { }

8. Ajoutez la méthode TrouverProduit en gras à la classe ProxyClientPro-duit. Cette méthode suit le même schéma que celui utilisé par le proxy SOAP illustré plus haut dans ce chapitre ; il transmet la de-mande du client au canal de communication.

class ProxyClientProduit : ClientBase<IDetailsProduit>, IDetailsProduit { public Produit TrouverProduit(string idProduit) { return this.Channel.TrouverProduit(idProduit); } }

9. Affichez le fichier ClientProduit.xaml dans la fenêtre Concepteur.

10. Faites un double clic sur le bouton Trouver le produit pour générer la



méthode du gestionnaire d’événement trouverProduit_Click de ce bouton.

11. Dans la fenêtre Code, ajoutez les instructions using suivantes à la liste en haut du fichier ClientProduit.xaml.cs :

using ContratsDetailsProduit;

12. Dans la méthode trouverProduit_Click, ajoutez le code en gras sui-vant :

private void trouverProduit_Click(object sender, RoutedEventArgs e) { ProxyClientProduit proxy = new ProxyClientProduit(); try { Produit produit = proxy.TrouverProduit(idProd.Text); nomProduit.Content = produit.ProductName; idFournisseur.Content = produit.SupplierID.Value; idCategorie.Content = produit.CategoryID.Value; quantiteParUnite.Content = produit.QuantityPerUnit; prixUnitaire.Content = String.Format("{0:C}", produit.UnitPrice.Value); unitesEnStock.Content = produit.UnitsInStock.Value; unitesEnCommande.Content = produit.UnitsOnOrder.Value; seuilReassort.Content = produit.ReorderLevel.Value; enRupture.IsChecked = produit.Discontinued; } catch (Exception ex) { MessageBox.Show("Erreur en récupérant les détails du produit : " + ex.Message, "Erreur", MessageBoxButton.OK, MessageBoxImage.Error); } finally { if (proxy.State == CommunicationState.Faulted) { proxy.Abort(); } else { proxy.Close(); } } }

Ce code crée une instance de la classe ProxyClientProduit et l’utilise pour appeler la méthode TrouverProduit du service Web REST. Les



données de l’objet Produit retournée sont affichées dans les contrôles label du formulaire.

13. Dans l’Explorateur de solutions, faites un double clic sur le fichier app.config. C’est le fichier de configuration de l’application. Il a été généré automatiquement lorsque vous avez créé le proxy du service Web SOAP dans un exercice précédent. Il contient un élément <sys-tem.serviceModel> qui décrit le point de terminaison du service Web SOAP, notamment l’URL à laquelle l’application doit se connecter.

14. Recherchez l’élément <client>, et ajoutez l’élément <endpoint> en gras à la section existante <endpoint> :

<client> <endpoint address="http://localhost:4600/DetailsProduitService/Service.svc" binding="webHttpBinding" contract="ContratsDetailsProduit.IDetailsProduit" behaviorConfiguration="WebBehavior"> </endpoint> <endpoint address="http://localhost:4500/ServiceInformationsProduit/Service.svc" binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IInformationsProduit" contract="ServiceInformationsProduit.IInformationsProduit" name="WSHttpBinding_IInformationsProduit"> <identity> <userPrincipalName value="VotreOrdinateur\VotreNom" /> </identity> </endpoint> </client>

15. Après la balise fermante </client>, ajoutez la section <behaviors> en gras :

<client> ... </client> <behaviors> <endpointBehaviors> <behavior name="WebBehavior"> <webHttp /> </behavior> </endpointBehaviors> </behaviors>

Ce code définit le comportement WebBehavior référencé par le



client point de terminaison. Il spécifie que le client doit se connecter au service Web en utilisant le comportement webHttp attendu par le service Web REST.

16. Dans le menu Déboguer, cliquez sur Démarrer sans débogage.

17. Lorsque le formulaire Détails du produit apparaît, dans la zone de texte ID Produit, saisissez 10 ; dans la zone de texte Combien, saisissez 5 ; puis cliquez sur Calculer le coût. Le coût total doit être affiché (155). Cela permet de vérifier si le service Web SOAP fonctionne tou-jours.

18. Cliquez sur Trouver le produit. Les détails pour Ikura doivent apparaître dans les étiquettes du formulaire, comme dans la figure suivante :

19. Testez avec d’autres ID produit. Notez que si vous spécifiez un ID pro-duit qui n’existe pas, le service Web retourne une exception « Bad Re-quest ».

20. Fermez le formulaire Détails du produit lorsque vous avez terminé.

Dans ce chapitre, vous avez vu comment utiliser Visual Studio pour conce-voir deux styles différents de service Web : SOAP et REST. Vous avez égale-ment vu comment concevoir des applications clientes qui peuvent utiliser ces styles de service Web.

Vous avez également terminé tous les exercices de ce livre. Vous devez maintenant connaître très bien le langage C# et comprendre comment utiliser Visual Studio 2010 pour générer des applications professionnelles. Cependant, ce n’est pas la fin de l’histoire. Vous avez sauté la première haie, mais les meilleurs programmeurs C# apprennent en pratiquant, et vous pouvez acquérir cette expérience uniquement en générant des ap-



plications C#. Vous allez ainsi découvrir de nouvelles façons d’utiliser le langage C# et de nombreuses fonctionnalités disponibles dans Visual Stu-dio 2010 que je n’ai pas eu la place de traiter dans ce livre. N’oubliez pas également que C# est un langage qui évolue. En 2001, lorsque nous avons écrit la première édition de ce livre, C# présentait une syntaxe et une sé-mantique permettant de générer des applications qui utilisaient le .NET Framework 1.0. Certaines améliorations ont été ajoutées à Visual Studio et au .NET Framework 1.1 en 2003, puis en 2005, C# 2.0 est apparu et prenait en charge les génériques et le .NET Framework 2.0. C# 3.0 a ajouté de nombreuses fonctionnalités telles que les types anonymes, les expressions lambda, et la plus significative, LINQ. Et maintenant C# 4.0 a étendu le langage encore plus avec la prise en charge des arguments nommés, des paramètres optionnels, des interfaces contra et covariant, et l’intégration avec des langages dynamiques. La prochaine version de C# nous réserve-ra sans doute d’autres surprises…

Aide-mémoire du chapitre 29 Pour Accomplissez

Créer un service Web SOAP Utilisez le modèle Service WCF. Définissez un contrat de service qui spécifie les méthodes Web exposées par le service Web en créant une interface avec l’attribut ServiceContract. Marquez chaque méthode avec l’attribut OperationContract. Créez une classe qui implémente cette interface. Configurez le service pour utiliser la liaison wsHttpBinding.

Créer un service Web REST Utilisez le modèle Service WCF. Définissez un contrat de service qui spécifie les méthodes Web exposées par le service Web en créant une interface avec l’attribut ServiceContract. Balisez chaque méthode avec l’attribut OperationContract et l’attribut WebGet, qui spécifie le modèle URI pour appeler la méthode. Créez une classe qui implé-mente cette interface. Configurez le service pour utiliser la liaison webHttpBinding, et spécifiez le comportement webHttp pour le point de terminaison du service.



Pour Accomplissez

Afficher la description d’un service Web SOAP

Faites un clic droit sur le fichier .svc dans l’Explorateur de solutions, et cliquez sur Afficher dans le navigateur. Internet Explorer s’exécute, va sur l’adresse du service Web, et affiche une page décrivant comment créer une application cliente pouvant accéder au service Web. Cli-quez sur le lien WSDL pour afficher la description WSDL du service Web.

Transmettre des données complexes en tant que méthode Web et retourner des valeurs

Définissez une classe pour contenir les données, et balisez-la avec l’attribut DataContract. Assurez-vous que chaque élément des don-nées est accessible soit comme champ public soit via une propriété publique qui fournit les accès get et set. Assurez-vous que la classe possède un constructeur par défaut (qui peut être vide).

Créer une classe proxy d’un service Web SOAP dans une application cliente

Dans le menu Projet, cliquez sur Ajouter une référence de service. Sai-sissez l’URL du service Web dans la zone de texte Adresse en haut de la boîte de dialogue, puis cliquez sur Aller à. Spécifiez l’espace de noms de la classe proxy, puis cliquez sur OK.

Créer une classe proxy d’un service Web REST dans une application cliente

Créez une classe qui hérite de la classe générique ClientBase, et spéci-fie l’interface qui définit le contrat de service en tant que paramètre de type. Implémentez cette interface, et utilisez la propriété Channel héritée de la classe ClientBase pour envoyer des demandes au service Web.

Appeler une méthode Web Créez une instance de la classe proxy. Appelez la méthode Web en utilisant la classe proxy.

Chapitre29 Visual C# 2010 etape par etape - Web Services SOAP .net

Documents

Transcript of Chapitre29 Visual C# 2010 etape par etape - Web Services SOAP .net