Conception d'un service video pour terminaux portables de type smatphone

Conclusion :

J2ME et Microsoft embedded Architecture ont une approche totalement différente dans leur manière d'aborder le développement embarqué. Si Java privilégie l'aspect Multipériphériques et Multi-OS, Microsoft préfère concentrer ses efforts sur Windows CE, son système d'exploitation maison.

Malgré tous ces efforts, force est de constater que la technologie Microsoft ne parvient pas à rivaliser avec J2ME, ce dernier conservant de loin la première place en termes de taux de pénétration sur le terrain des logiciels mobiles. La plupart des grands constructeurs de téléphones portables au premier rang desquels figure Nokia demeurent en effet fidèle à l'infrastructure de Sun. Principal point fort de J2ME : sa portabilité. Une caractéristique qui le rend des plus attractifs pour les fournisseurs de services embarqués, qui cherchent à rendre leurs applications indépendantes des machines sous-jacentes.

Conception d'un service vidéo pour terminaux portables de type Smartphones

47

Conception d'un service vidéo pour terminaux portables de type Smartphones

Mémoire Ingénieur des Travaux des Télécommunications-ESMT-Monjouo M. Rodrigue

De plus, il est à noter qu'il existe des machines virtuelles Java permettant d'exécuter une application J2ME sur Windows CE.

C'est donc presque naturellement que nous optons pour l'architecture J2ME qui repose sur le langage java. Le chapitre suivant montrera comment nous utiliseront les différents modules de cette architecture pour implémenter notre service. Mais avant d'y arriver, revyons les solutions que nous comptons utiliser pour la gestion des données nécessaires au fonctionnement du service.

V.3 Les sources de données

Une source de données est une installation de stockage des données. Elle peut être aussi sophistiquée qu'une base de données complexe, un annuaire ou un entrepôt de données pour une grande entreprise ou aussi simple qu'un fichier avec des lignes ou des colonnes. Une source de données peut être localisée sur un serveur distant ou bien disponible en local sur une machine de bureau.

Une base de données (son abréviation est BD, en anglais DB, database) est une entité dans laquelle il est possible de stocker des données de façon structurée et avec le moins de redondance possible. Ces données doivent pouvoir être utilisées par des programmes, par des utilisateurs différents.

Afin de pouvoir contrôler les données ainsi que les utilisateurs, le besoin d'un système de gestion s'est vite fait ressentir. La gestion de la base de données se fait grâce à un système appelé SGBD (système de gestion de bases de données) ou en anglais DBMS (Database management system). Le SGBD est un ensemble de services (applications logicielles) permettant de gérer les bases de données, c'est-à-dire :

· permettre l'accès aux données de façon simple

· autoriser un accès aux informations à de multiples utilisateurs

· manipuler les données présentes dans la base de données (insertion, suppression, modification)

Les systèmes qui emploient le modèle relationnel pour contrôler la base de données sont nommés SGBDR (système de gestion de base de données relationnel).

De manière basique, tous les SGBD disponibles sur le marché intègrent ces fonctionnalités. D'autres raisons présideront alors au choix de l'un ou de l'autre parmi eux.

Notre étude portera sur deux d'entre eux disponibles en open source.

V.3.1 MySQL

Disponible sou licence GPL sous Linux, Windows, MacOSX, Unix, BSD, MySQL en est à sa version 5.0.15 (beta 5.1). Ses principaux avantages sont :

· Solution très courante en hébergement public

· Très bonne intégration dans l'environnement Apache/PHP

48

Conception d'un service vidéo pour terminaux portables de type Smartphones

Projet CLIPCLAP -Monjouo M. Rodrigue Ing. Télécom

· OpenSource

· Facilité de déploiement et de prise en main.

· Plusieurs moteurs de stockage adaptés aux différentes problématiques. Il présente cependant quelques inconvénients :

· Ne supporte pas entièrement des standards SQL-92

· Support incomplet des triggers et procédures stockées

· Assez peu de richesse fonctionnelle

· Manque de robustesse avec de fortes volumétries

· Pas d'héritage de tables

· Pas de vue matérialisée

· Pas d'ordonnanceur intégré

· Pas de partitionnement

2. Postgresql

C'est un SGBDR fonctionnant sur des systèmes de type UNIX et sur Windows. Ses avantages

sont :

· Open Source et gratuit

· Fiable et relativement performant, tout en restant simple d'utilisation

· Supporte la majorité du standard SQL-92 et possède en plus un certain nombre

d'extensions (Java, Ruby, PL-SQL).

· Très riche fonctionnellement, notions d'héritage de tables, multitude de modules

· Simple d'utilisation et d'administration

· Héritage de tables

Il présente néanmoins quelques inconvénients :

· Sauvegardes peu évoluées

· Supporte les bases de moyenne importance

· Pas de services Web

· Pas de support XML

· Pas d'ordonnanceur intégré

49

Conception d'un service vidéo pour terminaux portables de type Smartphones

Mémoire Ingénieur des Travaux des Télécommunications-ESMT-Monjouo M. Rodrigue

· Pas de vue matérialisée

· Permissions seulement au niveau de la table, pas au niveau de la colonne

Les solutions de synchronisation

La synchronisation offre la possibilité à un terminal de se connecter à un réseau afin de mettre à jour à la fois l'information de l'appareil et l'information du réseau pour que les deux soient identiques et à jour.

Devant la prolifération d'appareils mobiles et de protocoles propriétaires ainsi que la demande croissante d'accès à de l'information en situation de mobilité, les sociétés leader sur le domaine ont compris l'intérêt de créer un langage standard et universel décrivant les actions de synchronisation entre les terminaux et les applications. Elles ont formé un consortium pour sponsoriser cette initiative et pour créer ce langage.

Actuellement, le consortium SyncML a été adopté et incorporé à l'Open Mobile Alliance, un regroupement de plus de 300 sociétés qui supporte plusieurs projets collaboratifs portant sur les technologies et les protocoles.

Le standard SyncML

1. Qu'est ce que SyncML

SyncML ou Synchronization Markup Language est le protocole standard, basé sur XML, de synchronisation de données au travers d'une multitude de réseaux, de plates-formes et de terminaux. SyncML a été démarré en tant qu'initiative en 2000 par de grandes sociétés comme Ericsson, IBM, Palm Inc., Lotus, Matsushita Ltd. (Panasonic), Motorola, Nokia, Openwave, Starfish Software, Psion et Symbian. Leur but était la création d'un langage universel à partir de la myriade de protocoles de synchronisation propriétaires utilisés par les appareils mobiles et de fournir un ensemble complet de fonctionnalités de synchronisation pour les futurs terminaux. Le consortium a sorti la version 1.0 en décembre 2000. Ils ont développé de nouvelles fonctionnalités et résolu les problèmes découverts avec cette version, finalisant le protocole avec la version 1.1 en février 2002.

Le protocole SyncML a été conçu en gardant ces objectifs à l'esprit :

· Garder en cohérence deux ensembles de données

· Être indépendant du transport

· Être indépendant de la donnée synchronisée (PIM, email, fichier, ....) SyncML comprend des commandes client et serveur définies par des DTD.

2. Principes de SyncML

50

Conception d'un service vidéo pour terminaux portables de type Smartphones

Projet CLIPCLAP -Monjouo M. Rodrigue Ing. Télécom

Voici quelques éléments de vocabulaire :

· Client - le terminal mobile, son application et sa base de données locale.

· Serveur - un système distant communiquant avec la base de données du système ou de l'application.

· Modifications - les données dans les champs d'une base de données qui sont modifiées.

· Synchronisation - le client et le serveur échangent des messages SyncML avec des commandes.

· Package - Balises XML conformes à la DTD de SyncML décrivant les requêtes ou actions qui doivent être effectuées par un client ou un serveur SyncML. Un package est un ensemble d'actions à effectuer.

· Message - La plus petite unité de balise SyncML. Les grands packages sont découpés en messages séparés.

· Mapping - Utilisation d'un identifiant intermédiaire pour lier deux informations. Exemple: Disons que 'vert' c'est '5', et '5' c'est bien. Qu'est-ce qui est bien ? Si vous répondez 'vert', vous êtes tombé juste. vous avez réalisé un mapping !

·

3. Messages et Packages

Un message est un ensemble de commandes SyncML transmises (en une seule fois) vers le client ou le serveur. La taille maximale d'un message est définie par la Meta données MaxMessageSize. Si un message à transmettre dépasse cette taille on le découpe en plusieurs messages. On parle alors de Multiple Message in Package. Un package correspond à un ensemble de messages pour effectuer une des étapes de la synchronisation. Les packages sont les suivants: pkg1 = initialisation du client (authentification, échange des devinf, des informations sur les bases à synchroniser), pkg2 = initialisation du serveur, pkg3 = modification côté client, pkg4 = modification côté serveur, pkg5 = mis à jour des données et statuts, pkg6 = mapping des ids client et serveur.

Communication entre client et serveur

SyncML est basé sur XML mais supporte obligatoirement un protocole de transport, par exemple HTTP, OBEX ou WSP. Mais SyncML ne change pas quelque soit le protocole de transport. Une session SyncML est constituée de 4 phases :

1. La phase d'alerte du serveur, qui est optionnelle et peut être considérée comme une
phase de pré-initialisation. Son principal objectif est de permettre au serveur d'alerter le client sur une probable session à démarrer.

2. L'initialisation de la synchronisation qui est un passage obligatoire pour le client et le
serveur avant d'entamer une synchronisation. La première étape est que le client et serveur parlent le même langage, en s'échangeant l'un et l'autres leurs capacités (définies par le

51

Conception d'un service vidéo pour terminaux portables de type Smartphones

Mémoire Ingénieur des Travaux des Télécommunications-ESMT-Monjouo M. Rodrigue

matériel, comme la quantité de mémoire, et le protocole définit par la DTD). La seconde étape est l'identification des bases de données à synchroniser. Ensuite, les deux doivent décider du type de synchronisation. La troisième et dernière partie est l'authentification. Une fois que cette étape à été complétée avec succès, la synchronisation à proprement parler peut commencer.

3. L'échange de données : normalement le client commence par envoyer ses
modifications. Le serveur les reçoit, détecte et résout les conflits avant d'envoyer ses modifications.

4. La phase de finalisation dans laquelle s'effectuent le mapping, la mise à jour des
ancres et l'envoi d'accusé de réception.

ETAPES DE LA COMMUNICATION ENTRE CLIENTS ET SERVEUR

1. Authentification

Le client s'identifie puis se met d'accord avec le serveur sur les principes d'échanges.

2 Adressage

L'adressage est réalisé au travers des balises <Source> et <DocURI>. Un serveur aura une URI du genre http://www.wec-sarl.com/sync et le terminal mobile client aura un numéro d'identification IMEI comme ceci 354101000208403.

3 Mapping ou Correspondance

SyncML est basé sur l'idée que les clients et les serveurs peuvent avoir leur propre méthode pour faire correspondre les informations dans leur base de données. Aussi, les clients et les serveurs doivent avoir leur propre ensemble d'identifiants uniques.

Par gain de place, certains terminaux mobiles ne peuvent accepter, en effet, des id trop longs, ils vont alors définir leur propres id, et envoyer au serveur le mapping à effectuer à l'aide de la balise <Map>. De cette manière, le mobile ne stocke que l'id qu'il a choisi (généralement assez court) et le serveur, lui, stocke les deux, ce qui lui permet de s'adresser au mobile avec l'id que le mobile connait. Le serveur conserve l'ensemble des id indéfiniment.

Dans les futurs échanges, le mobile utilisera seulement l'id qu'il connait, et le serveur se chargera d'effectuer les mappings correspondants.

· Les identifiants locaux uniques (LUID - Locally Unique Identifiers) sont des nombres assignés par le client à une donnée dans la base de données locale (comme un champ ou une ligne). Ce sont des nombres non réutilisables assignés à ces objets par le client SyncML.

· Les identifiants globaux uniques (GUID - Globally Unique Identifiers) sont des nombres assignés à une donnée utilisés dans une base de données distante. Cet identifiant est assigné par le serveur.

Le serveur va créer une table de correspondance pour lier les LUID et GUID ensemble.

52

Projet CLIPCLAP -Monjouo M. Rodrigue Ing. Télécom

Journaux de modification (change logs)

Les change logs sont une manière pour un dispositif (client ou serveur) de déterminer la liste des modifications dans la base depuis la dernière synchronisation

Les ancres

Les ancres servent à savoir si la dernière synchronisation s'est bien passée. Au début de session, le client envoie ses ancres (last et next). Le serveur stocke la next du client. A la fin de la session (s'il n'y pas eu d'interruption), le client met à jour ses ancres (last = next et il incrémente next). Lors de la prochaine session, le client envoie son next et last. Le serveur vérifie que le last du client vaut le next qu'il a stocké précédemment. Si c'est le cas, c'est OK, on continue. Sinon ça ne va pas du tout et le serveur peut forcer une slow sync.

Types de Synchronisation

Dans sa version 1.1, le langage SyncML définit 7 types de synchronisation. La section ci-dessous définit ces différents types:

1. Two-way Sync (Synchronisation bi-directionnelle) Le client et le serveur s'échangent des informations relatives aux données modifiées. Le client transmet les modifications en premier.

2. Slow sync (Synchronisation lente) Le client renvoie l'intégralité de ses données. Le serveur calcule le delta (avec les siennes) et le renvoie au client. Ce type de synchronisation est généralement utilisé lors d'une première synchro, lors d'une interruption, ou lorsque l'une des deux parties le demande.

3. One-way sync, client only (Synchronisation uni-directionnelle, Client uniquement)

Le client transmet ses modifications. Le serveur les accepte puis met à jour les données sans transmettre en retour ses modifications.

4. Refresh sync from client (Synchronisation de mise à jour avec les donnés du client)

Le client transmet sa base de données entièrement au serveur. Le serveur remplace la base de données cible par celle transmise par le client.

5. One-way sync, server only (Synchronisation uni-directionnelle, Serveur uniquement) Le serveur transmet ses modifications au client. Celui ci les accepte puis met à jour ses données locales sans transmettre en retour ses modifications.

6. Refresh sync from server (Synchronisation de mise à jour avec les données du serveur) Le serveur transmet l'intégralité des informations de sa base de données. La base de données du client est entièrement remplacée.

7. Server alerted sync Le serveur télé-commande au client d'initier un des modes de synchronisation présentés ci-dessus. De cette façon, le client est contrôlé à distance par le serveur.

Conception d'un service vidéo pour terminaux portables de type Smartphones

53

Conception d'un service vidéo pour terminaux portables de type Smartphones

Mémoire Ingénieur des Travaux des Télécommunications-ESMT-Monjouo M. Rodrigue

Structure d'un message SyncML

Comme SOAP, il y a deux parties dans un message SyncML, un en-tête <SyncHdr> et un corps <SyncBody>. L'en-tête contient des méta-informations sur la requête comme la base de données cible <Target> et la base de données source <Source>, les informations d'authentification <Cred>, l'identifiant de session <SessionID>, l'identifiant du message <MsgID>, et la déclaration de la version de SyncML <VerDTD>. Le corps contient les commandes SyncML (les statuts des commandes du message précédent, et toutes les autres commandes prévues par SyncML).

4. Le serveur de synchronisation

La synchronisation offre la possibilité à un terminal de se connecter à un réseau afin de mettre à jour à la fois l'information de l'appareil et l'information du réseau pour que les deux soient identiques et à jour.

Convaincus de l'utilité de pouvoir disposer, au besoin, de données à jour sur son mobile, plusieurs éditeurs de logiciels se sont lancés dans la production d'une panacée : un serveur de synchronisation où l'information sur les mobiles serait stockée et centralisée.

On distingue deux grandes catégories de sociétés positionnées sur ce segment : les pure players⁾ d'une part, les éditeurs généralistes d'autre part. Présents sur le marché depuis quelques années déjà, les premiers proposent des solutions généralement basées sur des technologies propriétaires et principalement articulées autour d'environnements de développement et d'exécution Java. Les éditeurs généralistes sont les derniers à explorer ce domaine.

Dans le monde de l'open source, un produit a fait le vide derrière lui : il s'agit de Funambol. Ce serveur est l'implémentation standard, de facto, de l'OMA. Il fournit, en plus du moteur de synchronisation, des API en C++ ou J2ME, pour le développement d'applications clientes. Ces API cachent au développeur toute la complexité de SyncML.

Funambol DS (Data Synchronisation) est contenu dans Tomcat et gère la communication http, la manipulation des sessions, l'échange de données avec le client et beaucoup d'autres fonctionnalités. Son architecture est construite autour du sync engine (moteur de synchronisation). Il transforme les messages SyncML reçus des clients et construit les messages destinés aux clients en guise de réponse. Le moteur de synchronisation permet au développeur de se focaliser sur la source de données à synchroniser avec l'application mobile.

Une application cliente interagit principalement avec deux entités de l'API: le SyncManager et le SyncSource. Le SyncManager est le composant qui gère toute la communication. Il cache la complexité des processus de synchronisation en fournissant une interface simple à l'application cliente. Le SyncSource représente la collection d'objets stockés dans le répertoire local. Il contient la logique métier du client pour découvrir les éléments à envoyer au serveur et pour stocker ceux obtenus à partir du serveur. Le client alimente le SyncSource avec les éléments changés du côté client, tandis que le SyncManager l'alimente avec les données reçues du serveur.

54

Conception d'un service vidéo pour terminaux portables de type Smartphones

Projet CLIPCLAP -Monjouo M. Rodrigue Ing. Télécom

V.4 Choix des outils d'implémentation adéquats

Pour chacun de nos modules, nous aurons à faire des choix technologiques sur les différents segments de sa réalisation. Le service formant un tout, malgré son découpage en modules, un choix sur un segment peut influer sur le choix dans la réalisation d'un autre module.

Netbeans est un environnement de développement pour java, placé en open source par Sun sous licence CDDL. En plus de Java, NetBeans permet également de supporter différents autres langages.

Il comprend toutes les caractéristiques d'un IDE moderne (éditeur en couleur, projets multi-langage, refactoring, éditeur graphique d'interfaces et de pages web).

NetBeans est lui-même développé en Java, ce qui peut le rendre assez lent et gourmand en ressources mémoires.

Netbeans Mobility pack est le plug-in propre à Netbeans qui permet le développement d'applications J2ME reposant sur MIDP en utilisant un Wireless Toolkit. Il permet surtout l'édition graphique des MIDlets. C'est la raison pour laquelle nous avons préféré NetBeans à Eclipse combiné avec son plugin EclipseME.

Le Sun Java Wireless Toolkit (anciennement Wireless Toolkit) ou WTK est l'ensemble des outils proposés par Sun pour développer des applications basées sur une configuration CLDC. Il existe également un Sun Java Toolkit pour CDC.

L'interface graphique est sommaire, il faut un éditeur tiers pour créer le code source, mais toutes les fonctionnalités sont là, c'est pour cela que la plupart des IDE sont des frontends pour le WTK.

Fonctionnalités de WTK

· Toute la chaine de création jusqu'au test via un émulateur.

· Signature des MIDlets

· Gestion des certificats

· Emulation OTA

· Emulation Push registry

· Nokia's Scalable Network Application Package (SNAP) · ...

APIs supportées par WTK

La version 2.5.2 du toolkit, que nous utilisons d'ailleurs, supporte les API suivantes :

· Mobile Service Architecture (JSR 248)

· Java Technology for the Wireless Industry (JTWI) (JSR 185)

· Connected Limited Device Configuration (CLDC) 1.1 (JSR 139)

· Mobile Information Device Profile (MIDP) 2.0 (JSR 118)

· PDA Optional Packages for the J2ME Platform (JSR 75)

· Java APIs for Bluetooth (JSR 82)

· Mobile Media API (MMAPI) (JSR 135)

· J2ME Web Services Specification (JSR 172)

55

Conception d'un service vidéo pour terminaux portables de type Smartphones

Mémoire Ingénieur des Travaux des Télécommunications-ESMT-Monjouo M. Rodrigue

· Security and Trust Services API for J2ME (JSR 177)

· Location API for J2ME (JSR 179)

· SIP API for J2ME (JSR 180)

· Mobile 3D Graphics API for J2ME (JSR 184)

· Wireless Messaging API (WMA) 2.0 (JSR 205) · Content Handler API (JSR 211)

· Scalable 2D Vector Graphics API for J2ME (JSR 226)

· Payment API (JSR 229)

· Advanced Multimedia Supplements (JSR 234)

· Mobile Internationalization API (JSR 238)

· Java Binding for the OpenGL(R) ES API (JSR 239)