Architecture des systèmes de déploiement pour les équipements mobiles

Institut de la Francophonie pour l’Informatique
École Nationale Supérieure des Télécommunications de Bretagne

MÉMOIRE DE FIN D’ÉTUDES
MASTER D’INFORMATIQUE

Architecture des systèmes de déploiement pour les équipements
mobiles

TRINH Anh-Tuan
Responsable de stage : Fabien DAGNAT

Ce stage a été réalisé au sein du Département informatique de l’École Nationale
Supérieure des Télécommunications de Bretagne
GET - ENST Bretagne

Brest, 20 août 2007


Remerciements
Je tiens à remercier tout particulièrement Fabien DAGNAT pour m’avoir encadré pendant
ces six mois. Je remercie de son contact chaleureux, ses conseils et encouragements, son soutien
permanent et la liberté de recherche qu’il a bien voulu me laisser.
Mes plus sincères remerciements vont également à tous les professeurs et les personnels de
l’Institut de la Francophonie pour l’Informatique (IFI) pour m’avoir donné des cours de très
bonne qualité et pour leur soutien tout au long de mes études à l’IFI.
Un grand merci aux thésards et aux autres stagiaires à l’ENST Bretagne pour une ambiance
de travail particulièrement favorable.
Je remercie chaleureusement mes camarades de la promotion XI pour leur amitié sans faille
et je leur souhaite bonne chance pour la soutenance.
Merci enfin à mes parents et mes amis pour leur soutien et leur encouragement à tout

instant.

i


Résumé
Avec le progrès de l’informatique mobile et de la technologie des terminaux, les jeux sur
mobile sont aussi variés et animés. Ce sont donc des applications complexes que les utilisateurs
ont besoin d’utiliser dans des contextes d’exécutions variés. Par conséquent, les applications
de jeu doivent s’adapter aux différentes capacités des terminaux. De plus, il est nécessaire de
disposer d’une plate-forme de déploiement pour gérer automatiquement les applications qui
prend en compte toutes les activités du cycle de vie de logiciel : l’installation, la mise à jours,
l’activation/désactivation et la désinstallation.
Dans cette mémoire, on propose un modèle pour la gestion des jeux multi-joueurs sur mobiles
qui s’adapte aux contextes d’utilisation et de déploiement. Il se compose des trois serveurs. Le
serveur de jeu qui s’occupe des sessions de jeu et des comptes des utilisateurs. Le serveur
de stockage permet de stocker et approvisionner les applications mobiles compatibles avec les
terminaux en tenant compte de leurs spécificités. Le noyau de ce modèle est le serveur de gestion
des dispositifs qui permet d’exploiter les équipements, accéder et contrôler les ressources sur
mobiles afin de s’occuper bien toutes les activités du déploiement des applications.
Le noyau du modèle repose sur l’OMA DM, c’est un protocole qui permet aux serveurs
de gérer des terminaux mobiles en échangeant les messages en forme SyncML. Ces messages
transportent les commandes du serveur aux terminaux afin d’agir sur les objets gérés du dispositifs. Ces objets sont représentés par une structure arborescente hiérarchique appelé l’arbre
de gestion du dispositif. Les nœuds de l’arbre peuvent décrire l’information de configuration
ainsi que les applications. Le déploiement des applications basé sur le protocole OMA DM est
effectué par les interactions sur les nœuds de l’arbre.
Une réalisation du serveur de gestion des dispositifs est effectué pour démontrer la faisabilité du modèle proposé. Elle se base sur le framework open source Funabol qui est une
implémentation de protocole OMA DM.
Mots-clés : gestion des dispositifs, déploiement composants, jeu multi-joueur, OMA DM,
GASP.

ii


Table des matières
Introduction

1

I

5

État de l’art

1 Projet JEMTU
1.1

1.2

1.3

6

Plate-forme GASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

1.1.1

Architecture du GASP . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

1.1.2

Interfaces de communication : GASPClient et GASPServer . . . . . . .

8

1.1.3

Services proposées par GASP . . . . . . . . . . . . . . . . . . . . . . . .

8

1.1.4

Optimisation des communications : protocole MooDS . . . . . . . . . . .

8

1.1.5

Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

Plate-forme Client Provisionning - JSR 124 . . . . . . . . . . . . . . . . . . . .

9

1.2.1

Architecture générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

1.2.2

Stockage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

1.2.3

Découverte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

1.2.4

Livraison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

1.2.5

Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2 Architecture de Service Mobile

12

2.1

But de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

2.2

Initiative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.3

Composants JSRs de la plate-forme . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.4

Modèle d’éxecution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

2.5

Cartographie technologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

2.6

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

iii


3 Standard de gestion de dispositif
3.1

3.2

3.3

17

Protocole SyncML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.1.1

Spécification de SyncML . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.1.2

Framework de SyncML

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

19

3.1.3

Paquet, message et commandes de SyncML . . . . . . . . . . . . . . . .

20

3.1.4

Formation de données de SyncML . . . . . . . . . . . . . . . . . . . . .

21

Le protocole OMA Device Management

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

21

3.2.1

Modèle de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

3.2.2

Protocole et mécanisme . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

3.2.3

Gestion des applications avec OMA DM . . . . . . . . . . . . . . . . . .

26

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

4 Technologie pour le déploiement à base de composants
4.1

4.2

4.3

4.4

II

31

PushRegistry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4.1.1

Composant de PushRegistry . . . . . . . . . . . . . . . . . . . . . . . . .

31

4.1.2

Cycle de vie et Activation de Midlet . . . . . . . . . . . . . . . . . . . .

32

4.1.3

Connexion entrante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

4.1.4

Enregistrement de Poussé . . . . . . . . . . . . . . . . . . . . . . . . . .

34

Le Modèle OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

4.2.1

Architecture multi-couche . . . . . . . . . . . . . . . . . . . . . . . . . .

36

4.2.2

Bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

4.2.3

Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

LIBlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

4.3.1

Profil MIDP 3.0 avec le modèle composant LIBlets . . . . . . . . . . . .

39

4.3.2

Dépendance du LIBlet . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

4.3.3

Découvert de MIDlet dans le profile MIDP 3.0 . . . . . . . . . . . . . .

42

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

Approche des Modèles étudiés pour le déploiement

5 Modèle Proposé

44

45

5.1

Modèle général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

5.2

Composants du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

5.2.1

Serveur de jeu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

5.2.2

Portail de Stockage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

iv


5.2.3

5.3

Serveur de gestion de dispositif . . . . . . . . . . . . . . . . . . . . . . .

47

Contextes de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

5.3.1

Demande de déploiement X sur le mobile M . . . . . . . . . . . . . . . .

47

5.3.2

Gestion de dispositif . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

5.3.3

Recherche d’une application indisponible . . . . . . . . . . . . . . . . . .

49

5.3.4

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

6 Réalisation du Serveur DM

51

6.1

Framework Funambol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

6.2

Séquence d’exécution de processus d’opération . . . . . . . . . . . . . . . . . . .

52

6.3

JSPs et EJBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

6.4

Base de données du Serveur DM . . . . . . . . . . . . . . . . . . . . . . . . . .

54

6.5

Statut d’opération de gestion . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

6.6

Implémentation des opérations . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

6.7

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

7 Réalisation de l’activation du MIDlet

60

7.1

Enregistrement de PushRegistry d’une MIDlet . . . . . . . . . . . . . . . . . . .

60

7.2

Découverte et Activation d’une MIDlet . . . . . . . . . . . . . . . . . . . . . . .

61

7.3

PushRegistry avec le déploiement à base de composant . . . . . . . . . . . . . .

63

7.4

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

Conclusion et perspectives

65

Bibliographie

68

A Prototype de gestion des dispositifs

69

v


Table des figures
1

Fragmentation des APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

2

Les objectifs de la gestion des dispositifs . . . . . . . . . . . . . . . . . . . . . .

2

1.1

Architecture du GASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

1.2

Architecture du serveur SUN d’approvisionnement . . . . . . . . . . . . . . . .

10

2.1

Simplification des APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.2

Spécification de MSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.3

Composants JSRs de MSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.4

Modèle d’éxecution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

2.5

Cartographie Technologique de MSA . . . . . . . . . . . . . . . . . . . . . . . .

16

3.1

Représentation du paquet SyncML . . . . . . . . . . . . . . . . . . . . . . . . .

18

3.2

Protocole du SyncML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

3.3

Framework du SyncML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

3.4

L’arbre de gestion de dispositif . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

3.5

Packages du protocole OMA DM . . . . . . . . . . . . . . . . . . . . . . . . . .

25

3.6

La description de dispositif . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

3.7

Le protocole de gestion d’application du framework OMA DM . . . . . . . . . .

28

3.8

La description d’objet de gestion d’application (Nokia série 60) . . . . . . . . .

29

4.1

Elements typiques de PushRegistry . . . . . . . . . . . . . . . . . . . . . . . . .

32

4.2

Cycle de vie et Activation de Midlet . . . . . . . . . . . . . . . . . . . . . . . .

32

4.3

Diagramme de séquence d’activation sur le réseau . . . . . . . . . . . . . . . . .

33

4.4

Architecture générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

4.5

Architecture multi-couche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

4.6

Cycle de vie d’un bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

4.7

Contenu d’un bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

4.8

Registre de services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

vi


4.9

Modèle d’application du profil MIDP 2.0 et 3.0 . . . . . . . . . . . . . . . . . .

40

4.10 Dépendance basée le Hash du LIBlet . . . . . . . . . . . . . . . . . . . . . . . .

41

4.11 Dépendance basée le certificate du LIBlet . . . . . . . . . . . . . . . . . . . . .

41

4.12 Attribute de Dépendance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

4.13 Découverte le MIDlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

5.1

Modèle proposé du système de jeu multi joueur . . . . . . . . . . . . . . . . . .

46

5.2

Diagramme de séquence de déploiement d’application sur la mobile . . . . . . .

48

5.3

Diagramme de séquence de gestion de dispositif . . . . . . . . . . . . . . . . . .

48

5.4

Diagramme de séquence de recherche d’une application indisponible . . . . . . .

49

5.5

Diagramme de séquence de téléchargement d’une application . . . . . . . . . . .

50

6.1

Le framework Funambol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

6.2

Simplification des APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

6.3

Base de données du Serveur DM . . . . . . . . . . . . . . . . . . . . . . . . . .

54

6.4

Diagrame d’état d’une session . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

6.5

Les opérations atomiques de Funambol OMA DM . . . . . . . . . . . . . . . . .

56

6.6

Arborescente de gestion des applications . . . . . . . . . . . . . . . . . . . . . .

57

6.7

États de deploiement de l’application . . . . . . . . . . . . . . . . . . . . . . . .

58

7.1

Processus d’activation d’une MIDlet . . . . . . . . . . . . . . . . . . . . . . . .

62

7.2

Sous-MIDlets pour le déploiement à base de composants . . . . . . . . . . . . .

63

vii


Introduction
De nos jours, les téléphones mobiles sont utilisés massivement dans la vie quotidienne.
Leurs services sont aussi variés et animés, surtout les jeux sur mobile. Une des tendances très
intéressantes est le jeu multi-joueurs. Du point de vue informatique, ce sont des applications

complexes distribuées qui imposent l’utilisation de techniques modernes. Ce stage se déroule
dans l’équipe CAMA

1

du département informatique de l’ENST Bretagne

projet est appelé JEMTU

3

2

à Brest. Notre

[?], c’est un projet de coopération entre des écoles du GET 4 ,

qui a pour objectif de développer des recherches dans le domaine des jeux multi-joueurs sur
mobile. Ce stage concerne plus précisément la partie du projet JEMTU sur l’adaptation et le
déploiement sur les téléphones mobiles. C’est un domaine difficile du fait de l’hétérogénéité des
terminaux et la capacité limitée des mobiles.

Problématique
La technologie Java pour l’industrie sans-fil est répandue. Le nombre de dispositifs compatible avec Java représente plus de la moitié du marché des mobiles. Cependant, elle provoque
de nouveaux défis, il est difficile de réaliser des applications pour mobiles en raison de l’hétérogénéité des équipements matériel et logiciel. Les différences de caractéristiques, fonctionnalités,
standard de fabrication, etc. rendent le développement complexe et donc coûteux.
La figure 1 représente le modèle de développement sur les mobiles, elle illustre la fragmentation d’APIs pour réaliser des applications. Ce modèle est assez complexe et inconsistant. Il
n’intègre pas bien l’évolution ; et son architecture n’est pas bien structurée. Une nouvelle initiative est donc nécessaire pour s’adapter non seulement à toutes les caractéristiques actuelles
mais aussi aux développements futurs.
De plus, le nombre de dispositifs ne cesse d’augmenter et ils intègrent beaucoup de services

et d’applications. Comme la figure 2, chaque utilisateur peut posséder plus d’un équipement,
1

Équipe Composants pour Architectures Mobiles Adaptables
École Nationale Supérieure des Télécommunications de Bretagne
3
JEux sur Mobiles : Technologies et Usages
4
Groupe des École des Télécommunications
2

1


2

Fig. 1 – Fragmentation des APIs

il veut les mêmes applications et les mêmes données dans des environnements différents (par
exemple : son calendrier, son courrier, etc.) sans répéter des actions semblables d’installation
sur tous ses terminaux. Du côté des fournisseurs, ils veulent aussi offrir facilement de plus en
plus des nouveaux services, applications etc aux terminaux sur le réseau mobile avec n’importe quel transport. On a donc besoin d’un système de déploiement automatique (recouvrant
l’installation, la mise à jour, l’activation et la désinstallation) des outils sur mobiles. La figure
2 démontre le système que on désire. Dans ce système, l’information de configuration et les
composants de chaque équipement sont bien gérées par un protocole de gestion de dispositifs.

Fig. 2 – Les objectifs de la gestion des dispositifs

Un autre problème, la taille d’application et le nombre de fonctionnalités sont de plus en
plus grands et on a besoin des nouvelles techniques pour les construire et déployer. Une des

solutions est le développement à base de composants, c’est-à-dire, les applications sont divisées


3
en petites parties qui s’occupent de fonctionnalités identifiées, et un mécanisme permettant aux
applications d’appeler ces parties afin d’adapter leurs opérations. Chaque partie est considérée
comme un composant qui peut être déployée dynamiquement et utilisé par une ou plusieurs
applications.

Motivation et objectifs du stage
Un des objectifs principaux du projet JEMTU est de mener des recherches sur un système
de déploiement qui est spécifié et compatible avec les jeux multi-joueurs sur mobiles. Ce stage
a pour but d’étudier les technologies existantes qui s’adaptent bien au développement et au
déploiement pour les jeux multi-joueurs afin de mener bien au projet.
Actuellement, il y a une plate-forme disponible pour construire des jeux multi-joueurs, c’est
le plate-forme GASP [24], mais elle semble ne pas gérer l’hétérogénéité des dispositifs. En plus,
un stage précédent [25] sur le sujet de déploiement a conduit à la réalisation d’une plate-forme
Client Provisionning [13] qui permet de stocker et de délivrer les applications mobiles. Mais il
manque le contrôle du déploiement sur le dispositif.
A partir des problématiques et de l’état actuel du projet, mon stage se compose de trois
études principales :
– Les plate-formes qui s’adapte bien à l’hétérogénéité des dispositifs.
– La gestion des dispositifs.
– Les mécanismes qui soutiennent le déploiement à base de composants.

Plan du document
Ce rapport est divisé en deux parties. La première partie est l’état de l’art qui présente
l’étude des modèles pour le développement et le déploiement sur mobiles qui peuvent résoudre
les problèmes posés. La deuxième partie propose un modèle pour le système de gestion de jeu
mobile et réalise des démonstrations de ces solutions.

La première partie se compose de quatre chapitres :
Le Chapitre 1 présente le travail déjà réalisé dans la carde du projet JEMTU, à savoir
la plate-forme de jeu mobile avec multi-joueurs GASP, et le modèle de déploiement Client
Provisioning pour les applications mobiles.
Le Chapitre 2 présentée l’architecture de service mobile MSA [18], une nouvelle plateforme en cours de standardisation pour les équipements mobiles.
Le Chapitre 3 décrit le protocole standard OMA DM [11] qui permet de gérer des équipements mobiles, et leurs applications.


4
Le Chapitre 4 aborde les nouvelles techniques soutenant le déploiement à base de composants en environnement mobile. Il s’agit du framework OSGi [1], du modèle de composant
LIBlet du profil MIDP 3.0 [20] et de l’attribut PushRegistry [22].
La deuxième partie se compose trois chapitres :
Le Chapitre 5 propose une solution pour le système de gestion et de déploiement d’application sur les mobiles.
Le Chapitre 6 expose une réalisation du modèle OMA DM. Cette réalisation se base sur
le framework Funambol [15], qui nous permet de gérer des équipements par des commandes en
format SyncML.
Le Chapitre 7 présente une démonstration de PushRegistry qui peut soutenir le mécanisme
de déploiement à base de composants.
Enfin, c’est une conclusion qui résume le résultat du stage, montre des manques dans le
travail et présente quelques perspectives.


Première partie

État de l’art

5


Chapitre 1

Projet JEMTU
En mai 2005, les écoles du GET sont décidé le lancement d’une Action Innovante sur les
jeux sur mobiles. Ce programme présente le travail de cette Action baptisée JEMTU (JEux sur
Mobiles : Technologie et Usages). Le projet JEMTU est mené en étroite collaboration avec les
partenaires comme : le CNAM-CEDRIC, l’ENST Paris, l’ENST Bretagne et l’INT.
Parmi les volets du projet JEMTU, le volet technologique, vise à investiguer et développer
des outils pour la mise en place technique des jeux sur mobiles. Il étudie l’infrastructure réseau
et, le problème de l’interopérabilité entre les opérateurs. Ce chapitre présente deux plate-formes
étudiées dans le projet JEMTU concernant la technologie sur mobiles, ce sont la plate-forme
GAming Services Platform (GASP) et le Client Provisionning. La GASP [23] est une plateforme open source conforme aux intergiciels de jeux multijoueurs sur mobile. Et l’autre est une
plate-forme de SUN [13] conforme au stockage et déploiement d’application sur mobiles.

1.1

Plate-forme GASP

La plate-forme open source GAming Services Platform (GASP) est une plate-forme pour le
jeu multi-joueurs sur mobile implémentant les spécifications de l’OMA Game Services version
1.0 [12] . L’Open Mobile Alliance (OMA) [2] est une organisation qui a été formée en 2002
par un groupement de plus de 200 entreprises : opérateurs mobile, entreprises de fabrication
de terminaux mobiles, entreprises spécialisées dans les réseaux, dans les technologies de l’information et fournisseurs de contenu. L’OMA a mis en place des spécifications pour la réalisation
de plate-forme pour le jeu multi-joueur sur mobile, elles constituent une solution solide au
problème de l’hétérogénéité des plate-formes propriétaires.
Cette plate-forme constitue une tentative d’amélioration du modèle proposé par l’OMA, une
réflexion architecturale et fonctionnelle tel que l’élaboration d’un protocole de communication
permettant d’optimiser la taille des messages et donc le temps de communication entre client
6

1.1 Plate-forme GASP

7

et serveur impliquant un gain de performance non négligeable sur des supports de ce type.

1.1.1

Architecture du GASP

Fig. 1.1 – Architecture du GASP
La figure 1.1 présente l’architecture de GASP. Elle se compose des modules interagissant :
– Platform Representation : ensemble des instances des classes constituant la plateforme. IDManager est la classe de gestion des ID des instances, DBManager est la classe
accueillant l’ensemble des méthodes amenées à accéder directement à la base de données
(BD). Les classes Platform et MasterApplicationInstances gèrent les sous ensembles
représentant l’exécution des jeux. Les ApplicationInstances et les ActorSessions, sous
ensemble s’intitulant Games Representation.
– Servlet Container : conteneur accueillant les classes de communication de GASP. C’est
un ensemble de Servlets qui est chargé de traiter les requêtes des utilisateurs depuis leur
mobile et depuis un jeu utilisant les interfaces de communications de GASP. Ces requêtes
pour GASP v1.0 utilisent le protocole HTTP over GPRS.
– Game Servers : l’ensemble des logiques de jeu serveur instanciées et gérées par leur
ApplicationInstance.
– Interfaces de communications : GASPClient et GASPServer. Ces interfaces permettent la communication entre la logique cliente et la logique serveur à travers la plateforme GASP. Ils respectent les spécifications de l’OMA.
– GASP DB : la base de données de GASP.


1.1 Plate-forme GASP

1.1.2

8

Interfaces de communication : GASPClient et GASPServer

Ces deux interfaces de communication permettent les échanges de messages via la plateforme GASP. Elles fournissent donc des méthodes de connectivité nécessaires aussi bien à
l’accès aux services de GASP qu’à la communication entre logique de jeu client et serveur. Ces
méthodes respectent la version 2.0 des spécifications de l’OMA. Détaillons les :
– GASPClient : doit être étendue par la logique cliente et offre les méthodes de communication avec la plateforme GASP (servlets).
– GASPServers : doit être implémentée par la logique serveur, elle lui permet de communiquer avec la plate-forme, et d’intégrer le modèle événementiel de la plate-forme.

1.1.3

Services proposées par GASP

Afin de gérer les informations échangées par les joueurs, GASP propose un nombre de
services restreints :
Services clients
– La salle de jeu permettant aux joueurs de la rejoindre et jouer ensemble.
– La gestion de jeu mise en œuvre par InGame, qui est responsable de rejoindre, créer,
démarrer, stopper, quitter une ApplicationInstance.
– La gestion de compte mise en oeuvre par la base de données de GASP, qui s’occupe
de login, mot de passe, pseudonyme.
Services systèmes
– La gestion de session de jeu mise en oeuvre par ActorSession et Session.
– Le contrôle d’accès et l’authentification vérifient les droits au niveau de la base de
données de GASP.
Cet ensemble de services est minimal et est amené à évoluer rapidement avec le développement de GASP, notamment en termes de services systèmes et de services éditeurs, ces derniers
afin de faciliter le déploiement de jeux sur la plate-forme, combinaison d’accès BD, pour la
gestion des utilisateurs et de leurs droits, et d’interfaces de publications pour les jeux.

1.1.4

Optimisation des communications : protocole MooDS

Le protocole Mobile Optimized Objects Description Serialization (MooDS), réalisé pour
répondre aux besoins d’optimisations de GASP, a pour objectif la minimisation de la taille
des messages afin d’accélérer le temps des communications et la taille des données transférées
(souvent facturées au prix fort par les opérateurs) entre la logique client et la logique serveur. Le
générateur de MooDS va se servir de cette description XML pour générer une classe d’encodage


1.2 Plate-forme Client Provisionning - JSR 124

9

et de décodage des types personnalisés décrits afin que ne soient passés sur le réseau uniquement
les valeurs binaires des attributs des objets contenus dans la hashtable du DataEvent.

1.1.5

Synthèse

La plate-forme pour les jeux multi-joueurs sur mobiles GASP constitue une implémentation
des spécifications normalisatrices de l’OMA. Cette plate-forme reprend donc le modèle fonctionnel proposé par l’OMA en y apportant certaines améliorations et clarifications, propose une
implémentation de son modèle événementiel et propose des solutions pour l’optimisation des
communications avec l’élaboration du protocole MooDS.
GASP a publié des dossiers qui guident à développer des applications, initier l’environnement et installer le serveur pour le jeu multi-joueurs. Le serveur de GASP basé sur la plate-forme
Apache Tomcat et la base de données MySQL, se compose des servlets qui implémentent les
fonctionnalités proposées.

Il y a des projets de jeu mobile qui ont utilisé la plate-forme GASP, par exemple le projet
JIMM [24] , surtout le projet Formula_1 [14] des étudiants en deuxième années à ENST Bretagne, en 2007. Ce projet a réalisé un jeu multi-joueurs de course sur mobile. Dans ce projet, il
y encore des problèmes comme la grande latence de synchronisation entre les terminaux, mais
il a réussi à utiliser les fonctionnalités principales de la plate-forme GASP.

1.2

Plate-forme Client Provisionning - JSR 124

Un serveur d’approvisionnement permet la découverte et la livraison de services à une variété
de terminaux clients. La JSR 124 [13] (Client Provisioning) est une spécification qui définie une
API pour le développement d’applications d’approvisionnement et un format d’empaquetage
pour permettre la livraison des services par le serveur.

1.2.1

Architecture générale

Cette spécification est implémentée dans un serveur J2EE qui assure la communication avec
les clients. Ce serveur utilise l’APIs pour implémenter la découverte, la recherche et la livraison
des paquets. Les paquets doivent être stockés avec leurs descripteurs dans un dépôt. Selon le
type de terminal client, un adaptateur est mis en place pour réaliser les différents protocoles
de téléchargement.
La figure 1.2 montre l’architecture du serveur SUN. L’API est utilisée par des servlets,
avec les adaptateurs MIDP et JNLP assurant le téléchargement, et le dépôt (repository) est
implémenté par un composant EJB.


1.2 Plate-forme Client Provisionning - JSR 124

10

Fig. 1.2 – Architecture du serveur SUN d’approvisionnement

1.2.2

Stockage

Le stockage est le processus de gestion du dépôt pour ajouter des paquets. Les tâches de
stockage se divisent en trois catégories principales :
– Empaquetage stocke des paquets dans un format standard en fournissant des informations des décision sur la manière dont ces paquets sont découverts et livrés. L’empaquetage
se compose d’un fichier archive PAR qui peut contenir plusieurs paquets et d’un fichier
descripteur XML qui contient toutes les informations concernant ces paquets. Les informations peuvent contenir les exigences du paquet concernant les capacités du terminal.
– Pré-vérification vérifie le paquet et l’intégrité de l’empaquetage et du descripteur. Par
exemple, on peut vérifier que le fichier JAR est conforme à la spécification MIDP.
– Ajout au dépôt enregistre des archives PAR dans le serveur de stockage.

1.2.3

Découverte

Le serveur d’approvisionnement doit contenir un service qui permet aux clients de découvrir
les paquets disponibles à la livraison. Les composants J2EE du serveur utilisent les API définies
dans la spécification de JSR 124 afin d’exécuter trois tâches pendant ce processus de découverte :
– Détermination des caractéristiques du terminal de l’utilisateur. Chaque type de terminal
est décrit sous forme d’un profil contenant une liste de capacités. Lors de la recherche,
ces capacités seront comparées aux exigences afin de choisir les paquets compatibles.
– Recherche des paquets appropriées dans le dépôt. Une série de filtres standards est appliquée afin d’éliminer les paquets incompatibles avec le terminal. Mais on peut personnaliser
le filtrage selon d’autres critères en réalisant l’interface MatchPolicy.
– Production des URIs qui permettent au terminal d’initier la livraison. Ces URIs sont une

1.3 Conclusion

11

liste de paquets avec leur description sera disponible pour le client.

1.2.4

Livraison

Après la phase de découverte, un serveur d’approvisionnement doit être capable de délivrer
ses paquets aux clients. La livraison est gérée par des adaptateurs qui implémentent les protocoles d’interaction entre client et serveur. Ces adaptateurs rendent le serveur extensible en lui
permettant d’approvisionner plusieurs types de terminaux. L’adaptateur est un composant qui
implémente l’interaction avec un certain terminal.

1.2.5

Synthèse

Cette section a présenté une plate-forme de déploiement des applications sur mobiles conforme
à la spécification Client Provisioning (JSR 124). Cette plate-forme est implémentée sous la
forme d’un serveur d’approvisionnement qui stocke les paquets et ensuite déploie ces paquets
dans les terminaux. Dans un stage précédent [25] du projet JEMTU en 2006, une implémentation du serveur d’approvisionnement a été réalisée. Cette plate-forme est extensible au niveau
des algorithmes de comparaison pour implémenter des nouveaux types d’attributs et au niveau
des adaptateurs pour pouvoir supporter des nouveaux types de terminaux.

1.3

Conclusion

Dans ce chapitre, deux plate-formes étudié du projet JEMTU sont présentées : la plateforme GASP pour développer les jeu et gérer les sessions de jeu multi-joueurs sur mobiles, et le
Client Provisioning - JSR 124 pour stocker, rechercher et le télécharger les applications mobiles
compatibles avec la capacité de terminal.
Cependant, ces plate-formes ont encore des manques. Pour le développement, GASP ne
considère pas encore la hétérogénéité des dispositifs, leur capacité qui sont importantes avec
les exigences technologiques et l’architecture complexe de jeu. En plus, GASP ne vise pas au
déploiement de jeu et à la gestion de leurs versions. La plate-forme Client Provisioning est
pour le déploiement sur mobiles mais toutes les activités du déploiement sont décidées par
l’utilisateur, les rôles d’administrateur et de fournisseur des services ne sont pas importants.
Dans cette plate-forme, il manque également le contrôle du déploiement sur le terminal.
Par conséquence, on a besoin des meilleures solutions pour le développement, le déploiement
et la gestion de jeux sur mobiles. Selon moi, il est nécessaire de disposer d’un système qui gère
bien des dispositifs (leur configuration et leurs applications). Dans ce système, l’administrateur
peut commander les terminaux pour les configurer, déployer les applications, etc.


Chapitre 2

Architecture de Service Mobile
Comme les dispositifs continuent à évoluer sans cesse et à incorporer de nouvelles technologies et de nouveaux services, une plate-forme qui standardise ces nouvelles technologies est
nécessaire. Actuellement, Nokia, Vodafone et quelques autres fournisseurs mobiles se mettent
d’accord sur une architecture conçue pour simplifier les normes de Java sur les mobiles, c’est
la Mobile Service Architecture (MSA). Elle est marqué le JSR 248 [18].
Ce chapitre présente le modèle MSA, c’est une nouvelle plate-forme pour le monde des
mobiles. Ce modèle a pour but de spécifier les services standards et l’environnement des applications, en construisant sur le succès du Mobile Information Device Profile (MIDP), du
Connected Limited Device Configuration (CLDC), et la technologie Java pour l’industrie sans
fil (JTWI). Elles simplifient, de plus, les caractéristiques existantes pour définir une architecture
cohérente de services Java et pour assurer la compatibilité applicative à travers les dispositifs

mobiles de plusieurs fournisseurs.

2.1

But de conception

Premièrement, la spécification de MSA a pour but de réduire au minimum la fragmentation
des environnements mobiles de Java en définissant un environnement prévisible et inter-opérable
d’application et de service pour les développeurs. Pour atteindre ce but, ces spécifications
contiennent deux ensembles des composants obligatoires JSRs, des clarifications, des conditions
supplémentaires et des recommandations pour les développeurs. Cette spécification maximise
l’interopérabilité dans l’implémentation et assure que les applications fonctionnent dans la
grande variété de dispositifs compatible avec MSA.
Deuxièmement, l’approche générique de la MSA s’applique à une grande variété de terminaux et des segments de clients différents. Ceci est réalisé en proposant deux définitions de
plate-forme (MSA Subset et de MSA complet). Ces définitions soutiennent aussi la configuration
12


2.2 Initiative

13

CDC (qui est réservée aux dispositifs puissants), et offrent la condition pour les caractéristiques
qui ne sont pas encore disponibles sur tous les dispositifs compatible avec la MSA
Troisièmement, la conception de MSA a pour but d’assurer la consistance de définition dans
non seulement l’environnement actuel de Java mobile mais aussi la prochaine génération (MSA
et MSA avancé - JSR 248 et JSR 249)

2.2

Initiative

Actuellement, il y a beaucoup d’APIs variées correspondants aux caractéristiques des dispositifs mobiles. Par conséquentes, il existe une forte fragmentation à cause des APIs optionnelles.
L’idée initiale est donc de proposer une plate-forme qui peut consolider et lier toutes les APIs
nécessaires [17]. Ces APIs sont rassemblées dans un noyau commun et on clarifie les exigences
ajoutées et leurs relations. Cette plate-forme est unifié et consistante.

Fig. 2.1 – Simplification des APIs
Pour construire cette plate-forme, le processus consiste en quatre étapes :
– Collecter tous les JSRs concernant les mobiles pour former la plate-forme MSA. On
décide quelles fonctionnalités sont nécessaires, quelles ressources sont requises, etc.
– Ajouter des clarifications en basant sur les JSRs collectés. Parce que les interactions entre
ces JSRs ne sont pas bien spécifiées. Ces clarifications peuvent réduire la fragmentation
et l’ambiguïté.
– Spécifier des exigences obligatoires sur la sécurité et le matériel.
– Fournir le Technology Compatibility Kit (TCK) qui vérifie la compatibilité aux clarifications définies dans MSA.


2.3 Composants JSRs de la plate-forme

14

Fig. 2.2 – Spécification de MSA

2.3

Composants JSRs de la plate-forme

MSA définit un ensemble standard de fonctionnalités pour les terminaux mobiles ainsi que la
clarification des interactions entre ces diverses technologies. Puisqu’il y a une grande variation

de matériel et de logiciel pour les mobiles, les spécifications de MSA offrent deux choix : la
spécification de MSA Subset et ou la spécification complète de MSA.

Fig. 2.3 – Composants JSRs de MSA
– MSA Subset décrit les fonctionnalités communes minimales des mobiles. Il se compose
des JSRs obligatoires. Les dispositifs compatibles avec MSA doivent satisfaire toutes les
fonctionnalités de ces JSRs.
– La spécification complète de MSA rassemble toutes les JSRs concernant les équipements
mobiles d’aujourd’hui. Aux fonctionnalités indispensables de MSA Subset, elle ajoute des
JSRs dont caractéristiques visent les dispositifs les plus modernes. Ces composants JSRs
sont optionnelles, c’est-à-dire leur implémentation dépendent du terminal.


2.4 Modèle d’éxecution

2.4

15

Modèle d’éxecution

Il se base sur le noyau commun consistant l’ensemble fixé des APIs dans les dispositifs
compatibles avec MSA. Les applications peuvent appeler seulement ces APIs fixées et ces fonctionnalités ne sont pas extensibles. Leur installation est contrôlée par des ’slot’, c’est-à-dire
chaque application est isolée et ne peut pas interagir avec les autres applications (par ex :
chaque application ne peut pas lancer, appeler, contrôler les autres). En plus, elles ne peuvent
pas partager des données.

Fig. 2.4 – Modèle d’éxecution

2.5

Cartographie technologique

MSA est réservée aux configurations standards CLCD, c’est-à-dire aux configurations ayant
des ressources limitées, même s’il est adaptable aux équipements CDC avec des fonctionnalités
plus puissantes. Car les technologies modernes aujourd’hui vont devenir la base commune dans
un futur proche, il est donc nécessaire de disposer d’une cartographie permettant le développement plus rapide de la technologie. C’est le but de la plate-forme MSA Advanced qui est en
cours de préparation.
La figure 2.5 décrit des composant de MSA Advanced. En se basant sur le framework CDC et
le Profil de Fondation, elle vise les équipements modernes qui intègrent les connexions en haute
débit, les interfaces graphiques et les services. Il s’adapte encore aux CLDC avec un noyau
commun d’APIs comme la plate-forme MSA. Cependant, il ajoute le framework de Mobile
Optional Management qui soutient un environnement de gestion plus fort.
– Loadable APIs : la capacité de téléchargement des nouveaux APIs et recompiler.
– Advanced Core APIs : le noyau avancé des nouveaux APIs..


2.6 Conclusion

16

– Framework OSGi : le déploiement des composants et le management à distance.

Fig. 2.5 – Cartographie Technologique de MSA

2.6

Conclusion

Ce chapitre a présenté l’Architecture des Services Mobiles, c’est une plate-forme qui peut

limiter l’hétérogénéité des matériels et la fragmentation du développement afin d’exécuter les
différentes étapes du déploiement d’une entité logicielle. Elle peut être compatible avec plusieurs dispositifs différents, non seulement les configurations matérielles limitées mais aussi les
équipements avec de fortes capacités. Ce chapitre a présenté aussi une extension de MSA qui
pourra s’adapter aux changements rapides des matériels, c’est la plate-forme MSA avancé. Elle
a lancé une orientation technologique qui assure la consistance pour le développement pendant
longtemps.
Actuellement, SUN a proposé le toolkit sans-fil de CLDC ver 2.5 [19] conforme à la MSA
pour la programmation mobile. Cet émulateur fournit des options de développement pour les
plate-formes JTWI, MSA Subset et MSA complet, ou même les JSRs isolés. Il fournit aussi des
outils pour la signification, la permission, et la technologie PushRegistry [22] etc.
En conséquence, la plate-forme MSA est le choix indispensable pour le développement pour
mobiles, surtout pour la programmation des jeux mobiles qui demande beaucoup de technologies
et la compatibilité avec des matériels variés. On peut appliquer l’architecture MSA pour adapter
le modèle GASP du projet JEMTU afin d’obtenir une meilleure plate-forme de programmation
des jeux mobiles.


Chapitre 3

Standard de gestion de dispositif
Sur chaque mobile, il existe un arbre de gestion qui consiste des répertoires et des fichiers de
données, appelés les nœuds. Ces nœuds se situent sur l’arbre à une adresse déterminé (URIs)
et contiennent des informations sur le dispositif, ses applications et ses composants. OMA DM
[11] est un protocole permettant aux serveurs de gérer des terminaux mobiles en se basant sur
cet arbre. Ce protocole est une extension du protocole SyncML [5] dont l’objectif initial est de
la synchronisation des données entre les terminaux et les serveur. Dans l’OMA DM, le serveur
et les clients communiquent par le protocole SyncML qui utilise une représentation XML et un
transport par HTTP. Dans ce chapitre, nous présentons le protocole SyncML et le modèle de
la gestion des dispositifs de OMA DM.

3.1

Protocole SyncML

Les dispositifs mobiles sont considérés comme les ordinateurs portables. Une problématique
importante liée aux dispositifs mobiles est la synchronisation avec le serveur. Le protocole
SyncML a été publié en 2002, son but vise à créer une norme générale pour les problématiques
de synchronisation, mais d’autres scénarios sont aussi possibles. SyncML fournit un framework
qui s’adapte bien aux dispositifs sans fil avec des connexions bas débit. Il peut être employé
par différentes connexions comme le protocole HTTP [6], Wireless Session Protocol (WSP) [3],
Object Exchange (OBEX) [4], etc. La version 1.1 de SyncML a ajouté une nouvelle extension,
c’est un protocole de gestion de dispositif (Device Management) permettant l’administration
centralisée d’un grand nombre de dispositifs.

3.1.1

Spécification de SyncML

La spécification de SyncML se compose de trois composants principaux :
– La représentation XML
17