Guide du débutant sur les Enterprise JavaBeans

Enterprise JavaBeans (EJB) a suscité beaucoup d'enthousiasme depuis l'annonce de mars 1998 de la version 1.0 de la spécification Enterprise JavaBeans. Des sociétés telles qu'Oracle, Borland, Tandem, Symantec, Sybase et Visigenic, entre autres, ont annoncé et / ou livré des produits conformes aux spécifications EJB. Ce mois-ci, nous allons jeter un regard de haut niveau sur ce qu'est exactement Enterprise JavaBeans. Nous verrons en quoi EJB diffère du modèle de composant JavaBeans original et expliquerons pourquoi EJB a généré un intérêt si énorme.

Mais d'abord, un conseil: nous ne regarderons pas le code source ou les sujets pratiques ce mois-ci. Cet article n'est pas un tutoriel; c'est plutôt un aperçu architectural. EJB couvre beaucoup de territoire, et sans d'abord comprendre les concepts de base impliqués, les extraits de code et les astuces de programmation n'ont aucun sens. Si les lecteurs de JavaWorld sont intéressés , les prochains articles pourront couvrir les spécificités de l 'utilisation de l' API Enterprise JavaBeans pour créer vos propres Enterprise JavaBeans.

Afin de comprendre pourquoi l'EJB est si attrayant pour les développeurs, nous avons besoin d'un historique. Tout d'abord, nous examinerons l'historique des systèmes client / serveur et l'état actuel des choses. Ensuite, nous discuterons des différentes parties d'un système EJB: les composants EJB - qui vivent sur un conteneur EJB s'exécutant à l'intérieur d'un serveur EJB - et les objets EJB, que le client utilise comme une sorte de "contrôle à distance" des composants EJB . Nous allons passer en revue les deux types d'EJB: les objets session et entité . Vous lirez également sur la maison et la télécommandeles interfaces, qui créent des instances EJB et donnent respectivement accès aux méthodes métier de l'EJB. À la fin de l'article, vous aurez une idée de la manière dont les serveurs extensibles peuvent être créés à l'aide d'Enterprise JavaBeans. Mais d'abord, un retour dans le temps.

Historique client / serveur

Histoire ancienne

Au début, il y avait l'ordinateur central. Et c'était bon. (Ou aussi bon que ce soit, de toute façon.) L'état de l'art dans le traitement de l'information dans les années 1960 consistait principalement en de grosses machines coûteuses utilisées par les grandes organisations pour soutenir leurs opérations commerciales quotidiennes. Les mini-ordinateurs et le partage de temps dans les années 1970 ont augmenté l'accessibilité de la puissance de calcul, mais l'information et le traitement étaient encore centralisés sur des machines individuelles. Les premiers ordinateurs personnels des années 1980 ont rapidement encombré le paysage de l'entreprise avec des milliers de minuscules îlots d'informations, produisant tous inlassablement des rapports de qualité variable, perdant des données critiques en cas de panne et devenant rapidement incompatibles les uns avec les autres.

Client / serveur à la rescousse

L'architecture client / serveur est l'une des solutions les plus courantes à l'énigme de la gestion du besoin à la fois d'un contrôle centralisé des données et d'une accessibilité généralisée des données. Dans les systèmes client / serveur, les informations sont maintenues relativement centralisées (ou sont partitionnées et / ou répliquées entre des serveurs distribués), ce qui facilite le contrôle et la cohérence des données, tout en fournissant un accès aux données dont les utilisateurs ont besoin.

Les systèmes client-serveur sont désormais généralement composés de différents nombres de niveaux. L'ancien ordinateur central standard ou système de partage de temps, où l'interface utilisateur s'exécute sur le même ordinateur que la base de données et les applications d'entreprise, est appelé un seul niveau. De tels systèmes sont relativement faciles à gérer et la cohérence des données est simple car les données sont stockées à un seul endroit. Malheureusement, les systèmes à un seul niveau ont une évolutivité limitée et sont sujets à des risques de disponibilité (si un ordinateur est en panne, toute votre entreprise tombe en panne), en particulier si la communication est impliquée.

Les premiers systèmes client / serveur étaient à deux niveaux, dans lesquels l'interface utilisateur s'exécutait sur le client et la base de données vivait sur le serveur. De tels systèmes sont encore courants. Un type de serveur à deux niveaux de type jardin exécute la plupart de la logique métier sur le client, mettant à jour les données partagées en envoyant des flux de SQL au serveur. Il s'agit d'une solution flexible, car la conversation client / serveur se déroule au niveau de la langue de la base de données du serveur. Dans un tel système, un client correctement conçu peut être modifié pour refléter les nouvelles règles et conditions commerciales sans modifier le serveur, à condition que le serveur ait accès au schéma de base de données (tables, vues, etc.) nécessaire pour effectuer les transactions. Le serveur d'un tel système à deux niveaux est appelé un serveur de base de données, comme illustré ci-dessous.

Les serveurs de base de données ont cependant certaines responsabilités. Souvent, le SQL d'une fonction métier particulière (par exemple, l'ajout d'un élément à une commande) est identique, à l'exception des données mises à jour ou insérées, d'un appel à l'autre. Un serveur de base de données finit par analyser et réanalyser un SQL presque identique pour chaque fonction métier. Par exemple, toutes les instructions SQL permettant d'ajouter un article à une commande sont susceptibles d'être très similaires, tout comme les instructions SQL permettant de rechercher un client dans la base de données. Le temps que prend cette analyse serait mieux dépensé pour traiter les données. (Il existe des solutions à ce problème, y compris les caches d'analyse SQL et les procédures stockées.) Un autre problème qui se pose est le contrôle de version des clients et de la base de données en même temps: toutes les machines doivent s'arrêter pour les mises à niveau,et les clients ou serveurs en retard dans leur version logicielle ne sont généralement pas utilisables tant qu'ils ne sont pas mis à niveau.

Serveurs d'applications

Une architecture de serveur d'applications (voir l'image suivante) est une alternative populaire à une architecture de serveur de base de données car elle résout certains des problèmes rencontrés par les serveurs de base de données.

Un environnement de serveur de base de données exécute généralement des méthodes commerciales sur le client et utilise le serveur principalement pour la persistance et l'application de l'intégrité des données. Dans un serveur d'applications, les méthodes métier s'exécutent sur le serveur et le client demande au serveur d'exécuter ces méthodes. Dans ce scénario, le client et le serveur utilisent généralement un protocole qui représente une conversation au niveau des transactions commerciales, plutôt qu'au niveau des tables et des lignes. Ces serveurs d'applications fonctionnent souvent mieux que leurs homologues de base de données, mais ils souffrent toujours de problèmes de version.

Les systèmes de base de données et d'application peuvent être améliorés en ajoutant des niveaux supplémentaires à l'architecture. Les systèmes dits à trois niveaux placent un composant intermédiaire entre le client et le serveur. Toute une industrie - le middleware - a surgi pour faire face aux responsabilités des systèmes à deux niveaux. Un moniteur de traitement des transactions,un type de middleware, reçoit des flux de demandes de nombreux clients et peut équilibrer la charge entre plusieurs serveurs, fournir un basculement en cas de défaillance d'un serveur et gérer les transactions au nom d'un client. D'autres types de middleware fournissent la traduction de protocole de communication, consolident les demandes et les réponses entre les clients et plusieurs serveurs hétérogènes (ceci est particulièrement populaire dans le traitement des systèmes hérités lors de la réingénierie des processus métier) et / ou fournissent des informations de mesure de service et de trafic réseau.

Les niveaux multiples offrent une flexibilité et une interopérabilité qui ont abouti à des systèmes avec plus de ces trois couches de service. Par exemple, les systèmes à n niveaux sont des généralisations de systèmes à trois niveaux, chaque couche de logiciel fournissant un niveau de service différent aux couches supérieures et inférieures. La perspective à n niveaux considère le réseau comme un pool de services distribués, plutôt que comme un simple moyen pour un client d'accéder à un serveur unique.

À mesure que les langages et les techniques orientés objet sont devenus en vogue, les systèmes client / serveur ont de plus en plus évolué vers l'orientation objet. CORBA (Common Object Request Broker Architecture) est une architecture qui permet aux objets dans les applications - même des objets écrits dans différents langages - de s'exécuter sur des machines séparées, en fonction des besoins d'une application donnée. Les applications écrites il y a des années peuvent être conditionnées en tant que services CORBA et interagir avec de nouveaux systèmes. Enterprise JavaBeans, qui est conçu pour être compatible avec CORBA, est une autre entrée dans l'anneau de serveur d'applications orienté objet.

Le but de cet article n'est pas de fournir un tutoriel sur les systèmes client / serveur, mais il était nécessaire de fournir des informations générales afin de définir le contexte. Voyons maintenant ce que l'EJB a à offrir.

Enterprise JavaBeans et serveurs d'applications extensibles

Maintenant que nous avons regardé un peu d'histoire et que nous comprenons ce que sont les serveurs d'applications, regardons les Enterprise JavaBeans et voyons ce qu'ils offrent dans ce contexte.

L'idée de base derrière Enterprise JavaBeans est de fournir un cadre pour les composants qui peuvent être "connectés" à un serveur, étendant ainsi les fonctionnalités de ce serveur. Enterprise JavaBeans est similaire aux JavaBeans d'origine uniquement en ce qu'il utilise des concepts similaires. La technologie EJB n'est pas régie par la spécification des composants JavaBeans, mais par la spécification Enterprise JavaBeans entièrement différente (et massive) . (Voir Ressources pour plus de détails sur cette spécification.) La spécification EJB appelle les différents acteurs du système client / serveur EJB, décrit comment EJB interagit avec le client et avec les systèmes existants, précise la compatibilité d'EJB avec CORBA, et définit les responsabilités pour les différents composants du système.

Objectifs d'Enterprise JavaBeans

La spécification EJB essaie d'atteindre plusieurs objectifs à la fois:

  • EJB est conçu pour permettre aux développeurs de créer facilement des applications, en les libérant des détails système de bas niveau de la gestion des transactions, des threads, de l'équilibrage de charge, etc. Les développeurs d'applications peuvent se concentrer sur la logique métier et laisser les détails de la gestion du traitement des données au framework. Pour les applications spécialisées, cependant, il est toujours possible de «passer sous le capot» et de personnaliser ces services de niveau inférieur.

  • La spécification EJB définit les principales structures du cadre EJB, puis définit spécifiquement les contrats entre elles. Les responsabilités du client, du serveur et des composants individuels sont toutes clairement définies. (Nous reviendrons sur ce que sont ces structures dans un instant.) Un développeur créant un composant Enterprise JavaBean a un rôle très différent de celui qui crée un serveur compatible EJB, et la spécification décrit les responsabilités de chacun.

  • EJB vise à être le moyen standard pour les applications client / serveur d'être construites dans le langage Java. Tout comme les JavaBeans originaux (ou les composants Delphi, ou autre) de différents fournisseurs peuvent être combinés pour produire un client personnalisé, les composants serveur EJB de différents fournisseurs peuvent être combinés pour produire un serveur personnalisé. Les composants EJB, qui sont des classes Java, fonctionneront bien sûr dans n'importe quel serveur compatible EJB sans recompilation. C'est un avantage que les solutions spécifiques aux plates-formes ne peuvent pas espérer offrir.

  • Enfin, l'EJB est compatible et utilise d'autres API Java, peut interagir avec des applications non Java et est compatible avec CORBA.

Fonctionnement d'un système client / serveur EJB

Pour comprendre le fonctionnement d'un système client / serveur EJB, nous devons comprendre les éléments de base d'un système EJB: le composant EJB, le conteneur EJB et l'objet EJB.

Le composant Enterprise JavaBeans

Un Enterprise JavaBean est un composant, tout comme un JavaBean traditionnel. Les Enterprise JavaBeans s'exécutent dans un conteneur EJB, qui à son tour s'exécute dans un serveur EJB. Tout serveur qui peut héberger un conteneur EJB et lui fournir les services nécessaires peut être un serveur EJB. (Cela signifie que de nombreux serveurs existants peuvent être étendus pour devenir des serveurs EJB, et en fait, de nombreux fournisseurs ont atteint cet objectif ou ont annoncé leur intention de le faire.)

Un composant EJB est le type de classe EJB le plus susceptible d'être considéré comme un "Enterprise JavaBean". C'est une classe Java, écrite par un développeur EJB, qui implémente la logique métier. Toutes les autres classes du système EJB prennent en charge l'accès client ou fournissent des services (comme la persistance, etc.) aux classes de composants EJB.

Le conteneur Enterprise JavaBeans

Le conteneur EJB est l'endroit où le composant EJB "vit". Le conteneur EJB fournit des services tels que la gestion des transactions et des ressources, la gestion des versions, l'évolutivité, la mobilité, la persistance et la sécurité aux composants EJB qu'il contient. Étant donné que le conteneur EJB gère toutes ces fonctions, le développeur du composant EJB peut se concentrer sur les règles métier et laisser la manipulation de la base de données et d'autres détails de ce type au conteneur. Par exemple, si un seul composant EJB décide que la transaction en cours doit être abandonnée, il indique simplement son conteneur (d'une manière définie par la spécification EJB, et le conteneur est responsable de l'exécution de toutes les annulations, ou de tout ce qui est nécessaire pour annuler un transaction en cours. Plusieurs instances de composant EJB existent généralement dans un même conteneur EJB.

L'objet EJB et l'interface distante

Les programmes client exécutent des méthodes sur des EJB distants via un objet EJB. L'objet EJB implémente "l'interface distante" du composant EJB sur le serveur. L'interface distante représente les méthodes "métier" du composant EJB. L'interface à distance effectue le travail réel et utile d'un objet EJB, comme la création d'un bon de commande ou le transfert d'un patient à un spécialiste. Nous discuterons de l'interface distante plus en détail ci-dessous.