Télécharger le fichier original (Mémoire de fin d’études)

ARCHITECTURES ORIENTEES SERVICES

Qu’est ce qu’un service Web ?

Dans le cadre de la programmation orientée service, un service peut être défini comme une entité fonctionnelle auto-contenue, auto-décrite, indépendante des plateformes, et pouvant être décrite, publiée, découverte, invoquée, composée à l’aide de protocoles standards. La technologie des services Web constitue une approche pour la concrétisation du paradigme de service sur le Web. Par le biais de cette technologie, il devient possible de délivrer et de consommer des services logiciels sur le Web, détournant l’usage premier de celui-ci qui ne consistait initialement qu’à publier et à lire des documents et des informations. Le W3C (World Wide Web Consortium) définit le service Web de la manière suivante [1] : Un service Web est un système logiciel identifié par un identificateur uniforme de ressources URI, dont les interfaces publiques et les liens binding sont définis et décrits en XML. Un service Web peut être découvert et sélectionné dynamiquement par d’autres systèmes logiciels. Ces derniers peuvent, ensuite, interagir avec le service sélectionné en utilisant des messages XML transportés par des protocoles Internet.
Les services Web se basent sur un modèle de trois couches : un protocole de communication permettant de structurer les messages échangés entre les composants logiciels, une spécification de description des interfaces des services et enfin une spécification de publication et de localisation de service. Les services Web sont le fondement de base des architectures orientées services.

Qu’est ce que une architecture orientée services ?

Une architecture orientée services (SOA) est un style d’architecture fondé sur la description de services et de leurs interactions. Les caractéristiques principales d’une architecture orientée services sont le couplage faible, l’indépendance par rapport aux aspects technologiques et l’extensibilité. La propriété de couplage faible implique qu’un service n’appelle pas directement un autre service. Les interactions sont gérées par des fonctions externes d’orchestration. L’indépendance par rapport aux aspects technologiques est obtenue grâce aux interfaces d’utilisation offertes par le fournisseur du service. Enfin, l’extensibilité est rendue possible par le fait que de nouveaux services peuvent être découverts et invoqués à l’exécution.
La notion d’architecture orientée services n’est pas nouvelle, elle est apparue dès le développement des approches client/serveur. Les définitions sont nombreuses et nous retiendrons les suivantes :
– “Une architecture orientée services est un style d’architecture qui aide les organisations à partager la logique métier et les données entre plusieurs applications et selon différents modes d’utilisation.”, donnée en 1996 par le groupe Gartner [2].
– “SOA permet une intégration flexible des applications et des ressources: (1) en représentant chaque application ou ressource en tant que service avec une interface normalisée, (2) en permettant aux services d’échanger des informations structurées (messages, documents, objets métier »), et (3) en coordonnant les services afin de s’assurer qu’ils peuvent être invoqués, utilisés et modifiés de manière efficace par des utilisateurs ou par d’autres services [3].”
– Dans le modèle de référence OASIS [4], “SOA est un paradigme pour organiser et utiliser des ressources métiers distribuées qui peuvent être sous le contrôle de différents domaines. Il fournit un moyen uniforme pour offrir, découvrir, interagir et utiliser ces ressources afin de produire des résultats souhaités compatibles avec des conditions et des attentes mesurables”.
Malgré le manque de spécification officielle pour définir une architecture orientée services, trois rôles clés sont communément identifiés : producteur de services, annuaire de services et consommateur de services. L’interaction entre ces trois rôles est décrite par la Figure 1 [4].
Le producteur de services a pour fonction de déployer un service sur un serveur et de générer une description de ce service. Ce dernier précise à la fois les opérations disponibles et leur mode d’invocation. La description de ce service est publiée dans un annuaire. Les consommateurs de services peuvent découvrir les services disponibles et obtenir leur description en lançant une recherche sur l’annuaire. Un consommateur peut alors utiliser la description du service obtenue pour établir une connexion avec le fournisseur et invoquer les opérations du service souhaité.
Bien que les SOAs n’aient vraiment pris leur essor que ces dernières années, il existe des propositions plus anciennes sur ce même modèle telles que CORBA [5] ou DCOM [6]. Les SOAs sont en effet plus connues sous leur version services Web (Web Services Oriented Architectures ou WSOA) car elles reposent sur des technologies basées sur des standards XML et offrent ainsi une solution indépendante des implantations, plateformes, langages ou encodage de données propriétaires. Les trois protocoles de base sont WSDL [7], UDDI [8] et SOAP [9]. Le standard WSDL (Web Service Description Language) est un langage reposant sur la notation XML permettant de décrire les services Web. WSDL permet ainsi de décrire l’emplacement du service Web ainsi que les opérations (méthodes, paramètres et valeurs de retour) que le service propose. Le standard UDDI (Universal Description Discovery and Integration) défini par l’OASIS vise à décrire une manière standard de publier et d’interroger les services Web au sein d’un service d’annuaire. Et enfin, SOAP est un protocole défini à l’origine par Microsoft, puis standardisé par le W3C, utilisant la notation XML permettant de définir les mécanismes d’échanges d’information entre des clients et des fournisseurs de services Web. Dans la section suivante, nous présentons les principes de base de la qualité de services dans les architectures SOA.

Notions générales sur la qualité de service (QdS)

Avec la prolifération des services Web, la notion de QdS émerge aujourd’hui. Son importance pour les fournisseurs et les clients de services devient de plus en plus importante. En parcourant la littérature, nous avons remarqué qu’il n’existe pas de consensus sur la définition de la qualité de service [12]. La recommandation ITU-X.902 [10] définit la QdS comme un ensemble d’exigences dans le comportement collectif d’un ou plusieurs objets. Dans le contexte des technologies de l’information et multimédia, la QdS a été définie par Vogel et al. [11] comme l’ensemble des caractéristiques quantitatives et qualitatives d’un système multimédia, nécessaires pour atteindre la fonctionnalité requise par l’application. On peut aussi dire [12] que la qualité de service représente l’aptitude d’un service à répondre d’une manière adéquate à des exigences, exprimées ou implicites, qui visent à satisfaire ses usagers. Ces exigences peuvent être liées à plusieurs aspects d’un service, par exemple : sa disponibilité, sa fiabilité, etc.

PRINCIPES DES CONTRATS DE QUALITE DE SERVICE DANS LES SOAS

Compte tenu de l’importance des services et de la dynamicité des systèmes dans les architectures orientées services, il est nécessaire de spécifier les relations qui existent entre fournisseurs et consommateurs de services. À la base, ces relations contractuelles ne sont pas réellement explicitées. Ensuite, des contrats (ou Service Level Agreement – SLA) sont justement définis pour expliciter et identifier les besoins et les engagements des différentes parties sur la réalisation des services. Ces contrats sont généralement bilatéraux et traduisent ainsi d’une façon formelle le fait que, d’un côté, les fournisseurs s’engagent à fournir des services aux qualités spécifiées à la condition que les directives de l’utilisation des services soient suivies et d’un autre côté, les consommateurs acceptent de respecter les directives d’utilisation pour pouvoir alors bénéficier des qualités de service garanties.

SLA : Définition

SLA (Service Level Agreement) est une expression anglaise qui peut être traduite par « contrat de qualité de Service » ou par « Engagement de qualité de Service », ou encore plus simplement « Convention de Service » [13]. Nous retenons qu’un SLA est un contrat définissant les engagements du fournisseur quant à la qualité de sa prestation et les pénalités engagées en cas de manquement. Cette qualité doit être mesurée selon des critères objectifs acceptés par les deux parties (client et fournisseur) comme par exemple, le temps de rétablissement du service en cas d’incident [14]. Un SLA contient donc un ensemble d’accords communs entre le client et le fournisseur sur les niveaux de qualité de la prestation de ce dernier.
Les SLA ne constituent pas un nouveau concept et sont déjà traditionnellement utilisés dans plusieurs domaines lorsqu’il s’agit, par exemple, de contractualiser la réservation de ressources. En revanche, ces contrats sont établis manuellement par des échanges et des signatures de documents papiers. Ainsi, un défi majeur dans les SOA réside dans l’automatisation du processus complet de contractualisation : de la création des contrats dans des formats traitables par la machine jusqu’à leur surveillance et leur gestion au cours de l’exécution des services, en passant par des mécanismes automatisés permettant de négocier ces contrats pour établir ou maintenir des formes d’accord.

Structure des accords de qualité de service

Un SLA est composé généralement de 3 sections [15] (voir Figure 2) :
i. La première section (Parties) contient les parties impliquées dans le contrat : les parties signataires (le fournisseur de service et son client) et les parties tierces qui participent à la surveillance de SLA.
ii. La deuxième section (ServiceDescription) présente la description des services. Cette partie contient les opérations du service, leurs messages d’entrée/sortie et l’encodage du transport de ces messages.
Elle contient aussi les paramètres de SLA représentant les variables de qualité de service qui vont être utilisées dans la spécification des obligations du contrat. Ces paramètres se basent sur des métriques évaluées par des directives de mesure. Ces dernières définissent comment les métriques sont mesurées. Le dernier élément (schedule) de cette deuxième partie du contrat spécifie la durée et la fréquence des mesures des qualités de service.
iii. La troisième section (Obligation) présente les obligations du contrat : sa période de validité, les conditions qui spécifient ces obligations et les actions à prendre en cas de non respect du contrat. Le SLA est accompagné d’une partie technique, appelée SLS (Service Level Specification) [125], qui définit les paramètres négociés entre les différents domaines afin de se mettre d’accord sur un niveau de QdS. Les principaux paramètres utilisés dans un SLA sont :
• Temps de service : Spécifie le temps pendant lequel la QdS négociée doit être garantie.
• Paramètres de QdS : Délai, gigue, taux de perte, bande passante.
• Profil du trafic : Taille des paquets.
• Traitement d’excès : Spécifie le traitement que le réseau applique aux paquets hors profils.
• Identification du trafic : Adresse IP source et destination, port source et destination, identification du protocole.
• Identification du client : Utilisée pour les fonctions d’authentification, d’autorisations et de calcul de coût (AAA : Authentication, Authorization, Accounting).
• Mode de négociation : Prédéfini ou non, c’est-à-dire que les paramètres de SLS sont contraints par le fournisseur ou prennent des valeurs quelconques.
• Intervalle de renégociation : L’intervalle de temps pendant lequel un SLS négocié ne peut être renégocié.
• Fiabilité : Temps d’inaccessibilité et temps de rétablissement d’un service suite à une panne.

L’établissement des accords de qualité de service

Bien que les contrats électroniques aient pour but de formaliser des accords acceptés mutuellement par les deux parties (fournisseurs et consommateurs de services) le processus d’établissement des contrats reste cependant bien souvent asymétrique [16] et contrôlé par les fournisseurs. Ce processus, sous sa forme la plus générale, se décompose selon la Figure 3 en :
– Fournisseurs de services qui créent des gabarits de contrats (template) définissant notamment la liste des services offerts et les niveaux de services associés et intègrent parfois les coûts financiers des services ainsi que des pénalités en cas de violation des termes du contrat. Ces gabarits de contrats sont envoyés aux consommateurs,
– Consommateurs qui sélectionnent les services et créent une instance de contrat. Ce contrat est renvoyé et soumis à validation par les fournisseurs.
Ainsi, les fournisseurs et les consommateurs peuvent entrer dans un processus de négociation basé sur des échanges successifs de tels documents qui expriment les contrats souhaités par les consommateurs et ceux acceptés par les fournisseurs. Bien évidemment, cela implique que les fournisseurs de services aient les capacités pour supporter et proposer différents types de services et que les deux parties puissent dialoguer durant ce processus de négociation. Par la suite, un ensemble de systèmes sont intégrés pour surveiller et gérer les contrats négociés lors de l’exécution des services.
Le cycle de vie habituel [18] appliqué à cette architecture est composé des phases suivantes (comme présenté dans la Figure 4) :
1. Le développement d’un modèle (template) du contrat
2. La négociation du contrat
3. L’implantation du contrat et son établissement
4. L’exécution du contrat et la surveillance des performances engagées
5. La terminaison ou la fin du contrat.

Table des matières

INTRODUCTION GENERALE
I. CONTEXTE DU TRAVAIL
II. PROBLEMATIQUE
III. OBJECTIFS
IV. CONTRIBUTIONS
V. EXEMPLE DE MOTIVATION
VI. ORGANISATION DU DOCUMENT
CHAPITRE I – ETAT DE L’ART : TRAVAUX RELATIFS AU CYCLE DE VIE DES CONTRATS DE QDS
I. INTRODUCTION
II. ARCHITECTURES ORIENTEES SERVICES
1. Qu’est ce qu’un service Web ?
2. Qu’est ce que une architecture orientée services ?
3. Notions générales sur la qualité de service (QdS)
III. PRINCIPES DES CONTRATS DE QUALITE DE SERVICE DANS LES SOAS
1. SLA : Définition
2. Structure des accords de qualité de service
3. L’établissement des accords de qualité de service
IV. MODELISATIONS DES ACCORDS DE QDS
1. Spécifications existantes des accords de QdS
1.1 WSLA [15]
1.2 WSOL [19]
1.3 SLAng [20]
1.4 Ws-agreement [21]
2. Bilan sur les spécifications existantes des accords de QdS
V. NEGOCIATION DES ACCORDS DE QUALITE DE SERVICE
1. Négociation : Définition et principe
2. Protocoles de négociation
2.1 Le protocole SrNP
2.2 Le protocole COPS-SLS
2.3 Le protocole DSNP
2.4 Le protocole NSLP
2.5 Le protocole Contract-Net
3. Projets existants de négociation
3.1 Le projet WS-agreement
3.2 Le projet BEinGRID
3.3 Le projet TrustCOM
3.4 Le projet NEXTGRID
4. Bilan des travaux existants sur la négociation des accords de QdS
VI. SURVEILLANCE DES ACCORDS DE QUALITE DE SERVICE
1. Surveillance : Définition et principe
2. Infrastructures de surveillance d’accords de QdS
2.1 WSLA
2.2 WSML
2.3 Cremona
2.4 Autres approches de surveillance de SLA
3. Bilan sur la surveillance des accords de QdS
VII. CONCLUSION
CHAPITRE II – ETAT DE L’ART : INTEGRATION DE LA SEMANTIQUE DANS LE CYCLE DE VIE DES ACCORDS DE QDS 
I. INTRODUCTION
II. LES ONTOLOGIES
1. Notions d’ontologies et de Web sémantique
2. Structure générale d’une ontologie
3. Objectif général d’une ontologie
4. Exemple d’une ontologie
III. MODELISATIONS DES ACCORDS DE QDS EN UTILISANT LES ONTOLOGIES
1.1 OWL-QoS
1.2 QoSOnt
1.3 SL-Ontology
1.4 WS-QoS
1.5 FIPA QoS
1.6 MOQ
1.7 Bilan sur la modélisation des accords de QdS
IV. NOTION D’INTENTION
1. Définition
2. Formalisation d’une intention
3. Exemple de représentation d’une intention
V. ALIGNEMENT DES ONTOLOGIES
1. Alignement : définition et principe
2. Techniques d’alignement
3. Approches existantes d’alignements
3.1 Anchor-PROMPT
3.2 S-Match
3.3 MAFRA
3.4 GLUE
3.5 QOM
3.6 ASCO
4. Bilan sur l’alignement des ontologies
VI. CONCLUSION
CHAPITRE III – CONTRIBUTIONS : APPROCHE SEMANTIQUE POUR LA NEGOCIATION ET LA SURVEILLANCE DES ACCORDS DE QDS
I. INTRODUCTION
II. PRE-REQUIS DE NOTRE APPROCHE DE NEGOCIATION D’ACCORDS DE QUALITE DE SERVICE
1. Proposition d’une modélisation des intentions du client : « ClientOnto »
2. Proposition d’une modélisation des offres des fournisseurs : « ProviderOnto »
3. Proposition d’un modèle de conversion des unités « UnitsOnto »
4. Proposition d’un modèle de SLA : « SLAOnt »
III. APPROCHE D’ALIGNEMENT DES INTENTIONS DU CLIENT AVEC LES OFFRES DU FOURNISSEUR
1. Génération des correspondances
1.1 Définition d’une correspondance
1.2 Modélisation d’une correspondance
1.3 Probabilité d’existence d’une correspondance
1.4 Génération des Correspondances directes
1.5 Génération des Correspondances indirectes
2. Raffinement des correspondances
2.1 Génération des adjacences
2.1.1 Définition et principe d’une adjacence
2.1.2 Modélisation d’une adjacence
2.1.3 Algorithme de génération des adjacences
2.2 Stabilisation des correspondances
2.2.1 Définition et objectif de la stabilisation
2.2.2 Algorithme de stabilisation
3. Vérification de compatibilité
3.1 Définition et objectifs
3.2 Algorithme de vérification de compatibilité structurelle
3.3 Algorithme de vérification de compatibilité de contraintes
4. Génération de contrats
4.1 Définition et principe
4.2 Processus de génération de contrat
5. Bilan des contributions sur la négociation des accords de QdS
IV. APPROCHE SEMANTIQUE DE SURVEILLANCE DES ACCORDS DE QDS
1. Architecture de surveillance des obligations de SLAOnt
2. Etapes de surveillance des accords de qualité de service
2.1 Principe de fonctionnement des services de mesures des métriques
2.1.1 Définition et principe des services de mesure des métriques
2.1.2 Algorithme de mesure des métriques
2.2 Principe de fonctionnement des services de mesures des paramètres de QdS
2.2.1 Définition et principe des services de mesures des paramètres de QdS
2.2.2 Algorithme de mesure des paramètres de QdS
2.3 Principe de fonctionnement des Services de surveillance des obligations de QdS
2.3.1 Définition et principe des services de surveillance des obligations
2.3.2 Algorithme de surveillance des obligations de QdS
3. Bilan des contributions sur la surveillance des accords de QdS
V. CONCLUSION
CHAPITRE IV – CONTRIBUTIONS : IMPLANTATION ET EVALUATION DE NOS APPROCHES DE NEGOCIATION ET DE SURVEILLANCE DES ACCORDS DE QDS
I. INTRODUCTION
II. CHOIX D’IMPLANTATION
1. Langage de programmation
2. Langages d’implantation des ontologies
3. Bibliothèques Java de gestion des ontologies
4. Mesures de similarités sémantiques et de proximité linguistiques
4.1 WordNet::Similarity
4.2 Choix de la mesure de proximité linguistique
4.3 Choix de la mesure de similarité sémantique
4.4 WordNet
5. Couches logicielles utilisées
III. CONCEPTION DE NOS OUTILS DE NEGOCIATION ET DE SURVEILLANCE D’ACCORDS DE QDS
1. Conception d’outil de négociation d’accords de QdS
1.1 Fonctions offertes aux utilisateurs
1.2 Génération de correspondances sémantiques
1.2.1 Génération des correspondances directes
1.2.2 Génération des correspondances indirectes
1.3 Raffinement des correspondances
1.3.1 Génération des adjacences
1.3.2 Stabilisation des correspondances
1.4 Vérification de compatibilité
1.5 Génération de contrats de qualité de service
2. Conception d’outil de surveillance d’accords de QdS
2.1 Fonctions offertes aux utilisateurs
2.2 Modélisation statique de notre outil de surveillance
2.3 Modélisation dynamique de notre outil de surveillance
IV. CAS D’ETUDES
1. Service de téléchargement d’une bibliothèque numérique de vidéos
1.1 Description des ontologies utilisées
1.2 Utilisation de notre outil de négociation de QdS
2. Fournisseur d’hébergement de services
2.1 Description des instances du contrat de QdS
2.2 Utilisation de notre outil de surveillance de QdS
V. ETUDE COMPARATIVE ET RESULTATS EXPERIMENTAUX
1. Situation de notre approche d’alignement dans les approches existantes
2. Situation de notre approche de surveillance dans les approches existantes
3. Résultats expérimentaux
VI. CONCLUSION
CONCLUSIONS ET PERSPECTIVES
BIBLIOGRAPHIE
PUBLICATIONS

Télécharger le rapport complet