ArchiMed : canevas multimédiateur pour la réconciliation de conversations entre services web

ArchiMed : canevas multimédiateur pour la réconciliation de conversations entre services web Ali Aït-Bachir Marie-Christine Fauvet Laboratoire LIG/MRIM, Universités de Grenoble 385 rue de la bibliothèque B.P. 53 38041 Grenoble Cedex 9 Ali.Ait-Bachir@imag.fr, Marie-Christine.Fauvet@imag.fr RÉSUMÉ. La technologie des services web est aujourd hui largement utilisée comme support de l interopérabilité entre les applications. Dans ce cadre, les interactions entre deux applications encapsulées par des services web sont réalisées par le biais d un ensemble d échanges de messages appelé conversation. Une conversation peut échouer parce que l interface fournie d un participant a été modifiée et n est plus compatible avec celle requise par l autre participant. L étude rapportée dans cet article porte sur la réconciliation de telles conversations. La solution proposée consiste en un canevas qui, s appuyant sur les versions successives de l interface fournie du service, génère un ensemble de médiateurs. A l initiation d une conversation par un client, si nécessaire, le canevas sélectionne parmi les médiateurs disponibles celui qui résoud les incompatibilités entre le client et le service. Cet article décrit le modèle pour la détection des incompatibilités et leur résolution, et fournit les détails de sa mise en œuvre. ABSTRACT. web service-based technology is widely accepted as the infrastructure which enables applications interoperability. In this setting, message exchanges form the basics of interactions between applications wrapped as web services. The set of messages exchanged between two services describes a conversation. The study reported in this text aims at reconciliating conversations which fail due to an evolution of the provided interface which is thus no longer compatible with the one required by clients. To address this issue, we propose a framework which, relying on successive versions of the interface provided by the service, generates mediators. When a client starts a conversation, the framework selects one suitable mediator which is responsible for seamlessly resolving incompatible conversations. This article presents a model and its implementation for detection and resolution of incompatibilities. MOTS-CLÉS : services web, conversation, interface, conformité, médiation, version, automates. KEYWORDS: web services, conversation, interface, compatibility, mediation, version, automata. RSTI - ISI 13/2008. Modèles, formalismes et outils, pages 83 à 106

84 RSTI - ISI 13/2008. Modèles, formalismes et outils 1. Introduction Les interactions par échanges de messages sont à la base des services web. La modélisation de services web met en jeu la description de ces interactions et de leurs interdépendances, aussi bien du point de vue structurel (types de messages échangés) que du point de vue comportemental (flot de contrôle entre interactions). L ensemble de ces interactions réalisées entre un client et un service est appelé conversation. Selon que l on se réfère à l interface qu un service existant est capable de fournir, ou de l interface qu un service est censé fournir, et donc attendue par les clients, on parle d interface fournie ou d interface requise. Suite à des modifications de l interface fournie d un service il peut s avérer que celle-ci ne corresponde plus à l interface que les partenaires du service requièrent, ce qui conduit nécessairement à la mise en échec des conversations entre le service et ses clients et probablement à la perte des clients par le service. Pour éviter cela, le fournisseur peut choisir entre deux solutions : (1) adopter l interface requise de ses clients comme interface fournie et modifier le service en conséquence ; (2) introduire un médiateur qui réconcilie l interface fournie avec celles requises par ses partenaires. La première solution est en général mauvaise car le même service peut interagir avec plusieurs autres services partenaires qui considèrent son interface originale. Ce qui conduit à la situation où le même service peut participer à diverses collaborations qui nécessitent différentes interfaces fournies. La seconde solution pallie ce défaut par la fourniture d un médiateur ou d un adaptateur. Une interface peut être décrite selon la dimension structurelle, comportementale ou encore non fonctionnelle. Ainsi l adaptation doit être étudiée selon chacune de ces dimensions. Le problème de l adaptation structurelle se ramène essentiellement à celui de la réconciliation entre des types de messages. Il existe sur ce sujet de très nombreuses études (Ponnekanti et al., 2004; Altenhofen et al., 2005; Oaks et al., 2005) et plusieurs systèmes proposant des solutions certes partielles, sont commercialisés (par exemple Microsoft s BizTalk Mapper). A l inverse, le problème de l adaptation selon la dimension comportementale est en cours d étude (Peltz, 2003; Altenhofen et al., 2005; Benatallah et al., 2005; Ait-Bachir et al., 2007). Dans cet article nous proposons d étudier l adaptation des interfaces selon leur dimension comportementale. La contribution du travail rapporté ici est essentiellement la proposition du canevas ArchiMed 1, hébergé côté fournisseur dont les caractéristiques sont résumées ci-après. Détection de toutes les incompatibilités : chaque version successive de l interface fournie par un service est formalisée par un automate. Nous proposons un algorithme qui compare l automate de la nouvelle version à celui de la précédente version et détecte toutes leurs incompatibilités. Cette exhaustivité est une originalité par rapport aux approches qui se limitent à tester la compatibilité d interfaces (voir par exemple (Bordeaux et al., 2004; Corrales et al., 2006)). 1. ArchiMed : Architecture de Médiation.

Médiation de conversations de services 85 Génération des médiateurs : pour chaque version de l interface, si l automate associé ne simule pas celui de la version courante, un médiateur est généré. Ce mécanisme est une originalité de l approche, il permet de supprimer le coût lié à la réalisation manuelle des médiateurs. Gestion multimédiateur : le canevas maintient autant de médiateurs qu il existe de versions différentes de l interface d un service. Ainsi, la réconciliation des conversations entre un client et le service est rendue possible quelle que soit la version de l interface fournie considérée par ce client. Choix du médiateur à l exécution et mécanisme transparent pour les clients : lors de l initialisation d une conversation par un client, si l interface requise par ce dernier est incompatible avec la version courante de l interface du service, le canevas détermine le médiateur qui doit être utilisé afin de résoudre les incompatibilités. Le médiateur sélectionné conduit ensuite les échanges avec le service, et ce de manière transparente pour le client. La structure de la suite de l article est la suivante : dans la section 2 un scénario exemple décrit le problème posé et justifie le travail présenté dans ce texte. La section 3 présente le principe et l architecture fonctionnelle du canevas ArchiMed. La détection et la résolution des différents types d incompatibilités entre deux versions d interface sont étudiées dans la section 4 puis illustrées dans la section 5. La mise en œuvre de la solution est présentée dans la section 6. La section 7 discute des apports et des limites de travaux connexes. Finalement, la section 8 conclut et fournit quelques-unes des perspectives que cette étude a ouvertes. 2. Motivations et exemple illustratif L interface fournie, dans sa version P, d un service peut évoluer vers une nouvelle version P suite à des changements selon l une de ses dimensions structurelle ou comportementale. Selon cette dernière dimension, ces changements se traduisent par des ajouts, des suppressions ou des modifications d opérations. Dans cet article, la suppression et l ajout d opérations sont étudiés et la modification d opérations s inscrit dans nos perspectives. Pour illustrer notre approche nous considérons un service de ventes de produits dont le processus associé modélise toutes les phases depuis la commande des articles jusqu à leur facturation et leur paiement, et finalement leur au client. La suppression d une opération dans le flot de contrôle décrivant la dimension comportementale d une interface est étudiée selon que l opération à supprimer se situe dans une composition conditionnelle ou dans une composition séquentielle. L évolution d une interface par ajout d opérations dans une séquence est également étudiée. Nous illustrons ci-après le problème posé par chacun de ces cas de figure. Une étude est en cours dans la perspective de compléter cette analyse et de couvrir toutes les situations possibles d évolution d une interface fournie.

86 RSTI - ISI 13/2008. Modèles, formalismes et outils Suppression d une opération dans une séquence : au centre de la figure 1 est décrit le diagramme d activités (dans la notation UML) de la dimension comportementale d un fragment de l interface requise d un client. Celle-ci a été implantée selon la version P fournie par le service, et est donnée à gauche de la figure 1, sous forme d un autre diagramme d activités. Le diagramme fourni à droite de la figure est celui de la version P déduite de P, où l opération correspondant au choix du mode de a été supprimée. Cette modification se traduit par la suppression des activités ModeLivraison et réponse. Il s en suit que les conversations initiées par des clients qui continuent d interagir avec le service selon P, échouent car l envoi du message ModeLivraison ne trouve pas de destinataire. Fournisseur interface fournie/version P transfert ModeLivraison réponse Client Interface requise transfert ModeLivraison réponse Fournisseur interface fournie/version P? transfert Figure 1. Suppression d une opération Suppression d une opération dans une alternative : la figure 2 décrit une phase du processus au cours de laquelle le service propose au client plusieurs choix dans une alternative. La suppression illustrée ici consiste à ne plus permettre l un des termes de l alternative. Dans la figure 2, le paiement en espèces n est plus possible dans la nouvelle version P de l interface fournie, ainsi, le message envoyé par le service client l ayant choisi provoquera systématiquement un échec. Fournisseur Client Fournisseur interface fournie/version P interface requise interface fournie/version P facture facture facture transfert chèque espèces espèces? transfert chèque? Figure 2. Suppression d un terme à une alternative Ajout d opérations dans une séquence : selon la nouvelle version P modélisée par le diagramme d activités donné à droite de la figure 3, le service fourni requiert de recevoir de la part de ses clients un message qui fixe le mode souhaité pour la. Un message indiquant le mode finalement applicable est retourné au client. Cette

Médiation de conversations de services 87 évolution est l inverse de celle illustrée dans la figure 1. Les clients dont l interface est décrite en termes de la version P du service ne sont pas en mesure de transmettre le message attendu, ce qui conduit à l échec des conversations qu ils initient. Fournisseur interface fournie/version P transfert Client Interface requise transfert Fournisseur interface fournie/version P transfert? ModeLivraison réponse Figure 3. Ajout d opérations dans une séquence L étude rapportée dans cet article vise à fournir une solution pour la détection des types d incompatibilité illustrés ci-avant ainsi que pour leur résolution. Nous en donnons les principes généraux dans la section qui suit. La modification d une opération peut être vue comme un ajout suivi d une suppression d opération ou inversement. 3. ArchiMed : un canevas multimédiateur Nous décrivons ici le principe de médiation à la base de notre approche (voir section 3.1). Puis, l architecture fonctionnelle du canevas pour la médiation est décrite dans la section 3.2. Ensuite, dans la section 3.3 nous montrons comment nous nous appuyons sur les techniques d automates pour modéliser l interface d un service selon sa dimension comportementale et pour formaliser les mécanismes introduits dans la section 3.2. Enfin, dans la section 3.4 nous discutons des aspects relatifs à la gestion de médiateurs multiples pour une même interface. 3.1. Principe général L idée principale de la médiation de la conversation entre deux services web, est que tout envoi ou réception de messages entre les deux interlocuteurs, doit passer par un tiers qui joue le rôle de médiateur (Altenhofen et al., 2005). En d autres termes, si un client envoie un message vers un fournisseur, le message est dans un premier temps reçu par le médiateur avant que ce dernier ne décide de le transmettre à son destinataire après traitement si nécessaire. Le rôle de ce médiateur est de garantir la cohérence des interactions entre le client et le fournisseur, c est-à-dire de réconcilier la conversation initiée par le client selon l interface qu il requiert avec celle que le fournisseur fournit.

88 RSTI - ISI 13/2008. Modèles, formalismes et outils Le médiateur que nous proposons résout les incompatibilités entre la nouvelle version de l interface fournie P et les interfaces requises des clients qui continuent à interagir avec le fournisseur en considérant une de ses versions antérieures. Nous nous limitons ici aux aspects comportementaux de ces interfaces. 3.2. Architecture fonctionnelle du canevas La figure 4 présente l architecture fonctionnelle du canevas ArchiMed. Les fonctions offertes s articulent en deux phases, selon qu elles sont exécutées à la conception d une nouvelle version d interface, ou à l exécution d une conversation initiée par un client. [Générateur de médiateurs] InterfaceFournie_P InterfaceFournie_P (3) (2) Simulation (4) (1) [Service Fournisseur] InterfaceFournie_P WSDL_P BPEL_P (12) (10) Sélection Détection (5) Résolution (6) [Médiateur] InterfaceFournie_Med WSDL_P BPEL_P (11) (9) (8) (7) [Service Client] InterfaceRequise_R WSDL BPEL Figure 4. Architecture fonctionnelle d ArchiMed La première phase est sous le contrôle du générateur de médiateurs (voir les étapes (1) à (6) dans la figure 4). Le générateur s appuie sur les versions P et P de l interface fournie du service fournisseur (voir (1) dans la figure 4). Sur la base des représentations formelles des versions P et P le module Simulation vérifie si la nouvelle interface P simule P (voir (2) et (3)). La formalisation est discutée section 3.3. Le résultat de ce calcul est transmis au module de détection d incompatibilités qui retourne les états sources d incompatibilités ainsi que leurs types d incompatibilités associés dans le cas où P ne simule pas P (voir (4)). Sur la base des incompatibilités détectées (voir (5)), un autre module les résoud en construisant et en déployant le médiateur correspondant (voir (6)). Ensuite, lorsqu un client initie une conversation avec le service (voir (7)), une première étape de sélection permet d étudier, sur la base de l analyse de l interface exposée par le client, la compatibilité de cette dernière avec la version courante P de l interface du service. Il peut en découler trois situations différentes : 1) l interface du client est conforme à la version actuelle de l interface fournie. Dans ce cas les interactions entre le client et le fournisseur ne transitent par aucun médiateur (voir (9) et (10)),

Médiation de conversations de services 89 2) l interface du client n est conforme, ni avec la version actuelle, ni avec aucune des versions précédentes. Il n existe donc aucun médiateur pour ce client. La conversation est interrompue dès son initiation car elle ne peut pas aboutir, 3) il existe une version conforme à l interface du client, et celle-ci est unique (ce résultat est démontré dans la section 3.4). Les interactions sont gérées par le médiateur associé (voir (9), (11) et (12)). 3.3. Modélisation du comportement des services Nous avons choisi d exprimer l interface comportementale d un service web par le biais d un système de transitions étiquetées (Labelled Transition Systems, LTS). De nombreuses autres approches s appuient sur cette représentation en automates (voir section 7). Il y avait d autres termes à l alternative, dont en particulier les réseaux de Petri. Nous ne discutons pas ce choix car cela est hors du champ de cet article. Un LTS est un automate qui peut être représenté par un graphe orienté où les nœuds désignent les états possibles d un système (avec un état initial) et les arcs désignent les transitions entre les états. Chaque arc est étiqueté par l événement dont l occurrence déclenche le passage de l état origine de la transition vers l état destination. Une condition (ou garde) sous forme d expression booléenne peut être associée à une transition et si cette condition est vérifiée, l état destination de la transition est atteint. Puisqu il s agit de modéliser l interface comportementale d un service, les transitions sont étiquetées par les messages émis et reçus. Une transition est déclenchée à l envoi ou à la réception du message et lorsque la condition associée, si elle est définie, est vérifiée. Les opérations internes sont elles aussi représentées par des transitions. Chaque état correspond à une des phases du processus. Des opérations de manipulation de données peuvent également être associées à un état pour modifier les valeurs des variables du contexte d une instance de processus (Wombacher et al., 2004; Pathak et al., 2006). Dans notre approche, certains états sont étiquetés par échec ou succès pour caractériser l issue (positive ou négative) de certaines opérations. La figure 5 illustre la représentation en LTS de la partie mode de du processus de l exemple introduit dans la section 2. Dans cet exemple, le client exprime son souhait quant au mode de la (express, différé, etc.). Le choix du mode de est contraint par exemple par le poids du colis à envoyer, il s en suit que le mode souhaité par le client peut ne pas être satisfait. >c:confirmer(msg) succès mode >c:livrer(listeart) <c:virement(cb,mnt) transfert <c:mode(m) mode >c:refus(msg) échec mode >c:livrer(listeart) Figure 5. LTS pour le choix du mode de

90 RSTI - ISI 13/2008. Modèles, formalismes et outils Nous l avons déjà souligné, l envoi de messages est à la base des interactions entre des services. Nous notons par >m (respectivement <m) l envoi (respectivement la réception) du message m. La réception d un message se traduit par l exécution d une ou de plusieurs opérations par le service qui le reçoit. Les opérations mentionnées ici, dites de communication, déclenchent d autres opérations dites internes implantées par des applications propriétaires. Chaque conversation entre le service et un client génère une instance de l automate (soit c dans la figure 5). Conformité d interfaces Les évolutions que nous considérons sont uniquement celles qui sont visibles par les clients. En particulier, nous ne nous intéressons pas aux modifications qui affectent les activités internes sans avoir de conséquences sur les activités de communications d un service. Pour comparer deux versions d interfaces, nous appliquons tout d abord aux LTSs correspondants un algorithme de réduction d automates par élimination des ɛ transitions (van Glabbeek et al., 1996). Considérant les opérations internes comme des ɛ transitions, seules les opérations de communication sont prises en compte (comportement observable (Bordeaux et al., 2004)). Après avoir réduit les interfaces aux envois et aux réceptions de messages, la simulation de P par P n est vérifiée que si toutes les opérations suivantes d un état courant de P sont reproduites dans les opérations suivantes de l état équivalent dans P. En d autres termes, si P inclut le comportement de P. En particulier, le cas d évolution qui nous intéresse est celui où P ne simule pas P. En effet, dans le cas où P simule P (noté P P ) alors toute interface requise R d un service client compatible avec P (noté R P ) reste compatible avec P. Soit R qui dénote l interface contraire obtenue en transformant les envois de messages en réceptions de messages et en transformant les réceptions de messages en envois de messages de R. Etant donné que R P alors R P (Bordeaux et al., 2004). Par transitivité de la relation de pré-ordre de la simulation (Clarke et al., 2001), il s en suit que R P (car R P et P P ). En conclusion, R est conforme à P (R P ). Ainsi, la détection et la résolution des incompatibilités ne sont nécessaires que lorsque P ne simule pas P. 3.4. Versions multiples d interface Dans notre approche, la conformité entre une interface requise d un client et une nouvelle version d une interface fournie est garantie par l introduction d un médiateur. Ainsi, dans le cas où une interface requise d un client C 1 est conforme avec une interface fournie P 1 et que P 1 évolue vers P 2, un médiateur M 1,2 est introduit pour garantir la conformité entre C 1 et la nouvelle version d interface fournie P 2. Cependant, si l interface fournie P 2 évolue vers P 3, le médiateur M 1,2 n est plus nécessaire car il est remplacé par un autre médiateur M 1,3 qui garantit la conformité entre l interface requise C 1 et la nouvelle version d interface fournie P 3. Pour l interface requise d un

Médiation de conversations de services 91 nouveau client C 2 qui était conforme à la précédente version d interface fournie P 2, un autre médiateur M 2,3 est généré pour garantir la conformité entre C 2 est la nouvelle version P 3. Ce mécanisme de génération et de suppression de médiateur peut être généralisé à des évolutions d une interface fournie vers N versions (voir Figure 6). P1 P2 P3 Pn 1 Pn M1,n M2,n M3,n Mn 1,n Légende : C1 C2 C3 Cn 1 Pi : i ème version de P Ci : i ème interface requise Mi,j : médiateur entre la i ème et la j ème version Figure 6. Génération de médiateurs pour des versions multiples Au moment de la création de la nième version P n, de l interface fournie, le client d interface requise C 1 (qui était conforme à l interface fournie précédente P n 1 par le biais du médiateur M 1,n 1 ) est conforme avec cette nouvelle version grâce à un nouveau médiateur M 1,n. Le précédent médiateur (M 1,n 1 ) n étant plus utile, il est supprimé. Pour garantir la conformité des N 1 interfaces requises des clients avec la nouvelle version P n, les n 2 médiateurs qui garantissaient la conformité avec la précédente version P n 1 sont supprimés pour être remplacés par n 1 nouveaux médiateurs qui assurent la conformité des interfaces requises avec la nouvelle version P n. Si un médiateur est conforme avec une interface requise alors il est unique. La démonstration de ce résultat est donnée ci-après. Un raisonnement par l absurde est utilisé où l hypothèse de l existence de deux médiateurs distincts conformes à une même interface requise est prise. Hypothèses : (1) : P i, P j, P r des LTSs telle que i < j < r { P r est la version actuelle. } (2) : P i P j P j P r P i P r (3) : M i,r un médiateur entre P i et P r et M j,r un médiateur entre P j et P r (4) : R une interface requise telle que R M i,r R M j,r { Hypothèse inverse. }

92 RSTI - ISI 13/2008. Modèles, formalismes et outils Construction de la contradiction : (5) : (3) M i,r P i P r M j,r P j P r { D après la définition du comportement d un médiateur qui inclut les comportements des deux versions. } (6) : (4) R M i,r R M j,r (7) : (5) (6) R P i P r R P j P r { Par transitivité de la relation de simulation et de la relation d équivalence. } (8) : (7) R P i R P j P i R P j P i R P j P j R P i Ceci contredit l hypothèse (2) : P i P j. 4. Détection et résolution des incompatibilités Dans ce travail, nous étudions les incompatibilités engendrées par les évolutions des interfaces fournies d une version antérieure P à une nouvelle version P. Afin de détecter les incompatibilités, un langage à base d expressions qui manipule des représentations en automates des interfaces est introduit (voir section 4.1). L algorithme de détection des incompatibilités est présenté dans la section 4.2. Enfin, le principe de résolution est présenté dans la section 4.3. 4.1. Langage pour la formalisation des types d incompatibilité La détection des incompatibilités entre les versions d un LTS s appuie sur des expressions d un langage qui formalisent les types d incompatibilité. L utilisation d un tel langage est fondée sur l hypothèse suivante : si T est l ensemble des types d incompatibilité et L est l ensemble des phrases du langage alors : t T, ϕ L : ϕ caractérise t L évaluation de ces expressions prend en paramètres deux LTSs (P et P ) et deux états (s de P et s de P ). Une expression est évaluée à vraie si le sous-automate de P d état initial s et le sous-automate de P d état initial s vérifient les conditions modélisées dans l expression. Ceci traduit le fait que le type d incompatibilité associée à cette expression est détecté au couple d états (s,s ). Un LTS est décrit par le tuple (S, L, T, s 0, F ) où : S est l ensemble fini des états, L est l ensemble fini des événements (actions), T est la fonction de transition, s 0 est l état initial avec s 0 S et F est l ensemble des états finaux avec F S. La fonction de transition T associe à un état source s 1 S et à un événement l 1 L, un état destination s 2 S. Les deux versions d interfaces fournies sont définies par deux LTSs P et P qui sont respectivement décrits par (S, T, s 0, F, L) et (S, T, s 0, F, L ).

Médiation de conversations de services 93 Les opérateurs de base du langage que nous proposons sont 2 (les exemples s appuient sur le LTS donné dans la figure 5) : s : ensemble des transitions sortantes de l état s (par exemple, modelivraison = {>c :confirmer(msg), >c :refus(msg) }), s : ensemble des transitions entrantes dans l état s (par exemple, modelivraison= {>c :mode(m)}), t : état cible de la transition t (par exemple, <c :mode(m) =modelivraison), t : état source de la transition t (par exemple, <c :mode(m)=transfert). L opérateur (respectivement ) est généralisé aux ensembles de transitions (respectivement d états). Par exemple, si T est un ensemble de transitions : T = n i=1 {t i} alors T = n i=1 {t i }. Les opérateurs ensemblistes sont introduits pour comparer les LTSs. En voici quelques-uns : s : cardinalité de l ensemble des transitions sortantes de s, s s : différence ensembliste entre les transitions sortantes de s et les transitions sortantes de s, s s : les transitions sortantes de s sont incluses dans les transitions sortantes de s. Des opérateurs logiques (,, etc.) sont introduits pour construire des expressions booléenes. D autres opérateurs de typage permettent de construire des ensembles de transitions ou d états qui sont dans un type donné. Par exemple, l opérateur Receptions appliqué à un ensemble de transitions retourne un sous-ensemble des transitions qui sont associées à des réceptions de messages. D autres opérateurs sont introduits dans la section 5 où des expressions de notre langage permettent de détecter les cas d incompatibilités. Des exemples sont donnés plus loin (voir les sections 5.1, 5.2 et 5.3). 4.2. Algorithme de détection des incompatibilités L algorithme présenté dans la figure 7 permet de retrouver tous les types d incompatibilité représentés par un ensemble IE d expressions, entre deux versions Pi et Pj de l interface d un service (Pi antérieure à Pj). L algorithme récursif est appliqué aux états initiaux <si0, sj0> des LTSs qui sont respectivement associés à Pi et à Pj. 2. Ces opérateurs sont inspirés des travaux présentés dans (Djikman et al., 2004).

94 RSTI - ISI 13/2008. Modèles, formalismes et outils Cet algorithme retourne un ensemble de triplets dont le type est défini par : type Expression { une expression e de type Expression est une phrase du langage défini plus haut. } type Etat { un état s de type Etat est défini dans un automate. } type tripletres = < typei : Expression, s1 : État, s2 : État > { si tr est de type tripletres alors tr.typei est l expression qui modélise l incompatibilité détectée au niveau du couple d états < tr.s1, tr.s2 > } 1 Détection (si : État ; Pi : LTS ; sj : État ; Pj : LTS ) : { tripletres } 2 { Détection(si,Pi,sj,Pj) : la détection des incompatibilités est réalisée sur les deux automates Pi initialisé à l état si et Pj initialisé à l état sj. Le résultat retourné est un ensemble de triplets tripletres. } 3 ensres : {tripletres} { variable résultat } 4 P1,P2 : LTS ; s1,s2 : État ; ensres1 : {tripletres} { variables intermédiaires } 5 ensce : {coupleetats} { ensemble de couple d états à explorer } 6 IE : {IncompExp} 7 tex : IncompExp 8 ensres 9 ensce 10 IE ChargerIE() 11 Si si = alors { cas général } 12 Pour tout tex IE 13 ensres1 Evaluer(tEx,si,Pi,sj,Pj) 14 ensres ensres1 ensres 15 Si ensres1 alors 16 ensce ensce Explorer(tEx,si,Pi,sj,Pj) 17 Pour tout c ensce 18 P1 finlts(pi,c.s1) ; P2 finlts(pj,c.s2) 19 ensres ensres Détection(c.s1,P1,c.s2,P2) 20 Pour tout t si sj 21 P1 finlts(pi,t ) ; P2 finlts(pj,t ) 22 ensres ensres Détection(t,P1, t, P2) 23 Retourner(ensRes) Figure 7. Algorithme de détection des incompatibilités L ensemble IS est chargé à partir d une base de données (voir ligne 10 de l algorithme). A l état courant si, la détection n est pertinente que dans le cas où si possède des transitions sortantes pour les comparer aux transitions sortantes de l état sj (voir ligne 11). C est le cas général de l algorithme récursif. Dans le cas particulier où l ensemble des transitions sortantes de si est vide aucune action n est exécutée. Les expressions qui modélisent les incompatibilités (chargées dans IE) sont testées sur les LTSs courants (P i et P j) et leurs états intiaux (respectivement si et sj) grâce à la fonction d évaluation (voir lignes 12 et 13). Cette fonction d évaluation est définie comme suit :

Médiation de conversations de services 95 Evaluer (tex : Expression,si : État, Pi : LTS,sj : État, Pj : LTS) : {tripletres} { Evaluer (tex, si, Pi, sj, Pj) est un singleton contenant un tripleres de valeur < tex, si, sj > si l expression tex est évaluée à vrai sur les états si et sj respectivement dans les automates Pi et Pj. Le singleton est l ensemble vide si l expression est évaluée à faux. } L évaluation des expressions de détection sur le couple d états courant <si,sj> retourne un résultat intermédiaire qui sera cumulé au résultat final (voir ligne 14). Pour déduire les couples d états et les sous-automates associés à examiner, une fonction d exploration est introduite (voir lignes 15 et 16). Pour chaque type d incompatibilité est associée une stratégie d exploration qui détermine les couples d états à passer en paramètres lors des appels récursifs. Par exemple, lors de la suppression d opérations dans une séquence, le couple d états à examiner est l état descendant de si dont les transitions sortantes sont incluses dans les transitions sortantes de sj et l état sj. La fonction d exploration est définie comme suit : type coupleetat = < s1 : État, s2 : État > Explorer (I : Expression, si : État, Pi : LTS, sj : État, Pj : LTS) : {coupleetats} { Explorer (I, si, Pi, sj, Pj) est un ensemble de couples d états à partir desquels seront calculés les sous-automates à prendre en compte lors de l appel récursif à la fonction de détection. } La récursivité s applique à chaque couple de l ensemble résultat de l exploration (voir ligne 17). Pour chacun des états c.s1 et c.s2, est calculé un sous-lts retourné par la fonction finlt S qui donne le reste d un LTS (voir ligne 18). Cette fonction finlts(p : LTS, s : Etat) : LTS prend en paramètre un LTS P et un de ses états s puis génère le sous-lts de P commençant dans P à l état s. L appel récursif de la fonction de détection est ainsi appliqué aux résultats des fins de LTSs (voir ligne 19). Les sous-automates des états cibles des transitions en commun à si et sj sont eux aussi explorés par la fonction de détection (voir lignes 20, 21 et 22). 4.3. Principe de résolution des incompatibilités La résolution des incompatibilités est basée sur le résultat de la détection de cellesci. L objectif de cette phase est de construire le LTS du médiateur. Le comportement du médiateur doit simuler celui de la version actuelle de l interface fournie P donc le LTS du médiateur doit contenir les mêmes états et les mêmes transitions que le LTS de P. Afin que le comportement du médiateur résolve les incompatibilités son LTS est modifié par des ajouts d états et de transitions selon chaque type d incompatibilité détecté à des endroits précis du LTS du médiateur (voir par exemple les figures 8, 9 et 10). Des expressions de résolution associées à chaque type d incompatibilité sont utilisées pour déterminer les états et les transitions à ajouter. Ce mécanisme de résolution est similaire à celui de la détection et pour des raisons de limitation d espace nous ne le détaillons pas ici.

96 RSTI - ISI 13/2008. Modèles, formalismes et outils 5. Illustration Dans cette section, afin d étayer notre propos sur l approche que nous proposons, quelques cas de détection et de résolution d incompatibilité sont présentés. Les types d incompatibilités traités sont la suppression d opérations et l ajout d opérations. La suppression d opérations se décline en deux sous-types d incompatibilité, la suppression d opérations dans une séquence (voir la section 5.1) et la suppression d un choix d opération dans une alternative (voir la section 5.2). L ajout d opérations dans une séquence est détaillé dans la section 5.3. 5.1. Cas de suppression d opérations dans une séquence Quand une opération (ou une suite d opérations) est supprimée de l interface fournie, le service client ne peut plus l utiliser. Dans ce cas, le médiateur simule l existence de cette opération qui n est pas transmise au service. Le médiateur garde dans son interface cette opération. Dans le cas de la suppression d une suite d opérations, le médiateur choisit le chemin d échec (illustré en gras dans la figure 8) pour arriver dans l état où les opérations suivantes dans les deux versions d interfaces fournies sont les mêmes. Le chemin d échec désigne une suite de transitions et d états qui contient un état d échec et par conséquent un envoi de message de refus. <c:virement(cb,mnt) transfert <c:mode(m) mode >c:refus(msg) échec mode >c:livrer(listeart) Légende : chemin ajouté à P >c:livrer(listeart) Figure 8. LTS du médiateur pour la suppression du mode de Dans le scénario, le fournisseur dans sa version P expose à ses clients une opération de choix de mode de (voir figure 5). Cependant, après évolution vers une nouvelle interface P, cette opération n est plus offerte. Ainsi, le médiateur doit avoir une interface, comme illustrée dans la figure 8, qui prend en compte le mode de. Mais, au lieu de recevoir le résultat de cette opération, c est un refus systématique qui est renvoyé au client. Dans le cas où l opération supprimée ne renvoie qu un message résultat, le médiateur continue à renvoyer au client ce type de message mais vide d information, la structure est conforme mais le contenu n est pas renseigné. La détection de cette forme d évolution de l interface fournie se fait en parcourant les états de P et de P. L objectif est de comparer les transitions sortantes des états courants s et s respectivement de P et P grâce à l expression booléenne : s (s = (s s s (((s ) ) ) s )) La suppression d une opération est détectée dans le cas où les transitions sortantes de s existent (s n est pas un état final, exprimé par s = ) et où les transitions

Médiation de conversations de services 97 sortantes de s n existent pas (s est un état final, exprimé par s = ). Une autre possibilité de suppression d opération est détectée dans le cas où les transitions sortantes des états successeurs de s ne sont pas incluses dans les transitions sortantes de s (exprimé par s s ). Dans ce cas, les transitions sortantes des états successeurs de s sont incluses dans les transitions sortantes de s (exprimé par (((s ) ) ) s ). La généralisation au cas de détection de suppression d une suite d opérations d un processus peut être formalisée par l expression booléenne qui suit : s (s = (s s s IncEt(s, s )) F aux s = avec : IncEt(s, s ) = V rai s s (s ) i=1 IncEt((((s ) ) i ), s ) sinon L idée consiste à vérifier s il existe au moins un état descendant de s dont les transitions sortantes sont incluses dans les transitions sortantes de s. Cette vérification s appuie sur la fonction d inclusion étendue IncEt(s, s ). Si une telle incompatibilité est relevée pour un couple d état <s, s >, un chemin formé d une suite de transitions et d états est calculé à partir de s dans P et qui s arrête dans l état qui contient des transitions sortantes incluses dans s. Puis, ce chemin est ajouté dans P à partir de s et prend fin dans les états (s ). 5.2. Suppression d un choix d opération dans une alternative Dans une nouvelle interface fournie qui ne prend plus en compte un choix d opération quelconque dans une alternative, les incompatibilités seront générées avec les interfaces clientes qui continuent à solliciter cette opération supprimée. Pour y remédier le médiateur est défini avec une interface comportementale qui contient ce choix d opération mais dont la réponse est toujours un message de refus. Ainsi, le client aura la possibilité (s il l a prévu dans son interface requise) de choisir une autre opération. Comme illustré dans la figure 9, le client qui effectue un paiement en espèces, reçoit un message de refus tant qu il ne choisit pas un paiement par transfert ou par chèque. Ce type d évolution peut être détecté en s appuyant sur la conjonction des deux formules booléennes qui suivent : 1 : Receptions(s ) 2 2 : Receptions(s ) Receptions(s ) 1 D après ces formules, la détection des suppressions des choix dans une alternative consiste à comparer les transitions sortantes de s qui contiennent des réceptions de messages (exprimé par Receptions(s ) 2) et à vérifier si elles existent toujours parmi les transitions sortantes de s. Dans l expression booléenne, ceci se traduit par le fait que la différence ensembliste Receptions(s ) Receptions(s ) a une cardinalité au moins égale à un. L interface du médiateur est construite en ajoutant

98 RSTI - ISI 13/2008. Modèles, formalismes et outils à P un chemin de retour sur s. Chaque chemin de retour correspond à un choix supprimé et renvoie un message de refus au client. Une garde est ajoutée à ce chemin et porte sur le nombre d essais accordés pour solliciter ces opérations qui n existent plus (par exemple, [essai<=3] voir figure 9). <c:virement(cb,mnt) [délai <= t] transfert >c:livrer(listeart) >c:facturer(listeart,mnt) Légende : chemin ajouté à P facturation >c:refus(msg) [délai > t] <c:deposerchq(cb,mnt) [délai <= t] [essai <= 3] >c:refus(msg) chèque <c:deposeresp(cb,mnt) échec paiement >c:livrer(listeart) échec commande Figure 9. LTS du médiateur pour la suppression de l alternative espèce 5.3. Ajout d opérations dans une séquence Une interface fournie peut évoluer par ajout d une ou de plusieurs opérations dans une séquence. Ces nouvelles opérations peuvent être ajoutées pour solliciter des informations complémentaires (propriétaires du client) ou bien pour que le client choisit de nouvelles options offertes par le fournisseurs. Dans la situation d ajout d une opération qui sollicite des informations propriétaires au client, le médiateur ne peut simuler une telle opération que si le client définit une interface qui expose des opérations de consultation de ces informations. En pratique, les clients n exposent de telles opérations qu à leurs partenaires ce qui est loin d être le cas de toutes les applications clientes dans le web. Pour l ajout d une opération qui sollicite le choix du client dans une liste, le médiateur peut la simuler car il détient ces informations et peut ainsi choisir des informations par défaut. <c:virement(cb,mnt) transfert <c:mode(m) >c:confirmer(msg) mode succès mode >c:livrer(listeart) >c:livrer(listeart) Légende : chemin ajouté à P >c:livrer(listeart) >c:refus(msg) échec mode Figure 10. LTS du médiateur pour l ajout du mode de Dans notre exemple, l interface du service fournisseur peut évoluer d une interface qui enchaîne les opérations de transfert et de à une interface qui introduit entre ces deux opérations de nouvelles opérations pour le choix du mode de. Dans la figure 10, le médiateur va résoudre les incompatibilités, pour les interfaces requises qui continuent d interagir selon l ancienne version, en simulant les opérations

Médiation de conversations de services 99 d envoi du choix de mode de livraion et de réception du message de réponse du service fournisseur dans sa version actuelle. Ces échanges sont masqués au client qui au final ne va recevoir que le message de qu il attend conformement à son interface requise. L ajout d une opération peut être détecté si la condition suivante est vérifiée : t s : t / s t ((s ) ) Ajouter une opération dans une séquence d opérations revient à introduire une nouvelle transition qui est étiquetée par la signature de l opération ajoutée. D après l expression, pour détecter cet ajout il suffit de vérifier s il existe une transition parmi les transitions sortantes de s (voir t s ) qui n apparaît pas dans les transitions sortantes de s (voir t / s ). Cette transition apparaît dans les transitions sortantes des états suivants de s (voir t ((s ) ) ). En cas d ajout de plusieurs opérations dans une séquence, la généralisation de la formule de détection est donnée comme suit : t s : t / s AppEt(t, s ) F aux s = avec : AppEt(t, s ) = V rai t s (s ) i=1 AppEt(t, (((s ) ) i ) ) sinon Si plusieurs opérations sont ajoutées, la transition sortante de s n apparaît que dans les transitions sortantes des états descendants de s. Pour vérifier cette condition, une fonction dite appartenance étendue (voir AppEt) est introduite est permet de vérifier si une transition appartient ou non aux transitions sortantes des états descendants d un état. 6. Mise en œuvre de la solution Dans cette section, sont présentés les différents composants de l architecture logicielle (voir section 6.1) ainsi que des détails d implantation pour la mise en œuvre de la solution (voir section 6.2). 6.1. Architecture logicielle Le canevas ArchiMed se décline en trois principaux modules : le générateur de médiateurs, le compilateur et les médiateurs (voir la figure 11). Le générateur de médiateurs s appuie sur une base de données qui contient un historique de toutes les versions de l interface fournie (voir [Génération]). Ces versions d interface sont stockées sous forme de LTSs pour être comparées à la dernière version de l interface fournie. Lors de la comparaison, la détection des incompatibilités est réalisée en sollicitant le compilateur qui évalue les expressions associées à chaque type d incompatibilité. Si

100 RSTI - ISI 13/2008. Modèles, formalismes et outils d autres cas d incompatibilités peuvent être représentés par de nouvelles expressions, ces expressions ainsi que leur type d incompatibilité associé sont ajoutés à la base et seront automatiquement pris en compte lors de la génération des médiateurs. Expressions et types Compilateur Générateur de médiateurs Service fourni Médiateurs Protail de médiation Services clients LTSs des versions Contextes des instances [Génération] [Déploiement] Figure 11. Architecture du canevas ArchiMed Après avoir résolu les incompatibilités, les médiateurs qui assurent la conformité entre les différentes interfaces requises et la nouvelle interface fournie sont déployés par le générateur de médiateurs (voir [Déploiement]). Lorsqu un client initie une conversation, le portail de médiation vérifie la conformité de l interface requise par ce client et détermine si un médiateur est nécessaire. Dans le cas où la conformité n est pas garantie (ni par un médiateur ni par le service actuel), le portail de médiation interrompt la conversation avec le client dès son initialisation car les incompatibilités ne pourront pas être résolues. Le contexte associé à chaque instance de processus initiée par un client est sauvegardé dans une base de données. 6.2. Détails d implantation La représentation des automates La représentation des automates et les opérations associées s appuie sur le standard, SCXML 3 (State Chart XML) à base d XML. Afin de rendre exécutables des automates représentés en SCXML, le groupe Apache propose une API Java : Commons SCXML 4. Ainsi, en partant d une représentation XML d un automate, l API interprète le document pour initialiser une classe qui est le moteur d exécution de l automate. Ce moteur offre quelques primitives pour l exécution de l automate : déclencher une transition, vérifier si un état est final ou pas, etc. 3. http ://www.w3.org/tr/scxml/. 4. http ://commons.apache.org/scxml/.

Médiation de conversations de services 101 Pour adapter les représentations d automate SCXML à notre définition des LTSs, nous avons ajouté des étiquettes d envois et de réceptions de messages ainsi que l identifiant de l instance du LTS, dans les attributs événements des transitions. Comme illustré ci-après, dans l état confirmation, la transition est associée à un événement composé de trois parties. L identifiant de la conversation est dans ce cas idc01. La deuxième partie envoi désigne que l opération Confirm est une opération d envoi. <state id="confirmation"> <transition event="idc01.envoi.confirm" target="facture"/> </state> En d autres termes, lorsque l automate atteint l état confirmation, le moteur d exécution de l automate déclenche un événement d envoi de confirmation dans la conversation identifiée par idc01. Après le déclenchement de l événement, l état courant de l automate passe à l état cible de la transition qui est facture. Dans le cas de processus de longue durée, le document SCXML décrivant le contexte d exécution de l instance de conversation en cours d exécution peut être généré à partir du moteur d exécution. Ce document peut être ainsi sauvegardé dans une base de données décrivant le contexte d exécution qui peut être rechargé au moment opportun pour reprendre l exécution. Le compilateur du langage d expression Afin d interpréter et d évaluer les expressions du langage de détection des incompatibilités, nous avons développé un compilateur en Java. Dans le projet javacc 5 (Java Compiler Compiler) un générateur d analyseur lexical et syntaxique est mis au point et permet également la construction d arbres de dérivation grâce à un autre outil JJTree inclus dans javacc. L analyseur lexical et syntaxique du langage est réalisé à partir de la grammaire du langage en BNF. L analyse lexicale d une expression du langage produit un arbre de dérivation qui est évalué dans la phase d analyse sémantique. L évaluation des opérateurs est faite en les traduisant par l exécution des actions primitives définies pour les classes SCXML qui désignent les LTSs considérés. Voici un exemple d expression de détection de l incompatibilité de l ajout d opérations dans une séquence : Exists t IN TOut(si) / NOT t IN TOut(sj) AND EX IN(t, TOut(sj) ) Dans cette expression, TOut(si) désigne les transitions sortantes de l état si et EX IN() désigne l appartenance étendue. L opérateur IN désigne l appartenance d un élément à un ensemble. La négation d une expression est exprimée par l opérateur NOT. 5. https ://javacc.dev.java.net/.

102 RSTI - ISI 13/2008. Modèles, formalismes et outils 7. Etude bibliographique La description comportementale des services web s appuie essentiellement sur des standards tels que WSCI (Peltz, 2003) et BPEL (Wohed et al., 2003). La plupart des travaux qui traitent des incompatibilités comportementales proposent des solutions pour le calcul d équivalence et de similarité entre interfaces fournies et requises au moment de la conception des services. En partant des descriptions BPEL ou WSCI des interfaces, certaines approches proposent de générer des représentations formelles à base d automates (voir par exemple (Foster et al., 2003; Bordeaux et al., 2004; Pathak et al., 2006; Ponge, 2006)). Ces approches à base d automates proposent des outils de conception pour la composition de services. Cette conception est guidée par la détection des incompatibilités comportementales qui sont signalées au concepteur qui doit les résoudre de lui-même. Une fois la compatibilité entre les différents partenaires de la composition garantie, le nouveau service est déployé. Dans les approches à base de réseaux de Petri (Chrzastowski-Wachtel et al., 2003; Djikman et al., 2004; Martens et al., 2006) les algorithmes de bisimilarité sont utilisés pour détecter les incompatibilités comportementales entre l interface fournie par le service et celle attendue par le client. En cas d incompatibilité, une trace des erreurs est retournée au concepteur afin qu il réajuste la définition du comportement. Ces approches ne traitent pas la situation où, suite à une modification de l interface fournie par le service, celle-ci n est plus compatible avec celle requise par ses clients. De ce fait, le service fournisseur aussi bien que ses partenaires doivent adapter leurs interfaces comportementales à chaque nouvelle modification. Dans d autres approches, les incompatibilités comportementales résolues sont déduites des incompatibilités structurelles qui peuvent se produire car les messages reçus ou envoyés n ont pas la structure attendue (voir par exemple (Schmidt et al., 2002; Benatallah et al., 2005; Dumas et al., 2006)). La plupart de ces travaux proposent des adaptateurs qui s appuient sur des outils de transformation de données tels que Xpath, XQuery, XSLT. Les approches étudient les incompatibilités structurelles induites par les différents modes d envois et de réceptions des messages. Les adaptateurs sont construits de manière semi-automatique en se basant sur des patrons d incompatibilité identifiés ou en utilisant des opérateurs d adaptation. Parmi ces patrons d incompatibilités structurelles, certains ont une influence sur le comportement, comme par exemple l envoi ou la réception de messages superflus, des envois multiples versus une réception unique, un envoi unique versus des réceptions multiples. Dans une optique qui se rapproche des approches à base d adaptateurs, les approches à base de médiateurs (on parle de patrons de médiation dans (Altenhofen et al., 2005)), suggèrent la définition de fournisseurs virtuels qui transforment la structure des messages envoyés et reçus. Cependant, sur le plan comportemental ces propositions se limitent aux cas d opérations optionnelles qui n influent pas sur la logique métier du service. L adaptation des interfaces est faite à la conception. Les incompatibilités produites à la suite des évolutions des interfaces obligent le concepteur du service à redéfinir les adaptateurs à chaque évolution et pour chaque client. Contrairement à ArchiMed, ces travaux n offrent aucun mécanisme de détection automatique des incompatibilités.