CAW1 2014 Projet d'Alexis Chretienne et de Theophile Montovert

De Ensiwiki
Aller à : navigation, rechercher
Logo webrtc petit.png
Titre du projet Web conference
Cadre Projet WEB

Équipe alexis Chretienne théophile Montovert
Encadrants Sebastien VIARDOT


Présentation du projet

Description générale

Ce projet a pour but de faciliter la mise en place de débat et de conférence pour des personnes géographiquement distantes grâce aux outils de l'Internet.

Existant depuis de nombreuses années, la technologie de visio conférence permet facilement aux gens de communiquer de manière instantanée. En effet, beaucoup de personnes utilisent cette technologie au moyen de logiciels (à installer comme Skype) qui permettent de communiquer avec des contacts précis. D'autre part, il existe sur internet de nombreux lieux de partage (chatrooms, ...) où les discussions se font avec des utilisateurs inconnus. Ici, nous souhaitons rapprocher les utilisateurs grâce à la visio-conférence qui est encore très peu présente sur la toile. Nous souhaitons que les internautes puissent discuter simplement entre eux de manière plus rapprochée. Mais nous avons pensé qu'il serait intéressant de poser des règles pour organiser ces discussions. D'où, l'idée de créer des débats et des conférences. Les débats permettent de discuter autour d'un sujet de manière organisée, l'objectif est de développer un algorithme de prise de parole (chaque utilisateur fait une demande de prise de parole, et lui ai ainsi accordé selon une liste FIFO). La conférence permet quant-à elle à une personne ou un groupe de personne de faire un exposé sur un sujet précis, les spectateurs peuvent à la fin poser des questions sur la présentation. Poussé dans un élan collaboratif, l'utilité de ces deux derniers permettrait de discuter autour de sujets personnelles ou professionnelles à distance.

Ainsi chacun pourrait y trouver son intérêt :

  • Parler librement autour d'un sujet d'actualité
  • Donner un cours à distance
  • Animer un débat

C'est pourquoi, nous avons inventé un système collaboratif et gratuit de visio conférence qui permet à chacun soit d'animer librement un débat/une conférence, d'y participer sur invitation ou en tant que spectateur. Un système de temps de parole (notamment pour les débats) et de questions serait alors mis en place afin de gérer simplement ces discussions.

De plus, ce système serait simple d'utilisation. Il suffit de créer un meeting ou d'y participer. En effet, la valeur ajoutée de ce système concerne votre ordinateur. La technologie d'aujourd'hui permet la communication type visio conférence avec un navigateur web, qui intègre ces fonctionnalités. Cela s'appelle la communication web temps réel.

En plus de cela, la communication peer-to-peer que propose l'API EasyRTC permet de décharger le serveur de la gestion des streams utilisateurs. Ainsi, il serait alors difficile pour un internaute externe d'avoir accès à la totalité des streams des utilisateurs. L'objectif est aussi de proposer une certaine confidentialité aux utilisateurs qui pourraient être heureux de savoir que leurs conversations ne sont pas écoutés par un tiers.

Démonstration vidéo

Un démonstration vidéo est disponible à cette addresse

La communication web temps réel (WebRTC)

La communication web en temps réel WebRTC est une interface de programmation (API) JavaScript actuellement au stade de brouillon (Draft) développée au sein du World Wide Web Consortium (W3C) dont les premières ébauches sont apparues en mai 2011. C'est aussi un canevas logiciel avec des implémentations précoces dans différents navigateurs web pour permettre une communication en temps réel. Le but du WebRTC est de lier des applications comme la voix sur IP, le partage de fichiers en pair à pair en s'affranchissant des plugins propriétaires jusqu'alors nécessaires.

Webrtc-overview.png

Nous utiliserons dans ce projet une API dérivée de WebRTC, nommée easyRTC dont la documentation est disponible ici : Github et le site constructeur associé EasyRTC

Enfin, vous pouvez essayer librement cette technologie ici : Démonstration. Essayez de vous connecter à cet adresse web depuis de multiples machines (ordinateur, mobile, tablette), vous y verrez la puissance de cette jeune technologie !

Easyrtc.png

Objectifs du projet

Il faut bien comprendre dans ce projet qu'il existe deux parties :

  • Le système d'information de gestion des discussions (voir partie 2).
  • Le système de visio conférence en lui même (voir partie 3).

L'objectif principal de ce projet est de réaliser la première partie, c'est à dire l'application de gestion des meetings. En fonction de l'avancement du projet, l'équipe pourra commencer la seconde partie. Pour plus d'informations, veuillez vous référer aux incréments mis en place.

Cahier des charges du système d'information de gestion des discussions

Cette partie présente le cahier des charges de l'application Web. Les fonctionnalités seront d'abord expliquées, puis la mise en place de l'infrastructure du système d'information, avec enfin l'ensemble des diagrammes UML.

Fonctionnalités

Rôles des internautes

L'application web est un système de consultation / création / réservation de discussions (débat et conférence). L'utilisateur pourra facilement réaliser ces opérations. Il est important de rappeler que seul le créateur d'une discussion devra s'enregistrer. Il y aura donc Quatre rôle à définir avec les des fonctionnalités associées :

  • Le créateur : Pour créer un meeting, un utilisateur devra forcement être enregistré. Il complétera un formulaire décrivant la discussion

, ainsi que les personnes à invitées (adresse email). Un email sera alors envoyé aux participants afin qu'il confirme leur présence pour la date convenue. Cet personne aura son propre compte, lui résumant l'ensemble des opérations réalisées sur le site (liste de ses discussions, etc..)

  • Le Participant : on distingue deux types de participants, les utilisateurs enregistrés et les utilisateur non enregistrés. Dans la pratique, un utilisateur non enregistrés peut participé uniquement aux meetings privées pour lesquels il a reçu une invitation. Il recevra un email de la part de l'application pour lui prévenir qu'il a été invité à rejoindre un meeting. Il devra confirmer sa présence par l'intermédiaire d'une adresse URL donné dans le mail (son clic confirmera sa présence). En plus de cette fonctionalité, les utilisateurs enregistrés peuvent eux participés aux meetings public (il lui suffit de cliquer sur le bouton participer dans la liste des meetings).
  • L'administrateur du site : Il régulera la bonne gestion du site. Il pourra annuler toute discussion si le créateur ne respecte pas les termes mis en place (sujet sensibles notamment).

Le débat

Un utilisateur peut créer un débat. Il spécifie le sujet, la date, l’heure, une langue et la durée (pas obligatoire). Il choisit si ce débat est public ou privé. Si celui-ci est privé, il invite les utilisateurs souhaités en renseignant leur adresses mail. Si le débat est public, le créateur peut fixer le nombre de participant. Les utilisateurs peuvent réserver une place au débat.

Déroulement :

  • Au début du débat, le créateur à la parole. Il peut la céder en appuyant sur “espace”. Chaque utilisateur peut appuyer sur “espace” pour prendre la parole. Une demande de prise de parole peut être annuler en appuyant sur “espace”. Tous les utilisateurs sont notifiés anonymement par la volonté de prise de parole d’un participant. Les demandes de prise de paroles s’accumulent.
  • Lorsque la durée est écoulée, l’ensemble des utilisateurs votent pour terminer ou non le débat. La majorité l’emporte. Si le débat doit continuer ou si aucune durée n’a été spécifié, tous les participants peuvent proposer la clôture du débat à tout moment (la majorité l’emporte).


La conférence

Un utilisateur peut créer une conférence. Il spécifie le sujet, la date, l’heure, une langue et la durée. Il choisit si cette conférence est privée ou public. Si celle-ci est privée, il invite les utilisateurs souhaités en renseignant leur adresses mail. Si la conférence est public, le créateur peut fixer ou non le nombre d’invités. Les utilisateurs du site peuvent réserver une place à la conférence.

Déroulement :

  • Au début de la conférence, le maître de conférence a la parole. Il peut décider ou non d’attendre son public.
  • A la fin de la conférence, les utilisateurs (ayant réservé une place) peuvent interroger le maître de conférence.

Infrastructure mise en place

L'infrastructure informatique à mettre en place pour le bon fonctionnement du projet sera constitué de plusieurs composantes logicielles, décrit dans le schéma suivant.

Infrastucture pweb.png

Pour le développement, un serveur Play 1.2.7 sera installé sur chaque station de travail afin de pouvoir tester localement l'application. Cependant la base de données associées (MySql 5.5.37) à l'application sera commune. Elle sera installée sur un serveur distant (GNU/Linux disponible à l'adresse IP 91.121.203.21. L'interface PhpMyadmin pourra être installé si besoin.

Chaque station de travail sera également équipé d'un environnement de développement lié au gestionnaire de version de sources Git. Le projet sera déposé sur la plateforme Github (projet privé).

Enfin, le serveur NodeJs sera mis en place pour la seconde partie du projet, pour utiliser la communication web en temps réel (grâce à l'API EasyRTC).

  • L'application sur le serveur permet la gestion des meetings et des utilisateurs associés.
  • Le serveur NodeJs permet la mise en relation des utilisateurs à la date des meetings.

Utilisation du Webservice SOAP pour vérifier les adresses emails

Pour garantir la fiabilité les adresses emails des utilisateurs à enregistrer (si il y a un contact email à faire), l'application (côté serveur) devra vérifier les adresses lors de :

  • L'enregistrement d'un nouvel utilisateur
  • La mise à jour de l'email d'un utilisateur inscrits dans son compte personnel

Lors de l'une de ces opérations, le serveur Play vérifiera localement la validité de l'email (regex) tandis que le Webservice cherchera à vérifier :

  • sa validité (équivalent à une regex). Valeur : oui/non
  • son rattachement à un serveur email. Valeur oui/non
  • sa disponibilité SMTP. Valeur oui/non

Celui-ci est disponible à cette adresse.

Avec ces informations, nous estimerons qu'une adresse email existe et qu'il sera possible de la contacter. Le diagramme de séquence associée au scénario "s'inscrire sur le site" illustre l'intégration et l'utilisation de ce Webservice.

De plus, Le contact entre le serveur play et le Webservice se fera par SOAP (1.2). Play enverra l'email à vérifier tandis que le Webservice répondra par les 3 informations citées ci-dessus. La figure ci-dessous montre le message SOAP envoyée et reçu par Play.

Soap.png

Diagrammes de la base de données

La modélisation de ce diagramme nous a permis de facilement créer l'ensemble des classes du modèle utilisés par Play.

WebMeeting DB diag.png

Diagrammes UML

Cas d'utilisation

Usecase pweb.png

Diagramme de classes

Utilisant la technologie JPA, le diagramme de classe ci-dessous contient les classes qui seront à implémenter. Bien entendu, ce diagramme est équivalent à au diagramme de base de données, initialement établit.

Class diagram.png

Diagramme de séquence

Scénario : s'inscrire sur le site

Signup.png

Dès que l'utilisateur recevra un email de création de compte, il devra se confirmer pour valider le compte.

Scénario : se connecter au site

Signin.png

Scénario : demander un nouveau mot de passe

Forgot password.png

Scénario : se déconnecter du site

Signout.png

Scénario : mettre à jour des champs du compte

Account update.png

Ce diagramme est générique pour l'ensemble des champs à mettre à jour dans le compte utilisateur (email, username et mot de passe). L'email disposera d'une vérification en plus (confirmation par le web service dédiée).

Scénario : créer un débat / une conférence

Make meeting.png

Ce diagramme est générique pour la création d'un débat / une conférence privée/publique. Il est à noter que chaque participant (d'un meeting privé) recevra un email de confirmation.

Tests

L'application web sera testé à l'aide de trois types de tests :

  • Tests unitaires : opération d'insertion, lecture, mis à jour et suppression (opération CRUD sur le modèle de l'application)
  • Tests fonctionnels : test de scénarios (modèle de l'application)
  • Tests séléniums : test de scénarios (modèle et vue de l'application)

Un scénario sera valide si et seulement si ses trois tests (pris dans l'ordre donné) ne reportent aucune erreur.

Informations supplémentaires

Cahier des charges (trés simplifiée) du système de visio conférence

Le serveur NodeJs intègre les APIs suivantes : express, mysql, socket.io et easyrtc. Ce serveur permet de mettre en relation les utilisateurs avec le meeting pour lequel ils se connectent.

En parallèle, le serveur exécute :

  • une attente active pour récupérer les utilisateurs.
  • un pool toutes les 30s vers la BD pour créer les rooms correspondant aux meetings actifs.


Depuis l'application Play, les utilisateurs ont accès à un lien qui les rediriges vers l'url ci-dessous.

http://[@ip-nodertc]:8080/participe/hashCode?=parametre

Le paramètre passé est code MD5 qui peut correspondre à deux cas :

  • URL unique du meeting (créé à partir de la concaténation de l'id du meeting et du code langage)
  • hashCode unique du participant (créé à partir de la concaténation de l'id du meeting et de l'id de l'utilisateur)


Le fait que ce paramètre puisse correspondre à deux éléments différents permet de faire la distinction entre la connexion du créateur du meeting et de celle des participants. En effet, le créateur se connecte grâce à l'url du meeting et les participants avec le hashCode du tuple correspondant dans la table PARTICIPANTS de la BD mysql.

Après vérification en base de donnée (si l'utilisateur est le créateur ou un participant et si la date du meeting est valide), on récupère le MD5 du meeting roomName. Ensuite, le serveur redirige l'utilisateur vers l'url suivante :

http://[@ip-nodertc]:8080/room.html?id=roomName

A ce stade l'utilisateur doit activer l'utilisation de ses périphériques (microphone et webcam) et peut enfin communiquer avec tous les participants du meeting.


Lorsque le serveur nodertc est actif, un cron s'exécute toutes les 30s pour aller chercher en BD les meetings actifs.

   Pour chaque meeting actif dans la BD
       Si la room n'existe pas
           Une room est créée avec pour identifiant la variable roomName contenant le MD5 du meetig (champ URL table MEETINGS).
       Sinon
           Si le meeting est terminé
               Si tous les participants sont partis
                   On supprime la room et on met à jour le champ STATUS du meeting à TERMINATED
               Sinon 
                   On attend que tous les utilisateurs partent
           Sinon
               On attend la fin du meeting

Réalisations

Avancement du projet

Plusieurs incréments ont été définis, notamment les deux principaux définis ci-dessous. La priorité est donnée au système d'information de gestion de réservations{ (application web)

  • Etude du projet
    100 %
  • Etude de la technologie WebRTC
    100 %
  • Mise en place du wiki
    100 %
  • Mis en place du système d'information de gestion de réservations
    100 %
    • Rédaction du cahier des charges
      100 %
      • Rédaction du contexte et objectifs du projet
        100 %
      • Diagrammes UML
        100 %
      • Diagrammes pour la base de données
        100 %
    • Mise en place de l'infrastructure informatique
      100 %
    • Développement
      100 %
      • Prise en main de Play
        100 %
      • Développement du Modéle
        100 %
        • Mise en place de la base de données
          100 %
        • Développement des composantes du modèle
          100 %
      • Développement de la vue
        100 %
      • Développement du contrôleur
        100 %
    • Tests
      100 %
      • Tests unitaires
        100 %
      • Tests fonctionnels
        100 %
      • Tests selenium
        0 %
    • Démonstration vidéo
      100 %


  • Mis en place du système d'information permettant la visio conférence
    50 %
    • Rédaction du cahier des charges
      100 %
    • Mise en place de l'infrastructure informatique
      100 %
    • Développement
      100 %
      • Prise en main de Node JS
        100 %
      • Développement de la partie applicative supportant le module EasyRTC
        50 %
      • Développement de l'algorithme de prise de parole pour les conférences
        0 %
      • Développement de l'algorithme de prise de parole pour les débats
        0 %
    • Tests pour la partie développée
      100 %

Aperçu de l'application mobile

L'utilisation de JQuery mobile a été nécessaire afin d'adapter l'application web.

  • Page d'accueil

Home mobile.png

  • Page personelle (compte)

Account mobile.png

  • Page de connexion

Signin mobile.png

  • Ecran listant les conférences (publiques ici) pou un utilisateur

Conference mobile.png List mobile.png

Validation du projet par les tests

Tests unitaires

  • Mis en place des tests unitaires
    100 %
  • Tests unitaires des composantes de la base de données
    100 %
  • Tests unitaires des autres composantes du modèle
    100 %

Tests fonctionels

  • Mis en place des tests fonctionels
    100 %
  • Tests seleniums des scénario
    100 %

Tests selenium

  • Mis en place des tests selenium
    0 %
  • Tests selenium des scénario
    0 %

Perspectives et améliorations possibles

Global

Nous avions penser à créer une sorte de chaîne médiatique qui proposerait la visualisation des conférences et des débats ayant eu lieu. Il serait alors nécessaire de proposer cette fonctionnalité au créateur du meeting. Les participants au meeting en serait informés. Le serveur NodeRTC se devrait d'enregistrer l'ensemble des flux qu'il traite pour créer la vidéo. L'activitation permetterait au site d'héberger la vidéo sur une chaîne de type YouTube ou Dailymotion afin qu'elle puisse être visualisée par tous les internautes de la toile. Les revenus ainsi dégagés par la publicité pourrait établir un business model pour la bonne vie du site.

Une amélioration possible serait de renforcer la confidentialité avec la sécurisation des flux avec https (la fonctionalité openSSL étant déjà implémenter au sein de l'API EasyRTC).

Application

Du point de vue de l'application, nous pensons à ajouter de nombreuses fonctionnalités :

  • Ajout de tests sélénium
  • Ajout d'un type de meeting, la discussion qui permettrait de discuter sans algorithme de gestion de temps de parole
  • Ajout de la synchronisation des meetings auxquels l'utilisateur participe avec son agenda
  • Ajout d'un système de paiement pour utiliser le service WebMeeting à une fréquence plus élevée (ex : création de plus de 10 meetings privée par mois)

NodeRTC

Du point de vue du serveur nodeJs, il reste à implémenter les différents algorithmes de gestion du temps de parole (débat et conférence). Le système de pool pour la création des rooms des meetings actifs peut être repensé pour créer les rooms lors du premier accès utilisateur. Enfin, le design pour améliorer le confort des communications est aussi à améliorer (nous avions pensé à un carousel 3D), l'existant étant celui de l'API EasyRTC.

Bilan du projet académique

  • Utilisation d'un framework -> oui (Play 1.2.7)
  • Gestion des rôles avec des utilisateurs différents ayant des droits et des rôles différenciés -> oui (utilisateur (non) enregistré, administrateur)
  • Site adapté à plusieurs terminaux dont une version mobile -> oui (JQuery Mobile)
  • Mise en place de jeux de tests unitaires -> oui
  • Souhaitable : Mise en place de jeux de tests fonctionnels avec des technologies de type selenium -> non
  • Souhaitable : utilisation webservice -> oui (emailValidate)
  • Optionnel : abonnement rss -> non
  • Optionnel : partie du site en gwt ou au moins avec un framework type smartclient -> non

Télécharger le projet

Voici l'archive (projet web Play + serveur node js) avec sa documentation : Fichier:Projet.zip