Le métamodèle des KComponent fournit : • le graphe de configuration,
• les protocoles et actions de reconfiguration de base agissant sur le graphe,
• la gestion de la reconfiguration dynamique intégrée au sein des programmes nommés contrats, situés au métaniveau.
De manière pratique, le graphe de configuration est déduit automatiquement d’un sys-tème construit de manière programmatique. La reconfiguration est transactionnelle, et gèle l’exécution et l’état des composants. Les contrats sont décrits dans un langage d’adaptation spécifique, diffèrent du langage de programmation des composants. Ils sont chargés/déchargés dynamiquement (en dehors des phases de configuration du système) par un "configuration manager" situé avec eux dans le métaniveau (Figure A.3).
FIGURE A.3 – KComponent
Ces contraintes sont évaluées à la perception d’événements de reconfiguration du sys-tème, produisant ainsi un découplage entre niveau de base et méta et une possibilité de mise en oeuvre dynamique des contrats. Du point de vue de l’état de l’art, les rè-gles dans les contrats d’adaptation sont interprétées comme une convention entre les participants (composants) au contrat.
Deux types de contrats d’adaptation sont distingués :
• configuration : spécifie des contraintes architecturales entre composants d’un même système (techniquement limité à un espace d’adressage)
• connexion : spécifie des contraintes sur une connexion individuelle entre le sys-tème et un composant dont il dépend et qui lui est extérieur. Techniquement il peut s’agir d’un composant dans un autre espace d’adressage.
Les auteurs décrivent les contrats de la manière suivante :
/* Automatically generated from XML configuration descriptor */ configuration configuration* ::= configuration -descriptor.xml interface interface* ::= component-descriptor.xml
/* Automatically generated from component XML descriptors */ component component-name* ::= component-descriptor.xml consumes user_defined_handler* ::= component-descriptor.xml emits adaptation_event* ::= component-descriptor.xml
handler handler* ::= reconfiguration_op | user_defined_handler reconfiguration_op ::= change_component | change_configuration | install_interceptor | remove_interceptor | rollback |
callback_client
/* User-defined below here*/
contract configuration configuration {
/* Conditional statements and reconfiguration operations */ }
contract connection connection-contract* ::= [component client_name] [interface port_name] [component provider_name]
{
/* Conditional statements and reconfiguration operations */ }
A.4.2 CQML
La caractéristique de qos Les caractéristiques acceptent des paramètres et peuvent inclure dans leur définition des invariants, exprimés à l’aide de prédicats OCL. De plus une clause value : suivie d’une formule OCL, fonction de paramètres de la carac-téristique, permet de fixer les valeurs possibles de la grandeur, par exemple :
quality_characteristic startUpTime (flow : Flow) {
domain : decreasing numeric milliseconds; values : if flow.SE->isEmpty() then invalid
else flow.SE->first.time() - flow.initiate.time() endif;
invariant : flow.initiate = invalid implies flow.SE->isEmpty }
Enfin la composition de composants peut être prise en compte du point de vue de la qos. CMQL distingue la relation entre un composant utilisé par un autre et la re-lation entre plusieurs composants eux mêmes utilisés par un autre. Dans le premier cas la composition est modélisée par l’opérateur "sequential" indiquant la dépendance d’un composant par rapport à un autre. Dans le second cas les composants sont in-dépendants, néanmoins, vis à vis de leur utilisateur, ils sont susceptibles de devoir être utilisés conjointement ou non. Par exemple un client utilisant deux connexions
internet peut passer soit par l’une soit par l’autre, l’utilisation commune n’est pas obli-gatoire. Dans le cas d’un service de lecture de film, le composant de rendu d’image est à utiliser conjointement avec celui de son. Ces deux cas sont respectivement traités par les opérateurs parallel-or et parallel-and. sequential, parallel-or, parallel-and sont des opérateurs binaires. quality_characteristic { ... composition : parallel-and left_component_charac.max(right_component_charac) parallel-or left_component_charac.min(right_component_charac) sequential left_component_charac + right_component_charac }
Par ailleurs CQML permet de spécifier plus finement les caractéristiques que QML par l’utilisation de clauses values et invariant qui suivies d’une formule OCL décrivent les valeurs des caractéristiques ou les invariants qu’elles doivent respecter.
Le contrat Le corps de chaque contrainte est une expression OCL et sa validité peut être modulée dans le cas de contraintes statistiques qui requièrent de manière globale plusieurs mesures avant de pouvoir être décidées. Par exemple :
• best-effort : la contrainte n’est pas garantie,
• compulsory, threshold (appliqués à best-effort) with limit : respectivement, le ser-vice s’arrête si il ne peut maintenir une valeur donnée, et les clients d’un serser-vice (définis par l’intermédiaire du profile) sont prévenus quand une grandeur limite est atteinte par l’implémentation sous jacente du framework.
quality try_high {
compulsory best-effort frameOutput > 25 with limit 20; threshold best-effort delay < 5 with limit 8;
}
Dans cet exemple, le service s’arrêtera si il ne peut se maintenir au dessus de 20, par contre les clients seront simplement prévenus quand la limite de 8 est dépassée. ou encore :
quality quickAndAlert (s : Stream) : fast {
s->forAll (f : Flow | startUpTime(f) < 100); }
Les profils La spécification des profils est moins fine que dans QML, CQML ne de-scend pas jusqu’au niveau de la méthode. Mais comme pour QML il est possible d’at-tacher plusieurs contrats à une même entité d’implémentation, permettant ainsi la sé-paration des préoccupations.
A la manière de QuO avec ses régions de fonctionnement, CQML fait reposer les négo-ciations de QoS en phase de configuration ainsi que la gestion dynamique de celle-ci, sur la fourniture pour chaque profil d’un ensemble de sous profils imbriqués, requis ou fournis et nommés, par exemple :
profile adaptiveBinding for videoBinding {
profile good {
uses high (incoming.videoFlow);
provides high(outgoing.videoFlow) and fast(outgoing.videoFlow);
}
profile average {
uses medium(incoming.videoFlow);
provides medium(outgoing.videoFlow) and fast(outgoing.videoFlow);
}
transition any->average : incoming.some_callback("average"); transition average->good :
{
incoming.some_callback("good"); outgoing.another_callback("good"); }
precedence : good, average; }
En phase d’exécution, la transition d’un profil à un autre peut être associée à des réac-tions du système (à travers des callbacks). Du point de vue de la composition des com-posants, les auteurs expliquent que les caractéristiques qos d’un assemblage peuvent se déduire de celles de ses composants mais placent ces travaux en dehors du champs d’étude de CQML.
A.4.3 CQML+
Cette extension de CQML offre encore dans le langage une prise en charge de la qos des ressources distincte de celle des composants. En effet le système de composants ne gère pas concrètement les ressources systèmes, à la différence des ressources des com-posants. Le langage CQML est aussi étendu par des caractéristiques de qos composites ex. :
resource cpu {
quality_characteristic cpu_demand (r: Resource) {
domain: tupel {
period (r),
execution_time (r) };
invariant: execution_time < period; }
quality_characteristic execution_time (r: Resource) {
domain: numeric real [0..) milliseconds; }
quality_characteristic period (r: Resource) {
domain: numeric real [0..) milliseconds; }
}
Dans cet exemple la caractéristique cpu_demand est composée des caractéristiques execution_time et period, et fait porter sur celles-ci un invariant.
Enfin l’extension permet de définir des dépendances explicites entre les clauses uses et provides des profils. En effet dans certains cas un profil peut accepter plusieurs régions de fonctionnement. Il est possible de les décrire à l’aide d’un ensemble de sous-profils présentant les caractéristiques uses et provides correspondantes. Mais il peut être plus efficace de relier les caractéristiques uses et provides du profil par une ou plusieurs équations. Finalement Les concepteurs de CQML travaillent sur son intégration au EJB, dans le cadre de laquelle la spécification CQML serait transcrite en XML.