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.
Eine weitere Art der Darstellung kann, wie im folgenden Bild, das Archiv als Paket und die im Paket enthaltenen
Komponenten zeigen.
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.
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.
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.
|