Revue de Presse Xebia

La revue de presse de l’actualité Java/J2EE hebdomadaire proposé par Xebia.

Agilité

• Les bases de Scrum, en 10 minutes, avec le sourire.

RIA

• Native Client de Google et Alchemy d’Adobe
• Spring BlazeDS Integration 1.0.0.M1
• Choisir sa solution RIA

Le coin de la technique

• OpenXava 3.1 est disponible
• Java Persistence API 2.0 Public Draft

Agilité

Les bases de Scrum, en 10 minutes, avec le sourire.

En 2009, je vais tenter de comprendre ce que Xebia raconte dans la partie Agilité de sa revue de presse. Si vous faites cette bonne résolution, alors la vidéo suivante est pour vous ! Hamid Shojaee (Axosoft) résume en 8 minutes les principaux concepts de Scrum.

RIA

Native Client de Google et Alchemy d’Adobe

Google annonce la sortie de Native Client, une technologie permettant d’exécuter du code natif directement dans le navigateur. Le but de Native Client est d’exploiter le processeur et la carte graphique du poste client pour pouvoir mettre en place des applications web plus performantes. Google rassure en disant que cette exploitation ne remettra en cause ni la neutralité du navigateur, ni la sécurité, ni la portabilité des applications sur les différents systèmes d’exploitation.

Il est possible de tester une version expérimentale de Native Client. À noter pour le moment que cette version n’est compatible qu’avec les navigateurs suivants : Firefox, Safari, Opera et Google Chrome; et sur les systèmes d’exploitations suivants : Windows, Mac et Linux qui ont un processeur x86.

Coïncidence ou pas, Adobe a présenté, lors de ses journées Adobe MAX, Alchemy qui offre les mêmes fonctionnalités que Native Client.

Alchemy est un projet d’Adobe Labs permettant d’intégrer du code C ou C++ dans une machine virtuelle ActionScript. Le code C/C++ est d’abord compilé en ActionScript3 dans un swc ou swf. Il peut ensuite fonctionner sur Flash Player 10 ou AIR 1.5, sécurisé par les protections Flash Player.

Quoi qu’il en soit, le but de ces technologies reste le même : faire en sorte que les applications web deviennent plus puissantes. Cela ne devrait donc pas concerner l’informatique de gestion. Mais pour les applications qui demandent beaucoup de ressources, telles que les jeux en ligne par exemple, cela pourrait changer la donne.

Une question reste cependant en suspend. Pourquoi Google a t’il décidé de sortir cette technologie ? Java Applets, ActiveX, Flash, Flex, Air, Silverlight, JavaFX, ce ne sont pas les technologies concurrentes qui manquent. Native Client ressemble d’ailleurs plus à une nouvelle version d’ActiveX cross-browser qu’à une nouvelle technologie RIA au sens Flex ou SilverLight. Certains pensent que cette technologie est le fruit d’un travail indépendant ne répondant à aucune vision technique cohérente à long terme. D’autres, au contraire, pensent qu’il s’agit d’un pas de plus vers un système d’exploitation made in Google. Le débat est ouvert, difficile de s’avancer pour le moment … Une fois de plus, Google est arrivé à faire le buzz autour de ses technologies.

Pour ceux qui voudraient tester Quake made in Native Client, voici le lien ;-)

Spring BlazeDS Integration 1.0.0.M1

Nous en parlions la semaine dernière, c’est maintenant officiel, le premier milestone de Spring BlaseDS Integration est maintenant disponible.
Alors à quoi ressemble cette intégration ? Elle vous permettra de mixer les configurations BlaseDS et Spring à votre guise. L’idée est de laisser les configurations statiques d’infrastructure dans le fichier de configuration BlaseDS et d’externaliser le reste dans les fichiers de configuration Spring. Cette solution devrait donc plaire à tout le monde : les utilisateurs de BlaseDS ne devraient pas être perdus, le mécanisme général restant inchangé ; les utilisateurs Spring s’y retrouveront également avec une configuration standard Spring MVC et Spring Remoting.

Voici quelques détails de cette configuration :

• Seule la configuration de la DispatcherServlet de Spring MVC est nécessaire
• L’exposition du MessageBroker de BlazeDS passe par :
  • la déclaration d’un FactoryBean dans le fichier de configuration XML de Spring MVC : MessageBrokerFactoryBean
  • le routage des requêtes de la DispatcherServlet vers le MessageBroker via la configuration d’un HandlerMapping
• À la manière de Spring Remoting, il ne vous reste plus qu’à exposer vos services Spring au MessageBroker avec la configuration d’un nouveau type d’Exporter : le FlexRemotingServiceExporter

Même si nous n’avons pas encore testé cette solution, cette intégration aussi simple qu’élégante rapproche sans conteste les développeurs Java au développement d’applications Flex.

Choisir sa solution RIA

Les solutions RIA sont de plus en plus nombreuses et il devient difficile de trancher catégoriquement pour l’une ou l’autre lors du démarrage d’un projet. Très souvent, une librairie est choisie par sa côte de popularité alors qu’elle ne correspond pas forcément au besoin client.
Au final, l’énergie dépensée pour apprendre, utiliser et adapter ces widgets/actions/effets dans le projet se révèle très coûteuse en temps, en maintenance…

Robbie Cheng (développeur principal de ZK Mobile pour Android) éclaircit nos esprits avec l’article How to Choose an RIA Solution sur Sys-Con avec un Top 10 des critères architecte et manager à prendre en compte lors du choix de sa solution.

Sans surprise, côté architecte, on se retrouve avec :

• de nombreux widgets, simples, des fonctionnalités comme le lazy loading ou le drag & drop, des pop-up…,
• facilité de développement,
• parfaite intégration dans l’entreprise,
• sécurité et scalabilité,
• et bien évidemment multiplateforme.

Côté manager, les besoins ne sont pas les mêmes :

• solution standard ? utilisée par d’autres projets ? Open Source ?,
• bien évidemment le coût de formation, entre une solution JavaScript et Java il n’y a pas qu’un pas :-) ,
• outils associés à la solution (plugins, éditeur, WYSIWYG…),
• dépendante d’autres librairies / d’autres plugins ?,
• un background solide i.e. qui est derrière la solution ! Adobe, Google, un développeur dans son garage ? Mais aussi un support de qualité, des corrections de bugs et des mises à jour régulières.

Selon tous ces aspects, l’auteur nous donne 4 catégories de solutions RIA / frameworks :

• Snippet : amélioration légère avec quelques effets, des pages plus rapides à l’affichage, des nouvelles petites fonctions de ci de là… avec peu de changement au niveau de l’architecture ou du design. Script.aculo.us et Prototype sont de bons exemples,
• Widget : vous avez dit Web 2.0 ? C’est clairement ce que tout le monde a vu avec l’arrivée de librairies comme YUI ou ExtJS : une nouvelle expérience utilisateur au niveau de l’interface graphique avec des composants travaillés, très beaux, du drag & drop, de l’animation… ces frameworks s’appuient donc sur une libraire de widgets solides,
• Client : réécriture de l’application côté client dans une nouvelle technologie, nouvelle interface utilisateur, amélioration de la productivité mais un gros travail de refonte côté client. Nous parlons bien sûr des GWT, Flex et Cie,
• Full : la solution complète, riche, MVC, patterns de développement, à la fois une nouvelle expérience utilisateur mais aussi une réelle valeur ajoutée pour l’entreprise… mais nécessite des plateformes/technologies spécifiques côté client et serveur. On citera les ZK ou Wicket.

La conclusion sans surprise à la question (alors, laquelle ???) est bien sûr : ça dépend…
En effet :

• tous les projets n’ont pas la même cible d’utilisateur,
• et les technologies passent du Java au XML en passant par du JavaScript, autrement dit les compétences ne sont clairement pas les mêmes d’un framework à un autre.

Alors entre jQuery, ExtJS, GWT et Flex, ce sera à vous et vous seul de choisir !

Le coin de la technique

OpenXava 3.1 est disponible

OpenXava est un ensemble d’outils et de composants destinés à simplifier le développement d’applications Web Java.

OpenXava permet de générer des formulaires CRUD à partir des POJOs et des annotations JPA. Il vous propose également d’intégrer des fonctionnalités avancées : la génération des rapports PDF, exports Excel, formulaire de recherche, tri, impression… Avec OX, vous pouvez aussi créer des applications sophistiquées avec une logique complexe et des IHM avancées.

La nouvelle version 3.1 apporte AJAX dans vos applications générées. Pour ceux qui utilisent déjà OX le passage à la version 3.1 permet « d’ajaxifier » vos applications sans toucher une seule ligne de code.

Le projet est fourni sous licence LGPL.

Plusieurs démos sont disponibles.

Java Persistence API 2.0 Public Draft

La spécification JSR 317: JavaTM Persistence 2.0 est un public draft, comme l’annonce sur son blog la specification lead, Linda Demichiel (Sun Microsystems) : Java Persistence 2.0 Public Draft.

Une entrée précédente de la revue de de presse de Xebia : JPA 2.0, la nouvelle version d’une API bien portante, annonçait l’ajout de l’API Criteria à la version 2 de JPA.

Linda Demichiel décrit sur son blog le fonctionnement possible de cette API Criteria : Java Persistence 2.0 Public Draft: Criteria API.

Celle ci permet de construire des requêtes SQL en Java de manière programmatique. Cette technique présente les intérêts suivant :

• Les requêtes dynamiques sont plus faciles à construire et leurs constructions peuvent dépendre de données évaluées à l’exécution
• Les fonctions des IDE permettent d’assister le développeur comme par exemple le refactoring, la complétion

Cependant les requêtes sont plus difficiles

• A optimiser
• A maintenir (plus difficile à lire)

Ces requêtes sont construites à partir d’un object QueryDefinition obtenu à partir d’un EntityManager :

EntityManager em = ... ;
QueryBuilder queryBuilder = em.getQueryBuilder();

Exemple de création de requête sur l’entité Customer :

DomainObject customer = queryBuilder.createQueryDefinition(Customer.class);

En manipulant l’objet JPA DomainObject, on peut charger, par jointure, la relation customer->orders->items:

DomainObject item = customer.join("orders").join("items");

Voici un exemple complet :

DomainObject customer = queryBuilder.createQueryDefinition(Customer.class);
DomainObject item = customer.join("orders").join("items");
customer.where(item.get("productType").equal("printer"))
.select(customer.get("name"));

Comme le fait remarquer Gavin King dans l’article A typesafe criteria query API for JPA, il est dommage de manipuler des chaînes de caractères afin d’obtenir un attribut d’une classe. On perd un des intérêts de l’API Criteria : le refactoring et la complétion fournis par les IDE.

Ainsi, en reprenant l’exemple complet, si l’on renomme l’attribut name de la classe customer en firstName (avec notre IDE préféré), notre IDE sera incapable de changer le requête précédente de customer.get(« name ») à customer.get(« firstName »).