Introduction aux. services web 2 / 2

Transcription

1 Introduction aux services web 2 / 2 1

2 Calendrier 2 x CM A 107 mercredi 7 janvier 2015, 08 h h 00 : introduction sur la théorie des services web mercredi 28 janvier 2015, 08 h h 00 : introduction aux services web Microsoft 2 x TD A 107 mercredi 14 janvier 2015, 08 h h 00 : préparation du TP 1 et du TP 2 mercredi 4 février 2015, 08 h h 00 : préparation du TP 2 et du TP 3 3 x TP GR 18 (effectif réparti en deux groupes) jeudi 22 janvier 2015 : consommation de services web existants 08 h h 00 : groupe B 10 h h 00 : groupe A jeudi 12 février 2015 : création de services web Microsoft (1 / 2) 08 h h 00 : groupe A 10 h h 00 : groupe B jeudi 19 février 2015 : création de services web Microsoft (2 / 2) 08 h h 00 : groupe B 10 h h 00 : groupe A

3 Plan 1 er CM Vision théorique des services web 2 e CM Vision pratique des services web selon les outils proposés par Microsoft

4 Les standards WS-*

5 Les standards WS-* Dès la fin de la spécification de WSDL/SOAP/UDDI, leurs initiateurs avaient bien conscience de leur limites De par la volonté de consensus, la norme englobe finalement peu de choses (pas de sécurité, pas de souscriptions ) Tous les acteurs ont donc depuis le début des années 2000 ajouté des spécifications, dont certaines sont devenues des recommandations du W3C Lorsque vous entendez parler de web services WS-*, on parle donc de web services plus évolués que du simple WSDL/SOAP/UDDI

6 Les standards WS-* WS-Addressing Rajouter des informations de routage sur des messages SOAP Dans WSDL de base, la réponse à l appel se fait sur le channel HTTP déjà ouvert. Avec WS-A, il est possible de répondre sur un autre. (Asynchronicité) WS-Discovery Réaliser des multicasts sur un réseau pour découvrir les web services présents Exemple d implémentation dans Windows Vista/7 avec PNM (People Near Me)

7 Les standards WS-* WS-Management Normer l utilisation de SOAP pour des tâches d administration de serveurs, de logiciels Exemple d implémentation dans WinRM WS-Eventing Proposer une norme de souscription à un Web Service WS-Policy Définir des règles dans le WSDL en ce qui concerne la qualité de service, les certificats

8 Les standards WS-* WS-Transaction Ajouter à SOAP des informations nécessaires à l ouverture de transactions (ACID) WS-ReliableMessaging Définir les fonctionnalités nécessaires à SOAP et WSDL pour réaliser des solutions de messaging avec des web services

9 Les standards WS-* WS-Security Normer le cryptage, la signature de messages SOAP (hors utilisation de HTTPS, déjà supporté en natif) et l ajout de tokens de sécurité (Kerberos, SAML ) WS-Trust Normer le renouvellement des tokens de WS-Security et les services dédiés à cela WS-Federation Étendre l utilisation de WS-Security à une multitude de web services dans un environnement SOA Fourniture de contexte SSO

10 Les standards WS-* MTOM pour SOAP Message Transmission Optimization Mecanism est une optimisation de SOAP pour ne pas sérialiser en XML les données binaires éventuellement transmises La sérialisation texte d une donnée binaire est usuellement réalisée en Base64 Encoding, qui encode 3 octets en 4 caractères Base64 encode en effet 24 bits (3 octets) en les séparant en 4 blocs de 6 bits (64 valeurs décimales) et en leur affectant un caractère parmi {A-Za-z0-9+/}

11 Les standards WS-* Ces standards sont très nombreux, plus ou moins matures et peu supportés pour certains Liste non exhaustive : Heureusement une norme d interopérabilité a été établie pour déterminer lesquels de ces standards sont implémentés par les parties en présence

12 Interopérabilité Les niveaux d interopérabilité sont normés dans WS-I Basic Profile Une spécification du WS-I Consortium Il y en a eu historiquement 3 grandes versions 2006: WS-I Basic Profile 1.1 (SOAP 1.1, WSDL 1.1, UDDI 2.0) 2010: WS-I Basic Profile 1.2 (Standards WS-*: Ajout de MTOM, WS-Addressing ) 2010: WS-I Basic Profile 2.0 (Passage à SOAP 1.2 et UDDI 3) La 1.1 est encore la plus répandue à ce jour

13 Infrastructure Client/Serveur

14 Côté client Le client génère un stub ou classe proxy avec un outil à partir de WSDL Ce stub masque la complexité de deux parties Le sérialiseur/désérialiseur SOAP L encapsuleur de requêtes HTTP

15 En pratique en.net Pour utiliser un Web Service on ajoute une Web Reference dans Visual Studio, en fournissant l URL du WSDL. Cela génère un stub ou classe proxy, que l on peut appeler comme toute autre classe Elle transmettra les appels et retours SOAP de manière transparente

16 Côté serveur C est un peu plus complexe car si la partie sérialisation et encapsulation reste, il faut aussi un listener HTTP, et l implémentation du service Le retour est symétrique

17 En pratique en.net Dans la plupart des langages, développer un web service est ceci dit aisé Plus question de taper le WSDL et le SOAP à la main Depuis.NET 2.0 par exemple il suffit de déclarer une classe comme fille de WebService, et de déclarer les méthodes exposées comme [WebMethod] public class CalcService : System.Web.Services.WebService { } [WebMethod] public int Add(int x, int y) { } return x + y; Puis de déployer la librairie compilée et un fichier d appel (anciennement.asmx, puis.svc) dans un serveur web (IIS ou Cassini)

18 Démo / Rappel Web Services «Simples»

19 Windows Communication Foundation

20 La notion de contrat Objectifs Permet d exprimer sous la forme de contrats la coopération entre les fournisseurs et les utilisateurs de services Sépare l interface de l implantation des objets Masque les divers problèmes liés à l interopérabilité : Hétérogénéité Localisation Un contrat spécifie les types manipulés par un ensemble d applications réparties : Les types d objets (ou interfaces) Les types de données échangés entre les objets Le contrat : Isole les clients et fournisseurs de l infrastructure logicielle et matérielle Les met en relation à travers le bus On remarque une analogie à ce qui a pu être vu avec CORBA (IDL)

21 Windows Communication Foundation WCF a pour but d unifier le développement de services autour d un modèle unifié Un service dans WCF est défini par trois composants, désignés par les lettres A, B et C A comme Address l URL du service B comme Binding ou comment on communique avec le service (protocole ) C comme Contract ce qu expose le service

22 Windows Communication Foundation Ce principe sépare la notion de contrat de service (dont le principe est partagé par toutes les technologies) de son hébergement

23 Windows Communication Foundation Dans l ordre on commence déjà par définir le contrat Deux classes dans WCF, les ServiceContract et les DataContract Le service et ses données complexes On définit donc notre classe de données [DataContract] public class Etudiant { } [DataMember] public string Nom

24 Windows Communication Foundation Et notre contrat de service [ServiceContract] public interface IGestionEtudiantsService { [OperationContract] public List<Etudiant> ListerEtudiants(); } Qui doit être implémenté par une classe (interface) public class GestionEtudiantsImpl:IGestionEtudiantsService { } public List<Etudiant> ListerEtudiants() { }

25 Windows Communication Foundation Address et Binding sont spécifiés dans le fichier de configuration du service (app.config ou web.config) <system.servicemodel> <services> <service name="mynamespace.myservice"> <endpoint address="myservice" binding="basichttpbinding" contract="mynamespace.iservice" /> <host> <baseaddresses> <baseaddress baseaddress=" /> </baseaddresses> </host> </service> </services> </system.servicemodel>

26 Windows Communication Foundation Les bindings peuvent être de différents types, pour couvrir les service abordés plus hauts HTTP TCP et Named Pipes MSMQ Chaque binding peut être configuré avec des bindingconfiguration pour s adapter à tous les scénarii ComNonTransactionalBinding pour les services COM par exemple

27 Bindings disponibles

28 Windows Communication Foundation Dès lors hébergement du service peut se réaliser: Dans une application de son choix (self hosted) dont une classe étend ServiceBase et définit OnStart() et OnStop() Dans Windows Activation Service (WAS) un service Windows dédié Dans les deux cas précédents, le nombre de protocoles est élevé (HTTP, TCP, Named Pipes ) et extensible Mais ce ne sont pas ceux qui nous intéressent

29 Windows Communication Foundation La dernière option (traditionnelle avant WCF) est l hébergement dans IIS (Internet Information Services) Le serveur Web de Microsoft Ce qui limite bien sûr au protocole HTTP Il suffit de déployer dans IIS la DLL de notre service, avec un fichier.svc qui comprend généralement une seule ligne: language="c#" Service="MyNameSpace.MyService" %>

30 Windows Communication Foundation IIS permet d utiliser les différents bindings HTTP disponibles BasicHttpBinding : le plus répandu, Basic Profile 1.1, recommandé pour les scénarii d interopérabilité WsHttpBinding : prise en charge des technologies WS-* (transactionnel, messaging avec A/R, WS-Addressing ) WsDualHttpBinding : idem qu au dessus avec ACK WsFederationHttpBinding : sécurité fédérée entre différents services (WS-Federation) BasicHttpBinding est de loin le plus utilisé Le choix du type de binding dépend de l utilisation faite et des systèmes concernés:

31 Personnalisation des Services Microsoft Démo

32 Publication sur IIS depuis VS20xx Procédure : Se rendre dans l outil de gestion de sites web IIS Créer un nouveau dossier virtuel Ouvrir le service web dans Visual Studio Dans les paramètres du projet, onglet serveur web : choisir IIS local au lieu de IIS Express Préciser dans l URL cible le dossier virtuel créé dans IIS Appuyer sur <F5>

33 Personnalisation du Service IIS Démo

34 Exemple de Client JAVA

35 Création d un client Java Procédure de création Créer un nouveau projet Java avec l EDI NetBeans, par exemple Créer un nouveau fichier de la catégorie Web Services / Web Service Client Préciser la localisation du fichier WSDL

36 Création d un client Java Procédure de création Interface d exploitation sous NetBeans

37 Exemple de Client JAVA Démo

38 Services Web Microsoft Avantages Intégrité, cohérence et homogénéité (qualité) Productivité assurée Interopérabilité assurée de facto Inconvénients (leitmotiv) Outils commerciaux Environnement «fermé» même si des efforts d ouverture sont en cours Outils spécifiques nécessaires pour la création et le déploiement même si des efforts d ouverture sont également en cours

39 Nouvelles architectures (1 / 3) REpresentational State Transfer (REST) C est un «style d architecture» orienté ressource, pas une technologie! Repose sur le protocole standard HTTP Ressource : Décrite par une URI (Uniform Resource Identifier) originale Identifiée par un identificateur de ressource Support natif de la lecture par GET, l écriture par POST, la mise à jour par PUT et la suppression par DELETE Équivalent Microsoft : Production également possible par WCF, le.net Framework 4 et Microsoft Unified Communications Web API (utilisable conjointement de Microsoft LINQ, Language INtegrated Query) Disponible en pré-packagé sur Microsoft Azure Sécurité assurée par OAuth

40 Nouvelles architectures (2 / 3) REpresentational State Transfer (REST) Avantages Facile à mettre en œuvre d une façon générale : aucun outil nécessaire «Léger» : pas de contenu verbeux en XML (par rapport à l utilisation de WSDL et SOAP) => moins consommateur de bande passante Contenus lisibles (compréhensibles) à la fois par les êtres humains et les machines => consommation simplifiée Support du cache Sécurité assurée par HTTP Inconvénients : Création du service «plus complexe» de par le fait que l on n utilise pas d outils «générateurs automatiques» côté serveur Notion de contrat non supportée (à gérer soit-même) Sécurité assurée par HTTP Résumé : «-1» pour SOAP côté client : «difficile» à consommer «-1» pour REST côté serveur : «difficile» à implémenter

41 Nouvelles architectures (3 / 3) Services Web Sémantiques Basés sur les outils du web sémantique Utilisation de ressources décrites au format RDF (Resource Description Framework), OWL (Web Ontology Language) Stockage des données sous forme de «triplets» Sujet Prédicat Objet/Valeur Opérations sur les ressources exposées : création, modification suppression Traitement sur les données : SPARQL (SPARQL Protocol and RDF Query Language)

42 Exemples de services web Côté serveur : Application serveur Exposition du service : Microsoft Internet Information Services (IIS), Apache HTTPD, Apache Tomcat, Sun/Oracle GlassFish Langage : C#, C/C++, ASP, JAVA, PHP, Python, XML, JSON, Côté client : Application client ou serveur, web ou native Langage : C#, C/C++, ASP, JAVA, PHP, Python, HTML/JavaScript, Applications et technologies complètement interopérables si les spécifications «service web» sont respectées

43 Exemples de services web Sources de données INSPIRE (Application CArGOS) Infrastructure d'information géographique dans la Communauté européenne Consultation de données publiques en Europe Bases de données interopérables via une API web (GetCapabilities, GetMap,...) Données géoréférencées Différents protocoles d échange : Description des données et services : CSW (Catalog Service for the Web) Consultation et affichage de cartes : Web Map Service (WMS) Web Map Tile Service (WMTS) Téléchargement de données Raster : Web Coverage Service (WMS) Vectorielles : Web Feature Service (WFS) Données publiques :

44 Exemples de services web Météo France Plusieurs API web accessibles avec ou sans redevance (selon la nature des services) Utilisation du service au moyen d une clef Échange de données : Animations satellites, Modèles et données de prévision Observations radar, satellite Bulletins climatologiques, à différentes fréquences Ensemble de fonctionnalités permettant une simplification des tâches de gestion côté vendeur Données publiques :

45 Exemples de services web Amazon Web Services (AWS) Contrat client établi selon les options choisies Plusieurs API web gratuites ou payantes Utilisation du service au moyen d une clef Échange de données : Produits : catalogues, prix, description, stocks Marketting : inventaires, commandes, paiements Ensemble de fonctionnalités permettant une simplification des tâches de gestion côté vendeur Plus de détails :

46 Conclusion

47 Conclusion Les web services sont un indéniable succès depuis 10 ans et leur facilité d utilisation croît au fil du temps Les normes pour définir les bases d une véritable architecture SOA à base de web services sont en constante évolution Microsoft a choisi d unifier tous ses middlewares orientés service dans l unique Windows Communication Foundation (WCF)

48 Conclusion Ce que l on retient de l ensemble Cours/TD/TP Architectures des services web Création de services web avec les outils Microsoft et la suite Visual Studio avec ou sans WCF Publication de services web au sein du serveur web intégré à Visual Studio ou IIS local Consommation de services web depuis un client Windows (ou web) en C# Consommation de services web depuis des applications écrites dans d autres langages (JAVA pour l exemple)