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.
| 
