LES WEB SERVICES

Ø  La requête

 

Ø  La réponse

 

En-tête de la requête :

Le format de l'URI dans la première ligne de l'en-tête n'est pas obligatoire mais sa présence permet de router la requête XML-RPC vers le bon système d'écoute.

Le User-Agent et Host doivent être spécifiés, le Content-Type doit être de type "text/xml" et le Content-Length doit être lui aussi obligatoirement spécifié et correct.

 

Contenu de la requête :

Le contenu est en XML, et ne peut contenir qu’une seule balise <methodCall> qui elle même ne peut contenir qu’une seule balise <methodName>. La valeur contenue dans la balise <methodName> est obligatoirement de type chaîne de caractères et contient le nom de la méthode distante à invoquer. Ici on appelle la fonction distante "monsite.password_provisoire" et on lui transmet le paramètre "max17200".

 

En-tête et contenu de la réponse :

Sauf erreur, la réponse doit retourner "200 OK", le Content-Type doit être de type "text/xml" et le Content-Length doit obligatoirement être renseigné et correct.

La réponse renvoyée est une structure XML contenant la balise <methodResponse>. Cette méthode contient alors soit la balise <params> avec la réponse de la méthode en cas de réussite soit la balise <fault> dans le cas ou une erreur se serait produite. Une balise <methodResponse> ne peut contenir en même temps la balise <params> et <fault>. Dans le cas de notre exemple, la méthode a renvoyé la chaine de caractère "x7x7x7x7frr77v"

 

 

3.2 - SOAP

SOAP (Simple Object Access Protocol), initialement défini par Microsoft et IBM, est aujourd'hui devenu le protocole de référence pour l'envoi de messages dans le cadre d'architecture de type SOA pour les Web Services.

Tout comme XML-RPC, SOAP est un protocole de type RPC bâti sur XML mais il est, lui, orienté objet. Ces deux protocoles sont très proches car ils sont, comme nous venons déjà de le dire en présentant XML-RPC, issus du même moule qui est le travail de Dave Winer qui, en réponse au développement de SOAP au sein de Microsoft jugé trop long, avait décidé de créer sa propre version de SOAP qu’il baptisa XML-RPC.

SOAP a finalement été publié dans sa première version stabilisée en juin 1999 et les deux protocoles ont ensuite évolués chacun de leur coté. Ces deux protocoles garderont néanmoins à jamais un lien étroit car SOAP, qui est donc à l’origine de XML-RPC, en est aujourd’hui devenu son successeur. La raison de la popularité grandissante de SOAP est principalement dû au soutient, tout d’abord de Microsoft puis par la suite, du W3C qui est devenu le mainteneur officiel de la spécification depuis sa version 1.2 publiée en 2003.

Bien que reposant principalement sur HTTP du fait de sa popularité dans les technologies Web, SOAP n’est pas lié à un protocole de transport particulier et peut très bien fonctionner par exemple avec SMTP, FTP ou encore tout autre protocole capable de véhiculer un flux d'information. SOAP est également indépendant du système d’exploitation et du langage de programmation.

SOAP est un protocole suffisamment puissant et souple pour permettre d'encoder des structures de données de complexité de tous niveaux. Une des grandes forces de ce protocole est d’ailleurs de permettre aux développeurs d'adjoindre leurs propres spécialisations au sein des messages.

Un message SOAP est bien plus complexe qu’un simple fichier XML classique car il représente en réalité une déclaration très structurée, appelée "enveloppe", qui a elle seule, doit réussir à contenir la totalité des informations nécessaires à l’invocation et l’exécution de la fonction distante. Cette enveloppe est constituée d'un en-tête (header) facultatif et du corps du message (body). Ces deux éléments reposent fortement sur l'usage des espaces de noms afin de permettre le transport de tout type de contenu XML en évitant les conflits de noms d'éléments. Le squelette complet d’un message SOAP prend la forme suivante :

 

 

 

3.2.1 - L'enveloppe

C'est l'élément supérieur du document, il englobe l'en-tête et le corps du message. Cet élément est obligatoire et sans enveloppe, le message ne peut pas être transporté. Il doit également répondre comme étant qualifié, c'est-à-dire répondre à l'espace de noms définissant SOAP. L’enveloppe est l’élément le plus externe, ou racine, d’un message SOAP.

 

Ø  L'en-tête

Placé au sein de l'enveloppe avant le corps, l'en-tête peut être utilisé pour compléter certaines informations nécessaires à une requête. Le plus souvent, on y trouve des extensions SOAP, des identifiants de connexion ou encore des métadonnées relatives au message. Les informations de l'en-tête peuvent être traitées, modifiées ou effacées par les applications intermédiaires. Pour assurer le bon traitement de ces informations, tous les éléments de Header doivent également être qualifiés par un espace de noms. L'en-tête reconnaît plusieurs attributs spécifiques :

Ø  actor : permet d'indiquer le destinataire du message ou de viser une application intermédiaire spécifique via une URL,

Ø  mustUnderstand : booléen qui permet d'indiquer si le traitement est obligatoire ou non,

Ø  encodingStyle : permet de spécifier les règles d'encodage.

 

Ø  Le corps

Cette section contient les données transportées par le message SOAP (le payload) qui, comme pour les éléments précédents, doit voir tous ses sous-éléments correctement qualifiés par des espaces de noms. Si c'est une requête, il doit contenir au minimum le nom de la méthode appelée, ainsi que les paramètres appliqués à cette méthode. En réponse, il contiendra soit un appel pour une autre méthode, soit une réponse à la requête, soit encore un message d'erreur détaillé.

 

Le protocole SOAP définit un mécanisme d'exception permettant de signaler la présence d'erreurs. Pour avertir d’une erreur, SOAP utilise le sous-élément "Fault", qui lui-même dispose de quatre sous-éléments :

Ø  faultcode : code identifiant de l'erreur,

Ø  faultstring : explication lisible de l'erreur,

Ø  faultactor : désigne l'origine de l'erreur,

Ø  detail : donne des détails spécifiques.

 

Ø  Types de données supportées en paramètre

Ø  entier,

Ø  date,

Ø  booléen,

Ø  chaîne de caractères,

Ø  tableau,

Ø  structure.

 

3.2.2 - Exemple

Nous allons maintenant voir un peu plus en détail ces messages. Pour cela nous allons simuler la méthode d'un service simple qui va doubler la valeur d'un entier qu’on lui transmet:

 

Ø  Requête

 

Ø  Réponse

 

Le prologue XML <?xml version="1.0" encoding="UTF-8" ?> spécifie la version de XML et l'encodage des caractères utilisés.

L'enveloppe SOAP <SOAP-ENV:Envelope ... > spécifie tout d'abord ici que le style d'encodage du message SOAP suit le schéma standard défini dans http://schemas.xmlsoap.org/soap/encoding/. C’est également ce schéma qui sera utilisé si aucun schéma n’est spécifié. L'Enveloppe SOAP contient également des définitions d'espaces de noms. Il est important de savoir que les espaces de noms sont optionnelles mais qu’à partir du moment où ils sont définis, ils doivent être corrects.

L’en-tête SOAP < SOAP-ENV:Header> comprend dans cet exemple une chaine de caractère qui servira d’identifiant à l’utilisateur. Les en-têtes SOAP sont optionnels et ne sont généralement utilisés que pour transmettre des informations d'authentification ou de gestion de session. Il est important de se rappeler que l'authentification et la gestion de session sont en dehors du cadre du protocole SOAP, même si SOAP en autorise la transmission.

Le corps SOAP <SOAP-ENV:Body> encapsule un unique tag qui porte le nom de la méthode invoquée <ns1: Fonction_double_entier ... >. Notez que le tag reçoit l'espace de noms correspondant au nom du service pour en assurer l'unicité. Le tag de méthode encapsule à son tour des tags <param> pour une requête et <return> pour une réponse. Les noms des tags <param> peuvent être modifiés.

 

L'une des caractéristiques les plus puissantes du protocole SOAP est sa capacité à gérer des paramètres de tout niveau de complexité. Voici pour le prouver, la réponse qui aurait été renvoyée si le rôle de la fonction distante n’était plus de retourner le double de l’entier qu’on lui transmet mais plutôt de retourner un tableau de chaînes de caractères à deux dimensions contenant par exemple le nom et le numéro de téléphone d’une personne dont l’identifiant serait l’entier transmis. La requête d’invocation de la fonction distante, hormis le nom de la fonction invoquée qui a changé, reste identique. Par contre la réponse retourne maintenant un tableau à deux dimensions.

 

Ø  Réponse

 

Comme on peut le constater, seule la spécification du type contenu dans le tag <return> du message est modifiée (en plus du nom de la fonction invoquée). C'est donc ici une structure de tableau qui est retournée : xsi:type="ns2:Array" ns2:arrayType="xsd:string[2]" à la place de l'entier retourné précédemment.

Bien entendu, pour que cet exemple soit fonctionnel, il serait également nécessaire d'effectuer quelques changements dans le fichier WSDL de description du Web Services sous peine d'obtenir une erreur dû à un mauvais type de donnée retourné, mais cet exemple est néanmoins très parlant pour prouver la simplicité avec laquelle SOAP s'est adapté à ce changement de structure.

 

Aujourd’hui, SOAP, même s’il est parfois critiqué à cause de la lourdeur imposée par la verbosité d’XML, est devenu un standard incontournable dans le monde des Web Services et un service se doit en principe d'être au moins accessible par ce protocole.

 

3.3 - WSDL

Afin de pouvoir invoquer un Web Services, il est obligatoire de connaître certaines informations comme par exemple son emplacement, ses méthodes, les paramètres à transmettre, etc. C’est en face à ce besoin que le standard WSDL (Web Service Description Language), basé sur le langage XML, est né.

Le standard WSDL est un langage de description de Web Services qui permet aux applications désirant les utiliser d'auto-configurer leurs échanges. Pour cela, un fichier WDSL contient toutes les informations nécessaires du Web Services pour permettre aux clients d'établir leurs requêtes d'invocation de méthodes. On dit aussi qu’un fichier WSDL est un "contrat" établi entre les différentes parties.

Les requêtes émises par le client devront être traduites au format XML afin de les rendre compréhensibles par le Web Services. Une fois ces requêtes traitées, ce sera au tour des réponses XML qui en résultent d’être retraduites dans le langage utilisé par le client. Ce mécanisme de transformation (marshaling / unmarshaling en anglais) est réalisé grâce à un proxy généré dynamiquement pour chacune des requêtes à partir du fichier WSDL. C’est donc grâce à ce mécanisme que les Web Services peuvent être indépendant des langages de programmation et des plateformes sur lesquelles ils s’exécutent.

 

Un fichier WSDL est composé de 8 sections principales :

Ø  définitions : élément racine du document, il contient le nom du Web Services et les diverses déclarations d’espaces de noms utilisés,

Ø  types : permet de décrire tous les types de données utilisés dans les messages,

Ø  messages : défini le nom de la balise qui contiendra le message. Chaque message peut contenir plusieurs éléments "part" qui permettront de le décomposer,

Ø  portTypes : défini les opérations que peut effectuer le Web Services ainsi que les messages (input, output ou fault) qu'il comprend. Dans le monde de l'échange de messages, les points de connexion sont des ports et la définition abstraite d'un port est appelée "type de port",

Ø  opérations : les opérations sont les méthodes proposées par le Web Services,

Ø  liaison (binding) : permet de décrire la manière dont le Web Services sera implémenté (protocole, format de données des opérations, type de port particulier,…). Les informations spécifiques à SOAP sont décrites dans cette partie,

Ø  service : permet de définir les adresses permettant l'invocation du Web Services,

Ø  port : c’est le point d’accroche du Web Services, il est identifié de manière unique par la combinaison d'une adresse internet et d'une liaison,

Ø  documentation : contient d’éventuels commentaires à l’intention des développeurs.

 

 

L’annonce de la version 2.0 de WSDL courant 2007 a marqué la fin des travaux par le W3C concernant ce protocole, ce dernier estimant que cette version était maintenant mûre et suffisante pour répondre aux besoins de bases actuels et futurs en matière de Web Services.

 

Voici un exemple de fichier WSDL complet :

 

 

 

 

3.4 - UDDI

A partir du moment où un Web Services est créé, une entreprise doit pouvoir le rendre disponible et inversement, les développeurs doivent pouvoir le trouver. La découverte d'un Web Services est une étape essentielle car c’est à cette occasion que l’on pourra récupérer le contrat WSDL sans lequel rien ne serait possible.

C’est suite à ce besoin que les sociétés Ariba, IBM et Microsoft ont débutées l’élaboration du standard UDDI (Universal Description, Discovery and Integration), finalement repris puis défini par l'OASIS (Organization for the Advancement of Structured Information Standards), dans le but de fournir une manière standard de publier et d'interroger les Web Services.

La spécification UDDI adopte une approche basée sur un annuaire virtuel distribué qui permet à un utilisateur, via une interface Web, de publier ou de rechercher un Web Services. UDDI est pour simplifier comparable à un annuaire téléphonique papier traditionnel (en plus complet).

 

UDDI contient trois types d’informations :

Ø les pages blanches qui identifient les prestataires de Web Services, c'est-à-dire qu’elles contiennent des informations sur les entreprises (nom, adresse, numéro de téléphone…),

Ø  les pages jaunes qui classent les Web Services d’après leur secteur d’activité comme dans les pages jaunes de notre annuaire papier classique,

Ø  les pages vertes qui contiennent les informations techniques sur le Web Services lui-même, c'est-à-dire toutes les informations nécessaires à son utilisation (url, interfaçage…).

 

 

Il est utile de bien comprendre qu’UDDI ne fait que classer les Web Services et que l’utilisateur, après avoir trouvé le Web Services désiré, devra se débrouiller pour récupérer les informations contenues dans son fichier WSDL pour pouvoir l'utiliser.

 

Les recherches ou ajouts de Web Services dans l'annuaire se font par requêtes XML (définies dans le schéma fournit par uddi.org) intégrées au sein d’une enveloppe SOAP. Ces requêtes peuvent être faites, soit par le Web, soit de manière logicielle, deux API étant prévues à cet effet (Inquiry API et Publication API).

 

Cinq informations sont importantes pour enregistrer un Web Services :

Ø  BusinessEntity : contient toute l’information concernant l’entreprise, son secteur d’activité et les éventuels autres Web Services qu’elle propose, cette partie représente les pages blanches,

Ø  BusinessService : contient les descriptions de l’ensemble des Web Services proposés par l’entreprise, cette partie correspond aux pages jaunes,

Ø  BindingTemplate : contient les informations techniques concernant le Web Services et ses points d’accès, cette partie représente les pages vertes,

Ø  tModel : cette partie permet de décrire de façon suffisamment précise les spécifications du Web Services pour connaitre son fonctionnement et le rendre accessible,

Ø  PublisherAssertion : cette partie sert surtout aux grandes entreprises pour lesquelles la description BusinessEntity ne suffirait pas pour la décrire de façon assez précise.

 

 

Schéma de fonctionnement général

Ø  La partie businessEntity décrit l’entreprise qui publie le Web Services, elle englobe une ou plusieurs parties businessService.

Ø  Chaque partie businessService contient des informations techniques et descriptives sur le Web Services publié. Pour cela, il contient une ou plusieurs sections bindingTemplate.

Ø  Chacune des sections bindingTemplate contient à son tour des parties tModel qui vont permettre de présenter les spécifications techniques du Web Services.

 

 

Nous n’allons pas entrer plus profondément dans les entrailles d’UDDI car il semblerait aujourd’hui que l’intérêt pour cette technologie décroît sérieusement. La raison est qu’à l’origine, UDDI a été créé dans le but de devenir un immense annuaire public où chacun pourrait trouver, voir éventuellement acheter, certains Web Services mais à la place de cela, il s’est plutôt transformé en un lieu d’échange privé uniquement adapté aux grandes entreprises.

 

En effet, dans la majorité des cas, les Web Services recensés sur UDDI ne sont pas publics et ne sont ouverts qu’à un groupe restreint de partenaires commerciaux ou même parfois simplement utilisés à des fins de communication interne au sein d'une même entreprise.

 

Il est donc de plus en plus fréquent que les développeurs contournent purement et simplement UDDI et font en sorte d'obtenir et de s’échanger directement les documents WSDL selon les besoins.

 

Voici un exemple de fichier exploitable par UDDI

 

 

 

3.5 - REST

REST (REpresentational State Transfer) est une approche alternative à SOAP et XML-RPC en matière d'implantation de Web Services qui commence sérieusement à faire parler d'elle car elle parvient de plus en plus à s'imposer face à ces deux compères pourtant aujourd’hui reconnus comme étant des piliers en matière de Web Services. Son intérêt est tel, qu’il est aujourd’hui devenu impossible d'en faire l’impasse.

 

REST n’est pas un standard ou un protocole reconnu par les organismes de normalisation et ne possède donc aucune reconnaissance dans ce sens. Néanmoins, même si REST n'est pas reconnue comme standard en tant que tel, elle repose néanmoins sur des standards éprouvés qui ont largement fait leurs preuves. REST est donc, à ce jour, plutôt considéré comme étant une "philosophie" de l'utilisation du Web qui repose sur des principes architecturaux déjà existants afin d'en permettre une exploitation optimum.

 

Cette "philosophie", que nous allons tout de même définir comme étant un style d'architecture à part entière, a été élaborée en 2000 par Roy Fielding en personne (créateur entre autre du protocole HTTP et du serveur Web Apache), car il estimait que dans bien des cas les méthodes HTTP de bases, combinées avec de bonnes URI, étaient largement aussi efficace et surtout beaucoup plus simple que d'utiliser les couches d'abstraction proposées par SOAP et XML-RPC.

 

Cette réflexion n'est pas apparue par hasard, la raison est qu’à l’origine, les Web Services devaient reposer sur un protocole ouvert, stable et robuste comme HTTP ou XML mais sans en altérer les performances et la qualité. Malheureusement, avec l'engouement pour les Web Services, SOAP a été contraint de se complexifier (utilisation de SMTP, gestion des pièces jointes, aspects sécurité, ...) et il s'est vu entouré d'une multitude d'autres formats et protocoles comme par exemple WS-Addressing, WS-Security, UDDI,…. SOAP est donc devenu pour beaucoup, trop complexe à mettre en œuvre dans les situations ne nécessitant pas une complexité accrue.

 

Le résultat d'une telle bataille entre deux technologies est classique. Il y'a d'un coté les poids lourds de l'industrie (IBM, Microsoft, Oracle, HP,..) qui ont investis des sommes faramineuses dans ces technologies et qui, pour récupérer leurs investissements, doivent les rendre opérationnelles à tout prix, et de l'autre coté un groupe de petits partisans privilégiant la véritable efficacité d'une technologie plutôt que les débats politiques qui en résultent. Dans le camp des partisans, nous retrouvons en particulier ici les prôneurs des méthodes Agiles qui ont totalement délaissés Java et qui ne jurent plus que par Ruby on Rails qui intègre nativement et de façon quasi transparente REST au cœur de son architecture.

 

 

Roy Fielding à la Rails conférence 2007

 

Roy Fielding explique dans sa thèse décrivant l'approche REST qu'il existe deux façons d’aborder un processus de conception d’architecture. La première, qui met en avant la créativité, est de partir de zéro et de construire petit à petit une architecture à base de composants jusqu'à obtenir le système envisagé. La seconde approche, sur laquelle a été défini REST, consiste à répondre tout d'abord aux besoins du système dans son ensemble puis d'y ajouter ensuite les contraintes nécessaires au fur et à mesure suivant les exigences rencontrées.

 

REST repose donc à la fois sur l’architecture existante du Web et sur les différents standards qui le compose, cela permet de retrouver certains principes simples :

Ø  chaque ressource du système est accessible via une URI unique et connaitre cette URI doit être suffisant pour accéder à la ressource,

Ø  l'utilisation du protocole HTTP permet de fournir une interface uniforme à chacune des ressources via les fonctions de base du protocole (GET, POST, PUT et DELETE),

Ø  l'utilisation des Types MIME pour la description des formats (text/xml, image/gif…),

Ø  chaque opération doit être auto-suffisante et autonome, c'est-à-dire qu'il n’y a pas de gestion d’état et que tous les paramètres sont intégralement transmis à chaque requête,

Ø  l'utilisation de standards hypermédias, c'est-à-dire pouvant transporter plusieurs types d'information (texte, image, vidéo...),

Ø  l'utilisation de liens entre les ressources afin d'assurer la navigation au sein de l’application,

Ø  la gestion de la sécurité se fait selon les normes usuelles (SSL, sessions, cookies...) et est principalement assurée par les navigateurs,

Ø  la possibilité d’utiliser ou non les mécanismes de cache standard (serveur Web, proxy, passerelle, navigateurs…).

 

Il est important de bien différencier HTTP et REST car on pourrait avoir tendance à penser que REST n'est en réalité qu'une description du protocole HTTP. Cette ressemblance est présente car HTTP est à la base de la quasi-totalité des applications Web existantes et que REST repose lui-même sur cette infrastructure, c'est-à-dire principalement sur HTTP. La différence est que REST ne se limite pas à HTTP et en contrepartie, il est tout à fait possible de faire une application HTTP sans respecter la philosophie REST. En fait HTTP est simplement une fonctionnalité utilisé par REST.

 

 

 

 

Dans l’approche REST, tout ce qui peut être nommé (compte utilisateur, article de journal, tableau de bord, document, image, service…) est considéré comme étant une ressource et se voit attribuer une URI unique de manière à pouvoir interagir avec elle. REST utilisera pour cela les méthodes de base du protocole HTTP qui sont POST, GET, PUT et DELETE.

 

Chaque opération d'un Web Services est donc associée à une URI et l'on pourra y accéder via les méthodes HTTP classiques. Le contenu des messages sera lui, simplement encodé en XML et la distinction entre les en-têtes et le contenu de ce dernier sera laissée à la charge des applications. Il est à noter que l'encodage en XML, bien que privilégié, n'est toutefois pas obligatoire et des réponses par exemple au format JSON (JavaScript Object Notation) ou en objets Java sérialisés sont également acceptables.

 

Dans REST, chaque ressource, identifiée par une URI unique, doit obligatoirement fournir une interface d'accès uniforme constituée d'un ensemble :

Ø  de Types MIME permettant de décrire le format des paramètres envoyés et des réponses attendues.

 

Ø  d'opérations correspondant aux verbes (méthodes) HTTP (POST, DELETE, GET, PUT), ces verbes correspondront aux méthodes dites "CRUD" (Create, Read, Update, Delete).

 

 

 

Pour effectuer une comparaison, là où SOAP et XML-RPC se basent sur des méthodes, REST se base sur les ressources existantes. Avec REST, connaître l’URI d’une ressource suffit pour y accéder et interagir avec elle.

 

 

Roy Fielding précise, toujours dans sa thèse, les avantages de ce style architectural par rapport aux autres styles d'architectures d'applications Web :

Ø  l'application est plus simple à entretenir car les liens sont mieux structurés, car de façon universelle,

Ø  l'absence d'état sur le serveur :

·         conduit à une consommation de mémoire inférieure et permet par conséquent au serveur de répondre à un plus grand nombre de requêtes simultanément,

·         rend le fonctionnement plus simple à appréhender,

·         permet une répartition des requêtes sur plusieurs serveurs avec une meilleure granularité et de manière plus souple,

·         permet une meilleure tolérance aux pannes d'un des serveurs,

Ø  le respect de la philosophie du protocole HTTP conduit à une architecture plus cohérente et plus simple,

Ø l'utilisation d'URI pour représenter une ressource permet l'utilisation de serveurs caches.

 

 

La principale limitation que connait actuellement REST vient de la non standardisation des méthodes PUT et DELETE du protocole HTTP au sein des navigateurs. C'est l'un des freins majeurs à son adoption car même si la possibilité de mettre en place une architecture REST côté serveur, grâce, par exemple à l'utilisation de champs cachés dans les formulaires HTML pour envoyer ces méthodes (comme le fait d'ailleurs le Framework Ruby on Rails), cela demande tout de même des connaissances informatiques non négligeables. Il est également utile de préciser que REST est uniquement une méthode alternative à XML-RPC ou SOAP et un Web Services REST devra également, en principe, être associé à un fichier WSDL pour assurer sa description.

 

Etudions pour finir un petit exemple d'utilisation de REST

Prenons une entreprise spécialisée dans la vente de fleurs sur Internet qui veut permettre à ses clients d'obtenir, via un Web Services utilisant REST, la liste des articles en vente et éventuellement d'obtenir des informations complémentaires sur un article précis. La liste des articles sera alors disponible à l'URL suivante : http://www.maboutique.com/articles/.

 

La manière dont le Web Services va générer cette liste n'est pas important pour le client et la seule chose qui va l'intéresser est que cette adresse lui fournira la liste des articles de la boutique. Cette étape montre déjà un point très positif de REST car nous constatons que l’entreprise est libre d’implémenter la création de sa liste de la manière dont elle le souhaite sans impacter les visiteurs, c'est le principe du "couplage lâche" (loose coupling).

 

Le client recevra la liste sous la forme suivante :

 

Cette liste contient des liens permettant d'obtenir des informations détaillées sur chaque article et en cliquant sur le lien http://www.maboutique.com/Articles/0001/ nous arrivons alors sur la fiche de présentation de l'article 0001 qui, dans cet exemple, permettra d'obtenir un descriptif encore plus détaillé en cliquent sur le lien http://www.maboutique.com/Articles/00001/details.

 

La réponse renvoyée au client sera alors :

 

Nous voyons ici la véritable force de REST : les liens entre les ressources.

 

REST est en train de gagner de plus de points dans l'opinion des développeurs et pour preuve, les API des gros Web Services comme Amazon, Yahoo! et eBay qui offraient un accès à la fois avec SOAP et REST ont abandonné SOAP et ne proposent aujourd'hui plus qu'un accès via REST pour certaines de leurs fonctionnalités.

 

IV - Les WS - *

 

Nous venons de voir les technologies (XML-RPC, SOAP, WSDL, UDDI et REST) qui composent aujourd'hui l’architecture de référence des Web Services. Cependant, cette architecture montre rapidement ses limites dès que les exigences vont au delà d’interactions simples via des protocoles standards et l'ajout de nouveaux standards, pour les compléter, s'est vite fait sentir pour pouvoir répondre aux exigences demandées. Le but ne fut alors pas de jeter tout ce qui avait été réalisé jusqu'ici dans le domaine, mais plutôt, du fait de son architecture en couche, de venir y greffer des protocoles complémentaires. C'est pour répondre à ce besoin que le groupe architecture du W3C s'est activement penché à l’élaboration d’une architecture étendue dans laquelle plusieurs couches, répondant chacune à un standard et un besoin particulier des Web Services, viendront se greffer sur les couches de bases. L'ensemble de ces couches a alors pris la dénomination de WS - *.

 

 

Architecture étendue proposé par le W3C pour les Web Services

 

 

4.1 - La WS - I

Afin d’assurer l’interopérabilité entre les implémentations de toutes ces nouvelles normes, une organisation, baptisée WS-I, a été fondée le 6 février 2002 sous l'impulsion de Microsoft, d'IBM et de BEA Systems. Le consortium WS-I regroupe aujourd'hui plus de 160 sociétés et son objectif est de faire progresser l’interopérabilité des Web Services en définissant les bonnes pratiques d'utilisation de standards existants et à venir.

 

Les travaux du WS-I sont menés en coopération avec les organismes de standardisation OASIS et W3C. Le WS-I a ainsi élaboré et proposé trois types de livrables :

Ø  des profils regroupant des règles de bonnes utilisations des standards en vue d’assurer l’interopérabilité des implémentations,

Ø  des exemples mettant en œuvre ces profils,

Ø  des outils de tests permettant de comparer une implémentation avec un profil.

 

 

Ø  Les profils

Les profils sont donc des règles de bonne utilisation destinées à permettre une bonne interopérabilité des Web Services. Voici comment s’articulent les différents profils :

·         le Basic Profile constitue le socle des profils,

·         le Basic Security Profile y ajoute une dimension sécurité.

 

 

Il est intéressant de noter que la sortie du Basic Profile 1.0, première version officielle, a déjà permis de résoudre plus de 200 problèmes d'interopérabilité. Au jour de la rédaction de ce chapitre c'est la version Basic Profile 1.2 qui est en cours de finalisation. L’objectif à terme sera de regrouper l’ensemble des profils au sein d’un Reliable Security Profile 1.0.

 

Ø  Les outils

Le WS-I propose deux outils de tests de conformité : Le Monitor et l’Analyzer.

 

• Le Monitor est configuré pour intercepter les requêtes et les réponses échangées entre un client et un Web Services.
• L’Analyzer permet lui de tester la conformité par rapport à un profil. L'analyse effectuée peut porter par exemple, sur la définition du contrat WSDL, le contenu d’un annuaire UDDI ou encore les traces générées par le monitor.

 

 

 

 

 

 

 

 

 

 

4.2 - La carte des WS - * aujourd'hui

Nous n'allons pas détailler les protocoles composants aujourd'hui les WS-* car leur présentation serait le sujet d'un mémoire à part entière mais voici tout de même la carte des avancées réalisées afin de bien se rendre compte du travail titanesque qui est en train de s'effectuer dans ce domaine. A l'heure actuelle, ces travaux sont réalisés conjointement par le WS-I, le W3C, l'IETF et l'OASIS et la plupart des protocoles sont encore en cours de développement

 

L'architecture actuelle des WS - *

 

Avec comme dépendances principales :