La plate-forme J2EE (Java 2 enterprise edition), destinée à l’entreprise, arrive à maturité. La technologie J2EE ?” normalisée et complétée de services middlewares avancés ?” et l’ensemble de spécifications qu’elle regroupe (EJB, JMS et JCA) ont permis d’élaborer une plate-forme orientée objets complète, dotée de services transactionnels évolués, adaptés aux applications e-business stratégiques. Voilà pour le tableau d’ensemble. Mais qu’en est-il dans le détail ?On est encore loin du recours systématique aux technologies EJB (Enterprise JavaBean). Les spécifications sont jeunes, et les retours d’expérience rarissimes. EJB n’est mis en ?”uvre que par de grandes entreprises. Aujourd’hui, la majorité des développements Java se font en servlet. Cela ne remet pas en cause l’amélioration et la pénétration de J2EE, progressives, mais inéluctables. D’ailleurs, la sortie de la plate-forme.NET, de Microsoft, devrait, paradoxalement, aider à sa plus large acceptation. “Tous les concepts véhiculés par Java ?” à savoir l’orienté objets, la réutilisation du code, la forte structuration, la modélisation ou la portabilité ?” ont été bien intégrés par le marché”, explique Jean-Baptiste Bugeaud, consultant chez Fi System. Il aura cependant fallu gommer certains défauts de jeunesse des serveurs d’applications et des ateliers de développement Java.
Une prise en main facilitée
Par exemple, si les composants transactionnels EJB sont encore peu utilisés, cela tient à la difficulté de maîtriser tous les aspects du développement orienté objets ?” à commencer par la modélisation UML. “C’est une technologie qui est mature, soutient Jean-Baptiste Bugeaud, mais qui demande d’accéder à un niveau technologique supérieur. Sa prise en main est facilitée par les outils de nouvelle génération. Ces derniers disposent d’assistants de reprise et d’analyse du code, intègrent l’ensemble du cycle de développement EJB, et assistent le développeur dans les phases les plus délicates.” La spécification EJB a pu être critiquée pour l’absence de garanties qu’elle apportait en portabilité. Cette critique doit être nuancée. “Les premières moutures des EJB ne couvraient pas forcément bien les besoins d’optimisation. Avec la version 2, la couverture est suffisante pour les projets actuels. Il est inutile d’utiliser de fonctionnalités propriétaires d’un serveur d’applications pour améliorer les performances.”Les améliorations apportées début 2002 aux ateliers de développement Java ont changé la donne. “Les technologies de déploiement telles que les EAR ou les WAR facilitent l’intégration. Un fichier EAR, créé sous JBuilder, sera opérationnel sur WebSphere 4 ou sur WebLogic 6.1”, poursuit le consultant.Les ateliers de développement (AGL) Java de première génération étaient moins fournis que leurs homologues du monde C++. Ces lacunes commencent à être gommées. VisualAge pour Java, l’AGL de développement orienté objets d’IBM, ne brillait pas par la qualité de son intégration avec WebSphere. IBM vient d’y remédier avec WSAD (WebSphere studio application developer). Cet atelier, qui remplacera VisualAge en 2003, couvre tous les aspects du cycle de développement Java et XML. Optimisé pour la production d’applications EJB pour WebSphere, il témoigne d’un début d’ouverture : il supporte, en effet, Jakarta Tomcat, un serveur Open Source, complémentaire d’Apache.
WebGain, un modèle en matière d’ouverture
Mais, en matière d’ouverture, c’est WebGain qui fait figure d’exemple avec AGL WebGain Studio. Fondée à l’initiative, notamment, de BEA, WebGain couvre tous les aspects du développement Java d’entreprise, de la modélisation UML au développement XML en passant par les JSP, servlet, EJB et J2EE. Les applications construites sous WebGain Studio sont déployables sur le serveur WebLogic, de BEA, mais aussi sur les serveurs d’applications WebSphere Server, Oracle 9i Application Server, Sybase EAServer et HP Bluestone.Meilleure couverture du cycle de développement, support du standard EJB 2.0 et déploiement multiserveur : cette triple évolution a été suivie par d’autres éditeurs ; citons Compuware, avec sa toute récente suite OptimalJ ; Borland, avec la version 6 de JBuilder ; et SilverStream, avec SilverStream Extend. Ce dernier peut déployer des applications J2EE non seulement sur le serveur propre à SilverStream, mais aussi sur WebSphere, WebLogic, Oracle 9i Application Server et Jakarta Tomcat !La portabilité du code J2EE et l’indépendance vis-à-vis des serveurs d’applications ne sont donc plus des vues de l’esprit ?” si l’on suit les spécifications J2EE et EJB.Reste la gestion de la persistance des objets dans le modèle EJB. Il existe des solutions pour accroître les performances en ce domaine. Une correspondance entre les objets et une description relationnelle sont généralement utilisées avec des outils tels que TopLink, de WebGain ; ou CocoBase, de Thought. Cela permet de s’appuyer sur une base de données traditionnelle.Pour monter en puissance, on peut recourir à des bases de données objets telles qu’enJin, de Versant. “Le modèle JDO est une solution plus simple, note Jean-Baptiste Bugeaud. Un produit comme Castor, de l’Exolab, laisse entrevoir de nouvelles possibilités.” Mais, qu’une entreprise décide ou non d’investir dans du développement lourd, il est probable qu’elle viendra aux technologies J2EE, ne serait-ce que parce que les éditeurs de logiciels fonctionnels commencent à se les approprier.Ce mouvement concerne les éditeurs d’outils front-office et de places de marché. Tant BroadVision que Vignette ont fait un choix J2EE et EJB, l’un pour la version 6 de sa suite Commerce Suite ; l’autre, pour la suite Merchant Suite, dont le noyau, Commerce Engine, a une architecture modulaire, à base de composants EJB.
MS et JCA pour une intégration standardisée
Le français Exponentiel Technology a suivi la même voie, en développant en EJB les services nécessaires à la constitution d’une place de marché privée. Ont ainsi été séduits des groupes comme Saint-Gobain ou Spie-Batignolles.Ce mouvement touche également les éditeurs de progiciels de type back-office. Rares toutefois sont ceux à s’être lancés dans une stratégie de complète réécriture de leurs progiciels en Java.En revanche, ils sont nombreux à exploiter Java pour ouvrir et standardiser les interfaces de leur produit, et offrir des services e-business. Intentia, l’éditeur de l’ERP Movex, avait été l’un des premiers à adopter une stratégie tout Java. L’éditeur cherchait à se diversifier au niveau des plates-formes gérées et à l’international. Il lui fallait passer à une technologie portable.“Avec Java, le nombre de lignes de code a été quasi divisé par deux ; les composants ont été restructurés en technologie objets, ce qui autorisait dès lors des déploiements ERP par phases”, explique Philippe Michel, directeur des solutions e-business d’Intentia. Cette venue à Java a servi la stratégie de l’éditeur. Intentia s’est lancé dans le développement de services Web complémentaires de Movex et couvrant les fonctions de CRM et d’e-procurement.Même si tous les fournisseurs n’ont pas poussé aussi loin leur investissement Java, la tendance est là. Pour le spécialiste de GED d’entreprise qu’est Documentum, Java a constitué le moyen d’étendre les fonctions de son moteur Documentum 4i. Ses solutions WCM et B to B adaptées à la gestion de contenu en ligne s’appuient sur des API ouvertes et sur un kit de développement, tous deux compatibles J2EE. Même SAP participe à ce mouvement. Les progiciels middlewares de type EAI se prêtent aussi très bien à une migration vers Java. Les spécifications J2EE représentent la voie royale pour standardiser les mécanismes de connexion aux applications. D’autant qu’elles englobent deux importantes spécifications : JMS, qu’implémentent désormais tous les éditeurs d’EAI développés sous Java ; et JCA, une API de connexion à des sources de données non structurées et qui, elle, monte en puissance depuis août 2001. Car les outils d’EAI classiques posent un problème aux entreprises.Des produits concurrents communiquent difficilement entre eux. Dès lors, en s’urbanisant autour d’une solution donnée, l’entreprise craint de se fermer aux évolutions en matière d’interconnexion et de développement. Dans ce contexte, JMS et JCA apparaissent comme le gage d’une intégration standardisée et, donc, pérenne, car facilement évolutive. “JMS est souvent mis en ?”uvre pour l’envoi de messages. JCA fonctionne sur des maquettes, précise toutefois Jean-Baptiste Bugeaud, et JMS nécessite une API complémentaire de gestion des flux de messages, correspondant à la brique Integration broker d’un EAI. Cela constituerait une sorte de spécification J2EE+ !”. La spécification JSR 77, en cours d’élaboration, est un pas important. Bientôt, administrer un WebSphere ou un webMethods sera fondé sur des compétences communes. L’entreprise aura tout à y gagner en termes de coûts de personnels et de compétences nécessaires.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
