Poster-These-France-projet-05G1409

Admintheia

Description

„„¾„¾¾¾¾„„„„„¾„¾™„¾„¾¾¾9„9„9„¾„¾„¾¾¾„„¾¾/¾.„„¾„¾¾„„„¾„¾¾„„„„„¾„¾„¾„¾¾„™.™„„„¾„¾¾„/¾¾Projet CMCU, Action Intégrée n° 05G 1409 Architectures dynamiques dans le contexte des applicationsLaboratoire d’Analyse etDépartement d’Informatique et à base de composants et orientées servicesd’Architecture des Systèmesde Mathématiques AppliquéesMohammed Karim GuennounDirecteurs de thèse: Khalil Drira, Michel DiazContexte RéalisationsDescription du style d’architecture (le style 2-tier)Algorithmes de recherche d’homomorphismesAdaptabilité des architectures : Grammaire de graphe < AX;{CS};{Client,Serveur}; Prod}, où Prod = Spécification. < {AX};{ };{CS};{ } > (I) Première implémentation en JAVA, avec un algorithme récursif :Contrôle. < {CS};{ };{ };{ } > (II) ☺ Variables dans les labels.Gestion. < { }; {CS};{Client(c), Serveur(s), c -> s} > (III) Labels de type string pour les nœuds de la règle.Architectures logicielles dynamiques distribuées orientées composants. < { }; {CS, Client(c)}; {Serveur (s), c-> s} > (IV) Limitation par rapport à la structure de la règle (pas de cycles dans la Styles d’architectures. précondition).< { }; {CS, Server(s)}; {Client(c), c->s} > (V)Passage à l’échelle laborieux.< { }; {CS, Client(c), Server(s)}; {c->s} > (VI)Deuxième implémentation en C++, avec un algorithme par ...

Informations

• Publié par: Irro
• Nombre de lectures: 71
• Langue: Français

Extrait

Grammaire de graphe < AX;{CS};{Client,Serveur}; Prod}, où Prod = < {AX};{ };{CS};{ } >(I) (II)< {CS};{ };{ };{ } > < { }; {CS};{Client(c), Serveur(s), c > s} >(III) < { }; {CS, Client(c)}; {Serveur (s), c> s} > (IV) (V)< { }; {CS, Server(s)}; {Client(c), c>s} > (VI)< { }; {CS, Client(c), Server(s)}; {c>s} >

API C++|| APIJava

Des outilspour la description et la gestion des architectures dynamiques

Environnements et approches pour la conception formelle des architectures dynamiques

Gestion et contrôle de l’évolution (en runtime)

Vérification dela conformité du protocole de coordination par rapport à la spécification

Mohammed Karim Guennoun Directeurs de thèse: Khalil Drira, Michel Diaz

Vérification des propriétés de correction

Réalisations

¾1 revue Francophone ¾7 Conférences internationales ¾2 Conférences francophones

Algorithmes de recherche d’homomorphismes

Description des architectures dynamiques

Implémentation

Objectifs

Favoriser l’adaptabilité des applications et services

Contexte

Exemple: Rediriger un client d’un serveur vers un autre dans une application à architecture Client/Serveur

Une règle de transformation est décrite par un graphe partitionné. La partition du graphe de la règle spécifie : ¾Quand une évolution est possible : Exigeant laprésenced’un Pattern dans le graphe représentant l’architecture courante de l’application. ¾Et comment l’évolution est réalisée : Transformation du graphe de l’architecture par l’ajoutet la suppressionde Patterns. Génération des actions basiques pour la modification de l’architecture. L’application de la règle est subordonnée à l’existence d’homomorphisme entre sapréconditionet le graphe modélisant l’architecture courante.

Département d’Informatique et de Mathématiques Appliquées

 Adaptabilité des architectures : ¾Spécification. ¾Contrôle. ¾Gestion. Architectures logicielles dynamiques distribuées orientées composants. Styles d’architectures.

Résultats expérimentaux pour une règle de 10 nœuds ¾Graphe de 1 000 nœuds : 0.5 s ¾Graphe de 1 000 000 nœuds :2 min

de grande taille

dans les applications

Laboratoire d’Analyse et d’Architecture des Systèmes

¾3 revues internationales: 9K. Guennoun, K. Drira and M. Diaz. Considering topological constraints for the description of dynamic serviceoriented orchestrated architectures.International Journal of Computing & Information Sciences (IJCIS) , Vol.5, N°1, pp.4550, Avril 2007 9C. Chassot, K. Drira, K. Guennoun, F. Armando, E. Exposito and A. Lozes. Towards autonomous management of QoS through modeldriven adaptability in communicationcentric systems.International Transactions on Systems Science and Applications, Vol.2, N°3, pp.255264, 2006. 9K. Guennoun and K. Drira. Using graph grammars for interaction style description. Application to serviceoriented architectures.International Journal of Computer Systems Science & Engineering, Vol.21, N°4, pp.293299, Juillet 2006

Coordination

Publications

Description du style d’architecture(le style 2tier)

13 articles (actes et comité de lecture):

 Approches et méthodes: ¾Coordination des modèles et des procédures d’adaptabilité architecturale et comportementale ¾Coordination et optimisation de l’adaptation multiniveaux Applications: ¾Coordination de la reconfiguration architecturale dans les applications à base de services Web avec l’adaptation comportementale au niveau des processus BPEL. ¾Coordination de la reconfiguration niveau application avec des mécanismes d’adaptation niveau transport. Algorithmes et outils: ¾Implantation du deuxième algorithme ¾Intégration générique avec les technologies de programmation distribuée (Web services, Composants)

 Modèle basé sur les grammaires de graphes pour : ¾La description des architectures dynamiques. ¾Le contrôle et la gestion de ces architectures. ¾Vérification et validation des propriétés architecturales. Algorithmes de recherche d’homomorphismes et de transformation de graphes appropriés pour le type de problématique à traiter. Outil basé sur la réécriture de graphes pour la conception/validation et pour le contrôle/gestion des architectures logicielles dynamiques. Application à des styles architecturaux génériques et à différentes applications coopératives

Evolution de l’architecture (les règles de transformation)

Comparaison expérimentale avec l’outil AGG (Technische Universität Berlin):

Deux modules en couches: ¾Moteur de transformation de graphes ¾Protocole de reconfiguration programmable

C S C S

Conclusion

cl1 serv1 cl1 serv1 MoveClient(cl3,serv3,serv2) MoveClient(cl2,serv2,serv1) Choix du formalisme s cl2 erv2 cl2 serv2 n’est pas applicable  Notre choix : les grammaires de graphe: cl3 serv3 cl3 serv3 ¾Une architecture = un graphe.un composant = nœud, une connexion ou une interdépendance = un arc). ¾et opérationnel pour la vérification et la validation.Moyen formel  Les autres possibilités: ADLs (e.g. Wright +CSP, Darwin +picalculus): ¾ Langages formels pas appropriés pour la phase de spécification (différents Applications et cas d’étude traités profils des interlocuteurs). ¾Traitement limité de l’évolution dynamique de l’architecture. Caractérisation de styles architecturaux de base, introduction des règles de coordination correspondantes, et vérification formelle de leur consistance: ¾Style 2tier (Client/serveur classique). ¾Style 3tier (Client/ Middleware/ Serveur). Formalisation ¾Styles pour les architectures orientées services (avec les notions d’orchestration de chorégraphie ).  Une instance de l’architecture = un graphe. Modélisation d’applications coopératives distribuées, Introduction des Un style d’architecture = une grammaire de graphe. règles de coordination pour gérer l’adaptation par rapport aux Une propriété architecturale = existence ou absence d’un homomorphisme de contraintes du contexte d’exécution tout en respectant les exigences du graphes contexte d’utilisation : Une architecture dynamique = un graphe initial + un ensemble de règles de ¾Edition Coopérative transformation. ¾Revue Coopérative Modèle pour l’analyse de l’architecture (passage d’un point de vue ou d’un ¾Opérations d’intervention d’urgence niveau d’abstraction à un autre) = grammaire de graphe NCE.

Feuilles de l’arbre de production = Instances consistantes de l’architecture

Ax I II Graphe CS Vide III C S IV CS II V C S III C SS C SC SC C SC CS …….. CS II II …….. …….. C S VI C SC S C S S C SC S C CS …….. II

Projet CMCU, Action Intégrée n° 05G 1409

Perspectives

 Spécification formelle du style de l’architecture du système: ¾Décrire les instances consistantes de l’architecture. Contrôle de l’évolution dynamique en ligne: ¾Autoriser ou non une évolution de l’architecture. Gestion (consistante) de l’évolution dynamique en ligne: ¾Spécifier les opérations à effectuer en réponse à un besoin d’adaptabilité de l’architecture (oui/non + comment?).

 Première implémentation en JAVA, avec un algorithme récursif : ☺Variables dans les labels. .Labels de type string pour les nœuds de la règle. /Limitation par rapport à la structure de la règle (pas de cycles dans la précondition). /Passage à l’échelle laborieux. Deuxième implémentation en C++, avec un algorithme par décomposition : ☺Aucune limitation au niveau de la structure des graphes. ☺Liste de labels typés. ☺Traitement d’arcs valués (permet la distinction du type d’interdépendance). N ⎛ N ⎞ ⎛ ⎞ 2 N G PRE +2 K× ⎜ ⎟ N PRE ⎜ ⎟ .Complexité au pire cas de: ⎝ N G −N PRE N G −N PRE ⎠ ⎠ G ⎜ ⎟ ⎝ Troisième implémentation avec un algorithme profitant du contexte d’utilisation du formalisme (ensemble stable de règles potentiallment applicables: ☺Mise à jour de l’arbre de recherche au lieu de sa reconstruction à chaque transformation ☺Gain important par rapport à l’algorithme précédent

MoveClient (ClientId, ServerId1, ServerId2) Précondition Match Nodes de la règle C1 with parametersId = ClientId , Role = Client, C1 S1 with parametersId = ServerId1, Role = Server, S2 with parametersId = ServerId2, Role = Server, C2 with parametersRole = Client; Pattern à introduire Edges S1 Pattern à supprimer C1 > S1 , C2 > S1 ; Delete Edges S2 C1 > S1 ; Pattern Invariant Add Edges C1 > S2 ;

Architectures dynamiques dans le contexte des applications à base de composants et orientées services

et propriétés

Consistance

de correction

Approche