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 2006

Support du paradigme maître-travailleur dans les

applications à base de composants

Tâche 2.2

Hinde BouzianeRéunion LEGO

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 d’un modèle générique– Composition abstraite– Intégration d’un mécanisme de transfert de requêtes

• Cas d’étude: modèle de composants CORBA et DIET• Conclusions et perspectives


Paradigme maître-travailleur

worker

worker

worker

Masterworker

Workers collectionRequests transport

SchedulingFault tolerance

• Plusieurs calculs simultanés et indépendants (boucle ~ForAll)• Environnements/API dédiés

– BOINC, XTremWEB, – DIET, NetSolve, Nimrod/G, ...


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

ConvectionDispersionAqueous Reactions

Gaz-liquid exchange Dissolution

Biology

Applications multi-paradigmes!!!

Hydrologie


Vers la programmation à base de composants

• Challenges – Simplifier la structure et la programmation– Indépendance du type de ressources

d’exécution• Processeurs multi-core• Machines SMP• Clusters• Grilles

u

Modèles de composants



Composantlogiciel

PORTSFOURNI

PORTSREQUIS

(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.



• Assemblage/composition– Instances de composants et

connexions– Architecture Description

Language (ADL)• CCM, Fractal

– Dynamique• CCA, CCM, Fractal

• Déploiement– Installation– Configuration

• Connexions

ADLinstanceComp:

a: A, b: B, c: C, d: D;connections:

a.pA1 <-> b.pB;c.pC <-> d.pD2;d.pD1 <-> a.pA2;

a

b

c

pA1pB

pC

pD2

dpD1

pA2


Exemple d’application 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) {

// computationreturn res;

}


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

d’ordonnancement

WWworkermaster

mastertransp.

req.WWworker

• A la charge du programmeur– Complexe– Non transparence

master

WWworker

WWworker


Objectifs

• Indépendance de toute infrastructure de ressources• Transparence

– Gestion du nombre de travailleurs– Gestion du transport des requêtes et ordonnancement

• A l’initiative du système– Adaptation du nombre de travailleur au ressources

utilisées – Choix d’une politique d’ordonnancement

• Réutilisation des environnements maître-travailleur existant


Notre modèle générique


Idée générale

Round-Robin

Deploymentenvironment

Système(framework) Round-Robin


Collection de composants

Port fourni exposé

worker

W1 Wn W2 Wi

Collection à l’exécution

Instanciation

Type1 Type3Type2 Type1 T1x Type2 T2y T2y

Type3Type3 T3z

Instanciation

Définition d’une collection


Assemblage abstrait

Composition de composants avec collections

≈

Composition de composants

m

Type1 Type3Type2

X


Assemblage abstrait -> assemblage concret

Vue programmeur

Collection

binding

master

worker

Exposed provided port

Round-Robin

Vue système/plateforme

Resourcesinfrastructure

#workers+

Pattern selection

Set of request transport mechanism patterns

1. Random2. Round-Robin3. NetSolve4. Diet


Patrons de transport de requêtes

w w w

M

Round-Robin / Random

LA

LALA

M

w w w

MA

MAMA

Patron a base de composant

Ordonnancement hiérarchique

Patron DIET

M

Random

w w

Round-Robin Round-Robin

w w


Projection sur CCM


Extension de CCM

• Spécification– Définition des composants

maître et travailleur• Interface Description

Language (IDL3)

• Définition d’une 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

<element type=“worker"/><binding><externPort portRef=“c_port"/> <internPort elemType=“worker“ port=“w_port"/></binding>

master

worker

w_port

m_port


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) {

// computationreturn res;

}

• Pas d’impacte sur l’implémentation


Assemblage abstrait vers assemblage concret

• Assemblage abstrait – Extension de la DTD de l’ADL 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


Utilisation de DIET(stage)


Intégration de Diet (1/2)

LALA 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»


• Optimiser les indirections• Génération automatique des entités «glue»

– A partir des prototypes de fonction (IDL3)

Questions ouvertes (1/2)

MA


• 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)

LALA LA

MA


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 d’une

politique de transport de requêtes par le système• Niveau d’abstraction plus élevé

– Collections, ADL abstrait, patrons• Support manuel de Diet

– Entités «glue»


Perspectives

• Mesures de performance– En déduire le type d’application à 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


• 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

Documents

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