Conception d'un système d'agents mobiles pour l'accès aux données réparties : cas du multimédia.

DEDICACES

Je dédie ce travail :

À l'Éternel mon Dieu, En qui je trouve toute mon inspiration. Il pourvoit à mes besoins et sans cesse veille
sur moi,

À mon père M. NANGUE Michel pour l'amour et l'affection dont il me comble,

À la mémoire de ma chère maman, feue NANGUE née VOGUE Marie Solange, Qui

n'aura pas vécu assez longtemps pour jouir du résultat de son travail,

À Monsieur ASSONTSA GUY Pacôme qui m'a accompagné durant ce master.

À Madame TIADEM Sylvie Clémentine qui m'a sans cesse soutenu dans mes moments de détresse et

de maladie.

REMERCIEMENTS

Avant tout développement sur ce mémoire de fin d'études, nous rappelons que : « Une seule main ne peut pas attacher un paquet » dit la sagesse africaine. Ainsi, il apparaît opportun de commencer nos propos par des remerciements, à ceux qui nous ont beaucoup appris au cours de ce stage. Notamment :

Pr. Claude TANGHA - Chef de département de Génie Informatique de l'ENSP, pour sa rigoureuse contribution à notre formation et pour l'honneur qu'il me fait en acceptant de présider le jury de soutenance ;

A mon encadreur académique Dr Paul Martin LOLO Enseignant à l'ENSP, pour sa disponibilité, ses remarques et l'encadrement apporté tout au long de ce master au sein du département de génie informatique de l'ENSP. Nos échanges ont été très enrichissants.

Dr. Georges Edouard KOUAMOU - Enseignant à l'ENSP, pour le soutien moral émis à notre égard durant ce master et pour avoir accepté de juger mon travail ;

Dr GUILLAUME KOUM pour avoir accepté de juger mon travail ;

A Mon frère M.NANGUE Achille pour le suivi régulier et permanant durant ce master, A L'entreprise AFFIXE, pour m'avoir accordé la possibilité de faire ce master.

M.WAFEU André et M.YAMENNI Alain, pour leurs soutiens et leurs conseils qui m'orientent savamment dans le monde professionnel.

Dr KOUANFACK Charles, KOUANFACK Sylvie, KOUANFACK Emilienne et Ingénieur WOUATSA Georges pour leurs réconforts sur tous les plans.

A M. NANA Marc, M.DJOUOMESSI Rodrigue, et M. FOTSO NOTUE pour leurs apports dans la qualité de rédaction de ce mémoire

Nous ne saurions passer sous silence, ceux-là qui ont de près ou de loin contribués à la réalisation de ce travail. Nous pensons à:

Tous mesfrères et soeurs pour leur soutien ineffables pendant les périodes difficiles, et particulièrement Achille, Serges, Médard, Landry, Olivier, Valère, Guileine, Romuald.

Tous mes amis et connaissances.

Tous ceux que nous avons omis de citer ici, et qui ont contribués d'une façon ou d'une autre au bon déroulement de ce mémoire

ACRONYMES

Sigle	Signification
ACL	Agent Communication Language
DCOM	Distributed Component Object Model
FIPA	Fondation for Intelligent Physical Agents
IIOP	Internet Inter-ORB Protocol
KIF	Knowledge Interchange Format
KQML	Knowledge Qwery and Manipulation Language
OBR	Object Request Broker
PDA	Personal Digital Assistant
RdP	Réseau de Pétri
RMI	Remote Method Invocation
RPC	Remote Procedure Call
SMA	Système Multi-Agents
SOAP	Simple Object Access Protocol
UMTS	Universal Mobile Telecommunications System
WI-FI	Wireless Fidelity
WINMAX	Worldwide Interoperability for Microwave Access
XML	eXtended Markup Language

RESUME

Afin de faciliter le développement et la maintenance des applications réparties à grande échelle et mobiles, et de répondre aux besoins de gestion des données multimédia, nous proposons une solution à base d'agents mobiles collaboratifs. Les agents mobiles constituent un outil permettant une collaboration entre applications aux variations de la qualité des services offerts par le système et le réseau. Ils doivent eux-mêmes s'adapter dynamiquement à des conditions d'exécution variables. Nous présentons dans ce mémoire une architecture d'agents mobiles collaboratifs qui transforme des processus, du mode évaluation distante, en agents. Cette transformation offre une autonomie du code (processus) et rend le système distribué dynamique via la mobilité des agents. Toutefois, après avoir présenté les différents modes de conception d'un système distribué et leurs limites dans le cadre de la collecte des documents multimédia, nous montrerons comment notre architecture propose une amélioration. Pour valider cette proposition, nous définissons un formalisme via le Réseau de Pétri.

Mots dles : applications réparties, données multimédia, agents mobiles collaboratifs, évaluation distante, Réseau de Pétri

ABSTRACT

In order to render the development and maintenance of mobile and large scale distributed applications easier and also to satisfy the need for the management of multimedia data, a solution based on mobile collaborative agents is proposed. The mobile agents permit collaboration between applications as diverse the quality of the services offered by the network. They have to adapt dynamically to varying run conditions. In this memoir is presented an architecture of these mobile collaborative agents, which transforms processes, from the point of view of distant evaluation mode, to agents. This transformation gives the code (process) autonomy and renders the distributed system dynamic through the mobility of the agents. However, after a presentation of the different design modes of a distributed system and their disadvantages under the framework of the management of multimedia files, it is shown how this new system permits amelioration. In order to validate our proposal, a formal description of this system is done using the formal Petri Network model.

Keywords : distributed applications, multimedia data, mobile collaborative agents, distant evaluation, Petri Network

LISTE DES FIGURES

Figure 1: Invocation distante 9

Figure 2: Evaluation distante 9

Figure 3: Agent mobile 10

Figure 4: Schéma organisationnel : invocation distante 12

Figure 5:Schéma organisationnel : évaluation distante 13

Figure 6: Schéma organisationnel : agent mobile 14

Figure 7: Schéma organisationnel : agent mobile collaboratif 16

Figure 8:Schéma organisationnel : Agent mobile collaboratif 18

Figure 9: Les stratégies de mobilité [14] 20

Figure 10: La stratégie par agent mobile collaboratif 21

Figure 11 : Graphe des échanges d'informations 27

Figure 12 : Représentation formelle : Communication 28

Figure 13: Itinéraire d'un agent 28

Figure 14 : représentation formelle : Migration 29

Figure 15 : Représentation Globale du système 30

LISTE DES TABLEAUX

Tableau 1 : Niveaux de décomposition des objets 6

Tableau 2 : Analyse des coûts de la bande passante. 18

Tableau 3 : Analyse des stratégies de mobilité 21

Tableau 4 : agents participants 23

Tableau 5 : Propriété des langages de communication entre agents [16] 24

SOMMAIRE

DEDICACES i

REMERCIEMENTS ii

ACRONYMES iii

RESUME iv

ABSTRACT v

LISTE DES FIGURES vi

LISTE DES TABLEAUX vii

SOMMAIRE viii

INTRODUCTION 1

Chapitre I. Etat des lieux et problématique 2

I.1. Contexte 2

I.2. Problématique 2

I.3. Objectifs 3

Chapitre II. Etat de l'art 4

II.1. Agents mobiles 4

II.1.1 Historique 4

II.1.2 Définition 4

II.1.3 Mobilité d'un agent 5

II.1.4 Avantages et inconvénients 5

II.2. Multimédia 6

II.2.1 Définition 6

II.2.2 Objet multimédia 6

II.2.3 Quelques types complexes : l'audio et la vidéo 7

II.3. Systèmes répartis 8

II.3.1 Invocation distante 8

II.3.2 Evaluation distante 9

II.3.3 Agent mobile 9

II.4. Etude d'une application de collecte de données multimédia 10

II.4.1 Application à l'invocation distante 11

II.4.2 Application à l'évaluation distante 12

II.4.3 Application à l'agent toujours mobile 13

II.4.4 Limites des différents schémas organisationnels 14

Chapitre III. Modélisation et spécification 16

III.1. Agent mobile collaboratif 16

III.2. Amélioration de la collecte des documents multimédia. 17

III.3. Etude des stratégies de mobilité des agents 18

III.4. Spécification du schéma agent mobile collaboratif 22

III.4.1 Réseau de Pétri 22

III.4.2 Analyse du système 22

III.4.3 Formalisme 22

III.4.3.1 Cas d'Utilisation: Communication entre agents : 23

III.4.3.2 Cas d'Utilisation: Migration d'un agent 28

III.4.3.3 Représentation formelle du système Global. 29

CONCLUSION 31

REFERENCES BIBLIOGRAPHIQUES 32

ANNEXES 34

INTRODUCTION

Les réseaux à grande échelle, tels l'Internet, les grilles de calcul ou de stockage donnent accès à des quantités de données, de services et de ressources répartis. Les équipements mobiles d'aujourd'hui (PDA, Wifi. WINMAX, ...) enrichissent les possibilités d'interconnexion, et l'avenir semble tendre vers des systèmes informatiques ubiquitaires et mobiles. Dans un tel contexte, les applications doivent faire face à l'hétérogénéité des données [1] notamment les données multimédia.

En outre, ces applications doivent répondre de plus en plus à de nouvelles exigences de qualité de service et à l'émergence de nouvelles applications comme le calcul sur la grille ; ce qui généralement se traduit par des impératifs de dynamicité et de mobilité. Si des solutions satisfaisantes existent pour des environnements distribués statiques, elles sont inadaptées dans le cas où le système devient dynamique (mobilité, évolution, modification de composants). En effet, la conception d'algorithmes distribués est traditionnellement fondée sur l'hypothèse d'un réseau dont la topologie est statique.

Ainsi pour l'accès aux données multimédia réparties, nous nous proposons de concevoir un système d'agents mobiles, et définir une politique de mobilité des agents afin de montrer comment la manipulation des données multimédia peut être améliorée.

Plan du mémoire

Dans ce mémoire, le travail que nous avons effectué sera présenté suivant le plan cidessous :

Chapitre I : Présenter le contexte dans lequel s'inscrivent nos travaux, la problématique qui se dégage de ce contexte et les objectifs que nous nous sommes fixés afin de proposer une solution.

Chapitre II: Proposer une revue de la littérature pour permettre de mieux cerner les spécificités de notre approche. Après une présentation générale sur les agents mobiles et les données multimédia réparties, nous présentons les différentes architectures de conceptions d'un système distribué. A travers l'étude d'une application de collecte de documents multimédia, nous montrons les limites des schémas organisationnels issus de ces différentes architectures.

Chapitre III: Présenter la modélisation de notre schéma organisationnel pour une amélioration des limites citées au chapitre II. Ensuite, établir une comparaison entres les différentes stratégies de mobilités existantes. Enfin, présente le formalisme de notre modèle.

Chapitre I. Etat des lieux et
problématique

I.1. Contexte

En raison de la réduction du coût des machines et du développement des réseaux de communication, les systèmes distribués se généralisent largement. Ils sont constitués d'un ensemble d'éléments matériels ou logiciels, localisés sur différentes machines, qui interagissent pour atteindre un but commun. Les éléments de ces systèmes coordonnent leurs activités et échangent de l'information par transmission de messages à travers le ou les réseaux de communication qui relient les machines. Les réseaux à grande échelle, particulièrement l'Internet, sont de plus en plus utilisés. Dans ces réseaux, des machines puissantes (p.ex. macro-ordinateurs du type mainframe) côtoient des unités de calcul fixes ou mobiles à ressources plus restreintes (p.ex. micro-ordinateurs, assistants personnels, téléphones cellulaires UMTS¹, cartes à puces). Le partage de données et de ressources devient une motivation centrale lors de la conception d'applications sur ces réseaux de machines hétérogènes. Plusieurs schémas d'organisation sont possibles. Le choix du placement des éléments sur le réseau, leurs rôles et la manière dont ils communiquent influent particulièrement sur les propriétés non fonctionnelles d'une application distribuée.

I.2. Problématique

La problématique d'implémentation des systèmes distribués connait de nombreux succès avec l'avènement de nouveaux concepts tels : les objets, les composants et les agents. De plus, l'émergence des technologies d'interopérabilités notamment l'internet et les grilles, a amené les chercheurs à s'intéresser à la manipulation d'énormes quantités de données. Cette manipulation a entrainé des problèmes liés à la gestion de la bande passante.

Cependant le concept d'agents mobiles ; dont l'idée est de donner la capacité à un agent logiciel de se déplacer d'une machine à une autre en fonction des données et informations à traiter, a favorisé l'évolution considérable des systèmes repartis car il permet de réduire les interactions distantes.

En revanche, la conception des agents mobiles connait aujourd'hui de nombreux problèmes [2] non résolus par exemple : la sécurité de l'agent et de ses données, la mobilité

¹ UMTS : Universal Mobile Telecommunications System

des agents, la dynamicité des agents et l'interopérabilité. Dans le cadre de notre travail, nous tenterons de répondre à la question suivante : Quel schéma organisationnel permettrait de concevoir un système d'agents mobiles qui intègre une bonne politique de mobilité des agents ? Ceci afin d'améliorer l'accès aux données multimédia réparties.

I.3. Objectifs

Il nous incombe donc dans le cadre de notre travail de proposer un schéma organisationnel ayant une stratégie de mobilité optimale. Pour cela, nous allons effectuer une analyse des schémas existants en faisant ressortir leurs limites. Puis, nous allons apporter quelques améliorations via notre schéma. Ensuite, nous comparerons la stratégie de mobilité définie dans notre modèle aux stratégies existantes. Enfin, nous allons utiliser les réseaux de Pétri (Mieux adapter pour les systèmes distribués [3]) pour le formalisme du schéma organisationnel que nous avons proposé.

Chapitre II. Etat de l'art

Accéder à de l'information multimédia demande généralement aux usagers des systèmes, des efforts de différents niveaux[4]: expertises, compréhension, voire apprentissage. Ces systèmes, confrontés le plus souvent à des données réparties,

doivent gérer de façon optimale la bande passante afin de favoriser la manipulation de grands volumes de données.

Ainsi, dans ce chapitre, nous introduirons la notion d'agents mobiles. Puis nous effectuerons un bref rappel des données multimédia. Ensuite, nous étudierons les différents schémas organisationnels qui permettent de modéliser un système distribué. Enfin, nous montrerons les limites de ces différents schémas dans le cadre d'une application de collecte des données multimédia.

II.1. Agents mobiles

II.1.1 Historique

Les agents mobiles sont inspirés de travaux sur le calcul intensif initiés au sien de Xerox. La notion d'agent mobile [5] a été introduite pour la première fois en 1994 par White qui décrit l'environnement Telescript. Dans cet environnement, des processus (code et unité d'exécution pouvaient se déplacer d'eux-mêmes d'un site du réseau à un autre pour interagir localement avec des ressources d'autres sites. Cette technologie est alors apparue comme prometteuse pour la conception d'applications distribuées.

II.1.2 Définition

En informatique, un agent est l'équivalent d'un robot logiciel. C'est un programme qui accomplit des tâches à la manière d'un automate et en fonction de ce que lui a demandé son auteur. Dans le contexte d'Internet, les agents intelligents [6] sont liés au Web sémantique, dans lequel ils sont utilisés pour faire à la place des humains les recherches et les corrélations entre les résultats de ces recherches.

La notion mobilité permet à un agent de se déplacer d'un site à un autre en cours d'exécution pour accéder à des données ou à des ressources. Il se déplace avec son code et ses données propres, mais aussi avec son état d'exécution. Il décide lui-même de manière autonome de ses mouvements. Ainsi, la mobilité est contrôlée par l'application elle-même, et non par le système d'exécution comme dans le cas de la migration de processus dans les systèmes opératoires.

II.1.3 Mobilité d'un agent

Dans ce schéma, le savoir-faire appartient au client. Les agents mobiles peuvent être vus comme une généralisation de l'évaluation distante (cf. section II.3.2), où en plus du code, l'unité d'exécution est mobile. Les agents mobiles peuvent transporter des données paramétrées. Afin d'accéder aux ressources, les processus agents migrent de manière autonome vers les composants qui les proposent (voir Figure 3).

Au niveau de la mise en oeuvre, les migrations d'agents mobiles peuvent s'effectuer selon deux modes :

Migration forte

La migration forte (p.ex Telescript, Ara [7], AgentTcl [7]), où la totalité de l'agent (c'est-à-dire code, données et unité d'exécution) migre vers le nouveau site. Pour cette migration réelle, l'agent est suspendu ou capturé avant d'être transfèré. Une fois arrivé sur le site distant, il redémarre son exécution au point de contrôle précédent, en conservant l'état du processus.

MigrationForte ~ code + unité d'exécution + données-paramètres

Une autre possibilité proposée consiste à stopper l'exécution de l'agent avant la migration puis d'en créer une copie distante identique sur le site distant (migration par réplication).

Migration faible.

La migration faible où seul le code et les données migrent.

MigrationForte ~ code + données-paramètre

Une fois arrivé sur le site distant, l'agent est réexecuté. Le programmeur doit donc préserver, dans les données, les informations d'état permettant la poursuite logique de l'exécution.

II.1.4 Avantages et inconvénients

En pratique, la mobilité d'agent permet de rapprocher client et serveur et en conséquence de réduire le nombre et le volume des interactions distantes (en les remplaçants par des interactions locales), de spécialiser des serveurs distants ou de déporter la charge de calcul d'un site à un autre. Une application construite à base d'agents mobiles peut se redéployer dynamiquement suivant un plan pré-établit ou en réaction à une situation particulière, afin par exemple d'améliorer la performance ou de satisfaire la tolérance aux pannes, de réduire le trafic sur le réseau, ou de suivre un composant matériel mobile. La

mobilité du code offre un premier niveau de flexibilité aux applications. La décentralisation de la connaissance et du contrôle à travers les agents, et la proximité physique entre les agents et les ressources du système renforce la réactivité et les capacités d'adaptation.

La mobilité ne se substitue pas aux capacités de communication des agents (la communication distante reste possible) mais les complète ; afin de satisfaire aux contraintes des réseaux de grande taille ou sans fil (latence, non permanence des liens de communication), les agents communiquent par messages asynchrones le plus souvent.

Les agents mobiles, bien qu'ils connaissent quelques difficultés, restent une architecture appropriée pour la manipulation de grands volumes de données notamment des données multimédia

II.2. Multimédia

II.2.1 Définition

Le multimédia est la combinaison de plusieurs types de données sur le même support ou dans une même application. Il est à noter que pour qu'on parle de multimédia il faut qu'il y'ait interactivité. Par exemple : un livre peut être diffusé sous forme multimédia puisqu'il contient à la fois du texte et des graphiques (Les figures).

II.2.2 Objet multimédia

Un objet [8] est une unité d'information simple ou complexe pouvant être distribuée a travers un système d'information multimédia. A chaque type de média correspondent plusieurs niveaux de décomposition des objets. Par exemple, l'unité de base d'un objet de type texte est le caractère, mais des objets plus complexes tels que le mot, la phrase, le paragraphe ou le document peuvent être composés a partir des objets de base.

Médium unité	Unité Atomique	Unité intermédiaire	Cadre	Objet composite
Image	Pixel		Image
Vidéo	Pixel	Trame	Image	Segment Film
Graphique	Vecteur		Polygone	Dessin
Audio	Son	Phoême Mot	Phrase	Paragraphe discours
Texte	caractère	Mot	Phrase	Paragraphe Documents

Tableau 1 : Niveaux de décomposition des objets

Mémoire de Fin d'Etudes de Master 2 Recherche en Informatique : ENSP YAOUNDE, DECEMBRE 2008 Ingénieur DONFACK Cédric Pérez 6

II.2.3 Quelques types complexes : l'audio et la vidéo Type vidéo

Le type vidéo [9] est généralement représenté par une séquence de trames dans laquelle chaque trame est une image fixe. Toutefois, au lieu d'identifier les objets et les activités dans chaque trame, individuelle, on divise la vidéo en segments, chaque segment étant constitué d'une séquence de trames contiguës qui contiennent les mêmes objets ou activités. Chaque segment est identifié par une trame de début et une trame de fin. Les objets identifiés dans chaque segment peuvent servir à indexer les segments. Une technique d'indexation nommé arbre de segmentation de trame [10] a été proposée pour l'indexation des types vidéo. L'index comprends à la fois des objets comme des personnes, des maisons ou des voitures et des activités. Exemple : Quelqu'un qui prononce un discours ; 02 personnes qui conversent.

Type Audio

Ce sont par exemple des messages enregistrés (discours, présentations, cours etc.). Il est possible d'utiliser des transformations discrètes pour identifier les principales caractéristiques d'une voie données (extractions des caractéristiques) afin d'obtenir les possibilités d'indexation fondées sur les similitudes. Les caractéristiques audio sont : les volumes, l'intensité, le ton et la clarté.

Type textuel

Il est en substance le texte complet d'un article, d'un livre ou d'un magasine. On indexe généralement ces types en identifiant les mots clés qui apparaissent dans le texte et leur fréquence relative. Toutefois, les mots grammaticaux sont éliminés de ce processus. En raison du nombre trop important de mots clés lors de la tentative d'indexation de document, on a développé des techniques pour réduire le nombre de mots clés à ceux qui sont les plus pertinents pour la collection. Une technique nommé décomposition des valeurs singulière [11] basée sur des transformations peut être utilisée à cette fin. On peut ensuite employer une technique d'indexation nommée telescoping vector trees ou arbres TV pour grouper les documents apparentés.

Bien que l'émergence des technologies telles que le XML (eXtended Markup Language) aient permis une évolution considérable du multimédia ; des questions restent encore ouvertes ; notamment les problèmes de synchronisation, de distribution et de recherche sur Internet ou Intranet. Cette dernière thématique requiert des connaissances sur les systèmes distribués.

II.3. Systèmes répartis

Un système réparti [12](ou distribué, de «distributed system»), est une composition de plusieurs systèmes calculatoires autonomes, n'ayant pas de mémoires physiques communes et qui communiquent par l'intermédiaire d'un réseau quelconque. Ainsi, la maitrise des différentes approches de conception (Invocation de méthode, Invocation de service, échange de messages, etc.) des systèmes distribués favorisent une manipulation aisée des informations multimédia.

II.3.1 Invocation distante

Il existe plusieurs modes d'invocation distantes dont les plus utilisés sont l'invocation de méthodes et l'invocation de service.

Invocation de méthode :

Par souci initial de réutilisation et pour faciliter la conception et la maintenance, le domaine du génie logiciel s'est porté vers la programmation orientée objet. Un objet est une abstraction conceptuelle qui encapsule des données, associées à un ensemble de méthodes. Les systèmes basés sur les objets distribués adoptent le plus souvent un schéma client-serveur. Les objets sont gérés par des serveurs et les clients invoquent leurs méthodes (RPC objet, appelé RMI, Remote Method Invocation).

Invocation de service

De plus en plus, les architectures reposant sur un schéma client-serveur s'appuient sur l'Internet. Cependant, les protocoles existants, tels que IIOP (Internet Inter-ORB Protocol) ou celui DCOM (Distributed Component Object Model) s'adaptent difficilement aux environnements à grande échelle. Ils nécessitent un support d'exécution dédié. Des spécifications de protocole pour l'invocation distante telles que SOAP (Simple Object Access Protocol) émergent afin de standardiser les communications entre les applications à travers l'Internet, où les clients et serveurs s'affranchissent d'un ORB (Object Request Broker).

La figure1 nous présente le fonctionnement d'une invocation distante.

Figure 1: Invocation distante

II.3.2 Evaluation distante

Dans une interaction par évaluation distante, le composant client (un acteur du système) envoie un code à un autre site. Le composant récepteur exécute le programme, le code de l'application. Ce code peut contenir des données. Eventuellement, une interaction additionnelle délivre ensuite les résultats du service au composant émetteur. L'unité d'exécution (c'est-à-dire le compteur ordinal, pile, tas) et les ressources sont fixes, seul le savoir-faire est mobile. La Figure 2 présente le schéma à la manière de la Figure 1, illustrant le schéma client-serveur. Le service est réalisé sur le composant serveur (c'est-à-dire boite jaune), à la réception du code.

Figure 2: Evaluation distante

Un exemple d'évaluation distante est la commande rsh du système Unix. Elle permet à un utilisateur d'exécuter une suite d'instructions (c'est-à-dire script) sur un site distant.

II.3.3 Agent mobile

A la différence de l'évaluation distante, avec un agent mobile, l'exécution du code est initiée sur le composant client et continuée sur une collection de composants visités. Un agent mobile à migration faible, dont l'itinéraire est limité à un unique site, migrant dès le debut de son exécution, peut correspondre au schéma d'évaluation distante (l'état du processus transporté par les données-paramètres étant vide).

Mémoire de Fin d'Etudes de Master 2 Recherche en Informatique : ENSP YAOUNDE, DECEMBRE 2008 Ingénieur DONFACK Cédric Pérez 9

Figure 3: Agent mobile

Par leur nature, les agents mobiles traitent la distribution en interne. Un agent mobile est donc un processus migrant volontairement. Il peut se déplacer de site en site en suivant un itinéaire en fonction des taches à réaliser.

II.4. Etude d'une application de collecte de données

multimédia

En s'inspirant de l'analyse de Carzaniga, Picco et Vigna [13], supposons qu'un document multimédia est constitué du texte de taille T, d'un fichier vidéo de taille V, d'un fichier audio de taille A et d'une image de taille I. De plus, nous considérons qu'un fichier vidéo et un fichier audio sont représentés respectivement sous forme d'images (Images fixes) et de trames (Phoême Mot) de tailles respectives Iv, Ta. Aussi, nous admettons qu'un fichier vidéo et un fichier audio sont constitués respectivement de Im fichiers images et de Tm trames ; et chaque image ou trame est rattachée à un fichier de synchronisation de taille Syn. Ainsi, une vidéo aura une taille V = Iv * Im, un fichier audio sera de taille A = Ta * Tm ; leur stockage en mémoire représentera respectivement Sv = V + Im * Syn et Sa = A + Tm * Syn. La taille totale d'un document sera définie par Dm = T + V + A + I, et nous aurons en stocke SDm = Sv + Sa + T + I.

Dans l'application, un client souhaite récupérer des documents multimédia de taille constante b (b peut être égale à Dm ou à SDm), en interagissant avec n sites. Pour un site i donné, il existe des interactions avec les n -- 1 autres sites ainsi qu'un autre site vi de telle sorte que chaque site i ait un site vi qui lui est propre. Chaque site dispose d'un même nombre D de documents. Seul le site contenant le texte d'un document détient la localisation des autres morceaux de ce document. Pour chaque site, le client récupère dans un premier temps le texte et l'image des documents sur ce site ensuite, dans un deuxième temps il récupère les vidéo sur le site vi et enfin, dans un troisième temps il récupère les fichiers audio sur le site d'indice consécutif (pour i = n nous prendrons comme site consécutif i + 1 = 1). Un service complexe si (sur chaque site) permet de récupérer ces documents sous forme synchronisée, c'est-à-dire Out(si) = D * Dm et un autre permet de les récupérer sous forme non synchronisée (i.e.: vidéo = bloc d'images + fichiers de synchronisation et audio= bloc de trames + fichiers de synchronisation.), c'est-à-dire Out(s¹i) = D * SDm. Le service si est

Mémoire de Fin d'Etudes de Master 2 Recherche en Informatique : ENSP YAOUNDE, DECEMBRE 2008 Ingénieur DONFACK Cédric Pérez 10

constitué d'un service sAi, d'un service sVi et d'un service sTIi qui permettent de récupérer respectivement des fichiers audio c'est-à-dire Out(sAi) = D * A , Out(sVi) = D * V et Out(sTIi) = D * (T + I). De même, le service s^'i est décomposé en s^'Ai, s^'Vi et s^'TIi tels que :

Out(s'Ai) = D * Sa , Out(s'Vi) = D * Sv et Out(s'rIi) = Out(sTIi) = D * (T + ~),

Nous admettons qu'il existe un même nombre de documents sur chaque site dont la vidéo contient une image ayant le logo de l'entreprise. Ce dernier sélectionne donc ces documents afin de les télécharger. Les documents sont supposés uniformément repartis entre les sites. k(0<=k<=1) représente le ratio entre les documents à télécharger et le nombre de documents présents sur le site (sélectivité). Les requêtes émises par le client ont une taille fixe r (demande de fichier audio, demande de vidéo, ...), c'est-à-dire :

Pour tout i : In(si)=In(sAi)= In(sVi)= In(STIi)=r et In(s'i)= In(s^'Ai)= In(s^'Vi)= In(S^'TIi)=r.

Carzaniga, Picco et Vigna [13] ont proposé d'analyser les consommations en bande passante d'application de collecte de documents, mise en oeuvre selon trois schémas d'organisation notamment interaction RPC, évaluation distante et agent mobile.

Nous allons utiliser leur approche pour analyser notre application et considérer que ces schémas d'organisation ont été évalués, quand les n sites proposaient les mêmes services :

II.4.1 Application à l'invocation distante

Pour des interactions à base d'invocation distante (cf. section II.3.1), le client interagit à distance avec les n sites. Pour chaque site, il émet dans un premier temps D requêtes de taille r afin de récupérer les documents (taille Out(s)). Ensuite, il émet dans un second temps D requêtes de taille r afin de récupérer les bonnes vidéo. Enfin, suivant le ratio k fixé, il établit la connexion qui lui fournira les fichiers audio recherchés. Le coût suivant ce schéma est : n * [2 * D * r + Out(s^'TI1) + Out(s^'V1) + k * {D * r + Out(s'A1)}]

Figure 4: Schéma organisationnel : invocation distante

II.4.2 Application à l'évaluation distante

En utilisant l'évaluation distante (cf. section II.3.2), il devient possible de choisir les documents à télécharger directement sur le site distant (la sélection se fait à distance). Le client interagit à distance avec les n sites en envoyant du code source suivi d'une requête sur chacun d'eux. Pour chaque site, il envoie dans un premier temps le code source et la requête de taille r afin de récupérer les documents (taille Out(s)). Ensuite, il émet dans un second temps le code source de taille r afin de récupérer les bonnes vidéo. Enfin, suivant le ratio k fixé, il récupère les fichiers audio dont la vidéo répond au critère fixé. Le cout suivant ce schéma est : n * [3 * code + 3 * r + Out(STJ1) + k{Out(SA1) + Out(Sv1)}]

Figure 5:Schéma organisationnel : évaluation distante

II.4.3 Application à l'agent mobile

L'utilisation d'un seul agent mobile (cf. section II.3.3) pour parcourir sequentiellement les n sites induit un coût plus important que dans les deux cas precedents (l'itineraire est indifferent vu que tous les sites sont identiques). En effet, la requête et le code de l'agent migre n + 2 fois (les n sites, remonte au site 1 pour executer SA_n et le retour chez le client), ce qui est sensiblement equivalent à l'evaluation distante (n fois). Toutefois, les documents recuperes par l'agent en local sont place dans son sac à doc au fur et à mesure de son itineraire. Cependant, l'agent sauvegarde les donnees de son sac à dos chaque fois qu'il migre du site i vers le site Vi car il y retournera. Ainsi, les resultats des premiers services sTI1 et sVi vont transiter à travers les n -- 1 sites suivants avant d'être retournes au client. De même, les resultats du premier service sm s'obtiennent quand l'agent migre sur le deuxième site 2 et son parcours vers le site client est constitue de n -- 2 sites. Au cour de la (i + 1)nième interaction, les documents accumules par l'agent ont une taille de :

i * k * (Out(STI1) + Out(sVi)) + (i -- 1) * k * Out(sm) + source + r + k * Out(sVi) = i * k * (Out(sTIi) + Out(sVi) + Out(sm)) -- k * Out(sm)+ source + r + k * Out(sVi) =

i * k * Out(s1) --k * Out(sm)+ source + r + k * Out(sVi)

La taille des documents en transit correspond à la somme de 1 à n coût de ces migrations i. Le coût suivant ce schéma est :

(n + 2) * [source + r + k(n/2)Out(s1) -- out(sA1)] + n * [source + r + k * Out(sV1)]

Figure 6: Schéma organisationnel : agent mobile

Cette analyse permet de raisonner sur la meilleure technologie à exploiter pour l'application traitée. Pour cette application et avec les hypothèses données, les auteurs montrent que client-serveur (par invocation de méthode, RPC) et évaluation distante sont nettement plus favorables que l'utilisation d'un agent mobile (problème du cumul des documents sur l'itinéraire).

II.4.4 Limites des différents schémas organisationnels

Invocation distante

Cette approche présente un grand nombre d'inconvénients :

· Le nombre important d'invocations distantes de services oblige le client à utiliser un flux considérable pour ses interactions entre sites.

· L'utilisation systématique d'invocations distantes sans intégrer la mobilité du code impose le déplacement de grands volumes de données.

· Le transport des fichiers de synchronisation entraine une surcharge supplémentaire du réseau.

Evaluation distante

Cette approche propose une amélioration de l'invocation distante grâce à la mobilité du code. Toutefois, elle présente quelques limites tels que :

· Les processus mobiles qu'elle envoie sur les sites distants ne sont pas autonomes et cela oblige le client à faire transiter les données à travers le réseau.

· Tout comme l'invocation distante, le client est au centre des opérations. Ceci entraine une augmentation du flux des données à travers le réseau.

Agent mobile

Cette approche quant à elle, vient minimiser les interactions distantes. Cependant, l'utilisation d'un agent mobile montre quelques faiblesses :

· L'agent effectue un cumul de données précédemment collectées. Ce qui peut causer une saturation (Plantage) du réseau.

· Elle ne met pas à profil les notions de calcul parallèle afin de minimiser le temps d'exécution.

Ainsi, il sera souhaitable de penser à un schéma organisationnel qui apporte des améliorations à ces manquements.

Chapitre III. Modélisation et
spécification

Dans ce chapitre, nous proposons un schéma organisationnel qui permet une gestion optimale de la bande passante. De plus, nous montrerons l'amélioration de l'application de collecte de documents via ce schéma.

Ensuite, nous établirons une comparaison avec les stratégies de mobilité existante. Enfin, nous présenterons le formalisme de notre schéma organisationnel.

III.1. Notre proposition : Agent mobile collaboratif

La conception des agents mobiles collaboratifs s'inspire du fonctionnement des processus mis en oeuvre dans le mode évaluation distante. En outre, cette approche remplace des processus par des agents et offre ainsi la possibilité au client de faire migrer du code intelligent sur plusieurs sites parallèlement. Aussi, en considérant la notion d'agents mobiles au sens SMA (voir annexe2) (Système Multi Agents) ; nous avons la possibilité d'intégrer la notion de communication entre agents. De ce fait, le schéma, nommé agent mobile collaboratif, que nous proposons est un système à base d'agents mobiles au sens SMA.

Figure 7: Agent mobile collaboratif

La figure 7 nous montre dans la première partie (schéma de mobilité de l'agent) qu'un client est représenté par un agent. Ce dernier, pour réaliser une opération sur un site distant, délégue un agent qui sera sensé lui retourner le résultat. Puis, elle nous présente dans la deuxième partie (Schéma de collaboration des agents) qu'un agent délégué sur un site distant se comporte comme un client sur ce site. Ainsi, lorsqu'un agent sollicitera un service sur un site, le service sera exécuté par l'agent situé sur ce site : On parle alors de collaboration entre agents via des échanges de messages.

III.2. Amélioration de la collecte des documents multimédia.

En utilisant notre approche agent mobile collaboratif, il devient possible de choisir les documents à télécharger directement sur le site distant (la sélection se fait à distance). Aussi, il est possible de faire de l'agent migrant un client de la machine distante. Ceci permet à l'agent de faire migrer un autre (Un agent a la faculté de se répliquer [14].) vers les sites non occupés (Les sites n'ayant pas d'agents.) et de collaborer avec les agents situés sur les sites exécutant un agent. Ainsi, pour les n sites, le client émet dans un premier temps du code exécutable (sélectivité source) et sa requête r. Le nouveau site est considéré comme un client. Le client situé sur le site s1, après avoir déterminé les sites s1+1 et _sVi qui hébergent les autres fragments des documents qu'il recherche, va faire migrer de prime abord un agent vers le site V; via la requête r ; afin que celui-ci sélectionne, synchronise et récupère les vidéos concernées(suivant le ratio k) de tailles k * Out(sV1). Ensuite, le client situé sur le site s1 va dans un deuxième temps solliciter une fois de plus via la requête r, l'aide de l'agent situé sur le site distant, afin de récupérer les fichiers audio de tailles k * Out(sA1). Enfin, le même client va retourner les documents de tailles k * Out(s1). Le cout induit est donc moindre qu'avec des évaluations distantes. Il en est de même qu'avec des invocations distantes si la taille de la source est faible par rapport à la taille des documents et des requêtes. Le cout suivant ce schéma est :

n * [2 * source + 2 * r + k * {r + Out(s1) + Out(sA1) + Out(sV1)}]

Figure 8:Notre schéma organisationnel : Agent mobile collaboratif

Discussions sur les interactions distantes.

Interaction	Coût
Invocation distante	n * [2 * D * r + Out(s'ri1) + Out(s'v1) + k * (D * r + Out(s'A1)}]
Evaluation distante	n * [3 * code + 3 * r + Out(ST/i ) + k(Out(SA1) + Out(Svi)}]
Agent mobile	(n + 2) * [~ource + r + k (^n 2) Out(1) -- out(sA1)1 + n * [source + r + k * Out(sv1)]
Agent mobile collaboratif	n * [2 * source + 3 * r + k * (Out(s1) + Out(sA1) + Out(sv1)}]

Tableau 2 : Analyse des coûts de la bande passante.

Nous constatons que l'agent mobile avec son sac à dos est grossièrement inefficace. Mais, la transformation des processus du mode évaluation distante en agent, nous donne (comme le montre le tableau 2) une valeur du coût mieux appréciée que les deux premiers modes présentés par Carzaniga, Picco et Vigna [13].

III.3. Etude comparative de notre stratégie de mobilité aux

stratégies existantes.

L'étude précédente s'est restreinte à un agent qui ne réutilise pas les données accumulées et qui interagit toujours localement suivant un itinéraire fixé (toujours mobile). Aussi, elle n'a pas considéré le fait qu'un service doit prendre en paramètre des données venant d'une autre machine. Considérons maintenant une application ayant cinq services sl,

Mémoire de Fin d'Etudes de Master 2 Recherche en Informatique : ENSP YAOUNDE, DECEMBRE 2008 Ingénieur DONFACK Cédric Pérez 18

s1, s2, s2 et s3 qui fournissent un résultat à partir d'une requête. A la différente de l'analyse précédente, les cinq services sont donc composés (Services complexes). La donnée en entrée du service s1^~ (In(s1^~)) au cours d'une interaction correspond à la donnée rendue par le service s ~ (Out(s2)). De même, s^'2 prend entrée la donnée rendue par s3 ; s3 prend celle rendue par

s2, s2 celle de si et enfin si reçoit la donnée fournie par le client. Initialement, les données du client sont In(s1). Ainsi, la fonction à réaliser est sous la forme :

s1^~{s~^~[s3(s2{s1[In(s1)1})1}

.

Cependant, ces services sont répartis sur trois sites : Site 1 (s1 et s1^~), site 2 (s2 et s) et site 3 (s3). Le cas d'interactions multiples avec un service est envisagé. Toutefois, la donnée fournie en résultat est réutilisée directement en tant que nouvelle entrée du service. Ainsi, interagir m fois avec un service si par invocation distante engendre une taille de donnée Isize(s1) égale à m fois la somme de In(si) et Out(si). Isize est le volume total dû aux m interactions par invocation distante à travers le réseau.

Isize(a) = m(In(a) + Out(a)) oil V i, a E {si, s ~}

Chia et Kannapan [15] ont proposé trois études de cas afin de comparer le nombre d'octets transmis sur un réseau pour une application de transformation de données implantée à l'aide d'un agent.

Nous allons utiliser chacune des études qu'ils ont menées pour analyser notre stratégie.

1. Agent stationnaire : les interactions se font à distante entre les sites (invocation distante). Le trafic généré est équivalent à la somme des m interactions avec s1 , s2 , s3 , s ~ et s1^~ ; soit Isize(s1), Isize(s2), Isize(s3), Isize(s2) et Isize(s1^~). Le coût de ce schéma est donc :

Isize(s1) + Isize(s2) + Isize(s3) + Isize(s2) + Isize(s1^~)

2. Agent mobile : un agent, initié par le site client, migre vers le site prestataire de s1, ensuite celui proposant s2, puis vers le site prestataire s3 enfin rebourse chemin vers les services respectifs s_~^~ et s1, avant de retourner le résultat sous la forme d'un message à son client. Le trafic engendré sur le réseau correspond ainsi à cinq fois la taille du code de l'agent (source), la donnée initiale du client In(si), auxquels s'ajoutent les résultats fournit par s1, s2, s3, s~^~ et s1^~ (c'est-àdire Out(s1), Out(s2), Out(s3), Out(s2) et Out(s1^~)). Il n'y pas cumul de données à l'agent, p.ex Out(si) est consommé sur le site prestataire de s2. Le

volume de données Isize produit par les m interactions n'est pas à prendre en compte, celles-ci se faisant en local. Le coût de ce schéma est :

5 * source + In(si) + Out(si) + Out(s2) + Out(s3) + Out(s2) + Out(si^~)

3. Solution mixte : Chia et Kannapan [15] ont étudié le cas oil l'agent migre vers le site si, puis vers s2, interagit à distante avec s3 et si^~ et fournit finalement le résultat sous la forme d'un message à son client. Dans ce troisième cas, l'agent a la possibilité de s'appropriée des ports de communication sur un des sites de son itinéraire pour interagir par invocation distante (p.ex. synchrone) avec des services localisés sur d'autres sites. Le trafic engendré correspond à deux fois la taille du code de l'agent, la donnée initiale du client In(si), le coût des interactions distantes avec s3 et si^~ finalement le résultat de si^~ (retransmis au client). Le cout de cette interaction mixte est :

2 * source + In(si) + Out(si) + Isize(s3) + Isize(si^~) + Out(si^~)

Figure 9: Les stratégies de mobilité existantes [14]

4. Agent mobile collaboratif : Dans notre approche, l'agent initié par le site client, migre vers le site prestataire de si, ensuite, il se comporte comme un client en initiant un agent vers le site s2. Ce dernier fait de même lorsqu'il se trouve sur le site s2. Enfin l'agent situé sur le site s3 retourne le résultat vers l'agent situé sur le site s~ ~ (c'est-à-dire s2). Celui-ci renvoie le résultat vers si^~ (c'est-à-dire si) qui sera finalement fournit au client. Le trafic engendré sur le réseau correspond ainsi à trois fois la taille du code de l'agent (source), la donnée initiale du client In(si), auxquels s'ajoutent les résultats fournit par si, s2, s3, s~ ~ et si^~ (c'est-à-dire Out(si), Out(s2), Out(s3), Out(s2) et Out(si^~)). Une fois de plus, il n'y pas cumul de données à l'agent, p.ex. Out(si) est

consommé sur le site prestataire de s2. Le volume de données Isize produit par les m interactions n'est non plus à prendre en compte, celles-ci se faisant en local. Le coût de ce schéma est :

3 * source + In(si) + Out(si) + Out(s2) + Out(s3) + Out(s2) + Out(si^~)

Figure 10: Notre stratégie par agent mobile collaboratif

Discussions sur les stratégies de mobilité.

Interaction	Coût
Agent stationnaire	Isize(si) + Isize(s2) + Isize(s3) + Isize(s~^~) + Isize(si^~)
Agent mobile	5 * source + In(si) + Out(si) + Out(s2) + Out(s3) + Out(s~^~ ) + Out(si^~)
Solution mixte	2 * source + In(si) + Out(si) + Isize(s3) + Isize(si^~) + Out(si^~)
Agent mobile collaboratif	3 * source + In(si) + Out(si) + Out(s2) + Out(s3) + Out(s~^~ ) + Out(si^~)

Tableau 3 : Analyse des stratégies de mobilité

Le tableau 3 nous montre la stratégie utilisant l'agent stationnaire. Cette stratégie oblige le client à effectuer plusieurs appels distants. Cela entraine une consommation considérable de la bande passante. En revanche, l'agent mobile, bien que inefficace dans le cadre de la collecte des informations (Mauvaise conception du schéma.), est considéré comme étant la solution la mieux adaptée pour les services complexes. Toutefois, l'agent mobile collaboratif (Notre politique de mobilité), avec la notion de collaboration, offre une amélioration du coût de l'agent mobile comme le montre les coûts du tableau3.

Mémoire de Fin d'Etudes de Master 2 Recherche en Informatique : ENSP YAOUNDE, DECEMBRE 2008 Ingénieur DONFACK Cédric Pérez 21

III.4. Spécification du schéma agent mobile collaboratif

III.4.1 Réseau de Pétri (Voir annexe3)

III.4.2 Analyse du système

Nous cherchons à representer et analyser le fonctionnement et les interactions entre les divers sites de notre schema organisationnel (figure8). Ce schema dispose d'un site client et des sites distants. Le client (agent principal) souhaite s'interconnecter avec les autres sites pour faire migrer des agents mobiles (Aux sens SMA) afin de recuperer des documents multimedia. Aussi, c'est aux agents, arrives sur les sites distants, de reconstituer le document à telecharger. Toutefois chaque site distant, pour reconstituer un document, devra se connecter successivement sur deux machines distantes. Premièrement pour faire migrer un agent et deuxièmement pour etablir une communication.

Ainsi, notre système contient deux cas d'utilisations.

· Migration d'un agent.

· Communication entre agents.

III.4.3 Formalisme

Soit R le reseau de Petri à objets et interprete (La synchronisation "Gestion des rendezvous" est la principale raison pour laquelle notre reseau de Petri est interprete) representant notre formalisme. R est defini par le uple R = (P,T,F,K,J , M, W, C)

· P est l'ensemble (fini) des places : P = {Si, Svi / i E N}

· T est l'ensemble (fini) des transitions : T = {Ti/ i E N} oil Ti est un ensemble d'evenements necessaires pour le franchissement.

· P \ T = 0;

· F est la relation du flot d'execution: F g P x T u T x P;

F = {Si --> Ti, Svi --> Ti,Ti,Svi,Ti,Si / i ^E N}

· K represente la capacite de chaque place: K E P9Nat U{tu}

V j E J, V a E P, K(a(j)) fii avec les critères suivants : Si j E {doc, audio, video, Texte, Image}; fii = D

Si j E t^a--doc^{, a--}video^{, a--}audio^{, a--}doclj ; fii = ¹

· J représente les jetons. Un élément de J peut être soit un agent (Cas de la mobilité), soit des données (cas de la communication): J= {doc, a_doc, vidéo, a_vidéo, audio, a_audio, texte, image}. I est la variable qui renseigne sur le nombre d'instances d'un élément de J. Elle est initialement égale à zéro et locale à une place donnée.

· M représente le marquage initial de chaque place: M E P4Nat U{co} et vérifie la condition Vs E S: M(s) K(s).

· W représente le poids de chaque arc: W E F4Nat U{co};

V j E F, W(j) = Nat

· C représente les contraintes liées à la synchronisation de la communication. Il est régi par les variables de temps suivantes :

Tinitial : Date à laquelle l'agent est initialisé.

Tcourant : Date à laquelle on se trouve (Temps présent)

O_mi_n et _°max sont des variables qui représentent le temps début et le temps fin des opérations d'un agent. 00 est une constante.

III.4.3.1 Cas d'Utilisation: Communication entre agents : Description des agents participants.

Agents	Actions	Informe/travaille confirme/demande	Est déclenché
Document	Il est responsable du traitement du document multimédia dans sa totalité.	-Demande communique avec les agents vidéo ou audio. -Délègue les agents audio et vidéo (Ceux-ci, après réalisation de la tache restituent le résultat).	Par l'agent document principal (Situé sur le site client).
Vidéo	Il est responsable du traitement sur la vidéo : -Transport de fichiers constituant la vidéo. -Gère la synchronisation des images pour en faire des vidéos	Informe l'agent document sur la fin de sa tâche et restitue le résultat.	Par l'agent document. Et délégué vers le site approprié
Audio	Il est responsable du traitement sur l'audio: -Transport de fichiers constituant l'audio. -Gère la synchronisation des sons pour en faire des vidéos	Informe l'agent document sur la fin de sa tâche et restitue le résultat.	Par l'agent document. Et délégué vers le site approprié.
DocumentPrincipal	Il est responsable de l'affichage des documents vidéo.		Par le client (Personne physique)

Tableau 4 : agents participants

Description de la communication

Les langages de communication entre agents les plus courants encore appelés ACL (Agent Communication Language) sont FIPA² ACL et KQML³.

KQML et FIPA ACL sont utilisés pour la communication entre agents. Le KQML est beaucoup plus utilisé et donne par conséquent une très grande ouverture sur la programmation telle que l'illustre le tableau5. D'après le tableau5, nous choisirons le langage KQML pour la suite:

Application	Langage de communication	Langage de requête	Ontologie structure
SIMS_based	KQML	loom	propriétaire
WARREN : Amulti agent financial port for management	KQML	Pas spécifié	Pas spécifié
Information gathering based on low level retrival agent accessing HTML, supervised by planninge, coordination and scheduling agent	KQML	Pas spécifié	Pas spécifié
Infomaster	Pas spécifié	KIF (Knowledge Interchange Format)	Pas spécifié
Agent for hypermédia information discovery	KQML	XML / Prolog	Pas spécifié
Multi agent systems an information Rich environnement	KQML	SQL	KIF - Ontologie
COMRIS	FIPA ACL (XML)	XML	Propriétaire

Tableau 5 : Propriété des langages de communication entre agents [16]

Le principe de KQML est de séparer la sémantique liée au protocole de communication indépendamment du domaine de communication.

² FIPA ( Fondation for Intelligent Physical Agents).

³ KQML (Knowledge Qwery and Manipulation Language).

Le protocole de communication doit donc être universel pour tous les types d'agents. Dans le langage KQML un message contient toutes les informations nécessaires à sa compréhension.

(KQML-performatif

: émetteur <texte>

: récepteur <texte>

: langage <texte>

: ontologie <texte>

: contenu <texte>

....)

Exemple de communication entre agents du système.

Le langage logique KIF [17] (Knowledge Interchange Format) est capable de décrire les faits concrets, Son but est de définir un format standard de représentation de connaissances manipulées par des agents. Ce langage sera utilisé dans la suite.

A/ l'agent document sollicite l'aide d'un agent voisin pour collaborer. (Stream-all

: sender agentDocument

: receiver agentAudio

: language KIF

: ontology synchronisation

: reply-with q2

: content « débuter la sélection, x »)

B/ l'agent Audio restitue le résultat de la sélection à l'agent document. (tell

: sender agentAudio

: receiver agentDocument

: language KIF

: ontology synchronisation

: in-reply-to q1

: content « restitue le résultat, oui »)

C/ l'agent Audio restitue le résultat de la sélection à l'agent document. (tell

: sender agentAudio

: receiver agentDocument

: language KIF

: ontology synchronisation

: in-reply-to q2

: content « restitue le résultat, oui »)

D/ l'agent Document restitue le résultat de la collecte à l'agent DocumentPrincipal. (tell

: sender agentDocument

: receiver agentDocumentPrincipal

: language KIF

: ontology synchronisation

: in-reply-to q2

: content « restitue la collection, oui »)

Schématisation de la communication.

Dans le système, l'agent document échange des informations avec l'agent audio (a_audio), reçoit des traitements venant de l'agent vidéo (a_video : Précédemment délégué.) et renvoie les résultats vers l'agent client (a_docP). L'automate de la figure11 montre les différentes interactions possibles.

Figure 11 : Graphe des échanges d'informations

Le réseau de Pétri de la figure11 est une représentation formelle des échanges de données entre agents du système. Il nous montre les conditions à remplir pour qu'un échange ait lieu. Ceci se fait via des événements définis au niveau des transitions.. Les marquages initiaux et finaux M0 et _Mfinal sont définis comme suit :

M0(doc)={D,0,0,0} ; M0(video)={0,D,0,0}, M0(requete)={1,0,0,0} et M0(audio)={D,0,0,0}

Mfi_nal(doc)={0,0,0,D} ; Mfi_nal(video)={0,0,0,D, Mfi_nal(audio)={0,0,0,D} et M0(requete)={0,0,1,0}

Figure 12 : Représentation formelle : Communication

III.4.3.2 Cas d'Utilisation: Migration d'un agent

L'itinéraire d'un agent est représenté par l'automate de la figure13. Lorsque le client lance le système, un agent (a_docP) est créé. Celui-ci envoie l'agent document (a_doc) pour la collecte des documents multimédia. L'agent a_doc, afin de favoriser les déplacements fluides se sert des agents spécialisés à des tâches spécialisées.

Figure 13: Itinéraire d'un agent

Le réseau de Pétri de la figure14 est une représentation formelle de la migration des agents du système. Il nous montre les événements à remplir pour qu'un agent puis se mouvoir

(p.ex : l'agent document ne peut se déplacer que si le site distant abrite un service S1). Les transitions T3 et T4 représentent les contraintes de création des agents a_doc et a_video. Les marquages initiaux et finaux M0 et _Mfinal sont définis comme suit :

M0(a_doc)={0,0,1} ; M0(a_video)={1,0,0} et M0(a_audio)={1,0,0}

Mfi_nal(a_doc)={1,0,0} ; Mfi_nal(a_video)={0,1,0} et Mfi_nal(a_audio)=M0(a_audio)

Figure 14 : représentation formelle : Migration

III.4.3.3 Représentation formelle du système Global.

Considérons que nous avons un système disposant de deux sites. La figure14, nous montre les interactions de mobilité et de communication entre les agents. De plus, étant donné que nous avons deux types d'objets, notre réseau de Pétri, afin de faciliter la compréhension du schéma, a été défini avec deux types d'arcs comme présenté dans la légende de la figure15. L'instant qui correspond au modèle est le moment où tous les types d'objets ont été initialisés. Pour la représentation successive des franchissements (voir annexe1).

Figure 15 : Représentation Globale du système

La figure15 présente le fonctionnement global du système. Lorsque l'événement T1 est vérifié, le site P3 reçoit un nouveau jeton : Création d'un agent document. Celui-ci migre vers les places P0 et P2 si l'événement T3 est satisfait. Les agents situés sur les sites P0 et P2 font générer des agents vidéo sur chacun des sites lorsque _T13 ^et _T14 seront respectivement atteints. Ces derniers migreront respectivement vers les sites P1 et P4 pour T9 et _T11 valides ; les résultats obtenus par chacun sont retournés sous forme de messages selon les événements T8 et _T12. Après la réception des résultats des agents vidéo, chaque agent document générera des agents audio (Lorsque les transitions _T13 ^et _T14 sont satisfaites.) pour qu'ils effectuent le traitement des fichiers audio via des échanges de messages déclenchés par les événements T6 et _T10 pour l'émission de la requête et T7 et T5 pour la réception des résultats. Ainsi, chaque agent document, ayant réalisé toutes les opérations, reconstitue le document multimédia et le retourne au client sous forme de message ; ceci marque la fin de la collecte.

CONCLUSION

Ce travail s'inscrivait dans le cadre des systèmes à base d'agents mobiles pour l'accès aux données réparties (Cas des multimédia). Il visait plus précisément à proposer une solution sur le problème lié à la mobilité du code notamment le choix entre l'invocation distante et la migration du code. L'intérêt de ce problème, offre une gestion optimale de la bande passante.

Bilan

Pour y parvenir nous avons procédé en plusieurs étapes. De prime abord, il a fallu faire une étude bibliographique afin d'énumérer les solutions existantes à ce sujet. Ensuite, nous avons appréhendé les concepts inhérents à la problématique soulevée. Puis, en appliquant l'étude analytique de Carzaniga, Picco et Vigna dans le cadre de la collecte des données multimédia non synchronisées, nous avons constaté que les solutions existantes étaient limitées. Aussi, pour améliorer ces dernières, nous avons proposé une architecture d'agents mobiles collaboratifs et nous l'avons comparée aux stratégies de mobilité présentées par Chia et Kannapan. Enfin, nous avons défini via les réseaux de Pétri, le formalisme permettant la spécification de notre schéma.

Perspectives

Nous avons proposé une architecture qui offre une bonne stratégie de mobilité aux systèmes à base d'agents mobiles. Cependant, il serait plus optimal et plus fiable de prendre en compte le problème de sécurité rencontré dans le développement des agents mobiles. De plus, de refaire notre analyse en prenant en compte les interactions natives d'un système Multi-Agents.

REFERENCES BIBLIOGRAPHIQUES

1. Sébastien LERICHE, Jean-Paul ARCANGELI. Une architecture pour les agents mobiles. [En ligne] 2004. [Citation : 15 juillet 2008.] http://www2.lifl.fr/jc2004/articles/leriche-arcangeli.pdf.

2. Min-Jung YOO, Jean-Pierre BRIOT and Jacques FERBER. Using Components for Modeling Intelligent and Collaborative Mobile Agents. Workshop WetIce98. [En ligne] 1998. [Citation : 02 octobre 2008.] http://www-poleia.lip6.fr/~briot/publications/mobileagents-wetice98.ps.gz.

3. Sujet de Stage Master recherche Approche incrémentale et modulaire pour la vérification de propriétés temporelles linéaires sur les réseaux de Petri. Petrucci, Laure et Klai, Kais. 7030, Paris : F-93430 Villetaneuse, France, Vol. 1. LIPN, CNRS UMR 7030.

4. Interrogation et Stockage. [En ligne] [Citation : 20 Octobre 2008.] http://wwwclips.imag.fr/mrim/User/Stephane.Bissol/AS/.

5. Peter Braun, Wilhelm Rossak. From Client-Server to Mobile Agents. Mobile Agents Basic Concepts, Mobility Models,and the Tracy Toolkit. Heidelberg : Morgan Kaufmann Publishers, 2005, p. Germany.

6. Agent (informatique). WIKIPEDIA. [En ligne] Wikimedia Foundation, Inc, 14 mars 2008. [Citation : 03 11 2008.] http://fr.wikipedia.org/wiki/Agent_(informatique).

7. Evry, Guy Bernard - INT. Agents mobiles dans les systèmes répartis :. [En ligne] 20 octobre 1999. [Citation : 03 octobre 2008.] http://rge.ustrasbg.fr/reunions/rge14101999/agentsmobile/index.htm.

8. LOLO, Paul Martin. UN MODELE DE COMMUNICATION PERMETTANT DRE EALISER. Ecole Nationale Supérieure Polytechniq de Yaoudé : s.n., 25 Septembre 1994.

9. KOUM, Guillaume. Cours de BD et MULTIMEDIA, Ecole Nationale Supérieure Polytechnique de Yaoundé. 2008.

10. Aissa, Saoudi. Empreinte numérique et indexation de la vidéo. [En ligne] [Citation : 29 10 2008.] http://plate-formeast.mshparisnord.org/IMG/pdf/Empreinte_num__index_video.pdf.

11. Bertin, Nancy. Techniques de décomposition matricielle pour la transcription de musique polyphonique (Thèse de l'ENST). s.l. : Département Traitement du Signal et des Images, 2003.

12. Tardieu, Samuel. Systèmes répartiis. [En ligne] 2000/2001. [Citation : 15 juillet 2008.]

13. Designinig Distributed Application with Mobile Code Paradigms. Carzaniga, Antonio, Picco, Gian Pieto et Vigna, Giovanni. ACM Press : Taylor, mai 1997. Proceedings of the 19th International Conference on SoftWare Engineering. pp. 22-32.

14. Rouvrais, Siegfie. Utilisation d'agents mobiles pour la construction de services distribués. [En ligne] 02 Juillet 2002. [Citation : 03 octobre 2008.] http://www.odilehalbert.com/Famille/Rouvrais.pdf.

15. Strategically Mobile Agents. Chia, Teck-How et Kannapan, Srikanth. New York : Cornell University, Novembre 1996. Proceedings First International Conference on Mobile Agents. pp. 2-10.

16. TIAKO NGATCHEU, Irénée. Synchronisation multi-media par modélisation multi-agents. [fichier text] Douala : LORIMA.

17. Pease, Adam. Standard Upper Ontology Knowledge Interchange Format. [En ligne] 18 02 2004. [Citation : 28 10 2008.] http://ontolog.cim3.net/file/resource/reference/SIGMA-kee/suo-kif.pdf.

18. Briot, Jean Pierre et Demazeau, Yves. Principes et architecture des systèmes multi-agents. Hermès : collection I, 2001.

19. Medi@TICE. Les réseaux de Petri. Les réseaux de Petri. [En ligne] 08 2007. [Citation : 23 09 2008.] http://www.cyber.uhp-nancy.fr/demos/GEII010/cha_2/cours_2_1_3.html.

ANNEXES

Annexe 1 : Description du Parallélisme de notre système Présentation des opérations aux différents instants de fonctionnement du système. Instant t=initial (Initialisation du système par l'a_docP)

M(a_doc)={0,0,0,0,0} ; M(a_video)={0,0,0,0,0}, M(a_audio)= {0,0,0,0,0},

M(doc)={0,0,0,0,0} ; M(video)= {0,0,0,0,0}, M(requete)= {0,0,0,1,0} et M(audio)= {0,0,0,0,0}

Instant t=initial+1

M(a_doc)={0,0,0,1,0} ; M(a_video)={0,0,0,0,0}, M(a_audio)= {0,0,0,0,0},

M(doc)={0,0,0,0,0} ; M(video)= {0,0,0,0,0}, M(requête)= {0,0,0,1,0} et M(audio)= {0,0,0,0,0}

Instant t=initial+2

M(a_doc)={1,0,0,1,0} ; M(a_video)={0,0,0,0,0}, M(a_audio)= {0,0,0,0,0},

M(doc)={0,0,0,0,0} ; M(video)= {0,0,0,0,0}, M(requête)= {1,0,0,1,0} et M(audio)= {0,0,0,0,0}

Instant t=initial+3

M(a_doc)={1,0,1,0,0} ; M(a_video)={0,0,0,0,0}, M(a_audio)= {0,0,0,0,0},

M(doc)={D,0,0,0,0} ; M(video)= {0,0,0,0,0}, M(requête)= {1,0,1,1,0} et M(audio)= {0,0,0,0,0}

Instant t=initial+4

M(a_doc)={1,0,1,0,0} ; M(a_video)={1,0,0,0,0}, M(a_audio)={0,0,0,0,0},

M(doc)={D,0,D,0,0} ; M(video)= {0,0,0,0,0}, M(requête)= {1,0,1,1,0} et M(audio)= {0,0,0,0,0}

Instant t=initial+5

M0(a_doc)={1,0,1,0,0}, M0(a_video)={0,1,1,0,0}, M0(a_audio)={1,0,0,0,0},

M0(doc)={D,0,D,0,0} ; M0(video)= {0,0,0,0,0}, M0(requête)= {1,1,1,1,0} et M0(audio)= {0,0,0,0,0}

Instant t=initial+6

M0(a_doc)={1,0,1,0,0} ; M0(a_video)={0,1,0,0,1}, M0(a_audio)= {1,0,1,0,0},

M0(doc)={D,0,D,0,0} ; M0(video)= {0,D,0,0,0}, M0(requête)= {1,1,1,1,1} et M0(audio)= {0,0,0,0,0}.

Instant t=initial+7

M0(a_doc)={1,0,1,0,0} ; M0(a_video)={0,1,0,0,1}, M0(a_audio)= {1,0,1,0,0},

M0(doc)={D,0,D,0,0} ; M0(video)= {D,0,0,0,D}, M0(requête)= {1,1,1,1,1} et M0(audio)= {0,0,0,0,0}.

Instant t=initial+8

M0(a_doc)={1,0,1,0,0} ; M0(a_video)={0,1,0,0,1}, M0(a_audio)= {1,0,1,0,0},

M0(doc)={D,0,D,0,0} ; M0(video)= {D,0,D,0,0}, M0(requête)= {1,1,1,1,1} et M0(audio)= {0,0,k*D,0,0}.

Instant t=initial+9

M0(a_doc)={1,0,1,0,0} ; M0(a_video)={0,1,0,0,1}, M0(a_audio)= {1,0,1,0,0},

M0(doc)={D,0,D,0,0} ; M0(video)= {k*D,0,0,0,0}, M0(requête)= {1,1,1,1,1} et M0(audio)= {2*k*D,0,0,0,0}.

Instant t=initial+10

M0(a_doc)={1,0,1,0,0} ; M0(a_video)={0,1,0,0,1}, M0(a_audio)= {1,0,1,0,0},

M0(doc)={D,0,D,0,0} ; M0(video)= {D,0,D,0,0}, M0(requête)= {1,1,1,1,1}

et M0(audio)={ k*D,0, k*D,0,0}.

Instant t=initial+11 (Fin des opérations)

M0(a_doc)={1,0,1,0,0} ; M0(a_video)={0,1,0,0,1}, M0(a_audio)= {1,0,1,0,0},

M0(doc)={0,0,0,2*k*D,0} ; M0(video)={0,0,0,2*k*D,0}, M0(requête)= {1,1,1,1,1}

et M0(audio)={0,0,0,2*k*D,0}.

Annexe2 : Système Multi Agents [18]

La définition d'un système multi-agent (avec son acronyme SMA, et MAS pour « multi-agent system » en anglais) est plus immédiate : « un système multi-agent est un ensemble organisé d'agents ». Nous ne faisons que suivre ici la définition usuelle du terme système : « un ensemble organisé d'éléments ». Cela signifie que dans un système multi-agent, il existe une ou plusieurs organisations qui structurent les règles de cohabitation et de travail collectif entre agents (définition des différents rôles, partages de ressources,

dépendances entre tâches, protocoles de coordination, de résolution de conflits, etc.). Dans un même système, il existe en général plusieurs organisations et un même agent peut appartenir à plusieurs simultanément. Des exemples d'organisations d'agents dans le monde réel sont une organisation économique telle qu'une entreprise, mais aussi une organisation animale telle qu'une fourmilière. Suivant les cas, les comportements des agents sont plus ou moins complexes et rationnels et l'organisation est plus ou moins adaptative. Central aux systèmes multi-agents est l'équilibre (et la complémentarité) entre autonomie et organisation.

Les agents sont en général situés dans un environnement (par exemple, topologique) contenant également des entités passives, manipulées par les agents (par exemple, des ressources, des données, des objets physiques...) et communément appelées objets. Chaque agent n'a qu'une connaissance partielle de son environnement et des autres agents. Un système multi-agent est donc intrinsèquement décentralisé.

Annexe3 : Réseau de Pétri [19]

Définition

Un Réseau de Pétri (RdP) est un graphe orienté comportant :

· un ensemble fini de places, P= {P1, P2, P3, ..., P_m}, symbolisées par des cercles et représentant des conditions : une ressource du système (ex. : une machine, un stock, un convoyeur, ...), l'état d'une ressource du système (ex. : machine libre, stock vide, convoyeur en panne, ...)

· un ensemble fini de transitions, T= {T1, T2, T3, ..., T_n}, symbolisées par des tirets et représentant l'ensemble des événements (les actions se déroulant dans le système) dont l'occurrence provoque la modification de l'état du système,

un ensemble fini d'arcs orientés qui assurent la liaison d'une place vers une transition ou d'une transition vers une place,

Un ensemble de jetons représentant une donnée ou/et une classe.

Marquage d'un Réseau de Pétri (RdP) :

Le marquage d'un RdP est précisé par la présence à l'intérieur des places d'un nombre fini (positif ou nul), de marques ou de jetons. Une place est donc vide ou marquée.

Lorsque la place représente une condition logique (ex. : machine à l'arrêt, convoyeur en panne), la présence d'un jeton indique que cette condition est vraie ; fausse dans le cas contraire.

Lorsque la place représente une ressource (au sens le plus large - ex. : une machine, un stock), elle peut contenir plusieurs jetons (ex. : nombre de pièces en stock).

Franchissement d'une Transition

Le franchissement d'une transition ou tir d'une transition, consiste à retirer une marque dans chacune des places d'entrée de la transition et à ajouter une marque dans chacune des places de sortie de la même transition.

Validation d`Une Transition

Une transition est validée (ou sensibilisée ou franchissable ou tirable) lorsque toutes ses places d'entrée contiennent au moins un jeton.

Transition Source

Une transition source est une transition qui ne comporte aucune place d'entrée ; c'est une transition toujours franchissable et le franchissement a lieu lorsque l'événement associé se produit.

Transition Puits

Une transition puits est une transition qui ne comporte aucune place de sortie ; le franchissement d'une transition puits enlève des jetons de toutes les places d'entrée de la transition.

Mémoire de Fin d'Etudes de Master 2 Recherche en Informatique : ENSP YAOUNDE, DECEMBRE 2008 Ingénieur DONFACK Cédric Pérez 37