Plateformes de services intégrés pour mobiles

Chapitre 7 : Implémentation de la solution

I. Synthèse de la solution

1. Le service de sauvegarde /restauration

Il s'agit en définitive, d'une part d'écrire une midlet capable de synchroniser avec le serveur installé en utilisant le SDK24(*) Funambol JavaME (entendre par là l'API SyncML cité supra), et d'autre part connecter le serveur à une base de données MySQL.

1.1. Création de la MIDlet

Les pré requis sont :

· Ant et Antenna

Ant est un projet open source de la fondation Apache écrit en Java qui vise le développement d'un logiciel d'automatisation des opérations répétitives tout au long du cycle de développement logiciel, à l'instar des logiciels Make.

Antenna fournit un de jeu de tâches Ant adéquates pour le développement d'applications destinées au MIDP. Antenna permet de compiler, prévérifier, packager et exécuter les applications MIDP.

· L'API SyncML : c'est le SDK évoqué plus haut. Il est téléchargeable ici

· L'API Common qui vient en appoint pour l'exécution de certaines tâches telles la sérialisation. Il est disponible en téléchargement ici

Les classes clé de l'API sont :

SyncManager : c'est la classe principale qui contrôle le process de synchronisation et fait appel aux méthodes de la classe SyncSource

SyncConfig : classe utilisée pour instancier le SyncManager avec la configuration du client (URL,login, mot de passe, etc)

Implémentation de SyncSource : c'est l'implémentation de l'interface SyncSource qui est le lien entre le moteur de synchronisation (du côté du serveur) et le client. C'est la source des données du client à synchroniser.

SyncItem : représente l'objet échangé entre le SyncSource et le moteur de synchronisation, il peut transporter n'importe quel type d'information.

1.1.1. Implémentation de notre SyncSource

C'est l'interface entre le client et le moteur de synchronisation. En implémentant cette méthode de la manière la plus convenable pour accéder à la source de données cliente, nous pouvons synchroniser tout type de données à partir du mobile.

Nous pouvons implémenter cette interface directement ou bien nous pouvons étendre la classe abstraite BaseSyncSource , où une partie du travail est déjà réalisée. Les méthodes abstraites à implémenter sont les initXXXitems() pour initialiser les tableaux d'éléments à synchroniser (SyncItem), selon le mode de synchronisation, où XXX peut signifier :

all : il s'agit, dans ce cas, de tous les éléments stockés dans la base de données cliente. Il est utilisé dans le cas d'un slow sync ou d'un refresh from client

new : c'est pour récupérer le tableau des éléments ajoutés chez le client depuis la dernière synchronisation

upd : c'est le tableau des éléments modifiés depuis la dernière synchronisation

del : c'est le tableau des éléments supprimés de la base cliente depuis la dernière synchronisation

Pour gagner de la place en mémoire, il est important que ces tableaux ne contiennent que des informations sur les éléments, sans leur contenu qui pourra être récupéré par un appel à la méthode getItemContent(). Cette méthode est appelée pour chaque élément à synchroniser.

1.1.2. Création du SyncManager

Une instance de SyncManager doit être créée avant d'entamer n'importe quelle synchronisation. Un SyncManager propose un constructeur recevant un SyncConfig en paramètre, qui doit être rempli lors de l'appel avec l'URL, un login et un mot de passe. Les autres informations peuvent être optionnelles.

Le SyncConfig contient aussi la classe DeviceConfig, un simple conteneur d'informations relatives à l'appareil telles que le manufacturier, etc.

Voici, sous forme de diagramme de classe, les relations entre les principales classes de l'API :

Figure 53 : Relation entre les différentes classes de l'API SyncML

1.1.3. Démarrage de la synchronisation

Une fois que nous avons instancié le SyncManager, nous pouvons démarrer la synchronisation par la méthode sync en passant le SyncSource en paramètre. La synchronisation sera lancée avec le mode de synchronisation stocké dans le SourceConfig .

En JavaME, nous exécuterons la synchronisation dans un thread séparément. L'implémentation minimale de la méthode run est la suivante :

import com.funambol.syncml.protocol.SyncML;

import com.funambol.syncml.spds.SyncManager;

import com.funambol.syncml.spds.SyncSource;

import com.funambol.syncml.spds.SyncConfig;

import com.funambol.syncml.spds.SourceConfig

import com.funambol.storage.NamedObjectStore;

import com.funambol.util.Log;

public void run() {

SyncConfig conf = new SyncConfig();

conf.syncUrl = "http://2sisyncml.com";

conf.username = "user";

conf.password = "pass";

SourceConfig sc = ClientStore.loadMySourceConfig();

MySyncSource myss = new MySyncSource(sc);

SyncManager sm = new SyncManager(conf);

sm.sync(sc);

ClientStore.saveMySourceConfig();

}

Dans ce thread MySyncSource représente l'implémentation de notre SyncSource.

1.2. Connecter le serveur à une base de données MySQL

Pour mener à bien cette tâche, il suffit de suivre les étapes suivantes :

installer la version bundle du serveur de synchronisation disponible en téléchargement ici (http://funambol.com/opensource/download.php?file_id=funambol-6.5.14.exe). Le répertoire d'installation sera nommé FUNAMBOL_HOME. Par défaut ce sera C:/Programme files/Funambol/ sous Windows.

· créer sur le serveur MySQL une base de données nommée funambol et un utilisateur

· lancer le script sql install_funambol-ds-server_schema.sql pour créer les tables du DS server

· lancer le script sql install_funambol-foundation_schema.sql

· Arrêter le serveur lorsqu'il tourne

· Modifier les fichiers <FUNAMBOL_HOME>\tools\tomcat\conf\Catalina\localhost\funambol.xml et <FUNAMBOL_HOME>\tools\tomcat\conf\Catalina\localhost\webdemo.xml :

Spécifier les valeurs correctes pour les attributs de l'élément ressource ; c'est-à-dire : <Resource name="jdbc/fnblds" auth="Container" type="javax.sql.DataSource" username="funambol" password="funambol" driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost/funambol" />

· Copier dans le répertoire <FUNAMBOL_HOME>\tools\tomcat\common\lib le MySQL JDBC (c'est-à-dire mysql-connector-java-5.*.*-bin.jar))

2. Le service de billetterie dématérialisée

Dans ce service, il s'agit de mettre en place un portail web pour la consultation des événements et l'achat d'un ticket, en plus d'un portail d'administration, d'un portail USSD et d'un module de validation.

2.1. Front office, back office et paiement

Toutes les pages sont réalisées en php.

Lorsque l'utilisateur veut acheter un ticket, il remplit les formulaires adéquats. Parmi ceux-ci, nous avons le formulaire pour le paiement en ligne. Ces informations seront transmises au partenaire de paiement (PayBox) qui entre en contact avec la banque du client et nous renvoie l'autorisation de faire la transaction.

2.2. Portail USSD

L'achat de ticket à partir des revendeurs nécessite l'apport de l'opérateur. Ce dernier devra ajouter notre service à son serveur d'application USSD. Lors d'un achat, son serveur d'application USSD transmettra à notre serveur MTicket une URL contenant l'ensemble des informations de la transaction.

2.3. Génération et validation du ticket

Le ticket, après avoir été généré en java, sous un format image standard (.jpg), est envoyé au bénéficiaire par l'intermédiaire d'une MMG^25(*) qui permet l'envoi de messages.

A la validation, notre dispositif (Workabout Pro G2) lit le code barres sur le téléphone puis le transmet à notre serveur :

· Soit par SMS grâce à la fonction de téléphonie intégrée.

· Soit par HTTPS via un réseau WIFI si disponible.

Il s'agira pour nous d'éditer un programme en .NET CF capable d'assurer cette transmission.

Figure 54 : Schéma d'ensemble de MTicket

II. Les environnements de développement

Dans le cadre du service de sauvegarde / restauration, nous développons avec l'IDE Netbeans, dans sa version 6.0.1, combiné avec son Mobility pack.

Netbeans est un environnement de développement pour java, placé en open source par Sun sous licence CDDL^26(*). 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.

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^27(*) combiné avec son plugin EclipseME.

Figure 55 : NetBeans mobility pack : vue en mode flow

Figure 56 : NetBeans mobility pack : vue en mode screen

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^28(*) pour le WTK.

Figure 57 : Interface 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^29(*)

· 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^30(*) 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)

· 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)

III. Diagrammes de composants

Le diagramme de composants décrit l'organisation du système du point de vue des modules de code (fichier source, exécutable, bibliothèque). Ce diagramme permet de mettre en évidence les dépendances entre les composants (qui utilise quoi ?) et ainsi de mieux organiser les modules.

Figure 58 : Diagramme de composants MTicket

Figure 59 : Diagramme de composant SOS PIN

IV. Diagrammes de déploiement

Un diagramme de déploiement est une vue statique qui sert à représenter l'utilisation de l'infrastructure physique par le système et la manière dont les composants du système sont répartis ainsi que leurs relations entre eux. Les éléments utilisés par un diagramme de déploiement sont principalement les noeuds (représentation d'une ressource matérielle), les composants, les associations et les artefacts^31(*). Les caractéristiques des ressources matérielles physiques et des supports de communication peuvent être précisées par stéréotype.

Figure 60 : Diagramme de déploiement MTicket

Figure 61 : Diagramme de déploiement SOS PIN

V. Sécurité de la plateforme

1. Service de sauvegarde

L'utilisation de SyncMl et du serveur Funambol sont un gage de sécurité car ils gèrent de nativement la sécurité des transactions.

Dans la phase d'authentification, le serveur envoie au client un message contenant la balise <Chal> qui représente une demande d'authentification (Challenge en anglais) pour les informations auxquelles le client tente d'accéder. Le client doit alors répondre et donner le login et mot de passe dans une balise <Cred> (Credential en anglais).

SyncML peut utiliser l'accès authentifié par le hachage md5. Le client et le serveur échangent leurs identifiants durant la phase d'authentification, retournant un code d'erreur si le processus s'arrête quelque part. La balise <Cred> est utilisée dans le <SyncHdr> pour fixer le type d'authentification qui sera utilisé dans la phase d'authentification. (Il y a le hachage md5, mais aussi l'encodage base64 et d'autres... Il faut donc que le serveur informe le client du type d'authentification utilisée).

Au niveau du serveur, la résolution des conflits de synchronisation (modification d'une même donnée à la fois sur le client et le serveur) revient à la charge du Sync Engine (moteur de synchronisation) et s'effectue en s'appuyant sur les ancres.

2. Service MTicket

La stratégie de sécurité pour ce service est déployée à plusieurs niveaux :

Ø Accès des utilisateurs au portail

L'administrateur se connecte au portail grâce à un login et un mot de passe crypté par hachage MD5. Il peut ainsi procéder aux tâches qui lui sont dévolues (gestion des événements, création d'un nouveau compte pour l'organisateur d'un nouvel événement).

L'organisateur d'événement peut aussi se connecter grâce à son login et son mot de passe. Sa vue est cependant restreinte à son cadre d'organisation, c'est-à-dire qu'il ne peut voir et agir que sur son événement.

Une trace des différentes connexions est toujours gardée par le système.

Ø Paiement en ligne

La sécurité de ce module est totalement assurée par le partenaire de paiement (Paybox). L'ensemble des phases de paiement à réaliser entre l'acheteur et le système est entièrement crypté et protégé. Le protocole utilisé est SSL^32(*) couplé à de la monétique bancaire. Il nous suffit juste de nous mettre en HTTPS^33(*). Dans ce cas, un cadenas fermé apparaît en bas de la fenêtre du logiciel de navigation.

Figure 62 : Navigateur en mode HTTPS

Ø Génération des tickets

Pour s'assurer que le numéro généré pour ce ticket est unique, nous utilisons la fonction uniqid() de php :

string  uniqid ( string   prefix , bool   more_entropy )

Cette fonction retourne un identifiant préfixé unique, basé sur l'heure courante, en micro-secondes. Le paramètre prefix est optionnel mais peut servir à identifier facilement différents hôtes, si nous générons simultanément des fichiers depuis plusieurs hôtes, à la même micro-seconde. Depuis PHP 4.3.1, prefix peut prendre jusqu'à 114 caractères.

Si le paramètre optionnel more_entropy est TRUE , uniqid() ajoutera une entropie "combined LCG" à la fin de la valeur retournée, ce qui renforcera encore l'unicité de l'identifiant.

Sans prefix (préfixe vide), la chaîne retournée fera 13 caractères. Si more_entropy est à TRUE , elle fera 23 caractères. En combinant cette méthode au hachage md5, nous obtenons un code de 32 caractères :

// meilleur, difficile à deviner
$code = md5(uniqid(rand(), true));

Le code généré, ainsi que les autres références du ticket, sont stockés au niveau de la base de données. Un process java plus sécurisé se chargera de parcourir la base et générer les tickets en instance. Une génération avec un script php rendrait l'opération visible au niveau de la page web.

Ø MMS non transférables

Le MMS transmis à un bénéficiaire, après une transaction, ne peut plus être utilisé par un autre appareil mobile, en d'autres termes ce MMS ne peut plus être transféré. Pour cela, l'Open Mobile Alliance (OMA) a spécifié un modèle de gestion des droits [OMADRM^34(*)], dont la version 1 actuelle prévoit trois niveaux de protection :

· Niveau 1, Forward Lock :

- l'usage du contenu téléchargé est illimité (ex : autant d'écoutes que l'on veut)

- le contenu ne peut être transmis.

· Niveau 2, Remise Combinée (Combined Delivery) :

- l'usage du contenu téléchargé est régi par des droits (ex : 3 écoutes maximum).

- les droits d'accès au contenu sont véhiculés avec le contenu

- le contenu ne peut être transmis.

· Niveau 3, Remise Séparée (Separate Delivery) :

- l'usage du contenu téléchargé est régi par des droits (ex : 3 écoutes maximum).

- les droits d'accès au contenu sont véhiculés indépendamment du contenu

- le contenu peut être transmis (sans les droits), possibilité de marketing viral.

On doit néanmoins mettre l'accent sur le fait que tous les terminaux n'ont pas encore intégré de mécanisme de protection des droits. En outre, malgré la normalisation par l'OMA, il existe encore un certain nombre de modèles ayant une implémentation propriétaire des DRM. Cependant, un contenu protégé par un DRM, mais envoyé sur un mobile ne supportant pas ce DRM, est rejeté.

Une seconde version de DRM est prévue par l'OMA, utilisant un cryptage des droits d'accès par une clé publique (PKI).

Pour protéger un fichier par Combined Delivery (pour rendre le message, entre autres, non transférable) celui-ci doit être encapsulé dans une enveloppe de type : application/ vnd.oma.drm.rights+xml

Exemple:

Content-Type: application/vnd.oma.drm.rights+xml

boundary="----123456789"

----123456789

Content-Type: image/jpeg; name="Ticket.jpg"

Content-Transfer-Encoding: base64

Content-Location: Ticket.jpg

/9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8S

etc.etc.etc.etc.etc.etc..etc.etc.etc.etc etc.etc.etc.etc.etc.etc.etc.etc

5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA

----123456789--

Figure 63 : Exemple de MMS non transferable

VI. Captures d'écrans

Figure 64 : Interface d'accueil de SOS PIN - test sur l'émulateur de SUN

C'est à partir de cette interface que l'abonné choisit de sauvegarder ou restaurer ses données, ou bien de paramétrer ce service. Il peut choisir une de ces options en utilisant les touches haut et bas de son téléphone. Pour valider un choix, il peut appuyer sur le bouton situé en haut à droite (option " lancer "). Pour sortir de cet écran, il suffit d'utiliser l'option "sortir".

Cet écran est le front-office de MTicket permettant à un internaute d'acheter un ticket pour un des événements représentés par une image cliquable.

Cet écran du backoffice de MTicket permet d'avoir une vue sur les événements présentés au niveau du front.

Conclusion

2SI compte, à travers cette plateforme, poser les jalons de nouveaux types de SVA.

Il s'agissait, d'une part, d'assurer la pérennité des données stockées dans le téléphone mobile. Ceci a été réalisé, en partie, dans le service SOS PIN avec la sauvegarde des contacts. En perspective, il peut être extensible à une sauvegarde de tous les types de données du mobile en manipulant le système de gestion des fichiers du terminal grâce aux packages adéquats proposés par J2ME.

D'autre part, la plateforme propose de dématérialiser les tickets permettant d'accéder à des services, en particulier des évènements. L'acquisition d'un ticket virtuel est possible désormais à partir du portail web. Il reste cependant la contribution de l'opérateur pour implanter ce service au niveau de son serveur d'application pour le rendre utilisable à partir du réseau de recharge de crédit. L'achat d'un ticket en mode WAP ou par serveur vocal est aussi prévu pour multiplier les modes d'accès au service MTicket.

L'utilisation des codes-barres ouvre, quant à elle, l'ère de la portabilité d'un certain type d'information : ici il s'agissait d'un numéro de ticket. L'intégration des codes barres 2D pourrait largement augmenter ce volume : une chaine d'informations complète sur un objet précis.

La réalisation de cette plateforme, ainsi articulée autour des services pour téléphones mobiles nous a permis d'explorer ce vaste domaine en approfondissant notre connaissance en réseaux pour mobiles, en synchronisation de données et en programmation java pour l'embarqué, trois concepts fondamentaux dans l'informatique d'aujourd'hui.

Bibliographie / Wébographie

* ²⁴ SDK : Software Development Kit

* ²⁵Multimedia Mobile Gateway: plate-forme de messagerie de bout en bout pour les échanges de données mobiles sur plusieurs supports. Elle permet de connecter des réseaux de télécommunication ayant des architectures, des protocoles ou des services différents.

* ²⁶ Community Developement and Distribution Licence

* ²⁷ Un autre IDE open source, extensible, universel et polyvalent, permettant potentiellement de créer des projets mettant en oeuvre n'importe quel langage de programmation.

* ²⁸ Interfaces grafiques associés à des programmes en ligne de commande

* ²⁹ Over The Air Programming (OTA) est une méthode de distribution de logiciels et de mises à jour destinée aux appareils mobiles (téléphone portable, smartphone...). L'avantage d'une installation via OTA est que l'acquisition du programme se fait depuis le réseau sans-fil de l'appareil (WAP, MMS...).

* ³⁰ Java Specification Requests émises par le Java Community Process, qui décrivent les spécifications et technologies proposées pour un ajout à la plateforme Java

* ³¹ composant consommé ou créé durant l'une des étapes du processus de déploiement.

* ³² Secure Sockets Layers -couche de sockets sécurisée- est un procédé de sécurisation des transactions effectuées via Internet

* ³³ http sécurisé : protocole http sécurisé avec SSL

* ³⁴ OMA Digital Rights Management - gestion des droits numériques