Lancée en 1998, la plate-forme J2EE est sans conteste la principale raison du succès de Java dans les entreprises. Les serveurs d’applications qui en sont issus sont devenus un pivot dans l’architecture des systèmes d’information. “J2EE a bien progressé. Aujourd’hui, nous disposons d’une offre industrielle. Mais l’essentiel est que nous y trouvons des produits de qualité “, constate Bruno Dumant, directeur technique de Kelua, éditeur spécialiste de l’intégration de composants. A mesure que de nouveaux besoins apparaissent, la norme évolue pour les prendre en compte ?” en particulier en matière de persistance (EJB, JDO) et d’interfaçage avec les autres applications (JMS, JCA). Mais la véritable architecture de composants logiciels EJB (Enterprise JavaBeans) reste encore une promesse. En effet, si d’importants projets s’appuient sur J2EE, l’approche par composants pose toujours un problème d’abstraction.
EJB 2.0, asynchronisme et persistance
Introduite il y a un an, la version 2 des spécifications EJB s’applique à résoudre les principales limitations de la version antérieure ?” en particulier sur le plan de la persistance des objets et de la gestion de leur association. L’intégration de JMS (Java Message Service) à la plate-forme a pour corollaire l’arrivée de nouveaux composants, les Message Driven Beans, spécialement conçus pour gérer les messages JMS. L’asynchronisme lié à cette approche permet de découpler les composants et d’assouplir dans une large mesure leurs interactions, l’émetteur d’une requête n’étant plus systématiquement bloqué dans l’attente d’une réponse. L’autre axe majeur d’amélioration concerne la persistance des objets et des données. L’introduction d’un langage de requête, EJB QL, et d’un gestionnaire de persistance pour les Beans CMP (persistance et relations gérées par le container) ouvre un éventail de possibilités, déchargeant le développeur de l’ensemble de la “cuisine” d’accès et de dialogue avec les SGBD. EJB QL, basé sur la norme SQL 92, définit les méthodes de recherche que le gestionnaire de persistance doit mettre en ?”uvre. Ces méthodes peuvent d’ailleurs s’appliquer à un ensemble de Beans, en fonction de leur association. Enfin, l’introduction des interfaces locales aux côtés des interfaces distantes (“remote”) permet d’optimiser les relations entre Beans au sein d’un même container, celui-ci conservant la gestion du cycle de vie de ces relations.
JMS encapsule les messageries interapplications
Lors d’un appel de type RPC, l’objet appelant reste bloqué dans l’attente d’une réponse. Or, toutes les applications n’ont pas besoin de ce couplage étroit. L’asynchronisme apporte à Java un mode de communication plus souple entre applications. JMS (Java Message Service), apparue en 1998 et partie intégrante de J2EE 1.3, est une interface qui permet de mettre en ?”uvre plusieurs types de communications synchrone ou asynchrone entre applications. Elle est complètement intégrée aux différents services de la plate-forme : les EJB, bien sûr, ainsi que JDBC (Java Database Connectivity) pour l’accès aux sources de données, JTS (Java Transaction Services) pour la gestion des transactions, et JNDI (Java Naming and Directory Services) pour les fonctions d’annuaire. JMS peut prendre en compte différents modèles de messagerie. Dans le mode “point à point “, les messages sont directement écrits dans la file d’attente d’une application cible. Le mode “publier/s’abonner” privilégie la notion de sujet (“topic”) publié par l’émetteur, auquel peuvent s’abonner un ou plusieurs destinataire(s). JMS propose une interface spécifique pour chaque mode. Ce qui permet d’interagir avec des systèmes n’offrant pas la totalité de ces modes. JMS a profondément modifié le paysage du middleware asynchrone. Elle est devenue une interface obligatoire pour ces systèmes. Propulsant sur le devant de la scène des acteurs comme Sonic, qui propose, avec SonicMQ, une implémentation complète, et oblige IBM à enrober son MQSeries avec des interfaces adaptées.
JCA, l’ouverture vers l’existant
Comment devenir le pivot de l’informatique d’entreprise sans se donner les moyens de se placer en fédérateur des grands progiciels ? Sans parler des applications transactionnelles qui forment l’ossature des systèmes d’information… C’est l’ambition de JCA (Java Connector Architecture), un élément à part entière de J2EE 1.3. Il s’agit d’une interface banalisant, pour le développeur Java, l’accès à des ressources extérieures. Dans la pratique, l’utilisation de JCA au sein de la plate-forme J2EE passe par un adaptateur de ressources dédié à un progiciel spécifique. Plusieurs adaptateurs peuvent être intégrés au serveur d’applications. Ces adaptateurs sont accessibles via une interface unique, CCI (Common Client Interface). La base de la communication est le contrat passé entre la plate-forme et le progiciel ou l’application dans trois domaines : les connexions, les transactions et la sécurité. JCA assure la création, la gestion et, éventuellement, le regroupement des connexions. Il permet aussi d’installer des sondes pour intercepter des événements ?” en particulier les erreurs ?” en vue d’y répondre. Les transactions peuvent être locales ou distribuées, via des interfaces standards, telle XA. Enfin, le contrat de sécurité permet de transmettre au progiciel toutes les informations d’identification nécessaires.
JDO : la persistance n’est pas que pour les EJB
Si les EJB disposent de leurs propres modes de gestion de la persistance, il n’en allait pas de même pour les autres objets Java. Pour ceux-ci, demeurait la problématique du “mapping “, c’est-à-dire de l’établissement d’une correspondance entre les données stockées dans la base ou le fichier et le modèle des objets Java. Dans bien des cas, il fallait coder “en dur” les appels JDBC, en prenant le risque de modifier la structure de données. C’est pour bonifier cette pratique qu’est née JDO (Java Data Objects), qui vient d’être acceptée par la communauté Java. JDO n’est pas seulement une API comme d’autres ajouts à J2EE. Ce service propose un ensemble de fonctions dédiées au mapping et à l’accès aux données. Et ce quel que soit le mode de programmation utilisé ?” EJB ou non. Ses promoteurs ne sont d’ailleurs pas certains de souhaiter voir JDO intégrée à la plate-forme J2EE. Une grande partie des programmes Java ne sont pas à base d’EJB, et de nombreuses opportunités apparaissent ?” en particulier dans le secteur embarqué avec J2ME. Pour le développeur, JDO, qui s’appuie d’ailleurs sur JDBC, se traduit par une phase de compilation additionnelle, qui va intégrer au “bytecode” les instructions de mapping décrites. Avec JDO, toute classe Java devient potentiellement persistante, via des supports de stockage aussi divers que des moniteurs transactionnels, des SGBD, ou encore des fichiers plats. Malgré ces précautions, JDO peut être perçu comme une concurrente des solutions proposées par les EJB ?” en particulier du mode CMP (Container Managed Persistence). A charge, pour ses promoteurs, de lever les doutes.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
