| |
 |
Alexis Moussine-Pouchkine
Architecte Java
Sun Microsystems |
|
Alexis Moussine-Pouchkine
"Mettre de l'Ajax à toutes les sauces n'est certainement pas une bonne idée"
Des frameworks Java masquent l'utilisation du Javascript pour faciliter le déploiement du client riche en entreprise. Un moyen de capitaliser sur les ressources existantes.
13/11/2006 |
| |
|
 |
JDN
Solutions. Que propose Sun en matière de technologies de client riche ?
Alexis Moussine-Pouchkine. Nous disposons de deux réponses différentes en fonction des demandes. La première est liée à l'évolution du navigateur Web. Ajax est une technologie très intéressante, qui repousse les limites du navigateur, mais pose le problème de la maîtrise du Javascript. C'est un langage de script avec des propriétés dynamiques qui, si on le cantonne à du client riche sans l'utiliser pour des transactions, est assez bien adapté.
Reste la problématique de pouvoir tester régulièrement son code. La sortie d'IE 7 par exemple remet en exergue les problèmes de compatibilité entre navigateurs. Si le client riche est capable de masquer et d'encapsuler ce code Javascript, c'est encore mieux et nous le faisons avec Java Server Faces ou JSF.
Comment fonctionne JSF ?
A l'image de Struts, il se présente comme un framework structurant les couches de présentation de l'information comme la navigation d'une page à une autre, la présentation des données, la gestion des évènements
Tout comme Struts, JSF est un framework Java exécuté coté serveur. Celui qui fabrique le composant graphique doit connaître le Javascript mais celui qui l'utilise le manipule sans le voir.
Avec ce système, l'entreprise dispose des bénéfices d'Ajax, comme le rafraîchissement partiel de page, sans les inconvénients, à savoir la manipulation de Javascript et la gestion des compétences.
Sur un tel environnement, est-il aussi rapide et facile de développer une application métier ?
Le coté encapsulation dans un composant est plutôt élégant. Bien entendu, avec JSF il va falloir déployer son application avant de pouvoir la tester mais la compilation peut se faire à la volée de manière à tester l'application rapidement. L'outil de développement, à savoir NetBeans, permet de faire du développement incrémental de manière à voir directement les modifications et ce qu'elles apportent dans la page grâce à une interface Wysiwyg.
Offrez-vous les mêmes fonctions que le code Javascript utilisé dans Ajax ou JSF est-il limité ?
|
|
 Nous travaillons de manière rapprochée avec Dojo pour mieux moduler Ajax" |
|
Nous fournissons exactement les mêmes fonctions. Celui qui va écrire les composants pourra toujours utiliser les frameworks Ajax si nécessaire comme le Dojo Toolkit. Nous travaillons de manière rapprochée avec Dojo, d'ailleurs dans un effort de modularisation. Concrètement, il s'agit de faire en sorte que tout le framework ne descende pas sur une page quand celle-ci est appelée par l'internaute.
En fonction de l'outil utilisé, nous allons au contraire faire descendre une cascade de fichiers qui s'appellent les uns les autres pour exécuter les fonctions nécessaires. Même avec la meilleure des technologies, on peut aboutir à la pire des architectures. Le développeur a donc un rôle, et mettre de l'Ajax à toutes les sauces n'est certainement pas une bonne idée.
Quelle est votre réponse pour travailler sur des clients riches en mode déconnecté ?
C'est la seconde partie de notre offre dont je parlais au début. Une application Web ne sait pas travailler en mode déconnecté. Pourtant, le besoin est là dans les centres d'appels ou pour équiper les forces de ventes mobiles par exemple.
Nous utilisons du Java sur le poste client avec Swing. Le résultat final est assez comparable à Xul, WinForms ou XAML mais écrit en Java et donc portable et bénéficiant d'une forte communauté de développeurs. Cette fois, il ne s'agit que de langage Java. Avec Swing, nous nous rapprochons de Dreamweaver, mais la complexité d'utilisation reste plus grande qu'une simple conception de page Web.
|
|
Swing peut combiner plusieurs services Web pour les aggréger" |
|
Cependant, beaucoup de progrès ont été faits sur les outils d'interfaces homme / machine, notamment par le biais du Wysiwyg de NetBeans que j'évoquais précédemment, et qui s'applique également à Swing. Pour travailler en mode déconnecté, il existe aussi la base Derby chez Apache pour laquelle nous fournissons du support. C'est une petite base de 100 Ko en Java qu'il est possible d'embarquer dans une application Swing.
Qu'en est-il du déploiement d'applications Swing ?
Avec Java Web Start, aucune installation n'est requise sur le poste client. L'utilisateur clique sur un lien à partir d'une page Web pour installer le programme. C'est à l'architecte de préciser s'il souhaite utiliser un serveur d'application ou non, par exemple s'il se connecte à une base de données Web.
Il peut également faire du mashup, c'est-à-dire combiner plusieurs services Web pour les aggréger. Sur le Web, l'application Aerith l'utilise en mélangeant les informations de Google Maps et de Flick'r de manière à pouvoir positionner l'endroit où les photos de l'internaute ont été prises.
Sur quelle base se repose l'interface graphique de Swing ?
Elle est très flexible puisqu'il est possible de faire une interface qui ressemble à Windows, à Mac OS ou à Linux Gnome ou KDE. L'application peut également partir sur une interface complètement nouvelle.
Faut-il nécessairement un serveur d'application pour faire fonctionner Swing ?
Pour Swing, absolument pas, mais JSF est une brique d'un serveur d'application et il aura à communiquer avec. Cependant, il existe une grande variété de serveur d'applications Java. J'en citerais 4 qui sont Open Source : Glassfish de Sun, JBoss de Red Hat, Jonas d'ObjectWeb et Geronimo d'Apache.
En serveurs d'applications propriétaires, il existe BEA, IBM, Oracle et SAP notamment. L'environnement de développement NetBeans est également Open Source.
|
| |
Propos recueillis par Yves DROTHIER, JDN Solutions |
|
