Introduction
Un module J2EE correspond à la plus petite unité indépendante de déploiement d'une application J2EE. Il existe
plusieurs types de module J2EE, comme décrit dans Concept : Présentation de J2EE.
Le nombre et la taille des modules J2EE influent sur la facilité de déploiement et de test d'une application
J2EE. Ces facteurs influent également sur la facilité de réutilisation des composants dans d'autres
applications et la facilité d'adaptation du système aux autres configurations de déploiement.
Pour plus d'informations sur l'assemblage de modules J2EE, reportez-vous à Instructions : Assemblage de modules J2EE.
Pour plus d'informations sur le déploiement de modules J2EE, reportez-vous à Instructions : Déploiement de modules et d'applications
J2EE.
Identification de modules J2EE
Les modules J2EE sont créés au cours de l'intégration, mais ils reflètent les décisions prises lors de l'implémentation
(en réalité de la conception). Les modules J2EE sont en règle générale utilisés pour mettre en package des sous-systèmes d'implémentation, pour
lesquels un mappage a lieu au produit : Conception de sous-système.
Les modules J2EE doivent contenir des EJB fortement liés et des classes auxiliaires utilisées uniquement par ces EJB.
En règle générale, de telles relations sont identifiées lors de la conception et ces classes doivent être regroupées
dans un sous-système de conception. Lors de l'identification des sous-systèmes de conception, les problèmes de
réutilisation, le remplacement et la prise en charge de plusieurs configurations de déploiement doivent déjà avoir été
étudiés. Toutefois, lorsque des modules ont été affectés à des noeuds spécifiques à des fins de déploiement, les points
faibles de la conception apparaissent et il peut s'avérer nécessaire d'apporter des changements aux sous-systèmes de
conception (et/ou d'implémentation).
Identifiez les modules J2EE qui doivent contenir des composants ayant pour cible un conteneur unique. Les composants
Web sont mis en package dans des modules Web, les composants EJB sont mis en package dans des modules EJB et les
composants de client d'application sont mis en package dans des modules de client d'application.
Les classes Java classiques utilisées par plusieurs modules doivent être mises en packages dans des modules J2EE
distincts. Les fichiers JAR qui en résultent apparaissent dans des références CLASSPATH, au niveau des modules qui
requièrent ces fichiers (ou dans dans la jointure transitive de ces références CLASSPATH).
En résumé : lorsque vous identifiez des modules J2EE, commencez par identifier un module pour chaque sous-système
d'implémentation, sauf si le sous-système contient des composants à afficher dans des conteneurs, puis définissez des
modules séparés pour chaque conteneur.
Modélisation des modules J2EE
Les modules J2EE sont représentés dans le modèle d'implémentation en tant qu'artefacts UML, un stéréotype
identifiant leur type : <<JAR EJB>>, <<JAR>> ou <<WAR>>.
Comme indiqué dans le diagramme suivant, l'assemblage de composants (des EJB ou des servlets, par exemple) en un module
J2EE peut être représenté par un graphique illustrant la dépendance <<implements>>, du composant contenu
avec le module dans lequel il est mis en package. Les dépendances <<JARInclude>> peuvent également être
indiquées pour illustrer l'insertion de la totalité d'un package Java dans l'archive.
Comme l'indique le diagramme suivant, une autre possibilité consiste à représenter l'archive comme un package et à
indiquer les composants contenus dans ce package.
Hormis la possibilité de modéliser les composants mis en package dans l'archive, vous avez également la possibilité de
modéliser les propriétés des composants, lesquelles sont au final documentées dans le descripteur de déploiement de
l'archive.
Un exemple de modélisation de quelques propriétés de composant EJB figure ci-dessous.
Le diagramme ci-dessus illustre l'assemblage de quatre EJB, BankEJB (banque), LoanEJB (prêt), CustomerEJB (client) et
LoanManagerEJB (gestionnaire de prêts), dans le même module, EJBJARArchive1. Vous remarquerez la modélisation des
propriétés de méthode EJB, les rôles de sécurité et les transactions. Dans cet exemple, l'EJB CustomerEJB est exécuté
sous le type de transaction spécifié par l'EJB CustomerTrans ("Requis", par exemple). Le code source utilise le nom de
rôle "user" (utilisateur), mappé au rôle utilisateur "Customer" (Client) dans le descripteur de déploiement. Par
ailleurs, toutes les méthodes des EJB LoanEJB et CustomerEJB sont exécutées avec les autorisations "du client", même si
l'utilisateur appelant appartient à un autre rôle. De même, les méthodes de l'EJB LoanManagerEJB sont exécutées en tant
qu'"admin". Au final, aucune méthode n'est accessible aux utilisateurs dans l'EJB BankEJB.
Un exemple de modélisation de quelques propriétés de composant Web figure ci-dessous.
Le diagramme ci-dessus illustre l'assemblage d'un servlet en un module Web. Vous remarquerez la modélisation des rôles
et des contraintes de sécurité : les utilisateurs de type "Customer" (Client) exécutent en tant qu'utilisateurs des
méthodes dans le servlet "showresults" (afficher résultats) et doivent respecter des contraintes de sécurité définies
par les propriétés de WebSecurityContraint1.
Le déploiement d'un module J2EE vers un noeud peut être indiqué dans le modèle de déploiement. Pour obtenir des
informations plus détaillées sur la modélisation du mappage de modules à des noeuds de déploiement, reportez-vous à Instructions : Description de la répartition pour les
applications J2EE.
Descripteurs de déploiement
Chaque module J2EE contient un descripteur de déploiement J2EE standard et un certain nombre de descripteurs
spécifiques au fournisseur (ce nombre étant supérieur ou égal à zéro). Les différents types de descripteurs de
déploiement sont décrits dans Concept : Présentation de J2EE. En règle générale,
les descripteurs de déploiement J2EE standard regroupent principalement les décisions de conception et
d'implémentation. Les décisions désignées dans RUP par "décisions de déploiement", qui portent par exemple sur le choix
des noeuds au niveau desquels un composant est exécuté ou sur le mode de configuration d'un composant pour un noeud
particulier, sont regroupées dans des descripteurs de déploiement spécifiques au fournisseur.
Les descripteurs de déploiement présentent deux objectifs principaux :
-
Ils représentent un moyen de communiquer les décisions de conception au conteneur. Supposons par exemple que le
descripteur de déploiement d'un EJB session comporte un "type de session" indiquant si un état ou non est doit être
affecté à l'EJB session. Une certaine cohérence doit exister entre la conception et le code (il est impossible de
procéder à des changements dans le descripteur de déploiement uniquement).
-
Ils représentent un moyen de personnaliser le comportement sans que le code ne soit recompilé. Supposons par
exemple que le comportement indique la possibilité d'utiliser le descripteur de déploiement pour définir les rôles
autorisés à appeler des méthodes spécifiques. Il est POSSIBLE de modifier ce comportement sans changer le code de
l'EJB.
Le contenu du descripteur de déploiement est défini lors de la création du module J2EE et de son assemblage en une
application J2EE. Pour plus d'informations sur l'assemblage de modules J2EE, reportez-vous à Instructions : Assemblage de modules J2EE. Pour plus
d'informations sur l'assemblage d'applications J2EE, reportez-vous à Instructions : Assemblage d'applications J2EE.
|