Concept: Présentation de Java 2 Platform Enterprise Edition (J2EE)
Ces instructions offrent une présentation complète de la plateforme J2EE.
Relations
Eléments connexes
Description principale

Introduction

Dans le monde actuel de l'e-business, où les applications réparties complexes évoluent à vive allure, la commercialisation rapide de vos applications d'entreprise est un enjeu crucial. Votre équipe projet ne peut donc se permettre de passer du temps à développer des services au niveau du système, tels que la connectivité à distance, le nommage, la persistance, la sécurité ou la gestion des transactions. Elle doit développer et se servir de composants portables et réutilisables. Votre but n'est pas de perdre du temps à réinventer des architectures existantes et éprouvées.

La plateforme Java™ 2 Platform, Enterprise Edition (J2EE™), répond à ce besoin grâce à une infrastructure très documentée et normalisée, utile au développement et à l'exécution d'applications Java réparties multiniveau et fondées sur des composants. Cette infrastructure gère une grande partie des détails complexes de l'application, telle que la connectivité à distance, le nommage, la persistance, la sécurité et la gestion des transactions, permettant aux développeurs de se concentrer librement sur la logique métier de l'application.

La plateforme J2EE comprend :

  • Un ensemble de normes pour les composants J2EE et la plateforme J2EE sur laquelle ils sont exécutés.
  • Un Blueprint pour le développement d'une application, qui décrit la plateforme J2EE en détail et présente les meilleures pratiques et les points forts du secteur relatifs au développement d'applications J2EE.
  • Une implémentation référentielle de la plateforme J2EE, livrée par Sun Microsystems Inc. en tant que norme de comparaison pour les produits J2EE commerciaux. Cette implémentation contient des modèles d'application entièrement développés.
  • Une suite de tests de compatibilité permettant de tester et d'évaluer les implémentations J2EE commerciales par rapport aux normes J2EE.

La plateforme J2EE offre des services analogues à ceux du système d'exploitation de votre ordinateur : à l'aide d'outils de programmation, le système d'exploitation fournit des services standard à partir desquels vous pouvez développer et exécuter des applications sans vous soucier des détails annexes, comme la gestion de l'accès au disque, de la mémoire, de la sortie vidéo, du réseau, etc. Vous vous occupez des détails de l'application, et non de ceux du système sous-jacent. Il en va de même pour la plateforme J2EE, qui offre un système d'exploitation sophistiqué pour les applications d'entreprise.

Grâce à cette plateforme, vous simplifiez votre effort de développement et permettez à votre équipe projet d'utiliser toute son énergie sur la logique métier de l'application, au lieu de sacrifier du temps de développement crucial à la résolution de problèmes au niveau du système. Une équipe projet qui peut se concentrer sur ce que fait l'application, plutôt que sur la livraison de tous les services sous-jacents requis, est bien plus susceptible de livrer un système à temps, sans bogue, et répondant aux exigences de l'utilisateur.

Pour plus d'informations, reportez-vous à la présentation de Sun concernant la plateforme J2EE, sur le site http://java.sun.com/. Suivez les liens Products & APIs > Java™ 2 Platform, Enterprise Edition (J2EE™) > Overview.

Le développement J2EE en un clin d'oeil

Du point de vue du développeur d'applications :

  • Vous achetez une plateforme commerciale J2EE sous la forme d'un serveur compatible J2EE. Le comportement de ce serveur est spécifié par la norme J2EE.
  • Vous achetez des composants J2EE commerciaux ou les développez.
  • Vous déployez et exécutez vos composants J2EE sur votre serveur compatible J2EE, qui fournit tous les services requis par ces composants.

Exemple

Exemple simple d'application J2EE : un site de commerce électronique, sur lequel un client (utilisateur) se sert d'un navigateur Web pour accéder à distance à un serveur J2EE. Ce serveur fournit des services niveau Web et niveau métier, et interagit avec un niveau système d'information d'entreprise (dorsal) qui permet l'accès au système de gestion de base de données relationnelle (SGBDR).

Pourquoi utiliser J2EE ?

Vous souhaiterez utiliser la plateforme J2EE pour le développement de votre application Java e-commerce ou d'entreprise si vous vous trouvez dans l'une des situations suivantes :

Chacun de ces points est abordé plus en détail ci-après.

Infrastructure normalisée et éprouvée

Les composants J2EE sont exécutés dans des conteneurs J2EE, généralement livrés avec le serveur compatible J2EE. Ces conteneurs fournissent un ensemble de services standard (API) utilisés par les composants. Ces API sont les suivantes :

  • J2SE 1.4
    • JDBC
    • Java IDL
    • Remote Method Invocation with CORBA's Internet Inter-ORB Protocol (RMI-IIOP)
    • Java Naming and Directory Interface (JNDI)
    • Java Authentication and Authorization Service (JAAS)
  • Java Transaction API (JTA)
  • JavaMail
  • Java Message Service (JMS).
    Pour plus d'informations sur JMS, reportez-vous à Concept : Java Messaging Service (JMS).
  • JavaBeans Activation Framework (JAF)
  • Enterprise JavaBeans (EJB)
  • Java Servlet
  • Java API for XML Processing (JAXP)
  • Java Connector (Remarque : non pris en charge par les versions antérieures à J2EE 1.3)
  • JavaServer Pages (JSP)
  • Web Services for J2EE (Remarque : non pris en charge par les versions antérieures à J2EE 1.4)
  • Java API for XML-based RPC (JAX-RPC) (Remarque : non pris en charge par les versions antérieures à J2EE 1.4)
  • SOAP with attachments API for Java (SAAJ) (Remarque : non pris en charge par les versions antérieures à J2EE 1.4)
  • Java API for XML Registries (JAXR) (Remarque : non pris en charge par les versions antérieures à J2EE 1.4)
  • J2EE Management (Remarque : non pris en charge par les versions antérieures à J2EE 1.4)
  • Java Management Extensions (JMX) (Remarque : non pris en charge par les versions antérieures à J2EE 1.4)
  • J2EE Deployment (Remarque : non pris en charge par les versions antérieures à J2EE 1.4)
  • Java Authorization Service Provider Contract for Containers (JACC) (Remarque : non pris en charge par les versions antérieures à J2EE 1.4)

Portabilité

Les composants et applications J2EE étant portables d'un serveur compatible J2EE à un autre sans nécessiter de modification de code, vous pouvez déployer votre application sur le serveur de votre choix en mettant simplement à jour les informations de déploiement spécifiques au serveur, contenues dans les fichiers eXtended Markup Language (XML) du descripteur de déploiement.

La normalisation de la spécification J2EE a alimenté la concurrence ; vous disposez donc d'une gamme de serveurs compatibles J2EE en fonction de vos besoins et de votre budget.

Composants réutilisables

Etant conformes à la norme J2EE, les composants J2EE peuvent être achetés dans le commerce et ajoutés à votre application J2EE selon vos souhaits, ce qui vous permet de réaliser un gain d'effort de développement (en particulier de débogage et de test).

Si vous développez un composant, vous pouvez le réutiliser dans une autre application ou le déployer sur différents serveurs compatibles J2EE, comme vous le souhaitez.

Patterns de conception et architecture éprouvés

La plateforme J2EE définit une architecture d'application multiniveau bien structurée. En optimisant l'architecture J2EE, vos développeurs peuvent commencer à développer immédiatement la logique métier de l'application.

La documentation J2EE comprend :

  • Un Blueprint pour le développement d'une application, qui décrit la plateforme J2EE en détail et présente les meilleures pratiques relatives au développement d'applications J2EE.
  • Des patterns J2EE très documentés (les meilleures pratiques du secteur) qui décrivent des solutions aux problèmes courants de conception et d'architecture.

Pour plus d'informations sur la plateforme J2EE, reportez-vous à l'adresse http://java.sun.com/. Suivez les liens J2EE > Blueprints.

Evolutivité

J2EE prend en charge l'évolutivité de plusieurs manières, vous permettant ainsi d'augmenter vos performances ou de faire face à des charges croissantes :

  • Fonctions d'amélioration des performances dans le conteneur J2EE : ces fonctions comprennent le regroupement de ressources (regroupements de connexions à une base de données, d'instances de beans session et d'unités d'exécution), l'envoi de messages asynchrones et la gestion efficace des cycles de vie des composants. Par exemple, l'ouverture d'une connexion à une base de données est lente. De plus, les connexions à la base de données peuvent constituer une ressource rare, en raison de restrictions de licence par exemple. La plateforme J2EE gère ces inconvénients à l'aide du regroupement de connexions à une base de données. Le conteneur J2EE maintient un groupe de connexions ouvertes qui peuvent être affectées à un composant de votre choix, pour rendre les connexions plus rapides et plus efficaces.
  • Possibilité d'équilibrer la charge grâce à une mise en cluster (déploiement des mêmes composants vers plusieurs serveurs sur différentes machines). La charge à attribuer à chacun des serveurs peut alors être équilibrée comme vous le souhaitez, par exemple, selon un algorithme de permutation circulaire ou selon la charge du serveur. La spécification de la plateforme J2EE n'exige pas l'existence de cette fonction d'équilibrage sur un serveur J2EE, mais elle la recommande pour les serveurs haut de gamme. Les fournisseurs de serveurs J2EE offrent diverses solutions d'équilibrage de charge.
  • Partitionnement de l'application : des portions logiquement distinctes d'une application peuvent être déployées sur différents serveurs ; par exemple, pour une application de commande en ligne par messagerie électronique, le déploiement des sous-systèmes de comptabilité et celui des sous-systèmes d'inventaire peuvent être effectués sur des serveurs séparés.

Outils de développement et de déploiement

Les fournisseurs ont répondu au besoin en outils J2EE en offrant une excellente prise en charge du développement J2EE dans leurs environnements de développement intégrés Java (IDE), qui comprennent :

  • Des assistants pour la création de servlets
  • Des assistants et boîtes de dialogue pour la création et la maintenance d'EJB
  • La génération et la maintenance de descripteurs de déploiement
  • Un mappage objet EJB-base de données (incluant la génération d'informations de descripteur de déploiement pour les relations gérées par conteneur)
  • L'intégration d'un conteneur Web pour le test des services Web
  • La transparence du déploiement, du débogage et du test des EJB au sein de l'IDE, grâce à l'intégration d'un conteneur d'EJB J2EE et de ses outils de déploiement.
  • La génération automatique de clients de test J2EE
  • L'intégration d'outils de modélisation UML

Intégration du niveau dorsal

Le niveau dorsal désigne le niveau système d'information d'entreprise (EIS) de l'application. Les systèmes dorsaux peuvent être par exemple des SGBDR, des systèmes en vigueur ou des systèmes de planning des ressources d'entreprise (ERP).

J2EE prend en charge l'accès transactionnel aux EIS de type SGBDR à l'aide de la connectivité JDBC et des API JTA. De plus, les conteneurs EJB prennent en charge la persistance gérée par conteneur, dans laquelle le conteneur gère automatiquement la connexion et l'accès transactionnels à un SGBDR.

L'interface Service Provider Interface (SPI) de l'architecture J2EE Connector définit quant à elle une norme pour la connexion des autres types de ressources EIS à un conteneur J2EE. Un adaptateur de ressources spécifique à l'EIS (livré par le fournisseur d'EIS) étend le conteneur J2EE pour lui permettre d'offrir une prise en charge transactionnelle et sûre de cet EIS. Les composants du conteneur peuvent alors y accéder par le biais de l'interface SPI de l'architecture J2EE Connector.

Remarque : l'interface SPI de l'architecture J2EE Connector n'est pas prise en charge par les versions antérieures à J2EE 1.3.

Sécurité

J2EE offre des fonctions de sécurité simples et puissantes. Les informations de sécurité pour les composants J2EE sont définies dans les descripteurs de déploiement. Ces informations définissent les rôles de sécurité autorisés à accéder à un URL particulier et/ou aux méthodes d'un composant. Un rôle de sécurité n'est qu'un nom logique pour un regroupement d'utilisateurs. Par exemple, les membres de l'équipe de direction d'une organisation peuvent se voir attribuer à tous un rôle intitulé "dirigeants".

Les informations de sécurité étant déclarées dans le descripteur de déploiement, le comportement de sécurité peut être modifié sans passer par un cycle coûteux de mise à jour, débogage et test du code.

Architecture multiniveau

J2EE est une architecture d'application répartie multiniveau : elle comprend un niveau client, un niveau intermédiaire et un niveau EIS ou dorsal.

La figure 1 représente l'architecture multiniveau de la plateforme J2EE, ainsi que les différents conteneurs J2EE qui prennent en charge les composants J2EE.

Diagramme décrit dans le texte d'accompagnement.

Figure 1 : Architecture multiniveau J2EE

Niveau client

Les composants du niveau client sont exécutés dans les conteneurs de clients. Les implémentations possibles du niveau client sont les suivantes :

  • Applications Java autonomes : il s'agit généralement d'une interface graphique (également appelée "client lourd"). Une telle application doit être installée sur toutes les machines client. Une application Java peut accéder au niveau EIS ou au niveau intermédiaire par des API telles que la connectivité JDBC.
  • Pages HTML statiques : elles offrent une interface graphique limitée pour une application.
  • Pages HTML dynamiques : elles sont générées par des pages JSP ou des servlets.
  • Applets : elles sont exécutées dans un navigateur Web. Les applets sont imbriquées dans une page HTML et sont généralement utilisées pour fournir une interface graphique.

Niveau intermédiaire

Le niveau intermédiaire comprend le niveau Web et le niveau métier. Tandis que les composants du niveau Web sont exécutés dans un serveur Web J2EE qui offre un conteneur Web, les composants du niveau métier sont exécutés dans un serveur d'applications J2EE qui offre un conteneur d'EJB.

Niveau Web

Les composants du niveau Web sont des servlets et des pages JSP, qui gèrent l'interaction avec le niveau client en isolant les clients du niveau métier et du niveau EIS. Les clients émettent des requêtes sur le niveau Web, celui-ci les traite puis renvoie les résultats aux clients. Les requêtes des clients adressées à des composants du niveau Web entraînent généralement l'envoi de requêtes par le niveau Web vers le niveau métier, qui peut entraîner à son tour l'envoi de requêtes vers le niveau EIS.

Niveau métier

Les composants du niveau métier sont les EJB.

  • Ils contiennent la logique métier de l'application.
  • Ils émettent des requêtes auprès du niveau EIS selon la logique métier, généralement en réponse à une requête du niveau Web.

Niveau EIS

Le niveau EIS représente les données stockées de l'application, souvent sous la forme d'un SGBDR. Le niveau EIS peut également comprendre des systèmes en vigueur ou des plannings ERP, auxquels donne accès l'API de l'architecture J2EE Connector.

Pour plus d'informations sur l'API de l'architecture J2EE Connector, reportez-vous à l'adresse http://java.sun.com/. Suivez les liens Products & Technologies > J2EE > J2EE Connector Architecture.

Pour plus d'informations sur les configurations de déploiement standard de J2EE, reportez-vous à Concept : Configurations de déploiement J2EE.

Serveurs J2EE

Les serveurs J2EE sont des produits commerciaux qui implémentent la plateforme J2EE. BEA WebLogic, Borland Enterprise Server, IBM WebSphere et iPlanet sont des exemples de serveurs J2EE.

L'usage du terme "serveur J2EE" est quelque peu laxiste. Habituellement, il désigne "un serveur J2EE qui prend en charge un conteneur Web et un conteneur d'EJB". Selon une terminologie plus stricte, un serveur Web J2EE (tel que Tomcat, l'implémentation de référence du serveur Web J2EE) prend en charge un conteneur Web, tandis qu'un serveur d'applications (ou d'EJB) J2EE prend en charge un conteneur d'EJB.

Conteneurs J2EE

Les composants J2EE sont exécutés dans, ou hébergés par des conteneurs J2EE habituellement inclus dans un serveur J2EE commercial. Les conteneurs prennent non seulement en charge les API J2SE standard, mais offrent également un environnement d'exécution et un ensemble standard de services (API) aux composants J2EE.

La plateforme J2EE définit les types suivants de conteneurs :

Conteneur de clients d'application

Un client d'application J2EE est exécuté dans un conteneur de clients d'application, qui prend en charge les API J2EE suivantes : JDBC, JMS, JAXP, JAAS, JavaMail, JAF, JSR, JAX-RPC, SAAJ, J2EE Management et JMX.

Les conteneurs de clients d'application sont constitués d'une installation J2SE standard. Ils doivent prendre en charge l'interface de gestionnaire d'appel JAAS pour respecter les contraintes de sécurité du reste de l'application d'entreprise dans les conteneurs Web et d'EJB.

Conteneur d'applets

Une applet est exécutée dans un conteneur d'applets, qui prend en charge le modèle de programmation d'applets et les API J2SE standard. Les conteneurs d'applets sont livrés en tant que plug-in Java de navigateur Web.

Conteneur Web

Les composants Web (pages JSP et servlets) sont exécutés dans un conteneur Web inclus dans un serveur J2EE ou livré en tant que serveur Web J2EE autonome. Un conteneur Web prend en charge les API et packages J2EE suivants : JDBC, JMS, JAXP, JAX-RPC, JAXR, JAAS, Java Mail, JAF, architecture J2EE Connector, JTA, JSR, SAAJ, J2EE Management, Java Servlet et JSP.

Conteneur d'EJB

Les composants EJB sont exécutés dans un conteneur d'EJB, inclus dans un serveur J2EE.

Un conteneur d'EJB prend en charge les API et technologies J2EE suivantes : EJB, JDBC, JMS, JAXP, JAX-RPC, JAXR, JAAS, Java Mail, JAF, JTA, JSR, SAAJ, J2EE Management et architecture J2EE Connector.

Les sous-sections suivantes résument les fonctionnalités clés prises en charge par les conteneurs d'EJB :

Communications distantes

Les conteneurs d'EJB cachent aux développeurs la complexité des communications distantes à l'aide des classes fournies par des conteneurs, qui implémentent les interfaces EJB (ces classes sont générées par des outils de conteneur lors de la compilation de l'EJB, parallèlement aux classes de remplacement RMI à l'usage des clients). Ces classes d'implémentation sont des objets Java distants auxquels un client peut accéder à l'aide de l'invocation Java RMI. De son côté, le client se contente d'appeler des méthodes sur l'interface EJB, sans se soucier des communications distantes.

Accès concurrent

Les conteneurs d'EJB gèrent de manière transparente les requêtes concurrentes provenant de plusieurs clients. Ces clients peuvent agir comme s'ils disposaient d'un accès exclusif à l'EJB. Par exemple, si deux clients émettent des requêtes sur le même EJB entity, le conteneur fournit à chacun sa propre instance et gère la synchronisation en interne, à l'insu des clients.

Nommage

Le conteneur d'EJB offre un espace nom JNDI pour la localisation des EJB déployés dans le conteneur. Les clients d'EJB peuvent rechercher des EJB pour obtenir une interface Home. Cette interface offre des méthodes de recherche et de création d'instances d'EJB. Tant que le contexte de nommage JNDI est disponible depuis l'emplacement des clients, ces derniers ont accès aux EJB.

Persistance

Les développeurs d'EJB peuvent choisir entre deux schémas de stockage pour les données rémanentes d'EJB entity : la persistance gérée par conteneur (CMP) et la persistance gérée par le bean (BMP). La persistance gérée par conteneur délègue au conteneur l'implémentation du code d'accès aux données, tandis que la persistance gérée par le bean laisse le soin d'implémenter ce code au développeur d'EJB. La persistance gérée par conteneur permet au développeur d'EJB d'utiliser une implémentation standard pour accéder au stockage des données rémanentes, en déclarant simplement les zones gérées par conteneur dans un descripteur de déploiement.

Gestion des transactions

Une transaction est une séquence d'opérations qui échoue ou est réussie dans son intégralité, de sorte que si une opération de la séquence échoue, l'état du système ne subit aucun changement. Supposons par exemple que vous souhaitiez émettre des billets d'avion. Vous valideriez le compte de carte de crédit d'un client, débiteriez ce compte, puis émettriez les billets. Cette séquence d'opérations devrait s'effectuer en une seule transaction, de sorte que, si une opération échouait, aucun changement ne serait effectué sur le compte de votre client et aucun billet ne serait émis.

Les EJB peuvent utiliser la démarcation des transactions gérée par le bean ou la démarcation des transactions gérée par conteneur. Ces deux méthodes sont décrites dans les sections ci-après.

Démarcation des transactions gérée par le bean

Dans la démarcation des transactions gérée par le bean, vous utilisez une simple API pour délimiter les frontières de la transaction. Il s'agit de Java Transaction API (JTA), que vous utilisez pour contrôler la démarcation des transactions au moyen de la programmation ; par exemple, en appelant les méthodes begin(), commit() et rollback() de l'interface JTA UserTransaction. C'est le développeur qui doit coder la logique d'annulation pour les conditions d'exception des transactions, car le conteneur ne les traite pas automatiquement.

Remarque : Les EJB Entity ne peuvent pas utiliser la démarcation des transactions gérée par le bean ; ils ne peuvent utiliser que la démarcation gérée par conteneur.

Démarcation des transactions gérée par conteneur

Dans la démarcation des transactions gérée par conteneur, vous ne fournissez pas de code pour commencer et terminer les transactions. En revanche, vous fournissez des informations sur l'attribut de transaction pour chaque méthode de votre EJB dans le descripteur de déploiement de beans EJB. L'attribut de transaction (Required, RequiresNew, NotSupported, Supports, Mandatory ou Never) indique au conteneur la portée de la transaction à utiliser pour la méthode. Par exemple, si un client est exécuté dans une transaction et qu'il appelle une méthode de votre EJB dont l'attribut est défini sur Required, cette méthode sera appelée dans la portée de la transaction existante.

Dans la mesure du possible, utilisez la démarcation des transactions gérée par conteneur de préférence à la démarcation gérée par le bean. Vous éviterez ainsi de devoir ajouter, déboguer et tester le code de démarcation dans votre composant. Le comportement de transaction de chaque méthode d'EJB est quant à lui spécifié lors du déploiement, dans le descripteur de déploiement. Ainsi, il peut être modifié sans passer par un cycle coûteux de mise à jour, débogage et test du code.

Transactions réparties

Une transaction répartie est une transaction qui doit être coordonnée sur plusieurs bases de données et/ou applications. Elle est à l'opposé d'une transaction centralisée (par exemple, une transaction validée par un seul serveur d'applications J2EE sur une seule base de données).

Les transactions réparties nécessitent une validation en deux phases (si plus d'une base de données est mise à jour, par exemple). Certains conteneurs d'EJB (tels que BEA WebLogic Server 6.0) prennent en charge ce type de validation, à l'aide du protocole XA d'Open Group. Le programmeur d'application n'a pas besoin d'écrire de code pour traiter la validation en deux phases ; c'est le conteneur d'EJB qui s'en charge.

Gestion de la sécurité

C'est le conteneur d'EJB qui gère la sécurité des EJB, à l'aide des informations de sécurité indiquées dans le descripteur de déploiement. Dans ce descripteur, vous déclarez un ensemble de rôles et, pour chaque méthode EJB, les rôles autorisés à l'appeler.

Lors de l'exécution, chaque client de l'EJB se voit attribuer un rôle, et le conteneur d'EJB gère l'accès aux méthodes de cet EJB en vérifiant que le rôle du client est autorisé à les appeler.

Les informations de sécurité étant déclarées dans le descripteur de déploiement, le comportement de sécurité peut être modifié sans passer par un cycle coûteux de mise à jour, débogage et test du code.

Gestion du cycle de vie

Au cours de leur cycle de vie, les EJB passent par une série d'états en réponse aux requêtes client. Le conteneur d'EJB est chargé de gérer ce cycle de vie.

Lors de son initialisation, le conteneur crée un pool d'instances EJB dans un pool de ressources (pour gagner du temps au démarrage lorsqu'une ressource EJB est requise). Lorsqu'un client demande la création d'un EJB, une instance du pool lui est attribuée. Il peut alors émettre des requêtes sur l'EJB. Lorsque ce client demande la suppression d'un EJB, l'instance retourne dans le pool.

Le conteneur notifie divers événements d'un cycle de vie d'EJB à une instance EJB, à l'aide d'un ensemble de méthodes de rappel standard, telles que :

  • ejbCreate() : appelée par le conteneur après la création d'une instance EJB
  • ejbRemove() : appelée par le conteneur juste avant la suppression d'une instance EJB
  • ejbActivate() : appelée par le conteneur lorsqu'une instance EJB n'est plus à l'état passif
  • ejbPassivate() : appelée par le conteneur juste avant la passivation de l'instance EJB
  • ejbStore() : appelée par le conteneur juste avant l'écriture de l'instance EJB dans une base de données
  • ejbLoad() : appelée par le conteneur après le chargement des zones d'une instance EJB depuis une base de données

Chaque EJB est nécessaire à l'implémentation de ces rappels, bien que l'implémentation par l'EJB de la méthode de rappel soit souvent vide. Par exemple, le conteneur appelle la méthode ejbRemove() de l'EJB pour lui notifier qu'il est sur le point d'être supprimé (suite à une requête client demandant sa suppression). Dans la méthode ejbRemove(), vous codez toutes les opérations nécessaires à la suppression de l'EJB, telles que la libération des ressources retenues par l'EJB.

Les EJB peuvent être mis à l'état passif (les informations d'état sont sauvegardées et l'instance d'EJB est libérée pour être utilisée par le pool) sur requête du conteneur. Un EJB mis à l'état passif sera activé (les informations d'état seront restaurées) par le conteneur s'il reçoit une requête client sur cet objet EJB particulier.

Regroupement de connexions à une base de données

L'ouverture d'une connexion à une base de données est lente. De plus, les connexions à la base de données peuvent constituer une ressource rare, en raison de restrictions de licence par exemple. Le conteneur d'EJB gère cet inconvénient grâce au regroupement de connexions à une base de données : il maintient un groupe de connexions ouvertes qui peuvent être affectées à un EJB de votre choix, pour rendre les connexions plus rapides et plus efficaces.

Pour les EJB entity qui utilisent la persistance gérée par conteneur, la gestion des connexions à une base de données est automatique. Aucun code SQL ou de connexion n'est nécessaire ; il vous suffit de spécifier le nom JNDI de la source de données JDBC dans le descripteur de déploiement de beans EJB et d'utiliser les outils de déploiement spécifiques au conteneur qui généreront les routines pour vous. C'est le conteneur qui gère le pool de connexions à une base de données.

En revanche, pour les EJB entity qui utilisent la persistance gérée par le bean ou pour les EJB session, vous devez écrire un code de connexion pour vous connecter à une source de données JDBC, et un code SQL pour accéder à la base de données. La source de données JDBC reste gérée par le conteneur ; elle utilise un pool de connexions à une base de données maintenu par le conteneur.

Messagerie

Les conteneurs d'EJB sont nécessaires à la prise en charge de l'échange asynchrone de messages. Le service JMS, ou d'autres types de messageries, peut être utilisé par les EJB gérés par message pour le traitement des messages livrés. Etant donné que ce service implique des EJB, il doit prendre en charge l'accès transactionnel à partir du Web ainsi que les composants du conteneur d'EJB, tels que les servlets, les pages JSP et les EJB.

Composants J2EE

La section suivante aborde brièvement tous les types de composants J2EE. Ces composants sont les applets, les clients d'application, les composants Web et les Enterprise JavaBeans. Ils sont exécutés dans des conteneurs J2EE.

Applets

Les applets sont de petits programmes qui peuvent être envoyés en même temps qu'une page Web et qui sont exécutés dans un navigateur Web. Elles peuvent également être exécutées dans d'autres environnements qui prennent en charge le modèle de programmation d'applets.

Principalement utilisées pour implémenter les interfaces utilisateur, les applets peuvent étendre considérablement les fonctions des pages HTML.

Clients d'application

Les clients d'application sont des applications Java. Ils ont accès aux fonctions des niveaux J2EE intermédiaire et EIS. Il s'agit généralement d'applications PC qui fournissent une interface utilisateur. Ils peuvent servir à implémenter un "client lourd", comme décrit dans le Concept : Patterns de répartition.

Composants Web

Java Servlets

La technologie Java Servlet permet à un serveur Web de traiter des requêtes provenant d'un client Web et de fournir des réponses à contenu dynamique. Un servlet Java peut interagir avec d'autres composants Web et EJB pour produire ce contenu dynamique. Le contenu généré peut prendre la forme d'un document texte quelconque utilisant les langages HTML et XML. Les servlets peuvent également être utilisés comme noeuds finaux de service Web en collaboration avec l'API JAX-RPC.

Remarque : l'utilisation d'un servlet en tant que noeud final de service Web est une nouvelle fonctionnalité de J2EE 1.4 (JAX-RPC 1.1) et n'est donc pas prise en charge par les versions antérieures.

Pour plus d'informations sur les servlets J2EE, reportez-vous à l'adresse http://java.sun.com/. Suivez les liens J2EE > Blueprints.

JavaServer Pages

La technologie JavaServer Pages (JSP) repose sur les servlets, mais elle est fondée sur du texte et non sur du code. Une page JSP traite des requêtes et génère des réponses, tout comme un servlet, mais sa logique est principalement guidée par la présentation. Une page JSP contient en majeure partie du langage HTML statique qui définit le format de présentation des données obtenues d'autres sources, comme les JavaBeans et les EJB. Un développeur de composant Web peut créer des bibliothèques de balises personnalisées pour étendre JSP et ajouter de nouvelles fonctions.

Pour plus d'informations sur JSP, reportez-vous à l'adresse http://java.sun.com/. Suivez les liens J2EE > Blueprints.

Pages HTML

Les pages HTML peuvent être utilisées pour prendre en charge les interfaces utilisateur. Elles peuvent être définies sous forme de pages Web statiques, ou générées par des servlets et des pages JSP. Conformément à la spécification J2EE, les clients Web J2EE doivent prendre en charge l'affichage des pages HTML.

JavaBeans

L'API JavaBeans définit une architecture pour la création de composants simples réutilisables. Ces composants peuvent être édités et assemblés à l'aide d'outils de génération d'applications. L'implémentation des JavaBeans s'effectue à l'aide d'un code Java classique, de sorte qu'elle reste lisible pour d'autres programmeurs susceptibles d'utiliser ces composants, ainsi que pour les outils.

La technologie JavaBeans est utilisée par les technologies J2EE, bien qu'elle n'en fasse pas partie. Les EJB peuvent par exemple utiliser les JavaBeans en tant qu'objets valeur. Pour en savoir plus sur les différences entre les JavaBeans et les Enterprise JavaBeans, reportez-vous à la section intitulée Comparaison entre les JavaBeans et les EJB.

Pour plus d'informations sur les JavaBeans, reportez-vous à Concept : JavaBeans.

Enterprise JavaBeans

La spécification Enterprise JavaBeans définit une architecture pour le développement et le déploiement des applications métier réparties transactionnelles et fondées sur des composants.

Les composants définis par la spécification EJB sont appelés Enterprise JavaBeans (EJB). Les EJB sont des composants Java côté serveur, dans lesquels vous implémentez les règles métier de votre application.

Ils sont déployés et exécutés dans un environnement appelé conteneur d'EJB (précédemment décrit sous le titre Conteneur d'EJB) qui fournit des services tels que la gestion des transactions, la connectivité à une base de données et la sécurité. En masquant de telles complexités, l'architecture des EJB permet aux développeurs de composants de se concentrer sur la logique métier.

Un Enterprise JavaBean (EJB) est une collaboration entre des interfaces Java, une classe d'implémentation d'EJB et un descripteur de déploiement XML. Les interfaces EJB et la classe d'implémentation doivent se conformer aux règles définies par la spécification EJB, telles que l'implémentation de certaines interfaces et la fourniture de certaines méthodes de rappel.

Les interfaces EJB comprennent des interfaces home qui fournissent des méthodes de recherche et de création d'instances EJB, et des interfaces de composant qui fournissent les méthodes métier pour une instance d'EJB particulière. Il peut s'agir d'interfaces distantes (qui peuvent être appelées dans le réseau) ou d'interfaces locales (l'appelant doit se situer dans le même processus, ou plus précisément, dans la même machine virtuelle Java). Ces interfaces sont implémentées par des classes de conteneur d'EJB, qui délèguent les méthodes à la classe d'implémentation d'EJB. Toutefois, et il s'agit d'une exception, une méthode de recherche d'EJB entity géré par conteneur sera traitée par la classe de conteneur.

Il existe trois types d'EJB : les beans session, les beans entity et les beans gérés par message.

Pour plus d'informations sur les EJB, reportez-vous à l'adresse http://java.sun.com/. Suivez les liens J2EE > Blueprints.

Beans session

Un composant bean session fournit des services qui implémentent la logique métier spécifique au client. Un seul client peut accéder à chaque instance de bean session par des interfaces home ou distantes. Les beans session peuvent sauvegarder des données dans une base de données, mais pour ce faire, ils font généralement appel aux beans entity qui représentent les objets métier. Les instances de beans session peuvent maintenir un état conversationnel transitoire.

Un bean session peut disposer d'une méthode getAllCustomers() qui renvoie un ensemble formé de toute la clientèle présente dans la base de données. Ce bean obtiendrait ces informations du bean entity Clientèle et livrerait les résultats au client.

Les beans session sans état peuvent être utilisés en tant que noeuds finaux de service Web, comme le définissent les spécifications JSR et EJB.

Remarque : l'utilisation d'un bean session sans état en tant que noeud final de service Web est une nouvelle fonctionnalité de J2EE 1.4 (JSR 109 et EJB 2.1) et n'est donc pas prise en charge par les versions antérieures.

Pour plus d'informations sur les beans session, reportez-vous à la spécification Enterprise JavaBeans Specification, Version 2.1, à l'adresse http://java.sun.com/. Suivez les liens Products & Technologies > J2EE > Enterprise JavaBeans.

Beans entity

Un composant bean entity fournit des services qui implémentent la logique spécifique à l'objet métier. Plusieurs clients peuvent accéder simultanément à une instance de bean entity par des interfaces locales ou distantes. Les beans entity sauvegardent les données de l'objet métier dans les bases de données, ce qui permet aux données stockées de résister aux pannes de conteneur ou de client.

Un bean entity pourrait représenter un client (clientèle), qui peut être stocké sous forme de ligne dans la table Clientèle d'une base de données relationnelle. Le développeur d'EJB choisit la méthode de persistance, en l'occurrence une base de données relationnelle.

Il existe deux types de persistance pour les beans entity : la persistance gérée par le bean (BMP) et la persistance gérée par conteneur (CMP). Les beans entity BMP doivent implémenter le code d'accès aux données, tandis que pour les beans entity CMP, cette capacité est implémentée par le conteneur. Les implémentations de conteneur CMP sont habituellement livrées pour la persistance sous forme de base de données relationnelle, bien qu'il soit possible d'utiliser d'autres types de persistance (base de données objet, fichiers, etc.).

Pour plus d'informations sur les beans entity, reportez-vous à la spécification Enterprise JavaBeans Specification, Version 2.1, à l'adresse http://java.sun.com/. Suivez les liens Products & Technologies > J2EE > Enterprise JavaBeans.

Beans gérés par message

Un composant bean géré par message fournit un service qui implémente la logique métier spécifique au traitement de message. Seul le conteneur peut appeler ce service ; le client ne peut pas le faire directement par des interfaces locales ou distantes. Lorsqu'un message arrive à une destination ou un noeud final auquel le bean a fourni un service, le conteneur appelle une instance de bean géré par message attribuée en tant que MessageListener à la destination. Les instances de beans gérés par message ne maintiennent pas d'état conversationnel, mais peuvent, par le biais des appels de méthode, maintenir des variables d'instance avec des références à des ressources (par exemple, une connexion à une base de données).

Remarque : les beans gérés par message ne sont pas pris en charge par les versions antérieures à EJB 2.0. La prise en charge des types de messagerie autres que JMS est une nouvelle fonctionnalité de la spécification EJB 2.1 ; elle est donc inexistante dans les versions antérieures.

Pour plus d'informations sur les beans gérés par message, reportez-vous à la spécification Enterprise JavaBeans Specification, Version 2.0, à l'adresse http://java.sun.com/. Suivez les liens Products & Technologies > J2EE > Enterprise JavaBeans.

Comparaison entre les JavaBeans et les EJB

Bien que leurs noms soient semblables, les EJB sont bien plus complexes que les JavaBeans ordinaires. Tous deux définissent des architectures pour des composants réutilisables, mais les EJB ajoutent la prise en charge nécessaire à la création de services répartis multi-utilisateurs. Les deux types de composants peuvent être assemblés à l'aide d'outils de génération d'applications, mais les EJB doivent être déployés dans un conteneur d'EJB pour être exécutés.

Services (API) pour les composants J2EE

Les conteneurs J2EE prennent en charge toutes les API J2SE standard, ainsi qu'un sous-groupe d'API J2EE selon le type de conteneur. Les composants d'un conteneur peuvent accéder à ce sous-groupe disponible. Le tableau suivant présente une brève description de chaque API et répertorie les conteneurs J2EE disponibles.

Nom
Description
Conteneurs J2EE
où les API sont disponibles

EJB 2.1

Cette spécification EJB définit un modèle de composant pour les EJB (des composants du niveau métier qui prennent automatiquement en charge des services tels que la communication distante, la gestion des transactions, la sécurité et la persistance).

Pour plus d'informations sur les EJB, reportez-vous à l'adresse http://java.sun.com/ et suivez les liens Products & Technologies > J2EE > Enterprise JavaBeans.

  • EJB
  • Client d'application*
  • Web*

* API client uniquement

JAAS

Java Authentication and Authorization Service (JAAS) fournit des services pour l'authentification et l'autorisation d'utilisateurs afin de vérifier qu'ils ont la permission d'effectuer une action.

Pour plus d'informations sur JAAS, reportez-vous à l'adresse http://java.sun.com/ et suivez les liens Products & Technologies > J2SE > Core Java > Java Authentication and Authorization Service (JAAS).

  • Client d'application
  • Web
  • EJB

JAF 1.0

JavaBeans Activation Framework (JAF) fournit des services qui permettent l'identification de données et l'instanciation d'un JavaBean en vue de manipuler ces données.

Pour plus d'informations sur JAF, reportez-vous à l'adresse http://java.sun.com/ et suivez les liens Products & Technologies > J2SE > Desktop Java > JavaBeans > JavaBeans Activation Framework.

  • Client d'application
  • Web
  • EJB

JAXP 1.2

Java API for XML Processing (JAXP) fournit une interface abstraite pour le traitement de documents XML qui peuvent être utilisés avec des interpréteurs et transformateurs compatibles qui font appel à DOM SAX ou XSLT.

Pour plus d'informations sur JAXP, reportez-vous au site http://java.sun.com/ et suivez les liens Products & Technologies > J2EE > Java API for XML Processing (JAXP).

  • Client d'application
  • Web
  • EJB

JAX-RPC 1.1

La spécification JAX-RPC définit des API client pour l'accès aux services Web, ainsi que des techniques d'implémentation des noeuds finaux de service Web.

Pour plus d'informations sur JAX-RPC, suivez ce lien : JAX-RPC

  • Client d'application
  • Web
  • EJB

Web Services for J2EE 1.1

La spécification Web Services for J2EE (JSR-109) définit les fonctions qu'un serveur d'applications J2EE
doit prendre en charge pour le déploiement de noeuds finaux de service Web .

Pour plus d'informations sur Web Services for J2EE, reportez-vous à l'adresse http://jcp.org/aboutJava/communityprocess/final/jsr109/index.html

  • Client d'application
  • Web
  • EJB

SAAJ 1.2

L'API SSAJ permet de manipuler des messages SOAP .

Pour plus d'informations sur SAAJ, reportez-vous au site http://java.sun.com/ et suivez les liens Products & Technologies > J2EE > SOAP with Attachments API for Java (SAAJ).

  • Client d'application
  • Web
  • EJB

JAXR 1.0

La spécification JAXR définit des API qui permettent l'accès client aux registres fondés sur le langage XML, tels que les registres WebXML et UDDI.

Pour plus d'informations sur JAXR, reportez-vous au site http://java.sun.com/ et suivez les liens Products & Technologies > J2EE > Java API for XML Registries (JAXR).

  • Client d'application
  • Web
  • EJB

JavaMail 1.3

L'API JavaMail fournit une infrastructure extensible pour la construction d'applications de messagerie électronique Java.

Pour plus d'informations sur JavaMail, reportez-vous à l'adresse http://java.sun.com/ et suivez les liens Products & Technologies > J2EE > JavaMail.

  • Client d'application
  • Web
  • EJB

JDBC 3.0

Java Database Connectivity (JDBC) est une API qui permet l'accès à des sources de données tabulaires telles que les bases de données SQL, les tableurs et les fichiers à plat.

Pour plus d'informations sur JDBC, reportez-vous à l'adresse http://java.sun.com/ et suivez les liens Products & Technologies > J2EE > JDBC.

  • Client d'application
  • Web
  • EJB

JMS 1.1

Java Message Service (JMS) fournit des services de messagerie asynchrone pour le transfert de données et la notification d'événements. Grâce au service JMS, il est possible d'utiliser des EJB gérés par message pour traiter de manière asynchrone les messages adressés aux sujets et files d'attente JMS.

Pour plus d'informations sur JMS, reportez-vous à l'adresse http://java.sun.com/ et suivez les liens Products & Technologies > J2EE > Java Message Service.

  • Client d'application
  • Web
  • EJB

JNDI

La spécification Java Naming and Directory Interface (JNDI) fournit des services de nommage et d'annuaire qui permettent d'enregistrer et de rechercher des composants et ressources répartis. Il suffit aux clients de connaître le nom JNDI enregistré du composant ou de la ressource, sans connaître leur emplacement réseau réel.

Exemple : les EJB sont enregistrés dans l'annuaire d'entreprise lors du déploiement, à l'aide de la zone ejb-name du descripteur de déploiement. Des clients J2EE recherchent un EJB à l'aide de la fonction de recherche de l'interface JNDI (tous les clients doivent connaître le nom d'enregistrement de cet EJB dans l'annuaire). La fonction de recherche JNDI renvoie une référence vers l'objet home de l'EJB.

Pour plus d'informations sur JNDI, reportez-vous à l'adresse http://java.sun.com/ et suivez les liens Products & Technologies > J2SE > Core Java > Java Naming and Directory Interface (JNDI).

  • Client d'application
  • Web
  • EJB

JTA 1.0

Java Transaction API (JTA) définit des interfaces pour la gestion des services de transaction répartis entre le gestionnaire de transactions, le gestionnaire de ressources, le serveur d'applications et l'application.

Pour plus d'informations sur JTA, reportez-vous à l'adresse http://java.sun.com/ et suivez les liens Products & Technologies > J2EE > Transactions.

  • Web
  • EJB

J2EE Connector 1.5

L'interface Service Provider Interface (SPI) de l'architecture J2EE Connector définit une norme pour la connexion des ressources EIS à un conteneur J2EE : un adaptateur de ressources spécifique à l'EIS (livré par le fournisseur d'EIS) étend le conteneur J2EE pour lui permettre d'offrir une prise en charge transactionnelle et sûre de cet EIS. Les composants du conteneur peuvent alors y accéder par le biais de l'interface SPI de l'architecture J2EE Connector.

Pour plus d'informations sur J2EE Connectors, reportez-vous à l'adresse http://java.sun.com/ et suivez les liens Products & Technologies > J2EE > J2EE Connector Architecture.

  • Web
  • EJB

JSP 2.0

La technologie JavaServer permet aux développeurs Web de créer et maintenir des pages Web dynamiques. Les pages JSP utilisent du texte et des balises semblables à XML pour réaliser la logique métier et générer un contenu personnalisé. La technologie JSP permet de déléguer la logique métier à d'autres composants, de manière à ce que seule la logique de présentation ait besoin d'être imbriquée dans la page JSP.

Pour plus d'informations sur JSP, reportez-vous à l'adresse http://java.sun.com/ et suivez les liens Products & Technologies > J2EE > JavaServer Pages.

Web

Servlet 2.4

Java Servlets étend les fonctions du serveur Web pour permettre la construction d'applications Web. Les servlets sont souvent utilisés dans des applications Web interactives, où le serveur Web répond à des requêtes utilisateur en renvoyant un contenu généré de manière dynamique et obtenu par des systèmes métier existants.

Pour plus d'informations sur Java Servlets, reportez-vous à l'adresse http://java.sun.com/ et suivez les liens Products & Technologies > J2EE > Java Servlet.

Web

RMI-IIOP

La technologie Remote Method Invocation fondée sur le protocole Internet Inter-Orb Protocol (RMI-IIOP) permet aux composants Java de communiquer avec les composants CORBA existants écrits dans d'autres langages que C++ ou Smalltalk.

Pour plus d'informations sur RMI-IIOP, reportez-vous à l'adresse http://java.sun.com/ et suivez les liens Products and APIs > RMI-IIOP.

  • Client d'application
  • Web
  • EJB

J2EE Management 1.0

L'API J2EE Management fournit des API qui permettent aux outils de gestion d'interroger un serveur d'applications J2EE
afin de connaître son statut en cours, les applications déployées, etc.

Pour plus d'informations sur J2EE Management, reportez-vous à l'adresse http://java.sun.com/ et suivez les liens Products & Technologies > J2EE > J2EE Management Specification.

  • Client d'application
  • Web
  • EJB

JMX 1.2

L'API JMX est utilisée par l'API J2EE Management pour offrir une partie de la prise en charge nécessaire à la gestion d'un produit J2EE.

Pour plus d'informations sur JMX, reportez-vous à l'adresse http://java.sun.com/ et suivez les liens Products & Technologies > J2SE > Core Java > Java Management Extensions (JMX).

  • Client d'application
  • Web
  • EJB

J2EE Deployment 1.1

L'API J2EE Deployment définit les interfaces entre l'environnement d'exécution d'un outil de déploiement et les composants de plug-in fournis par un serveur d'applications
J2EE.

Pour plus d'informations sur J2EE Deployment, reportez-vous à l'adresse http://java.sun.com/ et suivez les liens Products & Technologies > J2EE > J2EE Deployment Specification.

JACC 1.0

La spécification JACC définit un contrat entre un serveur d'applications J2EE et un
fournisseur de règles d'autorisation.

Pour plus d'informations sur JACC, reportez-vous à l'adresse http://java.sun.com/ et suivez les liens Products & Technologies > J2EE > Java Authorization Contract for Containers.

  • Client d'application
  • Web
  • EJB

Assemblage et déploiement

Les applications J2EE sont constituées du descripteur de déploiement de l'application (application.xml) et d'un ou de plusieurs modules J2EE qui forment l'application. Ces modules sont des composants réutilisables et portables. Les applications J2EE sont regroupées dans des archives .ear.

Descripteurs de déploiement

Les descripteurs de déploiement sont des fichiers XML utilisés dans les applications et modules J2EE. Ils fournissent des informations de configuration lues par le serveur J2EE lors du déploiement. Ces informations permettent au serveur de personnaliser l'application ou le module J2EE de manière déclarative sans modifier le code ou les classes source.

Il existe un type de descripteur de déploiement générique pour chaque application ou module J2EE. Les descripteurs de déploiement génériques, tels que le fichier ejb-jar.xml du module d'EJB, définissent les informations qui s'appliquent à l'EJB quel que soit le serveur sur lequel il est déployé. Les descripteurs de déploiement spécifiques au serveur définissent uniquement les informations pertinentes pour un serveur particulier. Le nom d'un descripteur de déploiement spécifique au serveur reflète le serveur auquel il s'applique.

Modules J2EE

Un module J2EE est constitué d'un descripteur de déploiement pour le module et d'un certain nombre d'éléments qui forment le module, y compris :

  • Des éléments non Java déployés sur un serveur Web (pages JSP, fichiers image, pages statiques HTML) ; en d'autres termes, des éléments de répertoire virtuel
  • Des éléments Java déployés sur un serveur Web (servlets, JavaBeans, classes Java)
  • Des éléments déployés sur un serveur d'EJB (EJB et classes Java de support)

Il existe trois types de modules J2EE :

Clients d'application J2EE

Les modules de clients d'application J2EE sont regroupés dans des archives .jar et contiennent :

  • le descripteur de déploiement application-client.xml
  • les fichiers .class d'implémentation du client d'application
Composants Web

Les modules de composants Web sont regroupés dans des archives .war et contiennent :

  • le descripteur de déploiement web.xml et les descripteurs de déploiement spécifiques au serveur
  • des pages JSP
  • des pages HTML
  • des images (par exemple, .gif et .jpg)
  • des fichiers Servlet Class

Si le module est un service Web, l'archive .war contient :

  • le descripteur de déploiement webservices.xml
  • des fichiers Servlet Class
  • des fichiers WSDL
Enterprise JavaBeans

Une seule archive JAR d'Enterprise JavaBeans peut contenir un certain nombre d'EJB, mais leurs informations de déploiement sont stockées dans un ensemble de descripteurs de déploiement (des fichiers ejb-jar.xml et tout descripteur de déploiement spécifique au serveur).

Un module d'Enterprise JavaBeans standard contient :

  • le fichier ejb-jar.xml et les descripteurs de déploiement spécifiques au serveur
  • des fichiers Class d'implémentation d'EJB

Un module d'Enterprise JavaBeans de services Web contient :

  • les descripteurs de déploiement webservices.xml
  • des fichiers Class d'implémentation d'EJB

Pour plus d'informations sur le regroupement et le déploiement de composants J2EE, reportez-vous à l'adresse http://java.sun.com/. Suivez les liens Docs & Training > J2EE Platform, Enterprise Edition > Java Blueprints Program.

Développement d'une application J2EE

Le processus de développement d'une application J2EE définit plusieurs rôles et étapes. Les sections suivantes définissent les rôles de développement livrés par la spécification J2EE et les étapes de développement auxquelles participent ces rôles.

Rôles de développement d'une application J2EE

Ce tableau récapitule les rôles de développement d'une application.

Nom du rôle Description

Fournisseur de produits J2EE

Un fournisseur de produits J2EE livre une implémentation de la plateforme J2EE, également appelée produit J2EE. BEA, IBM et Sun sont des fournisseurs de produits J2EE. Ces organisations utilisent généralement leurs atouts existants pour livrer une implémentation de la plateforme J2EE. Par exemple, l'implémentation BEA est construite autour de Tuxedo, son moniteur transactionnel à grand succès. Un fournisseur de produits J2EE livre également les outils nécessaires à la prise en charge du déploiement et de la gestion de l'application.

Fournisseur de composants d'application

Le fournisseur de composants d'application englobe un certain nombre de rôles, tels que les développeurs d'EJB et les concepteurs de documents HTML. Ces rôles sont chargés de produire les composants d'application J2EE à l'aide des outils fournis.

Assembleur d'application

L'assembleur d'application crée une application J2EE à partir de composants d'application J2EE à l'aide des outils fournis. Cette application est livrée sous forme de fichier Enterprise Archive (EAR). L'assembleur d'application décrit également toutes les dépendances externes que possède l'application. Le déployeur résout ces dépendances lorsqu'il déploie l'application J2EE.

Déployeur

Le déployeur est chargé de déployer une application J2EE, et les composants d'application qui la constituent, dans l'environnement d'exécution. La première étape consiste à installer les différents composants d'application dans les conteneurs J2EE pertinents. La deuxième étape consiste à configurer toutes les dépendances externes déclarées afin de les résoudre. Par exemple, les rôles de sécurité qui ont été définis sont mappés à des groupes et comptes d'utilisateurs dans l'environnement d'exploitation. Enfin, lors de la troisième étape, le déployeur doit exécuter la nouvelle application afin qu'elle soit prête à recevoir des demandes.

Administrateur système

L'administrateur système est responsable de l'infrastructure d'exécution, qui comprend toutes les applications J2EE déployées. Ce rôle utilise les outils appropriés livrés par le fournisseur de produits J2EE pour accomplir cette tâche.

Fournisseur d'outils

Ce rôle fournit des outils pour la prise en charge du développement et du regroupement des composants d'application. Ces outils, qui correspondent souvent aux différents types de composants d'application produits, contiennent des environnements de développement intégrés tels qu'IBM VisualAge for Java et Borland JBuilder.

Fournisseur de composants système

Ce rôle fournit différents composants de niveau système, tels que les adaptateurs de ressources ou le fournisseur de règles d'autorisation.


Ces rôles ne sont pas exclusifs ; une seule personne peut en remplir plus d'un, en particulier dans les petites équipes de développement ou lors d'un prototypage.

Etapes de développement d'une application J2EE

Cette section décrit les différentes étapes de développement d'une application J2EE, telles qu'elles sont décrites dans la spécification J2EE. Ces étapes sont les suivantes :

  • Développement de composants
  • Une application J2EE devant contenir au moins un module J2EE, au moins l'une des étapes de développement de composant est requise. Les deux dernières étapes sont toujours nécessaires, car toutes les applications J2EE doivent être assemblées et déployées.

    Le tableau suivant récapitule les étapes de développement d'applications J2EE.

    Etape de développement J2EE Tâches Réalisée par le rôle J2EE Produit (Livrable)

    Création de clients d'application J2EE

    • Ecriture du code du client et compilation des classes
    • Création du descripteur de déploiement application-client.xml
    • Création d'une archive de fichiers JAR contenant les fichiers Class et XML

    Fournisseur de composants d'application (développeur de logiciels)

    Un fichier JAR contenant le client d'application J2EE

    Création de composants Web

    • Ecriture du code des servlets et compilation des classes
    • Ecriture des pages JSP et HTML
    • Création du descripteur de déploiement web.xml
    • Création d'un fichier archive Web Application Archive (WAR) contenant les fichiers Class, .jsp, .html et XML

    Fournisseur de composants d'application (développeur de logiciels : servlets ; concepteur Web : pages JSP et HTML)

    Un fichier WAR contenant le composant Web

    Création d'Enterprise JavaBeans

    • Ecriture du code des EJB et compilation des classes
    • création du fichier ejb-jar.xml et des descripteurs de déploiement spécifiques au serveur
    • Création d'une archive de fichiers JAR contenant les fichiers Class et XML

    Fournisseur de composants d'application (développeur de logiciels)

    Un fichier JAR contenant l'Enterprise JavaBean

    Assemblage de l'application J2EE

    • Création du descripteur de déploiement application.xml
    • Création d'une archive de fichiers EAR contenant les EJB (JAR), les composants Web (WAR) et les fichiers XML

    Assembleur d'application

    Un fichier EAR contenant l'application J2EE

    Déploiement de l'application J2EE

    • Ajout de l'application J2EE (EAR) à l'environnement du serveur J2EE
    • Edition du descripteur de déploiement application.xml avec la configuration de l'environnement local
    • Déploiement de l'application J2EE sur le serveur J2EE

    Déployeur

    Une application J2EE installée et configurée


    Chaque étape du processus de développement produit un livrable qui est utilisé dans l'étape suivante. Les composants créés au cours des étapes du développement de composants sont utilisées lors de l'assemblage de l'application pour produire l'archive EAR de l'application J2EE. Au cours de l'étape de déploiement de l'application, cette archive est déployée sur le serveur J2EE.

    Les livrables de chaque étape sont portables et n'ont pas besoin d'être réalisés par les mêmes personnes, ni dans le même environnement, tant que celui-ci respecte les exigences de la plateforme J2EE.

    Pour plus d'informations sur le regroupement et le déploiement de composants J2EE, reportez-vous à l'adresse http://java.sun.com/. Suivez les liens J2EE > Blueprints.

    Plus d'informations

    Les Blueprints J2EE de Sun contiennent des informations supplémentaires. Vous pouvez les consulter à l'adresse http://java.sun.com/. Suivez les liens J2EE > Blueprints > Guidelines: Designing Enterprise Applications with the J2EE Platform, Second Edition.

    Une copie de ce document est également incluse dans Rational Unified Process.

    Le tableau suivant récapitule les chapitres des Blueprints J2EE de Sun contenant des informations sur des sujets spécifiques.

    Concept J2EE Chapitre des Blueprints J2EE

    Technologies de la plateforme J2EE

    Chapitre 2

    Enterprise JavaBeans

    Chapitre 5

    Transactions

    Chapitre 8

    Sécurité

    Chapitre 9

    Servlets

    Chapitre 4

    JavaServer Pages

    Chapitre 4

    Déploiement et regroupement

    Chapitre 7