Sla

Rapport de projet de Master 2 Recherche Systmes et Logiciels
Universit Joseph Fourier (Grenoble 1)
Accords de niveau de service dans les plateformes dynamiques services
Soutenu par: Lionel TOUSEAU le 21 juin 2005 devant: Jolle COUTAZ Jean-Franois MHAUT Rachid ECHAHED Patrick REIGNIER (Rapporteur) Didier DONSEZ (Directeur)
ralis dans l'quipe ADELE du laboratoire LSR-IMAG de Grenble
Rsum
Les plates-formes dynamiques services occupent une place de plus en plus prpondrante dans l'industrie. Ces plates-formes permettent la ralisation d'applications dont l'architecture suit les paradigmes des architectures orientes service. Elles sont le support d'excution pour des services qui apparaissent et disparaissent au cours de l'excution d'une application. Le niveau de service garanti par des fournisseurs de services est galement une proccupation de plus en plus importante. Le niveau de service peut faire l'objet d'un accord entre les fournisseurs et leurs clients. Cet accord de niveau de service est tabli aprs la ngociation d'un contrat. Dans le contexte des plates-formes dynamiques de services, l'accord doit tenir compte de la dynamique des services qui apparaissent et disparaissent souvent de manire imprvisible. Un des principaux verrous lever dans ce problme est la prise en compte de la dynamique des services dans les accords de niveau de service. L'objectif du travail prsent dans ce document est de proposer et d'valuer des solutions ce verrou. Mots cls: Architecture oriente service, plateformes dynamiques services, disponibilit dynamique, accords de niveau de service, contrat, rseaux d'quipements, OSGi, services Web.
Abstract
Dynamic service platforms are spreading more and more in the industry. These platforms enable the design of systems following the paradigms of Service-Oriented Architectures. A dynamic service platform is a framework supporting the execution of services which can appear and disappear at runtime. The service level guaranteed by the service providers is of a growing interest. It can be represented by an agreement made between the service providers and their consumers called Service Level Agreement. The agreement is the result of a contract negociation. In the context of dynamic service platforms, it must take into account the dynamics of services which can appear or disappear unexpectedly. Among numerous problems, the main issue is the support of dynamic services in the Service Level Agreements. The goal of our work is to submit and evaluate solutions to this issue. Keywords: Service-Oriented Architecture, SOA, dynamic service platforms, dynamic availability, Service Level Agreements, SLA, contract, networked devices, OSGi, Web Services.
Remerciements
Je tiens remercier toutes les personnes de lquipe ADELE du laboratoire LSR pour mavoir accueilli lors de ce stage et permis dacqurir une exprience enrichissante. Je tiens remercier particulirement : M. Patrick Reignier pour avoir accept de rapporter ce travail. Tous les membres du jury qui ont accept dvaluer mon travail. M. Didier Donsez pour mavoir encadr et pour ses conseils. M. Philippe Lalanda pour avoir galement particip mon encadrement. M. Jacky Estublier pour mavoir donn la possibilit de travailler dans son quipe. Mikal Desertot, Clment Escoffier et Johann Bourcier pour m'avoir fait partager leur exprience. Laureline, pour sa patience et le soutien qu'elle m'a apport tout au long de cette anne. Mes parents qui m'ont permis de poursuivre mes tudes grce leur soutien moral et financier. Ainsi que tous ceux que j'aurais pu oublier.
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services
Table des matires

1.Introduction....................................................................................................................................... 9 1.1.Contexte..................................................................................................................................... 9 1.2.Problmatique............................................................................................................................ 9 1.3.Structure du document............................................................................................................... 9 2.Etat de l'Art......................................................................................................................................10 2.1.Architectures orientes service dynamiques............................................................................10 2.1.1.Dfinition et concepts...................................................................................................... 10 2.1.1.1.Notion de service......................................................................................................11 2.1.1.2.Architecture Oriente Service.................................................................................. 11 2.1.1.3.Architecture oriente service dynamique................................................................. 13 2.1.2.Plateformes services dynamiques..................................................................................15 2.1.2.1.Jini............................................................................................................................ 15 2.1.2.2.Services Web ...........................................................................................................16 2.1.2.3.Universal Plug and Play........................................................................................... 18 2.1.2.4.Devices Profile for Web Services............................................................................ 19 2.1.2.5.La plateforme OSGi................................................................................................. 20 2.2.Contrats....................................................................................................................................22 2.2.1.Dfinitions et concepts.....................................................................................................22 2.2.1.1.Definition gnrale................................................................................................... 22 2.2.1.2.Le contrat dans les architectures orientes service...................................................22 2.2.1.3.Ngociation de contrat..............................................................................................24 2.2.2.Le contrat sur les diffrentes plateformes services....................................................... 24 2.2.2.1.Jini............................................................................................................................ 24 2.2.2.2.Services Web............................................................................................................25 2.2.2.3.UPnP / DPWS.......................................................................................................... 25 2.2.2.4.OSGi.........................................................................................................................25 2.3.Accords de niveau de service ..................................................................................................26 2.3.1.Dfinition et concepts...................................................................................................... 26 2.3.2.Travaux acadmiques.......................................................................................................28 2.3.2.1.RBSLA: Rule-based Service Level Agreement (ContractLog)............................... 28 2.3.2.2.SLAng...................................................................................................................... 30 2.3.3.Un standard mergeant: Web Service Level Agreements................................................30 2.4.Synthse................................................................................................................................... 33 3.Prise en compte de la dynamique dans les accords de niveau de service........................................35 3.1.Identification des problmes soulevs..................................................................................... 35 3.1.1.Modlisation de l'accord et smantique........................................................................... 35 3.1.2.Contractualisation du comportement d'un service........................................................... 36 5 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services 3.1.3.Composition de services et sous-contractants..................................................................36 3.1.4.Ngociation et slection du contrat.................................................................................. 36 3.1.5.Rengociation de contrat..................................................................................................37 3.1.6.Restitution de l'tat et du contexte, contrat persistant...................................................... 37 3.1.7.Service Level Management et auditeur tiers....................................................................38 3.1.8.Pnalits et facturation..................................................................................................... 38 3.1.9.Confidentialit des ngociations...................................................................................... 38 3.1.10.Impact de la dynamique sur les accords de niveau de service....................................... 39 3.2.Notre contexte: les rseaux d'quipements.............................................................................. 40 3.3.Scnarios de ngociation d'accords de niveau de service sur des plateformes dynamiques services...........................................................................................................................................42 3.3.1.Rengociation de contrat dans un environnement ressources limites et fluctuantes...42 3.3.1.1.CPU et mmoire vive limits................................................................................... 42 3.3.1.2.Energie limite......................................................................................................... 43 3.3.2.Ngociation de la disponibilit dynamique d'un service, continuit de service et contrat persistant................................................................................................................................... 44 3.3.3.Stabilit de l'architecture, dynamique dans un ensemble statique................................... 44 3.4.Modle d'architecture dynamique oriente service supportant les accords de niveau de service ....................................................................................................................................................... 46 3.4.1.Vue gnrale.................................................................................................................... 46 3.4.2.SLA.................................................................................................................................. 47 3.4.3.SLAService...................................................................................................................... 48 3.4.3.1.Proxy dynamique et sla.<service pid>..................................................................... 48 3.4.3.2.Intercepteur...............................................................................................................48 3.4.4.SLMService..................................................................................................................... 49 3.4.5.Auditeurs tiers.................................................................................................................. 49 3.4.6.ContractProposalService.................................................................................................. 50 3.4.7.Proposition pour une architecture rpartie....................................................................... 50 3.5.Modle d'accords de niveau de service supportant la disponibilit dynamique...................... 51 3.5.1.Les parties........................................................................................................................ 51 3.5.2.Les paramtres SLA.........................................................................................................53 3.5.3.Les pnalits.....................................................................................................................53 4.Exprimentation et validation de notre modle d'architecture........................................................ 55 4.1.Scnario du prototype.............................................................................................................. 55 4.2.Choix de la plateforme.............................................................................................................56 4.3.Architecture du prototype........................................................................................................ 56 4.4.Validation.................................................................................................................................57 5.Conclusion et perspectives.............................................................................................................. 59 5.1.Positionnement de notre contribution...................................................................................... 59 5.2.Perspectives court terme....................................................................................................... 59 6 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services 5.3.Perspectives long terme........................................................................................................ 60 6.Bibliographie................................................................................................................................... 61 7.Glossaire.......................................................................................................................................... 65
7 / 65
Index des figures

Figure 1. Acteurs classiques d'une architecture oriente service....................................................... 12 Figure 2. Patron d'interaction d'une architecture oriente services [Cervantes2004].........................13 Figure 3. Architecture oriente service dynamique supportant la disparition de service...................14 Figure 4. Schma d'interaction de services Web [Donsez2001]........................................................ 17 figure 5. Exemple de rseau UPnP [Donsez2005]............................................................................. 19 Figure 6. Pile de protocoles pour DPWS [Jammes2005a]................................................................. 20 Figure 7. La liaison entre un usager et un fournisseur suit un contrat bi-parties............................... 23 Figure 8. Cas d'un contrat multi-parties............................................................................................. 23 Figure 9. Le certifieur de service valuation le respect de l'accord de niveau de service.................. 28 Figure 10. Architecture en couches de l'approche Rule Based SLA [Paschke2006]......................... 29 Figure 11. Les principaux concepts de WSLA [Ludwig2003]...........................................................31 Figure 12. Patron d'interactions du canevas WSLA [Keller2002]. ................................................... 32 Figure 13. Composition de services et sous-contractant.................................................................... 36 Figure 14. Vue oriente service du modle de rseau d'quipements................................................ 41 Figure 15. Modle d'architecture oriente service supportant les accords de niveau de service........47 Figure 16. Diagramme UML du patron proxy . ........................................................................... 48 Figure 17. Le SLA Manager fournit un service de proposition de contrat.........................................50 Figure 18. Notre modle UML de structuration des accords de niveau de service. ..........................52 Figure 19. Architecture de notre prototype pour un scnario de cotation boursire.......................... 56
8 / 65
1. Introduction
1.1. Contexte
Les plateformes dynamiques services occupent une place de plus en plus importante dans l'industrie, et plus particulirement dans le domaine des rseaux d'quipements. Les rseaux d'quipements sont un domaine relativement large allant des rseaux de capteurs industriels la domotique en passant par des quipements embarqus sur des vhicules. L'approche services est particulirement bien adapte dans ce contexte tant donn la grande diversit et l'htrognit d'quipements au sein d'un mme rseau. Il s'agit de plus d'un domaine o la demande en dynamique est trs forte. L'architecture de tels systmes doit pouvoir voluer dynamiquement au cours de l'excution sans porter prjudice aux quipements en cours d'excution sur la plateforme.
1.2. Problmatique
L'objectif de notre travail se situe l'intersection de trois domaines lis aux services. Il s'agit de prendre en compte la dynamique des services, caractristique des architectures dynamiques orientes service, dans les accords de niveau de service. Ces accords font gnralement l'objet d'un contrat entre le fournisseur et l'usager d'un service.
1.3. Structure du document

Le second chapitre tablit un tat de l'art des trois domaines concerns par le sujet: les architectures orientes service dynamiques, la notion de contrat, et les accords de niveau de service. Le chapitre 3 prsente ensuite notre travail, savoir une identification des problmes inhrents aux domaines tudis dans l'tat de l'art, une dfinition de l'objectif de nos travaux l'aide de scnarios, c'est--dire lever le verrou de la prise en compte de la dynamique des services dans les accords de niveau de service. Nous proposons pour cela un modle d'architecture oriente service dynamique prenant en charge la gestion des accords de niveau de service ainsi qu'un modle d'accords de niveau de service supportant la disponibilit dynamique. Nous exprimentons enfin notre modle afin de le valider dans le chapitre 4, puis nous dfinissons diffrents axes de recherche possibles ouverts par notre tude. Notation: Dans la suite du document nous utilisons le formalisme suivant: reprsente un service fourni et reprsente un service requis.
9 / 65
2. Etat de l'Art
Les accords de niveau de services dans le contexte des plateformes dynamiques services font intervenir plusieurs thmes de recherche. Tout d'abord, les plateformes dynamiques services relvent du domaine des architectures orientes services et plus particulirement des architectures orientes services dynamiques1. Les acteurs de ce domaine intragissent par l'intermdiaire de services. Et comme nous nous plaons dans un contexte ou les acteurs peuvent faire partie d'organisations diffrentes, leurs interactions doivent respecter des accords, appels accords de niveau de service2 qui prennent gnralement la forme de contrats. Notre travail porte sur l'intersection de ces trois domaines que nous tudions dans ce chapitre. Notons qu'en toile de fond de notre tude intervient le domaine de l'informatique autonomique, mais nous avons fait le choix de ne pas traiter ce problme qui fait dj l'objet de nombreuses recherches [Kephart2001], [Kephart2003] et [Sterritt2005]. Pour plus d'information sur ce sujet, le lecteur peut se rfrer au rapport men l'an dernier par Clment Escoffier [Escoffier2005].
2.1. Architectures orientes service dynamiques

Aujourd'hui les entreprises travaillant dans le domaine des technologies de l'information font face une augmentation importante de la complexit de leurs systmes, ce qui implique de nombreux besoins. L'htrognit devient invitable et ne doit plus tre un frein. Des systmes historiquement indpendants, acquis grce des fusions ou l'acquisition d'autres entreprises, devraient pouvoir tre intgrs facilement, et interconnects sans gnrer un problme de multiplication des interfaces dues des liaisons point point [Channabasavaiah2004]. Ce type d'entreprise a acquis au fil du temps un large ventail d'applications patrimoniales qu'elle doit galement pouvoir rutiliser facilement plutt que tout rinventer. En outre, le dveloppement de nouveaux systmes gagnerait tre plus facile et plus rapide. Une meilleure utilisation des ressources, en vitant les applications monolithiques trop complexes et en privilgiant la modularit et la rutilisation, permettrait galement un plus grand retour sur investissement. Une solution de plus en plus adopte est l'approche oriente service. Elle est mise en oeuvre sur des architectures orientes service. Ce type d'architecture favorise l'utilisation de patrons architecturaux [Stal2006] pour faciliter l'intgration d'applications.
2.1.1. Dfinition et concepts

Cette section dfinit la notion de service comme brique de base des architectures orientes service et par extension des architectures dynamiques.
1 En anglais, Service Oriented Architecture (SOA) et Dynamic Service Oriented Architecture (DSOA) 2 En anglais, Service Level Agreements (SLAs)
10 / 65
2.1.1.1. Notion de service
La littrature propose un grand nombre de dfinitions pour le terme service. Retenons qu'un service est une brique logicielle dont les fonctionnalits, les proprits non fonctionnelles ainsi que les conditions d'utilisation sont dfinies de manire dclarative par un descripteur de service. Un service peut se suffire lui-mme, toutefois il peut tre publi et rendu disponible pour tre utilisable par des tiers. Ainsi des services peuvent tre utiliss tels quels ou bien tre composs pour excuter une fonctionnalit de plus haut niveau, voire orchestrs pour mener terme un processus complexe et atteindre un objectif prcis. Grce aux mcanismes d'encapsulation et de liaison retarde, un service peut-tre dcrit et utilis indpendamment de sa ralisation. La liaison proprement dite n'est effectue qu'au moment de l'excution, juste avant que le service requis ne soit utilis. De ce fait on a un couplage extrment faible entre services et l'interoprabilit de systmes en environnements htrognes, matre mot de l'approche service, est ainsi facilite. Un service est dcrit par son descripteur de service, sa spcification en quelque sorte. Le descripteur peut tre compos: d'informations fonctionnelles: la smantique des oprations le comportement du service (pr-condition, post-condition, invariant, exception, proprits) l'interface du service d'informations non-fonctionnelles: prix, politique, spcification des mesures de la qualit de service, information de dploiement, etc. d'informations additionnelles composes d'informations sur le service, non spcifies par le fournisseur du service: mesure de qualit de service qui peut tre effectue par un certifieur de service note, rapport d'utilisation (par le certifieur ou l'usager).
2.1.1.2. Architecture Oriente Service
Le SOA peut tre la fois une architecture au sens propre du terme et un modle de programmation. Ce modle comble le manque de canevas architectural permettant de guider la conception, dvelopper, intgrer et rutiliser des applications plus facilement et plus rapidement. De plus, comme le domaine de mtier d'une entreprise est en constante volution, les systmes de cette entreprise doivent suivre cette volution pour rpondre de nouveaux problmes. Une architecture oriente service permettrait d'assembler des composants et des services pour construire et fournir dynamiquement des solutions ces problmes. La figure 1 illustre une vision simpliste d'une architecture oriente service et des interactions entre les diffrents acteurs. C'est auprs d'un composant appel registre de services ou courtier de service que les fournisseurs de service exposent leurs services grce leurs descripteurs de service. L'usager interroge le registre pour dcouvrir et slectionner le service qui rpond ses exigences. La liaison entre l'usager et le fournisseur d'un service est ralise une fois que des accords concernant l'utilisation du service sont tablis. La figure 2 dcrit de manire plus dtaille les interactions entre ces acteurs et les diffrentes tapes ncessaires la publication et l'utilisation d'un service. Pendant la phase de ngociation de ces accords, un quatrime acteur peut apparatre: le 11 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services certifieur de service, charg de surveiller le respect de ces accords. Sur ce dernier point la recherche est encore peu dveloppe. Registre de Service
recherche publication
Usager du Service
interactions
Fournisseur de Service
Figure 1. Acteurs classiques d'une architecture oriente service
Une architecture oriente service doit donc mettre disposition des mcanismes de publication, de recherche (aussi appele courtage) et dinvocation de service. Il existe d'autres mcanismes plus complexes dont nous ne dtaillerons pas le fonctionnement, dont la substitution qui permet un usager de substituer au cours de l'excution une instance de service par une autre instance de ce mme service. L'invocation de service doit suivre un contrat dfini entre le demandeur et le fournisseur. La notion de contrat est prsente plus en dtail dans la section 2.2. Enfin retenons que l'architecture oriente services, en tant qu'architecture, est indpendante du domaine d'application. Cependant des instances de cette architecture, spcifiques un domaine, sont ncessaires pour la construction de systmes concrets [IST2006].
12 / 65
Figure 2. Patron d'interaction d'une architecture oriente services [Cervantes2004]
2.1.1.3. Architecture oriente service dynamique
L'architecture oriente service dynamique ajoute l'aspect dynamique l'architecture oriente service classique. Elle est gnralement ralise sur des plateformes dynamiques service. Lorsqu'on parle de systme dynamique, on parle souvent de la capacit du systme ragir aux changements du contexte [Redmond2002] [Coutaz2005] et d'applications pilotes par des vnements. Dans le cadre d'architectures orientes service, un changement de contexte peut se traduire par l'arrive ou le dpart de services sur une plateforme, ou bien par leur mise jour par exemple. On parle dans ce cas-l de disponibilit dynamique [Cervantes2005]. A l'chelle des services ce peut aussi tre leurs proprits ayant servi au courtage qui changent dynamiquement au cours de l'xcution. En pratique le changement dynamique de proprits concerne les informations non-fonctionnelles et additionnelles contenues dans le descripteur de service. 13 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services Les proprits d'un service peuvent changer au cours de l'excution. On peut facilement imaginer qu'un service supportant n clients expose le nombre de clients qu'il peut accepter lorsqu'il est publi, et qu'au fil de l'excution il modifie cette valeur chaque fois qu'un client arrive ou repart. Cette capacit est particulirement utile dans le cadre de ngociation ou d'adaptation dynamique au contexte. La disponibilit dynamique est dfinie comme le fait quun service puisse devenir indisponible ou disponible tout moment pendant quun usager qui lutilise ou qui pourrait lutiliser est en cours d'excution. Pratiquement, de nouveaux services peuvent tre publis tandis que d'autres se dsenregistrent et ceci pendant l'excution du systme. Un service peut galement revenir, c'est-dire devenir indisponible puis se renregistrer et redevenir nouveau disponible et utilisable; ce qui rend l'architecture dynamique. L'usager du service est alors prvenu des disparitions et rapparitions de certains services par une notification (voir figure 3).
Annuaire de Service
notification du retrait
retrait
Usager du Service
Interaction
Fournisseur du Service
Figure 3. Architecture oriente service dynamique supportant la disparition de service. La disponibilit dynamique d'un systme prsente plusieurs avantages, entre autres des services la demande et la possibilit de dploiement chaud . Le systme peut voluer sans tre arrt et donc sans pnaliser les applications en cours d'excution, ce qui rend possible la maintenance de systmes devant s'excuter sept jours sur sept. Un tel besoin est courant, que ce soit dans le domaine des technologies de l'information1 avec les serveurs d'organismes comme Yahoo2 ou eBay3, ou dans les systmes embarqus. Toutefois il faut prendre en compte l'aspect nonfonctionnel de la dynamique dans la phase de dveloppement, ce qui n'est pas trivial. Le dveloppeur doit savoir construire des applications capables de s'arrter mais aussi de redmarrer. Le chapitre suivant prsente une tude de certaines plateformes services dynamiques qui, prennent en charge une partie de la gestion de la dynamique.
1 En anglais, IT (Information Technology) 2 http://www.yahoo.com/ 3 http://www.ebay.com/
14 / 65
2.1.2. Plateformes services dynamiques

Cette section prsente une tude des principales plateformes dynamiques services permettant la ralisation d'applications dont l'architecture suit les paradigmes du SOA et volue dynamiquement en cours d'excution. Nous dtaillons dans cette section les principales d'entre elles: Jini, les services Web, Universal Plug and Play, Devices Profile for Web Services et OSGi.
2.1.2.1. Jini
Jini1 est la plateforme services promue par Sun. Base sur Java, elle permet le tlchargement de code et la srialisation ce qui en a fait une plateforme distribue utilise pour les applications rparties. Une autre caractristique de Jini est que usagers et fournisseurs de services doivent trouver un registre avant de commencer interagir. Un registre, qui correspond en pratique un service de recherche, peut tre connu par une adresse fixe ou bien il peut tre dcouvert. Pour cela, les diffrents acteurs (usagers et fournisseurs de service) diffusent une annonce de prsence. Cette annonce est coute par les services de recherche qui rpondent aux annonces et se font connatre. Par la suite, ce sont ces services de recherche qui seront utiliss comme registres. Les services dans Jini peuvent tre organiss par groupes (par exemple groupe services dimpression) et un registre peut hberger un groupe de services particulier. Bien que Jini supporte lexistence de registres multiples, il noffre pas de mcanismes permettant aux registres de dlguer une demande de service. Au lieu de cela, les fournisseurs de services enregistrent leur services dans plusieurs registres. L'information envoye au service de recherche comprend : Une instance d'une classe qui implmente l'interface du service, qui permet d'utiliser les services proposs. Ceci inclut notamment les dclarations des mthodes pouvant tre utilises. De faon optionnelle, des attributs du service peuvent aussi tre envoys. Descripteur de service: Dans Jini, un service est dcrit par une interface Java et un nombre variable d'attributs, qui sont des objets de sous-classes de la classe Entry. Registre: Il est distribu entre plusieurs services de recherche. Une fois un service de recherche 2 trouv, le fournisseur de service peut y enregistrer son service. Pour retirer un service, le fournisseur peut attendre la fin du bail ou bien forcer son expiration. Dcouverte / recherche: La dcouverte de services se fait par interrogation du registre qui a rpondu l'annonce. Jini ne propose cependant pas de mcanismes flexibles du ct du registre pour raliser un filtrage et une slection plus fine des fournisseurs. Le critre pour dterminer si un service correspond une demande est que les interfaces du service concident avec celles demandes et que les valeurs d'attributs envoyes par le demandeur soient identiques celles prsentes dans la description du service. Liaison: Elle se fait par le protocole RMI. L'interaction consiste en des appels de mthodes passant par des proxys3.
1 http://www.jini.org/ 2 Appel lookup service 3 Qui sont appels stubs et skeletons
15 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services Notifications: Jini fournit des mcanismes de notification asynchrones permettant aux clients dtre informs des changements au niveau de la disponibilit des services.
2.1.2.2. Services Web
Le terme service est de plus en plus associ aux services Web [Malloy2006] qui sont devenus un standard de fait. Ce succs est du au fait que les services Web abordent un domaine o le besoin est trs fort, et ce pour les raisons voques en introduction de la section 2.1. En effet les services Web permettent des applications htrognes sexcutant au sein de diffrentes entreprises de pouvoir interoprer travers des services offerts par les applications. Or l'utilisation de standards tels que XML facilit l'encapsulation et par consquent l'interoprabilit [Motahari2006]. Pourtant, bien que la plateforme services web soit fonde sur les concepts de lapproche services, linteraction propre cette approche nest pas toujours suivie de faon systmatique. Il faut aussi souligner que linteraction de services dans les services web est ralise sur une chelle de temps diffrentes des autres plateformes prsentes dans cette tude. C'est une des raisons qui fait que certaines organisations n'utilisent pas le registre pour publier leurs services. La description des services web est ralise dans un langage appel WSDL1. WSDL est bas sur une grammaire XML et permet de dcrire linterface du service, les types de donnes employs dans les messages, le protocole de transport employ dans la communication et des informations permettant de localiser le service spcifi. Le registre de services, appel UDDI2 supporte lenregistrement de descriptions de services (appels types de services) ainsi que de fournisseurs de services (des entreprises). UDDI fournit des moyens de publier un fournisseur de service (typiquement une entreprise) travers des pages blanches, jaunes et vertes. Les pages blanches contiennent le nom du fournisseur et sa description, les pages jaunes catgorisent un fournisseur et les pages vertes, plus techniques, dcrivent les moyens dinteraction avec un fournisseur: description de services fournis en WSDL ou processus mtiers. UDDI est un registre distribu dans lequel linformation est rplique sur plusieurs sites, en consquence, un fournisseur de services ne doit publier sa description de service que vers un seul noeud du rseau de registres. Le protocole de communication par dfaut est SOAP3. SOAP enveloppe le message dans un format XML. Il est la plupart du temps utilis sur la couche de transport HTTP. L'interaction est schmatise par la figure 4.
1 Web Services Description Language 2 The Universal Description, Discovery and Integration 3 Simple Object Access Protocol
16 / 65
Figure 4. Schma d'interaction de services Web [Donsez2001]
La disponibilit dynamique n'est pas intgre directement la plateforme des services Web. Comme UDDI n'est pour le moment que trs peu utilis et que sa partie vnementielle n'est que peu dveloppe, la dcouverte de service n'est pas dynamique et le systme de notifications n'est que trs rarement mis en pratique par les dveloppeurs de services Web. Donc si un service devient indisponible, la rponse la requte sera une erreur 404 Not Found. Les services Web sont galement utiliss conjointement avec SOAP pour la liaison de composants faiblement coupls dans SCA1 (Service Component Architecture). SCA est une solution mergeante dveloppe principalement par IBM, BEA et Oracle pour dfinir un modle de composant pour les architectures orientes service. Descripteur de service: Il est crit dans le langage WSDL bas sur une grammaire XML. Il fournit les informations suivantes: definitions : nom du service et espace de nommage types : description des types de donnes complexes message : description dun message. La description contient le nom du message et zro ou plus parties qui dcrivent les paramtres dans le cas d'une requte, ou les valeurs de retour dans le cas d'une rponse. portType : description dune mthode forme par un groupe de messages, par exemple une mthode combinant requte et rponse. binding : le protocole de transmission des messages service : emplacement du service, gnralement une URL.
1 http://www-128.ibm.com/developerworks/library/specification/ws-sca/
17 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services Registre: UDDI est un registre distribu dans lequel linformation est rplique sur plusieurs sites. Un fournisseur de services n'a par consquent publier sa description de service que vers un seul noeud du rseau de registres. L'annuaire UDDI est consultable de diffrentes manires. Chaque type de pages blanches, jaunes ou vertes donnent des informations de nature diffrentes. Respectivement des informations lies au fournisseur du service (gnralement une entreprise), une catgorisation des entreprises et des informations techniques plus prcises comme les services fournis et les processus mtiers associs. Dcouverte / recherche: La recherche se fait donc par interrogation du registre qui permet de trouver le service dsir et d'obtenir son URL. Liaison: L'usager peut grce au protocole SOAP interroger le service Web dsir une fois qu'il a rcupr son descripteur. Notification: UDDI supporte lenregistrement auprs du registre pour recevoir des notifications concernant des changements dans le registre: ajout, retrait et modification au niveau des services ou des entreprises.
2.1.2.3. Universal Plug and Play
UPnP1 [UPnP] a t cr pour fournir une infrastructure rseau transparente (voir figure 5) pour le SOHO2. Pouvoir changer, brancher ou dbrancher des quipements volont confre un tel rseau son caractre dynamique et phmre. Cet aspect dynamique oblige ce type de rseau viser le zro-administration. Pour cela, les noeuds (quipements) d'un rseau UPnP sont autoconfigurables et auto-descriptifs. Bas sur IP et autres standards d'Internet (TCP, UDP, HTTP et XML), UPnP est indpendant de la technologie utilise, que ce soit le canal de communication (Ethernet, WiFi, etc.), le systme d'exploitation, ou encore le langage de programmation utilis pour l'implmentation. Les noeuds sont soit des quipements, soit des points de contrle. Par exemple, un quipement pourrait tre un appareil d'clairage et un point de contrle serait une tlcommande ou un assistant personnel (PDA). Les quipements fournissent des services utilisables par les points de contrle et notifient ces derniers lorsqu'ils changent d'tat. Il n'y a donc pas de registre en tant qu'entit unique. La dcouverte est base sur le protocole SSDP (Simple Service Discovery Protocol). Pour dcouvrir un service, un usager, c'est--dire un point de contrle, recherche les quipements disponibles sur le rseau UPnP. L'quipement qui est auto-descriptif lui transmet alors le service qu'il propose via son descripteur de service, un fichier XML. Fonctionnement d'UPnP en 6 tapes: Equipements et points de contrle obtiennent des adresses IP pour participer au rseau. Un point de contrle recherche les quipements disponibles. Un point de contrle examine les aptitudes dun quipement. En parallle: Un point de contrle invoque une action dun quipement. Un point de contrle est notifi des changements dtat dun quipement. Un navigateur Web peut examiner un quipement via une interface HTML.
1 Universal Plug and Play 2 Small Office Home Office
18 / 65
Media Center Gateway X10-UPnP
IGD
WWW
Gateway IEEE1394 FireWire-UPnP
figure 5. Exemple de rseau UPnP [Donsez2005] Descripteur de service: Il contient des informations concernant le fournisseur de service, des icones utilisables par les points de contrle graphiques, une liste des services disponibles et les URLs (@IP et port) qui permettent de les utiliser. En particulier un lien vers un descripteur plus prcis dtaillant les variables d'tats de l'quipement, les actions disponibles ainsi que leurs paramtres. Registre: Il est distribu et repose sur le protocole de dcouverte SSDP1. Dcouverte / recherche: La dcouverte d'quipements et de services se fait grce un systme de diffusion de messages. Les messages de dcouverte contiennent quelques renseignements sur l'quipement ou un de ses services, par exemple son type, son identifiant ou un pointeur vers des informations plus dtailles. Liaison: Une fois que l'quipement a t dcouvert, le point de contrle peut agir dessus. L'appel se fait par HTTP / SOAP. Notifications: un point de contrle peut s'abonner aux quipements de la part desquels il souhaite recevoir des vnements sur les variables d'tat.
2.1.2.4. Devices Profile for Web Services
Bien que UPnP ait l'avantage d'tre indpendant des plateformes d'excution grce sa construction sur des standards d'internet (IP, TCP, UDP, HTTP, SOAP et XML), on peut lui reprocher d'utiliser des protocoles spcifiques pour la dcouverte de devices et les notifications ainsi qu'un langage spcifique de description de service et de device. L'approche de Devices Profile for Web Services2 conserve les avantages d'UPnP et est de plus totalement compatible avec la technologie des services Web. C'est le principal avantage de DPWS, les services fournis par les quipements se comportent comme des services Web. C'est pourquoi DPWS est en passe de devenir la base d'UPnP V2. DPWS est en effet un sous-ensemble de la spcifiaction des services Web qui permet des quipements3 d'utiliser ce mcanisme standard de l'industrie pour communiquer avec d'autres quipements, ordinateurs, et services Web sur Internet. La spcification DPWS dfinit deux types de services: les services d'hbergement (hosting services) et les services hbergs (hosted services). Un service d'hbergement est li un quipement et joue un rle primordial dans la phase de dcouverte, tandis qu'un service hberg
1 Simple Service Discovery Protocol 2 DPWS 3 En anglais, device
19 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services dpend de l'quipement qui l'hberge quant la phase de dcouverte. En plus de ces services, DPWS intgre un ensemble de services: les services de dcouverte qui permettent de diffuser une annonce et de dcouvrir d'autres quipements, les services d'change de mta-donnes qui fournissent un accs dynamique aux services hbergs par un quipement et ses mta-donnes, et les services de publicaion / souscription qui permettent des quipements de s'abonner aux messages produits par un service en particulier.
Figure 6. Pile de protocoles pour DPWS [Jammes2005a] La figure 6 prsente la pile de protocoles utiliss pour DPWS. En plus des protocoles classiques utiliss dans les services Web que nous ne dtaillerons pas ici (WSDL, SOAP, WS-Adressing, WSMetadataExchange, WS-Policy et WS-Security), DPWS ajoute des protocoles pour la dcouverte et les notifications. WS-Discovery, protocole multicast pour la dcouverte plug-and-play et ad-hoc d'quipements connects au rseau, permet de chercher, localiser des quipements puis d'exposer les services fournis par ces quipements. WS-Eventing, quant lui, dfinit un protocole pour la prise en charge des vnements de type publish-subscribe, ce qui permet des quipements d'tre informs des changements au niveau d'autres devices. WSD1 est l'implmentation par Microsoft de la spcification DPWS qui se trouve au coeur de Vista, la prochaine version du systme d'exploitation Microsoft Windows, et qui permet des quipements d'intragir avec Windows sur un rseau IP.
2.1.2.5. La plateforme OSGi
OSGi [OSGi] est un consortium qui a pour but de spcificier, crer et promouvoir une plateforme dynamique service ouverte / libre. Cette plateforme a pour objectif la livraison et l'administration de services dans des rseaux rsidentiels ou autres types denvironnements restreints (automobile, tlphonie mobile, rseaux de capteurs, ...). La plateforme OSGi offre une surcouche la machine virtuelle Java. Centralise / non-distribue, elle sert d'infrastructure au dploiement de fournisseurs ou demandeurs de service appels bundles. Dans la pratique, un bundle est une unit de dploiement qui correspond un fichier JAR 2
1 Web Services for Devices: http://msdn.microsoft.com/windowsvista/default.aspx?pull=/library/enus/dnlong/html/WebSerDev.asp 2 JAR: Java ARchive
20 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services contenant du code et des ressources. La plateforme OSGi supporte la disponibilit dynamique. En effet elle fournit des mcanismes dadministration permettant de raliser linstallation, activation, dsactivation, mise jour et dsinstallation des bundles de faon continue. Lorsqu'un bundle est actif, il peut publier ou dcouvrir des services et se lier avec dautres bundles travers un registre de services fourni par la plateforme. Notons qu'un bundle peut la fois jouer le rle de fournisseur et d'utilisateur de service, les dpendances de services sont alors dcrites dans le descripteur de service. OSGi prsente l'avantage de fournir un environnement gnrique pour le dploiement de services. En effet, l'interoprabilit est possible avec n'importe quel autre protocole grce l'approche services (il existe dj un service de passerelle avec des quipements Jini et UPnP). Descripteur de service: Un bundle contient un fichier manifest tendu. Ce dernier fournit des informations sur le fournisseur de service, les services fournis (leur classe d'implmentation), les services requis, sa version, etc. Registre: Il est centralis et intgr la plateforme. Dcouverte / recherche: La recherche de services se fait au moyen dune requte LDAP1 simple qui peut limiter la recherche lensemble des services qui ont des proprits spcifiques. Liaison: Comme la plateforme est centralise, l'usager d'un service et le fournisseur sont colocaliss sur la mme machine virtuelle Java. Ils interagissent par le biais d'appels de mthodes Java. Notifications: La plateforme communique avec ses bundles via un mcanisme vnementiel.
1 Lightweight Directory Access Protocol
21 / 65
2.2. Contrats
Dans le contexte des architectures orientes service, l'usager d'un service doit au moins connatre la syntaxe des oprations qu'il souhaite utiliser. Il utilise pour cela un contrat de service qui dans sa version la plus simple dcrit la syntaxe du service. Le contrat peut tre enrichi par des informations non fonctionnelles telles que des informations sur le comportement du service ou sur la qualit de service garantie. Ces donnes supplmentaires rendent le contrat ngociable et permettent, dans un environnement concurrenciel, des services similaires provenant de plusieurs fournisseurs de se distinguer. La suite introduit la notion de contrat et la manire dont il est actuellement reprsent dans les plateformes dynamiques service.
2.2.1. Dfinitions et concepts

Cette premire partie donne une dfinition gnrale du contrat. La notion de contrat ainsi que les concepts qui lui sont associs, dont la ngociation de contrat, sont ensuite prsents dans le cadre des architectures orientes service.
2.2.1.1. Definition gnrale
Dans le langage courant, un contrat est un accord de volont pass entre au moins deux parties. La signature des parties signifie quil y a accord sur les termes du contrat. Un contrat peut aussi tre conclu oralement. Plus prcisment, un contrat contient une ou plusieurs clauses que les parties s'engagent respecter partir du moment o le contrat est accept, c'est--dire sign.
2.2.1.2. Le contrat dans les architectures orientes service
Le monde du SOA tant trs li au monde de l'entreprise puisqu'une de ses principales cibles est le B2B1, la notion de contrat y est rapidement apparue. La notion de contrat dans le gnie logiciel n'est pas rcente ni propre l'approche service bien qu'elle y soit tout particulirement adapte. Son apparition remonte l'approche composant. L'approche composant prconise l'encapsulation des fonctionnalits dans le composant afin de les dissimuler derrire un patron2 de faade, qui est en pratique ralis par une interface. Les interactions entre composants se font donc par l'intermdiaire du contrat pour respecter le principe de bote noire. Ceci signifie que les appels doivent suivre la syntaxe dfinie par le contrat. Dans une architecture oriente service, un contrat est une entit liant le fournisseur et l'usager d'un service (voir figure 7).
1 business-to-business 2 En anglais, pattern
22 / 65
Usager
Contrat clause 1 ... clause n
Fournisseur
Figure 7. La liaison entre un usager et un fournisseur suit un contrat bi-parties En pratique un contrat est plus souvent bi-parties mais il existe des cas o plusieurs acteurs sont lis par un mme contrat (figure 8).
Producteur
Achat benzene Paiement avec credit
Finance
Transporteur
Acheteur B2B
Expdition avec delai de livraison Assurrance sur le transport Autorisation gouvernemental pour un transport scuris
Assureur
Gouverne m e nt
Figure 8. Cas d'un contrat multi-parties Au sein de l'quipe ADELE, le groupe de travail sur les services a labor la dfinition suivante du contrat de service [ADELE2005]: Un contrat de service est souscrit lorsqu'un demandeur de service se lie avec un fournisseur du service requis. Ce contrat peut tre ngoci lors de la phase de dcouverte / requte de service. Le contrat est bas sur un modle de contrat contenu dans la description du service. Nous considrons que chaque liaison entre demandeur et fournisseur est une instance personnalise du modle de contrat fourni par le fournisseur. On dit d'une application service qu'elle est rsolue lorsque ses contrats sont signs. Tant qu'ils ne sont pas signs, c'est--dire non accepts, l'application est dans un tat non-rsolue. Une classification des contrats a t tablie par Beugnard et al [Beugnard1999]. Elle distingue quatre niveaux de contrat allant d'un niveau o la ngociation est impossible un niveau o la ngociation est possible dynamiquement. Le niveau syntaxique se rsume ce qu'on peut trouver en rgle gnrale dans les interfaces des langages de programmation classiques et dans les langages de dfinition d'interfaces (IDLs). C'est-dire les oprations disponibles, les paramtres d'entres et de sorties requis et ventuellement les exceptions qui pourraient tre leves durant ces oprations. A son tat le plus basique un contrat de niveau comportemental spcifie le comportement de chaque opration en utilisant des assertions boolennes appeles pre- ou post-conditions et invariants. Dans [Meyer1992] la conception oriente contrat1 implmente ce niveau de contrat grce
1 En anglais, Design by Contract
23 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services au langage Eiffel. Par la suite, Java ou encore UML 1 ont adopt cette approche travers les assertions Java et OCL2. Un contrat de niveau synchronisation spcifie le comportement global d'objets en terme de synchronisations entre appels de mthodes. Une solution serait d'attacher aux objets des politiques de synchronisation telles qu'une stratgie Mutex par exemple. Le niveau qualit de service [Zschaler2004] est un type de contrat plus orient services puisqu'il a pour but de quantifier le comportement d'un service. La qualit de service est une notion que l'on retrouve souvent dans les rseaux (elle pourrait par exemple porter sur un temps de rponse maximal). Par sa nature quantificatrice ce type de contrat a l'avantage de pouvoir tre ngoci en jouant sur les valeurs proposes. Ce niveau de contrat est abord plus en dtail dans le chapitre suivant qui traite des accords de niveau de service.
2.2.1.3. Ngociation de contrat
Il arrive que pour un contrat donn, certaines clauses peuvent tre ngocies. Les parties entament alors une phase de ngociation du contrat ayant pour but l'tablissement d'un nouveau contrat satisfaisant toutes les parties. Dans l'tat de l'art actuel, les contrats sont rarement ngociables. Ils sont gnralement proposs par le fournisseur et l'usager n'a que deux possibilits: soit le contrat rpond ses besoins et il l'accepte, soit il ne lui convient pas auquel cas il n'utilisera pas le service attach ce contrat, ce qui revient une simple slection. Une relle ngociation impliquerait par exemple une nouvelle proposition de la part du fournisseur suite une requte du demandeur de service. Il existe cependant quelques variantes visant amliorer et raffiner cette phase de slection. Un systme de filtrage portant sur les clauses du contrat (essentiellement dans les contrats de niveau Qualit de Service) permet l'usager de choisir son service avec une granularit plus fine. Il existe galement des systmes de slection qui utilisent des stratgies de scoring, mais ce point est abord plus en dtail dans la partie 'ngociation' de la section 3.1.
2.2.2. Le contrat sur les diffrentes plateformes services

Actuellement, le contrat est en rgle gnrale propos par le fournisseur et reprsent par une simple interface qui dcrit les oprations fournies par le service. Le contrat entre un fournisseur et l'usager d'un service exprime rarement les besoins non fonctionnels de chacun. Et la ngociation est souvent rduite une acceptation ou un refus du contrat, ce qui correspond au niveau syntaxique de [Beugnard1999]. Dans cette partie nous tudions la reprsentation du contrat pour les diffrentes plateformes service tudies dans la section 2.1.2.
2.2.2.1. Jini
Dans une architecture Jini le contrat est reprsent par l'interface Java du service et les proprits associes ce service. Ces proprits sont en fait un ensemble dattributs reprsent comme une
1 Unified Modeling Language, www.uml.org/ 2 Object Constraint Language, intgr UML 2.0
24 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services instance dune classe Java o chaque attribut est un champ public de cette classe ce qui permet un typage fort des attributs. Ensuite, lors d'une recherche de service auprs du registre, un usager passe en paramtre de la mthode lookup le type du service (i.e le nom de l'interface) ainsi qu'un ensemble de valeurs d'attributs. Le registre retourne un ensemble de rsultats parmi lequels le demandeur devra faire un choix [Ayed2003]. La phase de ngociation se rsume donc une recherche suivie d'une slection. Le fournisseur n'intervient pas dans la ngociation, il ne fait qu'exposer un ensemble de proprits attache son service qui pourra correspondre ou non la recherche de l'usager.
2.2.2.2. Services Web
Le contrat d'un service Web correspond son descripteur de service qui est publi dans un registre UDDI. Si le descripteur reste basique et n'est pas tendu, le contrat est de niveau syntaxique: l'usager interroge le fournisseur en respectant la syntaxe fournie par le descripteur de service. Les informations quune entreprise peut enregistrer au niveau de UDDI sont des informations sur son nom, des contacts, des codes industriels, des classifications de produits, des URLs, lensemble des services offerts ainsi que des informations sur leurs interfaces techniques et leurs fonctionnements. La ngociation se limite alors une interrogation du registre qui renvoie un ensemble de rponses parmi lesquelles l'usager choisit le service qu'il souhaite utiliser.
2.2.2.3. UPnP / DPWS
Dans UPnP (ou DPWS) le contrat est un fichier de mta-donnes au format XML dcrivant l'quipement et ses services. Les quipements et leurs services sont dcouverts. Un point de contrle peut ensuite slectionner le service qu'il souhaite utiliser. Il est alors considr comme ayant accept le contrat ds que l'interaction avec l'quipement dbute. L'quipement est ensuite utilis en respectant la syntaxe dfinie dans le contrat. NB: La description d'un quipement peut contenir des attributs qui correspondent aux variables d'tat de l'quipement mais les services peuvent pas tre slectionns d'aprs ces variables.
2.2.2.4. OSGi
Dans la plateforme OSGi, le contrat correspond au descripteur de service. Il est modlis par l'interface du service qui contient les informations fonctionnelles et par les proprits qui reprsentent la partie non fonctionnelle du contrat. Il s'agit donc d'un contrat de niveau la fois syntaxique et qualit de service. Le contrat intgre galement d'autres informations non fonctionnelles telles que les dpendances de services, etc. Un service est slectionn par une interrogation du registre qui utilise un filtre LDAP pour permettre une slection plus fine comme dcrit dans la section 2.2.1.3.
25 / 65
2.3. Accords de niveau de service

Le contexte des architectures orientes service fait intervenir des acteurs appartenant souvent des organisations diffrentes. Pour garantir le bon fonctionnement de ces systmes et une cohsion entre ses diffrents acteurs, des accords portant sur les services fournis doivent tre conclus entre les diffrentes parties. Pendant de nombreuses annes les accords de niveau de service1 taient prsents dans un format papier rdig dans un langage naturel. Les dernires recherches dans ce domaine poussent les intgrer aux applications en les rdigeant dans un format interprtable par une machine. Les accords de niveau de service ont toujours t trs prsents dans le domaine des rseaux o il y a un rel besoin d'accords entre les diffrents oprateurs mais ils sont maintenant en essor dans le monde des architectures orientes services. Les termes de l'accord portent gnralement sur la garantie du service fourni, sur son tarif et sur les pnalits en cas de non respect de l'accord. Par exemple dans le cas du rseau la garantie peut concerner les performances comme le dbit, le temps de rponse ou la gigue.
2.3.1. Dfinition et concepts

Voici une dfinition des accords de niveau de service construite partir de nombreuses dfinitions trouves dans la littrature: Un accord de niveau de service est un contrat souscrit entre le fournisseur d'un service et un usager de ce service dfinissant les engagements de ces deux parties. Ces engagements, contenant le niveau de service fourni ainsi que les pnalits encourrues en cas de manquement de part et d'autre, sont dfinis par des critres objectifs de qualit de service pouvant tre valus par les deux parties. Bien que les accords de niveaux de services ressemblent une simple contractualisation de la qualit de service2, il en existe un grand nombre de natures diffrentes: du basique contenant des standards de disponibilit et de performance s'appliquant une large gamme d'applications, aux accords plus prcis, focaliss, qui varient d'un client l'autre au sein de la mme entreprise. Des accords de niveau de service trop gnraux ne reprsentent qu'une faible valeur ajoute, c'est pourquoi on rencontre principalement des solutions ad-hoc plus prcises, adaptes chaque problme. D'aprs [Miller1987] et [Consulting2002] un accord de niveau de service devrait tre construit en suivant les 9 tapes suivantes: Dfinir les parties engages par l'accord. Dcrire le service fourni. Spcifier le volume de demande pour le service. Dfinir le temps d'utilisation du service. Par exemple: 90% du temps pendant 2 heures ou, pour une tche programme, si le traitement dbute 8h alors le rsultat sera fourni 20h . Spcifier la disponibilit du service. Gnralement une fentre de temps.
1 En anglais, Service Level Agreements, SLAs 2 En angalis, QoS
26 / 65

Dfinir la fiabilit du service fourni. En pratique il s'agit du temps o le service est effectivement disponible sur le temps de disponibilit annonc. Quantifier la compensation pour le service fourni. Souvent la compensation correspond au prix du service, mais en plus elle peut augmenter ou diminuer si l'utilisateur ou le fournisseur ne respect pas les accords. Elle englobe donc le principe de pnalit. Une telle mesure est indispensable mais elle implique la mise en place d'un systme de facturation. Dcrire les procdures de mesure utiliser. Les mesures peuvent tre stockes pour tre rutiliser comme preuves en cas de litige entre les parties, ou bien servir des outils statistiques ou prvisionnels. Fixer une date pour la rengociation de l'accord. Cette date est en fait une date de validit de l'accord. Comme les politiques des diffrents acteurs peuvent changer (prix du service, volume autoris, etc.) il est ncessaire d'avoir dans ces cas-l une phase de rengociation.
Ces tapes permettent de structurer un accord de niveau de service entre un fournisseur et un usager. Elles soulvent toutefois quelques problmes, et pour mieux les comprendre, introduisons de nouveaux concepts. On trouve dans la littrature (par exemple dans [Software2004], [Consulting2002] ou [Oldham2006]), par analogie avec le terme SLA, les termes SLM et SLOs qui signifient respectivement Service Level Management1 et Service Level Objectives2. Le premier correspond la gestion du niveau de service, c'est--dire qu'il englobe tout ce qui est surveillance 3, facturation et gestion des pnalits tandis que le second concerne les objectifs du fournisseur, le niveau de service qu'il garantit. Dans un souci d'quit, la surveillance doit tre dlgue un partie tierce de confiance choisie par les parties signataires de l'accord, ceci afin d'viter d'ventuels litiges. Cette tierce partie peut tre constitue d'un seul ou de plusieurs auditeurs. Chaque auditeur est charg de prendre des mesures pour vrifier le respect des accords dont la surveillance lui a t confie. En cas de non respect il doit appliquer les mesures dcrites par les politiques de pnalit. Concernant l'instrumentation, le nombre de critres de qualit de service qui peuvent tre dfinis pour un service est potentiellement trs grand. Le moindre paramtre peut tre dfini de diffrentes manires. Par exemple le temps de rponse peut-tre observ valeur par valeur, en moyenne, du point de vue du client ou du serveur d'application hbergeant le service, etc. Il est donc ncessaire de dfinir une mtrique propre chaque paramtre. Cette tierce partie joue donc un rle primordial dans le SLM et devient un acteur part entire qui pourrait tre nomm certifieur de service ou auditeur tiers (voir figure 9). Toutefois un certain cot est associ l'instrumentation et il est ncessaire de prendre ce cot en compte lors des mesures pour ne pas fausser les rsultats et pnaliser une partie tort. Les accords de niveau de service ont t le sujet de recherches intenses pendant plusieurs annes et ont maintenant atteint un certain degr de maturit. Toutefois le problme de l'tablissement d'un canevas gnrique pour le SLM dans un environnement multi-organisations n'est toujours pas rsolu. Les sections suivantes prsentent plusieurs travaux qui ont pour but l'tablissement d'un tel canevas.
1 Gestion du niveau de service 2 Objectifs de niveau de service 3 En anglais, monitoring
27 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services Annuaire de Service
recherche publication
Usager du Service
Accord de niveau de service

interaction
Fournisseur du Service
Certifieur de service
Figure 9. Le certifieur de service valuation le respect de l'accord de niveau de service.
2.3.2. Travaux acadmiques

Cette partie tudie les travaux acadmiques mens dans le domaine des accords de niveau de service dans le contexte des architectures orientes service: ContractLog, un canevas1 pour la prise en charge des accords de niveau de service construit sur une approche base de rgles appele Rule-based SLA , et d'autre part SLAng, un langage de dfinition des accords de niveau de service.
2.3.2.1. RBSLA: Rule-based Service Level Agreement (ContractLog)
De rcentes recherches menes par Adrian Paschke2 ont conduit une approche du SLA base sur des rgles, Rule-based SLA (RBSLA) [Paschke2005] et une implmentation de ContractLog [Paschke2005a], un canevas pour la reprsentation et l'application d'accords de niveau de service utilisant l'approche RBSLA. Ces travaux proposent une reprsentation des accords de niveau de service partir de rgles en utilisant des concepts de reprsentation de connaissances sophistiqus, base de logique. Ils reprsentent une alternative aux contrats crits en langage naturel, ou dans des langages tels que Java ou C++ et dont les implmentations sont dissmines dans le code applicatif. En combinant
1 Framework en anglais 2 Chercheur l'universit technique de Munich (Technical University of Munich, TUM). Pour plus d'informations, se rfrer http://ibis.in.tum.de/staff/paschke/index.htm
28 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services des formalismes logiques dans le canevas ContractLog, il est possible de dcrire des spcifications de contrat base de rgles formelles qui peuvent tre surveilles et excutes de manire automatique. La figure 10 illustre l'implmentation trois niveaux qui a t ralise: le canevas ContractLog, le langage dclaratif RBSLA et un outil de gestion de niveau de service bas sur des rgles, RBSLM1. ContractLog est implment sur le moteur de rgles open-source Mandarax2 construit au dessus de Java, et RBSLA est un langage bas sur RuleML3, donc sur XML. Le principe du langage RBSLA repose sur l'utilisation de rgles issues du domaine de la programmation logique. Nous ne nous tendrons pas sur le fonctionnement complexe de ContractLog qui intgre des formalismes logiques tels que des rgles ECA (Evnement, Condition, Action), l'Event Calculus, la logique dontique, la logique annulable4 et la logique de description. Mais il est important de retenir que les accords de niveau de service sont dcrits par des rgles ECA actives, c'est--dire qu'elles sont excutes toutes les priodes T et sont du type eca(T,E,C,A). Par exemple, chaque minute le systme vrifie si un vnement service indisponible a t reu. Dans ce cas, si aucune maintenance n'est prvue, un message d'avertissement est envoy un administrateur. La rgle s'crit alors de la manire suivante:
eca(everyMinute, serviceUnavailable, notScheduledMaintanance, sendNotification)
Les principaux avantages de cette approche logique, par contraste avec les approches traditionnelles par programmation, sont sa flexibilit leve, son extensibilit dynamique et un fort potentiel pour ce qui concerne l'automatisation de tches telles que la dtection de violation de contrat, le contrle d'autorisation (par la logique dontique), la dtection de conflit, la facturation de service et la cration de rapport.
Figure 10. Architecture en couches de l'approche Rule Based SLA [Paschke2006]
1 2 3 4
Rule Based Service Level Management http://sourceforge.net/projects/mandarax http://www.ruleml.org/ En anglais, deontic logic et defeasible logic
29 / 65
2.3.2.2. SLAng
SLAng [Lamanna2003] est un langage de dfinition d'accords de niveau de service. Un modle pour la livraison de service inter-organisations la fois, au niveau de l'application, de l'intergiciel, du rseau et du stockage constitue la base de SLAng. Les objectifs de SLAng sont multiples. Ce langage tente de fournir un format pour la ngociation de proprits de qualit de service, les moyens de capturer ces proprits de manire non ambige et de les intgrer dans des accords, ainsi qu'un langage interprtable qui permet des traitements automatiques. Dans son approche, SLAng considre deux catgories d'accords de niveau de service: les SLAs horizontaux, passs entre parties de mme niveau qui fournissent un service du mme type, et les SLAs verticaux passs entre infrastructures de niveaux diffrents (par exemple, entre un conteneur et un composant, ou bien entre un conteneur et la couche rseau). Un des avantages de SLAng est l'expression des accords de niveau de service dans un langage XML, ce qui offre une compatibilit leve avec les technologies Internet. Toutefois SLAng se propose comme un complment aux services Web et reste donc trs li cette plateforme. De plus SLAng n'est pas un langage extensible et ce manque de flexibilit reprsente un inconvnient non ngligeable.
2.3.3. Un standard mergeant: Web Service Level Agreements

Les services Web, de plus en plus en rpandus, sont devenus un standard de fait (voir section 2.1.2.2). Il n'est donc pas tonnant de voir merger un canevas pour les accords de niveau de service bas sur cette technologie. Des recherches menes par IBM1 ont abouti au langage Web Service Level Agreements2 (WSLA) d'une part et l'implmentation du SLA Compliance Monitor d'autre part [Keller2002] et [Dan2004]. Le langage WSLA est un langage de description d'accords de niveau de service bas sur WSDL3. La spcification WSLA [Ludwig2003] intgre les diffrents concepts lis aux accords de niveau de service (voir figure 11). Un accord de type WSLA est divis en 3 parties: les parties concernes par l'accord, c'est--dire les parties contractantes ainsi que les parties tierces; la description du service. Elle contient les oprations fournies par le service, le protocole de transmission des messages, les paramtres d'accord de niveau de service, i.e les critres de qualit de service ainsi que les mtriques associes ces critres (les mtriques intgrent les fonctions et algorithmes ncessaires aux mesures); et les obligations qui concernent les garanties donnes par le fournisseur et les contraintes qui lui sont imposes. De plus cette partie spcifie une date de validit de l'accord, des formules permettant de dtecter une violation de contrat et les actions entreprendre en cas de violation., ce qui correspond au principe de pnalit.
1 www.ibm.com/ 2 Accords de niveau de services Web: WSLA 3 http://www.w3.org/TR/wsdl
30 / 65
Figure 11. Les principaux concepts de WSLA [Ludwig2003] Il faut galement savoir que les accords de niveau de service WSLA sont rdigs par le fournisseur de service avec l'accord de l'usager, avant la phase de dploiement. Ces accords sont par la suite utiliss lors de l'excution par un systme charg de surveiller leur respect, le SLA Compliance Monitor (qui est maintenant disponible dans le Web Services ToolKit d'IBM1). IBM a propos un canevas pour la prise en charge des accords de niveau de service dans le contexte des services Web avec comme objectif de pouvoir rpondre aux besoins suivants [Keller2002]: pouvoir s'adapter une large gamme d'accords de niveau de service, fournir des mcanismes automatiques de ngociation, chaque partie implique ne doit recevoir parmi les accords de niveau de service que le fragment qui la concerne (par exemple un auditeur tiers charg de surveiller uniquement le dlai de rponse n'a pas besoin de connatre les garanties de bande passante), dlguer la surveillance et l'instrumentation des parties tierces. La figure 12 illustre le fonctionnement de ce canevas et le rle du SLA Compliance Monitor qui en est la partie oriente SLM. Une fois que les accords de niveau de service ont t conclus et mis sous la forme WSLA, ils sont dploys, c'est--dire distribus entirement ou partiellement aux diffrentes parties par le SLA Compliance Monitor. Ce composant est ensuite responsable des mesures et de la surveillance du respect des accords de service (en interceptant les appels du client par exemple). Si le service d'valuation de condition dtermine qu'une obligation n'a pas t respecte, des actions prvues dans les accords doivent tre entreprises. L'entit mtier (Business
1 WSTK (Web Services ToolKit): http://www.alphaworks.ibm.com/tech/webservicestoolkit
31 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services Entity) contient des informations prives propres au fournisseur de service telles que des objectifs et des politiques, et n'est l que pour valider ou invalider les actions si elles sont ou non en accord avec les objectifs actuels du fournisseur.
Figure 12. Patron d'interactions du canevas WSLA [Keller2002].
32 / 65
2.4. Synthse
Les plateformes dynamiques services sont en plein essor et leurs domaines d'application sont de plus en plus vastes. Bien que les services Web soient le type d'architectures le plus rpandu, l'aspect dynamique n'est pas assez mis en valeur. D'autres technologies mergeantes telles que UPnP, DPWS et OSGi ou mme Jini proposent des plateformes qui ciblent plus cet aspect dynamique. Un rcapitulatif des caractristiques de ces plateformes est fourni par le tableau 1. Actuellement les contrats de service tels qu'ils sont dcrits dans la section 2.2.1.2 dpassent rarement le niveau syntaxique et sont essentiellement bi-parties. De plus, la phase de ngociation n'est qu'une simple acceptation ou refus du contrat. Les accords de niveau de service viennent enrichir les contrats de service en les haussant au niveau qualit de service et en offrant une description plus dtaille des services. Toutefois, la prise en compte d'accords de niveau de service ncessite la mise en place d'infrastructures capables de les supporter. Mme si la recherche a atteint un certain degr de maturit dans ce domaine, il y a encore beaucoup faire. Un modle d'accords de niveau de service doit tre gnrique mais pour tre rellement effectif, il doit tre extrmement prcis par rapport au domaine d'application et donc tre extensible. C'est pour cela que nous observons une vaste diversit de systmes de gestion d'accords de niveau de service ad-hoc et peu de standards. Parmi les tentatives nous pouvons citer Rio1 pour la plateforme Jini mais cette dernire n'est plus tellement utilise. Naturellement la plupart des travaux portent sur les services Web. SLAng n'est pas encore trs abouti alors que Web Services Level Agreements pouss par IBM est dj utilis. Nous pouvons galement citer deux spcifications rcentes propres au domaine des services Web: WS-Policy [W3C2006] et WS-Agreement [Oldham2006]. WS-Policy permet d'exprimer des politques d'usage sous forme de conjonctions et disjonctions d'assertions. Jusqu' prsent, les politiques ont t dfinies pour la scurit (WS-Security-Policy), pour l'envoi fiable de messages (WS-Reliable-Messaging) et pour le routage des rsultats (WS-Addressing). Concernant les accords de niveau de service, rien ne semble avoir t dfini sur la base de WS-Policy. WS-Agreement est une autre spcification qui s'intresse plus particulirement la dfinition d'objectifs de niveau de service (SLOs) et l'ontologie. WS-Agreement spcifie un langage bas sur XML pour la cration de contrats, d'accords et de garanties partir d'offres entre un fournisseur de service et un client. Il existe toutefois des travaux acadmiques tentant de s'abstraire de toute technologie tels que l'approche Rule-Based SLA, mais cette solution demeure inutilisable du fait de sa complexit. Nous retiendrons nanmoins l'utilisation de rgles ECA (pour dcrire les dcisions prendre), que l'on retrouve galement dans le contexte autonomique. L'tat de l'art montre enfin que l'aspect dynamique, essentiellement la disponibilit dynamique des services, n'a pas t une proccupation principale lors des recherches menes sur les accords de niveau de service. De mme, peu de travaux compatibles avec les plateformes dynamiques services ont t effectus sur les accords de niveau de service. C'est sur ce point que nous proposons de travailler et que porte notre contribution.
1 http://rio.jini.org/
33 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services Jini Architecture Registre
Distribue / dynamique
UPnP / DPWS
Services Web
OSGi
Centralise (mme Machine Virtuelle Java) / dynamique Unique et centralis. Fourni par le framework OSGi
Distribue / dynamique Distribue / aspect dynamique peu dvelopp Distribu Registres UDDI multiples mais centraliss car rpliqus. NB: peu utilis Descripteur en WSDL (bas sur une grammaire XML) ou WSLA pour les accords de niveau de service Syntaxique / WSLA est bi-parties Interrogation d'un annuaire UDDI
Distribu (services de recherche)
Descripteur de Interface Java + proprits service / Modlisation du contrat Niveau de contrat Dcouverte / recherche
Descripteurs XML des quipements et de leurs services (DPWS utilise WSDL)
Interface ou classe Java + proprits
Syntaxique et un peu de Syntaxique qualit de service. Le type du service (interface) et les valeurs des attributs sont passs en paramtres de la recherche Non, recherche puis simple slection Simple. Typage fort sur le nom de l'interface et la signature de ces mthodes. Filtre sur l'galit des proprits. (notion de templates) Distant / RMI Protocole de dcouverte bas sur IP Multicast (SSDP). Filtrage trs limit. (WS-Discovery pour DPWS) Non, dcouverte service Limite. Simple recherche de service. Les valeurs des variables d'tat ne peuvent pas tre utilises pour la recherche Messages dans des enveloppes SOAP
Syntaxique et qualit de service. Une recherche dans le registre partir d'un filtre LDAP retourne une rfrence vers l'objet du service Non, simple slection par filtrage
Ngociation Filtrage / slection
du Non
Utilisation des pages Filtre LDAP blanches, jaunes et complexe avec vertes d'UDDI relations d'ordre pour les valeurs des proprits
Liaison
Messages dans des enveloppes SOAP
Appels locaux de mthodes Java (par rfrences) Arrive, dpart et modification
Notifications Arrive, dpart et

modification
Arrive et dpart Arrive, dpart et (SSDP), changement de modification valeur des variables dtat (WS-Eventing pour DPWS) Tous Tous
Portabilit / langages supports SLA
Java
Java avec possibilit de passerelles vers d'autres plateformes Rien
Rio
Rien
WSLA
Tableau 1. Rcapitulatif des caractristiques de quelques plateformes dynamiques services
34 / 65
3. Prise en compte de la dynamique dans les accords de niveau de service

Les plateformes dynamiques services ou les accords de niveau de service sont des domaines de recherche rcents. Les domaines abords soulvent donc de nombreux problmes que nous allons examiner dans la section suivante. Nous avons choisi de nous focaliser sur l'aspect dynamique et sa prise en compte dans les accords de niveau de service par l'intermdiare du contrat de service. Notre travail porte essentiellement sur l'impact de la dynamique sur les accords de niveau de service. Aprs avoir prsent les architectures orientes service dans le domaine d'quipements connects un rseau, contexte dans lequel nous plaons notre tude, diffrents scnarios sont tudis afin de mettre en vidence les principaux problmes lis la prise en compte de la dynamique dans les accords de niveau de service, et diffrents cas de ngociation de contrats de service. Les sections 3.4 et 3.5 prsentent notre contribution. D'une part, une chelle macroscopique, un modle gnral d'architecture dynamique oriente service prenant en charge les accords de niveau de service. Ce modle intgre un mcanisme de gestion des liaisons que nous reprsentons par des contrats. D'autre part, une chelle plus rduite, nous proposons un modle de contrat de service intgrant des concepts lis la dynamique et permettant la mise en oeuvre des mcanismes du premier modle.
3.1. Identification des problmes soulevs

Les problmes lis aux domaines des accords de niveau de service et des plateformes dynamiques services sont nombreux et certains font dj l'objet de recherches actives. Ils ne peuvent donc tre tous traits. Nous avons donc choisi au final de focaliser notre travail sur l'aspect dynamique.
3.1.1. Modlisation de l'accord et smantique

L'accord de niveau de service entre l'usager et le fournisseur d'un service correspond gnralement au contrat liant les deux parties. Souvent cet accord est reprsent par un fichier au format texte crit dans un langage spcifique. On pourrait galement modliser le contrat par une approche oriente objet mais le problme resterait le mme: les parties qui souscrivent au contrat doivent tre d'accord sur la syntaxe et la smantique utilises pour pouvoir interprter le contrat de la mme manire et viter toute ambigut ou incomprhension. Cette contrainte est due un avantage des architectures orientes service, le faible couplage. L'encapsulation permet aux services de s'xcuter en environnements htrognes mais il subsiste quand mme un lien, un partage d'information minimal, entre un fournisseur de service et ses usagers, pour rendre possible leurs interactions. En outre, l'expression de la qualit de service, o la smantique est trs lie un domaine de mtier, est aussi un problme spcifique. Nous ne nous poserons pas ce problme et nous supposerons que les diffrents acteurs sont en accord sur la smantique des services.
35 / 65
3.1.2. Contractualisation du comportement d'un service

En cas de rupture de contrat, ou juste de dpart d'un service, un utilisateur a plusieurs possibilits. Il peut attendre le retour du service, le remplacer par un autre ou bien arrter son travail et considrer le dpart comme une rupture de contrat. A l'instar du type de pnalit appliquer qui doit faire partie des accords de niveau de service, le comportement adopter dans les cas de figure pr-cits devrait galement y tre dcrit.
3.1.3. Composition de services et sous-contractants

La composition de service, aussi appele chainage, schmatise par la figure 13 est une configuration courante. Le service A utilise le service B, mais le service B a besoin du service C. Pour A, le service C est un sous-contractant de B.
SLA-1 Service A Service B
SLA-2 Service C
Figure 13. Composition de services et sous-contractant B doit-il tre responsable de C devant A? En cas de rupture du contrat SLA-2 de la part de C, B ne peut plus assurer le service qu'il fournissait A, il rompt donc lui aussi le contrat SLA-1. Dans ce cas les pnalits doivent-elles tre appliques C et B? Uniquement C? Le bon sens voudrait que B et C soient tous deux pnaliss. B tant responsable de C, c'est lui de prendre les mesures ncessaires en spcifiant par exemple dans SLA-2 une pnalit suffisante pour amortir celle dcrite dans SLA-1. Nous venons de voir le cas de la rupture de contrat mais en cas de violation d'une des clauses, pour cause de performances non atteintes par exemple, le raisonnement est le mme. La composition de services et d'accords de niveau de service est un point que nous ne traitons pas dans nos travaux.
3.1.4. Ngociation et slection du contrat

Gnralement la ngociation d'un contrat de service se rsume une recherche et une souscription si le service prsente les proprits voulues. Si la recherche n'aboutit aucun rsultat satisfaisant alors la ngociation s'arrte l. Il n'y a pas vraiment de ngociation au sens propre o les parties changent pour se mettre d'accord sur un contrat. Cependant certains processus sont plus volus avec la mise en place de stratgies de slection, par un systme de points et de coefficients par exemple1 ou bien par d'autres algorithmes de
1 En anglais, scoring
36 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services slection. Le scoring [Sierra1997] consiste attribuer chaque proprit du service un certain nombre de points, ce qui donne au final par additivit, ou par toute autre fonction de scoring, un score. Le contrat ayant le score le plus intressant est retenu. Mais encore une fois il ne s'agit que d'une slection plus fine et plus complexe. Un vrai processus de ngociation impliquerait des changes entre les parties. Le fournisseur de service propose un contrat et l'utilisateur peut en ngocier certains points s'ils ne rpondent pas ses besoins. Par rapport ses objectifs, le fournisseur peut alors dcider de modifier ou non les termes de son contrat, ce qui techniquement suppose possible le changement dynamique de proprits. Des publications sur l'informatique autonomique [Kephart2003] traitent dj des notions d'objectifs et de plans d'actions. Nous pouvons donc imaginer dlguer le problme de la ngociation un systme autonomique.
3.1.5. Rengociation de contrat

Lorsque les services sont dploys sur une plateforme dynamique, il est parfois ncessaire de rengocier un contrat. Une rengociation suppose que les proprits du contrat peuvent changer dynamiquement ou bien qu'un autre contrat peut tre propos l'usager par le fournisseur de service. Une rengociation peut par exemple tre ncessaire partir du moment o un changement se produit dans l'architecture et que le service ou ses performances ne sont plus garantis, le fournisseur peut demander rengocier le contrat. Ou bien lorsque les ressources viennent manquer, un fournisseur ne peut plus dispenser son service de la mme manire. La rengociation d'un contrat ne doit pas non plus perturber le fonctionnement du reste du systme. De la mme manire que pour la ngociation, elle pourrait tre dirige par un systme autonomique.
3.1.6. Restitution de l'tat et du contexte, contrat persistant

Dans un contexte dynamique, les services peuvent disparaitre puis ventuellement reapparaitre et mme tre substitus. D'aprs les paradigmes des architectures orientes service dynamiques, l'usager d'un service devrait pouvoir reprendre l'utilisation du service son retour o il l'avait arrt. Or la continuit de service implique plusieurs problmes tels que la restitution de l'tat de l'usager et du fournisseur, ou bien la restitution du contexte tel qu'il tait avant le dpart du service, sachant qu'une telle solution est trs complexe mettre en oeuvre dans un environnement dynamique. Ce type de situation est rapprocher du problme connu de reprise sur panne [Hanemann2005] qui peut tre trait par diffrentes politiques. Faut-il avoir des services avec ou sans conservation d'tat (en anglais, stateless ou stateful)? Une conservation du contexte? Toutefois, ces cas de figure nous permettent d'introduire la notion de contrat persistant, c'est-dire une liaison persistante entre l'utilisateur du service et le service qui pourrait exister sans que les parties concernes par le contrat ne soient prsentes. Cette solution, en plus d'autoriser la continuit de service, permet de dfinir des accords de niveau de service avant que le service et son utilisateur ne soient dploys.
37 / 65
3.1.7. Service Level Management et auditeur tiers

La recherche est trs active dans tout ce qui concerne la partie 'gestion' des accords de niveau de service, le Service Level Management (SLM, qui peut parfois signifier Service Level Monitoring [Hanemann2005]). Le SLM couvre un spectre assez large de problmes: la prise de mesures et leurs traitements, les comportements adopter selon les valeurs prleves et les SLAs (en cas de violation d'une clause du contrat par exemple). Il a pour but d'valuer et assurer le respect du contrat et ragir en cas de non respect. Il a besoin pour ceci d'avoir une mtrique bien dfinie associe chaque critre de qualit de service. Afin de conserver une certaine impartialit dans cette tche d'arbitrage, le Service Level Management est gnralement dlgu une tierce partie, que nous appelons auditeur tiers. Un auditeur tiers est un composant charg de surveiller le respect des accords et de reporter toute infraction. Plusieurs questions se posent quant ce composant. Tout d'abord, il doit tre neutre et choisi par les deux parties concernes par la contrat. Ensuite, la manire dont il mesure la qualit du service doit tre connue des deux parties, ceci pour viter les litiges. Enfin comme pour tout systme d'instrumentation, ses mesures influent sur les rsultats. En cas de litige il est donc difficile de dtecter prcisment la violation d'une clause du contrat. Keynote Systems, Inc.1 et Xaffire, Inc.2 sont des exemples de fournisseurs de service de type auditeurs tiers.
3.1.8. Pnalits et facturation

Un fournisseur de service s'engage par les accords de niveau de service fournir un service d'une certaine qualit. Un manquement ces obligations peut porter prjudice l'utilisateur du service et doit donc tre pnalis. De la mme manire, l'usager peut lui aussi avoir des responsabilits dcrites dans les accords et donc tre pnalis. Les pnalits peuvent tre de natures diffrentes: financires (une surtaxation pour l'usager ou bien un ddommagement pour le fournisseur), mettre le client ou le fournisseur sur liste noire, changer de fournisseur, utiliser un systme de bonus et de malus, etc. Une solution serait de dfinir plusieurs politiques et de spcifier dans les accords de niveau de service laquelle sera utilise. Les rsultats d'ventuelles pnalits doivent tre pris en compte lors de la facturation. Et doit on dlguer le problme dlicat de la facturation un tiers de confiance ou bien doit-il tre la charge du fournisseur de service
3.1.9. Confidentialit des ngociations

Un contexte multi-organisations est propice la concurrence. C'est pourquoi les facteurs influenant la ngociation (leur poids pour un systme de scoring par exemple) doivent tre cachs la concurrence. Il en va de mme pour les plans d'action d'agents chargs de la ngociation dans un contexte autonomique [Sierra1997].
1 KeynoteThe Internet Performance Authority, Keynote Systems, Inc., http://www.keynote.com. 2 Xaffire, Inc., http://www.xaffire.com/.
38 / 65
3.1.10. Impact de la dynamique sur les accords de niveau de service

Le fait de se placer dans une architecture oriente service dynamique a plusieurs impacts sur les accords de niveau de service et leur gestion. La disponibilit dynamique autorise les services disparatre et rapparatre au cours de l'excution, donc au cours de l'utilisation d'un service. Doit-on rompre le contrat si le service disparat? La rponse est non si la notion de disponibilit dynamique est intgre l'accord de niveau de service. Le comportement que l'usager doit adopter en cas de dpart du service qu'il utilisait devrait donc faire partie de l'accord. Pour notre tude nous considrons que l'usager attend toujours le retour du service jusqu' une date d'chance spcifie dans l'accord. Selon les ressources disponibles qui fluctuent au cours de l'volution de l'architecture du systme et du temps, une plateforme services ne sera pas toujours en mesure d'admettre le dploiement d'un nouveau service. Ou alors elle peut ngocier certains critres de qualit de service pour diminuer la consommation. Certains systmes, notemment ceux chargs de calculs qui ne doivent tre interrompus, ont besoin un moment donn de stabilit. Il faut alors pouvoir assurer une part de statique au sein d'une architecture dynamique et viter le scintillement (c'est--dire les services qui apparaissent et disparaissent continuellement) de l'architecture. Cet aspect doit faire partie des accords de niveau de service. C'est sur les problmes soulevs par cette dernire partie que porte notre travail.
39 / 65
3.2. Notre contexte: les rseaux d'quipements

Comme nous l'avons vu dans les parties prcdentes, grce sa modularit et son intgration facilite en environnements htrognes, l'approche service est en plein essor dans le monde des quipements et de l'embarqu. C'est dans cette optique qu'ont t dveloppes les plateformes dynamiques service UPnP et DPWS, ainsi que la plateforme OSGi qui ciblait au dpart le domaine de la domotique et les passerelles rsidentielles. Nous nous plaons donc dans le contexte de rseaux d'quipements qui suivent les paradigmes des architectures orientes service dynamiques et dont les services peuvent provenir de fournisseurs diffrents. Ce contexte multi-organisations rend indispensable l'tablissement d'accords de niveau de service. Nombreux sont les domaines d'application qui utilisent des quipements, gnralement des capteurs, interconnects et parfois administrs par une passerelle multi-fournisseurs. On en trouve dans: 1 2 l'industrie, c'est par exemple le cas de Schneider Electric et de son projet SIRENA [Jammes2005] bas sur DPWS; la domotique, que ce soit des quipements mnagers [Marples2004] (clairage, videosurveillance, ...) ou bien multimdia (video la demande, media center3), et dans l'immotique, par exemple des capteurs d'incendie dans un immeuble [Snoonian2003]); l'automobile. De plus en plus les vhicules automobiles intgrent de l'quipement informatique, du GPS au lecteur DVD en passant par le radar de recul; l'aeronautique et le spatial: les satellites sont quips d'une multitude de capteurs et embarquent des systmes qui doivent pouvoir tre mis jour depuis la terre sans devoir tre arrts; l'armement, les commandes de contrle, et de nombreux autres systmes embarqus. Les travaux de [Marin2005] ont abouti un mta-modle du domaine des rseaux de capteurs que nous avons tendu au cas de rseaux d'quipements reprsent par la figure 14. Les quipements pilots par un driver sont connects un rseau modlis par un bus. Les devices sont des reprsentations logicielles simplifies des quipements. Un service mtier peut ensuite utiliser, par l'intermdiaire d'un mdiateur (qui se comporte comme un fournisseur de service mme s'il n'est pas reprsent comme tel sur la figure 14), un ou plusieurs devices pour excuter une tche mtier Par exemple, l'agrgation de donnes pour calculer une moyenne si les quipements sont des capteurs.
1 http://www.schneiderelectric.com/ 2 Projet SIRENA: http://www.sirena-itea.org 3 www.mediacenter.org/
40 / 65
Equipement 1
Device 2
BUS
Equipement 2
Driver
Mdiateur
Device 1
Service Mtier
Figure 14. Vue oriente service du modle de rseau d'quipements Ces infrastructures ont un rel besoin de flexibilit, elles ncessitent donc une architecture oriente service qui soit dynamique. La disponibilit dynamique permet le dploiement chaud, c'est--dire que le systme peut voluer dynamiquement sans devoir tre arrt, mais le point dlicat de la disponibilit dynamique est sa prise en charge en tant qu'aspect non fonctionnel. Le systme doit pouvoir s'adapter et ragir aux changements d'architecture qui sont plus complexes dans un contexte dynamique. De plus ce type d'architectures dynamiques orientes service est porte sur des plateformes dynamiques services sur lesquelles s'xcutent des applications provenant de divers fournisseurs et donc d'organisations diffrentes, sur des passerelles multi-fournisseurs par exemple. Les services voluent donc dans un milieu concurrenciel multi-organisations. Or dans un contexte multiorganisations le niveau de service fourni a besoin d'tre garanti et les contrats, plus particulirement les accords de niveau de service, jouent un rle primordial. Par consquent les domaines auxquels nous nous intressons sont trs demandeurs en systmes dynamiques capables de prendre en charge les accords de niveau de service. Dans le cas d'applications critiques embarques, les composants ont besoin d'un ct d'avoir une garantie sur le niveau de service qui leur est fourni, et d'un autre ct que la dynamique soit bien prise en charge afin d'viter des situations indsirables. Par exemple, un systme de gopositionnement embarqu dans un vhicule autombile en mode pilotage automatique doit tre capable lorsque le vhicule passe sous un tunnel, et que la communication GPS devient indisponible (vnement assimil un dpart de service), soit de changer rapidement de mode de communication, soit de dsactiver le pilotage automatique et de prvenir le conducteur. Ce cas est prsent plus en dtails dans le scnario de la partie 3.3.2. Nous allons effectivement voir dans la partie suivante quelques scnarios mettant en vidence les besoins lis aux plateformes dynamiques services et aux accords de niveau de service dans le domaine d'quipements en rseau.
41 / 65
3.3. Scnarios de ngociation d'accords de niveau de service sur des plateformes dynamiques services
Pour illustrer nos propos nous prsentons quatre scnarios d'usage qui montrent les diffrents problmes que peut poser la prise en compte de la dynamique des architectures oriente services dans les accords de niveau de service. Nous nous placerons successivement dans le cas d'environnements ressources limites, d'un vhicule quip d'un systme de pilotage automatique dont le service GPS devient indisponible et enfin dans le cas de calcul partir de donnes fournies par un rseau d'quipements lectriques. Nous y tudierons respectivement la rengociation de contrat en vue d'conomiser les ressources, comment traiter le dpart d'un service lorsque la disponibilit dynamique de ce dernier fait partie des accords de niveau de service, puis comment avoir une architecture dynamique qui reste stable le temps d'un calcul.
3.3.1. Rengociation de contrat dans un environnement ressources limites et fluctuantes

Dans le contexte dans lequel nous nous plaons pour notre tude, il n'est pas rare que les plateformes dynamiques service soient dployes sur un systme embarqu dont les ressources sont limites et fluctuent dans le temps. L'arrive sur un rseau d'un nouvel quipement, dont on connait ou dont on peut prvoir la consommation, ne peut pas toujours tre accepte si les ressources disponibles sont insuffisantes. Une rengociation des contrats et du mode de fonctionnement du systme peut aussi tre ncessaire dans le cas o les ressources viennent manquer et doivent tre conomises.
3.3.1.1. CPU et mmoire vive limits
Description du problme: Les ressources mmoire et CPU du systme sont limites et font donc l'objet d'accords de niveau de service. Un nouvel quipement se connecte au rseau mais le systme ne possde plus suffisamment de ressources pour l'accueillir. Son device ne peut donc pas tre dploy sur la plateforme services. Une autre solution plus complexe consisterait rengocier le contrat des quipements dj dploys afin d'conomiser les ressources. Les changements des termes du contrat peuvent alors tre assimils des changements dynamiques de proprits. Considrons une station relais charge de fusionner les donnes transmises un composant video par des capteurs vidos en rseau, et d'afficher le rsultat. Sa mmoire vive et son CPU sont limits. Le programmeur estime que le composant vido ncessite 45% du CPU et 150 ko de mmoire pour afficher 25 images / seconde [Tournier2005]. Chaque capteur vido consomme 5% de ressources supplmentaires. Plus prcisment c'est le device reprsentant le capteur video qui s'xcute sur la plateforme service et qui consomme les ressources de la plateforme, puisque les capteurs possdent leurs propres ressources. Dans le cas o le CPU est utilis au maximum de ses possibilits et o un nouveau capteur se connecte au rseau pour transmettre ses donnes, l'ajout du composant est remis une date
42 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services ultrieure (par dsynchronisation de l'vnement reu par exemple) lorsque les ressources seront suffisantes. En effet, le contrat propos par le fournisseur du service d'affichage video spcifie des ressources disponibles nulles ou bien infrieures celles requises par le nouveau capteur video. On peut aussi imaginer une ngociation plus complexe. Si le composant video est prt ngocier le nombre d'images par seconde, en spcifiant un nombre d'images par seconde minimal dans le contrat par exemple, il consommera moins et pourra donc proposer un contrat de service avec des ressources disponibles plus leves. Dans ce cas il pourra accepter le nouveau capteur.
3.3.1.2. Energie limite
Description du problme: Dans de nombreux systmes embarqus et mobiles, l'nergie est limite. Toujours dans une optique d'conomie, afin de garantir une autonomie plus longue et prvenir l'arrt du systme, il est ncessaire de rengocier la qualit de service sur les points du contrat qui consomment le plus d'nergie. Une autre ressource limite dans le cas d'quipements mobiles est l'nergie. Les dernires gnrations d'ordinateurs portables, o l'autonomie de la batterie reprsente la plus grosse contrainte, intgrent dj ce principe en proposant plusieurs modes de fonctionnement. Par exemple lorsque la jauge de batterie descend en dessous de 50%, le mode d'utilisation change et l'cran devient moins lumineux. Le mode d'utilisation a t rengoci. Observons le cas de capteurs physiologiques produits par Cyberfab (oxymtres, glucomtre, cardio-frquencemtres) [Cyberfab]. Des services dploys sur un tlphone mobile permettent de recevoir par Bluetooth1 les informations releves par les capteurs et de les traiter pour les rendre comprhensibles l'utilisateur. Considrons un patient quip d'un capteur glucomtre. Son tlphone portable (ou son assistant personnel2) lui permet de suivre l'volution de son taux de glycmie et de l'alerter du danger en cas de chute. Lorsque la batterie du contrleur faiblit, ce dernier peut passer en mode conomie d'nergie. Il diminuera la consommation de CPU pour conomiser l'nergie tout en laissant une quantit de ressources suffisante aux applications critiques. En plus de la rengociation des accords de niveau de service au niveau des ressources, il pourra rengocier la frquence de polling3 ou la frquence de rafrachissement de l'affichage. En effet, en diminuant la frquence des communications avec les capteurs, la batterie est conomise et l'utilisateur aura plus de temps pour trouver une autre source d'alimentation. On retrouve galement ce type de scnario ds que l'on a un quipement qui est dconnect de sa source d'alimentation principale et qui doit basculer sur une alimentation auxiliaire. Il doit rengocier son mode de fonctionnement et donc les contrats de ses services. Ces cas de figure relvent toutefois du domaine des applications sensibles au contexte4 et cet aspect tant un sujet de recherche actif et trs li aux applications auto-adaptables et l'informatique autonomique, nous ne tenterons pas de rsoudre ce point.
1 Bluetooth est une spcification de l'industrie des tlcommunications qui utilise une technologie radio courte distance 2 PDA 3 Le polling consiste scruter rgulirement les changements de valeur lorsque la remonte d'vnements trop frquents cote cher en CPU 4 En anglais, context-aware
43 / 65
3.3.2. Ngociation de la disponibilit dynamique d'un service, continuit de service et contrat persistant
Description du problme: En cas de dpart d'un service, le contrat ne doit pas systmatiquement tre rompu, la dcision prendre doit tre spcifie dans les accords. Si les accords de niveau de service intgrent la notion de disponibilit dynamique, alors le fournisseur peut garantir la disponibilit de son service dans une fentre de temps et se permettre de disparatre puis rapparatre. La liaison et le contexte, donc le contrat, doivent dans ce cas tre conservs jusqu'au retour du service ou jusqu' ce que la date d'chance (permise par les accords) soit atteinte. Un autre avantage du contrat persistant est la possibilit de le conclure sans que les parties ne soient toutes prsentes. Un service de pilotage automatique est install sur un vhicule automobile. Il a besoin entre autres de donnes fournies par des capteurs de gopositionnement (reprsents par leur device respectifs) et par un acclromtre. Dans les accords liant ce service au device du GPS1, le GPS garantit une disponibilit de 30 secondes par minute. Le service de pilotage accepte ce contrat et donc le fait que le device puisse disparaitre 30 secondes par minute. Le vhicule passe sous un tunnel, le service GPS devient indisponible. A ce moment, le contrat ne doit pas tre rompu! La liaison, donc le contrat, est conserve jusqu' ce que le service revienne ou jusqu' ce que l'chance (i.e les 30 secondes) soit coule. A partir de la dernire position reue par le service GPS et des donnes de l'acclromtre le service de pilotage automatique peut continuer guider le vhicule pendant 30 secondes. Une fois ce dlai pass, l'erreur due aux calculs devient trop importante pour garantir la scurit, il y a danger. Donc si le vhicule n'est pas sorti du tunnel au bout de ce dlai, soit le pilotage dynamique automatique est dsactiv et le contrle rendu au conducteur, soit l'utilisation d'un autre protocole de gopositionnement, comme un service GPRS2 par exemple, est ngocie. Toutefois si le vhicule sort du tunnel en moins de 30 secondes et que le service GPS redevient disponible, alors la liaison persistante qui avait t conserve est rutilise et le service de pilotage automatique peut nouveau exploiter les donnes fournies par le GPS.
3.3.3. Stabilit de l'architecture, dynamique dans un ensemble statique

Description du problme: Dans certains cas, il est ncessaire de pouvoir garantir une stabilit au sein mme d'un environnement dynamique. On parle alors de dynamique dans un ensemble statique 3. L'usager se fixe un ensemble de services qu'il souhaite utiliser pendant une priode de temps T. Pendant cette priode, les services choisis peuvent disparatre et rapparatre dynamiquement si le contrat prvoit cette possibilit, mais de nouveaux services ne seront pas accepts; l'usager ne sera notifi que des arrives des services slectionns. Considrons le cas de la surveillance d'un rseau d'quipements lectriques, domaine de Schneider Electric. Supposons qu'un calcul est effectu tous les midis partir de donnes collectes
1 Global Positioning System 2 Global Packet Radio Service 3 En anglais, Dynamic in a Static Set (DSS)
44 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services pendant une demi-heure. Pendant ce calcul, on ne souhaite pas que l'architecture du systme change dynamiquement. Le scintillement, c'est--dire les arrives et dparts intempestifs de services, est effectivement un aspect des architectures orientes services dynamiques qu'il faut viter lorsqu'une architecture stable est ncessaire. A 11h45 le service mtier charg du calcul vrouille l'architecture jusqu' 12h15. Le vrouillage consisterait interdire l'arrive de nouveaux services et leur liaison. Le device d'un nouvel quipement qui arriverait sur le rseau pendant cette plage horaire ne pourrait donc pas tre dploy sur la plateforme services ni signer de contrat avec le service mtier.
45 / 65
3.4. Modle d'architecture dynamique oriente service supportant les accords de niveau de service
Nous proposons dans ce chapitre de fournir un modle d'architecture oriente service supportant les accords de niveau de service. Le modle doit rester assez gnrique pour tre applicable plusieurs scnarios vus dans la partie prcdente. Comme expliqu dans la section 3.1, nous ne pouvons traiter tous les problmes simultanment. Nous nous intressons ici principalement la disponibilit dynamique et son impact sur les accords de niveau de service. Pour le moment, nous ne nous intressons pas la modlisation des accords de niveau de service qui sera aborde dans la section suivante. Nous devons alors faire plusieurs hypothses : i. Les diffrentes parties sont en accord sur la smantique utilise dans les SLAs et les interprtent de manire non ambige. ii. Les accords de niveau de service ne sont pas modliss mais ils doivent tout de mme contenir les parties engages par le contrat, des critres de qualit de service, et les contraintes et obligations de chaque partie. iii. Les accords sont tablis d'aprs les besoins de l'usager et la proposition de contrat du fournisseur du service. iv. Chaque service peut tre identifi de manire unique, ceci afin de supporter la disponibilit dynamique. Nous considrons qu'un service possde un identifiant persistant appel <pid> afin de l'identifier lors de ses rapparitions. Un point intressant du modle propos est qu'il peut tout fait coexsiter sur une plateforme services classique, c'est--dire qui ne prend pas en charge la gestion des accords de niveau de service. Dans le cas o un service est utilis en dehors d'un accord ngoci, le fournisseur de service peut rejeter la demande de l'usager ou bien fournir le service sans aucune garantie ni obligation de rsultat.
3.4.1. Vue gnrale

Le modle que nous dfinissons, reprsent sur la figure 15, est centralis. Il est ax autour d'un service de gestion des accords de niveau de service: le SLAService fourni par le SLA Manager qui est publi dans le registre de service de la plateforme d'excution et donc utilisable par tout usager. La cration des accords de niveau de service (SLA) revient au SLA Manager. Le processus est expliqu dans la partie suivante. Le SLA Manager est aussi charg d'orchester les interactions et les accords passs entre usagers et fournisseurs de services. Grce une combinaison des patrons proxy et intercepteur, les interactions entre un usager et le service qu'il utilise peuvent tre capturs par le SLA Manager dans un objectif de surveillance du respect des accords de niveau de service. Ces tches d'instrumentation (mesures, cration et stockage d'historiques ou de fichier de log si ncessaire), de surveillance ainsi que de prise de dcision en cas de violation des accords, que nous nommerons SLM (pour Service Level Management) pour plus de commodit, sont dlgues un 46 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services ou plusieurs auditeurs tiers (appels Audit sur la figure 13). Nous avons choisi de dlguer les oprations de cration et de suppression d'auditeurs une fabrique d'auditeurs qui se prsente sous la forme d'un service, le SLMService. Les sections qui suivent dtaillent le rle de chaque entit pr-cite.
Service Registry
SLA Service
SLA Manager
SLA interceptor
Consumer Requirements x Prov ider ContractProposal
Service Requester 1
SLA Service
Service A Service B
Dynamic sla.Service A Proxy
Service A
Service Provider A
Service Requester 2
SLA Service Service B
Dynamic interceptor Proxy Dynamic interceptor sla.Service B Proxy
Service B
Service Provider B
SLM Service
SLM Service
+Audit createAudit(SLA) +void removeAudit(Audit)
Audit
+pre-invoke +post-Invoke
SLM Service
Audit Factory
Audit1 Audit2
Audit3
Figure 15. Modle d'architecture oriente service supportant les accords de niveau de service
3.4.2. SLA
L'objet 'SLA' (Service Level Agreement) reprsente un accord de niveau de service conclu entre un usager et un ou plusieurs fournisseur de services. Avant l'utilisation du service, l'accord doit tre tabli. Il est le rsultat d'une adquation entre les besoins de l'usager et la proposition de contrat du (ou des) fournisseur(s) de service (voir la section 3.4.6. 'ContractProposalService'). Si nous nous plaons dans le cas simple d'un contrat bi-partie, chaque liaison usager-service est associ un accord de niveau de service. Dans le cas plus complexe d'un contrat multi-parties pass entre un usager et n fournisseurs de service du mme type, un accord de niveau de service peut correspondre 47 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services l'ensemble des liaisons vers ces services. Par exemple un service peut faire appel N capteurs effectuant la mme tche, et si les accords de niveau de service intgrent la notion de groupe de fournisseurs, alors un seul accord peut suffir pour le groupe de capteurs. Un modle de structure pour les accords de niveau de service est propos dans la partie 3.5.
3.4.3. SLAService
Le service fourni par le SLA Manager permet d'tablir les accords de niveau de service. Une fois qu'ils sont tablis, le service SLAService veille ce qu'ils soient respects. Pour cela, il utilise les patrons de proxy et d'intercepteur.
3.4.3.1. Proxy dynamique et sla.<service pid>
Figure 16. Diagramme UML du patron proxy . Lorsqu'un usager dcide de passer par le SLAService pour utiliser un service S, le SLA Manager cr dynamiquement un proxy du service S: un reprsentant qui a la mme syntaxe donc la mme interface dans une approche oriente objet (voir figure 16). Pour cela le SLA Manager fournit dynamiquement un service S' identique au service S l'identifiant prs (voir hypothse iv). Si le service S est identifi par <S.pid>, alors S' sera identifi par <"sla".S.pid>. La liaison se fait entre l'usager et le service S' qui se charge de la liaison avec S. Un des avantages de cette solution est le fait que S' puisse rester disponible alors que le service S n'est plus l. Au retour de S, la liaison est dj en place, le contrat n'a pas t rompu grce sa persistance. De plus ce schma permet d'intgrer aisment un intercepteur si l'on dsire effectuer des mesures ou des traitements sur les interactions entre l'usager et le service S.
3.4.3.2. Intercepteur
Nous avons effectivement choisi d'utiliser un intercepteur la suite du proxy dynamique. 48 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services Lorsque l'usager invoque une mthode d'un service, le proxy se charge de propager l'appel ce service. C'est ici qu'intervient l'intercepteur: le proxy lui dlgue l'invocation du service. L'intercepteur connait le service et l'opration appeler, ainsi que les paramtres ncessaires. L'avantage d'un patron 'intercepteur' est qu'il permet d'effectuer des oprations de traitement ou des mesures avant et aprs l'invocation du service. Connaissant les accords de niveau de service, il est alors possible de vrifier leur respect ou leur violation. Pour cela, les accords de niveau de service sont fournis au service SLMService.
3.4.4. SLMService
L'Audit Factory est comme son nom l'indique, une fabrique d'auditeurs. Les auditeurs sont reprsents par les objets Audit sur la figure 15 et leur fonctionnement est expliqu dans la partie suivante. Chaque auditeur est cr par un intercepteur partir des accords de niveau de service et peut tre supprim la fin de l'utilisation du service, ou la rupture du contrat, par les oprations suivantes:
Audit createAudit(SLA) void removeAudit(Audit)
Supposons le service SLMService enregistr dans le registre de services. Le SLA Manager a cr un contrat C1 impliquant un usager U1 et un fournisseur F1 de service S1, ainsi qu'un deuxime contrat C2 impliquant respectivement U2, F2 et S2. Avant que la liaison ne soit tablie entre U1 (respectivement U2) et S1 (respectivement S2), le SLA Manager (plus prcisment l'intercepteur) utilise le service SLMService pour crer un auditeur A1 charg de surveiller le respect de C1 et un auditeur A2 charg de surveiller C2. La fabrique d'auditeurs pourrait tre enrichie avec des mthodes de passivation, d'activation et de recherche d'auditeur propres au patron de fabrique, mais ce n'est pas le but de notre proposition.
3.4.5. Auditeurs tiers

Dans notre modle, les auditeurs tiers sont crs et utiliss par les intercepteurs. Avant d'appeler un service l'intercepteur permet l'auditeur de prendre des mesures s'il le souhaite en appelant une mthode pre-invoke; et avant de retourner le rsultat de l'appel grce l'opration post-invoke. Les auditeurs doivent galement tre capables d'agir sur les parties concernes en cas de violation des accords par exemple. Ceci est possible d'aprs l'hypothse ii: les accords de niveau de service fournissent aux auditeurs les identifiants des parties impliques. Nous ne nous proccupons pas de la manire dont un auditeur peut agir sur les parties mais voici quelques propositions: Un systme de publication / souscription pourrait permettre aux parties signataires d'couter les vnements de type "pnalits" mis par les auditeurs en charge de leurs accords de niveau de service. Les parties signataires pourraient galement fournir un service implmentant les pnalits contenues dans les accords et l'auditeur n'aura qu' utiliser ce service. Enfin, les actions issues de la prise de dcision par les auditeurs peuvent tre soit synchrones, soit asynchrones. Concernant l'origine des auditeurs, nous avons fait le choix de crer les auditeurs dynamiquement la demande, mais ce n'tait pas la seule solution possible. Une variante consiste utiliser des 49 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services auditeurs dj dploys qui fournissent des services de surveillance. On a alors une architecture de type plug-in o des services d'audit (qui doivent tout de mme implmenter les mthodes preinvoke et post-invoke) sont recherchs en passant par le registre de service et se branchent au SLA Manager (plus prcisment l'intercepteur). Un service de ce type pourrait par exemple tre construit suivant une architecture de type gestionnaire autonomique [Escoffier2005]. NB: Les auditeurs doivent prendre en compte lors de l'valuation du respect des critres de qualit de service les cots lis l'instrumentation et la prise de dcision, oprations qui perturbent le systme.
3.4.6. ContractProposalService
Les accords de service sont tablis d'aprs les besoins de l'usager et la proposition de contrat du fournisseur, qui, notons-le, peut trs bien contenir des contraintes sur l'usager. Deux solutions sont envisageables. La premire, plus simple, consiste enregistrer la proposition de contrat dans le registre de service, en tant que proprit par exemple. La seconde est de passer par l'utilisation d'un service fourni par le SLA Manager: ContractProposalService. Comme illustr sur la figure 17, le SLA Manager fournit un service permettant au fournisseur d'enregistrer ses propositions de contrat (par une mthode register(ContractProposal) par exemple). Ceci l'avantage de les rendre persistantes et de pouvoir mener des tches de ngociation lorsque le service requis n'est pas encore disponible.
ConctractProposal Service
SLA Manager
ConctractProposal Service
SLA
Consumer Requirements x Prov ider ContractProposal
Service A
Service Provider A
Figure 17. Le SLA Manager fournit un service de proposition de contrat
3.4.7. Proposition pour une architecture rpartie

L'architecture que nous avons prcdemment propos est centralise autour du SLA Manager. Bien que les auditeurs, les usagers et les fournisseurs de services puissent tous se trouver sur des sites diffrents, le SLA Manager demeure une seule entit monolithique. Une autre solution que nous ne dtaillerons pas dans ce document est de rpartir les fonctions du SLA Manager sur les usagers et les fournisseurs de service (que l'on soit dans un contexte centralis ou distribu). L'instrumentation pourrait ainsi se faire directement la source. 50 / 65
3.5. Modle d'accords de niveau de service supportant la disponibilit dynamique

Nous avons choisi de modliser la liaison entre un usager et un fournisseur de service par un contrat auquel les deux parties souscrivent. La liaison est effective si et seulement si les termes du contrat sont accepts par les deux parties. La ngociation a donc lieu avant la liaison. Les termes du contrat pouvant voluer dynamiquement, l'usager doit accepter les nouvelles clauses pour continuer utiliser le service. Nous considrerons que l'usager spcifie ses exigences pour chaque clause (sous forme d'un intervalle de valeurs) et que si le nouveau contrat propos par le fournisseur ne respecte pas ces contraintes, le contrat et donc la liaison sont rompus. La ngociation correspond dans notre cas une simple adapatation de la proposition de contrat du fournisseur aux exigences de l'usager. D'aprs les travaux de [Dan2004] et la spcification WSLA [Ludwig2003], les accords de niveau de service peuvent tre dcoups en trois parties: les parties engages par le contrat, la description du service et les obligations. Nous avons prfr isoler la description du service tout en gardant l'esprit les diffrentes parties constitutives d'un accord de niveau de services dcrites par [Miller1987] et prsentes dans la section 2.3.1. Nous avons donc choisi de dcouper les accords sur le modle de WSLA en trois sous-parties (voir figure 18): les parties concernes par le contrat, les paramtres SLA, les pnalits.
3.5.1. Les parties

La section 'parties' contient les identifiants des parties concernes par le contrat, savoir l'usager, le ou les services (les parties signataires), et les parties tierces appeles auditeurs tiers charges de surveiller et d'valuer le respect des accords. Bien entendu l'identifiant des parties doit tre unique et persistant, ceci pour plusieurs raisons: L'identifiant d'un service ne doit pas changer au cours de l'excution afin que les accords de niveau de service puissent tre persistants et supporter le dpart et le retour d'un service. Le scnario traitant de la dynamique dans un ensemble statique (section 3.3.3) suppose que les identifiants de l'ensemble de fournisseurs choisis ne changent pas l'excution, mme en cas de dpart d'un des services. Un auditeur tiers doit pouvoir identifier de manire unique les diffrentes parties engages pour par exemple mener bien ses tches de facturation ou de pnalisation. L'identifiant doit permettre de localiser la partie. En pratique, ce peut-tre une URL, un port, ou bien une cl permettant d'obtenir une rfrence sur la partie en question.
51 / 65
Figure 18. Notre modle UML de structuration des accords de niveau de service.
52 / 65
3.5.2. Les paramtres SLA

Les paramtres SLAs reprsentent les critres de qualit de service, et les accords de niveau de service dfinissent leur valeur. Nous supposons que les parties contractantes ainsi que les parties charges de l'valuation des accords comprennent les paramtres de la mme manire et utilisent la mme mtrique. Nous avons fais le choix de dfinir chaque paramtre par un intervalle de valeurs. Par exemple, le temps de rponse serait dfini par
responseTime.min = 0 et responseTime.max = 2
l'unit de mesure tant la seconde. Afin de supporter la disponibilit dynamique, tout accord de niveau de service construit sur notre modle doit inclure le paramtre suivant: dynamicAvailability. Il est exprim en pourcentage par rapport une fentre de temps exprime en secondes par exemple. Ainsi,
dynamicAvailability.rate = 50 et dynamicAvailability.window = 3600
signifie que pendant une heure le service assure une prsence de 30 minutes. Un autre paramtre ajouter est la date de validit des accords. Ces derniers ont une dure de vie limite et sont susceptibles d'tre changs selon les changements de politique du fournisseur de service. S'ils ne sont pas modifis avant la date limite de validit, alors le contrat devient invalide et est rompu. Les paramtres SLAs peuvent aussi bien tre des contraintes imposes au client. Par exemple,
clientCallsPerSecond.min = 0 et clientCallsPerSecond.max = 2
impose au client de ne pas effectuer plus de 2 appels par seconde. Le prix du service, c'est--dire la compensation pour le service fourni doit galement tre dclar dans cette section. Paramtres SLA englobe donc des critres de qualit de service dont les valeurs sont comprises dans un intervalle dfini par un minimum et un maximum, ainsi que les trois paramtres suivants: la disponibilit dynamique: elle est dfinit par un pourcentage sur une fentre de temps; la date de validit du contrat; la compensation pour le service fourni qui est plus ou moins quivalente au prix du service. Pour cette partie, nous n'imposons pas de formalisme puisque les cas peuvent tre extrmement divers.
3.5.3. Les pnalits

La dernire partie concerne les pnalits et plus gnralement les actions entreprendre. Nous avons choisi pour notre modle de les prsenter sous la forme de rgles ECA (vnement > condition > action) o l'vnement correspond simplement un paramtre SLA qui n'a pas t respect, les conditions sont des expressions boolennes et les actions sont des oprations pouvant tre composes d'une srie de plusieurs actions. Voici quelques exemples comments de ces rgles:
<clientCallsPerSecond.max, serviceAvailable, client.addPenality(50)>
=> Si un auditeur dtecte que le client fait trop d'appels en une seconde et que pourtant le service est disponible (ce ne sont donc pas des tentatives de connexion au service), alors la pnalit du client est augmente. Ici ce peut tre de 50 points ou une surtaxe de 50 puisque la mtrique n'est pas prcise.
<dynamicAvailability, anotherServiceIsAvailable, serviceProvider.blacklist & changeService>
53 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services => Si le fournisseur n'a pas respect sa contrainte de disponibilit dynamique (en n'ayant pas assur un service de 30 secondes par minute par exemple), et si un autre service est disponible, alors le fournisseur fautif est mis sur la liste noire de l'usager et ne sera plus utilis, et.
<validityDate, null, rompre_le_contrat>
=> La date de validit a expir, le contrat est rompu. Concernant les actions entreprendre, plusieurs politiques sont possibles. Outre la rupture de contrat, il est possible de surtaxer un service, d'utiliser un systme de bonus / malus similaire ce qui se fait dans le monde des assurances, ou encore de mettre une partie sur la liste de noire d'une autre partie. Dans le cas d'un usager qui dpasse le quota qui lui est accord, notre architecture grce l'utilisation des patrons proxy et intercepteur permet de geler les appels du client ou de lui renvoyer une exception, plutt que de transmettre son appel au service.
54 / 65
4. Exprimentation et validation de notre modle d'architecture

Ce chapitre montre une ralisation de notre modle construit sur la plateforme services OSGi. Le but de ce prototype est de valider notre proposition en exprimentant un scnario de gestion de la disponibilit dynamique dans les accords de niveau de service.
4.1. Scnario du prototype

Afin d'exprimenter notre modle, nous avons choisi d'illustrer le scnario de la section 3.3.2, c'est--dire un cas de violation de la clause portant sur la disponibilit dynamique. Une application StockRequester utilise un service de cotation boursire de type StockService qui lui permet de rclamer intervalle rgulier (toutes les secondes) diffrentes cotations boursires . Le service StockService attend un temps T alatoire avant de servir StockRequester. Deux services de type StockService sont dploys: StockServiceSilver et StockServiceGold dont le temps de rponse alatoire T est infrieur respectivement 3 et 2 secondes et dont le prix est respectivement de 1 et 2 par information. L'application StockRequester exige un temps de rponse infrieur 2 secondes et on suppose que les deux fournisseurs acceptent cette garantie. Les accords de niveau de service garantissent donc un temps de rponse maximal de 2 secondes. Dans un premier temps StockRequester choisit d'utiliser le StockServiceSilver (un StockService avec un attribut type = 'silver') puisqu'il est moins cher. Au bout d'un certain temps, le StockServiceSilver rpond aprs 2 secondes et viole la clause portant sur le temps de rponse. Le rsultat de la requte est intercept par le SLA Manager qui a dtect le non-respect de l'accord et est remplac par un message SLA non respect . StockRequester interprte ce message et dcide de ne plus utiliser ce StockService et d'en choisir un de type Gold. Le service Gold prcise dans son contrat une disponibilit de 50% sur une fentre de 10 secondes. Une fois la liaison tablie, le service disparat au bout de 2 secondes puis rapparait 2 secondes plus tard. La liaison n'est pas rompue pendant cet intervalle. Mais il redisparait 2 secondes plus tard et n'a toujours pas rapparu au bout des 10 secondes. Le SLA Manager considre alors que la garantie de disponibilit dynamique n'a pas t respecte et que le contrat est rompu. StockRequester en est averti par une exception du SLA Manager et ne se fait pas facturer les informations qu'il a reu.
55 / 65
4.2. Choix de la plateforme

Nous avons choisi d'exprimenter notre modle sur la plateforme dynamique services Oscar/Flix, implmentation d'OSGi (pour plus de dtails voir section 2.1.2.4) pour plusieurs raisons. La plateforme OSGi est particulirement adapte aux services colocaliss sur une mme machine virtuelle Java et convient de ce fait l'administration d'quipements en rseau. De plus en tant que surcouche la plateforme Java 2, la plateforme OSGi intgre une bonne gestion de la scurit, ce qui reprsente un avantage considrable pour la gestion d'accords de niveau de service. La plateforme OSGi offre une gestion avance de la dynamique, et la plateforme Java fournit depuis la version 1.3 une implmentation de proxy dynamique, java.lang.reflect.Proxy, ce qui nous a facilit la tche.
4.3. Architecture du prototype

SLA Manager
StockService
type = Silver
StockService SLA1
Stock Service Silver

StockService
Stock
Requester
SLA2
type = Gold
Stock Service Gold
Audit Figure 19. Architecture de notre prototype pour un scnario de cotation boursire
56 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services Nous utilisons un modle simplifi d'accord de niveau de service, ainsi qu'un service d'audit relativement simple. Pour exemple, voici le contenu de l'accord liant StockRequester au StockServiceGold d'aprs le scnario:
//parties RequesterID = StockRequester.pid ProviderID = StockService.pid AuditID = ... //dfini la cration de l'Audit ... //paramtres SLA pricePerMessage = 2; responseTime.MAX = 2; dynamicAvailability.rate = 50; dynamicAvailability.window = 10; ... //pnalits <responseTime, anotherStockServiceIsAvailable, rompre_contrat & changeService> <dynamicAvailability, null, noBillig> ...
Le SLA Manager se prsente sous la forme d'un bundle exposant un service SLAService. Dans un souci de clart nous avons fait le choix de ne pas le reprsenter sur la figure 19 qui illustre l'architecture de notre prototype. Un premier auditeur est cr pour surveiller le respect des accords SLA1 entre le StockRequester et le StockServiceSilver. A la rupture du contrat, le StockRequester se lie avec le StockServiceGold et un nouvel auditeur est cr pour surveiller le respect de l'accord SLA2 entre ces deux parties.
4.4. Validation
Nous avons commenc par installer sur la plateforme Oscar (par la commande install <bundle_URL>) les diffrents bundles ncessaires au fonctionnement de notre prototype avant de dmarrer leur services par la commande start <ID>, savoir (dans l'ordre): le SLA Manager qui fournit le service SLA Service et requiert le service SLM Service. Le SLA Manager contient galement les accords prdfinis SLA1 et SLA2 car nous n'avons pas ralis de mcanisme de ngociation; le bundle AuditFactory qui fournit le service SLM Service; deux bundles StockServiceSilver et StockServiceGold qui fournissent un service StockService, dont l'implmentation possde un attribut 'type' gal respectivement 'silver' et 'gold' et dont le temps alatoire avant la rponse est infrieur respctivement 3 et 2 secondes. Le bundle StockRequester qui requiert le service SLA Service et le service StockService. Le StockRequester commence alors par utiliser le SLA service afin d'obtenir une rfrence sur le reprsentant du StockService de type 'silver'. Il peut alors intragir avec le service StockServiceSilver en passant par le proxy dynamique et ses interactions sont interceptes par l'auditeur cr juste avant la liaison par le SLA Manager. Une fois que la rupture du contrat pour dpassement de dlai par le service Silver a t dtecte, la liaison est rompue et le StockRequester cherche donc se lier au StockServiceGold, toujours en utilisant le SLA Service. 57 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services Pendant l'utilisation du service gold, nous simulons l'apparition et la disparition du service en arrtant et redmarrant le service par la commande stop <ID>. Si nous l'arrtons plus de 5 secondes, nous nous apercevons que mme en redmarrant le service, il n'est plus utilis par le StockRequester: le contrat, donc la liaison, a t rompu. Ce prototype nous permis de valider notre modle qui fonctionne bien au moins pour ce scnario. L'auditeur attach la liaison a pu intercepter les interactions entre les l'usager et les fournisseurs de service grce au patron de proxy dynamique, prendre des mesures de temps et jouer son rle en appliquant les pnalits dfinies dans les accords de niveau de service.
58 / 65
5. Conclusion et perspectives
5.1. Positionnement de notre contribution
Les accords de niveau de service ont toujours t trs lis au contexte des rseaux et la recherche dans le domaine des accords de niveau de service a acquis un certain degr de maturit. Aujourd'hui, avec la prolifration des plateformes services qui souvent sont multi-fournisseurs, les besoins d'accords de niveau de service dans ce domaine sont de plus en plus forts. Mais du fait de leurs domaines d'application, les architectures services connaissent galement un besoin de dynamique croissant. Or ce caractre dynamique n'est pas encore assez considr par les nombreux travaux portant sur les accords de niveau de service. C'est pourquoi nous avons propos, pour rpondre ces nouveaux besoins, un modle d'architecture dynamique prenant en charge les accords de niveau de service, ainsi qu'un modle d'accord de niveau de service intgrant les concepts propres aux architectures dynamiques orientes service.
5.2. Perspectives court terme

Nous envisageons plusieurs perspectives ces travaux. Nos perspectives court terme:
Exprimentation avec des moteurs de rgles Une exprimentation approfondie de notre modle d'accord de niveau de service requiert de dfinir des accords plus prcis pour tester son extensibilit. De mme, la partie pnalits de notre modle d'accord ainsi que tout ce qui se rapporte aux actions entreprendre en cas de violation d'une clause du contrat (comme le fonctionnement des auditeurs par exemple), mriterait d'tre tudi plus en dtail, notamment l'excution des rgles ECA que nous n'avons pas trait. Proposition de mcanismes de ngociation Dans notre tude nous avons galement fait le choix de ne pas nous proccuper des mcanismes de ngociation. Enrichir notre modle d'un schma de ngociation plus complexe que la simple slection de service dans un registre, et faisant intervenir pleinement les parties contractantes, serait un atout considrable et valoriserait notre travail. Validation de l'approche sur le modle de composant SCA Il serait enfin intressant de modliser et de valider la version rpartie de notre SLA Manager que nous avons voqu dans la section 3.4.7. En effet, il y a des cas, par exemple pour les services Web, o l'instrumentation doit tre faite au niveau du demandeur et du fournisseur de service. SCA (Service Component Architecture) est 59 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services un projet visant faciliter la construction d'architectures orientes service en encapsulant des composants prexistants dans des services Web. Les applications construites sur la plateforme SCA sont donc majoritairement rparties. Une perspective de dveloppement futur consiterait fournir partir du modle rparti du SLA Manager un canevas pour la prise en charge des accords de niveau de service sur cette plateforme prometteuse. Nos dveloppements s'appuieront sur les canevas iPOJO [Escoffier2006] et Spoon [Pawlak2005]. Ces deux canevas ont pour objectif de sparer les aspects fonctionnels des aspects non fonctionnels et particulirement dans le contexte de la dynamique dans la gestion des accords de niveau de service.
5.3. Perspectives long terme

Les perspectives long terme sont:
La prise en compte du temps critique dans les accords de niveau de service Nous ne l'avons pas cit dans ce document, mais il existe une trs forte demande, en particulier dans le domaine des systmes embarqus et critiques, pour des plateformes services dynamiques supportant la cohabitation de services temps rel, semi-temps rel et non-temps rel. De telles plateformes ncessiteraient des accords de niveau de service bien dfinis, et des mcanismes de ngociation permettant d'assurer une bonne gestion des ressources qui seraient contractualises, afin que l'excution de tches en temps rel, gnralement critiques, ne soient pas premptes par des tches d'importance moindre. Le comportement autonomique des certifieurs de service Nous n'avons pas non plus cherch modliser les certifieurs de services (ou auditeurs tiers). Toutefois, comme expliqu prcdemment, une solution particulirement efficace serait l'utilisation de l'informatique autonomique. Les processus de ngociation des accords de niveau de service, la surveillance et l'valuation de leur respect, ainsi que la prise de dcision pour les pnalits pourraient alors tre dirigs par des objectifs clairement dfinis et facilement maintenables. Les mtriques lies la dynamique des services Enfin, comme montr dans la section 3.1, notre tude a soulev plusieurs problmes dont l'accord des parties sur la smantique des contrats et des mtriques, problmes qui ne sont pas encore rsolus et qui ouvrent de nombreux axes de recherche.
60 / 65
6. Bibliographie
Bibliographie
[ADELE2005] [Ayed2003] [Beugnard1999] ADELE - Runions autour des services, 2005 Ayed, Dhouha and Taconet, Chantal and Bernard, Guy - Etude Comparative des Services de Recherche sur Proprits., 2003 Beugnard, A. and Jzquel, J.-M. and Plouzeau, N. and Watkins, D. - Making Components Contract Aware, 1999, IEEE Computer, Volume 32, Humberto Cervantes - Vers un modle a composants orient services pour supporter la disponibilit dynamique, Universit Joseph Fourier, 2004 H. Cervantes and R. S. Hall - Service Oriented Concepts and Technologies, Service-Oriented Software System Engineering: Challenges and Practices - Chapitre 1, Zoran Stojanovic and Ajantha Dahanayake, 2005 Kishore Channabasavaiah and Kerrie Holley and Edward Tuggle, Jr. - Migrating to a service-oriented architecture, 2004, IBM DeveloperWorks White Paper, Volume , RL Information Consulting - A Description of Service Level Agreements, 2002 Jolle Coutaz and James L. Crowley and Simon Dobson and David Garlan - Context is key, 2005, Commun. ACM, Volume 48, ACM Press Cyberfab, http://www.cyberfab.net Asit Dan and Doug Davis and Robert Kearney and Alexander Keller and Richard P. King and Dietmar Kuebler and Heiko Ludwig and Mike Polan and Mike Spreitzer and Alaa Youssef Web services on demand: WSLA-driven automated management., 2004, IBM Systems Journal, Volume 43, Didier Donsez and Pierre Yves Gibello - Advanced Transaction Models for EJB and Web Services, 2001 61 / 65
[Cervantes2004]
[Cervantes2005]
[Channabasavaiah2004]
[Consulting2002] [Coutaz2005]
[Cyberfab] [Dan2004]
[Donsez2001]
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services [Donsez2005] [Escoffier2005] [Escoffier2006] [Hanemann2005] Didier Donsez - Atelier mise en uvre d'UPnP avec OSGi , 2005 Clment Escoffier - Administration autonomique dans le contexte du Edge Computing, Universit Joseph Fourier, 2005 iPOJO, http://www-adele.imag.fr/~escoffie/dev/ipojo/ Andreas Hanemann and David Schmitz and Martin Sailer - A Framework for Failure Impact Analysis and Recovery with Respect to Service Level Agreements. - IEEE SCC, 2005 Information Society Technologies IST - The Software and Services Challenge, 2006 F. Jammes and H. Smit - Service-Oriented Architectures for Devices the SIRENA View, 2005 Franois Jammes and Antoine Mensch and Harm Smit - Serviceoriented device communications using the devices profile for web services - MPAC '05: Proceedings of the 3rd international workshop on Middleware for pervasive and ad-hoc computing, 2005 A. Keller and H. Ludwig - Defining and Monitoring Service Level Agreements for dynamic e-Business, 2002 J. O. Kephart and W. E. Walsh and T. J. Watson - An Artificial Intelligence Perspective on Autonomic Computing Policies Fifth IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY'04), 2001 J. O. Kephart and D. M. Chess - The Vision of Autonomic Computing, 2003, Computer, Volume 36, IEEE Computer Society Press D. Davide Lamanna and James Skene and Wolfgang Emmerich SLAng: A Language for Defining Service Level Agreements. FTDCS, 2003 Heiko Ludwig and Alexander Keller and Asit Dan and Richard P.King and Richard Franck - WSLA Language Specification, Version 1.0, 2003 Brian A. Malloy and Nicholas A. Kraft and Jason O. Hallstrom and Jeffrey M. Voas - Improving the Predictable Assembly of Service-Oriented Architectures, 2006, IEEE Software, Volume 23, IEEE Computer Society Press 62 / 65
[IST2006] [Jammes2005] [Jammes2005a]
[Keller2002] [Kephart2001]
[Kephart2003]
[Lamanna2003]
[Ludwig2003]
[Malloy2006]
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services [Marin2005] Cristina Marin and Philippe Lalanda and Didier Donsez - A MDE Approach for Power Distribution Service Development. ICSOC, 2005 D. Marples and S. Moyer - Home Networking and Appliances, Smart Environments:Technologies, Protocols and Applications (Diane Cook, Sajal Das) - Chapitre 6, Wiley, 2004 Bertrand Meyer - Applying Design by Contract, 1992, IEEE Computer, Volume 25, George W. (Bill) Miller - Service Level Agreements: "Good Fences Make Good Neighbors". - Int. CMG Conference, 1987 Motahari Nezhad, H.R. and Benatallah, B. and Casati, F. and Toumani, F. - Web Services Interoperability Specifications, 2006, IEEE Computer, Volume 39, Nicole Oldham, Kunal Verma, Amit P.Sheth, Farshad Hakimpour - Semantic WS-Agreement Partner Selection, 2006 The OSGi Alliance, http://www.osgi.org Adrian Paschke and Martin Bichler - SLA Representation, Management and Enforcement., 2005 Adrian Paschke and Martin Bichler and Jens Dietrich ContractLog: An Approach to Rule Based Monitoring and Execution of Service Level Agreements., 2005 RBSLA: Rule-based Service Level Agreement, http://ibis.in.tum.de/staff/paschke/rbsla/ Pawlak, R. - Spoon: Annotation-Driven Program Transformation - The AOP Case., 2005 Barry Redmond and Vinny Cahill - Supporting Unanticipated Dynamic Adaptation of Application Behaviour. - ECOOP 2002 Object-Oriented Programming, 16th European Conference, Malaga, Spain, June 10-14, 2002, Proceedings, 2002 C. Sierra and P. Faratin and N. Jennings - A Service-Oriented Negotiation Model between Autonomous Agents - Proceedings of the 8th European Workshop on Modeling Autonomous Agents in a Multi-Agent World (MAAMAW-97), 1997 Snoonian, D. - Smart buildings, 2003, Spectrum, IEEE, Volume
[Marples2004]
[Meyer1992] [Miller1987] [Motahari2006]
[Oldham2006] [OSGi] [Paschke2005] [Paschke2005a]
[Paschke2006] [Pawlak2005] [Redmond2002]
[Sierra1997]
[Snoonian2003]
63 / 65
TOUSEAU Lionel Accords de niveau de service dans les plateformes dynamiques services 40, [Software2004] [Stal2006] [Sterritt2005] [Tournier2005] [UPnP] [W3C2006] [Zschaler2004] End-end Software (ITS) - Service Level Agreements, 2004 Michael Stal - Using Architectural Patterns and Blueprints for Service-Oriented Architecture, 2006, IEEE Software, Volume 23, Roy Sterritt and Michael G. Hinchey - Autonomic Computing Panacea or Poppycock? - CBSE, 2005 Jean-Charles Tournier and Jean-Philippe Babau and Vincent Olive - Qinna, a Component-Based QoS Architecture. - CBSE, 2005 The UPnP Forum, http://www.upnp.org W3C Member Submission, http://www.w3.org/Submission/WSPolicy/ Steffen Zschaler and Simone Rttger - Types of Quality of Service Contracts for Component-Based Systems, 2004
64 / 65
7. Glossaire
Accord de niveau de service (Service Level Agreement, SLA): Contrat accept par l'usager et le (ou les) fournisseur(s) de service portant sur le niveau de service garanti par les parties et les contraintes respecter. Device: Equipement, et par extension, application reprsentant l'quipement. Fournisseur de service: Entit logicielle qui fournit un service. Proposition de contrat: Dans le cadre du SOA, contrat propos par un fournisseur de service avant qu'il ne soit accept par un usager. Registre / courtier de service (registry, trader ou broker en anglais): Entit propre aux architectures orientes service charge de la publication des services et de leur courtage. Rgle ECA: Rgle vnement-condition-action. Une rgle eca (E,C,A) signifie que lors d'un vnement E, si la condition C est vrifie, alors l'action A est mene. Service Level Management (SLM): Dsigne l'ensemble des mcanismes destins la prise en charge des accords de niveau de service. (Prise de mesure, de dcision, application des pnalits, facturation, journalisation, ...). Service Level Objectives (SLOs): Objectifs de qualit de service que se fixe un fournisseur de service. Dans les accords de niveau de service, ils sont assimils aux garanties du fournisseur. Service-Oriented Architecture (SOA): Architecture utilisant l'approche services. Utilisateur / usager / demandeur / consommateur de service: Entit logicielle qui utilise un service.
65 / 65

Sla

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Sla

Transféré par

Droits d'auteur :

Formats disponibles

Rapport de projet de Master 2 Recherche Systmes et Logiciels

Universit Joseph Fourier (Grenoble 1)

Accords de niveau de service dans les plateformes dynamiques services

ralis dans l'quipe ADELE du laboratoire LSR-IMAG de Grenble

Table des matires

Index des figures

1.3. Structure du document

2.1. Architectures orientes service dynamiques

2.1.1. Dfinition et concepts

Figure 1. Acteurs classiques d'une architecture oriente service

Figure 2. Patron d'interaction d'une architecture oriente services [Cervantes2004]

2.1.1.3. Architecture oriente service dynamique

1 En anglais, IT (Information Technology) 2 http://www.yahoo.com/ 3 http://www.ebay.com/

2.1.2. Plateformes services dynamiques

Figure 4. Schma d'interaction de services Web [Donsez2001]

1 Universal Plug and Play 2 Small Office Home Office

Media Center Gateway X10-UPnP

Gateway IEEE1394 FireWire-UPnP

2.1.2.4. Devices Profile for Web Services

1 Lightweight Directory Access Protocol

2.2.1. Dfinitions et concepts

1 business-to-business 2 En anglais, pattern

Contrat clause 1 ... clause n

1 En anglais, Design by Contract

2.2.2. Le contrat sur les diffrentes plateformes services

2.3. Accords de niveau de service

2.3.1. Dfinition et concepts

1 Gestion du niveau de service 2 Objectifs de niveau de service 3 En anglais, monitoring

Accord de niveau de service

Figure 9. Le certifieur de service valuation le respect de l'accord de niveau de service.

2.3.2. Travaux acadmiques

Figure 10. Architecture en couches de l'approche Rule Based SLA [Paschke2006]

2.3.3. Un standard mergeant: Web Service Level Agreements

1 www.ibm.com/ 2 Accords de niveau de services Web: WSLA 3 http://www.w3.org/TR/wsdl

Figure 12. Patron d'interactions du canevas WSLA [Keller2002].

Distribu (services de recherche)

Descripteurs XML des quipements et de leurs services (DPWS utilise WSDL)

Interface ou classe Java + proprits

Ngociation Filtrage / slection

Messages dans des enveloppes SOAP

Appels locaux de mthodes Java (par rfrences) Arrive, dpart et modification

Notifications Arrive, dpart et

Portabilit / langages supports SLA

Java avec possibilit de passerelles vers d'autres plateformes Rien

Tableau 1. Rcapitulatif des caractristiques de quelques plateformes dynamiques services

3. Prise en compte de la dynamique dans les accords de niveau de service

3.1. Identification des problmes soulevs

3.1.1. Modlisation de l'accord et smantique

3.1.2. Contractualisation du comportement d'un service

3.1.3. Composition de services et sous-contractants

SLA-1 Service A Service B

3.1.4. Ngociation et slection du contrat

3.1.5. Rengociation de contrat

3.1.6. Restitution de l'tat et du contexte, contrat persistant

3.1.7. Service Level Management et auditeur tiers

3.1.8. Pnalits et facturation

3.1.9. Confidentialit des ngociations

3.1.10. Impact de la dynamique sur les accords de niveau de service

3.2. Notre contexte: les rseaux d'quipements

1 http://www.schneiderelectric.com/ 2 Projet SIRENA: http://www.sirena-itea.org 3 www.mediacenter.org/

3.3.1. Rengociation de contrat dans un environnement ressources limites et fluctuantes

3.3.3. Stabilit de l'architecture, dynamique dans un ensemble statique

3.4.1. Vue gnrale