Institut de la francophonie pour l’informatique Rapport du stage de fin d’´etudes Mod´ elisation des services dans le cadre de la mobilit´ e R´ealis´e par : Do Manh Ha promotion Responsables : Fabien Dagnat Julien Mallet Hanoi 2005 Remerciement Je tiens a` remercier les profresseurs a` l’intitut de la francophonie pour l’informatique (IFI), o` u je pr´epare mon DEA J’addresse mes remercients les plus sinc`eres a` Fabien Dagnat et Julien Mallet du ´ d´epartement informatique de l’Ecole Normale Sup´erieure des T´elescommunications de Bretgane, d’avoir encadr´e pour ce travail Je remercie les professeurs, et les membres du d´epartement informatique, de MAISEL, ´ de RESEL de l’Ecole Normale Sup´erieure des T´elescommunication de Bretgane pour leurs aides pendants les jours que je suis a` Brest Je remercie les vietnammiens a` Brest : Nam, Minh, madame Huong pour leurs renseignements, leurs aides R´esum´e Les terminaux mobiles sont apparus et deviennent populaires aujourd’hui grˆace a` leurs pratiques Parall`element avec cet apparition, c’est les applications sur ces terminaux A cause de la caract´eristique du terminal mobile : portabilit´e, bas de performance les applications sur les terminaux mobiles (services mobiles) face aux fr´equentes changements de leurs contextes d’ex´ecution Donc les services mobiles doivent adapter a` ces changements C’est la raison pour laquelle une architecture avec une couche interm´ediaire est utilis´ee Dans ce rapport, en utilisant cet architecture, je pr´esente notre approche pour la description et pour la composition des services en basant la notion de l’automate Abstract Terminal mobiles appeared and became more popular due to its benifit and since the application based on that terminal mobiles have developed Because of the terminal mobiles ’specific characteristic, the service mobiles have faced to the frequent change of the execution context So these services must have capacity to adapt to that change For this reason, an architecture with an intermidiate layer is used In this report, by using this architecture and basing on the notion of the automat, I present our approach for the description and for the composition of these services Table des mati` eres Introduction 1.1 Contexte du travail 1.2 Sujet d´etaill´e 1.3 Le plan du rapport ´ Etat de l’art 2.1 Introduction g´en´erale 2.2 Survol du service composite 2.2.1 Composition de services 2.2.2 Description de service 2.2.3 D´ecouverte, Choix de service 2.3 Mod`eles existants 2.3.1 Web service 2.3.2 eFlow 2.3.3 EJB 2.3.4 JINI 2.3.5 SWORD 2.4 S´ecurit´e 2.5 Performance 2.6 Conclusion Mod` ele de description de services 3.1 Introduction d´etaill´e du stage 3.2 Automate 3.2.1 Le concept de l’automate 3.2.2 Automate et l’ordre d’invocation de 3.3 Mod`ele propos´e 3.3.1 Transitions 3.3.2 Conditions 3.3.3 Actions 3.3.4 Fonctions 3.3.5 Corr´elation dans un service 3.4 G´en´eration du connecteur 3.4.1 La premi`ere approche 3.4.2 La deuxi`eme approche fonctions dans un service 4 6 6 7 10 11 12 13 13 13 15 15 16 16 17 19 19 20 20 21 21 22 22 23 ` TABLE DES MATIERES 3.5 3.6 Probl`emes et solutions 3.5.1 Back-tracking 3.5.2 Typage 3.5.3 Exceptions 3.5.4 Non d´eterministe 3.5.5 Boucle infinie Discutions Composition de services 4.1 Introduction 4.2 Synchronisation entre les services 4.2.1 Le besoin du langage de la requˆete 4.2.2 Description la synchronisation 4.3 Compositions des services 4.3.1 Algorimthme de composition des automate 4.3.2 Utilisation de cet algorithme dans la composition des services 4.4 Conclusion 25 25 25 25 26 26 26 27 27 27 27 28 28 28 29 31 Conclusion, perspectives 32 Annexe 33 A Dot langage 33 Table des figures 2.1 2.2 2.3 Architecture du Web service Mod`ele eFlow Achitecture de EJB 11 3.1 3.2 3.3 3.4 3.5 3.6 3.7 Architecture propos´ee par GAKHAR exemple exemple Mod`ele propos´e Une transition premi`ere approche Exemple 4.1 4.2 4.3 Exemple : Service de traduction Exemple : Service d’achat Exemple : Composite service 15 17 18 19 20 23 23 30 30 30 A.1 Imgage g´en´er´ee par l’utile graphviz 34 Chapitre Introduction 1.1 Contexte du travail Le projet se d´eroule dans l’´equipe CAMA1 du d´epartement d’informatique de l’ENST Bretagne Cette ´equipe d´eveloppe des recherches dans le domaine ´emergent de l’informatique nomade La recherche envisage de proposer une couche interm´ediaire (gestionaire des services), qui permet d’adapter une application mobile aux fr´equentes changements de son contexte d’ex´ecution 1.2 Sujet d´ etaill´ e Les probl´ematiques associ´ees a` ce domaine de recherche apparaissent dans de nombreuses applications du fait de la multiplication de l’utilisation de terminaux mobiles qui changent fr´equemment de contexte d’ex´ecution Par exemple, si un utilisateur visualise une image haute d´efinition sur son ´ecran de bureau et sort du bˆatiment, il peut ˆetre n´ecessaire de passer a` une d´efinition inf´erieure pour la regader sur l’´ecran d’un PDA De plus la composition de services doit ˆetre effectu´ee en prenant en compte les contraintes de qualit´e de service des applications, qu’elles soient fonctionnelles ou non fontionnelles (s´ecurit´e, performance, fiabilit´e ou passage l’´echelle) Dans l’exemple pr´ec´edent, la consultation sur PDA peut requ´erir la prise en compte de la r´edution de bande de passante et la n´ecessit´e d’augmenter la s´ecurit´e des communications Il existe des produits industriels et des standards qui d´ecrivent la notion de service de composant (p.ex EJB, Web service) qui sont associ´es a` des syst`emes de d´ecouverte et d’utilisation de service permetant leur int´egration dynamique (p.ex JINI, UnPN, UDDI) Toutefois ces approches pramatiques sont, a` ce jour, limit´ees La description des services n’int`egre pas (ou peu) leur s´emantique, et ne permet donc pas de garantir une int´egration correcte respectant des contraintes non fonctionnelles De plus, elles ont ´et´e con¸cues pour des environnement statiques ferm´es ce qui rend difficile l’adaption dynamique des services au contexte d’ex´ecution Donc, le travail de ce stage se d´ecompose en tˆache de mani`ere suivante : Composants pour Architectures Mobiles Adaptables 1.3 LE PLAN DU RAPPORT Etudier les diff´erents mod`eles qui permettent de d´ecrire un service, cette ´etude concentr´ee sur de services mobiles et sur quelques propri´et´es non fonctionelles Proposer un mod`ele qui permet de composer dynamiquement des services Valider les approches retenues en ´etudiant des propri´et´es de la s´ecurit´e et de la performance sur un type d’application donn´e R´ediger le rapport final du stage 1.3 Le plan du rapport Ce rapport se compose de parties et un annexe Une petite introduction du travail de stage est pr´esent´ee dans la partie 1, la partie deux est une ´etude sur des mod`eles de la description et de la composition des services La partie et partie pr´esentent notre mod`ele de la description des services, l’utilisation et la composition des services d´ecrits par ce mod`ele La conclusion et perspectives sont dans la partie 5 Chapitre ´ Etat de l’art 2.1 Introduction g´ en´ erale Aujourd’hui, les utilisateurs peuvent acc´eder a` l’internet, donc a` des services, a` l’aide de leur terminal mobile (PDA, t´el´ephone portable ) ´equip´e d’interfaces de communication sans fil Ils peuvent consulter la temp´erature, les taux d’´echange Les services qui rendent accessibles depuis ces terminaux sont de plus en plus complexe comme les achats sur l’internet, les consultation de service de m´edecin A cause de la portabilit´e et de la mobilit´e, les terminaux mobiles ont des limites comme : la capacit´e de la batterie, la capacit´e de stockage ou ils subissent des contraintes comme : le changement fr´equent de bande de passante, ou la d´econnexion Toutes ces caract´eristiques peuvent causer des probl`emes de maintient de la qualit´e du service Donc les services doivent tenir compte des contraintes venues des terminaux mobiles D’autre part, les services aujourd’hui qui sont con¸cus pour un environnement statique, pour des syst`emes ferm´es, ne sont pas convenable pour un environnement mobile Dans les parties suivantes, une ´etude sur des produits, des mod`eles existants est pr´esent´ee suivi d’un survol du service composite 2.2 Survol du service composite Un service composite est une composition de plusieurs services existants afin d’obtenir un service plus complexe qui peut r´epondre aux besoinxs de l’usager Le service composite n’est pas une nouvelle notion mais avec l’´emergence des Web services et la capacit´e de fournir les services via l’internet, la tendance est aux services 2.2.1 Composition de services Il y a plusieurs fa¸cons de classifier la composition de services, dans le cadre de ce document, nous’en pr´esentons deux : Classification bas´ee sur la disponibilit´e du service composite ` ´ 3.3 MODELE PROPOSE 3.3.4 Fonctions L’ensemble de fonctions dans un service que les clients peuvent invoquer sont apparue comme l’interface du service Donc on d´ecrit les fonctions d’un service comme on d´ecrite les interfaces Pour d´ecrire une fonction, on d´ecrire le nom de la fonction, quel sont les types d’entr´ees et les types de sorties (la signature de la fonction) Par exemple : on peut d´ecrire la fonction payer(int ,int) comme Cette fonction n’a pas de sorties Dans des cas, il y a des fonctions qu’elles prennent des entr´ees, modifient leurs valeurs et ces valeurs sont trait´ees comme des r´esultats de sorties de la fonction Donc pour d´ecrire des fonctions il faut supporter des mot comme ”inout” pour dire cette variable est a` la mˆeme l’entr´ee et la sortie de la fonction Dans la description des fonctions, on a pr´esent´e le type des entr´ees et des sorties de la fonctions Donc pour utiliser un type, il faut que ce type est connu Un type peut ˆetre le type du syst`eme (int, boolean, les classe d´efinies par le syst`eme ), le type d´efini par le service (structure les classe d´efinies par le service) 3.3.5 Corr´ elation dans un service Est-ce avec le mod`ele que je pr´esente dans la partie pr´ec´edente, peut on utiliser le service sans avoir des probl`emes ? La r´eponse c’est non Il manque les corr´elations entre les actions Autrement dit, il faut sp´ecifier les sorties d’une action vont ˆetre prises comme les entr´ees d’une autre action En fait il y a plusieurs choix possibles pour d´ecrire les corr´elations entre les actions On peut les d´ecrire dans une partie comme : dans cet exemple, il veut dire que la variable var2 dans l’action action2 va prendre la sortie var1 dans l’action action1 21 ´ ERATION ´ 3.4 GEN DU CONNECTEUR On peut utiliser d’autre fa¸con pour pr´esenter les corr´elations Une fa¸con simple, on consid`ere que dans tous les actions les variables qui ont le mˆeme sens si leurs noms sont identiques Ont peut voir que cette fa¸con est utilis´ee dans WSDL (pour en savoir plus revoir le chapitre ´etat de l’art) Si on utiliser cette fa¸con, il faut faire attention quand on compose des services et particuli`erement quand on composer les mˆemes services ( j’aborde ce probl`eme dans le chapitre suivant) 3.4 G´ en´ eration du connecteur Dans cette partie je pr´esente, comment on peut utiliser un service qui est d´ecrit avec le mod`ele qu’on propos´e Autrement dit comment on peut g´en´erer le connecteur entre le client et le service Le travail de connecteur est de conduire les transitions du service pour qu’il peut arriver a` un ´etat final du service si possible, si non il ´enonce un message erreur Le principe du fonctionnement de connecteur est d´ecrire dans l’algorithme suivant : Algorithme 1: initial : x = e ´tat initial algorithme(x) si x est un e ´tat final alors le service est d´ ej` a bien utilis´ e sinon pour chaque e ´tat y et la transition x > y est valid´ ee appliquer les actions associ´ ees avec cette transition algorithme(y) Avec le principe du fonctionnement du connecteur ci-dessus, quand on g´en`ere le connecteur on peut utiliser deux approches : 3.4.1 La premi` ere approche Le connecteur ne concr´etise (impl´emente) que l’algorithme pr´ec´edent Plus pr´ecis´ement le connecteur est comme : Les transitions, actions, conditions, fonctions sont utilis´ees par la fonction qui impl´emente l’algorithme pr´ec´edent L’int´erˆet de cette approche c’est que le connecteur est pareil pour tous les services Deux connecteur qui correspondent a` deux services diff´erents, sont diff´erents les contenus dans les transitions, les conditions, les actions, et les fonctions Alors le connecteur est pr´ed´efinit quand le serveur de service qui veut g´en´erer un connecteur qui sert a` un service pr´ecise, il faut seule analyser sa description pour obtenir ses transitions, ses conditions, ses actions, et ses fonctions ensuite il lance le connecteur avec ces informations 22 ´ ERATION ´ 3.4 GEN DU CONNECTEUR Fig 3.6 – premi`ere approche 3.4.2 La deuxi` eme approche On peut g´en´erer directement un programme a` partir des transitions, des conditions, des actions, et des fonctions Avec cet approche le connecteur ne contient plus des transitions, des conditions, des actions et des fonctions - tous ces informations sont pr´esent´ees dans le code du connecteur Pour chaque service, avec cet approche, il faut g´en´erer un connecteur Cet approche on peut classifier en deux sous approches :orient´e fonction ou orient´e objet Orient´ e fonction Dans cet approche chaque ´etat (dans les transitions) du service est g´en´er´e comme une fonction dans le connecteur Je pr´esente cet approche dans un exemple suivant : Exemple Fig 3.7 – Exemple 23 ´ ERATION ´ 3.4 GEN DU CONNECTEUR Explication : Cet exemple est un peu pareil l’exemple pr´ec´edent sauf il permet a` l’utilisateur de choisir plusieurs objet comme il veut Donc la description du service est un peu diff´erente La variable ok signifie la terminaison de choix de l’utilisateur, la variable ref contient la liste d’objets choisis Quand la fonction choisir est invoqu´ee, elle va ajouter quelques r´ef´erences d’objets a` la variable ref (`a la fois la sortie et l’entr´ee) Le code du connecteur g´en´er´e dans ce cas avec l’approche orient´e fonction se compose de quatre fonctions suivantes : fonction AvantLogin(){ id = login() AvantChoisir(); } fonction AvantChoisir(){ si id > alors{ ok = choisir(id,ref); AvantPayer(); } } fonction AvantPayer(){ si ! ok alors{ ok = choisir(id,ref); AvantPayer(); } si ok et ref null alors{ payer(id,ref); } } fonction main(){ AvantLogin(); } Avec cet approche, pour chaque ´etat du service il faut g´en´erer une fonction dans le code du connecteur Alors apr`es avoir g´en´er´e le connecteur, le serveur de services va lancer ce connecteur Les langage fonctionnels on peut utiliser cet approche Orient´ e objet Cet approche est un peu pareil l’approche orient´e fonction La diff´erence c’est que pour chaque ´etat on g´en`ere une classe au lieu a` une fonction Au niveau pratique, on peut utiliser cet approche pour les langage orient´e objet et les classes sont des impl´ementations d’une interface commune Par exemple cet interface peut ˆetre d´ecrite simple comme : public interface Etat{ public void excuser (); } 24 ` 3.5 PROBLEMES ET SOLUTIONS L’impl´ementation de la fonction excuser dans chaque classe impl´ement´ee l’interface cidessus est impl´ement´ee un peu pareil l’impl´ementation les fonctions dans l’approche orient´e fonction Pour la g´en´eration du connecteur, il faut r´esoudre des probl`emes comme : le probl`eme de typage, le probl`eme d’exception Donc dans les parties suivantes, je pr´esente quelques probl`emes que on a rencontr´e 3.5 3.5.1 Probl` emes et solutions Back-tracking Le fonctionnement du connecteur est d’essayer de trouver un chemin de l’´etat initial a` l’´etat final du service Il est possible qu’on ne peut pas trouver le chemin si on suit une branche b alors dans ce cas, il faut essayer avec les autres branches Autrement dit, il faut retourner a` l’´etat E o` u la branche b s’est pass´ee et essaye avec autre branche, mais avant de cet essai, il faut reprendre les valeurs de variables (´etat du connecteur) avant de suivre la branche b (back-tracking) Donc on peut r´ecrire l’algorithme pr´ec´edent comme : initial : x = e ´tat initial algorithme(x) si x est un e ´tat final alors le service est d´ ej` a bien utilis´ e sinon sauvegarder les valeurs des variables a ` l’´ etat x; pour chaque e ´tat y et la transition x > y est valid´ ee appliquer les actions associ´ ees avec cette transition connecteur(y); restaurer les valeurs des variables a ` l’´ etat x; 3.5.2 Typage Quand on g´en`ere le connecteur, il faut d´eterminer et v´erifier le type de variables Un type d’une variable est d´etermin´e par la description de la fonction o` u cette variable est utilis´ee Mais si dans le service une variable est utilis´ee par plusieurs fonctions (corr´elation entre les fonctions), il faut v´erifier qu’il n’y a pas des fautes de typage de cette variable Quand on g´en`ere le connecteur, on peut utiliser une table de deux colonnes, une pour garder le nom et une pour garder le type de variables Cette table est utilis´ee dans la v´erification et la d´eclaration (d´eterminaison) de variables 3.5.3 Exceptions Quand on invoque des fonctions dans un service, particuli`erement le service a` distance, il y a toujours des exceptions Il y a deux types d’exception : exception du syst`eme 25 3.6 DISCUTIONS (connexion en panne ), et exception retourne par le service (les entr´ees fournies par le client par suffisantes ) Pour le premier type d’exception on ne peut rien faire, sauf arrˆeter l’utilisation de ce service Pour le deuxi`eme type, les exceptions sont pr´evues par le service C’est a` dire le concepteur du service peut pr´evoir les exceptions qui peuvent ˆetre retourn´ees aux utilisateurs et les traitements pour chaque exception Le traitement d’exception peut ˆetre simple comme il retourne le service a` l’´etat o` u il permet a` l’utilisateur d’entrer les donn´ees (les informations) ou il prend quelques actions suppl´ementaires avant de continuer a` utiliser le services Donc avec le mod`ele que j’ai introduit, je pense qu’on peut d´ecrire le service et aussi des exceptions du service Et quand on g´en`ere le connecteur, les exceptions sont trait´ees comme les conditions pour valider des transitions Mais en fait il faut plus penser a` ce probl`eme par exemple : O` u on va mettre la transition de traitement l’exception A ou B quand la transition de l’´etat A a` l’´etat B, il y a une exception qui se passe 3.5.4 Non d´ eterministe Quand on utilise le concept de l’automate pour d´ecrire de services Le probl`eme de non d´eterministe est toujours important Dans la th´eorie de l’automate on peut enlever les non - d´eterministes en regroupant des ´etats Mais je pense que avec la description de services, on peut avoir autre fa¸con de faire On peut donner pour chaque transition une priorit´e, si il y a plusieurs choix, alors la transition ayant la priorit´e haute est prise 3.5.5 Boucle infinie Quand le connecteur fonctionne, il est possible de tomber dans une boucle infinie Une question je me pose comment on peut d´etecter (savoir) la boucle infinie quand le connecteur qui fonctionne Comme dans la partie 3.5.1 (back-tracking), on sait qu’il faut sauvegarder les valeurs des variables (´etat du connecteur) a` chaque ´etat de l’automate, et on peut utiliser ces informations pour d´etecter la boucle infinie Quand le connecteur il retourne a` l’´etat E, avec les valeurs courantes des variables et les valeurs stock´ees a` E on peut savoir s’il y a une boucle infinie(si les valeurs ne changement pas) ou non Avec cette fa¸con le connecteur peur savoir quand il tombe dans une boucle infinie 3.6 Discutions Quand on utilise des types pour d´ecrie le service, il faut que les types sont bien connus Avec les types simples, on peut prendre une projection vers le langage qu’on peut g´en´erer le connecteur avec Pour les types complexes, il faut avoir des description de ces types Donc on peut prendre des notions pour d´ecrire des types complexes dans les autres langages de descriptions comme : IDL avec le CORBA ou WSDL dans le Web service Le probl`eme d’initialisation des variables : dans quelques invocations des fonctions, il faut que les variables doivent avoir des valeurs initiales Alors il faut penser a` d´ecrire les valeurs initiales pour les variables dans la description de service 26 Chapitre Composition de services 4.1 Introduction Dans ce chapitre, je pr´esente la composition de services qui sont d´ecrits par le mod`ele dans le chapitre pr´ec´edent L’objectif de l’utilisation de l’automate dans la description de services c’est qu’on peut r´eutiliser les algorithmes de composition des automates dans la composition de services Quand on compose deux services, il faut avoir des informations suppl´ementaire qui permet de composer de services correctement : les sorties d’un service va entrer dans l’autre C’est a` dire il faut une synchronisation entre les services avant de les composer 4.2 Synchronisation entre les services Les services a` composer peuvent ˆetre classifier en deux cat´egories : – D´ependance : entre les services, il y a des d´ependance des informations, service A doit utiliser quelques informations fournies par le servie B et inversement, dans ce cas le service A doit savoir o` u ces informations sont stock´ees dans le service B Donc il faut avoir une m´ecanisme (synchronisation)qui permet au service A peut obtenir les informations qu’il veut dans le service B – Ind´ependance : entre les services il n’y a pas de d´ependance des informations Dans ce cas on ne veut pas de synchronisation entre eux 4.2.1 Le besoin du langage de la requˆ ete Le but de la composer de services est de r´epondre a` la requˆete du client Le client peut exprimer ses besoins en langue naturelle ou on peut construire des moyens qui permet de capturer les besoins du client, mais de tout fa¸cons, il faut traduire ces besoin sous un langage que le syst`eme peut comprendre Par exemple, un client il exprime ses besoin comme : «je veux acheter une voiture et un mobile phone « alors il faut traduire pour que le syst`eme il puisse comprendre que le client il veut utiliser le service d’acheter une voiture et le service d’acheter un mobile phone Donc il faut construire un langage de requˆete 27 4.3 COMPOSITIONS DES SERVICES Quand le besoin du client est ´ecrit par un langage de requˆete, il ne permet pas seulement de savoir quels services sont utilis´es pour r´epondre au besoin mais il permet aussi de savoir la fa¸con d’utiliser ses services Autrement dit, on peut savoir comment on peut composer les services (synchronisation entre les services) Donc le rˆole du langage de requˆete est tr`es important : – permet de d´ecouper les requˆetes du client sous en sous requˆetes, chaque sous requˆete correspond a` un service – d´ecide le type de composer entre les services (synchronisation entre les services) pour r´epondre au besoin du client Le but de mon stage n’est pas de chercher a` proposer un langage de requˆete Donc mois je suppose que avec un langage de requˆete, qui nous permet de savoir la synchronisation entre les services et on utilise ces informations pour composer les services 4.2.2 Description la synchronisation Les informations d’un service qu’il peut partager avec les autres services ne stockent que dans leurs variables entr´ees et sorties Donc quand on veut d´ecrire les synchronisation entre deux services A et B, on peut d´ecrire que la variable x de A est partag´ee comme la variable y de B, ou plus pr´ecis´ement on peut d´ecrire les sorties de la fonction f1 dans est les entr´ees de la fonction f2 dans B Il d´epend de la langage de description que le serveur de services qu’on peut choisir une fa¸con pour d´ecrire les synchronisations entre le service On peut d´ecrire une synchronisation comme : dans le petit exemple ci-dessus, il y a une synchronisation entre la variable var1 et la variable var2 de deux services 4.3 4.3.1 Compositions des services Algorimthme de composition des automate Avant de pr´esenter la composition entre les services, je pr´esente l’algorithme pour composer deux automates On peut utiliser cet algorithme pour les cas de plusieurs automates L’algorithme cherche un automate compos´e (Q, A, q,t,E) a` partir de deux automates (Q1,A1,q1,t1,E1) et (Q2,A2,q2,t2,E2) Algorithme pour composer deux automates D´efinir l’ensemble Q ( l’ensemble des ´etats dans l’automate produit) : Q = Q1 × Q ou on peut ´ecrire Q = {q = (q , q )|q ∈ Q1 ; q ∈ Q2 } 28 4.3 COMPOSITIONS DES SERVICES D´efinir l’ensemble A les alphabets dans l’automate produit : l’´etat initial : q = (q , q ) A = A1 ∪ A ou A = {a|a ∈ A1 oua ∈ A2 } l’´etat final : t = (t1 , t2 ) D´efinir les transitions E : si (qi , a, qj ) appartient a` E ou (qi , a, qj ) appartient a` E alors ((qi , qi ), a, (qj , qj )) appartient a` E ou : E = {((qi , qi ), a, (qj , qj ))|(qi , a, qj ) ∈ E 4.3.2 ou (qi , a, qj ) ∈ E } Utilisation de cet algorithme dans la composition des services On voit bien qu’avec le mod`ele qui permet de d´ecrire des service en utilisant les automates On peut utiliser l’algorithme de composer des automates ci-dessus pour composer des services Le service compos´e est d´ecrit aussi sous ce mod`ele, alors on peut g´en´erer le connecteur pour le service compos´e comme pour les autres services (chapitre 3) Avant de composer des service, il faut renommer les variables les fonctions, les actions, et les conditions dans chaque service composant Si non il apparaˆıt peut-ˆetre des fautes quand on g´en`ere le connecteur Par exemple dans le service A, il utilise une variable x, dans le service B il utilise aussi une variable nomm´ee x, et il n’y a pas de synchronisation entre A et B concernant la variable x, alors il faut renommer les noms de deux variables x dans A ou dans B Quand on r´ealise le renommage des variables, des fonctions, des actions, et des conditions Il faut r´ealiser ce changement dans tous les cas et dans tous les services composants Mais il faut faire attention au renommage des fonctions dans le cas o` u le service composite est la composition de mˆeme service (on compose un service deux fois par exemple) les noms des fonctions dans le mˆeme service sont toujours les mˆemes Transitions du service composite : quand on compose des services avec l’algorithme pr´ec´edent, les transitions du service compos´e sont d´efinies par cet algorithme (on voit dans l’exemple apr`es) Conditions du service composite : les conditions du service compos´e sont une union des toutes les conditions des services composants Actions du service composite : les actions du service compos´e sont une union des toutes les actions des services composants Fonctions du service composite : les fonctions du service compos´e sont une union des toutes les fonctions des services composants Quand on obtient le service composite : les descriptions des transitions, les descriptions des conditions, les descriptions des actions et les descriptions des fonctions, on peut dire que le composite service est bien d´ecrit comme le mod`ele de l’automate dans le chapitre Alors tous ce qu’on pr´esente dans le chapitre pr´ec´edent peuvent ˆetre utilis´es avec le composite service pour g´en´erer le connecteur qui permet d’utiliser ce composite service 29 4.3 COMPOSITIONS DES SERVICES exemple :On compose deux services suivants : service :Service de traduction : Fig 4.1 – Exemple : Service de traduction service :Service d’achat Fig 4.2 – Exemple : Service d’achat service composite : Fig 4.3 – Exemple : Composite service 30 4.4 CONCLUSION 4.4 Conclusion On peut minimiser les transitions du service composite avant de g´en´erer le connecteur, cette minimisation permet de minimiser le code du connecteur qu’on doit g´en´erer Le besoin de minimiser les transitions du composite service vient de : – L’algorithme de composition des automates : apr`es avoir appliqu´e cet algorithme sur des automates, il a besoin des minimisation l’automate r´esultat Et on peut trouver l’algorithme de minimisation des automate dans dans livre qui parle de les automates – Le besoin de la minimisation vient aussi du service, comme dans l’exemple pr´ec´edent, on peut voir bien que l’´etat (Atraduire,Terminer2) n’est pas jamais touch´e Donc pour ce type de minimisation il faut trouver un algorithme efficace 31 Chapitre Conclusion, perspectives Ce stage est r´ealis´e au laboratoire du D´epartement d’Informatique de l’ENST Bretagne, et il s’est d´eroul´e dans le projet CAMA, l’int´erˆet de ce travail est de d´ecrire des services dans le cadre de la mobilit´e et de les composer Apr`es une ´etude sur des mod`eles existantes (EJB, Web service, eFlow, SWORD ), le concept des automates semble le plus adapt´e pour d´ecrire des services Et en basant sur l’architecture propos´ee par Kamal Gakhar (un stagiaire du d´epartement l’ ann´ee derni`ere) on a propos´e un mod`ele en deux couches pour d´ecrire le services Avec ce mod`ele, on a ´etudi´e deux approches pour la g´en´eration de connecteur, et ses probl`emes (le typage, le non d´eterministe, le back tracking ) La composition des services avec ce mod`ele devient la composition des automates Mais avant d’appliquer des algorithmes de la composition, il faut : – renommer les variables, les fonctions, les conditions, les actions du service composants – ajouter la description de la synchronisation entre les services – minimise le r´esultat Pour montrer la composition et la g´en´eration des services, un petit programme est ´ecrit en java Mais il faut l’am´eliorer pour qu’il puisse s’int´egrer dans une plate forme r´eelles Avec le temps de six mois du stage, il reste encore beaucoup des choses a` faire Donc pour les travails dans la future : – Am´eliorer le mod`eles pour trouver des solutions plus efficaces pour les probl`emes de la g´en´eration du connecteur et de la composition des service – Chercher a` proposer un langage de la description pour les service dans le cas r´eel – tudier et proposer des solutions pour qu’on puisse ajouter et enlever des services composants pour avoir un service composite satisfaisant des propri´et´es non fonctionnelles : Comment on peut d´ecrire des propri´et´es non fonctionnelles et comment on peut les utiliser 32 Annexe A Dot langage Dans mon programme, j’utilise un utile pour dessiner les transitions du service Cet utile est distribu´e avec le Mandrake, c’est le dot ( dans le console tapez man dot pour plus d´etaill´e) En fait, le dot travaille comme le Graphviz (open source graph drawing software, d´evelopp´e par AT&T Labs - Researche) Un fichier est ´ecrit en dot langage comme : digraph finite state machine { rankdir=LR ; size=”8,5” orientation=land ; node [shape = doublecircle] ; LR LR LR LR ; node [shape = circle] ; LR -> LR [ label = ”SS(B)” ] ; LR -> LR [ label = ”SS(S)” ] ; LR -> LR [ label = ”S($end)” ] ; LR -> LR [ label = ”SS(b)” ] ; LR -> LR [ label = ”SS(a)” ] ; LR -> LR [ label = ”S(A)” ] ; LR -> LR [ label = ”S(b)” ] ; LR -> LR [ label = ”S(a)” ] ; LR -> LR [ label = ”S(b)” ] ; LR -> LR [ label = ”S(a)” ] ; LR -> LR [ label = ”S(b)” ] ; LR -> LR [ label = ”S(a)” ] ; LR -> LR [ label = ”S(b)” ] ; LR -> LR [ label = ”S(a)” ] ; } est analys´e par dot et donne une image r´esultat comme : 33 Fig A.1 – Imgage g´en´er´ee par l’utile graphviz (http ://www.research.att.com/sw/tools/graphviz/) Dans mon programme, j’impl´emente la classe Transition2Dot pour g´en´erer un fichier en Dot langage et utiliser la classe Runtime du java pour invoquer le dot Un petit code d’invoquer le dot comme : Runtime runtime = Runtime.getRuntime() ; Process process = null ; try{ process = runtime.exec(”dot -Tpng -o output.png input.dot”; } catch(IOException e){ return ;} if(process != null) { try{ process.waitFor() ; } catch(InterruptedException e){return ;} } Le petit programme ci-dessus va g´en´erer une fichier image (output.png) a` partir de fichier en dot langage (input.dot) 34 Bibliographie ´ ements de th´eorie des automates, Vuibert Informatique, 2003 [1] J.Sakarovitch El´ [2] http ://www.java.sun.com/products/ejb [3] http ://www.javaworld.com/javaworld/jw-10-1998/jw-10-beans-p2.html [4] S.Higels, D.Lewis State of the Art : Service zones.org/deliverables/D1 1/Svc Composition.pdf, 2003 composition, www.m- [5] F.Casati, S.Ilnicki, L.Jin,V.Krishnamoorthy, M.C.Shan Adaptive and Dynamic Service Composition in eFlow,http ://www.hpl.hp.com/techreports/2000/HPL-200039.pdf [6] K.Gakhar Description, V´erification et Adaptations de composants dans le cadre de syst`eme mobiles.Rapport de stage DEA 2003 [7] W3C Web Services Architecture, http ://www.w3.org/TR/ws-arch, 2004 [8] Jini by example, http ://www.cswl.com/whiteppr/tutorials/jini.html#h [9] D.Chakraborty, A.Joshi Dynamic Service Composition : State-of-the-Art and Research Directions Technical Report TR-CS-01-19, Department of Computer Science and Electrical Engineering, University of Maryland, Baltimore County, Baltimore, MD, 2001 [10] L.Chung, B.A.Nixon, E.Yu, J.Mylopoulos Non-Functional requirements in software engineering, Kluwer Academic Publishers, 2000 [11] http ://www2002.org/CDROM/alternate/786/ 35 [...]... types complexes dans les autres langages de descriptions comme : IDL avec le CORBA ou WSDL dans le Web service Le probl`eme d’initialisation des variables : dans quelques invocations des fonctions, il faut que les variables doivent avoir des valeurs initiales Alors il faut penser a` d´ecrire les valeurs initiales pour les variables dans la description de service 26 Chapitre 4 Composition de services. .. composite : les actions du service compos´e sont une union des toutes les actions des services composants Fonctions du service composite : les fonctions du service compos´e sont une union des toutes les fonctions des services composants Quand on obtient le service composite : les descriptions des transitions, les descriptions des conditions, les descriptions des actions et les descriptions des fonctions,... tracking ) La composition des services avec ce mod`ele devient la composition des automates Mais avant d’appliquer des algorithmes de la composition, il faut : – renommer les variables, les fonctions, les conditions, les actions du service composants – ajouter la description de la synchronisation entre les services – minimise le r´esultat Pour montrer la composition et la g´en´eration des services, ... Introduction Dans ce chapitre, je pr´esente la composition de services qui sont d´ecrits par le mod`ele dans le chapitre pr´ec´edent L’objectif de l’utilisation de l’automate dans la description de services c’est qu’on peut r´eutiliser les algorithmes de composition des automates dans la composition de services Quand on compose deux services, il faut avoir des informations suppl´ementaire qui permet de composer... renommer les noms de deux variables x dans A ou dans B Quand on r´ealise le renommage des variables, des fonctions, des actions, et des conditions Il faut r´ealiser ce changement dans tous les cas et dans tous les services composants Mais il faut faire attention au renommage des fonctions dans le cas o` u le service composite est la composition de mˆeme service (on compose un service deux fois par exemple)... s’int´egrer dans une plate forme r´eelles Avec le temps de six mois du stage, il reste encore beaucoup des choses a` faire Donc pour les travails dans la future : – Am´eliorer le mod`eles pour trouver des solutions plus efficaces pour les probl`emes de la g´en´eration du connecteur et de la composition des service – Chercher a` proposer un langage de la description pour les service dans le cas r´eel... d´ecrire des fonctions il faut supporter des mot comme ”inout” pour dire cette variable est a` la mˆeme l’entr´ee et la sortie de la fonction Dans la description des fonctions, on a pr´esent´e le type des entr´ees et des sorties de la fonctions Donc pour utiliser un type, il faut que ce type est connu Un type peut ˆetre le type du syst`eme (int, boolean, les classe d´efinies par le syst`eme ), le type... d´ecrire les synchronisation entre deux services A et B, on peut d´ecrire que la variable x de A est partag´ee comme la variable y de B, ou plus pr´ecis´ement on peut d´ecrire les sorties de la fonction f1 dans est les entr´ees de la fonction f2 dans B Il d´epend de la langage de description que le serveur de services qu’on peut choisir une fa¸con pour d´ecrire les synchronisations entre le service... causer le probl`eme d’extension 14 Chapitre 3 Mod` ele de description de services 3.1 Introduction d´ etaill´ e du stage Mon stage est comme la suite du stage de GAKHAR (Description,v´erification et Adaptation de composants dans le cadre de syst`emes mobiles) Le r´esultat de son stage est de proposer une architecture qui se compose de 5 parties (composants) : Le client : qui demande des services Le serveur... par la description de la fonction o` u cette variable est utilis´ee Mais si dans le service une variable est utilis´ee par plusieurs fonctions (corr´elation entre les fonctions), il faut v´erifier qu’il n’y a pas des fautes de typage de cette variable Quand on g´en`ere le connecteur, on peut utiliser une table de deux colonnes, une pour garder le nom et une pour garder le type de variables Cette table