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

Dans cette mémoire, on propose un modèle pour la gestion des jeux multi-joueurs sur mobilesqui s’adapte aux contextes d’utilisation et de déploiement.. Dans ce système, l’information de

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-TuanResponsable 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 aỏt 2007

Je tiens à remercier tout particulièrement Fabien DAGNAT pour m’avoir encadré pendantces six mois Je remercie de son contact chaleureux, ses conseils et encouragements, son soutienpermanent 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 del’Institut de la Francophonie pour l’Informatique (IFI) pour m’avoir donné des cours de trèsbonne 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 à toutinstant

i

Avec le progrès de l’informatique mobile et de la technologie des terminaux, les jeux surmobile sont aussi variés et animés Ce sont donc des applications complexes que les utilisateursont 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 dedisposer d’une plate-forme de déploiement pour gérer automatiquement les applications quiprend 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 mobilesqui s’adapte aux contextes d’utilisation et de déploiement Il se compose des trois serveurs Leserveur 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 lesterminaux en tenant compte de leurs spécificités Le noyau de ce modèle est le serveur de gestiondes dispositifs qui permet d’exploiter les équipements, accéder et contrôler les ressources surmobiles 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 messagestransportent 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 configurationainsi que les applications Le déploiement des applications basé sur le protocole OMA DM esteffectué 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

fai-sabilité 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

1.1 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

1.2 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

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

3.1 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

3.2 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

3.3 Conclusion 30

4 Technologie pour le déploiement à base de composants 31 4.1 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

4.2 Le Modèle OSGi 35

4.2.1 Architecture multi-couche 36

4.2.2 Bundle 36

4.2.3 Services 38

4.3 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

4.4 Conclusion 43

II Approche des Modèles étudiés pour le déploiement 44 5 Modèle Proposé 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 Serveur de gestion de dispositif 47

5.3 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

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

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èsintéressantes est le jeu multi-joueurs Du point de vue informatique, ce sont des applicationscomplexes distribuées qui imposent l’utilisation de techniques modernes Ce stage se dérouledans l’équipe CAMA 1 du département informatique de l’ENST Bretagne 2 à Brest Notreprojet est appelé JEMTU 3 [?], 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 surmobile Ce stage concerne plus précisément la partie du projet JEMTU sur l’adaptation et ledéploiement sur les téléphones mobiles C’est un domaine difficile du fait de l’hétérogénéité desterminaux et la capacité limitée des mobiles

l’hétéro-La figure 1 représente le modèle de développement sur les mobiles, elle illustre la tation d’APIs pour réaliser des applications Ce modèle est assez complexe et inconsistant Iln’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 actuellesmais aussi aux développements futurs

fragmen-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

Fig 1 – Fragmentation des APIs

il veut les mêmes applications et les mêmes données dans des environnements différents (parexemple : son calendrier, son courrier, etc.) sans répéter des actions semblables d’installationsur tous ses terminaux Du côté des fournisseurs, ils veulent aussi offrir facilement de plus enplus des nouveaux services, applications etc aux terminaux sur le réseau mobile avec n’im-porte quel transport On a donc besoin d’un système de déploiement automatique (recouvrantl’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 lescomposants 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 enplus grands et on a besoin des nouvelles techniques pour les construire et déployer Une dessolutions est le développement à base de composants, c’est-à-dire, les applications sont divisées

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

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 audé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ésentel’étude des modèles pour le développement et le déploiement sur mobiles qui peuvent résoudreles problèmes posés La deuxième partie propose un modèle pour le système de gestion de jeumobile 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 forme en cours de standardisation pour les équipements mobiles

plate-Le Chapitre 3 décrit le protocole standard OMA DM [11] qui permet de gérer des pements mobiles, et leurs applications

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 cation sur les mobiles

d’appli-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 letravail 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 lesjeux sur mobiles Ce programme présente le travail de cette Action baptisée JEMTU (JEux surMobiles : Technologie et Usages) Le projet JEMTU est mené en étroite collaboration avec lespartenaires 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évelopperdes 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 conplate-forme 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

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 plate-forme IDManager est la classe de gestion des ID des instances, DBManager est la classeaccueillant 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 ensemblesrepré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 leurmobile et depuis un jeu utilisant les interfaces de communications de GASP Ces requêtespour 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 leurApplicationInstance

– Interfaces de communications : GASPClient et GASPServer Ces interfaces mettent la communication entre la logique cliente et la logique serveur à travers la plate-forme GASP Ils respectent les spécifications de l’OMA

per-– GASP DB : la base de données de GASP

1.1 Plate-forme GASP 81.1.2 Interfaces de communication : GASPClient et GASPServer

Ces deux interfaces de communication permettent les échanges de messages via la forme 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 Cesméthodes respectent la version 2.0 des spécifications de l’OMA Détaillons les :

plate-– GASPClient : doit être étendue par la logique cliente et offre les méthodes de nication avec la plateforme GASP (servlets)

– GASPServers : doit être implémentée par la logique serveur, elle lui permet de niquer 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

commu-Afin de gérer les informations échangées par les joueurs, GASP propose un nombre deservices 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 dedonnées de GASP

Cet ensemble de services est minimal et est amené à évoluer rapidement avec le ment de GASP, notamment en termes de services systèmes et de services éditeurs, ces derniersafin de faciliter le déploiement de jeux sur la plate-forme, combinaison d’accès BD, pour lagestion des utilisateurs et de leurs droits, et d’interfaces de publications pour les jeux

développe-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 tailledes 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 Legé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émentationdes 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 uneimplémentation de son modèle événementiel et propose des solutions pour l’optimisation descommunications avec l’élaboration du protocole MooDS

GASP a publié des dossiers qui guident à développer des applications, initier ment et installer le serveur pour le jeu multi-joueurs Le serveur de GASP basé sur la plate-formeApache Tomcat et la base de données MySQL, se compose des servlets qui implémentent lesfonctionnalités proposées

l’environne-Il y a des projets de jeu mobile qui ont utilisé la plate-forme GASP, par exemple le projetJIMM [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’empaquetagepour 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 avecles clients Ce serveur utilise l’APIs pour implémenter la découverte, la recherche et la livraisondes paquets Les paquets doivent être stockés avec leurs descripteurs dans un dépôt Selon letype 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’approvisionnement1.2.2 Stockage

Le stockage est le processus de gestion du dépôt pour ajouter des paquets Les tâches destockage se divisent en trois catégories principales :

– Empaquetage stocke des paquets dans un format standard en fournissant des tions des décision sur la manière dont ces paquets sont découverts et livrés L’empaquetage

informa-se compoinforma-se d’un fichier archive PAR qui peut contenir plusieurs paquets et d’un fichierdescripteur XML qui contient toutes les informations concernant ces paquets Les infor-mations 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 Parexemple, 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écouvrirles paquets disponibles à la livraison Les composants J2EE du serveur utilisent les API définiesdans 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 terminalest 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.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 paquetsdans les terminaux Dans un stage précédent [25] du projet JEMTU en 2006, une implémenta-tion du serveur d’approvisionnement a été réalisée Cette plate-forme est extensible au niveaudes algorithmes de comparaison pour implémenter des nouveaux types d’attributs et au niveaudes adaptateurs pour pouvoir supporter des nouveaux types de terminaux

Dans ce chapitre, deux formes étudié du projet JEMTU sont présentées : la forme GASP pour développer les jeu et gérer les sessions de jeu multi-joueurs sur mobiles, et le

plate-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 neconsidère pas encore la hétérogénéité des dispositifs, leur capacité qui sont importantes avecles 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 parl’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èrebien des dispositifs (leur configuration et leurs applications) Dans ce système, l’administrateurpeut 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 logies et de nouveaux services, une plate-forme qui standardise ces nouvelles technologies estnécessaire Actuellement, Nokia, Vodafone et quelques autres fournisseurs mobiles se mettentd’accord sur une architecture conçue pour simplifier les normes de Java sur les mobiles, c’est

techno-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 desmobiles 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 architecturecohérente de services Java et pour assurer la compatibilité applicative à travers les dispositifsmobiles de plusieurs fournisseurs

Premièrement, la spécification de MSA a pour but de réduire au minimum la fragmentationdes environnements mobiles de Java en définissant un environnement prévisible et inter-opérabled’application et de service pour les développeurs Pour atteindre ce but, ces spécificationscontiennent deux ensembles des composants obligatoires JSRs, des clarifications, des conditionssupplémentaires et des recommandations pour les développeurs Cette spécification maximisel’interopérabilité dans l’implémentation et assure que les applications fonctionnent dans lagrande variété de dispositifs compatible avec MSA

Deuxièmement, l’approche générique de la MSA s’applique à une grande variété de minaux et des segments de clients différents Ceci est réalisé en proposant deux définitions de

ter-plate-forme (MSA Subset et de MSA complet) Ces définitions soutiennent aussi la configuration

12

dispo-Fig 2.1 – Simplification des APIsPour construire cette plate-forme, le processus consiste en quatre étapes :

– Collecter tous les JSRs concernant les mobiles pour former la plate-forme MSA Ondé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 entreces 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

clarifi-cations définies dans MSA

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 lesfonctionnalité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 JSRssont optionnelles, c’est-à-dire leur implémentation dépendent du terminal

2.4 Modèle d’éxecution 15

Il se base sur le noyau commun consistant l’ensemble fixé des APIs dans les dispositifscompatibles 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 peuventpas 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 ayantdes ressources limitées, même s’il est adaptable aux équipements CDC avec des fonctionnalitésplus 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 hautedé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

Ce chapitre a présenté l’Architecture des Services Mobiles, c’est une plate-forme qui peutlimiter l’hétérogénéité des matériels et la fragmentation du développement afin d’exécuter lesdiffé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 quipourra 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 pendantlongtemps

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 pourmobiles, 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 programmationdes 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 dedonné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 surcet 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 untransport par HTTP Dans ce chapitre, nous présentons le protocole SyncML et le modèle de

la gestion des dispositifs de OMA DM

Les dispositifs mobiles sont considérés comme les ordinateurs portables Une problématiqueimportante liée aux dispositifs mobiles est la synchronisation avec le serveur Le protocoleSyncML 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’administrationcentralisé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

3.1 Protocole SyncML 18

– Le protocole de synchronisation

– La fixation protocole

Représentation de SyncML

SyncML contient un ensemble de messages bien définis qui sont transmis entre un client et

un serveur participant à une opération de synchronisation Les messages sont représentés comme

des documents XML ou comme des entités Multipurpose Internet Mail Extension (MIME) qui

fournissent un mécanisme pour différencier le contenu ou les types séparés de documents Cettereprésentation indique un type de la description de document XML (DTD) [7], qui permet lareprésentation de toutes les informations exigées pour exécuter la synchronisation, en incluantles données, les meta-données et les commandes

Fig 3.1 – Représentation du paquet SyncML

La figure 3.1 [16] montre la structure de base d’un paquet de SyncML, un récipient tuel pour des messages de synchronisation Le message de SyncML est une entité individuelle

concep-de MIME concep-de SyncML, essentiellement un document XML bien formé Cette représentation seradécrite en détail dans la section 3.1.3

Protocole de synchronisation

Le protocole de synchronisation définit comment les différents messages dans la DTD deSyncML sont échangés selon un schéma prédéfini Dans la fig 3.2

3.1 Protocole SyncML 19

– Le Client (le dispositif mobile) contient un agent de synchronisation client et envoiehabituellement des messages SyncML Il doit également être capable de recevoir desréponses du serveur de SyncML Dans certains cas, il pourrait recevoir des messagesSyncML de commande du serveur

– Le Serveur SyncML contient un agent de synchronisation serveur et un moteur desynchronisation, et reçoit habituellement les messages du client SyncML Le serveur doitégalement être capable d’envoyer des réponses aux commandes si nécessaires Dans cer-tains cas, il pourrait envoyer les messages de SyncML comme commandes au client

Fig 3.2 – Protocole du SyncML

Fixation de transport

Chaque paquet de SyncML est indépendant, et pourrait être porté par n’importe quel

trans-port Les associations spécifiées sont les protocoles HTTP, Wireless Session Protocol (WSP)

et OBEX, mais SyncML pourrait également être mis en application en utilisant des E-mail ou

d’autres méthodes Puisque les messages de SyncML sont indépendants, un grand nombre deformes de transports peuvent être employé

3.1.2 Framework de SyncML

Ce framework est décrit par la figure 3.3 [16] On suppose qu’il y ait un couple client-serveur

qui ont besoin de synchroniser leurs données App A dans cette figure est un service du serveurqui fournit des données de synchronisation aux autres applications d’un dispositif sur le réseau,ici App B Le serveur et le dispositif sont reliés par un transport commun de réseau, tel que

le HTTP Du côté serveur, le moteur de synchronisation est une entité logique qui compare

3.1 Protocole SyncML 20

les changements de données du serveur et celui du client S’il y a des différences, ce moteursynchronisera le client avec son image sur serveur

Le framework de SyncML consiste en un adaptateur conceptuel de SyncML et une interface

de SyncML L’adapteur de SyncML est le processus conceptuel que le créateur et le récepteurdes objets formés de SyncML emploient pour communiquer avec l’autre Il s’occupe de créer et

de maintenir une connexion de réseau entre App A et App B L’interface de SyncML fournitdes APIs pour appeler l’adaptateur de SyncML

Fig 3.3 – Framework du SyncML

Pour la synchronisation, l’agent de synchronisation du serveur appelle les APIs dans terface SyncML Ces APIs lui permette de contrôler l’accès du moteur de synchronisation auréseau et communique les opérations de synchronisation à/de l’application au client Du côtéclient, App B emploie aussi l’agent de synchronisation de client pour accéder au réseau et à sonadapteur de SyncML, en appelant des fonctions dans l’interface SyncML

l’in-3.1.3 Paquet, message et commandes de SyncML

Comme on a présenté précedement, les opérations de synchronisation de SyncML sontconceptuellement liées dans un paquet de SyncML Le paquet de SyncML est simplement

un framework conceptuel pour un ou plusieurs messages de SyncML qui sont exigés pour

transmettre un ensemble de commandes de synchronisation Les paquets de SyncML ne sontpas définis dans la DTD de représentation de données de SyncML

3.2 Le protocole OMA Device Management 21

Le message de SyncML est un document individuel en format XML qui se compose de :

– Une en-tête (header ) : indiquée par le type d’élément de SyncHdr Elle détermine le

cheminement, la version, l’authentification du message de SyncML

– Un corps (body) indiqué par le type d’élément de SyncBody Le corps de SyncML est un

récipient pour une ou plusieurs commandes de SyncML qui doivent être exécutées.SyncML définit des commandes [5] suivantes :

– Add, Copy, Delete, Move, Replace, Put : permet à l’expéditeur de demander au tinataire de changer des éléments qui peuvent être accédés par le destinataire

des-– Alert : permet au créateur de notifier au destinataire

– Get, Search : permet à l’expéditeur d’exploiter des ressources du destinataire

– Atomic : permet à l’expéditeur d’indiquer qu’un ensemble de commandes doit être cutés avec une sémantique toute ou rien (transaction)

exé-– Sequence : permet au créateur d’indiquer qu’un ensemble de commandes doit être exécutédans l’ordre indiqué

– Results : présente le résultat de commandes Get et Search

– Status : indique le statut d’accomplissement d’une opération si une demande précédente

à conduit à une erreur

Un des avantages de SyncML rend ce protocole extensible à d’autres utilisations, pas ment pour la synchronisation

seule-3.1.4 Formation de données de SyncML

SyncML identifie également un ensemble de formats de données qui fournissent un ensemble

de types de supports pour échanger l’information admise commune, telle que des contacts, descalendriers et des messages En plus de ces formats, SyncML tient compte de l’identification

de n’importe quel autre format enregistré SyncML emploie le type content de MIME pour

identifier les formats de données

L’OMA est une grande organisation des constructeurs de mobiles, qui est responsable de legestion des standards pour les équipements portables En se basant sur le protocole SyncML,

en 2004, l’OMA a proposé deux services standards : la synchronisation de données (Data

Syn-chronization - DS) et la gestion de dispositifs (Device Management - DM) L’OMA DM est un

protocole qui permet d’exploiter et configurer les équipements, accéder et contrôler les ressourcessur les mobiles Un des avantages de l’OMA DM est la capacité de déployer les applications

3.2 Le protocole OMA Device Management 22

Dans cette partie, on présente le protocole OMA pour gestion des applications Il consiste

en deux parties :

– Le modèle des données disponibles pour la manipulation à distance

– Le protocole de communication entre le serveur de gestion et le client mobile

3.2.1 Modèle de données

Il est difficile pour le serveur de gérer des mobiles à cause de leur configuration spécifique

et de leurs caractéristiques particulières qui dépendent de chaque constructeur L’OMA DM

a proposé un framework standard permettant aux fournisseurs de définir la description des

dispositifs [7] et la communiquer au serveur Le serveur se base sur cette description pourenvoyer les opérations Cette description est appelée l’arbre de gestion de dispositif [10].Arbre de gestion de dispositif

La figure 3.4 décrit un exemple l’arbre de gestion de dispositif Cet arbre organise tousles objets gérés du dispositif sous la forme d’une structure arborescente ó chaque nœud est

adressé (de manière unique) par un URI (Uniform Resource Identifier).

Fig 3.4 – L’arbre de gestion de dispositifLes nœud peuvent être de n’importe quelle forme : un paramètre simple, une image GIF oumême une application complète Il y a deux types d’objets :

– Les objets permanents sont incorporés dans le dispositif, ils ne peuvent pas être supprimés.Par ex, l’objet DevInfo qui spécifie l’information fondamentale du dispositif

3.2 Le protocole OMA Device Management 23

– Les objets dynamiques sont des objets qui peuvent être ajoutés ou supprimés (Parexemple, les sonneries)

Adresse des nœuds

Dans les dispositifs compatibles avec OMA DM, les objets sont présentés comme des nœuds[10] qui se situent sur un arbre unique Ces nœuds ont une URI unique Chaque nœud a un typedéterminé et on peut lire et mettre une valeur compatible La valeur de nœud peut représenterplusieurs formats de données, soit un text simple soit une application C’est l’initiative degestion des dispositifs, des nœuds sur l’arbre de gestion

Pour accéder aux nœuds de l’arbre, par exemple : le nœud xyzInc dans la figure 3.4, unserveur doit utiliser l’adresse /DMAcc/xyzInc correspond à son URI qui représente son chemindepuis la racine de l’arbre de gestion

Caractéristiques de nœud

Les nœuds sont les entités qui peuvent être manipulées par le protocole OMA DM Lapropriété Format indique si le nœud est :

– un nœud intérieur (il peut avoir des nœuds fils reliés en structure arborescente)

– un nœud feuille (ou il peut contenir une information mais n’a pas de nœud fils)

Chaque nœud de l’arbre a un ensemble de propriétés qui définit des caractéristiques de :

– ACL (Access Control List) : définit qui peut utiliser le nœud.

– Format : détermine comment un nœud est interprété

– Name : le nom du nœud

– Size : la taille de l’information que le nœud contient

– Title : le nom visible du nœud

– Timestamp : la date et l’heure de sa dernière modification

– Type : le type MIME de l’information que le nœud contient

– VerNo : le numéro de version, automatiquement incrémenté à chaque modification.Manipulation des nœuds

Les nœuds de gestion peuvent être manipulés par des messages SyncML DM contenant lescommandes suivantes :

– Get : permet au serveur de gestion d’explorer la structure de l’arbre Si le nœud consultéest un nœud intérieur, une liste de tous les noms des nœuds fils est retournée et si lenœud est une feuille, son information est retournée

– Add : Ajoute un nœud à un arbre

3.2 Le protocole OMA Device Management 24

– Replace : Remplace un nœud dans l’arbre

– Delete : Supprime un nœud de l’arbre

– Copy : Copie un nœud de l’arbre

Le serveur peut modifier l’arbre de gestion durant l’exécution par les commandes Add etReplace Les nouveaux nœuds peuvent être intérieurs ou être des feuilles, mais son parent doitêtre un nœud intérieur Le dispositif lui-même peut également modifier son arbre

Objets standards du protocole

OMA DM propose un framework qui permet aux constructeurs de définir eux-mêmes des

descriptions correspondant à leurs produits Mais il serait limité si les entités contrôlablesdans les dispositifs avaient des formats différents et des comportements différents Pour évitercette situation, l’OMA a définit un certain nombre d’objets obligatoires [9] Ces objets sontprincipalement associés à OMA DM et à la configuration de SyncML :

– DevInfo : description du dispositif, envoyée du client au serveur

– DevDetail : L’information générale de dispositif qui bénéficie de la standardisation.– DMAcc : l’établissement pour le client de DM

3.2.2 Protocole et mécanisme

OMA propose un protocole de communication entre le client et le serveur pour la gestiondes dispositifs Le protocole consiste en une séquence de messages entre le client et le serveurpour réaliser des opérations

Paquets du protocole

Le protocole [8] consiste deux phases principales, la phase d’initiation et celle de gestion

La première phase a pour but d’authentifier et d’échanger des informations de dispositif Laseconde effectue des commandes du serveur sur le client Ces phases sont considérées commedes transactions des paquets SyncML

La phase de gestion consiste en un certain nombre d’itérations Le contenu du paquet voyé par le serveur détermine si la session doit être continuée ou pas Si le serveur envoie lesopérations dans un paquet qui a besoin d’une réponse (Status ou Results), cette phase conti-nue avec un nouveau paquet du client pour le serveur contenant les réponses Le paquet deréponse du client commence une nouvelle itération Le serveur peut envoyer un nouveau paquetd’opération de gestion et donc lancer une nouvelle itération s’il le souhaite Le traitement despaquets peut rendre un temps non prévisible Par conséquent, le protocole OMA DM n’indique

en-3.2 Le protocole OMA Device Management 25

aucun délais d’attente entre les paquets

Fig 3.5 – Packages du protocole OMA DM

Le Paquet 0 Certains dispositifs ne peuvent pas détecter la connexion à un serveur degestion D’autres dispositifs ne souhaitent pas ouvrir le port (c’est-à-dire accepter les connexionsextérieures) pour des raisons la sécurité Par contre, la plupart des dispositifs peuvent recevoir

des messages de notification Cette action n’est pas requise si le client peut se connecter au

serveur Elle permet à un serveur de lancer une session de gestion du dispositif

Le paquet 1 La phase d’installation consiste en une demande du client et la réponse du

serveur Il contient la demande initiale du client avec la commande Alert, qui se compose de :

– L’information de dispositif (comme le constructeur, le modèle, etc.), qui se situe dansl’objet DevInfo

3.2 Le protocole OMA Device Management 26

– Le certificat du client, pour l’identifier sur le serveur

– Une marque informe le serveur que cette session est lancée par le serveur (si le serveur aenvoyé le paquet 0) soit par le client (comme une action de l’utilisateur)

Le Paquet 2 transporte la réponse du serveur à la demande initiale du client avec lecertificat du serveur pour l’authentification Le serveur peut également envoyer des commandes(incluant l’interaction avec l’utilisateur) dans cette réponse

Le Paquet 3 est envoyé si le client reçoit des commandes du serveur dans le paquet 2

Le client répondra au serveur avec les résultats (par la commande Get) ou les résultats de latransaction du message précédent

Le Paquet 4 se produit pour terminer la session ó commencer une nouvelle itération sid’autres opérations de gestion sont requises S’il y a des opérations supplémentaires, la réponse

à ce message sera du même type de transaction que la transaction 3 Cette itération continuerajusqu’à ce que le serveur de gestion envoie un message de fin de session au client

Plusieurs messages pour un paquet

Le protocole OMA DM fournit la possibilité de transférer un paquet de SyncML en utilisantdes messages multiples de SyncML C’est nécessaire quand un paquet de SyncML est trop grand(par exemple, si la séquence des commandes est complexes) Dans ce cas ci, on divise le paquet

en morceaux compatibles avec la taille de message et on utilise l’élément <MoreData/> pourl’annoncer au destinataire Si un paquet de SyncML est transféré en multi-messages, le derniermessage dans le paquet doit inclure l’élément <Final/>

Ce mécanisme peut provoquer la confusion des messages, surtout dans le cas ou le serveurenvoie des lots d’opérations (avec la commande Séquence) Pour éviter cette situation, le serveur

ne peut pas envoyer un nouveau message s’il n’a pas reçu la réponse du client correspondant à

la commande précédente

3.2.3 Gestion des applications avec OMA DM

Une idée proposée est que l’on peut utiliser l’OMA DM pour la gestion des applications

On peut considérer les applications d’un mobile comme des objets contrơlables que l’on place

dans l’arbre de gestion du dispositif Le framework de description de dispositif nous permet de

définir les descriptions compatibles d’applications mobiles Avec le protocole OMA DM et sescommandes de manipulation des objets, le serveur a la capacité de déployer les applications dudispositif (installation, mise à jour, suppression, ó même activation/désactivation)

3.2 Le protocole OMA Device Management 27

Framework de description de dispositif

Il est nécessaire que le système de gestion connaisse chaque dispositif bien qu’ils aientdes structures et des comportements différentes Pour cela, OMA DM intègre un concept de

framework de description de dispositif (Device Description Framework DDF) [7] Ce framework

prescrit une manière pour les fabricants de décrire leurs dispositifs de sorte qu’un système degestion puisse comprendre comment contrôler le dispositif

Fig 3.6 – La description de dispositif

La description proposée du framework est définie par une Document Type Definition DTD

XML Elle représente un objet de gestion, ou un arbre complet de gestion Les fabricants quisuivent ce standard doivent publier la description de leurs terminaux sur les serveurs de gestion

La figure 3.6 présente le processus de la description de dispositif avec le framework DDF.

Le fondament du framework est la DTD, qui permet de représenter un objet par un document XML En basant sur ce framework, les caractéristiques d’une série de dispositifs sont classifiées,

structurées et représentées par un fichier XML Cette description sera envoyée au serveur pourque le serveur puisse connaître ce type de dispositifs et ses caractéristiques Il peut décrirechaque dispositif par un document XML particulier de sa configuration avec le même format

de la description du type mobile Le serveur se base ce document pour gérer les dispositifs

3.2 Le protocole OMA Device Management 28

L’arbre de gestion est présenté facilement par le framework DDF OMA DM publie quelques

éléments standards pour la représentation du type de dispositif comme les éléments structuraux(qui décrit l’arborescence hiérarchie de l’arbre et les nœuds de l’arbre), et les éléments propriétésqui décrivent les caractéristiques de nœud, etc

Ce framework assure que tout le système de gestion basé sur l’OMA DM est flexible et

extensible Il s’accommode des requêtes actuelles, ainsi que des demandes du futur Il permet

au serveur OMA DM de s’adapter les changements de la configuration matériel et de structure logicielle sur mobiles

l’infra-Protocole de gestion des applications via l’OMA DM

Fig 3.7 – Le protocole de gestion d’application du framework OMA DM

La figure 3.7 décrit la transaction de gestion des applications d’OMA DM Tout d’abord,

le serveur de gestion envoie une requête d’inventaire de dispositif avec une option d’interaction

de l’utilisateur (ex : la demande de confirmation) Le client répond en fournissant l’informationd’inventaire appropriée au serveur et le serveur l’analyse et effectue des opérations de déploie-ment d’application Le client renvoie la confirmation après avoir complété ces opérations.Description d’objets contrôlables

La figure 3.8 [21] montre la description d’objets de gestion d’application sur les équipements

de série 60 de Nokia suivant le framework DDF Elle fournit des fonctionnalités pour la gestiondes applications à distance via OMA DM Cette figure représente l’état des applications dumobile sur lequel serveur se base pour effectuer ses opérations de gestion

3.2 Le protocole OMA Device Management 29

Le nœud Delivered est un nœud parent rassemblant les nœuds des applications qui sontlivrées par le serveur de gestion via le protocole OMA DM mais ne sont pas encore lancées Lalivraison, essentiellement, est la transmission des données concernant une application spécifiée(son nom, sa version, son fichier de description jad, son fichier d’archive) du serveur au clientpar des messages SyncML Le serveur envoie un ensemble des commandes Add pour ajouter unenouvelle application ou des commandes Replace pour mettre à jour Ces applications livrées

se situent dans une espace mémoire ó les serveurs OMA DM peuvent accèdent

Fig 3.8 – La description d’objet de gestion d’application (Nokia série 60)

Pour interagir avec les applications, la description d’objets de gestion de Nokia propose lesnœuds d’opérations correspondant aux activités du déploiement que les serveurs de gestion desdispositifs peuvent lancer par la commande Exec En effet, ces nœuds référencent un ensembledes commandes qui effectuent des applications Par exemple, pour installer une applicationlivrée, le serveur envoie une commande Exec à son nœud /Operation/Install, cette applicationchange son état en activé En notation, après avoir été installée, cette application est considérée

Le serveur peut gérer les terminaux mobiles en se basant l’arbre de gestion qui représente

la configuration et les objets contrôlables du dispositif Le processus de gestion est effectué pardes commandes que le serveur envoie au client par des messages SyncML La transmission des

messages se base le frammework SyncML, qui permet la synchronisation ainsi que la gestion

des terminaux Un système comme ça est le modèle de la gestion des dispositifs OMA DM

Il permet de configurer les dispositifs, exploiter/déployer des applications, implémenter desservices, gérer des ressources de dispositif, et contrôler des terminaux à distance

Sur le réseau mobile, il est nécessaire de connaître la configuration matérielle, les ressources

et les logiciels des dispositifs Le déploiement des applications et des services aux terminaux estmieux géré par le serveur que par l’interaction de l’utilisateur En particulier, avec le jeux multi-jouers sur mobiles, on doit gérer les joueurs, les sessions de jeux, ainsi que les versions de jeux

à cause du changement rapide des jeux Dans un futur proche, une orientation de jeux mobilessera à base de composants et de services L’OMA DM s’adaptera bien à la problématique lagestion des composants

Actuellement, plusieurs téléphone mobile sont conformes au protocole OMA DM, par exemple :les séries de Nokia comme la série 60, 80, le nouveau série N Une description d’application pour

la gestion des dispositifs de Nokia 60 est présenté dans la section 3.2 Nokia a publié aussi lesémulateurs qui soutiennent la programmation compatible avec OMA DM, par exemple : le

ServicePack 1 de l’émulateur série 60 Un framework opensource intéressant qui fournit des

APIs de programmation OMA DM, est le modèle Funambol DM Une réalisation basé sur ce

framework va être présenté dans le chapitre 6.

En perspectifs, on peut faire coopérer le serveur de gestion des dispositifs avec le serveur

de gestion de jeux pour obtenir une solution complète sur mobiles qui se compose de la grammation, le stockage, le déploiement des applications de jeux et la gestion des services dejeux