Actualité éditeurs / SSII

• IBM dévoile WebSphere 8
• Sortie de Play! Framework 1.2
• Nudge, une plate-forme hébergée de monitoring de performance applicative (SaaS)
• Sortie de Rails 3.0.6 corrigeant une faille de sécurité de type XSS

Le coin de la technique

• Red Hat prépare Ceylon, un nouveau langage pour la JVM

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

• Scrum Day 2011: comme si vous y étiez!

Actualité éditeurs / SSII

IBM dévoile WebSphere 8

Nos confrères du Monde Informatique et du Journal du Net reviennent sur la conférence Impact 2011, qui se tenait à Las Vegas les 12 et 13 avril derniers, au cours de laquelle IBM a notamment présenté les grandes lignes de la version 8 de son célèbre serveur d’applications.

Disponible en version bêta depuis le mois de mars — la sortie officielle étant prévue pour juin — cette dernière version est 100% compatible avec Java EE 6. Parmi la longue liste de fonctionnalités au programme de cette nouvelle mouture, citons le support des standards suivants :

• Enterprise JavaBeans (EJB) 3.1
• Java Persistence API (JPA) 2.0
• JavaServer Faces (JSF) 2.0
• JavaServer Pages (JSP) 2.2
• Servlet 3.0
• JAXB 2.2
• JAX-WS 2.2, et notamment le support de Web Services Security API (WSS API) et WS-Trust, censés faciliter le SSO à l’aide de web services.

WebSphere 8 devrait apporter également:

• une meilleure prise en charge des applications OSGi;
• une meilleure intégration des web services utilisant WS-Security SAML Token Profile 1.1;
• un support de SIP Servlet 1.1 afin de favoriser l’utilisation d’applications de communication;
• le support du cache L2 de JPA à l’aide de DynaCache (le cache par défaut utilisé dans WebSphere);
• une intégration simplifiée avec WebSphere MQ.

IBM semble également avoir voulu contenter les développeurs d’applications (il était temps, diront certains): non seulement le serveur semble démarrer plus rapidement, mais surtout le processus de déploiement a été simplifié, et il sera désormais possible de (re)déployer une application avec un simple drag’n drop.

Sortie de Play! Framework 1.2

La version 1.2 du framework Play! vient tout juste de voir le jour. Pour ceux qui ne le connaitraient pas encore, Play est un framework web orienté haute productivité. Comme son cousin Grails, il repose sur des conventions, est extensible via des plugins et supporte le rechargement à chaud des modifications du code.

Les nouveautés apportées par cette nouvelle version sont nombreuses :

• ajout d’un système de gestion de dépendances basé sur Ivy, permettant de récupérer des modules Play ou toutes autres librairies requises,
• support du Long Polling et des Web Sockets, pour les connections asynchrones,
• introduction d’un mécanisme de gestion des évolutions des schémas de bases de données,
• ajout du concept d’Invocation permettant la mise en place de mécanismes équivalent aux Servlet Filters ou à l’AOP (pour la déclaration des transactions à l’arrivée d’une requête par exemple),
• support des bases H2, maintenant embarquées par défaut,
• possibilité de lancer les tests JUnit directement dans Eclipse (sans passer par la page de tests),
• une meilleure documentation du framework, avec notamment une Cheat-Sheet, toujours accessible en mode déconnecté.

Cette version 1.2 est accompagnée de la version 0.9 du plugin Scala pour Play. Ce plugin permet l’utilisation du langage Scala pour développer vos applications Web avec le framework Play. Outre une meilleure intégration de Scala dans le framework Play, cette nouvelle version du plugin apporte une nouvelle couche d’accès aux bases de données nommée Anorm. Anorm permet l’accès en SQL à vos données et utilise des fonctionnalités du langage Scala (le Combinator Parsing) pour mapper le résultat des requêtes avec vos objets. D’importantes évolutions sont encore attendues dans la prochaine version de ce plugin, qui devrait encore améliorer son intégration et sa documentation.

Cette nouvelle version apporte donc d’importantes améliorations et confirme la simplicité qui est au coeur de la philosophie de Play.

Nudge, une plate-forme hébergée de monitoring de performance applicative (SaaS)

La société Level5 Consulting vient de sortir Nudge, une offre hébergée de monitoring d’applications en production. Les cibles sont des logiciels de type web ou batch développés en Java/JEE.

Utilisateurs, vous aurez à disposition des fonctionnalités permettant de :

• collecter et agréger des temps de réponse,
• identifier les requêtes SQL consommatrices,
• suivre la consommation mémoire et CPU,
• agréger des données par module et/ou processus métier,
• créer de métriques personnalisées par API,
• gérer des alertes et des SLA,
• collecter des informations sur les incidents de production.

Vous bénéficierez aussi d’un support d’expert sur l’optimisation d’application. Vous pouvez dès maintenant découvrir Nudge gratuitement ou bien tester une application de démonstration disponible sur le site de l’éditeur. Pour plus de détails, consultez l’article de Developpez.com sur le sujet.

Sortie de Rails 3.0.6 corrigeant une faille de sécurité de type XSS

C’est le 6 avril que la dernière version (3.0.6) de l’outils Rails est sortie. C’est une version importante puisqu’elle corrige, entre autre, une faille de sécurité. En effet, une vulnérabilité de type XSS (Cross Site Scripting) peut être exploitée si la méthode auto_link est utilisée dans les sources. Cette dernière en effet avait la fâcheuse habitude de marquer automatiquement ses paramètres comme étant html safe, et ce, quelle que soit leur origine: ceux-ci n’étaient donc en vérité jamais contrôlés. Il était donc possible d’exécuter du code javascript malveillant en l’injectant dans un paramètre de type string. Le billet mentionne trois solutions pour palier ce problème: mettre à jour votre version de Rails, installer un patch ou… ne pas utiliser cette méthode

Cette mise à jour apporte quelques autres ajouts, dont vous pouvez retrouver le détail sur le blog du projet.

Le coin de la technique

Red Hat prépare Ceylon, un nouveau langage pour la JVM

Le « buzz » de la semaine c’est bien sûr la diffusion d’une présentation (et de sa deuxième partie) que Gavin King a faite à Pékin lors de la QCon, où il révèle qu’il travaille pour Red Hat à un nouveau langage pour la JVM : Ceylon. Bien que Gavin ne prévoyait pas de parler officiellement du projet de son équipe aussi tôt, il a confirmé la nouvelle ; d’abord sur son blog, puis lors d’une interview pour InfoQ.

Alors de quoi s’agit-il ? La première chose à noter est que Gavin King se défend de vouloir créer le langage du futur pour la JVM ou un « Java Killer ». Il se dit d’ailleurs « fan apologétique » de Java et propose donc Ceylon comme un langage fortement inspiré de celui-ci, sans les frustrations qu’il occasionne. Les principales frustrations étant selon lui :

• les librairies du SDK, vieilles et mal conçues ;
• la difficulté de définir une interface utilisateur en Java (il blâme d’ailleurs le complément quasi-automatique de Java pour beaucoup de besoins : XML) ;
• le manque d’un vrai système de modules (il dénonce à cet égard la complexité de Maven et d’OSGi, en se prononçant en faveur du framework JBoss Modules) ;
• le manque de fonctions d’ordre supérieur et/ou de première classe ;
• la gestion de la concurrence (il fustige le fait que tout objet Java puisse être un sémaphore et juge qu’un langage ne devrait pas avoir de primitives de synchronisation, ce rôle devant selon lui être assumé par des librairies spécialisées) ;
• ce qu’il appelle les « verrues » du langage : getters/setters, tableaux et types primitifs, la gestion des valeurs null, les checked exceptions, la généricité (surtout des points qu’il juge obscurs comme la notion de type erasure ou les wildcards) et le système de typage d’une manière globale.

En pratique — et en résumé — Ceylon propose les points suivants :

• de garder tout ce qui fonctionne bien dans Java et en a fait le succès : la JVM, la garbage collection, pas de pointeurs, le typage statique, la lisibilité ;
• le tout objet : tout est type et il n’y a pas de types « primitifs » (mais on peut encore utiliser void pour spécifier le non-retour d’une fonction) ;
• la possibilité de faire des mixins, c’est-à-dire d’implémenter des méthodes dans des interfaces (tant qu’il n’y a pas besoin d’initialisation) — fonctionnalité sans doute inspirée du Projet Coin ;
• une généricité à la fois plus simple et plus restrictive : les paramètres-types (type parameters) peuvent, à l’aide des mots-clés in et out, être déclarés covariants ou contravariants, ce qui élimine la nécessité de passer par des wildcards, qui n’existent d’ailleurs pas dans ce langage: si Box prend un paramètre-type T covariant, une variable de type Box<Integer> est alors assignable, sans transtypage explicite, à une variable de type Box<Number>. Cela conduit Gavin King à imaginer deux interfaces List<T>, l’une covariante avec T et prenant en charge les opérations de lecture, l’autre contravariante prenant en charge les opérations d’écriture (qui modifient la liste) ;
• une structure intrinsèquement récursive: « une classe n’est qu’une fonction retournant à l’appelant une fermeture renfermant tous ses membres » (à la manière de ce que fait JavaScript) ;
• des fonctions d’ordre supérieur et de première classe : une fonction peut ainsi être passée en paramètre d’une autre fonction, une fonction peut contenir d’autres fonctions (ceci découle de la structure récursive du langage), une fonction peut être assignée à une variable, etc… — cependant, les fonctions anonymes (fonctions lambda) ne sont pas autorisées;
• classes et interfaces peuvent spécifier par avance l’ensemble des sous-types qu’elles peuvent avoir ;
• pas d’opérateur de transtypage (casting), mais la possibilité d’utiliser une structure switch particulière :

switch(maVariable) case (is UnType) {...} case(is UnAutreType) {...} else {...}

• des contrats plus forts :
  • des valeurs ne sont nullables que si explicitement déclarées comme telles (avec un « ? » derrière le type) et il faut alors obligatoirement les tester avec :

    if (exists maVariable) {...} else {...}

  • les attributs d’une classe ne sont modifiables que si déclarés comme tels avec variable, et il faut alors utiliser l’opérateur := plutôt que = pour leur réaffecter une valeur ;
• des niveaux de visibilité simplifiés : shared (public) ou privé par défaut ;
• des getters/setters implicites pour les variables d’instance ;
• pas d’exceptions vérifiées (checked exceptions) ;
• pas de surcharge (overloading) de méthodes mais en revanche des valeurs par défaut pour les paramètres ;
• pas de surcharge d’opérateur mais des équivalents/méthodes que l’on peut redéfinir pour un type les supportant. Par exemple > est équivalent à .largerThan() qui peut être redéfini par les implémentations de Comparable ;
• une syntaxe alternative où il est obligatoire de nommer les arguments des méthodes, ce qui donne au final un langage descriptif que Gavin envisage comme une solution face à XML pour décrire des interfaces — l’exemple suivant, tiré de la présentation de Gavin King, est en effet assez parlant:

Table squares {
    title = "Squares";
    rows = 10;
    Column {
        heading = "x";
        String content(Natural row) {
            return $row;
        }
    }
    Column {
        heading = "x**2";
        String content(Natural row) {
            return $row**2;
        }
    }
}

Au rayon des choses étranges :

• pas de mot-clé new ;
• un seul constructeur autorisé (définitivement pas d’overloading donc), qui plus est fusionné avec la définition de la classe :

class Counter(Natural initialValue) {
	if (initialValue > 100) {
		throw OutOfRangeException()
	}
	...
}

• le support de la curryfication ;
• la documentation est conçue comme partie intégrante du langage (un peu comme dans Noop).

Que penser de cet énième langage fondé sur la JVM?

On retrouve en effet dans Ceylon beaucoup de fonctionnalités également présentes dans d’autres langages dérivés de Java (Scala, Groovy, Gosu, Fantom, pour ne citer qu’eux). On les retrouve aussi dans la réflexion de Stephen Colebourne pour définir un futur grand langage pour la JVM, qu’il a notamment présentée lors de la réunion du Paris JUG du mois de mars.

On constate donc bien que le but n’est pas de révolutionner le monde Java, et par ailleurs beaucoup de critiques ont déjà fusé sur le fait que Scala propose mieux depuis longtemps ou que ce langage propose tellement peu qu’il pourrait être mort-né.

Cela étant, les idées proposées sont plus que jamais d’actualité, et l’initiative étant portée par Red Hat et Gavin King (Hibernate, JBoss Seam), on peut légitimement espérer qu’elle fasse bien plus d’effet qu’un pétard mouillé.

Quoi qu’il en soit, il y a encore beaucoup de travail sur le projet : bien que le langage soit en étude depuis deux ans, aucun compilateur n’a encore vu le jour.

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

Scrum Day 2011: comme si vous y étiez!

Les webcasts du Scrum Day sont en ligne sur le wiki du FSUG. Revivez l’intégralité de l’événement, comme si vous y étiez! Les présentations du grand amphithéâtre ont été filmées, les autres sont diffusées en commentaires audio accompagnés de slides.

Actualité éditeurs / SSII

• SpringSource : sortie par le haut
• Websphere: les derniers seront les premiers ?

Agilité

• Prioriser le Product Backlog
• Leçons de management par la NASA

RIA

• 10 choses à savoir sur Flex
• GraniteDs en version 1.1.0

Le coin de la technique

• JSR-277 : OSGi m’a tuer (Stanley Ho)

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

• Paris JUG : soirée OSGi

Actualité éditeurs / SSII

SpringSource : sortie par le haut

Comme nous l’annoncions succinctement mercredi, SpringSource a revu sa copie concernant sa nouvelle politique de maintenance abandonnant de ce fait les points les plus polémiques de celle-ci, dont sa fameuse règle des trois mois à l’origine des levées de boucliers de la communauté.

Dans son post de mardi dernier, Rod Johnson dévoile donc le nouveau fonctionnement de celle-ci : les releases seront disponibles pour la communauté jusqu’à la sortie d’une nouvelle version majeure. Ainsi, les binaires des versions 2.5.x du cœur du framework continueront d’être publiés tant que Spring 3.0 RC1 n’est pas disponible. SpringSource compte, par ce biais, inciter la communauté open-source à toujours coller aux dernières versions de son framework.

Websphere: les derniers seront les premiers ?

Dernier serveur certifié Java EE 5, Websphere ressort grand vainqueur d’une étude comparative des principaux serveurs d’application du marché, menée par Evans Data Corporation (rapport gratuit, mais enregistrement nécessaire).

Cette étude soulève déjà de nombreuses questions chez les concurrents (comme Rick Sharples, de JBoss), le marketing d’IBM n’allant pas se plaindre d’une si belle vitrine.
Rick émet 3 interrogations majeures :

• Comment comparer des serveurs d’application dont les communautés peuvent varier d’un noyau de type ‘niche’ (SAP) à des super-communautés mondiales (IBM, BEA, RedHat ou Microsoft) ?
• Pourquoi n’arrive t’on pas à corréler les résultats de cette étude avec ceux d’autres études publiques, voire internes, sur JBoss ?
• Pourquoi évalue t’on un serveur aussi confidentiel que Geronimo (lui aussi chez IBM) ?

Pour notre part, nous émettons un certain nombre de réserves :

• L’étude ayant été menée durant l’été 2008, elle ne peut nécessairement pas porter sur WAS 7.0, sorti officiellement en septembre (d’autant plus qu’un des points de l’étude porte sur le support, qui n’est pas assuré pour les versions beta). Cette étude porte donc plus globalement sur ‘les marques’, plutôt que sur les dernières versions des serveurs d’application cités.
• Les consultants Xebia ont l’habitude de travailler avec bon nombre de ces serveurs d’application, et au petit jeu des comparaisons directes (ce qui n’est pas le cas de cette étude), les avis sont loin d’être aussi tranchés.
• La rédaction du rapport est très orientée ‘marketing’, ce qui est étonnant au vu de la population consultée. Il est étonnant de lire des phrases telles que « WebSphere’s users obviously love this product. » venant de développeurs qui n’ont souvent pas le choix de leur serveur d’application (souvent dicté par les achats groupe ou l’exploitant) et qui ont tendance à ne faire que « subir » ses désavantages.

Alors, étude téléguidée par un éditeur ? Enième conflit d’intérêt pour un cabinet d’analyse dont les clients sont les premiers sujets de comparatifs ? La réponse est sûrement plus complexe et on peut tout au plus tirer quelques enseignements de ce travail :

• JBoss joue définitivement dans la cour des grands, et est un concurrent sérieux pour les « grands » serveurs d’application, même sur des applications à grande échelle.
• la communauté s’inquiète du rachat de BEA par Oracle (peut-être est-ce même la raison principale de cette 7ème place).
• Le « petit jeune », Glassfish, qui remporte l’adhésion des développeurs pour sa facilité de mise en oeuvre, n’est pas en reste sur les fonctions principales (performances, scalabilité) et vient titiller les vieux mastodontes.
• La comparaison objective de serveurs d’application, dans un environnement aussi hétéroclite que celui des SI du XXIeme siècle, avec des problématiques variées et complexes, est un exercice dangereux, qui porte rapidement à critique.

Agilité

Prioriser le Product Backlog

En Scrum, il faut ordonner les éléments du Product Backlog pour que l’équipe sache quelles sont les fonctionnalités à implémenter en priorité.
Peter Stevens propose différentes stratégies pour prioriser le Product Backlog, à composer selon le contexte du projet :

• Ensemble minimum de fonctions : faire une liste minimum des fonctions à implémenter pour que le produit soit utilisable et accepté par les utilisateurs
• Valeur métier en premier : se concentrer sur les fonctions à haute valeur ajoutée métier. La valeur métier (typiquement avec un coefficient entre 1 et 100) est fixée par le Product Owner.
• En avoir pour son argent : semblable à la précédente approche, elle se concentre sur les éléments qui ont le meilleur rapport valeur métier/coût.
• Risques techniques en premier : préconisée par RUP, cette approche s’attaque aux points techniques difficiles en premier. Cela peut cependant conduire à un système trop complexe par rapport aux besoins.
• Reporter le risque : s’attaquer aux difficultés en dernier (ou jamais). Préférer les stories bien comprises, tout en investigant les stories plus risquées/coûteuses pour les décomposer.
• Votes des utilisateurs : demandez aux utilisateurs de voter parmi une liste de fonctionnalités potentielles.

Ce dernier point peut être accompli par une analyse de Kano comme le propose Mike Cohn dans sa présentation Prioritizing Your Product Backlog mise en ligne sur InfoQ. Le pdf est également disponible.
Mike Cohn y présente plusieurs techniques de priorisation, plus concrètes mais nécessitant plus de calculs :

• Analyse de Kano : distinguer les thèmes selon 3 types : fonctions obligatoires, linéaires, et attractives. Implémenter toutes les fonctions obligatoires, le plus de linéaires possible et quelques excitateurs pour la satisfaction utilisateur.
• Theme screening : noter les thèmes selon certains critères de sélection, par rapport à un thème de référence.
• Theme scoring : semblable au Theme screening en pondérant les critères de sélection
• Relative weighting : pour chaque thème, calculer le rapport entre sa valeur relative (aux autres thèmes du product backlog) et son coût relatif. Ce rapport donne la priorité du thème.

Ces techniques s’appliquent toutes au niveau thème, car descendre au niveau user story demanderait trop de travail sur un product backlog complet.

Leçons de management par la NASA

Jerry Madden, un ancien employé du Goddard Space Flight Center de la NASA, a collecté « 100 leçons » apprises auprès des managers qu’il a cotoyés.
Marios Alexandrou en a extrait les leçons qui collent le plus avec son expérience des projets web. Parmi les plus marquantes :

• Une réunion de travail devrait durer 5 minutes minimum (moins elle est inutile) et 1 heure maximum (plus c’est un marathon). Au-delà de 6 personnes, elle devrait être réservée au transfert d’information.
• Ne demandez jamais à vos chefs de prendre une décision que vous pouvez prendre vous-même, sauf si un document vous l’interdit.
• Ne supposez jamais que quelqu’un a fait quelque chose, demandez lui. Même le plus évident peut être oublié, surtout en période de stress.
• La documentation ne remplace pas la connaissance. Les documents restent des images statiques dans le temps et sont rapidement dépassés.
• Les projets nécessitent un travail d’équipe pour réussir. Rappelez-vous que la plupart des équipes ont un coach et non un boss, mais le coach doit parfois arbitrer certaines parties.
• Si un chef de projet est l’homme le plus intelligent de l’équipe, c’est qu’il a fait un mauvais travail de recrutement.
• Les principes de gestion sont toujours les mêmes. Seuls les outils changent. Vous devez toujours trouver les bonnes personnes pour faire le travail et rester à l’écart pour qu’ils puissent le faire.

Il est amusant de constater certaines similitudes avec les méthodes agiles. Les individus et leurs connaissances sont plus importants que la documentation. Le coach doit s’appuyer sur une équipe de personnes motivées, intelligentes, et responsables qui n’attendent pas d’ordre d’un patron. Leur collaboration est essentielle à la réussite du projet. Ces ressemblances sont logiques finalement, il s’agit simplement de bon sens.

RIA

10 choses à savoir sur Flex

Les articles recommandant Flex se succèdent. Après l’annonce d’Atos sur son blog Entreprise 2.0 du choix de Flex sur plusieurs projets pour de grands comptes et la « victoire » de Flex lors de notre RIA Contest, c’est au tour de Alaric Cole, l’auteur de « Learning Flex 3″ de lister 10 avantages à l’utilisation de Flex.

Alaric Cole est partie prenante, et on a déjà pu lire sur d’autres blogs les différents points cités, mais l’article a l’avantage de les regrouper :

1. Flex s’apparente aux standards d’une application Web : MXML est un langage de balises comparable à l’HTML, l’ActionScript est l’équivalent du JavaScript. Le tout customisable avec du CSS.
2. Flex = Flash : tout ce qui était possible en Flash l’est en Flex. Flex apporte cependant une couche de structuration/méthodologie par rapport à Flash
3. Une application Flex fonctionne sur tous les navigateurs et tous les OS (Linux 64bit ?). La seule contrainte est d’avoir déployé le plug-in d’exécution.
4. Le framework RIA d’Adobe accepte l’échange de données et propose des interfaces de communication avec plusieurs formats d’échange (SOAP, HTTP, AMF…)
5. Une application Web Flex aura un « Look And Feel » identique quelque soit l’OS client
6. Flex est léger et rapide grâce notamment aux améliorations du futur plug-in Flash 10. Par exemple, la fonctionnalité de « Framework Caching » permet de réduire à 100Ko la taille de l’application à télécharger
7. Les composants de Flex sont nativement construits pour être accessibles (loupe, internationalisation, raccourcis clavier…)
8. Le contenu d’une application Flex peut maintenant être indexé par un moteur de recherche
9. Le SDK Flex est maintenant OpenSource et gratuit mais attention l’IDE Flex Builder est payant.
10. Enfin, il rappelle la facilité d’apprentissage du langage. Pour un habitué de la Javadoc, l’accès au format ASDocs d’Adobe est cependant déroutant les premiers temps.

Même si l’ancienneté de Flex sur le marché, la couverture de déploiement de son plugin d’exécution et la solidité de son distributeur Adobe semblent placer Flex en tête du tournoi RIA, il est bon de rappeler que la compétition ne fait que commencer : 2 outsiders sérieux (Silverlight et JavaFx) vont bientôt s’élancer dans la course ! L’avance prise par Flex pourra t-elle être comblée ?

GraniteDs en version 1.1.0

GraniteDS est un framework opensource équivalent à BlazeDS, simplifiant le développement des communications entre un RIA Flex et un serveur J2EE. Cet article d’InfoQ nous présente les nouvelles fonctionnalités disponibles sur GraniteDS 1.1.0:

• Granite Eclipse Builder : un plugin Eclipse basé sur AS3 Generator permettant de générer le code ActionScript 3 associé aux JavaBeans. Ce plugin génère automatiquement du code lorsqu’un JavaBean est modifié.
• Tide : ce framework fournit des fonctionnalités telles que la mémorisation d’objets dans un contexte qui transite entre la partie cliente et la partie serveur, la pagination des données. Il permet également de gérer le lazy loading des collection en wrappant les collections et en les récupérant dés que c’est nécessaire.
• MXML Web Compiler : une compilation à la volée du code source MXML et ActionScript 3 sur le serveur d’application.

Avec cette nouvelle version, GraniteDS se positionne comme un concurrent sérieux de BlazeDS. La génération des JavaBeans, la gestion du lazy loading et la compilation à la volée sont des points forts qui séduiront très vite les développeurs. Cette nouvelle approche ne peut que faciliter et améliorer le développement d’applications Flex.

Le coin de la technique

JSR-277 : OSGi m’a tuer (Stanley Ho)

Stanley Ho a annoncé son départ de Sun Microsystems. Par la même occasion, il laisse les clés de la JSR-277 dont il était à la tête. C’est donc Alex Buckley qui reprend le flambeau, il était déjà responsable de la petite sœur, la JSR-294 : les superpackages.

Nous sommes en droit de nous demander si la création du prototype permettant l’interopérabilité entre Java Module System et OSGi qu’a amorcé Sun ces derniers mois a quelque chose à voir avec ce départ. Quoi qu’il en soit, le tournant est définitivement engagé pour le futur de Java Module System.

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

Paris JUG : soirée OSGi

Dernière piqûre de rappel pour la soirée OSGi de ce mardi 14 octobre au Paris JUG.

• Le programme est disponible ici : première partie ‘introduction à OSGi’, seconde partie : ‘OSGi appliqué’
• Les inscriptions sont gratuites et ouvertes à tous, enregistrez-vous ici
• La soirée aura lieu à l’ISEP, dont voici le plan d’accès

Nous vous y attendons nombreux.

Actualité éditeurs / SSII

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

Agilité

• Le Scrum meeting, story par story ?

RIA

• Microsoft et Nokia adoptent jQuery

Le coin de la technique

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

Actualité éditeurs / SSII

Spring Source : les VC prennent le contrôle

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

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

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

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

Quelques liens :

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

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

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

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

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

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

Agilité

Le Scrum meeting, story par story ?

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

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

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

RIA

Microsoft et Nokia adoptent jQuery

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

Le coin de la technique

Les spécifications REST se terminent

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

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

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

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

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

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

JVM Wish List vue par Terracotta

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

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

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

Principes pour le design d’une API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

David Syer communique sur Spring Batch

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

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

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

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

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

Le coin de la technique

• invokedynamic vu de l’intérieur
• Concurrency : past and present
• Tuning des JVM Websphere 6.1
• Performance d’affichage d’une page Web

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

• Refactoring itératif de conférences : JavaPolis, Javoxx et DeVox

Le coin de la technique

invokedynamic vu de l’intérieur

Dans cet article, Charles Nutter, JRuby Core Developper nous présente pourquoi il est nécessaire de mettre à jour le bytecode invokedynamic.
Java nous oblige à typer chaque variable et chaque méthode doit définir une signature statique dont les types sont connus avant le Runtime : Java est un langage ‘statiquement’ typé. Si ce typage fort est une des forces du langage, comment la JVM peut-elle supporter des langages dynamiques ? La rigidité de Java provient, plus de son langage que de son bytecode. C’est ainsi que des langages comme Groovy permettent d’enfreindre certaines règles, par exemple : ne pas définir de types aux variables. Ce n’est pas pour autant que le bytecode va tout nous permettre, certaines règles sont incassables dont celles qui s’appliquent aux invocations de méthodes :

• Les invocations sont statiquement typées.
• Les invocations doivent s’effectuer sur des méthodes Java. Il est impossible de remplacer un appel à une méthode par un morceau de code interprété.

À l’origine, la JSR-292 a proposé la mise en place d’un nouveau code invokedynamic permettant l’invocation de méthodes sans signatures typées statiquement, mais rien n’avait été prévu pour modifier dynamiquement la logique d’invocation de la JVM.

Concurrency : past and present

Brian Goetz, auteur du livre ‘Java Concurrency In Practice’, a publié sur InfoQ une vidéo enregistrée lors du QCon 2007 : Concurrency : Past and Present.
Pourquoi est-il plus difficile de développer des applications multithreadées que de parler en lisant son journal ?
Dans cette présentation, Brian tente de répondre à cette question en revenant sur les principales difficultés de la programmation concurrente. Sujet que nous avions également abordé lors d’un article publié cet été sur le sujet : « programmation concurrente : notions fondamentales« . Pour illustrer ces problèmes, Brian revient sur l’histoire de la programmation concurrente et ses différentes approches, avant de donner ses recommandations. À la fin de la vidéo, il présente également les fonctionnalités offertes par d’autres langages comme ErLang et Scala.

Tuning des JVM Websphere 6.1

Giribabu Paramkusham et Ajay Bhalodia, WebSphere Application Server Technical Support, présentent dans JVM Performance Tuning with respect to Garbage Collection(GC) policies for WebSphere Application Server V6.1 part 1 (pdf) les points clef du tuning des JVM pour Websphere. Nous retiendrons :

• Les JVM IBM proposent quatre stratégies de garbage collections :
       - -Xgcpolicy:optthruput pour minimiser le temps global d’exécution (batch, …).
       - -Xgcpolicy:optavgpause pour minimiser la durée de chaque pause.
       - -Xgcpolicy:gencon destiné aux applications web. L’algorithme Générationnel Concurrent communément utilisé dans les JVM Sun est optimisé pour les objets à courte durée de vie.
       - -Xgcpolicy:subpools pour les serveurs à grand nombre de processeurs (>16).
• A la différence de l’implémentation GenCon de Sun qui comprend trois zones (Young, Tenurd et Permanent), celle d’IBM n’en comporte que deux (Young et Old)
• L’option -verbose:gc est activable en production avec un impact négligeable sur les performances et l’option moins connue -Xverbosegclog permet de préciser un fichier de sortie en mode rolling file . Nous noterons que les informations de GC sont désormais formattées en XML ce qui facilitera la manipulation avec des outils.
• Indépendamment des limites techniques liées au système d’exploitation, les JVM IBM sont optimisées pour utiliser des heap le plus souvent inférieures à 2 GB :

source IBM

• L’utilisation de JVM 64 bits supprime les limites de taille de heap mais pénalisent les performances (plus de données manipulées) et la consommation mémoire (des pointeurs sur 64bits plutôt que 32bits accroissent de 30% à 50% la mémoire consommée)
• La JVM 6 d’IBM réduit les dégradations de performances et de consommation mémoire en 64bits grâce à l’introduction de « pointeurs compressés »

Performance d’affichage d’une page Web

Hayes Potter, nous présente dans Speed up your website, quick! des règles structurantes afin d’améliorer les performances d’affichage d’une page Web :

• Compression des ressources statiques (images, fichiers flashs, scripts, …).
• Mettre en place une politique d’expiration des ressources statiques .
• Mettre les styles CSS en haut de la page HTML tandis qu’il faut mettre les fichiers Javascript en bas de la page.
• Limiter les requêtes http://request vers d’autres domaines. En effet à chaque requête vers un autre domaine, pendant le chargement de la page, une résolution DNS est effectué (accès réseaux supplémentaires).

Dans le même esprit, Yahoo a mis à dispositon de la communauté des développeurs Web un ensemble de règles : Exceptional Performances.
Il y a 34 Best Pratices répartis dans 7 domaines différents :

• Contenu
• Serveur
• Cookie
• CSS
• Javascript
• Image
• Mobile

Voici les règles les plus marquantes :

• Externaliser les fichiers CSS et Javascripts de la page HTML.
• Réduire la taille des fichiers Javascripts en éliminant les caractères superflus (espace, variable à rallonge, …). Cela peut être assisté par des outils tel que JSMin et YUI Compressor. L’idéal c’est que les développeurs des pages gardent des fichiers Javascripts lisibles et maintenables puis au déploiement de ces pages, passer une moulinette sur les fichiers Javascripts afin d’épurer les caractères superflus.
• Eviter la duplication des importations du même script, par exemple IE retéléchargera plusieurs le fichier bien que c’est la même ressource.
• Utiliser une requête HTTP GET pour les requêtes AJAX.
• Rassembler l’ensemble de vos images (pour les gestions des boutons par exemple) en une seule image et en faire un sprite avec CSS. Cette tache peut être assister par les outils CSS Sprites et Website Performance CSS Sprite Generator.
• Limiter l’utilisation des iframe.

Références :

• Yahoo! New Performance Best Practices Now Available (Mars 2008), excellente présentation de Stoyan Stefanox, développeur Yahoo, qui reprend point par point toutes ces Best Pratices

Voici une liste d’outils facilitant la mise en oeuvre et la vérification de ces points :

• YSlow, outil Yahoo aidant à la vérification de ces best pratices
• Fiddler, debugger HTTP
• IBM Page Detailler, décrire le déroulement des fichiers téléchargés pour l’affichage d’une page
• Firebug (que pour firefox)
• JSMin, minimiseur JavaScript
• YUI Compressor, minimiseur Javascript
• CSS Sprites, générateur de sprite CSS
• Website Performance CSS Sprite Generator, générateur de sprite CSS

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

Refactoring itératif de conférences : JavaPolis, Javoxx et DeVox

Terminons cette revue de presse par la petite histoire belge de la semaine. L’un des plus gros événements Java au monde JavaPolis vient de changer de nom pour la seconde fois cette année. Renommé Javoox en début d’année, il semblerait que cet ancien nouveau nom soit encore trop proche de « Java » pour Sun. Avec ce nouveau nom : DeVoxx, le BeJug (porteur de l’événement) continue le bras de fer avec Sun en osant mettre un ‘V’ en 3e caractère de leur nouveau nom … tout comme dans ‘jaVa’ … La newsletter de DeVoxx nous explique que ce nouveau changement de nom est dû à une volonté de rester un événement Java indépendant.

• Site officiel du BeJug
• Site officiel du DeVoxx
• Consultez la liste des intervenants à DeVoxx 2008

Actualité éditeurs / SSII

• MySQL by Sun : Revirement de stratégie open source ? Choquant ?
• Superpackages (JSR-294) vs. OSGI : Episode n° 34291567….

Agilité

• User stories « En tant que … je veux … »

Le coin de la technique

• De la sérialisation au parallélisme, une évolution incarnée par java.util.concurrent
• Innovation autour de JPA : JBoss Hibernate confirme son domination avec Envers
• Cas d’utilisation des grilles Java avec WebSphere eXtreme Scale/ ObjectGrid
• JSR-311 JAX-RS REST une histoire de RESTaurant

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

• XKE, le programme de la session de mai

Actualité éditeurs / SSII

MySQL by Sun : Revirement de stratégie open source ? Choquant ?

Slashdot essaie de nous emmener sur une polémique « Sun gâche MySQL » avec Sun May Begin Close Sourcing MySQL Features à l’occasion de l’annonce par l’éditeur de fonctionnalités (online backup, etc) qui seront uniquement disponibles dans la version payante MySQL Enterprise. Au delà de l’insinuation peu crédible quand on se rappelle que l’essentiel du catalogue de Sun est disponible gratuitement, on retrouve le défi aujourd’hui classique de la monétisation de l’Open Source. Le rachat de MySQL par Sun change complétement le modèle économique de l’éditeur de base de données.

Hier, la startup MySQL, financée par des fonds de capital risque, se permettait d’être déficitaire car les candidats au rachat (Oracle puis finalement Sun) ne valorisaient pas MySQL Inc sur ses revenus mais sur les parts de marché de sa base de données. La stratégie a magnifiquement porté ses fruits puisque MySQL Inc s’est vendue un milliard de dollars à Sun, félicitations au management.

Aujourd’hui, MySQL est vraisemblablement devenue une division ‘classique’ de Sun et doit donc devenir rentable. L’équation de la rentabilité de l’open source est complexe, Red Hat et JBoss by Red Hat ont été des pionniers sur ce chemin, souhaitons à MySql by Sun de trouver lui aussi son modèle.

TSS : MySQL to get new features in Enterprise version

Modification du billet le 29 Avril 2008 : Jonathan Schwartz est finalement revenu en arrière et a annoncé que tous les produits que Sun distribue, sans exception, sont proposés gratuitement en licence Open source à la communauté. Pour plus de détails sur cette histoire, nous vous recommandons la série de The 451 Group : MySQL’s business model in a state of flux, Finding the right balance – MySQL’s changing development model et Jonathan Schwartz has the last word on MySQL

Superpackages (JSR-294) vs. OSGI : Episode n° 34291567….

La guerre continue entre les partisans de OSGI et ceux des JSR de SuperPackage et de JAM. Cependant, l’attaque vient cette fois-ci d’Alex Buckley de chez Sun.

Il explique dans son email les inconvénients qu’il voit dans l’implémentation actuelle des superpackages[1]. En substance, il propose d’introduire à la place un nouvel ‘access modifier’ (module).

Peter Kriens de l’OSGi Alliance semble plutôt emballé par cette proposition.

[1] Pour mémoire, nous avons publié en février dernier un article présentant les superpackages

Agilité

User stories « En tant que … je veux … »

Mike Cohn nous rappelle les 3 raisons pour lesquelles il préconise de décomposer les user stories sous forme de phrase « En tant que <role>, je veux <but>, pour que <raison> » (la raison est optionnelle) :

• L’emploi de la 1ère personne du singulier aide les développeurs à s’identifier à l’utilisateur
• La structure de la phrase – représentée par 3 colonnes dans le Product backlog – aide le Product Owner à comprendre et prioriser les user stories
• Pour ne pas rajouter de bruit dans la description des user stories, il suffit de nommer les colonnes du Product backlog « En tant que … », « je veux … », « pour que … » et le backlog devient intuitif à lire.

Le coin de la technique

De la sérialisation au parallélisme, une évolution incarnée par java.util.concurrent

La programmation multi-threadée en java a évoluée : anciennement on utilisait la sérialisation incarnée par synchronized, désormais on peut faire du parallélisme avec l’introduction des API java.util.concurrent en Java 5.

Sharadjava nous présente dans sa Java Concurrency Series les différents aspects de cette nouvelle librairie :

• Simple Executor example pour la parallélisation des tâches.
• Barrier pour l’attente entre tâches (on n’oubliera pas sur ce sujet le CountDownLatch).
• Meaning of volatile pour la visibilité inter-threads des valeurs des variables.

Innovation autour de JPA : JBoss Hibernate confirme son domination avec Envers

Après l’intégration de la recherche full text Lucene [1] et le support du Database Sharding, Hibernate confirme sa domination de l’innovation autour de JPA en ouvrant le chantier du versionnage des données. Cette problématique, bien que récurrente et accentuée par les nouvelles contraintes réglementaires (Sarbane & Oaxley, etc), restait largement ignorées par nos frameworks et nos très chers design patterns. Seul Martin Fowler nous éclairait sur ce sujet délicat avec Patterns for things that change with time.

JBoss comble aujourd’hui ce vide en lançant Envers, une extension d’Hibernate qui versionne les données persistantes selon un pattern similaire au Temporal Object de Martin Fowler. Envers n’est qu’en version preview mais le projet est très prometteur et déjà une source d’inspiration pour les projets qui n’ont pas le temps d’attendre la première version stable.

On notera au passage qu’Envers préfère l’API standard JPA EntityManager à l’historique Session Hibernate ; on peut y voir un signe que le temps est venu pour les équipes projets de privilégier les standards JPA aux API historiques Hibernate.

Exemple d’entité persistante versionnée avec JBoss Envers

@Entity
public class Person {
    @Id
    @GeneratedValue
    private Integer id;
    @Versioned
    private String name;
    @Versioned
    private String surname;
    @Versioned
    @ManyToOne
    private Address address;
   ...
}

[1] cf notre billet Introduction à Hibernate Search (Googling your Persistent Domain Model)

Cas d’utilisation des grilles Java avec WebSphere eXtreme Scale/ ObjectGrid

Billy Newport présente dans Video: Introduction to WebSphere eXtreme Scale/ObjectGrid with patterns and use cases les scénarios typiques d’utilisation de la grille Java d’IBM :

• Cache de proximité classique : la grille sert de Map distribuée ; l’application métier gère les données (chargement depuis les backends, mise en cache et sauvegarde des modifications dans les backends).
• Cache de proximité avec « Loader synchrone » dans la grille : l’application métier se limite à demander des données à la grille et à les modifier ; la grille, grâce à un Loader, s’occupe de charger les données depuis les backends et sauvegarde en synchrone les données modifiées dans les backends.
• Cache de proximité avec un « Loader à écriture différée » dans la grille : similaire au scénario précédent mais la sauvegarde des modifications dans les backends est asynchrone.
• Cache collocalisé : l’application et la grille s’éxécutent dans les même JVM, chaque JVM héberge un noeud du cluster de l’application et un noeud de la grille. Ce scénario est typique de la mise en cache des sessions HTTP.

On notera que les architectures de type Map/Reduce, qui nécessitent une conception radicalement différente, ne semblent pas encore très répandues.

JSR-311 JAX-RS REST une histoire de RESTaurant

Dans cet article, Nicolas Martignole nous présente l’architecture REST (Representational State Transfer) et JSR 311: JAX-RS: The Java API for RESTful Web Services. L’objectif de cette JSR est de faciliter la programmation d’applications REST en Java.
La première partie est consacrée à une introduction de REST (définition d’une ressource, lecture, création, mise à jour, suppression d’une ressource, Services Webs RESTfull).
La deuxième partie nous présente quelques détails sur l’implémentation JAX-RS avec Java.

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

XKE, le programme de la session de mai

Le prochain XKE (Xebia Knowledge Exchange) aura lieu le mardi 6 Mai 2008. Les sujets suivants seront abordés :

• Sessions Pratiques
  • Terracotta, the Network Attached Memory (NAM)
  • java.util.concurrent, concours de developpement

• Technique
  • Java et la Cryptographie

• Architecture
  • Retour sur l’architecture de l’un des plus grand site de ecommerce de France
  • Tests unitaires avec les librairies de Mock

• Xebia Hollande
  • Intervention du CTO de Xebia Hollande

Comme nous l’annoncions, les XKE sont ouverts à l’ensemble des personnes à l’écoute du marché de l’emploi autour des technologies Java/J2EE. Si vous êtes l’une d’entre elles , n’hésitez pas à contacter Mélanie Bacrot pour vous inscrire.

Actualité éditeurs / SSII

• Google App Engine, écrivez vos propres applications Google
• Polémique : Gartner Group nous révèle que Windows Vista s’écroule sous son propre poids

Le coin de la technique

• Polémique : Java est en train de perdre la bataille du web moderne
• Java EE Next Generations, les prédictions de Rod Johnson
• Sortie de Maven 2.0.9
• Camel 1.3 : les lightweight ESB progressent
• Netcraft Web Survey : Jetty progresse alors que Tomcat stagne
• IBM ObjectGrid est mort ! Longue vie à Websphere eXtreme Scale !
• Java Web Frameworks Survey

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

• Kirk Pepperdine au Paris JUG

Actualité éditeurs / SSII

Google App Engine, écrivez vos propres applications Google

Google a annoncé la semaine passée la mise à disposition d’une plateforme d’hébergement pour applications Web, Google App Engine. La plateforme est pour l’instant en preview release, seuls 10 000 développeurs on pu s’enregistrer pour y accéder.

App Engine met à disposition des développeurs (pour l’instant gratuitement, mais le service sera bientôt payant) les outils utilisés par Google pour ses propres applications :

• Stockage de données avec BigTable et Google File System (GFS)
• Scalabilité et répartition de charge
• APIs Google, pour gérer l’authentification, envoyer des mails, et dialoguer avec le système de stockage de données
• Ainsi qu’un environnement de développement local

Les développements sont pour l’instant effectués en Python, mais d’autres langages devraient prochainement être supportés. Si vous souhaitez promouvoir votre langage favori, c’est par ici que ça se passe (la demande de support de Java est actuellement en tête devant celles de Ruby et PHP).

Depuis la mise à disposition de ses services Amazon Simple Storage Service (S3), Amazon Elastic Cloud (EC2 – nuage de serveurs), et SimpleDB (base de données), nous savions que ce n’était qu’une question de mois avant de voir la riposte de Google.
Mais les services de Google et Amazon ne sont pas en concurrence frontale. Là où Amazon met à disposition des briques logicielles, Google met à disposition un environnement complet. On pourrait imaginer une application utilisant l’App Engine de Google en façade d’un nuage (EC2) pour le traitement par batchs.
A quand la réponse de Microsoft?

Quelques articles qui nous ont paru intéressants sur le sujet

• ZDNet : Google announces App Engine: Should Amazon worry?
• BusinessWeek : Google App Engine Goes Up Against Amazon, But That’s Not the Point
• BioloGeek : Google App Engine – avantages et inconvénients

Polémique : Gartner Group nous révèle que Windows Vista s’écroule sous son propre poids

Gartner Group nous annonce dans Windows collapsing under its own weight; Radical change needed que Windows 7 sera radicalement différent de Vista, ce sera le premier système d’exploitation modulaire de Microsoft.

Scoop ? Pas vraiment, Gartner nous l’avait déjà annoncé en Février 2007 dans Is Vista the last monolithic release?. En revanche, la nouvelle annonce nous dévoile quelques détails sur Windows 7.

Le coin de la technique

Polémique : Java est en train de perdre la bataille du web moderne

TV4IT nous avait invité à participer à son débat Java est mort, vive Java ? (part 2, part 3).
The Server Side relance le débat cette semaine avec Java is losing the battle for the modern web …. Derrière ce titre bien trouvé de guerre moderne, comme d’habitude, Java se ferait sortir du monde des applications web par des architectures LAMP sur des moteurs en C ; même la JVM ne trouve pas grâce aux yeux des cassandres.

Rien de nouveau dans les polémiques millénaristes si ce n’est un avis pessimiste sur l’avenir du prochainement disponible JavaFX face au prometteur Microsoft Silverlight et à l’omniprésent Adobe Flex. Comment JavaFX arrivera-t-il à prendre des parts de marché aux solutions d’Adobe et de Microsoft ? Quelle promesse de valeur ajoutée convaincra les clients de changer de technologie ?

Java EE Next Generations, les prédictions de Rod Johnson

Rod Johnson nous livre dans The Biggest Loser’s Next Contestant: Java Bloatware sa vision des prochains serveurs d’applications Java.

C’est l’occasion de comprendre la ligne directrice du framework Spring et en particulier de Spring Dynamic Modules for OSGi(tm) Service Platforms, Spring Integration et Tomcat (récemment rapproché de Spring par le rachat de Covalent).

Nous passerons les habituelles piques contre les serveurs d’applications Java EE qualifiés cette fois de « morbidly obese legacy platforms ». Au delà de ces critiques lassantes, nous retiendrons :

• L’avenir de Java EE ne passera plus seulement par les spécifications du JCP mais aussi par celles d’organismes (cf OSGI, SCA, etc.)
• Les serveurs d’applications de demain seront modulaires et beaucoup plus compacts
• Les ESB et les serveurs d’applications vont converger
• Ces évolutions augurent un renouveau de la compétition sur la marché des serveurs d’applications
• Spring se positionne avec sa stack associée au serveur Tomcat dont on peut s’attendre une évolution rapide (OSGI-fication ?)

Sortie de Maven 2.0.9

La dernière version de Maven est disponible, voici les points les plus innovants :

• MNG-3395 : le super pom 2.0.9 contient désormais les versions par défaut pour les plugins de base de Maven. Cette fonctionnalité était grandement attendue, elle devrait résoudre les problèmes de stabilité rencontrés sur les projets qui ne fixent pas dans leur pom parent les versions des plugins, puisque dans ce cas les plugins étaient mis à jour automatiquement dès leur mise en ligne sur le repository. Le travail effectué par Don Brown avec sa branche maven-db a en partie payé!
• MNG-1412 et MNG-3111 : l’ordre des dépendances dans les fichiers classpath générés est désormais déterminé par l’ordre de déclaration dans le pom, les dépendances héritées étant ajoutées à la fin.
• MNG-3415 : une erreur lors du téléchargement d’un artefact ne devrait plus corrompre les métadonnées du repository local. On ne devrait plus avoir besoin de supprimer une partie du repository local dans ce cas.
• Un projet peut désormais importer les dépendances de plusieurs projets grâce au scope « import ». Sur un gros projet multi-modules c’était quasiment impossible, puisqu’un module ne peut hériter que d’un seul parent. Bien évidemment si on utilise cette fonctionnalité Maven 2.0.9 devient obligatoire pour builder le projet.

A noter que les 2 premiers points peuvent changer le comportement de votre build, attention aux risques de régression! La liste complète des corrections et améliorations est en ligne.

Camel 1.3 : les lightweight ESB progressent

James Strachan nous présente les nouveautés d’Apache Camel 1.3, le prédécesseur du toujours pas releasé Spring Integration dans le domaine des lightweight esb [1].
On remarquera l’amélioration de la testabilité, la meilleure intégration aux POJOs et le support de Microsoft Message Queuing (MSMQ) et d’AMQP.

Si cette release est une bonne nouvelle pour les utilisateurs des Enterprise Integration Patterns, elle est en revanche une source de confusion pour les utilisateurs d’Apache ServiceMix 3, le conteneur JBI également inclus dans la stack IONA FUSE, dont la valeur ajoutée par rapport à Camel est aujourd’hui difficile à trouver. La présentation du futur ServiceMix 4, qui intégrera OSGI, CXF et Camel, aidera les utilisateurs surpris à comprendre comment s’articulera la suite ActiveMQ-Camel-CXF-ServiceMix.

[1] cf. Xebia Blog : Spring Integration – L’avènement des ‘lightweight ESB’ ?

Netcraft Web Survey : Jetty progresse alors que Tomcat stagne

Alors que LightHttpd empiète poliment sur les plates-bandes de Apache Http Server avec seulement 2% des parts de marché de son aîné, le conteneur de Servlets open source Jetty rivalise sans complexe avec le très établi mais stagnant Apache Tomcat : le nombre de serveurs Jetty représente 80% de celui de serveurs Tomcat (cf webtide blog: Jetty has 80% of Tomcats public servers).

Comment Jetty a-t-il rattrapé Tomcat aussi vite ? Les innovations de Jetty sont certes intéressantes (OSGI, Ajax Comet Push, etc) mais il faut surtout voir l’attention que Jetty porte à sa communauté de développeurs en proposant un produit très léger et facile à intégrer alors que Tomcat s’est quelque peu endormi sur ses lauriers. Espérons que le récent rachat de Covalent par Spring Source redynamisera la communauté Tomcat.

Source : Webtide blog : Jetty Improves in Netcraft survey

IBM ObjectGrid est mort ! Longue vie à Websphere eXtreme Scale !

Billy Newport nous annonce que la grille de données qu’il a supervisée, IBM ObjectGrid, s’appellera dorénavant Websphere eXtreme Scale

Simple détail de marketing ou signe de « Big Is Beautiful » chez IBM ? Hormis ses qualités qui font d’ObjectGrid une grille de données de tout premier plan [1], ObjectGrid se singularisait dans le portfolio Java d’IBM par une grande indépendance à la stack Websphere (les 6 petits Mo du client ObjectGrid s’exécutent indépendamment de Websphere, même sur une JVM Sun) et par un format de documentation très novateur avec un wiki Confluence plutôt qu’un classique Infocenter.

Billy Newport avait été visionnaire en prédisant dès juillet 2005 l’avènement du lightweight Java dans End of the Java Web Frameworks Survey road for invasive middleware?. Espérons que son message continuera à influencer Big Blue et qu’ObjectGrid ne disparaîtra pas dans l’imposante stack Websphere.

[1] cf. l’EntityManager à la JPA qui n’a pas d’égal pour manipuler les POJOs des la grille

Java Web Frameworks Survey

Peter Karich présente dans Java Web Frameworks Survey un comparatif des huit frameworks Web qui suivent :

• Click Framework
• Echo2
• GWT
• JSP
• Thinwire
• Wicket
• WingS
• ZK Framework

L’application était un simple bouton avec une zone de texte, dans laquelle on devait mettre un morceau de code permettant de dessiner un graphique. Pour le graphique, la librairie gnuplot a été utilisée.

Le comparatif nous permet de découvrir certains frameworks peu connus. Selon l’auteur, le framework Click présente des similarités avec Wicket et propose des aspects plus simples. Mettre en place sa première page avec Echo n’est pas très compliqué. En revanche GWT demande un certain coût d’entrée… (Nous avions partagé certaines de ces conclusions dans notre Web Framework Contest en Octobre dernier.

La conclusion de cette étude est que comme souvent chacun de ces frameworks a ses forces et ses faiblesses, et que si vous devez en choisir un il faut se poser les bonnes questions: un support est-t-il disponible ? Il y a t’il une communauté active? Quelles sont les possibilités d’intégration à une application existante ?

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

Kirk Pepperdine au Paris JUG

Kirk Pepperdine est venu présenter au Paris JUG les enjeux de performances en Java. En attendant que la présentation de Kirk soit disponible, les points essentiels :

• L’émergence des processeurs multi-coeurs révèle des problèmes de concurrence d’accès qui n’apparaissaient pas auparavant : une application peut s’exécuter moins vite sur un processeur multi-coeur à cause d’apparition de goulets d’étranglement (synchronisation, etc).
• Les APIs java.util.concurrent introduites avec Java 5 (en même temps que la clarification du modèle mémoire) simplifient le développement d’applications hautes performances.
• Les bases de données ne sont pas encore optimisées pour les architectures multi-coeurs et sont concurrencées frontalement par les grilles de données (Terracotta, Coherence, etc) qui elles exploitent les opportunités de parallélisme.
• Diagnostiquer un problème des performances d’une application Java nécessite d’étudier simultanément les quatre couches de « The Box » [1] : Hardware, JVM, Application et People.
• Les premiers outils pour ce type de problèmes sont le Gestionnaire des Tâches sous Windows et vmstat/top sous Unix/Linux car ils donnent une vision d’ensemble (IO, CPU Système, CPU Applicative, etc).

D’autres blogs parlent de la venue de Kirk Pepperdine : Le touilleur Express : Présentation de Kirk Pepperdine au Paris Java User Group, David Gageot: Troisième rencontre du Paris Java User Group.

Merci encore aux organisateurs du Paris JUG et rendez-vous le 13 mai pour des présentations sur la Productivité des développements Java (Guillaume Duquesnay) et Maven (Arnaud Heritier).

[1] cf InfoQ : The Box: A Shortcut to finding Performance Bottlenecks par Kirk Pepperdine

Actualité éditeurs / SSII

• Microsoft se rapproche de la fondation Eclipse
• Eclispe 4, une refonte du socle ?
• SpringSource Application Management Suite (AMS)

Agilité

• Polémique : Scrum aliène-t-il XP ?

RIA

• Adobe AIR pour Linux

Le coin de la technique

• SCA Java EE Integration specification : v0.9
• IBM annonce Websphere MQ V7 pour Juin
• Complexité cyclomatique optimale : 11 selon Enerjy !
• Java Module System (JSR-277) et OSGI, un silence pesant

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

• Poissons d’avril

Actualité éditeurs / SSII

Microsoft se rapproche de la fondation Eclipse

A l’occasion d’EclipseCon 08, Sam Ramji, leader de la communauté Open Source chez Microsoft, a annoncé le début d’une collaboration entre La fondation Eclipse et Microsoft.
Le principal but de ce rapprochement concerne une meilleure intégration du toolkit graphique d’Eclipse SWT avec Windows Presentation Foundation (WPF).

Eclispe 4, une refonte du socle ?

Voulant conquérir de nouveaux horizons, notamment côté serveur, la fondation Eclipse annonce la création d’un nouveau composant appelé e4. Le but principal de ce projet est de poser les bases du futur Eclipse 4.0. Partant de zéro, son rôle sera de simplifier la plateforme Eclipse et d’être résolument tourné vers le web.
Prévu au mieux pour fin 2009, Eclipse 4 sera développé en parallèle d’Eclipse 3.4 (Ganymede) et devrait assurer le compatibilité des plugins existants.

SpringSource Application Management Suite (AMS)

SpringSource vient de livrer une solution de monitoring des applications basée sur Spring. Voyons ici un système concurrent de Glassbox. Cependant, cet outil tire partie des nouvelles possibilités de configuration par annotation offertes par Spring 2.5. Il comprend automatiquement les annotations @Controller, @Repository, @Transactional, @Component et @Service. L’avantage donc par rapport à Glassbox finalement c’est la prise en compte automatique des beans gérés par Spring dans le monitoring.

SpringSource AMS est basé sur Hyperic’s HQ Enterprise Edition, fruit du récent partenariat entre les deux sociétés.

Un outil résolument à suivre ….

Agilité

Polémique : Scrum aliène-t-il XP ?

Notre collègue Vikas Hazrati a résumé sur InfoQ: Do Extreme Programming Folks Care about Scrum? une discussion très « animée » initiée par Michael James à propos de Scrum vue par les praticiens d’XP (eXtreme Programming). Ce dernier pense que Scrum et XP sont des alliés, mais ce n’est pas l’avis de tout le monde.

Comme Guillaume Bodet l’expliquait dans Scrum ou XP ? Scrum et XP !, nous pensons que Scrum et XP sont complémentaires, Scrum se positionne au niveau de la gestion/organisation de projet tandis que XP concerne les activités de développement.
Mais comme le dit Bruce Robinson, XP n’est pas la seule méthode de développement et elle n’est pas forcément la plus adaptée dans tous les cas, on peut par exemple préférer la revue de code au pair programming.

Alistair Cockburn répète que les pratiques préconisées par XP sont utiles mais pas nécessaires, des projets fonctionnent très bien sans XP.
Peu importe la méthode, mais tous sont d’accord qu’un projet nécessite des pratiques de développement pour réussir. Effectivement Scrum fournit un cadre méthodologique mais elle nécessite d’être complétée, « implémentée » par des pratiques de développement.

Wayne Mack propose l’approche du menu chinois : apprenez les 2 méthodes, choisissez ensuite les éléments qui vous semble intéressants parmi le menu.
Attention toutefois, Vikas Hazrati nous rappelle à travers le ShuHaRi que choisir les éléments du menu et créer sa propre méthode demande de la maturité, il conseille de commencer par expérimenter une méthode telle que préconisée, et seulement une fois à l’aise avec la méthode vous pouvez essayer de la personnaliser.

Pour en revenir aux valeurs de l’agilité, la méthode n’est pas le principal, les personnes et leurs interactions sont plus importantes. Car même si vous appliquez de bonnes pratiques, cela ne vous protège pas contre une « mauvaise » équipe (manque de compétences techniques, mauvais relationnel, esprit compliqué…). Quelle que soit la méthode il faut des gens talentueux et motivés pour mener à bien un projet selon J. B. Rainsberger, cependant un processus peut aider et XP semble le mieux adapté pour compléter Scrum.

Même si le groupe n’a pu se mettre d’accord au final, certains ont mentionné avoir utilisé Scrum et XP ensemble avec succès !

La discussion originale est sur Yahoo! Extreme Programming: How is Scrum alienating the eXtreme Programming folks?.

RIA

Adobe AIR pour Linux

Adobe AIR est enfin disponible pour la plateforme Linux. Seul bémol, celui-ci est une version alpha. Néanmoins, cette version contient le runtime, un exemple d’application et le AIR SDK. Par ailleurs, Flex Builder 3 a aussi été mis à jour afin de supporter la mise en place d’applications AIR sous Linux.
Adobe continue son ascension et remporte de plus en plus de succès et d’adhésion. Va t-on vers une ère Adobe ?

Le coin de la technique

SCA Java EE Integration specification : v0.9

Pendant que le Java Community Process tarde à statuer sur le modèle de composants de bas niveau OSGI, la communauté SCA continue à avancer les pions de son standard d’assemblage de composants de haut niveau avec la publication d’une première ébauche de la SCA Java EE Integration specification. Cette spécification a le mérite d’apaiser le monde Java EE après la tonitruante déclaration de Michael Rowley (BEA) : « EJB session beans, MDBs, JAX-WS and even JMS aren’t usually necessary in an SCA universe » dans Does SCA define a new programming model for Java?.

Quel impact pour le quotidien des développeurs Java ? Quasiment aucun pour le moment ; SCA est une spécification à l’utilisation encore confidentielle (SCA est principalement présent dans Websphere ESB et Process Server).

IBM annonce Websphere MQ V7 pour Juin

Le marché des middlewares de messages est lui aussi modifié par l’émergence d’offres open source matures (Apache ActiveMQ, etc ). Dans cette atmosphère dynamisée, IBM Websphere MQ, le leader du marché, tourne la page de trois ans de V6.0 avec l’annonce de WMQ V7.0 pour Juin 2008.
Les principales améliorations :

• Amélioration des performances (particulièrement publish/subscribe, réception sur selector et messages non persistents).
• Simplification de l’administration du mode publish/subscribe et des ressources JMS.
• Bridge HTTP pour directement exposer les queues à des clients Web 2.0/Ajax.
• Intégration native du mode publish/subscribe au Queue Manager [1].

Nous aurions espéré :

• Un mécanisme de relivraison différé des messages équivalent à la redelivery policy d’ActiveMQ.
• Une amélioration des performances des temporary queues similaire à celle apportée aux selectors. L’utilisation de files temporaires est un modèle encore plus simple que les selectors pour réaliser des invocations synchrones avec un middleware de messages (cf pattern request/reply).

Plus d’informations dans Redbook: WebSphere MQ V7.0 Features and Enhancements (Draft).

[1] En v6.0, un broker périphérique était utilisé.

Complexité cyclomatique optimale : 11 selon Enerjy !

Les outils d’analyse statique de code fleurissent avec l’essor des serveur d’intégration continue. L’éditeur Enerjy, après avoir étudié des projets open source réputés à la loupe de son analyseur, révise la valeur optimale de la complexité à 11. On notera que cette valeur est légèrement supérieure à celle retenue par CheckStyle, le leader de l’analyse statique, qui estime que 10 est déjà excessif.

Si la valeur exacte est sujette à débat, c’est l’occasion de se rappeler que la complexité cyclomatique est un indicateur pertinent de qualité du code et que les environnements de développement et serveurs d’intégration continue rendent aujourd’hui facile le suivi de ces indicateurs.

Java Module System (JSR-277) et OSGI, un silence pesant

Nouveau rebondissement dans le feuilleton « JSR-277 : Java Modules System versus OSGI ».

La JSR d’assemblage des composants menée par Sun prenait un retard inquiétant pour être intégrée à la version 7 de Java (Dolphin). Un petit répit s’annonce avec le décalage de la sortie de Dolphin désormais planifiée pour Janvier 2009.

Si cette prolongation donne une chance à la JSR-277 de figurer dans la prochaine version de Java, il reste néanmoins un problème de gouvernance de fond sur cette spécification. Peter Kriens (OSGI Alliance) expliquait en Septembre dernier qu’il a été refoulé de l’expert group sans raison convaincante. Dalibor Topic (kaffe.org) a demandé en Janvier l’éviction de 9 membres de ce même expert group sur une mailing list du projet Open JDK. Les déclarations fusent et l’expert group de la JSR 277 qui ne communique toujours rien de concret sur la position du très important OSGI, laissant la place à la rumeur et au mécontentement …

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

Poissons d’avril

Premier jour d’avril oblige, certains ont annoncé de fausses nouvelles, surprenantes ou amusantes. Voici une liste des poissons d’avril que nous avons recensés :

• Microsoft rachète SpringSource
• Microsoft rachète TheServerSide.com (décidément Microsoft est en forme)
• Google et Richard Branson (Virgin) s’associent pour lancer la 1ère colonie sur Mars
• De l’ASCII Art dans le bytecode Java
• Le projet JavaRebel intègre une Intelligence Artificielle qui code à votre place pendant vos pauses-cafés
• Cédric Beust lance le projet Toledo : un générateur de code multi-langage
• Eclipse e4 déjà disponible
• TSS devient multilingue

Actualité éditeurs / SSII

• Sortie de Wicket 1.3.1
• Sortie de Grails 1.0

Agilité

• Comment mesurer le succès d’un projet agile du point de vue client ?

Le coin de la technique

• Eclipse 3.4 M5 : le Breadcrumb Mode
• Les différents GC de la JVM
• Test Unitaire avec Spring MVC
• Websphere Webcast : Prepare for Problem Determination for WebSphere Application Server

Actualité éditeurs / SSII

Sortie de Wicket 1.3.1

Il y a un mois nous annoncions la sortie de Wicket 1.3.
Comme un peu de teasing ne fait pas de mal, nous profitons de la sortie version 1.3.1 pour vous annoncer une prochaine série de billets dédiée à ce Web Framework.
Quant à cette version, la principale nouveauté concerne le support transparent et out-of-the-box d’un mode cluster.

Sortie de Grails 1.0

Grails est défini comme ‘the ultimate rapid prototyping for Java’ par certains. Il s’agit d’un framework web s’inspirant de Ruby on Rails écrit en Java et de Groovy. Grails repose sur des frameworks ayant fait leurs preuves comme Spring et Hibernate.
Vous pouvez télécharger Grails à cette adresse, sa documentation est disponible ici.

Agilité

Comment mesurer le succès d’un projet agile du point de vue client ?

Vikas Hazrati revient dans InfoQ – Discussion: Measuring Success of an Agile Project from the Customer’s Perspective sur un échange ayant eu lieu sur le user group Scrum Development.
Il y offre des pistes pour définir quels éléments de mesure peuvent (devraient) être communiqués par l’équipe afin qu’un client puisse mesurer sa satisfaction (et donc le succès du projet).

Le coin de la technique

Eclipse 3.4 M5 : le Breadcrumb Mode

Le projet Eclipse vient de mettre à disposition le MileStone 5 de la version 3.4 – Projet Ganymede (Date de Sortie prévue le 25 juin). Parmi les évolutions marquantes, on peut noter le Breadcrumb Mode. Une fois activé, Eclipse ajoute sur chaque fichier ouvert une barre de navigation horizontale qui indique les différents éléments qui mènent à la sélection courante. Dans cette vidéo, on voit l’évolution de cette barre en fonction de la sélection: une classe, une méthode, une inner-classes et une méthode de l’inner-classe.

Démonstration en vidéo : Breadcrumb.wmv.

Les différents GC de la JVM

Ce post de Jon Masamitsu présente les particularités des différents algorithmes offerts par la JVM pour gérer et libérer les différentes zones mémoires d’une JVM Sun. Il dévoile également un nouveau type de ‘collector’ qui serait disponible et utilisé par défaut dans la prochaine version de Java, le ‘Garbage First’ ou G1. L’idée principale est ne plus diviser la mémoire en deux zones (Young & Tenured) mais en plusieurs régions dont le rôle majeur (Young/Tenured) serait déterminé au runtime.

Test Unitaire avec Spring MVC

Le nombre de tests unitaires d’un framework de présentation est souvent faible en comparaison des autres parties de l’application. C’est sur ce constat que le framework Spring MVC a mis l’accent sur l’outillage de ces tests unitaires.
Craig Walls et John Ferguson Smart nous présentent respectivement leurs conseils dans Unit-testing Spring MVC: It gets even awesomer et Unit testing your Spring-MVC applications. Il n’y a plus d’excuses !

Websphere Webcast : Prepare for Problem Determination for WebSphere Application Server

Yu Tang, membre du WebSphere SWAT team, nous présente Prepare for Problem Determination for WebSphere Application Server . Les points essentiels :

• La gestion d’un problème sur un serveur J2EE se décompose en trois étapes :
     - Collecte des informations de diagnostique. Cette phase est essentielle pour la correction sur le fond du problème.
     - Fix en urgence et redémarrage du serveur.
     - Correction sur le fond du problème.
• Les problèmes se regroupent en deux grandes familles :
     - Les crashs (JVM, système, etc).
     - Les blocages / dégradations de performances (avec ou sans consommation élevée de CPU).
• Les principales informations à collecter sont :
     - Les classiques logs SystemOut et SystemErr sans oublier les informations de FFDC et d’activity.log.
     - Les logs de VerboseGC : un très bon indicateur de l’état de santé de la JVM. VerboseGC mérite d’être activé en permanence car son impact sur les performances est très faible (il faut toutefois gérer la purge régulière du fichier).
     - Les javacores (aka thread dumps) : essentiels pour diagnostiquer les blocages/dégradations de performances.
     - Vmstat et netstat : compléments des javacores en cas de problème de performance.
     - Les heap dumps : essentiels pour traiter les OutOfMemoryError. Préciser la variable IBM_HEAPDUMPDIR pour diriger ces logs très volumineuses sur un système de fichiers dédié pour prévenir les problèmes file system full [1].
     - Il faut rédiger et tester régulièrement les procédures de collecte des informations de diagnostiques (notamment les heap dumps et les java cores).

Un complément pour approfondir le sujet : The Support Authority: 12 ways you can prepare for effective production troubleshooting par IBM Software Services for Websphere.

[1] Ce système de fichiers dédié (e.g. /coredumps/) sera mutualisé entre les différentes applications java voire avec d’autres applications qui peuvent générer des cores volumineux. Ce système de fichiers est destiné à devenir plein si le problème se répète rapidement et que le nombre de cores se multiplie. Son but est d’éviter de remplir les autres systèmes de fichiers.

Le coin de la technique

• JSF Testing Tools
• Wicket 1.3 released
• WebSphere MQ en environnent J2EE/JEE : JMS vs. ‘MQ Java Interfaces’
• IBM ObjectGrid 6.1 fix 3 : une grille résolument ‘developer friendly’

Le coin de la technique

JSF Testing Tools

Cet article présente trois principaux frameworks permettant d’effectuer des tests unitaires JSF. Pour rappel, la principale difficulté est de pouvoir effectuer des tests en dehors du container, et grâce à ces outils il est possible de tester les composants côtés client mais aussi côté serveur.

• JSFUnit est basé sur HttpUnit et Apache Cactus. Son API permet notamment de tester le transfert de données dans un formulaire et de savoir si le managed bean correspondant à bien été mis à jour… Cet outil inclue aussi un JSF Static Analysis permettant notamment d’analyser les fichiers de configuration.
• Shale Test est un projet Apache fournissant des implémentations d’objet Mock pour les Servlets et les composants JSF.
• JSF Extensions est basé sur JUnit, HTMLUnit, et Cactus. Cet outil est composé d’un module Test-Time fournissant des objets Mock pour les composants JSF 1.2, ainsi qu’un module Design-Time pour effectuer des déploiements plus rapide (hot deploy). Cette fonctionnalité a pour but de mettre en place des tests de manière itératif durant le développement d’application JSF.

Enfin l’article termine par deux outils d’aide au développement et au monitoring d’applications JSF :

• JXInsight, se basant sur l’interface PhaseListener, permet de collecter différentes informations sur l’exécution du code (les stacks…)
• JSF Tools, sous projet de Eclipse WTP, fournit un support pour le développement et le déploiement d’application JSF.

Pour terminer, cet article présente assez bien les différents outils, mais il aurait peut être été bien de proposer des critiques sur ceux-ci, qui feront peut être l’objet d’un nouvel article.

Wicket 1.3 released

Nous annoncions lors de la revue de presse du 12 novembre dernier son passage en RC, et bien c’est maintenant officiel : Apache Wicket 1.3 fait maintenant partit de la volumineuse liste des java web framework disponibles sur le marché. Malgré cette farouche concurrence, le buzz continue : Wicket est l’un des web framework faisant le plus de bruit sur la toile, ses promesses sont simples : simplicité d’utilisation, POJO-centric, pas de configuration XML … donnez votre sur le billet du Xebia Web Framework Contest.

Nous vous invitons à consulter la liste complète des nouveautés à partir du site d’Apache.

• Apache Wicket
• Discovering Apache Wicket 1.3 by Pachod Joseph
• Guide de migration à Wicket 1.3

WebSphere MQ en environnent J2EE/JEE : JMS vs. ‘MQ Java Interfaces’

David Currie nous rappelle dans WebSphere MQ Java in J2EE que JMS est l’API privilégiée pour accéder à Websphere MQ dans un environnement J2EE/JEE et que les historiques API « MQ Java Interfaces » devraient progressivement être remplacées [1].

Au delà d’un simple choix technique d’API (la fiabilité de JMS est aujourd’hui avérée), il s’agit d’un réel changement de culture depuis l’historique approche en langage C (user exits MQ, style de programmation des « MQ Java Interfaces », etc) vers le monde orienté objet Java / .Net [2]. Cette évolution demande un travail d’explication et de formation des équipes qu’il ne faut pas négliger.

La roadmap MQ JMS pourra aller jusqu’au remplacement de Queue Managers MQ par le Websphere Embedded Messaging Engine pour les utilisateurs du serveur J2EE d’IBM …

[1] IBM Technote : Using WebSphere MQ Java Interfaces in J2EE/JEE Environments : « This technote explains why ‘WebSphere MQ classes for Java Message Service’ is the API best suited for use in J2EE/JEE environments … »
[2] IBM DeveloperWorks : Introducing XMS : The IBM Messages API

IBM ObjectGrid 6.1 fix 3 : une grille résolument ‘developer friendly’

Le fix 3 d’IBM ObjectGrid apporte de nouvelles fonctionnalités résolument à l’écoute des développeurs avec notamment :

• Support de Spring Framework
  - Intégration aux transactions Spring et à leurs annotation @Transactional
  - Gestion par le container Spring des beans d’extension d’ObjectGrid (ObjectTransformer, Loader, TransactionCallback, etc)
• Entity Listeners similaires aux listeners JPA/Hibernate autour des événements persist, load, update et remove

On remarquera à l’occasion la poursuite de la nuit de noces entre IBM et Spring Framework dont les précédents épisodes marquant furent le support officiel de Websphere par Spring Framework (11/2007) et la présentation de Billy Newport sur l’eXtreme Transaction Processing à The Spring Experience (12/2007).

Actualité éditeurs / SSII

• Aqualogic Service Bus 3.0
• IBM et l’intégration continue
• Websphere Process Server 6.1 : renforcement des workflows humains
• Websphere Application Server 6.1 supporte les EJB 3

Agilité

• Le monde devient agile

Le coin de la technique

• Apache Tomcat, la star des serveurs d’applications ?
• La collision dans les hashmap
• Introducing JBoss Seam
• Groovy 1.5

Actualité éditeurs / SSII

Aqualogic Service Bus 3.0

La nouvelle version de l’ESB de BEA est pour bientôt. Parmis les fonctionnalités majeures attendues on retrouve :

• non seulement la performance (Gestion des messages de grandes tailles, routine XSLT/Xquery et une meilleure gestion de caches lié à la sécurité)
• mais également l’intégration avec les différents élements de la suite Aqualogic, en particulier avec Aqualogic Registry Repository et sa vision SCA (Service Component Architecture).
  L’intégration consiste également à généraliser le developpement lié au bus. Dans les versions précédentes, l’approche consistait principalement à du paramétrage: le developpeur se connecte au bus, importe ses resources (XSchéma, WSDL), défini ses Business Services et Proxy Services. Unitairement cette approche est séduisante mais au niveau d’une réelle mise en oeuvre sur un projet d’entreprise cette méthode montre rapidement ces limites:
  • gestion des environnements et des versions : le passage d’un environement de dev à un environnement de recette se fait par un unique mécanisme d’import / export
  • mauvaise vision d’ensemble : refactoring et mutualisation de resources impossible

L’approche proposée par ALSB 3.0 est de pouvoir effectuer toutes ces opérations depuis un environement de travail unifié sous Workshop Studio (Eclipse) et d’ensuite pouvoir déployer (au sens J2EE) l’applications ‘bus’ dans un environement adéquat, de gérer ses resources dans un gestionnaire de source type CVS/SVN, de se connecter facilement à un repository de services pour les assembler et les composer (SCA).
Reférence : AQUALOGIC SERVICE BUS 3.0 sneak preview sur Dev2Dev.

IBM et l’intégration continue

IBM possède maintenant lui aussi sa propre solution d’intégration continue : IBM Rational Build Forge.
Il commence aussi à pondre des articles sur le sujet, comme celui-ci : Automation for the people: Continuous Integration anti-patterns.

Reste à suivre cette série d’articles pour voir ce que cette solution apporte face aux actuels leaders du marché.
Le tutoriel : Improve your build process with IBM Rational Build Forge, Part 1.

Websphere Process Server 6.1 : renforcement des workflows humains

Les éditeurs de serveurs de processus BPEL avaient encore rappelé en juin 2007 leur intention de couvrir le domaine des workflows humains avec la publication du standard WS-BPEL Extension for People (Active Endpoints, Adobe, BEA, IBM, Oracle et SAP).

IBM franchit aujourd’hui une nouvelle étape avec l’enrichissement des fonctionnalités de workflows humains dans la version 6.1 de Websphere Process Server et de Websphere Integration Developer. Si l’infocenter 6.1 n’a pas encore été publié, des introductions sont déjà disponibles sur Developerworks : What’s new in WebSphere Process Server V6.1 What’s new in WebSphere Integration Developer V6.1.

Est-ce le moment de remplacer les moteurs de workflow par des serveurs de processus BPEL ? Ce choix est à évaluer au cas par cas étant données les limitations de WS-BPEL Extension for People [1].

[1] voir Evaluation of the BPEL4People and WS-HumanTask Extensions to WS-BPEL 2.0 using the Workflow Resource Pattern par Nick Russell and Wil M.P. van der Aalst, Université d’Eindhoven.

Websphere Application Server 6.1 supporte les EJB 3

Websphere 6.1 supporte désormais les EJB 3.0 avec le Feature Pack for EJB 3.0. Un complément au Feature Pack for Web Services pour entrer dans le monde Java EE 5 et préparer Websphere 7.

Rappelons que l’implémentation JPA repose sur Apache OpenJPA et que celle de JAX-WS est une adaptation d’Axis 2.

Des tutoriels du Feature pack for EJB 3.0 sont disponibles sur IBM Education Assistant for WebSphere Application Server V6.1 Feature Pack EJB 3.0.

Agilité

Le monde devient agile

Les temps changent et Le Monde Informatique aussi
Avec un titre qui pourrait facilement créer des polémiques auprès de ses lecteurs habituels, Le monde informatique nous décrit très brièvement les méthodes agiles les plus populaires (XP et Scrum). Il nous invite à assister aux rencontres agiles auxquelles il s’associe et qui auront lieu le 18 décembre prochain, à Paris La Défense.

L’article : Des rencontres agiles pour améliorer le taux de réussite des projets

Le coin de la technique

Apache Tomcat, la star des serveurs d’applications ?

Le cabinet BZ Research estime qu’Apache Tomcat est utilisé par 64% des développeurs Java, suivi par IBM Websphere et JBoss Application Server. Si l’on peut débattre de la précision des chiffres, la tendance est indiscutable. L’utilisation de Tomcat sur les postes de développement est en train de se banaliser et des grand comptes montrent la pertinence de Tomcat en production (Morgan Stanley pour la finance, LinkedIn et Yahoo pour l’Internet, etc).

A quand du support commercial en France pour Tomcat ?

La collision dans les hashmap

Il est bon de rappeler parfois qu’une Map (HashMap,Hashtable,…) n’est efficace que si la fonction de hash() est performante. Mais la performance d’une telle fonction engendre nécessairement des collisions. Ce billet de chez ‘Coding Horror’ illustre parfaitement cette dualité (Cases à Pigeon vs Le paradoxe des anniversaires)

Introducing JBoss Seam

JBoss Seam nous vante de simplifier J2EE et de rendre utilisable JSF. Reste à savoir quel est l’intérêt d’utiliser un standard qui nous oblige à le compléter avec d’autres frameworks du marché et de fait, nous écarter du standard …

L’introduction …

Groovy 1.5

Guillaume Laforge nous présente les principales caractéristiques de la version Groovy 1.5 dans cet article sur InfoQ :

• Intégration Java5 : ajout des annotations, generic types, enums, varargs, static imports, covariant return type
• Syntaxe :
  - Elvis operator ‘?:’ (smiley avec la banane) :

  x ?: "defaut"

  equivaut en java à

  x != null ? x : "defaut"

  - Java ‘for’ : les for syntaxe java sont désormais possibles
  - named parameters sans parentèses

• Outils :
  – Joint compiler : permet de compiler des sources java et groovy ensemble sans se soucier des dépendances entre classes
  – MOJO Maven plugin
  – GroovyDoc : équivalent de JavaDoc pour Groovy
  – Nouveau Groovy shell : pour les fans de VI
  – IntelliJ IDEA JetGroovy plugin
• Amélioration des performances
• MetaClass : permet entre autre de rajouter des méthodes au runtime
• Swing on Steroids : pour construire des interfaces Swing plus facilement

Ce langage dynamique fort de son succès avec la version 1.0, améliore ici sa compatibilité avec Java et l’outillage commence à s’étoffer. Ce langage vaut vraiment le détour.
Pour aller plus loin, InfoQ a récemment interviewé Guillaume Laforge sur Groovy et les Domain-Specific Languages.

Actualité éditeurs / SSII

• Enfin une intégration native de Maven à Eclipse

Le coin de la technique

• Les 12 commandements pour préparer le ‘troubleshooting’ de production
• WebSphere MQ Low Latency Messaging : le ‘multicast messaging’ version IBM
• Spring 2.5 released
• Comparing JVM Web Frameworks Videocast

Actualité éditeurs / SSII

Enfin une intégration native de Maven à Eclipse

Le projet q4e vient d’être proposé à la fondation Eclipse. Ne vous réjouissez pas trop vitre pour autant, d’après leur roadmap, la première release est prévu pour septembre 2008. En attendant, il est possible d’essayer d’utiliser la version actuelle 0.2.3.

Plus d’info sur http://www.eclipse.org/proposals/iam/.

Le coin de la technique

Les 12 commandements pour préparer le ‘troubleshooting’ de production

Daniel Julin, WebSphere Serviceability, nous livre ses 12 ways you can prepare for effective production troubleshooting :

1. Créer et maintenir à jour un schéma d’architecture système.
2. Créer et suivre un inventaire des éléments qui permettent de diagnostiquer les problèmes (localisation des fichiers de logs, etc).
3. Attacher une attention particulière aux dumps et autres éléments qui ne sont générés que lorsqu’un problème survient (cores système, javacores, heap dumps, First Failure Data Capture – FFDC, etc)
4. Revoir et améliorer les niveaux de logs durant le fonctionnement normal de la plateforme.
5. Suivre les indicateurs des couches système d’exploitation et réseau (cpu, disque, trafic réseau inter composants, etc).
6. Etre préparé à générer des informations de diagnostique complémentaires lorsqu’un problème survient (générer des dumps, collecter des métriques, générer de l’activité métier, etc).
7. Définir une procédure de collecte d’informations de diagnostique et s’entraîner à exécuter cette procédure.
8. Etablir une image de référence pour connaître la valeurs des indicateurs et logs lorsque la plateforme fonctionne correctement (logs, dumps générés à la demande,  niveaux d’activité cpu/disque/réseau, débit moyen des applications, etc).
9. Purger et archiver régulièrement les logs et les dumps.
10. Eliminer les ‘fausses erreurs’ et autres messages bruyants des logs.
11. Maintenir un change log des modifications de la plateforme.
12. Mettre en place des outils de supervision de bon fonctionnement du système.

Une liste pleine de bon sens qui sera une bonne base de réflexion pour aborder le ‘troubleshooting’ de production.

WebSphere MQ Low Latency Messaging : le ‘multicast messaging’ version IBM

IBM annonce la sortie de WebSphere MQ Low Latency Messaging version 2, un middleware de message destiné aux places de marchés [1] capable d’envoyer jusqu’à 3 millions de messages par seconde avec une latence de quelques dizaines de microsecondes.

Quelle est la différence entre Websphere MQ Low Latency Messaging et le classique Websphere MQ utilisé en informatique de gestion ?

• Websphere MQ Low Latency Messaging repose sur un modèle de distribution multicast : l’émetteur envoi un seul exemplaire du message via un multicast UDP que reçoivent tous les destinataires. Ce modèle est particulièrement adapté aux scénarios ayant un très grand nombre de destinataires (one-to-very-many) mais est inadapté à la garantie d’acheminement des messages qui requiert de contrôler que chaque destinataire a reçu le message et de gérer le cas échéant les ré-envois sans pour autant envoyer plusieurs fois le même message à un destinataire.
• Le classique Websphere MQ repose sur un modèle hub-and-spoke : l’émetteur envoi un exemplaire du message à un hub (le Queue Manager) qui prend en charge l’acheminement du message à chacun des destinataires. Ce modèle permet de gérer facilement la garantie d’acheminement et tient bien la charge tant que le nombre de destinataires est limité. La principale difficulté du modèle hub-and-spoke est la haute disponibilité qui nécessite la mise en cluster du hub.

Pour conclure, Websphere MQ et Websphere MQ Low Latency reposent sur deux modèles fondamentalement différents : hub-and-spoke et multicast. Si le modèle hub-and-spoke est adapté aux scénarios classiques d’informatique de gestion en offrant des fonctionnalités riches (garantie d’acheminement, etc), il devient inadapté lorsque le nombre de destinataires augmente. A l’inverse, le modèle multicast offre de grandes performances dans les scénarios qui impliquent un très grand nombre de destinataires mais cela se fait au dépend des fonctionnalités comme la garantie d’acheminement qui devient très complexe.

Qu’en est-il de l’offre de Tibco, le principal concurrent de Websphere MQ ? Tibco propose également les deux modèles de middlewares de messages : Tibco Rendezvous (RV) repose sur le modèle multicast et le récent Tibco Enterprise Messaging Service (EMS) repose sur le modèle hub-and-spoke [2]. On notera que :

• Seul Tibco EMS offre un connecteur JMS ; Tibco Rendezvous expose une API Java propriétaire. On peut y voir que Tibco positionne plus EMS pour l’informatique de gestion classique.
• Tibco Rendezvous propose deux mécanismes pour pallier au problème de garantie d’acheminement du modèle multicast : RV Certified Messaging (le message est acheminé au moins une fois, avec un risque de duplication) et RV TX (le message est acheminé exactement une fois, avec une dégradation sensible des performances).

[1] Plus de détails dans Smart Money : IBM WebSphere Products Improve Financial Markets Firms’ Ability to Manage Growing Market Data Volumes and Speeds.
[2] Voir Tibco RV vs Tibco EMS by Narendra Naidu.

Spring 2.5 released

Spring 2.5 vient d’être releasé et apporte son lot de nouveautés que vous pouvez consulter ici.

InfoQ se lance pour l’occasion dans un découverte des apports de cette version 2.5 : http://www.infoq.com/articles/spring-2.5-part-1.

Nous avions déjà traité des nouveautés de Spring 2.5 dans notre revue de presse de la semaine dernière :

• Réduction et simplification des configurations XML
  • Java Config
  • XML namespaces « jms » et « context »
  • etc
• Componentisation avec OSGI
• Unification des accès aux systemes externes avec JCA 1.5
• Support officiel de Websphere

Comparing JVM Web Frameworks Videocast

Dans la revue de presse précédente, nous parlions de la comparaison des principaux framework de présentation effectuée par Matt Raible. JavaZone vient de publier une vidéo de cette même analyse dans laquelle les frameworks Jsf, Spring MVC, Struts 2, Stripes, Tapesty, Wicket sont détaillés sous deux angles de vue principaux : un premier aspect « technique » étudiant les fonctionnalités offertes par chacun des framework et un aspect « communautaire » mesurant l’activité de chacun.

• Consulter la vidéo
• Récupérer les slides de la présentation
• Xebia Web Framework Contest

Actualité éditeurs / SSII

• Weblogic Server 10.3

Le coin de la technique

• Release de Seam 2.0
• Un vent de Websphere 7 chez IBM
• Apache Wicket 1.3.0-rc1 is released!

Actualité éditeurs / SSII

Weblogic Server 10.3

Cette nouvelle mouture du serveur d’application de BEA reste conforme aux spécifications J2EE 5 tout en ajoutant le support de Java SE 6. Donc peu de nouveautés technico-fonctionnelles, l’accent a été mis sur les performances. Cette version vient de sortir en mode ‘Tech Preview‘. La version 10.3 deviendrat-elle une version aussi performante et stable qu’est (ou fût) la version 8.1SP5+ ?

Le coin de la technique

Release de Seam 2.0

Pour rappel, Seam permet de mettre en des applications par le biais des technologies JSF, EJB 3, AJAX, BPM… Sa nouvelle version arrive avec ses lots de corrections et d’améliorations parmi lesquelles :

• possibilité d’écrire des composants Seam en Groovy
• intégration de GWT pour le rendering de page ou bien encore inclure des composants GWT dans une page JSF
• les composants Seam peuvent faire l’office de Web Service
• intégration de Hibernate Search
• syntaxe des EL améliorée

Un vent de Websphere 7 chez IBM

IBM nous prépare à Websphere 7, ses EJB3, sa persistance JPA et ses web services JAX-WS 2.0 en publiant le redbook Designing and Coding Applications for Performance and Scalability in WebSphere Application Server et en annonçant Rational Application Developer 7.5 Open Beta.

RAD 7.5, dont la beta sera disponible mi-décembre, apporte le support de support de Java EE 5 (EJB 3, JPA, JAX-WS, etc). La sortie de cette version, en avance sur Websphere 7, rassurera les clients RAD qui avaient été déçus par le décalage de plusieurs mois entre la sortie de WAS 6.1 et celle de RAD 7 (la v7 de RAD apportait le support de Java 5 et le WAS 6.1 runtime environment).

Designing and Coding Applications for Performance and Scalability in WebSphere Application Server est un RedBook de transition de l’ère des EJB 2.1 vers les nouveaux EJB 3.0 qui seront supportés par le futur Websphere 7 :

On y retrouve hélas quelques exemples légèrement défraîchis qui font penser à des copier/coller des redbooks précédents :

• Le chapitre sur l’utilisation des mécanismes de synchronisation (p99) mériteraient d’être réécrit en s’inspirant du très intéressant Google Tech Talk Advanced Topics in Programming Languages: The Java Memory Model de Jeremy Manson qui nous expliquent comment les blocs synchronized devraient être remplacé par les verrous introduis avec la librairie java.util.concurrent.locks
• Les exemples qui utilisent Vector et Hashtable pourraient avantageusement être mis à jour pour parler de List/ArrayList et de Map/HashMap
• Le paragraphe sur Struts et ses ActionForm pourrait être remplacé par son équivalent avec Struts2 ou être supprimé si IBM ne souhaite pas mettre en avant Struts2.

A côté de ces anachronismes mineurs, IBM nous livre les grands axes de la stratégie Websphere :

• SCA/SDO sont toujours des technologies clefs. Ce redbook nous explique avec clarté et raison leur rôle et leur position par rapport à EJB3/JPA : If you are developing a traditional (non SOA) application and only have relational data and are only developing in Java, then EJB 3.0 is a good choice. (p 449).
• Java Connector Architecture (JCA) est désormais la technologie standard et unifiée pour accéder aux Enterprise Information Systems (EIS) comme CICS et IMS dont les connecteurs Java propriétaires ont été remplacés par des Resources Adapter JCA [1]. Le support de l’API JCA permet une intégration élégante à SpringFramework [2].
• EJB3, JPA et JAX-WS sont les successeurs respectifs d’EJB 2.1, d’EJB CMP et de JAX-RPC ; ils sont disponibles avec WAS 6.1 sous forme de feature pack additionnels [3] ; Websphere 7 les embarquera en standard. Ce redbook sera une bonne introduction pour ceux qui n’ont pas encore eu le temps de découvrir ces nouvelles technologies.

Pour conclure, RAD 7.5 et ce redbook sont principalement des previews des technologies JavaEE 5 (EJB3, JPA, JAX-WS, etc) que nous attendons avec impatience et qui seront disponible avec Websphere 7.

D’ici à y voir les prémices d’une grande opération de teasing pour préparer l’imminente arrivée de Websphere 7 …

[1] Voir IMS TM Resource Adapter et CICS Transaction Gateway.
[2] Voir Access CICS applications with Spring par Thierry Templier pour JavaWorld.
[3] Voir WebSphere® Application Server Version 6.1 Feature Pack for EJB 3.0 et Feature Pack for Web Services for WebSphere Application Server V6.1

Apache Wicket 1.3.0-rc1 is released!

Le projet Wicket avance et entre en release candidates. Cela signifie que seulement des corrections de bugs seront faites jusque la sortie finale de la version 1.3.
Au programme de cette release :

• un guide de migration à partir de la version 1.2 : l’API a évolué/changé et donc pas mal de changements sont à prévoir.
• beaucoup de bugs ont été corrigés, et les évolutions sont nombreuses. Voici la liste.

Actualité éditeurs / SSII

Agilité

• Intégration continue – taux de couverture de code
• Estimations Agiles

Le coin de la technique

• Continuum 1.1 Beta 4 et Archiva 1.0 Beta 3
• RIA – qui utilise Flex aujourd’hui ?
• Buildr premier projet Ruby à rejoindre l’incubateur de la fondation Apache
• Encodage des messages avec Websphere MQ

Agilité

Intégration continue – taux de couverture de code

Un serveur d’intégration continue qui déroule les tests unitaires du projet, c’est très bien. Le serveur donne le nombre de tests unitaires qui sont passés, le nombre de tests échoués, notifie les intervenants du projet, et génère des rapports et des graphiques à partir des résultats donnés par JUnit. Mais il manque tout de même une information importante… Quel est le pourcentage de code couvert par les tests unitaires ?

Clover, après son récent rachat par Atlassian, vient de sortir en version 2 avec son lot de nouveautés :

• les rapports présentent désormais à la fois le taux de couverture des tests et le résultat des tests,
• on connaît couverture de code par test,
• le module d’affichage des sources en HTML a été amélioré

Clover est un outil commercial nécessitant une licence payante. Dans le monde opensource, les alternatives se nomment Cobertura et EMMA. Ces outils peuvent être couplés au processus de build (Ant ou Maven), et les résultats peuvent (parfois, suivant les plugins disponibles sur tel ou tel serveur) être affichés dans les rapports du serveur d’intégration continue.

Estimations Agiles

Mike Griffiths, praticien agile ayant participé en 1994 à l’élaboration de la méthode agile DSDM, vient d’initier une série de billets sur les estimations agiles. Dans ce premier billet, il aborde notamment la problématique de l’estimation initiale et commence par rappeler que, approche agile ou non, cet exercice sera toujours difficile du fait du caractère unique de chaque projet. Ainsi, les estimations initiales peuvent considérablement varier par rapport à la réalité comme l’illustre parfaitement bien le désormais célèbre cône d’incertitude de Barry W. Boehm. Avec les méthodologies agiles, les estimations peuvent être affinées après quelques itérations en fonction de la vélocité mesurée du projet. Mais en début de projet, que la méthodologie adoptée soit agile ou traditionnelle, le problème reste le même – estimer le temps nécessaire pour construire un système unique avec une équipe inexpérimentée – et nous devons donc accepter que les approches seront similaires. Mike livre ici quelques techniques qui peuvent vous aider.

Le coin de la technique

Continuum 1.1 Beta 4 et Archiva 1.0 Beta 3

Semaine riche sur la planète Maven avec les annonces, à quelques jours d’intervalle, de Continuum 1.1 Beta 4 et Archiva 1.0 Beta 3. Au menu pour Continuum (non exhaustif) : de nombreuses corrections de bogues, une nouvelle page permettant de visualiser la queue de build et la possibilité d’utiliser des templates de mail configurables. Pour plus de détail, vous pouvez consulter les release notes. Pour Archiva, cette nouvelle beta qui sera a priori l’avant dernière avant la 1.0 finale contient essentiellement des corrections de bogues et quelques améliorations. De même, les release notes vous donneront tous les détails. Félicitations aux équipe Continuum et Maven Archiva !

RIA – qui utilise Flex aujourd’hui ?

Le taux de pénétration d’une technologie est un facteur important (prédominant?) pour les décideurs informatiques. Les deux technologies qui sortent du lot pour développer des applications RIA (Rich Internet Application) sont AJAX (et sa flopé de frameworks) et Flex d’Adobe.

Flex est un environnement de développement permettant de créer des applications RIA multiplateformes, la partie présentation est en Flash (le taux de pénétration du plugin Flash est excellent, proche de 100%, il n’y a donc pas de problème de déploiement), et les applications Flex peuvent consommer des services distants (web services, EJB, etc.). L’environnement de développement FlexBuilder est basé sur Eclipse, mais est payant, tandis qu’Adobe a récemment passé Flex sous licence opensource.

Flex est aujourd’hui utilisé par de nombreuses compagnies, cet article chez InfoQ liste certaines d’entre elles.

Buildr premier projet Ruby à rejoindre l’incubateur de la fondation Apache

Buildr semble être l’alternative à Maven 2 qui monte… Cet article d’InfoQ est un bon point d’entrée pour en apprendre un peu plus sur l’outil.
Buildr est donc un outil de build pour projets Java, mais est codé en Ruby. L’outil semble être plus rapide que Maven 2 et est surtout beaucoup plus facilement extensible.

Il ne sera tout de même pas être évident de déloger Maven 2 mais les deux projets sont désormais sous l’ombrelle de la fondation Apache, nous verrons bien ce qu’il en sortira.

Encodage des messages avec Websphere MQ

La gestion des encodages avec Websphere MQ est toujours un sujet délicat à traiter (EBCDIC, CCSID et autres joyeusetés). IBM met à jour Data Conversion Under WebSphere MQ. C’est l’occasion de rappeler quelques bonnes pratiques pour prévenir ces problèmes auxquels nous ne sommes pas habitués :

• JMS et son pendant XMS (.Net, C et C++) sont les API de prédilection pour accéder à MQ depuis des applications d’informatique de gestion :
  - JMS est une API de beaucoup plus haut niveau que MQI qui est intégrée aux standards et frameworks Java EE (JTA/JCA, Message Driven Bean, Spring JMS, etc).
  - L’implémentation JMS de MQ offre les mêmes performances que l’API « WebSphere MQ classes for Java » (cf JMS Performance with WebSphere MQ for Windows 6.0)
  - Le pooling des ressources JMS par les serveurs d’application, similaire aux DataSource jdbc, apporte simplicité d’exploitation et maîtrise de la montée en charge (cf Using JMS connection pooling with WebSphere Application Server and WebSphere MQ)
  - XMS porte l’API JMS pour les langages C, C++ et .Net (cf XMS Clients), cette nouveauté est une roadmap importante à étudier. La transposition de l’API JMS pour les autres langages de programmation se retrouve aussi dans Tibco Enterprise Messaging Service (EMS).
• Le format MQRFH2, autrefois difficile à manipuler avec les APIs MQI, se généralise avec les APIs JMS/XMS et le support de SOAP (cf. WMQ SOAP Listeners).
• L’utilisation de TextMessage pour transporter des documents XML est le standard de-facto. Cependant, ce choix nécessite de maintenir en synchronisation le ccsid du message MQ et l’attribut « encoding » du document XML (cf MQSeries.net : XML in JMSTextMessage or JMSBytesMessage). Une règle de précaution est de systématiquement utiliser UTF-8, l’encodage par défaut en XML (voir infra).
• UTF-8 est un très bon candidat comme encodage standard d’échange des messages MQ. Il est supporté de façon transparente par les APIs JMS et XMS et est l’encodage par défaut des documents XML.

• L’axe de la maîtrise des risques pour sécuriser le projet.
• L’axe des opportunités pour ne plus voir ce projet comme une contrainte mais comme une occasion d’améliorer sa plate-forme et d’apporter des avantages aux différents acteurs de la DSI (exploitation, études et achats).

 

 
Télécharger le Livre Blanc Migration Websphere 6.1 par Xebia.