Modélisation des services dans le cadre de la mobilité

Institut de la francophonie pour l’informatique Rapport du stage de n d’ etudes Modelisation des services dans le cadre de la mobilite Realise 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), ou je prepare mon DEA J’addresse mes remercients les plus sinceres a Fabien Dagnat et Julien Mallet du departement informatique de l’Ecole Normale Superieure des Telescommunications de Bretgane, d’avoir encadre pour ce travail Je remercie les professeurs, et les membres du departement informatique, de MAISEL, de RESEL de l’Ecole Normale Superieure des Telescommunication 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 rensei-gnements, leurs aides R esum e Les terminaux mobiles sont apparus et deviennent populaires aujourd’hui gr^ace a leurs pratiques Parallelement avec cet apparition, c’est les applications sur ces terminaux A cause de la caracteristique du terminal mobile : portabilite, bas de performance les applications sur les terminaux mobiles (services mobiles) face aux frequentes chan-gements de leurs contextes d’execution Donc les services mobiles doivent adapter a ces changements C’est la raison pour laquelle une architecture avec une couche intermediaire est utilisee Dans ce rapport, en utilisant cet architecture, je presente 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 beni t and since the application based on that terminal mobiles have developed Because of the terminal mobiles ’speci c 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 matieres Introduction 1.1 Contexte du travail 1.2 Sujet detaille 1.3 Le plan du rapport Etat de l’art 2.1 2.2 Introduction generale Survol du service composite 2.2.1 2.2.2 2.2.3 Modeles existants 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 Securite Performance Conclusion 2.3 2.4 2.5 2.6 Modele de description de services 3.1 Introduction detaille du stage 3.2 Automate 3.2.1 3.2.2 3.3 Modele propose 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.4 Generation du connecteur 3.4.1 3.4.2 TABLE DES MATIERES 3.5 3.6 Composition de services 4.1 4.2 4.3 4.4 Conclusion, perspectives Annexe A Dot langage Problemes et solutions 3.5.1 3.5.2 3.5.3 3.5.4 3.5.5 Discutions Introduction Synchronisation entre les services 4.2.1 4.2.2 Compositions des services 4.3.1 4.3.2 Conclusion Table des gures 2.1 2.2 2.3 Architecture du Web service Modele eFlow Achitecture de EJB 3.1 3.2 3.3 3.4 3.5 3.6 3.7 Architecture proposee par GAKHAR exemple exemple Modele propose Une transition premiere approche Exemple 4.1 4.2 4.3 Exemple : Service de traduction Exemple : Service d’achat Exemple : Composite service A.1 Imgage generee par l’utile graphviz Chapitre Introduction 1.1 Contexte du travail Le projet se deroule dans l’equipe CAMA du departement d’informatique de l’ENST Bretagne Cette equipe developpe des recherches dans le domaine emergent de l’informa-tique nomade La recherche envisage de proposer une couche intermediaire (gestionaire des services), qui permet d’adapter une application mobile aux frequentes changements de son contexte d’execution 1.2 Sujet detaille Les problematiques associees a ce domaine de recherche apparaissent dans de nom-breuses applications du fait de la multiplication de l’utilisation de terminaux mobiles qui changent frequemment de contexte d’execution Par exemple, si un utilisateur visualise une image haute de nition sur son ecran de bureau et sort du b^atiment, il peut ^etre neces-saire de passer a une de nition inferieure pour la regader sur l’ecran d’un PDA De plus la composition de services doit ^etre e ectuee en prenant en compte les contraintes de qualite de service des applications, qu’elles soient fonctionnelles ou non fontionnelles (securite, performance, abilite ou passage l’echelle) Dans l’exemple precedent, la consultation sur PDA peut requerir la prise en compte de la redution de bande de passante et la necessite d’augmenter la securite des communications Il existe des produits industriels et des standards qui decrivent la notion de service de composant (p.ex EJB, Web service) qui sont associes a des systemes de decouverte et d’utilisation de service permetant leur integration dynamique (p.ex JINI, UnPN, UDDI) Toutefois ces approches pramatiques sont, a ce jour, limitees La description des services n’integre pas (ou peu) leur semantique, et ne permet donc pas de garantir une integration correcte respectant des contraintes non fonctionnelles De plus, elles ont ete concues pour des environnement statiques fermes ce qui rend di cile l’adaption dynamique des services au contexte d’execution Donc, le travail de ce stage se decompose en t^ache de maniere suivante : Composants pour Architectures Mobiles Adaptables 1.3 LE PLAN DU RAPPORT Etudier les di erents modeles qui permettent de decrire un service, cette etude concentree sur de services mobiles et sur quelques proprietes non fonctionelles Proposer un modele qui permet de composer dynamiquement des services Valider les approches retenues en etudiant des proprietes de la securite et de la performance sur un type d’application donne Rediger le rapport nal 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 presentee dans la partie 1, la partie deux est une etude sur des modeles de la description et de la composition des services La partie et partie presentent notre modele de la description des services, l’utilisation et la composition des services decrits par ce modele La conclusion et perspectives sont dans la partie 5 3.4 GENERATION DU CONNECTEUR On peut utiliser d’autre facon pour presenter les correlations Une facon simple, on considere que dans tous les actions les variables qui ont le m^eme sens si leurs noms sont identiques Ont peut voir que cette facon est utilisee dans WSDL (pour en savoir plus revoir le chapitre etat de l’art) Si on utiliser cette facon, il faut faire attention quand on compose des services et particulierement quand on composer les m^emes services ( j’aborde ce probleme dans le chapitre suivant) 3.4 Generation du connecteur Dans cette partie je presente, comment on peut utiliser un service qui est decrit avec le modele qu’on propose Autrement dit comment on peut generer le connecteur entre le client et le service Le travail de connecteur est de conduire les transitions du service pour qu’il peut ar-river a un etat nal du service si possible, si non il enonce un message erreur Le principe du fonctionnement de connecteur est decrire dans l’algorithme suivant : Algorithme 1: initial : x = etat initial algorithme(x) si x est un etat final alors le service est deja bien utilise sinon pour chaque etat y et la transition x > y est validee appliquer les actions associees avec cette transition algorithme(y) Avec le principe du fonctionnement du connecteur ci-dessus, quand on genere le connecteur on peut utiliser deux approches : 3.4.1 La premiere approche Le connecteur ne concretise (implemente) que l’algorithme precedent Plus precisement le connecteur est comme : Les transitions, actions, conditions, fonctions sont utilisees par la fonction qui imple-mente l’algorithme precedent L’inter^et de cette approche c’est que le connecteur est pareil pour tous les services Deux connecteur qui correspondent a deux services di erents, sont di erents les contenus dans les transitions, les conditions, les actions, et les fonctions Alors le connecteur est prede nit quand le serveur de service qui veut generer un connec-teur qui sert a un service precise, 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 3.4 GENERATION DU CONNECTEUR Fig 3.6 { premiere approche 3.4.2 La deuxieme approche On peut generer 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 presentees dans le code du connecteur Pour chaque service, avec cet approche, il faut generer un connecteur Cet approche on peut classi er en deux sous approches :oriente fonction ou oriente objet Oriente fonction Dans cet approche chaque etat (dans les transitions) du service est genere comme une fonction dans le connecteur Je presente cet approche dans un exemple suivant : Exemple Fig 3.7 { Exemple 23 3.4 GENERATION DU CONNECTEUR Explication : Cet exemple est un peu pareil l’exemple precedent sauf il permet a l’utilisateur de choisir plusieurs objet comme il veut Donc la description du service est un peu di erente La variable ok signi e la terminaison de choix de l’utilisateur, la variable ref contient la liste d’objets choisis Quand la fonction choisir est invoquee, elle va ajouter quelques references d’objets a la variable ref (a la fois la sortie et l’entree) Le code du connecteur genere dans ce cas avec l’approche oriente 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 generer une fonction dans le code du connecteur Alors apres avoir genere le connecteur, le serveur de services va lancer ce connecteur Les langage fonctionnels on peut utiliser cet approche Oriente objet Cet approche est un peu pareil l’approche oriente fonction La di erence c’est que pour chaque etat on genere une classe au lieu a une fonction Au niveau pratique, on peut utiliser cet approche pour les langage oriente objet et les classes sont des implementations d’une interface commune Par exemple cet interface peut ^etre decrite simple comme : public interface Etat{ public void excuser (); } 24 3.5 PROBLEMES ET SOLUTIONS L’implementation de la fonction excuser dans chaque classe implementee l’interface ci-dessus est implementee un peu pareil l’implementation les fonctions dans l’approche oriente fonction Pour la generation du connecteur, il faut resoudre des problemes comme : le probleme de typage, le probleme d’exception Donc dans les parties suivantes, je presente quelques problemes que on a rencontre 3.5 3.5.1 Problemes et solutions Back-tracking Le fonctionnement du connecteur est d’essayer de trouver un chemin de l’etat initial a l’etat nal 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 ou la branche b s’est passee 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 recrire l’algorithme precedent comme : initial : x = etat initial algorithme(x) si x est un etat final alors le service est deja bien utilise sinon sauvegarder les valeurs des variables a l’etat x; pour chaque etat y et la transition x > y est validee appliquer les actions associees avec cette transition connecteur(y); restaurer les valeurs des variables a l’etat x; 3.5.2 Typage Quand on genere le connecteur, il faut determiner et veri er le type de variables Un type d’une variable est determine par la description de la fonction ou cette variable est utilisee Mais si dans le service une variable est utilisee par plusieurs fonctions (correlation entre les fonctions), il faut veri er qu’il n’y a pas des fautes de typage de cette variable Quand on genere 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 utilisee dans la veri cation et la declaration (determinaison) de variables 3.5.3 Exceptions Quand on invoque des fonctions dans un service, particulierement le service a distance, il y a toujours des exceptions Il y a deux types d’exception : exception du systeme 25 3.6 DISCUTIONS (connexion en panne ), et exception retourne par le service (les entrees fournies par le client par su santes ) Pour le premier type d’exception on ne peut rien faire, sauf arr^eter l’utilisation de ce service Pour le deuxieme type, les exceptions sont prevues par le service C’est a dire le concepteur du service peut prevoir les exceptions qui peuvent ^etre retournees aux utilisateurs et les traitements pour chaque exception Le traitement d’exception peut ^etre simple comme il retourne le service a l’etat ou il permet a l’utilisateur d’entrer les donnees (les informations) ou il prend quelques actions supplementaires avant de continuer a utiliser le services Donc avec le modele que j’ai introduit, je pense qu’on peut decrire le service et aussi des exceptions du service Et quand on genere le connecteur, les exceptions sont traitees comme les conditions pour valider des transitions Mais en fait il faut plus penser a ce probleme par exemple : Ou 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 deterministe Quand on utilise le concept de l’automate pour decrire de services Le probleme de non deterministe est toujours important Dans la theorie de l’automate on peut enlever les non - deterministes en regroupant des etats Mais je pense que avec la description de services, on peut avoir autre facon de faire On peut donner pour chaque transition une priorite, si il y a plusieurs choix, alors la transition ayant la priorite haute est prise 3.5.5 Boucle in nie Quand le connecteur fonctionne, il est possible de tomber dans une boucle in nie Une question je me pose comment on peut detecter (savoir) la boucle in nie 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 detecter la boucle in nie Quand le connecteur il retourne a l’etat E, avec les valeurs courantes des variables et les valeurs stockees a E on peut savoir s’il y a une boucle in nie(si les valeurs ne changement pas) ou non Avec cette facon le connecteur peur savoir quand il tombe dans une boucle in nie 3.6 Discutions Quand on utilise des types pour decrie 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 generer le connecteur avec Pour les types complexes, il faut avoir des description de ces types Donc on peut prendre des notions pour decrire des types complexes dans les autres langages de descriptions comme : IDL avec le CORBA ou WSDL dans le Web service Le probleme d’initialisation des variables : dans quelques invocations des fonctions, il faut que les variables doivent avoir des valeurs initiales Alors il faut penser a decrire les valeurs initiales pour les variables dans la description de service 26 Chapitre Composition de services 4.1 Introduction Dans ce chapitre, je presente la composition de services qui sont decrits par le modele dans le chapitre precedent L’objectif de l’utilisation de l’automate dans la description de services c’est qu’on peut reutiliser les algorithmes de composition des automates dans la composition de services Quand on compose deux services, il faut avoir des informations supplementaire 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 classi er en deux categories : { Dependance : entre les services, il y a des dependance des informations, service A doit utiliser quelques informations fournies par le servie B et inversement, dans ce cas le service A doit savoir ou ces informations sont stockees dans le service B Donc il faut avoir une mecanisme (synchronisation)qui permet au service A peut obtenir les informations qu’il veut dans le service B { Independance : entre les services il n’y a pas de dependance 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 repondre 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 facons, il faut traduire ces besoin sous un langage que le systeme peut comprendre Par exemple, un client il exprime ses besoin comme : fije veux acheter une voiture et un mobile phone fi alors il faut traduire pour que le systeme 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 seule-ment de savoir quels services sont utilises pour repondre au besoin mais il permet aussi de savoir la facon d’utiliser ses services Autrement dit, on peut savoir comment on peut com-poser les services (synchronisation entre les services) Donc le r^ole du langage de requ^ete est tres important : { permet de decouper les requ^etes du client sous en sous requ^etes, chaque sous requ^ete correspond a un service { decide le type de composer entre les services (synchronisation entre les services) pour repondre 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 entrees et sorties Donc quand on veut decrire les synchronisation entre deux services A et B, on peut decrire que la variable x de A est partagee comme la variable y de B, ou plus precisement on peut decrire les sorties de la fonction f1 dans est les entrees de la fonction f2 dans B Il depend de la langage de description que le serveur de services qu’on peut choisir une facon pour decrire les synchronisations entre le service On peut decrire une synchronisa-tion 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 presenter la composition entre les services, je presente l’algorithme pour composer deux automates On peut utiliser cet algorithme pour les cas de plusieurs auto-mates L’algorithme cherche un automate compose (Q, A, q,t,E) a partir de deux auto-mates (Q1,A1,q1,t1,E1) et (Q2,A2,q2,t2,E2) Algorithme pour composer deux automates De nir l’ensemble Q ( l’ensemble des etats dans l’automate produit) : Q=Q Q2 1 2 ou on peut ecrire Q = fq = (q ; q )jq Q ; q Q g 28 4.3 COMPOSITIONS DES SERVICES De nir l’ensemble A les alphabets dans l’automate produit : A=A [A ou A = faja A oua A g l’etat initial : q = (q ; q ) l’etat nal : t = (t ; t ) 1 2 De nir les transitions E : si (qi ; a; qj ) appartient a E ou (qi ; a; qj ) appartient 2 a E alors ((qi ; qi ); a; (qj ; qj )) appartient a E ou : 2 1 E = f((qi ; qi ); a; (qj ; qj ))j(qi ; a; qj ) E ou (qi2; a; qj 2) E2g 4.3.2 Utilisation de cet algorithme dans la composition des services On voit bien qu’avec le modele qui permet de decrire des service en utilisant les automates On peut utiliser l’algorithme de composer des automates ci-dessus pour composer des services Le service compose est decrit aussi sous ce modele, alors on peut generer le connecteur pour le service compose 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 genere le connecteur Par exemple dans le service A, il utilise une variable x, dans le service B il utilise aussi une variable nommee 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 realise le renommage des variables, des fonctions, des actions, et des conditions Il faut realiser ce changement dans tous les cas et dans tous les services composants Mais il faut faire attention au renommage des fonctions dans le cas ou le service compo-site 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 precedent, les transitions du service compose sont de nies par cet algorithme (on voit dans l’exemple apres) Conditions du service composite : les conditions du service compose sont une union des toutes les conditions des services composants Actions du service composite : les actions du service compose sont une union des toutes les actions des services composants Fonctions du service composite : les fonctions du service compose 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 decrit comme le modele de l’automate dans le chapitre Alors tous ce qu’on presente dans le chapitre precedent peuvent ^etre utilises avec le composite service pour generer 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 generer le connecteur, cette minimisation permet de minimiser le code du connecteur qu’on doit generer Le besoin de minimiser les transitions du composite service vient de : { L’algorithme de composition des automates : apres avoir applique cet algorithme sur des automates, il a besoin des minimisation l’automate resultat 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 precedent, on peut voir bien que l’etat (Atraduire,Terminer2) n’est pas jamais touche Donc pour ce type de minimisation il faut trouver un algorithme e cace 31 Chapitre Conclusion, perspectives Ce stage est realise au laboratoire du Departement d’Informatique de l’ENST Bretagne, et il s’est deroule dans le projet CAMA, l’inter^et de ce travail est de decrire des services dans le cadre de la mobilite et de les composer Apres une etude sur des modeles existantes (EJB, Web service, eFlow, SWORD ), le concept des automates semble le plus adapte pour decrire des services Et en basant sur l’architecture proposee par Kamal Gakhar (un stagiaire du departement l’ annee derniere) on a propose un modele en deux couches pour decrire le services Avec ce modele, on a etudie deux approches pour la generation de connecteur, et ses problemes (le typage, le non deterministe, le back tracking ) La composition des services avec ce modele 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 com-posants { ajouter la description de la synchronisation entre les services { minimise le resultat Pour montrer la composition et la generation des services, un petit programme est ecrit en java Mais il faut l’ameliorer pour qu’il puisse s’integrer dans une plate forme reelles Avec le temps de six mois du stage, il reste encore beaucoup des choses a faire Donc pour les travails dans la future : { Ameliorer le modeles pour trouver des solutions plus e caces pour les problemes de la generation du connecteur et de la composition des service { Chercher a proposer un langage de la description pour les service dans le cas reel { tudier et proposer des solutions pour qu’on puisse ajouter et enlever des services composants pour avoir un service composite satisfaisant des proprietes non fonc-tionnelles : Comment on peut decrire des proprietes 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 distribue avec le Mandrake, c’est le dot ( dans le console tapez man dot pour plus detaille) En fait, le dot travaille comme le Graphviz (open source graph drawing software, developpe par AT&T Labs - Researche) Un chier est ecrit en dot langage comme : digraph nite state machine f 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)" ] ; g est analyse par dot et donne une image resultat comme : 33 Fig A.1 { Imgage generee par l’utile graphviz (http ://www.research.att.com/sw/tools/graphviz/) Dans mon programme, j’implemente la classe Transition2Dot pour generer un chier 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 ; tryf process = runtime.exec("dot -Tpng -o output.png input.dot"; g catch(IOException e)f return ;g if(process != null) f tryf process.waitFor() ; g catch(InterruptedException e)freturn ;g g Le petit programme ci-dessus va generer une chier image (output.png) a partir de chier en dot langage (input.dot) 34 Bibliographie [1] J.Sakarovitch Elements de theorie des automates, Vuibert Informatique, 2003 [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 composition, zones.org/deliverables/D1 1/Svc Composition.pdf, 2003 www.m- [5] F.Casati, S.Ilnicki, L.Jin,V.Krishnamoorthy, M.C.Shan Adaptive and Dynamic Ser-vice Composition in eFlow,http ://www.hpl.hp.com/techreports/2000/HPL2000-39.pdf [6] K.Gakhar Description, Veri cation et Adaptations de composants dans le cadre de systeme 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 ... une etude sur des modeles de la description et de la composition des services La partie et partie presentent notre modele de la description des services, l’utilisation et la composition des services. .. 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,... comme la variable y de B, ou plus precisement on peut decrire les sorties de la fonction f1 dans est les entrees de la fonction f2 dans B Il depend de la langage de description que le serveur de services