THÈSE - LIMSIUNIVERSITÉPIERREETMARIECURIE PARISVI Laboratoire d’Informatique de Paris 6 THÈSE pour obtenir le titre de DOCTEUR DE L’UNIVERSITÉ PIERRE ET MARIE CURIE

UNIVERSITÉ PIERRE ET MARIE CURIEPARIS VI

Laboratoire d’Informatique de Paris 6

THÈSE

pour obtenir le titre deDOCTEUR DE L’UNIVERSITÉ PIERRE ET MARIE CURIE

Spécialité : Informatique

présentée par

Yasmine CHARIF

Chorégraphie dynamique de services basée sur lacoordination d’agents introspectifs

Thèse dirigée par Nicolas SABOURET

Soutenue publiquement le 10 décembre 2007 devant le jury composé de

Djamal BENSLIMANE (Pr.) Univ. Lyon I Examinateur

Stefano CERRI (Pr.) Univ. Montpellier II Examinateur

Amal EL FALLAH-SEGHROUCHNI (Pr.) Univ. Paris VI Directrice

Serge HADDAD (Pr.) Univ. Paris IX Rapporteur

Jean-Luc KONING (Pr.) INP, Grenoble Rapporteur

Jacques MALENFANT (Pr.) Univ. Paris VI Examinateur

Nicolas SABOURET (MCF) Univ. Paris VI Encadrant

“Mon paresseux bonheur qui longtemps sommeillaS’éveille.”

André Gide (Les nourritures terrestres).

4

Remerciements

Je suis très heureuse d’écrire ces remerciements réservés de coutume à l’abou-tissement de grands projets. Le mien fut ma thèse de doctorat.

Tout d’abord, je tiens à remercier et exprimer toute ma reconnaissance auprèsde mon encadrant Nicolas Sabouret. Il m’a initiée à la recherche dans un domainequi m’a toujours motivée. Méticuleux et perfectionniste, toujours disponible, profi-ler psychologique, il m’a prodigué des conseils inestimables, dans tous les domaines,tout au long de ma thèse. Je suis très fière de la formation de chercheuse acquisesous son encadrement.

Je remercie ma directrice de thèse, Amal El Fallah-Seghrouchni, qui m’aparrainée au commencement de cette thèse, non financée au départ. Ses commen-taires sur mon travail m’ont chaque fois permis de m’orienter dans les bonnesdirections. Au delà d’avoir été ma directrice de thèse, son aide précieuse et activem’a permis de dépasser des conditions personnelles pas toujours favorables. Je tiensà lui exprimer toute ma gratitude.

Finalement, c’est une seconde famille que j’ai trouvée au sein de notre équipeSMA.

Je remercie mon rapporteur Jean-Luc Koning pour l’honneur qu’il m’a accordéen acceptant d’évaluer ma thèse. Je suis très heureuse que mon travail ait trouvégrâce à ses yeux. Je le remercie également pour les commentaires très constructifsqu’il a formulés. Je remercie mon rapporteur Serge Haddad pour l’honneur qu’ilm’a accordé en acceptant également d’évaluer mon travail, et aussi pour m’avoirdonné plus de recul sur certains aspects que j’ai abordés.

Je souhaite remercier chaleureusement mon examinateur Stefano Cerri pourl’enthousiasme qu’il a manifesté à l’égard de ma thèse, ainsi que pour les com-mentaires détaillés dont il m’a fait part à propos de mon manuscrit. J’adresse mesremerciements à mon examinateur Djamal Benslimane pour avoir accepté de ma-nière si optimiste de faire partie de mon jury de thèse. À une époque de stress, celam’avait beaucoup encouragée. Je remercie également Jacques Malenfant pouravoir accepté d’examiner ma thèse et de présider mon jury.

L’équipe SMA, au sein de laquelle cette thèse est née et a évoluée, m’a pro-curé les conditions de travail les plus favorables. Tout y est : déjeuners bruyants,ambiance studieuse, pauses rigolades, sans oublier la gazette SMA où tous les com-mérages possibles et imaginables ont été colportés.

i

ii REMERCIEMENTS

Parmi les membres de cette équipe, j’adresse mes remerciements à Samir Ak-nine pour l’intérêt qu’il a porté à mon travail et pour ses relectures de plusieursparties de mon manuscrit. Je remercie vivement Zahia Guessoum pour les conseilsqu’elle ne manque pas de me prodiguer en toute occasion. Elle m’a également initiéeaux activités administratives en criant mon nom lorsque l’équipe faisait un appeld’offre pour le poste d’organisateur de séminaires. J’ai beaucoup appris grâce auxresponsabilités que j’ai eu à assumer. Je remercie Vincent Corruble pour m’avoirdonnée l’opportunité de donner mes premiers cours magistraux. Merci également àJean-Pierre Briot, Frederic Peschanski et Jean-Daniel Kant pour leurs conseilset leur bonhomie.

Que le travail de thèse aurait été austère sans l’ambiance créée par la complicitéet l’humour des doctorants de l’équipe : Zach Lewkovicz, une oreille attentiveà toute épreuve, Alessandro De Luna Almeida, toujours de retour de voyage,Hakim Belhaouari, un humour (qu’il trouve) très drôle, Carolina Felicissimo,jamais à court d’histoire de cœur, Nicolas Stefanovitch, agent double, ClémentPira, rédacteur en chef de la gazette SMA, et Thomas Béline, enquêteur auservice de la gazette. Je n’oublie pas les autres doctorants et docteurs avec qui ona partagé des moments de complicité : Miniar Hemaissia, Caroline Chopinaud,José Ghislain Quenum, Samuel Thiriot, Beiting Zhu, Joël-Alexis Bialkiewicz,Vinicius Seba Patto et Bruno Silvestre.

Je tiens par ailleurs à remercier Éric Platon pour ses relectures mais surtoutpour avoir ouvert la voie à la collaboration LIP6-NII. En dehors des workshopsque nous avons organisés dans le cadre de cette collaboration et grâce auxquels j’aibeaucoup appris, je suis très fière d’avoir pu effectuer un séjour à Tokyo au sein duNII. J’ai pu y rédiger 80% de mon manuscrit dans une ambiance ultra studieuse,mais j’y ai aussi vécu beaucoup d’aventures inoubliables. Je remercie le Pr. ShinichiHoniden pour m’avoir accueillie au NII. Merci à Jean-François Perrot pour sescommentaires avisés. Je remercie Julien Bourdaillet pour avoir toujours cruen moi durant nos rédactions simultanées et pour m’avoir tirée vers le haut lorsdes moments de doute. Merci à mes amis Isis Truck, Fabien Baligand, MichaelSchneider et à mon cousin Amir Djouama d’avoir été là lorsque j’en avais besoin.

Je remercie le staff administratif et technique du Pôle IA : Ghislaine, Jacque-line, Thierry, Jean-Pierre, Kevin, Christophe, Vincent et Konstantin, pour leursympathie, leur efficacité et leurs services rendus.

Je remercie les membres de ma petite et grande famille pour leur soutien in-défectible et leurs coups de fil/mails/sms d’encouragement. Mes remerciementss’adressent tout particulièrement à ma mère qui a surmonté le stress de sa propresoutenance de thèse (prévue 6 jours après la mienne) pour venir m’encourager.Je suis tellement heureuse qu’elle ait pu venir, sans parler des délicieux gâteauxalgériens qu’elle n’a pas manqué d’apporter pour mon pot de soutenance.

Résumé

La composition de services web est l’un des défis majeurs du paradigmeémergent SOC (Service Oriented-Computing). Les travaux existants proposent demodéliser cette problématique par l’orchestration de services. Cependant, ce typed’approche est centralisé autour d’un moteur de composition, et statique du faitque la composition de services suit un schéma prédéfini.

Dans ce contexte, l’objectif de cette thèse est de proposer une approche dyna-mique pour la composition de services. L’approche étudiée s’appuie sur la colla-boration décentralisée entre une collection de services dont le but est d’atteindreun objectif donné. C’est ce que l’on appelle la chorégraphie de services. Néan-moins, modéliser des capacités de collaboration au niveau des services nécessitequ’ils soient dotés de propriétés d’autonomie, d’adaptativité et d’interactivité. Cespropriétés, qui font défaut aux services web, ont par ailleurs été largement étudiéesdans les communautés agent et multiagent. Cependant, dans les modèles de co-ordination multiagent existants, aucune hypothèse n’est faite sur la manière dontles agents traitent leurs tâches. De plus, la décomposition des tâches y est faite apriori, et non pas en fonction des compétences disponibles.

Nous proposons alors dans cette thèse un modèle de coordination mul-tiagent, pour la chorégraphie de services web, dans lequel les capacités de collabora-tion des services sont modélisées à l’aide d’agents introspectifs. Ces agents sontcapables de raisonner sur leurs propres actions (ou sur les services qu’ils offrent),de décomposer dynamiquement une tâche en fonction de leurs compétences, et dese coordonner avec d’autres agents pour pallier leurs limites et couvrir les besoins àsatisfaire. Nous proposons alors une architecture orientée services basée sur un sys-tème multiagent ainsi qu’une formalisation des besoins de l’utilisateur en requêteset en contraintes globales. Nous définissons un modèle d’agent introspectif ainsiqu’un langage expressif de communication inter-agent. Nous spécifions un proto-cole d’interaction décentralisé et distribué pour la coordination des agents, dontnous vérifions les principales propriétés. Enfin, nous validons notre approche surdes scénarii du e-commerce, de l’intelligence ambiante et des services web.

Mots-clés

Systèmes multiagents, modèle de coordination, protocole d’interaction, servicesweb, chorégraphie de services, composition dynamique de services, intelligence am-biante.

iii

iv RÉSUMÉ

Abstract

The composition of web services is one of the challenges of the SOC (Ser-vice Oriented-Computing) emerging paradigm. Existing work propose to model thisproblem through service orchestration, that is defining an abstract plan which is ins-tanciated following the available concrete services, then executed by a compositionengine. However, the implemented approaches are centralized (on the compositionengine) and static since they follow a predefined plan.

In this context, our aim is to propose a dynamic approach for service compo-sition. We explore an approach relying on the decentralized collaboration of a setof services which aim is achieve a specific goal. The specification of such an ap-proach from a global point of view is known as service choreography. In our work,the services’ goal consists in satisfying human user needs. Nevertheless, modellingcollaboration capabilities among services requires the services to be provided withproactive, adaptive, and interactive properties. The latter have been well studied inagent and multi-agent systems’ communities. However, in existing multi-agentcoordination models, no assumption is made on the way the agents process theirtasks. Moreover, task decomposition is made a priori and not according to theavailable skills.

This is the reason why we propose in this thesis a multi-agent coordinationmodel for dynamic service choreography. In this coordination model, the services’collaboration capabilities are modeled through introspective agents capable toreason on their own actions (or on the services they offer), to dynamically take partto a task achievement, and to coordinate with other agents so as to overcome theirlimitations and cover the user needs to be satisfied. We present a service-orientedarchitecture based on a multi-agent system. We propose a model to formalize theuser needs. We specify a decentralized and distributed interaction protocol for theagents’ coordination, and verify its main properties. We define an algorithm toselect the services that best fit the user constraints. We analyze and validate ourcoordination protocol through ambient intelligence and web services use cases, andsum up our choreography approach on the web. Finally, we conclude this thesis byits main contributions, a discussion on the improvements to be provided and ourresearch work future directions.

Keywords

Multi-Agent Systems, Coordination Model, Interaction Protocol, Web Services,Service Choreography, Dynamic Service Composition, Ambient Intelligence.

v

vi ABSTRACT

Table des matières

Introduction 1SOC ou la programmation orientée services . . . . . . . . . . . . . 1

SOA ou les architectures orientée services . . . . . . . . . . 1Les services web . . . . . . . . . . . . . . . . . . . . . . . . 2

La composition de services . . . . . . . . . . . . . . . . . . . . . . . 3Limites des approches de composition de services . . . . . . 6Limites des services web . . . . . . . . . . . . . . . . . . . . 9

Les systèmes multiagents . . . . . . . . . . . . . . . . . . . . . . . . 9La coordination d’agents autonomes . . . . . . . . . . . . . 10

Entre coordination d’agents et chorégraphie de services . . . . . . . 11Proposition et organisation du manuscrit . . . . . . . . . . . . . . . 12

1 État de l’art 151.1 Composition de services . . . . . . . . . . . . . . . . . . . . . . . . 15

1.1.1 Catégories de la composition de services . . . . . . . . . . . 151.1.2 Approches pour la composition de services . . . . . . . . . . 161.1.3 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.2 Coordination multiagent . . . . . . . . . . . . . . . . . . . . . . . . 231.2.1 Généralités sur les systèmes multiagents . . . . . . . . . . . 231.2.2 Modèles de coordination d’agents, et applications à la com-

position de services . . . . . . . . . . . . . . . . . . . . . . . 231.2.3 Limites des modèles de coordination pour la chorégraphie de

services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.2.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2 SOA basée sur un SMA 312.1 Vue d’ensemble de l’approche de chorégraphie de services . . . . . 312.2 Description de l’architecture . . . . . . . . . . . . . . . . . . . . . . 32

2.2.1 “Agent cognitif offre service” (agent introspectif) . . . . . . 322.2.2 Architecture orientée services basée sur un SMA . . . . . . 33

2.3 Modèle des agents et leurs connaissances . . . . . . . . . . . . . . . 352.3.1 La base de données . . . . . . . . . . . . . . . . . . . . . . . 352.3.2 Les actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.3.3 Synthèse du modèle d’agent introspectif . . . . . . . . . . . 40

vii

viii TABLE DES MATIÈRES

2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3 Modèle de requêtes et ACL 433.1 Modèle de requêtes et besoins de l’utilisateur . . . . . . . . . . . . 43

3.1.1 Syntaxe des requêtes . . . . . . . . . . . . . . . . . . . . . . 443.1.2 Sémantique des requêtes . . . . . . . . . . . . . . . . . . . . 453.1.3 Formalisation des besoins de l’utilisateur . . . . . . . . . . . 49

3.2 Langage de communication entre agents . . . . . . . . . . . . . . . 523.2.1 Envoi de messages . . . . . . . . . . . . . . . . . . . . . . . 523.2.2 Contenu des messages . . . . . . . . . . . . . . . . . . . . . 523.2.3 Syntaxe des messages . . . . . . . . . . . . . . . . . . . . . 523.2.4 Construction des messages réponses . . . . . . . . . . . . . 53

3.3 Traitement des requêtes par le RPM . . . . . . . . . . . . . . . . . 543.3.1 Requêtes What-is . . . . . . . . . . . . . . . . . . . . . . . . 553.3.2 Requêtes Order . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4 Protocole de coordination 614.1 Comportement du SMA . . . . . . . . . . . . . . . . . . . . . . . . 61

4.1.1 Rôles et comportements des agents . . . . . . . . . . . . . . 624.1.2 Trace des interactions . . . . . . . . . . . . . . . . . . . . . 634.1.3 En sortie du processus de coordination . . . . . . . . . . . . 64

4.2 Scénario d’illustration . . . . . . . . . . . . . . . . . . . . . . . . . 654.2.1 Requêtes de l’utilisateur . . . . . . . . . . . . . . . . . . . . 654.2.2 Agents participants et leurs compétences . . . . . . . . . . . 664.2.3 Dépendances entre les requêtes . . . . . . . . . . . . . . . . 674.2.4 Résolution par le RPM . . . . . . . . . . . . . . . . . . . . . 67

4.3 Règles dialectiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.3.1 Traitement du message initiateur . . . . . . . . . . . . . . . 694.3.2 Construction et envoi des messages réponses . . . . . . . . . 714.3.3 Traitement des messages réponses . . . . . . . . . . . . . . . 734.3.4 Détection d’attributs non fournis par l’utilisateur . . . . . . 91

4.4 Évaluation analytique du protocole . . . . . . . . . . . . . . . . . . 914.4.1 Terminaison . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.4.2 Complexité de communication . . . . . . . . . . . . . . . . . 934.4.3 Complexité calculatoire . . . . . . . . . . . . . . . . . . . . 94

4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

5 Services compatibles 975.1 Problème . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.1.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 975.1.2 Formulation du problème . . . . . . . . . . . . . . . . . . . 100

5.2 Scénario d’illustration . . . . . . . . . . . . . . . . . . . . . . . . . 1015.3 Résolution du problème . . . . . . . . . . . . . . . . . . . . . . . . 103

5.3.1 Construction des offres . . . . . . . . . . . . . . . . . . . . . 1035.3.2 Sélection des offres optimales . . . . . . . . . . . . . . . . . 110

TABLE DES MATIÈRES ix

5.4 Complexité calculatoire de la solution . . . . . . . . . . . . . . . . 1115.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

6 Expérimentations 1156.1 Expérimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.1.1 Travail effectué . . . . . . . . . . . . . . . . . . . . . . . . . 1156.1.2 Scénario d’AmI . . . . . . . . . . . . . . . . . . . . . . . . . 1176.1.3 Scénario de services web . . . . . . . . . . . . . . . . . . . . 126

6.2 Synthèse de l’approche de chorégraphie . . . . . . . . . . . . . . . . 1366.2.1 Publication des services . . . . . . . . . . . . . . . . . . . . 1366.2.2 Découverte des services . . . . . . . . . . . . . . . . . . . . 1416.2.3 Invocation et chorégraphie de services . . . . . . . . . . . . 142

6.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Conclusion et perspectives 145

x TABLE DES MATIÈRES

Table des figures

1 Services web fondés sur les fonctions Publier, Trouver, Invoquer. . . 42 Chorégraphie de services pour la commande et la livraison d’un pro-

duit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Interface de comportement de l’action Payer pour le rôle client. . . 54 Orchestration de services pour le rôle fournisseur. . . . . . . . . . . 6

1.1 Classification des travaux en composition de services. . . . . . . . . 17

2.1 Vue d’ensemble de l’approche de chorégraphie. . . . . . . . . . . . . 322.2 Structure d’un agent offrant un service. . . . . . . . . . . . . . . . 342.3 Architecture combinant technologies agents et services web. . . . . 35

4.1 Comportement du SMA. . . . . . . . . . . . . . . . . . . . . . . . . 624.2 Graphe de dépendances entre les requêtes. . . . . . . . . . . . . . . 674.3 Protocole pour le traitement des réponses Missing. . . . . . . . . . 744.4 Protocole pour le traitement des réponses Unknown. . . . . . . . . 764.5 Protocole pour le traitement des commandes Order. . . . . . . . . . 804.6 Protocole pour la décomposition d’une commande Order. . . . . . . 804.7 Protocole pour le traitement des réponses Assert-can. . . . . . . . . 824.8 Protocole pour le traitement des requêtes What-is. . . . . . . . . . 844.9 Protocole pour le traitement des assertions Assert-is. . . . . . . . . 894.10 Arbre défini par notre protocole. . . . . . . . . . . . . . . . . . . . 92

6.1 Interface où l’utilisateur entre ses besoins. . . . . . . . . . . . . . . 1186.2 Extrait de la base de données de l’agent television. . . . . . . . . . . 1186.3 Extrait de l’action de l’agent dvdrecorder. . . . . . . . . . . . . . . . 1196.4 Message initiateur pour le scénario d’AmI. . . . . . . . . . . . . . . 1206.5 Traces des interactions capturées par le sniffer (scénario d’AmI). . 1216.6 Requête What-is construite par l’agent dvdrecorder après décompo-

sition de la commande de l’utilisateur. . . . . . . . . . . . . . . . . 1226.7 Assertion Assert-is envoyée par l’agent television à l’agent dvdrecorder. 1236.8 Résolution des besoins de l’utilisateur pour le scénario d’AmI. . . . 1246.9 Extrait du code de l’agent UIFVideoProvider. . . . . . . . . . . . . . 1276.10 Extrait du code de l’agent UIFtoMPEGConverter. . . . . . . . . . . 1286.11 Extrait du code de l’agent MovieJacketDisplayer. . . . . . . . . . . . 1286.12 Extrait du code de l’agent Scenario2VideoSeller. . . . . . . . . . . . 1296.13 Début du sniffer pour le scénario services web. . . . . . . . . . . . . 130

xi

xii TABLE DES FIGURES

6.14 Suite du sniffer pour le scénario services web. . . . . . . . . . . . . 1316.15 Message initiateur pour le scénario 2. . . . . . . . . . . . . . . . . . 1316.16 Message réponse de l’agent UIFVideoProvider. . . . . . . . . . . . . 1326.17 Résolution de la requête r1 par l’agent UIFtoMPEGConverter. . . . 1326.18 Message regroupant des requêtes Missing envoyées aux mêmes des-

tinataires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1336.19 Assertions pour les requêtes Missing reçues. . . . . . . . . . . . . . 1336.20 Résolution de la requête r2 par l’agent MovieJacketDisplayer. . . . . 1336.21 Résolution de la requête r3 par l’agent VideoSeller et VideoSeller2. . 1346.22 Interface WSDL d’un service. . . . . . . . . . . . . . . . . . . . . . 1376.23 Modèle de données UDDI. . . . . . . . . . . . . . . . . . . . . . . . 1386.24 Génération d’interfaces WSDL dans notre architecture. . . . . . . . 1406.25 Mapping WSDL ← VDL-XML → UDDI. . . . . . . . . . . . . . . 140

Liste des tableaux

3.1 Syntaxe et sémantique du modèle de requêtes. . . . . . . . . . . . . 463.2 Requêtes et leurs réponses correspondantes construites par le RPM. 55

4.1 Les requêtes de l’utilisateur. . . . . . . . . . . . . . . . . . . . . . . 664.2 Répartition des compétences des agents. . . . . . . . . . . . . . . . 674.3 Les réponses des agents participants construites par le RPM. . . . 684.4 Les réponses des agents participants envoyées à l’agent de l’utilisateur. 88

5.1 Les requêtes de l’utilisateur (scénario des contraintes globales). . . 1015.2 Liste de propositions candidates (scénario des contraintes globales). 1025.3 Tableau de propositions PTab (scénario des contraintes globales)

avant l’application de la fonction setAssoProposals. . . . . . . . . 1055.4 Tableau de proposition PTab (scénario des contraintes globales). . 106

6.1 Résultats expérimentaux sur le scénario 1. . . . . . . . . . . . . . . 1256.2 Resultats expérimentaux sur le scénario 2. . . . . . . . . . . . . . . 135

xiii

xiv LISTE DES TABLEAUX

Introduction

L’évolution des réseaux informatiques combinée à celle des systèmesinformatiques a permis la mise en œuvre de systèmes distribués de plus en plusperformants et le développement d’applications de toute sorte s’appuyant sur cesinfrastructures. Les systèmes informatiques distribués recouvrent un champ trèsvaste dont font partie les grilles de calcul, le stockage d’informations dans desréseaux de pairs, le déploiement d’applications web, etc.

L’évolution de plateformes à composants distribués (ex. les EJB de Sun ouencore .NET de Microsoft) a donné naissance à un nouveau mode de développementlogiciel appelé SOC.

SOC, acronyme de Service Oriented-Computing, désigne ce para-digme de programmation émergeant, pour le développement de sys-tèmes d’informations distribués, dans lequel les concepts de distri-bution, d’ouverture, de messagerie asynchrone et de faible couplagetiennent un rôle primordial [99, 114].

Dans ce contexte, les applications sont construites à partir de services indi-viduels exposant leurs fonctionnalités à travers des registres et s’abstrayant com-plètement de leur implémentation sous-jacente. Leurs interfaces publiées peuventalors être recherchées et invoquées par des utilisateurs ou d’autres services.

L’avantage de SOC est qu’il permet de créer des systèmes d’information enagrégeant des services individuels. En effet, il permet de créer des systèmes d’infor-mation inter- et intra-entreprises de manière relativement aisée en “serviçant” lessystèmes existants, d’accomplir interopérabilité et transparence entre ces systèmesau fil de l’eau, de sélectionner dynamiquement des services sur la base de critères dequalité de services personnalisés par chacun et d’utiliser efficacement les ressourcesde grilles.

SOA ou les architectures orientées services

Les besoins de SOC pour la satisfaction des précédents cas d’usage peuventêtre plus facilement satisfaits à travers une architecture répondant aux propriétésrequises. Une telle architecture est appelée SOA ou architecture orientée services.

1

2 INTRODUCTION

Une architecture orientée services, calque de l’anglais ServiceOriented Architecture, ou SOA, est une architecture logicielle s’ap-puyant sur un ensemble de services simples. Son objectif est de dé-composer une fonctionnalité en un ensemble de fonctions basiques(les services) fournies par des composants et de décrire le schémad’interaction entre ces services [83].

Dans une SOA, les services peuvent communiquer entre eux. Cette communi-cation peut soit consister en un simple passage de données ou impliquer la coordi-nation de deux ou plusieurs services pour l’accomplissement d’une activité. Il fautalors définir des moyens pour connecter les services entre eux.

Beaucoup considèrent que la première SOA est apparue avec l’utilisation desDCOM 1 ou ORB 2 basés sur les spécifications de CORBA.

Cependant, la principale différence entre SOA et les autres architectures distri-buées, telles que CORBA, est le faible couplage des services par l’expression des“interactions” entre les services. En effet, le point de départ des spécifications SOAa été le besoin croissant de sélectionner et d’intégrer, au fil de l’eau, des serviceshétérogènes et inter-organisationnels, aussi bien à travers le web qu’au sein d’envi-ronnements intelligents et pervasifs. Toutefois, là où CORBA se concentre sur lesobjets pour créer un environnement de programmation distribué, SOA se focalisesur les documents et l’interopératibilité des processus métiers entre partenaires etconsommateurs à travers l’Internet moyennant des transactions à long terme (etpas seulement des transactions à court terme).

Les services web

Afin de mettre en œuvre une SOA, il est essentiel d’avoir une compréhensionclaire de ce qu’est un service web.

À l’origine, la technologie des services web a été initiée par IBM et Microsoft,puis en partie normalisée sous l’égide du W3C 3, l’organisme chargé de standardiserles évolutions du web. Elle est maintenant acceptée par l’ensemble des acteurs del’industrie informatique, faisant des services web une technologie révolutionnaire[53].

Un service web est concrètement un ensemble de fonctionnalités exposées surun réseau. Ces fonctionnalités sont bien définies, auto-contenues et ne dépendentni du contexte ni de l’état d’autres services.

Un service web est un composant logiciel accessible à travers desintranets, des extranets et l’Internet moyennant des technologies webet un système standard de messagerie basé sur XML [5].

1. DCOM pour Distributed Component Object Model.2. ORB pour Object Request Brokers.3. Le World Wide Web Consortium, abrégé W3C, est un consortium fondé en octobre 1994,

par Tim berners Lee, pour promouvoir la compatibilité des technologies du World Wide Webtelles que HTML, XHTML, XML, CSS, PNG, SVG et SOAP. Le W3C n’émet pas des normes,mais des recommandations.

3

L’avantage des services web, par rapport aux autres approches de systèmes dis-tribués tel que RMI (pour Remote Method Invocation), réside dans leur supportdes pare-feux, mais surtout dans leur articulation autour d’XML (standard pro-mulgué par le W3C), ce qui leur procure l’avantage d’être non propriétaire et ainsimultiplateforme.

Les services web varient en complexité de simples opérations telles que la véri-fication en ligne du solde d’un compte bancaire, des services domotiques d’enregis-trement et de diffusion de programmes audiovisuels, des services en ligne d’agencesde voyages, à des systèmes complexes de type CRM (customer relationship mana-gement) [12], ERP (enterprise resource planning) [60], etc.

Techniquement parlant

La travaux dans le domaine des services web ont rendu possible la publication,la découverte et l’invocation d’applications à travers le web. Ainsi, les services websont actuellement basés sur la triade de fonctions illustrées sur la figure 1. Leurarchitecture repose sur les principes et standards suivants :

– Un service web est identifié par une chaîne de caractère appelée URI (UnifiedResource Identifier), dont la syntaxe respecte une norme d’Internet mise enplace par le W3C.

– L’interface publique du service et les liaisons sont définies et décrites en XML,généralement en WSDL [33]. Un document WSDL, pour Web Service Des-cription Language, est une description basée sur XML indiquant le protocolede communication et le format de messages requis pour communiquer avecun service.

– La définition du service peut alors être découverte par d’autres systèmes lo-giciels au travers de registres tels que UDDI [1]. Ce modèle, acronyme deUniversal Description Discovery and Integration, est une technologie d’an-nuaire basée sur XML permettant de localiser sur le réseau un service webrecherché.

– Les applications et systèmes peuvent alors interagir avec le service web d’unemanière prescrite par les protocoles Internet [21], usuellement SOAP [125](pour Simple Object Access Protocol) qui est un protocole permettant l’échanged’informations structurées dans un environnement decentralisé et distribué.Il a été conçu indépendamment de tout modèle de programmation et autresémantique spécifique d’implémentation.

La composition de services

Un des défis des SOA est l’intégration de services ou de systèmes distribuéspour l’approvisionnement de nouveaux services personnalisés, plus riches et plusintéressants aussi bien pour des applications, d’autres services ou plus communé-ment pour des utilisateurs humains.

En effet, si une application ou un client requièrent des fonctionnalités, et qu’au-cun service n’est seul apte à les fournir, il devrait être possible de combiner ou de

4 INTRODUCTION

Figure 1 – Services web fondés sur les fonctions Publier, Trouver, Invoquer.

composer des services existants afin de répondre aux besoins de cette applicationou de ce client [87, 106]. C’est ce que l’on appelle la composition de services[59].

La composition de services vise à faire interopérer, interagir etcoordonner plusieurs services pour la réalisation d’un but.

Les travaux du domaine [10, 36, 102] identifient trois angles sous lesquelles cettecoordination peut être décrite : la chorégraphie, l’interface de comportementet l’orchestration.

La chorégraphie décrit la collaboration entre une collection deservices dont le but est d’atteindre un objectif donné. L’accomplisse-ment de ce but commun se fait alors par des échanges ordonnés demessages [8].

La chorégraphie de services dépeint les interactions dans lesquelles les servicesengagés participent afin d’atteindre cet objectif, ainsi que les dépendances entreles interactions telles que le flot de contrôle (ex. une interaction doit précéder uneautre), le flot de données, les corrélations des messages, les contraintes de temps,les dépendances transactionnelles, etc.

La figure 2 représente la chorégraphie des services client, fournisseur et en-trepôt pour la commande et la livraison d’un produit. Elle est représentée sousla forme d’un diagramme d’activités UML. Les actions élémentaires dans ce dia-gramme représentent des activités impliquant l’envoi et la réception de messages.Par exemple, l’action Commander produit, entreprise par le client, résulte en l’envoid’un message au fournisseur.

Un modèle de chorégraphie n’est pas exécutable. Il constitue en fait un accordentre des parties, où celles-ci spécifient comment leur collaboration doit se dérouler.Cette convention peut être établie par une consultation commune ou conçue parun comité de standardisation.

WS-CDL [74] est un exemple de langage pour la description de chorégraphies.

5

Figure 2 – Chorégraphie de services pour la commande et la livraison d’un produit.

L’interface de comportement décrit le comportement interne d’unservice [10].

L’interface de comportement complémente l’interface structurelle d’un service(ex. l’interface WSDL où les interactions élémentaires et les types des messagessont décrits). Elle capture les dépendances de flot de contrôle, les dépendances deflot de données, les contraintes de temps, etc.

Une chorégraphie peut être utilisée pour générer l’interface de comportementque les services devraient fournir afin de participer à la collaboration, ou alorsvérifier si une interface de comportement d’un service existant est conforme à unechorégraphie.

La figure 3 montre un exemple de l’interface de comportement de l’action Payerpour le rôle client dans la chorégraphie de la figure 2.

Figure 3 – Interface de comportement de l’action Payer pour le rôle client.

L’orchestration décrit, du point de vue d’un service, les interac-tions de celui-ci ainsi que les étapes internes (ex. transformationsde données, invocations à des modules internes) entre ses interac-tions [102].

6 INTRODUCTION

Dans une orchestration, le chef d’orchestre est donc le service dont les inter-actions sont dépeintes. Celles-ci comprennent l’envoi et la réception de messagesà/de la part de partenaires sélectionnés. L’orchestration permet ainsi à un ser-vice d’être enchaîné à d’autres d’une manière prédéfinie. Elle est ensuite exécutéepar des scripts d’orchestration qui décrivent les interactions entre les applicationsen identifiant les messages, la logique et les séquences d’invocations. Le composantexécutant les scripts d’orchestration est appelé moteur d’orchestration. Celui-ci agitcomme une entité centralisée pour coordonner les interactions entre les services.

La figure 4 illustre, du point de vue du service fournisseur, l’orchestration desservices de l’exemple précédent. Notons que les noms d’action dans ce schéma d’or-chestration (ex. Vérifier disponibilité) peuvent différer de ceux apparaissantdans le schéma de chorégraphie (ex. Vérifier stock dans la figure 2). En effet, lesactions dans un schéma d’orchestration sont instanciées en fonction de la structuredu service dont l’orchestration est spécifiée.

Par ailleurs, un schéma d’orchestration organise des interfaces de comporte-ments de plusieurs actions et dépeint en plus les actions internes du service (enpointillés sur la figure 4).

Il est à noter qu’une interface de comportement peut être utilisée comme pointde départ pour générer un squelette d’orchestration qui sera ensuite complété pard’autres actions et des détails d’actions internes.

WS-BPEL [67] et ebXML [94] sont des exemples de langages d’orchestration.

Figure 4 – Orchestration de services pour le rôle fournisseur.

Limites des approches de composition de services

Les récentes recherches en composition de services ont concentré leurs effortsdans la résolution de procédures génériques, c’est-à-dire les cas d’étude où leprofil des services à composer ainsi que le schéma de composition sont préala-blement déterminés par un expert. C’est par exemple le cas de l’organisation d’unvoyage (où sont composés des services de gestion du transport, de réservation d’hô-tel, etc), ou alors la recherche de la meilleure proposition de crédit (impliquant larecherche d’une assurance pour l’emprunteur, le paiement complémentaire avec uncompte sur livret, etc), ou encore en immunologie, la détection d’une pathologie“lupus” (impliquant la caractérisation des AA de la jonction des anticorps, etc).

Les procédures génériques représentent des besoins communs ou fréquents d’ap-plications ou d’utilisateurs tels que les services impliqués dans la composition, ainsique leur enchaînement, peuveut être étudiés et prédits par un expert, celui-là mêmequi fournit le schéma de composition.

7

Ainsi, ce que l’on appelle communément résolution de procédures génériquesconsiste en fait à procéder à l’enchaînement automatique de processus métiers,ou en anglais business process.

Un processus métier référence :1. une transaction nécessitant des informations ou le changement

d’une donnée dans une base de données ;2. un évènement spécifique dans une chaîne d’activités structu-

rées impliquant le changement de l’état des données et/ou d’unproduit et générant des résultats en sortie.

Un processus métier peut par exemple être la réception d’une com-mande, une facturation, la livraison de produits, la mise à jour desinformations sur des employés, etc.

Ainsi, les approches proposées pour la composition de services visent à satis-faire les cas d’usage précités (i.e. les procédures génériques) par l’orchestration oul’enchaînement de processus métiers. Dans ces approches, un schéma d’orchestra-tion, spécifié par un expert, est associé à chaque procédure générique à satisfaire.Chaque schéma regroupe les profils (ex. service d’hôtellerie) ou les identifiants desservices à composer, ainsi que leur enchaînement (ex. séquence d’appel des actionsdes services). Lorsque l’utilisateur requiert l’exécution de l’une de ces procéduresgénériques (ex. organisation d’un voyage), le schéma d’orchestration donné a prioriest instancié en fonction des services concrets disponibles et ensuite exécuté.

Suite à cela, les solutions existantes procèdent à une sélection de services.

La sélection de services est la décision de choisir des services enparticulier parmi un ensemble de services sur la base de besoinsfonctionnels ou des paramètres de qualité de services 4, ex. sélec-tionner un service de traduction en ligne.

Il est tout de même à noter que ces approches de composition de servicesprésentent plusieurs limites dont voici les deux plus récurrentes :

1. Les orchestrations spécifient des schémas de composition ad hoc où les ser-vices à composer sont présélectionnés, et le flot de contrôle préalablementspécifié (dans le chapitre 1, nous parlerons de composition statique).Ainsi, si un des services participant à une orchestration n’est pas disponible,le schéma de composition n’est alors plus valide.Des inconsistances peuvent de plus survenir à cause de l’approvisionnementde nouveaux services ou du remplacement d’anciens services par d’autres.Par exemple, le flot de contrôle des interactions avec ces nouveaux servicesne deviendrait plus valide et pourrait nécessiter des adaptation en fonctionde leur interface structurelle.

4. La qualité de service, en anglais Quality of Service ou QoS, est l’aptitude d’un serviceà répondre adéquatement à des exigences, exprimées ou implicites, qui visent à satisfaire sesusagers. Ces exigences peuvent être liées à des paramètres tels que l’accessibilité, la disponibilité,la maintenabilité, le temps de réponse, le coût, la fiabilité, etc.

8 INTRODUCTION

2. Comme nous l’évoquions plus haut, les approches existantes de compositionde services proposent des solutions pour la satisfaction de procédures géné-riques. Ces cas d’usages sont ainsi ceux où les besoins des utilisateurs sontcommuns et peuvent être connus à l’avance (ex. packages proposés par desagences de voyage à des clients ayant des besoins prévisibles en transport,hébergement, etc). C’est d’ailleurs la raison pour laquelle ces approches selimitent à un schéma d’orchestration prédéfini pour décrire les besoins (préa-lablement connus) de l’utilisateur.Cependant, l’utilisateur peut également être dans une configuration ou, aucontraire, il a besoin d’émettre des demandes personnalisées et totalementimprévisibles par un expert. Par exemple, organiser un emménagement (oùpourraient être composés des services de décoration, de vente de meubles etde livraison), se procurer un ensemble de matériels informatiques (qui pour-raient présenter contraintes de compatibilité, de coût ou de marque que lesservices à composer doivent respecter), ou même personnaliser sa maison in-telligente (où pourraient être composées les fonctionnalités d’un téléphoneet d’une télévision pour afficher l’identité des appelants), etc. Contrairementaux procédures génériques, ces cas d’usage sont des exemples de demandesd’utilisateur peu communes (car personnalisées) et imprévisibles par un ex-pert.D’un point de vue synthétique, les requêtes de l’utilisateur peuvent :– porter sur toutes sortes de questions, commandes, demandes de devis, etc.– comporter diverses contraintes sur les services demandés, qu’elles soient

locales comme une marque ou une capacité de stockage, ou globales tellesque le coût total d’une commande ou la durée totale d’un itinéraire, etc.

– présenter des interdépendances entre les sous-requêtes, que ce soit à proposde ressources, de contraintes de simultanéité, des relations entre des tâcheset sous-tâches, etc.

Or, les travaux existants ne fournissent ni un modèle pour représenter detels besoins (qu’ils décrivent à travers des schémas), ni une architecture deservices capables de raisonner sur ces besoins, et encore moins des modèlesde collaboration dynamique entre les services pour la satisfaction de ces be-soins (puisque la composition dans les approches existantes est le résultat del’exécution d’un schéma).

En conséquence, dans le contexte d’environnements dynamiques tels que le webou l’informatique pervasive, où les services changent et les besoins des utilisateursvarient et ne peuvent pas tous être prévus à l’avance par un expert, la découvertedes services doit se faire à la volée et la chorégraphie de ceux-ci, au lieu d’être préa-lablement fournie à travers un schéma de composition, doit s’effectuer de manièredynamique en fonction des besoins énoncés par l’utilisateur, des caractéristiquesfonctionnelles et structurelles des services découverts et des interactions résultantesde ceux-ci.

C’est dans ce contexte de chorégraphie de services que s’inscrit notre travail.En effet, notre objectif est de proposer une approche de chorégraphie de services

9

prenant en compte à la fois :– des besoins ouverts d’utilisateurs, qui contrairement aux procédures géné-

riques, doivent pouvoir être personnalisés et donc comporter des contrainteslocales et globales sur les services demandés, porter sur des questions oudes commandes et pouvoir présenter des interdépendances entre les sous-requêtes ;

– l’ouverture et la distribution de l’environnement des services ;– la construction dynamique de la collaboration (ou coordination) des services

par l’agencement de ces derniers sur la base de leurs fonctionnalités et desbesoins à satisfaire.

Limites des services web

Comme nous le citions précédemment, il existe des langages pour la spécifica-tion de composition (orchestration ou chorégraphie) de services. Cependant, aucunstandard n’a été promulgué pour la composition de services. En comprendre lesraisons nécessite de revenir aux sources en identifiant les limites intrinsèques auxservices web [62] :

– Les services web sont passifs jusqu’à ce qu’ils soient invoqués ;– Un service web a seulement connaissance de lui-même, mais pas de ses ap-

plications ou utilisateurs clients ;– Un service web n’est pas adaptable, et il n’est pas capable de bénéficier des

nouvelles capacités de l’environnement afin d’apporter des services améliorés ;– Enfin, la plus grande limite des services web est qu’il n’existe actuellement

aucun standard pour supporter la composition de leurs fonctionnalités.

L’autonomie, l’adaptation et la coopération, points faibles des services web,sont par ailleurs des domaines qui ont largement été explorés par la recherche dansles systèmes multiagents. Plusieurs études décrivent à ce propos la pertinence dela combinaison des technologies agent et services web [7, 15, 63, 73, 90, 96].

Dans ce qui suit, nous faisons une brève présentation des systèmes multiagentset de la coordination multiagent. Nous rapprochons les domaines de la chorégraphiede services et de la coordination multiagent avant d’esquisser notre proposition pourla conception d’une approche dynamique et automatique pour la chorégraphie deservices.

Les systèmes multiagents

Les systèmes multiagents sont l’une des dernières générations de systèmes in-formatiques intelligents. Émergeant de la recherche en intelligence artificielle distri-buée dans les années quatre-vingt, les systèmes multiagents constituent aujourd’huiune grande part de la recherche et du développement de l’intelligence artificielle etde la programmation distribuée.

10 INTRODUCTION

Un système multiagent est défini comme un ensemble d’agentsautonomes ayant un ou plusieurs buts à accomplir et qu’ils œuvrentà atteindre en exécutant concurremment une ou plusieurs tâches.

La notion d’agent, sur laquelle se fondent les systèmes multiagents, s’est vuedonner des définitions par plusieurs auteurs [47, 71, 129]. Ce qu’il faut en retenirc’est qu’un agent, contrairement à d’autres programmes, doit au moins simultané-ment être :

1. situé : il perçoit le monde/environnement dans lequel il se situe ;2. autonome : il prend des décisions et agit sur son environnement en vue d’at-

teindre son objectif ;3. interactif : il a la capacité d’interagir avec d’autres agents ;

La coordination d’agents autonomes

Partageant un espace commun, usuellement appelé environnement, les agentssont amenés à coopérer pour s’aider mutuellement dans l’accomplissement de leursobjectifs, partager leurs ressources, résoudre les conflits éventuels ou les éviter,etc. Ceci amène les agents à se coordonner afin de pouvoir évoluer en complètesynergie dans cet environnement [3]. En conséquence, des interactions prennentplace afin que ces agents déterminent l’organisation la plus appropriée (qui faitquoi) et communiquent les résultats de leur coopération (quand et à qui).

La coordination est un processus d’agencement et de répartitiondes actions d’un système distribué en vue d’atteindre un objectif dé-terminé ou d’obtenir une meilleure rentabilité des composants dusystème.

Selon Malone et Crowston, la coordination peut également être définie commeétant la gestion des interdépendances entre les activités [84]. Ces interdépendancespeuvent concerner des ressources partagées, des contraintes de simultanéité, desrelations entre producteur/consommateur, des tâches/sous-tâches, etc.

Dans ce contexte, le rôle d’un agent est de construire des solutions, seul ou encoopération avec d’autres agents, qui tiennent compte des interdépendances et descontraintes spécifiques au problème traité et qui soient en plus en mesure d’assurerune cohésion avec l’ensemble des agents qui partagent son environnement.

Au vu de la contrainte de distribution dans les systèmes multiagents, c’est-à-dire qu’il n’existe aucun contrôle centralisé et que les agents sont totalementautonomes dans leur choix d’actions et de décisions en général, la coordination estainsi assurée de façon complètement distribuée au travers de mécanismes tels queles négociations automatiques [3, 118].

Par ailleurs, il existe actuellement diverses formes et mécanismes de coordi-nation ; de la coordination implicite, comme dans les communautés biologiques(par exemple, les fourmis), à la coordination explicite à travers des mécanismesde raisonnement formalisés et surtout plus élaborés. Ces mécanismes recourent àl’utilisation de la communication explicite par envoi de messages dont la syntaxe

11

et la sémantique sont régies par des standards de communication tels que KQML[48], FIPA ACL [51], etc.

Entre coordination d’agents et chorégraphie de services

Les services web partagent avec les systèmes multiagents plusieurs propriétésdont les méthodologies agents tiennent explicitement compte dans leur ébauche desolutions. De telles propriétés sont [96] :

La distribution géographique et/ou logique d’entités, données ou informationshétérogènes ;

La complexité du problème global à résoudre, celui-ci n’étant manipulable quepar des stratégies heuristiques utilisant des données ou connaissances locales ;

La flexibilité des interactions il n’y a pas d’affectation a priori des tâches etles mécanismes de résolution de problèmes ne sont pas préalablement assignésà telle ou telle autre entité ;

L’environnement dynamique nécessitant, pour la résolution de problèmes, desentités réactives et adaptative ;

L’ouverture il n’est pas possible de donner une spécification complète du pro-blème à résoudre ni de définir une fonction d’utilité globale.

En outre, les services web sont souvent des interfaces de programmes orientésobjet (développés via J2EE ou .NET) traités pour générer des descriptions WSDLafin de pouvoir communiquer avec des messages SOAP. Ils bénéficient alors descaractéristiques d’abstraction du paradigme orienté objet (encapsulation, héritage,passage de messages, etc). L’une des majeures évolutions de SOA et SOC consiste àremplacer le noyau orienté objet des services par un noyau orienté agent [21, 62, 63,73]. Les services tiendraient alors compte du contexte d’ouverture et de distributionde l’environnement, bénéficieraient des caractéristiques de proactivité, flexiblité etd’adaptativité des agents, et deviendraient de plus réellement interactifs. En outre,comme les agents peuvent potentiellement participer à des interactions complexestout en maintenant la coordination avec leurs accointants, les services pourraientêtre dotés des pré-requis pour la modélisation d’une collaboration dynamique entreservices.

En conséquence, les systèmes multiagents semblent alors être particulièrementbien adaptés à la modélisation des problématiques (de distribution, d’ouverture,de flexibilité et de collaboration des services) sous-tendues par la chorégraphie dy-namique de services. C’est la raison pour laquelle l’objet de notre étude va portersur l’étude de solutions SMA pour la modélisation des problématiques de choré-graphique de services. Plus précisément, notre travail a pour but de définir desmécanismes de coordination multiagent, supportant des interactions flexibles desagents pour la satisfaction de besoins en services énoncés par des utilisateurs, dansles contextes ouverts et décentralisés du web et de l’intelligence ambiante. Notreobjectif est alors de spécifier ces mécanismes dynamiques de coordination, vérifier

12 INTRODUCTION

leurs comportements, notamment la complexité calculatoire et de communication,et les adapter pour le contexte des services web.

Proposition et organisation du manuscrit

L’approche de chorégraphie de services que nous voulons concevoir se veut :– automatique, i.e. n’ayant (autant que faire se peut) pas recours à l’utilisateur

pour la sélection et la combinaison des services appropriés ;– et dynamique, i.e. les services existants sont disponibles dans un environne-

ment ouvert tel que le web ou l’intelligence ambiante, et sont découverts etcomposés à la volée, en fonction des besoins de l’utilisateur et de leurs fonc-tionnalités, par le biais de mécanismes de coordination explicite d’agents.

La conception d’une telle approche nécessite de disposer de services capablesde déterminer s’ils peuvent prendre en charge, en fonction de leurs compétences,tout ou partie des besoins de l’utilisateur à satisfaire. Ceci requiert des servicesde pouvoir raisonner sur les besoins de l’utilisateur à satisfaire ainsi que sur leurspropres fonctionnalités afin de décomposer adéquatement les besoins de l’utilisa-teur. L’ensemble des services participant à la chorégraphie doivent alors pouvoirinteragir de manière flexible, puisqu’ils ne sont pas connus a priori les uns desautres, et se coordonner, en fonction de ce que chacun a accompli et de ce dont ila besoin, afin de couvrir l’intégralité des besoins à satisfaire.

Nous présentons l’approche de chorégraphie, répondant à ces besoins, à travers cemémoire en six chapitres :

1. Dans le chapitre 1, nous catégorisons les approches existantes de compositionde services. Nous analysons les différentes classes de propositions, y compriscelles empruntant des solutions agent et celles issues de l’intelligence am-biante. Nous étudions alors les travaux sur la coordination multiagent à partirdesquels nous pourrons esquisser une proposition satisfaisant les contraintesde notre problématique.

2. Dans le chapitre 2, nous donnons une vue d’ensemble de notre approcheet présentons notre architecture combinant technologies services web et sys-tèmes multiagents.

3. Nous décrivons dans le chapitre 3 un modèle pour formaliser d’une part lesbesoins de l’utilisateur, en un ensemble de requêtes et de contraintes globales,et d’autre part le contenu des messages échangés par les agents. Ensuite,nous présentons le langage de communication entre agents permettant à cesderniers d’interagir à propos des besoins de l’utilisateur en fonction de leurscapacités.

4. Pour la chorégraphie des services, nous spécifions dans le chapitre 4 le pro-tocole de coordination permettant aux agents de prendre dynamiquementpart à la réalisation d’une tâche complexe (i.e. requêtes de l’utilisateur),pouvant impliquer l’exécution de plusieurs sous-tâches dépendantes. Ce pro-tocole est caractérisé par le fait que les agents qui l’exécutent sont capables

13

de décomposer chaque tâche en fonction de leurs compétences, se coordonnerdynamiquement avec leurs accointants pour couvrir l’intégralité de la tâcheà satisfaire, et détecter les éventuelles informations, requises pour la com-position, qui n’ont pas été fournies par l’utilisateur. Suite à sa spécification,nous vérifions les principales propriétés de notre protocole, notamment laterminaison, la complexité calculatoire et de communication.

5. Pour la sélection des services, nous proposons dans le chapitre 5 un algo-rithme permettant de déterminer, à l’issue de la coordination des agents, lespropositions qui satisfont au mieux les contraintes globales exprimées parl’utilisateur.

6. Pour la validation de notre approche, nous déroulons dans le chapitre 6 descas d’étude du web et de l’intelligence ambiante et présentons les résultatsproduits par notre application. De plus, nous synthétisons l’approche globalede chorégraphie de services en décrivant comment celle-ci s’articule techni-quement autour de notre protocole de coordination multiagent.

7. Enfin, nous concluons ce mémoire par une synthèse de nos contributions,une analyse critique de notre approche, et les améliorations et travaux enperspective.

14 INTRODUCTION

Chapitre 1

Entre composition de services etcoordination d’agents : Un étatde l’art

Ce chapitre est consacré à un état de l’art sur les travaux liés à lacomposition de services et à la coordination multiagent. Nous les présentons endeux temps.

D’abord, nous proposons une catégorisation selon laquelle nous décrivons etanalysons les approches existantes de composition de services web. Ensuite, nousprésentons un panorama des modèles de coordination dans les systèmes multiagentsainsi que les travaux les implémentant pour le problème de la composition deservices.

Nous analysons les approches présentées et concluons ce chapitre par les limitesque les travaux existants en composition de services et en coordination multiagentprésentent pour la modélisation du problème de la chorégraphie dynamique deservices.

1.1 Composition de services

1.1.1 Catégories de la composition de services

La composition de services est à l’origine d’un nombre considérable de travaux,aussi bien dans la recherche académique que dans l’industrie.

En dépit de tous les efforts déployés, la composition de services reste un pro-blème très complexe. Cette complexité tient au fait que les solutions de compositionde services doivent tenir compte du nombre croissant de services déployés sur leweb, de leur mise à jour continuelle et de leur hétérogénéité [107]. En conséquence,elles nécessitent de traiter les problématiques de la coordination des services, leurstransactions, leur exécution et leur modèles de conversation (ou d’interaction) [13].

15

16 CHAPITRE 1. ÉTAT DE L’ART

Ces dernières années, plusieurs communautés se sont intéressées à la problé-matique de la composition de services. Des solutions ont notamment été propo-sées dans les communautés des bases de données [100, 105], du web sémantique 1

[29, 35, 57, 81], et plus récemment dans celles des agents [6, 26, 45, 95].Les solutions proposées peuvent être classifiées selon deux axes :

1. En fonction du degré de participation de l’utilisateur dans la définition duschéma de composition, ces propositions sont manuelles, semi-automatiquesou automatiques.

2. Selon que la sélection des services et la gestion du flot soient faites ou non apriori, une approche sera dite statique ou dynamique.

On dit qu’une composition est statique lorsqu’elle prend place àl’étape de conception, au moment où l’architecture et la conceptiondu système logiciel sont planifiés. Les composants (ou services) quiseront utilisés sont préalablement choisis et reliés, et la gestion duflot est effectuée a priori [40].

Les approches statiques de composition de services sont celles adoptées par l’in-dustrie. Elles s’inspirent de la gestion de processus métiers quant à la descriptiondes données et des flots de contrôle pour le processus de composition.

Par opposition, une composition de services est dite dynamique siles services sont sélectionnés et composés à la volée en fonction desbesoins formulés par l’utilisateur [97].

Une approche dynamique pour la composition de services offre le potentiel de réa-liser des applications flexibles et adaptables en sélectionnant et en combinant lesservices de manière appropriée sur la base de la requête et du contexte de l’utili-sateur. Ce type de composition peut engendrer de nombreuses applications utilesqui n’ont pas été prévues à l’étape de conception. Par conséquent, la compositiondynamique de services est propice dans un environnement tel que le web et l’infor-matique pervasive où les composants disponibles sont dynamiques et les attentesdes utilisateurs variables et personnalisées. C’est précisément ce type d’approchequi fait l’objet de notre travail.

1.1.2 Approches pour la composition de services

Nous présentons dans cette section les approches de composition selon le pre-mier axe de notre classification, soit les approches manuelles/semi-automatiqueset automatiques. Lors de notre description, nous catégorisons chacune selon notredeuxième axe en précisant si la sélection ou le moteur de composition y sont sta-tiques ou dynamiques. La figure 1.1 classifie la majorité des approches que nousallons présenter selon cette catégorisation.

1. Le web sémantique est, d’après la définition de son créateur Tim Berners-Lee, le web quipermettra de rendre le contenu sémantique des ressources Web interprétables non seulement parl’homme mais aussi par la machine [17].

1.1. COMPOSITION DE SERVICES 17

Figure 1.1 – Classification des travaux en composition de services.

Suite à la présentation de l’ensemble de ces travaux, nous faisons une ana-lyse critique des approches et méthodes employées par rapport au problème de lacomposition dynamique de services.

1.1.2.1 Composition manuelle/semi-automatique

Les techniques de composition manuelles [14, 66, 74] reposent sur un expert encharge de définir et générer, graphiquement ou moyennant un éditeur de texte, desscripts de workflow qui sont ensuite soumis à un moteur d’exécution de workflows.La plupart d’entre elles sont entièrement statiques puisque les services à composersont préalablement sélectionnés, et le flot de composition défini a priori.

Microsoft Biztalk et Bea WebLogic sont des exemples de moteurs de composi-tion statiques [117].

WS-BPEL (Web Services Business Process Execution Language) [67] est unlangage d’orchestration permettant de définir des processus métiers et de décrireles interactions d’un service. Le langage WS-BPEL permet ainsi de décrire cesinteractions à travers un plan en spécifiant les flots de contrôle quant à l’invoca-tion de services partenaires, ainsi que les dépendances des données entre plusieursprocessus métiers.

BPWS4J [66] fournit quant à lui un plug-in Eclipse permettant à l’utilisateurde composer un graphe au niveau XML. Le graphe composé, associé à un documentWSDL pour le service composé, est soumis à un moteur d’exécution.

D’autre approches manuelles comportent en revanche des moteurs de composi-tion dynamiques.

C’est par exemple le cas d’eFlow d’HP [27]. eFlow est un système spécifiant,ordonnant et surveillant des e-services composés.

Un e-service est le moyen par lequel une entreprise offre ses pro-


duits, ses services et ses ressources via Internet.Les e-services peuvent être utilisés par des personnes, des entreprisesou des dispositifs électroniques.

Dans eFlow, les e-services composés sont modélisés par un graphe (similaire audiagramme d’activités UML) définissant le flot d’invocation des services, et pou-vant être traduit en code XML. Pour spécifier ces services composés, le concepteurde services détermine la partie abstraite du graphe, et ajoute éventuellement desentrées et des sorties à certains noeuds dont les valeurs seront collectées auprès del’utilisateur.

Par ailleurs, on compte également le langage de chorégraphie WS-CDL (TheWeb Services Choreography Description Language) [74], effort du W3C ayant pourobjectif d’apporter un langage reflétant les interactions à long-terme, i.e. les colla-borations, entre services. C’est un langage basé sur XML permettant à l’utilisateurde décrire des collaborations pair à pair (P2P) entre services en définissant leurcomportement commun et observable. Un document de chorégraphie décrit les in-teractions entre participants. L’accomplissement de leur but commun se fait alorspar des échanges ordonnés de messages suivant le plan déterminé dans ce document.

Dans les approches semi-automatiques, des outils sont développées afin de pro-poser à l’utilisateur des “suggestions sémantiques” quant à la sélection des servicesà composer (ex. en fonction de leurs entrées/sorties, annotations, etc) durant leprocessus de composition.

Par exemple, l’outil graphique IRS-III développé par Domingue et al. [37] guidel’utilisateur étape par étape pour la composition de services décrits en WSMO (WebService Modeling Ontology) qui est un modèle pour la description de services websémantiques [81].

Les services web sémantiques sont des services web munis d’unesémantique ayant pour but de les rendre interopérables et compré-hensibles par des moteurs ou des agents logiciels capables de rai-sonner 2 [17].

Durant le processus de composition, le framework propose à l’utilisateur de sélec-tionner des buts, des médiateurs et des opérateurs de flot de contrôle. Une fois quele service composé est défini, l’outil instancie les opérateurs de contrôle ainsi quele workflow.

Le framework décrit dans [32] exploite quant à lui les connaissances du domainepour guider l’utilisateur voulant construire un workflow. L’outil fournit à cet uti-lisateur des conseils sur la sélection et l’instanciation des services et lui permet demémoriser les workflows pour faciliter leurs réutilisations.

Analyse

Les approches et systèmes sus-décrits permettent ainsi à un utilisateur d’écrirele plan de composition de services, afin que ce dernier soit :

2. L’approche la plus populaire consiste à décrire cette sémantique à travers des métadonnées(ex. RDF [124]) ou des ontologies (ex. OWL [44], OWL-S [86], WSMO [81]).


1. directement exécuté. On dit alors que la composition est entièrement sta-tique ;

2. instancié et ensuite exécuté. La composition n’est pas entièrement dyna-mique, puisque le profil des services à composer est préalablement spécifié.Néanmoins, le moteur de composition est dynamique, puisque la compositionvarie en fonction des instances des services trouvées.

Par ailleurs, la plupart de ces approches permettent de traiter aussi bien lesprocédures génériques que des besoins ouverts d’utilisateurs. Cependant, elles pré-sentent plusieurs inconvénients :

– Ces approches exigent de l’utilisateur d’avoir des connaissances bas-niveaudu système. Dans le cas de WS-BPEL, BPWS4J et WS-CDL par exemple,l’utilisateur est censé construire un workflow au niveau XML. Ces systèmes nes’adressent donc qu’à des usagers spécialistes en ingénierie de l’information.

– Les langages de chorégraphie permettent de décrire une collaboration entreservices pour l’accomplissement d’un but. Toutefois, n’étant pas exécutables,ils ne suffisent pas seuls à l’implémentation d’une chorégraphie automatiquede services.

– Dans ces travaux, les services à composer et le flot entre services sont préa-lablement définis. En conséquence, si l’un des services à composer n’est pasdisponible, l’exécution échoue.

– Des inconsistances peuvent survenir à cause de l’approvisionnement de nou-veaux services ou du remplacement d’anciens services par d’autres. Dansces cas, il est inévitable de changer d’architecture logicielle et de la relierà d’autres services ou même, dans le pire des cas, changer la définition duprocessus et reconcevoir le système.

Par conséquent, une sélection et une composition statiques (ou partiellementdynamiques) de services conviennent tant que l’environnement des services (lespartenaires et les composants services) reste inchangé, ou change rarement. L’uti-lisation de ces approches peut être très restrictive dans des environnements à largeéchelle tels que le web où il faut envisager des composants capables de s’adapterautomatiquement aux changements imprévisibles.

1.1.2.2 Composition automatique

Ces techniques automatisent entièrement le processus de composition en le trai-tant généralement comme un problème de planification. Dans ce cas, le moteur decomposition y est toujours dynamique.

Par exemple, les auteurs dans [120] effectuent la planification en commençantpar traduire les descriptions des services disponibles en systèmes d’états transi-tions décrivant leurs interactions dynamiques avec des services externes. En effet,les services disponibles sont au départ définis en OWL-S (Ontology Web Languagefor Services) [86], qui est un modèle pour la description déclarative de processusde services web. Leur transformation en systèmes d’états transitions permet de lessoumettre à un moteur de planification (et ensuite pour les auteurs de comparer lesperformances entre une approche de composition sémantique vs. exécutable). La


tâche de composition consiste alors à trouver un plan satisfaisant un but de compo-sition dans le domaine des services disponibles. Les plans générés par l’algorithmede planification sont des automates pouvant être traduits en code exécutable.

L’outil SWORD [104] automatise la tâche de composition en utilisant des des-criptions de services basées sur les règles. L’utilisateur spécifie les faits des étatsinitial et final. Le planificateur tente alors de construire une chaîne de servicespouvant satisfaire ces besoins.

StarWSCoP (Star Web Services Composition Platform) est introduite dans[117] comme une plateforme de composition dynamique de services web. La com-position y est effectuée en quatre étapes :

1. Les founisseurs publient leurs services dans un registre de services ;2. Le moteur de composition de services décompose les besoins de l’utilisateur

en plusieurs services abstraits et envoie une requête SOAP au registre afind’y découvrir les services appropriés ;

3. Le registre de services web retourne un ensemble de services concrets ;4. Le moteur de composition envoie une requête SOAP aux services concrets et

établit une liaison avec ces services.La plateforme StarWSCoP inclut différents modules dont un système intelligentpour décomposer les besoins de l’utilisateur en une description abstraite de service,un registre de services, un moteur de découverte de services pour trouver les servicesdont les fonctionnalités conviennent aux besoins de l’utilisateur dans le registre deservices et un moteur de composition qui agence les services composés pour êtreexécutés dans l’ordre.

Dans [82], les auteurs préconisent une approche de composition de servicess’appuyant sur l’observation des interactions entre services web. Ils proposent unearchitecture en deux couches pour la gestion des interactions entre services. Danscette approche, le processus de composition, qui est défini dans la première coucheà travers le schéma des services à invoquer et leur flot de transactions, est exécutétout en tenant compte des règles de traitement d’exceptions, spécifiées au niveaude la seconde couche, se produisant lors de la composition des services.

Par ailleurs, la composition automatique de services a également fait l’objet dequelques travaux et prototypes dans le domaine de l’intelligence ambiante.

Les domaines de recherche de l’intelligence ambiante (AmI) et de l’informatiquediffuse [126] visent à intégrer la puissance de la programmation dans l’environ-nement de l’utilisateur. L’AmI envisage la création d’environnements intelligentsintégrant information, communication et technologies de détection dans les objetscommuns pour s’adapter ou répondre aux besoins de l’utilisateur.

L’AmI se situe donc à la convergence de trois domaines partageant des traitscommuns :

– L’informatique diffuse (Ubiquitous Computing) qui consiste à intégrer desmicroprocesseurs dans les objets de la vie quotidienne.

– La communication diffuse, ou l’interaction entre agents ambiants numériques(Ubiquitous Communication) qui permet à ces objets de communiquer entreeux et avec l’utilisateur.


– Les interfaces entre agents humains et agents ambiants (Intelligent User In-terface) qui permet aux usagers de contrôler et interagir intuitivement avecces objets.

Aini, la mutualisation des compétences de ces trois domaines a donné lieu à plu-sieurs travaux dans la composition de services ambiants. Ces travaux s’intéressentà la communication utilisateur-composant et inter-composants pour la satisfactionde besoins de l’utilisateur.

Par exemple, Gárate et al [61] ont développé un réseau d’appareils domotiques(réfrigérateur, télévision, etc) connectés et gérés par un contrôleur central. Dansce réseau, l’utilisateur peut dialoguer avec ses appareils et demander les services etfonctionnalités que ces appareils offrent en langue naturelle.

HomeLab de Philips Research, présente dans [80] le concept prototypé de la sallede bain intelligente. Celle-ci comprend un miroir interactif, jouant un rôle centraldans les interactions et pouvant interagir avec des composants régulièrement utilisésdans la salle de bain (affichant le poids inscrit sur un pèse-personne, activant uncoach de santé, etc). Dans ces deux derniers travaux, le moteur de composition eststatique.

Dans [121], les auteurs proposent de composer des services offerts par des objetsambiants, moyennant des techniques de web sémantique, afin de répondre à destâches spécifiques requises par l’utilisateur. Dans leur approche, un plan abstrait estdéfini pour chaque tâche. Par exemple, la tâche “surveillance d’appareil ménager”est associée à un plan où il s’agit de vérifier que le four et le robinet ne sont pasen marche lorsqu’une personne sort de cuisine. Leur mécanisme de compositionapparie alors chaque sous-tâche avec un service existant, prenant en compte desparamètres de contexte et testant la cohérence entre les services concrets trouvés.

Analyse

Parmi les approches décrites, certaines présentent des avantages tels que l’utili-sation dans [120] d’un langage pour la formalisation des buts complexes de compo-sition, étendant la logique temporelle CTL [42]. En effet, le langage utilisé, appeléEaGLe [34], comporte des constructeurs permettant d’exprimer des préférencesainsi que des séquences de buts. D’autre approches [117] proposent par ailleursdes moteurs de décomposition des besoins de l’utilisateur ainsi qu’un moteur dedécouverte de services.

En contrepartie, ces approches comportent les points faibles suivants :– Lorsqu’un langage est proposé pour modéliser le but de composition, il est

généralement lié à la méthode employée pour la composition automatiquedes services (notamment la planification), et ne peut représenter des besoinstels qu’une requête et des contraintes locales sur un service.

– La décomposition des besoins de l’utilisateur dans ces approches est faitea priori alors qu’elle devrait être faite sur la base des fonctionnalités desservices découverts, comme Ermolayev et al. l’ont montré dans [45].

– Les approches proposées sont centralisées autour d’un moteur de composition.La centralisation de ces approches découle du principe même d’orchestrationde services qu’elles implémentent.


– La sélection des services dans ces approches est soit statique (les services sontprésélectionnés), soit basée sur un simple mécanisme d’appariement séman-tique. Ce dernier ne permet cependant pas de garantir que les services trouvésvont répondre aux contraintes et préférences exprimées par l’utilisateur. Eneffet, on ne peut pas prévoir toutes les contraintes et préférences auxquellesun service peut répondre dans ses annotations (c.f. le Frame Problem [89]).En conséquence, il est insuffisant que la sélection définitive des services sebase uniquement sur une processus d’appariement sémantique.

– Le fait que la composition soit basée sur des implémentations de servicesspécifiques rend le partage des workflows difficile si un service n’est plusdisponible. De même, si elle est basée sur un plan abstrait et que les servicesdisponibles ne répondent pas exactement au profil énoncé.

Pour ce qui est des approches proposées dans l’AmI, elles partagent plusieursdes limites précédemment identifiées. Elles supposent notamment l’existence d’unelibrairie prédéfinie de plans abstraits correspondant à chaque tâche que l’utilisateurpourrait demander. Celui-ci ne pourrait donc pas se voir satisfaire une nouvelledemande si le plan de cette dernière n’a pas été préalablement spécifié et intégré àla librairie de plans.

Enfin, les approches en AmI sont pour la plupart centralisées, autour d’uncontrôleur pour [61], un miroir interactif dans [80], ou un moteur d’exécution deplans dans [121]. Si une panne survient au niveau de l’entité médiatrice, elle bloquetout le processus de composition. De plus, deux utilisateurs devraient pouvoir si-multanément solliciter deux différents ensembles de services. Dans les approchesexistantes, cela n’est pas possible puisque chaque processus de composition requiertde passer par une entité centrale.

1.1.3 Synthèse

Nous venons de présenter les principaux travaux en composition de services ;approches utilisant des scripts de workflows, des éditeurs, des techniques de plani-fication, ou encore celles issues de l’intelligence ambiante.

Pourtant, aucune de ces approches ne peut être considérée comme étant plei-nement dynamique. Certes, elles présentent pour chacune des points forts danscertains aspects de la composition, tels que des moteurs de composition dyna-mique. Ceci au détriment d’autres aspects, tels que des plans abstraits prédéfinis,des moteurs de composition centralisés, et une sélection statique des services àcomposer.

Comme nous l’évoquions plus haut, ces limitations proviennent du fait que cestravaux implantent des orchestrations de services. Elles décrivent la compositiondu point de vue d’un service ou d’un moteur de composition centralisé pour un butprédéfini (i.e. procédure générique). Ce qui conduit inévitablement à des solutionsstatiques et ad hoc.

Au contraire, la chorégraphie de services se fonde sur le principe d’une compo-sition de services dynamique et décentralisée, où chaque service doit être capablede collaborer avec d’autres services. Une telle approche doit tenir compte de la

1.2. COORDINATION MULTIAGENT 23

distribution et de la flexibilité des services, des besoins ouverts de l’utilisateur etdes interactions flexibles des services sur la base de leurs fonctionnalités.

Comme nous l’avons présenté dans le chapitre précédent, les systèmes mul-tiagents semblent être un paradigme particulièrement bien adapté pour pallier leslimites intrinsèques aux services web en général et des approches existantes de com-position de services en particulier. Dans la suite de ce chapitre, nous faisons unebrève présentation des concepts clé des systèmes multiagents ainsi que les classesde modèles de coordination. Nous présentons ensuite les principaux modèles decoordination existants ainsi que les travaux en composition de services les implé-mentant dans leurs solutions. Nous étudions enfin dans quelle mesure les modèlesde coordination existants sont adaptés mais insuffisant pour modéliser le problèmede la chorégraphie de services.

1.2 Coordination multiagent

1.2.1 Généralités sur les systèmes multiagents

Les agents et systèmes multiagents ont beaucoup été étudiés dans la littérature[47, 64, 72]. Le paradigme agent a été très influencé par le paradigme objet, maiss’en distingue par trois aspects qui sont l’autonomie, la rationalité et l’interaction.Les systèmes multiagents ne sont pas qu’un simple groupe d’agents dans un en-vironnement commun, mais une réelle organisation avec des règles sociales et desinteractions permettant la coopération et la collaboration pour la résolution deproblèmes que les systèmes centralisés ne pourraient pas résoudre.

Les modèles d’agents peuvent être classés selon un axe qui va des agents ditspurement réactifs, dans lesquels le comportement des agents est décrit uniquementsous la forme de règles “perceptions→action”, aux agents cognitifs qui ont unereprésentation globale de leur environnement et des autres agents avec lesquelsils communiquent et qui s’organisent autour d’un mode social d’organisation, enpassant par les agents hybrides, combinaison des deux précédentes catégories.

Les SMA constitués d’agents cognitifs ou hybrides utilisent des ACL (AgentCommunication Language) pour la communication inter-agent. Les principauxACL utilisés, i.e. KQML [48] et FIPA-ACL [51], sont fondés sur la théorie desactes de langage [111, 122] et ont été conçus pour l’échange d’information, deconnaissances ou encore de services entre agents. C’est la communication entreagents qui fait qu’un groupe d’agents forme un SMA. La communication permetla coopération et la coordination entre agent [47, 128].

1.2.2 Modèles de coordination d’agents, et applications à la com-position de services

La coopération multiagent, en vue d’engendrer un comportement global cohé-rent du SMA, requiert des mécanismes élaborés de coordination afin d’éviter desconflits potentiels et de favoriser la synergie des activités des agents [20]. La co-ordination multiagent fait souvent référence au processus qui contrôle la prise de


décision et guide le comportement global inhérent à l’exécution d’une collectiond’agents.

On distingue deux grandes classes de modèles de coordination :Les modèles orientés tâches Il s’agit de modèles applicables dans un contexte

de résolution distribuée de problèmes (Distributed Problem Solving). Dansces modèles de coordination on présuppose l’existence d’un but global partagépar un groupe d’agents au sein d’une organisation.C’est par exemple le cas de la métaphore des agents déménageurs, où il estquestion d’un ensemble d’agents (A1, A2, . . .) en charge d’assurer le déména-gement d’une maison (tâche T ) constituée de plusieurs pièces. Le but globaldes agents est alors d’accomplir la tâche T , et le but individuel de chaqueagent Ai est d’accomplir une sous-tâche Tj selon l’allocation d’un gestion-naire.

Les modèles orientés agents Il s’agit de modèles applicables dans le contexted’agents (semi-) autonomes ne partageant pas forcément un but global sinonla cohérence et la viabilité du système. Dans ce cas de figure, les agents entant qu’entités individuelles cherchent à optimiser leurs propres objectifs ouutilités (par exemple, gagner le maximum dans une situation de compétitiondes agents déménageurs).

Ces deux classes de coordination reposent sur les mécanismes détaillés dans lesmodèles que nous présentons ci-après.

Notons d’ores et déjà que les modèles de coordination orientés tâches corres-pondent mieux aux caractéristiques du problème de la chorégraphie de services.Nous présentons alors les principales approches de coordination multiagent et don-nons des exemples de travaux les ayant employées pour la composition de services.

1.2.2.1 Les structures organisationnelles

Une structure organisationnelle est une distribution fonctionnelle (de com-pétences, de rôles), spatiale (affectation à des régions délimitées) et temporelled’agents.

Une organisation peut être statique ou dynamique. Elle est dite statique lors-qu’elle fige a priori, lors de la conception du SMA, les comportements des agentsainsi que les règles de comportement qu’ils doivent respecter pour éviter des conflitspotentiels. Ainsi, dans une coordination par règlementation, plusieurs conflits sontrésolus a priori.

Une organisation est dite dynamique lorsque ses fondements peuvent changerau cours du temps (ex. formation et dissolution de coalitions). Le problème de coor-dination dans ce cas consiste à spécifier l’organisation et la répartition dynamiquedes tâches à résoudre, la sauvegarde des compétences et connaissances du systèmelorsque l’organisation change et la représentation des connaissances organisation-nelles [54].

La formation de coalitions

Un domaine très significatif pour les organisations dynamiques est celui dela formation de coalitions dans les SMA. Les coalitions sont des regroupements


ponctuels d’agents compétitifs pour la réalisation d’un projet commun [25]. Unecoalition peut être définie comme une organisation à court terme basée sur desengagements spécifiques et contextuels, ce qui permet aux agents de bénéficier deleurs compétences respectives. Dans un contexte économique par exemple, plu-sieurs compagnies s’allient virtuellement pour répondre à des offres nécessitant descompétences variées.

Le principe de la formation de coalition a été proposé pour l’allocation detâches pour la résolution de problèmes. Les travaux du domaine ont porté surla recherche de consensus par formation de coalitions [2, 112, 123]. Par exemple,dans [2], l’approche consiste à coordonner des agents lors de l’allocation de tâches.Les agents considérés peuvent être coopératifs ou compétitifs. Cette approche sefonde sur une agrégation multicritère basée sur des techniques d’aide à la décision.L’approche décrite dans [123] propose quant à elle un algorithme de consensus quiprivilégie les libertés des agents où chacun peut changer de stratégie durant laphase de recherche du consensus et peut n’échanger que ses préférences.

Pour la composition de services

Plusieurs travaux exploitant les méthodologies agent et SMA pour la compo-sition de services proposent d’utiliser des mécanismes de formation de coalitions.L’approche de [45] propose par exemple de composer des services à travers la coa-lition d’agents médiateurs qui ont pour rôle de réaliser les tâches requises parles services. Les besoins à satisfaire sont exprimés en terme de contraintes (ex.budget=1500AC) et de préférences (ex. petit déjeuner continental). La décomposi-tion de ces besoins est ensuite faite au niveau des agents médiateurs qui consultentune ontologie de tâche [93] pour déduire qu’une tâche à réaliser est complexe etimplique la réalisation de plusieurs sous-tâches.

Une tâche est dite complexe si elle nécessite l’utilisation des capa-cités de plusieurs agents.

Dans l’approche de [45], les agents contractent en priorité les agents crédibles etde confiance, c’est-à-dire ceux dont ils savent qu’ils ont auparavant déjà effectué letype de tâches demandées.

Aussi, les travaux de [95] emploient un agent utilisateur qui publie dans unblackboard le but de composition à satisfaire. Ce but contient la description d’unworkflow générique référençant des “types” de services (ex. service de location devoiture, d’hôtellerie, etc). Les agents services existants, au delà d’une deadlined’inscription, récupèrent alors du blackboard les sous-buts à satisfaire, et procèdentà un appariement entre les types de services recherchés et les services qu’eux-mêmesproposent afin d’évaluer s’ils peuvent ou non contribuer à une coalition. Chaqueagent service peut ensuite proposer ou accepter la demande d’un autre agent servicepour former une coalition. Pour qu’un nouvel agent service rejoigne une coalition,il doit être sujet au vote de tous les agents services la formant.


1.2.2.2 La planification

L’approche de coordination par planification distribuée s’intéresse aux inter-actions qui existent entre les plans des agents [85]. Dans ce type d’approches, lacoordination peut s’exprimer par la résolution de conflits entre les activités desagents. Celle-ci peut être vue comme un processus de négociation [131] au coursduquel les agents doivent parvenir à un consensus, un processus d’argumentation[79] où chaque agent essaie de convaincre les autres du bien-fondé de sa proposition,une synchronisation entre les plans [41] ou une fusion de plans [4].


Nous avons déjà présenté plusieurs approches de composition utilisant des tech-niques de planification dans la section 1.1.2.2. Nous pouvons également citer cellede [130] où le planificateur SHOP2, de la famille des planificateurs HTN (Hierchi-cal Task Network), est utilisé pour la construction d’un plan global à partir desdescriptions (préconditions, effets) des services.

1.2.2.3 Les protocoles d’interaction

Un protocole d’interaction permet aux agents d’avoir des conversations, sousforme d’échanges structurés de messages [65]. Il décompose une tâche en sous-tâcheset les distribue, suivant une stratégie donnée, aux agents du système. Cette stratégiedoit par exemple permettre [39] : d’allouer les tâches aux agents en fonction deleurs capacités, d’allouer les responsabilités aux agents de manière couvrante pourassurer la cohérence globale, etc.

On compte d’ores et déjà plusieurs protocoles d’interaction tels que le CNP(Contract Net Protocol) [115] qui relève des réseaux contractuels et qui proposedes séries épisodiques pour des actes d’intercommunication (annonces, enchères,messages de récompense) ; le protocole Rubinstein [108] alternant proposition etcontre-proposition, FIPA-Request [52] permettant aux agents d’accepter ou de refu-ser d’exécuter une requête ou encore les protocoles de ventes aux enchères [50, 106].


À notre connaissance, il existe peu de travaux proposant des protocoles d’in-teraction conçu spécifiquement pour le problème de la composition de services.

Ceux qui s’en rapprochent sont par exemple les travaux de [101] qui trans-crivent, pour la négociation entre services, le protocole Rubinstein dans la descrip-tion XML des services, ou encore le protocole WS-Agreement [43] qui spécifie desconversations à deux étapes, une offre suivie d’un accord, pour l’établissement decontrats et d’accords entre un service fournisseur et un consommateur.

Enfin, l’approche de [6] sépare la description et la composition des services dela spécification des formats de données et du protocole de transport (notammentdécrits en WSDL). Les contributions de ces travaux consistent en la propositiond’un langage de description de services ainsi qu’un protocole de composition. L’ap-proche conçue se base sur un agent en charge de contacter des services à proposdes tâches qu’il souhaite accomplir. Chaque fois qu’un service accepte de réaliser


une tâche demandée, l’agent met à jour la construction de son workflow. Celui-ciest ensuite exécuté pour l’accomplissement de la tâche globale.

1.2.3 Limites des modèles de coordination pour la chorégraphiede services

Après avoir décrit les modèles de coordination multiagent et analysé les travauxles implémentant pour le problème de la composition de services, nous étudionsdans cette section les limites des approches proposées ainsi que les faiblesses in-trinsèques aux modèles de coordination pour leur application au problème de lachorégraphie de services.

1.2.3.1 La formation de coalition

Lorsque l’on considère les travaux basés sur la formation de coalition, on peutdistinguer deux principales catégories d’approches. Celles qui se fondent sur desagents égocentrés qui concourent pour l’obtention de ressources [113], et cellescomplémentaires se basant sur la théorie des jeux coopératifs et qui emploient desagents qui ne peuvent atteindre leurs objectifs qu’à travers des collaborations [112].

Les agents égocentrés ont pour but de maximiser leurs utilités individuellesalors que les agents coopératifs maximisent l’utilité de leur coalition. Cependant,pour atteindre des coalitions d’agents stables et optimales, ces approches se basentsur des hypothèses restrictives telles que des connaissances a priori sur la valeurd’une coalition, l’ensemble des coalitions possibles, les capacités des agents connuesd’un agent leader de coalition, etc. De plus, les coalitions stables et optimales sontsouvent obtenues au prix de complexités exponentielles [18].

Dans les algorithmes proposés pour la formation de coalitions [2, 123], les agentsdoivent atteindre un consensus afin que soit alloué à chacun un ensemble de tâchesde sorte que les préférences de chaque agent soient satisfaites. Cependant, dansces algorithmes, on considère que les tâches ont été décomposées en amont et quechaque sous-tâche obtenue est atomique. Ainsi, ces solutions se basent sur l’hypo-thèse qu’il existe des agents capables de satisfaire intégralement une ou plusieursdes sous-tâches à accomplir.

Enfin, les approches proposées de composition de services par formation decoalitions utilisent des métriques d’évaluation quantitatives telles que le nombre decoalitions formées et abandonnées et négligent l’évaluation qualitative du résultatfourni par la composition de services en fonction de besoins donnés à satisfaire [46].

1.2.3.2 La planification distribuée

Dans les méthodes de planification distribuée [38, 55], et en particulier dansla planification multiagent orientée tâche, on considère une tâche globale qu’unagent manager décompose en sous-tâches qui sont allouées à un ensemble d’agentscoopératifs capables de les réaliser. Dans ce modèle, la coordination des sous-tâches(et des agents) est effectuée à travers le plan de l’agent manager.


Cependant, la disponibilité des agents capables d’exécuter une sous-tâche n’estjamais garantie. En conséquence, plusieurs itérations pour décomposer et distribuerla tâche globale peuvent ainsi nécessaires avant que les sous-tâches obtenues necorrespondent aux capacités d’agents existants, et plusieurs itérations peuvent ainsiêtre nécessaires avant que les agents n’exécutent réellement le plan. Finalement,dans ce modèle de coordination, aucune hypothèse n’est faite sur la manière dontles agents coopératifs vont réaliser leur(s) sous-tâche(s).

D’autres approches de planification suggèrent de demander au programmeur defournir la description du workflow [97]. Cette technique a un coût réduit. Cepen-dant, elle est statique et conduit à des solutions ad-hoc qui dépendent fortementde l’application. Ces stratégies dites de partage de résultats nécessitent de spécifierexplicitement les relations entre les actions (ex. le résultat de l’action d’un agentest requis par un autre pour réaliser une autre action) [38].

Enfin, les approches se basant sur la planification HTN utilisent une plani-fication qui en fait est très puissante pour les domaines où la connaissance estcomplète et détaillée, ce qui n’est pas le cas avec les services web, comme l’ontdémontré Klush et al. dans [75].

1.2.3.3 Les protocoles d’interaction

En ce qui concerne les protocoles d’interaction existants [49, 108, 123], ils sup-posent de même que les sous-tâches à réaliser sont atomiques. C’est-à-dire quechaque agent peut soit intégralement exécuter la tâche demandée ou ne pas l’exé-cuter. Cela limite leur application pour la composition de service dans le mesureoù, comme nous le soulignions précédemment, la décomposition et la répartition dubut global de composition doit s’effectuer sur la base des fonctionnalités disponibleset non en amont [45].

En effet, le CNP par exemple est un protocole simple où un agent managerenvoie un cfp (call for proposal) aux agents participants qui peuvent soit acceptersoit refuser de réaliser l’intégralité de la tâche. De plus, il néglige les stratégiespossibles de raisonnement sur les capacités des agents participants [96]. C’est laraison qui fait que ce protocole n’est appliqué que dans des problèmes où les tâchesà accomplir sont bien définies et décomposées.

1.2.4 Discussion

Après analyse des différents modèles de coordination, il apparaît que les prin-cipales limites de leur application au problème de la chorégraphie dynamique deservices est l’hypothèse faite que les tâches à satisfaire sont décomposées en amontde la coordination. Au contraire, une tâche devrait pouvoir être décomposée sur labase des fonctionnalités disponibles (et non en amont) en sous-tâches interdépen-dantes en terme d’exécution.

Cela requiert aux agents, avant tout, de pouvoir raisonner sur leurs actionsafin de déterminer si une tâche est complexe et nécessite ainsi le concours d’autresagents pour son accomplissement. Or, les plates-formes de développement d’agentsactuelles, telles que JADE [70], DIMA [58] ou JACK [69], ne permettent pas de

1.3. CONCLUSION 29

doter les agents de capacités leur permettant de raisonner sur leur propres compé-tences. De même, les langages de communication entre agent actuels (ACL) [51, 48]ne permettent pas d’exprimer des questions ou des assertions à propos des capacitésdes agents [16, 88, 127]. Enfin, les protocoles d’interaction existants ne prennentpas en compte les dépendances entre les différentes sous-tâches issues de la décom-position d’une tâche globale [103], considérant que la tâche a été préalablementdécomposée.

En conséquence, même s’ils constituent un paradigme adapté pour traiter lesproblèmes de distribution, d’ouverture et de flexibilité de l’environnement des ser-vices web, les modèles de coordination existants ne suffisent pas en l’état à couvrirle problème de la chorégraphie de services.

1.3 Conclusion

Nous avons vu dans la première partie de ce chapitre que plusieurs approchesse sont déjà penchées sur le problème de la composition de services. Certainesutilisent des techniques de planification, de web sémantique, ou d’autre encoredes éditeurs ou des moteurs d’exécution de workflows, résultant en un ensembled’approches manuelles, semi-automatiques ou automatiques tout en implantantdes compositions statiques ou partiellement dynamiques.

Dans la deuxième partie de ce chapitre, nous avons étudié les différents travauxliés à la coordination multiagent. Nous avons ainsi passé en revue les principauxmodèles de coordination ainsi que les travaux en composition de services implé-mentant ces méthodes dans leurs propositions.

Après analyse de ces différents travaux, il en ressort que la difficulté pour laconception d’une approche dynamique de chorégraphie de services réside principa-lement dans :

– La formalisation du but de composition. La plupart des approches existantesne traitent pas ce problème puisqu’elles s’appuient sur un workflow, écritpar un expert dans un langage tel que WS-BPEL, destiné à être instanciéet exécuté d’une part, et manipulé par des spécialistes en technologie del’information d’autre part.

– La découverte dynamique des services candidats à la composition par rapportau but de composition. En effet, les approches existantes décomposent enamont le but de composition qu’ils décrivent à travers un plan spécifiant lesprofils des services à découvrir. Les méthodes de découverte se réduisent alorsà une simple procédure d’appariement sémantique entre les profils abstraitset les services concrets trouvés.

– La conception d’un modèle dynamique d’interaction de services, qui tientcompte à la fois du but de la composition et des fonctionnalités des ser-vices. En effet, les buts de composition, décrits à travers des plans dansles approches actuelles, spécifient le profil des services à composer ainsi quela séquence de leur invocation. Pour implémenter une coordination dyna-mique, il s’agira d’abord pour les services de prendre dynamiquement partà la décomposition et l’allocation du but de composition et ensuite utiliser


des mécanismes de coordination tenant compte de leurs fonctionnalités afind’interagir de manière flexible de couvrir adéquatement ce but.

Par ailleurs, notre étude nous a conduit à la conclusion que les modèles de co-ordination multiagent étaient un bon candidat pour pallier les limites des servicesweb en général, et de la chorégraphie de services en particulier car ils apportent dessolutions et modèles pour tenir compte de plusieurs contraintes telles que la distri-bution des services, l’ouverture et la flexibilité de leur environnement. Cependant,certaines des difficultés précédemment soulevées restent insatisfaites, notamment :(a) la modélisation de buts de composition complexes, où il s’agit de formaliser desbesoins complexes d’utilisateurs pouvant regrouper des requêtes sur des services,des contraintes, et des interdépendances entre les requêtes, (b) la décomposition etl’allocation dynamique des tâches en fonction des compétences des agents/servicesdécouverts.

C’est sur ces points que notre travail porte. Nous avons pour objectif de pro-poser un modèle de coordination orienté tâche, i.e. applicable dans un contexte derésolution distribuée de problèmes et dans lequel un but global à satisfaire (i.e. lesbesoins de l’utilisateur) est présupposé. Plus précisément, nous voulons concevoirun protocole d’interaction, fondé sur des agents hybrides, i.e. cognitifs et réactifs,capables de raisonner et d’interagir à propos des besoins de l’utilisateur et de leurspropres capacités. Ceci afin de permettre aux agents de pouvoir prendre dynami-quement part à la décomposition d’une tâche à résoudre et de se coordonner avecd’autres agents afin de pallier leurs limites et ainsi adéquatement couvrir l’inté-gralité de la tâche demandée. Le protocole d’interaction spécifié peut ainsi êtreinstancié dans le contexte des services web et fonder une approche dynamique dechorégraphie de services.

Chapitre 2

Architecture orientée servicesbasée sur un SMA

Nous donnons dans ce chapitre une description générale de notre ap-proche de chorégraphie de services et présentons l’architecture combinant techno-logies agent et services web sur laquelle elle s’appuie. Nous décrivons ensuite lastructure interne des agents offrant des services qui composent le système mul-tiagent sur lequel se fonde notre approche de chorégraphie.

Ce chapitre constituant une vue d’ensemble de notre approche et architecture, lelecteur y trouvera alors plusieurs références aux chapitres suivants afin d’y trouverla description détaillée de chaque composant.

2.1 Vue d’ensemble de l’approche de chorégraphie deservices

Notre travail a pour objectif de proposer une approche décentralisée, dynamiqueet automatique de chorégraphie de services. Comme l’illustre la figure 2.1, notreapproche se déroule en quatre principales étapes :

1. D’abord, un utilisateur humain formule ses besoins en services à travers uneinterface graphique. Ces besoins incluent des requêtes en services, i.e. ques-tions ou commandes, ainsi que des contraintes globales, par exemple sur unprix ou une durée totale, sur les services demandés.Dans notre travail, nous n’abordons pas les problèmes relatifs au traitementautomatique de la langue naturelle. Au lieu de quoi, nous proposons un lan-gage pour formaliser les requêtes de l’utilisateur. Une interface graphiquepropose alors des champs à remplir afin de faciliter la saisie de ces requêtes.Le langage formalisant les besoins de l’utilisateur est présenté dans le cha-pitre 3.

2. Un module de découverte de services extrait ensuite des mot-clé de la requête

31

32 CHAPITRE 2. SOA BASÉE SUR UN SMA

Figure 2.1 – Vue d’ensemble de l’approche de chorégraphie.

de l’utilisateur pour découvrir des services candidats à la composition. Ceux-ci sont recherchés à partir d’un registre en ligne de services web.

3. Les services candidats tentent alors de satisfaire cette requête en s’envoyantdes messages. C’est la phase de chorégraphie de services. Leurs interactionssont régies par un protocole de coordination que nous présentons dans lechapitre 4.

4. Enfin, parmi les services ayant pu répondre à la requête de l’utilisateur, unsous-ensemble répondant aux contraintes globales énoncées par celui-ci estsélectionné, ainsi que les réponses proposées par ces services. La sélection desservices se base sur l’algorithme présenté dans le chapitre 5.

Ainsi, notre approche prend en compte une spécification de besoins en ser-vices formulés par l’utilisateur et permet la découverte de services susceptibles derépondre à tout ou partie de ces besoins. Dans notre approche, ces services inter-agissent entre eux de manière autonome et décentralisée afin de couvrir les besoinsexprimés.

Les aspects d’autonomie, de distribution et de décentralisation de la coordi-nation des services découlent d’une architecture s’appuyant sur un système mul-tiagent, comme nous le présentons ci-après.

2.2 Description de l’architecture

2.2.1 “Agent cognitif offre service” (agent introspectif)

Pour implémenter notre architecture orientée services, nous reprenons la recom-mandation du W3C [22] définissant l’architecture d’un service web comme suit :

”Un service web est vu comme une notion abstraite qui doit être implé-mentée par un agent concret. L’agent est une entité concrète (logicielle)qui envoie et reçoit des messages, alors que le service est l’ensemble defonctionnalités offertes” .

2.2. DESCRIPTION DE L’ARCHITECTURE 33

Dans cette définition, un service est vu comme partie d’un agent. De même, notreapproche de chorégraphie de services utilise un modèle de coordination multiagentse basant sur des agents offrant des services.

Comme le montre la figure 2.2, nos agents sont composés de trois principalescouches :

1. La couche de connaissance inclut une base de données et un ensembled’actions. Celles-ci peuvent être encapsulées dans un service déployable etpubliable sur le web (représenté par l’interface WSDL illustré en rouge dansla figure 2.2). C’est pourquoi nous parlons d’agent offrant un service .La couche de connaissance peut par ailleurs intégrer une ontologie regroupantles concepts et noms d’actions manipulés par l’agent / service.

2. La couche de traitement des requêtes et gestion du protocole permetà l’agent de traiter les messages reçus, en fonction de sa capacité à répondreà tout ou partie des besoins exprimés, soit au niveau du module de raison-nement, appelé RPM (pour Request Processing Module), soit au niveau duprotocole de coordination.Le RPM est un module associé à chaque agent permettant le traitement desmessages en fonction de sa couche de connaissance. Lorsque l’agent n’est pascapable de répondre à l’intégralité du message reçu, c’est au niveau du proto-cole de coordination, qui permet de collaborer avec d’autres agents et de tenircompte des précédents messages échangés, que l’agent traite ses messages.

3. La couche de communication permet le transport des messages. C’est unlangage de communication entre agents (ou ACL pour Agent CommunicationLanguage) qui gère cette couche de l’agent. Celui-ci a pour rôle de structurerles messages construits par l’agent. Nous le présentons dans le chapitre 3.Par ailleurs, grâce à leur interface WSDL, les agents peuvent communiquersur le web via le protocole de transport standard SOAP. Les messages expri-més dans l’ACL des agents sont alors transcrits en XML et encapsulés dansdes messages SOAP.

À travers cette structure, les agents peuvent ainsi offrir un ensemble de fonc-tionnalités ou services, via leur couche de connaissance, sur lesquels ils peuventraisonner. Du fait des capacités de raisonnement des agents, nous les qualifionsd’agents introspectifs.

Un agent introspectif est un agent hybride capable d’examiner etde raisonner sur ses propres actions afin de répondre aux requêtesreçues.

Les capacités d’introspection dont sont dotés nos agents sont en partie dé-crites dans la section 2.3.

2.2.2 Architecture orientée services basée sur un SMA

Les agents offrant des services, que nous avons précédemment introduit, formentle système multiagent sur lequel se fonde notre architecture orientée services.


Figure 2.2 – Structure d’un agent offrant un service.

À travers cette architecture, l’utilisateur communique ses besoins en exprimantun ensemble de requêtes et de contraintes sur les services demandés. Pour formali-ser les besoins de l’utilisateur, nous avons choisi de nous appuyer sur le modèle derequêtes VDL [110]. En effet, ce modèle a été étudié pour formaliser les questionsqu’un utilisateur humain peut poser à un agent [109] à propos de ses actions, etpour formaliser les réponses de celui-ci à propos de ses actions et ses décisions. Ilest ainsi particulièrement bien adapté pour la représentation d’une large gamme derequêtes en services. Nous y apportons toutefois certaines extensions et affinons lasémantique de ses requêtes afin qu’elles capturent les types de requêtes en services,des dépendances entre plusieurs requêtes, et des réponses à propos des connais-sances et des fonctionnalités des services. Nous abordons ce point plus en détaildans le chapitre suivant.

Les requêtes de l’utilisateur sont envoyées aux agents du système. Ces derniersvont alors interagir entre eux afin de les satisfaire. Leur communication est régie parun ACL [31], également présenté dans le chapitre suivant, permettant de structurerles messages échangés. Le contenu de ces messages est par ailleurs formalisé par lemême modèle de requêtes que celui utilisé pour formaliser les besoins de l’utilisa-teur. En effet, ce modèle a également été conçu de sorte à permettre la formalisationde questions et de réponses d’agents à propos de leurs capacités, ceci en réponse àdes questions et des commandes de l’utilisateur. C’est la raison pour laquelle nouspensons qu’il convient spécifiquement dans un contexte de communication (pourla coordination) d’agents introspectifs.

Chaque service abstrait offert par un agent peut se voir générer une interfaceWSDL permettant de l’invoquer sur le web. C’est ainsi que, dans notre architecture,les services peuvent être publiés et découverts à partir de registres de services web,et communiquer entre eux moyennant des protocoles standards tels que SOAP.Comme nous le voyons dans le chapitre 6, le contenu de ces messages est basé surnotre ACL, et SOAP ne sert finalement que de support à l’ACL sur le web.

La figure 2.3 illustre l’architecture décrite. Écrits entre crochets sont tous leslangages et formalismes utilisés pour supporter les différents aspects de notre ap-

2.3. MODÈLE DES AGENTS ET LEURS CONNAISSANCES 35

Figure 2.3 – Architecture combinant technologies agents et services web.

proche de chorégraphie.

2.3 Modèle des agents et leurs connaissances

Le langage dans lequel les agents sont écrits est appelé VDL-XML [109]. Celui-ci est fondé sur les arbres de réécriture en XML [91, 92]. Le code d’un agent estun arbre XML dont les nœuds représentent soit des données structurées, soit desactions, i.e. modifications à effectuer sur ces données et/ou des interactions avecd’autres agents.

L’exécution d’un agent consiste donc en la réécriture à chaque cycle d’exécutionde sa description XML en fonction des actions définies. Ainsi, un arbre VDL-XMLest à la fois le code de l’agent et le modèle dans lequel il s’exécute. C’est ce quilui permet d’avoir accès à tout instant de l’exécution à la description des don-nées qu’il manipule et des actions qu’il effectue. C’est comme ça que les capacitésd’introspection des agents sont rendues possibles.

Dans cette section, nous définissons de manière formelle les données et les ac-tions dans la couche de connaissances de l’agent.

2.3.1 La base de données

Un agent offrant un service fournit par exemple des fonctionnalités telles que lavente d’appareils électroménagers, la conversion de devises, un service de livraison, laréservation en ligne de billets de train, l’enregistrement de programmes télévisés, etc.

Soit F l’ensemble de symboles d’attributs, tels que prix, réference, taille, durée,etc.

La base de données d’un agent introspectif est un ensemble D = d1, d2, . . . ,d|D|. Chaque donnée d ∈ D est un ensemble de valeurs associées aux attributs.


Notation. Nous notons equal(f, d, value) le fait qu’un attribut f ∈ F de ladonnée d ∈ D ait la valeur value. La donnée d est ainsi caractérisée par :

d = ∧ni=1equal(fi, d, valuei) (2.1)

C’est-à-dire que la donnée d peut être définie en spécifiant l’ensemble des valeursde ses attributs.

ExempleSi un agent fournit un service de vente d’appareils photo numériques, il pourraitavoir dans sa base de données l’appareil photo c où :

c = equal(type, c, camera)∧equal(trademark, c, canon)∧

equal(ref, c,EOS40D).

Cette formule veut dire que c est un appareil photo, dont la marque est canonet la référence est EOS40D.

2.3.2 Les actions

En plus d’une base de données, les agents sont munis d’actions constituantleurs capacités. Dans le cas des agents offrant des services, nous parlons de fonc-tionnalités de services. Celles-ci peuvent alors être déployées et invoquées sur leweb.

Ainsi, chaque action d’un agent (ou fonctionnalité d’un service) est définie parun tuple A = 〈name,P,E〉 où :

– name est le nom de l’action (ex. enregistrer programmes télé, livrer matériels,convertir euro en yen, etc.) ;

– P est un ensemble de préconditions ;– E est un ensemble d’effets. Ceux-ci représentent des modifications à effectuer

sur les données de l’agent et/ou des interactions avec d’autres agents [c.f.chapitre 3, section 3.2].

Dans notre modèle, les capacités d’introspection ainsi que la coordination dy-namique des agents sont centrées sur les préconditions P seulement.

2.3.2.1 Les préconditions

Chaque action d’un agent introspectif peut être munie d’une précondition. Dansnotre modèle, nous distinguons deux types de préconditions exclusives :

1. Les patrons d’évènements décrivent les évènements qui déclenchent uneaction.

La réception d’un évènement peut être associée à l’exécution d’une action etpermet ainsi au programmeur de doter les agents d’un comportement réactif.


Un patron d’évènement apparaît dans la définition d’une action, précisémentparmi ses préconditions, et a pour rôle de spécifier le format autorisé desévènements déclenchant l’action en question.

Chaque patron d’évènement a la forme E(fii∈[1,n]) où E est le nom del’évènement et chaque fi ∈ F est un symbole d’attribut, tel que :∀i 6= j, fi 6= fj (c’est-à-dire que les symboles d’attributs dans l’évènement Esont tous différents).Par la suite, nous parlerons des fi comme d’attributs attendus par l’agentpour déclencher l’action dont le patron d’évènement E(fii∈[1,n]) est la pré-condition.

ExempleL’action acheter produit est munie de la précondition : Buy(ref, iban). Ellepeut donc être déclenchée à la réception d’un évènement s’appariant àBuy(ref, iban), et donc fournissant la référence du produit et le numéro ducompte en banque de l’acheteur.Le processus d’appariement “évènement-patron d’évènement” des agents in-trospectifs est formalisé ci-après.

Remarque. Notons que dans notre architecture, nous partons de l’hypo-thèse que tous les agents utilisent la même ontologie. Nous ne traitons doncpas dans notre travail les problématiques liées à l’utilisation d’ontologies hé-térogènes. Ainsi, le traitement du cas d’un agent attendant par exemple unévènement Record et recevant à la place l’évènement Save sort du cadre denotre étude.

Un agent peut donc déclarer des patrons d’évènement en tant que précon-ditions pour ses actions. Il peut alors recevoir un évènement, émis par unutilisateur ou un autre agent, qui a pour but de déclencher l’une de ses ac-tions.

Notation. Les évènements qu’un agent introspectif reçoit ont la formeE(p1, ..., pm). Chaque paramètre pk est une variable renseignant les valeursd’un ou plusieurs attributs fj déclarés dans un patron d’évènement. Ainsi,un paramètre p est défini par :

∧lj=1equal(fj , p, valuej) (2.2)

ExempleReprenons l’action acheter produit de l’exemple précédent. Cette action estmunie de la précondition (patron d’évènement) Buy(ref, iban). Elle peut êtredéclenchée si l’agent reçoit l’évènement suivant :

Buy(equal(ref, x,E31X ), equal(iban, y, 678))

Par la suite, pour l’équation 2.2 caractérisant les évènements, nous parlonsdes fj comme des attributs renseignés ou reçus par l’agent.


Contrairement aux données, dénotées par la formule 2.1, les paramètres nesont pas obligatoirement instanciés dans la base de données de l’agent. Ilsreprésentent des valeurs envoyés à l’agent pour être traitées.

Appariement « Évènement-Patron d’évènement »

Un évènement reçu E(pkk∈[1,m]) déclenchera une action dont la précondi-tion comprend le patron d’évènement E(fii∈[1,n]) si et seulement si :∀fi, i ∈ [1, n],∃pk, k ∈ [1,m], pk = ∧l

j=1equal(fj , pk, valuej),

tel que : ∃fj , j ∈ [1, l] et fi = fj

Autrement dit, un évènement reçu déclenchera une action si ses paramètress’apparient avec au moins tous les attributs du parton d’évènement déclaré.C’est-à-dire que s’il y a plus d’attributs reçus que d’attributs attendus, et sitous les attributs attendus sont renseignés dans les paramètres reçus, l’évè-nement est reconnu et pourra déclencher l’action. Les attributs renseignés etnon attendus sont ignorés par l’agent 1.

ExempleD’après la définition de l’appariement des évènements aux patrons d’évè-nements, l’action acheter produit est également exécutée à la réception del’évènement :Buy(equal(ref, x,E31X ),

equal(iban, y, 678) ∧ equal(bankname, y, hsbc)).Comme nous l’avons précédemment mentionné, toute information non atten-due par l’agent, telle que equal(bankname, y, hsbc), n’est pas traitée par cedernier.

Calcul des attributs manquantsDans le cas où les noms des évènements dans un patron d’évènement et unévènement reçu sont identiques, et que l’ensemble des attributs renseignésFr ne couvre pas l’ensemble des attributs attendus Fa, l’agent peut calcu-ler l’ensemble des attributs manquants Fa − Fr, i.e. ce sont les attributsattendus et qui n’ont pas été renseignés à travers les paramètres reçus.

En effet, soit un agent ayant dans ses connaissances une action dont la pré-condition est le patron d’évènement E(fii∈[1,n]). Si cet agent reçoit unévènement E(pkk∈[1,m]), où :

∀fj , j ∈ [1, l], et pk = ∧lj=1equal(fj , pk, valuej), si :

1. Dans le contexte de la coordination multiagent, les attributs reçus et non attendus par unagent peuvent cependant servir à retrouver des attributs lui faisant défaut pour le déclenchementd’une de ses actions. Nous voyons cela plus en détail dans le chapitre 4.


∃!fi, i ∈ [1, n],∧fi 6= fj → fi ∈ Fa −Fr

c’est-à-dire que s’il existe au moins un attribut attendu fi du patron d’évène-ment qui n’a été renseigné dans aucun des paramètres pk, alors fi est calculépar l’agent comment un attribut manquant fi ∈ Fa − Fr. En d’autrestermes, c’est un attribut qui n’a pas été et qui devrait être renseigné parl’agent émetteur si celui-ci veut exécuter l’action concernée.

Cette capacité d’introspection dont l’agent est doté et qui fait qu’il est capabled’analyser les attributs qui lui manquent pour déclencher une de ses actions,permettra à l’agent, dans un contexte de coordination multiagent, ou dechorégraphie de services, une décomposition et une allocation dynamique detâches.En effet, on peut considérer que l’exécution d’une tâche ou une sous-tâchedébouche sur la provision de la valeur d’un ou plusieurs attributs (ça peutpar ailleurs n’être qu’une simple confirmation d’exécution, ce qui ne changerien à notre hypothèse). Dans cette vision, la capacité d’introspection décritepermet alors à l’agent d’informer les autres de ce qu’il est capable d’accomplirau niveau de la tâche globale, lorsqu’elle lui aura été soumise, ainsi que dessous-tâches qui doivent être nécessairement réalisées par les autres agents (ouattributs manquants) pour qu’il puisse exécuter sa propre sous-tâche. Nousverrons cette partie plus en détail tout au long des chapitres 3 et 4.

2. Les conditions de garde représentent le deuxième type de préconditiondont une action peut être munie. Ce sont des expressions booléennes quidoivent être vérifiées pour que l’action soit exécutée.

Au contraire des évènements qui permettent aux agents d’être réactifs, lesconditions de garde permettent de doter les agents d’un comportement proac-tif. Plus précisément, cela se vérifie lorsqu’un agent est doté d’au moins uneaction dont la précondition est exclusivement une condition de garde.

Notation. Les conditions de garde sont dénotées par des formules DNF oùchaque proposition a la forme :

op(f, d, value) où op ∈ equal, greater, less (2.3)

Les interprétations des opérateurs de prédicats canoniques equal, greater etless sont alors comme suit :

– equal(f, d, value) est vraie ssi f(d) = value– greater(f, d, value) est vraie ssi f(d) > value– less(f, d, value) est vraie ssi f(d) < value

Ces opérateurs permettent ainsi de formaliser que la donnée d pour un certainattribut f est respectivement égale, supérieure ou inférieure à la valeur value.


ExempleL’action vendre actions en bourse est exécutée dès lors que l’une des précon-ditions suivantes est vérifiée :

(equal(type, edf, share) ∧ less(cost, edf, 30AC))∨ (equal(type, edf, share) ∧ greater(cost, edf, 250AC)).

C’est-à-dire que l’action sera vendue si son prix passe en dessous des 30AC oualors qu’il dépasse les 250AC.

Une action dont la condition de garde est vérifiée est ainsi automatiquementexécutée par l’agent. Le comportement proactif sous-tendu bénéficie alors auxservices, uniquement réactifs au départ, offerts par les agents.

2.3.3 Synthèse du modèle d’agent introspectif

Notre architecture permet aux agents de stocker des données et de se munird’actions ou de fonctionnalités.

La spécification de ces actions et notamment leurs préconditions, permet auxagents et aux services qu’ils offrent de se comporter aussi bien de manière réac-tive que proactive. De plus, grâce à leur capacité d’introspection, les agents sontcapables d’examiner les évènements reçus et de calculer les informations leur fai-sant défaut, en fonction de leurs propres actions, afin que l’évènement soit pris encompte.

Dans notre approche de chorégraphie, l’introspection des agents a pour objectifde permettre la décomposition et l’allocation dynamique d’une tâche à accomplir,ou sur le web, d’un besoin/requête en services à satisfaire. En effet, à partir del’énonciation d’une tâche à réaliser, un agent introspectif pourra :

– examiner en fonction de ses capacités s’il est capable d’accomplir seul ou nonl’intégralité de la tâche.

– si non, s’il y a une part de la tâche (une sous-tâche) qu’il peut prendre encharge. Et dans ce cas, laquelle.

– s’il est capable de prendre part à la réalisation de la tâche, quelles informa-tions il requiert pour son exécution si celle-ci dépend d’autres sous-tâches.

En conséquence, dans le contexte de la chorégraphie de services, chaque agentpourra s’allouer un sous-but en fonction de ses compétences et interagir avec lesautres agents afin de pallier ses limites et couvrir l’intégralité du but de compositionà satisfaire.

Dans les prochains chapitres, nous voyons plus amplement comment l’agent ex-ploite ses capacités d’introspection pour la décomposition et l’allocation dynamiqued’une tâche.

2.4 Conclusion

Nous avons donné une description globale de notre approche de chorégraphiede services et brièvement introduit ses composants tout au long de ce chapitre.

2.4. CONCLUSION 41

Nous avons notamment présenté l’architecture orientée services sur laquelle notreapproche s’appuie. Celle-ci est fondée sur un système multiagent constitué d’agentsintrospectifs, i.e. des agents offrant des services sur lesquels ils peuvent raisonner.Nous avons décrit la structure de ces agents et formalisé les connaissances surlesquelles se fondent leurs capacités d’introspection.

Le SMA sur lequel notre architecture se base permettra d’implanter la chorégra-phie des services à travers la coordination des agents du système. La particularitéde notre approche est qu’elle s’appuie sur des agents capables d’examiner et deraisonner sur leurs propres actions. Cette capacité d’introspection a pour but deleur permettre de décomposer et de s’allouer dynamiquement une tâche à réaliser(le but de composition dans le contexte de la chorégraphie de services) en se ba-sant sur leurs compétences. Dans cette configuration, la coordination a pour rôlede faire collaborer les agents pour que chacun participe à la réalisation de la tâcheen fonction de ses capacités mais aussi qu’il pallie les limites des autres agents dansleur traitement de la tâche globale.

Nous avons donc besoin de formaliser cette tâche et disposer d’un langagepermettant aux agents de communiquer à propos de cette tâche en fonction deleurs capacités. Ce sont les deux points dont le chapitre suivant fait l’objet.


Chapitre 3

Modèle de requêtes etcommunication entre agentsintrospectifs

L’une des problématiques à laquelle la composition de services fait faceest le fait qu’il n’existe pas de recommandation ou de langage permettant de poserdes requêtes en services et de retrouver et combiner des services satisfaisant leproblème posé.

En réponse à cette problématique, nous proposons une solution en deux parties :formaliser les besoins de l’utilisateur d’une part, et munir les agents/services decapacités et de protocoles leur permettant de traiter ces besoins d’autre part.

En effet, nous proposons dans le présent chapitre une formalisation en un en-semble de requêtes et de contraintes des besoins de l’utilisateur. Nous présentonsle modèle de requêtes permettant de formaliser les requêtes de l’utilisateur et spé-cifions formellement la syntaxe et la sémantique des différents types de requêtesutilisés. Par ailleurs, nous décrivons le langage de communication entre agents(ACL), permettant à ces derniers de prendre en compte les besoins énoncés maisaussi de répondre en tenant compte de leurs propres capacités. Enfin, nous présen-tons l’algorithme employé par les agents pour traiter les requêtes reçues en fonctionde leurs compétences. Nous donnons des exemples tout au long de nos descriptionspour illustrer nos propos.

3.1 Formalisation des besoins de l’utilisateur et modèlede requêtes

La coordination des agents ou la chorégraphie des services a pour but de sa-tisfaire un ensemble des besoins énoncés par l’utilisateur. Nous formalisons ceux-cipar la paire Υ def= 〈R,C〉 où :

43

44 CHAPITRE 3. MODÈLE DE REQUÊTES ET ACL

– R est un ensemble de requêtes, i.e. questions ou commandes sur des services.Chaque requête r ∈ R est formellement représentée par le modèle de requêtesque nous présentons ci-après [c.f. sections 3.1.1 et 3.1.2] ;

– C un ensemble de contraintes globales sur les services demandés. Chaquecontrainte c ∈ C est une expression booléenne sur les valeurs des résultatsfournis par deux ou plusieurs services.

Nous revenons à la fin de cette section sur les besoins de l’utilisateur en pro-posant une formalisation des requêtes et des contraintes globales, accompagnée deplusieurs exemples, à l’issue de la présentation du modèle de requêtes.

Dans notre approche de coordination, ce modèle intervient aussi bien dans lesdialogues humain-agent que les dialogues inter-agent. Il est basé sur le modèle derequêtes VDL (acronyme de View Design Language) proposé dans [109]. Ce der-nier a en effet été spécifié afin de pouvoir représenter des requêtes de bon sens àun composant actif à propos de ses actions. Nous choisissons ce modèle dans notreapproche pour son potentiel à représenter une large gamme de requêtes en services.Cependant, nous devons adapter ses actes de langage et les étendre afin de tenircompte du contexte de coordination des agents et de l’expression de certaines ca-ractéristiques, notamment d’introspection et de décomposition de tâches, de notreapproche.

3.1.1 Syntaxe des requêtes

Le modèle de requêtes que nous présentons est utilisé dans notre approche pourformaliser les besoins de l’utilisateur, mais aussi le contenu des messages échangésentre agents. Parce qu’il est employé dans les interactions humain-agent et inter-agents, il comprend plusieurs types de requêtes, dont des questions, des commandes,des assertions, etc. Nous définissons formellement ces requêtes comme suit.

Une requête est une paire :r

def= 〈α, γ〉 (3.1)

où α est un performatif et γ est le contenu (ou l’objet) de la requête. Paranalogie à la théorie des actes de langage [111], le performatif α peut être assimiléà l’acte illocutoire, et le contenu de la requête γ au contenu propositionnel.

Les performatifs de notre modèle ont été proposés afin de répondre au besoind’expressivité dans les interactions humain-agent et inter-agents, pour la coordina-tion multiagent visant à satisfaire les besoins de l’utilisateur. Le performatif α dela requête peut ainsi prendre les valeurs suivantes :

– What-is : pour les requêtes qui représentent les questions à propos des donnéesde l’agent.Par exemple, « Quelle est la durée du vol LH710 ? ».

– Assert-is : pour les assertions à propos des valeurs des données de l’agent (enréponse aux requêtes What-is).Par exemple, « La durée du vol LH710 est de 12 heures ».ou « Le vol LH710 part de Tokyo et arrive à Frankfort ».

3.1. MODÈLE DE REQUÊTES ET BESOINS DE L’UTILISATEUR 45

– Order : pour commander l’exécution d’une action étant donné un ensemblede paramètres, i.e. moyennant l’envoi d’un évènement.Par exemple, « Réserve un billet pour le vol LH710 ».ou encore, « Livre le piano à Monzen-Nakacho ».

– Ack : pour les confirmations d’exécution d’actions (en réponse aux requêtesOrder).Par exemple, « Livraison à Monzen-Nakacho effectuée ».

– Assert-cannot : pour exprimer qu’un agent est incapable d’exécuter une ac-tion.Par exemple, « Je ne fais pas de livraison ».

– Assert-can : pour exprimer qu’un agent peut exécuter une commande, moyen-nant certains paramètres.Par exemple, « Je peux effectuer la livraison, mais il me faut l’adresse exactede livraison ».ou encore, « Je peux enregistrer le programme télé, mais il me manque sonheure de diffusion ».

– Unknown : pour exprimer qu’une entité demandée n’a pas été reconnue del’agent.Par exemple, « Je n’ai pas de programme télé ».ou encore, « Je n’ai aucune chambre d’hôtel ».

– Missing : pour communiquer les valeurs d’attributs que l’agent n’a pas pu in-terpréter. Cela se produit, lorsqu’une requête reçue présente des dépendancesavec d’autres requêtes.Par exemple, un agent peut recevoir la commande « Réserve une chambred’hôtel aux dates de la conférence MFI’07 » qui est dépendante de la requête« Quelles sont les dates de la conférence MFI’07 ».Si l’agent ne possède pas encore les informations à propos de la conférence, ilrépond alors « Je ne connais pas les dates de la conférence MFI’07 ». C’estcette dernière requête qui est exprimée moyennant un performatif Missing.Nous revenons dans la section 3.1.2.1 sur les dépendances entre requêtes etformalisons l’expression d’un attribut qui dépend de la résolution d’une autrerequête.

Ainsi, What-is, Assert-is, Order, Ack, Assert-cannot, Assert-can, Unknown, Missingest l’ensemble de performatifs que nous utilisons dans la formalisation des requêtesde l’utilisateur ainsi que dans la représentation des réponses des agents. Le contenud’une requête, dont le performatif appartient à cet ensemble, a alors la forme décriteci-dessous.

3.1.2 Sémantique des requêtes

Le contenu d’une requête dépend fortement de son performatif. La combinaisondes deux détermine la sémantique formelle d’une requête.


α γ

What-is selections|contraintesAssert-is D′Missing selections

Unknown F ′Order E(p1, ..., pm)

Ack

Assert-cannot E

Assert-can E,F ′

Table 3.1 – Syntaxe et sémantique du modèle de requêtes.

Le tableau 3.1 reporte pour chaque performatif α de notre modèle, la formecorrespondante du contenu γ de la requête. Ces formes sont définies comme suit.

Soit D l’ensemble des données d’un agent, et F l’ensemble des symboles d’at-tributs.

Lorsque α=What-is – le contenu a la forme : γ =selections|contraintes.– selections est un ensemble de f(x) avec f un symbole d’attribut (tel queprix, durée, référence) et x une variable ;

– contraintes une conjonction de op(f ′, x, value) où op est un symbole deprédicat canonique dont les valeurs et l’interprétation ont été données dansle chapitre 2 [c.f. section 2, page 39].

ExempleLa requête « Je voudrais le prix et la référence d’un appareil photo dont larésolution est supérieur à 8 Méga pixels » aura le contenu :

γ = price(x), reference(x) |equal(type, x, camera) ∧ greater(resolution, x, 8Mpx).

– price(x) et reference(x) sont des sélections ;– equal(type, x, camera) ∧ greater(resolution, x, 8Mpx) réprésente une contrainte

locale spécifiant les caractéristiques de la donnée recherchée.

Par ailleurs, tout comme dans SQL, on peut utiliser le mot clé ∗ au lieu del’attribut f pour obtenir tous les attributs à propos d’une donnée dans labase de données.

Par exemple, si l’on veut obtenir les valeurs de tous les attributs, tels quela marque, les durées d’exposition, la résolution, etc, de l’appareil photo de-mandé, le contenu de la requête s’écrira comme suit :

γ = ∗(x) | equal(type, x, camera) ∧ greater(resolution, x, 8Mpx).

Lorsque α=Assert-is – le contenu est un ensemble de données D′ ⊆ D dans la basede données de l’agent, où chaque donnée d ∈ D′ est définie par l’expression2.1 du chapitre 2 [c.f. page 36].


ExempleL’assertion « La durée du vol LH710 est de 12 heures » aura le contenusuivant : γ = equal(flightnum, l, LH710) ∧ equal(duration, l, 12 hours).

Lorsque α=Missing – le contenu est un ensemble de selections.Plus précisément, ces sélections ont la forme g(request-get), où g est un sym-bole d’attribut dont la valeur fait justement défaut à l’agent. Comme nous levoyons à la fin de cette section, dans la formalisation des dépendances entreles requêtes, le mot-clé request-get indique que cette valeur est attendue dela résolution d’une autre requête.Par ailleurs, lorsque nous parlons de sélection indéfinie , c’est une sélectionde la forme g(request-get) que nous désignons.

ExempleLa requête « Je ne connais pas les dates de la conférence MFI’07 » aura unperformatif Missing et un contenu :γ=conf -start(request-get), conf -end(request-get).

Lorsque α=Unknown – le contenu est un ensemble d’attributs F ′.

ExempleLorsqu’une donnée demandée est inconnue de l’agent, comme dans la requête« Je n’ai pas d’appareil photo dont la résolution est supérieure à 8Mpx », leperformatif sera Unknown et le contenu s’écrira : γ = ∗.Lorsqu’il ne s’agit que d’un attribut en particulier, par exemple la duréed’exposition, le contenu s’écrira : γ = expo-duration.

Lorsque α ∈ Order,Ack – le contenu de la requête est un évènementE(p1, ..., pm).Ce dernier étant formellement défini par l’équation 2.2 du précédent chapitre[c.f. page 37].

ExempleLa commande « Achète l’appareil photo canon avec la carte de crédit 6512 »aura le contenu suivant :γ = Buy(equal(product, x, camera) ∧ equal(trademark, x, canon),equal(credit-card, y, 6512)).

Ou la commande « Livre le piano à Monzen-Nakacho » aura comme contenu :γ = Deliver(equal(adr, x,Monzen-Nakacho)∧

equal(delivrable, x, piano)).

La confirmation d’exécution d’une commande a par défaut le même contenuque la commande elle-même. Cependant, si la commande a déclenché l’exécu-tion d’une action dont les effets consistent à envoyer un message, par exempleun message d’information regroupant le coût et la date de livraison, soncontenu est inclus dans la confirmation d’exécution.


Ainsi, la confirmation « Livraison du piano à Monzen-Nakacho effectuée le13/08/2007 au prix de 20000U » aura le contenu :γ = Deliver(equal(delivery-date, x, 13/08/07)∧

equal(price, x, 20000U)).

Lorsque α=Assert-cannot – le contenu est le nom de l’évènement E qui n’a paspu être traité.

ExempleLa requête « Je ne fais pas de livraison » aura le contenu :γ = Deliver.

Lorsque α=Assert-can – le contenu est une paire (E,F ′) où E est le nom del’évènement (connu de l’agent) et F ′ ⊆ F est un ensemble de symboles d’at-tributs. Ces attributs sont ceux manquant dans l’évènement reçu pour quel’agent puisse exécuter l’action.

ExempleLa requête « Je peux réserver une chambre d’hôtel, mais pour ce faire, j’aibesoin de connaître la date de départ » peut être formalisée par une requêteAssert-can dont le contenu est :γ = Book, checkOut-date.

Notation. Pour faciliter la lecture des requêtes, nous utiliserons la notation α(γ)pour les écrire. Par exemple, la requête « Je peux réserver, mais il me manque ladate de départ » s’écrira :

Assert-can(Book, checkOut-date)

ou encore la requête « Quelles sont les informations relatives au vol LH710 »s’écrira :

What-is(∗(x)|equal(flightnum, x, LH710))

3.1.2.1 Dépendances entre requêtes

Notre modèle permet de formuler des dépendances entre les requêtes, notam-ment au niveau des requêtes What-is et Order. Cela permet d’exprimer des re-quêtes dont certains paramètres ou contraintes ne sont pas connus a priori car ilsdépendent du résultat de la résolution d’autres requêtes.

Comme nous le voyons ci-dessous, ces dernières ne sont pas explicitement spéci-fiées dans l’expression de la dépendance. Seuls les attributs dont les valeurs ne sontpas connues a priori sont précisés. C’est le rôle des agents de déterminer ensuiteles requêtes dépendantes et celles dont elles dépendent.

Une requête présente des dépendances dans les deux cas suivants :


– Soit une requête r=What-is(selections|c1 ∧ c2, . . .).Si ∃k tel que ck = op(f ′, x, g(request-get)), alors la requête r est dépendantede celle qui fournira la valeur de l’attribut g.

En effet, l’expression (ou sélection indéfinie) g(request-get) désigne la valeurde l’attribut g, et indique via le mot-clé request-get que celle-ci est censée êtreobtenue par la résolution d’une des requêtes de l’utilisateur.

ExempleSoit la requête suivante :r=What-is(ref -card(x)|equal(type, x,memory-card)∧

greater(storage-capacity, x, 1Go)∧equal(compliant-with, x, ref -camera(request-get))).

Cette requête demande ainsi la référence d’une carte mémoire. La capacitéde stockage de celle-ci doit être supérieure à 1Go et son modèle doit êtrecompatible avec la référence d’un appareil photo devant être obtenue par larésolution d’une des requêtes de l’utilisateur.En conséquence, cette requête est dépendante de celle qui fournira la valeurde l’attribut ref -camera.

– Soit une commande r=Order(E(p1, p2, . . .).Si ∃k tel que pk = ∧l

j=1op(fj , x, valuej) et ∃j tel que valuej=g(request-get),alors la requête r est de même dépendante de celle qui fournira la valeur del’attribut g.

ExempleReprenons l’exemple de la commande « Réserve une chambre d’hôtel auxdates de la conférence MFI’07 ». Celle-ci est alors formalisée par :r=Order(Reserve(equal(type, x, single-room)∧

equal(checkIn-date, x, conf -start(request-get)))∧equal(checkOut-date, x, conf -end(request-get)))).

Cette commande est donc dépendante des requêtes qui fourniront les valeursdes attributs conf -start et conf -end.

De plus amples définitions sont données dans le chapitre 5 [c.f. section 5.1.1,page 97].

Remarque. Dans notre modèle, puisque nous ne traitons pas les problèmes sur-venant de l’utilisation d’ontologies hétérogènes, nous faisons l’hypothèse que deuxdifférents attributs (ex. la référence d’une carte mémoire et la référence d’un ap-pareil photo) ont deux symboles différents (ex. ref -card et ref -camera).

3.1.3 Formalisation des besoins de l’utilisateur

Comme nous l’introduisions au début de cette section, les besoins de l’utilisateurΥ sont formalisés en un ensemble de requêtes R et un ensemble de contraintesglobales C.


3.1.3.1 Les requêtes

Un utilisateur peut formuler un ensemble R de requêtes. Chaque requête r ∈R peut être soit de type commande, i.e. requêtes de performatif Order, soit unequestion sur des données, i.e. requêtes de performatif What-is.

ExempleVoici deux exemples de requêtes en services d’un utilisateur, accompgnées de leurformalisation. La première est la commande : « Réserve une suite à l’hôtel Bristolpour le 10/12/2007 ». Elle est formalisée par :

Order(Reserve(equal(type, x, suite) ∧ equal(hotel, x, bristol)∧equal(checkIn-date, x, 10/12/07)).

La seconde est une requête sur un produit : « Quels sont tous les modèles d’aspi-rateur dotés d’un filtre HEPA dont la puissance est d’au moins 1800 Watts et dontle bruit n’excède pas 70 dB ». Elle est formalisée par :

What-is(∗(x)|equal(type, x, vacuum-cleaner) ∧ equal(filter, x,HEPA)∧greater(power, x, 1800 Watts) ∧ less(noise, x, 70 dB)).

Moyennant ces types de requêtes, sur le web ou dans un environnement d’in-telligence ambiante, un utilisateur pourra commander des services ou alors poserdes questions à propos des données ou produits proposés par un service.

Dans notre travail, nous traitons essentiellement les demandes pouvant néces-siter le concours et la collaboration de plusieurs compétences. En particulier, unecommande Order peut n’être exécutée qu’en combinant les fonctionnalités de deuxou plusieurs services, et les requêtes Order et What-is peuvent porter sur une donnéedépendante du résultat d’une autre requête (ex. « Je veux réserver une chambred’hôtel aux dates de la conférence MFI’07 » ou « Je veux un appareil photo dotéd’un écran 3 pouces et d’une résolution de 8 Méga, et je veux la référence des cartesmémoires compatibles avec cet appareil »).

Dans notre approche, les requêtes de l’utilisateur sont satisfaites à travers lacoordination des agents. Nous présentons le protocole d’interaction utilisé à cettefin dans le chapitre 4.

3.1.3.2 Les contraintes globales

Une contrainte globale c ∈ C est une contrainte portant sur le résultat de deuxou plusieurs services. Ainsi, C ne peut être spécifié que si |R| > 1.

Notons que l’objet de notre travail étant focalisé sur la coordination des agents,nous ne proposons ici qu’un modèle simple pour formaliser les contraintes globales.Celui-ci limite l’expressivité des contraintes globales mais peut par la suite êtreétendu sans affecter l’approche de coordination.

Il permet toutefois à l’utilisateur d’exprimer un sous-ensemble de contraintesglobales telles que « la somme des prix de l’appareil photo et de sa livraison nedoit pas dépasser 200AC », que nous proposons de traiter moyennant l’algorithme


présenté au chapitre 5. Celui-ci fournit à l’utilisateur, à partir d’un ensemble deréponses de services à ses requêtes, l’identité des services ainsi que leurs réponses,respectant la contrainte exprimée.

Notation. Une contrainte globale est une expression booléenne

opcg(symbii∈[0,z−1], fii∈[0,z], value) (3.2)

– opcg ∈ equalcg, greatercg, lesscg ;– symbi ∈ +,−,×,÷ ;– fi ∈ F sont des symboles d’attributs ;– z 6 |R| (i.e. le nombre de requêtes de l’utilisateur) ;

L’expression 3.2 indique que les valeurs des attributs fi, obtenues à l’issue dela coordination des agents (i.e. suite à la résolution des requêtes de l’utilisateur),combinées par les symboles symbi, doivent respecter la valeur value.

Pour représenter cette combinaison, nous définissons la fonction ./ comme suit.Soient symbi ∈ +,−,×,÷ et valuei la valeur de l’attribut fi (obtenue à l’issuede la coordination des agents). La fonction ./ pour représenter la combinaison dessymboles symbi et des attributs fi est alors définie par :

./ (symbii<z, fii6z)⇐⇒value1 (symb1) value2 (symb2) . . . (symbz−1) valuez

Selon le symbole de l’opération opcg, l’expression 3.2 est interprétée par :– ./ (symbii<z, fii6z) < value, si opcg=lesscg ;– ./ (symbii<z, fii6z) > value, si opcg=greatercg ;– ./ (symbii<z, fii6z) = value, si opcg=equalcg.

ExempleReprenons l’exemple de l’utilisateur souhaitant acquérir un aspirateur et sup-

posons qu’il souhaite également se le faire livrer. Sa demande est alors formaliséecomme suit :

r1=What-is(∗(x)|equal(type, x, vacuum-cleaner)).r2=Order(Deliver(equal(ref, y, ref -product(request-get)))).

Si l’on suppose que cet utilisateur veuille que l’achat et la livraison de sonproduit ne dépasse pas 70AC, sa contrainte serait formalisée comme suit :

lesscg(+, product-price, delivery-price, 70AC).

Si l’on suppose que valueproduct-price et valuedelivery-price sont respectivementles valeurs des attributs product-price et delivery-price obtenues à l’issue de lacoordination des agents pour la résolution des requêtes r1 et r2, alors la précédentecontrainte peut être interprétée comme suit :

valueproduct-price + valuedelivery-price < 70AC.


3.2 Langage de communication entre agents

Un langage de communication est conçu pour l’échange, entre logiciels (agents),d’informations, de connaissances ou encore de services [78]. Dans notre architecture,les agents sont munis d’un ACL leur permettant de communiquer à propos desbesoins de l’utilisateur et de construire des contenus de messages exprimant desinformations à propos de leurs capacités [28].

3.2.1 Envoi de messages

Un agent envoie un message dans deux cas de figure :

1. S’il a reçu un message nécessitant d’être traité, il construit alors un messagepour répondre à celui qu’il a reçu et l’envoie à l’émetteur de ce dernier ;

2. S’il exécute une action dont les effets consistent en l’envoi d’un ou plusieursmessages, alors il construit ces messages et les envoie au(x) destinataire(s)spécifié(s).

3.2.2 Contenu des messages

En contraste avec les messages KQML et FIPA-ACL, où est exprimée une seulevaleur d’illocution appliquée à un seul contenu propositionnel, nos agents peuventau contraire traiter un ensemble de requêtes rkk∈[1,s], chacune comportant unperformatif et un contenu.

En effet, les langages KQML et FIPA-ACL ont été conçu pour des besoins ap-plicatifs, le plus souvent liés à l’échange d’informations et de connaissances. Cesmodèles ne sont cependant pas adaptés à des interactions de types conversation-nel, en particulier lorsqu’il s’agit de communautés impliquant agents artificiels ethumains.

C’est dans cette optique que nous avons conçu notre ACL. Il est un moyen pourles agents non seulement de communiquer et d’exprimer une large gamme d’infor-mations, mais aussi de pouvoir directement traiter les besoins de l’utilisateur aveclequel ils interagissent. En effet, ces besoins peuvent être complexes et doivent par-fois être formalisés en un ensemble de requêtes qui se complètent et dont certainesdépendent des résultats des autres. Ces besoins peuvent ainsi être manipulés parles agents, moyennant leur ACL. Leur traitement s’effectuera ensuite, en fonctionde la capacité des agents à répondre à tout ou partie de ces besoins, soit au ni-veau de leur module de raisonnement, i.e. le RPM, soit au niveau du protocole decoordination.

3.2.3 Syntaxe des messages

Pour construire les messages échangés entre les agents, ceux-ci utilisent un lan-gage de communication appelé VDL-ACL. Similairement aux messages KQML [48]et FIPA-ACL [119], un message VDL-ACL comprend un niveau de communicationet un niveau contenu :

3.2. LANGAGE DE COMMUNICATION ENTRE AGENTS 53

1. Le niveau communication permet d’identifier les agents émetteur et récep-teur, et précise l’identifiant du message ainsi que l’identifiant de celui auquelil est construit en réponse (i.e. le message d’origine). De plus, ce niveau af-fecte un identifiant de la conversation à laquelle appartient ce message, i.e.c’est un identifiant commun à l’ensemble des messages générés pour la satis-faction d’un même ensemble de besoins de l’utilisateur, et les identifiants desrequêtes auxquelles le message répond [c.f. section 3.2.4].

2. Le niveau contenu englobe le contenu du message. Celui-ci est constituéd’un ensemble de requêtes dont la syntaxe et la sémantique ont précédemmentété définies.

Chaque message a ainsi la syntaxe suivante :

m = [ sender,receiver,conv-id,reply-with,in-reply-to,req-id,content ]

(3.3)

– sender est l’identifiant de l’agent émetteur ;– receiver est l’identifiant de l’agent récepteur ;– conv-id est l’identifiant de la conversation dans laquelle le message m est

impliqué. Une conversation réfère l’ensemble des messages générés pour sa-tisfaire un même ensemble de besoins de l’utilisateur ;

– reply-with est l’identifiant du message m ;– in-reply-to est l’identifiant du message auquel m est construit en réponse ;– req-id est un tableau regroupant les identifiants des requêtes auxquelles m

répond ;– content est le contenu du message.

3.2.4 Construction des messages réponses

Soit m un message reçu par l’agent b. Sa structure est la suivante :

m = [sender : a,receiver : b,conv-id : convid,reply-with : id-rw,in-reply-to : id-irt,req-id : tab-id,content : C]

Dans notre modèle, lorsque ce message comporte dans son contenu les besoinsde l’utilisateur, le champ in-reply-to est à null. Ce type de message est alorsappelé un message initiateur.


Définition 1 Un message initiateur est un message dont le contenu englobe lesbesoins de l’utilisateur. Il initie les interactions entre les agents qui vont collaborerpour satisfaire les besoins qu’il véhicule. Le champ in-reply-to d’un tel messageest égal à null.

Un message m′ construit en réponse à m aura la même valeur du champconv-id. De plus, la valeur de son champ in-reply-to sera égale à la valeurdu champ reply-with de m. La valeur de son champ reply-with sera quant à ellegénérée automatiquement.

Concernant le contenu du message réponse m′, il comportera une ou plusieursrequêtes réponses à celles contenues dans m. En effet, le contenu d’un messagereçu m est un ensemble de requêtes C = rkk∈[1,s]. Cependant, un ou plusieursmessages peuvent être construit en réponse à m. Cela dépend du types des requêtescontenues dans m et de l’identité des agents destinataires de leurs réponses (nousvoyons cela plus en détail dans le prochain chapitre dans la section 4.3.2).

Ainsi, un messagem′, construit en réponse àm, peut ne comporter des requêtesréponses C′ = ρkk∈[1,t],t6s qu’à un sous-ensemble des requêtes C. En fonction desrequêtes auxquelles m′ répond, le tableau req-id est affecté en conséquence (demême, ce point est plus explicité dans le prochain chapitre).

Si par exemple le message m′ comporte les réponses aux requêtes r2, r4 et r5contenues dans m, sa structure sera la suivante :

m′ = [sender : b,receiver : a,conv-id : convidreply-with :, new(idrw)in-reply-to : id-rw,req-id : [2, 4, 5],content : C′ = ρ1, ρ2, ρ3]

3.3 Traitement des requêtes par le RPM

Les agents sont munis d’un module de traitement des requêtes, le RPM, qui esten charge de construire, en fonction des capacités de l’agent, les réponses corres-pondantes :

– aux questions sur les données de l’agent (requêtes de performatif What-is) ;– et aux commandes (requêtes de performatif Order).

Pour les autres types de requêtes, i.e. requêtes de performatif Unknown, Missing,Assert-can, Assert-is, etc, leur traitement dépend des interactions et des actions desautres agents. Nous voyons ce traitement, dans le chapitre 4, au niveau du protocolede coordination.

Le tableau 3.2 reporte les performatifs des requêtes qu’un agent peut traiterau niveau du RPM, le performatif de la réponse dans le cas où il a été capable derépondre à la requête (Cas de succès dans le tableau), le performatif de la réponsedans le cas contraire (Cas d’échec) mais également le performatif de sa réponse

3.3. TRAITEMENT DES REQUÊTES PAR LE RPM 55

Type de requête Cas de succès Cas d’échec Cas alternatifWhat-is Assert-is Unknown Missing

Order Ack Assert-cannotMissingAssert-can

Table 3.2 – Requêtes et leurs réponses correspondantes construites par le RPM.

lorsqu’il a été capable de répondre à une partie de la requête (Cas alternatif ). Desexemples concrets sont donnés ci-après.

3.3.1 Requêtes What-is

Lorsqu’un agent reçoit une requête What-is(selections|contraintes), il la traitecomme suit.

Soit What-is(selections|c1 ∧ c2 ∧ . . .) la requête que l’agent reçoit, où chaquecontrainte cj a la forme cj = opj(fj , x, valuej).

Si ∃cj telle que cj = opj(fj , x, g(request-get)), et si l’agent ne possède pas lavaleur g(request-get), alors il construit la réponse Missing(g(request-get)).

Autrement, il procède comme suit.Soit cet agent comprenant dans sa base de données la donnée d ∈ D, où d est

définie par ∧iequal(fi, d, valuei).

On dit que les contraintes = c1 ∧ c2 ∧ . . . d’une requête sont vérifiées dans labase de données D d’un agent, et on le dénote par contraintes b D, si ∀fj , ∃fi telque :

– valuej = valuei, si opj désigne equal ;– valuej > valuei, si opj désigne greater ;– valuej < valuei, si opj désigne less ;

Soient alors les selections demandées par la requête reçue. Afin de formaliserque la valeur d’une sélection f(x) est définie à l’intérieur d’une donnée d, nousdéfinissons la fonction ∝ comme suit :

On dit qu’une sélection f(x) est définie dans d ssi f ∝ d où :

f ∝ d =⇒ ∃i, fi = f

Ainsi, si la donnée d comprend le terme equal(fi, d, valuei) alors : f ∝ d envaluei.

Nous utilisons également cette fonction pour les sélections indéfinies.Ainsi g(request-get) ∝ d ssi g ∝ d.

Reprenons les selections demandées par la requête reçue :– Si selections=∗(x), alors la réponse à la requête What-is est Assert-is(d).

Si contraintes b D′ ⊆ D, i.e. si plusieurs données de D′ ⊆ D vérifient lescontraintes de la requête reçue, alors la réponse à construire est Assert-is(D′) ;


– Si selections=f(x) :– Si f(x) ∝ d, alors la réponse à la requête reçue est Assert-is(valuei) ;– Sinon, la réponse à la requête reçue est Unknown(∗) ;

ExempleSoit un agent de vente d’appareils numériques. Supposons qu’il reçoive la requête

suivante :What-is(∗(x)| equal(type, x, camera) ∧ greater(resolution, x, 8Mpx)∧

less(price, x, 300AC))À travers cette requête, l’utilisateur veut demander tous les appareils photo,

avec l’ensemble des valeurs de leurs attributs ∗(x), dont la résolution est supérieureà 8 Méga pixels et dont le prix est inférieur à 300AC.

Si l’on suppose que cet agent a deux appareils photo d1 et d2 correspondantsà ces critères, il construira alors la réponse Assert-is(d1, d2) tels que d1 et d2 sontrespectivement formalisés par :

equal(type, d1, camera) ∧ equal(ref, d1,A550) ∧ equal(price, d1, 260AC) ;equal(type, d2, camera) ∧ equal(ref, d2,A710) ∧ equal(price, d2, 180AC).

Remarque. Pour des soucis de lisibilité, nous utiliserons pour les assertionsl’écriture compacte Assert-is(d1, d2, . . .) où chaque symbole de donnée di remplaceson expression ∧kequal(fk, di, valuek).

Le traitement des requêtes What-is est spécifié par l’algorithme 1 où b est lafonction qui retourne qu’un ensemble de contraintes sont vérifiées dans un ensemblede données, et ∝ est la fonction qui retourne qu’une sélection est définie dans unedonnée.

3.3.2 Requêtes Order

Lorsqu’un agent reçoit une commande Order(E(p1, p2, . . .)), où E est le nomd’un évènement et pi des paramètres, le traitement qu’il lui applique est commesuit.

Soient les actions A1, A2, . . . dont l’agent est doté, et soit les actions Aj dontla précondition est le patron d’évènement Tj(f1, f2, . . .).

– Si ∀Aj E 6= Tj , alors l’agent construit la réponse Assert-cannot(E).– Si au contraire ∃Aj telle que E = Tj , on dit que l’évènement E est reconnu

par l’agent. Soit alors Fa l’ensemble des attributs attendus par d’évènementTj , et soit Fr l’ensemble des attributs reçus (i.e. renseignés) :– Si Fa−Fr = ∅, i.e. si tous les attributs attendus ont été renseignés dans

les paramètres reçus, alors l’agent exécute la commande et construit uneconfirmation d’exécution Ack.

– Sinon si Fa − Fr = F ′, i.e. s’il existe un sous-ensemble d’attributs at-tendus non renseignés, alors l’agent construit la réponse Assert-can(E,F ′).

– Si ∃pi tel que pi = ∧kequal(fk, x, valuek) et valuek=g(request-get), alorsl’agent construit la réponse Missing(g(request-get)).

3.3. TRAITEMENT DES REQUÊTES PAR LE RPM 57

Algorithm 1 Traitement des requêtes What-is par le RPM.Entrées: r = 〈What-is, selections|contraintes〉 la requête reçue.Sorties: ρ la requête construite en réponse à r.1: si act(r)=What-is alors2: si contraintes b D′ ⊆ D alors3: si selections=∗(x) alors4: ρ← 〈Assert-is, D′〉 ;5: sinon si selections=f(x) et f ∝ d ∈ D′ en value alors6: ρ← 〈Assert-is, value〉 ;7: sinon8: ρ← 〈Unknown, ∗〉 ;9: finsi10: sinon11: Soit k ← 0 ;12: pour ∃ cj ∈ contraintes et valuej=g(request-get) faire13: ρk ← 〈Missing, g(request-get)〉 ;14: k++ ;15: fin pour16: finsi17: finsi

Dans le cas où l’agent a reconnu l’évènement reçu et a pu exécuter l’action Aj

dont cet évènement est la précondition, l’objet de sa confirmation d’exécution Ackest comme suit :

– Si aucun message n’est envoyé à l’issue de l’exécution de Aj , alors la réponseconstruite est Ack(E(p1, p2, . . .)).

– Sinon, l’action exécutée Aj a pour effet l’envoi d’un message. Dans notremodèle, celui-ci véhiculera une assertion à propos de l’action exécutée. SoitS = s1, s2, . . ., où chaque si = ∧lequal(fl, x, valuel), le contenu de cetteassertion. La confirmation d’exécution construite sera alors Ack(E(S)).

ExempleSoit un agent convertisseur Euro-Yen recevant l’ordre de convertir 100AC à travers

la requête Order(ConvertEuroY en(100AC)).Supposons que l’action convertir euro en yen de cet agent émet suite à son

exécution, à travers un message, le résultat de la conversation. Dans notre exemple,le résultat émis est :

equal(converted, 100AC, 16500U).En conséquence, la réponse construite par l’agent est :

Ack(ConvertEuroY en(equal(converted, 100AC, 16500U))).

Si aucun message n’est envoyé à l’issue de l’exécution de l’action, l’agent construitla réponse Ack(ConvertEuroY en(100AC)).

Si cette requête avait été reçue par un agent Calcul itinéraire n’ayant pas reconnul’évènement ConvertEuroY en, sa réponse serait :

Assert-cannot(ConvertEuroY en).


Le traitement des commandes Order par le RPM est spécifié par l’algorithme 2où known est la fonction qui retourne vrai lorsqu’un évènement est reconnu parun agent, et get-effect est la fonction qui retourne le contenu du message émis(plus précisément l’objet de l’assertion émise) comme effet de l’exécution de l’actiondéclenchée par la commande reçue.

Algorithm 2 Traitement des requêtes Order par le RPM.Entrées: r = 〈Order, E(p1, . . . , pm)〉 la requête reçue.Sorties: ρ la requête construite en réponse à r.1: si act(r)=Order alors2: si known(E) alors3: si Fa −Fr = ∅ alors4: si get-effect(E) = S alors5: ρ← 〈Ack, E(S)〉 ;6: sinon7: ρ← 〈Ack, E(p1, ..., pm)〉 ;8: finsi9: sinon si Fa −Fr = F ′ alors10: ρ← 〈Assert-can, E,F ′〉 ;11: sinon si ∃pk et g(request-get)∝ pk alors12: ρ← 〈Missing, g(request-get)〉 ;13: finsi14: sinon15: ρ← 〈Assert-cannot, E〉 ;16: finsi17: finsi

3.4 Conclusion

Nous avons proposé dans ce chapitre une formalisation des besoins de l’utilisa-teur en un ensemble de requêtes et de contraintes globales. Nous avons présenté lemodèle de requêtes permettant à la fois de formaliser les requêtes de l’utilisateur,mais également le contenu des messages échangés par les agents. Nous avons vu quece modèle permettait de formaliser à la fois des requêtes en services, des requêtesou assertions à propos des capacités des agents mais aussi des requêtes présentantdes dépendances avec d’autres, couvrant ainsi plusieurs domaines d’applicationstels que le web ou l’intelligence ambiante. Pour ce qui est des contraintes globales,nous avons précisé que l’expressivité de la formalisation proposée était limitée maisnous permettait toutefois d’exprimer un sous-ensemble de contraintes pouvant êtrerésolues par l’algorithme proposé au chapitre 5.

Dans ce chapitre, nous avons également présenté l’ACL utilisé par les agentspour qu’ils puissent à la fois de communiquer mais aussi gérer directement lesbesoins de l’utilisateur avec lequel ils interagissent. La particularité de cet ACL est

3.4. CONCLUSION 59

qu’il permet à la fois d’encapsuler plusieurs requêtes au niveau d’un même message,mais aussi aux messages de véhiculer des requêtes à propos des capacités des agentset des requêtes présentant des dépendances.

Enfin, nous avons présenté les algorithmes utilisés par le module de raisonne-ment (RPM) associé à chaque agent pour traiter les questions sur les données etles commandes. Nous avons vu qu’il prenait en compte les cas triviaux lorsquel’agent savait intégralement répondre à une requête, ou pas. Mais également descas subsidiaires où l’agent détectait des attributs manquants ou des dépendancesau niveau de la requête.

Ainsi, nous avons vu dans ce chapitre comment un agent traitait une requête, etcomment par l’analyse de ses propres préconditions, il était capable de déterminerles éléments lui faisant défaut pour la résolution d’une requête. C’est en partant surces compétences que le protocole de coordination multiagent spécifie le comporte-ment des agents dans un SMA. Le but de ce protocole est de permettre à chaqueagent de déterminer quelles parts des besoins de l’utilisateur il peut accomplir etlesquelles nécessitent d’être résolues par ses accointants. De plus, il détermine lecomportement du SMA pour que celui-ci puisse satisfaire un ensemble de requêtescomplexes de l’utilisateur moyennant le concours et la coordination des compé-tences des agents le constituant.


Chapitre 4

Protocole dynamique decoordination multiagent

Précédemment, nous avons décrit le traitement des requêtes de l’utili-sateur par les agents en fonction de leurs capacités propres, et ce, en dehors detout contexte d’interaction avec d’autres agents. Dans le présent chapitre, nousmontrons comment un groupe d’agents se répartit dynamiquement les tâches à ac-complir à partir de la spécification des requêtes de l’utilisateur, et comment il secoordonne de façon décentralisée afin de couvrir adéquatement les besoins énoncés.

Nous spécifions pour cela le protocole d’interaction utilisé pour la coordina-tion. Nous décrivons d’abord les rôles et comportements des agents impliqués dansle protocole. Nous proposons ensuite un scénario d’illustration. Nous présentonsalors les règles dialectiques régissant le traitement des requêtes en tenant comptedes capacités des agents, des dépendances entre les requêtes, et des interactionsinter-agents. Nous déroulons chacune sur notre scénario d’illustration. Enfin, nousprocédons à l’évaluation analytique du protocole par la spécification et la vérifica-tion de ses propriétés, notamment la terminaison, la complexité calculatoire et decommunication.

4.1 Comportement du SMA

La spécification d’un protocole d’interaction implique qu’on y précise informel-lement la sémantique des messages ainsi que les stratégies des rôles. De plus, on ydécrit les réactions d’un agent à un message donné ainsi que les procédures qui dé-terminent ces réactions. Celles-ci peuvent en retour être la génération de nouveauxmessages [78].

Dans cette section, nous décrivons la première partie de cette spécification, no-tamment les rôles et comportements des agents impliqués dans notre protocole,ainsi que la formalisation des résultats attendus en sortie à l’issue de leur coordi-nation.

61

62 CHAPITRE 4. PROTOCOLE DE COORDINATION

4.1.1 Rôles et comportements des agents

Deux principaux rôles interviennent dans le protocole de coordination que nousvoulons concevoir :

1. L’agent de l’utilisateur qui est principalement en charge d’intergir avecl’utilisateur et de diffuser ses requêtes aux agents participant à la coordina-tion. Lorsqu’à la fin de la coordination, il reçoit les réponses des agents, il estégalement en charge de les trier en fonction des contraintes de l’utilisateur.

2. Les agents participants ont pour rôle de se coordonner afin de satisfairel’ensemble des requêtes de l’utilisateur. Le protocole d’interaction que nousspécifions dans ce chapitre décrit les règles utilisées par les agents participantspour se coordonner. Il y est également précisé les conditions sous lesquelles lesagents participants envoient leurs messages réponses à l’agent de l’utilisateur.

Définition 2 On dit qu’un agent a résolu une requête s’il a réussi à construire,pour une requête reçue, une requête réponse de type Assert-is, Ack, Unknown ouAssert-cannot.On dit qu’il l’a satisfaite si la réponse construite est Assert-is ou Ack.

Notre protocole de coordination est basé sur l’hypothèse que les agents n’ontaucune connaissance les uns sur les autres et qu’ils doivent se coordonner en pro-duisant un flux optimal de messages et en procédant au minimum des traitementsnécessaires.

Figure 4.1 – Comportement du SMA.

Le comportement du SMA, illustré sur la figure 4.1, peut alors être synthétisécomme suit :

– L’agent de l’utilisateur reçoit l’ensemble des requêtes et contraintes que l’uti-lisateur a formulées. En effet, dans notre approche, l’utilisateur a un seulinterlocuteur : l’agent de l’utilisateur. Celui-ci mémorise ses contraintes etencapsule ses requêtes dans un message, devenant un message initiateur (m0

sur la figure 4.1), qu’il diffuse à tous les agents participants.

4.1. COMPORTEMENT DU SMA 63

– Lorsqu’un agent participant reçoit un message, il le traite selon son RPM etles règles dialectiques décrites dans ce chapitre.

– Chaque fois qu’un agent construit un requête réponse, il calcule l’ensembledes agents destinataires à qui l’envoyer. Si l’agent a calculé le même ensembled’agents destinataires pour plusieurs requêtes réponses construites, il encap-sule les requêtes dans un même message qu’il envoie à chacun des agentsdestinataires calculés.

– Lorsqu’enfin l’agent a résolu toutes ses requêtes, il envoie un message conte-nant ses requêtes réponses à l’agent de l’utilisateur.

Proposition 1 Lorsqu’un agent participant a fini de résoudre toutes ses requêtes,il les regroupe dans un message qu’il envoie à l’agent de l’utilisateur.

Proposition 2 Le rôle d’un agent participant se termine dès lors qu’il a résolutoutes ses requêtes.

Proposition 3 L’agent de l’utilisateur termine son rôle dès lors qu’il a collectétous les messages réponses des agents participants.

Pour garantir cette dernière propriété, il faut que l’agent de l’utilisateur sache àcombien de messages réponses il doit s’attendre de la part des agents participants.Cela est possible à partir du moment où il collecte au moins un message par agentparticipant. L’analyse des réponses et la sémantique de l’ACL lui permettent alorsde savoir si d’autres messages sont susceptibles de lui parvenir.

4.1.2 Trace des interactions

Les agents dans notre SMA interagissent et se coordonnent en fonction desmessages reçus et de ceux qu’ils se sont précédemment échangés. Pour ce faire,chaque agent est muni d’une table d’historique.

Une table d’historique regroupe les traces des interactions d’unagent, notamment les précédents messages qu’il a échangé avec sesaccointants, ainsi que le message initiateur de chacune de ses inter-actions.

Une table d’historique associée à un agent a, notée ~a, est un ensemble d’en-registrements, chacun étant dédié à une interaction ou conversation. Dans cecontexte, ce que nous appelons interaction ou conversation, c’est l’ensemble demessages échangés pour la satisfaction d’un ensemble de besoins donnés, suivant leprotocole d’interaction.

Une conversation est une séquence de messages échangés entreplusieurs agents, conforme à un protocole d’interaction.

Un enregistrement d’une conversation est défini par ∇ def= (id,m0,M,U) telque :


– id est l’identifiant de l’enregistrement (ou de l’interaction). Il correspondégalement à la valeur du champ conv-id des messages impliqués dans l’in-teraction 1.

– m0 est le message initiateur de l’interaction.– M est l’ensemble de messages échangés, i.e. envoyés et reçus, durant l’inter-

action.– U est l’ensemble de réponses finales, construites par l’agent, devant être en-

voyées à l’agent de l’utilisateur, tel que U = ξ1, ξ2, . . .. Chaque réponsefinale ξj = ρ1j , . . . , ρ|R|j contient une résolution pour chacune des requêtesde l’utilisateur.

ExempleSupposons que les agents a, b et c soient impliqués dans l’interaction suivante,

où le patron de chacun des messages est sender, receiver, conv-id, reply-with,in-reply-to, req-id, content (le contenu des messages est ici représenté demanière informelle) :

– m0 = a, b, j81, q20, null, [1], “Enregistre Desperate Housewives”– m1 = b, c, j81, q21, q20, [1], “Quelle est son heure de diffusion ?”– m2 = c, b, j81, q22, q21, [1], “Ce programme est diffusé à 20h50”– m3 = b, a, j81, q23, q22, [1], “Enregistrement effectué”

Par conséquent, si nous considérons l’agent participant b, celui-ci aura dans satable d’historique l’enregistrement :∇ = 〈j81, m0, M = m0,m1,m2,m3,U =“Enregistrement effectué” 〉.

Chaque fois qu’un agent reçoit ou envoie un message, il stocke ou met à jour,dans sa table d’historique, l’élément approprié de l’enregistrement correspondant.Plus précisément, si le message reçu est un message initiateur, l’agent crée un nouvelenregistrement et y mémorise le message. Sinon, il mémorise le message reçu dansl’enregistrement correspondant à son identifiant.

Dans notre SMA, lorsqu’un agent construit une réponse à un message reçu,il consulte sa table d’historique afin de répondre en fonction des précédentes sé-quences de messages échangés, des agents impliqués et du but de l’interaction ,c’est-à-dire, la satisfaction des besoins de l’utilisateur contenus dans le messageinitiateur m0. Par ailleurs, il envoie un message réponse à l’agent de l’utilisateurlorsqu’il aura collecté au moins une réponse finale dans U, i.e. une résolution pourchacune des requêtes de l’utilisateur.

4.1.3 En sortie du processus de coordination

À l’issue de l’échange de messages entre les agents participants, l’agent de l’uti-lisateur reçoit les messages réponses de ces derniers et les synthétise comme suit :

– Pour les requêtes qui ont été satisfaites, l’agent construit l’ensemble des listesdes réponses candidates L(rk) chacune étant définie par :

1. Rappelons qu’un message construit en réponse à un autre a la même valeur du champconv-id. En conséquence, les messages échangés pour la résolution d’un même ensemble de besoinsont le même identifiant conv-id.

4.2. SCÉNARIO D’ILLUSTRATION 65

L(rk) def= 〈bj , ρkj〉j6|participants| (4.1)

où bj est l’identifiant d’un agent, ρkjest la réponse que celui-ci a fournie

pour la requête rk, et |participants| est le nombre d’agents participants à lacoordination.Cela veut dire que le résultat de la coordination des agents sera un ensemblede réponses, pour chaque requête exprimée par l’utilisateur, associées auxidentifiants des agents les ayant fournies.Une fois ces listes de réponses candidates construites, l’agent de l’utilisateurpeut procéder à la phase de sélection afin de ne proposer à l’utilisateur queles réponses et les agents satisfaisant les contraintes qu’il a émises. Nousdécrivons cette phase dans le prochain chapitre.

– Si toutes les requêtes n’ont pas trouvé de réponses à l’issue de la coordina-tion des agents, l’utilisateur se verra retourner les attributs manquants. Ungestionnaire de dialogue les présentera sous forme de requêtes.Cela se produit lorsque l’utilisateur n’a pas fourni l’intégralité des rensei-gnements nécessaires pour l’accomplissement de ses requêtes (ex. la date dedépart pour une réservation d’une chambre d’hôtel, la durée de l’enregistre-ment d’un programme télé, etc).

Nous déroulerons un exemple tout au long de la spécification de notre protocolepour illustrer ses différentes étapes ainsi que les différents cas traités.

4.2 Scénario d’illustration

Afin de faciliter la compréhension de notre protocole, nous proposons un exemplenécessitant la coordination d’agents et sur lequel nous illustrerons par la suite lesrègles dialectiques de notre protocole.

Nous proposons ici délibérément un exemple complexe afin que nous puissionsdérouler dessus l’ensemble de nos règles dialectiques.

4.2.1 Requêtes de l’utilisateur

Soit un utilisateur voulant consulter des produits et faire afficher de façon per-sonnalisée le résultat de ses recherches. Cet utilisateur est notamment intéressé pardes appareils photo répondant à certains critères ainsi que par des cartes mémoires,compatibles avec les appareils recherchés, dotées d’une grande capacité de stockage.Sa demande est la suivante :« Quels sont les appareils photo de marque canon dont la résolution est supérieure à7 Mpx, à multiples durées d’exposition, dont le prix est inférieur à 200AC » ; « ... etles mémoires compatibles d’une capacité de stockage supérieure à 1 Go » ; « Affichesur un tableau les appareils trouvés avec les cartes mémoires compatibles » ; « Etaffiche les appareils trouvés avec leurs images ».


Suivant notre modélisation, les requêtes de l’utilisateur sont formalisées parl’ensemble R = r1, r2, r3, r4 où le contenu des requêtes r1, r2, r3 et r4 est reportésur le tableau 4.1.

r1 What-is(∗(x) | equal(type, x, camera) ∧ equal(trademark, x, canon) ∧greater(resolution, x, 7Mpx) ∧ greater(exp-duration, x, 1))

r2 What-is(∗(x) | equal(type, x,memory-card) ∧greater(storage-capacity, x, 1Go) ∧equal(compliant, x, ref(request-get)))

r3 Order(DisplayArray(equal(ref, x, ref(request-get)),equal(refcard, y, refcard(request-get)) ∧equal(compliant, y, ref(request-get)))

r4 Order(DisplayP ic(equal(ref, x, ref(request-get)))

Table 4.1 – Les requêtes de l’utilisateur.

4.2.2 Agents participants et leurs compétences

Dans notre approche, chaque agent participant peut avoir les compétences pourrésoudre une ou plusieurs requêtes, ou une partie d’une requête.

Pour notre exemple, nous supposons que les requêtes sont envoyées aux agentsparticipants suivants :

1. Un agent PhotoSon&Vidéo fournissant appareils photo, dictaphones, cames-copes, accessoires, etc.

2. Un agent Accessoires fournissant des accessoires, dont des cartes mémoires,pour des appareils numériques.

3. Un agent Affichage proposant d’ordonner et d’afficher les éléments envoyésen entrée sur des tableaux.

4. Un agent BanqueImages muni d’une base de données d’images de produitsinformatiques, et doté de compétences d’affichage.

5. Un agent Factice qui fait des dessins étant donnés une largeur et une hauteuren entrées. Il représente un agent qui n’offre pas de service pertinent pour lademande de notre utilisateur.

La répartition des compétences des agents est reportée sur le tableau 4.2. Cetableau indique que chaque agent sur la colonne de gauche peut potentiellementrésoudre les requêtes sur la colonne de droite, i.e. directement ou moyennant leconcours des compétences et connaissances d’autres agents.

Sur ce tableau, on voit par exemple que l’agent PhotoSon&Vidéo peut potentiel-lement répondre aux requêtes r1 et r2, ou encore que l’agent Affichage est capablede prendre en charge les requêtes r3 et r4. Concrêtement, l’agent PhotoSon&Vidéopeut directement résoudre les requêtes r1 et r2 alors que l’agent Affichage pourrarésoudre les requêtes r3 et r4 à condition qu’il ait reçu les références des produitsà afficher ainsi que leurs images.


Agent Participant Dans ses cordesAgent1 PhotoSon&Vidéo r1, r2Agent2 Accessoires r2Agent3 Affichage r3, r4Agent4 BanqueImage r4Agent5 Factice -

Table 4.2 – Répartition des compétences des agents.

4.2.3 Dépendances entre les requêtes

Pour que les agents puissent satisfaire toutes les requêtes qui entrent dans lecadre de leurs compétences, il leur faut disposer des connaissances nécessaires pourleur interprétation. Par exemple, une requête telle que r3 ne peut être directementrésolue puisqu’elle dépend des valeurs des attributs ref et refcard.

Par ailleurs, d’autres requêtes, et en fonction des capacités des agents quipeuvent les prendre en charge, requièrent d’être décomposées et l’agent de rece-voir les informations dues à cette décomposition. Dans notre exemple, supposonsque l’agent Affichage soit doté d’une action Afficher image dont la précondition estle patron d’évènement DisplayP ic(ref, image). Il lui manquera alors la valeur del’attribut image pour pouvoir satisfaire la requête r4. Il finira donc par décomposerla commande et devra solliciter les autres agents pour la valeur de image.

Le graphe de dépendances des requêtes est illustré sur la figure 4.2 2.

Figure 4.2 – Graphe de dépendances entre les requêtes.

4.2.4 Résolution par le RPM

Moyennant leur RPM, les agents participants vont traiter chacune des requêtesformulées par l’utilisateur [c.f. chapitre 3, section 3.3]. Les réponses respectivesalors construites sont reportées sur le tableau 4.3.

2. Soulignons que ce graphe ne prend pas en compte les compétences des agents qui vontprendre en charge ces requêtes (auquel cas, des requêtes telles que r4 pour l’agent Affichageauraient affiché d’autres dépendances).


Ce tableau montre par exemple que l’agent PhotoSon&Vidéo propose deux mo-dèles d’appareils photo mais requiert la valeur de l’attribut ref pour proposer desmodèles de cartes mémoire. Cet agent exprime par ailleurs qu’il ne peut ni afficherles produits ni leurs images.

Notons que la réponse ρ11=Assert-is(a1, a2) de l’agent PhotoSon&Vidéo est enfait l’écriture compacte de :

ρ11=Assert-is(equal(ref, a1,EX321) ∧ ... ∧ equal(price, a1, 180AC),equal(ref, a2,CN550) ∧ ... ∧ equal(price, a2, 250AC)).

On remarque ainsi à travers les réponses des agents que, la première requêter1 de l’utilisateur mise à part, aucune autre n’a pu être résolue directement parle RPM. Même si les agents participants ont les compétences nécessaires pourrépondre à ces requêtes, aucun ne peut seul y parvenir à cause des dépendances queces requêtes présentent et des compétences insuffisantes au niveau de chaque agent.La mémoire ne peut notamment pas être trouvée sans la référence de l’appareilphoto avec laquelle elle doit être compatible, et l’affichage des produits ne peut sefaire sans avoir trouvé les appareils recherchés. De plus, un agent tel que Affichagene afficher les images des produits trouvés sans disposer des images requises.

Pour gérer dynamiquement ces dépendances, et pouvoir construire des réponsessatisfaisant toutes les requêtes énoncées, les agents utilisent le protocole de coordi-nation que nous décrivons dans ce qui suit.

Agent Participant Réponses construites par le RPMAgent1 PhotoSon&Vidéo ρ11=Assert-is(a1, a2)

ρ21=Missing(ref(request-get))ρ31=Assert-cannot(DeliverArray)ρ41=Assert-cannot(DisplayP ic)

Agent2 Accessoires ρ12=Unknown(∗)ρ22=Missing(ref(request-get))ρ32=Assert-cannot(DeliverArray)ρ42=Assert-cannot(DisplayP ic)

Agent3 Affichage ρ13=Unknown(∗)ρ23=Unknown(∗)ρ33=Missing(ref(request-get),refcard(request-get))ρ43=Missing(ref(request-get))

Agent4 BanqueImages ρ14=Unknown(∗)ρ24=Unknown(∗)ρ34=Assert-cannot(DisplayArray)ρ44=Missing(ref(request-get))

Agent5 Factice ρ15=Unknown(∗)ρ25=Unknown(∗)ρ35=Assert-can(DisplayArray, width, hight)ρ45=Assert-cannot(DisplayP ic)

Table 4.3 – Les réponses des agents participants construites par le RPM.

4.3. RÈGLES DIALECTIQUES 69

4.3 Règles dialectiques

Dans un protocole d’interaction, les agents doivent s’accorder sur les séquencesde messages possibles et sur le contenu des messages lorsque ceux-ci sont interprétésdans un contexte de conversations inter-agents dirigées par un but [56].

Ainsi, un protocole d’interaction est un ensemble de règles dialectiques plusou moins génériques paratagées par les agents et régissant le traitement de leursconversations.

Une règle dialectique spécifie quels messages sont admis pour unétat donné de l’interaction [98, 77].

Dans notre approche, les agents utilisent des règles dialectiques prenant encompte leurs interactions pour le traitement des messages qu’ils reçoivent. L’en-semble de ces règles dialectiques forme l’algorithme de notre protocole de coordi-nation.

Dans la suite de ce chapitre, nous représenterons graphiquement les règles dia-lectiques par des micro-protocoles. Nous choisissons pour ce faire la méthodologiegraphique AUML étendant les diagrammes de séquences UML 2.0 [11, 24]. En effet,notre choix pour ces diagrammes est motivé par leur simplicité et la sémantiqueclaire et facilement compréhensible de leurs éléments. De plus, la version 2.0 d’UMLa permis d’intégrer la représentation des alternatives, des boucles, des références,ainsi que d’autres éléments nécessaires pour la modélisation graphique de nos règlesdialectiques.

4.3.1 Traitement du message initiateur

Dans un message initiateur, les requêtes à traiter sont soit des requêtes What-iset/ou des commandes Order.

Lorsqu’un agent reçoit un message initiateur, il traite chacune des requêtes qu’ilcontient moyennant son RPM.

À l’issue de ce premier traitement, l’agent teste chacune des réponses construites.Si l’une d’elle est une réponse Missing(g(request-get)) ou Assert-can(E,F ′), alorsl’agent recherche la valeur des attributs manquants dans ses autres réponses. S’ilen trouve une fournissant la valeur de ces attributs, alors il traite à nouveau larequête à laquelle il avait au départ construit la réponse Missing, et utilise les va-leurs trouvées des attributs comme connaissance pour ce traitement. Notons quece traitement est désigné dans nos algorithmes par la fonction rpmplus.

Quant à la construction et l’envoi du (ou des) message(s) réponse(s) compor-tant les requêtes réponses construites, c’est un autre traitement qui dépend deparamètres tels que la classe des requêtes réponses et leurs agents destinataires. Ilqui est d’ailleurs commun à tous les types de messages (initiateurs ou pas). Nousle décrivons dans la section 4.3.2.

Ainsi, le traitement réservé aux messages initiateurs est spécifié à travers l’al-gorithme 3. Dans ce dernier :


Algorithm 3 Traitement des requêtes du message initiateur.Entrées: m0 le message initiateur reçu.Sorties: l’ensemble C = ρii∈[1,|R|] des requêtes réponses aux requêtes de m0.1: si isTriggeringMessage(m) alors2: pour tout ri : content(m0) faire3: ρi ← rpm(ri) ;4: C[i]← ρi ;5: fin pour6: pour tout ρi : C faire7: si ρi=Missing(selections) ou ρi=Assert-can(E,F ′) alors8: Soit K un ensemble de connaissances, vide ;9: si ρj=Assert-is(D′) et ∃d ∈ D′, selections ∝ d ou ∃f ∈ F ′, f ∝ d alors10: K← K, d ;11: ρi ← rpmplus(ri,K) ;12: finsi13: finsi14: C[i]← ρi ;15: fin pour16: finsi

– isTriggeringMessage est la fonction qui retourne vrai si un message estinitiateur, i.e. son champ in-reply-to est à null.

– rpm est la fonction retournant, pour une requête donnée, la réponse construitepar le RPM suivant les algorithmes 1 et 2 du chapitre 3.

– rpmplus est une fonction retournant le traitement du RPM pour une requêtedonnée moyennant des connaissances supplémentaires données en paramètre.

– ∝ est la fonction retournant qu’un attribut est défini dans une donnée [voirsa définition dans la section 3.3, page 55].

Sur le scénario

Dans notre exemple, l’agent PhotoSon&Vidéo a résolu et satisfait la requête r1du message initiateur en fournissant deux modèles d’appareils photo a1 et a2 (c.f.le tableau 4.3).

Considérons la requête r2 demandant les informations relatives aux cartes mé-moires compatibles avec les appareils photo trouvés, qui dépend de ref , et doncdu résultat trouvé pour la requête r1. L’algorithme précédemment décrit permetà l’agent PhotoSon&Vidéo de résoudre une telle requête (moyennant la fonctionrpmplus et la valeur de ref).

En écriture compacte, la réponse que PhotoSon&Vidéo va construire est alorsρ21=Assert-is(mc1, mc2, mc3). Sa forme détaillée est en fait :ρ21=Assert-is(equal(refcard,mc1,EX3211) ∧ ... ∧ equal(compliant,mc1,EX321),

equal(refcard,mc2,EX3212) ∧ ... ∧ equal(compliant,mc2,EX321),equal(refcard,mc3,CN5501) ∧ ... ∧ equal(compliant,mc3,CN550)).


Celle-ci indique que l’agent propose trois modèles de cartes mémoires mc1,mc2 et mc3, et que les deux premiers modèles mc1 et mc2 sont compatibles avecl’appareil a1 et le dernier mc3 avec l’appareil a2.

Les réponses de tous les autres agents sont, à ce stade, conformes au tableau 4.3.

4.3.2 Construction et envoi des messages réponses

Nous regroupons dans cette section le traitement commun appliqué à tous lestypes de messages (qu’ils soient ou pas initiateurs).

4.3.2.1 Calcul des agents destinataires

Soit un agent a recevant un message m et ~a sa table d’historique. Soit ∇ l’en-registrement dédié à la conversation relative à m, dont m0 est le message initiateur,tel que :∇ = (id,m0,M), oùM 6= ∅.

Pour chaque requête construite en réponse à une requête de m, l’agent doitcalculer l’ensemble ℵ des agents auxquels elle doit être envoyée :

– Si c’est une requête Missing, Assert-can ou What-is 3 alors elle doit être en-voyée à tous les agents participants pour que ceux-ci tentent de trouver lesinformations demandées ;

– Si c’est une requête Assert-is, Assert-cannot, Ack, Unknown, et qu’elle répondà une requête du message initiateur, alors elle est considérée comme unerésolution à une des requêtes de l’utilisateur. En conséquence, elle est stockéedans la table d’historique dans l’élément U de l’enregistrement correspondantà la conversation.Lorsque l’agent aura collecté une réponse finale dans U, i.e. les résolutionsà toutes les requêtes de l’utilisateur, il l’envoie à l’agent de l’utilisateur àtravers un même message réponse.

– Sinon, la requête doit être envoyée seulement à l’agent émetteur de m ;

L’algorithme 4 présente le calcul des agents destinataires ℵ pour chaque ré-ponse construite par un agent. Si cet agent a collecté des réponses finales pour lesrequêtes de l’utilisateur, l’algorithme décrit la construction et l’envoi du messageles véhiculant à l’agent de l’utilisateur. Ainsi, dans l’algorithme 4 :

– insert est la fonction utilisée pour insérer une requête réponse parmi lesréponses finales ξj mémorisées dans l’ensemble U.

– la fonction isComplete retourne vrai si une réponse finale ξ comporte desrésolutions à toutes les requêtes de l’utilisateur.

– sender, receiver, convid, replywith, inreplyto, reqid, et content sont lesfonctions retournant respectivement, pour un message donné, la valeur deschamps du même nom de ce message.

3. Nous voyons dans quel cas une requête What-is peut être construite en réponse dans la règledialectique de la section 4.3.3.3. Cette dernière présente en effet une extension au traitement duRPM.


Algorithm 4 Calcul des agents destinataires.Entrées: m le message reçu,∇ l’enregistrement de la conversation.

Sorties: l’ensemble ℵ des agents destinataires pour chaque requête réponse.1: pour tout requêtes ρi construite en réponse aux requêtes de m faire2: si act(ρi)=What-is ou act(ρi)=Missing ou act(ρi)=Assert-can alors3: ℵi ← participants\receiver(m) ;4: sinon si isTriggering(m) et (act(ρi) =Unknown ou act(ρi)=Assert-is

ou act(ρi)=Assert-cannot ou act(ρi)=Ack) alors5: insert(ρi,U) ;6: sinon7: ℵi ← sender(m) ;8: finsi9: fin pour10: pour tout ξj : U faire11: si isComplete(ξj) alors12: Soit m′ le message réponse à envoyer ;13: sender(m′)← receiver(m) ;14: receiver(m′)← au ;15: convid(m′)← convid(m) ;16: replywith(m′)← newid() ;17: inreplyto(m′)← replywith(m0) ;18: content(m′)← ξj ;19: store(m′, ~) ;20: send(m′) ;21: finsi22: fin pour

– send est la fonction utilisée pour l’envoi de messages.– store est la fonction pour l’enregistrement des messages dans la table d’his-

torique.– au désigne l’agent de l’utilisateur.

4.3.2.2 Réduction du flux de messages

Soit une requête réponse ρi et ℵ l’ensemble où sont mémorisés les identifiantsde ses agents destinataires.

Soient toutes les réponses qu’un agent a construites. Toutes celles qui ont lemême ensemble ℵ d’agents destinataires sont regroupées dans un même message.Celui-ci est alors envoyé à tous les agents dans ℵ.

De plus, le champ req-id d’un tel message est affecté en fonction des identi-fiants des requêtes auxquelles les réponses ont été construites.

ExemplePour mieux visualiser ce que cela donne, supposons un agent c qui reçoit un


message m dont le contenu est C = r1, r2, r3, r4. Cet agent construit alors pourles requêtes r2 et r3 respectivement les réponses ρ2 et ρ3. Supposons qu’il ait calculéle même ensemble d’agents destinataires a pour chacune de ces deux réponses.Le message dans lequel il les encaspulera sera alors :

m′ = sender : c,receiver : a,conv-id : j81,reply-with : q21,in-reply-to : q20,req-id : [2,3],content : ρ2, ρ3

Ainsi, le tableau des identifiants des requêtes req-id est affecté avec les iden-tifiants (récupérés dans le message original) des requêtes r2 et r3 pour lesquellesl’agent c a construit des réponses. Cela permet aux agents à tout moment de savoirpour quelle requête de l’utilisateur une requête reçue répond (ou a été construite).

Proposition 4 Si, pour un ensemble de requêtes, les réponses correspondantes ontle même ensemble d’agents destinataires, l’agent les encapsule dans un seul mes-sage.

4.3.3 Traitement des messages réponses

Proposition 5 Pour résoudre ses requêtes, un agent fait d’abord appel à ses connais-sances propres. Sinon, il recherche les connaissances nécessaires dans sa table d’his-torique. Enfin, si ces connaissances lui font toujours défaut, il sollicite ses accoin-tants.

Lorsque ce n’est pas un message initiateur, un agent reçoit des messages conte-nant des requêtes réponses de performatifs Unknown, Missing, Assert-is, Assert-can,Assert-cannot et/ou Ack :

– Lorsqu’il s’agit de réponses Missing(selections) ou Assert-can(E,F ′), il re-cherche dans sa table d’historique si une assertion à propos des selections oudes attributs F ′ manquants ont été reçus.

– S’il reçoit une assertion Assert-is(D′), il vérifie d’après sa table d’historique sielle était attendue, i.e. s’il a auparavant envoyé une requête What-is(selections|contraintes), Missing(selections) ou Assert-can(E,F ′) et procéde alors autraitement adéquat.

– S’il reçoit une requête Unknown, c’est qu’il a sollicité des informations auprèsd’autres agents pour une certaine requête. Dans ce cas, il doit vérifier s’il doiten déduire qu’il est finalement incapable de la satisfaire ou s’il lui manquedes données à solliciter auprès de l’utilisateur.

Voyons le traitement réservé pour chaque type de requête.


4.3.3.1 Requêtes Missing

Si un agent reçoit un message contenant une réponse Missing(g(request-get)), illa traite suivant l’algorithme 5. Cet algorithme stipule que l’agent doit rechercherun message mémorisé dans sa table d’historique contenant une requête ρk où :

– ρk est une assertion telle que ρk =Assert-is(D′) ;– ∃d ∈ D′ telle que g ∝ d.

Cela veut dire que l’agent aura à trouver dans sa table d’historique une as-sertion dans laquelle la valeur de l’attribut g est définie. Ainsi, pour les requêteMissing(selections) en général, deux situations sont possibles :

1. Si |selections|=1 et selections=g(request-get), et si l’agent a trouvé une ouplusieurs valeurs pour l’attribut g, il l’envoie aux agents destinataires à traversune requête Assert-is(D′′) où D′′ = equal(g, dk, valuek)k∈N représente lesexpressions définissant les valeurs pour l’attribut requis.

2. Si |selections|>1, soit plusieurs sélections inconnues de l’agent émetteur,il renvoie alors successivement les assertions Assert-is(D′′ii6|selections|), oùl’ensemble D′′ii contient respectivement les expressions définissant les va-leurs des selections.

Si les assertions requises ne sont pas trouvées, alors l’agent construit la réponseUnknown(*).

Le traitement des requêtes Missing est représenté par le micro-protocole illustrésur la figure 4.3.

Figure 4.3 – Protocole pour le traitement des réponses Missing.

Sur le scénario

Dans notre exemple, l’agent PhotoSon&Vidéo reçoit la requête réponseρ44=Missing(ref(request-get)) émise à la première étape par l’agent BanqueImages


Algorithm 5 Traitement des requêtes Missing.Entrées: m le message reçu ;

r la requête à traiter ;∇ l’enregistrement de la conversation.

Sorties: ρ la requête réponse construite.1: store(m, ~) ;2: si r=Missing(selections) alors3: pour tout mj : messages(∇) faire4: Soit D′′ un ensemble vide (pour les assertions à renvoyer) ;5: si ∃ρk = content(mj)[k] et ρk =Assert-is(D′) alors6: pour tout dk ∈ D′ et selection ∝ dk faire7: D′′ ← D′′, equal(g, dk, valuek) ;8: fin pour9: ρ← Assert-is(D′′) ;

10: finsi11: fin pour12: finsi

où celui-ci exprime qu’il a besoin de la valeur de l’attribut ref (pour interpréter larequête r4 qu’il souhaite résoudre).

Puisque l’agent PhotoSon&Vidéo a construit la réponses à la requête r1 danslaquelle l’attribut ref est renseigné, il envoie à l’agent BanqueImages les assertions :

Assert-is(equal(ref, a1,EX321)) ;Assert-is(equal(ref, a2,CN550)).

Celles-ci correspondent en effet aux références des appareils photos retournés parPhotoSon&Vidéo.

De même, l’agent PhotoSon&Vidéo reçoit la requête réponseρ33=Missing(ref(request-get),refcard(request-get)) de la part de l’agent Affichage,où celui-ci indique qu’il a besoin des valeurs des attributs ref et refcard (pourinterpréter la requête r3).

Puisque l’agent PhotoSon&Vidéo a également construit la réponse à la requêter2 dans laquelle les attributs refcard et ref sont tous deux renseignés, il envoieles assertions suivantes à l’agent Affichage :

Assert-is(equal(ref, a1,EX321), equal(refcard,mc1,EX3211)) ;Assert-is(equal(ref, a1,EX321), equal(refcard,mc2,EX3211)) ;Assert-is(equal(ref, a2,CN550), equal(refcard,mc3,CN5501)).


4.3.3.2 Requêtes Unknown

Lorsqu’un agent reçoit une requête Unknown, il récupère dans sa table d’his-torique celle qui est à l’origine de son envoi. Si celle-ci est une requête What-is ouune commande Order, il vérifie :

1. s’il a lui même envoyé une résolution pour cette requête d’origine, auquel cas,il ne traite pas la requête Unknown reçue ;

2. sinon, il vérifie si les agents auxquels il a émis cette requête d’origine ont tousrépondu.Si c’est le cas, et qu’il n’y a aucune assertion parmi les réponses collectées,cela veut dire que l’agent n’a aucune nouvelle connaissance pour la résolutionde sa requête d’origine :– Ainsi, si la requête d’origine est What-is, la réponse qu’il construira est

Unknown(∗) ;– Si c’est une commande Order dans laquelle les valeurs de certains attributsF ′ lui faisaient défaut, il construira la réponse Unknown(F ′).

Le micro-protocole correspondant à cette règle est représenté sur la figure 4.4.Quant au traitement, il est détaillé dans l’algorithme 6. Dans cet algorithme, lafonction getOrigin, pour une requête r donnée en paramètre, renvoie la requête àlaquelle r répond.

Figure 4.4 – Protocole pour le traitement des réponses Unknown.

Sur le scénario

Dans notre exemple, l’agent Factice est muni d’une action Dessiner tableau dontle patron d’évènement est DisplayArray(width, high). Lorsqu’il reçoit la requêter3 du message initiateur demandant d’afficher sur un tableau les produits trouvés,


Algorithm 6 Traitement des requêtes Unknown.Entrées: m le message reçu ;

r la requête à traiter ;∇ l’enregistrement de la conversation ;a l’agent recevant m.

Sorties: ρ la requête réponse construite.1: store(m, ~) ;2: si act(r) =Unknown alors3: Soit ri ← getOrigin(r) ;4: si ri=What-is(selections|contraintes) ou ri=Order(E(p1, p2, ...)) alors5: pour tout mj : messages(∇) et sender(mj)=a et replywith(mj) =

inreplyto(m) faire6: cpt++ ;7: fin pour8: si cpt == |participants| − 1 alors9: si act(ri) =Order alors

10: Soit F ′ les attributs manquants pour la résolution de ri.11: ρi ← Unknown(F ′) ;12: sinon si act(ri) =What-is alors13: ρi ← Unknown(∗) ;14: finsi15: finsi16: finsi17: finsi

il construit la réponse ρ35=Assert-can(DisplayArray, width, height), informantqu’il a besoin des valeurs des attributs width et height, qu’il diffuse à tous lesparticipants.

Il reçoit alors successivement de leur part la même réponse Unknown(∗). À l’is-sue de la dernière réponse Unknown reçue, l’agent Factice peut déduire que pourcette conversation, il ne pourra pas exécuter son action et construira alors la réso-lution ρ35=Unknown(width, height).


4.3.3.3 Requêtes Order

Revenons sur les commandes Order. Nous avons donné dans le précédent cha-pitre le traitement réservé par le RPM aux commandes [c.f. section 3.3.2, page56].

En effet, lorsqu’un agent reçoit une commande Order(E(pii∈N)), la réponseconstruite est :

– Ack s’il réussit à l’exécuter ;– Assert-cannot sinon (i.e. s’il ne reconnaît pas l’évènement E) ;– Missing s’il détecte des attributs dont la valeur lui est inconnue ;– Assert-can s’il reconnaît l’évènement mais que les attributs attendus ne sont

pas tous renseignés.

Voyons de plus près le dernier cas Assert-can(E,F ′).

Dans notre modèle, une commande peut être exécutée par le biais d’une seuleaction, lorsque les préconditions de cette dernière sont vérifiées et que les attri-buts attendus sont tous renseignés (c’est le cas où une confirmation Ack peut êtreconstruite en réponse).

Il arrive également qu’une commande ne fournisse pas toutes les valeurs desattributs attendus par une action. Cela se produit soit parce que l’utilisateur aoublié de donner ces valeurs (ex. l’adresse exacte de livraison), soit parce qu’il ena donné d’autres à la place (ex. titre d’un programme télé à enregistrer à la placede sa durée, son heure et sa chaîne de diffusion).

Dans ce dernier cas, les valeurs des attributs manquants peuvent être retrouvéeset obtenues par l’exécution d’autres actions.

C’est ainsi que dans notre modèle, une requête peut être décomposée en l’appelà plusieurs actions, dont l’exécution de certaines dépend des résultats obtenus del’exécution des autres.

Deux cas de figures sont alors possibles :

1. Soit l’agent ayant décomposé la commande comporte toutes les actions dontelle dépend ;

2. Soit la commande dépend d’actions inconnues de l’agent ;

Supposons que l’agent ait reçu la commande Order(E(p)). Ainsi, pour tenter deretrouver les valeurs des attributs manquants F ′ = f1, f2, . . . dépendant d’actionsautres que celle invoquée par l’évènement E, l’agent construit une requête :

What-is(f1(var), f2(var), ...| p).où f1, f2, . . . = F ′ sont les attributs manquants, p est le paramètre de la com-mande reçue, et var la variable utilisée dans l’expression du paramètre p.

Dans notre exemple du programme télé à enregistrer, où le titre est donné à laplace de la durée, de l’heure et de la chaîne de diffusion, et afin de retrouver lesattributs manquants, l’agent construit la requête :What-is(channel(x), duration(x), time(x)| equal(title, x,Desperate Housewives).


À cette requête, l’agent tente d’abord lui-même de répondre. S’il échoue, il ladiffuse alors à ses accointants.

Notons qu’une réponse What-is remplace la réponse Assert-can dans un seulcas : l’évènement reçu doit comporter un seul paramètre. C’est à dire qu’il ne porteque sur une variable (ex. une chambre d’hôtel à réserver, un programme télé àenregitrer). En effet, cette restriction a pour but d’éviter de construire, sur la basede plusieurs paramètres, plusieurs requêtes What-is problablement incohérentes,saturant le réseau et sollicitant des traitements par les agents participants.

Dans notre scénario, cela évite à l’agent Factice de construire des requêtes in-cohérentes telles que :

What-is(width(z)| equal(ref, z, ref(request-get)))What-is(width(t)| equal(ref, t, ref(request-get)) ∧

equal(compliant, t, refcard(request-get)))

En conséquence, lorsqu’un agent reçoit une commande Order(E(pii∈N)), iltente de la résoudre moyennant le micro-protocole de la figure 4.5. Selon ce dernier,si l’agent ne réussit pas à exécuter la commande, il peut la décomposer suivant lemicro-protocole de la figure 4.6.

Le traitement des requêtes Order dans un contexte d’interaction multi-agentsest spécifié par l’algorithme 7.

Sur le scénario

Soit la requête r4 demandant d’afficher les images des appareils photo trouvés.Dans notre exemple, l’agent Affichage a reçu les valeurs des attributs ref dont ilavait besoin pour l’interprétation de cette requête.

Nous avons précédemment mentionné qu’il était doté d’une action Afficherimage dont la précondition est le patron d’évènement DisplayP ic(ref, image).

Ainsi, en tentant à nouveau de résoudre la requête r4, il lui manquera la valeurde l’attribut image. L’agent Affichage construit alors les requêtes :

What-is(image(x) | equal(ref, x,EX321)) ;What-is(image(x) | equal(ref, y,CN550)).Puisqu’il ne peut pas lui-même les satisfaire, il les diffuse à ses accointants (dont

l’agent BanqueImage qui possède les connaissances pour y répondre).


Figure 4.5 – Protocole pour le traitement des commandes Order.

Figure 4.6 – Protocole pour la décomposition d’une commande Order.


Algorithm 7 Traitement des requêtes Order.Entrées: m le message reçu ;


Sorties: ρ la requête réponse construite.1: store(m, ~)2: si act(r) =Order alors3: ρ← rpm(r) ;4: si ρ=Assert-can(E,F ′) et |pii| = 1 alors5: ρ← 〈What-is, fk(var)k6|F ′||p1〉 ;6: finsi7: si ρ=Missing(selections) ou ρ=Assert-can(E,F ′)

ou ρ=What-is(selections|contraintes) alors8: Soit K un ensemble de connaissances, vide ;9: pour tout mj : messages(∇) et ρk : content(mj) faire

10: si ρk =Assert-is(D′) et ∃d ∈ D′, selections ∝ d ou ∃f ∈ F ′, f ∝ d alors11: K← K+ D′ ;12: ρi ← rpmplus(r,K) ;13: finsi14: fin pour15: finsi16: finsi


4.3.3.4 Requêtes Assert-can

Si un agent reçoit un message contenant une requête réponse Assert-can(E,F ′),il traite celle-ci suivant l’algorithme 8.

Tout comme dans les cas précédents, cet algorithme spécifie que l’agent doitrechercher dans sa table d’historique une assertion où les attributs f ∈ F ′ sontrenseignés.

Si une ou plusieurs assertions sont trouvées pour chaque f ∈ F ′, l’agent enconstruira une où il fournira les valeurs possibles de ces attributs manquants, sinonil enverra une requête Unknown. Ceci est représenté par le protocole de la figure 4.7.

Figure 4.7 – Protocole pour le traitement des réponses Assert-can.

Algorithm 8 Traitement des requêtes Assert-can.Entrées: m le message reçu ;


Sorties: ρ la requête réponse construite.1: store(m, ~)2: si r=Assert-can(E,F ′) alors3: Soit K un ensemble de connaissances, vide ;4: pour tout mj : messages(∇) et ρk : content(mj) faire5: si ρk =Assert-is(D′) et ∃d ∈ D′,∃f ∈ F ′, f ∝ d alors6: K← K+ D′ ;7: finsi8: fin pour9: si K 6= ∅ alors10: ρ← 〈Assert-is, K〉 ;11: sinon12: ρ← 〈Unknown, ∗〉 ;13: finsi14: finsi


Sur le scénario

L’agent Affichage dans notre exemple tente entre autres de résoudre la requêter3 demandant d’afficher les produits trouvés sur un tableau. L’agent a d’abord puinterpréter cette requête grâce à l’assertion ρ11 envoyé par l’agent PhotoSon&Vidéolui fournissant les valeurs des attributs ref et refcard dont il avait besoin.

Supposons à présent que cet agent soit muni d’une action Afficher sur tableaudont le patron d’évènement est DisplayArray(. . . , provider), nécessitant ainsi quel’attribut provider soit renseigné pour exécuter son action. Il construit alors larequête Assert-can(DisplayArray, provider) qu’il diffuse à ses accointants.

Les agents participants reçoivent cette requête et la traitent suivant l’algorithmeprécédent. Tous répondent par Unknown, sauf l’agent PhotoSon&Vidéo qui réussità construite une assertion renseignant l’attribut provider pour la conversation encours. Il envoie alors sa réponse à l’agent Affichage.


4.3.3.5 Requêtes What-is

Si un agent reçoit une requête What-is et que son traitement par le RPM produitune réponse Missing(selections), l’agent devra rechercher dans sa table d’historiquedes assertions fournissant les valeurs des sélections indéfinies.

S’il arrive à trouver les connaissances nécessaires pour satisfaire la requêteWhat-is, il construit alors une assertion Assert-is. Sinon, c’est une requête Unknown.Si le message d’où provient la requête What-is n’est pas initiateur, les réponsesconstruites sont envoyées à l’agent émetteur seulement.

Le traitement des requêtes What-is dans un contexte d’interaction multi-agentsest ainsi dépeint par le protocole de la figure 4.8 et décrit par l’algorithme 9.

Sur le scénario

Dans notre exemple, tous les agents reçoivent les requêtes suivantes émises parl’agent Affichage :

What-is(image(x) | equal(ref, x,EX321)) ;What-is(image(x) | equal(ref, x,CN550)).Notamment l’agent BanqueImages. Celui-ci arrive à y répondre en utilisant sim-

plement son RPM. Il renvoie alors à l’agent Affichage les assertions :Assert-is(equal(image, a1, http ://image-a1)) ;Assert-is(equal(image, a2, http ://image-a2)).

Figure 4.8 – Protocole pour le traitement des requêtes What-is.


Algorithm 9 Traitement des requêtes What-is.Entrées: m le message reçu ;


Sorties: ρ la requête réponse construite.1: store(m, ~)2: si act(r) =What-is et ¬(isTriggeringMessage(m)) alors3: ρ← rpm(r)4: si ρ=Missing(selections) alors5: Soit K un ensemble de connaissances, vide ;6: pour tout mj : messages(∇) et ρk : content(mj) faire7: si ρk =Assert-is(D′) et ∃d ∈ D′, selections ∝ d alors8: K← K+ D′ ;9: ρi ← rpmplus(r,K) ;

10: finsi11: fin pour12: finsi13: finsi


4.3.3.6 Requêtes Assert-is

D’après les règles dialectiques précédemment spécifiées (c.f. les micro-protocolesdes figures 4.4, 4.6 et 4.7), si un agent reçoit une assertion Assert-is, c’est qu’il aenvoyé à travers un précédent message, soit une requête What-is, Missing ou alorsAssert-can.

L’agent doit alors vérifier si cette assertion était bien attendue et à quel typede requête elle répond, ceci afin de savoir ce qu’il doit en faire.

Il recherche alors dans sa table d’historique le message qui est à l’origine decelui qu’il vient de recevoir. Un tel message est caractérisé par une valeur du champin-reply-to égale à celle du champ reply-with du message reçu.

Ce message trouvé, l’agent explore son contenu. Selon la requête à l’origine del’assertion reçue, et suivant l’algorithme 10, l’agent doit gérer les trois cas suivants :

1. L’assertion reçue répond à une requête Assert-can. Cela veut dire que l’agent aprécédemment échoué à résoudre une requête Order, et a envoyé cette requêteAssert-can(c.f. le protocole de la figure 4.5).Dans ce cas, c’est cette dernière requête pour laquelle l’agent vient de recevoirl’assertion Assert-is qu’il est censé traiter.L’agent utilise alors l’assertion reçue pour résoudre à nouveau la commandeinitiale Order.

2. L’assertion répond à une requête What-is. Dans ce cas, la requête What-isa été construite par l’agent pour décomposer une commande Order (c.f. lemirco-protocole de la figure 4.6). L’agent utilise alors l’assertion reçue pourtenter de résoudre à nouveau cette commande initiale Order.

3. L’assertion répond à une requête Missing. Dans ce cas :

(a) Si la requête Missing répond elle-même à une requête What-is (c.f. lemicro-protocole de la figure 4.8), l’agent utilise l’assertion pour résoudrela requête What-is d’origine.

(b) Sinon, si la requête Missing répond elle-même à une requête Order (c.f. lemicro-protocole de la figure 4.5), l’agent utilise l’assertion pour répondreà la commande Order d’origine.

Le protocole de la figure 4.9 illustre le traitement pour les requêtes Assert-is.Celui-ci est par ailleurs décrit à travers l’algorithme 10 où getTriggeringRequestest la fonction qui retourne la requête de l’utilisateur pour laquelle une requête aété construite.

Sur le scénario

Dans notre exemple, l’agent BanqueImages a reçu de la part de l’agent Photo-Son&Vidéo les assertions Assert-is(equal(ref, a1,EX321), equal(ref, a2,CN550)).

En cherchant dans sa table d’historique, il retrouve le message à l’origine decette assertion qu’il vient de recevoir. Il avait en fait envoyé une requête Missing(ref(request-get)) puisqu’il n’a pas pu interpréter la commande r4 du messageinitiateur.


Il utilise ainsi l’assertion reçue pour tenter à nouveau de résoudre cette com-mande. Il réussit à l’exécuter et construit alors la réponse :ρ44=Ack(DisplayP ic(equal(ref, s, ref(request-get))).

De même, l’agent Accessoires traite l’assertion reçue ρ11=Assert-is(a1, a2) à pro-pos des appareils photo trouvés. Celle-ci lui fournit les informations requises pourinterpréter la requête r2 du message initiateur (pour trouver des modèles de cartesmémoires compatibles). L’agent Accessoires va ainsi traiter à nouveau la requêted’origine r2 moyennant ces informations et construira l’assertion :ρ22=Assert-is(equal(refcard,mc4,EX3213) ∧ ... ∧ equal(compliant,mc4,EX321),

equal(refcard,mc5,CN5502) ∧ ... ∧ equal(compliant,mc5,CN550).Dans sa réponse, il décrit deux modèles de cartes mémoires trouvés mc4 et mc5

respectivement compatibles avec les appareils a1 et a2.

L’agent Affichage traite, lui, les assertions ρ21=Assert-is(mc1, mc2, mc3) etρ22=Assert-is(mc4,mc5) fournissant les informations à propos des modèles de cartesmémoires et des appareils photo, ainsi que l’assertion émises par l’agent BanqueI-mages à propos des images des appareils photo.

Suivant l’algorithme précédent, l’agent Affichage retrouve que les requêtes àl’origine de ces assertions sont respectivement des requêtes Missing et Assert-canqu’il a émises en tentant d’interpréter les commande r3 et r4. Il utilise alors lesassertions reçues pour traiter à nouveau cette commande. Il construit alors lesconfirmations d’exécution :

ρ33=Ack(DisplayArray(equal(ref, x, ref(request-get)),equal(refcard, y, refcard(request-get)) ∧equal(compliant, y, ref(request-get))).

ρ43=Ack(DisplayP ic(equal(ref, x, ref(request-get))).

Ainsi d’ailleurs s’achève la coordination des agents. Tous les agents ont ainsirésolu les requêtes du messages initiateur, et certains d’entre eux ont pu satisfaireune ou plusieurs d’entre elles. Les résultats envoyés à l’agent de l’utilisateur sontreportés sur le tableau 4.4. On y constate que les requêtes du message initiateuront toutes été satisfaites. Les réponses satisfaisant ces requêtes sont reportées enbleu (et soulignées) sur le tableau.


Agent Participant Résolutions construites

Agent1 PhotoSon&Vidéo ρ11=Assert-is(a1, a2)ρ21=Assert-is(mc1, mc2, mc3)ρ31=Assert-cannot(DeliverArray)ρ41=Assert-cannot(DisplayP ic)

Agent2 Accessoires ρ12=Unknown(∗)ρ22=Assert-is(mc4, mc5)ρ32=Assert-cannot(DeliverArray)ρ42=Assert-cannot(DisplayP ic)

Agent3 Affichage ρ13=Unknown(∗)ρ23=Unknown(∗)ρ33=Ack(DisplayArray(...))ρ43=Ack(DisplayP ic(...))

Agent4 BanqueImages ρ14=Unknown(∗)ρ24=Unknown(∗)ρ34=Assert-cannot(DisplayArray)ρ44=Ack(DisplayP ic(...))

Agent5 Factice ρ15=Unknown(∗)ρ25=Unknown(∗)ρ35=Unknown(width, height)ρ45=Assert-cannot(DisplayP ic)

Table 4.4 – Les réponses des agents participants envoyées à l’agent de l’utilisateur.


Figure 4.9 – Protocole pour le traitement des assertions Assert-is.


Algorithm 10 Traitement des requêtes reçues Assert-is.Entrées: m le message reçu ;

r l’assertion à traiter ;∇ l’enregistrement de la conversation.

Sorties: ρ la requête réponse construite.1: store(m, ~)2: si r =Assert-is(D′) alors3: Soit ri0 ← getTriggeringRequest(r) ;4: Soit ri ← getOrigin(r) ;5: Soit ri% ← getOrigin(ri) ;6: si act(ri) =Assert-can alors7: ρ← rpmplus(ri0 ,D′) ;8: sinon si act(ri) =What-is alors9: ρ← rpmplus(ri0 ,D′) ;10: sinon si act(ri) =Missing alors11: ρ← rpmplus(ri% ,D′) ;12: finsi13: finsi

4.4. ÉVALUATION ANALYTIQUE DU PROTOCOLE 91

4.3.4 Détection d’attributs non fournis par l’utilisateur

Lorsque l’agent de l’utilisateur a reçu l’ensemble des réponses des agents parti-cipants, il dresse les listes des réponses candidates. Pour chaque requête de l’utili-sateur, il calcule ainsi l’ensemble des requêtes réponses proposées en solution.

Si pour une requête de l’utilisateur, il n’y a pour seule réponse qu’une ou plu-sieurs requêtes Unknown(F ′), alors cet ensemble d’attributs manquants F ′ est re-tourné à l’utilisateur. Cela implique que ce dernier n’a pas fourni les valeurs de cesattributs qui sont nécessaires pour la résolution de ses requêtes.

Sur le scénario

Supposons que dans notre exemple, l’utilisateur ait formulé la requête :r6=Order(Deliver(equal(ref, x,EX321))) demandant de se faire livrer le produitde référence EX321 .

Soit un agent Livraison muni du patron d’évènement Deliver(ref, deliveryAdr)pour son action livrer produit. Pour répondre à la requête r6, il construit au débutune requête What-is pour demander auprès des agents participants la valeur del’attribut manquant deliveryAdr.

Puisqu’aucun n’aura pu la calculer, l’agent Livraison construit la réponseUnknown(deliveryAdr).

Si c’est la seule réponse collectée par l’agent de l’utilisateur pour la requête r6alors il retournera l’attribut manquant deliveryAdr à l’utilisateur.

4.4 Évaluation analytique du protocole

4.4.1 Terminaison

Proposition 6 Chaque rôle de notre protocole de coordination, soit le rôle d’agentparticipant et l’agent de l’utilisateur, se termine en un nombre fini d’étapes.

Preuve. Les propositions 1 et 3 déterminent les conditions de terminaison du rôlede l’agent de l’utilisateur. Il nous faut à présent démontrer la terminaison du rôlede l’agent participant, et prouver qu’il ne peut pas s’impliquer pas dans des cyclesde requête-réponse.

Pour prouver la proposition 6, nous regroupons toutes les règles dialectiques,que les agents participants utilisent, sous forme d’une seule grammaire. Celle-cidécrira alors le comportement global du protocole pour la génération des messageset déterminera les conditions d’arrêt de la construction et de l’envoi de nouveauxmessages.

Pour décrire cette grammaire, nous utilisons le langage formel ISO LOTOS[19, 68]. C’est un langage composé d’une algèbre de processus pour décrire les com-portements et d’un langage algébrique pour décrire les types abstraits de donnée.Notre choix pour ce langage a été motivé par le fait qu’il est mathématiquementbien défini et expressif : il permet la description du parallélisme, du non détermi-nisme, des communication synchrones et asynchrones. Cependant, pour nos besoins,


Figure 4.10 – Arbre défini par notre protocole.

nous utiliserons seulement l’algèbre de processus pour décrire le comportement duprotocole.

Dans ce qui suit, nous assimilons le protocole de coordination que nous avonsspécifié à un processus LOTOS. Un processus LOTOS est défini par des portes decommunication (G) avec son environnement et par son comportement (B).

Soit l’ensemble des performatifs de l’ACL que nous avons défini. Chacun d’euxest repris ici pour représenter un micro-comportement possible dans le comporte-ment global du protocole.Par exemple Missing est le micro-comportement consistant à générer et envoyer,dans le SMA, une requête de performatif Missing. Nous ajoutons cependant lemicro-comportement nt-What-is (pour non triggering What-is), différencié de What-isdu message initiateur. pour représenter la génération d’un requête What-is suite àla décomposition d’une commande Order,

Ainsi, le comportement de notre protocole est construit par l’algèbre de pro-cessus LOTOS selon la grammaire suivante :

B ::= What-is | Order | B|[G∗]|BWhat-is ::= Assert-is » exit | Unknown » exit | MissingOrder ::= Ack » exit | Assert-cannot» exit | Missing | nt-What-is | Assert-canAssert-is ::= Assert-is » exit | Ack » exitUnknown ::= Unknown » exitMissing ::= Assert-is | Unknownnt-What-is ::= Assert-is | UnknownAssert-can ::= Assert-is » exit | Unknown » exit

La figure 4.10 4 représente l’arbre défini par notre protocole en suivant cettegrammaire. Cette dernière exprime que notre protocole de coordination peut êtreinitialisé par l’émission d’une question sur des données What-is, d’une commande

4. La notation i; B exprime le préfixage par une action interne. i; B est alors un comportementqui exécute l’action interne i, puis se comporte comme B. Dans notre arbre, i est l’action de vérifierdans la table d’historique que tous les agents questionnés pour la requête en cours ont répondu.

4.4. ÉVALUATION ANALYTIQUE DU PROTOCOLE 93

Order, ou de plusieurs requêtes parmi ces deux types en parallèle. Cette dernièrealternative est formalisée par l’expression B|[G∗]|B (qui en LOTOS est définiecomme la composition parallèle de B et B avec synchronisation sur les portes decommunication G∗).

Les comportements survenant à la suite de l’envoi des requêtes What-is etOrder sont détaillés dans les expressions suivantes. La deuxième expression parexemple spécifie que l’envoi d’une requête What-is peut générer l’envoi d’une re-quête Assert-is suivie d’un exit, c’est-à-dire la terminaison du traitement de larequête en cours (sachant que B1 » B2 exprime la composition séquentielle de B1

et B2, et exit exprime un comportement qui se termine avec succès).En déroulant cette grammaire, nous constatons que chaque micro-compor-

tement, et quelque soit les micro-comportements qu’il engendre, finit, directementou indirectement (par exit). En effet, lorsque l’envoi d’une requête initiale génèredes confirmations d’exécution ou des assertions (i.e. Assert-is, Ack, Unknown ouAssert-cannot), ces dernières terminent directement le traitement de la requête enquestion (ex. Assert-is » exit). Lorsque les requêtes initiales engendrent l’envoi derequêtes Missing, nt-What-is et Assert-can, celles-ci finissent également par directe-ment (pour Assert-can) ou indirectement (pour nt-What-is et Missing), et entraînentla terminaison du traitement des requêtes initiales.

En conséquence, le traitement des requêtes dans notre protocole de coordinationse termine en un nombre fini d’étapes. La terminaison du traitement de l’ensembledes requêtes pour chaque agent implique ainsi la terminaison de notre protocole.

4.4.2 Complexité de communication

Soit k le nombre de requêtes de l’utilisateur et n le nombre d’agents, com-prenant les agents participants et l’agent de l’utilisateur, dans notre protocole decoordination.

Pour une meilleure représentation visuelle, nous avons donc élagué en arbre lagrammaire de notre protocole (c.f. figure 4.10). D’après l’arbre défini par notreprotocole, une requête est résolue, dans le pire cas, à l’issue de quatres niveaux :

1. Lors du premier niveau, les k requêtes sont diffusées aux agents participantsen un seul message initiateur. On compte alors n− 1 messages envoyés.

2. Les participants commencent ensuite à répondre aux messages reçus. Dansle pire cas, ils traitent les requêtes qui y sont incluses une par une, i.e. unmessage envoyé pour chacune. De plus, on suppose qu’ils n’ont pu en résoudreaucune mais sont a priori capables de le faire moyennant d’autres connais-sances. On a alors k(n−1)(n−2) messages en plus (n−1 agents dont chacunenvoie k messages à n− 2 accointants).

3. Enfin, les réponses aux précédentes requêtes sont reçues, moyennant k(n −1)(n − 2) autres messages. Elles sont utilisées pour le traitement final desrequêtes initiales, impliquant n−1 messages envoyés à l’agent de l’utilisateur.

En conséquence, la complexité de communication de notre protocole, i.e. lenombre total de messages émis au pire cas, est de l’ordre de O(kn2).


En comparaison, un protocole tel que le CNP a une complexité de communica-tion de l’ordre de O(kn). En effet, dans le cas général, ce protocole a une complexitéde communication de l’ordre de O(knm) si l’on considère k tâches (correspondantà nos requêtes), n agents contractants (correspondants à nos agents participants)et m agents managers (correspondant à notre agent de l’utilisateur).

La complexité de notre protocole est donc élevée par rapport à celle du CNP.Toutefois, les messages supplémentaires générés permettent de traiter (dans uncontexte où les agents n’ont aucune connaissance sur leurs accointants) les dépen-dances entre les tâches, leur décomposition en fonction des compétences des agentsainsi que la coordination des agents pour couvrir l’ensemble des tâches. Par ailleurs,ces problèmes ne sont pas gérés dans le cas du CNP ni d’aucun autre protocole decoordination multi-agents à notre connaissance.

4.4.3 Complexité calculatoire

Soit k le nombre de requêtes de l’utilisateur et n le nombre d’agents dans notreprotocole de coordination.

Pour chaque message qu’un agent reçoit, il doit :1. Traiter chacune des requêtes le composant en utilisant les règles dialectiques

précédemment spécifiées.Cette opération requiert dans le pire cas de faire des recherches au niveaude tous les messages mémorisés dans la table d’historique, et pour chaquemessage, dans les requêtes qu’il contient. Elle est effectuée en un temps kn.

2. Construire l’ensemble des agents destinataires auxquels la réponse est émise.Cette opération requiert de tester la classe de la requête et si le message quila véhicule est initiateur ou pas. Elle est effectuée en k étapes.

3. Tester pour chaque requête réponse si elle peut être regroupée avec d’autresayant le même ensemble d’agents destinataires. Concrètement, une table dehachage a été consacrée pour la réalisation de cette étape. Sa clé est l’ensembled’agents destinataires communs à un ensemble de requêtes. Cette opérationrequiert simplement pour chaque réponse de tester si son ensemble ℵ d’agentsdestinataires existe dans la table. Elle est exécutée en un temps k.

4. Tester pour chaque requête réponse si elle doit être intégrée à l’ensemble Udes réponses finales à envoyer à l’agent de l’utilisateur. Elle nécessite k étapes.

En conséquence, la complexité calculatoire de notre protocole de coordinationest polynomiale et, est au pire cas, de l’ordre de O(kn).

4.5 Conclusion

Dans ce chapitre, nous avons spécifié le protocole de coordination des agents.Ce protocole permet à des agents, dotés d’un ensemble de compétences, de secoordonner afin de résoudre un ensemble de requêtes complexes, présentant desdépendances entre elles et devant parfois, en fonction des compétences des agents,être décomposées.

4.5. CONCLUSION 95

Pour spécifier notre protocole, nous avons présenté les rôles et comportementsdes agents qui y sont impliqués et formalisé les résultats attendus à l’issue duprocessus de coordination. Nous avons ensuite proposé un scénario d’illustrationoù nous avons donné en détail les requêtes de l’utilisateur et leurs dépendances,les agents participants et leurs compétences. Nous avons alors décrit les règlesdialectiques permettant aux agents de traiter les messages reçus en tenant comptede leurs interactions et leurs compétences, et déroulé nos algorithmes de traitementsur notre scénario. Enfin, nous avons analysé les principales propriétés de notreprotocole, dont la terminaison et la complexité.

Nous avons ainsi spécifié à travers ce chapitre un protocole d’interaction per-mettant aux agents de dynamiquement se coordonner, et ce de façon :

– décentralisée : puisque tous les agents impliqués dans la coordination jouentle même rôle (agent participant), le protocole ne s’appuie donc sur aucund’entre eux.

– distribuée : puisque chaque agent prend part à la résolution de l’ensembledes requêtes de l’utilisateur, leur résolution est distribuée. En effet, un agentdans notre protocole peut traiter plusieurs, une, ou une partie d’une requête.

En conséquence, pour implanter une coordination dynamique des agents, notreprotocole s’appuie sur le raisonnement de ces derniers à propos de leurs capaci-tés, des classes des requêtes traitées et des autres messages échangées. Le flux demessages généré pour se coordonner reste raisonnable par rapport à l’hypothèsede départ stipulant que les agents n’ont aucune connaissance les uns sur les autreset des requêtes complexes à satisfaire. Il permet à partir d’une spécification debesoins, en ensemble de requêtes, la résolution dynamique et automatique des re-quêtes exprimées et permet de détecter les données qui n’ont pas été fournies parl’utilisateur et qui sont nécessaires pour la résolution des requêtes.


Chapitre 5

Services compatibles etcontraintes globales

En spécifiant un protocole de coordination multiagent, nous avons pro-posé un moyen permettant aux agents de collaborer dynamiquement afin de satis-faire un ensemble de requêtes complexes formulées par l’utilisateur.

Nous avons formalisé les résultats attendus à l’issue du processus de coordina-tion et avons déterminé que le rôle en charge de les gérer était celui de l’agent del’utilisateur. Ce dernier, servant de médiateur entre l’utilisateur et le SMA, est eneffet le principal destinataire des messages réponses finaux des agents participants,chacun contenant une résolution par agent des requêtes de l’utilisateur.

Ce chapitre traite à présent de la satisfaction des contraintes de l’utilisateur.L’objectif étant de retourner à ce dernier une sélection des agents et réponses four-nies à l’issue de la coordination et qui satisfont les contraintes qu’il a exprimées.Dans ce chapitre, nous formalisons ce problème que nous appelons “sélection desservices compatibles par rapport aux contraintes globales” et présentons un algo-rithme, en quelques étapes simples, pour le résoudre. Il est à noter que le principede l’algorithme proposé est similaire à une opération de jointure de tables en basede données suivie d’une opération de sélection, à certaines différences près que nousexplicitons.

5.1 Problème

5.1.1 Définitions

L’approche de chorégraphie de services au centre de notre étude a pour objectifde satisfaire un ensemble des requêtes r1, r2, . . . rn et de contraintes c1, c2, . . . , cm,à propos de services, formulées par un utilisateur.

Comme nous le présentions lors du précédent chapitre, les requêtes de l’utilisa-teur sont satisfaites par la coordination des agents participants.

97

98 CHAPITRE 5. SERVICES COMPATIBLES

Définition 3 Une résolution positive d’un agent à une requête r de l’utilisateurest une requête réponse ρi satisfaisant r (i.e. son performatif est donc Ack ouAssert-is).

Prenons le scénario d’illustration du précédent chapitre [c.f. section 4.2, page 65].À l’issue de la coordination, chaque agent a pu proposer une résolution pour cha-cune des requêtes de l’utilisateur [c.f. tableau 4.4, page 4.4]. Les résolutions quisatisfont les requêtes de l’utilisateur, telles que ρ11 où sont fournis des modèlesd’appareil photo, sont alors désignées comme des résolutions positives.

Plus généralement, dans notre approche, chaque agent doit proposer un en-semble de résolutions R(r1), R(r2), . . . , R(rn) pour les requêtes de l’utilisateur (unerésolution étant une requête réponse de performatif Ack, Assert-is, Assert-cannot ouUnknown). Chaque ensemble R(ri) peut contenir une, plusieurs ou aucune résolu-tions positives à la requête ri.

Notation. Une résolution positive ρi (par exemple la requête réponse fournissantles modèles d’appareil photo) peut contenir une ou plusieurs propositions (parexemple l’appareil photo a1). Chaque proposition pour la résolution positive ρi estalors notée P(ri)k

.

Définition 4 Une proposition P(ri)kdans une résolution positive ρi d’un agent

pour une requête ri de l’utilisateur est :– L’une des données d ∈ D′, si la réponse de l’agent est une assertion Assert-is(D′).– L’action effectuée accompagnée des informations S relatives à son exécution,si la réponse de l’agent est Ack(E(S)).

Dans notre précédent scénario, l’agent PhotoSon&Vidéo fournit à l’utilisateurplusieurs modèles d’appareils photo en réponse à la première requête de l’utilisa-teur. Chaque appareil photo est alors considéré comme une proposition de l’agent.

Notons que chaque proposition est caractérisée par un ensemble d’attributs,par exemple son prix, sa résolution, son poids, sa durée, etc.

Dans notre modèle, il est à noter qu’une proposition peut être construite surla base d’une autre. Ceci se produit lorsque les requêtes pour lesquelles les pro-positions ont été fournies sont dépendantes. Par exemple, dans notre précédentscénario, la requête demandant les modèles de carte mémoire est dépendante decelle fournissant les modèles d’appareil photo. Ainsi, l’agent Accessoires a proposédes modèles de cartes mémoire mc4 et mc5 sur la base des appareils photo a1 eta2.

D’autre part, l’agent ayant construit une proposition peut être distinct de celuiqui a fourni celle sur laquelle le premier s’est basé. Dans notre exemple, les appareilsa1 et a2, à partir desquels l’agent Accessoires a fourni ses propositions, ont étéproposés par un autre agent PhotoSon&Vidéo.

Définition 5 On dit qu’une requête présente des dépendances si la valeur del’un des attributs définissant ses contraintes ou ses paramètres est une sélectionindéfinie g(request-get), où g est un symbole d’attribut.

5.1. PROBLÈME 99

Dans notre précédent scénario, les requêtes r2, r3 et r4 présentent des dé-pendances. En effet, dans leurs paramètres ou contraintes, les valeurs de cer-tains attributs sont exprimés en fonction de sélection indéfinies g(request-get) (ex.ref(request-get), refcard(request-get), etc).

Définition 6 On dit qu’une requête r est dépendante d’une autre r′, et on noter ≺ r′, ssi :

– r 6= r′ et ;– Soit r=Order(E(p1, p2, ...)), telle que pi = ∧jopj(fj , xi, valuej),ou r=What-is(selection|c1, c2, ...), telle que ci = ∧jopj(fj , xi, valuej).– Si l’une des valeurs valuej définissant l’un des paramètres pi ou l’une descontraintes ci est une sélection valuej=g(request-get) ;

– et si g ∝ d, où d est une proposition dans la réponse ρ′ à une requête r′.alors r est dépendante de r′.

Reprenons les deux premières requêtes r1 et r2 de l’utilisateur dans notre scé-nario d’illustration du précédent chapitre :

r1=What-is(∗(x) | equal(type, x, camera) ∧ . . . ) ;r2=What-is(∗(x) | equal(type, x,memory-card) ∧

equal(compliant, x, ref(request-get))).

Dans cet exemple, la requête r2 est dépendante de la requête r1. En effet,comme nous le présentions dans l’introduction des dépendances entre requêtes dansle chapitre 3 [c.f. section 3.1.2.1, page 48], la requête r2 est dépendante de cellequi lui fournira la valeur de l’attribut ref . Au fil de l’interaction des agents, nousavons vu que c’est dans la réponse à la requête r1 que cette valeur est fournie.Ainsi, r2 ≺ r1.

Définition 7 Une requête ri est dite libre ssi :– elle ne présente pas de dépendances, i.e. les contraintes et les paramètresqu’elle comporte sont exprimés en fonction de valeurs statiques ;

– et si aucune autre requête ne dépend d’elle, c’est-à-dire : ∀i′, ri′ ⊀ ri et ri ⊀ri′.

Dans notre précédent exemple, aucune requête n’est libre. Toutes dépendentsoit d’une ou plusieurs requêtes (par exemple r3 dépend de r1 et r2) ou appa-raissent dans les dépendances d’autres requêtes (par exemple r1 apparait dans lesdépendances de toutes les autres requêtes).

Définition 8 Une proposition P(ri)kest associée à une autre P(ri′ )k′ ssi :

– ri ≺ ri′ ou ri = ri′ ;– P(ri)k

a été construite sur la base de P(ri′ )k′ ;

Dans notre exemple, la proposition de la carte mémoire mc4 est associée à laproposition de l’appareil photo a1. En effet, la requête r2 pour laquelle mc4 a étéfournie est dépendante de la requête r1 pour laquelle a1 a été founi. De plus, mc4


a été proposée sur la base de la référence de l’appareil a1. Donc mc4 est associée àa1.

Définition 9 Une proposition P(ri)kest dite compatible avec une autre P(ri′ )k′

ssi :– P(ri)k

est associée à P(ri′ )k′ ;– ou alors si ri′ est libre.

Selon cette définition, le modèle de carte mémoire mc4 est compatible avecle modèle d’appareil photo a1. Supposons alors que l’utilisateur ait demandé àavoir des modèles de lecteurs DVD, à travers une requête libre, sans rapport avecl’appareil photo et les cartes mémoires. Si dvd3 est l’un des modèles de lecteursDVD proposés, alors la proposition mc4 est dite compatible avec dvd3. De mêmea1 est compatible avec dvd3.

Dans notre approche, l’utilisateur peut exprimer une contrainte globale qu’unensemble de propositions doivent respecter. Comme nous le présentions dans lechapitre 3 [c.f. section 3.1.3.2, page 50], une contrainte globale est une conditionbooléenne que les attributs d’un ensemble de propositions, fournies pour des re-quêtes distinctes, doivent respecter. Par exemple, le prix d’acquisition et de livrai-son de produits ne doit pas dépasser un certain budget. Ou encore, la durée d’unvol plus celle des escales ne doivent pas dépasser une certaine durée de temps, etc.

5.1.2 Formulation du problème

Soient les ensembles de propositions P(ri)1 , P(ri)2 , . . . collectées pour chaquerequête ri ∈ R de l’utilisateur.

Notation. Comme nous le mentionnions plus haut, chaque proposition est ca-ractérisée par un ensemble de propriétés. Nous notons Ωk l’ensemble des propriétésd’une proposition P(ri)k

. L’ensemble Ωk regroupe ainsi les paires “attribut-valeur”pour la proposition P(ri)k

. Il est formalisé par :Ωk = (fl, valuel)l∈N où fl est un attribut, et valuel sa valeur pour la propositionP(ri)k

.

Ainsi, chaque proposition P(ri)k: [Ωk, aj ] est liée à l’ensemble Ωk de ses pro-

priétés ainsi qu’à l’identifiant de l’agent aj l’ayant construite.

ExempleDans notre précédent scénario, l’appareil photo a2 représente la proposition

P(r1)2 : [Ωa2 ,PhotoSon&Vidéo]. C’est-à-dire que l’appareil photo a2 a été proposépar l’agent PhotoSon&Vidéo 1 et qu’il est caractérisé par l’ensemble de propriétésΩa2 . Ce dernier vaut :

Ωa2 = (ref,CN550), (resolution, 8Mpx), (price, 250AC), . . ..De même, le modèle de carte mémoire mc4 représente la proposition P(r2)1 :

[Ωmc4 ,Accessoires]. C’est-à-dire que la carte mémoiremc4 a été proposée par l’agent

1. L’agent PhotoSon&Vidéo a également proposé l’appareil a1. L’appareil a2 est donc sadeuxième proposition, d’où la notation P(r1)2 .


Accessoires et qu’elle est caractérisée par l’ensemble de propriétés Ωmc4 . Ce derniervaut :

Ωmc4 = (refcard,EX3213), (storage-capacity, 1Go), (pricecard, 40AC), . . ..

Soit alors la contrainte globale : opcg(symbii∈[o,z−1], fii∈[0,z], value), où zest inférieur ou égal au nombre de requêtes de l’utilisateur. Celle-ci vise à acquérirl’ensemble des propositions dont les valeurs des attributs fi combinées avec lesopérations symbi moyennant la fonction ./ [voir sa définition dans l’équation 3.2,page 51], respectent la valeur value.

Dans ce contexte, résoudre le problème de la sélection des services compatiblespar rapport aux contraintes globales revient à déterminer l’offre (ou les offres)optimale(s) Ow : P(r1)k1

, P(r2)k2, . . . à proposer à l’utilisateur telle(s) que :

– Dans chaque offre Ow, il y a exactement une proposition P(ri)kpour chaque

requête ri de l’utilisateur ;– Chaque proposition P(ri)k

∈ Ow doit être compatible avec toutes les autresP(ri′ )k′ ∈ Ow, i 6= i′, qui y sont incluses ;

– Et selon opcg :– ./ (symbii<z, fii6z) < value, si opcg=lesscg ;– ./ (symbii<z, fii6z) > value, si opcg=greatercg ;– ./ (symbii<z, fii6z) = value, si opcg=equalcg.

5.2 Scénario d’illustration

Pour illustrer les données de notre problème, nous reprenons le scénario duprécédent chapitre et le modifiant légèrement pour les besoins de notre problème.

Soit un utilisateur voulant acquérir un appareil photo et une carte mémoiredotés des même caractéristiques exprimées dans notre précédent scénario (sachantque la carte mémoire doit être compatible avec le modèle d’appareil photo trouvé).Cette fois-ci, il veut en plus se faire livrer ses produits, et s’inscrire à une formationde photographie.

r1 What-is(∗(x) | equal(type, x, camera) ∧ equal(trademark, x, canon) ∧greater(resolution, x, 7Mpx) ∧ greater(exp-duration, x, 1))

r2 What-is(∗(x) | equal(type, x,memory-card) ∧greater(storage-capacity, x, 1Go) ∧equal(compliant, x, ref(request-get)))

r3 Order(Deliver(equal(ref, x, ref(request-get)),equal(refcard, y, recard(request-get)) ∧equal(compliant, y, ref(request-get)))

r4 Order(RegisterPhotoCourse(equal(level, x, starter))

Table 5.1 – Les requêtes de l’utilisateur (scénario des contraintes globales).

Dans notre modèle, la demande de l’utilisateur est formalisée par quatre re-quêtes : r1 pour la recherche de l’appareil photo, r2 pour la recherche du modèle de


carte mémoire compatible, r3 pour la commande de livraison et r4 pour la demanded’inscription. Ces requêtes sont détaillées sur le tableau 5.1.

Notre utilisateur souhaite par ailleurs que le coût total des opérations ne dépassepas 450AC, soit :

lesscg(+,+, cameraPrice,mcardPrice, deliveryPrice, 450AC).

À présent, supposons que cinq agents participants se soient coordonnés poursatisfaire l’ensemble des requêtes de l’utilisateur. Ces agents sont :

1. L’agent a1 : PhotoSon&Vidéo ;

2. L’agent a2 : Accessoires ;

3. L’agent a3 : Livraison ;

4. L’agent a4 : FormationPhoto ;

5. L’agent a5 : FormationPhoto2 ;

Le tableau 5.2 représente la liste de propositions candidates construites parl’agent de l’utilisateur à l’issue de la coordination des agents participants. C’esten fait la liste des réponses candidates dans laquelle chaque résolution positive aété remplacée par l’ensemble des propositions qu’elle contient. Dans ce tableau,chaque proposition a en plus été inscrite avec son prix ainsi que, entre parenthèse,la proposition à partir de laquelle elle a été construite.

Requête Agent Propositionsr1 Agent PhotoSon&Vidéo a1 : 150AC

a2 : 180ACr2 Agent PhotoSon&Vidéo mc1 : 50AC (pour a1),

mc2 : 45AC (pour a1),mc3 : 25AC (pour a2)

Agent Accessoires mc4 : 40AC (pour a1),mc5 : 26AC (pour a2)

r3 Agent Livraison Delivery1 : 55AC (pour a1, mc1),Delivery2 : 55AC (pour a1, mc2),Delivery3 : 55AC (pour a2, mc3),Delivery4 : 55AC (pour a1, mc4),Delivery5 : 55AC (pour a2, mc5)

r4 Agent FormationPhoto Register1 : 200ACAgent FormationPhoto2 Register2 : 250AC

Table 5.2 – Liste de propositions candidates (scénario des contraintes globales).

Le tableau 5.2 montre que plusieurs combinaisons de propositions peuvent êtrefaites à l’utilisateur. Voyons dans ce qui suit comment construire celles qui tiennentcompte des associations entre les propositions et de la contrainte globale spécifiéepar l’utilisateur.

5.3. RÉSOLUTION DU PROBLÈME 103

5.3 Résolution du problème

Soit R = r1, r2, . . . , rn l’ensemble des requêtes de l’utilisateur, et A=a1, a2,. . . , a|participants| l’ensemble des agents participants qui se sont coordonnés pourles satisfaire.

À l’issue de la coordination, un ensemble de propositions P(ri)1 , P(ri)2 , . . . estconstruit pour chaque requête ri ∈ R de l’utilisateur. Chaque proposition P(ri)k

:[Ωk, aj ] est associée à son ensemble de propriétés Ωk ainsi qu’à l’identifiant del’agent aj l’ayant construite.

L’algorithmique du problème de la sélection des services compatibles par rap-port aux contraintes globales implique donc de déterminer la ou les offres respectantla contrainte globale formulée par l’utilisateur, telle que opcg(symbii<z, fii6z, value),où symbi sont des opérations, et fi sont des symboles d’attributs.

Pour construire une telle offre, nous procédons en deux principales étapes :1. Construire d’abord les offres, où chaque offre Oq contient exactement une

proposition pour chaque requête, et dans laquelle chaque proposition est com-patible avec toutes les autres qui y sont incluses ;

2. Sélectionner l’offre (ou les offres) Ow respectant la contrainte globale de l’uti-lisateur.

5.3.1 Construction des offres

L’étape de construction des offres nécessite d’explorer les propositions des agentstout en disposant de certaines informations les concernant. Il s’agit notamment despropriétés (paires attribut-valeur), de l’identité de l’agent fournisseur, et de l’en-semble de propositions associées. Il faut alors :

– Construire un tableau des propositions des agents. Celui-ci doit regrouper,pour chaque requête de l’utilisateur, l’ensemble des propositions qui lui ontété faites, chacune écrite sous la forme P : [Ω, a, N ] où P est une proposition,Ω son ensemble de propriétés, a l’agent l’ayant construite et N l’ensembledes propositions associées ;

– Explorer le tableau des propositions pour la construction des offres.

5.3.1.1 Tableau de propositions PTab

Nous voulons disposer d’une structure de données dans laquelle nous aurionsles mêmes informations que celles reportées sur le tableau 5.2 pour notre exemple.C’est-à-dire qu’on doit avoir accès, pour chaque proposition, à ses propriétés, sonagent fournisseur, et l’ensemble de ses requêtes associées.

Pour ce faire, nous construisons un tableau de propositions appelé PTab. Cetableau comprend, pour chaque requête de l’utilisateur, l’ensemble des propositionsqui ont été fournies par les agents sous la forme Pk : [Ωk, aj , Nk].

Par exemple, la proposition de la carte mémoire mc1 suite à la construction dece tableau doit apparaître sous la forme : mc1 : [Ωmc1 ,PhotoSon&Vidéo, a1], oùΩmc2 = (refcard,EX3211), (pricecard, 50AC), . . ..


Algorithm 11 Construction du tableau de propositions PTab.Entrées: R l’ensemble des requêtes de l’utilisateur ;

L(ri) l’ensemble des listes de réponses candidates pour toutes les requêtes ri ∈R ;

Sorties: PTab le tableau des propositions des agents.1: Soit PTab un tableau à une dimension, de taille |R| ;2: pour tout i : R faire3: PTab[i].reqCol()← ri ;4: pour tout j : L(ri) faire5: ρk ← getResponses(L(ri))[k] ;6: pour tout ρk : ρk faire7: si ρk=Assert-is(D′) alors8: pour tout dl : D′ faire9: PTab[i].propCol()[j]← dl : [getPairs(dl), getAgent(L(ri)[k]), ∅] ;10: fin pour11: sinon si ρk =Ack(E(S)) alors12: PTab[i].propCol()[j]← S ;13: finsi14: fin pour15: fin pour16: fin pour17: return PTab ;

Pour construire PTab, nous partons de la liste des réponses candidates et éla-guons chaque réponse ou résolution positive en l’ensemble des propositions qu’ellecontient. C’est ce que décrit l’algorithme 11. Dans ce dernier :

– reqCol est la fonction qui retourne la colonne des requêtes du tableau PTab ;– propCol est celle qui retourne la colonne des propositions du tableau PTab ;– getResponses est la fonction qui retourne, pour un élement de la liste des

réponses candidates, et pour un agent, les réponses fournies par cet agent ;– getPairs est la fonction qui retourne les paires (fi,valuei) à partir d’une

expression d = ∧iequal(fi, d, valuei) ;– Quant à la fonction getAgent, elle retourne, pour un élément de la liste de

réponses candidate, et pour l’élément correspondant aux réponses d’un agent,l’identifiant de l’agent en question.

Par ailleurs, à l’issue de l’application de l’algorithme 11, l’ensemble N des pro-positions associées à chaque proposition est laissé à vide (il est ensuite rempli parun autre algorithme présenté ci-après).

Sur le scénario

Dans notre scénario d’illustration, le tableau de propositions PTab construitest à cette étape conforme au tableau 5.3.


r1 r2 r3 r4a1 : [150AC,a1, ∅] mc1 : [50AC,a1, ∅] Deliver1 : [55AC,a3, ∅] Register1 :a2 : [180AC,a1, ∅] mc2 : [45AC,a1, ∅] Deliver2 : [55AC,a3, ∅] [200AC,a4, ∅]

mc3 : [25AC,a1, ∅] Deliver3 : [55AC,a3, ∅] Register2 :mc4 : [40AC,a2, ∅] Deliver4 : [55AC,a3, ∅] [250AC,a5, ∅]mc5 : [26AC,a2, ∅] Deliver5 : [55AC,a3, ∅]

(cameraPrice) (cardPrice) (deliveryPrice) (schoolPrice)

Table 5.3 – Tableau de propositions PTab (scénario des contraintes globales)avant l’application de la fonction setAssoProposals.

Pour des soucis de lisibilité, et puisque la contrainte de l’utilisateur ne men-tionne que les prix des services requis, nous n’avons reporté que les valeurs de cetattribut là pour chaque proposition à la place de l’ensemble Ω.

De même, pour ne pas encombrer le tableau, le nom de l’attribut pour lequel lavaleur est inscrite avec la proposition est reporté sur la dernière ligne du tableau.

Revenons à la construction du tableau PTab. Pour remplir le champ N despropositions associées à chaque requête (laissé précédemment à vide), le tableauPTab est parcouru, et chaque proposition se voit affecter l’ensemble de son champN moyennant la fonction setAssoProposals. Celle-ci retourne donc pour une pro-position donnée, l’ensemble des propositions associées. Elle est décrite dans l’algo-rithme 12. Dans ce dernier :

– La fonction getTriggeringRequest retourne, pour chaque proposition, la re-quête de l’utilisateur pour laquelle elle a été fournie.

– La fonction getProposals retourne à l’inverse, pour chaque requête l’ensemblede propositions collectées.

– Pour ce qui est la fonction n, elle est vrai si une proposition apparaît (ou estincluse) dans la formule d’une autre, et fausse sinon. Elle est formellementdécrite comme suit :Soit P1 = ∧iequal(fi, d1, valuei) et P2 = ∧jequal(fj , d2, valuej).P1 n P2 est vraie ssi :– getRequest(P1) ≺ getRequest(P2) et ;– ∃i, j valuej = valuei

Sur le scénario

Après application de la fonction setAssoProposals, le tableau de propositionsPTab construit est conforme au tableau 5.4. Les ensembles de propositions associéesinsérées sont marquées en rouge (soulignées).

5.3.1.2 Calcul des offres

À présent, on peut appliquer l’algorithme 13 pour la construction des ensemblesd’offres en explorant le tableau PTab.


Algorithm 12 La fonction setAssoProposals : P → N .Entrées: P une proposition ;

PTab le tableau des propositions.Sorties: Ensemble N des propositions associées rempli.1: Soit ri ← getTriggeringRequest(P ) ;2: pour tout ri′ telle que ri ≺ ri′ faire3: Soit E ← getProposals(ri′) ;4: pour tout Pk : E faire5: si Pk n P alors6: N ← N,Pk ;7: finsi8: fin pour9: fin pour

r1 r2 r3 r4a1 : [150AC,a1, ∅] mc1 : [50AC,a1, a1] Deliver1 : [55AC,a3, a1,mc1] Register1 :a2 : [180AC,a1, ∅] mc2 : [45AC,a1, a1] Deliver2 : [55AC,a3, a1,mc2] [200AC,a4, ∅]

mc3 : [25AC,a1, a2] Deliver3 : [55AC,a3, a2,mc3] Register2 :mc4 : [40AC,a2, a1] Deliver4 : [55AC,a3, a1,mc4] [250AC,a5, ∅]mc5 : [26AC,a2, a2] Deliver5 : [55AC,a3, a2,mc5]

(cameraPrice) (cardPrice) (deliveryPrice) (schoolPrice)

Table 5.4 – Tableau de proposition PTab (scénario des contraintes globales).

Il s’agit donc simplement de construire les “bonnes” combinaisons de proposi-tions, i.e. en ne créant que les offres de propositions compatibles.

Cet algorithme stipule que pour générer les offres, le tableau PTab des propo-sitions doit être exploré de la façon suivante :

– On débute l’exploration par la première colonne, correspondant à la requêter1. On sélectionne la première proposition P(r1)1 et on crée une offre O1 danslaquelle on insère cette proposition.

Sur le scénario

Dans notre exemple, on aura : O1 = a1.

– On passe ensuite à la deuxième colonne. Pour toutes les propositions P(r2)k:

[Ωk, aj , Nk] dont :– Nk = ∅ ;– ou bien P(r1)1 ∈ Nk ;on réplique l’offre O1 autant de fois que de propositions trouvées, et on insèrechaque proposition dans une offre.


Sur le scénario

Les propositions mc1, mc2 et mc4 comportent dans leur ensemble Nk laproposition a1 de l’offre en cours. On réplique donc l’offre en cours O1 poury insérer les propositions trouvées comme suit :O1 = a1,mc1 ;O2 = a1,mc2 ;O3 = a1,mc4.

– Pour toutes les autres colonnes, et pour chaque offre Oq construite, il suffitde procéder de la même manière en sélectionnant les propositions P(ri)k

:[Ωk, aj , Nk] telles que :– Nk = ∅ ;– ou bien, ∀i′ < i, si ri ≺ ri′ :∀P(ri′ )k′ ∈ Oq, P(ri′ )k′i′<i ∈ Nk.C’est-à-dire que si la requête explorée ri dépend d’une ou plusieurs autresprécédemment explorées ri′ , les propositions à sélectionner sont alors cellesqui contiennent dans leur ensemble N les propositions, correspondant auxrequêtes ri′ , incluses dans l’offre en cours.

De même, on réplique l’offre Ok en cours autant de fois que de propositionstrouvées, et on insère chaque fois une proposition.

Sur le scénario

Dans notre exemple, on arrive à la troisième colonne avec l’offre O1 =c1,mc1. Sachant que r3 est dépendante de r1 et de r2, on recherche lespropositions dont l’ensemble N de propositions associées est soit vide soitcomprend c1 et mc1.Ainsi, une seule proposition est compatible avec celles de O1, et l’offre O1

devient alors :O1 = a1,mc1, Deliver1.On procède de même pour les autres offres O2 et O3 qui deviennent à leurtour :O2 = a1,mc2, Deliver2.O3 = a1,mc4, Deliver4.

– On procède ainsi jusqu’à la dernière colonne de requêtes.

Sur le scénario

Dans notre exemple, les dernières propositions étant issues de requêtes indé-pendantes, on réplique les offres en cours en conséquence, et on y insère cespropositions. Les offres en cours deviennent les suivantes :O1 = a1,mc1, Deliver1, Register1.O2 = a1,mc2, Deliver2, Register1.O3 = a1,mc4, Deliver4, Register1.O4 = a1,mc1, Deliver1, Register2.O5 = a1,mc2, Deliver2, Register2.


O6 = a1,mc4, Deliver4, Register2.

– On revient ensuite à la première colonne de PTab et on procède de la mêmemanière en commençant par la prochaine proposition P(r1)2 , et ainsi de suitejusqu’à ce qu’aient été formées toutes les offres à partir de toutes les propo-sitions P(r1)k

.

Sur le scénario

Dans notre exemple, on reprend depuis la prochaine proposition a2 (fourniepour la requête r1). En procédant de la même manière, on obtient les offres :O7 = a2,mc3, Deliver3, Register1.O8 = a2,mc5, Deliver5, Register1.O9 = a2,mc3, Deliver3, Register2.O10 = a2,mc5, Deliver5, Register2.

Dans l’algorithme 13 pour la construction des offres :– getAssoProposals est la fonction qui retourne, pour une proposition donnée,

l’ensemble N de ses propositions associées ;– et la fonction compatible est une fonction qui retourne vrai si une proposition

est compatible avec un offre. Elle est décrite dans l’algorithme 14.

5.3.1.3 Similarités et distinction avec l’opération de jointure

Nous avons mentionné en introduction de ce chapitre les similarités de l’algo-rithme proposé avec une opération de jointure de tables en base de données.

En effet, lorsque les propositions sont compatibles du fait des dépendances deleurs requêtes d’origines, la construction du tableau PTab équivant à une jointurenaturelle sur la base de l’attribut en commun entre les propositions (la référencede l’appareil photo dans notre exemple). Lorsque les propositions sont compatiblesdu fait que leurs requêtes d’origine sont libres, l’opération équivant à une jointureexterne [23].

Cependant, l’algorithme proposé se distingue d’une opération de jointure dufait que la compatibilité des propositions, qui est vérifiée lors de la constructiondes offres compatibles, se base non seulement sur les attributs en commun entre lespropositions mais également sur les dépendances apparaissant entre leurs requêtesd’origine. Ainsi, deux propositions ayant un attribut en commun mais dont lesrequêtes d’origine ne sont pas dépendantes peuvent apparaître séparément dansdes offres distinctes, alors que l’opération de jointure aurait conduit à l’éliminationde ces offres possibles.


Algorithm 13 Construction des offres Oq.Entrées: PTab le tableau des propositions.Sorties: Oqq∈N les ensembles d’offres.1: Soit le nombre d’offres q ← 0 ;2: Soit un booléen rep ;3: pour tout i : PTab faire4: propTab← getProposals(i) ;5: rep← false ;6: pour tout k : propTab faire7: Soit P(ri)k

la proposition à examiner ;8: si i = 1 alors9: q + + ;10: Créer Oq ← P(r1)k

;11: sinon12: Soit Nk ← getAssoProposals(P(ri)k

) ;13: si Nk = ∅ ou compatible(P(ri)k

, Oq) alors14: si ref = false alors15: Oq ← Oq + P(ri)k

;16: rep = true ;17: sinon18: q + + ;19: Créer Oq ← Oq + P(ri)k

;20: finsi21: finsi22: finsi23: fin pour24: fin pour

Algorithm 14 Fonction compatible : P(ri), O → boolean.Entrées: P(ri) proposition ;

O une offre ;PTab le tableau des propositions.

Sorties: vrai si P(ri) compatible avec l’offre O, faux sinon.1: Soit ri ← getTriggeringRequest(P(ri)) ;2: Soit un booléen compatible← true ;3: pour tout i′ : O faire4: Soit ri′ ← getTriggeringRequest(P(ri′ )

) ;5: si ri ≺ ri′ alors6: si P(ri′ )

/∈ getAssoProposals(P(ri)) alors7: compatible← false ;8: break ;9: finsi10: finsi11: fin pour12: return compatible ;


5.3.2 Sélection des offres optimales

Après avoir construit les offres comportant les bonnes combinaisons des propo-sitions des agents, il suffit à présent de sélectionner celle(s) qui répond(ent) à lacontrainte globale de l’utilisateur.

Rappelons qu’une telle contrainte opcg(symbii<z, fii6z, value) requiert quel’offre Ow à sélectionner comprenne les propositions, dont les valeurs des attributsfi combinés par symbi, respectent la valeur value stipulée tel que :

– ./ (symbii<z, fii6z) < value, si opcg=lesscg ;– ./ (symbii<z, fii6z) > value, si opcg=greatercg ;– ./ (symbii<z, fii6z) = value, si opcg=equalcg ;

Étant donné le tableau PTab des propositions, où chaque proposition est re-portée sous la forme P : [Ω, a, N ], les valeurs des attributs fi sont alors recherchéesau niveau des ensembles de propriétés Ω = (fj , valuej)j∈N.

Nous définissons la fonction getV alue pour retourner la valeur d’un attribut àpartir d’une proposition comme suit :

getV alue(fi, P )=valuej ssi (fj , valuej) ∈ Ω et fi = fj .

Utilisant cette fonction, la sélection des offres optimales est alors réalisée parl’algorithme 15. Soit opcg l’opérateur dans la contrainte globale de l’utilisateur.Dans l’algorithme 15, opcg est la fonction qui retourne vrai pour deux valeurs v1 etv2 si :

– opcg=lesscg et v1 < v2 ;– opcg=greatercg et v1 > v2 ;– opcg=equalcg et v1 = v2.

Sur le scénario

Dans notre exemple, l’utilisateur demande que le prix de l’intégralité de l’offrene dépasse pas 450AC. En évaluant les offres précédemment construites, on obtient :

O1 = c1,mc1, Deliver1, Register1 : 455AC.O2 = c1,mc2, Deliver2, Register1 : 450AC.O3 = c1,mc4, Deliver4, Register1 : 445AC.O4 = c1,mc1, Deliver1, Register1 : 505AC.O5 = c1,mc2, Deliver2, Register1 : 500AC.O6 = c1,mc4, Deliver4, Register1 : 495AC.O7 = c2,mc3, Deliver3, Register1 : 460AC.O8 = c2,mc5, Deliver5, Register1 : 461AC.O9 = c2,mc3, Deliver3, Register1 : 510AC.O10 = c2,mc5, Deliver5, Register1 : 511AC.C’est finalement les offres optimales O2 et O3 qui seront proposées à l’utilisa-

teur.

5.4. COMPLEXITÉ CALCULATOIRE DE LA SOLUTION 111

Algorithm 15 Sélection des offres optimales Ow.Entrées: Okk∈N les offres construites ;

c la contrainte globale de l’utilisateur.Sorties: Ow les offres optimales.1: pour tout Ok : Okk∈N faire2: Soit une valeur globale Vk ← 0 ;3: pour tout Pj : Ok faire4: pour tout symbi, fi ∈ c faire5: Vk ← ./ (symbi, Vk, getV alue(fi, Pj)) ;6: fin pour7: fin pour8: Ok ← Ok : Vk ;9: fin pour

10: Soit Ow l’ensemble des offres optimales, vide ;11: pour tout Ok : Okk∈N faire12: si opcg(Vk, value alors13: Ow ← Ow, Ok ;14: finsi15: fin pour16: return Ow ;

5.4 Complexité calculatoire de la solution

Pour évaluer la complexité de l’intégralité de la solution que nous proposonspour le problème de la sélection des services compatibles par rapport aux contraintesglobales exprimées, nous évaluons celles de ses différentes étapes sur la base desalgorithmes sur lesquels ces étapes s’appuyent.

Soit n le nombre de requêtes formulées par l’utilisateur, et k le nombre maxi-mum de propositions fournies pour une même requête.

1. Construction du tableau de dépendances (utilisé par la fonction ≺) :Pour chaque requête, cette opération requiert d’explorer toutes les autresrequêtes. Sa complexité au pire est de O(n2).

2. Construction du tableau de propositions PTab :L’agent de l’utilisateur parcourt la liste des réponses candidates, contenantautant d’éléments que de requêtes (c’est-à-dire n). Pour chaque élément, ilexplore le nombre de réponses fournies pour une même requête. Si le nombremaximum de réponses pour une même requête est de k′, où k′ < k, la com-plexité au pire jusque là est de O(k′n).A cela, s’ajoute la complexité de la fonction setAssoProposals() pour remplirl’ensemble N des propositions associées. Elle au pire de O(kn).

3. Construction des offres Oq :Cette étape requiert de parcourir pour chaque requête, les propositions quilui ont été fournies. Ensuite, elle nécessite d’examiner chaque proposition parrapport aux offres en cours, pour voir comment l’insérer.


La complexité au pire pour la construction des offres Oq atteindra donc aupire O(kn).

4. Sélection des offres optimales Ow :Cette étape nécessite de parcourir les offres Oq construites, et évaluer pourchacune l’équation de la contrainte globale de l’utilisateur (i.e. les valeurs desattributs apparaissant dans la contrainte globale).Notons que le nombre d’offres construites Oq est restreint par le fait que lesrequêtes de l’utilisateur sont rarement indépendantes les unes des autres (eneffet, leurs dépendances justifient en grande partie la nécessité de coordina-tion). Il est au pire deO(k′mk′′) où k′ est le nombre maximum de propositionspour une requête dépendante, m le nombre de requêtes indépendantes et k′′

le nombre de propositions maximum pour une requête indépendante, sachantque k′, k′′ < k et m < n.Au pire, la sélection des offres optimales Ow requiert O(k2n) pour son exé-cution.

En conséquence, la complexité de notre solution dans le pire des cas, étantdonnées n requêtes et k propositions au maximum pour une requête, est de : O(kn).

Concrètement, n et k sont toujours petits. En particulier, le nombre de requêtesn ne dépassent pas les 5 requêtes et le nombre de propositions k se réduit à mesureque les requêtes comportent des contraintes locales restrictives.

5.5 Conclusion

Dans notre approche, les requêtes de l’utilisateur sont satisfaites moyennant lacoordination d’agents. Cette coordination fournit en sortie un ensemble de réponsescomportant à leur tour un ensemble de propositions. Sachant que les requêtes del’utilisateur peuvent présenter des dépendances entre elles, la plupart des propo-sitions retournées sont en fait construites sur la base d’autres propositions parmicelles qui ont été collectées.

Dans ce chapitre, nous avons décrit et formalisé notre problème des servicescompatibles par rapport aux contraintes globales. Celui-ci consiste en effet à déter-miner l’offre optimale, regroupant une combinaison de propositions compatibles, etrépondant aux contraintes globales de l’utilisateur, à retourner à ce dernier.

Nous avons alors décrit sa résolution, qui consiste d’abord à construire l’en-semble d’offres regroupant les propositions compatibles, et ensuite sélectionnercelles qui satisfont les contraintes de l’utilisateur.

Notre solution construit strictement un nombre d’offres tel que les combinaisonsde propositions compatibles uniquement sont créées. En moyenne, le nombre depropositions n’atteint jamais une taille exponentielle puisque les requêtes dansnotre modèle ne sont jamais toutes libres, i.e. les dépendances qu’elles présentententre elles justifient la coordination des agents. Ces dépendances impliquent queles propositions ne peuvent pas toutes être combinées entre elles et réduisent ainsiconsidérablement le nombre d’offres possibles à construire.

5.5. CONCLUSION 113

Ainsi, en sortie de la coordination des agents participants et de la sélection deservices par l’agent de l’utilisateur, l’utilisateur se voit retourner toutes les offressatisfaisant aussi bien ses requêtes que ses contraintes globales. Il dispose de plus,pour chaque proposition, de ses propriétés et de l’identité de son agent fournisseur.


Chapitre 6

Expérimentations et synthèse del’approche de chorégraphie deservices

Nous venons de spécifier au long des précédents chapitres les algorithmeset structures de données permettant de concevoir une approche dynamique pourla collaboration des agents. Dans le présent chapitre, nous présentons les résultatsobtenus à l’implémentation.

En effet, dans une première partie, nous proposons deux scénarii illustrantdifférents aspects de notre protocole et évaluons les performances de ce dernier enterme de résultats produits, de flux de messages échangés et de temps d’exécution.De plus, suite à l’analyse de ces résultats, nous esquissons des propositions pourl’amélioration du comportement et des performances de notre protocole.

Dans une seconde partie, nous décrivons comment l’approche de chorégraphiesur le web s’articule autour de notre protocole de coordination multiagent. Nousprésentons notamment les phases de publication et de découverte de services, etexpliquons comment la chorégraphie sur le web s’appuie techniquement sur le pro-tocole multiagent que nous avons développé.

6.1 Expérimentations

Pour implémenter notre protocole de coordination, et évaluer ses performances,nous devions disposer d’un SMA composé d’agents introspectifs, que nous avonsintégralement . Celui-ci a été intégralement développé en Java 1.5.

6.1.1 Travail effectué

Pour implémenter notre SMA d’agents introspectifs, nous sommes partis dela plate-forme VDL développée par N. Sabouret [109]. Celle-ci permet en effet la

115

116 CHAPITRE 6. EXPÉRIMENTATIONS

conception et l’exécution d’agents capables d’interagir avec les utilisateurs humains,et de répondre à des questions sur leurs actions et leurs décisions.

Partant du principe d’implémentation de ces agents (i.e. réécriture d’arbresXML, observation et raisonnement sur le code, ainsi que de leur capacité à interagiravec l’utilisateur humain), nous avons successivement doté les agents des capacités,ACL et protocoles spécifiés dans les précédents chapitres, afin d’obtenir le SMAavec les propriétés requises.

Le travail effectué a consisté en la définition de 12 classes Java et la définitionet l’intégration de plusieurs méthodes au sein de classes préalablement existantede la plateforme.

– D’abord, nous avons développé une interface afin de permettre à l’utilisateurd’entrer ses requêtes et ses contraintes.

– Ensuite, nous avons muni les agents des capacités d’introspection décritesdans le chapitre 3. Rappelons que celles-ci permettent à un agent d’identifierles attributs faisant défaut, dans une commande reçue, pour le déclenchementd’une de ses actions. Cette opération se base sur l’analyse des préconditions(du type patron d’évènement) des actions de l’agent.

– Au module de raisonnement RPM, nous avons ajouté les traitements descommandes Order et des requêtes sur les données What-is. Ces traitementsfont appel à l’exploration de codes XML composés de plusieurs nœuds quisont parfois organisés sur plusieurs niveaux.

– Nous avons alors implémenté le langage de communication entre agents.Celui-ci permet aux agents de la plate-forme non seulement de communiquerentre eux, mais également de s’échanger des messages comprenant plusieursrequêtes.

– Aussi, nous avons muni chaque agent d’une table d’historique pour qu’ilspuissent mémoriser les messages échangés durant leurs interactions. Nousavons notamment implémenté plusieurs structures de données facilitant lamanipulation et la gestion des messages à plusieurs requêtes.

– Nous avons ensuite développé le protocole d’interaction multiagent, ainsi quetoutes les règles dialectiques auxquelles celui-ci fait appel. Là également, desstructures de données ont été conçues pour limiter le flux de messages enfonction des types des requêtes envoyées ainsi que de leurs agents destina-taires.

– Pour visualiser les interactions des agents, nous avons conçu une interface,appelée Sniffer, permettant de représenter graphiquement, au travers d’undiagramme de séquences, les messages échangés par les agents. Dans cetteinterface, chaque message peut être accédé et visualisé séparément.

Par ailleurs, nous avons implémenté plusieurs scénarii pour tester notre proto-cole de coordination. Dans ce chapitre, nous en présentons deux illustrant différentsaspects de notre protocole ainsi que son comportement sur différents types de re-quêtes, avec et sans dépendances, en variant le nombre/type d’agents et de requêtes.

6.1. EXPÉRIMENTATIONS 117

Chaque fois, nous évaluons les résultats obtenus et les performances en terme de ré-solution de requêtes, de flux de messages produits, de temps d’exécution, de tempsmoyen pour un agent pour calculer sa résolution des requêtes de l’utilisateur, et letemps moyen pour satisfaire chaque requête.

6.1.2 Scénario d’AmI

Notre premier scénario met en scène des agents ambiants domotiques. Il a pourbut d’illustrer les capacités d’un agent à décomposer une commande en fonctionde ses capacités. De plus, il montre comment il se coordonne avec ses accointantspour satisfaire l’intégralité de la requête.

6.1.2.1 Les besoins de l’utilisateur

Dans ce scénario, l’utilisateur a une seule requête : « Enregistre le programmetélé Desperate Housewives ». Dans notre modèle, elle est formalisée par :

r1 = Order(Record(equal(type, x, tv-program))∧equal(title, x,Desperate Housewives)))

En VDL-XML, les valeurs des attributs type sont considérés comme le noeudpère des autres paramètres de l’évènement. Ainsi, la précédente requête est écriteen VDL-XML commt suit :

<request><act>Order</act><object>

<Record><tv-program>

<title>Desperate Housewives</title></tv-program>

</Record></object>

</request>

Comme nous l’avons précédemment spécifié, l’utilisateur interagit avec un seulagent en charge de transmettre sa demande aux agents participants, et de déter-miner les réponses à proposer à l’utilisateur en fonction de ses contraintes. Dansnos scénarii, cet agent porte le nom de UserAgent. L’utilisateur lui communique sesbesoins à travers l’interface représentée par la figure 6.1. Celle-ci permet d’entreret sauvegarder plusieurs requêtes et contraintes.

6.1.2.2 Les agents participants

La requête de notre premier utilisateur est envoyée aux quatre agents domo-tiques suivants :

1. L’agent telephone qui est muni d’une base de données contenant les contactsde l’utilisateur et qui affiche le nom et le numéro des appelants ;


Figure 6.1 – Interface où l’utilisateur entre ses besoins.

Figure 6.2 – Extrait de la base de données de l’agent television.


Figure 6.3 – Extrait de l’action de l’agent dvdrecorder.

2. L’agent television qui est muni de base de données de type “télétext” où sontmémorisées les informations concernant les programmes télé diffusés. Le fi-gure 6.2 montre un extrait de sa base de données.

3. L’agent hifisystem qui est capable de diffuser des enregistrements vidéo ainsique des podcasts d’émissions radio ;

4. L’agent dvdrecorder qui est capable d’enregister un programme vidéo étantdonnées son heure de diffusion, sa durée et la chaîne télé où il est diffusé. Unextrait de cette action, en particulier son patron d’évènement, est reporté surla figure 6.3.

6.1.2.3 Résultats de l’application

En examinant la requête de l’utilisateur, ainsi que les capacités des agentsparticipants, on peut en conclure qu’aucun ne peut à lui seul prendre en chargel’intégralité de la requête.

En effet, l’agent dvdrecorder peut enregistrer, mais seul le titre du programmelui a été donné. La figure 6.3, dans laquelle apparaît son action et sa précondition,montre que les valeurs dont il a besoin sont celles de l’heure, la durée et chaîne dediffusion du programme.

D’autre part, comme le montre la figure 6.2, on peut constater que l’agenttelevision a les capacités de fournir les informations requises par l’agent dvdrecorder.Il faut donc que ces deux agents collaborent, de manière dynamique, pour résoudrela requête de l’utilisateur.

Dans les protocoles usuels tel que FIPA-CNP ou les protocoles de formationde coalition, l’interaction se serait arrêtée à l’envoi de réponses telles que failure ou


Figure 6.4 – Message initiateur pour le scénario d’AmI.

refuse (ou équivalentes en fonction de l’ACL) de la part des agents.

Dans notre approche, à la réception d’une requête qu’ils ne peuvent accomplir,les agents examinent en plus leur code en vue de déterminer s’ils peuvent au moinsprendre part à la résolution de la requête. C’est le cas de l’agent dvdrecorder.

La figure 6.4 montre le message initiateur pour ce scénario. Quant à la figure 6.5,qui représente le sniffer de notre application, elle capture les interactions des agentsà la réception de ce message qui contient la demande de l’utilisateur. On voit ainsisur cette dernière figure que l’agent dvdrecorder fait appel à ses accointants pourtenter de résoudre la requête de l’utilisateur. Ceci se traduit, dans ce scénario, parla construction de la requête What-is, représentée sur la figure 6.6, par l’agent dvdre-corder où celui-ci demande précisément les attributs qu’il requiert pour l’exécutionde son action, à partir des informations qu’ils possède (le titre du programme).

La requête What-is issue de la décomposition de la commande reçue est alorsenvoyée à tous les agents participants, sauf l’agent UserAgent et l’agent dvdrecorderlui-même. C’est l’agent television qui renvoie une assertion à cette requête d’aprèsles informations qu’il possède dans sa base de données (c.f. la figure 6.7).

À la réception de cette assertion, l’agent dvdrecorder examine sa table d’histo-rique, comme le spécifie la règle dialectique pour le traitement des requêtes Assert-is,afin de retrouver la requête d’origine (i.e. pour laquelle il attendait une assertion).Grâce aux identifiants des messages, il récupère la commande de l’utilisateur, larestructure en fonction des paramètres attendus par sa précondition, l’exécute etenvoie une confirmation d’exécution Ack. Celle-ci est représentée sur la figure 6.8.L’object de cette réponse, représenté plus bas sur cette même figure, montre bienque les attributs qui lui faisaient défaut ont été retrouvés et renseignés.


Figure 6.5 – Traces des interactions capturées par le sniffer (scénario d’AmI).


Figure 6.6 – Requête What-is construite par l’agent dvdrecorder après décomposi-tion de la commande de l’utilisateur.


Figure 6.7 – Assertion Assert-is envoyée par l’agent television à l’agent dvdrecorder.


Figure 6.8 – Résolution des besoins de l’utilisateur pour le scénario d’AmI.


6.1.2.4 Analyse

Les résultats de notre protocole pour ce scénario sont synthétisés sur le ta-bleau 6.1. Dans ce tableau, le temps moyen de coordination par agent indique letemps moyen consommé par un agent pour envoyer une résolution à l’agent initia-teur.

Par ailleurs, ce tableau indique que le flux de messages résultant est nettementinférieur à la complexité de communication théorique calculée dans le pire cas. Ilest de 12 messages produits contre 25 calculés théoriquement dans le pire cas.

De plus, on constate que le temps d’exécution total est supérieur au tempsconsommé pour résoudre la commande de l’utilisateur (c.f. la dernière ligne dutableau). Sachant que seuls deux des quatre agents participants ont participé à larésolution de cette commande, on peut en conclure que les performances de notreprotocole pourraient être améliorées via une phase de présélection d’agents. En ré-exécutant le scénario sans les agents figurants, i.e. qui n’ont pas de capacités utilespour les besoins de l’utilisateur, soit les agents hifisystem et telephone, on obtientun temps d’exécution total et un temps moyen pour la résolution de la commandemoitié inférieur aux précédents. Dans cette optique, une phase de découverte deservices est intégrée à l’approche globale sur le web afin de ne sélectionner que lesservices pertinents pour les besoins à satisfaire.

Nombre de requêtes 1 (décomposée)Nombre d’agents 5Flux de message 12

Temps d’exécution (en millisecondes) 281Temps moyen de coordination/agent 35

Résultat de la coordination r1 résolue en : 140 msPar : dvdrecorder et television

Table 6.1 – Résultats expérimentaux sur le scénario 1.

En conséquence, ce scénario aura démontré la capacité de notre protocole àcomposer des fonctionnalités ou compétences d’agents (television et dvdrecorder)pour la satisfaction des besoins de l’utilisateur. Cette composition est entièrementdynamique, car elle n’a reposé sur aucun plan ou règle, mais s’est plutôt fondéesur l’introspection des agents sur leurs actions. Plus précisément, ce scénario aillustré le traitement du RPM pour les commandes et leur décomposition (c.f.les réponses Assert-cannot et What-is dans la figure 6.5), l’application de la règledialectique pour le traitement des assertions (c.f. la réponse de l’agent dvdrecordersuite à la réception de l’assertion émise par l’agent television), et le calcul des agentsdestinataires (la réponse de l’agent dvdrecorder n’a été envoyée à l’agent UserAgentque lorsqu’il a pu construire une résolution pour la requête de l’utilisateur), Deplus, il aura montré le potentiel applicatif de notre approche au domaine de l’AmI[30].


6.1.3 Scénario de services web

Notre second scénario met en scène la coordination d’agents pour la satisfactiond’une demande de l’utilisateur en services web. Par rapport au précédent scénarioqui ne montrait que la capacité des agents à décomposer une commande complexeet à se coordonner pour la satisfaire, ce scénario a pour but d’illustrer la capacitédes agents à manipuler et à gérer plusieurs requêtes, présentant non seulement desdépendances entre elles mais devant également être décomposées au vue des compé-tences des agents participants. Ce scénario montre en plus la capacité du protocoleà organiser le flux des messages générés par le calcul des agents destinataires.

6.1.3.1 Les besoins de l’utilisateur

Notre deuxième utilisateur veut louer un film, dont le titre est The Prestige, auformat MPEG. Dans ce scénario, cette requête sera émise dans un contexte où iln’y pas de service disponible fournissant des vidéos MPEG. Cependant, à la place,il y a un service fournisseur de vidéos UIF et un service convertisseur UIF-MPEG.

Par ailleurs, cet utilisateur veut aussi obtenir l’affiche de ce même film etconnaître le prix de vente du film trouvé. Ces deux dernières requêtes vont doncdépendre du résultat trouvé à la première.

Les requêtes de l’utilisateur sont formalisées dans notre modèle par :

r1=Order(GetMPEGV ideo(equal(type, x, video) ∧ equal(title, x,The Prestige))) ;r2=Order(DisplayJacket(equal(refMovie, y, refMovie(request-get)))) ;r3=What-is(price(z)|equal(refMovie, z, refMovie(request-get))).

En VDL-XML, ces requêtes sont respectivement écrites comme suit :


<GetMPEGVideo><video>

<title>The Prestige</title></video>

</GetMPEGVideo></object>

</request>


<DisplayJacket><equal>

<refMovie/><refMovie><request-get/></refMovie>

</equal></DisplayJacket>


</object></request>

<request><act>What-is</act><object>

<price/><where>

<equal><refMovie/><refMovie><request-get/></refMovie>

<equal></where>

</object></request>

Figure 6.9 – Extrait du code de l’agent UIFVideoProvider.

6.1.3.2 Les agents participants

La requête de notre deuxième utilisateur est envoyée aux cinq agents partici-pants suivants :

1. L’agent UIFVideoProvider qui est muni d’une base de données contenant lesinformations à propos de films au format UIF. Un extrait de celle-ci apparaîtsur la figure 6.9 ;

2. L’agent UIFtoMPEGConverter qui retourne des films MPEG à partir des filmsUIF donnés en paramètre. Son action est reportée sur la figure 6.10 ;

3. L’agent MovieJacketDisplayer qui retourne des affiches de films à partir de laréférence des films. La figure 6.11 montre le début du code de son action ;


4. L’agent VideoSeller qui est un service de vente de vidéos. Il est muni d’unebase de données regroupant les informations à propos des vidéos proposées àla vente. La figure 6.12 représente un extrait de sa base de données ;

5. L’agent VideoSeller2 qui est un autre service de vente de vidéos.

Figure 6.10 – Extrait du code de l’agent UIFtoMPEGConverter.

Figure 6.11 – Extrait du code de l’agent MovieJacketDisplayer.

6.1.3.3 Résultats de l’application

En examinant les requêtes de l’utilisateur, ainsi que les connaissances et capa-cités des agents participants, on peut également conclure qu’aucun agent ne peutseul prendre en charge l’intégralité de chaque requête.

Comme pour le précédent scénario, les requêtes de l’utilisateur sont envoyéesaux agents participants par le biais de l’agent UserAgent. Le sniffer, représenté par


Figure 6.12 – Extrait du code de l’agent Scenario2VideoSeller.

les figures 6.13 et 6.14, illustre les interactions des agents pour résoudre ce scénario.Ces deux figures montrent qu’au départ tous les agents participants reçoivent

les requêtes de l’utilisateur émises par l’agent UserAgent. Celles-ci sont groupéesdans un même message initiateur comme le montre la figure 6.15. Chaque agenttente alors de répondre à chacune des requêtes comprises dans ce message. Si lesréponses résultantes ne sont pas toutes des résolutions, l’agent participant n’en-voie pas sa réponse à l’agent initiateur. C’est le cas de l’agent UIFVideoProviderqui n’a envoyé de réponse finale à UserAgent que lorsqu’il s’est assuré qu’aucunecollaboration ne pouvait l’aider à répondre à ces requêtes. Le cas de cet agentillustre d’ailleurs la règle dialectiques pour les réceptions des réponses Unknown,i.e. si aucune assertion n’a été reçue, la réponse n’est calculée que si tous les agentsquestionnés ont répondu. Le message réponse de l’agent UIFVideoProvider, qui n’apu répondre à aucune requête, est montré sur la figure 6.16.

L’agent UIFtoMPEGConverter, qui peut envoyer des vidéos MPEG (comme de-mandé par l’utilisateur), a besoin pour exécuter son action du film recherché au for-mat UIF. Il utilise alors la règle dialectique pour la décomposition des commandes,réussit à récupérer les informations à propos des paramètres qui lui manquent au-près de l’agent UIFVideoProvider, et compose sa réponse finale. Comme le montrela figure 6.17, celle-ci est proposée à l’utilisateur à l’issue de la coordination.

Pour gérer les requêtes dépendantes r2 et r3, les agents MovieJacketDisplayer,VideoSeller et VideoSeller2 envoient des requêtes Missing à leurs accointants. Commecelles-ci sont envoyées aux mêmes agents destinataires, elles sont groupées dans unmême message, comme le montre la figure 6.18.

Lorsque l’agent UIFtoMPEGConverter a exécuté la commande r1, il a envoyé avecsa confirmation d’exécution des informations relatives à son action, notamment laréférence du film. Ainsi, lorsqu’il reçoit une requête Missing demandant la référencedu film requis, il répond par une assertion, comme le montre la figure 6.19.

L’agent MovieJacketDisplayer qui reçoit cette assertion peut satisfaire la requête


Figure 6.13 – Début du sniffer pour le scénario services web.

r2. Lorsqu’il reçoit d’autres réponses Unknown à propos de la requête Missing qu’il aenvoyé, il recherche s’il a envoyé une résolution à l’agent UserAgent, et si c’est le cascomme dans notre exemple, il ne renvoie pas d’autres réponse. Puisque cet agenta pu résoudre l’une des requêtes de l’utilisateur, sa résolution est alors proposée àce dernier comme le montre la figure 6.20.

Il en est de même pour les agents VideoSeller et VideoSeller2 qui réussissent à ré-cupérer les informations concernant les attributs inconnus dans la requête What-isqu’ils tentent de résoudre. En effet, le premier l’obtient de l’agent MovieJacket-Displayer et le second de l’agent VideoSeller. Une fois l’information obtenue, lesagents VideoSeller et VideoSeller2 envoient leurs réponses à l’agent UserAgent quiles propose à son tour à l’utilisateur, comme le montre la figure 6.21.


Figure 6.14 – Suite du sniffer pour le scénario services web.

Figure 6.15 – Message initiateur pour le scénario 2.


Figure 6.16 – Message réponse de l’agent UIFVideoProvider.

Figure 6.17 – Résolution de la requête r1 par l’agent UIFtoMPEGConverter.


Figure 6.18 – Message regroupant des requêtes Missing envoyées aux mêmes des-tinataires.

Figure 6.19 – Assertions pour les requêtes Missing reçues.

Figure 6.20 – Résolution de la requête r2 par l’agent MovieJacketDisplayer.


Figure 6.21 – Résolution de la requête r3 par l’agent VideoSeller et VideoSeller2.


6.1.3.4 Analyse

Ce scénario a permis de illustrer l’utilisation de plusieurs règles dialectiques denotre protocole de coordination, notamment celles pour les requêtes Order, What-is,Assert-is, Missing, Unknown. De plus, il a montré la capacité des agents à gérer unensemble de requêtes complexes (à décomposer et présentant des dépendances).

Le tableau 6.2 synthétise les résultats de ce scénario. Il montre que pour 3 re-quêtes (dont 2 présentant des dépendances) envoyées à 6 agents, 50 messages ontété produits, soit moins que la complexité de communication calculée théorique-ment, i.e. 108. Cependant, là encore le nombre de messages pourrait être réduit sile calcul des agents destinataires prenaient en compte les capacités des agents.

Ce tableau, montre également que le temps d’exécution total est nettementinférieur à la somme des temps consommés pour résoudre chaque requête. Ceciprouve qu’il y a bien des traitements en parallèles de requêtes lorsque cela estpossible.

Enfin ce scénario a démontré que les agents réussissaient à gérer des ensemblesde requêtes dans un même message et contrôlaient le flux de messages par le calculdes agents destinataires en fonction des types de réponses construites. C’est lecas par exemple de l’agent VideoSeller qui a regroupé dans un même message lesrequêtes Missing qu’il devait envoyer à ses accointants. Dans le cas particulier decet exemple, les requêtes Missing en question visent à récupérer la valeur du mêmeattribut refMovie. Une amélioration possible du protocole consisterait à analyserle groupe de requêtes destinées aux mêmes agents afin d’éviter le redondances.

Nombre de requêtes 3 (dont 2 avec dépendance)Nombre d’agents 6Flux de message 50

Temps d’exécution 532Tps coordination/agent 65.4

Résultats r1 résolue en : 187 msPar : UIFtoMPEGConverter et UIFVideoProviderr2 résolue en : 265 msPar : MovieJacketDisplayer et UIFtoMPEGConverterr3 résolue en : 218 msPar : VideoSeller et VideoSeller2 et UIFtoMPEGConverter

Table 6.2 – Resultats expérimentaux sur le scénario 2.


6.2 Synthèse de l’approche de chorégraphie

Dans cette deuxième partie du chapitre, nous synthétisons notre approche dechorégraphie de services web. Pour ce faire, nous présentons les fonctionnalitésque les agents/services publient sur le web, expliquons comment les services sontdécouverts à partir des besoins de l’utilisateur et des fonctionnalités publiées, etenfin comment la chorégraphie de services sur le web s’appuie sur notre protocolede coordination multiagent.

6.2.1 Publication des services

Dans notre architecture, les connaissances des agents, données et actions confon-dues, sont assimilées à un service. Déployés sur le web, les agents sont vus commedes entités offrant des services web. Chaque service peut alors être publié et décou-vert à partir d’un registre, et invoqué en ligne par des utilisateurs ou des applica-tions tierces.

Pour ce faire, chaque service se voit générer une interface WSDL [33] pourrendre possible son invocation en ligne, et un modèle UDDI [1] pour permettre sapublication et sa découverte à partir d’un registre.

Pour décrire notre procédure de publication de services, nous présentons briè-vement les principes des spécifications WSDL et UDDI, et nous montrons ensuitecomment les concepts de notre approche sont appariés à ceux de ces modèles.

6.2.1.1 Le rôle de WSDL

La spécification du langage WSDL est à sa version 2.0 (depuis août 2004) et estrécemment devenue une recommandation du W3C (depuis juin 2007). Elle décritles différentes parties que l’interface d’un service doit comprendre, notamment, lestypes utilisés, les messages impliqués dans l’interaction avec le service, les ensemblesd’opérations constituant un service, la localisation du service fournisseur, etc.

La figure 6.22 regroupe ces éléments pour la description d’une interface deservice WSDL.

6.2.1.2 Le rôle d’UDDI

Les standards UDDI fournissent des annuaires centraux où les consommateursde services web peuvent accéder aux services qui les intéressent, soit à travers leparefeu d’une entreprise, via un extranet, ou par l’Internet publique. Les fournis-seurs de services peuvent alors inscrire des services web et les rendre disponiblesvia UDDI.

La spécification UDDI est celle qui a le plus évolué parmi toutes celles destechnologies pour le web. Sa dernière version remonte à juillet 2002.

Une entrée dans un registre UDDI est un document XML composé de plusieurséléments, dont les principaux sont :

– businessEntity : est la description de l’organisation (département, serveur,personnes, etc) fournissant le services ;

6.2. SYNTHÈSE DE L’APPROCHE DE CHORÉGRAPHIE 137

Figure 6.22 – Interface WSDL d’un service.

– businessService : est la liste de tous les services web fournis par la businessEntity ;– bindingTemplate : regroupe les aspects technique du service offert (URL ;

protocole, etc) ;– tModel (Technical Model) : est un élément générique pouvant être utilisé afin

de stocker des informations supplémentaires à propos du service. Cela peutêtre des informations techniques ou des informations sur comment utiliser leservice, les conditions d’utilisation, les garanties, etc.

Ensemble, ces éléments sont utilisés pour fournir :

1. des pages blanches : données à propos du fournisseur du service.

2. des pages jaunes : quels types de services et quels services sont offerts.

3. des pages vertes : informations techniques sur l’utilisation des services, ainsique des pointeurs sur les descriptions WSDL des services (qui ne résident pasdans le registre UDDI).

La figure 6.23 représente le modèle de données UDDI illustrant l’articulationdes éléments précédemment décrits.

Notons que la spécification UDDI offre un nombre d’APIs permettant d’effec-tuer plusieurs opérations au niveau d’un registre. Elle est notamment divisée en uneinterface de programmation pour la publication de services web dans un annuaireUDDI et une autre pour la recherche d’information, respectivement supportées pardeux grandes bibliothèques : API de requêtes et API de publication. Ce sont cellesque nous utilisons pour publier et découvrir nos services.


Figure 6.23 – Modèle de données UDDI.

6.2.1.3 Publication des services dans notre approche

Dans notre architecture, les services offerts par les agents se voient, chacun,générer une interface WSDL. C’est ce qui permet d’invoquer ou de communiqueravec le service en ligne sur le web.

La génération de l’interface WSDL prend en paramètre les actions dans le codesource VDL-XML de chaque service. À partir de ces actions, un fichier .jws estconstruit dans lequel sont regroupées les signatures en Java des actions. La plate-forme Axis [9], qui est un environnement pour déployer et invoquer des services web,génère à partir de ce fichier l’interface WSDL du service. La figure 6.24 représentecette partie de notre architecture pour la génération des services web (i.e. interfacesWSDL).

Pour ce qui est du modèle de données UDDI, tous les services s’exécutantsur notre plateforme sont déclarés dans la même interface businessEntity. Ladéclaration de chaque service est encapsulée dans un élément businessService.Quant à la localisation et les fonctionnalités du service, elles sont respectivementmémorisées dans les éléments bindingTemplate et tModel 1. La figure 6.25 montrel’appariement VDL-XML – WSDL et VDL-XML – UDDI dans notre approche.

Une fois que les interfaces WSDL et UDDI des services sont générées, les APIsde publication UDDI peuvent être utilisées pour publier les services sur le registre.Nous voyons ci-après quelles sont les fonctionnalités publiées pour un service. Dansla section 6.2.2, nous montrons comment ces fonctionnalités permettent de décou-vrir les services appropriés par rapport aux besoins exprimés par l’utilisateur.

1. Cette démarche est la même que celle adoptée, par exemple, dans les travaux sur la publi-cation de services web sémantiques OWL-S [116].


6.2.1.4 Quelles fonctionnalités sont publiées ?

Soit D la base de données d’un service et A et l’ensemble de ses actions :

1. Pour une donnée d ∈ D où d = ∧iequal(gi, d, valuei), sont publiées toutesles valeurs valuei correspondant à l’ensemble des attributs Γ. Cet ensembleΓ = type, reference, trademark, . . . contient des attributs dont les valeurssont considérées comme “représentatives”. Ces valeurs valuei∈ V sont publiéesdans un élément data-tModel.

Pour un ensemble de données dk ∈ D, et si ∩kVk 6= ∅, i.e. si les ensemblesrespectifs Vk des valeurs à publier pour les données dk contiennent des valeursen commun, celles-ci ne sont bien sûr publiées qu’une fois pour toute la basede données D.

ExempleSoit un service en ligne Location et vente de vidéos muni des données d1 et d2

telles que :d1 = equal(type, d1, video) ∧ equal(title, d1,The Prestige)∧

equal(res-price, d1, 3AC) ∧ equal(price, d1, 25AC) ;d2 = equal(type, d2, video) ∧ equal(title, d2,Memento)∧

equal(res-price, d1, 2AC) ∧ equal(price, d2, 19AC) ;L’interface UDDI de ce service incluera en conséquence dans data-tModel,l’élément video.

2. Pour une action a ∈ A où a = 〈name,P,E〉, dont la précondition P estun patron d’évènement E(f1, . . . , fn) sont publiés son nom name, le nom del’évènement qui la déclenche E, ainsi que les attributs fi de l’évènement E.Ces informations sont publiées dans un l’élément action-tModel.

ExempleSupposons que le service Location et vente de vidéos soit muni des actions a1

et a2 telles que :– L’action a1 consiste à réserver un film et est munie du patron d’évènement :ReserveMovie(client-id, title, reservation-date) ;

– et l’action a2 consiste à acheter un film et est munie du patron d’évène-ment : BuyMovie(title, iban).

L’interface UDDI de ce service comprendra deux éléments action-tModel,respectivement pour l’action a1 et a2. Le premier élément comprendra le nomréserver un film de l’action a1 ainsi que celui de son évènementReserveMovieet ses attributs en paramètre client-id, title et reservation-date, et le secondle nom acheter un film de l’action a2, celui de son évènement BuyMovie, etle nom des attributs en paramètres title, iban.

Les éléments data-tModel et action-tModel sont reliés à l’interface business-Service par l’attribut <categoryBag>. En effet, celui-ci permet communé-ment de mémoriser les informations permettant de découvrir un service.


Figure 6.24 – Génération d’interfaces WSDL dans notre architecture.

Figure 6.25 – Mapping WSDL ← VDL-XML → UDDI.


6.2.2 Découverte des services

La découverte de services est le procédé de recherche du fournisseur de servicele plus approprié pour une requête donnée en services. Cependant, comme la dé-couverte effective et automatique de services n’entre pas dans le cadre de notreétude, nous ne décrivons ici, tout comme pour la publication, qu’une approchesimple nous permettant de disposer d’un ensemble de services candidats, plus oumoins pertinents, pour la coordination ou la chorégraphie.

Notre approche de découverte de services consiste, en premier lieu, à extraire desmots-clé des requêtes de l’utilisateur, et de les exploiter ensuite pour la découvertedes services à partir d’un registre.

Soient les deux types de requêtes qui composent les besoins d’un utilisateur,i.e. les questions sur les données et les commandes :

1. Pour les questions sur les données : r=What-is(selections|c1, c2, . . .), sontextraites, de même que pour la publication, toutes les valeurs valueij dontles contraintes ci correspondantes aux attributs appartenant à l’ensemble Γ.Une condition sur ces valeurs est qu’elles ne doivent pas être des sélectionsindéfinies (i.e. de type g(request-get) où g est un symbole d’attribut).Pour un service dans un registre, on recherchera ces valeurs dans son élémentdata-tModel.

2. Pour les commandes r=Order(E(p1, p2, . . .)), sont extraits le nom de l’évène-ment E, ainsi que les attributs fij composant les paramètres pi.Pour un service publié dans un registre, ces paramètres sont alors recherchésdans son élément action-tModel.

Pour une requête What-is, un service publié dans un registre est considérécomme un service candidat, s’il comporte dans son data-tModel au moins unedes valeurs extraites de la requête de l’utilisateur. Si plusieurs services sont trou-vés, ce sont ceux qui comportent le plus de valeurs en commun avec la requête del’utilisateur qui sont choisis.

Pour une commande Order, un service est considéré comme un service candidats’il comporte dans son élément action-tModel au moins le même nom d’évènementE extrait de la requête de l’utilisateur. Si plusieurs services répondant à cettecontrainte sont trouvés, ce sont ceux qui ont déclaré le plus d’attributs en communavec ceux de la requête de l’utilisateur qui sont choisis.

ExempleSoit un utilisateur formulant une requête pour réserver des vidéos de Christian

Bale pour la date du 27/09/2007. Cette requête est formalisé dans notre modèlecomme suit :

r=Order(ReserveMovie(equal(main-actor, x,Christian Bale) ∧equal(res-date, x, 27/09/2007))).

De la requête de l’utilisateur, on extrait ainsi le nom de l’évènementReserveMovie,ainsi que les attributs type, main-actor et res-date. Ceux-ci seront appariés aux


déclarations contenues dans l’élément action-tModel des services publiés dans leregistre.

Soit le service Location et vente de vidéos de notre précédent exemple, ayantpublié le même nom d’évènement ReserveMovie avec les attributs type, res-dateet client-id dans son action-tModel. Puisque le nom de l’évènement est au moinsun de ses attributs (notamment type et res-date) sont appariés aux mots clésextraits de la commande de l’utilisateur, le service Location et vente de vidéos serapar conséquent découvert et proposé comme service candidat.

6.2.3 Invocation et chorégraphie de services

Après que chaque service a publié ses fonctionnalités dans le registre UDDI et,qu’à partir de la demande de l’utilisateur, des services candidats ont été découvertset localisés, la communication entre services est entreprise afin que les services secoordonnent pour la satisfaction des requêtes de l’utilisateur.

Les services sont invoqués moyennant leur interface WSDL. Les traitementsdes requêtes de l’utilisateur, ainsi que le traitement des messages, se situent auniveau des agents, où s’effectuent le raisonnement et la construction des messagesréponses. Ainsi, l’interaction des services est entièrement régie par le protocole decoordination que nous avons spécifié.

Toutefois, sur le web, ces messages sont encapsulés dans des messages SOAP etenvoyés afin d’invoquer les services via leur interface WSDL.

En effet, les messages SOAP 2 sont contenus dans des enveloppes et com-prennent une entête, décrite dans la balise <Header>, et un corps de message,décrit dans une balise <body>. C’est là que sont encapsulés les messages construitsdans notre protocole de coordination.

6.2.3.1 La communication entre services

Dans notre architecture, les actions des agents sont déclarées dans l’interfaceWSDL des services et sont donc directement invocables sur le web.

Afin également de pouvoir permettre l’interaction en ligne des agents (ou ser-vices) suivant notre protocole, une méthode sendMessage a été automatiquementrajoutée à chaque interface WSDL de service. Celle-ci permet d’invoquer la fonc-tionnalité d’envoi de messages, structuré selon notre ACL, à travers le web. Ainsi,chaque service peut recevoir un message, à la base formaté dans notre ACL, quiest encapsulé dans une enveloppe SOAP pour son émission sur le web.

6.2.3.2 Infrastructure

L’infrastructure permettant à la fois la publication, la découverte, le déploie-ment et la chorégraphie des services sur le web est supportée par les outils etlibrairies open source suivants :

2. La spécification SOAP en est à sa version 1.2. Depuis avril 2007, c’est également unerecommandationW3C. Cette spécification définit la structure des messages XML à travers lesquelsles messages SOAP sont décrits.

6.3. CONCLUSION 143

– Tomcat : qui est un serveur d’application pour l’utilisation de servelts, defichiers .jsp et .java.

– jUDDI : implémentation open source de l’annuaire UDDI. jUDDI gère letransport des données XML grâce à Axis (qui est considéré principalementcomme un moteur SOAP). Il tourne par ailleurs sur le serveur Tomcat.

– MySQL : représente la base de données supportant l’annuaire jUDDI.– UDDI4J : est une API Java permettant d’interagir avec l’annuaire jUDDI,

c’est-à-dire de s’y connecter, de publier et de rechercher des services.

6.3 Conclusion

Dans ce chapitre, nous avons exposé les résultats donnés à l’implémentation denotre protocole de coordination et avons synthétisé l’approche globale de chorégra-phie de services s’appuyant sur ce même protocole.

En effet, dans la première partie du chapitre, nous avons présenté le com-portement de notre protocole à travers deux scénarii illustrant différents aspectscomplémentaires de ce dernier.

Les résultats ont démontré la capacité de notre protocole à gérer un ensemblede requêtes complexes moyennant des capacités et des connaissances distribuéesde plusieurs agents, dont aucun n’était pourtant capable (au départ) de seul lesrésoudre. Ces scénarii ont donc montré que notre protocole permet de composer desfonctionnalités (services) pour la satisfaction de besoins complexes d’utilisateurs,et ce de manière entièrement décentralisée, distribuée et dynamique (ne reposantsur aucun plan mais plutôt sur les capacités d’introspection des agents à propos deleurs actions).

Par ailleurs, ces mêmes résultats ont montré que le flux des messages produitsétait inférieur à la complexité calculatoire théorique. Cependant, nous avons vuqu’il pouvait être encore largement réduit, ainsi que le temps d’exécution global dela coordination :

– en limitant le nombre d’agents figurants, i.e. n’ayant pas de capacité pouvantservir à la résolution des besoins de l’utilisateur. ;

– en calculant les agents destinataires non seulement en fonction des types derequêtes construites, mais aussi des capacités des agents disponibles.

Sur le web, ces solutions peuvent être intégrées respectivement grâce aux phasesde découverte et de publication des fonctionnalités des services dans un registre deservices. Par ailleurs, nous avons également constaté que certaines redondancespouvaient apparaître dans les requêtes émises lorsque, dans plusieurs requêtes re-çues, les agent détectent des attributs manquants communs. Une amélioration pos-sible du protocole consisterait donc à analyser le groupe de requêtes envoyées àun même agent afin d’éviter ces redondances. Ces expérimentations ont égalementmontré le potentiel de notre approche à modéliser (et résoudre) des cas d’étudesde services web et d’AmI.

Dans la seconde partie de ce chapitre, nous avons synthétisé l’approche globalede chorégraphie de services, en reliant nos précédentes spécifications au contexte


et aux technologies du web. Nous avons ainsi décrit les phases de publication, dedécouverte et d’invocation des services. Les deux premières permettent, à partirde la requête de l’utilisateur, de fournir un ensemble de services candidats à lachorégraphie. N’étant pas l’objet de notre étude, les approches que nous avons pré-sentées ne garantissent pas un nombre optimal de services pertinents trouvés, maistendent à proposer un ensemble de services susceptibles de répondre, directementou en se coordonnant, aux besoins que l’utilisateur a exprimés. Cette phase permetnotamment d’améliorer les performances de notre protocole en réduisant le fluxde message et le temps d’exécution. Comme nous l’avons précédemment évoqué,l’autre voie pouvant être explorée dans ce sens est l’exploitation des informationssur les capacités des services pour orienter certaines requêtes construites vers lesagents qui sont les plus à même d’y répondre.

Une fois les services candidats découverts, ils interagissent entre eux au moyendu protocole de coordination que nous avons spécifié. Les différentes opérations deraisonnements, de traitements ou de construction de messages se situent entière-ment au niveau des agents. L’interaction des services est donc entièrement régiepar notre protocole de coordination. Quant à leur communication, elle est géréepar des protocoles de transport pour le web.

Conclusion

Des environnements tels que le web et l’informatique diffuse sont des en-vironnements ouverts et distribués. Ils se caractérisent par des services très flexibleset dynamiques (où de nouvelles propriétés peuvent apparaître pour un service etde nouveaux services peuvent être disponibles sur une base quotidienne) et où lesbesoins des utilisateurs en services varient. Dans un tel contexte, le processus decomposition de services pour la satisfaction des besoins de l’utilisateur doit pou-voir s’adapter de manière dynamique aux besoins de ce dernier avec un minimumd’intervention de sa part.

C’est dans le cadre de cette problématique que notre travail de recherche s’esteffectué. Après avoir présenté cette problématique et les verrous sous-tendus, cemanuscrit a décrit notre proposition. Celle-ci a consisté en l’étude et la conceptiond’une approche dynamique de chorégraphie de services web basée sur des méca-nismes de coordination multiagent.

Nous avons identifié les limites récurrentes des travaux existants de compositionde services ainsi que les limites intrinsèques aux services web pour la conceptiond’une telle approche. C’est ensuite en étudiant les propriétés et modèles proposésdans la communauté agent et multiagent que nous avons constaté que les systèmesmultiagents était un bon candidat pour la modélisation des problématiques (dedistribution, de flexibilité et de collaboration) impliquées par une approche dyna-mique de chorégraphie de services. Plus précisément, les modèles de coordinationmultiagent semblaient particulièrement bien adaptés pour modéliser les collabora-tions dynamiques entre services.

D’autre part, nous avons pu conclure que la solution consisterait en un modèlede coordination orienté tâche, car comme le requiert la solution à la probléma-tique de la chorégraphie dynamique, ce modèle est applicable dans un contextede résolution distribuée de problèmes où un but global à satisfaire est présupposé(correspondant à un ensemble de besoins énoncés par l’utilisateur à satisfaire dansle problème de la chorégraphie de services). Cependant, nous avons pu constaterqu’aucun des modèles de coordination existants ne satisfaisait pleinement la mo-délisation de la problématique de chorégraphie dynamique de services. En effet,pour qu’une entité (agent ou service) parvienne à combiner ses fonctionnalités etcoordonner ses compétences avec d’autres sur la base d’un ensemble de besoinsà satisfaire, elle doit comporter d’importantes propriétés, notamment de raison-

145

146 CONCLUSION ET PERSPECTIVES

nement, d’interaction flexible et de décomposition dynamique de tâche, qui fontdéfaut aux modèles d’agents et de coordination multiagent actuellement existants.

Contributions

La principale contribution de cette thèse consiste en la proposition à la foisd’une approche globale de chorégraphie dynamique de services et d’un modèle decoordination dynamique multiagent. Aboutir à une telle proposition a requis laprovision des contributions subalternes et résultats suivants :

– Une architecture générale combinant technologie services web et système mul-tiagent ;

– Un modèle d’agent introspectif, capable d’analyser et de raisonner sur sespropres actions afin d’évaluer s’il est capable de prendre en charge intégrale-ment ou partiellement la résolution d’une tâche ;

– Une modèle de représentation des besoins de l’utilisateur en un ensemble derequêtes et de contraintes globales, et un modèle de requêtes pour appuyersa formalisation ;

– Un modèle de communication entre agents leur permettant à la fois deprendre directement en charge des besoins complexes de l’utilisateur maisaussi de communiquer à propos de leurs connaissances et leurs compétences ;

– Un protocole dynamique d’interaction multiagent, décentralisé et distribué,permettant la décomposition dynamique des tâches à accomplir par les agents,des interactions flexibles entre ces derniers, et surtout une coordination deleurs compétences sur la base d’un ensemble de besoins à satisfaire et sansconnaissance préalable sur les capacités de leurs accointants.

– Un algorithme proposant à l’utilisateur une sélection de services répondantà ses contraintes, à partir d’un ensemble de réponses à des requêtes et d’unensemble d’agents fournisseurs.

De manière générale, cette thèse constitue alors une contribution dans la réso-lution distribuée de problèmes et, en vue de ses domaines d’application, dans lacomposition de services sur le web et dans l’intelligence ambiante.

Travaux futurs

La conception de l’approche de chorégraphie de services, ainsi que les expéri-mentations préliminaires du modèle de coordination proposé dans cette thèse, ontdonné lieu à des propositions et à des réflexions aussi bien sur des aspects tech-niques du protocole d’interaction que sur des aspects plus généraux sur l’approchede chorégraphie et à des perspectives de recherche à long terme :

Perspectives à court terme

– Le flux de message produit par la coordination des agents peut être réduitpar l’exploitation de connaissances à propos des compétences des agents par-ticipants. Similairement aux registres publiques de services sur le web, un

147

registre privé où ne sont mémorisés que les compétences des agents parti-cipants, consulté chaque fois qu’un agent nécessite des collaborations, peutconstituer une solution préliminaire.Il faut alors évaluer le gain en complexité de communication par rapport àla consommation calculatoire supplémentaire à la consultation systématiqueet la mise en place de ce type de registre.

– En fonction du domaine d’application de la chorégraphie de services, le rôle del’agent de l’utilisateur est un rôle utile de médiateur entre l’utilisateur et lesagents participants, par exemple sur le web, mais peut en revanche constituerune entité sur laquelle l’approche de chorégraphie est centralisée, par exempledans des environnements d’intelligence ambiante et d’informatique diffuse.Il faut donc envisager une déclinaison du protocole d’interaction, pour ce typede configurations, dans laquelle le rôle de l’agent de l’utilisateur est suppriméet les règles dialectiques, au niveau des agents participants, sont adaptéesde sorte à ce que les agents se coordonnent pour la livraison du résultat àl’utilisateur.

– Dans notre modèle, la décomposition d’une tâche par un agent fait appelà l’analyse de ses compétences, et plus précisément des préconditions de sesactions. Si des paramètres attendus en entrée de son action n’ont pas été four-nis à travers la commande reçue, l’agent fait appel à ses accointants en leurenvoyant des questions pour tenter de retrouver les valeurs des paramètresrequis.Cette décomposition se traduit ainsi par l’envoi de requêtes sur des données.Cependant, si les valeurs des paramètres recherchés ne sont pas dans la basede données de l’agent, elles devraient pouvoir être calculées par ses actions.Il faut alors envisager la modélisation de commandes, dont le nom de l’évè-nement ou de l’action n’est pas connu a priori mais peut être remplacé parl’ensemble de ses entrées et de ses sorties (les sorties étant les paramètresrecherchés par l’agent ayant décomposé sa commande).

Perspectives à moyen terme

– Les cas d’utilisation pour la chorégraphie de services nécessitent d’examinernon seulement les propriétés statiques des services (ex. prix=100AC, date-liv-raison=15/10/07 , etc) mais aussi des propriétés dynamiques qui n’ont pasété traitées dans le cadre de cette thèse (ex. “si les 100AC ne sont pas payés àla fin de la semaine, la disponibilité du service n’est plus assurée”). Dans cecontexte, il faut assurer que les services candidats aient les comportementset les propriétés souhaités. De plus, à l’issue de la sélection des services àfournir à l’utilisateur, il faut vérifier que les propriétés de ceux-ci ne sont pasincompatibles.Une solution possible consiste alors à étudier la mise en place de contrats(accords ou engagements) [76] pour permettre une compréhension mutuelleet l’obtention de services dotés de propriétés dynamiques compatibles.


– Comme nous l’avons annoncé, l’expressivité des contraintes dans notre mo-dèle est limitée. Par exemple, elle ne permet pas d’exprimer des contraintes“continues” du type : “l’appareil photo le moins cher avec la plus haute réso-lution”.Si la formalisation de ce type de contraintes n’est pas un problème, leursatisfaction demande en revanche d’interpréter des propriétés discrêtes deservices et d’inférer la tranche de leur valeur en fonction de la compositiondes unes aux autres.

– Il devrait être possible pour l’utilisateur d’exprimer plusieurs contraintes surles services qu’il requiert, par exemple “Je souhaite réserver une chambred’hôtel pour moins de 90AC et si possible dans l’hôtel le plus étoilé”. Il ar-rive alors que ces contraintes concernent le même service demandé, et queplusieurs services candidats répondent à toutes ou partie des contraintes for-mulées.Il faut alors envisager de mettre en place un profil de l’utilisateur ainsi quel’application d’algorithmes d’apprentissage dans le but de mémoriser ses pré-férences. Ainsi, lorsqu’une situation ou plusieurs services candidats répondentplus ou moins à un ensemble de contraintes de l’utilisateur, son profil pourraitpermettre de faire une sélection en adéquation avec ses préférences.

Perspectives à long terme

– Les approches actuelles pour la composition de services traitent toutes d’unecomposition à la demande où les besoins sont explicitement formulés parl’utilisateur ou par un expert. Des recherches pourraient être conduites dansla conception d’approches de composition anticipée de services. Les besoinsà satisfaire dans ce type d’approches ne seraient pas explicitement exprimésmais inférés de l’environnement et des actions de l’utilisateur.Le contexte et les actions de l’utilisateur peuvent par exemple être un simplechangement d’horaire d’un billet d’avion, la fin des provisions en nourri-ture, un piéton qui traverse une rue, un accident sur la voie publique, etc.Il faut alors concevoir des services capables de percevoir l’environnement etle contexte de l’utilisateur, détecter et répercuter les changements qui y ontopéré (l’utilisateur devant prendre un train après son vol se voit changerl’horaire de son billet de train), découvrir dynamiquement et collaborer avecles services en rapport avec le contexte de l’utilisateur (cybercourses auto-matiques, émission de signaux de prévention sur les GPS des véhicules auxalentours du piéton, appel aux services d’urgences les plus proches et la fa-mille de l’accidenté) pour prévenir ou couvrir des situations d’exception. Ilfaut également déterminer les configurations où les services demandent l’avalde l’utilisateur avant de procéder à toute composition anticipée, et munir lesservices de capacités d’explication de leurs actions et décisions.

– Les approches existantes pour la composition dans l’informatique diffuse sonttoutes centrées sur un utilisateur se mouvant dans un environnement dyna-mique quoique fermé et homogène. En plus des adaptations apportées à notre

149

approche pour un tel domaine d’application (ex. repenser le protocole d’in-teraction sans le rôle de l’agent de l’utilisateur) la chorégraphie de servicedevrait alors être étudiée dans un contexte d’environnements dynamiqueset hétérogènes, impliquant plusieurs problématiques quant à la disponibilitédes services, leurs conditions d’exécution en fonction de chaque environne-ment, et la gestion de conflits lorsque plusieurs utilisateurs cohabitent dansun même environnement.Il faut alors étudier l’adaptation automatique de la gestion des services dé-livrés à l’utilisateur en fonction du contexte de chaque environnement quecelui-ci visite et en tenant compte des changements d’environnement.


Bibliographie

[1] UDDI Specifications Technical Committee Draft. http://uddi.org/pubs/uddi\_v3.htm, 2004.

[2] S. Aknine. Modèles et méthodes de coordination dans les systèmes multi-agents. PhD thesis, Thèse Doctorat. Université Paris IX Dauphine, 2000.

[3] S. Aknine. Contribution à l’étude des méthodes de coordination dans lessystèmes multi-agents, 2006.

[4] R. Alami, F. Robert, F Ingrand, and S. Suzuki. Multi-Robot Cooperationthrough Incremental Plan-Merging. In Proc. of the international Confe-rence on Robotics and Automation, pages 2573–2579. IEEE Computer SocietyPress, 1995.

[5] G. Alonso, F. Casati, H. Kuno, and V. Machiraju. Web Services - Concepts,Architectures and Applications. Springer-Verlag, 2004.

[6] S. Ambroszkiewicz. Agent-based Approach to Service Description and Com-position. In Proc. 1st International Workshop on Radical Agent Concepts(WRAC), pages 135–149, 2003.

[7] M. Amor, L. Fuentes, and J.M. Troya. Putting Together Web Services andCompositional Software Agents. In Proc. of the International Conference onWeb Engineering (ICWE’03), pages 44–53, 2003.

[8] D. Austin, A. Barbir, E. Peters, and S. Ross-Talbot. Web Services Choreo-graphy Requirements W3C Working Draft. Technical report, World WideWeb Consortium (W3C), 2004.

[9] Axis. Apache Axis. http://ws.apache.org/axis/.[10] A. Barros, M. Dumas, and P. Oaks. A Critical Overview of the Web Services

Choreography Description Language (WS-CDL). In Proc. of the BusinessProcess Trends (BPTrends), 2005.

[11] B. Bauer and J. Odell. UML 2.0 and Agents : How to Build Agent-basedSystems with the New UML Standard. Engineering Applications of ArtificialIntelligence, 18(2) :141–157, March 2005.

[12] H. Baumeister. Customer Relationship Management for SME, 2002.[13] B. Benatallah, M. Dumas, M.C. Fauvet, F.A. Rabhi, and Q.Z. Cheng. To-

wards Patterns of Web Services Composition.[14] B. Benatallah, Q.Z. Sheng, and M. Dumas. The Self-Serve Environment for

Web Services Composition. IEEE Internet Computing, 7(1) :40–48, 2003.

151

152 BIBLIOGRAPHIE

[15] J. Bentahar, Z. Maamar, D. Benslimane, and P. Thiran. Using Argumenta-tive Agents to Manage Communities of Web Services. In Proc. of the 21stInternational Conference on Advanced Information Networking and Applica-tions Workshops (AINAW’07), pages 588–593, Washington, DC, USA, 2007.IEEE Computer Society.

[16] A. Berger and S. Pesty. Towards a Conversational Language for ArtificialAgents in Mixed Community. In Proc. of the 3rd International Central andEastern European Conference on Multi-Agent Systems (CEEMAS’05), pages31–40, 2005.

[17] T. Berners-Lee. Weaving the Web. Harper San Francisco, 1999.[18] B. Blankenburg, M. Klusch, and O. Shehory. Fuzzy Kernel-Stable Coalitions

between Rational Agents. In Proc. of the 2nd International Joint Conferenceon Autonomous Agents and Multiagent Systems (AAMAS’03), pages 9–16,New York, NY, USA, 2003. ACM Press.

[19] T. Bolognesi and E. Brinksma. Introduction to the ISO Specification Lan-guage LOTOS. Computer Networks, 14 :25–59, 1987.

[20] A.H. Bond and L. Gasser. Readings in Distributed Artificial Intelligence.Morgan Kaufmann, 1988.

[21] D. Booth, M. Champion, C. Ferris, F. McCabe, E. Newcomer, andD. Orchard. Web Services Architecture. http://www.w3.org/TR/2003/WD-ws-arch-20030514/, May 2003.

[22] D. Booth, H. Haas, F. McCabe, E. Newcomer, M. Champion, C. Ferris, andD. Orchard. Web Services Architecture. Technical report, W3C WorkingGroup Note 11, 2004.

[23] F. Brouard. SQL. 2001.[24] L. Cabac. Modeling Agent Interaction Protocols with AUML Diagrams and

Petri Nets. Diplomarbeit, University of Hamburg, Department of ComputerScience, Vogt-Kölln Str. 30, 22527 Hamburg, Germany, 2003.

[25] P. Caillou, S. Aknine, and S. Pinson. Méthode de formation et de restructu-ration dynamique de coalitions d’agents fondée sur l’optimum de Pareto. InProc. 9èmes Journées Francophones d’Intelligence Artificielles et SystèmesMulti-Agents (JFIAD), 2001.

[26] J. Cao, M. Li, S.S. Zhang, and Q. Deng. Composing Web Services based onAgent and Workflow. In Proc. of the 2nd International Workshop on Gridand Cooperative Computing (GCC), volume 3032, pages 948–955, 2004.

[27] F. Casati and S. Ming-Chien. Dynamic and Adaptive Composition of e-Services. Elsevier Science Ltd, 2001.

[28] Y. Charif and N. Sabouret. A Model of Interactions about Actions for Activeand Semantic Web Services. In Proc. Semantic Web Service workshop at 3rdInternational Semantic Web Conference (ISWC’04), pages 31–46, 2004.

[29] Y. Charif and N. Sabouret. An Overview of Semantic Web Services Com-position Approaches. In Proc. International Workshop on Context for WebServices (CWS’05), 2005.

BIBLIOGRAPHIE 153

[30] Y. Charif and N. Sabouret. An Agent Interaction Protocol for AmbientIntelligence. In Proc. of the 2nd International Conference on Intelligent En-vironments (IE’06), pages 275–284, 2006.

[31] Y. Charif and N. Sabouret. Coordination d’agents introspectifs. In Proc.15èmes Journées Francophones sur les Systèmes Multi-Agents (JFSMA’07),pages 201–210, 2007.

[32] L. Chen, N.R. Shadbolt, C. Goble, F. Tao, S.J. Cox, C. Puleston, andP. Smart. Towards a Knowledge-based Approach to Semantic Service Com-position. In Proc. 2nd International Semantic Web Conference, 2003.

[33] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. Web ServicesDescription Language (WSDL). http://www.w3.org/TR/wsdl, 2001.

[34] U. Dal Lago, M. Pistore, and T. Traverso. Planning with a Language forExtended Goals. In Proc. of the 18th International Conference on ArtificialIntelligence (AAAI’02), 2002.

[35] David Martin et al. OWL-S : Semantic Markup for Web Services. Technicalreport, DAML Organization, 2004.

[36] R. Dijkman and M. Dumas. Service-oriented Design : A Multi-viewpointApproach. 13(4) :338–378, 2004.

[37] J. Domingue and S. Galizia. Towards a Choreography for IRS-III. In Proc.of the Workshop on WSMO Implementations (WIW 2004), 2004.

[38] E.H. Durfee. Distributed Problem Solving and Planning. pages 118–149,2001.

[39] E.H. Durfee and V. Lesser. Using Partial Global Plans to Coordinate Distri-buted Problem Solvers. In Proc. the 10th International Joint Conference onArtificial Intelligence.

[40] S. Dustdar and W. Schreiner. A Survey on Web services Composition. In-ternational Journal of Web and Grid Services, 1, 2005.

[41] A. El Fallah-Seghrouchni and S. Haddad. A Coordination Algorithm forMulti-Agent Planning. j-LECT-NOTES-COMP-SCI, 1038.

[42] E.A. Emerson. Temporal and Modal Logic. Elsevier.

[43] A. Andrieux et al. Web Services Agreement Specification (WS-Agreement).Technical report, Globus Alliance, 2004.

[44] M. Dean et al. Web Ontology Language (OWL) Reference Version 1.0, 2002.

[45] V. Ermolayev, N. Keberle, and S. Plaksin. Towards Agent-Based RationalService Composition – RACING Approach. In M. Jeckle and L-J. Zang, edi-tors, Proc. of the International Conference on Web Services Europe, volumeLNCS 2853, pages 167–182, Erfurt, Germany, September 2003. Springer-Verlag.

[46] A. El Fallah-Seghrouchni. Modèles de coordination d’agents cognitifs. InJ.P. Briot et Y. Demazeau, editor, Principes et architecture des systèmesmulti-agents. Hermès, Lavoisier, 2001.

154 BIBLIOGRAPHIE

[47] J. Ferber. Les systèmes multi-agents : Vers une intelligence collective. Inter-Editions, 1995.

[48] T. Finin, R. Fritzson, and D. McKay. An overview of KQML : A KnowledgeQuery and Manipulation Language. Technical report, University of MarylandBaltimore Country, 1992.

[49] FIPA Contract Net Interaction Protocol Specification. http://www.fipa.org/specs/fipa00029/index.html, 2002.

[50] FIPA English Auction Interaction Protocol Specification. http://www.fipa.org/specs/fipa00031/index.html, 2001.

[51] FIPA Interaction Protocol Library Specification. http://www.fipa.org/specs/fipa00025/XC00025E.pdf, 2001.

[52] FIPA Request Interaction Protocol Specification. http://www.fipa.org/specs/fipa00026/SC00026H.html, 2002.

[53] Gartner. Hype Cycle for Web Services. http://www.gartner.com/, 2007.[54] L.G. Gasser. The Social Dynamics of Routine Computer Use in Complex

Organizations (Work, Management, Sociology). PhD thesis, 1984.[55] M. P. Georgeff. Planning. In J. Allen, J. Hendler, and A. Tate, editors,

Readings in Planning. Kaufmann, San Mateo, CA, 1990.[56] M. Greaves, H. Holmback, and J. Bradshaw. What is Conversation Policy ? In

Frank Dignum and Mark Greaves, editors, Issues in Agent Communication,pages 118–131. Springer-Verlag : Heidelberg, Germany, 2000.

[57] N. Guarino. Semantic Matching : Formal Ontological Distinctions for Infor-mation Organisation, Extraction, and Integration. A multidisciplinary ap-proach to an emerging information technology. International summer school,pages 139–170, 1997.

[58] Z. Guessoum and J-P. Briot. From Active Objects to Autonomous Agents.IEEE Concurrency, 7(3) :68–76, 1999.

[59] A. Gustavo, F. Casati, H. Kuno, and V. Machiraju. Web Services. Concepts,Architectures and Applications. Springer-Verlag Berlin Heidelberg, 2004.

[60] H. Guyennet, D. Saint-Voirin, and I. Rasovska. State of the Art in MultipleData Format Handling. Technical report, ITEA Proteus, 2003.

[61] A. Gárate, N. Herrasti, and A. López. GENIO : an Ambient IntelligenceApplication in Home Automation and Entertainment environment. In Proc.Joint Conference on Smart Objects and Ambient Intelligence, pages 241–256,2005.

[62] M.N. Huhns. Agents as Web Services. IEEE Internet Computing, 6(4) :93–95,2002.

[63] M.N. Huhns. Software Agents : The Future of Web Services. In AgentTechnologies, Infrastructures, Tools, and Applications for E-Services, pages1–18, 2002.

[64] M.N. Huhns and M.P. Singh, editors. Readings in Agents. MOrgan Kauf-mann, San Francisco, CA, USA, 1998.

BIBLIOGRAPHIE 155

[65] M.N. Huhns and L.M. Stephens. Multiagent Systems and Societies of Agents.pages 79–120, 1999.

[66] IBM Alphaworks. BPWS4J. http://www.alphaWorks.ibm.com/tech/bpws4j, 2002.

[67] IBM, Microsoft, SAP, Siebel Systems. Business Process Execution Languagefor Web Services Version 1.1. Technical report, 2003.

[68] ISO. Information Processing Systems - Open Systems Interconnection. LO-TOS - A Formal Description Technique based on the Temporal Ordering ofObservational Behaviour, 1989.

[69] JACK. JACK Intelligent Agents Tutorials, Agent Oriented SoftwarePty. http://www.disi.unige.it/person/ZiniF/Didattica/Jack/jack_tutorial.pdf.

[70] JADE. Java Agent DEvelopement Framework. http://jade.tilab.com.[71] N. Jennings, K. Sycara, and M. Wooldridge. A Roadmap of Agent Research

and Development. In Proc. AAMAS’98, 1998.[72] N.R. Jennings. An Agent-based Approach for Building Complex Software

Systems. Communication of the ACM, 44(4) :35–41, 2001.[73] C. Jonquet. Dynamic Service Generation : Agent interactions for Service

Exchange on the Grid. PhD thesis, Université Montpellier 2, Montpellier,France.

[74] N. Kavantzas, D. Burdett, G. Ritzinger, T. Fletcher, and Y. Lafon. WebServices Description Language (WS-CDL). Technical report, W3C, 2004.

[75] M. Klush, A. Gerber, and M. Schmidt. Semantic Web Service CompositionPlanning with OWLS-Xplan. In Proc. of the 1st International AAAI FallSymposium on Agents and the Semantic Web. AAAI Press, 2005.

[76] J. Knottenbelt and K. Clark. Contract-related Agents. In Proc. 6th Inter-national Workshop of the Conference Computational Logic in Multi-AgentSystems (CLIMA VI), pages 226–242, 2005.

[77] J-L. Koning. Operational Semantics Rules as a Computational CoordinationMechanism in Multi-Agent Systems. International Journal on IntelligentControl and Systems, 2(12) :167–178, 2007.

[78] J-L. Koning and S. Pesty. Modèles de communication. In J-P. Briot et Y. De-mazeau, editor, Principes et architecture des systèmes multi-agents. Hermès,Lavoisier, 2001.

[79] S. Kraus, M. Nirkhe, and K. Sycara. Reaching Agreements through Argu-mentation : A Logical Model (preliminary report). In Proc. of the 12th In-ternational Workshop on Distributed Artificial Intelligence), pages 233–247,Hidden Valley, Pennsylvania, 1993.

[80] T.A. Lashina. Intelligent Bathroom. In European Symposium on AmbientIntelligence (EUSAI 2004), 2004.

[81] H. Lauren, D. Roman, and U. Keller. Web Services Modeling Ontology- Standard (WSMO-Standard). http://wsmo.org/2004/d2/v0.2/, March2004.

156 BIBLIOGRAPHIE

[82] Z. Maamar, D. Benslimane, and Q.Z. Sheng. Towards A Two-Layered Fra-mework for Managing Web Services Interaction. In ACIS-ICIS, pages 87–92,2007.

[83] M. MacKenzie, K. Laskey, F. McCabe, P. Brown, and R. Metz. ReferenceModel for Service-Oriented Architecture 1.0. Technical Report wd-soa-rm-cdl, OASIS.

[84] T.W. Malone and K. Crowston. The interdisciplinary study of coordination.ACM Comput. Surv., 26(1) :87–119, 1994.

[85] F. Von Martial. Interactions among Autonomous Planning Agents. In Y. De-mazeau and J.P. Müller, editors, Proc. of the 1st European Workshop onModelling Autonomous Agents in Multi-Agent World, Cambridge, England.

[86] D. Martin, M. Paolucci, S. McIlraith, M. Burstein, D. McDermott, D. Mc-Guinness, B. Parsia, T. Payne, M. Sabou, M. Solanki, N. Srinivasan, andK. Sycara. Bringing Semantics to Web Services : The OWL-S Approach,2004.

[87] M. Matskin, P. Küngas, J. Rao, J. Sampson, and S. Abbas Petersen. EnablingWeb Services Composition with Softward Agents. In IMSA, pages 93–98,2005.

[88] P. McBurney, S. Parsons, and M. Wooldridge. Desiderata for Agent Argu-mentation Protocols. 2002.

[89] J. McCarthy and P.J. Hayes. Some philosophical problems from the stand-point of Artificial Intelligence. Machine Intelligence, 4 :463–502, 1969.

[90] T. Melliti and S. Haddad. Synthesis of Agents for Web Services Interaction.In Proc. of Workshop on Semantic Web Services for Enterprise ApplicationIntegration and E-Commerce of the 5th International Conference on Electro-nic Commerce, Pittsburgh, USA, 2003.

[91] J. Meseguer. Conditional rewriting logic as a unified model of concurrency.Theoretical Computer Science, 96(1) :73–155, 1992.

[92] J. Meseguer. Rewriting Logic and Maude : Concepts and Applications. InProc. RTA 2000, pages 1–26, 2000.

[93] R. Mizoguchi, J. Vanwelkenhuysen, and M. Ikeda. Task ontology for reuse ofproblem solving knowledge. In Proc. 2nd international conference on buildingand sharing of very large-scale knowledge bases, 1995.

[94] J. Moon, D. Lee, C. Park, and H. Cho. ebXML BP Modeling Toolkit. InProc. of the 7th International Conference on Enterprise Distributed ObjectComputing (EDOC), page 296. IEEE Computer Society, 2003.

[95] I. Müller, R. Kowalczyk, and P. Braun. Towards Agent-based Coalition For-mation for Service Composition. In Proc. of the International Conference onIntelligent Agent Technology (IAT’06), pages 73–80, 2006.

[96] E. Oliveira, K. Fisher, and O. Stepankova. Multi-Agent Systems : WhichResearch for which Applications. Robotics and Autonomous Systems, 27 :91–106, 1999.

BIBLIOGRAPHIE 157

[97] T. Osman, D. Thakker, and D. Al-Dabass. Bridging the Gap between Work-flow and Semantic-based Web services Composition. In Proc. of the WebService Composition Workshop WSCOMPS05, 2005.

[98] P-Y. Oudeyer and J-L. Koning. Formalization, Implementation and Valida-tion of Conversation Policies using a Protocol Operational Semantics. Cog-nitive Systems Research, 4(3) :223–242, 2003.

[99] M.P. Papazoglou and D Georgakopoulos. Service Oriented-Computing. Com-munications of the ACM, 46(10) :25–28, 2003.

[100] C. Parent and S. Spaccapietra. Issues and Approaches of Database Integra-tion. Communications of the ACM, 41(5) :166–178, 1998.

[101] S. Paurobally, V. Tamma, and M. Wooldridge. Cooperation and Agreementbetween Semantic Web Services. In W3C Workshop on Frameworks for Se-mantics in Web Services. Innsbruck, Austria, June 2005.

[102] C. Peltz. Web Services Orchestration and Choreography. Computer,26(10) :46–52, 2003.

[103] J. Pitt and A. Mamdani. Some Remarks on the Semantics of FIPA’s AgentCommunication Language. Autonomous Agents and Multi-Agent Systems,2(4) :333–356, 1999.

[104] S.R. Ponnekanti and A. Fox. SWORD : A Developer Toolkit for Web ServicesComposition. 2002.

[105] A.D. Preece, K. Hui, W.A. Gray, P. Marti, T.J.M. Bench-Capon, D.M. Jones,and Z. Cui. The KRAFT Architecture for Knowledge Fusion and Transfor-mation. Knowledge Based Systems, 13(2-3) :113–120, 2000.

[106] C. Preist, A. Byde, C. Bartolini, and G. Piccinelli. Towards Agent-basedService Composition through Negotiation in Multiple Auctions. TechnicalReport hpl-2001-71, Hewlett Packard, 2001.

[107] J. Rao and X. Su. A survey of AutomatedWeb Service Composition Methods.In Proc. of 1st International Workshop on Semantic Web Services and WebProcess Composition, 2004.

[108] A. Rubinstein. Perfect Equilibrium in a Bargaining Model. Econometrica,50(1) :97–109, 1982.

[109] N. Sabouret. Étude de modèles de représentation, de requêtes et de raisonne-ment sur le fonctionnement des composants actifs pour l’interaction homme-machine. PhD thesis, Université Paris-Sud, 2002.

[110] N. Sabouret and J.P. Sansonnet. Traitement de requêtes de bon sens surles actions pour l’interaction homme-machine. In Proc. Modèles Formels del’Interaction (MFI) 2003, pages 209–218, 2003.

[111] J.R. Searle. Speech Acts. Cambridge University Press, 1969.[112] O. Shehory and S. Kraus. Methods for Task Allocation via Agent Coalition

Formation. Artificial Intelligence, 101(1–2) :165–200, 1998.[113] O. Shehory and S. Kraus. Feasible Formation of Coalitions among Autono-

mous Agents in Nonsuperadditve Environments. Computational Intelligence,15 :218–251, 1999.

158 BIBLIOGRAPHIE

[114] M.P. Singh and M.N. Huhns. Service-Oriented Computing, semantics, pro-cesses, agents. John Wiley and Sons, 2005.

[115] R.G. Smith. The Contract Net Protocol : High-Level Communication andControl in a Distributed Problem Solver. IEEE Transactions on Computers,C-29(12) :1104–1113, 1981.

[116] N. Srinivasan, M. Paolucci, and K. Sycara. Adding OWL-S to UDDI, Imple-mentation and Throughput. In Proc. of the 1st International Workshop onSemantic Web Services and Web Process Composition (SWSWPC’04), SanDiego, California, 2004.

[117] H. Sun, W. Xiaodong, Z. Bin, and Z. Peng. Research and Implementation ofDynamic Web Services Composition. In Proc. of APPT’03, pages 457–466.Springer-Verlag Berlin Heidelberg, 2003.

[118] K. Sycara, M. Paolucci, J. Soudry, and N. Srinivasan. Dynamic Discoveryand Coordination of Agent-based Semantic Web Services. IEEE InternetComputing, 8(3) :66–73, 2004.

[119] The FIPA ACL Message Structure Specifications. http://www.fipa.org/specs/fipa00061/, 2002.

[120] P. Traverso and M. Pistore. Automated Composition of Semantic Web Ser-vices into Executable Processes. In Proc. of the 3rd International SemanticWeb Conference, Hiroshima, Japan (ISWC’04), pages 380–394, 2004.

[121] M. Vallée, F. Ramparany, and L. Vercouter. Composition flexible de servicesd’objets communicants. In Proc. Ubimob’05, volume 120, pages 85–192, 2005.

[122] D. Vanderveken. On the Unification of Speech Act Theory and Formal Se-mantics. In P.R. Cohen, J. Morgan, and M.E. Pollack, editors, Intentions inCommunication, pages 195–220. MIT Press, Cambridge, MA, 1990.

[123] G. Vauvert and A. El Fallah-Seghrouchni. Formal Specification of OpinionsApplied to the Consensus Problem. In Proc. of the 8th Iberoamerican Confe-rence on Artificial Intelligence. (IBERAMIA’02), 2002.

[124] W3C. RDF : Ressource Description Framework. http://www.w3.org/RDF/,1999.

[125] W3C. Simple object access protocol (soap). http://www.w3.org/TR/SOAP,2000.

[126] M. Weiser. The Computer for the 21st Century. Scientific American,253(3) :94–104, 1991.

[127] M. Wooldridge. Semantic Issues in the Verification of Agent CommunicationLanguages. Autonomous Agents and Multi-Agent Systems, 3(1) :9–31, 2000.

[128] M. Wooldridge. An Introduction to Multi-Agent Systems. 2002.[129] M. Wooldrige and N.R. Jennings. Intelligent Agents : Theory and Practice.

The Knowledge Engineering Review, 10(2) :115–152, 1995.[130] D. Wu, B. Parsia, E. Sirin, J. Hendler, and D. Nau. Automating DAML’S

Web Services Composition using SHOP2. In Proc. of the International Se-mantic Web Conference (ISWC’03), 2003.

BIBLIOGRAPHIE 159

[131] G. Zlotkin and J.S. Rosenschein. Negotiation and Conflict Resolution inNon-Cooperative Domains. In Proc. of the AAAI’90, pages 100–105, Boston,MA, 1990.

160 BIBLIOGRAPHIE

Publications

1. Y. Charif, N. Sabouret. A Model of Interactions about Actions for Active andSemantic Web Services. Proc. of the Semantic Web Service Workshop at the3rd International Semantic Web Conference (SWS@ISWC’04), pages 31-46.In CEUR online proceedings, vol. 119. Hiroshima, Japan. 2004.

2. Y. Charif, N. Sabouret. Modèles de composants logiciels réflexifs et dialo-giques, Proc. 12es Journées de Rencontres interdisciplinaires sur les sys-tèmes complexes naturels et artificiels (Rochebrune’05), pages 53-64. Megève,France. 2005.

3. Y. Charif, N. Sabouret. Programmer des agents assistants interopérables dansle web sémantique. Proc. des 3es Journées francophones des Modèles Formelsde l’Interaction (MFI’05), pages 217-222. Caen, France. 2005.

4. Y. Charif, N. Sabouret. An Overview of Semantic Web Services CompositionApproaches. Proc. of the Context for Web Services Workshop at the 5th In-ternational and Interdisciplinary Conference on Modeling and Using Context(CWS@Context’05), ENTCS, Volume 146, Issue 1, pages 33-41. Paris, France.2005.

5. Y. Charif, N. Sabouret. An Agent Interaction Protocol for Ambient Intelli-gence. Proc. of the 2nd International Conference on Intelligent Environments(IE’06), pages 275-284. Athens, Greece. 2006.

6. Y. Charif, N. Sabouret. Protocole d’interaction pour la composition de ser-vices dans l’intelligence ambiante. Proc. des 14es Journées Francophones surles Systèmes Multi-Agents (JFSMA’06), pages 253-266. Annecy, France. 2006.

7. Y. Charif, N. Sabouret. Dynamic Web Service Selection and Composition : AnApproach based on Agent Dialogues. Proc. of the 4th International Conferenceon Service Oriented Computing (ICSOC’06), pages 515-521. Chicago, Illinois,USA. 2006.

8. Y. Charif, N. Sabouret. Dynamic Service Composition and Selection thoughan Agent Interaction Protocol. Proc. of the 2nd Workshop on Service Compo-sition of the International Conference on Intelligent Agent Technology (Ser-Comp@IAT’06), pages 105-108. Hong Kong, China. 2006.

9. Y. Charif, N. Sabouret. Coordination d’agents introspectifs. Proc. des 15esJournées Francophones sur les Systèmes Multi-Agents (JFSMA’07), pages201-210. Carcassone, France. 2007.

161

162 PUBLICATIONS

10. Y. Charif, N. Sabouret. Coordination in Introspective MultiAgent Systems.Proc. of the International Conference on Intelligent Agent Technology (IAT’07),pages 412-415. Silicon Valley, California, USA. 2007.

Acronymes

ACL Agent Communication Language

AUML Agent Unified Modeling Language

CNP Contract Net Protocol

FIPA Foundation for Intelligent Physical Agents

LOTOS Language Of Temporal Ordering Specifications

RPM Request Processing Module

SMA Système MultiAgent

SOA Service-Oriented Architecture

SOAP Simple Object Access Protocol

SOC Service-Oriented Computing

SQL Structured Query Language

URI Unified Resource Identifier

UDDI Universal Description, Discovery and Integration

VDL View Design Language

WS-CDL Web Service Choreography Description Language

WSDL Web Service Description Language

WS-BPEL Web Service Business Process Execution Language

W3C World Wide Web Consortium

XML Extensible Markup Language

163

Documents

THÈSE - LIMSIUNIVERSITÉPIERREETMARIECURIE PARISVI Laboratoire d’Informatique de Paris 6 THÈSE pour obtenir le titre de DOCTEUR DE L’UNIVERSITÉ PIERRE ET MARIE CURIE