Rennes, le 18 septembre 2006 Support du paradigme maître-travailleur dans les applications à base de composants Tâche 2.2 Hinde Bouziane Réunion LEGO

Rennes, le 18 septembre Plan Contexte –Paradigme maître-travailleur –Modèles de composants Applications maître-travailleur et modèles de composants –Limitations des modèles de composants existants Proposition dun modèle générique –Composition abstraite –Intégration dun mécanisme de transfert de requêtes Cas détude: modèle de composants CORBA et DIET Conclusions et perspectives

Rennes, le 18 septembre Paradigme maître-travailleur worker Master worker Workers collection Requests transport Scheduling Fault tolerance Plusieurs calculs simultanés et indépendants (boucle ~ForAll) Environnements/API dédiés –BOINC, XTremWEB, –DIET, NetSolve, Nimrod/G,...

Rennes, le 18 septembre Caractéristiques des environnements maître-travailleur Scalables Politiques de transfert de requêtes Gestion transparente du transport des requêtes API Dédiées Seul le paradigme maître-travailleur est supporté u PrecipitationSorption Relargage Convection Dispersion Aqueous Reactions Gaz-liquid exchange Dissolution Biology Applications multi-paradigmes!!! Hydrologie

Rennes, le 18 septembre Vers la programmation à base de composants Challenges –Simplifier la structure et la programmation –Indépendance du type de ressources dexécution Processeurs multi-core Machines SMP Clusters Grilles u Mod è les de composants

Rennes, le 18 septembre Modèles de composants Composant logiciel PORTS FOURNI PORTS REQUIS (interfaces client) (interfaces serveur) Boite noire Ports –Invocation de méthodes, événement/messages/streams Plusieurs modèles de composants –CORBA Component Model/OMG (CCM) –Common Component Architecture/CCA Forum (CCA) –Fractal/ObjectWeb –Etc.

Rennes, le 18 septembre Modèles de composants Assemblage/composition –Instances de composants et connexions –Architecture Description Language (ADL) CCM, Fractal –Dynamique CCA, CCM, Fractal Déploiement –Installation –Configuration Connexions ADL instanceComp: a: A, b: B, c: C, d: D; connections: a.pA1 b.pB; c.pC d.pD2; d.pD1 a.pA2; a b c pA1 pB pC pD2 d pD1 pA2

Rennes, le 18 septembre Exemple dapplication maître-travailleur master interface Compute { long f (in long value); } ; Master: ForAll i= 0 to N { call f (..) on a worker through yellow port; } worker Worker: long f (long value) { // computation return res; }

Rennes, le 18 septembre Limitations des modèles de composants Différente infrastructures –Multi-core, SMP, clusters, grilles, etc. Propriétés dépendantes des ressources –Nombre de travailleurs –Transport de requêtes et politique dordonnancement W W worker master transp. req. W W worker A la charge du programmeur –Complexe –Non transparence master W W worker W W

Rennes, le 18 septembre Objectifs Indépendance de toute infrastructure de ressources Transparence –Gestion du nombre de travailleurs –Gestion du transport des requêtes et ordonnancement A linitiative du système –Adaptation du nombre de travailleur au ressources utilisées –Choix dune politique dordonnancement Réutilisation des environnements maître-travailleur existant

Rennes, le 18 septembre Notre modèle générique

Rennes, le 18 septembre Idée générale Round-Robin Deployment environment Système (framework) Round-Robin

Rennes, le 18 septembre Collection de composants Port fourni exposé worker W1 Wn W2 Wi Collection à lexécution Instanciation Type1Type3 Type2 Type1 T1x Type2 T2y Type3 T3z Instanciation Définition dune collection

Rennes, le 18 septembre Assemblage abstrait Composition de composants avec collections Composition de composants m Type1Type3 Type2 X

Rennes, le 18 septembre Assemblage abstrait -> assemblage concret Vue programmeur Collection binding master worker Exposed provided port Round-Robin Vue système/plateforme Resources infrastructure #workers + Pattern selection Set of request transport mechanism patterns 1.Random 2.Round-Robin 3.NetSolve 4.Diet

Rennes, le 18 septembre Patrons de transport de requêtes w w w M Round-Robin / Random LA M w w w MA Patron a base de composant Ordonnancement hiérarchique Patron DIET M Random w w Round-Robin w w

Rennes, le 18 septembre Projection sur CCM

Rennes, le 18 septembre Extension de CCM Spécification –Définition des composants maître et travailleur Interface Description Language (IDL3) Définition dune collection en 2 étapes –Vue externe: extension IDL3 –Contenu et bindings: Collection Description Language (CDL) en format XML interface Compute {..} ; component master { uses Compute m_port; }; component worker { provides Compute w_port; }; collection coll { provides Compute c_port; }; c_port worker <internPort elemType=worker port=w_port"/> masterworker w_port m_port

Rennes, le 18 septembre Implémentation des composants master interface Compute { long f (in long value); } ; Master: ForAll i= 0 to N { call f (..) on a worker through yellow port; } worker Worker: long f (long value) { // computation return res; } Pas dimpacte sur limplémentation

Rennes, le 18 septembre Assemblage abstrait vers assemblage concret Assemblage abstrait –Extension de la DTD de lADL de CCM Assemblage abstrait -> assemblage concret –Actuellement Manuellement : transformation de documents XML –Future Outil de déploiement ADAGE (plugin) –Entrées ADL abstrait sous format XML Patrons de politique de transport de requêtes –Sortie ADL concret sous format XML prêt à être déployé Round-Robin

Rennes, le 18 septembre Utilisation de DIET (stage)

Rennes, le 18 septembre Intégration de Diet (1/2) LA MA maître glue client / client Diet glue serveur / serveur Diet travailleurs Objectif –Transfert des requêtes avec Diet –API Diet transparente au programmeur Idée –Coté maître Traduire un appel de méthode sur un port en une requête Diet –Coté travailleur (le contraire) Une proposition –Pseudo composants «glue»

Rennes, le 18 septembre Optimiser les indirections Génération automatique des entités «glue» –A partir des prototypes de fonction (IDL3) Questions ouvertes (1/2) MA

Rennes, le 18 septembre Déploiement –Intégration ADAGE + GoDiet –Entrée Description du patron associé à la structure de Diet –ADL concret Encapsuler les entités DIET dans des composants ADL multi-entités : composants, processus, etc. Questions ouvertes (2/2) LA MA

Rennes, le 18 septembre Conclusions Améliorer le support du paradigme maître- travailleur dans les modèles de composants –Indépendance des ressources –Adaptation du nombre de travailleurs et choix dune politique de transport de requêtes par le système Niveau dabstraction plus élevé –Collections, ADL abstrait, patrons Support manuel de Diet –Entités «glue»

Rennes, le 18 septembre Perspectives Mesures de performance –En déduire le type dapplication à cibler Etude de la dynamicité: ajout de travailleurs (en cours B. Daix) –Support dans ADAGE Répondre aux questions ouvertes, principalement sur le déploiement

Rennes, le 18 septembre Intégration ADAGE + GoDiet Description du patron associé à la structure de Diet ADL concret –ADL multi-entités : composants, processus, etc. –Encapsuler les entités DIET dans des composants Autres –Optimiser les indirections –Génération automatique des entités «glue» A partir des prototypes de fonction (IDL3) Questions ouvertes MA