Actualité éditeurs / SSII

• Sortie de RabbitMQ 2.0

Le coin de la technique

• Gestion automatique des ressources dans Java7 (ARM)

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

• Google et les brevets

Actualité éditeurs / SSII

Sortie de RabbitMQ 2.0

La sortie de la version 2.0 du serveur de messaging AMQP RabbitMQ vient d'être annoncée ici.
Cette release majeure vient avec une refonte importante et son lot de nouveautés :

• Une refonte de la gestion de la persistence permettant une alternative au moteur de persistence embarqué. Il sera possible de développer un support pour une base de données relationelle ou NoSQL ou tout autre data store.
• Le support de différents protocoles de messaging : AMQP (0-8 et 0-9-1), XMPP, STOMP, HTTP, SMTP... Il sera aussi possible d'ajouter de nouveaux protocoles à l'aide d'extensions.
• La mise en place d'une infrastructure ayant pour but de simplifier le développement d'outils pour la gestion et le monitoring de RabbitMQ.
• Une amélioration de la gestion des plugins (il n'est plus nécessaire de compiler les plugins, une version pré-compilée peut être directement chargée par RabbitMQ).

SpringSource qui a récemment racheté RabbitMQ (nous vous en avions parlé ici) propose de son côté un template reprenant les principes des templates jdbc, hibernate, jms ou encore LDAP encapsulant le client Java d'AMQP. Les utilisateurs habitués à JmsTemplate retrouveront donc leurs repères en utilisant l'AmqpTemplate du projet spring AMQP.

SpringSource/VMWare continue donc de faire évoluer son portefeuil de produits avec cette évolution majeure de RabbitMQ, qu'il considère comme une pièce essentielle à sa stratégie de développement du Cloud Computing (voir cet article de Rod Johnson).

Le coin de la technique

Gestion automatique des ressources dans Java7 (ARM)

Java7 suit son petit bonhomme de chemin sans qu'on ait encore une bonne visibilité sur la date de sortie officiel. Le build 105 de la version actuelle propose une nouvelle fonctionnalité très intéressante qui devrait facilité la vie de chaque développeur: l'Automatic Resource Management.

L'idée, proposée par Joshua Bloch depuis quelques années déjà, consiste à améliorer la fermeture des ressources sous la forme d'une clause try-with-resources. Actuellement lorsqu'on manipule une ressource, par exemple un InputStream, la façon la plus propre ressemble à ceci:

Ce code devient vite très verbeux et répetitif car beaucoup de vérifications doivent être faites pour s'assurer de la possibilité de fermer la ressource. La solution pour simplifier cela est de déléguer la fermeture du flux à l'aide du try:

Le code gagne énormément en visibilité, les tests pour savoir si la ressource est null ou si la fermeture s'est bien déroulée sont gérés en interne de la JVM. A noter que pour être fermées les ressources devront étendre une nouvelle interface AutoCloseable.

S'il existe un certain consensus autour de l'utilité de cette évolution, il demeure encore un petit débat sur la partie catch des exceptions. Sans rentrer dans les détails, les exceptions levées pendant la fermeture d'une ressource annihilent celles levées dans le bloc try, ce qui en général est préférable mais du coup peut aussi masquer des exceptions importantes pour l'analyse du problème.

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

Google et les brevets

Semaine chargée pour Google:

• InfoQ nous annonce que le MPEG LA a décidé de continuer à ne pas réclamer de royalties pour les videos encodées en H.264 et distribuées gratuitement aux utilisateurs. Seules les plateformes vendant des vidéos sont, elles, toujours soumises à taxation. C'est donc une réponse à Google qui avait il y a quelques temps annoncé WebM, un codec vidéo semblable au H.264 mais plus libre et débarrassé des problèmes de brevets et de royalties qui entravent ce dernier. Si InfoQ ne voit pas trop de problèmes à continuer d'utiliser H.264, ce n'est pas du tout l'avis de Mike Shaver ingénieur haut gradé chez Mozilla et qui rappelle que les logiciels permettant de produire ou de consommer ces vidéos devront eux toujours s'acquitter d'une licence. La bataille entre WebM et H.264 ne fait donc que commencer.
• Ensuite, c'est Paul Allen, le co-fondateur de Microsoft, qui attaque Google et nombre de ses petits camarades (AOL, Yahoo, Facebook) pour avoir enfreint 4 brevets détenus par sa compagnie "Interval Licensing". Le blog Digits du Wall Street Journal s'est penché sur 2 de ces brevets. Nous vous déconseillons fortement la lecture de son analyse si vous avez réalisé quoi que ce soit dans l'informatique ces 10 dernières années. En effet, vous risquez de ne plus trouver le sommeil en vous rendant compte que vous enfreignez sans doutes, vous aussi, nombre de brevets !
• Et pour finir sur Google et les brevets, vous vous souvenez des récentes poursuites engagées par Oracle concernant Java et Android. Google vient de riposter, en annoncant qu'aucun de ses employés ne participera à JavaOne cette année. Pour ceux qui voulaient échanger avec les employés de Google, il semble que c'est plus tard dans l'année, à Devoxx, qu'il faille se rendre. Mais rassurez vous, il y aura quand même de l'ambiance à JavaOne: James Gosling, père de Java, demande sur son blog à toute personne y assistant de porter un TShirt arborant le slogan "Java just Free it". Si cette idée ne risque pas trop de faire bouger Oracle, elle devrait quand même apporter sa dose de fun à l'évènement !

Actualité éditeurs / SSII

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

Le coin de la technique

• Hibernate ne supporte plus CGLIB

Actualité éditeurs / SSII

James Gosling sur l'affaire Oracle vs Google

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

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

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

ActiveMQ 5.4.0

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

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

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

Le coin de la technique

Hibernate ne supporte plus CGLIB

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

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

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

Actualité éditeurs / SSII

• Oracle poursuit Google pour violation de brevets

RIA

• Bean Validation pour Flex.
• Annonce de jQuery Mobile

SOA

• La NASA ouvre les sources de son cloud privé

Le coin de la technique

• Continuous Delivery, le livre le plus important de 2010 ?

Actualité éditeurs / SSII

Oracle poursuit Google pour violation de brevets

Jeudi dernier, Oracle a lancé une action en justice contre Google pour violation de brevets quant à l'utilisation de Java pour la plateforme Android. L'information a rapidement fait le tour du web et de la twitosphère provoquant à l'encontre d'Oracle son lot de commentaires indignés, notamment dans les communautés Java et libristes (On retiendra le billet peu amène de James Gosling : "The shit finally hits the fan....").

Dans sa plainte, Oracle précise que "Android [...] et les appareils qui utilisent Android violent un ou plusieurs brevets parmi les suivants: 6,125,447; 6,192,476; 5,966,702; 7,426,720; RE38,104; 6,910,205; et 6,061,520". Les brevets en question portent sur l'implémentation de machines virtuelles, l'outillage et les compilateurs.
Google, certainement pour garder les coudées franches, a fait le choix d'implémenter sa machine virtuelle Dalvik sans utiliser OpenJDK (la version GPL2 de Java). Cette implémentation n'est pas pleinement compatible Java et est exécutée sur des terminaux mobiles. Or, lorsque Sun avait "open sourcé une partie de Java" au travers d'OpenJDK, les garanties d'être à l'abri d'attaques pour violation de brevet ne protégeaient que les implémentations pleinement compatibles Java pour desktop et serveur uniquement (pas les implémentations pour terminaux mobiles).
Pour étayer son accusation selon laquelle Google a sciemment violé les brevets relatifs à Java, Oracle avance que Google était, de longue date, au courant des brevets détenus par Sun. Eric Schmidt (CEO de Google) et Urs Hölzle (Senior VP of operations chez Google) ont en effet joué un rôle significatif dans le développement de la technologie Java lorsqu'ils étaient chez Sun.
La réponse de Google à l'attaque d'Oracle (au travers d'un communiqué de presse) est sans surprise : Google estime que la plainte est sans fondement. D'autre part, Google considère qu'avec cette plainte, Oracle n'attaque pas seulement Google, mais aussi la communauté Open Source Java.

A priori, l'objectif d'Oracle n'est pas de "tuer" Android mais de profiter de son succès en imposant à Google de lui reverser une part des revenus de la plateforme. En effet, Java ME est une source non négligeable de revenus pour Sun (Oracle) puisque cette technologie équipe de très nombreux terminaux. Mais le succès fulgurant d'Android sur le marché des smartphones est sur le point de tarir cette source de revenus.
D'autre part, Oracle souhaite sans doute envoyer un message clair quant à sa conception de l'utilisation de la technologie Java là où le silence de Sun vis à vis d'Android pouvait être perçu comme un blanc seing.

Ce genre d'affaire est généralement synonyme de feuilleton judiciaire à rallonge (comme dans le cas emblématique de SCO vs. Linux). Il y a donc peu de chances que le cas Google / Oracle se règle rapidement. La complexité du dossier (notamment en ce qui concerne les tenants et aboutissants techniques) laisse présager de longs débats. Même si l'issu d'un procès reste incertaine Google était certainement préparé à une telle attaque (et est de taille à y faire face) et sa défense sera bien préparée.
Tant que l'affaire ne sera pas réglée, l'ensemble de l'écosystème Android (constructeurs, développeurs, utilisateurs, ...) va retenir son souffle, mais l'engouement pour la plateforme Android ne devrait pas trop en pâtir. D'une part, Google continuera de développer la technologie Android. D'autre part, gageons que Google prendra ses responsabilités sur le sujet de la propriété intellectuelle et jouera son rôle de pare feux vis à vis des constructeurs équipant leurs terminaux de l'OS Android.

La fin d'Android est très peu probable. Oracle n'y a aucun intérêt et ce pour plusieurs raisons. D'abord parce qu'Oracle a tout intérêt à ce que Java soit présent sur le marché des smartphones. Or cette présence passe par Android, pas par Java ME et Oracle n'a, aujourd'hui, ni la volonté, ni la capacité d'innover dans ce sens. Ensuite parce que l'essor des smartphones sous Android favorise le développement d'applications utilisant des backend (serveurs) mettant en œuvre des serveurs d'applications Java et des bases de données, augmentant ainsi la taille d'un marché sur lequel Oracle se taille la part du lion. Enfin parce qu'Android réunit une large communauté Java.
Il semble donc que cette affaire ne puisse avoir que deux issues :

• Google sera contraint à verser une partie des revenus d'Android à Oracle. Soit parce qu'Oracle aura gagné un procès, soit parce que Google aura préféré négocier un accord à l'amiable.
• Ce sera le status quo. Soit parce qu'Oracle aura perdu un procès, soit parce qu'Oracle retirera sa plainte suite aux négociations qui vont s'entamer (au cours desquels Google pourrait commencer à utiliser ses brevets comme arme de dissuasion).

Ce qui est sûr, c'est que l'image de Java ne sortira pas grandie de l'initiative d'Oracle (qui semble d'ores et déjà avoir perdu la bataille de l'image).

Pour ceux qui souhaitent approfondir le sujet, l'excellent billet de Charles Nutter "My Thoughts on Oracle v Google" fait longuement le tour de la question et propose des perspectives très intéressantes.

RIA

Bean Validation pour Flex.

Le framework GraniteDS continue à offrir des fonctionnalités riches pour Flex, en parallèle des offres de Adobe, BlazeDs (open source) et LifeCycle ES (commercial).
La version 2.2 (actuellement en bêta publique) ne faillit pas à la règle et amène une rafraichissante innovation : l'implémentation de la JSR 303 (BeanValidation) pour Flex. Toutes les contraintes standard de la JSR sont implémentées via des annotations AS3 et le générateur de code maison (GAS3) permet la conversions des annotations des beans Java.
La validation s'appuie sur une nouvelle fonctionnalité de réflexion.
Autre avancées, peut être moins spectaculaire, la prise en compte des types 'big numbers' de Java dans les sérialisations offertes par le framework.
GraniteDs, dont certains avait décrété la mort à la publication de BlazeDs, est toujours bien vivant et comble, en open source, certains manques laissés par Adobe.

Annonce de jQuery Mobile

C'est une nouvelle qui va à coup sûr faire du bruit dans un monde du développement mobile déjà bouillonnant, puisque vient d'être annoncée la sortie pour la fin d'année de la version mobile du framework jQuery. Et ce n'est pas par la petite porte que le célèbre framework web souhaite faire son entrée, puisque contrairement à ses concurrents déclarés, tels que jQTouch ou bien Sensha Touch, jQuery Mobile se veut être un framework JavaScript ciblant la quasi totalité des plateformes mobiles web actuelles (Blackberry, Windows Mobile, iOS pour l'iPhone et l'iPad, Android, Symbian, Bada, ...), et permettant de développer des interfaces riches capables de faire rougir bon nombre d'interfaces graphiques natives.

Avec l'avènement d'HTML5 (WebStorage, WebSockets, Vidéo, Géolocalisation, ...), du CSS3, et des navigateurs mobiles dernière génération proposant des moteurs JavaScripts performants, la guerre du web semble se trouver un nouveau terrain de bataille, et le web mobile aura sous peu toutes les armes nécessaires pour déstabiliser le business modèle à peine naissant des Markets, tel que l'iTunes App Store ou bien l'Android Market. Le marché des applications mobiles semble donc suivre la voie de son grand frère, celui des applications PC, et proposera à terme de nombreuses applications riches directement par le web.

L'annonce parue sur le site de jQuery Mobile indique que l'un des objectifs du framework est de pouvoir développer une application unique pour toutes les plateformes mobiles. Ce concept, ne semble pas nouveau puisque l'objectif de J2ME sorti il y a 10 ans déjà était bien de développer une solution unique, rappelez-vous: "Write Once, Run everywhere". Le slogan semble être ici: "Write Less, Do More", mais l'objectif de fond est bien le même.

Palm avec sa plateforme WebOS et Firefox sont déjà sponsors du projet. Bien qu'encore en développement intense, la première sortie est prévue pour fin 2010. Ce framework pourrait bien être une des grandes surprises mobile de 2010 et devenir très rapidement un incontournable pour le développement web d'applications riches pour mobile.

Pour en apprendre plus sur cette déclinaison de jQuery, vous pouvez suivre les liens suivants et apprécier les designs présentés :

• Site officiel de jQuery Mobile
• La device support grid de jQuery Mobile
• Les designs concepts

SOA

La NASA ouvre les sources de son cloud privé

La NASA a récemment annoncé son intention d'offrir le code de son cloud privé Nebula au projet OpenStack en partenariat avec Rackspace. Il s'agit d'une implémentation d'une IaaS orientée vers le calcul scientifique et le stockage de données. Par ailleurs OpenStack est un projet actuellement supporté par plus de 25 firmes, dont Dell et Intel. Il offre une pile logicielle ouverte permettant de créer et exploiter un cloud privé sur la base d'infrastructures matérielles standards. Il est disponible sous la licence Apache 2.0. D'après la présentation du projet, la création d'un nouveau Framework ouvert pour le cloud est motivée par deux raisons principales :

• Le paysage du cloud est actuellement composé d'offres propriétaires, incompatibles entre elles et manquant de transparence, freinant ainsi l'expansion de cette nouvelle industrie. La création d'un framework Open Source permettrait donc une adoption plus massive.
• La plupart des autres projets Open Source existant ne pouvaient satisfaire les énormes besoins de scalabilité exprimés par Rackspace. Seule Nebula, semblait correspondre au besoin.

Pour l'instant le projet est disponible en "Developer preview". Une première release sera disponible respectivement mi-septembre pour "OS Compute" et mi-octobre pour "OS Storage".

Le coin de la technique

Continuous Delivery, le livre le plus important de 2010 ?

Continuous Delivery, le livre de Jez Humble et David Farley, est disponible en version finale, en édition papier ou électronique (chez vos revendeurs habituels). Il traite d'un sujet qui tient à cœur de plus en plus d'acteurs de l'écosystème JEE : comment améliorer et dédramatiser les processus de build, de livraison et de déploiement d'un produit. Ce livre recueille déjà de nombreux lauriers. Dont ceux de Martin Fowler (directeur de la collection, donc forcément un peu partial), qui en fait le livre technique le plus important de 2010.

De ce que nous avons pu en lire (par exemple, en RoughCuts ici), ces louanges sont justifiées : ce livre traite de tous les problèmes qui devraient animer n'importe quel consultant au démarrage d'un projet. Collaborer entre équipes, développer de manière incrémentale, tester, automatiser, déployer, tout cela dans un seul but, maximiser la qualité du produit délivré.

Ce livre donnera lieu a un grand nombre de présentations en conférence, qui, si ce n'est déjà fait, devrait vous donner envie d'en faire votre livre de chevet avant la rentrée littéraire.

Pour en savoir plus, consultez le blog Continuous Delivery

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

Actualité éditeurs / SSII

• Naufrage pour Google Wave

Le coin de la technique

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

Actualité éditeurs / SSII

Naufrage pour Google Wave

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

Le coin de la technique

Nouvelle architecture de réplication et de sharding pour MongoDB

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

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

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

Axon, une implémentation Java du pattern CQRS

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

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

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

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

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

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

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

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

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

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

Actualité éditeurs / SSII

• Nokia donne son "Mobile Runtime" Java à la fondation Symbian

Agilité

• Cinq pièges à l'adoption des méthodes agiles

RIA

• FxObjects: un framework pour JavaFX

Le coin de la technique

• IntelliJ IDEA 9.0.3
• VisualVM 1.3

Actualité éditeurs / SSII

Nokia donne son "Mobile Runtime" Java à la fondation Symbian

Dans un effort de rendre plus accessible le développement d'applications Java pour les mobiles basés sur le système Symbian, Nokia vient d'annoncer, ce 15 juillet, faire don de son "Mobile Runtime for Java Applications" (JRT) à la fondation Symbian (créée en 2008 justement, suite au rachat de Symbian Software Limited). Avec le don de son JRT, Nokia met à disposition pas moins d'1 million de lignes de code Java et C++ correspondant à son runtime, son installeur d'applications, ses API, ses tests et sa documentation. Le tout est mis à disposition sous license Eclipse Public License (EPL) et est disponible comme partie intégrante du dernier Symbian^3 Product Development Kit.

Nokia annonce le support de la norme MIDP 2.1 (JSR 118), ainsi que ses nombreuses JSR, dont l'architecture MSA. Rien de bien nouveau, jusqu'à présent, serait-on tenté de dire. D'un point de vue graphique, la plateforme Symbian^3 apporte le support d'une accélération graphique hardware, ainsi que deux API non standard : la classique Nokia UI API en version 1.4, ainsi qu'une implémentation de l'Eclipse Standard Widget Toolkit (eSWT) UI API en version 1.0.3.

En complément du langage Java, Le SDK Symbian^3 propose d'écrire des applications natives en utilisant le langage C++ et le support intégré du tookit graphique Qt. Un support de développement basé sur les technologies Web est également disponible, il permet de construire des applications basées sur le Nokia's Web Runtime (WRT) et l'outil PhoneGap, qui permet de tirer parti de différentes fonctionnalités de l'OS habituellement uniquement accessibles par les applications natives.

Pour les curieux, une roadmap de développement permet de se faire une idée des fonctionnalités des futures version de la plateforme.

Quelle stratégie pour Nokia en 2010?

Dès 2008, Nokia avait préparé sa riposte face à la sortie de la plateforme mobile Android de Google. Déjà détenteur de 48% de la société Symbian Limited, Nokia avait racheté les parts restantes auprès de ses concurrents de l'époque (Sony-Ericsson, Panasonic, Siemens, ...) pour un montant avoisinant les 250 millions d'euros. Ce rachat qui n'était qu'une première étape devait permettre à Nokia de faire don de la plateforme Symbian à la fondation éponyme. A la même époque les autres acteurs de l'environnement Symbian devaient faire de même: Sony-Ericsson et Motorola devaient, entre autre, fournir la technologie UIQ à la fondation. Le but de la fondation Symbian était donc de créer, à partir de ces différentes contributions, une plateforme mobile unifiée ouverte à la communauté.

En l'espace de 2 ans, le paysage des plateformes mobiles a cependant bien changé: l'iOS d'Apple est devenu un leader emblématique, même s'il commence à se faire disputer le titre par la plateforme Android de Google, tandis que Microsoft tente revenir dans la course pour les fêtes avec son nouveau système Windows Phone 7. En parallèle, de nouveaux acteurs apparaissent tel que Samsung avec son système Bada, ou bien Baidu qui souhaite copier son grand frère Google avec un OS ayant pour ambition de conquérir le marché chinois ...

Près de 2 ans après la présentation de sa stratégie pour contrer Google, l'annonce de la sortie de Symbian^3 par Nokia ressemble beaucoup à une tentative désespérée de raccrocher le wagon. Il n'est plus l'heure pour Nokia de redorer son blason, mais plutôt de sauver les meubles dans un secteur où les évolutions se font à coup de bottes de sept lieues. Pour s'en convaincre, il suffit de comparer le paysage des plateformes mobiles aujourd'hui avec celui de 2008. Malgré un parc important d'appareils mobiles déployés et sa communauté de développeurs, Nokia est toujours à la recherche d'un business model efficace. Ses talents d'innovation et de fabricant de combinés haut de gammes semblent être un lointain souvenir tant la concurrence a pris de l'avance rapidement. La stratégie de Nokia est-elle la bonne ? Nokia est en tout cas, aujourd'hui, au pied du mur. Le géant scandinave annonce pour la fin d'année des appareils compatibles avec la toute dernière version de la plateforme Symbian, comme le Nokia N8. Dans un marché en mouvement permanent, cela sera-t-il suffisant ?

Agilité

Cinq pièges à l'adoption des méthodes agiles

Mike Griffiths, blogueur et agiliste travaillant au PMI, nous présente dans son article les Anti-Patterns nuisant à l'adoption des méthodes agiles. Bien que les bénéfices tirés des méthodes agiles ne soient plus à prouver, le passage à l'agilité n'est pas forcément couronné de succès. Nombreux sont les pièges et les digressions dans lesquels on peut tomber. Mike décrit ensuite cinq pièges courants, mais c'est à vous d'identifier les autres selon le contexte de votre projet.

• L'agilité n'est pas un miracle

Oui, l'agilité permet de gagner du temps, d'accroître la valeur métier, et de développer un produit de meilleure qualité. Cependant, ce n'est pas une recette magique, qui va permettre à un projet anémique voué à l'échec d'être un succès. Bien au contraire, vous pourriez arriver encore plus rapidement en situation d'échec, ou au mieux vous en rendre compte avant avec des nouveaux indicateurs.

• L'agilité ne veut pas dire aucune discipline

Certaines personnes ne connaissant pas bien l'agilité ont l'idée reçu que les méthodes agiles font preuves de très peu de discipline, de planification et d'estimation. Les méthodes agiles sont parfois appelées "méthodes légères" par opposition aux anciennes méthodes.
On peut quand même constater de nombreuses cérémonies et activités de haut niveau nécessitant de la discipline, comme: le stand-up daily meeting, le sprint planning, la rétrospective, la démo, etc.
Même si les documents afférents aux cérémonies sont peu nombreux, ils ne sont pas une excuse pour manquer de discipline et éviter de rendre des comptes. Ils contiennent les indicateurs suffisants pour réaliser des plannings, des estimations, etc.

• L'agilité sans aucune explication

Une équipe agile ne travaille pas toute seule en silo. Elle interagit avec d'autres équipes, comme le marketing, l'architecture applicative, etc. Le caractère itératif d'un projet agile peut les perturber. Ainsi, il convient d'expliquer le processus agile aux autres équipes, avant d'arriver à des situations de blocages ou pire de rejets.

• L'importance du feedback client

L'une des contraintes importantes des méthodes agiles est d'avoir le client sur site. Cela permet entre autre d'avoir un feedback régulier au cours d'une itération. La réunion de démonstration a aussi pour rôle d'avoir un retour et une validation du client. Attention, même si le client ne fait pas ou peu de retours, cela ne veut pas pour autant dire que tout va bien et que son réel besoin est satisfait. Au contraire, il peut avoir fait preuve d'inattention. Pour éviter cela, Mike propose des sessions de revue, où le client est assisté par un membre de l'équipe.

• Obsédé par le processus agile

La recherche de l'amélioration du processus agile au sein d'un projet est bonne chose en soi.
Cependant, il ne faut pas tomber dans le cas extrême du scrum master obnubilé par le process et le sur-outillage avec des indicateurs inutiles. Il faut rester pragmatique et garder à l'esprit que l'objectif de l'agilité est de satisfaire le client et répondre à des contraintes business. Il faut donc garder son attention sur lui et non sur le process. Mike suggère d'utiliser des métriques orientées sur l'objectif final: satisfaction client, fonctionnalités réalisées et acceptées, plutôt que le pourcentage de pratiques agiles suivies, ou le temps passé en pair-programming.

RIA

FxObjects: un framework pour JavaFX

TheServerSide nous apprend aujourd'hui que la version 1.0 du Framework FxObjects vient de sortir. C'est un framework réalisé par Srikanth Shenoy, destiné à aider la programmation d'applications JavaFX. Il s'avère être, malgré sa jeunesse, assez ambitieux. S'articulant autour du pattern Model-View-Presenter qui facilite les tests unitaires, les 3 briques principales sont les suivantes:

• le command framework
  • commandes asynchrones
  • HTTP & REST
  • marshalling/unmarshalling XML avec JAXB
• le Controller chain framework
  • contrôleurs
  • support de la navigation
  • présentations des nœuds
• l'Event Framework, encore à l'état expérimental

A noter que le Controller chain framework et l'Event Framework disposent d'un cycle de vie customisable, et que l'on peut utiliser Spring pour définir les divers éléments de son application (ouf !).
De nombreuses évolutions sont d'ores et déjà au menu de la V0.2 prévue pour septembre:

• gestion du cycle de vie de l'application
• gestionnaire d'évènements
• sécurité
• conversion vers et depuis JSON

Il est intéressant de voir un framework venir aider au développement JavaFX car il semble que les programmeurs étaient, jusqu'à maintenant, peu gâtés dans ce domaine. Reste à voir s'il saura gagner l'adhésion de la communauté et réussira à dépasser le stade de proof of concept. On serait en effet tenté de dresser un parallèle avec le Swing Application Framework qui fut pendant un temps considéré comme le futur de Swing, mais qui n'a jamais réussi à fédérer assez de monde derrière lui pour devenir un standard malgré la JSR le supportant. Mais alors que ce framework devait faire face à la rude concurrence de Netbeans RCP et Eclipse RCP, c'est plus au manque d'engouement pour JavaFX que risque d'avoir à faire face FxObjects. A moins que ce ne soit lui le sauveur de JavaFX ?

Le coin de la technique

IntelliJ IDEA 9.0.3

IntelliJ IDEA continue son petit bonhomme de chemin. Et 3 mois après la release 9.0.2 , voici venir la nouvelle version de l'IDE en 9.0.3. La release notes complète se trouve ici.

Amélioration du débogueur Flex, meilleur support de Grails, l'éditeur HTML qui supporte par défaut HTML5... en bref des nouveautés plutôt intéressantes. Mais pour ma part, la killer feature de cette version est sans nul doute le gestionnaire de mots de passe encryptés pour entre autres les VCS.

Ayant depuis quelques jours migré sous Git avec tous nos repositories dorénavant sous Github, je me suis retrouvé, à chaque push vers une branche remote, à devoir ressaisir ma passphrase. Et que ce soit pour 1 ou 10 pushs, cela devient très vite embêtant pour peu que cette passphrase soit quelque peu évoluée. Mais voilà, je ne serais resté que 2 semaines dans cet état car cette nouvelle version de l'IDE apporte ce fameux gestionnaire de mots de passe.

Au premier push, IDEA vous proposera de sauvegarder votre passphrase. Si vous répondez positivement, il vous est alors demandé de rentrer un mot de passe maître. Celui-ci sera votre mot de passe pour accéder au gestionnaire et vous sera demandé la première fois que vous voudrez faire un push. Mais dès lors, votre passphrase ne vous sera plus jamais demandée ! Ainsi, une fois celui-ci saisi, vous pourrez effectuer autant de push que vous le souhaitez sans saisie de passphrase ! A noter qu'après chaque redémarrage, votre mot de passe maître vous sera redemandé uniquement lors de votre premier push serveur. Une fonctionnalité très agréable donc.

Bien évidemment, les plugins SVN ou Git nous offrent des fonctionnalités simplifiées comme un affichage élaboré de l'historique des commits ou bien encore un diff entre 2 fichiers plus visuel. Néanmoins, n'oubliez pas que Git regorge de commandes toutes plus utiles les unes que les autres ! Et rester 100% de son temps dans un IDE, ce serait passer à côté de plusieurs perles de productivités. Bien sûr, les commandes standards comme le rebase, stash, pull, push, etc sont gérées, mais d'autres comme le bisect ou le cherry-pick ne le seront pas forcément. Une bonne intégration avec l'IDE, donc, mais sans écarter complètement le terminal ou Cygwin!

VisualVM 1.3

VisualVM vient de sortir en version 1.3. Pour rappel, cet outil graphique de diagnostic permet de faire du monitoring et du profiling de nos applications Java. Développé par Sun et téléchargeable gratuitement, cette boite à outils intègre de nombreux plugins et est autant destinée à un environnement de développement qu'à un environnement de production.
Cette nouvelle version corrige quelques bugs et apporte les évolutions majeures suivantes:

• Support des langages dérivés de la JVM: Clojure, Groovy, JRuby, Jython et Scala.
• Le plugin Sampler (qui monitore les activités du CPU et de la mémoire) est maintenant intégré par défaut.
• Les plugins Sampler et Profiler disposent d'une configuration par défaut. Exemple: Classes et packages à filtrer, intervalle de temps entre les mesures, etc.
• On peut monitorer à distance des applications qui ont activé JMX.
• Apparition du Tracer framework et d'une série de sondes: jvmstat, java I/O, Garbage collectors.
• Apparition d'un nouveau plugin Threads Inspector, permettant une vision plus fine d'un thread.