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.
A.5 Formalismes non fonctionnels pour les services
A.5.1 WSLA
Description de l’opération. Un exemple d’opération sera :
<Operation xsi:type="wsla:WSDLSOAPOperationDescriptionType" name="WSDLSOAPGetQuote"> <SLAParameter name="AverageResponseTime" type="float" unit="seconds"> .... </SLAParameter> ....
<Metric name="SumResponseTimeTimeSeries" type="TS" unit="milliseconds">
<Source>ACMEProvider</Source>
<Function xsi:type="TSConstructor" resultType="TS"> <Schedule>hourlyschedule</Schedule>
<Metric>SumResponseTime</Metric> <Window>2</Window>
</Function> </Metric> ....
<!-- This part is the wsdl-specific definition of the operation. -->
<WSDLFile>StockQuoteService</WSDLFile>
<SOAPBindingName>GetQuoteSoapBinding</SOAPBindingName> <SOAPOperationName>getQuote</SOAPOperationName>
</Operation>
L’opération getQuote est ainsi associée au paramètre AverageResponseTime. Celui-ci doit être fourni par le ACMEProvider selon la métrique SumResponseTimeTimeSeries. En effet en plus des clients et fournisseurs du service, il est possible de faire intervenir des entités chargées de mesurer les valeurs.
ServiceLevelObjective Par exemple :
<ServiceLevelObjective name="g1"> <Obliged>provider</Obliged> <Validity> <Start>2001-11-30T14:00:00.000-05:00</Start> <End>2001-12-31T14:00:00.000-05:00</End> </Validity> <Expression> <Predicate xsi:type="wsla:Less"> <SLAParameter>AverageResponseTime</SLAParameter> <Value>5</Value> </Predicate> </Expression> <EvaluationEvent>NewValue</EvaluationEvent> </ServiceLevelObjective>
Dans cet exemple le parameter AverageResponseTime doit être inférieur à 5 sur la durée définie par le champs validity. L’expression est évaluée quand est détecté l’événe-ment NewValue.
ActionGuarantee Par exemple :
<ActionGuarantee name="ga3"> <Obliged>ZAuditing</Obliged> <Expression> <Predicate xsi:type="Violation"> <ServiceLevelObjective>ga1</ServiceLevelObjective> </Predicate> </Expression> <EvaluationEvent>NewValue</EvaluationEvent> <QualifiedAction> <Party>XInc</Party>
<Action actionName="notification" xsi:type="Notification"> <NotificationType>Violation</NotificationType>
<CausingGuarantee>ga1</CausingGuarantee> <SLAParameter>Availability_UpTimeRatio</SLAParameter> </Action> </QualifiedAction> <ExecutionModality>Always</ExecutionModality> </ActionGuarantee>
Dans cet exemple la partie "ZAuditing" s’assure que le ServiceObjective "ga1" est véri-fié à chaque événement "NewValue". Dans le cas ou "ga1" n’est pas vérivéri-fié alors "ZAu-diting" notifie la partie "Xinc".
ANNEXE
B
Plugins et spécialisation du
système de contrat
Dans cette partie nous allons présenter les classes et mécanismes spécialisés par chacun des plugins, ainsi que les implémentations de ces derniers propres à Fractal et CCLJ.
B.1 Plugin d’architecture
Le plugin d’architecture a pour objet de fournir l’implémentation de classes génériques du noyau liées à l’architecture, adaptée à une architecture concrète. Les classes du noyau à spécialiser sont les suivantes :
pour la description de l’architecture :
• ArchitectureDescription: cette interface offre des fonctionnalités d’in-trospection de l’architecture du système contraint en des termes génériques, c’est à dire que les objets retournés sont des instances de Reference et
Relation. Elle donne aussi accès auRelationObserver, moniteur de l’ap-parition et disl’ap-parition de relations dans le système contraint. Elle permet aussi à l’utilisateur d’obtenir pour une référence issue de l’implémentation du système architectural, laReferenceéquivalente générique.
pour la désignation d’éléments d’architecture :
• Reference: chaque spécialisation de cette classe est destinée à désigner un élément d’architecture dans le système contraint (composant, méthode, in-terface, service etc...),
• Link et Node : ces classes servent à construire un chemin (alternance de
Linket deNodechainés) décrivant une navigation, par rapport à un élément de départ dans le système contraint pour désigner un ensemble d’éléments d’architecture. Elles doivent être spécialisés pour tenir compte des différents types de relations qui existent dans le système contraint (enfants de Link, connexion, contenance etc...), et des différentes propriétés qui peuvent servir à filtrer les éléments du système (enfants deNode, nom de l’élément, etc...) à chaque étape de la navigation.
pour l’observation du système :
• ObservationDescription: la description d’une observation peut être spé-cialisée pour tenir compte de spécificités des classesTrigger,Data, Observa-tionNotifierpropres à un type d’architecture donné,
• Trigger: la nature du déclencheur des observations est lié à celle des événe-ments qui se produisent dans le système contraint, il doit donc être spécialisé pour chaque type d’événement différent et mettre en oeuvre les ressources appropriées d’observation du système concret (interception d’appel de méth-ode, de message non fonctionnel, etc...),
• Data: les données qui peuvent être lues sur un système dépendent de sa nature concrète, les ressources à mettre en oeuvre pour les obtenir dépen-dent naturellement aussi de l’implémentation du système observé. Il peut s’agir de paramètres échangés, de références à des éléments d’architectures, d’attributs de ces derniers etc...
• ObservationNotifier: permet d’enregistrer le lien entre un ou des obser-vateurs (Watcher) et une requête d’observation (ObservationDescription) : suivant la nature des ressources mises en oeuvre dans le cadre des observa-tions cet objet peut proposer des politiques d’économies de ces dernières en mutualisant les requêtes d’observation identiques faites par plusieurs obser-vateurs, en relachant immédiatement une ressource d’observation dès lors qu’elle n’a plus d’observateurs etc...
pour la description du motif d’architecture :
• Relation : cette classe est utilisée pour décrire une configuration archi-tecturale donnée, faite de Reference liées par des Relation. En partic-ulier chaque instance de motif d’architecture est composée d’un ensemble de
Referenceet des relationsRelationqui les relient.. Ainsi suivant la nature de l’architecture cette classe doit être spécialisée pour prendre en compte les différents types de relations (connexion, inclusion ...) apparaissant dans le système.
Fractal. Dans le cas du modèle de composants Fractal, ces classes sont spécialisées de la manière suivante :
description et désignation de l’architecture :
Nous avons montré, dans la partie "Mise en oeuvre du modèle de contrat", com-ment les classesReference Link Nodedevaient être spécialisées :
• Reference:FractalComponentReferenceetFractalInterfaceReference
possèdent une référence vers un composant et une interface Fractal, tandis que FractalMethodReferencedésigne une interface Fractal et une méth-ode (au sens java du terme),
• Link: les objetsLinksont des objets fonctions qui partant d’uneReference
retournent celles qui sont liées à celle-ci via une relation donnée. Ils utilisent les fonctionnalités d’introspection de la plate-forme Fractal pour obtenir les éléments connectés à un autre, inclus dans celui-ci ou l’incluant,
• Node: les spécialisations deNodepour Fractal sont aussi des objets fonctions capables de trier desReferencesur la base de certaines propriétés. Pour ce faire elles utilisent les attributs exposés par les éléments Fractal (composant et interface), ainsi que java (pour les méthodes). Les noms utilisés comme paramètres de filtrage par unNodepeuvent être remplacés par le caractère générique "*",
• ArchitectureDescription: comme cette classe permet l’introspection du système contraint, elle utilise dans le cas de Fractal les fonctionnalités d’in-trospection de cette plate-forme,
observation du système :
Les observations du système sont spécialisées de deux points de vue que nous avons abordés dans la partie "Mise en oeuvre du modèle de contrat" et utilisent différentes ressources de la plate-forme Fractal :
• le déclencheur : les événements pris en compte consistent en l’interception d’appel de méthode, qu’il s’agisse de méthode d’une interface fonctionnelle ou d’une interface non fonctionnelle (par exemple la requête de démarrage d’un composant). Pour ce faire nous avons utilisé un framework d’observa-tion de système de composants Fractal qui met en oeuvre des intercepteurs et des mixins, outils de tissage de code sur les composants. Ils permettent d’intercepter les appels sur, respectivement, les interfaces fonctionnelles et les interfaces de Controller. Intercepteurs et mixins sont des ressources de l’implémentation de référence Julia de Fractal,
• la valeur observée : elle est soit relative à l’exécution interceptée, soit rel-ative à l’architecture contrainte. Ainsi il est possible d’obtenir les valeurs des paramètres ou de la valeur de retour de la méthode, ou bien d’obtenir une référence sur l’appelant, ou de résoudre un chemin donné sur l’archi-tecture. Les valeurs relatives à l’exécution sont obtenues dans le cadre de l’interception, celles relatives à l’architecture sont issues de l’introspection de l’architecture Fractal.
ContractManager:
Dans le cas de l’application du système de contrat à la plate-forme Fractal, les
ContractManagerne sont pas gérés par le ContractSystemManagement. Pour préserver la modularité des composants Fractal, chaque composant composite possède intègre sous forme de Controller le ContractManagerqui va gérer les contrats entre ses sous composants. Il n’y a pas non plus de ContractManager
spécifique pour gérer les contrats entre les composants de plus haut niveau car il n’y a qu’un seul composant de plus haut niveau qui contient le tout le système.