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

Institut de la francophonie pour l’informatique

Rapport du stage de fin d’´etudes

Mod´
elisation des services dans le
cadre de la mobilit´
e
R´ealis´e par :

Do Manh Ha
promotion 8
Responsables :

Fabien Dagnat
Julien Mallet

Hanoi 2005


Remerciement
Je tiens a` remercier les profresseurs a` l’intitut de la francophonie pour l’informatique
(IFI), o`
u je pr´epare mon DEA
J’addresse mes remercients les plus sinc`eres a` Fabien Dagnat et Julien Mallet du
´
d´epartement informatique de l’Ecole
Normale Sup´erieure des T´elescommunications de
Bretgane, d’avoir encadr´e pour ce travail.
Je remercie les professeurs, et les membres du d´epartement informatique, de MAISEL,
´

de RESEL de l’Ecole
Normale Sup´erieure des T´elescommunication de Bretgane pour leurs
aides pendants les jours que je suis a` Brest.
Je remercie les vietnammiens a` Brest : Nam, Minh, madame Huong pour leurs renseignements, leurs aides


R´esum´e
Les terminaux mobiles sont apparus et deviennent populaires aujourd’hui grˆace a` leurs
pratiques. Parall`element avec cet apparition, c’est les applications sur ces terminaux.
A cause de la caract´eristique du terminal mobile : portabilit´e, bas de performance ...
les applications sur les terminaux mobiles (services mobiles) face aux fr´equentes changements de leurs contextes d’ex´ecution. Donc les services mobiles doivent adapter a` ces
changements. C’est la raison pour laquelle une architecture avec une couche interm´ediaire
est utilis´ee.
Dans ce rapport, en utilisant cet architecture, je pr´esente notre approche pour la
description et pour la composition des services en basant la notion de l’automate.


Abstract
Terminal mobiles appeared and became more popular due to its benifit and since the
application based on that terminal mobiles have developed.
Because of the terminal mobiles ’specific characteristic, the service mobiles have faced
to the frequent change of the execution context. So these services must have capacity to
adapt to that change. For this reason, an architecture with an intermidiate layer is used.
In this report, by using this architecture and basing on the notion of the automat, I
present our approach for the description and for the composition of these services


Table des mati`
eres
1 Introduction

1.1 Contexte du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Sujet d´etaill´e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Le plan du rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
´
2 Etat
de l’art
2.1 Introduction g´en´erale . . . . . . . . .
2.2 Survol du service composite . . . . .
2.2.1 Composition de services . . .
2.2.2 Description de service . . . .
2.2.3 D´ecouverte, Choix de service .
2.3 Mod`eles existants . . . . . . . . . . .
2.3.1 Web service . . . . . . . . . .
2.3.2 eFlow . . . . . . . . . . . . .
2.3.3 EJB . . . . . . . . . . . . . .
2.3.4 JINI . . . . . . . . . . . . . .
2.3.5 SWORD . . . . . . . . . . . .
2.4 S´ecurit´e . . . . . . . . . . . . . . . .
2.5 Performance . . . . . . . . . . . . . .
2.6 Conclusion . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.

3 Mod`
ele de description de services
3.1 Introduction d´etaill´e du stage. . . . . . . .
3.2 Automate. . . . . . . . . . . . . . . . . . .
3.2.1 Le concept de l’automate . . . . . .
3.2.2 Automate et l’ordre d’invocation de
3.3 Mod`ele propos´e . . . . . . . . . . . . . . .
3.3.1 Transitions . . . . . . . . . . . . .
3.3.2 Conditions . . . . . . . . . . . . . .
3.3.3 Actions . . . . . . . . . . . . . . .
3.3.4 Fonctions . . . . . . . . . . . . . .
3.3.5 Corr´elation dans un service . . . .
3.4 G´en´eration du connecteur. . . . . . . . . .
3.4.1 La premi`ere approche . . . . . . . .
3.4.2 La deuxi`eme approche . . . . . . .
1

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
fonctions dans un service
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

4
4
4
5

.
.
.
.
.
.
.

.
.
.
.
.
.
.

6
6
6
6
7
7
7
8
9
10
11
12
13
13
13

.
.
.
.
.
.

.
.
.
.
.
.
.

15
15
16
16
17
19
19
20
20
21
21
22
22
23


`
TABLE DES MATIERES
3.5

3.6

Probl`emes et solutions .
3.5.1 Back-tracking . .
3.5.2 Typage . . . . . .
3.5.3 Exceptions . . . .
3.5.4 Non d´eterministe
3.5.5 Boucle infinie . .
Discutions. . . . . . . . .

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.

.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.

.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.

.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.

.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.

.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

4 Composition de services
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2 Synchronisation entre les services . . . . . . . . . . . . . . . . . . . .
4.2.1 Le besoin du langage de la requˆete . . . . . . . . . . . . . . .
4.2.2 Description la synchronisation . . . . . . . . . . . . . . . . . .
4.3 Compositions des services . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Algorimthme de composition des automate . . . . . . . . . . .
4.3.2 Utilisation de cet algorithme dans la composition des services.
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

25
25
25
25
26
26
26

.
.
.
.

.
.
.
.

27
27
27
27
28
28
28
29
31

5 Conclusion, perspectives

32

Annexe

33

A Dot langage

33

2

Table des figures
2.1
2.2
2.3

Architecture du Web service
Mod`ele eFlow . . . . . . .
Achitecture de EJB . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1
3.2
3.3
3.4
3.5
3.6
3.7

Architecture propos´ee par GAKHAR
exemple . . . . . . . . . . . . . .
exemple . . . . . . . . . . . . . .
Mod`ele propos´e . . . . . . . . . .
Une transition . . . . . . . . . . .
premi`ere approche . . . . . . . . .
Exemple . . . . . . . . . . . . . .

4.1

4.2
4.3

Exemple : Service de traduction
Exemple : Service d’achat . .
Exemple : Composite service .

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.

.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.

.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.

.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

15
17
18
19
20
23
23

. . . . . . . . . . . . . . . . . . . . . . . . . . . 30
. . . . . . . . . . . . . . . . . . . . . . . . . . . 30
. . . . . . . . . . . . . . . . . . . . . . . . . . . 30

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

3


Chapitre 1
Introduction
1.1

Contexte du travail

Le projet se d´eroule dans l’´equipe CAMA1 du d´epartement d’informatique de l’ENST
Bretagne. Cette ´equipe d´eveloppe des recherches dans le domaine ´emergent de l’informatique nomade. La recherche envisage de proposer une couche interm´ediaire (gestionaire
des services), qui permet d’adapter une application mobile aux fr´equentes changements
de son contexte d’ex´ecution.

1.2

Sujet d´
etaill´
e

Les probl´ematiques associ´ees a` ce domaine de recherche apparaissent dans de nombreuses applications du fait de la multiplication de l’utilisation de terminaux mobiles qui
changent fr´equemment de contexte d’ex´ecution. Par exemple, si un utilisateur visualise
une image haute d´efinition sur son ´ecran de bureau et sort du bˆatiment, il peut ˆetre n´ecessaire de passer a` une d´efinition inf´erieure pour la regader sur l’´ecran d’un PDA. De plus la
composition de services doit ˆetre effectu´ee en prenant en compte les contraintes de qualit´e
de service des applications, qu’elles soient fonctionnelles ou non fontionnelles (s´ecurit´e,
performance, fiabilit´e ou passage l’´echelle). Dans l’exemple pr´ec´edent, la consultation sur
PDA peut requ´erir la prise en compte de la r´edution de bande de passante et la n´ecessit´e

d’augmenter la s´ecurit´e des communications
Il existe des produits industriels et des standards qui d´ecrivent la notion de service
de composant (p.ex. EJB, Web service) qui sont associ´es a` des syst`emes de d´ecouverte et
d’utilisation de service permetant leur int´egration dynamique (p.ex. JINI, UnPN, UDDI).
Toutefois ces approches pramatiques sont, a` ce jour, limit´ees. La description des services
n’int`egre pas (ou peu) leur s´emantique, et ne permet donc pas de garantir une int´egration
correcte respectant des contraintes non fonctionnelles. De plus, elles ont ´et´e con¸cues pour
des environnement statiques ferm´es ce qui rend difficile l’adaption dynamique des services
au contexte d’ex´ecution.
Donc, le travail de ce stage se d´ecompose en tˆache de mani`ere suivante :
1

Composants pour Architectures Mobiles Adaptables

4


1.3. 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

1.3

Le plan du rapport

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.

5


Chapitre 2
´
Etat
de l’art
2.1

Introduction g´
en´
erale

Aujourd’hui, les utilisateurs peuvent acc´eder a` l’internet, donc a` des services, a` l’aide de
leur terminal mobile (PDA, t´el´ephone portable ...) ´equip´e d’interfaces de communication
sans fil. Ils peuvent consulter la temp´erature, les taux d’´echange ... Les services qui rendent
accessibles depuis ces terminaux sont de plus en plus complexe comme les achats sur
l’internet, les consultation de service de m´edecin...
A cause de la portabilit´e et de la mobilit´e, les terminaux mobiles ont des limites
comme : la capacit´e de la batterie, la capacit´e de stockage... ou ils subissent des contraintes
comme : le changement fr´equent de bande de passante, ou la d´econnexion ... Toutes ces
caract´eristiques peuvent causer des probl`emes de maintient de la qualit´e du service. Donc
les services doivent tenir compte des contraintes venues des terminaux mobiles. D’autre
part, les services aujourd’hui qui sont con¸cus pour un environnement statique, pour des
syst`emes ferm´es, ne sont pas convenable pour un environnement mobile.

Dans les parties suivantes, une ´etude sur des produits, des mod`eles existants est pr´esent´ee suivi d’un survol du service composite.

2.2

Survol du service composite

Un service composite est une composition de plusieurs services existants afin d’obtenir
un service plus complexe qui peut r´epondre aux besoinxs de l’usager. Le service composite
n’est pas une nouvelle notion mais avec l’´emergence des Web services et la capacit´e de
fournir les services via l’internet, la tendance est aux services.

2.2.1

Composition de services

Il y a plusieurs fa¸cons de classifier la composition de services, dans le cadre de ce
document, nous’en pr´esentons deux :
1. Classification bas´ee sur la disponibilit´e du service composite

6


`
2.3. MODELES
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.

2.2.2

Description de service

La composition de services n´ecessite quelques points communs (p.ex. structure de message ´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´emantique.

2.2.3

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

2.3

Mod`
eles existants

Il y a des produits industriels, des mod`eles qui permettent de d´ecrire les services. On
peut lister quelques mod`eles :
1. Web sevice
2. eFlow
3. EJB
4. JINI
5. ATL Postmaster
6. Ninja....
Mais ´etant limit´e par le temps, nous ne pouvons pas tous les pr´esenter. nous introduisons quelques mod`eles (produits), qui ont, d’apr`es nous, des int´erˆets .
7


`
2.3. MODELES
EXISTANTS

2.3.1

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´eration 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 ;
Sem : S´emantique
Explication :
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.UDDI1 ) pour obtenir la description de service, donc
1

Universal Description, Discovery, and Integration

8


`
2.3. MODELES
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.

2.3.2

eFlow

eFlow est d´evelopp´e par HP, c’est un plate-forme offrant des m´ecanismes pour : sp´ecifier, ´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. Visuellement, 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 instance 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.

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´ecision
qui est utilis´e pour sp´ecifier les invocations parall`eles des services. Un service est sp´ecifi´e

9


`

2.3. MODELES
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/HPL2000-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´ecification 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 plusieurs 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 modification) : l’eFlow permet de changer la composition de service. Le sch´ema de processus 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 modification 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 modifications 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

2.3.3

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 fonctionnalit´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).

10


`
2.3. MODELES
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
{http ://www.oreilly.com/catalog/entjbeans/chapter/ch02.html#62215}
Un serveur d’application EJB, fournit des fonctionnalit´es (g´erer des ressources) utilis´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 objet server 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 JNDI2 pour obtenir la r´ef´erence du
home objet (qui impl´emente la home 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

2.3.4

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 le Lookup 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

11

`
2.3. MODELES
EXISTANTS
Quand le client veut chercher le service, il utilise le service template pour sp´ecifier l’ensemble 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.

2.3.5

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´eress´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 un world
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 person 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 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.
12


´
´
2.4. SECURIT
E

2.4

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 informatique
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´erentes : 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.

2.5

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 SpacePerformance. 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 le SapcePerformance 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.

2.6

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.

13


2.6. CONCLUSION
La technique bas´
ee sur les templates : c’est le cas du eFlow, le composition des services 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 concernant les interfaces des services composants (les op´erations, les entr´ees, les sorties ...)
pour composer le composite service. Quand un utilisateur demande une application 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.

14


Chapitre 3
Mod`
ele de description de services
3.1

Introduction d´
etaill´
e du stage.

Mon stage est comme la suite du stage de GAKHAR (Description,v´erification et Adaptation de composants dans le cadre de syst`emes mobiles). Le r´esultat de son stage est de
proposer une architecture qui se compose de 5 parties (composants) :
Le client : qui demande des services.
Le serveur 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

15


3.2. AUTOMATE.
Le client envoie une requˆete au serveur de service(1) (cette requˆete contient aussi la
description du client : les messages qu’il peut comprendre l’interface du client). Le serveur
de services va envoyer cette description au « trader »(2). Le « trader » va chercher le(s)
service(s) qui peut r´epondre a` la demande du client et il retourne la(les) description(s)
de service(s) et sa(ses) r´ef´erence(s) au serveur de services(4). Le serveur de services base
sur ces informations pour g´en´erer le connecteur(5). Et ce connecteur est charg´e de la
communication entre le client et le(s) services(5)(6).
Mon stage concentre sur la description de services, c’est a` dire comment peut ont
d´ecrire des services pour que le serveur de services puisse g´en´erer automatiquement le
connecteur. La description doit satisfaire pour deux cas :
1. Si on a un seul service et sa description
2. Si on a plusieurs services et alors plusieurs descriptions. Il s’agit une composition de
services.
Dans le cas si on dispose un template pour le service composite on peut bien g´en´erer le
connecteur. Mais la technique d’utiliser les template n’est pas flexible cas si les templates
n’existes pas on ne peut rien faire. Donc les travails concentrent sur chercher et proposer

un mod`ele qui permet de :
1. d´ecrire les services.
2. composer dynamiquement des services.

3.2
3.2.1

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’ensemble 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 acheter 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 utilis´ees pour la livraison et pour envoyer des informations concernant de l’achat (le somme
16


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.

3.2.2

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´ecution 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 :

Fig. 3.2 – exemple
Dans la deuxi`eme fa¸con, les actions sont associ´ees avec les transitions de l’automate et
17


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 :

Fig. 3.3 – exemple
Le deuxi`eme fa¸con est plus naturelle que la premi`ere fa¸con par rapport de la d´efinition 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 :
<Transitions>
<Transition>
<source = "avant login"/>
<source = "avant choisir"/>
<action= "id = login()"/>
</Transition>
<Transition>
<source = "avant choisir"/>
<source = "avant payer"/>
<condition = "id > 0"/>
<action= "ref = choisir(id)"/>
</Transition>
<Transition>
<source = "avant login"/>
<source = "avant choisir"/>

<action= "payer(id,ref)"/>
</Transition>
</Transitions>
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
18


`
´
3.3. MODELE
PROPOSE
sont la mˆeme. Il est bien sur d´ecrire les fonctions (les signatures ou les interfaces), ces
informations sont utilis´ees pour g´erer les types de variables.

3.3

Mod`
ele propos´
e.

Dans cette partie je introduis notre proposition pour le mod`ele de description du
service. Avec tous les discutions dans les parties pr´ec´edentes, il me permet de penser a` un
mod`ele de deux couches pour d´ecrire les services. Une couche - couche automate- est un
peut abstrait o`

u on ne d´ecrit que les transitions, c’est a` dire pour d´ecrire les conditions et
les actions dans une transitions on ne d´ecrit que ses identifications (ses nom pas exemple).
Et la deuxi`eme couche - couche fonctionnalit´e - qui va r´epondre a` la question « quelle est
la signification de chaque action et de chaque condition » . La couche fonctionnalit´e est
une concr`ete de la couche automate o`
u tous les conditions, les actions, les signatures de
fonctions utilis´ees dans le service

Fig. 3.4 – Mod`ele propos´e

3.3.1

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 :
Sous le langage XML :
<Transition>
<source = "avant choisir"/>
<source = "avant payer"/>
<condition = "loginOk"/>
<action= "choisir"/>
</Transition>
La condition ”loginOk” et l’action ”loginOk” ne sont pas d´ecrites ici, elles sont d´ecrites

dans les deux parties suivantes
19


`
´
3.3. MODELE
PROPOSE

Fig. 3.5 – Une transition

3.3.2

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 ( >, =,
<, <=, !=, ...) entre leurs valeurs. Une condition complexe est compos´ee de plusieurs
conditions simples, la liaison entre elles c’est des op´erations logiques (and, or , xor ). Par
exemple avec une condition a > 5 on peut d´ecrire comme :
<condition name = "exemple">
<variable = "a"/>
<operation = ">"/>
<value = "5"/>
</condition>
En fait pour des cas actuelle, il faut penser a` un langage de description, qui est suffisant

pour d´ecrire les services. Dans le cadre de ce stage je n’ai pas beaucoup le temps pour le
faire

3.3.3

Actions

Une action est une invocation une ou plusieurs fonctions. Donc pour d´ecrire une action,
on doit pr´eciser quelle(s) fonction(s) qui est(sont) invoqu´ee(s) et quelles sont les entr´ees
et les sorties qui sont utilis´ees pour chaque fonction.

20


`
´
3.3. MODELE
PROPOSE
<action>
<function = "choisir"/>
= "nom du variable sortie"/>
</action>

3.3.4

Fonctions

L’ensemble de fonctions dans un service que les clients peuvent invoquer sont apparue
comme l’interface du service. Donc on d´ecrit les fonctions d’un service comme on d´ecrite

les interfaces.
Pour d´ecrire une fonction, on d´ecrire le nom de la fonction, quel sont les types d’entr´ees
et les types de sorties (la signature de la fonction).
Par exemple : on peut d´ecrire la fonction payer(int ,int) comme
<fonction name = "payer"/>
<input type = "int"/>
<input type = "int"/>
</fonction>
Cette fonction n’a pas de sorties. Dans des cas, il y a des fonctions qu’elles prennent des
entr´ees, modifient leurs valeurs et ces valeurs sont trait´ees comme des r´esultats de sorties
de la fonction. Donc pour d´ecrire des fonctions il faut supporter des mot comme ”inout”
pour dire cette variable est a` la mˆeme l’entr´ee et la sortie de la fonction
Dans la description des fonctions, on a pr´esent´e le type des entr´ees et des sorties de la
fonctions. Donc pour utiliser un type, il faut que ce type est connu. Un type peut ˆetre le
type du syst`eme (int, boolean, les classe d´efinies par le syst`eme ...), le type d´efini par le
service (structure les classe d´efinies par le service).

3.3.5

Corr´
elation dans un service

Est-ce avec le mod`ele que je pr´esente dans la partie pr´ec´edente, peut on utiliser le
service sans avoir des probl`emes ? La r´eponse c’est non. Il manque les corr´elations entre
les actions. Autrement dit, il faut sp´ecifier les sorties d’une action vont ˆetre prises comme
les entr´ees d’une autre action.
En fait il y a plusieurs choix possibles pour d´ecrire les corr´elations entre les actions.
On peut les d´ecrire dans une partie comme :
<correlation>
<action = "action1" output = "var1"/>

<action = "action2" input= "var2"/>
</correlation>
dans cet exemple, il veut dire que la variable var2 dans l’action action2 va prendre la
sortie var1 dans l’action action1.
21