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
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 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)
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
Liste des packages de MIDP
j avax.microedition.lcdui
|
Fournit la gestion de l'interface utilisateur
(contrôles, ...)
|
|
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 :
|
javax.microedition.midlet
|
Socle technique destiné à gérer le cycle de
vie des midlets
|
|
j avax.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 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.
V.3. L'Architecture Microsoft Windows
Embedded
A travers le temps, l'approche de Microsoft concernant le
monde de l'embarqué a considérablement évolué. De
Microsoft Embedded Visual Tools (eVB et C++), nous sommes passé à
la plate-forme .NET et les différents langages qui l'accompagnent
(C#,
VB.NET, ...). Même
s'il est vrai que l'engouement autour de cet univers des terminaux
légers est allé
croissant dès lors que les PDA et autres
téléphones mobiles ont fait leur apparition, il n'en demeure pas
moins que ce segment de marché a toujours été
délaissé par le géant éditeur de logiciels.
Aujourd'hui, l'offre de Microsoft est essentiellement basée sur son
système d'exploitation embarqué : Windows CE.
Microsoft Embedded propose une approche plus orientée
« système » de l'embarqué. Un constructeur
désireux d'intégrer un environnement Windows dans un terminal
donné, devra extraire les briques logicielles d'une version standard en
fonction des caractéristiques du récepteur. Par exemple, dans le
cas d'un périphérique sans fil, les composants embedded «
wireless » accompagnés des drivers adéquats seront
proposés à l'intégrateur. Lorsque le terminal
nécessite une base de données embarquée, il suffira de
générer une image du Système
d'exploitation prenant en compte cette contrainte. Bref, Microsoft propose une
panoplie de composants systèmes en tout genre et adaptés à
tout type de besoin, charge ensuite à l'intégrateur de
définir sa propre configuration. Cette approche comparée à
Java est donc sensiblement différente.
Avec l'avènement du Framework .NET, la
partie embarquée de l'offre de Microsoft a subi quelques
évolutions majeures. Ainsi, le .NET Compact Framework
(.NET CF) a fait son apparition au sein de l'architecture avec une philosophie
proche de J2ME pour Java : Un ensemble d'API allégés permettant
de répondre aux exigences des périphériques en termes de
ressources. Mais .NET CF se
destine aux plateformes Windows CE.
| 
