Luận văn thạc sĩ VNU architecture des systèmes de déploiement pour les équipements mobiles

Plate-forme GASP

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 classe accueillant l’ensemble des méthodes amenées à accéder directement à la base de données (BD) Les classes Platform etMasterApplicationInstances gèrent les sous ensembles représentant l’exécution des jeux LesApplicationInstanceset lesActorSessions, sous ensemble s’intitulant Games Representation.

– Servlet Container: conteneur accueillant les classes de communication de GASP C’est un ensemble deServletsqui est chargé de traiter les requêtes des utilisateurs depuis leur mobile et depuis un jeu utilisant les interfaces de communications de GASP Ces requêtes pour GASP v1.0 utilisent le protocole HTTP over GPRS.

– Game Servers : l’ensemble des logiques de jeu serveur instanciées et gérées par leur ApplicationInstance.

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

– GASP DB : la base de données de GASP.

Interfaces de communication : GASPClient et GASPServer

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

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

– GASPServers: doit être implémentée par la logique serveur, elle lui permet de commu- niquer avec la plate-forme, et d’intégrer le modèle événementiel de la plate-forme.

Services proposées par GASP

Afin de gérer les informations échangées par les joueurs, GASP propose un nombre de services restreints :

Services clients – Lasalle 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 – Lagestion de sessionde jeu mise en oeuvre par ActorSessionetSession.

– Le contrôle d’accès et l’authentification vérifient les droits au niveau de la base de données de GASP.

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

Optimisation des communications : protocole MooDS

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

1.2 Plate-forme Client Provisionning - JSR 124 9 et de décodage des types personnalisés décrits afin que ne soient passés sur le réseau uniquement les valeurs binaires des attributs des objets contenus dans lahashtable du DataEvent.

Synthèse

La plate-forme pour les jeux multi-joueurs sur mobiles GASP constitue une implémentation des spécifications normalisatrices de l’OMA Cette plate-forme reprend donc le modèle fonc- tionnel proposé par l’OMA en y apportant certaines améliorations et clarifications, propose une implémentation de son modèle événementiel et propose des solutions pour l’optimisation des communications avec l’élaboration du protocole MooDS.

GASP a publié des dossiers qui guident à développer des applications, initier l’environne- ment et installer le serveur pour le jeu multi-joueurs Le serveur de GASP basé sur la plate-forme Apache Tomcat et la base de données MySQL, se compose desservletsqui implémentent les fonctionnalités proposées.

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

Plate-forme Client Provisionning - JSR 124

Architecture générale

Cette spécification est implémentée dans un serveur J2EE qui assure la communication avec les clients Ce serveur utilise l’APIs pour implémenter la découverte, la recherche et la livraison des paquets Les paquets doivent être stockés avec leurs descripteurs dans un dépôt Selon le type de terminal client, un adaptateur est mis en place pour réaliser les différents protocoles de téléchargement.

La figure 1.2 montre l’architecture du serveur SUN L’API est utilisée par des servlets,avec les adaptateurs MIDP et JNLP assurant le téléchargement, et le dépôt (repository) est implémenté par un composant EJB.

1.2 Plate-forme Client Provisionning - JSR 124 10

Fig 1.2 – Architecture du serveur SUN d’approvisionnement

Stockage

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

– Empaquetage stocke des paquets dans un format standard en fournissant des informa- tions des décision sur la manière dont ces paquets sont découverts et livrés L’empaquetage se compose d’un fichier archive PAR qui peut contenir plusieurs paquets et d’un fichier descripteur XML qui contient toutes les informations concernant ces paquets Les 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 Par exemple, on peut vérifier que le fichier JAR est conforme à la spécification MIDP.

– Ajout au dépôt enregistre des archives PAR dans le serveur de stockage.

Découverte

Le serveur d’approvisionnement doit contenir un service qui permet aux clients de découvrir les paquets disponibles à la livraison Les composants J2EE du serveur utilisent les API définies dans la spécification de JSR 124 afin d’exécuter trois tâches pendant ce processus de découverte : – Détermination des caractéristiques du terminal de l’utilisateur Chaque type de terminal est décrit sous forme d’un profil contenant une liste de capacités Lors de la recherche, ces capacités seront comparées aux exigences afin de choisir les paquets compatibles.

– Recherche des paquets appropriées dans le dépôt Une série de filtres standards est appli- quée afin d’éliminer les paquets incompatibles avec le terminal Mais on peut personnaliser le filtrage selon d’autres critères en réalisant l’interfaceMatchPolicy.

– Production des URIs qui permettent au terminal d’initier la livraison Ces URIs sont une

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

Livraison

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

Synthèse

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

Conclusion

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

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

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

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

Client Provisioning - JSR 124 pour stocker, rechercher et le télécharger les applications mobiles compatibles avec la capacité de terminal.

Cependant, ces plate-formes ont encore des manques Pour le développement, GASP ne considère pas encore la hétérogénéité des dispositifs, leur capacité qui sont importantes avec les exigences technologiques et l’architecture complexe de jeu En plus, GASP ne vise pas au déploiement de jeu et à la gestion de leurs versions La plate-forme Client Provisioning est pour le déploiement sur mobiles mais toutes les activités du déploiement sont décidées par l’utilisateur, les rôles d’administrateur et de fournisseur des services ne sont pas importants.

Dans cette plate-forme, il manque également le contrôle du déploiement sur le terminal.

Par conséquence, on a besoin des meilleures solutions pour le développement, le déploiement et la gestion de jeux sur mobiles Selon moi, il est nécessaire de disposer d’un système qui gère bien des dispositifs (leur configuration et leurs applications) Dans ce système, l’administrateur peut commander les terminaux pour les configurer, déployer les applications, etc.

Comme les dispositifs continuent à évoluer sans cesse et à incorporer de nouvelles techno- logies et de nouveaux services, une plate-forme qui standardise ces nouvelles technologies est nécessaire Actuellement, Nokia, Vodafone et quelques autres fournisseurs mobiles se mettent d’accord sur une architecture conỗue pour simplifier les normes de Java sur les mobiles, c’est laMobile Service Architecture (MSA) Elle est marqué le JSR 248 [18].

Ce chapitre présente le modèle MSA, c’est une nouvelle plate-forme pour le monde des mobiles Ce modèle a pour but de spécifier les services standards et l’environnement des ap- plications, en construisant sur le succès du Mobile Information Device Profile (MIDP), du

Connected Limited Device Configuration (CLDC), et la technologie Java pour l’industrie sans fil (JTWI) Elles simplifient, de plus, les caractéristiques existantes pour définir une architecture cohérente de services Java et pour assurer la compatibilité applicative à travers les dispositifs mobiles de plusieurs fournisseurs.

But de conception

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

Deuxièmement, l’approche générique de la MSA s’applique à une grande variété de ter- minaux et des segments de clients différents Ceci est réalisé en proposant deux définitions de plate-forme (MSASubsetet de MSA complet) Ces définitions soutiennent aussi la configuration

Initiative

CDC (qui est réservée aux dispositifs puissants), et offrent la condition pour les caractéristiques qui ne sont pas encore disponibles sur tous les dispositifs compatible avec la MSA

Troisièmement, la conception de MSA a pour but d’assurer la consistance de définition dans non seulement l’environnement actuel de Java mobile mais aussi la prochaine génération (MSA et MSA avancé - JSR 248 et JSR 249)

Actuellement, il y a beaucoup d’APIs variées correspondants aux caractéristiques des dispo- sitifs mobiles Par conséquentes, il existe une forte fragmentation à cause des APIs optionnelles.

L’idée initiale est donc de proposer une plate-forme qui peut consolider et lier toutes les APIs nécessaires [17] Ces APIs sont rassemblées dans un noyau commun et on clarifie les exigences ajoutées et leurs relations Cette plate-forme est unifié et consistante.

Pour construire cette plate-forme, le processus consiste en quatre étapes : – Collecter tous les JSRs concernant les mobiles pour former la plate-forme MSA On décide quelles fonctionnalités sont nécessaires, quelles ressources sont requises, etc.

– Ajouterdes clarifications en basant sur les JSRs collectés Parce que les interactions entre ces JSRs ne sont pas bien spécifiées Ces clarifications peuvent réduire la fragmentation et l’ambiguùtộ.

– Spécifier des exigences obligatoires sur la sécurité et le matériel.

– Fournir le Technology Compatibility Kit (TCK) qui vérifie la compatibilité aux clarifi- cations définies dans MSA.

Composants JSRs de la plate-forme

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 MSASubset et ou la spécification complète de MSA.

Fig 2.3 – Composants JSRs de MSA

– MSA Subset décrit les fonctionnalités communes minimales des mobiles Il se compose des JSRs obligatoires Les dispositifs compatibles avec MSA doivent satisfaire toutes les fonctionnalités de ces JSRs.

– La spécification complète de MSA rassemble toutes les JSRs concernant les équipements mobiles d’aujourd’hui Aux fonctionnalités indispensables de MSASubset, elle ajoute des

JSRs dont caractéristiques visent les dispositifs les plus modernes Ces composants JSRs sont optionnelles, c’est-à-dire leur implémentation dépendent du terminal.

Modèle d’éxecution

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

Cartographie technologique

MSA est réservée aux configurations standards CLCD, c’est-à-dire aux configurations ayant des ressources limitées, même s’il est adaptable aux équipements CDC avec des fonctionnalités plus puissantes Car les technologies modernes aujourd’hui vont devenir la base commune dans un futur proche, il est donc nécessaire de disposer d’une cartographie permettant le dévelop- pement plus rapide de la technologie C’est le but de la plate-formeMSA Advanced qui est en cours de préparation.

La figure 2.5 décrit des composant deMSA Advanced En se basant sur leframework CDC et le Profil de Fondation, elle vise les équipements modernes qui intègrent les connexions en haute débit, les interfaces graphiques et les services Il s’adapte encore aux CLDC avec un noyau commun d’APIs comme la plate-forme MSA Cependant, il ajoute le framework de Mobile Optional Management qui soutient un environnement de gestion plus fort.

– Loadable APIs: la capacité de téléchargement des nouveaux APIs et recompiler.

– Advanced Core APIs : le noyau avancé des nouveaux APIs

Conclusion

– 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 peut limiter l’hétérogénéité des matériels et la fragmentation du développement afin d’exécuter les différentes étapes du déploiement d’une entité logicielle Elle peut être compatible avec plu- sieurs dispositifs différents, non seulement les configurations matérielles limitées mais aussi les équipements avec de fortes capacités Ce chapitre a présenté aussi une extension de MSA qui pourra s’adapter aux changements rapides des matériels, c’est la plate-forme MSA avancé Elle a lancé une orientation technologique qui assure la consistance pour le développement pendant longtemps.

Actuellement, SUN a proposé le toolkit sans-fil de CLDC ver 2.5 [19] conforme à la MSA pour la programmation mobile Cet émulateur fournit des options de développement pour les plate-formes JTWI, MSASubset et MSA complet, ou même les JSRs isolés Il fournit aussi des outils pour la signification, la permission, et la technologiePushRegistry [22] etc.

En conséquence, la plate-forme MSA est le choix indispensable pour le développement pour mobiles, surtout pour la programmation des jeux mobiles qui demande beaucoup de technologies et la compatibilité avec des matériels variés On peut appliquer l’architecture MSA pour adapter le modèle GASP du projet JEMTU afin d’obtenir une meilleure plate-forme de programmation des jeux mobiles.

Standard de gestion de dispositif

Sur chaque mobile, il existe un arbre de gestion qui consiste des répertoires et des fichiers de données, appelés les nœuds Ces nœuds se situent sur l’arbre à une adresse déterminé (URIs) et contiennent des informations sur le dispositif, ses applications et ses composants OMA DM

[11] est un protocole permettant aux serveurs de gérer des terminaux mobiles en se basant sur cet arbre Ce protocole est une extension du protocole SyncML [5] dont l’objectif initial est de la synchronisation des données entre les terminaux et les serveur Dans l’OMA DM, le serveur et les clients communiquent par le protocole SyncML qui utilise une représentation XML et un transport par HTTP Dans ce chapitre, nous présentons le protocole SyncML et le modèle de la gestion des dispositifs de OMA DM.

Protocole SyncML

Spécification de SyncML

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

– Le protocole de synchronisation – La fixation protocole

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ésMultipurpose Internet Mail Extension (MIME) qui fournissent un mécanisme pour différencier le contenu ou les types séparés de documents Cette représentation indique un type de la description de document XML (DTD) [7], qui permet la représentation de toutes les informations exigées pour exécuter la synchronisation, en incluant les 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 concep- tuel pour des messages de synchronisation Le message de SyncML est une entité individuelle de MIME de SyncML, essentiellement un document XML bien formé Cette représentation sera décrite en détail dans la section 3.1.3

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

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

– Le Serveur SyncML contient un agent de synchronisation serveur et un moteur de synchronisation, 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.

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 desE-mail ou d’autres méthodes Puisque les messages de SyncML sont indépendants, un grand nombre de formes de transports peuvent être employé.

Framework de SyncML

Ceframework 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 serveur qui 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 moteur synchronisera le client avec son image sur serveur.

Leframework 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écepteur des 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 fournit des APIs pour appeler l’adaptateur de SyncML.

Pour la synchronisation, l’agent de synchronisation du serveur appelle les APIs dans l’in- terface SyncML Ces APIs lui permette de contrôler l’accès du moteur de synchronisation au ré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 à son adapteur de SyncML, en appelant des fonctions dans l’interface SyncML.

Paquet, message et commandes de SyncML

Comme on a présenté précedement, les opérations de synchronisation de SyncML sont conceptuellement 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 sont pas 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 deSyncBody 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 des- tinataire de changer des éléments qui peuvent être accédés par le destinataire.

– 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 exé- cutés avec une sémantique toute ou rien (transaction).

– 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 commandesGet etSearch.

– 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 seule- ment pour la synchronisation.

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, 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.

Le protocole OMA Device Management

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 pour envoyer les opérations Cette description est appeléel’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 tous les 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 dispositif

Les nœud peuvent être de n’importe quelle forme : un paramètre simple, une image GIF ou mê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 DevInfoqui 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 (Par exemple, les sonneries).

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 type déterminé et on peut lire et mettre une valeur compatible La valeur de nœud peut représenter plusieurs formats de données, soit un text simple soit une application C’est l’initiative de gestion 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, un serveur doit utiliser l’adresse /DMAcc/xyzInc correspond à son URI qui représente son chemin depuis la racine de l’arbre de gestion.

Les nœuds sont les entités qui peuvent être manipulées par le protocole OMA DM La propriétéFormatindique 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.

Les nœuds de gestion peuvent être manipulés par des messages SyncML DM contenant les commandes 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 le nœ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 et Replace 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.

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ôlables dans les dispositifs avaient des formats différents et des comportements différents Pour éviter cette situation, l’OMA a définit un certain nombre d’objets obligatoires [9] Ces objets sont principalement 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.

Protocole et mécanisme

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

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 La seconde effectue des commandes du serveur sur le client Ces phases sont considérées comme des transactions des paquets SyncML.

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

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 de gestion D’autres dispositifs ne souhaitent pas ouvrir le port (c’est-à-dire accepter les connexions exté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 commandeAlert, qui se compose de :

– L’information de dispositif (comme le constructeur, le modèle, etc.), qui se situe dans l’objetDevInfo

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 a envoyé 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 le certificat 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 la transaction du message précédent.

Le Paquet 4 se produit pour terminer la session ó commencer une nouvelle itération si d’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 continuera jusqu’à 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 utilisant des 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 pour l’annoncer au destinataire Si un paquet de SyncML est transféré en multi-messages, le dernier message dans le paquet doit inclure l’élément.

Ce mécanisme peut provoquer la confusion des messages, surtout dans le cas ou le serveur envoie des lots d’opérations (avec la commandeSé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.

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 Leframework de description de dispositif nous permet de définir les descriptions compatibles d’applications mobiles Avec le protocole OMA DM et ses commandes de manipulation des objets, le serveur a la capacité de déployer les applications du dispositif (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 aient des structures et des comportements différentes Pour cela, OMA DM intègre un concept de framework de description de dispositif (Device Description FrameworkDDF) [7] Ce framework prescrit une manière pour les fabricants de décrire leurs dispositifs de sorte qu’un système de gestion puisse comprendre comment contrôler le dispositif.

Fig 3.6 – La description de dispositif

La description proposée du framework est définie par uneDocument Type Definition DTD XML Elle représente un objet de gestion, ou un arbrecompletde gestion Les fabricants qui suivent 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 duframework est la DTD, qui permet de représenter un objet par un document XML En basant sur ceframework, 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 pour que le serveur puisse connaợtre ce type de dispositifs et ses caractộristiques Il peut dộcrire chaque 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 leframework 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és qui 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 l’infra- structure 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 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’information d’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.

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 gestion des applications à distance via OMA DM Cette figure représente l’état des applications du mobile 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 sont livrées par le serveur de gestion via le protocole OMA DM mais ne sont pas encore lancées La livraison, 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 client par des messages SyncML Le serveur envoie un ensemble des commandesAddpour ajouter une nouvelle 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 les nœuds d’opérations correspondant aux activités du déploiement que les serveurs de gestion des dispositifs peuvent lancer par la commandeExec En effet, ces nœuds référencent un ensemble des commandes qui effectuent des applications Par exemple, pour installer une application livrée, le serveur envoie une commandeExecà son nœud/Operation/Install, cette application change son état en activé En notation, après avoir été installée, cette application est considérée

Conclusion

comme une application déployée et elle se placera sous le nœud Deployed qui s’occupe des applications exécutables.

Le serveur peut non seulement délivrer directement des applications au client, mais aussi demander au client de tộlộcharger des logiciels en lui annonỗant l’adresse URI du fichier jad.

Mais il faut envoyer également au client le type MIME de l’application Après que le client a téléchargé l’application requise, le serveur peut la contrôler.

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é par des 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 des services, 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 est mieux 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 mobiles sera à base de composants et de services L’OMA DM s’adaptera bien à la problématique la gestion 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 pro- grammation, le stockage, le déploiement des applications de jeux et la gestion des services de jeux.

Technologie pour le déploiement à base de composants

Ce chapitre expose quelques mécanismes qui peuvent aider au déploiement à base de com- posants sur les mobiles La section 4.1 décrit la techniquePushRegistry du profil MIDP 2.0 et comment l’appliquer pour lancer l’application mobile La plate-forme dynamique de servicesOSGi est aussi présenté dans la section 4.2 Et dans la dernière section du chapitre, c’est le nouveaux modèle de composants LIBlet du profil MIDP 3.0 qui est étudié.

PushRegistry

Composant de PushRegistry

PushRegistry est un composant de Application Management System (AMS), le logiciel qui dans le dispositif s’occupe du cycle de vie de chaque application (installation, activation, exé- cution, et déplacement) La figure 4.1 montre les éléments duPushRegistry.

Les APIs dePushRegistrypermettent d’enregistrer des alarmes et des connexions "poussée",rechercher des informations sur des connexions poussées et de découvrir si la MIDlet est activée par une connexion entrante.

Fig.4.1 – Elements typiques de PushRegistry

Cycle de vie et Activation de Midlet

La figure 4.2 décrit des états du cycle de vie d’une application mobile MIDlet [22] Elle présent aussi les événements qui peut activer une MIDlet sans changer du cycle de vie d’une MIDlet Sauf la méthode d’activation manuelle, il y en a encore deux suivant qui applique la techniquePushRegistry On peut lancer une MIDlet :

Fig 4.2 – Cycle de vie et Activation de Midlet

Le diagramme de séquence 4.3 [22] démontre l’activation par connexion entrante La MIDlet doit d’abord enregistrer une connexion de Push à l’AMS pour que puisse être activée par les agents externes Cet enregistrement est exécuté seulement une fois L’AMS est responsable de vérifier les événements externes arrivés Quand une connexion entrante se produit, l’AMS activera la MIDlet appropriée si cette MIDlet est inactive Après l’activation de la Midlet, l’AMS ne s’occupe plus des connexions, la MIDlet doit s’occuper elle-même de tous les événements.

Elle doit surveiller des connexions entrantes afin de maintenir son cycle de vie La MIDlet peut également créer lui-même une connexion entrantes afin de lacer une autre.

Fig 4.3 – Diagramme de séquence d’activation sur le réseau

Connexion entrante

MIDP 2.0 définit de nouveaux types de connexion TCP et UDP, qui peuvent être considérées comme la connexion entrante, s’adapte à la poussée En outre, les APIs de la transmission sans fil de messages (Wireless Message API WMA, JSR 120) rendent les SMS compatibles avec l’activation de poussée Typiquement, on utilise une socket et un datagram pour activer une MIDlet.

Une connexion entrante est basée sur une adresse locale statique ou dynamique Une adresse locale se compose typiquement de deux parties, une adresse (telle qu’une addresse IP ou un numéro de téléphone), et un port Les numéros de téléphone sont statiques (fixés), alors que les adresses IP sont assignées statiquement ou dynamiquement, ainsi que les ports Pour créer une connexion entrante basé sur une adresse, on appel la fonctionnalité Connector.open() avec une URL qui décrit un protocole et un port entrant local.

En utilisant une adresse assignée du système, on doit lancer cette adresse de sorte que les sys-

4.1 PushRegistry 34 tèmes externes puissent se connecter à l’application Si on utilise leServerSocketConnection ou UDPDatagramConnection, on peut obtenir l’adresse dynamiquement assignée par les mé- thodesgetLocalAddress()etgetLocalPort() On peut également rechercher le nom de l’hot du dispositif, par l’appelSystem.getProperty("microedition.hostname").

Enregistrement de Poussé

Pour devenir une application compatible PushRegistry, une MIDlet doit s’inscrire à un enregistrement de poussée Il y a deux types : l’enregistrement statique et celui dynamique.

Ce sont les enregistrements des connexions statiques qui se produisent pendant l’installation de la suite de MIDlet Ces enregistrements sont spécifiés par la liste des attributsMIDlet-Push dans le fichier JAD ou dans le manifeste de la suite MIDlet :

MIDlet-Push- : , ,

– MIDlet-Push-identifie l’enregistrement de poussée ó n est un nombre à partir de 1 ; par exemple MIDlet-Push-1.

– identifie l’adresse d’enregistrement, elle a le même format d’URL utilisé en appelant Connector.open().

– nom de la classe du MIDlet qui est activée quand AMS détecte l’activité de réseau dans.

– filtre utilisé pour limiter les serveurs qui peuvent activer.

L’AMS effectue l’enregistrement statique quand la suite de MIDlet est installée L’installa- tion échouera si on enregistrer une adresse qui est déjà attribuée De même, quand la suite de MIDlet est désinstallé, l’AMS supprime automatiquement tous ses enregistrements associés.

On enregistre les connexions dynamiques et les alarmes temporelles, en utilisant des APIs PushRegistry.

– Enregistrement d’une alarme de temporisateur : L’alarme de poussée permet de planifier la future exécution d’un MIDlet Pour programmer un lancement de MIDlet par l’AMS, la MIDlet appelle la méthodePushRegistry.registerAlarm(), avec un argument déclarant le nom entier de la classe de la MIDlet à lancer, et un autre déclarant le temps avant le lancement Notez que les APIs de PushRegistry ne permettent pas de découvrir si uneMIDlet a été activée par une alarme.

Le Modèle OSGi

Architecture multi-couche

L’architecture générale OSGi [1] est décrit dans la figure 4.4 La plate-forme OSGi prend en charge la manipulation des bundles en fournissant des services de déploiement et d’exécution.

Elle se base sur la machine virtuelle java (JVM).

La figure 4.5 détaille l’architecture multi couche d’OSGi Les applications sont déployées sur la plate-forme suos la forme d’unités de livraison appeléesbundles qui seront détaillés dans la section 4.2.2 La plate-forme offre aux applications d’une part un registre de services qui permet de rechercher des objets offrant un contrat de service donné, et d’autre part, un mécanisme de notification des changements qui se produisent sur les services Le déploiement de la plate- forme, réalisé par la couche de cycle de vie, couvre les opérations de déploiement La couche la plus basse de l’architecture prend en charge le chargement de classes, il permet à partager des classes entre des bundles en implémentant un chargeur de classes.

Bundle

Un bundle est une unité java de déploiement Une fois installé le cycle de vie d’un bundle dépend des actions de déploiement (voir la figure 4.6) :– INSTALLED : lebundle vient d’être installé ou d’être mis à jour

– RESOLVED : les dépendances dubundle sont résolues – STARTING : le bundle est en train d’être démaré, l’état suivant est ACTIVE – ACTIVE : lebundle est en service

– STOPPING : lebundle est en train de s’arrêter, l’état suivant est RESOLVED – UNINSTALLED : le bundle est déinstallé

STOPPING STOPPING install start update refresh u n in s ta ll re s o lv e re fr e s h u p d a te stop u n in s ta ll

Fig 4.6 – Cycle de vie d’un bundle

Le bundle est conditionné sous la forme d’un fichier JAR La figure 4.7 présente le contenu d’un bundle Unbundle contient des classes java qui réalisent des interfaces et leurs implanta- tions Il existe normalement un activateur qui active lebundle en utilisant l’information décrite dans le fichier manifeste Le fichier manifeste décrit aussi les services requis et fournis, ainsi que les paquets importés et exportés Un bundle contient aussi des ressources tel que des fichiers, du code natif etc.

Le fichier manifeste décrit l’information du bundle en utilisant des en têtes La plate-forme OSGi a définit un ensemble d’en têtes standards, par exemple :

– Bundle-Name : Nom du bundle

– Bundle-Version : Version du bundle

– Bundle-Activator : La classe de l’activateur – Import-Package : la liste des paquets importés – Import-Service : la liste des services requis – Export-Package : la liste des paquets exportés – Export-Service : la liste des services fournis – Bundle-NativeCode : bibliothèque de codes natifs, comme une JNI –

La plate-forme OSGi permet au créateur dubundle de définir ses en têtes.

Services

OSGi suit le paradigme de la programmation orientée service dynamique Le client récupère la liste des services en interrogeant un registre de services Un fournisseur enregistre son service auprès du registre de services en y associant un contrat (figure 4.8) La programmation orientée service permet à un service d’apparaợtre et de disparaợtre pendant son exộcution, donc les clients qui utilisent ce service doivent être sensible au changement.

Service Provider Acme.com register bind/invoke bind/invoke notify

Dans la plate-forme OSGi, les services sont le moyen pour lesbundles de coopérer Chaque service est présenté par une interface, qui est réalisée par une implémentation Une implémen-

LIBlet

Profil MIDP 3.0 avec le modèle composant LIBlets

Un LIBlet est un composant logiciel partageable que des MIDlets peuvent employer au moment de l’exécution Les LIBlets sont des fragments de code qui ne peuvent pas s’exécuter eux-mêmes sauf dans le contexte de l’environnement d’exécution d’une MIDlet Chaque LIBlet expose un ensemble de classes et de ressources que des applications peut utiliser Ces classes et ressources de LIBlet sont empaquetées dans le fichier JAR (comme les MIDlets) et il est nécessaire donc d’avoir un fichier JAD qui les représentes.

La figure 4.9 montre le modèle d’application du profil MIDP 3.0 plus d’avantage que celui duMIDP 2.0 Dans le profil MIDP 2.0, chaque application mobile procède des classe et ressources privés, ces applications sont isolées et permis d’appeler les APIs fixés Aucun partage existe entre eux bien que elles aient les mêmes classes ó les mêmes ressources Mais avec le nouveau profil MIDP 3.0, les applications peuvent utiliser ensemble les même classes et ressources Par exemple, on suppose qu’il y aie deux applications de jeu qui se base sur la plate-forme GASP et le protocole MooDS avec les mêmes APIs comme la figure 4.9 On peut construire des composants partageables réutilisable LIBlets contenant les APIs de GASP ou les ressources communs pour que les applications mobiles puissent utiliser ces LIBlets comme leurs dépendances.

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

Un fichier JAR de LIBlet se compose de : – Un fichier Manifest décrit le contenu du LIBlet.

– Des classes partageables du LIBlet.

– Des ressources employées par le LIBlet.

– Des données persistantes dans le RMS (Record Management System).

Dépendance du LIBlet

Non seulement les MIDlet, mais aussi les LIBlet peuvent employer les autres LIBlets Un LIBlet employé par les autres est appelé une dépendance et les suites MIDLets et le LIBlets doivent déclarer leur dépendances quand ils veulent les utiliser Il y a deux options pour dé- clarer la dépendance de LIBlet qui peut être authentifiée par l’AMS (Application Management

System) : basé surhash et basé sur le certificat de fournisseur – Une déclaration de dépendance de LIBlet basée surhashindique la dépendance sur seule- ment une version spécifique d’un LIBlet, en utilisant le hash du JAR du LIBlet Une démonstration est présentée dans la figure 4.10, le manifeste de la MIDlet déclare la dépendance fixé d’une LIBlet spécifié avec le LIBlet-Jar-Hash Selon cette déclaration, aucune liste de versions ne peut être indiquée.

– Une déclaration de dépendance basée sur le certificat indique des dépendances sur des ver- sions compatibles multiples d’un même LIBlet de fournisseur C’est utile pour permettre à une MIDlet existante sur le dispositif de télécharger de nouvelles versions d’un four- nisseur de LIBlet sans mettre à jour la MIDlet Dans ce cas, un certificat de fournisseur

4.3 LIBlet 41 est employé au lieu d’une déclaration de dépendance de hash La figure 4.11 présent le fichier de manifeste d’une MIDlet qui déclare une dépendance avec le certificat du LIBlet.

Dans ce fichier, la signe 1.0+ monte que cette MIDlet utilise des versions plus nouvelles du LIBlet.

Fig 4.10 – Dépendance basée leHash du LIBlet

Fig 4.11 – Dépendance basée le certificate du LIBlet

L’installation d’une suite de MIDlet peut échouer si ses dépendances ne peuvent être satis- faites Un dispositif ne peut pas contenir des versions multiples de la même suite de MIDlet en même temps ; cependant, il peut avoir des versions multiples du même LIBlet en même temps pour les utilisations différentes des MIDlets.

Comme un LIBlet peut dépendre d’un autre LIBlets, il peut y avoir des dépendances circu- laires Ces dépendances circulaires posent le problème de la poule et de l’oeuf Le développeur doit se rendre compte que les dépendances circulaires sont possibles en utilisant des dépendances et éviter de déclarer de telles dépendances.

L’attribut Dependency- indique aussi des dépendances standard comme l’API d’unJSR Par exemple, une application MIDlet de navigation qui dépend de JSR 179 (Location) et également d’un LIBlet de carte développé par un fournisseur est présenté en figure 4.12

Découvert de MIDlet dans le profile MIDP 3.0

La figure 4.13 démontre le nouveau scénario de l’installation de MIDlet 3.0 ou on trouve une extension de LIBlet En utilisant le navigateur, l’utilisateur accède à un serveur de provision et voit une description de la suite de MIDlet avec un lien correspondant à la suite de MIDlet.

Si le lien à un fichier JAR décrit dans les spécifications de MIDP, ce fichier et son URL sont passés à l’AMS sur le dispositif pour activer le processus d’installation Celui ci peut comporter le téléchargement des LIBlets dépendants si des dépendances sont indiquées par ce MIDlet.

Conclusion

L’approvisionnement de LIBlet est transparent pour l’utilisateur Le descripteur de MIDlet énumère ses dépendances de LIBlet Chaque LIBlet peut en plus avoir d’autres dépendances de LIBlet Le descripteur JAD impliqué, pour les MIDlet et les LIBlets, doit être téléchargé d’abord avant que des fichiers JARs de MIDlet ou de LIBlet puissent être téléchargés En se basant sur ces descripteurs, le dispositif calcule la taille nécessaire pour l’installation et avise l’utilisateur de la taille globale du téléchargement, du MIDlet et des LIBlets inclus.

L’installation de LIBlet est toujours déclenchée par un déploiement du MIDlet dont une dépendance correspondant au LIBlet C’est la même chose pour étendre un LIBlet Si un LIBlet est étendu, le MIDlet qui dépend de ce LIBlet doit mettre à jour également son descripteur JAD avec une nouvelle dépendance de LIBlet Une nouvelle version de MIDlet doit être fournit même si aucun changement de code de la MIDlet pour cet extension de LIBlet Mais une version plus récente du LIBlet ne remplace pas une version existante du LIBlet Les versions plus anciennes peuvent seulement être enlevées s’il n’y a aucun autre MIDlets ou LIBlets dépendant d’eux.

Ainsi, plusieurs versions du même LIBlet peuvent exister sur le dispositif en même temps.

Comme les ressources des dispositif sont limités, on a besoin des mécanismes qui rendre rendent les application mobile plus utilisable par un utilisateur Le déploiement à base des composant est une solution très connue qui est appliquée suivant sur les systèmes répartis.

Elle permet d’installer, d’activer, de mettre à jour et aussi de désinstaller plus facilement les applications mobiles.

Ce chapitre a présenté trois mécanismes qui aident à déploiement à base de composants sur mobiles La section 4.1 présente la techniquePushRegistry) qui permet d’activer des applications mobiles sans déclenchement d’utilisateur Elle peut soutient l’interaction entres les applications MIDlets du dispositif Une réalisation dePushRegistry appliqué pour l’activation des MIDlets va être démontée dans la section 7 Le modèle OSGi présenté dans la section 4.2 est une plate-forme s’adaptant le déploiement dynamiquement les services sur les terminaux Enfin, la section 4.3 décrit le modèle de composants LIBlet pour les applications mobiles, un nouvelle caractéristique du profil MIDP version 3.0.

Cependant, ces modèles ne sont pas encore appliqué suivant à cause du la capacité matérielle limitée des terminaux mobiles Actuellement, il y a un peu des dispositifs mobiles avec la capacité fort qui sont compatibles avec cette plate-forme, et le dossier publié concernant le profil MIDP 3.0 est une préparation écrite Pour mettre en œuvre le déploiement à base de composant sur mobiles, ỗa dộpend du dộveloppement matộrielle.

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

La première partie du rapport a présenté les modèles étudiés sur mobiles concernant le développement, la gestion de jeu multi-joueurs, la gestion des dispositifs et la déploiement des applications Chaque modèle est une plate-forme qui s’adapte à un objectif spécifique et ne peut pas satisfaire toutes les exigences d’un système de gestion de jeu multi-joueur Une bonne idée a germé, on associe ces modèles pour obtenir un système complet qui peut gérer les sessions du jeu, ainsi que stocker et approvisionner les applications, surtout gérer les dispositifs afin de déployer automatiquement les applications.

Ce chapitre propose un modèle pour la gestion des jeux multi-joueurs sur mobiles Ce modèle est la collaboration entre les plate-formes étudiées : le GASP [?], le Client Provisioning [25] et l’OMA DM Il relie le serveur du jeu, le portail de stockage et le serveur OMA DM en décrivant les contextes pour le gestion des dispositif et le déploiement des applications Dans ce système, on se concentre au déploiement des applications.

Modèle général

Le modèle proposé est un système général de déploiement pour les jeux multi-joueurs La figure 5.1 décrit en détail les composants du système Son noyau est le serveur de gestion de dispositif qui se base sur le framework Funambol [15] et le protocole OMA DM Il permet à l’administrateur d’exploiter les terminaux et de mettre les commandes afin de gérer les équi- pements à distance Dans ce cas ci, on s’intéresse à la capacité de déployer les applications du serveur aux clients Les flèches en couleurs dans cette figure représentent des contextes d’exé- cutions variés du système Ces contextes de déploiement sont exposés dans la section 5.3, et le fonctionnement du serveur de gestion sont détaillé dans le chapitre 6

De plus, on intègre avec le serveur de jeu GASP et le Portail de Stockage (tous les deux sont présentés dans le chapitre 1) Les composants des serveurs sont expliqués suivants.

Composants du système

Serveur de jeu

Ce serveur gère des comptes et des sessions de jeu Les utilisateurs peuvent accéder au serveur afin de créer un nouveau compte, créer ó rejoindre une session de jeu, attendre les autres et jouer ensemble Ce système se base sur la plate-forme GASP On ajoute une partie qui permet aux utilisateurs de demander des nouveaux jeux, elle capture les requêtes et les redirige vers le serveur de gestion de dispositifs pour déployer des jeux.

Portail de Stockage

C’est le serveur qui dispose des applications mobiles Il peut non seulement contenir des MIDlets, mais aussi rechercher des MIDlet qui s’adapte aux requêtes Il consiste trois parties : – Dépôt : contient des applications mobiles

– Moteur de recherche et conciliation: détermine les caractéristiques des équipement et recherche les Midlets appropriés dans le dépôt.

– Moteur d’adaptation: détermine les politiques pour accorder des configuration d’équi- pement avec des exigences de Midlet.

Serveur de gestion de dispositif

Ce serveur s’occupe des dispositifs dans le réseau mobile, mais tient leurs informations de configuration, gère des applications sur les équipements en basant sur le protocole OMA DM.

Il se compose de deux couches : la couche de communication et celle de gestion.

Elle s’occupe des connexions du/vers le serveur et consiste de 2 parties : – Manipulation de commandes : capture des requêtes de déploiement qui viennent des agents externes (fournisseurs de service, utilisateurs, système de jeu, etc.).

– Adaptateur de SyncML : traduit des messages reỗus du client pour que le serveur puisse les traiter (suivant un format XML) et inversement, converti des opérations du serveur en format compatible pour la transmission au client Pour cela, il accepte des connexions HTTP, mais d’autres protocoles comme OBEX ou WAP sont envisageables.

Elle est responsable de traiter les requêtes pour créer des opérations de gestion, analyser des connexions et identifier des équipements afin d’effectuer des commandes spécifiées Elle se compose de 5 parties :

– Processeur de gestion: une bibliothèque contenant des procédures qui permet de créer des commandes du framework OMA DM.

– Pipeline des opérations : traduit des opérations de gestion en messages au format XML et les conserve dans une file d’attente Ces opérations sont rangées en ordre FIFO.

– Info de dispositif : une base de donnée contient l’identifiant et les informations de la configuration de chaque équipement.

– Description des Midlets: petit entrepôt des applications mobiles.

– Moteur de gestion: c’est la partie principale qui relie les composants du système Elle sera présentée en détail dans la section suivant.

Contextes de déploiement

Demande de déploiement X sur le mobile M

Le processus de déploiement est démontré par le digramme de séquence dans la figure 5.2Quand la couche de communication reỗoit une demande de dộploiement sur le mobile identifiộ,elle la passe au moteur de gestion Ce moteur accède à la base de données pour obtenir les informations sur le mobile M et l’application X Ensuite, il crée les commandes de déploiement

5.3 Contextes de déploiement 48 en basant sur la bibliothèque de procédures de gestion OMA DM Ces commandes seront enregistrées dans le pipeline d’opérations.

Fig 5.2 – Diagramme de séquence de déploiement d’application sur la mobile

Gestion de dispositif

La session de gestion commencera si le dispositif se connecte au serveur OMA, bien que le serveur puisse envoyer une notification au client La figure 5.3 présente la communication entre le serveur et le terminal mobile afin de exộcuter les opộrations de gestion Quand il reỗoit une connexion du client, la couche la passe au Moteur de gestion Le serveur vérifie les informations du mobile et recherche les opérations appropriées qui ont été spécifiés dans le pipeline des opérations Ces opérations sont envoyées au client en format de messages SyncML.

Fig 5.3 – Diagramme de séquence de gestion de dispositif

Recherche d’une application indisponible

C’est un contexte alternatif qui est décrit par les flèches en rouge dans la figure 5.1, quand il n’y aucune application dans le dépôt de serveur OMA DM qui s’accorde avec la demande de déploiement Il peut lancer une demande avec l’information de configuration de dispositif au portail de stockage qui contient des Midlets disponibles Ce portail recherche dans son dépôt et retourne une adresse URI de l’application la plus compatible au serveur OMA DM Ce serveur peut alors télécharger le Midlet recherché depuis son dépôt, ou bien il peut créer une séquence d’opérations qui commande au dispositif de télécharger ce Midlet Les transactions d’exécution du contexte est décrit dans la figure 5.4 Dans ce cas, toutes les opérations de déploiement

Fig 5.4 – Diagramme de séquence de recherche d’une application indisponible peuvent être effectuées si le mobile connecte au serveur de gestion Le serveur renvoie au mobile des messages SyncML de commande avec une adresse URI et le type d’application Ce mobile peut alors télécharger le Midlet exigé et envoie au serveur la confirmation La session de déploiement est présenté dans la figure 5.5, elle continuera s’il y a encore d’autres opérations dans le pipeline.

Conclusion

Ce chapitre a proposé un modèle pour le système de gestion des jeux mobiles qui se base les plate-formes étudiées Ce modèle se compose des trois parties : le serveur de jeu, serveur de stockage, et le serveur de gestion OMA DM Ce chapitre a décrit en détails les composants de chaque serveur, la relations entre eux et les contextes utilisables du système Le noyau du

Fig 5.5 – Diagramme de séquence de téléchargement d’une application modèle est la gestion des dispositifs qui se base le protocole SyncML Ce modèle s’adapte à toutes les activités non seulement de jeu mais aussi du déploiement.

Une réalisation du serveur OMA DM Comme est décrite dans le chapitre suivant Cette réalisation démontre l’implémentation et la faisabilité du protocole OMA DM Comme chaque composant du système a été implémenté, ce n’est pas difficile de réaliser ce système Cette solution est disponible et on peut l’appliquer au projet de jeu JEMTU pour obtenir un système complet qui s’adapte bien aux exigences de jeu ainsi que du déploiement.

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 ó l’on entre des commandes Ce serveur se base leframework

Funambol et fonctionne sur l’infrastructure J2EE On utilise l’outilSyncML Conformance TestSuite pour le tester.

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.

– Installer, mettre à jour et supprimer les logiciels sur le dispositif.

La figure 6.1 décrit l’architecture du serveur deframework [?] Il est composé de 5 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 ap- plications 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.

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

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.

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

JSPs et EJBs

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 :

1 La gestion externe (par ex : une console, une application) initie un processus ôd’opộration de gestion ằpour un dispositif spộcifiộ.

2 Ce service invoque le service correspondant l’interface d’EJB du serveur.

3 L’EJB fait suivre cet appel au moteur de gestion.

4 Pour créer le processus d’opération, le moteur de gestion choisit et appelle le processeur approprié à la demande dans l’étape 1.

5 Le processus se compose d’opérations atomiques en ordre On enregistre des opérations du processus dans un pipeline d’opérations.

6 Le moteur de gestion établit le message de notification (PKG 0) et indique l’expéditeur pour le pousser sur le téléphone

7 Le dispositif reỗoit le message de notification ; il commence une nouvelle session OMA

DM en envoyant le paquet PKG 1 au serveur.

8 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

9 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 7 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 7 sans recevoir un message de notification.

La réalisation du stage est une application web basée sur l’architecture J2EE Elle se com- pose de pagesJsp qui capturent des commandes de l’administrateur pour :

Base de données du Serveur DM

– 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’EJBsans 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 ó 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

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

Implémentation des opérations

définit et manipule l’information d’état de chaque processus de gestion dans la tabledmstate.

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’).

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 commandeGet/Replacequi 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.

Quand un client commence une session de gestion, le moteur de gestion choisit un proces- seur approprié par le composant de sélecteur Le framework Funambol fournit une interface ManagementProcessorqui définit les méthodes suivantes pour créer un processeur de gestion.

Ceframework 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 commandeExec) 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érieNokia60 présenté dans la section 3.2.3

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 debootstrap.

– 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.jadet 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

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

Ce chapitre a présenté une réalisation du serveur de gestion des dispositifs OMA DM dont l’architecture se base sur leframework Funambol [?] Ce serveur se compose d’un interface web ó 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

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 5 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.

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 profilMIDP 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.

Enregistrement de PushRegistry d’une MIDlet

Pour inscrire un port, on a deux faỗons : l’enregistrement statique et l’enregistrement dy- namique Tous les deux doit dộterminer un port dePush 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’attributMIDlet-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.

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ộ, 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é parmidletClassName L’APIgetClass().getName()obtient le nom de la classe de MIDlet ó 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 ó 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’APIlistConnection().

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 desocket pour l’activation de la classe qui s’appelle className Dans ce cas ó 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.

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 effectué par les

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.

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.

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’attributPushRegistry 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 leframework 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.

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 leframework open sourceFunambol 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 compo- sants 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ésinstalla- tion 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.

[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 ?id4.

[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

[19] A Komsi and M Düsener Mobile service architecture specification version 1.0. http ://www.jcp.org/en/jsr/detail ?id$8, 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'1, 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 ://develo- pers.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 InUBIMOB 05, Grenoble, France,

[26] R SAID Étude du déploiement pour téléphone mobile Master’s thesis, Dept Informa- tique, ENST Bretagne, Brest, France, juin 2006.