On parle également de failover pour parler de la capacité à rendre l’indisponibilité d’un ou de plusieurs serveurs du cluster complètement transparente vis à vis du client; cela se traduit par le fait de garantir au client la reprise du même contexte d’exécution qui existait en amont de l’apparition de la panne du serveur incriminé.

Glassfish V3, l’implémentation de référence de JEE6 (JSR 316), inclut à partir de sa version 3.1 des nouvelles fonctionnalités de clustering (synchronisation lors du démarrage d’une nouvelle instance, réplication des changements dynamiques de configuration,…), et offre également un mécanisme de réplication de la session http et des EJB statefull.

Au cours de cet article nous aborderons la mise en place d’un cluster glassfish, la configuration Apache avec le plugin Glassfish Load Balancer et le test du failover à travers une application web.

Il faut noter que toutes les étapes d’installation et de configuration peuvent être réalisées en mode console ou en mode GUI (à travers la console d’administration Glassfish). L’approche console (ligne de commande) a été adoptée.

Outils & téléchargements

• Glassfish 3.1 : http://dlc.sun.com.edgesuite.net/glassfish/3.1/release/glassfish-3.1.zip (en édition Open source sous licence CDDL ou GPLv2, la version commerciale est disponible ici)
• clusterjsp.ear : http://blogs.sun.com/arungupta/resource/glassfish/clusterjsp.zip (Application web qui nous permettra d’illustrer le mécanisme de la réplication de session)
• Glassfish Load Balancer plugin: http://download.oracle.com/otn-pub/java/ogs/3.1//glassfish-lbconfigurator-3_1.zip

Architecture cible

L’architecture présentée dans la figure ci-dessous fait apparaître les composants suivants:

• Un cluster Glassfish de deux instances pilotées par le DAS (Domain Administration Server) et tournant sur un «MacOS».
• Un serveur HTTP (Apache) intégrant un load balancer de type Glassfish Load Balancer et tournant sur une machine virtuelle «CentOS» dans un environnement virtualisé «VirtualBox».

La réplication de session: Principe de fonctionnement

La réplication de la session est assurée par un module OSGI, chargé uniquement lorsque la haute disponibilité est activée au niveau des applications déployées.

Le module de réplication permet de distribuer uniformément les états de la session sur les serveurs abonnés au cluster.

Il utilise GMS (Group Management Service) qui est également un module OSGI responsable des notifications concernant les instances joignant ou quittant le cluster; ces évènements, une fois consommés par le module de réplication, lui permettront de choisir l’instance la plus appropriée pour répliquer la session.

Il est utilisé par le conteneur web pour la réplication de la session HTTP et par le conteneur EJB pour la réplication des SFSB.

Load Balancing: Failover avec Apache & Glassfish LB Plugin

• Instance1 OK:

La requête «Request1» émise par un utilisateur «Utilisateur1» arrive au niveau du LB qui la route vers l’instance «Instance1»

La session «Session1» ainsi créée, peut être répliquée par le module de réplication sur l’instance «Instance4».

La requête «Request2» peut être également routée vers l’instance «Instance1» par le LB. Le module de réplication répliquera la session «Session2» sur une autre instance dans la mesure du possible (dans le cas où l’on dispose de plus de deux instances dans le cluter), «Intance2» par exemple.

Le module de réplication ne réplique pas l’ensemble des sessions d’une instance donnée sur une même autre instance, il essayera de les répartir sur l’ensemble des instances du cluster. La session est répliquée sur une seule instance et non pas sur la totalité des instances du cluster.

• Instance1 KO:

Dans le cas où l’instance «Instance1» n’est plus accessible, Glassfish LB plugin routera la requête «Request1» vers l’instance «Instance4» vu qu’elle contient les données répliquées de la session «Session1» qui sera nouvellement répliquée sur une autre instance, en l’occurrence sur l’instance «Instance3». De même, la requête «Request2» sera routée vers l’instance «Instance2» et la session «Session2» sera répliquée sur l’instance «Instance4».

Load Balancing: Failover avec Apache LB & mod_jk

La politique de load balancing avec le load balancer Apache est différente de celle du load balancer Glassfish et elle est moins optimisée et moins performante. En effet le load balancer ne dispose pas des informations nécessaires pour router la requête vers une instance qui possède déjà la session répliquée.

Si le load balancer Apache route la requête «Request1» vers l’instance «Instance3», un «pull» de la session «Session1» à partir de l’instance «Instance4» est donc nécessaire.

Création du cluster

Le cluster est composé de deux instances sur un même nœud (un nœud est une représentation logique d’un host). Pour ce faire déroulez la suite des commandes suivantes:

• Démarrer le serveur d’administration:

  asadmin start-domain
  

• Activer le mode SSL pour sécuriser la connexion entre les instances du cluster et le DAS (Domain Application Server):

  asadmin enable-secure-admin
  

• Redémarrage du DAS pour prise en compte du mode SSL:

  asadmin restart-domain
  

• Création du cluster «cluster1»:

  asadmin create-cluster cluster1
  

• Afficher la liste nœuds:

  asadmin list-nodes
  

• Créer «instance1» sur le noeud «localhost-domain1» dans le «cluster1»:

  asadmin create-instance --node localhost-domain1 --cluster cluster1 instance1
  

• Créer «instance2» sur le noeud «localhost-domain1» dans le «cluster1»:

  asadmin create-instance --node localhost-domain1 --cluster cluster1 instance2
  

• Vérifier la création du «cluster1»:

  asadmin list-clusters
  

• Démarrer le «cluster1»:

  asadmin start-cluster cluster1
  

Déploiement de l’application clusterjsp

Il s’agit de déployer l’application clusterjsp.war sur le cluster «cluster1» précédemment créé en activant la haute disponibilité:

asadmin deploy --target cluster1 --availabilityenabled=true clusterjsp.ear

Il faut savoir que les applications de type «Servlet API Based Web Application» ne sont pas «clusterisables» par défaut. Pour qu’une application puisse être déployée sur un cluster, il faut qu’elle déclare un tag spécifique dans le web.xml: <distributable /> (Official Web App DTD 2.2). Ce tag fut intégré dans l’API Servlet à partir de sa version 2.2 (version introduite dans J2EE 1.2).

Test du failover sans load balancing:

• Saisir l’URL suivante: http://localhost:28080/clusterjsp/HaJsp.jsp:

• Ajouter des variables de session à l’aide du formulaire suivant:

• Arrêter «instance1»:

  asadmin stop-instance instance1
  

• Accéder à «instance2»: http://localhost:28081/clusterjsp/HaJsp.jsp:

Préparation de la VM: CentOS 32 bits (Apache & Glassfish LB plugin)

Installation Apache en mode SSL: http://wiki.centos.org/HowTos/Https

Le SSL est nécessaire pour pouvoir utiliser l’option de déploiement automatique de la configuration LB à partir du DAS vers la machine sur laquelle est installé le Glassfish LB plugin.

Installation du Glassfish LB plugin

Le plugin n’est pas compatible avec tous les OS notamment MacOs et HP-UX (Supported Operating Systems and Web Servers).

• Lancer l’installation du plugin avec la commande suivante:

  java -jar glassfish-lbconfigurator-3_1.jar
  

• Choisir «Apache serveur» et compléter la suite des instructions.

	Le plugin n’est compatible qu’avec une version apache 2.2.x. La vérification la version d’apache installée est donc faite avant le lancement de l’installation en essayant d’exécuter la commande suivante: $APACHE_HOME/bin/apachectl
	Si ce script n’existe pas à l’emplacement recherché par le plugin, la solution la plus simple consiste à en créer un avec les droits d’exécution (chmod 755 apachectl) qui pourrait contenir les lignes suivantes: $APACHE_HOME/bin/apachectl #!/bin/bash /usr/sbin/apachectl -v

Assurez-vous également d’avoir les fichiers «httpd-ssl.conf» et «httpd-vhosts.conf» sous le répertoire «$APACHE_HOME/conf/extra» qui seront enrichis par la configuration SSL nécessaire au LB.

Une fois l’installation terminée, vous devez les déplacer dans le répertoire «$APACHE_HOME/conf.d» de manière à ce qu’ils soient inclus dans le fichier de configuration principale «httpd.conf» par le biais de la directive <Include> qui existe déjà (Include conf.d/*.conf), ou éventuellement, rajouter le <Include> qui va bien.

• Exporter le certificat de glassfish:

  L’upload de la configuration LB est réalisé en Https. Il est donc nécessaire d’exporter le certificat de Glassfish et de l’intégrer au niveau de la configuration Apache SSL du LB.

  Sur la machine du serveur Glassfish, exécutez le script suivant:

  export_certificate.sh

  keytool \
  -export \
  -rfc \
  -alias s1as \
  -keystore $GLASSFISH_HOME/glassfish/domains/domain1/config/keystore.jks \
  -file ./glassfish.crt \
  -storepass changeit
  

• Copier le certificat sur la machine du LB:

  scp glassfish.crt root@glassfishlb:/etc/httpd/conf/ssl.crt/
  

• Récupérer le subject et le serial number du certificat avec la commande suivante:

  keytool -printcert -file glassfish.crt
  

Les valeurs concernant l’organisation (O), l’unité d’organisation (OU) et le serial number seront utilisées par la suite pour compléter la configuration SSL du LB. Le serial number devrait être saisi en majuscule.

• Renseigner les informations liées au certificat dans le fichier «httpd-ssl.conf»

    SSLVerifyClient require
    SSLVerifyDepth 1
    SSLRequireSSL
    SSLCACertificateFile /etc/httpd/conf/ssl.crt/glassfish.crt
    SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)-/ \
     and %{SSL_CLIENT_S_DN_O} eq "Oracle Corporation" \
     and %{SSL_CLIENT_S_DN_OU} eq "GlassFish" \
     and %{SSL_CLIENT_M_SERIAL} eq "4D5A2F07" )
    SSLVerifyClient require
    SSLVerifyDepth 1
    SSLRequireSSL
    SSLCACertificateFile /etc/httpd/conf/ssl.crt/glassfish.crt
    SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)-/ \
     and %{SSL_CLIENT_S_DN_O} eq "Oracle Corporation" \
     and %{SSL_CLIENT_S_DN_OU} eq "GlassFish" \
     and %{SSL_CLIENT_M_SERIAL} eq "4D5A2F07" )
  ##END GlassFish Load-Balancer Plugin Configuration
  

Apache aura du mal à redémarrer et principalement à cause de l’absence des librairies nécessaires au module «mod_loadbalancer.so» dans le path et/ou sur le disque:

httpd: Syntax error on line 1011 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/mod_loadbalancer.so into server: libicuuc.so.2: cannot open shared object file: No such file or directory

Assurez-vous de la disponibilité de toutes les dépendances du module «mod_loadbalancer.so» et ajoutez la variable d’environnement «LD_LIBRARY_PATH» dans le fichier «/etc/init.d/httpd» export LD_LIBRARY_PATH=/etc/httpd/glassfish-lbplugin/lib/ Vous pouvez également déclarer cette variable d’environnement au niveau du fichier «$APACHE_HOME/bin/envvars» s’il est bien chargé au niveau du démarrage du demon httpd.

Vous pouvez également anticiper le problème lié au listener https lors de la communication ssl entre le serveur glassfish et le LB qui se manifeste par le warning ci-dessous dans les logs apache:

[warn] lb.healthchecker: HLCK3003: Listener: [http://192.168.1.16:24849] is detected to be still unHealthy in cluster: cluster1

Rajoutez également ces lignes pour permettre le NSS (Network Security Services) forking. export NSS_STRICT_NOFORK=DISABLED

Création du LB et déploiement de la configuration à partir du DAS

• Créer le LB

  asadmin create-http-lb --devicehost glassfishlb --deviceport 443 --target cluster1 cluster_lb
  

• Déployer le configuration sur la VM de Glassfish LB plugin:

  asadmin apply-http-lb-changes cluster_lb
  

	Dans le cas où vous êtes confrontés à des problèmes de certificat SSL lors du déploiement du fichier de configuration LB vous pouvez toujours l’exporter et remplacer le contenu du fichier $APACHE_HOME/conf/loadbalancer.xml.
	Exporter le fichier de configuration asadmin export-http-lb-config --lbname cluster_lb

$GLASSFISH_HOME/glassfish/domains/domain1/load-balancer/loadbalancer.xml.cluster_lb_LB_CONFIG

<!--?xml version="1.0" encoding="UTF-8"?-->
<!DOCTYPE loadbalancer PUBLIC "-//Sun Microsystems Inc.//DTD Sun Java System Application Server 9.1//EN" "glassfish-loadbalancer_1_3.dtd">
<loadbalancer>
  <cluster name="cluster1" policy="round-robin">
    <instance disable-timeout-in-minutes="30" enabled="true" listeners="http://$HOSTNAME:28080 https://$HOSTNAME:28181 http://$HOSTNAME:24848" name="instance1" weight="100"/>
    <instance disable-timeout-in-minutes="30" enabled="true" listeners="http://$HOSTNAME:28081 https://$HOSTNAME:28182 http://$HOSTNAME:24849" name="instance2" weight="100"/>
    <web-module context-root="/clusterjsp" disable-timeout-in-minutes="30" enabled="true"/>
    <health-checker interval-in-seconds="10" timeout-in-seconds="30" url="/"/>
  </cluster>
  <property name="response-timeout-in-seconds" value="60"/>
  <property name="reload-poll-interval-in-seconds" value="60"/>
  <property name="https-routing" value="false"/>
  <property name="preferred-failover-instance" value="true"/>
  <property name="require-monitor-data" value="false"/>
  <property name="rewrite-location" value="true"/>
  <property name="number-healthcheck-retries" value="3"/>
  <property name="active-healthcheck-enabled" value="false"/>
  <property name="rewrite-cookies" value="false"/>
</loadbalancer>

Test du failover avec load balancing:

• Saisir l’URL suivante: http://glassfishlb/clusterjsp/HaJsp.jsp et ajouter quelques variables de session:

• Arrêter «instance1»:

  asadmin stop-instance instance1
  

• Rafraichir la page http://glassfishlb/clusterjsp/HaJsp.jsp

Conclusion

Au cours de cet article nous avons pu voir la mise en place d’un cluster d’instances vivants dans un même nœud. Il faut savoir qu’il est également possible de faire cohabiter dans un même cluster, des instances créées sur des nœuds différents. La gestion centralisée des nœuds au niveau du DAS est assurée par accès en SSH aux différentes machines; elle remplace la notion de «node-agent» dans Glassfish V2.

Si vous êtes dans ce cas d’utilisation, les principales commandes à utiliser pour la création des nœuds et des instances du cluster seraient les suivantes:

• Configurer SSH

  asadmin setup-ssh ${node-host}
  

• Installer le serveur glassfish sur la machine distante:

  asadmin install-node --installdir ${install-dir} ${node-host}
  

  Cette commande effectuera une copie du zip d’installation du serveur glassfish sur la machine distante; ce qui permettra d’exécuter par la suite les commandes «asadmin» à distance.

• Créer le noeud

  asadmin create-node-ssh --installdir ${install-dir} --node ${node-host} ${node-name}
  

• Désormais, les opérations de création d’instances sont possibles. Il suffit de spécifier le cluster et le target node

  asadmin create-instance –cluster ${cluster-name} --node ${node-name} ${instance-name}
  

• Une solution pour le marshalling JSON
• Un serveur web NIO supportant le long polling
• Une solution pour la persistence et le partage des données

Notre démarche a été de réaliser des POCs implémentant la création des utilisateurs et le long polling pour retenir la meilleure solution. La solution devait être simple et rapide à implémenter, et tenir une charge conséquente en la testant à l’aide de ab l’outil de benchmark Apache et de la librairie Async Http Client. Pour le JSON, nous nous sommes tous rapidement mis d’accord sur l’utilisation de la librairie Jackson. Nous étions tous convaincus qu’il nous faudrait un serveur web NIO sans passer par la case Servlet. C’est à partir de là que notre tour d’horizon des API NIO en Java a commencé.

Pourquoi NIO ?

Revenons d’abord à l’essentiel, nous ne pouvons justifier notre choix sans expliquer ce qu’est cette API Java. Cette API existe depuis la version 1.4 du JDK et permet essentiellement de réaliser des traitements non-bloquants sur les entrées-sorties. NIO est en fait l’acronyme de New IO, la nouvelle api java.nio vient en supplément de l’API java.io existante.
Prenons l’exemple d’une Socket en Java, par défaut les opérations de lecture et d’écriture sont bloquante. Le thread lançant une opération de lecture ou d’écriture sur Socket sera bloqué sur cet appel tant que l’opération ne sera pas terminée. Tant qu’il n’y aura rien à lire sur la socket ou qu’il n’y aura pas d’espace disponible pour écrire dessus, le thread sera bloqué. Il sera aussi débloqué en cas d’exception dû à un timeout par exemple.

Depuis java.nio, il est possible de réaliser ces appels sans avoir à attendre qu’il y ait de l’espace libre ou des données à lire sur la Socket. Pour éviter ce temps de bloquage, l’API fournit un système pour écouter les évènements sur les sockets il s’agit du Selector. On enregistre la ou les Sockets dans le selector en précisant si l’on veut lire et/ou écrire, et/ou accepter des connexions sur la socket. Sur chaque appel à select(), le sélecteur créera une liste des Channel pour lesquels une opération est prête à réaliser. Bien sûr, le serveur devra toujours attendre qu’il y ait des opérations disponibles sur ses sockets clients, mais la grande différence est que le serveur attend une fois pour l’ensemble de ses clients au lieu d’attendre une fois par client.

Pendant que le thread de l’API historique java.io attend un client, un Thread utilisant java.nio pourra traiter d’autres clients. Pour traiter les requêtes en parallèle avec l’API java.io, il suffit de multiplier le nombre de Thread avec un thread par client, il n’y aura pas d’attente non plus. Malheureusement on ne peut pas multiplier indéfiniment les Threads sans impact sur l’espace mémoire. Dans le cadre du challenge, nous étions limités en mémoire et nous devions supporter le maximum possible de client concurrents. Avec son faible nombre de Threads (1 par CPU) et donc sa consommation de mémoire inférieur, NIO est rapidement devenu une évidence pour tous.
Pour ces même raisons, nous avions décidé d’éliminer les serveurs de Servlet. L’API Servlet est consommatrice par essence et apporte une quantité non négligeable de raffinements dont nous n’avions pas besoin. Depuis l’API Servlet 3.0, il est possible de réaliser des Servlets Asynchrone qui permettent de libérer le Thread d’exécution de la requête pour envoyer la réponse plus tard à partir d’un autre Thread. Par curiosité nous avons donc testés Tomcat 7 en Servlet asynchrone, avec de forts à priori.

Le test

Afin de départager les différentes API, nous avons réalisé une implémentation du service de création des utilisateurs qui les persistent dans une Map. Quelque soit le framework, le service de mapping du JSON et de persistance sont les mêmes. Ainsi, nous pouvions nous intéresser à notre seul problème: la performance du serveur HTTP. Les tests ont été réalisés sur un macbook pro 2,4 Ghz core i5 sans optimisation de JVM. Les seules modifications réalisées sur le système sont:

• L’augmentation du nombre de port éphémères via sysctl net.inet.ip.portrange.first
• La réduction du maximum segment lifetime afin de réduire la durée de réservation des sockets en TIME_WAIT.
  Ces configurations ont pour seule but de permettre à ab d’injecter une charge conséquente sans souffrir de timeout dûe à un nombre trop élevé de socket réservé.

Tour d’horizon des implémentations NIO

Restlet

Restlet est un framework REST qui embarque le serveur HTTP et permet de choisir parmi différentes implémentations de Mina par défaut à Jetty en passant par Grizzly et Netty.
Restlet, semblait donc parfaitement adapté à la réalisation du serveur REST tout en nous offrant la possibilité de choisir le serveur à utiliser. En ultime recours sachez tout de même qu’il est parfaitement possible d’embarquer Restlet dans un war.
Nous avons donc créé un POC pour le service de création des utilisateurs (1Million d’utilisateurs en moins d’une heure). Après quelques tests rapides, l’API est convaincante pour sa simplicité d’utilisation et sa rapidité de prise en main. Mais les performances ne sont pas à la hauteur de nos espérances. Nous étions bien sûr largement capables de créer le million d’utilisateur en moins d’une heure, mais le temps passé dans les API Restlet, Mina et Jetty était trop impactant. Nous avons testé ce POC avec Mina et Jetty sans nous intéresser aux autres solutions que nous souhaitions tester en direct. Pour la solution Jetty, ab indiquait en moyenne 5k requêtes par secondes pour un temps de traitement moyen de 11ms à la création des utilisateurs. Si cette performance est encourageante et s’avère la meilleure disponible toute implémentation de serveur confondue, il y a tout de même une consommation en mémoire importante et des points de synchronisation bloquants. Pour le test via Mina la solution par défaut, les tests de charge supportaient mal l’augmentation du nombre d’injecteurs qui cause une cascade de Timeout. D’autre part alors que Jetty se limite à 80 Threads, avec son implémentation Mina, Restlet crée rapidement des centaines de Threads et consomme beaucoup de mémoire. Retenez donc que l’implémentation Jetty NIO de Restlet est très performante et répondra à la majorité des besoins en informatique de gestion.

Tomcat 7

Le développement de ces POCs était une bonne occasion pour tester Tomcat 7 et les Servlets 3.0. Nous avons donc implémenté notre service avec des Servlets déclarées par annotation et utilisant l’exécution asynchrone pour maximiser le nombre de connexions concurrentes supportées.
Notez que l’utilisation des Servlets asynchrones a un impact immédiat sur les performances du serveur. La version asynchrone de la solution supportait effectivement plus de connexions avec des temps de réponse à peu près similaires. Le simple fait de passer la Servlet en traitement asynchrone permet donc de gagner en performance. Malheureusement en examinant les ThreadDump, il était clair que Tomcat avait un gros impact sur les temps de réponse (files d’attente et autre point de synchro était omni-présent).
Une dernière remarque, les tests ont été réalisés en utilisant deux connecteurs HTTP différents : le standard et le NIO. La solution NIO était bien plus performante en terme de parallélisme, mais le connecteur souffrait alors d’une fuite de mémoire conséquente. Le connecteur NIO de Tomcat aurait pu être une bonne option, mais nous ne voulions pas partir sur une solution reposant d’emblée sur des API instables comme c’était le cas du connecteur. A priori le bug a été corrigé dans les versions suivantes de Tomcat. Notez aussi que Tomcat a une empreinte mémoire importante et implique l’utilisation quasi permanente du GC car la mémoire utilisée dans la heap augmente régulièrement.

Grizzly

Pour mémoire, Grizzly est l’API réseaux utilisée par GlassFish. La librairie fournie un serveur de Servlet et un framework de traitement réseau NIO, “haute performance”. Tant qu’à faire, c’est à la partie framework NIO que nous nous sommes intéressés. Pour créer le serveur, il suffit d’utiliser HttpServer.createSimpleServer() auquel on ajoute ensuite des HttpRequestProcessor mappés par URL. Bien que très mal documentée, l’API est simple à mettre en place. Le problème vient plutôt du fine tuning car il est facile de changer le port d’écoute et d’activer le monitoring JMX, par contre la gestion des ThreadsPool s’avère bien plus complexe. Il n’existe pas dans Grizzly un moyen simple de spécifier son ExecutorService. Sur le scénario simple d’injection des utilisateurs, Grizzly crée rapidement plusieurs centaines de Threads et souffre de nombreux points de synchronisation. N’ayant pas beaucoup de temps à consommer dans cette phase de POC, nous avons rapidement éliminés Grizzly qui nécessitait d’emblé des optimisations et ne répondait pas aux besoins directement sorti de sa boite. En tests nous avons atteint une moyenne de 1500 req/s pour l’injection de 100k joueur dans une simple HashMap. Notez tout de même que Grizzly supporte différentes stratégies pour gérer les IO (http://grizzly.java.net/nonav/docs/docbkx2.0/html/iostrategies.html), par défaut il applique le WorkerThread qui consiste à déléguer le traitement des IO à un worker séparé. Nous n’avons pas testé d’autres stratégies que celle par défaut; cela aurait nécessité plus de temps que nous ne souhaitions en allouer au POC. En résumé, les tests sur grizzly se sont avérés décevants; avec plus de temps nous aurions sûrement amélioré ces performances.

Deft

Deft est une implémentation Java s’inspirant de Tornado, le serveur HTTP de facebook en python. Son principe est de créer une boucle infinie unique exécutant l’ensemble des évènements remontés par le Selector dans le même thread. Comme dans NodeJS, ce système permet de réaliser les traitements de façon évènementiel sans se soucier de la concurrence. Avec quelques tests sur un seul Thread, nous avons constaté des performances impressionnantes. En temps de réponse, en nombre de requêtes concurrentes, comme en consommation mémoire le serveur dépasse l’ensemble de ses concurrents sans aucune optimisation. Il y avait toutefois quelques bugs rédhibitoires dans l’API causant des erreurs graves à l’exécution de certains tests de charge. Le code étant simple, Séven a réalisé des corrections de bugs et implémenté un mode multi-thread permettant de lancer plusieurs boucles infinies pour tirer au mieux parti des CPU multi-coeurs. Sur le test d’injection de 100k joueurs, nous avons atteint entre 10 et 11k req/s pour une moyenne de 6ms de temps de réponse. Pour Deft, nous avons donc fait exception à la règle du temps consommé, n’étant jamais à l’abri d’une bonne surprise cela pouvait valoir le coups. Au final, l’API étant encore un peu trop instable et manquant de raffinement, comme la gestion des cookies ou le support de la compression gzip, ou encore une solution clé en main de longpolling, nous avons abandonné ce POC pourtant prometteur. Notez que, depuis la fin du challenge, le projet est rentré en incubation chez Apache avec pour but de fournir un serveur Java haute performance non J2EE. L’histoire continue pour Séven qui a rejoint l’équipe des commiters de ce nouveau projet Apache.

Netty

Netty est le framework NIO de JBoss, il permet de créer rapidement un serveur HTTP. Netty utilise deux ThreadPool, l’un pour écouter et accepter les connexions entrantes et l’autre pour traiter les échanges de données sur socket établies (Boss / Worker). Il définit ensuite une liste de Handler permettant de traiter les messages lus et d’écrire une réponse. Les handlers se comportent comme des filtres passant un événement portant un message, ils sont invoqués dans le sens de la lecture puis dans le sens de l’écriture vers le SocketChannel. La création d’un serveur HTTP nécessite donc de configurer les décodeurs dans le bon ordre mais l’exemple fournit dans la documentation permet de mettre le tout en œuvre en quelques minutes. Pour les habitués des documentations Jboss, notez que celle de Netty est riche et lisible : un bel effort pour ces experts du labyrinthe. Netty a l’avantage de supporter nativement le long-polling et de parfaitement gérer les envois de réponse en masse sur les sockets client. Sur le test d’injection des 100k utilisateurs, nous avons atteint les 9k req/s pour des temps de réponses de 6ms en moyenne. Pendant le test, Netty alloue un peu de mémoire supplémentaire mais se stabilise rapidement sans avoir d’activité GC. Comme vous pouvez le constater, cette solution supporte une charge légèrement inférieure mais apporte une stabilité accrue par rapport à Deft et surtout bénéficie d’optimisation pour le long-polling. La seule optimisation dont nous avons eu besoin par rapport au code de démonstration, fût l’utilisation d’un MemoryAwareThreadPool en lieu et place du CachedThreadPool qui causait un goulet d’étranglement. C’est donc la maturité de l’API, la simplicité d’usage et la performance de la solution qui ont fait la différence au final sur notre choix.

Conclusion

Pour conclure, ce tour d’horizon nous a permis finalement de découvrir qu’avec un peu d’optimisation, il est facile de faire des serveurs de hautes performance en reposant sur nos bons vieux serveurs J2EE comme Tomcat et Jetty. Les solutions NIO font surtout la différence sur l’application du long-polling, et les réponses groupées. Ainsi que sur la consommation mémoire et le nombre de Thread utilisés favorisant ainsi l’économie des FullGC et plus globalement du temps de traitement du garbage collector. NIO prend tout son sens pour le messaging et les serveurs de type événementiels. Parmi les API NIO non couvertes par nos tests, notez aussi l’existence de Simple : un serveur web prometteur permettant d’héberger des application Jersey en JAX-RS et intégré dans Restlet.
Vous trouverez les sources des pocs sur le GitHub de Xebia: https://github.com/xebia-france/NIO

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)

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

• Java EE 6, Glassfish v3 et NetBeans 6.8 dans les bacs
• Terracota et Quartz : un premier produit disponible.

RIA

• GWT 2.0 est (enfin) là !
• Sortie de la release de FlexPMD 1.0

Le coin de la technique

• Le projet Lambda apparaît au sein d’OpenJDK
• Nouvelle version du meilleur IDE Java du monde…
• 10 ans d’attente et ECMAScript 5
• Nouvelle Milestone d’Eclipse Helios
• Spring Surf – le studio de composition de pages pour Spring MVC

Actualité éditeurs / SSII

Java EE 6, Glassfish v3 et NetBeans 6.8 dans les bacs

C’est la fin de longs mois d’attente, Sun nous livre finalement sa version 6 de la plateforme Java EE dont nous parlons depuis déjà longtemps sur le blog. Comme promis, c’est GlassFish v3 qui sert d’implémentation de référence à JavaEE 6. Le tout est fourni prêt à l’emploi : le SDK, l’implémentation serveur et l’IDE compatible. Vous pouvez donc d’ores et déjà essayer les EJB lite, les Servlet 3.0, la validation de Bean, l’injection de dépendance et bien sûr, la toute nouvelle JSF 2 « tant attendue ».
Voilà un beau cadeau de Noël que Sun nous offre, d’autant que la sortie de GlassFish v3 s’accompagne des plugins adéquats pour Eclipse et IntelliJ. Nous souhaitons longue vie et grand succès à cette nouvelle plateforme JavaEE.
Pour plus d’information sur le sujet:

• JavaEE6 à Devoxx
• La news sur le site de Sun
• Inteview de Roberto Chinnici sur InfoQ
• L’annonce sur The Server Side

Terracota et Quartz : un premier produit disponible.

Un peu moins d’un mois après le rachat de Quartz par Terracota, l’éditeur met en application son acquisition, en proposant Terracotta Quartz EX, un Job Store pour Quartz. Cette nouveauté permet de développer une plate forme de gestion de charge et de distribution des traitements basée sur une gestion des jobs en mémoire.
Pour ceux qui utilisaient Quartz de manière non clusterisée, une nouvelle version de Quartz permet d’utiliser une instance de serveur Terracota comme JobStore. Cela procure, automatiquement, à la fois une solution de persistance et de haute disponibilité pour la programmation des jobs. Cette implémentation repose sur le lock manager et la plate forme haute-dispo de Terracotta (et ne nécessite donc pas de base de données).
Pour ceux qui utilisaient déjà Quartz de manière clusterisée, à l’aide d’une base de données centrale, le nouveau Terracotta Job Store permet de continuer à utiliser le mode clusterisé, sans l’overhead dû à la base de données.

A n’en pas douter, comme pour EHCache, aquis il y a quelques temps déjà, Terracotta va rapidement proposer de nouvelles applications permettant de profiter au mieux des interactions possibles entre un scheduler et une plate-forme clusterisée.

Au passage, Quartz a subi un lifting afin que le framework respecte au mieux les normes Maven et s’intègre plus facile à Hudson.

Via infoQ

RIA

GWT 2.0 est (enfin) là !

L’une des sensations de la semaine dernière n’est autre que la sortie en release finale de GWT en version 2.0, quelques mois seulement après la mise à jour 1.7 qui ne faisait que corriger GWT pour les navigateurs récents.

Nous avons déjà bien couvert le sujet dans nos précédentes revues de presse, que ce soit pour la Milestone 1 ou la Release Candidate 1. Rien de nouveau donc si vous nous suivez régulièrement. On retrouve ainsi le development mode, le code splitting, l’intégration HTMLUnit, l’UIBinder, le RunAsync et bien d’autres. Le détail complet des différentes nouveautés se trouve sur cette page.

A noter aussi l’arrivée avec GWT 2.0 de Speed Tracer, un outil vous permettant d’analyser votre application et ainsi de repérer d’éventuels problèmes de performances.
Le plugin Eclipse a lui aussi été mis à jour et possède désormais de nouvelles fonctionnalités spécifiques à GWT 2.0, comme le support d’UiBinder et de ClientBundle.

Concernant la migration, les retours (comme celui-ci) sont plutôt encourageants et laissent présager une migration sans trop de difficultés. Les gains en performance se situent, comme on pouvait s’y attendre, au niveau du development mode et de son plugin pour débuguer directement dans le navigateur (ce bon vieux Hosted Mode ne va décidément pas me manquer). Même au niveau des librairies tierces, il n’y a pas de grosses incompatibilités remontées par l’auteur.

La section téléchargement se trouve ici.

Sortie de la release de FlexPMD 1.0

Une bonne nouvelle cette semaine pour les développeurs Flex : la sortie de FlexPMD, FlexCPD et FlexMetrics en release pour contrôler votre code. Voyons un peu plus en détail ces différents outils :

• FlexPMD

Nous vous en parlions en septembre, FlexPMD fournit maintenant des fonctionnalités supplémentaires :

• invocation depuis Eclipse grâce à son plugin,
• depuis FlashDevelop ou TextMate sur Mac OS X.

Le rapport peut être généré en HTML ou XML. Son rapport au format XML est un standard pouvant être exploité par tout intépréteur PMD comme le plugin d’Hudson.

• FlexCPD (Copy & and Paste Detector)
• FlexCPD permet comme son nom l’indique de détecter les duplications de code. Basé sur le moteur de JavaCPD, il peut être appelé en ligne de commande par une tâche Ant ou avec Maven. Les résultats sont exploitables dans Hudson également grâce au plugin DRY.
• FlexMetrics
• FlexMetrics permet d’avoir des métriques sur votre code Flex. Comme FlexCPD, il peut être appelé en ligne de commande, avec Ant ou Maven. Pour interpréter les résultats de l’outil, il est possible d’utiliser le plugin JavaNCSS.

Des outils intéressants donc, pour ajouter vos projets Flex dans vos outils d’intégration continue.

Le coin de la technique

Le projet Lambda apparaît au sein d’OpenJDK

Mark Reinhold annonce la création d’un nouveau sous-projet au sein d’OpenJDK : le Projet Lambda. Son but est d’apporter une implémentation des closures pour le JDK 7. Dans la mesure où il est prévu que cette fonctionnalité soit implémentée dans un premier temps pour être spécifiée par la suite, il sera particulièrement intéressant de suivre l’évolution de ce projet dans les prochains mois afin de découvrir à quoi pourraient ressembler les closures dans la prochaine version de Java.

Un premier document de travail a été mis à disposition. Il présente de manière non formelle la proposition pour l’implémentation des closures qui est retenue pour le moment. Cette proposition se base sur les trois principales bases de travail qui s’étaient dégagées lors des débats précédents, à savoir la BGGA, la CICE et la FCM. Elle met en avant principalement :

• La syntaxe retenue pour la définition de fonctions anonymes qui se base sur le caractère #, ainsi #()(42) définit une fonction retournant toujours 42.
• La définition d’un type Java pour ces fonctions. Ainsi la fonction #()(42) prise en exemple précédemment a pour type #int().
• Les fonctions anonymes peuvent être converties automatiquement lorsqu’elle sont passées en argument d’une méthode attendant une instance d’une classe anonyme. En clair, il sera possible de créer une nouvelle thread avec new Thread(#() { ...some code... } ) plutôt que de fournir au constructeur une classe anonyme implémentant Runnable pour définir la méthode run(). Cette possibilité permettra donc aux closures d’être utilisées directement dans les APIs existantes !
• Dans certaines conditions, les closures sont à même d’utiliser les variables accessibles dans le contexte dans lequel elles sont définies.
• Le mot clé this peut être utilisé si la closure est déclarée depuis une méthode d’instance, il référence alors l’instance à laquelle est attachée la méthode concernée.

Enfin, pour faciliter les évolutions des APIs existantes que pourraient justifier ces nouvelles possibilités du langage, la notion de méthodes d’extensions est introduite. Il s’agit de permettre la définition de méthodes au sein des interfaces dont l’implémentation par défaut serait une méthode statique indiquée en argument.

Pour plus de détails sur cette proposition, n’hésitez pas à lire le document de travail, volontairement très didactique, du projet Lambda.

Nouvelle version du meilleur IDE Java du monde…

… en tout cas, c’est une des accroches d’IntelliJ IDEA
JetBrains continue donc sur sa lancée d’évolution majeure de ses produits.
Ainsi, après TeamCity 5.0, c’est au tour d’IntelliJ IDEA d’évoluer et de passer en version 9.

Les nouveautés sont très nombreuses. Les points importants retenus par JetBrains sont :

• la rapidité de l’IDE,
• l’amélioration de la lecture du code (meilleure coloration syntaxique…),
• meilleure UI, une structure de projet plus flexible,
• premier support Java 7 avec JSR308, support de JEE 6,
• meilleur support de Groovy,
• plugin de développement Android,
• support d’autres frameworks (Tapestry, GAE, GWT 1.7 et 2.0, Spring 3.0 et Spring Security 2.0 et 3.0),
• meilleur support de Maven,
• plusieurs nouvelles fonctionnalités pour le développement d’applications Flex. (Air, FlexUnit…).

Deux éditions nous sont proposées en téléchargement (avec différentes licences) :

• l’édition ultimate : complète, gratuite pour les licences Classroom et Open Source Project ;
• l’édition community : produit sous licence Apache 2.0 proposant en standard l’IDE pour Java et Groovy (et quelques plugins gratuits).

Et même quelques Friends of Eclipse vous encouragent à le télécharger Comme on dit : l’essayer, c’est l’adopter !

10 ans d’attente et ECMAScript 5

ECMAScript, langage de programmation de type script implémenté entre autres par Javascript et ActionScript, passe en version 5 (via InfoQ).
La version 4 ayant été abandonnée, il faut remonter à 1999 pour voir la dernière version d’ECMAScript et sa version 3… Ce fût long, mais au moins il est là !

Comme nous le rappelle Alex Blewitt, celle-ci essayera de s’imposer là où la version 4 (qui a d’ailleurs été abandonnée) a échoué, à savoir être pleinement supportée par les navigateurs actuels. En effet, nos sites web et nos outils évoluent mais pas la spécification ECMA. Côté application, c’est une nouvelle fois Google Wave (en GWT donc Javascript) qui est cité en exemple pour son côté collaboratif live. Et pour les outils, l’auteur cite Speed Tracer (inclus dans la release GWT 2.0) qui va nous permettre de détecter et de fixer certains problèmes de performances sur nos applications.

On notera la rétrocompatibilité avec les anciennes applications ECMAScript grâce au code suivant :

"use strict;"

Ce code indique au runtime ECMAScript qu’il faut être compatible avec la version 5 d’ECMAScript et ses différentes nouveautés. Il sera possible d’être compatible sur tout le document ou seulement sur une partie de code. Concernant les anciens runtimes, le strict sera compris mais ne changera pas leur comportement.

Concernant les nouveautés de la spécification, on retiendra :

• déclaration de variable obligatoire : terminé les i=3, il faudra obligatoirement passer par var i=3 ;
• eval devient un mot clé réservé ;
• l’opérateur with disparaît ;
• les fonctions et objets ne peuvent plus avoir des arguments/propriétés doubles avec le même nom ;
• nouvel objet JSON et mécanisme de parsing désormais standard ;
• méthode trim pour l’objet String ;
• méthodes indexOf, map, filter and reduce pour l’objet Array;
• nombreuses nouvelles méthodes sur Object dont seal (empêche l’ajout/la suppression de propriétés), freeze (propriétés read-only), keys (liste les propriétés de l’objet) ou getPrototypeof (prototype de l’objet).

Beaucoup de bonnes nouvelles pour les développeurs donc. La rétrocompatibilité permettra une mise en place progressive sur notre code, soit par bloc soit directement sur toute la page. Côté API, on avait déjà l’habitude d’utiliser ces fonctions par l’intermédiaire de librairies comme jQuery mais cette standardisation est la bienvenue.

Nouvelle Milestone d’Eclipse Helios

Eclipse 3.6, nom de code Helios, vient de sortir en version Milestone 4. De nouvelles fonctionnalités sont apparues avec ce build, comme :

• la possibilité d’éditer plusieurs quick fix en même temps
• les « virtual folders » qui permettent de créer des regroupements de fichiers au niveau du projet pour une navigation plus facile
• amélioration du plugin JUnit

Pour plus de détails, voici la liste des améliorations et l’annonce officielle d’EclipseSource.

Spring Surf – le studio de composition de pages pour Spring MVC

Spring s’intéresse à présent à la gestion documentaire, grâce à une collaboration avec Alfresco, le système de GED Open Source Java, qui a démarré le projet Surf. A l’origine, l’objectif était de proposer aux utilisateurs d’Alfresco une plateforme pour développer leurs propres applications connectées à la GED.

Pour profiter des facilités de développement d’applications que propose Spring avec Spring Roo et Spring Tool Suite, Alfresco commence à migrer son projet Surf dans l’incubator Spring Extension.

Pour le moment, les principales informations se trouvent sur le wiki d’Alfresco, la page d’accueil de Spring Surf étant encore très succincte.

Pour démarrer, seuls l’addon Spring Roo et un QuickStart sont disponibles chez Spring (pas encore de tutorial). Et pour mieux connaitre ce que deviendra cette extension, l’application Alfresco Share, basée sur la plateforme Surf donne un bon nombre de pistes comme :

• Création d’applications uniquement par scripting (Freemarker, Groovy, PHP, JavaScript)
• Ajout de pages à une application basée sur le framework Spring MVC
• Développement avec un modèle extensible de templates, composants, styles, etc.

Premier sujet abordé, le futur de Java, à savoir JEE 6 et son implémentation de référence, Glassfish V3.

Dès l’opening keynote (par ailleurs relativement décevant étant donné l’aura qui l’entourait), James Gosling, le papa de Java, plante le décor : pour Java, « we’re we heading », c’est JEE6 (et ses profils) et Glassfish V3, l’implémentation de référence.
On a même droit dès cet opening keynote à une démo des key features de Glassfish 3 (démo qui sera resservie dans la session dédiée au serveur d’application) : configuration des webapp par annotations, déploiement (exploded) à chaud, préservation des sessions, simplicité d’utilisation des EJB 3.1.

D’ailleurs, Roberto Chinnici insistera, dans sa présentation des nouveautés de JEE 6, sur ses JSR « coup de coeur », à savoir Servlet 3.0 (en particulier les Servlets asynchrones), JAX RS (qui abstrait les API HTTP bas niveau et facilite les développements REST), BeanValidation (mieux vaut tard que jamais), EJB 3.1 (et les nombreuses annotations qui vont faciliter leur utilisation : @Singleton, @Asynchronous, @Startup, @Locka …).
Faute de temps, il est passé rapidement sur d’autres JSR qui devraient « révolutionner » les développements : JPA 2.0, scopes JNDI multiples, Web Profile …
Cependant, deux informations que nous attendions ont été évoquées au détour d’une phrase : la JSR 299 (ex Web Beans) serait en cours d’adoption (aucune allusion à la JSR @Inject) et la date de final release de J2EE 6 est toujours septembre 2009.

On n’insistera pas sur une très bonne présentation GlassFish, qui a été malheureusement fortement déflorée par l’opening keynote. On notera cependant le fort accent porté sur la modularité OSGi du serveur d’application de Sun.

Enfin, James Gosling a fait d’autres annonces plus étonnantes : NetBeans serait le meilleur IDE pour développer en Java (ce dont il va falloir nous convaincre, même si la version 6.7 apporte des nouveautés intéressantes), et son intégration au projet Kenaï devrait faciliter le travail collaboratif (notion de developers cloud).
Il a aussi abordé dans le désordre les performances de Java comparées à C/C++ et même Fortran la voiture électrique de Neil Young pilotée par des smart cards Java, les améliorations continues de JSE 6, et enfin la création d’UI avec JavaFX.

Bref, de nombreux sujets dont nous aurons l’occasion de reparler ces deux prochains jours.

Le rapprochement de ces deux poids lourds du monde J2EE risque d’entrainer de profonds changements dans nos écosystèmes dans les mois à venir.

Les raisons officielles du rachat

Une stratégie à définir

• Quelle gouvernance pour Java ?
• JRockit, une nouvelle JVM standard ?
• Quel avenir pour MySql ?
• Glassfish peut il encore exister ?
• Netbeans, (enfin) la mort de JDeveloper ?
• Poursuivre dans la voie JavaFx ?

De grandes dates pour voir la situation se décanter

Les raisons officielles du rachat

Larry Ellison, le CEO d’Oracle, invoque, dans son communiqué officiel, la volonté d’Oracle de mettre à disposition de ses clients une offre complète, du disque dur au logiciel.
Le rachat de Sun permet à Oracle de s’approprier la dimension hardware, mais aussi le système d’exploitation Solaris (support majoritaire de la base de données Oracle). La volonté affichée est d’exploiter et de tuner au mieux l’alliance Hardware / OS / SGDB / Serveur d’Applications, comme peut d’ailleurs le proposer d’ores et déjà IBM avec sa stack sur zOs.
Pour le côté hardware, on notera que Sun possède actuellement une lucrative activité stockage qui complètera avantageusement la base de données pour proposer aux clients d’Oracle une offre intégrée.

L’autre versant de ce rachat est bien sûr l’acquisition de Java. Après le rachat de BEA, c’est un énorme pas qu’Oracle a franchi pour s’ancrer définitivement dans l’informatique d’entreprise.

Une stratégie à définir

Quelle gouvernance pour Java ?

Historiquement, Oracle a réussi là où Sun a toujours dû batailler : monétiser ses middlewares. Le grand défi qui va se présenter à Oracle pourrait se résumer à la question suivante : comment faire des profits avec Java sans en dénaturer complètement l’esprit communautaire ?
Comment va évoluer la gouvernance du JCP ? La firme va t’elle poursuivre le mouvement insufflé depuis quelques mois qui tendait à ouvrir le JCP à un large nombre de contributeurs / projets ? Cette ouverture, souhaitée par de nombreux acteurs du monde J2EE, devait permettre l’émergence de ‘specs leaders’ indépendants des gros éditeurs (BEA, Oracle, IBM).
C’est peut être l’avenir même de Java 7 qui est en jeu ici.

JRockit, une nouvelle JVM standard ?

Pour un développeur Java, le choix d’une JVM est loin d’être anodin, et il est courant de se retrouver avec 2 ou 3 JVMs sur sa machine, en fonction du serveur J2EE cible.
Jusqu’à maintenant, le choix était relativement vite fait : la JVM de Sun pour lancer son environnement de développements, et la JVM JRockit ou IBM en fonction de la cible.
Avec ce rachat, Oracle a maintenant à maintenir 2 JVMs : celle de Sun, qui fait office de JVM par défaut pour la majorité des environnements Java, et JRockit.

Quel avenir pour MySql ?

Sun avait racheté MySql pour pouvoir offrir une alternative crédible au SGDB d’Oracle.
Depuis, Sun avait lutté pour faire de Mysql un produit commercial profitable. Ce nouveau rachat signifie-t-il la mort du produit open source ?
Pas nécessairement, Oracle ayant déjà fait par le passé des mouvements destinés à contrer la montée de ce concurrent, avec les rachats de SleepyCat et InnoDb. Il avait même été question de rachat pur et simple, à une époque pas si lointaine.
Maintenant que les 2 produits se retrouvent dans le même portefeuille, la question de leurs développements respectifs se pose légitimement.

Glassfish peut il encore exister ?

Le rachat de BEA il y a quelques mois avait offert à Oracle un serveur d’application J2EE digne de ce nom. Et le serveur J2EE ‘maison’ d’Oracle avait rapidement disparu du catalogue de l’éditeur.
Que va devenir Glassfish ? Le ‘serveur open source qui monte’ peut il exister à coté du mastodonte Weblogic ?
Sans vouloir jouer les oiseaux de mauvais augure, on peut rappeler la déconfiture de Géronimo après le rachat de Gluecode par IBM en 2005.

Netbeans, (enfin) la mort de JDeveloper ?

Soyons francs, à moins d’avoir été ‘élevé’ avec, il est difficile de trouver des qualités à l’environnement de développement labellisé Oracle.
Il a pourtant survécu au rachat de BEA, même si les développeurs Weblogic lui préfèrent toujours le plugin Eclipse.
Oracle a déjà planté un clou dans le cercueil de JDeveloper, en faisant un pas vers les développeurs Eclipse, avec Oracle 11G Enterprise Pack for Eclipse
Survivra-t-il à la concurrence de Netbeans, qui, même s’il est toujours en retrait par rapport à Eclipse et Intellij IDEA, bénéficie d’une communauté bien plus large ?

Poursuivre dans la voie JavaFx ?

Alors que certaines voix s’élevaient chez Sun pour réclamer l’abandon de JavaFx, Oracle continuera-t-il à investir sur cette technologie ‘à la traine’, qui ne sera probablement pas ‘profitable’ à court terme ?

De grandes dates pour voir la situation se décanter

Alors, évolution (logique) ou révolution ?
La communauté devrait être assez rapidement fixée, avec la pléthore de sorties au programme ces prochains mois : Java7, JEE 6, Glassfish 3, JavaFx 1.2 … Ces milestones importantes devraient permettre d’y voir plus clair dans la stratégie qu’Oracle va adopter vis à vis de son nouveau protégé.
Rappelons seulement que le rachat de BEA par Oracle avait provoqué un émoi similaire, et que finalement cette absorption s’est faite en douceur, en appliquant des décisions pleines de bon sens.

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

• Glassfish v2.1 et Glassfish Portfolio
• GlassFish Mobility Platform 1.1

RIA

• Mozilla Labs sort Bespin, un IDE web
• Blaze Data Service ou LiveCycle Data Service

Le coin de la technique

• Sonar en version 1.6
• Groovy 1.6, tout pareil, mais en mieux
• AribaWeb passe en OpenSource
• Maven 2.0.10

Actualité éditeurs / SSII

Glassfish v2.1 et Glassfish Portfolio

La version 2.1 du serveur d’applications GlassFish de Sun est sortie fin janvier. Cette nouvelle release apporte peu de grosses nouveautés. Comme le souligne Alexis Moussine-Pouchkine, la sortie de SailFin v1 a motivé la v2.1 de Glassfish. SailFin repose sur des servlets SIP et le protocole SIP (Session Initiation Protocol). Ce protocole est notamment utilisé pour réaliser de la VoIP ou de la messagerie instantanée.

Outre la correction des quelques 500 bugs, cette nouvelle version apporte avec elle son lot de nouveautés intéressantes :

• un nouveau service de Shoal Group Management (GMS), qui permet à une JVM d’appartenir à un cluster et d’être notifiée lors d’événements sur celui-ci ;
• une implémentation plus robuste des mécanismes de réplication de sessions ;
• l’implémentation de Glassfish Enterprise Manager. Il s’agit en fait de la grosse nouveauté de cette version, cette plateforme offre trois nouveaux outils pour gérer GlassFish en production :
  • un Support SNMP ;
  • Performance Advisor, qui permet d’ajuster et de monitorer à chaud la configuration en fonction de la charge et des performances de l’application en cours d’exécution ;
  • Performance Monitor, gestion de la performance basée sur VisualVM.

Avec cette nouvelle version, Sun se lance donc dans une opération séduction destinée aux exploitants. Sera-t-elle suffisante pour transformer le chouchou des développeurs en machine de guerre prête à concurrencer les plus gros en production ? Quoi qu’il en soit, une marche de plus a été franchie.

D’après la roadmap de GlassFish, cette mise à jour sera la dernière évolution majeure de la branche v2, actuellement utilisée sur les serveurs de production.
GlassFish v3, dont la version Prelude est qualifiée de « production-ready » par Sun, reste le véritable avenir de GlassFish. Son architecture modulaire et la possibilité de redéploiement rapide qu’il offre lui permettront de rivaliser avec les serveurs d’applications de nouvelle génération tels que JBoss AS 5.0.

D’autre part, Sun a annoncé le 10 février dernier la sortie de GlassFish Portfolio. Il s’agit d’une plateforme applicative unifiée regroupant 4 produits déjà existants : Enterprise Server, ESB, Web Stack et Web Space Server.
Cette nouvelle plateforme n’apporte pas de réelles nouveautés et peut être considérée comme un repackaging marketing. Alexis Moussine-Pouchkine est plus mitigé sur la question.

GlassFish Mobility Platform 1.1

Sun annonce la disponibilité de GlassFish Mobility Platform 1.1 qui constitue une mise à jour de son produit anciennement nommé Mobile Enterprise Platform 1.0 qui avait été introduit en Juillet 2008. Cette plate-forme a pour but de faciliter le développement d’applications mobiles communiquant avec un back-end Java.

Dans cette optique, la première version offrait déjà la possibilité de synchroniser les données d’un appareil mobile avec celle d’un serveur via l’utilisation du protocole SyncML.

Cette nouvelle version offre maintenant également le support de JAX-RS, apporté par un connecteur coté serveur, et par JerseyME coté client mobile CLDC.

Parmi les possibilités de middleware mobile, GlassFish Mobility Platform représente ainsi une alternative intéressante à l’utilisation d’un serveur d’application JEE classique invoqué par Web Services SOAP via la JSR-172 (J2ME Web Services Specification) qui est dorénavant implémentée dans de nombreux appareils J2ME.

RIA

Mozilla Labs sort Bespin, un IDE web

Mi-Octobre 2008, Dion Almaer et Ben Galbraith, les fondateurs du site Ajaxian, rejoignaient Mozilla, pour travailler sur des outils pour le développeur (l’employeur précédent de Dion Almaer était… Google).
Dion et Ben ont annoncé la semaine dernière le premier fruit de leurs travaux chez Mozilla Labs : Bespin, un éditeur de code web en ligne, avec le cahier des charges suivant :

• accessible de n’importe où
• facile à utiliser
• rapide
• collaboration en temps réel
• ligne de commande à la vi intégrée
• extensible

Il sera intéressant de voir le résultat de cette expérimentation : un logiciel qui a naturellement sa place sur le bureau peut-il être porté sur le web?
La première version mise en ligne est une « tech preview », en version 0.1. Elle ne supporte pour le moment que quelques fonctionnalités d’édition de base (coloration syntaxique ou prévisualisation du rendu des pages dans le navigateur par exemple), et ne fonctionne pour l’instant que sur Firefox 3 et une version nightly de WebKit.
Parmi les fonctionnalités attendues, citons en particulier la « collaboration en temps réel ». Cette fonctionnalité est soit absente de nos IDEs favoris, soit rarement utilisée. Elle est pourtant séduisante ! Prenons pour exemple l’éditeur SubEthaEdit, dont la fonction de collaboration inspire Mozilla Labs pour Bespin.

Blaze Data Service ou LiveCycle Data Service

Dans cet article, Ryan Knight clarifie les différentes offres d’Adobe concernant les data services. Comme nous l’avions expliqué dans cet article sur BlazeDS, ce dernier est OpenSource alors que le LiveCycle Data Services (LCDS) est propriétaire. Ces deux produits permettent notamment la communication entre un client Flex et un serveur d’applications Java par l’intermédiaire d’une Servlet (Message Broker), mais aussi grâce au protocole AMF.

Il existe cinq versions différentes:

• Blaze Data Services
• LiveCycle Data Services Community Edition
• LiveCycle Data Services Single-CPU Licence
• LiveCycle Data Services
• LiveCycle Data Services Entreprise Suite

Afin d’effectuer un choix parmi ces offres, les questions suivantes se posent:

• Avez-vous besoin de support ?
• Avez-vous besoin d’un service de gestion des données ?
• L’application devra-t-elle supporter beaucoup de connections ?
• De quels channels (AMF, RTMP) avez-vous besoin ?

Par la suite, le NIO (Java New Input/Output) endpoint est décrit. Le NIO, basé sur une socket, permet de gérer un grand nombre de connexions avec moins de threads. Néanmoins, comparé à la Servlet MessageBroker, ce dernier est moins rapide à mettre en place (mise en place d’une meilleure authentification…). A l’origine NIO a été créé pour pallier les problèmes de performances, mais ces derniers sont remis en questions, car dorénavant sous le JDK 1.6 par exemple, la JVM possède une meilleure gestion des threads.

Enfin pour terminer, le choix parmi les offres proposées par Adobe, dépend essentiellement des besoins et de la criticité (besoin de support éventuel) du projet à mettre en place. De manière générale, l’utilisation de la Servlet MessageBroker et du protocole AMF permettent de gérer bon nombre de situations.

Le coin de la technique

Sonar en version 1.6

Décidément, l’équipe de Sonar Source est prolifique en versions et en nouvelles fonctionnalités pour sa plateforme d’observation des indicateurs qualité : Sonar.
Nous annoncions sur ce blog à la fin de l’année dernière la sortie de la version 1.5 et à peine deux mois après, c’est la version 1.6 qui est annoncée en images sur le blog lié à l’outil.
A noter donc, 3 features liées à la gestion des règles de qualité à observer sur les projets :

• La possibilité de lier un ruleset qualité différent selon les projets (fonctionnalité qui permet par exemple, d’adapter le niveau d’exigence en matière de qualité selon l’expérience de l’équipe de développement ou l’existant du projet)
• Des alertes peuvent désormais être paramétrées sur l’apparition de règles spécifiques ou selon des seuils à ne pas dépasser. Sur le dashboard, l’indicateur du projet dépassant ces seuils apparaitra surligné. Il est aussi possible de lier les projets à un flux RSS.
• Les rulesets sont maintenant historisés et peuvent être rechargés par projet.

Sonar corrige et agrémente ses nouvelles versions en dépilant les fonctionnalités présentées dans sa roadmap (la version 1.7 est annoncée en Mars 2009).
Mais l’outil propose déjà un panel riche d’outils qui agrègent et présentent des données qualité à destination, aussi bien des directeurs de projet, pour une vision haut niveau, que des développeurs souhaitant une remontée continue d’informations qualitatives sur leur travail.

Groovy 1.6, tout pareil, mais en mieux

Guillaume Laforge a annoncé cette semaine sur son blog la sortie de Groovy 1.6. Notons qu’il s’agit de la première grosse release de Groovy depuis l’acquisition de G2One par SpringSource en Novembre dernier.

Lors de la soirée Groovy du Paris JUG de Septembre, Guillaume nous parlait avec enthousiasme de cette version 1.6 (qui était déjà disponible en bêta) : elle devait permettre à Groovy de devenir le langage de scripting pour JVM le plus rapide du marché. C’est d’ailleurs cette course à la performance qui a certainement occupé le plus les équipes de développement ces derniers mois. On se souvient de l’amélioration notable des temps de compilation (x3) à l’arrivée de Groovy 1.5.5. Cette fois-ci, c’est le bytecode généré qui a été mis au régime et qui permet a Groovy 1.6 d’améliorer grandement ses performances.
Les chiffres annoncés lors de la sortie de la version bêta permettaient d’espérer une amélioration des performances spectaculaire. Ils annonçaient alors entre 150% et 400% d’amélioration… sur certains tests bien spécifiques. Alors, qu’en est-il réellement ? Difficile à dire pour le moment, aucun test de performance n’ayant encore été publié. Si Guillaume Laforge lit ces lignes et qu’il peut nous en dire un peu plus, qu’il n’hésite pas !

L’autre nouveauté intéressante ne concerne pas directement les développeurs : la transformation d’AST. Un AST (Abstract Syntax Tree) correspond à la représentation mémoire du code source telle que le voit le compilateur avant que le bytecode ne soit généré. Il s’agit donc d’une fonctionnalité avancée ouvrant la porte à certaines solutions intéressantes. Effectuer des transformations sur l’AST revient à modifier, avant la compilation, le code de votre application : soit pour l’optimiser (suppression de code inutile, des variables non utilisées, …), soit pour en modifier le comportement.
Il devient donc aisé, pour le compilateur, d’ajouter un traitement particulier avant la compilation en fonction du code source. Vous utilisiez le runtime weaving de Spring, le load time weaver des agents java, Grrovy vous propose le compilation time weaving.
Concrètement, le compilateur pourra directement détecter la présence d’annotations (ou autres) dans votre code et effectuer ses modifications avant même que le code source ne soit compilé. Ainsi, la transformation d’AST facilitera probablement grandement l’intégration de nouveaux bultins type Spring ou Seam et permettra de ce fait la gestion transparente d’annotations du type @Singleton, @Immutable, @Lazy, @Delegate ou @Binding.

D’autre part, voici en vrac la liste des nouveautés plus terre-à-terre apportées par cette nouvelle version (nous n’en détaillerons pas les cas d’utilisation ici) :

• Affectations multiples : def (a,b) = [1,2]
• Retours optionnels dans les blocks if/else et try/catch
• Améliorations des builders Swing
• Builtin permettant l’exécution de scripts au sens JSR-223 (si si, du script dans un language de scripting)
• L’intégration d’un builder JMX

AribaWeb passe en OpenSource

Après quatre versions de sa stack de développement d’applications web, la société Ariba Inc. a décidé de la passer en OpenSource. La version 5, actuellement en Release Candidate 1 vient d’être publiée en même temps chez SourceForge et Google Code. Le projet AribaWeb passe donc en licence Apache Version 2.0 et l’équipe de développement nous gratifie pour sa sortie d’un joli site de promotion avec tutoriaux et screencasts de démonstration.

Relativement peu connu, du fait de son utilisation propriétaire dans ses premières versions, AribaWeb promet une productivité sans commune mesure avec les autres stacks de développement web : à application équivalente, 100 fois moins de code à écrire qu’avec Rails ! Ils annoncent également avoir besoin de 10 fois moins de code qu’avec GWT pour développer une application GoogleMaps. La fonction LiveEdit, permettant de replacer ses composants UI et éditer les règles d’accès aux écrans directement dans un navigateur, vaut le détour. Des plugins Eclipse et IntelliJ IDEA sont livrés en standard pour permettre de tester rapidement dans un environnement familier.

Souhaitons une longue vie à ce nouveau projet, dont le passage en OpenSource a été initié pour « offrir un retour à la communauté qui a rendu son développement possible ».

Maven 2.0.10

Dix mois après la sortie de la version 2.0.9, la version 2.0.10 de Maven vient d’être mise en ligne.
Au programme, essentiellement des corrections d’anomalies. De nouvelles fonctionnalités devaient au départ être intégrées dans cette version, mais elles ont été reportées dans la branche 2.1.
Vous trouverez plus d’informations sur la sortie de la nouvelle version sur le blog de Sonatype (la société de Jason van Zyl, le père de Maven), ils y donnent en particulier un rapide tour d’horizon des différentes branches actuelles (2.0.x, 2.1.x et 3.0.x).
Si vous utilisez Maven 2.0.9 et que vous n’êtes pas affectés par une des anomalies corrigées, la migration n’est pas bien urgente…

Actualité éditeurs / SSII

• Sun supprime 5.000 à 6.000 emplois dans la continuité de sa mutation en un acteur Open Source
• SpringSource dévoile sa roadmap

RIA

• Le framework préféré des développeurs Flex
• Adobe lance Cocomo

Le coin de la technique

• Essayez le nouvel algorithme Garbage First
• Gestion des documents Office 2007
• Hyperic v4.0 : le monitoring d’applications Java passe par JMX
• Sortie de Grails 1.0.4

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

• Open Source eXchange : comptes-rendus des participants
• L’Aquarium à Paris le 12 décembre : inscriptions ouvertes

Actualité éditeurs / SSII

Sun supprime 5.000 à 6.000 emplois dans la continuité de sa mutation en un acteur Open Source

Sun annonce un plan de restructuration assez conséquent puisqu’il touchera plus de 15% de ses effectifs.

Triste nouvelle. La nécessaire mutation de ce fleuron de l’informatique des années 90, tiraillé entre son activité hardware en déclin (traditionnellement haut de gamme, mais malheureusement à contre-courant d’investissements en berne en période de crise) et son activité software (en recherche d’un second souffle – le patron de la branche logicielle, Steve Green est parti Vendredi dernier), est en marche depuis plusieurs années et n’est pas une surprise.

L’annonce faite sur le site Corporate de Sun est claire : Software et Open Source !
Espérons pour Sun que les récentes (pour certaines judicieuses) et coûteuses acquisitions porteront leurs fruits.

Si nous osions, nous dirions que, toute activité hardware mise à part, Sun ressemble de plus en plus à des pures players de l’Open Source au même titre que Redhat par exemple.

Il n’est en effet pas surprenant que Sun ait choisi cette voie. Lors de la conférence de Malaga des partenaires de Redhat, à laquelle Xebia était invitée, James Whitehust nous époustouflait en nous annonçant que sa marge et sa croissance étaient parmi les plus élevées de l’industrie logicielle (information vérifiée et qui s’avère exacte).

Bonne continuation à Sun dans cette voie, elle est légitime. Et bonne chance avec la prometteuse gamme Sun Storage 7000, un condensé de hardware, d’open source et d’innovation dans le lignée du nouveau modèle Sun !

SpringSource dévoile sa roadmap

Vous avez probablement entendu parler des rencontres Spring qui se sont déroulées jeudi dernier. Nous ne résumerons pas ici le contenu de l’ensemble des conférences, d’autres blogs s’en sont déjà chargés avec brio (cf liens annexes). Si, dans l’ensemble, les conférences étaient plutôt réussies, nous avouons être un peu restés sur notre faim :

• Les discussions ont beaucoup tourné autour du rachat par SpringSource de G2One sans pour autant révéler clairement la place de Groovy et Grails dans la stack Spring. Elles ont tout de même permis de servir de point de départ à des discussions off bien plus intéressantes lors de la pause.
• Aucune explication sur les (petits) retards de la M1 de Spring 3.0, aucune référence à Spring JavaConfig ni à l’intégration des Servlet 3.0, pas de communication sur le contenu des M2 et M3, bref, rien de neuf depuis le billet que nous avons publié le mois dernier sur Spring 3.0.

Heureusement donc que ce rachat, annoncé en début de semaine, et la présence de speakers d’exceptions ont permis de pimenter cette demi-journée.

La partie la plus intéressante a été probablement celle de Peter Cooper Ellis nous présentant de la roadmap Spring dont voici les points à retenir :

• Concernant Spring 3.0 : le premier milestone doit sortir d’ici fin novembre. Il sera probablement suivi d’un M2 et d’un M3 avant l’arrivée d’une Release Candidate prévue en mars 2009. La sortie officielle devrait arriver en avril si tout se passe bien.
• Sortie de Spring Integration d’ici la fin de l’année.
• La version 1.2 de Spring DM devrait sortir durant le premier trimestre 2009 offrant le support au Configuration Admin service. Elle sera suivie peu de temps après par la version 2.0 qui implémentera l’OSGi Blueprint Service (RFC 124) partie d’OSGi R4.2. Spring DM 2.0 sera d’ailleurs probablement la reference implementation de ces spécifications. Sa date de sortie est prévue pour le second trimestre 2009.
• En parallèle à cela, deux nouvelles versions de Spring dmServer sont planifiées l’année prochaine. La première, dmServer Jersey, offrira, entre autres, une compatibilité Tomcat. Cette version devrait voir le jour au second trimestre 2009. L’autre version est prévue pour fin 2009 : dmServer Ockney. En voici quelques nouveautés : load balancer dynamique, enregistrement et exécution de scripts sur la console …
• Notons également au premier trimestre 2009 : une mise à jour de Spring IDE (2.5) et les versions 1.6 de Groovy et 1.1 de Grails, dont Guillaume Laforge vente les mérites depuis la soirée Groovy du Paris JUG.
• Mais c’est le second trimestre qui sera le plus chargé avec au programme : Spring Batch 2.0, Spring Security 2.5, Spring ROO et Spring Web. La version 2.0 de Spring Batch apportera une mise à jour importante de ce framework : passage à Java 5, configuration via annotations, on parle également d’une éventuelle intégration avec la stack apportée par G2One. Vous aurez également remarqué la présence d’un nouveau framework baptisé Spring ROO. Il s’agirait d’un framework RAD / DDD de génération de codes privilégiant les conventions à la configuration (tiens, tiens, ça nous rappelle quelque chose). Ici encore, aucune information n’est donnée quant à la place de ce framework vis-à-vis de Grails.

Notez que ce planning ne se veut ni complet ni définitif, certaines de ces dates seront très probablement amenées à évoluer.

Liens connexes :

• Consultez l’agenda de la demi-journée.
• Téléchargez-les slides des conférences.
• Remerciements post-conférences par Julien Dubois.
• Résumé de la demi-journée par Pierre Mage.
• Résumé de la demi-journée par Olivier Mallassi.
• Résumé de la demi-journée par Nicolas Martignole.
• Autres billets : Spring dmServer, le pari fou ?, Tuning Tomcat par Thomas Queste.

RIA

Le framework préféré des développeurs Flex

Rich Tetrola a lancé la semaine dernière un sondage sur le framework préféré des développeurs Flex. Et voici le résultat. PureMVC remporte le sondage à la surprise de l’auteur lui-même qui misait plutôt sur Cairngorm. Les candidats au titre de framework préféré des développeurs Flex étaient :

• Cairngorm : une micro architecture fournissant plusieurs motifs de conception (notamment le Modèle-Vue-Contrôleur).
• PureMVC : un framework permettant de concevoir des applications basées sur le motif de conception Modèle-Vue-Contrôleur.
• Mate : un framework qui gère les évènements dont voici une démonstration Hello World.
• Swiz : un framework facilitant le développement d’applications riches.
• EasyMVC : il permet également de concevoir des applications sur le motif de conception Modèle-Vue-Contrôleur.
• Ruboss : il facilite le développement d’application Flex/Rails.

Cairngorm, bien qu’il soit un produit d’Adobe Labs, n’a pas remporté le succès attendu à cause de sa complexité, c’est ce qui ressort des commentaires. Peut être est ce à cause de son « ModelLocator fourre tout ». Les résultats sont intéressants mais il ne faut pas les prendre au pied de la lettre. Tous ces frameworks ont pour but de mettre en place de bonnes pratiques dans le développement d’applications riches. Chacun dispose d’avantages et d’inconvénients à bien évaluer lorsqu’on veut choisir d’utiliser l’un de ces frameworks.

Adobe lance Cocomo

Avec cette première version bêta dans les labs, Adobe étoffe encore son offre RIA.
Cocomo est une plateforme Flex permettant au développeur d’ajouter des capacités « sociales » aux applications RIA. Cocomo mêle une partie cliente Flex et les infrastructures réseau mises à disposition par Adobe. En bref, il permet de facilement mettre en place des outils collaboratifs dans vos applications Flex. La version bêta propose déjà le support de :

• Conférences audio (par VoIP).
• Conférences vidéo (par Webcam).
• Chat texte.
• Echange de fichiers.
• Gestion des utilisateurs.
• Et d’autres choses à découvrir.

Pour plus d’informations rendez vous sur le site d’Adobe : Présentation de Cocomo.

Le coin de la technique

Essayez le nouvel algorithme Garbage First

Danny Coward, dont nous avons déjà parlé à plusieurs reprises, a publié cette semaine sur son blog un billet annonçant la disponibilité du nouvel algorithme pour le ramasse-miettes Java sur le dernier build du JDK 7 (bon courage pour l’installer …). Trois saisons ont passé depuis la publication sur notre blog d’un article présentant le fonctionnement de celui-ci. Son principe n’a pas changé, vous pouvez donc toujours vous y référer si le sujet vous intéresse : GC générationnels traditionnels (JDK 6) VS Garbage First (JDK 7).

À retenir sur ce nouvel algorithme, Garbage First (G1) :

• Il est destiné à remplacer le parrallel and concurrent mark and sweep.
• Il devrait être activé par défaut dès le JDK 7.
• Il propose un nouveau découpage du tas : la taille des zones mémoire se réduit, plus de zones sont créées en contrepartie.
• Il permet également d’exploiter les forces des architectures multicœurs.
• Il se veut plus prédictible et moins intrusif en offrant par exemple des garanties sur des temps de pauses.
• Il permet en moyenne d’obtenir un meilleur débit de nettoyage, tout en offrant une implémentation simple à comprendre.

Gestion des documents Office 2007

La société Aspose annonce la sortie d’une nouvelle version de son produit Aspose.Word permettant de gérer nos fichiers Word 2007, les fameux .docx de Microsoft Office 2007 (annonce relayée par The Server Side).

Cette 2.6.0 ajoute l’importante fonctionnalité de pouvoir charger un fichier Word existant, rendant possible l’édition de celui-ci. Un produit très complet donc, qui gère aussi les images, les zones de texte, les objets OLE et Active X et bien d’autres fonctionnalités de Microsoft Word.

A noter que la gestion des fichiers Excel 2007 (.xlsx) et PowerPoint 2007 (.pptx) est en très bonne voie chez Apache POI, le support du format OOXML étant déjà disponible dans POI en version 3.5 beta 3. Ce support est désormais une priorité pour le projet. Rappelons que depuis quelques mois Microsoft est partenaire du projet Apache POI et contribue ainsi à l’intégration de son format dans POI.

Hyperic v4.0 : le monitoring d’applications Java passe par JMX

Hyperic HQ, l’outil de supervision choisi par Iona (Fuse HQ), Redhat (JBoss Operations Network) et SpringSource (Application Management Suite), dévoile cette semaine sa version 4.0 dont une des nouveautés clefs est le nouveau JMX MBean Browser.

Nous retiendrons de cette annonce que JMX est la technologie incontournable pour superviser des applications Java. Le développement d’indicateurs en MBean JMX est aujourd’hui très facile pour les équipes applicatives avec des frameworks comme Spring JMX et la consultation de ces informations est banalisée avec l’incontournable Visual VM (cf Blog Xebia : Diagnostique d’une JVM à distance).

Ne pas s’intégrer facilement à JMX est aujourd’hui un très sévère handicap pour une solution de supervision d’applications Java.

Sortie de Grails 1.0.4

La sortie officielle de Grails 1.0.4 vient d’être annoncée par SpringSource. Pour ceux qui ne le connaissent pas, Grails est un framework orienté web écrit en Java et Groovy et placé sous licence Apache. Il s’inspire fortement du framework Rails (Ruby on Rails). Mais contrairement à Rails, Grails est ancré complètement dans l’univers Java, et repose sur des frameworks très connus comme Spring ou Hibernate.

Cette nouvelle version propose des nouvelles fonctionnalités pour une meilleure intégration avec Spring et Hibernate, un support des tags JSP dans GSP, de nouveaux plugins pour Java Content Repository (JCR API), Java Persistence API (JPA) et l’api Portlet.

L’année prochaine s’annonce très prometteuse, avec la possibilité d’intégration de Groovy avec Grails et des produits du portefeuille Spring comme Spring Batch, Spring Integration, et Spring dm Server.

Autres liens :

• Le site officiel de Grails.
• La documentation officielle : http://grails.org/doc/1.0.4.

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

Open Source eXchange : comptes-rendus des participants

Si vous n’avez pas pu assister à la journée OpenSource Exchange organisée conjointement par Skills Matter et Xebia de la semaine dernière, nous vous proposons ici en rattrapage quelques-uns des retours effectués par les participants à cette journée.

• Éric Lefevre met à disposition sur son blog un compte rendu synthétisant l’ensemble de la journée.
• Olivier Croisier a quant à lui effectué une série d’articles fort intéressante sur chacune des conférences :
• Compte rendu SpringSource dmServer, dont la conférence était présentée par Michael Isvy.
• Compte rendu eXo Platform, dont la conférence était présentée par Tugdal Grall.
• Compte rendu Java EE 6, dont la conférence était présentée par Antonio Goncalves.
• Compte rendu Groovy, dont la conférence était présentée par Guillaume Laforge.
• Compte rendu Glassfish v3, dont la conférence était présentée par Alexis Moussine-Pouchkine.
• Compte rendu Portlet 2.0, dont la conférence était présentée par Christophe Laprun.
• Compte rendu Hadoop, dont la conférence était présentée par Hugues Le Bars.

Nous profitons de cette revue de presse pour les remercier.

Vous pouvez également nous proposer d’autres comptes-rendus si vous le désirez.

L’Aquarium à Paris le 12 décembre : inscriptions ouvertes

Nous en parlions la semaine dernière, 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 a été baptisée « L’Aquarium à Paris » et 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…

Les inscriptions sont désormais ouvertes.

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

• GlassFish et MySQL, premiers signes d’intégration
• IBM investit dans EnterpriseDB
• DomainHealth : Un outil de monitoring pour les serveurs Weblogic (9 & 10)

Agilité

• Certification ScrumMaster, on en parle

Le coin de la technique

• Spring WS 1.5 : un fort potentiel à concrétiser
• Milestone 3 pour Spring Java Configuration

Actualité éditeurs / SSII

GlassFish et MySQL, premiers signes d’intégration

L’intégration de MySQL au groupe Sun Microsystem n’a pas tardé. Alexis Moussine-Pouchkine nous présente dans MySQL et GlassFish dans un bateau l’intégration du serveur Open Source Glassfish à la célèbre base de données. On y découvre notamment les tarifs des contrats de support et de maintenance, des éléments décisifs pour les équipes d’exploitation.

IBM investit dans EnterpriseDB

EnterpriseDB vient d’annoncer une levée de fonds de 10 millions de dollars, dont l’un des principaux investisseurs n’est autre que IBM. L’éditeur de DB2 justifie ce choix en rappellant ses investissements dans le monde open source sur des projets tels que Linux, Eclipse et Apache.

Ce choix peut peut-être aussi s’expliquer par le fait qu’EnterpriseDB édite Postgres Plus Advanced Server, qui se veut être un concurrent direct des bases de données Oracle. Produit commercial s’appuyant sur la base de données open source Postgresql (sous license BSD), Postgres Plus Advanced Server fournit entre autres des outils de migration pour Oracle.

Quelques liens :

• http://ostatic.com/158698-blog/enterprisedb-a-new-stake-from-ibm-and-its-novel-approach
• http://news.dzone.com/news/ibm-buys-enterprisedb
• http://developers.slashdot.org/article.pl?sid=08/03/25/207211&from=rss
• http://www.lemondeinformatique.fr/actualites/lire-ibm-injecte-de-l-argent-dans-enterprisedb-25697.html
• http://www.01net.com/editorial/375401/ibm-investit-dans-les-bases-de-donnees-open-source-d-enterprisedb/?rss

DomainHealth : Un outil de monitoring pour les serveurs Weblogic (9 & 10)

Dans cet article disponible sur le blog dev2dev de BEa, j’apprend l’existence d’un produit Open Source permettant de surveiller la bonne santé des serveurs Weblogic. Il permet entre autres de consulter la taille et l’utilisation de la Heap de la JVM, l’utilisation des pool de threads d’exécution, les datasources, les destinations JMS, les WorkManagers et beaucoup autres choses. Bea fournit déjà un outil similaire, une extension de la console d’administration qui permet d’obtenir ce type d’information basé sur le framework de diagnostiques de Weblogic (WLDF). Cependant, cette extension a quelques défaut que comble ‘DomainHealtn’:

• elle n’est pas activée par défaut, il faut ajouter un jar complémentaire dans un répertoire et redémmarer le serveur (DomainHealth se compose d’un simple war à déployer)
• elle ne propose pas de vue d’ensemble sur une page.

DomainHealth offre de parcourir les données collectées pendant toute la vie du domaine, quid de la consommation mémoire sur un domaine qui ne redémarre jamais ou très rarement ?

Bref un outil à tester et à surveiller ici !

Agilité

Certification ScrumMaster, on en parle

Xebia a organisé les 25 et 26 Mars 2008 une formation ScrumMaster certifiante, dispensée par Jeff Sutherland.
Premiers retours:

• http://www.touilleur-express.fr/2008/03/26/im-now-a-scrum-master/
• http://jefute.blogspot.com/2008/03/formation-scrum-master-la-dfense.html

Le coin de la technique

Spring WS 1.5 : un fort potentiel à concrétiser

Spring WS, arrivé bien après les leaders CXF (ex XFire), Axis2 et Metro (JAXWS-RI par Sun), se démarque par une approche originale qui préfère le Plain Old Xml à SOAP et cherche à s’affranchir des WSDL. Cette démarche en fait un bon candidat pour traiter les communications non-soap encore très nombreuses dans nos applications.
Arjen Poutsma nous présente dans What’s New in Spring Web Services 1.5? les nouvelles fonctionnalités du framework. On notera en particulier le support de JMS, de WS-Security et WS-Adressing.
Les points que nous avons aimé dans Spring-WS :

• L’ouverture aux communications non-SOAP (situation particulièrement fréquente pour les communications sur JMS)
• L’intégration à la stack Spring plus poussée que celle de CXF ou d’Axis2.
• La qualité de l’intégration à JAXB 2 avec le Jaxb2Marshaller qui est un modèle d’utilisation de cette API.

Les points que nous espérons pour les prochaines versions de Spring-WS :

• Un support naturel et documenté de l’approche wsdl2java avec un plugin maven similaire au cxf-codegen-plugin.
• Des points d’extension dans l’API pour enrichir les messages échangés (ajout du header JMS_IBM_Character_Set avec Websphere MQ, appel à Tibjms.setEncoding(Message, String) pout Tibco EMS, etc).
• Une documentation plus étoffée.

Milestone 3 pour Spring Java Configuration

Google avait défrayé la chronique en révélant Google Guice, le framework d’injection de dépendances d’Adwords dont la configuration est gérée avec du code Java plutôt qu’avec des fichiers XML.
SpringSource a répondu avec l’utilisation élargie des annotations dans Spring 2.5 (@Autowired, etc) et le lancement de Spring Java Configuration Project. Ce deuxième chantier avance plus lentement, probablement parce que le concurrent Google Guice reste peu utilisé et parce que la tâche s’avère très délicate.
Chris Beams nous présente les dernières évolutions dans Spring Java Configuration – What’s New in M3.
Nous avons été sensibles à :

• L’externalisation des variables (@ExternalValue) équivalent au PropertyPlaceholderConfigurer des configurations XML. Ce mécanisme, incomplet dans Google guice, est particulièrement important pour gérer les paramètres de configuration dont la valeur change suivant les environnements (développement, intégration, production, etc).
• L’étoffement de la documentation qui accorde notamment une place à l’intégration à Maven2.

Si l’utilisation de Spring JavaConfig n’est pas encore d’actualité, voici une bonne occasion de se pencher sur le XML Schema-based configuration introduite en version 2.5 qui allège avantageusement la gestion des configurations XML.

Ressource complémentaire : Spring Dependency Injection & Java 5 par Alef Arendsen ( slides, exemple source).