JDO : un excellent choix technologique !

Pour Yves Yang, le mapping objet/relationnel imposé par les beans CMP (Container Managed Persistence) est une hérésie qui coûte cher aux entreprises. Pour arrêter le massacre, elles devraient plutôt utiliser JDO (Java Data Objects).

En matière de persistance et d’accès aux données, Java comporte un écueil de taille: c’est un langage orienté objet (OO) qu'on a marié avec les SGBDR (tables et colonnes). Or, les objets Java s'accommodent fort mal de cette logique à deux dimensions. N’en déplaise aux aficionados de CMP, le mapping relationnel/objet imposé par cette technologie est un véritable fléau, qui freine l'adoption massive de Java par les grandes entreprises.

Le modèle de composant de Java, les EJB, s'appuie en matière de persistance sur la norme CMP (Container Managed Persistence), un mécanisme magique sur le papier. Le composant gère automatiquement la persistance des objets qu'il manipule. En pratique, c'est un cauchemar à implémenter, les concepts objets sont réduits à leur plus simple expression, la plomberie à mettre en œuvre pour faire fonctionner un CMP est excessivement lourde, réduisant à néant tout intérêt potentiel de ce concept.

Les experts de l'objet, ceux là même à l'origine de l'ODMG, recherchent désespérément un cas intelligent d'usage des CMP.

Car pour les faire persister dans une base de données relationnelle, le développeur Java doit abandonner son langage de prédilection et coder ses requêtes directement en SQL. Cette partie de l'application – le mapping objet/relationnel - n'apporte aucune valeur ajoutée d'un point de vue fonctionnel. Il sert uniquement à expliquer aux objets Java quelles tortures ils doivent subir pour se retrouver hébergés dans une ou plusieurs tables en un seul ou plusieurs morceaux.

Seul un expert maîtrisant simultanément les concepts objets et relationnels peut coder manuellement le mapping. Ce surcoût est évalué en moyenne à 30% du coût d’un projet Java.

Ce surcoût n’est pas le seul inconvénient d’une approche à base de CMP et de mapping. La transformation de modèles se concrétise en effet par des requêtes et des jointures entre tables particulièrement coûteuses en CPU. En clair, l’application est moins performante et monte plus difficilement en charge. Pour contourner ce problème, l'administrateur de la base de données multiplie en général le nombre d'index. Si bien que les disques sont au final occupés pour moitié par les données et pour l’autre par les index.

Comme un malheur n’arrive jamais seul, pour combler le déficit de performance et de capacité à monter en charge, la tentation est forte d'utiliser des API et des outils spécifiques et non standards propres au SGBDR, associé au code du mapping et à la multiplication des indexes. Tout ceci induit une forte dépendance à l'éditeur du SGBDR tout au long du cycle de vie de l'application.

Java Data Objects (JDO): un standard pour arrêter le massacre

En 1999, un groupe d'experts travaillant alors sur la problématique de persistance des objets Java a décidé d'apporter l'ensemble de ses travaux à SUN, dans le cadre du JSR 12: Java Data Objects. 

Ambitieux, l'objectif de cette JSR est "write once, persist anywhere" (coder une fois, persister n'importe où). Un standard préconçu par des éditeurs de bases de données orientées objets se transforme en une solution universelle; n'importe quel support de persistance : un SGBDR, un SGBDO, un fichier, … , peut recevoir une interface JDO. Réciproquement, une application développée dans un cadre JDO peut persister sans aucune modification sur tout support de persistance doté d'une interface JDO.

Le standard JDO (Java Data Objects) permet de répondre à chacun des trois niveaux de problème apporté par le mapping:

• Le surcoût en développement est réduit à néant: le développeur ne connaît que Java. Il développe son application sans se soucier de la cible en terme de persistance. L'éditeur du pilote JDO choisi prend à sa charge et de façon automatique la génération éventuelle du code de mapping nécessaire pour stocker les objets Java dans une base relationnelle. Il conviendra de choisir celui qui apporte le plus de compétences et d'expérience en ce domaine, tant les stratégies de mapping peuvent être différentes et diversement efficaces suivant la nature de l'application.
• 
  
• L'impact en performance et en confort d'exploitation pourra être réduit, puisque suivant les exigences de l'application, le client final choisira le support de persistance le mieux adapté à ses contraintes. Le SGBD objet redevient notamment redevient un choix possible. Le choix de la solution de persistance est réalisé en aval du projet, en phase de déploiement, et peut être remis en question à tout instant.
• 
  
• Enfin, l'application n'a plus de dépendance vis-à-vis d'une plate-forme de persistance particulière. Le seul choix qui soit difficilement révocable dans une démarche JDO est le choix de Java.

* Yves Yang est directeur technique chez Versant, un éditeur d'applications d'infrastructures middleware qui propose des solutions de gestion d'objets pour les environnements java, C++ et J2EE.