Dans une situation où le support pour une infrastructure destinée à supporter les ap- plications basées sur les services, et qui repose de plus en plus sur une haute disponibilité des ressources de calcul, un moyen générique de décrire l’infrastructure s’applique parfai- tement bien à cette vision, permettant la conception abstraite de l’application par rapport à l’infrastructure existante.
6.1.4.1 Le support pour les communications collectives
Le support pour les communications collectives est amélioré dans le modèle GCM, grâce à l’introduction des interfaces gathercast et multicast. Le but ici est de fournir des commu- nications plusieurs-vers-une et une-vers-plusieurs efficaces. Ces interfaces permettent de gérer un groupe d’interfaces comme une seule entité. La notation pour ces deux interfaces est montrée dans la Figure6.5
6.1.4.2 Les interfaces gathercast
Les interfaces gathercast permettent d’effectuer des communications plusieurs-vers-une (M x 1) et peuvent être utilisées pour effectuer des synchronisations, de la récupération de paramètres, de la réduction et de l’envoi de résultat. Le comportement spécifique pour ces interfaces peut être spécifié en utilisant des politiques d’agrégation.
Les interfaces gathercast reçoivent les invocations depuis plusieurs interfaces qui leur sont connectées, rassemblant ainsi tous les paramètres, et les réduisant dans une seule invocation. Quand un résultat est obtenu, l’interface gathercast effectue l’envoi correspon- dant vers les partenaires qui ont effectué l’invocation.
6.1.4.3 Les interfaces multicast
Les interfaces multicast permettent les communications une-vers-plusieurs et peuvent être utilisées pour effectuer des invocations parallèles, l’envoi de paramètres et le rassem- blement de résultats. Le comportement spécifique pour ces interfaces peut être configuré en utilisant différents modes d’envoi (dispatch modes). Les modes d’envoi peuvent être uti- lisés pour définir la façon dont les paramètres de l’invocation originelle sera divisée entre les différentes destinations, ou pour choisir l’interface, parmi les interfaces connectées, qui sera choisie pour effectuer l’invocation.
Les interfaces multicast transforment une seule invocation en plusieurs invocations parallèles. Quand un résultat est obtenu, les résultats, potentiellement nombreux, peuvent être agrégés et retournés au partenaire qui est à l’origine de l’invocation.
L’existence des interfaces multicast et gathercast a été développée initialement pour les interfaces fonctionnelles, et permet qu’un composant soit connecté à un nombre indéfini d’interfaces. Dans notre approche, nous utilisons la communication avec les membranes, puisque non-fonctionnelles, de tous les composants impliqués dans l’application, grâce aux interfaces multicast.
6.1.4.4 Le support pour les préoccupations non-fonctionnelles
La spécification Fractal, et son implémentation de référence Julia, décrivent les éléments de gestion comme un ensemble d’objets contrôleurs contenus dans la membrane d’un composant Fractal. Ces contrôleurs sont définis de façon statique et sont décrits par le biais de l’ADL Fractal.
Les composants GCM étendent cette notion pour permettre l’introduction des compo- sants Non-Fonctionnels (NF) dans la membrane. Les composants NF ont un but similaire aux contrôleurs, qui est de fournir des fonctionnalités de gestion aux composants GCM, et de prendre en charge des tâches Non-Fonctionnelles.
6.1.4.5 Séparation entre les préoccupations Fonctionnelles (F) et Non-Fonctionnelles (NF)
La motivation pour fournir une membrane "componentisée" aux composants GCM, est de permettre la composition d’activités plus complexes dans la partie contrôle du compo- sant, et de fournir une séparation plus claire des préoccupations entre les tâches fonc- tionnelles et les tâches non-fonctionnelles. Pour cela, l’ADL GCM peut être divisé et l’ar- chitecture componentisée de la membrane peut être décrite dans un fichier séparé de la partie fonctionnelle. Cela permet de développer les deux parties de façon indépendante et de les associer seulement au moment du déploiement, appliquant ainsi la séparation des des préoccupations fonctionnelles et non-fonctionnelles.
Le concept des tâches NF se réfère à toutes les tâches qui ne sont pas en relation avec le but principal (ou but fonctionnel) d’un composant GCM. Les taches NF peuvent être définies comme les tâches qui supportent le but fonctionnel d’un composant. Elles incluent en général la gestion du cycle de vie du composant, et la supervision de l’exécution du but fonctionnel.
6.1.4.6 Les interfaces NF
Dans beaucoup de cas, les activités de gestion peuvent requérir une collaboration si- gnificative de plusieurs tâches, qui peuvent être propagées transversalement vers d’autres composants. Par exemple, pour obtenir la mesure de la consommation d’énergie d’une ap- plication, il est nécessaire d’agréger la consommation d’énergie de tous les composants individuels inclus dans le composite, ou clients du composite.
GCM inclut des interfaces de contrôle additionnelles que l’on appelle interfaces non- fonctionnelles. Contrairement aux composants Fractal qui fournissent seulement des in- terfaces NF serveurs pour accéder aux tâches NF, GCM propose des interfaces NF clientes. Les interfaces NF clientes peuvent être connectées aux interfaces NF serveurs, dans le but de communiquer avec les membranes des différents composants et permettent d’effectuer des tâches NF collaboratives.
Dans la mise en œuvre de notre solution, nous utiliserons la possibilité d’avoir une vue orientée composant de la membrane des composants GCM, pour fournir une implémen- tation flexible et modulaire de notre gestionnaire d’orchestration distribuée, décrit dans le chapitre5.
En ce qui concerne les interfaces internes, GCM permet à la membrane de communi- quer avec le contenu, permettant ainsi une communication hiérarchique entre les taches NF collaboratives d’un composite et de ses sous-composants. Dans ce cas, GCM définit des interfaces NF internes. Ces interfaces communiquent avec les composants placés dans le contenu fonctionnel. Elles permettent aussi à ces sous-composants de communiquer avec les composants contenus dans la membrane du composite dans lequel ils sont inclus.
6.1.4.7 Notation et liaisons Non-Fonctionnelles
La figure 6.6 montre un exemple d’une application GCM où les composants NF ont été placés dans la membrane d’un composant composite et d’un composant primitif. Nous pouvons remarquer que GCM permet la coexistence des contrôleurs et des composants NF (parfois appelés composants contrôleurs) dans la membrane. Cependant, les contrôleurs objets ne peuvent pas être modifiés pendant l’exécution, et ne peuvent pas être connectés aux autres interfaces NF, ni communiquer avec elles, comme le feraient d’autres compo- sants NF.
La description dans la Figure6.6, illustre aussi les connexions possibles entre les inter- faces introduites précédemment. Une interface cliente d’un composant NF peut se connec- ter à une interface NF cliente interne appartenant à la membrane (1). Cette interface NF interne cliente agit comme un point de passage de la membrane vers le contenu. Une inter- face NF cliente interne peut se connecter à l’interface NF externe d’un sous-composant (2), concrétisant la communication de la membrane vers le contenu. Cela permet de propager les taches d’administration initiées dans la membrane du composite vers les membranes des sous-composants. Un exemple très simple consiste à un signal d’arrêt depuis la mem- brane du composite qui peut être propagé aux membranes de ses composants internes.
Inversement, la communication peut aussi s’effectuer du contenu vers la membrane. Une interface NF cliente d’un sous-composant peut se connecter à une interface NF ser- veur interne de son composant parent (3). Cette interface NF serveur agit comme un point de passage du contenu vers la membrane. L’interface NF serveur interne peut se connecter à l’interface serveur d’un composant NF (4), concrétisant ainsi l’accès à la tâche d’adminis- tration. Cela permet aux membranes des sous-composants d’accéder aux tâches d’admi- nistration dans la membrane de leur composant parent. Par exemple, un composant qui représente une ressource de stockage peut utiliser une interface NF pour communiquer à son parent que la capacité de stockage est presque atteinte, et que la membrane du composite doit prendre une décision.
Les autres éléments montrés dans la figure6.6 indiquent les connexions entre les in- terfaces NF serveurs externe d’un composant avec l’interface serveur d’un composant NF dans la membrane (5) ; la connexion entre l’interface cliente d’un composant NF vers une interface cliente NF externe (6) permet la communication avec l’extérieur. Finalement, une interface NF cliente peut être liée à une interface NF serveur d’un autre composant externe (7), permettant la communication entre les membranes de deux composants, et donc la la collaboration entre tâches NF. Par exemple, un gestionnaire de sécurité placé dans la membrane peut propager un certificat de sécurité à tous les composants avec lesquels il maintient une connexion fonctionnelle dans le but de lui-même s’authentifier.