Revue de presse

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

Actualité éditeurs / SSII

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.

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.

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

Billets sur le même thème :

3 commentaires

  • petite précision, c’est la version 7.1 de JBoss AS qui implémentera le « full profile ». La version 7.0 implémente uniquement le web profile.

    cf : http://community.jboss.org/blogs/mark.little/2011/07/12/jbossas-70-is-here
    « And full EE6 is next on the roadmap, with JBossAS 7.1 due out soon. »

  • citation: Les limitations les plus notables sont l’absence de support pour HBase et Hive.

    Solution pour hive dans oozie:
    http://archive.cloudera.com/cdh/3/oozie/DG_HiveActionExtension.html

    Solutions pour hbase dans oozie:
    Lorsqu’on cherche à faire une action custom, on peut utiliser une action Java. Elle sera distribuée (en 1 seule instance) comme un Mapper.
    L’autre approche (si il y a un besoin de scalabilité sur cette action spécifique) est d’implémenter un MapReduce.

    Les limitations habituellement exprimées sur les mailing list oozie sont plutôt dirigées vers les limitations des SLA dans les coordiateurs de workflow et le manque d’action d’envoi de mail pour la gestion d’erreur (en cours d’implémentation). Un workaround est d’utiliser nagios, mais cela implique un effort conséquent.

  • Merci pour ce rectificatif.

    De la même manière, on notera également le support de Sqoop.
    http://archive.cloudera.com/cdh/3/oozie/DG_SqoopActionExtension.html

    Il est ainsi possible avec Oozie de construire un workflow avec un import de données depuis une base de données relationnelle qui alimentera des requêtes Hive. Tout cela avec des points de décision, en parallèle ou en séquentiel selon les besoins.

Laisser un commentaire