FLASH INFORMATIQUE FI



Vers une approche orientée contexte pour la découverte & la composition de services dans des environnements mobiles




Soraya KOUADRI MOSTÉFAOUI

Béat HIRSBRUNNER


Introduction

L’arrivée de la technologie de communication 3G UMTS, la prolifération du Wi-Fi (WLAN IEEE 802.11b) et l’évolution des caractéristiques des unités mobiles (e.g. capacité de mémoire et de calcul) contribuent à la croissance de la popularité et la diversité des applications mobiles [8]. De ce fait, de nouvelles classes de Services Web apparaissent, dans lesquelles des supports multiples et coordonnés sont utilisés dans des configurations variées, dans des lieux et à des moments différents pour accomplir une tâche[1]. Les avantages de tels services ont conduit à un grand nombre de travaux, tant dans le milieu académique que dans le milieu industriel.

fig. 1 - Position du Problème 

A présent les éléments de base de l’architecture des Services Web sont bien définis, même s’ils sont amenés à évoluer [5]. Ces éléments regroupent un langage de définition des interfaces de services WSDL1, un service de découverte UDDI2 et un protocole d’échange de messages SOAP3. Les efforts actuels portent en partie sur la définition de solutions à la composition de Services Web pour faciliter le développement d’applications à partir de l’intégration de services existants [9]. Dans le cadre des activités du projet CB_SeC4, nous avons proposé une solution à la découverte et à la composition de services qui permet une meilleure sélection de services dans des environnements mobiles. L’approche adoptée dans notre système implique des dispositifs mobiles tels que des Palms, des téléphones mobiles, des ordinateurs portables, etc, qui non seulement consomment des services, mais proposent également leurs propres services (fig.1). Notre solution repose sur la définition d’un langage de description de services basé sur le contexte.

Les services Web

Qu’est ce qu’un service Web ?

Le consortium W3C [5] définit un service Web comme étant une application ou un composant logiciel qui vérifie les propriétés suivantes : il est identifié par une URL, ses interfaces et ses liens (binding) peuvent être décrits en XML, sa définition peut être découverte par d’autres Services Web, il peut interagir directement avec d’autres Services Web à travers le langage XML et en utilisant des protocoles Internet. L’objectif ultime de l’approche Services Web est de transformer le Web en un dispositif distribué de calcul où les programmes (services) peuvent interagir de manière intelligente en étant capables de se découvrir automatiquement, de négocier entre eux et de se composer en des services plus complexes [3].

L’architecture de référence
L’architecture de référence des Services Web (fig.2) s’articule autour des trois rôles suivants [5] :

fig. 2 - Architecture de référence des services Web 

1. Le fournisseur de services : correspond au propriétaire du service. D’un point de vue technique, il est constitué par la plate-forme d’accueil du service [3].
2. Le client : correspond au demandeur de service. D’un point de vue technique, il est constitué par l’application qui va rechercher et invoquer un service. L’application cliente peut être elle-même un Web service [3].
3. L’annuaire des services : correspond à un registre de description de services offrant des facilités de publication de services à l’intention des fournisseurs ainsi que des facilités de recherche de services à l’intention des clients.

Les interactions de base entre ces trois rôles incluent les opérations de publication, de recherche et de liens d’opérations [4][3].
Dans ce qui suit nous allons présenter les lignes directrices du projet CB_SeC, qui permet de découvrir, sélectionner et composer des services dans des environnements mobiles.

Présentation de l’architecture

L’architecture de CB_SeC se décompose en quatre couches (fig. 3) :
• La couche physique : comporte toutes les entités physiques du système, y compris les dispositifs et les capteurs. En raison des changements dynamiques de la disponibilité des dispositifs, de la largeur de la bande passante et de la connectivité, le système doit classifier ces entités surveillant constamment leurs changements. D’une manière telle que les couches supérieures aient toujours une description cohérente de la dimension physique.
• La couche contexte : cette couche est responsable de collecter et d’interpréter les informations contextuelles. Elle se compose de deux parties : le module d’acquisition du contexte, et une base de données contexte.
• La couche services : cette couche est le noyau de notre système ; elle est responsable de la découverte, la sélection, la composition et l’exécution de services en prenants en compte les informations contextuelles provenant de la couche contexte.
• Applications utilisateurs : comporte diverses interfaces graphiques (GUI) par lesquelles les utilisateurs peuvent personnaliser leurs applications, lancer des requêtes de découverte et composition de services, etc. [4].

fig. 3 - Architecture générale 



La couche contexte

Elle se compose de deux grands modules : le module d’acquisition du contexte et la base de données contexte. Chacun de ces modules va être décrit en détail après une description du contexte dans CB_SeC.

Qu’est ce que le contexte dans CB_SeC ?

Le contexte est une vieille connaissance. La littérature indique un grand nombre de recherches basées sur la notion du contexte, typiquement dans la linguistique, l’IA, la vision par ordinateur, et l’IHM (interaction homme-machine). Avec l’apparition du concept de l’informatique omniprésente (ubiquitous computing), les chercheurs redécouvrent cette notion. Des travaux développés sur le contexte [2] [7] , on peut tirer les leçons suivantes :

Leçon 1

Le contexte peut seulement être défini par rapport à un but. Dans notre cas, le contexte est défini pour la découverte et la composition de services. De ce fait il se base sur deux axes principaux
• L’axe utilisateur : rôle de l’utilisateur, profil, préférences, coordonnées physiques, etc.
• L’axe service : temps d’exécution, attribut contexte, nombre d’instances du service, etc.

Leçon 2 :

Le contexte est un espace d’information qui sert l’interprétation [2]. Dans notre cas, l’interprétation des informations contextuelles est effectuée par le module d’acquisition.

Leçon 3

Le contexte est un espace partagé d’information [2]. Dans notre travail, le contexte définit un espace commun entre les services et les utilisateurs.

Le module d’acquisition du contexte

Il est responsable de collecter, traiter et interpréter les informations contextuelles. Il consiste en un système multiagents, dans lequel chaque agent est associé à un type d’information contextuelle. Les agents sont responsables de collecter les données fournies par les capteurs, d’interpréter ces données, d’en extraire les spécifications et finalement de les fournir à la base de données contexte. L’information contextuelle est acquise par des capteurs physiques (e.g. coordonnées physiques), ou par des capteurs logiciels5 en utilisant des messages spéciaux entre les agents du système (e.g. préférences des utilisateurs).

La base de données contexte

Elle reçoit les informations contextuelles des agents du module d’acquisition, ces informations sont ensuite traduites en documents XML pour en faciliter l’utilisation. Une fonction importante de la base de données contexte est la classification des informations contextuelles en types. Les spécifications du type de contexte sont réalisées en utilisant un template XML. En utilisant cette approche, la couche services peut accéder aux données contextuelles d’une manière découplée du service utilisé pour acquérir ces informations. Cette méthode de cacher le mécanisme réel pour rechercher l’information contextuelle permet au système CB-SeC de coordonner l’accès au contexte pour différentes applications.

La couche services

La couche services se compose de quatre modules principaux : le module de découverte et sélection de services, le module de composition, le module d’exécution, et un cache. Chacun de ces modules va être décrit en détail après une brève description des services CB_SeC.

Vers une description de services Web orientée contexte

La description de services dans CB_SeC se compose en quatre principales parties :

1. L’interface : contient les informations concernant les opérations qui peuvent être invoquées dans un service et leurs paramètres d’entrée et de sortie respectifs.
2. La capsule : fournit des informations concernant la localisation du service (URL) et comment il peut être accédé, les protocole(s) d’invocation (HTTP : HTTPS, SMTP, etc.), les type(s) et les port(s).
3. Description de contraintes : il est souvent nécessaire de décrire des contraintes concernant les paramètres d’entrée et de sortie d’un service, parce qu’il peut exister deux implémentations d’un même service ayant la même description d’interface mais ayant différentes descriptions de contraintes (e.g un service Web qui permet d’envoyer des SMS peut avoir des contraintes sur le nombre de caractères en entrée).
4. L’attribut contexte : cet attribut représente la sensibilité du service au contexte. à la différence des trois parties précédentes, la valeur de cet attribut n’est pas connue à l’avance, elle n’est calculée que si l’étape de découverte résulte en plus d’un seul service, afin d’aider à une meilleure sélection. Cet attribut peut être une fonction primitive quand le service est sensible à un seul paramètre contextuel, ou une fonction complexe quand le service est sensible à plus d’un seul paramètre contextuel. Un exemple d’un tel attribut pour le service imprimante peut être une fonction composée de deux fonctions primitives F = (N ¡ L) : N qui permet de retrouver l’imprimante la plus proche, et L qui permet de déterminer quelle imprimante est la moins chargée. Selon l’évaluation de la fonction F l’utilisateur aura le meilleur service d’impression dans son contexte.

Exemple d’un Service CB_SeC


Attributes*

service-identifier         =         "pai-acc121";
num instances             =         3 ; number of allowed instances
type          =         "W-service"; //Web or M-service
isMobile        =         "No"; //whether the service can move to other places
description         =         "accommodation booking service";
provider-identifier         =         "PAI";
input-parameters         =         {Int Num of Persons, Int Num of Days, String Contact Name};
output-parameters         =         {XML Doc accommodation Details};
price         =         5;                         //e-coins per invocation

Capsule*

location         =         "pai-acc.diuf.com.ch";
protocol         =         https;
port         =         80;

Constraints & Requirements*

diskfree         >          20; //Kbytes
memoryfree         >=          128; //Kbytes
OpSys         =          "Palm OS, Linux"

Context of Interest Function //the value of this field is not known in advance

CoIF        =         ping iiufps31.unifr.ch

fig. 4. Exemple d’une description d’un service CB-SeC.

La figure 4 montre une description d’un service Web qui permet de réserver une chambre d’hôtel. Dans cet exemple le service accepte trois paramètres en entrée et renvoie les détails du résultat trouvé sous forme d’un document XML. Pour exécuter ce service, une ressource doit avoir au moins 20 Kbytes d’espace disque libre, et au moins 128 Kbytes de mémoire libre. En outre, le service peut être exécuté sous des environnements Palm OS ou Linux. Et enfin l’attribut contexte6 présente la sensibilité du service aux paramètres contextuels, dans notre exemple et pour des raisons de simplicité, nous prenons une fonction simple (Ping) qui permet de vérifier quel fournisseur a le meilleur temps de réponse (fig. 5).

fig. 5. Sélection du service ayant le meilleur temps de réponse 

Module de découverte et sélection

Ce module est responsable d’accomplir les trois tâches suivantes :

1. Décomposer les requêtes complexes en services basiques : la présente implémentation de notre système utilise les lois sociales d’UCM (Ubiquitous Coordination Model) pour décomposer les requêtes complexes, et pour déterminer le modèle d’exécution. Le modèle UCM7 est une instantiation du modèle de coordination XCM (Generic Coordination Model). Il est vu comme un domaine d’organisation composé par des entités autonomes. Une entité est définie par sa structure obtenue par composition récursive d’entités. à l’intérieur de ce domaine, les entités communiquent entre elles par des points finaux de communication qui définissent un ensemble d’actions. Les lois sociales sont définies pour déterminer la composition des actions de base. Dans notre système nous associons chaque action UCM à un service CB_SeC, les points finaux de communication sont associés aux entrées / sorties des services.
2. Extraire les informations contextuelles de la base de données contexte, puis utiliser ces informations pour découvrir les services basiques, en commençant par ceux enregistrés sur sa proximité (en utilisant l’attribut coordonnées physiques de l’utilisateur), puis il augmente progressivement son rayon de recherche pour découvrir les différents services nécessaires pour la composition.
3. L’étape précédente produit un ensemble de services, le module de découverte doit donc réitérer par cet ensemble, et sélectionner les meilleures offres selon le contexte courant et les contraintes posées par les fournisseurs de services. En d’autres termes les services sont incrémentalement filtrés et classés selon l’évaluation des contraintes et des attributs contexte.

Module de composition

Ce module est responsable de composer les services résultants de l’étape de découverte. Il raffine l’ensemble des services trouvés en utilisant les paramètres contextuels qui sont plus appropriés à la composition qu’à la découverte, un exemple d’un tel paramètre peut être les préférences d’utilisateur qui sont applicables au service composé global, (e.g. une personne qui planifie ses vacances d’été ne veut pas dépenser plus que 2000 CHF pour le service composé entier c.-à-d. réservation d’hôtel, service de location de voiture, recherche d’attractions, billets d’avion, etc.). Le service composé qui satisfait toutes les préférences de l’utilisateur est choisi et les capsules correspondantes (c.-à-d. les informations sur les services, les adresses, les ports, et les protocoles d’invocation) sont envoyés au module d’exécution. Entre temps une copie du modèle d’exécution ainsi que son contexte sont copiés dans le cache.

Module d’exécution

Ce module est responsable d’exécuter le service composé. Avant ceci le module de composition fournit l’ordre d’exécution dans lequel les services basiques peuvent être invoqués. Principalement deux types d’exécution existent selon la nature du service, qui peut être un service Web (W-service) ou un service Mobile (M-service). Pour les M-services l’exécution est toujours locale au dispositif d’exécution puisque le service a été transporté sur la plate forme du client. Cependant pour des W-services l’exécution peut être distante ou locale. Dans l’invocation à distance le client envoie une demande au fournisseur demandant l’exécution du service. L’exécution a lieu sur la plate-forme du fournisseur. Dans l’invocation locale le client demande à distance à transférer une copie du service sur son dispositif. Après avoir été transféré, l’exécution a lieu sur la plate-forme du client.

Le cache

Le cache stocke le modèle d’exécution résultant d’une requête ainsi que son contexte, et les réutilise pour d’autres clients qui fournissent la même requête. Le cache est également utile quand un client fournit la même requête dans d’autres contextes ; dans ce cas le cache est d’abord vérifié pour voir si le même service composé satisfait les nouveaux besoins de la requête (selon le nouveau contexte), sinon le service est décomposé, les services basiques qui ne répondent pas aux nouvelles exigences sont enlevés, et un nouveau processus de découverte/composition est lancé pour ces services. Les nouveaux services découverts sont composés avec ceux du cache. Un autre avantage du cache est qu’il fournit au système un mécanisme de tolérance aux fautes ; pour réaliser ceci, des points de contrôle (check points) sont insérés dans le modèle d’exécution, et le module d’exécution renvoie les résultats après qu’une sous-tâche soit accomplie, ces résultats sont copiés dans le cache. Quand une erreur d’exécution se produit au lieu de lancer une nouvelle requête de découverte/composition, on reconstruit seulement le reste de la requête qui n’est pas encore résolue.

Conclusions et travaux futurs

Le projet CB_SeC se situe à la convergence de deux domaines de recherche importants qui concernent l’informatique omniprésente, à savoir les Services Web et le context-aware computing. Dans cet article nous avons présenté les lignes directrices du projet qui porte sur la découverte et la composition de services. La définition de CB_SeC est en cours d’achèvement, l’extension du système par une définition formelle du contexte pour les Services Web est prévue. Nous voulons également exploiter l’intégration du contexte afin d’améliorer les standards existants, tels que WSDL et UDDI.

Afin de valider notre modèle un travail d’implémentation est actuellement en cours. En conclusion, il apparaît que CB_SeC constitue un point de départ prometteur pour le développement d’une plate-forme de découverte et composition de services basée sur le contexte, notamment de par son aptitude à favoriser une meilleure sélection de services.

Références

[1] C. Denis, L. Karsenty & F. Panaget, Favoriser les Transitions avec des Services Multisupports, Colloque sur la mobilité, Décembre 2002, LORIA , Nancy, France.
[2] Gaëtan Rey, Joëlle Coutaz, le Contexteur un Model Computationnel pour le Contexte, Colloque sur la mobilité, Décembre 2002, LORIA , Nancy, France.
[3] Patrick Kellert et Farouk Toumani, Les services Web sémantiques, Rapport de Recherche, LIMOS/RR 03-15, Juillet 2003.
[4] Soraya Kouadri.M and Béat Hirsbrunner, A Context-Based Service Discovery and Composition Framework for Wireless Environments, Proc. of the IASTED International Conference on Wireless and Optical Networks, WOC’2003, Banff, Alberta, Canada, July 2003.
[5] http://www.w3.org/2002/ws/
[6] A. Tafat Bouzid, M. Courant and B. Hirsbrunner. A Coordination Model for Ubiquitous Computing. In Proceedings of the 2003 International Conference on Parallel and Distributed Processing Techniques and Applications PDPTA’2003, Las Vegas, Nevada, USA, June, 2003.
[7] Moran, T. P. and Dourish, J. P. (editors). Special Issue on Context-Aware Computing. Human Computer Interaction, Volume 16, Numbers 2-4. Erlbaum.
[8] Patricia Serrano-Alvarado, Claudia L. Roncancio, Michel E. Adiba, Transmobi : Intergiciel Pour la Gestion des Transactions Mobiles. Colloque sur la Mobilité, Décembre 2002, LORIA , Nancy
[9] http://www.inria.fr/travailler/opportunites/jeunes/offres/ro08.html

1 - Web Services Description Language
2 - Universal Description Discovery and Integration
3 - Simple Object Access Protocol
4 - Context Based Service Composition
5 - Software sensors.
6 - CoIF sur la figure 4.
7 - Plus de détails sur UCM sont disponibles dans [6]



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.