Cédric CHEDALEUX Thomas GUERIN Jérémy SCHOEN Florent WEBER.

PROJET D’OPTIONCédric CHEDALEUX

Thomas GUERINJérémy SCHOENFlorent WEBER

Applications Web en mode déconnecté

Tuteur-entreprise : M. Nicolas ANDRE (ZENIKA)Tuteur-école : M. Hervé GRALL

Ecole des Mines de Nantes 3

Présentation Contexte d’application Une étude en 4 phases :

Phase 1 : Découverte Phase 2 : Approfondissement Phase 3 : Prototypage avec Google Gears Phase 4 : Prévisions et Conclusion

Conclusion : de l’utilité du mode déconnecté Bilan : un projet enrichissant

Plan


Web 2.0◦ Nouveaux usages (communautés…)◦ Nouvelles technologies

Parmi ces technologies◦ Apparition du mode déconnecté pour les

applications Web

L’explosion du Web 2.0


Exemple : un voyage en train : le passage dans un tunnel provoque la perte de la connexion.

Impossible de terminer l’envoi du courriel en cours d’écriture.

Solution : Simulation de la page Web en local Stockage du courriel dans une base de données Synchronisation au moment de la reconnexion

Contexte : une connectivité à Internet variable


Les objectifs de ce sujet de veille technologique sont :

Répertorier l’ensemble des solutions existantes Retenir les solutions pertinentes (critères à définir) Réaliser un prototype pour la solution phare Conclure sur l’état de l’art et anticiper les évolutions

Thème d’étude


OBJECTIF TRANSVERSE : Découvrir et maîtriser les techniques de gestion de projet :

AU DEBUT : estimation des charges… PENDANT : suivi au quotidien, adaptation face aux

imprévus… A LA FIN : bilan, enseignements…

Chef de projet : Florent W.

Outil : Open WorkBench (logiciel de gestion de projet, libre)

Un mot sur la gestion de projet…


L’organisation du projet est basée sur le découpage en 4 phases :

Phase 1 : Découverte Implication de tous afin d’avoir une idée globale du

thème d’étude.

Phase 2 : Approfondissement Répartition des technologies jugées intéressantes :

Google Gears : Cédric C. Adobe Air : Jérémy S. Zimbra : Thomas G. Autres : Florent W.

Gestion de projet (1/2)


Phase 3 : Prototypage Répartition en fonction de la charge :

Google Gears : le « gros morceau », le cœur de l’étude. Cédric C., Thomas G., Florent W.

Adobe Air : en plus par rapport aux attentes initiales. Jérémy S.

Phase 4 : Prévisions & Conclusion Implication de tous (mise en commun des acquis)

Durée du projet : environ 13 semaines travaillées

Gestion de projet (2/2)


OBJECTIF : Pour chacun des membres de l’équipe, découvrir :

Le contexte d’application Les intérêts du mode déconnecté Les principaux acteurs Les briques technologiques essentielles

Phase 1 : Découverte


Fusion RIA/RDA

RIA : Rich Internet Application◦ Lancement dans le navigateur◦ Pas d’installation

RDA : Rich Desktop Application◦ Installation sur le poste client◦ Accès aux ressources de l’ordinateur◦ Utilisation locale

Mode déconnecté, qu’est ce que c’est?


L’arrivée du mode déconnecté réduit la frontière entre RDA et RIA :◦ Si la RIA permet le mode déconnecté, alors on

obtient une application utilisable sans connexion Internet donc de type “desktop“

◦ Inversement, en mode connecté, des RDA offrent les mêmes fonctionnalités et interactions qu’une page web.

Différence entre RDA et RIA


Palier le plus gros défaut des RIA : une perte de connexion => perte du service

Permettre aux RIA d’accéder aux ressources locales afin d’assurer la continuité du service

Il existe 2 modes de déconnexion :◦ Explicite : voulue par l’utilisateur◦ Implicite : non souhaitée par l’utilisateur

Mode déconnecté, qu’est ce que c’est?


Il est difficile pour certaines architectures d’offrir un mode déconnecté

En effet, les pages web peuvent être générés côté serveur et non côté client comme GWT, Flex ou tout simplement HTML/JavaScript

Rendre une application “déconnectée“ nécessite un rapatriement de tout ou partie des traitements métiers sur le navigateur

Enjeux des applications Web en mode déconnecté


Comment assurer une bonne répartition des traitements entre le serveur et le navigateur client?

Comment gérer de gros volume de donnés?(répartition de la charge)

Comment gérer les problèmes de mises à jours concurrentes et comment les notifier aux utilisateurs?

Enjeux des applications Web en mode déconnecté


OBJECTIF : Réaliser un panorama de l’existant afin de sélectionner les solutions pertinentes.

Phase 2 : Approfondissement


Yahoo offre un mode déconnecté à son webmail via Zimbra Desktop

FlickR, MyBlogLog: exemples de services offerts par Yahoo

Mais qu’offre donc Zimbra pour engendrer un tel engouement de la part de Yahoo?

Yahoo se lance dans le mode déconnecté


Zimbra est une suite collaborative comprenant une solution serveur ainsi qu’un certain nombre d’applications :

Webmail Calendrier partagé avec gestion de contacts Des extensions pour relier Zimbra à d’autres clients de

messagerie (Outlook, Thunderbird…)

Yahoo s’est surtout intéressé à Zimbra Desktop qui est une RIA offrant un webmail, un calendrier et un système de gestion de contacts avec la possibilité de travailler en mode déconnecté.

Zimbra : présentation


Zimbra Desktop : schéma (1/2)


Jetty : un serveur HTTP et un moteur de servlet 100% implémenté en java

Prism : navigateur web léger dont le moteur de rendu est fondé sur celui de Firefox

Derby : base de données de petite taille (2MB) appartenant au projet Apache et totalement implémentée en java.

Zimbra Desktop : schéma (2/2)


Zimbra Desktop : retour au schéma


Zimbra met à disposition un toolkit AJAX Cependant, il ne possède pas de librairies

pour le mode « déconnecté » Zimbra Desktop est totalement gratuite,

excepté sa licence commerciale qui est payante.

Communauté active (notamment dans son forum)

Des informations parfois difficiles à trouver surtout en ce qui concerne son implémentation du mode « déconnecté »

Zimbra Desktop : conclusion


Les applications web déconnectées utilisant Gears fonctionnent sans serveur HTTP local.

L’API Gears est composée de 3 modules :

◦ Un serveur local (LocalServer)

◦ Une base de donnée SQLite qui stocke les données sur le poste client.

◦ Un « WorkerPool » qui facilite la synchronisation des données.


Toute l'application dans un cache

LocalServer◦ Il remplace le serveur HTTP distant.

◦ Il met dans le cache de Gears (différent de celui du navigateur) les ressources utilisées en déconnecté (DB SQLite).

◦ Il stocke l'ensemble des éléments de l'application - pages HTML, bibliothèques Javascript, images, feuilles de style (CSS), etc - sur le poste client.

◦ Il intercepte les requêtes HTTP de l'application lorsqu'elle fonctionne en mode déconnecté.


Une base de données locale

La base de données locale s'appuie sur le moteur SQL open-source SQLite.◦ Stocke localement les données téléchargées par

l'utilisateur lorsque celui-ci est connecté.◦ Une base de données hébergée sur le serveur distant

peut être copiée intégralement ou partiellement dans la base de données locale.

◦ En mode déconnecté, c'est la base de données locale qui est utilisée par l'application.

◦ Un moteur de synchronisation se charge de réconcilier les données lorsque l'utilisateur se reconnecte.


Synchronisation des données

Les données entre le serveur et le client ne sont plus synchronisées automatiquement dans les cas suivants :◦ Modification de données hors-ligne◦ Données partagées entre plusieurs utilisateurs◦ Données provenant d'une source extérieure (exemple : flux

RSS)

Pour résoudre ces problèmes de synchronisation, deux stratégies sont possibles pour les applications Gears :◦ Synchronisation manuelle◦ Synchronisation en tâche de fond


Synchronisation manuelle (manual sync) L'utilisateur décide quand il veut lancer la

synchronisation (usuellement via un bouton):◦ Upload des données locales◦ Téléchargement des données récentes du serveur

La quantité de données à transférer doit rester faible (quelques Mo pour une connexion Wifi).

Cette synchronisation nécessite que l'utilisateur connaisse l'état de la connexion. Il peut également oublier de synchroniser avant de se déconnecter.


La synchronisation s'effectue toute seule Avec la synchronisation en tâche de fond (Background sync),

l'application web se synchronise automatiquement et continuellement :


Des traitements asynchrones en tâche de fond Les synchronisations de données nécessitent

souvent du temps. Gears propose un 3ème module : le WorkerPool.

◦ Il élimine les blocages du navigateur dus à l'exécution trop longue de scripts.

◦ Il transforme les traitements Javascript synchrones en processus asynchrones.

◦ Grâce à ce module, la synchronisation des données ou la capture de sites se fait de manière complètement transparente pour l'utilisateur. Toutes ces tâches sont effectuées en arrière-plan.

Détection automatique de la déconnection et affichage

Téléchargement autonome des fichiers requis au fonctionnement de l’application en mode déconnecté



Moteur d'exécution multi-plateforme ◦ Compatible Windows, Linux, Mac OS◦ Moteur et SDK en téléchargement gratuit

Applications bureau riches◦ Véritablement déconnectées

Solution la plus mature à ce jour◦ Air 1.0 en mars 2008

Communauté active et nombreuses applications

Adobe Integreted Runtime (AIR)


Adobe Air et Google Gears: deux philosophies antagonistes ….

Google Gears

Adobe Air


Installation d’un moteur d’exécution◦ Code unique pour toutes les plateformes

Langages◦ ActionScript

Pour les applications Flash ou Flex◦ JavaScript

Pour les applications AJAX◦ Possibilité de les mélanger dans une même

application

Adobe Air: Fonctionnement


Intègre le moteur de rendu Webkit de Safari et Chrome

Flash Player inclus

API variée◦ Son◦ Vidéo◦ Sécurité… et beaucoup d’autres!◦ Détection de connexion automatique

Stockage des données en local en offline puis synchronisation dès le passage online

Adobe Air: Fonctionnalités


eBay Desktop◦ Client bureau

pour le site d’enchères

◦ Permet de faire un listing des objets à vendre offline et de synchroniser ensuite une fois connecté.

Adobe Air: un exemple d’application


Matrice comparativeGoogle Gears Adobe Air

Date de sortie(1ère version stable)

Juin 2007 Mars 2008 (version 1.0)

Version (nov. 2008) 0.4 1.5

Type d’applications visé RIA RDA

Licence BSD EULA (Moteur)/Open Source

Type de technologie Plug-in (~ 1Mo) Moteur d’exécution (~ 13 Mo)

Communauté / SupportGears.google.com

Pré-requis au développement 1 script d’initialisation 1 SDK (~ 12 Mo)

Langages utilisables pour le développement

JavaScript Flash / Flex / JavaScript

Extension DojoX (simplification) non

Exemples Zoho Mail, Google Reader… eBay Desktop, AOL Top 100 Videos…


OBJECTIF : Réaliser une application fonctionnelle simple illustrant quelques unes des possibilités du mode déconnecté.

Phase 3 : Prototypage


Choix du prototype Ajouter à l'application web ZenContact un

mode déconnecté


Objectifs du prototype:

Rajouter un contact à la liste en mode déconnecté

Synchroniser la liste avec le serveur lors de la reconnexion


Design du prototype


Liste des fichiers 4 fichiers jsp pour accéder à la

base de données du serveur index.html: page principal offline.js: contient tout le code

javascript pour utilise l'API Gears

manifest.json: liste des fichiers nécessaires au fonctionnement hors-ligne

gears_init.js: script d'initialisation pour Gears

prototype.js & DatePicker.js: framework pour AJAX


Exemple de code// Create the local database if not exists// 1. One stores all customers (same data as the one stored on the server)// 2. The other one stores the queuing customerfunction initializeDB() { try { db = google.gears.factory.create('beta.database', '1.0'); } catch (ex) { alert('Could not create database: ' + ex.message); } if (db) { db.open('gears'); db.execute('CREATE TABLE IF NOT EXISTS localContact ( id int, firstName

varchar(255), lastName varchar(255), email varchar(255), notes varchar(255), language varchar(255), category varchar(255), active bool, birthDate Date)');

db.execute('CREATE TABLE IF NOT EXISTS datablobs ( id_contact int, status int )'); localServer = google.gears.factory.create("beta.localserver"); }}

Créer le serveur local pour les fichiers du manifest

Créé 2 tables pour la gestion des contacts dans la base SQLite


Prototype final: démonstration


Problèmes rencontrés Difficultés de debuggage avec le Javascript Pas de gestion de synchronisation

concurrente des contacts Détection de la connexion difficile à

maitriser Intégration de l'API Gears à Wicket assez

compliquée Récupération de la page principale de

ZenContact et recodage de toutes les fonctions metiers et ajout des JSPs.


But◦ Obtenir une version Adobe Air de l’application

ZenContact ayant des fonctionnalités offline similaires à celles de l’application codée avec Google Gears

Deux méthodes possibles◦ « à la main »◦ « avec les outils de développement »

Prototype complémentaire avec Adobe Air


Méthode 1: « à la main »

Avantages Inconvénients

Code maitrisé de bout en bout

Utilisation d’outils gratuits uniquement

Idéal pour apprendre

Méthode fastidieuse quand le nombre de fichier augmente

Débogage limité Design plus difficile


Quels outils?◦ Dreamweaver CS3

Éditeur de sites web permettant une conception par code et par design direct (What You See Is What You Get )

◦ Extention Adobe Air pour Dreamweaver Plug in développé par Adobe ajoutant le support de Air

à Dreamweaver

◦ FlexBuilder 3.0 IDE basé sur Eclipse pour le développement

d’applications web en Flex (format SWF)

Méthode 2: « avec des outils de développement»


Permet l’utilisation de wizards pour la création du XML de déploiement, du certificat de signature numérique ou du packaging de l’application finale

Extention Adobe Air pour Dreamweaver


Aperçu du prototype


Méthode 2: conclusion

Avantages Inconvénients

Rapide Efficace Facile d’utilisation Adapté à la réalisation

d’applications d’entreprises (beaucoup de fichier inclus dans une même application)

Solutions payantes◦ Dreamweaver: 300 € ◦ Flex Builder: 215 €

Méthode retenue malgré tout◦ Utilisation des versions

d’essai des logiciels pour la réalisation du prototype


En Flex (ActionScipt) uniquement…◦ Avantages: deboggage facile◦ Inconvenient: nouveau langage a maitriser

Utilisation d’un Event Listener pour écouter l’évènement Event.NETWORK_CHANGE

Une fonction fait appel à une URL de test qui autorise le ping du server utilisé.

Le résultat des tests du réseau permet d’activer ou non un drapeau (booléen) appelé networked

Selon la valeur de networked on dirige les données vers la base de donnée SQLlite locale ou distante

Détection du réseau


Un simple double clic suffit…

Installation de l’application


Problèmes rencontrés

Apprentissage de l’ActionScript

Outils payants

Temps limité

Mises à jour concurrentes


OBJECTIF 1 : Conclure l’étude en émettant un avis clair et objectif sur les technologies étudiées.

OBJECTIF 2 : Au regard de l’étude réalisée, envisager l’avenir de ces technologies :

A 1 an. A 3 ans.

Phase 4 : Prévisions & Conclusion


Air et Gears sont les deux solutions les plus exploitables à l’heure actuelle

Mises en œuvre différentes◦ RIA / RDA

Gears, l’outil le plus avancé…


Complet, fiable, évolutif Communauté active Déjà présent dans certaines applications

◦ Récemment Gmail Evolutions rapides Apparition de premiers « framework »

facilitateurs

Gears, un produit « made in Google »


A un an: les prémices◦ Prise de conscience généralisée de l’intérêt du

mode déconnecté◦ Arrivée probable de concurrents (retard)◦ Versions définitives 1.xx …◦ Augmentation de l’activité sur les forums

Prévisions à court terme


A trois ans: la maturité◦ Généralisation du mode déconnecté◦ Technologie Gears incluse dans les outils de

développement Web◦ Gears devrait conserver son avance◦ Abondance de documentation

Prévisions à plus long terme


Une grande importance accordée à la communication.

Un partage des tâches réaliste.

Des livrables partagés.

Organisation au sein de l’équipe


Des réunions « courtes » régulières (au moins 1x/sem.) : les jeudis lors du cours de gestion de projet :

1. Bilan global avec M. BLANC 2. Réunion au sein du groupe

Des réunions « longues » aux moments-clés : Avant la remise des livrables (aux 4 phases donc)

Rédaction systématique d’un compte-rendu « Les paroles s’envolent mais les écrits restent » Utilisé en cas d’absence (cas de Thomas en contrat de

professionnalisation par exemple)

Communication (1/2)


Courriel au sein de l’équipe : Programmation des réunions Résumés des réunions / envoi des CRs Remontée des problèmes

Courriels réguliers à M. ANDRE (tuteur-entreprise) : Au départ (spécifications, cahier des charges…). En cours de réalisation : état d’avancement. Au moment de la remise des livrables : contenu, prise en main.

Contact téléphonique au début de la phase de prototypage (moment critique).

Communication (2/2)


Lucidité : pas ou peu de travail pendant les vacances de Noël / le voyage à Javapolis.

Implication de tous lors des phases « générales » : Prise de connaissance Conclusion

Attribution d’une tâche lors des phases « lourdes » : Approfondissement sur une technologie Prototypage

La personne chargée de la tâche en prend la responsabilité.

Cependant : idée générale de chacun sur le travail des autres.

Gestion de projet : ≈ 2h/sem. réservées pour le chef de projet.

Partage des tâches


Rapport : présentation Powerpoint (en accord avec M. ANDRE).

Partage des sources à l’aide de Google Code (outil spécialisé, gratuit) :

Accès possible depuis l’extérieur. Accès possible en permanence pour M. ANDRE. Permet donc, moyennant quelques règles de bonnes

pratiques, de travailler sur le même document simultanément.

Format des livrables


D’un point de vue organisationnel◦ Véritable gestion de projet◦ Apprentissage de la démarche pour un sujet de

veille technologique

D’un point de vue technique◦ Nouvelles technologies◦ Sujet « brûlant »

Un projet enrichissant…

FinAvez-vous des questions ?

Cédric CHEDALEUX Thomas GUERIN Jérémy SCHOEN Florent WEBER.

Documents

Transcript of Cédric CHEDALEUX Thomas GUERIN Jérémy SCHOEN Florent WEBER.