T H E S E - LIFL

32 Travaux sur la gestion de la Qualité de ServiceFigure 3.1: Modèle de mise en oeuvre des aspects AO4BPELNéanmoins ce travail requiert un moteur BPEL spécifique, ce qui en fait une solutioninexploitable par les autres plateformes. Par ailleurs l’utilisation d’aspects modularisantdu code BPEL est limitée du seul fait que le langage BPEL n’est pas un langagegénéraliste. Par conséquent, il n’est pas possible de rajouter de nouvelles préoccupationsexcepté en développant de nouveaux services Web qui intègreront ces préoccupations.Cette façon de procéder n’est pas aisée, n’offre pas de possibilités de garantir certainespropriétés avant l’exécution, et impose un couplage fort entre le moteur d’exécution etles services Web contenant la logique des préoccupations non fonctionnelles. En outre,si les outils BPEL proposent des modélisations sous forme de graphe pour permettred’écrire aisément du code BPEL, AO4BPEL requiert que l’utilisateur écrive lui mêmeson code. Enfin, AO4BPEL n’intègre pas la gestion des caractéristiques de QdS de typeperformance (temps de réponse, débit, etc.).3.2.2 DYNAMOIntroduction Ce travail [BGP05, BGP07, BG07] vise à apporter des solutions faceaux lacunes du langage BPEL4WS concernant la spécification et la mise en oeuvred’exigences non fonctionnelles dans les compositions de services. Pour cela, les auteursintroduisent deux nouveaux langages, « WSCoL » 3 et « WSRel » 4 qui ont respectivementpour but de permettre la définition, dans un processus BPEL, d’assertionsliées au monitoring, ainsi que de stratégies de réaction. Ces langages ne dépendent3. Web Service Constraint Language4. Web Service Recovery Language