ntergiciel et Construction d’Applications R’ eparties c 2006-2008 M. Dumas, M. -C. Fauvet (version du 12 juin 2008 17:18) Licence Creative Commons (http://creativecommons. org/licenses /by-nc-nd/2. O/fr/deed. fr) Chapitre 4 Les Services Web Cacc es aux syst emes d’information s’appuie aujourd’hui de plus en plus sur des technologies Internet.
Les efforts de standardisation dans ce contexte ont accentu e l’engouement des personnes et de qu’industrielles, com 5 l’utilisation de l’Intern et Swape next page des services Web co applications accessibl n acad ‘ emiques, elles) pour gence ppement des s technologies associ es aux services Web sont devenues incontournables pour le d ‘ eveloppement d’applications interagissant les unes avec les autres par le biais de l’Internet. Nous proposons dans ce chapitre de faire un point sur le sujet des services Web.
L’objectif de la discussion est de traiter des aspects conceptuels de la mod’ elisation des services aussi bien que des aspects li’ es a’ leur implantation. La section 4. 1 commence par donner quelques d • efinitions et prlnclpes n ‘ ecessalres a la compr• ehension de la suite. Puis la section 4. 2 discute de la mod ‘ elisation des interactions support ‘ ees par un service Web n abordant les deux points de vue, structurel et comportemental. La section 4. donne un ‘ eclairage sur les principaux standards pour la comportementaux et non-fonctionnels des services. Dans la section 4. 4 nous d • ecrivons quelques outils existants pour la mise en œuvre de services Web. Finalement la section 4. 5 donne, en forme de conclusion, quelques perspectives faisant actuellement l’objet de recherches. Services Web : historique, d efinition, et principes Plusieurs d ‘ efinitions des services Web ont et’ e mises en avant par d’ff’ erents auteurs.
Ci-dessous, nous citons une d’ efinition g’ en ‘ eralement accept e et fournie par le consortium W3C CW3C-WSA-Group 20041 : A Web service is a software system designed to support interoperable machineto-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL 1 Other systems interact With Web Service Description Language 86 CHAPITRE 4. LES SERVICES WEB the Web service in a manner prescribed by its description using SOAP 2 messages, typically conve ed using HTTP With an XML serialization in coniunction eb-related standards. 2 OF SS protocoles sont aussi utilis ‘ es (voir Section 4,4).
Une etude plus approfondie des points communs partag es par es diff’ erentes d ‘ efinitions et par les usages qui sont faits des services Web, permet de d egager au moins deux principes fondamentaux : – Les services Web interagissent au travers d » echanges de messages encod• es en XML. Dans certains cas, les messages sont plut* ot transmis dans un encodage binaire, m *eme s’ils sont g’ en ‘ eralement produits et consomm ‘ es en XML ou en utilisant des Interfaces de programmation bas • ees sur les concepts d » el’ ement et d’attributco d’ efinis par le mod ‘ele dit « XML Infoset ». Les Interactions dans lesquelles les services Web peuvent s’engager sont d ‘ ecrites u sein d’interfaces. La d’ efinition W3C restreint la port ee des interfaces des sewices Web aux aspects fonctionnels et structurels, en utilisant le langage WSDL qui, essentiellement, ne permet de d • ecrire que des noms d’op erations et des types de messages.
Cependant, d’autres auteurs proposent d’aller plus loin et de consid erer aussi les aspects comportementaux et non-fonctionnels comme nous le verrons dans la section 4. 3. Par rapport a d’autres plates-formes pour le d • eveloppement d’applications distribu ees telles que CORBA (voir le chapitre 1) et Java RMI (voir le chapitre 5), l’une des diff’ erences rimordiales est que les services Web n’imposent pas de mod eles de programmation sp ecifiques.
En d’autres termes les services Web ne sont pas concern ‘ es par la fa,con d 3 OF SS aux vendeurs d’outils de d • eveloppement d’offrir diffi erentes m ‘ ethodes et interfaces de programmation au-dessus de n’importe quel langage de programmation, sans -etre contraints par des standards comme c’est le cas de CORBA qui d • efinit des ponts sp’ ecifiques entre le langage de d • efinition IDL4 et diff’ erents langages de programmation. Ainsi, les fournisseurs d’outils de d’ eveloppement peuvent acilement diff erencier leurs produits avec ceux de leurs concurrents en offrant diff erents niveaux de sophistication. ar exemple, il est possible d’offrir des environnements pour des m’ ethodes de programmation de services Web minimalistes au-dessus de plates-formes relativement ‘ eg• eres comme c’est le cas de NuSOAP (pour le langage PHP) ou d’Axis (voir la section 4. 4). En revanche, des plates-formes plus lourdes telles que BEA Webl_ogic, IBM Websphere ou . Net (voir le chapitre 6) offrent un environnement pour des m ‘ ethodes de d’ eveloppement tr’ es sophistiqu ees. 2 Simple Object Access Protocol
Il faut noter que WSDL et SOAP sont des standards d • efinls par le consortium W3C, ce qui explique que la d’ efinition ci-dessus essaye d’imposer ces standards. 4 Interface Deflnition Language 3 42. MODELISATION DE SERVICES WEB 87 4 OF SS description explicite des interactions entre les services Web, est aussi un point fort des services Web. Cependant, des efforts de recherche et de d ‘ eveloppement plus approfondis sont n ‘ ecessaires afin de r • eellement exploiter ce principe dans des outils ou des m ‘ ethodes de d • eveloppement.
En particulier, comme nous le discuterons dans la section 4. , l’usage des descriptions comportementales et non-fonctionnelles des services requi’ erent davantage d’attention de la part de la communaut’e de recherche. 4. 2 42. 1 M0d’ ellsation de services Web Points de vue dans la mod elisation de services Les sen,’ices Web interagissent les uns avec les autres par le biais d’envois de messages. Dans ce cadre, une interaction entre deux services, un client et un fournisseur, est d’ ecrite par un envoi de message par le client et la r • eception de ce message par le fournisseur.
De cette interaction peuvent d’ ecouler d’autres interactions, au cours desquelles les r- Oles de client et de fournisseurs peuvent s’inverser. Une s ‘ equence de telles interactions est appel ee une conversation De ce fait, la mod elisatlon de services Web met en jeu la description d’interactions et de leurs interd’ ependances aussi bien du point de vue structurel (types de messa s OF SS service donn e. Selon cette dimension, il est possible de distinguer trois types de mod eles de services : – Chor’ egraphie.
Une chor’ egraphie d’ ecrit, d’une part un ensemble d’interactions qu- peuvent ou doivent avoir lieu entre un ensemble de services (repr esent es de fa,con abstraite par des r » Oles), et d’autre part les d • ependances entre ces interactions. – Interface. Une interface d • ecrit un ensemble d’interactions dans lesquelles un service donn ‘ e peut ou doit s’engager et les d’ ependances entre ces interactions. Dans une interface, les interactions sont d ‘ ecrites du point de vue du service concern e sous forme d’actions communicationnelles, c’est- a-dire d’envols et de r • eceptions de messages.
Orchestration. Une orchestration d ‘ ecrit un ensemble d’actions communicationnelles et d’actions internes dans lesquelles un service donn ‘ e peut ou doit s’engager (afin de emplir ses fonctions) ainsi que les d • ependances entre ces actions. Une orchestration peut etre vue comme un raffinement d’une interface qui inclut des actions qui ne sont pas n ‘ ecessairement pertinentes pour les clients du service mais qui servent a’ remplir les fonctions que le service fournit et doivent donc etre prises en compte dans son implantation.
A titre d’exemple, la figure 4. 1 pr• esente une chor egraphie correspondant a’ un processus de gestion de commandes dans le domaine commercial. Afin de laisser la description de cette chor’ egraphie a’ un niveau abstrait, nous utilisons des diagrammes d’activit’e U OF SS actions correspondent a des interactions entre des r • Oles correspondant a • des types de service (client, fournisseur et entrep- ot en l’occurrence). Pour simplifier, pour chaque echange de message le diagramme montre soit l’envoi de ce message, soit la r’ eception, mais pas les deux.
Par exemple, dans ractivit•e « Commande », nous faisons r’ er erence a • l’envoi du Bon de Commande (BdC) par le client au fournisseur. Bien entendu, le fournisseur doit ex ecuteur l’action correspondant a la r ‘ eception de ce message, mais nous ne pr• esentons pas cette action duale dans le diagramme ‘activit es. Il est a remarquer aussi que les diagrammes d’activit ‘e permettent de mod’ eliser des aspects comportementaux, et en particulier des flots de contr- Ole- Ils ne permettent pas cependant de mod eliser des aspects structurels tels que les types de donn ‘ ees d’ ecrivant le contenu des messages • echang• es.
Ceux-ci peuvent -etre d ecrits au travers de diagrammes de classe mais nous omettons ces d etails car ils ne contribuent pas a’ la compr’ ehension du concept g’ en eral de chor ‘ egraphie. Client Fournisseur Commande [envoyer BdC à fournisseur] Entrepôt Vérification de Stock envoyer demande de dis OF SS trepôt transfert à fournisseur] Confirmation de Livraison [recevoir avis de livraison du client] Figure 4. 1 — une chori egraphie Il faut noter que la chor’ egraphie Pr’ esent ‘ ee dans la figure 4. n’adopte le point de vue d’aucun des services (ou plus pr ‘ ecis • ement des Oles) concern es. En effet, cette chor’ egraphie 89 inclut des interactions entre le client et le fournisseur, entre le fournisseur et son entrep- et entre l’entrep- ot et le client. Lorsqu’on passe a • des •etapes ult erieures dans le cycle de d ‘ eveloppement de services, on s’int eresse a • voir des nteractions du point de vue d’un service sp ecifique, comme par exemple un service cens e jouer le r » Ole de fournisseur dans l’exemple en question. Dans ce cas, on utilise la notion d’interface (voir chapitre 2).
Une interface de service d’ ecrit un ensemble d’interactions dans lesquelles un service donn • e peut ou doit s’engager. Le concept d’interface est d ‘ eriv• e des langages de programmation et des intereiciels a’ base d’appe ures tels que CORBA. 8 OF SS s equence correspond a’ une r • eception (par exemple Recevoir bon de commande) ou un envoi de message (par exemple Envoyer demande de disponibilit e). L’ensemble des types de messages echang es mod elisent la dimension structurelle de l’interface alors que le flot de contr- Ole exprim’e par la s’ equence mod’ elise la dimension comportementale de Pinterface.
Recevoir bon de commande Envoyer demande de disponibilité Recevoir avis de disponibilité Disponible Envoyer acceptation Envoyer bordereau d’expédition Non disponible Envoyer rejet Envoyer facture Recevoir copie d’ordre de transfert Figure 4. 2 – Interface correspondant au r- Ole de fournisseur dans la chor ‘ egraphle de la figure 4. 1 Selon que l’on se r’ er ere a’ l’interface qu’un service existant est apable de fournir, ou de l’interface qu’un service est cens e fournir dans le cadre d’une chor’ egraphie, on parle d’interface fournie ou d’interface re uise (voir chapitre 2).
Cinterface Pr’ esent’ ee d S l’interface fournie diff• ere de l’interface requise en deux points. Premi erement, alors que dans l’interface requise le service peut r’ epondre par une acceptation ou un rejet, dans l’interface fournie il r • epond avec le m ’eme type de message quel que soit le cas. Deuxi emement, dans l’interface requise, l’ordre d’exp ‘ edition et la facture sont envoy ‘ es dans n’importe quel ordre, alors que dans ‘interface requise l’envoi de la facture et la r • eception de l’ordre de paiement pr ‘ec edent l’envoi de l’ordre d’exp ‘ edition.
Dans ce contexte, il est n ecessalre de r • econcilier ces deux interfaces. Ce probl eme est connu sous le nom d’adaptation de services et fait l’objet de plusieurs efforts de recherche (voir section 4. 5. 1). Envoyer réponse à bon de commande Réponse négative Réponse positive Figure 4. 3 – Exemple d’interface fournie. Enfin, la figure 4. 4 pr ‘ esente une orchestration correspondant a l’interface de la figure 4. 3. Cette orchestration rajoute une action (indiqu ‘ ee en lignes point 0 DE SS
