JavaVidEd : Dossier de conception

 

 

 

 

 

A l’attention de :

M. MICHELIN

michelin@univ-mlv.fr

 

Etudiants :

Arnaud BALAY

arnaud@balay.nom.fr

Juliette COLMANT

gcolmant@aol.com

Denis ELBAZ

denis_elbaz@yahoo.fr

Patrice LAMARQUE

patrice.lamarque@freesbee.fr

Marilyne MERCIER

marilyne_mercier@club-internet.fr

Rana TADAYONI

rana_tadayoni@yahoo.com

 


Ce document présente les choix techniques réalisés à la suite des différentes réunions et des études de faisabilité menées. Il décrit les points clés qui ont guidé la conception du produit. Il s'agit d'une synthèse des étapes de conception qui ont été réalisées par l'équipe de projet. Pour la description complète, il est nécessaire de se reporter au site du projet : http://javavided.sourceforge.net .

1.               Architecture du serveur

JavaVidEd adopte un modèle client-serveur. Il s'agit d'un système communautaire destiné à réaliser des petits montages vidéo à travers un réseau ou bien Internet. Cette section présente les caractéristiques du système en soulignant les choix fonctionnels et techniques.

1.1.                          Droits d'accès et sécurité

Le système prévoit plusieurs niveaux d'accès aux utilisateurs.

Pour pouvoir profiter de l'ensemble des fonctionnalités du système un utilisateur doit s'enregistrer sur le système en choisissant un pseudonyme (login) et un mot de passe. Une fois enregistré, l'utilisateur peut bénéficier de l'ensemble des fonctionnalités du système. Il pourra alors réaliser ses propres montages, les publier ou les conserver privés.

 

Pour entrer dans le système, un utilisateur doit s'authentifier en fournissant son login et  son mot de passe. Ces informations circulent sur le bus JavaVidEd. Le login n'est pas crypté, en revanche le mot de passe est crypté à l'aide de l'algorithme MD5 pour assurer un niveau maximal de sécurité.

L'algorithme de cryptage MD5 utilisé a été emprunté au projet JigSaw (http://www.w3.org/Jigsaw) . Ces informations sont stockées dans une base de données.

 

Chaque utilisateur Javavided a la possibilité de livrer ses montages à l'ensemble de la communauté. Un montage public est un montage que son auteur accepte de rendre disponible à l'ensemble de la communauté. Les autres utilisateurs pourront visualiser ce montage et le manipuler à leur guise. Cependant, seul l'auteur d'un montage est autorisé à modifier de manière permanente un montage. Les utilisateurs qui désirent réutiliser un montage public dont ils ne sont pas l'auteur ont cependant la possibilité de sauvegarder un montage public sous un nom différent ou identique. Ils deviennent alors l'auteur d’une copie de ce montage.

 

Enfin, il est possible d’entrer sur le système dans le mode invité. Un invité ne saisit aucune information et peut librement consulter les montages publics. Il peut aussi utiliser l'interface de montage et le panier de médias mais il n'a pas la possibilité de sauvegarder son travail. C'est un privilège réservé aux utilisateurs enregistrés.

1.2.                          Persistance

Les données du système ne sont pas volatiles. Un utilisateur peut retrouver ses anciens montages tels qu'il les a laissés lors de sa dernière session.

JavaVidEd utilise donc une base de données pour stocker l'ensemble des montages ainsi que les informations sur l'utilisateur. Une solution commerciale étant exclue dans ce projet, le système de gestion de base de données utilisé est MySQL.

 

L'accès à cette base de données est réalisé en Java grâce à l'API JDBC. Cette API rend abstrait l'accès à une base de données et permet de connecter n'importe quel système de gestion de base de données sans qu'il ne soit nécessaire de réécrire le code. Il suffit simplement de se procurer un driver adéquat. Le driver JDBC pour MySQL que nous avons utilisé est celui de Mark Matthews (http://mmmysql.sourceforge.net).

1.3.                          Description et schéma de la base

Voici le schéma de la base de données que nous avons utilisée pour stocker les informations de manière permanente sur :

·        Les utilisateurs (users)

·        Les éléments constituant le basket (media)

·        Les montages des utilisateurs (Assemblies)

Un assembly est un élément permettant de stocker les informations sur le créateur, le nom du montage, et des informations internes comme la date de création, de dernière modification, de dernière ouverture.

A un Assembly, on associe un unique Script qui permet de stocker des informations plus techniques sur le montage, comme la durée...

A un Script on associe un ensemble de ScriptEvents dont le rôle est de stocker chaque élément de la time line. On pourra par exemple indiquer que l’on veut jouer le média M à T secondes pendant D secondes sur le canal C.

Enfin les Media, en plus d’être référencés par les ScriptEvents sont utilisés pour constituer le contenu du panier (Basket). Les media sont associés à un thèmes via la table MediaBelongToTable ce qui permet d’avoir une relation “many to many” entre thèmes et média. On pourra donc par exemple trouver la vidéo d’un chat qui tombe dans les thèmes humour et animaux. Pour finir, les média sont divisés en 2 catégories (son ou vidéo).


 

Voici le schéma de la base :

1.4.                          Bus de communication

Le système JavaVidEd adopte le modèle client-serveur pour la communication. Les échanges entre le client et le serveur utilisent un bus de communication similaire à celui de RMI ou de CORBA. Il n'est cependant pas compatible avec ces deux technologies.

 

L'objectif étant de réaliser un client léger, la solution CORBA a été écartée car elle nécessite l'import de nombreuses API supplémentaires. L'étude de la solution CORBA OpenORB (http://www.openorb.com), bien que séduisante, a été abandonnée en raison de difficultés pour la mise en œuvre de la persistance.

 

La solution choisie permet notamment de débarrasser le client du support du driver de base de données et de délocaliser la base de données ailleurs que sur le serveur. En effet, pour des raisons de sécurité, les applets ne peuvent établir des connexions réseau qu'avec le serveur dont elles sont issues. Cette limitation impliquait forcément que la base de données se trouve physiquement sur la même machine que le serveur. En laissant la gestion des appels de base de données au serveur, le système bénéficie d'une souplesse de déploiement supérieure.

 

Elaboré sur les bases des études menées sur CORBA, le principe de fonctionnement du bus JavaVidEd est donc relativement proche de celui de CORBA et encore plus de celui de RMI. Sur le client, une façade de méthodes permet d'envoyer des requêtes au serveur.

 

Le serveur répond en fournissant des objets Java en utilisant le mécanisme de la sérialisation. La sérialisation fournit un moyen efficace de sauvegarder l'état des objets Java. Ces objets sont alors facilement transmissibles sur un réseau par le protocole de transport TCP. Le serveur utilise un seul port pour répondre aux requêtes des clients. Il s'agit du port TCP 52828.

1.5.                          Streaming et montage audio/vidéo

Les montages vidéo sont réalisés sur le serveur avant d'être transmis au client par le biais d'une session RTP. L'avantage de cette solution est de libérer le client des tâches de montage relativement lourdes. En revanche, la machine sur laquelle sera déployé le serveur devra être suffisamment robuste pour supporter le montage de nombreux utilisateurs simultanés.

 

[Explication du principe du RTP -> Denis]

 

Pour tirer partie de la transmission de flux audio/vidéo via RTP, JavaViEd utilise la JMF (Java Media Framework). Cette API, bien qu'encore jeune, reste pourtant la plus avancée en Java pour ce type de tâches.

Notons que la présence de la JMF est nécessaire à la fois sur le serveur et le client.

 

1.6.                          Concurrence

 

Le serveur JavaVidEd est capable de servir plusieurs clients simultanément. Chaque session utilisateur possède son propre contexte qui est géré au sein d'une thread indépendante afin de gérer la concurrence.

Afin d'améliorer les performances lors des montées en charge, le serveur possède un gestionnaire de thread qui maintient un pool de thread prêtes à servir un client. Ces threads sont recyclées après achèvement de la session utilisateur.

Le travail du serveur consiste à rester à l'écoute sur le port, à l'attente de nouvelles connexions. Dès qu'une connexion est réalisée, le serveur réquisitionne une thread et se remet en attente.


2.               Architecture du client

Le client est une applet mais peut fonctionner parfaitement en mode application de bureau pour peu qu'une connexion Internet soit disponible.

2.1.                          Applet et sécurité

Le logiciel client se présente sous la forme d'une applet. Pour permettre à l'applet de communiquer avec le serveur, il est nécessaire de la signer numériquement. Sans cette étape la machine virtuelle n'autorise pas l'applet à réaliser des connexions réseau.

Un certificat numérique est nécessaire pour signer une applet. Un certificat a été obtenu auprès de l'autorité de certification Thawte Consulting. Ce certificat entre dans le cadre du programme Freemail qui correspond au niveau de confiance minimum permettant de signer une applet.

Sur un produit professionnel, un certificat de niveau supérieur doit faire l'objet de vérifications de la part de l'autorité de certification.

2.2.                          Environnement multifenêtre

L'interface graphique du client utilise les composants légers Swing de Java2. Leur flexibilité permet de tirer partie des capacités objet de Java pour construire des interfaces graphiques personnalisées.

 

Pour permettre aux utilisateurs d'organiser leur espace de travail à leur convenance, plusieurs fenêtres sont disponibles :

·          le panneau de contrôle (Control Panel) permet à l'utilisateur dans un premier temps de s'enregistrer, de modifier son mot de passe et de se loger sur le système. Une fois logé, le panneau de contrôle se transforme en panneau de gestion de montages. A partir de ce panneau l'utilisateur peut charger et supprimer ses montages.

·          Le panier de médias (Basket) est une fenêtre dans laquelle l'utilisateur peut visualiser les médias mis à disposition sur le système. Ces médias sont stockés sur le serveur et sont administrés par les administrateurs de JavaVidEd. Pour plus de lisibilité, les médias sont catégorisés dans des thèmes. Le panier de médias propose la fonctionnalité de jouer un média en le sélectionnant. La lecture utilise le mécanisme de streaming décrit précédemment.

·          La timeline est la représentation en fonction du temps de la lecture des différents média constituant le montage. Il est possible d’ouvrir plusieurs timelines simultanément et de réaliser des glisser-déplacer entre elles.

·          La fenêtre de visualisation est la fenêtre dans laquelle l'utilisateur pourra visualiser son montage, le montage d’une autre personne ou bien un média du basket. Cette fenêtre n'est disponible que lors de la lecture d'un montage ou d'un média pour ne pas encombrer l'espace de travail.

·          L'application est dotée d'une fenêtre d'aide contextuelle que l'utilisateur peut appeler à sa guise en cliquant sur l’icone “?” puis en cliquant sur le composant dont on requiert l’aide.

2.3.                           Internationalisation

L'interface graphique est configurée par défaut pour la langue française. L'utilisateur a cependant la possibilité de choisir la langue qui lui convient. L'application se reconfigure automatiquement à la volée. Le nombre de langues supportées n'est pas figé et il est possible d'ajouter facilement des fichiers de ressources pour d'autres langues que le français.

Les fichiers de ressources sont facilement éditables et modifiables car il s'agit de simples fichiers textes organisés sur le principe de clé/valeur.

Notons cependant que l'application n'est pas prévue pour fonctionner avec des jeux de caractères autres que les jeux de caractères européens (ISO???). Dans sa version actuelle, l'application cliente supporte le français et l'anglais.

 

2.4.                          Paramétrage

 

Les couleurs et les icones sont paramétrables par le biais d'un fichier de configuration. Ce fichier de configuration contient tous les paramètres concernant le serveur, les fichiers de ressources et le look de l'application.