Rubriques

IntroductionTo top of page

Dans le monde au rythme élevé des affaires électroniques d'application distribuées complexes d'aujourd'hui, il est essentiel que vos applications d'entreprise soient mises sur le marché rapidement. Votre équipe de projet ne peut donc pas se permettre de passer du temps à développer des services au niveau du système comme la connectivité distante, le nommage, la persistance, la sécurité ou la gestion de transaction. Votre équipe de projet a besoin de développer et d'utiliser des composants réutilisables et portables; vous ne voulez perdre aucun temps à réinventer une architecture éprouvée.

L'édition pour l'entreprise de la plate-forme Java 2 (J2EE) répond à ces besoins en procurant une "infrastructure" (bibliothèque de classes spécialisées) basé sur des standards et bien établi pour développer et exécuter des applications Java "multi-tiers" (à plusieurs niveaux), distribuées et à base de composants. Cette infrastructure gère la plus grande partie du niveau peu complexe de l'application comme la connectivité distante, le nommage, la persistance, la sécurité et la gestion de transaction, ce qui permet aux développeurs de se concentrer sur la logique d'entreprise de l'application.

La plate-forme J2EE se compose de :

  • Un ensemble de standards pour les composants de J2EE et la plate-forme sur laquelle ils sont exécutés.
  • Une méthodologie pour le développement d'applications qui décrit la plate-forme J2EE en détail, offrant une information de force industrielle sur la façon de développer les applications J2EE.
  • Une implémentation de référence de la plate-forme J2EE fournie par Sun Microsystems Inc. en tant que standard auquel les produits commerciaux J2EE peuvent être comparés. Cette implémentation de référence inclut des exemples d'applications complètement développés.
  • Une suite de tests de compatibilité pour tester et comparer aux standards les implémentations commerciales de J2EE.

La plate-forme J2EE est analogue aux services fournis par le système d'exploitation de votre ordinateur. En utilisant des outils de programmation, vous pouvez ajouter aux services standards qu'offre le système d'exploitation, des applications que vous pouvez développer et exécuter sans vous inquiéter de la gestion de problèmes de bas niveau comme l'accès au disque, la mémoire, la sortie vidéo, le réseau, etc. Vous ne vous souciez que des détails de votre application, pas des détails du système de base. La plate-forme J2EE procure un système d'exploitation sophistiqué pour les applications d'entreprise.

En utilisant la plate-forme J2EE, vous réduisez vos efforts de développement. Cela permet à votre équipe de projet de se concentrer sur la logique d'entreprise de l'application plutôt que de passer du temps, qui devrait être consacré au développement, à résoudre des problèmes au niveau du système. Une équipe de projet, qui peut se concentrer sur ce que l'application fait plutôt que sur la mise en place de tout ce dont l'application a besoin, est plus apte à fournir, en respectant les délais, un système sans erreur qui répond aux besoins de vos utilisateurs.

Pour plus d'informations, consultez la vue d'ensemble de la plate-forme J2EE sur le site http://java.sun.com/. Suivez les liens pour Products & APIs > Java 2 Platform, Enterprise Edition (J2EE) > Overview.

Le développement de la plate-forme J2EE, en bref To top of page

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

  • Vous achetez une plate-forme J2EE commerciale sous la forme d'un serveur compatible J2EE. Le comportement du serveur J2EE est spécifié par le standard J2EE.
  • Vous développez ou achetez dans le commerce des composants J2EE.
  • Vous déployez et exécutez vos composants J2EE sur votre serveur compatible J2EE, qui offre tous les services dont vos composants J2EE ont besoin.

Exemple To top of page

Un site de commerce sur Internet, sur lequel un client (utilisateur) se sert d'un navigateur Web pour accéder à distance à un serveur J2EE, est un exemple simple d'application J2EE. Le serveur J2EE propose des services des tiers Web (Web tier) et entreprise (business tier) et permet l'interaction avec le tiers système d'information de l'entreprise (EIS, back end tier) qui offre l'accès au RDBMS (système de gestion de bases de données relationnelles).

Pourquoi utiliser J2EE ?To top of page

Vous aurez envie d'utiliser la plate-forme J2EE pour développer votre commerce sur Internet Java ou votre application d'entreprise, si vous êtes dans l'un des cas suivants :

Chacun de ces points sera abordé en détails dans le reste de cette section.

Une infrastructure standardisée et testée au niveau industrielTo top of page

Les composants J2EE s'exécutent dans des conteneurs J2EE, proposés habituellement comme partie du serveur compatible J2EE. Ces conteneurs offrent un ensemble de services standards (Les "API" : Interfaces de programmation d'application ) qui sont utilisés par les composants J2EE. Ces API sont :

  • J2SE 1.4
    • JDBC
    • Java IDL
    • L'invocation de méthode distante RMI avec le protocole Internet Inter-ORB de CORBA (RMI-IIOP)
    • L'interface de nommage et d'annuaire Java (JNDI)
    • Le service d'authentification et d'autorisation de JAVA (JAAS)
  • L'API de transaction Java (JTA)
  • JavaMail
  • Le service de messagerie Java (JMS).
    Pour plus d'informations sur JMS, voir la rubrique Concepts : Service de messagerie Java.
  • JavaBeans Activation Framework (JAF)
  • Enterprise JavaBeans (EJB)
  • Le servlet Java
  • Les API Java pour le traitement XML (JAXP)
  • Le connecteur Java (Note : n'est pas supporté par les versions antérieures à J2EE 1.3)
  • Les pages JavaServer (JSP)
  • Les services Web pour J2EE (Note : ne sont pas supportés par les versions antérieures à J2EE 1.4)
  • L'API Java pour le RPC basé sur le XML (JAX-RPC) (Note : n'est pas supportée par les versions antérieures à J2EE 1.4)
  • Le SOAP (simple object acces protocol) avec accessoires API pour Java (SAAJ) (Note : n'est pas supporté par les versions antérieures à J2EE 1.4)
  • API Java pour registres XML (JAXR) (Note : n'est pas supportée par les versions antérieures à J2EE 1.4)
  • J2EE Management (Note : n'est pas supportée par les versions antérieures à J2EE 1.4)
  • L'extension de gestion pour Java (JMX) (Note : n'est pas supportée par les versions antérieures à J2EE 1.4)
  • Le déploiement J2EE (Note : n'est pas supporté par les versions antérieures à J2EE 1.4)
  • Le contrat pour les conteneurs du fournisseur de service d'autorisation pour Java (JACC) (Note : n'est pas supporté par les versions antérieures à J2EE 1.4)

La portabilité To top of page

Les composants et applications J2EE sont portables sur les différents serveurs compatibles J2EE sans qu'aucune modification de code ne soit nécessaire, vous pouvez donc déployer votre application sur le serveur compatible de votre choix, en mettant simplement à jour des informations de déploiement spécifiques au serveur, contenues dans les fichiers descripteurs de déploiement XML.

La standardisation de la spécification J2EE ayant encouragé la concurrence des secteurs, vous pouvez choisir entre différents serveurs compatibles J2EE selon vos besoins et votre budget.

Les composants réutilisablesTo top of page

Etant conformes au standard de J2EE, les composants peuvent être achetés dans le commerce et branchés sur votre application J2EE, selon vos besoins, en diminuant l'effort de développement, spécialement au niveau de la phase de débuggage (chercher et corriger les erreurs d'un programme) et de tests.

Si vous développez un composant, vous pouvez le réutiliser dans une autre application ou le déployer sur d'autres serveurs compatibles J2EE selon vos besoins.

Une architecture et des modèles de conception éprouvésTo top of page

La plate-forme J2EE définit une architecture d'application multi-tiers bien structurée. En s'appuyant sur l'architecture de J2EE, vos développeurs peuvent rapidement commencer à développer la logique d'entreprise de l'application elle-même.

La documentation de J2EE inclut :

  • Une méthodologie pour le développement d'application qui décrit la plate-forme J2EE en détails et fournit l'information la plus testée pour développer les applications de J2EE.
  • Des modèles bien établis, les plus testés de l'industrie, qui décrivent les solutions aux problèmes courants d'architecture et de conception pour J2EE.

Pour plus d'informations sur la plate-forme J2EE, visitez le site http://java.sun.com/. Suivez les liens pour J2EE > Blueprints.

ExtensibilitéTo top of page

J2EE supporte l'extensibilité pour augmenter la performance ou pour répondre à des flux de données croissants de différentes manières :

  • Fonctionnalités d'amélioration de la performance dans le conteneur J2EE - Ces fonctionnalités comprennent le regroupement des ressources (regroupement des connexions aux bases de données, regroupement d'instances de bean de session et regroupement de threads), le passage de messages asynchrones, et une gestion efficace du cycle de vie des composants. Par exemple, ouvrir une connexion aux bases de données est un processus lent, de plus, les connexions aux bases de données peuvent apporter des ressources peu abondantes dues aux restrictions de licences. La plate-forme J2EE gère cela en utilisant le regroupement des connexions aux bases de données. Le conteneur J2EE garde une réserve de connexions ouvertes qui peuvent être attribuées à un composant selon les besoins ce qui permet des connexions rapides et efficaces.
  • La répartition des charges peut être obtenue par le "clustering" (regroupement d'éléments similaires) - Déployer les mêmes composants sur de multiples serveurs et sur différentes machines. Le flux de données pour chacun des serveurs peut alors être équilibré selon les besoins, que ce soit selon un algorithme "Round Robin"ou selon la charge du serveur. La spécification de la plate-forme J2EE ne nécessite pas une fonctionnalité de répartition de charges dans un serveur J2EE mais suggère qu'un serveur de grande capacité la possède. Les vendeurs de J2EE offrent des solutions variées de répartition des charges.
  • Le partitionnement d'application - Les parties logiquement différentes d'une application peuvent être déployées sur des serveurs différents. Il est possible, par exemple, de déployer les sous-systèmes de comptabilité et d'inventaire de l'application d'un service de vente par correspondance en ligne, sur des serveurs séparés.

Outils de développement et de déploiementTo top of page

Les vendeurs ont répondu au besoin d'outils J2EE en offrant un excellent support pour le développement de J2EE dans leurs environnements de développement intégrés Java (IDE) incluant :

  • Des assistants de création de servlets
  • Des assistants et des dialogues pour la création et la maintenance d'EJB
  • La génération et la maintenance du descripteur de déploiement
  • Le mapping EJB objet vers base de données (incluant la génération de l'information du descripteur de déploiement pour les relations gérées par les conteneurs)
  • L'intégration à un conteneur Web pour tester les services Web
  • Le déploiement en continu en IDE, le débuggage, et le test d'EJB par l'intégration à un conteneur EJB J2EE et à ses outils de déploiement
  • La génération automatique de clients tests J2EE
  • L'intégration aux outils de modélisation du langage ULM

Intégration au système d'arrière-planTo top of page

L'arrière plan fait référence au tiers système d'information de l'entreprise de l'application (EIS). Le système d'arrière plan peut-être, par exemple, le RDBMS, des systèmes existants ou des systèmes de planification de revenus d'entreprise (ERP).

J2EE supporte un accès transactionnel aux EIS de RDBMS en utilisant les API JDBC et JTA. De plus, les conteneurs EJB supportent la persistance gérée par le conteneur, dans laquelle la connexion et l'accès transactionnel RDBMS sont automatiquement pris en charge par le conteneur.

L'interface du fournisseur de service de l'architecture du connecteur J2EE définit un standard pour connecter les ressources non-RDBMS à un conteneur J2EE. Un adaptateur de ressources spécifique pour EIS (fourni par le vendeur de l'EIS) est branché au conteneur, étendant le conteneur pour qu'il procure un support transactionnel et sécurisé pour cet EIS. Les composants dans le conteneur peuvent alors accéder à l'EIS à travers la SPI de l'architecture du connecteur J2EE.

Note : La SPI de l'architecture du connecteur J2EE n'est pas supportée par les versions antérieures à J2EE 1.3.

La sécuritéTo top of page

La plate-forme J2EE propose des fonctionnalités de sécurité simples et puissantes. Les informations concernant la sécurité pour les composants de J2EE sont définies dans leur descripteur de déploiement. Ces informations définissent quels rôles de sécurité sont autorisés à accéder à une URL particulière et /ou aux méthodes d'un composant. Un rôle de sécurité est simplement un nom logique pour un groupe d'utilisateurs; par exemple, on peut attribuer le nom de rôle "directeurs" à tous les membres de l'équipe de direction d'une organisation.

Etant donné que les informations de la sécurité sont déclarées dans le descripteur de déploiement, les comportements de la sécurité peuvent être modifiés sans avoir recours à un coûteux cycle de tests, de mise à jour et de débuggage du code.

Architecture "multi-tiers"To top of page

J2EE est une architecture d'application multi-tiers se composant d'un tiers client, d'un tiers intermédiaire et d'un tiers EIS ou tiers de système d'arrière plan.

Le pattern 1 montre l'architecture multi-tiers de la plate-forme J2EE ainsi que les divers conteneurs J2EE qui supportent les composants J2EE.

Diagramme décrit dans le texte d'accompagnement.

Figure 1: L'architecture "multi-tiers" de J2EE

Le tiers «client»To top of page

Les composants du tiers client s'exécutent dans les conteneurs clients. Le tiers client peut être implémenté avec :

  • Les applications autonomes Java, habituellement une IUG (interface utilisateur graphique, également appelée un "thick client"). Une application Java comme celle-ci doit être installée sur chacune des machines du client. Une application Java peut accéder au tiers client ou au tiers intermédiaire à travers l'utilisation d'API comme JDBC.
  • Une page HTML statique procure une IUG limitée pour une application.
  • Le HTML dynamique généré par les pages JSP ou les servlets.
  • Les applets s'exécutent dans un navigateur Web. Les applets sont intégrés à des pages HTML et sont habituellement utilisés pour fournir une IUG.

Le tiers "intermédiaire"To top of page

Le tiers intermédiaire se compose du tiers Web et du tiers entreprise. Les composants du tiers Web s'exécutent dans un serveur Web qui fournit un conteneur Web. Les composants du tiers entreprise s'exécutent dans un serveur d'application J2EE qui fournit un conteneur EJB.

Les tiers "Web"To top of page

Les composants du tiers Web comprennent les servlets et les pages JSP, qui gèrent l'interaction avec le tiers client, isolant les clients du tiers entreprise et du tiers EIS. Les clients font des demandes au niveau du tiers Web, celui-ci exécute la demande et renvoie les résultats aux clients. Les demandes des clients aux composants du tiers Web résultent généralement en des demandes du tiers Web aux composants du tiers entreprise, qui, à leur tour, résultent en demandes au tiers EIS.

Le tiers entreprise To top of page

Les composants du tiers entreprise sont les EJBs.

  • Ils comprennent la logique d'entreprise de l'application.
  • Ils font des demandes au tiers EIS selon la logique de l'entreprise, habituellement en réponse à une demande du tiers Web.

Le tiers EISTo top of page

Le tiers EIS représente les données stockées de l'application, souvent sous la forme d'un RDBMS. Le tiers EIS peut aussi se composer de systèmes existants ou ERP, accédé à travers les API de l'architecture du connecteur de J2EE.

Pour plus d'information sur les API de l'architecture du connecteur visitez le site http://java.sun.com/. Suivez les liens Products & Technologies > J2EE > J2EE Connector Architecture.

Pour plus d'informations sur les configurations de déploiement standards de J2EE, visitez Concepts: J2EE Deployment Configurations.

Les serveurs J2EE To top of page

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

L'utilisation de la terminologie "serveur J2EE" est un peu vague. Ce que l'on veut généralement dire c'est "un serveur J2EE qui supporte aussi bien un conteneur Web qu'un conteneur EJB". En utilisant une terminologie plus pointilleuse on pourrait dire qu'un serveur Web J2EE (comme l'installation de serveur Web J2EE de référence Tomcat)supporte un conteneur Web et qu'un serveur d'application J2EE (ou EJB) supporte un conteneur EJB.

Les conteneurs J2EE To top of page

Les composants J2EE s'exécutent dans ou sont accueillis par des conteneurs J2EE généralement fournis comme partie d'un serveur J2EE commercial. Les conteneurs fournissent aux composants J2EE exécutés dans le conteneur un environnement d'exécution et un ensemble de services standards (API)), en plus de supporter les API standards J2SE.

J2EE définit les types de conteneurs suivants :

Le conteneur d'application clienteTo top of page

Une application cliente J2EE s'exécute dans un conteneur d'application cliente qui supporte les API J2EE suivantes : JDBC, JMS, JAXP, JAAS, JavaMail, JAF, JSR, JAX-RPC, SAAJ, J2EE Management et JMX.

En pratique, un conteneur d'application cliente se compose de l'installation standard de J2SE. Le conteneur d'application cliente doit supporter l'interface de gestion du rappel automatique JAAS pour répondre aux contraintes de sécurité du reste de l'application entreprise dans les conteneurs Web et EJB.

Le conteneur d'applet To top of page

Un applet s'exécute dans un conteneur d'applet qui supporte le modèle de programmation d'applet et supporte les API standards J2SE. En pratique, les conteneurs d'applets sont fournis comme les modules externes Java pour un navigateur Web.

Le conteneur WebTo top of page

Les composants Web (pages JSP et servlets) s'exécutent dans un conteneur Web et sont fournis comme une partie d'un serveur J2EE ou fournis en tant que serveur Web J2EE autonome. Un conteneur Web supporte les API et packages suivants: JDBC, JMS, JAXP, JAX-RPC, JAXR, JAAS, Java Mail, JAF, l'architecture du connecteur J2EE, JTA, JSR, SAAJ, la Gestion J2EE, Java Servlet, et JSP.

Le conteneur EJBTo top of page

Les composants EJB sont exécutés dans un conteneur EJB qui est fourni comme une partie d'un serveur J2EE.

Un conteneur EJB supporte les API et technologies J2EE suivantes : EJB, JDBC, JMS, JAXP, JAX-RPC, JAXR, JAAS, Java Mail, JAF, JTA, JSR, SAAJ, la Gestion J2EE, et l'architecture du connecteur J2EE.

Les sous-sections suivantes résument les fonctionnalités clés supportées par les conteneurs EJB :

Les communications distantes To top of page

Les conteneurs EJB masquent la complexité des communications à distance aux développeurs en utilisant des classes fournies avec les conteneurs (générées par les outils des conteneurs quand le EJB est compilé, avec des classes souches RMI pour l'utilisation par les clients) qui implémentent les interfaces EJB. Ces classes d'amélioration sont des objets Java distants auxquels les clients peuvent accéder en utilisant la méthode RMI Java. Du point de vue du client, le client appelle simplement des méthodes sur l'interface EJB, sans tenir compte des communications distantes.

La concurrence To top of page

Les conteneurs EJB gèrent de façon transparente les demandes de plusieurs clients. Les clients peuvent agir comme s'ils avaient un accès exclusif à l'EJB. Par exemple, si deux clients formulent la même demande d'EJB entité, le conteneur leur fournit à chacun leur propre instance et gère la synchronisation de manière interne sans que les clients en aient connaissance.

Le nommage To top of page

Le conteneur EJB fournit un espace de noms JNDI pour localiser les EJB déployés dans le conteneur. Les clients EJB peuvent chercher dans les EJB pour obtenir une interface d'accueil. L'interface d'accueil pour un EJB fournit des méthodes pour trouver et créer des instances EJB. Tant que le contexte de nommage JNDI est accessible depuis leur emplacement, les clients peuvent accéder à l'EJB.

La persistance To top of page

Les développeurs d'EJB ont le choix entre deux possibilités de stockage pour les données persistantes d'EJB entités : La persistance gérée par le conteneur (CMP), et la persistance gérée par le bean (BMP). La méthode CMP laisse la responsabilité d'améliorer le code des données au conteneur alors que la méthode CMP laisse cette responsabilité au développeur d'EJB. La méthode CMP permet au développeur d'EJB d'utiliser une implémentation standard pour l'accès au stockage persistant, en déclarant simplement des champs gérés par le conteneur dans le descripteur de déploiement.

La gestion de transaction To top of page

Une transaction est une séquence d'opérations qui réussit ou échoue automatiquement afin qu'aucun changement ne soit infligé à l'état du système, au cas ou l'une des opérations de la séquence échoue. Par exemple, disons que vous voulez produire des billets d'avion, vous validez la carte de crédit d'un client, vous débitez le compte correspondant à la carte et émettez les billets. Cette séquence d'opérations doit se produire en une transaction unique, afin qu'aucun changement ne soit fait sur le compte de la carte de crédit du client et qu'aucun billet ne soit émis en cas d'échec de l'une des opérations.

L'EJB peut utiliser indifféremment l'une ou l'autre des démarcations suivantes : la démarcation de transaction gérée par le bean ou la démarcation de transaction gérée par le conteneur, lesquelles sont décrites dans les deux prochains paragraphes.

Les démarcations de transactions gérées par le beanTo top of page

Dans la démarcation gérée par le bean vous utilisez une simple API pour démarquer les frontières de la transaction. C'est l'API de transaction Java(JTA), que vous utilisez pour contrôler, à travers un programme, la démarcation de transaction ; par exemple, en appelant les méthodes begin(), commit() et rollback(), méthodes de l'interface de transaction utilisateur JTA. Le développeur est responsable du codage de la logique du rollback (retour en arrière) pour les conditions exceptionnelles de transaction, le conteneur ne les prenant pas en charge automatiquement.

Note : Les EJB entités ne peuvent pas utiliser la démarcation de transaction gérée par le bean, ils ne peuvent utiliser que les démarcations de transactions gérées par le conteneur.

Les démarcations de transactions gérées par le conteneurTo top of page

Dans les démarcations de transactions gérées par le conteneur vous ne fournissez pas un code pour commencer ou terminer les transactions. Vous fournissez à la place une information d'attribut de transaction dans le descripteur de déploiement pour chaque méthode de votre EJB. L'attribut de transaction (un de ceux-ci: "Required, RequiresNews, NotSupported, Supports, Mandatory, Never") dit au conteneur quelle portée de transaction utiliser pour la méthode. Par exemple, si un client est exécuté à l'intérieur d'une transaction et qu'il appelle une méthode de votre EJB pour laquelle l'attribut de transaction est programmé "required", la méthode sera alors appelée au sein de la portée de la transaction en cours.

Le fait d'utiliser la démarcation de transaction gérée par le conteneur plutôt que la démarcation de transaction gérée par le bean aussi souvent que possible vous évitera le test, le débuggage et l'ajout de code de démarcation de transaction dans votre composant. Au lieu de cela, les comportements de transaction de chacune des méthodes de vos EJB sont spécifiés au moment du développement dans le descripteur de déploiement. Cela veut dire que les comportements de transaction peuvent être modifiés sans avoir recours à un coûteux cycle de test, de débuggage et de mise à jour.

Les transactions distribuéesTo top of page

Une transaction distribuée est une transaction qui doit être coordonnée avec de multiples bases de données et/ou de multiples applications. C'est le contraire d'une transaction centralisée : un serveur d'application J2EE unique qui engage des transactions vers une base de données unique.

Un protocole à deux phases (two-phase commit) est nécessaire lors de transactions distribuées lorsque par exemple, plusieurs bases de données sont mises à jours en même temps. Certains conteneurs EJB (comme BEA WebLogic Server 6.0) fournissent un support pour le protocole à deux phases, en utilisant le protocole XA d'Open Group. Le programmeur n'a pas besoin d'écrire de code pour gérer le protocole à deux phases, c'est le conteneur EJB qui s'en charge.

La gestion de la sécurité To top of page

La sécurité EJB est gérée par le conteneur EJB en utilisant l'information de sécurité du descripteur de déploiement. Dans le descripteur de déploiement, vous déclarez un ensemble de rôles et pour chaque méthode EJB vous déclarez les rôles qui ont l'autorisation d'appeler la méthode.

En phase d'exécution, chaque client EJB est attribué à un rôle et le conteneur gère l'accès aux méthodes en vérifiant que le rôle du client est autorisé à appeler la méthode.

Etant donné que l'information de sécurité est déclarée dans le descripteur de déploiement, le comportement de la sécurité peut être modifié sans avoir recours à un coûteux cycle de tests, de débuggage et de mise à jour de code.

La gestion du cycle de vieTo top of page

En répondant aux demandes des clients, les EJB passent par une série d'états différents au cours de leur cycle de vie. Le conteneur EJB est responsable de la gestion de ce cycle de vie.

A son démarrage, le conteneur crée une réserve d'instances EJB dans une réserve de ressources (pour éviter le temps du démarrage quand on a besoin de la ressource EJB). Quand un client fait une demande de création d'un EJB, une instance est attribuée par la réserve. Le client peut alors faire des demandes à l'EJB. Quand un client EJB fait la demande du retrait d'un EJB, l'instance est remise dans la réserve.

Le conteneur notifie des instances EJB de différents évènements au cours du cycle de vie d'un EJB, en utilisant un ensemble de méthodes callback standards comme :

  • ejbCreate() - appelée par le conteneur quand l'instance EJB est créée
  • ejbRemove() - appelée par le conteneur quand l'instance EJB est sur le point d'être effacée
  • ejbActivate() - appelée par le conteneur quand l'instance EJB a été restaurée d'un état passif
  • ejbPassivate() - appelée par le conteneur quand l'instance EJB est sur le point d'être mise en état passif
  • ejbStore() - appelée par le conteneur quand l'instance EJB est sur le point d'être écrite sur une base de données
  • ejbLoad() - appelée par le conteneur quand les champs d'instances EJB ont été chargés depuis la base de données

Chaque EJB est nécessaire pour implémenter ces callbacks même si l'implémentation de la méthode du callback est souvent vide. Par exemple, le conteneur appelle la méthode EJB ejbRemove(), méthode qui notifie à l'EJB que l'EJB est sur le point d'être enlevé (il y a eu une demande de client pour enlever l'EJB). Dans la méthode EJB ejbRemove(), vous coderiez chaque opération nécessaire avant que l'EJB puisse être enlevé, en libérant par exemple toutes les ressources contenues dans l'EJB.

L'information mise à l'état passif, pouvant devenir EJB, est sauvegardée et l'instance EJB est libérée pour être utilisée par la réserve de ressources comme demandé par le conteneur. Un EJB rendu passif sera une information rendue active et restaurée par le conteneur si un client fait la demande de cet objet en particulier.

Le regroupement des connexions aux bases de données To top of page

Ouvrir une connexion à une base de données est un processus lent, d'autre part, les connexions aux bases de données pourraient être des ressources peu abondantes dues aux restrictions de licences. Le conteneur EJB gère cette dépense par le biais du regroupement des connexions aux bases de données, le conteneur garde une réserve de connexions ouvertes qui peuvent être attribuées ou enlevées à un EJB, selon les besoins, résultant en des connexions rapides et efficaces.

Pour les EJB entités qui utilisent la méthode CMP, les connexions aux bases de données sont gérées automatiquement. Vous n'avez pas de code SQL ou de connexion à écrire, vous spécifiez simplement le nom JNDI de la source de donnée JDBC dans le descripteur de déploiement et vous utilisez des outils de déploiement spécifiques au conteneur pour générer vos routines de connexion. Le conteneur gère la réserve de connexions aux bases de données.

Pour les EJB entités qui utilisent la méthode BMP ou pour les EJB de session, vous devez écrire un code de connexion pour vous connecter à une source de données JDBC et vous devez écrire un code SQL pour accéder à la base de données. La source de donnée JDBC est toujours gérée par le conteneur, la source de données JDBC utilise en fait une réserve de connexions aux bases de données maintenue par le conteneur.

La messagerie To top of page

Les conteneurs EJB sont nécessaires pour fournir un support de messagerie pour l'échange de messages asynchrones, JMS, comme d'autres types de messagerie, peut être utilisé par le processus des EJB activés par message des messages livrés. Etant donné l'engagement de JMS aux EJB, ils doivent supporter un accès transactionnel des composants de conteneur Web et EJB comme les servlets, les pages JSP et les EJB.

Les composants J2EE To top of page

La section suivante donne une brève description de tous les types de composants J2EE. Les composants comprennent les applets, les applications clientes, les composants Web et les composants réutilisables JavaBeans d'entreprise. Les composants J2EE s'exécutent dans des conteneurs J2EE.

Les applets To top of page

Les applets sont de petits programmes qui peuvent être ajoutés à une page Web et qui s'exécutent dans un navigateur Web. Ils pourraient aussi s'exécuter dans d'autres environnements qui supportent le modèle de programmation d'applets.

Les applets sont utilisées de façon primaire pour implémenter les interfaces et étendre de manière conséquente les possibilités des pages HTML.

Les applications clientes To top of page

Les applications clientes sont des applications Java. Elles ont accès aux fonctionnalités des tiers intermédiaires et EIS. Elles sont, en général, des applications de bureau qui fournissent une interface utilisateur. Elles peuvent être utilisées pour implémenter un client "thick client", comme décrit Concepts : Modèles de répartition.

Les composants WebTo top of page

Les Servlets Java To top of page

La technologie des servlets Java permet à un serveur Web de gérer des demandes venant d'un client Web et fournit des réponses au contenu dynamique. Un servlet Java peut communiquer avec d'autres composants Web ou EJB pour produire ce contenu dynamique. Le contenu ainsi généré peut prendre la forme de n'importe quel document basé sur le texte incluant HTML et XML. Le servlet Java peut également être utilisé comme un services Web d'extrémité en collaboration avec l'API JAX-RPC.

Note : L'usage de servlets comme service Web d'extrémité est une nouvelle fonctionnalité de J2EE 1.4 (JAX-RPC 1.1) et n'est de ce fait pas supporté par les versions antérieures.

Pour plus d'information sur les servlets J2EE, visitez le site http://java.sun.com/. Suivez les liens pour J2EE > Blueprints.

Les pages JavaServer To top of page

La technologie des pages JavaServer (JSP) est basée sur les servlets Java, mais elle est basée sur le texte plutôt que sur un code. Une page JSP traite des demandes et génère des réponses comme un servlet mais sa logique est principalement basée sur la présentation. Une page JSP se compose en grande partie de HTML statique qui définit le format pour la présentation des données obtenues par d'autres sources comme les Javabeans et les EJB. Un développeur de composants Web peut créer des librairies de balises personnalisées pour étendre JSP et ajouter d'autres possibilités.

Pour plus d'informations sur JSP, visitez http://java.sun.com/. Suivez les liens pour J2EE > Blueprints.

Les pages HTML To top of page

Les pages HTML peuvent être utilisées pour supporter les interfaces utilisateurs. Elles peuvent être définies comme des pages Web statiques ou elles peuvent être générées par des servlets et des pages JSP. La spécification de J2EE nécessite que les clients Web permettent l'affichage de pages HTML.

Les JavaBeans To top of page

L'API JavaBeans définit une architecture pour créer des composants simples et réutilisables. Ces composants peuvent être édités et assemblés en utilisant les outils de construction de l'application. Le code habituel Java est utilisé pour implémenter les Javabeans, pour que l'implémentation reste lisible pour d'autres programmeurs qui peuvent utiliser ces composants aussi bien que pour les outils.

Le JavaBean n'est pas une technologie J2EE mais il est utilisé par les technologies de J2EE. Par exemple, l'EJB peut utiliser les JavaBeans comme des objets valeur. Pour les différences entre les JavaBeans et les JavaBeans d'entreprise, veuillez vous référer à la section Comparer les JavaBeans et les EJB.

Pour plus d'informations sur les JavaBeans, veuillez vous référer à la section Concepts : JavaBeans.

Les JavaBeans d'entreprise To top of page

La spécification des JavaBeans d'entreprise stipule une architecture pour le développement et le déploiement d'applications métier distribuées transactionnelles basées sur les composants.

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

Les EJB sont déployés dans un environnement et y sont exécutés. Cet environnement s'appelle un conteneur EJB, décrit précédemment sous le titre Conteneur EJB, qui fournit des services comme la gestion de transaction, la connectivité aux bases de données et la sécurité. En dissimulant ce genre de complexités aux développeurs de composants, l'architecture EJB leur permet de se concentrer sur la logique de l'entreprise.

Un JavaBean d'entreprise est une collaboration entre des interfaces Java, une classe d'implémentation EJB, et un descripteur de déploiement XML. Les interfaces EJB et la classe d'implémentation doivent se conformer à des règles définies par la spécification de l'EJB comme l'implémentation de certaines interfaces et la fourniture de certaines méthodes de callback.

Les interfaces EJB incluent les interfaces d'accueil, qui fournissent des méthodes pour trouver et créer des instances EJB, et les interfaces de composants qui fournissent les méthodes métier pour une instance EJB spécifique. Celles-ci peuvent être des interfaces distantes, ce qui veut dire qu'elles peuvent être invoquées à travers le réseau ou des interfaces locales, ce qui implique que l'appelant soit dans le même processus (ou plus précisément dans la même machine virtuelle Java). Les interfaces EJB sont implémentées par des classes de conteneur EJB qui délèguent des méthodes à la classe d'implémentation EJB. La méthode "localisateur" d'un EJB entité géré par le conteneur, qui est gérée par la classe du conteneur est une exception.

Il y a trois types d'EJB : les beans de sessions, les beans entité et les beans activés par messages.

Pour plus d'information sur les EJB, visitez le site http://java.sun.com/. Suivez les liens pour J2EE > Blueprints.

Les beans de session To top of page

Un composant bean de session fournit des services qui implémentent la logique d'entreprise spécifique au client. Un seul client peut accéder chaque instance de bean de session à travers des interfaces locales ou à distance. Les beans de session peuvent sauvegarder des données dans une base de données mais habituellement, font appel à un bean entité qui représente les objets métiers pour sauvegarder les données. Les instances de beans de session peuvent maintenir un état conversationnel transitant.

Un bean de session peut avoir une méthode getAllCustomers() qui renvoie un ensemble de tous les clients dans la base de données. Ce bean peut obtenir ses informations par le bean entité client et livrer le résultat au client.

Les beans de sessions sans état peuvent être utilisés comme service Web d'extrémité, comme défini dans les spécifications de EJB et JSR.

Note : L'utilisation de beans de session sans état comme service Web est une nouvelle fonctionnalité de J2EE 1.4 (JSR 109 and EJB 2.1) qui ne sera donc pas supportée par les versions antérieures.

Pour plus d'informations sur les beans de session, voyez les spécifications des JavaBeans d'entreprise, Version 2.1 sur le site http://java.sun.com/. Suivez les liens pour Products & Technologies > J2EE > Enterprise JavaBeans.

Les beans entités To top of page

Un composant bean entité fournit un service qui implémente la logique spécifique à l'objet métier. Plusieurs clients peuvent accéder à une instance de bean entité de manière concurrente à travers des interfaces distantes ou locales. Les beans entités sauvegardent les données objet métier dans les bases de données, et les données persistantes peuvent survivre aux crashs de conteneur ou de client.

Un bean entité peut représenter un client, qui peut être stocké comme une ligne dans la table du client d'une base de données relationnelle. Le développeur d'EJB choisit la méthode de persistance, dans ce cas, une base de données relationnelle.

Il y a deux types de persistances de bean entité : La persistance gérée par le bean (BMP), et la persistance gérée par le conteneur (CMP). Le bean entité BMP doit implémenter le code d'accès aux données alors que pour le bean entité CMP, le code a été implémenté par le conteneur. Les implémentations d'un conteneur CMP sont, en général, fournies pour une persistance de base de données relationnelle, cependant, d'autres types de persistance sont possibles (base de données objet, persistance basée sur les fichiers, etc.)

Pour plus d'informations sur le bean entité, veuillez consulter : "La spécification des JavaBeans d'entreprise", Version 2.1 sur le site http://java.sun.com/. Suivez les liens pour Products & Technologies > J2EE > Enterprise JavaBeans.

Les beans activés par messages To top of page

Un composant bean activé par message fournit un service qui implémente la logique de l'entreprise spécifique au traitement des messages. Seul le conteneur peut appeler ce service ; le client ne peut pas appeler directement ce service depuis une interface locale ou distante. A la place, quand un message arrive à destination ou à une extrémité servie par le bean, le conteneur appelle une instance du bean activé par message et l'assigne comme "récepteur de message" à la destination. Les instances de beans activés par messages ne maintiennent pas un état conversationnel mais peuvent maintenir les variables instances avec les références ressources (par exemple, connexion aux bases de données) à travers les appels de méthodes.

Note : Les beans activés par messages ne sont pas supportés antérieurement à EJB 2.0. Le support de types de messagerie autres que JMS est une nouvelle fonctionnalité de la spécification EJB 2.1 et n'est donc pas supporté sur les versions antérieures.

Pour plus d'informations sur les beans conduits par messages, veuillez consulter : "La spécification des JavaBeans d'entreprise", Version 2.0 sur le site http://java.sun.com/. Suivez les liens pour Products & Technologies > J2EE > Enterprise JavaBeans.

Comparer les JavaBeans et les EJB To top of page

Même s'ils se ressemblent par le nom, les EJB sont beaucoup plus complexes que les habituels JavaBeans. Les deux définissent des architectures pour composants réutilisables mais les EJB ajoutent le support nécessaire pour la création de services distribués pour utilisateurs multiples. Les deux types de composants peuvent être assemblés en utilisant les outils de construction d'application, mais les EJB doivent être déployés dans un conteneur d'EJB pour être exécutés.

Les services (API) pour les composants J2EE

Les conteneurs J2EE supportent toutes les API standards de J2SE, ainsi qu'un sous-ensemble des API de J2EE, selon du type de conteneur. Les composants d'un conteneur peuvent accéder à ce sous-ensemble disponible. Le tableau suivant offre une brève description de chaque API et fait la liste des conteneurs J2EE lorsqu'ils sont disponibles.

Nom
Description
Conteneurs J2EE,
API disponibles

EJB 2.1

La spécification EJB définit un modèle de composant, pour les composants EJB du tiers entreprise, qui supporte automatiquement des services comme la communication distante, la gestion de transaction, la sécurité et la persistance.

Pour plus d'informations sur les EJB, visitez le site http://java.sun.com/ suivez les liens pour Products & Technologies > J2EE > Enterprise JavaBeans.

  • EJB
  • Application cliente*
  • Web*
  • * API cliente seulement

    JAAS

    Le service d'authentification et d'identification Java (JAAS) fournit un service d'authentification et d'identification des utilisateurs pour s'assurer qu'ils ont la permission de réaliser une action.

    Pour plus d'informations sur JAAS, visitez le site http://java.sun.com/ et suivez les liens pour Products & Technologies > J2SE > Core Java > Java Authentication and Authorization Service (JAAS).

  • Application cliente
  • Web
  • EJB
  • JAF 1.0

    L'infrastructure d'activation JavaBeans (JAF) fournit un service d'identification de données et un service d'attribution d'un JavaBean pour les manipuler.

    Pour plus d'informations sur JAF, visitez le site : http://java.sun.com/ et suivez les liens pour Products & Technologies > J2SE > Desktop Java > JavaBeans > JavaBeans Activation Framework.

  • Application cliente
  • Web
  • EJB
  • JAXP 1.2

    L'API Java pour le traitement XML (JAXP) fournit une interface abstraite pour le traitement de documents XML qui peut être utilisé avec des analyseurs syntaxiques compatibles et des transformateurs qui utilisent DOM SAX or XSLT.

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

  • Application cliente
  • Web
  • EJB
  • JAX-RPC 1.1

    La spécification JAX-RPC définit les API clientes pour accéder aux services Web
    ainsi que les techniques d'implémentation des services Web d'extrémité.

    Pour plus d'information sur JAX-RPC, visitez le site : http://java.sun.com/ et suivez les liens pour Products & Technologies > J2EE > Java API for XML-based RPC (JAX-RPC).

  • Application cliente
  • Web
  • EJB
  • Services Web pour J2EE 1.1

    La spécification de services Web pour J2EE (JSR-109) définit les possibilités qu'un serveur d'application J2EE
    doit avoir pour déployer des services Web d'extrémité.

    Pour plus d'information sur les Services Web pour J2EE, visitez le site : http://jcp.org/aboutJava/communityprocess/final/jsr109/index.html

  • Application cliente
  • Web
  • EJB
  • SAAJ 1.2

    L'API SAAJ fournit la possibilité de manipuler des messages SOAP (simple acces object protocol).

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

  • Application cliente
  • Web
  • EJB
  • JAXR 1.0

    La spécification JAXR définit les API pour l'accès du client aux registres basés sur le XML comme
    les registres ebXML et UDDI.

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

  • Application cliente
  • Web
  • EJB
  • JavaMail 1.3

    L'API JavaMail fournit une infrastructure qui peut être étendue à la construction d'applications de messages basées sur Java.

    Pour plus d'informations sur JavaMail, visitez le site : http://java.sun.com/ et suivez les liens pour Products & Technologies > J2EE > JavaMail.

  • Application cliente
  • Web
  • EJB
  • JDBC 3.0

    La connectivité aux bases de données Java (JDBC) est une API pour accéder aux sources d'informations tabulaires comme les bases de données SQL, les feuilles de calcul, et les fichiers plats.

    Pour plus d'informations sur JDBC, visitez le site : http://java.sun.com/ et suivez les liens pour Products & Technologies > J2EE > JDBC.

  • Application cliente
  • Web
  • EJB
  • JMS 1.1

    Le service de messages Java (JMS) fournit des services de messages asynchrones pour le transfert de données et la notification d'évènements. Avec JMS, il est possible d'utiliser des EJB activés par messages pour traiter de façon asynchrone des messages livrés aux topics et queues de JMS.

    Pour plus d'information sur JMS, visitez le site : http://java.sun.com/ et suivez les liens pour Products & Technologies > J2EE > Java Message Service.

  • Application cliente
  • Web
  • EJB
  • JNDI

    La spécification de l'interface de nommage et d'annuaire de Java (JNDI) fournit des services de nommage et d'annuaire pour enregistrer et parcourir les ressources et composants distribués. Seuls les clients ont besoin de savoir le nom enregistré JNDI du composant ou de la ressource et n'ont en fait pas besoin de connaître leur position dans le réseau.

    Exemple : les EJB sont enregistrés dans l'annuaire de l'entreprise au moment du développement en utilisant le champ ejb-name du descripteur de déploiement. Les clients J2EE parcourent un EJB en utilisant le processus de parcours de JNDI. Tout ce que le client doit savoir est le nom sous lequel l'EJB a été enregistré dans l'annuaire. Le processus de parcours de JNDI renvoie une référence à l'objet accueil de l'EJB.

    Pour plus d'informations sur JNDI, visitez le site : http://java.sun.com/ et suivez les liens pour Products & Technologies > J2SE > Core Java > Java Naming and Directory Interface (JNDI).

  • Application cliente
  • Web
  • EJB
  • JTA 1.0

    L'API de transaction Java (JTA) définit les interfaces pour la gestion des services de transactions distribuées entre le gestionnaire de transaction, le gestionnaire de ressources, le serveur d'application et l'application.

    Pour plus d'informations sur JTA, visitez le site : http://java.sun.com/ et suivez les liens pour Products & Technologies > J2EE > Transactions.

  • Web
  • EJB
  • J2EE Connector 1.5

    L'interface du fournisseur de services (SPI) de l'architecture du connecteur définit un standard pour connecter les ressources EIS à un conteneur J2EE, un adaptateur de ressources spécifique pour EIS (fourni par le vendeur de l'EIS) est branché au conteneur J2EE, étendant le conteneur afin qu'il fournisse un support transactionnel et sécurisé pour cet EIS. Les composants dans le conteneur peuvent accéder l'EIS à travers la SPI de l'architecture du connecteur.

    Pour plus d'informations sur les connecteurs J2EE visitez le site : http://java.sun.com/ et suivez les liens pour Products & Technologies > J2EE > J2EE Connector Architecture.

  • Web
  • EJB
  • JSP 2.0

    La technologie des pages JavaServer (JSP) fournit aux développeurs Web la possibilité de créer et de maintenir des pages Web dynamiques. Les pages JSP sont basées sur le texte et utilisent des balises du genre XML pour proposer une logique d'entreprise et générer un contenu personnalisé. La technologie JSP permet à la logique d'entreprise d'être déléguée à d'autres composants afin que seule la logique de présentation ait besoin d'être intégrée à la page JSP.

    Pour plus d'informations sur JSP, visitez le site : http://java.sun.com/ et suivez les liens pour Products & Technologies > J2EE > JavaServer Pages.

    Web

    Servlet 2.4

    Les servlets Java étendent les possibilités du serveur Web pour aider à construire des applications basées sur le Web. Les servlets sont souvent utilisés dans les applications Web interactives ou le serveur Web réponds à des demandes d'utilisateurs avec un contenu généré dynamiquement et obtenu par le système d'entreprise existant.

    Pour plus d'informations sur les servlets Java, visitez le site : http://java.sun.com/ et suivez les liens pour Products & Technologies > J2EE > Java Servlet.

    Web

    RMI-IIOP

    La technologie d'invocation de méthode distante exécutée sur le protocole Web Inter-Orb (RMI-IIOP) permet aux composants Java de communiquer avec les composants d'héritage CORBA écrits dans d'autres langages comme C++ ou Smalltalk.

    Pour plus d'informations sur RMI-IIOP, visitez le site : http://java.sun.com/ et suivez les liens pour Products and APIs > RMI-IIOP.

  • Application cliente
  • Web
  • EJB
  • J2EE Management 1.0

    L'API de gestion J2EE fournit des API pour permettre aux outils de gestion d'interroger un serveur d'application J2EE
    et de déterminer son statut actuel, les applications y étant déployées, etc.

    Pour plus d'informations sur RMI-IIOP, visitez le site : http://java.sun.com/ et suivez les liens pour Products & Technologies > J2EE > J2EE Management Specification.

  • Application cliente
  • Web
  • EJB
  • JMX 1.2

    L'API JMX est utilisée par l'API de Gestion J2EE pour fournir une partie du
    support nécessaire pour la gestion d'un produit J2EE.

    Pour plus d'informations sur RMI-IIOP, visitez le site : http://java.sun.com/ et suivez les liens pour Products & Technologies > J2SE > Core Java > Java Management Extensions (JMX).

  • Application cliente
  • Web
  • EJB
  • J2EE Deployment 1.1

    L'API de déploiement J2EE définit les interfaces entre l'environnement d'exécution
    d'un outil de déploiement et les composants de modules externes fournis par un serveur
    d'application J2EE.

    Pour plus d'informations sur le déploiement de J2EE visitez le site : http://java.sun.com/ et suivez les liens pour Products & Technologies > J2EE > J2EE Deployment Specification.

     

    JACC 1.0

    La spécification JACC définit un contrat entre un serveur d'application J2EE et un
    fournisseur de police d'autorisation.

    Pour plus d'informations sur JACC, visitez le site : http://java.sun.com/ et suivez les liens pour Products & Technologies > J2EE > Java Authorization Contract for Containers.

  • Application cliente
  • Web
  • EJB

  • L'assemblage et le déploiement To top of page

    Les applications J2EE sont composées de l'application du descripteur de déploiement (application.xml) et d'un module ou plus qui fait l'application. Les modules sont des composants portables et réutilisables. Les applications J2EE sont "empaquetés» dans les archives .ear.

    Les descripteurs de déploiement To top of page

    Les descripteurs de déploiement sont des fichiers au format XML utilisés dans les modules et les applications de J2EE. Ils fournissent des informations de configuration que le serveur J2EE lit au moment du déploiement. Cette information de configuration permet au serveur de personnaliser l'application ou le module J2EE sans avoir à changer le code source ou les classes.

    Il y a un type de descripteur de déploiement générique pour chaque application ou module J2EE. Les descripteurs de déploiement génériques comme les "ejb-jar.xml" des modules EJB, définissent l'information qui s'applique à l'EJB quel que soit le serveur sur lequel il est déployé. Les descripteurs de déploiement spécifiques au serveur spécifient l'information qui n'a de sens que pour un serveur en particulier. Les descripteurs de déploiement spécifiques au serveur ont des noms qui reflètent le serveur pour lequel ils sont faits.

    Les modules J2EE To top of page

    Un module J2EE se compose d'un descripteur de déploiement pour le module et d'un nombre d'éléments qui font le module. Ils incluent :

    • Des éléments autres que des éléments Java déployés sur le serveur Web (pages JSP, fichiers images, pages HTML statiques), autrement dit des éléments de l'annuaire 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 EJB (EJB et classes Java)

    Il y a trois types de modules J2EE :

    L'application cliente J2EETo top of page

    Les modules de l'application cliente J2EE sont empaquetés dans les archives ".jar" et contiennent :

    • Le descripteur de déploiement application-client.xml
    • Les fichiers de l'implémentation de l'application cliente ".class"
    Les composants Web To top of page

    Les modules de composants Web sont empaquetés dans les archives «.war" et contiennent :

    • Le descripteur de déploiement web «.xml" ainsi que les descripteurs de déploiements spécifiques Web
    • Des pages JSP
    • Des pages HTML
    • Des images (par exemple, .gif et .jpg)
    • Des fichiers de classe servlets

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

    • Le descripteur de déploiement "webservices.xml."
    • Des fichiers de classes servlets.
    • Des fichiers WSDL (Web services definition language).
    Les composants JavaBean d'entreprise To top of page

    Une seule archive JAR de JavaBean d'entreprise peut contenir plusieurs EJB mais leur information de déploiement est stockée dans un ensemble de descripteurs de déploiement ("ejb-jar.xml", ainsi que tout descripteur de déploiement spécifique au serveur).

    Un module JavaBean d'entreprise standard comprend :

    • ejb-jar.xml et des descripteurs de déploiement spécifiques au serveur
    • Des fichiers de classe d'implémentation EJB

    Un module de JavaBean d'entreprise de services Web comprends :

    • Des descripteurs de déploiement "webservices.xml."
    • Des fichiers de classe d'implémentation EJB

    Pour plus d'informations sur le l'empaquetage et le développement de J2EE visitez le site http://java.sun.com/. Suivez les liens pour Docs & Training > J2EE Platform, Enterprise Edition > Java Blueprints Program.

    Le développement de l'application J2EE To top of page

    Le processus de développement de l'application J2EE définit plusieurs rôles et stades. La section suivante définit les rôles de développement fournis par la spécification J2EE et les stades de développement auxquels ces rôles participent.

    Les rôles de développement de l'application J2EE To top of page

    Les rôles de développement de l'application sont résumés dans le tableau suivant :

    Nom du Rôle Description

    Fournisseur de produit J2EE

    Un fournisseur de produit J2EE est un fournisseur de l'implémentation d'une plate-forme J2EE appelée également "produit J2EE". Les fournisseurs de produit J2EE comprennent : BEA, IBM et Sun. Ces organisations utilisent leurs forces existantes pour fournir une implémentation de la plate-forme J2EE. Par exemple, l'implémentation BEA s'appuie sur le fameux moniteur de traitement de transactions Tuxedo. Un fournisseur de produit J2EE fournit également les outils nécessaires au support du déploiement et de la gestion de l'application.

    Le fournisseur de composants d'application

    Le fournisseur de composants d'application englobe en fait plusieurs rôles, comme le développeur d'EJB et le concepteur de documents HTML. Ces rôles sont responsables de la production des composants d'application J2EE en utilisant les outils fournis.

    L'assembleur d'application

    L'assembleur d'application crée une application J2EE à partir de composants de l'application J2EE en utilisant les outils fournis. L'application J2EE est livrée en tant que fichier d'archive d'entreprise (EAR). L'assembleur d'application décrit également toute dépendance externe de l'application J2EE. Le "déployeur" résous ces dépendances quand il déploie l'application J2EE.

    Le "déployeur"

    Le déployeur est responsable du déploiement d'une application J2EE et de ses composants dans un environnement opérationnel. Le premier stade du déploiement est l'installation des divers composants de l'application au sein des conteneurs appropriés. Le second stade de développement est la configuration de toute dépendance externe ayant été déclarée pour qu'elle puisse être résolue. Par exemple, les rôles de sécurité qui ont été définis sont mappés en groupes et comptes d'utilisateurs dans l'environnement opérationnel. Le troisième stade de développement est l'exécution de la nouvelle application afin qu'elle soit prête à recevoir des demandes.

    Administrateur système

    L'administrateur système est responsable de l'infrastructure de la phase d'exécution qui comprend toute application J2EE déployée. Ce rôle utilise les outils appropriés, fournis par le fournisseur de produit J2EE, pour accomplir cette tâche.

    Le fournisseur d'outil

    Le fournisseur d'outil fournit les outils pour supporter le développement et l'empaquetage des composants de l'application. Ces outils correspondent souvent aux différents types de composants d'application fabriqués, et incluent des IDE comme IBM VisualAge pour Java et Borland JBuilder.

    Le fournisseur des composants du système

    Le fournisseur des composants du système fournit des composants pour différents niveaux du système comme des adaptateurs de ressources ou des fournisseurs de polices d'autorisations.


    Ces rôles ne sont pas exclusifs et une seule personne pourrait prendre en charge plus d'un rôle, spécialement au sein de petites équipes de développement ou dans une situation de prototypage.

    Les stades de développement de J2EE To top of page

    Cette section décrit les différents stades du développement de l'application J2EE, comme stipulé dans la spécification J2EE. Les stades de développement sont :

    Une application J2EE doit contenir au minimum un module J2EE pour qu'au moins l'un des stades de développement de composants soit nécessaire. Les deux stades finaux sont toujours nécessaires puisque chaque application J2EE doit être assemblée et déployée.

    Le tableau suivant résume les stades de développement pour les applications J2EE.

    Stade de développement de J2EE Tâches Réalisé par (Rôle J2EE) Résultats (livrable)

    Création de l'application cliente J2EE

    • Ecrire les codes clients et compiler les classes
    • Créer le descripteur de déploiement ".xml" de l'application cliente
    • Créer une archive fichier JAR contenant les classes et les fichiers XML

    Le fournisseur de composants d'applications (développeur de logiciels)

    Un fichier JAR contenant l'application cliente J2EE

    Création de composants Web

    • Ecrire le code du servlet et compiler les classes
    • Ecrire les pages JSP et HTML
    • Créer le descripteur de déploiement Web ".xml."
    • Créer un fichier d'archive d'application Web (WAR). Fichier comprenant la classe, fichiers .jsp, .html et les fichiers XML

    Fournisseur de composants d'applications (Développeur de logiciels : servlets, concepteur Web : pages JSP, pages HTML)

    Un fichier JAR contenant les composants Web

    Création de JavaBean d'entreprise

    • Ecrire le code EJB et compiler les classes
    • Créer le descripteur de déploiement spécifique au serveur et le "ejb-jar.xml."
    • Créer un fichier d'archive JAR qui contient la classe et les fichiers XML

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

    Un fichier JAR contenant le JavaBean d'entreprise

    Assemblage de l'application J2EE

    • Créer le descripteur de déploiement de l'application .xml
    • Créer un fichier d'archive EAR contenant les EJB (JAR), les composants Web (WAR) et les fichiers XML

    Assembleur de l'application

    Un fichier EAR qui contient l'application J2EE

    Le déploiement de l'application J2EE

    • Ajouter l'application J2EE (EAR)à l'environnement du serveur J2EE
    • Editer le descripteur de déploiement de l'application .xml avec une configuration de l'environnement local
    • Déployer l'application J2EE sur le serveur J2EE

    "Le déployeur"

    L'application J2EE installée et configurée


    Chaque stade du processus de développement produit un "livrable" qui est utilisé au stade suivant. Les composants créés dans les stades de développement de composants sont utilisés dans le stade d'assemblage de l'application pour produire l'archive EAR de l'application J2EE. Dans le stade de déploiement de l'application J2EE, l'archive est déployée au serveur J2EE.

    Les livrables de chaque stade sont portables et ne nécessitent pas d'être utilisés par les mêmes personnes ou sur le même environnement tant que ce dernier répond aux besoins de la plate-forme J2EE.

    Pour plus d'informations sur le déploiement et l'empaquetage de J2EE, visitez le site : http://java.sun.com/. Suivez les liens pour J2EE > Blueprints.

    Plus d'informationsTo top of page

    Des informations complémentaires concernant J2EE sont disponibles dans les méthodologies de J2EE de Sun, vous pouvez les consulter sur le site : http://java.sun.com/. Suivez les liens pour J2EE > Blueprints > Guidelines: Designing Enterprise Applications with the J2EE Platform, Second Edition.

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

    Le tableau ci-dessous propose le sommaire des chapitres d'information sur les domaines spécifiques abordés dans la méthodologie J2EE de Sun.

    Le concept J2EE Les chapitres de la méthodologie de J2EE

    Les technologies de la plate-forme J2EE

    Chapitre 2

    Les JavaBeans d'entreprise

    Chapitre 5

    Les transactions

    Chapitre 8

    La sécurité

    Chapitre 9

    Les servlets

    Chapitre 4

    Les pages JavaServer

    Chapitre 4

    Le déploiement et l'empaquetage

    Chapitre 7



    RUP (Rational Unified Process)   2003.06.15