Revue de Presse Xebia

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

Actualité éditeurs / SSII

• Amazon RDS, support de MySQL 5.5 et support d’Oracle 11gR2 (à venir)
• Sonatype supporte Hudson plutôt que Jenkins
• Netbeans – Arrêt du support de Ruby on Rails

RIA

• Sortie de jQuery 1.5.0
• Sortie de jQuery Mobile 1.0 alpha 3

NoSQL

• Cas d’utilisation et pièges de NoSQL

Le coin de la technique

• Nouvelles règles et gouvernance du projet OpenJDK
• Important risque de Déni de Service

Actualité éditeurs / SSII

Amazon RDS, support de MySQL 5.5 et support d’Oracle 11gR2 (à venir)

Pour rappel, Amazon Relational Database Service (RDS) est un service permettant d’héberger une base de données relationnelle dans un environnement cloud.

Amazon RDS s’est vu doté, la semaine passée, du support de la version 5.5 de MySQL. Cette version inclut le moteur InnoDB en version 1.1 et améliore entre autre, la prise en charge des processeurs multi-cores, la gestion des E/S, ainsi que le monitoring. Une liste plus détaillée des changements de la version est consultable ici. Enfin pour les utilisateurs d’instance en version 5.1, sachez qu’à l’heure actuelle la mise à jour vers MySQL 5.5 nécessite d’effectuer un export/import manuellement. Cependant, Amazon espère pouvoir fournir une procédure automatisée.

Toujours concernant Amazon RDS, Amazon annonce le support d’Oracle Database 11g R2 pour le 2ème trimestre de cette année. Si l’annonce ne donne pas davantage d’éléments techniques, elle décrit les modes de facturation associés. Le coût horaire du service sera fonction du type d’instance choisie et de l’édition Oracle choisie (Standard, Standard One, Entreprise). Mais Amazon permettra également aux détenteurs de licences de les transférer vers le service cloud, les tarifs étant alors moins élevés.

Profitons de cette nouvelle pour apporter un complément d’information (merci à Arnaud Rolly d’avoir signalé cet oubli) sur le service Amazon Elastic Beanstalk traité dans la revue de presse du 25 janvier. Nous avions donc oublié d’évoquer les systèmes de stockage accessibles depuis Beanstalk. Il est ainsi possible d’associer simplement votre application Beanstalk à un stockage Amazon Simpe DB ou Amazon RDS. L’interface d’administration permet de saisir l’url JDBC à utiliser, la valeur est accessible comme paramètre d’environnement. Actuellement, Amazon RDS ne supporte que le SGBD MySQL, mais on rappellera ceci:

With Elastic Beanstalk, developers … can perform a variety of functions, including:

• Choosing from several available database and storage options such as Amazon RDS, Amazon SimpleDB, Microsoft SQL Server, or Oracle.

Le support de Microsoft SQL Server ne devrait donc pas trop tarder ;-) .

Sonatype supporte Hudson plutôt que Jenkins

Nous vous parlions récemment, du fork de Hudson en Jenkins. Son créateur semblait entraîner avec lui la plus grande partie de la communauté et le sort de Hudson, dont Oracle conservait la propriété, nous paraissait scellé. C’était sans compter sur Sonatype ! L’entreprise principale derrière Maven semble en effet vouloir reprendre un flambeau qui paraissait devoir s’éteindre. Et ceci un peu à la surprise générale. En effet, sur le blog de Sonatype, Jason Van Zyl a annoncé la mise a disposition, conjointement avec Oracle, de personnes à temps plein sur le projet. Il a critiqué:

• L’état du projet, notamment les librairies utilisées (Jelly)
• Le fait que certaines soient forkées sans trop d’explications
• Le manque d’infrastructure et de tests
• Les problèmes de propriété intellectuelle se cachant derrière les diverses licences des librairies utilisées

Mais il en a profité pour énoncé une imposante liste de tâches actuellement dans le backlog.
C’est une nouvelle d’importance. Même si Sonatype semble profiter de la situation confuse, ce qui n’est pas forcément bien vu, ils se positionnent de plus en plus en tant qu’incontournable dans le domaine du build Java. Reste que pour les utilisateurs, on ne sait plus d’Hudson et de Jenkins lequel est le fork de l’autre et surtout lequel est le plus susceptible de tenir sur la longueur…

Netbeans – Arrêt du support de Ruby on Rails

Le 27 janvier dernier, les membres du projet Netbeans ont annoncé leur intention d’arrêter le support de Ruby on Rails avec la version 7 de l’IDE.

Netbeans est un IDE fourni par Sun Microsystems et écrit entièrement en Java. S’il a connu une période difficile face à son principal concurrent (Eclipse). Il a depuis la version 6.5 rattrapé son retard sur certains points : en devenant accessible comme une plateforme par exemple. Mais s’il s’est également diversifié comme son concurrent en offrant le support des langages : C/C++, PHP, Ruby et (feu) JavaFX.

Cette décision s’explique par la volonté d’Oracle, de faire de l’IDE Netbeans l’OUTIL de référence pour la plateforme Java. Plus concrètement, cette version de l’IDE doit accompagner la sortie de Java 7 prévue pour cette année. L’ensemble des ressources de développement est donc recentré sur le support de Java.

L’autre raison invoquée est qu’en dépit du relatif succès de cette feature, la base des utilisateurs est trop restreinte pour justifier l’investissement en ressources humaines sur le projet. Sur la page du support Ruby, les développeurs Netbeans exhortent donc les utilisateurs et développeurs Ruby à poursuivre le développement de ce support. Espérons que leur appel soit entendu.

Une telle décision peut surprendre aujourd’hui. Pour rappel, Sun avait beaucoup investi sur le langage Ruby en embauchant Charles Nutter et Thomas Enebo (alors parmi les lead développeurs de JRuby). De manière très cohérente, Oracle réaffirme ici la place stratégique qu’il entend donner à la plateforme Java; mais les développeurs Ruby ont toutes les raisons de grincer des dents.

RIA

Sortie de jQuery 1.5.0

Ces derniers jours ont été prolifiques en news au sujet de l’écosystème jQuery. Le 31 janvier est sortie la version 1.5.0 de la librairie qui nous propose différentes améliorations intéressantes et sûrement attendues depuis longtemps par bon nombre de développeurs.

Les changements principaux de cette version concernent une réécriture complète du support Ajax fournissant une API encore plus efficace et consistante, et l’intégration d’un mécanisme qui permet de chaîner différents callbacks sur des appels de fonctions qu’ils soient asynchrones ou non.

L’API Ajax fournit maintenant un object jqXHR retourné par l’appel de la méthode jQuery.ajax() qui permet de gérer de façon consistante l’objet XMLHttpRequest quelque soit la plateforme utilisée. Par exemple, il est maintenant possible d’annuler facilement une requête JSONP ce qui n’était pas le cas auparavant.

// Assign handlers immediately after making the request,
// and remember the jxhr object for this request
var jxhr = $.ajax({ url: "example.php" })
.success(function() { alert("success"); })
.error(function() { alert("error"); })
.complete(function() { alert("complete"); });

// perform other work here ...

// Set another completion function for the request above
jxhr.complete(function(){ alert("second complete"); });

Une explication complète du mécanisme appelé: ‘Deferred Objects‘ est disponible sur le site de jQuery.

jQuery expose maintenant, par le biais de la méthode jQuery.sub() un moyen simple de créer et modifier un clone de jQuery dans la même page sans pour autant interférer avec la déclaration par défaut. il est ainsi possible d’overrider des méthodes natives jQuery sans craindre d’incompatibilité avec d’autres scripts d’une même page basée sur jQuery. Cela rend aisé l’écriture d’API basées sur jQuery sans risquer une collision de namespaces.

(function(){
var sub$ = jQuery.sub();

sub$.fn.myCustomMethod = function(){
      return 'just for me';
    };

sub$(document).ready(function() {
      sub$('body').myCustomMethod() // 'just for me'
    });
})();

typeof jQuery('body').myCustomMethod // undefined

Cette version inclut également des améliorations de performance puisque la gestion de certaines méthodes de traversée de l’arbre DOM ont largement été optimisées comme les méthodes: .children(), .prev(), and .next(). Ces améliorations sont particulièrement importantes sous webkit (Chrome et Safari), mais elles sont également intéressantes sous Internet Explorer, puisqu’elles permettent de faire décoller un peu les performances de notre cher navigateur.

A ce jour quelques 4500 tests passent avec succès sur un nombre impressionnant de browsers (dont IE6, mais également Firebox 4 beta), ce qui pousse au respect au vue de l’hétérogénéité de ce joyeux petit monde.

Pour finir sur une note intéressante, le système de build de jQuery est maintenant basé sur l’environnement serveur JavaScript: NodeJS, ce qui est plutôt original, mais qui permet au navigateur de réduire sa dépendance envers Java/Rhino, et de se tourner vers de nouvelles solutions JavaScript innovantes.

Une road map de la librairie est disponible à l’adresse suivante: http://docs.jquery.com/Roadmap.

Sortie de jQuery Mobile 1.0 alpha 3

Presque 3 longs mois après la sortie de la version précédente, jQuery Mobile vient tout juste de sortir sa troisième version alpha, accompagnant à une semaine d’intervalle la release de son grand frère jQuery en version 1.5.0. L’attente ne fut pas vaine, puisque de nombreuses améliorations sont au rendez-vous:

• Quelques 150 bugs fixés, environs 250 nouveaux tests unitaires
• Une amélioration substantielle de la navigation et du core de la librairie
• Un support de première classe pour de nouveaux browsers mobiles: Firefox Mobile (Fennec), Opera Mobile / Mini. Un support de première classe est également proche pour les plateformes Windows Phone 7 et Nokia.
• Un support amélioré des browsers des plateformes iOS, Android, BlackBerry 6, Palm WebOS, et de nose browsers de bureau.
• La prise en charge d’un date picker, non packagé dans la version. La prise en charge de nouveaux composants devrait arriver dans les prochaines versions (Progress Bar, Spinner, Time Picket)
• La prise en charge du clavier a été améliorée et permet de mieux simuler un comportement natif au sein du navigateur.
• De très nombreuses autres améliorations ont été intégrées à cette version. Une liste exhaustive peut être trouvée sur le blog de jQuery Mobile.

Ce qu’il faut retenir également, c’est l’annonce d’une bêta dans le mois qui va suivre, puis la sortie de la release 1.0 dans la foulée. Les objectifs fixés sont d’améliorer les performances générales de la librairie,
d’améliorer l’expérience utilisateur et la réactivité, et de fournir un support à un nombre plus important de browsers et plateformes mobiles. Bien que le sujet ne soit pas vraiment abordé dans le billet de l’annonce de cette sortie, on devrait également voir dans un avenir proche, une meilleure prise en charge de nos chères tablettes: iPad, PlayBook, et compagnie (après la sortie de la 1.0 ?).

Bien que l’annonce de cette release soit réjouissante pour le monde des développeurs mobiles, il n’en reste pas moins vrai que le niveau de performance souffre encore fortement la comparaison avec les applications natives (Gestion de liste), et la gestion de la navigation entre les différents écrans présente encore quelques dysfonctionnements. Il n’y a pas de doute que ce type de défauts seront rapidement gommés avec la sortie des prochaines versions.

Vous pouvez retrouvez ces informations sur le site de jQuery Mobile, leur blog et les suivre sur twitter via le compte: @jquerymobile.

NoSQL

Cas d’utilisation et pièges de NoSQL

Billy Newport, architecte de la In Memory Data Grid d’IBM (Websphere eXtreme Scale), présente dans « Enterprise NoSQL: Silver Bullet or Poison Pill? » les cas d’utilisation et le pièges des technologies NoSQL. Voici le résumé très succinct d’une présentation passionnante faite par un défenseur de NoSQL qui connait aussi parfaitement l’informatique vieille école IBM/mainframe/DB2/SQL-relationnel :

SQL et NoSQL résolvent des problèmes différents

Le monde SQL est centré sur le domaine (le modèle de données). Il permet grâce aux requêtes SQL et à des index de réaliser à peu près n’importe quelle question sur ce domaine avec des temps de réponse inférieur à la seconde.
A l’inverse, le monde NoSQL est centré la question dominante qu’on pose sur les données. NoSQL est souvent introduit quand on atteint les limites du modèle relationnel, le problème est tel qu’on façonne les données au cas d’utilisation dominant même si c’est au détriment des autres cas d’utilisation, des autres questions à poser sur les données.

SQL est là pour longtemps et a des atouts innombrables

Le monde SQL/relationnel a survécu aux bases Orientées Objet, hiérarchiques ou encore XML ; ce n’est pas NoSQL qui le renversera. Les atouts de SQL sont innombrables :

• Approche centrée sur le domaine qui ouvre à la réutilisation,
• Facilité de requêtage très puissant notamment grâce aux jointures,
• Normalisation des données en un système d’enregistrement sans copie pour prévenir les inconsistances,
• Outillage pléthorique depuis l’intégration aux environnements de développement aux solutions de reporting en passant pour les standards et outils d’intégration (JDBC, ODBC, ETL, EAI, etc),
• Performances adaptées à la très grande majorité des cas d’utilisation : un serveur bi processeur avec 256 Go de RAM et des disques SSD a une puissance incroyable pour un coût très raisonnable.

NoSQL : des solutions à la puissance hors normes et des pièges

NoSQL est souvent la solution lorsque le modèle relationnel atteint ses limites, le plus souvent pour des problèmes de volumétrie de données ou de performances.

Cependant, ces capacités hors normes s’accompagnent de nombreux pièges :

Le premier piège est qu’il faut radicalement changer de façon de penser ! il ne faut pas penser relationnel avec NoSQL sous peine d’avoir des performances moins bonnes qu’avec des bases SQL ! Les NoSQL ne supportent pas de jointures (hormis Neo4j), il ne faut pas normaliser mais au contraire gérer avec du code la consistence des données dupliquées.

Les modèles de données des NoSQL sont très peu structurés (blob, colonnes à géométrie variable, documents sans schéma, etc), c’est à la fois puissant et source d’anarchie. C’est au développeurs d’être rigoureux.

NoSQL est orienté « question dominante », la tenue à la charge est remarquable mais l’introduction d’une nouvelle question peut tout remettre en cause.

Map/Reduce est synonyme de « table scan multi-machines », c’est trop lent pour les accès interactifs. Il faut pré-calculer en batch-offline les search grâce à du map-reduce pour les transformer en get-by-key.

Le modèle répliqué avec shards ne permet pas de transactions, il faut coder les rollbacks.

NoSQL requiert des développeurs au niveau et à la formation hors du commun, tout le monde ne peut pas recruter comme Twitter, Google ou Facebook.

Ces pièges signifient-ils qu’il faut bannir NoSQL ? Sûrement pas, ce serait « jeter bébé avec l’eau du bain ». NoSQL résout des problèmes que SQL gère mal, il a ouvert des possibilités qui étaient hier inimaginables et amène SQL à faire une cure de jouvence.

Le coin de la technique

Nouvelles règles et gouvernance du projet OpenJDK

Mark Reinhold annonce dans ce billet la création d’un ensemble de règles, rassemblées dans le projet Bylaws définissant le fonctionnement de la communauté derrière le projet OpenJDK. Le but de ces règles est d’assurer l’avenir d’OpenJDK dont la communauté ne cesse de grandir (avec notamment de récents acteurs tels qu’Apple ou IBM).

Le but de Bylaws est d’encourager les membres du projet OpenJDK à agir de manière ouverte, transparente et d’instaurer une méritocratie favorable au projet. Le projet Bylaws étant encore à l’état de draft, Mark Reinhold encourage les personnes intéressées à poser des questions ou émettre des suggestions pour l’améliorer.

Le projet Bylaws définit aussi un board dont le but est d’assurer la gouvernance d’OpenJDK. Ce board sera initialement composé de :

• Adam Messinger (Chair, Oracle),
• Jason Gartner (Vice Chair, IBM),
• Prof. Doug Lea (At-Large, SUNY Oswego),
• Mike Milinkovich (At-Large, Eclipse),
• Mark Reinhold (OpenJDK Lead, Oracle).

Les réactions à cette annonce n’ont pas tardé à apparaître. Sur la composition du board dans un premier temps, à part Doug Lea et Mike Milinkovich qui sont indépendants, les autres membres sont liés à Oracle et IBM. D’autres importants contributeurs du projet, comme Google, Redhat et récemment Apple n’y sont donc pas représentés. Certains membres du board étant nouveaux venus sur le projet (IBM par exemple était auparavant sur le projet Apache Harmony), on peut comprendre certaines frustrations face à cette situation.

D’autres problèmes ont été levés comme :

• le rapprochement de l’OpenJDK et du JCP amène des problèmes de licence. La licence GPL d’OpenJDK est en effet incompatible avec les licences des spécifications, implémentations de référence et autres TCK produits par le JCP,
• les membres du projet doivent céder leurs droits à Oracle. Le projet OpenJDK étant communautaire, on peut effectivement se demander de quel droit Oracle s’approprierait les droits sur les développements effectués sur ce projet.

Ces points on été relevés par Mark Wielaard en réponse à la proposition de Mark Reinhold.

Le projet Bylaw est encore à l’état de draft et a provoqué de vives réactions dans la communauté OpenJDK. Espérons que la version finale aboutisse à un consensus satisfaisant pour tout le monde et permettant un développement du projet dans les meilleures conditions.

Important risque de Déni de Service

Une importante faille de sécurité est récemment remontée qui affecte nos applications Java tournant sur serveurs x86.

Cette faille permet une attaque par Déni de Service lorsque le système tente la conversion d’un nombre infiniment petit en Float. Lorsque qu’un thread de la JVM tente de traiter un nombre bien particulier (2.2250738585072012e-308), celui-ci se bloque et se met à consommer indéfiniment du CPU.

Les membres du projet Tomcat ont promptement réagi en proposant un patch disponible dans les versions 7.0.7 et 6.0.32 du serveur d’application Tomcat. Ce patch permet d’éviter une attaque consistant à passer le nombre en question dans le header d’une requête HTTP. Il est donc vivement recommandé de mettre à jour les serveurs d’application Tomcat avec les dernières versions disponibles. Dans le cas où il ne serait pas possible d’effectuer cette montée de version rapidement, nous vous recommandons de durcir la configuration de vos front-end Apache, firewalls ou autre load-balancers. Il est par exemple possible d’effectuer un filtrage du header HTTP à l’aide du mod_header d’Apache ou encore avec un iRule F5/BigIP. Nous n’avons hélas pas trouvé de lien vers des patchs d’autres éditeurs.

Le problème ne touchant malheureusement pas uniquement le header HTTP, il y aura tout de même un risque que le nombre en question soit passé dans un formulaire ou dans un appel web service.

On regarde donc maintenant en direction d’Oracle en espérant un patch de la JVM dans les plus brefs délais afin de pallier à ce problème une bonne fois pour toute.