Richtlinie: J2EE-Modul
In dieser Richtlinie wird das J2EE-Modul beschrieben, die kleinste unabhängige Deployment-Einheit in einer J2EE-Anwendung.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Einführung

Ein J2EE-Modul ist die kleinste unabhängige Deployment-Einheit in einer J2EE-Anwendung. Wie unter Konzept: Überblick über J2EE beschrieben, gibt es unterschiedliche Arten von J2EE-Modulen.

Anzahl und Größe der J2EE-Module bestimmen, wie einfach die Implementierung und der Test einer J2EE-Anwendung sind. Außerdem wird dadurch festgelegt, wie einfach es ist, Komponenten für andere Anwendungen wiederzuverwenden und das System an andere Implementierungskonfigurationen anzupassen.

Informationen zur Assemblierung von J2EE-Modulen finden Sie unter Richtlinie: J2EE-Module assemblieren.

Informationen zur Implementierung von J2EE-Modulen finden Sie unter Richtlinie: J2EE-Module und -Anwendungen implementieren.

J2EE-Module festlegen

J2EE-Module werden während der Integration erstellt, sie zeigen aber die Entscheidungen, die bei der Implementierung (und tatsächlich im Design) getroffen wurden. J2EE-Module werden normalerweise verwendet, um Implementierungssubsysteme zu packen, die in der Regel Designsubsystemen zugeordnet sind.

J2EE-Module sollten eng zusammengehörige EJBs und Helper-Klassen, die nur von diesen EJBs verwendet werden, enthalten. Im allgemeinen werden solche Abhängigkeiten im Design festgelegt, und diese Klassen würden dann in einem Designsubsystem gruppiert werden. Beim Festlegen der Designsubsysteme müssen die Aspekte der Wiederverwendbarkeit, Ersetzung und Unterstützung mehrerer Implementierungskonfigurationen bereits berücksichtigt worden sein. Wenn die Module zwecks Implementierung bestimmten Knoten zugeordnet werden, können allerdings Schwachstellen im Design sichtbar werden und es können Änderungen in den Designsubsystemen (und/oder in den Implementierungssubsystemen) notwendig sein.

Legen Sie J2EE-Module so fest, dass sie nur Komponenten enthalten, die für einen einzelnen Container vorgesehen sind. Webkomponenten werden in Webmodule gepackt, EJB-Komponenten in EJB-Module und Anwendungsclientkomponenten in Anwendungsclientmodule.

Reguläre Java-Klassen, die von mehreren Modulen verwendet werden, sollten in separate J2EE-Module gepackt werden. Die resultierenden JAR-Dateien erscheinen in Klassenpfadreferenzen in den Modulen, die sie benötigen (oder im transitiven Ende solcher Klassenpfadreferenzen).

Zusammenfassend lässt sich feststellen, dass zum Festlegen von J2EE-Modulen zunächst ein Modul für jedes Implementierungssubsystem bestimmt werden muss, es sei denn, das Subsystem enthält Komponenten, die in unterschiedlichen Containern implementiert werden sollen, und dass anschließend separate Module für jeden Container definiert werden müssen.

J2EE-Module modellieren

J2EE-Module werden im Implementierungsmodell als UML-Artefakte mit einem Stereotyp angegeben, das seinen Typ festlegt: <<EJB-JAR>>, <<JAR>> oder <<WAR>>.

Die Zusammensetzung von Komponenten (z. B. EJBs oder Servlets) zu einem J2EE-Modul kann grafisch dargestellt werden, indem wie im folgenden Diagramm eine <<implements>>-Abhängigkeit von der enthaltenen Komponente zu dem Modul gezeichnet wird, in das sie gepackt wurde. <<JARInclude>>-Abhängigkeiten können ebenfalls gezeichnet werden, um die Aufnahme eines gesamten Java-Pakets in das Archiv darzustellen.

Im Begleittext beschriebenes Diagramm.

Eine weitere Art der Darstellung kann, wie im folgenden Bild, das Archiv als Paket und die im Paket enthaltenen Komponenten zeigen.

Im Begleittext beschriebenes Diagramm.

Sie können nicht nur modellieren, welche Pakete in das Archiv gepackt sind, sondern Sie können auch Eigenschaften der Komponenten modellieren, die letztlich im Implementierungsdeskriptor des Archivs dokumentiert sind.

Ein Beispiel dafür, wie einige dieser EJB-Komponenteneigenschaften modelliert werden, wird nachfolgend gezeigt.

Im Begleittext beschriebenes Diagramm.

Das oben dargestellte Diagramm zeigt die Assemblierung der EJBs BankEJB, LoanEJB, CustomerEJB und LoanManagerEJB in einem einzigen Modul, EJBJARArchive1. Beachten Sie die Modellierung der EJB-Methodeneigenschaften, der Sicherheitsrollen und der Transaktionen. In diesem Beispiel wird die CustomerEJB unter dem von CustomerTrans angegebenen Transaktionstyp (z. B. "Required") ausgeführt. Der Quellcode verwendet den Rollennamen "user", der im Implementierungsdeskriptor der Benutzerrolle "Customer" zugeordnet ist. Außerdem werden alle Methoden in LoanEJB und CustomerEJB unter Verwendung der Berechtigungsnachweise von "Customer" ausgeführt, selbst wenn der aufrufende Benutzer zu einer anderen Rolle gehört. In ähnlicher Weise werden die LoanManagerEJB-Methoden als "Admin" ausgeführt. Die Benutzer in BankEJB schließlich können auf keine Methoden zugreifen.

Ein Beispiel dafür, wie einige Webkomponenteneigenschaften modelliert werden, wird nachfolgend gezeigt.

Im Begleittext beschriebenes Diagramm.

Das oben dargestellte Diagramm zeigt die Assemblierung eines Servlets in ein Webmodul. Beachten Sie die Modellierung der Sicherheitsrollen und Integritätsbedingungen. Die Benutzer des Typs "Customer" führen Methoden im Servlet show als sie selbst aus, unterliegen aber den Integritätsbedingungen für die Sicherheit, die durch die Eigenschaft WebSecurityContraint1 definiert werden.

Die Implementierung eines J2EE-Moduls in einem Knoten kann im Implementierungsmodell gezeigt werden. Nähere Informationen zur Modellierung der Zuordnung von Modulen zu Implementierungsknoten finden Sie unter Richtlinie: Beschreibung der Verteilung für J2EE-Anwendungen.

Implementierungsdeskriptoren

Jedes J2EE-Modul enthält einen J2EE-Standardimplementierungsdeskriptor sowie null oder mehr herstellerspezifische Deskriptoren. Die unterschiedlichen Arten von Implementierungsdeskriptoren werden unter Konzept: Überblick über J2EE erläutert. Im allgemeinen enthalten die J2EE-Standardimplementierungsdeskriptoren primär Entscheidungen bezüglich Design und Implementierung. Entscheidungen, die man in RUP als "Implementierungsentscheidungen" bezeichnet würde, z. B. auf welchen Knoten eine Komponente ausgeführt wird und wie eine Komponente für einen bestimmten Knoten konfiguriert wird, werden in herstellerspezifischen Implementierungsdeskriptoren festgelegt.

Die Implementierungsdeskriptoren erfüllen zwei Zwecke:

  • Sie sind ein Mittel, um dem Container Designentscheidungen mitzuteilen. Beispielsweise verfügt der Implementierungsdeskriptor für eine Session-EJB über einen "session-type", der anzeigt, ob die Session-EJB statusabhängig (stateful) oder statusunabhängig (stateless) ist. Dies muss mit dem Design und Code konform sein - es kann im Implementierungsdeskriptor nicht einfach geändert werden.
  • Sie bieten die Möglichkeit, das Verhalten ohne erneutes Kompilieren des Codes anzupassen. Beispielsweise kann mit dem Implementierungsdeskriptor definiert werden, welche Rollen zum Aufruf bestimmter Methoden berechtigt sind. Dies darf geändert werden, ohne dass der Code der EJB geändert werden muss.

Der Inhalt des Implementierungsdeskriptors wird festgelegt, wenn das J2EE-Modul erstellt und in einer J2EE-Anwendung assembliert wird. Nähere Informationen zur Assemblierung von J2EE-Modulen finden Sie unter Richtlinie: J2EE-Module assemblieren. Nähere Informationen zum Assemblieren von J2EE-Anwendungen finden Sie unter Richtlinie: J2EE-Anwendungen assemblieren.