Accès à l’information

Comme nous l’avons déjà dit l’accès à l’information disponible au sein d’une application de

proximité peut être réalisé de façon réactive ou proactive. Un client est capable d’émettre

une requête pour localiser une information et il peut également recevoir sur son terminal les

informations diffusées au sein de l’application de proximité. Dans cette section, nous

présentons comment ces différents accès à l’information sont gérés.

5.1. Principe d’évaluation des requêtes

Le langage d’interrogation des requêtes utilisé permet l’interrogation des métadonnées

stockées dans l’instance d’ISLANDS. Dans le cas d’un nœud central, pour des raisons de

performances, l’utilisation d’un SGBD est favorisée. Dans ce cas, par exemple, les

différentes métadonnées RDF sont stockées au sein du SGBD et interrogées en utilisant

SQL. Dans le cas d’un nœud léger ne bénéficiant pas d’un SGBD, les métadonnées RDF

peuvent, par exemple, être stockées dans des fichiers XML et interrogées grâce à XQuery.

Après avoir été exprimée, la requête est prise en charge par l’évaluateur de requêtes de

ISLANDS. L’évaluation d’une requête classique, non dépendante de la localisation, se

déroule en deux étapes :

- Etape 1 – l’évaluation locale : la requête est tout d’abord évaluée localement sur le nœud

client. L’évaluateur interroge les métadonnées stockées dans l’instance locale

d’ISLANDS. Si l’information recherchée est décrite par les métadonnées, l’évaluateur

récupère la valeur de l’élément identifiant de la ressource RDF. Cet élément permet de

fournir un chemin d’accès à l’information recherchée. L’évaluateur peut ainsi récupérer

l’information recherchée. Si la requête est satisfaite, la réponse est transmise au client.

Sinon l’évaluateur effectue l’étape 2. Si le nœud client est un nœud léger très restreint en

terme de ressources (mémoire et CPU), il peut ne pas avoir d’informations à partager et

donc reposer sur une version d’ISLANDS dégradée. En particulier, l’évaluateur de

requêtes ne permet alors que la gestion de l’étape 2 de l’évaluation d’une requête.

- Etape 2 – la distribution de la requête : l’évaluateur de la requête distribue aux autres

services de localisation en fonction des métadonnées décrivant des ressources de type

ISLANDSReference. La requête est alors, envoyée aux autres instances d’ISLANDS

accessibles, et évaluée sur ces instances. Les réponses sont ensuite sélectionnées par

l’évaluateur de requêtes de l’instance d’ISLANDS présent sur le nœud client pour être

finalement envoyées au client.

Concernant la distribution de la requête vers d’autres services ISLANDS sur d’autres nœuds,

l’évaluateur de requêtes choisit la distribution la plus adaptée en fonction des contraintes de

temps de réponse et de qualité de réponse souhaitées. En effet, cette distribution est réalisée

dans le but d’obtenir un compromis satisfaisant entre qualité de réponse et ressources

utilisées pour cette évaluation distribuée. Plus une requête est distribuée sur des nœuds

distants, plus les coûts en terme de communication, de traitement et de temps de réponse

augmentent. Les différentes stratégies de distribution sont présentées et discutées dans le

chapitre 6 de ce mémoire.

Ce principe d’évaluation est adapté à l’évaluation des requêtes classiques : par exemple, dans

l’application de proximité se déroulant dans un aéroport, la requête « Quel est le bureau

d’enregistrement du vol A7861 ? » est évaluée suivant le principe décrit ci-dessus. Un autre

exemple de ces requêtes est « Où est Sophie ? » : dans ce cas, l’évaluateur recherche une

ressource de type localisationType dont le créateur est Sophie.

5.2. Requêtes de localisation

Au sein d’une application de proximité, pour personnaliser l’informa tion recherchée par un

client en fonction de sa localisation géographique, les requêtes de localisation sont utilisées.

Deux exemples différents de requêtes de localisation sont :

- Exemple 1 : « quel est l’arrêt de bus le plus proche de moi ? ». Dans ce cas, il s’agit

d’une requête dépendante de la localisation. La localisation de référence est celle du

client.

- Exemple 2 : « quel est l’arrêt de bus le plus proche de la gare ? ». Dans ce cas, il s’agit

d’une requête relative à la localisation. La localisation de référence est alors celle de la

gare.

5.2.1. Expression

Afin d’exprimer ces requêtes de localisation, nous avons introduit trois opérateurs simples et

faciles d’utilisation. Ces opérateurs permettent aux utilisateurs d’exprimer des contraintes de

localisation. Les trois opérateurs sont : inside, closest et close [THI 04a]. Ces opérateurs

permettent d’exprimer à la fois des requêtes dépendantes de la localisation et des requêtes

relatives à la localisation. En effet, l’opérateur prend en paramètre une localisation : par

défaut la localisation du client qui émet la requête ou une localisation de référence spécifiée

par le client.

L’opérateur inside est utilisé pour retrouver une information à l’intérieur d’une “zone

géographique” définie. Ainsi, il peut être utilisé pour retrouver l’ensemble des vendeurs du

premier étage d’un bâtiment. Le type de la « zone géographique » est défini comme

paramètre de l’opérateur inside : dans l’exemple, le paramètre est « étage ».

L’opérateur closest est utilisé quant à lui pour retrouver une information donnée qui soit la

plus proche de l’expéditeur de la requête (ou d’une localisation spécifiée). Il peut être utilisé,

par exemple, pour retrouver l’arrêt de bus le plus proche de moi (ou le plus proche de la

gare).

Finalement, l’opérateur close est une extension de l’opérateur closest. Cet opérateur est

utilisé pour retrouver plusieurs éléments proches de l’expéditeur de la requête (ou d’une

localisation spécifiée). Il est également possible de préciser un paramètre de distance. Ce

paramètre optionnel est un entier représentant le nombre de mètres maximal séparant

l’information recherchée de l’expéditeur de la requête (ou de la localisation spécifiée). Un

exemple de requête dépendante de la localisation utilisant l’opérateur closest est décrit dans

le tableau 3.3 : la requête est alors « rechercher l’arrêt de bus le plus proche de moi ».

Select busStop.Title, busStop.Description

From busStop

Where closest(BusStop.localisation);

Tableau 3.3. Exemple de requêtes dépendantes de la localisation exprimé en SQL

5.2.2. Evaluation

Après avoir exprimé la requête, pour l’évaluer, trois étapes distinctes sont exécutées :

- La localisation de référence est évaluée. Pour l’exemple 1, la localisation du client est

récupérée. Dans le cas de l’exemple 2, la localisation de la gare est récupérée.

- La requête non dépendante de la localisation est évaluée. Dans les exemples, l’évaluation

de cette requête consiste à récupérer l’ensemble des arrêts de bus et leurs localisations

respectives. L’évaluation de cette requête s’effectue en deux étapes comme il est décrit

dans la section 3.3.1.1.

- Lorsque les deux premières étapes sont effectuées, l’étape 3 consiste à évaluer le critère

de localisation en fonction des réponses obtenues pour les étapes 1 et 2. Pour l’exemple,

cette étape consiste à retrouver l’arrêt de bus dont la localisation est la plus proche de la

localisation de référence.

5.3. Diffusion de l’information

Les solutions de diffusion adaptées aux environnements sans fil [IMI 97, JUN 02] ne sont

pas adaptées à l’environnement des applications de proximité. Ces solutions reposent sur la

diffusion d’un index permettant aux utilisateurs mobiles de choisir le canal adapté en

fonction de l’information qu’ils recherchent et ainsi d’économiser ses ressources. Cependant,

le contexte de ces solutions est centralisé : l’information à diffuser est stockée de façon

centralisée et permet donc la création d’un index. Dans les applications de proximité,

l’information à diffuser provient de différents nœuds centraux. La solution utilisée dans les

applications de proximité repose donc sur l’utilisation de groupes multicast. Ces groupes

multicast sont créés en fonction du type d’informations diffusées dans ce groupe. Lorsqu’un

utilisateur souhaite recevoir une information particulière, il peut alors s’abonner au groupe

multicast adéquat et récupérer l’information qui l’intéresse. Cette solution permet de limiter

les ressources utilisées par les terminaux nomades pour récupérer l’information diffusée

[IMI 94]. Par exemple, dans l’application de proximité se déroulant dans un aéroport, un

groupe multicast peut être créé pour la diffusion des bureaux d’enregistrement associés à

chaque vol. Avant d’arriver à l’aéroport, l’utilisateur peut ainsi paramétrer son service de

localisation en spécifiant qu’il est intéressé par les renseignements concernant les vols et en

indiquant son numéro de vol. Dès son arrivée à l’aéroport, son service de localisation se joint

aux groupes qui intéressent l’usager et il peut alors récupérer le bureau d’enregistrement de

son vol.

6. Conclusion

Dans ce chapitre, nous avons défini le modèle d’architecture choisi pour les applications de

proximité : le P2P hybride. Dans ce modèle d’architecture, on distingue deux types de

nœuds : central et léger. Les nœuds sont principalement différenciés en fonction de leurs

ressources et de leur comportement (mobile ou fixe). Le service de localisation ISLANDS

proposé pour la localisation des informations au sein d’une application de proximité est donc

adapté à ce modèle d’architecture. Nous choisissons de distribuer une instance d’ISLANDS

sur chaque nœud. Les instances sont référencées entre elles au moyen de métadonnées en

fonction des connexions entre les différents nœuds.

Le service gère à la fois un accès proactif aux données en permettant la diffusion de certaines

informations mais également un accès réactif. Dans ce contexte, ISLANDS permet

d’exprimer et d’évaluer une requête sur l’espace de recherche constitué des différents

« îlots » d’informations. Un type particulier de requêtes est géré par ISLANDS : les requêtes

dépendantes de la localisation. Pour l’évaluation de ces requêtes, la localisation

géographique de l’utilisateur est requise. Cette localisation est fournie par le module de

positionnement. Ce module est une interface entre les différents systèmes de positionnement

présents sur le terminal tels qu’un module GPS. En outre, ce module repose également sur

une solution de localisation utilisant l’environnement du nœud client qui permet ensuite

d’évaluer les requêtes dépendantes de la localisation. Dans le chapitre suivant, nous

décrivons cette solution permettant la localisation géographique d’un utilisateur mobile.

Dans le document Requêtes dépendantes de la localisation : Expression, évaluation et optimisation (Page 65-70)