Françoise André IRISA/Université Rennes1 Responsables du contrat :

1. Françoise André IRISA/Université Rennes1 Responsables du contrat : Jean-Marie Gilliot, Maria -Teresa Segarra GET / ENST-Bretagne/ Département Informatique ReCoDEM :Réplication et Cohérence de Données en Environnement MobileContrat Orange FT R&D / ENST Bretagne

2. Problématique, objectifs • Éléments du service statique • Architecture pour l'adaptation dynamique distribuée • Conclusion Plan

3. Problématique : Application Orange FTR&D • Service de gestion de données multi-utilisateurs et multi-terminaux • Partage de données entre communautés • Adaptation des données aux terminaux • en environnement multi-réseaux, fixes et mobiles (réseau cœur opérateur + « satellites »)‏ • Réplication des données (avec cohérence) pour accès rapides et disponibilité (déconnexions terminaux) • Adaptation dynamique aux réseaux Adaptation “statique” Réplication et Adaptation Dynamique

4. PortableChloé Environnement Réseau cœur de l’opérateur ADSL GPRS Smart phone Raphaël PC maison Smart phone Karine Réseau Wi-Fi maison

5. PortableChloé Scénario Réseau cœur de l’opérateur ADSL Réplique sans photo GPRS Réplique avec photo PC maison Smart phone Raphaël Réseau Wi-Fi maison

6. ReCoDEM • Utiliser la réplication pour la disponibilité et pour diminuer temps d'accès • Service de placement des répliques • Service d’accès aux répliques • Service de cohérence • Adaptation dynamique en fonction des • ressources disponibles (réseaux et terminaux)‏ • ex. si chute de bande passante, passer d'un protocole de cohérence forte à un protocole de cohérence faible • ex. adapter format photos sur PDA • « nature » des données • ex. pas de réplication d'un compte bancaire sur terminal cyber-café

7. Démarche • Expression du contexte requis/fourni pour la réplication • Caractérisation des diverses implantations des services de réplication en fonction du contexte • Architecture pour l'adaptation dynamique • Architecture logicielle (à base de composants) • Adaptation dynamique des services selon le contexte d'exécution courant • ajout/suppression de composants • modification des connexions entre composants • changement d’implantation des composants

8. Plan • Problématique, objectifs • Éléments du service statique • Description du contexte requis et fourni • Service de réplication • Architecture pour l'adaptation dynamique distribuée • Conclusion

9. Description du contexte • Différents formalismes existants • Paires (clé, valeur)‏ • Ontologies • Retenu • Méta modèle dérivé de • COACH, « Component based open source architecture for distributed Telecom Applications. WP2 : Specification of the deployment and configuration », Juillet 2003. • OBJECT MANAGEMENT GROUP, « Deployment and Configuration of Component-based Distributed Applications Specification », OMG TC Document ptc/2003-07-08, Boston, U.S.A., Juillet 2003. • Approche déclarative

10. Système (service) de réplication • Trois (sous) services principaux • Placement, accès, cohérence • Inspiré de • S. Drapeau. RS2.7 : un canevas adaptable de services de duplication. Thèse de Doctorat, Institut National Polytechnique de Grenoble, 2003. • V. Marangozova. Duplication et cohérence configurables dans les applications réparties à base de composants. Thèse de Doctorat, Université Joseph Fourier, 2003.

11. Hypothèses de travail • Focalisation sur le service cohérence • Pas de prise en compte des dépendances avec placement et accès • Nombre et localisation des répliques sont fixes • Donnée et variantes • Pas de prise en compte des dépendances entre elles (i.e. pas de variante)

12. Service de gestion cohérence • Opérations de lecture/écriture sur la réplique locale • Un CM (« Consistency Manager » ) par réplique d'une donnée Collaboration avec autres CM selon un protocole de cohérence pour écritures Ensemble de composants CM distribués qui collaborent Collaboration entre CMs = protocole de cohérence particulier

13. Un exemple Réseau cœur de l’opérateur CM M ADSL Protocole de cohérence forte Maître – esclave Envoi atomique des MàJ CM E PC maison Smart phone Raphaël CM E Réseau Wi-Fi maison Karine et Raphaël

14. Plan • Problématique, objectifs • Éléments du service statique • Architecture pour l'adaptation dynamique distribuée • Principe fondateur • Dimension métier : le service de cohérence • Dimension de contrôle : l'adaptation dynamique • Conclusion

15. Le principe fondateur • Regrouper les nœuds et les liens de communication fournissant le même contexte • Environnement : constitué de sous-environnements • Sous-environnement = nœuds (et liens) fournissant le même contexte • Utiliser le protocole de cohérence le plus pertinent pour chaque sous-environnement • Remplacement « à chaud » du protocole utilisé dans un ou plusieurs sous-environnements

16. Le principe fondateur : exemple Réseau cœur de l’opérateur Sous environnement B (cohérence faible)‏ Sous environnement A (cohérence forte)‏ CM maître ADSL GPRS CM escl CM CM PC maison PortableChloé Smart phone Karine CM Réseau Wi-Fi maison Smart phone Raphaël

17. Architecture générale du service • Deux dimensions • Métier = service de cohérence • Contrôle = adaptation dynamique • La dimension métier • CMs implantant des protocoles de cohérence • La dimension de contrôle • Remplacement dynamique de protocoles de cohérence

18. Architecture générale du service • Regroupement pertinent des répliques en sous-environnement • Fonction des qualités du réseau … • Implantation pertinente d’un protocole pour chaque sous-environnement • Adéquation type de protocole (cohérence forte, faible …) - type de sous-environnement • Changement « à chaud » des protocoles, des sous- environnements • Mécanismes pour décider de l'intérêt d'un changement • Mécanismes pour exécuter les décisions • Angle d'attaque : canevas logiciel

19. Terminologie • Intra-environnement vs inter-environnement • Dimension métier intra et inter-environnement • Adaptation intra-environnement • Remplacement du protocole de cohérence implanté par CMs dans un sous-environnement • Adaptation inter-environnements • Remplacement de(s) protocole(s) de cohérence implanté(s) par CM(s) dans des sous-environnements différents

20. Dimension métier intra-environnement • Ensemble de composants (« Consistency Manager » ) distribués qui collaborent • Collaboration entre CMs = protocole de cohérence particulier • Un CM par réplique (d'une donnée) • Opérations de lecture/écriture sur la réplique locale • Selon le protocole de cohérence implanté par collaboration

21. Dimension métier inter-environnements • Propagation des mises à jour réalisées au sein d'un sous-environnement aux autres • en cohérence faible (de par la façon dont les sous-environnements sont construits)‏ • Si vers sous-environnement en cohérence forte • propagation à un point d'accès unique (composant « Gateway »)‏ • Si vers sous-environnement en cohérence faible • propagation directe aux CMs

22. Exemple 1 Sous environnement A (cohérence forte)‏ Sous environnement B (cohérence faible)‏ CM maître Gateway CM escl CM escl CM Inter-environnement (cohérence faible)‏

23. Exemple 2 Sous environnement A (cohérence forte)‏ Sous environnement B (cohérence forte)‏ CM maître Gateway CM escl Gateway CM CM CM Inter-environnement (cohérence faible)‏

24. Plan • Problématique, objectifs • Éléments du service statique • Architecture pour l'adaptation dynamique distribuée • Principe fondateur • Dimension métier : le service de cohérence • Dimension de contrôle : l'adaptation dynamique • Conclusion

25. Dimension de contrôle • Architecture à deux niveaux • Cohérents avec la dimension métier • Adaptation intra-environnement • sur des CMs distribués ayant le même protocole • Adaptation inter-environnements • sur des CMs distribués ayant différents protocoles

26. Dimension de contrôle intra-environnement • Un composant « Strategy Manager » par sous-environnement • Spécialisant le canevas Dynaco • Action d'adaptation • Remplacement de l’implantation d'un composant

27. Architecture

28. Dimension de contrôle inter-environnements • Problématique • Actions d'adaptation sur des composants distribués dans différents sous-environnements • Coordination de plusieurs prises de décision (une par « Strategy Manager ») • Composants métiers doivent être cohérents à l'issue des actions d'adaptation • Résultats existants • Aceel : implante une coordination centralisée • PBs : Passage à l'échelle, entités non accessibles ...

29. Dimension de contrôle inter-environnements • Composant « Coordinator » par sous-environnement • Spécialisant le canevas Dynaco (dans une certaine mesure ?) • Dialogue entre « Coordinators » pour mettre en place l'adaptation inter-environnement • Adaptation dynamique distribuée

30. Dimension de contrôle inter-environnements Adaptation dynamique centralisée Adaptation dynamique distribuée Coordinator A Strategy Manager A Gateway Coordinator B CM escl CM escl CM maître Strategy Manager B CM CM

31. Fonctions du « Coordinator » : Quelques pistes • Prise de décision • Accord entre les « Coordinators » sur les nouveaux protocoles à utiliser (entre “deciders” des coordinateurs) • Planification • Définition des actions d'adaptation intra-environnement • Exécution • actions à destination du “strategy manager” • Suivi de l'adaptation distribuée (protocole entre coordinateurs)

32. Conclusion • Canevas logiciel d'adaptation dynamique d'un service de cohérence de données répliquées • Plusieurs protocoles de cohérence pour une donnée répliquée dans différents contextes fournis par l'environnement • Prise en compte des fluctuations des contextes • Remplacement du (des) protocole (s) de cohérence utilisé (s)

33. Perspectives • Dimension métier • Prise en compte de dépendances entre services (placement, accès et cohérence) • Prise en compte de la nature des données, des variantes de données • Dimension de contrôle : adaptation dynamique distribuée Coordination de l'adaptation • intra-environnement (en raison des dépendances entre services) • inter-environnements (“coordinators” distribués)

34. Perspectives • Etudier des techniques d'auto-adaptation • Algorithmes d'apprentissage pour décider des adaptations • Notion de « qualité » d'adaptation • Contrats d'adaptation (ou d'évolution) • Négociation de contrats

35. Annexe

36. Exemple

37. Décomposition de l'adaptation dans Dynaco • 4 fonctions principales • Observation de l'environnement d'exécution • Décision de l’opportunité d’une adaptation et détermination d’une stratégie d’adaptation • Planification des actions pour adapter le composant • Ordonnancement et exécution des actions planifiées • Séparation des diverses dépendances de l'adaptabilité vis-à-vis du composant et de la plate-forme