Modélisation et Test Fonctionnel de l’Orchestration de Services Web

Ces dernières années ont vu l’émergence d’architectures logicielles fondées sur les services qui visent à mettre en place des processus métier performants ainsi que des systèmes d’information constitués de services applicatifs indépendants et interconnectés. Ces architectures sont connues sous le nom d’Architectures Orientées Services (SOA) [2]. Elles facilitent l’exposition, l’interconnexion et la réutilisation d’applications à base de services. Ainsi, de nouveaux services peuvent être créés à partir d’une infrastructure informatique de systèmes déjà existante. Ces services peuvent être utilisés par des processus métier ou par des clients dans différentes applications.

Les services Web sont la réalisation la plus importante d’une architecture SOA. Ce sont des applications auto descriptives, modulaires et faiblement couplées fournissant un modèle simple de programmation et de déploiement d’applications. Ils reposent principalement sur des technologies basées sur SOAP pour la structure et le contenu de messages échangés entre services, WSDL pour la description des services, UDDI pour la découverte des services et BPEL pour leur composition.

La composition de services Web est au cœur des architectures SOA puisque elle supporte la construction de services, dits composés ou composites, à partir de fonctionnalités de base (i.e. services de base). Elle a pour but la réutilisation des services (simples ou composés). L’exécution d’un service composé implique des interactions avec les services partenaires en faisant appel à leurs fonctionnalités. On peut distinguer deux méthodes de composition de services Web :
– Orchestration de services, qui décrit la manière dont les services Web peuvent interagir ensemble au niveau des messages, incluant l’ordre d’exécution des messages et la logique métier. Dans l’orchestration, un seul processus, appelé orchestrateur, est responsable de la composition et contrôle les interactions entre les différents services. Cet orchestrateur coordonne de manière centralisée les différentes opérations des services partenaires qui n’ont aucune connaissance de cette composition.
– Chorégraphie de services, qui décrit une collaboration entre services pour accomplir un certain objectif. Elle se ne repose pas sur un seul processus principal. La chorégraphie est une coordination décentralisée où chaque participant est responsable d’une partie du workflow, et connaît sa propre part dans le flux de messages échangés.

BPEL s’est imposé depuis 2005 comme le langage standard OASIS [3] d’orchestration de services Web. Il est largement utilisé dans le cadre de la mise en œuvre d’une architecture orientée services. Il se caractérise par rapport aux autres langages par sa gestion des exceptions (fautes et événements), l’exécution parallèle des activités et la synchronisation des flots, son mécanisme de compensation, et sa gestion de la corrélation des messages.

BPEL permet de décrire un processus exécutable décrivant une orchestration de services ou un processus abstrait spécifiant les échanges de messages entre différents partenaires. Il s’appuie sur le langage WSDL puisque chaque processus BPEL est exposé comme un service Web via une interface WSDL. Il utilise les opérations, les données ainsi que les liens des partenaires décrits dans son interface WSDL.

Les activités de validation et de vérification [4] sont des activités visant à assurer qu’un système informatique développé satisfait bien les besoins exprimés et/ou les exigences de qualité requises. La vérification consiste à établir l’exactitude d’une spécification et/ou d’une implantation d’un système. Elle répond à la question : développe-t’on bien le système ? La validation de logiciel a pour but de répondre à la question : développe-t’on le bon système ? Elle se réfère aux besoins fonctionnels de départ et aux exigences globales de qualité. Le test est une activité de vérification représentant une tâche importante dans le processus de développement d’un système. Son objectif majeur est de concevoir des tests permettant de découvrir systématiquement différentes classes d’erreurs avec un minimum de temps et d’efforts, et de démontrer que certaines fonctionnalités sont bien atteintes par rapport aux attentes.

Nécessité d’une modélisation formelle de la composition de services L’utilisation de BPEL facilite la mise en œuvre de la composition de services. Toutefois, BPEL est un langage exécutable basé sur XML, et doté de plusieurs mécanismes de gestion de corrélation de messages, d’exceptions, de terminaison et de compensation. En outre, BPEL est critiqué pour sa complexité et l’absence d’une sémantique précise. Pour toutes ces raisons, il est nécessaire d’avoir une modélisation formelle de la composition de services. Cette modélisation permettra alors d’appliquer des méthodes formelles pour tester les services composés. Cependant, cette modélisation doit être temporisée pour pouvoir décrire les propriétés temporelles de la composition (e.g. temps d’attente, transactions contextuelles de longue durée). Concernant la description BPEL d’un service composé, le modèle formel doit être capable de décrire les interactions (synchrones ou asynchrones) entre les différents services participants dans la composition, les données échangées, la gestion de la corrélation de messages, la gestion des exceptions et de la terminaison des activités. De nombreux modèles ont été proposés pour la modélisation de l’orchestration des services ; certains modèles ne sont pas temporisés et/ou ne peuvent décrire qu’une partie de la sémantique de BPEL. En outre, ils ont été utilisés pour l’analyse, la vérification, la découverte ou le monitoring des services composés, et ne sont pas forcément bien adaptés au test (de conformité).

Nécessité du test de la composition de services Le test de services Web, en particulier de services composés, pose de nouveaux défis étant donné les caractéristiques spécifiques de cette composition de services : gestion des transactions de longue durée (synchrones ou asynchrones), complexité des données et de leur transformation, gestion des exceptions (fautes et événements), corrélation des messages, etc. Différentes approches ont été proposées pour le test de la composition de services Web : test de l’interface WSDL, test structurel (boîte blanche) et test fonctionnel (boîte noire). Le test de l’interface WSDL [5] d’un service Web consiste à considérer un service (simple ou composé) comme une boîte noire. Ce test peut s’avérer incomplet pour le test de la composition puisque il ne prend pas en compte les interactions entre le service composé sous test et ses différents partenaires ni l’enchaînement des opérations WSDL ; seul le client du service composé est pris en compte. Quant au test boîte blanche, les approches proposées testent BPEL comme étant un langage (d’orchestration) et non pas une spécification de la composition. Ce test a en plus besoin du code BPEL décrivant l’orchestration de services. Certaines approches proposent une plateforme de test mais sans aucune automatisation de la génération de cas de test. Alors que d’autres travaux proposent de tester une description BPEL par des techniques de model checking tout en dérivant automatiquement une suite de test selon certains critères de couverture. Notre approche de test boîte grise se base sur une spécification de référence de l’orchestration. Elle est différente mais complémentaire aux autres approches citées ci-dessus. D’une part, à la différence du test boîte noire, notre approche prend en compte les interactions entre le service composé et ses services partenaires. D’autres part, elle ne considère que le flot de contrôle et les échanges de messages entre services, au contraire du test boîte blanche qui vise, entre autres, à tester et à couvrir toutes les activités d’une description BPEL, y compris les activités de communication (i.e. les envois/réception de messages qui sont aussi testés par notre approche).

Une approche de test fondée sur les automates temporisés L’approche de test proposée dans cette thèse est fondée sur le modèle des automates temporisés. Ces modèles sont bien adaptés pour la description des comportements de services Web composés (e.g. échanges de messages, temps d’attente ou écoulement de temps), ajoutant à cela, la richesse et la diversité des méthodes formelles et des techniques de test qui se basent sur les automates temporisés.

Table des matières

1 Introduction générale
I État de l’art
2 Modélisation et test de la composition de services Web
II Contributions
3 Modélisation formelle de la composition de services Web
4 Transformation d’une description BPEL en langage IF
5 Méthode de test de la composition de services Web
III Mise en œuvre et et implantations
6 Plateforme de test de la composition de services Web
IV Conclusion et annexes
7 Conclusion et perspectives
A Le service LoanApproval — variante séquentielle
B Le service LoanApproval — variante parallèle
C Flot de contrôle du service LoanApproval — variante parallèle
D Descriptions WSDL du client et des partenaires du service loanApproval
E Cas de test concret du scénario 1
F Cas de test concret du scénario 8
8 Conclusion générale

Télécharger le rapport complet