En s'interrogeant tout d'abord sur les raisons de leur utilisation, ce chapitre introduit à la pratique des applications informatiques distribuées, applications réalisées par le biais d'objets distribués, s'activant sur des ordinateurs séparés et communiquant à travers la couche physique : Internet ou un niveau sémantique au-dessus : le Web. Différentes implémentations de ces objets distribués seront évoquées et expérimentées.
Répartition des utilisateurs et des responsables, tous les utilisateurs de l'informatique ne partagent pas un même lieu géographique, et ne l'utilisent pas pour les mêmes raisons. Ils sont tout autant distribués que l'est leur machine. Et leur mobilité est devenue celle de leur portable. L'existence des objets distribués conduit à faciliter l'intégration de services rendus par des entreprises commerciales distinctes mais, éventuellement complémentaires. A ce titre, on parle souvent et de plus en plus, d'architecture informatique orientée service (SOA).
XML : pour une dénomination universelle des services, la façon dont les services sont présentés sur l'annuaire, et celui dont le message ainsi que son retour sont codés rien de tout cela n'est vraiment conforme au style dans lequel les concepteurs et le acteurs principaux du Web ont décidé de coder toutes informations installées et circulant sur ce Web. Pour autant que les services à disposition, ainsi que les messages qui y circulent sur Internet, soient à assimiler à n'importe quel autre type d'informations disponibles sur le Web, un standard aujourd'hui s'impose, qui a pour nom XML. La circulation ne se fait plus véritablement via internet mais via le Web, en utilisant le protocole http. Dans l'approche des services web, tout comme dans n'importe quel échange au-dessus du protocole http, un « serveur web » est indispensable pour recevoir et traiter la requête côté serveur (par exemple : « IIS » sur Windows). Dans les services web par le protocole http, ne circule que du texte et non des ordres prêts pour l'exécution.
Pas un jeu de balises imbriquées, XML permet de structurer de manière très homogène tout le contenu sémantique (à différencier de sa seule mise ne forme) des documents disponibles sur le Web. XML pourrait ainsi constituer un mode de représentation des services et des messages envoyés sur le Web, à utiliser au-dessus des autres existants. Cela permet également d'homogénéiser, dans leur représentation, tous les services disponibles sur le Web, quelle que soit l'implémentation finale de ces services. L'interopérabilité redevient possible à partir d'XML. Ce mariage entre l'informatique distribuée, la possibilité qu'ont deux applications de se solliciter mutuellement à travers le web et le langage XML porte le nom de « services web ».
Microsoft a parfaitement anticipé avec XML cette homogénéisation du contenu des messages et des services dans sa nouvelle plate-forme .Net, en automatisant la traduction en XML de tous services codés, au départ, dans un langage de programmation comme C# ou VB.Net.
XML
XML installe l'information dans une structure imbriquée de balises, comme l'exemple ci-après l'illustre, lorsqu'il s'agit d'encoder un livre et ses auteurs :
<livre>
<auteur>
<prénom> Hugues </prénom>
<nom> Bersini </nom>
</auteur >
<auteur>
<prénom> Ivan </prénom>
<nom> Wellesz </nom>
</auteur >
</livre>
Il est facile dans une telle structure récursive d'effectuer une recherche ou de traiter l'information. L'utilisation massive d'XML devrait permettre une bien plus importante homogénéisation de toute l'information contenue dans Internet, impossible par l'HTML (qui est une simple manière d'organiser la disposition de cette information main non pas de définir son contenu). La dénomination des balises est laissée au choix des concepteurs. Cependant, l'intérêt est de s'accorder sur des dénominations et des structurations de document communes, qui seront définies dans un format appelé DTD (Data Type Dictionnary), par exemple, toujours pour le livre :
< !ELEMENT livre (auteur)+>
< !ELEMENT auteur (prénom, nom)>
< !ELEMENT prénom (#PCDATA)>
< !ELEMENT nom ( #PCDATA )>
Un autre possibilité, plus récente, d'écriture des documents de conformation a été adoptée dans le cadre des services web. Ce sont les schéma XML, plus proches dans leur syntaxe des documents XML de base (à nouveau, un système de balises imbriquées, ce qui permettra d'uniformiser le traitement). En permettant la prise en compte de type de données plus complexes que la simple composition récursive propre à XML, ces schémas faciliteront la traduction dans un format XML des bases de données relationnelles ainsi que des diagrammes de classe UML. Le schéma XML de l'exemple du haut ressemblerait plus ou moins à ceci :
<Schema xmlns = « urn :schemas-microsoft-com :xml -data » >
<ElementType name = "prénom" content = "textOnly" model = "closed" />
<ElementType name = "nom" content = "textOnly" model = "closed" />
<ElementType name = "auteur" content = "elOnly" model = "closed" >
<element type name = "nom" minOccurs= "1" maxOccurs= "1" / >
<element type name = "prenom" minOccurs= "1" maxOccurs= "1" / >
</ElementType>
La manière dont .Net nous invite à développer des services web, la plus simple à mettre en oeuvre, en prenant conscience que cette manière d'intégrer XML dans la dénomination des services et des messages est en passe d'être adoptée par tous les grands constructeurs informatiques, tous les langages de programmation, et de devenir de facto un standard web.
Les services web sur .NET, la plate forme .Net a pour vocation de fournir un environnement qui simplifie la conception, le développement, le déploiement et l'exécution d'applications distribuées.
Code C# du service
using System;
using System.Web.Services;
public class TestService : System.Web.Services.WebService
{
[WebMethod]
public string jeTravaillePourLeWeb( string unNom) {
return "Salut, " + unNom + jeSuisPriveDansLaClasse() ;
}
private string jeSuisPriveDansLaClasse() {
return ", je travaille pour le web" ;
}
}
Un service web doit se coder dans un fichier de type asmx, .Net permet de partir directement de l'implémentation. La présence de [WebMethod], rend la signature de la méthode disponible sur le Web, sans qu'il y ait besoin de détacher cette signature pour l'installer dans un code à part (on dit que l'on « expose » la méthode sur le web).
De manière à rendre ce service disponible, mais surtout « lisible », sur le Web, .Net crée automatiquement une version XML de ce même service, reprenant ce qu'il y a lieu de connaître pour utiliser ce service : son nom, les arguments à passer et ce que le service renvoie en retour. Le type de langage XML utilisé à cette fin s'appelle Web Service Description Langage : WDSL. Ci-après, vous pouvez voir une partie de fichier TestService.asmx?WSDL qui reprend la description du service.
<?xml version="1.0" encoding="UTF-8"?>
-<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://tempuri.org/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://tempuri.org/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
-<wsdl:types> -<s:schema targetNamespace="http://tempuri.org/" elementFormDefault="qualified"> -<s:element name="jeTravaillePourLeWeb"> -<s:complexType> -<s:sequence> <s:element name="unNom" type="s:string" maxOccurs="1" minOccurs="0"/> </s:sequence> </s:complexType> </s:element> -<s:element name="jeTravaillePourLeWebResponse"> -<s:complexType> -<s:sequence> <s:element name="jeTravaillePourLeWebResult" type="s:string" maxOccurs="1" minOccurs="0"/> </s:sequence> </s:complexType> </s:element> </s:schema> </wsdl:types> -<wsdl:message name="jeTravaillePourLeWebSoapIn"> <wsdl:part name="parameters" element="tns:jeTravaillePourLeWeb"/> </wsdl:message> -<wsdl:message name="jeTravaillePourLeWebSoapOut"> <wsdl:part name="parameters" element="tns:jeTravaillePourLeWebResponse"/> </wsdl:message> -<wsdl:portType name="TestServiceSoap"> -<wsdl:operation name="jeTravaillePourLeWeb"> <wsdl:input message="tns:jeTravaillePourLeWebSoapIn"/> <wsdl:output message="tns:jeTravaillePourLeWebSoapOut"/> </wsdl:operation> </wsdl:portType> -<wsdl:binding name="TestServiceSoap" type="tns:TestServiceSoap"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/> -<wsdl:operation name="jeTravaillePourLeWeb"> <soap:operation style="document" soapAction="http://tempuri.org/jeTravaillePourLeWeb"/> -<wsdl:input> <soap:body use="literal"/> </wsdl:input> -<wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> -<wsdl:binding name="TestServiceSoap12" type="tns:TestServiceSoap"> <soap12:binding transport="http://schemas.xmlsoap.org/soap/http"/> -<wsdl:operation name="jeTravaillePourLeWeb"> <soap12:operation style="document" soapAction="http://tempuri.org/jeTravaillePourLeWeb"/> -<wsdl:input> <soap12:body use="literal"/> </wsdl:input> -<wsdl:output> <soap12:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> -<wsdl:service name="TestService"> -<wsdl:port name="TestServiceSoap" binding="tns:TestServiceSoap"> <soap:address location="http://localhost:5766/WebSite1/Service.asmx"/> </wsdl:port> -<wsdl:port name="TestServiceSoap12" binding="tns:TestServiceSoap12"> <soap12:address location="http://localhost:5766/WebSite1/Service.asmx"/> </wsdl:port> </wsdl:service> </wsdl:definitions>
WDSL, parmi les différentes informations encodées en XML (nous n'en détaillerons pas la structure), vous pouvez deviner le nombre et le type des arguments, le retour du services ainsi qu'à la fin, l'emplacement URL de ce dernier. Ici, car nous travaillons en local, cet emplacement est : http://localhost/5766/Service.asmx.
Afin de visualiser les services en format WDSL, il faut créer une URL virtuelle, ici le local localhost:/6152 et éditer le fichier TestService.asmxWSDL à partir de votre navigateur. La lecture du service web sur le navigateur n'est possible que si le serveur web est actif (IIs sous Windows). En effet, c'est lui qui reçoit la requête, l'interprète comme un service web et vous en expose le contenu. Mais bien évidemment, l'adresse URL de ce service variera en fonction de l'emplacement de l'objet à même de l'exécuter. Le service doit pouvoir être localisé sur Internet, mais cette localisation est directement codée sous forme XML et fait partie intégrante de la définition du service. Nous justifierons la présence de l'expression Soap par la suite.
L'existence de ce standard WSDL de description de services, WDSL, rendra toute application distribuée utilisable par l'ensemble des technologies d'objet distribués, tout environnement web (par exemple, ce service pourrait être utilisé à partir d'un navigateur Internet) et sur toute plate-forme informatique confondue.
Création du proxy, une fois le service disponible sur Internet et prêt à être exécuté sur un serveur donné, comment un client peut-il y avoir accès ? Il faut créer un « proxy » ou un « stub », qui permettra au client, localement, de procéder comme s'il s'adressait directement au serveur. C'est ce proxy qui sert de passerelle entre le client et le serveur. Comme dans tous les mécanismes d'invocation statique d'objet distribué décrits jusqu’à présent, c'est un intermédiaire essentiel.
Soap (Simple Objetct Access Protocol)
Soap est le protocol XML d'écriture des messages à envoyer au serveur (le nom des méthodes et leurs paramètres) et d'écriture de la réponse obtenue, suite à l'exécution des messages.
Mais où sont passés les objets ? Du côté serveur, l'objet est créé à la volée, le temps de l'exécution du service. Un nouvel objet est créé pour chaque message qui arrive au serveur, et est détruit à la fin de l'exécution de ce dernier. Cela simplifie grandement les choses et doit pouvoir suffire dans une majorité d'application. On peut dès lors légitimement se demander l'intérêt qu'il y a à maintenir un objet serveur toute la durée de l'interaction.
S'il est difficile de percevoir ce que cet objet pourrait nous apprendre au début de son activation, il n'en est pas moins vrai que, durant l'interaction, l'objet peut maintenir un ensemble d'information, du côté serveur, propice à cette interaction. Par exemple, un second envoi de message pourrait ne pas avoir le même effet selon les résultats du premier envoi (résultats enregistrés dans l'état de l'objet serveur). Imaginez un jeu informatique ayant cours sur le réseau ; le comportement de chaque objet, en réponse à un message envoyé par un autre, dépendra de son état. De même, dans un négociation commerciale entre deux objets, les décisions prises par chaque objet lors de cette interaction dépendrons de leur connaissance de cette négociation.
Un manière de procéder pourrait consister à sauvegarder cet état intermédiaire sur le disque dur (par exemple, dans un base de données). Cependant, vu les temps d'accès disque, cela pourrait considérablement ralentir et alourdir le déroulement de l'application.
Les services web ne fonctionnent pas directement au-dessus de TCP/IP, en raison de leur homogéneisation web et de leur codage XML, un étage plus haut, au dessus du protocole HTTP (le protocole de communication web). Lorsque, au-dessus de ce protocole, une interaction client-serveur doit se dérouler, en maintenant, du côté serveur, des informations sur son état, on invoque souvent la présence de « cookies ».
Un annuaire des services XML universel : UDDI, existe t'il dans cette nouvelle infrastructure d'objet distribué, un mode d'organisation et de présentation en annuaire ? Oui, car tous les constructeurs se sont mis d'accord sur un mode uniforme de présentation de ce services, dénommé UDDI (Universal Description Discovery and Integration). Tous les services décrits dans le langage WDSL peuvent y être affichés et consultés, ainsi que leur emplacement et la façon de les activer.
Dès qu'un de ces services se révèle utile à un client, ce dernier pourra télécharger le proxy du service, de manière, par exemple, à pouvoir communiquer directement avec le serveur responsable du service. La spécification UDDI décrit une série de standards que les fournisseurs de services web doivent respecter, afin de présenter leur service dans cet annuaire. Dans l'annuaire UDDI, chaque enregistrement contient trois types d'informations, décrits sur le modèle des bottins téléphoniques (nom, adresse, contact de l'entreprise), des pages jaunes (catégorie de l'entreprise) et pages vertes (informations plus techniques concernant le service web). Logiquement centralisé mais physiquement réparti, cet annuaire universel recueille les inscriptions des fournisseurs de services web et permet à tout un chacun d'effectuer des recherches selon ses besoins.
Services web, il est incontestable que les services web sont en train de damer le pion de leurs concurrents. En premier lieu, du fait de la généralisation d'XML à tout le contenu du web, que celui-ci soit statique (sites) ou plus dynamique (service). Ensuite, grâce à la facilité et à la rapidité (due à l'automatisation) de mise en oeuvre de ces mêmes services - en tout cas en ce qui concerne la plate-forme de développement .Net.
Cependant, les services web ne sont pas à l'abri des critiques. Le contenu d'un message doit être « parsé » avant de pouvoir s'exécuter. Ce processus est long, et doit en outre faire l'objet d'une standardisation (par exemple : types de données que l'on peut passer en arguments et en retour des méthodes) afin qu'un message XML envoyé par un client soit interprété correctement par le serveur. C'est loin d'être le cas aujourd'hui avec la multiplication des standards Soap.
Malgré sa dénomination, Soap (Simple Object Access Protocol), le protocole d'envoi et de réception de message, n'est pas du tout orienté objet : rien n'est prévu pour la référence, la sauvegarde ou le maintien de l'état des objets durant un session. Comme nous l'avons vu précédemment, il n'y a pas vraiment d'objets exécutant les services le temps de l'interaction. Les objets sont les grands absent des services web. Sans doute le véritable avantage des services web s'avère être un contrôle plus efficace de la sécurité, surtout grâce aux pare-feu qui empêchent toute circulation sur des ports autres que http (le port 80 utilisé par les service web).
Aucun commentaire:
Enregistrer un commentaire