Depuis trois ans, Sun a fait le choix de promouvoir J2EE. En témoignent les investissements consentis pour séduire la communauté Java. Pourtant, l’idée d’un système de persistance nativement intégré au langage plutôt qu’un dispositif lié à une architecture a fait son chemin. Donc, en 1999, un groupe de travail décide de doter le langage Java et les environnements d’exécution associés d’un mécanisme de persistance transparent et universel. Cet aréopage d’éditeurs de SGBD et d’outils de développement, Sun, Oracle, IBM, Informix, Versant et BEA, fait approuver cette spécification Java, baptisée JDO (Java Data Object) par le JCP en juillet 1999. Un an après, les fondements de la spécification sont présentés lors de la conférence JavaOne. Celle-ci suscite d’emblée l’intérêt des développeurs, tout en faisant naître de nombreuses interrogations, relatives notamment à la cohabitation possible entre JDO et les EntityBeans de J2EE. Ces derniers assurant par définition un mécanisme de persistance. En mars dernier, la spécification est pourtant définitivement approuvée.
JDO devrait satisfaire les développeurs
Ce faisant, JDO apporte une réponse pertinente à un problème majeur rencontré par tous les développeurs. En effet, lorsque l’exécution d’un programme se termine, les données portées par les instances de classes (objets), par exemple le solde d’un compte-chèques, sont définitivement perdues, sauf si le programmeur les a préalablement enregistrées sur un dispositif de stockage externe. D’après une récente étude publiée par IDC, les ordres JDBC, responsables de la persistance des objets Java, représentent plus de 30 % du code des applications persistantes et leur maintenance monopolise 50 % du temps des développeurs concernés. Dans le cadre des architectures 3-tiers, Sun propose, avec J2EE, une gestion de composants persistants : EJB de type Entité (EntityBean). Le stockage de tels objets est soit pris en charge par le développeur au c?”ur du composant, soit assuré automatiquement par le container. Mais même avec les EJB, la correspondance entre le monde objet et le monde relationnel demeure délicate et coûteuse, sans parler des faiblesses de l’architecture J2EE dans des contextes transactionnels lourds impliquant de nombreux accès concurrents aux EJB persistants. Dans ces conditions, pourquoi le marketing de Sun, habituellement si efficace, ne s’empare-t-il pas de JDO ?
JDO ne s’oppose pas à J2EE
Dans son environnement de développement, récemment rebaptisé SunONE Studio, Sun comporte bien une prometteuse fonction Transparent Persistance qui s’appuie même sur une application d’un document de travail de JDO. Mais celle-ci n’est pas compatible avec l’actuelle spécification (JDO 1.0) et la future version (4.0) de SunONE Studio ne devrait rien apporter de nouveau dans ce domaine. D’après Alexis Moussine Pouchkine, architecte SunONE (Sun), “JDO se veut plus large que J2EE ou J2SE [le JDK standard, Ndlr]. S’il trouve sa place au c?”ur de telles architectures applicatives, JDO peut faciliter la gestion d’un cache de données dans les applications Java embarquées [J2ME – Java 2 Micro Edition, Ndlr] et apporte également une réponse intéressante pour gérer la persistance des clients Java lourds.”Sun destine donc JDO au développement de J2ME et à des applications clientes autoexécutable Java, sans navigateur. Pourtant, s’il est vrai que la spécification correspond à une véritable attente des développeurs, tous domaines applicatifs confondus, elle constitue aussi une solution élégante, capable de pallier certains défauts de jeunesse de J2EE. Les grands éditeurs d’environnements de développement ont beaucoup investi pour fournir des applications performantes de J2EE et ne souhaitent certainement pas remettre en cause aujourd’hui ce choix stratégique.Ainsi, Sun n’est pas le seul acteur à minimiser l’intérêt de la spécification. Outre Microsoft, naturellement écarté du débat autour de JDO, Oracle, pourtant membre actif des groupes de travail Java, mise plutôt sur XML pour garantir la persistance des objets. Et ce malgré les contraintes de performances associées au traitement de descripteurs XML, par essence très prolixes. De son côté, IBM affirme avoir voté en faveur de JDO, en mars 2002, mais se contente, pour l’instant, “d’envisager de développer des partenariats avec certains éditeurs spécialistes de la persistance pour compléter WebSphere”, explique Alain Rabenandrasana, directeur avant-vente de la gamme WebSphere. Aucune extension JDO de Developer Studio ne semble donc prévue. Seuls quelques rares acteurs se sont engagés, comme SAP en juillet 2001, à fournir des applications de JDO. Si les développeurs souhaitent promouvoir cette extension de Java, il leur faudra faire pression sur les grands éditeurs du marché ou s’intéresser aux produits proposés par des acteurs spécialisés : WebGain, Kodo, LIBeLIS.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
