La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Actualité éditeurs / SSII

• JavaOne
• Google Dart
• Google Cloud SQL
• Apache TomEE

Agilité

• SCRUM se met au crowdsourcing

Actualité éditeurs / SSII

JavaOne

La conférence JavaOne 2011 s’est tenue la semaine passée à San Francisco. Comme chaque année, elle a été l’occasion d’un grand nombre d’annonces, de keynotes et de plans sur le futur de Java. On notera après avoir pris la température auprès de la communauté, que celle-ci semble moins inquiète que dans un récent passé: Oracle est là depuis un moment maintenant, les choses semblent s’être stabilisées et clarifiées. La récente arrivée de Java 7 ne doit pas y être pour rien. Parmi les diverses annonces, on retiendra surtout :

• Java 8 est retardé à début 2013. Nous aurons le temps de vous reparler des nouveaux apports.
• Java ME tend à se rapprocher de Java SE et vise à en devenir un sous ensemble. L’intérêt est d’unifier les communautés de ces 2 versions.
• Java EE 7 est en préparation, orienté Cloud et multi-tenancy
• JavaFX n’est pas mort. Les mauvaises langues diront que le projet ressort du placard chaque année pour JavaOne. Mais Oracle semble décidé à le faire avancer: il devrait progressivement devenir complètement OpenSource et une version 3 est prévue, intégrée directement dans le JDK 8.
• Pour rêver un peu, quelques pistes pour le JDK 9 ont été évoquées. On parle de VM s’adaptant toutes seules aux applications (plus de XmX et autres barbaries ?!), d’un nouveau Meta Object Protocol améliorant le support entre langages… Là encore, nous aurons laaaargement le temps d’en reparler !

On regrettera encore malgré tout l’absence de speakers de Google, à cause du procès opposant celui-ci à Oracle et alors que la compagnie n’est pas la moins active dans l’écosystème Java.
Le blog suivant recense nombre d’articles sur JavaOne et vous pourrez retrouver quelques roadmaps sur le podcast JavaSpotlight.

Parmi les autres annonces intéressantes, on notera l’annonce du serveur Apache TomEE qui est maintenant certifié EE 6 Web Profile. C’est un serveur Java EE qui se veut léger, basé sur un Tomcat tout ce qu’il y a de plus standard avec utilisation d’une librairie Apache pour chacune des fonctionnalités requises par la norme Web Profile: on retrouvera ainsi Apache OpenWebBeans, Apache MyFaces, Apache ActiveMQ, Apache OpenJPA et Apache CXF.
Et pour finir, Oracle a annoncé une nouvelle solution NoSQL. Le géant des bases relationnelles compte donc se diversifier en élargissant son offre. Retrouvez tous les détails de cette solution basée sur Java chez infoQ.

Google Dart

A l’occasion de la GotoCon, Lars Bak le créateur de la machine JavaScript V8 de Chrome et Gilad Bracha auteur du langage NewSpeak ont annoncé la naissance d’un nouveau langage de script pour les navigateurs nom de code Dart. L’annonce concerne le disponibilité de ce langage en Technology Preview, il n’est pour le moment pas supporté par Chrome.
Ce langage inspiré de la syntaxe JavaScript offre de plus le support de la concurrence de type acteurs. Notez de plus qu’il permet de créer des applications pour iPad.
Quelques caractéristiques du langage:

• Orienté objet avec classe, interface, et héritage
• Typage optionnel
• Mono-thread

Selon le paradigme acteur, les pocessus dart sont isolés et ne peuvent communiquer entre eux que par une API de messaging.
Dart supporte différents type d’éxecutions:

• JavaScript – Avec le compilateur DartC les .dart sont compilés JavaScript.
• DartVM – Une machine virtuelle permet d’éxecuter directement les scripts Dart.
• Un utilitaire permet de créer et packager une image binaire de la heap qui pourra être exécutée par la suite.

Côté outillage, Dart propose un éditeur basé sur Eclipse avec support de l’auto-complétion. Bref, avec Dart, Google semble vouloir proposer une alternative à JavaScript permettant enfin de structurer son code et probablement de réconcilier les Javaïstes avec la programmation côté navigateur. Une belle initiative à laquelle nous souhaitons un franc succès.
Pour plus d’information:

• L’annonce sur InfoQ
• Dartlang.org
• Google code de Dart

Google Cloud SQL

Google App Engine, la solution de cloud PaaS made in Google offre dorénavant la possibilité d’utiliser une base de données relationnelle de type MySql.
Ce service nommée Google Cloud SQL répond à de nombreuses demandes d’utilisateurs, qui souhaitaient une manière plus simple de persister ses données que la solution BigTable.

Comme on pouvait s’y attendre, ce service ne nécessite aucune maintenance, ni administration. Une interface d’administration est néanmoins fournie. Vous avez la possibilité d’importer ou d’exporter votre base de données MySQL. De plus, il offre un mécanisme de réplication géolocalisé des données sur des centres de données.

Pour le moment, ce nouveau service est gratuit et mis à disposition d’un nombre limité d’utilisateurs. Par ailleurs, les quotas fixés sont plutôt modestes: 5 requêtes par seconde et la taille d’une requête est limitée à 15MO. Si vous êtes intéressé, c’est ici pour s’inscrire.

Apache TomEE

Apache a profité de JavaOne pour annoncer la sortie de TomEE en version Bêta. La particularité de ce serveur web est d’être certifié JEE 6 Web Profile.
Il s’ajoute à la liste des serveurs open source déjà existant compatibles JEE 6 Web Profile: GlassFish, JBoss et Apache Geronimo.

Ce serveur est assemblé à partir d’un simple Apache Tomcat, auquel ont été ajoutées différentes implémentations Apache pour fournir tous les services EE.
Voici les implémentations des différentes briques de la stack JEE embarquées dans TomEE:

• CDI: Apache OpenWebBeans
• EJB: Apache OpenEJB
• Javamail: Apache Geronimo JavaMail
• JPA: Apache OpenJPA
• JSF: Apache MyFaces
• JTA: Apache Geronimo Transaction
• Connector: Apache Geronimo Connector
• JMS: Apache ActiveMQ
• Web Services: Apache CXF

La philosophie d’Apache TomEE est d’offrir une solution simple et légère pour faire du JEE. Ce serveur semble bien prédisposé pour les solutions de Cloud avec notamment sa faible taille mémoire (< 24 Mo).
Toutes les informations et le téléchargement se trouvent ici.

Agilité

SCRUM se met au crowdsourcing

La plus populaire des méthodes agiles marque un tournant significatif dans son histoire. Les co-créateurs ont décidé de laisser la possibilité à chacun de proposer des modifications ou des extensions au cadre de base. Cette annonce intervenue peu avant le week-end serait presque passé inaperçue. Il y a quand même eu quelques réactions spontanées, notamment David Anderson, le meneur du mouvement Kanban, qui se demandait sur Twitter qui serait le premier à proposer une extension Kanban pour Scrum.

De notre côté on se demande qui sera la première SSII française à proposer une extension de SCRUM pour remettre un rôle de chef de projet et de MOA dans tout ça ? Heureusement pour veiller aux dérives, il existe un comité de revue des propositions dont on connait au moins 2 personnes: James Coplien et David Starr. Ce comité est en charge de revoir les propositions et interagir avec leur auteur. L’histoire nous dira si ce comité, censé veiller au grain, adopte une ligne plutôt rigide ou permissive. Dans tous les cas le modèle pour proposer une modification ou une extension (c’est le même) demande de bien préciser le contexte dans lequel l’élément proposé est utile, à la façon d’une approche par pattern. Il faut également que la proposition soit appuyée par un sponsor et on nous promet une réaction sous 3 mois. Il est possible de voir en ligne la liste des extension proposées. Pour l’instant on en trouve une seule qui émane de David Starr, du comité de revue. Elle traite, d’après le titre, du découpage en tâche dans le sprint planning. Ah, mais ce n’est pas ce qui avait été supprimé de SCRUM en Juillet ça ? D’ailleurs les explications sur les modifications du Sprint Backlog provenaient également de David Starr. Donc si j’ai bien compris, il explique pourquoi ça disparait de SCRUM et ensuite il propose une extension pour le réintroduire si l’on veut. Bon, j’espère juste que SCRUM ne va pas finir comme le RUP avec un site web qu’on peut configurer à partir d’une bibliothèque d’extensions…

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.

Actualité éditeurs / SSII

• IE6 : End of life !
• cdnjs.com un content delivery network pour javascript

Agilité

• Traiter l’urgence dans une équipe agile

NoSQL

• Infinispan au Paris NoSQL User Group

Actualité éditeurs / SSII

IE6 : End of life !

IE6 Countdown est un site lancé par Microsoft pour mesurer la baisse de part de marché d’IE6 dans le monde (et accessoirement promouvoir IE7 et 8). Ce dernier affiche 3,9% pour la France, alors que la Chine plafonne à 34,5%. Le «_grand gagnant_» est la Norvège, qui affiche seulement 0,7% de part de marché. La firme de Richmond encourage vivement à migrer vers IE7/8, avec pour argument un tableau comparatif, où l’on peut observer que presque aucune feature des navigateurs modernes n’est supportée : gestion des fenêtres par onglets, barre de favoris, compatibilité avec les standards du Web. Les développeurs Web quant à eux, peuvent même rajouter une bannière sur leur site, qui invite les utilisateurs ayant une version d’Internet Explorer antérieure à la 7, à le mettre à jour :

Enfin, bien qu’un grand du Web tel que Google ait récemment cessé de supporter IE6 sur Google Docs et Google Sites (Gmail et Google Calendar suivront dans l’année), le navigateur est encore très largement répandu en entreprise, avec son OS Windows XP. De ce fait, nous ne serions que trop vous conseiller d’inviter vos clients respectifs à monter de version, notamment pour des raisons de sécurité et de compatibilité. Pour les autres, Microsoft assurera tout de même le support jusqu’en Avril 2014.

cdnjs.com un content delivery network pour javascript

cdnjs.com est, comme son nom l’indique, un Content Delivery Network pour javascript : un nouveau service en ligne utilisant l’infrastructure AWS d’Amazon pour mettre à disposition des bibliothèques javascript. Google et plus récemment Microsoft proposent déjà ce type de service, mais uniquement pour les bibliothèques javascript les plus populaires… d’après leur propre usage. L’idée de cdnjs.com est d’apprécier à travers les votes de la communauté les bibliothèques javascript les plus utilisées afin de les héberger. Les sites web utilisant ce service bénéficient alors d’un cache http commun.

Agilité

Traiter l’urgence dans une équipe agile

Serge Beaumont, notre confrère de Xebia Pays-Bas, vient de publier un intéressant article sur les différentes manières de traiter les situations d’urgence dans les équipes agiles. C’est un sujet toujours difficile, car, par définition, la charge de travail requise pour traiter ces situations est inconnue. Donc peu estimable et planifiable.
Il commence son article par regretter la bonne vieille époque des projets waterfall où il n’y avait jamais de maintenance à faire. Ahhh, le bonheur que ça devait être que de travailler sur des projets parfaits, sans bugs, sans… Ah, attendez: une lecture plus attentive précise que c’était en fait l’équipe de maintenance qui était chargée de corriger la pile de non-sens créée par d’autres. Les pauvres…
Sur un projet agile, les livraisons régulières responsabilisent les équipes elles-mêmes qui verront revenir plus rapidement leurs propres erreurs.
Plusieurs scénarios sont envisagés:

• un Product Owner jouant le rôle de « firewall » et élimine bon nombre de problèmes (qui bien souvent n’en sont pas !)
• ce même Product Owner peut mettre les urgences au planning du sprint suivant et n’accepter que les vraies urgences

Pour les vrais problèmes, ceux qu’on ne peut pas éviter de traiter immédiatement, il est envisageable de garder à chaque début de sprint un buffer leur étant destiné. Mais notre confrère nous met en garde sur le fait que ce serait sans doute une fausse bonne idée: dès que votre MOA aura connaissance de la présence de votre buffer, ils n’auront de cesse d’essayer de le remplir. D’où la règle numéro 1 du buffer: le buffer n’est pas pour les éléments du backlog. La règle numéro 2, pourtant extrême, permettra de relativiser l’importance des demandes: un remplissage du buffer entraîne un abandon du sprint en cours. Extrême ? Mais efficace ! Les gens réfléchirons par 2 fois à la priorité de leurs demandes. Le principal reste tout de même de fixer la cause racine et donc d’améliorer la qualité. Logique, non ?

Finalement, l’auteur donne un conseil pour les équipes qui doivent faire beaucoup de maintenance: Kanban bien que proche de Scrum propose un process plus adapté. Nous vous renvoyons à notre article sur « Kanban in action » à Devoxx.

NoSQL

Infinispan au Paris NoSQL User Group

Manik Surtani, est venu au Paris NoSQL User Group présenter Infinispan, la In Memory Data Grid de JBoss dont il est le lead technique. Nous retiendrons :

Objectif : concurrencer Coherence

L’objectif d’Infinispan est de proposer une alternative Open Source à Oracle Coherence, Gigaspace ou IBM eXtreme Scale.

Les topologies

Infinispan propose deux topologies de déploiement :

• Embedded Mode (aka peer-to-peer) : l’application est fusionnée avec la grille de données : les JVM qui portent la(les) application(s) participent à la grille et portent des données. C’est la mode d’intégration qui permet le plus grand nombre de fonctionnalités mais qui apporte aussi le plus grand couplage.

• Client-Server Mode :
• L’application se connecte à la grille de données avec un connecteur comme elle se connecte à des SGBD.
• Il existe quatre protocoles : REST/HTTP, MemCached, Hot Rod (protocole bi-directionnel interne d’Infinispan) et les Web Sockets. Hot Rod sera le protocole le plus riche qui facilitera la haute disponibilité grâce à l’autodécouverte de la topologie de la grille et permettra les continuous queries. Seul Hot Rod impose java côté client. Les WebSockets sont temporairement remises en cause par les failles de sécurité inhérentes à cette technologie. 

Les APIs

Infinispan propose aujourd’hui une API bas niveau de style key-value store et travaille sur une API de haut niveau de style JPA qui manque cruellement à certains concurrents . Ces APIs seraient utilisables en mode « Embedded » et en mode « Client-Server » avec le protocole Hot Rod.

Fort de l’expérience de JBoss sur les annotations JPA et Hibernate Search, on peut espérer une API élégante.

Le plus : Hibernate Search

Infinispan apporte une fonctionnalité originale qui le différencie de ses concurrents : l’intégration d’Hibernate Search qui permet de créer des index secondaires plus sophistiqués que ceux « à la SQL » qu’on voit dans les autres In Memory Data Grids. Il est tout de même probable que cette richesse d’indexation ne concerne que peu de cas d’utilisation.

La road map

Le projet est dynamique et prometteur et il reste encore beaucoup de travail comme :

• l’envoi de traitements dans la grille (map/reduce, entry-processors, etc) qui est encore en version beta,
• le choix de language de programmation pour réaliser des traitements dans la grille. La réflexion se place aujourd’hui autour d’un langage neutre comme javascript ou de java,
• des optimisations de la gestion de la mémoire pour gérer des JVM de grande taille (> 10 Go),
• l’intégration de JBoss Marshalling avec l’ajout d’une API de versioning pour sérialiser les données dans la grille,
• l’ajout d’une query language pour requêter les données.

Scénarios d’utilisation d’Infinispan aujourd’hui

Le principal scénario d’utilisation d’Infinispan aujourd’hui est un « distributed key-value store » qu’on peut même installer sous forme « Data as a Service » pour reprendre l’expression de Manik Surtani.

Les utilisations en In Memory Data Grid haute performance avec des traitements au coeur des données sont a réserver à un public averti .

Après la traditionnelle introduction où chacun partage les actualités du mois précédent, place aux présentations, en parallèle :

• Michael Figuière a présenté Apache Mahout, le framework de Machine Learning de l’ecosystème Hadoop ;
• Nicolas Jozwiak et Frédéric Dubois se sont quant à eux attaqués aux concepts SOLID.

Ont suivi deux nouvelles sessions parallèles :

• Erwan Alliaume, Julien Buret, Séven Le Mesle et Pablo Lopez ont animé un débat sur les problématiques de Load Balancing dans les architectures soumises à forte charge ;
• Nathaniel Richand a organisé un open space, où il a notamment été question de traitement des exceptions Java puis de gestion des émotions.

Après la pause déjeuner, les sessions sont redevenues plénières :

• Katia Aresti est revenue en détail sur son expérience MongoDb et nous a fait l’honneur de l’avant première de la présentation qu’elle donnera à Mongo Paris ;
• Romain Maton nous a proposé un aperçu des APIs Google Guava ;
• Nathaniel Richand nous a démontré à quel point la communication est un facteur déterminant dans la réussite d’une mission ;
• Et, une fois n’est pas coutume, ce sont des intervenants extérieurs qui ont clos la journée. Mais contrairement à l’habitude, ce n’est pas un éditeur qui est venu nous présenter sa solution, mais deux de nos clients, Vincent Jaouen et Jean-Yves Cronier, qui nous ont exposé comment une refonte complète de leur couche HTML a permis de diviser les temps d’accès à un site internet grand public par cinq. Un grand merci à eux pour avoir apporté leur pierre à cet échange de connaissances.

Malgré l’heure avancée (la journée a une fois de plus été dense), bon nombre de courageux ont poursuivi les discussions autour d’un verre (Ajax, Json, méthodes d’audit, Grid computing mais aussi vacances au soleil et cinéma ).

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

Actualité éditeurs / SSII

• Google accélère le web avec le mod_pagespeed
• Oracle proposera une JVM Premium

SOA

• Le CEP, un domaine en expansion

Actualité éditeurs / SSII

Google accélère le web avec le mod_pagespeed

Google a annoncé la première version de ce nouveau module Apache. Il s’agit d’accélérer le chargement des pages HTML sans avoir à modifier son application. Le module applique un certain nombre d’optimisations, relevées par InfoQ:

• Changement des directives de cache par extension de fichier notamment.
• Optimisation du HTML, des CSS et du JavaScript à la volée (suppression des commentaires, passage en ligne, suppression d’espaces).
• Concaténation des fichiers CSS pour limiter le nombre de requête HTTP nécessaire à la page.
• Suppression des caractères et des attributs HTML inutiles.
• Optimisation des fichiers images par compression et effet d’échelle.
• Intégration en ligne des images en base 64.

Toutes ces optimisations sont bien sûr configurables et c’est à nous de choisir de les appliquer ou non via les différents filtres du module. Nous voyons ce nouveau module avec un oeil bienveillant, l’idée est séduisante et les bénéfices pourraient s’avérer convaincants. Reste encore à savoir comment se comporte le module en production, et quel est son impact sur les ressources du système ?

Il faudra donc le tester en conditions réelles pour pouvoir se prononcer sur ce nouveau venu. Voici le site officiel et la documentation. A noter également sur le blog de dynaTrace, un article intéressant sur des bonnes pratiques pour rendre son site plus performant.

Oracle proposera une JVM Premium

La semaine dernière au QCon, le monde Java a lancé la machine à rumeur. La faute à Adam Messinger, vice président du développement pour l’entité Fusion Middleware d’Oracle, qui a annoncé qu’il y aurait une version Premium (comprendre payante) de la JDK en plus de la version gratuite.

En réalité les plus avertis avaient déjà noté cette information au dernier JavaOne:

Premium offerings such as JRockit Mission Control, JRockit Real Time, Java for Business and Enterprise Support will continue to be made available for an additional charge.

En clair, Oracle a l’intention de vendre une version payante de la JDK qui comprendra, entre autres, les outils JRockit Mission Control (outil de monitoring), Real Time (outil de temps réel) et un support donnant accès par exemple à des corrections sans attendre les versions officielles. L’offre reste encore à définir, entre autre le prix, et des inconnus demeurent sur les différences entre les JDKs.

Par ailleurs Adam Messinger se veut plutôt rassurant sur le maintien d’une version gratuite. L’objectif d’Oracle reste de fusionner Hotspot et JRockit vers OpenJDK.

Néanmoins Stephen Colebourne (membre la fondation Apache et Java Champion) souligne les risques entourant cette annonce:

• Est-ce que la version gratuite et la version premium sortiront en même temps ?
• Est-ce que la version gratuite sera supporté sur la même quantité d’OS ?
• Quels sont précisément les fonctionnalités de la version premium ?
• Est-ce qu’il s’agira seulement de fonctionnalités pour le management ?
• Ou s’agira aussi de fonctionnalités sur les performances ?
• Quel est le marché ciblé ?

Il remarque également que ces craintes seraient levées si la JSR 924, qui spécifie la JVM, pouvait être implémentée librement, en s’abstrayant entre autre des champs d’utilisation (une vieille querelle entre Apache et Sun). Ceci permettrait d’avoir un standard et aux implémentations telle qu’Harmony d’être certifiées.

Depuis la prise en main de Java par Oracle, la communauté, qui est historiquement tournée vers l’Open Source, a quelques sueurs froides et l’annonce récente de monter les prix du support de MySQL n’arrangera rien.

SOA

Le CEP, un domaine en expansion

Le domaine du CEP, pour Complex Event Processing ou Traitement d’évènements complexes, est un domaine dont on entend peu parler mais dont l’utilité, une fois que l’on se penche dessus, semble évidente. Rappelons que le CEP est un concept dans lequel des suites d’évènements sont analysées, de façon automatisée, pour en dégager des informations qui ne seraient pas déductibles à partir de chaque événement pris séparément. La corrélation d’une suite d’évènements « simples » permet donc de déduire d’autres informations, plus complexes. Pour être concret, le CEP peut servir à détecter des fraudes bancaires par des suites d’évènements louches survenant sur un compte, ou alors pour détecter des problèmes dans un système suite à la réception, à une fréquence plus élevée que la moyenne, d’un certain type d’évènement.

Toujours est-il que de nombreuses solutions existent, Open Source ou non, pour satisfaire les divers besoins d’analyse. Dans un récent article, Marc Palmer de Streambase qui édite ses propres solutions CEP, revient sur la publication de chiffres semblant indiquer que les CEP ne représentent qu’un petit marché. Et pour contrer ces chiffres, il cite nombre de sociétés utilisatrices de la solution de Streambase. Même si c’est surtout un coup de pub pour sa compagnie, nous pouvons malgré tout réaliser à quel point les CEP sont importants dans le domaine du Capital Market.

Pour aller plus loin et découvrir différentes solutions, citons cet article de Debu Panda (de EJB3 in Action) vu sur ServerSide et dans lequel il évoque la solution de Starview. Mais si vous voulez vraiment être pris par la main pour avoir une première approche du CEP, Michal Bali, auteur de Drools JBoss Rules 5.0, nous livre un tutorial complet implémentant la détection de fraude dans un système bancaire en utilisant Drools Fusion, solution de JBoss. Ce dernier article est très complet et permettra au lecteur d’avoir une bonne première approche des possibilités de l’outil.

Cet article a pour but de vous présenter quelques-unes des solutions les plus répandues pour répondre à ce besoin. Pour cela, nous allons créer un camembert de 3 manières différentes :

• Google Chart API
• Achartengine
• ChartDroid

Cet article est une adaptation libre du billet de l’un des mes collègues indiens Yogesh Kapoor, l’original est disponible en anglais sur le blog de Xebee.

Google Charting API

L’utilisation de Google Charting est très simple. Cette API permet de créer des graphiques par l’intermédiaire d’une URL. Vous n’avez qu’à passer les bon arguments à celle-ci pour récupérer votre graphique. Comme ce service est basé sur une URL, vous devez disposer d’une connexion internet pour que celle-ci fonctionne. Si votre application s’exécute hors ligne, passez votre chemin.

L’appel à l’API Google Charting s’effectue par l’intermédiaire d’URL ressemblant à celle-ci :

http://chart.apis.google.com/chart?cht=p3&chs=250x100&chd=t:30,60,10&chl=cars|bikes|trucks

Dans cet exemple, voici comment lire les paramètres :

• cht=t3, type du graphique, t3 = camembert 3D,
• chs=250×100, la résolution,
• chd=t:30,60,10, les données,
• chl=cars|bikes|trucks, les libellés.

Le google code du projet est plutôt bien fait, il vous permet de créer différents types de graphiques en vous inspirant d’une multitude d’exemples.

Vous pouvez intégrer un graphique de ce type dans une application Android par l’intermédiaire d’une simple WebView. Difficile de faire plus simple.

@Override
public void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  WebView webView = new WebView(this);
  webView.loadUrl("http://chart.apis.google.com/chart?cht=p3&chs=250x100&chd=t:30,60,10&chl=cars|bikes|trucks");
  setContentView(webView);
}

La méthode onCreate() est appelée à la création d’une activité. Dans l’exemple ci-dessus, nous avons créé une WebView, chargé l’url de notre graphique dans celle-ci et affecté notre vue comme composant principal de l’activité.

Pour que cela fonctionne, comme vous avez besoin d’un accès internet, vous devez ajouter la permission suivante dans votre AndroidManifest.xml.

<uses-permission android:name="android.permission.INTERNET" />

Et c’est tout ce que vous avez à faire ! Notez au passage que vous n’êtes pas obligé de passer par une WebView, vous pouvez également télécharger cette image et l’afficher comme n’importe quel autre drawable dans n’importe quel composant (imageView, boutons, backgounds …)

Voici un capture d’écran du résultat obtenu, le graphique est plutôt joli. Il vous est possible de modifier les couleurs, ajouter une légende, changer le type de graphique en ajoutant des paramètres supplémentaires.

Si votre application n’a pas besoin d’accéder à internet, ce type de graphique n’est pas adapté. Continuons notre tour d’horizon avec une autre solution … hors ligne.

achartengine

achartengine est un projet permettant de générer différents types de graphique pour Android. Cette API utilise le mécanisme d’Intent, des messages configurables qui permettent de lancer l’exécution d’une activité tierce. Elle ne nécessite aucune connexion internet..

Qui dit Intent dit nouvelle activité. Les graphiques sont affichés sur des activités dédiées. Contrairement à Google Chart API, vous ne pourrez donc pas intégrer vos graphiques directement dans vos activités.

Pour l’utiliser, télécharger la dernière version du jar du projet sur le Google Code du projet, puis ajoutez le à votre projet Android.

Voici l’exemple d’une classe contenant une méthode qui créer un Intent configuré pour afficher un camembert :

public class MyChartExample {
  public Intent createIntent(Context context) {
    int[] colors = new int[] { Color.RED, Color.YELLOW, Color.BLUE };
    DefaultRenderer renderer = buildCategoryRenderer(colors);
    CategorySeries categorySeries = new CategorySeries("Vehicles Chart");
    categorySeries.add("cars ", 30);
    categorySeries.add("trucks", 20);
    categorySeries.add("bikes ", 60);
    return ChartFactory.getPieChartIntent(context, categorySeries, renderer);
  }
  private DefaultRenderer buildCategoryRenderer(int[] colors) {
    DefaultRenderer renderer = new DefaultRenderer();
    for (int color : colors) {
      SimpleSeriesRenderer r = new SimpleSeriesRenderer();
      r.setColor(color);
      renderer.addSeriesRenderer(r);
    }
    return renderer;
  }
}

La récupération de l’Intent bien configuré s’effectue par l’intermédiaire de la méthode createIntent. À l’intérieur de celle-ci, un SimpleSeriesRenderer est créé pour chaque part du camembert. Ces renderers sont ensuite ajoutés à un DefaultRenderer global au graphique.

À ce stade, la structure du graphique est configurée, il nous reste plus qu’à déclarer les valeurs des différentes parts de notre camembert. Pour cela, nous créons un CategorySeries avec les mêmes libellés et valeurs que nous avons utilisé dans l’exemple précédent.

Pour finir, nous fabriquons à partir de tout cela (renderers + series) un Intent correctement configuré en utilisant la factory prévue à cet effet.

Notre Intent créé, il ne nous reste plus qu’à l’utiliser pour lancer une nouvelle activité contenant le graphique. Il s’agit du mécanisme habituel pour lancer une nouvelle activité.

  Intent achartIntent = MyChartExample.createIntent(this);
  startActivity(achartIntent);

Après avoir exécuté ce code, voici ce qui devrait s’afficher.

Chartdroid

La dernière solution présentée dans cet article est plus contraignante d’utilisation. Elle utilise le même mécanisme d’Intent que la solution précédente, mais ici les activités ne sont pas directement intégrées à votre projet. Pour que les Intents fonctionnent, vous devez installer une application tierce : ChartDroid. Notez qu’il vous est cependant possible de faciliter cette installation en proposant programmatiquement un lien sur le market pour la récupérer (ce mécanisme n’est pas présenté dans cet article, il fonctionne, une fois encore, via un Intent).

Pour utiliser cette solution, vous devez créer un ContentProvider. C’est un mot qui peut faire peur au premier abord, mais il s’agit d’un des mécanismes proposé par Android pour communiquer entre application. Un ContentProvider est utilisable après la création d’un Intent, il permet de récupérer des données à partir d’un type et d’un URL.

public class ChartDroidDataProvider extends ContentProvider {
  static final String AUTHORITY =  "com.xyz.contentprovider.chardroid";
  @Override
  public String getType(Uri uri) {
    return "vnd.android.cursor.dir/vnd.com.googlecode.chartdroid.graphable";
  }
  public static final Uri PROVIDER_URI = new Uri.Builder().scheme(ContentResolver.SCHEME_CONTENT).authority(AUTHORITY).build();
  @Override
  public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder)
    // Fetch the actual data
    MatrixCursor c = new MatrixCursor(new String[] {
      BaseColumns._ID,
      "COLUMN_AXIS_INDEX", "COLUMN_SERIES_INDEX",
      "COLUMN_DATUM_VALUE", "COLUMN_DATUM_LABEL"
    });
    c.newRow().add(1).add(0).add(1).add(30).add(null);
    c.newRow().add(2).add(0).add(1).add(10).add(null);
    c.newRow().add(3).add(0).add(1).add(60).add(null);
    return c;
  }
  ...
}

Notez que nous avons supprimé du code précédent les méthodes qui sont générées par défaut par nos IDEs et que nous n’avons pas eu besoin de modifier.

La méthode query est en fait chargée de fournir les données nécessaires à la construction du graphique. Ce listing est l’un des exemples les plus minimalistes nécessaire à l’API pour générer un camembert. Nous utilisons un MatrixCursor afin de passer les valeurs de notre graphique. Au premier abord, la manière de récupérer les données ne semblent pas très claire, la syntaxe n’est pas des plus conviviale. Au final, on dit souvent que la première impression est souvent la bonne

N’hésitez pas à consulter le site officiel pour plus d’informations sur ce projet.

Maintenant que notre content provider est crée, il ne nous reste plus qu’à démarrer l’activité ChartDroid pour afficher notre graphique. Cela s’effectue par un Intent :

Intent chartDroidIntent = new Intent(Intent.ACTION_VIEW, ChartDroidDataProvider.PROVIDER_URI);
chartDroidIntent.putExtra(Intent.EXTRA_TITLE, "Chart droid");
chartDroidIntent.addCategory("com.googlecode.chartdroid.intent.category.PIE_CHART");
startActivity(chartDroidIntent);

Dans le morceau de code précédent, la ligne category est importante car elle définie le type de graphique à afficher.

Après exécution, vous devriez avoir un résultat qui ressemble à cela :

Conclusion

Pour conclure, la solution Google Chart API est la plus aboutie, je vous la recommande vivement. Les graphiques sont obtenus très facilement et sont plutôt jolis. Si vous n’êtes pas prêt à dépendre d’une connexion internet, je vous recommanderais la deuxième solution : achartengine. Bien que cela ne se voit pas sur les captures d’écran ci-dessous, les graphiques obtenus par achartengine sont généralement un peu moins jolis que ceux obtenus par chartdroid. C’est la contrainte d’avoir à installer une application tierce qui cause du tord à la troisième solution.

Pour finir, notez que toutes les solutions n’ont pas été présentées dans cet article. Je pense en particulier aux nombreuses petites surcouches jfreechart qui émergent (et meurent) ici et là. Je ne les ai pas présentées car la majorité d’entre elles ne sont que très peu actives.

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:

public void copyFile(File in, File out) {
    FileInputStream fis = null;
    FileOutputStream fos = null;
    try {
       fis = new FileInputStream(in);
       fos= new FileOutputStream(out);
       // Lire le fichier in et écrire dans le out
       ...
    }  catch (Exception e)  {
       ...
    } finally {
      close(fis);
      close(fos);
    }
}
private void close(Closeable closeable){
    if(closeable != null) {
        try{
           closeable.close();
        } catch(IOException e){...}
    }
}

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:

public void copyFile(File file) {
    try(FileInputStream fis=new FileInputStream(in);
        FileOutputStream fos=new FileOutputStream(out)) {
       // Lire le fichier in et écrire dans le out
       ...
    }
}

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 !

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.

Google I/O

• Partenariat entre Google et VMWare
• App Engine For Business
• WebM: enfin un standard vidéo libre ?

SOA

• Les créateurs de jBPM chez Alfresco

Le coin de la technique

• MyBatis : un fork de iBatis chez Google Code
• JRuby 1.5.0

Google I/O

Dans le foisonnement d’annonces lors du Google I/O 2010 qui s’est tenu la semaine dernière à San Francisco, nous en avons retenu quelques unes très intéressantes.

Partenariat entre Google et VMWare

VMWare et SpringSource sont décidément très actifs actuellement dans le domaine des partenariats et des acquisitions (RabbitMQ, GemStone ou VMForce). Google I/O a été l’occasion pour eux d’annoncer un nouveau partenariat autour du cloud computing, voire au delà: ils poussent plus loin leur concept d’Open PaaS déjà évoqué pour le partenariat avec SalesForce.

L’idée sous-jacente est de faire de VMWare la plateforme de développement privilégiée pour toute solution de PaaS (Plateform as a Service). En citant Steve Herrod, CTO chez VMWare:

Developers must be able to write applications without needing to know what underlying technology powers the cloud that they’ll be deployed on.

Et donc on pourrait développer une application App Engine et la tester sur les environnements de Google puis les déployer en production sur des instances VMWare. Au-delà de la problématique de l’hébergement, Steve Herrod ajoute également la possibilité d’accéder aux services Google (géolocalisation, traduction automatique…) et de diversifier les supports, en particulier sur les smartphones. Ce sont deux notions qu’on retrouve également dans le partenariat avec SalesForce.

Tout cela constitue pour l’instant des vœux pieux. Rod Johnson nous donne un aperçu plus précis de ce que sera ce partenariat:

• Intégration de GWT à l’outil Spring ROO, l’outil de SpringSource Tool qui permet de générer des projets Java en ligne de commande.
• Intégration de Google Speed Tracer à Spring Insight. Speed Tracer est un très bon outil de mesure de performance côté client, disponible aussi comme extension de chrome, alors que Spring Insight est un outil de mesure de performance plutôt côté serveur et directement accessible dans SpringSource Tool Suite. L’association des deux semble assez naturelle.

Il est encore difficile de voir la pertinence de ce nouveau paradigme, l’Open PaaS, et si l’hétérogénéité des solutions ne va pas le rendre un peu creux. Mais au-delà de ça, la stratégie actuelle de VMWare semble être la captation des développeurs Java vers leurs outils et en particulier SpringSource Tool Suite.

App Engine For Business

Au-delà du partenariat avec VMWare et alors qu’aujourd’hui App Engine a encore une étiquette (un peu) de bricolage, Google a la volonté de percer dans les entreprises et d’ajouter tout un arsenal prompt à rassurer celles qui voudraient se lancer. D’où la nouvelle offre Google App Engine For Business qui s’articule autour de ces points:

• Administration centralisée : cette console permettrait de gérer, entre autres, plusieurs projets d’une même entreprise.
• Fiabilité et support : une garantie de SLA de 99.9% et support pour les utilisateurs.
• Sécurisation par défaut : l’application serait par défaut sécurisé par les comptes Google App de l’entreprise.
• Coût raisonnable : la plateforme serait disponible pour 8$ par utilisateur et par mois, plafonné à 1000$.
• une architecture plus orientée entreprise : utilisation du SSL à l’intérieur du domaine de l’entreprise, utilisation des services avancés de Google et surtout enfin accès à des bases SQL (c’était un des gros points noirs d’App Engine). Ces nouveautés seraient disponibles dans le courant de l’année.

Plus de détails ici.

WebM: enfin un standard vidéo libre ?

Le Google I/O a aussi été l’occasion pour le géant de faire une annonce que de nombreux partisans d’un internet ouvert espéraient depuis le rachat de la société On2. Jusqu’à présent, les formats vidéo « du futur » étaient d’un coté H264, et de l’autre Theora. H264, meilleur techniquement que Théora avait le gros désavantage de traîner derrière lui nombre de brevets. Le consortium gérant ce format avait déclaré ne pas désirer recevoir de royalties avant quelques années. Mais le format n’en restait pas moins propriétaire et l’épée de Damoclès des royalties était susceptible de s’abattre plus tard sur ses utilisateurs. Cette guerre commençait à devenir visible au niveau des navigateurs et de leur support de la balise video du HTML5. Pour rappel, la spécification de celle-ci n’impose aucun codec. Nous arrivions donc à une situation difficile où certains navigateurs ne supportaient que Theora (Firefox) et d’autres que le H264 (Safari). L’incertitude était de mise quant à préserver un web standardisé mais ouvert. C’est là que Google intervient en proposant un nouveau projet, WebM, et endosse son costume de sauveur du web.
Ce projet est destiné à développer un format vidéo libre. Techniquement, des fichiers WebM contiendront:

• de la vidéo au format VP8
• du son en Vorbis
• le tout dans un conteneur Matroska.

Certaines voix se sont d’ores et déjà élevées pour dénoncer le format VP8 pour diverses raisons, mais il y a fort à parier que ce codec soit celui que tout le web attendait, notamment pour utiliser la norme HTML5 sans soucis de compatibilité. Les versions de développement de Firefox et Chrome intègrent déjà le support de ce format, les mobiles Android devraient le faire avant la fin de l’année et Adobe, avec Flash, suivra aussi.

A coté de l’aspect technique, il nous semble intéressant de nous attarder sur la licence de WebM qui est assez singulière et participera à n’en pas douter à imposer WebM. L’un des problème de ce projet est que, malgré toutes les dispositions prises, il n’est pas certain qu’un bout de code quelque-part n’enfreigne pas un quelconque brevet… Or, la licence stipule, en gros, que quiconque intentera un procès au projet ou à ses utilisateurs devra cesser d’utiliser le projet lui-même. C’est un coup de génie: si WebM commence à s’imposer (ce dont nous ne doutons pas avec la puissance de feu de Google, Youtube…), alors les entreprises susceptibles de lui intenter un procès ne le pourront pas, car elles seront en même temps obligées de l’utiliser elle-mêmes pour ne pas pénaliser leurs propres utilisateurs. Impossible d’imaginer les utilisateurs d’Opera interdits de Youtube pour cause de format vidéo non supporté par exemple: ils auraient tôt fait de migrer vers un autre navigateur. Google tient donc peut être, avec WebM, le nouveau standard vidéo du Web. En tout cas, il entend bien l’imposer comme tel.

SOA

Les créateurs de jBPM chez Alfresco

Alfresco a annoncé son nouveau BPMS, Activiti, mené par le créateur de jBPM, Tom Baeyens, et de son ancien lead developer Joram Barrez, tous deux partis de chez JBoss il y a peu.

A l’instar de jBPM, Activiti est un BPMS léger, qui s’intègre facilement à nos applications Java. Il propose en plus, une console d’administration et un modeler graphique en ligne.

Par ailleurs, il s’appuie sur le standard BPMN 2.0, et bénéficie ainsi à la fois d’une sémantique d’exécution, ainsi que d’un modèle de représentation graphique. Cette décision marque bien le contraste avec le choix précédent des créateurs, lors du développement de jBPM, de s’appuyer sur un format propriétaire, jPDL.

L’éditeur de la célèbre solution ECM a toutefois annoncé qu’il continuerait le support de jBPM au sein de sa suite logicielle. Bonne nouvelle, pour les nombreux projets qui ont déjà investi dans la solution de jBoss.

On notera enfin que SpringSource annonce la collaboration de Dave Syer, project lead de Spring Batch, avec l’équipe d’Activiti. On devrait donc s’attendre à un prochain support de BPMN dans les applications Spring.

Le coin de la technique

MyBatis : un fork de iBatis chez Google Code

Alors que la version 3.0 d’iBatis a été finalisée il y a un mois après une longue période de gestation, une annonce majeure pour l’avenir du projet vient d’être diffusée sur son site. Le créateur d’iBatis, Clinton Begin, ainsi que plusieurs des principaux commiters ont décidé de créer un fork du projet en dehors de la fondation Apache.

Ce nouveau projet est baptisé MyBatis et est hébergé sur Google Code. Le projet iBatis d’origine est conservé au sein de la fondation, mais stoppé. Il devient donc un sous-projet d’Apache Attic qui regroupe les projets Apache dépréciés.

Clinton Begin clarifie les principales questions que l’on peut se poser suite à cette annonce :

• Les noms des packages ne changent pas, et la compatibilité ascendante est préservée avec le passage à MyBatis.
• Les branches 2.x et 3.x sont préservées dans MyBatis avec la disponibilité immédiate des versions 2.3.5 et 3.0.1.
• La licence est conservée.

Cette annonce est pour le moins inattendue mais dans la mesure où il s’agit d’un transfert de responsabilité plus que d’un fork, les ressources du projet ne seront pas divisées et son activité devrait donc être préservée.

JRuby 1.5.0

Avec un peu de retard, nous tenons quand même à signaler la sortie de JRuby en version 1.5.0. Cette version a été celle de la maturation du moteur. En terme de compatibilité avec le langage Ruby, très peu d’ajouts ont été faits. En revanche, beaucoup d’ajouts de stabilité, améliorations de l’utilisation mémoire, du support de Windows, support de Ruby On Rails version 3. Pour le détail : l’Annonce officielle.

L’astuce de la semaine

Nous inaugurons aujourd’hui une nouvelle rubrique qui est destinée à vous faire part brièvement de petites astuces qui, nous l’espérons, pourront vous être utiles. Et c’est le tout récent Eclipse MarketPlace qui honore cette nouvelle rubrique de sa présence. Pour rappel, le MarketPlace est le successeur de Eclipse Plugin Central (maintenant en fin de vie) et destiné à lui ajouter de nombreuses fonctionnalités.
Dans son post, Zviki Cohen nous apprend comment utiliser le MarketPlace pour créer des liste de plugins et les installer facilement. C’est une astuce qui peut être particulièrement intéressante lorsque l’on cherche à uniformiser les postes de développement par exemple: il suffit d’une URL pour ajouter à une installation d’Eclipse tous les plugins utilisés. C’est une alternative pratique à l’installation manuelle par chaque développeur qu’on retrouve souvent sur les projets.

Sommaire

• HTML5 ?
• Nouveau modèle de contenu
• Nouveaux éléments de mise en page
• Eléments interactifs
• Les WebForms
  • Nouveaux input
  • Validation native
  • Auto-complétion
  • Répétitions
  • Etat des lieux
• Multimedia
  • Audio et Video
  • La guerre des Codecs
  • Le Canvas
• Conclusion

HTML5 ?

HTML5 est au départ la nouvelle version du langage HTML en cours de développement par le W3C. Pour le moment, il s’agit d’une recommandation en DRAFT, fruit du travail initial réalisé par le WHATWG depuis 2004. Le W3C espère en faire un de ses standards libres aux alentours de 2022. De prime abord, ça nous laisse le temps de réfléchir au problème pendant les 10 prochaines années. L’idée d’une nouvelle version de HTML serait motivée par quelques constats simples :

• Les navigateurs ont besoin de plugins pour gérer le multimédia (flash et consorts)
• La structure des documents n’est pas intuitive et rend l’accessibilité difficile
• Les API JavaScript varient trop d’un navigateur à l’autre pour garantir la portabilité des documents
• Les sites sont de plus en plus proches des applications de bureaux mais souffrent encore de limitations

Pour répondre à ces problématiques et favoriser l’émergence du web sémantique, la spécification propose :

• Un nouveau modèle de contenu des éléments
• Des éléments de mise en page
• De nouveaux éléments pour les formulaires
• Du contenu multimédia
• Plus d’interactivité
• Des APIs standards JavaScript

Bien que la spécification soit encore en cours d’écriture, certaines parties sont déjà très avancées et les navigateurs ont tous commencé à les implémenter. Google Chrome est actuellement en tête. Il bénéficie nativement de Gears et respecte 87% de la spécification. Parmi les principaux supporters de ce standard en devenir, nous retrouvons Google, Mozilla, Opera, Apple et Palm, pour ne citer que les plus grands. Apparemment, les navigateurs qui ont le vent en poupe sont tous de la partie. Microsoft, de son côté, suit la tendance de très loin en intégrant des fonctionnalités au compte goutte dans son IE, qui supporte tout de même 28% du langage.

Nouveau modèle de contenu

Bye, bye, les alignements hasardeux dus aux éléments de type bloc ou en ligne. Les éléments seront plutôt classés par catégories.

• La catégorie ancêtre Flow correspond à tous les éléments qui contiennent un flot de texte
• Phrasing correspond aux éléments qui apparaissent dans le texte (a, li)
• Interactive définit les éléments qui fournissent une interaction avec l’utilisateur
• Embedded affiche des ressource externes dans le document
• Les Metadata représentent tout ce qui n’est pas affiché (style, script, …)
• Heading définit les en-têtes d’une section
• Sectioning définit le scope des en-têtes et pieds de page

Toutes ces catégories permettent de définir le contenu autorisé pour les éléments. Leur but est d’une part de fournir une grande souplesse de composition (par exemple la balise a peut maintenant contenir un paragraphe entier, une liste ou des headers (h*)), d’autre part ces catégories permettent aux navigateurs d’assimiler le contenu de la page, notamment pour les exports d’impression ou l’accessibilité.

Nouveaux éléments de mise en page

Jusqu’à maintenant, l’élément de mise en page par excellence était la balise div. La grande majorité des sites est construite sur un modèle d’empilement de ces boites avec des id différents pour finir par une grosse partie de styles CSS assurant le positionnement. Mais cela a quelques inconvénients:

• Ce n’est pas intuitif pour le développeur, vous en conviendrez.
• Le navigateur ne peut pas connaître le rôle de chacune des parties de la mise en page, ce qui rend beaucoup plus difficile la génération de plan ou d’aide à la navigation.

Les balises article, section, header et footer indiquent clairement à quel type de texte elles correspondent et comment s’organise leur contenu. La balise aside définit un contenu lié au sujet principal, sans en faire partie pour autant. Reste le tag nav qui est prévu pour servir les liens de navigations de la page comme un menu par exemple. La mise en page proposée ci-dessus ne révèle pas la flexibilité d’utilisation de ces éléments. Notez bien que les article et section peuvent avoir leur propre header et footer.

Avec ces nouvelles balises, nous serons enfin capables de gérer l’organisation de nos documents de façon intuitive et les navigateurs pourront générer le plan des documents eux-mêmes. L’algorithme nécessaire est d’ailleurs décrit dans la spécification. Tous ces éléments sont déjà supportés nativement par les navigateurs avec l’exception habituelle de IE pour lequel il existe un workaround JavaScript. Vous pouvez dès maintenant vous familiariser avec ces nouvelles balises sans avoir peur des problèmes de compatibilité.

Eléments interactifs

Sous ce terme limpide se cachent les éléments qui fournissent de l’interaction utilisateur dans la page. Ce qui correspond aux Interactive elements de la spécification. La grosse nouveauté ici est la définition d’une balise menu permettant de construire des barres de menu (type="toolbar"), des menus contextuels (type="context") ou de simples listes de commandes. Un tag menu peut contenir des sous-menus et se compose d’éléments permettant de lancer des commandes.

<menu type="toolbar">
 <li>
  <menu label="File">
   <button type="button" onclick="fnew()">New...</button>
   <button type="button" onclick="fopen()">Open...</button>
   <button type="button" onclick="fsave()">Save</button>
  </menu>
 </li>
 <li>
  <menu label="Edit">
   <button type="button" onclick="ecopy()">Copy</button>
   <button type="button" onclick="epaste()">Paste</button>
  </menu>
 </li>
</menu>

Pour les commandes, HTML5 propose directement un élément command qui permet d’associer un texte ou icône à une exécution JavaScript sur événement onclick="alert('hello world')". Pour utiliser le menu contextuel, il suffit d’ajouter l’attribut contextmenu="menu_id", sur l’élément qui doit utiliser le menu.

L’autre nouveauté parmi les éléments interactifs est la balise details. Le fonctionnement de ce tag est proche d’un menu en accordéon, avec une partie de texte toujours affichée et une partie cachée pouvant être rendue visible sur demande de l’utilisateur. Cela peut être utile, pour cacher des options avancées par exemple.

<section class="progress window">
 <h1>Copying "Really Achieving Your Childhood Dreams"</h1>
 <details>
  <summary>Copying... <progress max="375505392" value="97543282"></progress> 25%</summary>
  <dl>
   <dt>Transfer rate:</dt> <dd>452KB/s</dd>
   <dt>Local filename:</dt> <dd>/home/rpausch/raycd.m4v</dd>
   <dt>Remote filename:</dt> <dd>/var/www/lectures/raycd.m4v</dd>
  </dl>
 </details>
</section>

Ici, le tag details est utilisé pour cacher les informations techniques d’une copie. Vous noterez au passage l’utilisation d’une balise progress, pour afficher une barre d’avancement.

Les WebForms

Nouveaux input

Les formulaires aussi profitent de la mise à jour en reprenant en partie XForms pour les connaisseurs. Le principe est de fournir des input fortement typés ainsi qu’une API JavaScript de validation en plus d’une interactivité accrue. Parmi les nouveaux types d’input, il y a :

• Le support des saisies de dates et heure décliné sous plusieurs formes (date, datetime, datetime-local, month, week, time). Nous n’aurons donc plus besoin des widgets supplémentaires JavaScript pour générer des calendriers.
• La saisie de formats numériques via les number et les range qui pourront prendre la forme d’un slider vertical ou horizontal
• Différents types de chaînes formatées comme les url, les email et tel
• Le selecteur de couleur color
• Le champ de recherche search

Les anciens types sont maintenus. Ils bénéficient d’un bon lifting, tel le type file qui permettra désormais de sélectionner plusieurs fichiers d’un seul coup, tout en précisant le type mime accepté. Il y a aussi l’attribut placeHolder qui permet de fournir un texte descriptif affiché dans le champs si il n’est pas renseigné.

Validation native

Tous les input supportent de nouveaux attributs de validation qui permettent de contraindre les saisies de l’utilisateur, et peuvent interdire la soumission du formulaire, s’il n’est pas valide. Encore une fois, cela permettra de remplacer des solutions hétérogènes JavaScript par un standard nativement supporté par le navigateur. La validation s’accompagne aussi de nouveaux évènements DOM pour notifier les erreurs ou surcharger la validation avec son propre code JavaScript. Plus besoin non plus de jouer avec les classes CSS pour faire ressortir les champs en erreur grâce aux pseudo-formats (:invalid, :valid, :Out-of-range, …).

Des validateurs par défaut sont fournis sous la forme de nouveaux attributs à placer sur les input :

• required pour un champ requis
• min et max permettent de définir une valeur minimum et maximum sur les types numérique et date
• pattern fournit une expression régulière que la saisie doit respecter

Auto-complétion

Autre nouveauté inspirée des widgets JavaScript existant, les datalist sont des listes de valeurs construites à l’aide d’éléments de type liste (li, option, …). La datalist est transparente par défaut mais elle peut-être liée à un ou plusieurs input avec l’attribut list. Une fois l’association établie avec un input, la liste est utilisée pour fournir des suggestions à la saisie. Les éléments à l’intérieur de la liste peuvent-être décorés par CSS directement.

<input type="text" list="roles" autofocus />
<datalist id="roles">
   <li>Designer</li>
   <li>Integrateur</li>
   <li>Programmeur</li>
</datalist>

Répétitions

Une autre évolution sympathique est la création d’un système de template, facilitant la création de formulaire dynamique. Dans les applications de gestion, il est souvent utile de pouvoir ajouter et supprimer des lignes de saisie dans le formulaire. Le système de répétition est fait pour ça. Je peux définir un bloc comme étant mon template, et le contenu de cet élément pourra être dupliqué via une API JavaScript.

<tr id="order" repeat="template" repeat-start="3">
   <td><input type="text" name="row[order].product" value=""></td>
   <td><input type="text" name="row[order].quantity" value="1"></td>
   <td><button type="remove">Remove This Row</button></td>
</tr>
<p><button type="add" template="order">Add Row</button><button type="submit">Submit</button></p>

C’est l’attribut repeat qui définit notre bloc de répétition, le repeat-start permet de gérer les aller-retour serveur, pour afficher la liste avec le nombre d’éléments précédemment soumis. Pour assurer l’ajout et la suppression de ligne, j’ai utilisé les boutons de type add et remove mais j’aurais aussi bien pu utiliser des méthodes JavaScript de l’élément template addRepetitionBlock(). Il y a aussi des solutions pour gérer l’ordre des répétitions permettant de monter et descendre les lignes répétées.

Etat des lieux

Voilà la promesse d’un monde meilleur dans lequel nous aurons moins de travail à fournir (CSS, JS) pour obtenir des résultats simplement meilleurs. Notez une dernière chose, les input peuvent être liés à un ou plusieurs formulaires via le nouvel attribut form. En d’autres termes, il sera possible de placer nos input pour un formulaire à l’extérieur de ce dernier.

Comme vous l’avez remarqué, j’ai utilisé le futur dans ce paragraphe car pour le moment seul Opera 9 supporte nativement les WebForms. Pour permettre aux développeurs de s’y essayer et valider la spécification, le projet WebForms2 propose une implémentation partielle en JavaScript. La spécification au départ avait été séparée du langage HTML5, mais le W3C a décidé de la ré-intégrer en y apportant des modifications. Du coup la plupart des fonctions développées sont liées à une ancienne version des WebForms.

Pour les autres navigateurs, notez tout de même que les développements ont déjà commencé. Par exemple Chrome 5 devrait être livré avec le support des nouveaux input et l’API de validation(Chrome Web Platform Status). Safari bénéficie du même support que chrome qui se limite aux types search, range et file multiple. Du côté de Firefox, les choses sont moins claires ; il existe bien un ensemble de bugs pour le support des WebForms mais Mozilla communique peu sur le sujet. Actuellement, Internet Explorer 8 ne supporte aucune des ces nouveautés et il est impossible de connaître la roadmap de Microsoft sur le sujet. Tout ce que l’on sait, c’est que l’éditeur a décidé de mettre les bouchées doubles pour améliorer son support des travaux du W3C. Peut-être une bonne solution pour inverser la vapeur et en finir avec la descente aux enfers de son précieux navigateur.

Page de démonstration pour Chrome, Safari et Opera.

Multimedia

Il est temps de parler des nouveaux types de contenu poussés par HTML5. Les auteurs du whatwg se sont probablement demandé pourquoi doit-on installer des plugins dans nos navigateurs ? Nous savons a priori tous aujourd’hui que Flash est utilisé principalement pour 3 choses dans les applications :

• Pouvoir écouter de la musique
• Pouvoir regarder des vidéos
• Faire des animations de folies

J’ai mis volontairement de côté Flex car il cible plutôt les applications d’entreprise, et les jeux Flash car le Boss ne veut pas en entendre parler . Sachez, si vous êtes passé à côté de ça, que HTML5 adresse ces trois problématiques en sortant trois nouvelles balises de son chapeau :

• audio permet de gérer la lecture de fichiers audio en streaming.
• video assure la lecture de vidéos en streaming toujours.
• canvas permet de dessiner et de faire des animations en JavaScript.

Audio et Video

Jusqu’à maintenant, les gros avantages de la technologie d’Adobe sont la portabilité puisque Flash est disponible pour tous les navigateurs, et la performance en comparaison avec les moteurs JavaScript. Il est clair que ces trois balises viennent marcher sur les plate-bandes de Flash. Les éléments média disposent des attributs :

• controls pour activer l’affichage de l’interface de contrôle du navigateur
• autobuffer pour activer le chargement automatique de la ressource en cache
• autoplay pour activer le lancement automatique de la lecture
• loop pour lire le ou les médias en boucle
• src pour fournir l’url du fichier média à lire

La balise source placée à l’intérieure d’une balise audio ou video permet aussi de définir l’url (@src), le type mime et le codec (@type) d’une ressource média. Il suffit de mettre plusieurs source pour créer une playlist.

<audio controls autobuffer autoplay loop>
  <source src="elvis.ogg" />
  <source src="elvis.mp3" />
</audio>
<video src="video.ogg" controls>
  <source src='video.mp4' type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'>
  <!-- Un texte alternatif pour les anciens navigateurs -->
  Your browser does not support the <code>video</code> element.
</video>

Si le navigateurs n’arrivent pas à lire le fichier ogg, il tentera de lire le fichier H.264. De même, si le navigateur ne supporte pas l’élément video, il affichera le texte alternatif. Il suffit donc de placer un lecteur Flash à la place du texte pour que la vidéo reste lisible dans un ancien navigateur.

Si vous ne voulez pas utiliser l’interface native, ou que vous souhaitez simplement cacher le lecteur audio, vous pouvez utiliser l’API standard JavaScript pour créer un lecteur, et profiter des méthodes play(), pause(), et load() pour charger la prochaine ressource média. Une dernière méthode : canPlayType(type), permet de demander au navigateur si il supporte le format vidéo ou audio fournit en paramètre. Cela sera très utile pour gérer les incompatibilités de format.

De plus l’interface HTMLMediaElement fournit quantité de propriétés allant du volume à l’état du buffer en passant par le temps de lecture courant. Le tout est, bien sûr, accompagné d’une batterie d’événements qui permettent de suivre l’avancement du chargement, l’état du lecteur, et les action lancées par l’utilisateur.

Pour plus de détail sur le sujet, je vous invite à lire la spécification W3C des éléments média et à tester la démo de jPlayer un lecteur audio pour jQuery.

La guerre des Codecs

Venons en au problème des codecs. Le W3C se contente de citer un certain nombre de formats allant du H.264 au DIRAC pour la vidéo en passant par mpeg-4 et Theora; même chose pour l’audio avec AAC, FLAC, Vorbis, … La spécification laisse le libre choix aux navigateurs et table sur la création d’extensions propres à ces derniers pour apporter le support de nouveaux formats. Si aujourd’hui YouTube et Vimeo ont choisi le H.264, DailyMotion joue les fidèles Mozilla avec sa démo basée sur Ogg et ne supportant que Firefox.

Chrome et Safari poussent H.264 tandis que Mozilla le rejette totalement et pousse les formats libres Vorbis et Theora (Ogg). Le gros avantage d’H.264, à mon sens, tient au fait qu’il est parfaitement adapté à l’embarqué et beaucoup plus optimisé que Theora. Malgré le barrage de Firefox (25% de parts de marché), avec Apple et Google le codec H.264 semble avoir de beaux jours devant lui. Google qui est justement le plus gros contributeur de Mozilla, fournira peut-être une extension, sinon ce sera probablement du codec pack pour tous.

Codecs supportés par navigateurs

Internet Explorer est pour le moment hors-jeu, sauf si on installe Google Chrome Frame. Mais il semblerait que Microsoft s’intéresse au sujet pour l’avenir et participe à la rédaction de la spécification. En attendant, Flash conserve une avance confortable et profite de sa très large base installée. Le changement arrive bizarrement par l’embarqué, iPhone et iPod Touch en tête, qui, d’une part, supportent pleinement les balises audio, et video, et d’autre part prouvent que les utilisateurs peuvent se passer de Flash sur le web.

Le Canvas

Passons maintenant au canvas. Inventé par Apple pour le Dashboard d’OS X et ses widgets, le canvas fournit une API JavaScript pour le dessin 2D. La balise définit une aire de dessins avec sa hauteur et sa largeur. L’objet DOM donne accès au contexte graphique qui possède les primitives de dessins. Outre les formes géométriques standards, l’API permet de faire de la composition, des transformations, de manipuler des images et d’afficher du texte formaté. Avec un timeout ou un intervalle sur l’objet et un peu de JavaScript, il devient possible d’animer les dessins. Les implémentations ne sont pas encore très optimisées. Un simple gif animé reste pour le moment plus performant en terme d’animation. Il existe déjà un tas de librairie JS construites autour de l’élément canvas pour générer des graphes et des charts par exemple (Flotr, ProtoChart, fgCharting).

<canvas id=firstCanvas">Browser does not support the canvas element.</canvas>
<script type="text/JavaScript">
var canvas=document.getElementById('myCanvas');
var ctx=canvas.getContext('2d');
ctx.fillStyle='#FF0006';
ctx.fillRect(0,0,80,120);
</script>

Les détracteurs déplorent l’utilisation d’une API procédurale, et l’absence d’éléments crées dans l’arbre DOM de la page comme le fait SVG. Autre inconvénient, canvas travaille la composition directement en pixels et non en calques. SVCKit a donc implémenté en grande partie SVG dans canvas dans SVGCanvas. Il existe déjà beaucoup de documentations et tutoriels autour de canvas qui rencontre, malgré ses défauts (de jeunesse ?), un grand succès. Mozilla a même développé un IDE en ligne basé sur canvas, nom de code : BeSpin.

Voilà pour les domaines d’application, passons maintenant à la question des navigateurs. Avec Apple pour inventeur et Mozilla comme évangéliste, canvas est déjà supporté nativement sur Safari, Firefox, Chrome et Opéra. Comme d’habitude IE est à la traine, mais il existe des contournements comme le plugin IECanvas, ou le portage Flash ExplorerCanvas.

Conclusion

Nous voici à la fin de ce tour d’horizon des nouveautés d’HTML5, côté contenu du moins.
Avec les grands du web dans la poche, HTML5 est déjà promis à un bel avenir, malgré son jeune age. La prochaine échéance du W3C devrait être le passage en recommandation dans le courant de cette année peut-être. Si les WebForms ne sont pas pour tout de suite, le multimédia et le canvas sont déjà suffisamment supportés pour être utilisés aujourd’hui. Il faudra attendre la sortie d’IE 9 pour connaître les plans concrets de Microsoft sur le sujet. A mon humble avis, Microsoft intégrera HTML5 au fur et à mesure qu’il s’imposera sur le web. Il faudra aussi regarder de près l’évolution du standard CSS car HTML5 ne va pas sans CSS3. De ce côté, pas de crainte à avoir puisque même IE est dans la course.

Il reste un problème d’outillage, car il n’existe pas pour le moment de WYSIWYG compatible HTML5. Et il ne faut sans doute pas compter sur Adobe pour le faire rapidement. Apple propose déjà DashCode pour créer des widgets ou des applications web iPhone avec un éditeur graphique bien monté. Mais l’export vers d’autres navigateurs est presque impossible tant les applications construites reposent sur des fonctionnalités spécifiques de Safari.

Dans le prochain article, je vous présenterai les nouveautés JavaScript poussées par HTML5 et leur état actuel d’implémentation.

Malgré tout, l’outil de Google a attisé notre curiosité, principalement grâce à son architecture ouverte et à ses possibilités d’extension.

Trois protocoles, deux APIS

Google Wave Federation Protocol

C’est là tout l’intérêt et le cœur du produit de Google. En effet, grâce à ce nouveau protocole ouvert et standardisé, l’hébergement d’un serveur Wave peut se faire indépendamment de Google. Et c’est là le nerf de la guerre pour l’entreprise : contrairement à Google Docs, qui centralise les documents sur une plateforme hébergée chez l’éditeur, l’aspect ouvert du protocole de fédération entre serveurs Wave va permettre à chaque entreprise de garder la maîtrise sur ses Waves, et sur les documents qui les composent. Certains imaginent déjà la très belle utopie d’un client passant commande à son fournisseur via une Wave commune, gérant des processus complexes (passage de commande, envoi de devis automatisé, workflow humain de validation et facturation automatique…).

Si l’on s’intéresse d’un peu plus près à ce protocole, on constate qu’il s’agit d’une extension du protocole bien connu XMPP (précédemment nommé Jabber). Google s’est appuyé sur le mécanisme d’extension de ce protocole (XEP 114) pour renforcer en particulier la sécurisation des échanges inter-serveurs mais aussi l’authentification forte d’un utilisateur auprès de ses waves.

Schématiquement, ce protocole s’appuie sur des mécanismes de Gateway / Proxy. Chaque serveur possède une Gateway, qui s’occupe des modifications locales de chaque Wavelet hébergée. Cette Gateway pousse ensuite ces modifications vers les Proxys des autres serveurs participant à la Wave.

Ce protocole étant ouvert, vous pourrez trouver une documentation riche sur le site de Google, via le draft de spécifications et de nombreux white papers.

Et si vous voulez vous lancer dans l’expérience, Google propose, outre le serveur Wave servant à la bêta, un serveur prototype implémenté en Java.

Protocole client-serveur

Pour interagir avec une Wave, chaque participant doit s’équiper d’un client. Pour l’instant, il n’en existe qu’un seul, le client web créé par Google et disponible sur https://wave.google.com/wave/ (ou une des ses encapsulations, comme WaveBoard). Le protocole qui permet d’échanger avec le serveur Wave n’est pour l’instant pas encore spécifié, mais des tentatives en ce sens existent.

Le client web de Google est une application HTML 5, développée avec GWT. Il communique avec le serveur suivant un protocole GWT propriétaire, porté par HTTP.

L’espoir de standardisation du côté des clients est cependant tangible : la société ProcessOne a réalisé un client prototype basé sur XMPP.

API Robot et JSonRPC

Dernier protocole, et non des moindres, le protocole qui permet aux robots (pour les fans d’irc, on parle de bot) d’intervenir dans une Wave. Pour se faire, ils utilisent JSon-RPC, sur HTTP.
Ces robots fonctionnent sur une programmation événementielle. Ils sont donc à priori agnostiques vis à vis du langage. Il existe actuellement 2 API fournies par Google : une pour Java, que nous détaillerons dans un prochain article, et une pour Python.
Les robots peuvent interagir avec la Wave (ajout de participants, modification du contenu de la Wave, envois d’alertes) en étant déclenchés par des évènements internes à la Wave (arrivée d’un nouveau participant, publication de texte, déclenchement par mot clé).

API Gadget

Il existe une autre façon d’enrichir les fonctionnalités de la Wave : les gadgets. Les gadgets sont des briques de code (HTML + javascript), bien connus des utilisateurs de iGoogle, embarqués dans le client Wave. Ils sont similaires à ceux de l’API OpenSocial, même si curieusement celle-ci n’est pas officiellement compatible. La différence avec les gadgets statiques est que les gadgets Wave tirent profit de l’aspect ‘live’ de la Wave et peuvent interagir avec celle-ci. Ils comportent une gestion d’état, ont connaissance de l’utilisateur en cours de visualisation et des utilisateurs connectés et s’intègrent au mécanisme de playback.
Nous reviendrons là aussi plus en détail sur l’écriture de gadget.

Synthèse

Pour résumer ces différents protocoles, le plus simple est encore de les représenter sur un schéma.

source : J Aaron Farr

Avec des extensions correctement pensées et développées, Wave semble pouvoir être un énorme atout dans la communication interne de l’entreprise.
Alors, serez-vous les premiers à installer un serveur Wave en remplacement de votre bon vieil SMTP ?

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

• Subversion, le nouveau projet de la Fondation Apache
• MuleSoft annonce Mule Data Integrator
• Des nouvelles de Tomcat 7

RIA

• Atmosphere, atmosphere ?

Le coin de la technique

• Sortie de JRuby 1.4.0
• Le mouvement NoSQL divise et intrigue

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

• Soirées Google et Atmosphere au Paris JUG

Actualité éditeurs / SSII

Subversion, le nouveau projet de la Fondation Apache

C’est officiel, Subversion fait maintenant partie des projets de la fondation Apache. Avant de pouvoir devenir projet top-level, Subversion doit d’abord passer par l’incubateur. Durant cette période, CollabNet continuera d’héberger le projet sur http://subversion.tigris.org. De plus, les différents binaires continueront d’être publiés sur ce site au-delà de la période d’incubation. Nous sommes donc en droit de nous demander ce que cette nouvelle va finalement changer ?

Certains imaginent la refonte de Subversion pour lui ajouter des fonctionnalités de gestionnaire de sources distribué, comme GIT ou Mercurial. Il est pourtant difficile de croire à une telle transformation, Subversion étant connu comme le gestionnaire centralisé star du moment. Un tel virement de bord signifierait la fin de ce modèle centralisé.

D’autres perçoivent au contraire cette nouvelle comme une fierté personnelle et voient l’arrivée de Subversion dans l’ASF comme un aboutissement. Le projet est assez mature pour rentrer dans une nouvelle phase et Apache est la maison idéale pour le faire vivre sur le long terme tout en pérennisant la communauté.

Au final, la véritable réponse à cette question se situe probablement entre ces deux visions. Pourquoi le projet ne continuerait pas tout simplement à avancer sur le chemin qu’il suit depuis sa création ? Il lui reste du trajet à parcourir : performances, intégration avec les IDEs, outillage …

MuleSoft annonce Mule Data Integrator

MuleSoft annonce aux abonnés de sa newsletter l’arrivée en version beta de Mule Data Integrator, un outil permettant de définir facilement des mappings de données de toutes formes (XML, JavaBeans, WSDL, base de données, fichier simple, …). Ces modèles d’intégration de données peuvent ensuite être exploités directement par un transformer spécifique pour Mule ESB. L’outil se présente sous la forme d’une application Eclipse.

Il s’agit là d’une réponse à une problématique courante puisque Mule ESB simplifie l’intégration entre protocoles mais laisse au développer le soin d’apporter sa solution de transformation de données en se basant sur XSLT ou Java. On appréciera donc une telle possibilité offerte sur un ESB Open Source, même si aucun détail n’est pour le moment fourni quant à la licence pratiquée sur Mule Data Integrator.

Cette annonce fait suite à une activité très dense de l’éditeur ces derniers mois qui avait déjà créé la surprise avec iBeans et son offre Tcat Server. Fort de ce portfolio plus dense et plus riche, MuleSoft cherche donc à devenir un éditeur pour solutions d’entreprise à part entière, et non plus simplement l’entreprise derrière l’ESB à succès.

Des nouvelles de Tomcat 7

A l’occasion des festivités organisées à l’ApacheCon2009 pour les 10 ans d’Apache, les annonces furent nombreuses. Nous avons déjà parlé de l’arrivée du projet Subversion, dans le giron de la fondation. Outre l’utilisation par la maison blanche du projet Drupal, ce fût aussi l’occasion d’annoncer l’arrivée prochaine de Tomcat 7. Mark Thomas, interviewé par Dzone sur le sujet, parle d’une version alpha pour la fin de l’année. Voilà qui serait un beau cadeau de Noël pour la communauté. Dans l’interview, Mark revient sur les nouveautés attendues dans cette nouvelle version, le but principal étant bien sûr d’implémenter l’API Servlet 3.0. Tomcat supportera les web fragments et la déclaration dynamique de Servlet et Filter.

Côté sécurité, Mark annonce le SSL session tracking pour utiliser les identifiants de session SSL, une plus grande séparation des rôles utilisés pour l’administration (par script, par le web ou par JMX), et l’utilisation de jetons temporaires (nonce) en protection contre les attaques de type Cross Site Request Forgery. Une autre nouveauté majeure annoncée par Mark est la capacité de Tomcat 7 à être embarqué dans une application. Selon ses dires il suffit de 8 lignes de codes pour lancer Tomcat et configurer son application web.

Restent les logs asynchrones, l’ajout d’alias permettant d’héberger des répertoires du système de fichier hors du contexte standard de l’application, et de nouvelles protections contre les fuites mémoires. L’interview complète sur Dzone…

RIA

Atmosphere, atmosphere ?

Pas mal de buzz en ce moment autour du framework web Atmosphere (via TSS pour la sortie du produit en version 0.4) qui permet de créer des applications RESTful et Ajax Push/Comet.
Le framework supporte entre autres Java, JRuby, Groovy et Scala. Plusieurs exemples sont disponibles pour ce dernier avec notamment l’intégration d’Atmosphere avec Akka et Jersey (ici).

Au menu des nouveautés depuis la 0.3, une intégration avec Wicket et GWT, une intégration simplifiée avec des applications existantes (servlet based), le support des derniers protocoles bayeux, le support d’EJB 3.1, et OSGi ready …

Si ce framework vous intéresse, allez donc faire un petit tour au Paris JUG !

Le coin de la technique

Sortie de JRuby 1.4.0

L’équipe du projet JRuby annonce une nouvelle version de l’interpréteur Ruby full-Java. Parmi les avancées :

• Compatibilité avec Ruby 1.8.7 patchlevel 174
• Nouveau parser YAML, portage complet de Syck!
• Meilleure intégration de Java, plus rapide
• Installeur Windows
• Avancée du support de Ruby 1.9
• 307 bugs corrigés depuis la version 1.3.1

Le support de Rails dans sa dernière version est pleinement assuré et les objectifs pour le futur sont axés sur le support complet de Ruby 1.9.

Le mouvement NoSQL divise et intrigue

Le nom NoSQL est apparu courant 2009 pour qualifier un mouvement initié depuis longtemps mais qui a pris une importance et une visibilité particulière ces derniers mois. Il regroupe l’ensemble des projets proposant une solution de persistance de données non relationnelle qui se caractérisent par un design favorisant la scalabilité et la flexibilité. On reconnaît dans ces deux caractéristiques les besoins du Web, dont les grands acteurs que sont Google, Amazon et Facebook ont joué un rôle important en apportant leur propre solution (respectivement BigTable, SimpleDB et Cassandra).

Remettre en question le stockage relationnel exclusif qui s’était imposé presque comme une évidence dans le monde de l’entreprise ne pouvait se faire sans initier de nombreux débats. La dernière intervention en date est celle de Michael Stonebraker qui critique vivement cette initiative en avançant :

• Le choix du NoSQL comme solution de persistance est en général amené par un besoin de performance et de flexibilité. Ces deux caractéristiques peuvent être assurée par les RDBMS traditionnelle par la mise en place de bonnes pratiques épaulées d’un éventuel sharding
• Les systèmes NoSQL souffrent eux aussi de certaines des problématiques des RDBMS et ne sont donc pas une solution parfaite
• L’utilisation de procédures stockées permet d’obtenir la performance voulue dans de nombreuse situations

Ces arguments, assez classiques à l’encontre du NoSQL, sont opposés à ceux mis en avant par Debasish Ghosh, l’auteur du prochain DSLs in action à paraître chez Manning :

• Le sharding, solution souvent mise en avant pour sauver la scalabilité des RDBMS, est une solution très lourde à mettre en place, qui évolue mal et qui est très intrusive dans la logique métier ; elle est appliquée à des systèmes qui n’ont pas été prévus pour une telle utilisation
• Le théorème CAP montre que seule une approche différente des RDBMS classiques permet d’obtenir les performances voulues
• Une coopération intéressante se met en place entre les projets NoSQL afin de permettre des interopérabilités (tel que Neo4j s’appuyant sur Cassandra ou Riak sur CouchDB)

La remise en question apportée par le NoSQL est forcément bénéfique et ne peut amener qu’une innovation. Si le mouvement est encore récent et qu’il doit gagner en maturité, il amènera probablement à se poser plus naturellement la question de la ou des meilleure(s) solution(s) de persistance pour les données d’une application ou d’un système d’information.

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

Soirées Google et Atmosphere au Paris JUG

Pour rebondir sur la news ci-dessus concernant le framework Atmosphere, le Paris JUG nous propose ce jeudi 12 novembre une soirée spéciale Atmosphere.
A l’heure où nous écrivons ces lignes, il reste encore quelques places donc c’est maintenant ou jamais pour vous inscrire !

Toujours par le Paris JUG, la deuxième soirée de la semaine, mardi 10 novembre, autour de Google Wave / Android / App Engine affiche complet :p !
La remise à disposition des places des personnes non présentes 5 minutes avant le début de la session reste envisageable mais l’abonnement à la newsletter / rss / autre reste quand même le meilleur moyen d’être averti à temps !

SOA

• SOA Manifesto : pragmatisme utopique ?
• WADL devient une Submission W3C

Le coin de la technique

• Play! Framework 1.0
• Mise à jour de VisualVM en 1.2
• Comment concevoir un datacenter, … par Google
• Ca bouge dans la communauté Groovy/Grails
• Votre application web est elle vulnérable ?
• Artifactory : évolutions et mode SaaS

SOA

SOA Manifesto : pragmatisme utopique ?

La communauté SOA vient de publier son SOA Manifesto. Les valeurs sont très consensuelles, on pourrait même les trouver trop lisses quand on a vécu un naufrage SOA (avec l’oubli des objectifs métier, sa perfection naïve initiale, ses services faussement partagés qui finalement ne satisfont même pas le premier consommateur et autres ESB passe-plats).

Saluons tout de même cette initiative. SOA est une réalité. Les projets utopistes sont aujourd’hui minoritaires face à tous les projets qui intègrent des web services pour interconnecter les applications.
Le Manifeste SOA en français :
Valeur métier plutôt que stratégie technique,
Objectifs stratégiques plutôt que bénéfices spécifiques à un projet,
Interopérabilité intrinsèque plutôt qu’intégration propriétaire,
Services partagés plutôt qu’implémentation spécifique à un besoin particulier,
Flexibilité plutôt qu’optimisation,
Amélioration incrémentale plutôt que recherche de la perfection initiale.

Et rassurons-nous, ce n’est pas un manifesto qui empêchera les zélotes SOA de se déchirer. La guerre SOAP versus REST bat (toujours) son plein .

Ils parlent du SOA Manifesto : InfoQ SOA Manifesto, Stefan Tilkov’s Weblog : Comments on SOA Manifesto.

Allez, je retourne à mes web services Contract First avec CXF .

WADL devient une Submission W3C

Marc Hadley, auteur de la spécification WADL et spec-lead de la JSR-311 (JAX-RS), a annoncé que WADL venait d’être accepté en tant que Submission W3C.

Cette spécification portée par Sun a pour but de définir un format XML de description de services REST. Il s’agit donc d’un équivalent à WSDL pour REST. Alors que REST-*, porté par JBoss, a récemment relancé le débat sur la tendance récurrente à vouloir intégrer dans REST les fonctionnalités des très controversés WS-*, la soumission de WADL au W3C fait réapparaître la question de l’intérêt de définir des contrats pour des services REST.

Joe Gregorio s’opposait vivement à l’initiative WADL il y a deux ans déjà. Il reprochait principalement :

• l’insuffisance de WADL pour définir élégamment tous les types de services REST
• la fragilité du client qui ne fonctionne plus lorsque le contrat change comme c’est déjà le cas avec WSDL
• le manque de réalisme de l’approche WADL2Java qui ne permettrait pas la pleine exploitation de REST. Il préférait donc une approche d’écriture du client REST manuelle, en se basant sur un socle commun.

Toutefois, l’approche « REST avec un contrat » est séduisante pour les applications d’entreprise dont les services sont souvent aussi nombreux que les consommateurs variés.
C’est dans cette logique que de nombreux projets lèvent les ambiguïtés de leurs services REST en préférant XSD à JSON. Les URL et paramètres d’appel restant alors décrits uniquement dans une documentation annexe.

Par ailleurs, on peut regretter que WADL n’ait pas mieux adressé que WSDL des problèmes aussi important que le versioning des services alors qu’un projet comme Apache Thrift a su être innovant sur le sujet.

La soumission de WADL au W3C n’implique donc pas forcément son succès à venir. La disponibilité en masse d’outils et de frameworks permettant de gérer ce format pourrait en revanche attirer une partie des adeptes de SOAP.

Le coin de la technique

Play! Framework 1.0

The Server Side nous annonce la sortie de Play! Framework en version 1.0.

Play! est un framework web de haute productivité (tout comme Grails ou Spring Roo) qui simplifie la création et le développement d’applications Web en langage Java. Ce framework full stack inclut tout une batterie de composants tels que Groovy (pour le templating), Apache Mina mais aussi Hibernate. Quant à l’architecture de vos projets Play!, elle sera de type RESTful.

Cette vidéo nous donne un bon aperçu du produit, surtout en ce qui concerne le fameux Fix the bug and hit reload ! c’est à dire pas de compilation, de déploiement ou de redémarrage serveur suite à la modification de vos classes Java, juste un rafraîchissement de votre navigateur pour voir vos modifications.

A noter que l’équipe travaille déjà sur la version 1.1 et, entre autres, sur le support de Scala

Pour les liens utiles, la documentation complète du produit se trouve sur cette page. Le téléchargement se passe par ici. Et, comme le rappelle TSS, n’oubliez pas la présentation Play! framework in practice à Devoxx, en tous cas nous y serons !

Mise à jour de VisualVM en 1.2

8 mois après la sortie de la version 1.1, l’équipe nous gratifie d’une nouvelle version de son outil de monitoring de JVM. Avec un passage de 1.1.1 à 1.2, il ne faut pas s’attendre à de grandes révolutions. Une liste de 31 bugs corrigés, suivie de quelques nouvelles fonctionnalités notables:

• Un sampling profiler CPU et mémoire
• Support de plusieurs instances de JStatd
• Amélioration de l’API de génération de graphes
• Sauvegarde d’un snapshot de l’application dans un fichier nps pouvant-être utilisé plus tard pour analyse

Nous vous passons les améliorations de GUI et le support des proxys qui peut toujours s’avérer utile pour les analyses à distance. La vraie grande nouveauté c’est le plugin permettant de profiler l’application par sampling. Il ne faut pas s’attendre à la précision des outils instrumentant l’application comme JXInsight. Cependant, cela permettra une analyse assez poussée sans impact sur les performances.

Comment concevoir un datacenter, … par Google

Lors de la conférence Ladis 2009 (Large Scale Distributed Systems and Middleware), Jeff Dean, du groupe infrastructure chez Google, a présenté les manières de concevoir un système distribué.

Il passe en revue différentes problématiques :

• Infrastructure
• Stockage
• Clustering
• Échange de données sur le réseau
• Communication entre applications
• Construction d’application sur de telles infrastructures

Il est intéressant de voir les problématiques posées et les solutions proposées, sur des problématiques que nous avons trop tendance à oublier en tant que développeurs. Citons entre autres :

• Latence réseau : un critère important, car difficile à optimiser
• Bande passante du réseau
• Capacité de stockage (mémoire et disque)

Il est donc très important même pour un développeur d’avoir ces chiffres en tête.

Par retour d’expérience, Jeff Dean montre les joies d’interagir avec du matériel physique. Les applications ne doivent pas supposer que le matériel est infaillible, il y a différentes erreurs que nos applications doivent gérer. Quand on voit les nombres d’occurrences de ce type de problème et leur nature, leur gestion par l’application n’est pas aussi triviale qu’il y parait :

• Problème DNS
• Plantage de serveur
• Perte de connections
• …

Cette présentation est très riche, et elle permet de voir les tenants et aboutissants d’une bonne infrastructure mais aussi les impacts que cela peut avoir dans nos développements de tous les jours.

Les contraintes que s’est imposé Google en terme de disponibilité, dimensionnement, … ont amené plusieurs innovations technologiques en terme d’infrastructure qui ont des impacts sur le développement applicatif :

• Protocol Buffer
• MapReduce
• Google File System
• Big Table

Les lecteurs intéressés par les innovations mises en place par Google sur ses infrastructures noteront que Gregor Hohpe (auteur de Enterprise Integration Patterns) présentera à Devoxx une session Distributed Programming the Google Way.

Ca bouge dans la communauté Groovy/Grails

Pour commencer, on peut noter la longue présentation de Grails faite par Graeme Rocher sur InfoQ. Le « papa » de Grails revient sur de nombreux points relatifs à ce très bon framework permettant de créer des applications web rapidement en bénéficiant de la puissance de Java, Groovy, Hibernate, Spring…

Ensuite, et c’est la rançon du succès, il y a beaucoup de discussions et d’interrogations autour des besoins auxquels répondent Groovy et Grails. Sur son blog, Peter Delahunty précise par exemple que, pour lui, Grails n’est l’arme absolue que si on a une bonne connaissance des technologies sous-jacentes (Spring, Hibernate…). Il ne faut pas débuter par Grails sans s’attendre à bloquer sur des problèmes relatifs à ces technologies.

Cet article va dans le même sens et rappelle qu’à partir du moment où l’on parle de « la magie Groovy » il faut être conscient que des choses qui n’ont rien de magique (cela reste du code !) se passent. Les « dynamic finders », le MOP (Meta Object Protocol) et la magie des closures font rêver mais s’expliquent bel et bien ! Ensuite, il y est noté que la proximité de Groovy et Java fait que de nombreuses personnes pensent que l’on peut passer de Java à Groovy sans formation particulière. Si l’on ne comprend pas les principes de ces choses magiques et que l’on se contente de les accepter comme tels, on s’expose tôt ou tard à des retours de flamme sévères qui se matérialisent généralement sous la forme de StackTraces incompréhensibles. Enfin, le manque de support professionnel pour Groovy/Grails est évoqué. Sur ce point, je pense que l’auteur se trompe. On note en effet que Springsource semble fournir un support commercial pour ces technologies. Mais, il y a peu, Groovy et Grails n’étaient pas encore dans le giron de Springsource et l’on devait « se contenter » du support de la communauté. Néanmoins, celui-ci a toujours été assez réactif et de bon niveau.

Toujours concernant Groovy, on peut noter la version Community Edition de l’IDE IntelliJ, tout récemment publiée, semble bien lotie au niveau du support de ce langage. Malheureusement, le support de Grails, lui, n’est pas présent dans cette version.

Votre application web est elle vulnérable ?

Le Web Application Security Consortium (WASC) estime que 87% des applications de la toile sont vulnérables. Tout le monde ne peut pas s’offrir les services d’un expert en sécurité, et un développeur ne peut pas écrire du code sécurisé s’il ne connaît ou ne comprends pas les risques auxquels il s’expose. C’est pour cette raison que DeveloperWorks revient sur les principales failles de sécurité qui nous guettent, et quelques outils simples pour analyser notre code.
Les points de faiblesse les plus connus sont :

• le cross site scripting : le pirate injecte, via un autre site (de type forum par exemple), un script (de type javascript) vers le site visé. Ce script lui permet de récupérer des informations de connexion, des cookies…
• l’injection de SQL : le pirate saisit du code SQL dans un formulaire web. Celui-ci est poussé jusqu’à la base, exécuté et donne (le plus souvent) accès à la base ‘en direct’ au pirate (l’un des exemples le plus connus est l’injection de OR 1=1- dans un formulaire d’authentification, qui retourne alors toujours TRUE).

Et l’on reparle de l’OWASP, qui propose un outil open source pour détecter ces erreurs de conception : WebScarab. WebScarab s’utilise comme un proxy HTTP (qui se place entre votre browser et votre serveur d’applications, par simple redirection des ports). Ensuite, un simple fichier .txt permet d’injecter votre site avec quelques-uns des plus célèbres cas de cross site scripting ou d’injection SQL. Un autre outil open source est présenté, d’un fonctionnement similaire, Paros Proxy.
Reste ensuite à détecter les faux positifs, opération généralement manuelle.

On notera que la section Ressources de l’article original est richement fournie, et permet de réellement comprendre les risques auxquels sont exposées les applications accessibles sur internet.

Saurez-vous trouver les failles du site de test Webgoat ?

Artifactory : évolutions et mode SaaS

Artifactory est un repository Maven dont la principale particularité est de s’appuyer sur Java Content Repository (JCR) pour assurer le stockage des artefacts. Le choix de JCR plutôt qu’un simple système de fichiers n’avait pas fait l’unanimité car il rend les tâches courantes d’administration plus délicates. En effet, lorsque l’on veut supprimer, remplacer ou déplacer un ensemble d’artefacts, l’action est triviale lorsque le système de fichier est utilisé alors qu’elle devient plus complexe avec JCR, qui n’est pas aussi directement manipulable.

Conscient de ce problème JFrog, l’éditeur derrière Artifactory, a peu à peu intégré un certain nombre de fonctionnalités permettant d’effectuer ces tâches courantes d’administration des artefacts directement depuis l’interface Web. Ainsi, la dernière version du projet permet même le déplacement d’artefacts entre plusieurs repository.

Début septembre, JFrog a également lancé ArtifactoryOnline, un service d’hébergement de repository Maven Artifactory en mode SaaS (Software as a Service). Ce type d’offre répond clairement à un besoin puisque la présence d’un repository Maven est souhaitable pour de nombreux cas d’utilisation et que cette infrastructure nécessite du temps et du matériel dont ne disposent pas toujours les équipes de taille réduite.

Par ces innovations, le repository Maven de JFrog saura sûrement séduire les utilisateurs déçus par les solutions concurrentes que sont Nexus et Archiva.

Article mis à jour le 26/10/2009 à 21h25

Actualité éditeurs / SSII

• Google essuie les plâtres et met à jour l’Android NDK
• MIDP 3 et MSA 2 pour sauver J2ME ?

Agilité

• Départs de la Scrum Alliance : bruits de couloirs

RIA

• Sécurité : 13 choses que les agresseurs d’applications web ne vous diront pas

Le coin de la technique

• Les roadmaps des implémentations de JPA 2.0
• Web Beans est mort ! Longue vie a Weld !

Actualité éditeurs / SSII

Google essuie les plâtres et met à jour l’Android NDK

Pour rappel, le NDK est un environnement de développement complémentaire au SDK qui permet d’utiliser des langages autres que Java pour développer sur Android. Ce NDK est principalement dédié au développement C et C++. Parmi les nouveautés de la version 1.6, vous trouverez :

• Les librairies OpenGL ES 1.1 qui rapprochent encore un peu Android de l’IphoneOS.
• Ciblage de version Android pour garantir le fonctionnement de votre application.
• Possibilité de mélanger les sources Java et le code natif dans un même projet.

Mais la semaine passée fût aussi l’occasion d’une joute entre Google et certains développeurs Android. Sujet de la discorde, le CyanogenMod une version libre, modifiée, d’Android. Google n’a pas apprécié le fait que son développeur ait la riche idée de distribuer avec son mod, les applications propriétaires qui lui sont chères. Citons par exemple : GMail, YouTube, Maps et Market. Nul besoin de dire que le système perd de son intérêt quand il est privé de ces outils estampillés Google…

Le spécialiste de la recherche a donc demandé l’interruption de toute distribution de ce mod, en attendant que le développeur trouve un moyen de livrer de l’Android sans aucune des G-Apps. C’est un baptême du feu pour ce système que Google a voulu ouvert. D’aucun disent que Google avait la possibilité de créer une alternative libre au jardin d’Eden d’Apple entouré de hauts remparts, à la place ce sera un autre jardin avec des murs un peu plus bas.

MIDP 3 et MSA 2 pour sauver J2ME ?

Mobile Information Device Profile (MIDP), associé à Connected Limited Device Configuration (CLDC) constitue l’API de base de J2ME, c’est cette architecture qui constitue le parc de 2 milliards de devices revendiqués par SUN.

La JSR-248 (Mobile Service Architecture), quant à elle, définit un ensemble d’APIs additionnelles pour les environnements MIDP J2ME apportant chacune un service particulier permettant souvent d’accéder à des fonctionnalités matérielles sous-jacentes (Bluetooth, GPS, Camera, …).

Ces deux piliers de J2ME sont en train d’évoluer avec la finalisation de MIDP 3 et MSA 2. Tandis que le premier apportera un rafraichissement de l’API de base de J2ME, le second poussera plus loin les possibilités d’intégration des applications mobiles J2ME.

Alors que les valeurs montantes du moment dans le monde du développement mobile sont clairement les plates-formes Android et iPhone, le rafraîchissement des APIs J2ME vieillissantes est le bienvenue et viendra épauler JavaFX Mobile dans son hypothétique ascension. On peut toutefois douter que cela suffira à inverser la tendance même si J2ME, fort de son parc colossal, n’est clairement pas menacé à court terme.

Agilité

Départs de la Scrum Alliance : bruits de couloirs

Vous le savez surement, la fin de l’été a marqué un tournant au sein de la Scrum Alliance.
Le 15 Septembre, dans un communiqué laconique (et très américain – nous remercions … blablabla pour son excellent travail … blabla), il nous était annoncé le départ de deux éminents membres de la Scrum Alliance, Ken Schwaber (son CEO) et Jim Cundiff (son Managing Director).
Après une enquête acharnée et au détour de quelques indiscrétions de sources (que nous ne citerons pas), il s’avère que Ken a eu un grave accident de vélo et que Jim a été démissionné compte tenu de ses manquements dans la refonte du processus de certification dont il était en charge.

RIA

Sécurité : 13 choses que les agresseurs d’applications web ne vous diront pas

Le Denim Group regroupe dans 13 Things a Web Applications Attacker Won’t Tell You les principales failles de sécurité de nos applications web :

1. Transformer une requête GET en POST ne cachera pas les paramètres même s’ils n’apparaissent plus dans la barre d’adresse du navigateur (vérifiez avec Charles Proxy ou Fiddler si vous en doutez).
2. Utiliser un champ de formulaire hidden ne permet ni de cacher une information ni d’empêcher sa modification.
3. Idem pour les cookies (voir #1).
4. Contrôler les données coté client avec du javascript ne m’empêchera pas de modifier leur valeur.
5. J’aime vous entendre dire « Cela n’arrivera jamais en production ».
6. Et j’adore quand vous dites « Un pirate ne ferait jamais ça ».
7. Je déteste les validations strictes cote serveur.
8. Cette page d’erreur avec le message détaillé me facilite tellement la vie.
9. La plupart des bannières « Sécurité Garantie ! » ne me servent qu’a voir que vous n’avez pas compris les bases de la sécurité.
10. Ce scanneur d’application web que vous avez lancé, il n’a rien trouvé. Il n’a même pas effleuré les failles de votre application.
11. Ce scanneur réseau que vous avez lancé, il n’a même pas commencé a tester la sécurité de votre application.
12. Je connais AJAX (et toutes les nouvelles technologies a la mode) mieux que vous et mieux que vous ne pouvez imaginer.
13. Le plus astucieux vous vous croyiez, le mieux je me sens.

Moralité, soyons humble et rigoureux, nous ne pourrons pas dire que nous ne savions pas, ces conseils sont répétés par la plupart des tutoriaux de frameworks web .

Le coin de la technique

Les roadmaps des implémentations de JPA 2.0

Alors que la JSR-317 (Java Persistence API 2.0) vient de diffuser une Proposed Final Draft 2 et que sa finalisation approche, nous souhaitions faire un tour d’horizon des principales implémentations en préparation. Comme c’est souvent le cas avec les JSRs, les développeurs n’attendent pas la finalisation des spécifications pour commencer à les implémenter. Ainsi, on se souvient que JPA 1.0, intégré à la JSR-220 (Enterprise JavaBeans 3.0) avait fait l’objet d’implémentations alpha chez JBoss dès la diffusion des early drafts, ce qui avait permis la stabilisation du conteneur peu après la finalisation de la JSR.

• Hibernate : l’équipe de développement Hibernate a annoncé fin aout la disponibilité d’une version 3.5 beta 1 qui implémentait la majorité des nouveautés de JPA 2.0. Aucune indication n’était alors donnée sur la date de finalisation, mais le bon avancement permet de supposer qu’elle arrivera rapidement. A noter toutefois que certaines optimisations importantes telles que la compilation des requêtes criteria n’arriveront que dans une version ultérieure.
• EclipseLink : la fondation Eclipse avait annoncé fièrement en début d’année 2008 qu’EclipseLink serait l’implémentation JPA 2.0 de référence. Une roadmap mise à jour en avril dernier fait état d’une version 2.0 d’EclipseLink implémentant JPA 2.0 pour l’automne 2009.
• Apache OpenJPA : le projet OpenJPA maintient une roadmap très rigoureuse tablant sur un démarrage de phase release candidate pour la fin de l’année. Il s’agira de la version 2.0 d’OpenJPA, elle est actuellement développée sur le trunk du projet.

La première version de la spécification JPA a été un succès puisque de nombreux développeurs ont reconnu sa légitimité et l’ont adopté dans leurs projets plutôt que de se reposer sur l’API propre à leur framework de persistance. Toutefois, pour certaines fonctionnalités telles que les requêtes criteria ou des options de mapping évoluées, il était jusqu’alors nécessaire de contourner JPA. Dès lors, on imagine aisément que JPA 2.0, comblant les manques de son ainée, bénéficiera d’une large adoption. La disponibilité des moteurs JPA 2.0 qui seront utilisés par JBoss AS, Glassfish et WebSphere autour de la fin de l’année devrait par ailleurs accélérer l’omniprésence de cette nouvelle API.

Web Beans est mort ! Longue vie a Weld !

Apres les bruits de couloir de la Scrum Alliance, nous continuons la rubrique people avec une fois encore Web Beans. Après le changement de nom de la JSR 299 en Java Contexts and Dependency Injection, voici que la Reference Implementation se rebaptise Weld.
Pendant ce temps, la JSR 330: Dependency Injection for Java continue son chemin avec son implémentation partielle dans Spring Framework 3.0 RC1 et son intégration dans Google Guice.

Actualité éditeurs / SSII

• Google lance son langage pour la JVM
• iBeans : la solution d’intégration pour applications Web de MuleSoft

Agilité

• Pair programming à distance sous Eclipse avec Saros

SOA

• L’initiative REST-* fait débat

Le coin de la technique

• OSGi 4.2
• Scala OSGi-fié
• Astuces de performance pour MySQL
• Enquête sur les temps de redémarrage des serveurs JEE
• Premiers pas avec memcached

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

• Soirée Tontons Flexeurs le 24 Septembre

Actualité éditeurs / SSII

Google lance son langage pour la JVM

Lors du JVM Language Summit de la semaine dernière, Google a présenté son nouveau langage pour la JVM appelé Noop. Le Wiki du projet et sa présentation permettent de faire le tour des spécificités de ce langage :

• Syntaxe prévue pour être facilement compréhensible par un développeur Java ou C++
• Pas de types primitifs, pas de classes ou méthodes statiques, variables non mutables par défaut, pas de syntaxe optionnelle, exceptions uniquement de type unchecked
• Librairie standard s’appuyant sur JodaTime, util.concurrent et Google Collections
• Support natif du concept d’injection de dépendances offert par Guice ou PicoContainer, un type est alors soit newable soit injectable
• Support natif des tests unitaires qui ont leur structure dédiée sans classes ni méthodes

Les réactions qui ont suivies cette annonce montrent en général un intérêt couplé à une réserve légitime due à l’état embryonnaire du projet. Ainsi l’analyse de Dominique de Vito s’inscrit dans ce schéma, tandis qu’Alexis Moussine-Pouchkine, Sun, explique à 01net qu’il trouve enrichissant la profusion de nouvelles idées mais que, selon lui, le langage Java restera malgré tout omniprésent pendant encore des années.

Reste que là où de nombreux nouveaux langages justifient leur existence par une syntaxe plus compacte, une nature dynamique ou encore des concepts élaborés, Noop semble adopter une approche plus pragmatique et plus proche des besoins quotidiens rencontrés en informatique de gestion. L’avenir nous dira si les apports de ce langage sont suffisants pour convaincre des équipes de le préférer à Java pour leurs développements.

iBeans : la solution d’intégration pour applications Web de MuleSoft

MuleSource, récemment renommé en MuleSoft lors du lancement de leur offre Tcat Server a récemment diffusé une première beta public d’un nouveau produit : Mule iBeans. Il s’agit d’une nouvelle solution d’intégration s’attaquant à un marché différent des ESB traditionnels. MuleSoft part en effet du constat que de nombreuses applications Web doivent s’intégrer avec diverses ressources distantes, mais ne peuvent s’appuyer sur un ESB qui constituerait une solution trop lourde. iBeans se positionne ainsi en tant que solution d’intégration pour applications Web. La nuance est légère par rapport aux ESB mais on constate clairement cette orientation dans la pratique : annotations, composants iBeans, injection de services type IoC avec un contexte request, …

La particularité principale du projet est son modèle de composant iBeans. Il s’agit de composants similaires aux Beans Spring ou aux Session Beans EJB mais spécialisés dans l’accès à un service à distance. Ces composants utilisent certaines annotations de la récente JSR-330 (Dependency injection for Java) et peuvent s’intégrer facilement avec Spring, Struts et JSF.

MuleSoft propose parallèlement un projet nommé Community iBeans Proposals visant à regrouper les iBeans de la communauté pour intégrer les ressources les plus fréquentes.

iBeans répond à un besoin courant des applications Web. La réponse proposée par MuleSoft est élégante mais on pourra regretter l’apparition d’un modèle de composant supplémentaire disposant de son propre cycle de vie. Actuellement l’éditeur n’a pas communiqué sur son projet naissant en dehors de la page Wiki dédiée. Une recherche Google montre rapidement que la communication autour de ce projet est quasi inexistante. Toutefois, une session dédiée au sujet prévue pour Devoxx 2009 tend à nous faire penser que la célèbre conférence européenne pourrait bien servir de rampe de lancement au nouveau projet de MuleSoft.

Agilité

Pair programming à distance sous Eclipse avec Saros

L’université de Berlin propose depuis quelques temps un plugin Eclipse nommé Saros, offrant des fonctionnalités permettant le pair programming à distance grâce au protocole XMPP. Concrètement les possibilités sont :

• Reproduction ou synchronisation d’un projet Eclipse à distance via une connexion XMPP.
• Visualisation dans l’environnement de l’observer des classes ouvertes et de la classe en cours d’édition par le driver.
• Affichage en temps réel des modifications du code, et de la position du curseur et du texte sélectionné.
• Gestion expérimentale d’un mode multi-driver permettant de modifier le code à deux simultanément.
• Chat via une vue dédiée dans Eclipse

Un screencast est proposé sur le site du projet, celui-ci permet de se rendre compte des capacités du plugin.

Idéalement complété d’une conversation Skype, ce plugin trouvera sa place dans de nombreux scenarii allant du distributed pair programming à l’assistance d’un collègue situé à un autre étage.

SOA

L’initiative REST-* fait débat

JBoss vient de lancer le site REST-*.org hébergeant son initiative de standardisation de plusieurs services middleware traditionnels sur le modèle REST.

Actuellement deux drafts sont en cours de rédaction, l’un porte sur RESTful Messaging, l’autre sur RESTful Transactions. Ces deux spécifications visent à définir un ensemble d’URIs standards sur le modèle REST permettant d’exposer une ressource transactionnelle ou un broker de messages.

Très rapidement, de vives réactions sont apparues au sein de la communauté, principalement pour faire part de leur scepticisme quant à cette initiative, régulièrement comparée à la très lourde collections de spécifications WS-*, qui pourrait mettre à mal la simplicité unanimement reconnue du modèle REST. C’est ainsi le cas d’Anne Thomas Manes qui revient également sur les critiques de Bill Burke à l’égart de l’initiative RestMS qui existait déjà et qui pariait plutôt sur Atom et AMQP.

Bill Burke de son coté publie sur son blog un billet par jour depuis la publication sur le site REST-*.org, pour justifier ses choix et la légitimité du projet qu’il porte. Ses arguments portent principalement sur le fait qu’il existe une demande très forte de la communauté pour gérer les services de messaging et les transactions avec REST.

Le débat est compréhensible : la volonté d’exposer certaines ressources transactionnelles ou services de messaging s’inscrit dans les besoins courants des entreprises, tout comme les craintes de voir se reproduire les erreurs du passé sont légitimes. L’apport de cette initiative est donc probablement de porter sur le devant de la scène une réflexion sur un problème pourtant courant et déjà exposé par Leonard Richardson et Sam Ruby, il y a deux ans, dans leur livre majeur RESTful Web Services.

Le coin de la technique

OSGi 4.2

OSGi est sur le devant de la scène, d’InfoQ à OSGi Thoughts en passant par The Programming Delusion (BJ Hargrave, CTO de l’OSGi Alliance), depuis une petite semaine et pour cause : l’OSGi Alliance a sorti et mis à disposition le 16 septembre dernier les spécifications finales de la version 4.2 (téléchargeables ici).

Alex Blewitt nous résume la situation sur InfoQ. On retiendra qu’Equinox et Félix ont déjà commencé leur travail de compatibilité avec OSGi 4.2. Les spécifications étant désormais released, ce n’est qu’une question de temps avant que les projets affichent fièrement leur label OSGi 4.2 compliant.
On notera aussi une nouvelle méthode de lancement du runtime OSGi, le nouveau nom des Distributed OSGi qui deviennent les Remote Services (connexion de VMs OSGi), les Blueprint Services qui seront des services wired à la Spring, le concept de Bundle Tracker ou bien encore le mécanisme de permission sur une opération dans un bundle.

Pour la petite piqure de rappel, on pourra se tourner vers JavaLobby qui nous propose depuis quelques jours 2 tutoriaux HelloWorld sur OSGi, le premier avec Swing et le second avec Spring RC.
Et pour les plus nostalgiques, le Paris JUG sur OSGi, c’était (déjà) il y a 1 an…

Scala OSGi-fié

On reste dans les news OSGi avec un projet qui propose Scala 2.7.6 en version OSGi-fiée (vu ici).

Comme expliqué sur le GitHub du projet, Scala n’est pas (encore) packagé en bundle OSGi. Certes, le plugin Eclipse Scala IDE utilise un bundle OSGi qui embarque Scala mais celui-ci ne peut pas être utilisé de manière générale (manifest spécifique et toutes les librairies dans un seul jar).

scala-lang-osgi répond à ce besoin et fournit un bundle OSGi pour chaque librairie Scala. Le tout est disponible sur le repository maven scala-tools.org.

Astuces de performance pour MySQL

Même si nos ORMs préférés génèrent des requêtes optimisées à notre place, il arrive parfois que, pour des raisons de performances ou autres, l’on doive écrire certaines requêtes directement en SQL.
Le site Debian Admin (par Code Purity) référence à cette fin 84 astuces d’optimisations de performances pour MySQL.
Certes, la plupart des astuces de configuration de MySQL sont peut-être/certainement déjà mises en place par nos chers DBA. Mais on trouvera aussi une pléiade d’astuces concernant la requête elle-même : cela passe de la non utilisation du gourmand SELECT *, d’éviter au possible l’utilisation de DISTINCT (très consommateur), d’utiliser pour l’insertion des BATCH INSERT et REPLACE ou bien encore l’utilisation INET_ATON et INET_NTOA au lieu de CHAR et VARCHAR pour les adresses IP.
Pour le détail complet, rendez-vous directement sur le site de Debian Admin.

Enquête sur les temps de redémarrage des serveurs JEE

ZeroTurnAround, l’éditeur de JRebel, a mené (et continue même à collecter des données) une étude sur les temps de redémarrage / redéploiement des serveurs d’applications auprès des lecteurs de son blog (environ 700 personnes ont répondu).
Tout d’abord, passons sur la conclusion évidente de l’étude, vous avez besoin de JRebel, pour tenter de voir au delà de cette évidence marketing. On évitera aussi la polémique sur le rapprochement Conteneurs de Servlets / Serveurs d’applications.
On constate tout d’abord que la population fréquentant le blog de ZeroTurnAround (on a donc dès le début une information en partie biaisée) a une forte tendance à confier ses applications à une plate-forme basée sur Tomcat (JBoss + Tomcat), plutôt qu’aux historiques IBM et BEA Oracle. Là encore, étant donné la notoriété naissante de JRebel, au sein d’une communauté plutôt tournée vers l’open source, rien d’étonnant.

En revanche, il est intéressant de constater que les temps de redéploiement deviennent assez rapidement délirants, avec des serveurs qui en moyenne mettent entre 2 et 5 minutes à redémarrer, la palme de la lenteur revenant, on le savait déjà par expérience, aux gros serveurs monolithiques commerciaux. Alors, au-delà du constat qu’un développeur passe aujourd’hui une grande partie de son temps à attendre que son application se mette à jour sur son serveur d’applications, au-delà du fait que JRebel est une des manières d’adresser ce problème, nous nous posons la question suivante : est-il normal, pour un serveur d’applications, de mettre cinq minutes à redémarrer ?

L’actualité de cette revue de presse met en avant OSGI, qui sera certainement une des réponses apportées à cette explosion des temps de démarrage. Ce sont d’ailleurs les absents de cette étude qui porteront la première estocade : GlassFish 3.x et dmServer.

Premiers pas avec memcached

Dans le but de proposer une implémentation d’un système de cache pour Grails, James Goodwill, sur DeveloperWorks, propose, dans un premier temps, une découverte du système de cache distribué memcached.
Une mise en bouche qui permet de découvrir les bases de ce produit, avant de combiner ce cache avec Grails dans une seconde partie, qui, on l’espère, permettra d’optimiser les performances du plus célèbre des frameworks haute productivité.

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

Soirée Tontons Flexeurs le 24 Septembre

Suite des Tontons Flexeurs, après la très bonne soirée Flex et Java en entreprise, avec une nouvelle session ce jeudi 24 septembre. 2 invités de marque : Mike Chambers et Lee Brimelow qui nous feront une présentation d’Adobe AIR (techniques avancées de synchronisation de données, de manipulation de fichiers, possibilités d’intégration à la plateforme hôte…) et des nouvelles fonctionnalités des prochaines versions de AIR.

A l’heure où nous écrivons ces lignes, il reste encore quelques places disponibles donc rendez-vous sur le formulaire d’inscription de l’évènement.

Dans ce second article, nous allons découvrir des outils d’injection plus évolués, qui devraient nous permettre de réaliser par la suite notre premier exemple ‘réel’ d’implémentation Guice.

Injection ‘nommée’

Reprenons l’exemple simple utilisé dans l’article précédent pour en augmenter la difficulté.
Nous partons du postulat que notre DAO ne possède plus une seule, mais deux implémentations distinctes : MyBasicDaoImpl, précédemment utilisée, et MyBasicDaoMock, une nouvelle implémentation utilisant une base volatile.
Nous allons utiliser ces deux implémentations successivement dans notre service, et donc injecter deux implémentations différentes de la même interface dans notre service :

@Override
public void displaySample() {
	try {
		recorder.append("Calling DAOn");
		String daoResult = basicDao.select();
		recorder.append("Result from DAO : " + daoResult + "n");
		recorder.append("Calling memory DAOn");
		daoResult = memoryDao.select();
		recorder.append("Result from memory DAO : " + daoResult + "n");
	} catch (IOException e) {
		e.printStackTrace();
	}
}

Premier point à noter, pour notre DAO existant rien ne change, Guice utilisera la première implémentation déclarée pour résoudre la dépendance.
Pour notre seconde dépendance, nous utiliserons l’injection nommée.
Première solution, créer une annotation, @Memory, en utilisant la BindingAnnotation de Guice :

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

Il suffit alors d’annoter le constructeur du service :

@Inject
public MyServiceImpl(MyBasicDao basicDao, @Memory MyBasicDao memoryDao) {
	super();
	this.basicDao = basicDao;
	this.memoryDao = memoryDao;
}

et d’annoter la déclaration de dépendance dans la classe Module

binder.bind(MyBasicDao.class).annotatedWith(Memory.class)
    .to(MyBasicDaoMemoryImpl.class);

Cette solution est relativement élégante, mais comporte le défaut de multiplier les classes d’annotation.
Le même résultat peut être atteint en utilisant une classe Guice permettant de nommer ses classes, mais sans créer d’annotation spécifique, à l’aide de l’annotation @Named et de la méthode Names.named(String)
Le code ci-dessus est équivalent à :

// Dans MyModule
binder.bind(MyBasicDao.class).annotatedWith(Names.named("Memory"))
    .to(MyBasicDaoMemoryImpl.class);
// Dans MyServiceImpl
@Inject
public MyServiceImpl(MyBasicDao basicDao, @Named("Memory") MyBasicDao memoryDao) {
    ...
}

Utiliser une dépendance conditionnelle à l’aide de l’annotation @Provides

Continuons à affiner notre injection de dépendance, en la conditionnant à des conditions runtime.
Imaginons que nous voulions injecter une implémentation de notre DAO en dépendant d’un paramètre runtime (nous nous baserons simplement sur un nombre aléatoire).
Pour cela, nous allons utiliser une méthode @Provides (à ne pas confondre avec les Providers de la version 1 de Guice).
Cette méthode doit être placée dans un module (où elle sera auto-découverte et retournera une instance de la classe injectée).

// Dans MyModule
/**
 * Provides method
 */
@Provides
@Inject
private @Named("Random")
MyBasicDao provideRandomDao(MyBasicDao basicDao,
		@Named("Memory") MyBasicDao memoryDao) {
	if (RandomUtils.randomBoolean()) {
		return basicDao;
	}
	return memoryDao;
}

On peut noter que cette méthode peut elle-même être injectée (avec les instances de Dao précédemment utilisées).

Conclusion

Nous avons maintenant une certaine souplesse dans l’injection, qui va nous permettre d’aborder dans un prochain billet un exemple plus concret.
À noter que durant la rédaction de ce billet, la version 2.0 de Google Guice a été officiellement releasée, et que les prochains billets se baseront sur cette version stable.

Téléchargez le projet Eclipse sur le Google Code de Xebia.

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.

SOA

• Fuji, le futur d’OpenESB

Le coin de la technique

• Concevoir des APIs efficaces
• JavaFX : informations et controverses
• Sortie de Wicket 1.3.6
• @Inject standardisation de l’injection de dépendances
• Sortie de Tapestry 5.1
• Trucs et astuces Json – Restfull

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

• Soirée Datagrid au Paris Jug

SOA

Fuji, le futur d’OpenESB

La prochaine version d’OpenESB, qui sera estampillée ‘v3′, est en cours de développement sous le nom de code ‘Project Fuji’. Ce projet a été récemment mis en avant par Andi Egloff, dans un webcast qui fait le tour des nombreuses nouveautés. Les principales d’entre elles sont :

• Integration Flow Language (IFL) : il s’agit d’un DSL externe permettant de définir des flux d’intégrations. Le rôle de ce langage est donc le même que le DSL interne offert par Apache Camel.
• Distributed JBI : La spécification JBI (JSR-208) ne couvre pas la problématique de distribution des composants JBI sur plusieurs noeuds. Fuji apporte une extension propriétaire pour permettre cette distribution.
• Utilisation de composants OpenJBI : ces composants seront utilisables directement dans OpenESB v3. Le projet prévoit de mettre les composants dont la compatibilité aura été validée dans le repository Maven du projet.
• Enterprise Integration Patterns : un certain nombre d’EIP sera supporté en standard et configurable via le langage IFL.

La version finale d’OpenESB v3 est prévue pour le second semestre 2009, l’équipe du projet annonce une probable preview pour JavaOne en juin.

Le coin de la technique

Concevoir des APIs efficaces

John De Goes vient de publier une série de deux articles (première partie et deuxième partie) portant sur les bonnes pratiques de conception d’APIs. Il s’appuie sur un exemple d’API de configuration pour illustrer son propos. Les points qu’il met particulièrement en avant sont :

• Il est important de sélectionner le niveau d’abstraction approprié et d’assurer l’uniformité de celui-ci sur l’ensemble de l’API, ainsi que de définir et respecter une responsabilité pour chaque classe. Ceci concerne la granularité des méthodes, le type d’objets manipulés en entrée et en sortie, ainsi que la présence et le type d’exception éventuellement renvoyée.
• N’offrir qu’une seule possibilité pour chaque besoin, afin d’éviter la confusion chez l’utilisateur de cette API.
• S’appuyer sur les possibilités offertes par le langage pour empêcher certaines mauvaises utilisations d’une API.
• L’API doit être la plus intuitive possible afin de minimiser autant que possible le besoin pour l’utilisateur d’avoir à se plonger dans une documentation.

Certaines de ces idées sont déjà partagées par de nombreux développeurs, mais comme c’est souvent le cas dans l’énonciation de bonnes pratiques ou de patterns, tout l’intérêt réside ici dans la formalisation apportée par l’auteur.

Les lecteurs intéressés par cette problématique pourront se tourner vers le livre de Jaroslav Tulach, Practical API Design, qui apporte l’intéressant retour d’expérience d’un architecte de NetBeans, ou encore How to Design a Good API and Why it Matters par Joshua Bloch (auteur de Effective Java).

JavaFX : informations et controverses

Depuis plusieurs mois, nous vous rapportons les différentes informations et controverses à propos de JavaFX. Cette technologie RIA, développée par Sun, et introduite en décembre 2008 fait beaucoup parler d’elle car personne ne sait dire aujourd’hui ce qu’il adviendra de JavaFX dans les mois et années à venir.

Les propos particulièrement négatifs dont JavaFX a été victime à ses débuts se font moins nombreux, non pas parce que cette technologie a convaincu, mais parce qu’elle n’est plus au centre des débats. En fait, ceci est bénéfique puisque cela permet d’observer plus sereinement les différents exemples postés régulièrement par la communauté JavaFX naissante. Il ressort de ce tour d’horizon que les capacités actuelles de JavaFX ne prêtent pas à critique : les fonctionnalités de graphisme et d’animations qui sont offertes semblent satisfaire de nombreux développeurs. Le problème porte principalement sur les manques et les promesses non tenues à ce jour :

• la portabilité de JavaFX sur plusieurs environnements (_desktop_, web, mobile, et TV, le fameux ‘All the screens of your life‘) n’est pas assuré puisque le déploiement est impossible sur mobile, faute de device compatible. Le fonctionnement sur téléviseur est lui toujours prévu dans une version ultérieure.
• les composants graphiques de haut niveau sont absents. Il s’agit pourtant d’un élément indispensable pour le développement d’applications RIA.

Joshua Marinacci, un des meneurs de JavaFX chez Sun, a été interviewé par Scott Hanselman dans un podcast. Il annonce que la démonstration de JavaFX sur TV pourrait être faite lors de JavaOne 2009, en juin. Il reconnaît par ailleurs le marketing excessif entourant cette technologie.

Outre ces réflexions d’ordre technique, le rachat de Sun par Oracle constitue une autre source de débats. Personne ne sait quelle décision Oracle prendra quant à JavaFX : soutenir ce projet qui nécessite encore un investissement lourd pour prétendre réellement concurrencer les autres acteurs RIA ou abandonner ce marché. Les différentes opinions sur ce sujet sont présentées et argumentées dans le dernier podcast des Cast Codeurs.

Sortie de Wicket 1.3.6

Wicket, le framework orienté composant de la Fondation Apache, sort en version 1.3.6 (1.4 toujours en release candidate 2).

Malgré les 7 mois d’écart avec la version précédente, il ne faut pas s’attendre à une révolution pour cette nouvelle mouture. Il s’agit en effet d’une version de stabilisation et d’amélioration. On notera donc de nombreux correctifs de bugs et plusieurs améliorations.

Cette version est téléchargeable sur le site d’Apache ou en changeant votre version de pom.xml en 1.3.6.

A noter, toujours autour de Wicket, le retour critique de Tom’s Quest sur Wicket et ses limites après la présentation, chez Zenika, de Martin Dashorst, un des committers principaux de Wicket et coauteur du livre Wicket In Action.

@Inject standardisation de l’injection de dépendances

Pas mal de bruit la semaine dernière dans la blogosphère Java avec l’annonce par Google et SpringSource d’une nouvelle proposition de JSR dédiée à l’injection de dépendances : @Inject (« Annotations for Dependency Injection »).
Comme le souligne ‘Crazy’ Bob Lee, l’auteur principal de Google Guice, la sortie de Spring 1.0, il y a déjà 5 ans, a apporté l’injection de dépendances aux masses, via un fichier de configuration propriétaire. Il y a 3 ans, Google Guice a proposé la même chose via des annotations (et SpringSource propose la même chose depuis Spring 2.5).
Si le succès de Google Guice est assez limité face au raz de marée Spring, le constat est là : il manque un standard. Comme les deux librairies ne sont pas compatibles, si vous exposez à un autre projet/équipe une librairie contenant des dépendances injectées par Google Guice, et que l’autre équipe utilise Spring, elle devra redéfinir tous les beans et leurs dépendances dans un fichier de configuration Spring (ou des annotations Spring).
@Inject propose donc de standardiser les annotations, afin de rendre portables sur différents frameworks (Guice, Spring, Tapestry IOC, etc.) des classes injectables.

Lire notre article à ce sujet : @Inject standardisation de l’injection de dépendances.

Sortie de Tapestry 5.1

Tapestry, dont on parlait récemment dans l’article l’injection de dépendances avec Tapestry IoC, passe en version 5.1 en respectant à la lettre son nouveau planning d’une version tout les 4 à 6 mois.
Outre les améliorations de performance et les nombreux bugs corrigés, la mise à jour embarque des nouveautés sur le support JavaScript, à la traîne par rapport au prédécesseur Tapestry 4.
Le rafraîchissement de plusieurs zones d’une page en une seule requête Ajax est maintenant supporté. Tapestry embarque maintenant la console JavaScript Blackbird.
Du côté des améliorations sur les templates, le chargement et le rendu des pages ont été optimisés, ce qui rend T5 plus rapide que jamais.
Vous pourrez aussi apprécier l’amélioration substantielle de l’archetype quickstart qui offre désormais une jolie interface, avec un design css intégré.
L’intégration de Spring est maintenant à double sens : on peut injecter des services Tapestry dans un Bean Spring.
Pour la prochaine version, qui sortira sans doute à la rentrée 2009, l’accent sera mis sur l’intégration de Spring Web Flow, et la possibilité d’utiliser une application Tapestry en tant que Portlet.

• Release note
• Site Maven du projet

Trucs et astuces Json – Restfull

Edwin Khodabakchian, fondateur de Collaxa (aujourd’hui au coeur de la stratégie SOA d’Oracle), nous donne quelques bonnes pratiques pour écrire des services web REST en utilisant Json (un couple qui a le vent en poupe). Actuellement lancé dans l’écriture de Feedly, une extension Firefox qui agrège des tweets et des entrés Google Reader, Edwin fera régulièrement profiter ses lecteurs de son expérience. Sans entrer dans les détails de ces bonnes pratiques, nous retiendrons l’astucieux découpage en 7 phases d’implémentation :

• Definir un service ou une ressource simple : définir le modèle Json et les 4 opérations REST et le servlet qui les fournit.
• Ecrire un client : utiliser le service avec un javascript simple. Cette possibilité est offerte par de nombreux frameworks, dont JQuery.
• Ajouter une étape de validation : modifier le service pour valider les ressources Json et utiliser les codes retour HTTP.
• Complexifier les ressources : modifier la hiérarchie d’Url pour servir des ressources plus riches. Tester la pérennité des ressources simples (phase 2).
• Ajouter un cache : améliorer les performances et la scalabilité de votre système.
• Implémenter la sécurité : utiliser une authentification web.
• Publier des événements business : pour découpler les processus REST des processus back-end. Les ressources REST sont traitées, un évènement business est lancé, qui déclenche le ou les traitements back-end.
• Gérer un cycle de vie pour les ressources : coupler un état de la ressource avec la phase de validation et la phase de publication des évènements.

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

Soirée Datagrid au Paris Jug

Le DataGrid au Paris Jug, c’est demain.
Pensez à réserver si ce n’est déjà fait.

Si le succès de Google Guice est assez limité face au raz de marée Spring, le constat est là : il manque un standard. Comme les deux librairies ne sont pas compatibles, si vous exposez à un autre projet/équipe une librairie contenant des dépendances injectées par Google Guice, et que l’autre équipe utilise Spring, elle devra redéfinir tous les beans et leurs dépendances dans un fichier de configuration Spring (ou des annotations Spring).

@Inject propose donc de standardiser les annotations, afin de rendre portables sur différents frameworks (Guice, Spring, Tapestry IOC, etc.) des classes injectables.

Pourquoi autant de bruit ?

Une autre JSR qui parle d’injection de dépendances a déjà passé le stade de la proposition, la JSR 299, ex-Web Beans, portée en particulier par Gavin King de Red Hat, auteur d’Hibernate. La JSR 299 va beaucoup plus loin (trop?) que l’injection de dépendances, sujet abordé dans de précédentes revues de presse.

La JSR 299 a déjà beaucoup fait parler d’elle, car elle a récemment été remaniée, afin d’être intégrée à temps à Java EE 6 (dont la spécification doit être terminée dans 3 mois). Vous pouvez lire les commentaires sur notre revue de presse du 26 Janvier dernier, dans laquelle nous nous étonnions de l’absence de SpringSource dans la JSR 299.

Quelques extraits de ces commentaires :

Emmanuel Bernard (JBoss) : « …SpringSource n’a jamais demandé à faire partie du groupe d’expertise… »
Emmanuel Bernard : « …JBoss a passé un temps énorme à construire JSR 299… »
Antonio Goncalves (Java EE 6 Expert Group) : « …la JSR 299 ne se transforme pas radicalement, je dirais plutôt qu’elle réduit sa voilure et se concentre sur son but initial : un contexte unifié entre les EJBs et JSF… »
Cyrille Le Clerc (Xebia) : « …une JSR qui se transforme radicalement, au point de changer de nom, pendant la phase de Public Review, après deux années et demie de travail intensif, cela me parait exceptionnel et peu rassurant… »

Bonne idée, mauvais timing ?

C’est dans ce contexte que Google et SpringSource décident de proposer @Inject. L’intention est légitime, et les deux acteurs sont sans aucun doute les plus expérimentés sur le sujet de l’injection de dépendances. Il semble en effet beaucoup plus aisé pour Guice, Spring ou autre framework d’implémenter une JSR de la taille de l’éventuelle JSR @Inject, alors qu’on les voit mal implémenter rapidement la JSR 299. Google et SpringSource suggèrent donc à la JSR 299 de ne plus spécifier l’injection de dépendances, et de réutiliser les annotations définies dans @Inject (extrait de la proposition : « JSR 299 is defining a dependency injection framework for Java EE, and might support these annotations.« ).

En revanche le timing nous semble vraiment mal choisi : cette spécification est proposée à quatre mois de la validation de Java EE 6 (Septembre 2009). Cela semblait déjà compliqué pour la JSR 299 (dont l’inclusion à Java EE 6 n’a toujours pas été votée), et @Inject ajoute très tard son grain de sel.
Même si Bob Lee pense pouvoir faire valider @Inject par le JCP en cinq mois, ou moins dans le cadre de Java EE 6, il est peu probable qu’@Inject fasse partie de Java EE 6 ; on n’a jamais vu de JSR consensuelle validée aussi rapidement, comment ferait une JSR polémique ? La JSR 299 fait quant à elle face à un planning de plus en plus serré. Le résultat des courses est sans appel : on « risque » donc de voir arriver une spécification Java EE 6 sans JSR d’injection de dépendances.

Hormis Gavin King (JSR 299 – JBoss) et Bob Lee (@Inject – Google) qui ont âprement débattu sur la blogosphère, les membres des expert groups de JSR 299 et Java EE 6 sont restés silencieux … comme Rod Johnson, co-inspirateur de @Inject (qui était sans doute bien occupé la semaine dernière).

Enfin, je vous suggère de prendre quelques minutes pour lire le « brouillon » de proposition de JSR @Inject. On y voit de nombreux noms connus et reconnus parmi les supporters de cette JSR (Joshua Bloch, Paul Hammant – ThoughtWorks & PicoContainer founder, Doug Lea, Tim Peierls, James Strachan, Hani Suleiman, Jason van Zyl – Maven Plexus, Thiago H de Paula Figueiredo – Tapestry IoC). @Inject ne propose que de standardiser les annotations, et ne décrit pas la manière dont les dépendances vont être résolues, ce sera à la charge du conteneur. Le périmètre fonctionnel de la proposition est donc très focalisé.

Sous vos yeux ébahis, une injection de dépendance sans Spring, sans Guice et sans JSR

Pour rappel, même si aucune JSR d’injection de dépendances n’est intégrée dans le futur à Java EE 6, vous avez le droit d’injecter vos dépendances vous même, sans Spring, sans Guice, par exemple avec un simple constructeur Java !

public class MyService {
	private MyDAO myDAO;
	public MyService(MyDAO myDAO) {
		this.myDAO = myDAO;
	}
}

Ce qui vous permettra d’y injecter bouchons ou mocks depuis vos tests unitaires.

Quelques liens sur le sujet

• l’annonce sur le blog de Bob Lee
• la réaction de Gavin King et les échanges avec Bob Lee dans les commentaires
• le projet @Inject sur Google Code
• Proposition de la JSR @Inject
• quelques (rares) commentaires intéressants sur TSS
• @Inject sur twitter

Nous entamons aujourd’hui une série d’articles qui a pour but de vous faire toucher du doigt la grande liberté qu’offre l’injection de dépendance par code. Nous irons progressivement des concepts de base de Guice 2.0, vers une utilisation avancée du framework.

Déclarer une dépendance avec l’annotation @Inject.

Prenons le postulat de départ suivant : la classe MyServiceImpl (qui implémente l’interface MyService) doit recevoir l’injection de la classe MyBasicDaoImpl (qui implémente l’interface MyBasicDao).
Dans le code source de la classe à injecter, nous allons donc indiquer que Guice doit s’occuper de cette injection, en utilisant l’annotation com.google.inject.Inject. Dans ce premier exemple, nous positionnerons cette annotation au niveau du constructeur.

En outre, nous déclarons un Appendable qui nous permettra de réaliser des traces. Cet appendable sera injecté directement dans la variable.

public class MyServiceImpl implements MyService {
	@Inject
	private Appendable recorder;
        private final MyBasicDao basicDao;
	@Inject
	public MyServiceImpl(MyBasicDao basicDao) {
		super();
		this.basicDao = basicDao;
	}
}

Vous remarquerez que grâce à l’injection par constructeur, nous sommes en mesure de déclarer la variable basicDao finale.

L’injection peut être réalisée au niveau du constructeur, d’une méthode voire même de la variable elle-même. Quelques avantages / inconvénients de ces différentes méthodes :

• Constructeur
• + Les variables peuvent être déclarées finales
• - Ne peut être utilisé si l’objet est instancié hors de Guice
• Méthode
• + Permet d’injecter un objet instancié hors de Guice
• + Les classes filles n’ont pas besoin de connaître les dépendances des classes mères.
• Variable
• + Syntaxe la plus compacte
• - Réduit la testabilité et l’encapsulation

La méthode recommandée par Google est l’injection par constructeur.

Lier une interface à son implémentation réelle, dans un Module

Il nous faut maintenant lier l’interface MyBasicDao à l’implémentation que nous souhaitons utiliser dans un premier temps, à savoir MyBasicDaoImpl.
Ceci se fait dans un module de configuration étendant com.google.inject.Module à l’aide d’un DSL relativement explicite.

public class MyModule implements com.google.inject.Module {
	@Override
	public void configure(com.google.inject.Binder binder) {
		// Bind to class
		binder.bind(MyBasicDao.class).to(MyBasicDaoImpl.class);
		binder.bind(MyService.class).to(MyServiceImpl.class);
		// Bind to instance
		binder.bind(Appendable.class).toInstance(System.out);
	}
}

Le Module permet de lier des interfaces à des classes que Guice se chargera d’instancier (_bind … to_) mais aussi à des classes déjà instanciées (_bind … toInstance_) comme c’est le cas pour notre Appendable, qui sera lié à la console System.out.

Récupérer une instance auprès de l’Injector

Dernière étape, il nous faut obtenir une instance injectée de notre service.
C’est auprès de la classe com.google.inject.Injector que nous la récupérerons. Cet injecteur est créé de manière statique, à partir d’un ou plusieurs Module.
Dans cet exemple, nous réaliserons cette opération à partir d’un main.

public class MyMain {
	public static void main(String[] args) throws IOException {
		Injector injector = Guice.createInjector(new MyModule());
		MyService myService = injector.getInstance(MyService.class);
		myService.displaySample();
	}
}

Et Spring dans tout ca ?

La question qui se pose dès que l’on aborde l’injection de dépendances est bien sûr ‘Oui, mais par rapport à Spring ?’.
Essayons d’éviter la réponse de normand, même si Spring et Guice ne jouent pas dans la même cour : Guice se concentre exclusivement sur l’injection de dépendances, alors que Spring vise à offrir une stack complète.
L’équipe de Guice répond d’ailleurs elle-même à la question sur son wiki.
Cependant, pour donner un point de vue plus pragmatique :

• le footprint du Jar du Guice est bien inférieur à celui (ceux) de Spring Core.
• le chaînage des Beans est plus rapide avec Guice, même si cet argument pèse peu, la majorité des dépendances étant chargées à l’initialisation de l’application.
• Guice est plus intrusif (apparition d’annotations dans le code source des services métier)
• la programmation orientée aspect de Guice est au stade embryonnaire.

Dans la suite de cette série d’articles, nous essayerons de montrer que la différence d’approche entre Guice et Spring offre plus de libertés aux développeurs (mais conduit peut-être aussi à plus de chaos).

La suite ?

C’est déjà la fin de ce premier tutoriel, et vous savez maintenant injecter simplement une classe. Cependant, dans le projet tel qu’écrit aujourd’hui, la classe MyBasicDaoImpl sera injectée dans toutes les classes nécessitant un MyBasicDao. Dans un prochain article, nous verrons comment lever cette limite.

Téléchargez le projet Eclipse sur le Google Code de Xebia

Ressources

Site officiel
Un comparatif de performances Spring / Guice, basé sur les versions précédentes

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 !

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

Agilité

• Les bases de Scrum, en 10 minutes, avec le sourire.

RIA

• Native Client de Google et Alchemy d’Adobe
• Spring BlazeDS Integration 1.0.0.M1
• Choisir sa solution RIA

Le coin de la technique

• OpenXava 3.1 est disponible
• Java Persistence API 2.0 Public Draft

Agilité

Les bases de Scrum, en 10 minutes, avec le sourire.

En 2009, je vais tenter de comprendre ce que Xebia raconte dans la partie Agilité de sa revue de presse. Si vous faites cette bonne résolution, alors la vidéo suivante est pour vous ! Hamid Shojaee (Axosoft) résume en 8 minutes les principaux concepts de Scrum.

Cliquer ici pour voir la vidéo.

RIA

Native Client de Google et Alchemy d’Adobe

Google annonce la sortie de Native Client, une technologie permettant d’exécuter du code natif directement dans le navigateur. Le but de Native Client est d’exploiter le processeur et la carte graphique du poste client pour pouvoir mettre en place des applications web plus performantes. Google rassure en disant que cette exploitation ne remettra en cause ni la neutralité du navigateur, ni la sécurité, ni la portabilité des applications sur les différents systèmes d’exploitation.

Il est possible de tester une version expérimentale de Native Client. À noter pour le moment que cette version n’est compatible qu’avec les navigateurs suivants : Firefox, Safari, Opera et Google Chrome; et sur les systèmes d’exploitations suivants : Windows, Mac et Linux qui ont un processeur x86.

Coïncidence ou pas, Adobe a présenté, lors de ses journées Adobe MAX, Alchemy qui offre les mêmes fonctionnalités que Native Client.

Alchemy est un projet d’Adobe Labs permettant d’intégrer du code C ou C++ dans une machine virtuelle ActionScript. Le code C/C++ est d’abord compilé en ActionScript3 dans un swc ou swf. Il peut ensuite fonctionner sur Flash Player 10 ou AIR 1.5, sécurisé par les protections Flash Player.

Quoi qu’il en soit, le but de ces technologies reste le même : faire en sorte que les applications web deviennent plus puissantes. Cela ne devrait donc pas concerner l’informatique de gestion. Mais pour les applications qui demandent beaucoup de ressources, telles que les jeux en ligne par exemple, cela pourrait changer la donne.

Une question reste cependant en suspend. Pourquoi Google a t’il décidé de sortir cette technologie ? Java Applets, ActiveX, Flash, Flex, Air, Silverlight, JavaFX, ce ne sont pas les technologies concurrentes qui manquent. Native Client ressemble d’ailleurs plus à une nouvelle version d’ActiveX cross-browser qu’à une nouvelle technologie RIA au sens Flex ou SilverLight. Certains pensent que cette technologie est le fruit d’un travail indépendant ne répondant à aucune vision technique cohérente à long terme. D’autres, au contraire, pensent qu’il s’agit d’un pas de plus vers un système d’exploitation made in Google. Le débat est ouvert, difficile de s’avancer pour le moment … Une fois de plus, Google est arrivé à faire le buzz autour de ses technologies.

Pour ceux qui voudraient tester Quake made in Native Client, voici le lien

Spring BlazeDS Integration 1.0.0.M1

Nous en parlions la semaine dernière, c’est maintenant officiel, le premier milestone de Spring BlaseDS Integration est maintenant disponible.
Alors à quoi ressemble cette intégration ? Elle vous permettra de mixer les configurations BlaseDS et Spring à votre guise. L’idée est de laisser les configurations statiques d’infrastructure dans le fichier de configuration BlaseDS et d’externaliser le reste dans les fichiers de configuration Spring. Cette solution devrait donc plaire à tout le monde : les utilisateurs de BlaseDS ne devraient pas être perdus, le mécanisme général restant inchangé ; les utilisateurs Spring s’y retrouveront également avec une configuration standard Spring MVC et Spring Remoting.

Voici quelques détails de cette configuration :

• Seule la configuration de la DispatcherServlet de Spring MVC est nécessaire
• L’exposition du MessageBroker de BlazeDS passe par :
  • la déclaration d’un FactoryBean dans le fichier de configuration XML de Spring MVC : MessageBrokerFactoryBean
  • le routage des requêtes de la DispatcherServlet vers le MessageBroker via la configuration d’un HandlerMapping
• À la manière de Spring Remoting, il ne vous reste plus qu’à exposer vos services Spring au MessageBroker avec la configuration d’un nouveau type d’Exporter : le FlexRemotingServiceExporter

Même si nous n’avons pas encore testé cette solution, cette intégration aussi simple qu’élégante rapproche sans conteste les développeurs Java au développement d’applications Flex.

Choisir sa solution RIA

Les solutions RIA sont de plus en plus nombreuses et il devient difficile de trancher catégoriquement pour l’une ou l’autre lors du démarrage d’un projet. Très souvent, une librairie est choisie par sa côte de popularité alors qu’elle ne correspond pas forcément au besoin client.
Au final, l’énergie dépensée pour apprendre, utiliser et adapter ces widgets/actions/effets dans le projet se révèle très coûteuse en temps, en maintenance…

Robbie Cheng (développeur principal de ZK Mobile pour Android) éclaircit nos esprits avec l’article How to Choose an RIA Solution sur Sys-Con avec un Top 10 des critères architecte et manager à prendre en compte lors du choix de sa solution.

Sans surprise, côté architecte, on se retrouve avec :

• de nombreux widgets, simples, des fonctionnalités comme le lazy loading ou le drag & drop, des pop-up…,
• facilité de développement,
• parfaite intégration dans l’entreprise,
• sécurité et scalabilité,
• et bien évidemment multiplateforme.

Côté manager, les besoins ne sont pas les mêmes :

• solution standard ? utilisée par d’autres projets ? Open Source ?,
• bien évidemment le coût de formation, entre une solution JavaScript et Java il n’y a pas qu’un pas ,
• outils associés à la solution (plugins, éditeur, WYSIWYG…),
• dépendante d’autres librairies / d’autres plugins ?,
• un background solide i.e. qui est derrière la solution ! Adobe, Google, un développeur dans son garage ? Mais aussi un support de qualité, des corrections de bugs et des mises à jour régulières.

Selon tous ces aspects, l’auteur nous donne 4 catégories de solutions RIA / frameworks :

• Snippet : amélioration légère avec quelques effets, des pages plus rapides à l’affichage, des nouvelles petites fonctions de ci de là… avec peu de changement au niveau de l’architecture ou du design. Script.aculo.us et Prototype sont de bons exemples,
• Widget : vous avez dit Web 2.0 ? C’est clairement ce que tout le monde a vu avec l’arrivée de librairies comme YUI ou ExtJS : une nouvelle expérience utilisateur au niveau de l’interface graphique avec des composants travaillés, très beaux, du drag & drop, de l’animation… ces frameworks s’appuient donc sur une libraire de widgets solides,
• Client : réécriture de l’application côté client dans une nouvelle technologie, nouvelle interface utilisateur, amélioration de la productivité mais un gros travail de refonte côté client. Nous parlons bien sûr des GWT, Flex et Cie,
• Full : la solution complète, riche, MVC, patterns de développement, à la fois une nouvelle expérience utilisateur mais aussi une réelle valeur ajoutée pour l’entreprise… mais nécessite des plateformes/technologies spécifiques côté client et serveur. On citera les ZK ou Wicket.

La conclusion sans surprise à la question (alors, laquelle ???) est bien sûr : ça dépend…
En effet :

• tous les projets n’ont pas la même cible d’utilisateur,
• et les technologies passent du Java au XML en passant par du JavaScript, autrement dit les compétences ne sont clairement pas les mêmes d’un framework à un autre.

Alors entre jQuery, ExtJS, GWT et Flex, ce sera à vous et vous seul de choisir !

Le coin de la technique

OpenXava 3.1 est disponible

OpenXava est un ensemble d’outils et de composants destinés à simplifier le développement d’applications Web Java.

OpenXava permet de générer des formulaires CRUD à partir des POJOs et des annotations JPA. Il vous propose également d’intégrer des fonctionnalités avancées : la génération des rapports PDF, exports Excel, formulaire de recherche, tri, impression… Avec OX, vous pouvez aussi créer des applications sophistiquées avec une logique complexe et des IHM avancées.

La nouvelle version 3.1 apporte AJAX dans vos applications générées. Pour ceux qui utilisent déjà OX le passage à la version 3.1 permet « d’ajaxifier » vos applications sans toucher une seule ligne de code.

Le projet est fourni sous licence LGPL.

Plusieurs démos sont disponibles.

Java Persistence API 2.0 Public Draft

La spécification JSR 317: JavaTM Persistence 2.0 est un public draft, comme l’annonce sur son blog la specification lead, Linda Demichiel (Sun Microsystems) : Java Persistence 2.0 Public Draft.

Une entrée précédente de la revue de de presse de Xebia : JPA 2.0, la nouvelle version d’une API bien portante, annonçait l’ajout de l’API Criteria à la version 2 de JPA.

Linda Demichiel décrit sur son blog le fonctionnement possible de cette API Criteria : Java Persistence 2.0 Public Draft: Criteria API.

Celle ci permet de construire des requêtes SQL en Java de manière programmatique. Cette technique présente les intérêts suivant :

• Les requêtes dynamiques sont plus faciles à construire et leurs constructions peuvent dépendre de données évaluées à l’exécution
• Les fonctions des IDE permettent d’assister le développeur comme par exemple le refactoring, la complétion

Cependant les requêtes sont plus difficiles

• A optimiser
• A maintenir (plus difficile à lire)

Ces requêtes sont construites à partir d’un object QueryDefinition obtenu à partir d’un EntityManager :

EntityManager em = ... ;
QueryBuilder queryBuilder = em.getQueryBuilder();

Exemple de création de requête sur l’entité Customer :

DomainObject customer = queryBuilder.createQueryDefinition(Customer.class);

En manipulant l’objet JPA DomainObject, on peut charger, par jointure, la relation customer->orders->items:

DomainObject item = customer.join("orders").join("items");

Voici un exemple complet :

DomainObject customer = queryBuilder.createQueryDefinition(Customer.class);
DomainObject item = customer.join("orders").join("items");
customer.where(item.get("productType").equal("printer"))
.select(customer.get("name"));

Comme le fait remarquer Gavin King dans l’article A typesafe criteria query API for JPA, il est dommage de manipuler des chaînes de caractères afin d’obtenir un attribut d’une classe. On perd un des intérêts de l’API Criteria : le refactoring et la complétion fournis par les IDE.

Ainsi, en reprenant l’exemple complet, si l’on renomme l’attribut name de la classe customer en firstName (avec notre IDE préféré), notre IDE sera incapable de changer le requête précédente de customer.get(« name ») à customer.get(« firstName »).

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