Implementation de flux c un environnement de ges ...

afternoonhandsomelySoftware and s/w Development

Nov 17, 2012 (4 years and 7 months ago)

321 views

Flux continus dans environnement pervasif Page 2
Sommaire

I. Présentation du Projet .................................................................................................................... 3
1. Contexte ...................................................................................................................................... 3
a) Environnement pervasif .......................................................................................................... 3
b) Le Projet Optimacs .................................................................................................................. 3
c) Le LIRIS ..................................................................................................................................... 4
2. Travaux précédents ..................................................................................................................... 4
a) L’API DataSource ..................................................................................................................... 5
b) L’implémentation précédente ................................................................................................. 5
3. Objectifs....................................................................................................................................... 7
c) Objectif principaux .................................................................................................................. 7
d) Objectifs secondaires .............................................................................................................. 8
II. Conception et mise en œuvre ......................................................................................................... 8
1. Environnement de travail ............................................................................................................ 8
2. Déroulement du projet ................................................................................................................ 9
3. Prise en main ............................................................................................................................. 10
4. Conception et Implémentation ................................................................................................. 10
5. Vérification et Elaboration d’un scénario .................................................................................. 12
a) Chronomètre ......................................................................................................................... 12
b) Elaboration d’un scénario : Antivol ....................................................................................... 14
c) Résultats ................................................................................................................................ 16
6. Autres Travaux ........................................................................................................................... 16
a) Mise aux normes du nouveau protocole............................................................................... 16
b) Refactorisation/Simplification ............................................................................................... 17
III. Conclusion ................................................................................................................................. 18
1. Aboutissement du projet........................................................................................................... 18
2. Retour d’expérience .................................................................................................................. 18
3. Suite du projet : ......................................................................................................................... 19
IV. Annexes : ................................................................................................................................... 20
1. Code d’un bundle simple : ......................................................................................................... 20
2. Tutoriel pour créer de nouveaux bundle :................................................................................. 22

Flux continus dans environnement pervasif Page 3
Remerciements
Je tiens à remercier mes encadrants Frédérique Laforest et Marian Scuturici. Je tiens aussi à
remercier très chaleureusement Yann Gripay pour sa disponibilité et ses conseils toujours bons.
I. Présentation du Projet

Nous sommes actuellement à la fin d’une révolution technologique majeure ayant concerné les
sciences de l’information et de la technologie. La première étape a été l’avènement de l’électronique
ayant automatisé le traitement de l’information. La seconde étape a été l’invention de liaisons
électroniques entre les différents ordinateurs traitant l’information. Ces liens n’étaient d’abord que
physiques et onéreux. Ils sont actuellement de tout types, notamment sans fils et de moins en moins
coûteux. Parallèlement, une standardisation des normes de communications (IP) est en train
d’apparaître malgré la différence des types d’informations communiquées (voix, vidéo, textes,
donnés, mesures). Les sources d’informations peuvent donc être multiples, et non plus seulement
humaines. Elles peuvent être ponctuelles, ou continues.
Il convenait donc d’organiser ces échanges entre sources et récepteurs de données en construisant
un protocole. Le projet Optimacs fournit un cadre pour l’organisation de ces échanges. Ma part de
travail dans ce projet consiste à implémenter et à tester les échanges en flux continus suivant le
protocole et l’API fournis.
1. Contexte

Pour bien comprendre les tenants et les aboutissants de ce projet, il convient de définir clairement
les différents éléments en jeu.
a) Environnement pervasif

Un environnement pervasif est un fonctionnement de communication où les objets communicants se
reconnaissent et se localisent automatiquement entre eux. Les objets doivent être capables de
communiquer entre eux à tout moment et sans intervention humaine. Un exemple type d’un
environnement pervasif est un réseau de capteurs pouvant s’auto gérer, et s’organiser afin de
transmettre une information. Ces capteurs peuvent être différents et néanmoins être tout à fait
capables de s’auto organiser afin de répondre à un besoin plus complexe où à une tâche plus globale.
b) Le Projet Optimacs

Ce PFE s’insère dans le projet Optimacs qui concerne les requêtes et la composition de service dans
les environnements pervasif. Ce projet est financé par l’Agence Nationale de la Recherche (ANR) et
s’effectue en collaboration avec le LIG de Grenoble et le LAMIH de Valenciennes ainsi que le LIRIS de
Lyon. Ce projet doit faciliter à terme le développement d’application pour environnement pervasif.
Flux continus dans environnement pervasif Page 4
Mon projet devait se conclure par une démonstration de mon travail lors d’une des rencontres
bisannuelle de bilan concernant l’avancement du projet. Ce projet se déroule de décembre 2009 à
2012.
c) Le LIRIS
Ce projet s’est déroulé dans le laboratoire LIRIS qui est commun au CNRS, à l’Insa Lyon, à Lyon 1, à
Lyon 2 ainsi qu’à Centrale Lyon. LIRIS signifie Laboratoire d’informatique en Image et Système
d’information. Inutile de dire que mon projet s’insérait plus dans la perspective « Système
d’information » qu’Image. J’appartenais à l’équipe « Base de données » dirigée par Jean-Marc Petit.
Ma tutrice était Frédérique Laforest, et j’ai aussi beaucoup travaillé et échangé avec Marian Scuturici
et Yann Gripay respectivement professeur et doctorant au LIRIS. Le rôle dévolu au LIRIS dans le projet
Optimacs est de développer une plateforme de tests et de benchmarks.

2. Travaux précédents

Marian Scuturici a formalisé un protocole REST permettant de régir les échanges de données via URL
et HTTP. Les deux élèves du département Télécom précédents, Thibault Blanc et Gaël Garcin ont
quant à eux développé une Architecture reposant sur OSGI et les WebServices permettant
d’implémenter les consignes données par Marian.
Flux continus dans environnement pervasif Page 5
a) L’API DataSource

L’API DataSpace est définie simplement par la phrase « Providing some tools to interact with
surrounding Data » [
http://ds.liris.cnrs.fr/pmwiki.php/Main/HomePage
]. Concrètement il offre un
cadre aux échanges de données entre sources et consommateurs de données via le protocole HTTP.
Des exemples permettent de mieux comprendre cet API. Voici une série de requêtes/réponses
définis dans ce protocole. Cette liste n’est pas exhaustive mais vise à comprendre des exemples de
base de ces échanges.
Requête

:
http://IP/

suivie de

Répons
e

Explication

datasource

/datasources

/Storage
/Time
Demande la liste des sources de
données disponible sur une machine.

Time
/
desc

Provides some time

related

information.
For example the local time, or a
chronometer.
Renvoie la description de

la source
de données.
Time
/
output

/outputs

/LocalTime
/Chrono
Affiche les différents flux continus de
données offert
Time
/
LocalTime
/
struct

/LocalTime

/ID:String
/Hour:int
/Minute:int
/Secondes:int
Envoie le format dans
le
quel

les
données seront transmises par le
flux.
Time
/
output
/
LocalTime
/
stream

Name:VGKEAK==

Hour:17
Minute:30
Secondes:12
Name : VGKEAK==
Hour:17
Minute:30
Secondes:13
Transmet

les données générées par
le flux en temps réel.
Les mots surlignés en bleu, représentent les mots clés utilisés dans le protocole. Ces mots sont fixes
et ne dépendent pas d’une source de donnée.
Les mots surlignés en jaune peuvent varier et identifient une source de donnée, ou de flux.
b) L’implémentation précédente

Les élèves précédents Thibault Blanc et Gaël Garcin ont fait la première partie de ce travail. Ils ont
développé une architecture basée sur OSGI et Java afin d’implémenter le protocole de l’API
DataSource.
La figure ci-dessous représente l’architecture développée précédemment. Les Data Sources qui
regroupent des services sous formes de Bundles OSGI peuvent s’enregistrer auprès d’un annuaire.
Flux continus dans environnement pervasif Page 6
Les Datasources partagent alors les différents services fournis avec cet annuaire au moment de leur
enregistrement. L’annuaire peut alors rendre possible la publication des services fournis. Entourés en
bleue sur le schéma, ce sont les parties que j’ai modifiées lors de ce projet. Elles ne concernent pas
directement tout le service d’annuaire et d’enregistrement, mais concernent la génération et
l’échange de données par les différents services.

Figure 1 Architecture globale à la fin du PFE repris. Les éléments encadrés ou soulignés en bleu sont les parties que j'ai
modifiées.
Concrètement lorsqu’on lance le projet précédent, Apache Felix, qui est une implémentation de la
plateforme de service OSGI, se lance en premier. L’annuaire de service est le premier Bundle lancé.
Les autres services, qui sont en fait des Datasource, se lancent ensuite et vont s’enregistrer auprès de
l’annuaire comme Source de données. Puis, le serveur Web répond aux requêtes, en s’interfaçant
entre d’un côté Felix, son annuaire et les DataSource, et de l’autre côté les consommateurs de
données qui effectuent les requêtes HTTP. Le Serveur Web peut donc lister les différents bundle
actifs d’OSGI, et effectuer des requêtes sur ces mêmes bundle. Tout les bundles implémentent une
même interface Java. Dans cette implémentation, la source était capable de répondre au
consommateur lorsque celui-ci demandait les descriptions de sources de données ou les
descriptions de commandes. Il pouvait aussi répondre au demande de format de données produites
Flux continus dans environnement pervasif Page 7
par les différentes réponses à des commandes. Et bien sûr cette implémentation pouvait aussi
retransmettre les résultats de commandes.
Le système exécute par exemple la séquence suivante : (Attention cette version ne respecte pas la
version actuelle de l’API Dataspace).
http://134.214.107.71:8080/math/command/bigFunction?a=23&b=-2&c
=5


Le système analyse l’URL fourni, et va exécuter la commande « BigFunction », du Bundle/Datasource
« Math » avec les paramètres 23, -2, 5.
3. Objectifs

Ma partie concernait plus spécifiquement les flux continus. Un flux continu est une source qui envoie
continuellement des données. Ces données peuvent être régulières et émises à une fréquence
donnée, ou aléatoires (émise lorsqu’un certain seuil est dépassé par exemple). Un bon exemple de
flux continu, est un capteur qui envoie la température toutes les minutes. Un autre exemple peut
être un accéléromètre qui envoie des données, seulement lorsque l’accélération varie.
Mon objectif principal était de fournir un prototype gérant les flux continus et permettant leur
production de manière simple. Néanmoins au fil du temps, je me suis rendu compte que j’avais
d’autres buts secondaires mais nécessaires pour ce projet.

c) Objectif principaux

Implémentation du mode « PUSH »
Mon travail consiste à reprendre le travail précédemment effectué et à y ajouter la possibilité de
transmettre un flux continu. Concrètement, un Bundle doit être capable de transmettre des
informations en mode « PUSH », et non plus « PULL » exclusivement. Je dois aussi valider
l’implémentation par une série de tests qui démontrent l’utilité des flux continus.
Conception d’un scénario de validation
Je dois aussi définir et implémenter un Scénario qui validera cet objectif. Le Choix du scénario est
libre, mais il doit valider la bonne implémentation de flux continus et montrer la pertinence d’utiliser
la plate forme Optimacs pour ce choix.
/sum

/26
/multiplication
/-230
/max
/23


Flux continus dans environnement pervasif Page 8
Démonstration à Valenciennes
Mon travail a aussi été présenté à la mi décembre aux équipes de Valenciennes et de Grenoble,
membres du projet Optimacs. J’ai dû expliquer mon travail, et leur montrer le bon fonctionnement
de mon implémentation via une démonstration de mon scénario.

d) Objectifs secondaires

Compatibilité avec la dernière version du protocole
Le protocole a évolué au cours du projet et était différent de celui fourni lors de l’implémentation
précédente. J’ai donc dû veiller à l’évolution de l’application afin de la maintenir compatible avec
l’API. J’ai dû effectuer des tests pour vérifier cette compatibilité.
Factorisation et simplification du code
Le projet doit être réutilisable par la suite. Je devais donc rendre le code lisible, le commenter, et
surtout le rendre le plus simple possible afin d’être étendu.
Production de documentation
Toujours dans le but de permettre la reprise de ce projet, j’ai dû produire de la documentation. Les
deux documents fournis sont les suivants :
-Tutoriel pour le lancement du projet, et surtout la création de nouveaux Bundles, ainsi que l’ajout de
méthodes et de flux continus (Stream) aux projets.
-Tutoriel pour le lancement de mon scénario principal de test.
II. Conception et mise en œuvre

Dans cette partie, je détaillerais mes solutions techniques proposées et implémentées afin de
répondre aux objectifs de ce PFE.
1. Environnement de travail

Ubuntu
Le projet a été développé sous Ubuntu 9.04.
NetBeans
NetBeans 6.8 a été utilisé avec les plug in Maven et SunSpot.
Flux continus dans environnement pervasif Page 9

Java
L’intégralité du projet fut réalisé en Java tout comme le projet que je reprenais
SunSpot
Les SunSpot sont des capteurs dotés de capacités de
communications sans fil et conçus par SUN. Ils sont construits
en faible quantité et valent 600$ par lot de deux SunSpot + une
base. Ces objets sont programmables très simplement en Java.
Le code est compilé sur un ordinateur puis envoyé vers le
SunSpot où il y sera exécuté. En cours de fonctionnement un
SunSpot peut communiquer avec une base, elle-même reliée à
un ordinateur, ou bien avec d’autres SunSpots. Les SunSpots
disposent de capteurs de température, d’accélération,
d’orientation et de luminosité. Ils peuvent aussi mesurer la
qualité du signal qu’ils reçoivent. Ils communiquent en sortie de
trois façons. Soit via leur 8 LED multicolores, soit par émission
de signal radio ou encore par transmission de données via un câble USB lorsque reliés à l’ordinateur.
J’ai eu quelques difficultés à faire fonctionner les SunSpot au début. La documentation n’est pas
encore très conséquente, et la gestion des SunSpot sans le plug in NetBeans fastidieuse. Néanmoins
générer un code pour les SunSpot est très simple et la gestion des connexions aussi. Après un temps
pour installer et connecter le SunSpot à la machine, le développement d’application peut se faire très
rapidement.
OSGI Service Platform
L’OSGI (Open Services Gateway initiative) est une plateforme de service basée sur le langage Java
qui peut être gérée de manière distante. Les différents services sont regroupés sous forme de Bundle
qui peuvent être installés, arrêtés, démarrés, mis à jour ou désinstallés de manière distante. La
gestion du cycle de vie est effectuée à travers une API. Le référentiel (registry) de services permet
aux bundles de détecter l’addition de nouveaux services ou la suppression de services. La plateforme
de Service OSGI, est donc parfaitement adaptée, aux environnements pervasifs.

2. Déroulement du projet

Voici le déroulement approximatif du projet par semaine. A noter que la rupture des semaines 8 et 9
est simplement due à une panne de machine. L’implémentation fût donc remplacée par la
production de documents.
Flux continus dans environnement pervasif Page 10

Figure 2 Diagramme de Gantt du projet

3. Prise en main

Les premières semaines du projet ont été consacrées à la prise en main du prototype. Le projet et les
exemples basiques (additions) simples étaient relativement faciles à prendre en main. Néanmoins
lorsqu’il s’agissait de créer un nouveau bundle, la situation était moins évidente et le code bien que
clair était peu commenté. Ceci ne devrait plus se reproduire car j’ai écrit un tutoriel afin de créer, je
l’espère plus simplement, de nouveaux bundles.
4. Conception et Implémentation

Mon implémentation principale a consisté en la création de Bundles capables d’envoyer des
informations en mode PUSH. Les données peuvent être produites par n’importe quel Thread, et
doivent être retransmises au Serveur Web.
Pour cela j’ai créé un objet intermédiaire(voir graph page suivante) , un StreamListener doté d’une
méthode qui appelée par le Thread permet la transmission des données produites au Bundle, puis au
Serveur et enfin au client. L’objet intermédiaire permet à plusieurs Thread d’écrire en même temps
des données qui iront au même client. Cet objet dispose en outre d’un constructeur qui prend en
argument la Socket sur laquelle les données sont écrites. Cet objet dispose aussi d’une méthode
permettant la fermeture de la connexion à l’initiative du Thread.
Flux continus dans environnement pervasif Page 11
Le cas type comme décrit sur la Figure suivante est lorsqu’un client veut récupérer des données en
temps réel. Il initie la connexion via une Socket du Serveur. Le client envoie ensuite la requête http,
qui contient le nom du flux voulu. Le Web Server analyse alors cette requête et va créer l’objet
StreamListener permettant la communication, ainsi que le Thread qui générera les données. Le
données générées par le Thread sont ensuite transmises au client via le StreamListener qui utilise lui-
même la socket du serveur.
Un cas particulier devait aussi être géré. Certains Thread peuvent envoyer des données à une
fréquence très faible. Par exemple une température peut être envoyée toutes les deux heures.
Pendant cette période le client peut décider de fermer la connexion. Pour cette raison, le serveur
doit en permanence vérifier que la connexion n’est pas fermée par le client, afin de ne pas maintenir
inutilement un StreamListener et de garder la main sur une Socket tant que des nouvelles données
ne sont pas envoyées.


Figure 3 Diagramme de séquence simplifié de requête d'un flux continus et de sa réponse

Flux continus dans environnement pervasif Page 12

Figure 4 Exemple de Code pour un flux continu jouant le rôle d'un chronomètre

5. Vérification et Elaboration d’un scénario

Deux types de tests ont été effectués lors du développement du projet. Le premier estsimples mais
vise à valider l’implémentation correcte du protocole via un simple Flux continu en envoyant un
Tuple de données toutes les secondes. Le second était plus complexe et visait à vérifier le bon
fonctionnement et la justesse du protocole dans un scénario plus large.
a) Chronomètre

Pour valider mon implémentation des flux continus, j’ai créé un Bundle qui possède un flux continu
faisant office de chronomètre en secondes. Lorsqu’on appelle ce flux, celui-ci envoie un Tuple avec
l’ID du flux, et le nombre de secondes écoulées depuis l’appel du flux, et ce, toutes les secondes.
J’ai testé ce flux de différentes manières. Pour le débogage avec l’outil NetCat, et pour la
vérification du contenu avec l’outil de réceptions des flux continus développé par Marian, et de
manière plus visuel, avec un navigateur Web.
Concrètement, le Bundle Chronomètre réagit de la manière suivante aux requêtes affichées en haut
dans le navigateur :
Flux continus dans environnement pervasif Page 14
b) Elaboration d’un scénario : Antivol

Ce scénario est utilisé pour montrer l’efficacité et la pertinence de l’implémentation d’Optimacs.
Optimacs a été conçu pour rendre les communications entre différentes sources de données plus
simples dans un environnement pervasif avec des flux de données continus. Le but de ce scénario est
de prouver qu’Optimacs est adapté à la gestion de flux continus, et que cette gestion est efficace.
But du Scénario
Un système d’alarme antivol est simulé dans ce scénario. L’antivol se place sur l’objet à protéger, et
est fixe par rapport à lui. Il détecte le mouvement de l’objet de deux façons, par mesure de
l’accélération, et de l’évolution de la position. Quand l’objet a bougé, un message est envoyé à la
personne qui a placé l’antivol. L’antivol se met aussi à clignoter.
Elément du système
- 1 SunSpot avec un accéléromètre intégré ainsi que des Led et un transmetteur ZigBee. Du
code Java peut être exécuté sur un SunSpot.
- 1 station de Base capable de mettre en liaison un ordinateur et un capteur SunSpot.
- 1 serveur central connecté à la station de base SunSpot. Optimacs, et un serveur web
s’exécutent sur ce serveur. Il gère tout les évènements générés par les autres éléments du
système.
- 1 client web (SmartPhone, Ordinateur), permettant d’activer ou de désactiver l’antivol à
distance.
Cas type:

Figure 8 Schéma simplifié du scénario
Pas de vol
Flux continus dans environnement pervasif Page 15
1. Un utilisateur veut protéger son ordinateur. Il place le SunSpot sur son ordinateur. Le SunSpot
doit être installé sur son ordinateur. Il va ensuite sur son SmartPhone, active le SunSpot qu’il a
placé sur son ordinateur et commence la supervision via une application Client Java.

2. La station de base commence à communiquer et à surveiller le SunSpot en temps réel. Il
évalue continuellement la qualité du lien entre lui et le SunSpot. Le SunSpot quant à lui
détectera en temps réel si une accélération s’effectue.

3. Le serveur central surveille en temps réel, les deux flux (accélération et qualité du lien).
Comme il n’y a pas de vol dans ce scénario, l’ordinateur surveillé n’est pas emporté et aucune
accélération n’est détectée par le Sun Spot. Néanmoins la qualité du lien entre le SunSpot et
la station de base peut évoluer. C’est pourquoi le serveur central vérifie que l’accélération et
la qualité du lien évolue en même temps afin de détecter les faux positifs.

4. A la fin du scénario, l’utilisateur veut reprendre son ordinateur. Il peut désactiver la
surveillance de son ordinateur afin de pouvoir le déplacer sans déclencher l’alarme.



Vol
1. Etape 1., 2., 3., du Scénario sans vol.
2. Le serveur central reçoit un message du SunSpot. La valeur de l’accélération a dépassé un
seuil. Le serveur central reçoit aussi un message de la station de base, lui disant que la qualité
de la liaison entre la base et le SunSpot est en train d’évoluer.
3. Le serveur central analyse les données sur quelques secondes. Si les deux flux (accélération et
qualité du lien) montrent que l’objet est en train d’évoluer, alors le serveur central déclenche
la procédure de vol. Un email est envoyé à l’utilisateur. Les LED sur le SunSpot se mettent à
clignoter.
4. Si tout se passe bien, le propriétaire peut rattraper le voleur.
Ce que cela prouve
-Production et consommation de flux continus
Dans ce scénario, des flux de données sont produits et consommés en permanence par un serveur
central via le protocole http.
-Agrégation de flux :
Une agrégation de donnée est effectuée car la décision de déclencher l’alarme ou non est basée sur
deux flux différents. Les flux sont donc tout les deux consommés et analysés. La décision est prise
juste après l’analyse des données.
-Contrôle à distance :
Les actions sont déclenchées à distance par le serveur central (clignotement des LEDs, envoi d’Email).
Flux continus dans environnement pervasif Page 16

Figure 9 Diagramme de déploiement du scénario

c) Résultats

Le Scénario fonctionnait et répondait comme prévu aux spécifications de tests. Le client pouvait se
déconnecter au milieu du flux sans que cela ne pose de problèmes au système OSGI. A noter que la
Fonction d’envoi d’email est déclenchée via une requête « commande » et non via un flux continu.
Ainsi les commandes ont aussi été testées et validées.
6. Autres Travaux

Bien que mon PFE fût d’abord consacré à l’implémentation des flux continus, une large partie de mon
travail a consisté à reprendre des parties de codes du communicationManager. Je devais maintenir à
jour le protocole avec les nouvelles améliorations apportées par Marian lors de l’évolution du
protocole. Le nouveau protocole développé par Marian réduisait en effet les ambigüités et simplifiait
la desérialisation des données.
a) Mise aux normes du nouveau protocole

Mon travail ne s’est pas limité à l’implémentation des flux continus. J’ai aussi dû mettre à jour le
système afin de le rendre compatible avec la nouvelle version du protocole de communication.
Flux continus dans environnement pervasif Page 17
Concrètement j’ai dû changer intégralement la manière dont le serveur Web répondait aux données.
La manière dont répond une source de données aux demandes de descriptions, de listage des
différentes commandes et flux ainsi que la manière d’exécuter les commandes étaient en effet
différentes dans le nouveau protocole. J’ai aussi essayé de rendre le code plus simple à maintenir si
le protocole change à nouveau.
Tout comme les échanges de données via un flux continu, j’ai aussi testé cette mise aux normes avec
Marian et son logiciel de référence.
Version originale du protocole (Juin 2009) Nouvelle Version (Octobre 2009)
http://192.168.0.123:8080/Math/command/compute/struct

Null

/Math/command/computer
/sum:real
/multiplication:real
/max:rea


http://192.168.0.123:8080/Math/command/compute?a=2&b=3

/sum

/5
/multiplication
/6
/max
/3
sum

:5

multiplication :6
max :3
Figure 10 Exemple d'évolution du code entre le protocole initial et le nouveau protocole

b) Refactorisation/Simplification

J’ai tenté de rendre plus simple la création de nouveaux Bundle, et surtout l’ajout de commande/flux
à ces Bundle. J’ai aussi extrait les méthodes qui pouvaient être communes à tous les bundles dans
une nouvelle classe, afin de garder le strict minimum dans les bundles et de permettre à tout
développeur de créer sans rien avoir à maîtriser de nouveaux bundles.
Le développeur de nouveaux bundles ne doit au final ajouter à un bundle que les informations
concernant les commandes, les structures de données, les flux, et le code de génération des résultats
de commandes et des flux continus.
Exemple de Code pour l’ajout des propriétés inhérentes au flux d’un bundle
/*----------------------------------------------------
*Add a new Stream to the Service
*----------------------------------------------------*/
//Stream to be added to the Datasource
StreamObject so = new StreamObject();
//Name of the stream
so.Name="time";
//Description of the stream
so.Description="Display the time since the thread has been launched";
//The format of the Tuple
String FieldName[] = {"Time"};//Name of the field
Format.Type FieldType[] = {Format.Type.real};//Type of the field
so.Format=new Format(FieldName,FieldType);
Flux continus dans environnement pervasif Page 18
//Add the DataSource to the StreamList
this.datasourceObject.StreamList.add(so);

III. Conclusion

1. Aboutissement du projet

Le projet a finalement débouché sur une démonstration à Valenciennes dans le cadre d’un séminaire
avec les deux autres entités (Grenoble et Valenciennes) participant au projet. La démonstration s’est
déroulée conformément à la procédure décrite dans le scénario.
Finalement le projet a presque autant concerné l’implémentation des flux continus dans un
environnement pervasif que la mise en conformité du projet au nouveau protocole et la
simplification/factorisation du code.
Il me semble maintenant, simple et rapide (de l’ordre de quelques minutes) grâce aux documents
fournis, de créer un nouveau Bundle, et d’y ajouter des commandes et des flux continus.
Les sources sont déposées sur un SVN, ainsi que les différents documents techniques. Le code est
commenté et documenté et devrait donc être exploitable facilement.
2. Retour d’expérience

Reprise d’un projet précédent
Dans ce projet j’ai dû reprendre un projet déjà existant et développé par des personnes que je n’ai
pas rencontrées. Ce type de projet est probablement très fréquent notamment au sein de la
recherche, mais probablement encore plus en entreprise. J’ai donc appris l’immersion dans un projet
afin de le prendre en main. Il convient de se documenter initialement sur l’ensemble des
technologies utilisées. Puis de fonctionner par méthode de couches successives afin d’apprendre le
fonctionnement d’un projet. Il faut en effet d’abord essayer de comprendre le fonctionnement
global, essayer de le faire tourner, puis rentrer de plus en plus dans les détails.
Développement et conception plus que des choix technologiques
Contrairement au projet précédent, mon travail était bien plus un travail de programmeur que
d’architecte dans le cadre de ce projet. Je n’avais pas de choix technique général ou d’architecture à
effectuer. Je devais surtout implémenter un protocole qui avait préalablement été conçu par Marian.
Les choix personnels que j’ai effectués en concertation avec les tuteurs se limitent globalement au
choix du Scénario. Tout le déroulement était quasiment dicté par nature dès le début et les choix à
faire se présentaient de manière linéaire et toujours sans grande rupture possible. Ce n’est pas une
critique, juste une constatation.
Flux continus dans environnement pervasif Page 19
Environnement libre
Mis à part pour la partie Bureautique, tous les logiciels que j’ai utilisés pour produire sont libres et
gratuits. (Netbeans, Ubuntu, Subversion, Gimp). Je me suis rendu compte que les produits libres
étaient très présents dans la recherche en général.
Travail autonome en collaboration plus que travail d’équipe
Etant seul sur ce projet, j’ai travaillé individuellement mais encadré par Marian et Yann. On ne peut
pas parler de travail d’équipe sur ce projet, car tout ce qui a été produit l’a été par moi-même.
Néanmoins j’ai reçu de nombreux conseils de la part de mes tuteurs qui m’ont guidé et orienté afin
de faire les bons choix.
Découverte des SunSpost
La découverte et la prise en main des SunSpots fût réellement quelque chose de ludique voire
d’amusant. J’ai vraiment été surpris par la facilité de prise en main de ces capteurs. Et bien que
n’étant pas forcément très fiable (notamment pour les mesures de températures), j’ai pris
néanmoins conscience des nombreuses applications permises par les réseaux de capteurs
interconnectés.
3. Suite du projet :

Le projet peut être repris et amélioré simplement avec les sources commentées et les tutoriaux.
Comme Grand axe d’amélioration, je vois les possibilités suivantes :
￿ Développement d’un outil pour la création automatique et simplifiée de nouveaux bundles.
Un bundle étant relativement simple, un plug in NetBeans pourra faire l’affaire. Ces
nouveaux bundles pourront être installés à chaud sur le système.
￿ Développement d’un outil de gestion des bundles et surtout des connexions entre Bundles
via des flux continus. On peut imaginer un outil de type LabView ou les fils constituent des
flux continus, et les carrés des bundles ou des méthodes/flux de bundles.
￿ Sécurisation des communications via un Encryptage avec gestion des certificats. Cet axe me
semble assez prioritaire, étant donné que n’importe qui peut se glisser au milieu du système.
￿ Composition des sources de données afin qu’une source de donnée puisse transmettre un
flux à une autre source, qui modifiera ou consommera ces données.


Finalement un système fonctionnel est aujourd’hui disponible et dispose de méthodes de
communication par commande et flux continus. Néanmoins il convient de rendre l’ajout de bundle
encore plus simple à développer et à gérer afin de permettre l’avancée du projet. La sécurisation des
communications me semble relativement simple à implémenter mais nécessaire.
Flux continus dans environnement pervasif Page 20
IV. Annexes :

1. Code d’un bundle simple :
Je présente ici, le fichier de base d’un Bundle qui s’occupe de la gestion des flux
et des commandes.
EmptyService.java
Classe ou sont repertoriés les propriétés inhérentes à un bundle ainsi que ses commandes et ses flux.
public class EmptyService extends ServiceClass implements ServiceIfc{
private Empty mbean;
/**
* Constructor. Create a new Bundle based on the BundleContext given by the
* Framework OSGI. Will also link the object to a JMX furnished by Felix.
* Also create the Method description.
* @param context
*/
public EmptyService (BundleContext context)
{
/*---------------------------------------------
* No change needed here
*--------------------------------------------- */
this.context = context;
this.mbean = new Empty (this);
this.datasourceObject = new DatasourceObject();
//This list contains all the information about the streams
this.datasourceObject.StreamList = new Vector<StreamObject>();
//This list contains all the information about the commands
this.datasourceObject.CommandList = new Vector<CommandObject>();
/*---------------------------------------------
* To be modified
* -------------------------------------------- */

// Put your service Name here
this.ServiceName = "Empty";
//Description of the DataSource
this.datasourceObject.DataSourceDescription="This datasource is simply used as a test bundle";
/*----------------------------------------------------
*Add a new Stream to the Service
*----------------------------------------------------*/
//Stream to be added to the Datasource
StreamObject so = new StreamObject();
//Name of the stream
so.Name="time";
//Description of the stream
so.Description="Display the time since the thread has been launched";
//The format of the Tuple
String FieldName[] = {"Time"};//Name of the field
Format.Type FieldType[] = {Format.Type.real};//Type of the field
so.Format=new Format(FieldName,FieldType);
//Add the DataSource to the StreamList
Flux continus dans environnement pervasif Page 21
this.datasourceObject.StreamList.add(so);
/*----------------------------------------------------
*Add a new Command to the Service
*----------------------------------------------------*/
//Create a newcommand object
CommandObject co = new CommandObject();
//Name of the command
co.Name="hello";
//Number of parameters
co.ParamNumber=0;
//FieldName of the Answer
String FieldName2[] = {"Hello World"};
//FieldType of the Answer
Format.Type FieldType2[] = {Format.Type.string};
//Add the out format to the command object
co.OutFormat = new Format(FieldName2,FieldType2);
//Parameters
co.Display=true; //Data to be displayed or processed (base64 encoded)
co.Sync=true;
//Description of the function
co.Description="This function only displays Hello World";
//Add the commandObject to the service command list
this.datasourceObject.CommandList.add(co);

// Setting port used by servlets*/
this.setPort(8080);
}
/*------------------------------------------------------------------------
* Command and Stream (output) code
*------------------------------------------------------------------------*/
//This function will be called when a function need to be executed
public String executeCommand(String commandName, HttpServletRequest req ){
Tuple t=null;
CommandObject cof=null;
String resp = new String();
boolean commandFound = false;
for(CommandObject co : this.datasourceObject.CommandList){
if(co.Name.equalsIgnoreCase(commandName)){
cof=co;
commandFound = true;
}
}
if(commandFound == false){
return "Error this command does not exist in the bundle";
}
if(cof.Name.equalsIgnoreCase("hello")){
//Put your fonction code here
Object[] Resp={"String"};
Data d = new Data(Resp);
System.out.println("I send the response"+d.toString());
System.out.println("");
if(cof.Display==false){
resp=new Tuple(this.getCommandFormat("hello"),d).TupleToString();
Flux continus dans environnement pervasif Page 22
}else{
resp=new Tuple(this.getCommandFormat("hello"),d).TupleToStringwithoutEncoding();
}
}else if(cof.Name.equalsIgnoreCase("otherFunction")){
//Code to be added here for another command
}
return resp;
}

@Override
public void subscribeStream(StreamListenerHandler slh, String streamName) throws StreamNotFoundException,
ArgumentException {
System.out.println(" A client is subscribing to the stream "+streamName);
if(streamName.equals("time")){
//Put the Thread here
Thread ets= new EmptyTimeStream(slh,this);
ets.start();
}else if(streamName.equals("OtherStreamName")){
//Code to be added for another Stream
}else{
try {
//Stream not found
slh.handleStreamEventString("Error", "Error : This Stream can not be found in this bundle");
slh.closeConnection();
} catch (IOException ex) {
Logger.getLogger(EmptyService.class.getName()).log(Level.SEVERE, null, ex);
}
}
}
}

2. Tutoriel pour créer de nouveaux bundle :

Eléments nécessaire :
- Netbeans 6.5.1
- Plug In Netbeans : Maven
Afin de faciliter la création de nouveaux Bundles, on partira à partir d’un Bundle déjà existant que
l’on modifiera et adaptera.
1. Importer le Projet via Netbeans

Récupérer les sources du projet.
Dans Netbeans :
File -> Open Project -> Emplacement du projet
-Sélectionner le projet principal (Optimacs).
Flux continus dans environnement pervasif Page 23
Le projet principal contenant les différents Bundle doit s'ouvrir. Vous pouvez explorer un Bundle en
double cliquant sur celui ci. Ce Bundle apparaîtra alors en tant que nouveau sous projet et les
sources seront visibles.
2. Copier le Bundle « [Optimcas] DS- Empty » afin d’en créer un nouveau

Dans cette partie nous copions le sous-projet Empty, qui est en fait un bundle Maven de base et vide.
Ce projet peut servir d'exemple. Il ne comporte que 1 commande et 1 Stream.
-La commande hello qui renvoit : Answer : Hello World
-Le Stream (flux continu) Time qui est un simple chronomètre en seconde.

-Pour copier le projet avec Netbeans : Clic Droit-> Copy project
-Spécifier le nouveau nom du projet ( fr.cnrs.lirs.optimacs.datasource.logical.empty2 par
exemple).Spécifier aussi le nouvel emplacement du Bundle.

Il faut maintenant renommer certains éléments du nouveau Bundle. On va passer de empty à
empty2 dans notre exemple. L’image suivante résume tout les fichiers à renommer ou à modifier.


-Clic droit sur le projet Maven nouvellement créé -> Properties -> Dans le champ artifactID,
remplacer empty, par empty2. Changer aussi le nom du Bundle(champ Name) en Empty2.
Dans les deux packages appartenant au sous projet DS-Empty, remplacer via la refactorisation
(Crtl+R), empty par empty2.
Dans le fichier Pom.xml, changer les trois lignes suivantes en remplacant empty par empty2 :
<Bundle-Activator>fr.cnrs.liris.optimacs.dscontainer.datasource.logical.empty.Empty</Bundle-Activator>
<Private-Package>fr.cnrs.liris.optimacs.dscontainer.datasource.logical.empty</Private-Package>
<Export-Package>fr.cnrs.liris.optimacs.dscontainer.datasource.logical.empty.service</Export-Package>

Devient :
Flux continus dans environnement pervasif Page 24
<Bundle-Activator>fr.cnrs.liris.optimacs.dscontainer.datasource.logical.empty2.Empty2</Bundle-Activator>
<Private-Package>fr.cnrs.liris.optimacs.dscontainer.datasource.logical.empty2</Private-Package>
<Export-Package>fr.cnrs.liris.optimacs.dscontainer.datasource.logical.empty2.service</Export-Package>
Refactoriser tout les fichier .java du sous projet en remplaçant Empty par Empty2

3. Description de la datasource

Compléter les objets suivants afin de décrire votre bundle et ses méthodes/flux. Les commentaires
du code sont assez explicites.
Fichier : EmptyService.java
Nom de la datasource :
// Put your service Name here
this.ServiceName = "Empty";

Un nouvel objet (datasourceObject) est créé afin de posséder les attributs du projet. Ajouter lui la
description de la source de donnée. this.datasourceObject = new DatasourceObject();
this.datasourceObject.DataSourceDescription="This datasource can
provides all the data geneterated by a SunSpot";

4. Ajout de commandes

L'ajout de commande au service se fait en deux étapes.
Fichier : EmptyService.java
On créé d'abord un objet (CommandObject), qui contient tout les paramètres de la commande
excepté le Code.
//Create a new object
CommandObject co = new CommandObject();
//Name of the command
co.Name="hello";
//Number of parameters
co.ParamNumber=0;
//FieldName of the Answer
String FieldName2[] = {"Hello World"};
//FieldType of the Answer
Format.Type FieldType2[] = {Format.Type.string};
//Add the out format to the command object
co.OutFormat = new Format(FieldName2,FieldType2);
//Parameters
co.Display=true;
Flux continus dans environnement pervasif Page 25
co.Sync=true;
//Description of the function
co.Description="This function only displays Hello World";
//Add the commandObject to the service command list
this.datasourceObject.CommandList.add(co);

On ajoute ensuite le Code dans la fonction executeCommand:
L'objet Resp est la réponse qui sera renvoyé au client, ayant demandé l'exécution de la commande.
L'objet Resp doit correspondre au format définit lors de la phase précédente.
if(cof.Name.equalsIgnoreCase("hello")){
//Put your fonction code here
Object[] Resp={"Hellow World"};
Data d = new Data(Resp);
System.out.println("I send the response"+d.toString());
System.out.println("");
if(cof.Display==false){
resp=new
Tuple(this.getCommandFormat("test"),d).TupleToString();
}else{
resp=new
Tuple(this.getCommandFormat("test"),d).TupleToStringwithoutEncoding();
}
}

5. Ajout de flux continus (output)

Le stream a pour but de renvoyer des informations au client en mode Push. Alors que pour la
commande, l'information arrive quand le client le décide, pour les stream l'information arrive quand
l'émetteur le décide.
La toute première étape consiste à compléter le fichier EmptyService.java, afin de rentrer les
informations qui concernent le stream.
Fichier : EmptyService.java
/*----------------------------------------------------
*Add a new Stream to the Service
*----------------------------------------------------*/
//Stream to be added to the Datasource
StreamObject so = new StreamObject();
//Name of the stream
so.Name="time";
//Description of the stream
so.Description="Display the time since the thread has been launched";
//The format of the Tuple
String FieldName[] = {"Time"};//Name of the field
Format.Type FieldType[] = {Format.Type.real};//Type of the field
so.Format=new Format(FieldName,FieldType);
//Add the DataSource to the StreamList
Flux continus dans environnement pervasif Page 26
this.datasourceObject.StreamList.add(so);

La seconde étape consiste à créer un Thread qui enverra les données via un StreamListener :
Fichier : EmptyTimeStream.java
@Override
public void run() {
System.out.println("Time Thread");
Format format = this.s.getStreamFormat(this.STREAM_NAME);

System.out.println("Connection opened");
System.out.println("Start to recieve the data");
for(int i=0;i<100;i++){
try {
this.sleep(1000);
} catch (InterruptedException ex) {

Logger.getLogger(EmptyTimeStream.class.getName()).log(Level.SEVERE, null,
ex);
} Object[] value={i};
Data data = new Data(value);
Tuple tp = new Tuple(format,data);
System.out.println("Sending to the Client :
"+tp.TupleToStringwithoutEncoding());
try{

slh.handleStreamEventString("time",tp.TupleToStringwithoutEncoding());
}catch(Exception e){

}
}
System.out.println("Stream dying");
try {
slh.closeConnection();
} catch (IOException ex) {

Logger.getLogger(EmptyTimeStream.class.getName()).log(Level.SEVERE, null,
ex);
}

}

On modifie ensuite la méthode suscribeStream du fichier EmptyService, afin d’y ajouter le Thread
EmtpyTimeStream qui s’occupera de générer des données en se servant du StreamListenerHandler

Fichier : EmptyService.java

public void subscribeStream(StreamListenerHandler slh, String streamName)
throws StreamNotFoundException, ArgumentException {
System.out.println(" A client is subscribing to the stream
"+streamName);
Flux continus dans environnement pervasif Page 27
if(streamName.equals("time")){
//Put the Thread here
Thread ets= new EmptyTimeStream(slh,this);
ets.start();
}else{
//Stream not found
}
StreamListenerHandler slh;
ServiceIfc s;
String STREAM_NAME = "time";
public EmptyTimeStream(StreamListenerHandler slh,ServiceIfc s) {
this.slh=slh;
this.s=s;
}

6. Compilation du bundle/projet

Il suffit simplement de compiler le Bundle en faisant :
-Clic droit sur le nom du Bundle -> Clean and Build

7. Ajout du Bundle au script de lancement.

Il faut indiquer au script de lancement OSGI l'emplacement du Bundle, qui est sous forme d'un fichier
Jar. L'emplacement de compilation du bundle Jar, peut être modifié depuis Netbeans via Clic Droit ->
Properties.
Pour le bundle empty, on ajoute par exemple la commande suivante au fichier conf.dscontainer:
file:${optimacsRootDir}/fr.cnrs.liris.optimacs.dscontainer.datasource.logical.empty/fr.cnrs.liris:fr.cnrs
.liris.optimacs.dscontainer.datasource.physical.sunspot2:bundle:0.1-
SNAPSHOT/target/fr.cnrs.liris.optimacs.dscontainer.datasource.logical.empty-0.1-SNAPSHOT.jar \

8. Lancement

Il suffit de lancer le script dscontainer.sh via :
./dscontainer.sh