JDNet Solutions inaugure une nouvelle série
d'articles consacrés aux idées reçues de l'informatique.
Avec un double objectif: examiner dans quelle mesure les promesses des
technologies ont été tenues et permettre
au plus grand nombre de prendre le train en marche.
"Write once, run anywhere" (codez une
fois, exécutez n'importe où) : le slogan est connu et il
accompagne le langage Java depuis son lancement par Sun. Et, de fait,
lorsqu'apparaît Java sur la scène des technologies Web (en
1995, quelques années après son invention), sa portabilité,
autrement dit la possibilité d'exécuter sans réécriture
des développements Java sur un large éventail de plates-formes,
représente son principal argument de séduction. Rappelons
que pour assurer cette portabilité, Java passe par l'entremise
d'une machine virtuelle: un environnement d'exécution, disponible
sur l'essentiel des plates-formes du marché, et qui prend donc
en charge le traitement du code Java.
Cette "universalité" de Java fait mouche: elle permet
d'enrichir les pages Web alors très statiques d'appliquettes (de
petits programmes) capables de s'exécuter sur les principales machines
du marché. Avec HTML, le Web avait déjà un langage
de description de pages universel ; avec Java, il gagne un langage de
programmation. Un petit miracle en somme. Qui aujourd'hui mérite
cependant d'être nuancée. Pour deux raisons: primo parce
que cette portabilité de Java est devenue plus discutable; secundo
parce que l'intérêt de Java est désormais tout autre.
Java déserte le poste client
Une raison majeure explique ce glissement: si à l'origine on a
beaucoup attendu de Java sur le poste des utilisateurs connectés
au réseau, au final son champ d'action véritable s'est avéré
être avant tout du côté des serveurs. La faute entre
autres aux contraintes des postes clients qui, situés derrière
un firewall ou bien encore disposant d'une connexion à faible débit
au Net, gèrent plus ou moins bien le téléchargement
et l'exécution d'appliquettes Java. Ces contraintes ont conduit
les développeurs à privilégier des applications Web
qui se "contentent" de retourner à l'utilisateur (qu'il
soit au bureau ou à la maison) de strictes pages Web.
Mais Java n'a pas pour autant été abandonné. Bien
au contraire. En quête d'un langage de programmation côté
serveur (pour les traitements donc qui s'exécutent sur les
machines
serveur et non sur le poste de l'utilisateur), les développeurs
ont adopté Java en masse. Pas seulement pour la portabilité
du langage mais aussi pour sa syntaxe (proche d'un autre langage, le C++)
et pour son ancrage dans l'univers des applications Web. Un engouement
qui s'amplifie au fur et à mesure que Sun dessine autour de Java
le "modèle J2EE" (Java 2 Enterprise Edition): un ensemble
de services qui, capitalisant sur Java, standardisent par exemple comment
accéder à une base de données (via l'interface Java
Database Connector, JDNC) ou encore comment générer des
composants Java interopérables (ce qu'on appelle des Enterprise
Java Beans, EJB). Un environnement mis en oeuvre à travers les
serveurs d'applications conformes au modèle J2EE (comme Weblogic
Server de Bea ou Websphere d'IBM).
Du langage à l'architecture
On le comprend, en quelques années, les applications Java ont radicalement
changé de nature: à l'origine conçues par exemple
pour améliorer l'interactivité des pages web et être
exécutées sur le poste de l'internaute, les développements
Java concernent aujourd'hui des traitements plus complexes mis en oeuvre
sur des serveurs. Pour être plus précis d'ailleurs sans doute
faudrait-il parler des développements "Java/J2EE". Et
la portabilité dans tout ça ?
Sun n'a pas fait une croix dessus. Loin de là puisque le modèle
J2EE est aussi élaboré avec ce souci de portabilité:
un développement Java/J2EE devrait ainsi pouvoir s'exécuter
sur toute plate-forme qui se conforme au modèle. Dans les faits,
cette portabilité semble encore très partielle. Logique:
un développement Java/J2EE est plus complexe qu'une appliquette
expédiée à un navigateur Web et le modèle
J2EE connaît des différences d'interprétation d'un
éditeur de logiciels à un autre qui nuisent à cette
portabilité. Cela n'empêche manifestement pas le modèle
Java/J2EE de prospérer. Pour une raison évidente: l'intérêt
du modèle réside moins désormais dans la portabilité
des développements que dans la standardisation du modèle
même. Une standardisation qui permet aux entreprises d'uniformiser,
donc de rationaliser, leurs architectures informatiques. Ainsi que les
compétences associées. Voilà pourquoi aujourd'hui
la qualité première de Java réside moins dans son
caractère multi-plate-forme que dans la standardisation du modèle
qui l'accompagne.
[Cyril Dhenin, JDNet] |