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

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.. MOD `ELES EXISTANTScomposit

Institut de la francophonie pour l’informatique

Rapport du stage de fin d’´etudes

R´ealis´e par :

Do Manh Ha promotion 8

Responsables :

Fabien Dagnat Julien Mallet

Hanoi 2005

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 leursaides pendants les jours que je suis `a Brest

Je remercie les vietnammiens `a Brest : Nam, Minh, madame Huong pour leurs gnements, leurs aides

Dans ce rapport, en utilisant cet architecture, je pr´esente notre approche pour ladescription et pour la composition des services en basant la notion de l’automate.

Terminal mobiles appeared and became more popular due to its benifit and since theapplication 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 toadapt 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, Ipresent our approach for the description and for the composition of these services

Table des mati` eres

1.1 Contexte du travail 4

1.2 Sujet d´etaill´e 4

1.3 Le plan du rapport 5

2 ´Etat de l’art 6 2.1 Introduction g´en´erale 6

2.2 Survol du service composite 6

2.2.1 Composition de services 6

2.2.2 Description de service 7

2.2.3 D´ecouverte, Choix de service 7

2.3 Mod`eles existants 7

2.3.1 Web service 8

2.3.2 eFlow 9

2.3.3 EJB 10

2.3.4 JINI 11

2.3.5 SWORD 12

2.4 S´ecurit´e 13

2.5 Performance 13

2.6 Conclusion 13

3 Mod`ele de description de services 15 3.1 Introduction d´etaill´e du stage 15

3.2 Automate 16

3.2.1 Le concept de l’automate 16

3.2.2 Automate et l’ordre d’invocation de fonctions dans un service 17

3.3 Mod`ele propos´e 19

3.3.1 Transitions 19

3.3.2 Conditions 20

3.3.3 Actions 20

3.3.4 Fonctions 21

3.3.5 Corr´elation dans un service 21

3.4 G´en´eration du connecteur 22

3.4.1 La premi`ere approche 22

3.4.2 La deuxi`eme approche 23

TABLE DES MATI `ERES

3.5 Probl`emes et solutions 25

3.5.1 Back-tracking 25

3.5.2 Typage 25

3.5.3 Exceptions 25

3.5.4 Non d´eterministe 26

3.5.5 Boucle infinie 26

3.6 Discutions 26

4 Composition de services 27 4.1 Introduction 27

4.2 Synchronisation entre les services 27

4.2.1 Le besoin du langage de la requˆete 27

4.2.2 Description la synchronisation 28

4.3 Compositions des services 28

4.3.1 Algorimthme de composition des automate 28

4.3.2 Utilisation de cet algorithme dans la composition des services 29

4.4 Conclusion 31

Table des figures

2.1 Architecture du Web service 8

2.2 Mod`ele eFlow 9

2.3 Achitecture de EJB 11

3.1 Architecture propos´ee par GAKHAR 15

3.2 exemple 17

3.3 exemple 18

3.4 Mod`ele propos´e 19

3.5 Une transition 20

3.6 premi`ere approche 23

3.7 Exemple 23

4.1 Exemple : Service de traduction 30

4.2 Exemple : Service d’achat 30

4.3 Exemple : Composite service 30

A.1 Imgage g´en´er´ee par l’utile graphviz 34

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 breuses applications du fait de la multiplication de l’utilisation de terminaux mobiles quichangent fr´equemment de contexte d’ex´ecution Par exemple, si un utilisateur visualiseune 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 lacomposition de services doit ˆetre effectu´ee en prenant en compte les contraintes de qualit´e

nom-de service nom-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 surPDA peut requ´erir la prise en compte de la r´edution de bande de passante et la n´ecessit´ed’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 etd’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 servicesn’int`egre pas (ou peu) leur s´emantique, et ne permet donc pas de garantir une int´egrationcorrecte respectant des contraintes non fonctionnelles De plus, elles ont ´et´e con¸cues pourdes 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

1.3 LE PLAN DU RAPPORT

1 Etudier les diff´erents mod`eles qui permettent de d´ecrire un service, cette ´etudeconcentr´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 laperformance 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 notremod`ele de la description des services, l’utilisation et la composition des services d´ecritspar ce mod`ele La conclusion et perspectives sont dans la partie 5

Chapitre 2

´

Etat de l’art

Aujourd’hui, les utilisateurs peuvent acc´eder `a l’internet, donc `a des services, `a l’aide deleur terminal mobile (PDA, t´el´ephone portable ) ´equip´e d’interfaces de communicationsans fil Ils peuvent consulter la temp´erature, les taux d’´echange Les services qui rendentaccessibles depuis ces terminaux sont de plus en plus complexe comme les achats surl’internet, les consultation de service de m´edecin

A cause de la portabilit´e et de la mobilit´e, les terminaux mobiles ont des limitescomme : la capacit´e de la batterie, la capacit´e de stockage ou ils subissent des contraintescomme : le changement fr´equent de bande de passante, ou la d´econnexion Toutes cescaract´eristiques peuvent causer des probl`emes de maintient de la qualit´e du service Doncles services doivent tenir compte des contraintes venues des terminaux mobiles D’autrepart, les services aujourd’hui qui sont con¸cus pour un environnement statique, pour dessyst`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 sent´ee suivi d’un 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 compositen’est pas une nouvelle notion mais avec l’´emergence des Web services et la capacit´e defournir les services via l’internet, la tendance est aux services

2.3 MOD `ELES EXISTANTS

composition r´eactive : Une composition (un service composite) est compos´ee etcompil´ee avant la demande du client Ce type de composition est appropri´epour les applications stables sur les plate-formes riches en ressources

composition proactive : Le service composite n’est compos´e et compil´e qu’`a lademande 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 composantssont obligatoires Si un composant ne fournit son r´esultat ou retourne unefaute 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´esultatscorrects de tous les composants ne sont pas obligatoires quelques composantspeuvent ne pas participer `a l’ex´ecution du composite service

La composition de services n´ecessite quelques points communs (p.ex structure de sage ´echang´e, description de la corr´elation entre les op´erations) Donc la description estn´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

Un service est disponible quelques part sur l’internet Il faut un processus pour lechercher (d´ecouvrir) Les m´ethodes utilis´ees pour la d´ecouverte sont introduites dansquelques syst`emes comme : JINI, eFlow, DySCo ou UPNP

Apr`es avoir cherch´e, il existe probablement plusieurs services Il faut choisir le plusconvenable pour le prendre Ce travail est r´ealis´e par le Service Broker

Il y a des produits industriels, des mod`eles qui permettent de d´ecrire les services Onpeut lister quelques mod`eles :

introdui-2.3 MOD `ELES EXISTANTS

Un web service est un syst`eme logiciel con¸cu pour supporter l’interaction de machine `amachine au-dessus d’un r´eseau Il y a une interface d´ecrite dans un format exploitable parmachine sp´ecifiquement (WSDL) Les clients (ou d’autres syst`emes) peuvent acc´eder auservice en utilisant le protocole SOAP (Simple Ob ject Access Protocol), mais ces acc`esdoivent 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, tion et interface Au niveau concrˆet sont introduit les concepts : binding et servicemessage : envoy´e ou re¸cu par le service sur le r´eseau

op´era-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

le service de d´ecouverte (p.ex.UDDI1) 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’unservice {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 lamˆ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

sp´e-de services Un graphe se compose sp´e-de sp´e-deux types sp´e-de noeuds : noeud sp´e-de service (une tance de service), noeud de d´ecision (sp´ecifie les r`egles de contrˆole le flux d’ex´ecution)

ins-Un exemple de graphe de processus

Fig 2.2 – Mod`ele eFlow

{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´ecisionqui 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 uneinstance (suivre la d´efinition du processus - le graphe de processus), communiquer avec leBroker 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œudd’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 sieurs fois et en parall`ele, alors l’eFlow introduit multiservice noeud L’eFlow inclutaussi les generic service noeud qui permet de personnaliser un service fournit par lesyst`eme

plu-Modification dynamique de processus de service (Dynamic service process 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

modi-un nouveau sch´ema doit ˆetre d´efini, ensuite c’est modi-une migration du service processinstance 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 lesmodifications concernant un single service process instance : p.ex Il faul changerdes 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 processuspeut avoir plusieurs instances Donc une modification de ce sch´ema de processusdoit s’appliquer sur toutes les instances

EJB est d´evelopp´e par Sun L’id´ee de base est de construire un framework pour que lescomposants 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 cedocument, on liste quelques buts importants :

– Faciliter le travails des d´eveloppeurs Il ne doivent pas s’inqui´eter des d´etails debas niveau du syst`eme (r´esolus par l’EJB framework) : g´erer des transactions, desthreads,

– Le sp´ecification EJB d´efinit une structure de framework EJB (les composants dumod`ele EJB et leurs contrats) Donc les responsabilit´es du client, du serveur, et dechaque composants sont toutes bien d´efinies (par ces contrats)

2.3 MOD `ELES EXISTANTS

– 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

Fig 2.3 – Achitecture de EJB

home interface : client cherche dans le r´epertoire JNDI2 pour obtenir la r´ef´erence duhome objet (qui impl´emente la home interface) En utilisant cette r´ef´erence, le clientpeut 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 quicontient toutes les m´ethodes export´ees de l’objet EJB

L’internet est plus dynamique avec la technologie JINI, elle permet aux dispositifs des’attacher et de se d´etacher du r´eseau sans besoin de reconfiguration Le coeur du syst`emeest le Lookup service o`u les dispositifs et les services sont enregistr´es Quand un dispositifs’attache au r´eseau, il va d´ecouvrir le lookup service et s’y enregistre en fournissant uneinterface pour acc´eder `a ses fonctionnalit´es Le lookup service peut ˆetre d´ecouvert parunicast ou par multicast

d´ecouverte unicast : est utilis´ee quand le service connaˆıt l’IP et le port o`u le Lookupservice ´ecoute Le service va envoyer un paquet de protocole d’unicast d´ecouverte `acet adresse IP et ce port pour s’enregistrer

d´ecouvert multicast : est utilis´ee quand le service ne connaˆıt pas l’adresse du Lookupservice

2 Java Naming et Diretory Interface

2.3 MOD `ELES EXISTANTS

Quand le client veut chercher le service, il utilise le service template pour sp´ecifier semble d’attributs qui servent `a trouver le service appropri´e, et un objet (instance) duservice est retourn´e, le client peut acc´eder `a cet objet

SWORD est un utilitaire pour composer des web services Mais dans le cadre de cerapport 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 estd´ecrit par ses entr´ees et ses sorties Les entr´ees et les sorties sont sp´ecifi´ees dans un worldmodel comprennant les entit´es (personnes, images, cin´emas, films ) et leurs relations (lesfilms sont tourn´es aux cin´emas ) Une entit´e poss`ede des attributs (une personne `a sonnom, 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, estmod´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 X alors on peut connaˆıtre l’adresse et le t´el´ephone

de X Si on utilise le terme known(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 ensembledes termes et un ensemble de r`egles, on peut avoir un service composite `a partir de cesservices Une demande de composer les services sous forme des termes entr´ees et destermes sorties est envoy´ee `a un moteur de SWORD qui se base sur l’emsemble de r`elgesdisponibles, et les termes entr´ees d´eterminer quels services sont utilis´es pour founir lestermes sorties On peut constater pour ce mod`ele se fonctionne de mani`ere similaire `a unsyst`eme expert

2.4 S ´ECURIT ´E

2.4 S´ ecurit´ e

Quand on parle de la s´ecurit´e, on peut compprendre simplement, c’est la protectiondes 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`esaux ressources

La disponibilit´e : permettant de maintenir le bon fonctionnement du syst`eme tique

informa-La non r´epudiation : permettant de garantir qu’une transaction ne peut ˆetre ni´eePour obtenir ces objectifs ci-dessus, les algorithmes de la cryptographie sont utilis´es Onpeut les classifier en deux grande familles : les algorithmes sym´etriques (DES, IDEA) etles algorithmess asym´etriques (RSA) On peut combiner un algorithme sym´etrique et unalgorithme 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´echiffrerl’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´esecrete 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 desservices La description des services doit sp´ecifier la demande de la s´ecurit´e : soit au niveautout le service, soit au niveau chaque op´eration du service

Quand on parle de la performance d’un syst`eme informatique, on parle du temps der´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 avecune petite utilisation de la m´emoire c’est toujours notre attente, mais il voit que c’esttr`es difficile (ou impossible) car le TimePerformance et le SapcePerformance contiennentdans eux-mˆeme des contradictions Donc il faut bien sp´ecifier le but (petit d´elai ou petitem´emoire utilis´ee) d’une application Si on veut une application r´epond vite, probablement,

il faut payer une grande espace de m´emoire

Apr`es avoir ´etudi´e les 5 syst`emes ci-dessus On peut classifier les techniques utilis´eespour la composition des services en trois cat´egories : les templates, les interfaces et lalogique

2.6 CONCLUSION

La technique bas´ee sur les templates : c’est le cas du eFlow, le composition des vices base sur des templates existant Avec cette technique, on peut mod´eliser desservices complexes mais il existe un point faible c’est la flexibilit´e La compositiondes service d´epend du template

ser-La technique bas´ee sur les interfaces : Cette technique base sur les informations 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 partirdes services composants tel qu’elle accepte les entr´ees et les sorties du client Cettetechnique est plus flexible par rapport de la technique bas´ee sur les templates, maiselle manque leur s´emantique

concer-La technique bas´ee sur la logique : c’est le cas du SWORD, cette technique est uneextension de la technique bas´ee sur les interfaces en ajoutant la logique comme lepr´e- et post-condition dans `a l’interface Une demande du client est ´ecrite sous desformules logiques et le service composite est compos´e tel que la conjonction de lalogique 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 entreles composants (les fournisseurs) Tous les composants doivent utiliser la mˆemed´efinitions logique donc il peut causer le probl`eme d’extension

Chapitre 3

3.1 Introduction d´ etaill´ e du stage.

Mon stage est comme la suite du stage de GAKHAR (Description,v´erification et tation de composants dans le cadre de syst`emes mobiles) Le r´esultat de son stage est deproposer une architecture qui se compose de 5 parties (composants) :

Adap-Le client : qui demande des services

Le serveur de services : son travail est de communiquer avec le trader pour obtenirle(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 responsablepar 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