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.

Présentation au sujet: "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."— Transcription de la présentation:

1 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

2 Rennes, le 18 septembre 2006 2 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

3 Rennes, le 18 septembre 2006 3 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,...

4 Rennes, le 18 septembre 2006 4 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

5 Rennes, le 18 septembre 2006 5 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

6 Rennes, le 18 septembre 2006 6 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.

7 Rennes, le 18 septembre 2006 7 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

8 Rennes, le 18 septembre 2006 8 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; }

9 Rennes, le 18 septembre 2006 9 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

10 Rennes, le 18 septembre 2006 10 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

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

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

13 Rennes, le 18 septembre 2006 13 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

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

15 Rennes, le 18 septembre 2006 15 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

16 Rennes, le 18 septembre 2006 16 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

17 Rennes, le 18 septembre 2006 17 Projection sur CCM

18 Rennes, le 18 septembre 2006 18 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

19 Rennes, le 18 septembre 2006 19 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

20 Rennes, le 18 septembre 2006 20 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

21 Rennes, le 18 septembre 2006 21 Utilisation de DIET (stage)

22 Rennes, le 18 septembre 2006 22 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»

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

24 Rennes, le 18 septembre 2006 24 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

25 Rennes, le 18 septembre 2006 25 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»

26 Rennes, le 18 septembre 2006 26 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

27 Rennes, le 18 septembre 2006 27 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