UDDI : mort et enterré…

Ca faisait un bout de temps que je n’avais pas vérifié http://uddi.microsoft.com ou http://uddi.ibm.com, mais il y a quelques années, j’avais déjà remarqué que le contenu était vraiment très limité. Récemment, j’ai du me replonger dans le sujet pour une intervention que je prépare chez un client, et j’ai pu constaté que la situation ne s’était pas améliorée : les sites sont carrément hors ligne, et la technologie UDDI est visiblement abandonnée.

Certains vendeurs de middleware qui se sont réorientés SOA en ont encore dans leur portfolio, mais ils ne doivent pas en vendre des masses. Evidemment, il est possible qu’UDDI ait eu plus de succès en entreprise que pour des annuaires de services sur internet, mais vu le nombre de retours négatifs, il y a peu de doute possible.

Pourquoi UDDI n’a-t-il pas eu le succès initialement escompté ? Après tout, cette technologie était censée être la pierre angulaire de la stratégie web services, au dessus de SOAP et de WSDL, le moyen technique qui allait permettre une réelle gouvernance SOA. L’expansion des services web allait nécessiter une solution de routage pour suivre les changements d’adresse, ainsi que les stratégies d’authentification, de robustesse, etc.

Une des explications les plus souvent avancées est la complexité d’UDDI. Pourtant, WS-Disco est plus simple, mais n’a pas percé non plus.

Personnellement, je pense que le problème était qu’UDDI essayait de solutionner un problème qui n’existait tout simplement pas. Même dans les systèmes informatiques les plus complexes, le nombre de services web n’excède pas quelques centaines, et sont en général répartis sur quelques serveurs. Les URLs changent rarement, de même que les settings de type sécurité ou routage. Quant aux WSDL, les changements de versions sont rarement parfaitement maîtrisés, alors imaginer qu’on pourrait avoir besoin d’un serveur spécifiquement pour les localiser dans leurs mouvements !

Une autre preuve de la trop grande complexité d’UDDI par rapport au besoin initial, surestimé, est que la technologie n’a tout simplement pas été remplacée par une autre : il n’y a rien, et les annuaires de services web sont tous des pages statiques. En interne, une page web sur l’intranet suffit, avec l’URL du serveur et le WSDL, plus une adresse mail du gestionnaire concerné. Les plus avancés pousseront jusqu’aux portions non-techniques du contrat de service comme les polices d’authentification, etc. Et tout cela suffit amplement.

Si ce n’est pas une belle illustration des approches KISS !

Tant que j’y suis, un petit retour sur un sujet connexe : l’utilisation de WADL pour décrire les services REST. Méfiance sur ce genre de normes, qui n’est pas compatible avec l’esprit du REST. La raison pour laquelle un service REST doit renvoyer dans sa grammaire des URI est qu’il doit être possible de revenir à une ressource de manière directe. Or, le principe d’un service REST est de supporter du discovery : l’enrichissement de ces URI doit être dynamique. Si un service REST change d’URL, le programme client qui le consomme doit pouvoir partir de l’URL unique du service et redescendre la structure pour aboutir à la ressource.

Lorsqu’on utilise un fichier WADL, on fixe par avance la structure de ce service REST, typiquement pour pouvoir créer des stubs par génération de code. Cette approche, qui est très paralysante car forçant un couplage, est déjà un problème dans les grammaires SOAP, pourtant très rigides. L’adopter pour des grammaires REST, dont le but est justement de s’éloigner de cette lourdeur, est contre nature.