Actualité éditeurs / SSII

• Object Grid Mapping, une alternative à Spring Data?
• Un flot de projets pour Hadoop
• JBoss AS 7 est sorti

Actualité éditeurs / SSII

Object Grid Mapping, une alternative à Spring Data?

Il manquait une API haut niveau, à la JPA, pour la manipulation des données dans Infinispan. En tant que preuve de concept, Emmanuel Bernard a tenté une adaptation d’Hibernate Core. Finalement, il s’avère que l’idée peut s’appliquer à de nombreux datastores NoSQL. C’est la naissance d’Hibernate Object Grid Mapping.

Les opérations CRUD sont stables mais la partie recherche par JP-QL est encore balbutiante. Celle-ci devrait cependant se reposer sur des technologies testées sur le terrain : Lucene et Hibernate Search.

JBoss par ce projet souhaite faciliter l’accès aux datastores NoSQL. Ce n’est certes pas sans rappeler Spring Data, l’initiative de VMware. Pour autant, même si ces deux entreprises sont en effet concurrentes et veulent se positionner en tant que facilitatrices, l’approche technique diffère.

JBoss souhaite proposer des implémentations pour une même API : JPA. La question se posera de savoir si JPA est suffisamment flexible pour cela. JPA fournit un vocabulaire commun; encore faut-il que pour chaque store sa sémantique ne varie pas trop.

VMware suit le principe de Spring : une configuration par POJO tout en ayant accès aux particularités de l’implémentation sous-jacente, quitte à avoir une API par datastore si cela se révèle être pertinent. On retiendra également que le but est plus large puisque le projet inclus également le support d’un framework MapReduce : Hadoop.

• http://www.infoq.com/news/2011/07/hibernateogm
• http://jduchess.org/duchess-france/blog/hibernons-avec-emmanuel-bernard/

Un flot de projets pour Hadoop

C’est peut-être la fin de la conquête spatiale mais l’ère du web ne fait que commencer. Et s’il y a bien quelque chose qui monte en flèche, c’est le volume des données.

HDFS vous a permis de stocker de manière distribuée vos données de telle sorte que la perte d’un noeud n’ait pas d’impact.

Avec l’API MapReduce, vous avez pu programmatiquement rapprocher vos traitements de vos données et profiter de la vitesse d’un calcul distribué et parallèle.

Mais voilà, après l’implémentation de plusieurs jobs, il vous a peut-être paru qu’il ne s’agissait pas nécessairement du bon niveau de granularité. Pig ou Hive vous ont alors permis d’exprimer vos requêtes avec un niveau d’abstraction équivalent à SQL pour les bases de données relationnelles.

Le paradigme relationnel est un acquis pour les entreprises. Passer à Hadoop ne signifie par pour autant que vous avez dû changer complètement votre système d’information. Avec HBase, vous avez pu disposer d’une base de données orientée colonne et d’un accès rapide à de petits fragments d’information. Et grâce à Sqoop, vos données relationnelles ont pu être importées dans HDFS.

Enfin Mahout vous a permis d’extraire de ces données une information pertinente en utilisant des algorithmes classiques de recommandation, clustering et classification.

Tous ces composants sont des éléments essentiels pour construire sa propre solution d’informatique décisionnelle que cela soit pour analyser les informations de ses utilisateurs ou pour consolider des sources de données externes. Cependant, au moins un élément manquait : l’orchestration des différentes étapes.

Yahoo a contribué à Oozie, une moteur de processus pour Hadoop. L’approche est classique. Le workflow peut se décrire par une API java ou en XML en utilisant hPDL, un langage similaire à celui utilisé par JBoss Business Process Management (jPBM) : jPDL. Les limitations les plus notables sont l’absence de support pour HBase et Hive.

L’écosystème d’Hadoop est jeune et en pleine expansion. L’ensemble des pièces est en construction et se perfectionne. Pour autant, c’est un écosystème qui a déjà fait ses preuves dans l’industrie comme le montre Yahoo et Hadoop.

• http://www.infoq.com/articles/introductionOozie
• http://yahoo.github.com/oozie/design.html
• http://archive.cloudera.com/cdh/3/oozie/DG_Overview.html

JBoss AS 7 est sorti

Impossible de passer à côté d’une des nouvelles les plus twittées de cette semaine : la sortie de la version finale du serveur d’application de RedHat, JBoss AS 7. Si sa version précédente implementait déjà la spécification Web Profile de JEE 6, il a fallu attendre la sortie de cette dernière release pour avoir l’implementation complète. L’équipe de Dan Allen et Pete Muir a travaillé à fond pour améliorer la vitesse de démarrage et le déploiement en réduisant, selon ce qui est annoncé sur le site, la durée par 10 par rapport à sa version précédente. Dans l’un des forums de JBoss, les meilleurs temps obtenus par ceux qui l’ont déjà testé sont affichés: ils varient entre une et trois secondes.

Quelles sont les bases de cette nouvelle release ?

Légèreté : l’introduction de la modularité via le Modular Services Container (MSC) permettant le chargement des jars en fonction de la demande.
Vitesse de démarrage : les services démarrent de façon concurrente pour profiter au maximum de l’architecture multi-core.

Par ailleurs la dernière version du serveur d’applications de Red Hat offre d’autres avantages tels que :

• Support à la spécification OSGi out-of-the-box
• Simplification de la gestion de la configuration
• Déploiement à chaud des fichiers de configuration
• Orientation à test en facilitant l’utilisation du modèle de composants Arquilian pour le développement des tests d’intégration.

Avec toutes ces caractéristiques, JBoss AS 7 se positionne au même niveau que d’autres serveurs d’application rivaux, notamment la référence de JEE 6, Glassfish 3.1.

http://community.jboss.org/wiki/AS7StartupTimeShowdown

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

Actualité éditeurs / SSII

• Sortie de MongoDB 1.8.1

Le coin de la technique

• Sortie de Jboss Seam 3 : un framework J2EE modulaire
• Twitter: l’asynchronisme est la clef

Actualité éditeurs / SSII

Sortie de MongoDB 1.8.1

Une mise à jour de maintenance de la version 1.8 (notes de version) de Mongo est sortie il y a quelques semaines. Elle apporte:

• Le mode journal lorsque l’on utilise un seul serveur Mongo.
• Support de Map/Reduce incrémental.
• Support des index partiel et couvert.
• Support des recherches géographiques en prenant en compte le rayon de courbure de la terre. Ce point est appréciable pour effectuer des recherches spatiales correspondant à un vrai cercle.

La 1.8.1 fixe quelques régressions liées à la dernière sortie.

Le coin de la technique

Sortie de Jboss Seam 3 : un framework J2EE modulaire

Jboss Seam vient de sortir en version 3.0.
De la même manière que Spring, Seam est un framework « boîte à outils », qui offre un ensemble de modules et d’extensions pour implémenter une solution J2EE complète. La grosse nouveauté de cette release est que le cœur de Seam est fourni par l’api CDI (JSR-299 Java Contexts and Dependency Injection). Ce choix permet au framework d’être totalement modulaire sous forme d’extensions portables. Les modules Seam peuvent être exécutés sur tous les serveurs compatible Java EE 6, mais aussi sur de simples serveurs web, comme Tomcat ou Jetty en utilisant Weld, une implémentation de CDI.
Cette nouvelle approche modulaire se retrouve aussi dans le système de build de Seam, qui utilise le pattern BOM (« Bill Of Materials ») de Maven 3. Les différents modules Seam peuvent alors être construits indépendamment et la mise à jour de la version d’une dépendance est aisée.

Voici la liste des principaux modules Seam:

• Solder: Offre un ensemble d’annotations utiles ajoutant des fonctionnalités supplémentaires à CDI
• Catch: Gestion des exceptions, plus d’infos ici.
• Config: Offre la capacité de configurer les CDI beans via XML.
• Persistence: Gestion de la persistance et des transactions.
• International: Gestion des langues et internationalisation complète de l’application.
• Remoting: Support Ajax coté client et serveur.
• Validation: Fournit des fonctionnalités supplémentaires à Hibernate Validator.
• Rest: Fournit une intégration de JAX-RS.
• Security: Fournit des services d’authentification et d’autorisation.
• Wicket: Intégrer CDI et ajouter quelques apports de Seam au framework Wicket.

Cette orientation modulaire et les nombreuses extensions proposées devraient permettre à Seam d’être un choix intéressant à la fois pour les nouveaux projets J2EE et à la fois pour faire évoluer en douceur des applications existantes. Et ce, que vous utilisiez un serveur d’application ou un simple serveur web.
Cette nouvelle version pourrait faire réfléchir plus d’un qui hésiterait entre le monde « Spring » et le monde « J2EE ».

Par ailleurs, la distribution de Seam vient maintenant accompagnée de SeamForge. C’est un outil en ligne de commande qui peut faire penser à Grails, Rails ou Spring Roo. Il permet de créer rapidement de nouvelles applications, de paramétrer facilement des applications existantes (ajout de JPA, JSF ou CDI), générer des IHM CRUD pour les @Entity… Plus d’infos sur TheServerSide ou dans la documentation.

Pour en savoir plus sur CDI, Oracle Tech Network vient de publier un article intéressant intitulé « Contexts and Dependency Injection in Java EE 6″.

Twitter: l’asynchronisme est la clef

La nouvelle a été relayée partout: Twitter remplace Ruby par Java. En plus, Java est 3 fois plus rapide ! Bref, de quoi regonfler l’égo des développeurs Java attaqués de toute part par des langages « plus rapides », « plus productifs » (et « plus hype » ?)… Qu’en est-il vraiment ?

En fait, plus que tel ou tel langage, Twitter est surtout passé, pour son moteur de recherche, d’un mécanisme de requêtes synchrones à un mécanisme complètement asynchrone agrégeant les résultats de requêtes sur les serveurs back-end. Plus que le remplacement d’un langage par un autre, c’est à une nouvelle architecture que Twitter a donné naissance et c’est elle qui apporte surtout le bénéfice. Le blog officiel des ingénieurs du site donne quelques éléments pour comprendre cette migration. C’est le serveur Netty qui propulse la toute nouvelle architecture. Il a été choisi pour « son API plus claire et une meilleure documentation » par rapport à Jetty ou Mina qui auraient aussi pu fournir les fonctionnalités asynchrones nécessaires. Par ailleurs, l’article décrit comment est déterminé l’ordre d’appel des différents services (en fonction de leurs dépendances) qui constituent alors une séquence de handlers à travers lesquels la requête passe pour être traitée. L’asynchronisme permet alors d’éviter d’avoir des threads se tournant les pouces en attendant les réponses des différents services.

Il est à noter que les traitements asynchrones sensés permettre de meilleures montées en charge ne sont pas l’apanage des serveurs Java: NodeJS et le Javascript sont souvent cités comme étant l’avenir. Un post sur le blog de MetaMarket annonce d’ailleurs que « les architectures LAMP sont mortes » et destinées à être remplacées par NodeJS et Javascript. C’est encore une fois la nature asynchrone du langage qui est mise en avant, ainsi que son adaptation aussi bien côté client que serveur. InfoQ vient d’ailleurs de publier une analyse de ce post qui semble faire un peu de bruit.

Bref, le langage du futur n’est pas connu avec certitude, mais le futur de la montée en charge sera asynchrone ou ne sera pas.

Cet article présente l’utilité de l’EJB Container et la manière de l’utiliser ; il s’appuie pour cela sur l’écriture d’un service et d’une suite de tests exécutables sur Glassfish 3 et sur JBoss 6.

L’EJB Container en théorie

Les EJB 3.1 sont spécifiés dans la JSR 318 dont la version finale a été validée en décembre 2009. Outre les spécifications liées au cœur même des EJB (Session Bean Stateless, Stateful, Message-Driven Bean, Timer Service, Transactions, etc) on trouve un chapitre dédié à un tout nouveau composant : l’EJB Container. Voici un résumé des fonctionnalités et obligations spécifiées :

• Supporter le sous-ensemble EJB Lite de l’API EJB 3.1 dans un environnement de conteneur embarqué ;
• Permettre à un code client (un programme Java standard par exemple) d’instancier un EJB Container qui s’exécute dans sa propre JVM avec son propre classloader ;
• Définir une API permettant de démarrer le conteneur et de récupérer les Enterprise Beans ;
• Fournir un environnement qui supporte les services de base tels que l’injection de dépendances, l’accès à l’environnement, la gestion des transactions, etc.

Pour rappel, le sous-ensemble EJB Lite est composé :

• De la prise en charge des Session Beans Stateless, Stateful, et Singleton ;
• Uniquement des EJB avec interface Local ou sans interface ;
• De la prise en charge des Interceptors ;
• Du support de la sécurité ;
• Du support des transactions.

La JSR 318 n’étant qu’une spécification, l’implémentation de ces fonctionnalités repose sur les éditeurs de serveurs d’applications.

L’EJB Container en pratique

L’EJB Container est le moteur qui va nous permettre de simuler l’exécution de nos EJB comme si nous étions dans le « vrai » conteneur EJB de notre serveur d’applications.

Un cas simple : Hello World !

Pour démarrer, nous allons développer un simple EJB HelloWorldService. Le test consistera à vérifier que la méthode sayHelloWorld() de HelloWorldService renvoie bien « Hello World ».

Voici tout d’abord notre bean HelloWorldService. Sa responsabilité est de retourner la chaîne de caractères « Hello World » lors de l’appel de la méthode sayHelloWorld.

@Stateless
@Local
public class HelloWorldService implements IHelloWorldService {
    public String sayHelloWorld() {
        return "Hello World";
    }
}

Pour tester uniquement cet EJB nous créons un test JUnit qui se charge d’instancier l’EJBContainer et de récupérer notre Bean. Le seul et unique test sera de vérifier que l’appel à la méthode sayHelloWorld retourne bien « Hello World ».

public class HelloWorldServiceTest {
    private static EJBContainer ejbContainer;
    private static IHelloWorldService helloWorldService;
    /***
     * Méthode d'initialisation appelée une seule fois lors de l'exécution
     * des tests de HelloServiceTest.
     * C'est l'endroit idéal pour démarrer l'EJBContainer et récupérer
     * les EJB à tester.
     * @throws NamingException
     */
    @BeforeClass
    public static void init() throws NamingException {
        Map<String, Object> properties = new HashMap<String, Object>();
        properties.put(EJBContainer.MODULES, new File("target/classes.ext"));
        ejbContainer = EJBContainer.createEJBContainer(properties);
        Context ctx = ejbContainer.getContext();
        // le nom JNDI d'un EJB dépend du serveur d'applications utilisé :
        // jboss     : "HelloWorldService/local"
        // glassfish : "java:global/classes.ext/HelloWorldService"
        String helloWorldServiceName = HelloWorldService.class.getSimpleName();
        helloWorldServiceName = isJbossContainer() ? helloWorldServiceName + "/local" : "java:global/classes.ext/" + helloWorldServiceName;
        helloWorldService = (IHelloWorldService) ctx.lookup(helloWorldServiceName);
    }
    /***
     * Méthode de test qui vérifie que nous avons bien récupéré l'EJB
     * HelloWorldService et qu'il est fonctionnel
     */
    @Test
    public void should_say_hello_world() {
        Assert.assertEquals("Hello World", helloWorldService.sayHelloWorld());
    }
    /***
     * Méthode de nettoyage appelée une seule fois après l'exécution de
     * l'ensemble des tests unitaires de HelloServiceTest.
     * C'est l'endroit idéal pour fermer le contexte JNDI et l'EJBContainer.
     * Un bug de JBoss nous contraint à ne pas appeler les méthodes close()
     * sur context et container.
     * @throws NamingException
     */
    @AfterClass
    public static void cleanup() throws NamingException {
        ejbContainer.close();
    }
    private static boolean isJbossContainer() {
        return System.getProperty("jboss.home") != null;
    }
}

Comme convenu par les spécifications, un EJBContainer est instancié grâce à la méthode EJBContainer.createEJBContainer() et fermé par la méthode EJBContainer.close().

Lors de la création de l’EJBContainer il faut préciser le répertoire des classes compilées. Habituellement lorsqu’on utilise Maven, ce répertoire est target/classes.

Malheureusement JBoss 6.0.0 Final contient un bug qui nous oblige à compiler nos EJB dans un dossier suffixé par 4 caractères (par exemple : target/classes devient target/classes.ext). En effet, lors de l’exécution du déploiement du conteneur, les 4 derniers caractères seront tronqués. La prochaine version de JBoss (v6.0.1) corrigera cette anomalie.

Une fois le conteneur récupéré, il suffit de passer par le Context JNDI pour rapatrier ses beans mais attention : le nom JNDI des EJB est différent selon le serveur d’applications utilisé.

Nous avons défini deux profils Maven dans le pom.xml permettant de passer d’une exécution avec Glassfish à une exécution avec JBoss. Pour choisir, il suffit d’ajouter le paramètre -Pglassfish ou le paramètre -Pjboss.

Pour exécuter les tests sur Glassfish il suffit d’exécuter la commande suivante :

mvn test -Pglassfish

Pour exécuter les tests sur JBoss il suffit d’exécuter la commande suivante :

mvn test -Pjboss

Le temps d’exécution total est très différent entre les deux conteneurs :

• Glassfish 3 : 6 secondes
• JBoss 6 Final : 61 secondes

Un cas plus complexe : EJB 3.1 + JPA 2

Pour aller plus loin, nous allons développer un service permettant d’enregistrer des personnes dans une base de données.

Pour manipuler nos entités Person nous créons PersonService qui est un EJB Session Bean Stateless utilisant l’EntityManager de JPA 2.0.

@Stateless
@Local
/**
 * Service permettant la gestion des entités Person avec la base de données
 * Seule la méthode de création est implémentée.
 */
public class PersonService implements IPersonService {
    @PersistenceContext
    EntityManager em;
    /**
     * Crée une nouvelle Person dans la base de données.
     * Méthode transactionnelle :
     *  @TransactionAttribute(TransactionAttributeType.REQUIRED) est implicite
     * @param person une instance de Person
     * @return L'instance de personne persistée, champ Id initialisé
     */
    @Override
    public Person create(Person person) {
        em.persist(person);
        return person;
    }
}

En nous arrêtant là, et à 2 fichiers de configuration près, notre EJB est packageable en JAR et déployable sur les serveurs d’applications JBoss et Glassfish :

• ejb-jar.xml contient la liste de vos EJB. Ce fichier est portable et sera le même quel que soit le serveur d’applications ;
• persistence.xml contient les paramètres de connexion à la base de donnée. La configuration de ce fichier est fortement liée au choix de serveur d’applications. Pour JBoss, Hibernate sera privilégié comme Persistence Provider (persistence.xml), alors que pour Glassfish ce sera plutôt Eclipse Link (persistence.xml).

Écriture et exécution du test

Comme précédemment, nous utilisons un test JUnit pour valider le comportement de PersonService. Pour plus de clarté, l’exemple ci-dessous ne contient pas les méthodes d’initialisation et de fermeture de l’EJBContainer :

public class PersonServiceTest {
    private static IPersonService personService;
    /***
     <strong> Méthode de test qui vérifie la création d'un objet Person dans la
     </strong> base de données. L'instance obtient un identifiant après avoir été
     * persistée par l'EntityManager.
     */
    @Test
    public void should_create_a_person() {
        Person person = new Person("Erich", "Gamma");
        Person createdPerson = personService.create(person);
        assertNotNull(createdPerson.getId());
    }
}

Regardons maintenant comment se comporte notre EJB Container en rajoutant ce nouvel EJB. Tout d’abord, voici les temps d’exécution mis à jour :

• Glassfish 3 : 12 secondes
• JBoss 6 Final : 67 secondes

Le temps d’exécution est toujours beaucoup plus faible en utilisant Glassfish 3 que JBoss 6.

Glassfish a mis 2 fois plus de temps à démarrer à cause des phases d’initialisation dues à l’utilisation de JPA 2.0 (entity manager, création de la base de données, création des tables, mapping des entités, etc). JBoss a quant à lui mis quelques secondes de plus que précédemment, il charge un conteneur entier et ne semble pas vouloir jouer la carte de la légèreté comme le fait Glassfish.

Ce temps total d’exécution est voué à augmenter tout au long du projet, au fur et à mesure des nouvelles entités, des nouveaux services. Une chose est sûre, des outils comme Infinitest — lançant en boucle les tests des EJB — sont à proscrire. Il n’est pas concevable de démarrer des conteneurs qui mettent plus d’une minute à s’initialiser!

Les limites de l’EJB Container

En conclusion, l’EJB Container est un vrai plus dans la testabilité des EJB 3.1. Sa simplicité d’utilisation permet de se reposer facilement sur le conteneur dans nos tests ; il permet même d’envisager le développement dirigé par les tests (TDD). Malheureusement, sa trop grande durée d’initialisation n’encouragera pas à lancer les tests toutes les 5 secondes.

Ce qu’il faut retenir c’est qu’après le démarrage de l’EJB Container, les tests sont exécutés à vitesse grand V. Ils feront partie des tests d’intégration et nous permettront toujours de déceler les régressions et bugs potentiels.

Nous n’avons pas exploré dans cet article les limites techniques dues au sous-ensemble réduit des EJB Lite. Si vous pensez avoir des cas dans lesquels l’EJB Container ne peut pas vous aider, laissez-nous un commentaire .

Code source

L’intégralité de l’exemple est disponible sur Github. Maven et JBoss 6.0. sont nécessaires à son bon fonctionnement.

Pour JBoss, une variable d’environnement JBOSS_HOME pointant vers le répertoire d’installation est indispensable.

Pour en savoir plus sur les EJB 3.1

Le livre Beginning Java™ EE 6 Platform with GlassFish™ 3: From Novice to Professional d’Antonio Goncalves permet d’approfondir les possibilités offertes par EJB 3.1 et Java EE 6. Plusieurs chapitres sont dédiés aux EJB 3.1 (Session Beans, Transactions, Timer Service, etc). Les autres chapitres portent sur JPA 2.0, JSF 2.0 ainsi que sur l’écriture de Web Services SOAP et REST. Ce livre est un guide qui se lit vite et permet de mettre rapidement le pied à l’étrier.

Annexe

Si vous exécutez les tests avec la version 6.0.0 de JBoss AS, attendez-vous à une erreur lors de la fermeture de l’EJB Container. En effet, une anomalie lève une stacktrace lors de l’appel à la méthode ejbContainer.close().

21:04:59,128 ERROR [AOPClassLoaderDeployer] Error during undeploy: vfs:///Users/juliensmadja/Documents/workspace_fluxx/EJBContainer/target/classes.ext/: java.lang.NullPointerException
	at org.jboss.aop.asintegration.jboss5.AOPClassLoaderInitializer.unregisterLoaders(AOPClassLoaderInitializer.java:54) [jboss-aop-asintegration-mc.jar:2.2.1.GA]
	at org.jboss.aop.asintegration.jboss5.AOPClassLoaderDeployer.internalUndeploy(AOPClassLoaderDeployer.java:77) [jboss-aop-deployers.jar:2.2.1.GA]
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.undeploy(AbstractRealDeployer.java:117) [jboss-deployers-spi.jar:2.2.0.GA]
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.undeploy(DeployerWrapper.java:204) [jboss-deployers-impl.jar:2.2.0.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doUndeploy(DeployersImpl.java:1862) [jboss-deployers-impl.jar:2.2.0.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doUninstallParentLast(DeployersImpl.java:1769) [jboss-deployers-impl.jar:2.2.0.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.uninstall(DeployersImpl.java:1724) [jboss-deployers-impl.jar:2.2.0.GA]
	at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:385) [jboss-dependency.jar:2.2.0.GA]
	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:2078) [jboss-dependency.jar:2.2.0.GA]
	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1624) [jboss-dependency.jar:2.2.0.GA]
	at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1472) [jboss-dependency.jar:2.2.0.GA]
	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:756) [jboss-dependency.jar:2.2.0.GA]
	at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:669) [jboss-dependency.jar:2.2.0.GA]
	at org.jboss.dependency.plugins.AbstractController.shutdown(AbstractController.java:270) [jboss-dependency.jar:2.2.0.GA]
	at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.shutdownKernelAndDeployer(AbstractMCServerBase.java:202) [jboss-bootstrap-impl-mc.jar:2.1.0-alpha-5]
	at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.doShutdown(AbstractMCServerBase.java:160) [jboss-bootstrap-impl-mc.jar:2.1.0-alpha-5]
	at org.jboss.bootstrap.impl.base.server.AbstractServer.shutdown(AbstractServer.java:304) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
	at org.jboss.ejb3.embedded.sub.JBossSubmersibleEJBContainer.close(JBossSubmersibleEJBContainer.java:76) [jboss-ejb3-embedded-sub.jar:1.0.0-alpha-4]
	at com.xebia.ejbcontainer.service.HelloWorldServiceTest.cleanup(HelloWorldServiceTest.java:57)

La revue de presse hebdomadaire proposée par Xebia vous souhaite une bonne et heureuse année 2011.

Actualité éditeurs / SSII

• JBoss AS 6 est disponible

Agilité

• Comment impliquer votre client dans un projet ?

Le coin de la technique

• La JSR 310 devient « Project ThreeTen »
• PhoneGap, une autre approche du développement d’application mobile

Actualité éditeurs / SSII

JBoss AS 6 est disponible

Un an après la sortie de la spec finale JEE6 en simultanée avec son implémentation de référence, Glassfish V3, c’est au tour de JBoss AS (pour Application Server) de montrer le bout de son nez en version 6.
JBoss, c’est le poids lourd des serveurs JEE. Poids lourd par la part de marché, car, d’après une récente étude de ZeroTurnaround (ceux de l’excellent JRebel), il représente tout de même près du quart des déploiements de serveurs Java. Mais poids lourd aussi par ses fonctionnalités. Il implémente en effet la totalité de la spécification JEE6 en partie JEE6 dont  le « Web Profile » en totalité (pour visualiser ce que représente Web Profile, ce graphique sur le site de Caucho est représentatif). Nous ne reviendrons pas sur JEE6 déjà largement évoqué ici.
Sur DZone, Mitchell Pronschinske a listé les composant remarquables. Reprenons les un par un:

• JBoss Embedded AS, le serveur est embarquable directement depuis Maven, utile pour les tests
• Single POM Dependency for all the AS runtime, permet comme expliqué ici de fournir une intégration facilitée aux utilisateurs de Maven. Une dépendance unique « tire » toutes les dépendances du serveur embarqué.
• ShrinkWrap, l’API permettant d’assembler aisément des JAR, WAR ou autres EARs
• JBoss Switchboard et JBoss-injection prennent en charge l’injection de ressources JNDI
• HornetQ, la solution de messaging JBoss, récemment vantée pour ses performances
• VFS 3, le système de fichier virtuel uniformise l’accès aux différentes ressources et est censé apporter une vitesse accrue pour lire depuis les fichiers jars
• JBoss OSGi integration
• les Servlets en version 3.0, avec notamment la configuration par annotations, la modularisation grâce aux webfragments et l’exécution asynchrone. Plus de détails sur notre blog
• JPA 2.0, implémenté comme il se doit par Hibernate
• RESTEasy 2.0 qui propose une implémentation de la JSR 311, JAX-RS dont le principe est évoqué sur le Touilleur Express
• Microcontainer 2.2, un peu le coeur du systeme, qui nous est décrit dans une série de 6 articles par Ales Justin de JBoss.
• Le déploiement de la console de management seulement à la demande pour ne pas pénaliser le temps de chargement
• Les EJB 3.1 avec toutes les fonctionnalités apportées par la JSR 318 (Singleton Session Beans, packaging WAR, EJB lights…)
• La stack JBossWS en versions CXF/Metro/Native
• La spécification EE 6 « Web Profile » est bien sûr de la partie, permettant des développement plus légers
• Weld 1.1, implémentation de référence de la JSR 299 autrement connue sous le nom de Context & Dependency Injection

Au final, ce n’est bien sûr pas un serveur sorti de nulle part que JBoss nous sert là. C’est un assemblage cohérent basé sur des composants éprouvés et disponibles pour la plupart depuis un moment. Il sera donc intéressant d’observer les retours des premiers utilisateurs et voir si les prévisions de JBoss ont des chances de se réaliser.

Agilité

Comment impliquer votre client dans un projet ?

c’est la question à laquelle Vikas Hazrati répond dans cet article sur InfoQ.

Selon Vikas, les signes du manque d’engagement de la part d’un client sont :

• peu ou pas de retours sur le travail effectué,
• un retour sur les erreurs tardif, qui révèle généralement que le client teste ou s’intéresse au dernier moment au projet,
• notre interlocuteur n’est pas le bon et nous ne sommes finalement pas en contact avec le client réel.

Ce manque d’implication peut provenir d’une mauvaise formation aux processus de développement agiles ou encore d’un problème de temps ou de ressource disponible. Différentes stratégies peuvent être employées afin de remédier à ce problème d’implication :

• identifier un interlocuteur unique faisant l’interface avec les autres clients,
• utiliser des techniques comme celle des personas afin d’améliorer la compréhension mutuelle,
• planifier les réunions en prenant au maximum compte des contraintes de vos clients,
• motiver votre client en notant ses efforts et en l’encourageant dans cette voie,
• et enfin la communication avec votre client est primordiale, lui garantissant un bonne connaissance de l’actualité du projet, même en phase de développement.

L’implication des clients dans le projet est un élément important de sa réussite et elle ne doit donc pas être négligée. Rappelez-vous, la collaboration avec le client est une des quatre valeurs fondamentales du manifeste agile.

Le coin de la technique

La JSR 310 devient « Project ThreeTen »

La JSR 310, la fameuse JSR « Date and Time API » attendue comme le messie pour remplacer l’implémentation défaillante des dates dans le JDK n’en finit pas d’être retardée. Nous vous en parlions déjà en 2008, puis l’API fut planifiée avec des réserves pour le JDK 7… Aujourd’hui, Stephen Colebourne, le spec lead annonce sur son blog diverses informations.

• tout d’abord, il ne semble vraiment pas satisfait de la façon dont Oracle a pris en main la communauté mais il désire tout de même continuer son travail sur l’implémentation de référence.
• cette implémentation de référence a d’ailleurs maintenant un nom: elle est portée par le projet ThreeTen (ThreeTen, 310… vous voyez le rapport ? ).
• la cible est maintenant Java 8 et non plus Java 7. Il va falloir patienter encore.
• une nouvelle mailing liste, encore bien vide, est en place et un repo SVN est disponible sur Sourceforge.

Une autre particularité est aussi mentionnée et peut faire réfléchir. Stephen indique en effet se réserver la possibilité d’écrire des spécifications pour le projet ThreeTen séparées de la JSR 310. Concrètement, il parle de pouvoir fournir une terminologie commune et un comportement de plus haut niveau pour pouvoir collaborer avec d’autres langages ou librairies comme XML ou SQL. Sur le principe c’est une excellente idée: faciliter la collaboration de Java avec « l’extérieur » en prenant une base solide pour socle semble une bonne chose. Mais il ne faudrait pas que cette nouvelle perspective ne vienne retarder une fois encore le projet… Cela serait vraiment dommageable pour tous ceux qui préfèrent se reposer sur les API standard du JDK plutôt que sur une librairie tierce comme Joda Time (malgré ses qualités) et qui sont en attente de cette implémentation.

PhoneGap, une autre approche du développement d’application mobile

Aujourd’hui, dans le domaine du développement mobile, le choix se résume encore entre développer une application native ou une application Web Mobile. PhoneGap est un framework qui permet le développement d’applications mobiles multi-plateformes en combinant ces deux mondes.

L’approche retenue est de développer votre application en utilisant les technologies HTML 5 et JavaScript. L’accès aux fonctionnalités de la plateforme (système de fichiers, géolocalisation, notifications, appareil photo, accéléromètre, …) s’effectue via des APIs JavaScript. Le framework prend en charge le code de liaison nécessaire, et fournit également un modèle d’application native pour chaque plateforme. Il sert entre autre à démarrer une version embarquée du navigateur web. Le navigateur est donc utilisé comme environnement d’exécution standard. Cette approche est possible car les navigateurs des plateformes iOS, Android, BlackBerry OS et WebOS sont tous basés sur le moteur WebKit. Même si l’expérience utilisateur peut varier entre les plateformes, le résultat reste dans l’ensemble cohérent.

PhoneGap est encore en phase de développement. Les supports des plateformes iOS et Android sont les plus avancés, mais il faut y ajouter les plateformes BlackBerry OS, WebOS et Symbian. C’est, au final, une alternative intéressante au développement natif pour les plateformes mobiles. La dernière version en date (0.9.3) est sortie le 23 décembre.

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.

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

Actualité éditeurs / SSII

• Naufrage pour Google Wave

Le coin de la technique

• Nouvelle architecture de réplication et de sharding pour MongoDB
• Axon, une implémentation Java du pattern CQRS
• L’architecture de Last.fm basée sur HornetQ

Actualité éditeurs / SSII

Naufrage pour Google Wave

Nous l’apprenons sur The H, Google Wave coule et ne sera bientôt plus. Après un peu plus d’un an d’existence, Google a décidé de mettre fin à son expérimentation qui n’aura pas répondu à toutes les attentes qu’elle avait provoqué. Pourtant, nous-mêmes, nous y avons cru ! Basé sur des protocoles ouverts, le système avait de quoi séduire, même si tout le monde se demandait un peu quelles allaient être les applications réelles… Las, les serveurs de Google devraient être fermés l’année prochaine. La firme annonce quand même la mise à disposition future d’outils permettant aux utilisateurs de « libérer leurs données de Wave ». Mais ne nous y trompons pas, même si l’interface graphique colorée ayant donné aux internautes un avant goût de la communication du futur disparaît, il reste quasi-certain que le mécanisme d’échange de données entre serveurs Wave devrait survivre et servir de base à d’autres projets.

Le coin de la technique

Nouvelle architecture de réplication et de sharding pour MongoDB

MongoDB est une base de données orientée documents très populaire ces temps-ci. 10gen l’entreprise Open Source qui en est à la source se montre très active tant sur la communication que le plan technique en apportant des améliorations régulières pour placer leur base de données NoSQL à la hauteur des ambitions qu’on lui prête.
Respectant le planning présenté mi-juin lors du MongoDB Day à Paris, la version 1.6 vient d’être finalisée. Cette release estivale était particulièrement attendue car elle apporte des améliorations majeures sur l’architecture distribuée de MongoDB :

• La réplication était jusqu’alors assurée par une architecture master / slave qui souffrait d’un single point of failure à cause de son nœud master. MongoDB 1.6 introduit la notion de replica set qui est un ensemble de nœuds qui possèderont des replicas d’une même donnée. Une élection de master permet alors de définir un nœud unique qui sera responsable des écritures.
• Le sharding est maintenant production ready dans MongoDB. L’architecture de partitionnement repose sur un ou plusieurs nœud proxy intermédiaire entre les clients et les instances MongoDB.

En apportant ces améliorations, 10gen offre à MongoDB une architecture distribuée plus attrayante. Ce choix se comprend puisque MongoDB ne proposait jusqu’alors que des mécanismes peu innovants et qui poussaient beaucoup de projets à lui préférer Cassandra.

Axon, une implémentation Java du pattern CQRS

Le Command Query Request Segregation (CQRS) est un pattern architectural qui a été formalisé fin 2009 par Greg Young et Udi Dahan. Il repose sur l’idée de séparer le code métier selon qu’il s’appuie sur des opérations d’écriture (command) ou de consultation de données (query), plutôt que par découpage fonctionnel. Le but recherché ici est d’offrir une grande scalabilité en permettant aux lectures de s’effectuer de manière synchrone dans un cache, tandis que les requêtes d’écritures sont effectuées de manière asynchrone en mettant à jour à la fois le cache et la base de données sous-jacente.

Les développeurs Java disposent d’une implémentation Open Source de ce pattern, il s’agit du framework Axon (anciennement CQRS4J). Le projet est très actif et vient diffuser une version 0.6 dont la maturité mérite de s’y attarder : gestion et persistance des évènements, intégration à Spring et gestion des transactions.
Ce framework reste modeste pour l’instant et ne couvre qu’un nombre limité d’environnements techniques mais à défaut de répondre à votre besoin il constituera un exemple d’implémentation intéressant à étudier.

L’architecture de Last.fm basée sur HornetQ

Tout le monde connaît Last.fm, le service de streaming et de recommandation de musique. La compagnie a récemment changé son infrastructure de streaming et en a profité pour adopter JBoss HornetQ comme serveur de messaging, au détriment « d’un autre serveur open-source » (mais nous ne saurons pas lequel !). Jeff Mesnil publie sur DZone un article expliquant les raisons de ce changement et la façon dont Last.fm se sert d’HornetQ.
Pour résumer simplement, les messages JMS sont générés principalement par les streamers pour:

• notifier la fin de l’écoute d’un morceau et donc faire mettre à jour la base.
• permettre la déconnexion automatique d’un utilisateur connecté à un flux si un message généré par un second streamer indique qu’il vient de se connecter à un autre flux.

Dans sa configuration de HornetQ, Last.fm a mis l’accent sur la performance:

• la persistance a été désactivée. Comme rapporté par nos lecteurs dans les commentaires d’un précédant article celle-ci est connue pour être consommatrice.
• messages déclarés comme pré-acquittés, permettant d’éliminer des accès réseau supplémentaires.

Bien sûr tout ceci est fait au détriment de la robustesse. On n’a rien sans rien ! Mais Last.fm préfère perdre des messages plutôt que d’empêcher un auditeur d’écouter sa musique: « Availability was more important than reliable delivery ». Il est à noter que pour renforcer la robustesse, les envois de messages ne sont pas faits n’importe comment: un seul thread s’occupe de la communication JMS. Il communique avec les autres threads en interne par un mécanisme de files, dans lesquelles il puise les messages à envoyer à HornetQ et dépose les messages reçus. Ces files étant limitées en mémoire, cette dernière est donc maîtrisée et comme il y a un seul thread responsable des accès JMS, il n’y a pas de risque de blocage de tout le système.

Pour continuer sur HornetQ, notons que la tant attendue interface REST vient d’être annoncée par Bill Burke, son développeur principal, sur le forum du broker. Cette interface n’est pas encore disponible dans une version officielle de HornetQ, mais sa documentation permet d’ores et déjà de se faire une idée. Basée directement sur HTTP, elle évite de forcer l’utilisation d’une quelconque encapsulation (autre qu’applicative) des messages. Et bien sûr, on peut l’utiliser avec n’importe quel langage: REST est interopérable. La documentation spécifique à la création de messages permet de se faire une idée rapidement. Basée sur RestEasy, qui fera aussi partie du futur JBoss AS 6, il y a fort à parier que cette interface fera parler d’elle et ouvrira la voie à de nouvelles utilisations du broker.

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é…

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 ?

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

• JEE 6 commence à apparaître chez JBoss

Le coin de la technique

• Sortie de TeamCity 5
• Apache Camel continue d’évoluer

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

• Suite et fin, traduction de la deuxième partie de DDD Quickly

Actualité éditeurs / SSII

JEE 6 commence à apparaître chez JBoss

Quelques jours avant la finalisation de Glassfish V3, l’implémentation de référence de la nouvelle spécification JEE, JBoss met à disposition une première milestone de JBoss AS 6.0, le serveur d’application que l’éditeur destine à implémenter JEE 6.

Ce premier jet apporte seulement 3 des composants propres à JEE 6 :

• Weld, un conteneur CDI implémentant la JSR-299 (Contexts and Dependency Injection).
• Un moteur de validation implémentant la JSR-303 (Bean Validation). L’implémentation utilisée est Hibernate Validator 4.0.
• Une implémentation de JSF 2. Il s’agit de l’implémentation de référence de Sun.

Pourquoi ces composants en particulier ? Parce qu’il s’agit soit des composants pour lesquels JBoss est responsable de l’implémentation de référence, soit, dans le cas de JSF 2, d’une implémentation de référence empruntée à Sun. Or, ces composants sont forcément finalisés puisqu’ils seront intégrés à l’implémentation de référence de l’ensemble de la spécification JEE 6 qu’est Glassfish V3, qui sera disponible dans quelques jours (peu après la finalisation de la spécification le 10 décembre).

JBoss AS 6.0 M1 embarque Hibernate 3.5.0 beta 2, or Steve Ebersole, un des membres de l’équipe Hibernate, expliquait que le support de JPA 2 dans cette version était encore partiel. Aucune indication n’est par contre donnée quant au statut de l’autre composant majeur de JEE 6 qu’est EJB 3.1.

Aucune roadmap n’est annoncée, mais il semble raisonnable de penser à une finalisation pour fin 2010. Si l’on regarde la vitesse de déploiement des serveurs Java EE 5, rares seront donc les privilégiés qui pourront utiliser Java EE 6 avant 2011 voire 2012…

Le coin de la technique

Sortie de TeamCity 5

Fin de semaine dernière est sortie la nouvelle version du serveur d’intégration continue de JetBrains à savoir TeamCity (via JavaLobby). Cette version 5 apporte son lot de nouveautés et elles sont assez alléchantes, jugez par vous-même :

• support d’Amazon EC2 avec un agent de build sur le Cloud permettant de faire du build distribué,
• meilleur support de maven,
• templates de build (préférences partagées),
• intégration avec les gestionnaires de bugs YouTrack, Jira et Bugzilla,
• archivage de projets,
• command line tool (build sans plugin intégré à l’IDE),
• back-up and restore pour simplifier la maintenance de TeamCity,
• ainsi que plusieurs nouvelles fonctionnalités et corrections de bugs dont le support de Git et la compatibilité du plugin TeamCity avec IntelliJ IDEA CE.

Les licences ne changent pas, laissez-vous tenter !

Apache Camel continue d’évoluer

Claus Ibsen, un membre de l’équipe Apache Camel, annonce une nouvelle version 2.1 du moteur de médiation d’Apache.

Il liste les principales nouveautés parmi lesquelles on notera un effort particulier pour apporter une gestion plus robuste des routes :

• Amélioration des messages d’erreur fournit au démarrage en cas de mauvaise définition d’une route.
• Il est désormais possible de définir un ordre de démarrage pour les routes.
• Il est également possible d’indiquer si une route doit être auto-démarrée.

Poursuivant dans cette voie, Claus Ibsen explique son intention d’apporter un graceful shutdown à Camel pour la version 2.2, ce qui permettrait un arrêt de l’ESB sans perdre de messages. Cet arrêt sans perte est dors et déjà possible avec la version 2.1 mais nécessite plusieurs manipulations via JMX (arrêt des routes, puis arrêt du moteur lorsque plus aucun message n’est en cours de traitement).

James Strachan, créateur du projet, expliquait lors de Devoxx 2009 que la majorité de ses clients déployaient Camel sur Tomcat, Jetty ou ServiceMix pour bénéficier d’un environnement de monitoring plus riche et d’une structure plus familière pour l’administration. Ces pratiques montrent les besoins de robustesse des entreprises quant aux déploiements Camel. Ces améliorations, répondant à des problématiques réelles lors de l’utilisation de Camel pour la médiation, devraient donc être accueillies avec joie par les équipes utilisant ce framework.

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

Suite et fin, traduction de la deuxième partie de DDD Quickly

Dans la revue de presse du 10 octobre 2009, nous avons relayé l’information de la traduction de la première partie de DDD Quickly.

La traduction de la deuxième et dernière partie est terminée. Ce livre est disponible sur le portail DDD France.

Dans cette deuxième partie : On y retrouve des techniques pour mettre en oeuvre DDD sur de gros projets impliquant plusieurs équipes, mais aussi pour refactorer un domaine et gérer sa croissance, notamment à travers la distillation et l’identification d’un Coeur de Domaine. (source sur le blog de Guillaume)

Félicitations à Guillaume Lebur pour ce gros travail, et bonne lecture de DDD Vite fait au pied de votre arbre de Noël !

Actualité éditeurs / SSII

• Condamnation pour non respect de licence

RIA

• Chrome dans IE avec Google Chrome Frame

Le coin de la technique

• Guide utilisateur de Tellurium
• Lucene évolue et prépare l’avenir
• JBoss Microcontainer et son Virtual File System
• Injection de dépendances en Javascript …

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

• Devoxx 2009 : le planning des sessions est maintenant connu
• Asylum, un nouveau podcast dédié à JBoss

Actualité éditeurs / SSII

Condamnation pour non respect de licence

Qu’arrive-t-il lorsque l’on réutilise du code open source sans se soucier de sa licence ? On se fait taper sur les doigts. C’est en effet la mésaventure qui est arrivé à la société Edu4, comme le présente l’article de la Free Software Foundation France sur l’affaire.
Ayant fourni en 2000 à l’AFPA (un organisme de formation professionnelle) un logiciel basé sur VNC, Edu4 a reçu une requête de cet organisme demandant le code source du logiciel, conformément à ce qu’autorise la licence GPL.
Edu4, dans un premier temps, a refusé de fournir les sources de VNC modifiées par ses soins. Puis, à la suite d’une décision de justice de 2002, a fourni des sources ne correspondant pas à la version livrée et dans lesquelles le texte de la licence GPL de VNC avait été retiré.
Cette semaine, la cour d’Appel de Paris a reconnu Edu4 coupable.
Nous savons tous comment se passent les projets sur lesquels il y a une certaine pression et certains enjeux qui poussent à sortir des produits le plus vite possible sans mesurer toutes les conséquences. Nous ne jetterons donc pas la pierre à Edu4. Mais cette histoire permet de préciser que (1) la licence GNU GPL a bien valeur légale en France et que (2) n’importe quel utilisateur de logiciel basé sur la licence GNU GPL est en droit de réclamer les sources, et pas seulement les auteurs du code original (dans le cas présent, les auteurs de VNC n’ont pas participé au procès).

Il faut donc être bien conscient des conséquences que peut avoir la réutilisation de code open-source. Selon la licence (article de Wikipedia sur les licences du logiciel libre), il y a des obligations et des contraintes. Mais c’est bien là la moindre des choses pour pouvoir profiter de code déjà testé, éprouvé et amélioré par nombre de contributeurs. Cette prise de conscience est d’autant plus nécessaire que les composants open-source sont de plus en plus présents dans les SI des entreprises françaises. Pour un autre éclairage sur ces questions, on peut citer l’interview de Matt Light par ITRManager.

RIA

Chrome dans IE avec Google Chrome Frame

Une des sensations de la semaine dernière est l’annonce de Google Chrome Frame ou comment transformer Internet Explorer en Google Chrome.
On ne compte plus les sites ayant relayé l’information : cela passe par InfoQ, Ajaxian, Inside RIA ou encore TechCrunch.
Google Chrome Frame se présente sous la forme d’un plug-in pour Internet Explorer (6, 7 et 8). Le plug-in se lancera sur la balise suivante (ce qui implique donc que tous nos header HTML doivent être changés) :

<meta http-equiv="X-UA-Compatible" content="chrome=1">

À partir de là, 2 possibilités :

• Le plug-in est installé : il détecte le tag et lance le moteur de rendu de Chrome (WebKit) dans IE
• Le plug-in n’est pas installé : la page s’affiche normalement dans IE mais il est possible de rediriger l’utilisateur vers une page d’installation

Les avantages sont multiples : on retiendra de nombreuses optimisations de performances Javascript, un chargement de page plus rapide mais aussi l’utilisation de HTML 5 avec le offline et les canvas.
Il sera alors possible, comme le rappelle InfoQ, pour Google Wave d’offrir une expérience utilisateur complète à tous les utilisateurs d’Internet Explorer (en effet, celui-ci utilisera de nombreuses fonctionnalités de HTML 5).
Le support d’IE continuera comme le rappelle Lars Rasmussen (Team manager de Google Wave) qui insiste aussi sur le fait que les différentes versions d’IEs ralentissent l’élaboration d’applications web dîtes riches (avec des quick fixes à n’en plus finir pour obtenir des résultats présents out of the box chez les autres navigateurs).

Plusieurs réactions ont suivi cette annonce. On pourra retenir celle de Robert Nyman (par Ajaxian) qui rappelle fort justement que les utilisateurs restant sur de vielles versions d’IEs sont (pour résumer grossièrement) :

• soit des utilisateurs qui ne savent pas ce qu’est un navigateur (et donc n’installeront jamais ce plug-in)
• soit (malheureusement pour ceux qui y sont confrontés) des sociétés qui bloquent les mises à jours logicielles (il sera donc peu probable que le plug-in soit autorisé à être installé)

Dion Almaer se pose la question de l’inversion des rôles quant à l’expérience utilisateur : est-ce au développeur de choisir (forcer ?) le renderer/navigateur à utiliser ?
En tous cas, on ne peut que saluer le travail effectué et espérer que cela aidera, ne serait-ce qu’un peu, à réduire les IE 6 de ce monde

Le coin de la technique

Guide utilisateur de Tellurium

Tellurium nous annonce la sortie de son guide utilisateur version 0.6.0.
En 5 chapitres, celui-ci parcourt :

• Les concepts et fonctionnalités principaux de l’outil
• Un Getting Started
• Les sous-projets de Tellurium (archetype Maven, TrUMP…)
• L’architecture de Tellurium
• Ses APIs (DSLs, data access…)

Le PDF se récupère à cette url.
Et pour un petit aperçu du projet, je vous renvoie vers notre article sur comment améliorer l’écriture de vos tests selenium.

Lucene évolue et prépare l’avenir

Le projet Apache Lucene annonce la disponibilité de la version 2.9 du célèbre framework de recherche d’information. La liste des changements est conséquente.

Shalin Shekhar Mangar, committer sur Apache Solr, faisait part il y a quelques mois d’une activité très dense sur le projet Lucene pour préparer cette nouvelle version. Il expliquait alors que la majorité du travail était imputable au near real-time search, amélioration permettant de refléter très rapidement les modifications des données dans les résultats des requêtes alors que celles-ci sont habituellement rendues visibles seulement après le commit des changements dans l’index.

Outre cette nouvelle possibilité de recherche en temps réel, les principaux apports de Lucene 2.9 :

• Optimisations portant sur la mise en cache de segments inchangés de l’index, apportant un gain significatif de performance
• Gestion plus efficace des champs numériques avec l’ajout des classes NumericField et NumericRangeQuery. Il en résulte un gain de performance sur les requêtes par intervalles
• Support des requêtes géo-spaciales (module contrib/spatial)
• Nouveaux analyzers (PersianAnalyzer, ArabicAnalyzer, et SmartChineseAnalyser)
• Diverses améliorations d’API notamment sur le Collector / Scorer et le QueryParser

Par ailleurs, Lucid Imagination, une société américaine d’expertise Lucene, propose un webinar sur les nouveautés de cette version. On y retrouve également les plans pour la version 3.0 : les changements seront majeurs puisqu’il est prévu de passer l’API à Java 5 et de supprimer les éléments précédemment dépréciés.

La documentation du projet évolue également mais reste moins fournie qu’on ne le souhaiterait et les développements avec Lucene doivent souvent être accompagnés de l’ouvrage Lucene In Action paru chez Manning. Ce livre paraîtra dans une seconde édition, mise à jour pour la version 3.0 du framework, en mars 2010.

Cette activité dense de l’équipe Lucene est en rapport avec l’importance que prend ce projet dans la mise en œuvre des nombreux cas d’utilisations issus du Web moderne, tels que les recherches intelligentes et rapides, les systèmes de suggestions, et les analyses de contenu.

JBoss Microcontainer et son Virtual File System

Le projet Microcontainer de JBoss est le noyau de la version 5.0 du serveur d’application de l’éditeur sortie en fin d’année dernière. Il remplace le Microkernel JMX qui était utilisé jusqu’alors dans les version 4.x de JBoss AS. Le choix d’un tel noyau développé en interne avait fait l’objet de quelques remarques lors de son développement puisqu’il offre des fonctionnalités très classiques telles que la gestion du cycle de vie de ses composants, l’injection de dépendances et de propriétés, et des fonctionnalités d’AOP.

Ce Microcontainer s’illustre malgré tout par son système de déploiement reposant sur une abstraction très flexible encapsulant le chargement de ressources qu’elles soient sous forme de Jar, de fichiers, ou de répertoires : le Virtual File System. Cette fonctionnalité très puissante est malheureusement très peu documentée dans le manuel utilisateur du projet. Sa bonne maîtrise est pourtant souhaitable pour bien comprendre le comportement et les possibilités du déploiement d’applications dans JBoss AS 5.0 ou encore (scénario certes beaucoup moins courant) pour utiliser directement le Microcontainer dans un projet.

Ce manque de documentation est maintenant partiellement comblé grâce à Ales Justin, travaillant chez JBoss sur leur serveur d’application, qui a mis en ligne un article sur VFS. Cet article fait suite à deux articles précédents sur le modèle de composants et l’injection de dépendances dans JBoss Microcontainer.

Il y présente l’architecture de VFS et les abstractions et APIs mises en œuvre. On découvre alors des interfaces très claires et on se rend compte qu’il est envisageable de développer son propre protocole pour VFS afin de permettre le chargement de ressources depuis n’importe quelle source de stockage (réseau, base de données, repository, …).

Au-delà de la compréhension de cette architecture et de son comportement standard, on retiendra donc cette possibilité d’adapter le déploiement des applications sur JBoss AS 5.x à l’infrastructure mise en place dans l’entreprise, et ce, pour un coût raisonnable.

A noter que l’auteur annonce que le prochain article portera sur le système de classloading du Microcontainer. A suivre donc …

Injection de dépendances en Javascript …

Dans la série pourquoi faire simple quand on peut faire compliqué, à l’heure où Spring vient d’annoncer la sortie de la version 3-RC1 de son framework, à l’heure où Google sort son nouveau framework web sitebricks basé sur Google Guice, son framework d’injection de dépendances, pourquoi ne pas abandonner tout cela et gérer vous-même l’injection des dépendances de votre application Java en … Javascript ! C’est ce que nous propose l’auteur de cet article.

S’il est clair que vous n’allez pas jeter votre framework préféré dés la lecture de ce billet, cette solution
a tout de même le mérite, en plus d’être originale, d’utiliser uniquement les fonctions du JDK : Scripting API + proxy dynamique.

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

Devoxx 2009 : le planning des sessions est maintenant connu

Devoxx (anciennement JavaPolis) est la première conférence Java au niveau européen et la seconde au niveau mondial, après JavaOne. L’édition 2009 se déroulera du 16 au 20 novembre et devrait, cette année encore, réunir plus de 3000 personnes.

Le planning des sessions est maintenant connu, ce qui permet d’observer les tendances du moment. On dégage ainsi une présence marquée du Cloud Computing, de JDK 7 et des langages alternatifs pour la JVM, notamment Scala.

On peut également noter quelques sessions particulièrement alléchantes telles que :

• Le keynote de Steven Harris (Oracle, Product Development & Server Technologies)
• Le keynote d’Ivar Jacobson
• Distributed Programming the Google Way par Gregor Hohpe (l’auteur de Enterprise Integration Patterns), qui présentera les technologies mises au point par Google (MapReduce, GFS, Sawzall, Chubby, Protocol Buffers, …) pour rendre leurs applications distribuées optimales et surtout réalisables
• The Modular Java Platform & Project Jigsaw par Mark Reinold, qui permettra de faire le point sur cette technologie clé du JDK 7 qui est encore peu documentée.
• Maven 3 par Jason van Zyl (créateur de Maven)

En outre, pour ceux qui n’auraient pu assister à la présentation de JEE 6 par Antonio Goncalves au ParisJUG en début d’année, ou qui souhaiteraient être au fait des dernières évolutions, il présentera de nouveau une session sur ce sujet à Devoxx.

L’édition 2009 s’annonce donc aussi riche que les précédentes, ce qui laisse présager que, comme les années passées, les places seront toutes vendues 1 ou 2 semaines avant le début de la conférence, alors ne tardez pas à vous inscrire si vous êtes intéressés !

Asylum, un nouveau podcast dédié à JBoss

JBoss Community Asylum est un nouveau podcast créé par Max R. Andersen (JBoss Tools), Emmanuel Bernard (Hibernate), et Michael Neale (Drools) dont le contenu sera entièrement centré sur l’actualité et les informations relatives à la communauté JBoss.

Le premier épisode est en ligne et revient sur la conférence JBoss World et les nouveautés qui y ont été présentées, notamment :

• Infinispan, une évolution majeure de JBoss Cache
• REST-*, un ensemble de spécifications de services pour REST
• GateIn, le nouveau portail issu du partenariat entre JBoss et eXo
• TorqueBox, un conteneur d’applications Ruby On Rails pour JBoss AS
• HornetQ, la nouvelle version de JBoss Messaging
• Shrinkwrap, une API d’assemblage d’archives applicatives Java

Pour rappel, Emmanuel Bernard participe également à un podcast en français, les Cast Codeurs, dont le dernier épisode en date est disponible depuis hier.

Architecture

• Gartner adopte le pragmatisme avec l’Architecture Émergente

Actualité éditeurs / SSII

• JBoss HornetQ

RIA

• BlazeMonster

Le coin de la technique

• Liste finale des évolutions du langage Java apportées par le JDK 7
• Fin d’Eclipse RCP, place à…
• TestSwarm

Architecture

Gartner adopte le pragmatisme avec l’Architecture Émergente

Gartner nous livre un plaidoyer pour la pragmatisme avec Emergent Architecture. La formulation est parfois compliquée mais on se réjouira de trouver la responsabilisation des équipes sur le terrain et des Architectes d’Entreprise évangélistes de lignes directrices. Pour reprendre une expression chère au Lean Manufacturing, « Empower the People » :

1. Non déterminisme – Dans le passé, les architectes d’entreprise prenaient des décisions centralisées qui s’appliquaient à tous. Dans une architecture émergente, ces architectes d’entreprise doivent au contraire décentraliser la prise de décisions pour permettre l’innovation.
2. Acteurs autonomes – Les architectes d’entreprise ne peuvent plus contrôler tous les aspects de l’architecture comme ils le faisaient auparavant ; ils doivent désormais reconnaître l’étendue et la variété du SI ; ils doivent déléguer le contrôle aux équipes sur le terrain.
3. Limiter les contraintes aux lignes directrices – Jusqu’à présent, les architectes d’entreprise ont fourni des spécifications détaillées de tous les aspects de l’architecture ; ils doivent désormais limiter leurs prescriptions aux lignes directrices et de permettre le choix.
4. Acteurs orientés objectif – Auparavant, les seuls objectifs qui comptaient étaient les objectifs de l’entreprise mais cela s’est maintenant déplacé et chaque acteur agit dans ses propres intérêt. Il ne faut pas pour autant oublier les lignes directrices.
5. Influences locales: Les acteurs sont influencés par des interactions locales et des informations limitées. Les feedbacks au sein de leur sphère de communication modifie leur comportement. Aucun acteur individuel ne possède la vision globale d’un système émergent. Les architectes d’entreprise doivent intensifier leur travail coordonner et de transmission de l’information.
6. Systèmes dynamiques et adaptatifs: le système (les différents acteurs et leur environnement) changent avec le temps. Les architectes d’entreprise doivent définir les pourtours des systèmes émergents et ajuster en fonction des changements.
7. Environnement aux ressources limitées: L’abondance, les budgets illimités, ne permet pas de créer une architecture émergente ; c’est au contraire la rareté des moyens qui permet une architecture émergente.

Actualité éditeurs / SSII

JBoss HornetQ

Après 2 ans de développement, le projet JBoss Messaging 2.0 sort enfin dans les bacs sous le nom HornetQ. Ce Message Oriented Middleware n’est pas une évolution de son prédécesseur qui continue d’exister dans sa version 1.0, mais belle et bien une réécriture (presque) intégrale. Redhat nous le vend comme un MoM opensource, multi-protocol, embarquable, haute performance, réparti, et asynchrone.
HornetQ peut-être utilisé en standalone ou bien embarqué dans un serveur d’application JBoss AS par exemple. Chose appréciable, HornetQ est léger, il dépend uniquement du JDK (5 minimum) pour être complètement fonctionnel.
Dans sa présentation, Redhat nous annonce que le projet est facile d’utilisation avec une documentation déjà très complète et la bagatelle de 65 exemples de codes sources. Il est même possible de démarrer en moins de 5 minutes.
HornetQ bénéficie d’une conception orientée Pojo qui lui permet d’être utilisé directement dans Spring ou Guice. La performance a fait l’objet d’une attention importante, avec un journal haute performance et JBoss Netty pour la scalabilité.
JBoss nous livre une liste sans fin des fonctionnalités embarquées parmi lesquels on retiendra:

• JMS 1.1
• JTA
• Adaptateur JCA

Enfin, l’editeur annonce orienter ses développements vers le support d’API RestFull qu’il voit comme le futur du cloud computing. Redhat souhaite donc pousser la porte des clouds privé en tentant de s’imposer comme le provider de message incontournable dans le nuage.

• Site du projet
• Wiki

RIA

BlazeMonster

BlazeMonster vient de sortir dans sa deuxième version. Pour rappel cet outil, basée sur la technologie AIR, permet le support et l’aide à la génération de code pour consommer/exposer des services Java en tant que service Remote pour BlazeDS ou LCDS (LiveCycle Data Services).
Parmi les supports, nous avons entre autre :

• Génération des fichiers de configurations : déclarations des services, channels..
• Génération du code appelant le service Remote
• Génération des beans ActionScript (Value Object)
• Visualisation des réponses des services Remote

Dans cette deuxième version, BlazeMonster intègre le support de Spring BlazeDS, permettant la génération de services Remote en utilisant cette librairie. Je vous invite à jeter un coup d’œil sur les autres corrections et évolutions apportées à ce projet ici.
Facile d’utilisation, ce projet permet de copier/coller des morceaux de code dans votre application, facilitant le développement.
Enfin, à travers ce projet nous voyons, une fois de plus, l’engouement que les technologies Flex et BlazeDS remportent. Peut être pouvons nous espérer l’intégration de ce type d’outil dans le Flash Builder 4. Alors messieurs d’Adobe, qu’attendez vous ?

Le coin de la technique

Liste finale des évolutions du langage Java apportées par le JDK 7

En début d’année, Sun a initié le Project Coin, un sous-projet d’OpenJDK visant à recueillir les propositions d’évolutions du langage Java pour le JDK 7 prévu pour début 2010. Les soumissions ont été nombreuses et Joseph D. Darcy, leader du projet, informait régulièrement la communauté sur l’avancement du processus de sélection. C’est maintenant la liste finale des évolutions qu’il annonce. Sauf problème de planning, il s’agit donc là de ce que le langage Java sera dans JDK 7 :

• Clause switch utilisable sur les String.
• Gestion automatique des resources. Cette évolution vise à simplifier la gestion de la fermeture des flux ou autre ressources par l’utilisation d’une clause try spécifique pour les objets implémentant l’interface Disposable introduite dans le JDK pour l’occasion.
• Inférence de type améliorée pour la création d’objets génériques grâce à une syntaxe du type List<String> list = new ArrayList<>().
• Evolution de la gestion des warnings pour l’utilisation des generics dans des varargs.
• Autorisation de la notation binaire pour les entiers comme en C/C++ et possibilité de placer des underscores dans les nombres pour en simplifier la relecture tel que long creditCardNumber = 1234_5678_9012_3456L
• Accès en lecture et écriture aux valeurs des collections Java par la notation utilisé jusqu’alors uniquement pour les tableaux.

On est loin de la liste d’évolutions très audacieuses initialement prévue pour JDK 7, mais les évolutions finalement retenues ont l’avantage d’être réalistes en terme de temps d’implémentation, tout en apportant un confort supplémentaire au quotidien pour les développeurs Java.

Rémi Forax, très au fait des développements sur l’OpenJDK, propose d’ailleurs son analyse des tâches restant à accomplir et de leur complexité pour chacune des évolutions.

Fin d’Eclipse RCP, place à…

Après Java Rebel, c’est Eclipse RCP qui se trouve sur la voie du changement de nom.
Cette fois-ci, ce n’est pas pour une raison de marque déposée mais tout simplement, dixit l’auteur, parce que ce nom est horrible .
Un vote est organisé avec tous les noms remontés par la communauté Eclipse depuis 3 mois.
Alors, Aurora, Montage ou Tangram, c’est à vous de voter ! Et ça se passe sur cette page.

TestSwarm

John Resig, créateur de jQuery, nous annonce que Test Swarm est maintenant ouvert au public (par ajaxian).

Test Swarm permet de tester le code Javascript sur différents navigateurs de différentes plateformes de manières continues. A l’origine utilisé pour jQuery, il est désormais possible de tester son propre code Javascript, moyennant 8 steps d’installation paragraphe Setting Up Your Own Swarm. Les tests (jobs) peuvent être lancés à chaque commits (SVN ou Git) ou bien en appelant une URL spécifique. Les résultats des tests sont résumés dans un tableau avec une colonne pour chaque navigateur/plateforme. Il est possible de rester au niveau projet mais on peut affiner l’affichage au niveau commit voir au niveau de chaque fichier js de tests. Côté couleur, les tests vert se sont bien passés, les rouges contiennent au moins une erreur, les noirs ont au moins une erreur critiques et les gris sous en cours/en attente. Des logs sont disponibles pour chaque run de tests et permettent de voir ceux qui ne seraient pas passés.

Les frameworks de tests unitaires Javascript gérés (bien d’autres suivront) sont pour l’instant :

• QUnit (jQuery)
• UnitTestJS (Prototype)
• JSSpec (MooTools)
• JSUnit
• Selenium
• Dojo Objective Harness

Une vidéo de type quick tour nous donne un bon aperçu du site. Plusieurs directions sont possible concernant la roadmap du produit dont l’intégration à l’IDE, tests sur encore plus de browser… Un produit à suivre.

Actualité éditeurs / SSII

• Fin officielle de la guerre des JSR d’injection de dépendances

Le coin de la technique

• SpringSource Tool Suite 2.1.0
• JBoss vous aide à manipuler vos annotations
• Eclipse 3.6 M1

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

• JavaCampParis en plein air !

Actualité éditeurs / SSII

Fin officielle de la guerre des JSR d’injection de dépendances

Nous en parlions dès la semaine dernière (grâce aux informations fournies par les Cast Codeurs), la rivalité JSR-299 / JSR-330, portant sur l’injection de dépendances, débouche sur une harmonisation des deux JSR.
Roberto Chinnici, leader de la spécification Java EE 6, l’annonce sur son blog. Les deux JSR seront intégrées à la spécification JEE 6.

• la JSR 299 (dite « Web Beans ») intègrera les annotations proposées par la JSR 330.
• la JSR 330 (dite « @Inject ») intègre, dès aujourd’hui en draft, les objectifs de la JSR 299

L’équipe en charge de la JSR 330 a fait d’importants efforts sur le planning pour que celle ci puisse être intégrée à JEE6 : early draft d’ores et déjà disponible, et navigation à travers les différentes étapes du processus du JCP accélérée.
Cela aura un impact mineur sur la finalisation de la spécification Java EE 6 (estimé entre 4 et 6 semaines). Celle ci devrait donc être disponible en version finale en novembre.

Le coin de la technique

SpringSource Tool Suite 2.1.0

Quelques mois après l’annonce de la gratuité de STS ou SpringSource Tool Suite, le produit sort fin de semaine dernière en version 2.1.0 GA.

Côté packaging, on a le choix entre une version d’eclipse 3.4 ou 3.5, les 2 étant disponibles sous Windows, Mac et Linux. La suite inclut les dernières versions de tc Server et dm Server ainsi que Roo. Une autre release contenant le plugin Groovy est aussi disponible (uniquement en 3.5).

Comme le signale Christian Dupuis, la liste des nouveautés est assez conséquente. On retiendra plus particulièrement :

• Support des milestones Spring 3.0 (@Configuration, @Bean, validation XML…)
• Support des milestones de SpringSource dm Server 2.0
• Déploiement sur les plateformes virtuels de type EC2 ou VMWare Lab Manager
• Amélioration des performances de l’IDE et réduction de l’empreinte mémoire
• Et plusieurs corrections de bugs (cf. la release notes du Jira)

L’équipe travaille déjà sur la prochaine version 2.2.0 avec dans les tuyaux :

• Intégration du support Spring 3.0 pour le développement d’application RESTful
• Support de Grails
• Support de dm Server 2.0

Téléchargement sur le site de SpringSource après avoir rempli le formulaire d’accord.

JBoss vous aide à manipuler vos annotations

Début 2008, Bill Burke (project lead de JBoss RestEasy) présentait une petite librairie Java très pratique nommée Scannotation permettant de scanner les annotations présentes dans les classes d’un package donné. Il expliquait alors le besoin réel pour un tel framework par le fait qu’en standard, cette découverte de classes annotées n’est possible que par un coûteux mécanisme d’introspection nécessitant le chargement dans la JVM de l’ensemble des classes scannées (induisant donc une consommation de mémoire PermGen excessive puisque toutes les classes concernées n’auraient pas forcément été chargées lors de l’exécution de l’application).

JBoss présente maintenant un framework remplissant le même rôle et nommé JBoss Annotations, prévu pour être intégré aux différents projets de l’éditeur. Il vous permettra ainsi de constituer une base de données des annotations présentes sur l’ensemble des classes que vous aurez sélectionnées pour analyse, que vous pourrez ainsi facilement interroger. La documentation et la javadoc de JBoss Annotations sont pour le moment uniquement disponibles dans l’archive de distribution du projet.

Eclipse 3.6 M1

Quelques semaines après la sortie fin juin d’eclipse 3.5 galileo, voici venir la première milestone de la prochaine version de l’IDE à savoir eclipse 3.6 helios (par le blog de keulkeul).

Au menu des nouveautés :

• Regroupement des licences dans le wizard d’installation
• Ajout d’un Footer customisable pour l’aide
• Content assist et Hover Pop-Up redimensionnable sous Linux
• Amélioration d’Extract Method au niveau de continue et de retours multiples
• Export All pour les Formatters
• Nouvelles entrées de menu (Remove Nodes dans Call Hierarchy, Open Implementation…)

Early adopters, c’est par ici que ça se passe !

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

JavaCampParis en plein air !

Fort du succès des précédentes rencontres, le JavaCamp Paris organise une nouvelle session le 27 août dans un format très original puisqu’elle se tiendra en plein air, au Jardin des Tuileries.

Pour rappel, le principe des JavaCamp repose sur la constitution de groupes de discussion improvisés échangeant des informations et des idées sur des sujets décidés en début de session.

Si cette expérience vous intéresse, n’hésitez pas à vous inscrire sur le wiki du JavaCamp Paris 5.

RIA

• GChart 2.5 pour GWT

SOA

• jBPM 4.0 est disponible
• Avez-vous besoin d’un ESB ?

Le coin de la technique

• Making Good Software, bonnes pratiques du développement logiciel

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

• Sun fait évoluer sa certification programmer

RIA

GChart 2.5 pour GWT

Afficher des résultats sous forme d’histogramme ou de camembert se résume pour bon nombre de projets Java à l’import de JFreeChart, la librairie de référence pour faire des diagrammes en Java (démo).

Pour les projets GWT, une autre API fait beaucoup parler d’elle en ce moment (entre autres sur Ajaxian et onGWT) et cette API est GChart 2.5. Son objectif est simple : réaliser rapidement de beaux graphiques.

Une démo nous montre les capacités de l’outil en termes de rapidité d’affichage. Le code source de chaque exemple est aussi disponible (source du graphique Estimated Future Oil Prices).

Pour la release note technique (plus de compatibilité GWT 1.4, navigateurs testés, objets et méthodes dépréciés, bugfix…), tout se trouve sur cette page. Il ne reste plus qu’à tester ! Les retours d’expériences sont bienvenus dans les commentaires.

SOA

jBPM 4.0 est disponible

Tom Baeyens annonce sur son blog la disponibilité de la version finale de jBPM 4.0 respectant ainsi le calendrier prévu.

jBPM n’avait pas connu d’évolution majeure depuis 2005, cette nouvelle version constitue donc un évènement majeur pour les utilisateurs de jBPM. Les nouveautés apportées sont importantes :

• Nouvelle version du plugin Eclipse (GPD) permettant la définition graphique de processus suivant la notation BPMN
• Introduction de JBoss PVM (Process Virtual Machine), un moteur de workflow générique utilisé par jBPM pour l’implémentation des différents langages de définition de processus qu’il propose (jPDL, BPEL et Pageflow)
• Refonte des schémas de base de données utilisés pour les rendre plus évolutifs
• Intégration native à Spring
• Amélioration des performances
• Simplification de l’installation

Cette nouvelle version est d’ores et déjà disponible sur le repository Maven de JBoss. Par ailleurs, l’ensemble des apports de jBPM 4 seront passés en revue lors du JBoss World 2009 en septembre prochain, ainsi qu’à Devoxx 09 en novembre.

Avez-vous besoin d’un ESB ?

Ross Mason, fondateur de MuleSource a publié sur son blog une liste de points à vérifier avant de mettre en place un ESB. L’article, au titre plutôt racoleur (To ESB or not to ESB), à fait du bruit sur Twitter. D’ailleurs, en aparté, pour avoir nous-mêmes fait circuler ce lien, nous avons été surpris d’avoir été répondu par un certain @shakesp.

Pour en revenir au cœur du sujet, les points qui nous semblent intéressants sont simples à retenir :

• Commencez à penser à un ESB pour intégrer 3 applications, à plusieurs ESB si vous en avez plus que 10
• Avez-vous absolument besoin de plusieurs protocoles de communications ?
• Avez-vous de réels besoins d’intégration ? Découpage, routing, agrégation de messages …

Le coin de la technique

Making Good Software, bonnes pratiques du développement logiciel

Une fois n’est pas coutume, nous vous proposons cette semaine la découverte d’un blog tout récemment ajouté dans nos RSS : Making Good Software. Ce blog établit des listes de bonnes (et mauvaises) pratiques du développement logiciel. Non pas que son contenu soit extraordinaire, puisque vous en connaissez probablement déjà les plus gros points, mais il a le mérite de les rappeler : toute ressemblance avec personnes existantes ou ayant existé ne suivant pas ces règles ne saurait être que fortuite

Dans un premier article, une liste des 5 erreurs non techniques les plus répandues chez les développeurs, dont nos 2 préférés qui vous feront probablement penser à quelqu’un de votre open-space:

• Ego surdimensionné :  » je suis le meilleur développeur au monde, et ça me permet d’avoir toujours raison  » (ou la fameuse conversation à sens unique)
• Manque de discipline :  » j’essaye de tout faire en même temps, mais je ne termine jamais rien  » (définition de done plus que douteuse)

Un autre article vous donne une liste de 10 points à suivre pour écrire du bon code :

• Factorisez votre code, pour simplifier la correction d’anomalies et le refactoring
• Ecrivez des méthodes les plus courtes possibles
• Travaillez le nom des vos objets, variables et méthodes, il s’agit de la meilleure des documentations
• Une seule responsabilité par classe,
• Travaillez l’organisation de votre code, par groupes physiques de fichiers et groupes logiques de fonctions
• Faites des tests unitaires, quand vous aurez fini, faites-en encore plus
• Refactorez le plus tôt et le plus souvent possible
• Auto-documentez votre code
• Privilégiez le code par interface
• Faites des revues de code régulières

Dans un autre article l’auteur décrit une matrice permettant de noter votre code en fonction de sa simplicité et de son extensibilité.

Et pour finir, histoire de ne pas commenter l’ensemble des billets du blog, les 7 étapes pour corriger un bug : de la recherche de l’erreur, à l’analyse des dommages collatéraux.

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

Sun fait évoluer sa certification programmer

Sun teste une nouvelle version de sa certification SCJP (Sun Certified Java Programmer). La grosse nouveauté de cette révision : l’examen contiendra dorénavant une partie programmation. Cette certification, que certains appellent ‘pensez comme un compilateur Java’ évolue donc pour adopter une approche plus pragmatique.

• Les demandes d’ New Sun Java Programmer Plus Certification, SCJP vs SJPPC

Actualité éditeurs / SSII

• Yahoo! distribue Hadoop
• JBoss et eXo fusionnent leurs solutions de Portlets
• Refonte de JBoss Messaging

RIA

• AjaxSwing 2.4

Le coin de la technique

• SoapUI 3.0 se prépare
• Comparaison Gigaspace – Coherence
• L’invocation dynamique pour Java se concrétise

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

• Retour sur le CloudCamp

Actualité éditeurs / SSII

Yahoo! distribue Hadoop

Yahoo! a annoncé la disponibilité de leur propre distribution du projet Hadoop. Répondant à une demande de la communauté qui souhaitait avoir accès aux modifications effectuées par Yahoo! en interne, cette distribution est basée sur la dernière version du projet Hadoop disponible auprès de la fondation Apache.

Avec 13 committers sur les 22 que compte au total Hadoop, Yahoo! porte largement ce projet dont la popularité croît rapidement. Dans un contexte où Google, son concurrent direct, affirme fortement sa présence dans le domaine du calcul distribué et sur le très convoité bien qu’émergeant marché du Cloud Computing, le projet Hadoop constitue une belle vitrine technologique pour Yahoo!.

Souhaitant couper court aux inévitables accusations de tentative de fork ou de prise de contrôle du projet qui n’ont pas tardées à arriver, Yahoo! précise sur la page d’accueil de sa distribution que l’ensemble des patchs apportés par cette dernière ont déjà été contribués à Apache mais ne sont pas encore apparus dans une version stable.

JBoss et eXo fusionnent leurs solutions de Portlets

JBoss a annoncé la constitution d’un partenariat avec eXo qui va donner lieu à la fusion de leur solutions de Portlets respectives : JBoss Portal et eXo Portal. C’est assez logiquement la solution de JBoss qui survivra à cette fusion.

En pratique, le portail résultant proposera les spécificités suivantes aux utilisateurs :

• L’expertise de JBoss sur son moteur de Portlet qui était plus abouti que la solution d’eXo en terme de performance et de modularité.
• L’interface utilisateur d’eXo Portal ainsi que les possibilités d’administration confortables qu’il apportait.
• Le support des Portlets 2.0 telles que définies par la JSR-286. Les deux portails supportaient déjà cette spécification finalisée il y a un an.
• Les deux entreprises seront a priori à même de proposer du support sur JBoss Portal

Cette information a été relayée par le Touilleur, et Janus Boye propose une analyse des impacts de cette fusion pour les clients actuels de l’une des deux solutions existantes.

Refonte de JBoss Messaging

JBoss Messaging est une brique importante de la plate-forme entreprise de JBoss. Après avoir entrepris une ambitieuse refonte de son serveur d’application, l’éditeur réitère l’opération avec son middleware de messages. JBoss Messaging 2.0 vient en effet d’être mis à disposition en version beta. Tim Fox, project lead de Messaging, précise que cette nouvelle version ne réutilise que 5 % du code de son prédécesseur. Parmi les nouveautés, on notera en particulier :

• Embarquable dans n’importe quel type d’application et intégrable facilement à JBoss MicroContainer ou à d’autre framework d’injection de dépendances (Spring ?)
• Stockage performant des informations de journalisation
• Stockage JDBC s’appuyant sur Hibernate
• Support des messages de grosse taille
• Moteur NIO supportant TCP, SSL, HTTP et APR

Il est intéressant de noter que JBoss Messaging 2.0 s’appuiera sur un moteur NIO basé sur Apache Mina. Ce choix est inattendu, dans le mesure où JBoss publie Netty, un framework concurrent de Mina créé il y a un an par Trustin Lee, alors committer sur le projet Mina. Le framework NIO d’Apache bénéficiant d’une plus grande maturité et d’un support APR aura probablement eu raison du corporatisme.

Par ailleurs, le support d’AMQP, STOMP et REST devrait arriver d’ici la version finale 2.0 selon Tim Fox. Ces technologies de transports constituent un attrait stratégique important : AMQP dispose d’un fort potentiel en tant que protocole standard de transport de messages M2M, STOMP assure la compatibilité avec d’autres middlewares de messages, et REST permet de s’aligner sur ActiveMQ et d’offrir un accès Web Service au MOM non sans rappeler Amazon Simple Queue Service.

RIA

AjaxSwing 2.4

Un projet qui fait beaucoup de bruit en ce moment, avec entre autres une présentation / démo à Java One, c’est Eclipse RAP. Pour résumer, un projet de type RAP sera très similaire à un projet RCP, à la grosse différence que la cible ne sera pas le desktop mais le browser. Cela veut dire que l’on continue à développer en SWT like (RWT) avec toutes les compétences acquises pour le développement d’un client lourd mais qu’on obtiendra au final un client léger.

Mais qu’en est-il pour Swing ? C’est du côté de chez TSS que l’on apprend la release 2.4 d’un projet faisant le pont entre Swing et HTML : AjaxSwing.

L’outil convertira votre application Swing en application HTML / Javascript au runtime (à l’inverse de GWT qui le fait à la compilation). Aucune modification spécifique ni connaissance particulière n’est demandée par AjaxSwing : le code est en pur Java / Swing. Que du bonheur Reste maintenant à voir sur un projet d’envergure si tout se fait réellement sans coup de tournevis particulier…

Pour les nouveautés de cette 2.4, on note :

• Amélioration mémoire (vidage du buffer entre les requêtes)
• Meilleur support des mouse listeners
• Amélioration de composants (FileOpenDialog, JTable cells…)
• Meilleures performances (regexp, communication serveur…)
• Plusieurs corrections de bugs

Plusieurs démos sont disponibles avec des applications en Java Web Start et les mêmes en Ajax. Et bien sûr un lien vers les pages incontournables : licences et téléchargement.

Le coin de la technique

SoapUI 3.0 se prépare

Eviware relaie via The ServerSide, l’annonce de la sortie en version 3.0beta de SoapUi, l’outil graphique pour manipuler des WebServices.
Après l’ajout de la gestion de services REST, ce nouvel opus continue sur la même voie pour faciliter encore leurs manipulations :

• A partir des différentes requêtes et réponses, l’outil génère un schéma XML de validation/WADL des flux et ce même si le contenu échangé n’est pas du XML (par exemple JSON ou HTML)
• Ajout du support des opérations OPTIONS et TRACE
• Montée de version de la spécification WADL.
• Comme pour le taux de couverture de test des opérations d’un WSDL, il est maintenant possible d’avoir le même calcul sur les ressources, méthodes et paramètres REST (accessible seulement pour la version pro).

De plus, cette nouvelle version comporte entre autres les fonctionnalités suivantes :

• Support de JavaScript : dorénavant, en plus de groovy, il possible d’utiliser du JavaScript comme langage de script
• L’outil WS-I utilisé pour calculer son niveau de conformité WS-I Basic Profile est maintenant packagé avec SoapUI
• Le navigateur de composant est amélioré pour permettre la vision de réponse HTML et REST au contenu complexe (ex : FLASH, SVG, Images…)

A ceci s’ajoute la correction de bugs (voir la realease note complète). SoapUi se positionne encore plus comme l’outil incontournable pour manipuler WebServices et Services REST.
Bientôt sur notre blog une série d’article présentant les principales fonctionnalités de l’outil.

Comparaison Gigaspace – Coherence

Gojko Adzic (via TheServerSide) propose sur son blog une intéressante comparaison entre deux des produits phares du DataGrid, Oracle Coherence et Gigaspace XAP (dommage d’avoir laissé de coté IBM eXtrem Scale).
Cette comparaison porte sur cinq points :

• Cache de données : match nul, les fonctionnalités des deux produits sont quasi identiques.
• Processing : Gigaspace possède un modèle de processing orienté évènements et offre un bonne intégration de Spring Transaction. Coherence est plus limité.
• Déploiement : Gigaspace se positionne en remplacement des serveurs d’applications, et possède donc des mécanismes de déploiement comparables, ce que Coherence ne propose pas. D’un autre coté, le produit d’Oracle offre un mécanisme de sérialisation qui autorise plusieurs version d’une même classe à être déployées sur une grille.
• Scaling : Coherence offre un scaling dynamique (à la hausse comme à la baisse) là où Gigaspace ne fonctionne qu’avec un nombre de nœuds données.
• Persistance : là encore, les fonctionnalités offertes sont très comparables

Et comme d’habitude dans ce genre de comparaison, pas de vainqueur, pas de vaincu, seulement deux produits qui répondent à des besoins différents :

• Gigaspace XAP, plus apte à remplacer des serveurs d’applications et réaliser du calcul distribué. Le modèle de processing est plus flexible et plus riche que celui de Coherence
• Coherence, très performant dans les grilles passives (lecture seulement), car il scale dynamiquement, offre une topologie de données flexible et possède de riches librairies clientes.

Pour résumer, cet article propose une très bonne grille d’aide à la décision.

L’invocation dynamique pour Java se concrétise

Rémi Forax, l’un des 4 committers d’ASM, un framework de manipulation de bytecode largement utilisé dans le monde Java, vient d’annoncer que leur dernière version supportait l’instruction invokedynamic.

Cette instruction est définie par la JSR-292 et vise à simplifier l’invocation de méthodes non connues lors de la compilation, ce qui constitue une des principales capacités des langages dynamiques tels que Groovy. Un gain significatif de performance est donc attendu pour ces langages, puisqu’ils n’auront alors plus à s’appuyer sur un coûteux mécanisme d’introspection ou de génération dynamique de bytecode d’invocation.

Au delà des langages dynamiques qui sont les premiers destinataires de cette JSR, de nombreux frameworks pourront également profiter de cette possibilité. En effet, la manipulation de JavaBeans et d’annotations, deux concepts majeurs dans le monde JEE actuel, induisent de nombreuses invocations de méthodes découvertes au runtime. Dans de larges projets, cela conduit actuellement à la génération massive de bytecode pour éviter de très lentes introspections, induisant une forte consommation de la PermGen des JVMs.

Le support de l’instruction invokedynamic par ASM, combiné au fait que le draft actuel de la JSR-292 est d’ores et déjà implémenté et disponible dans la preview de l’OpenJDK 7 depuis la b59, permet d’être optimiste quant à la finalisation prochaine de cette JSR.

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

Retour sur le CloudCamp

Un CloudCamp s’est tenu à Paris le 11 juin, réunissant un certain nombre d’acteurs du Cloud Computing. Les CloudCamps ont été initiés par Reuven Cohen et Dave Nielsen et visent a partager la connaissance et les expériences sur ce secteur émergeant.

Ce CloudCamp s’est révélé bien plus commercial dans son contenu que les JavaCamps : de nombreux partenaires ont ainsi présenté leurs solutions pendant environ une heure avant que les réelles sessions (au nombre de quatre, se déroulant en parallèle) ne commencent. De chacune d’entre elles, on retiendra :

• Architecture du Cloud : une solution de Cloud Computing doit apporter abstraction, elasticité et automatisation. Si les deux premiers points sont d’ores et déjà couverts par les solutions actuelles, l’automatisation n’est en revanche pas encore une réalité. Ce point constituera un élément déterminant pour l’adoption du Cloud Computing.
• Cloud et Sécurité : les problèmes de sécurité que l’on connaît aujourd’hui dans les SI demeurent avec le Cloud Computing, mais de nouveaux défis s’annoncent dans le cas de clouds accessibles publiquement et répartis à travers Internet sans forcément passer par un VPN dédié.
• Cloud et Intégration : le constat est sombre. Les projets lancés par les différents éditeurs et fournisseurs surfant sur la vague du Cloud Computing ne suivent aucune standardisation. Changer de fournisseur ou de solution sur un projet constitue actuellement une modification majeure.
• Aspects business du Cloud : l’émergence du Cloud Computing draine la création de nouveaux besoins à pourvoir. Les 3 niveaux d’abstraction du Cloud Computing que sont SaaS (Software As A Service), Paas (Platform As A Service) et IaaS (Infrastructure As A Service) apportent chacun leurs spécificités en termes de monétisation et d’opportunités.

Actualité éditeurs / SSII

• JBoss veut son DataGrid
• SpringSource renforce (encore) le lien développement / production

Le coin de la technique

• Quelques nouveautés pour Apache Derby
• L’actualité d’Apache Directory Server
• La mémoire native en Java

Actualité éditeurs / SSII

JBoss veut son DataGrid

Le projet JBoss Infinispan a été initié il y a peu. Il vient de produire deux versions alpha successives. Il s’agit d’une réécriture majeure du projet JBoss Cache auquel il succède et qu’il est destiné à remplacer. Le but premier affiché par ce projet est de produire une solution de DataGrid, là où son prédécesseur n’offrait qu’une technologie de cache distribué. L’ambition est forte, puisqu’il s’agit de se positionner sur un marché dominé par les solutions commerciales que sont Oracle Coherence et IBM eXtreme Scale.

Une récente interview de Manik Surtani, project leader d’Infinispan et JBoss Cache, associée aux informations diffusées sur le site d’Infinispan, permet de mieux répondre aux différentes questions que l’introduction de ce nouveau projet peut soulever :

• Parmi les atouts prévisionnels d’Infinispan (après sa finalisation) face à Oracle Coherence, Manik Surtani met surtout en avant la nature Open Source, LGPL, de son projet. Il souligne toutefois la richesse d’Infinispan tant dans le domaine des performances (grâce à une implémentation efficace du MVCC locking) que des fonctionnalités (intégration simplifiée à Amazon EC2 et S3, compatibilité serveur Memcached).
• La création d’un nouveau projet et donc d’un nouveau nom plutôt que le maintien de JBoss Cache est justifiée pour l’équipe par la réécriture et les changements d’API. On peut aussi aisément imaginer que le nouveau positionnement ‘DataGrid’ ne coïncidait guère avec un nom de projet ‘Cache’…
• Infinispan pourra être utilisé en tant que cache Hibernate, ce qui est assez logique compte tenu de l’affiliation JBoss de ce dernier.

Face à des concurrents commerciaux bien installés sur ce marché, la tâche ne sera pas aisée pour JBoss, et le but affiché de proposer une solution équivalente à Coherence est très audacieux compte-tenu de la maturité acquise par ce produit. Ce scénario n’est pas sans rappeler le positionnement qu’avait JBoss AS lors de son arrivée sur le marché des serveurs d’application, mais l’absence de roadmap datée pour Infinispan tend à indiquer qu’il faudra probablement s’armer de patience pour savoir si l’histoire se répétera.

SpringSource renforce (encore) le lien développement / production

SpringSource a annoncé aujourd’hui le rachat de Hyperic, l’éditeur du célèbre outil de supervision du même nom.
Le partenariat SpringSource / Hyperic ne date pas d’hier (SpringSource redistribuait une version améliorée du serveur Hyperic dans son produit SpringSource Application Management Suite depuis 2007), mais cette acquisition confirme la direction affichée par SpringSource ces derniers mois : contrôler l’ensemble du cycle de vie d’une application Java, de sa conception à son exploitation.
En effet, un très grand nombre de projets Java s’appuient aujourd’hui sur le framework Spring (phase de développement). Un très grand nombre de ces développements tournent sur le serveur openSource Tomcat, dont SpringSource propose une distribution commerciale depuis peu (Spring tc Server). Et aujourd’hui, grâce à l’acquisition de Hyperic, SpringSource propose de réaliser l’exploitation de ces serveurs d’applications.

On peut d’ailleurs supposer qu’Hyperic devrait rapidement évoluer et proposer une version commerciale encore plus ‘orientée’ vers le framework Spring et le serveur Tomcat que ne l’était Spring AMS, avec une offre de support afférente.
Parmi les évolutions probables (car souvent évoquées par SpringSource comme des problèmes à résoudre pour les développeurs), nous devrions avoir :

• Gestion de la configuration au niveau Hyperic. Actuellement, Hyperic ne permet de réaliser que des opérations Stop/Start sur la ferme de serveurs. tcServer propose la gestion de la configuration du serveur. On peut donc imaginer un modèle de données qui permettrait de configurer ses tomcats directement depuis l’outil de monitoring.
• Déploiement phasé. Comme avec JBoss ON, il est souhaitable de voir apparaître un outil permettant de déployer progressivement sur les noeuds d’un cluster (probablement basé sur un outil de scripting).
• Virtualisation. Le déploiement sur des machines virtuelles types VM-Ware sera facilité.

Sur ces sujets, l’apport (et l’expérience) de Hyperic sera déterminant.

On peut s’amuser à retracer les différents rachats de Spring. En 2004, Hyperic est né d’un fork d’une partie des équipes de Covalent. En février 2008, SpringSource acquérait Covalent. Un peu plus d’un an après, SpringSource reconstitue l’entité de 2004 en acquérant Hyperic.

Javier Soltero, CEO d’Hyperic affirme qu’il s’agit là d’un mariage de raison, entre deux acteurs qui partagent la même vision de l’informatique et qui sont les meilleurs (et des standards de facto) dans leur domaine respectif (le développement Java pour SpringSource, et le management IT pour Hyperic). Il va d’ailleurs rejoindre le board de SpringSource en tant que directeur technique des outils de Management.

Parmi les effets collatéraux, on peut noter la (très probable) fin du projet (déjà mal en point) RHQ, partenariat entre RedHat et Hyperic, qui visait à créer une plate forme ‘manageable’ basée sur JBoss.
Toutefois, JBoss ayant racheté la base de code d’Hyperic avant qu’il ne devienne « public source », la fin du partenariat ne veut pas forcément dire fin de JBoss On dont le code à été très largement modifié par les équipes JBoss.

Le choix de monétisation des assets open source devrait commencer à effrayer les mastodontes de l’informatique (IBM, Oracle, Microsoft), qui avaient fait du contrôle total de la stack applicative (Java dans un cas, .Net dans l’autre) leur pré carré. C’est d’ailleurs la volonté de Rod Johnson (annoncée lors de SpringOne Europe) : devenir un ‘One Stop-By Shop’, comme peuvent l’être ces géants du monde informatique.

Le coin de la technique

Quelques nouveautés pour Apache Derby

Une nouvelle version du moteur de base de données Java de la fondation Apache vient d’être diffusée. Cette version apporte à Derby une dose d’évolutions intéressantes pouvant aider dans certains cas d’utilisation. François Orsini en présente la liste. On retiendra en particulier :

• In-memory backend : Cette fonctionnalité, particulièrement mise en avant dès la version 10.5 preview, permet de stocker une base de données en mémoire et ainsi de s’astreindre du stockage sur disque. Derby rejoint ainsi HSQLDB et H2 Database qui offraient déjà une telle possibilité, très utile dans le contexte des tests unitaires ou de certaines applications ne nécessitant pas de persistance durable.
• Roles SQL : Ils permettent de simplifier l’administration des privilèges attribués à une base de données. La documentation de Derby est d’ores et déjà à jour et permet de faire le tour des possibilités offertes.
• Generated columns : Il s’agit de colonnes dont les valeurs sont calculées à partir d’autres colonnes d’une même table. Il est également possible de déclarer un index sur une telle colonne afin d’améliorer les performances sur certains types de requêtes. Cette fonctionnalité est une version allégée des virtual columns introduites dans Oracle 11g.

L’actualité d’Apache Directory Server

Lors du dernier podcast des Cast Codeurs, Emmanuel Lécharny, committer français sur Apache Directory, a fait un tour d’horizon de ce projet. Pour rappel, Apache Directory est un projet de la fondation Apache qui produit un serveur LDAP en Java (Directory Server) et un outil de visualisation / édition de directory LDAP basé sur Eclipse (Directory Studio).

Du fait de son orientation Java, le positionnement de Directory Server sur le marché n’est pas évident, aussi les cas d’utilisation ont été longuement décrits ; on retiendra :

• Les tests unitaires, puisque le serveur LDAP peut ainsi être contrôlé et se faire injecter des données par Java lors du déroulement des tests.
• Embarquement du serveur LDAP dans l’application grâce au mode embedded de Directory Server, lorsque l’on ne souhaite pas dépendre d’un serveur externe.
• Profiter de la simplicité de configuration de Directory Server pour le mettre en place rapidement en premier lieu pour éventuellement passer ensuite à un serveur commercial.

Ainsi, lors de cette interview, il a été question d’utiliser Directory Server dans des rôles secondaires plutôt que directement en production. Pourtant, il y a un an, lors de l’ApacheCon 08, Emmanuel Lécharny s’était longuement attardé sur la question lors de sa présentation en mettant en avant les fonctionnalités exclusives de procédures stockées et de triggers pour légitimer l’utilisation de Directory Server en production. Face à l’oscillation autour de cette problématique, notons qu’Apache DS, pourrait, plus modestement, être utilisé conjointement à d’autres serveurs LDAP commerciaux par la mise en place d’un virtual directory.

Enfin, Emmanuel Lécharny a exposé une synthèse des principales nouveautés à attendre de la future version 2.0, actuellement prévue pour septembre :

• Réplication multi-master entre plusieurs noeuds Apache DS ainsi qu’avec des noeuds OpenLDAP.
• Disaster Recovery System permettant d’éviter les pertes de données suite à un crash. Cette fonctionnalité étant actuellement assurée par un journal, peu optimal, qui rend l’opération de récupération très longue.
• Configuration stockée au sein même du serveur LDAP.

La mémoire native en Java

Andrew Hall a publié deux articles très intéressants portant sur la gestion de la mémoire native dans la JVM, c’est-à-dire la mémoire consommée par la machine virtuelle mais ne faisant pas partie de la Java Heap et n’étant donc pas gérée par le garbage collector. Les systèmes d’exploitation couverts par ces articles sont Windows, Linux et AIX.

Après avoir fait un rappel sur la gestion de la mémoire par les systèmes d’exploitation, l’auteur explique en détail les différents composants Java susceptibles de consommer de la mémoire native non gérée au sein de la Heap Java. En font partie le bytecode des classes chargées par les classloaders, la mémoire allouée par le code JNI natif, les direct buffers NIO et les stacks de chaque thread. Le problème est que la mémoire totale adressable par un processus 32 bits est de 2 à 4 Go selon les cas. Des crashs de la JVM, dus à un manque de mémoire, peuvent donc parfois intervenir alors que la Java Heap n’est pas pleine.

Les solutions à cette problématique sont passées en revue, parmi lesquelles figurent : réduire la mémoire totale utilisée par la JVM en réduisant la taille de la Java Heap (via -Xmx), réduire l’utilisation de mémoire native non gérée par la Java Heap, repousser la taille limite de la mémoire adressable par le processus de la JVM en passant par exemple à un OS et une JVM 64 bits.

Au-delà des informations fournies par ces deux articles, les lecteurs intéressés par ce sujet pourront étudier le très complet, bien qu’ancien, livre de Bill Venners, ‘Inside the Java Virtual Machine’, partiellement disponible en ligne.

Actualité éditeurs / SSII

• Amazon lance son service Elastic MapReduce

Agilité

• Kanban vs Scrum

RIA

• Optimisation GWT : EntryPoint multiples

SOA

• Le calendrier se confirme pour jBPM

Le coin de la technique

• Les nouveautés du futur SpringSource dm Server
• Spring tc Server, c’est parti … en version beta

Actualité éditeurs / SSII

Amazon lance son service Elastic MapReduce

Un nouveau service, Elastic MapReduce, vient s’ajouter au catalogue Amazon. Basé sur EC2 pour la puissance de calcul et sur S3 pour le stockage, ce service permet de soumettre facilement des traitements sur un large volume de données à Amazon en s’appuyant sur le framework Apache Hadoop et son modèle de programmation MapReduce.

Par rapport au service EC2, Elastic MapReduce apporte une solution Hadoop clé en main. Ainsi, il suffit de fournir au service les données en entrée via S3 et un programme de traitement écrit soit en Java en utilisant l’API Hadoop, soit dans un autre langage grâce à Hadoop Streaming (Ruby, Perl, Python, PHP, R, ou C++). Les données produites lors du traitement sont également placées sur S3. Les jobs peuvent alors être créés et contrôlés soit depuis l’interface de management d’AWS, soit depuis une API SOAP.

Répondant à un besoin typique du cloud computing, ce service permet de se lancer dans des expérimentations de traitement distribué rapidement en délestant le développeur de toute tâche de configuration système préalable. Il est par ailleurs intéressant de noter cette mise en avant du framework Hadoop, issu du projet Nutch en 2006, qui bénéficiait déjà d’un large intérêt comme en témoigne les 3 livres qui lui seront consacrés d’ici la fin de l’année chez Manning, O’Reilly et Apress.

Agilité

Kanban vs Scrum

Sur son blog, Henrik Kniberg nous propose un document au sujet de Kanban et de Scrum. Cette première version de ce document nous explique, de manière simplifiée, les différences entre les implémentations. En voici quelques unes :

• Pas de définition de rôles dans le Kanban.
• Les estimations sont optionnels.
• Prioriser les items est optionnel.

Néanmoins, Kanban et Scrum présentent des similitudes :

• ce sont des processus d’optimisations.
• possibilité d’itérer sur plusieurs produits en même temps.

Au final, nous nous rendons compte que beaucoup de notions ne sont pas antinomiques, et selon les contextes il est intéressant de faire cohabiter certaines notions de Kanban et de Scrum.

RIA

Optimisation GWT : EntryPoint multiples

Les développeurs GWT se heurtent parfois à deux problèmes communs: un temps de compilation astronomique et des livrables très gourmands en taille.Heureusement, Matt Raible est là !

L’idée est de séparer votre application finale en plusieurs applications/écrans. Imaginons une application complète avec un seul EntryPoint qui contiendrait un front-office, un back-office et un écran standalone de statistiques : modifier le front-office impliquera la livraison de tous nos composants alors que les écrans back-office et statistiques n’ont pas été changés. Notre exemple ne contient que trois écrans différents mais selon le métier il est tout à fait possible d’envisager une dizaine d’écrans.

L’optimisation se passe sur le blog de Matt Raible avec l’article optimizing a GWT Application with Multiple EntryPoints. L’idée est simple : découper votre application en plusieurs mini-applications indépendantes (donc des écrans différents). La découpe se fera en créant plusieurs EntryPoints avec leur XML associé. On pourra alors ne compiler et ne livrer que le module souhaité (par exemple à l’aide d’un profil maven). On gagne alors en temps de compilation mais surtout en taille de livrable : ici on ne livre que ce qui doit être livré (to-be-released feature). Matt obtient alors sur son livrable un gain en taille de 56% (non négligeable).
La mise en place d’un tel découpage est simple : création d’un nouvel EntryPoint (classe java et gxt.xml), mise à jour des références dans le html et le nocache.js et enfin création d’un profil maven associé à votre entry point de release.

On peut recouper ce best-practice avec la modularisation d’une application GWT, celle-ci apportant en plus la notion de partage de module. On pourra alors créer des modules CommonsUI, StatsModule… qui seront des modules génériques pouvant être réutilisés par d’autres applications (inherit du gwt.xml). Cette pratique est très courante dans les projets GWT, mais la création d’EntryPoint de type livrable l’est déjà moins.

Avez-vous des retours concernant cette technique ?

SOA

Le calendrier se confirme pour jBPM

Le projet jBPM n’a pas connu de nouvelle version majeure depuis 2005. Pourtant ce moteur de BPM open-source très populaire fait partie de la suite JBoss Enterprise SOA Platform lancée début 2008.

La version 4 a été dévoilée en alpha en décembre dernier mais son temps de gestation particulièrement long, similaire au délai important qu’a connu JBoss AS 5, laissait planer le doute quant au calendrier. Tom Baeyens, project lead de jBPM, annonçait en début d’année l’arrivée d’une version finale pour juillet et a confirmé cette date lors d’une récente présentation au BeJUG. C’est maintenant l’équipe de JBoss Seam qui vient corroborer ce planing en annonçant l’arrivée de Seam 2.2 pour juin. Soit juste avant l’arrivée de jBPM 4 avec lequel il prévoit de s’intégrer par la suite.

Le temps de développement particulièrement long de cette nouvelle version est probablement imputable au très ambitieux module PVM (Process Virtual Machine), dont le principe a été conçu conjointement avec OW2 et son projet équivalent Bonita. Le but de PVM est d’offrir un moteur d’exécution de processus générique servant de base commune pour l’implémentation des différents langages de définition de workflow (jPDL, BPEL, Pageflow, …) supportés par jBPM. L’API de PVM reste malgré tout accessible par les développeurs souhaitant définir leurs workflows directement en Java.

Outre PVM, les autres nouveautés notables de cette version 4 seront :

• La possibilité d’utiliser BPMN dans l’éditeur graphique sous Eclipse.
• Une évolution de l’API de gestion des activities permettant un meilleur découplage.
• Un schéma de base de données plus évolutif et partitionné selon les langages de définition de processus.

Rendez vous est pris pour juillet.

Le coin de la technique

Les nouveautés du futur SpringSource dm Server

SpringSource dm Server était le produit phare mis en avant lors de SpringOne Europe 2008 de juin dernier. OSGi était alors omniprésent dans les présentations. Pourtant 9 mois après sa sortie, les débouchés ne semblent toujours pas évidents. Ceci est avant tout dû à OSGi, qui reste une technologie méconnue et dont l’introduction dans le monde du Java d’entreprise pose encore quelques problèmes en raison du modèle particulier de découpage en bundles qu’il impose.

SpringSource a présenté récemment la liste des nouveautés prévisionnelles de son dm Server 2, prévu pour juillet. Visiblement conscient des problèmes que pose OSGi, SpringSource propose plusieurs améliorations :

• Clonage de bundle : cette fonctionnalité, activée par défaut, entraînera le chargement automatique d’une seconde instance identique d’un bundle lorsqu’un conflit dû à une clause uses sera détecté. Un clone pourra également être créé manuellement pour palier au comportement de certains frameworks utilisant des variables statiques et dont le bundle se prête donc mal au partage
• Gestion des logs : elle sera revue dans la prochaine version pour permettre une configuration centralisée par application et permettra à un bundle partagé entre plusieurs application d’écrire dans le fichier de log adapté au contexte
• Bundlor : un outil de création automatisée de bundles, développé conjointement, et dont nous vous parlions la semaine dernière

Du reste des nouveautés, on retiendra surtout l’alignement avec les RFCs de l’OSGi Alliance, coïncidant ainsi avec le planning initialement prévu.

Spring tc Server, c’est parti … en version beta

Nous avions annoncé en Décembre 2008 le lancement de Tc Server, la version professionnelle de Tomcat par Spring Source. La version beta est désormais disponible. Pour mémoire, Tc Server apporte du support commercial, une simplification des installations, des outils de diagnostique avancé et des outils d’administration centralisés avec interface graphique et ligne de commande. Voici nos première impressions :

Aide au diagnostique

Tc Server apporte à Tomcat Standard des outils de diagnostique qui n’ont rien à envier à ceux qu’on trouve sur les gros serveurs JavaEE commerciaux. Nous retiendrons :

• La configuration JMX dans server.xml + catalina.properties (plutôt que dans setenv.sh) qui permet de surcroît de préciser le port d’écoute pour passer les firewalls (cf Daniel Fuchs blog : Connecting Through Firewall Using JMX – Without modifying the server application)
• La détection des requêtes HTTP lentes avec le détails des activités de Garbage Collection et d’accès Data Source (les accès web services sont prévus).
• Un mécanisme de First Failure Data Capture (heap dump, threads dump, état des composants Tomcat) pour les requêtes HTTP en erreur.
• La détection des requêtes SQL lentes, des deadlocks inter-threads et de durée de Garbage Collection excessive

Installation

L’installation reprend les bonnes pratiques Tomcat de séparer les binaires tomcat (CATALINA_HOME) des configurations des instances (CATALINA_BASE) et de grouper les paramètres spécifiques à chaque instance dans catalina.properties. Ce mode d’installation facilite grandement les montées de version de Tomcat ou de JVM et la gestion de plusieurs instances Tomcat voisines.

Le tuning des configurations JVM (setenv.sh) et Tomcat (server.xml) est très pédagogique.

Le script de création des instances ne prend en compte pour le moment ni l’incrément automatique des ports d’écoute (pour ne pas collisionner avec les instances voisines) ni la configuration Apache Httpd (mod_proxy_http) qui sont en amont des Tomcat.

Nous n’avons pas trouvé la commande tcadmin.sh qui permet de gérer les groupes de serveurs. La documentation semble en avance sur le produit livré ; c’est assez rare dans le monde du logiciel .

Administration et Spring AMS

Spring AMS Tc Server est une extension du socle déjà mature Spring AMS qui est lui même basé sur Hyperic. Nous noterons comme bémol qu’AMS repose sur une ancienne version d’Hyperic, qu’il n’est pas possible de déployer les plugins Spring AMS dans Hyperic et que l’inverse est certes possible mais demande un travail autant contractuel que technique d’installation. La solution la plus humble est de faire cohabiter un Spring AMS (serveur + agents) dédié aux serveurs Java EE aux côtés d’un Hyperic (serveur + agents) dédié aux autres composants à superviser.

Pour revenir sur Spring Tc Server, nous remarquerons la configuration par console graphique AMS des serveurs Tc Server avec ses judicieux conseils de paramétrages (le déploiment de configuration ne supprime pas les commentaires dans server.xml). Les alertes deadlock et temps de garbage collection excessifs sont remontés dans Spring AMS.

Au final, cette version beta est bien agréable pour les afficionados de Tomcat. La documentation est bien entamée, les fonctionnalités intéressantes et l’ensemble très pédagogique pour les connaisseurs. Ces qualités techniques se transformeront-elles en déploiement dans nos data center ? Il faudra convaincre les exploitants du bien fondé de passer d’un modèle open source gratuit à de l’open source professionel …

Actualité éditeurs / SSII

• Sun, Java et le JCP
• RIA, SOA, Tim Bray tire dans le tas

SOA

• Red Hat JBoss choisit d’investir dans CXF

Le coin de la technique

• Enfin une roadmap détaillée pour le JDK7
• La création de bundles OSGi selon SpringSource
• Utiliser le nuage pour réduire les coûts d’intégration continue.
• Outils Glassfish pour Eclipse

Actualité éditeurs / SSII

Sun, Java et le JCP

Depuis quelques jours, une agitation se crée au sein de la communauté Java autour des agissements de Sun vis-à-vis de son projet OpenJDK 7. Plusieurs observations permettent en effet de penser que le JDK 7 pourrait bien ne pas être basé sur un standard du JCP comme c’est habituellement le cas :

• Neil Bartlett remarque que le projet Jigsaw, poussé par Sun pour être le système de modules utilisé par le JDK, n’est pas défini par une JSR. Ceci en fait donc une technologie propriétaire dont il doute de la légitimité face à OSGi, un standard bénéficiant de 10 années d’expérience.
• Stephen Colebourne constate que Sun ne fait plus mention de « Java 7″ depuis quelques temps, mais seulement de « JDK 7″ qui n’est qu’une implémentation, là où « Java 7″ qualifierait un standard.
• Anne Thomas Manes faisant des observations similaires, compare l’OpenJDK à la position de framework Open Source « rebelle », non standard, que tient Spring.
• Stephen Colebourne encore, visiblement très impliqué par ce débat, revient dans une série de billets sur les différents qui opposent Sun à la fondation Apache, rappelant l’historique, ainsi que sur la problématique de propriété intellectuelle au sein du JCP de manière générale.

Si le JDK 7 devait être finalisé sans qu’aucun standard ne le soutienne, cela constituerait un évènement majeur, puisque l’avenir deviendrait incertain pour les JVMs fournies par d’autres éditeurs tels qu’Oracle ou IBM.

RIA, SOA, Tim Bray tire dans le tas

C’est dans une interview pour InfoQ que Tim Bray co-auteur du XML nous donne son avis sur les technologies RIA. Selon lui, les RIA type Flex, Silverlight et JavaFx n’ont pour but que de fournir des applications toujours plus immersives et de moins en moins utiles. Il modère tout de même ses propos en s’appuyant sur des exemples de réussite comme Google et Yahoo! qui utilisent de manière élégante Ajax et consort. En bref, pour lui les avantages des interfaces web sont la simplicité et la rapidité, Tim ne croit donc pas en la longévité du RIA. Rien de mieux pour faire de l’applicatif lourd que de l’applicatif lourd.
Dans son interview, il explique rapidement que l’émergence des Web Services et des architectures de type SOA s’est faite en dépit du bon sens. Au début chacun y allait de son format XML privé et ça fonctionnait, mais on a voulu généraliser le problème et fournir une solution pour tous. Cette volonté de créer une pierre philosophale pour exposer ses services n’a apporté que des difficultés d’implémentation, d’intégration et surtout d’interopérabilité. Bref, Tim est assez pessimiste en ce qui concerne les ‘WS-*’, il soutient en revanche REST qui selon ses termes, n’est qu’une reformulation des bonnes pratiques des Web Oriented Architectures.
Enfin, il reste très discret sur Sun et sur le cloud computing en indiquant tout de même que pour le moment le département se cherche un peu. Faut-il fournir des solutions et des outils pour implémenter des nuages ou bien héberger directement des nuages et devenir fournisseur?

L’interview complète sur InfoQ
La réponse de Yakov Fain

SOA

Red Hat JBoss choisit d’investir dans CXF

Red Hat a annoncé la semaine dernière qu’elle devient un « key contributor » du projet Apache CXF.
A terme, comme l’explique Sacha Labourey sur son blog, cela signifie que JBossWS qui laisse aujourd’hui le choix de l’implémentation Web Service (ne fournissant qu’une couche d’abstraction) ne fournira plus que l’implémentation Apache CXF. C’est dommage, d’autant plus que les dernières releases de CXF ont été plutôt douloureuses et riches en bugs.
D’un autre côté, la participation active des équipes JBoss au projet ne peut qu’aider à rectifier le tir. Gageons donc que les futures releases d’Apache CXF seront de bien meilleures factures que celles de 2008.

Le coin de la technique

Enfin une roadmap détaillée pour le JDK7

Lors de la conférence Devoxx de décembre dernier, un keynote avait particulièrement retenu l’attention : Mark Reinhold présentait alors la liste des fonctionnalités qui seraient intégrées au futur JDK 7, ainsi qu’une date pour la version finale.

Mark Reinhold annonce maintenant la mise en ligne d’un calendrier détaillé des milestones prévus et des fonctionnalités associées.

L’analyse de ces informations aboutit à quelques remarques :

• La période annoncée en décembre dernier pour l’arrivée d’une version finale, à savoir « début 2010″, est légèrement décalée puisqu’un final milestone est prévu pour le 18/02/2010 suivi d’une phase de release candidate d’un à deux mois. Ceci porterait donc l’arrivée d’une version finale à avril ou mai 2010.
• La liste des nouveautés reste globalement inchangée à une exception près : il n’est plus question de MVM (Multiple Virtual Machines) qui devait permettre d’exécuter plusieurs applications au sein d’une même VM. Cette fonctionnalité, particulièrement intéressante dans le contexte du regain d’intérêt pour les Applets Java et autres applications JavaFX embarquées dans le browser, était annotée d’un « maybe » il y a deux mois et était visiblement trop ambitieuse pour résister à la pression du calendrier.
• La JSR-310 (Date and Time API) n’avait pas été citée en décembre et ne l’est toujours pas. L’appel à l’aide du spec lead Stephen Colebourne aura donc été vain. En effet, comme il le faisait alors remarquer, dans le cas d’une inclusion au JDK, JDBC et NIO2 seraient impactés afin de prendre en compte la nouvelle API. Compte-tenu de cet impact, il était essentiel que cette JSR puisse être finalisée rapidement. Or son statut, toujours annoncé comme « inactive » par le site du JCP, tend à nous faire penser que la classe java.util.Date a encore de « beaux » jours devant elle.

La création de bundles OSGi selon SpringSource

SpringSource annonce l’arrivée de Bundlor, son outil de création de bundles OSGi, actuellement en version 1.0M2.

Dans un projet OSGi il est en effet nécessaire que l’ensemble des modules de l’application et des librairies tierces soient fournis sous forme de bundles. La création de bundles pour les modules dont on a le contrôle n’est pas un problème en soit, pour les librairies tierces, il en est tout autrement.

Deux possibilités s’offrent alors au développeur : obtenir la librairie qu’il recherche packagée sous forme d’un bundle OSGi sur un repository dédié (celui de SpringSource par exemple) ou créer ce bundle par lui-même. Dans ce dernier cas, il faudra analyser l’ensemble des dépendances de la librairie pour créer un manifest adapté. C’est là que les outils de création automatisée de bundles interviennent. Bnd était le seul disponible jusqu’alors, crée par Peter Kriens, Technical Director d’OSGi. SpringSource amène donc désormais son propre outil.

Bundlor est justifié par SpringSource par quelques fonctionnalités non présentes dans Bnd telles que la création incrémentale de manifests et l’intégration à Eclipse via un plugin dédié.

Malgré l’apparente efficacité de ce type d’outil, il est indispensable de ne l’appliquer qu’à des librairies tierces. En effet un des intérêts d’OSGi réside dans sa capacité à n’exposer qu’une partie soigneusement sélectionnée des interfaces d’un module, ce que seule une intervention humaine sera à même d’effectuer correctement.

Utiliser le nuage pour réduire les coûts d’intégration continue.

Il est de notoriété publique que plus la fin d’un sprint approche, plus les ressources du serveur d’intégration sont sollicitées. En outre, c’est dans ces périodes que les développeurs ont besoin des feedbacks les plus rapides. Alors, que faire ? S’offrir une machine surpuissante, dédiée à l’intégration continue, mais qui ne sera que rarement utilisée à pleine capacité ?
Atlassian, l’éditeur du serveur d’intégration continue Bamboo, propose de résoudre ce problème dans la version 2.2 de son produit, en offrant la possibilité d’utiliser « Elastic Bamboo », un agent distant s’exécutant sur le nuage Amazon EC2. Ainsi, la disponibilité et la puissance sont maximales lorsque l’équipe en a besoin, tout en limitant les coûts.
Et comme Atlassian utilise Bamboo en interne, certains plâtres sont déjà essuyés :

• Les builds doivent réellement être indépendants de l’environnement (à vous de construire vos builds en étant conscients de ce problème).
• Dans le cas standard, les dépendances doivent être téléchargées à chaque build (l’instance de build disparaissant du nuage lorsqu’elle se termine). Une solution peut être d’utiliser une image disque sauvegardée sur le nuage.

Toutes les astuces de Edwin Wong pour paramétrer votre serveur d’intégration continue sur le nuage se trouvent sur le blog d’Atlassian.

Outils Glassfish pour Eclipse

Sun vient de sortir la version 0.9 (la version 1.0 arrive bientôt) de son bundle.
Celui-ci intègre:

• Eclipse 3.4.1
• Serveurs Glassfish v 2.1 et v3 Prélude
• JDK 1.6 Update 12 (optionnel)
• Une série de plugins permettant de configurer votre serveur J2EE, ainsi que vos WebServices (Soap ou Rest) depuis l’IDE. (Plus de détails sur les plugins, ici).

Ce bundle offre l’avantage de fournir un paquet tout-en-un. Il est destiné aux développeurs et aux organisations qui n’utilisent pas NetBeans, mais Eclipse. Celui-ci étant l’IDE le plus répandu. Sun élargit ainsi son public et se rapproche de la grande communauté d’Eclipse.

Actualité éditeurs / SSII

• JBoss AS 5, ce fut long mais c’est parti
• SpringSource tc Server : un dm Server sans ses modules
• Quoi de neuf dans Spring 3.0 M1 ?
• Sortie de Spring Integration 1.0.0
• Sortie d’Hibernate Search 3.1

Agilité

• L’agilité chez IBM

RIA

• Au pied du sapin : JavaFX GA
• Silverlight sous Linux

Le coin de la technique

• Nouveau mode hosté pour GWT 2.0

Actualité éditeurs / SSII

JBoss AS 5, ce fut long mais c’est parti

Sacha Labourey, CTO de JBoss, nous avait parlé lors de sa venue au Paris JUG la semaine dernière de l’imminence de cette annonce que la communauté attendait depuis longtemps : JBoss AS 5 est enfin releasé !

Les principaux composants de JBoss AS 5

• JBoss Micro Container (MC) : remplaçant du JMX Kernel, MC est le conteneur du serveur d’applications. Il offre le cycle de vie des différents modules (installation, démarrage, arrêt, désinstallation).
• JBoss Messaging (JMS) : déjà utilisé dans JBoss AS 4, JBoss Messaging est le successeur de JBoss MQ. La version 2 de JBoss Messaging est en cours de développement; les synergies avec Red Hat Messaging sont prévues ; les efforts pour faire converger les deux middlewares de message seront vraisemblablement importants.
• JBoss Transaction : issu du rachat d’Arjuna Transaction Service en 2005, ce composant mature n’a pas connu d’évolution significative avec AS 5.
• JBoss WS : stack Web Service ; la multiplicité de ses implémentations SOAP (native, adapteur pour Glassfish Metro ou pour Apache CXF) rend compliquée la compréhension de ce composant.
• Clustering : la haute disponibilité et la réplication reposent sur le mature et dynamique JBoss Cache (aujourd’hui en version 3) qui repose lui-même sur la librairie de communication multicast JGroups.
• JBoss Web : fort de son long passé de commiter Tomcat, JBoss package sa version optimisée du moteur de servlet de la fondation Apache.

Pourquoi JBoss a-t-il mis autant de temps à sortir cette version ? Des difficultés pour implémenter Java EE 5 ?
JBoss n’a pas eu de difficultés particulières à implémenter les EJB 3 ou JPA qui étaient déjà disponibles dans JBoss AS 4.2. Java EE 5 est la partie émergée de l’iceberg AS 5. Ce qui a pris du temps à JBoss est la refonte complète de son serveur d’applications. Les fonctions structurelles du middleware (transactions, clustering, messaging, sécurité, administration, etc.) sont désormais séparées des applications déployées qui peuvent être packagées au format Java EE mais aussi OSGi, Spring, Ruby On Rails ou tout autre format dès lors qu’un deployer (i.e. adaptateur) est disponible.

JBoss Micro Container est-il une victime du syndrome Not Invented Here ?
La réponse est complexe et le choix de JBoss plein de mesure. Le projet MC a été lancé alors que la bataille (plus politique que technique) entre Java Module System et OSGi faisait rage. Sun misait sur le projet HK2 pour son serveur Glassfish et s’est finalement rabattu sur le conteneur OSGi Apache Felix. SpringSource a tellement amélioré OSGi que le résultat rendait OSGi méconnaissable (adieux les ServiceTracker et autres Declarative Services) ; le pari a réussi et Spring dm Server est en cours de standardisation par l’OSGi Alliance sous le nom de Blueprint Component Model. JBoss, pourtant habitué des contributions aux standards Java (cf. JPA, Web Beans, etc.) a cette fois ci préféré commencer cavalier seul avec un Micro Container qui supporte OSGi comme il aurait pu supporter Java Module System.

Si JBoss AS 5.0 est une refonte complète, il risque d’être buggué
Le risque n’est pas nul, mais nous remarquerons que la plupart des composants fondamentaux sont matures et n’ont pas été impactés par la refonte 5.0 (transactions, messaging, etc.).

Le chantier AS 5 a-t-il été trop ambitieux ?
Les autres serveurs d’applications ont déjà été refondus (Websphere 6.1) ou sont en cours de refonte (Glassfish 3). Cette remise à plat était importante. Cependant, JBoss a pris beaucoup plus de temps qu’il ne le prévoyait et a dû changer certaines méthodes de travail pour atteindre son objectif. Sacha Labourey a notamment expliqué que le mécanisme de build a été changé en cours de route et que le travail open source collaboratif à distance par forum/mailing-list interposés avait touché ses limites.

Les clients ont-ils perdu patience ? Ont-ils changé de serveur ?
Les clients ont sûrement été déçus par l’attente mais pas tellement plus que les clients Websphere et JBoss AS 4 proposait déjà les EJB 3 et JPA. Ensuite, Glassfish a surement pris des parts de marché à JBoss AS mais c’est plus probablement lié à l’essor de Glassfish qui se fait au détriment de ses concurrents JBoss, Websphere et Weblogic.

En conclusion, JBoss AS 5 est une bonne nouvelle pour l’Open Source Java et rappelle la vitalité du modèle économique du Professional Open Source que JBoss a contribué à inventer.

SpringSource tc Server : un dm Server sans ses modules

L’actualité Spring est particulièrement riche cette semaine : SpringSource a annoncé lors des conférences de SpringOne Americas l’arrivée prochaine d’un nouveau serveur d’applications : le tc Server. Non, il ne s’agit pas d’un second renommage de leur dm Server, mais bel et bien d’un nouveau produit. Comme son nom l’indique, tc Server n’est ni plus ni moins qu’un Tomcat gonflé en fonctionnalités et en support, permettant de répondre aux problématiques de production.

Selon SpringSource, ce nouveau serveur est destiné à trois types d’utilisateurs :

• Les utilisateurs de Tomcat, désireux d’acquérir du support en production et/ou des fonctionnalités supplémentaires d’aide à la configuration et de diagnostics.
• Les utilisateurs de serveurs d’applications JEE qui n’utilisent pas d’EJB, désireux de migrer vers une solution plus légère.
• Les futurs utilisateurs de dm Server, désirant modulariser leur application.

Par ailleurs, SpringSource a récemment annoncé dans sa roadmap une compatibilité Tomcat dans sa prochaine version de dm Server (Jersey) prévue pour Q2 2009. À terme, ces deux serveurs ne risquent-ils pas de se marcher dessus ? Vu de l’extérieur, cela donne l’impression que ce nouveau tc Server a été créé dans le but de rassurer les utilisateurs : pas besoin d’être modulaire pour tourner sur une plateforme SpringSource.

Ce chevauchement dans l’offre nous laisse entrevoir une stratégie intéressante de la part de SpringSource :

1. Attirer en douceur les utilisateurs via un simple support Tomcat avec tc Server.
2. Les aiguiller par la suite vers une solution plus complète basée sur dm Server.

Pour cela, Spring compte tout d’abord mettre en avant ses fonctions Java EE classiques (monitoring avancé, transactions distribuées), puis, dans un deuxième temps, ouvrir le développement sur un modèle de composants Spring Module. Tout l’enjeu de cette stratégie est de convaincre les exploitants. Une fois que dm Server sera suffisamment bien implanté, les développeurs devraient se mettre à déployer leurs propres modules OSGi.

Cette distinction, techniquement non nécessaire, nous montre encore à quel point la monétisation du libre et la vente de support restent difficiles. La tarification des services reste au centre de la stratégie (et c’est bien compréhensible) : avec ce nouveau serveur, SpringSource nous propose également une nouvelle grille de tarifications allégée.

Quoi de neuf dans Spring 3.0 M1 ?

Le premier milestone du Spring nouveau est arrivé, annoncé par Jurgen Holler ce vendredi sur son blog. Comme nous l’annoncions dans une précédente revue de presse, Spring 3.0 M1 sort avec un léger retard par rapport à la roadmap Spring prévue.

Utilisateurs de Spring 2.5, les nouveautés apportées par cette nouvelle version ne devraient pas vous dépayser : peu de nouveautés fonctionnelles, mais un gros travail de refactoring interne.

Modifications techniques internes :

• Migration de gestionnaire de source : CVS vers SVN, dont voici l’adresse.
• Refactoring du projet en modules, le trunk contient une vingtaine de sous projets : org.springframework.core, org.springframework.aop, org.springframework.expression …
• Chaque module est commité avec sa configuration Eclipse prête à l’emploi, vous trouverez donc les .project, .classpath et même les répertoires .settings directement sur le svn.
• Vous y trouverez également les fichiers de configuration de build Ivy et un début de configuration Maven. Cette dernière n’est probablement pas fonctionnelle : les derniers commits datent de fin d’octobre pour les fichiers Maven, alors que des modifications ont été effectuées plus récemment fin novembre sur la configuration Ivy. D’ailleurs, les .classpath ne vous y tromperont pas, ils contiennent tous la variable d’environnement IVY_CACHE.
• Refactoring des sources, chaque module utilise maintenant les fonctionnalités Java 5, le code interne en est simplifié.
• Montée de version des tiers frameworks : JRuby 1.1 et JUnit 4.5. La montée de version de JUnit simplifie l’utilisation de ses extensions.

Nouvelles fonctionnalités :

• Arrivée de Spring EL utilisable dans n’importe quel composant Spring (y compris ‘core’). Vous pouvez par exemple utiliser la syntaxe #{ … } lors de la définition de vos beans (XML et/ou annotations) pour permettre de définir au runtime la valeur de certaines propriétés de vos beans prototypes.
• Support de REST intégré dans Spring MVC.
• … le reste à venir dans les milestones M2 et M3 qui suivront, prévus pour Q1 2009.

Nous avions également publié un article en octobre présentant les principales nouveautés de Spring 3.0.

Sortie de Spring Integration 1.0.0

La version 1.0.0 GA de Spring Integration, le « light weight ESB«  de SpringSource a été annoncée cette semaine lors du dernier SpringOne Americas.

Comme nous l’expliquions dans notre Introduction à Spring Integration, cette implémentation légère des Enterprise Integration Patterns vise à simplifier le développement de solutions d’intégration d’entreprise et à faciliter l’adoption par les utilisateurs de Spring des principes EDA (Event Driven Architecture).

Sortie d’Hibernate Search 3.1

La version 3.1.0 d’Hibernate Search a été mise à disposition cette semaine. Comme l’explique Emmanuel Bernard dans l’article « Hibernate Search 3.1 is out: performance, robustness and new features on the menu« , cette nouvelle version met l’accent sur l’amélioration des performances, la robustesse du code et l’utilisabilité.

Comme nous l’expliquions dans notre Introduction à Hibernate Search, Hibernate Search est un moteur d’indexation et de recherche full-text reposant sur Apache Lucene. Il prend ainsi en charge la gestion d’un index Lucene et sa synchronisation avec une structure objet persistée en base de données.

Agilité

L’agilité chez IBM

Scott Ambler, responsable du développement agile chez IBM, a été interviewé par InfoQ sur l’état présent de l’agilité et son futur.
En se basant sur l’étude 2008 de Dr. Dobb’s, il rappelle que 69% des organisations font au moins un projet agile. L’agilité est une réalité. Le TDD fait aussi parler de lui mais ceux qui le pratiquent sont moins nombreux.

Une autre étude a montré que les équipes agiles font autant de documentation que les équipes traditionnelles, et même plus de modélisation upfront (88% des équipes agiles), que ce soit sur papier ou avec des outils plus sophistiqués.
Abordant les problèmes liés à l’introduction de l’Agilité dans les grandes équipes, Scott cite les 2 points les plus courants qui sont les équipes de grande taille (5000 ?) et les équipes distribuées. Il ajoute un 3e point : la gouvernance.
L’Agilité permet une gouvernance plus efficace que les projets traditionnels, en laissant le contrôle du périmètre, du budget et de l’agenda aux intervenants (stakeholders).
Concernant les équipes distribuées, l’étude du Dr Dobb’s rapporte le succès des projets mesuré par leurs clients :

• équipes colocalisées : 83%
• équipes proches (étages différents, bâtiments différents) : 72%
• équipes distribuées (qui nécessitent l’avion) : 60%

Scott conseille donc d’éviter les équipes distribuées. Si l’on ne peut vraiment pas, il conseille d’organiser les équipes en fonction de l’architecture afin de minimiser la communication entre les différents lieux. Cela nécessite notamment un « architecture owner », responsable de l’architecture, mais qui ne reste pas dans sa tour d’ivoire comme on peut en voir sur certains projets.

L’autre conseil pour les équipes distribuées est de s’équiper de bons outils. Il présente le nouveau produit Rational Team Concert, basé sur Eclipse et la plateforme Jazz, qui facilite la collaboration de l’équipe.

Pour finir avec le futur de l’agilité, Scott reprend son analogie avec l’astronomie :

• Avant on pensait que « tout tourne autour de la Terre ». C’est la communauté traditionnelle qui pense que « tout tourne autour de l’engineering et de la documentation ».
• Aujourd’hui la communauté agile pense que « tout tourne autour du soleil », c’est-à-dire « autour du développeur ».
• Demain nous verrons comme Newton que « tout tourne autour de tout ». Nous devons avoir une vision entreprise et non par silo.

Avoir une vue d’entreprise sur l’informatique est extrêmement difficile, mais nécessaire pour construire des applications de niveau entreprise et de haute qualité.

RIA

Au pied du sapin : JavaFX GA

Après presque 2 ans d’attente, JavaFX est enfin disponible en version finale. Enfin pas tout à fait : JavaFX Mobile, initialement dans le scope de cette première version, est repoussé à février 2009, et les OS Linux et Solaris ne sont pas (encore) supportés.
Cette version 1.0 tient elle malgré tout les promesses entrevues lors de la parution de la preview ?
Et bien, pas vraiment.
Les défauts rédhibitoires que nous y avions décelés sont toujours là : le seul IDE de développement disponible est Netbeans (sans même l’inclusion d’un éditeur graphique), les composants graphiques de haut niveau (hormis les portages Swing) manquent toujours à l’appel…
Qu’est ce qu’apporte vraiment cette version 1.0 ? A première vue, l’effort a été porté sur la documentation : la Javadoc a été mise à jour et est relativement complète. La galerie d’exemples et de tutoriaux ‘officielle’ a été copieusement alimentée. On regrettera cependant que cette galerie mette l’accent sur le spectaculaire, plus que sur le fonctionnel (aucun exemple d’intégration avec un back end Java ou une base de données).
Au rayon des nouveautés, on notera la présence de codecs audio et video, permettant d’intégrer facilement du contenu multimédia (par l’entremise d’un encodage en Flash).
Sur un niveau moins technique, on peut noter la présence de 2 plugins pour les produits Adobe, Photoshop et Illustrator, qui devraient faciliter les échanges entre web designers et développeurs J2EE.
A noter enfin, sur un plan plus marketing, la présence d’un émulateur mobile, qui préfigure ce que pourrait être JavaFx Mobile.
En conclusion, cette première version n’est pas vraiment au niveau des attentes qu’elle a suscitées. Cependant, nous restons une fois de plus sur l’agréable impression de pouvoir faire de jolies interfaces en Java.
A notre sens, la prochaine étape déterminante sera l’adhésion de la communauté à cette nouvelle technologie, qui devrait permettre l’émergence de composants de haut niveau (un travail auquel s’est déjà attelé James Weaver), en espérant que ceux ci seront incorporés dans les prochaines versions.
Reste que le produit de Sun est en retard par rapport à ses concurrents, et que la volonté de couvrir toutes les plateformes à la fois (desktop, mobile, télévision) pourrait se révéler à court terme un handicap pour cette technologie émergente.
Alors, Sun s’est il fourvoyé avec Fx, comme le pense Tim Bray ? Seules les futures versions nous le diront.

Silverlight sous Linux

La version 1.0 beta de Moonlight est disponible.
Moonlight est une implémentation open source de Silverlight pour Linux / Unix, portée par Novell et développée par le projet Mono. Cette béta est disponible pour un grand nombre d’environnements (Ubuntu, Suze, Fedora…) en 32 ou 64 bits.
Elle permet l’exécution de scripts Silverlight 1.0, la diffusion de contenu (MediaPack 1.0)…
Elle sera disponible en version finale le 20 janvier 2009.
Pour pouvoir profiter au maximum de Silverlight sous Linux, il faudra attendre la version 2 de Moonlight (support complet de Silverlight 2.0 et des dernières innovations Microsoft). Elle devrait être disponible en béta courant avril, puis en finale durant septembre 2009.
La roadmap complète est exposée sur le site du projet Mono.

Le coin de la technique

Nouveau mode hosté pour GWT 2.0

Les nouveautés des prochaines versions 1.6 et 2.0 de GWT continuent d’affluer.
Ainsi, après la possibilité de pouvoir fragmenter son application, c’est une fois de plus chez Sami Jaber que l’on apprend en vidéo l’une des grosses fonctionnalités à venir : le nouveau « Hosted Mode » de GWT 2.0.
Alors qu’aujourd’hui ce mode se lance dans une nouvelle fenêtre de votre IDE, demain vous pourrez le lancer directement dans votre navigateur (en tout cas ceux gérés pour l’instant).
Le mode reste toutefois celui que l’on connaît à savoir que GWT simule un site compilé (moteur de rendu) i.e. qu’aucun Javascript n’est généré. L’intégration avec des plugins comme Firebug sera donc limitée… Le mode Debug et le rafraichissement du navigateur suite à modification du code GWT sont bien sûr conservés.

Agilité

• Scrum et XP depuis les tranchées
• Scrum de scrums

RIA

• FlexMonkey 0.5
• Sortie de SmartGWT

Le coin de la technique

• Améliorez la testabilité de votre code
• Nexus pour chercher dans les repositories Maven
• Distribuez vos tests JUnit avec GridGain
• Tomcat : Trucs et astuces des pros de SpringSource

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

• Sacha Labourey au Paris JUG mardi pour une soirée JBoss

Agilité

Scrum et XP depuis les tranchées

Le livre référence de Henrik Kniberg, disponible sur InfoQ, vient d’être traduit en français (disponible en pdf ici).
Guillaume Mathias (Xebia) a participé à cette aventure aux côtés de Bruno Orsier, Emmanuel Etasse et Christophe Bunn.
Merci aux auteurs pour ce formidable don à la communauté Agile francophone.

Scrum de scrums

Une des questions récurrentes concernant l’adoption des démarches agiles sur une large échelle est celle de la synchronisation de nombreuses personnes. À ce sujet, InfoQ revient sur l’un des outils proposés par la méthode, le Scrum de Scrums. Allan Shalloway expose les problématiques d’un ‘grand’ projet Scrum, où plusieurs équipes interviennent sur la réalisation de modules inter connectés :

• Problématique technique : adopter une démarche agile, c’est éviter de réaliser des fonctionnalités non nécessaires. Ainsi, si une sous équipe ‘A’ créé un service, dont l’équipe ‘B’ aura peut-être besoin dans une itération ultérieure, rien ne l’oblige à exposer ce service. Quand ‘B’ aura besoin du même type de service, plusieurs questions surgiront : ‘B’ est-il au courant de l’existence de ce service. Si oui, qui doit le modifier pour qu’ils répondent aux besoins de ‘A’ et de ‘B’ ?
• Synchronisation d’équipe : les Scrums Masters et les Product Owners ne sont pas les mêmes pour les équipes ‘A’ et ‘B’. Les problématiques de synchronisation sont évidentes si on se place du point de vue du product owner (Cette fonctionnalité existe t’elle déjà ? Est elle est prévue ? …)
• Intégration du produit final : il n’est pas simple de délivrer un produit final fonctionnant de bout en bout juste en accolant les composants développés par les différentes équipes.

C’est pour cela qu’a été pensé le Scrum of Scrums.
Allan Shalloway, dans le cadre de la rédaction de son livre « Lean Software Development: Scaling Agile to the Enterprise » a collecté les retours d’utilisateurs sur ce ‘super’ daily scrum.
Pour Mike Dwyer, le SoS sert à gérer la décomposition des users – stories afin de veiller à ce qu’une fonctionnalité ne soit pas réalisée en double.
Pour Ilja Preuß, le SoS permet d’identifier les points d’entraide possibles, les impacts des différentes équipes sur le système, mais surtout, cette réunion permet de renforcer le sentiment d’appartenance à un seul et même projet.
Christophe Louvion a utilisé le SoS pour gérer l’intégration des sous composants au jour le jour. Il a aussi utilisé le SoS pour maintenir une méta-équipe, composée de membres seniors de chacune des sous équipes, et chargée de gérer les problématiques transverses du projet (rédaction des normes, intégration end to end, revues d’architecture…)

Enfin, Walter Bodwell partage sa recette secrète pour un SoS pleinement opérationnel : il faut qu’il soit court (15 minutes), concis, centré autour de l’information qu’on veut communiquer aux autres. Toutes les problématiques particulières doivent être abordées dans des réunions en tête à tête. Le SoS doit permettre d’identifier les points bloquants, et de les rappeler à tous (tous les jours s’il le faut) jusqu’à leur résolution.
Enfin, comme la problématique des SoS est attenante à celle des équipes de développement distribuées, il peut être utile, afin de conserver au SoS une pertinence maximale, de préparer quelques notes pour la réunion.

RIA

FlexMonkey 0.5

Lors de l’une de nos revues de presse, nous vous présentions FlexMonkey (framework de tests automatisés OpenSource pour Flex).
Ce projet vient de voir arriver la version 0.5 et permet :

• Une configuration afin de pouvoir lancer FlexMonkey par des systèmes de build (et plus particulièrement Ant).
• Un refactoring de l’API afin de séparer l’UI et le core.
• Une séparation entre la gestion des tests automatisés (FlexMonkey.swc) et le runner FlexUnit (FlexMonkeyUI.swc).

Pour un produit aussi jeune, ce dernier permet d’effectuer des tests convenables sous une application Flex. L’automatisation des tests sous Flex lève une barrière à son adoption, alors qu’attendez-vous ?

Sortie de SmartGWT

Sanjiv Jivan, ex-auteur de GWT-Ext a annoncé hier la sortie de SmartGWT, un nouveau Wrapper GWT au dessus d’un Framework Javascript très complet : SmartClient.

Les plus de SmartGWT par rapport à GWT-Ext :

• La richesse des composants fournis par l’api.
• L’amélioration des performances (peu de temps de latence, utilisation de l’asynchrone systématique …).
• Un code Java plus léger et plus consistant.
• Une intégration avec des services REST et à base de WSDL.

Les moins :

• Un style visuel par défaut moins attrayant que celui de son rival.
• Le niveau d’abstraction est le même que sur GWT-Ext. Dès qu’on souhaite customiser un composant ou créer un comportement différent, il faut la plupart du temps mettre le nez dans le code Javascript.

Le code source du projet est fourni sous licence LGPL.
Une démo de SmartGWT en action est disponible.
Notons aussi, pour cette occasion, un petit jeu de questions / réponses chez InfoQ.

Le coin de la technique

Améliorez la testabilité de votre code

Misko Hevery, coach Agile à Google, partage sur son blog quelques-unes des recommandations et alertes que Google suggère à ses développeurs afin de garder le code le plus propre et le plus testable possible. Rien de bien étonnant, la majorité des points abordés sont connus et relèvent du bon sens. Cependant, une piqûre de rappel ne fait jamais de mal.

Misko a donc regroupé ceux-ci en ‘fléaux’. Ces 4 thèmes permettent de vérifier ou d’améliorer simplement la testabilité d’une application (la liste ne se veut pas exhaustive) :

• Assurez-vous que vos constructeurs n’effectuent aucun véritable traitement. Alertes : utilisation du mot clé new, appel à des méthodes statiques, présence de conditions ou de boucles, utilisation de blocs d’initialisation, initialisation trop complexe.
• Contentez-vous d’utiliser les objets attributs de vos classes. Alertes : invocations chaînées trop profondes du type getObject1().getObject2().getObject3(). Objets avec des noms suspects comme ‘context’, ‘environnement’, ou ‘manager’.
• Utilisez les objets stateful à bon escient. Alertes : utilisation d’un singleton, utilisation d’un champ ou d’une méthode statique, présence de bloc statique d’initialisation. Misko est d’ailleurs l’auteur d’un projet sur Google Code permettant de détecter différents types de singletons.
• Découpez votre code, évitez les classes trop volumineuses. Alertes : les objets qui ont plusieurs fonctions distinctes, les classes difficiles à comprendre rapidement, les classes possédant des attributs qui ne sont utilisés dans aucune méthode.

Misko est également l’auteur d’un autre projet permettant l’analyse de la testabilité de votre projet à partir de son bytecode. Il a d’ailleurs passé celui-ci sur quelques-uns des frameworks Open Source de votre quotidien et regroupé les résultats sur son site dédié : Testability Explorer.

Nexus pour chercher dans les repositories Maven

On avait l’habitude d’utiliser http://www.mvnrepository.com (ou google, ou le plugin m2eclipse) lorsque l’on partait à la recherche de son jar favori, Sonatype (dont le fondateur et CTO est Jason Van Zyl, le père de Maven) a mis à disposition une instance publique de Nexus, son manager de repository Maven : http://repository.sonatype.org.

L’interface est propre, facile à utiliser, et est développée à l’aide du framework Ext JS.

Distribuez vos tests JUnit avec GridGain

Tester une application déployée sur plusieurs machines : quelle galère ! N’avez-vous jamais eu besoin d’effectuer des tests en environnement distribué ? Comment effectuez-vous vos tests d’intégration impliquant des communications clients-serveur ? Cet article nous propose une solution originale pour effectuer ce type de tests multi-jvm utilisant certaines fonctionnalités de GridGain, framework Open Source permettant la création d’applications distribuées de type grid computing. L’auteur de l’article n’utilise pour faire ses tests qu’une des fonctionnalités offertes par ce framework : la distribution des tests sur plusieurs nœuds.

Pour ce faire, vous aurez besoin, en plus de vos tests, de 3 ‘TestSuite’ configurées avec des annotations et runners GridGain :

• Une première ‘Remote TestSuite’ chargée de lancer les tests sur le serveur. Les tests de cette suite seront exécutés sur la grille.
• Une seconde ‘Local TestSuite’ pour lancer les tests sur le client local.
• Une troisième et dernière ‘Distributed TestSuite’ servant de point d’entrée unique au lancement de deux premières séries de tests.

Cela vous déplaît certainement d’utiliser un tel framework uniquement pour une de ses plus petites fonctionnalités, et vous avez probablement raison. Maintenant quelles autres options aussi puissantes et rapides à mettre en place proposeriez-vous en remplacement ?

Tomcat : Trucs et astuces des pros de SpringSource

SpringSource continue sa série de webinars sur Tomcat avec Apache Tomcat Tips and Tricks from the Pros (cf. Tuning et optimisation de Tomcat : mod_jk est mort ! Longue vie à mod_proxy_http ! et Améliorer les performances de Tomcat en production). Nous avons cette fois retenu :

• setEnv(.sh|.bat) est le fichier à utiliser pour configurer le lancement de Tomcat (afin de préciser le JDK, les options de la JVM, etc). startup.sh et catalina.sh peuvent le plus souvent rester inchangés.

JAVA_HOME=/usr/local/jdk_1.6.0.10/
CATALINA_OPTS=-Xmx512m
CATALINA_HOME=/usr/local/apache-tomcat-6.0.18
CATALINA_BASE=/usr/local/tomcat-instance-01
CATALINA_PID=$CATALINA_BASE/logs/tomcat.pid

Dans cet exemple, un JDK 1.6.0.10 avec 512 Mo de Heap démarre un Tomcat 6.0.18 avec une configuration située sous /usr/local/tomcat-instance-01 ; le pid sera stocké sous /logs/tomcat.pid.

• Le port de shutdown de Tomcat existe pour des raisons historiques [1] et présente une faille inutile de sécurité. Il doit être désactivé en précisant le port « -1″. On remplacera alors shutdown.sh et catalina.sh stop par le classique kill unix.

<Server port="-1" shutdown="SHUTDOWN" >

• L’Access Log Valve permet de générer des logs d’accès similaires à celles d’Apache. Ces informations sont très importantes pour la supervision et le troubleshooting. L’ExtendedAccessLogValve supporte le W3C Extended Log File Format et surtout facilite le troubleshooting en permettant d’afficher les paramètres et les attributs de requête (même en POST).

<Valve className="org.apache.catalina.valves.AccessLogValve"
    pattern="combined" directory="${catalina.base}/logs" prefix="tomcat_access_" suffix=".log" />

• Le fichier catalina.properties permet d’utiliser des variables de substitution. Exemple avec une variable engine.jvm-route :

<Engine ... jvmRoute="${engine.jvm-route}">

• Tomcat offre plusieurs méthodes pour déployer les applications (définition de <context> dans server.xml, auto deploy de .war/répertoires/context.xml, déploiement scripté). Si toutes ces options sont utilisables en production, il est important de n’en utiliser qu’une seule pour éviter les collisions.

[1] Les JDK 1.0, 1.1 et 1.2 n’offraient pas de graceful shutdown. Depuis, le mécanisme de Shutdown Hook des JVM permet un arrêt élégant de Tomcat sur commande kill.

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

Sacha Labourey au Paris JUG mardi pour une soirée JBoss

Sacha Labourey, CTO de JBoss et General Manager de JBoss Europe, présentera JBoss AS 5.0 à la soirée JBoss du Paris JUG mardi 2 décembre. Saheb Malik, JBoss France, présentera ensuite JBoss Seam.
C’est l’occasion rêvée de mieux comprendre l’agenda de JBoss. Nous avons notamment en tête les questions suivantes :

• JBoss MicroContainer et OSGi : quel positionnement tenir quand Sun a mis en retrait HK2 au profit d’Apache Felix.
• JBoss Messaging vs. RedHat MRG : quelles synergies ? Interopérables à l’instar de Websphere MQ (aka MQ Series) et Websphere Embedded Messaging Engine ? AMQP plaît à RedHat, JBoss est-il aussi intéressé ?
• JBoss AS 5 : comment le précurseur des implémentations EJB 3 et JPA se retrouve t’il parmi les retardataires des certifiés Java EE 5 ? Le chantier de refonte a-t-il été trop ambitieux ?
• Data Grids : pourquoi JGroups, le coeur de communication de JBoss Cache est-il un projet extérieur à JBoss ? Les Data Grids font-elles parties des priorités de JBoss ?
• JBoss, Fondation Apache et brique HTTP de JBoss AS : JBoss semble moins impliqué qu’auparavant dans Tomcat et vient de lancer son mod_cluster à l’extérieur du projet Apache HTTP Server et de son mod_proxy_balancer. À l’heure où les architectures Comet imposent des évolutions importantes des moteurs de Servlet, JBoss compte-t-il s’éloigner de Tomcat ?

Actualité éditeurs / SSII

• OSGi : Spring dm Server standardisé pour l’été 2009 ?

Agilité

• La fin de l’Agilité ?

SOA

• SOA : de la crise de doute à la désillusion ?

Le coin de la technique

• Seam 3 : les futures orientations de Seam
• Sortie de Netbeans 6.5
• Sortie de SOAP UI 2.5
• Survol de l’architecture MySpace
• Oracle sort son Incubateur Coherence

Actualité éditeurs / SSII

OSGi : Spring dm Server standardisé pour l’été 2009 ?

Eric Newcommer, OSGi Enterprise Expert Group (EEG) co-chair, présente dans « OSGi for the Enterprise Gets a Bit Closer & LinkedIn Too » l’avancement de l’EEG qui a pour ambition de faire coïncider la fin de ses travaux avec la sortie d’OSGi R4.2 annoncée pour Juin 2009.

On y apprend que la « RFC 124 / Blueprint Component Model » est quasiment finalisée, son implémentation de référence (RI) est SpringSource dm Server dont elle a repris les principes ; le Test Compatibility Kit (TCK) est développé par le projet Apache Geronimo. Souhaitons que cette standardisation de dm Server permette à SpringSource de reverser le contenu de son Enterprise Bundle Repository dans l’officiel OSGi Bundle Repository de l’OSGi Alliance et que la prolifération de bundles customisés par les grands acteurs de l’OSGi prenne fin.

Par ailleurs, « RFC 119 / Distributed OSGi » serait elle aussi prête. Apache CXF est en charge de la Reference Implementation (Cf. First Ever Demo of Distributed OSGi) et Tibco s’occupe du Test Compatibility Kit. Nous remarquerons que Distributed OSGi reprend certains principes de Service Component Architecture (SCA) et que le positionnement des deux technologies manque encore de clarté. De plus, à la différence de « Blueprint Component Model » avec Spring dm Server, Distributed OSGi ne connaît pas encore de « vraie » implémentation.

Agilité

La fin de l’Agilité ?

Le prix du buzz de la semaine revient incontestablement à James Shore pour son article The Decline and Fall of Agile. « Jim » raconte qu’il a noté un changement dans son métier : avant on l’appelait pour introduire les méthodes agiles sur les projets, aujourd’hui on l’appelle pour secourir des projets soi-disant « agiles ».
Et par « agile » la plupart des clients entendent Scrum, la méthode la plus répandue. Il reproche à Scrum son silence sur les pratiques d’ingénierie logicielle à mettre en place (contrairement à XP), pourtant indispensables à la viabilité d’un projet. Il critique également la Scrum Alliance et son système de certification ScrumMaster qui donnent l’impression que l’agilité est facile. La nature humaine nous incite à ne choisir que les côtés agréables (les sprints et les daily scrums) mais nous ignorons les côtés plus difficiles, qui sont aussi les plus importants : équipe co-localisée, auto-organisée, produit livrable à chaque fin d’itération, élimination des obstacles.

Cet article a déclenché de vives réactions dans la communauté agile, certaines un peu puériles, d’autres plus constructives. Sur InfoQ par exemple, le Gartner Hype Cycle est évoqué pour expliquer ce déclin. Après un pic d’attentes irréalistes concernant une technologie, celle-ci traverse un creux de désillusion avant de remonter pour atteindre son plateau de productivité. Les méthodes agiles traverseraient-elles actuellement ce creux ?

Le Touilleur cite Rob Bowley qui fait le rapprochement entre la déception de Scrum et l’engouement récent pour le Lean Software Development. Il prédit pourtant que le Lean subira le même sort que Scrum, pour les mêmes raisons. Selon lui peu importe la méthode, il y a toujours des personnes qui se concentrent sur les outils plutôt que sur les vrais problèmes. Ces personnes, qui échouent avec Scrum aujourd’hui, échoueront avec le Lean demain.

SOA

SOA : de la crise de doute à la désillusion ?

Nous évoquions en Mars dernier dans « 2008, annus horribilis de la la SOA ?«  la crise de doute qui s’emparait du Burton Group, grand chantre de la SOA. La crise s’accentue aujourd’hui avec l’autre évangéliste de SOA, le Gartner Group, qui nous gratifie de Ahh Shucks, SOA Is A Failure (Frank Kenney). À croire que le Gartner Group s’applique son célèbre Hype cycle et, après avoir loué SOA, tombe en pleine phase de désillusion.

Est-ce pour autant la fin de SOA ? Certainement pas, des ouvrages comme Enterprise Integration Patterns ou Developing in a Service-oriented World (Gregor Hohpe, Google) ont beaucoup apporté à l’intégration des Systèmes d’Information.

Quant aux cabinets de conseils qui ont parfois manqué de pragmatisme, ils ont trouvé des nouvelles marottes avec les architectures du moment : Representational State Transfer (REST) et Web Oriented Architecture (WOA) (Cf. Gartner – WOA: Putting the Web Back in Web Services ou Burton Group : The Tao Of REST), sans oublier les promesses mirobolantes du Software As A Service (SaaS) et du Cloud Computing !

Le coin de la technique

Seam 3 : les futures orientations de Seam

Gavin King, créateur d’Hibernate et Seam, présente les futures orientations de Seam3.

Il indique que Seam 2 était une première couche. Cette couche a pour responsabilité de gérer des composants à état, configurables et injectables pour le développement d’applications Web riches. Il permet de s’abstraire du code « glue » que l’on doit faire pour intégrer différentes technologies (JSF, JPA, …). Cette première couche est focalisée sur l’intégration de services à état côté serveur et sur la réalisation d’interface graphique (par défaut avec JSF).

Seam 3 ajoutera une seconde couche, qui aura pour responsabilité de faire de WebBeans le coeur de Seam, d’améliorer l’intégration de la sécurité, de Drools et jBPM. L’idée est de faire de Seam 3 un framework d’infrastructure basé sur Web Beans. Seam 3 permettra donc l’intégration de moteur de workflow et de moteur de règles qui devrait apporter de nouveaux outils pour la conception et la réalisation d’applications.

Seam 3 pourrait conduire à une réécriture de Seam 2 afin d’intégrer Web Beans.

A noter que le 2 décembre 2008 se tiendra une soirée JBoss au Paris JUG, dont la deuxième partie sera entièrement consacrée au framework Seam.

Sortie de Netbeans 6.5

Netbeans.org annonce la sortie de son IDE NetBeans 6.5 : NetBeans.org is proud to announce the availability of NetBeans IDE 6.5!.

Cette nouvelle version met à disposition des développeurs :

• le debug Javascript dans Internet Explorer et Firefox,
• le développement JavaFX (compilation, déploiement, prévisualisation, édition, …),
• l’intégration de Glassfish V3 Prelude (possibilité de scripter en JRuby),
• un plugin pour le développement en python : NetBeans IDE for Python EA Download,
• l’amélioration et l’intégration de nouvelles technologies de développement : PHP, Groovy / GRails, Ruby (RoR – Ruby On Rails, rake),
• et bien d’autres : NetBeans IDE 6.5 Release Information, NewAndNoteWorthyNB65.

Netbeans s’avère une alternative de plus en plus crédible à Eclipse. Il possède des avantages non négligeables par rapport à ce dernier : meilleur support Javascript (et du développement Web avec PHP), support de Python, JavaFx, etc.

Pour plus d’informations, voici quelques screencasts qui montrent le fonctionnement de Netbeans : NetBeans IDE 6.5 Released; Introductory Screencast Released.

Sortie de SOAP UI 2.5

SoapUI est un outil graphique pour tester les services web. Il permet d’inspecter, invoquer, développer, créer des tests de charges et des tests fonctionnels sur des services web. Il apporte aussi des plugins pour Eclipse, IntelliJ IDEA et NetBeans.

SoapUI 2.5 apporte un grand nombre de fonctionnalités :

• Inspection et invocation :
  • Importation et analyse de fichiers WSDL.
  • Appel des différentes opérations d’un service web.
  • SSL / authentification / sécurité WS.
• Développement et validation :
  • Génération de stubs client et serveur pour les frameworks les plus populaires : Axis 1.x/2.x, XFire / CXF, JWSDP, Oracle, .NET, GSoap, JBossWS.
  • Génération de XML bindings pour JAXB et XMLB.
• Tests fonctionnels :
  • Génération de séries de tests et de testcases sur la base du WSDL.
  • Utilisation de scripts « Groovy » pour l’exécution de tests.
• Tests de charge :
  • Établissement de tests de charge à partir de testcases fonctionnels.
  • Établissement d’assertions, tant au niveau de la performance que de la fonctionnalité.
  • Analyse de performance pour des scénarios variés..

Pour voir la liste complète des fonctionnalités, rendez-vous sur le site du projet.

Très facile d’utilisation, SoapUI devient de plus en plus un leader incontournable dans le test des services web en open source. Il existe en version gratuite et open source et en version payante appelée « SoapUI Pro ».

Vous pouvez télécharger l’outil, ou l’utiliser directement avec le déploiement Java Web Start. Java 1.5 est indispensable à son utilisation.

Survol de l’architecture MySpace

InfoQ poursuit sa série sur les architectures des grands du Web 2.0, avec l’interview de Dan Farino, architecte principal du site communautaire MySpace.

Nous entrerons probablement moins dans les détails de cette architecture pour la bonne et simple raison que MySpace est l’un des seuls site internet de cette taille à tourner sous .Net. Cependant, les grands principes de performances qui permettent au site communautaire de gérer plusieurs millions de visiteurs par jour, et un contenu en constante augmentation, s’appliquent à n’importe quelle technologie.

• Mettre l’accent sur l’automatisation : avec des fermes comportant plusieurs centaines de serveurs (300 serveurs web IIS frontaux par exemple), il est vital que toutes les opérations d’administration des serveurs soient automatisées à une large échelle.
• La détection des anomalies est la première étape nécessaire à l’amélioration des performances : à cette fin, Dan Farino a dû écrire un outil de supervision sur mesure permettant de ‘tracer’ chaque requête à travers les centaines de serveurs de l’architecture. Cette problématique est relativement courante.
• Pour chaque problème de performance ou de scalling détecté, l’équipe d’architectes de MySpace a favorisé la solution sur mesure aux nombreux outils ‘génériques’ proposés par Microsoft. On notera en particulier :
  • Le développement d’un système de cache spécifique, afin de s’affranchir des problèmes (connus) de GarbageCollection en .Net, et afin d’alléger la charge pesant sur les serveurs de DB.
  • Le développement d’un serveur de fichiers, en Linux, permettant d’adresser les fichiers aux utilisateurs finaux directement en HTTP, et gérant la redondance des fichiers audio, video (qui sont la vraie valeur ajoutée de MySpace).
  • Le développement d’un système d’introspection du code .Net en temps réel (mesure des temps d’appels, des allocations mémoire, levée d’exception, …) écrit en C++ (afin de monitorer le code .Net de la manière la plus indépendante possible).
  • La création d’un système de ‘load balancing’ spécifique, permettant de rapidement isoler un serveur défaillant et de n’impacter qu’un minimum d’utilisateurs.

Et bien sûr, MySpace respecte un principe que nous avons maintenant rencontré dans tous les sites gérant un trafic ou un contenu important, le partitionnement horizontal et vertical des bases de données, en fixant une limite d’un million d’utilisateurs par DB.

Les autres épisodes de la série disponibles sur notre blog :

• Ebay
• LinkedIn
• InfoQ

Oracle sort son Incubateur Coherence

Oracle tente d’élargir la communauté ‘Coherence’ après l’ouverture du mois dernier de son nouveau site web Coherence Incubator. Veillez à ne pas comparer celui-ci à l’incubateur Apache, son fonctionnement est tout autre. ‘Coherence Incubator’ a été créé dans le but de regrouper un ensemble de projets d’exemples, chacun d’entre eux proposant une implémentation de référence pour un cas d’utilisation standard de l’outil. Il s’agit donc d’un ensemble de bonnes pratiques validées par Oracle. Oracle espère par ce biais faciliter l’accès à son outil.

Pour mémoire, Oracle Coherence se positionne comme l’une des solutions les plus complètes de grilles de données distribuées. Il permet de clusteriser vos applications sur un environnement hardware évolutif. Par exemple, l’ajout et la suppression de machine s’effectuent sans contrarier la réplication, la distribution et le cache de données au sein du cluster.

Un mois après sa sortie, l’incubateur Coherence contient les projets suivants :

• coherence common : un regroupement de classes utilitaires et bonnes pratiques. Utilisés par les autres projets de l’incubateur.
• Implémentation distribuée du command pattern.
• Implémentation du functor pattern. Il s’agit d’une extension au ‘command pattern’ qui permet de renvoyer à l’appelant des valeurs de retour et des exceptions.
• Implémentation partielle du pattern messaging. Messages non persistés, managés en mémoire par Coherence.
• Implémentation du pattern Push Replication. Propagation des modifications des données, réplication.

Si le contenu de cet incubateur n’est pas encore très impressionnant, il aura le mérite de servir de bon point de départ aux futurs nouveaux utilisateurs de Coherence. Le nombre de cas d’utilisation est encore très faible ; reste à savoir à quelle vitesse Oracle enrichira-t-il celui-ci. Après un mois d’utilisation, seul un nouveau projet a été créé.

Actualité éditeurs / SSII

• Sun délaisserait Swing ? Entre sur réaction et conflit d’intérêts

Agilité

• ScrumMaster A.O.C
• Getting Real : les conseils de 37Signals

Le coin de la technique

• GlassFish v3 Prelude, Sun fait le Buzz
• Restlet 1.1.0: Plus de souplesse et une implémentation de JAX-RS 1.0:
• mod_cluster : JBoss fait cavalier seul pour l’après mod_jk
• JSR-299 : Web Beans disponible en Public Review Draft

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

• Journée « GlassFish et Java » à Paris chez Sun

Actualité éditeurs / SSII

Sun délaisserait Swing ? Entre sur réaction et conflit d’intérêts

Il a suffit que Sun annonce son désengagement temporaire de SwingLabs pour que la blogosphère s’enflamme et prédise la fin de Swing (ici, là, ou encore là ).

Swing Labs est l’incubateur des nouveaux composants et des nouvelles fonctionnalités de Swing (cf. SwingLabs – Status Update @ Java One 2008 par Richard Bair, SwingLabs Project Lead, Sun Microsystems). Les développements y sont réalisés en open source (GNU LGPL) avec un copyright « Sun Microsystems, Inc ». On retrouve ici la stratégie fréquente de Sun d’un mode Open Source à gouvernance exclusive avec Copyright Sun qui permet un dual licensing. Grâce à son copyright, Sun est libre de proposer le code sous un autre contrat de licence. La contre partie de ce copyright Sun Microsystems est que les contributions extérieures à Sun sont peu probables ; peu de développeurs et d’entreprise sont prêts à céder leur copyright à un a acteur commercial (1).

Le désengagement de Sun peut s’expliquer par l’énergie que la société place actuellement dans le lancement de son produit Java FX qui doit occuper ses développeurs d’interface graphique les plus talentueux. Si l’on ajoute que Sun restructure en ce moment ses équipes pour des raisons financières, cela laisse peut de monde pour s’occuper des nouveaux composants de Swing (JavaFX et Swing partagent le même socle mais ont des composants de haut niveau différents).

Quel impact aura ce désengagement sur les évolutions de Swing ? On peut voir ici un conflit d’intérêts entre l’éditeur Sun Microsystem qui lance un produit stratégique et la responsabilité du fondateur du langage Java qui a pris la gouvernance exclusive sur un chantier d’évolution du langage.

Alors, Java FX a tué Swing ? On peut en douter ; Swing a toujours été important pour Sun (Netbeans, Matisse, etc) et Java FX enrichiera probablement plus Swing qu’il ne lui nuira. En revanche, l’agenda commercial de Sun et le lancement de Java FX risquent de retarder temporairement les évolutions de Swing.

(1) On notera que certains projets open source prennent eux aussi le copyright du code (les développeurs se dépossèdent de leur travail) et que cela ne freine pas les contributions. Par exemple, la Fondation Apache utilise l’Apache Software License (ASL) et est propriétaire du copyright (« Licensed to the Apache Software Foundation (ASF)… ») ; la Fondation peut à tout moment exposer le code sous un nouveau contrat de licence, ce fut notamment le cas lors du passage de l’ASL version 1 à la version 2. Spring Framework a une approche différente puisque ce projet utilise lui aussi l’Apache Software License mais a laissé le copyright aux auteurs (« Copyright 2002-2005 the original author or authors »).

Agilité

ScrumMaster A.O.C

À partir de janvier 2009, il vous faudra passer un test en plus du CSM pour pouvoir être certifié ScrumMaster, comme l’annonce Michael James. Il s’agira d’un questionnaire à choix multiple, actuellement en bêta-test au Scrum Gathering Stockholm.
En effet jusqu’à maintenant il suffisait d’assister à un CSM pour être certifié ScrumMaster. N’importe qui, même sans aucune connaissance sur Scrum, pouvait assister à la formation et devenir ainsi « ScrumMaster ». Le terme « certification » était donc trompeur. Ce manque de garantie était d’ailleurs largement critiqué par la communauté agile.
Tom Mellor rappelle qu’à l’origine Ken Schwaber a créé le CSM en pied-de-nez au PMI. L’objectif du CSM n’est pas de découvrir le rôle de ScrumMaster mais de comprendre et maîtriser les concepts de Scrum.

Getting Real : les conseils de 37Signals

Kris Jordan avait recueilli les leçons qu’ils ont apprises chez 37Signals lors de la conférence donnée par Jason Fried pendant la Web 2.0 Expo.
David Larlet a traduit ce recueil qui synthétise les idées du célèbre manifeste Getting Real de 37Signals. L’occasion de revoir les points importants :

• Volatilité : les décisions sont limitées dans le temps, les plannings aussi. Les projections long terme ne servent à rien, les choses changent.
• Restez concentrés : concentrez-vous sur l’essentiel, le réel, ce qui est simple et qui ne change pas. Évitez les interruptions qui nuisent à la productivité.
• Travailler moins pour produire plus : ignorez ce qui n’est pas important, vous pourrez travailler moins pour aboutir à un produit plus simple mais d’aussi bonne qualité.

Le coin de la technique

GlassFish v3 Prelude, Sun fait le Buzz

Difficile de passer à côté de cette actualité cette semaine : la sortie de GlassFish V3 Prelude. Une pluie de billets sur les blogs de Sun a accompagné la sortie de cette version ‘démo’ de son futur nouveau serveur d’applications dont la sortie est prévue pour 2009. Notez tout de même que cette version est supportée par Sun et est prête pour tourner en production, veillez donc à ne pas le comparer à une version bêta.

Le kernel de FlassFish v3 Prelude repose sur une architecture modulaire. Pas de surprise à ce niveau, Sun reste dans la lignée de ses previews, GlassFish repose sur Apache Felix, l’implémentation Apache du runtime OSGi R4. La liaison entre cette technologie et le centre de mises à jour inclus, vous permettra d’activer, supprimer simplement les différentes technologies proposées : Servlet 3.0, JRuby, Groovy, Grails, … Et c’est la que repose toute l’utilité d’un tel kernel, vous ne chargez que ce qui vous intéresse et optimisez du même coup les temps de démarrage et consommation mémoire.

Offrant également un avant-goût de JEE 6 (dont la sortie est prévue pour début 2009), cette version de GlassFish vous permettra de tester certaines fonctionnalités de la future version de Java Enterprise, dont :

• JAX-RS 1.0, vous permettant le développement de services REST, les spécifications sont stables
• EJB 3.1 Lite, se voulant résoudre les dernières lourdeurs des EJB, GlassFish en sera la reference implementation
• JSF 2.0, dont les spécifications ne sont pas encore terminées

Sun a fait en sorte que toutes les conditions soient réunies pour que le buzz prenne autour de cette sortie (sortie prématurée, technologies affriandantes…). Force est de constater que l’objectif est rempli ! GlassFish v2 était déjà considéré comme le nouveau chouchou des développeurs, cette nouvelle version séduira elle en plus les exploitants ? Le futur nous le dira.

Comme l’indique, le créateur de Java et employé à Sun, James Gosling dans We’ve been cranking!, en complément de la sortie de Glassfish, Sun a mis à jour différents types de logiciels : son framework avec JDK6u10, son IDE avec Netbeans 6.5RC, sa base de données avec MySQL 5.1, son système d’exploitation avec OpenSolaris 2008.11.

Restlet 1.1.0: Plus de souplesse et une implémentation de JAX-RS 1.0:

Restlet est un framework Java qui permet de développer des applications REST-ful. La version 1.1.0 est sortie fin octobre 2008. Le blog de Noelios Technologies (la société qui dirige les développements sur Restlet) nous parle des différentes améliorations :

• Un support du protocole HTTP plus large.
• Une implémentation de la JSR 311 sur JAX-RS 1.0 la plus complète du moment.
• Une intégration étendue et facilitée avec les technologies en vogue (Spring 2.5, JAXB 2.1, etc.)
• Un portage de l’API côté client Restlet vers GWT 1.5 permettant d’appeler des applications REST-ful directement depuis le navigateur WEB. Ce fût d’ailleurs le sujet de la deuxième partie du Paris JUG du mardi 4 novembre présenté par Jérôme Louvel.
• … et beaucoup d’autres disponibles sur le billet posté sur le blog de Noelios.

Jérôme Louvel est le responsable principal du développement de Restlet. Il a été interviewé par InfoQ à propos de cette nouvelle version.
Trois questions ont été posées sur les points suivants :

• L’implémentation de la JSR 311 dans Restlet
  Réponse : La plus complète, et l’objectif est d’obtenir le kit de compatibilité (TCK) nécessaire pour être certifié.
• Les conditions d’utilisation de JAX-RS : seul ou avec l’API Restlet
  Réponse : Après avoir distingué les différentes approches de JAX-RS et de Restlet API, annotations sur un POJO pour le premier, héritage des classes de base pour le second, Jérôme pense que s’il n’y a pas nécessité d’être conforme avec les standards de JEE, il est plus simple et puissant d’utiliser Restlet.
• L’importance de la communauté Restlet
  Réponse : 8 valideurs sur le core, 6 sur les extensions et 160 contributeurs soutenus par une communauté solidaire.

Restlet 1.1.0 offre une implémentation très complète de JAX-RS 1.0 et s’intègre à plusieurs frameworks importants du marché.

mod_cluster : JBoss fait cavalier seul pour l’après mod_jk

Alors que la Fondation Apache propose depuis Httpd 2.2 le duo mod_proxy_balancer / mod_proxy_http comme successeur de mod_jk pour se connecter à Tomcat, JBoss se lance dans le développement de son propre module Httpd, mod_cluster, pour connecter le moteur Tomcat embarqué dans JBoss AS au serveur. mod_cluster met en avant les fonctionnalités suivantes :

• Configuration dynamique des workers http : alors que mod_proxy_balancer se limite pour le moment à l’interface web (/balancer-manager) destinée aux humains, mod_cluster expose un Cluster Management Protocol qui permettra à des outils de déploiement de centraliser les opérations sur le serveur moteur de servlet et sur le serveur web (installation, mise à jour, désinstallation). Nous noterons au passage qu’une application Tomcat arrêtée renvoi des erreurs 404 qu’un load balancer ne sait pas interpréter pour marquer comme indisponible le servant alors qu’une erreur 503 Service Unavailable ferait l’affaire. Ces fonctionnalités d’administration sont déjà disponibles dans des serveurs Java EE tels que Websphere (c.f. Websphere Education Center : eate a remote Web server definition).
• Gestion du cycle de vie des applications : mod_cluster apporte le très important concept de désactivation d’un servant (DISABLE-APP:) qui fait hélas défaut à l’actuel mod_proxy_balancer. On pourra éteindre en douceur un noeud en reportant la charge vers les autres servants sans pour autant perdre les sessions en cours (dans le cas ou l’on n’a pas de réplication de sessions).
• Algorithme de load balancing basé sur la charge des serveurs : les load balancers déduisent le plus souvent la charge des servants à partir du nombre de requêtes ou du nombre de requêtes en cours d’exécution. mod_cluster expose une API pour que chaque servant puisse communiquer des informations plus fines (charge CPU de la machine, etc). Ce mécanisme sophistiqué concernera les besoins avancés alors que la plupart des installations peuvent se contenter d’un simple algorithme round robin
• Mise en avant du protocole HTTP en substitution à AJP : JBoss continuait à mettre en avant mod_jk et le protocole AJP (cf JBoss AS Guide – 18.1. Configuring load balancing using Apache and mod_jk). La page semble aujourd’hui se tourner au profit du connecteur HTTP sur lequel portent les efforts du projet Tomcat.

Espérons que ces travaux bénéficieront un jour au module mod_proxy_balancer intégré à Apache Httpd.

JSR-299 : Web Beans disponible en Public Review Draft

Gavin King, le créateur d’Hibernate et le Spec Lead sur Web Beans, a annoncé sur le blog InRelationTo la sortie de la spécification Web Beans en Public Review Draft : Web Beans Public Review Draft released.

Cette spécification est issue des travaux ménés sur le framework Seam. De plus, elle s’inspire des moteurs d’injection Guice (Google) et Spring. Cependant Web Beans (et Seam) se démarque de Spring dans une approche orientée annotation plutôt que XML pour la configuration.

Web Beans a pour objectif de fournir un ensemble de services pour les composants JEE. La spécification définit :

• Le cycle de vie et les interactions de composants à état (stateful) dans des contextes définis et extensibles.
• Un mécanisme d’injection de dépendance permettant de choisir les dépendances d’un composant au déploiement.
• La possibilité d’utiliser un langage EL (Expression Language) étendu dans les pages JSP et JSP.
• Un paradigme d’intercepteur dont un nouveau type d’intercepteur baptisé Decorator.
• Un modèle de notification par événement.
• Un contexte d’exécution Web.
• Un SPI (Service Provider Interface) permettant l’intégration de framework tier dans Web Beans.

Cette spécification a pour vocation d’uniformiser de manière globale le développement d’applications de gestion en se reposant sur d’autres spécifications : EJB, JSF, Java Servlets, Common Annotation.

C’est une spécification assez velue, car elle introduit beaucoup de nouveaux concepts largement expérimentés dans Seam :

• Scope,
• Conversation,
• Composant à état,
• Intégration des standards ensemble EJB/JSF,
• Modèle d’annotations, d’intercepteurs, …

Cette spécification est indispensable dans le cas où vous voulez essentiellement développer avec des standards, mais elle peut être aussi, bien utile dans d’autres cas. Elle vous permettra de développer avec les standards comme JSF et EJB en utilisant leurs pleines puissances et en ayant à développer très peu de code pour intégrer les 2 technologies (pas de DTO Data Transfer Object , utilisation de Binding par annotation et EL).

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

Journée « GlassFish et Java » à Paris chez Sun

Sun organise le vendredi 12 décembre une journée gratuite « GlassFish et Java » dans ses locaux au 42, avenue d’Iéna à Paris.
Cette journée sera l’occasion de couvrir un large spectre de la gamme Sun :

• GlassFish,
• Java EE 6,
• Grizzly Comet,
• Jersey,
• OpenMQ,
• JavaFX,
• MySQL,
• OpenSSO,
• OpenESB.

Parmi les intervenants: Roberto Chinnici (spec lead), Richard Bair (tech lead), Paul Sandoz (spec lead), Linda Schneider (tech lead), Jean-François Arcand (tech lead), etc…

L’ouverture des inscriptions ne devrait pas tarder : A suivre sur le blog d’Alexis Moussine-Pouchkine …

Actualité éditeurs / SSII

• Google Android disponible en Open Source
• Amazon EC2 passe en production

Le coin de la technique

• Sortie de Seam 2.1.0.GA
• JBoss AOP 2.0.0 disponible, JBoss AS 5 se rapproche …
• Embedded Jopr pour JBoss AS : une console JMX de nouvelle génération
• Exemples de la JSR 203 (la nouvelle nouvelle JSR I/O)
• JVM 64 bits ? Oui mais avec compression des pointeurs

Actualité éditeurs / SSII

Google Android disponible en Open Source

Google a officiellement mis à disposition le code source de la plateforme Android et encourage les développeurs à la tester.

Cette annonce survient au moment du lancement du nouveau téléphone le HTC Dream G1 de HTC par T-Mobile aux États-Unis. Le code source est livré sous licence Apache, ce qui implique que son utilisation est gratuite et que les développeurs ne sont pas tenus de rendre public le code source de leurs nouveaux produits.

Le code source d’Android est à présent disponible au téléchargement à l’adresse suivante : http://source.android.com/download.

Quant à ceux qui souhaiteraient développer des applications pour ces téléphones, Google recommande Ubuntu comme environnement de programmation pour Android (il est également possible d’utiliser MacOS).

Amazon EC2 passe en production

Le service d’hébergement d’applications Amazon EC2 n’est plus une bêta depuis le 23 octobre. Aurait-on donc de nombreux changements à se mettre sous la dent ?
Pas vraiment. La seule « révolution » est l’introduction d’un SLA (Service Level Agreement, autrement dit un engagement de résultat) qui garantit une disponibilité à 99.95% du temps. Si le taux de service chute sous cette barre, le client peut remplir une demande et accéder à des remises commerciales (autant dire qu’Amazon a dû considérablement stresser son système avant d’annoncer de tels chiffres).

Dans un futur proche, le service d’Amazon devrait se voir enrichi des fonctionnalités suivantes :

• Console d’administration.
• Load Balancing.
• Adaptation automatique à la charge (AutoScaling).
• Monitoring global de l’ensemble des instances.

ainsi que de nouveaux logiciels : Windows Server 2003, SQL Server Standard 2005 ou Express (déjà disponibles en bêta), Windows Server 2008 (à venir)

Une nouvelle pierre dans le jardin des hébergeurs traditionnels…

Le coin de la technique

Sortie de Seam 2.1.0.GA

Dans une précédente revue de presse, nous vous avions présenté les nouveautés de Seam 2.1. L’équipe Seam concrétise ces nouveautés avec la sortie officielle de Seam 2.1.0.GA.

Seam 2.1.0.GA intègre les composants suivants :

• RichFaces 3.2 (implémentation JSF de JBoss).
• GWT (Google).
• Wicket (Apache) (exemple d’intégration de Wicket dans Seam : Seamless Wicket: Orchestrating your application).
• Groovy 1.5 (pour rappel il est possible d’écrire des composants Seam avec le langage Groovy).
• JBoss Cache 2 (ou JBoss Cache ou EHCache).
• JAX-RS (REST) via l’implémentation du projet JBoss RestEasy.
  A noter que RestEasy n’est actuellement qu’en version bêta.
• Documentation pour intégrer Seam dans d’autres containers que JBoss AS : WebLogic, WebSphere, OC4J et Glassfish.

Prochaine étape : Seam 2.1.1, l’équipe s’attachera à encore améliorer les performances, la scalabilité et le clustering de Seam.

En parallèle, la spécification Web Beans commence à pointer le bout de son nez : Web Beans Teaser.

Félicitation à l’équipe Seam pour le travail qui a été réalisé.

JBoss AOP 2.0.0 disponible, JBoss AS 5 se rapproche …

La sortie officielle de la version 2.0.0 de JBoss AOP vient d’être annoncée. Après s’être posé la question en début de semaine, Kabir Khan a finalement décidé de publier celle-ci. Doit-on y voir les signes avant-coureurs d’une sortie imminente du nouveau serveur d’applications made in JBoss ? Il est encore un peu tôt pour le dire. Notez tout de même que JBoss AS 5 est en RC2 depuis déjà plus d’un mois, date à laquelle il avait franchi la plus grande marche lui restant à gravir (La Certification JEE).

Pour en revenir au cœur du sujet, si JBoss AOP est directement intégré au sein du futur serveur d’applications, rien ne vous empêche d’utiliser celui-ci en standalone. La meilleure présentation de ce framework reste l’article de 5 pages publié sur DZone cet été : An Introduction to Aspect-Oriented programming with JBoss AOP qui en présente les principales nouveautés :

• Un nouveau mode de weaving permettant l’ajout d’advices autour des exceptions (before / after / throwing / finally).
• L’interception des accès à chaque élément d’un tableau.
• Un déploiement et une mise à jour à chaud des advices et des interceptors.
• Une intégration avec le microcontainer JBoss AS 5.

Autres liens :

• Le site officiel de JBoss AOP
• JBoss AOP 2.0.0 Release Note

Embedded Jopr pour JBoss AS : une console JMX de nouvelle génération

JBoss vient de mettre à disposition de la communauté une console JMX nouvelle génération pour la supervision et l’administration d’une instance du serveur JBoss AS. La console est une application web basée sur le framework Seam. Le code source de l’application est livré sous licence LGPL.

Une particularité de la nouvelle console est la possibilité d’intégrer des plugins de RHQ et Jopr.

La version 1.0 offre la possibilité de gérer l’instance du serveur et les instances des applications d’entreprise, de mettre à jour les configurations, de contrôler les activités et d’exécuter les scripts qui résident dans le répertoire bin du serveur JBoss AS.

Une capture d’écran de la console :

Une présentation vidéo flash de la console Embedded Jopr en action : http://www.jboss.org/embjopr/demo.html#.

Exemples de la JSR 203 (la nouvelle nouvelle JSR I/O)

Les exemples concernant cette JSR NIO2 (dont nous vous parlions déjà dans une revue de presse précédente) continuent d’affluer.

Récemment, c’est Alex Miller (examples and more features) qui nous propose des exemples d’utilisation balayant quelques nouvelles fonctionnalités de cette API.

Parmi ces changements, et pour ne garder que ceux qui nous simplifieront la vie (et surtout les lignes de code), nous retiendrons :

• L’objet central n’est plus File mais Path : il faudra donc, comme pour le Path d’Eclipse RCP, raisonner en « segments » (une liste de noms) représentant une hiérarchie, le dernier niveau représentant le fichier ou le dossier pointé.
• Méthodes copyTo et moveTo directement intégrées à l’objet : et oui, terminé les Streams pour une copie ou un déplacement ! Il suffit d’avoir le Path d’origine, de définir le Path de destination et d’opérer directement l’opération souhaitée telle que fromPath.copyTo(toPath) ou fromPath.moveTo(toPath).
• Itérateurs améliorés : recherche de fichiers à partir d’un filtre (DirectoryStream) ou d’un visiteur (SimpleFileVisitor). Là encore, on a la possibilité d’effectuer un traitement métier soit sur un type de fichier spécifique (défini par exemple par l’extension du fichier) soit sur tous les fichiers présents dans un dossier.

// Filter
DirectoryStream xmlFiles = myFolderWithXmlFiles.newDirectoryStream("*.xml");
for (Path xmlFile : xmlFiles ) {
   // Stuff...
}
// Visitor
Files.walkFileTree(myFolerToVisit, new SimpleFileVisitor<Path>() {
   public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) {
      // Stuff...
   }
});

• Lecture des attributs des fichiers dont les principaux sont :

// Standard file attributes
BasicFileAttributes attrs = Attributes.readBasicFileAttributes(Path.get("test.xml"), true);
TimeUnit scale = attrs.resolution();
new Date(scale.toMillis(attrs.creationTime));
new Date(scale.toMillis(attrs.lastAccessTime));
new Date(scale.toMillis(attrs.lastModifiedTime));
attrs.isDirectory();attrs.isFile();attrs.isSymbolicLink();attrs.isOther();attrs.size();
...
// Dos file attributes
DosFileAttributes attrs = Attributes.readDosFileAttributes(Path.get("test.xml"), true);
attrs.isArchive();attrs.isReadOnly();attrs.isHidden();attrs.isSystem();
...
// Posix file attributes
PosixFileAttributes attrs = Attributes.readPosixFileAttributes(Path.get("test.xml"), true);
attrs.permissions();attrs.owner();attrs.group();
...

Cette très attendue API est prévue pour Java 7.

JVM 64 bits ? Oui mais avec compression des pointeurs

La généralisation des processeurs x86 et des systèmes d’exploitation 64 bits amène les exploitants à étudier l’utilisation de JVM 64 bits pour les serveurs d’applications Java. Si les JVM 64 bits permettent d’allouer de larges heap (> 3 Go), l’augmentation de la taille des pointeurs (de 4 à 8 octets) nuit aux performances et à la consommation mémoire (cf Revue de Presse du 26/05/2008).

C’est ce que montre David Dagastine, Java Platform Performance Lead, dans son article SpecJbb2005, la mémoire allouée à la JVM 64 bits est le double de celle allouée à la version 32 bits alors que les performances de cette version 32 bits sont tout de même 13% meilleures que celles de la version 64 bits.

Marcus Lagergren (BEA Systems) et Bob Kasten (Intel) exposent la parade mise en place par BEA :
Oracle/BEA : Aim High with JRockit on Intel Architecture

JRockit 64 bits offre depuis la version 5.0-R26.4 un mécanisme de compression des pointeurs (-XXcompressedRefs, activé par défaut si la taille de la heap est inférieure à 4 Gb) pour concilier les performances et la consommation mémoire des JVM 32 bits avec l’allocation de larges Heap spécifique aux 64 bits.

JRockit 5.0 R26-4 release notes : « Compressed references has greatly increased the performance on 64-bit platforms. »

Aujourd’hui, seuls les mécanismes de compression de pointeurs disponibles sur les JVM JRockit 5.0+ et IBM 6.0 permettent d’utiliser des JVM 64 bits sans dégradation des performances (10-20%) ni augmentation de la consommation heap (> 50%). Ces mécanismes ne sont pas encore disponibles sur la JVM de Sun.

Pour conclure, on citera les communications « officielles » de Sun et d’IBM sur ce sujet :

Sun : FAQ About the Java HotSpot VM / What are the performance characteristics of 64-bit versus 32-bit VMs?

« Generally, the benefits of being able to address larger amounts of memory come with a small performance loss in 64-bit VMs versus running the same application on a 32-bit VM. This is due to the fact that every native pointer in the system takes up 8 bytes instead of 4.
…
The performance difference comparing an application running on a 64-bit platform versus a 32-bit platform on SPARC is on the order of 10-20% degradation when you move to a 64-bit VM. »

IBM Java Technology Center: What’s the Difference Between 32 and 64 Bit Java? (pdf)

« At Java 5, 64 bit can be around 20% slower than corresponding 32 bit runtime
…
We assume a ~20-30% increase in object size heap consumption – but can be much larger »

Actualité éditeurs / SSII

• Spring Source : les VC prennent le contrôle
• JBoss certifié Java EE 5 : un anachronisme corrigé …
• … tandis que Websphere 7 sera le dernier grand sur la ligne d’arrivée

Agilité

• Le Scrum meeting, story par story ?

RIA

• Microsoft et Nokia adoptent jQuery

Le coin de la technique

• Les spécifications REST se terminent
• JVM Wish List vue par Terracotta
• Principes pour le design d’une API
• David Syer communique sur Spring Batch

Actualité éditeurs / SSII

Spring Source : les VC prennent le contrôle

Les semaines se suivent et ne se ressemblent pas chez Spring Source. Après le tumultueux revirement de stratégie Open Source il y a dix jours (cf. Nouvelle politique de maintenance de Spring : La très périlleuse route de monétisation de l’open source), Benchmark Capital, le principal fond d’investissement de Spring Source, prend le contrôle opérationnel de la société en nommant Rob Bearden President and Chief Operations Officer (COO). Rod Johnson conserve le titre de CEO.

C’est un véritable tournant dans la vie de Spring Source qui était jusqu’à présent gouvernée par son fondateur Rod Johnson et est aujourd’hui confrontée aux défis de la rentabilité et de la croissance.

Nous noterons au passage un clin d’oeil de l’histoire : Rob Bearden, avant de rejoindre Benchmark Capital, a été COO de JBoss. Le monde de l’Open source est petit, espérons que les relations conflictuelles entre les camps JBoss et Spring Source s’adoucissent

Les interrogations sont nombreuses : quelle place trouvera Rod Johnson dans cette nouvelle organisation ? Quelle stratégie Open source va adopter Rob Bearden ? Entérinera-t-il la nouvelle politique de commercialisation des releases post trois mois qui suscite encore une polémique très vive ?

Quelques liens :

• The Server Side : What will be next with SpringSource?
• Communiqué officiel : SpringSource Names President and Chief Operating Officer
• The Register : SpringSource VC investor takes COO role

JBoss certifié Java EE 5 : un anachronisme corrigé …

L’anachronisme que personne ne comprenait est enfin corrigé. JBoss Application Server, précurseur de Java EE 5 avec le support de JPA dans Hibernate et la Web Application qui jouait le rôle d’un conteneur d’EJB 3 est enfin certifié Java EE 5. Sacha Labourey, JBoss, annonce dans JBoss AS is now EE5 certified! que la version release sera disponible dans les semaines à venir. Il n’en reste pas moins que JBoss AS 5 est une refonte sur le fond du serveur d’application (nouveau messaging, clustering, etc) qui a duré plus de trois ans (cf InfoQ : Releasing JBoss AS 5: Q&A with Project Lead Dimitris Andreadis) et qu’on peut s’attendre à une phase de stabilisation de la nouvelle stack JBoss.

… tandis que Websphere 7 sera le dernier grand sur la ligne d’arrivée

IBM nous rappelle avec Websphere que les parts de marché sont parfois décorrélées de l’implémentation des dernières spécifications. Websphere 7 sera le dernier grand serveur Java EE a être certifié Java EE 5.

La version d’évaluation est déjà disponible sur DeveloperWorks ; des blogs (Websphere Community et Websphere and Messagin) relaient la communication institutionnelle.

Agilité

Le Scrum meeting, story par story ?

Les daily standup meetings se déroulent habituellement personne par personne, c’est-à-dire que chaque membre de l’équipe répond aux 3 questions l’un après l’autre. Le défaut de cette méthode selon Mike Cohn est qu’elle ne permet pas toujours de voir les problèmes sur les stories dont personne ne s’occupe puisque personne n’en parle.
Il suggère la possibilité d’attaquer le standup story par story, mais on perd alors en visibilité sur ce que fait chaque personne. Face à ce dilemme, plusieurs solutions sont possibles :

• L’équipe s’engage t-elle sur trop d’items par sprint ? Mike préconise une moyenne de 1 à 1,5 story / personne / sprint. Attention, cela ne veut absolument pas dire qu’une story doit être gérée par une seule personne !
• Faire le standup devant le tableau des tâches, afin que chaque personne puisse pointer les items sur lesquels elle travaille.
• Désigner des « story owners » : pour chaque story, une personne de l’équipe est responsable de son avancement. Cette personne n’est pas forcément le développeur principal de la story.
• Regarder la taille de l’équipe : selon ses observations la taille idéale d’une équipe se situe entre 5-7 personnes.

La plupart des équipes font leur standup par personne, mais certaines équipes peuvent se heurter à un manque de visibilité sur certaines stories. Cette vision « story par story » peut répondre à leurs attentes.

RIA

Microsoft et Nokia adoptent jQuery

À part GWT avec Google, un des reproches que l’on peut faire aux librairies JavaScript/AJAX est leur absence de support par un grand éditeur. Cet état de fait pourrait bien changer pour la librairie jQuery, une de nos librairies favorites, que l’on conseille et rencontre de plus en plus fréquemment chez nos clients. jQuery annonce sur son blog l’adoption par Microsoft et Nokia du framework, et son intégration dans leur plateforme de développement officielle respective.
jQuery sera donc distribué avec Visual Studio, et sera présent dans tous les nouveaux téléphones de Nokia qui utiliseront le moteur de rendu maison Web Runtime.
Les bénéfices pour jQuery et ses utilisateurs sont multiples : la reconnaissance de la librairie comme parmi les plus populaires, et son amélioration via la soumission de patchs et de tests. Excellente nouvelle donc !

Le coin de la technique

Les spécifications REST se terminent

Vous en entendrez certainement parler prochainement à l’occasion de Spring 3.0, les spécifications de la JSR-311 : Java API for RESTful Web Service (JAX-RS) ont été approuvées quasi unanimement (15 pour, 0 contre, 1 non votant) par l’executive comitee.

JAX-RS est une API permettant l’implémentation de Web Services REST, son fonctionnement est simple :

• on rajoute des annotations sur des classes et des méthodes pour décrire les services à exposer et la manière de les exposer
• le choix du service s’effectue en fonction des URL / Content type / Headers et type de requête HTTP

REST étant à la mode, plusieurs framework existent déjà dont :

• Jersey, l’implémentation de référence pour JAX-RS développée par Sun
• Restlet, le framework du moment le plus utilisé pour les applications REST
• CXF RESTful Services, l’implémentation JAX-RS du projet Apache CXF
• RESTeasy, la version JBoss

Une interview des specs leads Marc Hadley et Paul Sandoz est disponible sur InfoQ. Une des questions intéressantes porte sur l’influence de la JSR311 sur les spécifications de Servlet. Cela nous rappelle que, même si les API REST et les Servlets ont des approches complètement différentes, ces deux technologies doivent pouvoir cohabiter et travailler ensemble.

JVM Wish List vue par Terracotta

Cet article présente une liste d’améliorations JVM espérées vues par un spécialiste Terracotta. S’il est vrai que cet outil aborde des problématiques peu communes (clustering de JVM), certaines de ces idées pourraient être utiles pour tout autre framework utilisant l’instrumentalisation de code.

Voici les idées proposées par Steeve Haris dans son article regroupées par domaines, elles permettent de :

• Simplifier grandement le code de ce genre de framework en évitant d’avoir à développer des surcouches logicielles simulant certaines de ces fonctionnalités
• Permettre de créer des proxy d’objets niveau JVM : cela faciliterait le maintien de la heap virtuelle de Terracotta
• Pouvoir associer des métadatas à un objet : cela permettrait d’affiner les choix du memory manager de Terracotta
• Faciliter le développement de tricks en améliorant le _Hot swapping_
• Optimiser le nombre d’objets à instrumentaliser
• Permette d’instrumenter des tableaux sans avoir besoin de passer par les classes les utilisant
• Permettre le remplacement de méthodes natives : actuellement si l’on veut modifier le comportement d’une méthode native, nous somme obligé d’instrumenter tous les objets appelant celle-ci.
• Adapter la JVM aux architectures d’aujourd’hui
• La taille des listes et des collections est définie par un int. Les architectures 64 bits nous permettant d’ajouter de plus en plus de mémoire, il se peut que cette taille devienne insuffisante dans certaines utilisations.

Principes pour le design d’une API

Joshua Bloch (Google), auteur de Effective Java, énumère un ensemble de principes clés afin de réussir la conception et la réalisation d’une API : Bumper-Sticker API Design.

Une API n’est pas seulement mise en place dans les frameworks mais aussi dans des applications à différents niveaux :

• la couche d’accès aux données
• la couche service

La volonté d’une API est de réaliser un module cadré au fonctionnement clair. Le fonctionnement interne du module est caché derrière un contrat d’utilisation (qui ne repose pas nécessairement uniquement sur des interfaces Java). Le terme d’utilisabilité de l’API peut être employé.

L’utilisabilité d’une API peut être décrite avec les spécificités suivantes :

• contrat d’utilisation simple et explicité, cela passe par le nommage des éléments (classe, méthode, argument, …).
• l’intégration aux cas d’utilisation doit être naturelle. Pour que ce soit le plus naturel possible, on peut même envisager de d’abord coder les cas d’utilisation avec l’appel à l’API et ensuite coder l’implémentation de l’API.
• l’implémentation de l’API doit être indépendante du contexte d’appel

Le développement d’API pose le problème de la gestion des versions. A partir du moment où elle est exposée, une API doit répondre de la même façon à tous les appels, quel que soit le client sollicitant le service. Il est vital de respecter les principes de l’IoC Inversion of Control, et ne pas enrichir chaque version d’un ou plusieurs comportements spécifiques :

if (isClient1) {
  // Traitement spécifique client 1
} else if (isClient2) {
  // Traitement spécifique client 2
} else {
...
}

Des principes qui font généralement débats sont aussi présentés :

• Faire peu de documentation, les noms des classes/méthodes doivent être explicites
• Ne pas remonter de CheckException que des RuntimeException

Il est vrai que la principale difficulté d’une API est de bien faire dès la première version. La moindre modification du contrat d’utilisation de l’API entraînera des régressions chez les clients de l’API.

C’est pour cette raison qu’il faut tenter de faire un premier jet aussi bref et concis que possible, et de ne traiter la multiplicité des cas qu’au fur et à mesure de leur apparition, dans des versions ultérieures.

Pour conclure, on reprendra la phrase de Joshua Bloch : le design d’API est un art, pas une science exacte.

N’hésitez pas à visionner le vidcast associé à cet article.

David Syer communique sur Spring Batch

Nous vous l’annoncions avant l’été, David Syer, le leader technique de Spring Batch, a entamé sa « tournée promotionnelle ».

À travers ce vidcast, capté au QCon de Londres et relayé par InfoQ (ou bien via le support de présentation), il revient sur :

• les patterns de batch et leur utilisation
• un survol des concepts de SpringBatch
• une étude de cas
• l’avenir de ce produit

D’autre part, dans une autre vidéo publiée sur TV4it, Olivier Rachon, Senior Manager chez Accenture, nous en dit plus quant à l’utilisation de ce récent framework : 5 projets en production, des 10aines en cours de développement.

Pour information, la version 1.1.2 est disponible et les premiers tests que nous avons effectués, dans le cadre d’un XKE, nous ont paru très convaincants. Nous devrions publier prochainement notre retour d’expérience sur ce framework.

Agilité

• Agile 2008 : La sagesse des foules

RIA

• FXStruts
• Interopérabilité Java – Silverlight
• HTML immobilisé par les tergiversations … pendant que les RIA progressent

Le coin de la technique

• Les nouveautés de Seam 2.1

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

• JSF One – Septembre 2008

Agilité

Agile 2008 : La sagesse des foules

La conférence Agile 2008 qui se déroulait à Toronto s’est terminée vendredi dernier. Avec près de 1600 participants et 400 présentations c’était la plus grande (trop grande ?) conférence Agile jamais organisée. Les retours sur le niveau des présentations semblent plutôt positifs bien que la qualité des sessions était inégale, certaines déceptions venant parfois des stars.

La conférence a débuté avec un très bon discours de James Surowiecki, auteur du livre The Wisdom of Crowds (La sagesse des foules). InfoQ revient sur la thèse de ce livre : « une décision prise par un groupe de personnes est souvent meilleure que la meilleure décision de n’importe quelle personne du groupe« . Cette affirmation est toutefois soumise à quelques contraintes : un groupe sage est un groupe diversifié, où chaque membre prend une décision de façon indépendante, et qui sait agréger l’ensemble des décisions individuelles pour obtenir une décision collective.

Robert C. Martin – surnommé l’oncle Bob – a donné un discours intitulé Quintessence dans lequel il propose d’ajouter un cinquième élément au Manifeste Agile : il appelle les développeurs à se laver les mains, c’est-à-dire à écrire du code propre, à ne pas faire de compromis sur la qualité.
Il tire aussi une caricature des 2 méthodes Scrum et XP en les comparant à Obama et Mc Cain : Scrum à cause de son idéalisme et de ses certifications, et XP car la méthode est trop stricte. Il rappelle que la conférence Agile 2008 est une fusion de deux anciennes conférences respectivement sur Scrum et XP, ce qui confirme le fait que les 2 méthodes ont fusionné en un seul ensemble de pratiques agiles.

Alan Cooper a clôturé la conférence avec sa présentation The Wisdom of experience. Il en a profité pour rappeler que sa conviction pour l’interêt de la conception détaillée par écrit ne fait pas de lui un adhérent à la méthode Waterfall.

Voici quelques blogs parlant d’Agile 2008, dont certains sont cités précédemment. En français :

• Alexandre Boutin
• Valtech

En anglais :

• Gojko Adzic
• Kent McDonald
• Mishkin Berteig
• Klinton Keith
• Lisa Crispin
• Tom Perry

Rendez-vous l’année prochaine à Chicago.

RIA

FXStruts

Cet article nous présente un nouvelle librairie open source: FXStruts. Cette dernière, développée, par Anirudh Sasikumar permet d’intégrer Flex dans la partie Vue de Struts. Le principe est assez simple: cette librairie fonctionne sur le même principe du tag bean:write dont l’output sera de l’AMF ou du XML. Pour cela, deux tags sont disponibles :

• fx:write équivalent au tag bean:message.
• fx:message équivalent au tag bean:write.

Le code source est accessible sur le repository de google et des aides à la migration d’applications Struts en Flex sont données.
Pour le moment, l’inconvénient majeur de cette libraire est qu’elle n’a été testée que pour la version 1.3.8 de Struts.
Ce projet témoigne encore de l’engouement pour les technologies RIA et plus particulièrement de Flex. A quand un FXStruts pour Struts 2 ?

Interopérabilité Java – Silverlight

Derrière le leader des RIA Flex, Microsoft s’accroche et tente d’imposer son RIA Silverlight.
En attendant la sortie de la version 2 et un billet plus complet sur ce blog, InfoQ présente un tutoriel pour interfacer Silverlight avec des Webservices Java (SOAP, REST et RSS).

Nous retiendrons les conclusions de cet exercice :

• Les technologies de communication de prédilection de Silverlight pour accéder à des backends Java sont SOAP, REST (aka XML sur HTTP) et RSS
• SOAP pose les classiques problèmes d’interopérabilité entre les mondes .Net et Java. Silverlight n’offre pour le moment que le support de WS-I Basic Profile (WS-I Basic Security Profile, n’est pas encore disponible).
• Le support de REST manque de maturité. La documentation est obsolète voire erronée. Les implémentations RESTful qui utilisent simplement HTTP POST ou GET (plutôt que PUT et DELETE) sont celles qui fonctionnent le mieux avec Silverlight.
• Si SOAP est un bon choix pour les accès en écriture, REST est en revanche plus simple à utiliser pour les accès en lecture.
• L’accès à des flux RSS est facile à mettre en place.
• Un des concepts fondamentaux à retenir est que Silverlight s’exécute dans un browser. C’est pourquoi il possède tous les problèmes inhérents aux composants ‘embarqués’ dans le navigateur : les problèmes de cross domaines, les limitations sur le nombre de connexions au navigateur, le support des différents types MIME, etc. Ces problématiques doivent être abordées durant le développement.

A noter, les références vers des objets JAXB devraient être supportées dans Silverlight 2 RTM de la même manière qu’elles le sont dans .NET Framework 3.5 SP1 (DataContractSerializer).

HTML immobilisé par les tergiversations … pendant que les RIA progressent

InfoQ revient sur les tergiversations autour des évolutions de HTML dans XHTML 2 and HTML 5 continue to diverge.
Pour mémoire,

• XHTML V2 est issu du W3C. Dans la veine du toujours confidentiel Web Sémantique soutenu par le W3C, l’objectif principal de XHTML V2 est de renforcer la séparation entre le contenu et la présentation.
• HTML V5 est une proposition du Web Hypertext Application Technology Working Group (principalement Google, Apple, Mozilla et Microsoft) suite à un désaccord avec la direction prise par XHTML V2. HTML V5 se veut plus pragmatique et met l’emphase sur la dimension Rich Internet Application (interactions browser-serveur, édition de documents, drag&drop, etc).

Pendant ces hésitations, les éditeurs de RIA continuent à ajouter des fonctionnalités à leurs environnements graphiques et Adobe va même jusqu’à évoquer des applications web widget-centric qui ne passeraient même plus par des browsers mais directemment des liens sur le bureau du système d’exploitation.

Plus de détails dans XHTML 2 vs. HTML 5 par Vinny Carpenter.

Le coin de la technique

Les nouveautés de Seam 2.1

Peter Muir, JBoss, présente dans DZone : What’s New in Seam 2.1 – An interview with Peter Muir les nouveautés de Seam 2.1.

Pour rappel, Seam est un framework permettant le développement d’applications web d’entreprise. Seam intègre des technologies Java EE 5 comme JSF, EJB 3, JPA. Il fournit également un ensemble d’API et d’annotations afin de faciliter le développement avec ces technologies. Seam tente de prendre les meilleures idées de chacune des technologies pour que le développeur ait à faire le moins de couture¹ possible, c’est à dire du développement purement technique pour intégrer les différentes couches de l’application.

Seam pose les bases des GWT et Wicket dans Seam 2.1. Le support GWT permettra à Seam de déléguer son rendu à celui-ci alors que le support de Wicket est plus complet. Wicket pourra directement utiliser des composants et des conversations Seam. Côté RIA, l’intégration de Flex est également à l’étude.

Les principaux changements que l’on peut attendre de Seam 2.1 sont :

• Les performances
• La sécurité : gestion de l’identité, gestion des habilitations sur les écrans, les workflows, …
• Amélioration du support REST : intégration de JAX-RS, JSR 311 et de RESTeasy, implémenté par un autre JBoss-ien : Bill Burke.

Web Beans est une spécification Java EE. Cette spécification se base sur Seam mais aussi Guice, le framework d’injection de dépendance de Google.

Voici quelques problématiques couvertes par Web Beans :

• Gestion des conversations
• Injection des dépendances
• Création de composants et la gestion de leurs cycles de vie
• Intégration de transactions
• Intégration de JPA
• Mécanismes de validation (Formulaire, métier, donnée, …)

La version 3 de Seam est actuellement en bêta. On peut espérer une sortie courant 2009. Cette version proposera un nouveau modèle de composant, à suivre …

¹ Seam signifie en français couture

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

JSF One – Septembre 2008

Du 4 au 6 septembre 2008 se tiendra une série de conférences autour de JSF : JSF One.

Les principaux sujets abordés seront :

• JSF 2.0 (JSR 314) (sera embarqué dans Java EE 6)
• Facelets
• Spring Integration
• Seam
• Développement Portlet
• Test
• Sripting JSF
• Développement de composant
• Suite de composant comme RichFaces (JBoss), ICEfaces, …
• Intégration des API Google

Les principaux acteurs du marché seront représentés : Sun, Spring, JBoss, etc. Voici le détail du programme et des intervenants.