Quelques mots sur les interfaces client. Contrairement aux frameworks Service et Persistance, le développement de l’interface Client n’a pas encore trouvé une démarche assurée. Faut-il coller au cycle requête/réponse des http, comme avec Struts (v1 et v2) ou bien s’abstraire de l’implémentation http et utiliser des listeners (à la JSF)? Faut-il créer ses vues avec du XML et du HTML (à la Tapestry), ou bien avec du javascript et du JSon, ou du pur Java qui encapsule la complexité des interfaces client léger (à la Wicket et GWT) ? On est loin du désormais classique Spring/Hibernate.
Elles suivent la tendance générale des technologies , à savoir : simplicité, richesse et recentrage sur ses responsabilités.
Simplicité : Chaque technologie prétend apporter plus de simplicité aux développements. Flex a fait de la simplicité un de ses maîtres mots. Gwt met à disposition la puissance des fonctionnalités ajax au commun des mortels développeur java. Tapestry a été complètement ré-écrit en vu de simplification. Et les JSF 2.0 promettent elles aussi une API plus accessible. Le mantra de Spring et de Rails a été repris par tout le monde.
Html, RIA, Ajax ? gwt, tapestry, silverlight ? En tout cas on aura:
– des frameworks plus simples car mieux spécialisés
– (et donc) des frameworks plus puissants.
– des clients de plus en plus divers : RIA, Ajax, Android. Ecrits en Java, PHP, Rails, Squeak …
– Pour répondre à tout ça : Des services. On n’aura plus « une interface graphique a besoin d’appeler tel ou tel service » mais « une interface graphique appelle un service et agit en conséquence, selon le retour ». Approche Sofea. Oui, je sais, encore un nouveau gros mot. Pour en savoir un peu plus allez voir l’excellent blog The Wisdow of Ganesh.
Lune des ‘idées directrices est : Le client a deux parties dans fonctionnalités : une application semi riche, qui s’initialise, puis qui va récupérer les données sur le serveur. Discussion avec JSon, Rest, Xml web services, whatever… Chaque couche est ainsi bien optimisée.
Du moins, la couche service deviendra vraiment ré-utilisable, par différents clients.
– Multiplicité des clients
– On se branche à des services ou à des ressources distantes. D’où l’importance de pouvoir aisément faire des appels distants, qui soient intégrables avec son « backend ».
En ce sens, on peut présenter deux solutions : une à base de standards et d’appels Rest. Rest devient une solution intéressante car aisée, facile à comprendre et à déployer. L’arrivée de JAX-RS pourrait bien pousser en ce sens d’une simplification et d’une intégration aisée du client (html, javascript, appels ajax par nos librairiezs favorites) et du serveur.
Autre solution RIA : Flex et BlazeDS qui permet de brancher un client Flex à un backend Spring. L’adjonction à Flex de cette solution est un apport essentiel qui pourrait crédibiliser leurs solutions.
On le voit, l’approche RIA fait appel à des outils plus spécialisés, plus puissants mais qui nécessitent de nouveaux outils d’intégration qui sachent se faire oublier. La montée en puissance est réelle mais le danger reste une configuration trop complexe.
Auteur : Gabriel Kastenbaum
Pour aller plus loin sur JAX-RS, voir l’article du Touilleur Express .