Wie ein Java EE-System zu strukturieren? Wie wird der Begriff Anwendung und damit der Inhalt einer EAR definiert?

Question

Ich bin im Begriff, ein Build-System und die Verzeichnisstruktur für ein großes Software-System zu entwerfen mit Java EE entwickelte 5. Das Build-System wird mit ant implementiert werden.

Wir haben mehrere verschiedene Dienste, die thematisch gruppiert sind. Jeder Dienst bietet entweder einen Web-Service oder EJBs. Jeder Dienst läuft auf einem dedizierten Anwendungsserver-Cluster. So haben wir mehrere Cluster und einige dieser Cluster können logisch nach Themen gruppiert werden.

Ich habe allgemeine Definitionen und Beispiele lesen, aber ich bin immer noch verwirrt über die Java EE Terminologie:

• Was ist eine Java-EE-Anwendung? Und so was ist der Inhalt einer EAR-Datei?
• Was ist ein Java-EE-Projekt? (Der Begriff wird von Netbeans verwendet sowie in den Java Blueprints Richtlinien Projektkonventionen für Enterprise Applications)

Müssen Ich habe alle EJB und WAR-Modul-Paket-Dateien in einem einzigen EAR, so dass diese einzelne EAR unser komplettes System enthält?

Oder habe ich jede Gruppe von Dienstleistungen in eine EAR, trotz der Tatsache, dass diese Dienste nur logisch gruppiert sind aber technisch nicht?

Oder zusammenbauen ich eine separate EAR für jeden Dienst, das heißt meistens nur eine einzige EJB-JAR-Datei enthalten, und manchmal und EJB und IST-Datei?

Oder entlassen ich das Konzept von Anwendungen und nur EJB und IST-Dateien bauen, so dass ich für jeden Anwendungsserver-Cluster genau eine Bereitstellungsdatei haben?

Ich denke, meine Hauptfrage ist: Was sind die Vorteile der Verpackung EAR-Dateien

Wie ich es im Moment zu sehen, gibt es nur die Notwendigkeit für EAR-EJB und SIND-Dateien und zusätzlich das Konzept des verschachtelten Teilprojektes in dem ant-Build-System und die Verzeichnisstruktur unserer Quelle?

Edit: Vielen Dank für die Antworten! Es scheint mir, dass eine Anwendung in ein Ohr verpackt ist ein eher Atom-Subsystem. Also ich denke, dass ich eine verschachtelte Teilprojekt-Struktur haben (nur logisch, nur sichtbar auf dem Build-System und in der Verzeichnisstruktur der Quelle) und eine ziemlich große Menge an EAH, die jeweils solche, die meist nur eine ejb-jar und / oder Kriegsmodul und einen einzigen Service Implementierung (die auf einem einzelnen Anwendungsserver-Cluster bereitgestellt wird).

Answer 1

Ich denke, was Sie sich entscheiden, in jedem Ohr zu setzen ist geregelt durch organisatorische und technische Fragen.

Ich denke, die wichtigste technische Rolle eines EAR eine Classloader Wurzel in einer Laufzeitumgebung ist. Dies bedeutet normalerweise, dass Sie verschiedene Versionen von Bibliotheken und Ihre eigenen Klassen in verschiedenen EAR bereitstellen können. Dies bedeutet, dass Sie Ihren Container Wurzel Classpath ziemlich leer (oder wie vom Behälter Lieferanten geliefert) halten sollen, weil es einem phsyical Behälter mehr Anwendungen Service ermöglichen, möglicherweise widersprüchlichen Bibliotheken. Dies ist eine gute Nachricht, wenn Sie eine Reihe von verschiedenen Anwendungen sind die Entwicklung einer gemeinsamen Code-Basis. Sie können eine Reihe von Projekten haben zu der gleichen Farm von Servern bereitstellen, ohne sie vermasseln.

Sie werden in der Regel nie eine kleinere Einheit von Software als die EAR bereitstellen. Jede EAR kann mehr oder weniger vollständig in sich abgeschlossen. Normalerweise würde ich den Inhalt dieser lassen refelect was die Eigentümerorganisation denkt als Anwendungen oder Subsystemen. Sie können in der Regel die gleichen Komponenten in mehreren EAR verpacken.

Answer 2

Viele Fragen hier.

Java EE-Projekte sind entweder EAR- oder WAR-Implementierungen, die Java EE-Technologie verwenden. Wenn Sie einen Krieg mit JSPs und JDBC-Zugriff einer relationalen Datenbank haben, ist, dass ein Projekt Java EE. Die ursprüngliche Absicht war, dass die EAR-Dateien waren „Unternehmen“, und das bedeutete, EJBs. EAR-Datei ein enthalten EJBs, kriege, JAR-Dateien, die ganze Enchilada.

Das Denken in Bezug auf Dienstleistungen sind ein wenig anders. Ich denke, Bereitstellung eines sorgfältige Prüfung verdient, da Komponenten, die zusammen verpackt sind, müssen nach oben und unten zusammengebracht werden, wenn eine Wartung durchgeführt werden muss.

So sorgfältig darüber nachdenken, wie Sie Ihre Service-Paket. Es ist nicht ein alle oder keine Decke Antwort, IMO. Sie sollten schauen, was Ihre Dienste tun und wie sie zusammen verwendet werden könnten, um zu entscheiden, wie sie verpackt werden sollten und eingesetzt werden.

Answer 3

logische und organisatorische Überlegungen ins Spiel kommen. Jede EAR würde alle Stücke, die für eine bestimmte Fähigkeit zu tun haben. Wir können immer davon ausgehen, dass jede EAR wird selbst enthalten sein und kann auf einem oder mehreren Behältern eingesetzt werden. Der typische Ansatz, den ich habe immer gefolgt ist jede EAR hat ein oder mehr Gläser und Kriege. Jeder Krieg oder Glas enthält einige wichtige Komponente oder einen Satz von zugehörigen Komponenten. Die EAR stellt eine Enterprise-Anwendung, die die Komponenten und Web-Anwendungen für die Anwendung enthält. Ein Beispiel ist ein Zahlungsverarbeitungssystem I beteiligt war. Die EAR enthielt alles, was erforderlich, um das Payment Processing System auszuführen. Dazu gehörte auch ein halbes Dutzend Gläser und drei Kriege. Jedes Gefäß repräsentiert einige Funktionen oder logische Gruppierung von Funktionalität. Jeder Krieg stellte einen Web-App. Ein Beispiel für die JAR-Komposition:

• ein Glas für Kernfunktionalität
• ein Glas für EJBs
• ein Glas für unsere fortschrittlichen Finanz math Stücke
• ein Glas für unsere Sicherheit Stücke usw. mehrere Gläser wurde durch die Tatsache diktiert, dass verschiedene Menschen verschiedene Stücke entwickelt, so dass sie in verschiedenen Eclipse-Projekten gearbeitet und kombiniert sie alle nach Bedarf. Es gibt keine festen Regeln, nur, was funktioniert für Ihr Team und Situation.