OSGi et UPnP Des technologies complémentairesfrance.osgiusers.org/wiki/uploads/Main/GuideUPnP-OSGi_FR.pdf · le lecteur a de bonnes bases en programmation Java et une certaine connaissance

OSGi™ et UPnP™ :Des technologies complémentaires

Juin 2005

Électricité de France (contact: David MENGA / david-dot-menga_@_edf_fr)

TRIALOG (contact: Michel D'HOOGE / michel-dot-dhooge_@_trialog_com).

Licence

Ce document est publié sous contrat Creative Commons « BY-SA »

Vous êtes libres : de reproduire, distribuer et communiquer cette création au public

de modifier cette création

d'utiliser cette création à des fins commerciales

Selon les conditions suivantes :Paternité. Vous devez citer le nom de l'auteur original.

Partage des Conditions Initiales à l'Identique. Si vous modifiez, transformez ou adaptez cette création, vous n'avez le droit de distribuer la création qui en résulte que sous un contrat identique à celui-ci.

A chaque réutilisation ou distribution, vous devez faire apparaître clairement aux autres les conditions contractuelles de mise à disposition de cette création.

Chacune de ces conditions peut être levée si vous obtenez l'autorisation du titulaire des droits.

Ce qui précède n'affecte en rien vos droits en tant qu'utilisateur (exceptions au droit d'auteur : copies réservées à l'usage privé du copiste, courtes citations, parodie...)

Ce document est publié sous contrat Creative Commons BY-SA 2

Table des matières1 Introduction.......................................................................................................................................... 5

1.A Public visé....................................................................................................................................51.B Choix techniques..........................................................................................................................51.C Historique.....................................................................................................................................61.D Notation....................................................................................................................................... 6

2 Références............................................................................................................................................ 7

Première partie : Présentation de UPnP™ et OSGi™3 UPnP™.................................................................................................................................................8

3.A Le forum UPnP............................................................................................................................ 83.B UPnP en quelques mots............................................................................................................... 83.C Les composants d'un réseau UPnP...............................................................................................9

3.C.1 Devices................................................................................................................................. 93.C.2 Services................................................................................................................................ 93.C.3 Control Points.......................................................................................................................9

3.D Survol des Devices standardisés.................................................................................................. 93.D.1 Basic Device.......................................................................................................................103.D.2 Lighting Controls............................................................................................................... 103.D.3 HVAC................................................................................................................................ 103.D.4 Audio-Video.......................................................................................................................103.D.5 Security.............................................................................................................................. 103.D.6 Remote UI.......................................................................................................................... 11

3.E La pile de protocole UPnP......................................................................................................... 113.E.1 Addressing..........................................................................................................................113.E.2 Discovery............................................................................................................................113.E.3 Description......................................................................................................................... 123.E.4 Control................................................................................................................................123.E.5 Eventing..............................................................................................................................123.E.6 Presentation........................................................................................................................ 13

3.F UPnP Templates......................................................................................................................... 133.F.1 Couleurs UPnP....................................................................................................................133.F.2 Exemple XML.................................................................................................................... 133.F.3 Exemple de document.........................................................................................................133.F.4 Création automatisée.......................................................................................................... 13

3.G UPnP Use Case.......................................................................................................................... 133.G.1 Présentation des acteurs..................................................................................................... 143.G.2 Étape par étape................................................................................................................... 21

4 OSGi™...............................................................................................................................................244.A L'alliance OSGi..........................................................................................................................244.B OSGi en bref.............................................................................................................................. 244.C Architecture d'un Framework OSGi.......................................................................................... 244.D Patron de conception des services OSGi................................................................................... 254.E Quelques services standardisés.................................................................................................. 254.F Use Case..................................................................................................................................... 264.G Devices et Drivers OSGi............................................................................................................26

4.G.1 Entités.................................................................................................................................264.H Use Case : Devices et Drivers....................................................................................................26


5 Utilisation conjointe de UPnP™ et OSGi™...................................................................................... 285.A Notion de micro-mondes........................................................................................................... 285.B Utiliser ensemble UPnP et OSGi............................................................................................... 285.C UPnP en tant que service OSGi................................................................................................. 285.D Un conteneur pour Control Points............................................................................................. 295.E Interface utilisateur.....................................................................................................................29

Seconde partie : Développement6 Présentation des technologies disponibles......................................................................................... 30

6.A Implémentations UPnP.............................................................................................................. 306.B Implémentations OSGi...............................................................................................................306.C Autres outils............................................................................................................................... 31

6.C.1 Environnement de développement intégré......................................................................... 316.C.2 Génération automatique..................................................................................................... 31

7 Technologies Java™ Open Source ....................................................................................................327.A Oscar.......................................................................................................................................... 327.B CyberLink for Java.....................................................................................................................32

7.B.1 Implémentation d'un Device...............................................................................................327.B.2 Implémentation d'un Control Point.................................................................................... 377.B.3 Astuces de codage.............................................................................................................. 40

7.C DomoWare.................................................................................................................................407.D Exercices....................................................................................................................................40

8 UPnP™ Device Description...............................................................................................................418.A Associer les fonctionnalités existantes à une description UPnP................................................418.B Traduire une description UPnP dans un protocole propriétaire................................................. 41

9 Relier un micro-monde à UPnP..........................................................................................................429.A Couche physique........................................................................................................................429.B Pont à sens unique......................................................................................................................429.C Pont bidirectionnel..................................................................................................................... 42

9.C.1 Comment gérer un export UPnP vers les réseaux pontés...................................................429.D Exemple: Ponter un réseau X10.................................................................................................43

9.D.1 Caractéristiques X10.......................................................................................................... 439.D.2 Pont à sens unique..............................................................................................................439.D.3 Hardware X10.................................................................................................................... 439.D.4 Composants OSGi..............................................................................................................439.D.5 Exemple : Light Adapter....................................................................................................43

10 Conclusion........................................................................................................................................45


1 IntroductionJusqu'à maintenant, aucune killer application n'est apparue pour dynamiser le déploiement de réseaux domestiques. Ceci veut peut-être dire que ce ne sera pas une seule application mais au contraire une multitude de services qui va permettre aux réseaux domestiques de prendre leur envol. Mais pour que cette offre puisse apparaître, il faut que tous les acteurs (de l'utilisateur aux fournisseurs de services) aient des motivations comme par exemple un faible coût ou une réelle valeur ajoutée.

Une solution pour réduire le coût des services est de tous les accueillir dans une plate-forme partagée1. On peut ainsi prédire que dès qu'une plate-forme d'hébergement de services (Service Hosting Platform) sera disponible dans la maison, chaque acteur voudra l'employer pour améliorer le service rendu à moindre coût. Cependant pour être vraiment utile, une telle plate-forme doit se baser sur des standards ouverts, ce qui est une assurance de pérennité autant pour l'utilisateur que pour les fournisseurs de service. En effet, l'utilisateur est sûr qu'il trouvera une offre variée et en augmentation constante de services. Et n'importe quel fournisseur de services a la garantie que son service s'exécutera sur cette plate-forme ouverte quelle que soit l'origine du matériel.

Ce document est une introduction à UPnP™ et OSGi™, pour promouvoir leur utilisation commune dans le cadre du déploiement de réseaux domestiques : OSGi™ comme passerelle de services, et UPnP™ comme langage de description des équipements (même pour les équipements non UPnP™).Pour terminer cette introduction, nous montrons comment une plate-forme ouverte de services (Open Service Hosting Platform) peut améliorer le confort d'utilisation des équipements. Supposons que la plate-forme soit reliée à Internet et communique avec l'utilisateur via la TV. Lorsque l'utilisateur branche un nouvel équipement, celui-ci est détecté par la plate-forme (quel que soit le réseau d'origine). Pour diminuer le coût, le constructeur de l'équipement a réduit l'interface physique au minimum (e.g. quelques boutons, pas d'affichage) mais la plate-forme télécharge une interface graphique de remplacement. Cette interface utilise la TV pour communiquer avec l'utilisateur tout en respectant le thème graphique choisi (e.g. gros caractères, couleurs fluo, ...). L'équipement est aussi accessible grâce à une modélisation UPnP™, ce qui permet à n'importe quelle application de l'utiliser facilement.

1.A Public viséLes lecteurs visés par ce document sont les architectes logiciel et les développeurs. Il est supposé que le lecteur a de bonnes bases en programmation Java et une certaine connaissance de XML. En effet, Java est utilisé aussi bien pour le développement des équipements UPnP que pour l'encapsulation du code résultant dans un bundle OSGi2. A noter que les concepts Java nécessaires à une utilisation optimale et efficace de OSGi vont au-delà des connaissances de base d'un développeur Java – mais le but de ce document est bien d'aider à passer la marche. Quant à XML, il est principalement utilisé du côté UPnP – même si les outils autour de OSGi l'utilisent aussi (e.g. Jakarta Ant, OBR) .

1.B Choix techniquesCe document a fait le choix de promouvoir des logiciels open source. Ainsi les logiciels utilisés dans les exemples sont des implémentations libres du protocole UPnP (CyberLink [CLK], Domoware [Domoware]) et de l'environnement OSGi ([Oscar]).

D'autres implémentations existent bien sûr et elles sont listées au début du chapitre 6.

1 C'est une des raisons pour lesquelles les PC sont devenus si populaires : l'utilisateur peut faire toute sorte de choses avec la même plate-forme. Internet est un autre exemple de ressources partagées.

2 Même si ce n'est pas le choix fait dans ce document, il est possible de développer des équipements UPnP dans un langage autre que Java. Par contre, les mécanismes fondamentaux de OSGi reposent sur Java.


1.C HistoriqueMai 2005 EDF/TRIALOG Première version, rédigée avec OpenOffice beta 2Juin 2005 EDF/TRIALOG Intégration des premières remarquesOctobre 2005 EDF/TRIALOG Diffusion

1.D NotationLe formalisme utilisé dans le document est standard et devrait être assez explicite.

Les extraits de code (Java, XML) sont en police non proportionnelle. Pour être dans l'esprit UPnP, les descriptions utilisent le code des couleurs définis par UPnP et résumés en 3.F.1.

Ce document étant ouvert et sujet à modifications et évolutions, un style spécial existe pour les « notes personnelles » des auteurs (parties à développer, questions/doutes, ...). Ces notes utilisent le style de ce paragraphe. Même si elles ne font pas vraiment partie du document elles peuvent cependant aider le lecteur à comprendre l'articulation générale du document.


2 Références[CLK] CyberLink for Java

http://www.cybergarage.org/net/upnp/java/index.html

[CLK-PG] CyberLink for Java – Programming Guidehttps://sourceforge.net/project/showfiles.php?group_id=75638

[DA] UPnP Device Architecture v1.0http://www.upnp.org/resources/documents.asp

[DCP] Standardized UPnP DCPshttp://www.upnp.org/standardizeddcps/default.asp

[DCP-Basic] Basic Device V 1.0http://www.upnp.org/standardizeddcps/basic.asp

[DCP-HVAC] HVAC V 1.0http://www.upnp.org/standardizeddcps/hvac.asp

[DCP-Light] Lighting Controls V 1.0http://www.upnp.org/standardizeddcps/lighting.asp

[DCP-Security] Device Security and Security Console V 1.0http://www.upnp.org/standardizeddcps/security.asp

[DCP-UI] Remote UI Client and Server V 1.0http://www.upnp.org/standardizeddcps/remoteui.asp

[Domoware] Domotics softwarehttp://domoware.isti.cnr.it/index.html

[Donsez-BR] ADELE Bundle Repositoryhttp://www-adele.imag.fr/~donsez/dev/osgi/

[Intel] Intel Software for UPnP Technologyhttp://intel.com/technology/upnp/

[KFish] Knopflerfish OSGihttp://www.knopflerfish.org/

[MS-UPnP] Understanding Universal Plug and Playhttp://www.upnp.org/download/UPNP_UnderstandingUPNP.doc

[NMPR] The Intel Networked Media Products Requirementshttp://www.intel.com/technology/dhdevnet/

[Oscar] Oscar, an OSGi framework implementationhttp://oscar.objectweb.org/

[OSGi] OSGi Service PlatformRelease 3, March 2003Disponible sur http://www.osgi.org/ après avoir rempli un formulaire.

[OSGi-A] The OSGi Alliancehttp://www.osgi.org/

[Siemens] SIEMENS: UPnP technologyhttp://www.plug-n-play-technologies.com/

[UPnP-F] The UPnP Forumhttp://www.upnp.org/

[UPNPLib] Une implémentation libre de la pile de protocole UPnPhttp://www.sbbi.net/site/upnp/index.html



http://www.upnp.org/

http://www.upnp.org/

http://www.plug-n-play-technologies.com/

http://www.osgi.org/



http://www.intel.com/technology/dhdevnet/

http://www.upnp.org/download/UPNP_UnderstandingUPNP.doc

http://www.knopflerfish.org/

http://intel.com/technology/upnp/

http://www-adele.imag.fr/~donsez/dev/osgi/repository.html

http://domoware.isti.cnr.it/index.html

http://www.upnp.org/standardizeddcps/remoteui.asp

http://www.upnp.org/standardizeddcps/security.asp

http://www.upnp.org/standardizeddcps/lighting.asp

http://www.upnp.org/standardizeddcps/hvac.asp

http://www.upnp.org/standardizeddcps/basic.asp

http://www.upnp.org/standardizeddcps/default.asp

http://www.upnp.org/resources/documents.asp


Première partie : Présentation de UPnP™ et OSGi™Cette première partie du document est une introduction à UPnP et OSGi. Elle présente les concepts sans trop entrer dans les détails techniques. Si le lecteur veut approfondir ses connaissances, il y trouve des références vers d'autres documents.

3 UPnP™Ce chapitre présente au lecteur ce qu'il doit connaître sur UPnP pour pouvoir aborder tranquillement la 2e partie du document. Les concepts abordés ici restent au niveau de l'utilisation de UPnP et sont introduits de façon progressive (c'est en tout cas la volonté des auteurs). Le lecteur pourra éventuellement commencer par la section 3.G qui est un Use Case sur l'utilisation d'équipements UPnP.

3.A Le forum UPnPLes extraits suivants proviennent du site officiel du forum UPnP [UPnP-F]

The UPnP™ Forum is an industry initiative designed to enable simple and robust connectivity among stand-alone devices and PCs from many different vendors.

Lors de l'écriture de ce document, le forum UPnP est ouvert gratuitement à tous : il suffit d'accomplir les formalités décrites pour devenir membre. Cependant il n'est pas nécessaire d'être membre pour avoir accès à l'ensemble des documents qui décrivent le protocole UPnP et les équipements standardisés.

3.B UPnP en quelques motsAccording to [UPnP-F]

UPnP™ technology is all about making home networking simple and affordable for users so the connected home experience becomes a mainstream experience for users experience and great opportunity for the industry. UPnP™ architecture offers pervasive peer-to-peer network connectivity of PCs of all form factors, intelligent appliances, and wireless devices. UPnP™ architecture leverages TCP/IP and the Web to enable seamless proximity networking in addition to control and data transfer among networked devices in the home, office, and everywhere in between. UPnP™ technology can be supported on essentially any operating system and works with essentially any type of physical networking media - wired or wireless - providing maximum user and developer choice and great economics.

La référence incontournable pour celui qui veut vraiment comprendre en détail tous les mécanismes de UPnP est [DA] (UPnP Device Architecture). Malheureusement, comme bien des manuels de référence son utilisation par un débutant est impossible. Les sections suivantes de cette introduction à UPnP ont pour objectif de préparer le lecteur en introduisant petit à petit les bases nécessaires à la lecture de [DA]. A noter aussi que pour la sortie de WindowsME, Microsoft a publié un document de synthèse intéressant [MS-UPnP].


3.C Les composants d'un réseau UPnPLes éléments de base pour pouvoir travailler avec un réseau UPnP sont les équipements (Devices), les services (Services), et les points de contrôle (Control Points, CP).

Un Device (qu'on peut également appeler “controlled device”) se comporte comme un serveur. Il répond aux requêtes des points de contrôle. Plusieurs Devices et points de contrôle peuvent être présents et opérationnels simultanément sur un même réseau.

3.C.1 DevicesUn Device UPnP est un élément qui contient des services et éventuellement d'autres Devices imbriqués. Typiquement, un Device est un équipement de la maison. Par exemple, un simple magnétoscope est un Device mais un combiné TV/magnétoscope est un Device qui a deux Devices imbriqués (la TV et le magnétoscope).

Le Device principal est appelée “Root Device”. Un Device imbriqué dans un autre est appelé “Embedded Device”.

3.C.2 ServicesLe service est la plus petite unité de contrôle dans un réseau UPnP. Un service propose des actions et son état est modélisé grâce à ses variables d'état.

Un service se compose de

une table d'état : Elle modélise l'état du service par des variables d'état et les met à jour quand l'état change.

un serveur de commande : Il reçoit des demandes d'action (telles que set_time), les exécute, met à jour la table d'état et renvoie les réponses.

un serveur d'événements : Il envoie des événements aux abonnés intéressés lorsque l'état du service change. Par exemple, un service de signal d'incendie enverrait un événement aux abonnés intéressés quand son état devient "alerte".

3.C.3 Control PointsUn point de contrôle est un contrôleur capable de découvrir et de contrôler des Devices, et d'utiliser leurs services.

A control point in a UPnP network is a controller capable of discovering and controlling other devices. After discovery, a control point could:

Retrieve the device description and get a list of associated services.

Retrieve service descriptions for interesting services.

Invoke actions to control the service.

Subscribe to the service’s event source. Anytime the state of the service changes, the event server will send an event to the control point.

3.D Survol des Devices standardisésLa page web Standards du Forum UPnP [DCP] donne accès à l'ensemble des Devices et des Services qui ont été standardisés par les membres. Chaque catégorie de Devices (Device Class) standardisée possède un « Standardized DCP » qui définit le DCP, ou Device Control Protocol. Le DCP impose la manière de décrire un équipement et ce qu'il doit offrir comme services – ceci pour garantir l'interopérabilité d'équipements provenant de constructeurs différents.


Les sections suivantes de ce chapitre présentent quelques Devices et Services susceptibles d'être utilisés en domotique. Cette présentation ne se veut pas exhaustive, mais on peut cependant remarquer qu'il y a encore peu de DCP standardisés, que ce soit dans le monde domotique ou dans celui de l'audio-video.

3.D.1 Basic DeviceIl s'agit d'un modèle de Device qui doit être choisi comme base de développement quand aucun des Standardized DCP ne convient.

[DCP-Basic]

Basic:1.0 provides a mechanism for products that wish to use UPnP, but for which there is not yet an appropriate standard base device type. The Basic Device type does not define any Services or embedded Devices, although a particular product may incorporate elements defined by other UPnP Standards and/or vendor-defined extension types.

3.D.2 Lighting ControlsDeux Devices existent pour la gestion de l'éclairage [DCP-Lighting] :

une lampe simple (Binary Light)

un variateur (Dimmable Light)

Deux Services sont définis par le DCP :

un service marche/arrêt (Switch Power)

un service de gestion du variateur (Dimming)

Le Service Switch Power est utilisé -bien sûr- par ces deux Devices, mais il est aussi utilisé par tous les Devices qui peuvent se « mettre en veille ».

3.D.3 HVACLe [DCP-HVAC] est plutôt bien développé (grâce au travail de Siemens Building Technology et Honeywell). La norme ne détaille cependant pas la façon d'inter-connecter tous ces éléments.

Il est composé des Devices System et Zone Thermostat, et des Services House Status, User Operating Mode, Temperature Set Point, Temperature Sensor, Fan Operating Mode, Fan Speed, Control Valve et Set Point Schedule.

3.D.4 Audio-VideoLa population UPnP Audio-Video se compose de trois types d'équipements :

Les serveurs de contenus multimédia (AV Media Server) sont des unités de stockage.

Les interpréteurs de contenus multimédia (AV Media Renderer) reçoivent un flux audio/video pour l'afficher ou le faire écouter. Par commodité pour l'utilisateur, ils peuvent aussi intégrer une unité de stockage.

Les contrôleurs pour serveurs et interpréteurs multimédia (AV Media Controller) servent en quelque sorte de télécommande universelle. Ils sont capables de lier des serveurs à des interpréteurs. A noter que pour des raisons d'efficacité, les protocoles utilisés pour le transfert des contenus ne reposent pas sur UPnP.

3.D.5 SecurityComme beaucoup de protocoles « un peu ancien », UPnP n'a pas été défini en prenant en compte la


sécurité du réseau et des équipements. De plus, comme il s'agit d'un protocole facilitant le Plug'n Play prendre en compte la sécurité est encore plus difficile3. En effet, comment permettre à des équipements de se connecter entre eux sans intervention de l'utilisateur, s'ils ne se connaissent pas ?

Le [DCP-Security] est une extension à UPnP qui permet aux équipements du réseau de s'échanger des messages en garantissant l'identité de l'émetteur et du destinataire, et éventuellement en cryptant les contenus.

Une implémentation beta de cette extension a été développée par [Siemens].

3.D.6 Remote UILa spécification sur les IHM déportées est compliquée et semble peu utilisée. Nous ne la détaillons donc pas. A la place, Intel propose d'utiliser [NMPR] pour améliorer le service rendu à l'utilisateur.

3.E La pile de protocole UPnP

3.E.1 AddressingL'adressage est la première phase indispensable au bon fonctionnement d'un Device UPnP. Elle lui permet d'obtenir une adresse IP indispensable pour la suite du protocole UPnP.

Chaque élément UPnP (Device ou Control Point) doit utiliser le protocole DHCP (Dynamic Host Configuration Protocol) lorsqu'il est connecté pour la première fois au réseau. Si un serveur DHCP est disponible, l'élément doit utiliser l'adresse IP que celui-ci lui fournit. Sinon, il doit s'en créer une en utilisant la méthode Auto-IP. Sans entrer dans les détails, Auto-IP explique comment une machine intelligente choisit une adresse IP dans un ensemble d'adresses réservées et est capable de passer facilement d'un réseau avec serveur à un réseau sans serveur.

3.E.2 DiscoveryCette phase permet de mettre en relation tous les acteurs du réseau UPnP. Elle s'appuie sur le protocole SSDP (Simple Service Discovery Protocol). Elle est utilisée par chaque Device et chaque Control Point lors de sa connexion au réseau, puis périodiquement pour re-signaler sa présence.

Lorsqu'un Device apparaît, SSDP lui permet de présenter aux points de contrôle présents sur le même réseau sa structure (Root Device, Embedded Devices) et la liste de ses Services. Chaque Root Device transmet ainsi 3 notifications (Root Device, UUID et Device Type), tandis qu'un Embedded Device n'en transmet que 2 (UUID et Device Type). Enfin, pour chaque service une seule notification est envoyée (Service Type).

La notification « Root Device » permet d'annoncer l'apparition d'un nouvel équipement.

La notification « UUID » (Universally Unique IDentifier) permet à un Control Point de retrouver un équipement déjà utilisé (ou connu par un autre biais) grâce à son identifiant unique, même si l'équipement a changé d'adresse.

La notification « Device Type » fournit une indication précieuse sur le type d'un Device. Elle peut être filtrée par un Control Point pour ne retenir que les Devices qu'il saura utiliser.

La notification « Service Type » fournit une indication précieuse sur le type d'un Service. Elle peut être filtrée par un Control Point pour ne retenir que les Services qu'il saura utiliser.

Lorsqu'un point de contrôle est ajouté au réseau, SSDP lui permet de découvrir tous les Devices et Services présents (dans le cas d'un point de contrôle généraliste), ou juste le sous-ensemble qui l'intéresse. Il peut pour cela rechercher l'ensemble des Devices, l'ensemble des Root Devices, un UUID

3 Voir par exemple http://www.goland.org/Tech/upnp_security_flaws.htm


http://www.goland.org/Tech/upnp_security_flaws.htm

particulier, l'ensemble des Devices répondant à un Device Type donné ou encore l'ensemble des Services répondant à un Service Type donné.

Techniquement parlant, un Device utilise la méthode NOTIFY pour s'annoncer ; tandis qu'un point de contrôle utilise la méthode M-SEARCH pour ses recherches. Chaque notification et réponse à un M-SEARCH contient une URL qui permettra dans la phase de Description d'obtenir plus d'informations sur le Device ou le Service.

Toujours côté technique, les messages d'annonce et de recherche sont des datagrammes qui reposent sur une variante multicast de HTTP via UDP. Ils sont envoyés vers l'adresse IP de classe « D » 239.255.255.250 et vers le port 1900.

3.E.3 DescriptionLorsqu'un point de contrôle a “découvert” un Device ou un Service pendant la phase Discovery, il n'en sait toujours pas beaucoup sur le Service ou le Device. La phase de description a donc été définie pour permettre aux points de contrôle d'obtenir une description détaillée à partir de l'URL qui a été fournie lors de la phase de découverte.

La description d'un Device est écrite en XML et contient des informations telles que : la marque, le modèle de l'appareil et le numéro de série. On y trouve également la liste des services proposés par le Device et les Embedded Devices qu'il contient. Pour chaque Service, la description contient la liste des Actions (i.e. les commandes) auxquelles le service réagit, et les arguments (i.e. les paramètres) pour chaque Action. On trouve également pour chaque service une liste de variables qui décrivent l'état du service à tout moment.

Les arguments des actions sont des parametres d'entrée (in) ou des valeurs de sortie (out). Le typage des variables d'état et des arguments des actions est figé aux 24 types suivants :

boolean (booléen)

ui1, ui2, ui4, i1, i2, i4, int (entier)

r4, float, r8, number, fixed.14.4 (flottant)

char, string

uri, uuid

time, time.tz, date, dateTime, dateTime.tz

bin.base64, bin.hex (contenu brut)

3.E.4 ControlUne fois que le point de contrôle a trouvé la description d'un service, il peut envoyer des commandes (i.e. des « actions ») vers le Device qui possède ce service. Il devra pour cela utiliser le protocole SOAP (Simple Object Access Protocol).

Tout comme dans le cas d'un appel de fonction local et classique, le service distant peut retourner des variables (ou des codes d'erreur). On mesure les effets de l'action à la modification des variables qui décrivent l'état du service.

3.E.5 EventingLa description d'un service UPnP est faite d'une liste d'actions auxquelles le service peut réagir et une liste de variables qui permettent de connaître l'état du service à un moment donné. Le service doit publier des mises à jour lorsque ces variables changent, et un point de contrôle peut s'abonner afin de recevoir ces informations. Les mises à jour sont notifiées par l'envoi de “event messages”, qui sont également codés en XML et formatés selon l'architecture GENA (General Event Notification Architecture). Lors de la souscription d'un point de contrôle, un “event message” spécial, appelé


initial, lui est envoyé. Ce message contient les noms et les valeurs de toutes les variables du service. Afin de supporter des scénarios comportant plusieurs points de contrôle, l'”eventing” prévoit d'informer tous les points de contrôle de façon identique lors d'une modification qui fait suite à une action. Ainsi, tous les abonnés reçoivent tous les “event messages”, et ceux-ci sont envoyés quelle que soit la raison qui a induit un changement d'état des variables (suite à une action ou suite à un changement interne du modèle du service).

3.E.6 PresentationLa dernière étape est la présentation. Si un Device a fourni, dans sa description, une URL de présentation, alors le point de contrôle peut charger la page qui se trouve à cette adresse et (en fonction de ce qu'autorise la page) permettre ainsi à son utilisateur de contrôler le Device et/ou de consulter son statut.

3.F UPnP TemplatesLa force de UPnP repose sur la découverte dynamique des équipements. Il est donc impératif que tous les acteurs parlent le même langage et utilisent le même formalisme. Le Forum UPnP a donc défini un formalisme pour décrire en XML chaque Device et chaque Service. La section 2 de [DA] décrit en détail l'ensemble des champs XML à renseigner par un Device ou un Service.

En plus de la description XML qui normalise les échanges entre machines, il est tout aussi important de normaliser la façon de présenter aux développeurs humains les informations sur les Devices et les Services. Il existe pour ça deux fichiers templates, l'un pour un Device, l'autre pour un Service qui expliquent comment rédiger un (proposed) DCP.

3.F.1 Couleurs UPnPTous les documents publiés par le Forum UPnP (e.g. Le Device Architecture et les DCPs) font une utilisation intensive des couleurs pour aider à différencier l'origine des informations :

UPnP Vendor [purple-italic]UPnP Forum [red-italic]UPnP Device Architecture [green-bold]SSDP/SOAP [blue]

3.F.2 Exemple XMLDans [DA] : Les sections 2.1, 2.2 et 2.6 présentent le fichier XML de description d'un device. Les sections 2.3, 2.4 et 2.7 présentent le fichier XML de description d'un service.

3.F.3 Exemple de documentIl est possible de télécharger sur [UpnP-F] des exemples de documents.

3.F.4 Création automatiséeL'outil de [Intel] appelé Device Author permet de générer automatiquement des descriptions de Device et de Service sans avoir à écrire de XML.

3.G UPnP Use CaseIl semble intéressant de reprendre l'exemple fourni par CyberLink pour éclaircir nos propos (la


présentation générale de CyberLink sera faite dans la 2e partie du document.)

Dans cet exemple, tous les composants UPnP sont simulés sur le PC. Il est toutefois à noter que les échanges ne se font pas de façon directe entre les processus mais “descendent” bien jusqu'à la couche IP. Pour s'en convaincre, on peut lancer chaque élément sur un PC différent du même réseau et voir qu'ils ont le même comportement que lorsqu'ils se trouvent sur un unique PC.

3.G.1 Présentation des acteursPour chaque Device de l'exemple, nous allons nous intéresser aux fichiers XML qui décrivent les services qu'il propose. Pour chaque Service, et à partir de la description XML, nous allons détailler les actions possibles et la liste de ses variables d'état (State Variables).

3.G.1.a Washing MachineC'est un Device qui simule un lave-linge. Lorsqu'il est en route, on voit une sorte de vague bleue dans le tambour. Il possède un service : state.

Le service stateLe début du fichier indique simplement qu'il s'agit d'une description de Service (version 1.0) selon les recommandations du [DA]. Cet en-tête est commun à toutes les descriptions de Service.

<?xml version="1.0"?><scpd xmlns="urn:schemas-upnp-org:s er vice-1-0 "><specVersion>

<major>1</major><minor>0</minor>

</specVersion>

Ensuite commence la description des actions que propose le service.

La première action, SetState, permet de démarrer ou d'arrêter le cycle de lavage. Elle comporte deux arguments. Le premier se nomme State et est un argument en entrée de l'action. Une variable d'état lui est liée qui s'appelle State également. Le deuxième argument, Result, est un argument en sortie de la fonction. La variable d'état qui lui est liée se nomme également Result.Dire qu'une variable d'état est liée à un argument d'une action, signifie que la variable d'état doit prendre la valeur de l'argument lorsque l'action est exécutée. Prenons un exemple avec l'argument State (arg) qui est lié à la variable d'état State (VE). A un moment donné, la VE a pour valeur 0 et un point de contrôle fait une demande d'action SetState(1). Lorsque le Device reçoit cette demande, il doit mettre sa VE à 1 : le lave-linge vient d'être démarré.

Remarque : Dans le cas de notre lave-linge simulé, un cycle s'arrête automatiquement au bout de quelques secondes.

<actionList><action>

<name>SetState</name><argumentList>

<argument><name>State</name><relatedStateVariable>State</relatedStateVariable><direction>in</direction>

</argument><argument>

<name>Result</name><relatedStateVariable>Result</relatedStateVariable>


<direction>out</direction></argument>

</argumentList></action>

La deuxième action proposée par ce service est l'action GetState. Elle ne prend qu'un argument en sortie, nommé State. La variable d'état qui lui est associée est à nouveau la variable State. L'action GetState permet de connaître l'état du lave-linge (en route=1 ou arrêté=0).

<action><name>GetState</name><argumentList>

<argument><name>State</name><relatedStateVariable>State</relatedStateVariable><direction>out</direction>

</argument></argumentList>

</action></actionList>

La table des variables d'étatUne fois que toutes les actions ont été décrites, le fichier XML continue avec la table des variables d'état. On voit ici que le service a deux variables d'état.

La variable State est de type string et son changement déclenchera l'envoi d'une trame événement aux points de contrôle qui se sont abonnés.

La variable Result est de type string également mais aucune trame d'évènement ne sera envoyée lorsque sa valeur change.

<serviceStateTable><stateVariable sendEvents="yes">

<name>State</name><dataType>string</dataType>

</stateVariable><stateVariable sendEvents="no">

<name>Result</name><dataType>string</dataType>

</stateVariable></serviceStateTable>

</scpd>

3.G.1.b Air ConditionerLe climatiseur est un Device qui propose deux services. Parcourons leurs descriptions.

Le service power

<?xml version="1.0"?><scpd xmlns="urn:schemas-upnp-org:service-1-0" ><specVersion>


</specVersion>

L'action SetPower a un argument en entrée, Power, lié à la variable d'état Power, et un argument en sortie, Result, lié à la variable d'état Result. Cette action permet d'allumer ou d'éteindre le climatiseur.



<name>SetPower</name><argumentList>

<argument><name>Power</name><relatedStateVariable>Power</relatedStateVariable><direction>in</direction>


<name>Result</name><relatedStateVariable>Result</relatedStateVariable><direction>out</direction>


</action>

L'action GetPower a un argument en sortie, Power, lié à la variable d'état Power. Cette action permet de connaître l'état du climatiseur (allumé=1 ou éteint=0).

<action><name>GetPower</name><argumentList>

<argument><name>Power</name><relatedStateVariable>Power</relatedStateVariable><direction>out</direction>



La table des variables d'état contient deux variables :

La variable Power est de type boolean et son changement provoquera l'envoi d'un événement aux points de contrôle qui se sont abonnés.

La variable Result est aussi de type boolean mais aucun évènement ne sera envoyé lorsque sa valeur change.


<name>Power</name><dataType>boolean</dataType>


<name>Result</name><dataType>boolean</dataType>


</scpd>

Le service temp



</specVersion>

L'action SetTemp a un argument en entrée, Temp, lié à la variable d'état Temp, et un argument en


sortie, Result, lié à la variable d'état Result. Cette action permet de définir la consigne de température.

Remarque : avec le point de contrôle « de debug » (voir ci-dessous), on peut donner une température directement sous forme d'un entier. Avec la télécommande (voir ci-dessous), on peut monter ou descendre la température par palier d'un degré. Il s'agit d'un choix d'implémentation des deux points de contrôle qui est totalement indépendant du climatiseur.


<name>SetTemp</name><argumentList>

<argument><name>Temp</name><relatedStateVariable>Temp</relatedStateVariable><direction>in</direction>




</action>

L'action GetTemp a un argument en sortie, Temp, lié à la variable d'état Temp. Cette action permet de connaître la température programmée dans le climatiseur.

<action><name>GetTemp</name><argumentList>

<argument><name>Temp</name><relatedStateVariable>Temp</relatedStateVariable><direction>out</direction>



La table des variables d'état contient deux variables. La variable Temp est de type String et son changement provoquera l'envoi d'un événement aux points de contrôle abonnés. La variable Result est de type Boolean et aucun évènement n'est envoyé lorsque sa valeur change.


<name>Temp</name><dataType>string</dataType>




</scpd>


3.G.1.c ClockL'horloge est un Device assez simple qui n'offre qu'un seul service.

Le service timerEn-tête de la description XML :



</specVersion>

L'action SetTime a un argument en entrée, NewTime, lié à la variable d'état Time, et un argument en sortie, Result, lié à la variable d'état Result. Ce service permet de modifier l'heure de l'horloge. Remarque : le service est proposé mais il n'est pas implémenté dans l'exemple de Cyberlink.


<name>SetTime</name><argumentList>

<argument><name>NewTime</name><relatedStateVariable>Time</relatedStateVariable><direction>in</direction>




</action>

L'action GetTime a un argument en sortie, CurrentTime, lié à la variable d'état Time.

<action><name>GetTime</name><argumentList>

<argument><name>CurrentTime</name><relatedStateVariable>Time</relatedStateVariable><direction>out</direction>



La table des variables d'état contient deux variables. La variable Time est de type String et son changement provoquera l'envoi d'une trame événement. La variable Result est de type String également mais aucune trame d'évènement ne sera envoyée lorsque sa valeur change.


<name>Time</name><dataType>string</dataType>


<name>Result</name><dataType>string</dataType>



</scpd>

3.G.1.d TVLa TV est un Device qui affiche une image fixe lorsqu'elle est « allumée » et un écran noir lorsqu'elle est « éteinte ». Elle agit également comme un point de contrôle. Ainsi, elle peut s'abonner à des services proposés par d'autres Devices du réseau et les exploiter. Par exemple, elle s'abonne à une horloge dès que le service apparaît sur le réseau. On voit alors apparaître sur l'écran la date et l'heure.

Elle ne possède qu'un service.

Le Service PowerL'action SetPower a un argument en entrée, Power, lié à la variable d'état Power, et un argument en sortie, Result, lié à la variable d'état Result. L'action permet d'allumer ou d'éteindre la TV.


<name>SetPower</name><argumentList>

<argument><name>Power</name><relatedStateVariable>Power</relatedStateVariable><direction>in</direction>




</action>

L'action GetPower a un argument en sortie, Power, lié à la variable d'état Power. Cette action permet de connaître l'état de la TV (allumée=1 ou éteinte=0).

<action><name>GetPower</name><argumentList>

<argument><name>Power</name><relatedStateVariable>Power</relatedStateVariable><direction>out</direction>



La table des variables d'état contient deux variables.

La variable Power est de type Boolean et son changement provoquera l'envoi d'une trame évènement aux points de contrôle qui se sont abonnés.

La variable Result est de type Boolean également mais aucune trame d'évènement ne sera envoyée lorsque sa valeur change.



<name>Power</name><dataType>boolean</dataType>




</scpd>

3.G.1.e Remote ControlC'est un point de contrôle qui permet d'accéder aux services des Devices de l'exemple. Il permet d'agir sur les Devices mais ne permet aucune visualisation de leurs états. Ainsi, on peut allumer ou éteindre la TV, démarrer ou arrêter le lave-linge, et enfin allumer ou éteindre le climatiseur et modifier sa température. Remarque : cette télécommande permet également de contrôler une lampe mais nous avons décidé de ne pas l'inclure dans notre document car l'exemple était assez complet.

Par définition les points de contrôle n'ont pas de fichier de description puisqu'aucun équipement du réseau UPnP ne les utilise.

3.G.1.f Debug Control PointIl s'agit d'un autre point de contrôle qui prend la forme d'une fenêtre dans laquelle on visualise les éléments UPnP présents sur le réseau. Pour chaque Device, on visualise la liste de ses services, auxquels on peut s'abonner ou se désabonner, ainsi que la liste de ses variables accompagnées de leurs valeurs. On retrouve globalement tout ce que le Device a annoncé lors de la phase de description. On peut également agir sur les services auxquels le point de contrôle s'est abonné. Dans cet exemple précis, on peut remarquer que le point de contrôle est plutôt utile à la visualisation – c'est un outil de debug. En effet, la télécommande permet d'agir sur les Devices de façon bien plus ciblée et conviviale.


3.G.2 Étape par étapeDans ce paragraphe, nous allons dans un premier temps faire arriver les acteurs de notre exemple les uns après les autres, puis nous jouerons avec les points de contrôle et observerons les réactions des Devices. Remarquons que nous avons choisi de faire arriver la TV en premier sur le réseau car son apparence sera modifiée par l'arrivée des autres Devices. Ceci n'est cependant pas une obligation. Toute la souplesse de UPnP repose sur le fait qu'il n'y a pas d'ordre imposé pour le branchement des équipements.

A chaque étape de l'exemple, nous détaillerons ce qui se passe lors des différentes phases UPnP que nous avons décrites au début de ce document (Adressing, Discovery, Description, Control, Eventing, Presentation).

Il y a cependant deux phases que nous n'approfondirons pas. Il s'agit de la phase d'Adressing et de la phase de Presentation. L'adressing a lieu dès la connexion de l'équipement sur le réseau. Comme nous l'avons déjà expliqué, cette étape est indispensable pour la suite. Nous ne nous intéressons cependant pas ici à la façon dont elle se déroule dans les faits, ceci étant du ressort des couches basses. L'étape de présentation est plutôt réservée aux points de contrôle qui ont, au minimum, accès à un navigateur web capable d'accéder et de présenter la page du Device à l'adresse que celui-ci avait fournie dans son fichier de description. D'une part, les points de contrôle de notre exemple n'en sont pas capables, et d'autre part, les Devices ne fournissent pas de page de présentation.

3.G.2.a Branchement de la TVDiscovery : En tant que Control Point, la télévision ne pourra découvrir aucun Device car elle est la première sur le réseau. Cependant, en tant que Device, elle envoie trois messages NOTIFY sur le réseau (qui ne seront lus par personne). Le premier message informe de l'arrivée d'un rootDevice :

NOTIFY * HTTP/1.0SERVER: Windows 2000/5.0 UPnP/1.0 CyberLink/1.3.2CACHE-CONTROL: max-age=1800LOCATION: http://192.168.200.231:4004/description.xmlNTS: ssdp:aliveNT: upnp:rootdeviceUSN: uuid:4966-a101-52f3-e032::upnp:rootdeviceHOST: 239.255.255.250:1900

Le second message NOTIFY annonce l'arrivée d'un Device particulier qui est la TV :

NOTIFY * HTTP/1.0SERVER: Windows 2000/5.0 UPnP/1.0 CyberLink/1.3.2CACHE-CONTROL: max-age=1800LOCATION: http://192.168.200.231:4004/description.xmlNTS: ssdp:aliveNT: urn:schemas-upnp-org:device:tv:1USN: uuid:4966-a101-52f3-e032::urn:schemas-upnp-org:device:tv:1HOST: 239.255.255.250:1900

Le troisième message NOTIFY annonce l'arrivée du service power :

NOTIFY * HTTP/1.0SERVER: Windows 2000/5.0 UPnP/1.0 CyberLink/1.3.2CACHE-CONTROL: max-age=1800LOCATION: http://192.168.200.231:4004/service/power/description.xmlNTS: ssdp:aliveNT: urn:schemas-upnp-org:service:power:1USN: uuid:4966-a101-52f3-e032::urn:schemas-upnp-org:service:power:1HOST: 239.255.255.250:1900

Description : Cette étape concerne les points de contrôle, mais sans équipement découvert, il n'y a rien à demander.


Control : C'est une étape qui concerne aussi les points de contrôle.

Eventing : Pour l'instant, rien ne se passe non plus à cette étape. En effet, des évènements seront édités si et seulement si au moins une des variables d'état du Device est soumise à un abonnement.

3.G.2.b Démarrage du Debug Control PointDiscovery : Le point de contrôle découvre qu'un Device (la TV) est présent sur le réseau.

Description : Voici un extrait de la description de la TV.

<serviceList><service>

<serviceType>urn:sche mas -upnp-org :service:power:1</serviceType><serviceId>urn:upnp-org:serviceId:power:1</serviceId><SCPDURL>/service/power/description.xml</SCPDURL><controlURL>/service/power/control</controlURL><eventSubURL>/service/power/eventSub</eventSubURL>

</service></serviceList>

Le point de contrôle constate que la TV propose un seul service qui se nomme “urn:upnp-org:serviceId:power:1”. La description du service se trouve dans le fichier description.xml du répertoire /service/power/. Ce répertoire est relatif à l'adresse URL donnée par le tag <URLBase>.

3.G.2.c Branchement de la télécommandeLes étapes que réalise la télécommande sont exactement les mêmes que celles réalisées par le point de contrôle de debug ci-dessus. Nous ne détaillons donc pas plus.

3.G.2.d Branchement de l'horlogeDiscovery : L'horloge va utiliser le protocole SSDP pour annoncer sa présence et envoyer la liste de ses services aux points de contrôle présents sur le réseau.

Description : Les points de contrôle ont été avertis à l'étape précédente de l'arrivée d'un nouveau Device sur le réseau. Chacun va pouvoir se rendre à l'adresse indiquée dans la description afin d'y trouver le fichier XML de description des services de l'horloge et s'abonner aux variables qui les intéresse. Rappelons ici que la TV est également un point de contrôle, elle a été programmée pour s'abonner à une horloge si un tel équipement arrivait sur le réseau. De façon automatique, la demande d'abonnement est alors envoyée de la TV vers l'horloge.

Eventing : A l'étape précédente, la TV a envoyé une demande d'abonnement à l'horloge. Celle-ci en retour lui envoie le “message initial” (voir 3.E.5). La TV est maintenant en mesure d'afficher la date et l'heure (en haut à gauche de l'écran). On peut remarquer que l'heure est bien mise à jour chaque seconde, ce qui veut dire que la TV reçoit un message Event toutes les secondes et qu'elle met à jour son affichage.

3.G.2.e Branchement du lave-lingeDiscovery : Le lave-linge va utiliser le protocole SSDP pour envoyer la liste de ses services aux points de contrôle présents sur le réseau.

Description : Les points de contrôle ont été avertis à l'étape précédente de l'arrivée d'un nouveau Device sur le réseau. Chacun va pouvoir se rendre à l'adresse indiquée dans la description afin d'y trouver le fichier XML de description des services du lave-linge et s'abonner aux variables qui les


intéresse.

3.G.2.f Branchement du climatiseurDiscovery : idem lave-linge

Description : idem

Eventing : A l'étape précédente, la TV a envoyé une demande d'abonnement au climatiseur. Celui-ci en retour lui envoie le message particulier (qui avait été nommé “message initial”). La TV est maintenant en mesure d'afficher la température ambiante donnée par le climatiseur (en haut à droite de l'écran).

3.G.2.g Tout ensembleEnvoyer des requêtes aux devices par le biais de la télécommande.On peut tout d'abord lancer un programme de lavage du lave-linge : il suffit de cliquer sur le bouton violet “Start” de la télécommande :

On cherche à montrer ici que les autres points de contrôle sont informés du changement. On regarde le résultat de la requête : allumage/extinction .... la TV sert à visualiser les différents changements.


4 OSGi™Ce chapitre est une introduction à OSGi. Il présente les concepts qu'un développeur Java doit connaître pour pouvoir créer ses propres composants et les interfacer avec ceux existants.

4.A L'alliance OSGiLe site web de l'OSGi Alliance est http://www.osgi.org/. Sur ce site, vous trouverez une présentation de l'alliance (voir l'extrait ci-dessous) ainsi qu'une introduction technique. Toutes les versions de la spécification OSGi sont également téléchargeables gratuitement, moyennant le remplissage d'un formulaire.

Founded in March 1999, the OSGi™ Alliance specify, create, advance, and promote wide industry adoption of an open service delivery and management platform. The OSGi Alliance serves as the focal point for a collaborative ecosystem of service providers, developers, manufacturers and consumers.

4.B OSGi en brefPlutôt que de (mal) paraphraser ce qui est (bien) dit par ailleurs, nous avons préféré « laisser la parole » à l'OSGi alliance [OSGi-A] pour résumer en quelques phrases la quintessence de OSGi.

The OSGi™ specifications define a standardized, component oriented, computing environment for networked services. Adding an OSGi Service Platform to a networked device (embedded as well as servers), adds the capability to manage the life cycle of the software components in the device from anywhere in the network. Software components can be installed, updated, or removed on the fly without having to disrupt the operation of the device. Software components are libraries or applications that can dynamically discover and use other components. Software components can be bought off the shelf or are developed in house.

4.C Architecture d'un Framework OSGiLe principal composant de [OSGi] est le Framework, qui fournit un environnement standardisé aux applications (appelées Bundles). Comme décrit sur le schéma ci-contre, le Framework est composé de plusieurs couches, avec au centre l'environnement Java nécessaire à l'exécution de OSGi.

La couche « Modules » définit la politique de chargement et de partage des classes Java. Le Framework utilise en effet un modèle de chargement des classes qui repose sur Java mais en cloisonnant ce que voit chaque application4. La couche « Modules » permet ainsi à chaque Bundle de choisir les classes qu'il veut garder privées (i.e. son implémentation) et celles qu'il accepte de partager avec les autres Bundles (i.e. son interface). Par exemple, les Bundles de type « bibliothèques de classes » n'ont pas de partie privée alors qu'à l'opposé, les Bundles applicatifs n'ont pas de partie publique. Entre ces deux cas, on trouve les Bundles offrant un Service et qui partagent leurs interfaces mais pas leurs implémentations.

4 Pour mémoire, il n'y a habituellement en Java qu'un seul classpath géré par un seul classloader et qui permet d'accéder à toutes les classes de l'application. OSGi permettant à plusieurs applications de cohabiter, il doit permettre à 2 applications de créer une même classe sans collision de nom.


© the OSGi Alliance


La couche « Cycle de vie » permet aux Bundles d'être dynamiquement installés, démarrés, arrêtés, mis à jour et désinstallés. Cette couche autorise un comportement dynamique qui n'existe habituellement pas dans une application Java5. Elle utilise la couche « Module » pour établir des liens au niveau des objets Java entre les Bundles.

Le « Service Registry » permet aux Bundles de découvrir et partager des services (i.e. des objets Java) entre eux, en utilisant une interface standardisée.

Enfin, se reposant sur ces trois couches ainsi que sur l'environnement Java viennent les Bundles (i.e. les applications).

4.D Patron de conception des services OSGiUn Service OSGi est défini par une Interface Java qui décrit l'ensemble des méthodes que le Service offre. L'interface peut en plus définir des constantes, des classes utilitaires, etc. Cette interface est « publiée » dans un Bundle « bibliothèque » qui ne contient que des définitions d'interfaces. Par exemple, le bundle « OSGi Service » contient toutes les interfaces standardisées par [OSGi] dans le package Java org.osgi.service.

Quand un Bundle veut offrir un service aux autres Bundles du Framework, il doit remplir 2 conditions :

implémenter l'interface correspondant au Service,

enregistrer dans le « Service Registry » la classe qui implémente le service.

Quand un Bundle veut utiliser un service, il peut :

faire une recherche dans le « Service Registry »,

attendre un événement système qui annonce l'arrivée d'un nouveau service.

4.E Quelques services standardisésL'alliance OSGi a spécifié de nombreux services qui reposent sur les fonctions offertes par le Framework. Voici une liste non exhaustive de services réprésentatifs :

Serveur HTTP : Il permet aux bundles de publier des fichiers et des servlets.

Configuration Admin : Ce service permet à l'administrateur du Framework de définir les configurations des Bundles.

User Admin : Ce service permet aux bundles de gérer l'authentification des utilisateurs ainsi que les autorisations associées.

Preferences : Ce service permet à chaque bundle de stocker des données spécifiques aux utilisateurs (meilleur score, personalisation de l'interface, ...)

Permission Admin : Ce service permet à l'administrateur de régler les permissions Java allouées à chaque Bundle.

Device Manager : Ce service permet de gérer le « hot-plug » des périphériques connectés au Framework.

UPnP Device : Ce service, qui n'est pour l'instant qu'une recommandation, permet aux bundles d'exporter et d'utiliser des services UPnP (voir les chapitres suivants).

5 Dans le cas « normal », l'application est démarrée directement par la JVM, et la JVM s'arrête en même temps que l'application. Dans le cas de OSGi, l'application (i.e. le Bundle) est démarrée et arrêtée par le Framework.


4.F Use CasePour une première prise en main de OSGi, le lecteur pourra se reporter au site web de [Oscar], plus particulièrement à la page http://oscar.objectweb.org/usage.html

4.G Devices et Drivers OSGiLe chapitre « Device Access Specification » de [OSGi] décrit un mécanisme pour installer à la volée et de façon transparente pour l'utilisateur les logiciels et autres firmwares nécessaires à l'utilisation d'un équipement connecté (au sens large) à la plateforme. Cette partie est très importante pour comprendre comment réaliser facilement des Control Points UPnP (voir 5.D, page 29) et des passerelles vers d'autres réseaux (voir 9, page 42).

[OSGi]

The Device Access specification supports the coordination of automatic detection and attachment of existing devices on an OSGi Service Platform, facilitates hot-plugging and -unplugging of new devices, and downloads and installs device drivers on demand.

4.G.1 EntitésVoir [OSGi] pour un schéma.

4.G.1.a Drivers OSGiIl s'agit de Drivers écrits en Java (au moins en partie) donc plutôt haut niveau.

4.G.1.b Base DriversCe ne sont pas des drivers au sens OSGi mais plutôt au sens conventionnel.

4.G.1.c Devices OSGiUn Device OSGi est reconnaissable au fait qu'il implémente le Service Device. Ce Service permet au Device Manager de communiquer avec le Device. Un Device n'est cependant intéressant que s'il implémente un autre service en rapport avec ses capacités.

4.G.1.d Device Manager, Driver Locator, Driver SelectorLe Device Manager surveille les apparitions et disparitions de Devices dans le framework. A chaque apparition et en se basant sur la Catégorie du Device, il charge avec l'aide du Driver Locator l'ensemble des Drivers susceptibles de pouvoir utiliser le nouveau Device. Ensuite chaque Driver analyse les données contenues dans le dictionnaire des propriétés du Device et renvoie une note au Device Manager. À noter que cette échelle des notes est propre à chaque Catégorie et doit être connue de tous les Drivers. Le Driver ayant donné la meilleure note est associé au Device.

4.H Use Case : Devices et DriversL'exemple donné ci-dessous va montrer comment le branchement d'une imprimante USB6 sur la plateforme déclenche le chargement des drivers les mieux adaptés à sa prise en charge7.

La plateforme étant équipée de prises USB, un Base Driver USB est actif : il surveille toutes les

6 Même si USB n'est pas officiellement géré en Java, nous avons décidé de l'utiliser dans cet exemple car ses principes sont maintenant bien connus des utilisateurs (voir par exemple http://jusb.sourceforge.net/ pour plus de détails).

7 Cet exemple n'est pas basé sur UPnP car l'objectif ici est de présenter la spécification « Device Access » à partir d'un cas imaginaire représentatif et de se focaliser uniquement sur les mécanismes OSGi. Le chapitre 5.D propose au contraire des scenarii utilisant UPnP comme Device Category.


http://jusb.sourceforge.net/

connexions et déconnexions.

Au branchement de l'imprimante, le Base Driver USB crée un Device et l'enregistre dans le Service Registry. Ce nouveau Device implémente les Services Device et USB et appartient à la catégorie USB. Le Service USB est défini par le Base Driver. Dans le dictionnaire des propriétés du Device, accessible via le Service Registry, le Base Driver a placé toutes les informations fournies par l'équipement USB. Le rôle du Base Driver se limite ainsi à créer un Device USB générique avec une interface « bas niveau » qui permet de dialoguer avec le véritable équipement sur le bus USB.

Le Device Manager détecte l'enregistrement de ce nouveau Device. Il charge alors l'ensemble des Drivers USB. Dans notre scénario, nous allons considérer que quelques Drivers génériques (un pour chaque grande famille d'équipements USB) sont chargés à cette étape. C'est bien sûr le Driver des Imprimantes USB qui remporte le match et se trouve attaché au Device.

Ce Driver n'a pas pour vocation de garder pour lui seul le Device qui lui a été attaché. Il crée donc un nouveau Device dans la catégorie « Imprimante USB » (qui est complètement différente de la catégorie USB). En terminologie OSGi, ce Driver est un Refining Driver.

Le Device Manager détecte aussitôt ce nouveau Device et charge les Drivers pour imprimantes USB. Le Driver correspondant à la marque et à la version de l'imprimante remporte le match et se trouve attaché au Device.

Ce Driver n'a évidemment pas non plus pour objectif de garder pour lui seul le Device qui lui a été attaché. Cependant il n'y a maintenant plus de raison d'affiner le service rendu par l'équipement distant. Au contraire il faut mettre les capacités d'impression de l'imprimante à la disposition de tous les Bundles. Dans ce cas, le Driver enregistre un Service d'impression (qui a été standardisé par ailleurs). Bien noter que ce Service n'est pas un Device mais un simple service OSGi.

Pour poursuivre notre exemple, considérons maintenant que la plateforme est aussi reliée à un réseau IP local. Sur ce réseau, l'utilisateur branche une imprimante qui implémente le protocole IPP. On obtient alors le scénario suivant :

Le Base Driver IPP8 détecte l'apparition d'une nouvelle imprimante et crée un Device Imprimante IPP.

Le Device Manager détecte ce nouveau Device et charge les Drivers pour imprimantes IPP. Le Driver correspondant à la marque et à la version de l'imprimante remporte le match et se trouve attaché au Device.

Ce Driver enregistre un Service d'impression (le même que dans l'exemple précédent). Tous les bundles du Framework ont maintenant le choix entre 2 imprimantes accessibles de façon identique.

8 On peut se demander comment ce Base Driver a été installé sur la plateforme. Plusieurs réponses sont possibles (aucune n'est d'ailleurs normalisée par [OSGi]). Soit l'utilisateur l'a explicitement installé, soit un espion IP a détecté l'utilisation du protocole IPP et a réagi en conséquence en installant le Base Driver (peut-être même en créant un Device dans la catégorie Protocole IP...)


5 Utilisation conjointe de UPnP™ et OSGi™Après avoir présenté UPnP et OSGi dans les chapitres précédents, il est temps de montrer comment les deux peuvent être utilisés ensemble pour leur plus grand bénéfice mutuel.

5.A Notion de micro-mondesSi l'on regarde les maisons actuelles, il est clair que tous les équipements ne sont pas UPnP. En fait, à part les PC utilisant Windows, la probabilité de trouver un Device UPnP dans une maison est actuellement presque nulle. Certains de ces équipements sont cependant communiquants et ils utilisent alors d'autres protocoles comme EHS/KNX, EIB ou X10. Certains équipements, comme les stores et les volets électriques, utilisent même des protocoles fermés et propriétaires.

Chacun de ces protocoles crée un réseau d'équipements communiquants entre eux que l'on appelera un micro-monde. La question qui se pose alors est : Est-il possible de connecter ces micro-mondes entre eux ? Et si oui, comment ? La réponse est bien évidemment « oui » et elle est justifiée par les chapitres qui suivent.

5.B Utiliser ensemble UPnP et OSGiLa première question que l'on peut se poser est alors de savoir qui de OSGi et UPnP encapsulera l'autre.

Si l'on regarde [DA] et [OSGi], il est clair que UPnP « ne connaît pas » OSGi, alors que la spécification OSGi consacre un chapitre entier sur la manière d'intégrer UPnP en tant que service. Donc, d'un point de vue purement pratique, le premier élément de réponse est que OSGi doit être « en-dessous » de UPnP.

Ensuite, d'un point de vue fonctionnel, OSGi est un conteneur de composants logiciels alors que UPnP est un protocole de communication réseau. Il semble donc logique de placer OSGi en-dessous de UPnP. Ainsi OSGi est le conteneur et UPnP est un des Services de communication réseau. De plus, cette approche a le mérite de permettre une inter-connexion facile de tous les réseaux physiques (IP, non-IP bas débit, vidéo...) et logiques (UPnP, contrôle-commande propriétaire, etc). Chaque réseau est alors modélisé par un ou plusieurs Bundles et il ne reste plus qu'à définir des interfaces standardisées (ce point est étudié en détail dans le chapitre 9, Relier un micro-monde à UPnP).

Enfin, du point de vue de l'utilisation des ressources mémoire et processeur -et sans vouloir lancer un débat- il semble plus facile d'ajouter la fonction UPnP à un équipement taillé pour de l'OSGi que le contraire. En effet, un équipement UPnP peut assez facilement être optimisé pour n'incorporer que ce dont il a besoin pour opérer de façon autonome ; alors qu'un équipement basé sur OSGi est a-priori plus polyvalent et le surcoût nécessaire à l'ajout de UPnP reste minime par rapport à l'ensemble des bibliothèques et services partagés.

5.C UPnP en tant que service OSGiLe chapitre « UPnP Device Service Specification » de [OSGi] définit comment rendre un réseau UPnP accessible aux Bundles d'un framework OSGi. Cette spécification se limite aux couches hautes de UPnP mais ce n'est cependant pas un problème car le but de ce document est bien d'expliquer comment utiliser et/ou développer des équipements UPnP. Les couches basses ont été développées et sont disponibles. Il existe même une implémentation open source ; elle a été développée par le projet [Domoware] à partir de l'implémentation Java de CyberLink. C'est cette implémentation que nous utiliserons dans le document.

La spécification a comme ambition de permettre les équivalences suivantes :


Un Bundle OSGi peut jouer le rôle de Control Point.

Un Service OSGi peut être exporté sur le réseau UPnP en tant que Device.

Les événements UPnP peuvent être reçus et transmis entre Bundles, Devices et Control Points.

5.D Un conteneur pour Control PointsComme évoqué dans 4.G page 26, OSGi offre des fonctionnalité intéressantes pour développer une passerelle capable de s'adapter dynamiquement aux équipements installés sur le réseau.

Cette section expliquera comment il est possible d'installer à la volée des Control Points UPnP adaptés aux Devices UPnP présents sur le réseau. Il s'agit en fait d'un cas particulier des bridges de la suite.

5.E Interface utilisateurLe service HTTP de OSGi permet de créer facilement une interface web à partir de fichiers contenus dans les bundles, de servlets et même d'applets. Cet accès web permet d'offrir à un device UPnP une interface facile à développer et déployer.


Seconde partie : DéveloppementCette seconde partie du document, après une présentation des technologies disponibles, explique comment :

développer un équipement UPnP en Java avec CyberLink9,

développer un bundle OSGi-UPnP avec Oscar et DomoWare,

connecter un réseau propriétaire à une passerelle OSGi en le faisant passer pour un réseau UPnP (via un pont réseau-propriétaire / UPnP),

modéliser en UPnP (Device, Service) un équipement non UPnP.

6 Présentation des technologies disponiblesCe chapitre liste brièvement les logiciels disponibles pour utiliser les technologies décrites dans le document.

6.A Implémentations UPnPVoici une liste non exhaustive de piles UPnP. Une liste plus détaillée est disponible sur le site du forum UPnP [UPnP-F] à l'URL : http://www.upnp.org/resources/sdks.asp

[Intel] fournit une pile de référence basée sur .NET ainsi qu'un ensemble d'outils téléchargeables gratuitement. Cette implémentation est la première et la plus complète. On y trouve des outils comme un point de contrôle universel (Device Spy), un générateur de descriptions UPnP (Device Author), quelques équipements multimédia, ...

Intel est très actif au niveau du Forum et rédige régulièrement de nouveaux DCPs. La spécification [NMPR] milite pour un renforcement des IHM dans UPnP.

[Siemens] possède une pile UPnP pour les langages C++ et java. Cette implémentation est propre et fonctionnelle et offre un bon niveau général, même si la documentation reste minimale. La version Java est parfaite pour l'implémentation car elle ne nécessite pas de se plonger dans le code. A noter cependant l'obscurantisme de certains noms de classes (A, AA, AB, ...).

CyberLink [CLK] fournit une pile UPnP open source en C++ et en Java. Cette implémentation est facile d'accès mais il lui manque (encore) beaucoup d'outils pour concurrencer les fonctionnalités de la pile [Intel], notamment les composants d'annonce sur le réseau.

Le projet [Domoware] utilise la version Java de CyberLink [CLK] pour offrir une implémentation du Service UPnP décrit par [OSGi].

[UPNPLib] est une autre implémentation libre en Java de la pile UPnP.

Le chapitre 7 offre une introduction à CyberLink [CLK] et [Domoware]. Il est aussi possible de trouver sur le web d'autres formations, comme par exemple sur les sites des fournisseurs des piles UPnP décrites précédemment.

6.B Implémentations OSGiVoici une liste non exhaustive de frameworks OSGi. Une liste plus détaillée est maintenue par [OSGi-

9 Apprendre à développer avec CyberLink (même si ça ne couvre pas l'objectif d'utiliser OSGi) est utile pour comprendre Domoware, et cela permet de tester UPnP en dehors du cadre de OSGi.


A].

[Oscar] est l'implémentation libre que nous utilisons dans ce document. Pour être précis, Oscar n'est que la partie framework de [OSGi] mais il existe un serveur « officiel » de bundles (Oscar Bundle Repository sur sourceforge) qui contient la majorité des services décrits dans [OSGi].

Knopflerfish [KFish] est une autre implémentation libre. Ayant une origine commerciale (Gatespace Telematics), sa base des services standardisés est plus importante que pour Oscar. Mais la bonne nouvelle est que ses bundles sont utilisables sans difficulté par Oscar (la réciproque est aussi vraie bien sûr).

ProSyst a développé le framework commercial mBeddedServer (http://www.prosyst.com/).

SMF est la solution OSGi de IBM (http://www-306.ibm.com/software/wireless/smf/).

6.C Autres outils

6.C.1 Environnement de développement intégréEclipse (http://www.eclipse.org/) est une des références en matière d'environnement de développement pour Java. À noter qu'à partir de la version 3, Eclipse intègre le framework SMF de IBM pour gérer la modularité.

6.C.2 Génération automatiqueEn combinant la génération de descriptions XML de l'outil de [Intel] et la génération de code Java de l'outil de Didier Donsez [Donsez-BR], il est en théorie possible de générer un device UPnP avec des connaissances minimales. En pratique, ces outils sont une aide appréciable pour les développeurs déjà expérimentés.


http://www.eclipse.org/

http://www-306.ibm.com/software/wireless/smf/

http://www.prosyst.com/

7 Technologies Java™ Open Source Ce chapitre présente les technologies que nous utilisons pour développer des équipements et des Bridges UPnP. Il s'agit de logiciels open source.

7.A Oscar[Oscar]

Oscar is an open source implementation of the Open Services Gateway Initiative (OSGi) framework specification; the goal is to provide a completely compliant implementation of the OSGi framework specification. Oscar is currently compliant with a large portion of the OSGi 3 specifications, although certain compliance work still needs to be completed. Despite this fact, the OSGi framework functionality provided by Oscar is very stable and is in use by many people.

Even though OSGi targets the embedded device market, the framework is ideally suited for experimenting with component-oriented and service-oriented computing in general. For example, Oscar can be easily embedded into other projects and used as a plugin or extension mechanism

7.B CyberLink for JavaCyberLink est une implémentation open source en Java de la pile complète UPnP. Il permet de transformer un PC (ou tout autre équipement avec une JVM) soit en Device, soit en Control Point, soit les deux. Par exemple, le PC peut annoncer de véritables Devices tels qu'un MediaServer ou un MediaRenderer. Et bien sûr, il est aussi possible de simuler des équipements UPnP depuis le PC, comme par exemple une lampe, un lave-linge, ...

7.B.1 Implémentation d'un DevicePour avoir une vision de la classe Device implémentée dans CyberLink, il est conseillé de se reporter au document [CLK-PG], chapitre 3.1. On y trouve un diagramme de classe simplifié, dans lequel l'auteur n'a présenté que l'essentiel pour programmer un Device.

Si le lecteur veut approfondir, il peut se référer à la javadoc téléchargeable sur le site de cybergarage. Cependant, celle-ci est très peu documentée et elle n'est donc pas facile d'utilisation.

7.B.1.a Fichier de description XMLVoir le paragraphe 3.F.2 pour les détails d'écriture des fichiers de description.

La base d'un Device UPnP repose sur les fichiers XML qui le décrivent, et ce, quelle que soit la pile UPnP utilisée. La toute première étape pour la création d'un Device UPnP est l'écriture de ces fichiers.

Pour cela, il faut se référer à [DA], paragraphe 2 : Description.

7.B.1.b Premiers pasCréer un Device avec CyberLink se fait par héritage : il faut créer une classe qui hérite de la classe Device. Ceci est fait de la façon suivante :

import org.cybergarage.upnp.*;Import org.cybergarage.upnp.device.*;...............public class MyUPnPDevice extends Device implements ActionListener,


QueryListenerTry {Device myDevice = new Device(« description/description.xml »);...........myDevice.start();.........myDevice.stop();

}catch (InvalidDescriptionException e) {............

}...........

L'exception InvalidDescriptionException est lancée lorsque le fichier de description est d'un format non valide. On peut utiliser la méthode e.getMessage() pour en savoir un peu plus.

Que se passe t-il lors de l'exécution de ce tout petit bout de code ?

1. Tout d'abord, le fichier de description est parsé et sa validité est vérifiée par xerces. S'il n'est pas correct, l'exception est lancée et l'exécution s'arrête là.

2. Si le fichier de description est correct, une instance de l'objet Device est créée. Dans tous les cas, l'objet ainsi créé est un root Device. De façon transparente pour le programmeur, le contructeur de la classe Device va lire le fichier de description du Device, accéder aux fichiers de description des services, et construire toutes les données dont elle aura besoin pour fonctionner dans un environnement UPnP. Le paragraphe suivant explique comment accéder aux différents éléments du Device mais nous n'avons pas besoin de savoir, pour programmer un Device, comment ces données sont organisées au sein de la classe.

3. Lors de l'appel à la méthode start(), le Device fraîchement créé entre dans la phase de Notify. Un message ssdp::alive est automatiquement envoyé sur le réseau, et trois messages NOTIFY peuvent être visualisés. Reprenons l'exemple de l'horloge. Lors de la création de l'objet horloge, voici les messages qui ont été automatiquement envoyés sur le réseau UPnP :

NOTIFY * HTTP/1.0SERVER: Windows 2000/5.0 UPnP/1.0 CyberLink/1.3.2CACHE-CONTROL: max-age=60LOCATION: http://192.168.200.231:4004/description.xmlNTS: ssdp:aliveNT: upnp:rootdeviceUSN: uuid:6d7f-a101-d03-e091::upnp:rootdeviceHOST: 239.255.255.250:1900NOTIFY * HTTP/1.0SERVER: Windows 2000/5.0 UPnP/1.0 CyberLink/1.3.2CACHE-CONTROL: max-age=60LOCATION: http://192.168.200.231:4004/description.xmlNTS: ssdp:aliveNT: urn:schemas-upnp-org:device:clock:1USN: uuid:6d7f-a101-d03-e091::urn:schemas-upnp-org:device:clock:1HOST: 239.255.255.250:1900NOTIFY * HTTP/1.0SERVER: Windows 2000/5.0 UPnP/1.0 CyberLink/1.3.2CACHE-CONTROL: max-age=60LOCATION: http://192.168.200.231:4004/service/timer/description.xmlNTS: ssdp:aliveNT: urn:schemas-upnp-org:service:timer:1


USN: uuid:6d7f-a101-d03-e091::urn:schemas-upnp-org:service:timer:1HOST: 239.255.255.250:1900

Le premier annonce l'arrivée d'un nouveau RootDevice sur le réseau. Le second annonce l'arrivée d'un embeddedDevice, une clock. Enfin, le troisième annonce le seul service proposé par de Device : le service timer.

4. Lorsque le programmeur souhaite retirer son Device du réseau, il lui suffit d'appeler la méthode myDevice.stop(). L'appel de cette méthode aura pour effet d'envoyer le message ssdp::byebye sur le réseau UPnP et à nouveau trois messages peuvent être visualisés sur le réseau :

NOTIFY * HTTP/1.0NTS: ssdp:byebyeNT: upnp:rootdeviceUSN: uuid:6d7f-a101-d03-e091::upnp:rootdeviceHOST: 239.255.255.250:1900NOTIFY * HTTP/1.0NTS: ssdp:byebyeNT: urn:schemas-upnp-org:device:clock:1USN: uuid:6d7f-a101-d03-e091::urn:schemas-upnp-org:device:clock:1HOST: 239.255.255.250:1900NOTIFY * HTTP/1.0NTS: ssdp:byebyeNT: urn:schemas-upnp-org:service:timer:1USN: uuid:6d7f-a101-d03-e091::urn:schemas-upnp-org:service:timer:1HOST: 239.255.255.250:1900

7.B.1.c Les composants de CyberLinkNous venons de voir que CyberLink nous permet de créer des Device UPnP de façon très rapide et facile. Il nous faut maintenant apprendre à les manipuler. Dans ce paragraphe, nous allons reprendre les exemples de code du document [CLK-PG] et les commenter :

Comment accéder aux « embeddedDevices »La méthode à appeler est getDeviceList(). Cette méthode retourne un objet DeviceList qui fait partie du package org.cybergarage.upnp et qui hérite de la classe Vector. On peut ensuite accéder à chaque Device par la méthode getDevice(n) de la classe DeviceList, n représentant le rang du Device dans la liste.

Voici l'extrait de code du document [CLK-PG] :

public void printDevice(Device dev){String devName = dev.getFriendlyName();System.out.println(devName);DeviceList childDevList = dev.getDeviceList();int nChildDevs = childDevList.size();for (int n=0; n<nChildDevs; n++) {

Device childDev = childDevList.getDevice(n);printDevice(childDev);

}}......Dev rootDev = ....;...DeviceList childDevList = rootDev.getDeviceList();int childDevs = childDevList.size();for (int n=0; n< childDevs; n++) {


Device childDev = rootDevList.getDevice(n);printDevice(childDev);

}

On a également la possibilité d'accéder aux Devices embarquées par leur nom (FriendlyName) par le biais de la méthode getDevice(name) de la classe Device. Name représentant alors le FriendlyName. Voici un exemple d'utilisation de cette méthode :

Device homeServerDev ....Device musicDev = homeServerDev.getDevice(“music”);

Comment accéder aux services, à ses actions et à ses variables d'étatDe façon similaire, il existe des méthodes pour accéder aux services du Device, ainsi qu'à ce qui le compose (actions et variables d'état). Il s'agit de :

Trois méthodes qui retournent un objet qui hérite de la classe Vector afin de gérer les listes :

getServiceList() est une méthode de la classe Device et retourne un objet ServiceList

getActionList() est une méthode de la classe Service et retourne un objet ActionList

getServiceStateTable() est une méthode de la classe Service et retourne un objet ServiceStateTable

Chacun de ces objets possède une méthode qui permet au programmeur d'accéder à un objet particulier en passant son rang en argument :

getService(n) pour la classe Service

getAction(n) pour la classe ActionList

getServiceStateVariable(n) pour la classe ServiceStateVariable

Device dev ....ServiceList serviceList = dev.getServiceList();int serviceCnt = serviceList.size();for (int n=0; n<serviceCnt; n++) {Service service = serviceList.getService(n);ActionList actionList = service.getActionList();int actionCnt = actionList.size();for (int i=0; i<actionCnt; i++) {

Action action = actionList.getAction(i);System.out.println(“action [“ + i + “] = “ + action.getName());

}ServiceStateTable stateTable = service. GetServiceStateTable ();int varCnt = stateTable.size();for (int i=0; i<actionCnt; i++) {

StateVariable stateVar = stateTable.getServiceStateVariable(i);System.out.println(“stateVar [“ + i + “] = “ + stateVar.getName());

}}

Tout comme pour les Device embarquées, on peut également accéder aux différents objets par les « FriendlyNames » :

Device clockDev ....Service timerSev = clockDev.getService(“timer”);Action getTimeAct = clockDev.getAction(“GetTime”);StateVariable timeStat = clockDev.getStateVariable(“time”);


7.B.1.d Remote ControlPour permettre le contrôle du Device par un point de contrôle, celui-ci doit implémenter l'interface ActionListener. La méthode actionControlReceived(Action act) permet au programmeur de réaliser l'action attendue par le point de contrôle. A partir de l'objet Action, on peut accéder aux valeurs passées par le point de contrôle et mettre l'argument de sortie de l'action à la bonne valeur. Il est conseillé de se reporter à la javadoc pour plus de détails. La méthode doit retourner true si l'action est valide et false sinon.

Si le Device n'a pas implémenté l'interface ou que la valeur de retour de la méthode est false, une trame UPnPError est automatiquement envoyée au point de contrôle. Par défaut, la valeur de l'erreur est INVALID_ACTION. Le programmeur a toutefois la possibilité de changer celle-ci en utilisant la méthode Action.setStatus.

Les points de contrôle peuvent également demander à lire la valeur d'une variable. Pour cela, le Device doit implémenter l'interface QueryListener. Celle-ci est symétrique à l'interface ActionListener et possède les même méthodes. Nous ne développons donc pas plus.

L'exemple suivant doit être assez clair :

public class ClockDevice extends Device implements ActionListener, QueryListener{public ClockDevice(){

super (“/clock/www/description.xml”);Action setTimeAction = getAction(“SetTime”);setTimeAction.setActionListener(this);Action getTimeAction = getAction(“GetTime”);getTimeAction.setActionListener(this);StateVariable stateVar = getStateVariable(“Timer”);stateVar.setQueryListener(this);

}public boolean actionControlReceived(Action action){

ArgumentList argList = action.getArgumentList();String actionName = action.getName();if (actionName.equals("SetTime") == true) {

Argument inTime = argList.getArgument(“time”);String timeValue = inTime.getValue();If (timeValue == null || timeValue.length() <= 0)

return false;....Argument outResult = argList.getArgument(“result”);arg.setValue(“TRUE”);return true;

}else if (actionName.equals(“GetTime”) == true) {

String currTimeStr = …..Argument currTimeArg = argList.getArgument(“currTime”);currTimeArg.setValue(currTimeStrs);return true;

}action.setStatus(UPnP::INVALID_ACTION, “…..”);return false;

}public bool queryControlReceived(StateVariable stateVar){

if (varName.equals(“Time”) == true) {


String currTimeStr = ….;stateVar.setValue(currTimeStr);return true;stateVar.setStatus(UPnP::INVALID_VAR, “…..”);return false;

}}

7.B.1.e EventingL'abonnement et le désabonnement des points de contrôle aux évènements du Device sont gérés de façon automatique. Le programmeur doit juste implémenter la méthode ServiceStateVariable.setValue() pour l'autoriser. L'exemple ci-dessous met à jour une variable d'état et la nouvelle valeur est distribuée aux souscripteurs automatiquement.

Device clockDevice = ....StateVariable timeVar = clockDevice.getStateVariable("Time");String timeStr = .....timeVar.setValue(timeStr);

7.B.2 Implémentation d'un Control PointTout comme pour l'implémentation des Devices, il est conseillé de se reporter au document [CLK-PG], chapitre 4.1 pour avoir une vision de la classe Device implémentée dans CyberLink.

D'autre part, comme nous venons de le voir pour l'implémentation des Devices, CyberLink fait beaucoup de choses de façon automatique et transparente pour le programmeur. Il suffit pour cela d'implémenter la bonne interface et/ou la bonne méthode. Nous nous contenterons donc dans ce chapitre de présenter les interfaces et les méthodes à implémenter.

7.B.2.a Premiers pasCréer un Point de Contrôle avec CyberLink se fait par héritage : il faut créer une classe qui hérite de la classe ControlPoint.

Ceci est fait de la façon suivante :

import org.cybergarage.upnp.*;import org.cybergarage.upnp.device.*;……ControlPoint ctrlPoint = new ControlPoint();……ctrlPoint.start();

C'est lors de l'exécution de la méthode start(), que le point de contrôle est effectivement créé sur le réseau UPnP. Le point de contrôle fraîchement créé entre alors dans la phase de Notify. Un message ssdp::discover est automatiquement envoyé sur le réseau, et un message M-SEARCH peut être visualisé :

M-SEARCH * HTTP/1.0ST: upnp:rootdeviceMX: 3MAN: "ssdp:discover"HOST: 239.255.255.250:1900

7.B.2.b Découverte des Root DevicesUn programmeur peut accéder à la liste des Devices qu'il a déjà découvert par l'intermédiaire de la


méthode getDeviceList() de la classe ControlPoint. Cette méthode retourne un objet DeviceList.

Voici un exemple :

ControlPoint ctrlPoint = new ControlPoint();……ctrlPoint.start();……DeviceList rootDevList = ctrlPoint.getDeviceList();int nRootDevs = rootDevList.size();for (int n=0; n<nRootDevs; n++) {Device dev = rootDevList.getDevice(n);String devName = dev.getFriendlyName();System.out.println(“[“ + n + “] = ” + devName);

}

7.B.2.c NotificationsPour permettre au point de contrôle de recevoir les messages NOTIFY envoyés par les Devices UPnP présents sur le réseau, le programmeur doit implémenter l'interface NotifyListener.

7.B.2.d Contrôle d'un DeviceLes méthodes SetArgumentValue et postControlAction de la classe Action permettent au programmeur de contrôler un Device.

La méthode SetArgumentValue affecte une valeur à un argument. Elle doit être appelée autant de fois qu'il y a d'argument d'entrée pour l'action. Car pour que l'action soit effectivement réalisée, il faut obligatoirement donner une valeur à chaque argument en entrée de l'action. (Remarque : si le programmeur donne une valeur à l'argument de sortie, cela n'aura aucun effet).

Si au moins l'un des arguments en entrée n'a pas reçu de valeur, l'action ne sera pas réalisée.

C'est en faisant un appel à la fonction postControlAction que le programmeur sait si l'action a été réalisée ou non.

Voici un exemple pour le Device Clock :

Device clockDev = ....Action setTimeAct = clockDev.getAction(“SetTime”);String newTime = ....setTimeAct.setArgumentValue(“time”, newTime); // setTimeAct.getArgument(“time”).setValue(newTime);if (setTimeAct.postControlAction() == true) {ArgumentList outArgList = setTimeAct.getOutputArgumentList();int nOutArgs = outArgList.size();for (int n=0; n<nOutArgs; n++) {

Argument outArg = outArgList.getArgument(n);String name = outArg.getName();String value = outArg.getValue();......

}}else {UPnPStatus err = setTimeAct.getUPnPStatus();System.out.println("Error Code = " + err.getCode());System.out.println("Error Desc = " + err.getDescription());

}

Un point de contrôle peut vouloir faire une requête sur une variable d'état d'un Device. Pour savoir si c'est possible, il utilise la méthode postQueryControl de la classe StateVariable. Si le retour de la méthode est true, il peut alors utiliser la méthode getValue de la classe StateVariable :


Device clockDev = ....StateVariable timeStateVar = clockDev.getStateVariable(“time”);if (timeStateVar.postQueryControl() == true) {String value = timeStateVar.getValue();......

}else {UPnPStatus err = timeStateVar.getUPnPStatus();System.out.println("Error Code = " + err.getCode());System.out.println("Error Desc = " + err.getDescription());

}

Il est possible, dans le fichier de description d'un service, de donner un intervalle de valeurs ou une liste de valeurs possibles pour un argument. (Se reporter au document [DA] pour plus de détails). Un point de contrôle peut avoir besoin de ces informations. Il lui suffit pour cela de faire des appels aux méthodes hasAllowedValueRange/ getAllowedValueRange et hasAllowedValueList/ getAllowedValueList de la classe StateVariable :

Device clockDev = ....Action timeAct = clockDev.getAction(“SetTime”);Argument timeArg = timeAct.getArgument(“time”);StataVariable stateVar = timeArg.getRelatedStateVariable();if (stateVar != null) {if (stateVar.hasAllowedValueRange() == true) {

AllowedValueRange valRange = stateVar.getAllowedValueRange();......

}if (stateVar.hasAllowedValueList() == true) {

AllowedValueList valList = stateVar.getAllowedValueList ();......

}}

7.B.2.e Event MessagesPour recevoir les messages que les Devices envoient pendant la phase Event, un point de contrôle doit simplement s'abonner par le biais de la méthode subscribe de la classe ControlPoint et implémenter l'interface EventListener. Celle-ci possède une méthode eventNotifyReceived qui a pour arguments toutes les caractéristiques de la variable d'état qui est l'objet du message Event.

La méthode subscribe retournera true quand la souscription est acceptée par le Device. Le programmeur a alors accès au « subscriptionID » et au « timeout » correspondants :

public MyControlPoint extends ControlPoint implements EventListener{public MyControlPoint(){

.....addEventListener(this);

}.....public void eventNotifyReceived(String uuid, long seq, String name, String

value){

....}

}..................


ControlPoint ctrlPoint = .....Device clockDev = ctrlPoint.getDevice(“xxxx-clock”);Service timeService = clockDev.getService(“time:1”);boolean subRet = ctrlPoint.subscribe(timeService);if (subRet == true) {String sid = timeService.getSID();long timeout = timeService.getTimeout();

}

7.B.3 Astuces de codageL'utilisation de classes internes anonymes pour les call-backs des Listeners UPnP permet d'avoir un code plus efficace et plus compact.

7.C DomoWareUn tutoriel est disponible sur [Domoware].

7.D ExercicesCe chapitre présente au lecteur quelques idées d'exercices pour bien prendre en main UPnP et OSGi. Ces exercices peuvent être faits d'abord avec CyberLink, puis adaptés dans DomoWare. Et bien sûr, afin de contribuer au grand mouvement Open Source, il est recommandé de faire les exercices très proprement et de diffuser le code développé sous une licence libre.

Partir d'un des exemples fournis et tenter de le refaire « from scratch » (écriture des descriptions XML des Devices et Services, codage en Java).

Implémenter un autre Device UPnP standardisé.

Implémenter un Control Point générique (genre SDK) ou spécifique (e.g. Multimedia).

[Donsez-BR] contient de nombreux exemples de bundles OSGi. Un exemple qui nous intéressera plus particulièrement est la génération automatique de Device UPnP en Java à partir d'une description XML:

http://www-adele.imag.fr/~donsez/dev/osgi/upnpgendevice/


8 UPnP™ Device DescriptionCe chapitre étudie la manière de représenter un équipement d'un micro-monde (voir 5.A, page 28) dans le monde UPnP (première section ci-dessous) et réciproquement (deuxième section). Le premier point permet d'offrir à des Control Points UPnP un accès transparent à des équipements non-UPnP. Le deuxième point permet de rendre visibles des Devices UPnP en dehors du monde UPnP (et donc de simuler des Control Points).

Ici, on ne s'intéresse pas à la manière d'échanger des messages entre différents mondes (c'est l'objectif du chapitre suivant) mais simplement à la façon de modéliser les capacités d'un équipement.

8.A Associer les fonctionnalités existantes à une description UPnPLe premier problème d'un développeur qui veut rendre visible son équipement non-UPnP aux Control Points UPnP est de fournir une Description UPnP (voir 3.F page 13). Plusieurs cas de figures existent :

Si l'équipement est 100% équivalent à un Device UPnP, il suffit de prendre la description standardisée par le UPnP Forum et de la compléter avec les informations du vendeur [purple-italic].

Si l'équipement reprend toutes les fonctions d'un Device UPnP standardisé par le UPnP Forum et en ajoute d'autres en plus, il faut prendre la description la plus proche et y ajouter les Devices et/ou Services supplémentaires, standardisés ou non.

Si l'équipement n'a rien à voir avec ce qui existe déjà (par exemple un lave-linge), il faut repartir du profil Basic Device et utiliser les templates et les check-lists. Cependant, même si le Device n'existe pas, il faut voir si certains Services standardisés peuvent être utiles (par exemple, Switch Power dans Lighting Controls).

Si l'équipement ressemble à un Device UPnP standardisé mais avec des déviations, il faut aussi repartir du profil Basic Device et tenter de réutiliser au maximum des parties déjà existantes.

A noter que ces 4 cas sont supportés en standard par UPnP – c'est tout l'intérêt de XML et de la découverte dynamique de fonctions. Cependant, un Device qui implémente des fonctions non standard risque d'être mal ou peu géré par un Control Point générique, qui ne saura pas comment gérer ces extensions propriétaires. Deux solutions à ça : soit faire accepter en tant que standard les extensions, soit fournir son propre Control Point - les deux n'étant d'ailleurs pas incompatibles.

8.B Traduire une description UPnP dans un protocole propriétaireScénario : une centrale domotique non-UPnP est intéressée par des lampes manoeuvrables à distance via UPnP. Elle doit être capable de gérer les commandes des lampes.


9 Relier un micro-monde à UPnPCe chapitre étudie comment relier un réseau non-UPnP et un réseau UPnP par l'intermédiaire d'une passerelle OSGi. La fonction logicielle qui permet de réaliser ce lien sera appelée un « Bridge ».

La première question porte sur l'accès physique (électromagnétique) aux réseaux. Ensuite, en fonction des besoins, il faut choisir entre une connexion uni-directionnelle ou bi-directionnelle.

9.A Couche physiqueL'hypothèse de départ de ce document est l'utilisation de OSGi comme plate-forme fédérative. Ceci veut dire que la plate-forme doit pouvoir accéder physiquement (couches basses) au réseau non-UPnP. Cet accès nécessite a-priori un « modem » qui transforme le signal électromagnétique du réseau en un signal compatible avec la passerelle, par exemple, via une connexion série (type RS232) ou via un port USB. Du côté du logiciel embarqué dans la plate-forme, un ou plusieurs Bundles (le « bridge ») interprètent le signal en provenance du modem et le transforme en objets Java de plus haut niveau.

9.B Pont à sens uniquePour des réseaux simples de type contrôle-commande, un pont à sens unique (one-way bridge) du réseau propriétaire vers OSGi-UPnP semble suffisant. On évite alors la plupart des difficultés qui seront décrites dans le cas des ponts bidirectionnels.

La notion de « one-way » est au niveau applicatif. Le bridge permet bien sûr de transférer des données dans les 2 sens, à l'initiative du Device non-UPnP (sur le réseau propriétaire) ou du Control Point (sur la plate-forme OSGi).

En théorie, il est aussi possible d'avoir un « one-way bridge » qui met en relation des Devices UPnP côté OSGi avec des Control Points simulés par le réseau propriétaire. Mais en pratique, vu les réseaux considérés cela semble très improbable.

9.C Pont bidirectionnelCette section s'attaque au cas générique où il y a des équipements UPnP réels sur le réseau UPnP et des équipements UPnP simulés (Devices et Control Points) sur le réseau propriétaire.

9.C.1 Comment gérer un export UPnP vers les réseaux pontésComme il a été expliqué au chapitre 5, OSGi a défini un service UPnP qui permet de « mapper » un vrai réseau UPnP dans OSGi. Nous allons étudier ici comment fédérer des réseaux variés sous la bannière UPnP.

D'un point de vue très technique, il faut étudier comment un bridge peut

publier ses pseudo-Device UPnP dans la plate-forme OSGi pour être utilisés par d'autres bundles et pour être diffusé sur le vrai réseau UPnP et/ou les réseaux d'autres Bridges,

découvrir les Devices UPnP visibles sous forme de services OSGi et les émuler sur son propre réseau privé (problème d'adressage, ...).

Un autre point intéressant à valider est la traversée de 2 bridges : un pseudo Control-Point UPnP commande un pseudo Device UPnP sur un autre réseau.


9.D Exemple: Ponter un réseau X10Cette section démontre comment les concepts décrits précédemment peuvent être mis en œuvre pour augmenter la visibilité d'équipements non-UPnP au delà de leur propre réseau. Après un résumé des caractéristiques de X10 et des composants OSGi qui doivent être installés, nous verrons comment créer un one-way bridge. L'objectif est ici de rendre visible un interrupteur X10 sous la forme d'une lampe UPnP.

9.D.1 Caractéristiques X10Le réseau X10 utilise la technologie du courant porteur pour véhiculer des messages depuis les émetteurs vers les récepteurs. Le réseau ainsi créé est mono-directionnel : il n'y a pas de voie de retour.

Chaque équipement récepteur possède une adresse composée d'une lettre (de A à P) et d'un chiffre (de 1 à 16), ce qui permet de définir au maximum 256 adresses. Plusieurs équipements peuvent cependant partager une même adresse s'ils doivent être actionnés de la même façon (par exemple toutes les lampes d'une même pièce).

9.D.2 Pont à sens uniqueComme expliqué ci-dessus, un réseau X10 est mono-directionnel par construction. Il n'y a donc pas de possibilité de réaliser un bridge bi-directionnel. L'absence de découverte dynamique des équipements récepteurs (mécanisme de Plug'n Play) limite encore plus les possibilités du bridge.

9.D.3 Hardware X10Dans notre exemple, le modem X10 est un module émetteur générique qui permet de transmettre sur le réseau électrique les commandes X10 reçues via une liaison série. Cette liaison série est reliée à la passerelle.

9.D.4 Composants OSGi

9.D.4.a Base Driver OSGi X10Comme expliqué dans 4.G, Devices et Drivers OSGi, il faut installer un « Base Driver » pour pouvoir utiliser le modem X10 relié à la passerelle. Ce Driver connaît le formalisme (propriétaire) utilisé par le modem. Il présente une interface Java qui permet à d'autres bundles de transmettre des commandes X10 vers les équipements du réseau.

Malheureusement comme X10 n'offre pas de mécanisme de détection de type Plug'n Play, le Base Driver ne pourra créer aucun « OSGi Device » susceptible d'être affiné automatiquement comme décrit dans 4.G. Les principes décrits dans 4.G restent néanmoins valables : l'utilisateur (ou l'installateur) installe manuellement chaque Bundle prenant en charge un type d'équipements X10 présents dans la maison. Puis il le configure pour envoyer les ordres aux bonnes adresses.

9.D.4.b Pont X10 UPnPEn respectant les contraintes évoquées ci-dessus sur l'installation d'un « OSGi Device » X10, il est alors possible de créer un contrôleur X10 qui offre une interface UPnP d'un équipement X10 réel.

9.D.5 Exemple : Light AdapterNous montrons ici comment un interrupteur X10 peut être rendu accessible aux Control Points UPnP sous le modèle d'une lampe. Nous sommes pour cela partis de la « binaryLight » de Domoware et nous lui avons ajoutée l'accès au réseau X10.


9.D.5.a Lampe DomowareL'exemple implémenté par Domoware utilise le design pattern « Model, View, Controller » pour séparer la représentation interne de l'état de la lampe (le modèle), les actions (le contrôleur) et les retours vers l'utilisateur (les vues). L'exemple utilise des mécanismes des Java Beans, et tout particulièrement le mécanisme des bound properties pour diffuser les modifications aux vues.

Rappel sur les « bound properties » :Il est possible d'informer d'autres composants du changement de la valeur d'une propriété d'un bean. Les java beans peuvent mettre en place un mécanisme qui permet pour une propriété d'enregistrer des composants qui seront informés du changement de la valeur de la propriété. Ce mécanisme peut être mis en place grâce à un objet de la classe PropertyChangeSupport qui permet de simplifier la gestion de la liste des écouteurs et de les informer des changements de valeur d'une propriété. Cette classe définit les méthodes addPropertyChangeListener() pour enregistrer un composant désirant être informé du changement de la valeur de la propriété et removePropertyChangeListener() pour supprimer un composant de la liste. La méthode firePropertyChange() permet d'informer tous les composants enregistrés du changement de la valeur de la propriété.

9.D.5.b Listener X10Pour faire fonctionner notre exemple, nous avons ajouté un Listener que nous avons nommé LightX10. C'est lui qui fait le lien entre le monde X10 et le monde UPnP de Domoware : il est capable de chercher la présence d'un Base Driver pour pouvoir accéder au réseau X10, tout en recevant les notifications de changement des « bound properties ».

9.D.5.c Diagramme de classesLe diagramme de classes ci-contre résume l'implémentation mise-en-oeuvre.


UpnPStateVariable[]

statustarget

UpnPAction

GetTargetAction

UpnPAction

SetTargetAction

UpnPAction

GetStatusAction

UPnPService

PowerSwitchService

LightModel

BoundProperties :statustargetfailure

Listener

LightX10

Listener

LightUI

10 ConclusionCe document vous a d'abord présenté OSGi™ et UPnP™, deux technologies à l'avenir plein de promesses :

UPnP™ est un standard émergent pour le contrôle à distance d'équipements domestiques (du multimédia au HVAC en passant par le monde du PC). UPnP™ permet (en théorie) de faire le lien entre la micro-informatique personnelle (type Mac ou PC) et l'informatique enfouie dans le matériel. Cependant UPnP™ utilise IP pour ces communications, ce qui le limite de-facto à des environnements capables d'implémenter une pile IP.

OSGi™ est une couche logicielle au-dessus du système d'exploitation qui permet de simplifier le déploiement d'applications variées dans un parc hétérogène. OSGi™ repose sur le langage Java™ pour garantir l'indépendance vis à vis du processeur et sur un mécanisme d'appairage de services entre différents fournisseurs. L'installation de nouvelles applications peut se faire de façon dynamique et « à chaud ».

Ce document a ensuite montré pourquoi ces deux technologies sont complémentaires. En effet, lorsqu'elles sont réunies, elles permettent de décupler les capacités d'une passerelle domestique.

La passerelle sert ainsi de traducteur UPnP™ pour tous les micro-mondes domestiques qui ne peuvent pas implémenter une pile UPnP™.

Ces micro-mondes sont installés en fonction des besoins par le téléchargement de nouvelles applications OSGi™ (à l'achat, la passerelle n'est qu'une boîte vide qui se remplira en fonction des équipements présents chez l'utilisateur).

La passerelle télécharge au fur et à mesure les « drivers » OSGi™ dont elle a besoin pour faire la traduction entre UPnP™ et les réseaux propriétaires réels. Ces drivers peuvent être soit génériques, soit fournis par un constructeur pour utiliser les capacités spécifiques à chaque modèle.

En résumé, utiliser conjointement OSGi™ et UPnP™ offre les avantages suivants :

Cohérence : Grâce à UPnP™, tous les équipements sont perçus de la même façon quelle que soit leur origine.

Déploiement : OSGi™ est un conteneur qui permet le téléchargement à la demande de logiciels.

Virtualisation : Les équipements des micro-mondes non UPnP™ sont simulés par la passerelle et peuvent ainsi être utilisés par de vrais contrôleurs UPnP™.

Virtualisation « inverse » : Lorsque le micro-monde le permet, les équipements UPnP™10 peuvent être exportés dans le micro-monde pour être utilisés par ses contrôleurs (par exemple, une centrale d'alarme peut modifier l'éclairage).

Ouverture : OSGi™ et UPnP™ étant des standards ouverts, tout constructeur peut facilement fournir un module d'adaptation.

10 Ces équipements peuvent être réellement UPnP™ ou bien être simulés par la passerelle depuis un autre micro-monde.


Documents

OSGi et UPnP Des technologies complémentairesfrance.osgiusers.org/wiki/uploads/Main/GuideUPnP-OSGi_FR.pdf · le lecteur a de bonnes bases en programmation Java et une certaine connaissance