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 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)
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.
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.
|
|
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.
|
|
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
|
|