accords de niveau de service dans les ... - · remerciements je tiens à remercier toutes les...

Rapport de projet

de

Master 2 Recherche Systèmes et LogicielsUniversité Joseph Fourier (Grenoble 1)

Accords de niveau de service dans les plateformes dynamiques à services

Soutenu par:Lionel TOUSEAU

le21 juin 2005

devant:Joëlle COUTAZ

Jean-François MÉHAUTRachid ECHAHED

Patrick REIGNIER (Rapporteur)Didier DONSEZ (Directeur)

réalisé dans l'équipe ADELEdu laboratoire LSR-IMAG de Grenble

Résumé

Les plates-formes dynamiques à services occupent une place de plus en plus prépondérante dans l'industrie. Ces plates-formes permettent la réalisation d'applications dont l'architecture suit les paradigmes des architectures orientées service. Elles sont le support d'exécution pour des services qui apparaissent et disparaissent au cours de l'exécution d'une application.

Le niveau de service garanti par des fournisseurs de services est également une préoccupation 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 après la négociation 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 manière imprévisible. Un des principaux verrous à lever dans ce problème est la prise en compte de la dynamique des services dans les accords de niveau de service. L'objectif du travail présenté dans ce document est de proposer et d'évaluer des solutions à ce verrou.

Mots clés: Architecture orientée service, plateformes dynamiques à services, disponibilité dynamique, accords de niveau de service, contrat, réseaux 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 l’équipe ADELE du laboratoire LSR pour m’avoir accueilli lors de ce stage et permis d’acquérir une expérience enrichissante.

Je tiens à remercier particulièrement :– M. Patrick Reignier pour avoir accepté de rapporter ce travail.– Tous les membres du jury qui ont accepté d’évaluer mon travail.– M. Didier Donsez pour m’avoir encadré et pour ses conseils.– M. Philippe Lalanda pour avoir également participé à mon encadrement.– M. Jacky Estublier pour m’avoir donné la possibilité de travailler dans son équipe.– Mikaël Desertot, Clément Escoffier et Johann Bourcier pour m'avoir fait partager leur

expérience.– Laureline, pour sa patience et le soutien qu'elle m'a apporté tout au long de cette année.– Mes parents qui m'ont permis de poursuivre mes études grâce à 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 matières1.Introduction....................................................................................................................................... 9

1.1.Contexte..................................................................................................................................... 91.2.Problématique............................................................................................................................ 91.3.Structure du document............................................................................................................... 9

2.Etat de l'Art......................................................................................................................................102.1.Architectures orientées service dynamiques............................................................................10

2.1.1.Définition et concepts...................................................................................................... 102.1.1.1.Notion de service......................................................................................................112.1.1.2.Architecture Orientée Service.................................................................................. 112.1.1.3.Architecture orientée service dynamique................................................................. 13

2.1.2.Plateformes à services dynamiques..................................................................................152.1.2.1.Jini............................................................................................................................ 152.1.2.2.Services Web ...........................................................................................................162.1.2.3.Universal Plug and Play........................................................................................... 182.1.2.4.Devices Profile for Web Services............................................................................ 192.1.2.5.La plateforme OSGi................................................................................................. 20

2.2.Contrats....................................................................................................................................222.2.1.Définitions et concepts.....................................................................................................22

2.2.1.1.Definition générale................................................................................................... 222.2.1.2.Le contrat dans les architectures orientées service...................................................222.2.1.3.Négociation de contrat..............................................................................................24

2.2.2.Le contrat sur les différentes plateformes à services....................................................... 242.2.2.1.Jini............................................................................................................................ 242.2.2.2.Services Web............................................................................................................252.2.2.3.UPnP / DPWS.......................................................................................................... 252.2.2.4.OSGi.........................................................................................................................25

2.3.Accords de niveau de service ..................................................................................................262.3.1.Définition et concepts...................................................................................................... 262.3.2.Travaux académiques.......................................................................................................28

2.3.2.1.RBSLA: Rule-based Service Level Agreement (ContractLog)............................... 282.3.2.2.SLAng...................................................................................................................... 30

2.3.3.Un standard émergeant: Web Service Level Agreements................................................302.4.Synthèse................................................................................................................................... 33

3.Prise en compte de la dynamique dans les accords de niveau de service........................................353.1.Identification des problèmes soulevés..................................................................................... 35

3.1.1.Modélisation de l'accord et sémantique........................................................................... 353.1.2.Contractualisation du comportement d'un service........................................................... 36

5 / 65


3.1.3.Composition de services et sous-contractants..................................................................363.1.4.Négociation et sélection du contrat..................................................................................363.1.5.Renégociation de contrat..................................................................................................373.1.6.Restitution de l'état et du contexte, contrat persistant......................................................373.1.7.Service Level Management et auditeur tiers....................................................................383.1.8.Pénalités et facturation..................................................................................................... 383.1.9.Confidentialité des négociations...................................................................................... 383.1.10.Impact de la dynamique sur les accords de niveau de service....................................... 39

3.2.Notre contexte: les réseaux d'équipements.............................................................................. 403.3.Scénarios de négociation d'accords de niveau de service sur des plateformes dynamiques à services...........................................................................................................................................42

3.3.1.Renégociation de contrat dans un environnement à ressources limitées et fluctuantes...423.3.1.1.CPU et mémoire vive limités................................................................................... 423.3.1.2.Energie limitée......................................................................................................... 43

3.3.2.Négociation de la disponibilité dynamique d'un service, continuité de service et contrat persistant................................................................................................................................... 443.3.3.Stabilité de l'architecture, dynamique dans un ensemble statique................................... 44

3.4.Modèle d'architecture dynamique orientée service supportant les accords de niveau de service....................................................................................................................................................... 46

3.4.1.Vue générale.................................................................................................................... 463.4.2.SLA.................................................................................................................................. 473.4.3.SLAService...................................................................................................................... 48

3.4.3.1.Proxy dynamique et sla.<service pid>..................................................................... 483.4.3.2.Intercepteur...............................................................................................................48

3.4.4.SLMService..................................................................................................................... 493.4.5.Auditeurs tiers.................................................................................................................. 493.4.6.ContractProposalService..................................................................................................503.4.7.Proposition pour une architecture répartie....................................................................... 50

3.5.Modèle d'accords de niveau de service supportant la disponibilité dynamique...................... 513.5.1.Les parties........................................................................................................................ 513.5.2.Les paramètres SLA.........................................................................................................533.5.3.Les pénalités.....................................................................................................................53

4.Expérimentation et validation de notre modèle d'architecture........................................................ 554.1.Scénario du prototype.............................................................................................................. 554.2.Choix de la plateforme.............................................................................................................564.3.Architecture du prototype........................................................................................................ 564.4.Validation.................................................................................................................................57

5.Conclusion et perspectives.............................................................................................................. 595.1.Positionnement de notre contribution...................................................................................... 595.2.Perspectives à court terme....................................................................................................... 59

6 / 65


5.3.Perspectives à long terme........................................................................................................ 606.Bibliographie................................................................................................................................... 617.Glossaire.......................................................................................................................................... 65

7 / 65


Index des figuresFigure 1. Acteurs classiques d'une architecture orientée service....................................................... 12Figure 2. Patron d'interaction d'une architecture orientée services [Cervantes2004].........................13Figure 3. Architecture orientée service dynamique supportant la disparition de service...................14Figure 4. Schéma d'interaction de services Web [Donsez2001]........................................................ 17figure 5. Exemple de réseau UPnP [Donsez2005]............................................................................. 19Figure 6. Pile de protocoles pour DPWS [Jammes2005a]................................................................. 20Figure 7. La liaison entre un usager et un fournisseur suit un contrat bi-parties............................... 23Figure 8. Cas d'un contrat multi-parties............................................................................................. 23Figure 9. Le certifieur de service évaluation le respect de l'accord de niveau de service.................. 28Figure 10. Architecture en couches de l'approche Rule Based SLA [Paschke2006]......................... 29Figure 11. Les principaux concepts de WSLA [Ludwig2003]...........................................................31Figure 12. Patron d'interactions du canevas WSLA [Keller2002]. ................................................... 32Figure 13. Composition de services et sous-contractant.................................................................... 36Figure 14. Vue orientée service du modèle de réseau d'équipements................................................ 41Figure 15. Modèle d'architecture orientée service supportant les accords de niveau de service........47Figure 16. Diagramme UML du patron « proxy ». ........................................................................... 48Figure 17. Le SLA Manager fournit un service de proposition de contrat.........................................50Figure 18. Notre modèle UML de structuration des accords de niveau de service. ..........................52Figure 19. Architecture de notre prototype pour un scénario de cotation boursière.......................... 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 particulièrement dans le domaine des réseaux d'équipements. Les réseaux d'équipements sont un domaine relativement large allant des réseaux de capteurs industriels à la domotique en passant par des équipements embarqués sur des véhicules. L'approche à services est particulièrement bien adaptée dans ce contexte étant donné la grande diversité et l'hétérogénité d'équipements au sein d'un même réseau. Il s'agit de plus d'un domaine où la demande en dynamique est très forte. L'architecture de tels systèmes doit pouvoir évoluer dynamiquement au cours de l'exécution sans porter préjudice aux équipements en cours d'exécution sur la plateforme.

1.2. Problématique

L'objectif de notre travail se situe à l'intersection de trois domaines liés aux services. Il s'agit de prendre en compte la dynamique des services, caractéristique des architectures dynamiques orientées service, dans les accords de niveau de service. Ces accords font généralement 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 concernés par le sujet: les architectures orientées service dynamiques, la notion de contrat, et les accords de niveau de service.

Le chapitre 3 présente ensuite notre travail, à savoir une identification des problèmes inhérents aux domaines étudiés dans l'état de l'art, une définition de l'objectif de nos travaux à l'aide de scénarios, 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 modèle d'architecture orientée service dynamique prenant en charge la gestion des accords de niveau de service ainsi qu'un modèle d'accords de niveau de service supportant la disponibilité dynamique.

Nous expérimentons enfin notre modèle afin de le valider dans le chapitre 4, puis nous définissons différents axes de recherche possibles ouverts par notre étude.

Notation: Dans la suite du document nous utilisons le formalisme suivant: représente un service fourni et représente un service requis.

9 / 65


2. Etat de l'ArtLes accords de niveau de services dans le contexte des plateformes dynamiques à services font

intervenir plusieurs thèmes de recherche. Tout d'abord, les plateformes dynamiques à services relèvent du domaine des architectures orientées services et plus particulièrement des architectures orientées services dynamiques1. Les acteurs de ce domaine intéragissent par l'intermédiaire de services. Et comme nous nous plaçons dans un contexte ou les acteurs peuvent faire partie d'organisations différentes, leurs interactions doivent respecter des accords, appelés accords de niveau de service2 qui prennent généralement 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 problème qui fait déjà l'objet de nombreuses recherches [Kephart2001], [Kephart2003] et [Sterritt2005]. Pour plus d'information sur ce sujet, le lecteur peut se référer au rapport mené l'an dernier par Clément Escoffier [Escoffier2005].

2.1. Architectures orientées 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 systèmes, ce qui implique de nombreux besoins. L'hétérogénéité devient inévitable et ne doit plus être un frein. Des systèmes historiquement indépendants, acquis grâce à des fusions ou l'acquisition d'autres entreprises, devraient pouvoir être intégrés facilement, et interconnectés sans générer un problème 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 réutiliser facilement plutôt que tout réinventer. En outre, le développement de nouveaux systèmes gagnerait à être plus facile et plus rapide. Une meilleure utilisation des ressources, en évitant les applications monolithiques trop complexes et en privilégiant la modularité et la réutilisation, permettrait également un plus grand retour sur investissement.

Une solution de plus en plus adoptée est l'approche orientée service. Elle est mise en oeuvre sur des architectures orientées service. Ce type d'architecture favorise l'utilisation de patrons architecturaux [Stal2006] pour faciliter l'intégration d'applications.

2.1.1. Définition et concepts

Cette section définit la notion de service comme brique de base des architectures orientées 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 littérature propose un grand nombre de définitions pour le terme service. Retenons qu'un service est une brique logicielle dont les fonctionnalités, les propriétés non fonctionnelles ainsi que les conditions d'utilisation sont définies de manière déclarative par un descripteur de service. Un service peut se suffire à lui-même, toutefois il peut être publié et rendu disponible pour être utilisable par des tiers. Ainsi des services peuvent être utilisés tels quels ou bien être composés pour exécuter une fonctionnalité de plus haut niveau, voire orchestrés pour mener à terme un processus complexe et atteindre un objectif précis.

Grâce aux mécanismes d'encapsulation et de liaison retardée, un service peut-être décrit et utilisé indépendamment de sa réalisation. La liaison proprement dite n'est effectuée qu'au moment de l'exécution, juste avant que le service requis ne soit utilisé. De ce fait on a un couplage extrêment faible entre services et l'interopérabilité de systèmes en environnements hétérogènes, maître mot de l'approche à service, est ainsi facilitée.

Un service est décrit par son descripteur de service, sa spécification en quelque sorte. Le descripteur peut être composé:

● d'informations fonctionnelles:○ la sémantique des opérations○ le comportement du service (pré-condition, post-condition, invariant, exception,

propriétés)○ l'interface du service

● d'informations non-fonctionnelles:○ prix, politique, spécification des mesures de la qualité de service, information de

déploiement, etc.● d'informations additionnelles composées d'informations sur le service, non spécifiées par le

fournisseur du service:○ mesure de qualité de service qui peut être effectuée par un certifieur de service○ note, rapport d'utilisation (par le certifieur ou l'usager).

2.1.1.2. Architecture Orientée Service

Le SOA peut être à la fois une architecture au sens propre du terme et un modèle de programmation. Ce modèle comble le manque de canevas architectural permettant de guider la conception, développer, intégrer et réutiliser des applications plus facilement et plus rapidement. De plus, comme le domaine de métier d'une entreprise est en constante évolution, les systèmes de cette entreprise doivent suivre cette évolution pour répondre à de nouveaux problèmes. Une architecture orientée service permettrait d'assembler des composants et des services pour construire et fournir dynamiquement des solutions à ces problèmes.

La figure 1 illustre une vision simpliste d'une architecture orientée service et des interactions entre les différents acteurs. C'est auprès d'un composant appelé registre de services ou courtier de service que les fournisseurs de service exposent leurs services grâce à leurs descripteurs de service. L'usager interroge le registre pour découvrir et sélectionner le service qui répond à ses exigences. La liaison entre l'usager et le fournisseur d'un service est réalisée une fois que des accords concernant l'utilisation du service sont établis. La figure 2 décrit de manière plus détaillée les interactions entre ces acteurs et les différentes étapes nécessaires à la publication et à l'utilisation d'un service. Pendant la phase de négociation de ces accords, un quatrième acteur peut apparaître: le

11 / 65


certifieur de service, chargé de surveiller le respect de ces accords. Sur ce dernier point la recherche est encore peu développée.

Une architecture orientée service doit donc mettre à disposition des mécanismes de publication, de recherche (aussi appelée courtage) et d’invocation de service. Il existe d'autres mécanismes plus complexes dont nous ne détaillerons pas le fonctionnement, dont la substitution qui permet à un usager de substituer au cours de l'exécution une instance de service par une autre instance de ce même service. L'invocation de service doit suivre un contrat défini entre le demandeur et le fournisseur. La notion de contrat est présentée plus en détail dans la section 2.2.

Enfin retenons que l'architecture orientée services, en tant qu'architecture, est indépendante du domaine d'application. Cependant des instances de cette architecture, spécifiques à un domaine, sont nécessaires pour la construction de systèmes concrets [IST2006].

12 / 65

Figure 1. Acteurs classiques d'une architecture orientée service

Fournisseur de Service

Usager du

Service

Registre de Service

publicationrecherche

interactions


2.1.1.3. Architecture orientée service dynamique

L'architecture orientée service dynamique ajoute l'aspect dynamique à l'architecture orientée service classique. Elle est généralement réalisée sur des plateformes dynamiques à service. Lorsqu'on parle de système dynamique, on parle souvent de la capacité du système à réagir aux changements du contexte [Redmond2002] [Coutaz2005] et d'applications pilotées par des événements. Dans le cadre d'architectures orientées service, un changement de contexte peut se traduire par l'arrivée ou le départ 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 propriétés ayant servi au courtage qui changent dynamiquement au cours de l'éxécution. En pratique le changement dynamique de propriétés concerne les informations non-fonctionnelles et additionnelles contenues dans le descripteur de service.

13 / 65

Figure 2. Patron d'interaction d'une architecture orientée services [Cervantes2004]


Les propriétés d'un service peuvent changer au cours de l'exécution. 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'exécution il modifie cette valeur chaque fois qu'un client arrive ou repart. Cette capacité est particulièrement utile dans le cadre de négociation ou d'adaptation dynamique au contexte.

La disponibilité dynamique est définie comme le fait qu’un service puisse devenir indisponible ou disponible à tout moment pendant qu’un usager qui l’utilise ou qui pourrait l’utiliser est en cours d'exécution. Pratiquement, de nouveaux services peuvent être publiés tandis que d'autres se désenregistrent et ceci pendant l'exécution du système. Un service peut également revenir, c'est-à-dire devenir indisponible puis se réenregistrer et redevenir à nouveau disponible et utilisable; ce qui rend l'architecture dynamique. L'usager du service est alors prévenu des disparitions et réapparitions de certains services par une notification (voir figure 3).

La disponibilité dynamique d'un système présente plusieurs avantages, entre autres des services « à la demande » et la possibilité de déploiement « à chaud ». Le système peut évoluer sans être arrêté et donc sans pénaliser les applications en cours d'exécution, ce qui rend possible la maintenance de systèmes devant s'exécuter 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 systèmes embarqués. Toutefois il faut prendre en compte l'aspect non-fonctionnel de la dynamique dans la phase de développement, ce qui n'est pas trivial. Le développeur doit savoir construire des applications capables de s'arrêter mais aussi de redémarrer.

Le chapitre suivant présente 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

Figure 3. Architecture orientée service dynamique supportant la disparition de service.

Fournisseurdu

Service

Usagerdu

Service

Annuairede Service

retraitnotificationdu retrait

Interaction

http://www.ebay.com/


2.1.2. Plateformes à services dynamiques

Cette section présente une étude des principales plateformes dynamiques à services permettant la réalisation d'applications dont l'architecture suit les paradigmes du SOA et évolue dynamiquement en cours d'exécution. Nous détaillons 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. Basée sur Java, elle permet le téléchargement de code et la sérialisation ce qui en a fait une plateforme distribuée utilisée pour les applications réparties.

Une autre caractéristique 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 découvert. Pour cela, les différents acteurs (usagers et fournisseurs de service) diffusent une annonce de présence. Cette annonce est écoutée par les services de recherche qui répondent aux annonces et se font connaître. Par la suite, ce sont ces services de recherche qui seront utilisés comme registres.

Les services dans Jini peuvent être organisés par groupes (par exemple groupe services d’impression) et un registre peut héberger un groupe de services particulier. Bien que Jini supporte l’existence de registres multiples, il n’offre pas de mécanismes permettant aux registres de déléguer une demande de service. Au lieu de cela, les fournisseurs de services enregistrent leur services dans plusieurs registres.

L'information envoyée au service de recherche comprend :● Une instance d'une classe qui implémente l'interface du service, qui permet d'utiliser les

services proposés. Ceci inclut notamment les déclarations des méthodes pouvant être utilisées.

● De façon optionnelle, des attributs du service peuvent aussi être envoyés.

Descripteur de service: Dans Jini, un service est décrit 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 recherche2 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.

Découverte / recherche: La découverte de services se fait par interrogation du registre qui a répondu à l'annonce. Jini ne propose cependant pas de mécanismes flexibles du côté du registre pour réaliser un filtrage et une sélection plus fine des fournisseurs. Le critère pour déterminer si un service correspond à une demande est que les interfaces du service coïncident avec celles demandées et que les valeurs d'attributs envoyées par le demandeur soient identiques à celles présentes dans la description du service.

Liaison: Elle se fait par le protocole RMI. L'interaction consiste en des appels de méthodes passant par des proxys3.

1 http://www.jini.org/ 2 Appelé lookup service3 Qui sont appelés « stubs » et « skeletons »

15 / 65

http://www.jini.org/


Notifications: Jini fournit des mécanismes de notification asynchrones permettant aux clients d’être informés 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 succès est du au fait que les services Web abordent un domaine où le besoin est très fort, et ce pour les raisons évoquées en introduction de la section 2.1. En effet les services Web permettent à des applications hétérogènes s’exécutant au sein de différentes entreprises de pouvoir interopérer à travers des services offerts par les applications. Or l'utilisation de standards tels que XML facilité l'encapsulation et par conséquent l'interopérabilité [Motahari2006].

Pourtant, bien que la plateforme à services web soit fondée sur les concepts de l’approche à services, l’interaction propre à cette approche n’est pas toujours suivie de façon systématique. Il faut aussi souligner que l’interaction de services dans les services web est réalisée sur une échelle de temps différentes des autres plateformes présentées 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 réalisée dans un langage appelé WSDL1. WSDL est basé sur une grammaire XML et permet de décrire l’interface du service, les types de données employés dans les messages, le protocole de transport employé dans la communication et des informations permettant de localiser le service spécifié. Le registre de services, appelé UDDI2 supporte l’enregistrement de descriptions de services (appelés 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 catégorisent un fournisseur et les pages vertes, plus techniques, décrivent les moyens d’interaction avec un fournisseur: description de services fournis en WSDL ou processus métiers. UDDI est un registre distribué dans lequel l’information est répliquée sur plusieurs sites, en conséquence, un fournisseur de services ne doit publier sa description de service que vers un seul noeud du réseau de registres. Le protocole de communication par défaut 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 schématisée par la figure 4.

1 Web Services Description Language2 The Universal Description, Discovery and Integration3 Simple Object Access Protocol

16 / 65


La disponibilité dynamique n'est pas intégrée directement à la plateforme des services Web. Comme UDDI n'est pour le moment que très peu utilisé et que sa partie événementielle n'est que peu développée, la découverte de service n'est pas dynamique et le système de notifications n'est que très rarement mis en pratique par les développeurs de services Web. Donc si un service devient indisponible, la réponse à la requête sera une erreur 404 Not Found.

Les services Web sont également utilisés conjointement avec SOAP pour la liaison de composants faiblement couplés dans SCA1 (Service Component Architecture). SCA est une solution émergeante développée principalement par IBM, BEA et Oracle pour définir un modèle de composant pour les architectures orientées 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 données complexes● message : description d’un message. La description contient le nom du message et zéro ou

plus parties qui décrivent les paramètres dans le cas d'une requête, ou les valeurs de retour dans le cas d'une réponse.

● portType : description d’une méthode formée par un groupe de messages, par exemple une méthode combinant requête et réponse.

● binding : le protocole de transmission des messages● service : emplacement du service, généralement une URL.

1 http://www-128.ibm.com/developerworks/library/specification/ws-sca/

17 / 65

Figure 4. Schéma d'interaction de services Web [Donsez2001]

http://www-128.ibm.com/developerworks/library/specification/ws-sca/


Registre: UDDI est un registre distribué dans lequel l’information est répliquée sur plusieurs sites. Un fournisseur de services n'a par conséquent à publier sa description de service que vers un seul noeud du réseau de registres.

L'annuaire UDDI est consultable de différentes manières. Chaque type de pages blanches, jaunes ou vertes donnent des informations de nature différentes. Respectivement des informations liées au fournisseur du service (généralement une entreprise), une catégorisation des entreprises et des informations techniques plus précises comme les services fournis et les processus métiers associés.

Découverte / recherche: La recherche se fait donc par interrogation du registre qui permet de trouver le service désiré et d'obtenir son URL.

Liaison: L'usager peut grâce au protocole SOAP interroger le service Web désiré une fois qu'il a récupéré son descripteur.

Notification: UDDI supporte l’enregistrement auprès 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 réseau transparente (voir figure 5) pour le SOHO2. Pouvoir changer, brancher ou débrancher des équipements à volonté confère à un tel réseau son caractère dynamique et éphémère. Cet aspect dynamique oblige ce type de réseau à viser le zéro-administration. Pour cela, les noeuds (équipements) d'un réseau UPnP sont auto-configurables et auto-descriptifs. Basé sur IP et autres standards d'Internet (TCP, UDP, HTTP et XML), UPnP est indépendant de la technologie utilisée, que ce soit le canal de communication (Ethernet, WiFi, etc.), le système d'exploitation, ou encore le langage de programmation utilisé pour l'implémentation.

Les noeuds sont soit des équipements, soit des points de contrôle. Par exemple, un équipement pourrait être un appareil d'éclairage et un point de contrôle serait une télécommande ou un assistant personnel (PDA). Les équipements fournissent des services utilisables par les points de contrôle et notifient ces derniers lorsqu'ils changent d'état. Il n'y a donc pas de registre en tant qu'entité unique. La découverte est basée sur le protocole SSDP (Simple Service Discovery Protocol). Pour découvrir un service, un usager, c'est-à-dire un point de contrôle, recherche les équipements disponibles sur le réseau 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 contrôle obtiennent des adresses IP pour participer au réseau.● Un point de contrôle recherche les équipements disponibles.● Un point de contrôle examine les aptitudes d’un équipement.● En parallèle:○ Un point de contrôle invoque une action d’un équipement.○ Un point de contrôle est notifié des changements d’état d’un équipement.○ Un navigateur Web peut examiner un équipement via une interface HTML.

1 Universal Plug and Play2 Small Office Home Office

18 / 65


Descripteur de service: Il contient des informations concernant le fournisseur de service, des icones utilisables par les points de contrôle 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 précis détaillant les variables d'états de l'équipement, les actions disponibles ainsi que leurs paramètres.

Registre: Il est distribué et repose sur le protocole de découverte SSDP1.Découverte / recherche: La découverte d'équipements et de services se fait grâce à un système

de diffusion de messages. Les messages de découverte contiennent quelques renseignements sur l'équipement ou un de ses services, par exemple son type, son identifiant ou un pointeur vers des informations plus détaillées.

Liaison: Une fois que l'équipement a été découvert, le point de contrôle peut agir dessus. L'appel se fait par HTTP / SOAP.

Notifications: un point de contrôle peut s'abonner aux équipements de la part desquels il souhaite recevoir des événements sur les variables d'état.

2.1.2.4. Devices Profile for Web Services

Bien que UPnP ait l'avantage d'être indépendant des plateformes d'exécution grâce à sa construction sur des standards d'internet (IP, TCP, UDP, HTTP, SOAP et XML), on peut lui reprocher d'utiliser des protocoles spécifiques pour la découverte de devices et les notifications ainsi qu'un langage spécifique 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 spécifiaction des services Web qui permet à des équipements3 d'utiliser ce mécanisme standard de l'industrie pour communiquer avec d'autres équipements, ordinateurs, et services Web sur Internet.

La spécification DPWS définit deux types de services: les services d'hébergement (hosting services) et les services hébergés (hosted services). Un service d'hébergement est lié à un équipement et joue un rôle primordial dans la phase de découverte, tandis qu'un service hébergé

1 Simple Service Discovery Protocol2 DPWS3 En anglais, « device »

19 / 65

figure 5. Exemple de réseau UPnP [Donsez2005]

IEEE1394GatewayFireWire-UPnP

MediaCenter IGD

WWW

GatewayX10-UPnP


dépend de l'équipement qui l'héberge quant à la phase de découverte. En plus de ces services, DPWS intègre un ensemble de services: les services de découverte qui permettent de diffuser une annonce et de découvrir d'autres équipements, les services d'échange de méta-données qui fournissent un accès dynamique aux services hébergés par un équipement et à ses méta-données, et les services de publicaion / souscription qui permettent à des équipements de s'abonner aux messages produits par un service en particulier.

La figure 6 présente la pile de protocoles utilisés pour DPWS. En plus des protocoles classiques utilisés dans les services Web que nous ne détaillerons pas ici (WSDL, SOAP, WS-Adressing, WS-MetadataExchange, WS-Policy et WS-Security), DPWS ajoute des protocoles pour la découverte et les notifications. WS-Discovery, protocole multicast pour la découverte plug-and-play et ad-hoc d'équipements connectés au réseau, permet de chercher, localiser des équipements puis d'exposer les services fournis par ces équipements. WS-Eventing, quant à lui, définit un protocole pour la prise en charge des événements de type publish-subscribe, ce qui permet à des équipements d'être informés des changements au niveau d'autres devices.

WSD1 est l'implémentation par Microsoft de la spécification DPWS qui se trouve au coeur de Vista, la prochaine version du système d'exploitation Microsoft Windows, et qui permet à des équipements d'intéragir avec Windows sur un réseau IP.

2.1.2.5. La plateforme OSGi

OSGi [OSGi] est un consortium qui a pour but de spécificier, créer et promouvoir une plateforme dynamique à service ouverte / libre. Cette plateforme a pour objectif la livraison et l'administration de services dans des réseaux résidentiels ou autres types d’environnements restreints (automobile, téléphonie mobile, réseaux de capteurs, ...).

La plateforme OSGi offre une surcouche à la machine virtuelle Java. Centralisée / non-distribuée, elle sert d'infrastructure au déploiement de fournisseurs ou demandeurs de service appelés bundles. Dans la pratique, un bundle est une unité de déploiement qui correspond à un fichier JAR2

1 Web Services for Devices: http://msdn.microsoft.com/windowsvista/default.aspx?pull=/library/en-us/dnlong/html/WebSerDev.asp

2 JAR: Java ARchive

20 / 65

Figure 6. Pile de protocoles pour DPWS [Jammes2005a]

http://msdn.microsoft.com/windowsvista/default.aspx?pull=/library/en-us/dnlong/html/WebSerDev.asp

http://msdn.microsoft.com/windowsvista/default.aspx?pull=/library/en-us/dnlong/html/WebSerDev.asp


contenant du code et des ressources. La plateforme OSGi supporte la disponibilité dynamique. En effet elle fournit des mécanismes d’administration permettant de réaliser l’installation, activation, désactivation, mise à jour et désinstallation des bundles de façon continue. Lorsqu'un bundle est actif, il peut publier ou découvrir des services et se lier avec d’autres bundles à travers un registre de services fourni par la plateforme. Notons qu'un bundle peut à la fois jouer le rôle de fournisseur et d'utilisateur de service, les dépendances de services sont alors décrites dans le descripteur de service.

OSGi présente l'avantage de fournir un environnement générique pour le déploiement de services. En effet, l'interopérabilité est possible avec n'importe quel autre protocole grâce à l'approche à services (il existe déjà 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'implémentation), les services requis, sa version, etc.

Registre: Il est centralisé et intégré à la plateforme.Découverte / recherche: La recherche de services se fait au moyen d’une requête LDAP1 simple

qui peut limiter la recherche à l’ensemble des services qui ont des propriétés spécifiques.Liaison: Comme la plateforme est centralisée, l'usager d'un service et le fournisseur sont

colocalisés sur la même machine virtuelle Java. Ils interagissent par le biais d'appels de méthodes Java.

Notifications: La plateforme communique avec ses bundles via un mécanisme événementiel.

1 Lightweight Directory Access Protocol

21 / 65


2.2. Contrats

Dans le contexte des architectures orientées service, l'usager d'un service doit au moins connaître la syntaxe des opérations qu'il souhaite utiliser. Il utilise pour cela un contrat de service qui dans sa version la plus simple décrit 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 données supplémentaires rendent le contrat négociable 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 manière dont il est actuellement représenté dans les plateformes dynamiques à service.

2.2.1. Définitions et concepts

Cette première partie donne une définition générale du contrat. La notion de contrat ainsi que les concepts qui lui sont associés, dont la négociation de contrat, sont ensuite présentés dans le cadre des architectures orientées service.

2.2.1.1. Definition générale

Dans le langage courant, un contrat est un accord de volonté passé entre au moins deux parties. La signature des parties signifie qu’il y a accord sur les termes du contrat. Un contrat peut aussi être conclu oralement.

Plus précisément, 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 orientées service

Le monde du SOA étant très 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 génie logiciel n'est pas récente ni propre à l'approche à service bien qu'elle y soit tout particulièrement adaptée. Son apparition remonte à l'approche à composant. L'approche à composant préconise l'encapsulation des fonctionnalités dans le composant afin de les dissimuler derrière un patron2 de façade, qui est en pratique réalisé par une interface. Les interactions entre composants se font donc par l'intermédiaire du contrat pour respecter le principe de boîte noire. Ceci signifie que les appels doivent suivre la syntaxe définie par le contrat. Dans une architecture orientée service, un contrat est une entité liant le fournisseur et l'usager d'un service (voir figure 7).

1 business-to-business2 En anglais, « pattern »

22 / 65


En pratique un contrat est plus souvent bi-parties mais il existe des cas où plusieurs acteurs sont liés par un même contrat (figure 8).

Au sein de l'équipe ADELE, le groupe de travail sur les services a élaboré la définition 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 négocié lors de la phase de découverte / requête de service. Le contrat est basé sur un modèle de contrat contenu dans la description du service. Nous considérons que chaque liaison entre demandeur et fournisseur est une instance personnalisée du modèle de contrat fourni par le fournisseur.

On dit d'une application à service qu'elle est résolue lorsque ses contrats sont signés. Tant qu'ils ne sont pas signés, c'est-à-dire non acceptés, l'application est dans un état non-résolue.

Une classification des contrats a été établie par Beugnard et al [Beugnard1999]. Elle distingue quatre niveaux de contrat allant d'un niveau où la négociation est impossible à un niveau où la négociation est possible dynamiquement.

Le niveau syntaxique se résume à ce qu'on peut trouver en règle générale dans les interfaces des langages de programmation classiques et dans les langages de définition d'interfaces (IDLs). C'est-à-dire les opérations disponibles, les paramètres d'entrées et de sorties requis et éventuellement les exceptions qui pourraient être levées durant ces opérations.

A son état le plus basique un contrat de niveau comportemental spécifie le comportement de chaque opération en utilisant des assertions booléennes appelées pre- ou post-conditions et invariants. Dans [Meyer1992] la conception orientée contrat1 implémente ce niveau de contrat grâce

1 En anglais, « Design by Contract »

23 / 65

Figure 7. La liaison entre un usager et un fournisseur suit un contrat bi-parties

Contrat

clause 1...

clause n

Usager Fournisseur

Figure 8. Cas d'un contrat multi-parties

AcheteurB2B

ProducteurAchat benzene

Assureur

Transporteur

Gouvernement

FinancePaiement avec credit

Expédition avec delaide livraisonAssurrance sur le transport

Autorisation gouvernementalpour un transport sécurisé


au langage Eiffel. Par la suite, Java ou encore UML1 ont adopté cette approche à travers les assertions Java et OCL2.

Un contrat de niveau synchronisation spécifie le comportement global d'objets en terme de synchronisations entre appels de méthodes. Une solution serait d'attacher aux objets des politiques de synchronisation telles qu'une stratégie à 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 réseaux (elle pourrait par exemple porter sur un temps de réponse maximal). Par sa nature quantificatrice ce type de contrat a l'avantage de pouvoir être négocié en jouant sur les valeurs proposées. Ce niveau de contrat est abordé plus en détail dans le chapitre suivant qui traite des accords de niveau de service.

2.2.1.3. Négociation de contrat

Il arrive que pour un contrat donné, certaines clauses peuvent être négociées. Les parties entament alors une phase de négociation 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 négociables. Ils sont généralement proposés par le fournisseur et l'usager n'a que deux possibilités: soit le contrat répond à 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 sélection. Une réelle négociation impliquerait par exemple une nouvelle proposition de la part du fournisseur suite à une requête du demandeur de service.

Il existe cependant quelques variantes visant à améliorer et raffiner cette phase de sélection. Un système 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 systèmes de sélection qui utilisent des stratégies de scoring, mais ce point est abordé plus en détail dans la partie 'négociation' de la section 3.1.

2.2.2. Le contrat sur les différentes plateformes à services

Actuellement, le contrat est en règle générale proposé par le fournisseur et représenté par une simple interface qui décrit les opérations 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 négociation est souvent réduite à une acceptation ou à un refus du contrat, ce qui correspond au niveau syntaxique de [Beugnard1999]. Dans cette partie nous étudions la représentation du contrat pour les différentes plateformes à service étudiées dans la section 2.1.2.

2.2.2.1. Jini

Dans une architecture Jini le contrat est représenté par l'interface Java du service et les propriétés associées à ce service. Ces propriétés sont en fait un ensemble d’attributs représenté comme une

1 Unified Modeling Language, www.uml.org/2 Object Constraint Language, intégré à UML 2.0

24 / 65

http://www.uml.org/


instance d’une 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 auprès du registre, un usager passe en paramètre de la méthode 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 résultats parmi lequels le demandeur devra faire un choix [Ayed2003].

La phase de négociation se résume donc à une recherche suivie d'une sélection. Le fournisseur n'intervient pas dans la négociation, il ne fait qu'exposer un ensemble de propriétés attachée à 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 qu’une entreprise peut enregistrer au niveau de UDDI sont des informations sur son nom, des contacts, des codes industriels, des classifications de produits, des URLs, l’ensemble des services offerts ainsi que des informations sur leurs interfaces techniques et leurs fonctionnements. La négociation se limite alors à une interrogation du registre qui renvoie un ensemble de réponses 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 méta-données au format XML décrivant l'équipement et ses services. Les équipements et leurs services sont découverts. Un point de contrôle peut ensuite sélectionner le service qu'il souhaite utiliser. Il est alors considéré comme ayant accepté le contrat dès que l'interaction avec l'équipement débute. L'équipement est ensuite utilisé en respectant la syntaxe définie 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 sélectionnés d'après ces variables.

2.2.2.4. OSGi

Dans la plateforme OSGi, le contrat correspond au descripteur de service. Il est modélisé par l'interface du service qui contient les informations fonctionnelles et par les propriétés qui représentent la partie non fonctionnelle du contrat. Il s'agit donc d'un contrat de niveau à la fois syntaxique et qualité de service. Le contrat intègre également d'autres informations non fonctionnelles telles que les dépendances de services, etc.

Un service est sélectionné par une interrogation du registre qui utilise un filtre LDAP pour permettre une sélection plus fine comme décrit dans la section 2.2.1.3.

25 / 65


2.3. Accords de niveau de service

Le contexte des architectures orientées service fait intervenir des acteurs appartenant souvent à des organisations différentes. Pour garantir le bon fonctionnement de ces systèmes et une cohésion entre ses différents acteurs, des accords portant sur les services fournis doivent être conclus entre les différentes parties.

Pendant de nombreuses années les accords de niveau de service1 étaient présentés dans un format papier rédigé dans un langage naturel. Les dernières recherches dans ce domaine poussent à les intégrer aux applications en les rédigeant dans un format interprétable par une machine.

Les accords de niveau de service ont toujours été très présents dans le domaine des réseaux où il y a un réel besoin d'accords entre les différents opérateurs mais ils sont maintenant en essor dans le monde des architectures orientées services. Les termes de l'accord portent généralement sur la garantie du service fourni, sur son tarif et sur les pénalités en cas de non respect de l'accord. Par exemple dans le cas du réseau la garantie peut concerner les performances comme le débit, le temps de réponse ou la gigue.

2.3.1. Définition et concepts

Voici une définition des accords de niveau de service construite à partir de nombreuses définitions trouvées dans la littérature:

Un accord de niveau de service est un contrat souscrit entre le fournisseur d'un service et un usager de ce service définissant les engagements de ces deux parties. Ces engagements, contenant le niveau de service fourni ainsi que les pénalités encourrues en cas de manquement de part et d'autre, sont définis par des critères objectifs de qualité de service pouvant être évalués 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 différentes: du basique contenant des standards de disponibilité et de performance s'appliquant à une large gamme d'applications, aux accords plus précis, focalisés, qui varient d'un client à l'autre au sein de la même entreprise. Des accords de niveau de service trop généraux ne représentent qu'une faible valeur ajoutée, c'est pourquoi on rencontre principalement des solutions ad-hoc plus précises, adaptées à chaque problème.

D'après [Miller1987] et [Consulting2002] un accord de niveau de service devrait être construit en suivant les 9 étapes suivantes:

● Définir les parties engagées par l'accord.● Décrire le service fourni.● Spécifier le volume de demande pour le service.● Définir le temps d'utilisation du service. Par exemple: « 90% du temps pendant 2 heures »

ou, pour une tâche programmée, « si le traitement débute à 8h alors le résultat sera fourni à 20h ».

● Spécifier la disponibilité du service. Généralement une fenêtre de temps.

1 En anglais, Service Level Agreements, SLAs2 En angalis, QoS

26 / 65


● Définir 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 pénalité. Une telle mesure est indispensable mais elle implique la mise en place d'un système de facturation.

● Décrire les procédures de mesure à utiliser. Les mesures peuvent être stockées pour être réutiliser comme preuves en cas de litige entre les parties, ou bien servir à des outils statistiques ou prévisionnels.

● Fixer une date pour la renégociation de l'accord. Cette date est en fait une date de validité de l'accord. Comme les politiques des différents acteurs peuvent changer (prix du service, volume autorisé, etc.) il est nécessaire d'avoir dans ces cas-là une phase de renégociation.

Ces étapes permettent de structurer un accord de niveau de service entre un fournisseur et un usager. Elles soulèvent toutefois quelques problèmes, et pour mieux les comprendre, introduisons de nouveaux concepts.

On trouve dans la littérature (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 surveillance3, facturation et gestion des pénalités 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 déléguée à 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 constituée d'un seul ou de plusieurs auditeurs. Chaque auditeur est chargé de prendre des mesures pour vérifier le respect des accords dont la surveillance lui a été confiée. En cas de non respect il doit appliquer les mesures décrites par les politiques de pénalité.

Concernant l'instrumentation, le nombre de critères de qualité de service qui peuvent être définis pour un service est potentiellement très grand. Le moindre paramètre peut être défini de différentes manières. Par exemple le temps de réponse peut-être observé valeur par valeur, en moyenne, du point de vue du client ou du serveur d'application hébergeant le service, etc. Il est donc nécessaire de définir une métrique propre à chaque paramètre.

Cette tierce partie joue donc un rôle primordial dans le SLM et devient un acteur à part entière qui pourrait être nommé certifieur de service ou auditeur tiers (voir figure 9). Toutefois un certain coût est associé à l'instrumentation et il est nécessaire de prendre ce coût en compte lors des mesures pour ne pas fausser les résultats et pénaliser une partie à tort.

Les accords de niveau de service ont été le sujet de recherches intenses pendant plusieurs années et ont maintenant atteint un certain degré de maturité. Toutefois le problème de l'établissement d'un canevas générique pour le SLM dans un environnement multi-organisations n'est toujours pas résolu. Les sections suivantes présentent plusieurs travaux qui ont pour but l'établissement d'un tel canevas.

1 Gestion du niveau de service2 Objectifs de niveau de service3 En anglais, monitoring

27 / 65


2.3.2. Travaux académiques

Cette partie étudie les travaux académiques menés dans le domaine des accords de niveau de service dans le contexte des architectures orientées service: ContractLog, un canevas1 pour la prise en charge des accords de niveau de service construit sur une approche à base de règles appelée « Rule-based SLA », et d'autre part SLAng, un langage de définition des accords de niveau de service.

2.3.2.1. RBSLA: Rule-based Service Level Agreement (ContractLog)

De récentes recherches menées par Adrian Paschke2 ont conduit à une approche du SLA basée sur des règles, Rule-based SLA (RBSLA) [Paschke2005] et à une implémentation de ContractLog [Paschke2005a], un canevas pour la représentation et l'application d'accords de niveau de service utilisant l'approche RBSLA.

Ces travaux proposent une représentation des accords de niveau de service à partir de règles en utilisant des concepts de représentation de connaissances sophistiqués, à base de logique. Ils représentent une alternative aux contrats écrits en langage naturel, ou dans des langages tels que Java ou C++ et dont les implémentations sont disséminées dans le code applicatif. En combinant

1 Framework en anglais2 Chercheur à l'université technique de Munich (Technical University of Munich, TUM). Pour plus d'informations, se

référer à http://ibis.in.tum.de/staff/paschke/index.htm

28 / 65

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

Accord de niveau de service Fournisseur

duService

Usagerdu

Service

Annuairede Service

publication

recherche

interaction

Certifieurde service

http://ibis.in.tum.de/staff/paschke/index.htm


des formalismes logiques dans le canevas ContractLog, il est possible de décrire des spécifications de contrat à base de règles formelles qui peuvent être surveillées et exécutées de manière automatique.

La figure 10 illustre l'implémentation à trois niveaux qui a été réalisée: le canevas ContractLog, le langage déclaratif RBSLA et un outil de gestion de niveau de service basé sur des règles, RBSLM1. ContractLog est implémenté sur le moteur de règles 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 règles issues du domaine de la programmation logique. Nous ne nous étendrons pas sur le fonctionnement complexe de ContractLog qui intègre des formalismes logiques tels que des règles ECA (Evénement, Condition, Action), l'Event Calculus, la logique déontique, la logique annulable4 et la logique de description. Mais il est important de retenir que les accords de niveau de service sont décrits par des règles ECA actives, c'est-à-dire qu'elles sont exécutées toutes les périodes T et sont du type eca(T,E,C,A).

Par exemple, chaque minute le système vérifie si un événement « service indisponible » a été reçu. Dans ce cas, si aucune maintenance n'est prévue, un message d'avertissement est envoyé à un administrateur. La règle s'écrit alors de la manière suivante:eca(everyMinute, serviceUnavailable, notScheduledMaintanance, sendNotification)

Les principaux avantages de cette approche logique, par contraste avec les approches traditionnelles par programmation, sont sa flexibilité élevée, son extensibilité dynamique et un fort potentiel pour ce qui concerne l'automatisation de tâches telles que la détection de violation de contrat, le contrôle d'autorisation (par la logique déontique), la détection de conflit, la facturation de service et la création de rapport.

1 Rule Based Service Level Management2 http://sourceforge.net/projects/mandarax 3 http://www.ruleml.org/ 4 En anglais, « deontic logic » et « defeasible logic »

29 / 65

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

http://www.ruleml.org/

http://sourceforge.net/projects/mandarax


2.3.2.2. SLAng

SLAng [Lamanna2003] est un langage de définition d'accords de niveau de service. Un modèle pour la livraison de service inter-organisations à la fois, au niveau de l'application, de l'intergiciel, du réseau et du stockage constitue la base de SLAng. Les objectifs de SLAng sont multiples. Ce langage tente de fournir un format pour la négociation de propriétés de qualité de service, les moyens de capturer ces propriétés de manière non ambigüe et de les intégrer dans des accords, ainsi qu'un langage interprétable qui permet des traitements automatiques.

Dans son approche, SLAng considère deux catégories d'accords de niveau de service: les SLAs horizontaux, passés entre parties de même niveau qui fournissent un service du même type, et les SLAs verticaux passés entre infrastructures de niveaux différents (par exemple, entre un conteneur et un composant, ou bien entre un conteneur et la couche réseau).

Un des avantages de SLAng est l'expression des accords de niveau de service dans un langage XML, ce qui offre une compatibilité élevée avec les technologies Internet. Toutefois SLAng se propose comme un complément aux services Web et reste donc très lié à cette plateforme. De plus SLAng n'est pas un langage extensible et ce manque de flexibilité représente un inconvénient non négligeable.

2.3.3. Un standard émergeant: Web Service Level Agreements

Les services Web, de plus en plus en répandus, 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 menées par IBM1 ont abouti au langage Web Service Level Agreements2 (WSLA) d'une part et à l'implémentation 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 spécification WSLA [Ludwig2003] intègre les différents concepts liés aux accords de niveau de service (voir figure 11). Un accord de type WSLA est divisé en 3 parties:

● les parties concernées par l'accord, c'est-à-dire les parties contractantes ainsi que les parties tierces;

● la description du service. Elle contient les opérations fournies par le service, le protocole de transmission des messages, les paramètres d'accord de niveau de service, i.e les critères de qualité de service ainsi que les métriques associées à ces critères (les métriques intègrent les fonctions et algorithmes nécessaires aux mesures);

● et les obligations qui concernent les garanties données par le fournisseur et les contraintes qui lui sont imposées. De plus cette partie spécifie une date de validité de l'accord, des formules permettant de détecter une violation de contrat et les actions à entreprendre en cas de violation., ce qui correspond au principe de pénalité.

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

30 / 65

http://www.w3.org/TR/wsdl

http://www.ibm.com/


Il faut également savoir que les accords de niveau de service WSLA sont rédigés par le fournisseur de service avec l'accord de l'usager, avant la phase de déploiement. Ces accords sont par la suite utilisés lors de l'exécution par un système 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 répondre aux besoins suivants [Keller2002]:

● pouvoir s'adapter à une large gamme d'accords de niveau de service,● fournir des mécanismes automatiques de négociation,● chaque partie impliquée 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 délai de réponse n'a pas besoin de connaître les garanties de bande passante),

● déléguer la surveillance et l'instrumentation à des parties tierces.La figure 12 illustre le fonctionnement de ce canevas et le rôle du SLA Compliance Monitor qui

en est la partie orientée SLM. Une fois que les accords de niveau de service ont été conclus et mis sous la forme WSLA, ils sont déployés, c'est-à-dire distribués entièrement ou partiellement aux différentes 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 détermine qu'une obligation n'a pas été respectée, des actions prévues dans les accords doivent être entreprises. L'entité métier (Business

1 WSTK (Web Services ToolKit): http://www.alphaworks.ibm.com/tech/webservicestoolkit

31 / 65

Figure 11. Les principaux concepts de WSLA [Ludwig2003]

http://www.alphaworks.ibm.com/tech/webservicestoolkit


Entity) contient des informations privées 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.

32 / 65

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


2.4. Synthèse

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 répandu, l'aspect dynamique n'est pas assez mis en valeur. D'autres technologies émergeantes telles que UPnP, DPWS et OSGi ou même Jini proposent des plateformes qui ciblent plus cet aspect dynamique.

Un récapitulatif des caractéristiques de ces plateformes est fourni par le tableau 1.Actuellement les contrats de service tels qu'ils sont décrits dans la section 2.2.1.2 dépassent

rarement le niveau syntaxique et sont essentiellement bi-parties. De plus, la phase de négociation 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 détaillée des services. Toutefois, la prise en compte d'accords de niveau de service nécessite la mise en place d'infrastructures capables de les supporter. Même si la recherche a atteint un certain degré de maturité dans ce domaine, il y a encore beaucoup à faire.

Un modèle d'accords de niveau de service doit être générique mais pour être réellement effectif, il doit être extrêmement précis par rapport au domaine d'application et donc être extensible. C'est pour cela que nous observons une vaste diversité de systèmes 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 dernière n'est plus tellement utilisée. Naturellement la plupart des travaux portent sur les services Web. SLAng n'est pas encore très abouti alors que Web Services Level Agreements poussé par IBM est déjà utilisé.

Nous pouvons également citer deux spécifications récentes 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'à présent, les politiques ont été définies pour la sécurité (WS-Security-Policy), pour l'envoi fiable de messages (WS-Reliable-Messaging) et pour le routage des résultats (WS-Addressing). Concernant les accords de niveau de service, rien ne semble avoir été défini sur la base de WS-Policy. WS-Agreement est une autre spécification qui s'intéresse plus particulièrement à la définition d'objectifs de niveau de service (SLOs) et à l'ontologie. WS-Agreement spécifie un langage basé sur XML pour la création de contrats, d'accords et de garanties à partir d'offres entre un fournisseur de service et un client.

Il existe toutefois des travaux académiques 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 néanmoins l'utilisation de règles ECA (pour décrire les décisions à 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 préoccupation principale lors des recherches menées sur les accords de niveau de service. De même, peu de travaux compatibles avec les plateformes dynamiques à services ont été effectués 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

http://rio.jini.org/


Jini UPnP / DPWS Services Web OSGi

Architecture Distribuée / dynamique Distribuée / dynamique Distribuée / aspect dynamique peu développé

Centralisée (même Machine Virtuelle Java) / dynamique

Registre Distribué (services de recherche)

Distribué Registres UDDI multiples mais centralisés car répliqués.NB: peu utilisé

Unique et centralisé. Fourni par le framework OSGi

Descripteur de service /

Modélisation du contrat

Interface Java + propriétés

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

Descripteur en WSDL (basé sur une grammaire XML)ou WSLA pour les accords de niveau de service

Interface ou classe Java + propriétés

Niveau de contrat

Syntaxique et un peu de qualité de service.

Syntaxique Syntaxique /WSLA est bi-parties

Syntaxique et qualité de service.

Découverte / recherche

Le type du service (interface) et les valeurs des attributs sont passés en paramètres de la recherche

Protocole de découverte basé sur IP Multicast (SSDP). Filtrage très limité. (WS-Discovery pour DPWS)

Interrogation d'un annuaire UDDI

Une recherche dans le registre à partir d'un filtre LDAP retourne une référence vers l'objet du service

Négociation Non, recherche puis simple sélection

Non, découverte du service

Non Non, simple sélection par filtrage

Filtrage / sélection

Simple. Typage fort sur le nom de l'interface et la signature de ces méthodes.Filtre sur l'égalité des propriétés. (notion de templates)

Limitée. Simple recherche de service. Les valeurs des variables d'état ne peuvent pas être utilisées pour la recherche

Utilisation des pages blanches, jaunes et vertes d'UDDI

Filtre LDAP « complexe » avec relations d'ordre pour les valeurs des propriétés

Liaison Distant / RMI Messages dans des enveloppes SOAP

Messages dans des enveloppes SOAP

Appels locaux de méthodes Java (par références)

Notifications Arrivée, départ et modification

Arrivée et départ (SSDP), changement de valeur des variables d’état (WS-Eventing pour DPWS)

Arrivée, départ et modification

Arrivée, départ et modification

Portabilité / langages supportés

Java Tous Tous Java avec possibilité de passerelles vers d'autres plateformes

SLA Rio Rien WSLA Rien

Tableau 1. Récapitulatif des caractéristiques 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 récents. Les domaines abordés soulèvent donc de nombreux problèmes 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'intermédiare du contrat de service. Notre travail porte essentiellement sur l'impact de la dynamique sur les accords de niveau de service.

Après avoir présenté les architectures orientées service dans le domaine d'équipements connectés à un réseau, contexte dans lequel nous plaçons notre étude, différents scénarios sont étudiés afin de mettre en évidence les principaux problèmes liés à la prise en compte de la dynamique dans les accords de niveau de service, et différents cas de négociation de contrats de service.

Les sections 3.4 et 3.5 présentent notre contribution. D'une part, à une échelle macroscopique, un modèle général d'architecture dynamique orientée service prenant en charge les accords de niveau de service. Ce modèle intégre un mécanisme de gestion des liaisons que nous représentons par des contrats. D'autre part, à une échelle plus réduite, nous proposons un modèle de contrat de service intégrant des concepts liés à la dynamique et permettant la mise en oeuvre des mécanismes du premier modèle.

3.1. Identification des problèmes soulevés

Les problèmes liés aux domaines des accords de niveau de service et des plateformes dynamiques à services sont nombreux et certains font déjà l'objet de recherches actives. Ils ne peuvent donc être tous traités. Nous avons donc choisi au final de focaliser notre travail sur l'aspect dynamique.

3.1.1. Modélisation de l'accord et sémantique

L'accord de niveau de service entre l'usager et le fournisseur d'un service correspond généralement au contrat liant les deux parties. Souvent cet accord est représenté par un fichier au format texte écrit dans un langage spécifique. On pourrait également modéliser le contrat par une approche orientée objet mais le problème resterait le même: les parties qui souscrivent au contrat doivent être d'accord sur la syntaxe et la sémantique utilisées pour pouvoir interpréter le contrat de la même manière et éviter toute ambiguïté ou incompréhension.

Cette contrainte est due à un avantage des architectures orientées service, le faible couplage. L'encapsulation permet aux services de s'éxécuter en environnements hétérogènes mais il subsiste quand même 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 sémantique est très liée à un domaine de métier, est aussi un problème spécifique. Nous ne nous poserons pas ce problème et nous supposerons que les différents acteurs sont en accord sur la sémantique des services.

35 / 65


3.1.2. Contractualisation du comportement d'un service

En cas de rupture de contrat, ou juste de départ d'un service, un utilisateur a plusieurs possibilités. Il peut attendre le retour du service, le remplacer par un autre ou bien arrêter son travail et considérer le départ comme une rupture de contrat. A l'instar du type de pénalité à appliquer qui doit faire partie des accords de niveau de service, le comportement à adopter dans les cas de figure pré-cités devrait également y être décrit.

3.1.3. Composition de services et sous-contractants

La composition de service, aussi appelée chainage, schématisée 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.

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 pénalités doivent-elles être appliquées à C et à B? Uniquement à C? Le bon sens voudrait que B et C soient tous deux pénalisés. B étant responsable de C, c'est à lui de prendre les mesures nécessaires en spécifiant par exemple dans SLA-2 une pénalité suffisante pour amortir celle décrite 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 même. 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. Négociation et sélection du contrat

Généralement la négociation d'un contrat de service se résume à une recherche et à une souscription si le service présente les propriétés voulues. Si la recherche n'aboutit à aucun résultat satisfaisant alors la négociation s'arrête là. Il n'y a pas vraiment de négociation au sens propre où les parties échangent pour se mettre d'accord sur un contrat.

Cependant certains processus sont plus évolués avec la mise en place de stratégies de sélection, par un système de points et de coefficients par exemple1 ou bien par d'autres algorithmes de

1 En anglais, scoring

36 / 65

Figure 13. Composition de services et sous-contractant

SLA-1Service A Service B Service C

SLA-2


sélection. Le scoring [Sierra1997] consiste à attribuer à chaque propriété 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 intéressant est retenu. Mais encore une fois il ne s'agit que d'une sélection plus fine et plus complexe.

Un vrai processus de négociation impliquerait des échanges entre les parties. Le fournisseur de service propose un contrat et l'utilisateur peut en négocier certains points s'ils ne répondent pas à ses besoins. Par rapport à ses objectifs, le fournisseur peut alors décider de modifier ou non les termes de son contrat, ce qui techniquement suppose possible le changement dynamique de propriétés. Des publications sur l'informatique autonomique [Kephart2003] traitent déjà des notions d'objectifs et de plans d'actions. Nous pouvons donc imaginer déléguer le problème de la négociation à un système autonomique.

3.1.5. Renégociation de contrat

Lorsque les services sont déployés sur une plateforme dynamique, il est parfois nécessaire de renégocier un contrat. Une renégociation suppose que les propriétés du contrat peuvent changer dynamiquement ou bien qu'un autre contrat peut être proposé à l'usager par le fournisseur de service.

Une renégociation peut par exemple être nécessaire à 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 à renégocier le contrat. Ou bien lorsque les ressources viennent à manquer, un fournisseur ne peut plus dispenser son service de la même manière.

La renégociation d'un contrat ne doit pas non plus perturber le fonctionnement du reste du système. De la même manière que pour la négociation, elle pourrait être dirigée par un système 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 même être substitués. D'après les paradigmes des architectures orientées service dynamiques, l'usager d'un service devrait pouvoir reprendre l'utilisation du service à son retour où il l'avait arrêté. Or la continuité de service implique plusieurs problèmes 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 départ du service, sachant qu'une telle solution est très complexe à mettre en oeuvre dans un environnement dynamique.

Ce type de situation est à rapprocher du problème connu de reprise sur panne [Hanemann2005] qui peut être traité par différentes 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 concernées par le contrat ne soient présentes. Cette solution, en plus d'autoriser la continuité de service, permet de définir des accords de niveau de service avant que le service et son utilisateur ne soient déployés.

37 / 65


3.1.7. Service Level Management et auditeur tiers

La recherche est très 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 problèmes: la prise de mesures et leurs traitements, les comportements à adopter selon les valeurs prélevées 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 réagir en cas de non respect. Il a besoin pour ceci d'avoir une métrique bien définie associée à chaque critère de qualité de service. Afin de conserver une certaine impartialité dans cette tâche d'arbitrage, le Service Level Management est généralement délégué à 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 concernées par la contrat. Ensuite, la manière dont il mesure la qualité du service doit être connue des deux parties, ceci pour éviter les litiges. Enfin comme pour tout système d'instrumentation, ses mesures influent sur les résultats. En cas de litige il est donc difficile de détecter précisément 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. Pénalités 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 préjudice à l'utilisateur du service et doit donc être pénalisé. De la même manière, l'usager peut lui aussi avoir des responsabilités décrites dans les accords et donc être pénalisé.

Les pénalités peuvent être de natures différentes: financières (une surtaxation pour l'usager ou bien un dédommagement pour le fournisseur), mettre le client ou le fournisseur sur liste noire, changer de fournisseur, utiliser un système de bonus et de malus, etc. Une solution serait de définir plusieurs politiques et de spécifier dans les accords de niveau de service laquelle sera utilisée.

Les résultats d'éventuelles pénalités doivent être pris en compte lors de la facturation. Et doit on déléguer le problème délicat de la facturation à un tiers de confiance ou bien doit-il être à la charge du fournisseur de service

3.1.9. Confidentialité des négociations

Un contexte multi-organisations est propice à la concurrence. C'est pourquoi les facteurs influençant la négociation (leur poids pour un système de scoring par exemple) doivent être cachés à la concurrence. Il en va de même pour les plans d'action d'agents chargés de la négociation dans un contexte autonomique [Sierra1997].

1 Keynote—The Internet Performance Authority, Keynote Systems,Inc., http://www.keynote.com.2 Xaffire, Inc., http://www.xaffire.com/.

38 / 65

http://www.xaffire.com/

http://www.keynote.com/


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

Le fait de se placer dans une architecture orientée service dynamique a plusieurs impacts sur les accords de niveau de service et leur gestion.

● La disponibilité dynamique autorise les services à disparaître et réapparaître au cours de l'exécution, donc au cours de l'utilisation d'un service. Doit-on rompre le contrat si le service disparaît? La réponse est non si la notion de disponibilité dynamique est intégrée à l'accord de niveau de service. Le comportement que l'usager doit adopter en cas de départ du service qu'il utilisait devrait donc faire partie de l'accord. Pour notre étude nous considérons que l'usager attend toujours le retour du service jusqu'à une date d'échéance spécifiée dans l'accord.

● Selon les ressources disponibles qui fluctuent au cours de l'évolution de l'architecture du système et du temps, une plateforme à services ne sera pas toujours en mesure d'admettre le déploiement d'un nouveau service. Ou alors elle peut négocier certains critères de qualité de service pour diminuer la consommation.

● Certains systèmes, notemment ceux chargés 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 problèmes soulevés par cette dernière partie que porte notre travail.

39 / 65


3.2. Notre contexte: les réseaux d'équipements

Comme nous l'avons vu dans les parties précédentes, grâce à sa modularité et à son intégration facilitée en environnements hétérogènes, l'approche à service est en plein essor dans le monde des équipements et de l'embarqué. C'est dans cette optique qu'ont été développées les plateformes dynamiques à service UPnP et DPWS, ainsi que la plateforme OSGi qui ciblait au départ le domaine de la domotique et les passerelles résidentielles. Nous nous plaçons donc dans le contexte de réseaux d'équipements qui suivent les paradigmes des architectures orientées service dynamiques et dont les services peuvent provenir de fournisseurs différents. Ce contexte multi-organisations rend indispensable l'établissement d'accords de niveau de service.

Nombreux sont les domaines d'application qui utilisent des équipements, généralement des capteurs, interconnectés et parfois administrés par une passerelle multi-fournisseurs.

On en trouve dans:● l'industrie, c'est par exemple le cas de Schneider Electric1 et de son projet SIRENA2

[Jammes2005] basé sur DPWS;● la domotique, que ce soit des équipements ménagers [Marples2004] (éclairage, video-

surveillance, ...) ou bien multimédia (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 véhicules automobiles intègrent de l'équipement informatique, du GPS au lecteur DVD en passant par le radar de recul;

● l'aeronautique et le spatial: les satellites sont équipés d'une multitude de capteurs et embarquent des systèmes qui doivent pouvoir être mis à jour depuis la terre sans devoir être arrêtés;

● l'armement, les commandes de contrôle, et de nombreux autres systèmes embarqués.

Les travaux de [Marin2005] ont abouti à un méta-modèle du domaine des réseaux de capteurs que nous avons étendu au cas de réseaux d'équipements représenté par la figure 14. Les équipements pilotés par un driver sont connectés à un réseau modélisé par un bus. Les devices sont des représentations logicielles simplifiées des équipements. Un service métier peut ensuite utiliser, par l'intermédiaire d'un médiateur (qui se comporte comme un fournisseur de service même s'il n'est pas représenté comme tel sur la figure 14), un ou plusieurs devices pour exécuter une tâche métier Par exemple, l'agrégation de données pour calculer une moyenne si les équipements sont des capteurs.

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

40 / 65

http://www.mediacenter.org/

http://www.sirena-itea.org/

http://www.schneiderelectric.com/


Ces infrastructures ont un réel besoin de flexibilité, elles nécessitent donc une architecture orientée service qui soit dynamique. La disponibilité dynamique permet le déploiement à chaud, c'est-à-dire que le système peut évoluer dynamiquement sans devoir être arrêté, mais le point délicat de la disponibilité dynamique est sa prise en charge en tant qu'aspect non fonctionnel. Le système doit pouvoir s'adapter et réagir aux changements d'architecture qui sont plus complexes dans un contexte dynamique.

De plus ce type d'architectures dynamiques orientées service est portée sur des plateformes dynamiques à services sur lesquelles s'éxécutent des applications provenant de divers fournisseurs et donc d'organisations différentes, sur des passerelles multi-fournisseurs par exemple. Les services évoluent donc dans un milieu concurrenciel multi-organisations. Or dans un contexte multi-organisations le niveau de service fourni a besoin d'être garanti et les contrats, plus particulièrement les accords de niveau de service, jouent un rôle primordial. Par conséquent les domaines auxquels nous nous intéressons sont très demandeurs en systèmes dynamiques capables de prendre en charge les accords de niveau de service.

Dans le cas d'applications critiques embarquées, les composants ont besoin d'un côté d'avoir une garantie sur le niveau de service qui leur est fourni, et d'un autre côté que la dynamique soit bien prise en charge afin d'éviter des situations indésirables. Par exemple, un système de géopositionnement embarqué dans un véhicule autombile en mode pilotage automatique doit être capable lorsque le véhicule passe sous un tunnel, et que la communication GPS devient indisponible (événement assimilé à un départ de service), soit de changer rapidement de mode de communication, soit de désactiver le pilotage automatique et de prévenir le conducteur. Ce cas est présenté plus en détails dans le scénario de la partie 3.3.2.

Nous allons effectivement voir dans la partie suivante quelques scénarios mettant en évidence les besoins liés aux plateformes dynamiques à services et aux accords de niveau de service dans le domaine d'équipements en réseau.

41 / 65

Figure 14. Vue orientée service du modèle de réseau d'équipements

BUS

Equipement 2

Equipement 1

Driver

Device 2

Device 1

Service Métier

Médiateur


3.3. Scénarios de négociation d'accords de niveau de service sur des plateformes dynamiques à services

Pour illustrer nos propos nous présentons quatre scénarios d'usage qui montrent les différents problèmes que peut poser la prise en compte de la dynamique des architectures orientée services dans les accords de niveau de service. Nous nous placerons successivement dans le cas d'environnements à ressources limitées, d'un véhicule équipé d'un système de pilotage automatique dont le service GPS devient indisponible et enfin dans le cas de calcul à partir de données fournies par un réseau d'équipements électriques.

Nous y étudierons respectivement la renégociation de contrat en vue d'économiser les ressources, comment traiter le départ 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. Renégociation de contrat dans un environnement à ressources limitées et fluctuantes

Dans le contexte dans lequel nous nous plaçons pour notre étude, il n'est pas rare que les plateformes dynamiques à service soient déployées sur un système embarqué dont les ressources sont limitées et fluctuent dans le temps.

L'arrivée sur un réseau d'un nouvel équipement, dont on connait ou dont on peut prévoir la consommation, ne peut pas toujours être acceptée si les ressources disponibles sont insuffisantes. Une renégociation des contrats et du mode de fonctionnement du système peut aussi être nécessaire dans le cas où les ressources viennent à manquer et doivent être économisées.

3.3.1.1. CPU et mémoire vive limités

Description du problème: Les ressources mémoire et CPU du système sont limitées et font donc l'objet d'accords de niveau de service. Un nouvel équipement se connecte au réseau mais le système ne possède plus suffisamment de ressources pour l'accueillir. Son device ne peut donc pas être déployé sur la plateforme à services.

Une autre solution plus complexe consisterait à renégocier le contrat des équipements déjà déployés afin d'économiser les ressources. Les changements des termes du contrat peuvent alors être assimilés à des changements dynamiques de propriétés.

Considérons une station relais chargée de fusionner les données transmises à un composant video par des capteurs vidéos en réseau, et d'afficher le résultat. Sa mémoire vive et son CPU sont limités. Le programmeur estime que le composant vidéo nécessite 45% du CPU et 150 ko de mémoire pour afficher 25 images / seconde [Tournier2005]. Chaque capteur vidéo consomme 5% de ressources supplémentaires. Plus précisément c'est le device représentant le capteur video qui s'éxécute sur la plateforme à service et qui consomme les ressources de la plateforme, puisque les capteurs possèdent leurs propres ressources.

Dans le cas où le CPU est utilisé au maximum de ses possibilités et où un nouveau capteur se connecte au réseau pour transmettre ses données, l'ajout du composant est remis à une date

42 / 65


ultérieure (par désynchronisation de l'événement reçu par exemple) lorsque les ressources seront suffisantes. En effet, le contrat proposé par le fournisseur du service d'affichage video spécifie des ressources disponibles nulles ou bien inférieures à celles requises par le nouveau capteur video.

On peut aussi imaginer une négociation plus complexe. Si le composant video est prêt à négocier le nombre d'images par seconde, en spécifiant 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 élevées. Dans ce cas il pourra accepter le nouveau capteur.

3.3.1.2. Energie limitée

Description du problème: Dans de nombreux systèmes embarqués et mobiles, l'énergie est limitée. Toujours dans une optique d'économie, afin de garantir une autonomie plus longue et prévenir l'arrêt du système, il est nécessaire de renégocier la qualité de service sur les points du contrat qui consomment le plus d'énergie.

Une autre ressource limitée dans le cas d'équipements mobiles est l'énergie. Les dernières générations d'ordinateurs portables, où l'autonomie de la batterie représente la plus grosse contrainte, intègrent déjà 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é renégocié.

Observons le cas de capteurs physiologiques produits par Cyberfab (oxymètres, glucomètre, cardio-fréquencemètres) [Cyberfab]. Des services déployés sur un téléphone mobile permettent de recevoir par Bluetooth1 les informations relevées par les capteurs et de les traiter pour les rendre compréhensibles à l'utilisateur. Considérons un patient équipé d'un capteur glucomètre. Son téléphone portable (ou son assistant personnel2) lui permet de suivre l'évolution de son taux de glycémie et de l'alerter du danger en cas de chute. Lorsque la batterie du contrôleur 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 renégociation des accords de niveau de service au niveau des ressources, il pourra renégocier la fréquence de polling3 ou la fréquence de rafraîchissement de l'affichage. En effet, en diminuant la fréquence des communications avec les capteurs, la batterie est économisée et l'utilisateur aura plus de temps pour trouver une autre source d'alimentation.

On retrouve également ce type de scénario dès que l'on a un équipement qui est déconnecté de sa source d'alimentation principale et qui doit basculer sur une alimentation auxiliaire. Il doit renégocier son mode de fonctionnement et donc les contrats de ses services. Ces cas de figure relèvent toutefois du domaine des applications sensibles au contexte4 et cet aspect étant un sujet de recherche actif et très lié aux applications auto-adaptables et à l'informatique autonomique, nous ne tenterons pas de résoudre ce point.

1 Bluetooth est une spécification de l'industrie des télécommunications qui utilise une technologie radio courte distance

2 PDA3 Le polling consiste à scruter régulièrement les changements de valeur lorsque la remontée d'événements trop

fréquents coûte cher en CPU4 En anglais, context-aware

43 / 65


3.3.2. Négociation de la disponibilité dynamique d'un service, continuité de service et contrat persistant

Description du problème: En cas de départ d'un service, le contrat ne doit pas systématiquement être rompu, la décision à prendre doit être spécifiée dans les accords. Si les accords de niveau de service intègrent la notion de disponibilité dynamique, alors le fournisseur peut garantir la disponibilité de son service dans une fenêtre de temps et se permettre de disparaître puis réapparaître. La liaison et le contexte, donc le contrat, doivent dans ce cas être conservés jusqu'au retour du service ou jusqu'à ce que la date d'échéance (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 présentes.

Un service de pilotage automatique est installé sur un véhicule automobile. Il a besoin entre autres de données fournies par des capteurs de géopositionnement (représentés par leur device respectifs) et par un accéléromètre. 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 véhicule 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 conservée jusqu'à ce que le service revienne ou jusqu'à ce que l'échéance (i.e les 30 secondes) soit écoulée. A partir de la dernière position reçue par le service GPS et des données de l'accéléromètre le service de pilotage automatique peut continuer à guider le véhicule pendant 30 secondes. Une fois ce délai passé, l'erreur due aux calculs devient trop importante pour garantir la sécurité, il y a danger. Donc si le véhicule n'est pas sorti du tunnel au bout de ce délai, soit le pilotage dynamique automatique est désactivé et le contrôle rendu au conducteur, soit l'utilisation d'un autre protocole de géopositionnement, comme un service GPRS2 par exemple, est négociée.

Toutefois si le véhicule sort du tunnel en moins de 30 secondes et que le service GPS redevient disponible, alors la liaison persistante qui avait été conservée est réutilisée et le service de pilotage automatique peut à nouveau exploiter les données fournies par le GPS.

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

Description du problème: Dans certains cas, il est nécessaire de pouvoir garantir une stabilité au sein même 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 période de temps T. Pendant cette période, les services choisis peuvent disparaître et réapparaître dynamiquement si le contrat prévoit cette possibilité, mais de nouveaux services ne seront pas acceptés; l'usager ne sera notifié que des arrivées des services sélectionnés.

Considérons le cas de la surveillance d'un réseau d'équipements électriques, domaine de Schneider Electric. Supposons qu'un calcul est effectué tous les midis à partir de données collectées

1 Global Positioning System 2 Global Packet Radio Service3 En anglais, Dynamic in a Static Set (DSS)

44 / 65


pendant une demi-heure. Pendant ce calcul, on ne souhaite pas que l'architecture du système change dynamiquement. Le scintillement, c'est-à-dire les arrivées et départs intempestifs de services, est effectivement un aspect des architectures orientées services dynamiques qu'il faut éviter lorsqu'une architecture stable est nécessaire.

A 11h45 le service métier chargé du calcul vérouille l'architecture jusqu'à 12h15. Le vérouillage consisterait à interdire l'arrivée de nouveaux services et leur liaison. Le device d'un nouvel équipement qui arriverait sur le réseau pendant cette plage horaire ne pourrait donc pas être déployé sur la plateforme à services ni signer de contrat avec le service métier.

45 / 65


3.4. Modèle d'architecture dynamique orientée service supportant les accords de niveau de service

Nous proposons dans ce chapitre de fournir un modèle d'architecture orientée service supportant les accords de niveau de service. Le modèle doit rester assez générique pour être applicable à plusieurs scénarios vus dans la partie précédente. Comme expliqué dans la section 3.1, nous ne pouvons traiter tous les problèmes simultanément. Nous nous intéressons ici principalement à la disponibilité dynamique et son impact sur les accords de niveau de service. Pour le moment, nous ne nous intéressons pas à la modélisation des accords de niveau de service qui sera abordée dans la section suivante.

Nous devons alors faire plusieurs hypothèses :i. Les différentes parties sont en accord sur la sémantique utilisée dans les SLAs et les

interprètent de manière non ambigüe.ii. Les accords de niveau de service ne sont pas modélisés mais ils doivent tout de même

contenir les parties engagées par le contrat, des critères de qualité de service, et les contraintes et obligations de chaque partie.

iii. Les accords sont établis d'après les besoins de l'usager et la proposition de contrat du fournisseur du service.

iv. Chaque service peut être identifié de manière unique, ceci afin de supporter la disponibilité dynamique. Nous considérons qu'un service possède un identifiant persistant appelé <pid> afin de l'identifier lors de ses réapparitions.

Un point intéressant du modèle 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 négocié, le fournisseur de service peut rejeter la demande de l'usager ou bien fournir le service sans aucune garantie ni obligation de résultat.

3.4.1. Vue générale

Le modèle que nous définissons, représenté 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'exécution et donc utilisable par tout usager.

La création 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 passés entre usagers et fournisseurs de services. Grâce à une combinaison des patrons proxy et intercepteur, les interactions entre un usager et le service qu'il utilise peuvent être capturés par le SLA Manager dans un objectif de surveillance du respect des accords de niveau de service. Ces tâches d'instrumentation (mesures, création et stockage d'historiques ou de fichier de log si nécessaire), de surveillance ainsi que de prise de décision en cas de violation des accords, que nous nommerons SLM (pour Service Level Management) pour plus de commodité, sont déléguées à un

46 / 65


ou plusieurs auditeurs tiers (appelés Audit sur la figure 13). Nous avons choisi de déléguer les opérations de création et de suppression d'auditeurs à une fabrique d'auditeurs qui se présente sous la forme d'un service, le SLMService.

Les sections qui suivent détaillent le rôle de chaque entité pré-citée.

3.4.2. SLA

L'objet 'SLA' (Service Level Agreement) représente 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 résultat d'une adéquation 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 plaçons 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 même type, un accord de niveau de service peut correspondre

47 / 65

Figure 15. Modèle d'architecture orientée service supportant les accords de niveau de service

SLA ManagerService

Requester 1

ServiceRequester 2

ServiceProvider B

ServiceProvider A

Audit Factory

Audit1 Audit2

DynamicProxy interceptor



Audit3

SLM Service

+Audit createAudit(SLA)+void removeAudit(Audit)

Service A

Service A

Service B

SLA Service

sla.Service B

Service B sla.Service A

Service B

SLM Service

SLM Service

SLA Service

SLA Service

Service Registry

SLAConsumer

Requirementsx

Prov iderContractProposal

Audit+pre-invoke+post-Invoke


à l'ensemble des liaisons vers ces services. Par exemple un service peut faire appel à N capteurs effectuant la même tâche, et si les accords de niveau de service intègrent la notion de groupe de fournisseurs, alors un seul accord peut suffir pour le groupe de capteurs.

Un modèle 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 respectés. Pour cela, il utilise les patrons de proxy et d'intercepteur.

3.4.3.1. Proxy dynamique et sla.<service pid>

Lorsqu'un usager décide de passer par le SLAService pour utiliser un service S, le SLA Manager créé dynamiquement un proxy du service S: un représentant qui a la même syntaxe donc la même interface dans une approche orientée objet (voir figure 16). Pour cela le SLA Manager fournit dynamiquement un service S' identique au service S à l'identifiant près (voir hypothèse 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 déjà en place, le contrat n'a pas été rompu grâce à sa persistance. De plus ce schéma permet d'intégrer aisément un intercepteur si l'on désire 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

Figure 16. Diagramme UML du patron « proxy ».


Lorsque l'usager invoque une méthode d'un service, le proxy se charge de propager l'appel à ce service. C'est ici qu'intervient l'intercepteur: le proxy lui délègue l'invocation du service. L'intercepteur connait le service et l'opération à appeler, ainsi que les paramètres nécessaires. L'avantage d'un patron 'intercepteur' est qu'il permet d'effectuer des opérations de traitement ou des mesures avant et après l'invocation du service. Connaissant les accords de niveau de service, il est alors possible de vérifier 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 représentés 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 opérations 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 deuxième 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 précisément l'intercepteur) utilise le service SLMService pour créer 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 méthodes 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 modèle, les auditeurs tiers sont créés et utilisés par les intercepteurs. Avant d'appeler un service l'intercepteur permet à l'auditeur de prendre des mesures s'il le souhaite en appelant une méthode pre-invoke; et avant de retourner le résultat de l'appel grâce à l'opération post-invoke.

Les auditeurs doivent également être capables d'agir sur les parties concernées en cas de violation des accords par exemple. Ceci est possible d'après l'hypothèse ii: les accords de niveau de service fournissent aux auditeurs les identifiants des parties impliquées. Nous ne nous préoccupons pas de la manière dont un auditeur peut agir sur les parties mais voici quelques propositions:

● Un système de publication / souscription pourrait permettre aux parties signataires d'écouter les événements de type "pénalités" émis par les auditeurs en charge de leurs accords de niveau de service.

● Les parties signataires pourraient également fournir un service implémentant les pénalités contenues dans les accords et l'auditeur n'aura qu'à utiliser ce service.

● Enfin, les actions issues de la prise de décision par les auditeurs peuvent être soit synchrones, soit asynchrones.

Concernant l'origine des auditeurs, nous avons fait le choix de créer les auditeurs dynamiquement à la demande, mais ce n'était pas la seule solution possible. Une variante consiste à utiliser des

49 / 65


auditeurs déjà déployés qui fournissent des services de surveillance. On a alors une architecture de type « plug-in » où des services d'audit (qui doivent tout de même implémenter les méthodes pre-invoke et post-invoke) sont recherchés en passant par le registre de service et se « branchent » au SLA Manager (plus précisément à 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 critères de qualité de service les coûts liés à l'instrumentation et à la prise de décision, opérations qui perturbent le système.

3.4.6. ContractProposalService

Les accords de service sont établis d'après les besoins de l'usager et la proposition de contrat du fournisseur, qui, notons-le, peut très bien contenir des contraintes sur l'usager.

Deux solutions sont envisageables. La première, plus simple, consiste à enregistrer la proposition de contrat dans le registre de service, en tant que propriété 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 méthode register(ContractProposal) par exemple). Ceci à l'avantage de les rendre persistantes et de pouvoir mener des tâches de négociation lorsque le service requis n'est pas encore disponible.

3.4.7. Proposition pour une architecture répartie

L'architecture que nous avons précédemment proposé est centralisée autour du SLA Manager. Bien que les auditeurs, les usagers et les fournisseurs de services puissent tous se trouver sur des sites différents, le SLA Manager demeure une seule entité monolithique.

Une autre solution que nous ne détaillerons pas dans ce document est de répartir 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

Figure 17. Le SLA Manager fournit un service de proposition de contrat

SLA Manager

ServiceProvider A

Service A

ConctractProposal Service

SLAConsumer

Requirementsx

Prov iderContractProposal

ConctractProposal Service


3.5. Modèle d'accords de niveau de service supportant la disponibilité dynamique

Nous avons choisi de modéliser 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 acceptés par les deux parties. La négociation 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 considérerons que l'usager spécifie 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 négociation correspond dans notre cas à une simple adapatation de la proposition de contrat du fournisseur aux exigences de l'usager.

D'après les travaux de [Dan2004] et la spécification WSLA [Ludwig2003], les accords de niveau de service peuvent être découpés en trois parties: les parties engagées par le contrat, la description du service et les obligations. Nous avons préféré isoler la description du service tout en gardant à l'esprit les différentes parties constitutives d'un accord de niveau de services décrites par [Miller1987] et présentées dans la section 2.3.1. Nous avons donc choisi de découper les accords sur le modèle de WSLA en trois sous-parties (voir figure 18):

● les parties concernées par le contrat,● les paramètres SLA,● les pénalités.

3.5.1. Les parties

La section 'parties' contient les identifiants des parties concernées par le contrat, à savoir l'usager, le ou les services (les parties signataires), et les parties tierces appelées « auditeurs tiers » chargées 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'exécution afin que les accords de niveau de service puissent être persistants et supporter le départ et le retour d'un service.

● Le scénario 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'exécution, même en cas de départ d'un des services.

● Un auditeur tiers doit pouvoir identifier de manière unique les différentes parties engagées pour par exemple mener à bien ses tâches de facturation ou de pénalisation.

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 référence sur la partie en question.

51 / 65


52 / 65

Figure 18. Notre modèle UML de structuration des accords de niveau de service.


3.5.2. Les paramètres SLA

Les paramètres SLAs représentent les critères de qualité de service, et les accords de niveau de service définissent leur valeur. Nous supposons que les parties contractantes ainsi que les parties chargées de l'évaluation des accords comprennent les paramètres de la même manière et utilisent la même métrique. Nous avons fais le choix de définir chaque paramètre par un intervalle de valeurs. Par exemple, le temps de réponse serait défini par

responseTime.min = 0 et responseTime.max = 2l'unité de mesure étant la seconde.Afin de supporter la disponibilité dynamique, tout accord de niveau de service construit sur notre

modèle doit inclure le paramètre suivant: dynamicAvailability. Il est exprimé en pourcentage par rapport à une fenêtre de temps exprimée en secondes par exemple. Ainsi,

dynamicAvailability.rate = 50 et dynamicAvailability.window = 3600signifie que pendant une heure le service assure une présence de 30 minutes.Un autre paramètre à ajouter est la date de validité des accords. Ces derniers ont une durée de vie

limitée et sont susceptibles d'être changés selon les changements de politique du fournisseur de service. S'ils ne sont pas modifiés avant la date limite de validité, alors le contrat devient invalide et est rompu.

Les paramètres SLAs peuvent aussi bien être des contraintes imposées 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 déclaré

dans cette section. Paramètres SLA englobe donc des critères de qualité de service dont les valeurs sont comprises dans un intervalle défini par un minimum et un maximum, ainsi que les trois paramètres suivants:

● la disponibilité dynamique: elle est définit par un pourcentage sur une fenêtre 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 extrêmement divers.

3.5.3. Les pénalités

La dernière partie concerne les pénalités et plus généralement les actions à entreprendre. Nous avons choisi pour notre modèle de les présenter sous la forme de règles ECA (événement > condition > action) où l'événement correspond simplement à un paramètre SLA qui n'a pas été respecté, les conditions sont des expressions booléennes et les actions sont des opérations pouvant être composées d'une série de plusieurs actions.

Voici quelques exemples commentés de ces règles:<clientCallsPerSecond.max, serviceAvailable, client.addPenality(50)>

=> Si un auditeur détecte 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 pénalité du client est augmentée. Ici ce peut être de 50 points ou une surtaxe de 50 € puisque la métrique n'est pas précisée.

<dynamicAvailability, anotherServiceIsAvailable, serviceProvider.blacklist & changeService>

53 / 65


=> 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 système 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 dépasse le quota qui lui est accordé, notre architecture grâce à l'utilisation des patrons proxy et intercepteur permet de geler les appels du client ou de lui renvoyer une exception, plutôt que de transmettre son appel au service.

54 / 65


4. Expérimentation et validation de notre modèle d'architecture

Ce chapitre montre une réalisation de notre modèle construit sur la plateforme à services OSGi. Le but de ce prototype est de valider notre proposition en expérimentant un scénario de gestion de la disponibilité dynamique dans les accords de niveau de service.

4.1. Scénario du prototype

Afin d'expérimenter notre modèle, nous avons choisi d'illustrer le scénario 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 boursière de type StockService qui lui permet de réclamer à intervalle régulier (toutes les secondes) différentes cotations boursières . Le service StockService attend un temps T aléatoire avant de servir StockRequester. Deux services de type StockService sont déployés: StockServiceSilver et StockServiceGold dont le temps de réponse aléatoire T est inférieur respectivement à 3 et à 2 secondes et dont le prix est respectivement de 1€ et 2€ par information.

L'application StockRequester exige un temps de réponse inférieur à 2 secondes et on suppose que les deux fournisseurs acceptent cette garantie. Les accords de niveau de service garantissent donc un temps de réponse 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 répond après 2 secondes et viole la clause portant sur le temps de réponse. Le résultat de la requête est intercepté par le SLA Manager qui a détecté le non-respect de l'accord et est remplacé par un message « SLA non respecté ». StockRequester interprète ce message et décide de ne plus utiliser ce StockService et d'en choisir un de type Gold.

Le service Gold précise dans son contrat une disponibilité de 50% sur une fenêtre de 10 secondes. Une fois la liaison établie, le service disparaît au bout de 2 secondes puis réapparait 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 réapparu au bout des 10 secondes. Le SLA Manager considère alors que la garantie de disponibilité dynamique n'a pas été respectée 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 reçu.

55 / 65


4.2. Choix de la plateforme

Nous avons choisi d'expérimenter notre modèle sur la plateforme dynamique à services Oscar/Félix, implémentation d'OSGi (pour plus de détails voir section 2.1.2.4) pour plusieurs raisons. La plateforme OSGi est particulièrement adaptée aux services colocalisés sur une même machine virtuelle Java et convient de ce fait à l'administration d'équipements en réseau. De plus en tant que surcouche à la plateforme Java 2, la plateforme OSGi intègre une bonne gestion de la sécurité, ce qui représente un avantage considérable pour la gestion d'accords de niveau de service.

La plateforme OSGi offre une gestion avancée de la dynamique, et la plateforme Java fournit depuis la version 1.3 une implémentation de proxy dynamique, java.lang.reflect.Proxy, ce qui nous a facilité la tâche.

4.3. Architecture du prototype

56 / 65

Figure 19. Architecture de notre prototype pour un scénario de cotation boursière

Stock Service Silver

StockRequester

Stock Service

Gold

SLA1

SLA2StockServicetype = Gold

StockServicetype = Silver

StockService

SLA Manager

Audit


Nous utilisons un modèle 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'après le scénario://partiesRequesterID = StockRequester.pidProviderID = StockService.pidAuditID = ... //défini à la création de l'Audit...

//paramètres SLApricePerMessage = 2;responseTime.MAX = 2;dynamicAvailability.rate = 50;dynamicAvailability.window = 10;...

//pénalités<responseTime, anotherStockServiceIsAvailable, rompre_contrat & changeService><dynamicAvailability, null, noBillig>...

Le SLA Manager se présente sous la forme d'un bundle exposant un service SLAService. Dans un souci de clarté nous avons fait le choix de ne pas le représenter 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 différents bundles nécessaires au fonctionnement de notre prototype avant de démarrer 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 prédéfinis SLA1 et SLA2 car nous n'avons pas réalisé de mécanisme de négociation;

● le bundle AuditFactory qui fournit le service SLM Service;● deux bundles StockServiceSilver et StockServiceGold qui fournissent un service

StockService, dont l'implémentation possède un attribut 'type' égal respectivement à 'silver' et à 'gold' et dont le temps aléatoire avant la réponse est inférieur 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 référence sur le représentant du StockService de type 'silver'. Il peut alors intéragir avec le service StockServiceSilver en passant par le proxy dynamique et ses interactions sont interceptées par l'auditeur créé juste avant la liaison par le SLA Manager. Une fois que la rupture du contrat pour dépassement de délai par le service Silver a été détectée, la liaison est rompue et le StockRequester cherche donc à se lier au StockServiceGold, toujours en utilisant le SLA Service.

57 / 65


Pendant l'utilisation du service gold, nous simulons l'apparition et la disparition du service en arrêtant et redémarrant le service par la commande stop <ID>. Si nous l'arrêtons plus de 5 secondes, nous nous apercevons que même en redémarrant 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 modèle qui fonctionne bien au moins pour ce scénario. L'auditeur attaché à la liaison a pu intercepter les interactions entre les l'usager et les fournisseurs de service grâce au patron de proxy dynamique, prendre des mesures de temps et jouer son rôle en appliquant les pénalités définies 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é très liés au contexte des réseaux et la recherche dans le domaine des accords de niveau de service a acquis un certain degré de maturité. Aujourd'hui, avec la prolifération 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 caractère dynamique n'est pas encore assez considéré par les nombreux travaux portant sur les accords de niveau de service.

C'est pourquoi nous avons proposé, pour répondre à ces nouveaux besoins, un modèle d'architecture dynamique prenant en charge les accords de niveau de service, ainsi qu'un modèle d'accord de niveau de service intégrant les concepts propres aux architectures dynamiques orientées service.

5.2. Perspectives à court terme

Nous envisageons plusieurs perspectives à ces travaux. Nos perspectives à court terme:

● Expérimentation avec des moteurs de règlesUne expérimentation approfondie de notre modèle d'accord de niveau de service

requiert de définir des accords plus précis pour tester son extensibilité. De même, la partie pénalités de notre modèle 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), mériterait d'être étudié plus en détail, notamment l'exécution des règles ECA que nous n'avons pas traité.

● Proposition de mécanismes de négociationDans notre étude nous avons également fait le choix de ne pas nous préoccuper

des mécanismes de négociation. Enrichir notre modèle d'un schéma de négociation plus complexe que la simple sélection de service dans un registre, et faisant intervenir pleinement les parties contractantes, serait un atout considérable et valoriserait notre travail.

● Validation de l'approche sur le modèle de composant SCAIl serait enfin intéressant de modéliser et de valider la version répartie 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


un projet visant à faciliter la construction d'architectures orientées service en encapsulant des composants préexistants dans des services Web. Les applications construites sur la plateforme SCA sont donc majoritairement réparties. Une perspective de développement futur consiterait à fournir à partir du modèle réparti du SLA Manager un canevas pour la prise en charge des accords de niveau de service sur cette plateforme prometteuse.

Nos développements s'appuieront sur les canevas iPOJO [Escoffier2006] et Spoon [Pawlak2005]. Ces deux canevas ont pour objectif de séparer les aspects fonctionnels des aspects non fonctionnels et particulièrement 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 serviceNous ne l'avons pas cité dans ce document, mais il existe une très forte demande,

en particulier dans le domaine des systèmes embarqués et critiques, pour des plateformes à services dynamiques supportant la cohabitation de services temps réel, semi-temps réel et non-temps réel. De telles plateformes nécessiteraient des accords de niveau de service bien définis, et des mécanismes de négociation permettant d'assurer une bonne gestion des ressources qui seraient contractualisées, afin que l'exécution de tâches en temps réel, généralement critiques, ne soient pas préemptées par des tâches d'importance moindre.

● Le comportement autonomique des certifieurs de serviceNous n'avons pas non plus cherché à modéliser les certifieurs de services (ou

auditeurs tiers). Toutefois, comme expliqué précédemment, une solution particulièrement efficace serait l'utilisation de l'informatique autonomique. Les processus de négociation des accords de niveau de service, la surveillance et l'évaluation de leur respect, ainsi que la prise de décision pour les pénalités pourraient alors être dirigés par des objectifs clairement définis et facilement maintenables.

● Les métriques liées à la dynamique des servicesEnfin, comme montré dans la section 3.1, notre étude a soulevé plusieurs

problèmes dont l'accord des parties sur la sémantique des contrats et des métriques, problèmes qui ne sont pas encore résolus et qui ouvrent de nombreux axes de recherche.

60 / 65


6. Bibliographie

Bibliographie

[ADELE2005] ADELE - Réunions autour des services, 2005

[Ayed2003] Ayed, Dhouha and Taconet, Chantal and Bernard, Guy - Etude Comparative des Services de Recherche sur Propriétés., 2003

[Beugnard1999] Beugnard, A. and Jézéquel, J.-M. and Plouzeau, N. and Watkins, D. - Making Components Contract Aware, 1999, IEEE Computer, Volume 32,

[Cervantes2004] Humberto Cervantes - Vers un modèle a composants orienté services pour supporter la disponibilité dynamique, Université Joseph Fourier, 2004

[Cervantes2005] 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

[Channabasavaiah2004] Kishore Channabasavaiah and Kerrie Holley and Edward Tuggle, Jr. - Migrating to a service-oriented architecture, 2004, IBM DeveloperWorks White Paper, Volume ,

[Consulting2002] RL Information Consulting - A Description of Service Level Agreements, 2002

[Coutaz2005] Joëlle Coutaz and James L. Crowley and Simon Dobson and David Garlan - Context is key, 2005, Commun. ACM, Volume 48, ACM Press

[Cyberfab] Cyberfab, http://www.cyberfab.net

[Dan2004] 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,

[Donsez2001] Didier Donsez and Pierre Yves Gibello - Advanced Transaction Models for EJB and Web Services, 2001

61 / 65


[Donsez2005] Didier Donsez - Atelier « mise en œuvre d'UPnP avec OSGi », 2005

[Escoffier2005] Clément Escoffier - Administration autonomique dans le contexte du Edge Computing, Université Joseph Fourier, 2005

[Escoffier2006] iPOJO, http://www-adele.imag.fr/~escoffie/dev/ipojo/

[Hanemann2005] 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

[IST2006] Information Society Technologies IST - The Software and Services Challenge, 2006

[Jammes2005] F. Jammes and H. Smit - Service-Oriented Architectures for Devices – the SIRENA View, 2005

[Jammes2005a] François Jammes and Antoine Mensch and Harm Smit - Service-oriented 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

[Keller2002] A. Keller and H. Ludwig - Defining and Monitoring Service Level Agreements for dynamic e-Business, 2002

[Kephart2001] 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

[Kephart2003] J. O. Kephart and D. M. Chess - The Vision of Autonomic Computing, 2003, Computer, Volume 36, IEEE Computer Society Press

[Lamanna2003] D. Davide Lamanna and James Skene and Wolfgang Emmerich - SLAng: A Language for Defining Service Level Agreements. - FTDCS, 2003

[Ludwig2003] Heiko Ludwig and Alexander Keller and Asit Dan and Richard P.King and Richard Franck - WSLA Language Specification, Version 1.0, 2003

[Malloy2006] 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


[Marin2005] Cristina Marin and Philippe Lalanda and Didier Donsez - A MDE Approach for Power Distribution Service Development. - ICSOC, 2005

[Marples2004] D. Marples and S. Moyer - Home Networking and Appliances, Smart Environments:Technologies, Protocols and Applications (Diane Cook, Sajal Das) - Chapitre 6, Wiley, 2004

[Meyer1992] Bertrand Meyer - Applying Design by Contract, 1992, IEEE Computer, Volume 25,

[Miller1987] George W. (Bill) Miller - Service Level Agreements: "Good Fences Make Good Neighbors". - Int. CMG Conference, 1987

[Motahari2006] Motahari Nezhad, H.R. and Benatallah, B. and Casati, F. and Toumani, F. - Web Services Interoperability Specifications, 2006, IEEE Computer, Volume 39,

[Oldham2006] Nicole Oldham, Kunal Verma, Amit P.Sheth, Farshad Hakimpour - Semantic WS-Agreement Partner Selection, 2006

[OSGi] The OSGi Alliance, http://www.osgi.org

[Paschke2005] Adrian Paschke and Martin Bichler - SLA Representation, Management and Enforcement., 2005

[Paschke2005a] Adrian Paschke and Martin Bichler and Jens Dietrich - ContractLog: An Approach to Rule Based Monitoring and Execution of Service Level Agreements., 2005

[Paschke2006] RBSLA: Rule-based Service Level Agreement, http://ibis.in.tum.de/staff/paschke/rbsla/

[Pawlak2005] Pawlak, R. - Spoon: Annotation-Driven Program Transformation - The AOP Case., 2005

[Redmond2002] 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

[Sierra1997] 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

[Snoonian2003] Snoonian, D. - Smart buildings, 2003, Spectrum, IEEE, Volume

63 / 65


40,

[Software2004] End-end Software (ITS) - Service Level Agreements, 2004

[Stal2006] Michael Stal - Using Architectural Patterns and Blueprints for Service-Oriented Architecture, 2006, IEEE Software, Volume 23,

[Sterritt2005] Roy Sterritt and Michael G. Hinchey - Autonomic Computing - Panacea or Poppycock? - CBSE, 2005

[Tournier2005] Jean-Charles Tournier and Jean-Philippe Babau and Vincent Olive - Qinna, a Component-Based QoS Architecture. - CBSE, 2005

[UPnP] The UPnP Forum, http://www.upnp.org

[W3C2006] W3C Member Submission, http://www.w3.org/Submission/WS-Policy/

[Zschaler2004] Steffen Zschaler and Simone Röttger - Types of Quality of Service Contracts for Component-Based Systems, 2004

64 / 65


7. GlossaireAccord 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 représentant 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 orientées service chargée de la publication des services et de leur

courtage. Règle ECA:Règle événement-condition-action. Une règle eca (E,C,A) signifie que lors d'un événement E, si

la condition C est vérifiée, alors l'action A est menée.

Service Level Management (SLM):Désigne l'ensemble des mécanismes destinés à la prise en charge des accords de niveau de

service. (Prise de mesure, de décision, application des pénalités, 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 assimilés 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

accords de niveau de service dans les ... - · remerciements je tiens à remercier toutes les...

Documents