Une infrastructure logicielle à base de services pour dispositifs

Nous avons vu que les architectures orientées services (SOA) sont largement utilisées en informa- tique mobile et ambiante pour représenter comme des services l’ensemble des fonctionnalités fournies par des dispositifs. Elles offrent des facilités pour l’interopérabilité entre les dispositifs, pour la dé- couverte de services ou encore d’encapsulation (SECTION2.2.2.1). Elles ont évoluées des SOA aux

SOAD (architectures orientées services pour dispositifs) afin de s’adapter aux caractéristiques des dis- positifs. Lorsque les technologies du Web sont utilisées pour implémenter les SOAD, l’interopérabilité entre tous les services est introduite. Seules deux implémentations des services web pour dispositifs existent aujourd’hui : UPnP2et DPWS3. Les SOAD ajoutent trois caractéristiques aux SOAD : (1) une découverte décentralisée réactive, (2) une gestion des apparitions et disparitions et (3) des com- munications événementielles.

5.2.1.1 Communications par événements

Les applications utilisant des dispositifs mobiles ont une nature réactive : les déconnexions fréquentes doivent être prises en compte rapidement. En effet, le fonctionnement sur batterie contraint les programmes à être efficaces et à utiliser des événements plutôt qu’un mécanisme de polling. Les capacités de traitement des dispositifs mobiles sont réduites en terme : de capacité de calcul, de quantité de mémoire et en durée d’utilisation à cause de l’alimentation par batterie. Les programmes doivent ainsi être les plus efficaces et pertinents possible. La mise en place de systèmes à file d’attente ou d’architectures complexes de publication/souscription [139], est rarement envisageable. C’est pourquoi des systèmes simples en relation 1 → N sont utilisés.

Les communications par événements permettent aux applications basées sur des dispositifs d’uti- liser de façon efficace les interruptions matérielles et offrent un découplage maximal. Si nous prenons l’exemple d’un interrupteur communiquant : lorsqu’il est actionné, une interruption matérielle est levée. Grâce aux événements, une notification sera immédiatement envoyée aux consommateurs. La dynamicité et l’efficacité sont maximales. Sans l’utilisation d’événements, l’interrupteur devrait garder une variable d’état à jour, en attendant que les consommateurs lui demandent sa valeur. Puisque ces invocations sont faites périodiquement, il existe un risque de manquer un changement d’état, s’il est plus court que la période d’invocation des clients.

Les communications par événements apportent la dynamicité nécessaire aux interactions entre les dispositifs prenant part aux applications d’informatique ambiante. Elles ajoutent de plus une dynami- cité dans ces interactions, en permettant à tout moment aux entités concernées de les reconfigurer. 5.2.1.2 Apparition et disparition

Comme nous l’avons vu, en informatique ambiante, l’infrastructure d’une application est forte- ment variable en raison de la forte mobilité des entités qui la compose. La mobilité des utilisateurs, et donc des dispositifs de leurs réseaux personnels, provoque de fréquentes déconnexions et change- ments de réseaux. La topologie des réseaux ne peut pas non plus être connue à l’avance. Dans les réseaux mobiles, on ne peut pas connaître à l’avance l’adresse des annuaires, ni même supposer qu’il en existera un. Pour construire des applications reposant sur ces entités, un intergiciel doit connaître les entités se trouvant dans cette infrastructure. Les SOAD apportent une telle évolution aux SOA.

Les fournisseurs de services émettent des annonces par diffusion à tout le réseau lorsqu’ils y entrent (après adressage), ou lorsqu’ils sont en train de le quitter : cette apparition ou disparition par annonce est asynchrone, et fournit la propriété de dynamicité à cette infrastructure logicielle. Cependant, lorsqu’un consommateur arrive dans l’infrastructure, c’est à lui d’initier cette apparition

2. Universal Plug and Play Forum :http://www.upnp.org/ 3. Device Profile for Web Services. http://www.ws4d.org/

ou disparition, sinon les fournisseurs ne pourront pas le découvrir rapidement. De plus, si les fournisseurs sont déconnectés brutalement, ou s’ils subissent une erreur de programmation, l’annonce de disparition ne sera pas envoyée. Pour palier à ces problématiques les fournisseurs utilisent un mécanisme de bail qui consiste à avertir régulièrement de leur présence.

A travers ces mécanismes d’annonces, les entités du réseau sont alors capables de connaître les en- tités se trouvant dans leur réseau dynamiquement et de les voir apparaître et disparaître. Ce mécanisme prend tout son sens lorsqu’il est couplé à une découverte dynamique décentralisée.

5.2.1.3 Découverte décentralisée réactive

Une autre évolution des SOA apportée par les SOAD est la modification de la découverte, pour prendre en compte des fournisseurs et consommateurs inconnus à l’avance. Les entités qui seront présentes pour créer une application ne sont donc pas connues, et doivent être découvertes de façon dynamique.

Des mécanismes de recherche décentralisée ont alors fait leur apparition, dans des standards industriels (SLP [140], Jini [133], Bluetooth SDP4, Salutation5, Bonjour6) et de nombreux projets de recherche ([160, 136, 157, 163, 88]). Ils permettent aux consommateurs de découvrir les fournisseurs sans passer par un registre centralisé. Le mécanisme de recherche est en fait ramené dans les fournisseurs et les consommateurs qui communiquent donc directement entre eux. La phase de découverte utilise alors les mécanismes d’apparition/disparition.

Ce mode est centré sur les consommateurs. Comme dans les architectures à services utilisant les registres, les consommateurs peuvent effectuer une requête de recherche, mais cette fois par diffusion. Dans la figure ci-dessous (FIG. 5.2), les traits en pointillés représentent des communications par diffusion, alors que ceux en trait plein sont point à point.

Toutefois, pour une meilleure efficacité ou sécurité, certains protocoles (SLP et Jini) permettent d’utiliser la diffusion pour découvrir un registre de services. Dans les environnements mobiles, les communications sans-fil sont souvent coûteuses en énergie. Le registre permet alors aux consomma- teurs d’avoir un seul interlocuteur et d’effectuer des requêtes en point à point. Un tel registre construit sa base de données à partir des messages d’annonce des fournisseurs.

La découverte est la première étape de la création d’applications à partir d’une infrastructure de services. En informatique ambiante, c’est d’autant plus le cas car les environnements dans lesquelles elles seront créées ne sont pas connus à priori. La découverte dynamique décentralisée couplée aux mécanismes d’apparition/disparition permet de découvrir les services sans les connaître a priori et sans se baser sur une entité statique.

4. Bluetooth Service Discovery Protocol, dans Specification of the Bluetooth System. Core, version 1.1. 2001. 5. Le Salutation Consortium n’existe plus.

FIGURE5.2 – Découverte dynamique décentralisée : protocoles de découverte et recherche.

5.2.1.4 Application au scénario

Dans le cadre de notre scénario, notre infrastructure reposera sur l’ensemble des dispositifs se trouvant dans le bâtiment intelligent (connus à l’avance) ainsi que de l’ensemble des dispositifs mobiles du personnel et des visiteurs (non prévisibles). Parmi ces dispositifs, nous trouvons : les fenêtres, l’ordinateur du gardien, des capteurs d’humidité, des capteurs de température, les PDA des techniciens ainsi qu’un capteur de niveau d’eau. Les capteurs d’humidité sont disséminés autour des fenêtres tandis que les capteurs de température sont dans le hall. Il permettront de gérer l’ouverture des fenêtres. Les capteurs pour le niveau d’eau se trouvent au sol et serviront à identifier si l’eau est au dessus d’un certain seuil dans le hall. Enfin, les dispositifs mobiles comme les téléphones portables ou les PDA n’étant pas connus à l’avance, les mécanismes d’apparition et de découverte dynamique sont pleinement utilisés afin que le système puisse les utiliser. Ce mécanisme nous permet de prendre en compte un premier challenge posé par ce scénario : la découverte dynamique et décentralisée nous permet de considérer la variabilité et l’imprévisibilité de l’infrastructure logicielle.

A partir de cette infrastructure de services pour dispositifs, nous souhaitons créer des applications en faisant interagir ces services vus comme des boites noires les uns avec les autres. Pour cela, dans le niveau réflexe interne de notre architecture, nous devons disposer d’une plateforme d’exécution permettant de faire ces orchestrations de services.