La plate-forme logicielle J2EE (Java 2 enterprise edition) a connu un succès grandissant au sein des entreprises qui ont choisi de l’adopter pour bâtir leurs applications e-business. Sa version 1.2 a marqué le début de la véritable croissance du marché des serveurs d’applications J2EE. Selon Sun Microsystems, ce marché atteint désormais 1,7 milliard de dollars, et ne cesse de croître.Durant l’été 2001, Sun et ses partenaires ont publié les spécifications de la version 1.3 de J2EE, qui avait deux objectifs principaux : accroître la maturité de la plate-forme, et marquer son évolution vers une plate-forme de création d’applications intégrées au système d’information.Depuis le début de cette année, la version 1.3 devient une réalité dans les serveurs d’applications proposés par les principaux éditeurs. Borland et Sybase ont été les premiers dont les serveurs d’applications ont été certifiés conformes à J2EE 1.3. Et BEA Systems, IBM, Macromedia et Silverstream ont créé des préversions, elles aussi certifiées conformes.
Les lacunes du modèle de programmation sont réglées
Pour accroître la maturité de la plate-forme J2EE, Sun Microsystems et ses partenaires ont, tout d’abord, pallié les lacunes du modèle de programmation J2EE, tant vis-à-vis de la gestion de la persistance de l’état des composants objets EJB de type Entité que vis-à-vis de la manipulation de documents XML (Extensible markup language).Dans la version 1.2 de la plate-forme, deux types d’EJB avaient été définis : d’une part, des EJB, de type Session, prenant en compte les traitements liés aux requêtes des utilisateurs ; d’autre part, des EJB, de type Entité, représentant en mémoire les données persistantes, et censés offrir un plus haut niveau d’abstraction aux développeurs (par l’intermédiaire d’une correspondance objet-relationnel).Le problème rendant les EJB Entité quasi inutilisables était, notamment, lié au fait que la gestion de la correspondance objet-relationnel imposait une correspondance directe entre un EJB de type Entité et une table organisée en base de données. De plus, les associations entre les composants n’étaient pas traitées. Le nouveau modèle de composants EJB 2.0 inclus dans J2EE 1.3 est beaucoup plus évolué de ce point de vue, et gère la correspondance entre des modèles objets complexes et une base de données relationnelle, sans imposer de contraintes sur la structure de cette dernière.Les relations entre les différents types d’EJB (association ou agrégation) sont aussi prises en compte, ce qui rend la gestion automatique de la persistance des EJB de type Entité beaucoup plus exploitable, face à des problèmes concrets. La gestion des relations entre EJB par le “conteneur” évite de développer des mises à jour des EJB dans les différents SGBD sous-jacents.Prenons un exemple : sur un site de commerce sur Internet, la passation d’une commande par un utilisateur implique souvent de mettre à jour les SGBD liés à l’inventaire, aux commandes à fournir, au fichier clients, etc. Avec les EJB 2.0, la déclaration de relations entre les EJB clients et commandes entraîne des mises à jour automatiques dans les différents SGBD (l’entrée d’une commande dans le SGBD des commandes implique la mise à jour automatique du SGBD des clients).Un autre point important, toujours dans les EJB 2.0 Entité, est l’introduction du langage de requête EJB QL permettant de rechercher un EJB Entité de façon similaire à une recherche de données dans un SGBD relationnel. Les nouveaux EJB 2.0 Entité devraient donc accroître la productivité, tout en évitant de coder à la main, en SQL, la correspondance objet-relationnel.
La prise en compte des services Web, prévue dans la version 1.4
J2EE 1.3 en profite pour régler une seconde lacune importante de la version 1.2, liée à l’absence de standard pour la manipulation de documents XML. Il introduit l’interface JAXP (Java API for XML processing), qui impose aux éditeurs d’inclure, dans leurs serveurs d’applications, des parseurs SAX (Simple API for XML) et DOM (Document object model), et un processeur XSLT (Extensible stylesheet language transformation). De plus, il devient possible d’écrire et de manipuler des JSP (Java server pages) en XML, ce qui évite de mélanger le graphisme et le code Java, et facilite la gestion de différents types de terminaux.En revanche, J2EE 1.3 n’inclut ni fonctionnalité ni interface de programmation relatives aux services Web. Cela est dû au fait que la version 1.3 a été définie fin 2000-début 2001, époque à laquelle les services Web n’avaient pas été adoptés universellement. La véritable prise en compte des services Web est prévue pour la version 1.4.Toutefois, devant la popularité croissante des technologies de services Web, Sun a créé le Java XML Pack, qui comprend des interfaces de programmation dédiées aux services Web ; et le Java Web Service Developer Pack, qui contient tous les éléments nécessaires pour mettre en ?”uvre des services Web avec J2EE 1.3. Les éditeurs de serveurs d’applications J2EE tels que BEA Systems, HP, IBM ou Oracle proposent une collection d’outils pour rendre l’usage des services Web transparent au développeur. Néanmoins, l’intégration de ces services par le modèle de composants EJB ne sera réalisée que dans la version 1.4.
Les composants EJB, sollicités en mode asynchrone
Outre la nécessité de remédier aux lacunes les plus importantes du modèle de programmation J2EE 1.2, il fallait aussi rendre l’administration des applications J2EE plus cohérente. Il n’existait pas, en effet, de protocole standard pour opérer une véritable administration à distance des serveurs d’applications J2EE. Certains éditeurs proposaient la supervision de leurs produits via SNMP ; d’autres, uniquement via leur console dédiée ?” plus ou moins complète. La version 1.3 inclut le standard JMX (Java management extension), d’origine Sun (lire l’encadré).J2EE 1.3 comprend aussi de nombreuses nouveautés facilitant une meilleure intégration des applications J2EE au système d’information existant. Les middlewares orientés messages (MOM), tels IBM WebSphere MQSeries ou Tibco Rendezvous, étant très répandus dans les entreprises comme bus logiciels de communication interapplications, Sun et ses partenaires ont défini l’interface JMS (Java messagery service) pour autoriser l’accès des applications J2EE de façon standardisée aux différents MOM du marché.La grande nouveauté de J2EE 1.3 réside dans l’enrichissement du modèle de composants EJB par un nouveau type de composant EJB pour permettre leur invocation de façon asynchrone (sur le modèle du mode messagerie). Les EJB de type Message sont activables sur réception d’un message transporté par un MOM JMS. Ils peuvent ensuite invoquer les autres types d’EJB (Session ou Entité). L’asynchronisme des EJB de type Message, couplé à la garantie de délivrance induite par ces middlewares, autorise, par exemple, le découplage des clients par rapport aux traitements effectués sur une commande, ou encore, la prise en compte de clients déconnectés, tels les utilisateurs de PC portables ou d’assistants personnels. De nombreux éditeurs indépendants proposent des MOM conformes à JMS, couplés à de nombreux serveurs d’applications. Ainsi, Progress Software commercialise son MOM JMS, appelé Sonic MQ, qui a été interfacé avec les serveurs d’applications de BEA Systems, de HP, d’IBM, etc. Les éditeurs de serveurs d’applications proposent aussi leurs MOM conformes à JMS, qu’ils incluent dans leurs produits. Enfin, les éditeurs de solutions d’EAI (Enterprise application integration, ou solutions d’intégration d’applications) tels que Tibco Software et webMethods proposent depuis peu leurs MOM conformes à JMS.En parallèle de JMS, Sun Microsystems et ses partenaires ont défini le standard de connecteurs JCA (J2EE connector architecture) pour interfacer de façon synchrone, cette fois-ci, les applications d’entreprise.Avec l’introduction obligatoire de l’architecture de connecteurs JCA dans les serveurs d’applications conformes à J2EE 1.3, Sun souhaite améliorer la portabilité des applications Java entre les serveurs d’applications des différents éditeurs.Jusqu’à présent, une application développée pour le serveur de l’éditeur “abc” ne fonctionnait pas, telle quelle, sur le serveur de l’éditeur “xyz “.
Vers des connecteurs logiciels standards
Chaque éditeur ayant développé ses propres connecteurs, ceux-ci n’avaient pas forcément les mêmes interfaces, et tout ou partie des interfaces propriétaires du progiciel pouvait ne pas être pris en compte. Pour porter une application J2EE d’un serveur d’applications à un autre, une adaptation du code source était nécessaire. Désormais, avec JCA, seul l’éditeur du progiciel fournira le connecteur capable d’intégrer son logiciel avec une application J2EE. Les divers éditeurs de serveurs d’applications devront inclure dans leur offre une structure d’accueil de connecteurs JCA, structure dans laquelle les connecteurs des fournisseurs de progiciels viendront se “plugger “.L’architecture JCA détermine, en pratique, un ensemble de contrats standards entre les serveurs d’applications et les progiciels à intégrer que devront mettre en place les connecteurs logiciels utilisés comme passerelles avec les systèmes d’information existants. Via ces connecteurs, le serveur d’applications et le progiciel à intégrer collaborent pour offrir aux composants métiers, de façon transparente, les mécanismes de système de gestion des transactions distribuées multisources, de la sécurité du système existant (contrôle d’accès) et du partage des accès au progiciel (pools de connexion). JCA définit aussi une interface standard d’accès aux progiciels existants, appelée CCI (Common client interface).CCI doit permettre aux composants applicatifs et aux solutions d’EAI de piloter des interactions entre divers progiciels hétérogènes avec une interface homogénéisée. Avec JMS et JCA, J2EE 1.3 marque une avancée très nette vers la connexion des applications J2EE au système d’information existant. L’impact de ces standards déborde du marché des serveurs d’applications, et commence à atteindre celui des EAI. Certains éditeurs d’EAI ?” comme Tibco Software, ou webMethods à nouveau ?” ont créé des connecteurs JCA pour relier les serveurs d’applications conformes à J2EE 1.3 à leurs solutions d’intégration d’applications.
J2EE 1.3, une version de transition…
L’impact sur l’EAI devrait aller au-delà avec la prise en compte du standard JCA par les solutions d’EAI pour interfacer les applications de l’entreprise. See Beyond, Sybase (Neon) et webMethods sont en train de doter leurs solutions d’EAI d’une structure d’accueil pour utiliser des connecteurs JCA. Il en est de même pour l’emploi des MOM conformes à JMS. See Beyond et webMethods, par exemple, ont créé un connecteur pour raccorder un MOM JMS à leurs solutions respectives d’intégration d’applications.Toutefois, cette avancée est limitée par les nombreuses lacunes restant à combler dans ces nouvelles technologies. Les implémentations de JMS pouvant fonctionner dans le contexte de grappes de serveurs sont encore rares. Ainsi, JCA permet uniquement des échanges synchrones, ne gère pas les métadonnées (description des données échangées) et ne prend pas en compte XML dans l’interface CCI. En conséquence, les éditeurs de solutions d’EAI se sont joints aux éditeurs de serveurs d’applications J2EE pour concevoir une nouvelle version de l’architecture JCA ( www.jcp.org), qui autorisera des échanges bidirectionnels synchrones ou asynchrones.JCA 1.5 pourra être davantage utilisé pour l’intégration des applications J2EE au système d’information. Mais, il faudra attendre J2EE 1.4 pour en disposer. De plus, il faudra faire face aux propositions d’intégration basées sur les services Web.J2EE 1.3. doit donc être plutôt considéré comme une version de transition, qui règle les lacunes de la version 1.2. et présente un nombre important de nouveautés quant à l’intégration des applications J2EE au système d’information, et à l’utilisation de J2EE pour créer des services Web. Il faudra attendre la version 1.4 pour disposer d’une offre beaucoup plus mature, et utilisable avec les standards JCA et JMS. La disponibilité des spécifications est prévue pour le deuxième semestre de 2002, et les premières implémentations devraient être disponibles fin 2002 ou début 2003.
… mais il est urgent de ne pas attendre J2EE 1.4
Ce jugement de valeur doit cependant être tempéré par la dynamique du marché. Les éditeurs n’hésiteront pas à proposer, dès que possible, des versions préalables des nouveautés de la future version 1.4. Il suffit, pour s’en convaincre, de considérer les annonces actuelles des éditeurs autour des services Web. Aucun éditeur de serveur d’applications J2EE ne prendra le risque d’attendre J2EE 1.4 pour inclure les technologies de services Web dans son offre, de peur de voir Microsoft profiter des services Web pour reprendre des parts de marché.Les entreprises utilisatrices de la plate-forme J2EE auront donc à leur disposition un grand nombre d’outils de création de services Web avant leur intégration dans la version suivante. Le risque d’adopter ces outils et technologies propres à chaque éditeur est faible, car les vrais standards en matière de services Web sont ceux du consortium W3C. Ces derniers sont les véritables garants de l’interopérabilité des plates-formes de création de services Web. Le risque de non-portabilité des services Web créés entre deux serveurs d’applications J2EE est aussi faible, car la création de ces services est le plus souvent faite par la génération automatique de la description des services à partir du composant Java sous-jacent, et par la publication automatique des services Web créés dans le référentiel UDDI. Porter son service Web d’un serveur J2EE à un autre revient à porter l’application sous-jacente et à régénérer les services Web.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
