Richtlinie: Session-Beans festlegen
Diese Richtlinie beschreibt, wie Session-Beans Beans für eine J2EE-Anwendung festgelegt und modelliert werden.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

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.