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.