Actualité éditeurs / SSII

• Object Grid Mapping, une alternative à Spring Data?
• Un flot de projets pour Hadoop
• JBoss AS 7 est sorti

Actualité éditeurs / SSII

Object Grid Mapping, une alternative à Spring Data?

Il manquait une API haut niveau, à la JPA, pour la manipulation des données dans Infinispan. En tant que preuve de concept, Emmanuel Bernard a tenté une adaptation d’Hibernate Core. Finalement, il s’avère que l’idée peut s’appliquer à de nombreux datastores NoSQL. C’est la naissance d’Hibernate Object Grid Mapping.

Les opérations CRUD sont stables mais la partie recherche par JP-QL est encore balbutiante. Celle-ci devrait cependant se reposer sur des technologies testées sur le terrain : Lucene et Hibernate Search.

JBoss par ce projet souhaite faciliter l’accès aux datastores NoSQL. Ce n’est certes pas sans rappeler Spring Data, l’initiative de VMware. Pour autant, même si ces deux entreprises sont en effet concurrentes et veulent se positionner en tant que facilitatrices, l’approche technique diffère.

JBoss souhaite proposer des implémentations pour une même API : JPA. La question se posera de savoir si JPA est suffisamment flexible pour cela. JPA fournit un vocabulaire commun; encore faut-il que pour chaque store sa sémantique ne varie pas trop.

VMware suit le principe de Spring : une configuration par POJO tout en ayant accès aux particularités de l’implémentation sous-jacente, quitte à avoir une API par datastore si cela se révèle être pertinent. On retiendra également que le but est plus large puisque le projet inclus également le support d’un framework MapReduce : Hadoop.

• http://www.infoq.com/news/2011/07/hibernateogm
• http://jduchess.org/duchess-france/blog/hibernons-avec-emmanuel-bernard/

Un flot de projets pour Hadoop

C’est peut-être la fin de la conquête spatiale mais l’ère du web ne fait que commencer. Et s’il y a bien quelque chose qui monte en flèche, c’est le volume des données.

HDFS vous a permis de stocker de manière distribuée vos données de telle sorte que la perte d’un noeud n’ait pas d’impact.

Avec l’API MapReduce, vous avez pu programmatiquement rapprocher vos traitements de vos données et profiter de la vitesse d’un calcul distribué et parallèle.

Mais voilà, après l’implémentation de plusieurs jobs, il vous a peut-être paru qu’il ne s’agissait pas nécessairement du bon niveau de granularité. Pig ou Hive vous ont alors permis d’exprimer vos requêtes avec un niveau d’abstraction équivalent à SQL pour les bases de données relationnelles.

Le paradigme relationnel est un acquis pour les entreprises. Passer à Hadoop ne signifie par pour autant que vous avez dû changer complètement votre système d’information. Avec HBase, vous avez pu disposer d’une base de données orientée colonne et d’un accès rapide à de petits fragments d’information. Et grâce à Sqoop, vos données relationnelles ont pu être importées dans HDFS.

Enfin Mahout vous a permis d’extraire de ces données une information pertinente en utilisant des algorithmes classiques de recommandation, clustering et classification.

Tous ces composants sont des éléments essentiels pour construire sa propre solution d’informatique décisionnelle que cela soit pour analyser les informations de ses utilisateurs ou pour consolider des sources de données externes. Cependant, au moins un élément manquait : l’orchestration des différentes étapes.

Yahoo a contribué à Oozie, une moteur de processus pour Hadoop. L’approche est classique. Le workflow peut se décrire par une API java ou en XML en utilisant hPDL, un langage similaire à celui utilisé par JBoss Business Process Management (jPBM) : jPDL. Les limitations les plus notables sont l’absence de support pour HBase et Hive.

L’écosystème d’Hadoop est jeune et en pleine expansion. L’ensemble des pièces est en construction et se perfectionne. Pour autant, c’est un écosystème qui a déjà fait ses preuves dans l’industrie comme le montre Yahoo et Hadoop.

• http://www.infoq.com/articles/introductionOozie
• http://yahoo.github.com/oozie/design.html
• http://archive.cloudera.com/cdh/3/oozie/DG_Overview.html

JBoss AS 7 est sorti

Impossible de passer à côté d’une des nouvelles les plus twittées de cette semaine : la sortie de la version finale du serveur d’application de RedHat, JBoss AS 7. Si sa version précédente implementait déjà la spécification Web Profile de JEE 6, il a fallu attendre la sortie de cette dernière release pour avoir l’implementation complète. L’équipe de Dan Allen et Pete Muir a travaillé à fond pour améliorer la vitesse de démarrage et le déploiement en réduisant, selon ce qui est annoncé sur le site, la durée par 10 par rapport à sa version précédente. Dans l’un des forums de JBoss, les meilleurs temps obtenus par ceux qui l’ont déjà testé sont affichés: ils varient entre une et trois secondes.

Quelles sont les bases de cette nouvelle release ?

Légèreté : l’introduction de la modularité via le Modular Services Container (MSC) permettant le chargement des jars en fonction de la demande.
Vitesse de démarrage : les services démarrent de façon concurrente pour profiter au maximum de l’architecture multi-core.

Par ailleurs la dernière version du serveur d’applications de Red Hat offre d’autres avantages tels que :

• Support à la spécification OSGi out-of-the-box
• Simplification de la gestion de la configuration
• Déploiement à chaud des fichiers de configuration
• Orientation à test en facilitant l’utilisation du modèle de composants Arquilian pour le développement des tests d’intégration.

Avec toutes ces caractéristiques, JBoss AS 7 se positionne au même niveau que d’autres serveurs d’application rivaux, notamment la référence de JEE 6, Glassfish 3.1.

http://community.jboss.org/wiki/AS7StartupTimeShowdown

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

Actualité éditeurs / SSII

• MySQL 5.5
• Sonar 2.4
• Hibernate Search 3.3

Le coin de la technique

• Une Refcard sur JPA2

Actualité éditeurs / SSII

MySQL 5.5

Après le rachat de MySQL en avril 2009 il y avait des craintes qu’Oracle continue à développer cette application. Cette nouvelle version 5.5 devrait rassurer (un peu) les inquiets car elle vient avec un bon nombre d’améliorations (à lire par ailleurs cette interview de Monica Kumar, d’Oracle, sur la complémentarité des deux produits). Parmi les points intéressants à noter:

• InnoDB devient le choix par défaut pour le moteur de stockage à la place de MyISAM. Ce dernier n’était pas transactionnel, entre autres défauts, et la plupart des utilisateurs changeaient leur configuration pour InnoDB.
• meilleur gestion dans l’utilisation des processeurs multi-coeurs dans le cas d’InnoDB
• amélioration des mécanismes de réplication avec à présent un heartbeat entre le maître et les esclaves ainsi qu’un envoi d’une confirmation lorsque le premier esclave a fini sa réplication (réplication semi-synchrone).
• un nouveau statement LOAD XML pour charger des données dans un fichier xml.
• il est possible à présent de plugger son système d’authentification, par exemple le LDAP de son entreprise.

Une liste plus complète des nouvelles fonctionnalités se trouve ici. Oracle estime une amélioration de 360% des performances de MySQL comparée à l’ancienne version, à prendre bien sûr avec des pincettes en fonction des différents cas d’utilisation. Sur Windows les chiffres grimpent même jusqu’à 1500% (!) de gain, cette version proposant une meilleure intégration à ce système d’exploitation. Bref cette nouvelle version semble très recommandable.

Sonar 2.4

La sortie de Sonar 2.4 le mois dernier nous avait échappé, profitons d’un rappel d’InfoQ cette semaine pour faire un tour des nouveautés:

• Régles d’architecture: une régle consiste à définir des exclusions de référence à un package. Par exemple on peut exclure les packages .web. (couche de présentation) dans les packages .dao. (couche basse d’accès aux données). On peut aussi exclure des classes de java jugés obsolètes comme Vector ou Hashtable. Parler d’architecture à ce niveau semble un peu exagérer tant les règles sont relativement simple mais ça peut aider à améliorer du code legacy.
• Personnalisation des dashboards: une vue synthétique peuvent être proposés à des chefs de projet ou des managers tandis qu’un développeur utilisera une vue détaillée qui contiendra plus de widgets par exemple. Sonar prévoit par ailleurs d’ajouter de nouvelles widget.
• Un centre de mise à jour des plugins: une page permet à présent de lister les plugins installés, de les mettre à jours, d’en installer d’autres et de vérifier s’il existe une nouvelle version de Sonar.
• Support pour Maven 3.0: cette mise à jour est appréciable. Il est à noter qu’il existe malgrès tout une incompatibilité avec Clover.

Dans ce même article, Olivier Gaudin, de l’équipe Sonar, nous informe des prochaines évolutions. Les règles d’architectures devraient se complexifier grâce à l’ajout d’un DSL permettant d’exprimer une règle comme “La couche A ne peut être utiliser que par la couche B et C”. Il identifie également 3 axes pour diminuer sa dette technique: meilleure visibilité de la dynamique d’un projet (ajout ou suppression de violations de certaines règles), une zone de partage d’information pour les revues de code et intégration d’une version légère dans Eclipse pour anticiper avant les commits les éventuelles violations.

Hibernate Search 3.3

La nouvelle version d’Hibernate Search 3.3 est disponible. Elle contient en particulier un nouveau système de requêtes DSL qui permet de faciliter l’écriture des requêtes, Martin Fowler parlera plutôt de Fluent Interface. Voici un exemple :

Query luceneQuery = mythQB.keyword()
.onField("history")
.andField("name")
.boostedTo(5)
.andField("description")
.matching("storm")
.createQuery();

Ceci allège l’écriture et devrait donc faciliter l’élaboration de requêtes plus complexes.

Sous le capot, des modifications ont été apportées sur le mécanisme d’envoi de message pour mettre à jour les indexes, améliorant ainsi les performances. De plus ces indexes peuvent également être stockés sur une grille Infinispan (qui appartient à JBoss tout comme Hibernate Search). Pour ne rien gâcher, des nouveaux indicateurs sur les statistiques sont remontés via JMX pour mieux configurer l’outil.

Enfin Hibernate Search 3.3 est compatible avec Lucene 3.0. Bien que cette dernière version de Lucene contienne des problèmes de rétro-compatibilité, Hibernate Search les masquera. Par ailleurs il supporte le nouveau type @NumericField encore expérimental dans Lucene mais qui améliore beaucoup les performances.

Le coin de la technique

Une Refcard sur JPA2

Mike Keith, un expert en persistance Java nous avait offert la Refcard « Getting started with JPA » en septembre 2008. Il vient de récidiver pour notre plus grand plaisir avec « What’s New in JPA 2.0 »
Une Refcard sur JPA est une très bonne idée, car qui n’a jamais pesté de ne pas savoir immédiatement quelles étaient les bonnes façons d’annoter ses entités. Entre les annotations provider-specific et « normalisées JPA », il y a en effet souvent de quoi se perdre. En effet, on trouve parfois des pièges comme @Mapkey par exemple qui se comporte différemment selon le fournisseur.

La première Refcard était, tout comme JPA 1, assez basique et nous rappelait des notions comme les entity managers et les transactions (container-managed ou non) ainsi qu’une petite référence JPQL pour écrire ses requêtes…
Dans la nouvelle mouture, nous retrouvons les apports de JPA2 à la persistance comme par exemple:
- la suppression des orphelins avec l’attribut orphanRemoval de @OneToMany
- les nouvelles fonctionnalités de JPQL (tiens, on peut utiliser un ‘CASE’, bon à savoir ! )
- les requêtes typées pour ceux qui veulent éviter de caster les valeurs de retour

Et pour ceux désirant renforcer au maximum le typage de leur requêtes à la compilation, les requêtes Criteria fortement typées sont évoquées:

CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery c = cb.createQuery(Account.class);
Root acct = c.from(Account.class);
c.select(acct).where(cb.equal(acct.get(Account_.name), “Jim Morrison”));
List result = em.createQuery(c).getResultList();

Certes, la façon de générer la classe du metamodèle canonique (le Account_ avec l’underscore bizarre) n’est pas évoquée et il vous faudra trouver par vous même comment la générer avec Hibernate ou avec EclipseLink. Mais le principe d’une RefCard est justement de ne pas être exhaustif, mais de donner les clefs pour un survol rapide des possibilités. Se rafraîchir ainsi la mémoire fait généralement beaucoup de bien et cette nouvelle Refcard mérite donc de rejoindre sa grande sœur et de rester en permanence à porté de main.

Le rendez-vous annuel incontournable de la communauté Java européenne est arrivé ! 3000 participants inscrits et une centaine de speakers pour 5 jours de conférences à Anvers en Belgique : Devoxx s’annonce cette année comme grandiose après une édition 2009 en léger retrait en raison du contexte économique. Xebia sera présent à cet évènement pour vous retransmettre l’information qui y sera véhiculée.

Au-delà des connaissances techniques qui y circulent, des échanges et des rencontres qui s’y font, Devoxx est aussi un formidable baromètre de l’éco-système Java actuel. Il est donc intéressant d’observer les sujets les plus en vogue cette année :

• NoSQL : il s’agit clairement du sujet majeur dont il sera question cette année. Très peu représenté l’année dernière (2 sessions seulement), on compte pour cette édition pas moins d’une douzaine de sessions dédiées à ce thème. Il sera ainsi question de Cassandra, HBase, Hadoop, Hive, Pig, MongoDB ou encore Voldemort.
• Java EE 6 et JPA 2 : déjà très représenté l’année dernière, ce sujet sera encore d’actualité cette année à Devoxx, ces APIs n’ayant pas encore été digérées par les entreprises.
• JDK 7 : le sujet devient récurrent, mais la récente actualité le concernant le rend incontournable dans une conférence Java de cette envergure. Cette semaine à Anvers sera l’occasion de faire le point sur les dernières avancées et orientations avec l’équipe responsable du JDK chez Oracle.

Outres ces sujets majeurs, on retrouve de nouveaux venus tels que DevOps, ce mouvement prônant le rapprochement des équipes de développement et d’exploitation, ainsi que des sujets maintenant plus classiques qui présenteront leurs dernières évolutions tels que Grails, Android, Scala, ou HTML5.

Comme l’année dernière, vous retrouverez jour après jour sur ce blog et celui de Duchess France nos retours des principales sessions qui se tiendront à Anvers cette semaine. Retrouvez également l’information en live sur nos comptes Twitter : dijouxellene, mfiguiere, morlhon et rmat0n.

Actualité éditeurs / SSII

• Apache Whirr, une proposition de librairie pour le Cloud

RIA

• Où l’on reparle de JavaFX

Le coin de la technique

• Des breaks dans Scala !
• Une troisième implémentation de JPA 2 finalisée

Actualité éditeurs / SSII

Apache Whirr, une proposition de librairie pour le Cloud

Whirr est une proposal intéressante qui vient d’apparaître au sein de la fondation Apache. Il s’agit de réunir au sein de ce projet tout un ensemble de scripts et de code source permettant d’intégrer facilement des services Apache avec les fournisseurs d’infrastructures de Cloud Computing. Parmi les première applications / services dont il est question, on compte sans grande surprise Hadoop (implémentation Java du modèle MapReduce de Google), HBase (implémentation de BigTable de Google au dessus d’Hadoop), ZooKeeper (service de configuration, nommage et synchronisation pour applications distribuées, implémentation Java de Chubby de Google), et Cassandra (base de données hybride BigTable et Dynamo, initialement développée par Facebook). Ces projets ont en effet acquis une grande popularité en quelques mois et font maintenant partie des applications typiques du Cloud Computing.

La raison d’être du projet est de mutualiser les efforts fournis par ces projets pour fournir des scripts et des mécanismes d’intégration de qualité sur les plate-formes de Cloud Computing. Au-delà de ces justifications techniques, on remarquera qu’il s’agit d’une véritable reconnaissance du Cloud Computing en tant qu’enjeu d’avenir. En effet cette proposition intervient dans un contexte où les projets liés à ce sujet se multiplient au sein de la fondation Apache, puis acquièrent leur indépendance : après la promotion de Cassandra hors de l’incubateur Apache, c’est au tour de HBase d’être promu top-level project sortant donc de l’affiliation au projet Hadoop. Enfin, on notera que les acteurs impliqués dans la proposition Whirr sont majeurs : Cloudera, Twitter ou encore HP Labs.

RIA

Où l’on reparle de JavaFX

JavaFX a beaucoup fait parler d’elle après sa sortie fin 2008. Elle n’avait guère convaincu : on lui reprochait de ne pas être mature, de ne pas offrir de composants graphiques de haut niveau, de ne pas tenir ses promesses de déploiement sur plusieurs plates-formes puisqu’il n’était alors pas possible de l’utiliser sur TV et sur mobile comme cela devait être le cas.

En février 2009, la version 1.1 avait permis le déploiement des applications JavaFX sur mobile (tout du moins théoriquement). La version 1.2, sortie en juin dernier, avait été une autre étape majeure en introduisant enfin des composants graphiques évolués.

Lors de la conférence Devoxx de novembre dernier, il avait été amusant de constater que les sessions et keynotes dédiés à JavaFX, si présents lors de la précédente édition, avaient été remplacés par leurs équivalents Flex avec l’annonce en grande pompe d’Adobe Catalyst. JavaFX disparaissait peu à peu de l’actualité.

Oracle vient d’annoncer l’arrivée de la version 1.3. Les nouveautés sont incontestablement conséquentes :

• Support étendu de CSS pour le design des widgets : JavaFX supportait déjà CSS, il va maintenant plus loin dans l’intégration de ce langage de style.

• Nouveaux widgets : une liste déroulante (ChoiceBox), un champ de saisie de mots de passe (PasswordBox), une vue scrollable (ScrollView), un séparateur (Separator) et une bulle d’information (ToopTip).

• Amélioration de widgets existants : divers améliorations des composants ListView, TextBox et Slider

• Le support des TV fait enfin son apparition : les TV faisaient historiquement partie des plates-formes de déploiement possibles pour JavaFX mais n’étaient pas accessibles jusqu’alors. Un émulateur de TV vient compléter ce support.

Pour rappel, l’équipe de développement de JavaFX expliquait que leur vision était qu’après une certaine période de développement, les différentes plate-formes RIA convergeront vers un niveau de fonctionnalités similaire et que JavaFX pourrait alors briller du fait de son intégration native à Java. Cette version 1.3 semble bien une étape pour rattraper le (grand) retard face à l’environnement RIA d’Adobe en terme de fonctionnalités, il sera alors intéressant de voir si JavaFX pourra maintenant rattraper son retard en terme d’adoption.

Le coin de la technique

Des breaks dans Scala !

Avec la sortie de la RC1 de Scala 2.8.0, la communauté est en ébullition et les articles sur les nouveautés de cette release majeure affluent sur la toile.

Ainsi, Scala ayant une syntaxe très allégée par rapport à Java, certains mots clés avaient tout simplement disparu du langage pour le malheur de certains java-istes. C’est le cas de break, souvent utilisé pour, par exemple, sortir d’une boucle, qui n’était jusqu’à présent pas disponible dans Scala. Le mot clé fait ainsi son apparition dans cette version 2.8.0, non pas en tant que mot clé mais en tant que trait/object.

La syntaxe sera donc un petit peu différente par rapport à ce que nous avions l’habitude d’utiliser en Java. Il faudra ainsi englober le code pouvant être arrêté dans un breakable, l’appel à break restant le même :

// Java
for(int i=0; i<10; i++)
   if(i==5) break;
   i++;
}
//Scala
breakable {
   for(int i=0; i<10; i++)
      if(i==5) break;
      i++;
   }
}

Rendez-vous sur cette page pour télécharger cette RC1 de Scala 2.8.0 et essayer de toute urgence les breaks mais aussi les Package objects, la nouvelle API de collection, les paramètres nommés et par défaut, le tout nouveau REPL ainsi que beaucoup d’autres nouveautés !

Une troisième implémentation de JPA 2 finalisée

La communauté Java dispose maintenant d’une troisième implémentation de la JSR-317 (JPA 2.0) : OpenJPA 2.0. Ce projet de la fondation Apache est utilisé dans WebSphere AS et constitue de ce fait un choix d’implémentation pertinent.

OpenJPA succède donc à EclipseLink (qui étant l’implémentation de référence avait logiquement été finalisée en premier) et Hibernate (qui a finalisé sa version 3.5 conforme à JPA 2.0 le mois dernier).

Les nouveautés d’OpenJPA 2.0 se limitent avant tout au support de JPA 2.0 ce qui inclut :

• La nouvelle API de construction de requêtes, basée sur l’interface QueryBuilder, qui standardise et étend l’API Criteria d’Hibernate.
• L’intégration à la JSR-303 (Bean Validation) qui apporte une logique de validation uniforme pour toutes les couches d’une application JEE.
• Une API de méta-modèle permettant de naviguer par programmation dans le modèle de données d’une unité de persistance.
• Diverses améliorations des APIs JPA

JPA avait connu une très large adoption par la communauté Java, mais on lui reprochait parfois quelques manquements qui nécessitaient de recourir aux APIs propriétaires de son implémentation. Ces ajouts permettent de contourner ces limites et donc de supprimer dans la plupart des cas le recours au fameux entityManager.getDelegate().

Actualité éditeurs / SSII

• Le meilleur de The Server Side

Le coin de la technique

• Spring Security seulement un alignement sur Spring 3.0 ?
• Tour d’horizon de JBoss Infinispan
• JGroups à l’heure du Cloud Computing

Actualité éditeurs / SSII

Le meilleur de The Server Side

Avec les fêtes vient le temps des rétrospectives. Et c’est TheServerSide qui ouvre le bal, avec son hit parade des neuf fils de discussion les plus vus en 2009. Sans surprise, on retrouve quelques stars de l’année, dont la popularité ne devrait pas faiblir en 2010 : JavaEE 6 et Glassfish 3, la persistance (JPA, les caches d’Hibernate, la démarcation transactionnelle avec Spring)… Mais aussi les buzz de l’année : Google App Engine, les langages next-gen… On trouve ensuite un grand article communautaire, sur ce que doit savoir un architecte applicatif.
Enfin, et nous devons bien avouer qu’à la vue des évènements passés, cela prête à sourire, un très beau fil de prospective : IBM parle de racheter Sun.

Cette première rétrospective reflète pour nous bien les tendances de l’année passée : pas mal de grandes manœuvres chez les éditeurs, des concurrents à Java de plus en plus présent, un nouvelle spécification très attendue, et des frameworks incontournables qui continuent à mener la danse.

Le coin de la technique

Spring Security seulement un alignement sur Spring 3.0 ?

Dans la foulée de la sortie de la version 3 de Spring Framework, c’est au tour de Spring Security de faire son annonce. Le point le plus marquant de cette version est l’utilisation du Spring Expression Language pour décrire les règles de contrôle d’accès qui simplifieront des vérifications simples comme @PreAuthorize("#contact.name == principal.name)") et surtout, couplé à des classes java transverses de sécurité, permettra d’effectuer élégamment des contrôles déclaratifs sophistiqués tels que :

@PreAuthorize("isPhysician(#patientFile.patient)")
public void create(PatientFile patientFile);

Bien sûr, il faudra programmer la méthode isPhysician(), Spring Security ne se substituera pas au code métier de votre application, il sera juste une aide précieuse .
Nous noterons au passage que l’Expression Language apporte à l’Aspect Oriented Programming le haut niveau d’abstraction qui permet de programmer des fonctionnalités métiers transverses sans être un spécialiste de la plomberie ProceedingJoinPoint et autres joyeusetés. L’AOP devient alors beaucoup plus accessible pour les développeurs d’informatique de gestion.

Les autres nouveautés que nous garderons en tête : des contrôles pré et post traitement (@PreAuthorize et @PostAuthorize), la restructuration des jars similaire à celle que Spring 2.5 a connu, et une clarification des règles de redirection post authentification.

Tour d’horizon de JBoss Infinispan

Le projet Infinispan a été initié en milieu d’année 2009 chez JBoss. Il s’agit d’une évolution de JBoss Cache d’un simple cache vers un DataGrid.

Dans le dernier épisode en date de JBoss Asylum, le podcast dédié à la communauté JBoss maintenu par Emmanuel Bernard et Max R Andersen, Mark Surtani, leader du projet Infinispan, était invité pour parler de son projet. Il a pu faire un tour d’horizon global en commençant par le lien entre JBoss Cache et Infinispan :

• Contrairement à JBoss Cache qui utilisait une organisation arborescente, Infinispan se base uniquement sur une structure clé-valeur à plat.
• Tout comme le faisait JBoss Cache, Inifinispan utilise JGroups pour assurer la découverte de ses instances.
• Une API d’adaptation permettra d’assurer la transition entre JBoss Cache et Infinispan, notamment en offrant une arborescence au dessus de la structure de base d’Infinispan. Des outils seront fournis afin de migrer les fichiers de configuration.

Manik Surtani a également abordé les fonctionnalités à venir, après la finalisation de la première version, dévoilant ainsi les ambitions de positionnement de ce produit :

• Utilisation de Lucene pour offrir une API de requêtes puissante permettant des recherches dans le DataGrid. Plusieurs possibilités d’architecture ont été évoquées telles que la réplication d’un index complet sur l’ensemble des noeuds ou la distribution de shards de l’index complet sur les noeuds via l’utilisation d’un InfinispanDirectory pour Lucene, actuellement en cours de développement.
• Intégration éventuelle avec Hibernate Search. Infinispan se substituerait à Hibernate Core et Hibernate Search lui apporterait alors la fonctionnalité de recherche.
• Possibilité d’effectuer des continuous requests pour que les résultats d’une requête s’enrichissent au fur et a mesure de l’arrivée de données sur la grille.
• API de MapReduce permettant de soumettre un Callable et un ensemble de clés d’objets sur lesquels doivent s’appliquer le traitement pour obtenir un Future représentant le résultat, à venir, après opération de réduction.

La plupart des fonctionnalités évoquées sont présentes dans les produits commerciaux que sont Oracle Coherence ou IBM eXtreme Scale. Toutefois, de telles possibilités seraient inédites dans un produit Open Source ce qui devrait faire d’Inifinispan un produit très intéressant à suivre en 2010…

JGroups à l’heure du Cloud Computing

JGroups est un framework permettant la communication au sein d’un groupe de serveurs. Actuellement développé au sein de JBoss, il est à la base de nombreux middlewares et frameworks d’entreprise permettant un fonctionnement distribué tels que JBoss Cache ou plus récemment Infinispan.

Après un an sans mise à jour majeure, Bela Ban, leader du projet, annonce la version 2.8. Outre de nombreuses évolutions améliorant la flexibilité de JGroups, un apport notable s’est glissé dans la liste : le support d’Amazon EC2. Il s’agit là d’une nouveauté emblématique de cette année 2009 qui va se conclure ; la majorité des frameworks cherche à afficher une compatibilité voire une synergie avec les environnements de Cloud Computing courant.
En pratique, cette intégration de JGroups à EC2 se fait par l’ajout d’un nouveau protocole de découverte de voisinage nommé S3_PING. Comme son nom l’indique, il utilise un stockage S3 commun dans lequel tous les membres d’un groupe écrivent leurs coordonnées. Ce mécanisme est particulièrement bien adapté à EC2 qui, de part la topologie réseau qu’il offre, ne permet pas le multicasting et n’est guère adapté aux autres protocoles de découvertes qui existaient jusqu’alors dans JGroups.

Notons tout de même que la principale nouveauté de cette version 2.8 est l’ajout du concept d’adresse logique que Bela Ban présentait il y a quelques mois. Une adresse logique permet de découpler l’identité d’un nœud JGroups de son adresse réseau ; l’association entre adresse logique et physique est résolue lors de la découverte des nœuds. Outre le découplage offert par ce concept, ces adresses permettent également de simplifier la gestion des pertes de messages lors de la ré-incarnation d’un nœud suite a son indisponibilité temporaire.

10 ans après sa création, JGroups continue donc de se maintenir à jour et, dans la mesure où il remplit toujours parfaitement son rôle, il devrait rester présent encore des années dans plusieurs middlewares et frameworks majeurs.

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.

RIA

• Mockito-Flex

Le coin de la technique

• JPA implementation patterns
• HadoopDB : un hybride entre MapReduce et DBMS
• Gaelyk ou Groovy sur AppEngine
• PostGIS, le SIG Open Source qui monte

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

• Enquête JavaEE 6

RIA

Mockito-Flex

Un mois après la sortie de la version 1.0, Mockito-Flex se met à jour en 1.0.1. Une release mineure donc mais qui apporte toutefois son petit lot de nouveautés (matchers anyOf(type:Class), notNull() …).

Les utilisateurs de Mockito ne seront pas perdus, le code Flex étant très similaire au code Java que ce soit pour les assertions ou pour le verify:

var list:ArrayCollection = ArrayCollection(mock(ArrayCollection, "collection", [[]]));
given(list.getItemAt(1)).willReturn("A");
assertEquals("A", list.getItemAt(1));
assertNull(list.getItemAt(2));
...
var array:Array = mock(Array) as Array;
array.push("1");
array.pop();
verify().that(array.push("1"));
verify().that(array.pop());

Le projet est très récent et néanmoins en bonne voie : article sur InfoQ, mailing-list, tutoriel… Comme toujours, rendez-vous est pris dans la section téléchargements.

Le coin de la technique

JPA implementation patterns

Vincent Partington, collègue de Xebia Hollande, a réalisé une série d’articles autour de la spécification JPA. Ses articles sont un complément à la documentation existante afin de faire le tour sur les fondamentaux et les faux-amis de JPA :

• Dao générique
• Persister, retrouver, effacer une entité
• Pattern d’architecture : Pour ou contre les DAO, DTO ou facade service, …
• Et bien d’autres patterns …

JPA et ses implémentations (telle qu’Hibernate) restent une technologie difficile à maitriser, et ces articles vous aideront à prendre des décisions techniques importantes pour vos projets.

HadoopDB : un hybride entre MapReduce et DBMS

Daniel Abadi a présenté HadoopDB, un projet issu des universités de Yale et de Brown, qu’il qualifie d’hybride entre MapReduce et DBMS classique. Il s’agit d’une extension pour Hadoop et Hive qui permet d’utiliser une base de données en remplacement de HDFS, le file system distribué utilisé par Hadoop.

Concrètement chaque nœud Hadoop embarque son propre serveur de base de données. HadoopDB reçoit des requêtes SQL qu’il analyse, traduit en tâches MapReduce qui seront envoyées sur chacun des nœuds du cluster Hadoop, puis retraduites en SQL pour être finalement exécutées par la base de données sous-jacente (SQL to MapReduce to SQL Planner).

L’ensemble du projet est décrit dans la publication qui lui est consacrée. Celle-ci présente en détail les réflexions qui ont accompagné la conception d’HadoopDB et les performances obtenues faces à des DBMS parallèles dédiés à l’analyse de données tels que Vertica. Si les performances mesurées d’HadoopDB sont en léger retrait face à Vertica, l’auteur met en avant que sa solution repose uniquement sur des technologies Open Source et qu’une base de données relationnelle (PostgreSQL) a été utilisée : il espère de meilleurs résultats en utilisant une base de données orientée colonnes.

Gaelyk ou Groovy sur AppEngine

Parmi les sujets traités régulièrement sur notre blog, on retrouve Groovy et Google AppEngine (GAE). Qu’obtient-on en mélangeant ? Et bien le dernier projet de Marcel Overdijk et de Guillaume Laforge à savoir Gaelyk (annonce).

Le toolkit s’appuie sur Groovlets et Groovy Template, et permet de déployer rapidement de petites applications sur GAE. Les auteurs rappellent en effet que pour de plus grosses applications, il vaut mieux se tourner vers Grails.

Le tutoriel très complet permet de faire un rapide tour d’horizon de Gaelyk.
Celui-ci décrit l’arborescence d’un projet Gaelyk, la configuration du web.xml et du appengine-web.xml.
La partie vues et contrôleurs s’intéresse :

• aux variables implicites mises en place par la servlet principale (eager avec request, response, context, session… et lazy avec out, html...),
• aux Groovy Templates, avec plusieurs exemples de gtpl, gestion des incude et redirect,
• aux Groovlets, avec là aussi plusieurs exemples de scripts.

Enfin, une dernière partie détaille les ajouts de syntaxes/méthodes spécifiques à Google AppEngine (envoi de mails, Entity, withTransaction()…) et explique comment déployer son application.
Un exemple d’application qui utilise Gaelyk est la Groovy Web Console, ou l’écriture de code Groovy live. Alors, un petit HelloWorld ?

PostGIS, le SIG Open Source qui monte

Les SIG (Systèmes d’Information Géographique) prennent de nos jours une nouvelle dimension avec la généralisation progressive de terminaux mobiles connectés à Internet et capables de se géolocaliser ou encore avec les sites Web riches proposant des cartes, des calculs d’itinéraires ou des recherches du plus proche point de vente. A travers cette évolution, un plus grand nombre d’entreprises peut potentiellement être intéressé par les SIG.

Alors que pendant un temps les principaux acteurs sur ce marché étaient des produits commerciaux, on trouve désormais une offre Open Source : MySQL Spacial, H2Spacial, SpacialLite et PostGIS.
Au sein de cette offre, PostGIS, une extension de PostgreSQL qui a fait son apparition il y a 4 ans, se distingue par sa maturité et sa popularité. Ainsi, l’éditeur Manning a récemment annoncé un ouvrage qui lui sera consacré pour début 2010.

Le site du projet vient d’annoncer la disponibilité de la version 1.4 de PostGIS apportant son lot d’améliorations et de corrections. Le driver JDBC dédié, composé principalement d’extensions à l’API JDBC standard, est lui aussi mis à jour, on le trouve dans la même archive que PostGIS.

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

Enquête JavaEE 6

Sun, via TheServerSide, relance la communauté Java pour ses cinq enquêtes à thème auprès des développeurs JavaEE6. Ces enquêtes doivent servir à optimiser les cours et les certifications JavaEE 6. Si vous êtes prêts à donner cinq minutes de votre temps à l’amélioration de la formation Java, n’attendez plus, vous avez jusqu’au 31 juillet.

Je vais vous présenter de manière concise le fonctionnement du datastore. De par sa nature, il impose des contraintes fortes, qui nécessitent de revoir sa façon de modéliser les données et de gérer la persistance dans son application.

Datastore et Big Table

La base de données de GAE appelée datastore repose sur le SGBD Big Table développé en interne par Google. Celui-ci a la particularité d’être hautement scalable et s’appuie sur un système de fichiers distribués géré par GFS (Google File System).
Big Table est une Map ordonnée multi-dimensionnelle. Les données (ou entités) sont stockées sous forme de <Clé, Valeur> dans des partitions appelées tablets. Des tablettes META1 référencent l’ensemble des tablettes contenant les entités. Une tablette maître appelée META0 référence les tablettes META1 et permet au client d’accéder aux tablettes de la base. Pour optimiser les performances, un mécanisme de cache permet au client de s’adresser directement aux tablettes META1 et aux tablettes contenant les entités.

MapReduce

L’idée de Google a été de simplifier au maximum la gestion des données sur un nombre très important de clusters. Le but étant de pouvoir tirer parti des milliers de machines dont dispose Google pour former un cluster géant.
La solution trouvée par Google s’appelle MapReduce. Cet algorithme permet de paralléliser et de distribuer automatiquement les données du datastore.
Lorsqu’une requête (un select par exemple) est exécutée sur une entité, le MapReduce est alors lancé pour récupérer le résultat. Il se décompose en deux étapes (ou fonctions):

• Une première fonction, Map, est appliquée sur les différentes partitions et renvoie une liste de valeurs intermédiaires (clé, valeur intermédiaire) correspondant aux critères du select.
• Ensuite, une seconde fonction, Reduce, fusionne toutes les valeurs intermédiaires pour une même clé pour former le résultat final (une valeur finale).

Entité et groupe d’entités

Vous l’aurez compris, le datastore n’est donc pas une base de données de type relationnelle, mais de type hiérarchique.
Cela implique une manière totalement différente de modéliser et d’accéder aux données de la base. Les données sont modélisées sous forme d’entités et de groupes d’entités. Une entité qui n’a pas de parents est appelée ‘root entity’. Cette root entity peut avoir des enfants, on appelle alors cet ensemble un groupe d’entités (entity group). Chaque groupe d’entités constitue alors un ensemble cohérent et indépendant vis à vis d’autres entités. Ces grappes d’objets peuvent ainsi être clusterisées dans une tablette.

Chaque entité est constituée d’un ensemble d’attributs, certains pouvant faire référence à d’autres entités. Une entité est implémentée avec une simple classe POJO, annotée avec JDO ou JPA.
Voici un exemple d’implémentation d’une entité UserEntity avec JDO:

@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class UserEntity {
	public UserEntity(){}
	@PrimaryKey
	@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
	private Key key;
	@Persistent
	private String email;
	@Persistent
	private List<FeedEntity> feeds;
	...
}

Clés primaires

Chaque entité dispose d’une clé qui l’identifie de manière unique parmi toutes les entités du data store. La clé contient un ensemble d’informations tel que l’application ID, la classe de l’entité et l’ID de l’entité. L’application doit fournir la partie ID de la clé via une propriété sur l’objet annoté avec @PrimatyKey avec JDO ou @Id avec JPA. Cette propriété peut être de type numérique (Long uniquement) ou de type String (unencoded String) et être générée automatiquement par le data store.
L’exemple ci-dessous représente un ID de type numérique implémenté via l’annotation @PrimaryKey (implémentation JDO). Au passage, on remarquera que la stratégie de génération des ID est dans tous les cas de type IDENTITY:

@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private Long id;

Malheureusement, si vous comptez gérer des relations entre entités, il n’est pas possible d’utiliser les types d’ID décrits précédemment. Il est nécessaire d’utiliser une instance de l’objet Key (com.google.appengine.api.datastore.Key) fourni par l’API de GAE. Il est tout de même possible d’utiliser une forme réencodée en String de cet objet Key afin de ne pas être dépendant de l’API GAE et de faciliter la migration de l’application hors de GAE.
L’objet Key inclut la clé de l’entité parent si elle existe, ainsi que l’ID. L’ID est fourni soit de manière manuelle par l’application sous forme de String, soit de manière automatique par le data store sous forme numérique. Dans ce dernier cas, il suffit de laisser la valeur à null.

Dans l’exemple ci-dessous, on peut voir qu’il est possible d’ajouter un accès direct à l’ID (numérique ou String) via un attribut supplémentaire id:

@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class FeedEntity {
	public FeedEntity(){}
	@PrimaryKey
	@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
	private Key key;
	@Persistent
	@Extension(vendorName = "datanucleus", key = "gae.pk-id", value = "true")
	private Long id;
	...
}

Par ailleurs, GAE offre une API pour manipuler les clés.
Pour créer une clé manuellement, il suffit d’indiquer la classe de l’entité et l’ID, de type numérique ou String, qui l’identifie de manière unique:

	Key k = KeyFactory.createKey(UserEntiy.class.getSimpleName(), "capitaine.haddock@xebia.fr");

Il est aussi possible de convertir une clé en String ou l’inverse via les méthodes KeyFactory.keyToString() et KeyFactory.stringToKey().

Les relations

Les relations sont modélisées de manière classique via les propriétés de l’entité qui référencent d’autres instances. Il est important de modéliser les relations en gardant à l’esprit que le data store est un système hiérarchique constitué de parents-enfants et de groupes.

GAE décrit les relations de deux manières : les owned relationships et les unowned relationships. On dit qu’une relation est owned lorsqu’une des entités de la relation ne peut exister sans l’autre. Ceci arrive dans le cas d’une entité enfant qui est liée à l’entité parent. L’entité parent peut elle-même être enfant d’une autre entité ou être une root entity. On dit qu’une relation est unowed lorsque les entités sont indépendantes : elles n’appartiennent pas au même groupe d’entités.

• owned relationship: GAE gère nativement les relations de type one-to-one, one-to-many (unidirectionelle et bidirectionelle), mais pas les many-to-many. Lors d’une opération de mise à jour ou de suppression, une cascade est appliquée aux enfants de la relation. Dans le cas d’une création, les enfants sont créés automatiquement et l’ensemble appartient au même groupe d’entités.
• unowned relationship: on ne peut pas modéliser la relation via une instance, mais uniquement via l’objet Key référençant l’entité. Il est alors possible de mapper les différents types de relations.

Pour réaliser des many-to-many, il faut que chaque entité référence l’autre entité via sa Key. On entre alors dans le cas d’une unowed relationship. On peut voir ci-dessous un exemple de many-to-many:

import com.google.appengine.api.datastore.Key;
import java.util.List;
@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class UserEntity {
	public UserEntity(){}
	//...
	@Persistent
	private List<Key> feeds;
	//...
}

import com.google.appengine.api.datastore.Key;
import java.util.List;
@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class FeedEntity {
	public FeedEntity(){}
	//...
	@Persistent
	private List<Key> users;
	//...
}

Les requêtes

Les requêtes sont écrites en JDOQL ou JPQL selon que l’on utilise l’implémentation JDO ou JPA. Il est possible de faire des jointures entre des entités appartenant au même groupe et de filtrer via des propriétés des entités parent et enfant.
Le data store gère les sélections, les filtres et les tris. Il est aussi possible de définir des plages (range) de résultat.
Cependant, oubliez les group by, les aggrégations, et les fonctions, ainsi que l’opérateur !=. Autre contrainte : il n’est possible de définir qu’un seul filtre d’inégalité par requête, et il faut impérativement ajouter la propriété filtrée comme première clause dans le tri.

import java.util.List;
import javax.jdo.Query;
// ...
Query query = pm.newQuery(FeedEntity.class);
query.setFilter("lastUpdateDate >= dateParam");
query.setOrdering("lastUpdateDate desc");
query.declareParameters("Date dateParam");
query.setRange(0,10);
List<FeedEntity> results = (List<FeedEntity>) query.execute(new Date());

GAE génèrent des index automatiquement pour chaque requête de l’application. Il est possible de créer ses propres index dans le fichier datastore-indexes.xml selon les besoins. Attention, les entités dont les propriétés ne sont pas indexées ou dont les propriétés n’existent pas seront ignorées par le data store.

À ce jour, Google ne fournit aucun outil pour visualiser et requêter le datastore en environnement de développement.
Cependant, dans l’interface d’administration du serveur fourni par Google, il est possible de requêter sur le datastore de production via le langage GQL (Google Query Langage) qui ressemble beaucoup à SQL.

Les transactions

Le datastore permet d’effectuer un ensemble d’opérations au sein d’une même transaction. Si une transaction échoue, toutes les opérations réalisées sont annulées. Le datastore réalise ainsi des opérations atomiques.

Une des principales restrictions du datastore est l’obligation de ne manipuler dans une transaction qu’une seule entité ou un seul groupe d’entités.
Si vous ne respectez pas cette restriction, vous obtiendrez l’erreur suivante: javax.jdo.JDOFatalUserException: can't operate on multiple entity groups in a single transaction.

Voici un exemple (implémentation JDO) d’opération incorrecte qui génère une exception:

import java.util.List;
import javax.jdo.Query;
import javax.jdo.Transaction;
import javax.jdo.PersistenceManager;
// ...
// Example of a failing transaction ...
Transaction tx = getPersistenceManager().currentTransaction();
tx.begin();
Query query = getPersistenceManager().newQuery(FeedEntity.class);
List<FeedEntity> feeds =  (List<FeedEntity>) query.execute();
for (FeedEntity feedEntity : feeds) {
    // some operations
	feedEntity.setLastUpdateDate(new Date());
	getPersistenceManager().makePersistent(feedEntity);
	}
tx.commit();

Autre restriction : l’impossibilité de mettre à jour ou de créer plus d’une entité ou groupe d’entités au sein d’une transaction. En effet, les entités sont stockées dans des tablettes potentiellement différentes.
Enfin, Google avertit qu’une requête peut échouer dans certains cas : dépassement d’un quota, niveau de contention trop élevé ou encore nombre d’utilisateurs trop important.

Quotas

Bien que GAE soit gratuit, des quotas sont définis pour le datastore. Ils sont assez pénalisants. Ainsi, je vous conseille de ne pas les négliger. Google limite le nombre d’entités à 1000 par requête. Par ailleurs, une entité a une taille maximum fixée à 1 Mo. Enfin, le temps d’exécution d’une requête envoyée au serveur ne doit pas dépasser 30 secondes.

Conclusion

Avec GAE, oubliez les bonnes vieilles modélisations à la Merise ou UML. Dorénavant, vous manipulez des groupes d’entités, des root entity, ou encore des relations de type owned-unowed. Le data store impose de nombreuses contraintes, qui pourraient en rebuter plus d’un. Cependant, il faut garder à l’esprit les objectifs de Google : fournir une plateforme hautement disponible et scalable.
Bien que la persistance soit gérée via l’ORM DataNucleus, il est possible d’utiliser une API de bas de niveau. Cependant, très peu de documentation est fournie.
Suite à cette présentation plutôt théorique du datastore, j’aborderai prochainement la persistance dans GAE avec les implémentations JDO et JPA.

Liens utiles

• Documentation officielle
• Groupe de discussions officiel
• MapReduce Google Presentation
• Big Table Google documentation
• Wikipedia MapReduce

Dans ce billet, nous allons essayer d’évaluer ce framework en menant une étude comparative entre deux prototypes basés sur le même socle fonctionnel. Un premier prototype en JSF/EJB3/JPA et un deuxième se basant sur le même socle technique mais intégrant Seam. L’étude va porter sur plusieurs critères tel que la maturité de la solution, la pérennité, la complexité de mise en œuvre, le coût de développement etc.

Au programme :

• Présentation de Seam
• Le prototype ContactBook
• La solution JSF/EJB3/JPA
• La solution Seam
• Comparatif des deux solutions
  • Architecture applicative
  • Code technique
  • Délai et facilité de mise en œuvre
  • Solution
• Conclusion

Présentation de Seam

Seam est un framework JEE 5 dont la première version est sortie en décembre 2005. Il se base essentiellement sur les standards EJB3 et JSF pour construire des applications web. L’objectif principal de Seam consiste à éliminer la complexité tant au niveau de l’architecture que de l’interface de programmation (API). Il se base sur les annotations JDK 1.5 et sur l’utilisation des POJO conformément à l’évolution de JAVA EE 5.

Il offre de nombreuses avantages :

• Meilleure Intégration (JSF/EJB3/JPA).
• Nouveaux contextes : conversation, business process et page.
• Gestion automatique des composants de l’application.
• Intégration simple des flux de pages.
• Intégration simple de JBoss JBPM.
• Accès distant simplifié.

Ce framework offre de nombreuses facilités au niveau de la mise en œuvre des applications web, et se présente de plus en plus comme un futur standard. Pour les utilisateurs qui ne sont pas encore prêts à utiliser les EJB, Seam supporte également des classes POJO et des classes Hibernate comme composants.

Nous allons essayer de vérifier la pertinence des éléments avancées par les créateurs de Seam en menant une étude comparative entre deux prototypes, un se basant sur les EJB3 et JSF et un se basant sur le même socle technique mais utilisant Seam comme framework d’intégration des deux technologies.
Pour ceux qui veulent se documenter plus n’hésitez pas à consulter le billet suivant.

Le prototype ContactBook

Le prototype ContactBook est une application web de gestion des contacts. Son périmètre fonctionnel couvre les fonctionnalités essentielles d’une application de gestion. Ces fonctionnalités sont réparties en deux domaines :

• Gestion des utilisateurs.
• Gestion des contacts.

ContactBook est une application web relativement simple. Elle permet à un utilisateur de gérer ses contacts. Chaque utilisateur répond à un profil (nom, prénom, adresse mail et numéro de téléphone). Chaque utilisateur doit s’identifier auprès du système pour utiliser l’application ContactBook.

ContactBook est une application internationale. Un utilisateur doit pouvoir choisir sa langue « de travail ». Un mécanisme de changement de gestion multilingue est donc proposé à l’utilisateur. Deux langues sont proposées : l’anglais et le français. La langue par défaut est le français.

La solution JSF/EJB3/JPA

cette solution se base sur une architecture 3 tiers avec jsf pour la couche présentation, ejb3 pour la couche métier et jpa pour la couche des données.

La couche présentation est constituée d’un ensemble de composants JSF. Les JSF Backing Beans ou les Managed Beans sont utilisés pour faire le lien entre la couche présentation et la couche métier, ils permettent ainsi de récupérer les données saisies par les utilisateurs, les valider et les véhiculer à la couche métier. La couche métier est un ensemble de composants EJB session qui encapsulent le logique métier de l’application. Les EJB entités représentent le modèle des données. Ceux-ci seront directement persistés dans la base de données grâce à l’api de persistance utilisée.

La solution Seam

Cette solution se base sur les mêmes composants que l’architecture précédente mais utilise Seam comme framework d’intégration des différentes frameworks et technologies utilisés dans le projet.

La couche présentation est constituée d’un ensemble de composants JSF. Les EJB session jouent un double rôle puisqu’ils permettent l’échange des données entre la couche présentation et la couche métier, la validation des données, et la gestion des transactions et des sessions des utilisateurs. Les EJB entités représentent le modèle des données. Ceux-ci seront directement persistés dans la base de données grâce à l’api de persistance utilisée.

Comparatif des deux solutions

Architecture applicative

Pour commencer, nous allons mener une comparaison au niveau de l’architecture applicative des deux solutions proposées :

Notation : Faible(1), Moyen(2), Élevé(3), Excellent(4)

Les dépendances introduites dans le code technique par Seam, ainsi que le modèle d’architecture imposé par ce framework rend la réutilisation de ses composants très faible par rapport aux composants sans Seam qui sont réutilisables dans l’état.

Seam couvre la plupart des besoins techniques liés au développement d’une application web, ce qui permet de simplifier le développement avec JEE5. Seam fournit aussi des outils pour faciliter la vie des développeurs. Sans Seam les développeurs doivent prendre en charge tout les problèmes liés à l’intégration des différentes briques JEE5.

Il est plus difficile d’intégrer des composants réutilisables dans une application Seam, car il faut les convertir en composants Seam. Sans Seam nous avons moins de contraintes pour intégrer des composants réutilisables dans l’application.

Seam est un framework complexe qui nécessite un grand cout d’entrée, mais qui permet de résoudre beaucoup de problèmes liés à l’intégration des différents frameworks du marché. Seam nous facilite la tâche en s’intégrant parfaitement avec plusieurs frameworks et implémentations des spécifications JEE5 (EJB3, JSF, Spring, GWT, IceFaces …).

L’architecture de la solution Seam est moins souple que l’architecture de la solution JSF/EJB3/JPA, c’est à la fois un avantage et un inconvénient. Un avantage car il y a moins de problèmes à résoudre lors de l’implémentation de la solution. Un inconvénient car le choix de Seam peut être impactant par la suite. Par exemple il serait difficile de passer de JSF à un autre framework web qui n’est pas pris en charge par Seam, Ce qui freine l’évolutivité à long terme.

Code technique

Pour voir l’apport de l’intégration de Seam sur le code technique, nous avons utilisés le plugin Metrics pour calculer quelques
métriques :

Nous avons constaté que l’intégration de Seam a permis de réduire considérablement la quantité du code technique. Comme il n’y a pas de distinction entre un composant backing bean et un composant Seam. Une page JSF peut donc invoquer directement un composant Seam sans passer par un backing bean ce qui permet de supprimer le code technique des backing beans.

Seam fournit aussi des annotations pour JSF, le cycle de vie des composants, les exceptions, l’asynchronicité, le databinding, l’intégration avec plusieurs apis du monde JEE etc. Ces annotations permettent de produire un code élégant et très compact. Beaucoup prétendent que l’utilisation de Seam ne nécessite pas de configuration XML ce qui est faux, l’intégration des briques et des apis tierces avec Seam nécessitent leurs propres configurations.

Seam est un framework très productif qui permet de réduire considérablement la quantité du code technique nécessaire pour développer une application web mais les dépendances introduites par Seam rend le code technique difficile à maintenir et difficilement réutilisable sans Seam.

Délai et facilité de mise en œuvre

Cette comparaison va nous permettre de comparer les deux prototypes au niveau de la mise en œuvre :

Notation : Très Facile (1), Facile (2), Moyen (3), Difficile (4), Très difficile(5)

La préparation du projet Seam est très simple car nous avons utilisés l’outil seam-gen pour générer la structure du projet avec des exemples de code fonctionnel. Avec Seam, la configuration est fournie dans le projet générée avec seam-gen ce qui n’est pas le cas dans le projet EJB3-JSF. La cohabitation des différentes briques JEE est prise en charge par Seam. Les backing beans n’existent plus, les pages JSF invoquent directement les composants Seam. Sans Seam, il faut coder tout les backing beans et les mapper avec les pages JSF. C’est un cout de développement de plus pour les développeurs. Néanmoins, il ne faut pas oublier que Seam introduit ses propres dépendances dans votre code ce qui le rend moins évolutif et difficilement réutilisable dans d’autres projets qui n’utilisent pas Seam.

Solution

Pour comparer les deux solutions développées, nous allons nous baser sur des critères spécifiques aux frameworks de présentation et des critères généraux :

La solution JSF/EJB3/JPA

La solution Seam

Conclusion

Seam permet d’effondrer les couches artificielles entre la couche présentation et la couche métier. Il permet ainsi de rapprocher les composants métiers de la couche web.

Dans la solution JSF/EJB3/JPA, il est nécessaire d’utiliser des backing beans JSF pour lier la couche présentation à la couche métier. En Seam il n’y a plus de couches d’intégration, mais il faut voir les choses autrement car Seam s’appuie sur une architecture 2 tiers. Lorsque l’on a plusieurs niveaux, il est préférable de les séparer en plusieurs couches pour avoir une meilleure visibilité du code et une séparation des responsabilités. Un autre problème réside dans le fait que Seam introduit une forte dépendance entre les différentes couches de l’application.

Seam a apporté une vraie valeur ajoutée à notre projet JSF/EJB3/JPA et nous a permis de gagner en productivité. Toutefois, le modèle d’architecture imposé par Seam et les dépendances techniques introduites dans nos briques nous laissent à réfléchir, mais il reste une solution très envisageable pour développer des applications entreprises.

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

Le coin de la technique

• Sonar en version 1.5
• Version finale de Tapestry 5
• Première implémentation de la JSR 299 : Web Beans RI 1.0.0.ALPHA1

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

• JavaLobby fait une restrospective des articles les plus lus en 2008

Le coin de la technique

Sonar en version 1.5

SonarSource (spin off de la société Hortis dédiée au développement et au support de Sonar) a annoncé la sortie de la nouvelle version de Sonar.
Comme déjà présenté plus en détail sur ce blog, Sonar est un outil open source qui collecte, consolide et présente les données Qualité d’un projet.
Dans les nouvelles fonctionnalités, il est à noter une volonté d’ouverture de l’API :

• Récupération des mesures à partir de services REST.
• Possibilité d’écrire ses propres extensions via des plugins de collecte (voir le tutorial ici).

Des présentations graphiques des métriques et de l’évolution dans le temps ont été ajoutés :

• Suivi des règles sous forme de radar.
• Couverture de code présenté en nuages de classe.
• Amélioration de l’affichage des graphiques d’évolution du respects des règles (Time machine).

L’intégration avec les outils open source utilisés lors des collectes est aussi améliorée :

• Ajout des règles Findbugs portant à 600 le nombre de règles de codes contrôlables (de la simple règle de nommage à l’anti-pattern).
• Mise à jour des versions des plugins PMD et Clover.

La release s’accompagne aussi de son lot de corrections de bugs.
Pour plus de détails, voir la release note complète.

Sonar, avec cette nouvelle version, se positionne encore plus comme un incontournable dans la présentation de données liées à la qualité, loin devant le dashboard Maven.
De plus, la roadmap présentée sur le site de Sonar propose des fonctionnalités intéressantes comme le regroupement de projets, le positionnement d’alerte sur indicateurs ou encore l’association de règles différentes selon les projets …

Version finale de Tapestry 5

Comme nous l’a fait remarquer un de nos lecteurs, François Armand, Tapestry 5.0 est actuellement disponible en version finale.

Tapestry 5 a nécessité près de 3 ans de développement afin d’avoir les améliorations suivantes (par rapport à la version 4) :

• Amélioration du modèle de programmation de Tapestry afin de pouvoir développer des composants « Tapestry » sous forme de classe POJO
• Moins de configuration par XML, et plus de conventions de nommage (principe de CoC, Convention over Configuration), utilisation des nouveautés du langage Java 5 (annotation)
• Amélioration de la productivité des développements avec la recharge à chaud des classes Java en cours de développement.

Le rechargement à chaud de classe permet de ne plus avoir un cycle de développement suivant :

• Modification.
• Compilation de l’application.
• Packaging de l’application.
• Déploiement de l’application.
• Démarrage de l’application.
• Test de l’application.

Le cycle de développement suivant permet d’être plus productif car beaucoup plus court que le précédent :

• Modification d’une classe.
• Compilation de la classe.
• Rechargement de la classe dans le Classloader de l’application sans le redemarrage de l’application.
• Test de l’application.

Pour plus d’informations sur l’intérêt d’un cycle de développement allégé, je vous invite à découvrir ou redécouvrir l’article à propos de JavaRebel.

Je vous propose aussi à lire le commentaire de François sur notre blog, qui fait un tour d’horizon et un retour d’expérience sur Tapestry. Encore une fois, merci François.

Matt Raible (Raible Design) avec l’aide de Serge Eby, ont mis à jour AppFuse afin d’intégrer Tapestry 5. Ils notent d’ailleurs ce qu’ils apprécient dans Tapestry 5 : la configuration, qui est minimale, ainsi que les URLs claires. Pour plus d’informations sur AppFuse, voici une présentation du plugin : AppFuse par l’exemple.

Première implémentation de la JSR 299 : Web Beans RI 1.0.0.ALPHA1

A plusieurs reprises dans cette revue de presse, nous avons parlé de la spécification JSR 299, baptisée WebBeans :

• JSR-299 : Web Beans disponible en Public Review Draft.
• Seam 3 : les futures orientations de Seam.

Sur la page consacrée à WebBeans sur le site de Seam Framework, une release de WebBeans est maintenant disponible : Web Beans 1.0.0.ALPHA1 released!.

Pour être plus précis sur l’avenir conjoint de Seam et WebBeans : Seam ne va pas devenir WebBeans. Il y aura un noyau WebBeans, et Seam utilisera ce noyau.

Le noyau WebBeans prend en charge le contexte de gestion de composants « WebBeans » ainsi que les mécanismes d’injection de dépendance.

Ainsi Seam embarquera ces propres fonctionnalités :

• Seam Security.
• Rendu PDF / mail.
• Intégration de moteur de workflow (JBPM).
• etc …

Cette release est une première étape importante afin d’achever cette spécification JSR 299 avec une implémentation et sa documentation.
Cette première release vous permettra peut être d’avoir les idées plus claires sur cette spécification.

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

JavaLobby fait une restrospective des articles les plus lus en 2008

JavaLobby fait le bilan de l’année 2008 en nous montrant les 10 articles les plus lus ces 12 derniers mois. En tête, l’interview de John de Goes président de N-BRAIN qui avoue que les produits open source deviennent de redoutables concurrents et annonce le passage en open source de leur plateforme UNA.
Rick Hightower dont l’un des articles fait partie du top 10 nous fait remarquer dans un commentaire la répartition des résultats en fonction des frameworks.
Voici le résultat :

• deux articles sur JSF dans le top 5 montrent que JSF a toujours le vent en poupe. L’un de ces articles parle d’ailleurs de l’interfaçage JSF/Flex.
• deux articles sur JPA/Hibernate
• un article sur Spring.

Rick Hightower nous précise aussi que les résultats ne prennent pas en compte l’âge des articles. En effet la majorité de ces articles a été publiée avant le mois de Mai.
Globalement, il est intéressant de voir que les frameworks tels JSF et JPA sont toujours aussi populaires et qu’ils intéressent toujours autant les lecteurs.

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

• Dur dur d’être un (Java)Rebel

RIA

• Vidcast de Christophe Coenraets autour de Flex

Le coin de la technique

• Failles de sécurité dans Spring MVC
• Premier résultat SpecJVM2008, et alors ?
• Envers : JBoss ajoute à JPA le versioning des données
• JSR 203: More New I/O APIs for the Java Platform (« NIO.2″)
• L’avenir de la virtualisation et du cloud computing java selon Billy Newport

Actualité éditeurs / SSII

Dur dur d’être un (Java)Rebel

S’il n’est pas simple de faire connaître un outil, il est encore plus compliqué de le monétiser. ZeroTurnaround nous en fait la démonstration avec JavaRebel. C’est la fête à la licence : après les dons aux ceintures marrons de Java Black Belt, et aux membres de projets open-source, ZeroTurnaround offre cette fois ses licenses aux lecteurs de DZone (digg-like pour développeurs). Quelle sera la prochaine étape ? La gratuité pour les usages non commerciaux ?

JavaRebel est agent java permettant de recharger à la volée des modifications effectuées sur classes. A l’utilisation, le principe reste le même que celui du hotswap proposé out-of-the-box par la JVM Sun, offrant un rechargement plus complet.

RIA

Vidcast de Christophe Coenraets autour de Flex

A ceux qui ont raté James Ward au Paris JUG, InfoQ offre une seconde chance avec l’interview de Christophe Coenraets, lui aussi évangéliste Adobe, captée dans le cadre du QCon 2008 de Londres.
Dans cette vidéo, Christophe Coenraets aborde les points suivants :

• Les technologies RIA Abode : Flex 3, Air et BlazeDs
• L’environnement de développement d’abode, FlexBuilder 3
• La stratégie open-source d’Adobe
• L’introduction d’un front-end Flex dans un SI existant
• L’avenir des RIA à travers leur intégration aux moteurs de recherche et aux navigateurs internet

Une bonne façon de se remettre rapidement à jour si vous avez raté les derniers développements de la percée d’Adobe sur le marché des clients riches.

Le coin de la technique

Failles de sécurité dans Spring MVC

La nouvelle est assez rare pour que tout le monde s’en empare (TSS, techtarget, net-security.org, xtremeopensource.org, linux mag, …), Ounce Labs annonce la découverte de problèmes dans Spring MVC pouvant causer des failles de sécurité dans les applications utilisant ce framework, en voici les descriptions :

1. Soumission de champs de formulaire non éditables. Si votre modèle contient plus de champs que votre formulaire HTML, il est possible d’envoyer une fausse requête contenant des données non éditables.
2. Injection Modèle/Vue. Ce problème arrive lorsque le rendering utilise un nom de vue provenant directement d’une requête. Si ces noms mappent certaines ressources protégées par le serveur d’applications, il est alors possible, dans certains cas, d’y accéder.

Ces deux vulnérabilités sont connues depuis longtemps par Spring Source, qui vient de publier une Spring MVC vulnerability FAQ à ce sujet. Il ne s’agit pas de véritables bugs, mais plus d’un mauvais usage du framework. Cela ressemble plus à une opération publicitaire de Ounce Labs qu’à une véritable alerte ; ce coup d’éclat a tout de même le mérite de nous rappeler la difficulté des développements web et le dilemme permanent des frameworks web qui sont écartelés entre l’ajout de fonctionnalités et la sécurité. Les approches actuelles zéro-confs sont à ce titre bien dangereuses.

Premier résultat SpecJVM2008, et alors ?

David Dagastine annonce dans First SPECjvm2008 Result Published! que Sun a publié le premier résultat de ce benchmark de JVM. Cependant, nous pouvons nous interroger sur le rôle qu’a aujourd’hui un tel benchmark dans le choix d’une JVM alors que les machines virtuelles d’IBM (J9), d’Oracle-BEA (Jrockit) et de Sun (Hotspot) qui ont aussi bonne presse sur ce sujet. Le critère de l’exploitabilité de la JVM, aujourd’hui très en vogue avec la médiatisation de VisualVM (Sun), ne semble pas plus pris en compte aujourd’hui alors que des écarts importants subsistent entre les éditeurs et qu’Oracle-BEA a de sérieux atouts différenciant avec son très mature JRockit Mission Control.

En fait, les JVM sont devenues des commodités et le critère de choix relève aujourd’hui plus de l’écosystème et particulièrement du serveur d’applications Java. Un utilisateur de Websphere devra utiliser J9 [1], un utilisateur de Weblogic aura le choix entre JRockit et Hotspot et les autres utilisateurs (Tomcat, JBoss, etc) se tournent le plus souvent vers le standard de facto : l’implémentation de Sun.

Nous noterons un point intéressant sur SpecJVM2008 : le benchmark se fait sans aucun tuning de la JVM. Cette règle illustre la tendance actuelle des éditeurs de JVM qui fournissent des machines virtuelles optimales en configuration par défaut grâce à des mécanismes de détection de la configuration de l’OS et d’optimisation automatique à l’exécution.

[1] sauf sur les plateformes sur lesquelles IBM n’a pas porté J9 et où il propose alors Hotspot (Solaris, HP UX)

Envers : JBoss ajoute à JPA le versioning des données

Trois mois après l’annonce d’une preview, Adam Warski propose aujourd’hui la version 1.0 de JBoss Envers, une extension à JPA pour versioner les données, un sujet fréquent dans l’informatique de gestion des contrats. L’occasion pour JBoss de réaffirmer sa place de leader de l’innovation autour de JPA.

Les points clefs de JBoss Envers :

• Versioning de propriétés simples (strings, integers, longs…) comme des composants embedded (eux même composés de propriétés simples)
• Versioning de classes aux ids simples, composites ou _embedded_
• Versioning des relations one-to-one et one-to-many
• Listener de révision @RevisionEntity pour notamment ajouter des modifications spécifiques aux entités versionées
• Historisation par numéro de version (@RevisionNumber) ou à date (@RevisionTimestamp)
• Requête sur les données historiées avec un VersionsReader
• Envers repose sur l’EntityManager JPA plutôt que la Session Hibernate, on peut y voir un signe supplémentaire pour migrer des API propriétaires d’Hibernate vers celles standard de JPA.

Exemple de classe versionnée avec Envers :

@Entity
@RevisionEntity(MyRevisionListener.class)
public class Person {
    @Id
    @GeneratedValue
    Integer id;
    @Versioned
    String name;
    @Versioned
    String surname;
    @Versioned
    @ManyToOne
    Address address;
    @RevisionTimestamp
    long revisionTimestamp;
   ...
}

Pour plus d’informations sur ce sujet, nous aimons Patterns for things that change with time de Martin Fowler.

JSR 203: More New I/O APIs for the Java Platform (« NIO.2″)

Si NIO 1 mettait l’accent sur la scalabilité, JSR 203 – NIO 2 se focalisera sur l’utilisabilité des différents systèmes de fichiers comme Alan Bateman (Sun) et Carl Quinn (Google) l’ont expliqué à JavaOne dans « New I/O in JDK 7″. Les points clefs de NIO 2 :

• Nouvelle API d’abstraction de système de fichier (FileSystem, Path / FileRef et FileStore) et notamment l’amélioration de la navigation dans les arborescences.
• Unification des API Channel et Socket avec une abstraction système de fichier sous-jacent.
• Amélioration des I/O asynchrones.
• Correction de bugs qui trainaient de longue date des les API I/O

Dans la continuité, Elliotte Rusty Harold détaille dans The Open Road: java.nio.file le fonctionnement de la nouvelle abstraction du système de fichier.

Pour plus d’informations sur les nouveautés de Java 7 :

• Nagez avec les dauphins ! JDK 7 proposals overview
• JSR 294 – Les Superpackages
• GC générationnels traditionnels (jdk6) vs. GC Garbage First (jdk7)

L’avenir de la virtualisation et du cloud computing java selon Billy Newport

Billy Newport, Websphere eXtreme Scale, explique dans une interview à Floyd Marinescu, InfoQ sa vision de la virtualisation et du cloud computing en Java.

Nous retiendrons :

• Pour les applications Java, la virtualisation de la couche physique (processeur, mémoire, etc) tend vers la gestion de grappes de petits serveurs virtuels à ressources fixes (e.g. 4 ways, 2 Go de RAM, 160 Go de disque) plutôt que vers des serveurs de grande capacité à ressources variables : il est très difficile d’optimiser les performances de gros serveurs (e.g. 32+ cores/ways, 10+ Go de RAM, etc) et les programmes ont le plus grand mal à se réadapter (e.g. pool de threads, taille de cache) quand les ressources allouées changent
• Des serveurs à plusieurs dizaines de cores arriveront plus vite que nous le pensons et les éditeurs de JVM s’y préparent, mais les JVM et les APIs de concurrence ne sont aujourd’hui pas prêtes. Par exemple, les pattern multi-reader/mono-writer ne seront plus adaptés.
• Les grilles de données n’ont pas besoin d’API spécifiques pour le moment : JPA et JMS suffisent aux besoins actuels. Par ailleurs, l’API JSR-107: JCache suscite des réticences de la part des grands éditeurs de grilles java et ne verra probablement jamais le jour.
• La virtualisation des données se divise en deux grande familles :
  • Network Attached Cache : le paradigme de programmation est le même qu’en l’absence de cache. Typiquement positionné en cache L2 d’un framework JPA, les données du cache sont rapatriées sur le serveur d’applications pour réaliser les traitements métiers, mais ce modèle atteint ses limites avec le coût de rapatriement des données.
  • eXtreme Transaction Processing Grid : le paradigme de de programmation change complètement ; le traitement métier, au lieu d’être réalisé sur le serveur d’applications, est envoyé sur tous les noeuds de la grille, seule la consolidation est effectuée sur le serveur d’applications. Cette architecture scale jusqu’à plusieurs milliers de noeuds sur la grille.
• Les SGBD, avec la co-localisation des données, ont atteint leur limite de scalabilité. IBM comme Oracle ou Microsoft investissent aujourd’hui dans les data grids pour lever cette limite (respectivement eXtreme Scale, Coherence et Velocity).

Agilité

• Le top 20 des livres sur l’Agilité

RIA

• NASDAQ Market Replay : une success story pour Flex, AIR et Amazon S3

Le coin de la technique

• Spring Source Application Platform : l’heure de se faire une opinion ?
• JPA 2.0, la nouvelle version d’une API bien portante
• Language Java, que faut-il attendre ?

Agilité

Le top 20 des livres sur l’Agilité

A partir de son top 100 des meilleurs livres d’ingénierie logicielle, Jurgen Appelo en a extrait le top 20 des livres sur l’Agilité.
Voici les 3 premiers pour les moins courageux :
1. Agile Software Development: Principles, Patterns and Practices de Robert C. Martin
2. Refactoring: Improving the Design of Existing Code de Martin Fowler
3. Agile Estimating and Planning de Mike Cohn

Une liste qui pourra vous guider dans vos prochains achats sur Amazon !

RIA

NASDAQ Market Replay : une success story pour Flex, AIR et Amazon S3

InfoQ explique dans InfoQ Case Study: NASDAQ Market Replay comment le NASDAQ offre un outil de rejeu des transactions effectuées (vérification de la validité d’une transaction, explication de l’écart entre le prix de vente espéré et le prix de vente réel, etc…) développé en FLEX avec un client standalone Abode AIR et connecté à un back end Amazon Simple Storage Service (S3).
La mise en place de cet outil est un véritable succès pour le RIA d’Abode, car il a été bâti en 6 mois par une équipe de 10 personnes, et répond complètement aux besoins fonctionnels, avec des performances supérieures à celles espérées.
De plus, un premier lot d’évolutions devrait voir le jour dans moins d’un mois, et son déploiement sera grandement facilité par l’utilisation de la technologie AIR (déploiement automatique par vérification de la dernière version en cours au lancement de l’outil).
Une démonstration de l’outil est disponible sur le site du NASDAQ.

Le coin de la technique

Spring Source Application Platform : l’heure de se faire une opinion ?

Julien Dubois, directeur de Spring Source France, a présenté Spring Source Application Platform (S2AP) lors de la soirée Spring du Paris JUG. Nous avions relaté en mai dernier la sortie du serveur hybride OSGI-Tomcat dans SpringSource Application Platform : la brèche dans Java EE. L’événement avait fait grand bruit, The Server Side avait lancé la polémique avec S2AP – totally rocks (220 messages enflammés). Si le buzz est retombé, Spring Source occupe le terrain médiatique pour nous faire patienter jusqu’à la première release avec des articles pédagogiques sur la valeur ajoutée des modules OSGI pour les applications web (Why should I care about OSGi anyway? par Adrian Colyer) autant que sur la nouvelle stratégie de Spring Source (Open Source, Open Strategy: The SpringSource Manifesto par Rod Johnson).

Au-delà des promesses un zest marketing du site officiel qui vont de l’amélioration de la réutilisabilité du code à la meilleure disponibilité des serveurs en passant par la reconfiguration à chaud, l’été peut-être l’occasion de regarder plus en détail la proposition de Spring Source.

Pour mémoire, S2AP est un serveur d’applications orienté modules basé sur OSGI Eclipse Equinox, dm-Kernel (Spring Source Dynamic Module Kernel), et Tomcat.

Le but de la présentation de jeudi dernier était autant de faire connaître le produit (après un rapide sondage avec l’assemblée, un peu plus la moitié du public connaissait s2ap) que de rassurer d’éventuels futurs utilisateurs sur la capacité de cette plateforme à aller rapidement en production. C’est d’ailleurs sur ce dernier point que Julien a insisté lors de la présentation au Jug : il ne faut pas oublier qu’il s’agit pour le moment que d’une béta.

L’administration de la plateforme s’effectue par l’intermédiaire : d’une web console ultra light (pour le moment). Celle-ci dispose d’un simple champ ‘Parcourir …’ vous permettant d’uploader vos bundles et de la liste des applications déployées disposant chacune d’un lien ‘undeploy’. (cf screenshot 2) ; et d’une console Osgi Equinox accessible via Telnet (cf screenshot 3). Si cela ne vous convient pas, rien ne vous empêche d’installer une console OSGI complémentaire plus conviviale du type knopflerfish .

Petit problème anecdotique à ce sujet noté sur la console Equinox : si vous voulez vous déconnecter, utilisez la commande ‘disconnect’, celle-ci vous demandera alors si vous êtes certain de vouloir quitter la console. Par contre si vous tapez la commande ‘exit’, le serveur est immédiatement arrêté sans aucun message de confirmation.

Après plus d’un mois de teasing en tout genre, vous n’avez peut-être pas encore eu le temps de vous faire une idée concrète du produit. C’est peut-être le moment de passer à l’action. Nous vous proposons ici une liste de liens permettant d’effectuer votre propre « Getting Started S2AP » rapidement :

• Téléchargez la dernière bêta S2AP en vous inscrivant sur Spring Source, user guide, programmer guide
• Téléchargez une application exemple
• Consultez le Repository officiel de bundles compatibles S2AP
• Tutoriel d’installation et d’utilisation rapide pour les développements

Screenshot 1 : S2AP startup	Screenshot 2 : Web Console	Screenshot 3 : Equinox Telnet Console

JPA 2.0, la nouvelle version d’une API bien portante

Il est loin le temps où le standard de persistance en Java, les EJB CMP, était conspué. JPA a refermé cette page tourmentée en créant un consensus autour du meilleur d’Hibernate, de TopLink et des autres.
Linda DeMichiel, Sun Microsystems, a présenté à JavaOne 2008 dans JavaTM Persistence API 2.0 les contours d’une nouvelle version largement inspirée d’Hibernate.

Nous retiendrons :

• Améliorations des mappings : collections de types basics avec @ElementCollection, supports amélioré des types @Embeddable, des tris et des Map, etc.
• Ajout d’une Criteria query API que regrettaient les adeptes d’Hibernate
• Intégration du mécanisme de validation JSR 303: Bean Validation dont le specification leader n’est autre qu’Emmanuel Bernard, Red Hat, également project leader d’Hibernate Validator

Cette ébauche de JPA 2.0 est l’occasion de rappeler qu’il est maintenant raisonnable de migrer de l’historique API Session d’Hibernate à l’API EntityManager de JPA. Cette dernière répond à la majorité des besoins de nos projets et il suffit de récupérer la session Hibernate avec ((Session) entityManager.getDelegate()) si le besoin s’en fait sentir.

Language Java, que faut-il attendre ?

Alex Buckley (Sun), Neal Gafter (Google) et Michael D. Ernst (MIT) ont présenté à JavaOne 2008 dans Upcoming Java Programming Language Features les enjeux de l’évolution du langage Java et les nouvelles fonctionnalités actuellement à l’étude :

• Multi-catch try {...} catch (E1, E2 e) {...}
• Safe re-throw : simplification des blocs catch lorsque la méthode encapsulante rethrow les exceptions levées dans le bloc try
• Modularité : Ajout d’un niveau de granularité entre les visibilités package et public
• Extension des annotations pour ne plus limiter leur utilisation aux déclarations de class / method / field / variable et pour ajouter des informations dans le code telles que @NonNull, @Readonly ou @Immutable. Ces évolutions sont regroupées dans JSR 308: Annotations on Java Types.

A plus long terme, l’Expert Group réfléchit entre autres à un meilleur support du parallélisme et une évolution du modèle de composant (versioning, etc). Plus généralement, d’autres sucs syntaxiques et évolutions du langage sont à l’étude, nous en avions consacré une partie à ce sujet lors de la présentation ‘jdk 7 proposals‘ en février dernier.

Actualité éditeurs / SSII

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

Agilité

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

Le coin de la technique

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

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

• XKE, le programme de la session de mai

Actualité éditeurs / SSII

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

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

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

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

TSS : MySQL to get new features in Enterprise version

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

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

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

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

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

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

Agilité

User stories « En tant que … je veux … »

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

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

Le coin de la technique

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

JSR-311 JAX-RS REST une histoire de RESTaurant

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

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

XKE, le programme de la session de mai

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

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

• Technique
  • Java et la Cryptographie

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

• Xebia Hollande
  • Intervention du CTO de Xebia Hollande

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

Actualité éditeurs / SSII

• EclipseLink devient l’implémentation de référence pour JPA 2.0
• Eclipse Foundation lance Eclipse Runtime Project
• SpringSource Tool Suite
• BlackBerry rejoint la fondation Eclipse
• Bea renforce son intégration avec Eclipse

Le coin de la technique

• La puissance des proxies

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

• Tours Java User Group

Actualité éditeurs / SSII

EclipseLink devient l’implémentation de référence pour JPA 2.0

Sun vient d’annoncer récemment que la RI (reference implemention) de la Java Persistence API 2.0, sera le plugin d’Oracle EclipseLink.
Le framework EclipseLink fournit à travers ses services OSGi l’outillage nécessaire pour interagir efficacement avec les bases de données relationnelles :

• JPA
  Ce service permet de mapper des objets Java avec un schéma de base de données en utilisant une configuration XML et/ou avec les annotations. Les opérations de mapping, transactions, cache des objets, clustering, et des options de tuning et administration sont également disponibles nativement.
• Mapping Objects to XML (MOXy)
  Ce service gère le mapping objets Java avec un schéma XML (XSD) en utilisant une configuration XML et/ou avec les annotations. Ce service permet de générer par exemple, à partir d’un modèle de données annoté, les XSD et mappings correspondants. Les opérations de transformation Java->XML et XML->Java sont également supportées via les standards DOM et SAX.
• Service Data Object (SDO)
  Ce service permet de générer des modèles SDO dynamiques ou statiques à partir d’un schéma XSD. Les SDO permet de réduire le couplage entre application et les systèmes de gestion de données. ce service permettra également de wrapper un objet Java (JPA entity) dans un DataObject permettant d’utiliser des objets de modèle existants.
• Database Web Services (DBWS)
  Ce service permet d’exposer sous forme de webservices les opérations sur les base de données.
• Enterprise Information Systems (EIS)
  Le service de persistance EIS permet d’utiliser les magasins de données (data stores) via le connecteurs JCA (Java Connector Architecture). Ce service permet l’utilisation de base de données non-relationnelles qui n’utilisent pas l’accès JDBC ou SQL (Mainframes).

Avec l’annonce en parallèle du projet Eclipse RT basé sur Equinox, OSGi a de beaux jours devant lui !

http://www.eclipse.org/eclipselink/
http://www.theserverside.com/news/thread.tss?thread_id=48757

Eclipse Foundation lance Eclipse Runtime Project

Le projet Eclipse RT veut concurrencer Java et .Net !

Basé sur le projet Equinox qui implémente les spécifications OSGi, Eclipse Runtime Project veut devenir le nouveau runtime universel multi-plateforme pour carrément supplanter Java et .Net. Ce meta-projet a pour but d’unifier les différents projets existants tels que Eclipse Communications Framework, EclipseLink, Rich Ajax Platform (RAP), Riena and Swordfish et ainsi offrir une solution globale pour le développement d’applications sur divers supports et plateformes (client lourd, léger, riche, mobile, …) et ainsi combler les lacunes de Java et .Net. La solution apportée par Eclipse RT consiste en un modèle et framework orienté composant pour simplifier le travail de développement, déploiement et gestion d’applications sur diverses plateforme sans avoir à reconstruire la logique métier à chaque fois.

http://blogs.zdnet.com/open-source/?p=2136
http://www.infoworld.com/article/08/03/16/eclipse-show_1.html
http://www.regdeveloper.co.uk/2008/03/17/eclipse_equinox_runtime/

SpringSource Tool Suite

SpringSource vient d’annoncer la sortie en version béta « SpringSource Tool Suite ». L’objectif de cet outil est de faciliter le développement d’applications avec Spring. Le détail des possibilités n’est pas encore pleinement clair (Plus de détails ici). Vous pouvez vous inscrire au programme de béta-test pour tester ce nouvel outil ici.

BlackBerry rejoint la fondation Eclipse

La société Blackberry rejoint la fondation Eclipse et offre à cette occasion un plug-in Eclipse permettant de développer des applications pour la célèbre plateforme de téléphone mobile. Il est donc maintenant possible de développer pour les systèmes mobiles BlackBerry, Android, Symbian & Palm avec un environnement Eclipse standard bien connu des développeurs. Deux plateformes manquent à l’appel : Windows Mobile et l’iPhone peu habituées à faciliter le travail des développeurs maisons

Plus d’informations sur cette annonce ici

Bea renforce son intégration avec Eclipse

JRockit, la JVM de BEA, fournit déjà une console de suivi dénommé JRockit Mission Control. Depuis la version 2, cet outil est basé sur une plateforme Eclipse mais récemment Bea a fait un pas de plus. Depuis la version 3.0.2, JRockit Mission Control est disponible sous forme de plugin Eclipse accessible depuis l’ « update site » de Bea. Ceci va permettre une unification et une meilleure intégration de l’outillage (notamment Workshop) fourni par Bea.

Quelques détails sur le blog dev2dev …

Le coin de la technique

La puissance des proxies

Cet article illustre l’utilisation des proxies Java. Même si l’utilisation qui en est faite ici, peut être un peu discutable en terme de lisibilité, cela n’en reste pas moins impressionnant quant aux possibilités offertes.

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

Tours Java User Group

L’idée d’Antonio Goncalves et David Dewalle semble faire des émules. Après la création récente du Paris User Group, le deuxième Java User Group français vient de se créer : le Tours JUG. Son fonctionnement reste à peu près similaire, un sujet sera abordé chaque second mercredi du mois. Ce sera Christophe Jollivet, fondateur de ce dernier, et coresponsable de la rubrique java de developpez.com qui ouvrira le bal le 9 avril avec ‘Unitils et Selenium, les partenaires de vos tests‘ (ça me rappelle quelque chose …). Concernant la suite du programme, peu d’éléments sont pour le moment communiqués. Pour en savoir davantage, le mieux reste encore de vous inscrire pour la soirée d’inauguration qui aura lieu le mercredi 9 avril à Tours.

Agilité

• 3 bonnes résolutions pour cette nouvelle année
• Top 5 developer benefits of agile development

RIA

• BEA Workshop et Flex Builder en bundle
• Google sait indexer le contenu Flash

Le coin de la technique

• Rapide présentation de Hermes JMS Console
• Slice your database, OpenJPA
• Polémique sur l’avenir de Geronimo. IBM abandonne-t-il le projet ?
• Présentation de certains algorithmes de garbage collection de la JVM de Sun

Agilité

3 bonnes résolutions pour cette nouvelle année

Un agiliste propose des bonnes résolutions pour les équipes agiles. Peut-être que vos bonnes résolutions de cette année devraient déjà être de passer aux méthodes agiles …

Top 5 developer benefits of agile development

Cet article présente les 5 principaux bénéfices des développements agiles sur les équipes de développements :

• Un lien plus étroit avec les clients : l’équipe est en contact direct avec les clients et de ce fait, la qualité du produit mis en place est plus en accord avec les attentes des clients.
• Une équipe plus autonome : c’est à l’équipe de décider comment réaliser le sprint. Le but est de faire confiance aux équipes de développement et de leur donner plus de responsabilités.
• Laisser l’équipe prendre des décisions : lorsque des problèmes trop complexes se présentent, il est préférable de laisser les personnes plus à même de comprendre les impacts d’une évolution ou d’un changement prendre les décisions.
• Améliorer la participation de l’équipe : favoriser la constitution de petites équipes (7 personnes environ) permet aux différents membres de participer.
• Des développeurs plus productifs : la mise en place des méthodes agiles permet d’avoir des développeurs plus épanouis dans leur travail, car ceux-ci sont plus valorisés.

Pour finir, les méthodes agiles entraînent certains changements et entre autre, dans le cas de cet article, la confiance envers les équipes de développements doit être plus grande. En conclusion de ces méthodes agiles, il en résulte que les clients sont mieux satisfaits, et avec un produit de qualité.

RIA

BEA Workshop et Flex Builder en bundle

Nous apprenons dans cet articleque BEA propose sur son site un bundle spécial comprenant son IDE Workshop et l’IDE Flex Builder d’Adobe. Aucune information en revanche le support apporter par BEA sur l’IDE ou sur la technologie Flex.
Flex semble être adopté par certains éditeurs du monde Java/J2EE, Oracle en Novembre dernier lors de son « Oracle OpenWorld » avait déjà présenté plusieurs utilisations maison de Flex.

Google sait indexer le contenu Flash

Ce n’est pas un fait très connu, mais oui Google sait indexer les fichiers Flash! Une recherche sur Google sur le type de fichier « swf » permet de s’en assurer: près de 23 millions de fichiers indexés. En revanche, Google n’indexe que le contenu statique, en « dur » dans le code. Donc pas d’indexation pour les boutiques en ligne développées en Flex… Mais de nouvelles possibilités se profilent à l’horizon, d’après cet article sur le blog CNET, Google utilise désormais le Search Engine SDK d’Adobe pour parser les fichiers Flash. Ce qui signifie deux choses:

• les développeurs vont pouvoir utiliser le Search Engine SDK pour optimiser le référencement de leurs fichiers Flash
• pour peu qu’Adobe mette à jour son outil, on peut espérer dans un futur proche avoir la possibilité de référencer des applications Flex sans avoir à recourir à des techniques un peu barbares (copie statique HTML du contenu de l’application Flex par exemple…)

Le coin de la technique

Rapide présentation de Hermes JMS Console

Sur le blog Dev2Dev de BEA, on peut actuellement trouver une rapide présentation de Hermes JMS Console. Cette petite console est bien pratique pour explorer des files JMS et devrait faire partie de la trousse de base des développeurs. Pour la tester, c’est ici que ça se passe.

Slice your database, OpenJPA

Pinaki Poddar, employé BEA et committer sur le projet Apache OpenJPA présente Slice [1] , une extension d’OpenJPA qui permet un partitionnement horizontal multi-instances des bases de données (aka database sharding).

Si Slice est fonctionnellement un concurrent direct d’Hibernate Shards, ce n’est encore qu’un ‘proof-of-concept’ développé par une seule personne dans un sous projet de l’Apache Lab Fluid (« JPA for Service Data Object »).
Nous sommes très loin d’une version release (les règles des Apache Labs stipulent qu’un lab ne peut pas faire de release) et on regrettera que Slice n’ait pas été développé en tant que sous-projet d’OpenJPA pour lui assurer un avenir plus certain.

Pour ceux qui espèrent voir OpenJPA s’étoffer pour concurrencer Hibernate, il faudra hélas patienter.

Nous en profitons pour émettre un voeu pour 2008 : l’intégration d’OpenJPA au moteur de recherche Lucene pour rivaliser avec Hibernate Search ; ce besoin est sûrement moins ‘hype’ que la ‘database sharding’ mais beaucoup proche des réalités de nos projets d’informatique de gestion.

[1] Ressources complémentaire sur BEA Dev2dev Blog : Slice : OpenJPA for Distributed databases part I and Part II.

Polémique sur l’avenir de Geronimo. IBM abandonne-t-il le projet ?

The Server Side (TSS) commence l’année 2008 avec la très belle polémique Geronimo: Are its days numbered ?. Le résultat est là. Plus de 50 commentaires souvent acerbes, un grande séance de ‘websphere bashing’ toujours aussi peu argumentée ; de la vraie polémique The Server Side

Après s’être bien amusé avec le sensationnalisme de TSS, revenons sur les faits.

Le serveur J2EE Open Source Apache Geronimo a été lancé en 2003, époque à laquelle le serveur open source JBoss faisait frémir les éditeurs commerciaux qui voyaient en lui un concurrent très menaçant et d’un type nouveau auquel il n’avaient pas l’habitude d’être confronté.

A l’époque, les branches système d’exploitation et environnement de développement d’IBM avaient déjà adressé des concurrents open source (Linux et Sun NetBeans) en promouvant des alternatives elles aussi open source (Linux et Eclipse). Cette approche de type « quitte à ce que quelqu’un scie la branche sur laquelle je suis assis, autant que ce soit moi pour que j’anticipe mieux » a permis à IBM de très bien se placer sur Linux et de devenir l’acteur clef de la gouvernance du socle de développement aujourd’hui quasi-universel qu’est Eclipse.

IBM a racheté en 2005 GlueCode, la société fondatrice de Geronimo, et on peut voir dans cette stratégie des similarités avec la gestion par Big Blue des enjeux Linux et Eclipse.

La suite des événements est elle, en revanche, légèrement différente mais pas moins à l’avantage d’IBM :

• JBoss n’a pas balayé les serveurs d’applications commerciaux comme le prédisait Marc Fleury, son virulent fondateur.
• JBoss, racheté par RedHat en 2006, est progressivement devenu un concurrent ‘classique’ pour les éditeurs commerciaux.
• BEA, le principal concurrent d’IBM sur le marché des serveurs d’applications, connaît des rumeurs récurrentes de rachat (cf. Oracle announces bid to buy BEA).
• Le serveur commercial d’IBM, Websphere Application Server, connaît une croissance forte et des parts de marché très solides chez ses clients.
• Les serveurs J2EE commerciaux comme open source rencontrent aujourd’hui un nouveau type de concurrence : les simples moteurs de servlet comme Tomcat (cf Is it a Tomcat, or the Elephant in the Room? par Rod Johnson, fondateur de Spring Framework).

JBoss et les serveurs J2EE open source ne sont plus aujourd’hui des concurrents aussi menaçant qu’ils ne l’étaient lors du rachat de Glue Code ; il n’est donc pas étonnant que l’engagement d’IBM sur Geronimo semble aujourd’hui moins intense. Il ne s’agit pas d’un abandon mais juste d’un focus moins important.

Parallèlement, fort de ses succès auprès de ses clients, IBM poursuit ses investissements massifs sur sa stack commerciale Websphere Application Server qui sert de socle à Websphere ESB et Websphere Process Server.

Qu’y a-t-il d’anormal à voir une entreprise ne pas « mettre tous ses oeufs dans le même panier » et réajuster sa stratégie en fonction du marché ?

Présentation de certains algorithmes de garbage collection de la JVM de Sun

Il est toujours intéressant de se pencher sur le fonctionnement du garbage collector de la machine virtuelle. Il faut cependant garder en tête que l’optimisation par changement d’algorithme de garbage collection ne fait pas de miracle : l’optimisation d’une application métier passe bien généralement d’abord par l’optimisation du code en lui-même.