Institut de la Francophonie pour l’Informatique École Nationale Supérieure des Télécommunications de Bretagne MÉMOIRE DE FIN D’ÉTUDES MASTER D’INFORMATIQUE Architecture des systèmes de déploiement pour les équipements mobiles TRINH Anh-Tuan Responsable de stage : Fabien DAGNAT Ce stage a été réalisé au sein du Département informatique de l’École Nationale Supérieure des Télécommunications de Bretagne GET - ENST Bretagne Brest, 20 août 2007 Remerciements Je tiens remercier tout particulièrement Fabien DAGNAT pour m’avoir encadré pendant ces six mois Je remercie de son contact chaleureux, ses conseils et encouragements, son soutien permanent et la liberté de recherche qu’il a bien voulu me laisser Mes plus sincères remerciements vont également tous les professeurs et les personnels de l’Institut de la Francophonie pour l’Informatique (IFI) pour m’avoir donné des cours de très bonne qualité et pour leur soutien tout au long de mes études l’IFI Un grand merci aux thésards et aux autres stagiaires l’ENST Bretagne pour une ambiance de travail particulièrement favorable Je remercie chaleureusement mes camarades de la promotion XI pour leur amitié sans faille et je leur souhaite bonne chance pour la soutenance Merci enfin mes parents et mes amis pour leur soutien et leur encouragement tout instant i Résumé Avec le progrès de l’informatique mobile et de la technologie des terminaux, les jeux sur mobile sont aussi variés et animés Ce sont donc des applications complexes que les utilisateurs ont besoin d’utiliser dans des contextes d’exécutions variés Par conséquent, les applications de jeu doivent s’adapter aux différentes capacités des terminaux De plus, il est nécessaire de disposer d’une plate-forme de déploiement pour gérer automatiquement les applications qui prend en compte toutes les activités du cycle de vie de logiciel : l’installation, la mise jours, l’activation/désactivation et la désinstallation Dans cette mémoire, on propose un modèle pour la gestion des jeux multi-joueurs sur mobiles qui s’adapte aux contextes d’utilisation et de déploiement Il se compose des trois serveurs Le serveur de jeu qui s’occupe des sessions de jeu et des comptes des utilisateurs Le serveur de stockage permet de stocker et approvisionner les applications mobiles compatibles avec les terminaux en tenant compte de leurs spécificités Le noyau de ce modèle est le serveur de gestion des dispositifs qui permet d’exploiter les équipements, accéder et contrôler les ressources sur mobiles afin de s’occuper bien toutes les activités du déploiement des applications Le noyau du modèle repose sur l’OMA DM, c’est un protocole qui permet aux serveurs de gérer des terminaux mobiles en échangeant les messages en forme SyncML Ces messages transportent les commandes du serveur aux terminaux afin d’agir sur les objets gérés du dispositifs Ces objets sont représentés par une structure arborescente hiérarchique appelé l’arbre de gestion du dispositif Les nœuds de l’arbre peuvent décrire l’information de configuration ainsi que les applications Le déploiement des applications basé sur le protocole OMA DM est effectué par les interactions sur les nœuds de l’arbre Une réalisation du serveur de gestion des dispositifs est effectué pour démontrer la faisabilité du modèle proposé Elle se base sur le framework open source Funabol qui est une implémentation de protocole OMA DM Mots-clés : gestion des dispositifs, déploiement composants, jeu multi-joueur, OMA DM, GASP ii Table des matières Introduction I État de l’art Projet JEMTU 1.1 1.2 1.3 Plate-forme GASP 1.1.1 Architecture du GASP 1.1.2 Interfaces de communication : GASPClient et GASPServer 1.1.3 Services proposées par GASP 1.1.4 Optimisation des communications : protocole MooDS 1.1.5 Synthèse Plate-forme Client Provisionning - JSR 124 1.2.1 Architecture générale 1.2.2 Stockage 10 1.2.3 Découverte 10 1.2.4 Livraison 11 1.2.5 Synthèse 11 Conclusion 11 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 Standard de gestion de dispositif 3.1 3.2 3.3 17 Protocole SyncML 17 3.1.1 Spécification de SyncML 17 3.1.2 Framework de SyncML 19 3.1.3 Paquet, message et commandes de SyncML 20 3.1.4 Formation de données de SyncML 21 Le protocole OMA Device Management 21 3.2.1 Modèle de données 22 3.2.2 Protocole et mécanisme 24 3.2.3 Gestion des applications avec OMA DM 26 Conclusion 30 Technologie pour le déploiement base de composants 4.1 4.2 4.3 4.4 II 31 PushRegistry 31 4.1.1 Composant de PushRegistry 31 4.1.2 Cycle de vie et Activation de Midlet 32 4.1.3 Connexion entrante 33 4.1.4 Enregistrement de Poussé 34 Le Modèle OSGi 35 4.2.1 Architecture multi-couche 36 4.2.2 Bundle 36 4.2.3 Services 38 LIBlet 39 4.3.1 Profil MIDP 3.0 avec le modèle composant LIBlets 39 4.3.2 Dépendance du LIBlet 40 4.3.3 Découvert de MIDlet dans le profile MIDP 3.0 42 Conclusion 43 Approche des Modèles étudiés pour le déploiement Modèle Proposé 44 45 5.1 Modèle général 45 5.2 Composants du système 46 5.2.1 Serveur de jeu 46 5.2.2 Portail de Stockage 46 iv 5.2.3 5.3 Serveur de gestion de dispositif 47 Contextes de déploiement 47 5.3.1 Demande de déploiement X sur le mobile M 47 5.3.2 Gestion de dispositif 48 5.3.3 Recherche d’une application indisponible 49 5.3.4 Conclusion 49 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 Réalisation de l’activation du MIDlet 60 7.1 Enregistrement de PushRegistry d’une MIDlet 60 7.2 Découverte et Activation d’une MIDlet 61 7.3 PushRegistry avec le déploiement base de composant 63 7.4 Conclusion 64 Conclusion et perspectives 65 Bibliographie 68 A Prototype de gestion des dispositifs 69 v Table des figures Fragmentation des APIs 2 Les objectifs de la gestion des dispositifs 1.1 Architecture du GASP 1.2 Architecture du serveur SUN d’approvisionnement 10 2.1 Simplification des APIs 13 2.2 Spécification de MSA 14 2.3 Composants JSRs de MSA 14 2.4 Modèle d’éxecution 15 2.5 Cartographie Technologique de MSA 16 3.1 Représentation du paquet SyncML 18 3.2 Protocole du SyncML 19 3.3 Framework du SyncML 20 3.4 L’arbre de gestion de dispositif 22 3.5 Packages du protocole OMA DM 25 3.6 La description de dispositif 27 3.7 Le protocole de gestion d’application du framework OMA DM 28 3.8 La description d’objet de gestion d’application (Nokia série 60) 29 4.1 Elements typiques de PushRegistry 32 4.2 Cycle de vie et Activation de Midlet 32 4.3 Diagramme de séquence d’activation sur le réseau 33 4.4 Architecture générale 35 4.5 Architecture multi-couche 36 4.6 Cycle de vie d’un bundle 37 4.7 Contenu d’un bundle 37 4.8 Registre de services 38 vi 4.9 Modèle d’application du profil MIDP 2.0 et 3.0 40 4.10 Dépendance basée le Hash du LIBlet 41 4.11 Dépendance basée le certificate du LIBlet 41 4.12 Attribute de Dépendance 42 4.13 Découverte le MIDlet 42 5.1 Modèle proposé du système de jeu multi joueur 46 5.2 Diagramme de séquence de déploiement d’application sur la mobile 48 5.3 Diagramme de séquence de gestion de dispositif 48 5.4 Diagramme de séquence de recherche d’une application indisponible 49 5.5 Diagramme de séquence de téléchargement d’une application 50 6.1 Le framework Funambol 52 6.2 Simplification des APIs 52 6.3 Base de données du Serveur DM 54 6.4 Diagrame d’état d’une session 55 6.5 Les opérations atomiques de Funambol OMA DM 56 6.6 Arborescente de gestion des applications 57 6.7 États de deploiement de l’application 58 7.1 Processus d’activation d’une MIDlet 62 7.2 Sous-MIDlets pour le déploiement base de composants 63 vii Introduction De nos jours, les téléphones mobiles sont utilisés massivement dans la vie quotidienne Leurs services sont aussi variés et animés, surtout les jeux sur mobile Une des tendances très intéressantes est le jeu multi-joueurs Du point de vue informatique, ce sont des applications complexes distribuées qui imposent l’utilisation de techniques modernes Ce stage se déroule dans l’équipe CAMA du département informatique de l’ENST Bretagne projet est appelé JEMTU Brest Notre [?], 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 compatible avec Java représente plus de la moitié du marché des mobiles Cependant, elle provoque de nouveaux défis, il est difficile de réaliser des applications pour mobiles en raison de l’hétérogénéité des équipements matériel et logiciel Les différences de caractéristiques, fonctionnalités, standard de fabrication, etc rendent le développement complexe et donc coûteux La figure représente le modèle de développement sur les mobiles, elle illustre la fragmentation d’APIs pour réaliser des applications Ce modèle est assez complexe et inconsistant Il n’intègre pas bien l’évolution ; et son architecture n’est pas bien structurée Une nouvelle initiative est donc nécessaire pour s’adapter non seulement toutes les caractéristiques actuelles mais aussi aux développements futurs De plus, le nombre de dispositifs ne cesse d’augmenter et ils intègrent beaucoup de services et d’applications Comme la figure 2, chaque utilisateur peut posséder plus d’un équipement, É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 2 Fig – Fragmentation des APIs il veut les mêmes applications et les mêmes données dans des environnements différents (par exemple : son calendrier, son courrier, etc.) sans répéter des actions semblables d’installation sur tous ses terminaux Du côté des fournisseurs, ils veulent aussi offrir facilement de plus en plus des nouveaux services, applications etc aux terminaux sur le réseau mobile avec n’importe quel transport On a donc besoin d’un système de déploiement automatique (recouvrant l’installation, la mise jour, l’activation et la désinstallation) des outils sur mobiles La figure 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 Chapitre Réalisation du Serveur DM Ce chapitre expose une réalisation du protocole OMA DM pour gérer des dispositifs et déployer des applications sur les mobiles Elle se compose d’un serveur d’implémentation de gestion avec une interface web où l’on entre des commandes Ce serveur se base le framework Funambol et fonctionne sur l’infrastructure J2EE On utilise l’outil SyncML Conformance Test Suite pour le tester 6.1 Framework Funambol Le serveur de Funambol DM est une réalisation du côté serveur du protocole d’OMA DM et d’un framework extensible pour le développement d’applications Ce framework fournit un noyau des protocoles et des services pour automatiser le la gestion de dispositif Il permet de : – Configurer et initier les dispositifs – Interroger les caractéristiques de dispositif – Surveiller les activités du dispositif – Approvisionner les logiciels mobiles – Installer, mettre jour et supprimer les logiciels sur le dispositif La figure 6.1 décrit l’architecture du serveur de framework [?] Il est composé de couche : – Couche Transport : le moyen par lequel les messages de client accèdent au système L’implémentation contient le protocole HTTP mais d’autres peuvent être ajoutés – Couche Protocole : responsable d’interprétation et de manipulation du protocole SyncML – Couche Server : implémentation du serveur basée sur le J2EE qui est réalisé et adapté – Couche Application : implémentation des interactions entre le serveur DM et les applications DM du client – Framework : fournit et implémente les services et les abstractions employés par les couches comme le protocole et la représentation SynML, et le noyau du moteur DM 51 6.2 Séquence d’exécution de processus d’opération 52 Fig 6.1 – Le framework Funambol 6.2 Séquence d’exécution de processus d’opération La figure 6.2 présente la séquence d’exécution d’une requête OMA DM La couche web implémente le protocole de transport (les messages d’OMA DM sont transportés via HTTP) La couche serveur contient des EJBs de gestion des dispositifs Fig 6.2 – Simplification des APIs Dans cette figure, les blocs vert décrit les systèmes ou les applications externes Ils agissent sur le serveur DM via une interface de service web ou appelle directement les EJB du serveur L’expéditeur de notification employé par le serveur de Funambol DM peut envoyer des paquets initiales PKG0 (présenté dans la section 3.2.2) aux dispositifs (dans ce cas les sessions de gestion 6.3 JSPs et EJBs 53 sont lancées par le serveur) Les blocs gris sont des parties du noyau du système que l’on ne touche pas Les blocs orange sont des composants personnalisables, qui peuvent être ajoutés, modifiés pour satisfaire les besoins de client mobile Ces sont des parties ce que l’on adapte pour la réalisation du stage Une session peut être lancée par le dispositif ou le serveur Ci présente une session de DM lancée par le serveur pour présenter plus complètement les activités effectuées : La gestion externe (par ex : une console, une application) initie un processus «d’opération de gestion »pour un dispositif spécifié Ce service invoque le service correspondant l’interface d’EJB du serveur L’EJB fait suivre cet appel au moteur de gestion Pour créer le processus d’opération, le moteur de gestion choisit et appelle le processeur approprié la demande dans l’étape Le processus se compose d’opérations atomiques en ordre On enregistre des opérations du processus dans un pipeline d’opérations Le moteur de gestion établit le message de notification (PKG 0) et indique l’expéditeur pour le pousser sur le téléphone Le dispositif reçoit le message de notification ; il commence une nouvelle session OMA DM en envoyant le paquet PKG au serveur L’adaptateur traite les messages du dispositif, les traduit en format XML Ces messages sont traversés une file d’entrée avant que le moteur de gestion ne les traite Le moteur de gestion traite la requête avec l’authentification de dispositif 10 Le moteur de gestion cherche des opérations correspondant au dispositif dans le pipeline 11 Les opérations de gestion sont traversées une file de sorti pour les envoyer au client 12 Les messages de réponse sont traduits en format compatible OMA DM 13 Les messages de réponse sont retournés au dispositif Le processus continue l’étape avec un nouveau message partir du client En effet, dans la même session, toutes les commandes et résultats sont échangés entre le client et le serveur jusqu’à ce que le serveur n’envoie plus de commande Notez que le client peut commencer une nouvelle session l’étape sans recevoir un message de notification 6.3 JSPs et EJBs La réalisation du stage est une application web basée sur l’architecture J2EE Elle se compose de pages Jsp qui capturent des commandes de l’administrateur pour : 6.4 Base de données du Serveur DM 54 – Découvrir la configuration et l’arbre de gestion des dispositifs – Effectuer des commandes atomiques OMA DM sur les nœuds – Gérer et déployer des applications : exploiter, livrer, mettre jour, télécharger, installer, activer, désactiver, supprimer En réalité, les composants du serveur sont configurés comme les JavaBeans du serveur EJB Cette configuration permettre de changer et de adapter facilement Les pages Jsps les utilisent pour accomplir les fonctionnalités en dessus Cependant, les agents extérieurs peuvent demander des services d’EJB sans interagir au l’interface de Jsp 6.4 Base de données du Serveur DM La figure 6.3 montre le schéma de la base de données du server DM Les tables sont : – user : stocke l’information sur les utilisateurs – principal : associe un utilisateur un dispositif Ceci permet des scénarios futur où un utilisateur peut utiliser plusieurs de dispositifs et/qu’un dispositif peut être employé par beaucoup d’utilisateurs – device : stocke des informations sur un dispositif – dmstate : stocke des données sur des opérations en suspens exécuter Fig 6.3 – Base de données du Serveur DM 6.5 Statut d’opération de gestion Les dispositifs dans le réseau mobile sont distribués et il est difficile de maintenir la connexion entre le serveur et le client sans interruption De plus, le processus de gestion est habituellement effectué par des phases qui ne se termine pas nécessairement une certaine heure ou même ne sont pas effectué dans la même session Pour effectuer le processus de gestion, le serveur DM 6.6 Implémentation des opérations 55 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 INEXISTENCE 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 56 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 processeurs 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 57 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’application 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 58 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 59 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éveloppement 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 : l’enregistrement statique et l’enregistrement dynamique Tous les deux doit déterminer un port de Push qui reçoit les agents d’activation (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 l’adresse 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 connaître 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 61 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é, l’ASM 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 connaître 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 62 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 automatiquement 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 63 PushRegistry avec le déploiement base de composant En effet, les jeux sont suivant plus complexes et grands que les autres applications Cependant, 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 effectué par les 7.4 Conclusion 64 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 plate-forme 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 effectuer 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 [...]... le choix indispensable pour le développement pour mobiles, surtout pour la programmation des jeux mobiles qui demande beaucoup de technologies et la compatibilité avec des matériels variés On peut appliquer l architecture MSA pour adapter le modèle GASP du projet JEMTU afin d’obtenir une meilleure plate-forme de programmation des jeux mobiles Chapitre 3 Standard de gestion de dispositif Sur chaque... 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... 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... 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. .. 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,... 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 l’infrastructure logicielle sur mobiles 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... équipements, accéder et contrôler les ressources sur 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... Composants JSRs de la plate-forme 14 Fig 2.2 – Spécification de MSA 2.3 Composants JSRs de la plate-forme MSA définit un ensemble standard de fonctionnalités pour les terminaux mobiles ainsi que la clarification des interactions entre ces diverses technologies Puisqu’il y a une grande variation de matériel et de logiciel pour les mobiles, les spécifications de MSA offrent deux choix : la spécification de MSA... 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, des calendriers 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 3.2 Le protocole OMA Device Management... 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