• Aucun résultat trouvé

Partie I – Etat de l’art : Contexte et Système d’Information Web

Chapitre 2- Système d'Information Web Sensible au Contexte

2.3. Système d’Information Web sensible au contexte

2.3.2 Systèmes d’Information Web sensibles au contexte restituant des Services Web pertinents

2.3.2.1 La phase de découverte de services

Dans cette phase, le contexte est intégré entre l’utilisateur et l’annuaire. Lors de la recherche des Services Web élémentaires, certains travaux intègrent le contexte d’utilisation afin de trouver les Services Web les mieux adaptés à la demande de l’utilisateur. Le système peut avoir à sa disposition un ensemble de Services Web qui peuvent répondre de manière fonctionnelle à la demande. La technique d’adaptation mise alors en jeu est celle de sélection

de Services Web qui consiste à sélectionner le service qui correspond au mieux au contexte.

Nous citons comme exemples, les travaux de [Balke et al., 2003b], de [Van Setten et al., 2004] et de [Chen et al., 2006].

Le but du travail de [Balke et al., 2003b] est de découvrir des Services Web dits centrés utilisateur. Dans ce but, [Balke et al., 2003b] intègrent le contexte (plus particulièrement le contexte de l’utilisateur) dans le processus de sélection des Services Web en enrichissant la requête de l’utilisateur avec les besoins particuliers de l’utilisateur et ses préférences.

Les Services Web sont décrits dans ces travaux pour une description sémantique. Cette description est exprimée à l’aide du langage DAML-S (DARPA Agent Markup Language for Services) [Ankolekar et al., 2002] contenant la description des interactions entre les acteurs, la description de la tâche (simple ou complexe) et son applicabilité (pré et post-conditions). Une tâche est dite complexe si elle a besoin d’informations supplémentaires (telles que le profil ou les préférences de l’utilisateur) pour être exécutée.

Le contexte est caractérisé par un ensemble d’informations décrivant l’utilisateur. Ce contexte est intégré, d’une part, dans la description du service (profil et préférences de l’utilisateur présents lorsque le service propose une tâche complexe), et, d’autre part, dans la requête de l’utilisateur (profil et patron d’utilisation).

Le processus de sélection de Services Web est basé sur trois étapes : l’expression de la requête, la recherche de services et la validation du résultat de la recherche par l’utilisateur.

L’expression de la requête : l’utilisateur lance sa requête qui est exprimée en SQL. Afin de

permettre à l’utilisateur de découvrir les Services Web pertinents par rapport à son contexte, [Balke et al., 2003b] ont proposé un processus d’enrichissement de la requête de l’utilisateur. Ce processus y intègre son profil (description de l’utilisateur incluant des

Chapitre 2. Système d’Information Web Sensible au Contexte

informations toujours vraies, telles que son nom, sa date de naissance) et les patrons d’utilisation (représentant les préférences de l’utilisateur pour un cas particulier). Par exemple, un utilisateur souhaite trouver un Service Web qui lui propose un restaurant ayant le style "Business". Cet utilisateur préfère les restaurants français ou japonais ou, si cela n'est pas possible, la cuisine italienne. La requête SQL enrichie par les préférences est présentée comme suit :

SELECT grounding (service) FROM Restaurant

WHERE categogy=’Business’

PREFERING (concept (service) = ‘French’ OR concept (service) =’Japanese’ PRIOR TO concept (service) = ‘Italian’)

La recherche de Services Web : la recherche est effectuée par un processus de

correspondance entre les ontologies représentant la requête, le profil et les patrons d’utilisation et celles représentant les services. Ces ontologies sont spécifiques au travail de [Balke et al., 2003b].

La validation de la recherche par l’utilisateur : le résultat de l’étape précédente est

retourné à l’utilisateur qui déclare s’il est satisfait de ce résultat. Si l’utilisateur n’est pas satisfait, le processus de recherche est renouvelé.

Ce travail fait intervenir l’utilisateur dans la phase de sélection du Service Web afin de lui retourner le Service Web le mieux adapté à son contexte. Cependant, le contexte est très limité parce qu’il est restreint au profil et aux préférences de l’utilisateur. D’autres facteurs tels que l’appareil de l’utilisateur, sa localisation, le type de réseau, etc. ne sont pas pris en compte dans ce contexte.

[Van Setten et al., 2004] ont proposé l’application COMPASS (COntext-aware Mobile

Personal ASSistant) qui sert à fournir aux visiteurs d’une ville, des informations touristiques à propos de cette ville, telles que la carte de la ville.

Cette application montre à l’utilisateur une carte de sa localisation actuelle. Selon le profil de l'utilisateur et l’objectif, une sélection de bâtiments à proximité, des amis et d’autres objets sont indiqués sur la carte et dans une liste.

La carte et les objets indiqués sont mis à jour lorsque l'utilisateur se déplace, lorsque son profil ou l'objectif changent. En cliquant sur un objet présenté dans la carte une interaction avec les services fournis par cet objet est généralement signifiée (Figure 2.7), par exemple appeler un ami, réserver une table au restaurant, ou réserver des billets pour un spectacle.

Figure 2.7 : Application COMPASS [Van Setten et al., 2004]

[Van Setten et al., 2004] restituent à l’utilisateur des services adaptés à son contexte. Ce contexte est représenté par le profil de l’utilisateur et sa localisation. Le processus

Chapitre 2. Système d’Information Web Sensible au Contexte

d’adaptation est résumé par un processus de filtrage de la liste de services et des données affichées sur la carte.

Dans ce travail, les auteurs ont proposé une application qui vise à délivrer des services adaptés au contexte de l’utilisateur équipé d’un téléphone mobile. Le contexte est donc représenté par le profil de l’utilisateur et sa localisation. Ce contexte ne concerne qu’un seul type de dispositif : le téléphone mobile. Le contexte est présenté d’une manière spécifique et très limitée. Les autres facteurs comme les caractéristiques du réseau par exemple ne sont pas pris en compte.

[Chen et al., 2006] ont proposé une architecture orientée services sensibles au contexte CA-SOA (Context Aware Service Oriented Architecture) (Figure 2.8). Cette architecture comprend trois composants pour la découverte et l’accès à des Services Web basés sur les contextes environnants :

1) Une Plateforme d’Agent «Agent Platform» qui contient trois types d’agent (Agent de Service, Agent de Demande et Agent Courtier). Ces agents ont été mis en œuvre pour améliorer la description du service orienté contexte, la publication, l'enregistrement, la découverte et l'accès.

A.Agent de Service «Service Agent» : conçu pour aider les fournisseurs des services à

décrire et à envelopper un service avec les descriptions contextuelles. Cet agent envoie ensuite le service avec les descriptions contextuelles à l’agent courtier.

B. Agent de Demande «Request Agent» : conçu pour aider les demandeurs du service à

décrire le service demandé et à envelopper la requête avec les contextes environnants. L’Agent de Demande envoie ensuite les requêtes avec les descriptions du contexte du demandeur à l’Agent Courtier.

C.Agent Courtier «Broker Agent» : prend les requêtes de la publication du service par les

fournisseurs et enregistre la description du service et les descriptions contextuelles du service dans les Profils de Service «Service Profiles» et les Ontologies de Service «Service Ontologies», respectivement. Cet Agent prend également les requêtes de l'Agent de Demande et lance un "matching" sémantique sensible au contexte.

Figure 2.8 : Architecture de CA-SOA ([Chen et al., 2006])

2) Un composant d’appariement sémantique «Semantic Matchmaker» est composé d’un

Chapitre 2. Système d’Information Web Sensible au Contexte

planner». Le raisonneur de contexte décompose la requête du demandeur en se basant sur une ontologie envoyée avec la demande de service par l’Agent de Demande, dans un ensemble de sous-requêtes. Le planificateur de service réalise un processus de matching du contexte afin de planifier un service composé basé sur la décomposition de la requête. 3) Un Dépôt de Service «Service Repository» est conçu pour englober un Registre UDDI

général associé aux Profils de Service et aux Ontologies de Service. Si les services demandés sont trouvés par le composant d’appariement sémantique dans le Registre UDDI, ce composant déroulera le matching du contexte.

Dans ce travail [Chen et al., 2006] prennent en compte non seulement le contexte du demandeur du service mais aussi le contexte du service lui-même. La modélisation des deux contextes est produite en se basant sur une ontologie OWL-S. Cette ontologie est un OWL (Ontology Web Language) basé sur l'ontologie de Service Web :

Le contexte du demandeur du service contient des informations sur les préférences du terminal, son terminal, etc.

Le contexte du service comprend des informations sur la qualité du service : des conditions

fonctionnelles (bande passante du réseau, temps de réponse, etc.) et conditions non- fonctionnelles (disponibilité, fiabilité et coût).

Du point de vue de la représentation du contexte, le fait de prendre en compte non seulement le contexte du demandeur mais aussi le contexte du service joue un rôle très intéressant pour augmenter la probabilité d’arriver aux services les plus pertinents. Cependant, nous remarquons que le contexte du service reste un peu limité. Ainsi, il ne contient pas d’informations sur la description du terminal qui doit être employé par l’utilisateur. Nous remarquons aussi que ce travail réalise la découverte des services en se basant une technologie agents ce qui ralentit l’exécution du service [Lopez, 2008].