Créer une architecture .NET distribuée

Créer et utiliser un service Web .NET

Comprendre les services Web XML

Les services Web sont des unités discrètes de fonctionnalité programmée et exposée aux clients via des protocoles de communication et des formats de données standardisés, à savoir HTTP et XML. Ces protocoles et formats sont bien connus et largement acceptés.

En communiquant via HTTP, les services Web résolvent le problème de la communication sur Internet et au travers des pare-feu d’entreprise sans faire appel à des solutions propriétaires qui imposent l’ouverture de ports de communication supplémentaires pour les accès externes. Les services Web utilisant XML pour la mise en forme des demandes et des réponses, ils peuvent être exposés et utilisés par toute plate-forme capable de mettre en forme ou d’analyser un message XML. Cela permet à ces services d’assembler des blocs de fonctionnalité disparates, existants ou nouveaux, internes ou externes à une organisation, en un ensemble cohérent.

OK, et CORBA alors? Il est vrai que CORBA va adresser tous ces sujets. Vous pouvez avoir des types complexes de données, clients et serveurs peuvent employer n'importe quel mélange de langages et de plates-formes, vous pouvez réutiliser la couche métier de votre architecture n-tiers et vous pouvez isoler le client des détails architecturaux du back-end.

Alors pourquoi devrions nous introduire SOAP? Voici quelques raisons:
CORBA exige de compiler et distribuer des stubs client pour chaque type de clients que vous avez. Ce n'est pas toujours pratique, particulièrement quand vous avez un grand nombre de combinaisons de plates-formes et de langages ou quand vous voulez offrir des services à des clients anonymes au travers d'internet. Si vous développez des services Web (voir plus bas) alors IIOP (le protocole de transfert de CORBA) n'est pas particulièrement convivial avec les firewall. Donc si vous voulez offrir des services à des clients au travers d' internet et bien que ce ne soit pas impossible avec CORBA, vous allez devoir surmonter des obstacles liés aux firewall. Le document suivant nous illustre le principe de fonctionnement des WebServices à travers un exemple pratique : un convertisseur Euro écrit en C#.

Le scénario comprend trois étapes :

• Le client demande un service sur le principe des pages jaunes. Vous cherchez un convertisseur Euro ? Dans ce cas, une recherche sémantique dans un annuaire UDDI vous donnera la liste des prestataires habilités à répondre à votre requête. Un peu comme les moteurs de recherches full texte sauf qu'ici vous effectuez une demande de services et non de documents.
  

• Une fois la réponse reçue (en XML), vous recherchez l'interface du composant référencé dans l'annuaire. Cette interface spécifiée en WSDL (encore du XML :-)) décrit l'ensemble des services implémentés par l'objet distribué. Vous avez ainsi la possibilité de vérifier si le contrat correspond bien à votre demande. 
  

• Si l'interface vous convient, il ne reste plus qu'à effectuer l'invocation du service. Pour ce faire, il vous faut fournir les paramètres attendus par l'interface et assurer la communication avec le serveur. Tout cela est pris en charge par un objet généré coté client à l'aide de l'interface WSDL et d'un outil adéquat. Cet objet possède toute l'intelligence nécessaire à la communication entre le client et le serveur. C'est le Proxy

Nous allons maintenant définir de manière plus concrète l'ensemble de ces technologies afin de bien comprendre leur mode d'utilisation.

Il est primordial de comprendre que SOAP est un protocole basé sur XML et en conséquence, particulièrement prolixe. CORBA, au travers de IIOP, le battra en performance car les opérations de conversion et de déconversion (marshalling et demarshalling) dans CORBA sont plus efficaces et il y a moins de données sur le réseau. Ceci dit, il y a un avantage significatif pour SOAP d'être basé sur du XML: le fait qu'il peut être lu et écrit par des humains. Ceci signifie que vous pouvez lire et manipuler les messages qui passent par le réseau. C'est extrêmement utile quand on débogue.

Un peu de vocabulaire ...

• SOAP (Simple Object Access Protocol)
SOAP est un format de structuration de messages en XML totalement indépendant d'un protocole de communication particulier. Pour faire un parallèle avec le monde réel, c'est comme si tout le monde parlait une langue universelle (j'en entends déjà hurler) et se servait de différents modes de communication afin de véhiculer leurs paroles (téléphone, radio, manuscrits, ...). SOAP est la langue universelle, et les protocoles représentent les différents canaux de communication pouvant être utilisés.   Sur plusieurs aspects, SOAP reprend certains paradigmes des dialogues requête-réponse de type RPC (Remote Procedure Call) et se marie parfaitement avec le protocole HTTP, mais il n'est pas impossible de trouver des implémentations de SOAP sur d'autres protocoles. SOAP est un protocole de messagerie basé sur XML qui a été standardisé par le W3C. La spécification SOAP impose le format des messages SOAP (nommé enveloppes SOAP), et fournit des standards optionnels pour le codage des données, le traitement demande/réponse et la liaison des messages SOAP avec HTTP.

La syntaxe d'un message SOAP est décrite en détail sur le w3c. Voici un résumé et quelques exemples pour les impatients.
Un message SOAP valide est un document XML au bon format. (pour plus de détails sur XML et sur le format correct, visitez le site w3c ). Le prologue XML peut être présent, mais dans ce cas, ne doit contenir qu'une déclaration XML (c-à-d. qu'il ne doit contenir ni référence à un DTD, ni instruction XML). Le message doit utiliser l'enveloppe SOAP et les namespaces d'encodage SOAP, et doit avoir la forme suivante:
Une déclaration XML (optionnelle), suivie de une Enveloppe SOAP (l'élément racine) qui est composée de: Une En-tête SOAP (optionnel) Un Corps SOAP Un dialogue RPC encodé par SOAP contient un message de requête et un message de réponse. Considérons la méthode d'un service simple qui double la valeur d'un entier donné. Signature de la Methode

int doubleAnInteger ( int numberToDouble );

La Requête SOAP

<?xml version="1.0" encoding="UTF-8" standalone="no" ?> 
<SOAP-ENV:Envelope   
	SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"   
	xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"  
	xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"   
	xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"   
	xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>		
	<ns1:doubleAnInteger		 xmlns:ns1="urn:MySoapServices">			
		<param1 xsi:type="xsd:int">123</param1>		
	</ns1:doubleAnInteger>	
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

La Réponse SOAP

 
	<?xml version="1.0" encoding="UTF-8" ?>  
	<SOAP-ENV:Envelope   
		xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"   
		xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"   
		xmlns:xsd="http://www.w3.org/1999/XMLSchema">	
	<SOAP-ENV:Body>	
		<ns1:doubleAnIntegerResponse	
			 xmlns:ns1="urn:MySoapServices"	
			 SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">		
		
			<return xsi:type="xsd:int">246</return>	
		</ns1:doubleAnIntegerResponse>	
	</SOAP-ENV:Body>  
	</SOAP-ENV:Envelope>



Maintenant, nous, développeurs côté client, nous ne voulons pas nous occuper de tous les détails de sérialisation SOAP et de l'encodage de HTTP. Nous employons alors un package SOAP qui le fera pour nous. Il s'agit typiquement d'une librairie que nous linkons dans notre propre code client. Nous invoquons ensuite le service, simplement en invoquant la méthode appropriée du package SOAP (typiquement en spécifiant l'URL du service, le nom du service et tous les paramètres requis). Le premier travail d'un package est de sérialiser l' invocation de ce service en requête SOAP. Il doit ensuite encoder ce message dans une requête HTTP et l'envoyer à l'URL spécifiée. Il y a beaucoup de packages SOAP disponibles gratuitement pour de nombreuses plates-formes. Vous pouvez ainsi écrire votre code client en n'importe quel langage et sur n'importe quelle plate-forme pour lesquels vous pouvez trouver un package SOAP.

Parmi les packages possibles:

• Visual Basic et le Toolkit Microsoft SOAP
• Java (Stand-alone ou Servlet/JSPs etc) et Apache SOAP pour Java
• Perl (Stand-alone ou CGI-Perl scripts etc) et SOAP::Lite pour Perl




• WSDL (Web Service Definition Langage)
WSDL est un format de représentation des interfaces de Service Web en XML. Il spécifie le prototype des services comprenant les signatures des méthodes et les différents types utilisés. Pour ceux ayant déjà pratiqué CORBA ou COM, WSDL est la représentation XML du langage IDL (Interface Definition Language) ou MIDL (Microsoft) de description des interfaces. WSDL a plusieurs rôles : Non seulement il sert de référence à la génération de proxies mais il assure que le couplage entre le client et le serveur se fait via les interfaces. Ainsi, toute évolution dans l'implémentation d'un service n'aura aucun impact sur le client tant que les interfaces restent inchangées et compatibles. La syntaxe d'un message WSDL est décrite en détail sur le w3c. Voir l'exemple de fichier avec le service web HelloWorld.



• UDDI (Universal Description, Discovery and Integration)
Voici la définition donnée sur uddi.org : "The project creates a platform-independent, open framework for describing services, discovering businesses, and integrating business services using the Internet, as well as an operational registry that is available today.". L'objectif est avant tout de fournir un annuaire mondial permettant de retrouver des services web sur le même principe que les pages jaunes. La réussite d'UDDI ne pourra se faire que si les différents fournisseurs de WebServices parviennent à s'entendre sur la définition de critères communs et de catégories "métier" bien déterminées. Cela n'empêche pas sa mise en oeuvre dans le cadre de places de marchés collaboratifs ou dans des domaines très spécifiques. En attendant, Microsoft et IBM proposent des solutions plus légères à mettre en oeuvre telles que WS-Inspection ou Disco.

Heureusement, le modèle de programmation ASP.NET présente l’avantage de faire complètement abstraction de la complexité de la messagerie SOAP dans le développement des services Web.

Créer un service Web

Avec ASP.NET, les services Web XML sont très simples à créer, parce que ce langage oblitère complètement la complexité de la messagerie SOAP et du transport HTTP pour les développeurs. Cette abstraction s’obtient avec des attributs indiquant au runtime qu’une classe spécifique et ses méthodes doivent être considérées comme des services Web. En fonction de ces attributs, le runtime fournit le code nécessaire pour exposer la classe et les méthodes sous forme de service Web, en fournissant aussi un contrat que les clients peuvent utiliser pour déterminer comment appeler le service et quel type de données il va renvoyer.

Les services Web sont définis dans des fichiers avec l'extension .ASMX. Le code réel du service Web ASP.NET peut en fait résider soit dans le fichier .ASMX, soit dans une classe précompilée.

Syntaxe de déclaration d'un service Web dans lequel la classe est définie dans le fichier asmx:

 
<@ WebService Language="c#" Class="NomClasse" >

Ou soit la syntaxe évoquée dans le cas où le code définissant la classe et les méthodes réside dans une classe compilée :

 
<%@ WebService Class="NomEspaceDeNom.NomClasse, NomAssemblage" > 

Cet assemblage devrait se trouver dans le répertoire bin de l'application Web dans laquelle réside le fichier .ASMX. La partie NomAssemblage est optionnelles mais il est toujours préférable de la préciser pour éviter l'impact sur les performances avec la recherche réalisée lors du premier accès au service Web. Il n'est pas nécessaire qu'une classe dérive de WebService pour fonctionner comme un service Web, mais la classe fournit des fonctions intéressantes pour les services Web. Il s'agit en particulier de l'accès à Application, Session ou tout autre objet ASP.NET dont l'objet Context, qui permet d'accéder aux informations concernant la demande HTTP qui appelle le service Web.

Les services Web XML utilisent l'espace de noms XML pour identifier de façon unique la cible ou le service d'écoute auquel un client envoie ses demandes, ASP.NET définit par défaut l'espace de noms XML d'un service web en http://tempuri.org. Si on prévoit de rendre son service web publiquement disponible sur internet, modifier l'espace de noms par défaut pour éviter tout conflit potentiel avec d'autres services Web XML utilisant le même nom que celui de son service, et qui pourraient aussi utiliser l'espace de noms par défaut. ? Propriété NameSpace de l'attribut de métadonnée WebService


Une question qui se pose fréquemment dans la mise en œuvre des WebServices est la suivante :
    « Puis-je passer n’importe quel type d’objet en paramètre tels que des ResultSet Java ou des DataSet .NET ?
    » La réponse se trouve dans la matrice à l'adresse (http://www.dotnetguru.org/articles/InteropWS/InteropWSJavaDotNet.htm).

En effet, il n’existe aucun mapping prenant en compte l’ensemble des API .NET ou Java (ou autre) avec Soap, c’est pourquoi, les WebServices, au même titre que  les ponts .NET Remoting et RMI (JaNet), ne doivent pas être utilisés afin de véhiculer des graphes d’objets dépendants d’un Framework technique. D’ailleurs, cela n’a pas beaucoup de sens étant donné la complexité inhérente aux Frameworks .NET et Java.  Pour cela , il faudrait disposer des mêmes API de part et d’autre, on sait bien aujourd’hui, que ce n’est pas le cas.
Quand vous utilisez HTTP GET ou HTTP POST pour les demandes de service Web, le jeu de types de données supportés est plus limité, tous ces types étant représentés par des chaînes pour le client. De plus les paramètres d'entrée ne peuvent être transmis que par valeur, alors que les paramètres des demandes SOAP peuvent être transmis soit par valeur, soit par référence.



L'important dans la publication est de savoir comment diffuser son service web de façon à ce que les clients intéressés puissent le découvrir facilement et l'intégrer à leurs applications.

La découverte de service Web est le processus de recherche et d'interrogation des descriptions du service Web, qui correspond à l'étape préliminaire pour un accès à un service Web XML. C'est par l'intermédiaire du processus de découverte que les clients du service Web apprennent son existence, découvrent ses fonctionnalités et la façon d'interagir correctement avec lui.

• Cependant, le site Web implémentant un service Web XML n'est pas obligé de gérer ce processus de découverte. Un autre site peut être chargé de décrire le service, par exemple un répertoire de Services Web. Par ailleurs, il n'est pas indispensable d'avoir un moyen public de rechercher un service ; c'est le cas lorsque vous créez le service pour un usage privé.
• Vous pouvez activer une découverte programmatique d'un service Web XML en publiant un fichier .disco, qui est un document XML contenant des liens vers d'autres ressources telles que des schémas XSD ou des descriptions de services. Les Services Web créés avec ASP.NET ont automatiquement la possibilité de proposer un document de découverte généré. Par exemple, pour accéder au document de découverte d'un service Web XML nommé HelloWorld.asmx sur votre machine locale, utilisez l'URL ci-après :

   
  http://localhost/disco/HelloWorld.asmx?DISCO
  

  
  
• La découverte dynamique
est un processus par lequel ASP.NET effectue une recherche itérative dans une hiérarchie de dossiers sur un serveur Web de développement afin de repérer les Services Web disponibles. Un fichier de découverte dynamique (.vsdisco) est un fichier XML, qui peut contenir aucun ou plusieurs noeuds <exclude>. Chaque noeud <exclude> contient un attribut "path" avec le chemin d'accès relatif à un sous-dossier que le processus de découverte dynamique n'a pas à explorer. Lorsqu'un fichier .vsdisco est demandé par un serveur Web sur lequel la découverte dynamique est opérationnelle, un document de découverte est renvoyé, avec des informations sur chaque service localisé par le processus dynamique. Par défaut, la découverte dynamique est désactivée dans le fichier web.config. Pour contrôler correctement les Services Web que les clients peuvent découvrir, la découverte dynamique ne doit être utilisée que sur des serveurs Web de développement. Lors du déploiement d'un service Web XML sur un serveur Web de production, vous devez créer et publier un fichier de découverte statique (.disco) qui fournira aux clients des informations sur les services proposés.

Une fois le service Web XML déployé, vous devez étudier un moyen qui permette aux développeurs de le localiser, pour que d'autres usagers y accèdent. Une solution qui a fait ses preuves est de l'inscrire dans un répertoire de Services Web. Le projet UDDI (Universal Description, Discovery and Integration) propose un répertoire des entreprises et des services qu'elles offrent.

• Test dans un navigateur

ASP.NET va générer un ensemble de pages de documentation décrivant les méthodes Web disponibles et la syntaxe que les clients peuvent appliquer pour accéder à ces méthodes.

Utiliser un service Web

L'utilisation d'un service web se fait selon les étapes suivantes :

• Location du service Web
  • Localisation avec fichier disco :
  Une fois que vous didposez de l'URL du .disco, vous pouvez executer l'utilitaire de ligne de commande disco.exe pour générer les contrats WSDL: disco [options] URL
  • Localisation avec UDDI:
  Le registre UDDI de Microsoft , à l'adresse http://uddi.microsoft.com/search/search.aspx fournit la recherche à partir de différents critères
• Créer une classe proxy: Il est assez compliqué d'utiliser un service Web via SOAP. Il faut créer et mettre en forme une enveloppe SOAP, un jeu d'en-têtes et un corps SOAP, avec l'ensemble des éléments et attributs appropriés au service web recherché.
  Tout le code requis pour l'accès à un service Web est heureusement fourni par le .NET Framework. Il offre un utilitaire wsdl.exe, destiné à créer une classe proxy .NET pour un service décrit par un contrat WSDL.

   
  Voici la syntaxe de wsdl.exe:
  wsdl [options] {URL | chemin}
  Par exemple : wsdl /l:cs /n:ASPNETSBS "http://localhost/disco/server/HelloService_CB.asmx?WSDL" va générer Hello.cs
  
  

  
  Ne pas oublier de compiler le proxy et de deployer l'assemblage obtenu dans le sous-répertoire bin de l'application où se trouve l'application cliente.
• Instanciation de la classe Proxy comme n'importe quelle classe locale

Sous Visual Studio : L'accès à un service Web XML à partir d'un code géré est un processus simple.

• En premier lieu, ajoutez une référence Web dans votre projet pour le service auquel vous souhaitez accéder. Cette référence Web crée une classe proxy avec des méthodes qui servent de proxys pour chaque méthode exposée du service en question.
• Ensuite, ajoutez l'espace de noms pour la référence Web.
• Enfin, créez une instance de la classe proxy et accédez aux méthodes de cette classe comme vous le feriez avec les méthodes de n'importe quelle autre classe.

Attention la classe proxy est nécessaire, lorsque vous ne pouvez pas accéder au service Web XML depuis la machine sur laquelle est installé Visual Studio, par exemple lorsque le service Web XML se trouve sur un réseau inaccessible au client au moment de l'exécution. Ensuite, vous ajoutez manuellement dans votre projet d'application le fichier généré par cet outil.

AIDE MEMOIRE Web Service :

• Créer un service XML en utilisant .NET
Créer un fichier d'extension .ASMX et ajouter la directive @ WebService dans ce fichier. Créer une classe pour implémenter le service en ajoutant l'attribut WebMethod dans chaque méthode que vous souhaitez voir exposée par le service Web.
• Tester un service Web
Afficher le fichier .ASMX contenant le service Web dans un navigateur Web. ASP.NET va générer les pages de documentation du service et permettre d'appeler ce service Web
• Publier un service Web
Créer un document de découverte pour vos services Web et publier ce document sur un site public, comme le site Web d'entreprise, ou enregistrer vos services dans un des registres commerciaux UDDI disponible publiquement, sans oublier de fournir l'URL du contrat WSDL de chaque service Web que l'on enregistre.
• Utiliser un service Web dans ASP.NET
Avec l'utilitaire wsdl.exe, créer une classe proxy basée sur le contrat WSDL du service Web, compiler la classe et instancier la dans l'application cliente comme vous le feriez avec n'importe quelle autre classe .NET.

Une remarque importante concernant les clients de services Web est qu'ils ne sont pas limités aux formulaires Web ASP.NET. Vous pouvez tout aussi bien intégrer des services Web dans des applications graphiques, des applications console ou même d'autres services Web.


Les Services Web permettent l'échange de messages dans un environnement souple via des protocoles standard tels que HTTP, XML, SOAP et WSDL. Les messages peuvent être structurés et typés, ou définis de manière flexible. Des protocoles standard étant à la base des services Web XML, les applications pour ce type de services peuvent communiquer avec un grand nombre d'implémentations, de plates-formes et de périphériques.

Vous créez des Services Web en utilisant la structure de page ASP.NET qui permet à ces mêmes services d'accéder aux multiples fonctionnalités de .NET Framework. Les Services Web s'appuient sur ASP.NET et .NET Framework, de sorte que les développeurs peuvent se consacrer à la création de services ou à leur accès sans avoir à écrire un code d'infrastructure. L'accès à un service Web XML en code géré est un processus relativement simple lorsque vous utilisez une classe proxy générée directement par Visual Studio à partir de la description du service. La classe proxy fait le nécessaire pour convertir l'appel de méthode en un message de requête, et le message de réponse en valeur de retour de méthode.