Plateforme de test de la composition de services Web

Plateforme de test de la composition de
services Web

 Introduction

 LA plateforme de test, décrite dans ce chapitre, a pour but de tester l’orchestration de services Web et de fournir un cadre pour la génération automatique de tests et de leur exécution. Elle met en œuvre notre approche de test détaillée dans le Chapitre 5. Les fonctionnalités de cette plateforme sont réparties en cinq phases : (i) modélisation de l’orchestration de services Web, (ii) génération de tests abstraits, (iii) concrétisation des tests qui consiste à dériver des tests exécutables qui sont fournis au Framework BPELUnit, (iv) édition et déploiement du service composé à l’aide de l’outil activeBPEL Designer, (v) l’exécution des tests qui est réalisée à l’aide de BPELUnit. Dans cette plateforme, l’architecture de test — représentant le service composé sous test ainsi que son environnement (client et partenaires) — est de nature distribuée : chaque service partenaire, intervenant dans un test, pourrait être simulé par un service testeur alors qu’un ou plusieurs clients pourraient être simulés par un seul service testeur. La transformation de BPEL en IF et la description de l’outil BPEL2IF ont été publiées dans les deux conférences ECOWS 2008  et NWeSP 2008 [163]. L’outil TestGen-IF a fait l’objet d’une publication dans la conférence DS-RT 2008 [181]. Il a été aussi utilisé dans deux travaux de collaboration qui ont été publié dans les deux conférences SITIS 2008 [182] et FORTE 2009 [183]. Dans ce chapitre, nous présenterons notre plateforme de test de la composition de services. Nous commencerons par décrire les différents outils développés et/ou utilisés dans cette plateforme : le moteur activeBPEL, le Framework de test unitaire BPELUnit, l’outil de transformation BPEL2IF et l’outil de génération de test TestGen-IF. Dans la seconde partie de ce chapitre, nous détaillerons une étude cas — test du service de prêt loanApproval — permettant d’illustrer notre approche de test et de montrer l’utilisation de notre plateforme de test. Pour cela, nous avons choisi de détailler trois scenarios de test parmi 17 scénarios probables pour ce service de prêt. Ces trois scénarios seront utilisés pour le test de la gestion de la corrélation des messages, de la gestion des timeouts et de quelques interactions du service composé loanApproval. Dans cette étude cas, nous expliciterons les différentes phases de notre approche : la transformation de la description BPEL du service loanApproval en spécification IF (par l’utilisation de BPEL2IF), la formulation des objectifs de test associés aux scénarios de test, la génération des tests (par l’utilisation de TestGen-IF), la concrétisation des tests, l’édition des tests et leur exécution dans le Framework BPELUnit.

Plateforme de test de l’orchestration de services Web

Dans cette section, nous présentons notre plateforme de test de l’orchestration de services Web. Cette plateforme met en œuvre notre approche de test boîte grise qui est a été définie dans le Chapitre 5. Cette approche se place dans le cadre du test de la conformité de l’orchestration de service Web, qui consiste à tester si l’implantation d’un service composé est conforme à sa spécification de référence (une description BPEL). Nous considérons ce test de conformité comme étant un test fonctionnel de type boîte grise où on connaît les différentes interactions entre le service composé, son client et ses partenaires.Cette plateforme a pour but de tester l’orchestration de services Web, de fournir un cadre pour la génération automatique de cas de test et de leur exécution. Elle est illustrée par la Figure 6.1. Les fonctionnalités de cette plateforme peuvent être réparties en cinq phases : 1. la modélisation de l’orchestration de services Web, qui est réalisée par notre outil de transformation BPEL2IF. A partir d’une description BPEL d’un service composé, de sa description WSDL et de celle de ses partenaires, BPEL2IF produit une spécification (temporelle) de l’orchestration de services en langage IF. Cette spécification servira, dans notre approche de test de conformité, comme modèle formel décrivant le comportement du service composé ; 2. la génération des tests abstraits, qui est effectuée par notre outil de génération de test TestGenIF. Cet outil permet de dériver automatiquement des tests temporisés à partir de la spécification IF et d’un ensemble d’objectifs de test décrivant les propriétés qu’on cherche à vérifier sur le service composé sous test ; 3. la concrétisation des tests, qui consiste à dériver des tests exécutables par l’outil BPELUnit ; cela à partir des tests abstraits générés lors de la phase précédente, et des interfaces WSDL du service composé et de ses partenaires. L’édition de ces tests se fait à l’aide de l’outil BPELUnit (plus précisément de son interface d’édition des suites de test) ; 4. l’édition et le déploiement du service composé (i.e. processus BPEL) sous test à l’aide de l’outil activeBPEL. Ce dernier est un moteur BPEL permettant aussi la gestion et l’exécution des processus BPEL ; 5. l’exécution des tests, qui est réalisée à l’aide de la plateforme de test BPELUnit. Rappelons ici qu’une architecture de test pour les services composés représente le service composé sous test ainsi que son environnement (client et partenaires). L’architecture de test adoptée dans notre travail est de nature distribuée : chaque service partenaire, intervenant dans le cas de test, pourrait être simulé par un service testeur. Cependant, on pourra simuler plusieurs clients et les regrouper dans un seul service testeur. On se reportera à la Section 5.4 et à [105] pour avoir plus de détails concernant les architectures de test proposées pour le test des services Web. Dans la section suivante, nous décrivons les outils utilisés dans cette plateforme de test : activeBPEL, BPELUnit, BPEL2IF et TestGen-IF.

Description des outils 

Dans cette section, nous commençons par présenter brièvement le moteur BPEL activeBPEL (que nous utilisons tout au long de notre étude de cas pour l’édition, le déploiement et l’exécution des processus BPEL) ainsi que le Framework BPELUnit de test unitaire de BPEL (que nous utilisons pour l’exécution des tests dérivés par notre méthode de test). Ensuite, nous décrirons les deux outils : BPEL2IF et TestGen-IF, que nous avons développé pour mettre en œuvre notre méthode de transformation de BPEL en IF (décrite dans le Chapitre 4), respectivement pour implanter notre algorithme de génération de cas de test (défini dans la Section 5.5.2).

Le moteur activeBPEL

 Un moteur d’orchestration BPEL, appelé moteur BPEL, est un outil d’exécution d’une orchestration décrite en BPEL. Il organise les envois/réceptions de messages et les appels de services Web selon l’orchestration décrite dans les processus BPEL. Il existe de nombreux moteurs BPEL (libres ou commerciaux) : ActiveBPEL de Active Endpoints 1 , BPEL Process Manager d’Oracle 2 , WebSphere Studio d’IBM 3 , BPEL Maestro de Parasoft 4 , Apache ODE 5 . Dans ce travail, nous utilisons le moteur activeBPEL étant donné qu’il intègre facilement le Framework de test BPELUnit — que nous décrivons dans la section suivante. activeBPEL est doté d’un serveur d’applications sous licence libre et reposant sur le serveur Tomcat 6 . Il est doté d’outils de conception et de déploiement de processus BPEL (e.g. activeBPEL Designer). Il possède une interface d’administration permettant la gestion et le déploiement des services et des processus BPEL ainsi que la création et l’exécution de leurs instances. La Figure 6.2 décrit l’architecture globale 7 du moteur activeBPEL — que nous ne détaillons pas ic

Le Framework de test BPELUnit

 BPELUnit 8 est un Framework de test unitaire de BPEL qui a été proposé par Mayer et al. [106]. Dans ce Framework, le service composé sous test, noté SST, est isolé de son environnement réel. Il est effectivement déployé dans un serveur d’applications (e.g. Tomcat) alors que le client et les services partenaires du service SST sont simulés respectivement par BPELUnit comme un Track client et des Tracks partenaires. Lors de l’exécution des tests, tous ces Tracks seront exécutés simultanément comme étant des services indépendants. 1. http://www.activevos.com/community-open-source.php 2. http://www.oracle.com/technology/products/ias/bpel/index.html 3. http://www-01.ibm.com/software/websphere/ 4. http://www.parasoft.com/jsp/products/home.jsp?product=BPEL 5. http ://ode.apache.org/ 6. http ://tomcat.apache.org/ 7. Source : www.activebpel.org 8. http://www.se.uni-hannover.de/forschung/soa/bpelunit/ Une suite de test en BPELUnit consiste en la description des deux parties (cf. Fig. 6.3) : 1. section de déploiement : qui contient toutes les informations de déploiement du service sous test et la spécification des services à simuler, i.e. le nom et la description WSDL du client et des partenaires (cf. Fig. 6.4) ; 2. section de cas de test : qui contient la description des cas de test contenue dans la suite de test. Chaque description d’un cas de test contient un seul Track client et un nombre de Tracks partenaires (probablement aucun) (cf. Fig. 6.5) .On distingue six types d’activités : Send Asynchronous, Receive Asynchronous, Send/Receive Synchronous, Receive/Send Synchronous, Send/Receive Asynchronous et Receive/Send Asynchronous. Les deux premières activités (i.e. Send Asynchronous et Receive Asynchronous) correspondent à une interaction simple d’envoi et de réception d’un message. Les deux activités synchrones (i.e. Send/Receive Synchronous et Receive/Send Synchronous) correspondent à une interaction synchrone bilatérale, plus précisément, envoi/réception synchrone et réception/envoi synchrone. Les paires asynchrones (i.e. Send/Receive Asynchronous et Receive/Send Asynchronous) sont considérées comme des paires d’interactions simples (asynchrones). L’édition (ou la création) d’un cas de test dans BPELUnit comporte deux étapes. On doit d’abord sélectionner un ensemble d’opérations que doivent invoquer le cas de test et les ajouter aux Tracks associés comme étant des activités. Un Track peut contenir plus d’une activité comme le montre le Track client de la Figure 6.6 (cf. Lignes 3 et 18). Ensuite, on doit préparer pour chaque activité, les données XML à transmettre au service SST et/ou les conditions de vérification qui sont utilisées, durant le test, pour vérifier les données envoyées par le SST et reçues par un Track client ou un Track partenaire. La Figure 6.6 donne un exemple d’un cas de test case1 composé d’un Track client et d’un Track partenaire. Le Track client (cf. Ligne 2 de la Figure 6.6) contient deux activités synchrones Send/Receive Synchronous (cf. Ligne 3 et Ligne 18). L’élément data (cf. Ligne 5) à l’intérieur de l’élément send de la première activité décrit les données XML à envoyer au service sous test. Quant à l’élément condition (cf. Ligne 12) à l’intérieur de l’élément receive de la même première activité, il décrit la condition de vérification des données reçues par le Track client en réponse à sa requête précédente. Notons que chaque activité d’un Track est associée à un service, un port et une opération qui font référence à la description WSDL d’un client ou d’un partenaire simulé par ce Track. Le Framework BPELUnit permet l’édition ainsi que l’exécution des cas de tests. Au début de l’exécution d’un cas de test, le client (simulé par le Track client) initie le test par l’envoi des données (déjà préparées ou décrites) au service sous test (SST). Ce dernier invoque, tout au long du test, les opérations de ses partenaires — qui sont simulés par les Tracks partenaires. Ces partenaires reçoivent les données envoyées par le service SST et les vérifient selon les conditions de vérification qui leurs sont associées. Si tout se passe comme prévu, les partenaires invoqués retournent les données déjà préparées au service SST en réponse à sa requête. Dans le cas contraire et en cas d’erreur, le test se termine immédiatement et l’erreur est signalée au testeur. 

L’outil BPEL2IF 

BPEL2IF est un outil que nous avons développé en Perl et XML/XSLT, dans le but de transformer la description d’un processus BPEL en une spécification en langage IF. Il met en œuvre notre méthode de transformation de BPEL en IF présentée dans le Chapitre 4. La Figure 6.7 décrit l’architecture de l’outil BPEL2IF qui contient les parties suivantes : – scripts de transformation : Pour chaque version de BPEL (BPELWS 1.1 et WS-BPEL 2.0), est associée un script en Perl (applyTrasform1.1 et applyTrasform2.0) permettant la gestion des fichiers d’entrée/sortie de l’outil ainsi que l’application des règles de transformation de BPEL ; – règles de transformation : A chaque activité des deux versions BPEL est associée à une règle de transformation décrite en langage XSLT [184] ; ajoutant à cela les règles de transformation des types de données décrites dans les fichiers WSDL, des variables et des liens partenaires de BPEL, des corrélations utilisées et des gestionnaires de fautes et d’événements ; – Entrées : La description BPEL du service composé, de sa description WSDL ainsi que celle de ses service partenaires ; – Sortie : La spécification formelle en langage IF de l’orchestration de services Web décrite par le processus BPEL. Chaque activité de BPEL est transformée en un processus IF par le biais d’une règle de transformation XSLT. Le processus IF principal de l’élément crée dynamiquement, à l’aide de l’instruction fork de IF, les processus de ses gestionnaires de fautes, d’événements et de son activité principale. Chaque processus IF doit être capable de terminer son exécution à la réception d’un message de terminaison terminate, et de propager la faute interceptée par l’envoi d’un message faute à son processus parent. Pour plus de détails, on peut se reporter au Chapitre 4.