Revue de Presse Xebia

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

Actualité éditeurs / SSII

• Grails 1.1.1 supporté par Google App Engine

Agilité

• SCRUM en vidéo en 5 minutes

SOA

• REST : Le bon et surtout le moins bon …

Le coin de la technique

• Utiliser Selenium Grid avec Hudson
• Une API Criteria pour JCR
• Intégration simple de GWT et Spring
• 8 bonnes pratiques pour améliorer scalabilité et performances

Actualité éditeurs / SSII

Grails 1.1.1 supporté par Google App Engine

Dans une précédente nouvelle, nous avions annoncé la sortie de Google App Engine pour Java et Groovy. Après Struts2, Spring MVC, le support de nombreux frameworks web continue.
Le framework web Grails, basé sur le langage Groovy et développé par l’équipe de Spring est maintenant supporté par App Engine. Des ajustements ont été apportés pour le rendre compatible, d’où la sortie de cette version 1.1.1.. Celle ci apporte aussi des corrections de bugs, dont la liste est disponible ici.
Par ailleurs, un plugin a été développé pour faciliter l’intégration de Grails avec le SDK de App Engine, notamment au niveau du déploiement du serveur web.

L’objectif fixé par SpringSource est que Grails devienne le framework web le plus utilisé avec Google App Engine, d’où les nombreux efforts fournis. Les prochains axes de travail porteront sur l’abstraction de JPA/JDO pour faciliter l’utilisation du data store (base de données) d’App Engine.

Agilité

SCRUM en vidéo en 5 minutes

Tout simplement géniale, cette vidéo fait le tour de la blogosphère SCRUM / Agile : Le retour de 6 mois d’expérience d’une équipe SCRUM.

Tout y est :

• L’équipe.
• Les cérémonies.
• Les artefacts.
• Le fun.

La réalisation très soignée et la BO ne gâchent rien.

A regarder !

SOA

REST : Le bon et surtout le moins bon …

Dans l’article « REST – The Good, The Bad and The Ugly« , publié sur DZone, Arnon Rotem-Gal-Oz propose un éclairage intéressant de ce qu’il y a de bon et surtout de ce qu’il peut y avoir de moins bon lors de la mise en place d’une architecture REST.
On retiendra de cette déclinaison deux travers récurrents dans la mise en œuvre de REST :

• Limiter REST à REST over HTTP : Ce raccourci appauvrit en effet dramatiquement les possibilités que nous offre la mise en place d’une architecture REST
• Limiter REST à l’utilisation du GET et du POST : Ici encore, n’utiliser qu’une sémantique à 2 verbes nous prive de la richesse dont nous pourrions profiter.

Comme pour beaucoup d’autres sujets (les méthodes agiles, les SOA, …), la mise en place d’architectures REST nécessite un changement d’approche et de façon de penser : REST implique une approche orientée ressources qui ne nous est pas naturelle. Il est donc primordial de ne pas bruler les étapes et de faire l’effort du changement avant de pouvoir bénéficier des promesses de REST.

Le coin de la technique

Utiliser Selenium Grid avec Hudson

Depuis 2006, Hudson offre un master / slave » >mode master / slave permettant d’effectuer des builds distribués. Récemment, ce mode de fonctionnement a commencé à être exploité par des plugins, tel que le plugin Hadoop permettant d’utiliser son cluster Hudson pour effectuer des traitements lourds de type MapReduce.

Selenium Grid, d’autre part, est une solution permettant de distribuer un ensemble de tests Selenium sur plusieurs machines, permettant ainsi de ramener leur temps d’exécution à un ordre de grandeur plus propice à l’intégration continue.

Kohsuke Kawaguchi, créateur du projet Hudson, vient d’annoncer la disponibilité d’un plugin Selenium Grid. Outre l’intégration à Hudson, facilitant le démarrage automatisé des tests, ce plugin présente l’intérêt de simplifier la configuration, puisqu’il s’appuie sur l’infrastructure cluster d’Hudson.

Il s’agit là d’une avancée qui devrait permettre de rendre plus accessible et moins coûteuse l’exploitation quotidienne de larges quantités de tests d’intégration. Parmi les perspectives d’avenir pour la pleine utilisation d’un cluster Hudson, on notera également une très intéressante proposition sur le Jira du projet Hadoop visant à créer un distributed JUnit TestRunner.

Une API Criteria pour JCR

Magnolia est un CMS en Java qui repose sur la technologie JCR (Java Content Repository, JSR-170) pour assurer la persistance versionnée des informations qu’il présente.

JCR, dans sa version 1.0, propose deux possibilités pour exécuter des requêtes sur son repository de contenu : XPath, supporté en standard, et SQL, dont le support est défini comme optionnel par la spécification JCR.

Dans ces deux cas, les requêtes se font en mode texte. Dans certains cas d’utilisation, tels que les recherches multi-critères, cela peut amener le développeur à créer une logique de construction de requêtes par concaténation. Avec Hibernate, ce genre de problématique est adressée par l’API Criteria qui rend le développement de ce type de besoin trivial.

Partant de ce constat, les développeurs de Magnolia proposent une librairie utilitaire permettant la construction de requêtes JCR par programmation. Cette librairie repose sur Magnolia mais pourrait être adaptée pour devenir standalone.

Ceci préfigure de ce que JCR 2.0 (JSR-283), actuellement en statut proposed final draft, s’apprête à offrir : les requêtes pourront être définies de manière objet grâce à l’API JCR-JQOM (JCR Java Query Object Model). Apache Jackrabbit, l’implémentation de référence, supporte déjà partiellement JQOM.

Intégration simple de GWT et Spring

Et même super simple selon l’article de Dev Bright qui dans son exemple s’appuie sur le projet gwtrpc-spring (qui nous permet par la même occasion de tester une autre librairie que GWT-SL, la librairie référence des projets GWT actuels). L’article est d’autant plus intéressant qu’il utilise les annotations pour déclarer les services auprès de Spring.

Les services seront accessibles par une URL qui possèdera une extension spécifique qui sera mappée dans le web.xml. Cela évite ainsi une multitude de servlets dans le web.xml. Ici il n’y aura qu’une seule servlet mais qui mappera toutes les extensions de type .rpc.

Le service :

@RemoteServiceRelativePath("myservice.rpc")
public interface MyService extends RemoteService {
   String myMethod(String arg);
}

Le web.xml :

   
      dispatcher
      org.gwtrpcspring.RemoteServiceDispatcher
   
   
      dispatcher
      *.rpc
   
   
      org.springframework.web.context.ContextLoaderListener
   

Pour le fichier de configuration Spring, il suffit d’activer la configuration par annotation et de donner le package à scanner :

Du coup, plus aucune configuration XML, l’annotation @Service finit le travail :

@Service
public class MyServiceImpl implements MyService {
   public String myMethod(String arg) {
      // You impl...
   }
}

En quelques lignes et très peu de configuration, l’auteur a créé une application GWT, Spring, avec annotation et avec un web.xml bindant tous les appels RPC. L’avantage dans cette configuration est que les fichiers XML de configuration n’évolueront pas (sauf ajout de nouveaux packages).

Le projet est récupérable à cette url.

8 bonnes pratiques pour améliorer scalabilité et performances

Wille Faler donne 8 conseils pour optimiser la scalabilité de vos applications.

• Déchargez la base de données : la base de données relationnelles est le plus courant des goulets d’étranglements sur nos applications.
• Utilisez des caches : cacher est un moyen simple d’appliquer le point précédent.
• Cachez des objets complexes : même si des objets ‘à maille fine’ sont stockées, cacher des entités plus complexes permettra de moins solliciter les ressources lors d’une recherche dans le cache, et de ramener plus rapidement une grappe d’objets complète.
• Ne sauvez pas d’état en base : ne doivent persister que les données business (pas d’informations de login, de session…)
• Réfléchissez à la spacialisation : placer les données au plus près de là où elles doivent être utilisées (en utilisant un CDN par exemple)
• Restreignez les accès concurrents aux ressources sensibles : il est plus performant d’adopter une attitude ‘un seul thread à la fois’
• Abusez de l’asynchrone pour fractionner vos process : séparez vos traitements en petites unités, traitées par des workers distincts; afin d’éviter un phénomène d’engorgement généralisé.
• Ne surchargez pas le réseau : sortir de votre runtime applicatif est couteux en temps, limitez donc les échanges avec les systèmes tiers.

Certains diront ‘encore un article de bonnes pratiques performance’… Pour notre part, sorti des grands classiques (base de données, réseaux…), nous avons apprécié deux conseils plutôt originaux : le caching d’entités complexes, et la spacialisation.