THÈSE. Une Approche de Composition des Services Web Basée Transformation de Graphes

Transcription

1 République Algérienne Démocratique et Populaire Ministère de l Enseignement Supérieur et de la Recherche Scientifique Université Abdelhamid Mehri Constantine 2 Faculté des Nouvelles Technologies de l Information et de la Communication Département IFA Année : 2014 N d ordre: LMD/NTIC/2014/005 Série : LMD/NTIC/2014/005 THÈSE Pour l obtention du diplôme de Doctorat 3ème cycle LMD en Informatique Une Approche de Composition des Services Web Basée Transformation de Graphes Présentée et soutenue le 07/12/2014 Par : FAYÇAL BACHTARZI Directeur de Thèse: Pr. ALLAOUA CHAOUI DEVANT LE JURY : Président Rapporteur Examinateur Examinateur Examinateur Pr. ZIZETTE BOUFAIDA Université Constantine 2 Pr. ALLAOUA CHAOUI Université Constantine 2 Dr. NADIA ZEGHIB Université Constantine 2 Pr. DJAMEL MESLATI Université de Annaba Dr. ZINEDDINE BOURAS EPST Annaba

2

3 Mes remerciements Au Professeur ALLAOUA CHAOUI pour avoir bien voulu diriger ce travail. Je lui suis très reconnaissant de m avoir apporté ses précieuses lumières tout au long de cette thèse, pour son encadrement et surtout pour son aide sincère et efficace, notamment dans la validation de mes travaux et leurs publications. Qu il trouve ici l expression de ma profonde gratitude. Mes remerciements vont au Pr. Z. BOUFAIDA qui a accepté de présider le jury et à tous les membres du jury, Pr. D. MESLATI, Dr. N. ZEGHIB et Dr. Z. BOURAS. Je suis sensible au fait qu ils aient bien voulu accepter de juger mon travail et surtout au temps qu ils y ont consacré. Je tiens également à remercier mes parents et mes sœurs qui n ont jamais cessé de m encourager durant l élaboration de ce travail, ainsi que pour le soutien moral qu ils m ont apporté dans les moments les plus difficiles.

4 Dédicaces A ma mère et à mon père, A ma fiancée, A toute ma famille et tous mes amis, A tous mes collègues, Je dédie cette thèse.

5 Résumé Ces dernières années ont vu l émergence d un nouveau style architectural reflété par les architectures orientées service (SOA). Celles-ci sont conçues pour faciliter la création, l exposition, l interconnexion et la réutilisation d applications à base de services. Plusieurs réalisations de ce type d architecture ont vu le jour dont la plus commune se base sur les services Web. Les services Web sont des applications auto descriptives et modulaires fournissant un modèle simple de programmation et de déploiement d applications. La composition de services Web, en particulier l orchestration, est au cœur de l ingénierie à base de services puisque elle supporte la construction de nouveaux services composés à partir de services de base. Dans le but de faciliter la composition, WS-BPEL (ou BPEL) s est imposé comme le langage standard d orchestration de services Web. Ce langage décrit la composition de services Web sous forme de processus métiers. Cependant, les processus métiers décrits à l aide de ce langage ne peuvent pas être analysés formellement. Ceci est principalement dû au manque de sémantique formelle dont soufre ce langage. De plus, BPEL se base principalement sur des concepts purs de programmation et néglige de ce fait une étape cruciale du cycle de vie de toute application qui est l étape de spécification. Nos travaux de thèse proposent une approche de composition de services Web qui ne néglige aucun aspect du processus de composition. L approche proposée traite la modélisation, l'analyse formelle et la réalisation des compositions de services Web sous forme d orchestration de services. Nous allons définir dans les différentes parties de la thèse des méthodes et des outils efficaces permettant à un concepteur d application à base de services de contrôler le processus de composition des services Web de bout en bout. Notre approche se présente sous forme d une méthodologie qui se déroule en plusieurs étapes et s appuie sur une approche de développement bien établie qui est l ingénierie dirigée par les modèles (IDM). Plus précisément, nous allons faire usage d un langage de modélisation graphique de type réseaux de Petri pour obtenir des modèles de composition de services Web. Ces modèles subissent diverses transformations afin d aboutir à une réalisation de composition de services Web correcte. Etant donné que le langage de modélisation se pressente sous forme de graphes, nous utilisons un type de transformation particulière de l IDM qui est la transformation de graphe. Mots clefs : Service Web, orchestration, vérification formelle, réseaux de Petri, ingénierie dirigée par les modèles, transformation de graphe.

6 Abstract The few last years have seen the emergence of a new software architecture style reflected through service oriented architectures (SOA).These are designed to make easy the creation, exhibition, interconnection and reuse of service-based applications. Several realizations of this type of architecture have emerged. The most common one is based on Web services. Web services are self-descriptive and modular applications that provide a simple programming and application deployment model. The Web services composition, especially the orchestration, is at the heart of service-based engineering because it supports the construction of new composed services from basic ones. In order to facilitate the composition, WS-BPEL (or BPEL) has emerged as the standard language for Web services orchestration. This language describes the Web services composition in the form of business processes. However, business processes described using this language cannot be formally analyzed. This is mainly due to the fact that BPEL does not provide a mathematically sound semantic. In addition, BPEL is based on pure programming concepts and thus neglects a crucial step in the life cycle of any application that is the specification step. Our thesis proposes a Web services composition approach that addresses every aspect of the composition process. The proposed approach deals with the modeling, the formal analysis and the implementation of Web services compositions as a services orchestration. We will define in the different parts of the thesis efficient methods and tools to help service-based application designer to control the process of Web service composition from the beginning to the end. Our approach takes the form of a methodology that involves several steps and is based on a well-established development approach which is model-driven engineering (MDE). More specifically, we make use of a graphical modeling language (a kind of Petri nets) to obtain Web services composition models. These models pass through various transformations in order to achieve a correct implementation of Web services composition. Given that the modeling language used in our work is in the form of graphs, we exploit a particular kind of model transformation which is graph transformation. Keywords: Web services, orchestration, formal verification, Petri nets, model driven engineering, graph transformation.

7 ص د دت ا وات ا ظور ط دد د ارت وھ اد او و ادت( SOA ). ود ت ل ق رض رط وإ دة ا دام اط$ت ا دة إ% د. ظرت ا&دد ن ازات ن ھذا اوع ن اد. وا-,+رو &د %دت اوب. دت اوب ھ ط$ت ذااوف وودااو 0 روذج طروراط$ت. ر,ب دت اوب ھو م 0 اد او و ادت -2 د م ء دت ددة 4 ف ن دت أ. 6 رض ل ار,ب رز,6 BPEL ر,ب دت اوب. ھذها 6 فر,ب دت اوب %,ل ت ر. و 9 ذك ا&ت ار اوو 0 دام ھذه ا6 ;,ن ر وھذا را 9 أ إ%أنھذها 6 ;و 0 ر&%ر. > 0 إ%ذك د ھذها 6 %=ھمارول طوة 0 دورة ة أيطقا ھطوةاوا=ت. $رح أطرو و از ر,ب دت وب ا ول,ل ب ن واب ار,ب. وا;ز ا$رول اذ الار و=ذرا,ب دت اوب. و وف دد 0 ا-زاء ا= ن أطرو ا- ب وا-دوات % دت اوب ا 0 طرة % د م ا ار,بناداإ A. و از 4 ذ,ل وي % دة طوات و د إ% طر$ را ا ھ اد او ن طرف ادج. و 4,+ر دد دم 6 اذ ار و (وعن,ت ري) ول % ذجر,ب دت اوب. ھذه اذج ر ر و Bت = ن أل $ق ا=ذ اC ر,ب دت اوب. ظر إ% أن 6 اذ ا د 0 ھ رة ن ر وم 6 لوع&ننولادجاذيھوولار ما.

8 Sommaire du manuscrit Introduction générale Contexte et problématique Objectifs de la thèse Organisation du manuscrit... 4 Chapitre 1 Architectures Orientées Service Introduction Architectures orientées services (SOA) Service Environnement d intégration des services Le modèle d interactions d une SOA SOA, avantages et défis Architecture orientée service Web (WSOA) Définition et concepts de service Web Les standards des services Web SOAP (Simple Object Access Protocol) UDDI (Universal Description, Discovery and Integration) WSDL (Web Services Description Language) La composition de services Web Orchestration vs Chorégraphie de services L Orchestration La Chorégraphie Composition statique vs Dynamique BPEL4WS (Business Process Execution Language for Web services) Anatomie d un processus BPEL Description des liens et des variables du processus Description du comportement du processus BPEL Vs Control-flow Patterns Les composantes de l architecture de BPEL Modélisation et Analyse formelle de la composition de services Web Synthèse et conclusion Chapitre 2 Ingénierie Dirigée par les Modèles... 33

9 1. Introduction Les principes généraux de l IDM Modèle et Méta-modèle Les langages de modélisation Syntaxe abstraite et sémantique statique Syntaxe concrète Sémantique dynamique La transformation de modèles Classification des transformations de modèles Nombre de modèles source et cible Appartenance à l espace technique Transformation Endogène versus Exogène Transformations horizontale versus verticale Transformations Syntaxiques versus sémantiques Le type du modèle source et cible Caractéristiques importantes d une transformation de modèles Degré d automatisation Complexité de la transformation Préservation Standards, langages et outils pour l IDM L environnement GME (Generic Modeling Environment) AGG (Attributed Graph Grammar system) Les éditeurs Meta-CASE DiaGen (Diagram Editor Generator) Eclipse (EMF) AToM 3 (A Tool for Multi-formalism and Meta-Modelling) ATL (ATLAS Transformation Language) Kermeta (Kernel Meta-Modeling Language) Concepts de graphe et de transformation de graphes Approches de composition des services Web dirigée par les modèles Approches utilisant les langages formels Approches utilisant les réseaux de Petri Approches utilisant les algèbres de processus Approches utilisant les systèmes de transition d états... 54

10 5.2. Approches utilisant les langages de modélisation des processus métiers Approches utilisant BPMN Approches utilisant UML Conclusion Chapitre 3 La Méthodologie WS-mcv Introduction Le formalisme G-Net Les concepts des G-Nets Les arcs Les places ISP Les Jetons Les transitions Méta-modélisation du formalisme G-Net S-GNet : Extension des G-Nets pour la modélisation des services Web La méthodologie WS-mcv Phase de sélection Phase d extraction des interfaces de services Phase de spécification du modèle de composition Phase de vérification du modèle de composition Phase d implémentation Conclusion Chapitre 4 Extraction des Interfaces et Spécification de la Composition des Services Web Introduction Méta-modélisation du Formalisme S-GNet avec AToM Phase d extraction des interfaces des services Web intervenants Formalisation Transformation WSDL vers S-GNet Exemple Mise en œuvre Phase de spécification du modèle de la composition Opérateurs de composition Sémantique formelle Notations utilisées... 90

11 Définition des opérateurs Grammaire de graphe pour la composition Exemple Mise en œuvre de la composition Conclusion Chapitre 5 Vérification et Implémentation du Modèle de Services Web Composé Introduction Phase de Vérification du modèle obtenu Méthode de transformation Déroulement de la phase de vérification Phase d Implémentation du modèle de composition Transformation S-GNet vers BPEL Grammaire de génération de code BPEL Mise en œuvre Conclusion Conclusion générale Bibliographie

12 Liste des Figures Figure 1.1 Environnement d intégration de services Figure 1.2 Les acteurs d une architecture à services Figure 1.3 Structure d un message SOAP Figure 1.4 Structure d un document WSDL Figure 1.5 Architecture des services Web Figure 1.6 Orchestration vs Chorégraphie de services Figure 1.7 Le flot de processus avec BPEL4WS Figure 1.8 Processus interprété par un moteur WS-BPEL Figure 1.9 Syntaxe de déclaration des éléments BPEL Figure 1.10 Syntaxe de déclaration des activités simples Figure 1.11 Syntaxe de déclaration des activités structurées Figure 2.1 L'architecture de méta-modélisation à quatre niveaux Figure 2.2 Méta-modèles et langages de modélisation Figure 2.3 Concepts basiques de la transformation de modèles Figure 2.4 Exemples de types de transformations de modèles Figure 2.5 Relation entre un modèle et sa représentation par un graphe Figure 2.6 Principe de règle de transformation de graphe Figure 2.7 Exemple d une étape de transformation utilisant la règle payfacture Figure 2.8 Classification des approches basées IDM pour la composition des services Web Figure 3.1 Notations utilisées pour la représentation d un G-Net Figure 3.2 Un exemple de modélisation en utilisant les G-Nets Figure 3.3 Le méta-modèle des G-Nets Figure 3.4 Le Méta-modèle des S-GNets Figure 3.5 Notations utilisées pour la représentation d un S-GNet Figure 3.6 Les principales étapes de l approche WS-mcv Figure 4.1 Elaboration de l outil de modélisation S-GNets sous AToM Figure 4.2 Outil de modélisation S-GNets généré avec AToM Figure 4.3 Edition de modèles S-GNet au sein du DSL Figure 4.4 Méthode de transformation de WSDL vers les S-GNets Figure 4.5 Règles de transformation de WSDL vers S-GNet Figure 4.6 Description WSDL du service BookingHotel et sa spécification S-GNet équivalente 85 Figure 4.7 Description WSDL du service BusTiketService et sa spécification S-GNet équivalente Figure 4.8 La règle 1 de transformation WSDL vers S-GNet dans l éditeur de règles d AToM Figure 4.9 Description WSDL du service Web BookingHotel Figure 4.10 La spécification S-GNet du service BookingHotel obtenu avec notre l outil généré. 88 Figure 4.11 Représentation graphique des opérateurs de l algèbre en termes de S-GNets Figure 4.12 Grammaire de graphe pour la composition, Règles Figure 4.13 Grammaire de graphe pour la composition, Règles Figure 4.14 Grammaire de graphe pour la composition, Règles Figure 4.15 Résultat de composition par la grammaire de graphe Figure 4.16 Processus d implémentation de la grammaire de graphe pour la composition

13 Figure 4.17 La règle N 3 de la grammaire de graphes pour la composition des services Web dans AToM Figure 4.18 Modèle du service composé TravelAgent avec l outil généré Figure 5.1 Schéma de la plate-forme pour l analyse des G-Nets Figure 5.2 Adaptation du service TravelAgent en G-Net Figure 5.3 Le modèle PrT-Nets équivalent au G-Net TravelAgent Figure 5.4 Fichier contenant la description PROD 1/ Figure 5.5 Fichier contenant la description PROD 2/ Figure 5.6 Méthode de transformation des spécifications S-GNets vers du code BPEL Figure 5.7 Grammaire de graphe pour la génération de code BPEL Figure 5.8 Processus d implémentation de la grammaire de graphes pour la génération de code BPEL Figure 5.9 La règle n 8 de la grammaire de graphes pour la génération de code BPEL Figure 5.10 Fichier contenant la description du processus BPEL

14 Introduction Générale

15 Introduction générale Introduction générale 1. Contexte et problématique Au cours des dernières décennies, l'évolution des systèmes logiciels a conduit à une croissance continue du niveau de complexité et de la maturation des réseaux et des protocoles. L'intégration des applications et leur interopérabilité, la flexibilité de leur mise en œuvre et de leur reconfiguration sont apparues comme des exigences essentielles pour les solutions technologiques et les styles architecturaux modernes. Ces exigences ont conduit à l émergence de méthodes et d approches qui prennent en charge la conception des systèmes d une manière efficace et permettent en même temps un haut degré de modularité et de réutilisation des composants. L'évolution des styles architecturaux a soutenu cette tendance en donnant lieu à des approches axées sur les services. L'architecture orientée services (SOA pour Service Oriented Architecture), en tant que paradigme architectural, constitue un accomplissement de telles approches en permettant l exposition, l interconnexion et la réutilisation d applications à base de services et ce, en dépit de l hétérogénéité des domaines, des technologies et des fournisseurs impliqués. L une des mises en œuvre d applications à base d architecture orientée services la plus utilisée est la technologie des services Web. Elle se concentre sur la définition d'un système logiciel comme une application distribuée qui implique une composition d'agents logiciels indépendants et interconnectés. Ces agents fournissent leurs fonctionnalités sous forme de services disponibles sur le Web et collaborent ensemble dans le but de réaliser un ensemble d'objectifs offrant des capacités à tendance commerciale. Dans la technologie des services Web, l infrastructure de base est constitutée des standards : WSDL (Web Service Description Language), UDDI (Universal Description, Discovery and Integration) et SOAP (Simple Object Access Protocol). Les Web services permettent aux entreprises de rendre accessibles leur information et expertise via Internet. Une fois le service Web développé, l entreprise publie la description de son interface en utilisant WSDL. Du point de vue de l utilisateur, cette description constitue la seule information disponible concernant le service. Les utilisateurs du service Web accèdent à la description WSDL via des registres spécifiques tels qu UDDI. SOAP est le protocole standard utilisé pour interagir avec les services Web. Ce protocole décrit entre autres le format des messages échangés. Un service Web présente la particularité d offrir des fonctionnalités spécifiques à une tâche et, la plupart du temps, ne peut répondre aux exigences des usagers. Afin de fournir à ces utilisateurs des services personnalisés, il est parfois nécessaire d organiser des services de base existants et de les combiner, offrant ainsi de nouvelles fonctionnalités. Dans ce contexte, deux principaux axes ont reçu une grande attention de la part des organisations de la recherche et de l industrie. Le premier concerne la sélection des services dont les fonctionnalités répondent aux besoins des utilisateurs. Ce processus, qui est appelé sélection des services Web, est réalisé en utilisant un ensemble de critères. Le second axe de recherche concerne le processus de combinaison des services 1

16 Introduction générale sélectionnés (appelés services composants) en un service composite. Le processus réalisant cette tâche est appelé composition des services Web. En conséquence, la tendance actuelle est d'exprimer la logique d'un service Web composite en utilisant un langage de modélisation des processus métiers adapté aux services Web. Un certain nombre de langages de ce type ont émergé tels que BPML (Business Process Modeling Language), BPEL (Business Process Execution Language) et WSCI (Web Service Choreography Interface). Parmi ces langages, BPEL a été désigné comme le langage standard pour la description de la composition des services Web sous forme de processus métier. L inconvénient majeur de ces langages de composition est qu ils s'appuient sur des concepts purs de programmation et ont été conçus pour l implémentation et l exécution des services composites sans prendre en considération les étapes de la spécification et de la vérification du service composite. La spécification constitue une étape cruciale dans le cycle de vie de n importe quelle application et est particulièrement importante parce que : 1) Elle renforce la compréhension globale du système 2) Elle permet de se détacher de l implémentation et d obtenir des modèles abstraits plus clairs 3) Lorsque le modèle est suffisamment expressif et précis, il peut servir de base pour l implémentation par génération automatique de code à partir du modèle de composition. De plus, la description des compositions de services Web en utilisant des langages tels que BPEL rend difficile l analyse formelle de la composition. Ceci est principalement dû au fait que ces langages ne fournissent pas une sémantique formelle. Il est donc nécessaire de développer des méthodes de spécification et de vérification pour contrôler la globalité du processus de développement d un service Web composite. Parce que la composition des services Web est une tâche prédisposée aux erreurs et que les partenaires intervenant dans la composition ont des interactions complexes, il y a un intérêt croissant pour les techniques de modélisation et de vérification des compositions des services Web. Ces techniques permettent aux concepteurs 1) de mieux comprendre et de spécifier le comportement d une composition de services désirée et 2) de tester et de réparer les erreurs de conception avant même le fonctionnement réel de l application exposée sous forme de service. Un certain nombre de travaux ont essayé de remédier à ces problèmes en proposant des techniques de transformation de spécification de compositions de services Web décrites dans un langage tel que BPEL vers un langage formel de modélisation. Ces transformations ont pour but d utiliser des outils d analyse formelle dédiés aux langages cibles des transformations. Cependant ces approches ne résolvent que partiellement le problème car elles raisonnent sur des spécifications décrites dans des langages de composition (sous forme textuelle) qui représentent l implémentation réelle du service composé, ce qui complique la compréhension du système. De plus, l analyse des services Web devrait permettre de tester et réparer les erreurs de conception avant même la mise en œuvre et le fonctionnement réel du service composé. On peut qualifier ces approches 2

17 Introduction générale comme des approches ascendantes, car elles raisonnent sur un système déjà réalisé (le service Web composite) au lieu de raisonner sur un modèle de composition et de le valider pour ensuite le réaliser. Afin de répondre à ce besoin, d autres travaux avec une toute autre approche ont vu le jour. Ces travaux suivent les principes de l ingénierie dirigée par les modèles pour obtenir le service Web composé. Après élaboration du modèle dans un langage de modélisation, la vérification de la composition s effectue sur le modèle de service composé et non sur le service lui-même. L avantage ici est la réduction des risques et des efforts de développement en générant directement un service composé correct à partir de son modèle. 2. Objectifs de la thèse L objectif principal de nos travaux de thèse est de faciliter la réalisation d applications à base de services Web en proposant une approche de conception et de développement des processus métiers de services Web intégrant des techniques de modélisation et d'analyse formelles qui permettent l'évaluation de la justesse du comportement du système (le service Web composé). Selon notre optique, une telle approche devrait être en mesure de résoudre les tâches suivantes: 1) L apport d un cadre formel aux descriptions des services Web à composer, 2) La modélisation formelle des comportements de composition avec un niveau d abstraction assez élevé, 3) La validation de la spécification de la composition et 4) La génération automatique du code exécutable à partir de la spécification. Pour cela, nous désirons fournir des environnements logiciels spécialisés qui soient adaptés à chaque phase du cycle de vie du processus de composition, depuis la spécification du modèle composite jusqu à son exécution. L ingénierie dirigée par les modèles (IDM) est une approche de développement logicielle qui se concentre sur la réalisation de modèles abstraits plutôt que sur des concepts algorithmiques. Elle offre les moyens pour concevoir des modèles, effectuer des raisonnements sur ces modèles, vérifier leur bon fonctionnement, et générer le code à partir des modèles. Ces principes sont réalisés en choisissant un langage formel de modélisation adapté qui est ensuite méta-modélisé pour obtenir un outil de modélisation. Les modèles obtenus passent par différentes transformations de modèles afin d aboutir au objectifs. Les services Web composés étant des systèmes logiciels comme d autres, les principes de l IDM peuvent tout à fait être appliqués à leur développement. Dans le cadre de la définition de notre approche de composition, nous allons donc appliquer ces principes durant toutes les étapes de l approche. Le langage de modélisation dont nous allons faire usage est un langage dérivé des réseaux de Petri qui est les S-GNet. Les S- GNet constituant un formalisme visuel dont la structure peut de façon naturelle être décrite par des graphes, nous proposons d appliquer une technique particulière de l IDM qui est la transformation de graphes. Il s agit d une technique déclarative basée sur des règles dont la popularité ne cesse de croitre pour deux raisons. La première est due à son caractère visuel qui facilite l élaboration des règles de façon intuitive, la seconde est due à 3

18 Introduction générale son caractère formel qui fait que les règles en question peuvent se prêter à une analyse. Les objectifs de notre thèse peuvent se résumer dans les points suivants : 4 1) Définition d un DSL (Domain Specific Language) adapté aux services Web : pour cela nous allons étendre un formalisme existant et bien établi qui a déjà été utilisé pour la modélisation des systèmes complexes et distribués nommé G-Nets. Cette extension, que nous avons baptisé S-GNet, est bien adaptée à la structure des services Web et permet une modélisation concise et intuitive. 2) Elaboration d un outil de modélisation dédié aux S-GNets : ceci en réalisant une méta-modélisation du nouveau formalisme (S-GNet) au sein d un outil adapté à la méta-formalisation. Il sera ainsi aisé de générer un outil de modélisation à partir du méta-modèle. 3) Définition d un cadre formel pour les descriptions de services Web : pour cela nous allons définir des règles de passage de descriptions syntaxiques WSDL vers le formalisme S-GNet. Ces descriptions spécifiées en S-GNet constituent les briques de base pour construire le modèle de composition. 4) Définition d une méthode de construction du modèle de composition : pour cela, nous allons définir une algèbre de composition avec un ensemble d opérateurs qui permettent de manipuler les modèles de services intervenant dans la composition. 5) Définition de moyens de vérification du modèle de composition décrit en S- GNets : cet objectif sera réalisé par des adaptations du modèle de services Web qui nous permettront d utiliser l outil d analyse PROD. 6) Définition d une méthode permettant l implémentation du modèle de composition : cet objectif est très important car il nous permettra de concrétiser toutes les manipulations effectuées auparavant en générant automatiquement du code BPEL à partir du modèle de service Web composé spécifié en S-GNet. Toutes les transformations de modèles présentes au sein de notre approche seront réalisées au sein de l outil pour la méta-modélisation et la transformation de modèles AToM 3. Celui-ci a été choisi parce qu il constitue un outil puissant, facile d utilisation, libre d accès et qu il répond pleinement à nos besoins de développement. 3. Organisation du manuscrit Outre l introduction, ce rapport de thèse est composé de deux parties principales : la première partie composée de deux chapitres présente l état de l art et les motivations pour la définition d une nouvelle approche de composition de services Web. La seconde partie, composée de trois chapitres, décrit notre approche, le formalisme que nous proposons ainsi que les moyens mis en œuvre pour réaliser notre approche. Partie 1: État de l art Cette partie présente un état de l art sur les architectures orientées services et sur les techniques de l ingénierie dirigée par les modèles. Le chapitre 1 a pour objectif d éclaircir tous les concepts relatifs à la SOA. Dans la première partie nous présentons en premier lieu la notion de service et d architecture orientée service en identifiant l origine des termes avec leurs principales définitions. Dans

19 Introduction générale la seconde partie, nous abordons une implémentation bien particulière de la SOA qui est l architecture orientée service Web (WSOA). Nous y définissons le concept de services Web, la composition de services Web et nous y présentons brièvement les différents standards qui encadrent les services Web. La troisième partie est consacrée au langage standard pour la composition des services Web qui est BPEL. Dans la quatrième partie du chapitre nous mettons l accent sur la nécessité de procéder à la vérification des compositions de services Web. Nous terminons le chapitre par une conclusion dans laquelle nous faisons une synthèse sur les problèmes posés par la composition des services Web. Le chapitre 2 présente les fondements de l IDM et plus particulièrement ceux de la transformation de graphes. Nous y verrons notamment les standards et les outils disponibles permettant de maintenir d une façon efficace et performante les modèles manipulés au cours du processus de transformation de modèles. Nous y étudions par la suite les approches qui ont appliqué les principes de l IDM pour la composition de services Web. Nous y proposons notamment, une classification de ces approches selon le formalisme utilisé. Nous terminons le chapitre par une synthèse en positionnant notre travail par rapport à des travaux de recherche développés dans le domaine. Partie 2: Contributions Cette partie décrit notre approche pour la modélisation et la vérification de composition des services Web en appliquant les principes de l IDM. Le chapitre 3 commence par une introduction au langage de modélisation G-Net ainsi que les motivations qui ont conduit à son utilisation comme base pour notre approche. Nous définissons ensuite une extension de ce langage qui le rend spécifique au domaine des services Web. Les concepts de cette extension, baptisée S-GNet, sont capturés au sein d un méta-modèle. Ce dernier est par la suite utilisé afin d obtenir un outil de modélisation dédié aux S-GNet. Le chapitre se termine par un aperçu des différentes étapes de la méthodologie WS-mcv que nous proposons. Pour chaque étape, nous présentons les moyens mis en œuvre ainsi que les solutions proposées pour la résolution de chacune des tâches de la méthodologie. Le chapitre 4 aborde les deux premières phases de la méthodologie WS-mcv, à savoir la spécification des services intervenant et la modélisation de la composition de ces services. Ces deux phases sont réalisées en suivant les principes phares de l IDM qui sont la méta-modélisation et la transformation de modèles. Nous montrons comment les modèles S-GNets des services Web participants dans le processus de composition sont obtenus à partir de leur description dans le langage standard WSDL. Cette phase de l approche rentre dans le cadre d un type spécifique de transformation de modèles qui est la rétro-ingénierie. Celle-ci est mise en œuvre par une grammaire de graphes. Nous présentons ensuite une algèbre basée S-GNet dont les opérateurs résolvent d une manière efficace la composition complexe des services Web. Nous réalisons les différents opérateurs de l algèbre par une deuxième grammaire de graphes. Nous présentons également dans ce chapitre les détails techniques relatifs à l implémentation de chacune de ces étapes au sein de l environnement de modélisation que nous avons généré. 5

20 Introduction générale Le chapitre 5 est consacré à la présentation détaillée des deux dernières phases de notre méthodologie qui sont la vérification du modèle de composition et l implémentation de ce modèle. Pour mettre en œuvre la phase de vérification, nous proposons d exploiter les règles de transformation qui permettent de transformer des spécifications S-GNet en des réseaux prédicats/transition (PrT-Nets). Cette transformation a pour objectif d exploiter les outils existants munis d une grande variété de techniques d analyse comme l outil PROD. La phase d implémentation, dont l objectif est la génération de code BPEL est également mise en œuvre par une grammaire de graphes permettant, à partir de spécifications S-GNet de modèles de services composés, de générer le code BPEL correspondant. Ce dernier permet de définir un processus BPEL implémentant le modèle du service Web composite. Pour chacune des deux phases, nous expliquons comment les grammaires sont intégrées à l outil de modélisation obtenu avec AToM 3. Le manuscrit se termine par une conclusion générale dans laquelle nous résumons les principales contributions de cette thèse, nous discutons des objectifs atteints et nous introduisons quelques perspectives à notre travail. 6

21 Chapitre 1 Architectures Orientées Service

22

23 Chapitre 1 : Architectures Orientées Service Chapitre 1 Architectures Orientées Service 1. Introduction La complexité croissante des systèmes d'information, la nécessité de faire face au développement des réseaux et l avènement du Web, de même que la nécessité pour les organisations de gérer et d'adapter leurs entreprises d une manière efficace afin de répondre rapidement à ces changements ont conduit à l'évolution de l informatique distribuée. Dans le but de relever ces défis, l'informatique distribuée a dû passer par le modèle client-serveur, l'architecture à plusieurs niveaux, les standards basés RPC (comme CORBA [OMG, 1991]), pour enfin aboutir à l architecture orientée service. De nos jours, l environnement de la technologie Internet vise à assurer l'efficacité et la flexibilité de l opérationnalisation à travers et au-delà des limites des entreprises, permettant ainsi leur interopérabilité. Le principal défi est de simplifier l'intégration des fonctionnalités d'entreprise, quel que soit l'hétérogénéité possible des plates-formes d'implémentation, des protocoles et des outils. L architecture orientée services ou SOA (pour Service Oriented Architecture) exploite les services comme constructions principales afin de fournir des applications d'entreprise distribuées à faible coût, flexibles et évolutives. Bien que la SOA ne soit pas une implication directe d'une certaine technologie et qu elle ait été appliquée au développement des logiciels avant l'invention de services Web, les architectures les plus aptes à réaliser la vision de la SOA sont construites avec les technologies de services Web. Dirigée par ces technologies compétentes, l'entreprise manipule des standards ouverts pour la communication à travers le réseau et l échange de services. Dans ce chapitre, nous donnons un aperçu du domaine d intérêt en présentant en premier lieu tous les concepts relatifs à la SOA comme la notion de service qui en constitue la brique de base, l environnement dans lequel s intègrent les services, ainsi que le modèle d interactions de la SOA, définissant ainsi ses principaux acteurs et les interactions entre eux. Ensuite, nous abordons une implémentation bien particulière de la SOA qui est l architecture orientée service Web (WSOA). L'aspect clé de cette technologie est l'utilisation de protocoles et de langages normalisés, conçus pour améliorer l'intégration entre les parties coopérantes. Ces standards couvrent pratiquement tous les aspects relatifs à la représentation et l'échange de données d'entreprise, la description des caractéristiques fonctionnelles et non fonctionnelles d'un service, l'agrégation, la coordination et la gestion d'un ensemble de services. Les principes relatifs à la WSOA sont introduits avec un regard particulier pour la conception des services, la composition et la vérification formelle de ces compositions. Ce chapitre est organisé comme suit : dans la section 2, nous présentons les différentes caractéristiques du paradigme SOA ainsi que tous les concepts de base sur lesquels elle s articule. Nous nous intéressons ensuite à une mise en œuvre particulière de ce type d architectures basée sur l utilisation de services Web et introduisons, dans la section 3 les principaux standards, langages et protocoles relatifs à cette mise en œuvre. La section 4 est consacrée à la définition du processus de composition des services Web 7

24 Chapitre 1 : Architectures Orientées Service et les solutions actuelles pour sa mise en œuvre. Nous nous étendons principalement sur le langage BPEL qui est le standard dédié à l exécution des processus d entreprises. Le problème d analyse formelle des compositions des services Web et leur vérification est présenté dans la section 5. Le chapitre est terminé par une conclusion dans laquelle nous faisons une synthèse sur les problèmes posés par la composition des services Web. 2. Architectures orientées services (SOA) Il existe plusieurs façons de percevoir une Architecture Orientée Services. Dans la littérature, le concept de SOA est le sujet de définitions très variées. [Dodani, 2004] propose la définition suivante: L architecture orientée service est un paradigme qui permet l intégration d applications et de ressources de manière flexible en : (1) représentant chaque application ou ressource sous la forme d un service exposant une interface standardisée, (2) permettant à un service d échanger des informations structurées (messages, documents, objets métier ), (3) coordonnant et organisant les services afin d assurer qu ils puissent être invoqués et utilisés de manière efficace. D autres définitions proposées par différents experts du domaine peuvent être trouvées dans la littérature [Endrei et al., 2004][Marin, 2008][Pourraz, 2007]. Ces définitions se placent selon différents points de vue qui vont plus ou moins dans le même sens. nous pouvons affirmer d une manière générale que l architecture orientée services est un style architectural pour la conception, le développement, le déploiement et la gestion de systèmes logiciels distribués qui délivre des fonctionnalités d application sous forme de services interopérables, soit à l'utilisateur final ou à d autres services. Les systèmes qui sont construits en se basant sur les caractéristiques SOA sont appelés systèmes orientés services Service Le service est la brique de base de la SOA. Il représente une entité logicielle fonctionnelle déployée et invocable à distance. Il est difficile de trouver une définition exacte du terme «Service» parce que plusieurs définitions existent. Dans [Dodani, 2004] un service est défini comme une entité qui représente certaines fonctionnalités (application fonctionnelle, transaction commerciale, un service du système de base, etc.) exposée en tant que composant d'un processus métier. Un service est défini à l'aide d'une interface qui expose les fonctionnalités et masque les détails de mise en œuvre sousjacents. Le service doit être sans état pour assurer qu'il ne dépend pas de l'état ou du contexte d'autres services. Les services sont appelés via des protocoles de communication bien définis qui mettent l accent sur l'interopérabilité et la transparence de localisation. Selon [Hashimi, 2003] A service in SOA is an exposed piece of functionality with three properties: 1)The interface contract to the service is platform-independent. 2) The service can be dynamically located and invoked. 3) The service is self-contained. That is, the service maintains its own state. A travers les différentes définitions, plusieurs caractéristiques spécifiques aux services apparaissent : 8

25 Chapitre 1 : Architectures Orientées Service Les services sont réutilisables : La réutilisation veille à ce que chaque fonctionnalité de service ne soit mise en œuvre qu une seule fois et peut être utilisée plusieurs fois. Les services partagent un contrat formel : Le contrat (description) définit comment communiquer avec un service particulier. Les services sont faiblement couplés : Le couplage faible est un concept qui permet de minimiser les dépendances. Cela conduit à une meilleure flexibilité. Les services agissent comme des boîtes noires : C'est à dire qu'ils cachent leurs détails à leur environnement extérieur et ne sont accessibles que par l'intermédiaire de leurs interfaces. Les services sont composables : La composition des services est basée sur le fait que les services peuvent être utilisés par d'autres services. C'est-à-dire qu un service est conçu de façon à participer à des compositions de services. La composition peut être considérée comme une autre forme de la réutilisation, car un service particulier peut agir dans plusieurs compositions. Les services sont autonomes et ils contrôlent la logique qu'ils encapsulent. Ceci appuie d'autre principes, tels que le couplage faible. Les services sont sans état : C est-à-dire que les services ne conservent pas les informations d'état entre les différents appels du service. Cela signifie qu après que l'appel de service soit terminé, toutes les informations locales qui ont temporairement été créées pour cet appel sont supprimées. Un service est découvrable : Un service est complété par un ensemble de métadonnées de communication au travers desquelles il peut être découvert et interprété de façon effective. Ce sont ces principes spécifiques aux services qui permettent de se détacher de tout aspect technologique car les services sont autonomes, c est à dire qu ils sont indépendants du contexte d utilisation ainsi que de l état des autres services, et qu ils inter-opèrent via des protocoles standardisés. Dans ce qui suit, nous allons voir comment faire interagir ces services au sein d un environnement. On parle alors d architecture orientée service Environnement d intégration des services L architecture orientée services offre un environnement d intégration et d exécution des services dont les éléments peuvent être divisés en deux catégories : Les éléments traitant les aspects fonctionnels Les éléments traitant les aspects qualité de service Comme illustré dans la figure 1.1, les aspects (ou éléments) fonctionnels incluent : Le transport : est le mécanisme utilisé pour déplacer les requêtes de service du consommateur de services au fournisseur de service, et les réponses des services du fournisseur de service au consommateur de service. Le protocole de communication : est un mécanisme utilisé par le fournisseur et le consommateur de service pour communiquer le contenu des requêtes et des réponses. 9

26 Chapitre 1 : Architectures Orientées Service La description de service : est un schéma spécifique pour décrire les fonctionnalités du service, la manière dont il doit être invoqué et les données requises pour invoquer le service correctement. La composition de services : est une collection de services, invoqués dans une séquence particulière, pour répondre à un besoin particulier. Il est à noter qu une composition de services est considérée comme étant un service en elle-même. Le registre (ou annuaire) de services : est un répertoire des descriptions de service et des données. Il peut être utilisé par les fournisseurs de services afin de publier leurs services, comme il peut être utilisé par les consommateurs de services afin de découvrir les services disponibles. Figure 1.1 Environnement d intégration de services Les aspects (ou éléments) concernant la qualité de services quant à eux incluent : L accord de service (ou contrat de service) : est un ensemble de règles ou de conditions sous lesquelles un fournisseur de services rend le service disponible aux consommateurs. Il y a des aspects du contrat qui sont fonctionnels, et des aspects qui concernent la qualité de service comme par exemple, un niveau de performances (temps de réponse, fiabilité, etc.). La sécurité : est l'ensemble des règles qui peuvent être appliquées lors de l'identification, de l'autorisation, et du contrôle d'accès des consommateurs qui invoquent les services. Le consommateur peut aussi demander l utilisation de règles de sécurité. Par exemple, dans le cas où il veut garantir l intégrité des données transmises. Transaction : un environnement d intégration de services peut contenir un élément chargé de garantir la cohérence des données utilisées et des résultats retournés par une collaboration (ou composition) de services. 10

27 Chapitre 1 : Architectures Orientées Service Management de service : est le processus chargé de surveiller et de contrôler de manière proactive le comportement d'un service ou d'un ensemble de services. Le management de service s opère sous des contraintes qui dépendent du contexte commercial Le modèle d interactions d une SOA Pour garantir une évolution et une intégration facile des applications hétérogènes au sein d une architecture orientée services, l approche à service prévoit un modèle d interaction basé sur différents acteurs et des interactions entre eux. La figure1.2 montre que l utilisation des services par ces acteurs suit un protocole spécifique qui est : la publication, la découverte et l invocation. Les acteurs collaborant dans une SOA sont [Dieng, 2010] [Endrei et al., 2004] : 1) Le fournisseur de service : est une entité adressable par réseau qui développe un ensemble de fonctionnalités sous forme de service. Ces fonctionnalités sont décrites dans une description appelée spécification de service. Cette dernière contient l ensemble des informations nécessaires à l utilisation du service. Les informations peuvent aussi concerner les propriétés non-fonctionnelles du service (i.e. celles concernant la qualité de service). Le fournisseur de service publie la spécification du service dans le registre de services afin que les consommateurs de services puissent découvrir et accéder au service. 2) Le consommateur de service (ou utilisateur de service) : est une application, un module logiciel ou un autre service qui interroge le registre de services pour obtenir les services disponibles qui correspondent à ses besoins. Il utilise une spécification de service disponible dans l annuaire pour découvrir et sélectionner un service puis exécuter les fonctionnalités fournies par ce service. L exécution du service se fait en accord avec le contrat de service. 3) L annuaire de services (ou courtier de services) : est un registre qui donne la possibilité aux fournisseurs de services de publier des descriptions de services. Il permet aussi aux consommateurs de service de pouvoir consulter les différentes descriptions disponibles. En plus des spécifications de service, l annuaire contient des références vers les fournisseurs de services. Ceci va permettre aux consommateurs de localiser les fournisseurs des spécifications de service qui correspondent à leurs besoins. L annuaire sert donc d acteur intermédiaire entre fournisseurs et consommateurs de services. A travers l étude du comportement des trois acteurs principaux qui interviennent dans une architecture orientée service, nous notons que trois actions principales (ou primitives) permettent de réaliser les communications nécessaire du modèle d interaction. 11

28 Chapitre 1 : Architectures Orientées Service Figure 1.2 Les acteurs d une architecture à services Ces interactions sont : Publication, découverte et invocation. 1) Publication de service : permet aux fournisseurs de service d enregistrer les descriptions de services qu ils fournissent afin qu elles puissent être découvertes et invoquées par un ou plusieurs consommateurs de service. Cette interaction s effectue entre les fournisseurs et l annuaire de service. 2) Recherche et découverte d un service : Selon leurs besoins, cette action permet aux consommateurs de service de rechercher et découvrir les fournisseurs de service qu ils requièrent. Cette interaction a lieu entre le consommateur et l annuaire de service. l opération de découverte peut-être réalisée à deux phases différentes du cycle de vie de l application : à la phase de conception pour récupérer la description de l interface du service afin de développer l application et à l exécution pour récupérer l emplacement du service afin de faire la liaison. 3) Invocation : Après avoir consulté la description du service découvert et fait la liaison avec le fournisseur du service choisi, le consommateur de service procède à l invocation de ce service en fonction des informations présentes dans la description de service. Cette interaction s effectue entre le consommateur et le fournisseur de service au moment de l exécution de l application SOA, avantages et défis La SOA offre la possibilité de réaliser une interopérabilité à grande échelle tout en offrant la souplesse nécessaire pour s'adapter à l'évolution des technologies et des besoins de l'entreprise. Lorsqu elle est correctement implémentée, la SOA offre les avantages suivants : Un couplage faible entre le fournisseur et le consommateur de service et une transparence à la localisation Un développement d applications interopérables Une réutilisation des applications déjà existantes 12

29 Chapitre 1 : Architectures Orientées Service Un développement d applications de façon parallèle et indépendante Une meilleure extensibilité Une réduction des couts de développement et d intégration d application Une maintenance plus facile Une réduction de la dépendance exclusive à l'égard des fournisseurs Grace à ses bases solides (couplage faible, réutilisation, flexibilité,etc.), la SOA promet aux entreprises des gains à plusieurs niveaux. Cependant, elle doit relever un certain nombre de défis qui rendent l'adoption de la SOA par les entreprises quelque peu difficile. Ces défis peuvent aussi bien être de nature purement technique telle que la performance des protocoles et la maturité des standards, que de nature commerciale qui inclut les considérations de disponibilité des compétences et les coûts d'infrastructure de la SOA. L avènement des architectures orientées services à été principalement motivé par le besoin des entreprises de créer rapidement des applications en transformant leurs ressources existantes en services réutilisables et en composant ces nouveaux services pour atteindre des objectifs. Plusieurs initiatives sont apparues pour répondre à ces besoins. Notre étude ne s est pas portée sur l ensemble des implémentations possibles des architectures orientées service. En effet, nous avons focalisé notre travail sur l approche la plus populaire pour mettre en oeuvre une architecture SOA qui est l utilisation de Services Web. L important intérêt porté aux services Web a conduit actuellement à une petite confusion qui est de rendre synonyme la notion de services Web avec la notion de services et d architecture à services. Même si à ce jour, les standards développés autour des services Web sont très avancés et nombreux, il s agit seulement d une implémentation particulière des principes de l approche à services. Dans ce qui suit, nous allons definir le concept de service Web ansi que les differents standards qui entourent cette technologie. 3. Architecture orientée service Web (WSOA) Les services Web représentent une technologie relativement nouvelle qui a bénéficié d'une large acceptation comme une mise en œuvre importante de l'architecture orientée services. Ceci est dû au fait que les services Web offrent une approche distribuée pour l'intégration des applications extrêmement hétérogènes sur Internet. Les spécifications des services Web sont complètement indépendantes des langages de programmation, des systèmes d exploitation et de matériel spécifique. Ceci pour permettre un couplage faible entre les consommateurs de services et les fournisseurs. Les services Web sont basés sur des technologies ouvertes telles que XML (extensible Markup Language) [XML], SOAP (Simple Object Access Protocol) [SOAP], UDDI (Universal Description, Discovery and Integration) [UDDI] et WSDL (Web Services Description Language) [WSDL]. L'utilisation de standards ouverts offre une large interopérabilité entre les différents fournisseurs de solutions (services). Ces principes permettent aux entreprises de pouvoir mettre en œuvre des services Web sans avoir aucune connaissance des consommateurs finaux, et vice versa. Ceci facilite grandement 13

30 Chapitre 1 : Architectures Orientées Service l'intégration et permet aux entreprises d'établir de nouveaux partenariats de manière dynamique Définition et concepts de service Web Il y a actuellement autant de définitions des services Web que de sociétés qui en proposent. Le groupe de travail sur les architectures service Web du consortium W3C dans son document de référence [WSAR] et dans son glossaire Web service [WSG] est conjointement parvenu à s accorder sur la définition suivante d'un service Web: Un Service Web est un système logiciel conçu pour permettre l'interopérabilité machineà-machine sur un réseau. Un service Web est un système logiciel identifié par un URI, dont les interfaces publiques sont définies et décrites en utilisant un langage dérivé de XML. Sa définition peut être découverte par d'autres systèmes logiciels. Ces systèmes peuvent alors interagir avec le service Web d une manière prescrite par sa définition, en utilisant des messages basés XML véhiculés par des protocoles d Internet. Cette définition du W3C mentionne la majorité des caractéristiques clé des services Web. Elle fait également allusion à la manière dont les services Web fonctionnent. La définition met l accent sur le fait que les services Web doivent pouvoir être «définis, décrits et découverts», ce qui clarifie le sens du mot «accessible» et rend la notion de «interface basée sur les standards d Internet» plus concrète. La définition indique également que les services Web doivent être des "services" similaires à ceux définis dans le contexte de la SOA. Ils doivent non seulement être opérationnels, mais aussi être décrits et publiés de telle manière qu il soit possible de les faire interagir avec des clients potentiels. En d'autres termes, les services Web sont des composants qui peuvent être intégrés dans d'autres applications complexes et réparties. Le W3C indique également qu une grande partie de la solution est basée sur XML. En effet, XML a servi de base pour établir des standards qui sont utilisés pour construire les différentes descriptions de services Web ainsi que pour mettre en œuvre la communication entre le service Web et ses clients. Le choix de ce langage est tout à fait évident étant donné que XML est aujourd'hui un standard largement reconnu et jouissant de nombreux avantages tel que son extensibilité, sa lisibilité, son intégrabilité pour ne citer que ceux-ci Les standards des services Web Comme mentionné précédemment, les services Web utilisent des standards développés autour des standards http et XML afin de permettre le développement des applications distribuées à travers Internet. Ainsi, la communication est réalisée en utilisant le standard SOAP, la description du service est réalisée par le standard WSDL et les registres de services utilisent le standard UDDI. Ces standards sont expliqués plus en détails dans les sections suivantes. Les organisations de standardisation pour les services Web les plus connues sont OASIS (Organization for the Advancement of Structured Information Standards) et W3C (World Wide Web Consortium). 14

31 SOAP (Simple Object Access Protocol) Chapitre 1 : Architectures Orientées Service C est le protocole de messagerie qui est devenu le standard utilisé pour les services Web. Il définit la façon de faire des invocations de services et d échanger des données structurées d'une manière standardisée en utilisant XML. Il se compose de trois parties: une enveloppe qui définit un Framework pour décrire le contenu d un message, un ensemble de règles de codage, et une convention pour représenter les appels et les réponses. Du fait de sa polyvalence, SOAP peut être combiné avec une variété de protocoles réseau tels que HTTP [Berners-Lee et al., 1996] ou FTP [Postel & Reynolds, 1985]. Un message SOAP est un document XML qui se compose de deux éléments obligatoires et d un élément facultatif. Les éléments obligatoires sont Envelope et Body. L élément facultatif est Header. La figure 1.3 illustre la représentation visuelle d un message SOAP. Les noms des éléments sont exactement comme cités car XML et sensible à la casse. La structure et l organisation de ces éléments sont comme suit : L élément «Envelope» est l'élément qui englobe les deux autres éléments du document XML représentant le message. Sa présence est obligatoire dans un message SOAP, et il peut contenir des déclarations d'espace de nommage ainsi que des attributs supplémentaires. Le cas échéant, ces attributs supplémentaires doivent être qualifiés par l espace de nommage. De même, l'élément peut contenir d'autres sous-éléments. Si présents, ces éléments doivent aussi être qualifiés par l espace de nommage et doivent suivre l'élément Body. L élément «Header» constitue un mécanisme d extension pour passer des informations dans un message SOAP sans peser sur l application. Ces informations de "contrôle" incluent, par exemple, des directives ou des informations contextuelles liées au traitement du message. Ceci permet d'étendre un message SOAP de manière spécifique à l'application. L élément «Header» est facultatif mais s il est présent, il doit être le premier élément enfant de l élément Envelope. Il peut contenir un ensemble de blocs appelés header block, chacun étant un élément enfant immédiat de l'élément «Header». L élément «Body» est un conteneur pour les informations destinées au destinataire final du message. Sa présence dans un message SOAP est obligatoire et il doit être un élément enfant immédiat de l élément Envelope. Il doit suivre directement l'élément Header si celui-ci est présent. Sinon, il doit être le premier élément enfant immédiat de l'élément Envelope. L élément «Body» peut contenir un ensemble d'entrées Body, chacune étant un élément enfant immédiat de l'élément Body UDDI (Universal Description, Discovery and Integration) UDDI est une spécification conçue pour permettre aux entreprises de toutes tailles de bénéficier de la nouvelle économie numérique. UDDI constitue une norme pour mettre en œuvre le registre (ou annuaire) de services du modèle SOA dans le contexte des services Web. Ces registres sont appelés registres UDDI et sont ouverts à tous. L'adhésion est gratuite et UDDI fournit aux membres (fournisseurs de services) un schéma de 15

32 Chapitre 1 : Architectures Orientées Service description qui leur permet de publier des informations les concernant, concernant les services qu'ils fournissent ainsi que des détails techniques sur chaque service. 16 Figure 1.3 Structure d un message SOAP Du coté consommateurs de service, UDDI fournit une API permettant d extraire des informations sur les services disponibles au niveau du registre ainsi que sur les fournisseurs de ces services. Les registres UDDI sont donc eux aussi exposés sous forme de service Web. Les recherches au sein d un registre UDDI peuvent être effectuées par nom de société, par nom de service spécifique, ou par type de service. Chaque organisation qui veut mettre en place un registre UDDI doit suivre un processus pour devenir un opérateur UDDI. Les registres UDDI créés sont organisés en réseaux, ils partagent ainsi les différentes informations publiées. La publication d un service chez un opérateur donne automatiquement lieu à un processus de propagation des informations aux différents registres UDDI. L accès à l ensemble des informations des registres peut se faire à partir de n importe quel opérateur UDDI. Chaque registre UDDI stocke trois sortes de données [Pourraz, 2007]: Des données concernant les fournisseurs de services appelées pages blanches, Des données concernant l activité ou le service métier des fournisseurs appelées pages jaunes, Des données techniques de chaque service publié, qui constituent les pages vertes WSDL (Web Services Description Language) L un des nombreux objectifs de l Architecture Orientée Services est que les briques de base de l implémentation (les services) puissent être réutilisées dans d autres systèmes. La réutilisation de services Web repose sur le fait que ces derniers sont accessibles sur le Web et utilisables par le plus grand nombre de clients possibles. Ainsi, ce sont des

33 Chapitre 1 : Architectures Orientées Service services dits universels et non propriétaires. Cette réutilisation est conditionnée par le fait que chaque service utilisé dans un système basé sur une SOA doit être, au préalable, décrit par son fournisseur. Etant donné que les services Web constituent l implémentation des SOA la plus largement utilisée, ils doivent être décrits par leur fournisseur. La description d un service Web est nécessaire pour deux raisons : la publication du service par son fournisseur dans un registre et sa sélection ultérieure par des clients via ce registre. Nous étudions ici le standard de description des services Web proposé par le W3C : le langage WSDL. L importance que nous attachons à l étude de WSDL s explique par le fait que WSDL est au cœur de la technologie des services Web. En effet, l utilisation de WSDL pour décrire un service est un critère déterminant pour qualifier ce service de service Web. WSDL est un langage basé XML qui a été développé pour satisfaire ces exigences. Depuis 2007, sa version 2.0 est une recommandation officielle du W3C. WSDL offre une manière standard de construire des descriptions détaillées de services Web. Une description WSDL d un service élémentaire n intègre que son (ou ses) profil(s) fonctionnel(s). Le profil fonctionnel intègre la description des informations permettant de faire appel au service (la description syntaxique des méthodes proposées, des paramètres de ces méthodes et des protocoles à utiliser). Chaque description se présente sous forme de fichier textuel structuré et ayant un encodage XML. Les différentes entreprises peuvent publier des descriptions WSDL pour les services qu'ils fournissent. Des liens vers ces descriptions WSDL sont offerts dans les profils des sociétés présentes dans les registres UDDI. En utilisant la description WSDL d un service Web, un client peut invoquer n importe quelle opération fournie par le service alors qu il n'a aucune connaissance préalable sur ce service [Singh et al., 2004]. La description WSDL d un service Web est indépendante de toutes plateformes ou technologies particulières, ce qui est un point important pour assurer l interopérabilité des services. La structure d'un document WSDL est représentée sur la figure1.4. Elle comprend sept (7) éléments qui peuvent être divisés en deux parties. La première partie est dédiée aux éléments pour les définitions abstraites, tandis que la seconde partie contient les descriptions concrètes. Nous donnons dans ce qui suit le contenu de chaque partie : 1) Eléments pour les définitions abstraites : L élément <Types> : décrit les types des données échangées entre le client et le fournisseur de services. La description se fait sous la forme d un schéma XML. Si le type (ou format) de données n est pas un format primitif défini par XML (integer, string, float, long, boolean, short), les développeurs peuvent définir leurs propres types de données complexes en utilisant ces types primitifs. L élément <Messages> : permet la définition des structures de données et leur contenu qui vont être échangées dans l utilisation du service. L élément <porttypes> : est l élément central d un fichier WSDL ; il définit l interface du service. Dans un fichier WSDL, on peut trouver une ou plusieurs définitions <porttypes>. Un élément <porttypes> peut contenir plusieurs opérations mais en général on associe une opération à un porttype. Pour chaque 17

34 Chapitre 1 : Architectures Orientées Service <Operation>, la spécification contient le nom et les <Messages> d entrée et de sortie. L élément <Operation> : est la description d une action exposée dans le port. Une description WSDL peut contenir plusieurs opérations. Figure 1.4 Structure d un document WSDL 2) Eléments pour les définitions concrètes : L élément <Bindings> : est élément qui définit le lien entre les différents <porttypes> et les protocoles utilisés, tels que SOAP. L élément <Ports> : définit un point d accès au service défini par une adresse réseau et une connexion. L élément <Services> : contient plusieurs éléments <Ports>, contenant chacun un nom, une URL de point d accès et une référence à une liaison donnée. Actuellement, SOAP, WSDL et UDDI sont les trois standards qui sont utilisés dans les architectures orientées services Web. Ensemble, ils adressent les problèmes de l hétérogénéité des systèmes pour l intégration d applications déployées sur Internet. Les interactions de base entre les trois rôles (Annuaire, Fournisseur et Client) incluent les opérations de publication, de recherche et de liens (bind) d opérations. Nous décrivons dans La figure 1.5 un scénario type d utilisation de cette architecture. Le fournisseur de services définit la description WSDL de son service et la publie dans l annuaire de service UDDI. Le client utilise les facilités de recherche disponibles au niveau de l annuaire pour retrouver et sélectionner un service donné. Il examine ensuite la description WSDL du service sélectionné pour récupérer les informations nécessaires lui 18

35 Chapitre 1 : Architectures Orientées Service permettant de se connecter au fournisseur du service et d interagir avec l implémentation du service considéré. 4. La composition de services Web Figure 1.5 Architecture des services Web Actuellement, un nombre considérable d entreprises utilise les services Web pour mettre à disposition leurs données et leurs informations via Internet. Les différents fournisseurs de services s appuient sur l infrastructure de base des services Web pour assurer l interopérabilité. La recherche dans le domaine des services Web, et dans la SOA en général, s'étendent sur de multiples axes. L'un des axes qui a reçu le plus d'attention de la part des organismes de recherche et de l'industrie dans le passé récent concerne la composition de services Web. Celle-ci fait référence au processus de combinaison (ou d interaction) de fonctionnalités de multiples services appelés services composants en un seul service composite. Ce dernier offrirait une certaine fonctionnalité, qui, autrement, ne pourrait être fournie par un service unique. Cet engouement est justifié par le besoin accru de développement d applications et de services à valeur ajoutée simplement en sélectionnant et intégrant des services déjà existants. Une telle approche présente des avantages considérables en termes de réduction du coût et de l'effort de construction de nouveaux services à partir de zéro, ce qui favorise un développement rapide d applications. De plus, les services composites résultants pourront être utilisés comme services de base dans des compositions futures. Dans la pratique, il existe différentes approches pour la réalisation d une composition de services Web. Afin de choisir l une ou l autre de ces approches de composition, le concepteur de systèmes à base de services Web doit prendre en compte différents paramètres. Dans ce qui suit, nous allons présenter deux classifications de ces différentes approches qui se placent selon deux points de vue différents. La première classification distingue entre une composition de type orchestration et une composition de 19

36 Chapitre 1 : Architectures Orientées Service type chorégraphie. La deuxième classification distingue quant à elle entre une composition statique et une composition dynamique. Nous allons également passer en revue les principaux langages utilisés pour chaque type de composition de services Orchestration vs Chorégraphie de services La plupart des travaux portant sur la composition de services Web reconnaissent deux types de composition : l orchestration et la chorégraphie de services. Selon [Benatallah et al., 2005], l orchestration et la chorégraphie sont des moyens différents de concevoir la composition. Ces deux approches sont basées sur les Workflow et ont comme objectif commun la collaboration entre les processus métiers impliquant plusieurs services autonomes, où chaque service assume un rôle bien défini et forme une relation spécifique avec les autres services. Cependant, elles se différencient par leur point de vue concernant la coordination des services intervenant dans une composition de services Web. L Orchestration et la Chorégraphie renvoient donc à une description des interactions entre un ensemble de services composants. La Figure 1.6 montre les deux types de composition présents dans cette classification L Orchestration Elle se réfère à un processus exécutable qui peut se traduire par un modèle d'interactions où les interactions sont toujours contrôlées par la perspective d une seule entité (qui est elle-même un service Web) impliquée dans le processus et que l on appelle chef d'orchestre. Ce dernier représente le résultat de l orchestration de services et constitue un nouveau service dit Composé. C est ce dernier qui gère l enchaînement des services Web par une logique de contrôle. Ce type de composition permet ainsi de centraliser l invocation des services Web composants. Les services impliqués dans une Orchestration peuvent être des services atomiques ou des services eux-mêmes Composés. Selon [Lopez-Velasco, 2009], l orchestration de services Web exige de définir l enchaînement des services Web selon un canevas prédéfini, et de les exécuter selon un script d orchestration. Ces derniers (le canevas et le script) décrivent les interactions entre services Web en identifiant les messages, et en spécifiant la logique et les séquences d invocation. 20 Figure 1.6 Orchestration vs Chorégraphie de services

37 Chapitre 1 : Architectures Orientées Service Le module exécutant le script d orchestration de services Web est appelé un moteur d orchestration. Ce moteur d orchestration est une entité logicielle qui joue le rôle d intermédiaire entre les services en les appelant suivant le script d orchestration La Chorégraphie Cette approche quant à elle, fournit une vue globale des échanges de messages et des interactions qui se produisent entre les point terminaux (endpoints) du processus. Elle consiste à concevoir une coordination décentralisée des services Web, dans laquelle il n y a pas de service privilégié, mais un réseau de services interconnectés qui échangent des messages. Ainsi, la chorégraphie s'apparente davantage à une architecture peer-to-peer (P2P), et offre un moyen par lequel les règles de participation pour la collaboration sont clairement définies et convenues. Dans une chorégraphie, la logique de contrôle est supervisée par chacun des services intervenant dans la composition. L exécution du processus est alors distribuée. En résumé, il y a une différence importante entre l'orchestration et la chorégraphie de services Web. L'orchestration se base sur un procédé métier exécutable pouvant interagir avec les services Web internes ou externes. Elle offre une vision centralisée et le procédé est toujours contrôlé du point de vue d'un des partenaires métiers. La chorégraphie est de nature plus collaborative ; chaque participant impliqué dans le procédé décrit le rôle qu'il joue dans l'interaction [Guermouche, 2010]. De nombreux langages ont ainsi été proposés pour modéliser la composition des services. Certains sont spécifiques à l Orchestration comme par exemple BPEL [BPEL], WSFL [WSFL] et XLANG [Xlang]. Parmi tous ces langages d orchestration, WS-BPEL 2.0 (ou BPEL) semble avoir gagné le consensus. En effet, BPEL est un langage exécutable basé sur XML standardisé par OASIS. D autres langages de composition sont dédiés à la Chorégraphie parmi eux on peut citer WSCI [Arkin et al., 2002] ou WS- CDL[Kavantzas et al., 2004] Composition statique vs Dynamique La deuxième classification présente dans la littérature concernant la composition des services Web est celle qui fait la distinction entre La composition statique et la composition dynamique de services. Selon [Hu, 2003] La composition statique regroupe les méthodes d orchestration et les méthodes de chorégraphie dont nous avons parlé dans les sections précédentes. Ce type de composition a lieu au moment de la conception d'une application à base de service Web. Ainsi, les composants impliqués (les services Web) sont choisis, liés et assemblés avant d'être déployés [Dustdar & Schreiner, 2005]. Une telle composition est adaptée aux environnements fermés où les composants n évoluent pas souvent. Si de nouveaux services sont disponibles ou remplacés par d autres, des incohérences pourront être relevées. Dans ce cas, il est inévitable de changer ou de modifier l architecture du système et de le relier à nouveau à d autres services ou, dans le pire des cas, de changer la définition du processus et concevoir à nouveau le système [Ait-Cheik-Bihi, 2012]. 21

38 Chapitre 1 : Architectures Orientées Service La composition dynamique quant à elle, a lieu au moment de l'exécution et permet de créer de manière autonome des services complexes en combinant des composants à la volée en fonction des demandes des utilisateurs et du contexte [Ragab Hassen, 2012]. Elle évolue dans des environnements flexibles, ouverts où la sélection et la combinaison des composants sont effectuées à la demande. La technologie de composition dynamique se confronte à plusieurs challenges comme par exemple, la sélection de services qui représente un réel problème dans ce type de composition. Selon [Qiqing et al., 2009], la complexité de la sélection des services inclue trois facteurs principaux. Le premier concerne le grand nombre de changements dynamiques des instances des services ayant des fonctionnalités similaires et qui pourraient être disponibles pour composer un service. Le deuxième facteur concerne les différentes possibilités d intégration des composants d une instance de service, au processus d un service complexe. Le troisième facteur correspond aux diverses exigences de performance d un service complexe (c.-à-d. introduction de critères de la qualité de service tels que le délai, le prix et la fiabilité). Pour arriver à réaliser des compositions dynamiques de services, plusieurs travaux de recherche ont vu le jour. Ces travaux se situent essentiellement dans le domaine du Web sémantique. Ces travaux commencent à explorer des approches combinant des outils d annotation de services et de planification de manière à pouvoir composer automatiquement des services en vue d atteindre des fonctionnalités prédéfinies. Ce type d approche constitue une alternative aux langages procéduraux de type BPEL4WS en permettant de générer l implantation d un service composite à partir de spécifications déclaratives de son comportement. Dans ce même domaine, des langages comme DAML- S [DAML-S] et OWL-S [OWL-S], ont été développés pour spécifier les services composés BPEL4WS (Business Process Execution Language for Web services) BPEL est un langage basé XML utilisé pour définir des processus métiers d entreprise au sein de services Web. BPEL est une convergence de fonctionnalités issue du langage WSFL et du langage XLANG. Le premier utilise une approche de graphe orienté alors que le second est un langage d orchestration utilisé dans le serveur BizTalk [BizTalk] et ayant une approche structurée en blocs. WSFL et XLANG sont désormais remplacés par la spécification BPEL. En Avril 2003, la version 1.1 de BPEL a été soumise à OASIS pour obtenir une plus large acceptation de l'industrie. 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 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. Chaque entreprise a sa façon unique de définir ses flux de processus métiers. Le principal objectif de BPEL est de normaliser le format de définition de ces flux de processus métiers afin que les entreprises puissent travailler ensemble de façon transparente à l'aide de services Web. BPEL étend le modèle d'interaction des services 22

39 Chapitre 1 : Architectures Orientées Service Web en lui permettant de supporter les transactions commerciales. BPEL est basé sur les services Web, dans le sens où chacun des processus métiers impliqués est supposé être mis en œuvre sous forme de service Web. Les processus écrits en BPEL peuvent orchestrer les interactions entre services Web en utilisant des documents XML de manière standardisée. Ces processus peuvent être exécutés sur n'importe quelle plate-forme conforme à la spécification BPEL. BPEL permet de décrire des processus abstraits et des processus exécutables : Processus abstraits: utilisent des descriptions de processus qui spécifient le comportement visible en termes d'échange mutuel de messages de chacune des parties impliquées dans le protocole (les services Web composants), sans révéler leur comportement interne. Processus exécutables: modélisent le déroulement des opérations et incluent les détails internes. Ce processus permet de spécifier l ordre d exécution des activités, le partenaire concerné, les messages échangés entre ces partenaires, et les mécanismes des erreurs et des exceptions. La Figure 1.7 [Peltz, 2003] illustre la mise en œuvre des deux types de processus (exécutable et abstrait) par BPEL4WS. Selon [Lopez-Velasco, 2009], la définition du processus métier est donnée par le processus exécutable. Les processus abstraits gèrent les invocations entre les différents services Web permettant l exécution de la composition de services définie dans le processus exécutable. Un processus BPEL est un service Web composé reflétant les interactions avec d autres services Web. 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. Figure 1.7 Le flot de processus avec BPEL4WS 23

40 Chapitre 1 : Architectures Orientées Service 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. La figure 1.8 montre la création, le déploiement et l'exécution d'un processus BPEL. Les descriptions WSDL des services Web participants sont utilisées pour définir les interfaces d'interaction et pour spécifier les types de données utilisées. A la fin de la création du processus, le fichier XML ainsi que la description WSDL du processus sont déployés sur un moteur BPEL. Chaque fois que le processus est invoqué par un appel de service Web, une nouvelle instance du processus correspondant est lancée sur le moteur BPEL. Ce dernier s'occupe de l exécution et du contrôle des processus déployés Anatomie d un processus BPEL Un processus BPEL consiste en un container dans lequel figurent plusieurs éléments que l on peut diviser en deux parties [Chami, 2008] : Les déclarations des éléments utilisés : éléments qui seront manipulés par le processus lors des différentes interactions avec ses partenaires, et La description du comportement du processus : (Workflow) Pour cela, BPEL utilise des activités primaires pour exécuter des opérations de base et des activités structurées pour définir l'ordre d exécution des activités de base. BPEL fournit aussi un autre type d'activités pour gérer les erreurs d'une manière globale ou locale. L élément «process» est utilisé pour spécifier le container principal du processus. Celui-ci comporte deux attributs. L attribut «name» pour spécifier le nom du processus et un attribut «targetnamespace» utilisé pour la déclaration de l espace de nom. La syntaxe qui doit être utilisée pour spécifier un élément «process» est illustrée dans la figure 1.9(a). L élément «process» est le container le plus externe. Tout partenaire, donnée de processus ou gestionnaire déclaré à l intérieur de ce container peut être considéré comme global. Dans ce qui suit nous allons présenter plus en détails les deux parties constituant un processus BPEL ainsi que la syntaxe utilisée pour spécifier chaque partie. Figure 1.8 Processus interprété par un moteur WS-BPEL 24

41 Chapitre 1 : Architectures Orientées Service Figure 1.9 Syntaxe de déclaration des éléments BPEL Description des liens et des variables du processus La partie déclarations dans un document BPEL contient les deux éléments suivants : PartnerLinks : est l élément qui permet de définir les différents liens avec les partenaires intervenant dans le processus. Un lien de partenaire désigne les relations entre le processus BPEL et ses partenaires. Un lien est de type Invocation si le processus BPEL invoque des opérations issues d autres services Web. Le lien est de type Client si le processus BPEL reçoit des invocations issues de clients. L élément <partnerlinks> contient un ou plusieurs éléments <partnerlinks> spécifiant chacun un seul lien de partenaire. Chaque élément <partnerlinks> possède quatre attributs : Name, myrole, partnerrole et partnerlinktype utilisés respectivement pour représenter le nom du lien de partenariat, le rôle du processus, le rôle du partenaire et le type du lien de partenaire. Il est à noter que dans un partnerlink, au moins un rôle (parmi myrole et partnerrole) doit être spécifié. La syntaxe qui doit être utilisée pour spécifier un élément «partnerlinks» est illustrée dans la figure 1.9(b). Variables : est l élément qui donne la possibilité de déclarer des variables qui permettent au processus BPEL d avoir un état interne. Les variables peuvent être manipulées par des activités d'affectation, par des activités de réception ou d'envoi de messages. La syntaxe qui doit être utilisée pour spécifier un élément «variables» est illustrée dans la figure 1.9(c). Chaque élément «variable» possède un attribut «name» et un attribut «type» pour spécifier le type de la variable. Celui-ci peut être de type simple ou de type complexe Description du comportement du processus Un processus BPEL est constitué d activités mises bout-à-bout par des structures de contrôle de flux. Le comportement du processus BPEL est décrit en utilisant des activités qui peuvent être catégorisées comme activités de base et activités structurées. Les activités structurées (aussi appelées structures de contrôle de flux) sont utilisées pour organiser l ordre d exécution des activités de base. Elles peuvent donc contenir d autres 25

42 Chapitre 1 : Architectures Orientées Service activités, contrairement aux activités de base qui ne peuvent pas contenir d autres activités. Les activités de base possibles pour un processus BPEL sont les suivantes : Receive : permet au processus BPEL de recevoir des requêtes afin de fournir des services à ses partenaires. La requête s opère sous forme de réception d un message. Une activité de réception indique un partnerlink, un porttype et une opération qui peut être invoquée. L activité «receive» est généralement la première activité d'un processus et elle est utilisée pour initier le processus. Un processus BPEL ne doit pas contenir deux activités «receive» qui ont les mêmes partnerlink et porttype. La syntaxe qui doit être utilisée pour spécifier une activité «receive» au sein d un processus BPEL est illustrée dans la figure 1.10(a). Reply : permet au processus de renvoyer un message afin de répondre à une demande préalablement acceptée à travers une activité«receive». L activité «reply» doit être placée uniquement après une activité «receive» et avec le même attribut partnerlink, porttype et operation. La syntaxe pour spécifier une activité «reply» au sein d un processus BPEL est illustrée dans la figure 1.10(b). Invoke : permet d exécuter (ou d appeler) une opération fournie par un service partenaire. Au sein de cette activité, le «partnerlink» et l opération du service Web doivent être spécifiés. La syntaxe utilisée pour spécifier une activité «invoke» au sein d un processus BPEL est illustrée dans la figure 1.10(c). Assign : permet manipuler des données, comme par exemple copier des valeurs entre variables, parties de variables ou manipuler des chaines de caractères. La syntaxe de spécification d une activité «assign» au sein d un processus BPEL est illustrée dans la figure 1.10(d). L activité «assign» possède un attribut «name» et contient un élément «copy» utilisé pour spécifier la variable source et cible de l assignation. Empty : permet de spécifier une activité BPEL qui ne fait rien. La syntaxe de spécification d une activité «empty» au sein d un processus BPEL est illustrée dans la figure 1.10(e). 26 Figure 1.10 Syntaxe de déclaration des activités simples Le langage BPEL fournit des activités plus complexes pour structurer la logique métier suivant les besoins. Ces activités sont appelées activités structurées et elles sont présentées dans ce qui suit :

43 Chapitre 1 : Architectures Orientées Service Sequence : est l activité structurée la plus simple. Elle consiste à exécuter une activité séquentiellement après une autre. Les activités à exécuter dans un ordre séquentiel peuvent être des activités simples ou des activités structurées. La syntaxe utilisée pour spécifier une activité «sequence» au sein d un processus BPEL est illustrée dans la figure 1.11(a). While : est l activité structurée qui permet d obtenir une structure de contrôle itérative qui exécute répétitivement une activité spécifiée tant qu'une condition booléenne est vérifiée. Cette condition est placée au début de l activité et elle est évaluée à chaque itération. La syntaxe utilisée pour spécifier une activité «while» au sein d un processus BPEL est illustrée dans la figure 1.11(b). Flow : est une activité BPEL structurée qui permet une exécution concurrente de plusieurs activités. Elle permet aussi la synchronisation de toutes les activités qu elle renferme. Les dépendances éventuelles entre ces activités peuvent être assurées par le constructeur «link». Un flow complète son exécution si toutes les activités qu'il contient complètent aussi leurs exécutions. La syntaxe utilisée pour spécifier une activité «flow» au sein d un processus BPEL est illustrée dans la figure 1.11(c). Pick: est une activité BPEL structurée qui peut contenir un ou plusieurs éléments «onmessage». L'activité «Pick» force le processus à attendre que l'un d'une série d'événements soit déclenché. Tous ces événements sont des éléments «onmessage» contenant chacun un traitement différent. On peut avoir autant d'activités «onmessage» que nécessaire, mais seulement l'une d'entre elles sera exécutée. Une fois qu un événement est exécuté, tous les autres sont désactivés. La syntaxe pour spécifier une activité «pick» au sein d un processus BPEL est illustrée dans la figure 1.11(d). If/Else : est une structure de branchement qui a le même comportement que celles rencontrées dans les langages de programmation traditionnels. Des conditions booléennes sont écrites et associées à chaque branche. Comme avec toutes les expressions de BPEL, Xpath peut être utilisé pour formuler la condition. La syntaxe utilisée pour spécifier une activité «if/else» au sein d un processus BPEL est illustrée dans la figure 1.11(e) BPEL Vs Control-flow Patterns Le Workflow Patterns initiative [WPI] sont des travaux joint du professeur Wil van der Aalst et du professeur Arthur ter Hofstede. L objectif majeur de leurs travaux est de fournir une base conceptuelle pour la technologie des processus. En particulier, leurs travaux de recherche fournissent un examen approfondi des différents aspects (structures de contrôle, données, ressources et gestion des exceptions) qui doivent être pris en charge par un langage de modélisation de Workflow ou un langage de modélisation des processus métiers. Le Workflow Patterns initiative a donné la description détaillée des différentes structures de contrôle (Control-flow Patterns) et a procéder à l évaluation du langage BPEL par rapport à sa capacité à prendre en compte ces structures. L étude à démonter que grâce à ses activités de base et ses activités structurées, BPEL prend en compte les 27

44 Chapitre 1 : Architectures Orientées Service cinq structures de base suivantes : La séquence (Sequence), le branchement multiple (Parallel split), la synchronisation (Synchronization), le choix exclusif (Exclusive choice) et la jonction simple (Simple merge). BPEL est aussi capable de modéliser les structures complexes suivantes : le choix non-exclusif (Multi-choice), la synchronisation structurée (Structured synchronizing merge) et la boucle structurée (Structured loop). Le fonctionnement des structures de contrôles (ou Control-flow Patterns) prises en compte par BPEL est expliqué comme suit : La séquence permet au développeur de réaliser des activités dans un ordre donné, par opposition au branchement multiple qui est utilisé pour les exécuter simultanément. La synchronisation joint les chemins d exécution parallèles et attend l'exécution de chacun d'eux avant de continuer. Dans le choix exclusif, une seule branche parmi plusieurs est choisis en fonction d'une condition. Enfin, le dernier Control-flow Pattern de base est la jonction simple qui relie deux ou plusieurs branches alternatives sans synchronisation. Le choix non-exclusif est une extension du choix exclusif où plus d'une branche de sortie peut être exécuté. La synchronisation structurée apparaît dans un Workflow après un choix non-exclusif afin de fusionner les branches d'entrée avec une synchronisation. Enfin, la boucle structurée a la capacité d'exécuter une tâche ou un sous-processus de façon répétée Les composantes de l architecture de BPEL Les trois principales composantes de BPEL sont : Le concepteur BPEL Le diagramme de flux de processus BPEL Le moteur d exécution BPEL Dans un scénario typique, un expert/analyste d'une société utilise BPEL pour définir le processus métier. Un processus métier par exemple, pourrait être le scénario «bon de commande» d'une entreprise. Les services Web nécessaires à ce scénario sont inclus dans le flux que définit le concepteur. Une fois que l'expert de l'entreprise définit le flux de processus métiers, un diagramme de traitement, contenant la logique de flux du processus, est généré par le concepteur. A l'exécution, ce diagramme de processus sera exécuté par le moteur d exécution BPEL. 28

45 Chapitre 1 : Architectures Orientées Service Figure 1.11 Syntaxe de déclaration des activités structurées Le Concepteur BPEL : C est une interface graphique permettant de définir des processus métiers indépendants des applications sous-jacentes. Cette interface est suffisamment intuitive et permet aux experts de définir des processus sans trop rentrer dans des détails techniques. Il génère le diagramme de flux de processus BPEL. Les éditeurs graphiques pour BPEL sont généralement intégrables dans les environnements de développement (Eclipse, Netbeans, Visual Studio, etc.). Le diagramme de flux de processus : Ce diagramme est conforme à la spécification BPEL. Il saisit la logique de flux des processus métiers. Il est généré par l interface BPEL à la conception et exécuté par le moteur BPEL à l'exécution. Le moteur d exécution BPEL : Il permet d exécuter n'importe quel modèle de flux de processus compatible avec le standard BPEL. Parmi ses fonctionnalités, nous citons l invocation des services Web, le mapping des données, la gestion des erreurs, la sécurité, etc. Généralement, le moteur BPEL est intégré dans le serveur d'applications. 5. Modélisation et Analyse formelle de la composition de services Web La composition des services Web est un paradigme émergeant pour l'intégration d'applications au sein et entre différentes organisations. En conséquence, la tendance actuelle est d'exprimer la logique d'un service Web composite en utilisant un langage de modélisation de processus métier adapté aux services Web. Comme évoqué auparavant, un certain nombre de langages comme BPML [BPML], BPEL [BPEL] et WSCI ont 29

46 Chapitre 1 : Architectures Orientées Service émergé et sont continuellement enrichis avec de nouvelles propositions venant de différents fournisseurs. Cependant, la majorité des langages proposés pour la composition de services Web sont des langages pour la description et l exécution des services composés. Ces langages sont textuels et négligent de fait l étape de spécification qui facilite grandement la compréhension du système (service composé). De plus, l analyse formelle avec ces langages n est pas possible à cause de leur manque de formalisme. Pour faire face à tous ces obstacles, et afin d assurer une composition de services Web correcte, une approche d analyse de composition rigoureuse est nécessaire. De ce fait, un intérêt croissant a été donné aux techniques de vérification formelle de composition de services Web [Foster, 2006]. Dans la littérature, plusieurs travaux ont été consacrés au développement d approches d analyse formelle des compositions de services Web. Ces travaux partagent globalement la même stratégie pour arriver à vérifier les Workflow de services Web spécifiés à l aide d un langage de composition. La stratégie se résume en la translation des spécifications dans un langage de modélisation (comme BPEL) en des spécifications dans un langage formel. Cette translation est faite afin de pouvoir tirer profit des outils disponibles pour le langage formel cible. Dans [Fu et al., 2004], les auteurs ont présenté un Framework où des spécifications de services Web en BPEL sont converties en une représentation intermédiaire en automates à état fini. Cette dernière est alors transformée en une autre représentation dans le langage Promela qui constitue le langage d entrée de l outil de vérification SPIN [Holzmann, 2003]. Ce dernier est finalement utilisé pour effectuer la vérification sur la spécification Promela. Un autre mapping entre BPEL et un langage de modélisation formel a été proposé dans les travaux de [Yang et al., 2005]. Pour ce mapping, les réseaux de Petri coloré (CPN) [Jensen, 1996], ont été choisis comme langage cible. Une fois que les spécifications de services composés en BPEL sont traduites en CPN, les outils de vérification dédiés, tel que Design/CPN [Design/CPN], sont utilisés pour effectuer la vérification. Les travaux de [Dong et al., 2006] ont proposé une technique pour analyser et tester la composition de services Web en utilisant des réseaux de Petri de haut niveau (HPNs) [Gerogiannis et al., 1995]. Afin d effectuer la vérification, les auteurs expliquent les relations entre les concepts de BPEL et ceux des HPNs. Par la suite, des HPNs sont générés à partir de spécifications BPEL grâce à un outil implémenté en C. Les spécifications résultantes sont ensuite soumises à un simulateur dédié aux HPNs. Comme nous l avons indiqué dans les sections précédentes, les langages de composition des services Web comme BPEL et WSCI offrent les moyens de spécifier un processus exécutable mettant en œuvre un Workflow de services Web. Les approches de vérification de composition de services Web que nous avons cité ci-dessus effectuent les vérifications directement sur les processus de composition. Ces derniers représentent une implémentation d un nouveau service à valeur ajoutée. Cependant (et Idéalement) les approches d analyse pour les services Web devraient permettre de tester et réparer les erreurs de conception avant même la mise en œuvre et le fonctionnement réel du service composé. Elles devraient aussi permettre de vérifier la présence de types de propriétés désirées ainsi que l absence de types de propriétés non désirées dans le système résultant. 30

47 Chapitre 1 : Architectures Orientées Service Afin de répondre à ce besoin, d autres travaux avec une toute autre approche ont vu le jour. Ces travaux, contrairement à ceux cités précédemment, suivent les principes de l ingénierie dirigée par les modèles (IDM) pour obtenir le service Web composé. Après élaboration du modèle dans un langage de modélisation, la vérification de la composition s effectue sur le modèle de service composé et non pas sur le service lui-même. L avantage ici est la réduction des risques et des efforts de développement en générant directement un service composé correct à partir de son modèle. Nous présenterons dans le chapitre suivant un état de l art sur les travaux basés IDM pour la composition et la vérification des services Web. 6. Synthèse et conclusion Dans ce chapitre, nous avons visité tous les aspects de l architecture orientée services et nous avons discuté des divers concepts qui ont conduit à la nécessité d'une telle technologie et contribué à son évolution. L'analyse approfondie de la SOA menée dans ce chapitre a mis en évidence deux aspects principaux: les technologies clés réalisant la SOA et les implémentations de la SOA. Concernant le premier aspect, nous avons discuté des concepts clés impliqués dans la SOA dont l apparition est justifiée par les besoins spécifiques des entreprises. Nous avons vu les principales définitions et les caractéristiques des services et qu un modèle commun, le modèle d interactions, a été défini pour que la SOA devienne une architecture universellement acceptée. Le deuxième aspect abordé dans ce chapitre concerne l'approche la plus commune et la plus populaire pour la réalisation de la SOA, qui est la WSOA, bâtie autour des services Web. Ces derniers sont des composants qui peuvent être intégrés dans d'autres applications complexes et réparties et dont les fonctionnalités sont universellement définies et accessibles. L accessibilité fait ici référence au fait que les services Web doivent pouvoir être définis, décrits et découverts. Avec cette nécessité et dans le souci de standardiser leur nature, ont émergé plusieurs standards établis comme universels. Ces derniers sont WSDL qui décrit les services Web, UDDI qui les enregistre et SOAP qui traite de l'échange de messages entre les services Web. Suite à cette étude, nous avons abordé le problème de la composition des services Web avec ses deux techniques principales : l orchestration et la chorégraphie. Alors que la première réfère à un processus impérativement décrit et exécutable, la seconde est une description déclarative pour suivre la trace des séquences de messages entre plusieurs sources participantes. Comme dans le contexte de notre travail, nous traitons le problème de la composition en utilisant la technique de l orchestration, nous avons porté un intérêt particulier au langage BPEL qui est la spécification la plus prometteuse adressant l orchestration. Après avoir constaté que la composition des services est confrontée à de nombreux problèmes et qu il n est pas toujours possible d assurer une composition de services Web correcte, nous avons mis l accent sur le fait qu une approche de modélisation et d analyse de composition rigoureuse est nécessaire. En effet, les langages exécutables comme BPEL sont destinés au niveau implémentation et sont principalement basés sur des concepts de programmation. Par conséquent, ces langages ne sont pas appropriés pour 31

48 Chapitre 1 : Architectures Orientées Service exprimer un modèle de composition parce qu ils n'ont pas la capacité de représenter des concepts abstraits. En conséquence, ils ne prennent pas en compte l étape de spécification qui est primordiale dans le processus de composition. La spécification est importante car elle facilite la compréhension globale du système, elle permet de réaliser des modèles abstraits et elle est suffisamment précise pour permettre la génération du code associé. Par ailleurs, le manque de formalisme dont souffrent les langages de composition rend l analyse formelle des systèmes difficile, voire impossible. Cet aspect de l analyse formelle prend toute son ampleur lorsqu il s agit de concevoir des systèmes à base de services Web dans des domaines critiques tels que la finance, la santé, etc. L ingénierie dirigée par les modèles offre les moyens pour concevoir des modèles, effectuer des raisonnements sur ces modèles, vérifier leur bon fonctionnement, et générer le code à partir des modèles. Etant donné que dans nos travaux, nous allons appliquer ces principes, le chapitre suivant sera consacré à présenter les fondements de l IDM ainsi que les divers travaux qui font usage de ces fondements pour la composition des services Web. 32

49 Chapitre 2 Ingénierie Dirigée par les Modèles

50

51 Chapitre 2 : Ingénierie Dirigée par les Modèles Chapitre 2 Ingénierie Dirigée par les Modèles 1. Introduction Pour aborder la complexité d un problème et pour effectivement exprimer les concepts d un domaine, l ingénierie logicielle s oriente actuellement vers l utilisation des technologies de l Ingénierie Dirigée par les Modèles (IDM) ou en anglais Model Driven Engineering (MDE). Cette approche prometteuse est une forme d ingénierie qui se concentre sur la création et l exploitation de modèles abstraits. Ces derniers sont ensuite utilisés pour générer tout ou une partie d une application. Plus récemment, les techniques de transformation de modèles de même que les outils associés se sont concentrés sur la façon d élever le niveau d'abstraction des langages textuels vers des langages de modélisation visuels. Les problèmes de transformation de modèles pouvant ainsi être formulés comme des problèmes de transformation de graphes, une grande variété d'outils choisissent cette technique comme un mécanisme sous-jacent pour la mise en place de la transformation. Le but de ce chapitre est tout d abord de présenter un état de l art sur l IDM d une façon générale et plus particulièrement sur les fondements de la transformation de graphes. Nous y verrons notamment les standards et les outils disponibles permettant de maintenir d une façon efficace et performante les modèles manipulés au cours du processus de transformation de modèles. Nous discutons en particulier la notion de transformation de graphes puisque c est cette technique de l IDM que nous avons choisie pour mettre en œuvre les différentes phases de notre approche. Une fois ces concepts définis, il reste à analyser les approches basées sur l IDM qui ont été proposées pour mettre en œuvre le processus de composition des services Web et les avantages qu elles présentent par rapport aux approches classiques étudiées dans le chapitre précédent. Ce chapitre est structuré comme suit : dans la section suivante, nous abordons les principes généraux de l IDM et définissons clairement les concepts de modèle, métamodèle et de transformation de modèles. La section 3 est dédiée à l étude des différents outils existants les plus répandus pour la mise en œuvre de la transformation de modèles, dont certains qui sont basés sur la réécriture des graphes. Ce dernier concept est étudié plus en détail dans la section 4. Dans la section 5, nous présentons les différentes approches de composition de services Web. Cette analyse nous permet d identifier les insuffisances des approches existantes que l approche proposée dans le cadre de cette thèse visera précisément à combler. 2. Les principes généraux de l IDM Ces dernières années, l IDM a rencontré un franc succès au sein de diverses organisations. Cet engouement est principalement dû au fait que c est une approche qui fournit de solides bases pour l utilisation des modèles afin de mieux appréhender, concevoir, construire, déployer, maintenir et modifier un système [Miller & Mukerji, 2003]. 33

52 Chapitre 2 : Ingénierie Dirigée par les Modèles La phase de spécification est particulièrement importante dans une approche IDM et représente une partie conséquente du cycle de développement. Elle permet aux développeurs de se concentrer sur le comportement souhaité du système, sans se soucier de la manière de l implémenter. La phase d implémentation est alors démarrée en fin de cycle, une fois que la spécification est achevée et validée. La génération partielle du code bas niveau à partir de la spécification permet également de réduire le temps et par conséquent les coûts de développement [Ait-CHEIK-Bihi, 2012]. L apparition de cette technologie et de son principe de base "tout est modèle" (en analogie avec "tout est objet") est une suite logique à l approche orientée objet. Le principe de "tout est modèle" possède plusieurs propriétés intéressantes provenant à l origine de celles de la technologie objet [Dumez, 2010]. Dans cette dernière, un objet est vu comme instance d une classe qui elle-même hérite d une autre classe (sa superclasse). Ainsi, en IDM, une vue particulière d un système est capturée par un Modèle qui est lui-même décrit dans un langage de modélisation spécifique à un domaine défini à l aide de son Méta-modèle. Dans ce contexte, plusieurs outils axés sur le concept de Méta-modèle ont été développés. Ces outils intègrent également un autre concept spécifique à l IDM qui est la Transformation de modèles. Cette dernière joue un rôle primordial dans la vision de l IDM car elle permet entre autres la génération de code à partir des modèles. La technologie IDM, comme nous allons le voir, combine ces divers aspects : les modèles, les langages de modélisation, les Méta-modèles et les transformations ou les mappings entre les modèles Modèle et Méta-modèle Malgré la place centrale qu occupent les modèles au sein de l IDM, il n existe pas à ce jour un commun accord sur ce qu est un modèle. Dans [Seidewitz, 2003], un modèle est défini comme "un ensemble de déclarations concernant un système à l'étude". Bézivin et Gerbé dans [Bézivin & Gerbé, 2001] définissent un modèle comme "une simplification d'un système construit avec un objectif en tête". Le modèle devrait être en mesure de répondre à certaines questions à la place du système réel. D'après Mellor et al. [Mellor et al., 2003] un modèle "est un ensemble cohérent d'éléments formels décrivant quelque chose (par exemple, un système, une banque, un téléphone ou un train) construit dans un but qui se prête à une forme particulière d'analyse". Le guide MDA [OMG 2003] définit un modèle d'un système comme "une description ou une spécification de ce système et de son environnement pour un certain objectif". Concrètement, un modèle est souvent présenté comme une combinaison de dessins et/ou de textes. Le texte pouvant être dans un langage de modélisation ou dans une langue naturelle. Il est à noter qu au sein de l IDM, les modèles ne sont pas considérés comme une simple documentation, mais comme des artefacts précis qui peuvent être compris par les ordinateurs et peuvent être manipulés automatiquement. Dans ce scénario, la métamodélisation joue un rôle clé. Elle est considérée comme une technique courante pour la définition de la syntaxe abstraite des modèles et des relations entre les éléments du modèle. En d autres termes, la Méta-modélisation peut être vue comme la construction d'un ensemble de concepts dans un certain domaine. Un modèle est une abstraction de 34

53 Chapitre 2 : Ingénierie Dirigée par les Modèles phénomènes du monde réel, et un méta-modèle est encore une autre abstraction, mettant en évidence les propriétés du modèle lui-même. Ce modèle se doit d être conforme à son méta-modèle tout comme un programme se doit d être conforme à la grammaire du langage de programmation dans lequel il est écrit. Les méta-modèles constituent donc un concept important de l IDM puisqu ils fournissent la possibilité de définir formellement des modèles dits conformes ou bien-formés [Bézivin, 2005]. Une particularité des méta-modèles est leur évolution durant leur cycle de vie. L évolution, le changement ou l extension d un méta-modèle, ne constitue pas un véritable problème pour les modèles existants qui sont conformes à l ancienne version d un méta-modèle. Il suffit alors que ces modèles migrent dans les nouvelles instances du méta-modèle révisé. A cet égard, l OMG (Object Management Group) a introduit l'architecture de Metamodélisation illustrée par le biais de la figure 2.1. Celle-ci se structure en quatre niveaux d abstraction. Au niveau le plus bas, la couche M0 constitue le système réel. Un modèle représente une abstraction de ce système au niveau M1. Ce modèle est conforme à son méta-modèle défini au niveau M2 et qui le décrit. Le méta-modèle lui-même est conforme au méta-méta-modèle au niveau M3. Le méta-méta-modèle est auto descriptif et est conforme à lui-même Les langages de modélisation Un langage de modélisation est tout langage artificiel utilisé pour exprimer une information ou une connaissance ou pour décrire une structure ou un système défini par un ensemble consistant de règles. Ces dernières pouvant être utilisées pour l interprétation du sens des composants dans la structure. Chaque langage possède une syntaxe et une sémantique. La syntaxe décrit les différentes constructions du langage, alors que la sémantique permet de donner un sens à chacune des constructions du langage. Combemale dans [Combemale, 2009] définit un langage comme un couple {S, Sem} où S est sa syntaxe et Sem sa sémantique. L IDM favorise la définition de langages de modélisation dédiés à un domaine particulier (en anglais Domain Specific Languages - DSLs) offrant ainsi aux utilisateurs des concepts propres à leur métier et dont ils ont la maîtrise. Les DSLs formalisent la structure d une application, son comportement et les exigences propres à un domaine particulier. Les concepteurs utilisent les DSLs pour définir un système complexe en utilisant des éléments du système pour exprimer l intention de conception d une manière plutôt déclarative qu impérative [Van Gorp, 2007]. Par exemple, au lieu d adopter des notations polyvalentes qui expriment rarement les concepts d un système et l intention de conception, les DSLs peuvent être adaptés via la méta-modélisation afin de répondre précisément à la sémantique et la syntaxe d un domaine. Un DSL est constitué d'un méta-modèle approprié qui définit sa syntaxe abstraite et sa sémantique statique. Un DSL est aussi constitué d un ensemble d'annotations textuelles et / ou graphiques, qui définit sa syntaxe concrète. C est cette dernière qui est utilisée pour créer des modèles dans le langage. 35

54 Chapitre 2 : Ingénierie Dirigée par les Modèles Figure 2.1 L'architecture de méta-modélisation à quatre niveaux La syntaxe concrète est donc manipulée par l utilisateur, alors que la syntaxe abstraite est une implémentation particulière du langage. Un DSL doit aussi préciser la sémantique dynamique et les contraintes associées aux concepts du domaine spécifique. Par conséquent, concevoir un modèle, c est aussi faire le choix d un langage de modélisation permettant d exprimer sa structure, son comportement, ainsi que ses exigences dans un domaine particulier. Le fait de décrire un modèle par le biais d un langage permet sa compréhension et sa manipulation par une machine. La figure 2.2 illustre les relations entre un système, son modèle et le langage utilisé pour écrire le modèle. Ici, la relation entre un modèle et son méta-modèle est instance-de. Dans ce qui suit, nous présentons les techniques, standards, et outils actuellement disponibles pour décrire les différentes parties d un DSL. 36 Figure 2.2 Méta-modèles et langages de modélisation

55 Syntaxe abstraite et sémantique statique Chapitre 2 : Ingénierie Dirigée par les Modèles Comme indiqué plus haut, pour un DSL donné, un méta-modèle définit: (1) la syntaxe abstraite et (2) la sémantique statique. La syntaxe abstraite constitue une partie importante de la définition du langage de modélisation. Elle spécifie les primitives de modélisation qui peuvent être utilisées lors de la modélisation. En d autres termes, elle définit la vision du langage par le compilateur ou l évaluateur. A la différence de la syntaxe concrète d'un langage, la syntaxe abstraite définit généralement les concepts linguistiques disponibles, sans se soucier de leur représentation réelle. La sémantique statique quant à elle désigne les règles et les contraintes de forme qui spécifient comment les primitives de modélisation sont autorisées à être composées. A ce jour, de nombreux environnements et langages de méta-modélisation ont été proposés : Eclipse-EMF/Ecore [Budinsky et al., 2003], GME/MetaGME [Ledecziet al., 2001], AMMA/KM3 [Jouault & Bézivin, 2006] [INRIA, 2005], XMF-Mosaic/Xcore [Clark et al., 2004] et Kermeta [Kermeta]. On peut cependant constater que la plupart de ces langages s inspirent de l approche orientée objet, et possèdent donc des constructions communes Syntaxe concrète Afin qu un langage puisse être implémenté, il est nécessaire d établir un mapping de la syntaxe abstraite vers une représentation spécifique à la machine à travers des codages. Ces derniers définissent la syntaxe concrète du langage. La syntaxe concrète d un langage est définie par une grammaire à contexte libre. Elle consiste en un ensemble de règles (productions) qui définissent la façon dont les modèles sont vus par l utilisateur. Par le biais d un formalisme graphique ou textuel, la syntaxe concrète offre des moyens de manipuler les concepts de la syntaxe abstraite et d en créer des instances. Définir une syntaxe concrète revient à définir un mapping M ac : SA SC. Ce dernier est généralement atteint par un ensemble de règles, chacune étant assignée à un concept (méta-élément) représenté par le méta-modèle. Suite à l exécution de l ensemble des règles, chaque construction définie dans la syntaxe abstraite aura un format représentatif pouvant être manipulé par l utilisateur du langage, ceci sans perte de la puissance du langage, de sa simplicité d expression ou de son efficacité. Dans ce contexte aussi, de nombreux outils ont été proposés, principalement basés sur la technologie EMF (Eclipse Modeling Framework) [EMF]: GMF (Generic Modeling Framework) [GMF], TOPCASED [Farail et al., 2006], Merlin Generator [Merlin], et TIGER [Ehrig et al., 2005] qui sont principalement des outils graphiques. D autres projets se consacrent à la définition de la syntaxe concrète textuelle comme les travaux des équipes INRIA Triskell [Muller et al., 2008] Sémantique dynamique Nous avons vu que le problème de la syntaxe se concentre surtout sur la notation du langage, sans tenir compte des questions de sens. Or le sens d un langage est décrit pas sa sémantique dynamique. Sans sémantique, la syntaxe devient pauvre puisque de graves mésinterprétations peuvent survenir. La sémantique dynamique d'un langage de modélisation ne peut être précisée avec son méta-modèle. Bien que le méta-modèle 37

56 Chapitre 2 : Ingénierie Dirigée par les Modèles prescrive à quoi "les modèles" valides d'un langage de modélisation doivent ressembler, la sémantique réelle de ces modèles reste floue. Ceci parce que l'information modélisée ne représente que des métadonnées sur une certaine connaissance du système [Greenfield & Short, 2004]. Cette sémantique, contrairement à la syntaxe, est un aspect qui ne peut être directement manipulé par des outils. Pour obtenir la signification réelle de cette métadonnée, cette dernière doit être soumise à des interpréteurs et des générateurs de code qui convertissent les constructions d'un langage de modélisation dans un autre langage qui a une sémantique formelle bien définie. Dans le contexte de l IDM, la sémantique des langages de modélisation a fait l objet d intenses travaux de recherche [Harel & Rumpe, 2000] [Harel & Rumpe, 2004] [Hausmann, 2005] La transformation de modèles Au cours de la phase d ingénierie d un système, plusieurs modèles de ce système, établis sous des perspectives différentes, peuvent coexister. Ces modèles ne sont pas forcément exprimés dans le même langage, et le besoin de maintenir une liaison entre eux requiert la définition de transformations. La transformation de modèles constitue le cœur et l âme de l IDM [Sendall & Kozaczynski, 2003]. Dans [Kleppe et al., 2003], les auteurs définissent une transformation comme "la génération automatique d'un modèle cible à partir d'un modèle source, selon une définition de transformation". Une définition de transformation est un ensemble de règles de transformation qui décrivent comment un modèle dans le langage de départ peut être transformé en un modèle dans le langage cible. Une règle de transformation quant à elle est définie comme une description de la manière dont une ou plusieurs constructions dans le langage de départ peuvent être transformées en une ou plusieurs constructions dans le langage d arrivée. La transformation des modèles constitue un domaine qui est loin d être récent. Cependant, elle demeure toujours d actualité étant donné que ses concepts sont le sujet de propositions dans différents domaines de l informatique, sous différentes perspectives et utilisant différentes technologies. La transformation de modèles requiert une bonne compréhension de la syntaxe abstraite et de la sémantique des deux modèles [Varro et al., 2004] [Küster et al., 2004] [Czarnecki et al., 2003]. Comme illustré dans la figure 2.3, un programme de transformation de modèle prend en entrée un modèle conforme à un méta-modèle source, et produit en sortie un autre modèle conforme à un méta-modèle cible. Le programme de transformation est composé d'un ensemble de règles qui doivent elles-mêmes être considérées comme un modèle. Par conséquent, il est basé sur un métamodèle correspondant, qui est une définition abstraite du langage de transformation utilisé. Concrètement, la transformation se situe entre les méta-modèles source et cible. La transformation des entités du modèle source se fait en deux étapes. La première étape permet d identifier les correspondances entre les concepts des modèles source et cible au niveau de leurs méta-modèles. La seconde étape consiste à appliquer la transformation du modèle source afin de générer automatiquement le modèle cible par un programme appelé moteur de transformation ou d exécution. 38

57 Chapitre 2 : Ingénierie Dirigée par les Modèles Figure 2.3 Concepts basiques de la transformation de modèles 2.4. Classification des transformations de modèles La première question importante dans une transformation concerne les modèles source et cible. Si ces modèles sont des programmes (i.e. code source ou code machine), il est préférable d utiliser le terme transformation de programmes. Cependant, la transformation de modèles, couvre l ensemble des transformations y compris celle des programmes, puisque le terme modèle peut aussi bien désigner les représentations abstraites d un système que les modèles concrets de code source. La transformation de modèles inclut également les transformations de modèles abstraits vers des modèles plus concrets et vice versa (ex. dans le contexte du reverse engineering). Dans ce qui suit, nous proposons une taxonomie des transformations de modèles qui permet de grouper les outils, les techniques, et les formalismes sous-jacents. La taxonomie est établie selon plusieurs critères, chacun répondant à l aspect pris en compte. Chaque critère est utilisé pour regrouper ensemble les approches de transformation de modèles le satisfaisant Nombre de modèles source et cible Une première caractéristique de la transformation de modèles est son nombre de modèles source et cible. D après la définition de Kleppe donnée ci-dessus, une règle de transformation est la description de la façon dont une ou plusieurs constructions du langage source peuvent être transformées en une ou plusieurs constructions du langage cible. A partir de là, il est possible de généraliser de façon à ce qu une transformation de modèles puisse aussi être applicable à plusieurs modèles source et/ou plusieurs modèles cibles. Pour le premier cas, on peut citer l exemple de la fusion de modèles, qui consiste à combiner plusieurs modèles source développés en parallèle en un modèle cible résultant. Le deuxième cas peut s appliquer à la transformation d un PIM (Platform-Independant Model) en un nombre de PSM (Platform-Specific Model) dans le contexte de la MDA. Les deux exemples sont représentés par la figure

58 Chapitre 2 : Ingénierie Dirigée par les Modèles Figure 2.4 Exemples de types de transformations de modèles Appartenance à l espace technique Un espace technique est un Framework de gestion de modèles contenant des concepts, des outils, des mécanismes, des techniques, des langages et des formalismes associés à une technologie particulière. Un espace technique est déterminé par le métaméta-modèle. Par exemple, le W3C (World Wide Web consortium) favorise l espace technique XML, qui utilise XML Schema comme méta-méta-modèle. Cet espace inclut un support pour les langages comme HTML, XML, XMI et XQuery. Comme autre exemple, l OMG offre l espace technique MDA qui utilise le MOF [OMG, 2002] comme méta-modèle, et supporte des langages comme UML (Unified Modeling Language) [UML]. Beaucoup d autres espaces techniques sont disponibles, y compris ceux en rapport avec les grammaires et les arbres de syntaxe abstraite, les graphes et la transformation de graphes, la technologie des bases de données et les ontologies. Etant donnée une transformation de modèles, ses modèles source et cible peuvent appartenir ou non au même espace technique. Dans le second cas, des outils et des techniques sont nécessaires afin de définir les transformations qui surmontent les différents espaces techniques. Une possibilité consiste à fournir des exportateurs et des importateurs de modèles pendant l exécution de la transformation actuelle soit dans l espace technique du modèle source ou bien celui du modèle cible. Par exemple, lors de la transformation de documents XML en diagrammes UML, deux possibilités s offrent à nous : exécuter la transformation dans l espace technique XML ou bien dans celui de la MDA. Si l on opte pour le premier choix, on peut utiliser un programme XSLT ou XQuery pour translater le document général UML en un document XML conforme à la syntaxe standard XMI (XML Metadata Interchange) et conforme à la sémantique MOF-XMI du standard UML. Un parseur XMI peut ensuite être utilisé pour importer le document XMI résultant dans l outil CASE UML, résidant dans l espace technique MDA. Par contre, l exécution de la transformation dans l espace technique MDA requiert le méta-modèle MOF pour XML. Après analyse du document XML comme instance de ce méta-modèle, la transformation courante peut être effectuée comme une transformation MOF. Le langage QVT (Query/View/Transformation) [OMG, 2002] a été proposé pour la standardisation de tous les efforts tentant d implémenter ce genre de transformation. 40

59 Transformation Endogène versus Exogène Chapitre 2 : Ingénierie Dirigée par les Modèles Les modèles à transformés sont exprimés dans des langages de modélisation dont la syntaxe et la sémantique sont exprimés par un méta-modèle. Par exemple, la syntaxe du méta-modèle UML est exprimée par des diagrammes de classes, alors que sa sémantique est décrite par des règles de bonne formation exprimées par des contraintes OCL. Si l on se base sur le langage dans lequel sont exprimés les modèles source et cible, une distinction peut être établie entre les transformations endogènes et exogènes. Une transformation est dite endogène si elle prend en compte des modèles exprimés dans le même langage, elle est exogène si les deux modèles sont exprimés par des langages de modélisation différents. Dans [Visser, 2001], la même distinction a été proposée mais en utilisant des termes différents : le terme reformulation (Rephrasing en anglais) pour la transformation endogène et le terme translation pour la transformation exogène. Des exemples typiques de transformations exogènes (translations) sont : La synthèse d une spécification de niveau plus abstraite en une de plus bas niveau, plus concrète. Un exemple typique de synthèse est la génération de code, où le code source d un programme est translaté en code machine exécutable sur une machine virtuelle ou bien la transformation d un modèle de conception en code source. La rétro-ingénierie est l inverse de la synthèse, elle extrait une spécification de haut niveau à partir d une autre de plus bas niveau. La migration d un programme écrit dans un langage en un autre, mais tout en gardant le même niveau d abstraction. Des exemples typiques de transformations endogènes (reformulation) sont : L optimisation, une transformation dont le but est d améliorer certaines qualités opérationnelles (ex. performance), tout en préservant la sémantique du logiciel. Le refactoring, un changement vers une structure interne d un logiciel de façon à améliorer certaines caractéristiques de qualité (telles que la modifiabilité, la réutilisation, la modularité et l adaptabilité) sans changer son comportement [Fowler, 1999]. La simplification et la normalisation, utilisées pour diminuer la complexité syntaxique. L aplatissement d une hiérarchie dans un diagramme de classes est un exemple d une telle simplification. L adaptation de composants, afin de modifier et d adapter le code de composants d un logiciel existant, soit syntaxiquement ou dynamiquement (i.e. pendant l exécution d un composant) aux besoins des utilisateurs Transformations horizontale versus verticale Une transformation horizontale est une transformation dans laquelle les modèles source et cible se situent au même niveau d abstraction. Des exemples typiques sont le refactoring et la migration. La transformation verticale est une transformation dans laquelle les modèles source et cible se situent à des niveaux d abstraction différents. On peut citer à titre d exemple le raffinement, dans lequel une spécification est graduellement 41

60 Chapitre 2 : Ingénierie Dirigée par les Modèles raffinée en une implémentation à part entière, par le biais d étapes successives de raffinement qui rajoutent des détails plus concrets [Back et al., 1998]. La table 2.1 illustre le fait que les dimensions horizontales vs verticales et endogène vs exogène sont orthogonales, à travers les exemples concrets pour chaque combinaison possible. Pour le raffinement formel mentionné dans la table, une spécification en logique des prédicats du premier ordre ou en théorie des ensembles peut être graduellement raffinée de sorte que les résultats finaux utilisent exactement le même langage que la spécification originale (ex. par ajout d axiomes supplémentaires). Horizontale Verticale Endogène Refactoring Raffinement Exogène Migration de langage Génération de code Table 2.1 Dimensions orthogonales de transformation de modèles avec des exemples Transformations Syntaxiques versus sémantiques Une distinction finale peut être faite entre les transformations de modèles qui transforment simplement la syntaxe, et des transformations plus sophistiquées qui prennent aussi en considération la sémantique d un modèle. Comme exemple de transformation syntaxique, un analyseur qui transforme la syntaxe concrète d un programme en syntaxe abstraite. La syntaxe abstraite est alors utilisée comme représentation interne du programme sur laquelle peuvent être appliquées des transformations sémantiques plus complexes. Notons que lors de l importation ou l exportation de modèles en un format spécifique, une transformation syntaxique est nécessaire Le type du modèle source et cible Les approches de transformation de modèles peuvent être distinguées entre les transformations de type model-to-text et model-to-model. La distinction réside dans le fait qu une transformation de modèle vers modèle crée sa cible sous forme de modèle conforme à son méta-modèle cible, alors que la cible d'une transformation de type modelto-text est essentiellement des chaînes de caractères. Dans ce qui suit nous passons en revue les différentes approches de transformations de type model-to-model : 42 Approche de la manipulation directe. Cette approche dispose d'une représentation interne des modèles (source et cible) et des API pour les manipuler. Elle est généralement mise en œuvre dans un environnement orienté objet, qui peut également fournir une infrastructure minimale. Les utilisateurs doivent mettre en œuvre les règles de transformation, l ordonnancement ainsi que le traçage. Ceci est généralement fait à partir de zéro et dans un langage de programmation donné (Java ou C++ par exemple) Approche opérationnelle. Elle est semblable à la manipulation directe, mais offre plus d assistance lors de la transformation de modèles. Un exemple dans cette catégorie serait d'étendre un langage de requêtes comme OCL avec des constructions impératives. Des exemples de systèmes de ce type sont des applications opérationnelles QVT, XMF et Kermeta.

61 Chapitre 2 : Ingénierie Dirigée par les Modèles Approche relationnelle. Elle regroupe les approches déclaratives dont le concept principal consiste en des relations mathématiques. En général, les approches relationnelles peuvent être considérées comme une forme de résolution de contraintes. L'idée de base est de préciser les relations entre l élément source et le type d'élément cible à l'aide des contraintes qui sont en général non exécutables. L utilisation de la programmation logique est particulièrement adaptée à ce type d approche. Approche hybride. Elle combine différentes techniques dans les catégories précédentes, comme ATL [Jouault & Kurtev, 2006]. Approche de Transformation de Graphe. Pour décrire une transformation de modèles par transformation de graphes, les modèles source ou cible doivent être donnés sous forme de graphes. La transformation de graphe, ainsi que les concepts qui entourent cette technique de transformation de modèles et les outils associés seront introduits plus en détail dans la section Caractéristiques importantes d une transformation de modèles Les caractéristiques d une transformation de modèles varient selon les auteurs, certaines d entre elles ne sont pas toujours prises en compte. Nous avons recensé dans ce qui suit les principales caractéristiques Degré d automatisation Une distinction doit être faite entre les transformations de modèles qui peuvent être automatisées et celles qui ont besoin d être réalisées de façon manuelle (ou du moins requièrent un certain taux d intervention manuelle). Un exemple pour le deuxième cas est la transformation d un document d exigences vers un modèle d analyse. Pour une telle transformation, une intervention manuelle est nécessaire pour adresser et résoudre des ambiguïtés ou des incohérences dans les exigences définies (en partie) par un langage naturel Complexité de la transformation Certaines transformations, tel le refactoring, peuvent être considérées comme légères alors que d autres sont considérablement plus lourdes. Les compilateurs ou les générateurs de codes sont des exemples de transformations lourdes. La différence de complexité entre les transformations légères et les autres est tellement importante qu elles requièrent un ensemble différent de techniques et d outils Préservation Bien qu il existe une grande variété de transformations qui sont utiles lors d un développement dirigé par les modèles, chaque transformation préserve certains aspects du modèle source dans le modèle cible transformé. Les propriétés qui sont préservées peuvent différer en fonction du type de transformation. Par exemple, avec le refactoring ou la restructuration, le comportement doit être préservé, alors que la structure est modifiée. Avec les raffinements, la correction d un programme doit être préservée. 43

62 Chapitre 2 : Ingénierie Dirigée par les Modèles L espace technique influence également ce qui doit être préservé. Par exemple, dans le cas de la transformation d une base de données, il faut préserver l intégrité des données, alors que dans le cas d une transformation de programmes, il faut préserver la bonne formation syntaxique et la correction du programme. 3. Standards, langages et outils pour l IDM Dans une approche dirigée par les modèles, la vision est que les modèles deviennent des artefacts à maintenir avec le code. L outillage est essentiel si l on veut maximiser les avantages d avoir des modèles et minimiser les efforts requis pour les maintenir. De façon plus spécifique, le besoin d avoir des outils plus sophistiqués que ceux d usage courant devient de plus en plus pressant. Les outils disponibles sont dans la plupart des cas juste des éditeurs de modèles. Les outils les plus performants sont certainement ceux qui présentent les caractéristiques suivantes : - Vérification/renforcement de contraintes de bonne modélisation - Support pour travailler avec des instances de modèles - Support des mappings entre les modèles - Support pour les tests et le contrôle - Gestion du processus logiciel Dans ce qui suit, nous présentons les différents outils de transformation de modèles qui mettent en œuvre les approches de transformation de modèles présentées dans la section précédente. La liste passe en revue les outils les plus répandus, certains sont basés sur la réécriture des graphes L environnement GME (Generic Modeling Environment) L environnement GME [Ledeczi et al., 2001] est un outil de méta-modélisation hautement configurable supportant deux couches: la couche méta-modèle et celle du modèle. Les définitions de syntaxe concrète peuvent être soit codées manuellement, soit initialisées par des propriétés au niveau méta-modèle et modèle. Cet environnement supporte un type spécial de définitions : les entrées de registre. Celles-ci sont assignées aux éléments du modèle et peuvent personnaliser l apparence AGG (Attributed Graph Grammar system) AGG [Taentzer, 2003] est un outil de transformation de graphe développé à la Technische Universität de Berlin. Contrairement à d'autres outils de transformation, AGG a des bases formelles solides sur la Théorie des Catégories. Les méta-modèles sont représentés par des graphes (appelés type graph) permettant le mécanisme d'héritage et les multiplicités tandis que les modèles sont représentés par des graphes attribués. AGG fournit un mode graphique qui facilite la spécification des règles de transformation. Sous AGG, aucune distinction n'est faite entre les méta-modèles source et cible. Le type graph fusionne les deux. Il ne met donc en œuvre que les transformations de type endogènes. Un des inconvénients d AGG est le manque de formats d'échange de modèles. Cependant, il est implémenté en Java et donc son moteur de transformation est utilisable par une API Java. 44

63 Chapitre 2 : Ingénierie Dirigée par les Modèles 3.3. Les éditeurs Meta-CASE 1 Ce sont des environnements capables de générer des outils CASE (ex. MetaEdit). Ils permettent la création de définitions d outils dans un environnement graphique de haut niveau, mais ils fournissent une interface utilisateur codée manuellement. Ces environnements stockent les définitions de syntaxe concrète dans les propriétés du métamodèle DiaGen (Diagram Editor Generator) DiaGen [Minas, 2002] est un autre Framework offrant une solution efficace pour la création d éditeurs visuels pour DSLs. Il n est pas basé que sur des techniques de métamodélisation et il utilise son propre langage de spécification pour définir la structure des diagrammes. DiaGen supporte l utilisation de la syntaxe concrète dans un contexte graphique, mais cependant n offre aucun moyen pour définir la forme graphique des éléments. La syntaxe concrète dans DiaGen est basée sur des propriétés. Cet outil peut générer un éditeur basé sur la spécification par l utilisation de grammaires d hypergraphes Eclipse 2 (EMF) Il s agit probablement de la plate-forme de modélisation hautement flexible open source la plus populaire qui supporte la méta-modélisation. Le Framework EMF peut générer du code source pour les modèles définis par des diagrammes de classes UML, mais il ne contient pas de définitions de syntaxe concrète. Le Framework GEF est aussi une partie du projet Eclipse. Il fournit des méthodes pour la création d éditeurs visuels, mais il ne supporte pas de génération de code. C est pourquoi les plug-ins GEF requièrent du codage manuel pour supporter la syntaxe concrète AToM 3 (A Tool for Multi-formalism and Meta-Modelling) AToM 3 [de Lara & Vangheluwe, 2002] est un outil utilisé pour la conception de DSLs et pour la transformation de modèles développé à l'université McGill de Montréal (Canada). Cet outil permet de définir la syntaxe abstraite et concrète d'un DSL en utilisant la méta-modélisation pour générer un environnement de modélisation personnalisé pour le DSL développé. Il permet également d'effectuer la transformation de modèles en appliquant la transformation de graphes. AToM 3 manipule les méta-modèles comme des graphes. Il fournit un mode graphique qui est approprié pour la transformation de modèles. Les valeurs d'attributs peuvent aussi être spécifiées textuellement par code Python. L'approche de la transformation de modèles implémentée par AToM 3 est l approche de grammaire triple. Cette approche est plus concise que la grammaire de graphe ordinaire car elle est basée sur trois graphes: un pour le modèle source, un pour le modèle cible et un troisième pour le graphe de correspondance. Ce dernier est caché à 1 Meta-case official homepage, 2 The Eclipse Modeling Framework, 45

64 Chapitre 2 : Ingénierie Dirigée par les Modèles l utilisateur, il est simplement utilisé pour maintenir la cohérence entre les modèles source et cible. La mise à jour de modèles est particulièrement développée en AToM 3. En effet, AToM 3 peut effectuer la transformation de façon incrémentale. Lors de l'ajout des éléments du modèle source, il est possible d'exécuter à nouveau la transformation et de mettre à jour le modèle cible. Ceci est rendu possible grâce à la persistance du graphe de correspondance). AToM 3 est un outil très complet: il permet d'effectuer la transformation de modèles, ainsi que la définition de la syntaxe abstraite et concrète d'un DSL afin de l'utiliser dans un éditeur graphique ou textuel. Il facilite également le mécanisme de mise à jour des modèles et permet la réutilisation des règles. Cependant, ses capacités de vérification sont très faibles par rapport à ceux proposés par AGG par exemple ATL (ATLAS Transformation Language) ATL [Jouault & Kurtev, 2006] est un outil de transformation de type model-tomodel développé à l'université de Nantes (France) par l'équipe ATLAS. Le processus de transformation (règles) est exprimé textuellement dans le langage ATLAS. ATL a été créé en réponse à la demande du langage QVT de l OMG. Il est considéré comme un langage textuel hybride qui associe un style déclaratif et impératif. Ce langage comprend les règles, les aides, les requêtes et les bibliothèques. ATL est implémenté sous forme d un plug-in Eclipse et est bien adapté à tous les outils et fonctionnalités de modélisation Eclipse. ATL a un mode d'exécution différent pour les transformations endogènes appelé: mode d'affinage. Le point négatif que présente ATL concerne la lourdeur de sa syntaxe. Un autre inconvénient est que la vérification de type des règles est relativement faible. Elle consiste principalement en une vérification syntaxique. De ce fait, l'utilisateur peut éventuellement générer des éléments erronés dans le méta-modèle cible Kermeta (Kernel Meta-Modeling Language) Kermeta [Kermeta] est un outil développé par l équipe Triskel de l'université de Rennes 1 (France). C'est un environnement de méta-programmation permettant de simuler l'exécution de méta-modèles. Habituellement, cet outil est utilisé pour représenter la sémantique opérationnelle des méta-modèles à des fins de test et de simulation. Pour cela, les développeurs ont utilisé la modélisation orientée aspect pour construire un métalangage exécutable. Le langage d'action de Kermeta est impératif et orienté objet. Du point de vue de la transformation de modèle, l'approche de Kermeta est classée parmi les approches opérationnelles de transformation. Kermeta est un langage puissant et expressif, mais il manque de simplicité et de clarté. Contrairement aux autres langages de transformations, Kermeta ne définit pas séparément les modèles source et cible. 4. Concepts de graphe et de transformation de graphes Un graphe est composé de nœuds et d'arcs orientés qui relient les nœuds. Pour les graphes typés attribués, les nœuds et les arcs ont des types. Ces types comprennent souvent un ensemble d'attributs nommés avec des valeurs qui peuvent varier d'un nœud à 46

65 Chapitre 2 : Ingénierie Dirigée par les Modèles un autre. La syntaxe concrète d'un graphe visualise tous les nœuds et tous les arcs par des symboles graphiques similaires. Une syntaxe concrète commune aux graphes est de représenter un nœud par un rectangle divisé en deux compartiments. Le premier compartiment désigne un identificateur d'instance de chaque type de nœud, tandis que le second compartiment contient la liste des attributs et de leurs valeurs. Un arc est normalement visualisé avec une flèche, où le type d arc est placé à côté de la flèche. Les graphes constituent une représentation naturelle des modèles qui ont une nature intrinsèquement basée sur les graphes (comme les diagrammes d états, les diagrammes d activité, les diagrammes de classes, les réseaux de Petri, etc.), par opposition au code source pour lequel une approche basée sur les arbres est susceptible d'être plus appropriée. Nous donnons ci-dessous la définition formelle d un graphe extraite de [Mens, 2006]. Définition1: Graphe (G) Un graphe G=(V,E) consiste en un ensemble de sommets V et un ensemble d arcs E tel que chaque arc e dans E possède respectivement un sommet source et un sommet cible respectivement désignés par source (e) et cible (e) dans V. Propriétés : implicitement, plusieurs fonctions sont associées à un graphe G. - Le mapping elab : E Σ E associe à chaque arc son label. - Le mapping vlab: V Σ V associe à chaque sommet son label. Dans le but de pouvoir spécifier une transformation de modèles par le biais d une transformation de graphes, il est impératif de trouver un moyen pour spécifier les modèles qui seront transformés. Ceci requiert la définition d un méta-modèle qui spécifie la validité d un modèle (ses règles de bonne formation). Comme les modèles sont représentés par des graphes, les méta-modèles sont représentés par des types graphes. Un modèle est donc bien formé s il est conforme à son type graph. Ces notions sont explicitées par la figure 2.5. La transformation de graphes a été largement utilisée pour exprimer la transformation de modèles, surtout pour les modèles visuels dont la structure peut de façon naturelle être décrite par des graphes. Il s agit d une technique déclarative basée sur des règles, dont la popularité ne cesse de croitre pour deux raisons. La première est due à son caractère visuel qui facilite l élaboration des règles de façon intuitive, la seconde est due à son caractère formel qui fait que les règles en question peuvent se prêter à une analyse. Figure 2.5 Relation entre un modèle et sa représentation par un graphe 47

66 Chapitre 2 : Ingénierie Dirigée par les Modèles Dans ce contexte, les premières propositions sont apparues vers la fin des années 60 et le début des années 70 [Pfaltz & Rosenfeld, 1969] [Pratt, 1971]. Les approches fondamentales qui sont à ce jour toujours répandues incluent l approche DPO (Double- Push Out) [Ehrig et al., 2006][Corradini et al., 1996], l approche NLC (Node-Label Controlled) [Janssens & Rozenberg, 1980], la logique des graphes [Courcelle, 1990] et l approche Progres [Schürr, 1997] qui représente l application majeure de la transformation de graphes à l ingénierie des logiciels. Cette technique a été également utilisée pour la description de la sémantique opérationnelle des langages visuels spécifiques à un domaine, en raison de sa faculté à manipuler la syntaxe concrète des langages [Cabot et al., 2008] [de Lara & Vangheluwe, 2004]. A l instar des transformations de modèles classiques, les transformations de graphes sont aussi spécifiées par rapport aux méta-modèles source et cible, et donc le concepteur d une transformation doit tout autant maitriser en détail les deux méta-modèles. Dans l approche de transformation de graphes, un graphe est dérivé d un autre graphe par application d un ensemble de règles. Une règle de transformation de graphe est souvent visualisée sous forme d une partie de graphe du côté gauche (Left Hand Side Graph ou de façon plus commune LHS) et d une partie de graphe du côté droit (Right Hand Side Graph - RHS). La LHS est égalée (matched en anglais) et remplacée par la RHS au sein du modèle en cours de transformation. Ce principe de base est illustré par la figure 2.6. En d autres termes, la LHS représente la pré-condition de la règle donnée, tandis que la RHS décrit les post-conditions. LHR RHS définit une partie qui doit exister pour appliquer la règle, mais qui n'est pas modifiée. LHS (LHS RHS), définit la partie qui doit être supprimée, et RHS LHS RHS définit la partie qui doit être créée. En plus des parties du graphe, la LHS contient souvent des conditions d application des règles. Certaines logiques supplémentaires sont nécessaires pour calculer les valeurs d'attributs cibles tels que les noms d'éléments. L application d une règle à un graphe définit en fait une relation binaire qui peut arbitrairement être itérée selon un processus de dérivation. Appliquer une théorie de transformation de graphes au problème de transformation de modèles nécessite une formalisation appropriée du modèle et du méta-modèle. Figure 2.6 Principe de règle de transformation de graphe 48

67 Chapitre 2 : Ingénierie Dirigée par les Modèles Dans la figure 2.7, nous montrons l application d une règle de transformation de graphe payfacture modélisant le paiement d une facture par transfert du montant requis du compte client. De façon opérationnelle, l application est réalisée en trois étapes. Premièrement, trouver une occurrence o L de la partie gauche L dans le graphe actuel G. deuxièmement, enlever tous les sommets et les arcs de G qui sont en correspondance avec L\R et s assurer que la structure restante D := G\ o (L\R) est toujours un graphe valide, i.e. qu il ne doit pas y avoir d arcs pendants dus à la suppression de leur sommet source ou cible. Si ce n est pas le cas, l application est interdite. Troisièmement, intégrer D avec R\L pour obtenir le graphe dérivé H. dans la figure 2.7, l occurrence de la règle est désignée par les objets ombrés dans la transformation. Figure 2.7 Exemple d une étape de transformation utilisant la règle payfacture 5. Approches de composition des services Web dirigée par les modèles Les principes de l IDM sont tout à fait applicables au développement de services Web composés étant donné qu il s agit de composants logiciels. De plus, l application des principes de l IDM au développement des services Web composés présente de nombreux avantages qui ont conduit à son adoption par de nombreux travaux dans le domaine. En premier lieu, l élaboration de modèles de services Web composés épargne aux développeurs les changements et les évolutions liés aux technologies utilisées, puisque la composition des services est un domaine très actif où les technologies évoluent considérablement. Seules les règles de transformation de modèle vers le code sont en mesure d être modifiées. L utilisation des modèles abstraits présente également l avantage de pouvoir générer différents types de codes à partir du même modèle selon le langage de composition ciblé. Toutes les approches pour la composition des services Web proposées dans la littérature et basées sur l IDM suivent en général les mêmes étapes. L idée principale 49

68 Chapitre 2 : Ingénierie Dirigée par les Modèles étant de démarrer avec une définition abstraite et de graduellement la rendre concrète de façon à générer un processus exécutable à partir des spécifications abstraites. Les services Web sont typiquement désignés pour interagir entre eux afin de former des services plus complets. Du point de vue de l IDM, la construction de nouveaux services par composition de services existants soulève des perspectives intéressantes qui influent considérablement sur la voie de développement des applications industrielles futures. Elle soulève également un nombre de challenges pour garantir la correction de l interaction des différentes parties communicantes. Dues à la nature de l interaction des services qui est basée sur l échange de messages, plusieurs erreurs peuvent apparaitre lorsque plusieurs services communiquent entre eux (non réception, inter-blocage, comportement incompatible, etc.). Ces problèmes bien connus sont récurrents dans le contexte d applications distribuées, mais ils deviennent cependant critiques dans le contexte de la composition des services. En effet, comme la composition de services est essentiellement régie par la vision à long terme de «services utilisés par des services», plutôt que celle de «services utilisés par des humains», les interactions doivent idéalement être aussi transparentes et automatiques que possible. Dans le chapitre précédent, nous avons mis l accent sur le problème majeur des approches classiques de composition rencontrées, qui est l absence de moyens de vérification de la composition des services, d où la nécessité de l utilisation de modèles formels. En particulier, ces modèles formels sont utilisés pour décider si les services satisfont certaines propriétés désirables. Si l on parvient à découvrir qu une propriété au sein du modèle est violée, il devient alors plus facile de diagnostiquer les erreurs de composition et par conséquent de corriger la conception. Plusieurs modèles ont été utilisés pour mener à terme la composition des services. Nous proposons dans ce qui suit une classification des approches dirigées par les modèles pour la composition de services Web basée sur le type de langage de modélisation utilisé [Morimoto, 2008]. Cette classification est schématisée par un diagramme présenté dans la figure 2.8. Deux catégories de langages ont été utilisées pour mettre en œuvre les approches de modélisation de la composition : les langages formels et les langages de modélisation des processus métiers. Dans la première catégorie, trois principaux types de modèles ont été identifiés par la communauté des modèles formels et utilisés pour la composition des services. Le premier type de modèle englobe les réseaux de Petri [Petri, 1962] et leurs différentes extensions, comme les réseaux de Petri colorés [Jensen, 1996] et les réseaux de Petri temporels [Zuberek, 1991]. Le second type regroupe les algèbres de processus telles que CSS et π-calculus [Milner, 1982]. Le troisième type concerne les systèmes de transition d état, dans lesquels nous retrouvons essentiellement les automates à états finis [McCulloch & Pitts, 1943], à entrées/sorties [Lynch & Tuttle, 1987] et temporisés [Alur & Dill, 1994]. La seconde catégorie contient les langages pour la modélisation des processus métiers comme BPMN (Business Process Model Notation) [BPMN] et les diagrammes d activité UML (Unified Modeling Language). Ces langages ont comme point commun le fait d être considérés comme étant moins formels. 50

69 Chapitre 2 : Ingénierie Dirigée par les Modèles Figure 2.8 Classification des approches basées IDM pour la composition des services Web 5.1. Approches utilisant les langages formels Dans le contexte des systèmes distribués et plus particulièrement celui des services Web, la concurrence constitue l un des aspects les plus importants du fait que plusieurs tâches peuvent être réalisées simultanément ou interagir entre elles. Les systèmes concurrentiels, réseaux de Petri ou algèbres de processus, sont des formalismes précis et bien établis pour la modélisation et la vérification automatique de la composition des services. Les systèmes de transition d états ont une base formelle qui permet leur utilisation pour la description formelle des systèmes. Dans les sous-sections qui suivent, nous allons passer en revue les approches pour la composition des services Web existantes basées sur ces trois formalismes Approches utilisant les réseaux de Petri Un réseau de Petri est un modèle mathématique servant à modéliser le comportement des systèmes qui ont la caractéristique d être concurrents, asynchrones, distribués, parallèles et/ou non-déterministes. Développés à l origine par Carl Adam Petri [Petri, 1962], leur principale attraction est la façon naturelle dont ils identifient mathématiquement et conceptuellement les aspects de base des systèmes concurrents. Dues à leur facilité de modélisation conceptuelle et graphique, et à leur aptitude à contrôler les flux des processus, ils sont devenus le modèle de choix dans diverses applications. En effet, ils peuvent modéliser les situations les plus complexes. De nombreux travaux ont montré la possibilité de modéliser la composition de services à l aide des réseaux de Petri. Les réseaux de Petri simples ont été largement utilisés pour modéliser la composition des services Web [Hamadi & Benatallah, 2003] [Feng et al., 2006][Yi & Kochut, 2004]. Dans [Hamadi & Benatallah, 2003], les auteurs utilisent les réseaux de Petri pour la modélisation du contrôle de flow dans les services Web. Cette approche fait correspondre une transition à un appel de service et une place à un état entre les appels. Avec le même formalisme, les auteurs introduisent également une algèbre pour la composition des services. Leur modèle est suffisamment 51

70 Chapitre 2 : Ingénierie Dirigée par les Modèles expressif pour rendre possible la création de relations dynamiques et temporaires entre les services. Toutefois, le principal inconvénient c'est que les types de données ne peuvent pas être distingués parce qu un modèle réseau de Petri élémentaire est utilisé. Un langage de description architectural basé sur les réseaux de Petri est introduit par [Zhang et al., 2004]. Dans ce langage, les systèmes orientés service peuvent être modélisés et analysés de façon automatique. L approche est uniquement illustrée par un simple cas d étude. Les auteurs prévoient de développer un moteur de translation automatique de WSDL, vers le langage qu ils proposent, pour faire face aux applications de taille réelle, et pour éliminer les erreurs dues à la transformation manuelle. Dans le même contexte, les travaux de [Ouyang et al., 2007] présentent un mapping faisant correspondre tous les constructeurs BPEL, spécialement ceux permettant de contrôler les flux, avec des structures réseaux de Petri, permettant ainsi d appliquer les techniques d analyse et de vérification des réseaux de Petri existantes. En particulier, BPEL intègre deux constructeurs sophistiqués Branching et Synchronisation qui existent dans les modèles Workflow. Une formalisation complète de tous les constructeurs BPEL en termes de mapping vers les réseaux de Petri permet de lever toutes les ambigüités des spécifications BPEL actuelles. Dans [Narayanan & McIlraith, 2002], une définition de la sémantique d un sous ensemble de DAML-S (à présent OWL-S) est présentée en termes de logique du premier ordre. En se basant sur cette sémantique, les auteurs décrivent des compositions de services Web dans le formalisme réseau de Petri. Ils discutent de l implémentation d un outil qui décrit et vérifie de façon automatique la composition des services Web. Dans [Yi & Kochut, 2004], les auteurs suivent la même intuition et proposent un Framework pour la composition des services basé sur les réseaux de Petri, qui peut être utilisé pour visualiser, créer et vérifier des processus BPEL existants. Cependant, ce Framework ne dispose pas encore d une interface graphique, permettant de visualiser les réseaux de Petri, et d assister les utilisateurs lors de la création de compositions de services Web. Les travaux de [Hinz et al., 2005] présentent une sémantique complète et formelle pour les réseaux de Petri incluant ainsi la gestion des exceptions. De plus, un parseur BPEL2PN transformant automatiquement les processus BPEL en réseaux de Petri est présenté. Suite à ce résultat, une variété d outils de vérification est applicable pour l analyse des processus BPEL. Il existe un autre Framework pour modéliser les processus BPEL par le biais des réseaux de Petri, incluant un algorithme pour l analyse de certaines propriétés comme l accessibilité [Martens, 2005]. Récemment encore, d autres approches basées sur les réseaux de Petri ont été proposées par [Ait-Cheikh-Bihi et al., 2012] et [Fan et al., 2013]. Dans [Ait-Cheikh- Bihi et al., 2012], une approche dirigée par les modèles est proposée pour spécifier, valider et implémenter les compositions de services Web en utilisant deux outils formels qui sont les réseaux de Petri et l algèbre (max, +). L inconvénient majeur de l utilisation des réseaux de Petri simples pour la modélisation de la composition est qu ils ne sont pas aptes à modéliser toutes les structures de contrôle de flow avancées. Comme solution, d autres travaux ont présenté des approches basées sur les réseaux de Petri colorés (CPN) [Jensen, 1996] qui sont une extension des réseaux de Petri supportant la récursivité et permettant de décrire le 52

71 Chapitre 2 : Ingénierie Dirigée par les Modèles comportement dynamique d un système. La proposition de [Zhang & Jeckle, 2008] offre un support sémantique permettant d améliorer la fiabilité et la maintenance des services composites. Elle permet également l'analyse de disponibilité, la confidentialité et l'intégrité du service composite. Le Framework CPN est également exploité par [Yubin et al., 2006] où une algèbre efficace est suggérée pour modéliser la composition de services Web. Les auteurs fournissent aussi des algorithmes pour construire et exécuter un service composite. Ces deux travaux semblent très liés, même si dans [Yubin et al., 2006] la séquence de composition de services ne peut pas être automatiquement générée parce que des conditions prédéfinies sont nécessaires. Dans [Rosario et al., 2006], les auteurs utilisent en premier lieu le langage d orchestration Orc [Orc] pour dégager les grandes caractéristiques du concept d'orchestration, puis transforment ces spécifications Orc en réseaux de Petri colorés qui peuvent traiter la récursivité et la manipulation des données. Bien que les modèles à base de CPN soient suffisamment expressifs, ils ne parviennent pas à faire face à d autres problèmes tels qu une modélisation de données assez pauvre, et une production de modèles très étendus qu il devient difficile de capturer et de maintenir. Dans une approche basée sur les réseaux de Petri Orientés Objet (OOPN) [Feng et al., 2006], la composition des services Web repose sur une transformation d un service en des objets de collaboration. Par conséquent, la description de leur comportement et des communications entre eux peut facilement être effectuée en utilisant le modèle OOPN. Cette approche est très intéressante car un outil de conception de processus Web WPDT (Web Process Design Tool) permettant de faire graphiquement la composition est offert. Le comportement et les performances d'un système peuvent être vérifiés lors de l étude du processus en action. Finalement, une approche récente basée sur les réseaux de Petri pour formaliser la composition des services peut être trouvée dans [Hartonas, 2007]. Cette proposition définit une classe de réseaux de Petri ouverts et introduit une opération de composition (concurrent join). L opération de composition dépend de l identification des correspondances des transitions d'entrée-sortie. La composition des services est également décrite avec le formalisme défini (réseaux de Petri ouverts), permettant ainsi la mise en place du processus de vérification Approches utilisant les algèbres de processus A l instar des réseaux de Petri, les algèbres de processus sont des formalismes précis et bien établis qui permettent la vérification automatique aussi bien des propriétés fonctionnelles que non fonctionnelles. Ils apportent une théorie riche de l analyse de bisimulation, i.e. établir si deux processus ont des comportements équivalents. De telles analyses sont utiles entre autres pour déterminer si un service peut être substitué par un autre service dans une composition ou pour vérifier la redondance d un service. L algèbre π-calculus [Milner et al., 1992] a inspiré les langages modernes de composition des services comme BPEL. La raison qui motive l utilisation de π-calculus pour la description des processus est proche de celle qui motive les réseaux de Petri. Elle réside dans les avantages fournis par une algèbre avec une riche théorie, à savoir la 53

72 Chapitre 2 : Ingénierie Dirigée par les Modèles vérification automatique des propriétés comportementales exprimées dans un tel formalisme. D un point de vue compositionnel, π-calculus offre des constructeurs pour composer des activités en termes d exécution parallèle, séquentielle et conditionnelle. Parmi les approches spécifiant et vérifiant la composition des services avec les algèbres de processus, les travaux de [Foster et al., 2007] décrivent un processus de vérification et l appliquent sur plusieurs études de cas. Ce processus est basé sur la translation d un modèle BPEL d une composition de services vers FSP (Finite State Processes) [Magee & Kramer, 2006]. Ainsi, en se basant sur l équivalence comportementale, il est possible de vérifier la correction de la composition FSP résultante. Dans [Salaün et al., 2004], les auteurs préconisent l utilisation des algèbres de processus pour décrire, composer et vérifier les services en mettant un accent particulier sur leurs interactions. En conséquence, ils présentent une étude de cas utilisant l algèbre CCS pour la spécification et la composition des services. Un banc d essai est utilisé pour valider les propriétés de la composition. Des algèbres de processus plus avancées ont été utilisées pour modéliser l échange de données durant l interaction des services Web. Dans [Ferrara, 2004], par exemple, un mapping à deux sens est défini entre BPEL et l algèbre de processus LOTOS [Bolognesi & Brinksma, 1987], l une des algèbres les plus expressives. L avantage de cette transformation est l inclusion de compensations et de la gestion des exceptions, permettant ainsi la vérification de propriétés temporelles. En utilisant ces transformations, deux choix sont possibles : concevoir en BPEL et vérifier avec l algèbre de processus, ou bien concevoir et vérifier avec l algèbre de processus. Finalement, dans [Rouached & Godart, 2007], un outil BPEL2EC est présenté. Ce dernier peut automatiquement transformer des processus BPEL en EC (Event Calculus). L outil considère en entrée une composition de services et produit en sortie sa spécification comportementale en EC. Par la suite, cette spécification peut être exprimée selon un format adéquat afin d être prouvée par le système d inférence SPIKE [Stratulat, 2001]. Bien que les algèbres de processus soient bien adaptées pour la description de systèmes étendus et complexes, il apparait que leur notation textuelle contribue à les rendre moins lisibles que les réseaux de Petri. Par ailleurs, toutes les approches présentées reposent sur des techniques d'analyse traditionnelles, et omettent généralement les difficultés liées aux interactions asynchrones et la complexité des données Approches utilisant les systèmes de transition d états Les automates ou systèmes de transition d états sont des modèles dont la célébrité est due à leur caractère formel. La façon intuitive dont un automate modélise le comportement d un système a donné naissance à plusieurs modèles de spécification basés sur les automates comme les automates à états finis [McCulloch & Pitts, 1943], Entrée/sortie [Lynch & Tuttle, 1987] et temporisés [Kaynar et al., 2010]. Leur base formelle facilite la mise en place d outils automatiques, permettant ainsi leur utilisation pour la description formelle, la composition et la vérification des compositions de services. Dans ce qui suit, nous présentons quelques approches basées sur ce formalisme. 54

73 Chapitre 2 : Ingénierie Dirigée par les Modèles Les travaux de [Zheng et al., 2007] ont défini une sémantique opérationnelle de BPEL pour tester les compositions de services Web. Cette sémantique est décrite par un type spécial d automates appelés WSA (Web Service Automata). Le modèle WSA (codé en XML) est utilisé en tant que modèle intermédiaire et est ensuite transformé dans le langage d entrée du model-checker SPIN [Holzmann, 2003]. De même, dans [Fisteus et al., 2004], les automates sont utilisés pour la transformation de processus BPEL vers Promela. L outil SPIN peut ensuite être utilisé pour vérifier si les compositions obtenues satisfont certaines propriétés exprimées en logique temporelle linéaire (LTL). Dans [Kazhamiakin & Pistore, 2006], une codification de processus BPEL est transformée et modélisée à l aide d un formalisme très lié aux automates temporisés. Les auteurs montrent comment les propriétés temporelles (qualitatives et quantitatives) peuvent être facilement vérifiées en les soumettant au vérificateur open source NuSMV [Cimatti et al., 2000] qui permet également de vérifier des propriétés exprimées en LTL. Cette approche a été étendue par les mêmes auteurs en modélisant la composition par le biais de systèmes de transitions d états étendus. Dans certains travaux, les descriptions de services écrites en BPEL/WS-CDL peuvent être automatiquement transformées en automates temporisés [Diaz et al., 2006]. Dong et al [Dong et al., 2006] proposent un Framework pour la vérification automatique des systèmes modélisés avec le langage d orchestration des services Web Orc. Cependant, il n y a pas d outils disponibles pour la vérification des propriétés critiques des modèles Orc. Donc au lieu d en construire, il est préférable de réutiliser les outils matures déjà existants. L approche consiste donc à définir en premier lieu une sémantique d automates temporisés pour le langage Orc, qui est équivalente à la sémantique opérationnelle originale. En conséquence, les modèles d automates temporisés sont systématiquement construits à partir des modèles Orc. L implication pratique de cette construction est que les outils prenant en charge les automates temporisés, comme UPPAAL par exemple, peuvent être utilisés pour la vérification. L approche est validée par l implémentation d un outil expérimental. Dans [Mitra et al., 2007], les services sont représentés par le biais d automates à entrées/sorties qui peuvent décrire les interfaces des services d une manière succincte et précise. Dans cette approche, deux types de chorégraphes sont considérés : un chorégraphe simple capable de transmettre les sorties d un service vers l entrée d un autre, et un chorégraphe de transduction capable de stocker et de réutiliser les entrées/sorties des services. La technique de cette approche repose sur la génération de représentation d automates à entrées/sorties à partir de tous les comportements de services chorégraphiés possibles et la vérification du comportement du service composé par des simulations de l ensemble des comportements chorégraphiés. Lallali dans [Lallali, 2009] propose une modélisation formelle des orchestrations de services et des méthodes pour les tester. L auteur définit un nouveau modèle appelé WSTEFSM qui est un type d automates étendu par un ensemble d horloges et de priorités associées aux transitions. Dans toutes les approches utilisant les systèmes de transition d états que nous avons étudiés, nous avons pu constater que le principal inconvénient des automates est leur incapacité à modéliser la concurrence d une manière directe (sans adaptation). Comme 55

74 Chapitre 2 : Ingénierie Dirigée par les Modèles conséquence, ils ne sont pas en mesure de modéliser certaines structures de contrôle importantes comme le choix non-exclusif et la synchronisation structurée. Ces structures font partie des structures de contrôle utilisées par le langage de composition le plus utilisé qui est BPEL Approches utilisant les langages de modélisation des processus métiers Un processus métier est une collection d activités conçues pour produire un résultat spécifique pour un client particulier. Il met l accent sur la façon dont un travail est réalisé au sein d une organisation. Un processus est donc un ordonnancement spécifique des activités d un travail à travers le temps et l espace. Il est marqué par un début et une fin ainsi qu une définition claire des entrées et des sorties. De plus en plus de travaux se sont concentrés sur la modélisation de la composition de services Web sous forme de processus métier. Ces travaux utilisent généralement des outils standards de modélisation des processus métiers comme BPMN ou le diagramme d activité UML. De tels langages présentent l avantage d être faciles à utiliser et à comprendre et ce en raison de leur caractère graphique Approches utilisant BPMN BPMN (Business Process Management Notation) a été développé par BPMI (Business Process Management Initiative) et est considéré comme un standard pour la modélisation des processus métiers. BPMN adopte une représentation graphique pour la modélisation des processus métiers à l aide de structures de contrôle telles que le choix exclusif, le branchement multiple et la synchronisation. C est à l aide de ses nombreuses structures de contrôle que BPMN définit le diagramme de processus métier (BPD). Le modèle de processus métier est alors un réseau d objets graphiques (les activités) et de contrôles de flux. Ces derniers définissent l ordre d'exécution des activités. Bien qu étant une proposition récente, BPMN est déjà supporté par plus de 60 outils. White, dans [White, 2004], a présenté un ensemble de règles permettant de transformer BPMN vers le langage BPEL. Ces règles ont par la suite été exploitées au sein de différents outils. BPMN à ainsi pu être utilisé pour la composition de services grâce à sa notation simple pour la modélisation des interactions entre les services sous forme d un processus métier. Le code BPEL est ensuite généré à partir du modèle en BPMN pour permettre l exécution du service composé. Une étude détaillée des transformations BPMN vers BPEL décrites dans [White, 2004] a été conduite par Ouyang et al., dans [Ouyang et al., 2006]. Cette étude montre que ces transformations ne parviennent pas à remplir les exigences suivantes: (1) l'intégralité, c'est-à-dire applicables à n'importe quel modèle BPMN, (2) l'automatisation, c'est à dire capables de produire un code cible sans l'intervention humaine, et (3) la lisibilité, c'est à dire produisent un code cible qui soit consistant et compréhensible par les humains. De plus, et toujours d après Ouyang, les règles introduites par White [White, 2004] sont limitées car d une part, la transformation ne prend pas en charge toutes les structures de contrôle, et d autre part, les transformations ne sont pas automatisées. Les limitations des transformations BPMN-vers-BPEL existantes ne sont pas surprenantes puisque 56

75 Chapitre 2 : Ingénierie Dirigée par les Modèles BPMN et BPEL représentent deux classes de langages fondamentalement différentes. BPMN est orienté graphe alors que BPEL est principalement structuré en blocs. Dans le cas des organigrammes, la transformation de diagrammes non structurés en diagrammes structurés constitue un défi Approches utilisant UML UML (Unified Modeling Language) est un langage standard de modélisation avec une notation graphique riche et un ensemble de diagrammes et d éléments compréhensifs. Tout comme BPMN, UML est maintenu par l OMG (Object Management Group). Le diagramme d activité UML constitue le principal concurrent du diagramme de processus métier BPMN. La proposition de [Orriens et al., 2003] introduit une approche IDM de composition des services dans laquelle UML est utilisé pour fournir un certain niveau d abstraction et pour permettre des correspondances directes avec d autres standards comme BPEL. Le langage OCL est utilisé pour exprimer les règles décrivant le flux des processus. Les règles peuvent être utilisées pour structurer et planifier la composition des services, et pour décrire la sélection des services et les liaisons entre eux. Afin de pouvoir représenter toutes les compositions possibles, les auteurs introduisent un modèle informel (un méta-modèle abstrait) qui modélise les composants et les relations entre eux. UML est également utilisé dans [Dahman, 2010] pour la modélisation des services Web afin de réaliser une composition automatique. L'approche est basée sur un profil pour le langage de modélisation UML. Les modèles de service Web obtenus permettent la génération du code source ainsi que les fichiers de configuration spécifiques à la plateforme d exécution des services Web modélisés. La génération de code est réalisée au moyen de règles de transformation et de génération de code définies dans le langage de transformation Xpand. De plus, un modèle de développement simple pour l'application du profil est proposé. La faisabilité de l'approche proposée pour le modèle de développement basé sur des services Web est validée par la mise en œuvre d'un service Web du système de bibliothèque. Dans [Skogan et al., 2004], une approche utilisant des diagrammes d'activité UML pour modéliser la composition des services Web est présentée. Les auteurs fournissent un moyen de modéliser la coordination et le séquençage des interactions entre les services Web. Ils expliquent aussi comment des diagrammes d activité UML peuvent être convertis en code BPEL. Récemment encore, les travaux de Dumez dans [Dumez, 2010], ont proposé un profil UML (appelé UML-S) utilisé pour modéliser la composition de services à l aide des diagrammes de classes et d activités. Il est à noter que l auteur a également défini des règles de transformation des diagrammes UML-S en BPEL. Si les langages tels que BPMN ou les diagrammes d activité UML sont connus pour leur simplicité et la lisibilité de leurs modèles, ils restent cependant inadéquats pour modéliser la composition des services Web et pour l analyser d une manière formelle. La principale raison étant leur manque de formalisme. Ce manque de formalisme à entre autres été démontré dans [Wohed et al., 2006]. 57

76 Chapitre 2 : Ingénierie Dirigée par les Modèles 6. Conclusion Dans ce chapitre, nous avons introduit les concepts de base de l ingénierie dirigée par les modèles. Nous avons vu que la transformation de modèles est une notion clé et qu elle joue un rôle décisif dans l IDM, c est pourquoi nous lui avons consacré une bonne partie du chapitre. Une classification des approches de transformation basée sur différents critères à été rapportée et les caractéristiques particulières de certaines classes de transformation ont été identifiées. Suite à cela, nous avons présenté les approches existantes dans la littérature utilisant l IDM pour effectuer une composition de services Web. Une classification de ces approches par type de langage utilisé ainsi qu une brève description de celles-ci est présentée. Suite à cette étude, nous avons pu tirer un certain nombre de conclusions. Les réseaux de Petri simples et temporisés présentent des capacités limitées pour prendre en compte les spécificités de la composition des services Web. Leur incapacité à modéliser les structures de contrôle de flow provient du fait que ces deux formalismes ne présentent pas de possibilité de conditions sur les arcs. Ce problème a été en partie résolu par l utilisation des CPN qui supportent des structures de contrôle avancées comme le choix non exclusif et la synchronisation structurée. Malgré la puissance d expressivité présentée par les CPN, il reste le problème de mauvaise modélisation de données car ils offrent uniquement la notion de couleur. Par ailleurs, tout comme les autres approches basées sur les réseaux de Petri, ils produisent des modèles très étendus difficiles à gérer. De plus, toutes les approches proposées ne définissent pas de méthode claire pour donner un cadre formel aux descriptions WSDL des services à composer, qui constitue l unique information disponible sur les services Web. Nous avons également pu constater que bien que les algèbres de processus permettent la vérification automatique de la composition, leur notation à caractère textuel ne contribue pas à les rendre aussi lisibles que les modèles à caractère visuel. De plus, la composition modélisée avec ce formalisme ne permet pas de prendre en compte les difficultés liées aux interactions asynchrones et à la complexité des données. L étude sur les approches utilisant les systèmes de transition d états nous a amené à constater que le principal inconvénient avec ce type de langage est qu il est inapte à modéliser la concurrence de façon directe. Ces langages ne peuvent donc pas représenter le choix non-exclusif et la synchronisation structurée qui sont des structures de contrôle inéluctables modélisant des aspects de la concurrence. Les derniers types de langages étudiés dédiés aux processus métiers tels qu UML et BPMN se sont avérés assez faciles à appréhender et produisent des modèles très lisibles. Leur utilisation n est cependant pas conseillée vu leur manque de formalisme qui rend très difficile la vérification des modèles de services Web composés. Cette analyse des différentes approches nous a permis d identifier de façon précise les insuffisances de chacun des langages utilisés. Pour pallier à tous ces problèmes, nous proposons une nouvelle approche de composition des services Web basée sur l utilisation massive des principes de l IDM. La première partie du chapitre suivant sera consacrée à la présentation du langage de modélisation que nous avons défini. Ce langage, comme nous le verrons, est beaucoup 58

77 Chapitre 2 : Ingénierie Dirigée par les Modèles plus adapté à la modélisation et à la vérification des compositions de services Web. La deuxième partie du chapitre suivant sera quant à elle consacrée à donner une vue globale sur l approche de composition proposée. Cette dernière se présente sous forme d une méthodologie se déroulant en plusieurs phases qui s appuie sur le langage de modélisation spécifique au domaine que nous avons baptisé S-GNet. 59

78 Chapitre 3 La Méthodologie WS-mcv

79

80 Chapitre 3 : L approche WS-mcv Chapitre 3 La Méthodologie WS-mcv 1. Introduction L'Ingénierie dirigée par les modèles est approche de développement logiciel qui a pour principal objectif de relever un certain nombre de défis du génie logiciel (qualité, productivité, séparation des préoccupations, coût, etc.) en suivant une approche à base de modèles dite générative. En focalisant le raisonnement sur les modèles, l IDM permet de travailler à un niveau d abstraction supérieur. Ceci en offrant un éventail d outils permettant de concevoir aisément des DSL (Domain Spécifique Language) selon les besoins spécifiques à chaque application. En se basant sur l étude des approches basées IDM pour la composition des services Web que nous avons menée au chapitre précédent, nous avons identifié un certain nombre d exigences. Ces exigences concernent le langage de modélisation qui devrait être utilisé au sein de notre approche pour modéliser la composition. Le formalisme doit être: Exigence 1 : Bien établi, déjà connu et ayant fait ses preuves en matière d efficacité. Exigence2 : Graphique, simple et clair pour être facilement déchiffré par les utilisateurs. Exigence 3 : Basé sur de fondements solides et formels afin de permettre la vérification de modèles. Exigence 4 : Capable de représenter les interfaces des services Web ainsi que le dynamisme induit par leur composition. Exigence 5 : Capable de modéliser le flux de contrôle et les flux de données en cours. Exigence 6 : Assez expressif pour permettre la génération du code à partir du modèle de composition. Il convient de mentionner que le service composite fait simplement appel aux autres services et les fait interagir. Comme conséquence, il ne devrait pas y avoir beaucoup de programmation nécessaire. Parmi les langages adoptés dans les approches basées IDM pour la composition des services Web, les réseaux de Petri avec leur différents types ont largement été utilisés. En effet, plusieurs travaux ont prouvés que les RdP présentent des qualités qui les rendent adéquats pour une modélisation claire et précise des Workflows. La spécification des Workflows à l aide des RdP permet d aboutir à un résultat de modélisation rigoureux et fidèle aux problèmes modélisés dans ses moindres détails. L inconvénient majeur des RdP pour la modélisation des compositions de services est que ce formalisme n est pas capable de modéliser tous les structures de contrôle offertes par le langage standard de composition des services Web qui est BPEL. De plus, les RdP offrent une modélisation des données assez pauvre. Ceci est principalement du au fait que les types de données ne sont pas distinguable au sein de ce formalisme. 60

81 Chapitre 3 : L approche WS-mcv Pour passer outre ces problèmes rencontrés, nous proposons le langage de modélisation S-GNet. Ce Framework, comme nous allons voir dans ce qui suit, à été conçu afin de satisfaire l ensemble des exigences identifiées. L approche que nous proposons pour la composition des services Web suit les principes fondamentaux de l IDM, et ce dans toutes les étapes de l approche. Notre objectif étant d améliorer les approches existantes en apportant simplicité et fiabilité au sein du développement des services Web composés. L organisation de ce chapitre est la suivante : nous introduisons dans la section 2 le langage de modélisation G-Net qui nous a servi de base pour la définition de notre propre DSL. Dans la section 3, nous présentons les S-GNets, langage que nous avons défini comme extension des G-Nets et qui répond aux besoins de la composition des services Web. Ce dernier représente le langage de modélisation sur lequel s articule l approche de composition que nous présentons dans la section 4. Le chapitre s achève par une conclusion. 2. Le formalisme G-Net Les G-Nets, introduits par [Deng et al., 1993], constituent un Framework basé sur les réseaux de Petri. Il est utilisé pour la conception modulaire et la spécification des systèmes d'information complexes et distribués. Ce cadre fournit un formalisme qui intègre pleinement la structure orientée objet dans les réseaux de Petri. Le but de cette intégration est d une part, de profiter des avantages du traitement formel et du confort expressif des réseaux de Petri et d autre part, de bénéficier des avantages de l'approche orientée objet (logiciels réutilisables, composants extensibles, encapsulation, etc.). Dans ce qui suit, nous présentons d abords les concepts inhérents au formalisme G- Net, puis nous décrivons la représentation du formalisme G-Net en utilisant la métamodélisation Les concepts des G-Nets Un système conçu à l aide du Framework G-Net se compose d'un ensemble de modules autonomes et faiblement couplés appelé G-Nets. A l instar d un objet dans le concept de programmation orientée objet, un G-Net satisfait la propriété d'encapsulation, c.-à-d. un module ne peut accéder à un autre qu à travers un mécanisme bien défini appelé G-Net abstraction. Un G-Net se compose de deux parties, la GSP (Generic Switch Place), qui représente l interface du G-Net et l IS (Internal structure) qui est la structure interne ou la réalisation du G-Net. La GSP fournit les informations sur le nom du G-Net et les méthodes qu il renferme. L IS est une sorte de RdP modifié qui se compose de places, de transitions et d arcs. Les places représentent des primitives qui peuvent être des actions ou des appels de méthodes. Ces derniers sont désignés par ISP pour Instanciation Switch Place. L ensemble des Transitions et des Arcs représente les relations entre les primitives. Une primitive ne peut être exécutée que si elle est activée, et son activation a lieu lorsqu elle reçoit un jeton. Dans ce qui suit nous donnons plus de détails sur les différents éléments de la structure des G-Nets. 61

82 Les arcs Chapitre 3 : L approche WS-mcv Un arc placé entre une place d entrée p et une transition t peut avoir une inscription. Celle-ci est soit une variable soit une expression logique sur des variables. L inscription sur l arc définit la condition pour laquelle la transition t est activée et définit aussi les valeurs qui doivent être exportées par la place p en input. Un arc placé entre une transition et une place de sortie peut lui aussi porter une inscription, celle-ci est sous forme d une liste de variables qui définit le contenu des jetons en entrée de chaque place en output Les places ISP Chaque ISP d un G-Net dénote une instance d invocation du G-Net basée sur une de ses méthodes. L exécution d une primitive ISP implique l invocation du G-Net par l envoi d un jeton. L exécution utilise le contenu du jeton reçu. Une propriété intéressante du Framework G-Net est qu il est possible d exécuter simultanément plusieurs invocations d un même G-Net. Ceci est possible grâce à la structure spécifique du jeton dans le Framework G-Net Les Jetons Un jeton est défini par un triplet (seq,sc,msg) où seq est une séquence de propagation du jeton, sc est le statut color du jeton et msg est le message porté par le jeton. Seq : est une séquence de la forme <Nid,ISP,Pid>, où Nid est l identifiant unique d un G- Net, ISP est le nom d une ISP et Pid est l identifiant du processus chargé d exécuter l instance du G-Net invoqué. L élément seq d un jeton est changé uniquement dans les ISP et les GSP (l interface). Quand un G-Net G est invoqué à partir d une ISP isp i dans un autre G-Net G, un tuple <G,isp i, Pid> est ajouté à l élément seq du jeton avant d être envoyé à G. Ceci indique qu une fois l exécution de G terminée, le jeton résultant doit être retourné à la place isp i du G-Net G. Lors de la réception d un jeton par la GSP du G-Net G, un tuple <0,0,Pid G > est ajouté à la fin de l élément seq du jeton. Ceci indique que l agent responsable de l exécution de l invocation est défini par Pid G. Le Pid est nécessaire pour distinguer l instance d exécution de G à laquelle le jeton résultant appartient. La structure du jeton dans le Framework G-Net garantit que tous les jetons appartenant à une instance d un G-Net ont la même séquence de propagation. Elle garantit aussi que chaque jeton contient son historique complet de propagation. Cette propriété permet de gérer les interactions entre les processus exécutants une spécification G-Net. Sc : est le statut color du jeton. Le sc peut prendre deux valeurs possibles qui sont before/after. Un jeton est disponible si son sc=after, il est indisponible si son sc=before. 62

83 Chapitre 3 : L approche WS-mcv Lorsqu un jeton arrive dans une place, son sc := before. Après exécution de la primitive de la place alors le sc :=after. Ceci indique que le jeton est prêt à être utilisé dans les transitions suivantes. Msg : est une liste de valeurs spécifiques à l application Les transitions Une transition appartenant à un G-Net G est franchissable (ou activée) si les quatre conditions suivantes sont satisfaites: (a) Chaque place en entrée contient au moins un jeton qui satisfait la condition de l arc en entrée I(p,t), (b) Tous les jetons définis en (a) ont la même séquence de propagation, (c) Tous les jetons définis en (a) et (b) ont leur sc= after, et (d) Le nombre de jetons dans les places de sortie est inférieur à leur capacité. Une transition activée peut être tirée. Lors du tir : (a) Un jeton qui satisfait la condition de l arc en sortie I(t,p) est supprimé de chaque place en entrée. (b) Un jeton avec la même séquence de propagation et avec son sc= before et ayant sa partie msg définie par l opération O(p,t) est déposé dans chaque place de sortie. La figure 3.1 illustre la structure globale d un G-Net avec tous les concepts que nous venons de décrire. La figure 3.2 quant à elle illustre un exemple simple de modélisation en utilisant le formalisme G-Net. Dans cet exemple, deux modules indépendants sont représentés : le G-Net Client et le G-Net Hôtel. Les GSP des deux G- Nets sont représentées par GSP(Client) et GSP(Hôtel) entourées par des ellipses. Les rectangles à coins arrondis sous les GSPs sont les ISs des G-Nets et contiennent quatre méthodes : bookroom(), askdate(), returnavail() et makereservation(). Les fonctionnalités de ces méthodes sont définies comme suit : askdate() invoque la méthode returnavail() qui est définie dans le G-Net Hotel pour vérifier si des chambres sont disponibles à des dates données; bookroom() invoque la méthode makereservation() définie dans le G-Net Hôtel pour réserver la chambre; returnavail() verifie la disponibilité des chambres au sein de l hôtel et makereservation(), génère la réservation et l envoie au G-Net Client. Dans la figure 3.2, MS et AS représentent respectivement l ensemble des méthodes et l ensemble des attributs. Le concepteur spécifie un appel synchrone de la méthode returnavail() offerte par le G-Net Hôtel en intégrant l ISP du G-Net Hôtel au sein de l IS du G-Net Client. Les flèches rouges en pointillés dans la figure sont seulement ajoutées dans un but illustratif et de telles flèches ne font pas partie de la structure des modèles G- Net. Pour une introduction plus détaillée au formalisme G-Net, le lecteur est référé à [Perkusich & De Figueiredo, 1997]. 63

84 Chapitre 3 : L approche WS-mcv Figure 3.1 Notations utilisées pour la représentation d un G-Net Figure 3.2 Un exemple de modélisation en utilisant les G-Nets 2.2. Méta-modélisation du formalisme G-Net L approche IDM est fondée sur l'utilisation massive de modèles au cours de toutes les étapes d'un cycle de vie d une l'application. Elle assure la stabilité du modèle en utilisant des méta-modèles comme éléments de structuration. Pour les concepteurs d applications, l'utilisation de ces techniques leur évite de coder en dur leurs applications lors de la création d environnements de modélisation personnalisés (DSLs). Ce faisant, l IDM élève le niveau d'abstraction du code source vers les modèles. Une fois le métamodèle défini, il est facile de faire de petites modifications pour obtenir des variations personnalisées du formalisme de modélisation pour un usage spécifique. Puisque le méta-modèle officiel des G-Nets n est pas disponible, nous proposons de définir nous-mêmes un méta-modèle. Nous avons étudié les méta-modèles déjà proposés 64

85 Chapitre 3 : L approche WS-mcv pour les G-Nets pour élaborer un méta-modèle adapté à une utilisation dans le cadre de notre approche de composition des services Web. La figure 3.3, illustre une représentation sous forme de méta-modèle du Framework G-Net. Le méta-modèle est défini en utilisant le Méta-langage diagramme de classes UML. Pour concevoir ce méta-modèle nous nous sommes inspirés des travaux de Kerkouche et al. [Kerkouche & Chaoui, 2009]. La syntaxe abstraite, la syntaxe concrète ainsi que la sémantique du langage de modélisation G-Net ont été clairement définies. Le méta-modèle capture toutes les spécificités du Framework G-Net que nous avons détaillées ci-dessous. Il comprend quatre classes reliées par cinq associations. La Classe "GSP": représente la place spéciale (Generic Switch Place) du G-Net. Elle possède un attribut Name ainsi que deux listes AS et MS contenant respectivement les variables manipulées ainsi que les méthodes offertes par le G-Net. La Classe "IS": représente la structure interne (IS) du G-Net. Chaque instance de cette classe dispose de trois contraintes qui permettent de garder ses composants (les places, les transitions et les arcs) à l intérieur de son apparence graphique. La Classe "Place": représente les places du G-Net. Elle possède cinq attributs: name, type, tokens, invokedgnet et usingmethod. L attribut type indique le type de la place. Les valeurs possibles pour cet attribut sont place ordinaire, place finale ou place ISP. Les attributs invokedgnet et usingmethod sont utilisés seulement dans le cas où la place est de type ISP. Ils contiennent respectivement le nom du G-Net auquel l ISP fait appel et la méthode invoquée. La contrainte TypeOfPlace donne l apparence graphique appropriée à chaque type de place. La Classe "Transition": représente les transitions du G-Net. Elle possède un attribut name et un attribut TransitionCondition représentant respectivement le nom de la transition et la condition de franchissement correspondant à cette transition. L Association "Realisation": elle relie la classe "GSP" à la classe "IS". Elle est visuellement représentée par une flèche partant de la place GSP du G-Net vers l IS correspondante. Cette association n est porteuse d aucun attribut. L Association "ArcPl2Tr": elle relie la classe "Place" avec la classe "Transition". Elle est visuellement représentée par une flèche portant l attribut arcinscription. Ce dernier représente la condition pour laquelle la transition est activée. L Association "ArcTr2Pl": elle relie la classe "Transition" avec la classe "Place". Elle est visuellement représentée par une flèche portant l attribut arcinscription. Dans cette association, cet attribut représente une liste de variables qui définit le contenu des jetons en entrée de chaque place en output. Les Associations "PlaceInside" et "TransitionInside": ces deux associations sont utilisées pour représenter l appartenance de places et de transitions à une structure interne (IS) d un G-Net. Il est à noter que ces deux associations n ont pas de syntaxe concrète (apparence graphique). 65

86 Chapitre 3 : L approche WS-mcv Figure 3.3 Le méta-modèle des G-Nets 3. S-GNet : Extension des G-Nets pour la modélisation des services Web Notre approche de développement des services Web composés repose sur l utilisation de modèles décrits dans un langage de modélisation adapté. L étude bibliographique que nous avons menée durant nos travaux de thèse nous a révélé que les réseaux de Petri simples et leurs différentes variantes sont certainement les mieux adaptés à la modélisation de la composition des services Web. Cette aptitude a notamment été démontrée par Ouyang et al dans [Ouyang et al., 2007]. Comme expliqué dans le chapitre précédant, les réseaux de Petri ont beaucoup été utilisés pour des problématiques de modélisation et de vérification de la composition de services. Ceci est clairement justifié par : La facilité de compréhension offerte par leur apparence visuelle Leur fondement mathématique qui permet une vérification formelle des modèles à la fois précise et puissante Leur expressivité qui leur permet la modélisation de la majorité des primitives des différents scénarios de composition Leur indépendance vis-à-vis des plateformes et langages de programmation Les différentes approches ayant utilisé un type de réseau de Petri pour la composition des services Web ont présenté certaines lacunes. Dans le cadre de notre travail, nous avons porté notre choix sur le formalisme G-Net pour la conception et la mise en œuvre de services Web composés réalisant une composition de type orchestration de services. Ce formalisme présente plusieurs avantages et nous est apparu comme une solution possible aux insuffisances rencontrées avec l utilisation des autres types de réseaux de Petri. Notre choix est justifié d une part, par le fait que ce formalisme est celui qui répond le mieux aux exigences définies au début du chapitre et d autre part pour les raisons suivantes : 66

87 Chapitre 3 : L approche WS-mcv 67 1) Contrairement aux réseaux de Petri classiques, les G-Nets produisent des modèles beaucoup plus réduits lors de la modélisation. Ce qui résout en partie le problème de l augmentation de la taille des modèles. 2) Les G-Nets permettent une bonne représentation des données échangées. Ceci permet de mieux capturer la complexité du scénario de composition. 3) La similarité de la structure d un G-Net avec celle d un service Web rend la modélisation plus intuitive (Structuration en méthodes, encapsulation et appel de méthodes). 4) Les G-Nets sont capables de représenter la totalité des structures de contrôle prises en compte par les langages d orchestration de services Web les plus utilisés tel que BPEL. Ceci est possible grâce à leur prise en charge des variables d environnement et des conditions sur les arcs. 5) Le cadre formel offert par les G-Nets rend possible la vérification des modèles décrits dans ce formalisme. 6) Les G-Nets permettent d obtenir des modèles abstraits suffisamment clairs qui peuvent servir de base à une génération automatique du code. Pour répondre d une façon beaucoup plus efficace à la tache de modélisation et de vérification des compositions des services Web, et dans le souci d offrir une conformité totale de ce formalisme avec les caractéristiques des services Web, nous avons proposé le DSL S-GNet. Ce dernier consiste en une extension des G-Nets permettant de supporter plus aisément la spécification et la modélisation des services Web. Cette extension est un atout important pour notre approche de développement puisqu il facilite la modélisation de la composition de services, tout en augmentant le niveau d expressivité des modèles obtenus. Le Framework S-GNet a spécialement été conçu pour offrir une correspondance intuitive avec les différents standards des services Web. Il permet aussi une meilleure modélisation des données échangées. Nous avons choisi de décrire la représentation des S-GNets en utilisant la métamodélisation. La notion de méta-modèle fournit une meilleure compréhension du formalisme, détermine l organisation des éléments de modélisation introduits et montre comment ces derniers peuvent s intégrer dans le méta-modèle des G-Nets. De plus, la méta-modélisation va contribuer à faciliter la manipulation des modèles exprimés dans le formalisme S-GNet (éditeurs, transformations,...). Toutes les caractéristiques de ce formalisme ont été capturées au sein du méta-modèle présenté dans la figure 3.4. On peut voir que ce méta-modèle possède des caractéristiques en commun avec les G-Net. Dans ce qui suit, nous présentons les principales extensions apportées sur le méta-modèle de base montré dans la figure 3.3. Nous avons étendu le Framework G-Net en associant une table de triplets à chaque S-GNet. Cette table contient la structure des messages d'entrée et de sortie du service modélisé. Elle contient également la définition des types de données complexes. Chaque ligne de la table est un triplet de la forme : <MName/CTName, PName, Type> Où :

88 Chapitre 3 : L approche WS-mcv MName/CTName: est soit le nom d un message input/output soit le nom d un type de données complexe, PName: est soit le nom d une partie de message ou le nom d un élément d un type complexe de données, et Type: est soit un des types de base (integer, string, etc.) ou le nom d un type complexe (composé de plusieurs types de base). Nous avons également modifié la structure de la GSP afin de l'adapter à la structure particulière des services Web où les activités sont regroupées en porttypes. Chaque porttype a un protocole spécifique utilisé pour interagir avec le porttype. La nouvelle structure de la GSP est le tuple <OGS, CPS> Où : OGS (Opération Group Set) : est l ensemble de tous les groupes d opérations offertes par le S-GNet. OGS= {<OGName: Op1(I1,O1), op2(i,o), >; } Où OGName est le nom d un groupe d opérations présent dans l OGS. Opi(Ii,Oi) est le nom d une opération présente dans un des groupes d opérations du S-GNet. Ii, et Oi sont les messages d entrée et de sortie de l opération. Le type et la structure des messages d entrée et de sortie sont dans la table associée au S-GNet. CPS (Corresponding Protocol Set) : est l ensemble de toutes les correspondances entre les groupes d opérations et les protocoles utilisés pour leur invocation. CPS= {<OGName, Ptcol>, } Où Ptcol est le nom du protocole associé à un groupe d opérations donné. Une autre extension que nous avons proposée concerne la structure interne (IS). Cette modification consiste en l ajout de nouveaux types de places qui sont les places Receive et Assign. Ces types de places sont utiles lors de l élaboration des services Web composés. Figure 3.4 Le Méta-modèle des S-GNets 68

89 Chapitre 3 : L approche WS-mcv Les places de type Receive sont utilisées pour spécifier le début d exécution d un service Web composé. Les places de type Assign possèdent un argument «FromTo» de type liste utilisé pour spécifier un certain nombre d opérations d assignation. Ces types de places possèdent aussi les arguments des places ordinaires dont ils héritent. La figure 3.5 illustre la structure globale d un S-GNet avec toutes les nouvelles extensions que nous venons de décrire y compris les nouveaux types de places. On peut noter que les places de type Receive sont représentées par un carré et les places Assign par une double ellipse. Ces nouveaux concepts que nous avons introduits ont tous été capturés au sein du méta-modèle des S-GNets que nous avons défini. Dans le méta-modèle, une classe supplémentaire nommée DataTable a été ajoutée. La classe possède deux attributs name et DataTriples représentant respectivement le nom de la table et ses différents triplets. Cette classe permet de modéliser les tables de données correspondant à chaque S-GNet. Des contraintes sont associées à cette classe pour garantir la cohérence des informations qu elle renferme. Le lecteur peut remarquer dans la figure 3.4 qu une association entre la classe GSP et la classe DataTable à été ajoutée. Cette association est utilisée pour exprimer l appartenance d une table à un S-GNet donné. Cette association est visuellement représentée par une flèche reliant le S-GNet à sa table de données. La classe GSP a aussi été modifiée pour permettre d intégrer les extensions faites au formalisme. La classe a été enrichie par les deux attributs OGS et CPS, représentant respectivement l ensemble des groupes d opérations et l ensemble des correspondances entre les opérations et les protocoles utilisés pour interagir avec les opérations. 4. La méthodologie WS-mcv Dans cette section, nous donnons un aperçu de l approche de composition proposée. L idée principale de cette approche est d exploiter les techniques offertes par l IDM présentées dans le chapitre précédent dans le but de définir une méthodologie de composition automatique qui couvre toutes les phases du processus de composition, de l importation des services à composer jusqu à la publication du service composite. Figure 3.5 Notations utilisées pour la représentation d un S-GNet 69

90 Chapitre 3 : L approche WS-mcv L approche proposée, que nous avons baptisée WS-mcv [Bachtarzi et al., 2012] (Web Service Modeling Composing and Verifying), traite les problèmes de la composition des services d une manière à la fois simple et efficace. Par ailleurs, pour réaliser les différentes phases du processus de composition, cette approche s appuie sur la transformation de modèles qui est un concept fondamental de l IDM. WS-mcv est une méthodologie qui traite des principaux problèmes qui apparaissent dans le domaine de la composition des services Web. Elle divise le processus de composition en plusieurs étapes offrant ainsi des solutions pour la spécification formelle des compositions des services Web, la vérification des modèles de composition et la génération automatique du code exécutable du service Web obtenu. Le processus, illustré par la figure 3.6 ci-dessous, permet aux développeurs d exploiter les services Web disponibles. Ces derniers agissent comme des composants réutilisables pour la réalisation de nouveaux services composites. La méthodologie WSmcv prend place à travers les étapes suivantes: 1. La Sélection des services existants : cette étape consiste à consulter un registre de services Web et sélectionner les services qui répondent aux besoins de la composition. 2. L'Extraction des interfaces de services : dans cette étape, des informations pertinentes pour la composition sont extraites à partir des descriptions WSDL des services sélectionnés. 3. La Spécification du modèle de composition: dans cette étape, le concepteur élabore un modèle de composition en utilisant le formalisme S-GNet selon un scénario de composition donné. 4. La Vérification du modèle de composition : cette étape correspond à la vérification formelle du modèle de composition S-GNet à l'aide des outils de vérification existants. 5. L Implémentation du modèle de composition: une fois que le modèle de composition est validé, il est transformé en code spécifique à la plate-forme tel que recommandé par l IDM. Ce code, exprimé en BPEL, représente la mise en œuvre du service composite. Ce dernier peut ensuite être publié dans un répertoire de services pour être réutilisé par d'autres applications. En suivant notre méthodologie, le développeur peut obtenir une composition correcte de services Web. Notre méthodologie présente plusieurs avantages. Le premier avantage est qu'elle prend en compte l'étape de spécification à un stade avancé du processus de développement. Le deuxième avantage de cette méthodologie est qu'elle est basée sur un langage de modélisation spécifique aux services Web (appelé S-GNet) capable de modéliser les services Web et leurs interactions de façon intuitive. Le DSL proposé offre également une représentation conviviale des descriptions WSDL des services Web dans le même langage de modélisation, c'est à dire dans le DSL S-GNet. Le troisième avantage est que dans notre méthodologie, le service composite est vérifié au moment de la conception c'est à dire avant toute mise en œuvre. Grâce à la base formelle du langage de modélisation S-GNet, nous exploitons l outil de vérification PROD afin d'effectuer une vérification automatique des propriétés de comportement souhaitées. 70

91 Chapitre 3 : L approche WS-mcv 71 Figure 3.6 Les principales étapes de l approche WS-mcv Dans les sous sections suivantes, nous allons présenter brièvement chaque étape de notre méthodologie. Cette présentation va permettre au lecteur d avoir une idée globale de l approche de composition mise en œuvre. Les étapes seront par la suite présentées dans le détail dans les chapitres 4 et Phase de sélection L'objectif de la phase de la découverte et de la sélection est d'identifier les services Web requis pour la composition et de fournir les informations permettant de les inclure dans un scénario de composition. L'idée est qu'un certain nombre de services Web peut répondre à certaines exigences de base spécifiées par un client. Ensuite, le client doit être assisté dans le choix de l'un des services qui répond le mieux à ses exigences. La sélection peut être automatique selon un ensemble de critères choisis, ou laissée à la discrétion du développeur. Le développeur consulte un annuaire de services tels que l'annuaire UDDI [UDDI] pour sélectionner les services requis. Ce répertoire est utilisé pour découvrir les services qui fournissent les fonctionnalités nécessaires et importer les descriptions WSDL des services Web souhaitées à partir du Registre. Dans le fichier WSDL, XML est utilisé pour exprimer des informations telles que le nom du service, ses méthodes et les types complexes impliqués. Nous précisons que notre approche ne traite pas du problème de la découverte et de la sélection des services mais prend place à la fin de cette opération en offrant la possibilité de composer les services sélectionnés d une manière adéquate Phase d extraction des interfaces de services Une fois que les services sélectionnés, la deuxième étape consiste à extraire les interfaces S-GNet des descriptions WSDL correspondant aux services sélectionnés. Cette étape permet de représenter les informations pertinentes concernant les services Web d une manière plus conviviale. Nous utilisons le même langage (S-GNet) pour représenter les interfaces des services participants et leur composition. Pour cette tâche, nous avons défini un ensemble de règles pour transformer les descriptions WSDL

92 Chapitre 3 : L approche WS-mcv (méthodes, messages, types de données) en des interfaces S-GNet. Nous abordons la phase de d extraction en proposant un ensemble de règles de transformation des descriptions WSDL en leurs spécifications S-GNets équivalentes. Cet ensemble de règles de transformation de modèles permet la rétro-ingénierie de ces documents WSDL en se basant sur les informations incluses dans le document en question. Une fois les services intervenants modélisés avec le formalisme S-GNet, il devient aisé de concevoir la composition de ces services. Cette phase est réalisée par le processus d extraction des services Web intervenants qui sera entièrement décrit dans le chapitre suivant Phase de spécification du modèle de composition La troisième étape correspond à la construction du modèle de composition abstrait qui spécifie le comportement du service composite. Le comportement du service composite est modélisé par les interactions des services participant dans le scénario de composition. Pour simplifier le processus de modélisation, nous avons étendu le formalisme G- Net pour modéliser non seulement les interfaces de services, mais aussi les interactions entre les services dans un Workflow. Le langage S-GNet permet au développeur d'obtenir des modèles lisibles et indépendants de l'implémentation qui améliorent la compréhension de la composition. Les principaux concepts du langage S-GNet et ses nombreux avantages pour la composition de services seront détaillés dans la section suivante. La phase de composition considère en entrée les spécifications S-GNet représentant les services à composer, ainsi qu une formule de composition représentant un scénario de composition bien défini et génère le modèle d un nouveau service à valeur ajoutée sous forme d un S-GNet. Pour effectuer cette opération, nous proposons une algèbre basée sur les S-GNets. Cette algèbre offre un ensemble représentatif d'opérateurs qui peuvent être appliqués pour les services S-GNets. Ces opérateurs reflètent toutes les structures de contrôle proposées par les langages actuels de composition comme BPEL. La formule de composition fournie en entrée est en fait une expression algébrique où les opérandes sont les services manipulés et les opérateurs sont des opérations de manipulation de graphes exécutées sur ces services. Pour mettre en œuvre l algèbre basée S-GNet proposée, nous utilisons les techniques de méta-modélisation et de transformation de modèles. Etant donné que les modèles manipulés sont des graphes (un type de RdP), la transformation de modèles est mise en œuvre par une transformation de graphes. Le processus de spécification complet réalisant cette phase est présenté en détail dans le chapitre suivant Phase de vérification du modèle de composition La quatrième étape est consacrée à la validation du modèle de composition. Cette étape est particulièrement importante, car elle est considérée comme l'instrument clé pour le développement de systèmes logiciels corrects. S-GNets étant un langage de spécification formelle, des outils de validation formelle peuvent être développés pour effectuer la vérification automatique de propriétés comportementales du modèle de composition. 72

93 Chapitre 3 : L approche WS-mcv Le fait de raisonner sur des modèles nous permet de vérifier sur une maquette numérique (les modèles) un ensemble de propriétés que l on devait vérifier sur le système final. L'un des apports supplémentaires du travail sur maquette numérique en lieu et place du traditionnel code logiciel est par ailleurs de fournir un référentiel central pour l'étude des différentes problématiques d un système permettant à différents acteurs de s'intéresser aux différents aspects du système (sécurité, performance, consommation...). Certaines des approches traditionnelles de composition de services Web ne permettent pas d'accomplir la vérification du service résultant. Ce faisant, il devient difficile de localiser les erreurs potentielles relatives aux services composants comme les incohérences au sein du service. Contrairement aux autres approches, WS-mcv permet de détecter la présence d anomalies au sein du service composite. Il est plus pratique de détecter et de corriger d'éventuelles erreurs le plus tôt possible. La phase de vérification est appliquée sur le modèle de composition afin de vérifier la conformité de la composition résultante, à savoir si l'intégration des services partenaires s exécute correctement. Dans le cas où des erreurs sont détectées, des raffinements sont opérés sur le modèle de composition et la vérification répétée jusqu'à obtention d un modèle valide. La vérification constitue généralement une tâche qui est automatisée grâce aux nombreux outils logiciels existants pour les méthodes formelles. Etant donné que l on ne dispose pas d outils de vérification pour le formalisme S-GNet, nous effectuons le passage vers le formalisme prédicat-transition (PrT-Nets) [Genrich et al., 1981]. Ce passage est aussi réalisé dans WS-mcv, par une technique de transformation de graphe. Cette transformation est effectuée afin d exploiter les outils de vérification existants avec une variété de techniques d analyse pour les réseaux PrT-Nets comme l outil PROD [PROD]. La méthode suivie pour réaliser la vérification des modèles de services Web composés sera exposée en détail au niveau du chapitre Phase d implémentation Comme, indiqué précédemment, l approche WS-mcv permet de développer les services Web composites selon les principes de l IDM. Ceci signifie que les modèles S- GNets peuvent être convertis en un code exécutable de bas niveau par le biais de règles de transformation. La dernière étape de notre méthodologie prend en entrée le modèle de composition vérifié et génère le code BPEL exécutable correspondant. Pour effectuer cette tâche, les règles nécessaires pour générer du code BPEL à partir de modèles S-GNet sont fournies. Etant donné que le formalisme S-GNet est bien adapté à la composition des services Web, le code généré est suffisamment précis pour fournir la structure globale du code ainsi que quelques détails du code. Le développeur devra alors éditer le reste des détails de mise en œuvre. Le langage BPEL est conçu comme une notation pour définir des processus exécutables, autrement dit, des processus qui peuvent être chargés dans un moteur d'exécution qui pourra ensuite coordonner les activités précisées dans les définitions du processus. Afin que le processus de composition soit complet, WS-mcv propose des 73

94 Chapitre 3 : L approche WS-mcv transformations à partir des spécifications S-GNets vers des définitions de processus BPEL. Ces transformations se révèlent être assez complexes en raison des différences inhérentes entre ces deux langages : les modèles S-GNets sont orientés graphe alors que les définitions de processus BPEL ont plutôt une structure de blocs. Pour permettre la génération de code BPEL à partir des spécifications S-GNets, nous avons mis au point un ensemble de règles de transformation de modèle de type model-to-text. Le processus complet réalisant la génération du code ainsi que les règles de transformation seront présentés en détail dans le chapitre 5. Le service composite obtenu, une fois validé et implémenté peut faire l objet d une future réutilisation et ce en publiant sa description WSDL dans un annuaire de services public comme UDDI par exemple. 5. Conclusion Dans ce chapitre, nous avons introduit la méthodologie WS-mcv que nous proposons pour réaliser la composition des services Web. Cette approche, comme nous l avons vu, est entièrement basée sur les principes de l IDM. De plus, elle permet d assister le concepteur lors du développement d un service composite dans toutes les étapes. Pour la spécification de la composition, le développeur doit travailler avec des modèles de haut niveau afin de faire abstraction de tout détail d implémentation. Nous avons donc proposé le modèle abstrait S-GNet comme formalisme de représentation de la composition des services. Ce modèle représente une extension des G-Nets adaptée aux services Web. Les S-GNets peuvent être utilisés dans les premières étapes de développement pour aider à l extraction des interfaces des services Web. Le méta-modèle des S-GNets que nous offrons renferme tous les concepts de modélisation nécessaires à la spécification des services Web. Pour le développeur, la tâche de composition est simplifiée, puisqu elle se base sur la rétro-ingénierie, la transformation de modèles, et la génération de code qui sont complètement automatisées. La rétro-ingénierie est utilisée pour transformer les documents WSDL en interfaces S-GNets. La transformation de graphes est utilisée pour spécifier la composition des services en S-GNets et pour la vérification formelle de la composition. La génération de code est utilisée pour générer du code à partir des spécifications S-GNets des services composites pour permettre leur implémentation en BPEL. La description WSDL du service obtenu peut alors être aisément extraite à partir de ces mêmes spécifications pour permettre la publication du service résultant de la composition. 74

95 Chapitre 4 Extraction des Interfaces et Spécification de la Composition des Services Web

96

97 Chapitre 4 : Extraction et Spécification de la Composition Chapitre 4 Extraction des Interfaces et Spécification de la Composition des Services Web 1. Introduction Dans le chapitre précédent, nous avons présenté un aperçu général de la méthodologie WS-mcv ainsi que le DSL que nous avons proposé pour mener à bien les différentes phases de notre approche. Le but de ce chapitre est de détailler deux phases de notre approche qui sont : 1) La phase d extraction des interfaces des services intervenants et 2) La phase de spécification de la composition de ces services. Ces deux phases sont réalisées en suivant les principes phares de l IDM qui sont la méta-modélisation et la transformation de modèles. Le méta-modèle du formalisme S-GNet que nous avons élaboré dans le chapitre précédant est utilisé pour générer un outil de modélisation dédié au S-GNets. La phase d extraction des interfaces des services permet d obtenir des représentations en S-GNets des services Web participants dans le processus de composition. Ceci est accompli à partir de leur description dans le langage standard WSDL. Jusqu à présent, nous avons défini la notion de service S-GNet d une manière informelle. Avant d entamer cette phase d extraction, nous proposons de donner quelques définitions formelles sur les notions de service S-GNet et de service Web. Ces définitions ont pour but de lever toute ambiguïté sur l extraction et d aider les concepteurs à appréhender la description et le comportement des services Web. Nous présentons ensuite une grammaire de graphes mettant en œuvre par un ensemble de règles la transformation de descriptions WSDL en une représentation S-GNet équivalente. Cette phase de l approche rentre dans le cadre d un type spécifique de transformation de modèles qui est la rétro-ingénierie. Cette transformation de description textuelle en un modèle visuel permettra de faciliter la compréhension du mode de fonctionnement des services Web impliqués dans la composition. Afin d illustrer la méthode proposée, nous présentons une étude de cas ainsi que l implémentation des différentes règles de transformation au sein de l environnement de modélisation que nous avons généré. La phase de modélisation des composition des services permet quant à elle d obtenir un modèle de service Web composé en ayant comme entrée les modèles S-GNet des services intervenants dans la composition ainsi qu une formule de composition appartenant à une algèbre manipulant des S-GNets. L algèbre proposée supporte des opérateurs de base et d autres plus élaborés. Tous les opérateurs de l algèbre sont syntaxiquement et sémantiquement définis en termes de S-GNets. Cette phase est réalisée par une transformation de graphe de type endogène. Cette transformation est aussi utilisée pour spécifier les règles de transformation qui sont en fait des règles de correspondance entre différentes parties de S-GNets. Nous commençons par présenter dans la section 2 les étapes qui nous ont menées à la génération d un environnement de modélisation dédié aux S-GNets. La section 3 introduit la technique de transformation des descriptions WSDL en interfaces S-GNet que 75

98 Chapitre 4 : Extraction et Spécification de la Composition nous avons proposé ainsi que la grammaire de graphe mettant en œuvre la transformation. Dans la section 4, nous abordons la phase la plus importante de notre approche qui est la phase de composition. Nous y présentons l algèbre basée S-GNet pour la composition ainsi que la grammaire de graphes mettant en œuvre l ensemble de ses opérateurs. Nous terminons par une conclusion dans la section Méta-modélisation du Formalisme S-GNet avec AToM 3 Les environnements de modélisation (DSLs) basés sur la méta-modélisation sont utilisés pour vérifier si un modèle donné est bien spécifié dans un langage donné L. Cette vérification est faite au moyen du méta-modèle du langage L. Les DSLs sont aussi utilisés pour contraindre le concepteur (au cours de la construction du modèle) à n utiliser que les éléments du langage L en question. À partir du méta-modèle d un langage, un environnement de modélisation peut être généré de façon automatique. La flexibilité de cette approche a un impact considérable: de nouveaux langages peuvent être conçus en modifiant simplement les parties d'un méta-modèle déjà défini. Comme cette modification est explicitement appliquée au modèle, la relation entre les différentes variantes d'un langage de modélisation est apparente. Au-delà de ces implications, il apparait qu avec un outil de méta-modélisation approprié, la modification d'un méta-modèle et la génération d un outil de modélisation visuelle est beaucoup plus rapide que le développement d'un tel outil à la main. Ces concepts de la méta-modélisation sont offerts par l outil AToM 3. Les formalismes et les modèles dans AToM 3 sont décrits graphiquement. À partir d une métaspécification d un formalisme, AToM 3 génère un outil pour manipuler visuellement (créer et modifier) les modèles décrits dans le formalisme spécifié. Les utilisateurs d AToM 3 ont le choix entre différents méta-formalismes pour décrire leurs méta-modèles comme par exemple le diagramme entité-relation ou le diagramme de classes. Dans notre approche, nous utilisons le méta-formalisme diagramme de classes qui nous permet de décrire le méta-modèle des S-GNets à l aide de classes et de relations entre elles. Ce méta-formalisme permet aussi de spécifier et de manipuler des propriétés aussi variées que les contraintes, les actions, les cardinalités et les apparences de chaque classe et association du méta-modèle. Dans le contexte de notre travail, nous faisons usage du méta-modèle des S-GNets que nous avons défini dans le chapitre précédent. Afin d'assurer une apparence et une structuration conformes aux modèles S-GNets, nous avons associé aux éléments de modélisation du méta-modèle S-GNet des contraintes. Ces contraintes sont aussi bien de nature graphique que structurelle. Les contraintes graphiques se réfèrent à l apparence visuelle des éléments, alors que les contraintes structurelles se réfèrent à la structure des modèles. Un exemple de contrainte graphique que nous avons défini est qu une place est représentée par un cercle portant un nom et qu une transition est représentée par un rectangle nommé. Un exemple de contrainte structurelle est qu un arc peut uniquement relier une place à une transition ou une transition à une place mais ne peut relier deux 76

99 Chapitre 4 : Extraction et Spécification de la Composition places ou deux transitions entre elles. Certaines contraintes sont spécifiées dans AToM 3, lors de la création du méta-modèle, en code python. La figure 4.1 illustre les différentes étapes qui nous ont permis d obtenir un environnement de modélisation pour les S-GNets. La première étape consiste à charger de méta-modèle Diagramme de Classe au sein d AToM 3. Ce méta-modèle modèle est disponible dans le répertoire des formalismes principaux d AToM 3. Ceci va nous permettre de réaliser la tâche de méta-modélisation, en d autres termes, de décrire le formalisme S- GNet utilisé pour modéliser des services Web. Dans la deuxième étape, nous avons spécifié au sein de l interface visuelle les différentes classes et associations constituant le méta-modèle S-GNet présenté dans le chapitre précédent. A chaque classe du méta-modèle, modèle, nous associons une apparence graphique spécifique. Après la sauvegarde du méta-modèle, AToM 3 génère l outil de modélisation pour les S-GNets. Il associe à chaque classe un bouton dans l outil de modélisation généré. L ensemble de ces boutons est spécifié au sein d AToM 3 sous forme d un modèle appelé modèle de boutons (Buttons model). Etant donné que nous avons besoin de boutons supplémentaires au sein de l outil, comme par exemple de boutons pour l exécution des grammaires de graphes, nous devons spécifier manuellement chaque bouton supplémentaire nécessaire ainsi que l action associée à celui-ci. Pour ce faire, nous accédons à travers l interface d AToM 3 au modèle de boutons de notre outil et nous définissons les boutons supplémentaires. Le méta-modèle modèle pour les S-GNets que nous avons défini contient cinq classes et six associations. L environnement de modélisation Diagramme de Classe d AToM 3 permet aisément de spécifier visuellement les différentes classes et les associations. Ceci par le biais de l interface utilisateur de l environnement. La partie supérieure de la figure 4.2 montre le méta-modèle modèle S-GNet édité au sein de l outil AToM 3. Dans le coin supérieur gauche de la fenêtre principale, nous remarquons que le formalisme diagramme de classes est utilisé pour modéliser le formalisme S-GNet. La partie inférieure présente l environnement de modélisation pour les S-GNets généré à partir du méta-modèle. Les boutons que nous avons manuellement définis sont aussi visibles. Figure 4.1 Elaboration de l outil de modélisation S-GNets sous AToM 3 77

100 Chapitre 4 : Extraction et Spécification de la Composition 78 Figure 4.2 Outil de modélisation S-GNets généré avec AToM 3 Après la compilation du méta-modèle S-GNet, seuls les modèles syntaxiquement corrects décrits dans ce formalisme seront acceptés. Une fois l'outil généré selon le métamodèle, les boutons de l'interface utilisateur permettent au concepteur d éditer des modèles conformes au formalisme S-GNet. La figure 4.3 illustre un modèle S-GNet édité au sein de notre outil de modélisation S-GNet. 3. Phase d extraction des interfaces des services Web intervenants Une description WSDL d un service Web donné représente la partie publique du service et constitue la seule information publique disponible pour un service donné. Elle regroupe le consensus sur la mécanique des interactions (opérations offertes, format des messages échangés, types des données et protocoles d échanges) concernant le service. Comme présenté dans le chapitre 1, une description WSDL se présente sous forme textuelle avec une structure typée XML. C est cette caractéristique fondamentale de la technologie des services Web qui permet aux différentes descriptions de services d être facilement traitées par une machine. Le concepteur de compositions de services Web doit s appuyer sur ces descriptions afin de spécifier le rôle de chaque opération au sein du Workflow de composition.

101 Chapitre 4 : Extraction et Spécification de la Composition Figure 4.3 Edition de modèles S-GNet au sein du DSL Cependant, du fait de la forme textuelle et de l absence de sémantique concrète de WSDL, Il est évident que la compréhension du mode de fonctionnement des services décrits soit fastidieuse pour l œil du concepteur. Afin de représenter les interfaces des services Web d une manière plus claire, notre approche fournit le moyen d obtenir automatiquement une représentation d un service Web élémentaire dans le formalisme S- GNet à partir de sa description WSDL. Chaque service intervenant dans la composition sera représenté par un S-GNet dont seule la partie interface (ou GSP) est renseignée. Ainsi, nous contribuons à faciliter la compréhension du fonctionnement externe des services intervenants dans une composition de services Web et nous mettons un cadre formel aux descriptions de ces derniers. Nous proposons donc une technique de transformation de modèles de type text-tomodel. Cette méthode de transformation [Bachtarzi et al., 2013] est illustrée d une façon générale par la figure 4.4. La partie supérieure de la figure présente les différentes parties d un document WSDL. Pour plus de clarté, nous avons simplifié le document WSDL en omettant quelques éléments et attributs. Nous avons également supprimé toutes les informations d'espace de noms XML. La partie inférieure de la figure présente les éléments S-GNets correspondants. Le lecteur peut noter la présence de la table de triplets qui contient la structure des messages d'entrée et de sortie. Elle contient également la définition des types de données complexes. 79

102 Chapitre 4 : Extraction et Spécification de la Composition Figure 4.4 Méthode de transformation de WSDL vers les S-GNets Dans ce qui suit, nous définissons d une manière informelle les règles de passage entre les éléments d un document WSDL et ceux du formalisme S-GNet. (1) A chaque fichier WSDL décrivant un service Web correspond un S-GNet. (2) Le nom du S-GNet modélisant un service Web correspond au nom du service Web défini dans sa description WSDL. (3) La GSP du S-GNet représentant le service Web est construite comme suit : L ensemble des PortType contenus dans le fichier WSDL correspondent à l OGS. A chaque porttype défini dans le fichier WSDL correspond un OGName. Dans le cas où il y a plus d un porttype dans le document WSDL, ils seront définis de la même manière et intégrés dans la GSP. Les opérations définies dans le fichier WSDL sont groupées dans l OGName correspondant. Pour chaque opération, les messages d entrée et de sortie sont spécifiés comme suit : Opi (Ii, Oi) pour i=1,n. La partie binding (correspondance entre un porttype et le protocole utilisé) est transformée en CPS. Le protocole associé à un porttype donné correspond à un Ptcol. (4) Les messages d entrée et de sortie définis dans la partie types du document WSDL sont intégrés dans La table de triplets associée au S-GNet Formalisation Jusqu à présent, nous avons défini la notion d un service S-GNet de façon informelle. Dans ce qui suit, nous donnons quelques définitions formelles à propos da la notion d un S-GNet et celle d un service Web. Ces définitions ont pour but de réduire l ambigüité de la spécification et d aider le concepteur à appréhender la modélisation d un service Web. 80

103 Chapitre 4 : Extraction et Spécification de la Composition Définition 1. (S-GNet) Un S-GNet G est un triplet G (GSP, IS, DM) où: GSP: est une place spéciale représentant l abstraction du service. IS: est la structure interne du service, un réseau de Pétri modifié. DM: est le module de données représentant la structure des messages et les définitions des types de données complexes. Définition 2. (GSP) La GSP d un S-GNet G est un couple GSP=<OGS, CPS> où : OGS= {<OGName: op1(i,o), op2(i,o), >} (pour Operation Group Set) est l ensemble de toutes les opérations offertes par le S-GNet où : OGName: est le nom d un groupe d opérations de l OGS. Opi(Ii,Oi,): est le nom d une opération disponible dans l OGS. Ii et Oi sont ses messages input et output. Le type et la structure des messages d input et output sont dans la table associée au S-GNet. Ces messages seront intégrés dans les champs message du S-GNet. CPS= {<OGName, Protocol>, } (pour Corresponding Protocol Set) est l ensemble de toutes les correspondances entre OGS et les protocoles utilisés pour leur invocation où : Protocol: est le nom du protocole associé à un OGS donné. Définition 3. (IS) L IS d un S-GNet G est le tuple IS =<P,T,W,L> où: P = NP ISP GP AP RP est un ensemble fini et non vide de places où: NP: est l ensemble des places normales dénotées par des cercles. ISP: est l ensemble des places ISP dénotées par des ellipses et utilisées pour interconnecter les S-GNets. GP: est l ensemble des places Goal dénotées par des doubles cercles utilisées pour représenter les états finaux d exécution des méthodes. AP: est l ensemble des places Assign. RP: est l ensemble des places Receive. T: est l ensemble des transitions. W: est l ensemble des arcs orientés W (P T) (T P) (la relation de flow). L : P O {τ} est la fonction d étiquetage où O est le nom d une opération et τ est l opération silencieuse. Définition 4. (DM). Un module de données (data module) DM d un S-GNet est le triplet DM = {<MName/CTName, PName, Type>} où: MName/CTName: est soit le nom d un message input / output ou le nom d un type de données complexe. PName: est soit le nom d un message ou le nom d un élément d un type de données complexe. Type: est soit un des types XSD (integer, string, etc..) ou le nom d un type complexe (composé de plusieurs types XSD). Définition 5. (Service Web) Un service Web est un tuple S = (NameS,Desc,Loc,URL,CS, SGN) dans lequel: NameS est le nom du service utilisé comme son identifiant unique. Desc est la description du service fourni. Elle résume les fonctionnalités offertes par le service. Cette description informelle est extraite du document WSDL. 81

104 Chapitre 4 : Extraction et Spécification de la Composition Loc désigne le serveur où le service est localisé. La localisation est aussi définie dans le document WSDL. URL est l invocation du service Web. CS est l ensemble des services composants du service Web. Si CS = NameS alors S est un service de base, sinon S est un service composite. SGN = (GSP, IS, DM) est le S-GNet modélisant le service Web Transformation WSDL vers S-GNet Dans le but de permettre la transformation d un document WSDL en un S-GNet, nous proposons d adopter une technique de transformation de modèle de type texte-versmodèle (text-to-model). Ce type de transformation à lieu lorsqu il s agit de transformer des chaines ou des fichiers texte en des modèles. Pour établir ce type de transformation, il faut mettre au point une grammaire de graphes annotée qui spécifie comment les chaines sont analysées et quel élément de modélisation correspond à chaque partie du langage. Ce procédé s inscrit dans le cadre de la rétro-ingénierie. Dans ce qui suit, nous proposons de présenter la grammaire de graphes que nous avons définie et qui permet la transformation d une description WSDL en une interface S- GNet équivalente. La grammaire, présentée dans la figure 4.5, comprend cinq règles qui sont exécutées selon un ordre de priorité défini. Notons que l ordre de priorité a été choisi de façon à ce que la génération du S-GNet soit réalisée d une manière cohérente. Nous avons vu que dans les S-GNets des fragments sont considérés comme des contenants (comme la GSP et l IS) et d autres comme des contenus (comme les places et les transitions). Par conséquent, lors de l élaboration des règles de spécification, nous avons pris soin de toujours produire les contenants avant leurs contenus. Par exemple la règle 1 génère la GSP et la règle 2 spécifie son contenu. Etant donné que la grammaire a pour objectif la rétro-ingénierie de documents WSDL en spécifications S-GNets, l application des règles de cette grammaire va aboutir à la génération de modèles S-GNets de services Web. Par conséquent, les parties droites et gauches de toutes les règles contiennent des fragments de graphes S-GNets. Le code WSDL correspondant aux services Web n est pas visible au sein des règles. L action initiale de notre grammaire de graphes consiste à sélectionner un fichier qui contient une description d un service Web dans le langage WSDL. La figure 4.5 illustre les différentes règles de la grammaire sous forme de LHS, RHS. Notre grammaire utilise des variables temporaires pour spécifier les différentes conditions de règles ainsi que pour stocker temporairement certaines informations concernant la transformation. La variable GEN_SGNet stocke le nom du service Web pour lequel un S-GNet est en cours de génération. Ceci va permettre d appliquer les règles uniquement sur le S-GNet souhaité. Les identifiants List_mtd et List_binding désignent respectivement deux listes de noms de porttypes et de bindings utilisés pour élaborer les GSP du S-GNet en cours de génération conformément aux règles de spécification que nous avons définies précédemment. List_triple est une liste de triplets utilisée pour contenir les triplets de la table de données associée à un S-GNet dont nous avons défini la structure auparavant. 82

105 Chapitre 4 : Extraction et Spécification de la Composition Figure 4.5 Règles de transformation de WSDL vers S-GNet 83

106 Chapitre 4 : Extraction et Spécification de la Composition Règle N 1: (Priorité 1) Cette règle est appliquée pour générer une GSP correspondant à une description WSDL donnée. Elle récupère le nom du service à partir de sa description WSDL et l affecte au nom du S-GNet correspondant. Le nom du S-GNet est affecté à la variable GEN_SGNet pour spécifier le service S-GNet en cours de génération. Cette information sera utile lors de la phase de matching (égalisation) pendant l application de la grammaire. Règle N 2: (Priorité 2) Cette règle est utilisée pour élaborer le contenu de la GSP du S-GNet. Après avoir récupéré les porttypes et les bindings du fichier WSDL, cette règle affecte le contenu des variables temporaires List_mtd et List_binding aux attributs OGS et CPS. Le traitement associé à cette action pourra être réalisé d une façon effective dans un environnement bien défini. Lors de la phase de matching de la partie gauche de cette règle, la variable GEN_SGNet est utilisée pour détecter le S-GNet en cours de génération. La condition stipule aussi que les deux attributs OGS et CPS de la GSP doivent être vides pour pouvoir les générer. Règle N 3: (Priorité 3) Pour le S-GNet en cours de génération, la règle N 3 génère la partie IS correspondante. Cette règle est appliquée après que la partie GSP ait été générée. Un lien est établi entre la GSP et l IS du S-GNet en cours de génération. Lors de la phase de matching de la partie gauche de cette règle, plusieurs conditions sont nécessaires à son application. Une des conditions est celle qui stipule que le S-GNet traité est bien celui en cours de génération. Une autre condition vérifie que L IS n a pas encore été générée pour ce S-GNet. Règle N 4: (Priorité 4) Cette règle permet de créer la table de données correspondant au S-GNet en cours de génération. Elle permet aussi de récupérer les déclarations contenues dans la partie Types du fichier WSDL et de les structurer sous forme de liste qui sera stockée au sein de la variable globale List_triple. La condition de la règle vérifie que pour le S-GNet en cours de traitement, aucune table de données n a été générée. La règle spécifie également le lien entre le S-GNet et sa table de données. Règle N 5: (Priorité 5) La dernière règle de notre grammaire effectue le remplissage de la table de données. Elle s exécute plusieurs fois jusqu'à l intégration de tous les triplets dans la table Exemple Dans cette section, nous illustrons à travers un exemple la méthode de transformation proposée pour la représentation des descriptions WSDL dans le formalisme S-GNet. L'exemple consiste en deux services Web. Le premier est un service de réservation spécifique à un hôtel appelé BookingHotel. Et le deuxième est un service Web de réservation de places de bus nommé BusTiketService. Pour interagir avec le service BookingHotel, l'utilisateur doit invoquer l opération makenewbooking avec son 84

107 Chapitre 4 : Extraction et Spécification de la Composition message d'entrée contenant les informations client (prénom et nom). Le service fait la réservation et envoie la confirmation à l'utilisateur. La partie droite de la figure 4.6 représente la description en S-GNet du service BookingHotel. La partie gauche quant à elle illustre la description WSDL du même service Web. Le service Web définit un porttype appelé BookingPortType qui contient l opération du service (makenewbooking). Cette dernière possède un message d'entrée infobooking et un message de sortie bookingresponse. Le message d'entrée infobooking définit deux parties, la première partie appelée customerinfo utilise l'élément customer comme type de données. customer est un type de données complexe défini dans la partie Types de la description du service. Notons que le S-GNet a le même nom que le service défini dans la description WSDL. La partie IS du S-GNet généré est vide. Ceci est dû au fait que ce S-GNet représente un service Web qui va intervenir dans une composition et non pas un service composé. Dans la section suivante, nous verrons qu un réseau de Petri sera intégré au S- GNet qui modélisera la composition des services intervenants. Les structures des messages échangés par les services et la définition des types de données sont représentées par la table associée au S-GNet. La première colonne de la table contient les noms des messages alors que la deuxième et la troisième colonne représentent respectivement la partie correspondante du message et son type. Le caractère spécial «#» avant le nom du type de la partie indique que c'est un type complexe. La définition du type complexe est ensuite exprimée dans les lignes subséquentes de la table. De la même manière, la figure 4.7 représente la description WSDL ainsi que la représentation en S-GNet du service Web BusTiketService. Ces deux exemples de représentation de service Web en S-GNet seront repris dans la suite de ce chapitre afin d illustrer les autres phases de notre méthodologie de composition des services Web. Figure 4.6 Description WSDL du service BookingHotel et sa spécification S-GNet équivalente 85

108 Chapitre 4 : Extraction et Spécification de la Composition Figure 4.7 Description WSDL du service BusTiketService et sa spécification S-GNet équivalente 3.4. Mise en œuvre Pour mettre en œuvre le processus de spécification des services Web intervenants, nous exploitons les puissantes fonctionnalités de l outil AToM 3. C est au sein de cet environnement que nous avons implémenté les différentes règles de transformation pour la spécification de services Web à partir des descriptions WSDL présentées ci-dessus [Bachtarzi & Chaoui, 2014]. Nous avons intégré la grammaire de graphe au sein de l outil de modélisation des S-GNets que nous avons généré grâce à AToM 3. Comme nous l avons vu, chaque partie LHS et RHS des règles est un sous graphe du formalisme S-GNet. Lors de la définition de cette grammaire de graphe en utilisant AToM 3 nous avons suivi les étapes suivantes : 1- Charger le méta-modèle S-GNet défini précédemment 2- Définir les règles de la grammaire 3- Générer le fichier exécutable de la grammaire L éditeur de grammaire d AToM 3 permet l édition, la génération et l exécution de la grammaire. Il donne accès à l éditeur de règles qui permet l édition des différentes parties (LHS, RHS) de la règle ainsi que la condition et l action de chaque règle. Les conditions sont du code Python qui doit être vérifié avant l exécution de la règle. Les actions associées à chaque règle sont aussi du code Python mais qui est exécuté une fois que la règle est appliquée. La figure 4.8 illustre l édition de la première règle dans l éditeur de règles d AToM 3. Le lecteur peut voir les parties gauche et droite de la règle. La case «Action» est activée (dans la partie supérieure de la figure) ce qui signifie que le code Python qui spécifie l action associée à la règle peut être édité. 86

109 Chapitre 4 : Extraction et Spécification de la Composition Figure 4.8 La règle 1 de transformation WSDL vers S-GNet dans l éditeur de règles d AToM 3 Les autres règles de la grammaire sont éditées de la même manière. Une fois toutes les règles définies, le code exécutable de la grammaire est généré. Le concepteur peut ensuite appliquer la grammaire de graphes définie ci-dessus pour obtenir un modèle de service Web à partir d un fichier WSDL contenant sa description. On peut voir dans la figure 4.9 la description WSDL complète du service Web BookingHotel. C est à partir de cette description qu a été généré le modèle S-GNet équivalent illustré par la figure Les services S-GNets créés peuvent être stockés et édités en vue d être consultés ou modifiés. Figure 4.9 Description WSDL du service Web BookingHotel 87

110 Chapitre 4 : Extraction et Spécification de la Composition Figure 4.10 La spécification S-GNet du service BookingHotel obtenu avec notre l outil généré 4. Phase de spécification du modèle de la composition L étude et la synthèse de l état de l art que nous avons menée nous ont montré que la puissance d expression d un modèle de composition dépend, en grande partie, de l outil formel utilisé pour définir la composition de services Web. L avantage majeur du formalisme S-GNet est qu il est parfaitement adapté non seulement pour modéliser les interfaces des services Web, mais aussi pour représenter une composition de services Web à partir d un scénario de composition. Nous l utilisons donc pour spécifier le comportement de la composition à travers un ensemble d appels à d autres services. Avec ce formalisme, une invocation de service se résume à la spécification de son nom et de la méthode souhaitée au sein d une place ISP. Pour modéliser la composition, le développeur doit définir un nom pour le nouveau service Web composite. Celui-ci sera utilisé lors de son invocation à travers une ISP par d éventuels utilisateurs. L interface de celui-ci contiendra les nouvelles opérations. Pour chacune des opérations identifiées dans le scénario de composition, le comportement est spécifié en capturant son flux de contrôle et son flux de données. Dans le contexte de notre travail, le modèle de composition est réalisé par un ensemble d activités élémentaires (ou opérations atomiques). Chaque type d opération est modélisé par un type de places spécifique : - Call : est un appel à une opération d un S-GNet via une ISP. Cette opération est représentée par une place ISP contenant le nom du S-GNet à invoquer ainsi que le nom d une des opérations qu il fournit. 88

111 Chapitre 4 : Extraction et Spécification de la Composition - Empty : est une opération vide qui permet d'insérer une instruction de nontraitement dans un processus. Cette opération est utile lors de l utilisation d une activité qui ne fait rien. Elle est représentée par une place de type normal. - Assign : est une opération de manipulation de données qui réalise la copie du contenu d'une variable dans une autre. Cette opération est représentée par une place de type Assign. - Receive : est une opération qui permet au concepteur de spécifier une réception de requête. Cette opération est représentée par une place de type Receive. - Reply : est une opération qui permet au concepteur de spécifier une fin d exécution d une opération et l envoi du résultat au client du service. Cette opération est représentée par une place de type Goal. Afin que le concepteur puisse définir quelles opérations doivent être exécutées dans le modèle de composition, ainsi que leur ordre d exécution, nous avons défini un certain nombre d opérateurs qui manipulent des opérations de base et des constructions S-GNet (ensemble d opérations de base). Ces opérateurs reflètent toutes les structures de contrôle offertes par le langage standard de composition des services Web BPEL. Ces constructeurs forment une algèbre de composition des services Web [Bachtarzi et al., 2011] qui combine les opérations élémentaires définies ci-dessus pour construire de nouveaux modèles de services composés. L ensemble représentatif des opérateurs que nous avons définis est : Sequence, Parallel/Synchronization, Alternative/Merge, Iteration et Arbitrary-Sequence. Dans ce qui suit, nous donnons en premier lieu une définition informelle de chaque opérateur, puis nous donnons sa sémantique formelle en termes de S-GNets accompagnée de sa représentation graphique Opérateurs de composition La notation BNF ci-dessous décrit une grammaire qui définit l ensemble des constructions permettant de représenter une structure interne (IS) des S-GNets modélisant un service composé. OP ::= Empty Call Assign Receive Reply (OP OP) (OP//OP) (OP OP) ( OP) (OP OP) Dans cette grammaire, les notations utilisées désignent: Empty est l opération nulle, i.e. une opération qui n exécute aucun traitement. Elle est utilisée pour des raisons techniques et théoriques. Elle est formellement représentée par une place de type Empty. Call représente l opération d invocation d une opération d un S-GNet. Elle est formellement représentée par une place ISP. Assign désigne l opération d affectation. L opération est formellement représentée par une place de type Assign. Receive désigne l opération de réception de requête. L opération est formellement représentée par une place de type Receive. 89

112 Chapitre 4 : Extraction et Spécification de la Composition Reply désigne l opération de réponse à une requête. L opération est formellement représentée par une place de type Goal. OP est soit une opération de base, soit une construction manipulant des opérations de base. OP OP représente une construction exécutant une opération élémentaire suivie immédiatement par une autre, i.e. est un opérateur de séquence. OP//OP représente une construction exécutant deux opérations en même temps et indépendamment l une de l autre. La construction résultante attend la fin d exécution des deux opérations. // est donc un opérateur parallèle avec synchronisation. OP OP représente une construction composite pouvant reproduire le comportement de l une des deux opérations mais pas les deux, i.e. est un opérateur alternative qui joint les deux branches sans synchronisation. OP représente une construction composite où une opération est successivement exécutée plusieurs fois. est donc un opérateur de boucle structuré. OP OP est une construction exécutant une séquence arbitraire des opérations intervenant dans la construction, i.e. est un opérateur de séquence arbitraire. Dans l algèbre que nous avons proposée, les constructions résultantes sont ellesmêmes des opérations auxquelles peuvent être appliqués les opérateurs de l algèbre. Ainsi, par l agrégation et la réutilisation de constructions existantes, et à travers des expressions déclaratives de l algèbre proposée, nous sommes en mesure de construire des services plus complexes. Une formule de composition des services, comme celle illustrée dans l exemple 1, peut aisément être exprimée en utilisant les divers opérateurs fournis par l algèbre. Cette formule combine les deux opérateurs Sequence et Parallel. Elle spécifie une construction qui exécute deux branches parallèles dont l une est une séquence de deux opérations OP1 et OP2. Exemple 1 : formule de composition 4.2. Sémantique formelle ((OP1 OP2) // OP3) Dans cette sous-section, nous donnons une définition formelle des opérateurs de composition en termes de S-GNets. Les constructions obtenues représentent les structures internes des S-GNets modélisant une composition de services. De ce fait, les notations P, T, W et l représentent respectivement l ensemble des places, l ensemble des transitions, l ensemble des relations de flow et la fonction d étiquetage (telles que mentionnées dans la définition 3) Notations utilisées Avant de définir les opérateurs, nous devons en premier lieu éclaircir quelques notations que nous allons utiliser dans les différentes définitions. OP : est l ensemble des opérations qui interviennent dans une construction 90

113 Chapitre 4 : Extraction et Spécification de la Composition T : est l ensemble des types d opérations de base tel que T = {Empty, Assign, Call, Receive, Reply} Type : est une fonction de signature Type:OP T qui, pour une opération donnée retourne son type. Card : est une fonction de signature Card :OP N* qui, pour une opération donnée retourne le nombre d opérations atomiques qui composent OP. Si Card(OP)=1 alors OP est une opération atomique sinon OP est une construction. Pour chaque construction, nous définissons une place d entrée IN et une place de sortie OUT. Ces deux places serviront comme point de liaison avec d autres constructions afin de modéliser des constructions plus complexes Définition des opérateurs Après avoir présenté l algèbre de composition des services Web, nous allons définir de façon plus détaillée chacun des opérateurs de l algèbre. Sequence. L opérateur Sequence permet d élaborer une construction composée de deux ou plusieurs opérations exécutées l'une après l'autre. Cet opérateur est utilisé quand une opération doit attendre le résultat d exécution d'une autre avant de commencer sa propre exécution. Par exemple, l activité «envoi de facture» est exécutée après l'exécution de l'activité «livraison des marchandises». La structure de la construction consiste à lier deux activités avec une transition et deux arcs de contrôle inconditionnel. Définition 6. La construction OP1 OP2 OPn est définie par OP1 OP2 OPn = (P, T, W, l) où: OPi i =1,n sont les opérations qui interviennent dans la construction P = {pi, i=1..n+2} où n est le nombre d opérations en séquence. OPi OP Card(OPi) 1 P = P\p i+1. T= {ti, i=1..n+1}, où n est le nombre d opérations en séquence W= {((Pi), ti), (ti, (pi+1)), i=1..n+1}, OPi OP Card(OPi) 1 W=W {(ti,in(opi)),(out(opi),ti+1)} l= {(pi, Type(OPi-1)) i,2..n+1} {(P1,IN)(Pn+2,OUT)} La construction résultant de l application de l opérateur Sequence est illustrée par la figure 4.11(a). Pour des raisons de clarté, nous avons limité le nombre d opérations intervenant dans la construction à deux opérations qui sont un appel au service S1 suivi d une opération Assign. Parallel/Synchronization. Etant données des opérations OPi, l'opérateur Parallel/Synchronization modélise une construction exécutant les opérations OPi en parallèle. La construction s apparente à un point dans le Workflow où un seul processus se divise en plusieurs branches qui peuvent être exécutées en parallèle, permettant ainsi aux activités associées à chaque branche de s exécuter simultanément. L'accomplissement de la construction résultante est atteint lorsque toutes les opérations sont terminées et qu un deuxième point dans le Workflow est spécifié pour permettre aux différentes branches (activités) parallèles de converger en un seul point, permettant ainsi la 91

114 Chapitre 4 : Extraction et Spécification de la Composition synchronisation de multiples opérations. Ce constructeur est utile quand un service exécute plusieurs services atomiques complètement indépendants. Par exemple, après avoir enregistré une déclaration de sinistre d'assurance, deux sous-processus parallèles sont déclenchés: l'un pour contrôler le contrat d assurance du client et l'autre pour évaluer le préjudice réel. Définition 7. La construction OP1//OP2// OPi est définie par OP1//OP2// OPi = (P, T, W, l) où: - OPi i=1,n sont les opérations qui interviennent dans la construction - P = {pi, i=0,n+1} {p0,p11}, OPi OP Card(OPi) 1 P = P\pi. - T={t1,t2}, - W= {(p0,t1),(t2,pn+1)} {(t1,pi),(pi,t2),i=1,n}. OPi OP Card(OPi) 1 W=W U{(t1,IN(OPi)),(OUT(OPi),t2)} - l={(pi,type(opi)),i=1,n}{(p0,in)(pn+1,out)} Figure 4.11 Représentation graphique des opérateurs de l algèbre en termes de S-GNets 92

115 Chapitre 4 : Extraction et Spécification de la Composition La construction résultant de l application de l opérateur Parallel/Synchronization est illustrée par la figure 4.11(b). Les deux opérations qui s exécutent en parallèle sont deux appels à deux services S1 et S2. La construction attend la fin d exécution des deux opérations (dans ce cas la réponse des services S1 et S2 à leur invocation) et synchronise le résultat à la transition T2. Alternative/Merge. L opérateur Alternative/Merge correspond à l opérateur d exclusion mutuelle. Appliqué aux opérations OPi, il reproduit le comportement d une seule opération. Autrement dit, l opérateur modélise une étape du processus où, sur la base d'une décision ou du flux de données, l'une des branches est choisie. Par exemple, en fonction de la charge de travail, une déclaration d'impôt est soit traitée est vérifiée à l'aide d'une simple procédure administrative ou est envoyée à un employé supérieur pour évaluation. Définition 8. La construction OP1 OP2 OPn est définie par OP1 OP2 OPn = (P, T, W, l) où: OPi i =1,n sont les opérations qui interviennent dans la construction P = {pi, i=0..n+1} où n est le nombre d opérations alternatives. OPi OP Card(OPi) 1 P = P\pi T= {t1i, i=1..n}u{t2i,i=1..n}, où n est le nombre d opérations alternatives W= {(p0,t1i),(t1i,pi),(pi, t2i)i=1,n} {(t2i,pn+1)i=1,n}. OPi OP Card(OPi) 1 W=W {(t1i,in(opi)),(out(opi),t2i)} l= {(pi, Type(OPi)) i,1..n}{(p0,in)(pn+1,out)} La construction résultant de l application de l opérateur Alternative est illustrée par la figure 4.11(c). Dans cet exemple, deux opérations interviennent dans la construction, une opération qui est un appel au service S1 et une opération Empty. Iteration. L'opérateur Iteration permet à une opération OP d être exécutée un certain nombre de fois. Un exemple d'utilisation de ce constructeur est quand un client commande à un service, un produit un certain nombre de fois. Définition 9. La construction OP est définie par OP = (P, T, W, l) où : OP est l opération qui intervient dans la construction P = {p1,p2,p3}. Si Card(OP) 1 P = P\p2 T= {t1,t2,t3} W= {(p1,t1),(t1,p2), (p2,t2),(t2,p2), (p2,t3), (t3,p3)}. Si Card(OP) 1 W=W {(t1,in(op)),(out(op),t2), (OUT(OP),t3), (t2,in(op))} l= {(p2, Type(OP))}{(p1,IN),(p3,OUT)}. La construction résultant de l application de l opérateur Iteration est illustrée par la figure 4.11(d). L opération itérée est un appel à un service Web S1. Arbitrary-Sequence. L opérateur Arbitrary-Sequence spécifie l'exécution de deux opérations qui ne doivent pas être exécutées en même temps. Ce constructeur est utile quand il n'y a aucun intérêt particulier à exécuter des services en parallèle. Cet opérateur 93

116 Chapitre 4 : Extraction et Spécification de la Composition peut par exemple être appliqué quand il n'y a pas de date limite pour accomplir une tâche globale et que le parallélisme engendre des coûts supplémentaires. Définition 10. La construction OP1 OP2 est définie par OP1 OP2= (P, T, W, l) où: - OP1, OP2 sont les noms des deux opérations qui interviennent dans la construction - P = {p1, p2,p3,p4,p5,p6,p7,p8,p9}. Si Card(OP1) 1 P = P\p5. SiCard(OP2) 1 P = P\p6. - T={t1,t2,t3,t4,t5,t6}, - W={(p1,t1),(t1,p2),(t1,p3),(t1,p4),(p2,t2),(t2,p5), (p5,t4),(t4,p7), (t4,p3), (p7,t6),(t6,p9), (p3,t2),(p3,t3),(p3,t6),(p4,t3),(t3,p6),(p6,t5), (t5,p3),(t5,p8),(p8,t6)}. Si Card(OP1) 1 W=W U{(t2,IN(OP1),(OUT(OP1),t4)). Si Card(OP2) 1 W=W U{(t3,IN(OP2),(OUT(OP2),t5)). - l= {(p1,in), (p5, Type(OP1)), (p6, Type(OP2)), (p9, OUT)}. La construction résultant de l application de l opérateur Arbitrary-Sequence est illustrée par la figure 4.11(e). Les deux opérations qui interviennent dans la construction sont deux appels aux services S1 et S Grammaire de graphe pour la composition Pour la mise en œuvre de la composition, nous utilisons des techniques de métamodélisation et de transformation de modèles basées sur le langage de modélisation S- GNet. Comme la syntaxe concrète des modèles manipulés est graphique, nous utilisons la réécriture de graphes pour effectuer la transformation de modèles. Nous mettons en œuvre un cas particulier de la transformation de graphes où le modèle source et le modèle cible est le même, à savoir celui des S-GNets. Les règles de transformation réalisent des modifications sur la partie gauche en ajoutant des portions de graphes conformes au métamodèle. La grammaire de graphes que nous proposons est une déduction naturelle de la formalisation que nous avons spécifiée dans la section précédente. Si l on se réfère aux critères de classification existants, le type de transformation que nous appliquons dans notre approche est: Endogène (par opposition à la transformation de modèle exogène), puisque le méta-modèle utilisé pour exprimer le modèle source et le modèle cible est le même. Horizontale (par opposition à la transformation du modèle verticale), puisque les modèles source et cible résident au même niveau d'abstraction. Pour mettre en œuvre les opérateurs de l algèbre de composition basée S-GNet, nous avons défini une grammaire de graphes qui consiste en un ensemble de règles de transformation. La grammaire complète inclut quinze règles qui sont appliquées pour obtenir un S-GNet modélisant une composition de services Web à partir d une formule de composition donnée. Avant d entamer l élaboration du S-GNet modélisant la composition, la grammaire analyse la formule de composition afin d appliquer les divers opérateurs intervenant dans la composition. Pour générer le S-GNet modélisant la composition, les interfaces des services Web intervenant doivent être extraites et 94

117 Chapitre 4 : Extraction et Spécification de la Composition représentées avec le formalisme S-GNet comme spécifié dans la phase précédente. Ceci permettra de pouvoir invoquer les différentes opérations fournies par les services lors de la composition. Lorsque l exécution de la grammaire de graphe se termine, nous obtenons un nouveau service S-GNet modélisant le service composite. Dans toutes les règles représentées, les nœuds et les différentes connexions sont marqués par des numéros qui les identifient. Ces identifiants sont utilisés au cours de l'application des règles. Ils sont également utilisés dans les actions associées aux règles pour calculer les valeurs des attributs portant l inscription <SPC> (pour Specified). Les valeurs de ces attributs éléments dans la partie gauche des règles sont comparées avec les valeurs des attributs des éléments du graphe hôte au cours du processus de comparaison des parties droites et gauches. Les figures 4.12 jusqu'à 4.14 illustrent les différentes règles de la grammaire de composition. Toutes les règles de cette grammaire de graphe utilisent dans leurs parties droites et gauches le méta-modèle S-GNet que nous avons défini précédemment. L action initiale de la grammaire de graphes consiste à créer des variables globales nécessaires au processus de transformation. Ces variables sont accessibles pour toutes les règles de la grammaire. C est aussi dans l action initiale de la grammaire que la formule de composition est analysée avant le début de l exécution de la grammaire. Elle est décomposée d une manière particulière qui va permettre l application des règles de la grammaire. La formule est découpée et organisée en une liste de tuples représentant des sous-formules. Chaque tuple contient au minimum deux éléments qui sont l opérateur et l (es) opération(s). L opérateur principal de la formule est détecté et est utilisé pour construire le premier tuple de la formule. La première case du tuple contient l opérateur en question et les cases suivantes représentent les opérandes. Les autres tuples représentent les constructions secondaires. On considère par exemple, la formule de composition de l exemple 1 : ((OP1 OP2) // OP3) Cette formule est décomposée en deux tuples représentant deux sous-formules : - La sous-formule 1 (sous-formule principale): (//,OP1 OP2, OP3) et - La sous-formule 2 : (, OP1, OP2) Dans les règles de notre grammaire de composition, à chaque type d opération spécifié au sein de la formule de composition, correspond un type de place spécifique. A une opération d assignation (Assign) est associée une place de type Assign, à une opération Call est associée une place du type ISP et à une opération de type Empty est associée une place normale. Un traitement est effectué pour représenter chaque type d opération avec son type de place correspondant. Ceci contribue à apporter une généricité aux règles. La règle Send_SubF est la première règle de la grammaire. Cette règle est appliquée pour affecter à la variable globale SubF une sous-formule de la formule de composition (Formula) extraite à partir de la queue de la liste de tuples. 95

118 Chapitre 4 : Extraction et Spécification de la Composition Figure 4.12 Grammaire de graphe pour la composition, Règles

119 Chapitre 4 : Extraction et Spécification de la Composition Les règles 2, 3 et 4 mettent en œuvre la construction Sequence. La règle 2 génère la place normale IN de la construction et lui affecte comme nom la chaine «IN.» concaténée avec le nom de la sous-formule. La règle 3 permet de générer une opération en séquence. Elle est exécutée autant de fois qu il y a d opérations en séquence. La liste Operands contient initialement les noms des opérations en séquence. Chaque fois que la règle est exécutée, une opération est supprimée de la liste Operands. Lorsqu elle devient vide, la règle n est plus applicable (il n y a plus d opérations en séquence à générer). La règle 4 génère enfin la place OUT de la construction, lui affecte comme nom la chaine «OUT.» concaténée avec le nom de la sous-formule et prend soin de remettre la variable SubF à Null afin de permettre une éventuelle application ultérieure de la règle 1. Les règles 5 et 6 mettent en œuvre la construction Alternative/Merge. La règle 5 génère les places IN et OUT de la construction et leur affecte comme nom respectivement les chaines «IN.»/ «OUT.» concaténées avec le nom de la sous-formule. La règle 6 génère une branche alternative pour chaque opération intervenant dans la construction. Les noms des opérations alternatives sont contenus dans la liste Operands. Cette liste est utilisée pour tester la fin d exécution de la règle. Lorsque cette liste devient vide, la variable SubF est réinitialisée à Null et la règle 6 ne devient plus applicable (il n y a plus de branches à générer). La règle 7 est utilisée pour réaliser la construction Iteration. Elle génère les places IN et OUT de la construction, leur affecte comme nom la chaine «IN.»/ «OUT.» concaténée avec le nom de la sous-formule et réitère l opération intervenant dans la construction. A la fin d exécution de la règle, elle réinitialise la liste SubF à Null. Les règles 8 et 9 mettent en œuvre la construction Parallel/Synchronization. La règle 8 génère les places IN et OUT et les transitions qui permettent le split et la synchronisation des branches de la construction. Les variables SplitTr et MergeTr permettent de sauvegarder les identifiants des transitions réalisant respectivement le split et la synchronisation. La règle 9 génère les branches parallèles de la construction. La liste Operands est utilisée pour sauvegarder les opérations en parallèle. La règle 10 met en œuvre l opérateur Arbitrary-Sequence. Elle génère les places IN et OUT de la construction. Elle génère également les places, les transitions et les arcs nécessaires au fonctionnement de la construction conformément à sa définition. La liste Operands est utilisée pour stocker les opérations avec lesquelles on souhaite construire une séquence arbitraire. A la fin de l exécution de la règle, la variable SubF est réinitialisée à Null. 97

120 Chapitre 4 : Extraction et Spécification de la Composition Figure 4.13 Grammaire de graphe pour la composition, Règles 8-10 La règle 11 intervient après que toutes les sous-formules et la formule principale soient générées, afin de structurer le résultat final. Elle recherche dans la formule principale une place (p) portant un nom de sous-formule (le nœud N 5 de la partie gauche) et détecte les places IN et OUT correspondant à la sous-formule traitée. Après quoi, elle supprime la place portant le nom de la sous-formule et spécifie deux nouveaux liens : le premier de p (l arc entre le nœud 4 et le nœud 2 de la partie droite) vers la place IN de la construction correspondant à la sous-formule. Le deuxième de la place OUT de la construction correspondant à la sous-formule vers p (l arc entre le nœud 3 et le nœud 6 de la partie droite). 98

121 Chapitre 4 : Extraction et Spécification de la Composition Figure 4.14 Grammaire de graphe pour la composition, Règles

122 Chapitre 4 : Extraction et Spécification de la Composition La règle 12 génère la GSP et l IS modélisant la composition. Elle génère aussi une place Receive et une place Goal pour le nouveau service (ou S-GNet). Ces deux places permettent respectivement de spécifier le début (réception d une invocation) et la fin (renvoi du résultat) d exécution du service composé en cours de génération. La règle 13 détecte les places IN et OUT de la construction globale générée précédemment et effectue les liens entre celles-ci et le reste de l IS du service généré. Ainsi, la construction globale générée lors de l exécution des premières règles constituera la structure interne du S-GNet. 100 La règle 14 génère la table du S-GNet et spécifie le lien avec sa GSP. La règle 15 détecte une place ISP non encore visitée et génère pour chaque place un nouveau tuple à partir des tables de données des services participants. La deuxième action de cette règle ajoute le tuple à la table du nouveau service. Les exécutions successives de cette règle permettent de construire les descriptions des messages inmsg et outmsg du nouveau service Exemple Dans ce qui suit, nous illustrons à travers un exemple une composition de services Web en appliquant notre grammaire de graphe définie ci-dessus. L exemple représente une composition des deux services Web bookinghotel et BusTiketService en un seul service Web composite d agence de voyage qui organise des séjours pour les clients. Ces derniers ne seront plus obligés d interagir avec les deux services séparément afin d obtenir une réservation d hôtel et de bus. Le concepteur de ce nouveau service Web composite souhaite que les deux réservations se fassent en parallèle. Pour cela, il utilise le constructeur adapté en spécifiant une formule de composition F comme suit : F = (SF1 // SF2) SF1= (Call(BookingHotel.checkNewBooking) Assign) SF2= (Call(BusTiketService.getTiket) Assign) La formule utilise le constructeur Parallel (//). La première branche du constructeur contient deux opérations exécutées en séquence qui sont un appel à une méthode du service Web bookinghotel et une opération d assignation. La deuxième branche du constructeur contient deux opérations exécutées en séquence qui sont un appel à une méthode du deuxième service Web BusTiketService et une opération d assignation. La grammaire de graphe considère en entrée la formule spécifiée par le concepteur ainsi que les spécifications S-GNet des services Web impliqués dans la composition (dans ce cas, les deux services illustrés dans les figures 4.6 et 4.7) et renvoie comme résultat un service Web composite toujours exprimé dans le formalisme S-GNet. La figure 4.15 illustre le résultat d application de la grammaire. Le nouveau S-GNet généré contient une place de type Receive et une place de type Goal qui permettent respectivement la réception de requêtes sous forme de messages conforme à la structure du message d entrée du S-GNet et le renvoi de la réponse sous forme de message conforme à la structure du message de sortie du S-GNet.

123 Chapitre 4 : Extraction et Spécification de la Composition Figure 4.15 Résultat de composition par la grammaire de graphe Le S-GNet résultant contient un PortType avec une opération «TravelAgentOP». Celle-ci prend en entrée le message inmsg et retourne le résultat au sein du message outmsg. La déclaration de la structure de ces deux messages va se trouver dans le fichier WSDL contenant la description du nouveau service obtenu Mise en œuvre de la composition A l instar du processus de modélisation, le processus de composition est implémenté avec AToM 3. Pour implémenter la composition des services Web, nous suivons les étapes du processus de composition représenté par un diagramme d activité UML dans la figure Nous rappelons que dans notre approche, l étape de composition est réalisée par une transformation de graphes endogène (le méta-modèle S-GNet est utilisé au sein des règles comme méta-modèle source et cible). Après chargement de l outil AToM 3, le métamodèle S-GNet est ouvert. Cette action rend l environnement de développement S-GNet disponible. Nous faisons alors appel à ce dernier pour mettre en œuvre la grammaire de graphes de composition. Pour cela nous utilisons le menu d édition de règles de transformation d AToM 3. La figure 4.17 illustre la règle N 3 de la grammaire au sein de l éditeur de règles d AToM 3. Les actions associées à chaque règle sont spécifiées en code Python. On peut voir sur la figure les parties gauche et droite de la règle. La grammaire de graphes, une fois éditée, est stockée dans la zone utilisateur d AToM 3. Pour obtenir un modèle de service Web dans le formalisme S-GNet, le concepteur commence par importer les S-NGets modélisant les services intervenant dans la composition. L environnement de développement invite alors l utilisateur à spécifier un 101

124 Chapitre 4 : Extraction et Spécification de la Composition scénario de composition sous forme d une formule de composition conforme à l'algèbre définie. Figure 4.16 Processus d implémentation de la grammaire de graphe pour la composition Figure 4.17 La règle N 3 de la grammaire de graphes pour la composition des services Web dans AToM 3 La figure 4.18 illustre le modèle de services Web composé TravelAgent obtenu dans notre outil (cf. section précédente). Le scenario de composition spécifié ici est celui présenté dans l exemple de la section précédente. 102

125 Chapitre 4 : Extraction et Spécification de la Composition 5. Conclusion Figure 4.18 Modèle du service composé TravelAgent avec l outil généré Ce chapitre a été consacré à la présentation de deux phases de notre méthodologie pour la composition des services Web à savoir, la phase d extraction des interfaces des services intervenants et la phase de modélisation de la composition. Comme nous avons pu le voir, ces deux phases ainsi que l approche dans sa globalité s appuient sur l utilisation massive des principes de l IDM. Le formalisme S-GNet a été méta-modélisé et son modèle nous a servi de base pour générer un environnement de modélisation spécifique aux S-GNets. Les deux phases ont été mises en œuvre grâce à des transformations de modèles successives utilisant le méta-modèle des S-GNet comme méta-modèle source et cible. Ces deux phases de l approche nous ont permis jusqu ici d obtenir un modèle de services Web composé selon un scénario de composition défini par l utilisateur. Toutes les notions introduites par notre approche ainsi que les opérateurs de notre algèbre de composition ont été formellement définis. La définition formelle des opérateurs présentée dans ce chapitre est fondamentale pour leur implantation. Au final, les deux grammaires de graphes proposées pour la mise en œuvre de la spécification des services intervenants et la modélisation de la composition ont été implémentées dans l outil de modélisation S-GNet généré. Le chapitre suivant, sera consacré à la présentation détaillée des deux phases restantes de l approche WS-mcv qui sont la phase de vérification du modèle de composition et la phase d implémentation du modèle de service Web composé. Ces deux phases permettent pour l une de procéder à la vérification du modèle obtenu et pour l autre d obtenir automatiquement le code exécutable associé au modèle. Le code généré s exprimera dans le langage BPEL qui est le standard d orchestration de services Web. 103

126 Chapitre 5 Vérification et Implémentation du Modèle de Service Web Composé

127

128 Chapitre 5 : Vérification et Implémentation du Service Web Composé Chapitre 5 Vérification et Implémentation du Modèle de Services Web Composé 1. Introduction Nous ne pouvons réellement tirer profit de l IDM que lorsque nous exploitons pleinement son potentiel pour l'automatisation. Cela comprend aussi, la vérification automatique des modèles sur un ordinateur et la génération automatique des programmes complets à partir de ces modèles. Le présent chapitre a pour objectif de détailler ces deux dernières phases de la méthodologie WS-mcv. La vérification automatique de modèles signifie utiliser un ordinateur pour analyser un modèle afin de s assurer de la présence de propriétés souhaitables et l'absence d autres indésirables. Cela peut prendre de nombreuses formes, y compris les analyses formelles (mathématiques) telles que l'analyse de la performance basée sur la théorie des files d attente ou la vérification de propriétés de sureté et de vivacité. Le plus souvent cela consiste en la simulation des modèles sur un ordinateur. Dans tous les cas, il est essentiel d'être capable de procéder à la vérification sur des modèles très abstraits et incomplets qui voient le jour tôt dans le cycle de développement, parce que c'est à ce moment-là que les concepteurs prennent la plupart des décisions fondamentales de conception. Pour mettre en œuvre la phase de vérification, nous proposons d exploiter les règles de transformation qui permettent de transformer des spécifications S-GNet en des réseaux prédicats/transition (PrT-Nets). Nous effectuons cette transformation dans le but d exploiter les outils existants munis d une grande variété de techniques d analyse comme l outil PROD. Un autre aspect de l automatisation au sein de l IDM est la génération de code complet. Elle signifie simplement que les langages de modélisation sont pour les modèles ce que sont les compilateurs pour les codes sources. Dans le sens où, avec la génération de code, il est rarement nécessaire d'examiner ou de modifier le programme généré, tout comme il est rarement nécessaire d'examiner ou de modifier le code machine que produit un compilateur. Notre phase d implémentation a pour objectif de générer du code BPEL permettant la définition d un processus BPEL implémentant le modèle du service Web composite. Dans ce contexte, nous proposons une grammaire de graphes permettant, à partir de spécifications S-GNet de modèles de services composés, de générer le code BPEL correspondant. Cette grammaire est aussi intégrée à l outil de modélisation obtenu avec AToM 3. Ce chapitre est structuré comme suit : dans la section 2, nous exposons les détails relatifs à la mise en œuvre de la phase de vérification. La phase d implémentation des modèles S-GNets est présentée dans la section 3. Nous y présentons la logique de transformation ainsi que la grammaire de graphes qui la réalise. Nous terminons le chapitre par une conclusion. 104

129 Chapitre 5 : Vérification et Implémentation du Service Web Composé 2. Phase de Vérification du modèle obtenu Les DSLs sont des langages qui sont axés sur un domaine particulier. En faisant des hypothèses sur ce domaine et en codant ces hypothèses dans le même langage, un système exprimé avec un DSL approprié est plus concis qu'un système qui exprime le même comportement, mais écrit dans un langage d'usage général. Dans le cadre de l IDM, une fonctionnalité importante est de pouvoir vérifier formellement les modèles construits à partir du DSL défini (dans notre cas le DSL S- GNet). Cette vérification s opère vis-à-vis d un ensemble donné de propriétés. Ces propriétés peuvent être soit générales au langage et définies alors sur le DSL, soit spécifiques au système considéré et exprimées alors sur les modèles. Un système écrit dans un DSL est plus facilement analysable vis-à-vis du domaine, car la sémantique du domaine est directement exprimée. A titre d'exemple, considérons un DSL qui optimise la consommation d'énergie dans un bâtiment. Une règle peut exprimer que si la température est inférieure à 25 degrés alors les climatiseurs sont arrêtés. L'identification des climatiseurs qui ne sont contrôlés par aucune règle est triviale en faisant en sorte que chaque climatiseur est référencé par au moins une règle. Faire la même chose pour un programme en langage de bas niveau qui commande les climatiseurs, est beaucoup plus difficile en raison du codage de la logique de l'application dans le langage de bas niveau. Cependant, il ya également des analyses qui ne peuvent pas être facilement réalisées simplement en observant un système écrit dans un DSL. Si l on revient à l exemple de gestion de l'énergie, la détection des climatiseurs non contrôlés devient beaucoup plus complexe si ces appareils apparaissent dans certaines règles, mais que les conditions de ces règles ne sont jamais satisfaites. Il s'agit d'un exemple typique du problème de satisfiabilité, à savoir, vérifier si une formule booléenne peut être vraie ou pas. Il existe de nombreux outils qui peuvent être utilisés pour effectuer ces analyses. Pour chaque outil d'analyse, nous avons besoin de transformer le modèle décrit dans le DSL vers le formalisme d'entrée de l outil d analyse. Contrairement à d'autres approches de composition de services Web, la méthodologie WS-mcv traite de la vérification formelle afin de tester et réparer les erreurs de conception avant même le fonctionnement réel du service composé. L'objectif étant d augmenter la fiabilité de la composition des services Web en s'assurant que le S- GNet composite ne contient pas d'erreurs ou d anomalies comportementales. Pour effectuer la vérification formelle des systèmes modélisés par les langages basés sur les réseaux de Petri, les recherches actuelles exploitent les caractéristiques puissantes des techniques d'analyse d'accessibilité des graphes. Ces techniques ont été implémentées dans divers outils d analyse spécifiques à un formalisme donné. Les S- GNets étant un formalisme basé sur les réseaux de Petri, nous proposons d utiliser les techniques d analyse d accessibilité de graphes au sein de notre approche pour procéder à la vérification des modèles de composition produits dans ce formalisme. Pour cela, des transformations sur le modèle à vérifier sont nécessaires afin de pouvoir exploiter les outils d analyse déjà existants. Dans ce qui suit, nous expliquons en détail la méthode de transformation que nous avons proposée. 105

130 2.1. Méthode de transformation Chapitre 5 : Vérification et Implémentation du Service Web Composé Etant donné qu il n'existe pas d'outils d'analyse d'accessibilité pour le formalisme S- GNet, nous faisons usage des travaux de Kerkouche [Kerkouche & Chaoui, 2009]. Ces travaux consistent entre autres à la réalisation d une plate-forme pour l analyse des G- Nets. Ces derniers sont les réseaux de Petri dont nous avons proposé une extension leur permettant d être mieux adaptés à la spécification des compositions de services Web. Cette plate-forme définit deux grammaires de graphes. La première transforme une spécification G-Net en leurs réseaux prédicat/transition équivalents (PrT-Nets) [Genrich et al., 1981]. La deuxième grammaire génère la description PROD [PROD] équivalente au modèle résultant de la première grammaire. Cette transformation est réalisée dans le but d'exploiter un outil d'analyse puissant pour les PrT-Nets, à savoir l analyseur d'accessibilité de graphes PROD. L analyse d accessibilité est une méthode très efficace pour analyser formellement les systèmes spécifiés dans des formalismes de type réseaux de Petri. Le but de l analyse d accessibilité est de calculer le graphe de tous les états du système qui peuvent être atteints à partir de son état initial. L analyse crée un graphe d accessibilité qui consiste en un ensemble de marquages V (les sommets) et un ensemble d arcs E. L ensemble des sommets V contient tous les états atteignables du système et l ensemble d arcs E contient toutes les actions survenues au sein du système. Lorsque le graphe d accessibilité a été créé, il est possible de trouver les nœuds terminaux du système ainsi que de vérifier si certaines propriétés sont présentes dans le système. PROD est un outil d analyse d accessibilité développé par une équipe de chercheurs de l université d Helsinki en Finlande. Cet outil crée des graphes d'accessibilité pour les systèmes modélisés par des réseaux de Petri de type PrT-Nets. A partir des graphes d accessibilité, PROD peut non seulement vérifier les propriétés d accessibilité mais aussi les propriétés de sureté et de vivacité. Les utilisateurs peuvent rechercher les nœuds terminaux, le chemin menant à ces nœuds terminaux et le chemin qui satisfait certaines propriétés données. PROD fait usage de plusieurs méthodes de génération de graphes d accessibilité réduits. Il permet le Model-Checking de formules CTL et permet aussi une vérification à la volée de formules LTL (on-the-fly verification). La propriété désirée peut donc être vérifiée au moment de la création du graphe. De cette manière, il n est pas toujours nécessaire de générer la totalité du graphe ce qui permet de remédier au problème d explosion du nombre d états en fonction de la taille du système à vérifier dont souffrent les méthodes d analyse d accessibilité de graphe. Le manuel complet de PROD peut être trouvé dans [PROD]. Dans la figure 5.1, nous avons représenté le schéma global de la plate-forme proposée par [Kerkouche & Chaoui, 2009]. Dans cette figure, il apparait que la phase de vérification est divisée en deux tâches: 1) la transformation d'un G-Net en un réseau PrT-Net équivalent et 2) la traduction du PrT-Net obtenu en une description PROD. 106

131 Chapitre 5 : Vérification et Implémentation du Service Web Composé Figure 5.1 Schéma de la plate-forme pour l analyse des G-Nets Afin de faire usage de cette plate-forme, nous proposons d adapter les modèles S- GNets obtenus à la phase de composition en G-Nets. Cette adaptation consiste en premier lieu à faire abstraction des tables de données. Cette action a pour conséquence l impossibilité de vérifier les données échangées entre les services Web. Une autre modification concerne la structure interne du S-GNet. Ces adaptations consistent à considérer la place de type Receive comme une place Input de la méthode du S-GNet et considérer les places du type Assign comme des places ordinaires. Ces simples modifications nous permettent ainsi de procéder à la vérification du modèle de composition. Si des anomalies sont détectées au sein du modèle, le développeur procède aux modifications nécessaires sur le modèle et réitère la phase de vérification jusqu à obtention d un modèle valide Déroulement de la phase de vérification Dans ce qui suit, nous allons montrer comment nous avons procédé à la vérification formelle des modèles de services Web en utilisant la plate-forme définie par Kerkouche. Pour cela, nous reprenons le modèle de service Web composé TravelAgent obtenu lors de la phase de modélisation de la composition. La figure 5.2 présente l adaptation du modèle du service TravelAgent et ce, au sein de la plate-forme considérée. Le lecteur peut remarquer dans la partie supérieure de la figure que le méta-modèle G-Net spécifique à la plateforme est utilisé. Cette plate-forme permet de transformer une spécification G-Net en son PrT-Net équivalent. Le processus de vérification commence par la sélection du service G-Net à analyser. Les règles de transformation sont donc appliquées au modèle G-Net TravelAgent. Lorsque cette transformation est terminée, nous obtenons la spécification PrT-Net équivalente au modèle considéré. Cette transformation est illustrée par la figure

132 Chapitre 5 : Vérification et Implémentation du Service Web Composé Figure 5.2 Adaptation du service TravelAgent en G-Net Figure 5.3 Le modèle PrT-Nets équivalent au G-Net TravelAgent Pour effectuer l analyse de ce modèle en utilisant PROD, il faut à présent convertir la spécification PrT-Net en une description PROD équivalente. Cette description facilement obtenue à l aide de la plate-forme, est représentée dans les figures 5.4 et

133 Chapitre 5 : Vérification et Implémentation du Service Web Composé Figure 5.4 Fichier contenant la description PROD 1/2 Figure 5.5 Fichier contenant la description PROD 2/2 PROD compile cette description et génère le graphe d accessibilité complet. Nous mettons l accent sur le fait qu à ce jour, l outil PROD ne dispose pas d interface utilisateur ; de ce fait, son utilisation s avère comme une tâche fastidieuse due à son utilisation en mode console. Nous prévoyons donc de pallier à ce problème en intégrant 109

134 Chapitre 5 : Vérification et Implémentation du Service Web Composé une interface plus conviviale au sein de notre outil qui permettra d interpréter les résultats obtenus par PROD. 3. Phase d Implémentation du modèle de composition Toutes les étapes que nous avons décrites jusqu à présent ont permis d aboutir à l élaboration du modèle de composition. Cependant, la modélisation constitue la moitié du travail. Si le développeur veut vraiment obtenir un retour intéressant sur l investissement de ses modèles, il doit définir des transformations qui visent à transformer ses modèles vers d'autres objets à valeur ajoutée tels que le code ou la documentation. La phase d implémentation de la méthodologie WS-mcv intervient après la validation du modèle de composition. Elle a pour objectif de générer du code BPEL permettant la définition d un processus BPEL implémentant le modèle du service Web composite. Pour atteindre cet objectif, nous proposons une technique de transformation du formalisme S-GNet vers du code BPEL. Cette transformation sera mise en œuvre par une grammaire de graphe que nous allons présenter dans les sous-sections suivantes Transformation S-GNet vers BPEL Dans ce qui suit, nous présentons un mapping entre une spécification S-GNet et le code BPEL. Il s agit ici d une transformation d une structure de graphes en une structure de blocs. Notre approche consiste à identifier les différents éléments d une spécification S-GNet représentant le modèle du service Web composé et de les faire correspondre avec des blocs BPEL adéquats. Cette méthode de transformation est illustrée d une façon générale par la figure 5.6. La partie supérieure de la figure présente les différents constituants du S-GNet composite ainsi que les S-GNets partenaires. Ces derniers sont la représentation en S-GNet des descriptions WSDL des services Web intervenant dans la composition qui ont été obtenue lors de la phase d extraction. La partie inférieure de la figure illustre les principales composantes de la structure d un fichier BPEL. Comme nous l avons déjà indiqué dans le chapitre 1, un processus BPEL correspond à une séquence d opérations ou plus exactement à un flux d activités de base structurées. Ces activités peuvent faire intervenir un à plusieurs services Web. Le processus BPEL permet aussi de déclarer des variables, avec le bloc <variables>, et de définir des liens de partenariat avec le bloc <partnerlinks>. Une description BPEL, schématisée dans la figure 5.6, se décompose donc en trois parties : La définition des liens avec les participants (ou PartnerLinks) du processus métier, La définition des variables permettant la sauvegarde et la manipulation des messages échangés avec les partenaires et La définition du processus métier (le flux d activités constituant le processus). 110

135 Chapitre 5 : Vérification et Implémentation du Service Web Composé 111 Figure 5.6 Méthode de transformation des spécifications S-GNets vers du code BPEL Dans ce qui suit, nous définissons les règles de transformation entre les éléments d une spécification S-GNet et ceux d une description de processus BPEL qui leur correspondent. Ces règles exposent la logique que nous avons suivie pour élaborer une grammaire de graphe qui est chargée de générer automatiquement le code BPEL. (1) A chaque S-GNet correspond un fichier (.bpel) décrivant un processus BPEL. (2) Le nom du processus BPEL correspond à celui du S-GNet (principal) modélisant le service composite. (3) La partie PartnerLinks du processus BPEL est construite à partir des places ISP présentes dans la structure interne (IS) du S-GNet composite ainsi que les GSP des S-GNets partenaires. (4) Pour chaque place de type ISP présente dans l IS du S-GNet composite, un bloc PartnerLinks est ajouté à la description du processus BPEL. Dans ce qui suit, le symbole + est utilisé pour exprimer une concaténation de chaines de caractères. Les valeurs des attributs du bloc sont comme suit : - L attribut «name» = "PLinkInvok" + "<le nom du S-GNet invoqué par l ISP>"+ "<le nom de la méthode invoquée par l ISP>".