Chapitre 6 : Prototype
2. Description des différents composants
Dans une application de proximité, le service ISLANDS est distribué sur chaque nœud de
l’application De ce fait, une version du prototype est déployée sur chaque nœud.
L’architecture du prototype implémenté est décrite dans la figure 6.1. Le prototype repose
sur quatre composants principaux :
- l’interface utilisateur : elle fournit à l’utilisateur un moyen de composer sa requête et de
visualiser les différents résultats.
- le gestionnaire de stockage des informations : les différentes informations partagées par
l’utilisateur y sont stockées.
- le module de positionnement : il fournit la localisation du client.
- l’évaluateur de requêtes d’ISLANDS : le service de localisation ISLANDS permet la
diffusion d’informations par les vendeurs mais il fournit un évaluateur dédié à
l’évaluation des requêtes émises par les différents participants dans l’application de
proximité.
Instance du service
ISLANDS
Interface utilisateur
Module de
positionnement
Stockage des
informations
Requête
Réponses
Interrogation Réponses
Interrogation Localisation
Autres instances
d’ISLANDS
accessibles
Evaluateur de
requêtes
Invocations locales sur le noeud Invocations distantes vers d’autres nœuds connectés
Figure 6.1. Composants de l’implémentation du prototype
Lorsqu’un client émet une requête : le client commence par saisir la requête via l’interface
utilisateur disponible sur son terminal. La requête saisie est ensuite envoyée au service de
localisation ISLANDS. S’il s’agit d’une requête dépendante de la localisation, le service
interroge le module de positionnement du nœud pour récupérer la localisation géographique
de l’utilisateur. Ensuite, l’évaluation de la requête est gérée par le service qui interroge les
informations partagées localement par le client mais également par les autres nœuds de
l’application en utilisant les différentes instances d’ISLANDS.
2.1. Interface utilisateur
Dans le prototype, deux séries d’interfaces différentes ont été réalisées. La première est
destinée aux nœuds centraux et la seconde est adaptée aux nœuds légers. En effet, dans une
application de commerce électronique de proximité, les fonctionnalités proposées aux
différents nœuds sont différentes en fonction du type de nœuds (central ou léger). De même,
les contraintes d’affichage sont différentes et elles interviennent donc dans la conception des
différentes interfaces. Les nœuds centraux représentent les vendeurs présents dans la galerie
marchande donc les différentes fonctionnalités à développer sont :
- la saisie/modification/suppression d’une offre (promotions, soldes etc.)
- la diffusion d’offres
- la saisie/modification/suppression d’un article ou d’un produit
Les interfaces développées pour les vendeurs sont statiques : la génération dynamique
d’interfaces pour les vendeurs n’est pas nécessaire. Le s fonctionnalités sont fixées et définies
pour l’application : les vendeurs peuvent diffuser des informations, enregistrer, modifier ou
supprimer de nouveaux produits et de nouvelles offres. Un exemple d’interface utilisée par
les nœuds centraux est illustré par la figure 6.2. Cette figure représente l’interface utilisée
pour la saisie d’un nouveau produit par un vendeur.
Figure 6.2. Interface utilisateur pour les nœuds centraux
En revanche, la série d’interfaces dédiée aux nœuds légers repose sur un fichier de
configuration. Ce fichier XML décrit les différentes étapes et enchaînements nécessaires à
l’expression d’une requête par un client. Ce fichier de configuration est diffusé dans la
galerie marchande et permet de générer des interfaces en fonction de l’environnement de
l’application de proximité. Un extrait du fichier de configuration utilisé dans l’application de
commerce électronique de proximité est décrit dans la figure 6.3.
<?xml version="1.0" encoding="ISO-8859-1" ?>
<CEP>
<Request>
<Produit type-directory="objectClass" id-directory="Product">
<Nom type-directory="attribute" id-directory="name">
<Vendeur type-directory="objectClass" id-directory="Store">
<Nomtype-directory="attribute" id-directory="name" />
<Typetype-directory="attribute" id-directory="type" />
</Vendeur>
</Nom>
<Type type-directory="attribute" id-directory="type">
<Vendeur type-directory="objectClass" id-directory="Store">
<Nomtype-directory="attribute" id-directory="name" />
<Typetype-directory="attribute" id-directory="type" />
</Vendeur>
</Type>
</Produit>
<…>
</Request>
<Localization>
<Close>
<Store type-directory="objectClass" id-directory="Store">
<Nametype-directory="attribute" id-directory="name" />
<Typetype-directory="attribute" id-directory="type" />
</Store>
</Close>
<…>
</Localization>
<CEP>
Figure 6.3. Fichier de configuration des interfaces graphiques pour la saisie des requêtes
Ce fichier contient deux parties, la première consiste à représenter les choix possibles pour la
requête classique (i.e. non dépendante de la localisation), la seconde permet, quant à elle de
saisir les informations relatives aux requêtes de localisation. Dans l’annexe 6, le fichier de
configuration utilisé est représenté dans son intégralité.
Les différents nœuds légers représentent des clients munis de terminaux nomades.
Cependant, ces terminaux offrent des capacités d’affichage hétérogènes : noir et blanc,
niveaux de gris, couleurs, taille de l’écran, etc. La saisie d’une requête est donc réalisée par
une série d’interfaces simples guidant l’utilisateur. La figure 6.4 représente la série
d’interfaces générées gr âce au fichier de configuration et utilisées pour exprimer la requête
« Quels sont les fast- foods situés à moins de 50 mètres de moi ? ». L’utilisateur peut
naviguer au travers de ces différentes interfaces par les boutons « Back » et « Next » comme
il en a l’habitude sur les terminaux légers.
Figure 6.4. Interfaces utilisateur pour les nœuds légers
2.2. Service de localisation ISLANDS
Le service de localisation est composé de trois parties :
- le module de positionnement : il permet de récupérer la localisation du client. Cette
localisation est, soit issue d’une technique de géo- localisation tel que le GPS, soit issue
de notre solution de localisation décrite également dans le chapitre 4. Ce module de
positionnement fournit au service de localisation une représentation XML (localisation
physique et/ou localisation symbolique) de la localisation du client.
- le gestionnaire de stockage : dans le prototype implémenté, les informations des nœuds
centraux sont stockées au sein de l’annuaire LDAP OpenLDAP. Les services d’annuaire
nous permettent notamment de privilégier l’accès aux données en lecture plutôt qu’en
écriture. Les informations des nœuds légers sont quant à elles stockées au sein de fichiers
XML.
- l’évaluateur de requêtes : il est quant à lui composé de 5 composants :
o le parseur de la requête qui permet de décomposer les requêtes, en particulier les
requêtes de localisation.
o l’évaluateur de la requête qui permet l’évaluation d’une requête sur les données
stockées localement.
o l’évaluateur de l’opérateur de localisation qui permet d’évaluer les différents
opérateurs de localisation comme nous l’avons décrit dans le chapitre 5.
o le composant permettant de gérer la distribution de la requête au sein de la sphère
de communication.
o le composant permettant la construction finale du résultat en fonction des
différents paramètres précisés par le client tels que le nombre de réponses
souhaitées.
L’évaluateur de requête présent dans ISLANDS peut être adapté en fonction des ressources
disponibles sur le nœud qui l’héberge. En effet, dans le cas d’un nœud léger, seule une
version dégradée de l’évaluateur peut être utilisée. Cette version dégradée d’ISLANDS
comporte le parseur de la requête qui permet entre autre de définir s’il s’agit d’une requête
dépendante de la localisation ou non et le composant permettant de gérer la distribution de la
requête. Ainsi, si le nœud client ne bénéficie que de la version dégradée, la requête est
directement envoyée aux autres instances d’ISLANDS avec le paramètre contenant la
localisation géographique de l’utilisateur s’il s’agit d’une requête dépendante de la
localisation.
Par contre, les nœuds centraux peuvent, quant à eux, bénéficier d’une version élaborée
d’ISLANDS comprenant en plus un composant permettant la diffusion d’informations sur la
sphère de communication.
Dans la suite, nous présentons en détail l’évaluation d’une requête au sein d’ISLANDS puis
nous décrivons l’infrastructure de communication utilisée.
Dans le document
Requêtes dépendantes de la localisation : Expression, évaluation et optimisation
(Page 123-127)