Rapport du projet iFridge - DIUF

Transcription

iFridge
Informatique pervasive
6 mars 2007
Timothée Maret & Nicolas Martenet
Prof. Béat Hirsbrunner
Prof. Peter Kropf
Dr. Vincenzo Pallotta
Pascal Bruegger
Marc Schiely
iFridge
Resumé
Ce projet est basé sur la vision pervasive de l’informatique, présentée par
Mark Weiser dans les années nonante. Les motivations sont d’offrir une interface
non-obstrusive pour les utilisateurs et d’utiliser leurs localisations et mouvements comme entrée d’un système permettant de modifier de manière opportuniste et distribuée une liste de tâches à effectuer. Le scénario d’un appartement
d’étudiant partageant le même frigo a été sélectionné. Chaque étudiant peut
gérer la liste d’achats et est appelé à acheter certains des éléments de la liste
lorsque le système le détecte à proximité d’un magasin.
Les concepts principaux ont pus être implémentés et testés grâce au prototype réalisé dans ce projet. L’application est composée de plusieurs modules
spécialisés et hétérogènes, communiquant entre eux de manière asynchrone par
un espace de tuples.
Ce projet s’inscrit dans le cadre du projet uMove mené par le groupe de
recherche en intelligence artificielle et en informatique pervasive de l’Université
de Fribourg.
Mots clef : localisation, analyse du mouvement, gestion opportuniste et distribuée, architecture modulaire, espace de tuple, informatique pervasive
i
iFridge
Abstract
This project is based on the Mark Weiser’s vision of Ubiquitous Computing.
The main motivations are the creation of an unobstrusive user interface and the
integration of the user’s localization and motions as input. The system manages
in an opportunistic and distributed manner a list of daily tasks to do. A group
of roommates sharing the same fridge has been selected as main scenario. Every
student can manage the list of purchases and can be asked by the system to buy
any items of the current list when he/she stands or pass nearby a grocery shop.
The main concepts have been implemented and tested in a prototype. The
application is built with four specialized and heterogeneous modules, communicating in an asynchronous manner through a tuple space.
This project is a primarily developpement of the uMove project, presently
carried out by the pervasive and artificial intelligence research group of the
University of Fribourg.
Keywords : localization, movement analysis, opportunistic and distributed
task management, modular architecture, tuple space, ubiquitous computing
ii
iFridge
Table des matières
1 Introduction
1.1 Présentation . . . . . . . . . . . .
1.2 Caractéristiques principales . . .
1.3 Déroulement . . . . . . . . . . .
1.4 Logiciels utilisés . . . . . . . . . .
1.5 Matériel utilisé . . . . . . . . . .
1.5.1 Téléphone mobile et GPS
1.5.2 Tags RFID . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
1
1
2
3
3
3
2 Spécification
2.1 Scénario . . . . . . .
2.2 Fonctionnalités clefs
2.3 Use case . . . . . . .
2.4 Architecture . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
4
5
5
3 Implémentation
3.1 Jini/JavaSpaces . . . . . . . . . . . . . . . . . . .
3.2 Mobile Phone . . . . . . . . . . . . . . . . . . . .
3.2.1 Plateforme J2ME . . . . . . . . . . . . .
3.2.2 Développement sur le Nokia 6600 . . . . .
3.2.3 GPS bluetooth . . . . . . . . . . . . . . .
3.2.4 Architecture . . . . . . . . . . . . . . . .
3.2.5 Librairie Java GPS-Bluetooth . . . . . . .
3.2.6 Interface graphique . . . . . . . . . . . . .
3.2.7 Accès aux ressources depuis un MIDlet . .
3.3 User Manager . . . . . . . . . . . . . . . . . . . .
3.3.1 Communication avec le téléphone mobile .
3.3.2 Architecture . . . . . . . . . . . . . . . .
3.4 Fridge . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 Architecture . . . . . . . . . . . . . . . .
3.4.2 Base de données . . . . . . . . . . . . . .
3.4.3 Serveur . . . . . . . . . . . . . . . . . . .
3.4.4 Interface Web . . . . . . . . . . . . . . . .
3.5 Backend . . . . . . . . . . . . . . . . . . . . . . .
3.5.1 Architecture . . . . . . . . . . . . . . . .
3.5.2 Base de donnée . . . . . . . . . . . . . . .
3.5.3 Serveur . . . . . . . . . . . . . . . . . . .
3.5.4 Interface Web . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
13
14
14
15
16
17
17
18
18
18
18
23
24
24
25
25
26
26
26
27
28
28
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Tests
5 Conclusions
5.1 Développement
5.2 Fonctionnelles .
5.3 Personnelles . .
5.4 Perspectives . .
29
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
29
29
30
30
Annexes
30
iii
iFridge
References
A Utilisation du programme
A.1 Compilation . . . . . . .
A.2 Exécution . . . . . . . .
A.2.1 Jini/JavaSpaces .
A.2.2 UserManager . .
A.2.3 Fridge . . . . . .
A.2.4 Backend . . . . .
A.2.5 MobilePhone . .
30
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
32
32
32
32
32
33
33
B Liste des figures
34
C Contenu du CD
34
iv
iFridge
1
Introduction
1.1
Présentation
L’objectif de ce projet est de créer une application basée sur les principes de
l’informatique pervasive1 définis par Mark Weiser dans son article, The Computer for the 21st Century (1991) [6]. Cette application consiste en un frigo
partagé par plusieurs utilisateur disposant d’un téléphone mobile standard capable d’exécuter un MIDlet et disposant d’une connexion internet sans fil tel
que GPRS, UMTS ou EDGE. Un GPS est requis pour communiquer la localisation
des utilisateurs. Le frigo contient une base de donnée géographique de magasins
d’alimentations et peut demander à un utilisateur d’acheter certains éléments
de la liste lorsqu’il se trouve à proximité d’un magasin contenu dans sa base de
données.
L’architecture de ce projet est modulaire et basé sur les technologies suivantes permettant d’écrire des applications distribuées.
Jini network technology [16] [5] fournit une architecture ouverte permettant de développer des applications distribuées hautement volatiles et flexibles.
Cette technologie permet la gestion décentralisée de services pouvant êtres offerts par chaque participant au réseau, son infrastructure comprend des protocoles permettants à des clients d’enregistrer et de découvrir des services de
manière transparente. Jini offre différents modèles de programmation tel que
la gestion des transactions et la programmation événementielle.
JavaSpaces [1] est une implémentation en Java du langage de coordination
Linda. Cette implémentation est réalisée au dessus de Jini, par un service. Le
principe du langage Linda est de faire communiquer différents processus à l’aide
d’informations (tuples) insérées et retirées d’un espace commun dont la gestion
est distribuée et transparente.
1.2
Caractéristiques principales
Les principales caractéristiques de ce projet sont les suivantes
• Utilisation de la localisation et du mouvement des utilisateurs comme
entrée pour le système
• Répartition distribuée et opportuniste d’une charge de travail
• Non-obtrusif pour l’utilisateur
• Gestion de la coordination par une communication asynchrone
1.3
Déroulement
Ce projet s’est déroulé en parallèle du cours d’informatique pervasive [12]
durant le semestre d’hiver de l’année académique 2006-2007. Ce cours est donné
conjointement entre l’Université de Neuchâtel et l’Université de Fribourg. Les
différents participants au cours et au projet sont listés ci-dessous.
1 Ubiquitous
Computing
1/34
iFridge
Etudiants
Timothée Maret
Nicolas Martenet
[email protected]
[email protected]
Professeurs
Prof. Béat Hirsbrunner
Prof. Peter Kropf
[email protected]
[email protected]
Responable du projet
Dr. Vincenzo Pallotta
Assistants
Pascal Bruegger
Marc Schiely
[email protected]
[email protected]
[email protected]
Dans la phase de spécification, le projet a été dimensionné et réparti entre
les deux étudiants pour l’implémentation.
1.4
Logiciels utilisés
Ce projet est constitué de quatre applications (modules) développées en langage Java. Trois modules s’exécutent comme une application standalone, tandis
que le dernier s’exécute comme un MIDlet sur un téléphone mobile. Les modules
Backend et Fridge possèdent une interface web s’exécutant sur un serveur d’application JEE 5.
Pour le développement de chacune de ces parties, l’environnement de développement NetBeans sous Windows XP a été utilisé. Cet environnement a été
sélectionné car il dispose d’un bon support pour le développement d’applications pour les terminaux mobiles. Ce projet base son implémentation sur les
technologies Jini et JavaSpaces, et utilise certaines fonctionnalités du langage
Java tel que la généricité, apparues dans la version 1.5 [15]. Tous les logiciels
et librairies utilisées pour ce projet sont listés ci-dessous et disponibles dans le
répertoire lib.
• Apache ANT v 1.6.5
• Wireless Toolkit v 2.2 Toolkit pour le développement d’applications
Java pour terminaux mobiles
• NetBeans v 5.5 et Sun Application Server 9.0 Environnement de développement et serveur d’application
• JDK v 1.5.0.09
• Jini v 2.1 JavaSpaces y est intégré comme un service
• MathFP v 2.0.6 Librairie de calcul en virgule flottante pour J2ME
• MySQL v 5.0.27
• MySQL GUI Tools v 5.0 Outils d’administration pour MySQL
• MySQL Java Connector v 5.0.4
2/34
iFridge
1.5
1.5.1
Matériel utilisé
Téléphone mobile et GPS
Le téléphone mobile à notre disposition est un modèle Nokia 6600 série
60 deuxième édition, possédant les caractéristiques listées ci-dessous. Les téléphones compatibles avec notre développement doivent les supporter au minimum.
•
•
•
•
•
Configuration CLDC 1.0
Profile MIDP 2.0
Bluetooth API (JSR-82)
Support des connections TCP
Symbian OS v7.0s
Pour transférer 2 le MIDlet du PC de développement au téléphone mobile,
nous utilisons un dongle bluetooth MITSUMI Bluetooth USB ADAPTOR.
Le GPS utilisé est du type BTGPS II Trine de EMTAC. Ce modèle supporte
les protocoles NMEA-0183 (V2.20) et les sentences suivantes GGA, GSV, RMC, VTG.
Nous utilisons la sentence GGA.
1.5.2
Tags RFID
Le kit PhidgetRFID distribués par Phidgets a été utilisé. Ce kit comprend
une carte avec une antenne ainsi que des tags RFID. La carte est raccordée à
l’ordinateur par à un câble USB. Tous les informations à propos de ce kit sont
contenues dans le document [11].
Fig. 1 – Kit PhidgetRFID
Pour le développement, le fichier phidget21.jar contient toutes les classes
nécessaire. Il est important de noter que ces classes Java font en réalité appel à
2 L’implémentation du service de transfert de fichier par bluetooth sur ce téléphone mobile
est imparfait. Avant de mettre à jour le MIDlet sur le téléphone mobile, il faudra commencer
par effacer le message contenant l’ancien MIDlet dans la boîte de réception de messages. La
mise à jour ne pourra se faire uniquement lorsque le MIDlet n’est pas en cours d’utilisation.
3/34
iFridge
des classes natives écrites en C, il faut donc également posséder cette librairie native. Elle est disponible sur le site du fabriquant, cependant le fichier est packagé
dans un fichier msi utilisable uniquement avec le framework .Net. Nous avons
extrait la dll nécessaire (phidget21.dll) disponible dans le répertoire lib. Ce
fichier doit être placé dans le répertoire C:/WINDOWS/system32 de l’ordinateur
qui va exécuter le programme.
2
Spécification
2.1
Scénario
Prenons le cas d’un appartement d’étudiants partageant leurs repas et donc
leur frigo. Cet exemple est intéressant car tous les étudiants vont êtres capables
d’acheter les différents ingrédients et tous vont pouvoir ajouter des éléments à
la liste d’achat.
Le dimanche soir, un étudiant prépare les menus pour la semaine et entre
les ingrédients nécessaires par l’interface web du frigo. Le frigo peut dès lors
constater que des ingrédients sont manquants et dresser une liste d’achats.
Le lundi matin, les étudiants se rendent à leurs cours respectifs. Sur sa route,
un étudiant stressé passe à proximité d’un magasin d’alimentation, le frigo lui
envoye alors un message lui proposant d’acheter les différents ingrédients de sa
liste. L’étudiant étant en retard, il ne prend pas la peine de répondre à ce message. Le frigo détecte ce comportement et recherche un nouvel étudiant. C’est
alors qu’un autre étudiant serviable, passe à proximité d’une petite épicerie,
le système l’avertit par un message des éléments qu’il pourrait y acheter. Cet
étudiant accepte la liste de course et achète les ingrédients dans l’épicerie. A ce
moment, la frigo n’a pas encore pu faire acheter tous les ingrédients sur sa liste
car l’épicerie ne dispose pas de tous les éléments nécessaires.
A midi, un étudiant gastronome discute avec un amis des meilleurs recettes
qu’ils aient réalisés. L’eau à la bouche, l’étudiant utilise sont téléphone portable
pour ajouter des ingrédients à la liste d’achat du frigo. Au cours de l’après
midi, l’étudiant serviable n’étant toujours pas rentré pour déposer les ingrédients
achetés dans le frigo, celui-ci l’averti par un message que certaines des denrées
achetées sont réfrigérées et qu’il faut les ramener au plus vite pour ne pas briser
la chaîne du froid. L’étudiant se rend alors rapidement chez lui pour déposer les
ingrédients dans le frigo. Le soir, après les cours, un étudiant passe à proximité
d’un grand magasin ce qui lui permet d’acheter les éléments restant sur la liste,
comme lui demande le frigo.
2.2
Fonctionnalités clefs
Les fonctionnalités clefs du système sont listées ci-dessous
• Gestion par le frigo de la liste d’achat
• Répartition des achats en fonction de la localisation et du contenu des
magasins
• Possibilité de modification de la liste d’achat par chaque utilisateur depuis
leurs téléphones ou l’interface du frigo.
4/34
iFridge
• Gestion des requêtes et des alertes envoyées aux utilisateurs par le frigo
2.3
Use case
Fig. 2 – Use case de l’application
2.4
Architecture
L’architecture de l’application visible sur la Figure 3 est divisée en quatres
blocs interconnectés par un espace d’échange de tuples ou une connection GPRS.
Les blocs communiquent entre eux par échange de messages.
Tous les messages échangés par l’espace de tuples ont la forme suivante
<from:String, to:String, msg:Message>
5/34
iFridge
Fig. 3 – Architecture générale du projet
6/34
iFridge
Les champs from et to sont utilisés pour identifier l’émetteur, le récepteur et
donc le sens de la communication. Les messages peuvent êtres destiné à un acteur
non déterminé du réseau en utilisant une valeur spécifique dans le champs to.
Le champs msg va contenir l’information du message dont les différents types
possibles sont listés sur la Figure 4. La communication entre le bloc Fridge et
le bloc UserManager ne se fait jamais directement, mais doit passer par le bloc
Backend.
Fig. 4 – Messages échangés par les blocs de l’application
Les structures de données utilisées dans les messages sont listées sur la Figure 5. La classe State contient les coordonnées de localisation x et y au format
SwissGrid CH1903, la vitesse, l’accélération, la direction, l’altitude d’un utilisateur et la date EPOCH de la mesure. La classe Item définit un élément pouvant
être placé dans le frigo. Le paramètre maxTimeOutOfFridge de la structure Item
est utilisée pour spécifier le temps disponible en milli-secondes pour un élément
hors d’un frigo, sans risquer de briser la chaîne du froid. L’interface Filter va
permettre d’implémenter un filtre qui sera appliqué sur les données de localisation que recevra le bloc UserManager. La classe User définit un utilisateur du
système par son nom et son mot de passe.
7/34
iFridge
Fig. 5 – Structures de données de l’application
Bloc Fridge Ce bloc gère la liste des éléments disponibles dans le frigo, ainsi
qu’un profile contenant les éléments à acheter. Une antenne RFID est utilisée
pour déterminer lorsque les éléments associés à des tags RFID sortent ou entrent
dans le frigo. Une base de donnée est utilisée pour sauvegarder les éléments gérés
par le frigo, dont les champs correspondent à l’objet Item défini précédemment
auxquels sont ajoutés des informations. Ces champs supplémentaires permettent
notamment de savoir si l’élément est dans le frigo ou non ainsi que le tag RFID
qui lui est associé. Lorsqu’un élément manque, ce bloc avertit le Backend avec
un message ItemNeeded. Il reçoit en retour des message du type ItemsBought
lui indiquant les éléments achetés. Les Figure 6 et Figure 7 présentent le comportement du frigo lorsqu’un événement RFID survient ou lorsqu’un élément a
été acheté. Dans le cas ou des éléments critiques mettent trop de temps avant
d’être placés dans le frigo après l’achat, un message ItemTimeOut est envoyé au
Backend pour avertir la personne concernée.
A la réception d’un message ListProfileItems, le bloc va retourner dans
un message du même type, la liste des éléments contenus dans le profile. A la
réception des messages AddProfileItems et RemoveProfileItems , le profile
du frigo est mis à jour en fonction des éléments spécifiés. A la réception d’un
message ListFridgeContentItems , ce bloc retourne dans un message du même
type, la liste des éléments contenus dans le frigo.
Bloc UserManager Ce bloc agit comme un proxy entre le Backend et le
MobilePhone. Il gère les connexions des utilisateurs et traite les coordonnées de
localisation qu’il reçoit. Il calcul et ajoute les informations de vitesse, d’accélération et de direction qui ne sont pas disponibles dans les messages du GPS. Ce
bloc applique le filtre définit par le Backend sur tous les messages UserState
afin de déterminer si l’information doit ou non être insérée dans l’espace des
tuples. Dans le cas ou aucun filtre n’est définit, tous les messages de localisation
sont directement insérés.
Pour tous les autres types de messages, ce bloc fait la passerelle entre le bloc
MobilePhone et le Backend.
Bloc MobilePhone Ce bloc gère l’interaction avec l’utilisateur. Au démarrage de l’application, la connexion s’établit avec le bloc UserManager. Lorsqu’elle est établie, l’utilisateur doit entrer son nom d’utilisateur et son login pour
pouvoir utiliser le système, ce qui va générer l’envoi d’un message UserLogin
pour le contrôle. Un message du même type est retourné et contenant la validité
du login dans le champs exists. Lorsque cette opération est effectuée, ce bloc
8/34
iFridge
Fig. 6 – Diagramme d’activité lors d’un événement RFID par le bloc Fridge
9/34
iFridge
Fig. 7 – Diagramme d’activité à la réception d’un message ItemBought par le
bloc Fridge
10/34
iFridge
va entrer en connexion avec le GPS pour recevoir les données de localisation,
puis va présenter un menu regroupant différentes actions permettant de mettre
à jour le profile et de consulter la liste des éléments contenus dans le frigo.
Lorsqu’un message AskUserToBuy est reçu, une alerte sonore est émise pour
l’utilisateur, lui demandant s’il peut acheter certains des éléments de la liste.
Si l’utilisateur confirme ce message, les éléments qu’il va acheter seront envoyés
au bloc UserManager dans un message ItemsBought. Au bout d’un timeout, si
l’utilisateur n’a pas quittancé le message, un quittancement implicite va envoyer
un message GpsItemsBought contenant aucun éléments.
A la réception d’une donnée de localisation depuis le GPS, une mesure de la
distance entre ce nouveau point et le dernier point envoyé au bloc UserManager
est calculée. Dans le cas ou cette distance dépasse un certain seuil, le dernier
point est mis à jour puis envoyé au bloc UserManager. Ce mécanisme permet
d’économiser le nombre de messages émis lorsque l’utilisateur n’est pas en mouvement. Lorsqu’un message AlertUser est envoyé depuis le bloc UserManager,
une alerte sonore est émise et le message d’alerte est affiché sur l’interface utilisateur. L’utilisateur peut soit quittancer le message, soit le message se quittance
automatiquement à l’échéance d’un timeout.
Les utilisateurs ont la possibilité de modifier le profile du frigo, en envoyant
des messages des types AddProfileItems et RemoveProfileItems. Ils ont la
possibilité de voir le contenu du profile en envoyant un message du type ListProfileItems et de demander la liste des éléments gérés par le système en
utilisant le message KnownItems. La liste des éléments contenus dans le frigo est
obtenue par un message ListFridgeContentItems.
Bloc Backend Ce bloc contient une base de données contenant les login et
password de tous les utilisateurs pouvant êtres connectés, ainsi qu’une base de
données des associations entre les différents éléments et les lieux géographiques
permettant de les acheter. Une table est également prévue pour répertorier les
noms des éléments gérés par le système. De cette manière tous les utilisateurs
utilisent les même noms pour ajouter des éléments. Ce bloc maintient le profile
à jour.
A la réception d’un message UserState, si la liste des éléments à acheter
est vide, aucun traitement n’est effectué. Dans le cas contraire, une requête est
effectuée dans la base de donnée pour déterminer si l’utilisateur se trouve dans
une zone lui permettant d’acheter le maximum d’éléments de la liste. Dans ce
cas, ce bloc va faire envoyer à l’utilisateur une requête d’achat par un message AskUserToBuy. Ce comportement est illustré par la Figure 8. Dans le cas
ou l’utilisateur accepte d’acheter certains des éléments de la liste, un message
ItemsBought contenant les éléments est reçu. Dans le cas ou aucun éléments
ne peut être acheté ou que l’utilisateur ne traite pas la requête, un message
ItemsBought ne contenant aucun élément est reçu.
Dans le cas ou le message ItemsBought contient des éléments, le Backend
envoye un message ItemsBought au bloc Fridge contenant les éléments achetés,
dans le cas contraire, il attend pour trouver un nouvel utilisateur potentiel et
ne fera plus de demandes à cet utilisateur avant un certain temps.
Afin de réduire la quantité d’information transmise dans le space, ou de
détecter certains comportements des utilisateurs, le Backend va déterminer la
politique de filtrage des informations de localisation des utilisateurs et l’envoyer
11/34
iFridge
Fig. 8 – Structogramme de la gestion des données de localisation par le bloc
Backend
12/34
iFridge
par un message UserStateFilter au UserManager.
En retour à un message du type KnownItems, ce bloc retourne la liste des éléments contenus dans sa base de donnée. Les messages ListFridgeContentItems,
RemoveProfileItems et AddProfileItems sont simplement transférés aux blocs
UserManager ou Fridge en fonction de la situation. Le Backend répond directement aux messages ListProfileItems en renvoyant un message du même
type contenant la liste des éléments du profile. A la réception d’un message
ItemNeeded, l’élément contenu dans le message est ajouté au profile.
La réception d’un message ItemTimeOut signifie qu’un élément acheté n’a
pas été apporté au frigo, le backend réagit en envoyant un message AlertUser au
bloc UserManager qui s’occupe de notifier l’utilisateur sur le téléphone mobile.
Lorsqu’un utilisateur se connecte, une demande d’identification d’un message
UserLogin est reçu. Ce bloc contrôle que le nom d’utilisateur et le mot de passe
du message correspondent à ce qui est inscrit dans sa base de donnée et renvoie
un message du même type avec le champs exists mis à jour en fonction de la
validité des informations de login.
3
3.1
Implémentation
Jini/JavaSpaces
Jini offre un mécanisme de recherche multicast des services sur toutes les
machines disponibles sur le réseau. Cependant, le désavantage de cette démarche est rapidement apparu lors des premiers tests. En effet, plusieurs services
JavaSpaces étaient disponibles sur le réseau. Nos modules ne pouvaient donc
pas communiquer car ils ne se connectaient pas systématiquement au même
service JavaSpaces. C’est pourquoi l’option d’une recherche de service Unicast
permettant de spécifier la machine sur laquelle s’exécute JavaSpaces a été prise.
L’implémentation de la classe UnicastLookupLocator.java permettant d’effectuer cette recherche a été effectuée par Pascal Bruegger selon une idée évoquée
par Jan Newmarch dans son livre [3].
JavaSpaces [1] fournit de nombreuses fonctionnalités supplémentaires par
rapport à son modèle Linda, telles que la possibilité de définir un temps maximum de vie d’un tuple dans l’espace (Lease time), et la possibilité de définir
des listeners offrant une notification lorsqu’un tuple est inséré dans l’espace.
La première fonctionnalité est utilisée pour les messages UserState envoyés
par le bloc UserManager vers le bloc Backend. En effet, dans le cas ou le Backend
n’est pas assez rapide pour gérer tous les messages de localisation, ceux-ci sont
automatiquement effacé et ne seront pas traités.
La fonctionnalité des listeners permet d’implémenter des évènements distribués. Elle est interressante car elle permet d’optimiser le délai entre l’insertion
d’un tuple et le traitement de cet évènement. Dès les premiers tests, nous avons
pu nous apercevoir que l’implémentation offerte par Jini/JavaSpaces de ces
listeners n’est pas utilisable pour ce projet car de nombreux messages se perdent
et il est impossible de les récupérer. Cette limitation est annoncée dans la documentation de JavaSpaces, le service n’est pas fiable et l’ordre d’arrivé des
évènement n’est pas garanti.
Ainsi, l’implémentation de chacun des listeners s’est effectuée avec un thread
dont le code consiste à prendre continuellement un message dans l’espace de
13/34
iFridge
tuple, puis à invoquer une methode permettant de traiter ce message. Cette
mise en oeuvre ce révèle efficace; ceci est du au fait que nous utilisons une
méthode bloquante pour prendre le message dans l’espace des tuples. Ainsi,
le passage d’un thread à un autre s’effectue directement lorsqu’aucun message
adéquat n’est disponible. Le Listing 1 montre un extrait de l’implémentation du
listener pour les messages AlertUser.
import ...
public class Al er tU ser Li s t e n e r implements Runnable {
private Server server ;
private boolean interrupted ;
private AlertUser alertUser ;
public Al er tU ser Li st en e r ( Server server ) {
this . server = server ;
interrupted = false ;
}
public void run () {
while (! interrupted ) {
process () ;
}
}
/* * Wait for a AlertUser tuple then call the a l e r t U s e r C a l l b a c k method */
public void process () {
try {
alertUser = ( AlertUser ) server . getSpace () . take ( Server .
ALERT_USER_TEMPLATE , null , Long . MAX_VALUE ) ;
if (! interrupted ) server . a l e r t U s e r C a l l b a c k ( alertUser ) ;
} catch ( Exception ex ) {
ex . printStack T ra c e () ;
}
}
...
}
Listing 1 – Extrait AlertUserListener.java
Un autre avantage qu’offre cette mise en oeuvre par rapport aux listeners
de Jini/JavaSpaces tient dans le fait qu’elle permet une isolation totale des
différents modules. En effet, l’ordre de leur démarrage n’a pas d’importance
car aucun mécanisme d’enregistrement n’est requis. Aussi, lorsqu’un module se
termine brusquement, il peut redémarrer et traiter les messages insérés durant
son absence.
3.2
3.2.1
Mobile Phone
Plateforme J2ME
Ce chapitre permet de comprendre les choix de développement présentés plus
tard. En fonction du matériel que nous avions à diposition, notre implémentation est prévue pour des terminaux mobiles supportant la plateforme Java J2ME.
Cette plateforme définie par Sun est pensée pour correspondre à deux types de
terminaux mobiles. Chaque type est associé à une configuration qui fournit un
ensemble de base de librairies en fonction de leurs ressources matérielles.
• CDC (Connected Device Configuration) pour des terminaux mobiles disposant de ressources relativement élevées tel que des PDA
14/34
iFridge
• CLDC (Connected Limited Device Configuration) pour des terminaux mobiles disposants de ressources limitées tel que les téléphones mobiles
Sun définit des profiles au dessus des configurations, qui consistent en un
ensemble d’API (fonctionnalités de réseau, interface graphique, etc.) spécifique
à des terminaux. Le profil MIDP (Mobile Information Device Profile) est utilisé
au dessus de la configuration CLDC, tandis que le profil Personal Profile est
utilisé au dessus de la configuration CDC. Les applications écrites pour le profile
MIDP sont appelées des MIDlet.
Les spécifications des profiles utilisent trois niveaux d’intérêt (MUST, SHOULD,
MAY) qui vont déterminer si une fonctionnalité est obligatoire, nécessaire ou
optionnelle pour que l’implémentation du profile puisse être certifiée par Sun.
Concernant les terminaux aux ressources limitées, il existe plusieurs version des
profiles (MIDP 1.0, MIDP 2.0) et des configurations (CLDC 1.0, CLDC 1.1). La
principale limitation de la CLDC 1.0 réside dans le fait qu’elle ne supporte pas
les types à virgule flottante de Java (float et double). Cette limitation est
absente de la CLDC 1.1.
Au dessus des profiles sont définis les packages optionnels qui définissent des
fonctionnalités spécifiques que le constructeur peut implémenter en fonction de
ses désirs. Une de ces fonctionnalités est le support du protocole Bluetooth
défini dans la JSR-82.
3.2.2
Développement sur le Nokia 6600
Le Chapitre 1.5 définit les caractéristiques principales du téléphone mobile
que nous avions à disposition pour ce projet. L’implémentation des API sur les
téléphones mobiles peut être partiellement effectuée ou varier en fonction du
terminal. Les documents suivants constituent une aide essentielle pour le développement
• Document permettant de contourner les principaux bugs d’implémentation des API sur le Nokia 6600 [9]
• Document sur les spécificités de l’implémentation des API par Symbian [8]
• Document contenant la sémantique des codes d’erreur de Symbian OS [17]
Les limitations de ce type de téléphone mobile ont influencé l’implémentation. Le support des nombres à virgule flottante est primordiale pour ce module,
afin d’assurer la conversion des coordonnées de la représentation en WGS84 vers
CH1903, ainsi que pour le calcul de la distance entre les points de mesure du
GPS. Cette fonctionnalité a pu être assuré avec la librairie MathFP [4] qui
l’émule à partir de nombres entiers. Cette librairie est disponible dans le répertoire lib.
• Le support non natif des nombres à virgule flottante, et le non support de l’interface Serializable ne permettent pas d’utiliser les mêmes
classes que pour les messages transitant entre entre le bloc UserManager et le bloc MobilePhone. Chacune des classes de la Figure 4 et de
la Figure 5 sont doublées. Les nouvelles classes sont disponibles dans
les package ifridge.messages.betweengpsandserver et ifridge.util.betweengpsandserver. Chacune des classes porte le même nom que l’oriTimothée Maret & Nicolas Martenet
15/34
iFridge
ginale, préfixées par Gps. La classe mère devient donc la classe GpsMessage.
• Le non support de ObjectOutputStream ne nous permet pas d’échanger
directement des objets. C’est pourquoi l’implémentation d’une couche de
communication au dessus de TCP est requise , permettant de sérialiser les
messages, et de les reconstruire.
3.2.3
GPS bluetooth
Bluetooth est un protocole sans fil utilisant la bande ISM de 2.4GHz. Ce
protocole permet d’interconnecter différents types d’appareils et nous allons
l’utiliser pour la connexion entre notre téléphone mobile et notre GPS pour récupérer les informations de localisation. La norme Bluetooth définit des classes de
périphériques (téléphone mobile, clavier, imprimante, etc.) ainsi qu’un ensemble
de profiles associés aux services pouvant être offerts(Echange de fichier, etc.). La
connexion à un nouvel appareil offrant un service s’effectue en plusieurs phases
1. Recherche des terminaux disponibles (inquiry), en utilisant un protocole
définit dans le norme Bluetooth
2. Recherche des services disponibles sur un terminal donné, identifiés par
des UUID
3. Connexion au service spécifié en utilisant le protocole L2CAP ou un protocole basé sur celui-ci
4. Réception des données
La spécification de la norme Bluetooth en Java est contenue dans la JSR-82.
Nous utilisons cet spécification pour notre développement et notamment deux
classes d’exemple contenues dans le package bluetooth fournies par Symbian [7].
Les caractéristiques du GPS à disposition sont listées au Chapitre 1.5. Ce GPS
supporte les standards NMEA. Ces standards définissent des formats de trames
appelées sentences [2] qui permettent de formater l’information de localisation
émises par le GPS dans un string. Il existe de nombreux types de sentences,
la plus basique étant la GSV. La sentence GGA est cependant utilisée car elle
contient toutes les informations de localisation nécessaires pour ce projet. Le
string ci-dessous représente une sentence GGA.
$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47
Sur la base de ces normes, une implémentation d’un parseur contenu dans la
classe io.GGADataParser.java a été réalisée. Ce parser contient une méthode
pour parser une sentence GGA, une méthode permettant d’effectuer la conversion
entre le système de coordonnées WGS84 utilisé dans les sentences NMEA et le
système CH1903, ainsi qu’une méthode de calcul de la distance entre deux points
CH1903. Le format CH1903 est le système de coordonnées géographiques suisse
et a l’avantage de les exprimer en mètre et dans un plan, ce qui simplifie le
calcul des distances. Les points renvoyés par le parser sont contenus dans des
Objets du type GpsGGAData.
A la réception d’une sentence GGA, les coordonnées au format WGS84 sont
transformées en système CH1903, ensuite, la distance avec le dernier point envoyé au UserManager est calculée. Si cette distance est plus grande qu’un seuil
16/34
iFridge
définit par la variable MIN_EXCURSION de la classe io.IOManagerWithGPS.java,
les coordonnées seront envoyées au serveur dans un message GpsUserState, et
les dernières coordonnées sont mises à jour. Ce mécanisme permet d’économiser
la quantité d’information transmise par GPRS lorsque l’utilisateur ne bouge pas.
3.2.4
Architecture
La Figure 9 montre les différents threads utilisés par le bloc MobilePhone.
Le lancement du MIDlet va démarrer un thread IoManagerWithServer. La
fonction de ce thread est de se connecter au serveur TCP du bloc UserManager puis d’ouvrir un stream bidirectionnel sur cette connection. Ensuite, ce
thread lit continuellement les données sur le stream d’entrée afin de parser les
messages. Lorsque qu’un message est arrivé, la méthode processMessage est
appelée et va invoquer une méthode de callback correspondant au type de message reçu. Ce thread peut aussi envoyer des messages en utilisant la méthode
sendMessageToServer.
Les threads DeviceLookup et ServiceLookup sont utilisés pour la phase
de connexion avec le GPS. Au terme de cette phase, ils se terminent tandis
qu’un thread IoManagerWithGps est créé. Ce thread va continuellement lire les
données émisent par le GPS, à la recherche d’une sentence GGA.
Fig. 9 – Architecture du bloc MobilePhone
3.2.5
Librairie Java GPS-Bluetooth
Il existe une API Open Source pour la plateforme J2ME permettant de simplifier le développement d’applications utilisant la localisation par GPS. Cette
17/34
iFridge
librairie est relativement récente (avril 2006) et a été développée durant un
travail de licence à l’Université de Genève. Elle permet de se connecter à de
nombreux types de GPS Bluetooth, de les paramétrer, et supporte tous les
standard NMEA. Elle offre de nombreuses fonctionnalités de conversions entre
la pluspart des systèmes de coordonées, ainsi que des méthodes permettant de
calculer les distances. Cette librairie est de plus bien documentée, ce qui en fait
un outil extrêmement performant pour le développement d’applications de localisation. Cependant, la configuration nécessaire pour la faire fonctionner 3 la
rend incompatible avec le téléphone mobile à notre disposition.
Le code source ainsi que le rapport et la documentation sont disponbiles en
ligne [13] et dans le répertoire references/gpsapi/.
3.2.6
Interface graphique
Les Figure 10, Figure 11 et Figure 12 montrent les séquences de l’interface
du téléphone mobile lors de l’utilisation de l’application.
3.2.7
Accès aux ressources depuis un MIDlet
Le modèle de sécurité des MIDlet restreint l’accès aux fonctions de l’API
jugées sensibles (globalement toutes les fonctionnalités dérivées du Generic
Connection Framework) et demande explicitement à l’utilisateur s’il accepte
d’accéder aux ressources. Ce fonctionnement est inutilisable pour cette application car de nombreux accès au réseau et au GPS sont effectués.
Un MIDlet peut être distribué sous deux forme, sécurisée ou non. Lorsqu’un
MIDlet est sécurisé, il a été signé à l’aide d’un certificat électronique du type
Sun Java Signing Digital ID que l’on peut obtenir à un certain prix chez des
organismes tel que VeriSign http://www.verisign.com/products/signing/
code/. Dès lors, il pourra accéder sans encombres à toutes les fonctionnalités
désirées.
Un MIDlet non sécurisé peut lui aussi accéder aux ressources, mais l’utilisateur
devra modifier certains paramètres du MIDlet dans le gestionnaire d’applications du téléphone mobile tel que représenté sur la Figure 13.
Cette option a été sélectionnée car l’obtention d’un certificat électronique est
une opération relativement onéreuse et qu’il est possible de s’en passer.
Plus d’informations sur la signature des MIDlets peut être obtenue dans la documentation de Nokia [10].
3.3
User Manager
3.3.1
Communication avec le téléphone mobile
La communication avec le téléphone mobile s’effectue par GPRS. Il existe
plusieurs protocoles pour la transmission dont leurs avantages et désavantages
sont listés dans le Tableau 1.
Ce tableau permet de conclure que le protocole HTTP doit être sélectionné
car il est le seul à être supporté par tous les terminaux mobiles disposant de
MIDP 2.0. Cependant, le faible rendement de ce protocole pour les quantités
de données structurées qui seront transportées, poussent à implémenter une
3 CLDC
1.1, MIDP 2.0, JSR-82, GPS Bluetooth supportant les standards NMEA
18/34
iFridge
Fig. 10 – Séquence lors de la connection au GPS
19/34
iFridge
Fig. 11 – Séquence lors de l’utilisation non spontanée du service
Fig. 12 – Séquence lors de l’utilisation spontanée du service
20/34
iFridge
Fig. 13 – Autoriser implicitement l’accès d’un MIDlet au réseau [10]
Protocole Type
HTTP
Ce
protocole
peut être orienté
connexion ou non,
selon sa configuration. Le transfert
d’information
est
fiable.
TCP
Ce protocole est
orienté connexion. Le
transfert d’information est fiable.
UDP
Ce
protocole
n’est pas orienté
connexion. Le transfert
d’information
n’est pas fiable.
Rendement
Support
Le rendement de
l’information
utile
rapporté à l’information totale transférée
est
relativement
faible sur les petites
quantités de données
que nous devons
transporter.
Le rendement est excellent.
Le support est obligatoire (MUST) dans
MIDP 2.0. Ce protocole pourrait être utilisé directement avec
un Session Bean du
serveur d’application.
Le rendement est excellent.
Le support est nécessaire (SHOULD)
dans MIDP 2.0. Ce
protocole demande
l’écriture d’un serveur TCP pour le
UserManager
Le support est nécessaire (SHOULD)
dans MIDP 2.0. Ce
protocole demande
l’écriture d’un mini
serveur UDP pour le
UserManager, et un
mécanisme de mise
en ordre des paquets.
Tab. 1 – Comparaison des protocoles de communication
21/34
iFridge
solution qui devrait être complémentaire à la première, basée sur le protocole
TCP. Pour ce projet, c’est ce protocole qui a été sélectionné car le téléphone à
notre disposition le supporte.
Une couche de communication simple offrant un service de transfert de messages spécifiques a été implémentée au dessus du protocole TCP. Cette couche est
un cas particulier du service offert par un service de transfert d’objet générique
tel que ObjectOutputStream non disponible sur notre plateforme.
La sérialisation d’un message s’effectue par le biais de la classe TCPMessage.
Cette classe englobe un vecteur contenant les différentes parties du messages.
Les méthodes addToken et addTokens permettant d’ajouter une ou plusieurs
parties, et la méthode getTCPMessage retourne un String structuré à partir du
contenu du vecteur.
Chacune des sous classes de GpsMessage doit implémenter la méthode public
TCPMessage toTCPMessage(). Cette méthode va retourner un objet TCPMessage
contenant ses champs. Le Listing 2 montre l’implémentation de cette méthode
pour les messages GpsUserState.
...
public class GpsUserState extends GpsMessage {
public GpsUser user ;
public GpsState state ;
...
/* *
* Build a TCP message for this object
* @return
*/
public TCPMessage toTCPMessage () {
TCPMessage out = new TCPMessage () ;
out . addToken ( " US " ) ;
// set the MSGID
out . addTokens ( user . toTokens () ) ;
out . addTokens ( state . toTokens () ) ;
return out ;
}
}
Listing 2 – Extrait GpsUserState.java
Chacun des messages sérialisés aura la structure suivante:
◦MSGID∗TOKEN1∗TOKEN2∗ ... ∗TOKENn∗•
dans laquelle le symbole ◦ représente le délimiteur de trame, (ASCII code
STX), ∗ représente le délimiteur de token (ASCII code ETX) et • représente
le délimiteur de fin de trame (ASCII code NULL). Les délimiteurs sont ajoutés
lors de l’exécution de la méthode getTCPMessage. Le MSGID représente l’identificateur du type de message et les champs TOCKEN contiennent l’information
utile.
un exemple de message GpsUserState sérialisé est donné ci-dessous. Les informations utiles correspondent au nom et mot de passe de l’utilisateur, aux
coordonées CH1903X et CH1903Y, à l’altitude et à l’heure de la mesure en millisecondes.
◦US∗ROGER∗MOORE∗571424∗174564∗634∗21684000∗•
22/34
iFridge
Dans cette trame, l’information utile représente 33/44 = 75% de l’information transmise. Ce rapport est bon pour ces faibles quantités d’informations
structurées. La même information transmise avec HTTP aurait la forme minimale
ci-dessous et aurait un rendement de 33/102 = 32%.
GET /page.jsp?n=ROGER&p=MOORE&x=571424&y=174564&a=634&h=21684000 HTTP/1.1
Host: diuflx-vm07.unifr.ch
3.3.2
Architecture
La Figure 14 montre les différents threads de l’application. Ce bloc détient
une connexion avec l’espace de tuples et une connexion avec chacun des terminaux mobiles. Au démarrage, la connexion est établie avec JavaSpaces , puis
un thread est démarré pour chacun des listeners du space, enfin le serveur TCP
est démarré et va continuellement attendre des connexions.
Lorsqu’un utilisateur se connecte, un thread Service puis un thread KeepAlive sont démarrés. Le premier va lire continuellement les données reçues
du téléphone mobile afin de reconstruire les messages. Ce thread permet aussi
d’envoyer des messages au MobilePhone par la méthode sendMessageToMobile.
Le thread KeepAlive va périodiquement déclencher l’envoi d’un message de
heartbeat GpsKeepAlive afin de maintenir la connexion TCP active.
Fig. 14 – Schéma bloc du bloc UserManager
Ce bloc tient à jour le dernier message UserState pour chaque utilisateur
afin de pouvoir calculer les valeurs de vitesse et d’accélération. A la réception
23/34
iFridge
d’un nouveau message UserState, ces calculs sont effectués puis le filtre est
appliqué pour déterminer si le message doit être placé ou non dans l’espace des
tuples. Le filtre est définit par le bloc Backend qui l’envoie à la fin de son initialisation. Ce filtre est contenu dans la classe OurFilter.java et laisse passer
uniquement les messages dont la vitesse est inférieure à 18km/h.
Le reste du travail de ce bloc est essentiellement de transformer les messages du
type Message vers des messages GpsMessage et inversément. Cette fonctionnalité est assurée par des méthodes de la classe MessageParser.java.
3.4
3.4.1
Fridge
Architecture
Fig. 15 – Schéma du bloc Fridge
Le frigo est équipé d’une antenne RFID et tous les aliments ajoutés au frigo
doivent être équipés de tags. L’antenne permet de détecter si un aliment entre
ou sort du frigo et transmet l’événement au serveur. C’est le serveur sur la base
des informations contenues dans le base de donnée qui va déterminer le sens,
il va utiliser le champ IsIn de la table Item. Lorsqu’un évènement est généré,
si le champ est à faux alors cela signifie que l’élément est entré dans le frigo
et que le champ devra être mis à jour à la valeur vrai et inversément pour le
sens inverse. En connaissant le sens, le serveur pourra alors appeler la fonction
correspondante.
24/34
iFridge
3.4.2
Base de données
La base utilisée par le serveur permet de garder une sauvegarde des éléments
présents dans le frigo. Une table est nécessaire pour les éléments et une pour les
tags RFID.
Fig. 16 – Relation entre les tables dans la base de données pour le bloc Fridge
La permanence est un champ important pour les éléments car c’est lui qui
va déterminer si le frigo doit demander son achat lorsqu’il n’est plus disponible.
La base de donnée est gérée de manière à ce qu’elle ne contienne que les
éléments présents actuellement dans le frigo ou ceux qui ont été ajoutés à la
liste d’achat.
Lorsqu’un élément est ajouté au frigo, un tag lui est automatiquement attribué parmis les tags dispobiles. Nous avons utilisé un champ label plus facilement
utilisable pour les utilisateurs. Le label du tag auquel il est associé est retourné
à l’utilisateur. C’est à lui qu’incombe la charge de fixer le tag à l’élément avec
de l’introduire dans le frigo.
3.4.3
Serveur
Le serveur est évidemment la partie la plus importante. Il centralise les
fonctionnalités qui sont ensuite offertes à l’utilisateur. Nous avons démarré l’implémentation en utilisant le serveur d’applications. Ainsi plusieurs SessionBeans
ont été créé mais nous avons abandonné cette implémentation car le débuggage
était trop pénible et le serveur posait de nombreux problèmes pour se connecter
au space. Nous avons donc conservé le serveur d’application uniquement pour
fournir l’interface web. Le serveur est une application standalone et l’interface
web utilise cette application.
La partie très importante du serveur est l’interaction avec l’espace des tuples.
Le serveur va l’utiliser pour demander des éléments mais également pour recevoir les informations du backend. La création de message se fait très simplement
en créant une instance de la classe voulue, tous les messages étant définis précédemment. Un listener est créé pour chaque type de message que le serveur
pourrait recevoir. Le serveur définit pour chaque type de message une méthode
correspondante. Lorsque le thread lit un message il appelle cette méthode. Ce
sont ces méthodes qui implémentent le comportement du frigo.
25/34
iFridge
3.4.4
Interface Web
Nous avons utilisé des pages JSP associés à des tags, le tout déployé sur un
serveur d’applications. Les tags ont principalement accès à la base de donnée
pour y recueillir les informations nécessaire mais également au serveur pour
ajouter un élément et demander ainsi demander la création du message correspondant.
3.5
3.5.1
Backend
Architecture
La Figure 17 présente l’architecture du Backend tel qu’il a été implémenté
pour ce projet.
Fig. 17 – Schéma du bloc Backend
Une des fonctions les plus importantes du backend est la gestion de la localisation des utilisateurs. Si des éléments doivent être achetés il faut avertir
les utilisateurs lorsqu’ils se trouvent à proximité d’un magasin leur permettant
d’acheter au moins un des éléments. Cela nécessite de connaître à la fois la
position de l’utilisateur, celle des magasins et enfin de connaître quels sont les
éléments proposés par chaque magasin. De plus afin de filtrer les demandes,
nous avons conçu un système basé sur des aires. Les aires sont des cercles caractérisés par la position de leur centre et de leur rayon Ces aires sont définies de
manière à indiquer les zones d’intérêts. Chaque magasin du système sera ainsi
associé à une ou plusieurs aires et c’est en se basant sur ces aires que le système
va décider d’alerter ou non l’utilisateur. Grâce à ces aires, lorsque le système
alerte un utilisateur pour un achat, il a la certitude que l’utilisateur se trouve
au maximum à la valeur du diamètre du cercle. Il faut donc définir les aires
de manière réfléchie pour faciliterle travail de l’utilisateur. La figure ci-dessous
26/34
iFridge
présente un exemple présentant deux aires.
Fig. 18 – Représentation d’une zône dans la base de données
Deux aires ont été définies, les bâtiments 2 et 3 sont associés à l’aire 2 et le
bâtiment 1 à l’aire 1. Si on considère que tous les éléments sont disponibles dans
chaque bâtiment alors un utilisateur qui entre dans l’aire 2 recevra un message
l’invitant à acheter les éléments de la liste d’achats. Il aura ensuite le choix d’aller
dans le magasin qu’il désire, même dans une autre aire puisque la délimitation
est arbritraire et totalement transparente pour l’utilisateur. L’intérêt est de
pouvoir filtrer plus facilement les positions reçues pour l’utilisateur et d’assurer
qu’il trouve un magasin dans un certain rayon.
3.5.2
Base de donnée
Le Backend utilise plusieurs tables car ses fonctions sont plus étendues.
La première fonction consiste à gérer la liste des achats ce qui nécessite une
première table. Il doit ensuite gérer les positions. Cette fonction nécessite donc
de nombreuses informations qui sont toutes stockées dans les différentes tables.
La Figure 19 suivant présente les relations entre les différentes tables.
La table du sommet est la table des achats, elle reprend exactement les
champs définis par le message Item. Elle ne contient donc que les objets devant
être achetés, un objet y est ajouté lors d’un message ItemNeeded et est supprimé
lors d’un message ItemBought.
Ensuite les 4 tables principales représent respectivement la liste des noms
d’éléments supportés par le système, les bâtiments, les aires et enfin les utilisateur. La table knownItems sert à uniformiser les noms des objets ajoutés par
les utilisateurs. La table user représente les données des objets User et State.
Enfin les 3 tables intermédiaires permettent de lier respectivement les items
avec les bâtiments, les bâtiments et les aires et enfin les utilisateurs avec les
aires.
Le calcul des relations entre aires et bâtiments ou utilisateurs se fait automatiquement en fonctions des positions. Il est important de noter qu’il faut entrer
27/34
iFridge
Fig. 19 – Relations entre les tables de la base de données pour le bloc Backend
tout d’abord les aires. Lors de l’insertion d’une nouvelle aire, aucune relation
par rapport aux utilisateurs ou aux bâtiements n’est calculée. Par contre lorsqu’un bâtiment est ajouté les relations sont calculées de même lorsqu’un nouvel
état pour un utilisateur est reçu. Une requête spéciale est prévue pour fournir
les éléments disponibles dans une certaine aire pour un utilisateur particulier.
3.5.3
Serveur
Le serveur du bloc Backend a comme principale fonction la gestion des utilisateurs et de leur localisation. Mais il sert également de relais entre le bloc
Fridge et le bloc UserManager. La totalité des messages vont donc passer par le
Backend, il devra soit les transmettre plus loin soit y répondre directement. Pour
chaque type de message un listener est créé. La particularité du Backend est
qu’il peut recevoir des messages provenant de plusieurs modules, il faut donc
vérifier la provenance pour diriger correctement la requête. Grâce au modèle
donné au listener il est possible de filtrer les messages uniquement par rapport à
la destination. Ainsi le backend retire du space tous les messages dont le change
TO vaut BACKEND.
3.5.4
Interface Web
l’interface web tout comme pour le frigo est minimale. Elle permet simplement d’ajouter des aires, des bâtiments ou des utilisateurs de manière plus aisée
que d’entrer les commandes SQL.
28/34
iFridge
4
Tests
Les quatres blocs ont été testé indépendamment durant la phase de développement. Des tests réels mettant en place les éléments du scénario ont été
effectués avec tous les bloc et un utilisateur. La validité des coordonnées mesurées, ainsi que l’insertion de zones dans la base de données a été contrôlée à
l’aide de la base de géodonnées de l’office fédéral de topographie disponible en
ligne http://www.swisstopogeodata.ch/geodatenviewer/. Une dizaine d’ingrédient, plusieurs zônes ainsi que des bâtiments associés à des sous ensembles
d’ingrédients ont été insérés dans notre base de donnée.
Ces tests ont permis de valider toutes les fonctionnalités clef définies au Chapitre 2.2. Cependant notre GPS ne possédant pas d’antenne, offrait de faibles
performances. Une zone de couverture a due être trouvée et la stabilité des
coordonnées mesurées était mauvaise puisque sans bouger, les points variaient
d’environs deux mètres entre deux mesures. C’est pourquoi les optimisations
mises en oeuvre pour économiser la quantité d’information ne fonctionne pas de
manière optimale. Une solution à ce problème serait d’implémenter un simple
filtre sur les données, effectuant une moyenne sur les derniers points pour déterminer la valeur actuelle.
5
5.1
Conclusions
Développement
Ce projet a demandé la mise en oeuvre de nombreux éléments hétérogènes.
Cependant, l’architecture modulaire, reliée par un espace d’échange de tuples
pour gérer la communication s’est révélé très souple. Les phases de tests nous
ont permis d’apprécier cette souplesse permettant de redémarrer uniquement
les blocs défectueux ou à modifier, nous épargnant une perte de temps considérable. La coordination entre les blocs s’est déroulée uniquement en définissant
le format de messages (tuples) échangés. Cette technologie présente cependant
une difficulté pour le développement, en effet, il n’est pas possible d’accéder
simplement à la liste des tuples contenus dans l’espace.
Les caractéristiques limitées de la plateforme utilisée pour le téléphone rendent
le MIDlet portable, mais ont compliqué passablement le développement. L’utilisation d’un téléphone plus performant (Linux, J2ME CDC|CLDC1.1) aurait
permis d’utiliser JMatos de PsiNaptic [14], une implémentation de Jini pour
les terminaux mobiles, afin de connecter directement le terminal mobile à l’espace de tuples. La librairie de l’Université de Genève aurait pu être utilisée et
aurait offert un gain de temps considérable.
5.2
Fonctionnelles
Les fonctionnalités clef définies lors de la spécification ont toutes été implémentées et testées avec succès. La liste d’achat est gérée correctement par le
frigo et peut être mise à jour soit par une interface web, soit par le téléphone
mobile de chaque utilisateur. Les demandes d’achat contiennent les bons éléments et sont envoyées correctement à l’utilisateur lorsqu’il se trouve dans une
zone concernée. Le système gère correctement les cas ou l’utilisateur ne lui réTimothée Maret & Nicolas Martenet
29/34
iFridge
pond pas, et envoye correctement des alertes lorsqu’un élément sensible tarde à
être placé au frigo.
Dans cette implémentation, la représentation des aires contenant des bâtiments est très simple. Il serait possible de l’étendre la puissance de description
des aires par une description géométrique plus complexe tel qu’un polygone.
Les caractéristiques de ce prototypes nous paraissent particulièrement intéressantes, il serait possible d’adapter ce projet pour pour d’autres tâches demandant à être réparties entre plusieurs utilisateur de manière opportuniste.
5.3
Personnelles
Ce projet a été réalisé par un groupe de deux étudiants. Les blocs Backend et
Fridge ont été implémentés par Nicolas Martenet, tandis que les blocs UserManager
et MobilePhone ont été implémentés par Timothée Maret.
La spécification, le rapport, la présentation ainsi que la vidéo de démonstration
ont étés réalisé à part égale entre ces deux étudiants. Au final, ce projet a représenté environs 250 heures de travail personnel pour chacun des deux étudiants.
5.4
Perspectives
Ce projet a posé des bases et a abouti à un prototype fonctionnel. Il est
possible d’améliorer de nombreux points de l’implémentation ou d’augmenter
les fonctionnalités.
Concernant l’implémentation de la communication entre les bloc UserManager et UserMobile, le support de HTTP ou HTTPS devra être réalisé pour garantir
une portabilité de l’application. Pour la partie TCP, la solution mise en oeuvre
est relativement figée et demande certaines adaptation pour transférer d’autres
types de messages que ceux spécifiés. Une solution serait de rechercher une implémentation de ObjectOutputStream pour J2ME afin de pouvoir transférer tous
types de messages.
Les fonctionnalités du bloc Fridge sont restées volontairement sobres, cependant les extensions envisageables sont nombreuses, tel que la gestion de menus,
d’un agenda ou l’état de contenance des ingrédient.
Références
[1] Freeman, Hupfer, Arnold. JavaSpaces Principles, Patterns, and Practice.
Addison-Wesley, 1999.
[2] Glenn Baddeley. NMEA sentence information. [en ligne].
http://home.mira.net/~gnb/gps/nmea.html (02 décembre 2006).
[3] Jan Newmarch. Foundations of Jini 2 Programming. Apress, 2006.
[4] jScience Technologies. MathFP Fixed Point Integer Math. [en ligne].
http://mywebpages.comcast.net/ohommes/MathFP (7 novembre 2006).
[5] Ken Arnold, Robert Scheifler, Jim Waldo, Bryan O’Sullivan, Ann Wollrath.
The Jini Specification. Addison-Wesley, 1999.
[6] Mark Weiser. The Computer for the 21st Century. [en ligne].
http://www.ubiq.com/hypertext/weiser/SciAmDraft3.html (9 novembre 2006).
30/34
iFridge
[7] Martin de Jode. An Introduction to Programming the Java APIs for
Bluetooth Wireless Technology (JSR 82) on Symbian OS. [en ligne].
http://www.symbian.com/developer/techlib/papers/JABWT/JABWT_
1_0.pdf (26 novembre 2006).
[8] Martin de Jode. What Java developers need to know about MIDP on
Symbian OS. [en ligne].
developer.symbian.com/main/downloads/papers/midpjava/
WhatJavaDevelopersNeedToKnow_1.0.pdf (22 décembre 2006).
[9] Nokia Corporation. Known Issues In The Nokia 6600 MIDP 2.0 Implementation v1.7. [en ligne].
sw.nokia.com/id/94d3bcbe-41e3-4522-bc8e-d6c45948d9ce/Known_
Issues_In_The_Nokia_6600_v1_7_en.pdf (21 décembre 2006).
[10] Nokia Corporation. MIDP 2.0: Tutorial On Signed MIDlets. [en ligne].
http://www.forum.nokia.com (18 décembre 2006).
[11] Phidgets Inc. PhidgetRFID. [en ligne].
http://www.phidgets.com/documentation/1023.pdf
2006).
(11
novembre
[12] Prof. B. Hirsbrunner , Prof. P. Kropf, Dr V. Pallotta, M. Schiely, P. Bruegger. Ubiquitous Computing, Master Course. [en ligne].
http://diuf.unifr.ch/pai/uc/index.php (9 novembre 2006).
[13] Stéphan Velen, Christophe Praplan. Librairie Java pour l’utilisation d’un
récepteur GPS Bluetooth sur téléphone mobile. Master’s thesis, Université
de Genève, avril 2006.
http://www.universal-locator.com (03 décembre 2006).
[14] Steve Hashman, Steven Knudsen. PsiNaptic, The Application of JiniTM
Technology to Enhance the Delivery of Mobile Services. [en ligne].
http://www.sun.com/software/jini/whitepapers/PsiNapticMIDs.
pdf (7 novembre 2006).
[15] Sun Microsystems. Enhancements in JDK 5. [en ligne].
http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.
html (15 novembre 2006).
[16] Sun Microsystems. Jini Network Technology. [en ligne].
http://java.sun.com/developer/products/jini/ (15 novembre 2006).
[17] Symbian. Comprehensive List Of Symbian OS Error Codes. [en ligne].
http://www.symbian.com/developer/techlib/papers/error_codes/
ErrorCodesLatest.zip (16 décembre 2006).
A
Utilisation du programme
Chacun des modules ayant été développé avec NetBeans, vous trouverez dans
le répertoire code du CD, les quatres projets correspondant chacun à un module.
Ces projets peuvent êtres directement ouverts par NetBeans. Ils contiennent les
sources, les classes compilées, les librairies, ainsi que des scripts ANT permettant
de compiler et d’exécuter chacun des projets.
Les interfaces web sont également des projets NetBeans. Ce sont les projets se
terminant par Web, iFridgeWeb pour le module Fridge et iFridgeBackenWeb
31/34
iFridge
pour le module Backend. Le fichier war déployable se trouve pour chacun des
projets dans le répertoire dist. Ils peuvent être déployés sur le serveur soit en
utilisant NetBeans soit en utilisant la console du serveur.
A.1
Compilation
Pour compiler et créer un fichier jar exécutable des projets correspondant
aux modules Backend, Fridge et UserManager, il faut se placer le répertoire
code/<project> et utiliser la commande
ant jar
Pour le module MobilePhone, la commande suivante doit être utilisée depuis le
répertoire code/MobilePhone
ant deploy
A.2
Exécution
La première étape avant de lancer les différent modules est de démarrer
Jini et JavaSpaces. Ensuite, L’exécution des différents modules interconnectés
par l’espace de tuples peuvent se lancer dans un ordre quelconque et sur des
machines différentes car elles sont reliées entre elles par JavaSpaces.
A.2.1
Jini/JavaSpaces
L’installation de Jini fournit un exécutable qui va lancer les principaux
services, dont JavaSpaces. Cet utilitaire se trouve sous <repertoire d’installation de Jini>/installverify/Launch-All.
L’adresse de la machine sur laquelle s’exécute Jini va devoir être mise à jour
dans le code des différents modules, car la nous avons opté pour une recherche
de services Unicast.
A.2.2
UserManager
Ce module comporte un mini serveur TCP ouvert sur le port 9001 qui va
gérer les connection GPRS avec les téléphones mobiles. Ce port doit donc être
ouvert pour l’exécution 4 . La variable javaSpaceURL contenant l’adresse de
la machine exécutant Jini/JavaSpaces doit être mise à jour dans la classe
tcpserver.Server.java. Pour lancer ce module, il faut se placer dans le répertoire code/UserManager et lancer la commande suivante
ant run
A.2.3
Fridge
Ce module comprend un programme principal qui fait office de serveur pour
le frigo et également une interface web ainsi qu’une base de donnée. Le serveur
d’application de Sun doit donc être préalablement installé et le fichier war peut
être déployé. Il faut ensuite créer la base de donnée à l’aide du script SQL fourni
4 Il est aussi possible de modifier le port d’écoute spécifié dans la variable
TCP_LISTENING_PORT de la classe tcpserver.Server.java
32/34
iFridge
dans le répertoire lib, pour cela l’outil MySQL Administrator est particulièrement indiqué puisque l’option Restore permet d’exécuter facilement le script.
Le contenu de la table RFID sont disponibles dans cette sauvegarde, cependant
la table des éléments est vide.
La connexion à la base de donnée se fait grâce à JDBC, le nom JDBC est définit
dans le fichier ifridge.db.DBManagerBean.java. Dans notre cas il contient la
valeur jdbc:mysql://localhost/ifridge. De la même manière que pour le
bloc UserManager, l’URL du serveur exécutant JavaSpaces doit être mis à
jour dans le fichier ifridge.manager.ManagerBean.
Enfin il faut placer la librairie native phidgets dans le répertoire C:/WINDOWS/system32
L’interface web n’est pas obligatoire pour utiliser ce module, cependant
elle permet de simplifier les modifications de la base de données. Pour utiliser l’interface web du frigo, il faut tout d’abord déployer le fichier war du projet
iFridgeWeb comme expliqué précédemment. L’URL a utiliser dans un navigateur
web est http://nom_du_serveur/iFridgeWeb/ la page d’accueil sera automatiquement chargée.
A.2.4
Backend
Au niveau de l’exécution, ce module est très proche du bloc Fridge puisqu’il
nécessite également le serveur d’application pour déployer l’interface web. Un
script SQL est également disponible pour créer les différentes tables nécessaires.
Les données de test ont été conservées à l’exception des utilisateurs.
La variable pour la connexion à la base de donnée se trouve dans le fichier
backend.db.BackendDBManagerBean.java et celle pour JavaSpaces dans le
fichier backend.manager.BackendManagerBean.java.
L’interface web n’est pas obligatoire pour utiliser ce module, cependant
elle permet de simplifier la gestion de la base de données. Pour utiliser l’interface web du Backend, il faut tout d’abord déployer le fichier war du projet iFridgeBackendWeb comme expliqué précédemment. L’URL a utiliser dans
un navigateur web est http://nom_du_serveur/iFridgeBackendWeb/ la page
d’accueil sera automatiquement chargée.
A.2.5
MobilePhone
Avant la compilation, la variable SERVER_URL de la classe ifridge.IFridge.java doit être mise à jour avec l’adresse et le port d’écoute de la machine sur
laquelle s’exécute le bloc UserManager.
Après avoir transféré puis installé le MIDlet disponible sous dist/iFridgeMiddlet.jar sur le téléphone mobile, il faut modifier les droits d’accès aux ressources
du MIDlet afin qu’il puisse y accéder sans confirmation de l’utilisateur. Les paramètres à modifier sont les suivants
• Network access = Ask first time
• Connectivity = Always allowed
Ensuite, le GPS peut être démarré et enfin, le MIDlet nommé iFridge peut
être lancé.
33/34
iFridge
B
Liste des figures
Table des figures
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
C
Kit PhidgetRFID . . . . . . . . . . . . . . . . . . . . . . . . . . .
Use case de l’application . . . . . . . . . . . . . . . . . . . . . . .
Architecture générale du projet . . . . . . . . . . . . . . . . . . .
Messages échangés par les blocs de l’application . . . . . . . . . .
Structures de données de l’application . . . . . . . . . . . . . . .
Diagramme d’activité lors d’un événement RFID par le bloc Fridge
Diagramme d’activité à la réception d’un message ItemBought
par le bloc Fridge . . . . . . . . . . . . . . . . . . . . . . . . . .
Structogramme de la gestion des données de localisation par le
bloc Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Architecture du bloc MobilePhone . . . . . . . . . . . . . . . . .
Séquence lors de la connection au GPS . . . . . . . . . . . . . . .
Séquence lors de l’utilisation non spontanée du service . . . . . .
Séquence lors de l’utilisation spontanée du service . . . . . . . . .
Autoriser implicitement l’accès d’un MIDlet au réseau [10] . . . .
Schéma bloc du bloc UserManager . . . . . . . . . . . . . . . . .
Schéma du bloc Fridge . . . . . . . . . . . . . . . . . . . . . . . .
Relation entre les tables dans la base de données pour le bloc
Fridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Schéma du bloc Backend . . . . . . . . . . . . . . . . . . . . . .
Représentation d’une zône dans la base de données . . . . . . . .
Relations entre les tables de la base de données pour le bloc Backend
3
5
6
7
8
9
10
12
17
19
20
20
21
23
24
25
26
27
28
Contenu du CD
Le contenu du CD est réparti dans cinq répertoires principaux.
• code Contient les sources, les exécutables et la javadoc pour chacun des
quatre modules
• lib Contient les librairies et programmes externes utilisés pour le développement
• presentation Contient la présentation ainsi qu’un petit film présentant
le fonctionnement du système
• rapport Contient le présent rapport ainsi que ses sources LATEX
• references Contient la documentation citée dans les références
34/34

Rapport du projet iFridge - DIUF

Transcription

Documents pareils

Les convoyeurs attendent

Condizioni di prenotazione Caravan, Camper e

Rencontre avec les lycéens de la classe des allophones du lycée

NOUVEAUTÉS DISCOTHÈQUE MAI 2015

Version pdf - CRJ BOURGOGNE

Nos offres pour mobil-homes occasions 2015 A SORTIR BK Bluebird

renault mascott 110 td frigo

Visite du Vieux Montpellier → Une visite sera Parapente

Willerby Nos offres pour mobil-homes occasions 2015 A SORTIR BK