Probleme de composition de services Web

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

Motivation : Composition centrée exigences des services Web

L’acceptation et la popularite croissantes de l’architecture AOS ont donne lieu a un ensemble d’opportunites. Dans le cadre de ce travail de these, la motivation qui anime notre inter^et pour l’architecture AOS est le developpement d’applications distribuees par composition de services Web. La composition de services est une opportunite seduisante puisqu’elle o re des avantages competitifs aux entreprises en leur o rant la possibilite de developper des applications a valeur ajoutee en assemblant des services deja existants.

De nombreux travaux de comites academiques et industriels ont aborde le probleme de composition de services Web en proposant des langages (par exemple BPEL [64], WS-CDL [63] et OWL-S [61]) et des formalismes (les reseaux de Petri [59], les machines de Mealy [9] et les machines d’etats [34]) divers. Il est toutefois constant de remarquer que tous ces travaux adoptent une vision \centree fonctions » de la composition en considerant les services comme des composant \logiciels ». L’inconvenient de cette vision est qu’elle est dediee aux developpeurs d’applications puisqu’elle se base sur des descriptions de \bas niveau » qui se concentrent sur des declarations purement techniques (comme les formats des messages de coordination, les types des parametres d’entree/sortie et le protocole Web utilise pour la communication). Toutefois, pour que l’architecture AOS soit transposee au niveau de l’entreprise, il est necessaire qu’une composition de services soit decrite en termes d’exigences que l’entreprise souhaite atteindre [49]. Ainsi, pour ^etre en phase avec le monde de l’entreprise, il est necessaire d’opter pour un changement d’echelle d’observation et adopter une vision \centree exigences » de la composition ou les services sont consideres comme des interactions \metiers ». Les descriptions des services sont exprimees en termes d’exigences et non plus en termes de fonctionnalites et ceci garanti un \haut niveau » d’abstraction qui renforce la variabilite et la reutilisation. En e et, ces descriptions comportent des variations d’usage et peuvent ainsi ^etre reutilises dans plusieurs autres compositions.

La vision centree exigences de la composition de services a fait l’objet de plusieurs travaux de recherche que nous pouvons classi er en trois categories. Nous trouvons des travaux qui ont opte pour : (i) une approche formelle pour l’expression des exi-gences [53], [93] et [83], (ii) une approche semi-formelle comme [1], [22], [80] et [81], et nalement (iii) une approche informelle comme [102] et [19]. Ces travaux s’interessent a proposer des solutions pour la decouverte et la composition de services logiciels a Problematique : Absence d’alignement entre les services metiers et les services logiciels dans le cadre de la composition de services Web partir des de nitions d’exigences. Neanmoins, les solutions qu’ils proposent sou rent de quelques limitations que nous detaillons dans ce qui suit.

Problematique : Absence d’alignement entre les ser-vices metiers et les services logiciels dans le cadre de la composition de services Web

Suite a notre etude des travaux precedents de la litterature, nous avons pu observer que les services metiers et les services logiciels sont traites d’une facon isolee dans le cadre de la composition. En e et, les services metiers ne peuvent ^etre mis en correspon-dance avec les services logiciels qui les realisent directement et automatiquement. Ceci peut entra^ner des discordances conceptuelles entre l’enonc des exigences decrivant les services metiers et des fonctionnalites de nissant les services logiciels.

Dans le cadre de ce travail de these, nous repondons a ce probleme principal concernant l’absence d’alignement entre les services metiers et les services logiciels dans le cadre de la composition de services Web et nous comblons les limitations listees ci-dessous.
{ Limitation 1. Traitement partiel de la variabilite. Le besoin de variabilite dans le cadre des applications logicielles a emerge a la suite d’un changement de comportement des utilisateurs qui ne veulent plus s’adapter aux logiciels mais qui preferent que ces derniers soient con gures selon leurs besoins [8]. Cet etat de fait a force les developpeurs a prendre en compte les exigences des utilisateurs. Leur objectif n’est plus reduit a l’augmentation de l’e cacit d’un logiciel mais a la proposition d’une solution generique qui couvre le plus grand nombre des besoins. Ainsi, la variabilite est devenue un facteur important dans le developpement des applications logicielles et plus particulierement des applications a base de services Web. La classi cation proposee par [42] est basee sur la distinction entre deux categories de variabilite : la variabilite essentielle et la variabilite technique. La variabilite essentielle represente le point de vue de l’utilisateur et s’interesse aux aspects lies a l’utilisation de l’application tandis que la variabilite technique represente le point de vue du developpeur et s’interesse aux aspects lies a la realisation de l’application. Suite a notre etude de la litterature qui relate au domaine de la composition de services Web, nous avons pu constater que les deux categories de la variabilite ont ete traitees d’une facon isolee et que la variabilite technique a suscite plus d’inter^et que la variabilite essentielle. En e et, nous trouvons que quelques travaux qui se sont focalises sur l’expression et la gestion de la variabilite essentielle..

Cependant, nous pensons qu’il est important de tenir compte des deux categories de la variabilite a n de garder une tracabilite entre les services metiers et les services logiciels qui les realisent. Cette tracabilite evite d’avoir des compositions de services rigides Problematique : Absence d’alignement entre les services metiers et les services logiciels dans le cadre de la composition de services Web et inadaptees aux exigences des utilisateurs.
{ Limitation 2. Negligence des exigences non-fonctionnelles. Les exigences non-fonctionnelles dans le domaine des services Web sont exprimees par le terme Qualite de Service QdS qui refere a diverses proprietes telles que la disponibilite, le temps de reponse, la securit et le debit [2]. La plupart des travaux comme [80], [102] et [19] se sont concentres sur l’expression des exigences fonctionnelles et ont neglig les exigences non-fonctionnelles. Toutefois, nous considerons qu’il est necessaire de tenir compte des exigences non-fonctionnelles qui contraignent la maniere dont l’application a base de services doit satisfaire les exigences fonctionnelles. En e et, devant l’accroissement incessant du nombre de services Web disponibles et la variabilite des besoins des utilisateurs, l’operation de composition peut engendrer di erents services composites qui o rent les m^emes fonctionnalites. Donc, c’est a la base d’un certain nombre de proprietes de QdS que nous pouvons choisir un service composite et pas un autre.

{ Limitation 3. Pas de decouverte et selection des services logiciels. La decouverte et la selection des services presentent un processus qui consiste a chercher dans l’annuaire les services logiciels qui repondent le mieux aux exigences fonctionnelles et non-fonctionnelles des utilisateurs. La plupart des travaux comme [93], [83], [1], [22], [80]et [81] proposent d’implementer les services logiciels qui realisent les exigences des utilisateurs. Ceci est en contradiction avec l’objectif principal de l’architecture AOS qui vise a reutiliser les services deja existants pour le developpement de nouvelles applications.
{ Limitation 4. Generation en bo^te noire du proced de coordination des services logiciels. La composition de services est mise en uvre moyen-nant un proced de coordination qui permet de speci er quels services doivent ^etre invoques, dans quel ordre et sous quelles pre-conditions. Deux types de coordination de services ont ete proposees : une coordination centralisee appelee orchestration et une coordination decentralisee appelee choregraphie [30]. Toutes des approches qui ont opte pour la vision centree exigences pour la composition de services n’explicitent pas le passage du modele des exigences au proced de coordination des services logiciels qui realisent ces exigences. La facon dont les services logiciels sont coordonnes et executes n’est pas claire et ce manque de transparence emp^eche toute comparaison ou amelioration des techniques d’alignement proposees.