Après avoir réalisé une maquette avec Adobe Flex j’ai testé il y a quelques jours la version Beta 2 de Microsoft Expression Blend. Quel est le positionnement de ces technologies aujourd’hui ? Le client léger basé sur les technologies du web (html,css,javacript) a-t-il encore un avenir ? Qu’en est-il de l’architecture service ?
Le coeur de mon métier, c’est le client riche. Avec mon équipe nous nous occupons d’un framework java propriétaire qui fonctionne en client léger dans IE ainsi qu’en mode client lourd (swing). Aujourd’hui je me rends compte qu’il est encore difficile de faire accepter l’évolution de l’architecture qui est en place. Nous passons d’un client lourd installé sur le poste de nos clients à une architecture déployée J2EE dont l’interface fonctionne dans un simple navigateur. Nous avons fait de gros efforts pour que l’application web soit aussi interactive que possible. En quelques sortes, cela fait plus de 2 ans que nous faisons de l’AJAX avant même que ce terme ne soit publié il y a maintenant 2 ans.
Et honnêtement le résultat est là.
Des tableaux éditables qui s’exportent vers Excel ou PDF, des graphiques avec JFreeChart, des blotters de données du marché qui se mettent à jour en temps réel… le tout avec du HTML, du CSS, des Javascripts et des composants HTC. Bref on est au limite de ce que peut faire un navigateur tel qu’IE6 sans aucuns plugins. Mais ça marche !
Aujourd’hui il y a encore quelques blocages qui font que nous avons ressorti le client lourd des cartons (Swing). Il y a aussi un coût plus important pour développer une interface riche web qu’une interface classique car les technologies actuelles (css,html,js,htc…) si l’on peut parler de technologies, ne sont pas très bien maîtrisées ou enseignées.
Ensuite sachez que tout n’est pas rose dans le monde AJAX. Ne vous emballez pas trop vite pour toutes ces librairies javascript comme Scriptaculous ou Prototype. Certes, elles vous font gagner du temps. Mais malheureusement elles ne sont pas toujours exemptes de bugs. Attention aussi au navigateur de Microsoft. Je pense particulièrement à Internet Explorer 6 (avant le SP2) et son moteur javascript. J’ai rencontré 2 fois un problème de fuite mémoire en javascript. Très difficile à identifier.
Pour revenir au débat « client riche/client lourd », je vois 2 soucis: je pense qu’il faut maintenant se tourner vers des technologies plus avancées pour faire un vrai produit fonctionnant dans un navigateur. J’ai testé Adobe Flex2 ainsi que Microsoft Expression Blend. Ces 2 produits sont adaptés pour construire un produit avancé qui fonctionnera en mode client lourd comme en mode client léger. Pour la technologie d’Adobe, Apollo AIR permet de faire fonctionner une application Flex en mode client lourd. Une syntaxe XML permet de définir l’interface, le MXML.
Chez Microsoft, la Beta 2 d’Expression Blend m’a agréablement surpris. Elle permet de construire une application qui fonctionnera avec le .Net framework 3,5. Elle peut fonctionner en client lourd comme en client léger grâce à Silverlight.
Adobe Flex 3 m’a semblé plus pratique au niveau des Layout Manager pour construire mon interface. Il est possible de définir un ensemble de composant et de les sauver dans sa boîte à outil afin de pouvoir s’en resservir. C’est aussi vrai pour Expression Blend. Du côté de Microsoft, l’éditeur est plus puissant. Il est moins facile à prendre en main mais la séparation entre l’interface et la partie dynamique est plus simple que chez Adobe. Je pense qu’il ne faut pas néglier ce que propose Microsoft. Nous arrivons à une solution mature pour développer à la fois en mode client lourd et en mode client léger.
Maintenant réveillons-nous un peu: je ne suis pas entrain de jeter aux orties tout le boulot web, et ce qui se passe derrière le décor. Je pense qu’il faut investir et commencer à regarder sérieusement Adobe Flex et/ou la couche Windows Presentation Framework avec Silverlight de Microsoft. Par contre je ne pense pas qu’il faille jeter l’architecture service J2EE pour autant. Et c’est l’un de mes soucis. On me demande de faire du client lourd. Du vrai client lourd 2-tiers avec la base de données et des services financiers déportés. Pour ma part, ma vision est que l’on devrait conserver un serveur d’application afin d’effectuer un certain nombre de services (profiling, authentification, authorisation…). Sur le serveur d’application, le coeur du produit continue à fonctionner. EJB3 ou pas, peu importe. En conservant une architecture Web+J2EE il reste possible de fonctionner en mode client léger dans un navigateur comme en mode client lourd déporté. Je pense que la méconnaissance de l’architecture J2EE nous conduit aujourd’hui à revenir en arrière, ce qui est vraiment dommage…
Deuxième réflexion: nous avons plusieurs produits. Nous offrons à nos clients une Suite qui regroupe tout ou partie de ces produits. Or si vous pensez en terme de client lourd, il devient rapidement compliqué de construire et livrer le binaire adapté à ce que le client a acheté. Pareil pour ce qui concerne les installations de patches… Avec 6 produits majeurs financiers, je peux vous assurer que vos équipes vont passer leur temps à mettre à jour tel ou tel produit… Mais bon, c’est envisageable.
En conservant une architecture 3 tiers, il est possible facilement d’ajouter ou de retirer tout ou partie d’un produit, car le coeur du produit n’est pas dans le client riche mais déporté sur le serveur d’application J2EE. Par ailleurs on concentrera les efforts sur l’ergonomie, l’interface du client, mais on se contentera d’effecteur des appels vers le serveur pour les traitements…
Voilà c’est tout… ce sont quelques idées qui me trottent dans la tête. L’arrivée des technologies de type client riche va bousculer une nouvelle fois nos connaissances d’architecture. Il faut penser maintenant à ce qui se passe derrière l’écran et la jolie fenêtre animé dans un écran Flex… Pensez-y si vous faites du client riche…
0 no like
