Contexte du travail
Le projet se d´eroule dans l’´equipe CAMA 1 du d´epartement d’informatique de l’ENST Bretagne Cette ´equipe d´eveloppe des recherches dans le domaine ´emergent de l’informa- tique 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.
Sujet d´etaill´e
Les probl´ematiques associ´ees `a ce domaine de recherche apparaissent dans de nom- breuses 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´eces- saire 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 :
1 Composants pour Architectures Mobiles Adaptables
Le plan du rapport
1 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.
2 Proposer un mod`ele qui permet de composer dynamiquement des services
3 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
4 R´ediger le rapport final du stage
Ce rapport se compose de 5 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 3 et partie 4 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.
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´e- sent´ee suivi d’un survol du service composite.
Survol du service composite
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 :
1 Classification bas´ee sur la disponibilit´e du service composite
2.3 MOD `ELES EXISTANTS composition r´eactive : Une composition (un service composite) est compos´ee et compil´ee avant la demande du client Ce type de composition est appropri´e pour les applications stables sur les plate-formes riches en ressources. composition proactive : Le service composite n’est compos´e et compil´e qu’`a la demande du client Ce type de composition est utilis´e quand les composants ne sont pas stables ou le nombre de demande du client est petit.
2 Classification bas´ee sur la pr´esence des composants Service composite oblagatoire : Les r´esultats corrects de tous les composants sont obligatoires Si un composant ne fournit son r´esultat ou retourne une faute r´esultat, alors le service composite ne peut pas fournir un r´esultat correct
Service composite optionnel : `a l’oppos´e de la cat´egorie ci-dessus Les r´esultats corrects de tous les composants ne sont pas obligatoires quelques composants peuvent ne pas participer `a l’ex´ecution du composite service.
Description de service
La composition de services n´ecessite quelques points communs (p.ex structure de mes- sage ´echang´e, description de la corr´elation entre les op´erations) Donc la description est n´ecessaire pour la composition de service Des langages de description de service (WSDL,WSCL, WSFL, XLANG) sont, aujourd’hui, limit´es Il leur manque la description s´eman- tique.
D´ecouverte, Choix de service
Un service est disponible quelques part sur l’internet Il faut un processus pour le chercher (d´ecouvrir) Les m´ethodes utilis´ees pour la d´ecouverte sont introduites dans quelques syst`emes comme : JINI, eFlow, DySCo ou UPNP.
Apr`es avoir cherch´e, il existe probablement plusieurs services Il faut choisir le plus convenable pour le prendre Ce travail est r´ealis´e par le Service Broker
Mod`eles existants
Web service
Un web service est un syst`eme logiciel conácu pour supporter l’interaction de machine `a machine au-dessus d’un r´eseau Il y a une interface d´ecrite dans un format exploitable par machine sp´ecifiquement (WSDL) Les clients (ou d’autres syst`emes) peuvent acc´eder au service en utilisant le protocole SOAP (Simple Ob ject Access Protocol), mais ces acc`es doivent suivre son interface{www.w3.org/TR/ws-arch/#id2263315}.
Le langage WSDL (Web Service Description Langage) est d´evelopp´e par le W3C (World Wide Web Consortium) Il d´ecrit une interface en deux ´etapes : une abstraite et une concr`ete Au niveau abstraite il y a des descriptions concernant : message, op´era- tion et interface Au niveau concrˆet sont introduit les concepts : binding et service message : envoy´e ou reácu par le service sur le r´eseau op´eration : associ´ee `a une ´echange de messages interface : groupe d’op´erations binding : l’interface est acc´ed´ee via une adresse (endpoint) service : collection des endpoints qui impl´ementent une interface commune
Fig 2.1 – Architecture du Web service
{www.w3.org/TR/ws-arch/#WSDL} WSD : Description de Web Service ; FD : Description de fonctionnalit´e ;
1 Une description du web service (en WSDL) permet de connaˆıtre ses fonctionnalit´es, les param`etres de chaque fonctionnalit´e, o`u on le trouve, Cette description est publi´ee quelque part Quand un client a besoin d’un service, il invoque, tout d’abord, le service de d´ecouverte (p.ex.UDDI 1 ) pour obtenir la description de service, donc
1 Universal Description, Discovery, and Integration
2.3 MOD `ELES EXISTANTS son URL En fait il a une ´etroite relation entre la publicit´e et la d´ecouverte d’un service {http ://www.w3.org/TR/ws-arch/#WSDL}, partie 3.4.2 pour savoir plus.
2 Le client et le serveur (fournisseur) mettent d’acord sur la mˆeme description et la mˆeme s´emantique du service
3 la description et la s´emantique de service sont entr´ees dans l’agent de client et l’agent de fournisseur.
4 l’agent de client et l’agent de fournisseur ´echangent des messages de SOAP pour r´ealiser le service.
eFlow
eFlow est d´evelopp´e par HP, c’est un plate-forme offrant des m´ecanismes pour : sp´e- cifier, ´etablir et g´erer les services composites Un service composite est d´ecrit (sp´ecifi´e) comme un processus compos´e de services de base ou d’autre services composites Visuel- lement, un service composite est mod´elis´e par un graphe qui d´efinit le flux d’ex´ecution de services Un graphe se compose de deux types de noeuds : noeud de service (une ins- tance de service), noeud de d´ecision (sp´ecifie les r`egles de contrˆole le flux d’ex´ecution).
Un exemple de graphe de processus.
{www.hpl.hp.com/techreports/2000/HPL-2000-39.pdf}
Dans le sh´ema ci-dessus, les boˆıtes rondes (Data colection, Reservation, Invitation ) repr´esentent les invocations de services La barre horizontale est un noeud de d´ecision qui est utilis´e pour sp´ecifier les invocations parall`eles des services Un service est sp´ecifi´e
2.3 MOD `ELES EXISTANTS par un graphe de processus Une r´ealisation de ce graphe est un service process instance. l’Architecture d’eFlow est compos´ee des trois entit´es suivantes : – le moteur d’eFlow
– le syst`eme de d´ecouverte des services (Broker) – les services ´el´ementaires
Le rˆole du moteur d’eFlow est tr`es important Il r´ealise le service process instance : mettre `a jour les ´etats des noeuds de services, d´ecider les noeuds qui sont activ´es dans une instance (suivre la d´efinition du processus - le graphe de processus), communiquer avec le Broker pour d´ecouvrir les services (consulter {www.hpl.hp.com/techreports/2000/HPL- 2000-39.pdf}) L’eFlow offre les propri´et´es suivantes :
Processus adaptatif de service (Adaptative service process) : la sp´ecification du nœud d’ex´ecution inclut la description du service qui sera invoqu´e et ainsi que la sp´ecifica- tion de la r`egle de choisir le service, il permet une d´ecouverte dynamique de service.
L’usager peut aussi remplacer le service broker par le nouveau qui est le plus adapt´e
`a ses besoins Dans quelques cas, un service compos´e doit appeler un service plu- sieurs fois et en parall`ele, alors l’eFlow introduit multiservice noeud L’eFlow inclut aussi les generic service noeud qui permet de personnaliser un service fournit par le syst`eme.
Modification dynamique de processus de service (Dynamic service process modi- fication) : l’eFlow permet de changer la composition de service Le sch´ema de proces- sus peut ˆetre chang´e quand le service fonctionne Pour le changement, tout d’abord un nouveau sch´ema doit ˆetre d´efini, ensuite c’est une migration du service process instance du sch´ema courant vers le nouveau sch´ema Il y a deux types de la mo- dification de processus : ad-hoc change et bulk change Ad-hoc change sp´ecifie les modifications concernant un single service process instance : p.ex Il faul changer des r`egle de choisir les services dans certains noeuds.Bulk change sp´ecifie les modi- fications concernant tous les service process instance : p.ex un sch´ema de processus peut avoir plusieurs instances Donc une modification de ce sch´ema de processus doit s’appliquer sur toutes les instances
EJB
EJB est d´evelopp´e par Sun L’id´ee de base est de construire un framework pour que les composants puissent ˆetre attach´ees au serveur, ils permettent d’augmenter les fonctionna- lit´es du serveur{http ://www.javaworld.com/javaworld/jw-10-1998/jw-10-beans-p2.html} EJB a quelques buts d´efinis par Sun {http ://www.java.sun.com/products/ejb} Dans ce document, on liste quelques buts importants :
– Faciliter le travails des d´eveloppeurs Il ne doivent pas s’inqui´eter des d´etails de bas niveau du syst`eme (r´esolus par l’EJB framework) : g´erer des transactions, des threads,
– Le sp´ecification EJB d´efinit une structure de framework EJB (les composants du mod`ele EJB et leurs contrats) Donc les responsabilit´es du client, du serveur, et de chaque composants sont toutes bien d´efinies (par ces contrats).
– EJB vise `a ˆetre un standard pour construire les applications client/serveur en java.
Il permet de combiner les composants de diff´erents fournisseurs sans re-compilation.
{http ://www.oreilly.com/catalog/entjbeans/chapter/ch02.html#62215}
Un serveur d’application EJB, fournit des fonctionnalit´es (g´erer des ressources) uti- lis´ees par les conteneurs, o`u les objets EJBs (Entreprise Bean) op`erent Le serveur EJB et les conteneurs fournissent un l’envirronement pour les objects EJB, la stablit´e et la s´ecurit´e sont assur´ees par cet environnement, donc le conteneur et le serveur EJB.
Un Entreprise Bean est un objetserver side, et il est conform´e `a la sp´ecification EJB.
Pour le d´eveloppement un objet EJB, il faut d´efinir deux interfaces : home interface et remote interface : home interface : client cherche dans le r´epertoire JNDI 2 pour obtenir la r´ef´erence du home objet (qui impl´emente lahome interface) En utilisant cette r´ef´erence, le client peut obtenir la r´ef´erence de l’objet EJB (en appelant la m´ethode create()). remote interface : le client acc´ede `a l’objet EJB `a travers la remote interface qui contient toutes les m´ethodes export´ees de l’objet EJB
JINI
L’internet est plus dynamique avec la technologie JINI, elle permet aux dispositifs de s’attacher et de se d´etacher du r´eseau sans besoin de reconfiguration Le coeur du syst`eme est leLookup service o`u les dispositifs et les services sont enregistr´es Quand un dispositif s’attache au r´eseau, il va d´ecouvrir le lookup service et s’y enregistre en fournissant une interface pour acc´eder `a ses fonctionnalit´es Le lookup service peut ˆetre d´ecouvert par unicast ou par multicast. d´ecouverte unicast : est utilis´ee quand le service connaˆıt l’IP et le port o`u le Lookup service ´ecoute Le service va envoyer un paquet de protocole d’unicast d´ecouverte `a cet adresse IP et ce port pour s’enregistrer. d´ecouvert multicast : est utilis´ee quand le service ne connaˆıt pas l’adresse du Lookup service.
2 Java Naming et Diretory Interface
Quand le client veut chercher le service, il utilise le service template pour sp´ecifier l’en- semble d’attributs qui servent `a trouver le service appropri´e, et un objet (instance) du service est retourn´e, le client peut acc´eder `a cet objet.
SWORD
SWORD est un utilitaire pour composer des web services Mais dans le cadre de ce rapport on ne peux pr´esenter que des id´ees principales de SWORD (si vous ˆetes int´e- ress´es, veuillez visiter {http ://www2002.org/CDROM/alternate/786/}) Un service est d´ecrit par ses entr´ees et ses sorties Les entr´ees et les sorties sont sp´ecifi´ees dans unworld model comprennant les entit´es (personnes, images, cin´emas, films ) et leurs relations (les films sont tourn´es aux cin´emas ) Une entit´e poss`ede des attributs (une personne `a son nom, son pr´enom, adresse, ) Par exemple un service qui retourne l’adresse et le num´ero de t´el´ephone d’une personne si on le fournit son nom, son pr´enom, son pays, sa ville, est mod´elis´e comme :
Entities involved : X Condition Inputs : Person(X) - indicates that X is person entity Data Inputs : firstname(X), lastname(X), city(X), state(X) -indicates that the service needs these four attributes of X Condition Outputs :
None - no condition ouputs for this service Data outputs : streetaddress(X), phone(X)
- indicates that the street adress and the phone of the per- son X are returned.
Avec ce mod`ele, un service est mod´elis´e par un l’emsemble de termes comme : pesonne(X), firsname(X) et des r`egles de d´eduction, par exemple :si X est un personne et on connaˆıt le nom, le pr´enom , la ville et le pays de Xalors on peut connaˆıtre l’adresse et le t´el´ephone de X Si on utilise le termeknown(firstname X) pour signifier qu’on connaˆıt le pr´enom de
X On peut ´ecrire la r`egle pr´ec´edente comme :
Si personne(X) & known(firstname X) & known(lastname X) & known( city X) & known( state X) alors known(streetadress X) & known(phone X)
La r`egle pr´ec´edente est encore divis´ee en deux r`egles sous forme de l’Horn Donc si on a un ensemble de services mod´elis´es par le world model, c’est `a dire qu’on a un ensemble des termes et un ensemble de r`egles, on peut avoir un service composite `a partir de ces services Une demande de composer les services sous forme des termes entr´ees et des termes sorties est envoy´ee `a un moteur de SWORD qui se base sur l’emsemble de r`elges disponibles, et les termes entr´ees d´eterminer quels services sont utilis´es pour founir les termes sorties On peut constater pour ce mod`ele se fonctionne de mani`ere similaire `a un syst`eme expert.
S´ecurit´e
Quand on parle de la s´ecurit´e, on peut compprendre simplement, c’est la protection des informations L’objectifs principaux de la s´ecutit´e informatique sont :
L’int´egrit´e : c’est-`a-dire garantir que les donn´ees sont bien celles qu’on croit ˆetre
La confidentialit´e : consistant `a assurer que seules les personnes autoris´ees aient acc`es aux ressources
La disponibilit´e : permettant de maintenir le bon fonctionnement du syst`eme informa- tique
La non r´epudiation : permettant de garantir qu’une transaction ne peut ˆetre ni´ee
Pour obtenir ces objectifs ci-dessus, les algorithmes de la cryptographie sont utilis´es On peut les classifier en deux grande familles : les algorithmes sym´etriques (DES, IDEA) et les algorithmess asym´etriques (RSA) On peut combiner un algorithme sym´etrique et un algorithme asym´etrique pour avoir un syst`eme cryptographique `a la cl´e session (PGP). l’algorithme sym´etrique : une cl´e secrete est utilis´ee pour chiffrer et pour d´echiffrer l’algorithme asym´etrique : le chiffrement et le d´echiffrement utilisent deux cl´es diff´e- rentes : une cl´e priv´ee et une cl´e publique. le syst`eme `a la cl´e section : l’algorithme asym´etrique est utilis´e pour ´echanger la cl´e secrete qui est utilis´ee pour chiffrer les donn´ees `a envoyer.
Donc, un emsemble des utiles de la cryptographie est n´ecessaire pour la s´ecurit´e des services La description des services doit sp´ecifier la demande de la s´ecurit´e : soit au niveau tout le service, soit au niveau chaque op´eration du service.
Performance
Quand on parle de la performance d’un syst`eme informatique, on parle du temps de r´eponse, l’espace de m´enoire utilis´ee, ou la volume de donn´ees transf´er´ee sur le r´eseau.
Donc la performace peut classifier en deux sous-types : TimePerformance et SpacePer- formance Une application qui peut r´epondre `a un demande dans un petit d´elai et avec une petite utilisation de la m´emoire c’est toujours notre attente, mais il voit que c’est tr`es difficile (ou impossible) car le TimePerformance et leSapcePerformance contiennent dans eux-mˆeme des contradictions Donc il faut bien sp´ecifier le but (petit d´elai ou petite m´emoire utilis´ee) d’une application Si on veut une application r´epond vite, probablement, il faut payer une grande espace de m´emoire.
Conclusion
Apr`es avoir ´etudi´e les 5 syst`emes ci-dessus On peut classifier les techniques utilis´ees pour la composition des services en trois cat´egories : les templates, les interfaces et la logique.
La technique bas´ee sur les templates : c’est le cas du eFlow, le composition des ser- vices base sur des templates existant Avec cette technique, on peut mod´eliser des services complexes mais il existe un point faible c’est la flexibilit´e La composition des service d´epend du template.
La technique bas´ee sur les interfaces : Cette technique base sur les informations concer- nant les interfaces des services composants (les op´erations, les entr´ees, les sorties ) pour composer le composite service Quand un utilisateur demande une applica- tion en donnant ses entr´ees et ses sorties, cette application est compos´ee `a partir des services composants tel qu’elle accepte les entr´ees et les sorties du client Cette technique est plus flexible par rapport de la technique bas´ee sur les templates, mais elle manque leur s´emantique.
La technique bas´ee sur la logique : c’est le cas du SWORD, cette technique est une extension de la technique bas´ee sur les interfaces en ajoutant la logique comme le pr´e- et post-condition dans `a l’interface Une demande du client est ´ecrite sous des formules logiques et le service composite est compos´e tel que la conjonction de la logique sp´ecifi´ee dans les services composants satisfait la demande de l’utilisateur.
Cette technique a un point faible, c’est de distribuer les d´efinitions logiques entre les composants (les fournisseurs) Tous les composants doivent utiliser la mˆeme d´efinitions logique donc il peut causer le probl`eme d’extension.
Chapitre 3Mod` ele de description de services
Introduction d´etaill´e du stage
Mon stage est comme la suite du stage de GAKHAR (Description,v´erification et Adap- tation 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 de services : son travail est de communiquer avec le trader pour obtenir le(s) service(s).
Le trader : qui est charg´e de trouver le(s) meilleur service(s) en basant sur la requˆete du client
Le connecteur : est g´en´er´e automatiquement par le serveur de services, il travaille comme un middle-ware entre le client et le(s) service(s), leurs interactions sont responsable par ce connecteur.
Le(s) service(s) : un ensemble de fonctionnalit´es qui sont group´ees pour r´ealiser une ou plusieurs tˆaches.
Fig 3.1 – Architecture propos´ee par GAKHAR
Automate
Le concept de l’automate
Notre approche est d’utiliser le concept de l’automate pour d´ecrire le services La th´eorie de l’automate est beaucoup d´evelopp´ee, elle est utilis´ee naturellement dans la th´eorie de la langage et plus il y a des algorithmes qui permettent de composer des automates Dans notre approche, on utilise le concept de l’automate d’´etats finis Un automate AF (Q,A,I,T,E) est sp´ecifi´e par les donn´es des ´el´ements suivants :
1 un ensemble Q, non vide appel´e ensemble des ´etats de AF.
2 un ensemble A, non vide ´egalement, appel´e alphabet de AF.
3 deux sous-ensembles I et T de Q ; I est l’ensemble des ´etats initiaux, et T est l’en- semble des ´etats finals (ou terminaux) de AF.
4 un sous-ensemble E de Q x A x Q, appel´e ensemble de transition de AF.
Avant de pr´esenter notre approche, un exemple d’un service sur l’internet, c’est le service d’acheter des marchandise sur cdiscount (http ://www.cdiscount.com) Pour ache- ter un souris sur cdiscount, tout d’abord on va connecter au service , une page web est affich´ee, on va choisir le souris qu’on pr´ef`ere pour ajouter au panier, d`es que on valide le panier, (vous pouvez choisir plusieurs choses pour ajouter au panier avant de valider le panier) une nouvelle page est apparue pour demander nos informations comme le nom,l’adresse, le code postal, le t´el´ephone, le courrier ´electronique , ces informations sont uti- lis´ees pour la livraison et pour envoyer des informations concernant de l’achat (le somme
3.2 AUTOMATE. total, et des services clients offerts par cdiscount ) Finalement c’est le payement, il y a quelques m´ethodes accept´ees par le cdiscount comme : le ch`eque, le virement Quand le cdiscount, reácoit l’agent, il va emballer les marchandise et l’envoyer par le service de la poste.
Automate et l’ordre d’invocation de fonctions dans un service
Dans l’exemple pr´ec´edent, on voit bien que quand on utilise un service, il faut respecter l’ordre d’ex´ecution des fonctions de ce service, on ne peut pas utiliser la fonction pour valider le panier avant d’appeler la fonction pour choisir les marchandises Donc quand on veut composer des services, il faut d´ecrire les ordres des fonctions.
Dans un service, l’invocation d’une fonction peut-ˆetre d´ependre du r´esultat de l’ex´e- cution d’une autre fonction Par exemple, si A donne un r´esultat positif, on appelle B et si non la fonction C est invoqu´ee Donc il faut d´ecrire la pr´e-condition pour chaque action de l’invocation d’une fonction Dans l’exemple pr´ec´edent, il faut d´ecrire que la action pour valider le panier ne peut ˆetre invoqu´ee quand le panier est vide.
Exemple : Supposons qu’on a un service qui permet d’acheter un v´elo sur l’internet.
Pour utiliser ce service, il faut invoquer trois fonctions : – login : si le client s’est bien connect´e au service, il va donner un id positif au client et si non une valeur n´egative est rentr´ee (on utilise les entier pour le type de id) – choisir : cette fonction va rentrer une r´ef´erence du v´elo que le client a choisi (dans le cas si on veut choisir plusieurs choses, il faut utiliser une liste de r´ef´erences comme le cas panier sur le cdiscount) Cette fonction est appel´ee seulement si le id est positif – payer : cette fonction va prendre la r´ef´erence (liste de r´ef´erences) du v´elo pour calculer la somme de l’agent `a payer Cette fonction est appel´ee seulement si la r´ef´erence (liste de r´ef´erences) n’est pas vide.
Il y a au moins deux faácon de pr´esenter la suite de l’invocation des fonctions dans le service pr´ec´edent Dans la premi`ere faácon on associe les actions de l’invocation les fonctions avec les ´etat de l’automate et une transition de l’´etat A `a l’´etat B est valid´ee par les pr´e conditions de l’action (l’invocation de la fonction du service) associ´ee avec l’´etat
B On voit la figure ci-dessous :
Dans la deuxi`eme faácon, les actions sont associ´ees avec les transitions de l’automate et
3.2 AUTOMATE. elles sont valid´ees par les pr´e conditions de l’action (l’invocation de la fonction du service) qui sont associ´ees avec On voit la figure ci-dessous :
Le deuxi`eme faácon est plus naturelle que la premi`ere faácon par rapport de la d´efini- tion de l’automate Alors on peut utiliser les algorithmes de compositions de l’automate directement sur elle sans avoir besoin les modifications.
Un automate comme ci-dessus peut ´ecrire sous le langage XML comme :
Dans le petit exemple ci-dessus, on mets directement les conditions et les actions dans la description de la transition Ce n’est pas une bonne solution, car dans le cas g´en´eral une condition ou une action est plus complexe que l’exemple pr´ec´edent Une action peut contenir plusieurs invocations de plusieurs fonctions, et une condition peut contenir plusieurs sous conditions Donc il est meilleur qu’on d´ecrit les actions dans sa propre place et chaque action est identifi´e par son nom par exemple, et pour les conditions
Mod`ele propos´e
Transitions
Pour d´ecrire une transition, on a d´ej`a discut´e dans les parties pr´ec´edentes Dans cette partie je fais simple un r´esum´e Une transition se compose en g´en´eral :
1 Le nom de l’´etat d´epart et le nom de l’´etat arriv´ee.
2 La (les) conndition(s) : o`u on ne d´ecrit que ses identifications
3 La (les) action(s) : o`u on ne d´ecrit que ses identifications Par exemple : On peut d´ecrire la transition suivante :
La condition ”loginOk” et l’action ”loginOk” ne sont pas d´ecrites ici, elles sont d´ecrites dans les deux parties suivantes
Conditions
Si une transition veut ˆetre valid´ee, alors la condition associ´ee avec elle doit ˆetre vraie.
On peut classifier les conditions en deux types : condition simple et condition complexe.
Exemple : simple : si ( a >5) complexe : si ((a >5) && (b > 5))
La condition simple prend deux arguments et une op´eration de comparaison ( >, =,
0 alors{ ok = choisir(id,ref);
} } fonction AvantPayer(){ si ! ok alors{ ok = choisir(id,ref);
} si ok et ref null alors{ payer(id,ref);
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.
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 ();
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 = ´etat initial algorithme(x) si x est un ´etat final alors le service est d´ej`a bien utilis´e sinon sauvegarder les valeurs des variables `a l’´etat x; pour chaque ´etat 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;
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.
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
(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
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.
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.
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
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.
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.
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.
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.
Synchronisation entre les services
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.
Quand le besoin du client est ´ecrit par un langage de requˆete, il ne permet pas seule- ment 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 com- poser 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.
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 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.
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 auto- mates L’algorithme cherche un automate compos´e (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
1 D´efinir l’ensemble Q ( l’ensemble des ´etats dans l’automate produit) :
2 D´efinir l’ensemble A les alphabets dans l’automate produit :
5 D´efinir les transitions E : si (qi 1, a, qj 1) appartient `a E 1 ou (qi 2, a, qj 2) appartient `a
E ={((qi 1, qi 2), a,(qj 1, qj 2))|(qi 1, a, qj 1)∈E 1 ou (qi 2, a, qj 2)∈E 2 }
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 auto- mates 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 condi- tions 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 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 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
3 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
4.3 COMPOSITIONS DES SERVICES exemple :On compose deux services suivants : service 1 :Service de traduction :
Fig 4.1 – Exemple : Service de traduction service 2 :Service d’achat
Fig 4.2 – Exemple : Service d’achat service composite :
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.
Ce stage est r´ealis´e au laboratoire du D´epartement d’Informatique de l’ENST Bre- tagne, 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 com- posants
– 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 fonc- tionnelles : Comment on peut d´ecrire des propri´et´es non fonctionnelles et comment on peut les utiliser.
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 0 LR 3 LR 4 LR 8 ; node [shape = circle] ;
LR 8 ->LR 5 [ label = ”S(a)” ] ; } est analys´e par dot et donne une image r´esultat comme :
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)