Instructions: Module J2EE
Ces instructions portent sur le module J2EE, la plus petite unité de déploiement indépendante d'une application J2EE.
Relations
Eléments connexes
Description principale

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.

Diagramme décrit dans le texte d'accompagnement.

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.

Diagramme décrit dans le texte d'accompagnement.

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.

Diagramme décrit dans le texte d'accompagnement.

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.

Diagramme décrit dans le texte d'accompagnement.

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.