Principes et conseils : Module J2EE
Rubriques
Introduction
Un module J2EE est la plus petite unité indépendante de déploiement d'une application J2EE. Les modules J2EE sont de différentes sortes, comme indiqué dans Concepts :
Présentation de J2EE.
Le nombre et la taille des modules J2EE influe sur la facilité avec laquelle une application J2EE est déployée et testée, avec laquelle ses composants peuvent être réutilisés dans d'autres applications et avec laquelle le système peut être adapté à d'autres configurations de déploiement.
Pour plus d'informations sur l'assemblage des modules J2EE, voir Principes et conseils :
Assemblage des modules J2EE.
Pour plus d'informations sur le déploiement des modules J2EE, voir Principes et conseils :
Déploiement des modules et des applications J2EE.
Identification des modules J2EE
Les modules J2EE sont créés lors de l'intégration, mais ils témoignent des décisions prises dans la phase d'implémentation (et en fait dans celle de conception). Les modules J2EE sont communément utilisés pour empaqueter les sous-systèmes d'implémentation, correspondant généralement à des Artefact : Sous-systèmes de conception.
Les modules J2EE doivent contenir des EJB étroitement liés et des classes d'aide utilisées uniquement par ces EJB. En général, ces relations sont identifiées à la conception, et ces classes sont regroupées dans un sous-système de conception. L'identification de sous-systèmes de conception doit avoir déjà pris en compte les problèmes de réutilisation, de remplacement et de prise en charge pour plusieurs configurations de déploiement. Néanmoins, lorsque les modules sont attribués pour le déploiement de noeuds spécifiques, les faiblesses de conception apparaissent et des modifications peuvent s'avérer nécessaires dans les sous-systèmes de conception (et/ou d'implémentation).
Identifiez les modules J2EE devant contenir des composants destinés à un conteneur unique.
Les composants Web sont empaquetés dans des modules Web, les composants EJB dans des modules EJB et les composants des clients d'application dans des modules Client d'application.
Les classes régulières Java utilisées par plusieurs modules doivent être empaquetées dans des modules J2EE séparés. Les fichiers JAR résultants apparaissent dans des références de chemin de classe dans les modules qui en ont besoin (ou dans la fermeture transitive de ces références de chemin de classe).
En résumé, lorsque vous identifiez des modules J2EE, commencez par identifier un module pour chaque sous-système d'implémentation (à moins que ce sous-système ne contienne des composants à déployer dans des conteneurs différents), puis définissez des modules séparés pour chacun des conteneurs.
Modélisation des modules J2EE
Les modules J2EE sont représentés dans le modèle d'implémentation sous la forme d'artefacts UML avec un stéréotype identifiant leur type : <<EJB-JAR>>,
<<JAR>> ou <<WAR>>.
La composition des composants (tels que les EJB ou les servlets) dans un module J2EE peut être représentée graphiquement par une flèche de dépendance <<implements>> tracée du composant vers le module où il est empaqueté, comme indiqué sur le diagramme ci-dessous. Des dépendances <<JARInclude>> peuvent également être tracées pour représenter l'inclusion d'un package Java entier dans l'archive.

Une autre option consiste à représenter l'archive comme un package et représenter les composants qu'elle contient comme sur le diagramme ci-dessous.

Vous pouvez modéliser non seulement les composants empaquetés dans l'archive, mais également les propriétés des composants, qui sont documentées en fin de processus dans les descripteurs de déploiement des archives des modules et de l'application.
Un exemple de modélisation des propriétés de certains composants EJB est représenté ci-dessous.

Le diagramme ci-dessus représente l'assemblage de quatre EJB, BankEJB, LoanEJB, CustomerEJB,
et LoanManagerEJB dans le même module, EJBJARArchive1. Observez la modélisation des propriétés des méthodes EJB, des rôles de sécurité et des transactions. Dans cet exemple, CustomerEJB s'exécute sous le type de transaction spécifié par CustomerTrans
("Required", par exemple). Le code source utilise le nom de rôle "user",
mappé au rôle d'utilisateur "Customer" dans le descripteur de déploiement.
De plus, toutes les méthodes de LoanEJB et de CustomerEJB sont exécutées avec les attributs de sécurité du "Customer", même si l'utilisateur appelant la méthode appartient à un rôle différent. De même, les méthodes de LoanManagerEJB sont exécutées comme "Admin". Enfin, aucune méthode n'est accessible aux utilisateurs dans BankEJB.
Un exemple de modélisation de propriétés de composants Web est représenté ci-dessous.

Le diagramme ci-dessus représente l'assemblage d'un servlet dans un module Web. Observez la modélisation des rôles de sécurité et des contraintes, où les utilisateurs de type "Customer" exécutent des méthodes dans le servlet showresults en tant qu'eux-mêmes, sujets aux contraintes de sécurité définies par les propriétés de WebSecurityContraint1.
Le déploiement d'un module J2EE sur un noeud peut être représenté dans le modèle de déploiement.
Voir Principes et conseils : Description de la distribution des applications J2EE pour une étude plus approfondie de la modélisation du mappage entre modules et noeuds de déploiement.
Descripteurs de déploiement
Chaque module J2EE contient un descripteur de déploiement standard J2EE, ainsi que zéro ou plus descripteurs spécifiques au fournisseur. Les différentes sortes de descripteurs de déploiement sont décrits dans Concepts : Présentation de J2EE.
En général, les descripteurs de déploiement standard contiennent principalement les décisions de conception et d'implémentation. Les décisions auxquelles le processus RUP se rapporte comme "décisions de déploiement", telles que le choix des noeuds sur lesquels un composant s'exécute et la manière dont un composant est configuré pour un noeud particulier, sont rassemblés dans les descripteurs de déploiement spécifiques aux fournisseurs.
Les descripteurs de déploiement répondent à deux objectifs séparés :
- Un moyen de communiquer les décisions de conception au conteneur. Par exemple, le descripteur de déploiement d'une session EJB comporte une section "session-type"
indiquant s'il s'agit d'un EJB avec ou sans état. Cette valeur doit être cohérente avec la conception et le code : on ne peut pas la modifier purement et simplement dans le descripteur de déploiement.
- Un moyen de personnaliser le comportement sans devoir recompiler le code. Par exemple, un descripteur de déploiement peut être utilisé pour définir les rôles autorisés pour appeler des méthodes spécifiques. Dans ce cas, cette valeur PEUT être modifiée sans que le code de l'EJB ne doive être modifié.
Le contenu du descripteur de déploiement est défini lors de la création du module J2EE et de son assemblage dans une application J2EE. Pour plus d'informations sur l'assemblage des modules J2EE, voir Principes et conseils : Assemblage des modules J2EE. Pour plus d'informations sur l'assemblage des applications J2EE, voir
Principes et conseils : Assemblage des applications J2EE.
|