La domotique

Les plateformes dynamiques de services

Une plate-forme de services permet le déploiement de services, et gère la communication entre eux, mais cela de manière centralisée. Tous les services seront présents sur la même passerelle, ceci permettant une communication plus rapide entre eux. Mais cette passerelle est ouverte vers l'extérieur, et peut quand même communiquer via un réseau. Par exemple un service HTTP propose une interface qui permet par exemple d'administrer la plate-forme via un navigateur web. Un autre service peut par exemple offrir la possibilité de visionner les données livrées par des caméras connectées à la passerelle.

Un service peut en requérir d'autres. Par exemple le service visualisation peut fournir une interface web publiant les images des caméras. Ce service a besoin du service HTTP et du service camera pour fonctionner.

Une plate-forme de services doit permettre d'installer, de mettre à jour et de retirer ces services de façon dynamique également, c’est-à-dire que ces opérations doivent être possibles « à chaud » Les plates-formes de services sont très intéressantes pour les architectures à plugins.

Dans ce site nous allons présenter les spécifications OSGi et UPnP qui permettent de mettre en place des plateformes de services dynamiques. Mais il existe d'autres systèmes que nous ne traiterons pas dans cette partie : OpenWings, JINI...

Présentation d'OSGi
OSGi s'ignifie : Open Services Gateway initiative. Il s'agit d'une norme définissant des plateformes de service accessibles par des appareils qui y sont connectés. Elle définit un canevas dynamique de déploiement et d’exécution de services Java. Les plateformes définies par cette norme sont administrable à distance. Il existe de plusieurs moyens pour exposer les services sur ces plateformes (HTTP, Corba, Web Services...). Les cibles principales sont les réseaux des voitures et domestiques. Il va ainsi être possible de créer des passerelles domestiques en utilisant OSGi. L'utilisation de plate-forme de services à l'intérieur du domicile permet son contrôle à distance. Des prestataires de services installent, de façon dynamique, sans arrêt des autres services, des fonctionnalités sur la passerelle pour, par exemple, effectuer des diagnostics de panne des appareils électroménagers, augmenter la sécurité du domicile (contrôle des caméras), ou médicaliser l'habitat (moniteur cardiaque.

Architecture OSGi
On peut représenter le framework OSGi, comme une couche logicielle dans laquelle vient se brancher les bundles. Cette couche logicielle s'exécute sur la plate forme Java (MachineVirtuelle Java).

Développement de services
Les services sont livrés sur la plateforme d’execution sous forme de fichier *.jar contenant : les bundles Un bundle contient un ou plusieurs services. Il peut en proposer et en requérir d'autres. C'est le framework qui a en charge la gestion des dépendances entre services et la gestion de leur cycle de vie, c'est à dire qu'il doit contrôler l'installation, la mise à jour et le retrait de bundles de manière dynamique. Sur la plateforme, les états du bundle peuvent être : INSTALLED, RESOLVED, STARTING, ACTIVE, STOPPING, UNINSTALLED.

Un bundle contient un ensemble de classes et de ressources qui vont permettre de fournir les services qu'il déclare. Une implémentation de l'interface BundleActivator va permettre de gérer l'activation et la désactivation du Bundle à travers les méthodes start() et stop() ce cette interface. Ces méthodes reçoivent en paramètre une référence du contexte du Bundle dans la plateforme : BundleContext. Le BundleContext permet d'enregistrer les services dans l'annuaire interne de la plateforme, rechercher des services dans cet annuaire, libérer des services quand ils ne sont plus utilisés, sourscrire aux évènements du Framework.

Exemple OSGi en domotique
La passerelle est administrée par un opérateur. Ce dernier autorise le déploiement de services fournis par les fournisseurs de services qui se partagent ainsi la passerelle et définit les règles de partage des ressources. Ces services sont généralement liés aux équipements du réseau privé dont ils exploitent les données enfouies et agissent sur les fonctions. Pour des questions de sécurité, l'operateur s’assure que les équipements éventuellement lies a un fournisseur (compteur électrique du distributeur d’électricité, moniteur cardiaque de l’hôpital, cameras et centrale d'alarme de la société de gardiennage) ne peuvent être utilises que par les services de ce fournisseur.

Les services (et leurs fournisseurs) peuvent coopérer entre eux dans l’élaboration de services plus complexes. Par exemple, en cas de malaise détecté par le moniteur cardiaque, l’hôpital peut récupérer le flux vidéo des cameras prises par la société de gardiennage. Les services déployés interagissent également avec les serveurs des fournisseurs. L'interaction peut être a l'initiative du serveur ou de la passerelle. Par exemple, le serveur du distributeur d’électricité procède a un télé-relevé en contactant le service connecte au compteur électrique. L'autre exemple est celui du service pilotant le moniteur cardiaque. Si ce dernier détecte une défaillance du cœur du patient, il contacte le serveur de l’hôpital qui dépêche aussitôt une équipe de secours.

Implémentations OSGi

• Pour les implémentation commerciales On remarque la présente des grands de l'industrie : ProSyst Software mBedded Server, Samsung OSGi R4 Solution, KT OSGi Service Platform (KOSP) HitachiSoft SuperJ Engine Framework IBM SMF (Service Management Framework)
• En Open Source, on également de grands acteurs. OSCAR et Apache Felix Eclipse Equinox Makewave Knopflerfish Pro
  Notons la présenc d'Eclipse qui utilise la norme OSGi pour développer la gestion de ses plugins depuis la version 3.2.
• Dans le monde .NET également, il y a eu des tentatives d'implémentations dont la principale a été fournie par Microsoft. Mais d'autres implémentations existent comme Mono et un projet de portage de OSCAR vers .Net

Dans les chapites suivant, nous allons voir les trois principales méthodes d'accès aux services :

• Le registry d’OSGi qu'on a vu plus haut avec l'utilisation du BundleContext pour publier les services. Le problème avec ce mode de publication, c'est que seuls les bundle présents dans la plateforme accèdent à ce registre.
• UPnP où tous les équipements du réseau local pourront accéder aux bundles
• OMG DDS qui est surtout utilisé en immotique.Les bundles sont exposés à l’échelle d’une usine, d’un hôpital, d’une ville
Il existe par ailleurs d'autres méthodes pour la publication des services. Il s'agit de services spécifiés par OSGi : HTTP Service et Corba Services.

UPnP

Présentation d'UPnP
L’Universal Plug and Play (UPnP) est un protocole réseau promulgué par l'UPnP Forum. Le but de l'UPnP est de permettre à des périphériques de se connecter aisément et de simplifier l'implémentation de réseaux à la maison (partages de fichiers, communications, divertissements) ou dans les entreprises. UPnP le permet en définissant et en publiant les protocoles de commande UPnP au-dessus des standards de communication de l'Internet. Le terme UPnP est dérivé de Plug and Play, une technologie pour attacher dynamiquement les périphériques à l'ordinateur.

Fonctionnement
Il existe trois types d'entités sur un réseau UPnP :

• Les devices qui sont identifiés par l'UUID défini la RFC 4122
• Les services qui sont publiés par les devices
• Les points de contrôle qui manipulent les services
Il existe trois cinq couches du protocole, toutes au dessus de HTTP :
• Découverte (discovery)
  La découverte de services est la première étape de la gestion d'un réseau UPnP est . Quand un périphérique est connecté au réseau, le protocole de découverte d'UPnP permet à de prévenir les points de contrôle du réseau des services. que celui-ci offre Le protocole permet également aux points de contrôle de découvrir les services disponibles sur le réseaux. Ce protocole de découverte UPnP est basé sur SSDP, le même protocole qui permet de configurer les adresses lien local en IPv6.
• Description [modifier]
  Vient ensuite la drescription qui permet de décrire les devices ainsi que les services qu'ils offrent. Pour le device, il s'agit de sa marque, son modèles... Pour les services, c'est essentiellement leur nom, les paramètres que ces derniers prennent lorsqu'on souhaite les utiliser et les valeurs de retour. Les descriptions sont faites en XML.
• Contrôle (control)
  Il s'agit de messages décrits en XML en utilisant SOAP qui permet d'envoyer des commandes pour utiliser les services.
• Notification d'évènements (event notification)
  Les points de contrôle s'enregistrent sur les services pour être notifiés en cas de changement d'état ou de variables des services. Ces notifications sont des messages XML de type GENA contenant le nom des variables et leurs valeurs.
• Présentation
  La dernière étape d'un réseau UPnP est la présentation. Si un dispositif a une URL de présentation, un point de contrôle peut recevoir une page depuis cette URL, charger la page dans un navigateur web et, selon les capacités de la page, permettre à un utilisateur de contrôler le dispositif et/ou de voir l'état d'un dispositif. Les possibilités d'une telle page peuvent changer en fonction des capacités du périphérique qui présente la page à l'utilisateur.
UPnP pour OSGi
Pour publier les services OSGI dans un réseau UPnP, le service UPnP Device Driver (disponible la R3 d'OSGi) peut être utilisé. Ce service a la capacité de mapper le protocole UPnP pour permettre aux bundles d'accéder au réseau UPnP.

OMG DDS

Présentation d'OMG DDS
Data Distribution Service ou DDS est un standard spécifié par l'OMG (Object Management Group), dont le rôle est de proposer une technologie évoluée d'échanges de données via un réseau. Il s'adresse principalement aux industries soumises à de fortes contraintes de fiabilité et de performances, telles que l'aéronautique, la défense ou encore les télécommunications, dont les données manipulées peuvent être de nature complexe. Mais il peut également être utilsé en immotique pour permettre de proposer des services domotiques à grande échelle.

Fonctionnement
DDS est basé sur le service de evènements et notification de Corba qui présente un modèle Publish / Subscribe. Son architecture se décompose en deux couches. Une très proche de la couche application (DLRL) et une autre plus basse (DCPS).

• DCPS : (Data-Centric Publish-Subscribe) est le cœur du système. Elle se charge de la gestion du modèle publish / subscribe. Il récupère et distribue les requêtes et assure l'acheminenement des réponses. Elle est capable de fournir une déférenciation de services (QoS).
• DLRL : (Data Local Reconstruction Layer). Elle se place au dessus de DCPS, en contact directe avec la couche application. Elle permet de simplidier les développements sous DDS puisqu'elle fournit une interface de programmation pour les langages orientés objet. Elle est en mesure de générer du code à partir de déclarations XML.

OMG DDS pour OSGi
Il n'existe pas de spécification de DDS de la part de OSGi. Mais une expérimentation du service Wire Admin Service d’OSGi qui décrit la construction de bundles basés sur le modèle publish-subscribe a été faite. L'expériementation concerne la mise en place d'un modèle de services basé capteurs (SBC) batisé SensorBeans.