Comment structurer un système Java EE? Comment le terme application et donc le contenu d'un EAR est-il défini?

Question

Je suis en train de concevoir un système de construction et la structure de répertoires d'un grand système logiciel développé avec Java EE 5. Le système de construction sera implémenté à l'aide de ant.

Nous avons plusieurs services différents, qui sont regroupés par thème. Chaque service offre un service Web ou des EJB. Chaque service s'exécute sur un cluster de serveurs d'applications dédié. Ainsi, nous avons plusieurs clusters et certains de ces clusters peuvent être regroupés de manière logique par thèmes.

J'ai lu des définitions génériques et des exemples, mais la terminologie Java EE me laisse perplexe:

• Qu'est-ce qu'une application Java EE? Et ainsi, quel est le contenu d’un fichier EAR?
• Qu'est-ce qu'un projet Java EE? (le terme est utilisé par Netbeans ainsi que dans les conventions du projet Java Blueprints Guidelines pour les applications d'entreprise)

Dois-je mettre tous les fichiers EJB et WAR-module-package-package dans un seul fichier EAR, afin que ce fichier EAR unique contienne notre système complet?

Ou dois-je placer chaque groupe de services dans un seul fichier EAR, malgré le fait que ces services ne sont regroupés que logiquement, mais non techniquement?

Ou dois-je assembler un fichier EAR distinct pour chaque service, c'est-à-dire ne contenant le plus souvent qu'un seul fichier jar EJB et parfois un fichier EJB et un fichier WAR?

Ou est-ce que je rejette le concept d'applications et ne crée que des fichiers EJB et WAR, de sorte que je dispose exactement d'un fichier de déploiement pour chaque cluster de serveurs d'applications?

Je suppose que ma principale question est la suivante: quels sont les avantages de l’emballage des fichiers EAR?

Comme je le vois pour le moment, seuls les fichiers EAR-EJB et WAR sont nécessaires, ainsi que le concept de sous-projet imbriqué dans le système ant-build-system et la structure de répertoires de notre source?

Edit: Merci beaucoup pour les réponses! Il me semble qu'une application empaquetée dans une oreille est un sous-système plutôt atomique. Je suppose donc que j'aurai une structure de sous-projet imbriquée (uniquement logique, visible uniquement par le système de construction et dans la structure de répertoires de la source) et une quantité assez importante d'EAR, chacun de ceux-ci contenant principalement un seul ejb-jar et / ou war et la mise en œuvre d’un seul service (déployé sur un seul cluster de serveurs d’applications).

Answer 1

Je pense que ce que vous décidez de mettre dans chaque EAR est régi par des problèmes organisationnels et techniques.

Je pense que le rôle technique le plus important d'un fichier EAR est celui d'un chargeur de classe dans un environnement d'exécution. Cela signifie normalement que vous pouvez déployer différentes versions de bibliothèques et vos propres classes dans différents EAR. Cela signifie que vous devez garder votre chemin de classe racine du conteneur assez vide (ou tel que fourni par le fournisseur du conteneur), car il peut permettre à un conteneur physique de desservir plusieurs applications à l'aide de bibliothèques potentiellement en conflit. C'est une bonne nouvelle si vous développez différentes applications à l'aide d'une base de code commune. Vous pouvez avoir plusieurs projets déployés sur la même batterie de serveurs sans vous gêner.

Normalement, vous ne déploierez jamais une unité de logiciel plus petite que le fichier EAR. Chaque EAR peut être plus ou moins totalement autonome. Je laisserais normalement le contenu de ces éléments recréer ce que l'organisation propriétaire considère comme des applications ou des sous-systèmes. Vous pouvez généralement regrouper les mêmes composants dans plusieurs fichiers EAR.

Answer 2

Beaucoup de questions ici.

Les projets Java EE sont des déploiements EAR ou WAR qui utilisent la technologie Java EE. Si vous avez un fichier WAR avec JSP et l'accès JDBC d'une base de données relationnelle, il s'agit d'un projet Java EE. L'intention initiale était que les fichiers EAR étaient des "entreprises", ce qui signifiait des EJB. Un fichier EAR peut contenir des EJB, des WAR, des JAR et toute l’enchilada.

Penser en termes de services est un peu différent. Je pense que le déploiement mérite une attention particulière, car les composants emballés ensemble doivent être rapprochés et remontés ensemble si une opération de maintenance doit être effectuée.

Alors réfléchissez bien à la manière dont vous packagez vos services. Ce n'est pas une réponse globale ou inexistante, IMO. Vous devriez regarder ce que font vos services et comment ils pourraient être utilisés ensemble pour décider de la manière dont ils devraient être empaquetés et déployés.

Answer 3

Les considérations logiques et organisationnelles entrent en jeu. Chaque EAR contiendrait toutes les pièces liées à une capacité particulière. Nous pouvons toujours supposer que chaque EAR sera autonome et pourra être déployé sur un ou plusieurs conteneurs. L’approche habituelle que j’ai toujours suivie est de faire en sorte que chaque oreillette contienne un ou plusieurs pots et guerres. Chaque guerre ou pot contient un composant clé ou un ensemble de composants associés. Le fichier EAR représente une application d'entreprise contenant les composants et les applications Web de l'application. Un exemple est un système de traitement de paiement auquel j'ai participé. Le fichier EAR contenait tout le nécessaire pour exécuter le système de traitement des paiements. Cela comprenait une demi-douzaine de bocaux et 3 guerres. Chaque jar représentait une fonctionnalité ou un groupement logique de fonctionnalités. Chaque guerre représentait une application Web. Un exemple de composition du pot:

• un pot pour les fonctionnalités de base
• un pot pour ejbs
• un bocal pour nos mathématiques avancées en mathématiques financières
• un pot pour nos pièces de sécurité etc. Avoir plusieurs jarres était dicté par le fait que différentes personnes ont développé différentes pièces, ce qui leur a permis de travailler dans différents projets Eclipse et de les combiner au besoin. Il n'y a pas de règles strictes, juste ce qui fonctionne pour votre équipe et votre situation.