Spécifications non-fonctionnelles appliquées aux services

La prise en compte des propriétés de QoS des services est d’autant plus importante qu’elle peut être l’objet de transactions commerciales entre client et fournisseur du service. Nous présenterons donc une des techniques les plus répandues pour exprimer ces propriétés sur les services.

2.4.5.1 Service Level Agreement

Une définition commune des Service Level Agreement est la suivante :

un accord sur la qualité de service passé entre un fournisseur et un util-isateur d’un service

Cet accord fait intervenir différentes dimensions destinées à expliciter et garantir l’u-tilisation du service. Le site de la société "ITIL & ITSM WORLD" fournit un ensemble

non exhaustif de celles-ci : "domaine de fonctionnement, performance, suivi et retour d’utilisation, gestion des problèmes, compensation, devoirs et responsabilités de l’u-tilisateur, garanties et solutions, sécurité, propriété intellectuelle, etc". Par défaut cet accord est l’objet de documents papier traditionnels, néanmoins avec l’automatisation de la mise en oeuvre de service il est naturel de voir leurs équivalents électroniques apparaître. Ainsi IBM propose sur son site une spécification des Web Service Level Agreement [66]. Appliqués aux Web Services, ces contrats reposent sur trois principes fondamentaux (Figure 2.5) :

• les parties impliquées dans le contrat • la description du service

• les obligations de chacune des parties par rapport à la description du service

FIGURE 2.5 – SLA

Parties impliquées Les parties impliquées par le contrat sont de deux types. Il s’agit : • soit des signataires, c’est-à-dire le consommateur et le fournisseur de service, • soit de contributeurs autorisés par les signataires pour effectuer les mesures, la

vérification des obligations à respecter, ou la coordination des actions d’une par-tie,

La description du service La description du service repose sur un ensemble de Ser-viceObject, dont chacun définit un ou plusieurs SLAParameter. Chaque SLAParame-ter correspond à une grandeur, associée à une métrique qui a pour objet de définir la manière dont sa valeur est mesurée, ou évaluée à l’aide d’une fonction. Par ailleurs,

cette métrique peut être composite et s’appuyer sur d’autres. La classe ServiceObject sert de classe de base aux classes de description d’opération OperationDescription. Ces classes décrivent les opérations du service de manière classique (WSDL : nom, signa-ture...) tout en leur associant des SLAParameters.

Voici un exemple de SLAParameter :

<SLAParameter name="TransactionRate" type="float"

unit="transactions / hour"> <Metric>Transactions</Metric> </SLAParameter>

La mesure de la valeur du paramètre fait appel à la métrique Transactions qui définit les fonctions d’évaluation. Un exemple de description d’opération est donné en an-nexe.

Les Obligations Les obligations sont de deux types :

• le Service Level Objective décrit des contraintes sur les valeurs des SLAParame-ters pour une certaine période. Le garant de cette obligation est spécifié par son attribut "obliged", c’est le provider. Par contre, une autre entité que le provider peut être sollicitée pour l’évaluation de la condition décrite par le Service Level Objective. Un exemple en est donné en annexe.

• le ActionGuarantee décrit l’engagement d’effectuer une certaine action dans une situation donnée ; classiquement quand un certain événement est détecté, un ap-pel de service ou une notification doit être effectuée. Un exemple en est donné en annexe.

2.4.5.2 Cycle de vie des SLA

Différents travaux ont étudié le cycle de vie des SLA. De manière récurrente nous statons que certaines phases leur sont communes. Comme point de départ nous con-sidérerons le cycle de vie des SLA dans le cadre du framework WSLA [55] :

1. Négociation et établissement du SLA : dans cette phase, les différents intervenants du SLA sont désignés, les paramètres et leurs métriques sont définis, les con-traintes qui forment les obligations des participants par rapport à ces grandeurs sont fixées. Un document complet décrivant le SLA est ainsi obtenu.

2. Déploiement du SLA : chaque signataire du SLA informe les tierces parties (chargées des mesures etc) de leur rôle (mesure de paramètres, vérification de contraintes etc).

3. Mesures et vérifications des contraintes : les tierces parties en charge des mesures les effectuent, ces dernières sont utilisées par les services dédiés à la vérification des contraintes du contrat pour évaluer celles-ci.

4. Actions correctives : le service de gestion du SLA obtient de celui-ci les actions à effectuer en cas de violation et il les applique au système contraint.

Par ailleurs, lors de la phase de déploiement du SLA il est possible d’ajouter le provi-sionnement de ressources [25] rendu nécessaire par les Service Level Objective du côté du fournisseur de service.

2.4.5.3 Bilan

L’approche des WSLA est intéressante car elle n’est pas initialement issue de besoins de génie logiciel. Au contraire, elle concrétise les préoccupations d’utilisateurs finaux vis-à-vis de la qualité de service. Ils ont l’avantage de présenter une logique générique par rapport à leur plateforme d’application. Par ailleurs, bien qu’assez verbeux du fait de l’utilisation d’XML, ils ne font pas intervenir de formalismes complexes. L’utilisation de métriques pourrait rendre envisageable la comparaison statique de spécifications à la manière dont QML procède. Toutefois seule la conformité du service à sa spécifica-tion est explicitement envisagée, bien qu’elle soit augmentée d’une nospécifica-tion de réacspécifica-tion à sa non-satisfaction.