Architecture du prototype

L’architecture logicielle du prototype mis en œuvre suit les mêmes principes que l’architecture générique proposée dans le chapitre IV. En effet, des modules sont implantés au-dessus du SGBD Oracle afin de tenir compte de la dépendance des résultats par rapport à la localisation du client mobile et des contraintes de temps réel. Ainsi, cette architecture s’articule autour de quatre principaux modules : Client Mobile, Transformations, Gestion des

Contraintes de Temps Réel, Vérifications et Transfert des Résultats. Pour communiquer avec le

SGBD Oracle, nous utilisons l’interface de programmation (API) JDBC.

Client Mobile Génération Requêtes Génération Mouvement Détermination Localisation Réception Résultats Identification Contraintes et Détermination du Type de requêtes

Dérivations de Prédicats Spatiaux Réécritures de Requêtes

Transformations

Gestion des Contraintes de Temps Réel Détermination Echéances Ordonnancement EDF JD BC SGBD Oracle

Vérifications et Transferts des Résultats Vérification Validité Spatiale Vérification Validité Temporelle File à priorité Transfert Requêtes Résultats

Client Mobile

Le but principal est de valider nos propositions en implémentant surtout les modules de notre architecture permettant la prise en compte des contraintes de temps réel et de la dépendance des résultats par rapport à la localisation. Pour cette raison, nous avons choisi de développer un module permettant de simuler le comportement des clients mobiles, au lieu de mener des expérimentations avec plusieurs utilisateurs possédant des vrais terminaux mobiles et soumettant des requêtes RDL à travers des réseaux sans fil tout en se déplaçant. Le fait d’avoir choisi de simuler le comportement du client mobile permet d’avoir plus de liberté concernant les exemples de requêtes choisis pour tester le prototype proposé.

Les clients mobiles sont assimilés à des points mobiles se déplaçant dans des directions et avec des vitesses choisies aléatoirement. Les localisations initiales des clients mobiles sont distribuées selon la loi uniforme dans une surface carrée appelée surface globale de travail (notée Work_Space). Le sous-module Génération Mouvement permet de générer aléatoirement la localisation initiale, la vitesse et la direction du client mobile. Nous supposons qu’entre l’instant d’envoi de la requête et l’instant de réception des résultats, un client mobile se déplace à une vitesse constante et ne change pas de direction. Selon la valeur de la vitesse, nous distinguons des clients : (i) avec un déplacement lent (leur vitesse est comprise entre 10 km/h et 50 km/h) (e.g. un client se déplaçant au centre ville), (ii) avec un déplacement moyen (leur vitesse est comprise entre 50 km/h et 80 km/h) (e.g. un client se déplaçant sur une voie rapide urbaine), (iii) avec un déplacement rapide (leur vitesse est comprise entre 80 km/h et 110 km/h) (e.g. client se déplaçant sur une route nationale), et (iv) avec un déplacement très rapide (leur vitesse est supérieure à 110 km/h) (e.g. client se déplaçant sur une autoroute).

Grâce au sous-module Détermination Localisation, la position du client mobile à n’importe quel instant est déterminée en fonction de sa localisation initiale, de sa vitesse et de

sa direction.

Le client mobile génère également des requêtes exprimées dans le langage LDQL décrit dans le chapitre III. Nous expliquons dans la section 3.1 la génération aléatoire des requêtes (e.g. selon le type, les données interrogées, le nombre de jointures, la loi d’arrivée).

Le sous-module Réception Résultats permet de recevoir et d’afficher les résultats obtenus après le traitement d’une requête RDL.

Transformations

Grâce au module Transformations, les requêtes exprimées dans le langage LDQL sont transformées en requêtes exprimées selon la syntaxe du langage SQL étendu (proposé par Oracle pour l’expression des requêtes spatiales). Cette transformation tient compte des conditions de dépendance des résultats par rapport à la localisation du client mobile, des contraintes temporelles et des conditions liées aux résultats partiels. Ainsi, nous implantons différents algorithmes présentés dans le chapitre V, à savoir : l’identification des contraintes et la détermination du type de requêtes, la dérivation des prédicats spatiaux et la réécriture des requêtes. Afin d’incorporer la localisation du client lors de la transformation de la requête, ce module fait appel à la méthode Détermination Localisation du module Client Mobile. Pour évaluer des requêtes continues, les deux méthodes proposées dans le chapitre V ont été implantées dans deux versions différentes du prototype. Rappelons que la première méthode consiste à

réévaluer la requête périodiquement en tenant compte du changement de localisation. Cette méthode ne nécessite pas de modifier les méthodes de transformation. Par contre, la seconde méthode nécessite de déterminer la zone de tous les résultats potentiellement corrects en dérivant les prédicats spatiaux (cf. chapitre V). La détermination de la zone de résultats potentiellement corrects fait partie du sous-module Dérivation des Prédicats Spatiaux de notre prototype.

Gestion des Contraintes de Temps Réel

Dans notre prototype, nous avons mis en œuvre la méthode de détermination des échéances présentée dans le chapitre VI pour attribuer une échéance à chaque requête selon son type. Rappelons que pour les requêtes RDL, cette méthode déduit une échéance en fonction du déplacement du client et du rayon de la surface de sélection. Si une autre échéance est précisée par le client mobile, cette méthode associe à la requête l’échéance la plus petite (cf. chapitre VI). Nous avons également mis en œuvre l’algorithme EDF pour ordonnancer les requêtes selon leurs échéances dans une file à priorités. La requête ayant l’échéance la plus proche est soumise au SGBD Oracle.

Vérifications et Transfert des Résultats

Les résultats des requêtes évaluées par le SGBD Oracle sont reçus par le module

Vérifications et Transfert des Résultats. Ce module est constitué des trois sous-modules suivants : Vérification de la Validité Spatiale, Vérification de la Validité Temporelle des résultats et Transfert des Résultats. La méthode de vérification de la validité spatiale calcule la distance entre chaque

objet cible et la localisation du client mobile. Nous avons implanté un algorithme basé sur la formule de Vincinty pour calculer la distance entre deux points possédant des coordonnées géographiques [Vin 75]. La précision de cet algorithme est de l’ordre de 0.5 mm [Vin 75]. C’est cette formule qui est utilisée par Oracle spatial. La méthode de vérification de la validité temporelle proposée dans le chapitre VI a été mise en œuvre afin d’éviter de transmettre les résultats des requêtes ne respectant pas leurs échéances. De même, cette méthode permet de déterminer le nombre d’objets cibles à transmettre en fonction de l’échéance lorsqu’un résultat partiel est toléré. Pour des contraintes matérielles, le prototype développé ne transmet pas les résultats des requêtes sur un réseau sans fil. Comme dans [IMI 06], le temps de transfert est calculé en supposant que nous disposons d’un débit réseau de 40kbp/s.

Avant de présenter des scénarii de test et de montrer les résultats de certains exemples de requêtes RDL expérimentées à l’aide de ce prototype, précisons que la mise en œuvre de ces modules a nécessité le développement de 7 classes Java. Ajoutons que d’autres classes ont également été développées pour générer aléatoirement les données interrogées (relatives aux objets cibles), les temps d’inter-arrivées entre les requêtes et les échéances ainsi que pour mesurer les performances des méthodes proposées.