Einführung
Diese Richtlinie konzentriert sich auf das Festlegen von Session-Beans. Nähere Anleitungen zu Session-Beans finden Sie
unter Richtlinie: Session-Bean. Allgemeine Anleitungen zu EJBs finden Sie unter Richtlinie: Enterprise JavaBean (EJB).
Session-Beans festlegen
In der Regel eignen sich Steuerungsklassen gut für Session-Beans, weil die Session-Beans die Steuerlogik bereitstellen,
insbesondere, wenn diese Steuerlogik den Dialog mit einem Client beinhaltet. Eine Session-Bean wird außerdem häufig als
Fassade für eine Gruppe von Objekten in der Geschäftsschicht festgelegt (siehe
weiter unten). Beginnend mit J2EE 1.4 können außerdem Stateless-Session-Beans zum Implementieren von Web-Services
verwendet werden.
Wenn Sie mit J2EE 1.3 arbeiten, sieht die Standardvorgehensweise so aus, dass alle fernen Clientzugriffe über
Session-EJBs ausgeführt werden, die die Entity-EJBs in derselben JVM über lokale Komponentenschnittstellen steuern.
Session-Beans modellieren
Siehe Richtlinie: Enterprise JavaBeans (EJBs) festlegen.
Statusabhängige vs. statusunabhängige Beans
Es gibt zwei Arten von Session-Beans: statusabhängige (stateful) und statusunabhängige (stateless). Eine Aufgabe beim
Festlegen einer Session-Bean ist die Definition ihrer Zuständigkeiten, wovon eine die Aufrechterhaltung des
Clientstatus zwischen den Aufrufen sein kann.
Stateful-Session-Beans (Session-Bean mit Statusaufzeichnung) enthalten Statusinformationen zum Dialog zwischen Client
und EJB-Container. Eine Instanz einer Stateful-Session-Bean existiert nur für die Dauer des Clientdialogs.
Normalerweise führen Stateful-Session-Beans Services aus, indem Sie diese Daten für den Client verwenden. Die Services,
die eine Stateful-Session-Bean bereitstellt, können die Interaktionen von anderen Geschäftsobjekten (Session-Beans und
Entity-Beans) koordinieren. Beispielsweise kann ein elektronischer Warenkorb, der Kaufobjekte enthält, mit einer
Stateful-Session-Bean implementiert werden, weil sie Informationen speichert, während der Client mit der Anwendung
interagiert. Weil Stateful-Session-Beans einem bestimmten Client zugeordnet sind, belegen sie eine größere Menge an
Systemressourcen als eine Stateless-Session-Bean (Session-Bean ohne Statusaufzeichnung), um den Vorteil bieten zu
können, den Clientstatus zu bewahren. Der Container verwaltet diese Ressourcen, indem er die Stateful-Session-Beans in
der Regel "passiviert" (auf die Platte schreibt) und bei Bedarf reaktiviert.
Stateless-Session-Beans enthalten keine Statusinformationen zum Dialog zwischen Client und EJB-Container. Der Begriff
"Stateless", d. h. statusunabhängig, bedeutet, dass kein Clientdialogstatus existiert. Eine Stateless-Session-Bean kann
daher andere Arten von Statusinformationen enthalten, z. B. eine Datenbankverbindung, die von jedem Client verwendet
werden kann. Stateless-Session-Beans führen generische Services aus, die keine Clientstatusdaten aus vorherigen
Methodenaufrufen verwenden, sondern alle relevanten Eingabedaten als Parameter im aktuellen Methodenaufruf empfangen
oder die Daten während des Methodenaufrufs aus anderen Quellen (z. B. aus Entity-Beans oder durch Zugriff auf eine
Datenbank über JDBC) abrufen. Stateless-Session-Beans werden normalerweise aus einem bereitstehenden Pool abgerufen und
bei Bedarf aus diesem Pool zugeteilt, um ankommende Anforderungen zu verarbeiten. Weil alle Instanzen äquivalent sind,
benötigen die Stateless-Session-Beans keine Angaben zu ihrem Client. Dies kann eine bessere Leistung und Skalierbarkeit
zur Folge haben. Stateless-Session-Beans sind effizienter, weil eine Instanz von mehreren nicht zusammenhängenden
Anforderungen verwendet werden kann und nicht an eine bestimmte Sitzung gebunden ist.
Sie sollten in der Regel so vorgehen, dass Sie die Art Session-Bean auswählen, die für den Dialog mit dem Client am
besten geeignet ist. Es gibt Strategien, mit deren Hilfe die Umwandlung einer Stateful-Session-Bean in eine
Stateless-Session-Bean erzwungen werden kann, beispielsweise indem der Clientstatus auf dem Client gespeichert und bei
jedem Aufruf erneut gesendet wird, oder indem der Clientstatus in einer Datenbank gespeichert und bei jedem
Methodenaufruf abgerufen wird. Aufgrund des Aufwands beim Datenaustausch über das Netz und Datenzugriff können diese
Strategien allerdings die Skalierbarkeit verringern.
Wird die Session-Bean zum Implementieren eines Web-Service erstellt, dann müssen Sie eine Stateless-Session-Bean gemäß
der Definition in der JSR 1.3 API-Spezifikation verwenden.
Andere Vorgehensweisen für das Design des Clientstatus finden Sie unter Richtlinie: Design des Status für J2EE-Anwendungen.
Muster einer Sitzungsfassade
Häufig werden Session-Beans als Fassade verwendet, die die Interaktionen zwischen Objekten in der Geschäftsschicht
kapselt. Eine Session-Bean kann von dieser Komplexität ablenken, indem Sie den Clients eine einfachere Schnittstelle
präsentiert. Dieses Muster wird detailliert unter "J2EE Patterns - Session Facade Pattern" ([ALU01]) erläutert.
Ein bewährtes Verfahren ist beispielsweise, die Logik zwischen Entity-Beans zu extrahieren und in Session-Beans zu
verschieben, um die Verkopplung zwischen Entity-Beans zu minimieren. Der Zugriff auf die Entity-Beans kann über lokale
Schnittstellen erfolgen, während die Session-Bean-Fassade den Zugriff auf ferne Clients ermöglicht. Diese
Vorgehensweise ist besonders effektiv, wenn mehrere eng zusammengehörige Entity-Beans existieren.
Web-Services-Endpunkt
Wie bereits erläutert, können Stateless-Session-Beans zum Implementieren von Web-Services verwendet werden. Diese Beans
werden auch als Serviceimplementierungs-Beans bezeichnet. Sie müssen folgende Voraussetzungen erfüllen:
-
Sie müssen einen allgemein zugänglichen Standardkonstruktor besitzen.
-
Sie müssen alle Methoden implementieren, die von der Serviceendpunktschnittstelle deklariert werden, und ihre Geschäftsmethoden
müssen allgemein zugänglich und weder final noch statisch sein.
-
Sie müssen statusunabhängig sein.
-
Die Klasse muss allgemein zugänglich, aber weder final noch abstrakt sein.
Nähere Informationen zur Verwendung von Session-Beans finden Sie in den Spezifikationen EJB 2.1 und JSR 109.
|