„„¾„¾¾¾¾„„„„„¾„¾™„¾„¾¾¾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 ...
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
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 serviceoriented orchestrated architectures.International Journal of Computing & Information Sciences (IJCIS),Vol.5, N°1, pp.4550, Avril 2007 9C. Chassot, K. Drira, K. Guennoun, F. Armando, E. Exposito and A. Lozes. Towards autonomous management of QoS through modeldriven adaptability in communicationcentric systems.International Transactions on Systems Science and Applications, Vol.2, N°3, pp.255264, 2006. 9K. Guennoun and K. Drira. Using graph grammars for interaction style description. Application to serviceoriented architectures.International Journal of Computer Systems Science & Engineering, Vol.21, N°4, pp.293299, Juillet 2006
Coordination
Publications
Description du style d’architecture(le style 2tier)
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 multiniveaux 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 serv1cl1 serv1 MoveClient(cl3,serv3,serv2) MoveClient(cl2,serv2,serv1) Choix du formalismes cl2 erv2cl2 serv2 n’est pas applicable Notre choix : les grammaires de graphe:cl3 serv3cl3 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 +picalculus): ¾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 2tier (Client/serveur classique). ¾Style 3tier (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 SS 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⎞ ⎛ ⎞ 2NG PRE+2 K×⎜ ⎟N PRE ⎜ ⎟ .Complexité au pire cas de:⎝NG−NPRENG−NPRE⎠ ⎠ 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 à supprimerC1 > S1 , C2 > S1 ; Delete Edges S2C1 > S1 ; Pattern Invariant Add Edges C1 > S2 ;
Architectures dynamiques dans le contexte des applications à base de composants et orientées services