Revue de presse Xebia

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

Actualité éditeurs / SSII

Le coin de la technique

Actualité éditeurs / SSII

JBoss veut son DataGrid

Le projet JBoss Infinispan a été initié il y a peu. Il vient de produire deux versions alpha successives. Il s’agit d’une réécriture majeure du projet JBoss Cache auquel il succède et qu’il est destiné à remplacer. Le but premier affiché par ce projet est de produire une solution de DataGrid, là où son prédécesseur n’offrait qu’une technologie de cache distribué. L’ambition est forte, puisqu’il s’agit de se positionner sur un marché dominé par les solutions commerciales que sont Oracle Coherence et IBM eXtreme Scale.

Une récente interview de Manik Surtani, project leader d’Infinispan et JBoss Cache, associée aux informations diffusées sur le site d’Infinispan, permet de mieux répondre aux différentes questions que l’introduction de ce nouveau projet peut soulever :

  • Parmi les atouts prévisionnels d’Infinispan (après sa finalisation) face à Oracle Coherence, Manik Surtani met surtout en avant la nature Open Source, LGPL, de son projet. Il souligne toutefois la richesse d’Infinispan tant dans le domaine des performances (grâce à une implémentation efficace du MVCC locking) que des fonctionnalités (intégration simplifiée à Amazon EC2 et S3, compatibilité serveur Memcached).
  • La création d’un nouveau projet et donc d’un nouveau nom plutôt que le maintien de JBoss Cache est justifiée pour l’équipe par la réécriture et les changements d’API. On peut aussi aisément imaginer que le nouveau positionnement ‘DataGrid’ ne coïncidait guère avec un nom de projet ‘Cache’…
  • Infinispan pourra être utilisé en tant que cache Hibernate, ce qui est assez logique compte tenu de l’affiliation JBoss de ce dernier.

Face à des concurrents commerciaux bien installés sur ce marché, la tâche ne sera pas aisée pour JBoss, et le but affiché de proposer une solution équivalente à Coherence est très audacieux compte-tenu de la maturité acquise par ce produit. Ce scénario n’est pas sans rappeler le positionnement qu’avait JBoss AS lors de son arrivée sur le marché des serveurs d’application, mais l’absence de roadmap datée pour Infinispan tend à indiquer qu’il faudra probablement s’armer de patience pour savoir si l’histoire se répétera.

SpringSource renforce (encore) le lien développement / production

SpringSource a annoncé aujourd’hui le rachat de Hyperic, l’éditeur du célèbre outil de supervision du même nom.
Le partenariat SpringSource / Hyperic ne date pas d’hier (SpringSource redistribuait une version améliorée du serveur Hyperic dans son produit SpringSource Application Management Suite depuis 2007), mais cette acquisition confirme la direction affichée par SpringSource ces derniers mois : contrôler l’ensemble du cycle de vie d’une application Java, de sa conception à son exploitation.
En effet, un très grand nombre de projets Java s’appuient aujourd’hui sur le framework Spring (phase de développement). Un très grand nombre de ces développements tournent sur le serveur openSource Tomcat, dont SpringSource propose une distribution commerciale depuis peu (Spring tc Server). Et aujourd’hui, grâce à l’acquisition de Hyperic, SpringSource propose de réaliser l’exploitation de ces serveurs d’applications.

On peut d’ailleurs supposer qu’Hyperic devrait rapidement évoluer et proposer une version commerciale encore plus ‘orientée’ vers le framework Spring et le serveur Tomcat que ne l’était Spring AMS, avec une offre de support afférente.
Parmi les évolutions probables (car souvent évoquées par SpringSource comme des problèmes à résoudre pour les développeurs), nous devrions avoir :

  • Gestion de la configuration au niveau Hyperic. Actuellement, Hyperic ne permet de réaliser que des opérations Stop/Start sur la ferme de serveurs. tcServer propose la gestion de la configuration du serveur. On peut donc imaginer un modèle de données qui permettrait de configurer ses tomcats directement depuis l’outil de monitoring.
  • Déploiement phasé. Comme avec JBoss ON, il est souhaitable de voir apparaître un outil permettant de déployer progressivement sur les noeuds d’un cluster (probablement basé sur un outil de scripting).
  • Virtualisation. Le déploiement sur des machines virtuelles types VM-Ware sera facilité.

Sur ces sujets, l’apport (et l’expérience) de Hyperic sera déterminant.

On peut s’amuser à retracer les différents rachats de Spring. En 2004, Hyperic est né d’un fork d’une partie des équipes de Covalent. En février 2008, SpringSource acquérait Covalent. Un peu plus d’un an après, SpringSource reconstitue l’entité de 2004 en acquérant Hyperic.

Javier Soltero, CEO d’Hyperic affirme qu’il s’agit là d’un mariage de raison, entre deux acteurs qui partagent la même vision de l’informatique et qui sont les meilleurs (et des standards de facto) dans leur domaine respectif (le développement Java pour SpringSource, et le management IT pour Hyperic). Il va d’ailleurs rejoindre le board de SpringSource en tant que directeur technique des outils de Management.

Parmi les effets collatéraux, on peut noter la (très probable) fin du projet (déjà mal en point) RHQ, partenariat entre RedHat et Hyperic, qui visait à créer une plate forme ‘manageable’ basée sur JBoss.
Toutefois, JBoss ayant racheté la base de code d’Hyperic avant qu’il ne devienne « public source », la fin du partenariat ne veut pas forcément dire fin de JBoss On dont le code à été très largement modifié par les équipes JBoss.

Le choix de monétisation des assets open source devrait commencer à effrayer les mastodontes de l’informatique (IBM, Oracle, Microsoft), qui avaient fait du contrôle total de la stack applicative (Java dans un cas, .Net dans l’autre) leur pré carré. C’est d’ailleurs la volonté de Rod Johnson (annoncée lors de SpringOne Europe) : devenir un ‘One Stop-By Shop’, comme peuvent l’être ces géants du monde informatique.

Le coin de la technique

Quelques nouveautés pour Apache Derby

Une nouvelle version du moteur de base de données Java de la fondation Apache vient d’être diffusée. Cette version apporte à Derby une dose d’évolutions intéressantes pouvant aider dans certains cas d’utilisation. François Orsini en présente la liste. On retiendra en particulier :

  • In-memory backend : Cette fonctionnalité, particulièrement mise en avant dès la version 10.5 preview, permet de stocker une base de données en mémoire et ainsi de s’astreindre du stockage sur disque. Derby rejoint ainsi HSQLDB et H2 Database qui offraient déjà une telle possibilité, très utile dans le contexte des tests unitaires ou de certaines applications ne nécessitant pas de persistance durable.
  • Roles SQL : Ils permettent de simplifier l’administration des privilèges attribués à une base de données. La documentation de Derby est d’ores et déjà à jour et permet de faire le tour des possibilités offertes.
  • Generated columns : Il s’agit de colonnes dont les valeurs sont calculées à partir d’autres colonnes d’une même table. Il est également possible de déclarer un index sur une telle colonne afin d’améliorer les performances sur certains types de requêtes. Cette fonctionnalité est une version allégée des virtual columns introduites dans Oracle 11g.

L’actualité d’Apache Directory Server

Lors du dernier podcast des Cast Codeurs, Emmanuel Lécharny, committer français sur Apache Directory, a fait un tour d’horizon de ce projet. Pour rappel, Apache Directory est un projet de la fondation Apache qui produit un serveur LDAP en Java (Directory Server) et un outil de visualisation / édition de directory LDAP basé sur Eclipse (Directory Studio).

Du fait de son orientation Java, le positionnement de Directory Server sur le marché n’est pas évident, aussi les cas d’utilisation ont été longuement décrits ; on retiendra :

  • Les tests unitaires, puisque le serveur LDAP peut ainsi être contrôlé et se faire injecter des données par Java lors du déroulement des tests.
  • Embarquement du serveur LDAP dans l’application grâce au mode embedded de Directory Server, lorsque l’on ne souhaite pas dépendre d’un serveur externe.
  • Profiter de la simplicité de configuration de Directory Server pour le mettre en place rapidement en premier lieu pour éventuellement passer ensuite à un serveur commercial.

Ainsi, lors de cette interview, il a été question d’utiliser Directory Server dans des rôles secondaires plutôt que directement en production. Pourtant, il y a un an, lors de l’ApacheCon 08, Emmanuel Lécharny s’était longuement attardé sur la question lors de sa présentation en mettant en avant les fonctionnalités exclusives de procédures stockées et de triggers pour légitimer l’utilisation de Directory Server en production. Face à l’oscillation autour de cette problématique, notons qu’Apache DS, pourrait, plus modestement, être utilisé conjointement à d’autres serveurs LDAP commerciaux par la mise en place d’un virtual directory.

Enfin, Emmanuel Lécharny a exposé une synthèse des principales nouveautés à attendre de la future version 2.0, actuellement prévue pour septembre :

  • Réplication multi-master entre plusieurs noeuds Apache DS ainsi qu’avec des noeuds OpenLDAP.
  • Disaster Recovery System permettant d’éviter les pertes de données suite à un crash. Cette fonctionnalité étant actuellement assurée par un journal, peu optimal, qui rend l’opération de récupération très longue.
  • Configuration stockée au sein même du serveur LDAP.

La mémoire native en Java

Andrew Hall a publié deux articles très intéressants portant sur la gestion de la mémoire native dans la JVM, c’est-à-dire la mémoire consommée par la machine virtuelle mais ne faisant pas partie de la Java Heap et n’étant donc pas gérée par le garbage collector. Les systèmes d’exploitation couverts par ces articles sont Windows, Linux et AIX.

Après avoir fait un rappel sur la gestion de la mémoire par les systèmes d’exploitation, l’auteur explique en détail les différents composants Java susceptibles de consommer de la mémoire native non gérée au sein de la Heap Java. En font partie le bytecode des classes chargées par les classloaders, la mémoire allouée par le code JNI natif, les direct buffers NIO et les stacks de chaque thread. Le problème est que la mémoire totale adressable par un processus 32 bits est de 2 à 4 Go selon les cas. Des crashs de la JVM, dus à un manque de mémoire, peuvent donc parfois intervenir alors que la Java Heap n’est pas pleine.

Les solutions à cette problématique sont passées en revue, parmi lesquelles figurent : réduire la mémoire totale utilisée par la JVM en réduisant la taille de la Java Heap (via -Xmx), réduire l’utilisation de mémoire native non gérée par la Java Heap, repousser la taille limite de la mémoire adressable par le processus de la JVM en passant par exemple à un OS et une JVM 64 bits.

Au-delà des informations fournies par ces deux articles, les lecteurs intéressés par ce sujet pourront étudier le très complet, bien qu’ancien, livre de Bill Venners, ‘Inside the Java Virtual Machine’, partiellement disponible en ligne.

Publié par

Publié par Xebia France

Xebia est un cabinet de conseil international spécialisé dans les technologies Big Data, Web, les architectures Java et la mobilité dans des environnements agiles. Depuis plus de 15 ans, nous avons la volonté de partager notre expertise et nos actualités à travers notre blog technique.

Commentaire

2 réponses pour " Revue de presse Xebia "

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.