“Le concept d’ouverture fait vendre, note Frédéric Bon, consultant chez Clever Age. Mais il faut lire entre les lignes pour situer la frontière entre ouverture et dépendance.” Synonymes de coût, de dépendance et de faible évolutivité, les technologies propriétaires font fuir les entreprises. Les éditeurs se sont donc lancés dans une course à l’ouverture et aux standards, avec Sun pour principal chef de file. Mais ce dernier doit désormais compter avec Microsoft. L’éditeur de Windows espère lui clouer le bec avec .Net, et faire aussi ouvert ?” sinon plus ?” que J2EE, tout en préservant son offre propriétaire.Les deux éditeurs s’opposent sur le concept d’ouverture : Microsoft propose une seule plate-forme pour exécuter vingt-trois langages ; Sun, au travers de J2EE, privilégie un seul langage ?” Java ?”, exécutable sur différentes plates-formes. Microsoft déplace le problème de l’ouverture en fondant sa stratégie sur l’interopérabilité, notamment au travers des services web, et non sur la portabilité du code, fer de lance de Sun. Il entend ainsi répondre aux besoins d’ouverture des entreprises, qui se situent plus au niveau des échanges entre environnements hétérogènes que dans la transposition de code entre systèmes d’exploitation. Dès lors que deux applications hétérogènes peuvent dialoguer de manière standardisée, leur portage d’un système à un autre perd, en effet, de son intérêt.
Entre portabilité et performance, il faut choisir
En soumettant les spécifications de son architecture à l’Ecma (European Computer Manufacturers Association) et au W3C, Microsoft propulse CLI (Common Language Infrastructure), concurrent direct de J2EE, et son langage de développement C# au rang de standards internationalement reconnus. Sun a préféré assurer l’évolution de Java au travers du Java Community Process (JCP), association d’éditeurs tels IBM, BEA, Oracle et Borland, qui détermine l’avenir de la plate-forme. Pour Bruno de Combiens, directeur marketing France de Borland, “le JCP fait office d’Ecma. Ce n’est pas le nombre de participants qui fait la standardisation “. Reste que l’Ecma est un organisme indépendant, alors que le JCP est piloté par Sun. En d’autres termes, là où il faut passer plus de cinq mille tests de conformité auprès de Sun pour obtenir la certification J2EE, n’importe quel développeur peut se procurer les spécifications de CLI auprès de l’Ecma et développer son implémentation. D’ailleurs, de Ximian à Halcyon Software en passant par DotGNU ou Corel, les adaptations de CLI sur Unix fleurissent. “D’ici à un an, la solution de Ximian sera stable, et les entreprises pourront choisir entre plusieurs versions de CLI”, précise Sami Jaber, consultant chez Valtech. Toutefois, “rien n’empêche Microsoft de faire évoluer son environnement d’exécution CLR (Command Language Runtime) sans prévenir l’Ecma. C’est pourquoi je ne crois pas au portage de CLR”, souligne Pierre Laurent, architecte applicatif chez Sopra. Au-delà des débats de standardisation, une ouverture fondée uniquement sur la portabilité du code a des limites, que relève Frédéric Bon : “La portabilité de J2EE n’est réelle que sur une partie des API. Dès que l’on utilise les composants EJB ou le bus interapplicatif JMS, le projet se retrouve rapidement lié au serveur d’applications pour lequel il a été développé.” Pour se différencier et faire face à la pression du marché, les éditeurs ajoutent, en effet, certaines fonctionnalités propriétaires ?” ou pour lesquelles il n’y a pas encore de spécifications ?” à leur serveur d’applications, pourtant certifié J2EE. C’est le cas des services web et des infrastructures de portail, qui ne font pas partie de la spécification J2EE 1.3, mais sont disponibles chez tous les éditeurs. Les développeurs y ont souvent recours pour diminuer les temps de développement, choississant la performance au détriment de la portabilité.Remarque également valable dans le cadre de la gestion de la persistance des données. La communication entre l’environnement objet d’un serveur d’applications et celui de la base relationnelle implique, en effet, une transformation des données (mapping). J2EE automatise ce processus avec des composants EJB de type CMP (Container-Managed Persistence), diminuant ainsi les coûts de développement. Les requêtes SQL utilisées par des composants pour extraire ou insérer des données sont générées automatiquement par le conteneur au niveau du serveur d’applications. Lequel, s’il est conforme à J2EE, ne génère que du SQL standard et s’appuie sur JDBC (Java Database Connectivity) pour s’interfacer avec la base. Or, il est bien connu que tous les éditeurs de bases de données utilisent du SQL optimisé et que leurs pilotes natifs sont plus performants que ceux standards proposés par ailleurs. Le choix des performances s’opère, là encore, au détriment de la portabilité : le développeur ayant la possibilité d’écrire ses propres requêtes en SQL “propriétaire”, son code ne sera alors plus conforme aux spécifications J2EE.
Miser sur XML présente beaucoup d’avantages
Il n’existe aucun équivalent de CMP sur .Net. Microsoft a, là encore, préféré l’interopérabilité en fondant sa stratégie sur XML. L’éditeur crée, en effet, une couche intermédiaire entre la source de données et le composant qui l’utilise en important les données dans un fichier XML : le dataset. Avantages : les données sont manipulées au niveau objet ; l’étape de transformation, coûteuse en performance, s’effectue en tâche de fond ; et, structurées en XML, les données du dataset peuvent être utilisées par différentes applications à l’aide des standards XPath ou XQuery. Enfin, cette solution n’impose aucune modification spécifique de l’existant : le dataset interroge la source de données via ODBC, OLE-DB ou une interface native.A la traîne, J2EE tente d’apporter une solution similaire avec son langage EJB-QL, qui permet aussi de manipuler les données au niveau objet. Mais en attaquant directement la base via EJB-QL, Sun oblige les éditeurs de bases de données à ajouter ce langage à leurs outils, privilégiant encore la portabilité par rapport à l’intégration de l’existant. Aucun éditeur de SGBD ne s’est engagé sur l’implémentation d’EJB-QL, et les solutions de J2EE ne semblent pas à la hauteur de celle de Microsoft. Ce que note Bruno de Combiens, de Borland : “XML est la vraie solution à la communication entre environnements objet et relationnel.” Dans ce cadre comme dans celui des services web, qui apportent une réponse concrète à la communication entre environnements hétérogènes, J2EE, pourtant parti en avance en matière d’ouverture, est aujourd’hui en retard sur l’architecture .Net de Microsoft.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
