6.1 JINI
La technologie Jini™ est spécifiée par Sun Microsystems [JINI05]. Elle promeut une architecture orientée service qui définit un modèle de programmation qui exploite et étend la technologie Java™ [JINI07] [AOS+99]. Son but est de permettre la construction de systèmes orientés service distribués et sécurisés. Jini n'est pas dépendant d'un système d'exploitation. En effet, les périphériques et les logiciels sont considérés comme des services indépendants et communicants. Cependant, Jini nécessite une machine virtuelle Java (JVM). Les systèmes construits au-dessus de Jini consistent en des fédérations de services et de clients au-dessus de réseaux. De telles fédérations peuvent s'installer automatiquement et fonctionner. Jini peut être utilisé pour construire des systèmes distribués adaptatifs qui peuvent passer à l'échelle, qui sont évolutifs et flexibles, comme cela est requis dans les environnements informatiques dynamiques actuels. Jini peut traiter les problématiques liées à distribution, à l'évolution des systèmes, à la sécurité et à l'assemblage de services et supporte aussi les transactions.
Jini définit un service comme une entité logicielle qui peut être utilisée par une personne, un programme, ou un autre service. Un service peut fournir, par exemple, du calcul, du stockage, un canal de communication avec un autre utilisateur, un filtre logiciel, un point d'entrée vers un équipement. Un service est décrit par une interface Java et des propriétés.
Jini possède plusieurs capacités intéressantes, telles la publication de services, la découverte de services, la création d'une unique ou de plusieurs instances de services, la mobilité de code, c'est-à-dire le téléchargement de code à travers le réseau, (qui lui permet d'être, par exemple, indépendant envers les protocoles de communication). Jini fournit aussi un ensemble de notifications concernant les services permettant aux clients d'être informés des changements au niveau des services. Ensuite, Jini supporte de façon explicite les politiques de libération des instances de service via l'utilisation de bail. Pour interagir, les clients et les fournisseurs de services doivent commencer, tout d'abord, par trouver un registre. A ce propos, un registre peut être contacté en utilisant une adresse fixe ou bien il peut être découvert, via la diffusion d'une demande. Dans Jini, les services peuvent être organisés par groupes (par exemple un groupe de services d'impression). Un registre peut héberger un groupe de services particuliers. Cependant, bien que Jini supporte l'existence de registres multiples, il n'offre pas de mécanisme explicite permettant aux registres de déléguer une demande de service. En conséquence, les fournisseurs de services enregistrent, généralement, leurs services dans tous les registres qu'ils ont à disposition. Jini supporte l'existence d'un nombre indéfini de registres de services.
Pour conclure, Jini est une technologie dont la vision de l'approche à service est en ligne avec celle des services web. Les contrats de services sont de niveau 1. Jini respecte l'architecture orienté service. Enfin, les services Jini respectent toutes les propriétés remarquables de l'approche à service que nous avons identifiées, à savoir, le couplage faible, la liaison retardée, la substituabilité, les accords de niveau de service, le courtage et la négociation et la possibilité de domaines d'administration disjoints. Enfin, la responsabilité de Jini a été transférée, fin 2006, de Sun Microsystems à Apache (Apache
Software Foundation) via la création du projet River [RIV08].
6.2 UPnP
Le Forum UPnP™ est un consortium industriel qui a été formé en 1999 [UPNP99] [UPNP00] [JW03]. Le terme UPnP signifie Universal Plug and Play, il est dérivé du terme Plug and Play qui est une technologie pour attacher dynamiquement des périphériques à un ordinateur. Le but du Forum UPnP est la définition de standards simplifiant la mise en réseaux de périphériques intelligents dans les maisons et dans les entreprises (Small Office Home Office, SOHO) et tout en les rendant robustes. Le Forum UPnP est constitué de plus de 800 industriels, incluant des leaders dans les domaines de l'informatique, de l'impression, des réseaux, ainsi que dans les domaines de l'électronique, de l'électroménager, de
l'automatisation, du contrôle et de la sécurité et des produits mobiles. En spécifiant et publiant des descriptions de périphériques UPnP et de services UPnP, le Forum UPnP cherche à promouvoir l'émergence de périphériques facilement connectables, à simplifier l'implémentation de logiciels pour les équipements réseaux, à rendre leur connexion transparente et enfin à conduire le développement d'un écosystème pour le support des périphériques UPnP.
L'architecture d'UPnP est constituée d'une plateforme distribuée de services dynamiques pour des périphériques réseau (comme, par exemple, les télévisions, les éclairages, les routeurs ADSL, les lecteurs de DVD, les volets déroulants) et de points de contrôle (comme, par exemple, des PDAs, des télévisions, des interrupteur muraux) connectés entre eux par un réseau ad-hoc. UPnP définit les protocoles réseau permettant la détection (et le retrait) dynamique des périphériques, l'utilisation des services qu'ils fournissent par des points de contrôle et la notification des changements de valeurs des variables d'état associées aux services. La première version des protocoles de l'UPnP s'appuyait sur XML et HTTP au dessus de TCP, UDP et UDP Multicast qui sont des standards d'Internet. La seconde version, appelée Device Profile for Web Services (DPWS) réoriente les protocoles vers les standards des services web, comme SOAP, WSDL, XML Schema, WS-Addressing, WS-Discovery, WS-Eventing.
Le modèle de services d'UPnP est relativement simple. Un device UPnP expose des services. Chaque service est constitué d'une liste de variables d'état qui peuvent être observée par plusieurs points de contrôle, et par une liste d'actions relatives à chaque variable d'état. L'invocation d'une action par un point de contrôle peut provoquer un changement dans l'état des variables d'état. En cas de changement, les points de contrôle qui observent ces variables sont notifiés du changement. Un device appelé racine (root) peut contenir d'autres devices.
Les devices et, respectivement, les services sont chacun décrits au moyen de document XML. Il existe un schéma XML pour les devices et un autre pour les services.
D e v ic e S e rv ic e S ta te V a ria b le A c tio n P a ra m e te r * 0 ..1 1 ..n 1 ..n 1 ..n * 1 p a r e n t c h ild d ir e c tio n : in , o u t in v o k e is O b s e r v a b le D e v ic e S e rv ic e S ta te V a ria b le A c tio n P a ra m e te r * 0 ..1 1 ..n 1 ..n 1 ..n * 1 p a r e n t c h ild d ir e c tio n : in , o u t in v o k e is O b s e r v a b le
Figure 18. Modèle de données d'UPnP [UPNP99]
Une des activités importantes de l'UPnP Forum est la standardisation de périphériques [UPNP07]. Pour ce faire, les membres du Forum UPnP proposent des descriptions de périphériques standards (Standardized Device Control Protocol, SDCP). Les SDCP décrivent des devices, leurs services obligatoires et optionnels, leurs variables d'état obligatoires et optionnelles et les actions obligatoires et optionnelles. Les fabricants d'équipements UPnP sont libres d'ajouter des services, des variables d'état et des actions propriétaires aux descripteurs de leurs équipements. La liste des SDCP comporte, actuellement, 16 devices et une quarantaine de services standardisés pour les domaines d'application suivants, à savoir, l'audio et la vidéo (via les standards MediaServer V2.0 et MediaRenderer V2.0), la maison, le réseau (via le standard Internet Gateway V1.0), les imprimantes, le contrôle (à distance) et les scanners.
UPnP ne suit pas réellement l'architecture orienté service. En effet, il n'existe pas de registre de services en tant que tel. Cependant, les points de contrôles situés sur le même réseau qu'un périphérique qui vient de se connecter sont informés, par le périphérique, des services qu'il propose. Parallèlement, lorsqu'un point de contrôle vient à être connecté à un réseau, il peut découvrir les périphériques et leurs
services associés. Ainsi, dans UPnP, comme dans le patron SOA, un fournisseur de service se publie et un demandeur de service peut rechercher et établir une interaction avec un fournisseur.
UPnP n'est pas lié à un langage de programmation particulier. En effet, plusieurs API (comme, par exemple, C, C#, C++, Java) existent sur de nombreuses plates-formes (comme, par exemple, Windows XP, Windows CE, Linux) et sont proposés par les principaux promoteurs d'UPnP, à savoir,
Microsoft, Siemens (http://www.plug-n-play-technologies.com), Intel (http://www.intel.com/technology/UPnP/). Au niveau du langage Java, l'Alliance OSGi spécifie la
manière de développer des périphériques UPnP et des points de contrôle UPnP au dessus d'OSGi (qui est une technologie basée sur le langage Java) [OSGi07b]. Le périphérique UPnP est ensuite conditionné dans un bundle qui est déployé au moyen du Device Access [OSGi07c].
Pour conclure, UPnP est une technologie dont la vision de l'approche à service est en ligne avec celle des services web. Les contrats de services sont de niveau 1. UPnP ne respecte pas l'architecture orientée service en tant que telle, mais un fournisseur de service se publie et un demandeur de service peut rechercher et établir une interaction avec un fournisseur. UPnP pallie donc l'absence de registre de services par des protocoles de publication et de découverte. Il est important de noter qu'une telle approche n'est viable que dans les réseaux locaux et qu'elle ne passe pas à l'échelle. Enfin, les services UPnP respectent toutes les propriétés remarquables de l'approche à service que nous avons identifiées, à savoir, le couplage faible, la liaison retardée, la substituabilité, les accords de niveau de service, le courtage et la négociation et la possibilité de domaines d'administration disjoints.