Soutenance mémoire
Les paramètres de Qualité des Services Web
Introduction
Les services Web sont des technologies émergentes et prometteuses pour le développement, le déploiement et l’intégration des applications Internet. Dans ce chapitre, nous décrivons les Services Web en mettant en évidence la définition, les acteurs et les technologies des Services Web. Nous mettons aussi l’accent sur l’aspect non fonctionnel des services Web en présentant quelques paramètres de QoS. Nous terminons en donnant une vue générale de la composition des services Web et son cycle de vie, car nous nous intéressons dans cette thèse particulièrement à l’étape de sélection des services Web qui est une phase importante du processus de la composition.
Définition des services Web
Les services Web ont été proposés initialement par IBM et Microsoft, puis en partie standardisés par le consortium W3C (World Wide Web Consortium). Plusieurs définitions sont alors utilisées pour présenter la technologie des Service WEB. Nous citons, celles d’IBM et W3C
Définition – Service Web (Selon IBM 1).
Les services Web sont la nouvelle génération des applications web. Ce sont des applications auto-contenues, auto-descriptives et modulaires qui peuvent être publiées, localisées et invoquées depuis le web. Les services Web effectuent des actions allant de simples requêtes à des processus métiers complexes. Une fois qu’un service web est déployé, d’autres applications (y compris des services Web) peuvent le découvrir et l’invoquer.
Définition – Service Web (Selon W3C 2).
Un service Web est un composant logiciel identifié par une URI (Uniform Resource Identifier), et conçu pour supporter l’interaction interopérable de machine à machine sur un réseau. Il possède une interface décrite dans un format exploitable par la machine (WSDL : Web Service Description Langage). D’autres systèmes interagissent 1. IBM Web services tutorial. Online : http ://www-106.ibm.com/developerworks/webservices/. 2. www.w3c.org .en même temps que d’autres normes du Web. A partir de ces deux définitions on peut voir un service web comme étant une entité logicielle offrant une ou plusieurs fonctionnalités allant des plus simples aux plus complexes. Les services Web sont publiés, découverts et invoqués à travers le Web grâce à l’utilisation des protocoles de transport d’Internet comme infrastructure de communication et de standards ouverts : XML, SOAP, WSDL, UDDI. XML est utilisé pour représenter les données, SOAP pour transporter les données, WSDL pour décrire les services disponibles, et UDDI (Universal Description Discovery and Integration) pour lister les fournisseurs de services et les services disponibles.
Les types des services Web
Les services Web peuvent être classés selon leur type d’invocation, leur description ou encore leur granularité. 1. Selon le type d’invocation et le style de communication : On distingue trois grands courants : (a) Services Web de type RCP : ils peuvent être vus comme l’application de RPC de (Remote Procedure Calls), sur le Web. Ce genre d’implémentation de service, même si elle est assez commune, n’est pas très recomman .(b) Services Web basés sur REST : ce type de services est en vogue ces dernières années et gagne de plus en en plus en popularité. Ils suivent l’architecture REST (REpresentational State Transfer), qui a été proposée par Roy Fielding [Fielding, 2000] comme un modèle pour le Web. L’interface de ces services est limitée à quatre méthodes HTTP : GET, POST, PUT et DELETE. L’ensemble des opérations du service est mis en œuvre en définissant différentes ressources sur lesquelles ces quatre méthodes peuvent être appelées. Les services Web basés sur REST n’ont pas forcément besoin de traiter les documents XML, ils utilisent des formats plus légers comme JavaScript Object Notation (c) Services Web basés sur SOAP : ce type de services est le plus souvent utilisé dans l’industrie des sociétés commerciales du fait qu’elles aient construit de nombreux outils pour appuyer leur développement. SOAP est un protocole basé sur l’échange de messages XML pour les services Web, ce dernier sera décrit dans la section consacrée à la couche de communication des services Web
Selon leur description
(a) Services Web Syntaxiques : certains travaux qualifient aussi ces services par le terme ’classiques’. Ces derniers ne reposent que sur le profil fonctionnel sans intégration d’aucune autre description. La description syntaxique du profil fonctionnel contient les informations relatives aux méthodes proposées, leurs paramètres et les protocoles à utiliser. Ces informations permettent de faire l’appel du service(b) Services Web Sémantiques : un service Web est dit sémantique si sa description intègre, en plus de la description du profil fonctionnel, une dimension sémantique. Cette dimension englobe toute description complémentaire (du fournisseur, des objectifs du service Web, etc.) de la description fonctionnelle qui permet d’ajouter de l’information à la description classique du service Web. Cette information peut ensuite être traitée par des mécanismes (tels que l’inférence) afin d’en extraire de la connaissance.
Selon leur granularité
(a) Services Web atomiques : un service est dit atomique, isolé ou seul s’il ne fait appel à aucun autre service Web dans son exécution. (b) Services Web composites : un service est dit composite ou composé s’il combine les fonctionnalités de plusieurs services Web au sein d’un même processus métier. Les services Web sont composés pour répondre à une demande complexe qu’un seul service ne pourrait satisfaire. La composition des services Web sera traitée dans la dernière section de ce chapitre, car nous nous intéressons dans cette thèse plus particulièrement à la sélection des services formant cette composition
Les paramètres de Qualité des Services Web
Le sens de la Qualité de Service (QoS : Quality of Service) diffère d’une communauté à une autre. Dans la communauté des réseaux, la QoS peut traiter des questions comme les délais et les bandes passantes des liens du réseau, ou le nombre de paquets perdus dans les transmissions. Quand nous évoquons la QoS dans la communauté des services Web, nous raisonnons au niveau applicatif contrairement aux réseaux où les exigences en QoS concernent les couches basses des réseaux. Toutefois, même pour les paramètres QoS relatifs aux services web, là encore, nous trouvons aussi certains paramètres QoS relatifs au réseau. Par conséquent, il faut distinguer entre les paramètres QoS relatifs à l’application appelés aussi QoS de ’niveau application’ et ceux relatifs au réseau, tels que le paramètre délai de livraison de paquets, etc.
Le groupe de travail du W3C [Lee et al., 2003] a eu pour objectif d’identifier les paramètres de QoS applicables aux services Web. Ces paramètres QoS désignent l’aspect non-fonctionnel des services Web. Il n’existe pas un consensus bien précis au sujet de l’ensemble des paramètres QoS importants pour les services Web, mais la plupart des travaux de recherche, qui ont essayé d’identifier les paramètres QoS, ont pris en considération les paramètres définis par le W3C. Nous donnons ici une liste de certains de ces paramètres [Menascé, 2002], [Ran, 2003] les plus couramment utilisés par la communauté de chercheurs.
• Le coût (ou le prix) : désigne le prix que le client doit payer pour chaque invocation du service. Ce paramètre apparaît fréquemment dans les services Web commerciaux• La latence (aussi connue comme le temps de réponse) : ce paramètre est utilisé pour désigner le temps pris par un service pour répondre à une requête. Cela peut comprendre le retard causé par le réseau lors de l’appel au service Web. • Le débit : le débit d’un service représente le nombre de demandes que le service est en mesure de traiter dans un intervalle de temps donné. Il peut inclure le débit maximal ou une fonction décrivant comment le débit varie en fonction de l’intensité de charge. • La fiabilité (aussi connue comme le taux d’exécution avec succès) : ce paramètre désigne la capacité du service à accomplir sa fonction correctement pendant une période de temps spécifiée. Il peut être mesuré par le temps moyen entre pannes. • La disponibilité : ce paramètre désigne la probabilité que le service soit actif. Il peut être exprimé par le ratio : périodeactive/périodetotale. La période active représente le temps où le service est opérationnel en répondant aux demandes des clients. La période totale (périodeactive + périodeinactive), elle désigne la durée durant laquelle le client souhaite que le service soit actif.
• La sécurité : la sécurité d’un service Web comporte différents aspects assurant que les échanges de messages entre le client et le service soient sécurisés. Plus précisément c’est un regroupement d’un ensemble de qualités à savoir : la confidentialité, le cryptage des messages et le contrôle d’accès. • La réputation : c’est une mesure de la crédibilité du service. Elle dépend principalement des expériences d’utilisateurs finaux. Ces paramètres peuvent être classés, selon leur mesure, en trois catégories [Araban and Sterling, 2004].
1. Métriques annoncées par le fournisseur : métriques dont les valeurs ont été annoncées par le fournisseur. Exemple : le coût d’un service. 2. Métriques évaluées par le consommateur : métriques dont les valeurs ont été données par l’utilisateur. Exemple la réputation. 3. Métriques observables : métriques dont les valeurs ont été obtenues par la surveillance ou le test. Comme exemple : le temps de réponse ou la disponibilité. D’autres paramètres de QoS peuvent être trouvés dans la littérature, un grand nombre d’entre eux sont des variantes ou combinaisons des paramètres mentionnés ci-dessus.
Architecture en couches des services Web
Il existe deux types d’architectures pour représenter les services Web. La première est une architecture de base ou de référence qui permet de décrire les interactions et relations entre les trois acteurs principaux comme celle représentée dans la Figure La seconde architecture vient compléter et étendre la première pour prendre en considération des processus plus complexes comme celui de la composition. Elle est constituée de plusieurs couches superposées, d’où son nom. Différentes extensions de l’architecture de base ont été proposées dans la littérature. Le groupe architecture du W3C travaille activement à l’élaboration d’une architecture étendue standard.
Couche de transport des services
Cette couche regroupe les protocoles de transport de bas niveau, ces derniers servent à transporter les requêtes et les réponses échangées entre services. cole le plus utilisé est http, il est d’ailleurs recommandé par le consortium « Web Service Interoperability»), néanmoins d’autres implémentations peuvent utiliser d’autres protocoles comme HTTPS , SMTP , FTP , etc.
Couche de communication des services
Cette couche spécifie les protocoles d’échanges de documents XML entre le service web et ses clients, elle caractérise aussi le mode d’échange (s’il est bloquant ou non). Nous notons que selon le mode d’invocation, trois styles de services peuvent être distingués RPC, REST ou SOAP (cf. section 2.3). Les services Web SOAP restent actuellement les services les plus utilisés même si les services REST commencent à gagner du terrain. Tout au long de cette thèse, nous désignons par service web, les services Web SOAP, les deux autres ne font pas l’objet d’étude dans nos travaux. Nous présentons Le protocole SOAP qui est adopté comme un standard pour la messagerie entre les services We • SOAP (Simple Object Acces Protocol) SOAP [Gudgin et al., 2003] a été développé par Microsoft et IBM. C’est un standard accepté par le W3C en 2000. SOAP est un protocole de communication basé sur XML qui permet aux services Web d’échanger des informations dans un environnement décentralisé et distribué en utilisant HTTP/SMPT/POP comme protocole de communication, tout en étant indépendant des plateformes de programmation utilisées. SOAP définit un ensemble de règles pour structurer les messages envoyés. Notons que la spécification du protocole SOAP ne donne aucune indication sur le mécanisme d’accès aux services Web. Cette indication est du ressort du langage WSDL qui sera défini dans la section suivante. SOAP est constitué des éléments suivants : – Entête des protocoles : les entêtes de protocoles (e.g. HTTP, SMTP, etc). – Enveloppe : définit un cadre général pour exprimer le contenu d’un message. Elle est elle même composée de deux autres éléments. ∗ Entête : cet élément est optionnel. C’est un mécanisme d’extension qui fournit une manière de passer les informations en messages SOAP qui ne sont pas prises en compte directement par les applications. Il peut contenir, par exemple, des informations de sécurité (telles que les signatures électroniques), des informations transactionnelles, des informations de traçabilités,etc. ∗ Corps : est un élément obligatoire. Il contient les informations principales transmises dans un message SOAP. Il peut s’agir soit du nom de la méthode, avec les données correspondantes, ou d’un simple document XML pour le cas d’une requête. Le corps doit contenir aussi les valeurs de retour ou un message d’erreur pour le cas d’une réponse.
Couche de description des services
Cette couche permet de décrire le service web. Cette description concerne le profil fonctionnel/non fonctionnel du service web. Comme nous l’avons mentionné plus haut, les services Web peuvent être syntaxiques ou sémantiques, atomiques ou composites. La description est liée au type de service qui peut être, de ce fait : 1. une description syntaxique qui utilise des structures syntaxiques de type XML pour décrire les propriétés des services Web. Elle repose principalement sur le langage WSDL pour décrire la structure du service atomique. Elle repose aussi sur WS*-spécifications pour décrire le comportement au sein d’une composition. Nous citons la recommandation WS-CDL (Web Services Choreography Description Language) [Kavantzas, 2004] pour couvrir la description comportementale de la chorégraphie des services. Concernant le comportement du service lié à l’orchestration des services, OASIS (Organization for the Advancement of Structured Information Standards) propose le standard WS-BPEL (Web Services Business Process Execution Language) [Alves et al., 2006]. L’orchestration et la chorégraphie sont des modèles d’exécution de la composition. Ces deux modèles seront présentés dans la section composition des services Web. Nous résentons dans ce qui suit brièvement le standard WSDL.
• Web Services Description Language (WSDL) WSDL [Chinnici et al., 2007] fournit un modèle et un format XML pour décrire des Services Web. WSDL permet de faire une séparation entre la
description abstraite et concrète d’un service. Le niveau abstrait permet de répondre à la question : ’quelle’ fonctionnalité est fournie ?. Tandis que la partie concrète permet de répondre à la question : ’comment’ et ’ou’ celle-ci est offerte ?. Par conséquent, le niveau abstrait regroupe les informations pouvant être réutilisées (non spécifiques à un service), tandis que le niveau concret est constitué de la description des protocoles d’accès au service Web (information particulière à un service). Le niveau abstrait est utilisé principalement lors du processus de sélection. Il est constitué de types de données, des messages et des interfaces du document WSDL. Tandis que le niveau concret est seulement utilisé lors de l’invocation des méthodes du service Web. Il est constitué d’informations relatives aux ports d’accès et aux protocoles de communication ainsi que les liaisons de services (bindings). 2. une description sémantique qui est réalisée grâce à des annotations sémantiques de wsdl comme WSDL-S [Akkiraju et al., 2005] , SAWDL ou des ontologies de services comme l’ontologie OWLS [Martin et al., 2004] ou WSMO. Nous définissons dans ce qui suit la facette structurelle et comportementale relatives à la description syntaxique.
Couche de découverte des Services
Un service web doit être d’abord référencé pour qu’il puisse être par la suite découvert et utilisé par des clients ou organisations. Pour cela, il existe des annuaires pouvant être soit internes à l’organisation, soit universels. Nous décrivons dans ce qui suit le registre universel UDDI(Universal Description Discovery and Integration) UDDI [Clement et al., 2004] (pour la version 3.02) est un standard pour décrire un annuaire de services Web. En plus de la description, UDDI est aussi un registre permettant de publier et de découvrir des services Web. Un registre UDDI est un registre basé sur XML qui contient des informations et des métadonnées concernant les services Web. Trois types d’informations peuvent être décrits par ces registres XML : – Les pages blanches : décrivent les informations de contacts sur les entreprises. Elles sont utilisées pour trouver les services par contact car elles contiennent toutes les informations jugées pertinentes pour identifier l’organisation (telles que son nom, son adresse physique). – Les pages jaunes : décrivent des informations de classification de services. Elles sont utilisées pour trouver les services à l’aide des taxonomies car ces pages jaunes décrivent les services offerts par l’organisation, le type de services et les conventions d’utilisation de ces services – Les pages vertes : donnent des informations techniques (telles que l’accès) des services
Couche de composition des services
Cette couche sert a traiter le processus de composition qui permet d’agréger des services Web. La composition permet de construire de nouveaux services appelés services composites ou agrégats par assemblage de services déjà existants. Les services participant à la composition sont nommés services basiques ou élémentaires ou encore atomiques. En industrie, le concept de composition des services Web est réduit aux concepts d’orchestration et de chorégraphie. Dans ce contexte, les efforts industriels se sont concentrés sur la description de l’aspect comportemental des services Web composites, en développant des langages de composition spécifiques tels que WS-BPEL et WSCDL. Ces langages permettent de décrire des plans de composition (traduisant des comportements ou encore la manière dont les composants doivent être agrégés) pour qu’ils puissent, par la suite, être exécutés par des serveurs d’applications. Nous décrivons dans ce qui suit de manière brève les deux modèles de composition à savoir l’orchestration et la chorégraphie et nous donnerons les principes du langage BPEL (Business Process Execution Language).
Modèle comportemental du processus de la composition
Les propriétés comportementales décrivent la manière avec laquelle un service composite est construit. Ce comportement est lié au processus de la composition où l’information sur le comportement interne du service composite (la chorégraphie) et le comportement externe des services qui le composent (l’orchestration) est primordiale afin d’interagir avec le service composite. • Modèle d’orchestration L’orchestration décrit le comportement externe d’un service composite. Elle désigne la manière dont les services invoqués sont agrégés au niveau de la composition afin de fournir une fonctionnalité plus complexe. L’orchestration permet de décrire l’enchaînement des services selon un canevas prédéfini [Sadiq and Racca, 2003], et de les exécuter comme étant un ensemble d’actions à réaliser par l’intermédiaire de services Web. Dans ce type de modèle, toutes les communications sont routées par un processus central appelé moteur d’orchestration ou moteur de workflow Le moteur d’orchestration aussi appelé ’coordinateur’ prend le contrôle de tous les services web impliqués et coordonne l’exécution des différentes opérations des services composants qui participent dans le processus. Les services composants ne doivent pas être modifiés pour exécuter le workflow. Un exemple typique de langage d’orchestration est WS-BPEL [Jordan et al., 2007] (pour la version 2.0). • Modèle de chorégraphie Contrairement à l’orchestration , il n’existe pas un coordinateur dans la chorégraphie, elle est basée sur la collaboration entre les services weboù chaque partie de la composition possède un contrat ou des accords avec le reste des services qui dictent la manière de collaborer.
Langage BPEL
Plusieurs langages de composition de services ont été proposés dans la littérature, mais un seul d’entre eux est devenu le formalisme le plus utilisé, c’est le standard BPEL ou BPEL4WS [Andrews et al., 2003] (pour la version 1.0) ou [Jordan et al., 2007] (pour la version 2.0). BPEL est basé sur XML et sur les Workflows. Il permet de modéliser les processus métiers en terme d’orchestration, en décrivant le flux de données (les variables) et le flux de contrôle (les activités simples et composées, les partenaires…), son but est de créer une fonctionnalité complexe qui réutilise les composition. Ce langage distingue les processus abstraits des processus exécutables. Le processus abstrait décrit les interactions publiques de messages entre les services web composants sans obligation d’indiquer le comportement interne de chacun d’eux. Par opposition, le processus exécutable montre l’ordre d’exécution des activités, des services invoqués, des messages échangés et des mécanismes de gestion des erreurs potentielles. En d’autres termes, il s’agit du moteur de l’orchestration donnant une représentation indépendante des interactions entre les services composants. Deux catégories d’activités peuvent être distinguées dans bpel, les activités primitives et les activités structurées. Les activités primitives (Receive, Reply, Assign, Throw et Wait) sont des activités simples utilisées pour décrire comment le processus effectué par le service Web composite doit réagir vis-à vis des messages échangés. Par ailleurs, les activités structurées (Sequence, Flow, while Switch ou Split) sont des activités complexes qui combinent plusieurs activités primitives pour décrire différents types de branchement dans un processus.
Couche de qualité de services
Il n’existe pas de langage dédié exclusivement à la spécification de la QoS des services web. Cependant, il est nécessaire d’avoir une spécification claire et nonambigüe de la QoS du service afin de permettre leur évaluation. Deux possibilités sont offertes pour faire cette spécification
L’extension des langages de description des services par la QoS
Les langages de description de service comme UDDI et WSDL ne concernent que les aspects fonctionnels du service, de nombreuses propositions ont été faites pour renforcer ces spécifications afin de permettre la description des paramètres QoS du Une des contributions les plus en avant, vient du groupe ouvert OASIS. Le groupe a proposé la prolongation du WSDL par la QoS appelée WSQDL (Web Service Quality Description Language). Nous trouvons aussi, l’extension de WSDL nommée Performance-enabled WSDL (P-WSDL) [D’Ambrogio and Bocciarelli, 2007] et l’extension d’UDDI nommée (UX) [Chen et al., 2004]. Dans ces deux formalismes, la QoS d’un service est modélisée comme un tuple de paramètres de QoS, en spécifiant une valeur (ou un intervalle de valeurs) pour chaque paramètre.
Utilisation des contrats de QoS
On parle aussi de Service Level Agreements (SLA), les contrats sont des accords conclus entre le fournisseur et le client d’un service concernant la QoS du service. Les contrats peuvent préciser les obligations du fournisseur et du client. Par exemple, un contrat peut dire que “à condition que le client fasse au plus cinq demandes par seconde, le fournisseur assure que ces demandes soient traitées en moins de 100 millisecondes”. La première partie de cette clause est une obligation que le client doit respecter et la seconde est une obligation du fournisseur. Un contrat peut avoir plusieurs clauses de ce genre, qui décrivent ensemble la QoS du service. Les contrats sont généralement négociés en off-line, avant que le service ne soit appelé par le client.
Toute méthode de gestion de QoS impliquant des contrats est accompagnée par des techniques de monitoring, pour veiller à ce que les obligations dans le contrat soient respectées. WSLA [Keller and Ludwig, 2003] et WS-Agreement [Andrieux et al., 2007] sont deux cadres répandus pour la spécification des contrats pour les services Web.
La composition et les services web composites
La composition de services Web (WSC : Web Service Composition) est un processus complexe qui va de la découverte des services jusqu’à leur composition pour répondre à une requête particulière. [Casati and Shan, 2002] définissent la composition des services Web comme la capacité de constituer de nouveaux services Web composites à valeur ajoutée en combinant des services Web existants et probablement offerts par différents fournisseurs. [Benatallah et al., 2005], quant à eux, considèrent la composition des services Web comme un moyen efficace pour créer, exécuter et maintenir des services qui dépendent d’autres services. [Martin et al., 2004] considèrent la composition comme le processus de sélection, de combinaison et d’exécution de services en vue d’accomplir un objectif donné. Nous pouvons définir, de façon générale, la composition de services Web comme étant un processus complexe qui consiste à trouver des composants appropriés, de les sélectionner, de les combiner, et de fournir des informations d’ordre comportemental renseignant sur leur orchestration ou chorégraphie en vue de les rendre exécutables. Le résultat de cette composition est un service web composite faisant interagir un ensemble de services web afin de satisfaire la requête de l’utilisateur qui ne peut l’être par un service atomique.
Nature de la composition des services
La combinaison des services web atomiques, en vue de répondre à une requête complexe, peut être réalisée de manière statique ou dynamique avec un degré d’automatisation plus au moins différent. Ces critères permettent d’identifier la nature de la composition de services.
Statique vs. dynamique
Dans la méthode statique, la combinaison des services Web est réalisée à la phase de conception du service composite. Les services Web sont reliés entre eux, avant d’être déployés. Dans ce genre d’approche, la substitution ou la modification d’un service composant nécessite d’apporter des modifications au niveau de la conception du service composite. De ce fait, ce type de composition est plus adéquat pour les environnements qui ne sont pas sujet à des changements rapides dans le temps. Contrairement à l’approche statique, la composition dynamique permet de réalise la combinaison des services Web au moment de l’exécution de la requête. L’approche de composition dynamique permet de sélectionner et combiner dynamiquement les services à partir des annuaires de services Web, tout en tenant compte des contraintes de l’utilisateur.
Manuelle vs. semi-automatique ou automatique
En dehors de l’aspect statique ou dynamique de la composition, un autre aspect peut définir la nature d’une composition en se basant sur le degré de participation de l’utilisateur dans le schéma de composition des services Web. Le degré de participation de l’utilisateur détermine le degrés d’automatisation de la composition qui peut aller de la composition manuelle à celle totalement automatisée. La composition manuelle suppose l’intervention totale de l’utilisateur sans l’intervention d’outils spécialisés. L’utilisateur se servira d’un simple éditeur texte pour programmer toutes les étapes du processus de la composition. Ce type de composition exige de l’utilisateur qu’il ait le profil développeur, faute de quoi, la composition devient une tâche fastidieuse où d’importants efforts sont à fournir de la part d’un utilisateur novice. Par opposition à la composition manuelle, la composition totalement automatique ne requiert pas l’intervention de l’utilisateur et prend en charge tout le processus de composition et le réalise automatiquement. L’approche semi-automatique est un compromis entre l’approche manuelle et automatique. Elle permet à l’utilisateur de composer les services en s’appuyant sur des outils dédiés. Cette façon de faire permet à l’utilisateur de garder un certain contrôle et de superviser le processus de composition sans qu’il ait pour autant un profil de programmeur en s’appuyant sur l’assistance fournie par les outils graphiques.
Techniques de composition des services web
Les deux courants principaux dans les approches de WSC sont : les approches à base de workflow et les approches à base de planification en intelligence artificielle
Composition à base de Planification en intelligence artificielle
Dans les cas de WSC à base de planification, la composition de services est vue comme un problème de planification. Généralement, un problème de planification AI [Russell et al., 2003] est défini par les éléments suivants : • la description de l’état initial(S0) ; • la définition de l’état (S) qui est une description de l’ensemble des états possibles. • l’état final ou l’état but (G) que l’on souhaite atteindre. • l’ensemble des actions possibles (A) qui permettent le changement d’états. • l’ensemble des transitions d’états possibles(R). Il s’agit de trouver l’ordre des actions qui transformeront l’état initial à l’état final. Dans le domaine de SWC, un service composite est représenté comme un état final qui doit être atteint et les services candidats sont représentés comme l’ensemble des actions qui peuvent transformer les états. À la fin d’un exercice de planification réussi (l’existence d’une composition), un plan est produit. Ce plan constitue les services Web choisis et l’ordre de leur exécution de telle façon qu’ils produisent la fonctionnalité exigée.
Composition à base de workflow
Les méthodes à base de workflows utilisent le principe qu’un service Web composite peut être considéré conceptuellement comme similaire à un Workflow. Par analogie à un workflow d’activités, un service composite correspond notamment à un ensemble de services atomiques ou composites interconnectés. De ce fait, l’exécution d’un service Web composite s’avère similaire à l’exécution d’un Worfklow dont les mécanismes assurent la flexibilité, l’adaptation et l’intégration de processus automatiques. Les frameworks de composition fondés sur la technique de Workflows ont été les premières solutions proposées pour la composition de services Web, ils peuvent être statiques ou dynamiques. Dans le cas statique, l’utilisateur établit manuellement un modèle abstrait des tâches, en plus des dépendances. (i.e. le flux de contrôle, le flux de données, ..etc). Chaque tâche contient une clause ou question qui est employée pour rechercher le service concret qui l’accomplit. Ce travail est fait pendant la conception. Durant l’exécution, le système de composition instancie chaque tâche, en cherchant un service concret. La construction des schémas de composition de type statique s’appuie généralement sur des langages de description comportementale pour préciser les interactions entre fournisseurs de services Web et leurs clients. Nous citons à titre d’exemples les langages tels que BPEL [Jordan et al., 2007], ou BPMN [Group et al., 2006]. Par contre, les méthodes à base de workflows dynamiques génèrent les graphes de tâches instanciées à la volée (pendant le runtime). La composition à base de workflows dynamiques crée le modèle de tâches et l’instanciation des services de façon automatique. Cette composition est qualifiée comme étant orientée processus ou comportement [Rao and Su, 2004], tous les services Web considérés possèdent des états (statefull web services). Contrairement aux services web sans états (stateless web services), dont le schéma d’interaction est trop simplifié (i.e. de type requête réponse), les services web avec états ont une interaction complexe, et les résultats finaux ne sont pas complètement prévisibles (non déterministes). Cette interaction est généralement modélisée avec des systèmes formels, tels que les automates d’états finis, les réseaux de petri,. . . ,etc. ) [Lécué, 2008]. L’interaction d’un service avec état représente un protocole multi-phases, qui peut englober des actions internes, des échanges de messages avec les partenaires, des accès aux bases de données. L’intérêt des méthodes formelles (systèmes formels) est de donner la possibilité de vérifier automatiquement des propriétés d’un système (code logiciel, modèle conceptuel,. . . ,etc.). Ils peuvent être adoptés pour générer les workflows dynamiques. Ils peuvent aussi vérifier et prouver la compatibilité de la composition avec les besoins de l’utilisateur. Généralement, les compositions à base de planification AI ne reposent pas sur une vue abstraite de la composition à l’exception faite des travaux de [McIlraith and Son, 2002]. Au contraire, cette vue abstraite de la composition est un élément clé dans les approches WSC basées workflow. Nous considérons dans cette thèse, la phase de sélection d’une composition basée sur les workflows. Pour cela, nous définissons dans la section suivante le cycle de vie d’une composition qui repose sur une solution typiquement workflow.
Cycle de vie d’une composition
La composition est un processus qui passe par plusieurs étapes. Nous présentons dans la figure 2.5 un cycle de vie qui montre l’enchainement des étapes d’une composition basée workflow inspirée du cycle de vie présentée dans [Moghaddam and Davis, 2014] où la vue abstraite et concrète d’une composition est mise en évidence. Dans ce cycle de vie, la première étape est la spécification des besoins. Ces besoins sont définis sous forme de préférences fonctionnelles et non-fonctionnelles (QoS) ; elles concernent les préférences des utilisateurs par rapport aux services demandés. Les préférences sont décomposées (semi) automatiquement dans un processus abstrait (workflow) qui correspond à la composition abstraite. Cette dernière comprend un ensemble de tâches, chacune représente une fonctionnalité distincte. Les Qualités de Service (QoS) pour le BP aussi bien que pour chaque tâche participante sont aussi spécifiées. Durant l’étape de découverte, les services Web concrets qui correspondent aux exigences fonctionnelles et non fonctionnelles des tâches sont localisées. La localisation des services est faite à travers des recherches effectuées dans des registres tels que UDDI ou l’API ’programmable web’ 4 cipantes les services correspondants. À cette étape, il est très probable que plus d’un service candidat soit trouvé pour chaque tâche avec des attributs de QoS différents. La sélection de services Web est l’étape qui vient juste après la découverte. À cette étape, une variété de techniques est proposée par la communauté de recherche pour aider le demandeur de service à choisir des services selon les exigences indiquées. Après avoir trouvé les services candidats pour toutes les tâches et lier chaque tâche à son service Web choisi, le service composite concret est créé. Pendant l’étape d’exécution, une instance du processus est créée en exécutant le service composite. La dernière étape de monitoring permet de contrôler le processus continuellement pour de nouvelles réponses en cas d’un quelconque échec (service indisponible) dans le but de maintenir le bon déroulement de la composition. La phase de la sélection des services, est considérée comme une étape fondamentale dans le cycle de vie de la composition. Elle fait l’objet de beaucoup de recherches par la communauté SOC (Service Oriented Computing). Elle à été adressée à deux niveaux : (i) pour une seule tâche ; (ii) pour le workflow en entier (la composition). La problématique de la sélection est au cœur des travaux de cette thèse. Le prochain chapitre fera l’objet d’étude et d’analyse de la problématique de la sélection des services web.
Conclusion
Nous avons présenté dans ce chapitre, une vue d’ensemble des services web tout en relatant leurs technologies et leur fonctionnement. Ces technologies améliorent l’intégration et l’interopérabilité entre services à travers l’infrastructure Web en utilisant différents standards XML : SOAP pour l’échange de messages, WSDL pour la description de services et UDDI pour la publication et la découverte de services Web. Nous avons abordé aussi l’aspect non fonctionnel des services web qui est défini par les paramètres QoS. Nous avons enfin consacré la dernière section à la composition des services Web. Cette dernière permet de combiner des services existants pour former de nouveaux services plus élaborés. Nous nous sommes intéressés plus particulièrement à la composition qui se base sur les workflow. Nous avons détaillé le cycle de vie de ce type de composition dans le but de mettre en évidence la phase de sélection. Cette phase est une étape importante dans la composition des services Web et constitue une problématique de recherche majeure dans la communauté SOC.
|
Table des matières
Remerciements
Résumé
Sommaire
Table des figures
Liste des tableaux
Liste des Algorithmes
Liste des abréviations et des sigles
1 Introduction générale
1.1 Contexte
1.2 Objectifs et problématiques
1.3 Contributions
1.4 Organisation du rapport
Partie I : Etat de l’art
2 Technologies des services Web
2.1 Introduction
2.2 Définition des services Web
2.3 Les types des services Web
2.4 Les paramètres de Qualité des Services Web
2.5 Architecture en couches des services Web
2.5.1 Couche de transport des services
2.5.2 Couche de communication des services
2.5.3 Couche de description des services
2.5.4 Couche de découverte des Services
2.5.5 Couche de composition des services
2.5.5.1 Modèle comportemental du processus de la composition
2.5.5.2 Langage BPEL
2.5.6 Couche de qualité de services
2.5.6.1 L’extension des langages de description des services par la QoS
2.5.6.2 Utilisation des contrats de QoS
2.6 La composition et les services web composites
2.6.1 Nature de la composition des services
2.6.1.1 Statique vs. dynamique
2.6.1.2 Manuelle vs. semi-automatique ou automatique
2.6.2 Techniques de composition des services web
2.6.2.1 Composition à base de Planification en intelligence artificielle
2.6.2.2 Composition à base de workflow
2.6.3 Cycle de vie d’une composition
2.7 Conclusion
3 La sélection des services Web dans une composition à base de QoS
3.1 Introduction
3.2 Exemple représentatif du problème QoSWSC
3.3 Analyse et définition du problème QoSWSC
3.3.1 Modélisation multi-objectif vs. mono-objectif
3.3.2 Stratégie de sélection locale vs globale
3.3.3 Complexité du problème QoSWSC
3.3.4 Formulation du problème QoSWSC
3.4 Défis du problème QoSWSC
3.4.1 La scalabilité
3.4.2 Le passage du workflow au plan d’exécution
3.4.3 Les fonctions d’agrégation
3.4.4 Définition des poids d’attributs QoS
3.5 État de l’art des travaux sur le problème QoSWSC
3.5.1 Approches exactes
3.5.2 Approches heuristiques (approximatives)
3.5.3 Approches méta-heuristiques
3.5.4 Approches basées sur les techniques de bases de données
3.6 Synthèse
3.7 Conclusion
4 La sélection des services Web basée sur les méta-heuristiques
4.1 Introduction
4.2 Principe et classification des méta-heuristiques
4.2.1 Les méta-heuristiques à base de solution unique
4.2.2 Les méta-heuristiques à base de population de solutions
4.2.2.1 Les algorithmes évolutionnaires
4.2.2.2 Les algorithmes basés sur l’intelligence par essaim
4.2.3 Les méta-heuristiques hybrides
4.3 État de l’art des méta-heuristiques appliquées au problème QoSWSC
4.4 Synthèse
4.5 Conclusion
5 La sélection des Services Web basée sur les techniques orientées bases de données
5.1 Introduction
5.2 Concepts de bases et définitions
5.2.1 Exemple introductif
5.2.2 Le concept Skyline
5.2.3 Concept de Top-k dominating
5.3 Etat de l’art
5.3.1 Travaux sur Skyline et Top-k dominating
5.3.2 Travaux sur la sélection des services web utilisant Skyline et/ou Top-k dominating
5.4 Synthèse
5.5 Conclusion
Partie II : Contributions
6 Approches proposées
6.1 Introduction
6.2 La sélection locale des services web basée sur les techniques orientées bases de données
6.2.1 Exemple illustratif
6.2.2 Proposition 1 : La séléction des Top-k Services basée sur la dominance floue
6.2.2.1 Formalisation du problème
a) Normalisation des paramètres QoS
b) Fuzzification de la relation de Pareto dominance
6.2.2.2 Algorithme de Top-k services basé sur la dominance floue
6.2.3 Proposition 2 : la sélection des services Skyline basée sur la dominance floue
6.2.3.1 Skyline vs. α-dominated-Skyline d’une classe de services
6.2.3.2 Algorithme de calcul des services Skyline α-DSkyS
6.3 La sélection des services web basée sur les méta-heuristiques
6.3.1 Motivations
6.3.2 Formalisation du problème
6.3.2.1 Composition abstraite vs. concrète
6.3.2.2 Les propriétés QoS d’une composition
6.3.2.3 Les contraintes de qualité globales
6.3.2.4 La fonction objectif
6.3.3 Proposition 1 : Adaptation de la métaheuristique SOMA au problème QoSWSC
6.3.3.1 L’algorithme QoS-SOMA
a) Initialisation
b) Création du vecteur de perturbation
c) La création de la séquence des sauts et la construction
des solutions d’essais
d) Mise à jour de la population
e) Itération
f) Migration
6.3.3.2 Exemple illustratif
6.3.4 Proposition 2 : Optimisation locale de l’algorithme QoS-SOMA par la dominance floue
6.3.5 Proposition 3 : La sélection des services web basée sur la recherche Tabou et calcul
6.3.5.1 La phase 1 : la sélection locale
6.3.5.2 La Phase 2 : l’optimisation globale par la recherche Tabou
6.4 Conclusion
7 Implémentation et expérimentations
7.1 Introduction
7.2 Présentation du système de sélection des services web : SoS-QoS
7.2.1 Module de sélection locale (M1)
7.2.2 Module de sélection globale (M2)
7.3 Implémentation du système SoS-QoS
7.4 Corpus utilisés
7.4.1 Base de test 1 : La base réelle ’QWSDataset’
7.4.2 Base de test 2 : La base synthétique
7.5 Expérimentations
7.5.1 Performances de l’approche de sélection locale des Top-k services
7.5.1.1 Simulation 1 : en variant ε and λ
7.5.1.2 Simulation 2 : en variant d and n
7.5.2 Performances des approches de sélection globale
7.5.2.1 Comparaison de QoS-SOMA avec FQoS-SOMA
7.5.2.2 Comparaison de QoS-SOMA, FQoS-SOMA avec PSO
7.5.2.3 Comparaison de QoS-SkyTabou avec QoS-Tabou
7.6 Conclusion
8 Conclusion et perspectives
8.1 Synthèse
8.2 Perspectives
Liste des publications
Bibliographie
Télécharger le rapport complet
