Interprétation d’une politique de contrôle d’accès ASTD par des
7.1 Description des jeux d’essai
Les jeux d’essai visent à évaluer les deux implémentations du filtre. Les données d’essai comportent des spécifications ASTD et pour chacune d’elles des séquences d’actions à tester ainsi que les résultats prédéterminés afin de les comparer avec les résultats obtenus lors de l’expérience. Ces données d’essai sont rassemblées dans un fichier qui respecte le format XML décrit dans le programme 7.1. Les lignes 3 à 5 contiennent une spécification ASTD et les lignes 6 à 16 incluent ses séquences d’actions (TestCase) imbriquées dans la balise TestSuite. Chaque séquence commence avec l’action Init (opération d’initialisation du filtre) et termine avec l’action Stop
1 <ax:Tests xmlns:ax="http://gril.udes.ca/astd/schema/ASTD"> 2 <ax:Test ax:Name="T001"> 3 <ax:Specification> 4 � 5 </ax:Specification> 6 <ax:TestSuite> 7 <ax:TestCase ax:Functionality="true"> 8 <ax:Init/>
9 <ax:Event ax:Name="T1" ax:ResultAccess="granted"/>
10 <ax:Commit ax:ResultIsFinal="true" ax:ResultIsCompleted="true"/>
11 � 12 <ax:Stop/> 13 </ax:TestCase> 14 <ax:TestCase ax:Functionality="true"> 15 � 16 </ax:TestSuite> 17 </ax:Test> 18 � 19 </ax:Tests>
Programme 7.1 – Fichier des données d’essai
(opération d’arrêt du filtre). Les autres actions possibles sont Event (opération de demande d’autorisation pour un événement) et les actions Commit/Rollback. Dans le cas de l’action Event (ligne 9), l’élément XML comporte le nom de l’événement et ses paramètres (le cas échéant) ainsi que la valeur de retour attendue pour la demande d’autorisation (granted ou denied). À la ligne 10, l’action Commit est utilisée avec les valeurs booléennes attendues des variables de débogage IsFinal et IsCompleted. L’action Rollback, qui n’est pas illustrée dans cet exemple, utilise aussi les même variables de débogage. À partir du fichier de données d’essai, trois groupes de fichiers sont créés : le groupe de fichiers relatif à la méthode de transformation, le groupe de fichiers relatif à la méthode d’interprétation et le groupe de fichiers projet de l’outil d’exécution des tests et des fichiers de scripts pour piloter l’exécution des jeux d’essai et générer les statistiques.
L’algorithme de transformation détaillé au chapitre 5 est implémenté dans un pro-gramme écrit en OCaml1 et dans un ensemble de feuilles de style XSL. Puisque les résultats attendus de la transformation sont i) des processus BPEL, ii) le document d’interfaces WSDL et iii) les fichiers de déploiement pour le moteur d’exécution ODE, l’utilisation d’un processeur XSLT et de feuilles de style XSL semble appropriée car
7.1. Description des jeux d’essai Spécifications ASTD + Séquences d’actions OCaml Structures XML pour BPEL Structures XML pour BPEL Structures XML pour BPEL xsl Processus
BPELProcessusBPELProcessusBPEL
Structures XML pour WSDL xsl Fichier d’interface WSDL Structures XML pour ODE xsl Fichier de déploie-ment ODE Fichiers de calcul XSLFichiers decalcul XSLFichiers decalcul XSL
Processeur XSLT Filtre
Figure 7.1 – Création du filtre de contrôle d’accès
tous ces fichiers sont dans un format XML. Le rôle du programme OCaml est de diriger la transformation en extrayant les spécifications ASTD du fichier de données d’essai. Une fois une spécification extraite, le programme la réorganise en fonction de la sortie attendue (respectivement les processus BPEL, le document d’interfaces WSDL et le fichier de déploiement) et traite ces nouveaux documents XML à l’aide du proces-seur XSLT et de la feuille de style correspondante (respectivement Process.xsl, FilterProcessInterface.xsl et Deploy.xsl). Ce traitement est illustré à la figure 7.1 et il est répété pour chaque spécification ASTD du fichier de données d’essai. Le nombre de documents XML (désigné par d) générés par le programme OCaml est fonction de la spécification ASTD :
d= 1+nombre de structures appel, fermeture de Kleene et synchronisation quantifi´ee. Ce nombre est également le nombre de processus BPEL créés. Chaque groupe de fi-chiers créés pour le filtre est enregistré dans un dossier correspondant à la spécification ASTD transformée.
Spécifications ASTD + Séquences d’actions xsl Processeur XSLT Spécifications ASTD
Figure 7.2 – Extraction des spécifications du filtre de contrôle d’accès
Dans le cas de la méthode d’interprétation décrite au chapitre 6, les fichiers de processus ne sont pas à créer parce qu’ils constituent l’interpréteur. Cependant, les spécifications ASTD sont extraites du fichier de données d’essai et rassemblées dans un fichier XML pour être interprétées par le filtre. L’action Init d’une séquence d’actions indique, par la valeur de son paramètre PId, laquelle des spécifications sera testée. L’extraction des spécifications se fait par un processeur XSLT et une feuille XSL appropriée, comme illustrée à la figure 7.2.
Les séquences d’actions exécutées sont concrètement des appels de services Web. Ces appels sont des messages SOAP envoyés par un outil approprié de test des ser-vices Web. L’outil choisi pour notre expérience est soapUI2. En effet, il offre une interface graphique ainsi qu’un programme utilisable en ligne de commande. Les re-quêtes SOAP sont créées à partir du fichier de données d’essai et sont rassemblées dans deux fichiers projet (un pour la transformation et un pour l’interprétation) propres à l’outil soapUI. À chaque requête SOAP sont attachées des assertions qui valident que la réponse SOAP reçue à l’issue de l’envoi du message est conforme aux valeurs attendues. À titre d’illustration pour la demande d’autorisation de la ligne 9 du pro-gramme 7.1, la requête SOAP correspondante comporte trois assertions dans les deux fichiers projet. La première assertion (SOAP Response dans l’outil soapUI ) valide que le format XML de la réponse reçue est conforme à celui des réponses SOAP. La se-conde assertion (Not SOAP Fault dans l’outil soapUI ) valide que la réponse reçue n’est pas une erreur SOAP. La troisième assertion (Access granted ou Access denied dans l’outil soapUI ), plus intéressante pour notre étude, valide que la réponse obtenue est conforme à la décision d’autorisation attendue, c’est-à-dire granted dans le cas de
7.1. Description des jeux d’essai Spécifications ASTD + Séquences d’actions xsl Fichier projet transformation xsl Fichier projet interprétation xsl Script de pilotage des tests Processeur XSLT Fichiers projet soapUI
Figure 7.3 – Création des fichiers projet soapUI
la ligne 9 du programme 7.1. Dans le cas des actions Commit/Rollback, des asser-tions spécifiques aux valeurs des variables de débogage IsFinal et IsCompleted sont ajoutées aux messages SOAP correspondants. Les deux fichiers projet sont créés à partir de feuilles de style XSL passées en paramètres (en plus du fichier de données d’essai) à un processeur XSLT (voir la figure 7.3).
À partir du fichier de données d’essai, un script de pilotage des tests unitaires est également créé. À son exécution, ce script déploie les processus BPEL propres à chacune des méthodes et exécute les mêmes séquences d’actions sur les processus déployés. L’exécution de ces séquences d’actions est en fait l’envoi des requêtes SOAP correspondantes dans les fichiers projet soapUI et cet envoi se fait par l’utilisation du programme soapUI en ligne de commande. L’exécution inclut également la validation des assertions attachées aux messages SOAP ainsi que la prise de mesures de perfor-mance (par exemple temps minimum, maximum et moyen). Enfin, le script rassemble dans un même fichier XML les résultats obtenus pour toutes les séquences d’actions de chaque spécification ASTD. La figure 7.3 illustre la création de ce script à partir du fichier de données d’essai.
Tableau 7.1 – Caractéristiques des machines de l’expérience
Serveur Client
Processeur Intel(R) Xeon(R)CPU X5550 @ 2.67GHz Intel(R) Core(TM) 2CPU 6400 @ 2.13GHz
Mémoire vive 4 Go 4 Go
Système d’exploitation Linux Ubuntu 10.04.4 LTSNoyau 2.6.32-41-generic Linux Ubuntu 10.04.4 LTSNoyau 2.6.32-42-generic Logiciel Apache Tomcat 7.0.28ODE 1.3.5
MySQL 5.1 soapUI 4.5.1