Blog Objet Direct

Nous savions déjà que JSF est une plateforme majeure (au sens d’importance comme de maturité) pour faire des applications WEB 2.0 utilisant AJAX. Jusqu’à présent, nous avions deux bibliothèques populaires de composants JSF pour le faire IceFaces de la société IceSoft et RichFaces de JBoss. Et bien cette famille pourrait bien s’enrichir d’un troisième larron :  OpenFaces.

OpenFaces est donc une riche bibliothèque de composants JSF riches couplée à une solution de requêtage Ajax (la double utilisation du mot riche a été faite à dessein ). On y trouve des champs de saisie avec assistance, saisie de date, courbes, camembert, grille de présentation de données, etc… On y trouve aussi – plus original – un composant Agenda qui permet de placer des items sur un calendrier un peu à la manière de Google Agenda.

OpenFaces arrive aussi munie d’une gestion d’événements JavaScript (que l’on peut piloter à l’aide de tags spécifiques). Ces tags peuvent être utilisés aussi bien sur les composants JSF standards que sur les composants d’OpenFaces.  Ils permettent d’invoquer des méthodes du backing bean, de demander le rafraichissement partiel de la page, …

Bien qu’étant déjà assez riche, OpenFaces n’est pas aussi fournie que ses conccurentes. Comme elles, OpenFaces est compatible avec Facelet et Seam.  C’est aussi un produit OpenSource. Un très bon point : OpenFaces sait fonctionner avec d’autres librairies de composants, RichFaces entre autres !

Il reste bien sûr du chemin pour qu’OpenFaces devienne aussi célèbre que RichFaces ou IceFaces. Sa présence confirme cependant la vitalité actuelle de la norme JSF.

• 

Le cloud computing en Java : c’est parti ! Google App Engine, c’est à dire la mise à disposition de l’infrastructure Google pour supporter les applications d’entreprise, peut désormais héberger des applications écrites en Java.

Les API gérées en standard sont : GWT, Servlet, JDO et JPA. Le mécanisme d’identification/authentification de Google (basé sur les adresses mail Google) s’intègre aussi très facilement. Tout cela utilise le JDK 1.6 de SUN.

Déclarer une nouvelle application à partir du site de Google est un jeu d’enfant. Il faut ensuite télécharger un plug-in  et l’installer sur Eclipse. Vous pouvez ensuite définir vos propres applications App Engine (qui sont en fait des applications GWT un peu customisées), les tester sur votre machine. Quand tout fonctionne, vous pouvez la déployer chez Google en 2 clics et un mot de passe. Encore plus simple que de déployer une application sur un Tomcat ou un JBoss local.

Évidemment, Google ne vous affecte qu’un ensemble limité de ressources (1Go de disque cependant). On peut ensuite « louer » de nouvelles ressources (CPU, mémoire, bande passante, disque) directement à partir du site d’administration de votre application. Et ajuster cette dépense au jour le jour. C’est le principe : vous payez ce que vous utilisez.

Tout n’est pas tout rose cependant : GWT demande du savoir faire. La base de données est DataStore, c’est à dire la BDD Google qui n’est pas précisément relationnelle. Ce qui signifie que les interfaces JDO/JPA proposées par Google imposent un certains nombre de contraintes, dont certaines ne sont pas précisément mineures …

Ne nous y trompons pas : cette offre est un événement majeur dans le monde de l’informatique,  si ce n’est pour le monde tout court. La facilité sidérante de déploiement d’une application sur App Engine, le coût très raisonnable et adaptatif, l’immense scalabilité garantie par Google, risquent de secouer très largement notre métier. On peut déjà imaginer que la livraison d’une application « clé en main »  sous la forme d’un déploiement Google App engine,  sera une prestation que nous aurons prochainement à faire. Il faut nous y préparer.

Je ne saurais trop vous conseiller de vous intéresser très très vite à cette technologie/proposition. C’est une opportunité majeure qui s’ouvre devant nous. Le cloud computing, c’est aujourd’hui. Demain il sera déjà trop tard pour se distinguer.

•