SaGE,unSystèmedeGestiond Exceptions pourla programmationorientéemessage: Le casdessystèmesmulti-agents et desplates-formesàbasedecomposantslogiciels

Transcription

1 numéro d identification : ACADÉMIE DE MONTPELLIER UNIVERSITÉ MONTPELLIER II SCIENCES ET TECHNIQUES DU LANGUEDOC THÈSE présentée àl Université des Sciences et Techniques du Languedoc pour obtenir le diplôme de DOCTORAT SPÉCIALITÉ :INFORMATIQUE Formation Doctorale :Informatique École Doctorale :Information, Structures, Systèmes SaGE,unSystèmedeGestiond Exceptions pourla programmationorientéemessage: Le casdessystèmesmulti-agents et desplates-formesàbasedecomposantslogiciels par FRÉDÉRIC SOUCHON Soutenue le5décembre 2005 devant le jury composé de : M. Olivier BOISSIER,Professeur, École des Mines de Saint-Étienne, Rapporteur M. Philippe LAHIRE,MDCHDR, Université de NiceSophia Antipolis, Rapporteur M. Alexander ROMANOVSKI,Professor, University of Newcastle upon Tyne, UK, Examinateur Mlle. Christelle URTADO,MDC École des Mines d Alès, Examinateur M. Jacques FERBER,Professeur, UniversitéMontpellier II, Examinateur M. Christophe DONY,Professeur, Université Montpellier II, Directeurde Thèse

2 2 à mes parents,

3 Remerciements Je remercie respectueusement mon directeur le thèse, le Professeur Christophe Dony, pour ses conseils, ses encouragements, sa confiance, tout ce par quoi il a su orienter ma liberté de recherche. Mes respects et ma gratitude vont également aux membres de mon jury qui m ont fait l honneur de juger ce travail en venant pour certains de fort loin et qui tous, par leur disponibilité, leurs observations et leurs rapports m ont permis de l enrichir. Mener à terme un doctorat, au delà de la rédaction du document de thèse, porte sur les efforts menés de la découverte de la bibliographie jusqu à l organisation de l événement si particulier que constitue le jour de sa soutenance en passant par les échanges et réflexions qui ont permis de proposer un travail enrichissant pour une communauté scientifique. L ensemble de ce processus serait irréalisable sans l aide et le soutien d autres personnes. Merci à Audrey, Camille, Olivier, Fabien et Eric pour avoir immensément contribué à chacun de ces aspects. Merci à Jérome Chapelle pour toute l aide qu il m a apporté de nombreuses fois durant toutes ces années. Merci à Christelle Urtado et à Sylvain Vauttier de m avoir fait participer à une activité de recherche si passionnante et inspirante. Merci à mes encadrants pour leur disponibilité lors des pré-soutenances. Merci à Fabien Jalabert pour son immense contribution à l organisation du jour J. Je remercie également Sylvie Cruvellier et Jocelyne Nanard pour leur précieuse aide lors des démarches administratives. Mener à terme un doctorat suppose aussi bien sur que les choses de la vie vous en aient donnés l occasion. Je pense à tous mes professeurs sans lesquels ce travail n existerait pas et plus spécialement à Jacques Ferber qui m a donné goût à l étude des systèmes multi-agents. Merci à Fabien Michel et Olivier Simonin pour m avoir fait partager leur expérience du doctorat. Je remercie l équipe pédagogique de l EERIE pour m avoir permis de faire mes premières armes dans l enseignement. Je remercie Annie Liothin et François Trousset pour leur aide et les bons moments que nous avons partagés tout au long de cette thèse. Mener à terme un doctorat est aussi une expérience humaine. Je remercie tous ceux qui m ont aidé dans cette aventure. Merci Géraldine, Nicolas, Canelle, Amélie, Patrice, Clément, Frédéric, Sébastien et Emilie. Je remercie ma mère et je remercie mon père. Merci à Agnès. 3

4 4

5 Table des matières 1 Introduction 13 1 Contexte et objet de ce mémoire Organisation du mémoire Contexte d étude : les programmations par agents et par composants 17 1 Les middlewares : une solution aux limites de la programmation distribuée classique Définition Les modes de communication dans les applications Concurrence et asynchronisme Possibilité de définir des activités concurrentes Coordination des activités concurrentes Les Systèmes Multi-Agents, un exemple typique de la programmation orientée message Introduction et définitions Les sociétés d agents L exemple des agences de voyage dans un système multi-agents : choix de modélisation Les plates-formes à base de composants logiciels Introduction et définitions Typologie des modes d interaction Définitions Interactions par requête/réponse et communications synchrones Interactions par requête/réponse et communications asynchrones Interaction par soumission d information L exemple des agences de voyage dans une plate-forme à base de composants logiciels : choix de modélisation Conclusion Gestion d exceptions : état de l art 45 1 Systèmes de Gestion d Exceptions (SGE) : motivations et définitions Tolérance aux pannes : quelles solutions?

6 TABLE DES MATIÈRES Cahier des charges pour la gestion des exceptions Codes de sortie Renvoi de valeurs particulières Gestion d exceptions Gestion d exceptions en programmation séquentielle Présentation d un système de gestion d exceptions typique Gestion d exceptions dans le paradigme objet Gestion d exceptions en milieu concurrent La gestion d exceptions dans le cadre de la concurrence isolée : la cas typique des threads Java Gestion d exceptions dans des langages permettant la concurrence collaborative Gestion d exceptions dans Multilisp La concurrence dans ProActive Des systèmes de gestion d exceptions pour la concurrence coopérative Le cas des Threadgroups Java Une proposition permettant la concertation d exceptions dans un langage à multi-procédures Un système distinguant les activités critiques et non-critiques dans le langage Guide Gestion d exceptions dans les systèmes multi-agents (SMA) SMA sans SGE dédié SMA avec gestion d exceptions centralisée SMA à superviseurs SMA avec gardiens Synthèse Gestion d exceptions dans les plates-formes à base de composants logiciels Gestion d exceptions pour les composants communiquant de manière synchrone et interagissant par requête/réponse Gestion d exceptions pour les composants communiquant de manière asynchrone et interagissant par requête/réponse Le cas des MessageDrivenBeans (J2EE) Le cas des composants RRA dans.net Le cas des composants RRA dans CORBA Le modèle à gardien pour composants RRA Gestion d exceptions pour les composants interagissant par émission d information Cahier des charges résultant de l étude

7 TABLE DES MATIÈRES 6.1 Réactivité du système lors du signalement d une exception Respect de la contextualisation lors du signalement des exceptions Asynchronisme des communications et coordination des activités concurrentes lors d un signalement d exception Concertation d exceptions signalées par des activités concurrentes Travaux connexes Synthèse SaGE, un SGE dédié aux SMA et aux plates-formes à composants logiciels : Spécification 77 1 Introduction Hypothèses sur le contexte d application Statut des exceptions Définition et association des handlers Les handlers du langage sous-jacent Définition et association des handlers SaGE Signalement des exceptions Levée des exceptions Mécanisme de signalement Signalement des exceptions Terminaison des services Concertation d exceptions signalées par des activités concurrentes Principe général de la concertation des exceptions dans SaGE Concertation d exceptions au niveau des services Concertation d exceptions au niveau des représentants de rôles Algorithme de signalement Traitements effectués par les handlers SaGE Synthèse Conception et Implémentation 95 1 Représentation des activités individuelles et collectives Représentation des activités individuelles par des services Représentation des activités collectives par des arborescences de services Services et encapsulation Exécution concurrente des services dans les entités Traitement des requêtes groupées Les représentants de rôle Le service de Broadcasting Exemple complet d une exécution standard Le mécanisme de terminaison

8 TABLE DES MATIÈRES 1.8 Réactivité du système Implémentations de SaGE dans une plate-forme SMA Présentation de MADKit La plate-forme Les agents Gestion des communications pour SaGE Définitions des agents SaGE et de leurs services Introduction technique : Implémentation des agents dans la plateforme MADKit Implémentation des agents SaGE Implémentation des services SaGE Statut des exceptions Gestion des requêtes groupées Évaluation des résultats dans MADKit Définition des agents Concertation d exceptions Terminaison Bilan Implémentation de SaGE dans une plate-forme à base de composants logiciels Présentation de JOnAS J2EE JOnAS Les composants EJB dans JOnAS Définition des SaGEMDBs et de leurs services Les SaGEMDB Définition des services SaGE Statut des exceptions et des messages Gestion des communications par la modification du conteneurs d EJB Gestion des requêtes groupées Évaluation des résultats dans JOnAS Bilan Conclusions et perspectives Contributions Perspectives Bibliographie 139 8

9 Table des figures 2.1 Place du middleware dans les couches logicielles Description d une invocation de méthode distante avec RMI Représentation simplifiée du bus CORBA Communication synchrone entre un client et un serveur Communication asynchrone entre un client et un serveur Un exemple de commande de billet auprès d une agence de voyage Envoi asynchrone d un message à destination d une boîte aux lettres Le modèle Agent-Groupe-Rôle Exploitation de la notion de groupe dans l exemple de l agence de voyages Exemple de descripteur de déploiement XML d un serveur J2EE Structure d une application construite à base de composants logiciels Communication synchrone entre composants RRS Exemple d invocation d une méthode Java d un Session Bean Interaction de type requête/réponse et communication asynchrone entre composants RRA Traitement d un message JMS Diagramme de classes du patron ServiceActivator Communication semi-synchrone entre un client et un serveur Exemple de code Java Parallel Communication synchrone entre composants interagissant par événements Un événement déclenche l exécution de comportements Classification générale Exemple d utilisation de code de sortie en C Exemple d une procédure en C pouvant signaler une exception par une valeur de retour particulière Les trois types de modèles de SGE Exemples d exécution de procédures en programmation séquentielle Structure d un bloc de code auquel on associe des handlers en C Exemple de programme en C avec gestion d exceptions

10 TABLE DES FIGURES 3.7 Exemple d utilisation d un objet-exception encapsulant de l information en Java Différentes politiques de signalement des exceptions Utilisation de future et touch dans Multilisp Signalement des exceptions dans MultiLisp Association d un handler à une expression à évaluer en parallèle dans MultiLisp Invocation synchrone d une multi-procédure Exemple en langage Guide où les deux composantes d une activité collective sont critiques Exemple de gestion d exceptions interne et globale dans le code Java d un participant Gestion d exceptions dans un Session Bean Exemple de gestion d exceptions dans le code Java d un Session Bean Gestion d exception dans un Message Driven Bean Traitement d une erreur de délivrance de message dans le code Java d un MDB Gestion d exceptions dans des composants interagissant par événements Récapitulatif des SGE dans la programmation classique Récapitulatif des SGE dans les SMA et systèmes à composants logiciels Définition de la classe SaGEException en Java Cohabitation de SaGE et du SGE de Java Exemple en pseudo-langage d association d un handler à une requête Exemple en pseudo-langage d association d un handler à un service Exemple en pseudo-langage d association d un handler à une entité active Exemple en pseudo-langage de handler associé à un représentant de rôle Recherche de handler dans SaGE Cheminement des exceptions dans SaGE Exemple de terminaison forcée d un service pendant Exemples de résultats de concertations d exceptions Exemple en pseudo-code de fonction de concertation associée au représentant des Prestataires Définition de la primitive de signalement Définition du mécanisme de signalement (première partie) Définition du mécanisme de signalement (deuxième partie) Principe de l algorithme de signalement Exemple de définition d un service et d un service complexe en pseudo-langage Diagramme UML état-transition d un service simple SaGE Diagramme UML état-transition d un service complexe SaGE Exécution résultant d une requête à l agence de voyage Interaction transparente entre services

11 TABLE DES FIGURES 5.6 Exemple d interaction transparente Exemple de structure d une entité en pseudo-code Exemple de requêtes traitées concurremment par une agence Exemple de traitement concurrent de deux requêtes par une agence Comportement d initialisation du service de Broadcasting écrit en pseudo-langage Arborescence de services (tous services représentés) Arborescence de services (première étape) Arborescence de services (broadcasting) Arborescence de services (établissement du contrat) Exemple d échanges de messages concernant la terminaison Exemple du code Java d un agent MADKit traitant des chaînes de caractères Diagramme UML de l implémentation de SaGE dans MADKit Définition de Prestataires_RoleAgent Une fenêtre MADKit typique avec des instances de SaGEAgents Diagramme de classes de l exemple dans l implémentation de SaGE pour MADKit Exemples de concertation d exceptions Fonction de concertation associée au code Java de Prestataires_RoleAgent Handler associé au code Java de Prestataires_RoleAgent Architecture de JOnAS Exemple en code Java de méthode de sélection de service Diagramme UML de classes de l implémentation de SaGE pour JOnAS Gestion des messages JMS par le conteneur d EJB JOnAS avec SaGE

12 TABLE DES FIGURES 12

13 Chapitre 1 Introduction Sommaire 1 Contexte et objet de ce mémoire Organisation du mémoire Contexte et objet de ce mémoire Nous observons depuis quelques années une augmentation de l intérêt porté à de nouveaux paradigmes de programmation tels que les systèmes multi-agents (SMA) [Fer95] ou les plates-formes à base de composants logiciels [Szy98]. Les applications résultantes peuvent être distribuées et éventuellement faire entrer en jeu des communication asynchrones (une entité logicielle qui émet un message de manière asynchrone poursuit son exécution sans attendre la réponse correspondante). La modularité, les facilités offertes en termes de distribution et d exploitation de la concurrence constituent, entre autres, des qualités de modélisation qui se sont avérées efficaces pour construire des applications évolutives, réutilisables et exploitables sur des systèmes hétérogènes au travers de réseaux informatiques (cf. chapitre 2). Les systèmes multi-agents sont constitués d un ensemble d entités logicielles actives et indépendantes (les agents) qui interagissent dans le cadre d un environnement. Cet ensemble forme un SMA. Les agents sont développés séparément. Par ailleurs ils peuvent être introduits dans un environnement ou en être retirés dynamiquement. Enfin, ils peuvent percevoir, analyser et modifier ce dernier dans la limite de leurs aptitudes et communiquent entre eux de manière asynchrone. Une application à base de composants logiciels est constituée d un ensemble d entités logicielles (les composants logiciels) qui sont interconnectées afin de pouvoir interagir. Les composants logiciels doivent être assez génériques pour que l on puisse les intégrer dans différents environnements et contextes d utilisation en les assemblant avec d autres composants logiciels. Les composants logiciels exposent leurs fonctionnalités au travers d interfaces dédiées et peuvent communiquer avec d autres composants de manière synchrone et/ou asynchrone en fonction de leur nature. 13

14 CHAPITRE 1. INTRODUCTION Que ce soit dans le cas des SMA ou des plates-formes à composants logiciels, l indépendance des entités actives, le caractère modulaire des plates-formes, leur distribution et la possibilité de faire entrer en jeu des communications asynchrones, éventuellement dans le cadre de la programmation orientée message, constituent autant de raisons pour lesquelles il n est pas possible, dans un tel contexte, de considérer la gestion d exceptions 1 comme un problème secondaire de la spécification de tels langages (encore moins comme un mécanisme greffé à un langage au travers d une bibliothèque additionnelle). La gestion d exceptions est un dispositif-clé des langages de programmation et l évolution des paradigmes de programmation nous conduit à reconsidérer cette problématique. Dans ce mémoire, nous nous intéressons à la problématique de la gestion des exceptions dans le contexte du développement de systèmes basés sur ces nouveaux paradigmes de programmation. Nous prenons en compte les contraintes induites par l usage de tels paradigmes comme l asynchronisme des communications qui n est que partiellement supportée dans les systèmes de gestion d exceptions (SGE) existants. Les mécanismes de messagerie asynchrone permettent de développer des applications dont l activité globale est produite par l exécution d un ensemble de processus concurrents qui coopèrent par échanges asynchrones de messages (on parle de programmation orientée-message). Quand une activité est initiée par un message envoyé de manière asynchrone, le processus ayant envoyé ce message poursuit son exécution pendant que le message est traité. Un tel comportement peut être un outil de conception efficace et offrir des performances accrues. En revanche, l utilisation de mécanismes de communications asynchrones complique la gestion des interactions et, en particulier, la gestion d exceptions (cf. chapitre 3). Les mécanismes de gestion d exceptions pour les langages de programmation séquentiels sont matures et répondent bien aux attentes des programmeurs dans le cadre de ces langages. Ils sont basés sur l exploitation de la pile des appels pour rechercher un gestionnaire d exception approprié au traitement des exceptions signalées [Goo75]. Malheureusement, dans le cadre de communications asynchrones, la notion de pile des appels perd son sens au niveau global et ne peut alors plus être exploitée pour gérer les exceptions. Par exemple, en cas d occurrence d une exception dans le contexte d une activité invoquée de manière asynchrone, il est possible que l entité ayant initié l activité défaillante ne soit plus en cours d exécution et l exception ne saurait alors être notifiée à cette dernière. Il se pose donc le problème de la diffusion des exceptions : à quelles entités et dans quel ordre? Ayant dégagé un ensemble de critères qualitatifs permettant de juger l efficacité et la validité d un système de gestion d exceptions, nous y avons confronté les différents types de SGE existants. Cette étude révèle les limites de ces derniers dans le contexte des nouveaux paradigmes de programmation quand des communications asynchrones entrent en jeu. Dans cette thèse, notre contribution se présente sous la forme d un système de gestion d exceptions dédié à ces nouveaux paradigmes de programmation. Ce système, baptisé SaGE (Système avancé de 1 Une exception indique l occurrence d une situation dans laquelle l exécution standard d un code ne peut se poursuivre. On peut prendre l exemple classique de la division par zéro. 14

15 2. ORGANISATION DU MÉMOIRE Gestion d Exceptions) propose des solutions à un ensemble de problèmes que nous recensons en nous appuyant notamment sur des travaux sur la gestion d exceptions en milieu concurrent (cf. chapitre 4). De notre point de vue, les possibilités offertes par un langage en termes de gestion d exceptions sont cruciales pour permettre la réalisation de systèmes fiables dans de tels paradigmes de programmation. Pour être adapté à ces derniers, nous considérons qu un système de gestion d exceptions doit présenter trois qualités essentielles : Respecter le paradigme dans lequel il est exploité, Gérer la concurrence, et Gérer les coopérations entre entités logicielles. Par ailleurs, la structure de l environnement d exécution a un impact significatif sur le traitement des exceptions. Comme nous l avons vu plus haut, c est l absence d une représentation globale de l exécution (on n a que des piles des appels isolées) qui pose problème dans la gestion d exceptions lorsque les entités actives s exécutent de manière concurrente en communiquant de manière asynchrone. C est pourquoi, dans nos travaux, nous avons été amenés à définir une notion de service permettant la représentation des activités globales pour pouvoir traiter efficacement les exceptions dans ces nouveaux paradigmes de programmation. C est sur ce point que nous faisons face à une contradiction. D une part, pour assurer l indépendance d entités actives concurrentes, il faut les isoler. D autre part, pour représenter les coopérations entre entités actives, il faut définir des moyens d interaction et des liens entre ces dernières (cf. chapitre 5). Nous avons donc dû définir un modèle qui permette à des entités isolées d échanger des informations leur permettant de coopérer (requêtes, réponses, notification d exceptions) tout en respectant le paradigme utilisé et l intégrité du système (isolation des threads). 2 Organisation du mémoire Outre cette introduction, ce mémoire de thèse est organisé en 5 autres chapitres : Le chapitre 2 présente le contexte de notre étude, c est-à-dire les paradigmes de programmation des systèmes multi-agents et des plates-formes à composants logiciels. Après avoir vu leurs spécificités communes, nous nous intéressons aux divers modes de communication et d interaction entre entités logicielles que l on peut observer et à leur éventuel impact sur la concurrence entre ces dernières. Par la suite, nous voyons plus en détails ce que sont les systèmes multi-agents et les plates-formes à base de composants logiciels. Le chapitre 3 fait un tour d horizon de l existant en matière de gestion des exceptions. Tout d abord nous y présentons les motivations qui ont mené à la spécification de systèmes de gestion d exceptions (SGE) pour ensuite voir comment ces principes se sont appliqués dans la programmation classique, qu elle soit séquentielle ou concurrente, puis dans les nouveaux paradigmes de programmation qui nous intéressent. Nous présentons ensuite un ensemble de 15

16 CHAPITRE 1. INTRODUCTION critères qualitatifs relatifs à la gestion d exceptions que nous considérons comme indispensables à la définition d un système de gestion d exceptions répondant aux attentes et besoins des programmeurs dans le contexte des paradigmes de programmation auxquels nous nous intéressons. Enfin, nous concluons ce chapitre par une synthèse mettant en évidence les lacunes des systèmes de gestion d exceptions existants au regard des critères qualitatifs pré-cités et établissons en conséquence un cahier des charges pour notre proposition. Le chapitre 4 présente la spécification de notre proposition : SaGE (Système avancé de Gestion d Exceptions) [SDUV03, SUVD03, SDUV04, SVUD04], un système de gestion d exceptions dédié aux systèmes multi-agents et aux plates-formes à base de composants logiciels. Il couvre les problématiques et les besoins identifiés dans le chapitre précédent. Ce chapitre présente une vision générique de notre proposition pour la programmation orientée message. Le chapitre 5 présente comment nous avons conçu SaGE puis comment nous l avons implémenté dans deux plates-formes. Notre première expérimentation, dans le cadre des systèmes multi-agents, a été implémentée [SDUV03, SDUV04, SVUD04] pour la plate-forme SMA MADKit (Multi-Agent Development Kit) [vd04]. Puis, nous présentons notre expérimentation, dans le cadre des plates-formes à base de composants logiciels [SUVD03], pour la plate-forme JOnAS [JOn04] (Java Open Application Server), une plate-forme libre implémentant les EJB (Enterprise JavaBeans) de J2EE (Java2 Enterprise Edition) [Sun04a, Sun03]. Enfin, le chapitre 6 conclut ce mémoire en établissant un bilan des contributions apportées et en présentant des perspectives pour ces travaux. 16

17 Chapitre 2 Contexte d étude : les programmations par agents et par composants Sommaire 1 Les middlewares : une solution aux limites de la programmation distribuée classique Définition Les modes de communication dans les applications Concurrence et asynchronisme Possibilité de définir des activités concurrentes Coordination des activités concurrentes Les Systèmes Multi-Agents, un exemple typique de la programmation orientée message Introduction et définitions Les sociétés d agents L exemple des agences de voyage dans un système multi-agents : choix de modélisation Les plates-formes à base de composants logiciels Introduction et définitions Typologie des modes d interaction L exemple des agences de voyage dans une plate-forme à base de composants logiciels : choix de modélisation Conclusion Les systèmes multi-agents et les plates-formes à base de composants logiciels prennent une place grandissante dans le monde des systèmes distribués grâce au niveau d abstraction qu ils offrent (possibilités de communiquer entre systèmes hétérogènes, abstraction de la distribution et réutilisabilité). 17

18 CHAPITRE 2. CONTEXTE D ÉTUDE : LES PROGRAMMATIONS PAR AGENTS ET PAR COMPOSANTS En effet, l augmentation de la taille du code des logiciels, le besoin de fiabilité et la volonté de diminuer les coûts ont contribué à orienter la pratique industrielle et la recherche en génie logiciel vers la spécification d entités logicielles de plus en plus réutilisables : les librairies puis les objets et, de nos jours, les agents et composants logiciels [Woo02, WC99, Szy98]. 1 Les middlewares : une solution aux limites de la programmation distribuée classique 1.1 Définition Dans les systèmes multi-agents comme dans les plates-formes à composants logiciels, les entités logicielles entrant en jeu (instances de classes, agents, composants, applications... ) communiquent par l intermédiaire d une couche logicielle commune : l intergiciel ou middleware. Définition : Le terme middleware désigne le bus de communication qui s interpose entre les couches du système d exploitation et celles des logiciels qu il exécute (cf. figure 2.1). Le middleware assure les communications entre applications (éventuellement distantes) en faisant abstraction de l hétérogénéité des systèmes impliqués en termes d architecture physique des processeurs, de système d exploitation, de langage de programmation utilisé et de représentation des données [WSPK01, Hal00, Pes00]. FIG. 2.1 Place du middleware dans les couches logicielles Les entreprises exploitent de multiples applications qui ont été construites indépendamment en utilisant divers langages et diverses plates-formes. Ces applications ont toutefois besoin d échanger des données et des services. Pour ce faire, les transferts de fichiers et les bases de données partagées sont exploités mais ces solutions restent souvent insuffisantes. En effet, les modifications de données peuvent nécessiter que des opérations de maintien de la cohérence des données soient exécutées dans plusieurs applications concernées. Il faut alors un mécanisme permettant à une application d invoquer une fonctionnalité d une autre application en lui communiquant l identifiant ou la description de la fonctionnalité souhaitée et les valeurs et paramètres correspondants. De plus, dans la mesure où les 18

19 1. LES MIDDLEWARES : UNE SOLUTION AUX LIMITES DE LA PROGRAMMATION DISTRIBUÉE CLASSIQUE applications en interaction peuvent ne pas être exécutées sur la même machine, le mécanisme d invocation de méthodes doit offrir l abstraction de la distribution des applications impliquées. C est ce que permettent, par exemple, les mécanismes de Remote Procedure Call (RPC). Avec de tels mécanismes, les applications peuvent fournir de multiples interfaces pour une même fonctionnalité afin de permettre l interopérabilité avec des clients hétérogènes et éventuellement distants. Par exemple, la solution Java RMI (Remote Method Invocation) [Gro01] de Sun pour l invocation distante de méthodes Java est incluse par défaut dans J2SE (Java2 Standard Edition) [Sun04b] depuis sa version 1.1. RMI est un mécanisme de RPC (Remote Procedure Call) dédié aux objets Java, dans le cadre duquel des interfaces spécifiques, appelées interfaces distantes, définissent les fonctionnalités des objets accessibles à des objets distants. Pour masquer les sérialisation/désérialisation 1 (marshalling/unmarshalling) des données transportées et les communications distantes, RMI génère, pour chaque interface distante définie, une classe souche (stub) côté client et une classe squelette (skeleton) côté serveur comme présenté en figure 2.2. Dans cette dernière, on observe le déroulement d une invocation de méthode distante au travers de RMI. Un client récupère auprès du serveur de nommage RMI correspondant une référence vers un objet représentant (proxy) l objet distant avec lequel on souhaite interagir (1-2). Cet objet représentant est une instance de la classe souche correspondant au type (interface distante) de l objet distant. L invocation d une méthode de l objet représentant génère un message de requête contenant le nom de la méthode invoquée et la valeur des paramètres d appel (sérialisation). Cette requête est transmise, côté serveur, à une instance de la classe squelette correspondante (3) qui est capable d extraire du message le nom de la méthode invoquée ainsi que la valeur des paramètres d appel (désérialisation). L instance de la classe squelette délègue alors l exécution de la méthode à l objet distant auquel elle est associée (4). Elle récupère alors la valeur de retour ou l exception générée par l exécution de la méthode invoquée et sérialise cette réponse pour la transmettre à l objet client qui la récupère par l intermédiaire de la classe souche utilisée (5-6). Avec RMI : Les paramètres de types simples (int, float,...) sont transmis par copie, Les paramètres de type objet non défini par une interface distante sont sérialisés et transmis par copie, Les paramètres de type objet distant sont transmis par référence. Un middleware doit reposer sur des standards communs pour garantir l interopérabilité des applications en interaction. A titre d exemple, CORBA (Common Object Request Broker Architecture) [Sie00], défini par l OMG (Object Management Group) [otomg] est un middleware de communication multi-systèmes d exploitation et multi-langages qui offre, grâce au langage IDL 2 (on retrouve 1 La sérialisation est un mécanisme qui permet de représenter un objet à envoyer comme paramètre dans le cadre d une invocation de méthode distante sous une forme transportable (chaîne de bytes) pour le middleware utilisé. La désérialisation est le mécanisme inverse qui permet de reconstruire, à partir des données transmises par le middleware, une copie locale de l objet attendu. 2 Interface Definition Language, qui est exploitable dans tout langage de programmation offrant une connectivité au bus logiciel CORBA. 19

20 CHAPITRE 2. CONTEXTE D ÉTUDE : LES PROGRAMMATIONS PAR AGENTS ET PAR COMPOSANTS FIG. 2.2 Description d une invocation de méthode distante avec RMI les mêmes qualité avec RMI) : La transparence de localisation et d accès : possibilité d utiliser des objets indépendamment de leur localisation grâce à des représentations par proxy des objets distants. Le programmeur peut alors exploiter les méthodes des objets distants comme si ces derniers étaient locaux en exploitant les ORBs (Object Request Broker) disponibles sur le bus CORBA comme présenté en figure 2.3. La séparation des interfaces et des implémentations : les clients sont définis uniquement en fonction des interfaces IDL mises à disposition du middleware et non pas en fonction des implémentations de la couche applicative. On assure ainsi l interopérabilité entre, par exemple, des éléments d applications développés séparément. FIG. 2.3 Représentation simplifiée du bus CORBA 20

21 1. LES MIDDLEWARES : UNE SOLUTION AUX LIMITES DE LA PROGRAMMATION DISTRIBUÉE CLASSIQUE De tels systèmes assurent une totale transparence de la distribution sans pour autant assurer l interopérabilité de manière systématique. Par exemple, si CORBA [Sie00] autorise les interactions entre entités logicielles développées dans des langages différents, ce n est pas le cas de RMI qui ne concerne que Java. La transparence de la distribution étant assurée par l ensemble des middlewares, nous ne prendrons plus en compte la problématique de la distribution des applications dans la suite de ce mémoire. 1.2 Les modes de communication dans les applications Les middlewares, en fonction de leur spécification, permettent des communications entre entités logicielles synchrones, ou asynchrones (ou les deux modes de communication). Définition : on parle de communication synchrone entre entités logicielles quand, suite à l envoi d un message par une entité logicielle A, son exécution est bloquée jusqu à ce que l entité logicielle destinataire B ait fini de traiter le message avec un éventuel renvoi de réponse (cf. Figure 2.4). Ce mode de communication n induit pas de concurrence et on le trouve dans les langages les plus courants comme Java et C++. Client Server Entité logicielle exécutable Invocation Retour Communication Exécution de code Attente du retour FIG. 2.4 Communication synchrone entre un client et un serveur Bien qu un mécanisme de type RPC abstraie la distribution, les accès distants par ce biais sont plus lents et moins fiables que s ils étaient réellement locaux. Or, quand de multiples applications d une entreprise communiquent, il n est pas souhaitable que la défaillance de l une d entre elles paralyse tout le système. Pour assurer fiabilité, performance et évolutivité, il est donc nécessaire d assurer un fort découplage entre applications distribuées. Les mécanismes de messagerie asynchrone sont alors une solution pragmatique à ce problème. Définition : on parle de communication asynchrone entre deux entités logicielles quand l envoi d un message ne bloque pas l exécution de son émetteur pendant qu il est traité par son destinataire [JS96, YBS86, YT87, Car93]. Dans les middlewares, la communication asynchrone est qualifiée d interaction par messagerie ou de programmation orientée message (MOM : Message-Oriented Middleware) comme présenté en figures 21

22 CHAPITRE 2. CONTEXTE D ÉTUDE : LES PROGRAMMATIONS PAR AGENTS ET PAR COMPOSANTS Client Message Server Entité logicielle exécutable Communication Exécution de code FIG. 2.5 Communication asynchrone entre un client et un serveur 2.5 et 2.7. Ce mécanisme induit de la concurrence dans les systèmes qui l utilisent car l émetteur d un message poursuit son exécution pendant que ce dernier est traité par son destinataire. Cette pratique permet par ailleurs de découpler les entités logicielles. En effet, dans la mesure où les communications asynchrones ne nécessitent pas d édition de liens à la compilation, la phase de développement des entités logicielles et la phase de leur intégration pour produire une application sont indépendantes [Sun02]. Le principal biais induit par l utilisation de communications asynchrones est que les tâches de tests et de corrections deviennent plus fastidieuses qu avec des applications qui s exécutent séquentiellement et que le programmeur peut faire face à des problèmes de nondéterminisme [CHS04]. Par exemple, pour debugguer une application codée en C++, le développeur a accès à la pile d exécution qui représente l état global de l exécution alors que cet outil n existe pas si on utilise un MOM. Même dans le cadre de communications asynchrones, il se peut que le programmeur souhaite définir des interactions dans lesquelles une entité logicielle émet une demande pour laquelle elle attend une réponse, à l image des valeurs de retour des méthodes. On parle alors de communication semisynchrone. Dans ce contexte, une fois que le point d exécution au niveau duquel l émetteur d une demande a besoin de la réponse est atteint, un mécanisme de futur [BBP86, LAB + 78, Lis88] est utilisé pour interrompre l exécution de l émetteur jusqu à ce que la réponse nécessaire à la poursuite de son exécution soit obtenue. Définition : On parle de futur explicite quand, pour interrompre l exécution d une entité logicielle qui a émis une requête de manière asynchrone jusqu à réception de la réponse correspondante, une fonction d attente dédiée est utilisée. On peut prendre l exemple de la fonction d attente touch de Multilisp [HL85] (cf. section du chapitre 3 et figure 3.9). Définition : On parle de futur implicite quand, pour interrompre l exécution d une entité logicielle qui a émis une requête de manière asynchrone jusqu à réception de la réponse correspondante. Par exemple, un mécanisme de synchronisation transparent peut être mis en œuvre lors de la tentative d accès à la valeur de la réponse correspondante. 22

23 2. CONCURRENCE ET ASYNCHRONISME Dans tout les cas, l utilisation de communications asynchrones permet d introduire de la concurrence car l émetteur d un message peut poursuivre son exécution parallèlement à celle du traitement de ce message par son destinataire. Dans certains MOMs [DF94, FG98, vd04, Sun03], un message peut-être envoyé non seulement à une entité destinataire unique, mais aussi à un groupe d entités destinataires 3. Dans ce dernier cas, on parle de diffusion groupée (broadcasting) et le message émis de la sorte est diffusé de manière transparente à l ensemble des entités membres du groupe destinataire. Il est par ailleurs possible que l émetteur d un tel message ne connaisse ni l identité ni le nombre de ces derniers. Si le message émis est une requête, on parle alors de requête groupée. 2 Concurrence et asynchronisme 2.1 Possibilité de définir des activités concurrentes Les paradigmes de programmation que nous étudions permettent : des accès concurrents à des entités partagés (le code d une entité pourra être exécuté concurremment par plusieurs threads d exécution), d utiliser des communications asynchrones (qui permettent à une entité active de poursuivre son exécution pendant que d autres traitent des requêtes qu elle leur a soumises), d exécuter des traitements concurrents au sein d une même entité logicielle active (une entité active peut en effet se voir affecter la gestion de plusieurs threads d exécution). Ces possibilités offrent des opportunités pour le développement d applications dans lesquelles il s avère souhaitable d exécuter des traitements concurremment. La concurrence permet le développement d applications plus évoluées. Elle peut en effet : offrir un gain en terme de temps d exécution en exploitant parallèlement plusieurs ressources de calcul, permettre la définition de politiques de traitement des réponses plus évoluées, rendre le système plus réactif (disponibilité) que dans une application purement séquentielle. On peut illustrer ces faits en prenant l exemple d une application que nous réutiliserons tout au long de ce mémoire : un logiciel de réservation pour agences de voyages. En voici une présentation générique qui fait abstraction du paradigme utilisé. Dans cette application, trois types d entités entrent en jeu : une agence de voyages qui travaille en relation avec un ensemble de prestataires pour répondre aux demandes émises par des clients. Voici un scénario d exécution classique (cf. Figure 2.6) : Un client demande un billet d avion à l agence de voyage (1) qui demande alors leurs tarifs aux prestataires de service avec lesquels elle travaille (2-3). Elle sélectionne ensuite le prestataire le plus 3 On peut rapprocher cette vision de la notion de groupes d objets (Object Groups) [PJA01]. 23

24 CHAPITRE 2. CONTEXTE D ÉTUDE : LES PROGRAMMATIONS PAR AGENTS ET PAR COMPOSANTS économique pour communiquer son identité et son tarif au client demandeur (4) et avertit le prestataire retenu qu il doit préparer un contrat (5). Enfin le client demandeur entre en contact avec le prestataire sélectionné pour valider le contrat (6). FIG. 2.6 Un exemple de commande de billet auprès d une agence de voyage Si l on s intéresse à une application de la concurrence dans un tel exemple, il est souhaitable que l agence de voyage puisse envoyer concurremment les demandes de tarifs auprès des prestataires qu elle connaît. Tout d abord, sur le plan du temps d exécution, le gain est évident car : Si les communications étaient synchrones, il faudrait que l agence de voyage attende, pour chaque prestataire, qu il traite la demande et retourne sa réponse. Dans ce cas, le temps de réponse global est la somme des temps de réponse individuels des prestataires (t = n i=0 t i ). Si l agence de voyage communique avec les prestataires par des communications asynchrones, les ressources des prestataires seront exploitées concurremment. Dans ce cas, le temps de réponse global est théoriquement celui du prestataire qui met le plus de temps à répondre (t = max n i=0 t i). D autre part, le programmeur se voit pourvu d un pouvoir d expression plus complet qu en programmation séquentielle car il va pouvoir définir des comportements spécifiques pour le traitement des réponses reçues. Si on reprend l exemple des demandes de tarifs émises par l agence de voyages auprès des prestataires de service, on peut imaginer des comportements spécifiques comme : Attendre les réponses des prestataires dans la limite d un délai donné ou Se contenter des réponses déjà reçues une fois un niveau de représentativité ou de qualité de service (QoS) donné atteint [Hal00, HHRS01, WSPK01, XNVW00]. Ce genre de politique peut être défini, par exemple, à des 24

25 2. CONCURRENCE ET ASYNCHRONISME fins d optimisation en termes de temps ou de trafic réseau. Enfin, la concurrence peut apporter un gain en termes de réactivité et de disponibilité car elle peut être exploitée pour permettre à une entité logicielle de traiter concurremment plusieurs requêtes. Par exemple, l agence de voyage doit pouvoir traiter concurremment plusieurs requêtes émises par des clients afin de répondre plus rapidement à ces derniers. En effet, si l agence de voyage traitait les requêtes des clients séquentiellement, du temps d exécution serait perdu, entre les traitements de chaque requête émise par un client, durant la phase d attente des réponses des prestataires. 2.2 Coordination des activités concurrentes La programmation de systèmes concurrents a toujours posé le problème de la coordination (souvent appelée synchronisation) des processus concurrents [BBP86, JS96, Lac90, Lis88] pour assurer, par exemple, la cohérence des données, la possibilité d exploiter des mécanismes transactionnels ou même pour optimiser l exploitation de ressources. Dans [RK01], ALEXANDER ROMANOVSKY et JÖRG KIENZLE proposent une classification qui distingue trois types de gestions de la concurrence qui peuvent être mis en place dans des systèmes orientés-objets. Dans ce contexte, processus et objets sont orthogonaux : Les objets sont vus comme des entités passives dont le code est exécuté par des processus qui leurs sont extérieurs. Tout d abord, la concurrence disjointe désigne le type de concurrence que l on trouve dans les systèmes n offrant pas d outils pour coordonner les activités concurrentes. Il est alors difficile de garantir, par exemple, la cohérence des objets partagés. Ensuite, la concurrence compétitive désigne le type de concurrence que l on trouve dans les systèmes gérant l isolation des entités actives (les processus dans le contexte des systèmes à objets ou les agents dans le cadre d un système multi-agent). Ces systèmes fournissent des mécanismes permettant d éviter les incohérences dues à l usage concurrent de ressources partagées. Ce type de gestion de la concurrence est mis en place grâce à des mécanismes de verrous [BCF + 97] qui permettent de garantir l isolation (c est-à-dire l indépendance) d opérations travaillant sur les mêmes données. Enfin, la concurrence coopérative désigne la gestion de la concurrence par les systèmes qui permettent la gestion de la collaboration entre entités actives. Il s agit alors de coordonner des activités concurrentes qui contribuent à une même activité collective. En particulier, gérer la concurrence coopérative requiert un modèle d exécution qui autorise la représentation explicite des activités collectives et donc de l imbrication des activités pour pouvoir gérer les contextes de ces collaborations : Pour chaque activité, il doit être possible de connaître l activité qui l a sollicitée et les activités qu elle a requises. Cette pratique permet la définition d outils de synchronisation des activités pour, par exemple, interrompre l ensemble des activités qui ont été directement ou indirectement sollicitées par une activité dont l exécution est interrompue. 25