Google AppEngine 1.5

Google livre une nouvelle version de sa plateforme de cloud AppEngine. On notera l’arrivée d’une nouvelle API de file de traitement en mode Producteur/Consommateur, les Pull Queues. Les consommateurs peuvent être des composants faisant partie de votre application AppEngine ou externes ; le service fournit une API REST et des librairies pour Java, Python, .NET, PHP et Ruby.

Cette version introduit également un nouveau type d’instance en liaison directe avec la nouvelle API de file de traitement, les instances « Backend ». Les traitements effectués sur une instance de type Backend ne sont pas soumis aux restrictions standards (comme par exemple la limite de durée à 30 secondes). Il est également possible de choisir une classe parmi 4 proposées pour ces instances ; ce qui offre plus de contrôle sur le dimensionnement de l’architecture de déploiement. Une des autres options de configuration est le mode de rétention de l’instance Backend : Resident, son arrêt et son démarrage sont alors manuels ; ou Dynamic, les instances sont alors automatiquement démarrées pour traiter les demandes et sont arrêtées après 30 secondes d’inactivité.

Voici un tableau récapitulatif, pour vous donner une idée des tarifs de ces Backends:

Autre annonce importante, la technologie quittera le statut de preview lors du 2ème semestre de cette année. Le programme « AppEngine for Business » s’arrête et nombre des fonctionnalités est ou sera réintégré dans AppEngine comme : les bases SQL hébergées, les engagements sur les niveaux de service, l’utilisation de SSL avec des noms de domaine externes, etc. Une première version du SLA est consultable ici. Autre modification importante, le modèle tarifaire évoluera également : certaines APIs, dont la consommation est évaluée en temps CPU, seront dorénavant facturées au nombre d’appels. Tout cela conforte l’engagement de Google pour cette technologie.

Rapprochement Android / GWT / AppEngine

La future version 2.4 du plugin Eclipse de Google (actuellement en bêta) permettra un rapprochement entre les technologies Android, AppEngine et GWT. Le plugin autorisera la création de projets « connectés », et générera automatiquement le code de plomberie technique nécessaire pour effectuer les appels aux services GWT depuis une application Android.

Il y a également des nouveautés du côté de l’API Cloud to Device (CD2M) qui est encore dans l’incubateur Google. Sa mise en œuvre sera simplifiée par une intégration au sein même de Google AppEngine. Pour rappel, le but de l’API Cloud to Device est de remplacer les mécanismes de polling que l’on pourrait développer directement au niveau applicatif par un système de notification push. L’intégration de cette fonctionnalité directement au cœur du système permet de mutualiser les notifications, et rend l’ensemble du service plus efficace et moins consommateur en bande passante et en énergie. Un exemple concret d’utilisation est l’extension ChromeToPhone qui permet de diriger vers votre Smartphone Android une page en cours de visualisation dans Chrome.

Avec ce rapprochement, c’est tout un éco-système autour de Google AppEngine qui se dessine peu à peu.

Chrome / HTML 5

Le navigateur de Google se voit doté de fonctionnalités supplémentaires intéressantes comme la reconnaissance vocale. Autre annonce marquante, l’équipe de développement signale que l’optimisation des performances reste un chantier de premier plan. Toutefois, le focus sera mis sur l’accélération matérielle et non plus sur le moteur JavaScript. Enfin, on peut rappeler le lancement mondial du Chrome Web Store accessible dans plus d’une quarantaine de langues.

Nouvelles versions Android

Cette conférence a été l’occasion pour Google d’annoncer 2 versions majeures de la plateforme Android. La version HoneyComb 3.1 et la très attendue version 4 (?!) Ice Cream Sandwich qui va permettre de regrouper la version téléphone et la déclinaison tablette du système d’exploitation. La plus importante nouveauté de ces versions est sans doute l’API Open Accessory qui permet aux appareils Android d’utiliser les appareils connectés via USB ou de se comporter comme un hôte USB (le mode hôte USB n’est accessible que pour HoneyComb).

Android@Home

Le framework Android@Home permet au système d’exploitation d’être utilisé pour la domotique. Votre appareil Android devient la commande centrale pour piloter les appareils sans fil de votre domicile ; les équipes ont également développé un nouveau protocole pour les appareils sans fil non connectés au réseau Wifi. Une démonstration du projet Tungsten permet par exemple de diffuser en streaming de la musique dans l’ensemble de votre domicile.

Google Storage

Google Storage, le service de stockage en ligne de haute disponibilité et accessible via une API REST. Bien qu’encore dans l’incubateur, il est maintenant accessible à tous, dispose d’un quota gratuit d’utilisation (jusqu’à la fin de l’année) et propose 2 zones géographiques de stockage les états-unis et l’Europe.

Chromebooks

Google a annoncé la prochaine sortie de 2 nouveaux « NetBook » utilisant le système d’exploitation Chrome OS. L’originalité vient l’offre de commercialisation puisqu’ils seront disponible à la vente de manière standard, mais aussi dans le cadre d’une souscription étudiante ou professionnelle pour respectivement $20 et $30. L’offre inclue également la mise à jour matérielle.

Le mot de la fin … en attendant Google I/O 2012

C’est ici que s’achève notre petit tour d’horizon de cette très généreuse conférence. Avec plus de 100 sessions réparties sur 2 jours, il y a fort à parier que nous avons « oublié » d’aborder certains sujets. Mais, j’espère vous avoir donné l’envie de parcourir plus en détail les annonces, vidéos et autres matériaux de cette conférence.

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

Actualité éditeurs / SSIIest

• Ehcache Search
• Chez Oracle: Netbeans 7, Java FX 2…

Agilité

• Continuous Delivery selon Martin Fowler et Jez Humble

Le coin de la technique

• jBPM 5 est de sortie
• Google Web Toolkit 2.2

Actualité éditeurs / SSII

Ehcache Search

La nouvelle version Ehcache 2.4 est sortie la semaine dernière, elle apporte une nouvelle fonctionnalité importante, Search, qui améliore les mécanismes de recherche. Elle offre entre autre une API fluent (Désignation chainée en français ?) qu’on retrouve souvent dans les API de recherche de ce type. Voici un exemple:

Results results = cache.createQuery().includeKeys().addCriteria(age.eq(32).and(gender.eq(“male”))).execute();

Nous voici donc avec un nouveau query language, EQL, qui rassemble toutes les fonctionnalités classiques de requêtage: les critères ( eq , lt, like, ilike, between…), les tris descendant/ascendant et les agrégateurs ( min , max, avg, sum, count…). Par contre il n’y a pas de possibilités de jointure.

Deux approches ont été utilisées selon qu’on soit en mode standalone ou distribué. En standalone la recherche se fait simplement en parcourant l’ensemble des éléments. Même si il y a beaucoup d’éléments le fait d’être en local permet d’avoir un temps de réponse très bon (d’après Ehcache, 1 million d’entrée en moins d’une seconde environ). Par contre le mode distribué, qui ne sera disponible qu’avec la future release Terracota 3.5, s’appuie sur des indexes et est par conséquent beaucoup plus rapide sur des tailles de cache de plusieurs giga voire téra octets. Dans ce mode on peut doubler le volume en gardant quasiment le même temps de réponse si on ajoute tout simplement un cache. A noter que la mise à jour des indexes est asynchrone.

Sans être révolutionnaire voici une nouvelle fonctionnalité assez utile pour un outil déjà appréciable par sa simplicité.

Chez Oracle: Netbeans 7, Java FX 2…

Attention, cette info est réservée à un public averti. Aux aventuriers du code. A ceux qui aiment prendre des risques avec leurs sources en utilisant un IDE encore en bêta. En effet, la bêta 2 de Netbeans 7 vient de sortir. Et elle sait nous mettre l’eau à la bouche ! On ne sera pas surpris d’apprendre que le support des produits Oracle comme WebLogic ou la base de donnée a été amélioré, mais c’est surtout le support de Java 7 qui nous fait saliver: découvrez les possibilités de refactoring dans les release notes.
Toujours concernant Netbeans, certains d’entre nous avaient été déçus de l’annonce de l’arrêt du développement du plugin Ruby. Rassurez-vous, la newsletter hebdomadaire de Netbeans annonce que Tom Enebo et la communauté comptent continuer à le développer. C’est une bonne nouvelle pour les amateurs de multilinguisme.

Pour continuer sur Oracle, Gerbrand van Dieijen, notre collègue Xebian néerlandais, nous livre quelques informations glanées lors d’un JUG. Les voici:

• comme prévu, le langage de script JavaFX est bien abandonné. Java FX 2 sera une librairie jar.
• il sera possible de mixer Swing et JavaFX2…
• … mais Swing est en mode maintenance. Comprendre « ne plus attendre d’innovations de ce coté ». Aie…

Faut-il s’attendre à ce que Java FX2 soit en fait Swing 2 ? Nous verrons mais en attendant, contrairement à d’autres, nous avons du mal à nous enthousiasmer pour un simple composant TableView qui était absent de la librairie jusqu’ici (bien que gérer correctement une table soit beaucoup plus dur qu’il n’y parait !).

Agilité

Continuous Delivery selon Martin Fowler et Jez Humble

Martin Fowler et Jez Humble (product manager de Go chez ThoughtWorks) ont présenté à QCon 2010 leur vision du Continuous Delivery. Nous retiendrons :

Qu’est ce que le « Continuous Delivery »

L’objectif du « Continuous Delivery » est d’accélérer le rythme de release des logiciels. L’Agilité et le « Continuous Integration » ont traité les périmètres des équipes fonctionnelles et de développement ; « Continuous Delivery » prolonge cette dynamique aux équipes de production.

Les bénéfices majeurs sont :

• Valider plus rapidement le « business plan » en recueillant plus rapidement les retours d’expérience des utilisateurs,
• Réduire les risques de mise en production (et donc des coûts) par rapport aux approches « Big Bang » grâce à des incréments plus petits, plus fréquents et automatisés.

Pour atteindre cet objectif, « Continuous Delivery » propose d’automatiser les phases de « build-deploy-test-release » en un « Build Pipeline ». Cela comporte l’automatisation de tests intégrés (User Acceptance Tests, Performance Tests, etc), la gestion des configurations, des environnements et des données ainsi que l’automatisation des déploiements.

Plus de détails dans InformIT – Continuous Delivery: The Value Proposition.

« Continuous Delivery » versus « Continuous Deployment »

« Continuous Delivery » et « Continuous Deployment » diffèrent par le fait que « Continous Delivery » laisse au business le choix du rythme des releases. Le logiciel doit toujours être releasable mais c’est le business qui choisit la date de la release (e.g. un éditeur limite le nombre de release à supporter, les équipes ne sont pas forcément disponibles pour supporter une mise en production, etc). A l’inverse, « Continuous Deployment » promeut la mise en production permanente ; chaque commit est l’occasion d’une release, il s’agit de « continuous release ».

Plus de détails dans Jez Humble – Continuous Delivery vs Continuous Deployment.

Les enjeux et pièges de l’adoption du « Continuous Delivery »

Le principal enjeu du « Continuous Delivery » est culturel : il s’agit de faire travailler ensemble les équipes de développement, de validation (QA) et d’exploitation.

Le premier piège de l’adoption de « Continuous Deployment » est le même que pour l’adoption de l’Agilité : l’adoption en mode « Big Bang ». Il faut à la place procéder incrémentalement, automatiser les étapes une par une en identifiant à chaque fois l’action la plus bénéfique.

« Continuous Delivery », « Feature Branching » et « Feature Toggle Pattern »

Martin Fowler et Jez Humble recommandent le développement sur le ‘trunk’ plutôt qu’une approche de « feature branching » à cause des difficultés de merge.

Tant qu’une fonctionnalité n’est pas complètement « done » ou que le business n’a pas décidé de son activation définitive, on recourra à un pattern de « feature toggle » qui permet d’activer/désactiver par configuration la fonctionnalité. Cette approche permet notamment le canary releasing et le A/B testing.

Plus de détails sur Martin Fowler’s Bliki : Feature Toggle.

Les outils pour le « Continous Delivery »

Il y a peu d’outils à part Go de Toughtworks. Les serveurs d’intégration continue commencent à s’intéresser au sujet (cf Atlassian Bamboo 3). Les produits Open Source comme Maven ou Hudson n’ont pas de proposition pour le moment.

Le coin de la technique

jBPM 5 est de sortie

La version 5 de jBPM est sortie il y a peu de temps. Pour mémoire, jBPM est une librairie open-source faite par JBoss pour faire du BPM (Business Process Management). On se rappellera que le projet a connu quelques heurts dont le départ de ses 2 principaux membres: Tom Baeyens et Joram Barrez avaient abandonné le navire pour aller faire Activiti sous la houlette de Alfresco. La 1ere version d’Activiti est d’ailleurs sortie récemment, avec le numéro de version 5, sans doutes pour concurrencer jBPM 5 !

Tout comme Activiti, ce jBPM 5 voit la généralisation du langage BPMN 2 pour décrire les process. Et par conséquence l’abandon du langage propriétaire JPDL employé jusqu’alors en parallèle de BPMN 1.2.
JBPM 5 résulte d’un merge avec Drools Flow et sort accompagné entre autres de plugin Eclipse, d’une console web de management et d’un Process Repository avec Guvnor.

JBPM 3, lui, a joui et jouira pour encore quelques années d’un support complet de la part de jBoss. De plus, des outils sont prévus pour migrer les process vers jBPM 5. Ce sont les utilisateurs de jBPM 4 qui se retrouvent le bec dans l’eau: il semble que rien n’est prévu pour eux. Toutefois il est vrai que cette version n’a jamais été présentée comme étant officiellement supportée, mais plutôt community. Notons tout de même que, comme indiqué en fin de cet article, ce sont les process qui seront migrés, et non les données de ces process.

L’intégration avec Drools sera-t-elle un pari réussi pour JBoss ? En tout cas le projet semble n’avoir pas trop souffert du départ de ses leaders et le combat pour le titre de solution BPM Open Source ne fait que s’engager avec Activiti. Profitons en pour noter que les français de Bonitasoft proposent eux aussi une solution concurrente.

Google Web Toolkit 2.2

La version 2.2 du framework GWT est sortie la semaine passée. Cette sortie, en plus d’un lot de correctifs, s’accompagne d’une mise à jour des outils de développement.

Le plugin GPE (Google Plugin for Eclipse) intègre donc en standard une version light de GWT Designer. GWT Designer est un outil WYSIWYG pour la création d’interfaces GWT. La version allégée n’inclut pas le support des librairies GWT-Ext, GXT ou SmartGWT. Elle offre moins d’options de configuration, et n’inclut pas les assistants et vérificateurs de la version complète pour s’appuyer sur ceux de GPE. La version complète reste toujours disponible gratuitement.

Autre nouveauté, le framework inclut un support expérimentale pour les éléments HTML 5 Canvas, Video et Audio. Les API sont encore susceptibles d’évoluer, mais l’équipe de développement pense qu’elles sont suffisamment « stables » pour être publiées. Et une démo et son code source sont accessibles ici.

On notera également l’ajout des fonctionnalités de tri et de dimensionnement des colonnes sur le composant CellTable.

Enfin, cette version déprécie le support de Java 1.5. Noter que l’équipe s’engage à supporter Java 1.5 au moins jusqu’à la prochaine release. Toutefois, la migration vers une version plus récente du runtime est recommandé.

Comment choisir ces fameux Frameworks Web qui sont, et c’est le moins que l’on puisse dire, assez nombreux. Et bien tout d’abord, il va falloir restreindre cette liste à quelques Frameworks et, pour chacun d’entre eux, prototyper une application. A partir de ces prototypes, il sera alors possible de créer une matrice comprenant différents critères qui seront notés pour chaque Frameworks. De là, on pourra faire ressortir les meilleurs prétendants, un petit document et faire nos recommandations. C’est ce qu’a fait Matt Raible durant cette présentation et voici ses résultats !

Matt fait un petit rappel sur les facteurs clés qui nous permettaient de choisir un Framework Web en 2007 (de son expérience) :

• composant, requête ou RIA,
• facilité de développement,
• communauté autour du Framework,
• roadmap et futur du Framework,
• maintenance,
• fonctionnalités.

Aujourd’hui, nous en demandons beaucoup plus à nos Frameworks Web et, pour Matt, nous passons de 6 à 20 ! Avec un peu d’exagération sur cette fulgurante croissance car certains points faisaient déjà parti de nos préoccupations en 2007 ; de là à dire que ce sont de nouveaux points… En tout cas, les voici au complet :

• productivité du développeur,
• perception du développeur,
• courbe d’apprentissage,
• santé du Framework,
• disponibilité des développeurs (sur le marché),
• offres d’emploi,
• templating,
• composants,
• ajax,
• plugins ou add-ons,
• scalabilité,
• support pour les tests,
• i18n et l10n,
• validation,
• support du multi-langage (groovy, scala…),
• qualité de la documentation / tutoriaux,
• publications,
• support de REST,
• support mobile,
• et degré de risque.

Bien sûr, nous pouvons remettre en cause certains points de cette liste et passer plusieurs journées à en débattre mais le débat n’est pas là. Matt assume que les choix qui sont fait sont les siens et il nous invite à participer pour ajouter des éléments à la liste ou lui indiquer pourquoi il se trompe sur telle ou telle appréciation. L’idée est ici de donner une base solide afin de pouvoir comparer sur plusieurs points importants de nos projets d’entreprise ces fameux innombrables Frameworks Web.

Roulement de tambour… voici la matrice ! (google spreadsheet)

Les gagnants de ce « concours » sont :

• Spring MVC,
• GWT,
• Ruby on Rails (non JVM mais non exclu car très présent sur le marché),
• Grails,
• Wicket.

Vient ensuite une partie avantages / inconvénients pour chacun d’eux. Cette partie est à prendre avec des pincettes car les inconvénients relevés sont souvent surmontables (certains sont même juste des comportements par défaut modifiable par configuration !) mais encore une fois cela donne un overview de ce que font ou ne font pas ces Frameworks :

• Spring MVC : configuration simple par conventions et annotations, intégration de plusieurs formats d’affichage (JSP, JSTL, FreeMarker, JSON, PDF…) et excellent support de REST mais pas de rechargement à chaud par défaut (toutefois possible avec JRebel ou Spring Roo), projet non ouvert à la communauté pour contribution (SpringSource mandatory) et pas de librairie ajax en bundle (ce qui peut aussi être vu comme un point positif car mise à jour des librairies Javascript non bloquée par le Framework) ;
• GWT : code Java traduit en un Javascript extrêmement optimisé, apprentissage facile et rapide (petit bémol car sur ce point les développeurs Web n’ont pas forcément cette compétence du code Swing-like) et une communauté vibrante mais il faut connaître Java (alors que l’on produit du Javascript), compilation très lente et code difficile à tester ;
• Ruby on Rails : apprentissage rapide pour tout développeur Web, documentation abondante et communauté de passionnés mais moins performant que les autres langages, langage dynamique = plus de tests pour éviter les cast exceptions au runtime et un manque d’outils de développement et de débugger comme dans le monde Java ;
• Grails : transition facile depuis le monde Java, utlise Groovy et nombreux plugins mais Groovy vise directement les développeurs Java (ce qui peut bloquer d’autres développeurs), stack traces affreuses (dans le slide ) et connaissances des sous-modules non nécessaires mais peut aider ;
• Wicket : parfait pour les développeurs Java, binding des pages et des vues et communauté active mais pas ou peu d’offres d’emploi, stateful par défaut et templates HTML juste à côté des classes Java (ce qui ne va pas aider le graphiste).

Pour finir, nous avons droit à quelques jolis graphiques qui nous montre à quelle point Ruby On Rails est très présent au niveau de la communauté mais ainsi en terme d’offres d’emploi.

Matt a insisté sur deux points importants tout d’abord sur le fait que ce sont les développeurs qui devraient choisir leur framework web, plus les développeurs sont heureux, plus ils seront productifs. D’autre part, javascript n’est pas si difficile comme on l’entend souvent de la part des développeurs java, plus on le pratique, plus on l’apprécie, et c’est vital si l’on veut être sérieux pour le développement d’application web.

Cette méthode peut être appliqué dans votre entreprise pour choisir votre framework web :

1. priorisez les fonctionnalités importantes de votre application
2. sélectionnez ensuite 3 ou 4 Frameworks pour prototyper une application (1 semaine chacun), documentez
3. calculez votre matrice et choisissez !

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

Actualité éditeurs / SSII

• SpringOne2GX 2010 – Les annonces de SpringSource
• Spring ROO 1.1.0
• Sortie de GWT 2.1
• Mozilla Rainbow: enregistrement audio et video dans le browser

Le coin de la technique

• jOOQ 1.4.2, ou comment faire du SQL object

Actualité éditeurs / SSII

SpringOne2GX 2010 – Les annonces de SpringSource

La semaine dernière se tenait la conférence SpringOne 2GX à Chicago. Cette conférence a été le théâtre de nombreuses annonces du duo SpringSource/Vmware. Cette actualité est notamment relayée sur le blog de Rod Johnson.

Code2Cloud

SpringSource présente ici une forge logicielle mettant en oeuvre des services tels que :

• un système de bug tracking basé sur Bugzilla,
• utilisation du système de bug tracking avec Mylyn
• la gestion du code source avec Git, le système de contrôle de version distribué phare du moment,
• de l’intégration continue avec Hudson,
• une intégration de cette nouvelle plateforme avec STS.

Code2Cloud a pour ambition de simplifier la vie des développeurs tout en augmentant leur productivité en leur permettant de se focaliser sur les aspects métiers. Nous ne manquerons pas de suivre l’actualité de ce projet et de l’évaluer dès que la Developer Preview sera disponible. Cette preview ne devrait pas être disponible avant le début 2011 (cf FAQ).
Pour ceux qui se posaient la question, le code de ce projet sera fournit sous les termes de la GPL.

Preview de Spring 3.1

De nombreuses évolutions nous attendent dans la version 3.1 du framework Spring avec au menu :

• le support des servlet 3.0,
• les profils d’environnement permettant de charger des propriétés différentes selon que l’on soit sur un environnement de développement, de recette ou de production (ce principe est notamment utilisé dans Grails par exemple),
• une couche d’abstraction pour l’accès aux systèmes de cache (EhCache et GemFire dans un premier temps) et une nouvelle annotation @Cacheable,
• un effort a aussi été réalisé afin de diminuer le nombre de configuration qu’il est possible de réaliser en xml mais pas en utilisant des annotations.

Cette version semble prévue pour le début de l’année 2011 (la roadmap s’arrête actuellement mi-janvier 2011 avec la 3.1M2).

Mais SpringSource annonce de nouveaux projets venant s’ajouter au portefeuille. Les voici:

Spring Data

SpringSource s’attaque avec Spring Data aux bases de données NoSql. L’idée est de fournir un moyen simple d’accès aux bases de données non relationnelles ainsi qu’à des technologies telles que Oracle RAC.
Le projet Spring Data contient de nombreux sous projets permettant notamment l’accès aux bases de données orientées :

• clé-valeur avec le support actuel de Redis, le support de Membase est prévu prochainement,
• document avec le support actuel de CouchDB et de MongoDB,
• colones avec le futur support de HBase, de Hadoop et de Cassandra,
• graphe avec le support de Neo4j.

Le projet propose un système de templating bien connu des développeurs utilisant le framework Spring, pour permettre l’accès à ces bases de données.

Spring Mobile

Ce projet a pour but de fournir un meilleur support pour l’écriture d’applications destinées aux terminaux mobiles. Il repose sur des évolutions de Spring MVC et un partenariat avec Google autour de GWT.

Spring Social

Ce projet doit simplifier les interactions avec des services des réseaux sociaux tels que Twitter, Facebook ou encore LinkedIn. Spring Social fournira :

• un Social Network Template permettant d’interagir avec les réseaux sociaux supportés (LinkedInTemplate, FacebookTemplate …),
• une intégration OAuth pour la gestion des autorisations (une request factory signera les requêtes REST avec les informations d’autorisation OAuth requises)
• le mécanisme nécessaire à l’extraction du Facebook User ID.

SpringSource fournit un exemple d’application permettant de voir comment fonctionne ce nouveau projet.

Spring Payment Services

Ce projet facilitera l’intégration de services de paiement dans les applications Spring. Ce projet réalisé en partenariat avec Visa qui fournit l’expertise métier aux développeurs de SpringSource vise à permettre différents types de paiements (paiement en ligne, paiement mobile, paiement de personne à personne …) via différents fournisseurs de services de paiement (donc pas uniquement Visa). Spring Payment Services étant encore en incubation, il est possible que les API subissent un lifting plus ou moins prononcé. Il est donc préférable de l’utiliser uniquement pour évaluation à l’heure actuelle.

Spring ROO 1.1.0

En restant toujours dans l’écosystème de SpringSource, Spring Roo 1.1.0 vient de sortir après 10 mois de gestation.

Spring Roo est un outil de haute productivité de SpringSource pour développer rapidement des applications Java. Par l’intermédiaire d’un shell, intégré à SpringSource Tool Suite, on peut en quelques commandes construire le squelette d’un projet, avec pojos et classes de tests, puis ajouter ensuite tout un ensemble de fonctionnalités liées à des frameworks tels que Spring MVC, Hibernate, JMS (la liste est longue)… Spring Roo s’appuie massivement sur les annotations et AspectJ pour générer les sources.

Parmi les nouvelles fonctionnalités:

• du reverse engineering incrémental à partir de la base de données. On génère les entités à partir de la base de données. Si le modèle évolue ensuite, les entités seront enrichies mais en gardant les éventuelles modifications que le développeur a pu ajouter depuis la dernière génération.
• des améliorations avec Spring MVC. Spring Roo utilise des fichiers JSPX (JSP XML compatible) au lieu de JSP ce qui lui permet à présent de pouvoir faire des aller-retours (round-trip) avec le modèle pour mettre à jour un champ par exemple.
• une meilleure intégration de GWT et de Google App Engine.
• une intégration de Apache Solr, le serveur de recherche derrière Apache Lucene, garantissant la réindéxation des éléments lorsqu’une entité est insérée, mise à jour ou effacée.
• des nouvelles annotations comme @RooJson qui ajoute deux méthodes de sérialisation/désérialisation à votre classe et @RooSerializable pour maintenir le serialVersionUID.

Le projet a lui-même subi des changements au niveau de son développement. Outre le passage à OSGI, ses sources sont maintenant sous Git (tout comme Hibernate récemment) et le projet a un nouveau logo. SpringSource a également mis à jour la plupart des librairies (JPA 2, Spring Framework, Spring Security, Spring Web Flow, Log4j, ActiveMQ, AspectJ et GWT).

Se plaçant comme une alternative à des outils comme Grails pour la haute productivité, il a le très grand avantage d’être full java. Par ailleurs, son shell, avec ses aides et ses complétions, est très réussi. A voir maintenant s’ils arrivent à convaincre plus de projets à migrer sur cette solution. Pour ceux qui aimerait en savoir plus, Spring Roo in Action va paraître chez Manning au printemps 2011.

Sortie de GWT 2.1

Après des mois d’attente, nous avons accueilli avec joie la sortie de GWT-2.1 jeudi dernier. Cette version arrive avec beaucoup de nouveautés; au menu un framework Editor, RequestFactory, MVP, Nouveaux widgets et bien plus. Bruce Johnson et son équipe ont voulu que cette version de GWT soit celle de la maturité. GWT 2.1 a pour objectif de bien répondre aux besoins des applications d’entreprise et les applications de haute scalabilité. C’est la version qui marie RAD, RIA et scalabilité.
Parmi les nouveautés on trouve:

• le framework Editor: Ce nouveau framework assure le binding entre les vues et le modèle. Vous aurez moins de code à écrire afin de peupler vos interfaces graphiques avec le contenu de vos POJO et vice versa.
• Le framework RequestFactory : Une alternative de GWT-RPC permettant de créer des applications CRUD. RequestFactory n’a pas pour but de remplacer GWT-RPC, mais plutôt de simplifier la mise en place de la couche d’accès aux données entre le client et le serveur.
• Le framework MVP (Places et activities): Enfin un framework interne qui implémente le pattern Model-View-Presenter en se basant sur les Places (notion de Lieu ou de place dans l’application) et les Activities (une activity c’est ce que peut faire un utilisateur dans une région de la page)
• Data présentation widgets (cell widgets): des composants orientés données ont été ajoutés toujours dans le but de permettre aux applications d’entreprises qui manipulent des millions d’enregistrements de faire des rendus rapides et efficaces (CellList, CellTable, CellTree, CellBrowser…).
• Sécurité: afin d’améliorer la sécurité des applications GWT, une nouvelle librairie voit le jour. Disponible sous le package com.google.gwt.safehtml et autour de l’interface SafeHTML. Cette librairie veut limiter les vulnérabilités liées au XSS (Cross-Site-Scripting).
• Logging coté client : java.util.logging est maintenant émulé dans le GWT-SDK il est désormais possible de créer des logs de la même manière que coté serveur et de les voir affichés dans une popup coté client. Les logs sont configurés non pas via fichier de propriétés mais plutôt via le descripteur .gwt.xml.
• SpeedTracer : passe d’un outil de monitoring côté client à un outil de monitoring client-serveur. Il est possible dorénavant de voir avec la même interface les performances du serveur et du client (s’appuyant entre autre sur Spring Insight).

D’autres nouveautés ont été apportées comme l’amélioration de l’intégration entre m2eclipse et le plugin Eclipse de Google (meilleure reconnaissance du classpath) et une intégration (plutôt moyenne à mon avis) avec Spring-roo…

Mozilla Rainbow: enregistrement audio et video dans le browser

Mozilla a récemment annoncé une nouvelle extension pour Firefox: Rainbow. Son rôle est de permettre au browser d’accéder aux capacités d’enregistrement audio & vidéo des ordinateurs et de les mettre à disposition à travers une API Javascript. Pour ce faire, Mozilla s’appuie sur des librairies cross-platform comme:

• Libvidcap pour l’accès au hardware vidéo
• Portaudio pour le hardware audio
• Vorbis et Theora pour l’encodage des flux audio et vidéo capturés

Mais l’intérêt de cette news réside peu dans l’extension elle-même qui est encore très loin d’être exploitable (ne fonctionne que sous Mac OS pour l’instant). Elle se situe plutôt dans la perspective apportée: il semble que l’on se dirige de plus en plus vers un monde où le navigateur aura accès aux matériels des machines. Lors d’un récent XKE (notre journée mensuelle d’échange) nous avions parlé de HTML5 vs Flash et l’un des problèmes que nous avions évoqué était que la technologie pour faire ne serait-ce qu’un simple chat vidéo en simple HTML/Javascript n’existait pas encore. Il semble maintenant que l’on s’en rapproche de plus en plus! Alors certes, ce n’est pas pour aujourd’hui… Ce n’est pas non plus pour demain car pour obtenir une API standard à plusieurs navigateurs, il faudra que les participants se mettent d’accord: Ericsson, par exemple, a commencé à jouer avec la balise device qui n’est pas encore standardisée et sur laquelle travaille le Whatwg, alors que l’implémentation de Mozilla semble ne pas passer par cette balise (du moins pour l’instant). Bref, on a le temps de voir arriver toutes ces bonnes choses, mais autant s’y préparer dès maintenant: le futur réside dans le navigateur !

Le coin de la technique

jOOQ 1.4.2, ou comment faire du SQL object

jOOQ, pour Java Oriented Object Querying, est un framework de persistance qui veut se démarquer des autres. En effet, son créateur Lukas Eder est parti de deux constats:

• le modèle relationnel est aujourd’hui quasi omniprésent dans les SI. De plus, le langage SQL nous permet de répondre à toutes nos attentes en terme d’interrogation de bases de données,
• une bonne partie des projets sur lesquels nous travaillons possèdent une base de données legacy dont il n’est souvent pas possible d’apporter quelconques modifications.

Mais alors pourquoi utiliser des outils de persistance complexes rajoutant une abstraction au SQL ? Question tout à fait légitime et pleine de bons sens.

Si vous êtes dans ce cas de figure, vous pouvez télécharger ce petit outil ici (même si vous ne l’êtes pas, je ne pense pas qu’il y ait d’inconvénient à ce que vous le testiez…). Puis, générez vos entités à partir de votre modèle relationnel en exécutant un générateur qui va parser votre base et détecter les entités ainsi que leurs relations. Ensuite, il vous suffira de créer vos requêtes en utilisant l’une des deux manières possibles. Voici un exemple pour illustrer ces propos:

Nous souhaitons exécuter la requête suivante avec jOOQ:

-- Select all books by authors born after 1920 from a catalogue:
SELECT *
FROM t_author a
JOIN t_book b ON a.id = b.author_id
WHERE a.year_of_birth > 1920
ORDER BY b.title

• Modèle objet:

// Instanciate your factory using a JDBC connection or datasource,
// and specify the SQL dialect you're using. Of course you can
// have several factories in your application.
Factory create = new Factory(datasource, SQLDialect.MYSQL);
// Create the query using generated, type-safe objects. You could
// write even less code with static imports!
SelectQuery q = create.selectQuery();
q.addFrom(TAuthor.T_AUTHOR);
q.addJoin(TBook.T_BOOK, TAuthor.ID, TBook.AUTHOR_ID);
q.addCompareCondition(TAuthor.YEAR_OF_BIRTH, 1920, Comparator.GREATER);
q.addOrderBy(TBook.TITLE);

• DSL SQL:

// Do it all "on one line".
SelectQuery q = create.select()
.from(T_AUTHOR)
.join(T_BOOK).on(TAuthor.ID.equal(TBook.AUTHOR_ID))
.where(TAuthor.YEAR_OF_BIRTH.greaterThan(1920))
.orderBy(TBook.TITLE).getQuery();

Ensuite, vous pourrez exécuter et récupérer vos résultats mapper sur vos objets grâce à jOOQ comme suit:

// Similar query, but don't join books to authors.
// Note the generic type that is added to your query:
SimpleSelectQuery q = create.select(T_AUTHOR)
.where(TAuthor.YEAR_OF_BIRTH.greaterThan(1920))
.orderBy(TAuthor.LAST_NAME).getQuery();
// When executing this query, also Result holds a generic type:
q.execute();
Result result = q.getResult();
for (TAuthorRecord record : result) {
    // With generate record classes, you can use generated getters and setters:
    String firstName = record.getFirstName();
    String lastName = record.getLastName();
    System.out.println("Author : " + firstName + " " + lastName + " wrote : ");
    // Use generated foreign key navigation methods
    for (TBookRecord book : record.getTBooks()) {
        System.out.println("  Book : " + book.getTitle());
    }
}

Enfin, l’API fournie permet d’exécuter des opérations de CRUD assez facilement:

// Create a new record and insert it into the database
TBookRecord book = create.newRecord(T_BOOK);
book.setTitle("My first book");
book.store();
// Update it with new values
book.setPublishedIn(2010);
book.store();
// Delete it
book.delete();

Vous trouverez tous les exemples cités ci-dessus sur le site officiel.

Plutôt sympa, ce framework démarre d’une idée intéressante en se situant entre les requêtes sql brutes via jdbc mais qui sont difficiles à maintenir et les frameworks tels que Hibernate ou iBatis, un peu trop haut niveau. Pour ne rien gâcher la roadmap du projet est visible ainsi que les tickets de bugs et l’avancement de chaque sprint, et bien que l’auteur soit seul sur ce projet, il le fait évoluer à un rythme soutenu.

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

Actualité éditeurs / SSII

• La diffusion des produits d’Instantiations par Google
• Avec BigMemory Terracotta se dote d’une mémoire d’éléphant
• PostgreSQL: version 9.0 finale

Agilité

• Les problèmes d’estimation de la valeur métier

SOA

• Sortie de Mule ESB 3 GA

Actualité éditeurs / SSII

La diffusion des produits d’Instantiations par Google

Dans les semaines qui ont suivi le rachat de la société Instantiations par Google début août, les produits phares de la start-up, comme GWT Designer, n’étaient plus accessibles. Comme on s’en doutait, Google vient de remettre à disposition ces outils, au détail prêt qu’ils sont désormais gratuits. On retrouve les plugins Eclipse suivant :

• GWT Designer

Ce plugin est un ensemble de fonctionnalités autour du framework Google Web Toolkit. Parmi ses avantages, on retrouve principalement le designer visuel permettant de concevoir rapidement des interfaces ou d’effectuer du reverse engineering sur un code existant et la génération automatique des services RPC.
L’acquisition de ce plugin marque un renforcement de l’offre RIA de Google, qui annonce travailler sur la fusion de GWT Designer avec GPE (Google Plugin Eclipse) et sur la prise en charge de l’UIBinding.

• CodePro AnalytiX

Ce plugin est un outil collaboratif autour de la qualité du code Java contenant pas moins de 700 métriques. Il propose des fonctions comme l’audit de code, la couverture de code, l’analyse des dépendances.

• WindowBuilder Pro

Ce plugin est un designer visuel permettant de concevoir rapidement des interfaces graphiques dans diverses technologies comme Swing, SWT, RCP, XWT et GWT. Au même titre que GWT Designer, l’outil permet également d’effectuer du Reverse Engineering sur du code existant (écrit à la main ou généré par des outils comme JBuilder, NetBeans, etc.)

• WindowTester Pro

Ce plugin permet de réaliser des tests d’interfaces pour les frameworks SWT et Swing.

Avec BigMemory Terracotta se dote d’une mémoire d’éléphant

La semaine dernière Terracotta a annoncé la sortie de BigMemory en version bêta. Cette nouvelle solution, qui se présente sous la forme d’un plugin d’Ehcache, permet d’utiliser un cache pouvant atteindre plusieurs centaines de Go d’espace (la compagnie annonce 350Go) sans souffrir des pauses dues au garbage collector.

Ce tour de force est possible en soustrayant cet espace à la heap de la jvm, Ehcache désigne cet espace off-heap store. Il s’agit d’une énorme HashMap qui n’est limitée que par la RAM du serveur. De plus la configuration semble assez facile, juste quelques lignes à ajouter dans la configuration de Ehcache. Bien sûr pour dépasser les 2 ou 4 Go il faudra un OS 64bits. Il est à noter par ailleurs que cette solution est 100% java. Parmi les points forts mis en avant:

• d’un point de vue logistique, concentrer la gestion du cache sur une seule machine peut être plus simple à gérer qu’avec un cache distribué.
• les projets confrontés à la taille maximum de leur JVM dépensent parfois beaucoup d’énergie afin de trouver les bonnes options pour limiter le garbage collector ou à trouver des dérivatifs, ici la question ne se pose plus.
• les temps de réponse sont quasi constants, en partie parce que le garbage collector n’est pas concerné, ce qui permet d’avoir un SLA prédictible. Le benchmark d’Ehcache est assez évocateur à ce sujet.

Parmi les bémols qui se sont exprimés, le billet sur ServerSide de Joseph Ottinger, employé de Gigaspaces (donc pas 100% objectif) et la discussion qu’il a engendré sont très instructifs. De façon abrégée, les points relevés:

• BigMemory n’est qu’une HashMap, lorsqu’on manipule autant de données il peut être nécessaire d’avoir un mécanisme de requête sur les clés.
• Le garbage collector a ses vertus, lorsqu’il y a un fort ratio d’écritures et que les tailles des objets varient beaucoup on peut se trouver dans une situation où l’espace est très fragmenté ce qui ralentira les écritures.
• Le monitoring de ce cache nécessitera d’autres outils que ceux utilisés habituellement pour surveiller l’efficacité du cache, rendant plus complexe leur utilisation.

PostgreSQL: version 9.0 finale

En version bêta depuis avril, PostgreSQL débarque dans sa version finale 9.0. Souvent considérée comme « l’autre base de donnée open source », PostgreSQL dispose pourtant de nombreuses qualités, que vient renforcer cette nouvelle version. Pendant la phase bêta, PostgreSQLFR nous avait décrit en détails les 2 principales nouveautés, orientées réplication et répartition de la charge en lecture.

• Le hot Standby: des bases secondaires sont disponibles en lecture seule. La charge peut donc être répartie entre les bases.
• La streaming replication: les bases secondaires sont maintenues à jour en temps réel, grâce aux logs de la base principale.

Ces 2 fonctionnalités justifient à elles seules le passage à la version supérieure. Il y en a bien sûr de nombreuses autres parmi lesquelles:

• des améliorations dans la gestion des droits qui peuvent être appliqués:
  • sur les blobs
  • en groupe sur les schémas
• le support de Python 3 en plus de nombreuses modifications dans la gestion des langages des procédures stockées

La liste complète des ajouts de cette version ainsi que des incompatibilités et informations de migration est disponible dans les release notes. Elle était déjà Open Source friendly, surtout après l’acquisition de MySQL par Oracle, voila que PostgreSQL va à n’en pas douter, avec cette nouvelle version, renforcer sa position dans les entreprises.

Agilité

Les problèmes d’estimation de la valeur métier

Mike Cohn, personnalité éminente dans la sphère agiliste et fondateur de l’Agile Alliance, nous fait part des difficultés à estimer la valeur métier des fonctionnalités développées dans un projet. En général, on estime la valeur métier pour deux raisons:

- Estimer la valeur ajoutée pour la société au cours des sprints (sous forme de graphique)
- Prioriser les user stories de manière plus efficace en comparant la valeur métier au coût de chaque story.

Vu que les user stories sont censés être des petits morceaux de fonctionnalités, il est très difficile de les estimer une à une puisqu’elles sont étroitement liées. Leur estimation s’apparente à la méthode des prix hédoniques (il va falloir ressortir les livres d’économie). Cette méthode est notamment utilisée pour évaluer les biens environnementaux et se base sur le principe que le prix d’un bien dépend de ses caractéristiques et des services qu’il rend.

En faisant des calculs de retour sur investissement, on peut être amené à comparer la valeur métier avec le coût de la story. Or, le coût d’une petite story est souvent dur à déterminer sans prendre en compte les autres stories (ex: une fonctionnalité d’architecture). Cela révèle tout le problème des coûts partagés.

Un autre constat que l’on peut faire est que la valeur de certaines stories peut être considérée comme la valeur totale de la fonctionnalité regroupant des stories. Mike reprend l’exemple de la valeur d’une roue alors que l’on veut fabriquer une voiture: Si on considère que l’on ne veut pas cette voiture sans cette roue, alors la valeur métier de la roue vaut la totalité de la voiture.

Mike nous a exposé tout le problème de l’estimation de la valeur métier sans toutefois nous proposer de méthode miracle. Celui-ci conclut en proposant d’estimer par groupe de user stories afin d’obtenir des valeurs plus réalistes et de permettre d’effectuer des analyses plus significatives.

SOA

Sortie de Mule ESB 3 GA

Le 15 septembre dernier, Ross Masson, CTO de MuleSoft, a officiellement annoncé la sortie de Mule ESB 3 en version GA. Cette 3ème version de l’ESB star, dont la première Milestone remonte à plus d’un an, était très attendue par la communauté Open Source, ainsi que par les utilisateurs, en raison des nombreuses nouveautés qui l’accompagnent.

Parmi les principales fonctionnalités se trouve le tout nouveau module Cloud Connect, qui regroupe un ensemble de connecteurs dédiés à l’intégration avec les applications Cloud, SaaS, ainsi qu’avec les Médias sociaux :

• Connecteurs Cloud clef-en-main dédiés aux fournisseurs de service Cloud populaires tels que Amazon Web Services et Facebook.
• Support natif de REST, facilitant le data-binding et la consomation de services RESTful s’appuyant notamment sur JAX-RS.
• Intégration avec les framework AJAX / JavaScript, offrant la possibilité d’interagir avec les services de l’ESB directement depuis son navigateur à l’aide de connecteurs dédiés à chaque librairie JavaScript (MooTools, ExtJS, JQuery, Dojo).
• Utilisation simplifiée d’ATOM et de RSS, pour la consommation et la création de flux. Il est notamment possible de déclencher des évènements en réaction à un flux.
• Support de JSON, à travers l’utilisation de nouveaux transformateurs.

Cette nouvelle version de Mule ESB introduit également une nouvelle gestion de la configuration basée sur les patterns, simplifiant l’exécution des tâches courantes telles que la publication de service REST, la création de passerelles transactionnelles ou la configuration de proxy de Services Web.

Par ailleurs, Mule ESB 3 supporte maintenant les annotations, simplifiant encore un peu la configuration de ces services. Parmi ces annotations, @Schedule offre la possibilité de planifier simplement l’exécution d’une méthode, et @Transformer, permet d’appliquer des transformations directement sur les messages reçus.

Du côté du déploiement, Mule ESB 3 est maintenant capable de déployer les nouveaux services à chaud, sans avoir à redémarrer son application. Basé sur une architecture OSGI, Mule 3 offre une meilleure isolation, permettant aux services d’être modifiés lors de l’exécution sans impact sur les autres services.

A noter parmi les autres changements :

• Une intégration avec jBPM améliorée permettant d’envoyer ou recevoir des messages vers et à partir d’un processus en cours.
• La possibilité de définir des endpoints dynamiques à l’aide d’expressions (Expression Language).
• Un mécanisme de transformations automatiques, s’appuyant sur les types Mime des messages.

Cette nouvelle version de Mule ESB apporte un très grand nombre de nouveautés, qui ont toutes vocation à en simplifier l’utilisation. La simplicité semble donc être le maître mot de cette 3ème mouture de l’ESB, qui va certainement conserver sa qualification de « couteau suisse » dans le domaine de l’intégration et des architectures SOA. En outre, Mule 3 sait également faire la part belle aux nouvelles exigences des entreprises, en s’ouvrant aux applications Cloud et aux Médias sociaux.

Pour plus d’informations sur Mule ESB 3 :

• Mule 3.0 Getting Started Guide
• Mule 3.0.0 Release Notes

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

Actualité éditeurs / SSII

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

SOA

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

Le coin de la technique

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

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

• Jug Summer Camp 2010 – La Rochelle

Actualité éditeurs / SSII

Cloudbees propose Hudson en Software as a Service

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

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

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

JBoss met en avant les performances de HornetQ

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

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

Les scénarios choisis suivent ces critères:

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

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

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

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

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

SOA

Lancement de vFabric au VMworld 2010 : Spring in the cloud

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

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

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

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

Le coin de la technique

GWT 2.1 sera Maven compliant

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

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

OAuth : pas le protocole d’authentification ultime ?

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

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

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

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

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

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

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

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

• L’annonce officielle

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

Jug Summer Camp 2010 – La Rochelle

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

Actualité éditeurs / SSII

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

RIA

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

Le coin de la technique

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

Actualité éditeurs / SSII

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

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

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

Terracota et Quartz : un premier produit disponible.

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

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

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

Via infoQ

RIA

GWT 2.0 est (enfin) là !

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

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

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

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

La section téléchargement se trouve ici.

Sortie de la release de FlexPMD 1.0

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

• FlexPMD

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

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

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

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

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

Le coin de la technique

Le projet Lambda apparaît au sein d’OpenJDK

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

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

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

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

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

Nouvelle version du meilleur IDE Java du monde…

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

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

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

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

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

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

10 ans d’attente et ECMAScript 5

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

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

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

"use strict;"

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

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

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

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

Nouvelle Milestone d’Eclipse Helios

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

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

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

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

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

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

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

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

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

Actualité éditeurs / SSII

• Terracotta a faim d’Open Source : acquisition de Quartz
• JDK 7, JEE 6, et Maven 3.0 : les annonces de Devoxx

RIA

• GWT version 2.0 RC1

Le coin de la technique

• OWASP Security Top Ten, la cuvée 2010 est arrivée
• Que devient Spring Rich Client ?

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

• Devoxx 2009

Actualité éditeurs / SSII

Terracotta a faim d’Open Source : acquisition de Quartz

Terracotta a annoncé cette semaine l’acquisition de Quartz, le scheduler open source le plus connu est le mieux intégré du marché. Cette acquisition est l’exacte copie de celle opérée cet été avec Ehcache. Tout comme ehCache, Quartz est un projet open source, largement utilisé et bien intégré avec la plupart des solutions stars de leur secteur … et porté par un seul homme (James House). Cible idéale pour Terracotta ? Probablement. Mais il se pose toujours la question suivante : comment Terracotta compte t’il rentabiliser cette acquisition, quand on sait a quel point la monétisation d’un projet open source est difficile. Quoi qu’il arrive, d’ici la prochaine acquisition, Terracotta touche, par ce biais, une communauté de plus en plus large. Cela sera-t-il suffisant pour séduire un éventuel racheteur ?

D’autre part, comme le signale Alex Miller, Quartz c’est :

• Un nouveau site web.
• Un nouveau gestionnaire de sources.
• Un nouveau gestionnaire d’anomalies.
• Un nouveau forum.
• Mais toujours la même licence, Apache 2.

JDK 7, JEE 6, et Maven 3.0 : les annonces de Devoxx

La conférence Devoxx ayant eu lieu la semaine dernière a été l’occasion de plusieurs annonces importantes qui ont rapidement fait le tour de la blogosphère.

JDK 7 avec les closures, mais retardé à nouveau

C’est surement l’annonce qui à fait le plus de bruit. Elle s’est répandue comme une trainée de poudre tant elle était inattendue. Lors d’une présentation en apparence sans surprise sur les nouveautés du JDK 7, Mark Reinhold explique que le temps est venu pour Java de supporter les closures. Afin de permettre leur implémentation, la finalisation du JDK 7 est repoussée à septembre 2010. Trois nouveaux milestones sont donc ajoutés au calendrier initial avec une finalisation des fonctionnalités (features complete) prévue pour Juin 2010. Ce nouveau délai permet donc à l’équipe du JDK de travailler sereinement sur la finalisation de Jigsaw, d’implémenter les closures, et devrait vraisemblablement permettre également l’inclusion du multi-catch pour les exceptions.

En fait ce délai semble laisser la possibilité à de nombreuses autres fonctionnalités et spécifications qui avaient été mises de coté de prétendre de nouveau intégrer le JDK 7. On peut ainsi imaginer :

• JMX 2, qui avait été repoussé au JDK 8
• La JSR-310 (Date and Time API) qui avait connu des difficultés par manque de contributions et n’avait finalement pas été incluse à la liste finale des fonctionnalités du JDK 7
• La JSR-296 (Swing Application Framework) dont le retrait du JDK 7 avait été annoncé cet été
• Le support des propriétés

Questionné à Devoxx sur l’étendue des fonctionnalités pouvant être concernées par une potentielle inclusion, Mark Reinhold ne ferme la porte à aucune hypothèse. Il explique ainsi qu’il n’a pas eu l’occasion de voir de proposal pour les propriétés qui lui semblait satisfaisante jusqu’à présent mais n’exclue pas une telle possibilité d’ici la finalisation des fonctionnalités du JDK 7.

JEE 6 finalisé en décembre

Lors du keynote du premier jour des conférences, Roberto Chinnici (Spec lead JEE 6) a annoncé la finalisation de l’ensemble des spécifications JEE 6 ainsi que de l’implémentation de référence associée (Glassfish V3) pour le 10 décembre 2009.

Cette nouvelle intervient alors que JEE 6 a été très bien accueilli par le public à Devoxx comme il l’a été maintes fois répété dans le dernier épisode des Cast Codeurs.

Maven 3.0 finalisé en Janvier

Cette annonce est passée plus inaperçue parmi l’actualité de Sun. Pourtant Jason van Zyl, lors de sa présentation des nouveautés de Maven 3.0, a annoncé une finalisation de la nouvelle version de son outil de build pour la fin janvier 2010.

Cette nouvelle version apportera le support des builds multithreadés ainsi qu’un environnement de base pour les extensions très intéressantes que sont Polyglot Maven et Maven Shell.

Nous publierons rapidement un article plus détaillé sur l’ensemble des nouveautés à venir sur Maven 3.x.

RIA

GWT version 2.0 RC1

Une nouvelle version majeure du RIA de Google, GWT, sort en version 2.0 RC 1. Cependant, aucune date de sortie n’est encore annoncée.
Cette version s’accompagne d’un plugin pour Eclipse, nommé Google Plugin for Eclipse 1.2 RC1, dont l’on recommande vivement la mise à jour.
Parmi les nouveautés, on peut citer:

• Utilisation du Development Mode (anciennement appelé Hosted Mode) dans le navigateur de votre choix via un plugin.
• Possibilité de fragmenter le code JavaScript généré en plusieurs morceaux en utilisant GWT.runAsync() va permettre d’accélérer considérablement les temps de chargement.
• Story Of Your Compile (SOYC) génère un rapport sur le processus de compilation et permet d’avoir une meilleure vision du code généré.
• Facilitation de la création d’IHM par déclaration avec Ui Binder.
• Apparition d’un ClientBundle, similaire au ImageBundle, qui permet la généralisation du sprinting à d’autres formats les fichiers textes, css, etc.
• Utilisation de HtmlUnit pour les tests unitaires, qui permet maintenant de débugger directement dans le débuggeur Java.

Les nouveautés sont donc nombreuses et apportent un réel gain de productivité.
Le combat auquel se livrent actuellement les RIA est loin d’être terminé…

Le coin de la technique

OWASP Security Top Ten, la cuvée 2010 est arrivée

Après le Beaujolais Nouveau et le calendrier des pompiers, c’est au tour de l’OWASP de faire son annonce avec la mouture 2010 de son « Security Top Ten ». En attendant de rédiger un billet complet sur ces failles et leur prévention en Java, voici un lien vers une présentation que nous avions fait pour une formation interne et la liste 2010 avec une présentation très succincte des parades dont nous disposons en Java :

A1 – Injection : injection sql, hibernate ql, jpa ql, http, etc.
Utiliser des prepared statements, les paramètres de commons http, etc.

A2 – Cross Site Scripting (XSS)
Utiliser JSR 303 Bean Validation pour valider les données entrantes et escaper les données sortantes avec JSTL ou un équivalent.

A3 – Failles d’Authentification et de gestion de Gestion de Session
Utiliser Spring Security ou les mécanismes du moteur de servlet.

A4 – Référence Directe Non Sécurisée aux Objets de données
Revalider tous les ID provenants des requêtes HTTP ou utiliser un aliasing par random (cf. org.owasp.esapi.AccessReferenceMap).

A5 – Cross Site Request Forgery (CSRF)

Protéger les invocations d’URL par le contrôle d’un nombre aléatoire généré côté serveur. En cas de risque majeur, utiliser un framework Web de description de flow (Spring Web Flow, JBoss Seam, etc).

A6 – Mauvaise configuration de sécurité (Nouveau)
Utiliser les installation standard des systèmes d’exploitation et des middlewares, restreindre les droits des utilisateurs unix, etc.

A7 – Mauvaise protection des URL

Utiliser des mécanismes de sécurité déclarative par URL ou par annotation sur les beans controlleurs et de service.

A8 – Utilisation de redirects et forwards non controlés (nouveau)

Ne pas construire l’url de redirection ou de forward avec des données saisies par l’internaute. Figer les valeurs possibles de redirection dans le code ou dans des fichiers de configuration.

A9 – Failles des systèmes de stockages encryptés

Ne jamais stocker un mot de passe en clair, éviter de stocker des informations sensibles comme les numéros de carte bleue, . Si c’est finalement nécessaire, mettre en place un système de stockage dédié avec une gestion très attentive.
Documenter dans les configurations de logging (e.g. log4j.properties) les loggers à ne pas activer si des informations sensibles ne doivent pas sortir dans les logs (e.g. couche de binding des frameworks web).

A10 – Protection insuffisante des canaux de communication

Ne pas réinventer de canal de transport sécurisé, utiliser SSL quand c’est possible ; sinon, regarder WS-Security même s’il est très couteux à mettre en œuvre (debugging, etc).

Que devient Spring Rich Client ?

Spring Rich Client est un framework applicatif basé sur Spring. Il permet de créer des applications clients lourds plus facilement qu’en utilisant l’environnement Swing de base.

La promesse est séduisante, toutefois le projet initié en 2004 ne s’est vu finalisé que 4 ans plus tard, en mars 2008. Dès lors certains doutes planent quant à la santé de cette communauté.

Lieven Doclo, leader du projet, en a présenté les fonctionnalités lors d’un BOF à Devoxx. Ce fut également l’occasion d’un certain nombre de questions quant à la santé et au positionnement de ce projet méconnu :

• Bien qu’il soit directement référencé au sein du portfolio de SpringSource, l’éditeur n’investit pas dans ce projet. On notera d’ailleurs que Lieven Doclo n’est pas employé par SpringSource mais consultant Java externe.
• Le projet souhaite se positionner face à Eclipse RCP et NetBeans RCP en mettant en avant l’obligation d’utiliser SWT pour le premier et le manque de perspectives pour le second du fait des récentes déclarations d’Oracle.
• Les évolutions lentes du projet s’expliquent par la taille réduite de l’équipe. Lieven Doclo appelle d’ailleurs les volontaires à le rejoindre.

Si l’utilisation du framework Spring pour l’assemblage des composants des applications Spring RC est attirante car elle permet de reproduire les paradigmes de programmation utilisés pour le développement d’applications Web, Spring Rich Client peine encore à convaincre face aux poids lourds que sont les solutions d’Eclipse et de Netbeans. Il pourra toutefois intéresser les équipes souhaitant réutiliser des composants Spring existants.

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

Devoxx 2009

La semaine dernière se tenait l’édition 2009 de Devoxx à Anvers. Retrouvez nos premiers billets sur cette semaine de conférence :

• Devoxx – Jour 1 – Adobe University
• Devoxx – Jour 1 – Applications robustes avec Amazon EC2
• Devoxx – Jour 1 – Kanban in action
• Devoxx – Jour 1 – JSF 2
• Devoxx – Jour 1 – NoSQL avec HBase
• Devoxx – Jour 2 – Google App Engine
• Devoxx – Jour 2 – Les effets avec Flex 4
• Devoxx – Jour 2 – Hibernate Search
• Devoxx – Jour 2 – Java FX The developer guide
• Devoxx – Jour 2 – SOA en pratique
• Devoxx – Jour 2 – Scala Actors

Actualité éditeurs / SSII

• Innovation permanente chez Google
• Java SE 5 en fin de vie, JDK 7 en approche

SOA

• 10 mythes au sujet des SOA

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

• Soirée Google au LyonJUG

Actualité éditeurs / SSII

Innovation permanente chez Google

Google est encore une fois au cœur de l’actualité cette semaine avec la mise à disposition d’un nouveau langage de programmation et d’un protocole destiné à remplacer HTTP.

Le langage Go est à la croisée de C, Java et Pascal et est annoncé comme ayant des performances proches du C. Go se distingue par le fait que son compilateur produise directement du code natif, et qu’il ne requiert donc pas de machine virtuelle. Il apporte toutefois un ramasse-miette et un ensemble d’abstractions permettant de simplifier la programmation parallèle.

Très rapidement, plusieurs opinions et résultats d’expérimentations sont apparus. Ainsi, Tim Yang montre les performances obtenues par une application serveur développée en Java (en utilisant Mina), C (avec Nginx) et Go. Les résultats qu’il obtient montre que Go est en retrait par rapport aux deux autres solutions. Ces résultats doivent toutefois être relativisés par la maturité acquise par le système d’entrée / sortie de la JVM, le design très performant offert par Mina, la réputation de performance de Nginx et enfin, bien sûr, par le stade embryonnaire de Go.

Google a également diffusé les spécifications de SPDY (prononcer Speedy), un protocole visant à remplacer HTTP. On le sait, HTTP n’est pas adapté au Web moderne. En particulier il n’est pas optimisé pour obtenir une latence minimale. SPDY ne redéfinit pas tout, il se base sur HTTP et y ajoute un ensemble de possibilités supplémentaires telles que la compression d’en-têtes, le multiplexage de flux ou encore la priorisation de requêtes.

Des tests sur le transport du contenu des sites Web les plus populaires, permettent à Google d’annoncer un gain moyen de 55%.

L’entreprise américaine continue donc d’impressionner par son innovation permanente, n’hésitant pas à remettre en cause régulièrement des technologies considérées comme incontournables.

Java SE 5 en fin de vie, JDK 7 en approche

Sur la page dédiée à J2SE 5.0, Sun notifie depuis début novembre les utilisateurs de l’arrivée en fin de vie (End of Service Life) de cette version de Java.

Arrivé il y a 5 ans, Java 5 avait constitué la mise à jour la plus importante de la plate-forme et de son langage depuis sa création. Son adoption en entreprise fut longue, mais s’est concrétisée au fil du temps. Ainsi aujourd’hui, on ne compte plus qu’une minorité de projets fonctionnant encore exclusivement avec la version 1.4 ou inférieure de Java.

Il en est tout autrement pour Java 6.0. En effet, contrairement à la version 5.0 dont l’adoption était indispensable pour profiter des technologies d’entreprise les plus récentes, les principales motivations pour passer à la version 6.0 concernent la JVM elle-même et les améliorations qu’elle a connue.

L’arrivée en EOSL pourrait accélérer les choses dans certaines entreprises, tandis que d’autres préfèreront se tourner vers l’offre Java for Business de Sun qui permet de continuer de bénéficier du support de l’éditeur.

Une autre possibilité pourrait se trouver dans l’arrivée de JDK 7. En effet, la roadmap du projet promet un début de phase Release Candidate débutant à la fin du premier trimestre 2010 pour une durée d’un à deux mois, ce qui permettrait donc l’arrivée d’une version finale dans 6 mois. Si la confiance dans les dates de finalisation annoncées de JDK 7 s’est évaporée au fil des reports successifs, la situation semble maintenant se stabiliser : Mark Reinhold vient d’annoncer la disponibilité de la M5 de JDK 7, en accord avec le calendrier prévisionnel de la roadmap. Quatre des fameuses évolutions du langage apportées par le projet Coin y sont implémentées et peuvent donc être d’ores et déjà testées.

SOA

10 mythes au sujet des SOA

Yefim Natis, de Gartner, a exposé durant l’évènement SOA in Action, dix mythes communs (et la réponse qu’il faut leur apporter) sur la mise en place d’une SOA.
Là où l’article porte à sourire, c’est que, pour une fois, la faute est partagée : cinq de ces mythes sont propagés par les fanatiques de la SOA, et sont mis en regard de cinq autres portés par les allergiques.

Pour les fanatiques, nous avons :

• Les services sont portés par l’IT et propagés vers les acteurs fonctionnels.
  Pour Yefim Natis, une SOA est un moyen pour l’IT de mieux comprendre et appréhender les problématiques métier.
• Les plate formes orientées services reposent sur des briques pré-fabriquées.
  Les SOA ne reposent pas uniquement sur des applications ‘services’, mais aussi sur des batchs et des applications héritées.
• Partager et réutiliser sont les principaux apports d’une SOA.
  C’est en effet un des bénéfices attendus, mais c’est loin d’être le seul. On peut citer : meilleure exploitation, meilleure montée en charge …
• Mettre en place une SOA permet de s’abstenir de réaliser une phase d’intégration.
  Même si la SOA permet d’introduire une stabilité dans les interactions entre services, elle ne dispense pas de réaliser de vrais tests d’intégration, bien au contraire.
• Une SOA réduit les coûts du SI.
  Sur le long terme, peut être … Mais dans un premier temps, une SOA peut s’avérer couteuse : nouvelle façon de penser, nouveaux outils, formations à prévoir…

Pour les allergiques, la liste est la suivante :

• Une SOA introduit une grande complexité et de nouveaux problèmes.
  La plupart des problèmes liés à la mise en place d’une SOA sont des problèmes existants partout ailleurs dans le monde de l’informatique distribuée. La mise en œuvre d’une SOA ne fait souvent que mettre en exergue des problèmes existants.
• SOA n’est pas nouveau, c’est juste un effet de mode.
  Il faut voir au delà de l’aspect technique : certes SOA repose sur les principes de l’informatique distribué, mais c’est l’ensemble de la démarche qui est nouvelle et qui a au moins l’avantage de crystaliser certaines bonnes pratiques.
• Une SOA est vouée à l’échec, parce que les Web Services sont un standard trop instable.
  SOA et SOAP sont deux choses complètement différentes. Les Web Services sont ‘juste’ un moyen d’exposer des services.
• Il est difficile de vendre une SOA, car les acteurs fonctionnels n’en voient pas les bénéfices.
  Certains bénéfices sont apparents de manières quasi instantanée (on pense aux indicateurs BAM), et les acteurs fonctionnels gagnent rapidement une nouvelle compréhension de leur environnement IT.
• SOA est déjà dépassé, il faut passer à la suite.
  Le challenge d’une SOA basique est en effet dépassé. Mais il reste de nombreux enjeux à adresser, notamment dans les architectures les plus complexes.

via InfoQ

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

Soirée Google au LyonJUG

Lundi 23 Novembre, le LyonJUG organise une soirée dédiée aux technologies Google. L’occasion de découvrir, démonstration à l’appui, Google Web Toolkit, Google App Engine, Android et le dernier né Google Wave. L’objectif est aussi de présenter l’architecture globale de ces produits pour mieux en saisir le fonctionnement et le but.
Pour faciliter l’organisation de la soirée dans les locaux d’EPITECH, vous devez vous inscrire ici.

Actualité éditeurs / SSII

• SpringOne G2X : c’est parti pour Spring 3 !

RIA

• GWT 2.0 Milestone 1

Le coin de la technique

• memcached vs. DataGrid, serveur stupide vs. serveur astucieux ?
• Finalisation de l’implémentation de référence de Beans Validation
• Le noyau de dm Server disponible séparément, pourquoi ?
• Un nouveau moteur de stockage pour ActiveMQ 5.3 : KahaDB

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

• Traduction de la première partie de DDD Quickly

Actualité éditeurs / SSII

SpringOne G2X : c’est parti pour Spring 3 !

L’édition américaine de cette conférence dédiée aux produits SpringSource commence aujourd’hui à la Nouvelle Orléans et durera 4 jours. Elle est donc plus longue que les années précédentes en raison de l’intégration de nombreuses présentations dédiées à Groovy, mais également plus dense puisqu’on compte pas moins de 8 sessions en parallèle. La lecture du planning permet de noter la présence fortement marquée de Spring 3.0 et Spring Roo. Par ailleurs SpringSource offre de nombreuses sessions à Groovy / Grails, avec des sujets rarement évoqués tels que Grails and the JVM Memory Management ou OSGi and Groovy.

En accord avec les préceptes du Conference Driven Development, évoqués par Guillaume Laforge dans un podcast , SpringOne G2X est l’occasion d’un certain nombre d’annonces. Ainsi SpringSource vient d’annoncer dans un communiqué la finalisation du très attendu Spring 3.0, qui était jusqu’alors en statut release candidate.

Cette version est la première mise à jour majeure de Spring depuis la version 2.5 sortie il y a maintenant 2 ans et qui avait notamment apporté la configuration massive par annotations. Les principaux apports de la version 3.0 sont :

• Support de REST dans Spring MVC
• Transition de l’ensemble du code du framework vers Java 5, tirant ainsi partie des generics
• Support de Spring Expression Language (SpEL) dans les annotations comme dans la configuration XML
• Intégration de certains des mécanismes de configuration de Spring JavaConfig
• Intégration d’OXM, l’abstraction de mapping Objet / XML jusqu’alors incluse dans Spring WS
• Support initial de la JSR-330 (Dependency Injection)

Ces nouveautés étaient très attendues par la communauté et le succès à venir de Spring 3.0 semble acquis. Si cette projection est évidente, il est par contre plus délicat de dire qui aura la préférence dans les projets entre JAX-RS et le support de REST intégré à Spring MVC ou encore entre le nouveau standard qu’est la JSR-330 face à l’API propriétaire de Spring…

RIA

GWT 2.0 Milestone 1

GWT 2.0 arrive à grands pas ! Un petit avant goût nous est proposé depuis quelques jours avec la Milestone 1 de ce nouveau cru GWT (via InfoQ).

Des nouveautés, il y en a ! Du changement de terminologie en passant par de nouveaux composants, GWT 2.0 apporte son lots de gros changements :

• nouvelle terminologie : le hosted mode devient le developpement mode et le web mode devient le production mode ;
• distribution unique avec, vous le verrez sur la page de téléchargement, un JAR unique et non plus un JAR par environnement (Windows, Mac et Linux) ;
• developpement mode directement dans le navigateur (GWT utilise pour cela un plugin de lecture de code natif), les fenêtres du mode hosté disparaissent ;
• ajout du code splitting qui découpera le code en plusieurs fragments : l’idée ici est que l’on pourra commencer à utiliser une application web GWT alors que certains fragments (non nécessaires au démarrage de la webapp) n’auront pas été chargés, ce qui permettra entre autres un démarrage plus rapide de l’application (chargement différé) ;
• UIBinder qui offrira la possibilité de déclarer nos écrans dans un fichier XML (swing-like ou flex-like, à vous de choisir ) ;
• ClientBundle qui optimisera et combinera des ressources telles que les fichiers texte, les CSS ou les XML, ce qui permettra de réduire le trafic réseau et les temps de latence ;
• utilisation d’HtmlUnit pour les tests unitaires ;
• suppression des APIs GWT dépréciées jusqu’à la version 1.6.

Les défauts que l’on remarquait sur les premières versions se corrigent donc petit à petit et GWT 2.0 affiche le souhait d’aider / simplifier la vie du développeur. Google confirme ainsi qu’il faut toujours compter sur GWT dans la course effréné au meilleur RIA du marché. Il est vrai que des applications comme Google Wave montrent clairement le potentiel technique de GWT (robustesse, rapidité…).

Concernant l’upgrade vers cette nouvelle mouture, l’équipe se veut rassurante et précise qu’une montée de version entre la 1.7 et la 2.0 ne devrait pas demander beaucoup d’efforts.
Le JAR se récupère à cette adresse.

Le coin de la technique

memcached vs. DataGrid, serveur stupide vs. serveur astucieux ?

Billy Newport, Websphere eXtreme Scale, est juge et partie dans son billet memcached versus DataGrid, dumb server versus smart server… dans lequel il compare le très à la mode memcached avec les sophistiquées DataGrid (IBM Websphere eXtreme Scale, Gigaspaces XAP, Oracle Coherence).
Le point d’attention de Billy Newport est la rusticité de memcached qui amène souvent les utilisateurs à inventer au dessus un ensemble de rustines qui rendent la solution finalement complexe et sous optimale. Le principal défi est la gestion de la haute disponibilité et la faiblesse du failover. En effet, l’intelligence de memcached se limite à être un gros entrepôt de clés-valeurs ; un serveur memcached n’est pas conscient qu’il est utilisé en mode partitionné et clusterisé avec d’autres serveurs, ce sont les clients memcached qui connaissent la topologie et ont une intelligence de routage des plus rudimentaire avec un modulo sur le hash de la clef à stocker.
De ce fait, les mécanismes de failover en cas d’arrêt d’un serveur sont très limités ; une extension de consistent hashing améliore la situation en évitant un transfert brutal de toutes les données que causerait la perte d’un nœud (tous les modulos changent). Ce ne sont que les débuts des difficultés, les ingénieurs de Facebook, gros consommateurs de memcached, détaillent dans Designing the Facebook username land rush les défis de fiabilité qu’ils ont rencontrés.
A cette rusticité de memcached, Billy Newport oppose la sophistication des DataGrids qui assurent en standard la fiabilité des données qu’elles gèrent, en consommant souvent moins de ressources mémoire, CPU et réseau.

Mesquinerie d’un éditeur qui cherche à tacler un concurrent ?

On peut en douter, l’argumentaire de Billy Newport est parfaitement cohérent. Memcached a été initialement créé pour mettre en cache des fragments html pour le site web LiveJournal, des données en lecture seule qui ne nécessitent de fiabilité, alors que les DataGrids ont été dès leur conception destinées au monde de la finance qui a besoin d’une fiabilité sans faille.

Alors que vaut-il mieux, un serveur rudimentaire étoffé par des gens astucieux ou des DataGrids astucieuses directement utilisables par des équipes qui n’ont pas le temps ou les compétences pour inventer un cache distribué fiable ?

Sans négliger le coût des DataGrids, rappelons nous l’adage « There is a fine line between clever and stupid », tout le monde n’est pas ingénieur clustering chez Facebook

Finalisation de l’implémentation de référence de Beans Validation

Emmanuel Bernard annonce la disponibilité de la version 4.0 finale d’Hibernate Validator. Cette version est la première à implémenter la JSR-303 (Beans Validation) qui devrait se voir également finalisée dans le même temps.

En pratique, Validator 4.0 apporte principalement :

• La composition de contraintes : il est ainsi possible de créer des contraintes qui réutilisent des contraintes existantes afin d’éviter la duplication de code.
• La notion de groupe : en catégorisant les contraintes dans des groupes, il est possible de ne valider qu’une partie des contraintes, ce qui trouvera son intérêt dans de nombreux cas d’utilisation.
• Les contraintes type-safe : la compatibilité entre le type supporté par une contrainte et celui de la valeur qu’elle valide est maintenant vérifié par Validator.
• Une API de création de contraintes : il est désormais possible de définir des contraintes par programmation et non plus uniquement par Annotation.
• La définition de contraintes par XML : alors que la version précédente ne permettait la définition de contraintes que par annotations, il est désormais possible de les définir également dans un fichier XML.

Les utilisateurs d’Hibernate Validator reconnaitront dans ces nouveautés des manques qu’ils avaient pu constater dans les versions précédentes. Toutefois, c’est probablement dans le support de la JSR-303 que réside la vraie révolution, puisqu’il s’agit d’unifier les très nombreux frameworks de validation qui se sont multipliés dans le monde Java depuis des années afin que nos applications ne dépendent plus que de javax.validation.

Le noyau de dm Server disponible séparément, pourquoi ?

Steve Powell, SpringSource, annonce la disponibilité d’une version autonome du noyau de dm Server : dm Kernel. Il s’agit d’une abstraction autour d’OSGi qui offre un environnement plus élaboré pour la construction de modules indépendants.

Par cette annonce SpringSource s’aligne sur un certain nombre d’autres middlewares qui mettaient déjà à disposition leur noyau assurant leur modularité tel que HK2 pour Glassfish, MicroContainer pour JBoss AS ou encore Karaf pour Apache ServiceMix. Une question vient alors naturellement en tête, pourquoi une telle séparation entre un middleware et son noyau en deux projets distincts ? On trouve des éléments de réponse en revenant sur le contexte entourant la sortie de chacun des noyaux concernés :

• Guillaume Nodet expliquait la création d’un projet à part pour le noyau de ServiceMix par le souhait exprimé par plusieurs projets Apache de se baser sur celui-ci.
• Steve Powell dans son annonce de dm Kernel met surtout en avant le fait qu’il ait pu être extrait de dm Server sans modification, prouvant ainsi le design propre et modulaire du serveur d’application de SpringSource.
• Glassfish HK2 et JBoss MicroContainer ont quant à eux été l’occasion de mettre en avant la légèreté du serveur d’application auquel ils sont liés.

Si la raison d’être de ces projets de noyaux modulaires se situe quelque part entre design, partage, et marketing, la communauté Java s’en trouve dans tous les cas enrichie puisqu’ils permettent à des projets naissant de bénéficier immédiatement d’une architecture flexible et d’un socle robuste.

Un nouveau moteur de stockage pour ActiveMQ 5.3 : KahaDB

Rob Davies annonce la disponibilité d’ActiveMQ 5.3. Cette nouvelle version apporte son lot de nouveautés et d’améliorations à ce Message Oriented Middleware très populaire dans le monde Open Source.

Parmi les nouveautés, c’est la finalisation du nouveau moteur de persistance de messages KahaDB qui retient l’attention. Annoncé il y a un an sur la mailing list du projet, et en gestation depuis, le but de KahaDB est d’apporter la vélocité de Kaha Message Store et la fiabilité de AMQ Message Store. Ce nouveau moteur de persistance offre ainsi :

• Journal transactionnel assurant la consistance des données
• Réplication des données très performante
• Support de plusieurs nœuds slaves
• Aucun point central d’échec, le noeud master peut être reconstruit sur un slave suite à une défaillance

KahaDB se base sur ZooKeeper pour assurer l’élection d’un nouveau nœud master.

Ce nouveau moteur de persistance s’annonce très novateur et devrait assurer l’attractivité de cette nouvelle version d’ActiveMQ. Les lecteurs intéressés par ActiveMQ noteront par ailleurs qu’un ouvrage lui étant entièrement consacré paraitra courant 2010 chez Manning.

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

Traduction de la première partie de DDD Quickly

Pour rappel, DDD = Domain Driven Design

Guillaume Lebur est à l’initiative d’un travail intéressant et difficile : la traduction en anglais du livre DDD Quickly. Ce livre propose une approche plus rapide du DDD afin d’en cerner les problématiques, contrairement au livre d’Eric Evans qui se veut plus exhaustif et précis sur le sujet.

Son travail est disponible sur le site DDD France, communauté libre qui ne parle que du DDD en français. En bon français cela donne DDD vite fait et surtout beaucoup de travail. La première partie est d’ores et déjà traduite, donc félicitations Guillaume et bon courage pour la suite !

Actualité éditeurs / SSII

• Les standards du Cloud Computing en préparation
• Fin de JavaRebel, place à …

RIA

• GWT 1.7 pour les nouveaux navigateurs !
• Flex Monkey 1.0

SOA

• La base de données dans une Event Driven Architecture
• REST et les abus de langage

Le coin de la technique

• OpenDS passe en version 2.0
• 10 bonnes raisons de chercher le successeur de Java

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

• Soirée Tontons Flexeurs

Actualité éditeurs / SSII

Les standards du Cloud Computing en préparation

Comme pour tout marché émergeant, le Cloud Computing s’est développé autour de technologies propriétaires mises au point par différents éditeurs et fournisseurs. Une session dédiée aux problématiques d’intégration lors du CloudCamp Paris avait conclu qu’aucun standard adapté n’était disponible pour permettre le transfert d’informations entre les différents fournisseurs et technologies du Cloud Computing.

Le monde du Cloud Computing montant en puissance mois après mois, la problématique de standardisation se fait de plus en plus pressante. C’est donc sans surprise qu’on a assisté à la constitution d’organismes de standardisation et de groupes de travail afin d’établir les standards à venir. Afin de donner une visibilité à l’ensemble de ces efforts, l’Open Grid Forum (OGF) annonce la création d’un site commun ou chaque organisme est invité à présenter ses travaux en cours : http://cloud-standards.org. On notera particulièrement deux spécifications prometteuses :

• Open Virtualization Format (OVF) : Format de packaging d’application permettant la distribution et le déploiement simplifié sur environnement virtualisé.
• Open Cloud Computing Interface (OCCI) : API standardisée permettant la définition, le provisioning et le monitoring d’infrastructures exposées en tant que services sur un Cloud (IaaS).

Par ailleurs, l’Open Cloud Consortium (OCC) explique travailler sur des frameworks d’interopérabilité entre Clouds et l’OASIS expose quant à elle sa vision selon laquelle le Cloud Computing est une extension naturelle des concepts SOA, et que, par conséquent, de nombreux standards qu’elle développe actuellement intègrent cette problématique.

Fin de JavaRebel, place à …

Zeroturnaround, l’éditeur de JavaRebel, doit faire face à un joli défi : pour avoir fait une entorse à la marque déposée Java, il doit modifier le nom de son produit, sans pour autant perdre la notoriété d’ores et déjà acquise. Pour faire d’une pierre deux coups (modifier effectivement ce nom mais aussi s’offrir un joli coup de pub), l’éditeur soumet ce renommage à un concours. En jeu, une licence JavaRebel à vie…

RIA

GWT 1.7 pour les nouveaux navigateurs !

Les dernières releases de GWT étaient plutôt espacées dans le temps (1 an entre 1.4/1.5 et 8 mois entre 1.5/1.6) mais il n’aura fallu attendre que 3 mois pour voir débarquer la version 1.6.5 1.7 de GWT.

Cette dernière version (définie comme mise à jour mineure / bugfix release) apporte un meilleur support des derniers navigateurs à savoir Internet Explorer 8, FireFox 3.5 et Safari 4 (meilleur support d’IE8 = disparition d’IE6 ? ).

L’ajout du user.agent ie8, qui peut potentiellement impacter certains projets, a fait pencher la balance vers un numéro de version de type majeure (1.7) pour forcer les développeurs à être attentif sur ce point important (une version de type 1.6.5 n’aurait pas eu le même impact).

Une simple recompilation suffit pour être compatible avec ces navigateurs, aucune modification de code n’est requise. Disponible comme toujours dans la section téléchargement du Google Code.

Flex Monkey 1.0

Plus de 7 mois après la sortie de la version 0.5 (précédente revue de presse), FlexMonkey, le framework de tests automatisés pour applications Flex et Air, se met à jour et passe ainsi en version 1.0 (par InfoQ).

Au menu : réorganisation de l’interface utilisateur, support direct d’applications Air (la console FlexMonkey devenant d’ailleurs une application Air) et tests générés pour Fluint (qui pourront aussi être lancés par FlexUnit 4).

Plusieurs tutoriels/exemples sont déjà disponibles sur la toile, on retiendra plus particulièrement le Getting Started d’Eric Owens (Gorilla Logic) et l’article très complet de Stuart Stern (CEO de Gorilla Logic et créateur de FlexMonkey) sur InfoQ.

SOA

La base de données dans une Event Driven Architecture

Sur son blog dédié aux traitements des évènements dans les systèmes d’informations, Tibco a publié un billet portant sur le positionnement d’une base de données dans une Event Driven Architecture (EDA).

Se trouvant à la base de nombreuses applications et services, elle constitue en effet une potentielle source d’évènements très intéressante. L’auteur met alors en avant la technologie Continuous Query Notification (CQN) intégrée à Oracle 11g, et qui permet aux clients d’une base de données de s’enregistrer pour recevoir des notifications lorsque les données d’une table ou le résultat d’une requête prédéfinie changent. On peut assimiler cette technologie à un mécanisme de trigger qui rappellerait des systèmes externes.

Cette possibilité permet ainsi d’enrichir les sources d’évènements disponibles au sein du système d’information : de par son positionnement, la base de données est capable d’offrir simplement des évènements qui seraient parfois complexes à générer au niveau applicatif. Dans une telle configuration, le Complex Event Processing (CEP) permettra alors de manipuler le volume important d’évènements ainsi créés afin d’en extraire des informations métiers utiles.

REST et les abus de langage

Ryan McDonough, contributeur au projet RESTEasy, a publié un billet dans lequel il fait un parallèle entre les abus de langages liés à REST et les mauvaises pratiques qui en découlent.

Parmi les erreurs de compréhension qu’il met en avant, on retrouve l’assimilation de REST à un protocole, la définition de REST en tant que synonyme de HTTP, ou encore l’utilisation abusive du qualificatif RESTful.

Il est souvent question lorsque l’on parle de REST de définition d’URLs, de représentations multiples d’une ressource, ou, plus couramment encore, d’opposition à SOAP. Loin de ces problématiques, Ryan McDonough met ici en avant le fait que REST est dans la réalité trop souvent utilisé pour justifier à tort tout type d’utilisation douteuse de JSON ou XML sur HTTP…

A ce titre, le livre RESTful WebServices de Leonard Richardson et Sam Ruby permet de comprendre en détail toutes les nuances de ce modèle d’architecture qui sont parfois délicates à appréhender.

Le coin de la technique

OpenDS passe en version 2.0

La version 2.0 du projet OpenDS est disponible. Il s’agit d’un serveur LDAP implémenté entièrement en Java et soutenu par Sun ; ces caractéristiques le positionne donc directement face à Apache Directory Server, son équivalent développé par la fondation Apache.

Ludovic Poitou présente les principales nouveautés de cette version :

• Ajout d’un control panel graphique, en remplacement du status-panel de la version précédente, permettant d’administrer le serveur et ses données
• Amélioration de la réplication multi-master
• Support de connections sécurisées SASL
• Affinement du système de contrôle d’accès
• Amélioration des performances. On notera sur ce point la collaboration avec l’équipe du garbage collector G1 qui avait été exposée il y a 2 mois

Au delà de l’ajout de fonctionnalités, la question du positionnement reste entière pour OpenDS tout comme pour son rival ApacheDS. En effet, l’annuaire est en général une ressource critique du système d’information pour laquelle on préfèrera généralement une implémentation native plus mature. Dès lors, OpenDS se destinera principalement au poste de développement, aux tests, et aux applications embarquant directement leur propre annuaire comme mécanisme de persistance.

10 bonnes raisons de chercher le successeur de Java

Dans la droite ligne d’un certain nombre de keynotes récentes, Mario Fusco expose, sur TheServerSide, 10 bonnes raisons de chercher un héritier à Java. Ces ‘manques’ de Java sont souvent évoqués, parfois partiellement comblés par les futures spécifications. Il nous a semblé malgré tout intéressant de les reprendre ici, ne serait ce pour que ces limitation soient bien comprises de tous.

• Absence de Closures, et son corollaire, l’absence de pointeur sur les fonctions (first-class function).
• L’existence de types primitifs (le langage n’est pas 100 % objet), et un autoboxing pas toujours performant (sur la gestion des null par exemple).
• La faiblesse des Génériques : impossible de découvrir leur type au Runtime.
• L’impossibilité de supprimer certains warnings concernant les génériques.
• Impossible de passer un paramètre void à une méthode.
• Le pattern proxy n’est pas implémenté de manière native sur les classes concrètes.
• Le switch…case est très faible
• La présence des exceptions Checked qui obligent à de douloureux try...catch ou à d’illisibles throws

Mario Fusco a l’honnêteté de reconnaitre que nombre de ces défauts font partie des péchés originels de Java et qu’il est quasiment impossible de les remettre en cause sans gravement compromettre la compatibilité ascendante du language, qui en est une des pierres angulaires. C’est pour cette raison qu’il se met en quête du next gen language

Vous ne manquerez pas de remarquer que, comme tout article qui parle de succéder à Java, ce billet est richement (parfois de manière assez virulente) commenté.

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

Soirée Tontons Flexeurs

Demain (mardi 21 Juillet) de 18h à 20h se déroulera une nouvelle soirée des Tontons Flexeurs dont le sujet est un retour d’expériences sur la mise en place d’applications Flex en entreprise dans le monde Java (tests unitaires/fonctionnels, intégration continue…).
L’événement étant déjà complet, il ne vous reste plus qu’à bookmarker leur calendrier pour être informé des prochaines réunions

RIA

• GChart 2.5 pour GWT

SOA

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

Le coin de la technique

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

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

• Sun fait évoluer sa certification programmer

RIA

GChart 2.5 pour GWT

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

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

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

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

SOA

jBPM 4.0 est disponible

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

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

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

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

Avez-vous besoin d’un ESB ?

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

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

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

Le coin de la technique

Making Good Software, bonnes pratiques du développement logiciel

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

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

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

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

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

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

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

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

Sun fait évoluer sa certification programmer

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

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

RIA

• Sortie de SmartGWT 1.1
• FlashBuilder 4 supportera FlexUnit 4
• JavaFX 1.2 est arrivé

Le coin de la technique

• G1 Payant ! Oracle sonne-t-il le glas des machines virtuelles Java gratuites ?
• Jetty dévoile sa roadmap
• Sortie de Tellerium 0.6.0 RC1

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

• Conférence Google IO 2009
• Adobe présente Flash Catalyst à Paris

RIA

Sortie de SmartGWT 1.1

Il aura fallu attendre près de 6 mois pour pouvoir apprécier la nouvelle version de SmartGWT, le wrapper GWT de SmartClient par Sanjiv Jivan (sortie de la version 1.0 lors d’une précédente revue de presse), information relayée par l’auteur et par The Server Side.

Cette version 1.1 apporte de nombreuses nouveautés (liste exhaustive sur la release note) :

• Correction de plus de 50 bugs.
• Amélioration générale des performances des composants et des skins.
• Champs de formules et résumés (wizards, bindable avec des DataBoundComponent…).
• Support du GWT-RPC DataSource avec les DataBoundComponent (tableaux, arbres, menus…).
• Nombreuses documentations Javadoc (le gros défaut de GWT-Ext).
• API de récupération d’état de la vue depuis le serveur (pour de nombreux composants).
• Nouveaux exemples dans le Showcase au niveau de New Samples.
• Un projet Helloworld pour SmartGWT avec GWT 1.6 …

Une librairie open source gratuite dans son intégralité (licence LGPL), ça ne se refuse pas ou au moins ça se teste !

FlashBuilder 4 supportera FlexUnit 4

Bonne nouvelle pour les développeurs Flex, nous apprenons par InsideRIA que FlexUnit 4 pourra être utilisé sur -FlexBuilder 4- FlashBuilder 4.
Dans cet article, l’auteur nous présente les nouvelles fonctionnalités que propose FlexUnit 4 telles que :

• Création simplifiée de suites de tests.
• Création et intégration facile de test runner à d’autres frameworks.
• Utilisation de l’intégration continue grâce à une automatisation de l’intégration.
• Meilleure gestion des tests asynchrones.
• Meilleure gestion des exceptions.
• Comme les annotations en Junit 4, les tests peuvent être gérés par les Metadata.

La prochaine étape maintenant est d’intégrer le projet à FlashBuilder 4. Il est d’ailleurs possible de voter pour ce projet. Si cela vous intéresse n’hésitez pas à voter vous aussi.

JavaFX 1.2 est arrivé

En accord avec le planning annoncé dès décembre dernier lors de Devoxx, une nouvelle version de JavaFX vient d’être mise à disposition. Les apports sont nombreux et comblent certains manques de la version 1.1. Le site de JavaFX propose un tour d’horizon très complet des nouveautés et Stephen Chin en présente un résumé accompagné d’un guide de migration. On retiendra :

• Ajout de widgets propres à JavaFX, skinnables et disponibles sur toute les plate-formes. Il n’est donc plus nécessaire de faire appel à des composants Swing (qui étaient inaccessibles sur mobile). L’ensemble des composants simples sont disponibles (bouton, checkbox, …), par contre la ListView est le seul composant de haut niveau à être fourni, pas de table, ni de tree.
• Ajout de composants dédiés à la création de graphiques de type Area, Bar, Bubble, Line, Pie, Scatter et X/Y.
• Ajout de nouveaux layouts en supplément des VBox et HBox déjà disponibles.
• Support de Linux et Solaris.

La compatibilité des binaires générés par JavaFX n’est pas assurée entre cette nouvelle version 1.2 et ses prédécesseurs. Il sera donc nécessaire de recompiler les applications pour assurer la migration.

Le nouveau JavaFX sera donc sorti dans les temps pour être le sujet de nombreuses présentations et annonces lors de JavaOne qui débute aujourd’hui même à San Fransisco. Comme nous vous en parlions il y a quelques semaines, le support des TVs pourrait y faire l’objet d’une démonstration.

Le coin de la technique

G1 Payant ! Oracle sonne-t-il le glas des machines virtuelles Java gratuites ?

Oracle va-t-il rendre Java payant ? Cette question que tous posaient après l’annonce du rachat de Sun revient aujourd’hui au premier plan avec une phrase sibylline de l’annonce de la version 6 update 14 de la JVM de Sun :

« Although G1 is available for use in this release, note that production use of G1 is only permitted where a Java support contract has been purchased… »

En théorie, la fonctionnalité concernée est encore expérimentale et le rachat de Sun par Oracle n’est pas clos : Oracle n’a pas à s’immiscer dans la gestion au quotidien de Sun ; il n’y aurait donc pas de raison que Sun change de stratégie sur la JVM.
Cependant, on n’a jamais vu de telles limitations contractuelles sur la JVM de Sun. Si les JVM mobile et temps réel ont toujours été payantes chez Sun comme IBM et BEA/Oracle, les JVMs serveur et poste de travail étaient traditionnellement gratuites … à un détails près : la JVM JRockit de BEA était devenue payante dès le rachat par Oracle ; on avait alors invoqué des considérations contractuelles qui empêchaient Oracle de distribuer gratuitement une JVM.

C’est aujourd’hui la très répandue JVM de Sun qui est menacée ; une fois de plus à la suite d’un rachat par Oracle. Faut-il craindre la fin des JVM gratuites ? Pour le poste de travail, cela parait très improbable faute de modèle économique crédible mais pour les serveurs, un revirement d’Oracle semble possible et dans la lignée de la nouvelle politique de JRockit. Il resterait alors disponibles gratuitement les JVM IBM J9 et Open JDK, le projet Open Source dont la gouvernance par Sun a été sujette à polémique ces derniers mois. Nous noterons au passage que G1 sera inclus dans la version 7 d’Open JDK.

Pour revenir sur les nouveautés de la JVM 6 update 14, nous retiendrons : la compression des pointeurs (-XX:+UseCompressedOops) pour les JVM 64 bits (cf. Java 64 bits, pas si souvent une bonne idée), l’optimisation des accès aux variables utilisées sur un seul thread ( -XX:+DoEscapeAnalysis ) et ce Garbage First (G1) Garbage Collector optimisé pour la gestion de grands volumes de mémoire mais réservé en production aux souscripteurs d’un contrat de support.

Jetty dévoile sa roadmap

Comme tous les conteneurs Servlet / JSP du marché, Jetty se prépare à l’arrivée de la JSR-315 (Servlet 3.0) prévue pour cet été. Par ailleurs, il opère également divers changements dûs à sa récente intégration à la fondation Eclipse.

Greg Wilkins a présenté une roadmap détaillée des fonctionnalités qui seront présentes dans les futures versions de Jetty.

Jetty 6 reste la version stable en attendant l’arrivée de son successeur.

Jetty 7 est la branche de développement que Greg Wilkins conseille d’adopter pour les projets débutant actuellement. Elle marquera la migration vers le package org.eclipse.jetty, et apportera une remodularisation accompagnée d’un packaging en bundle OSGi en supplément des artifacts Maven, et une préparation à Servlet 3.0 dont il proposera une preview.

Jetty 8 ne différera guère de son prédécesseur, il s’agira avant tout d’un rebuild en Java 1.6 exclusivement, accompagné d’une conformance stricte à Servlet 3.0 dont la spécification sera alors finalisée.

Aucune date précise n’est indiquée par l’auteur, mais il semble que la finalisation de la spécification Servlet 3.0 constituera le principal régulateur du calendrier de Jetty.

Sortie de Tellerium 0.6.0 RC1

Tellerium est un framework de tests unitaires d’interface utilisateur. Le projet s’appuie sur Selenium, est compatible avec JUnit et TestNG et permet d’écrire les tests en Java, Groovy ou par un DSL.

Les nouvelles fonctionnalités entre la version 0.5.0 et cette 0.6.0 sont plutôt nombreuses, on notera ainsi :

• Ajout du sélecteur jQuery (et du jQuery Cache).
• Support de Selenium 1.0 Beta 2 et Groovy 1.6.
• Core (Include, setCustomConfig, Dump method …).
• Selenium Grid (tests en parallèle).
• Archetype Maven (JUnit et TestNG) …

Plusieurs nouvelles fonctionnalités donc mais surtout de nombreuses optimisations de performances, des tests plus rapides et plus faciles à écrire, le tout utilisant les versions les plus récentes des projets dont il dépend. A noter aussi le plugin pour FireFox TrUMP (Tellerium UI Model Plugin) permettant d’écrire plus rapidement les tests (enregistrement des clicks, validation et customisation, export Groovy…).

Le téléchargement se passe par ici, et pour les pom ça se passe en bas de page par là.

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

Conférence Google IO 2009

Google I/O 2009 s’est tenu la semaine dernière à San Francisco. Il s’agit d’une des conférences destinées aux développeurs utilisateurs des applications et des API de Google. L’actualité autour de cette conférence étant relativement importante, nous avons décidé de traiter celle-ci dans un article séparé.

En voici les grandes lignes de ce qui s’est vu à Google I/O :

• Le futur du Web, avec les premières démonstrations émoustillantes Html 5.
• Google Wave, le prochain outil de communication et collaboration made in Google.
• La réconciliation de Google avec GWT, sortie de Gwt Query.
• Le futur d’Android, avec l’annonce de la branche Android 2.0 : Donut.
• Java et Google App Engine en GA.
• Google Web Elements, comment intégrer les services Google dans vos pages web.
• Les macros dans Google Document, avec Google Apps Script.
• Arrivée des extensions dans Chrome.

Pour en savoir plus, vous pouvez lire notre billet dédié au sujet.

Adobe présente Flash Catalyst à Paris

Mercredi 3 Juin 2009 à 16h, Adobe propose une présentation de Flash Catalyst. Cet outil destiné aux designers permet de concevoir des composants graphiques riches sans programmation. Ces créations peuvent ensuite être fournies à un développeur Flex pour que ce dernier se charge de la programmation intelligente.
Cette présentation va se diviser en deux sessions sous formes de conférences et d’ateliers :

• Une session développeur.
• Une session designer.

Elle se clôtura par un cocktail à 19h30.
Pour plus d’informations ou pour vous inscrire ça se passe ici.

Dans cet article, je vais donc revenir sur les annonces et points marquants de ces deux jours de conférences.

D’autre part, les vidéos des keynotes sont disponibles, vous pouvez consulter celle du premier jour (html5, android, web components …) ou celle du second jour (google wave).

Google I/O 2009, voici ce que j’en ai retenu :

• Le futur du Web, avec les premières démonstrations émoustillantes HTML 5.
• Google Wave, le prochain outil de communication et collaboration made in Google.
• La réconciliation de Google avec GWT et la sortie de GWT Query.
• Le futur d’Android, avec l’annonce de la branche Android 2.0 : Donut.
• Java sur Google App Engine en GA.
• Google Web Elements, comment intégrer les services Google dans vos pages web.
• Les macros dans Google Document, avec Google Apps Script.
• Arrivée des extensions dans Chrome.

HTML 5, le premier whaou effect

C’est la première fois que HTML 5 me fait rêver. C’est en effet un sacré coup de pouce que Google à donné afin de faire taire les tergiversions. Google a pris position, et nous en a mis plein la vue ! C’est ainsi qu’a débuté le premier jour de conférence avec une vidéo d’introduction de 5 minutes présentant des applications écrites avec HTML 5. Application ai-je dit ? Eh bien oui, il semble bien loin le temps de la page web statique. Il semble bien loin le temps des hacks Javascript, arrêtons la bidouille et commençons le développement d’applications riches : c’est en tout cas ce que nous promet Google avec le HTML 5. Tout cela sans nécessiter le moindre plugin … pour peu que vous ayez un navigateur compatible.

Pour Google, le navigateur a encore de beaux jours devant lui. Installé sur prêt d’un demi-milliard d’ordinateurs, il reste le moyen le plus simple et répandu pour accéder à Internet. Google l’a bien compris et a participé à la course aux performances des moteurs JavaScript. En un an, les performances des moteurs JavaScript ont été multipliées par 5 ! Vous n’êtes pas fan de JavaScript, il faudra pourtant vous y faire. Comme nous vous pourrez le constater dans la suite de cet article, ce langage est l’un des points centraux de la stratégie Google.

Sans le savoir, vous possédez peut-être déjà l’un des navigateurs compatibles avec certaines fonctionnalités HTML 5, si tel est le cas vous pouvez lancer certaines des démonstrations présentées directement depuis celui-ci.

Les principales nouveautés apportées par HTML 5 sont :

• Les canvas, zone sur laquelle il est possible de dessiner et d’effectuer des transformations : agrandissement, rotations, translations sur différents types de figures.
• Des balises audio et video, qui permettent d’intégrer des médias dans le document sans nécessiter un plugin externe. Elles disposent de fonctionnalités similaires aux lecteurs Flash ou Silverlight vous permettant de contrôler le comportement de vos médias.
• Les sections permettent de diviser vos pages en parts sémantiques. Elles se différencient des balises div qui ont pour rôle principal la présentation. Une section est complétée par un header et un footer.
• Un nouvel attribut async pour les balises script, il permet d’exécuter un script indépendamment de l’affichage de la page. Ces scripts pourront s’activer à la demande selon la disponibilité de ressources.

HTML 5 vous propose donc de transformer vos pages web en application riche, ce nouveau balisage vous permet de tirer pleinement partie de contenu multimédia sans nécessiter de plugin extérieur.

Google Wave, la grosse annonce de la conférence

Sans conteste la grosse annonce de Google durant ces 2 jours, Google a annoncé la sortie prochaine de Google Wave. Il s’agit d’un nouvel outil Open Source de communication et de collaboration, initié à l’origine par les deux frères Rasmussen, déjà à l’origine de Google Maps. Leur point de départ, à quoi les emails ressembleraient s’ils avaient été inventés aujourd’hui ? Après nous avoir parlé d’HTML 5 et d’applications riches, Google dévoile comment ils comptent tirer parti de ces nouveautés. A la vue du résultat, difficile de croire que l’application fonctionne sur un simple navigateur. Je vous encourage vivement de regarder la démonstration, le moins que l’on puisse dire est qu’elle donne envie d’essayer le produit. Pour ma part, même si j’avoue bien volontiers avoir été moins époustouflé qu’à la sortie de Google Earth il y a quelques années, il faut bien admettre qu’une fois encore Google est moteur d’innovations. Tout comme la sortie de Gmail, fort est à parier qu’une multitude de concurrents essayeront en vain d’égaler cette nouveauté. Et si une page était en train de se tourner dans le développement d’applications Web ?

Là où les emails permettaient un échange point à point, Google Wave centralise et met à disposition le contenu. On n’envoie pas une Wave, on y participe. L’historique des modifications des conversations (texte, média, widget) est stocké sur un serveur. Ainsi, tout nouveau participant pourra rejouer intégralement celle-ci.

Google Wave est un mixte entre email, messagerie instantanée, réseaux sociaux, partages de documents. Il se base sur un protocole spécialement créé pour l’occasion. Celui-ci permet la transmission d’incréments de données et permet, entre autres, l’affichage caractère par caractère d’une conversation au fur et à mesure de la rédaction par son auteur.

Bien plus qu’une application, Google Wave est également contrôlable via une API spécifique. Vous pourrez donc y utiliser ces services à votre guise pour modeler vos propres solutions. Du coup, fort est à parier que Google Wave sera également disponible sous la forme de widget à utiliser sur vos blogs, sites web …

Pour plus d’information sur le sujet, vous pouvez consulter cette page sur laquelle l’auteur à centralisé les informations, définitions et fonctionnalités de Google Wave.

GWT, au cœur de la stratégie Google ?

L’autre grosse surprise avec l’arrivée de Google Wave, l’utilisation de GWT à grande échelle dans un produit Google !

Jusqu’ici, il était drôle de constater que si GWT avait bien été créé intégralement en interne chez Google, au final, aucun produit phare n’utilisait cette technologie. Et bien, ceci sera bientôt du passé ! Non seulement le client Wave a été écrit en GWT, mais Google continue à investir beaucoup sur cette technologie. Certes GWT à tout de même dû subir pour l’occasion quelques modifications, mais force est de constater que GWT semble plus que jamais au centre de la stratégie Google. GWT permettra également la création d’applications pour Android et iPhone. C’est comme si Google voulait nous faire oublier nos applications locales/desktop aux bénéfices d’applications légères/riches.

Google I/O, c’est également l’annonce de la sortie de Gwt Query : un clone de jQuery pour GWT. Cette nouvelle Api permet d’ajouter du comportement côté client sans rencontrer les lourdeurs des Widgets. À ce stage GWT Query reprend 98% des fonctionnalités de jQuery.

Android 2.0 Donut, recherches et filtres

A l’heure où les premiers téléphones Android arrivent tout juste en France, Google a annoncé la création de la branche 2.0, appelée Donut. Sortie prévue : fin 2009.

Comme le communiquent certains, 2009 sera probablement l’année d’Android. Si à ce jour seuls deux mobiles sous ce système sont timidement sortis en France, Google attend la sortie d’une vingtaine d’appareils (pour une dizaine de fabriquants) en 2009.

Google I/O a donc été l’occasion de faire un point sur la roadmap de cette nouvelle version, celle-ci est prévue pour fin 2009 :

• Recherche globale : un champ de recherche commun pour le web, la musique, les contacts… C’est en effet, l’un des défauts de la version actuelle, le market nous encourage à installer toujours plus d’applications, il s’avère pour le moment peu pratique de retrouver celle que l’on cherche. J’avais d’ailleurs l’idée de développer une application ‘launcher’, je vais donc pouvoir nettoyer ma todo-list. Cette recherche globale vous permet donc d’effectuer des recherches aussi bien en local sur votre téléphone qu’en connecté sur le web. Démonstration de la fonctionnalité après la 3e minute de cette vidéo.
• Contrôle par la voix : Android 1.5 (Cupcake) a introduit les embryons de Google Voice Search, vous permettant de lancer des recherches Google par la voix. Donut va davantage utiliser cette fonctionnalité qui vous permettra aussi bien d’appeler un contact que de contrôler vos applications à la voix. Ces fonctionnalités seront intégrées aux applications Google, mais pas seulement. Vous pourrez les utiliser dans vos applications via la nouvelle API. Révolutionnaire ? par forcément, j’ai utilisé cette fonctionnalité pour la première fois sur Pocket PC il y a 3 ans avec Microsoft Voice Command.
• Synthèse vocale : vous contrôlez votre téléphone par la voix, celui-ci sait également vous parler. Donut offrira également des fonctionnalités de text2speach multi-langues, la présentation à été portée par une application de traduction plutôt réussie.
• Contrôle par le geste : votre téléphone sera capable également de reconnaître via l’écran tactile des formes complexes. Cela vous permettra entre autres de filtrer une liste de contacts en dessinant la première lettre du nom recherché.

Pour clôturer ce sujet, notez l’ouverture d’un nouveau concours mondial de programmation sur Android : Android Developper Challenge 2 avec de belles récompenses à la clé.

Java sur Google App Engine, ouvert à tous

Bien qu’aucune annonce n’ait encore été faire sur le blog officiel, il semblerait que Google ait annoncé officiellement le support Java sur Google App Engine, ce qui veut dire : ouvert à tous. En effet, en avril dernier, Google avait déjà pré-ouvert sa plateforme aux langages Java et Groovy aux 10 000 premiers inscrits.

Google Web Elements, widgets pour vos sites internet

Google Web Elements vous permet d’utiliser les services Google sous la forme de widgets sur vos blogs ou sites web. Ces widgets nous permettront par exemple d’afficher facilement nos présentations PowerPoint sur le blog, les sites du type Slideshare doivent grincer des dents…

Le fonctionnement est très simple :

• Rendez-vous sur le site de Google Web Elements pour choisir votre type de Widget.
• Configurez-le en ligne via un simple formulaire permettant de générer le code HTML et JavaScript représentant le widget.
• Copier-collez le code sur votre site ou blog.

Huit applications sont disponibles pour le moment: Calendar, Presentation, Conversation, Custom Search, Maps, News, Spreadsheets et Youtube News.

Google Apps Script, scriptez vos Google Documents

Google IO c’est du grand spectacle, comme nous l’avons vu durant les keynotes, mais aussi des annonces plus terre-à-terre : Google Apps Script en est un bon exemple. Avec cette fonctionnalité, il vous sera donc possible prochainement d’ajouter des fonctionnalités de scripting dans vos documents. Le développement de ces ‘macros’ s’effectuera entièrement en JavaScript à partir d’un éditeur intégré aux différentes applications Google Document. Je vous invite à consulter une vidéo de démonstration durant laquelle le présentateur effectue une macro d’envoi d’email.

Chrome, arrivée des extensions

Comme certains le savent déjà, Chrome, le navigateur internet made in Google, proposera prochainement un système de gestion d’extensions. Il vous est d’ailleurs déjà possible de commencer à écrire vos propres extensions en utilisant le dernier build developper, je m’y suis d’ailleurs essayé comme vous avez pu le lire sur mon twitter. Si cela vous intéresse, jetez un coup d’œil au howto vous permettant de créer votre premier plugin en 30 secondes chrono.

Les extensions sont des archives ZIP contenant du HTML, des CSS et du JavaScript. Chaque partie d’UI d’une extension se présente sous la forme d’une simple page internet. Du coup, vous utilisez les mêmes outils, même debugger, mêmes librairies JavaScript et les mêmes techniques de programmation que pour créer vos pages web. Google a particulièrement bien travaillé son API pour la rendre aussi simple que possible.

Chrome dispose depuis sa première version d’une gestion des processus bien ficelée : chaque onglet dispose de son propre processus rendant de ce fait difficile de planter le navigateur à cause d’une des pages web. Les extensions fonctionneront sur un principe similaire et disposeront donc également de leur propre processus.

Les extensions seront distribuées sous la forme de fichier CRX composé de :

• Une signature, pour éviter les attaques du type Man In The Middle.
• Un manifeste, contenant les informations générales (nom, version …).
• Un fichier zip avec le contenu.

Tiens tiens, cela n’est pas sans nous rappeler le packaging des applications Android…

Actualité éditeurs / SSII

• Grails 1.1.1 supporté par Google App Engine

Agilité

• SCRUM en vidéo en 5 minutes

SOA

• REST : Le bon et surtout le moins bon …

Le coin de la technique

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

Actualité éditeurs / SSII

Grails 1.1.1 supporté par Google App Engine

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

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

Agilité

SCRUM en vidéo en 5 minutes

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

Tout y est :

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

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

A regarder !

SOA

REST : Le bon et surtout le moins bon …

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

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

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

Le coin de la technique

Utiliser Selenium Grid avec Hudson

Depuis 2006, Hudson offre un plugin Hadoop permettant d’utiliser son cluster Hudson pour effectuer des traitements lourds de type MapReduce.

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

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

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

Une API Criteria pour JCR

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

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

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

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

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

Intégration simple de GWT et Spring

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

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

Le service :

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

Le web.xml :

<web-app>
   <servlet>
      <servlet-name>dispatcher</servlet-name>
      <servlet-class>org.gwtrpcspring.RemoteServiceDispatcher</servlet-class>
   </servlet>
   <servlet-mapping>
      <servlet-name>dispatcher</servlet-name>
      <url-pattern>*.rpc</url-pattern>
   </servlet-mapping>
   <listener>
      <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
   </listener>
</web-app>

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

<beans ...>
   <context:annotation-config>
      <context:component-scan base-package="org.gwtrpcspring.example.server" />
   </context:annotation-config>
</beans>

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

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

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

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

8 bonnes pratiques pour améliorer scalabilité et performances

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

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

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

Actualité éditeurs / SSII

• Amazon lance son service Elastic MapReduce

Agilité

• Kanban vs Scrum

RIA

• Optimisation GWT : EntryPoint multiples

SOA

• Le calendrier se confirme pour jBPM

Le coin de la technique

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

Actualité éditeurs / SSII

Amazon lance son service Elastic MapReduce

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

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

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

Agilité

Kanban vs Scrum

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

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

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

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

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

RIA

Optimisation GWT : EntryPoint multiples

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

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

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

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

Avez-vous des retours concernant cette technique ?

SOA

Le calendrier se confirme pour jBPM

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

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

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

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

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

Rendez vous est pris pour juillet.

Le coin de la technique

Les nouveautés du futur SpringSource dm Server

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

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

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

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

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

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

Aide au diagnostique

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

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

Installation

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

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

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

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

Administration et Spring AMS

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

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

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

Pourquoi les projets agiles ne peuvent pas (vraiment) être menés au forfait

En matière de sous-traitance du développement logiciel, la pratique contractuelle la plus fréquente est celle dite du projet au forfait. La notion de forfait n’a, en principe, pas de rapport avec le processus de développement ou les pratiques d’ingénierie utilisée dans la réalisation du projet. Il s’agit simplement, dans l’esprit des contractants, de fixer les contours exacts de leur relation commerciale, et de définir leurs obligations mutuelles – en terme de coûts, de délais, de mode de paiement et de livraison. Dans un État de droit, et pour autant qu’elles ne soient pas abusives, ces dispositions contractuelles ont force de loi, et protègent efficacement les parties prenantes.
A bien y regarder cependant la neutralité du forfait vis à vis du processus de développement est moins évidente. Conçu historiquement pour satisfaire aux exigences de mise en concurrence des fournisseurs du Département de la Défense américain, le contrat au forfait est né du même substrat que le processus de développement en cascade – initialement décrit en 1970 par Winston W. Royce dans Managing the developpement of large software systems.
Ce processus de développement est aujourd’hui fortement remis en question, sous le constat empirique de son échec relatif, et sous l’impulsion des méthodes agiles. Je pense quant à moi que la « cascade » sera perçue dans quelques années comme l’aveuglement juvénile d’une industrie encore adolescente, à la recherche de son identité.
La question qui nous intéresse ici est de savoir si le projet au forfait survivra à la cascade. Autrement dit s’il est possible de mener au forfait un projet agile sous-traité. Certains le pensent, et certains intégrateurs proposent au demeurant de tels contrats. J’entends quant à moi démontrer ici que l’agilité et le forfait reposent sur des logiques financières radicalement antinomiques, qui les rendent difficilement conciliables.

Lire cet article »

GWT Galaxy

Vous avez peut-être assisté au Paris JUG sur GWT et vous vous êtes forcément dit en sortant de la conférence qu’il fallait absolument vous mettre à GWT. En plus, le pas à franchir n’est pas énorme : c’est du Java (ça devrait aller), agrémenté de nombreuses librairies comme dans le monde J2EE, des libraires graphiques qui en jettent sont disponibles… Que d’avantages ! Mais par où commencer ?
Nous allons donc faire un tour d’horizon non exhaustif, mais balayant une grande partie de ce qui est utilisé dans la galaxie GWT : les plugins, les frameworks et les APIs générales et graphiques.

Lire cet article »

Quartz et Spring Scheduling

Quartz pour ceux qui ne le connaissent pas encore, est un ordonnanceur. Il permet de planifier des tâches pour des exécutions ponctuelles ou répétées. Les planifications possibles vont de la simple répétition infinie, à la répétition calendaire utilisant la syntaxe de cron (tous les jours à minuit, le 31 janvier 2009 à 12h00, …). Quartz est prévu pour toutes sortes d’applications allant des programmes standalone basiques aux gros systèmes JEE distribués.
De son côté, Spring scheduling nous donne le choix entre les Timers Java et Quartz. Avec ses interfaces, Spring nous permet de planifier, très facilement, des Jobs directement dans l’ApplicationContext. En revanche, la gestion des planifications dynamiques est moins évidente. Dans cet article, je vous présenterai l’API Quartz dans les grandes lignes, puis on mettra en place la planification Quartz avec Spring Scheduling.

Lire cet article »

Agilité

• LiquidTest : un outil de test des applications web

RIA

• Statut 2009 du Web et de l’Ajax vu par des superstars
• Google Analytics enfin pour les applications Flash

Le coin de la technique

• Jigsaw, un petit nouveau de l’OpenJDK
• Sortie de GWT 1.6 Milestone 1

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

• Paris JUG demain soir !

Agilité

LiquidTest : un outil de test des applications web

LiquidTest est un outil entièrement écrit en RCP qui permet de tester une application web en jouant des scénarios directement dans le navigateur.

Les scénarios sont rédigés soit sous forme de tables HTML, soit sous forme de programmes qui pilotent le navigateur (Java, Ruby, Groovy, C#).

L’outil permet de générer des tests cases en Java, JUnit et TestNG, C# NUnit.

Les fonctionnalités suivantes sont proposées :

• Enregistrement automatique des actions sur Firefox et Internet Explorer.
• Écriture rapide et simple des scénarios de tests.
• Une exécution en parallèle des tests sur plusieurs serveurs.
• Intégration avec JUnit, Eclipse (Plugin), .Net et d’autres frameworks.
• Support des langages de programmation Java, C#, Groovy et Ruby.
• Support du Drag and Drop.

L’outil LiquidTest est fourni en 3 éditions : une édition Développeur, une édition Testeur et une édition Serveur.

Une version d’essai de 30 jours est disponible.

RIA

Statut 2009 du Web et de l’Ajax vu par des superstars

Matt Raible, nous propose sur son blog, une retranscription de deux conférences intéressantes :

• The State of the Web 2009
• Ajax: The State of the Art with Dion and Ben

Chris Wilson, employé de Microsoft, fait remarquer que même si il y a des efforts de standardisation les développeurs Web doivent apprendre à utiliser plusieurs types de navigateur. De manière générale, la tendance est à des plateformes et des environnements clients de plus en plus variés (Windows, Mac, iPhone). Les développements doivent tenir compte de tous ces environnements pour construire des applications de plus en plus dimensionnables (scalables).

Lars Erik Bolstad, employé Opera, ajoute que le WAP n’a pas réussi et que les navigateurs (même pour les mobiles) font se focaliser sur les standards du Web CSS/HTML. Les performances seront aussi un axe d’amélioration des mobiles mais aussi des différents moteurs (navigateur, javascript, framework).

Dan Connolly, membre du groupe de travail du W3C HTML, indique qu’il y a aussi des axes de travail qui vont avoir de nouveau de l’intérêt après avoir été un peu ignorés :

• Le Web Semantique.
• Sécurité Javascript : actuellement la sécurité des navigateurs sur les scripts Javascript est faible. On constate souvent que le Javascript est désactivé par les équipes de sécurité ce qui freinent la portabilité des applications Web. (A voir sur google code le framework : Caja).

Sur l’axe développement, Scott Fegette, employé à Adobe, remarque une évolution importante dans le développement Web. Les IDE WYSIWYG sont dépréciés en faveur des frameworks. D’ailleurs, c’est JQuery qui semble avoir le plus les faveurs des développeurs Javascript. Un des grands axes d’intérêt d’Adobe est le RIA. Ajax est mature. L’idée de AIR est de développer des applications Bureau par des développeurs Web. Ainsi on développera des applications bureau comme des applications Web, avec des environnements, des techniques et des outils semblables. Ainsi Flash et Flex sont souvent trop riches pour de simples applications Web (hormis pour des composants multimédia – audio – vidéo) et sont plus destinés à des applications bureaux.

Une des orientations importantes est le développement des applications bureaux qui passera par ce que l’on a connu sur le développement d’applications Web.

Google Analytics enfin pour les applications Flash

Google Analytics est un excellent outil pour analyser le trafic sur un site web. Mais jusqu’à présent cet outil n’était disponible qu’en JavaScript.

Pour étendre les fonctionnalités sur les applications RIA, l’équipe de Google Analytics a sorti récemment une nouvelle API Gaforflash. Cet API est une implémentation native pour ActionScript3. Matthew McNeely nous présente sur le blog d’InsideRIA Gaforflash et des exemples d’utilisation. Un nouveau pas franchit pour les applications Flex, si vous voulez avoir plus d’informations sur cet API voici le lien : http://code.google.com/p/gaforflash/.

Le coin de la technique

Jigsaw, un petit nouveau de l’OpenJDK

Une nouvelle étape a été franchie cette semaine avec l’arrivée du projet Jigsaw dans l’OpenJDK.
Cette approbation fait suite au vote positif de 6 des 8 membres du Compiler Group.

Basé sur la JSR-294 dont il reprend les grands principes, Jigsaw a pour but d’ajouter la notion de modules au JDK. Ce projet, dernièrement créé, se doit de recoller les morceaux du très polémique puzzle de la modularité Java.

Il devrait permettre :

• De modulariser le JDK. Il était temps de remettre le JDK au sport. Il n’a cessé de s’engraisser à chaque nouvelle version au fil de ses 15 ans d’évolutions. Découper celui-ci en modules permettra, d’une part de mettre à plat les différentes dépendances de celui-ci, d’autre part de réduire les consommations mémoires et le temps de démarrage.
• D’offrir un moyen simple aux développeurs de modulariser leurs propres applications.

Nous présenterons prochainement le fonctionnement de ces nouveautés, un article dédié est en cours d’élaboration.

Sortie de GWT 1.6 Milestone 1

Nous vous parlions mi-décembre des futures orientations de GWT avec la roadmap de GWT 1.6, prévu pour le premier trimestre 2009.

C’est donc sans surprise qu’est sortie fin de semaine dernière cette version 1.6 en milestone 1. Cette version confirme entre autre :

• La structure de projet en WAR.
• Les nouveaux composants graphiques comme le DateTime Picker (à la manière du composant équivalent jQuery) ou le LazyPanel.
• Le Hosted Mode qui passe de Tomcat à Jetty avec l’ajout d’une fonctionnalité Restart.
• Un nouveau système de gestion des évènements.

Le téléchargement de cette version se passe par ici, le blog rappel toutefois que cette version n’est pas production ready.

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

Paris JUG demain soir !

Dernier rappel, le Paris JUG fête son 1er anniversaire demain soir à la Fiap à partir de 19h45. Pour plus de détails, regardez le programme.
Et n’oubliez pas de vous inscrire. On espère vous voir nombreux !

Évolutions du langage

Petit rappel : la toute première version de GWT (1.0) est sortie le 17 mai 2006. Oui, il y a seulement 2 ans et demi ! De nombreuses versions se sont suivies pour arriver à une version 1.4 (fin août 2007) stable et très complète, permettant de démarrer sereinement nos projets.
Mais voilà, fin août 2008 (1 an plus tard, la plus longue période entre 2 releases), la communauté GWT était en ébullition : en effet, l’importante version 1.5 pointa son nez apportant un lot de nouveautés assez importantes.
De nombreux articles nous exposent parfaitement ces nouveautés du langage ; on pourra se diriger sur le Blog de GWT, sur InfoQ ou chez Octo.
Un rapide résumé donnerait :

1. Enfin du Java en version 5 : annotations, generics, enhanced loop, autoboxing, import static…
2. Generics ? Donc nos @gwt.typeArgs sont terminés !
3. JRE Emulation beaucoup plus large avec entre autres les très attendues TreeMap, LinkedHashMap et autres StringBuilder
4. Compilateur beaucoup plus rapide
5. Widgets plus complets et plus rapides

En bref : que du bon !

Plug-ins

GWT Designer

Plugin de type WYSIWYG. Il permet entre autres :

• la création de projet GWT, de module, de service et de librairie,
• génération du service Async ,
• la palette de widgets (intégrée dans une vue multi-onglets Design et Source),
• ajout d’événements et modification des propriétés d’un composant dans les onglets Event et Properties,
• Compilateur et Hosted Mode intégrés au projet (Builder Eclipse, menu « Run As… »),
• drag and drop côté Design qui met automatiquement le « Source » à jour.

À noter qu’il faudra, au-delà de la période d’essai, une licence annuelle ou perpétuelle pour continuer à l’utiliser.

VistaFei

Environnement de développement (qui s’appuie sur Eclipse 3.2) intégrant toute sorte de plugins spécialement conçus pour GWT. Il propose :

• la création de projet, de module (GWTView) et de service,
• un WYSIWYG (très similaire à celui de GWT Designer) séparant l’onglet « Properties » de la vue « Design »,
• la génération de code depuis la « GWTView »,
• l’internationalisation aussi générée.

Son utilisation est gratuite avec la licence « Community Edition ».

IntelliJ IDEA

Un plugin GWT intégré à l’IDE très abouti :

• création de projet, de module et de service,
• compilateur de projet,
• complétion Javascript dans une méthode native (non, vous ne rêvez pas !!!),
• quick-fix spécifiques GWT (votre code Java est correct mais il ne compilera pas, oubli de l’interface « IsSerializable », utilisation d’une librairie non émulée…), remplacement des @gwt.typeArgs…,
• navigation rapide entre les méthodes synchrones et asynchrones.

Le plugin est intégré à l’IDE de JetBrains, il faudra donc mettre la main à la poche pour obtenir une licence à moins de vous lancer dans un projet Open Source.

Cypal Studio

Le plugin que tout développeur GWT anti-WYSIWYG a dans son IDE !

• création de module, de service et d’exemple (sample),
• compilateur intégré au projet (« builder » Eclipse),
• lancement du Hosted Mode.

Simple mais efficace, ce produit est disponible gratuitement.

Frameworks

GWT-Maven

De nombreuses commandes maven adaptées à GWT sont disponibles, on notera parmi les plus intéressantes :

• Lancement du Hosted Mode (Tomcat, noserver, debug…),
• Compilation GWT,
• Lancement des tests unitaires GWT,
• Génération des interfaces pour l’internationalisation,
• Création de WAR GWT,
• Création de JAR GWT.

Gilead (anciennement Hibernate4GWT)

L’un des gros problèmes rencontrés au démarrage de GWT est l’utilisation des POJOs Hibernate côté client.
Je vous renvoie vers le très bon article d’Amin Fathallah (Xebia) qui détaille très bien les problèmes rencontrés.
Ainsi, Gilead nous permet d’utiliser nos POJOs Hibernate directement côté client sans aucun mapping Dozer !

Spring

Accessible par les librairies GWT-SL et GWT-WL, il est tout à fait possible d’utiliser Spring dans un projet GWT.
Le principal changement est que les services ne sont plus définis en tant que servlets dans le web.xml. Ils sont remplacés par la classe DispatcherServlet de Spring qui pilotera l’application.
On notera aussi les classes GWTController et GWTHandler, cœur de GWT-SL, permettant de wrapper intégralement nos actions et nos services.

G4JSF

L’adaptation de JSF dans le monde GWT. Même mécanisme que pour le SpringController i.e. que l’on aura des interfaces/classes à implémenter/étendre au lieu des classes GWT standard, les principales étant ComponentEntryPoint et GwtFacesServiceAsync.
Le tutoriel de référence pour l’intégration de JSF avec GWT se trouve sur The Server Side.

APIs graphiques

Le tour d’horizon continue avec les APIs graphiques.
Chaque composant ne sera pas détaillé à outrance, seuls certains seront cités pour donner un aperçu général de ce qui est proposé (détail complet sur les sites officiels respectifs de chaque librairie).

Widgets Core (démo)

Premier réflexe avec tout ce que l’on entend sur GWT : foncer sur la première librairie de composants graphiques à la mode !
Mais n’oublions pas toutefois que GWT propose en standard des widgets haut niveau très complets :

• Boutons : basique, checkbox, radio, custom…,
• Listes : basique, suggest, arbre, menu…,
• Text : basique et riche (à la word),
• Popups,
• Panels : décorateur, horizontal, vertical, dock, disclosure, onglet…,
• Tables : tableau standard et flex.

GWT-Ext (démo)

Certainement la librairie graphique la plus répandue.
Wrapping complet de l’API ExtJS dans sa version 2.0.2.
L’API ne contient donc quasiment que des classes dont les méthodes font une redirection native vers le code Javascript d’ExtJS.
On retrouvera donc tout ce qui se fait dans ExtJS avec des composants très puissants comme :

• Arbres : éditable, drag & drop (arbre vers arbre ou tableau), tri, checkbox…,
• Layouts : horizontal, vertical, accordéon…,
• Liste : basique, listes liées, live (suggest), paginé…,
• Tableau : éditable, tableaux groupés, JSON ou XML, chargement local ou distant, checkbox…,
• Formulaire : à onglets, fieldset, multi-colonnes, binding avec un tableau…,
• Éléments redimensionnables, déplaçables…
• Widgets bien stylés et des thèmes out-of-the-box

Le point noir reste toutefois la Javadoc, même si celle-ci s’étoffe au fur et à mesure des sorties de GWT-Ext (gros efforts fournis entre les versions 2.0.2 et 2.0.5). Elle reste cependant insuffisante. On pourra tout de même se retourner sur la doc d’ExtJS (puisque ce n’est que du pur wrapping) mais dès que l’on souhaitera aller un peu plus loin avec les composants, il faudra mettre les mains dans le cambouis Javascript.

Ext-GWT (démo)

Le produit de la compagnie ExtJS adapté à GWT.
Ext-GWT prend le parti de tout réécrire en pur GWT i.e. il n’y a aucun Javascript externe, tout est en Java.
Autre atout, l’API utilise les mécanismes internes de GWT permettant une intégration standard des fonctionnalités comme le remote service en Callback, retour JSON, XML… mais aussi du Java 5 (generics, enums et varargs).
On retrouve, sans surprise, les mêmes composants que pour GWT-Ext.
A noter enfin 3 licences disponibles pour le produit (commercial, open source ou revendeur).

Smart-GWT (démo)

Sanjiv Jivan a encore frappé !
Après son wrapping complet d’ExtJS avec GWT-Ext, il s’attaque cette fois-ci à la librairie SmartClient avec sa nouvelle API SmartGWT (nous vous en parlions dans une précédente revue de presse).
Le wrapping est encore une fois très complet : tous les composants de SmartClient sont présents dont :

• Arbre : colonne bloquée, drag & drop entre de nombreux composants, data binding multiples…,
• Slider, effects, animations, dialogs, look & feel, …
• Tableau : filtres, interactions avancées, …
• Tile (démo),
• Liste-Tableau, Calendrier (à la outlook), load on demand, …

On retrouvera aussi, et sans surprise, la plupart des composants combobox, radio, field, … d’autres librairie du même type.

Rialto-GWT (démo)

De même que pour Ext-GWT, Rialto-GWT dans sa version 2.0 nous propose d’utiliser GWT 1.5 donc Java 5.
L’API utilise aussi les mécanismes internes à GWT, le Wrapping Javascript est présent mais l’abstraction avec les classes Java rend l’utilisation très simple.
A noter toutefois une Javadoc de composants peu fournie…
Les composants principaux sont proches de ceux d’Ext-GWT.

Tatami (Dojo) (démo)

Encore une célèbre librairie Javascript porté en GWT : Dojo !
Une fois de plus, on retrouve le support de GWT 1.5, des tableaux en tout genre, des sliders, des pickers…

Autres…

D’autres librairies/codes sont disponibles sur la plupart des sites d’informations GWT, on trouvera ainsi quelques wrapper Script.aculo.us (ici ou là) mais aussi des wrapper jQuery (avec entre autre GQuery).

APIs générales

I18N

GWT gère nativement l’internationalisation, donc pas de librairies externes pour cette fonctionnalité.
L’utilisation est simple :

• un fichier properties contenant toutes nos clés,
• des interfaces (I18NConstants, I18NMessages…) Java permettant de faire appel à ces clés,
• une entrée dans notre module.gwt.xml avec si besoin la locale par défaut,
• une locale pouvant être définie au runtime, dans la JSP ou dans l’URL.

Logs (demo)

Un logger côté client très complet avec différents niveaux de logs : info, warn, debug, error et fatal.
De nombreux loggers sont disponibles comme le ConsoleLogger, le GWTLogger ou bien encore le FireBugLogger.

Google API

Gears, gadgets, Ajax Search et Maps, voici ce que propose la librairie de Google.
À noter que Visualization est en release candidate.

Maths

Émulation de BigInteger et BigDecimal avec un grand nombre de méthodes (add, subtract, multiply, divide, abs, negate, compareTo, equals, toString…).

Et bien d’autres encore !

A chercher/récupérer au besoin

On pourra rapidement citer GWTEventService (qui permet entre autre de faire du pushing / comet), PureMVC (MVC pour GWT) ou bien encore Goda-Time (Joda-Time pour GWT !).

Conclusion

Ce petit tour d’horizon de la galaxie GWT nous permet de retenir 3 choses : vous avez dit galaxie ?, [Mode gros doutes] Tu penses que c’est possible ? et enfin ça ressemble vraiment à un puzzle cette techno….

Galaxie ? On peut se poser la question dans le sens où, si l’on creuse un peu, on trouve en effet quelques APIs très bien faites… mais elles sont tout de même rares ! Après plus de 2 ans d’existence, on a tout de même l’impression que cette techno se cherche encore et que, du coup, la communauté J2EE n’a pas encore confiance en GWT pour démarrer ses projets. Ce manque d’API robuste ne fera que renforcer cette tendance.

Est-ce possible ? Réponse : Google est ton ami Très peu de sites (comme par exemple onGWT) référencent ce qui se fait en GWT au niveau des outils, des frameworks… Il devient assez laborieux de trouver une API pour un besoin spécifique. N’oublions pas que GWT émule les packages java.util, java.lang et java.io. Suffisant pour certains projets, mais pour de grosses applications de gestion il en faudra d’autres…

Un puzzle ! C’est certainement ce qui ressort le plus des projets GWT. Les librairies se récupèrent à droite, à gauche sur Google, il y en a partout avec peu de référencement… GWT devrait peut-être intégrer directement des APIs reconnues qui ont fait leurs preuves (comme par exemple Java 7 avec Joda-Time)…

Autrement dit, et c’est aussi une des conclusions de GWT in Action, GWT permet de développer très facilement des applications Ajax sans forcément connaitre Javascript (tout en laissant la possibilité de coder directement en Javascript). Il y a bien sûr encore des choses à revoir/améliorer mais le langage est en très bonne voie et les librairies existantes font le travail demandé.

Cependant, devez-vous foncer tête baissée sur GWT car vous démarrez un nouveau projet Web / Ajax et vous ne savez pas quelle technologie choisir (GWT, Flex, Silverlight, JavaFX…) ? Impossible de répondre de manière générale pour tous les projets, cela dépend du back-end existant, des besoins du projet, du temps imparti… Sachez en tout cas que GWT est un excellent compromis entre Ajax, Java et Javascript et que personnellement, sur les projets auxquels j’ai participé, je ne regrette absolument pas son utilisation !

RIA Contest : Flex / Silverlight / GWT / Echo3 / JavaFX

Après le Xebia Web Framework Contest de l’année dernière, le thème du XKE du mois d’Octobre était un nouveau contest dédié aux RIA.

Le but de cette journée était de développer une application de gestion de playlist de morceaux de musique. En promoteurs des méthodes Agiles, les spécifications furent données sous forme d’un Product Backlog. Trois sprints d’une durée de 90 minutes ont permis à tous de suivre l’évolution des différentes réalisations. Un web service SOAP fournissait les différentes données: Artiste, Album, Titres et Pochettes d’album.

Cinq équipes ont été constituées, cinq frameworks ont donc été choisis :

• Flex 3
• Silverlight 2.0 beta 2
• Google GWT 1.5
• Echo3
• JavaFX Preview SDK

Au terme de cette journée, chaque équipe a pu exprimer un retour d’expérience significatif.

Lire cet article »

Diagnostic d’une JVM à distance

Développer une application Java, c’est bien. La rendre performante, c’est mieux.

Cependant, qui dit « performance », dit « mesure ». En effet, il est nécessaire de pouvoir :

• connaître les paramètres de lancement de la JVM,
• mesurer l’empreinte mémoire et le comportement du Garbage Collector,

Cet article va décrire dans une première partie les différents outils permettant de collecter ces informations en local. La seconde partie se concentre sur les moyens pour obtenir ces mêmes informations à distance.

Lire cet article »

Analyse mémoire d’une JVM

Mardi, 10 heures
- La production « Allo, le projet, depuis 10 minutes on voit passer des messages ‘OutOfMemoryError’. Que fait-on ? « 
- Le projet « Augmentez la mémoire de la JVM, doublez-la valeur de l’option -Xmx « 

Mardi, 13 heures
- La production « Allo, le projet, depuis 5 minutes on voit encore passer des messages ‘OutOfMemoryError’. Que fait-on ? « 
- Le projet « Augmentez la mémoire de la JVM, doublez encore la valeur de l’option -Xmx « 

Mardi 18 heures
- La production « Allo, le projet, depuis 2 minutes on voit passer encore des messages ‘OutOfMemoryError’. Que fait-on ? « 
- Le projet « Tut, tut, tut,….. »
- La production « Plus d’équipe projet, la nuit va être longue… »

Cette petite scène est un classique, un air de déjà-vu mais que faire ? Si votre application a déjà subi une batterie de tests techniques, augmenter la mémoire est rarement la bonne solution. La scène décrite ci-dessus laisse penser à ce que l’on appelle classiquement une Fuite Mémoire (Memory Leak). En réalité, avec les JVM récentes, la fuite mémoire n’existe pas, je préfère parler d’accumulation d’objets non désirés. Cet article va vous montrer comment débusquer cette accumulation avec les outils jmap, jhat et Eclipse Memory Analyser.

Lire cet article »

Dans cet article, nous présenterons une solution simple et propre pour vous permettre une meilleure intégration d’Hibernate avec GWT.

Ce billet se découpe de la façon suivante :

• Nous commencerons par introduire la problématique d’intégration d’Hibernate avec GWT.
• Nous introduirons ensuite une solution pour faire cohabiter Hibernate avec GWT.
• Nous proposerons ensuite une solution légère et transparente pour intégrer Hibernate avec GWT.
• Nous détaillerons ensuite la procédure d’intégration de la solution sur votre projet.
• Et nous terminerons par un petit retour d’expérience.

Introduction

L’idée de base est d’utiliser mes objets du Domaine directement dans la couche présentation. Google Web Toolkit se basant sur Java, cela semblait l’une des forces de cette union. Mais malheureusement, les divergences techniques rendent la tâche difficile.

Plusieurs raisons empêchent d’utiliser les objets du Domaine directement dans la couche présentation :

• Héritage différent : Les objets Java échangés entre le client et le serveur doivent implémenter une interface de sérialisation Google IsSerializable, tandis que les classes Hibernate implémentent l’interface Serializable. Autre problème gênant, le compilateur GWT dans sa version 1.4 ne supporte pas l’interface Java Seriablizable et affiche une erreur.
• Types de données incompatibles : Les classes PersistentSet et java.sql.DateTime utilisées par Hibernate ne sont pas reconnues par le compilateur GWT.
• Chargement partiel (Lazy-Loading) : GWT ne sait manipuler que des POJO (Plain Old Java Object) et non des objets Hibernate. À l’exécution, Hibernate remplace les instances par des Proxies, alors que JavaScript, mis en œuvre par GWT, accepte uniquement les types primitifs et les POJO qui en sont composés. Or une classe Proxy n’est pas un type primitif, ni un type déclaré comme sérialisable en JavaScript.

Toutefois, intégrer Hibernate avec GWT est possible. Mais doit-on abandonner l’idée d’utiliser les objets du Domaine directement dans la couche présentation ? GWT 1.5 est peut-être la solution.

Faire cohabiter GWT et Hibernate

Une solution consiste à créer une hiérarchie de classes DTO correspondant à la hiérarchie des classes Hibernate, puis à cloner les objets du Domaine en objets DTO afin de les véhiculer vers la couche présentation sans difficulté. L’opération de clonage est prise en charge par la couche service qui assure les conversions Hibernate<->DTO en utilisant la librairie bean-lib. Celle-ci gère la duplication dynamique des objets Hibernate et convertit les données non supportées par GWT. Reste donc le problème de chargement partiel (Lazy loading) qui doit être géré par les développeurs.

Cette solution s’est avérée complexe et coûteuse en temps de développement. De plus, elle entraîne beaucoup trop de dépendances techniques. Elle a cependant le mérite de fonctionner.

Pour plus d’informations n’hésitez pas à consulter le billet suivant.

Hibernate4GWT arrive … GWT 1.5 aussi

Hibernate4GWT est une librairie Java prenant en charge la cohabitation dynamique d’Hibernate avec GWT. Elle permet ainsi d’utiliser les objets du Domaine directement dans la couche présentation sans se soucier de créer une hiérarchie de classes DTO juste vos objets du Domaine et du Domain Driven Architecture.

À noter que si vous utilisez toujours GWT 1.4, vos objets du Domaine doivent respecter la syntaxe Java 1.4, ce qui n’est pas facile à gérer et à intégrer dans du code existant. Et même avec Hibernate4GWT, vous êtes contraints de créer des classes DTO pour vous en sortir. Les objets du Domaine qui proviennent du serveur sont rapatriés et organisés dans les DTO par la librairie (l’opération de clone) et les objets DTO renvoyés vers le serveur sont également restitués par la librairie (l’opération de merge).

Avec l’arrivée de GWT1.5, vous n’avez plus ni à créer des classes DTO, ni à utiliser explicitement les opérations de merge et de clone. il est désormais possible d’utiliser vos objets du Domaine directement sur la couche présentation : d’où la nécessité de passer à GWT 1.5 pour une intégration transparente entre Hibernate et GWT.

La classe HibernateBeanManager, qui est le cœur de l’API, s’occupe de la suppression des proxies Hibernate. Elle gère la conversion des types de données incompatibles avec GWT en leur équivalent valide. Puis elle stocke les informations des attributs partiellement chargés (Lazy attributes) pour restituer correctement les objets du Domaine.

Hibernate4GWT, avec un minimum de configuration et des impacts techniques très légers, fournit un socle technique qui masque la complexité introduite par l’intégration d’Hibernate avec GWT et nous permet ainsi de respecter les règles de l’art.

Et concrètement qu’est-ce que ça donne ?!

Hibernate4GWT s’adapte à plusieurs types de configurations, selon vos besoins et les contraintes du projet dans lequel vous souhaitez l’intégrer.

Plusieurs configurations sont possibles :

• Stateless (configuration par défaut) : le serveur ne stocke aucune information sur l’état de la session. Les classes du Domaine doivent hériter de la classe LazyPojo pour stocker les attributs partiellement chargés (Lazy attributes).
• Dynamic Proxy : Une classe Proxy est générée par la librairie pour stocker les informations sur les attributs partiellement chargés (Lazy attributes) côté serveur et côté client. Les classes du Domaine doivent implémenter l’interface Serializable.
• Stateful : Les informations sur les attributs partiellement chargés (Lazy attributes) ne sont pas stockées dans les POJO mais dans la session HTTP. Les classes du Domaine ne nécessitent aucun héritage technique, mais votre serveur devient stateful (sticky session).
• Java5 support : GWT 1.4 ne supporte pas la syntaxe Java 5, Hibernate4GWT permet de cloner dynamiquement les classes du Domaine Java 5 en DTO associés compatibles Java 1.4. Pour cela, ces classes DTO doivent avoir le même nom que les classes du Domaine (placées dans un package différent) et doivent hériter de la classe LazyPojo.

Pour démarrer, vous devez d’abord choisir une configuration pour votre projet. Pour un nouveau projet, ou si vous avez la possibilité d’ajouter des héritages techniques dans vos classes du Domaine, l’auteur de la librairie recommande la configuration Dynamic proxy ou le mode Stateless. Sinon, si vous ne voulez pas modifier l’existant, vous pouvez utiliser le mode Stateful ou la configuration Dynamic proxy si vos classes du Domaine implémentent l’interface Serializable.

À noter que si vous utilisez des classes du Domaine Java 5 et GWT 1.4, vous êtes contraints d’utiliser la configuration Java5 support.

Intégrer Hibernate4GWT dans votre projet

Installation

L’installation d’Hibernate4GWT dans un projet GWT :

• Décompression de l’archive hibernate4gwt-1.x.x.zip,
• Ajout d’hibernate4gwt.jar et des dépendances présentes dans le répertoire lib dans le classpath de votre projet GWT,
• Édition du fichier de configuration GWT :

Avec GWT 1.4 :

<module>
       <!-- Inherit the core Web Toolkit stuff -->
       <inherits name='com.google.gwt.user.User'/>
       <!-- Inherit the hibernate4gwt stuff -->
       <inherits name='net.sf.hibernate4gwt.Hibernate4Gwt14'/>
       <!-- Specify the app entry point class -->
       <entry-point class='...'/>
       <!-- Additional source path -->
       <!-- To add for java5 support configuration -->
       <source path='dto'/>
       <!-- To add for other configurations -->
       <source path='domain'/>
       <source path='client'/>
       <!-- To add for dynamic proxy configuration -->
       <generate-with class="net.sf.hibernate4gwt.rebind.Gwt14ProxyGenerator">
          <when-type-assignable class="java.io.Serializable" />
       </generate-with>
       <!-- Servlet path -->
</module>

Avec GWT 1.5 :

<module>
       <!-- Inherit the core Web Toolkit stuff -->
       <inherits name='com.google.gwt.user.User'/>
       <!-- Inherit the hibernate4gwt stuff -->
       <inherits name='net.sf.hibernate4gwt.Hibernate4Gwt15'/>
       <!-- Uncomment if your Domain class use JPA mapping annotations -->
       <!-- <inherits name='net.sf.hibernate4gwt.emul.java5.ejb3.Ejb3'/> -->
       <!-- Specify the app entry point class -->
       <entry-point class='...'/>
       <!-- Additional source path -->
       <!-- To add for java5 support configuration -->
       <source path='dto'/>
       <!-- To add for other configurations -->
       <source path='domain'/>
       <source path='client'/>
       <!-- To add for dynamic proxy configuration -->
       <generate-with class="net.sf.hibernate4gwt.rebind.Gwt15ProxyGenerator">
         <when-type-assignable class="java.io.Serializable" />
       </generate-with>
       <!-- Servlet path -->
</module>

Classes du Domaine

Pour utiliser vos classes du Domaine dans GWT, il y a quelques détails à régler :

• Ajouter vos classes du Domaine dans le classpath de l’application GWT,
• Implémenter l’interface Serializable dans vos classes du Domaine pour le mode Stateful et la configuration Dynamic proxy,
• Étendre la classe net.sf.hibernate4gwt.pojo.java14.LazyPojo (GWT 1.4) ou net.sf.hibernate4gwt.pojo.java5.LazyPojo (GWT 1.5) pour le mode Stateless,
• Créer une hiérarchie de classes DTO compatibles avec GWT 1.4 pour la configuration Java5 support.

Initialisation d’HibernateBeanManager

Lors l’initialisation de l’instance d’HibernateBeanManager, il faut lui associer une instance d’Hibernate SessionFactory. Cette configuration est à faire dans le code d’initialisation serveur.

Mode Stateless :

HibernateBeanManager.getInstance().setSessionFactory(sessionFactory);
// or HibernateBeanManager.getInstance().setEntityManagerFactory(emf);

Configuration Java5 support :

De plus, il faut également associer HibernateBeanManager à une instance de la classe DirectoryCloneMapper pour le mapping entre les classes du Domaine et les classes DTO.

HibernateBeanManager.getInstance().setSessionFactory(sessionFactory);
// or HibernateBeanManager.getInstance().setEntityManagerFactory(emf);
DirectoryCloneMapper cloneMapper = new DirectoryClassMapper();
cloneMapper.setRootDomainPackage("com.testing.server.domain");
cloneMapper.setRootClonePackage("com.testing.dto");
cloneMapper.setCloneSuffix("DTO");
HibernateBeanManager.getInstance().setClassMapper(cloneMapper);

Mode Stateful :

En plus de la configuration de base, il faut associer une instance d’HttpSessionPojoStore à l’instance d’HibernateBeanManager.

HibernateLazyManager.getInstance().setPojoStore(new HttpSessionPojoStore());
HibernateLazyManager.getInstance().setSessionFactory(sessionFactory);
// or HibernateLazyManager.getInstance().setEntityManagerFactory(emf);

Configuration Dynamic proxy :

Il est aussi nécessaire d’associer une instance de la classe ProxyClassMapper à l’instance d’HibernateBeanManager pour les opérations de clone et de merge.

HibernateBeanManager.getInstance().setSessionFactory(sessionFactory);
// or HibernateBeanManager.getInstance().setEntityManagerFactory(emf);
HibernateBeanManager.getInstance().setClassMapper(new ProxyClassMapper());

Service distant

L’implémentation du service GWT distant doit hériter de la classe HibernateRemoteService au lieu de la classe RemoteServiceServlet.

public class ProductRemoteImpl extends HibernateRemoteService
                            implements ProductRemote
{
    ...
    public Product getProduct(int id)
    {
         return _productDAO.getProductById(id);
    }
    public Product updateUser(Product product)
    {
         // Update the product in database
         _productDAO.updateProduct(product);
         // Send back a new clone (optimistic lock)
         return product;
    }
}

A noter qu’avec la configuration Java5 support, il faut merger les objets DTO en entrée et cloner les objets du Domaine en sortie.

public class ProductRemoteImpl extends HibernateRemoteService
                            implements ProductRemote
{
    ...
    public ProductDTO getProduct(int id)
    {
         return (ProductDTO) clone(_productDAO.getProductById(id));
    }
    public ProductDTO updateUser(ProductDTO productDTO)
    {
         // Update the product in database
         product = (Product)merge(productDTO);
         _productDAO.updateProduct(product);
         // Send back a new clone (optimistic lock)
         return (ProductDTO) clone(product);
    }
}

Conclusion

J’avais intégré l’API Hibernate4GWT sur un projet de petite taille avec une base de données de 10 tables et un nombre d’utilisateurs simultanés limité à 20. Lors de la mise en œuvre, l’API m’a facilité grandement la vie, et m’a permis une meilleure intégration d’Hibernate avec GWT. Je n’ai pas eu des problèmes particuliers en production ni d’impacts sur les performances de l’application, mais des questions se posent : peut-on utiliser l’API sur des grands projets ? Quel sera l’impact sur les performances lors de la montée en charge ?

Comme nous avons pu le voir, Hibernate4GWT est une petite librairie qui permet une intégration transparente et légère d’Hibernate avec GWT. L’auteur de la librairie nous promet beaucoup de choses dans l’avenir en renommant la librairie en Gilead ou Generic Light Entity Adapter, une nouvelle version Hibernate4ALL pour les technologies (Flex/BlazeDS, Web Services …).

Liens annexes :

• Présentation d’Hibernate4GWT sur le site officiel
• Présentation de Gilead sur le site officiel

Actualité éditeurs / SSII

• Coopération entre SpringSource et Adobe
• tc Server : SpringSource signe la première offre open source professionnelle sur Tomcat

Le coin de la technique

• Les orientations de GWT : Roadmap GWT 1.6
• Java 7, ce n’est pas pour tout de suite…
• Sortie de Grizzly 1.9
• Présentation de Google Guice 2.0

Actualité éditeurs / SSII

Coopération entre SpringSource et Adobe

SpringSource renforce son positionnement sur les RIA en signant un accord de partenariat avec Adobe Systems. Un partenariat dont l’objectif est de simplifier le développement et le déploiement des applications RIA se basant sur Adobe Flex et Spring.

Adobe et SpringSource se sont alliés pour travailler sur Spring BlazeDS Integration, un projet open source qui vise à simplifier l’intégration de Spring avec Adobe’s BlazeDS. Une version bêta est prévue dans une ou deux semaines.

SpringSource a prévu pour l’année prochaine un nouvel adaptateur pour Adobe LiveCycle Data Services ES, qui permet d’instaurer un moteur d’échanges de données entre les applications RIA basées sur Flex et Spring.

Ce rapprochement permet à SpringSource de renforcer son positionnement sur les RIA.

tc Server : SpringSource signe la première offre open source professionnelle sur Tomcat

Philip Hanik présente dans « SpringSource tc Server – The Tomcat you know. The enterprise capabilities you need. » le périmètre du nouvellement annoncé tc Server.

On y retrouve tous les ingrédients de la version commerciale d’un produit open source professionnel :

• Support : de l’entrée de gamme « heures ouvrées » à la formule « mission critique 24×365″ avec une réponse dans l’heure
• Packaging : livraison packagée avec les patchs nécessaires au client et des configurations et scripts de démarrage optimisés pour les différentes plateformes (32 vs 64 bits, etc).
• Indemnisation : en cas de problème juridique concernant la nature Open Source de Tomcat.
• Administration centralisée : ajout de mécanismes de gestion centralisée de serveurs Tomcat (configuration des serveurs, déploiement d’applications clusterisées [1] )
• Audit : suivi des opérations réalisées sur les serveurs.
• Monitoring et alertes : reprise des fonctionnalités de SpringAMS ( Hyperic HQ + extensions de monitoring de Spring Framework).
• Diagnostique : détection de thread lock, corrélation des erreurs avec les urls et les threads, mécanisme de First Failure Data Capture (FFDC).

Si les premiers points étaient déjà couverts par des offres de support commercial (e.g. SpringSource Enterprise Ready Server), c’est la première offre de type Open Core Licensing pour Tomcat (noyau open source + extensions commerciales orientées administration).
Les éditeurs incitaient jusqu’à présent leurs clients intéressés par un support Tomcat à faire un upsale sur serveur plus sophistiqué (JBoss App. Server, Websphere App. Server Community Edition, Spring dm Server, etc).

Quel intérêt de payer 500$/an/cpu pour tc Server plutôt que d’utiliser Tomcat ? Outre le support qui sera important pour de nombreux exploitants, les fonctionnalités d’exploitations et de supervision présentent un intérêt à prendre en compte.

Nous noterons pour conclure que l’ensemble des fonctionnalités annoncées ne sera pas disponible dès la version 1.0 de tc Server.

[1] tc Server permet notamment des opérations install/update/start/stop/uninstall/rollback phasées sur des clusters pour mettre à jour les noeuds les uns après les autres sans arrêt du service.

Le coin de la technique

Les orientations de GWT : Roadmap GWT 1.6

La version actuelle de GWT est la 1.5.3. L’équipe GWT a présenté sur son blog officiel les orientations de GWT 1.6 et des prochaines versions : What’s ahead for Google Web Toolkit.

Ainsi, on observe que l’équipe GWT s’attaque à différents points :

• Performance
• De compilation pour améliorer la productivité du cycle de développement
• D’exécution : optimisation de l’utilisation de la classe StringBuilder par exemple, des composants (cf LazyPanel plus bas)
• S’approcher des bonnes pratiques éprouvées dans la communauté Java : voici la spécification : Design Doc for 1.6 WAR structure. Ainsi, il sera possible de livrer les fichiers statiques (images, css) dans un répertoire hors de la WebApps. Actuellement tout est chargé via le classpath. Ces ressources statiques pourront être « akamai-llisées » et aussi relivrées indépendamment de la WebApp.
• Richesse des composants : intégration de nouveaux composants qui étaient dans l’incubateur de composants GWT
• Un calendrier : DatePicker
• Un Panel qui permet l’affichage du contenu d’un Panel lorsqu’on le souhaite afin d’améliorer les performances d’affichage : LazyPanel
• Migration de Tomcat à Jetty pour le Hosted Mode Server.

Cette version 1.6 est prévue pour le premier trimestre 2009.

Ils parlent aussi de la Roadmap GWT :

• Marwan KHELIF avec GWT 1.6 : quoi de neuf ?
• Thomas Recloux avec Roadmap GWT 1.6
• A voir aussi sur le site officiel de GWT Making Gwt Better

Java 7, ce n’est pas pour tout de suite…

Initialement prévu pour début 2009, nous n’avons toujours pas (peu) eu de détails officiels concernant celui-ci. Vous vous en doutiez, Java 7 ne sortira pas demain. Suite à une des conférences de Devoxx, nous en savons désormais un peu plus sur ce sujet : sa sortie décalée à début 2010.

Est-ce si lointain ? Pas vraiment, à la vue de tous les différents qui tournent autour du Jdk 7 (modularité, closures …), il ne sera probablement pas trop d’une année pour résoudre tous ces sujets de discordes. Pour y arriver, des choix rapides et judicieux devront être pris, cette même conférence en a d’ailleurs laissé sous-entendre quelques-uns, en voici les grandes lignes.

• Modularité : point central de Java7, après la mort programmée de la JSR-277, la réconciliation avec OSGi devra sans doute passer par la JSR-294 (sous-jacente) – les superpackages. Si quelques changements récents offrent des perspectives de réconciliation, l’aventure ne fait que commencer pour le sujet le plus sensible du Jdk 7. Le nouveau projet Jigsaw qui doit permettre de partager à la communauté l’avancement des travaux est déjà fortement controversé.
• Les closures : la grande blague ; le jdk7 ne proposera finalement pas cette fonctionnalité. Aucun consensus n’ayant été trouvé à ce sujet par la communauté : celles-ci sont pour le moment déscopées.
• Les nouvelles API : aucun scoop à ce sujet. Nous en connaissions déjà les principales : nio2 (JSR-203) et JodaTime (JSR-310).
• Évolutions du langage : C’est Joseph D. Darcy qui sera chargé de définir et regrouper les petites évolutions du langage pour le Jdk 7. Pour cette future nouvelle JSR (sa 3e après JSR-13 et JSR-269), il a prévu d’impliquer d’avantage la communauté pour ce point facilement sujet à controverse. Son idée est de proposer et demander les retours de la communauté en amont du processus pour éviter toute controverse. Avant même que la JSR ne soit proposée en draft, les grandes lignes de celles-ci devraient en être définies, disponibles et discutées sur un projet spécifique de l’open JDK. Cette JSR est prévue pour sortir au cours du premier semestre 2009.

À ce propos, vous vous demandez peut-être comment va-t-il s’y prendre pour intégrer ces changements ? C’est peut-être également l’occasion de revenir sur un de ces anciens articles présentant les différentes étapes à suivre pour ajouter des fonctionnalités dans le jdk .

Sortie de Grizzly 1.9

Grizzly 1.9 est sorti, à noter que la version 2.0 est prévue pour la fin de l’année. Grizzly est un framework Sun pour aider les développeurs à construire des serveurs robustes et scalables en utilisant l’API Java NIO (et NIO 2). Il met aussi à disposition le support de différents protocoles :

• Glassfish utilise Grizzly comme HTTP Listener.

  Les nouveautés de cette version sont :

  • Support des I/O asynchrones (NIO2, Xebia en avait parlé), cela permet d’améliorer grandement les performances
  • Support des HTTP write asynchrones
  • GrizzlyAdapterChain supporte maintenant plusieurs adapteurs et peut transformer les requêtes d’entrées à la volée
  • Le framework Comet a amélioré ses performances. À voir aussi un exemple d’implémentation utilisant GrizzlyComet : Writing a Twitter like application using Grizzly Comet part 1: The Servlet.

  Présentation de Google Guice 2.0

  La sortie Guice 2.0 est attendue pour décembre 2008 donc très prochainement.

  À l’image de Spring, Guice est un framework d’injection de dépendances. Cependant, Guice se démarque de Spring dans la mesure où Guice fonctionne sans aucun XML. La configuration et le tissage des dépendances se font de manière programmatique. Il utilise les annotations du langage Java 5.

  Guice se veut être un framework léger et facile à intégrer. Il existe d’ailleurs un plugin Struts pour gérer l’injection de dépendances en Guice.

  L’article Dependency injection with Guice de Nicholas Lesoecki, employé à Google, présente le fonctionnement de Guice.

  Voici le fonctionnement du Guice d’un point de vue programmatique :

  @Inject
  public FrogMan(Vehicle vehicle) {
    this.vehicle = vehicle;
  }
  

  Le tissage s’effectue aussi de manière programmatique, ce qui le différencie radicalement de Spring :

  public class HeroModule implements Module {
    public void configure(Binder binder) {
      binder.bind(Vehicle.class).to(FrogMobile.class);
    }
  }
  

  Le tissage est donc réalisé dans un Module.

  Ensuite le contexte Guice se démarre comme suit :

  public class Adventure {
    public static void main(String[] args){
      Injector injector = Guice.createInjector(new HeroModule());
      FrogMan hero = injector.getInstance(FrogMan.class);
      hero.fightCrime();
    }
  }
  

  Il est possible d’injecter une dépendance par :

  • Constructeur, c’est la méthode la plus simple, par forcément la plus élégante en Spring
  • Méthode
  • Attribut de classe

  Cependant, un problème peut se poser par rapport à l’exemple précédent : comment injecter plusieurs véhicules ? Solution : il faut nommer les cibles en créant ses propres annotations pour l’injection :

  @Inject
  public WeaselGirl(@Fast Vehicle vehicle) {
    this.vehicle = vehicle;
  }
  

  Code source du tissage :

  public class HeroModule implements Module {
   public void configure(Binder binder) {
      binder.bind(Vehicle.class).to(FrogMobile.class);
      binder.bind(Vehicle.class).annotatedWith(Fast.class).to(WeaselCopter.class);
    }
  }
  

  Code source de la déclaration de l’annotation :

  @Retention(RetentionPolicy.RUNTIME)
  @Target({ElementType.FIELD, ElementType.PARAMETER})
  @BindingAnnotation
  public @interface Fast {}
  

  Les nouveautés de cette version sont présentées sur le site officiel : Changes in Guice 2. On y trouve entre autre :

  • Implémentation de l’AOP
  • Surcharge du binding d’un module à un autre
  • Binding des éléments d’un tableau Set ({{Multibinding}}) ou Map ({{Mapbinding}})
  • Convertisseur de type branchable, par exemple, pour convertir une chaîne de caractères en date

  Même si Guice est loin d’avoir la maturité de Spring ou même autant de fonctionnalités que ce dernier, il propose une approche de l’injection de dépendances très pragmatique.

  Une étude sur la comparaison des versions Guice 1.0 et Spring 2.0.2 (Guice vs. Spring JavaConfig: A comparison of DI styles) arrive aux conclusions suivantes :

  • Performance : Guice est plus rapide, mais est-ce vraiment important car généralement les dépendances sont chargées au démarrage de l’application ?
  • Modèle de programmation Guice plus intrusif : il est dommage de devoir mettre un @inject dans les objets Guice qui peuvent être injectés
  • Spring AOP est plus puissante
  • Guice est plus facile à intégrer (il y a seulement 2 Jars à intégrer)

  À voir également : deux liens intéressants sur l’injection de dépendance issus de la documentation de PicoContainer, autre implémentation pour l’injection de dépendance :

  • Design patterns, règles a avoir en tête lorsque l’on fait de l’injection de dépendance
  • Inversion of Control history, tout sur l’injection de dépendance
  ]]> http://blog.xebia.fr/2008/12/15/revue-de-presse-xebia-87/feed/ 4 http://blog.xebia.fr/2008/12/08/revue-de-presse-xebia-86/ http://blog.xebia.fr/2008/12/08/revue-de-presse-xebia-86/#comments Mon, 08 Dec 2008 18:13:36 +0000 Xebia France http://blog.xebia.fr/?p=1112
  La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

  Actualité éditeurs / SSII

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

  Agilité

  • L’agilité chez IBM

  RIA

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

  Le coin de la technique

  • Nouveau mode hosté pour GWT 2.0

  Actualité éditeurs / SSII

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

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

  Les principaux composants de JBoss AS 5

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

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

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

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

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

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

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

  SpringSource tc Server : un dm Server sans ses modules

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

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

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

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

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

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

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

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

  Quoi de neuf dans Spring 3.0 M1 ?

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

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

  Modifications techniques internes :

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

  Nouvelles fonctionnalités :

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

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

  Sortie de Spring Integration 1.0.0

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

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

  Sortie d’Hibernate Search 3.1

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

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

  Agilité

  L’agilité chez IBM

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

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

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

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

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

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

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

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

  RIA

  Au pied du sapin : JavaFX GA

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

  Silverlight sous Linux

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

  Le coin de la technique

  Nouveau mode hosté pour GWT 2.0

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

  ]]> http://blog.xebia.fr/2008/12/08/revue-de-presse-xebia-86/feed/ 3 http://blog.xebia.fr/2008/12/01/revue-de-presse-xebia-85/ http://blog.xebia.fr/2008/12/01/revue-de-presse-xebia-85/#comments Mon, 01 Dec 2008 17:54:18 +0000 Xebia France http://blog.xebia.fr/?p=1096
  La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

  Agilité

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

  RIA

  • FlexMonkey 0.5
  • Sortie de SmartGWT

  Le coin de la technique

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

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

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

  Agilité

  Scrum et XP depuis les tranchées

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

  Scrum de scrums

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

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

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

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

  RIA

  FlexMonkey 0.5

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

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

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

  Sortie de SmartGWT

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

  Les plus de SmartGWT par rapport à GWT-Ext :

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

  Les moins :

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

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

  Le coin de la technique

  Améliorez la testabilité de votre code

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

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

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

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

  Nexus pour chercher dans les repositories Maven

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

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

  Distribuez vos tests JUnit avec GridGain

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

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

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

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

  Tomcat : Trucs et astuces des pros de SpringSource

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • JBoss MicroContainer et OSGi : quel positionnement tenir quand Sun a mis en retrait HK2 au profit d’Apache Felix.
  • JBoss Messaging vs. RedHat MRG : quelles synergies ? Interopérables à l’instar de Websphere MQ (aka MQ Series) et Websphere Embedded Messaging Engine ? AMQP plaît à RedHat, JBoss est-il aussi intéressé ?
  • JBoss AS 5 : comment le précurseur des implémentations EJB 3 et JPA se retrouve t’il parmi les retardataires des certifiés Java EE 5 ? Le chantier de refonte a-t-il été trop ambitieux ?
  • Data Grids : pourquoi JGroups, le coeur de communication de JBoss Cache est-il un projet extérieur à JBoss ? Les Data Grids font-elles parties des priorités de JBoss ?
  • JBoss, Fondation Apache et brique HTTP de JBoss AS : JBoss semble moins impliqué qu’auparavant dans Tomcat et vient de lancer son mod_cluster à l’extérieur du projet Apache HTTP Server et de son mod_proxy_balancer. À l’heure où les architectures Comet imposent des évolutions importantes des moteurs de Servlet, JBoss compte-t-il s’éloigner de Tomcat ?
  ]]> http://blog.xebia.fr/2008/12/01/revue-de-presse-xebia-85/feed/ 0 http://blog.xebia.fr/2008/11/03/revue-de-presse-xebia-81/ http://blog.xebia.fr/2008/11/03/revue-de-presse-xebia-81/#comments Mon, 03 Nov 2008 16:55:56 +0000 Xebia France http://blog.xebia.fr/?p=950
  La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

  Actualité éditeurs / SSII

  • SpringSource rejoint le comité exécutif du JCP pour Java SE et EE
  • Microsoft embrasse les Middlewares de Message Open Source

  Agilité

  • Scrum et le lavage en machine

  RIA

  • X2O framework ou comment faciliter la réalisation d’applications Flex.
  • Pivot 1.0 : développer des applications RIA en Java et XML
  • Testez vos applications Flex avec Fluint

  Le coin de la technique

  • Envers rejoint Hibernate

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

  • GWT au Paris JUG de Novembre
  • XKE, le programme de la session de Novembre

  Actualité éditeurs / SSII

  SpringSource rejoint le comité exécutif du JCP pour Java SE et EE

  SpringSource était déjà présent dans des Expert Groups clefs de Java EE (JSR-316 : JavaEE 6, JSR-291 : Dynamic Component Support for Java SE – aka OSGi, etc). Rod Johnson fait un pas de plus dans cet organisme en se faisant élire membre du JCP Executive Committee for Java SE/EE, le comité qui encadre les JSR relatives à Java SE et Java EE. L’Executive Committee est à l’image de l’ouverture du JCP ; on y retrouve principalement des grands acteurs du monde Java (IBM, Oracle, Sun, etc) mais aussi l’ancien trublion aujourd’hui assagi des serveurs Java EE JBoss/Redhat et des membres individuels comme l’universitaire Doug Lea ou le polémique auteur du Bile Blog Hani Suleiman (qui ne s’est pas représenté cette année).

  Rod Johnson place son mandat sous le signe de la transparence, de l’écoute de la communauté et du pragmatisme (Cf. A word about the election et our approach to the JCP). Cette vision s’inscrit dans la tendance actuelle du JCP dont les travaux s’ouvrent chaque année un peu plus (participation gratuite pour les individuels, publicité des débats, Reference Implementation (RI) et Technology Compatibility Kit (TCK) open source, etc).

  La présence de SpringSource dans les instances dirigeantes du JCP participera au maintien de l’équilibre entre « petits et grands » dans un monde en phase de concentration (Oracle/BEA, IBM/ILog, Progress/IONA, etc). De plus, on peut espérer que Rod Johnson facilite le rapprochement entre le JCP et l’OSGi Alliance dont le fonctionnement ressemble plus au JCP d’il y a 10 ans (participation payante, membres essentiellement commerciaux, confidentialité des débats, des RI et des TCK, etc) qu’à la communauté que nous connaissons aujourd’hui : certes perfectible mais exemplaire par son ouverture.

  Pour en savoir plus : SD Time : Rod Johnson on a mission to open up JCP, The 451 group : Spring forward.

  Microsoft embrasse les Middlewares de Message Open Source

  Microsoft avait déjà surpris la communauté Open Source cet été en devenant Platinium Sponsor de la Fondation Apache. La firme de Redmond poursuit aujourd’hui son rapprochement avec le monde Open Source en rejoignant l’AMQP Working Group pour soutenir le développement du protocole open source de middleware de messages AMQP destiné à concurrencer le duopole d’IBM et de Tibco (respectivement Websphere MQ et RendezVous).

  Au delà de l’effet d’annonce, comment la firme de Redmond concrétisera-t-elle cet engagement ? Microsoft refondra-t-il Microsoft Message Queing (MSMQ) pour implémenter AMQP ? Contribuera-t-il à un projet Open Source comme par exemple Apache QPid, projet largement supporté par Redhat qui en a fait le socle de sa solution Redhat Messaging ?

  En attendant plus de détails, ce ralliement pourrait d’une part être le soutien qui semblait manquer à AMQP pour prendre son essor et d’autre part être un différenciateur clef de Microsoft pour se lancer à l’assaut des parts de marché d’IBM et de Tibco.

  Pour en savoir plus : InteropNews : Microsoft embraces AMQP open middleware standard

  Agilité

  Scrum et le lavage en machine

  On connaissait la métaphore du Rugby pour expliquer Scrum, voici une comparaison plus originale : le lave-linge ! Le Touilleur Express fait l’analogie entre Scrum et le lavage en machine pour expliquer quelques notions :

  • Product backlog : le linge sale représente la liste des tâches à faire.
  • Itérations : le lavage s’effectue par cycle, comme le développement itératif.
  • Capacité non extensible : ne demandez pas à votre lave-linge de laver plus de linge que sa capacité (5kg), de même une équipe ne peut produire qu’une quantité limitée de fonctionnalités par itération.
  • Gestion de priorités : il faut trier le linge en fonction des priorités, si l’on a besoin de la chemise pour demain ou si elle peut attendre le prochain lavage.
  • Ne pas perturber l’itération : il est impossible d’arrêter un programme en cours pour y ajouter une chemise oubliée. L’itération ne doit pas être perturbée non plus.

  On pourrait rajouter qu’il faut éviter de mélanger les couleurs et les domaines métier, sinon le résultat pourrait déteindre !

  RIA

  X2O framework ou comment faciliter la réalisation d’applications Flex.

  Après Exadel Flamingo, voici un nouveau framework nous facilitant le développement d’applications Flex : X2O. Dans cet article, InfoQ interroge Ka Wai Cheung de We Are Mammoth sur ce nouvel outil. X2O est une plateforme permettant de réaliser des applications Flex sans toucher au code de la partie serveur. Grâce à ce framework, nous n’avons plus aucune intégration à réaliser, pas de base de données à mettre en place. Tout est géré par le framework.

  Il suffit pour cela de se créer un compte sur http://www.x2oframework.com/# puis de créer un modèle de données et de le soumettre à X2O.

  Celui ci va ensuite générer :

  • Un CMS sécurisé permettant de gérer les données.
  • Un fichier SWC contenant les value objects du modèle de données ainsi que les CRUDs basiques et les méthodes de chargement qui ont été configurés dans le CMS.
  • La documentation ActionScript 3 du projet.

  Le CMS généré comprend une base de données, des procédures stockées, une couche d’accès aux données et une couche web service. Il est hébergé par le site et à tout moment, le développeur peut modifier son modèle de données dans le CMS et régénérer la librairie swc et la documentation ActionScript 3. La librairie fournit également des fonctionnalités supplémentaires comme l’envoi d’email et l’upload de fichiers. La plus grosse tâche est maintenant de créer son application Flex et d’appeler les méthodes du fichier swc pour charger les bonnes données.

  Actuellement la version bêta est disponible et gratuite pour les développeurs. Ces derniers pourront donc tester ce framework (limité à deux projets par compte), donner leur avis et remonter des anomalies. La version définitive prévue en 2009 comportera probablement une version gratuite et une version payante sur plusieurs niveaux.

  Pivot 1.0 : développer des applications RIA en Java et XML

  Pivot est un framework Open Source pour le développement des applications RIA en Java. Ce dernier est le fruit d’un travail de l’équipe R&D de VMware, il fournit une alternative aux développeurs qui veulent développer leurs applications RIA en Java.

  Les applications Pivot sont construites en Java et XML. La structure de l’interface utilisateur est décrite au format XML avec un langage de description d’écrans appelé WTKX, la gestion des événements et la logique applicative sont écrites en Java.

  Pivot semble familier aux développeurs Swing, comme les deux utilisent Java2D et se basent sur une architecture MVC pour une séparation entre les données, la présentation et les traitements. Pivot fournit des composants graphiques dynamiques et réutilisables (panneaux, boutons, tables/grilles, boîtes de dialogues, menus et barres de menus …) pour créer des applications web de nouvelle génération.

  Les applications Pivot peuvent s’exécuter à l’intérieur d’un applet java ou à déployer en local, tous systèmes d’exploitation confondus.

  

  Le code source du projet est fourni sous licence Apache Version 2.0.
  Une démo de Pivot en action : http://pivot-toolkit.org/tutorials/demo.standalone.html.

  Testez vos applications Flex avec Fluint

  Lors de l’une de nos récentes revue de presse nous vous parlions de FlexMonkey, outil permettant d’enregistrer des tests fonctionnels à la manière d’un Selenium, mais sur des applications Flex.

  Dans cet article de Moxie Zhang, un autre outil nous est proposé et se nomme Fluint. A l’origine développé chez Digital Primates, cet outil est passé Open Source et permet de mettre en place des tests unitaires ainsi que des tests d’intégrations. En effet la majorité des outils ne permettent pas de tester les interactions (souvent asynchrones) entre les composants, et Fluint permet d’effectuer ce genre de tests.

  La documentation pour la mise en place est bien fournie, et permet de créer assez rapidement des suites de tests.

  A travers ces outils, nous voyons que les technologies RIA, et plus particulièrement Flex remportent de plus en plus de succès, alors qu’attendez vous pour franchir le pas ?

  Le coin de la technique

  Envers rejoint Hibernate

  Peu de temps après sa première release officielle, Adam Warski, développeur principal de JBoss Envers, a annoncé cette semaine sur son blog l’intégration de ce framework de versioning d’entités comme module d’Hibernate. S’il n’apparaît pas encore sur la page officielle du projet, les sources ont d’ores et déjà été migrées sur le repository d’Hibernate. Aucun tag Hibernate ne dispose d’Envers pour le moment. Son intégration n’est d’ailleurs pas complètement terminée, quelques modifications restent à régler avant sa première release sous ce nouveau nom. Par exemple, l’annotation @Versioned sera renommée @Audited pour éviter toute confusion avec @Version de JPA. La première version d’Hibernate proposant les fonctionnalités d’Envers devrait donc être la future 3.4.

  Pour mémoire, Envers vous permet de versionner simplement la plupart de vos mappings JPA et Hibernate. A l’image de Subversion, il offre un mécanisme de révisions et un moyen d’effectuer des recherches sur son historique.

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

  GWT au Paris JUG de Novembre

  Le prochain Paris JUG se tient demain 4 Novembre, dans les locaux de l’ISEP.

  Au programme de la soirée:

  • Une présentation de Google Web Toolkit, par Didier Girard, directeur technique de SFEIR.
  • Puis une démonstration de l’API Restlet portée sur GWT, Restlet-gwt, par Jérôme Louvel, l’auteur de Restlet.

  XKE, le programme de la session de Novembre

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

  • WSI-Basic profiles.
  • Java Rebel.
  • La galaxie GWT, un tour d’horizon des projets qui gravitent et améliorent le célèbre framework de Google.
  • DDD – Domain Driven Design.
  • Liquid Base, un outil qui gère les modifications de schéma de base de données.
  • Spring Dynamic Modules, l’OSGI vu à la sauce Spring.
  • Les outils de la JVM.

  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.

  ]]> http://blog.xebia.fr/2008/11/03/revue-de-presse-xebia-81/feed/ 1