Le W3C définit un Web Service comme un système logiciel conçu pour permettre l’interopérabilité entre deux machines sur un réseau. L’interface du service Web est décrite dans un “format machine”, généralement un WSDL (Web Services Description Language).

Cet article sera publié en deux parties, la première destinée à introduire et présenter le sujet.

Introduction

Des systèmes peuvent interagir avec le service Web de la manière prescrite par sa description en utilisant des messages SOAP, typiquement transmis via le protocole HTTP et une sérialisation XML en conjonction avec d’autres normes liées au Web.

Nous pouvons identifier deux grandes classes de Web Services :

• REST (REpresentational Sate Transfer), dans laquelle le but principal du service est de manipuler des représentations XML de ressources Web en utilisant un ensemble uniforme méthode du protocole HTTP (GET, POST, PUT et DELETE)
• les Web Services, dans lequel le service peut exposer un ensemble arbitraire de services, qui sont généralement des interfaces de programmation d’application (API) ou des API Web qui sont accessibles via HTTP (Hypertext Transfer Protocol) et exécutés sur un système distant hébergeant les services demandés.

Les Web Services (parfois appelés services d’application) sont des services qui sont mis à la disposition d’un serveur Web pour les utilisateurs du Web business ou d’autres programmes reliés au Web. Les fournisseurs de Web Services sont généralement connus en tant que fournisseurs de services applicatifs. Les Web Services vont des principaux services comme la gestion du stockage et la gestion de la relation client (CRM) jusqu’à des services beaucoup plus limités tels que le retour d’un cours de bourse ou la vérification des offres pour un objet aux enchères.

L’accélération de la création et de la disponibilité de ces services sont une tendance Web majeure. Des Web Services ont tendance à tomber dans l’un des deux camps : les “grands” Web Services et les services Web RESTful. Les premiers utilisent des messages XML qui respectent la norme SOAP et sont très populaires avec les entreprises traditionnelles. Dans de tels systèmes, il y a souvent une description lisible par machine des opérations proposées par le service écrit dans le WSDL.

REST : un concurrent de SOAP pour une intégration légère

A l’origine REST désignait un principe d’architecture basé sur la distribution de médias liés entre eux par des hypertextes (à la manière du Web). Aujourd’hui, le terme est employé pour désigner une architecture d’intégration de services allégée.

REST est beaucoup plus simple que SOAP. Il n’est pas à proprement parler un protocole d’invocation à distance ; il s’agit essentiellement d’un protocole destiné à des services CRUD utilisant des messages XML pour l’accès à des ressources distantes.

REST est largement utilisé pour les intégrations au niveau de l’interface utilisateur dans les services sur Internet. Ces services comme Flickr ou del.icio.us sont destinés à permettre à des internautes de partager des informations entre plusieurs applications. Leurs besoins en intégration sont donc très simples.
REST est donc destiné à des développeurs de sites Web : en aucun cas, cette technologie ne peut être utilisée pour des compositions de services au sein d’applications métiers complexes. Ce n’est donc pas un concurrent sérieux pour SOAP dans le cadre des architectures SOAP.

Définir un contrat de service avec WSDL

WSDL signifie Web Service Description Langage. Comme son nom l’indique, il s’agit d’un langage XML normalisé pour décrire le mode de fonctionnement d’un Web Service.
Il permet de décrire les modalités d’invocation distantes d’un Web Service en particulier :

• les opérations possibles au sein du service
• les paramètres d’entrée et sortie de ces opérations
• le typage de ces paramètres
• les points d’entrée (URL) des opérations

Le schéma ci-dessous montre comment WSDL traduit ces notions dans sa grammaire normalisée.

Les limites de WSDL sont dûes à la mécanique d’invocation du service ne permettant pas de décrire une plaquette commerciale du service, une tarification éventuelle du service, etc… En effet, un WSDL constitue un contrat pour l’invocation technique de Web Service, sur lequel les applications clientes peuvent s’appuyer pour connaître les opérations et leurs arguments. Ainsi chaque application pourra paramétrer de manière automatique cette invocation de service.

Appel de procédure distante (RPC)

XML-RPC date de 1995. C’est une technologie d’invocation de service à distance basée sur XML et HTTP, donc indépendante du langage d’implémentation. Son mode de fonctionnement consiste en l’invocation à distance d’une méthode de classe objet. Pour mener à bien cette invocation dans un environnement Internet, la signature de méthode est traduite en XML et les paramètres sont passés selon le même principe.
XML-RPC connaît une dizaine de types très primitifs, ce qui en fait une grammaire simple à appréhender, mais très rudimentaire en terme de capacité d’invocation.
Par ailleurs, la technologie ne propose pas de notions de description de l’interface du service. De plus, il n’y a pas non plus de normalisation des erreurs.
Cette technologie est donc utilisée aujourd’hui dans des cas très simples, mais inadaptée à des architectures distribuées complexes.

D’autres approches ont à peu près les mêmes fonctionnalités que RPC :

• OMG : Object Management Group
• CORBA : Common Object Request Broker Architecture
• DCOM : Microsoft Distributed Component Object Model
• RMI : Sun Microsystems Java / Remote Method Invocation
• REST : Representational State Transfer

Illustration des différences entre SOAP et REST

Si l’on prend l’exemple d’un fabriquant de produit voulant ouvrir son SI en s’appuyant sur REST, il déploiera un ensemble de services ouverts sur le Web pour ses nombreux clients :

• la liste des produits
• le détail d’un produit
• la mise à jour d’un produit
• la commande d’un produit (cette requête s’appuiera sur un POST)
• la suppression d’une commande

La figure ci-dessous montre (de façon simplifiée) comment ces services seront implémentés avec le style REST, et en SOAP.

Performance et publication

Comme les Web Services se multiplient, les préoccupations comprennent l’ensemble des demandes sur la bande passante du réseau et, pour un service particulier, l’effet sur les performances qu’exige ce service. Un certain nombre de nouveaux produits sont apparus permettant aux développeurs de logiciels de créer ou modifier les applications existantes pour qu’elles puissent être « publiées » (terme employé pour signifier : accessible) par les services Web.

La chose intéressante au sujet des Web services est qu’ils sont basés sur des protocoles standards qui visent à garantir que tout Web service peut être consulté par n’importe quels programmes clients, peu importe le langage dans lequel ils sont écrits et quelle que soit la plate-forme sur laquelle ils sont en cours d’exécution. Ainsi, un programme Java peut accéder et utiliser un Web service écrit en PHP et déployé sur un serveur Windows, aussi facilement qu’un programme Windows peut utiliser un Web service écrit en Java et fonctionnant sur un serveur Web Linux.

En raison de cette souplesse, plusieurs entreprises concurrentes pourraient par exemple publier par des Web services, une vérification orthographique d’un texte, et en interrogeant ce service vous pourrez l’utiliser. Tant qu’ils s’appuient tous sur la même description, votre programme peut utiliser n’importe lequel d’entre eux de façon interchangeable. La différence pourrait se faire sur la correction en différentes langues, la seconde concernera le développement et la publication d’un service Web en PHP.

La technologie des Web services a évolué autour d’une pile de cinq technologies : Network, Transport, Packaging, Description, et Discovery (j’ai volontairement laissé les termes en anglais car ils reflètent vraiment les différentes technologies). Chacune de ces technologies sont liées.

• Pour qu’un programme puisse utiliser un Web service, il doit d’abord être capable de le trouver : pour cela il faut mettre en place un réseau de serveurs (Network)
• Un système mondial d’annuaire des Web services, UDDI (Universal Description, Discovery, and Integration) permettant à un fournisseur de décrire ces Web services, puis au client de découvrir les Web services et de s’y connecter. Un UDDI est construit sur la base des normes WSDL et SOAP. (Discovery)
• Le WSDL décrit les différentes fonctions qu’un Web service publie. Le protocole SOAP permet d’encapsuler les appels de fonction et les messages comme des demandes de Web service. (Packaging)
• Une fois qu’une demande est encapsulée (par exemple, sous forme de message SOAP), vous avez besoin d’un moyen de le transmettre au Web service. En retour, celui-ci nécessite également un moyen de vous envoyer sa réponse. Pour cela, la technologie des Web services est assez souple à utiliser, puisque vous pouvez utiliser n’importe quel protocole. Le protocole HTTP (Hypertext Transport Protocol), utilisé par les navigateurs Web pour demander et recevoir des pages Web, est de loin le plus fréquemment utilisé. Pour envoyer et recevoir des demandes et des réponses entre les ordinateurs, un réseau de quelque nature doit être disponible. Dans la grande majorité des cas, l’Internet n’est que le réseau – ou un autre réseau interne basé sur TCP / IP (Transport)

L’architecture orientée services

Les Web services peuvent également être utilisés pour mettre en œuvre une architecture conforme SOA (Service-Oriented Architecture), concept, où l’unité de base de la communication est un message, plutôt qu’une opération. Ce concept est souvent appelé service “message-oriented“.
L’architecteure SOA basée sur les Web services est pris en charge par la plupart des grands fournisseurs de logiciels et analystes de l’industrie. Contrairement à des Web services RPC, l’accent est mis sur le contrat que fournit WSDL, plutôt que sur les détails d’implémentation sous-jacente.
De l’ensemble des offres en matière d’infrastructure SOA émerge le concept d’ESB (Entreprise Service Bus), mais force est de constater que c’est un concept “attrape tout” aux contours flous. Un ESB, au sens strict du terme, est un bus de communication de messages d’événements métiers. Ce composant permet à un consommateur d’accéder à un service. Je vous décrirais dans un prochain article, la notion d’ESB avec son architecture, ses besoins, etc…
Un exemple d’ESB Open Source est Mule, ou encore Open ESB.

La rédaction d’un Web Service

Il y a deux principales façons pour écrire un Web Service. Vous pouvez utiliser une approche ascendante, qui va dans un premier temps décrire la classe d’implémentation dans un langage de programmation, puis en utilisant un outil générer, le WSDL, pour en exposer ses méthodes en tant que Web Service. La deuxième méthode, vous oblige à d’abord écrire le fichier WSDL, puis programmer un outil qui va générer le squelette de classe complété ultérieurement. Cette approche plus complexe, produit de bien meilleurs résultats que la méthode ascendante.

Cet article se finit pour sa première partie. Très prochainement, je posterais la seconde partie qui nous permettra de réaliser l’implémentation d’un Web Service en différentes étapes. Les fichiers vous seront fournis et une démonstration sera en ligne.

Avez-vous déjà implémenter des Web Services ? SOAP ou REST ? Quelle technique de rédaction utilisez-vous ?