Application web pour la coordination de trajets piétons jusqu aux transports en commun

Transcription

1 Application web pour la coordination de trajets piétons jusqu aux transports en commun PROJET DE FIN D ETUDES ASR Etudiants : Encadrants : Oumar Sharif DAMBABA Clément BERTHOU Olivier BERGER Christian BAC

2 Table des matières Remerciements... 2 Introduction générale Présentation du sujet Recherche d applications similaires existantes Les technologies utilisées... 5 Node.js... 5 Redis... 6 Socket.io Comparaison avec certaines technologies existantes... 8 Node.js vs Java... 8 Redis vs MongoDB... 9 Socket.io vs Ajax Les cas d utilisation Architecture serveur Interface de l application Page d accueil Création de rendez-vous Liste des rendez-vous de l utilisateur Conclusion et perspectives Bibliographie

3 Remerciements Remerciements Nos remerciements vont { l endroit de nos encadrants, M. Olivier BERGER et M. Christian BAC, pour la proposition du sujet et surtout pour nous avoir encadrés tout au long de la réalisation de ce projet. 2

4 Introduction ge ne rale Introduction générale Ce document présente le travail effectué dans le cadre de notre projet de fin d études. Il décrit aussi bien les étapes suivies que les méthodes et technologies utilisées pour la réalisation dudit projet. Le projet consiste à développer un service pour la coordination de trajets piétons jusqu aux transports en commun. 1 Présentation du sujet Ce n est pas un secret de polichinelle. Tous autant que nous sommes, nous préférons ne pas voyager seuls. En effet, voyager avec d autres personnes nous épargne de la solitude et de l ennui. Nous voyageons en toute convivialité. Lorsque nous voyageons à plusieurs, nous ne voyons pas le temps passer ; si bien que, le voyage devient beaucoup moins pénible. On se sent plus en sécurité. C est dans ce contexte que s inscrit notre projet de fin d études. Nous avons développé une application qui permettra à ses utilisateurs de se donner des rendez-vous pour voyager ensemble ou juste pour se rendre aux transports en commun s ils vont dans différentes directions. Ils pourront non seulement se donner rendez-vous mais aussi s envoyer des messages pour s informer d un éventuel retard en vue de repousser le rendez-vous, si possible. 3

5 2 Recherche d applications similaires existantes L idée première était de trouver une application similaire déjà existante sur laquelle nous pourrions nous baser pour réaliser notre application. Le but était d éviter de réinventer la roue. Vu qu il n existe pas { ce jour d application existante pour le «copiétonage», nous avons recherché des applications de covoiturage qui pourraient nous servir dans la réalisation de notre projet. Nous avons trouvé entre autres : - Icare - Mycarpooling-carpooling - You-move Mais ces applications open-sources ne correspondaient pas réellement à ce que nous recherchions. Pour exemple, l application Icare nécessitait au moins une dizaine de technologies. Ce qui la rend très complexe et donc difficile à utiliser comme base pour notre projet. Nous avons donc finalement décidé de développer l application { partir de zéro. 4

6 3 Les technologies utilisées Pour ce qui est des technologies, nous avons choisi Node.js pour le backend, Redis pour la base de données, Socket.io pour la communication et l ensemble HTML/CSS/JavaScript pour le frontend. Node.js Node.js est une plateforme logicielle libre et événementielle en JavaScript. Il offre un environnement côté serveur qui nous permet d'utiliser le langage JavaScript pour générer des pages web. En gros, il vient en remplacement de langages serveur comme PHP, Java EE, etc.. JavaScript étant un langage basé sur les évènements, Node.js est donc lui aussi basé sur les évènements. Il est puissant et rapide. Sa rapidité vient de son moteur V8 et son fonctionnement non bloquant. En effet, Node.js utilise le moteur d exécution ultrarapide V8 de Google Chrome, un outil open source créé par Google qui analyse et exécute du code JavaScript très rapidement. Jusqu'à la sortie de Chrome, la plupart des navigateurs lisaient le code JavaScript de façon peu efficace : le code était lu et interprété au fur et à mesure. Le navigateur mettait beaucoup de temps à lire le JavaScript et à le transformer en code machine compréhensible pour le processeur. Le moteur V8 de Google Chrome, qui est réutilisé par Node.js, a un fonctionnement complètement différent. Très optimisé, il fait de la compilation JIT (Just In Time). Il transforme le code JavaScript très rapidement en code machine et l'optimise même grâce à des procédés complexes tels que code inlining ou encore copy elision. Comme JavaScript est un langage conçu autour de la notion d'évènement, Node.js a pu mettre en place une architecture de code entièrement non bloquante. Dans les applications web, il est courant d'avoir des opérations longues et bloquantes comme : Les appels aux bases de données Les appels à des services web (ex : l'api de Twitter) Node.js nous évite de perdre du temps en nous permettant de faire d'autres choses en attendant que les actions longues soient terminées. Node.js est donc idéal pour les applications qui doivent répondre à de nombreuses requêtes rapidement et efficacement, en temps réel. Ce qui justifie notre choix d utiliser cette technologie. 5

7 Redis Redis vient de l anglais REmote DIctionary Server qui peut être traduit par «serveur de dictionnaire distant». C est un système de gestion de base de données clefvaleur scalable, très hautes performances, écrit intégralement avec le langage de programmation C ANSI, par Salvatore Sanfilippo, et distribué sous licence BSD. Il est par définition mono-threadé et donc mono-cœur. Son architecture est similaire { Node.JS ou PlayFramework. C est une architecture événementielle non bloquante. Redis utilise cependant sa propre implémentation du gestionnaire d événements. Globalement, Redis est donc dans la mouvance de ces nouvelles architectures non bloquantes et réactives. Il vise à fournir les performances les plus élevées possibles. Socket.io Socket.io est une bibliothèque JavaScript pour les applications web en temps réel. Il permet la communication bidirectionnelle et en temps réel, entre les clients et le serveur web. Il comporte deux parties: une bibliothèque côté client qui s exécute dans le 6

8 navigateur, et une bibliothèque côté serveur pour Node.js. Les deux composants ont des APIs presque identiques. Comme node.js, il est piloté par les événements. Socket.io utilise principalement le protocole WebSocket. Il offre beaucoup de fonctionnalités, y compris la radiodiffusion à prises multiples, le stockage des données associées à chaque client, et les Entrées / Sorties asynchrones. 7

9 4 Comparaison avec certaines technologies existantes Node.js vs Java Node.js offre de meilleures performances que Java pour des accès concurrentiels, c est-à-dire, lorsqu il s agit de gérer des milliers ou des centaines de milliers de connexions à la fois. Cela peut se faire avec Java mais les rendements ne sont pas les mêmes. Lorsque les clients d un site obtiennent fréquemment des erreurs de connexion, le site finit par les perdre. Avec Node.js, on n obtient des erreurs de connexion que dans le cas d un déni de service. Cet avantage de Node.js sur Java lui vient de son caractère non bloquant comme on peut le voir sur les figures ci-après. En effet, Node.js n utilise pas un thread par connexion comme Java. Un unique thread gère toutes les connexions. Par conséquent il utilise moins de ressources pour certaines opérations comme la fermeture de connexion. 8

10 Redis vs MongoDB Tout d abord, l avantage de Redis est l amélioration considérable du temps de réponse, et donc des capacités de l instance. En effet, l{ où les autres SGDB doivent régulièrement lire sur le disque dur des données, ce qui a une durée relativement longue notamment sur des disques à plateau, Redis lit les données directement en RAM, donnant des temps de réponse très largement inférieurs, autant en lecture qu en écriture. 9

11 Malheureusement, cet avantage ne vient pas seul. En effet, le fait de stocker l intégralité de la base de donnée en RAM consomme beaucoup plus de mémoire, notamment lorsque de grandes quantités de données sont sauvegardées. De plus, la restauration de ces données en cas d arrêt du serveur est extrêmement longue. En effet, le mécanisme de persistance de Redis est assez atypique. Il propose deux modes : - Le mode RDB (Rigid Disk Block) qui consiste à sauvegarder le contenu entier de la base de données dans un fichier très compressé sur le disque dur à un instant donné. Les options de Redis permettent de définir un intervalle de temps pour les back up successifs (exemple : une sauvegarde toutes les 24h). Cependant, ces sauvegardes sont coûteuses en ressources, et ne peuvent donc pas être faites trop régulièrement, ce qui entraîne une perte de toutes les données depuis le dernier back-up en cas de crash de l instance. - Le mode AOF (Append Only File) qui consiste à simplement écrire toutes les instructions reçues par le serveur { la fin d un fichier de sauvegarde. La restauration se fait ensuite en effectuant { nouveau l ensemble des instructions enregistrées. Cependant, sur des bases de données très actives, le fichier peut rapidement prendre une taille démesurée, et la restauration n en est que plus longue. Cependant, après avoir vu ces deux méthodes, nous pouvons trouver un juste milieu : en effet, en mélangeant les deux méthodes (RDB toutes les 24h, AOF remise à 0 à chaque nouveau back up RDB), on obtient une solution plutôt légère et fiable, même si, de par sa structure, Redis ne sera jamais aussi performante pour de l archivage de gros volume de données que MongoDB par exemple. 10

12 Ensuite, cerise sur le gâteau, Redis propose également un système de PubSub (Publish/Subscribe) intégré, permettant la programmation événementielle multiserveur. Socket.io vs Ajax Socket.io utilise les websockets, une fonctionnalité supportée par l ensemble des navigateurs récents. Elle permet un échange bilatéral synchrone entre le client et le serveur. Les websockets permettent de laisser une sorte de "tuyau" de communication ouvert entre le client et le serveur. Le navigateur et le serveur restent connectés entre eux et peuvent s'échanger des messages dans un sens comme dans l'autre dans ce tuyau. Le serveur peut donc lui-même décider d'envoyer un message au client. AJAX permet au client et au serveur d'échanger des informations sans recharger la page. Mais en AJAX, c'est toujours le client qui demande et le serveur qui répond. Le serveur ne peut pas décider de lui-même d'envoyer des informations au client. Ce qui est possible avec websocket. 11

13 5 Les cas d utilisation Un administrateur s occupe de la modération de l application L utilisateur de l application peut : - créer un compte et se connecter. - Modifier son compte - Créer un rendez-vous - Rejoindre un rendez-vous - Rechercher un rendez-vous - Repousser un rendez-vous - Annuler un rendez-vous L administrateur peut : - Bannir un compte - Supprimer un message 12

14 13

15 6 Architecture serveur 14

16 7 Interface de l application 7.1 Page d accueil 7.2 Création de rendez-vous 15

17 7.3 Liste des rendez-vous de l utilisateur 16

18 Conclusion et Perspectives Conclusion et perspectives Ce projet nous a permis de perfectionner nos compétences en programmation événementielle en associant Node.js, redis et socket.io pour la réalisation de notre application. Il nous a aussi fait améliorer notre capacité de gestion et d autonomie. En effet, nous avons dû nous organiser avec rigueur pour remplir nos tâches respectives afin de respecter les délais tout en étant assidus à nos cours. Comme perspectives, nous envisageons de : Permettre aux utilisateurs d accéder aux horaires des RER Mettre au point un système de messagerie instantanée pour les utilisateurs Localiser le trajet sur une carte Envoyer des notifications aux utilisateurs Permettre la création d une liste d amis Améliorer l interface de l application Faire une application mobile android/ios 17

19 Bibliographie Bibliographie