đź“° Web Services

📅 December 16th, 2010 ⏲️ 2 mins 42 secs

Si l’on reprend la dĂ©finition de Mark Colan, Web Service and XML Chief Advocate chez IBM, les Web Services sont des “applications modulaires basĂ©es sur internet qui exĂ©cutent des tâches prĂ©cises et qui respectent un format spĂ©cifique”. Nous sommes bien conscients que cette citation apportera peu d’informations aux non initiĂ©s et nous allons tâcher d’en reprendre le contenu.

Il y a plusieurs manières de définir les web services :
Si l’on s’en remet Ă  une dĂ©finition non-informatique, le terme “Web Service” dĂ©crit une fonctionnalitĂ© commerciale exposĂ©e par une entreprise sur Internet afin de fournir un moyen d’utiliser ce service Ă  distance
Si l’on s’en tient aux aspects opĂ©rationnels, les “Web Service” sont des applications modulaires qui peuvent ĂŞtre dĂ©crites, publiĂ©es, localisĂ©es et invoquĂ©es dans un rĂ©seau.

Ainsi, cela permet à vos applications de faire appel à des fonctionnalités situées sur d’autres machines.
Si l’on dĂ©taille tout ceci, on peut dire que l’objectif initial d’un web service est de permettre l’utilisation d’un composant applicatif de manière distribuĂ©e.

Plus clairement, cela consiste Ă  permettre l’utilisation d’une application Ă  distance. En fait, les “Web Services” facilitent l’invocation de certains traitements depuis Internet. Le modèle logiciel proposĂ© contient Ă  la fois un nouveau mode de dĂ©veloppement et une nouvelle mĂ©thode de fourniture de services.  Les concepts qui le composent en font presque un vĂ©ritable paradigme de programmation.

L’avantage de ce modèle tient est de prĂ©senter ces services comme des “boĂ®tes noires”. En fait, les entrĂ©es-sorties d’un service sont gĂ©rĂ©es au sein de messages dont on connaĂ®t le format grâce Ă  des interfaces clairement exposĂ©es mais sur lesquels l’implĂ©mentation interne du traitement n’influe pas au niveau de la structure. Ceci permet un haut niveau de modularitĂ© et d’interopĂ©rabilitĂ©. L’avantage du modèle de message est qu’il permet de s’abstraire de l’architecture, du langage ou encore de la plate-forme qui va supporter le service : il suffit juste que le message respecte une structure donnĂ©e pour qu’il puisse ĂŞtre utilisĂ©.

Techniquement les concepts ayant donnĂ© lieu aux Web Services ne sont pas nouveaux. Nous venons d’Ă©voquer les protocoles existants : DCOM, RMI, CORBA, DIIOP et Remote Procedure Call (RPC).

Les implĂ©mentations propriĂ©taires de ces protocoles ont menĂ© Ă  leur perte. Ceux-ci sont progressivement abandonnĂ©s au profit des Web Services. On peut toutefois s’attendre Ă  les voir conserver tant que les technologies que nous allons vous prĂ©senter n’auront pas parfaitement adressĂ© l’ensemble des problèmes que l’informatique distribuĂ©e recouvre.

Pour finir, la dĂ©finition des Web Services ne serait pas complète si l’on n’Ă©voquait pas ses principaux standards : SOAP, WSDL et UDDI, des protocoles mis en place par Microsoft, IBM, Sun et bien d’autres.

SOAP est un protocole permettant l’invocation de mĂ©thodes Ă  distance par l’échange de messages XML
WSDL est une norme dĂ©rivĂ©e de XML qui permet la description de l’interface d’utilisation d’un Web Service. Ce standard est donc Ă©quivalent Ă  la partie publique d’une classe ou au header d’un programme C.
UDDI est un protocole d’annuaire permettant de trouver le web service que l’on recherche mais aussi d’en annoncer la disponibilitĂ©