Passer au contenu

Le point sur la normalisation des services web

Qui dit services web, dit SOAP et WSDL. Mais ces deux normes ne suffisent pas à elles seules à garantir la sécurité et la fiabilité des applications. Pour preuve : une myriade de propositions gravite aujourd’hui autour des architectures de service web.

Lancés à grand renfort de médiatisation, les services web ne sont pas un nouveau modèle de développement de composants mais un mécanisme RPC (Remote Procedure Call). Ils facilitent donc l’invocation des composants existants, ou nouveaux, développés dans n’importe quel langage et utilisant des middleware variés. C’est d’ailleurs la véritable révolution apportée par ces nouvelles architectures, supposées faciliter les échanges entre environnements hétérogènes. Ces services web s’appuient sur deux piliers dénommés WSDL et SOAP. Le premier est une sorte d’enveloppe qui encapsule les composants existants, pour leur faire dire quels services ils sont capables de rendre et quelles méthodes utiliser. Le deuxième est un mécanisme de transport standard s’appuyant sur HTTP, qui normalise les échanges entre services web. Dans les faits, la mise en oeuvre des services web a rapidement mis en évidence des lacunes autant du côté de la sécurité que de la gestion des transactions, raison pour laquelle ce concept n’est plus seulement lié à deux normes, mais à un grand nombre, dont la plupart sont encore loin d’être stabilisées.

Renforcer la sécurité et la gestion des transactions

Outre la norme d’annuaire UDDI servant à retrouver un service web, et son pendant WS-Inspection, supposé simplifier le processus, les services web sont en effet associés à des propositions de standards dans le domaine de la sécurité. Ainsi, XKMS, projet de protocole proposé à l’origine par Verisign, Microsoft et WebMethods, peut être assimilé à une infrastructure PKI. Il normalise donc l’authentification du service web et, au passage, de l’entreprise qui l’utilise et fonctionne avec XML Signature, une spécification de chiffrement en cours de normalisation au W3C.Côté fiabilité des transactions, plusieurs normes sont également à l’étude. HTTPR s’attaque par exemple à l’intégrité des transactions en s’assurant qu’un message a bien été délivré, et ceci une seule fois, afin de gérer les erreurs liées aux répétions (internaute qui clique plusieurs fois sur un formulaire par exemple). XAML, soutenu par Bowstreet, HP, IBM, Oracle et Sun, en fait autant mais au niveau de la couche applicative pour gérer la synchronisation de plusieurs services web dans le cadre de transactions longues (two-phases commit).BEA, pour sa part, est à l’origine de BTP, en cours de normalisation, à l’Oasis cette fois-ci. Concurrent de XAML, BTP gère et surveille les traitements couplés afin de s’assurer qu’ils s’effectuent dans l’ordre initialement prévu et que toutes les conditions d’exécution sont bien remplies et fonctionnent avec SOAP, ebXML messaging ou RosettaNet. Pour mieux maîtriser le chemin emprunté par les messages sur le réseau, Microsoft travaille sur WS-Routing et WS-Referral, fonctionnant au niveau de la couche IP ou UDP, et qui devraient être prochainement proposés pour la normalisation.Enfin, destinée cette fois à la présentation des services et à leur intégration dans les offres de portail notamment, WSCM est en cours de définition, à l’Oasis également.

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.


Marie Varandat