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 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 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 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 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 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 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 Fragmentation des APIs 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 du département informatique de l’ENST Bretagne Brest Notre projet est appelé JEMTU [?], c’est un projet de coopération entre des é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 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, Équipe Composants pour Architectures Mobiles Adaptables École Nationale Supérieure des Télécommunications de Bretagne JEux sur Mobiles : Technologies et Usages Groupe des École des Télécommunications Fig – 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 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 – 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 6.6 Implémentation des opérations définit et manipule l’information d’état de chaque processus de gestion dans la table dmstate Fig 6.4 – Diagrame d’état d’une session Le diagramme d’état d’une session de gestion est illustré dans la figure 6.4 L’état INEXIS-TENCE n’est pas un vrai état de session, il représente l’absence d’une session C’est-à-dire, si un dispositif se connecte au serveur et il n’y a aucune session qui lui est liée, aucune opération de gestion n’est exécutée Des opérations sont effectuées quand un dispositif se connecte au serveur Le processus d’opération de gestion a déjà été initié par le serveur Si le dispositif doit commencer la session, la session est créée avec l’état ANNONCÉ (’N’) Si le dispositif commence la session de gestion lui-même, l’état se déplace la EN COURS (’P’) Pendant la session de gestion, dans laquelle il y a beaucoup d’interactions entre le dispositif et le serveur, la session reste dans l’état P Quand la session se termine avec succès, l’état se déplace COMPLET (’C’) Si une erreur irrémédiable se produit, l’état devient ERREUR (’E’) 6.6 Implémentation des opérations Un processeur de gestion est un ordre de commande que le serveur envoie au dispositif afin d’exécuter une tâche de plus haut niveau Par exemple, pour configurer des paramètres du dispositif, une opération setConfiguration est traduite en une séquence de commande Get/Replace qui exploite et change des nœuds spécifiés dans l’arbre d’objets de dispositif Le moteur de gestion est le composant du noyau qui manipule des sessions et des opérations de gestion en déléguant aux processeurs disponibles (qui ont été créés avant), la réalisation des actions de gestion pendant une session 6.6 Implémentation des opérations Quand un client commence une session de gestion, le moteur de gestion choisit un processeur approprié par le composant de sélecteur Le framework Funambol fournit une interface ManagementProcessor qui définit les méthodes suivantes pour créer un processeur de gestion Ce framework fournit aussi des opérations atomiques SyncML dan la figure 6.5 Fig 6.5 – Les opérations atomiques de Funambol OMA DM Pour appliquer ce framework déployer des applications mobiles, on programme des pro-cesseurs d’opérations de gestion ci-dessus On utilise l’outil SyncML Conformance Test Suite (SCTS DM) pour tester La capacité de cet outil est limitée, il ne permet pas l’exécution de certaines commandes OMA DM (par ex : la commande Exec) Donc, les processeurs développés semblent des démonstrations Ils se composent de : – Initiation d’une structure de répertoire de gestion : crée un arborescence de ré-pertoire sur l’arbre de gestion du dispositif Cette structure est la base de gestion sur laquelle on peut mettre toutes les applications Il rend la gestion de l’application plus facile Sa structure ressemble la description d’objets de gestion d’application de la série Nokia60 présenté dans la section 3.2.3 6.6 Implémentation des opérations Fig 6.6 – Arborescente de gestion des applications On crée cette structure seulement une fois quand on initie le dispositif Ce processus se situe dans le processus de bootstrap – Livraison d’une application : envoie une application du serveur au dispositif L’envoi se compose des informations concernant l’application (comme le nom, la version, etc.) son fichier de description jad et celui d’exécution Les applications livrées par le serveur OMA DM se situent sous le nœud intérieur Inventory/Delivered Il faut faire attention au type et la taille de l’application mobile, surtout le MIDlet – Inventaire d’un dispositif : découverte les applications du dispositif En effet, on prend tous les nœuds de l’arborescence de gestion, et on les classifie Ce processus envoie au serveur une liste des applications et leurs états L’état d’une application dépend de sa position sur l’arbre Le serveur se base sur cet état pour décider quelle action peut être exécutée avec l’application appropriée Pour effectuer n’importe quelle action de déploiement, il faut d’abord inventorier le dispositif – Mise jour d’une application : change des informations concernant une application et le fichier d’exécution On peut seulement mettre jour les applications qui ont été livrées par le serveur OMA DM – Installation d’une application : quand on délivre des applications au dispositif, elle ne peuvent pas encore être activées Pour les activer, il faut d’abord installer En effet, chaque nœud d’opération contient un ensemble de commande du déploiement d’application Dans ce cas, pour installer une application, on envoi la commande Exec au nœud d’opération approprié de l’objet qui représente l’application Cependant, cause des limitations de l’émulateur, on ne peut pas encore effectuer la commande Exec Donc, pour l’installation d’une application, on échange l’application livrée du nœud parent Delivered au nœud Deployed – Demande de téléchargement d’une application : envoie des informations d’ap-plication avec sa adresse URI (du fichier jad ou jar) Les objets qui décrivent des applications télécharger se situe sous le nœud intérieur Dowload Pour déclencher le 6.7 Conclusion téléchargement, le serveur envoie la commande Exec au nœud d’opération approprié de l’objet Cependant, le même problème que celui l’installation se pose, pour réaliser le processeur de téléchargement, on envoie seulement l’adresse URI de l’application – Activation/désactivation d’une application : on envoi la commande Exec au nœud d’opération approprié du objet qui représente l’application – Suppression d’une application : supprime tous les nœuds concernant l’application sur l’arbre de gestion Pour comprendre mieux les fonctionnalités du système, il vaut mieux voir le diagramme d’état de déploiement dans la figure 6.7 Fig 6.7 – États de deploiement de l’application 6.7 Conclusion Ce chapitre a présenté une réalisation du serveur de gestion des dispositifs OMA DM dont l’architecture se base sur le framework Funambol [?] Ce serveur se compose d’un interface web où on peut mettre des commandes, des EJBs de gestion, et d’un adaptateur de SyncML qui est responsable de communiquer aux terminaux mobiles Les EJBs du serveur sont les com- 6.7 Conclusion posants qui traitent les requêtes et génère les commandes SyncML appropriées afin de diriger les terminaux mobiles Ce système permet de découvrir la configuration et les ressources du dispositif, de surveiller les applications du dispositif et leur état, et de mettre des commandes de déploiement des applications aux terminaux Le résultat de réalisation est testé par l’émulateur SyncML Conformance Test Suite Le framework Funambol est open source en fournissant les dossiers de guide pour le déve-loppement Son architecture se base de composants EJBs qui rende le serveur plus extensible et adaptable aux exigences variées Donc c’est facile pour les développeurs de programmer et améliorer le serveur OMA DM Ce travail a démontré la capacité de gestions des dispositif et de déploiement des applications sur mobiles Il prouve la réalité de la solution proposé dans la section bien qu’il y aie encore des limitations cause de la capacité d’émulateur et les processus d’opérations de gestion soient seulement des illustrations Chapitre Réalisation de l’activation du MIDlet Dans les dispositifs, une application mobile MIDlet peut interagir sur l’autre qui permet la connexion entrante d’activer Pour faire ỗa, on applique la technique PushRegistry du profil MIDP 2.0 qui est présenté dans la section 4.1 Ce chapitre décrit en détail dans un premier lieu l’enregistrement de PushRegistry d’une MIDlets pour que les autres MIDlets puisse l’activer, dans un second lieu l’activation d’une MIDlets par l’autre et dans troisième lieu la manière appliquée pour le déploiement base de composants 7.1 Enregistrement de PushRegistry d’une MIDlet Pour inscrire un port, on a deux faỗons : lenregistrement statique et l’enregistrement dynamique Tous les deux doit déterminer un port de Push qui reỗoit les agents dactivation (la connexion entrante, le message SMS, l’alarme temporaire) L’enregistrement statique inscrit un port statique qui est déterminé par l’attribut MIDlet-Push dans le fichier de description JAD, et l’autre inscrit un port dynamique par le codage L’enregistrement statique est facile d’effectuer mais elle est rarement appliquộ Comme ladresse du port statique est fixộ, la faỗon de l’enregistrement statique provoque la confusion s’il y a deux MIDlet qui s’inscrivent le même port En plus, ce n’est pas pratique pour activer une application si les autre doit conntre correctement son adresse du port de Push Dans ce section, on s’intéresse plus de l’enregistrement dynamique, surtout l’enregistrement d’un connexion entrante pour adapter le déploiement base de composants Voici le codage d’exemple pour l’inscription : // Nom du class MIDlet pour activer String midletClassName = this.getClass().getName() ; // Enregistrer une connexion dynamique 60 7.2 Découverte et Activation d’une MIDlet String url = "socket ://" ; / Filtrage de serveurs détermine tel que serveurs peuvent connecter String filter = "*" ; / Ouvert le port ServerSocketConnection ssc = (ServerSocketConnection)Connector.open(url) ; // Découvre le port assigné par le système url = "socket :// :" + ssc.getLocalPort() ; // Attend d’une connexion entrante pour l’activité SocketConnection sc = (SocketConnection)ssc.acceptAndOpen() ; On peut mettre ce codage dans le procédure initial de l’application MIDlet que l’on veut activer Lorsque cette MIDlet est lancé, lASM va enregistrer le port dans url qui reỗoit les connexions On peut fixer une adresse du port (ex : url = "socket :// :5000" ;) mais dans ce cas, on détermine dynamiquement ce port par l’API getLocalPort() qui prend l’adresse assigné par le système Cette méthode vainc le rassemblant des port ouvert dans le dispositif Lors qu’une connexion au port inscrit, l’ASM va activer cette MIDlet, concrètement, la classe qui est présenté par midletClassName L’API getClass().getName() obtient le nom de la classe de MIDlet où on met ce code source 7.2 Découverte et Activation d’une MIDlet Si l’on conntre bien l’adresse fixé de port qui est inscrit par la MIDlet, on peut créer une connexion entrante au port pour activer cette MIDlet Cependant, on ne veut pas fixer l’adresse du port Dans ce cas où on assigne l’adresse dynamique, il vaux mieux découvrir les ports ouverts correspondant aux MIDlet dans le dispositif afin que on puisse activer exactement la MIDlet exigée PushRegistry fournit l’APIs permettant de découvrir tous les ports inscrits pour par des MIDlet sur dispositif Donc, on peut utiliser cette découverte pour activer cette MIDlet Voici le codage de démonstration : / Nom de Midlet que on cherche pour activer String className = ; / Découvrir tous les connexions qui sont inscrits par les MIDlets String[] connections = PushRegistry.listConnections(false) ; if (connections != null) { 7.2 Découverte et Activation d’une MIDlet for (int i=0 ; i < connections.length ; i++) { String midlet = PushRegistry.getMIDlet(connections[i]) ; / Vérifier le nom de classe de la MIDlet if (midlet == className) { / Créer une connexion pour l’activer PushProcessor(connections[i]) ; } } } Dans ce codage, on prend une liste des connexions inscrites par l’API listConnection() On va chercher le classe de la MIDlet que on veut activer en comparant son nom Lors que on la retrouve, on peut l’activer par un procédure PushProcessor On peut voir le diagramme de séquence dans la figure 7.1 qui présente le processus se composant de l’enregistrement, la découverte et l’activation de MIDlet Fig 7.1 – Processus d’activation d’une MIDlet En réalité, on a construit deux procédures pour l’enregistrement et l’activation de MIDlet : – RegistryPushConnection(String className, unsigned int port, String filter) : enregistre un port de la connexion de socket pour l’activation de la classe qui s’appelle className Dans ce cas où le nom de la classe entré est vide, ce procédure utilise l’API getClass().getName() le prendre, et si l’adresse du port égal 0, il assigne automati-quement une adresse au MIDlet On suppose d’accepter tous les agent d’activation, donc on met la valeur ’*’ pour le filter On appelle suivant ce procédure lorsque l’initiation de MIDlet – ActiveMIDlet(String className, unsigned int port) : active la classe s’appelant className Si l’adresse du port égal 0, ce procédure recherche le port correspondant au className La MIDlet est activé lors que ce procédure connecte au port inscrit 7.3 PushRegistry avec le déploiement base de composant 7.3 PushRegistry avec le déploiement base de composant En effet, les jeux sont suivant plus complexes et grands que les autres applications Cepen-dant, comme la capacité limité du dispositif et la bande petite de passage du réseau mobile, la taille d’applications mobiles est très important pour le téléchargement et l’usage Pour résoudre ce problème de la taille d’applications, on peut appliquer le déploiement base de composant sur mobile Malheureusement, dans ce jour là, il y a très peu des équipements qui le soutient cause de la capacité limité Surtout le profile MIDP 2.0 avec le modèle d’application MIDlet, qui est considéré comme le modèle le plus connu sur mobiles, ne soutient pas le composant et l’interopération entre des applications Une idée proposée : on divise un grand jeux sur mobile en sous applications, par exemples, comme les niveaux d’un jeux Ces applications sont indépendantes avec le ressource isolé, et leur taille est petit pour que les terminaux téléchargent facilement Ces sous applications peuvent activer les autres par la technique PushRegistry bien que le système isole ces applications (le modèle d’exécution 2.4) Fig 7.2 – Sous-MIDlets pour le déploiement base de composants La figure 7.2 présente le modèle de réalisation de PushRegistry pour le déploiement base de composants A parti d’une MIDlet original de jeu, on construit les Sous-MIDlets correspondant les niveaux du jeu Chaque sous-MIDlets s’occupe seulement de sa ressource, l’AMS gère toutes les MIDlets et ne permet pas aux MIDlets d’entrer la ressource des autres Dans ce cas d’ici, tous les sous-MIDlet inscrivent un port d’activation Imaginez que on joue un jeu ayant des niveaux 1, 2, etc Quand on termine le premier niveau, on va appeler le second niveau pour continuer le jeu Ces actions sont e ffectué par les 7.4 Conclusion APIs de PushRegistry Selon moi, cette mécanisme surmonte le problème de d’interopération entre des applications et peut-être applique pour le déploiement base de composant 7.4 Conclusion Ce chapitre a présenté la réalisation de la technologie PushRegistry pour développer et activer des applications mobiles MIDlet En effet, on a construit deux procédures qui aide s’inscrire le port d’activation et activer les MIDlet On a appliqué ces procédure pour personnaliser le jeu mobile Fomula-1 (présenté dans la section 1.3) L’objectif d’ici est d’utiliser les techniques disponibles pour s’adapter le déploiement base de composants Selon moi, la technique PushRegistry aide les MIDlets interagir aux autres et elle peut conformer l’intéropérations entre des applications mobiles Conclusion et perspectives Le but du stage était d’étudier l’architecture et la faisabilité des systèmes de déploiement pour les équipements mobiles afin de proposer une plate-forme qui s’adaptent bien au dé-ploiement des jeux multi-joueurs sur mobiles Cette plate-forme doit prendre en compte tous les activités de déploiement : l’installation, la mise jour, l’activation, la désactivation et la désinstallation Dans ce rapport, la première partie introduit l’état de l’art dans le domaine de déploiement ainsi que de développement des applications On a décrit l’architecture de jeux multi-joueurs sur mobile avec l’intergiciel GASP et une plate-forme de déploiement des applications conforme la spécification JSR 124 (Client Provisioning) On a présenté aussi la nouvelle plateforme Mobile Service Architecture (MSA) qui spécifie les services standards et l’environnement des applications pour le monde des mobiles Quelques nouvelles technologies qui soutient le dé-ploiement base de composants en environnement mobile sont présentées ensuite Elle sont abordées : l’attribut PushRegistry de MIDP 2.0, le framework OSGi, le modèle de composant LIBlet du profil MIDP 3.0 Dans la premier partie, on a détaillé plus de l’OMA DM, c’est un protocole qui permet d’exploiter et configurer les équipements, accéder et contrôler des ressources sur les mobiles La spécification de l’OMA DM a proposé une structure arborescence hiérarchique qui permet de décrire les équipements mobiles Cette structure est appelé l’arbre de gestion du dispositif dont chaque nœud peut représenter un objets gérés du dispositif L’OMA DM a proposé également un protocole de communication entre le serveur et le client mobile permet au serveur de gérer les clients en basant sur l’arbre de gestion du dispositif Ce protocole est l’échange des messages en forme SyncML afin d’envoyer et les commandes du serveur au client Ces commandes agit sur les nœuds de l’arbre de gestion du dispositif pour e ffectuer les opérations de gestion du serveur Il est aussi compatible avec plusieurs protocoles de transmission (HTTP, OBEX, WSP), extensible et adaptatif Avec le framework DDF pour la description des applications du dispositif, on peut appliquer ce protocole gérer des applications sur mobiles Ce protocole s’adapte bien tous les activités du déploiement des applications 65 7.4 Conclusion Dans la deuxième partie, un modèle pour la gestion des jeux multi-joueurs sur mobiles est proposé en basant sur trois plate-formes étudiées : le GASP, le Client Provisioning et l’OMA DM Il se compose de trois parties : le serveur de jeu GASP, le portail de stockage Client Provisioning et le serveur de gestion des dispositifs OMA DM On décrit en détail les composants des serveur ainsi que les contextes de déploiement Ce modèle peut satisfaire tous les activités concernant les jeux multi-joueurs, le stockage et le déploiement des applications de jeu sur mobiles Une implémentation du protocole OMA DM a été réalisée afin de démontrer la faisabilité de la solution proposée Cette implémentation effectue un serveur de gestion des dispositifs en basant sur le framework open source Funambol Ce serveur permet de découvrir la configuration et les ressources du dispositif, de surveiller les applications du dispositif et leur état, et de mettre des commandes de déploiement des applications aux terminaux Cependant, il y a certains points résoudre pour améliorer notre travail : – Réalisation des liaison des serveurs pour accomplir le système proposé – Gestion bien de configuration du dispositif pour vérifier la compatibilité entre les capacités du dispositif et les exigences de l’application mobile avant le déploiement – Déploiement automatiquement des applications sans interaction d’administrateur – Implémentation de la sécurité, de la permission Cette solution est en cours d’implémentation, mais on peut vraiment l’appliquer au projet JEMTU pour le déploiement grâce sa faisabilité bien que ses résultats soient seulement les illustrations Comme prochaines étapes, on veut effectuer le déploiement base de composants Ce mécanisme est appliquée suivant sur les systèmes répartis grâce l’adaptabilité des contextes d’utilisation et la commodité de l’installation, de la mise jours et de la désinstallation Cependant, c’est difficile pour la plupart des équipements mobiles actuels d’implémenter le déploiement base de composants cause de la limitation matérielle et logicielle Bibliographie [1] O Alliance Osgi alliance home page http ://www.osgi.org/ [2] O M Alliance Oma home page http ://www.openmobilealliance.org/ [3] O M Alliance Syncml http binding specification, version 1.2, 2005 [4] O M Alliance Syncml obex binding specification, version 1.2, 2005 [5] O M Alliance Syncml representation protocole, version 1.2, 2005 [6] O M Alliance Syncml wsp binding specification, version 1.2, 2005 [7] O M Alliance Oma device management device description framework, version 1.2, feb 2007 [8] O M Alliance Oma device management representation protocol, version 1.2, feb 2007 [9] O M Alliance Oma device management standardized objects, version 1.2, feb 2007 [10] O M Alliance Oma device management tree and description, version 1.2, feb 2007 [11] O M Alliance Oma device management, version 1.2, feb 2007 [12] O M Alliance Oma game services, version 1.0, feb 2007 [13] D Caward and D Bowen J2ee client provisioning specification version 1.0 http ://www.jcp.org/en/jsr/detail ?id=124 [14] G des École des Télécommunications Jeux sur mobiles : Technologies et usages http ://proget.int-evry.fr/projects/JEMTU/PublicWebHome.html [15] P B et Michal KOZON et Anass RAISSOUNI et Stéphanie TEP et Dan WANG et Letian XU Rapport de projet ingénieur : Jeu multi-joueur sur téléphone mobile Brest, France, juin 2007 [16] Funambol Funambol dm server : Developer’s guide version 3.0 Funambol, sep 2006 [17] A Jonsson and L Novak Syncml getting the mobile internet in sync, 2001 [18] A Komsi and M Düsener Mobile service architecture initiative : The latest news on jsr 248 and 249 Nokia, 2005 67 BIBLIOGRAPHIE [19] A Komsi and M Düsener Mobile service architecture specification version 1.0 http ://www.jcp.org/en/jsr/detail ?id=248, sep 2006 [20] J ME Sun java wireless toolkit for cldc http ://java.sun.com/products/sjwtoolkit/ [21] M Milikich Draft review : Mobile information device profile for java micro edition version 3.0 http ://www.jcp.org/en/jsr/detail ?id=271, dec 2006 [22] Nokia Oma device management ddf for application management version 1.1 Forum Nokia, dec 2006 [23] E Ortiz The midp 2.0 push registry Sun Developper Network, jan 2003 http ://developers.sun.com/mobility/midp/articles/pushreg/ [24] G H Page Gasp : Gaming services platform http ://gasp.objectweb.org/index.html [25] R Pellerin, F Delpiano, E Gressier-Soudan, and M Simatic Gasp : Un intergiciel pour les jeux en réseaux multijoueurs sur téléphones mobiles In UBIMOB 05, Grenoble, France, June 2005 [26] R SAID Étude du déploiement pour téléphone mobile Master’s thesis, Dept Informatique, ENST Bretagne, Brest, France, juin 2006 Annexe A Prototype de gestion des dispositifs 69 ... 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. .. 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. .. Architectures Mobiles Adaptables École Nationale Supérieure des Télécommunications de Bretagne JEux sur Mobiles : Technologies et Usages Groupe des École des Télécommunications Fig – Fragmentation des