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

V.2 Les plateformes de développement pour clients mobiles

La bataille que se livre actuellement Sun et Microsoft au sujet des environnements de développement a un impact direct sur les plateformes embarquées proposées de part et d'autre. D'un coté, Sun propose Java 2 Micro Edition (J2ME) à travers son architecture J2SE, et de l'autre, Microsoft propose Smart Device Extensions (SDE) basé sur sa plate-forme .NET. Si jusqu'au début du millénaire, ce marché était essentiellement représenté par des acteurs très spécifiques de l'embarqué autour de multiples technologies propriétaires, il semble acquis aujourd'hui, à la lueur des évènements, que ces deux leaders mondiaux du logiciel que sont Microsoft et Sun seront à l'origine des prochaines générations de plateformes embarquées. Ce recentrage autour de Java et .NET ne sera pas sans effets. D'une part, l'utilisation de technologies standards et largement adoptées par l'industrie va tendre à réduire les risques d'enfermement technologiques et pérenniser les investissements. D'autre part, cela aura un impact indéniable en termes de réduction des coûts car les outils, les compétences et les architectures matérielles se résumeront à ces deux plateformes maîtrisées. Il va de soi que le mieux placé sur le terrain des outils de développement aura un avantage indéniable sur celui de la production.

A partir de ce constat, nous avons choisi de nous attarder les deux solutions prédominantes du moment. Dans un premier temps, nous nous attacherons à présenter les deux architectures concurrentes, puis nous porterons notre choix sur l'une d'elles que nous présenterons plus en détail.

La mise en place d'une plate-forme technique commune à tous les périphériques est une opération très délicate. Chaque appareil possède des spécificités qui obligent les applications à s'adapter à différentes caractéristiques d'affichage ou de pointage. Microsoft et Sun n'ont pas du tout la même approche concernant ce problème. Si J2ME s'attache à unifier

41

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

par le biais d'APIs les différents types d'appareils, Microsoft préfère proposer un ensemble de briques logicielles dans le cadre de son système d'exploitation embarqué : Windows CE.

La liste suivante démontre la variété des terminaux ciblés par les deux plate-formes :

· Téléphone cellulaire, Smartphone (Nokia, Ericsson, Alcatel, Siemens, ...)

· Assistant personnel, PDA (Palm Pilot, PocketPC, ...)

· Appareil d'imagerie numérique (Caméscope numérique, Appareils photo numérique, ...)

· Appareil automatique industriel (Robot dans une chaîne d'usinage, Affichage embarqué dans les automobiles,...)

· Appareil de paiement, Web Pad, Windows Thin Client, ...

Toute la difficulté de concevoir des technologies pour l'embarqué réside dans cette complexité inhérente à la diversité de l'offre. Nous verrons que cela aura un impact important sur la conception interne des environnements proposés de part et d'autre.

V.2.1 L'architecture Java 2 Micro Edition (J2ME)

V.2.1.1 La problématique multi-plateformes et multi-périphériques de java

Java 2 Micro Edition ou Java ME ou Java Platform Micro Edition est l'édition de la plateforme Java à destination de l'électronique grand public. Cette architecture technique a donc pour but de fournir un socle de développement aux applications embarquées. L'intérêt étant de proposer toute la puissance d'un langage tel que Java associé aux services proposés par une version bridée du Framework J2SE : J2ME. Les terminaux n'ayant pas les mêmes capacités en termes de ressources que les ordinateurs de bureau classiques (mémoire, disque et puissance de calcul), la solution passe par la fourniture d'un environnement allégé afin de s'adapter aux différentes contraintes d'exécution. Cependant, comment faire en sorte d'intégrer la diversité de l'offre à un socle technique dont la cible n'est pas définie à priori ? La solution proposée par J2ME consiste à regrouper par catégories certaines familles de produits tout en proposant la possibilité d'implémenter des routines spécifiques à un terminal donné. L'architecture J2ME se découpe donc en plusieurs couches :

1. Les profils : Ils permettent à une certaine catégorie de terminaux d'utiliser des
caractéristiques communes telles que la gestion de l'affichage, des évènements d'entrées/sorties (pointage, clavier, ...) ou des mécanismes de persistance (Base de données légère intégrée). Ces profils sont soumis à spécifications suivant le principe du JCP (Java Community Process)

2. Les configurations : Elles définissent une plateforme minimale en termes de services
concernant un ou plusieurs profils donnés.

3. Les machines virtuelles : En fonction de la cible, la machine virtuelle pourra être
allégée afin de consommer plus ou moins de ressources

42

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

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

4. Le système d'exploitation : L'environnement doit s'adapter au système d'exploitation

existant (Windows CE, Palm Os, SavaJe, ...)

Cette architecture en couches a pour but de factoriser pour des familles de produits données un ensemble d'APIs permettant à une application de s'exécuter sur plusieurs terminaux sans modification de code.

Les configurations

Une configuration est un environnement d'exécution Java complet constitué de trois éléments :

· Une machine virtuelle Java (JVM) pour exécuter le code Java.

· Le code natif qui compose l'interface avec le système sous-jacent.

· Un assortiment de classes Java exécutables.

Pour pouvoir utiliser une configuration sur une machine donnée, elle doit remplir certaines conditions minimales définies dans les spécifications officielles. Bien qu'une configuration ne fournisse pas un environnement Java complet, l'ensemble des classes du noyau est normalement très petit et doit être enrichi d'autres classes supplémentaires fournies par les profils de J2ME ou grâce à l'implémenteur de configuration. En particulier, les configurations ne définissent aucune classe destinée à l'interface utilisateur.

J2ME définit deux configurations : la CLDC et la CDC

La CLDC

CLDC signifie Connected Limited Device Configuration. Ce qui peut être traduit par configuration limitée pour appareils connectés.

Cette configuration s'adresse aux terminaux légers tels que les téléphones mobiles ou les assistants personnels. Ces périphériques étant limités en termes de ressources, l'environnement classique ne permet pas de respecter les contraintes d'occupation mémoire liées à ces appareils. J2ME définit donc un ensemble d'API spécifiques à CLDC et destinées à utiliser les particularités de chaque terminal d'une même famille (profil). La liste suivante résume l'ensemble de ses caractéristiques :

· Minimum de 160Ko à 512Ko de RAM, processeur 16 ou 32 bits, vitesse 16Mhz ou plus

· Alimentation limitée, prise en charge d'une batterie

· Connexion réseau non permanente, sans fil.

· Interface graphique limitée ou inexistante

Définie par un sous-ensemble de classes Java s'exécutant dans la KVM (KiloByte Virtual Machine), la CLDC s'inscrit donc dans une logique d'économie de ressources avec une KVM de 40 à 80 Ko s'exécutant 30 à 80% moins vite qu'une JVM normale. Il n'y a aucun compilateur Just-In-Time ni même de prise en charge des nombres flottants. La KVM omet

43

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

d'autres caractéristiques importantes telles que la finalisation. Cependant l'assortiment de classes exécutables du noyau ne représente qu'une toute petite fraction des classes du noyau de J2SE - classes de base des paquetages java.lang, java.io et java.util - accompagnées de quelques classes supplémentaires issues du nouveau paquetage javax.microedition.io. Quant au Multi-threading et au Ramasse miettes, ils demeurent supportés.

La CLDC n'intègre pas, non plus, la gestion des interfaces graphiques, la persistance ou les particularités de chaque terminal. Ces aspects ne sont pas de sa responsabilité. La matrice suivante résume les packages et classes présents dans cette couche :

Liste des packages de CLDC

Packages CLDC			Java.io
Fournit la gestion des flux d'entrées/sorties		Java.lang
Classes de base du langage (types, ...)		Java.util
Contient les collections et classes utilitaires		Javax.microedition.io
Classes permettant de se connecter via TCP/IP

Tableau III.1 : Liste des packages de CLDC

Le package javax.microedition.io fait partie des briques non incluses dans J2SE tel qu'illustré dans la figure ci-après. Il gère les connexions distantes ou entrées/sorties réseau.

La CDC

CDC signifie Connected Device Configuration. Ce qui peut être traduit par configuration pour dispositifs connectés. Elle spécifie un environnement pour des terminaux connectés de forte capacité tels que les téléphones à écran, la télévision numérique, etc.

Les caractéristiques de l'environnement matériel proposées par la configuration CDC sont :

· Minimum de 512Ko de ROM et 256Ko de RAM, processeur 32 bits

· Une connexion réseau obligatoire (sans fil ou pas)

· Support des spécifications complètes de la machine virtuelle Java optimisée, compacte et nommée pour l'occasion CVM (machine virtuelle C)

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

44

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

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

Cette configuration s'inscrit donc dans le cadre d'une architecture Java presque complète. C'est la raison pour laquelle elle requière plus de mémoire que la CLDC et un processeur plus rapide. La CDC est en fait un sur-ensemble de la CLDC.

Les profils

Un profil ajoute à une configuration des classes spécifiques d'un domaine afin de combler l'absence d'une fonctionnalité et pour supporter les utilisations spécifiques d'un dispositif. Par exemple, la plupart des profils définissent des classes d'interfaces utilisateurs qui permettent de construire des applications interactives.

Pour pouvoir utiliser un profil, la machine doit satisfaire à toutes les exigences minimales de la configuration sous-jacente ainsi qu'à toutes les exigences rendues obligatoires par les spécifications officielles du profil qui se surajoutent.

Il existe plusieurs profils qui en sont à des stades de développement variables. Le Mobile Information Device Profile (MIDP = profil pour dispositifs informatiques mobiles), premier profil publié, est basé sur la CLDC et conçu pour les applications tournant sur téléphones mobiles et les bips interactifs disposant d'un petit écran, d'une connexion HTTP sans fil et d'une mémoire limitée. Un autre profil plus évolué basé sur la CLDC, le Personal Digital Assistant Profile (PDAP = profil pour assistant numérique personnel), prolonge le MIDP en lui ajoutant de nouvelles classes et caractéristiques permettant de couvrir la gamme des appareils de poche plus puissants. En ce qui concerne les profils de type CDC, le Foundation Profile (FP = profil fondamental) prolonge la CDC en lui ajoutant des classes de J2SE, le Personal Basis Profile (PBP = profil personnel de base) prolonge le FP grâce à l'ajout de classes peu encombrantes d'interfaces utilisateurs dérivées de l'Abstract Window Toolkit (AWT = outil qui permet de générer les fenêtres de dialogue de l'interface utilisateur) et d'un nouveau modèle d'application, et le Personal Profile prolonge le PBP avec le support d'applets et des classes d'interfaces utilisateurs plus encombrantes.

Présentation de MIDP

Le Mobile Information Device Profile (MIDP) définit un environnement d'exécution pour une classe d'appareils référencés sous le nom d'appareils mobiles d'informations (MID = mobile information devices). Cela correspond aux appareils dotés des caractéristiques minimales suivantes :

· Suffisamment de mémoire pour exécuter les applications du MIDP

· Un écran numérique adressable d'au moins 96 pixels de largeur sur 56 pixels de hauteur, qu'il soit monochrome ou couleur.

· Des pavés numériques, un clavier ou un écran tactile.

· La capacité d'établir une liaison sans fils bidirectionnelle.

Il contient des méthodes permettant de gérer l'affichage, la saisie utilisateur et la gestion de la persistance (base de données). Il existe aujourd'hui deux implémentations majeures de profils MIDP : l'une, plus spécifique, destinée aux Assistants de type Palm Pilot (PalmOs) et l'autre, totalement générique, proposée par Sun comme implémentation de référence (RI). Voici un tableau présentant les API liés à ce profil :

45

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

Liste des packages de MIDP
javax.microedition.lcdui	Fournit la gestion de l'interface utilisateur (contrôles, ...)
javax.microedition.midlet	Socle technique destiné à gérer le cycle de vie des midlets
javax.microedition.rms	Base de données persistante légère

Tableau III. 3 : Liste des packages de MIDP

L'API lcdui est chargée de gérer l'ensemble des contrôles graphiques proposés par ce profil. Quant à la gestion des événements, elle suit le modèle des listeners du J2SE avec un CommandListener appelé en cas d'activation d'un contrôle. Pour finir, rms fournit les routines nécessaires à la prise en charge d'une zone physique de stockage.

Toute application MIDP est appelée MIDlet et doit dériver de la classe javax.microedition.midlet. Midlet.

Les Midlets

Les Midlets sont l'élément principal d'une application Java embarquée. Pour bien saisir leur mode de fonctionnement, il suffit de prendre comme analogie les Applets ou les Servlets. Le cycle de vie d'une Applet est géré par un conteneur, en l'occurrence le Navigateur Web, dont le rôle est d'interagir avec celle-ci sous la forme de méthodes de notifications prédéfinies (init(),paint(),destroyed(),...). Une servlet possède les mêmes caractéristiques qu'une Applet excepté le fait que le conteneur est un moteur de servlet (Tomcat, WebSphere, WebLogic, ...). Quant aux Midlets, ils représentent le pendant des Applets et des Servlets pour J2ME avec comme conteneur le téléphone mobile ou l'assistant personnel. Ainsi, en cas de mise à jour d'une application embarquée, un simple téléchargement de code Midlet est nécessaire à partir d'un quelconque serveur. De cette manière, un programme développé pour un profil donné est en mesure de s'exécuter sur tous les périphériques correspondant à cette famille. C'est aussi une manière de découpler le socle technique des applicatifs puisque le seul lien existant entre les logiciels embarqués et le terminal est l'API J2ME.

Une MIDlet connaît trois états dans son cycle de vie : en pause, active et détruite. Une fois créée par le système d'exploitation du téléphone, son état devient "en pause". Puis le système invoque la méthode startApp() qui change l'état en actif. Le retour au premier état a lieu lors de l'invocation de la méthode pauseApp(). Enfin, à tout moment l'exécution de la méthode

46

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

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

destroyApp() conduit à l'état détruit. Nous constatons ainsi que la méthode startApp() peut se voir appelée plusieurs fois au cours du cycle de vie de l'application. Le constructeur de la MIDlet fera donc office de méthode main() pour toutes les tâches ne devant s'opérer qu'une seule fois.