Service

Dans le domaine des services le contrat prend une importance particulière. En effet l’utilisation de services s’intègre dans des processus métier qui sont contraints par des critères tant non fonctionnels que fonctionnels. La simple description des interfaces ne suffit plus, l’objet des contrats est initialement dans ce cadre de limiter le risque que prend l’utilisateur d’un service tant du point de vue fonctionnel et que non fonctionnel.

SLA.Un métamodèle de contrat du type Service Level Agreement, SLA, a été proposé ([54]) avec la préoccupation de s’appliquer à des services à l’évolution dynamique. Le contrat réifié (figure 2.18) est constitué de trois types de composantes. Il possède une description du service ainsi que des participants au contrat, c’est à dire le fournisseur et les clients du service. Il contient aussi l’ensemble des contraintes (Guarantee), sur des grandeurs de QoS (QoSParameterDefinition), qui sont garanties par le four-nisseur. Ce modèle a la particularité d’autoriser l’ajout et le retrait dynamique de con-traintes (Guarantee). Toutefois, il n’exprime que la conformité d’un service à sa spé-cification et non une compatibilité entre des services. Enfin, la responsabilité vis à vis des garanties est implicitement celle du fournisseur de service bien que d’autres ac-teurs soient présents dans le contrat.

FIGURE 2.18 – modèle de contrat pour des services dynamiques

WSLA. WSLA [66] est un langage de description de SLA pour les WebServices conçu par les mêmes chercheurs que le précédent modèle, mais plus évolué. A nouveau le contrat est composé de trois parties (figure 2.19). Une partie contient les participants

au contrat, qui en plus des clients et du fournisseur, comprend des services tiers inter-venant dans la vérification des clauses du contrat. Une seconde partie du contrat con-tient l’objet du service contraint sous forme d’un ensemble de paramètres de qualité de service, qui peuvent être mesurés par des participants tiers. Enfin le contrat présente un ensemble d’obligations portant sur ces paramètres qui peuvent être évaluées par des participants tiers. Il faut noter que les obligations sont non seulement des contraintes sur les paramètres mais aussi des obligations d’actions. Par ailleurs ces obligations peuvent être associées à n’importe quel participant du contrat, client ou fournisseur, le contrat exprime donc plus que la satisfaction d’un service à une spécification. On peut aussi remarquer que dans [55], le cycle de vie complet du contrat est détaillé, depuis sa négociation jusqu’à sa terminaison.

FIGURE 2.19 – modèle de contrat WSLA

WS-Agreement.Le WS-Agreement [7] est un langage basé sur XML destiné à exposer ce qu’un fournisseur de service propose, à permettre la passation d’un accord sur cette base et le monitoring de celui-ci à l’exécution du service. Un agreement contient trois parties. La première nommée contextspécifie les participants de l’accord mais aussi entre autres sa durée. La seconde, les Service Description Terms décrit en particulier des grandeurs mesurables associées au service, par exemple un temps de réponse. Finalement la troisième partie d’unagreementcontient les Guarantee

Terms qui sont les contraintes sur les propriétés du service, éventuellement

condi-tionnées par des Qualifying Conditions. C’est la même syntaxe qui est utilisé pour décrire ce qu’un fournisseur propose, unagreement offer, et ce que l’accord prévoit que le service effectue, l’agreement. Par exemple, dans le premier document peuvent se trouver des alternatives qui sont résolues pour aboutir au second docu-ment. Les travaux [4] proposent une formalisation des WS-Agreements. En particulier les auteurs modélisent à l’aide d’un automate les différents états de l’agreementsur la base d’une formalisation de celui-ci. En effet l’agreement est défini comme com-posé d’un ensemble de termes, chacun combinaison d’un service et d’une garantie, ces derniers ayant leurs états propres dont on déduit celui du terme. Par ailleurs les au-teurs proposent des termes de l’accord réagissant à l’ouverture de ce dernier pour en

modifier d’autres et ainsi le rétablir. Le cycle de vie de l’accord est ainsi celui décrit dans la figure 2.20, un état Revisitedreprésente l’accord modifié après rupture. Ainsi ce type de contrat est intéressant, car bien qu’il ne porte que sur la satisfaction d’une spé-cification par un service, il présente des clauses de renégotiation qui portent sur lui même et explicite son cycle de vie.

FIGURE 2.20 – cycle de vie de WS-Agreement étendu

Contrats et composition. Dans [74] les auteurs considèrent les contrats comme des outils de spécification des web services. Ils proposent un langage de description des contrats, réifiant un large éventail de propriétés des services. Celles ci comprennent la description fonctionnelle du service, son comportement (pré et post conditions), ses performances, sa fiabilité, etc... . L’intérêt de cette approche est qu’elle propose une méthodologie pour déduire le contrat d’une composition de services des contrats des services individuels. Ils traduisent pour ce faire les contrats en machines B (figure 2.21) dont les termes, c’est à dire les propriétés du contrat, supportent des annotations décrivant leur évolution en cas de composition. Par la suite, pour chaque opérateur de composition, on définit pour chaque propriété, le résultat de sa composition suiv-ant son annotation, afin de déduire la machine B résultsuiv-ante, et par suite le contrat de la composition. Diverses vérifications doivent être effectuées pour valider la compati-bilité des contrats, la satisfaction des invariants par celui résultant etc. Le trait remar-quable de cette approche est qu’elle définit d’une part des opérations de composition sur les contrats, et d’autre part qu’elle établit une correspondance entre les opérations sur l’architecture et celles sur les contrats. Par ailleurs les opérateurs de composition ne sont pas limités, leur sémantique étant définie par rapport à l’évolution des propriétés composées.

Contrats et politiques. Dans [86] les contrats contraignent les relations entre les ob-jets exposés par les services de processus métiers. Ils sont composés (figure 2.22) de participants qui y jouent des rôles (Who), de leurs objets qui sont les relations entre ce qu’exposent les participants (What), et des contraintes à vérifier sur ces relations pour que le contrat soit rempli (How). Il faut toutefois noter que les contraintes à vérifier sont exprimées sous formes de règles ECA associées à la relation qui doivent être exécutées pour que celle-ci soit satisfaite. Par exemple, une relation spécificiant qu’un service de réservation de billet (SRB) émet un billet est :

"émettre (SRB, billet)"

cette relation est contrainte sur sa date par : Evénement : émettre (SRB, billet)

FIGURE 2.21 – méthodologie de composition des contrats

Action : autoriser (émettre (SRB, billet))

Ces contrats expriment la validité de relations, et donc la compatibilité, au sens large entre services et/ou objets des services. Mais ils se rapprochent plutôt de politiques car la vérification des relations guide des actions à effectuer sur le système.

Conclusion :

Par rapport à ceux sur les objets et composants, les contrats sur les services réifient clairement les rôles et les responsabilités des participants. Les cycles de vie de ces contrats sont aussi beaucoup plus clairement définis et des métriques de grandeurs contraintes presque systématiquement définies. Par contre, ils ne sont que rarement orientés vers la vérification de la compatibilité entre des services au sein d’une compo-sition.