AkaSigD’après ce que l’on peut lire sur l’expérience d’Amazon en matière de services Web, bien qu’Amazon publie ses services Web aussi bien sous une interface REST que sous une interface RPC/SOAP, 85% des accès à ces services se font via l’interface REST. Les développeurs Web apprécient la simplicité relative du modèle
REST.
Uche Ogbuji retrace l’historique des services web. En voici un résumé très schématique. IBM MQSeries était l’un des précurseurs de la tendance. En leur temps, vinrent CORBA et leurs pendants Microsoftesques COM et DCOM. Le protocole RMI pour Java naquit et les succès de niche de MQSeries donnèrent le jour à des technologies équivalentes chez Sun et Microsoft. Les services distribués prirent ensuite la forme de services Web (HTTP + XML) tout d’abord avec l’offre visionnaire e-Speak de HP (un peu trop en avance sur son temps ?) puis avec l’émergence du rustique mais simple et robuste XML-RPC au sein de la communauté opensource. Du côté des grosses entreprises, leurs besoins de transactions inter-organisations les menèrent de l’EDI façon Internet à l’ebXML (sponsorisé par Sun). C’est fin 1999 que SOAP (sponsorisé par Microsoft) fit son apparition. Une partie de la communauté opensource constituée autour de XML-RPC adopta peu à peu SOAP car cette spécification technique, pour une fois, semblait très ouverte. Plusieurs standards furent proposer pour décrire les services Web et c’est WSDL qui, sous le sponsorship d’IBM et de Microsoft s’affirma comme candidat le plus sérieux puis UDDI fut proposé en complément, pour constituer des annuaires de services Web. Aujourd’hui, c’est le trio SOAP + WSDL + UDDI qui est présenté comme la spécification moderne des services Web. SOAP connaît un certain succès “de terrain” auprès des développeurs notamment, malgré les problèmes d’interopérabilité qui subsistent lors des implémentations, tandis qu’à l’autre extrémité, UDDI, qui est sensé être un support pour des politiques “corporate” de gestion des services Web, à encore plus de mal à trouver ses marques.
D’après Uche Ogbuji, deux visions s’affrontent aujourd’hui parmi les promoteurs des technologies pour services Web : les uns pensent que les équipes amenées à implémenter des services Web devraient se composer d’experts en technologies XML (approche adéquate pour traiter des problématiques de communication inter-entreprises) ou de développeurs s’appuyant uniquements sur des boîtes à outils hermétiques (approche fréquente pour des périmètres spécifiquement internes aux entreprises). Microsoft (avec .Net) et IBM offrent de telles boîtes à outils. BEA, Iona et Apache offrent des fonctionnalités similaires. Etant donné le manque de maturité des technologies des services Web, les éditeurs de boîtes à outils risquent d’être l’objet d’importantes contraintes d’évolution lorsque des normes consensuelles émergeront et que leurs boîtes à outil devront tenter de s’y conformer. OASIS souhaite définir un modèle universel de composants pour services Web (WSCM) qui couvriraient des besoins tels que ceux aussi bien ciblés par CORBA ou COM que ceux ciblés par les composants visuels à la JavaBeans ou à la Delphi. De plus, l’avenir des services web pourrait être fortement influencé par l’évolution des bases d’objets et des technologies telles que le Web Sémantique. Pour l’instant, seul SOAP a fait l’objet d’implémentations fréquentes. Des spécifications technologiques complémentaires telles que UDDI, bien qu’émises depuis longtemps, n’ont toujours par pris forme en pratique et on peut s’interroger sur leur avenir.
Personnellement, je doute même de la pérennité, et surtout du bien-fondé, de SOAP qui, malgré sa séduisante et trompeuse simplicité d’implémentation auprès des développeurs, repose sur des principes architecturaux très éloignés du principe de “couplage faible” (loose coupling) qui a fait le succès des technologies Web. Le modèle REST semble bien plus satisfaisant à cet égard (chercher “REST” dans ce blog pour plus d’infos à ce sujet) bien que nécessitant un mode de conception d’applications + services Web inhabituel pour les développeurs, plus familiers du “j’ai une fonction/méthode, je lui passe des paramètres et j’obtiens un résultat en sortie” à la RPC.
Cet article décrit comment vous pouvez accéder sous la forme d’un flux RDF/RSS à la liste des derniers livres publiés par Amazon sur vos thèmes favoris.
Le Web Sémantique et les Services Web tirent-ils le Web dans de directions opposées ? Cet article (http://www.xml.com/lpt/a/2002/07/17/daml-s.html) signale une manière de conjuguer ces deux tendances. L’idée consiste à décrire un service Web en tant que ressource du Web, à l’aide d’un vocabulaire spécifique exploitant certains langages de représentation du Web Sémantique (DAML+OIL). Le résultat est DAML-S, une ontologie générale pour Services Web, qui permet à une application de répondre aux “Quoi ?” et aux “Pourquoi ?” (contrairement aux “Comment ?” auxquels répond déjà WSDL). Les fonctionnalités d’applications exploitant DAML-S seraient la découverte, l’invocation, la coordination (”interopération”), la composition, le contrôle et la supervision de Services Web. DAML-S : un futur standard ou un flop annoncé ? en tout cas sans doute une idée qui mérite réflexion…
Comme signalé sur ce site, REST présente des avantages certains sur le modèle Remote Procedure Call tel qu’adopté par le protocole SOAP.
SOAP est un coucou dans le nid des technologies Web. Il faut l’en déloger. C’est ce qu’explique cet article de Edd Dumbill. Une citation de cet article : “Le choix est entre une technologie ouverte et établie sur laquelle le Web se fonde et la direction proposée par de grosses entreprises dont l’existence dépend de leur capacité à faire de l’argent grâce à ces stratégies”.
Qu’est-ce que “.Net” ? La réponse sur dotnet-fr.org.
XML.com: REST and the Real World [Feb. 20, 2002]
En quoi le modèle REST serait-il préférable aux services web sur SOAP ?
XML.com: Google’s Gaffe
Google a fait un pas en avant vers les services web en publiant son API via XML et deux pas en arrière en choisissant de ne plus le faire en XML + HTTP-GET mais en SOAP + HTTP-POST.
Slashdot | Web Services
Miser sur SOAP pour mettre en place des services web sécurisés n’est sans doute pas une idée lumineuse :
“SOAP et al are a mistaken implementation for exactly that reason, in a typical Microsoft fashion: by running everything over HTTP, we can get things working quickly without wondering whether they are secure. Later on, there will be a ton of SOAP security holes and information leaks, but we won’t be able to plug the hole properly since we can’t cut off HTTP without strangling our businesses. I love innovation without cogitation. An absolute godsend to good firewall administrators would be to have specific services on specific ports so that you could easily audit the use of such services separately and have a better handle on what’s going in and out of your ‘net. You could, for example, inspect SOAP packets for a particular service without having to slow down all traffic through your HTTP proxy. But since you’re a lazy bastard, I bet you don’t care :)”
On voit à peine émerger la première génération des services web que l’on parle déjà de la seconde. N’empêche que ce qui s’en dit m’a l’air très intéressant. L’approche “je publie via SOAP/WSDL/UDDI une API pour accéder à mes procédures” serait à mettre à la poubelle au profit d’une approche centrée sur les URI et la publication des modèles de données. C’est ce que l’on appelle le modèle REST. J’aime cette approche, cohérente avec celle de RDF.
A l’occasion de la sortie d’un livre sur le sujet, O’Reilly dresse une synthèse de l’opportunité et de la faisabilité des webservices pour l’entreprise. Les approches de type REST (exposer des données de manière standardisée plutôt qu’exposer des interfaces d’appel à des procédures) ont peut-être plus de chances de réussir que les web services.
