Introduction
L’informatique évolue, nous pouvons observer à l’heure d’aujourd’hui des bouleversements dans le monde des technologies nouvelles. Les utilisateurs interagissent de plus en plus avec des appareils mobiles comme des Smartphones ou des tablettes, ce qui nous impose une adaptation à leur besoin.
Notre monde n’est pas un univers d’Herbrand, chaque matériel est construit par un constructeur différent, utilisant des technologies différentes et des méthodes différentes.
Prenons l’exemple du constructeur Samsung, celui-ci offre des Smartphones et tablettes équipé du système Androïd ce qui impose aux développeurs une conception en langage Java. Alors que chez Apple, on préfère utiliser un système propriétaire « iOS » et là encore le développeur doit se plier au système et développer ses applications en objective-c.
Le développement d’application dans des langages différents est donc un frein pour les communications inter-application, chaque langage à ses avantages et ses inconvénients et c’est aux équipes de développement que revient la tâche de décision de l’utilisation ou non d’un langage.
Il a donc fallu trouver une solution afin de permettre des communications à distance entre application, sans pour autant devoir recréer une même application en différent langage.
C’est ici que les technologies de Web Services entre en jeu ! De par leurs fonctionnement, celle-ci permettent de faire abstraction du langage et donc de pouvoir transmettre des informations entre applications facilement.
Afin de bien comprendre le concept de Web Service, je vous présenterai les différentes technologies et plateforme employées pour créer des Web Services, la procédure d’utilisation d’un Web Service ainsi que la réalisation et l’implémentation d’un Web Service grâce au framework Apache CFX.
Chapitre 1. Les technologies de Web Services
I. Définition du Web Service
Un Web Service est un moyen ou un programme permettant de distribuer l’information entre un client et un serveur. Celui-ci étant basé sur les standard du Web telles que HTTP et XML, il permet d’obtenir des applications faiblement couplées, ce qui signifie qu’il fait abstraction du langage et de la plateforme employés pour communiquer. Cela facilite grandement le développement d’applications réparties.
La technologie de Web Service repose essentiellement sur le langage XML qui permet d’avoir une représentation standard des données.
II. Les technologies Utilisées dans les services Web
1) Le protocole HTTP
Le protocole HTTP « Hyper Text Transfert Protocol » est un ensemble de règles régissant la demande et l’envoi d’information entre un client et un serveur, celui-ci fonctionne sur le principe d’émetteur/récepteur. Le client émet une requête vers un serveur qui lui retourne alors une réponse au client.
Le protocole HTTP délègue la transmission d’information au protocole TCP.
2) Le langage XML
XML ou plus précisément « eXtended Markup Language » est un langage de balisage extensible, cela signifie que c’est un langage de balise comme le langage HTML mais qu’à l’inverse de celui-ci nous pouvons créer nos propres balises !
XML ne fait rien tout seul, celui-ci doit être couplé à d’autres technologies pour fonctionner, si on exécute un fichier XML dans un navigateur ou un éditeur, seul le code XML sera afficher, ce qui a peu d’intérêt.
Voici un listing des différentes technologies : DTD, XSLT, FO, XQuery, DOM, JDOM, SAX, XLink, XPath, XForm, RDF, XSQL.
On retrouvera bien entendu parmi ces technologies SOAP, WSDL, WSDD et UDDI afin de pouvoir créer et utiliser des services Web.
L’XML a été créé et Standardisé par l’organisme W3C « World Wide Web Consortium », cela veut dire que pour qu’un document soit construit de la meilleure qualité possible, celui-ci doit respecter les règles de bonnes pratiques édifiées par cet organisme.
Dans le cas des Web Services, le XML intervient au niveau de leur description grâce au WSDL permettant leur description.
De plus le langage XML a été choisi pour sa simplicité, en effet le XML est un métalangage permettant de créer ses propres balises et étant indépendant des plateformes, ce qui le rend portable.
Le langage XML est donc largement utilisé pour les échanges inter-applications.
3) Le protocole SOAP
Le protocole SOAP, anciennement connu sous l’acronyme « Simple Object Access Protocol » est un protocole de transmission de message entre machine via le protocole HTTP. Celui-ci étant basé sur l’XML, il permet d’accéder aux services web mais aussi d’obtenir une interopérabilité entre les applications.
Celui-ci repose sur les standards édifiés par le W3C telles que l’XML et le protocole HTTP. Cela permet donc de le rendre portable et donc indépendant de tous système d’exploitation et langage de programmation.
Les applications communiquent entre elles grâce aux RPC (Remote Procedure Call) selon un fonctionnement requête / réponse. La problématique des RPC reste à l’heure actuelle celle de la sécurité et de la compatibilité entre les firewalls et les proxys, SOAP viens donc palier cette problématique en créant une enveloppe afin d’envoyer le message à travers le protocole HTTP.
Voici une présentation des messages SOAP :
Squelette de l’enveloppe SOAP :
<soap:Envelope
xmlns:soap=http://www.w3.org/2001/12/soap-envelope
soap:encodingStyle=http://www.w3.org/2001/12/soap-encoding>
<soap:Header>
…
</soap:Header>
<soap:Body>
<soap:Fault>
…
</soap:Fault>
</soap:Body>
</soap:Envelope>
Le document décrivant le message est appelé une enveloppe SOAP, celle-ci est donc composée de deux parties :
- L’en-tête(Header) : Celle-ci contient les informations spécifiques à l’application comme l’authentification par exemple.
- Le corps (Body) : Il contient les données transportées par le message, notamment le nom de la méthode et les paramètres donnés lors de la requête. Il contiendra de plus l’appel de la méthode demandée et son résultat ou éventuellement un message d’erreur en cas d’échec.
1) Le langage de description WSDL
WSDL (Web Services Description Language) est une grammaire XML permettant de décrire l’interface d’un service web afin de le rendre générique. Cela signifie qu’il permet d’obtenir une indépendance au niveau de la plateforme et du langage.
Les fichiers WSDL sont indispensables au déploiement des Web Services, on distingue par ailleurs deux types de documents WSDL. Le premier sert à décrire l’implémentation du service et le second son interface. Le client récupère l’URL du fichier WSDL décrivant l’implémentation du service qui lui-même référence le document WSDL décrivant le service.
Remarque : Les documents WSDL sont générés par des outils de développement favorisant l’intégration rapide du Web Service.
2) L’annuaire de service UDDI
UDDI (Universal Description Discovery and Integration) est l’annuaire de référencement des Web Services. Afin que nous puissions découvrir un Web Service, celui-ci doit être publié. UDDI est l’annuaire permettant de publier un document WSDL afin qu’une application cliente puisse découvrir un Web Service et le consommer.
3) L’architecture de service Web REST
REST (Representational State Transfer) est une bibliothèque permettant de mettre en place une architecture accès essentiellement sur le protocole HTTP à l’instar de SOAP ou XML-RPC.
On peut considérer reste comme une méthode regroupant un ensemble de bonnes pratiques pour la création et le déploiement de Web Services.
Avec l’architecture REST chaque URI permet d’accéder à une ressource précise ce qui permet d’obtenir une meilleur clarté de nommage. De plus les services sont sans états ce qui permet au système de minimiser ses ressources.
En revanche le fait de retirer les états des services, retire la possibilité de mettre en place des sessions, de plus les requêtes vers le serveur devrons contenir toute les informations nécessaires à leur traitement.
III. Le fonctionnement des Web Services
Les Web services découlent du protocole SOAP, celui-ci intervient du côté du client et du serveur.
Au niveau du client celui-ci ouvre une connexion HTTP afin d’émettre une requête vers le serveur. Cette requête SOAP est un document XML décrivant la méthode à invoquer sur la machine distante.
Au niveau du serveur, SOAP permet de récupérer la requête et donc d’exécuter la méthode appelé par l’application cliente, puis il renvoie une réponse SOAP au client.
Rôle de SOAP :
A – Découverte
B – Description
C – Interaction
Principes de fonctionnement des Web Services :
1 – Le fournisseur de services publie un web service dans l’annuaire UDDI
2 – Le client interroge le diffuseur de services UDDI qui recherche le service demandé par le client et récupère les caractéristiques du service et lui transmets les informations (réponse à la demande du client)
3 – Le client effectue ensuite sa demande de service au fournisseur et lui envoie un document XML formaté selon les caractéristiques du service récupérer.
4 – Le fournisseur (serveur) exécute la requête et retourne la réponse à celle-ci.
Chapitre 2. Les plateformes de Web Services
Comme souvent en programmation il est intéressant de faire « un tour d’horizon » des solutions existantes, cela permet de prendre de meilleures décisions concernant le choix des technologies à utilisées pour les projets de développement. Cela devient d’autant plus vrai lorsque l’on parle de Web Services, ce domaine et très vaste et il existe plusieurs façon d’implémenter SOAP.
Le précurseur de l’implémentation des Web Services est IBM, en effet celui-ci a travaillé sur le développement des spécifications des technologies de services web, ce qui l’a amené à la création des packages SOAP4J, WSDK4J et UDDI4J.
Puis l’organisation Apache a repris le concept afin de la faire évoluer en Apache SOAP4J qui est devenu l’implémentation SOAP de référence aujourd’hui.
Découvrons à présent quelques unes des plateformes existantes !
I. Apache Axis
Axis (Apache eXtensible Interaction System) est à la fois un environnement d’hébergement de Web Services ainsi qu’un outil facilitant les créations et découvertes de Web Services.
Axis supporte plusieurs couches de transport comme HTTP, FTP, POP, SMTP, etc…
Il permet de convertir des POJO en données SOAP afin de les envoyer ou les recevoir, de plus il automatise la sérialisation et désérialisation d’objets Java pour les messages SOAP.
Il offre en plus des outils permettant de générer automatiquement le fichier de description WSDL permettant d’obtenir les renseignements nécessaire à l’accès de méthodes distantes. Ainsi que des outils permettant de déployer et tester les Services Web.
La dernière version connue du projet Axis est la version Axis2. Ce projet n’étant pas la priorité de la société Apache Software Foundation, la dernier release datant du 17 Avril 2012 a été laissée à l’abandon au profit du projet CXF.
Site : axis.apache.org
II. Apache CXF
Apache CXF est un Framework open source permettant de créer, diffuser et consommer des web services grâce à des API comme JAX-WS (utilisé pour la génération de fichier XML : sérialisation / désérialisation). CXF travail directement avec les protocoles SOAP et HTTP, de plus celui-ci est compatible avec les Framework CORBA et RESTful.
CXF respect les normes standards de services web tels que SOAP, WSDL, WS-Addressing, WS-Policy, WS-ReliableMessaging, WS-Security, WS-SecurityPolicy, WS-SecureConverstation, et WS-Trust.
Afin d’être compatible avec les architecture REST celui-ci implémenté l’API JAX-RS.
L’intérêt de CXF est qu’il permet de déployer simplement un Web Service, il suffit d’ajouter les annotations @WebService ainsi que @WebMethod puis exécuté l’outil wgen fournit avec le JDK pour générer les artefacts nécessaire à la création de Web Service.
Ce qui lui permet d’être à la fois extensible, performant, intuitif et facile d’utilisation.
Voici une liste non exhaustive tiré du site « cfx.apache.org » des caractéristiques incluses dans Apache CFX
Transports, plusieurs liaisons de protocole, liaisons de données et les formats
- Transports: HTTP, Servlet, JMS, SMTP / POP3, TCP et Jabber
- Fixations de protocole: SOAP, REST / HTTP, XML pur
- Les liaisons de données: JAXB 2.x, Aegis, XMLBeans Apache, Service Data Objects (SDO)
- Formats: XML textuels, JSON
Déploiement flexible
- Conteneurs légers: déployer des services dans Jetty, Tomcat
- L’intégration Java EE: déployer des services dans les serveurs d’application Java EE tels que Apache Geronimo, JOnAS, JBoss de Redhat, OC4J, Oracle WebLogic, et IBM WebSphere
Support de plusieurs langages de programmation
- Prise en charge complète pour le modèle de programmation client / serveur JAX-WS 2.x
- JAX-WS 2.x synchrones, asynchrones et unidirectionnels API
- JAX-WS 2.x Dynamic Invocation Interface (DII) API
- JAX-RS pour les clients RESTful
- Soutien aux styles enveloppés et non enveloppés
- XML API de messagerie
- Support pour JavaScript et ECMAScript 4 XML (E4X) – à la fois client et serveur
- Support pour CORBA
- Support pour JBI avec ServiceMix
III. IBM WebSphere
IBM WebSphere est un outil de développement d’IBM conçu selon le modèle SOA Service-Oriented Architecture pour les plateformes distribuées. Il contient un ensemble d’outils accélérant le processus de développement et facilitant le déploiement de Java / J2EE.
Optimisé pour les architectures MiddleWare, celui-ci inclut des outils de tests et d’analyses d’application afin d’améliorer la qualité, la sécurité et les performances des applications web.
IBM WebSphere est un outil propriétaire, celui-ci est donc sous licence commerciale.
IV. Sun Metro
Sun Métro est un outil de développement open source développé par la société Sun Microsystème. Celui-ci intégré la norme JAXB 2.x Web Service qui correspond à la norme de liaison de données et JAX-WS. Celui-ci est connu pour ses capacités à haute performances, son extensibilité ainsi que sa facilité d’implémentation.
Sun Métro fait partie de la communauté GlassFish il a donc été conçu pour fonctionner de façon optimale sur un serveur d’application GlassFish et être facile d’implémentation pour les développeurs utilisant NetBeans, bien qu’il soit possible de l’intégrer dans d’autres projet de Web Services.
V. NuSOAP
NuSOAP est une libraire comportant un ensemble de classe PHP permettant de générer des Web Services, cette librairie s’utilise en PHP.
Cette libraire est une évolution de SOAPX4 fournie par l’organisation NuSphere, elle est basées sur SOAP 1.1, WDSL 1.1, HTTP 1.1 et supporte le protocole RPC (Remote Procedure Call).
Elle permet donc de générer le fichier WSDL nécessaire description du service et d’interroger l’annuaire UDDI grâce au protocole SOAP.
De plus celle-ci comporte les fonctions essentielles à la publication et découverte de WEB Service telle que register() et service().
Chapitre3. Implémentation et déploiement d’un Web Service
En cours de création …
Light 5.0 