7.5.1 Patrons d’intégration
Le modèleFractal propose une interface de contrôle spécifique qui modélise et permet de définir et de gérer les propriétés orthogonales primitives des composants [Bruneton et al. 2002]. Cette interface permet de donner accès aux attributs des composants sans qu’il ne soit nécessaire de les démarrer ou de connecter les autres interfaces fonctionnelles des composants. De plus, elle offre aussi différents modes d’accès – lecture et/ou écriture – et cela permet donc de respecter la différences entre les catégories de notre classification précédente dans laquelle les propriété de nature et les paramètres de fonctionnement ne sont modifiables, alors que les paramètres de configuration le sont davantage (voir section7.2). Ainsi, comme les propriétés de nature, les paramètres de configuration et les paramètres de fonctionnement représentent des attributs de composants, leur modélisation se fait naturellement par des attributsFractal et une interface de contrôle des attributs (voir Fig.7.8aand7.8b), avec leurs opérations de lecture/écriture associées.
7.5. Projection dans la plate-forme Fractal
FIGURE7.7 – Interactions entre un client (base ou méta) avec les entités du meta-niveau
Comme les ressources sont modélisés par des composants, ils sont, dans la plate-forme Fractal , aussi réifiés sous la forme de composants à part-entière (voir Fig.7.8c). Compte tenu de la diversité des ressources physiques, les composants de ressources qui les réifient ne fournissent pas a priori de fonc- tionnalités élaborée, si ce n’est de collecter diverses informations sur l’état des ressources physiques. En particulier, comme les propriétés de capacité des ressources constituent de telles informations basiques collectées par des sondes de ressources, lesquelles sont modélisées par des composants, ces propriétés sont modélisées par des interfaces fonctionnelles des composants de ressources associées au composant de ressource (voir Fig.7.8d). La modélisation n’impose pas de contraintes spécifique sur la nature des données de sondes collectées. Celles-ci restent ouvertes, et doivent donc être déterminées par les déve- loppeurs. Par exemple, ces mesures peuvent être très primitives et collectées directement au niveau des ressources physiques, ou alors être plus complexes issues de calcul plus statistiques plus sophistiqués (interpolations, corrélations, etc.).
Enfin, il est à noter que comme des ressources physiques peuvent être utilisées par différents compo- sants, le partage des composants [Bruneton et al. 2002] offert par la plate-formeFractal est ici reprise pour refléter au niveau applicatif le partage de ressources physiques, mais aussi cela permet d’utiliser une même instance de composant de ressource, dans des composites distincts, potentiellement à différents niveaux de hiérarchie, tout en préservant l’encapsulation des composants.
7.5.2 Support compositionnel
Compte tenu de l’ouverture de la plate-formeFractal , la gestion des propriétés compositionnelles des compositionnelles est aisément intégrée sous la forme d’une nouvelle fonctionnalité de contrôle et celle- ci est effectuée en suivant les principes d’intégration des contrôleurs définis dansJulia. Le gestionnaire de propriétés compositionnelles (CompositionalPropertyManager) est donc implémenté sous la forme d’une nouvelle interface de contrôleFractal, intégrée dans la membrane de tout composant composite paramétré. Le fonctionnalités offertes par ce nouveau contrôleur peuvent être utilisées de façon usuelle en récupérant par introspection l’interface de contrôle à partir de son nom.
Chapitre 7. Patrons d’intégration de propriétés extrafonctionnelles fonctionnelle d’attributs Propriétés de nature Paramètres de fonctionnement Interface de contrôle Interface getProperty() .... Composant métier
(a) Propriétés de nature et de fonctionnement
fonctionnelle get/setProperty() .... Interface d’attributs Interface de contrôle Paramètres de configuration Composant métier (b) Propriétés de configuration Partage de composant Partage de composant Composant métier Composant de ressource R R R (c) Ressources Interface Propriétés de capacité fonctionnelle getResourceLevel() .... Composant de ressource (d) Propriétés de capacité
FIGURE7.8 – Récapitulatif des patrons d’intégrations dans la plate-formeFractal
et maintient, pour cela, une table des différents objets réifiant les propriétés compositionnelles (Compo- sitionalProperty). Chacun de ces objets donne notamment accès à 1) la liste de tous les objets Quantitati- veNonFunctionalPropertydécomposant la propriété compositionnelle, et à 2) la valeur de cette dernière. Les objets QuantitativeNonFunctionalProperty sont instanciés à partir des informations composition- nelles décrites par des annotations Java multi-valuées sur l’interface d’attributs, et fournissent chacun les diverses informations de la propriété contributrice (nom, composant, interface, méthode, valeur). En particulier, la valeur de la propriété compositionnelle (CompositionalProperty) est calculée en récupérant les valeurs des différentes propriétés contributrices QuantitativeNonFunctionalProperty, et en évaluant ces valeurs selon la fonction compositionnelle.
Il est à noter que comme une propriété compositionnelle d’un composite dépend des propriétés de ses sous-composants, le gestionnaire de propriétés compositionnelles doit être notifié des événements d’ajouts de sous-composants. Pour chaque propriété compositionnelle, l’instanciation effective des objets CompositionalProperty, QuantitativeNonFunctionalProperty s’opère seulement lorsque tous les sous- composants requis sont disponibles dans le composite concerné. Inversement, dès qu’un sous-composant qui intervient dans la décomposition d’une propriété compositionnelle est retiré, la description composi- tionnelle de la propriété n’a plus aucun sens et l’objet qui réifie la propriété compositionnelle est invalidé.
8
Mise en œuvre dans Fractal et ConFract
L
E chapitre6 a défini un modèle de négociation dynamique de contrats pour composants logicielscontractualisés qui s’appuie sur les principes généraux des modèles de composantsFractal et de contratsConFract. Le système de négociation proposé offre comme principale fonctionnalité de rétablir la validité des contrats en faisant négocier les composants eux-mêmes. Il travaille sur les clauses, élé- ments les plus atomiques d’un contrat, et s’organise autour des négociations atomiques. Ces négociations atomiques regroupent les différents éléments de base nécessaires à toute négociation :
– Des parties bien définies : le contrôleur de contrats en tant qu’initiateur, les composants impliqués dans la clause avec leur responsabilité déterminée par le systèmeConFract, un éventuel participant externe pour injecter des paramètres de pilotage de plus haut niveau ;
– Des objets de négociation que sont les clauses des contrats autour desquels ces parties inter- agissent ;
– Des interactions entre parties organisées selon un protocole de négociation qui reprend les prin- cipes généraux duContract-Net Protocol ;
– Différentes politiques de négociation qui peuvent exploiter des informations fines contenues dans les contrats comme les responsabilités des composants et qui fournissent alors différentes orienta- tions aux négociations atomiques.
La suite de ce chapitre détaille la mise en œuvre du modèle de négociation dans les plates-formes ConFract et Fractal . Les besoins en termes d’intégration vis-à-vis des plates-formes et du cycle de vie des composants et des contrats sont rapidement décrits. Puis, l’architecture et le fonctionnement plus précis du système sont présentés.
8.1 Définition des besoins
L’intégration du système de négociation se fait sur une implémentation de la plate-formeConFract, elle-même basé sur l’implémentation de référenceJulia du modèle Fractal . De plus, comme le système de négociation étend le système de contrats construit sur les composantsFractal, les processus de négo- ciation définis ont besoin de s’appuyer sur plusieurs éléments extraits des contextes des composants et des contrats, et ils doivent aussi s’intégrer dans le cycle de vie des composants et des contrats.
Chapitre 8. Mise en œuvre dans Fractal et ConFract
Interfaçage avec Fractal
Le modèle de négociation utilise un certain nombre de fonctionnalités du modèle de composants Fractal dans sa version 2 [Bruneton et al. 2002]. En particulier, les informations sur les composants (recherche des participants lors du processus de négociation, objets de la négociation) sont récupérées par introspection des composants. De plus, les capacités supplémentaires nécessaires à la négociation (raisonnement lors de la négociation, informations compositionnelles éventuellement exploitées) sont intégrées à l’aide de la notion de contrôleur dans la membrane des composants (cf. section7.5, page
106). L’implémentation du modèleFractal choisie pour l’intégration est celle de référence Julia. Dans sa version 2.5,Julia offre notamment la possibilité d’implémenter les contrôleurs sous la forme des com- posantsFractal . Ceci permettra de placer des composants Fractal relatifs à la négociation dans les mem- branes de composants, tout en étant aussi compatible avec une version objet du contrôleur de contrats ConFract.
Interfaçage avec ConFract
Vis-à-vis du système de contrats, le modèle de négociation s’intègre à la première version du sys- tème ConFract, et les processus de négociation reposent sur les hypothèses suivantes. La capacité de négociation est intégrée par extension du contrôleur de contrats. En effet, aucun nouveau contrôleur de négociationn’est intégré au système. Par contre, c’est le contrôleur de contrats qui est étendu pour ini- tialiser et piloter les négociations atomiques relatives aux contrats non satisfaits qu’il gère. Pour cela, il va créer ou utiliser des nouveaux éléments du modèle de négociation qui seront implémentés sous la forme d’objets ou de composants définis dans les membranes des composants. De plus, le système de contrats donnera au système de négociation les accès aux contrats (clauses, participants, responsabili- tés des participants) pour qu’ils puissent être manipulés. Afin de faciliter le couplage avec le système de négociation, des adaptateurs vers les objets clauses et contrat originel seront fournis par le système de contrats et seront utilisés par les processus de négociation. Ces objets permettront d’obtenir la spé- cification originelle, de la remplacer et aussi de reconstruire des objets de contrats cohérents. Il est à noter que les négociations atomiques ne portent uniquement que sur les clauses du contrat violé. Les accords construits dans les contrats ne sont pas des objets de négociation. En revanche, ils sont censés être recalculés et éventuellement re-vérifiés en sortie de négociation atomique pour vérifier la validité du contrat original compte tenu des éventuelles modifications sur la clause négociée effectuées lors de la négociation. L’interfaçage avec les objets dansConFract est précisé dans une section suivante.
Intégration dans le cycle de vie
Le processus de négociation démarre lorsque la vérification, par le gestionnaire de contrats d’une clause d’un contrat se révèle fausse. Le système de négociation effectue alors les opérations suivantes :
1. Isolation des parties des composants et des contrats impactés. Au niveau du système de contrats, une image du contrat existant nommé est formé à partir du contrat original. Cette image figée du contrat original n’observe plus l’exécution, ni les modifications qui interviennent sur les compo- sants et les contrats. En particulier, cet objet contient aussi une copie des clauses sur lesquels vont porter les négociations atomiques. Ces dernières seront alors récupérés et adaptés pour devenir des objets de la négociation. Au niveau du système de composants, le fil d’exécution qui a déclenché la violation est bloqué avant de démarrer les négociations.
Il s’agit d’une condition nécessaire et de l’hypothèse minimale que peut exiger le processus de négociation avant de démarrer. D’autres éléments du système peuvent nécessité d’être isolés, mais comme on ne peut pas, a priori et dans le cas général, identifier ces éléments et évaluer leurs