38
École Polytechnique de l’Université de Nice Sophia Antipolis Institut National de Recherche en Informatique et Automatique Intégration de la technologie ProActive pour la téléphonie mobile Baptiste DE STEFANO, Nicolas DODELIN Responsable : Mme Françoise BAUDE SI5 - Filière STREAM 28/02/2008

École Polytechnique de l’Université de Nice Sophia

  • Upload
    others

  • View
    2

  • Download
    0

Embed Size (px)

Citation preview

Page 1: École Polytechnique de l’Université de Nice Sophia

École Polytechnique de l’Université de Nice Sophia Antipolis Institut National de Recherche en Informatique et Automatique

Intégration de la

technologie ProActive

pour la téléphonie mobile Baptiste DE STEFANO, Nicolas DODELIN Responsable : Mme Françoise BAUDE

SI5 - Filière STREAM 28/02/2008

Page 2: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

2 Baptiste DE STEFANO, Nicolas DODELIN

Page 3: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

3 Baptiste DE STEFANO, Nicolas DODELIN

Remerciements

Nous voudrions tout d’abord remercier Françoise BAUDE, chercheuse à l’INRIA dans l’équipe

OASIS, qui nous a permis de réaliser un stage très intéressant dans son équipe.

Nous aimerions remercier également Vincent BERGE, PDG de la société Mobile Distillery, qui

est en collaboration avec l’INRIA sur le projet auquel nous participons, pour son accueil dans les

locaux de son entreprise à Marseille.

Nous voudrions remercier Damien PRACA, Ingénieur chez Mobile Distillery, pour son aide et

son intérêt porté à notre projet.

Nos remerciements vont aussi à l’INRIA et plus particulièrement à l’équipe OASIS dirigée par

Denis CAROMEL, pour leur accueil, ainsi qu’à Fabrice HUET, Patricia MALEYRAN pour leur écoute.

Enfin, nous remercions tous les professeurs du département Informatique de l’École

Polytechnique de l’Université de Nice-Sophia Antipolis pour l’enseignement très complet dont nous

avons pu bénéficier.

Page 4: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

4 Baptiste DE STEFANO, Nicolas DODELIN

Sommaire

Introduction ............................................................................................................................................. 5

1. Présentation du projet ........................................................................................................................ 6

2. Description de la technologie ProActive ............................................................................................. 7

2.1. Présentation ................................................................................................................................. 7

2.2. L’objet actif ................................................................................................................................... 7

2.3. La migration .................................................................................................................................. 8

3. Architecture de l’application ............................................................................................................. 10

4. La partie PC / ProActive ..................................................................................................................... 12

4.1. Le Client PC ................................................................................................................................. 12

4.2. Le serveur PC .............................................................................................................................. 14

4.3. Migration ProActive, de Client PC à Client PC ............................................................................ 15

5. La partie Mobile................................................................................................................................. 17

5.1. Logiciel et matériel utilisé .......................................................................................................... 17

5.2. Architecture de la partie Mobile ................................................................................................ 18

5.3. Fonctionnement du Serveur Mobile .......................................................................................... 19

5.4. La migration Mobile - Mobile ..................................................................................................... 22

5.4.1. La connexion ........................................................................................................................ 23

5.4.2. La migration ......................................................................................................................... 24

5.4.3. La mise à jour de la conversation ........................................................................................ 27

6. Interaction ProActive (PC) - Mobile ................................................................................................... 28

6.1. Solution Bluetooth ..................................................................................................................... 28

6.2. Solution retenue : socket ........................................................................................................... 30

7. Interaction Mobile – ProActive (PC) .................................................................................................. 33

8. Problèmes rencontrés ....................................................................................................................... 35

9. Planning du projet ............................................................................................................................. 36

Conclusion ............................................................................................................................................. 37

Références ............................................................................................................................................. 38

Page 5: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

5 Baptiste DE STEFANO, Nicolas DODELIN

Introduction

Notre Projet de Fin d’Études dans le cadre de notre troisième année à l’École Polytechnique

de l’Université de Nice – Sophia Antipolis s’est déroulé à l’INRIA, l’Institut National de Recherche en

Informatique et Automatique, et plus particulièrement au sein de l’équipe OASIS (Active Objects,

Semantics, Internet and Security) de cet établissement.

Bien que nos locaux se trouvent à Sophia Antipolis, nous avons travaillé également en

collaboration avec différentes PMEs telles que Mobile Distillery ou le PACA Mobile Center situées

toutes les deux à Marseille. Ce projet se situe dans le contexte de Mobitools que l’on peut

rapidement définir par : « outils de recherche pour accélérer le développement, le portage, et

l’industrialisation des applications mobiles sur l’ensemble des téléphones ». Ce PFE met

principalement en avant la découverte de la technologie développée par l’équipe OASIS qui s’appelle

ProActive et de sa simulation ou éventuelle intégration dans un environnement JAVA J2ME pour les

téléphones mobiles.

Ce projet survient deux ans après le travail d’un étudiant ayant déjà essayé l’intégration de

ProActive sur un mobile. Durant ces deux années, certains changements sont apparus dans le

domaine de la téléphonie mobile et notre travail consiste à travailler sur ces avancés technologiques.

Dans un premier temps, nous vous présenterons la technologie ProActive développée par

l’INRIA.

Ensuite, nous vous montrerons en quoi a consisté réellement notre projet en vous expliquant

pourquoi nous avons choisi de développer une application de type Chat et quelles sont les

technologies que nous avons utilisées.

Dans une troisième partie, nous verrons dans le détail le fonctionnement de notre Chat avec

l’explication des protocoles que nous avons utilisés pour échanger des messages et migrer.

Enfin, nous vous expliquerons le déroulement du projet avec un planning détaillé de celui-ci

et les différents problèmes que nous avons rencontrés.

Page 6: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

6 Baptiste DE STEFANO, Nicolas DODELIN

1. Présentation du projet

Comme expliqué dans notre introduction, notre projet s’inscrit à la suite d’un stage d’un

étudiant deux ans auparavant. Son but était de tester et essayer d’intégrer la technologie ProActive

de l’INRIA, partiellement ou entièrement, dans les téléphones portables. Ce projet avait abouti à la

création d’un jeu qui se jouait au tour par tour à la manière d’un jeu d’échec avec l’envoi de SMS

pour avertir des événements qui ont lieu. Notre projet doit reprendre ces recherches afin de voir si

avec les technologies actuelles, il est possible d’intégrer ProActive dans les téléphones mobiles et

sinon quelles sont les nouvelles possibilités offertes pour simuler un fonctionnement proche de celui-

ci. Après de courtes recherches, il s’est vite avéré que les technologies des machines virtuelles JAVA

des téléphones mobiles n’ont pas réellement évolué durant ces deux dernières années.

En revanche, les capacités des mobiles et des réseaux téléphoniques, ont énormément

évolué en deux ans. Aujourd’hui, de plus en plus de téléphones portables sont équipés de la

technologie Wi-Fi et les opérateurs téléphoniques proposent des forfaits permettant un accès illimité

au réseau 3G et donc Internet.

Notre idée de base est d’avoir une application qui permet de changer de support d’exécution

et donc d’être capable de passer d’une machine virtuelle JAVA J2ME à une machine virtuelle

J2SE/ProActive. L’application nécessite aussi de rester connecter le temps de son utilisation. Ne

contenant pas la technologie ProActive, l’application doit permettre d’échanger des données avec

des objets actifs. Il faut donc choisir selon les capacités des téléphones mobiles du moment les types

de protocoles de communication pouvant être utilisés.

Cette application doit être capable de migrer vers un ordinateur ou un téléphone mobile de

manière totalement transparente pour tous les utilisateurs. Durant cette migration, des données

peuvent être échangées, il faut qu’il y ait une totale intégrité des données pour ne pas perturber

l’exécution de l’application.

C’est pourquoi nous avons décidé de mettre en place une application de Chat. Ce type

d’application intègre entièrement les spécifications décrites ci-dessus. Nous devons rester en

permanence connectés à un serveur à qui nous enverrons et qui nous transmettra des messages.

Lors d’une migration, d’autres utilisateurs peuvent continuer à parler car la migration doit leur être

totalement transparente, c’est pour cela qu’aucun des messages envoyés durant la migration ne doit

être égarés.

Page 7: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

7 Baptiste DE STEFANO, Nicolas DODELIN

2. Description de la technologie ProActive

2.1. Présentation

Pour réaliser notre stage nous devions travailler essentiellement sur la technologie ProActive

de l’INRIA.

ProActive est un framework : un ensemble de bibliothèques, d'outils et de conventions

permettant le développement d'applications. Ses librairies écrites en JAVA (sous licence LGPL)

permettent le calcul parallèle, distribué et concurrent sur les grilles. Il est composé d’un ensemble

réduit de primitives assurant mobilité et sécurité. Ces primitives constituent une API permettant de

simplifier la programmation distribuée sur un réseau local d’ordinateurs de type LAN ou WAN (Local

/ Wireless Area Network).

Sur ces réseaux, ProActive utilise par défaut une technologie « à la RMI » de J2SE (Remote

Method Invocation). RMI permet d’appeler des méthodes présentes sur des objets JAVA créés sur

une autre machine virtuelle et ne se trouvant pas sur la même machine que l’objet appelant.

ProActive reprend donc cette philosophie en ajoutant de nouvelles spécifications telles que la

possibilité pour un objet de pouvoir migrer sur une autre machine virtuelle.

Ces objets dans ProActive sont nommés des objets actifs.

2.2. L’objet actif

Un objet actif est composé d’une instance d’un objet standard JAVA et d’un body.

Le body est responsable de la réception des appels sur l’objet actif qui seront enregistrés

dans une queue d’exécution appelés « called requests ». Il va exécuter ces appels dans un ordre

spécifié par une politique de synchronisation. Par défaut, la politique utilisée est la FIFO (First In First

Out) ce qui signifient que la première requête arrivée est la première exécutée. Comme la gestion de

ce body est effectuée de manière transparente par ProActive, un objet actif ressemble exactement à

un objet JAVA standard pour la vision de l’utilisateur.

Du côté de l’appelant de méthode, l’objet actif est représenté par un stub et un proxy qui

vont permettre de transformer les appels sous forme de requêtes d’objets, requests objects.

Page 8: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

8 Baptiste DE STEFANO, Nicolas DODELIN

La communication entre deux objets actifs dans deux runtimes différ

d’un nœud pour chaque partie comme le montre la figure suivante

2.3. La migration

Comme écrit précédemment, un objet actif a la possibilité de migrer d’un environnement

JAVA à un autre. Nous allons vous expliquer le fonctionnement d’une migration.

Avant toute chose pour pouvoir migrer il faut que l’ordinateur de destination soit en attente

de réception d’une migration. Ceci est possible par la création d’un nœud

voici comment se présente le déroulement dans le cas simple

L’ordinateur source crée un objet actif. Cet objet actif devra hériter de

(pour qu’il puisse être déplacé) et contiendra une méthode

appelée chaque fois qu’un objet actif est démarré et donc chaque fois qu’il migrera.

les attributs de notre objet actif qui sont

• La création d’un nœud

• L’enregistrement sur la machi

un éventuel appel à distance

• La création de la fenêtre

• Paramétrer la stratégie de migration

La stratégie de migration permet principalement de définir deux méthodes qui sont

onDeparture() et onArrival()

la technologie ProActive pour la téléphonie mobile

Baptiste DE STEFANO, Nicolas DODELIN

La communication entre deux objets actifs dans deux runtimes différents s’effectue

d’un nœud pour chaque partie comme le montre la figure suivante :

précédemment, un objet actif a la possibilité de migrer d’un environnement

expliquer le fonctionnement d’une migration.

Avant toute chose pour pouvoir migrer il faut que l’ordinateur de destination soit en attente

de réception d’une migration. Ceci est possible par la création d’un nœud par ce dernier.

présente le déroulement dans le cas simple d’une migration d’une fenêtre.

L’ordinateur source crée un objet actif. Cet objet actif devra hériter de l’interface Serializable

(pour qu’il puisse être déplacé) et contiendra une méthode RunActivity(). Cette m

appelée chaque fois qu’un objet actif est démarré et donc chaque fois qu’il migrera. Nous initialisons

les attributs de notre objet actif qui sont :

L’enregistrement sur la machine de l’objet actif afin qu’une référence soit récupérable po

un éventuel appel à distance

étrer la stratégie de migration

a stratégie de migration permet principalement de définir deux méthodes qui sont

(). OnDeparture() s’exécute avant que l’objet actif ne migre.

la technologie ProActive pour la téléphonie mobile

par la création

précédemment, un objet actif a la possibilité de migrer d’un environnement

Avant toute chose pour pouvoir migrer il faut que l’ordinateur de destination soit en attente

par ce dernier. Ensuite

d’une migration d’une fenêtre.

Serializable

. Cette méthode sera

Nous initialisons

it récupérable pour

a stratégie de migration permet principalement de définir deux méthodes qui sont

s’exécute avant que l’objet actif ne migre.

Page 9: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

9 Baptiste DE STEFANO, Nicolas DODELIN

Dans notre exemple il nous servira pour détruire la fenêtre et se désinscrire de la machine. Une

interface graphique n’étant pas un élément sérialisable, il est donc nécessaire dans cette méthode de

sauvegarder les données relatives à la fenêtre. onArrival() est, quant à elle, appelée sur

l’ordinateur destinataire après que l’objet actif ait migré. Donc ici, nous recréerons notre fenêtre et

nous nous enregistrerons sur la nouvelle machine.

Une migration s’effectue à l’aide de la méthode migrateTo() en indiquant par exemple

l’adresse du nœud que nous avons créé au préalable sur l’ordinateur destinataire. Il existe cependant

plusieurs politiques de migration disponibles et configurables dans le constructeur de l’objet actif qui

sont :

• La migration par forward.

• La migration par serveur de localisation.

Dans cette première migration, il nous faut prendre l’exemple de deux objets actifs que nous

nommerons (A) et (B) situé sur deux machines différentes et donc deux machines virtuelles JAVA

différentes.

(A) décide de migrer et d’aller sur la machine de (B). Après la migration (B) essaie de

communiquer avec (A) mais ce dernier a changé de nœud et s’est inscrit auprès d’un objet particulier

nommé Forwarder.

(B) va essayer de communiquer avec (A) mais comme (A) a migré, son appel est récupéré par

le Forwarder et celui-ci va lui indiquer où se trouve dorénavant (A). Ils pourront ainsi continuer à

communiquer.

Lors d’une migration par serveur de localisation, il n’y a qu’un seul objet actif qui s’occupe de

savoir où se trouve les autres objets actifs après leurs migrations.

Dans notre exemple (A) migre et prévient le serveur de localisation en lui indiquant sa

nouvelle destination. (B) essaie de communiquer avec (A) et n’y arrive pas. Il va donc demander au

serveur de localisation s’il peut lui indiquer où se trouve maintenant (A). Le serveur lui donne la

nouvelle destination et (B) se met à jour pour communiquer avec (A) en ne passant plus par le

serveur de localisation.

Page 10: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

10 Baptiste DE STEFANO, Nicolas DODELIN

3. Architecture de l’application

Notre application contient deux types de terminaux qui sont les ordinateurs et les téléphones

mobiles. Le traitement des informations entre ces deux

ne disposant que de J2ME, nous nous retrouvons limités quant aux différents protocoles que nous

pouvons utiliser et RMI ne fait pas partie de cette liste de protocoles. En effet, nous avions trois

protocoles disponibles sur MIDP 2.0

• Connexion http

• Connexion socket (TCP/IP)

• Connexion de datagramme (UDP/IP)

Bien que ProActive permette de communiquer en http par l’utilisation de Web Services,

technologie permettant à des applications de dialoguer à distance via

la philosophie du Chat qui consiste à être connecté

personne ou le serveur. C’est pourquoi nous avons décidé de communiquer en TCP entre les

téléphones mobiles et nos serveurs.

Nous avons donc bien deux parties di

• Un Serveur Mobile qui s’occupera de la gestion des clients connectés à

d’un téléphone portable

• Un serveur PC qui s’occupera des clients connectés

La figure suivante montre l’architecture que nous avons mise en place

la technologie ProActive pour la téléphonie mobile

Baptiste DE STEFANO, Nicolas DODELIN

Architecture de l’application

Notre application contient deux types de terminaux qui sont les ordinateurs et les téléphones

mobiles. Le traitement des informations entre ces deux parties est différent. En effet, le

, nous nous retrouvons limités quant aux différents protocoles que nous

pouvons utiliser et RMI ne fait pas partie de cette liste de protocoles. En effet, nous avions trois

sur MIDP 2.0 :

datagramme (UDP/IP)

Bien que ProActive permette de communiquer en http par l’utilisation de Web Services,

technologie permettant à des applications de dialoguer à distance via Internet, nous avons privilégiés

la philosophie du Chat qui consiste à être connecté durant tout le temps de la discussion avec la

personne ou le serveur. C’est pourquoi nous avons décidé de communiquer en TCP entre les

téléphones mobiles et nos serveurs.

Nous avons donc bien deux parties distinctes dans notre application :

obile qui s’occupera de la gestion des clients connectés à

d’un téléphone portable

Un serveur PC qui s’occupera des clients connectés depuis leurs ordinateur

figure suivante montre l’architecture que nous avons mise en place :

la technologie ProActive pour la téléphonie mobile

Notre application contient deux types de terminaux qui sont les ordinateurs et les téléphones

différent. En effet, le téléphone

, nous nous retrouvons limités quant aux différents protocoles que nous

pouvons utiliser et RMI ne fait pas partie de cette liste de protocoles. En effet, nous avions trois

Bien que ProActive permette de communiquer en http par l’utilisation de Web Services, une

nous avons privilégiés

le temps de la discussion avec la

personne ou le serveur. C’est pourquoi nous avons décidé de communiquer en TCP entre les

obile qui s’occupera de la gestion des clients connectés à l’aide

ordinateurs

Page 11: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

11 Baptiste DE STEFANO, Nicolas DODELIN

Comme nous pouvons le voir sur la figure ci-dessus, les téléphones mobiles n’échangent pas

de données directement avec le Serveur Mobile. En effet, pour effectuer une connexion TCP multi-

utilisateurs, il est nécessaire d’utiliser des Threads pour ne pas bloquer le Serveur Mobile. C’est

pourquoi ce dernier contient un Thread que nous avons appelé ServerMobileThread qui va être

en attente sur les ports de communication. Une fois la connexion établie, il va créer un objet

ClientMobile et c’est avec celui-ci que le Serveur Mobile échangera principalement des

informations.

Page 12: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

12 Baptiste DE STEFANO, Nicolas DODELIN

4. La partie PC / ProActive

Dans cette partie, nous allons vous détailler plus précisément notre architecture, du

c'est-à-dire la partie qui utilise la technologie ProActive.

4.1. Le Client PC

Le Client PC est un objet actif.

Serveur PC par l’adresse IP qui lui est passé

un premier temps récupérer la référence de

appeler les méthodes de celui-ci à distance. Ensuite, il va s’en

PC afin qu’il le rajoute dans son groupe de diffusion (cf

certains de ces attributs comme nous l’avons vu dans la partie de la création d’un objet actif

et enfin il affiche son interface graphique.

La figure ci-dessous montre

connectés et au centre la conversation.

de migration et en bas la zone de saisie de texte.

la technologie ProActive pour la téléphonie mobile

Baptiste DE STEFANO, Nicolas DODELIN

4. La partie PC / ProActive

Dans cette partie, nous allons vous détailler plus précisément notre architecture, du

dire la partie qui utilise la technologie ProActive.

PC est un objet actif. Il est identifié par un nom d’utilisateur et sait localiser

qui lui est passée en paramètre. Pour se connecter, un Client PC va dans

la référence de l’objet actif correspondant au Serveur PC. Ainsi il pourra

à distance. Ensuite, il va s’enregistrer à son tour auprès du S

roupe de diffusion (cf : 4.2. Serveur PC, page 14). Il met en place

certains de ces attributs comme nous l’avons vu dans la partie de la création d’un objet actif

son interface graphique.

ontre la fenêtre du Client PC. A droite est présente la liste des

au centre la conversation. En haut de la fenêtre un champ permet d’indiquer l’adresse

de migration et en bas la zone de saisie de texte.

la technologie ProActive pour la téléphonie mobile

Dans cette partie, nous allons vous détailler plus précisément notre architecture, du côté PC,

et sait localiser l'objet

lient PC va dans

l’objet actif correspondant au Serveur PC. Ainsi il pourra

registrer à son tour auprès du Serveur

). Il met en place

certains de ces attributs comme nous l’avons vu dans la partie de la création d’un objet actif (page 7)

est présente la liste des

indiquer l’adresse

Page 13: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

13 Baptiste DE STEFANO, Nicolas DODELIN

Pour migrer, bien que précédemment nous indiquions qu’il fallait entrer l’adresse entière

d’un nœud, ici l’utilisateur a juste besoin d’indiquer l’adresse IP de la machine à atteindre. Une

méthode de ProActive nommée listActive() permet de lister tous les nœuds présents sur une

ordinateur de bureau (local ou distant). Nous rappelons aussi que l’ordinateur destinataire doit avoir

au préalable ouvert un nœud. Le Client PC testera alors les différents nœuds qu’il détectera et

migrera vers la machine concernée en suivant les protocoles adéquats selon s’il veut migrer vers un

autre ordinateur ou vers un téléphone mobile.

L’utilisateur n’aura pas à spécifier vers quel terminal il décide de migrer. En effet, dans la

méthode migrateTo() il va d’abord tester si c’est peut-être un téléphone qui est le destinataire de

la migration en essayant d’ouvrir une socket sur l’adresse IP passée en paramètre et sur le port

approprié. Si cette demande échoue, on va donc essayer de chercher si des nœuds sont prêts à

accepter une migration sur la machine distante qui devrait donc être un ordinateur.

Page 14: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

14 Baptiste DE STEFANO, Nicolas DODELIN

4.2. Le serveur PC

Le serveur PC s’occupe de tous les clients utilisant un ordinateur comme terminal. C’est un

objet actif et en possède donc toutes les caractéristiques comme par exemple une queue

d’exécution.

Pour gérer tous ses clients, il utilise une classe de ProActive qui s’appelle DiffusionGroup.

Un groupe de diffusion est du type des objets actifs que l’on désire lister. Cela nous permet d’appeler

très aisément une méthode à distance pour tout un groupe d’objets actifs. Cela est pratique dans le

cas de l’utilisation de notre Chat car nous effectuons que des opérations globales. Ainsi lorsque le

Serveur PC doit transmettre un message, il appelle simplement la méthode receptMessage() du

groupe de diffusion qui s’occupera en arrière plan d’appeler la méthode receptMessage() de

chaque client de la liste.

Le serveur PC réagit à chaque appel de méthode qu’il reçoit. Deux acteurs peuvent effectuer

ces appels :

• Le Serveur Mobile qui va avertir le Serveur PC de tous les événements qui se

produisent avec les Clients Mobiles. Ainsi lorsqu’un nouveau message est arrivé

ou qu’un Client Mobile vient de se connecter ou de se déconnecter, le Serveur

Mobile avertit le Serveur PC qui va diffuser l’information à l’ensemble de ses

Clients PCs.

• Les Clients PCs qui vont transmettre aussi des événements au Serveur PC comme

l’envoi de messages, une connexion ou une déconnexion. Le Serveur PC mettra à

jour comme ci-dessus ses Clients PCs mais avertira également le Serveur Mobile

de la présence d’un nouvel événement.

Prenons comme exemple la demande de connexion d’un nouveau client. Le Serveur PC

l’ajoute à son groupe de diffusion et met à jour les listes d’utilisateurs connectés pour ses propres

Clients PCs et indique au Serveur Mobile qu’un nouveau client est arrivé pour lui permettre de

mettre à jour ses clients. Entre ces deux serveurs nous sommes certains qu’il n’y aura pas de pertes

de données. Même si un des deux serveurs est occupé à traiter un événement, la queue d’exécution

sera remplie et de ce fait nous avons une garantie que plus tard notre événement sera bien traité

tout en conservant l’ordre dans lequel il est arrivé.

Page 15: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

15 Baptiste DE STEFANO, Nicolas DODELIN

4.3. Migration ProActive, de Client PC à Client PC

Pour gérer les migrations de PC à PC, nous avons opté pour une migration ProActive avec

serveur de localisation.

L’option de migration avec Forward ne correspond pas à la philosophie de notre Chat. En

effet, nous rappelons que le but de cette application est de permettre à un utilisateur, lorsque celui-

ci en a besoin, de pouvoir changer de terminal pour parler avec les autres utilisateurs en rendant

tout cela transparent… Imaginons que l’utilisateur ait effectué sa connexion sur un PC et qu’il décide

de migrer sur un autre ordinateur. Il va donc migrer l’application vers ce dernier et probablement

éteindre le premier. Or si l’ordinateur est éteint, il ne pourra pas posséder l’objet forwarder qui

indiquera au Serveur PC où se trouve maintenant l’utilisateur.

C’est pourquoi à l’aide du serveur de localisation, ce sera lors de la migration que le Client PC

indiquera sa nouvelle destination et ainsi permettra au Serveur PC de savoir où il se trouve

dorénavant.

Nous allons maintenant détailler comment se déroule la migration de Client PC à Client PC.

Le serveur de localisation est créé pendant le lancement du Serveur PC. Pour permettre aux

Clients PCs de retrouver facilement le serveur, nous avons défini son adresse qui est :

rmi://IP_du_serveur/LocationServer. L’IP du serveur devra être connue de la part de

chaque utilisateur.

Lorsqu’un client migre, il prévient le serveur de localisation qu’il se déplace. Ce dernier se

met à jour. Le Serveur PC essaie de communiquer avec ce client, n’y arrive pas et demande au

serveur de localisation s’il a une information. Si le Serveur PC n’arrive toujours pas à communiquer

avec son client alors que le serveur de localisation lui a donné la nouvelle information, il se met en

attente et continue de demander au serveur de localisation au cas où par exemple le client ne serait

pas une nouvelle fois en train de migrer.

Si le temps de la migration est lent, tous les messages transitant par le serveur de localisation

ne seront pas tout de suite envoyés aux clients ou au serveur mobile. En effet, comme le Serveur PC

est lui aussi un objet actif, tous les événements nécessitant de passer par lui, s’ils ne sont pas traités

tout de suite, sont stockés dans une queue d’exécution donc nous pouvons certifier que les

informations lors d’une migration de Client PC à Client PC ne seront pas perdues.

Page 16: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

16 Baptiste DE STEFANO, Nicolas DODELIN

Par contre, il peut arriver qu’un Client PC se déconnecte de manière « brutale » sans avertir

ni le Serveur PC ni le serveur de localisation d’une déconnexion ou d’une migration.

Le problème ici est que le Serveur PC effectue un appel de méthode à distance par

l’intermédiaire de son groupe de diffusion. Si un client ne répond pas, le Serveur PC se met en

attente. Si l’échec de la communication persiste une exception est levée en indiquant la référence du

client introuvable dans le groupe de diffusion et de ce fait l’événement ne sera pas envoyé au client.

Donc dans ce souci de non pertes d’informations, le Serveur PC déconnectera et retirera de

son groupe de diffusion le client si celui reste injoignable après toutes les requêtes qu’aura

effectuées le serveur.

Lorsqu’un Client PC décide de migrer, il doit au préalable sauvegarder toutes les informations

que contient son interface graphique telles que le dialogue et la liste des utilisateurs connectés du

fait qu’une migration ne permet pas de mémoriser l’état d’une interface graphique. C’est pourquoi

nous détruisons l’interface graphique sur l’ordinateur source pour la recréer sur l’ordinateur

destinataire.

Page 17: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

17 Baptiste DE STEFANO, Nicolas DODELIN

5. La partie Mobile

5.1. Logiciel et matériel utilisé

Les mobiles utilisant la technologie JAVA fonctionnent sur la plateforme Java Micro Edition

(J2ME) qui est la micro édition de J2SE.

Java Micro Edition (J2ME) est le framework Java spécialisé dans les applications mobiles.

Nous avons utilisé le Wireless ToolKit de Sun pour le développement d’applications basées sur J2ME.

J2ME se divise en deux APIs (Application Programming Interface ou interface de

programmation) différentes utilisées selon la puissance du terminal. Le premier profil utilise la

configuration CDC (Connected Device Configuration) qui utilise une machine virtuelle optimisée

implémentant l’ensemble des fonctionnalités de la JVM (Java Virtual Machine). Ce profil est utilisé

par les terminaux puissants comme les PDAs et PocketPCs. Le second profil est MIDP (Mobile

Information Device Profile). Celui-ci utilise la configuration CDLC, une version limitée de CDC. La

machine virtuelle utilisée est la KVM (Kilobyte Virtual Machine) qui n’implémente pas l’ensemble des

fonctionnalités de la JVM. Ce profil est fait pour les terminaux moins puissants comme l’ensemble

des téléphones portables.

La KVM utilisée sur les mobiles ne permet pas d’utiliser la technologie RMI et le mécanisme

de réflexion indispensable à ProActive pour fonctionner.

Étant dépendant des technologies disponibles sur les mobiles, nous avons donc développé un

protocole de « pseudo-migration ». L’essentiel est d’émuler une migration d’un mobile vers un autre

ou vers un objet ProActive sans aucunes pertes de messages.

Nous avons testé le fonctionnement de notre application avec l’émulateur du Wireless

ToolKit de Sun mais également en compilant les packages de notre application que nous déployions

ensuite sur le mobile.

Afin de réaliser des tests sur notre application nous avions besoin d’un mobile disposant du

Wi-Fi et d’un maximum de connectivité. Mobile Distillery travaille en collaboration avec le PACA

Mobile Center situé sur Marseille, Paris et également sur Sophia Antipolis. Le PACA Mobile Center

Page 18: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

18 Baptiste DE STEFANO, Nicolas DODELIN

met à disposition des professionnels quasiment tous les téléphones mobiles du marché. Nous avons

donc bénéficié d’un prêt de mobile, le HTC S620.

Ce mobile de type SmartPhone est équipé de

Mobile, mais surtout dispose des technologies Wi

Nous avons pu travailler en réseau Wi

portables et le mobile HTC S620 afin de tester certains points de

notre application.

5.2. Architecture de la partie Mobile

L’architecture de la partie mobile est similaire à l’architecture de la partie

Nous disposons d’un Serveur Mobile

objet actif qui gère l’ensemble des connexions avec

Utilisant la technologie ProActive le serveur gère une file de message

requêtes à transmettre aux mobiles.

Chaque mobile est connect

diffuser à l’ensemble des Clients PC

La connexion entre le Serveur Mobile et les cl

permet la communication entre différents processus à travers un réseau TCP/IP.

Le Wireless ToolKit de Sun ainsi que le HTC S620 permettent de gérer les connexions à

travers le réseau à l’aide du Wi-Fi, c’est pour cela que nous avons

sockets.

la technologie ProActive pour la téléphonie mobile

Baptiste DE STEFANO, Nicolas DODELIN

met à disposition des professionnels quasiment tous les téléphones mobiles du marché. Nous avons

donc bénéficié d’un prêt de mobile, le HTC S620.

Ce mobile de type SmartPhone est équipé de Microsoft Windows

Mobile, mais surtout dispose des technologies Wi-Fi et Bluetooth.

Nous avons pu travailler en réseau Wi-Fi entre nos ordinateurs

portables et le mobile HTC S620 afin de tester certains points de

la partie Mobile

L’architecture de la partie mobile est similaire à l’architecture de la partie PC ProActive.

erveur Mobile qui sert à toutes les transmissions mobiles.

objet actif qui gère l’ensemble des connexions avec les Clients Mobiles.

Utilisant la technologie ProActive le serveur gère une file de messages correspondant aux

requêtes à transmettre aux mobiles.

Chaque mobile est connecté à ce serveur qui transmet au Serveur PC les informations à

PCs connectés.

erveur Mobile et les clients est réalisée à l’aide de socket. Une s

permet la communication entre différents processus à travers un réseau TCP/IP.

it de Sun ainsi que le HTC S620 permettent de gérer les connexions à

Fi, c’est pour cela que nous avons choisi de communiquer via des

la technologie ProActive pour la téléphonie mobile

met à disposition des professionnels quasiment tous les téléphones mobiles du marché. Nous avons

ProActive.

sert à toutes les transmissions mobiles. C’est un

correspondant aux

erveur PC les informations à

ients est réalisée à l’aide de socket. Une socket

it de Sun ainsi que le HTC S620 permettent de gérer les connexions à

choisi de communiquer via des

Page 19: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

19 Baptiste DE STEFANO, Nicolas DODELIN

Nous allons voir comment se comporte le Serveur Mobile ainsi

travers des exemples.

5.3. Fonctionnement du S

L’objectif est de montrer qu’un objet actif peut communiquer et migr

mobile, de ce fait l’interface de notre prototype est relativement

Pour commencer nous allons voir comment s’

le Serveur Mobile.

Ce schéma nous montre les différentes étapes nécessai

la technologie ProActive pour la téléphonie mobile

Baptiste DE STEFANO, Nicolas DODELIN

ns voir comment se comporte le Serveur Mobile ainsi que les Clients M

Fonctionnement du Serveur Mobile

montrer qu’un objet actif peut communiquer et migrer avec et vers un objet

’interface de notre prototype est relativement basique.

Pour commencer nous allons voir comment s’effectue la connexion entre un Client Mobile et

Ce schéma nous montre les différentes étapes nécessaires à la connexion d’un Client M

la technologie ProActive pour la téléphonie mobile

que les Clients Mobiles à

er avec et vers un objet

effectue la connexion entre un Client Mobile et

res à la connexion d’un Client Mobile.

Page 20: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

20 Baptiste DE STEFANO, Nicolas DODELIN

Lorsque l’utilisateur lance la MIDlet, il lui est demandé de

saisir un nom d’utilisateur afin d’être reconnu dans la

conversation.

(1) Sur la page d’accueil nous devons saisir un nom

d’utilisateur pour se connecter au serveur. Deux autres choix sont

disponibles pour la migration qui seront expliqués plus tard.

Ici nous saisissons le nom d’utilisateur

Le Serveur Mobile gère plusieurs Threads qui lui permettent d’effectuer plusieurs tâches

simultanément. Le serveur devant toujours être en attente de client, celui

via les sockets des clients.

(2) Une fois la connexion effectuée, le mobile envoie de manière transparente son nom

d’utilisateur. Lorsque le serveur est en possession des s

d’utilisateur, un objet Client Mobile est créé

se connecte via son ordinateur. A travers cet objet, le S

nécessaires à la communication.

(4) Comme le Serveur Mobile stock

enregistré. Le serveur envoie alors sous forme de message la liste des connectés à ce client.

Mobile met donc sa liste des connectés à jour.

(5) Enfin pour terminer la connexion d’un client, le se

sockets de chaque client pour les avertir de l’arrivée d’un nouveau client. Le nom d’utilisateur

nouvel arrivant est alors envoyé à tous les clients.

la technologie ProActive pour la téléphonie mobile

Baptiste DE STEFANO, Nicolas DODELIN

lance la MIDlet, il lui est demandé de

saisir un nom d’utilisateur afin d’être reconnu dans la

Sur la page d’accueil nous devons saisir un nom

d’utilisateur pour se connecter au serveur. Deux autres choix sont

ion qui seront expliqués plus tard.

d’utilisateur : Exemple.

erveur Mobile gère plusieurs Threads qui lui permettent d’effectuer plusieurs tâches

Le serveur devant toujours être en attente de client, celui-ci attend les connexions

Une fois la connexion effectuée, le mobile envoie de manière transparente son nom

serveur est en possession des sockets pour la communication et du nom

objet Client Mobile est créé (3) au même titre qu’un objet Client PC lorsqu’un Client

. A travers cet objet, le Serveur Mobile obtient les informations

erveur Mobile stocke la liste des Clients Mobiles connectés, cet objet est

enregistré. Le serveur envoie alors sous forme de message la liste des connectés à ce client.

Mobile met donc sa liste des connectés à jour.

Enfin pour terminer la connexion d’un client, le serveur envoie un message à travers les

sockets de chaque client pour les avertir de l’arrivée d’un nouveau client. Le nom d’utilisateur

envoyé à tous les clients.

la technologie ProActive pour la téléphonie mobile

erveur Mobile gère plusieurs Threads qui lui permettent d’effectuer plusieurs tâches

attend les connexions

Une fois la connexion effectuée, le mobile envoie de manière transparente son nom

ockets pour la communication et du nom

au même titre qu’un objet Client PC lorsqu’un Client

erveur Mobile obtient les informations

connectés, cet objet est

enregistré. Le serveur envoie alors sous forme de message la liste des connectés à ce client. Le

un message à travers les

sockets de chaque client pour les avertir de l’arrivée d’un nouveau client. Le nom d’utilisateur du

Page 21: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

21 Baptiste DE STEFANO, Nicolas DODELIN

Une fois connecté, chaque utilisateur émet et reçoit des messa

Une fois le texte saisi, l’utilis

Le Serveur Mobile interprète le message car il peut y avoir plusieurs types de message. Un

message pour avertir d’une déconnexion, prévenir d’une connexion ou tout simplement un

texte. Dans ce cas le Serveur Mobile se contente de rediffuser ce message qui sera interprété par

chaque client mobile.

Les messages sont des chaînes de caractères divisées en trois parties

• La commande, par exemple : “MSG”

• Un premier argument, par exemple : “Exemple”

• Un second argument, par exemple : “Mon premier message”

Ce message indique qu’il est bien de type texte

de l’utilisateur qui l’envoie est Exemple et que le texte à afficher est

la technologie ProActive pour la téléphonie mobile

Baptiste DE STEFANO, Nicolas DODELIN

Une fois connecté, chaque utilisateur émet et reçoit des messages sur le Chat.

A gauche l’utilisateur

« Exemple » est connecté et

peut désormais participer à

la discussion. A droite le

message d’information reçu

par tous les Clients Mobiles

connectés.

Une fois le texte saisi, l’utilisateur envoi le message vers le Serveur Mobile à travers la

erveur Mobile interprète le message car il peut y avoir plusieurs types de message. Un

message pour avertir d’une déconnexion, prévenir d’une connexion ou tout simplement un

rveur Mobile se contente de rediffuser ce message qui sera interprété par

Les messages sont des chaînes de caractères divisées en trois parties :

La commande, par exemple : “MSG”

Un premier argument, par exemple : “Exemple”

second argument, par exemple : “Mon premier message”

st bien de type texte, donc à ajouter à la conversation, q

est Exemple et que le texte à afficher est : « Mon premier message

la technologie ProActive pour la téléphonie mobile

erveur Mobile à travers la socket.

erveur Mobile interprète le message car il peut y avoir plusieurs types de message. Un

message pour avertir d’une déconnexion, prévenir d’une connexion ou tout simplement un message

rveur Mobile se contente de rediffuser ce message qui sera interprété par

à ajouter à la conversation, que le nom

Mon premier message ».

Page 22: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

22 Baptiste DE STEFANO, Nicolas DODELIN

L’envoi du message (à gauche) est retransmis directement à l’ensemble

connectés au Serveur Mobile (à droite)

Bien sûr, toutes les informations envoyées aux Clients M

Serveur PC qui les diffusera aux utilisateurs connectés à partir de PC.

5.4. La migration Mobile

Il existe de nombreuses applications de Chat sur le marché, mais aucune ne permet à un utilisateur de migrer alors qu’il est connecté. Au contraire, s’il veut changer de support d’exécution, il doit interrompre la discussion, se reconnecter ensuite, et donProActive, nous pouvons migrer. Notre problème est que ProActive ne tourne pas sur J2ME. Nous avons donc cherché à imiter, reproduire, un mécanisme de migration Mobile que pourrait offrir une version de ProActive si elle pouvait exister sur J2ME.

Nous souhaitons rendre la tâche des serveurs plus ciblée sur la gestion des connectés et la transmission des informations et afin décidé que l’ensemble de la conversation serait transmis directement entre les mobiles. La migration devant être transparente au maximum pour les autres utilisateurs ainsi que pour le serveur.

la technologie ProActive pour la téléphonie mobile

Baptiste DE STEFANO, Nicolas DODELIN

L’envoi du message (à gauche) est retransmis directement à l’ensemble des Clients M

(à droite).

les informations envoyées aux Clients Mobiles sont également envoyées au

diffusera aux utilisateurs connectés à partir de PC.

La migration Mobile - Mobile

Il existe de nombreuses applications de Chat sur le marché, mais aucune ne permet à un utilisateur de migrer alors qu’il est connecté. Au contraire, s’il veut changer de support d’exécution, il doit interrompre la discussion, se reconnecter ensuite, et donc perdre la conversation. Or, avec

. Notre problème est que ProActive ne tourne pas sur J2ME. Nous avons donc cherché à imiter, reproduire, un mécanisme de migration Mobile – Mobile proche de ce

de ProActive si elle pouvait exister sur J2ME.

Nous souhaitons rendre la tâche des serveurs plus ciblée sur la gestion des connectés et la transmission des informations et afin de se rapprocher du fonctionnement de ProActive, nous avons

emble de la conversation serait transmis directement entre les mobiles. La migration devant être transparente au maximum pour les autres utilisateurs ainsi que pour le serveur.

la technologie ProActive pour la téléphonie mobile

Clients Mobiles

les sont également envoyées au

Il existe de nombreuses applications de Chat sur le marché, mais aucune ne permet à un utilisateur de migrer alors qu’il est connecté. Au contraire, s’il veut changer de support d’exécution, il

c perdre la conversation. Or, avec . Notre problème est que ProActive ne tourne pas sur J2ME. Nous

Mobile proche de ce

Nous souhaitons rendre la tâche des serveurs plus ciblée sur la gestion des connectés et la de se rapprocher du fonctionnement de ProActive, nous avons

emble de la conversation serait transmis directement entre les mobiles. La migration devant être transparente au maximum pour les autres utilisateurs ainsi que pour le serveur.

Page 23: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

23 Baptiste DE STEFANO, Nicolas DODELIN

5.4.1. La connexion

Nous avons réfléchis à plusieurs protocoles afin de connecter les deux mobiles entre eux

pour effectuer la migration.

Nous voulions activer la MIDlet au moyen de la technologie Push Registry qui permet de

réveiller une application JAVA préalablement installée sur le téléphone afin de la faire agir.

Avec le profil MIDP, J2ME dispose de la technologie Push Registry qui fait partie de l’AMS

(Application Management System), le logiciel responsable du cycle de vie de chaque application

(installation, activation, exécution et l’arrêt).

Lors de l’installation il faut spécifier le protocole ainsi que le port pour ensuite pouvoir

réveiller l’application par leurs biais. Il est possible d’utiliser le Push Registry via le Bluetooth,

l’Infrarouge, le SMS, la socket…

Une des premières difficultés rencontrée pour la migration Mobile – Mobile est le réveil via

le Push Registry. En effet, quelque soit le protocole choisit lorsque nous réveillons une application

distante, celle-ci se lance mais n’a aucun moyen de savoir si la MIDlet est lancée automatiquement

grâce au Push Registry ou bien par simple activation de l’utilisateur.

La technologie Push Registry est plutôt destinée à des applications qui effectuent des

traitements toujours similaire lors de leur lancement, ce qui n’est pas notre cas car nous voulons soit

nous connecter au Serveur Mobile, soit récupérer des données d’un autre mobile afin de migrer.

Notre solution est donc de mettre le mobile en attente sur le protocole, l’application devant

être lancée auparavant afin de migrer.

Enfin concernant le protocole nous avons opté pour le protocole SMS. Le Bluetooth ainsi que

l’Infrarouge nécessitant la proximité entre les appareils et la socket nécessitant la connaissance de

l’adresse IP du destinataire, il nous semble plus simple de saisir simplement le numéro de téléphone

du destinataire pour initialiser la connexion.

Page 24: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

24 Baptiste DE STEFANO, Nicolas DODELIN

5.4.2. La migration

Ce schéma montre les différentes actions entre le Client M

veut migrer ainsi que le Serveur Mobile.

(1) Nous avons donc décidé de mettre le destinataire en

attente de message. Celui-ci sera toujours réveillé à l’aide d’un

message PUSH mais l’application devra être lancée préalablement.

la technologie ProActive pour la téléphonie mobile

Baptiste DE STEFANO, Nicolas DODELIN

La migration

rentes actions entre le Client Mobile, le mobile vers lequel cel

obile.

Nous avons donc décidé de mettre le destinataire en

ci sera toujours réveillé à l’aide d’un

message PUSH mais l’application devra être lancée préalablement.

la technologie ProActive pour la téléphonie mobile

obile, le mobile vers lequel celui-ci

Page 25: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

25 Baptiste DE STEFANO, Nicolas DODELIN

L’avantage d’utiliser le SMS

est qu’il suffit de connaître le numéro

de téléphone du destinataire pour

effectuer la migration.

(2) A gauche le mobile qui

souhaite migrer saisie le numéro de

téléphone du destinataire. Le

Wireless ToolKit de Sun attribue un

numéro à chaque téléphone émulé

comme l’indique la barre de titre de

chaque mobile. Ici le destinataire a

numéro +5550001.

type d’offre souscrit auprès de l’opérateur.

JSR 205 (JAVA Spe

Messaging (WMA) permettant la rédaction, l’envoi et la réception

de message

lequel l’application est enregistrée à l’envoi du message SMS.

la technologie ProActive pour la téléphonie mobile

Baptiste DE STEFANO, Nicolas DODELIN

Du côté du Client Mobile

qui désire migrer vers un autre

mobile, l’utilisateur spécifie juste

le numéro de téléphone du

destinataire.

A gauche le mobile qui

désire migrer vers le mobile de

droite qui est en attente.

L’avantage d’utiliser le SMS

e numéro

de téléphone du destinataire pour

A gauche le mobile qui

souhaite migrer saisie le numéro de

téléphone du destinataire. Le

Wireless ToolKit de Sun attribue un

numéro à chaque téléphone émulé

de titre de

a le

Le désavantage est que l’envoi de SMS est payant selon le

type d’offre souscrit auprès de l’opérateur.

Pour l’envoi de message de type SMS Push, nous utilisons la

JSR 205 (JAVA Specification Requests) qui contient l’API Wireless

Messaging (WMA) permettant la rédaction, l’envoi et la réception

de messages. Un message Push nécessite juste l’ajout d’un port sur

lequel l’application est enregistrée à l’envoi du message SMS.

la technologie ProActive pour la téléphonie mobile

Du côté du Client Mobile

désire migrer vers un autre

mobile, l’utilisateur spécifie juste

le numéro de téléphone du

A gauche le mobile qui

désire migrer vers le mobile de

droite qui est en attente.

Le désavantage est que l’envoi de SMS est payant selon le

nous utilisons la

cification Requests) qui contient l’API Wireless

Messaging (WMA) permettant la rédaction, l’envoi et la réception

. Un message Push nécessite juste l’ajout d’un port sur

lequel l’application est enregistrée à l’envoi du message SMS.

Page 26: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

26 Baptiste DE STEFANO, Nicolas DODELIN

La réception du SMS réveille l’application en attente et permet de synchroniser les deux

mobiles qui vont communiquer via une s

que l’adresse de la socket créé par le mobile pour transférer la conversation.

(3) Le destinataire se connecte donc au mobile

migrer se met en attente de synchronisation

connecté au Serveur Mobile (5) avec le nom d’utilisateur reçu dans le SMS.

Comme pour une connexion normale, le Serveur M

envoie au téléphone l’ensemble des conn

(8) Une fois la connexion avec le serveur établie

souhaite migrer afin de lui indiquer qu’il est prêt à recevoir la conversation.

(9) Le premier téléphone

destinataire l’ensemble de la conversation

Une fois la conversation bien reçu

reçoit des messages comme si de rien était

transparente pour tous les autres clients e

pour le Serveur Mobile.

(11) La connexion entre les deux mobiles est alors fermée.

(12) La mise à jour de la conversation est assez délicate puisque les messages reçu

migration doivent être affichés correctement à la suite de

souhaite migrer.

La deuxième difficulté que nous avons donc

pendant la migration. En effet l’objectif est de ne perdre aucun message de la conversation durant la

migration.

la technologie ProActive pour la téléphonie mobile

Baptiste DE STEFANO, Nicolas DODELIN

La réception du SMS réveille l’application en attente et permet de synchroniser les deux

vont communiquer via une socket. Dans le SMS sont envoyés le nom d’utilisateur

ocket créé par le mobile pour transférer la conversation.

Le destinataire se connecte donc au mobile. A cet instant, le Client Mobile qui souhaite

migrer se met en attente de synchronisation (4) tant que le destinataire n’est pas complètement

avec le nom d’utilisateur reçu dans le SMS.

pour une connexion normale, le Serveur Mobile crée un objet Client Mobile (6) et

l’ensemble des connectés (7).

Une fois la connexion avec le serveur établie, le destinataire notifie le premier mobile qui

souhaite migrer afin de lui indiquer qu’il est prêt à recevoir la conversation.

ferme alors sa connexion avec le Serveur Mobile et envoi

destinataire l’ensemble de la conversation (10).

Une fois la conversation bien reçue, le destinataire émet et

comme si de rien était, la migration étant

transparente pour tous les autres clients et presque transparente

(11) La connexion entre les deux mobiles est alors fermée.

) La mise à jour de la conversation est assez délicate puisque les messages reçu

correctement à la suite de la conversation envoyée par le mobile qui

que nous avons donc rencontrée est la synchronisation nécessaire

pendant la migration. En effet l’objectif est de ne perdre aucun message de la conversation durant la

la technologie ProActive pour la téléphonie mobile

La réception du SMS réveille l’application en attente et permet de synchroniser les deux

ont envoyés le nom d’utilisateur ainsi

lient Mobile qui souhaite

(4) tant que le destinataire n’est pas complètement

obile crée un objet Client Mobile (6) et

, le destinataire notifie le premier mobile qui

eur Mobile et envoie au

) La mise à jour de la conversation est assez délicate puisque les messages reçus durant la

par le mobile qui

est la synchronisation nécessaire

pendant la migration. En effet l’objectif est de ne perdre aucun message de la conversation durant la

Page 27: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

27 Baptiste DE STEFANO, Nicolas DODELIN

5.4.3. La mise à jour de la conversation

Pendant une courte durée les deux mobiles sont connectés au Serveur Mobile. Cela est

nécessaire pour ne perdre aucun message.

Lors de la réception d’un message, chaque client l’affiche selon l’écran de l’application. En

revanche, un client qui est en attente de migration stocke l’ensemble des messages tant qu’il n’a pas

reçu toute la conversation provenant de l’autre mobile. Une fois cette conversation reçue, les

messages qui ont été stockés durant cette migration sont récupérés et ajoutés à la suite de la

conversation.

Durant ces étapes, les messages envoyés par les autres utilisateurs ne sont donc pas perdus

par la migration. Une fois que tous les messages sont affichés sans qu’il y en ait d’autres envoyés par

les autres clients, le mobile reprend le fonctionnement normal de l’application. L’émission et la

réception des messages sont directement affichées sur l’écran comme si de rien n’était.

Aucun message de Déconnexion / Connexion n’est apparue aux utilisateurs, la migration est

donc transparente pour les autres utilisateurs.

Elle est quasiment transparente pour le Serveur Mobile également puisque celui-ci est

seulement avertit lors de la connexion du destinataire, via un message, qu’il s’agit d’une connexion

suite à une migration et non pas une connexion classique.

Page 28: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

28 Baptiste DE STEFANO, Nicolas DODELIN

6. Interaction ProActive (PC) - Mobile

Afin d’effectuer la migration d’un Client PC vers un Client Mobile nous avons utilisé une

connexion via socket. Cependant nous avons développé une solution utilisant le Bluetooth. Comme

vous pourrez le voir plus en détail dans la partie Problèmes rencontrés (page 35), le mobile HTC S620

qui nous a été prêté ne permettait pas d’implémenter des services Bluetooth.

De plus comme nous utilisons un dongle Bluetooth (ou clé Bluetooth) notre PC n’est pas

capable de détecter des services créés par les émulateurs du Wireless ToolKit de Sun.

Nous allons donc vous présenter tout d’abord notre solution qui utilise le Bluetooth puis la

solution retenue avec la connexion socket.

6.1. Solution Bluetooth

Le principe de la migration de Client PC vers Client Mobile est de faire créer un service

Bluetooth par le téléphone portable. Plusieurs téléphones peuvent bien sûr être en attente d’une

migration et avoir créer ce service. C’est pourquoi le Client PC ajoute un système de recherche des

services Bluetooth afin de pouvoir choisir aisément vers quel téléphone l’on décide migrer. Un

téléphone ne possède pas initialement d’adresse IP. Pour en posséder une, il faut que ce soit le

téléphone qui initie une demande de connexion à un réseau afin que ce dernier lui fournisse une

adresse. L’intérêt du Bluetooth est de pouvoir utiliser le Push Registry afin de réveiller l’application et

lui envoyer directement les données sans passer par une connexion socket. Voici donc le scénario de

migration via Bluetooth d’un Client PC vers un Client Mobile :

1- Le Client Mobile se met en attente en créant un service Bluetooth

2- Le client qui décide de migrer cherche si un téléphone est prêt à recevoir une migration

3- S’Il détecte au moins un téléphone, il lance une interface graphique avec une liste de

téléphones qui permettra à l’utilisateur de choisir vers quel terminal il va migrer

4- Le Client PC envoie un signal PUSH au téléphone

5- Le téléphone reçoit le message et demande au client s’il peut accepter la connexion

6- Par le même protocole mis en place pour migrer de téléphone à téléphone, les deux

terminaux s’échangent des données

7- Le Client PC se déconnecte

Page 29: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

29 Baptiste DE STEFANO, Nicolas DODELIN

La figure suivante nous montre la fenêtre permettant de choisir un téléphone en attente

d’une migration.

Nous avons rencontré certains problèmes pour utiliser le Bluetoo

manière identique aux téléphones portables, pour utiliser un dispositif

nous nécessitons l’utilisation de la JSR 82. Il nous a fallu

sur la pile Bluetooth par la machine

Bluecove. En ajoutant les fichiers

technologie Bluetooth comme sur un téléphone portable.

la technologie ProActive pour la téléphonie mobile

Baptiste DE STEFANO, Nicolas DODELIN

e suivante nous montre la fenêtre permettant de choisir un téléphone en attente

certains problèmes pour utiliser le Bluetooth sur un

manière identique aux téléphones portables, pour utiliser un dispositif Bluetooth sur un ordinateur

JSR 82. Il nous a fallu télécharger des DLLs permettant d’interagir

par la machine virtuelle JAVA. Nous avons utilisé une librairie JAVA n

Bluecove. En ajoutant les fichiers .jar dans notre CLASSPATH JAVA nous avons p

technologie Bluetooth comme sur un téléphone portable.

la technologie ProActive pour la téléphonie mobile

e suivante nous montre la fenêtre permettant de choisir un téléphone en attente

th sur un ordinateur. De

sur un ordinateur

permettant d’interagir

Nous avons utilisé une librairie JAVA nommée

avons pu utiliser la

Page 30: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

30 Baptiste DE STEFANO, Nicolas DODELIN

6.2. Solution retenue

Le schéma ci-dessous montre les différentes étapes de la migration d’un Client PC vers un

Client Mobile.

la technologie ProActive pour la téléphonie mobile

Baptiste DE STEFANO, Nicolas DODELIN

6.2. Solution retenue : socket

dessous montre les différentes étapes de la migration d’un Client PC vers un

(1) Le mobile est tout d’abord en attente de connexion

sur la socket qu’il crée. Lorsque l’utilisateur sélectionne

Waiting Migration From PC (à gauche), l’écran suivant apparaît

permettant à l’utilisateur de connaître son adresse IP.

la technologie ProActive pour la téléphonie mobile

dessous montre les différentes étapes de la migration d’un Client PC vers un

Le mobile est tout d’abord en attente de connexion

Lorsque l’utilisateur sélectionne

), l’écran suivant apparaît

permettant à l’utilisateur de connaître son adresse IP.

Page 31: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

31 Baptiste DE STEFANO, Nicolas DODELIN

(2) Lorsque le Client PC se connecte, il envoi

se mettre en attente de synchronisation tant que l’objet Client Mobil

Ci-dessus l’utilisateur saisit l’adress

Client PC essaie tout d’abord de se connecter à la s

n’est trouvée à l’adresse IP correspon

l’utilisateur souhaite migrer vers un PC dont l’adresse IP est 192.168.1.20.

Dans notre cas, c’est bien une migration vers un mobile qui a lieu donc l

au Serveur Mobile en utilisant le nom d’utilisateur reçu et en précisant qu’il s’agit d’une migration et

non d’une simple connexion (5).

Pour une migration de mobile à mobile, il n’est pas nécessaire de prévenir au préalable le

Serveur Mobile qu’il s’agit d’une migration car

revanche comme ici et dans le cas d’une migration Client Mobile vers Client PC, il est impératif de

prévenir qu’une migration va avoir lieu

perdre la connexion.

(7) Le mobile se met également en attente de synchronisation car l’objet Client Mobile doit

être créé avant de poursuivre (6).

(8) Une fois réveillé, le nouveau Client Mobile réveille à son tour le Client PC pour lui indiquer

qu’il est prêt à recevoir la conversation

(10) La conversation envoyée

Client Mobile (11).

la technologie ProActive pour la téléphonie mobile

Baptiste DE STEFANO, Nicolas DODELIN

Lorsque le Client PC se connecte, il envoie tout d’abord le nom d’utilisateur

se mettre en attente de synchronisation tant que l’objet Client Mobile n’est pas créé (4)

dessus l’utilisateur saisit l’adresse IP du mobile. En cliquant sur le bouton Migrate

t d’abord de se connecter à la socket créé par le mobile. Mais si aucune s

l’adresse IP correspondante, cela signifie qu’en cliquant sur le bouton Migrate

l’utilisateur souhaite migrer vers un PC dont l’adresse IP est 192.168.1.20.

Dans notre cas, c’est bien une migration vers un mobile qui a lieu donc le mobile se connecte

utilisant le nom d’utilisateur reçu et en précisant qu’il s’agit d’une migration et

Pour une migration de mobile à mobile, il n’est pas nécessaire de prévenir au préalable le

Serveur Mobile qu’il s’agit d’une migration car les deux mobiles sont gérés par le Serveur Mobile. En

revanche comme ici et dans le cas d’une migration Client Mobile vers Client PC, il est impératif de

prévenir qu’une migration va avoir lieu afin que les serveurs gèrent leurs listes des connectés sans

Le mobile se met également en attente de synchronisation car l’objet Client Mobile doit

Une fois réveillé, le nouveau Client Mobile réveille à son tour le Client PC pour lui indiquer

est prêt à recevoir la conversation (9).

La conversation envoyée, le Client PC ferme la connexion avec le Serveur PC

la technologie ProActive pour la téléphonie mobile

tout d’abord le nom d’utilisateur (3) avant de

(4).

le bouton Migrate ! le

i aucune socket

dante, cela signifie qu’en cliquant sur le bouton Migrate !

e mobile se connecte

utilisant le nom d’utilisateur reçu et en précisant qu’il s’agit d’une migration et

Pour une migration de mobile à mobile, il n’est pas nécessaire de prévenir au préalable le

les deux mobiles sont gérés par le Serveur Mobile. En

revanche comme ici et dans le cas d’une migration Client Mobile vers Client PC, il est impératif de

des connectés sans

Le mobile se met également en attente de synchronisation car l’objet Client Mobile doit

Une fois réveillé, le nouveau Client Mobile réveille à son tour le Client PC pour lui indiquer

le Client PC ferme la connexion avec le Serveur PC et avec le

Page 32: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

32 Baptiste DE STEFANO, Nicolas DODELIN

(12) Enfin le Client Mobile met à jour la conversation avec les messages qu’il aurait pu

recevoir durant l’envoi de la conversation comme expliqué en détails page

Les Clients Mobiles et PCs (ProActive) communiquent donc parfaitement.

la technologie ProActive pour la téléphonie mobile

Baptiste DE STEFANO, Nicolas DODELIN

Enfin le Client Mobile met à jour la conversation avec les messages qu’il aurait pu

durant l’envoi de la conversation comme expliqué en détails page 27.

Au niveau des clients la migration est totalement

transparente vue que l’utilisateur reste connecté et ne perd

aucun message.

En ce qui concerne les deux serveurs, ils sont juste

avertis de la migration à la déconnexion du Client PC pour le

Serveur PC et à la connexion pour le Serveur Mobile.

Les Clients Mobiles et PCs (ProActive) communiquent donc parfaitement.

la technologie ProActive pour la téléphonie mobile

Enfin le Client Mobile met à jour la conversation avec les messages qu’il aurait pu

Au niveau des clients la migration est totalement

transparente vue que l’utilisateur reste connecté et ne perd

En ce qui concerne les deux serveurs, ils sont juste

ertis de la migration à la déconnexion du Client PC pour le

Serveur PC et à la connexion pour le Serveur Mobile.

Page 33: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

33 Baptiste DE STEFANO, Nicolas DODELIN

7. Interaction Mobile – ProActive (PC)

Afin de migrer d’un objet mobile vers un objet ProActive, nous utilisons un

socket. Les Serveur Mobile et Serveur PC

conversation, ce sont les deux objets qui communiquent directement entre eux.

Ci-dessus vous pouvez voir le schéma représentant la solution que nous avons développé

(1) Dans un premier temps le Client PC se met en

attente de connexion sur une socket.

la technologie ProActive pour la téléphonie mobile

Baptiste DE STEFANO, Nicolas DODELIN

ProActive (PC)

mobile vers un objet ProActive, nous utilisons une

ocket. Les Serveur Mobile et Serveur PC ne transmettent aucunes données relatives à la

conversation, ce sont les deux objets qui communiquent directement entre eux.

dessus vous pouvez voir le schéma représentant la solution que nous avons développé

(1) Dans un premier temps le Client PC se met en

ocket.

(2) Lorsque le Client

Mobile se connecte à cette

socket en spécifiant l’adresse IP

du destinataire, (3) il lui envoie

tout d’abord son nom

d’utilisateur nécessaire à la

création de l’objet actif.

la technologie ProActive pour la téléphonie mobile

fois de plus la

ne transmettent aucunes données relatives à la

dessus vous pouvez voir le schéma représentant la solution que nous avons développée.

Page 34: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

34 Baptiste DE STEFANO, Nicolas DODELIN

(4) L’objet actif est alors créé, puis est inscrit au groupe de diffusion du Serveur PC (5). A

instant, les messages reçus par le Client PC sont stockés tant que l’e

socket (6) n’est pas terminé.

(7) Une fois la conversation envoyée

Client Mobile prévient le Serveur Mobile qu’il va migrer vers

la liste des mobiles connectés (il ne reçoit donc plus de messages) et se met en attente de

synchronisation (9), c'est-à-dire qu’il attend que la migration soit terminée pour fermer

complètement sa connexion avec le Serveur Mobile.

(10) Durant ce temps, le Client PC met à jour la conversation et une fois terminé la fenêtre de

discussion apparaît avec le texte de la discussion et la liste des connectés

dessous.

Au niveau des utilisateurs, que ce soit mobiles ou PCs, la migration d’un objet mobile vers un

objet ProActive est complètement transparente.

Elle l’est un tout petit peu moins pour les deux serveurs qui sont avertis l’un que le client va

migrer et l’autre que l’objet est créé à partir d’une migration.

la technologie ProActive pour la téléphonie mobile

Baptiste DE STEFANO, Nicolas DODELIN

(4) L’objet actif est alors créé, puis est inscrit au groupe de diffusion du Serveur PC (5). A

e Client PC sont stockés tant que l’envoi de la conversation via la

(7) Une fois la conversation envoyée, le Client PC et le Client Mobile ferment

Client Mobile prévient le Serveur Mobile qu’il va migrer vers un PC (8). Le Client Mobile est retiré de

la liste des mobiles connectés (il ne reçoit donc plus de messages) et se met en attente de

dire qu’il attend que la migration soit terminée pour fermer

le Serveur Mobile.

(10) Durant ce temps, le Client PC met à jour la conversation et une fois terminé la fenêtre de

discussion apparaît avec le texte de la discussion et la liste des connectés comme sur l’image ci

utilisateurs, que ce soit mobiles ou PCs, la migration d’un objet mobile vers un

objet ProActive est complètement transparente.

Elle l’est un tout petit peu moins pour les deux serveurs qui sont avertis l’un que le client va

est créé à partir d’une migration.

la technologie ProActive pour la téléphonie mobile

(4) L’objet actif est alors créé, puis est inscrit au groupe de diffusion du Serveur PC (5). A cet

nvoi de la conversation via la

nt la socket et le

un PC (8). Le Client Mobile est retiré de

la liste des mobiles connectés (il ne reçoit donc plus de messages) et se met en attente de

dire qu’il attend que la migration soit terminée pour fermer

(10) Durant ce temps, le Client PC met à jour la conversation et une fois terminé la fenêtre de

comme sur l’image ci-

utilisateurs, que ce soit mobiles ou PCs, la migration d’un objet mobile vers un

Elle l’est un tout petit peu moins pour les deux serveurs qui sont avertis l’un que le client va

Page 35: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

35 Baptiste DE STEFANO, Nicolas DODELIN

8. Problèmes rencontrés

Le premier problème rencontré durant ce début de Projet de Fin d’Études a été la

compréhension et l’utilisation de ProActive. Un tutoriel est bien présent pour nous expliquer pas à

pas les différents aspects de ce framework. Malheureusement, ProActive est un produit en constante

évolution car les ingénieurs de l’INRIA travaillant dessus continuent chaque jour de le faire évoluer.

D’importantes modifications avaient été faites et il s’est avéré que les codes présents pour la

nouvelle version n’étaient pas compatibles avec le code correspondant sur le tutorial.

Ensuite nous avons eu des doutes quant à la réalisation du projet initialement prévu car un

projet de même type avait déjà été expérimenté auparavant et nous devions réévaluer les

possibilités qu’offrent les nouvelles technologies pour reprendre ce projet. Ces technologies ayant

finalement très peu évoluées durant cette période, nous avons donc passé beaucoup de temps à

analyser le problème afin de pouvoir l’aborder différemment de ce qui a pu être fait deux ans avant.

Nous avons aussi rencontré des problèmes pour nous adapter au téléphone que l’on nous a

prêté pour le projet. En effet, nous nécessitions un téléphone possédant la technologie Wi-Fi. Le

téléphone que nous avons reçu correspondait bien à nos attentes par rapport à ses capacités

techniques mais nous n’avions pas prévu que ce dernier soit très limité pour la programmation JAVA.

En effet, à l’origine nous voulions nous servir de la technologie Push Registry des téléphones

portables qui permet de réveiller une application installée sur un téléphone. Cette technologie est

utilisable sur plusieurs mediums tels que le SMS, le Bluetooth ou même l’infrarouge.

De nombreuses technologies JAVA sont localisées dans des librairies nommées JSR. Tous les

téléphones mobiles équipés de machine virtuelle JAVA ne possèdent pas les même JSR et donc

certaines technologies peuvent ne pas être disponibles si la JSR n’est pas présente ; même si le

téléphone normalement serait capable de le faire. Le téléphone que nous avons reçu possédait bien

la technologie Bluetooth mais pas la JSR 82 qui permet de communiquer par le biais de ce medium.

De même, la JSR 205, qui permet l’envoi de messages tels que des SMS, était elle aussi indisponible.

C’est pourquoi notre application a été testée en grande partie à l’aide de l’émulateur de

téléphones présent dans le Wireless Java ToolKit.

Page 36: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

36 Baptiste DE STEFANO, Nicolas DODELIN

9. Planning du projet

Durant le premier mois, notre projet a consisté à l’apprentissage de ProActive comme

comprendre ce qu’est un objet actif, le rôle des nœuds ou comment se déroule la migration d’un

objet actif.

Pendant le mois de novembre, tout en continuant notre apprentissage, nous commencions à

mettre en place une idée d’application respectant les spécifications énoncées dans la présentation

du projet et la mise en place d’une architecture envisageable.

Au mois de décembre, suite à un rendez-vous que nous avions eu avec Vincent BERGE,

directeur de l’entreprise Mobile Distillery, nous avons commencé l’analyse et la conception de notre

application de Chat avec plus précisément l’écriture de notre diagramme de classe, et de nos

protocoles de communications.

Durant les mois de Janvier et de Février, nous avons partagé le travail de codage de

l’application. Nicolas s’est occupé de toute la partie communication mobile avec la mise en place des

communications sockets entre les téléphones mobiles et le Serveur Mobile. Il a aussi implémenté le

protocole de migration de mobile à mobile, pour pouvoir migrer sans perdre d’informations.

Baptiste s’est occupé de la partie PC de l’application. Il a mis en place le serveur de

localisation, l’implémentation d’une migration simple d’utilisation et tester un protocole par

Bluetooth pour la migration d’un Client PC à un Client Mobile.

La dernière semaine a consisté à mettre en commun les deux parties et vérifier que toutes

nos spécifications avaient bien été respectées, comme tester que nous ne perdions bien aucunes

informations lors de nos quatre scénarii de migration en envoyant de nombreux messages via

d’autres clients.

Page 37: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

37 Baptiste DE STEFANO, Nicolas DODELIN

Conclusion

Pour conclure, ce Projet de Fin d’Etudes nous a permis de pouvoir partir sur de bonnes bases

pour notre futur stage. En effet, durant cette période, nous avons appris à comprendre le

fonctionnement de ProActive et d’en utiliser les fonctionnalités nécessaires au bon fonctionnement

du Chat. Nous avons réussi à créer un protocole capable de faire communiquer un objet actif

s’exécutant sous J2SE et des téléphones mobiles utilisant quant à eux J2ME. De plus, nous avons été

capables de faire migrer une application dans les quatre scénarii disponibles qui sont :

• Migration de client PC à client PC

• Migration de client PC à téléphone mobile

• Migration de téléphone mobile à client PC

• Migration de téléphone mobile à téléphone mobile

Nous avons aussi mis en place des protocoles totalement différents par rapport au projet d’il

y a deux ans. En effet, ce projet proposait des communications par HTTP reposant sur des Web

Services alors que notre solution reposant elle principalement sur des communications sockets a

l’avantage d’être plus légère en termes d’architecture.

Néanmoins, ce projet reste aussi un tremplin pour la suite, car notre stage sera dans la

continuité de celui-ci. Nous travaillerons cette fois-ci beaucoup avec Mobille Distillery, l’entreprise en

partenariat avec l’INRIA, et principalement avec leur logiciel nommé Celsius. Celsius permet d’écrire

un seul code et d’en dériver aisément, sans effort de la part du programmeur, une version pour

chacun des téléphones du marché. Notre but consistera donc en l'incorporation au sein de la

plateforme CELSIUS de mécanismes permettant la communication ProActive<->J2ME en nous

servant de notre programme de Chat comme base de travail. Ce stage pourra être aussi pour nous un

moyen de mettre en avant les problèmes techniques liés au Bluetooth que nous avons pu rencontrer

et essayer de les résoudre à l’aide de CELSIUS.

Page 38: École Polytechnique de l’Université de Nice Sophia

Intégration de la technologie ProActive pour la téléphonie mobile

38 Baptiste DE STEFANO, Nicolas DODELIN

Références

ProActive – Site officiel

http://proactive.inria.fr/

BlueCove – Librairie JAVA pour interagir sur la pile Bluetooth

www.bluecove.org

J2ME – Page de téléchargement

http://java.sun.com/products/sjwtoolkit/download.html

Java Specification Requests 82 - Bluetooth

http://java.sun.com/javame/reference/apis/jsr082/

Java Specification Resquests 205 – Wireless Messaging API

http://java.sun.com/products/wma/

Push Registry

http://developers.sun.com/mobility/midp/articles/pushreg/

Mobile Distillery

http://www.mobile-distillery.com/