La passerelle résidentielle H-Omega [Bourcier2007], qui est issue du projet européen
ANSO16, a pour objectif la livraison de services domotiques dans la maison. Un des
intérêts principaux d’H-Omega réside dans sa capacité à intégrer des services et
dispositifs hétérogènes (cf.
Figure 57). Pour cela, la passerelle utilise un composant appelé Remote Service
Manager, devenu aujourd’hui le gestionnaire de services distribués ROSE. Le serveur
d’applications domestique H-Omega est construit sur la plate-forme OSGi et le modèle à
composants iPOJO.
Les applications déployées sur H-Omega peuvent concerner aussi bien le contrôle de la
maison (réglage de la lumière, ouverture et fermeture des volets, verrouillage des portes,
etc) que des services externes (service web météo agrégé sur la passerelle) ou des
applications spécifiques à un domaine tel que le divertissement multimédia (utilisant des
équipements UPnP AV par exemple) ou l’hospitalisation et le maintien à domicile (HAD et
MAD).
UPnP DPWS Passerelle H-Omega Remote Service Manager / ROSE Remote Service Manager / ROSE OSGi ROSE ROSE Internet Services web Applications Service & device proxiesFigure 57. H-Omega agrège des services distribués grâce au Remote Service Manager.
VIII.4.1 Remote Service Manager
Le Remote Service Manager de H-Omega utilise un composant appelé Proxy Selector
qui définit la stratégie de sélection des mandataires (proxy) découverts. Si
l’administrateur souhaite modifier la stratégie, il doit modifier le composant Proxy
Selector et mettre à jour le bundle correspondant. Par exemple s’il est nécessaire
d’économiser l’espace disponible sur la passerelle, il est préférable de suivre une stratégie
qui prône la réutilisation de mandataires existants déjà présents sur la passerelle.
Toutefois, l’interruption du Proxy Selector déclenche l’arrêt du Remote Service
Manager, puisque ce dernier requiert le service du Proxy Selector auquel il est lié par une
politique de liaison dynamique. Or si le Remote Service Manager est arrêté, le composant
gérant les instances de service « mandataires » est lui aussi désactivé et détruit les
instances de mandataires. Par conséquent, les applications utilisant des services distants
(externes à la passerelle) seront elles-aussi temporairement désactivé, le temps que le
Remote Service Manager soit de nouveau disponible et que les mandataires soient recréés
et republient leurs services. Dans cette situation, l’utilisation d’une politique tolérante aux
interruptions (temporelle ou DSLA) est particulièrement recommandée.
VIII.4.2 Application médicale
Nous avons également validé notre approche dans un scénario multi-fournisseurs où la
substitution n’est pas souhaitable en cas d’interruption. Une application médicale d’HAD
(Hospitalisation à Domicile) ou de MAD (Maintien à Domicile) permet d’assurer le suivi
des patients et d’envoyer des rapports périodiques au médecin en charge du patient.
L’application décrite Figure 58 utilise les données issues de capteurs médicaux (montre
cardiogramme-podomètre, glucomètre, accéléromètre de SunSPOT pour le suivi
d’activité, etc) pour générer un rapport médical. Les données sont sauvegardées à
intervalles réguliers, puis intégrées au rapport qui est transmis périodiquement à l’hôpital
(toutes les 12 heures).
Pour cela, la passerelle H-Omega propose un gestionnaire de persistance, le Persistence
Manager basé sur le canevas Apache Cayenne. Ce gestionnaire instancie (en utilisant le
patron de conception Extender Model d’OSGi) des services de persistance ObjectContext
propres à une classe/modèle de données, ici une classe de représentation d’un rapport
médical. Ces services peuvent être liés à différentes sources de données. Dans l’exemple
traité, deux instances de service de persistance propre au rapport médical sont
disponibles. L’une est connectée à une base de données MySQL distante, tandis que
l’autre utilise le mécanisme de sauvegarde locale EmbeddedDriver fourni par Apache
Derby.
Par souci de cohérence il est préférable de stocker toutes les données dans la même
base, puisque les informations sont récupérées au moment de la génération du rapport
sont. Donc si la base de données distante n’est plus disponible, plutôt que d’effectuer une
substitution et sauvegarder les informations sur l’autre source de données, notre politique
DSLA privilégie la relation client-fournisseur et conserve la liaison avec BDD distante. La
sauvegarde est simplement « mise en pause », et une fois que la BDD redevient
disponible, les données sont persistées. Toutefois, si le service de persistance lié à la BDD
distante ne revient pas dans un délai raisonnable, l’application utilisera le second service.
De plus, cette stratégie permet d’économiser l’espace disponible sur la passerelle, qui est
souvent une ressource limitée.
Medical Sensors Persistence Manager (Cayenne) Persistence Manager (Cayenne) Medical application Medical application Local storage Remote DB
Sendmedical report
Save medical data
Figure 58. Application médicale utilisant la persistance d'H-Omega
Notre politique est également intéressante au niveau du service utilisé pour l’envoi des
rapports médicaux. Selon l’implémentation du service, l’envoi peut se faire par mail, ou en
utilisant un service web de l’hôpital pour que les données soient intégrées
automatiquement au système d’information de ce dernier. Or le service web utilisé pour
l’envoi de rapports est lié à un médecin, un service ou un hôpital particulier. Par
conséquent, si un médecin n’est pas disponible, le rapport peut être envoyé à un de ses
collègues, ou à un autre service/hôpital, c’est-à-dire à un autre fournisseur de service.
C’est effectivement ce qui se passerait avec les politiques dynamiques ou temporelles
d’iPOJO qui reconfigureraient les liaisons de l’application médicale. Cependant, comme le
rapport n’est émis qu’à des intervalles de temps espacés de 12 heures, une interruption
entre ces intervalles n’est pas gênante et il est donc inutile de modifier le destinataire des
rapports.
Chapitre IX
Perspectives et Conclusion
“L'échec est la voie du succès; chaque erreur nous apprend quelque chose.” Morihei Ueshiba, fondateur de l’Aïkido
Dans ce document nous avons présenté une approche basée sur les accords de niveau de
service pour la mise en œuvre d’une politique d’adaptation tolérante aux interruptions de
services. L’idée directrice de cette proposition est d’offrir un compromis entre la stabilité
de l’approche statique et la capacité d’adaptation offerte par l’approche dynamique.
Ce chapitre de conclusion est l’occasion de revenir sur le travail mené durant cette thèse
et d’y porter un regard rétrospectif. Avec le recul, les points forts, mais aussi les limites, de
ce travail apparaissent plus clairement, et plusieurs perspectives de recherche se
dessinent. Ces perspectives se placent aussi bien dans la continuité directe de cette thèse
que sur des thèmes connexes abordés au fil des réflexions.
Il faut également garder à l’esprit qu’au commencement de cette thèse des éléments
décrits dans ce manuscrit n’existaient pas encore et sont apparus en cours de route, voire
à la fin. C’est le cas des politiques de liaisons temporelles qui poursuivent un objectif
similaire au notre, ou encore des contextes applicatifs tels que le cloud computing ou
l’informatique verte qui ont confirmé la réalité de la problématique abordée, et donc
l’intérêt de notre proposition.
Dans le document
Politique de Liaison aux Services Intermittents dirigée par les Accords de Niveau de Service
(Page 167-171)