Services Web Présentation

Les services web XML Les Services Web sont la pierre angulaire de la stratégie Microsoft .Net: Ils permettent De développer des applications distribuées hautement évolutives et faiblement couplées. Il utilisent des protocoles Web standard comme HTTP, XML, WSDL et SOAP.

Vue d’ensemble Un service Web constitue un composant implémentant une logique de programme. Les services Web s’appuie sur une messagerie XML pour envoyer et recevoir des données. Ils permettent à des applications hétérogènes d’interopérer entre elles. Les services Web peuvent s’intégrer dans des applications écrites en différents langages et déployés sur différentes plates-formes. Ils fonctionnent aussi bien sur un intranet que sur Internet.

Niveau d’abstraction Le client n’a pas à connaître le langage dans lequel est implémenté le service Web. Le client doit juste connaître l’emplacement du service Web. Le client et le serveur ignorent tous deux les détails d’implémentation de l’autre.

Infrastructure des services Web Annuaire de services Web. Fournit un emplacement central pour stocker des informations publiées sur les services Web. La spécification UDDI définit les instructions permettant de publier les informations sur les services Web. Découverte des services Web. A l’aide de ce processus, les clients recherchent les documents décrivant un service Web à l’aide de WSDL. Description des services Web. Ce composant fournit des informations permettant de connaître les opérations qu’il est possible d’effectuer sur un service Web. Formats de transmission des Services Web. Pour permettre la communication entre systèmes distincts, les services Web utilisent des formats de transmission ouverts HTTP et SOAP.

Infrastructure des services Web page 366

Services Web vs Application Web. Les services web ne possèdes pas d’interface utilisateur. Les services exposent des méthodes web sur le net. Les services Web fournissent des services aux applications (Web, GUI, ...) mais ne sont destines a un utilisateur final.

Utilisation des services Web Offrir des cotations en “temps réel” (trafic routier, surveillance de centrales nucléaires). Rechercher des informations (base de connaissance, bibliothèque,...). Offrir des services propriétaires (Validation de cartes de crédits,...). ...

Vision des services Web dans l’avenir. Microsoft, SUN et IBM sont les principaux acteurs dans le monde des services web leur vision a plus ou moins court terme: Permettre un accès (pas forcement gratuit) a toute une quantité d’information. Faire de l’Internet non plus un outils final pour l’utilisateur mais un environnement hautement programmable.

Conclusion. Les services web sont amenés a prendre une part de plus en plus importante dans les applications futur, Microsoft a bien comprit que cette technologie est vouée a provoquer un important bouleversement sur la façon de concevoir le net. C’est principalement pour cette raison que le .net Framework et les web services sont en adéquation. Comme les services web ne sont pas la propriété de Microsoft celui-ci mise sur la simplicité de développement liée au .net Framework pour imposer son nouveau langage C# mais aussi sa plate-forme Visual Studio.

Conception d’un service Web Un service Web peut se définir de la façon suivante: Il s’exécute sur un serveur. Il expose des méthodes web sur le net. Il écoute les demandes http correspondant aux commandes permettant d’appeler les méthodes web. Il exécute les méthodes Web et retourne les résultats.

Description of providers Application discovery? Description of providers and services UDDI Category Provider WSDL Service Publication SOAP Transport SOAP Client XML Service Call Service Provider SOAP Transport Service HTTP/S

Appel des web services En règle générale les services Web attendent a ce que leurs méthodes soient appelées a l’aide d’une demande HTTP composées de messages SOAP. Les services web écrient avec le .net Framework peuvent aussi être dans certain cas appelées à l’aide des commandes HTTP GET et HTTP POST.

Communiquer avec SOAP Simple Object Access Protocol Services Web Communiquer avec SOAP Simple Object Access Protocol

Le protocole SOAP Le protocole SOAP est une spécification de communication entre les Web Services par échange de messages en XML. SOAP est indépendant des langages et des systèmes d’exploitations employé pour implémenter des services Web. SOAP est une recommandation du W3C http://www.w3.org/TR/SOAP

La spécification SOAP La spécification SOAP ce divise en 4 parties: L’enveloppe : Les règles de codage : Un protocole de RPC définissant la succession des requêtes et des réponses. La définition de l’utilisation de HTTP comme couche de transport des messages.

Structure des messages SOAP

Exemple d’appel de méthode POST /calc.asmx HTTP/1.1 Host: www.wintellect.com Content-Type: text/xml; charset=utf-8 Content-Length: 338 SOAPAction: http://tempsuri.org/Add <?xml version=“1.0” encoding=“utf-8”?> <soap:Envelope xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xmlns:xsd=http://www.w3.org/2001/XMLSchema xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/> <soap:Body> <Add xmlns=http://tempuri.org/> <a>2</a> <b>2</b> </Add> </soap:Body> </soap:Envelope>

Exemple de réponse HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: 353 <?xml version=“1.0” encoding=“utf-8”?> <soap:Envelope xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xmlns:xsd=http://www.w3.org/2001/XMLSchema xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/> <soap:Body> <AddResponse xmlns=http://tempuri.org/> <AddResult>4</AddResult> </AddResponse> </soap:Body> </soap:Envelope>

Fonctionnement Exemple de communication entre le client et le fournisseur du service web www.wintellect.com/calc.asmx appellant la méthode Add avec comme arguments 2 et 2. Le service web analyse l’enveloppe SOAP contenant les entrées et élabore l’enveloppe SOAP contenant le résultat et la retourne au client dans le corps de la réponse HTTP. La partie la plus complexe dans la gestion des services web consiste a analyser les demandes HTTP et a générer les réponses HTTP.

Avantage de l’utilisation du .net Framework Le Framework facilite l’écriture des services web car il prend en charge la gestion et l’analyse des messages HTTP, SOAP et XML. Les services web écrits avec le .net Framework constituent des applications managées.

Premier service Web Les services web sont implémentés dans des fichiers .asmx qui constituent une extension de nom de fichier enregistrée auprès du gestionnaire HTTP ASP.NET Les fichiers .asmx commencent par une directive @WebService et doivent comporter un attribut Class identifiant la classe composant le service Web. Les classes de services web peuvent comporter l’attribut WebService prennant en charge différents paramètres Les méthodes Web sont déclarées en complétant les méthodes publiques de la classe de service web avec l’attribut WebMethod, ceci permet d’exposer les méthodes en tant que méthodes web.

Tester le service web Pour tester le service web il suffit d’afficher la page .asmx dans le navigateur Le fichier .asmx doit se trouver dans un répertoire web virtuel pour être pris en charge par IIS.

Explications ASP.NET a répondu à la demande HTTP en générant une page html décrivant le service web. ASP.NET connaît le nom de la méthode et sa signature, car il les lit dans les Metadonnées de la DLL qu’il a compilée a partir du fichier .asmx. ASP.NET génère aussi un formulaire html pour tester les méthodes web mais celui-ci ne prend en compte que des requêtes HTTP Get et Post. Il ne peut donc tester que des services web utilisant des types de données primitifs.

Code behind Le code behind est utilise pour enregistrer les classes de services web dans des fichiers dll compilées offrant ainsi de meilleurs performances. Le fichier asmx ne contient donc plus qu’une seule instruction référençant la classe implémentée dans la dll. Pour obtenir la dll il faut compiler un fichier cs ou d’un autre langage supporté par le .net Framework. Utiliser du code behind permet d’écrire des services web avec n’importe quel langage du .net Framework. De plus les erreurs de compilation sont interceptées avant que le service ne soit déployé.

La classe WebService La classe WebService est la classe de base utilisée par Visual Studio lorsque l’on crée une application WebService. De même que la création d’une application WindowsForm utilise comme classe de base From. La classe WebService appartient a l’espace de noms System.Web.Services. Elle fournit aux classes dérives les propriétés Application, Session, Context, Server et User, grâce auxquelles un service Web accède aux objets ASP.NET de même noms. L’utilisation de la classe WebService n’est pas nécessaire si les fonctionnalistes ci-dessus ne sont pas désires.

Attribut WebMethod L’attribut WebMethod est utilise pour identifier une méthode en tant que méthode web. En plus de déclarer une méthode Web l’attribut WebMethod prend également en charge certains paramètres.

Parametres de WebMethod BufferResponse: Active et desactive la mise en memoire tampon de la reponse. CacheDuration: Place dans le cache les reponses generees par la methode, pendant le nombre de secondes specifie. Description: Ajoute une descriptiontextuelle a la methode Web. EnableSession: Active et desactive l’etat de session pour la methode Web. MessageName: Specifie le nom de la methode Web. TransactionOption: Definit le comportement transactionnel de la methode Web.

Exemple de création d’un web service

Consommation d’un Service Web par un client. Services Web Consommation d’un Service Web par un client.

Le langage WSDL Le langage WSDL est utilise pour decrire les webServices afin d’etre utilise correctement par les clients. Les fichiers WSDL decrivent les methodes web publiees par le service, les protocoles pris en charge, les signatures de ses methodes et l’emplacement (URL) du service. WSDL est un fichier XML, stantdard relativement nouveau concu par IBM, Microsoft, et autres, normalise par le w3c (http://www.3c.org/TR/wsdl ) Les fichiers WSDL sont generes par le .net framework et sont accesible via l’ajout de l’option wsdl dans la requete URL du service web. Ex: ttp://localhost/WSCalc.asmx?wsdl Le contrat WSDL est utilisee pour ecrire des clients pour le service web. Generalement les developpeurs ne lisent pas eux-memes les contrats mais utilisent l’outil Wsdl.exe, qui genere une classe wrapper contenant tous les elements requis.

Le type de donnees complexes Les types primitifs sont facilement exploitable car ils sont quasiment toujours representes de la meme facon (int, char, bool,...) Les types complexes sont en revanche diffilement exploitables de part leur nature non standard. La solution proposee par le .net framework consiste a serialiser les donnes de type complexe avec la classe System.Xml.Serialisation.XmlSerializer. Une application cliente recevant le code XML et possedant un schema qui decrit la structure et le contenu des donnees peut ‘rehydrater’ les informations en un objet. Les types de donnees complexes ne sont utilisees qu’avec le protocole SOAP.

Decouverte de service web: DISCO Une fois le contrat wsdl cree, le client dispose de toutes les informations necessaires pour dont il a besoin. Le probleme est s’il existe un service repondant a notre demande, de savoir ou trouver ce fichier wsdl. DISCO (discovery) permet d’optenir la liste des services web locaux sur le serveur. UDDI (Universal Description Discovery and Integration) constitue l’annuaire global des services web. Le protocole DISCO est tres simple et s’articule autour de fichier DISCO dont le contenu est au format XML.

<?xml version=“1.0”?> <discovery xmlns=http://schemas.xmlsoap.org/disco/ xmlns:scl=http://schemas.xmlsoap.org/disco/scl/> <scl:contractRef ref=http://www.wintellect.com/calc.asmx?wsdl docRef=http://www.wintellect.com/Calc.asmx/> <scl:contractRef ref=http://www.wintellect.com/locator.asmx?wsdl docRef=http://www.wintellect.com/Locator.asmx/> </discovery>

ContractRef: Identifie l’url du contrat wsdl. docRef: Attribut facultatif identifie l’emplacement du document decrivant le web service, generalement le fichier asmx du au caractere autodocumente. discoveryRef: utiliser pour referencer les fichiers disco.

Fichiers VSDISCO <?xml version=“1.0” ?> <dynamicDiscovery xmlns=“urn:schemas-dynamicdiscovery:disco.2000-03-17”> <exclude path=“_vti_cnf”/> <exclude path=“_vti_pvt”/> <exclude path=“_vti_log”/> <exclude path=“_vti_script”/> <exclude path=“_vti_txt”/> </dynamicDiscovery>

Lorsqu’un client demande un fichier vsdisco, le gestionnaire HTTP parcourt le repertoire hote et ses sous-repertoires a la recherche de fichiers ASMX et DISCO et retourne un document DISCO genere dynamiquement. Pour des raison de securite, la decouverte dynamique est desacitive. Pour la reactiver il suffit de decommenter la ligne de la section httpHandlers du fichier Machine.config L’activation des fichiers VSDISCO est fortement deconseille de la part meme de Microsoft. L’inconvenient majeur des fichiers disco est que pour lire un fichier disco il faut connaitre son URL. UDDI repond a ce probleme.

Decouverte de service web: UDDI La specification UDDI a ete developpe par IBM, Microsoft et Ariba. UDDI permet de creer des bases de donnees distribuees grace auxquelles chaque entreprise peut decouvrir et proposer des services web. Voir http://uddi.microsoft.com/default.aspx

Clients de services web Les clients de service web sont des applications qui vont utiliser le service, ces applications peuvent etre: Des applications ASPX. Des Windows Formulaires. Des applications Consoles ...

Le proxy Le concept de proxy est un concept essensiel pour les services web. Un proxy de service web fournit la representation locale d’un service Web distant. Les proxy servent de relais entre l’application locale et le service web distant. L’utilitaire Wsdl.exe sert a generer une classe proxy du service web a partir d’un contrat wsdl.

Creation d’un proxy Url du service web: Url du fichier wsdl: http://www.monsite.com/calc.asmx Url du fichier wsdl: http://www.monsite.com/calc.asmx?wsdl Ligne de commande generant le proxy: Wsdl http://www.monsite.com/calc.asmx?wsdl Si le service web n’a pas etait cree avec VS.net il faut indiquer a l’utilitaire wsdl l’emplacement du fichier wsdl decrivant le contrat du service web.

Wsdl.exe Wsdl.exe genere un fichier cs ou autre contenant la classe qui represente le proxy. Option de la ligne de commande wsdl.exe /baseurl:urlbase /d[omaine]:domaine /l[anguage]:langage /n[amespace]:espace de noms /o[ou]:nom du fichier /proxy:URL

Client Webform

Client WinForm

Sécurité et configuration Services Web Sécurité et configuration

Configuration et securite d’un service Web Les fichiers de configuration .config sont des fichiers XML que l’on utilise pour parametrer les applications sans avoir a les recompiler. Plusieurs fichiers de configurations peuvent exister dans differents dossiers. Les parametres de configurations sont automatiquement recalcules et mis en cache si des modifications sont faites a un fichier Web.config. Les fichiers Web.config sont extensible. Le serveur Web empeche l’acces direct aux fichiers Web.config. (erreur 403).

Parametres de l’application AppSettings definit les valeurs propres a l’application. Utilise la balise <appSettings> dans le fichier Web.config, cette balise doit etre declaree dans la balise <configuration>. AppSettings permet de modifier le comportement de l’application sans avoir a changer la moindre ligne de code ni avoir a recompiler l’application.

Exemple d’utilisation Fichier Web.config <cofiguration> <appSettings> <add key=“MyConnectionString” value=“server=hawkeye;database=pubs;uid=sa;pwd=“/> </appSettings> <configuration> Fichier.cs String conn = ConfigurationSettings.AppSettings[“MyConnectionString”]; SqlDataAdapter adapter = new SqlDataAdapter (“select * from titles where price !=0”, conn); DataSet ds = new DataSet(); Adapter.Fill (ds); ...

Services Web Techniques avancées

Creation de methodes asynchrones La programmation asynchrone permet a un programme d’appeler une methode web et de poursuivre son traitement sans attendre le retour de la methode. La programmation asynchrone peut etre implementee a l’aide des options suivantes: Rappels: On fournit un delegue de rappel a l’appel de la methode asynchrone. Interrogation terminee: On interroge regulierement la propriete IAsyncResult.IsCompleted de la methode asynchrone pour savoir si le traitement est termine. BeginInvoke, WaitHandle, EndInvoke: bloque l’execution du client jusqu’a ce que l’execution de la methode se termine. Utilisee avec WaitHandle le client execute des operations en attente de la fin de traitement.

Exemple de méthode asynchrone

Extensions SOAP Les extensions SOAP permettent d’acceder aux messages SOAP que les services web adressent aux clients ou recoivent d’eux, et de les modifier. Permet de valider le contenu d’un message SOAP avant de le passer au service web. Permet aussi d’integrer des methodes de cryptages ou de compressions.

Methode Creer une classe qui herite de la classe SoapExtension. Enregistrer une reference a la classe Stream qui represente les futurs messages SOAP. Initialiser les donnees propres a l’extension SOAP. Traiter les messages SOAP pendant les etapes SoapMessageStage appropriees. Configurer l’extension SOAP pour l’executer avec des methodes specifiques du sevice web.

La sérialisation

La sérialisation La sérialisation désigne le processus par lequel les objets ou les valeurs sont convertis dans un format a même d’être conservé ou transporté. La désérialisation constitue l’étape inverse qui permet de reconstruire un objet a partir de ses données sérialisées. Le .net Framework prend en charge deux types de sérialisation: La sérialisation binaire. La sérialisation XML.

Les applications pour lesquelles les performances présentent un caractère crucial recourent au codage Binaire. Dans le cas où l’interopérabilité avec les autres systèmes distants est essentielle, le codage XML s’impose. La sérialisation XML est le processus utilisé par ASP.NET pour créer les flux XML transmettant les données entre les applications et les services web.

Code d’une classe sérialisable [Serializable()] Public class MyClassSerializable { public int i; public string st; }

Remarques sur les classes sérialisables Pour définir une classe comme étant sérialisable il faut lui ajouter l’attribut [Serializable()] ou <Serializable()> en vb. L’attribut Serializable n’est pas héritable.

Code sérialisant une classe Using System; Using System.IO; Using System.Runtime.Serialization.Formatters.Binary; Public class ClasseSerialisante { static void Main(string[] args) MyClassSerializable obj = new MyClassSerializable(); obj.i = 10; obj.st =“coucou”; FileStream stream = new FileStream(“MyFile.dat”,FileMode.Create); BinaryFormatter format = new BinaryFormatter(); format.Serialize(stream, obj); }

Architecture d’accès à distance Net remoting

Le client utilise une référence à l’objet serveur pour accéder à l’objet distant. Cet appel recourt à des objets proxy pour autoriser l’utilisation de l’objet distant dans le processus client. C’est par l’intermédiaire du proxy que le client appel les méthodes et propriétés de l’objet distant.

Principe de fonctionnement

Tâches de bas niveaux Programmation réseaux. Ouverture de la connexion. Mise en forme des messages. Écriture des messages dans le flux. Connaissance des protocoles (TCP/IP, HTTP). Spécifications des formats de sérialisation.

Ces tâches de bas niveaux sont effectuées par le Framework. Cette association de technologies est appelé Canal de transport

Accessibilité des objets distants Une application distribuées peut contenir: Des objets accessibles à distances (utilisable hors de leur domaine d’application). Des objets non accessibles à distances (utilisable uniquement dans leur domaine d’application).

Objets accessibles à distance Les objets accessibles à distance sont: Soit accessible à l’extérieur de leur domaine d’application (par référence). Soit copiés et passés à l’extérieur de leur domaine d’application (par valeur). Seul les objets Marshalés par référence ont besoin d’un proxy pour accéder à distance à l’objet.

Activation distante des objets Lors du développement d’un objet distant il est important de suivre sa création et son initialisation ainsi que sa durée de vie. Le comportement de l’objet dépend de la façon dont il a été activé. Il existe 2 types d’activations possible: Activation serveur. Activation client.

Activation Serveur Dans l’activation serveur, les objets sur le serveurs sont créés lors de l’appel d’une méthode. Les objets ne sont pas créés au moment de la déclaration d’une instance avec ‘new’. Un objet activé par le serveur peut être créé en tant que ‘Singleton’ ou ‘SingleCall’

Objet ‘Singleton’ Il n’existe qu’une seule instance de l’objet. Cette instance gère l’ensemble des clients. Ces objets possèdent une durée de vie par défaut.

Objet ‘SingleCall’ Le système d’accès distant crée un objet pour chaque méthode cliente appelant l’objet distant.

Activation Client Les objets sont créés sur le serveur à l’appel de ‘new’. Le domaine d’application du client définit les durées de vie des objets activés par le client. Chaque instance activée par le client est référencé par son propre ‘bail’ coté serveur. A l’inverse du modèle COM, l’activation client permet de contrôler la durée de vie de l’objet serveur sans gérer des références ou de procéder d’interrogation.

Attention à l’utilisation des durées de vies illimitée. Possibilité de fournir des arguments au constructeur. Le serveur créé une instance par client. Attention à l’utilisation des durées de vies illimitée.

Utilisation du fichier .config S’utilise de la façon suivante: RemotingConfiguration.Configure("configuration.config"); Permet de distribuer les applications puis de faire évoluer la configuration. Pas de recompilation nécessaire. Le fichier .config est un fichier xml.

Gestion de la durée de vie Pas de durée de vie pour les objets serveur SingleCall. InitialLeaseTime: 5min par défaut, durée de vie de l’objet après activation. RenewOnCallTime: 2min par défaut, durée de vie minimum entre 2 appel de méthodes. CurrentLeaseTime: Durée restante avant que l’objet ne soit détruit, s’il ne reçoit pas un appel de méthode.

Pour modifier le Lease d’un objet il faut surcharger la méthode InitializeLifetimeService de notre objet MarchalByRef. Pour avoir une durée de vie infinie la méthode InitializeLifetimeService doit retourner la valeur null.

Utilisation d’interfaces L’utilisation d’une interface permet de ne stocker chez le client qu’une description des classes auxquelles il a accès. Les interfaces permettent aussi de pouvoir mettre à jour le code de l’objet publié, sans toucher aux clients.

Syntaxe d’utilisation des interfaces Objet activé coté serveur: IRemotableClass ir = (IRemotableClass)Activator.GetObject(typeof(IRemotableClass), »tcp:://localhost:1881/RemotableClass »); Objet activé côté client: Object[] url = {new UrlAttribute(« tcp://localhost:1881 »)}; IRemotableClass ir = (IremotableClasse)Activator.CreateInstance(typeof(RemotableClass), null, url);

Passer un objet par valeur

Appel asynchrone à un objet distant