Einführung
Diese Richtlinie konzentriert sich auf das Festlegen von EJBs. Nähere Informationen zu EJBs finden Sie unter Richtlinie: Enterprise JavaBean (EJB).
EJBs festlegen
Normalerweise werden EJBs verwendet, um ein Geschäftsobjekt der Serverseite zu implementieren, das Unterstützung für
Transaktionen, Sicherheit und Fernzugriff benötigt oder das für gemeinsame Daten ausgeführt wird (z. B.
Account-Informationen aktualisiert).
EJBs werden häufig festgelegt, wenn Designklassen aus der Analyseklasse ermittelt werden. In der Regel eignen sich
Steuerungsklassen als Session-Beans, weil die Session-Beans die Steuerlogik bereitstellen. Entitätsklassen wiederum
eignen sich für Entity-Beans, weil Entity-Beans dafür eingerichtet sind, Daten persistent zu speichern.
Lesen Sie auch folgende Richtlinien mit spezielleren Informationen:
Vergleich zwischen Session-Beans, nachrichtengesteuerten
Beans und Entity-Beans
In der folgenden Tabelle sind einige der oben erwähnten Richtlinien zusammengefasst. Sie zeigt, welche Rollen die
verschiedenen EJBs annehmen, wie auf die EJBs zugegriffen wird und welchen Status sie annehmen.
|
Session-Beans
|
Nachrichtengesteuerte Beans
|
Entity-Beans
|
Rolle
|
Clientspezifische Geschäftslogik implementieren
|
Spezielle Geschäftslogik für die Nachrichtenverarbeitung implementieren
|
Spezielle Geschäftslogik für Geschäftsentitäten implementieren
|
Zugriffsmethode
|
Einzelner Client über lokale oder ferne Schnittstelle
|
Container über JMS-MessageListener-Schnittstelle; kein direkter Zugriff der Clients
|
Viele simultane Clients über lokale und ferne Schnittstellen
|
Status
|
Transienter Dialogstatus zwischen Client und Container kann aufrechterhalten werden
|
Statusunabhängig (stateless), kann jedoch Kennungen für Ressourcen in der Instanz speichern
|
Persistenter Status wird in der Datenbank gespeichert
|
EJBs modellieren
EJBs werden als Gruppe von Klassen mit Stereotypen modelliert, insbesondere die Bean-Klasse und alle
EJB-Schnittstellenklassen. EJB-Schnittstellen werden als Klassen mit Stereotypen modelliert, nicht als
UML-Schnittstellen. Die Gründe dafür werden in der Richtlinie: Schnittstellen für J2EE-Anwendungen erläutert.
Die Beziehungen zwischen der Bean-Klasse und den EJB-Schnittstellen werden als Abhängigkeiten der Bean-Klasse von den
Schnittstellen modelliert. In der Regel wird das Java-Implementierungskonstrukt als Realisierung zwischen einer
Schnittstelle und einer Klasse dargestellt. Allerdings implementieren EJB-Klassen ihre Schnittstellenklassen nicht,
daher ist eine Abhängigkeit besser geeignet. Ein Beispiel hierfür sehen Sie im folgenden Diagramm. Nähere Informationen
zu diesem bestimmten Beispiel finden Sie unter Richtlinie: Design der Subsysteme für J2EE-Anwendungen.
Beispiel-EJB und Helper-Klassen
Nachfolgend sind die UML-Stereotypen aufgeführt, die für die Modellierung von EJBs verwendet werden können.
Stereotyp
|
Anwendbar für
|
Definition
|
<<EJBSessionHomeInterface>>
<<EJBEntityHomeInterface>>
|
Klasse
|
Gibt eine Sitzungs- bzw. eine Entity-Home-Schnittstelle an.
|
<<EJBRemoteInterface>>
|
Klasse
|
Gibt eine ferne EJB-Schnittstelle an.
|
<<EJBLocalInterface>>
|
Klasse
|
Gibt eine lokale EJB-Schnittstelle an.
|
|
|
|
<<EJBSession>>
|
Klasse
|
Gibt eine EJB-Session-Bean-Klasse an.
|
<<EJBEntity>>
|
Klasse
|
Gibt eine EJB-Entity-Bean-Klasse an.
|
<<EJBMessageDriven>>
|
Klasse
|
Gibt an, dass die Klasse eine nachrichtengesteuerte Bean ist.
|
Eine EJB ist normalerweise zusammen mit eng zusammengehörigen Klassen und EJBs in einem Subsystem gruppiert. Dies
erlaubt es dem Designer, eine Spezifikationssicht der EJBs unabhängig von ihrer Implementierung bereitzustellen
und sie mit anderen Designelementen zu gruppieren, um eine Abstraktion auf höherer Ebene zu erzielen. Nähere
Einzelheiten finden Sie unter Richtlinie: Design der Subsysteme für J2EE-Anwendungen.
Außerdem finden Sie eine vollständige Liste von Stereotypen, die EJB-Konstrukte darstellen, in der "UML/EJB Mapping
Specification" (RSC01).
Modellieren Sie Abhängigkeiten zu den Topics oder Warteschlangen, die die nachrichtengesteuerte Bean abonniert. Nähere
Anleitungen zum Modellieren von gleichzeitig ausgeführten Elementen in einer J2EE-Anwendung finden Sie unter Richtlinie: Beschreibung der Laufzeitarchitektur für J2EE-Anwendungen.
Mechanismen wie die containergesteuerte Persistenz, Transaktionen, Berechtigung usw. können als zusätzliche Merkmale
der Bean-Klasse modelliert werden oder einfach in eine Textbeschreibung aufgenommen werden, die der Bean-Klasse
zugeordnet wird.
Verwenden Sie Ablaufdiagramme, um Szenarios zu entwerfen, die diese Mechanismen verwenden.
Interaktionsdiagramme (Kollaborationsdiagramme und Ablaufdiagramme) können verwendet werden, um das dynamische
Verhalten von EJBs und die Interaktion mit Nicht-EJBs (einschließlich Webkomponenten und externen Clientanwendungen) zu
zeigen.
Diese Interaktionsdiagramme entsprechen im wesentlichen den unter Aufgabe:
Anwendungsfalldesign beschriebenen Diagrammen. Interaktionen können mit der Bean als Blackbox gezeigt
werden, indem nur Interaktionen mit der EJB-Schnittstelle ausgeführt werden. Interaktionen können außerdem die
Bean-Implementierung zeigen, indem Interaktionen zwischen den EJB-Schnittstellen und der Bean-Implementierungsklasse
gezeigt werden. Beachten Sie, dass zwischengeschaltete Interaktionen mit dem Container im allgemeinen nicht gezeigt
werden.
Nachrichtengesteuerte Beans konsumieren Nachrichten, die asynchron von anderen Quellen ankommen. Sie können zeigen, wie
eine asynchrone Nachricht direkt vom Produzenten zum Konsumenten fließt oder Sie können die die Beziehung zwischen
Produzenten und Konsumenten genauer modellieren, indem Sie Topics und Warteschlangen modellieren.
Ein Beispiel für ein Ablaufdiagramm, dass eine Interaktion einer Clientklasse mit EJB-Schnittstellen zeigt, ist in
Abbildung 2 dargestellt.
Abbildung 2: Interaktion einer
Clientklasse mit EJB-Schnittstellen
Abbildung 3 ist ein Ablaufdiagramm ähnlich dem in Abbildung 2, es zeigt jedoch Interaktionen mit der
Bean-Implementierung.
Abbildung 3: Beispiel für eine Interaktion mit einer
EJB-Implementierung
Die EJB, die eine Gruppierung einer Bean-Implementierungsklasse plus EJB-Schnittstellen darstellt, kann auch als
Subsystem oder Komponente modelliert werden.
Manche Designer können eine EJB auch als Klasse modellieren und Stereotype für die Operationen festlegen, um anzugeben,
ob sie zur lokalen, zur fernen oder zur Home-Schnittstelle gehören. Dies erlaubt eine kompaktere Notation als die
anderen Alternativen.
|