Conception et réalisation d'une plateforme de déploiement de services géolocalisés

Transcription

1 Université Libre de Bruxelles Année académique Faculté des Sciences Appliquées Service Informatique et Réseaux Conception et réalisation d'une plateforme de déploiement de services géolocalisés Directeur de Mémoire : Esteban Zimányi Mémoire de n d'études présenté par Patrick DESSALLE en vue de l'obtention du grade d'ingénieur Civil Informaticien.

2 Remerciements Je remercie d'abord mon promoteur Esteban Zimányi pour l'aide, le soutien et la disponibilité dont il a fait preuve tout au long de l'année. Je tiens également à remercier Jean-Michel Dricot et Serge Boucher pour leurs conseils et leurs idées fournies au premier semestre. Je remercie nalement ma famille, mes amis et mon frère qui a pris le temps de relire et de me conseiller dans la rédaction de ce rapport. i

3 Table des matières Table des matières Table des gures ii v 1 Introduction Contexte Objectifs du mémoire Organisation du rapport de mémoire Services géolocalisés Introduction Vue générale Exemples de services géolocalisés Types de services Push et Pull Positionnement de personnes et d'appareils Services diérents selon la position Dangers et abus Vie privée Spamming Surfacturation Méthodes de positionnement Positionnement satellitaire Réseaux cellulaires Positionnement indoor Positionnement par WiFi Positionnement sur Internet Etat de l'art Localisation par GSM - GeoMobile.be Plateformes géolocalisées - RedSpider LOBOS Localisation par WiFi - HereCast.com Localisation par IP - Windows Local Live Qui seront les futurs acteurs? ii

4 TABLE DES MATIÈRES 2.8 Conclusion Les données spatiales Introduction Représentation d'une position Géodésie Projections Calcul de distance Open Geospatial Consortium Données spatiales : OGC Autres recommandations de l'ogc Les bases de données spatiales Structure OpenGIS MySQL PostgreSQL Oracle 10g DB Middleware Création et manipulation de données spatiales Conclusion Choix préliminaires Introduction Scénario de base Modélisation du scénario Spécications Choix de l'architecture Technologies choisies Java Java Standard Edition Java Enterprise Edition Enterprise Java Bean Serveurs applicatifs J2EE XDoclet GeoTools PostGIS Eclipse et JBoss IDE phppgadmin Conclusion Implémentation Introduction Suppositions Jeu de données iii

5 TABLE DES MATIÈRES Le jeu de données Spearsh Le jeu de données Frida MapViewer Vision générale Client - Serveur Eléments de la plateforme Middleware J2EE Session Services avec ou sans identication Souscription payante aux services Services en cascade La super-classe ServiceBean HistoryBean Achage de cartes Structure du code Le package mfe.silas.lbs Le package mfe.silas.utils Le client SilasTalker couche graphique couche logique Le système de plugins pour les services Packages pour développeurs Améliorations Web Services Cartes Poisoning Réalisation du scénario Introduction GeoMail PostMessage GetMessage Client GeoMail FriendFinder Exemples de code Utiliser les méthodes de ServiceBean Créer une carte Scénario Conclusion 79 Bibliographie 80 iv

6 TABLE DES MATIÈRES Annexes 84 A Grammaires WKT 84 A.1 WKT pour les types spatiaux A.2 WKT pour les systèmes de références spatiaux B Calcul de distance de Vincenty 87 C Utilisation de PostGIS 88 C.1 Introduction C.2 Installation de PostGIS C.3 Conguration C.4 Créer une base de données spatiale C.4.1 Créer une table spatiale C.4.2 Créer une vue spatiale D Eclipse et JBoss 91 D.1 JBoss D.2 Eclipse v

7 Table des gures 2.1 Architecture LBS Téléphone dans une cellule Positionnement par Timing Advance [22] Positionnement par Time of Arrival [22] Positionnement par Angle of Arrival [22] Positionnement par E-OTD [22] Géoïde, sphère et ellipsoïde Datums locaux Projection cylindrique régulière, transverse et oblique [19] Zones UTM de la France et de la Belgique Projections coniques [19] Projections pseudo-cylindrique interrompue [19] Projection azimuthale et de Winkel [19] Projection Armadillo sur un tore [19] LineString simple et ouverte ; LineString simple et fermée (LinearRing) LineString non simple et ouverte ; LineString non simple et fermée Schéma UML des données spatiales OGC Représentation WKT de la projection UTM 30 Nord avec un géoïde WGS Structure des tables SQL OGC ShoutSpace Concurrence sans contrôle Concurrence avec contrôle Intégration de JBoss dans Eclipse (1) Intégration de JBoss dans Eclipse (2) Extrait du jeu de données Spearsh Le jeu de données Frida Diagramme UML simplié de MapViewer Sélection des couches dans MapViewer vi

8 TABLE DES FIGURES 5.5 Schéma UML simplié de l'architecture de Silas Carte et position de l'utilisateur dans SilasTalker Structure des packages du serveur Silas Structure du package mfe.silas.lbs Diagramme UML du client SilasTalker Système de découpage pour les cartes Alice lance SilasTalker et se connecte Alice lance ServiceFinder et sélectionne FriendFinder Alice voit Bob et sa position et lui envoie un message Bob reçoit le message d'alice vii

9 Chapitre 1 Introduction 1.1 Contexte Depuis quelques années, les appareils mobiles se multiplient et deviennent à la fois plus légers et plus puissants. Les GSM contiennent de plus en plus de possibilités multimédia (photo, son, vidéo,...), augmentent leur capacité mémoire et leur puissance de calculs. Les PDA peuvent être branchés à des récepteurs GPS ou contiennent directement la puce de réception GPS. Les voitures sont capables de capter les signaux GPS mais aussi d'accueillir des téléphones. Chacun de ces appareils a des caractéristiques diérentes que ce soit par la vitesse d'accès à Internet, la capacité de mémoire et de calcul ou la précision du positionnement. Mais on peut raisonnablement miser sur la généralisation prochaine d'appareils connectés à un réseau (Internet, GSM, UMTS, WiFi,...) capables de connaître leur position. L'expression services géolocalisés (en anglais, LBS pour Location-Based Services) regroupe l'ensemble des services basés sur la position géographique de l'utilisateur. Il existe plusieurs moyens de connaître, avec plus ou moins de précision, la position d'un appareil. Cela peut se faire au moyen des satellites GPS qui gravitent autour de la Terre ou à l'aide des cellules des réseaux GSM ou encore des points d'accès du WiFi. Cette précision va en s'améliorant grâce à l'augmentation de la densité des réseaux cellulaires, le lancement de nouvelles constellations de satellites comme dans le projet Galileo et l'intégration de techniques de localisation dans les protocoles Internet. Tous ces systèmes permettront à tout un chacun de facilement connaître sa position et ainsi d'utiliser des services géolocalisés. 1.2 Objectifs du mémoire Dans ce mémoire, nous allons identier les diérents types de services qui peuvent être déployés sur une plateforme géolocalisée. Nous allons analyser 1

10 CHAPITRE 1. INTRODUCTION les besoins communs de ces services et déterminer un ensemble de composants réutilisables pour construire plus facilement de tels services. Un scénario sera ensuite choisi pour créer un premier service sur base de ces composants de base et d'outils supplémentaires. Par la suite, une plateforme sera développée et on y déploiera le service correspondant au scénario an de valider la conception. Un client capable de découvrir les services, d'émettre des requêtes et d'acher les résultats sera également développé. La création d'un ensemble de composants réutilisables du côté client et du côté serveur pour le déploiement de services géolocalisés a pour but de simplier au maximum le travail des développeurs de services. 1.3 Organisation du rapport de mémoire Le rapport commence par une introduction aux diérentes notions relatives aux services géolocalisés. On y expose les diérentes catégorisations possibles de ces services et on y donne des exemples de services existants ou imaginables. Diérentes méthodes de positionnement d'un utilisateur sont également introduites suivies par un état de l'art montrant des exemples d'exploitation de ces techniques. Le chapitre 3 s'intéresse à la représentation des positions. Après une courte explication des modèles de la Terre et des projections principalement utilisées à l'heure actuelle, nous introduisons le modèle de données spatiales établi par l'ogc. L'OGC ou Open Geospatial Consortium est une initiative internationale regroupant des agences gouvernementales, des entreprises privées et des universités pour établir des standards sur les données spatiales et la communication entre applications exploitant ces données. Le modèle de l'ogc spécique aux bases de données spatiales est ensuite présenté, suivi par une description des diérents acteurs sur le marché des bases de données spatiales. Le chapitre 4 s'attarde plus particulièrement sur les besoins technologiques des services géolocalisés et les choix technologiques que nous avons pris. A côté de la justication des technologies, nous détaillons les particularités utiles au développement de notre plateforme. Le chapitre suivant contient les détails des fonctionalités, de la conception et de l'implémentation du serveur, du client et du logiciel de visualisation des données. Les détails de l'implémentation de notre scénario et des exemples de code permettant d'utiliser la plateforme sont exposées dans le chapitre 6. Pour nir, le chapitre 7 contient la conclusion de ce mémoire. 2

11 Chapitre 2 Services géolocalisés 2.1 Introduction Ce chapitre a pour but de donner une vision générale des services géolocalisés (également appelés LBS pour Location-Based Services). On va commencer par y décrire l'architecture classique des LBS avec les diérents éléments nécessaires an d'assurer leur bon fonctionnement. Ensuite, on va donner des exemples de services géolocalisés, les diérentes catégories dans lesquels on peut les classer et les besoins qui en découlent. Nous aborderons également les éventuels abus relatifs à une connaissance constante de la position des utilisateurs. Une solution à ces abus doit être trouvée an de permettre au grand public de faire conance aux services géolocalisé. C'est probablement le principal obstacle pour l'adoption en masse de ces services. Nous allons ensuite lister les moyens les plus courants de positionner un appareil mobile. Cette connaissance peut être du côté de l'appareil luimême ou bien être uniquement connue du réseau auquel il est connecté. Nous allons également parler des techniques existantes pour améliorer la précision du positionnement et aborderons les techniques de positionnement des ordinateurs basées sur leur adresse IP. Diérents services existants basés sur ces diérents moyens de localisation seront illustrés dans l'état de l'art. Nous en proterons également pour identier les probables futurs grands acteurs des services géolocalisés. 2.2 Vue générale L'infrastructure globale nécessaire pour le bon fonctionnement d'un service géolocalisé est composée de diérents éléments : l'appareil de l'utilisateur, un élément de localisation, une plateforme, des bases de données et les services eux-mêmes. Les utilisateurs utilisent un appareil (par exemple un téléphone mobile, un PDA, un ordinateur portable,...) an d'accéder aux services proposés 3

12 CHAPITRE 2. SERVICES GÉOLOCALISÉS Fig. 2.1 Architecture LBS. par la plateforme de services géolocalisés. La position de l'utilisateur est calculée au moyen d'un élément de localisation. Cet élément de localisation peut être situé du côté client ou du côté du réseau. Du côté client, on retrouve par exemple les récepteurs GPS, qui peuvent être directement intégrés dans l'appareil. Du côté réseau, on retrouve entre autres les techniques de positionnement des GSM. En eet les GSM actuels peuvent être approximativement localisés au moyen des stations de base du réseau GSM. L'utilisateur nal n'a alors pas connaissance de sa position. La plateforme est une application tournant sur un serveur et a pour but de faciliter l'accès aux données spatiales au travers de diérents outils. Elle permet également de reprendre une partie de la complexité de la logique métier du service géolocalisé. Globalement, la plateforme et le service géolocalisé travaillent ensemble an de simplier au maximum les besoins du côté client. Cela permet de diminuer la puissance de calcul ainsi que la bande passante nécessaire au bon fonctionnement du service. La plateforme permet de mettre à disposition de l'utilisateur les services géolocalisés situés sur la plateforme. Sur base de sa position et d'autres données annexes éventuellement nécessaires (direction, vitesse, lieu de destination,...), la plateforme communique avec des bases de données et ore des outils aux services géolocalisés. Ceux-ci eectuent la logique métier an de renvoyer à l'utilisateur la réponse à sa requête. Les données renvoyées par les services géolocalisés peuvent être de tout type : la liste des restaurants italiens les plus proches, une carte des rues avoisinantes, le meilleur itinéraire pour rejoindre un autre endroit, un enregistrement audio ou vidéo d'informations touristiques sur l'endroit visité,... Le client communique avec le fournisseur de services au travers d'un réseau (Internet, réseaux GSM d'un opérateur, réseau WiFi dans une entre- 4

13 CHAPITRE 2. SERVICES GÉOLOCALISÉS prise,...). Comme on peut le remarquer, dans ces diérents types de réseaux, les services géolocalisés peuvent être limités à un certain groupe de personnes (les clients d'un opérateur GSM) ou aux personnes dans une région géographique limitée (les employés dans un bâtiment ou dans une usine). On peut bien sûr aussi déployer des services géolocalisés à l'échelle mondiale grâce à Internet ou nationale avec les opérateurs GSM. 2.3 Exemples de services géolocalisés Pour donner une idée plus claire de ce que l'on considère comme étant un service géolocalisé, nous allons introduire les grandes familles de services que l'on peut imaginer. Il faut noter que cette liste n'est pas exhaustive. Le tracking de marchandises, de ottes de camions, de taxis,...est généralement considéré comme une des applications majeures des services géolocalisés car ils ont une utilité industrielle. En eet, ils peuvent améliorer les rendements en fournissant des informations comme l'avertissement de retards de livraison. Ils permettent aussi d'optimiser l'usage d'une otte de taxis. Ce genre de services est déjà mis en uvre dans de nombreuses sociétés comme les Taxis Verts à Bruxelles. On peut également faire du tracking de personnes. Certains parents pourraient vouloir connaître à tout moment où se trouve leur enfant ou être avertis quand il quitte l'enceinte de l'école. Le tracking de personnes soulève cependant des questions de respect de la vie privée. Les informations générales par rapport au lieu où l'on se trouve sont des services ayant une forte valeur ajoutée. Dans cette catégorie on retrouve par exemple un service permettant de rechercher l'ensemble des restaurants selon des critères (prix, style,...) dans un rayon donné autour de l'utilisateur. Les services liés à la sécurité sont également une application possible pour les services géolocalisés. Certaines voitures pourraient être équipées d'un système de positionnement capable d'appeler une ambulance et de donner la position précise du véhicule en cas de problème. Mais cette catégorie regroupe également des informations d'intérêt général, comme l'avertissement de personnes présentes dans une certaine zone qu'ils doivent évacuer après un feu ou une explosion. Les services de communication sont une autre application des services géolocalisés. Dans la lignée des services de messageries instantanés, on localise et communique avec des connaissances situées dans une même zone géographique. Les divertissements sont une des possibilités pour l'adoption massive des services géolocalisés par le grand public. Des jeux grandeur nature comme des chasses au trésor peuvent être mis en uvre à l'aide de 5

14 CHAPITRE 2. SERVICES GÉOLOCALISÉS services géolocalisés. Finalement, la publicité est vue comme une des industries majeures pouvant tirer parti des services géolocalisés. On pourrait demander la liste de magasins environnants qui font des promotions ou être avertis des produits en promotion lorsque l'on rentre dans un magasin. En plus du tracking de marchandises, la localisation de téléphones mobiles est également vue comme une des motivations à développer des services géolocalisés. La Federal Communication Commission (l'organe américain de régulation des communications, un peu comme l'ibpt belge) a exigé que les opérateurs de réseaux GSM américains puissent positionner leurs utilisateurs dans un rayon de 125 mètres an de faciliter le travail des services d'urgence. Cette régulation a poussé au développement de ces systèmes de localisation mais a fait également rééchir aux possibilités des services géolocalisés. Désormais, les téléphones cellulaires vendus aux USA ont un système de localisation intégré que ce soit grâce à une puce GPS ou grâce à une des méthodes de positionnement expliquées dans le point Types de services Push et Pull On peut classer les services géolocalisés selon la manière d'accéder à l'information. Les applications de type pull qui, comme leur nom anglais l'indique, consistent à récupérer des informations géolocalisées depuis le serveur à la demande du client. C'est donc l'utilisateur qui initie le transfert d'informations depuis le serveur. Les applications du type push envoient des informations au client sans qu'il en fasse la demande explicite, par exemple lorsqu'il arrive dans une certaine zone géographique. Cependant, dans les applications de type push, an que le serveur connaisse de manière constante la position de l'utilisateur, il est nécessaire que celui-ci mette régulièrement à jour sa position. De plus, pour que tous les utilisateurs d'une région reçoivent un message, il faut qu'à intervalle de temps régulier, le système récupère les utilisateurs dans une région et leur envoie un certain message. Les coûts en bande passante (communications entre les clients ou entre la plateforme et les services) et en puissance de calcul (calcul régulier de la distance des utilisateurs par rapport à une certaine zone) sont plus importants que les services de type pull. C'est pourquoi, il n'est pas encore très clair si ce genre de services est économiquement rentables [18]. Parmi les exemples cités dans le point 2.3, les services du type push sont l'avertissement des enfants quittant leur école, la publicité quand on rentre dans un magasin ou encore les alertes d'incendies. 6

15 CHAPITRE 2. SERVICES GÉOLOCALISÉS Positionnement de personnes et d'appareils Dans les services géolocalisés, on peut vouloir localiser soit des objets, soit des personnes. La localisation d'un objet se fait en localisant un appareil géolocalisable couplé à l'objet. Par exemple dans le cas de tracking de marchandises, on ne s'intéresse pas à savoir où se trouve le chaueur mais bien où se trouve le camion puisque la personne qui conduit le camion n'est pas pertinent pour un tel système. De manière similaire, dans un système de localisation de voiture, généralement utilisé pour retrouver une voiture volée, ce n'est pas le conducteur dont on souhaite connaître la position mais bien le véhicule. La localisation d'un appareil peut correspondre à une personne mais ce n'est pas une obligation. Dans le cas de la localisation de personnes, on souhaite connaître la position d'une personne en particulier et celle-ci garde généralement un certain contrôle sur cette localisation en ayant la possibilité de ne pas faire connaître sa position. Cette notion est également utile si on imagine qu'une personne peut posséder plusieurs appareils de positionnement et que par exemple, il en oublie un. Il faudra dans ce cas être capable de localiser la personne et non pas les appareils qui donneront des localisations diérentes Services diérents selon la position Une utilité des services géolocalisés est la capacité d'orir des services diérents en fonction de la position de l'utilisateur ou de lui fournir des données diérentes en fonction de cette position. Dans une usine d'assemblage de voitures, la personne contrôlant la qualité peut, grâce à de tels services géolocalisés, obtenir automatiquement des statistiques sur les diérentes étapes de la chaîne de production. Il ne doit pas préciser quelle étape il est en train d'inspecter puisque sa position dans l'usine permet de conclure ce qu'il inspecte. Dans un musée, un visiteur pourrait automatiquement recevoir des informations sur l' uvre d'art qu'il a devant soi. 2.5 Dangers et abus Vie privée Une des grandes craintes des services géolocalisés est l'atteinte à la vie privée. Le fait de communiquer sa position peut être réutilisé à des ns commerciales ou dans un état policier. An de limiter ce risque, il faut donner à l'utilisateur un maximum de contrôle sur la transmission de données ainsi que des garanties légales par rapport à l'utilisation, la manipulation et la revente des données stockées lors de l'utilisation de tels services. 7

16 CHAPITRE 2. SERVICES GÉOLOCALISÉS Spamming Une autre grande crainte des services géolocalisés est l'apparition d'une nouvelle forme de spam. En eet, des messages publicitaires non sollicités pourraient être envoyés de manière intempestive aux utilisateurs lorsqu'ils arrivent dans une certaine zone. Si on imagine que dans une galerie commerçante tous les magasins décident d'avertir les passants des promotions en cours, on comprend facilement qu'il faut imposer une certaine forme de limitation. Ce problème est assez compliqué à résoudre comme on peut le remarquer avec Internet. L'idéal serait probablement d'imposer l'opt-in c'est-à-dire l'autorisation préalable de l'utilisateur avant de lui envoyer un message (à l'exception de messages comme des avertissements d'incendie) Surfacturation La question de la facture reste ouverte. Chaque service et chaque fournisseur de plateforme géolocalisée sera probablement libre de facturer comme bon lui semble. En examinant la situation actuelle des services par SMS, on peut prédire qu'ici aussi il est possible d'avoir des problèmes de surfacturation. Par exemple, des sociétés mal intentionnées pourraient envoyer des messages push payant non sollicités. Comme pour les services par SMS, la communication sur les tarifs de l'utilisation des diérents services doit être claire an d'éviter de mauvaises surprises lors de la réception de la facture. 2.6 Méthodes de positionnement Positionnement satellitaire Le système GPS Le système GPS (Global Positionning System) est probablement le système de localisation le plus connu et le plus utilisé par le grand public. Développé par le département de la défense américain pour un usage exclusivement militaire, il utilise une constellation de 24 satellites en orbite autour de notre planète. Trois satellites supplémentaires sont prévus en cas de panne parmi les 24 principaux. En 1984, un avion de la compagnie nationale coréenne s'est écrasé dû à l'imprécision des systèmes de navigation. Pour éviter qu'une telle catastrophe ne se reproduise, le président Reagan décida d'ouvrir gratuitement le GPS à des utilisations civiles avec une précision limitée par un brouillage du signal. En l'an 2000, le président Clinton a toutefois levé cette limitation, ce qui permet d'atteindre une précision de 3 à 15 mètres. Il est tout de même possible aux Américains de réactiver le brouillage sur une région donnée s'ils le jugent nécessaire. 8

17 CHAPITRE 2. SERVICES GÉOLOCALISÉS Le principe d'un GPS [10] est le suivant : un code pseudo-aléatoire est envoyé par chaque satellite GPS. Le récepteur GPS reçoit un signal provenant de chaque satellite qu'il arrive à percevoir et calcule la distance qui le sépare de ces satellites. Chaque distance permet de placer le récepteur sur une sphère centrée sur le satellite. En utilisant trois satellites, on obtient ainsi deux points, dont un est éliminé car situé trop loin de la Terre ou se déplaçant à une vitesse irréaliste. Pour connaître la position du satellite, chaque récepteur GPS possède une table contenant la position des diérents satellites. An de pouvoir faire cette triangulation, il faut eectuer un calcul précis de la distance entre le satellite et le récepteur. Ce calcul est possible grâce à la mesure du temps que met le signal pour arriver au récepteur GPS. Comme les ondes électromagnétique se déplacent à la vitesse de la lumière, il est nécessaire d'avoir un signal d'horloge très précis. Chaque satellite GPS possède donc quatre horloges atomiques synchronisés à un temps universel standard. L'information sur le temps ainsi qu'une correction de la position du satellite par rapport à sa position théorique sont inclues dans chaque signal envoyé par le satellite GPS. Un autre avantage est que ce signal peut-être utilisé par un récepteur xe pour avoir une horloge de précision atomique à un coût réduit. Systèmes concurrents D'autres nations ont développé des systèmes similaires. C'est le cas de l'union Européenne avec le système Galileo qui permettra d'obtenir une meilleur précision (moins de 4 mètres) dans sa version gratuite. Des précisions plus poussées sont possibles dans la version payante du service. La Russie possède GLONASS, un système limité (8 satellites, précision 70 mètres) et la Chine possède son propre système restreint à l'asie. Améliorations La précision des systèmes de positionnement par satellites est dégradée par plusieurs facteurs comme les interférences atmosphérique, le feuillage des arbres en forêt dense ou encore les gratte-ciels qui gênent la réception des signaux. Pour compenser les interférences de l'atmosphère et an d'améliorer la précision des données reçues par GPS, le système DGPS (Dierential GPS) est utilisé entre autre par les garde-côtes américains [10]. Il consiste à déployer des récepteurs GPS xes à des endroits dont la position exacte est connue. Ils peuvent ainsi calculer l'erreur entre leur position réelle et la position calculée par leur récepteur GPS et ensuite la diuser par ondes radios. Les signaux de correction sont gracieusement accessibles à tous et utilisés, par exemple, par les bâteaux s'approchant des côtes. Le Japon développe de son côté Quasi-Zenith, un système hybride qui a 9

18 CHAPITRE 2. SERVICES GÉOLOCALISÉS Fig. 2.2 Téléphone dans une cellule pour objectif de répondre aux problèmes de la visibilité des satellites GPS dans les villes comme Tokyo où les gratte-ciels gênent la visibilité en permettant de donner l'impression de constamment avoir les signaux venant verticalement (d'où le nom Quasi-Zenith) Réseaux cellulaires Le positionnement basé sur la téléphonie mobile a l'avantage du taux de pénétration déjà important des réseaux GSM. Presque tout le monde possède déjà un GSM et est donc potentiellement capable d'accéder à des services géolocalisés basés sur leur GSM. De plus, les réseaux GSM recouvrent la majorité des zones du globe où les services géolocalisés sont utiles (c'està-dire principalement les zones à forte densité de population). Finalement, les GSM sont peu coûteux et la plupart des systèmes de positionnement de téléphones mobiles ne nécessitent aucune adaptation du côté du client puisqu'ils sont exclusivement réalisés par le réseau. On peut donc déployer un système géolocalisé à partir de n'importe quel appareil connecté au réseau GSM, même un appareil ancien. Cette section est principalement basée sur [22] et [10]. Cell ID Les réseaux cellulaires comme ceux utilisés par le GSM ou l'umts utilisent un maillage composé d'un ensemble de cellules au centre desquelles 10

19 CHAPITRE 2. SERVICES GÉOLOCALISÉS Fig. 2.3 Positionnement par Timing Advance [22] sont placées les antennes GSM (ou UMTS). La taille de ces cellules dépend de la densité des utilisateurs et de leur besoin de communiquer. Moins il y a d'abonnés en train d'appeler par km 2, moins il faut d'antennes pour couvrir une zone. La cellule sera alors très grande. Si le nombre d'abonnés est grand, ce qui est le cas typique des zones urbaines, on retrouvera un grand nombre d'antennes GSM et les cellules seront typiquement plus petites. Ce système manque donc de précision dans les zones rurales (jusqu'à 35 kilomètres) et n'atteint par la précision du GPS dans les zones urbaines (au mieux 200 mètres). Cependant, il a un certain nombre d'avantages. Premièrement, la cellule GSM dans laquelle se trouve un appareil mobile est une information qui est déjà stockée pour assurer le bon fonctionnement d'un réseau GSM. Pour connaître la cellule, il sut donc d'aller consulter la base de donnée centrale du réseau. Ce qui implique que sa mise en place n'est pas coûteuse. Le réseau GSM évoluant constamment, de nouvelles antennes GSM sont régulièrement installées pour absorber l'augmentation du trac GSM. La précision va donc en augmentant. Les réseaux UMTS utilisent une architecture en cellules similaire mais possèdent des cellules plus petites ce qui permet une précision accrue. Déjà déployés dans certaines zones urbaines, ils ne seront toutefois disponibles partout en Belgique que dans quelques années. Timing Advance Cette technique permet, en combinaison avec le Cell ID, d'amélioration la précision de la localisation. En calculant le temps nécessaire au signal pour atteindre l'antenne GSM 1 la plus proche, on peut positionner le téléphone à 1 Les antennes GSM sont parfois appelles stations de base ou Base Station 11

20 CHAPITRE 2. SERVICES GÉOLOCALISÉS Fig. 2.4 Positionnement par Time of Arrival [22] l'intérieur d'un anneau autour de l'antenne. La résolution ainsi obtenue est de l'ordre de 500 mètres, ce qui rend cette technique plutôt utile dans les zones rurales. On ne peut pas positionner exactement le mobile sur un cercle car les ondes ne sont pas assurées d'atteindre le mobile en ligne droite, sans obstacle sur son chemin. L'utilisation de cette technique ne nécessite aucune modication dans le GSM ou dans l'infrastructure du réseau mais il est nécessaire d'ajouter une application software dans le réseau. Time of Arrival (TOA) Chaque mobile dans un réseau cellulaire est capable de recevoir des signaux provenant de diérentes antennes GSM et inversément, plusieurs antennes GSM sont capables de recevoir les informations d'un mobile. Cela est utile lorsque l'utilisateur se déplace et que le réseau doit évaluer s'il est nécessaire de faire basculer un utilisateur d'une antenne à une autre. En calculant le temps nécessaire à un même signal pour arriver à trois ou plus antennes GSM et sachant que les ondes électromagnétiques voyagent à la vitesse de la lumière, il est possible de déterminer la position du mobile par triangulation. Les stations de base doivent être synchronisées au moyen d'un signal d'horloge (par exemple grâce au GPS) pour un calcul précis des distances. Les mobiles ne doivent pas être modiés. Ce système permet d'atteindre des résolutions de 125 mètres. Angle of Arrival (AOA) Cette technique est similaire au TOA mais utilise cette fois la diérence de phase des signaux reçus pour calculer l'angle entre l'antenne et le mobile. 12

21 CHAPITRE 2. SERVICES GÉOLOCALISÉS Fig. 2.5 Positionnement par Angle of Arrival [22] Un râteau d'antennes séparés, par exemple, par une demi-longueur de l'onde utilisée par le GSM doit être installé à chaque station de base. En comparant les phases reçues par les diérentes antennes sur le rateau, on peut calculer l'angle d'incidence de l'onde. La précision ainsi obtenue est de l'ordre de 125 mètres. E-OTD Cette technique est similaire au DGPS mais dans les réseaux cellulaires. Un signal est envoyé par les stations de base et est reçu par le mobile mais aussi par une antenne spéciale (LMU) située à une distance xe et connue de chaque station de base. On utilise une des techniques précédentes (par exemple TOA) entre les stations de base et la LMU pour calculer la distance par triangulation et en tirer un facteur de correction basé sur la distance réelle. Le mobile calcule également sa position par triangulation et améliore la précision grâce au calcul eectué par le LMU. La précision peut atteindre 25 mètres. Cela nécessite de lourds investissements d'installation de LMU et une modication software des mobiles Positionnement indoor Le positionnement indoor (à l'intérieur des bâtiments) est utilisé pour se positionner à l'intérieur des bâtiments et nécessite une grande précision. Une des applications est, par exemple, le positionnement à l'intérieur d'un musée ou d'un supermarché. Les satellites GPS ne sont généralement pas visibles à l'intérieur des bâtiments et la précision du positionnement des réseaux cellulaires n'est pas susante pour positionner un visiteur dans une salle où 13

22 CHAPITRE 2. SERVICES GÉOLOCALISÉS Fig. 2.6 Positionnement par E-OTD [22] les uvres sont séparées de quelques mètres. D'autres technologies existent pour ce type d'application. Nous pouvons citer des techniques basées sur l'infrarouge (généralement bloqué par les murs), les ondes radios, l'ultrason (qui a l'avantage de se déplacer moins vite que les ondes électromagnétiques) ou encore le WiFi. Nous n'entrerons pas dans les détails de ces diérentes techniques. Le lecteur intéressé pourra se référer à [12] et [18] Positionnement par WiFi Le WiFi est une solution qui peut être utilisée pour du positionnement à l'intérieur et à l'extérieur des bâtiments. Les Access Point (AP) WiFi 2 peuvent être vus comme les antennes du réseau GSM et tout appareil capable de capter le signal d'un Access Point se trouve dans sa cellule. Les techniques du point peuvent donc être appliquées. L'avantage principal du positionnement par WiFi est qu'il y a déjà beaucoup d'ap dans les zones habitées, des sociétés comme Belgacom ou Telenet déploient des hotspots 3 dans les gares, les restaurants ou les stations-service et il possible de voir les AP de particuliers dans les rues. Si en plus, on a le droit d'utiliser l'access Point, on peut communiquer avec un réseau et donc utiliser des services géolocalisés. La précision par identication des Access Point connaît cependant les même limitations que le Cell ID (précision moins bonne que le GPS en ville, précision mauvaise en campagne). Il faut noter que cette technique ne nécessite pas spécialement d'accéder à un Ac- 2 L'Access Point est l'appareil qui relie les appareils WiFi pour former un réseau sans-l qui peut ensuite être connecté à d'autres réseaux comme Internet. 3 Un hotspot est la zone couverte par un Access Point. 14

23 CHAPITRE 2. SERVICES GÉOLOCALISÉS cess Point, il sut de pouvoir le reconnaître et de retrouver l'identité unique de l'ap dans une base de données Positionnement sur Internet Une autre technique utilisée depuis longtemps pour obtenir un positionnement approximatif consiste à donner une position aux routeurs Internet. Lorsqu'un paquet IP se déplace entre les routeurs constituant Internet, on peut supposer que le premier routeur par lequel il passe est géographiquement proche de l'utilisateur. L'IETF a proposé en 1996 [9] dans le RFC1876 d'ajouter des informations de géolocalisation dans les données transportées par les mises à jour DNS. A partir de telles informations, il est possible d'identier le pays ou la ville pour les adresses IP sur Internet. Une autre technique consiste à demander à des visiteurs de sites Web de donner leur localisation et, à partir de là, d'analyser les adresse IP et essayer de faire un lien entre les groupes d'adresse IP et les pays ou les villes. C'est l'approche choisie par le logiciel GeoIP édité par la société MaxWind 4 qui croise diérentes bases de données. Les résultats ainsi obtenus sont assez précis et peuvent aller jusqu'à la commune de l'utilisateur. Une démonstration est disponible sur la page Un certain nombre de programmes utilisent de telles informations an de faire des représentations géographiques du déplacement de paquets sur Internet. Un de ces programmes est Xtraceroute sur Linux qui permet de visualiser sur un globe en 3D les routeurs par lesquels passe une commande traceroute 5. Windows Local Live 6, le service de cartes de Microsoft permet également de situer un utilisateur à partir de son adresse IP lorsqu'on clique sur Locate Me. Les outils d'analyse de trac sur les sites Web utilisent également ce genre d'informations. Finalement, l'ipv6 intègre une gestion de la mobilité en cours de nalisation. Le lecteur intéressé peut se référer à [6]. 2.7 Etat de l'art Dans cette section nous n'allons pas lister l'ensemble des acteurs du marché. En eet, les services géolocalisés et les systèmes de plateforme existant pour développer des services géolocalisés sont nombreux et variés, chacun pour des applications limitées. Dans le cas de produits similaires, nous avons choisi de privilégier des solutions disponibles en Belgique traceroute est un outil d'analyse de réseau qui sert à déterminer le chemin pris par un paquet IP

24 CHAPITRE 2. SERVICES GÉOLOCALISÉS Localisation par GSM - GeoMobile.be GeoMobile.be est un service édité par la PME belge NETiKA Internet & Mobile Solutions [20]. Cette solution se base sur le positionnement des GSM à l'aide des Cell ID des réseaux Proximus et Mobistar. GeoMobile est un service destiné uniquement aux entreprises, typiquement pour la gestion de ottes de véhicules ou de personnel mobile. Pour éviter les problèmes d'atteinte de la vie privée exposés au point 2.4.3, le service exige l'autorisation de l'abonné pour que sa position soit consultable. Ce n'est pas un service de LBS qui permet aux utilisateurs des GSM d'obtenir des services mais à l'employeur de gérer ses employés mobiles. Les principales fonctionnalités de GeoMobile sont de localiser et visualiser la position actuelle et l'historique d'un GSM, calculer des distances, trouver les GSM les plus proches d'un lieu donné et envoyer et recevoir des SMS depuis l'application. Le service est relativement cher, entre autre car, comme dans toute application passant par les opérateurs GSM, ceux-ci en protent pour prendre une commition non négligeable. Le logiciel coûte 250 euros, auxquels il faut ajouter 10 euros mensuel par numéro de GSM que l'on souhaite localiser et ensuite environ 30 centimes d'euros par localisation. Un de leurs clients sont les Taxis Verts à Bruxelles Plateformes géolocalisées - RedSpider LOBOS LOBOS est un logiciel développé par la société Ionic Software basée à Liège et en Virginie (USA). Il permet de développer des services géolocalisés en Java en se basant exclusivement sur les standards de l'ogc (Open Gis Consortium, décrit plus en détails au point 3.2.3), le Java et l'xml. Le logiciel inclut un moteur de recherche de lieux, la génération de cartes, le calcul d'itinéraire ainsi qu'une API 7 pour développer des services géolocalisés. Pour développer des clients capables de communiquer avec Lobos, on peut utiliser le logiciel RedSpider StudioLS. Ionic Software arme développer avec LOBOS, l'unique solution respectant totalement l'ols (OpenGIS Location Service) de l'ogc. Il faut noter qu'ionic Software fait partie des onze sociétés ayant rédigé les spécications de l'olg et qu'une partie des autres participants sont des fournisseurs de données ou des opérateurs de téléphonie mobile. Il existe également d'autres sociétés qui développent des services similaires. On peut citer entre autre le français Webraska, également participant à la rédaction de l'ols, qui arme avoir été déployé cinq fois plus que son concurrent le plus proche (qu'il ne cite pas). Il a installé ses solutions et 7 Application Program Interface, c'est à dire un ensemble de méthodes réutilisables an de faciliter le développement de nouveaux logiciels 16

25 CHAPITRE 2. SERVICES GÉOLOCALISÉS des services (itinéraires, recherche des restaurants avoisinants,...) sur les smartphones 8 Orange et Vodaphone. La grande diérence entre Ionic Software et Webraska est qu'ionic se concentre plutôt sur le marché des entreprises, la gestion de leurs données spatiales et l'interaction entre diérents logiciels tandis que Webraska vise plus les utilisateurs naux en déployant des services en partenariat avec les opérateurs de téléphonie mobile Localisation par WiFi - HereCast.com HereCast est une application de services géolocalisés basée sur les routeurs WiFi les plus proches. Chaque routeur WiFi émet un numéro d'identication unique. Comme les Access Point (AP) sont généralement xes, le logiciel est capable de donner la position approximative de l'utilisateur. La base de données des AP est mise à jour par les utilisateurs du logiciel. La position n'est pas donnée sous forme de coordonnées géographique mais sous forme d'une information textuelle comme par exemple Grand-Place de Bruxelles. L'avantage est que ce type de données est plus adapté à une utilisation humaine mais il ne permet pas d'avoir des calculs de distance entre les utilisateurs. Au mieux, ce logiciel est capable de dire qu'un autre utilisateur se trouve dans le même hotspot mais sans pouvoir donner ensuite d'instructions d'itinéraire. C'est assez problématique dans des larges zones couvertes par un seul hotspot mais également s'il y a de nombreux hotspot qui couvrent de très petite zones car deux utilisateurs très proches mais voyant deux AP diérents ne sauront pas se retrouver Localisation par IP - Windows Local Live Windows Local Live est un service de cartes sur Internet développé par Microsoft. Il possède un bouton Locate Me qui peut essayer de trouver la position d'un utilisateur à partir d'une liste d'access Point (comme Here- Cast) ou bien à partir de son adresse IP (avec des bases similaires à ce que développe MaxWind). La carte est alors zoomée autour de la position de l'utilisateur. Le site étant en version beta, la plupart des fonctionnalités ne sont pas encore au point : Locate Me à partir de l'adresse IP ne donne que des résultats approximatifs ou parfois incorrects pour l'europe Qui seront les futurs acteurs? Il est intéressant de se poser la question des futurs grands noms des services géolocalisés. Il y a plusieurs moyens de devenir un acteur important 8 Un smartphone est un téléphone mobile possédant des capacités supplémentaires permettant d'avoir tous types de logiciels : calendrier, client , navigateur Web, jeux, lecteur MP3 et de vidéos,... 17

26 CHAPITRE 2. SERVICES GÉOLOCALISÉS dans ce domaine, que ce soit en ayant une position forte sur Internet, dans la téléphonie mobile ou bien en possédant des cartes géolocalisées détaillées qui sont les données incontournables pour développer des services géolocalisés. Fournisseurs de cartes : Navteq, TeleAtlas,... Il existe seulement quelques grandes sociétés qui possèdent des cartes détaillées des grandes villes du monde. Ces données sont vitales an de fournir les cartes aux utilisateurs mais coûtent très cher : TeleAtlas a investi 600 millions d'euros en 20 ans [5]. Cependant, aucune de ces sociétés ne donne l'impression de vouloir jouer un autre rôle que celui de fournisseur de données. Cela se comprend car la collecte et l'exploitation de ces données sont deux domaines sans réelle synergie et ils sont sûrs de proter du boom des services géolocalisés sans devoir prendre le risque de développer les services eux-mêmes. Equipementiers GSM : Nokia, Siemens,... Les équipementiers de la téléphonie mobile, que ce soit les constructeurs de terminaux ou les sociétés qui construisent les infrastructures, peuvent en installant leurs systèmes de services géolocalisés devenir des acteurs de premier plan. Les Opérateurs GSM. Beaucoup d'opérateurs de téléphonie mobile comme Orange, Vodaphone, NTT Docomo,...possèdent déjà quelques services géolocalisés. Avec l'arrivée de l'umts, il faudra fournir toujours plus de services et les services géolocalisés font partie des services en cours de développement. Yahoo!, Google, Microsoft. Les trois grandes sociétés de l'internet ont déjà compris l'intérêt stratégique de la géolocalisation. Chacune a son service de cartes sur Internet et tente d'y intégrer le calcul d'itinéraire et la recherche de commerçants dans les environs de l'utilisateur. Ils ne semblent cependant pas s'intéresser pour l'instant au développement d'applications du type Friend Finder mais il semblerait plus logique pour eux, d'intégrer ce genre de services à l'intérieur de leurs clients de messagerie instantanée respectifs (Yahoo! Messenger, Google Talk et Microsoft Live Messenger). Les PME. Il reste encore de la place pour des sociétés comme Ionic Software ou d'autres qui arriveront à développer des plateformes et des services de qualité. La complexité et le coût du développement va probablement permettre l'existence de sociétés spécialisées dans ce domaine en tant que sous-traitant de grands groupes ayant un accès direct aux utilisateurs. 2.8 Conclusion Dans ce chapitre, nous avons exposé l'architecture générale composée du terminal, de l'élément de localisation, de la plateforme, des services et des 18

27 CHAPITRE 2. SERVICES GÉOLOCALISÉS bases de données. Nous avons montré que les services géolocalisés peuvent être utilisés dans des contextes diérents, que ce soit par le grand public ou dans le cadre d'une entreprise. Nous avons également abordé les diérents types et catégories de services géolocalisés existants et imaginables ainsi que quelques grands risques et abus qui leur sont liés. Ensuite, les techniques de positionnement existantes ont été présentées. Ces diérentes technologies peuvent être utilisées de manière combinée an d'obtenir une meilleure précision globale. Les deux moyens de positionnement actuellement les plus utilisés sont le GPS et Cell ID. Le premier car la qualité des résultats est bonne et son usage est répandu dans les ordinateurs de bord des voitures. Le second a l'avantage de se baser sur des informations déjà stockées dans les réseaux cellulaires existants et sur le fait que presque tout le monde possède un téléphone mobile. Le lancement de Galileo, l'arrivée de l'umts (qui possède des cellules plus petites et donc un positionnement par Cell ID plus précis) et la multiplication des Access Point WiFi devraient permettre d'atteindre la couverture, la précision et le faible coût nécessaires à une adoption par le grand public. Dans l'état de l'art, nous avons vu qu'il existe déjà de nombreuses initiatives de services géolocalisés mais limités à un certain type de clientèle, se basant sur une seule technique de localisation et permettant rarement l'intéraction entre les utilisateurs. 19

28 Chapitre 3 Les données spatiales 3.1 Introduction Au l du temps, de nombreuses initiatives ont été lancées an de représenter les données géographiques, généralement dans l'optique d'une utilisation spécique (cartographie géologique, cartographique maritime,...) chacune avec des particularités spéciques à un domaine donné. Cette représentation est divisée en la modélisation du globe terrestre et la méthode de projection de ce globe sur un plan. La Terre n'est pas ronde, elle est en fait plus proche d'une ellipse que d'une sphère. Du côté de la projection, l'impossibilité de conserver toutes les propriétés géométriques (comme les aires, les distances, les azimuts,...) lors de la projection de la surface du globe sur un plan a engendré diérentes méthodes de projection conservant chacune une ou plusieurs de ces propriétés. Le choix des propriétés importantes pour la projection dépend de l'application utilisée par la carte. plusieurs axes de coordonnées ont été construits au l du temps, certains géocentriques mais d'autres ont été développés par des pays diérents an de mieux optimiser l'espace occupé par la représentation de leur pays sur une carte plane. Ces projections ne sont pas capables de conserver toutes les propriétés que l'on retrouve sur la surface du globe (comme les distances, les aires, les azimuts,...) mais se concentrent sur l'un ou l'autre aspect en fonction de leur domaine d'application. Les applications informatiques communiquent de plus en plus entre elles, il a donc été nécessaire de développer une représentation commune des données spatiales pour les diérentes applications informatiques utilisant des représentations spatiales. Ce travail est eectué par l'open Geospatial Consortium (OGC) qui dénit également un ensemble de recommandations pour tout ce qui gravite autour des données spatiales. Ce chapitre aborde nalement diérents moteurs de bases de données relationnelles qui supportent les données spatiales, leurs points forts et leurs 20

29 CHAPITRE 3. LES DONNÉES SPATIALES limitations respectives. 3.2 Représentation d'une position Géodésie La géodésie est la discipline qui a pour but de décrire la forme et les dimensions du globe terrestre. La forme exacte de la Terre est dépendante de nombreux facteurs comme le mouvement des plaques tectoniques, sa rotation autour de son axe, le champ gravitationnel,...ces facteurs impliquent notamment que le niveau de la mer n'est pas constant aux diérents points du globe. Fig. 3.1 Géoïde, sphère et ellipsoïde La représentation de la surface de la Terre à partir du niveau de la mer s'appelle un géoïde. Il correspond à une représentation de la surface de Terre si l'on prolongeait le niveau de la mer sur les continents sans tenir compte de la pression de l'air et des courants,...le géoïde est donc une surface équipotentielle théorique correspondant à la mer calme, après avoir retiré l'eet des continents et des montagnes. Le géoïde ainsi obtenu n'est pas symétrique du fait de la répartition non uniforme des masses (les régions froides concentrant la masse). Les connaissances sur la surface de la Terre et ses dimensions évoluent avec le temps, principalement grâce à la multiplication de satellites d'observations. Par conséquent, le géoïde est devenu de plus en plus précis au fur et à mesure de la multiplication de ces connaissances. Il faut également tenir compte de diérents facteurs comme l'érosion, la dérive des continents,...qui fait que le modèle, aussi précis soit-il, doit être corrigé dans le temps. 21

30 CHAPITRE 3. LES DONNÉES SPATIALES Ce géoïde étant irrégulier, on utilise un ellipsoïde de révolution de même volume pour les modèles mathématiques. Le modèle du géoïde irrégulier est trop complexe pour être utilisé directement en cartographie et sert principalement à contrôler le modèle ellipsoïdal. Cet ellipsoïde est parfois aussi appelé Datum. A ce Datum correspond également un système d'axe, une position et une orientation de l'ellipsoïde dans l'espace. WGS 84 Le modèle retenu actuellement pour une représentation totale du globe est le WGS 84 pour World Geodesic System 1984, qui a été revu en 2004 et dont la validité court jusqu'en Ce modèle a remplacé le WGS 72 et a proté d'avancées technologiques importantes dans le domaine des mesures par satellites. C'est un modèle géocentrique, c'est à dire que le centre de l'ellipsoïde correspond (environ) au centre de masse de la Terre. Les valeurs des semi-axes sont de et mètres. C'est ce modèle du globe qui est utilisé dans le GPS. Autres modèles Il existe encore de nombreux modèles, principalement utilisés pour des représentations de zones restreintes et des applications nécessitant une précision locale meilleure que celle fournie par le WGS 84. C'est le cas par exemple du RGF 93 utilisé pour des applications précises en France ; le modèle pour les applications courantes restant le WGS 84 [3]. D'autres modèles sont encore fort utilisés pour des raisons historiques comme le ED 50 (European Datum 50) dans les cartes marines européennes. Fig. 3.2 Datums locaux 22

31 CHAPITRE 3. LES DONNÉES SPATIALES Projections Une fois que l'on possède un modèle du globe terrestre, pour la plupart des applications, il est nécessaire de le projeter sur un plan à deux dimensions an de le visualiser sur une carte ou sur un écran d'ordinateur. Ici aussi, il existe de nombreuses techniques qui ont chacune pour but de respecter certaines propriétés présentes à la surface de la Terre. On parle de projections conformes si les angles sont préservés, de projections équivalentes si elles conservent les surfaces, de projections équidistantes si elles conservent les distances sur les méridiens. Si aucune de ces propriétés est respectée, on parle de projections aphylactiques. Il faut souligner qu'une projection est indépendante d'un modèle géodésique de la Terre. Chaque projection peut être utilisée en combinaison avec n'importe quel modèle de la Terre et inversément. Projections cylindriques Les projections cylindriques consistent à projeter le globe sur un cylindre le contenant. Elles sont principalement utilisées pour représenter le monde dans sa globalité ou des régions le long d'un parallèle, un méridien ou une ligne oblique. Fig. 3.3 Projection cylindrique régulière, transverse et oblique [19] Les projections les plus connues sont la projection plan carrés où les méridiens et les parallèles restent parallèles et forment des carrés entre eux et la projection conforme de Mercator qui possède de grande distortions des aires aux alentours des pôles. Dans la projection de Mercator, le Groenland semble avoir une taille similaire à celle de l'amérique du Sud alors qu'en réalité, sa surface n'est qu'un septième de celle de l'amérique du Sud. La projection la plus utilisée avec le modèle WGS 84 est la projection UTM pour Universal Transversal Mercator. La surface de la Terre est divisée en 60 fuseaux de 6 degrés, formant ainsi 120 zones (en séparant le Nord et le Sud). La Belgique est à cheval sur la zone UTM 30 Nord (de 0 à 6 degrés Est) et UTM 31 Nord (6 à 12 degrés Est) (gure 3.4). Chaque zone possède ensuite un point de référence virtuel à partir duquel les points de la zone sont référencés. Pour éviter d'utiliser des chires négatifs, 23

32 CHAPITRE 3. LES DONNÉES SPATIALES Fig. 3.4 Zones UTM de la France et de la Belgique le point de référence est situé à 500 km à l'ouest du méridien central. Pour les zones de l'hémisphère Sud, le point de référence est situé à 500 km à l'ouest et à km au Sud de l'équateur. L'unité de base de la projection est le mètre. Cette projection permet de facilement faire des calculs assez précis de distances à l'intérieur d'une zone. Cependant, le calcul de la distance entre des points de zones diérentes n'est pas aussi direct. C'est pourquoi, sur des cartes représentant une zone à cheval entre deux zones, les deux systèmes de coordonnées sont représentés. Projections coniques Dans les zones tempérées principalement étendues d'est en Ouest (cartes des Etats-Unis, de l'europe ou de l'australie), les projections coniques sont préférables au projections cylindriques [19]. La projection la plus utilisée est la projection de Lambert au centre de la gure 3.5. Autres projections Il existe encore diérentes projections comme les projections pseudocylindriques qui ont, comme les projections cylindriques, les lignes de latitudes parallèles et les lignes de longitude espacées de manière égale. Cependant, uniquement le méridien central est droit, les autres sont courbés. Cer- 24

33 CHAPITRE 3. LES DONNÉES SPATIALES Fig. 3.5 Projections coniques [19] Fig. 3.6 Projections pseudo-cylindrique interrompue [19] taines projections sont interrompues pour diminuer les problèmes de courbure des méridiens (gure 3.6) [19]. Les projections azimuthales sont des projections sur un plan tangent au globe. Les projections de l'entièreté du monde utilisent souvent la projection azimuthale de Winkel. Il existe encore de nombreuses projections comme les projections sur des tores visibles sur la gure Calcul de distance Le calcul de grandes distances dans le modèle ellipsoïdal WGS 84 se fait généralement avec la formule de Thaddeus Vincenty [23]. Cette formule a été récemment validée par des chercheurs australiens [21] qui ont montré qu'elle était précise à 0,115 mm - ce qui est plutôt précis. Cette formule s'adapte à 25

34 CHAPITRE 3. LES DONNÉES SPATIALES Fig. 3.7 Projection azimuthale et de Winkel [19] Fig. 3.8 Projection Armadillo sur un tore [19] la plupart des modèles géodésiques de la Terre en modiant les paramètres de base. Le détail de l'algorithme se trouve dans l'annexe B, page Open Geospatial Consortium Pour que les applications informatiques puissent communiquer plus facilement, il a été nécessaire de créer un standard informatique pour les représentation de données géographiques. C'est le travail auquel s'attèle l'ogc (Open Geospatial Consortium, autrefois appelé OpenGIS Consortium) qui regroupe des grands noms de l'industrie (Oracle, AutoDesk, Google, NTT,...), des agences gouvernementales (ESA, NASA, USGS, OTAN,...) et des universités (EPFL, MIT, Harvard,...). Ce consortium érige un certain nombre de règles dans des domaines divers liés à la représentation géographique, allant des types de données jusqu'au moyen de communiquer entre diérents services de cartographie Données spatiales : OGC L'OGC a déni des recommandations pour la représentation de données spatiales. A chaque classe (qui hérite de la classe abstraite Geometry) correspond un système de référence spatial (ex : WGS 84, UTM 12,...) composé typiquement des informations caractérisant l'ellipsoïde, son système de coordonnées, l'unité utilisée ainsi que les facteurs particuliers à la projection si le système de référence est une projection. Le système de référence spatial est généralement abrévié par SRID (Spatial Reference IDentication). 26

35 CHAPITRE 3. LES DONNÉES SPATIALES Il y a quatre grands types de données dénis par l'ogc : Point : le point représente un simple point. Il peut être à deux ou trois dimensions. Fig. 3.9 LineString simple et ouverte ; LineString simple et fermée (LinearRing) Fig LineString non simple et ouverte ; LineString non simple et fermée Curve : la classe abstraite Curve représente un ensemble de points. En pratique, la seule classe qui en hérite est la classe LineString représentant une ligne brisée. Chaque paire de points consécutifs dénissant LineString déni donc un segment de droite de la ligne brisée. La classe Line qui hérite de LineString est un segment de droite, déterminé par les deux paires de coordonnées des points à ses extrémités. 27

36 CHAPITRE 3. LES DONNÉES SPATIALES La classe LinearRing (gure 3.9b) héritant de LineString est un LineString qui est fermé et simple. Par fermé, on entend le fait que le premier point du LinearRing est confondu avec son dernier point et par simple, on entend que l'objet géométrique n'a pas d'intersection avec lui-même (gures 3.9 et 3.10). Surface : la classe abstraite Surface représente un objet à deux dimensions composé d'un bord extérieur et de un ou plusieurs bords intérieurs. Pour créer des surfaces à trois dimensions, il faut assembler des surfaces à deux dimensions. GeometryCollection : Chacun de ces trois types de données peuvent être assemblés et former des collections (GeometryCollection). Il est intéressant de remarquer qu'il n'y a pas de moyen simple de représenter un cercle. OpenGIS ne dénissant que des segments de droite ou des lignes brisées, le seul moyen de représenter un cercle est en fait de construire un polygone avec un nombre élevé de côtés. Cette limitation peut parfois être dérangeante mais peut être généralement contournée. Fig Schéma UML des données spatiales OGC Les attributs et les méthodes pour ces diérentes classes ont également été déterminées dans [8]. Les méthodes contenues dans la classe Geometry peuvent être regroupées de la manière suivante : Les méthodes basiques (Dimension(), GeometryType(), SRID(),...) qui permettent d'obtenir des informations générales sur l'objet comme sa dimension, son type, son système de référence, ses limites ou encore le rectangle minimal qui contient tout l'objet. L'export de données en format binaire ou textuel. 28

37 CHAPITRE 3. LES DONNÉES SPATIALES Les méthodes de relations avec d'autre objets spatiaux : Equals(), Intersects(), Contains(), Distance(),... Chaque classe qui hérite de Geometry possède également des méthodes relativement triviales : récupération des coordonnées d'un Point, la longueur et les extrémités d'un LineString, la centroïde d'une Surface,... Les données peuvent être représentées de deux façons, d'une manière textuelle (WKT ou Well Know Text), facilement compréhensible pour un être humain et en binaire (WKB ou Well Know Binary) plus compact et plus utile pour la sauvegarde dans des chiers ou le transfert entre applications. Par exemple, l'écriture d'un point situé à x=100 et y=200 en WKT est POINT( ) Une collection d'objets géométriques composée du même point ainsi que d'une ligne déterminée par trois point s'écrit : GEOMETRYCOLLECTION (POINT( ), LINESTRING(10 30, 40 25, 70 90)) Il existe également du WKT pour dénir les systèmes de références spatiales (SRID) (gure 3.12). Le détail de la grammaire utilisée est reprise dans l'annexe A. PROJCS["WGS 84 / UTM zone 30N", GEOGCS["WGS 84", DATUM["WGS\_1984", SPHEROID["WGS 84", , , AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]], UNIT["degree", , AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4326"]], PROJECTION["Transverse\_Mercator"], PARAMETER["latitude\_of\_origin",0], PARAMETER["central\_meridian",-3], PARAMETER["scale\_factor",0.9996], PARAMETER["false\_easting",500000], PARAMETER["false\_northing",0], UNIT["metre",1,AUTHORITY["EPSG","9001"]], AUTHORITY["EPSG","32630"]] Fig Représentation WKT de la projection UTM 30 Nord avec un géoïde WGS 84 29

38 CHAPITRE 3. LES DONNÉES SPATIALES La structure du WKT pour les SRID est susamment complète que pour facilement intégrer des projections exotiques ou les évolutions futures du WGS 84. Cependant, la dénition d'un système de référence étant assez volumineux (une bonne dizaine de lignes au minimum comme sur la gure 3.12), la plupart des implémentations de l'opengis ont précodé les systèmes de référence les plus courants dans des variables statiques. C'est généralement la représentation textuelle qui sera utilisée pour la manipulation manuelle des bases de données. Nous n'entrerons pas dans le détail de la représentation binaire, le lecteur intéressé peut se référer à [7]. Toute implémentation de l'opengis se doit d'inclure ces diérents types de données ainsi que les méthodes et les attributs dénis par le consortium Autres recommandations de l'ogc Nous allons rapidement passer en revue certaines des recommandations de l'ogc. Nous n'allons pas détailler la plupart de celles-ci principalement car, bien que dictée par un consortium reconnu, elles ne sont pas des standards de fait. Pour transférer les données spatiales, l'ogc recommande d'utiliser le GML, une grammaire XML pour le transport et le stockage des données spatiales. Dans sa troisième mouture, le GML supporte des données 3D et des propriétés temporelles. Le GML ne contient que les données spatiales et aucune information quant à leur représentation. Ce travail est laissé au SVG (images vectorielles en XML), au X3D (images 3D en XML) ou n'importe quel autre programme de visualisation capable de lire des données GML. Les avantages principaux du GML par rapport à ses concurrents comme le ShapeFile (shp) sont les avantages du XML [13] : il est textuel et donc facilement lisible et éditable par tous, il permet de proter de la vérication de l'intégrité des données intégré à XML (GML DTD). De par l'universalité du XML, il peut être mélangé avec d'autres langages XML. Finalement, le XML peut facilement être transformé au moyen de l'xslt. C'est utile pour transformer le GML en SVG mais cela ouvre aussi les possibilités de bases de données GML. Cependant, le GML n'est pas universellement adopté. Google, qui fait pourtant partie de l'ogc, utilise pour Google Earth son propre format le KML (Keyhole Markup Language), basé en partie sur le GML mais qui intègre en plus des informations concernant l'achage des données (le style). Ce format gagne en popularité, en partie car il est plus facile à utiliser que le GML qui est plus complet mais aussi plus complexe. L'OGC dénit également un ensemble de protocoles de communication (WMS : Web Map Service, Web Feature Service : WFS et Web Coverage Service : WCS) entre serveurs de données. Cela permet de découvrir les possibilités d'un serveur de données compatible OGC. Ainsi, les informations renvoyées contiennent la zone de couverture des cartes ou encore le type de 30

39 CHAPITRE 3. LES DONNÉES SPATIALES formats d'images supportés par le serveur (principalement aux formats GIF, PNG et SVG qui supportent la transparence et sont donc superposables). En utilisant diérents serveurs, les données peuvent être mélangées avant d'être utilisées dans les applications. Le transfert de données se fait soit sous la forme d'images soit en GML si l'on souhaite connaître les données spatiales an de les manipuler. 3.4 Les bases de données spatiales Les bases de données spatiales ont été développées dans les années 70 an de stocker les données cartographiques. On appelle un GIS (Geographic Information System) une base de données qui permet de stocker et de consulter des informations ayant un ou plusieurs attributs spatiaux tels que la taille, la forme ou la position. Typiquement, toute application utilisant des adresses ou des cartes peuvent tirer avantage de ce type de bases de données. An de manipuler ce type de données, un certain nombre de primitives ont été dénies comme les points, les arcs, les polygones (vecteurs) ou des maillages (raster). On peut ensuite ajouter un certain nombre de caractéristiques à ces données. Il est également possible d'introduire une notion de temps et les bases de données de ce type sont alors qualiées de spatiotemporelles. Les GIS sont capables de manipuler plusieurs types de données, dans les bases de données populaires, ces types de données suivent les recommandations de l'opengis [2]. Les données attributaires correspondent aux attributs d'un objet géographique (nom d'une route ou d'un bâtiment, type de forêt ou de culture d'un champs,...) et permettent de les qualier. Les objets géographiques sont organisés en couches relatives à un domaine particulier (les routes, les rivières,...). De cette manière, les cartes sont composées d'un ensemble de ces couches. Préciser des données supplémentaires ou retirer des données inintéressantes pour une application se fait simplement en supprimant ou en rajoutant une couche de données. Les métadonnées sont le regroupement de données spatiales et de données supplémentaires an de décrire la donnée, sa qualité (date de saisie, précision,...) ou des informations de gestion interne (responsable, date d'acquisition, dernière mise à jour,...) Structure OpenGIS Comme précisé dans le point sur l'ogc à la page 28, les bases de données suivant les recommandations de l'ogc implémentent un certain nombre de méthodes sur les classes mais également des méthodes plus spéciques aux bases de données [17]. 31

40 CHAPITRE 3. LES DONNÉES SPATIALES Fig Structure des tables SQL OGC Le document [7] décrit la gestion des données spatiales et la structure des tables à utiliser dans le moteur de la base de données. Les tables de données sont les tables classiques d'une base de données mais qui peuvent contenir, parmi leurs attributs, des attributs de type spatial. La table GEOMETRY_TABLE contient les objets spatiaux qui peuvent être décrits sous une forme textuelle (normalisée) ou binaire. La table GEOMETRY_COLUMNS décrit les tables de données existantes et les propriétés spatiales qui y correspondent. La table SPATIAL_REF_SYS décrit les systèmes de coordonnées et les transformations possibles des données spatiales. Chaque table est susceptible d'accueillir une colonne spatiale. Il n'y a aucune obligation quant à la position de cette colonne à l'intérieur de la table. La colonne est référencée au moyen d'un numéro (GID = Geographical IDentication). Chaque colonne est également reprise dans la table GEOMETRY_COLUMNS, l'intérêt est de pouvoir facilement retrouver les attributs spatiaux de la base de données et d'y attacher des informations supplémentaires (comme les dimensions, le type de l'attribut, son système de référence,...). Les données spatiales sont réellement stockées dans la table GEOME- TRY_TABLE (voir tableau 3.1, page 34). A chaque objet correspond une 32

41 CHAPITRE 3. LES DONNÉES SPATIALES clé (GID) et consiste en un ou plusieurs éléments primitifs ordonnancés par un numéro de séquence (ESEQ). Un élément primitif est inséré dans la table au moyen d'une ou plusieurs lignes, identiées par un type (ETYPE : 1 pour Point, 2 pour LineString, 3 pour Polygon [11]), un numéro de séquence (SEQ) et un ensemble de coordonnées. Le numéro de séquence permet de connaître l'ordre des éléments composant l'objet. Ce nombre de coordonnées est une valeur préxée déterminée par le gestionnaire de la base de données. Si l'élément primitif est composé de moins de coordonnées que de colonnes prévues à cet eet, les coordonnées seront remplies par la valeur null. Si l'élément a besoin de plus de coordonnées, il est inséré au moyen de diérentes lignes. Dans l'exemple du tableau 3.1, nous avons un objet du type MultiPolygon (GID = 1) composé de deux polygones (ETYPE = 3) : un carré et un hexagone. La table GEOMETRY_TABLE est capable de contenir cinq paires de coordonnées par ligne. Les polygones sont exprimés au moyen de leur contour fermé, le premier et le dernier point de ce contour devant correspondre. Le carré (ESEQ 1) a ainsi besoin de cinq coordonnées (0,0), (0, 50), (50, 50), (0, 50) et (0, 0) et peut être noté sur une seule ligne. Cette ligne contient un numéro interne à la séquence (SEQ), le numéro 1. L'hexagone (ESEQ 2) a besoin de 7 coordonnées pour exprimer son contour. C'est plus que le nombre de coordonnées pouvant être exprimés sur une seule ligne. Le contour de l'hexagone sera par conséquent divisé en deux lignes. La première ligne (SEQ 1) contient les cinq premières coordonnées : (70, 0), (120, 0), (120, 50), (95, 50) et (95, 75). La deuxième ligne (SEQ 2) doit avoir, pour première coordonnée, la dernière coordonnée de la ligne qui la précède. Par conséquent, les coordonnées inscrites sont (95, 75), (70, 75) et (70, 0). Comme il n'y a plus de coordonnées restantes, on remplit le reste de la ligne par la valeur null. Pour résumer, chaque objet géométrique est exprimé au moyen d'un numéro (GID) et des diérents éléments qui le composent dont le type est donné par ETYPE et l'ordre par ESEQ. Chacun de ses éléments est exprimé sur une ou plusieurs lignes en fonction du nombre de colonnes présentes dans la table GEOMETRY_TABLE. Pour conserver l'ordre de ces lignes, un numéro de séquence (SEQ) est utilisé. La répétition des coordonnées lorsque l'objet est exprimé sur plusieurs lignes permet d'avoir une vérication supplémentaire La table SPATIAL_REF_SYS contient les informations relatives au système de référence spatial : un numéro d'identication (SRID), le nom de l'autorité qui dénit ce système de référence (AUTH_NAME), le numéro interne à cette autorité (AUTH_SRID) et une représentation en WKT du système de référence (SRTEXT) (voir l'annexe A.1). An de garantir que cette structure soit respectée, l'ogc a déni deux méthodes sur les tables pour ajouter et supprimer les colonnes spatiales [7] : 33

42 CHAPITRE 3. LES DONNÉES SPATIALES GID ETYPE ESEQ SEQ X0 Y0 X1 Y1 X2 Y2 X3 Y3 X4 Y null null null null Tab. 3.1 GEOMETRY_TABLE contenant un objet composé de deux polygones AddGeometryColumn() La méthode AddGeometryColumn(F_TABLE- _CATALOG, F_TABLE_SCHEMA, F_TABLE_NAME, G_COLUMN- _NAME, SRID)] s'assure que le numéro SRID existe bien dans la table SPATIAL_REF_SYS, ajoute la nouvelle colonne dans la table G_COLUMNS, modie la table au moyen de la fonction ALTER_TABLE de SQL et enn, ajoute les contraintes d'intégrité à la base pour s'assurer que les ajouts à la base respecteront bien le SRID. DropGeometryColumn() La méthode DropGeometryColumn(F_TABLE- _CATALOG, F_TABLE_SCHEMA, F_TABLE_NAME, G_COLUMN- _NAME)] va enlever la contrainte d'intégrité spatiale, enlever l'entrée dans G_COLUMNS et nalement enlever la colonne dans la table en question (F_TABLE_NAME). Nous allons vous présenter quelques moteurs de base de données spatiales 34

43 CHAPITRE 3. LES DONNÉES SPATIALES existants MySQL MySQL est un moteur de base de données Open Source sous licence GPL 1 qui a connu une croissance fulgurante ces dernières années. Sa simplicité, son évolution rapide et ses performances honorables en ont rapidement fait un système de base de données très populaire avec une estimation à 6 millions d'installations. Depuis la version 4.1, MySQL est doté de fonctionalités spatiales simples qui seront complétées dans la 5 me mouture du serveur de bases de données. Le développement respecte les recommandations de l'opengis mais n'implémente pas encore la vue geometry_columns qui a pour but de reprendre l'ensemble de colonnes ayant des attributs géométriques ce qui permet de standardiser la recherche d'attributs graphiques par des applications tierces. Les limitations sont assez fortes : les objets géographiques ne peuvent pas avoir plus de deux dimensions et les fonctions préimplémentées sont peu nombreuses. Le calcul de distance ou la modication du système de coordonnées n'est pas possible avec MySQL PostgreSQL PostgreSQL (aussi connu sous le nom de Postgres) est un projet de base de données sous licence BSD 2 débuté en Le support spatial aux systèmes de base de données PostgreSQL est fait au moyen du projet Post- GIS [17], lui-même sous licence GPL Oracle 10g Oracle est la référence dans les bases de données spatiales avec son produit Oracle Spatial. La licence d'utilisation d'oracle est payante. Il existe cependant une version gratuite et redistribuable (mais pas libre) d'oracle appelée Oracle XE (mais qui ne supporte pas les données spatiales), une version d'oracle limité à un utilisateur (Oracle Light) et une licence gratuite d'utilisation d'oracle limitée à la conception de prototypes. Oracle inclut différents outils de manipulation des données spatiales ainsi que des méthodes supplémentaires à celles proposées par l'ogc. 1 GPL est la GNU General Public Licence, une licence de logiciel libre. Tout le monde a le droit de lire, modier, redistribuer et d'utiliser le programme tant que le programme et ses modications sont publiées sous la même licence. Du code GPL ne peut pas être utilisé dans des logiciels n'ayant pas la licence GPL. 2 La licence BSD est une licence de logiciel libre. Sa principale diérence avec la licence GPL est que le code peut être réutilisé par n'importe qui pour n'importe quelle utilisation, commerciale ou non à condition de reconnaître les auteurs du code originel. Mac OS X et la couche IP de Windows sont dérivés de logiciels sous licence BSD. 35

44 CHAPITRE 3. LES DONNÉES SPATIALES DB2 DB2 est la base de données développée par IBM. Le support des données spatiales se fait au moyen de l'extension DB2 Spatial Extender qui respecte aussi les standards édictés par l'ogc Middleware La société ESRI édite ArcSDE (Arc Spatial Database Extension). C'est une couche logicielle (middleware) qui s'intègre entre les bases de données et les applications ayant besoin de données spatiales. Son but est de fournir une interface unique aux programmes quel que soit le système de bases de données en dessous du middleware. ArcSDE supporte actuellement Microsoft SQL Server, Oracle Database, DB2 et Informix. Ce middleware optimise le stockage des données spatiales en fonction de la base de données sous-jacente et le développeur de l'application utilisant ArcSDE ne doit pas se soucier des spécicités de l'architecture de la base de données. MapInfo, un autre grand nom des sociétés GIS, développe SpatialWare qui est destiné à être utilisée avec Microsoft SQL Server et Informix d'ibm. 3.5 Création et manipulation de données spatiales Les données spatiales étant fortement visuelles, il est naturel de développer des logiciels graphiques an de créer, visualiser et manipuler ces données. Un de ces logiciels est ArcGIS, édité par ESRI. Cette suite logicielle est composée entre autres de ArcReader ArcReader est gratuit et permet de faire des requêtes et d'acher des cartes développées par d'autre produits de la suite Arc. ArcView Ce logiciel a pour but d'analyser, gérer et de visualiser des données géographiques. ArcEditor est un éditeur de cartes géographiques. 3.6 Conclusion Dans ce chapitre, nous avons exposé le modèle de la Terre WGS 84 utilisé dans le système GPS. Nous avons également touché un mot à propos des diérentes techniques de projection de ce modèle sur une surface plane. Le système principalement utilisé avec le WGS 84 est la projection UTM. Nous avons ensuite exposé les initiatives de l'open Geospatial Consortium, les types de données dénies par cet organisme an de standardiser les programmes utilisant des données spatiales parmi lesquels se trouvent les bases de données. 36

45 Chapitre 4 Choix préliminaires 4.1 Introduction Dans ce chapitre, nous allons exposer un scénario de service géolocalisé. A partir de celui-ci, nous allons identier les besoins de ce scénario et choisir les technologies utilisées dans le cadre de ce mémoire. Les besoins pour les clients, le serveur, les bases de données et le moyen de communication entre ces diérents éléments ont été pris en compte en établissant ces choix. Ensuite, il sera nécessaire de sélectionner des outils an de faciliter le développement de notre plateforme. Les diérentes alternatives, les choix que nous avons faits et leurs particularités sont détaillés dans ce chapitre. 4.2 Scénario de base L'idée de ce scénario est inspirée du projet ShoutSpace 1 développé depuis 2004 par trois chercheurs à l'ecole Polytechnique Fédérale de Lausanne (EPFL). ShoutSpace permet aux utilisateurs d'ordinateurs portables sur le campus de l'epfl de voir leur position et de laisser des messages aux autres utilisateurs. Une carte du campus permet de visualiser sa position et les messages (voir gure 4.1). Notre scénario est relativement similaire. Deux services ont été créés sur notre plateforme que nous avons nommé Silas. GeoMail est un système de messagerie géographique. Une personne peut écrire un message à un autre utilisateur à un lieu géographique donné. Lorsque le destinataire s'approche de la position en question, il reçoit le message sur son écran. L'autre service est FriendFinder qui permet à un utilisateur de la plateforme Silas de dénir ses connaissances et d'acher les positions géographiques de ses amis sur une carte. La génération de la carte est aidée par des services internes à Silas qui fournissent des outils aux services géolocalisés disponibles sur la plateforme

46 CHAPITRE 4. CHOIX PRÉLIMINAIRES Fig. 4.1 ShoutSpace Alice est équipée d'un PDA muni d'un récepteur GPS et est tranquillement chez elle. Bob, un ami d'alice, est aussi équipé d'une PDA avec récepteur GPS mais est distant de quelques kilomètres et se déplace en voiture. Aucun des deux ne connaît la position de l'autre. Tous les deux ont leur PDA éteint. Alice allume son PDA, s'identie sur le système Silas et lance Friend- Finder qui n'ache que sa position car aucun connaissance n'est connectée au service. Quelques minutes plus tard, Bob allume également son PDA et lance FriendFinder. Alice et Bob voient désormais une carte représentant la zone où ils se trouvent ainsi que leurs positions sur cette carte. Alice décide d'envoyer à Bob le message Si tu as le temps, passe chez moi, j'ai quelque chose à te montrer avec un rayon de validité d'un kilomètre. Bob continue à avancer, s'approche de la maison d'alice et, lorsqu'il est à moins d'un kilomètre de la maison d'alice, reçoit le message et décide de passer chez Alice. 4.3 Modélisation du scénario Pour modéliser le scénario, nous allons représenter les appareils mobiles au moyen de diérentes instances d'une même application client. Les clients 38

47 CHAPITRE 4. CHOIX PRÉLIMINAIRES communiquent, au travers d'un réseau, avec un serveur en utilisant le protocole TCP/IP. Pour la modélisation des communications réseau, nous allons utiliser la boucle locale de la couche TCP/IP. Dans les ordinateurs disposant d'une pile TCP/IP (c'est le cas de la plupart des machines connectées à un réseau), l'ip et le nom de domaine localhost pointent vers la machine locale. Cela permet de simuler le fonctionnement d'un réseau, en passant par les diérentes couches TCP/IP, avec la même machine faisant oce de serveur et de client. La transposition à une architecture où le serveur et le client seront placés sur des machines diérentes se fait simplement en changeant l'adresse IP du serveur dans le client (c'est à dire remplacer l'ip par l'ip de la machine ou bien son nom de domaine par le nom de la machine). D'une manière similaire, les bases de données sont placées sur la même machine, mais on s'adresse à eux en utilisant leur adresse IP ou le nom de domaine correspondant. Les requêtes émises par le client sont interceptées par un serveur qui, éventuellement en communiquant avec des bases de données, va répondre au client. 4.4 Spécications Pour construire une plateforme de services géolocalisés réaliste et modulable, il faut respecter un certain nombre de contraintes : Les bases de données supportées doivent être nombreuses. Le concepteur d'un service doit avoir le choix de la base de données qu'il souhaite utiliser. Grâce à la spécication JDBC, les programmes écrits en Java sont capables de communiquer avec la quasi totalité des bases de données existantes. La plateforme, côté client et côté serveur, doit reprendre un maximum du travail commun aux applications géolocalisées et fournir l'accès à une API géolocalisée. Ceci an de permettre au concepteur de services de se concentrer sur les spécicités de son service. La communication au travers du réseau doit être minimisée. Les modes d'accès sont multiples et certains sont plus lents ou coûteux que d'autres. Il est donc intéressant dans le cas des téléphones mobiles de diminuer au maximum le besoin en bande passante lors des communications entre le serveur et les clients. Les services géolocalisés pouvant être développés par des personnes différentes, ils peuvent être placés sur des serveurs diérents et utiliser chacun une base de données spécique. Les applications situées sur des serveurs diérents doivent pouvoir communiquer avec le serveur central pour y récupérer les données qui y sont stockées (position de l'utilisateur,...) 39

48 CHAPITRE 4. CHOIX PRÉLIMINAIRES La plateforme doit intégrer un système d'identication et d'authentication des utilisateurs an de fournir des services basés sur cette identité, de limiter certains services à certains utilisateurs ou de laisser la possibilité de facturer certains services. 4.5 Choix de l'architecture L'appareil de l'utilisateur étant généralement un appareil mobile (PDA, GSM,...), l'application client sera programmée en Java, qui a l'avantage d'être un langage de programmation populaire, portable et disponible sur la majorité des matériels cibles existants (du GSM à l'ordinateur portable). Le langage Java possède des libraires spéciques prenant en charge les communications réseau. De plus, diérentes librairies supplémentaires sont développées par les utilisateurs de Java. La librairie spatiale GeoTools spécique aux données spatiales et qui a été utilisée dans le cadre de ce mémoire est détaillée au point L'application serveur, de son côté, doit avoir les capacités de communiquer avec des bases de données et avec le client. L'application serveur d'une plateforme de services géolocalisés a pour but de faire tourner certaines applications (les services) qui répondent aux requêtes des utilisateurs. Il existe sur le marché des serveurs applicatifs qui incluent une partie de la complexité du développement de ces plateformes. De nombreuses technologies existent (.NET de Microsoft, J2EE de Sun Microsystems, Zope,...) mais les serveurs applicatifs les plus populaires sont ceux qui respectent les recommandations J2EE de Sun qui sont programmés en Java, ce qui a l'avantage de nous permettre d'utiliser le même langage de programmation pour le client et le serveur. Les spécicités des serveurs J2EE sont exposées au point La communication entre le serveur et les clients peut se faire de diérentes façons. Corba est une technologie de communication entre langages entièrement indépendante des langages utilisés. Il permet ainsi des échanges entre, par exemple, des programmes en C et en Java. Cependant, Corba n'est plus très populaire suite à l'apparition du protocole SOAP utilisant le XML qui permet globalement de faire la même chose mais plus beaucoup plus simplement. Il existe également RMI qui est uniquement destiné aux communications entre applications Java. Du côté de la programmation, RMI et SOAP se valent. Cependant, SOAP utilise plus de bande passante que RMI (qui est directement codé en binaire) et le XML de SOAP doit être parsé côté client et côté serveur ce qui peut être problématique pour des terminaux mobiles peu puissants. Mais SOAP est plus universel car RMI est limité à Java. Nous avons fait le choix d'utiliser RMI. Dans l'optique d'étendre les possibilité de l'architecture, il est cependant possible sous J2EE de générer des Web 40

49 CHAPITRE 4. CHOIX PRÉLIMINAIRES Services en SOAP sans modier le code des EJB. Pour les bases de données, du côté des solutions propriétaires, la version gratuite d'oracle (Oracle XE) n'a pas le support des données spatiales et les solutions payantes exposées au point 3.4 sont trop chères pour le cadre d'un mémoire. Du côté Open Source, MySQL, dans sa version stable, n'a pas encore implémenté l'entièreté des spécications de l'ogc et ne possède pas encore susamment de méthodes pour la manipulation des données. PostGreSQL est complet, libre et gratuit et possède au total plus de 300 méthodes de manipulation de données, codées en SQL 2 (le standard de fait des langages de requêtes de bases de données), en PL/pgSQL (SQL procédural de PostGreSQL) ou directement en C (plus rapide). Il est possible d'ajouter soi-même des méthodes supplémentaires. Nous avons dès lors choisi d'utiliser PostGIS, l'extension spatiale de la base de données PostGreSQL. 4.6 Technologies choisies Java La famille des langages Java (Java Micro Edition, Java Standard Edition et Java Enterprise Edition) tourne sur une machine virtuelle Java. Elle permet de faire abstraction de l'architecture réelle et de donner l'illusion d'une architecture constante quel que soit le système réel sur lequel tourne l'application Java. C'est la machine virtuelle qui interprète et exécute le bytecode généré à la compilation d'un programme Java. La machine virtuelle transforme ce bytecode en code machine réellement exploitable par l'ordinateur. Pour porter n'importe quelle application Java sur diérentes architectures, il faut juste développer une autre machine virtuelle qui permettra d'interpréter le même bytecode en code machine adapté au processeur et à l'architecture de l'ordinateur. Des machines virtuelles existent pour la plupart des systèmes d'exploitations, des processeurs, téléphones mobiles, PDA et appareils mobiles existants Java Standard Edition Le choix du langage de programmation pour le client s'est porté sur Java qui combine diérents avantages : simple : Java est un langage simple et rapide à programmer. La gestion des erreurs, la présence d'un garbage collector en font un outil puissant pour le développement d'applications diverses. De nombreux outils et environnement de programmation existent pour accélérer encore le développement. 2 Structured Query Language 41

50 CHAPITRE 4. CHOIX PRÉLIMINAIRES multi plateformes : Java est disponible sur de multiples plateformes. Cela inclut entre autres tous les systèmes d'exploitation d'ordinateurs et les serveurs de type Linux, Unix et Windows. C'est également le langage le plus populaire sur les appareils mobiles. orienté objet : La puissance de l'orienté-objet est utile pour le développement d'une plateforme. Cela permet de faciliter la réutilisation des objets entre les diérents services et de séparer la programmation en couches. susamment performant : Java est régulièrement critiqué pour sa vitesse d'exécution, car il génère du bytecode qui est ensuite interprété par la machine virtuelle. Cependant, les applications côté client doivent être relativement simples puisque la plupart des appareils mobiles ne sont pas très puissants. gratuit : la machine virtuelle Java est disponible gratuitement sur le site de Sun ( Il existe de nombreuses API gratuites (ou libres) et des environnements de développement puissants (comme Eclipse d'ibm) sont disponibles gratuitement. communication native avec J2EE : Les applications savent communiquer directement avec des applications J2EE au moyen de l'api RMI. Cela permet de diminuer le travail de traduction lors des communications au travers du réseau. Une partie des appareils mobiles (principalement les GSM et les PDA moins puissants) ne sont pas capables de faire tourner J2SE. Sun a dès lors déni J2ME (Java Micro Edition). Il existe deux sous-catégories de J2ME : une version contenant le strict minimum pour faire tourner une machine virtuelle (CLDC) et une version (CDC) regroupant toutes les possibilités de J2SE excepté ce qui touche à l'interface graphique. Le passage de J2SE à J2ME ne nécessite généralement que l'adaptation de l'interface graphique à l'ergonomie de l'appareil utilisé. Nous avons choisi dans notre implémentation de séparer la gestion de l'interface graphique et des fonctionnalités du client pour permettre de facilement utiliser une autre interface graphique spécique à un certain type d'appareil mobile Java Enterprise Edition J2EE (ou Java EE : Java Enterprise Edition) est une plateforme de développement Java spécialement destinée aux applications de type serveur. J2EE est une spécication développée par Sun Microsystems qui dénit des API 3. Pour être certié J2EE, un serveur applicatif doit respecter les spéci- cations de Sun. Une application respectant totalement les standards J2EE 3 Application Programming Interface : librairie d'objets et de méthodes permettant d'étendre les possibilités du langage Java 42

51 CHAPITRE 4. CHOIX PRÉLIMINAIRES pourra être déployée sur n'importe quel serveur applicatif certié J2EE. Cependant, la plupart des serveurs applicatifs sur le marché ajoutent un certain nombre de composants spéciques an de répondre à plus de besoins que ceux couverts par le J2EE standard. J2EE contient diérentes spécications, comme JDBC (Java DataBase Connectivity) pour la communication avec les bases de données, les applets pour faire des pages Web, les communications à distance RPC (Remote Procedure Call), Corba et RMI (Java Remote Method Invocation) entre applications. Depuis J2EE 1.4, les web services font également partie des spécications ocielles de J2EE. De plus, les serveurs applicatifs J2EE ont été pensés pour pouvoir être distribués sur une architecture composée de plusieurs serveurs. Les programmes J2EE utilisent des EJB. Un EJB (Enterprise Java Bean) est un programme Java eectuant la logique métier sur le serveur. Les EJB sont invoqués par d'autres EJB ou des applications clients au travers d'interfaces Java. Les EJB et leur interfaces sont regroupés dans ce qu'on appelle un conteneur EJB. Cette notion de conteneur EJB est détaillée à la section Les détails de la spécication des EJB et les avantages sont expliqués à la section J2EE dénit en plus un ensemble d'api qui étendent Java SE (Standard Edition) : javax.ejb L'API Enterprise Java Beans (EJB) dénit un ensemble de méthode qu'un conteneur d'objet distribué doit fournir pour permettre la persistance, la communication à distance, le contrôle de concurrence et l'accès à des objets multiples. L'API EJB sera décrite plus en détails dans la section javax.servlet et javax.servlet.jsp dénissent un ensemble d'api an de permettre la communication entre un conteneur web et des servlets ou JSP (Java Servlet Page) qui permettent de générer ou d'être achées sur des pages Web. java.sql et javax.sql permettent la communication avec des bases de données à l'aide de connecteurs JDBC. Cela permet à Java de se connecter à toutes les bases de données qui supportent ODBC (Open Database Connectivity). La liste des bases de données supportées contient entre autres Oracle, DB2, Microsoft SQL Server, Sybase, MySQL, PostgreSQL ou Microsoft Access [1]. javax.naming est une API pour trouver les données et les objets sur un réseau au moyen d'un nom et de l'adresse du serveur. Son implémentation est indépendante de l'architecture qui fait tourner la machine virtuelle. Cette API est utilisée par RMI. autres : D'autre API font également partie de J2EE : JTA (Java Transaction API) qui permet de standardiser les transactions ; Java Mes- 43

52 CHAPITRE 4. CHOIX PRÉLIMINAIRES sage Service qui permet la communication asynchrone entre composants Java ; JAXP qui permet de lire des chiers XML Enterprise Java Bean Les EJB (Enterprise Java Bean) sont la véritable particularité du développement J2EE. Dans la suite de ce texte, nous utiliserons les termes Bean et EJB pour désigner un EJB. La spécication des EJB détaille ce que le serveur applicatif fournit. Ces fonctions étant gérées par le serveur applicatif, le concepteur des EJB ne doit pas s'en soucier. 1. La persistance : les données contenues dans les EJB peuvent être sauvées à la volée par le serveur applicatif. En cas de problème avec celui-ci (coupure de courant, panne du système,...), l'état courant des EJB qui ont activé la persistance n'est pas perdu. En choisissant correctement les EJB utilisant la persistance, le système peut redémarrer dans son état avant le problème. 2. Le contrôle des transactions permet de s'assurer qu'un ensemble d'opérations devant s'exécuter ensemble se déroulent correctement. Faute de quoi, l'ensemble des opérations qui composent la transaction est annulées. Le transfert d'argent entre deux comptes est un exemple classique de transaction : si 100 euros doivent aller du compte A au compte B, il faut débiter le compte A et créditer le compte B. Ces deux opérations font partie d'une même transaction, si une de ces deux opérations échoue, la transaction complète doit être annulée pour garantir l'intégrité du système. 3. Le contrôle de la concurrence permet de s'assurer que plusieurs objets Java (une application client, un autre EJB,...) n'accèdent pas en même temps à un même EJB. S'il n'y a aucune contrôle sur la concurrence d'évènements, il est possible que les modications appliquées par le premier objet soient écrasées par les modications apportées par le deuxième objet. Il faut donc appliquer un contrôle de ces accès concurrents pour garantir la consistance des données. Imaginons un système où plusieurs objets essaient d'incrémenter la variable x conservée dans un EJB. Dans la gure 4.3, il y a contrôle de la concurrence, un scénario où deux objets incrémentent la variable x=3 mène à une situation nale où x vaut 5. Dans la gure 4.2, il n'y a pas de contrôle de la concurrence, la variable x vaut 4 alors qu'elle devrait valoir 5. Les deux objets ont incrémenté en interne la variable mais n'ont pas tenu compte des modications opérées par l'autre objet. Pour assurer la consistance des données, il faut qu'un objet risquant de modier les valeurs d'un autre objet soit le seul à y avoir accès pendant la période où il risque de modier ces valeurs. 44

53 CHAPITRE 4. CHOIX PRÉLIMINAIRES Fig. 4.2 Concurrence sans contrôle 4. Les événements peuvent être utilisés, grâce à Java Message Service (JMS), pour envoyer, de manière asynchrone, des messages entre des clients (composés d'objets Java). 5. La communication à distance avec des applications est supportée grâce à RMI et Corba. Types d'ejb Il existe plusieurs grandes classes de beans : les EJB de session, les EJB entité et les EJB Message Driven. Ces derniers étant moins important, nous n'en parlerons pas. Le lecteur intéressé pourra se référer à [4]. L'EJB le plus courant est le bean de session. C'est lui qui eectue les tâches demandées par le client. La relation entre le client et le bean consiste en une session interactive avec son client. Chaque bean de session est utilisé par un seul client à la fois jusqu'à la n de sa session et il n'est pas persistant (dans le sens qu'il n'est pas stocké dans la base de données). Cela veut donc dire que s'il y a un problème avec le serveur (panne, coupure,...) les sessions en cours sont perdues. Puisque les beans de session ne sont utilisées que par un utilisateur en même temps, il n'y a jamais de problème de concurrence. Les EJB de session sont créés au lancement du serveur et sont dans un état passif. Lorsqu'une requête arrive, ils passent dans un état actif, ré- 45

54 CHAPITRE 4. CHOIX PRÉLIMINAIRES Fig. 4.3 Concurrence avec contrôle pondent à la requête et une fois la session nie, repassent dans un état passif. Les EJB passifs sont placés dans un pool consitué d'un nombre prédéni d'ejb. L'avantage de créer les EJB au lancement du serveur applicatif vient du fait que la création d'un objet en Java est relativement lente alors que la réponse à une requête doit être la plus rapide possible. Le fait d'avoir des EJB prêts à répondre aux requêtes permet de diminuer le temps de réponse. Stateful Session Bean. Dans ce type de bean, l'ejb est capable de conserver l'état entre les méthodes évoquées par le client. C'est à dire que les variables sont conservées entre deux appels de méthodes. Comme un bean ne peut pas être utilisé par deux clients en même temps, le bean est bloqué durant toute la session. Stateless Session Bean. Ce type de bean ne conserve pas la session entre deux appels de méthode. Pour retrouver les données utiles à la session, il faudra lui donner un moyen de retrouver ces données. Dans notre plateforme, nous utilisons le nom d'utilisateur et la clé de session an que le bean soit capable de récupérer les éventuelles données utiles à son bon fonctionnement comme par exemple la dernière position connue de l'utilisateur. Les beans avec état ont l'avantage de demander moins de ressources réseau puisqu'il ne faut pas repasser le contexte à chaque appel de méthode. 46

55 CHAPITRE 4. CHOIX PRÉLIMINAIRES Cependant, le fait que les beans soient bloqués pendant toute la session implique que le nombre de clients pouvant être servis en même temps est plus limité. De plus, les beans sans état ne doivent conserver aucune donnée entre les appels de méthode. Cela induit le fait qu'ils ne perdent aucune donnée en cas de panne du serveur applicatif. Nous avons dès lors opté de privilégier les beans de session sans état. Entity Bean. Les beans d'entité correspondent aux données persistantes, c'est-à-dire stockées dans une base de données. En cas de coupure du serveur, les données des beans d'entité ne sont pas perdues car elles sont constamment copiées dans une base de données. La structure d'un bean entité (c'est-àdire ses attributs) correspond aux attributs stockés dans la table de la base de données. Une instance d'un bean entité correspond à une ligne de la table à laquelle se réfère le bean. Les beans entité ont donc beaucoup de points communs avec les tables d'une base de données : ils possèdent une clé primaire permettant de facilement les identier et les retrouver, ils peuvent être liés à d'autres beans d'entité tout comme une table peut être liée à une autre table au moyen de clés étrangères. Un EJB d'entité ne contient les données d'une ligne d'une table que pendant qu'il est actif. Dès qu'on ne l'utilise plus, il retourne dans une pool où il est vide et attend d'être utilisé pour répondre à une autre requête. On ne peut donc pas passer un pointeur vers un EJB d'entité pour faire référence à ses données. En eet, il est possible qu'entre le moment où l'ejb a été activé et le moment où un autre objet souhaite récupérer ses données, l'ejb soit inactif ou contienne les données d'une autre requête. De plus, le nombre d'ejb étant limité, l'idée de vouloir bloquer un EJB pour ne pas aller rechercher deux fois les données dans la table diminue les performances globales du système. Les beans entité peuvent être utilisés par plusieurs clients. C'est dans ce cas-ci que les problèmes de concurrence doivent être pris en compte. Un autre aspect important géré par J2EE est la transaction exposées à la page 44 Les données d'un bean entité peuvent être stockées de manière automatique (sans une seule ligne de SQL) par J2EE si l'on utilise l'approche CMP (Container Managed Persistance). On peut également choisir l'optique BMP (Bean Managed Persistance) où le créateur du bean inclura lui-même le code nécessaire à la persistance. Le CMP ne nécessite aucune ligne de code pour conserver les données, le BMP permet d'optimiser ou de distribuer les données à sauvegarder sur plusieurs bases de données. Dans notre plateforme, nous utiliserons un mélange des deux approches, l'ensemble des données d'identication des utilisateurs seront conservées grâce au CMP alors que les données spatiales sont sauvées par du code SQL spécique. 47

56 CHAPITRE 4. CHOIX PRÉLIMINAIRES Conteneurs EJB Les Beans ne sont jamais accessibles directement par les applications clients. Ils sont toujours intégrés à des conteneurs EJB. Ceux-ci contiennent, en plus donc des EJB, des interfaces Java qui permettent aux clients d'appeler les méthodes. Il existe deux types d'interfaces : remote pour les clients situés sur une autre machine virtuelle et local pour les clients situés sur la même machine virtuelle. Cependant, rien n'empêche d'accéder de manière remote à des EJB situés sur la même machine virtuelle. Il est également possible de dénir les deux types d'interfaces pour un même EJB. Une interface remote est typiquement utilisées dans une optique clientserveur. Dans notre cas, les clients situés sur les téléphones mobiles étant situés sur des machines diérentes de celle où se trouvent les EJB, on utilisera principalement des interfaces remote. Pour trouver l'ejb, le client devra connaître le nom du serveur ainsi que le nom de l'ejb déni dans l'interface. La découverte de l'ejb est gérée par JNDI (Java Naming and Directory Interface). Les interfaces local sont généralement utilisées par des EJB situés sur un même serveur. Cela leur permet de communiquer entre eux sans passer par le réseau. Par exemple, le serveur Web Tomcat est intégré au serveur applicatif JBoss et permet de générer des pages Web au moyen de servlet qui communiquent avec les EJB au moyen de l'interface local Serveurs applicatifs J2EE Plusieurs constructeurs développent des serveurs applicatifs compatibles J2EE. Si le serveur applicatif suit les recommandations J2EE 1.4 édictées par Sun, il obtient la certication J2EE 1.4. Le nombre de serveurs applicatifs ainsi certiés est relativement limité. Nous pouvons citer Sun JSAS (Sun Microsystems), WebSphere AS (IBM), WebLogic (BEA), Oracle AS (Oracle), JOnAS (ObjectWeb), JBoss (JBoss Inc.), Geronimo (ASF),... Les trois derniers sont Open Source alors que les quatre premiers sont des solutions propriétaires. Le choix s'est posé sur JBoss qui est le leader avec plus d'un tiers de parts de marché selon BZ Media [14]. JBoss est réputé pour sa qualité, le support d'xdoclet (voir point 4.6.6), la facilité de déploiement des EJB (ce qui est important lors du développement) et l'intégration de nombreux outils supplémentaires qui étendent les possibilités de la spécication J2EE [15]. Les points négatifs concernent la conguration manuelle d'un grand nombre de chiers et des paramètres par défaut peu adaptés à la plupart des applications [15]. 48

57 CHAPITRE 4. CHOIX PRÉLIMINAIRES XDoclet XDoclet est un moteur de génération de code pour J2EE. A partir d'attributs écrits sous un format spécique (JavaDoc), XDoclet parcourt le code source Java et crée d'autres chiers. Ces chiers peuvent être du code Java, des chiers XML ou encore des chiers HTML. C'est ce qu'on appelle l'attribute-oriented Programming. L'avantage est que XDoclet permet de manipuler moins de chiers Java, augmentant ainsi la productivité du développeur. Au départ, principalement destiné à J2EE (qui utilise beaucoup d'interfaces Java pour accéder aux EJB), XDoclet a évolué en un outil généraliste. Voici un exemple qui montre que la génération des interfaces est grandement facilité en utilisant XDoclet. En eet, la création des interfaces est un travail relativement trivial. En précisant les bons paramètres à XDoclet, il est capable de les générer automatiquement. Au début de la déclaration de l'ejb, on introduit les commandes XDoclet suivantes qui permettent de dénir le nom du bean, sa description, son type et le type d'accès : bean name="gate" d i s p l a y name=" S i l a s main a c c e s s Gate" d e s c r i p t i o n =" S i l a s a u t h e n t i f i c a t i o n " jndi name="e j b /Gate" type=" S t a t e l e s s " view type="remote " / Chaque méthode remote ou local doit également être signalée pour être intégrée par XDoclet dans l'interface correspondante : / Business i n t e r f a c e method / view type = ' ' remote ' ' En voyant ces deux bouts de code JavaDoc, XDoclet sait qu'il doit générer une interface pour l'ejb GateBean. A parti de l'attribut ejb.bean name, XDoclet connaît le nom à utiliser (dans notre exemple : Gate). Cela consiste à créer plusieurs interfaces Java. Si l'ejb est de type remote, on crée deux interfaces. La première est GateHome.java qui contient le nom du composant pour JNDI et la signature de la méthode create() permettant de créer une instance de l'ejb. Une interface nommée Gate.java qui contient les signatures des méthodes correspondante est également créée. Si l'ejb contient des méthodes de type local, c'est un chier GateLocal- Home.java et GateLocal.java qui sont créés. Chacun de ces chiers contient l'équivalent des chiers créés pour les EJB remote. 49

58 CHAPITRE 4. CHOIX PRÉLIMINAIRES GeoTools GeoTools 4 est une API en Java pour la manipulation de données spatiales. GeoTools fournit une implémentation des recommandations de l'ogc au fur et à mesure de leur développement. Les fondateurs du projet travaillent pour un membre de l'ogc. GeoTools est organisé en modules fournissant chacun diérents aspects des GIS (Geographic Information System). Le module main contient la base nécessaire au développement utilisant GIS. Il contient les représentations des objets géographiques selon les standards de l'ogc (chapitre 3.2.3) et des objets permettant de créer et manipuler des collections de données spatiales. Ces collections de données, appelées Features, sont utilisées pour générer des cartes. Le contenu des Features peut être crée par l'utilisateur, importé depuis des bases de données ou depuis des chiers GML. Les données supportent les ltres au moyen du package org.geotools.lter. Des modules spéciques ont été développés an de récupérer les données depuis des sources diverses : bases de données Oracle, DB2, Post- GreSQL, MySQL, HyperSonic,... ; les systèmes supportés par l'ogc : WMS, WFS ; des données spéciques à diérents programmes : SHP (ArcSDE), VPF (Département américain de la défense), MIF (MapInfo),... Des objets Swing permettant de créer des outils de visualisation sont également proposés PostGIS Dans le cadre de ce mémoire, au vu des besoins relativement limités (nous n'avons pas de cartes détaillées pour la Terre entière, le système n'accueillera pas simultanément des millions d'utilisateurs), Oracle et PostGreSQL se valent. Nous avons dès lors choisi d'utiliser PostGreSQL et son extension spatiale PostGIS. Cependant, chaque concepteur de service géolocalisé doit avoir la possibilité d'utiliser la base de donnée qui lui convient et ce choix ne doit pas être dépendant de la base de données choisie pour l'architecture de la plateforme centrale. Puisque notre plateforme s'appuie sur GeoTools et JDBC pour l'utilisation des bases de données, n'importe quel format supporté par une de ces deux API peut être facilement manipulé. Les détails pratiques de l'utilisation de PostGIS dans ce mémoire sont exposés dans l'annexe C. On y décrit la procédure d'installation sous Debian GNU/Linux, la création de tables et de vues an qu'elles puissent être utilisées en combinaison avec l'api GeoTools

59 CHAPITRE 4. CHOIX PRÉLIMINAIRES Eclipse et JBoss IDE Fig. 4.4 Intégration de JBoss dans Eclipse (1) Eclipse est un environnement de développement modulable développé par IBM. Il n'est pas lié à un langage particulier et est capable d'accueillir diérents types de plugin an d'étendre ses possibilités. JBoss IDE est un plugin pour JBoss édité par la société JBoss Inc qui rend le lancement de leur serveur applicatif et le déploiement des EJB directement accessible depuis l'interface d'eclipse (gures 4.4, 4.5). Le plugin JBoss IDE permet d'intégrer diérentes fonctionnalités de JBoss : la création des diérents types d'ejb, le lancement et l'arrêt du serveur applicatif ou encore la génération de méthodes J2EE et des tags XDoclet à partir d'une interface graphique phppgadmin phppgadmin est un outil d'administration de bases de données Post- GreSQL écrit en PHP et tournant sur un serveur Web. Il est capable de gérer les utilisateurs, les groupes, les vues, les schémas, les triggers, les fonctions, les séquences et les objets avancés. phppgadmin ne supporte pas les données spatiales dans son interface graphique mais la possibilité de taper directement des requêtes SQL ne fait pas de cette limitation un handicap. phppgadmin est à l'origine basé sur phpmyadmin, un outil d'administration de bases de données MySQL et supporte les particularités de Post- GreSQL. 51

60 CHAPITRE 4. CHOIX PRÉLIMINAIRES 4.7 Conclusion Fig. 4.5 Intégration de JBoss dans Eclipse (2) Nous avons donc décidé d'utiliser un serveur applicatif J2EE, JBoss en particulier pour ses possibilités étendues et sa popularité. Les clients sont programmés en J2SE qui est portable et disponible sur de nombreuses architectures d'appareils mobiles. La communication entre ces éléments se fait en RMI, limité au langage Java mais plus économe en bande passante et en CPU car il ne demande pas à être parsé. J2EE dénissant des standards pour les services Web, il est possible de fournir, à côté de la communication en RMI, de la communication en SOAP (XML). L'API utilisée est GeoTools, entièrement en Java, gratuite, libre et qui respecte les standards de l'ogc. GeoTools jouit de plus d'une communauté active de développeurs. 52

61 CHAPITRE 4. CHOIX PRÉLIMINAIRES Pour la programmation, nous avons décidé d'utiliser Eclipse et le plugin JBoss IDE ainsi que les fonctionnalités d'xdoclet pour faciliter la programmation J2EE. 53

62 Chapitre 5 Implémentation 5.1 Introduction Nous allons présenter l'implémentation de notre solution de plateforme. Le code se divise en trois parties : la plateforme (Silas) pour le serveur (en J2EE) ; le client (SilasTalker) permettant de se connecter au serveur (en J2SE) et un logiciel de visualisation de données spatiales (MapViewer) an d'acher les diérentes données spatiales de notre plateforme. Nous expliquons également les facilités proposées par notre plateforme Silas pour le déploiement des services géolocalisés et la conception des clients. Nous allons commencer par dénir les termes désignant les diérents éléments de la plateforme utilisés dans la suite de ce chapitre. Serveur applicatif est un serveur applicatif de type J2EE installé sur une machine et sur lequel est déployé des EJB. Plate-forme Silas représente le c ur des services géolocalisés. La plateforme est composée des éléments (EJB) gérant les utilisateurs, l'historique de leurs positions, la découverte de services et diérents outils pour la création de services. La plateforme Silas est déployée sur un serveur applicatif JBoss. Service représente un service utilisant la plateforme Silas mais pas spécialement situé sur le même serveur applicatif. Serveur Silas est le terme désignant la plateforme Silas et les services qui sont construits sur la plateforme. Malgré le fait qu'on parle du serveur Silas, il est en réalité possible que la plateforme et les services soient situés sur plusieurs serveurs applicatifs. Client ou SilasTalker représente la base de l'application client : connexion avec la plateforme Silas, gestion des erreurs, achage des fenêtres, menus,... Client de service ou plugin est un plugin spécique à un service capable 54

63 CHAPITRE 5. IMPLÉMENTATION de communiquer avec ce service et de créer un JPanel 1 qui sera aché par SilasTalker. 5.2 Suppositions 1. Il existe de multiples manières pour un appareil de connaître sa position. Parfois elle est connue directement (GPS), parfois c'est un élément de l'opérateur télécom qui permet de faire ce calcul. On peut imaginer qu'un utilisateur de GSM puisse faire une demande au LBS sans devoir connaître sa position. C'est alors à la plateforme de faire la demande à l'opérateur télécom. Dans des soucis de simplicité, nous avons supposé dans notre scénario que l'utilisateur connaît sa position et que c'est lui qui fait directement la demande de service au LBS. Nous n'avons cependant pas exclu de notre modèle de plateforme la possibilité d'utiliser le réseau pour localiser l'utilisateur. Pour cela, nous avons en eet intégré un EJB (CellularNetworkBean) pouvant être interrogé si nécessaire. 2. Le concept de push qui suppose que l'appareil reçoit du LBS une information quand il arrive dans une certaine zone sera modélisé par du polling : l'appareil envoie de manière régulière (tous les x minutes ou tous les x mètres) sa position au serveur qui détermine alors s'il est nécessaire de lui envoyer une information en retour. Cette technique n'est bien sûr pas très réaliste puisqu'au vu du nombre d'utilisateurs, elle impliquerait que le réseau soit engorgé par les messages de polling. On peut cependant imaginer que l'information de position soit intégrée dans les communications de base entre les antennes GSM et les appareils. Cependant grâce à l'umts et l'avènement de protocoles comme SIP [16], un véritable push sera possible. 3. Les services peuvent être développés par plusieurs personnes. Par conséquent, l'ensemble des services ne seront pas placés sur le même serveur applicatif. Nous avons donc fait le choix de favoriser les interfaces du type remote permettant aux programmes Java situés sur des machines distantes de se connecter aux services. Les services situés sur le même serveur applicatif peuvent également utiliser ces interfaces, le côté négatif étant qu'ils doivent passer par l'ensemble des couches d'une communication réseau. Cependant, cela induit une architecture plus souple car les diérents composants situés sur un même serveur peuvent plus facilement être séparés sur des serveurs applicatifs diérents. Cette possibilité permet d'augmenter l'adaptabilité de la plateforme, en cas de surcharge, le nombre de serveurs applicatifs utilisés pour absorber les requêtes peut facilement être augmenté. 1 Un JPanel est un composant graphique "blanc" qu'on surcharge pour dessiner des composants graphiques. 55

64 CHAPITRE 5. IMPLÉMENTATION 4. Dans la même optique que le point précédant, les diérents concepteurs de services peuvent choisir d'autres types de bases de données. L'accès à diérentes architectures de bases de données est permise par l'api GeoTools et plus généralement par JDBC (points et 4.6.3). 5. Pour augmenter éviter les abus, l'ensemble des bases de données contenant les données sensibles des utilisateurs comme les mots de passe ou l'historique des positions ne sont totalement accessibles qu'au c ur de la plateforme. 6. Certains services peuvent nécessiter de connaître l'identité de l'utilisateur et éventuellement être payants. D'autres peuvent être génériques et n'ont donc pas besoin de système d'identication. 7. L'identication et l'authentication des utilisateurs doit également être géré par la plateforme. Pour éviter des abus comme la surfacturation ou l'intrusion dans la vie privée des utilisateurs, les services ne pourront récupérer des données sensibles depuis la plateforme qu'à condition qu'ils en aient reçu l'autorisation des utilisateurs. Cette autorisation est limitée dans le temps et liée à la session de l'utilisateur qui a la possibilité de fermer sa session à tout moment. 8. Les communications mobiles sont par dénition de nature instable. La perte de connexion peut arriver et ne doit pas signier la n d'une session. 9. Les outils d'internationalisation de Java qui permettent de supporter plusieurs langues et les particularités régionales ont été intégrés à l'application client. 5.3 Jeu de données Pour utiliser un service géolocalisé, il est intéressant d'avoir à sa disposition un jeu de données dans un format OGC qui pourra être stocké dans une base de données an d'être manipulé et aché Le jeu de données Spearsh Le jeu de données Spearsh a été créé à l'origine par Larry Batten lorsqu'il travaillait pour l'u. S. Geological Survey. Les données ont ensuite été améliorées par l'usa/cerl (U. S. Army Corps of Engineers' Construction Engineering Research Laboratory). La zone représentée s'étend sur environ 180 km 2 et est située au nord de Black Hills au Dakota du Sud (USA). La version utilisée dans ce mémoire est composée des couches suivantes : La table roads est composée de 825 éléments du type MULTILINES- TRING et représente les routes de la zone couverte. La table streams est composée de 116 éléments du type MULTILINES- TRING et représente les cours d'eau. 56

65 CHAPITRE 5. IMPLÉMENTATION Fig. 5.1 Extrait du jeu de données Spearsh La table archsites est l'emplacement de 25 lieux archéologiques (POINT). La table bugsites regroupant des lieux où des insectes ont été retrouvés (POINT). La table rstrct contient des zones interdites d'accès (réserves naturelles,...) (MULTIPOLYGON ) Le jeu de données Frida Frida 2 (gure 5.2) est un jeu de données représentant la ville d'osnabrück dans le Nord-ouest de l'allemagne. Le projet a pour but de promouvoir la mise à disposition de données géographiques sous licence libre (Free Software). La version utilisée dans ce mémoire est composée des couches suivantes : La table rues est composée de éléments du type MULTILINES- TRING et représente les rues. La table rivieres contient 57 éléments composants les cours d'eau qui passent dans la ville (MULTILINESTRING). La table planseau contient les objets de type MULTIPOLYGON composants les plans d'eau

66 CHAPITRE 5. IMPLÉMENTATION Fig. 5.2 Le jeu de données Frida La table espacesverts contient les objets de type MULTIPOLYGON composants les zones vertes. La table poi est un ensemble de 268 lieux touristiques dans la ville (POINT). 5.4 MapViewer Le premier logiciel que nous avons conçu est MapViewer. C'est une simple application permettant à l'utilisateur de choisir les données de notre base de données au format PostGIS. MapViewer (gure 5.3) utilise l'api GeoTools pour générer les cartes à acher. Une carte est représentée par l'objet MapContext et est constituée de diérentes couches contenant chacune un type d'information, par exemple les routes ou les lieux touristiques. Les couches sont représentées par les objets FeatureSource de GeoTools. Les objets de la classe FeatureSource sont générés au moyen des DataStore. DataStore est une classe abstraite qui représente les dépôts de données spatiales pouvant venir de sources aussi diverses que du GML, des bases de données spatiales ou des chiers propriétaires comme les ShapeFile de la société ESRI. Diérentes classes héritent de DataStore et contiennent le code spécique à la lecture et l'interaction avec ces diérentes sources de 58

67 CHAPITRE 5. IMPLÉMENTATION Fig. 5.3 Diagramme UML simplié de MapViewer données. Il est donc possible de mélanger des données provenant de sources diérentes. Le style graphique est déterminé au moyen d'un objet de la classe Style qui permet par exemple de représenter un point sur la carte au moyen d'un rond rouge ou bien les éléments de la couche plans d'eau" par un polygone bleu clair. Il est également possible d'acher un texte à côté des éléments, typiquement la description de l'objet spatial. Les informations nécessaires pour récupérer et représenter chaque couche sont stockées dans un objet de la classe FeatureInfos. Chaque couche possède une description textuelle utilisée dans l'interface graphique. Les données spatiales de la couche sont récupérées au moyen de la classe DataStore de GeoTools. La sélection des données à récupérer peut être ltrée au moyen d'un objet du type Filter. 59

68 CHAPITRE 5. IMPLÉMENTATION Fig. 5.4 Sélection des couches dans MapViewer Une fois les données récupérées, les diérentes couches sont assemblées dans l'objet MapContext qui est passé à un objet StyledMapPane capable d'acher la carte et intégrant des outils permettant de zoomer, de se déplacer dans la carte ou d'eectuer des rotations de celle-ci. Nous avons étendu StyledMapPane au moyen de StyledMapPaneFX ajoutant des eets visuels supplémentaires comme un zoom progressif sur la carte. MapViewer est une application qui utilise la plupart des possibilités offertes par l'api GeoTools : la récupération des données au moyen des DataStore, le stockage en mémoire de celles-ci dans FeatureSource et la représentation de ces données dans un StyledMapPane. Les fonctionnalités de l'application, à côté des possibilités oertes par StyledMapPane, sont les eets visuels de StyledMapPaneFX, la possibilité de sélectionner les couches à acher (gure 5.4 par rapport à la gure 5.2) ainsi que les paramètres pour récupérer les données de ces diérentes couches. MapViewer permet également de sauvegarder les cartes visualisées sous les formats d'image SVG, PNG et JPG. Les gures 5.2 et 5.1 ont été générées directement depuis MapViewer. 60

69 CHAPITRE 5. IMPLÉMENTATION Fig. 5.5 Schéma UML simplié de l'architecture de Silas 5.5 Vision générale Client - Serveur L'architecture est divisée en deux grandes parties. D'un côté l'ensemble des programmes sur le client (GSM, PDA,...) et d'un autre côté les programmes hébergés sur le (ou les) serveur(s) applicatif(s). La communication entre le client et le serveur se fait au travers du réseau par le protocole RMI spécique au langage Java. Il a l'avantage d'être concis (économie en bande passante) et natif Java (économie de CPU) Eléments de la plateforme Les diérents éléments de Silas sont le client SilasTalker (détaillé au point 5.7) qui communique avec les services (point 5.6). Les services sont capables de communiquer avec le c ur de la plateforme pour l'authentication des utilisateurs ou les outils de génération des cartes. Chaque concepteur de service doit écrire le code des EJB de son service ainsi que les classes Java utilisées dans le client pour accéder à son service. La partie client se limite uniquement à la logique et à l'achage graphique nécessaire au service. Les services sont en fait des plugins ajoutés à SilasTalker et ne doivent pas tenir compte de la gestion des erreurs de communication, l'identication des utilisateurs, le lancement des services,... 61

70 CHAPITRE 5. IMPLÉMENTATION 5.6 Middleware J2EE Nous allons d'abord introduire les fonctionnalités de la plateforme avant de présenter le code de manière plus technique Session Le fonctionnement des sessions est similaire au fonctionnement de sessions sur les sites Web. Après s'être identié sur la plateforme au moyen de leur nom d'utilisateur et leur mot de passe, les utilisateurs reçoivent une clé de session générée par la plateforme. Cette clé est stockée dans la base de données de Silas et, chez le client, dans un objet similaire à un cookie. Le mot de passe n'est ainsi transmis qu'une seule fois par session sur le système. Les services ayant par la suite besoin d'authentier un utilisateur recevront de celui-ci son nom d'utilisateur (login) et sa clé de session. La validité de la session s'arrête soit lorsque l'utilisateur se déconnecte soit lorsqu'une période de temps prédénie est écoulée (timeout) Services avec ou sans identication Deux types de services peuvent être proposés à l'utilisateur : les services avec authentication qui nécessite que l'utilisateur communique son login et sa clé de session et les services sans authentication capables de servir n'importe quel utilisateur. Les services avec authentication ne recevant que la clé de session et le nom de l'utilisateur doivent faire appel au c ur de la plateforme an de vérier la validité de la session Souscription payante aux services La souscription payante aux services est un problème compliqué. Diérents modes de facturation existent, à l'abonnement, à l'utilisation ou encore au nombre d'octets transférés. Les modèles étant multiples et l'intérêt d'intégrer un de ces modèles de manière poussée étant relativement faible nous avons décidé de ne pas inclure de système de souscription. Cependant, voici comment l'on pourrait construire des services payants à partir de la plateforme actuelle. Des services à base d'abonnement peuvent facilement être gérés à partir de l'identication. Il leur sut de conserver la liste de leurs abonnés et ainsi ne répondre qu'aux requêtes des utilisateurs ayant payé. Les services souhaitant utiliser le paiement à l'utilisation pourraient, avant de répondre à la requête de l'utilisateur, faire appel à un service de facturation indépendant des diérents services. Ce service aurait pour tâche de limiter les abus, par exemple en ayant pour chaque utilisateur une liste de services pouvant et ne pouvant pas facturer. Ce qui revient à imposer de 62

71 CHAPITRE 5. IMPLÉMENTATION l'opt-in. Le service de facturation pourrait également avoir, pour chaque utilisateur, un montant maximal mensuel an d'éviter les mauvaises surprises en n de mois. Le paiement au nombre d'octets transférés est plus compliqué à gérer, notre plateforme n'a aucune méthode prévue pour compter le volume des communications générées par l'utilisation des services Services en cascade Un service (service appelant) ayant reçu le nom d'un utilisateur et sa clé de session peut utiliser ces données pour faire appel à un autre service (service appelé) et ainsi étendre ses possibilités. Le service appelant fait appel au service appelé et peut obtenir de celui-ci les données relatives à l'utilisateur. Par exemple, un service de calcul d'itinéraire peut faire appel à un service de cartographie an d'obtenir une carte de la zone de l'utilisateur et superposer le calcul d'itinéraire à cette carte. Le client n'eectue qu'une requête au service d'itinéraire qui lui-même fera appel au service de cartographie. Les communications entre les clients et le service sont ainsi limitées. Cela engendre cependant du trac entre les diérents serveurs hébergeant les services mais ces connexions sont laires et à haute capacité ce qui rend leur coût moindre par rapport au coût des communications entre le service et l'appareil mobile du client La super-classe ServiceBean Les services peuvent étendre la super-classe abstraite ServiceBean qui est capable de communiquer avec la plateforme Silas et appeler les méthodes de gestion des utilisateurs : 1. checkuser(string username) permet de vérier que l'utilisateur existe bien. 2. checksession(string username, String sessionkey) permet de vérier que la session de l'utilisateur est valide. 3. getlastpos(string username, String sessionkey) permet de récupérer la dernière position d'un utilisateur. 4. islogged(string username) permet de vérier qu'une session est en cours pour l'utilisateur. 5. getdescription() est une méthode abstraite que la sous-classe doit redénir et qui renvoie une description du service. Nous voyons que pour récupérer la dernière position d'un utilisateur, le service doit avoir reçu la dernière clé de session de cet utilisateur. Cela l'empêche donc d'avoir accès aux données de l'utilisateur après qu'il aie fermé sa session. 63

72 CHAPITRE 5. IMPLÉMENTATION Il faut noter que bien que son nom contienne le mot Bean, ServiceBean n'est en fait pas un EJB. En eet, les EJB doivent pouvoir être instanciés et eectuer une certaine logique métier, ce qui n'est pas le cas ici puisque nous avons aaire à une classe abstraite. Les EJB des services devront implémenter l'interface SessionBean de J2EE comme pour tout EJB de session classique HistoryBean La position des utilisateurs doit être sauvegardée dans les bases de données de la plateforme Silas. Régulièrement, le client informe la plateforme de sa nouvelle position, HistoryBean reçoit cette position et la stocke dans une table prévue à cet eet. En plus de la position et du nom de l'utilisateur, la table contient également l'instant où cette position a été reçue par la plateforme Silas. Cela permet de conserver un historique complet d'un utilisateur et de fournir des services qui seraient basés sur plus que la dernière position de l'utilisateur. Pour faciliter l'accès à la dernière position d'un utilisateur, une vue a été créée ne contenant que la dernière position de chaque utilisateur (voir C.4.2 à la page 90). Les positions sont également utilisées pour simuler des services de type push Achage de cartes Fig. 5.6 Carte et position de l'utilisateur dans SilasTalker 64

73 CHAPITRE 5. IMPLÉMENTATION Le serveur de Silas est capable, grâce à l'api GeoTools, de manipuler de nombreuses sources de données spatiales an de générer des cartes sur lesquelles d'autres services peuvent ajouter des données. Une image est ensuite générée (sous un format compressé pour diminuer le volume de données à faire transiter par le réseau) et transférée à l'utilisateur au moyen d'une liste d'octets. Pour illustrer ceci, nous avons créé l'ejb MapperBean et un plugin achant la carte de Spearsh qui est une image reçue au format PNG (voir gure 5.6) Structure du code Fig. 5.7 Structure des packages du serveur Silas La plateforme Silas est composée de quatre packages : le package lbs qui contient les EJB nécessaires aux fonctionnalités de base : identication, authentication, historique, découverte de services et achage de cartes ; le package interfaces contenant les interfaces permettant de communiquer avec les EJB du package lbs, le package service contenant la classe abstraite ServiceBean étendue par les services déployés sur la plateforme et le package utils comprenant les classes représentant les exceptions générées par Silas, les classes communes avec le client, les classes permettant de générer les cartes et les classes capables de générer des images à partir des cartes Le package mfe.silas.lbs Ce paquet est principalement composé des classes suivantes : UserInfosBean : c'est un EJB entité contenant les informations des utilisateurs. Les informations conservées sont le nom de l'utilisateur (login), son mot de passe (password), la clé de session générée au début de la 65

74 CHAPITRE 5. IMPLÉMENTATION Fig. 5.8 Structure du package mfe.silas.lbs 66

75 CHAPITRE 5. IMPLÉMENTATION session (sessionkey), l'heure et la date du début de cette session (last- Login) et une valeur booléenne indiquant si l'utilisateur est connecté ou non (islogged). UserLoginBean : cet EJB utilise UserInfosBean et gère les connexions (login, logout) et les inscriptions (signin). C'est également dans cette classe que la clé de session est générée (generatesessionkey), sauvegardée dans UserInfosBean et renvoyée à l'utilisateur dans un objet User- Session. Cet EJB contient les méthodes appelées par ServiceBean : checksession, checkuser, islogged et getposition. GateBean : cet EJB sert à découvrir les services, il se connecte à une base de données pour récupérer les services disponibles pour un utilisateur à sa position actuelle. Ensuite, l'utilisateur peut sélectionner le service et éventuellement télécharger le plugin pour le client s'il ne le possède pas encore. HistoryBean : c'est l'ejb expliqué plus haut qui gère l'historique des positions des utilisateurs. MapperBean : cet EJB est un service relativement simple qui ache la position d'un utilisateur sur une carte. Il renvoie une image (PNG, JPEG, SVG,...) ce qui a l'avantage d'être plus compact et donc de consommer moins de bande passante que d'envoyer l'ensemble des informations sous forme vectorielle Le package mfe.silas.utils Les exceptions Un ensemble d'exceptions peuvent être envoyées au client en cas d'erreur. Le client doit être capable de gérer ces exceptions lorsqu'elles surviennent. Cependant, certaines de ces erreurs sont prises en charge par les services de la plateforme (par exemple les erreurs de connexion aux bases de données). AlreadyExistingUserException indique que le nom d'utilisateur existe déjà lorsqu'on essaie de créer un compte avec un login déjà utilisé. ExpiredException indique que la session a expiré. UnexistingUserException indique que l'utilisateur n'existe pas, par exemple lorsqu'on essaie de s'identier avec un login inexistant. UnloggedException indique qu'aucune session n'est active pour l'utilisateur. ConnectionException indique qu'il y a eu un problème de connexion. UnknownPositionException survient lorsque la position de l'utilisateur est inconnue. 67

76 CHAPITRE 5. IMPLÉMENTATION Classes en commun avec le client Les classes suivantes sont utilisées par le serveur et par le client : GPSPosition représente une position de l'utilisateur et est composé des coordonnées et de la précision en mètres de cette position. ServiceDescription contient les informations reçues par l'application client à propos d'un service : une description textuelle du service, le numéro de la version du service, l'url du chier JAR 3 à télécharger pour activer le service et le nom de la classe Java principale du service pour lancer l'interface graphique du plugin. Les interfaces clients et la structure des plugins sont détaillés à la section Données de la carte Pour faciliter la génération de carte, la classe SilasMap permet de récupérer les couches de la carte Spearsh et des styles standards utilisables pour acher ces couches (rivières en bleu, routes en jaune avec bord orange, zone restreinte en gris transparent, ronds rouges, triangle avec texte,...). Rien n'empêche bien sûr de dénir ses propres styles. Génération d'images Le package mfe.silas.utils.image contient des classes capables de générer, à partir d'une carte (classe MapContext de GeoTools) des images au format SVG, JPG et PNG. 5.7 Le client SilasTalker Le client est composé de deux couches : la couche de présentation, en Swing, qui permet d'acher les services et la couche de logique qui gère la connexion, récupère et envoie les informations depuis la plateforme Silas. La couche de présentation permet simplement d'acher les fenêtres, les menus et les boutons pour l'utilisateur. Cette couche fait appel aux fonctions de la couche logique qui va réellement eectuer les actions demandées par l'utilisateur. Pour garder la vision traditionnelle des trois couches, on peut dire que la couche de présentation est l'interface graphique, que la couche logique est partagée entre les services sur le serveur applicatif et la couche logique du plugin et que la couche de données est composée des bases de données accessibles depuis les services. 3 chier compressé contenant des classes Java 68

77 CHAPITRE 5. IMPLÉMENTATION Fig. 5.9 Diagramme UML du client SilasTalker 69

78 CHAPITRE 5. IMPLÉMENTATION Chaque couche utilise un ensemble de fonctions des autres couches pour communiquer avec elles. Prenons l'exemple d'une identication réussie d'un utilisateur. Au début, l'utilisateur voit devant lui une fenêtre graphique en Java avec deux champs nom d'utilisateur et mot de passe ainsi qu'un bouton Login. Après avoir rentré ces informations et que l'utilisateur appuie sur le bouton Login, la couche graphique va passer ces données à la couche logique du plugin qui va aller communiquer avec la couche logique de la plateforme Silas an que celle-ci valide le couple (nom d'utilisateur, mot de passe) en vériant les données dans les bases de données (couches de données). La plateforme Silas répond (de manière positive) et génère une clé temporaire, valide pour la durée de la session de l'utilisateur. C'est la couche logique du client qui reçoit ces données, les stocke pour une utilisation future dans un cookie et renvoie à la couche graphique un signal pour lui indiquer que tout s'est bien déroulé. L'avantage d'une telle approche est que les couches sont séparées et peuvent donc être modiées sans inuencer les autres couches. Par exemple, si l'on décide de changer les bases de données, grâce à l'utilisation d'interfaces standard de communication avec ces bases de données, la couche logique ne devra pas être modiée. De la même manière, on peut récrire la couche graphique pour par exemple créer un client en J2ME spécique à un modèle de téléphone couche graphique La couche graphique tourne autour des classes ClientGUI et Client- GUIManager. ClientGUI, qui hérite d'un JFrame 4, est la base de la couche graphique présentée à l'utilisateur : elle gère l'achage des menus ainsi que les JPanel spéciques aux services ou à Silas. Les JPanel de Silas sont les panels d'identication, d'enregistrement, de choix de services,...les JPanel spéciques aux services sont, par exemple, pour un système FriendFinder, une carte de la zone où l'on se trouve avec des points représentant soi-même et ses amis. Chaque service dénit un JPanel qui sera exécuté par ClientGUI. La classe ClientGUIManager a pour tâche principale de gérer les exceptions que le plugin n'a pas à gérer (problèmes de déconnexion, utilisateur non identié,...) au moyen de la méthode manageexception(). A côté de cela, ClientGUIManager est également connu des services lancés et permet à ceux-ci d'ajouter un menu à l'interface graphique ClientGUI et de changer le JPanel aché et d'accéder à la couche logique. 4 Fenêtre graphique en Java, issue de la librairie Swing pouvant contenir de JPanel, JMenu,... 70

79 CHAPITRE 5. IMPLÉMENTATION couche logique La couche logique permet de gérer les communications avec la plateforme Silas. Sa classe principale est ClientCommon qui regroupe l'ensemble des fonctions de bases permettant de communiquer avec le serveur applicatif, de gérer l'enregistrement et l'authentication de l'utilisateur ainsi que de connaître la position la plus précise de l'appareil. La position des utilisateurs est connue au moyen d'un (ou plusieurs) objet du type Positionner, géré par un PositionnerManager qui a pour but de sélectionner l'élément de localisation le plus précis. Régulièrement, la position est communiquée au serveur Silas an d'être utilisée dans les services ou bien pour être utilisée dans des services du type push qui ont besoin de connaître régulièrement les utilisateurs entrant dans leur zone Le système de plugins pour les services Lorsqu'un utilisateur souhaite lancer un service, il doit posséder le code nécessaire au fonctionnement de ces services, c'est à dire la couche logique correspondante et l'interface graphique du service. Pour permettre aux développeurs de services de se concentrer uniquement sur leurs services, nous avons décidé d'utiliser un système de plugin. Le client SilasTalker n'intègre pas le code des diérents services la première fois qu'il est lancé. Lorsqu'un utilisateur souhaite utiliser un service, il cherche des services depuis le menu du client (ServiceFinder). Il reçoit alors une liste de services disponibles à sa position actuelle qu'il peut lancer. Pour qu'un service puisse être lancé depuis l'application client, il faut deux choses : 1. Créer un chier JAR qui contient une classe héritant de ServiceClient. ServiceClient est une classe dénissant uniquement un constructeur auquel on passe comme paramètre un ClientGUIManager. Cela permet au service d'avoir accès à la couche logique du client de base, d'ajouter des menus au client ou encore de changer le JPanel aché. Le chier JAR sera téléchargé par le client. 2. Faire connaître le nom de la classe héritant de ServiceClient. Pour cela, il s'inscrit dans la base de données gérée par le serveur Silas. Lorsque l'utilisateur lance ServiceFinder, le client SilasTalker communique avec le serveur Silas qui lui renvoit des objets du type ServiceDescription contenant entre autres l'url du JAR et le nom de la classe (voir point ). C'est cette classe qui est alors lancée par le client. 71

80 CHAPITRE 5. IMPLÉMENTATION 5.8 Packages pour développeurs Pour permettre le développement des services, nous avons besoin de créer de fournir deux chiers JAR (chier compressé contenant des classes Java) : 1. SilasTalkerClient.jar contient la classe ServiceClient (dont hérite les JPanel des services) et les classes utilisées par ServiceClient. 2. SilasService.jar contient la classe ServiceBean (dont hérite les EJB des services), les interfaces pour accéder au c ur de la plateforme Silas et les outils du package utils. Ensuite, il faut inscrire le service dans la base de données que consulte ServiceFinder pour que les utilisateurs puissent trouver le service. Cependant, on peut créer un service pour une utilisation restreinte et donc sans s'inscrire sur ServiceFinder (par exemple lors de la phase de développement), il sut pour cela d'avoir le chier JAR du plugin et de connaître le nom de la classe qui hérite de ServiceClient pour que SilasTalker puisse lancer le plugin. 5.9 Améliorations Web Services A côté des communications en RMI, on peut étendre les possibilités de la plateforme en utilisant les services web. J2EE en version 1.4 propose une architecture standard implémentée par un plugin de JBoss. Ensuite, il faudrait adapter le client actuel pour qu'il parse le code XML généré ou mieux, créer un client dans un autre langage que Java qui serait capable de communiquer avec la plateforme Silas Cartes Il y a un embryon de système découpant les cartes en un quadrillage composé de morceaux de cartes. Lorsqu'on souhaite se déplacer sur une carte, il serait intéressant de ne pas devoir retélécharger l'entièreté de la carte mais uniquement les nouvelles zones apparues. Par exemple en divisant la carte achée en neufs rectangles et lorsqu'on souhaite acher ce qu'il y a à droite de la zone actuellement visualisée, il ne faudra télécharger que les 3 rectangles à droite des 9 déjà visibles. Ainsi on diminue les volumes transitant par le réseau. Ce système est déjà mis en place sur la plupart des services de cartographies sur le Web Poisoning Les services évoluent dans le temps, il pourrait être intéressant d'intégrer un système de poisoning, c'est-à-dire de supprimer sous certaines conditions 72

81 CHAPITRE 5. IMPLÉMENTATION Fig Système de découpage pour les cartes les JAR des services téléchargés an qu'ils se mettent à jour. Un tel système permettrait également, si l'on sort de la zone de couverture d'un service, de supprimer le JAR devenu inutile. 73

82 Chapitre 6 Réalisation du scénario 6.1 Introduction Notre scénario exposé au point 4.2 demande la construction de deux services : GeoMail pour envoyer et recevoir des messages à un lieu donné et FriendFinder pour acher la position de ses amis. Nous allons montrer comment on peut utiliser la plateforme développée pour réaliser ces deux services. Des morceaux de code Java montrent ensuite l'utilisation en pratique de la plateforme. 6.2 GeoMail Pour GeoMail, il nous faut d'abord avoir une base de données capable de stocker les messages des utilisateurs. Nous avons opté pour une table contenant les champs from (String), to (String), precision (int), timestamp (Date), message (String) et the_geom (Point). Il faut ensuite créer un Bean, qui étend ServiceBean et qui implémente SessionBean contenant deux méthodes : GetMessage() et PostMessage(). Pour faire transiter les messages entre le client et le service, on utilise une classe sérialisable, GeoMessage, contenant la valeur des champs from, to, message et where PostMessage Le code est relativement simple : 1. On vérie la session de l'utilisateur avec checksession() hérité depuis ServiceBean. 2. On vérier que le destinataire existe avec checkuser() hérité depuis ServiceBean. 3. On se connecte à la base de données avec JDBC. 4. On insère les données avec JDBC. 74

83 CHAPITRE 6. RÉALISATION DU SCÉNARIO GetMessage La réception d'un message est également simple : 1. On vérie la session de l'utilisateur avec checksession(). 2. On se connecte à la base de données avec JDBC. 3. On eectue une requête SQL permettant de récupérer les messages qui sont destinés à l'utilisateur en tenant compte de la zone de validité du message. 4. On met la liste des messages dans un Vector qu'on renvoie au client Client GeoMail Le client GeoMail est composé d'une classe capable de communiquer avec l'ejb au travers de RMI et d'une interface graphique qui étend ServiceClient. L'interface graphique permet de poster et de recevoir des messages (gures 6.3 et 6.4). 6.3 FriendFinder Le service FriendFinder est légèrement plus compliqué car il utilise les outils de génération de cartes et prend donc beaucoup de lignes pour dénir les couches de la carte à superposer et le style de ces couches. Du point de vue bases de données, on a besoin de conserver qui est l'ami de qui ainsi que les clés de session des personnes connectées au service pour pouvoir demander leur dernière position à la plateforme Silas. On crée deux méthodes dans l'ejb : getfriends() et getfriendsname() permettant de récupérer les positions et les noms des amis d'un utilisateur depuis la base de données. Ensuite, on utilise les classes dans le package utils de la plateforme Silas pour récupérer les couches des cartes correspondant aux routes et aux cours d'eau. A ces deux couches, on ajoute la couche des amis représentés par un carré vert et leur nom d'utilisateur et la couche contenant la position de l'utilisateur (rond rouge). On zoome la carte sur la zone contenant les deux utilisateurs (avec un espace de bordure), on génère l'image (au format PNG) qu'on envoie sous forme d'octets au client. Celui-ci récupère les octets, en génère une image (classe ImageIcon) et la place sur un JPanel qui est aché par SilasTalker (voir gure 6.3). Le code à écrire pour le client prend moins de 100 lignes, en comptant le code permettant de se connecter au service. Le code à écrire pour l'ejb du service prend environ 250 lignes, une grande partie servant à récupérer les données de la base de données, à les placer sur une couche compatible avec l'api GeoTools et à spécier le style de ces couches (par exemple carré vert avec texte pour les amis). 75

84 CHAPITRE 6. RÉALISATION DU SCÉNARIO 6.4 Exemples de code Voici quelques exemples de code montrant comment utiliser les outils proposés par la plateforme Silas Utiliser les méthodes de ServiceBean Voici un bout du code de GeoMailBean. Les variables to, from et sessionkey correspondent à l'expéditeur, le destinataire et la clé de session de l'expéditeur : try { // V é r i f i e l a s e s s i o n checksession ( from, sessionkey ) ; // V é r i f i e que l e d e s t i n a t a i r e e x i s t e checkuser ( to ) ; // Récupère l a d e r n i è r e p o s i t i o n GPSPosition pos = getlastpos ( from ) ; } catch ( UnloggedException e ) { // U t i l i s a t e u r from non l o g g é } catch ( UnexistingUserException e ) { // U t i l i s a t e u r from ou to i n e x i s t a n t } catch ( ConnectionException e ) { // Erreur à l a connections avec l a p l a t e f o r m e } Créer une carte Pour créer une carte, il faut d'abord créer un MapContext, lui ajouter des couches, leur appliquer un style et puis en faire une image. SilasMap fournit des styles standards (rivières en bleu, routes jaunes,...) et l'accès aux couches de la carte Spearsh. MapContext map = new DefaultMapContext ( ) ; SilasMap silasmap = new SilasMap ( ) ; //On a j o u t e l e s route e t l e s r i v i è r e s map. addlayer ( silasmap. getfsroads ( ), silasmap. getroadsstyle ( ) ) ; map. addlayer ( silasmap. getfsstreams ( ), silasmap. getstreamsstyle ( ) ) ; //On crée l a bordure de l ' image ( enveloppe ) // i c i c ' e s t l e s bords de l a c a r t e S p e a r f i s h Enveloppe env = map. getlayerbounds ( ) ; 76

85 CHAPITRE 6. RÉALISATION DU SCÉNARIO //On transforme l a c a r t e en image, on s é l e c t i o n n e j u s t e l ' enveloppe MaptoImage m2i = new MaptoImage (map, env ) ; //On d é f i n i t l a t a i l l e de l ' image de s o r t i e m2i. setcanvassize (new java. awt. Dimension (300, ) ) ; ByteArrayOutputStream output = new ByteArrayOutputStream ( ) ; try { //On sauve en PNG m2i. topng( output ) ; } catch ( IOException i o e ) { // Erreur à l a g é n é r a t i o n de l ' image } // output c o n t i e n t l e s o c t e t s de l a c a r t e en PNG 6.5 Scénario Pour illustrer le fonctionnement du scénario, voici le déroulement de celuici : Alice lance SilasTalker, s'identie sur le système (gure 6.1) et lance FriendFinder dans la liste proposée par ServiceFinder (gure 6.2). Comme aucun de ses amis n'est connecté, une carte générale de la zone est achée avec le rond rouge la représentant. Bob se connecte à ce moment ; sur l'écran d'alice, Bob apparaît (gure 6.3). Elle décide de lui envoyer un message (gure 6.3 à droite) qui est reçu par Bob (gure 6.4). Fig. 6.1 Alice lance SilasTalker et se connecte 77

86 CHAPITRE 6. RÉALISATION DU SCÉNARIO Fig. 6.2 Alice lance ServiceFinder et sélectionne FriendFinder. Fig. 6.3 Alice voit Bob et sa position et lui envoie un message Fig. 6.4 Bob reçoit le message d'alice. 78