Programmation orientée services 

Programmation orientée services 

La programmation orientée service [SH05] (SOC, Service Oriented Computing) est un paradigme de programmation qui utilise les services comme des constituants élémentaires à partir desquels sont réalisées des applications réparties. En particulier, afin de créer un nouveau service qui peut réaliser une tâche complexe que les services existants ne peuvent pas réaliser, une des solutions est de composer ces services. Par conséquent, l’architecture des services Web est une architecture orientée composant [MMM06] (SOA, Service Oriented Architecture). Les concepts de bases de cette architecture sont les trois éléments suivants : – Service fournisseur, – Service annuaire et – Service client. Les services fournisseurs sont des services qui proposent des fonctionnalités que d’autres services peuvent utiliser. Lorsque les services fournisseurs sont créés, le but est qu’ils soient accessibles par le maximum d’utilisateurs. Pour cela, il faut que ces services puissent être facilement retrouvés. En effet, les services sont répertoriés dans un service particulier appelé annuaire. Dans cet annuaire se trouve l’adresse et la description des services fournisseurs répertoriés. Les utilisateurs des services fournisseurs sont appelés services clients. Il existe différents problèmes concernant les services du modèle SOA. Parmi ces travaux nous citons : la description de services [CCMW01], la découverte de services [Dra01], la validation et le test de services [PBL08] et la composition de services [Ber05, MPT08]. Dans le cadre de cette thèse, nous sommes intéressée par l’étude de la complexité du problème de la composition. 

Les services et le problème de la composition de services

 Le problème de la combinaison des services, autrement appelé problème de la composition [BCGM06, PMBT05], constitue le foyer d’une intense activité de recherche. Ce problème peut être décrit comme suit : étant donnés un ensemble de services disponibles et un but, est-il possible de combiner les services disponibles afin de réaliser le but ? Pour avoir une description plus précise, il faut d’abord définir les services. Il existe différentes définitions pour les services [ACKM03]. Certaines sont plus générales que d’autres. Par exemple, dans certaines définitions, un service représente toute application accessible sur internet. Dans des définitions plus spécifiques, comme celle proposée par [JC], les services sont définis comme des applications basées sur le langage XML (Extensible Markup Language). Plus précisément, un service doit utiliser le langage WSDL (Web Services Description Language) pour sa description statique, il doit utiliser le protocole de communication SOAP (Simple Object Access Protocol) pour communiquer et il doit utiliser l’annuaire UDDI (Universal Description, Discovery and Integration) pour être répertorié et pour rechercher d’autres services. D’un point de vue formel, il existe aussi plusieurs représentations des services. Souvent, les services sont vus comme des automates finis. Dans ces automates, il est possible d’effectuer uniquement des actions de communication [PTBM05], d’exécuter uniquement des actions internes [BFDP08, BCGM06] ou d’exécuter les deux types d’actions [BCG+05]. Parfois, ces automates sont enrichis par l’ajout de conditions et d’effets sur les transitions [BCG+05]. Les réseaux de Petri sont également utilisés pour représenter formellement les services [HB03, MPPP02]. Par ailleurs, les réseaux de Petri permettent aussi la description des conditions et des effets pour les transitions. Dans d’autres approches, les services sont représentés par des axiomes de la logique linéaire [RKM04]. Par conséquent, la description formelle du problème de la composition est différente d’un formalisme à l’autre. Par exemple, lorsque les services sont des automates, le problème de la composition devient celui de l’équivalence entre un automate est un produit d’automate [BFDP08, MW08]. Lorsque  les services sont représentés par des axiomes, le problème de la composition consiste à prouver un séquent à partir d’un ensemble d’axiomes. Cependant, même si le formalisme choisi pour représenter les services est le même, les approches pour le résoudre ne sont pas forcément identiques. Par exemple, dans [PTBM05] et [BCG+05], les services sont formalisés par des automates, mais dans [PTBM05] les auteurs utilisent une méthode basée sur la planification pour résoudre le problème de la composition et dans [BCG+05], les auteurs utilisent une méthode basée sur la satisfaction d’une formule dans la logique dynamique propositionnelle (PDL). Ainsi, des techniques de résolution de différents domaines peuvent être appliquées afin de résoudre le problème de la composition. 

Notre approche 

En ce qui nous concerne, nous représentons les services par des automates communicants conditionnels CCA [BCF08a, BCF08b]. Ces automates sont capables d’exécuter des actions internes ainsi que des actions de communication. De plus, ils contiennent des préconditions et des effets sur les transitions. Notre modèle s’inspire du modèle COLOMBO [BCG+05]. Plus particulièrement, il utilise certaines de ses notions : – service client, – service but, – services disponibles et – service médiateur. L’objectif de la composition est d’utiliser les services disponibles afin de créer un service qui peut effecteur les tâches que le service client veut réaliser. La structure du service souhaité est représentée par le service but. Ce dernier communique uniquement avec le client. Quant au service médiateur, c’est celui qui sera synthétisé afin de réaliser le but. Plus précisément, le service médiateur peut effectuer uniquement des actions de communication. Par conséquent, afin de simuler les actions internes que le but effectue, il devra invoquer les services disponibles. En termes de niveaux d’abstraction, notre modèle se situe entre le modèle COLOMBO [BCG+05] et le modèle Romain [Ber05, BCGM06]. Effectivement, il est plus abstrait que le modèle COLOMBO par le fait de considérer des messages sans contenu et des actions sans paramètres. De plus, à la différence du modèle COLOMBO dans lequel les services partagent une base de données, dans notre modèle les services partagent un ensemble fini de variables propositionnelles. Toutefois, notre modèle est moins abstrait que le modèle Romain, car dans ce dernier les actions internes et les actions de communication ne sont pas distinguables. De plus, dans le modèle Romain, il n’existe ni de préconditions ni d’effets sur les transitions. Par conséquent, notre modèle est plus réaliste que le modèle Romain. Le problème de la composition que nous considérons est également inspiré du modèle COLOMBO et il est défini de la fa¸con suivante : Etant donn´ ´ es un service but, un service client et des services disponibles, déterminer l’existence d’un service médiateur tel que : le système composé du service but et du service client soit équivalent au système composé du service médiateur, du service client et des services disponibles. L’une des différences entre ce problème et celui décrit dans COLOMBO est le type d’équivalence considéré. En effet, dans notre modèle nous considérons : l’inclusion de traces, l’équivalence de traces, la simulation et la bisimulation. Tandis que, dans COLOMBO, l’isomorphisme est la relation d’équivalence considérée. L’isomorphisme entre les automates est une relation plus restrictive que les relations que nous avons citées, ci-dessus. L’isomorphisme peut être vue comme une égalité entre deux systèmes, modulo le renommage des états d’un des systèmes par les états de l’autre. Dans notre approche, l’objectif est de pouvoir exécuter les actions dans l’ordre exigé par l’utilisateur, mais pas forcément avec le même nombre d’états que le service but. Une autre différence réside dans le fait que dans COLOMBO les services considérés sont déterministes. En effet, toutes les actions effectuées par les services sont supposées observables. Ce qui n’est pas le cas dans la réalité. De plus, dans le modèle COLOMBO, des restrictions ont été considérées afin de résoudre le problème. Nous n’avons pas considéré ces restrictions, spécifiques aux services Web, car nous voulons apporter des résultats qui peuvent être appliqués dans d’autres domaines. Comme le domaine des systèmes multiagents en intelligence artificielle. Dans le Chapitre 2, nous donnons une comparaison détaillée de notre modèle avec le modèle COLOMBO. Nous verrons également plus en détail les différents formalismes utilisés pour représenter les services. Ainsi que les différentes approches utilisées pour résoudre le problème de la composition. Nous verrons à partir des résultats décrits que le problème de la composition n’est pas un problème facile à résoudre.