|
|
Laurent Guérin
Consultant
Sogeti |
|
Laurent Guérin (Sogeti - projet Telosys)
"Notre infrastructure réconcilie l'application avec les contraintes graphiques du client"
Loin des bibliothèques JavaScript qui font fureur, Telosys se présente comme un support de développement d'applications métier hybrides, combinant Ajax et composants graphiques.
20/11/2006 |
|
|
|
JDN
Développeurs. Vous dirigez le projet Telosys, soutenu par le consortium ObjectWeb. Pouvez-vous nous en décrire les grandes lignes ?
Laurent Guérin. L'idée initiale était de fournir un framework global, totalement intégré, autonome, et suffisant pour permettre aux débutants en développement Web avec Java de concevoir des applications métier rapidement. J'entends bien par là des applications d'entreprise à usage intensif, pas des sites dont l'objectif est de proposer une vitrine Web. Notre but premier est de proposer aux outils métier une réelle IHM (Interface Homme-Machine), avec une ergonomie adaptée.
|
|
Telosys n'a pas pour objectif de créer un site vitrine sur le Web." |
|
Pourquoi cet accent sur l'ergonomie ?
L'ergonomie est importante dans les applications métier, car elle rend leur utilisation plus naturelle. Avec notre framework, nous cherchons à retrouver les comportements client/serveur classiques sur des applications Web. Il faut savoir qu'il existe aujourd'hui deux grands types d'applications : celles lourdes à déployer, mais à l'ergonomie prévisible, et celles légères, les applications Internet, mais avec une ergonomie limitée. Avec Telosys, nous voulons marier les deux mondes, concevoir un poste de travail hybride.
Pour ce faire, nous utilisons Ajax comme socle technique entre client léger et serveur. A partir du moment où on échange du XML sur HTTP, on peut viser différents types de postes de travail, léger ou lourd au besoin. Telosys offre cela, et supprime les contraintes de déploiement.
Depuis quand ce projet est-il lancé, et à quel stade de développement se trouve-t-il ?
Nous avons à l'origine extrait Telosys d'un projet important chez un de nos clients, en en faisant un socle technologie capable de répondre à d'autres cas que celui initial.
Il nous semblait en effet judicieux de l'extraire, le rendre générique et retirer les parties spécifiques. Nos clients ont été intéressés, car cela permettait de mélanger applications existantes et Web. Nous avons alors choisi de le diffuser en GPL, pour répondre aux demandes.
Nous sommes conscients que l'on met plus de temps à développer aujourd'hui qu'on n'en mettait avant, aussi ce framework a pour but de renouer avec le niveau de productivité passé. En comparaison avec les environnements historiques, la productivité gagnée se situe entre 20 et 40%.
À l'heure actuelle, le framework est en pré-release 1.0, il est parfaitement utilisable. Nous avons de nombreux prototypes déjà faits, qui nous ont permis de valider les tests de montée en charge. La version 1.0 finale est prévue pour la fin de l'année.
Côté développement, qu'avez-vous prévu pour réellement augmenter la productivité ?
Nous avons travaillé sur deux aspects. Tout d'abord, la partie présentation. Dans une application Web, il y a déperdition de la couche de présentation, surtout avec les interfaces riches à base de DHTML & consorts. Nous proposons donc une bibliothèque de composants graphiques, comparables à JSP Taglibs, et le développeur les positionne dans son écran.
|
|
L'architecture modulable permet de facilement intégrer d'autres briques logicielles, comme Hibernate ou JDO." |
|
Ensuite, la partie serveur, où nous offrons un framework JavaScript orienté Objet, encapsulant la mécanique Ajax. Il se comporte comme un proxy pour un objet distant, et déclenche des actions sur le serveur de façon transparente. Il dispose par défaut d'une quinzaine d'actions stéréotypées préprogrammées, d'un accès SGBD avec une couche de persistance - facilement remplaçable par Hibernate ou JDO, mais suffisante en l'état - qui dialogue avec le serveur pour gérer les contextes-écran.
Notre objectif reste de couvrir le plus de cas d'utilisation standard, et l'utilisateur peut facilement remplacer les comportements par défaut par d'autres plus spécifiques, à l'aide d'une architecture modulaire. Struts, Hibernate, EJB ou services Web peuvent donc facilement s'intégrer.
Telosys semble différencier "l'écran" de la "page Web". Pourquoi cela ?
Simplement, nous nous plaçons d'un point de vue métier, où l'utilisateur reste sur une même page Web pendant plusieurs heures.
L'écran est donc une page Web unique, qui est mise à jour via un dialogue à base d'Ajax. L'utilisateur n'a plus à mettre à jour lui-même, celle-ci se fait à base de menus ou de liens.
En quoi Telosys se démarque-t-il des autres frameworks Ajax existant ?
Telosys dispose d'une intégration complète entre client et serveur. La plupart des framework sont concentrés sur JavaScript, avec des liaisons serveur légères. Avec Telosys, un appel Ajax peut déclencher jusqu'à une action de persistance, et est couplé à la bibliothèque de taglibs. On associe les conteneurs au module serveur, qui va les alimenter. Avec notre intégration, on ne se demande pas si le framework côté client va aller avec le framework serveur ou la couche de persistance : il s'agît d'un framework global, tout s'enchaîne, tout se tient, et on économise ainsi l'empreinte, en disposant d'une bonne montée en charge.
|
|
Ajax est aujourd'hui un choix pertient." |
|
Cette optimisation tient-elle toujours la route avec des composants tiers ?
Si on ajoute un composant tiers, cela n'aura pas de grosse influence, car tout est isolé, chaque composant est extensible, et un écran peut même en utiliser plusieurs. Les interfaces serveur font que tout est très isolé et sans impact du côté de l'appelant. Maintenant, si un paramétrage de brique tierce est mauvais, forcément il y aura un impact...
Faire de l'Ajax devient-il un mode de développement "sérieux"
?
Nous en sommes convaincus. Nous faisons de l'Ajax depuis 2002, et nous connaissons la pertinence de ce type de choix, notamment en ce qui concerne la réactivité des IHM.
Maintenant, les outils sont-ils suffisants ? Notre framework est notre réponse.
Il y a des initiatives pour fédérer Ajax, notamment chez Eclipse, mais ça reste embryonnaire, suite au manque des outils de développement JavaScript.
Comment parez-vous aux problèmes d'implémentation de JavaScript ?
Notre framework est orienté Objet, on a donc un objet qui encapsule les appels natifs. A chaque développement, notre environnement JavaScript est testé sous IE et Firefox. Par ailleurs, le DOM est assez standardisé et implémenté, sauf les appels spécifiques à un navigateur.
Pour le transfert de données,
nous avons étudié JSON, qui est très bien, mais suppose un moteur JavaScript, donc nous préférons travailler en XML pur. Nous évitons les technologies lourdes, pour être le plus léger possible, ce qui n'empêche pas d'intégrer le framework à d'autres technologies, sans les imposer.
Telosys permet de générer du code DHTML ou XUL. Étant Open Source, quelle difficulté y aurait-il à lui faire gérer d'autres types de code, comme du Flash par exemple ?
Nous avons conçu deux générateurs de code, XHTML puis XUL. Le deuxième a pour but de démontrer qu'il n'y avait pas que XHTML. On pourrait effectivement imaginer avoir des générateurs XAML ou Flash sans trop de difficulté, à partir du moment où on peut générer un flux XML.
Pour Flash, on remplacerait carrément notre bibliothèque de taglib pour la remplacer par Laszlo. On peut également imaginer générer du code Java Swing, Java SWT, Delphi... Mais pas de réécriture de générateur déjà existant, nous préférons alors les reprendre via l'architecture modulable...
|
|
Propos recueillis par Xavier Borderie, JDN Développeurs |
|
PARCOURS
|
|
|
|
Laurent Guérin, 43 ans, est responsable du pôle Nouvelles Technologies de Sogeti.
|
|
|
|