Soutenance mémoire
Services Web, composition de services et langage BPEL
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.
Architecture orientée services
Une architecture orientée services, notée SOA [2, 7], est une architecture logicielle visant à mettre en place un système d’information constitué de services applicatifs indépendants et interconnectés. L’architecture SOA permet la réutilisation des applications et des services existants, ainsi de nouveaux services peuvent être créés à partir d’une infrastructure informatique des systèmes déjà existante. En d’autres termes, SOA permet aux entreprises de tirer partie des investissements existants en leur permettant de réutiliser des applications existantes, en leur offrant une interopérabilité entre applications et technologies hétérogènes. L’objectif d’une architecture SOA est de décomposer une fonctionnalité en un ensemble de services et de décrire leurs interactions. Ces services peuvent être utilisés par des processus métier (i.e. services Web composés) ou par des clients dans différentes applications. Dans une architecture SOA, comme le montre la Figure 2.1, les fournisseurs de services publient (ou enregistrent) leurs services dans un annuaire de services (qui peut être publique ou local à un réseau d’entreprise par exemple). Cet annuaire est utilisé par les utilisateurs (i.e. les clients de services) pour trouver des services vérifiant certains critères ou correspondant à une certaine description. Si l’annuaire contient de tels services, il envoie au client les descriptions de ces services avec un contrat d’utilisation. Le client fait alors son choix, s’adresse au fournisseur et invoque le service Web.
Le langage BPEL
BPEL, tout d’abord nommé BPEL4WS [14] et WS-BPEL [1] depuis 2005, s’est imposé comme le langage standard OASIS 2 d’orchestration de services Web. Il est largement utilisé dans le cadre de la mise en œuvre d’une architecture orientée services. Le langage BPEL permet de décrire à la fois :
i. l’interface comportementale, via la définition d’un processus abstrait spécifiant les échanges de messages entre différents partenaires ;
ii. l’orchestration, via la définition d’un processus privé exécutable 3 qui représente la nature et l’ordre des échanges entre partenaires.
BPEL se caractérise par rapport aux autres langages (d’orchestration) par :
– sa gestion des exceptions, en particulier, des fautes et des événements ;
– l’exécution parallèle des activités et la synchronisation des flots ;
– la description des transactions 4 contextuelles (stateful) et de longue durée ;
– son mécanisme de compensation qui est très utile pour les transactions de longue durée ;
– sa gestion de la corrélation des messages.
Notons qu’un processus BPEL est directement exécutable par un moteur d’orchestration de BPEL (e.g. activeBPEL [15], Oracle BPEL Process Manager [16]). BPEL s’appuie sur le langage WSDL puisque chaque processus BPEL est exposé comme un service Web via une interface WSDL. BPEL utilise les opérations, les données ainsi que les liens des partenaires décrits dans son interface WSDL. Ce dernier décrit aussi tous les éléments nécessaires à un processus BPEL pour interagir avec ses partenaires, à savoir, l’adresse des partenaires, les protocoles de communication et les opérations disponibles. En outre, BPEL fait appel aux standards WSDL, SOAP, UDDI, mais aussi aux autres standards de services Web (cf. Fig. 2.4) tels que :
– WS-Addressing, qui est un mécanisme permettant de transporter des messages SOAP de façon bidirectionnelle, en mode synchrone ou asynchrone [17] ;
– WS-Policy, qui est une extension de WSDL permettant d’exprimer les fonctionnalités et les caractéristiques générales des partenaires (e.g. politiques d’usage, gestion des transactions, fiabilité, sécurité) [18] ;
– WS-Security, qui est une extension de SOAP permettant de sécuriser les échanges de messages [19] ;
– WS-Reliable Messaging, qui est un protocole permettant aux messages d’être délivrés de manière fiable entre différentes applications réparties, dans le cas de pannes de composants, de réseaux ou de systèmes [20] ;
– WS-Transactions, qui définit des mécanismes interopérables permettant de réaliser des transactions entre différents domaines de services Web [21].
La description d’un processus BPEL contient quatre parties principales : (i) la déclaration des variables utilisant des types décrits ou importés dans l’interface WSDL, (ii) la description des partenaires (iii) la déclaration des gestionnaires de fautes qui sont déclenchés après une exception, (iv) l’activité principale qui décrit le comportement du processus.
Compensation et gestion des erreurs
Les processus métier impliquent des transactions de longue durée qui sont basées sur des communications (i.e. échanges de messages) asynchrones. Ces transactions conduisent à un certain nombre de mise à jour pour les partenaires. Par conséquent, si une erreur se produit, il est nécessaire d’inverser les effets de certaines ou même de la totalité des activités antérieures. Cela est le rôle de la compensation. Durant l’exécution d’un processus BPEL, des conditions d’exception peuvent se produire et doivent être gérées. Un service Web invoqué peut retourner une faute WSDL qui doit être traitée ; un processus BPEL lui-même peut avoir besoin de signaler une faute à des clients. Ajoutant à cela, que certaines erreurs peuvent aussi se produire au niveau de l’environnement d’exécution (des processus BPEL). Pour BPEL, la gestion des fautes peut être effectuée au niveau d’un processus et/ou d’un scope. Une activité définit une unité logique de travail recouvrable et réversible, pour lequel un ensemble de gestionnaires de fautes et de compensation peut être défini. Cela en vue de traiter les fautes interceptées, et de défaire le travail effectué dans un scope en cas d’erreurs. Notons que BPEL permet aussi d’associer des gestionnaires de fautes à une activité (synchrone) pour traiter les fautes d’invocation.
Automates
Zheng et al. [45, 46, 47] ont défini une sémantique opérationnelle de BPEL pour le test de la composition de services Web. Cette sémantique a été décrite par un automate, appelé WSA (Web Service Automata), qui est une extension des machines de MEALY. Ce modèle WSA a servi comme modèle intermédiaire et a été codé en XML pour être transformé ensuite en langage d’entrée des Model-Checkers NuSMV [48] et SPIN [49]. WSA est assez adapté une grande partie de ses constructions, à l’exception des activités temporelles (e.g. , ) [1] étant donné que c’est un modèle non temporisé. Par contre, les données complexes, les valeurs concrètes et les prédicats de BPEL ont été abstraites afin de faciliter le Model-Checking. Le modèle WSTTS (Web Service Timed State Transition Systems) a été proposé par Kazhamiakin et al. [50, 51] pour décrire les comportements temporisés d’un processus BPEL. Intuitivement, WSTTS est une machine d’états finis enrichie avec un ensemble de variables d’horloge mais ne considérant pas les variables discrètes ; En conséquence, ce modèle ne permet pas donc de décrire les variables d’un processus BPEL, ni la gestion de la corrélation des messages. Dans [52], une transformation de BPEL en automate (aDFA pour annotated Deterministic Finite State Automata) a été proposée par Mahleko et al.. Cette modélisation de BPEL en aDFA a été utilisée par Wombacher et al. [53] pour la découverte de services. Cependant, ce modèle aDFA ne permet pas de décrire ni les aspects temporels des processus BPEL, ni ses variables ou ses gestionnaires d’exceptions. Un autre modèle d’automate, appelé STS (State Transition System), a été défini et utilisé par Pistore et al. [54] comme sémantique formelle de BPEL. La transformation de BPEL en STS a été implantée dans l’outil BPEL2STS. Notons que ce modèle ne prend pas en compte ni les données, ni le temps et ne décrit qu’une partie de BPEL. Enfin, nous citons les travaux de Yan et al. [55] qui ont présenté une méthode automatique de modélisation des comportements d’un service composé par le biais de systèmes à événements discrets DES (Discrete Event Systems). Yan et al. ont transformé une description BPEL en un système DES et ont utilisé ce modèle pour le diagnostic et la supervision (ou le monitoring) des processus BPEL. Thèse de Doctorat — Novembre 2009 Mounir LALLALI 2.5 Modélisation de l’orchestration de services Web 26 Dans [56, 57], Bultan et al. ont introduit une plateforme pour l’analyse de la composition de processus BPEL communiquant via des messages XML asynchrones, et la vérification de leurs propriétés. Cette plateforme permet, en premier lieu, de transformer chaque processus BPEL en un type particulier d’automates gardés appelés GFSA (Guarded Finite State Automata) dont chaque transition peut être associée à une garde sous la forme d’une expression XPath [58].Ces automates ont été ensuite transformés en une spécification Promela [59]. L’outil SPIN 6 a servi ainsi pour vérifier si la composition des processus BPEL satisfait certaines propriétés décrites en logique temporelle linéaire (LTL). Ces mêmes auteurs ont décrit, dans [57], leur outil WSAT permettant de transformer BPEL en GFSA — utilisée comme une représentation intermédiaire — et ensuite GFSA en Promela. Shin NAKAJIMA [60] a proposé d’utiliser les techniques de Model-Checking pour l’analyse des services composés décrits en BPEL. Ses auteurs ont décrit le comportement d’un processus BPEL par une variante d’automate EFA (Extended Finite State Automaton). Cet automate est transformé en une spécification Promela qui est automatiquement analysée par le Model-Checker SPIN. Notons que ce modèle formel ne permet pas de décrire toutes les constructions de BPEL, en particulier, les activités temporelles, la gestion des exceptions (fautes, événements, compensation) et la terminaison. Enfin, García-Fanjul et al. [61, 62] ont transformé un processus BPEL en une spécification Promela qui a été utilisée comme une entrée du Model-Checker SPIN afin de dériver une suite de tests pour le test des processus BPEL.
|
Table des matières
1 Introduction générale
1.1 Contexte
1.1.1 Services Web, composition de services et langage BPEL
1.1.2 Test de logiciels
1.2 Motivations
1.3 Contributions
1.4 Plan du manuscrit
1.5 Liste des publications liées à cette thèse
I État de l’art
2 Modélisation et test de la composition de services Web
2.1 Introduction
2.2 Présentation des services Web
2.2.1 Architecture orientée services
2.2.2 Services Web
XML
HTTP
WSDL
SOAP
UDDI
2.2.3 Composition de services Web
2.3 Le langage BPEL
2.3.1 Les activités de BPEL
Les activités basiques
Les activités de communication
Les activités structurées
2.3.2 Gestion des données
2.3.3 Corrélation des messages
2.3.4 Les scopes
2.3.5 Compensation et gestion des erreurs
2.4 Le test des logiciels
2.5 Modélisation de l’orchestration de services Web
2.5.1 Réseau de Pétri
2.5.2 Automates
2.5.3 Algèbre de processus
2.5.4 Machine d’états abstraite
2.5.5 Autres formalismes
2.5.6 Discussion
2.6 Test des services Web composés décrits en BPEL
2.6.1 Test de l’interface WSDL
2.6.2 Test structurel ou test boîte blanche de BPEL
Test unitaire de BPEL
Test de BPEL par Model-Checking
2.6.3 Test fonctionnel ou test boîte noire de BPEL
2.7 Quelques autres travaux sur les services Web
2.7.1 Les services Web sémantiques
2.7.2 Vérification de l’orchestration de services Web
2.7.3 Surpervision des services composés
2.8 Génération de cas de test temporisés
2.9 Synthèse
II Contributions
3 Modélisation formelle de la composition de services Web
3.1 Introduction
3.2 Modèle formel : WS-TEFSM
3.2.1 Machine étendue à états finis temporisée à priorité (WS-TEFSM)
Les variables
Les horloges
Les invariants d’état
Les transitions
Les priorités de transition
Sémantique d’une machine WS-TEFSM
Séquence temporisée, exécution et trace d’une WS-TEFSM
3.2.2 Machine WS-TEFSM Partielle
Fonctions de renommage d’état, de transition et de WS-TEFSM partielle
Produit asynchrone de machines WS-TEFSM partielles
3.3 Modélisation temporelle de BPEL
3.3.1 Approche de modélisation
3.3.2 Modélisation de l’élément process
Variables et horloges
Messages
Ensembles de corrélation
La machine WS-TEFSM de l’élément process
3.3.3 modélisation des activités internes
3.3.4 Modélisation des activités basiques
L’activité assign
L’activité empty
L’activité wait
L’activité throw
L’activité exit
3.3.5 Modélisation des activités de communication
L’activité receive
L’activité reply
L’activité invoke
3.3.6 Modélisation des activités structurées
L’activité sequence
L’activité while et repeatUntil
L’activité if
L’activité pick
L’activité flow
3.3.7 Modélisation des liens
L’élément target
L’élément source
3.3.8 Modélisation de l’activité scope
3.3.9 Modélisation de la corrélation des messages
3.3.10 Modélisation des gestionnaires de fautes
3.3.11 Modélisation des gestionnaires d’événements
3.3.12 Modélisation du gestionnaire de terminaison
3.3.13 Gestion de la terminaison des activités
Terminaison des activités atomiques
Terminaison des activités basiques et de communication
Terminaison des activités structurées
Terminaison des gestionnaires d’événements
Terminaison d’une scope
Terminaison de l’élément Process
3.3.14 Modélisation de la compensation
3.4 Synthèse
4 Transformation d’une description BPEL en langage IF
4.1 Introduction
4.2 Le langage IF
4.2.1 Syntaxe de IF
Système
Processus
Route de communication
Signal
État
Transition
Action
Données : constantes, types, variables et expressions
4.2.2 Le modèle formel de IF
Automate temporisé de IF et sa sémantique
Un système d’automates temporisés et sa sémantique
4.2.3 Relation entre une machine WS-TEFSM et un automate de IF
4.3 Transformation d’une description BPEL en langage IF
4.3.1 Données
Variables
Expressions
4.3.2 Liens partenaires et messages
4.3.3 Propagation de fautes et terminaison des activités
4.3.4 Synchronisation des activités
4.3.5 Activités basiques
4.3.6 Activités de communication
4.3.7 Activités structurées
Activité sequence
Activité if
Activités while et repeat until
Activité flow
Activité pick
4.3.8 Activité scope
4.3.9 Corrélation des messages
4.3.10 Gestionnaires de faute
4.3.11 Gestionnaires d’événement
4.3.12 L’élément process
4.3.13 Client et partenaires
4.3.14 Synthèse
5 Méthode de test de la composition de services Web
5.1 Introduction
5.2 Les besoins de test de la composition de services Web
5.3 Méthodologie de test d’un service composé
5.4 Architecture de test
5.4.1 Architecture de test centralisée
5.4.2 Architecture de test distribuée
5.4.3 Test de plusieurs instances d’un service sous test
5.4.4 Types d’interactions entre un service sous test et son environnement
5.4.5 Types d’erreurs
5.5 Génération automatique de tests temporisés
5.5.1 Test de conformité
Relation de Conformité
Objectif de test et cas de test
5.5.2 Algorithme de génération automatique de test temporisé
5.6 Concrétisation de cas de test
5.6.1 Approche de concrétisation
Dérivation des interactions de testeurs
Dérivation des délais d’attente
Dérivation des messages
Description du service contrôleur
5.6.2 Concrétisation des cas de test seq1 et seq2
Concrétisation de seq1
Concrétisation de seq2
5.7 Synthèse
III Mise en œuvre et et implantations
6 Plateforme de test de la composition de services Web
6.1 Introduction
6.2 Plateforme de test de l’orchestration de services Web
6.3 Description des outils
6.3.1 Le moteur activeBPEL
6.3.2 Le Framework de test BPELUnit
6.3.3 L’outil BPEL2IF
6.3.4 TestGen-IF
Boite à outils de IF
Implantation de l’algorithme de génération de tests temporisés
Architecture de TestGen-IF
Formulation des objectifs de test
Utilisation de TestGen-IF
6.4 Étude de cas — test du service loanApproval
6.4.1 Présentation du loanApproval
6.4.2 Transformation de la description BPEL du loanApproval en IF
6.4.3 Vérification de la spécification du loanApproval
Propriétés d’une composition de services Web
Observateurs IF
Propriétés attendues du service loanApproval
Exemple de vérification de propriétés du service loanApproval
6.4.4 Génération de tests abstraits avec TestGen-IF
Description des trois scénarios
Formulation des objectifs de test pour les trois scénarios
Génération de tests abstraits pour les trois scénarios de test
6.4.5 Dérivation des tests concrets
Concrétisation du cas de test abstrait du scénario 1
Concrétisation du cas de test abstrait du scénario 8
6.4.6 Exécution des tests avec BPELUnit
Phase d’édition d’une suite de test
Phase d’exécution de la suite de test
Phase d’émission du verdict
6.5 Synthèse
IV Conclusion et annexes
7 Conclusion et perspectives
7.1 Synthèse des travaux et résultats
7.2 Perspectives
7.2.1 Perspectives relatives à notre approche de test
7.2.2 Perspectives générales
Télécharger le rapport complet
