Depuis 1998, les composants Enterprise JavaBeans (EJB) ont fait des émules. Avec l’apparition des e-market places dédiées aux composants, un nouveau marché d’EJB voit le jour. Les éditeurs de serveurs d’applications, tels BEA Systems, IBM ou Oracle, disposent de composants EJB couplés à leur offre de serveurs d’applications. D’autres firmes, ComponentSource, Eontec, Flashline ou Unify, proposent des jeux de composants EJB indépendants des éditeurs de serveurs.
Asynchronisme et qualité de délivrance
La non-portablité de ces EJB entre les différents serveurs d’applications freine pourtant leur essor. La version 1.1 avait apporté de nombreuses précisions et rendu obligatoires les EJB de type entité. Le Deployathon 2000, consistant à faire tourner les mêmes composants sur différents serveurs d’applications, a été plus facile à réaliser. Néanmoins, les EJB 1.1 restent plus transportables que portables entre les serveurs. Lors du salon Java One 2000, Sun Microsystems a mis à disposition des internautes la version provisoire de la spécification des EJB 2.0. Trois innovations ont été introduites. La première a consisté en l’intégration de l’asynchronisme dans les dialogues avec les EJB grâce à JMS (Java messagery service) et aux middlewares de Message queuing et de publication-abonnement. Couplé à la garantie de délivrance induite par ces middlewares, cela autorise le découplage des clients dans les traitements back-end effectués sur une commande, ou la prise en compte de clients déconnectés, comme les utilisateurs de téléphones mobiles.
Les relations entre EJB désormais gérées
Une autre avancée des EJB 2.0 est la spécification plus complète de la gestion automatique, par le conteneur, de la persistance des EJB de type entité, représentant les données persistantes. Avec les EJB 1.1, la CMP (Container managed persistence) était trop simple. Cela a entraîné des divergences dans sa mise en ?”uvre. Avec les EJB 2.0, la gestion automatique de la persistance prend en compte les modèles objets complexes, ainsi que les relations entre les EJB, ce qui devrait avoir pour conséquence une simplification du code source des EJB de type entité et, donc, une meilleure portabilité. La gestion des relations entre EJB par le conteneur permet d’éviter de coder des mises à jour des EJB dans les différents SGDBD sous-jacentes. Le passage d’une commande par un internaute génère ainsi les mises à jour en SGBD de l’inventaire, des commandes à fournir, du fichier clients, etc.
La déclaration de relations entre les EJB clients et commandes entraîne des mises à jour automatiques en SGBD (l’entrée d’une commande dans le SGBD des commandes implique la mise à jour automatique de celui des clients).
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
