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 dis-positifs. 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

I

État de l’art

1

Projet JEMTU
1.1

Plate-forme GASP . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1
1.1.2
1.1.3
1.1.4
1.1.5

1.2

Plate-forme Client Provisionning - JSR 124 . . . .
1.2.1
1.2.2
1.2.3
1.2.4
1.2.5

1.3

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

2 Architecture de Service Mobile

2.1

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

2.2

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

2.3

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

2.4

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

2.5

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

2.6

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

iii


3 Standard de gestion de dispositif
3.1 Protocole SyncML . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1

3.1.2
3.1.3
3.1.4
3.2 Le protocole OMA Device Management . . . . . . .
3.2.1
3.2.2
3.2.3
3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Technologie pour le déploiement à base de composants

4.1 PushRegistry . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1
4.1.2
4.1.3
4.1.4
4.2 Le Modèle OSGi . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1
4.2.2
4.2.3

4.3 LIBlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1
4.3.2
4.3.3
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

II Approche des Modèles étudiés pour le déploiement
5 Modèle Proposé
5.1 Modèle général . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2 Composants du système . . . . . . . . . . . . . . . . . . .
5.2.1
5.2.2

iv


5.2.3
5.3

Contextes de déploiement . . . . . . . . . . . . . . . . . .
5.3.1
5.3.2
5.3.3
5.3.4

6

7

Réalisation du Serveur DM
6.1

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

6.2

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

6.3

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

6.4

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

6.5

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

6.6

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

6.7

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

Réalisation de l’activation du MIDlet
7.1

Enregistrement de PushRegistry d’une MIDlet . . .

7.2

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

7.3

PushRegistry avec le déploiement à base de com

7.4

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

Conclusion et perspectives
Bibliographie
A

Prototype de gestion des dispositifs

v


Table des figures
1

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

2

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

1.1

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

1.2

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

2.1

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

2.2

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

2.3

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

2.4

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

2.5

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

3.1

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

3.2

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

3.3

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

3.4

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

3.5

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

3.6

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

3.7

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

3.8

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

4.1

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

4.2

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

4.3

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

4.4

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

4.5

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

4.6

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

4.7

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

4.8

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


4.9

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

4.10

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

4.11

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

4.12

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

4.13

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

5.1

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

5.2

Diagramme de séquence de déploiement d’application sur la mobi

5.3

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

5.4

Diagramme de séquence de recherche d’une application indisponi

5.5

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

6.1

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

6.2

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

6.3

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

6.4

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

6.5

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

6.6

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

6.7

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

7.1

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

7.2

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

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

à Brest. Notre projet est appelé JEMTU

3

2

[?], c’est un projet de coopération entre des

4

écoles du GET , 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 compa-tible
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éro-gé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
fragmen-tation 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 ini-tiative 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

2

É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
1


2

Fig. 1 – Fragmentation des APIs

il veut les mêmes applications et les mêmes données dans des environnements di ffé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 o ffrir 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
com-posants 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’appli-cation 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 plate-forme
open source conforme aux intergiciels de jeux multijoueurs sur mobile. Et l’autre est une plateforme 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
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
plate-forme 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

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.
– 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éveloppe-ment 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
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 fonc-tionnel 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’environne-ment 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
Bre-tagne, 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

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 informa-tions
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
appli-qué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
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 proto-coles 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
ap-plications, 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 interopé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
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
dispo-sitifs 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

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

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
fonc-tionnalité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évelop-pement 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
– 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 plu-sieurs 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 plateforme 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
Les

Protocole SyncML
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