Linea guida: Identificazione di bean di sessione
Questa linea guida descrive come identificare e modellare i bean di sessione relativi ad un applicazione J2EE.
Relazioni
Descrizione principale

Introduzione

Questa linea guida si focalizza sull'identificazione di bean di sessione. Un'ulteriore guida ai bean di sessione viene fornita dalla Linea guida: Bean di sessione. Le informazioni generali sugli EJB si trovano nella Linea guida: EJB (Enterprise JavaBean).

Identificazione di bean di sessione

Le classi di controllo sono spesso buone candidate ai bean di sessione, che hanno lo scopo di fornire una logica di controllo, in particolare quando questa logica di controllo implica una conversazione con un client. Un bean di sessione viene spesso identificato come facade per una serie di oggetti nel livello business (vedere Pattern della facade di sessione qui sotto). Anche a partire da J2EE 1.4, i bean di sessione stateless possono essere utilizzati per implementare servizi Web.

Se si utilizza J2EE 1.3, si gestisce normalmente l'accesso remoto al client attraverso EJB di sessione, che manipolano EJB di entità dello stesso JVM mediante interfacce di componente locali.

Modellazione di bean di sessione

Vedere la Linea guida: Identificazione di EJB (Enterprise JavaBean).

Stateful e Stateless

Esistono due tipi di bean di sessione: stateful e stateless. Definire le responsabilità di un bean di sessione (es. mantenere lo stato del client tra le chiamate) fa parte dell'identificazione.

I bean di sessione stateful contengono informazioni di stato sulla conversazione tra il client e il contenitore EJB. Un'istanza del bean di sessione stateful esiste soltanto per la durata della conversazione del client. I bean di sessione stateful eseguono solitamente servizi utilizzando questi dati relativi al client. I servizi forniti dal bean di sessione stateful possono coordinare le interazioni di altri oggetti business (bean di sessione e di entità). Ad esempio, un carrello che contiene oggetti da acquistare può essere implementato mediante un bean di sessione stateful, che mantiene le informazioni mentre il client interagisce con l'applicazione. Poiché i bean di sessione stateful sono assegnati ad un client specifico, consumano più risorse di sistema di un bean di sessione stateless, ma hanno il vantaggio di mantenere lo stato del client. Il contenitore gestisce queste risorse, tipicamente "passivando" (scrivendo su disco) i bean di sessione stateful e riattivandoli quando occorre.

I bean di sessione stateless non contengono informazioni di stato sulla conversazione di stato tra il client e il contenitore EJB. "Stateless" significa proprio senza stato di conversazione del client. Quindi, un bean di sessione stateless può contenere altri tipi di stato, come una connessione database che ogni client può utilizzare. I bean di sessione stateless eseguono servizi generici che non utilizzano i dati di stato del client da precedenti chiamate al metodo, ma ricevono invece tutti gli input rilevanti, come i parametri dell'attuale chiamata al metodo, od ottengono i dati da altre fonti nel corso della chiamata al metodo (ad esempio da bean di entità o accedendo ad un database tramite JDBC). I bean di sessione stateless sono solitamente estratti da un pool pronto e distribuiti secondo le necessità per gestire le richieste in entrata. Poiché tutte le istanze si equivalgono, i bean di sessione stateless non hanno bisogno di informazioni sul client. Ciò aumenta le prestazioni e la scalabilità. I bean di sessione stateless sono più efficienti, in quanto un'istanza può essere condivisa tra richieste non contigue, anziché "legata" ad una particolare sessione di attività.

In generale, viene scelto il tipo di bean di sessione naturalmente adatto alla conversazione con il client. È possibile utilizzare strategie che consentono di adattare un bean di sessione stateful in un bean di sessione stateless, come la memorizzazione dello stato del client all'interno del client e la rispedizione di ogni chiamata, o la memorizzazione e il recupero dello stato del client da un database per ogni chiamata al metodo. Queste strategie, tuttavia, possono ridurre la scalabilità a causa di un eccessivo traffico di rete e accesso ai dati.

Se il bean di sessione viene creato per implementare un servizio Web, si deve utilizzare un bean di sessione stateless come descritto nella specifica API JSR 1.3.

Diversi approcci alla progettazione dello stato del client sono illustrati dalla Linea guida: Progettazione dello stato per applicazioni J2EE.

Pattern della facade di sessione

Un modo comune di utilizzare i bean di sessione è una facade che contiene le interazioni tra oggetti nel livello di business. Il bean di sessione serve a ricavare questa complessità, fornendo un'interfaccia più semplice per i client. Questo pattern è descritto ampiamente in J2EE Patterns - Session Facade Pattern ([ALU01]).

Ad esempio, in generale è meglio accantonare la logica dei bean inter-entità e preferire piuttosto i bean di sessione, per ridurre al minimo l'accoppiamento tra bean di entità. È possibile accedere ai bean di entità tramite interfacce locali, poiché la facade del bean di sessione fornisce l'accesso a client remoti. Questo approccio è più efficace in presenza di vari bean di entità strettamente legati.

Endpoint dei servizi Web

Come si è visto in precedenza, i bean di sessione stateless possono essere utilizzati per implementare servizi Web. Tali bean vengono anche chiamati bean di implementazione del servizio e devono soddisfare i seguenti requisiti:

  • Avere un costruttore pubblico predefinito.
  • Implementare tutti i metodi elencati dall'Interfaccia endpoint del servizio; i relativi metodi di business devono essere pubblici e non finali o statici.
  • Devono essere stateless.
  • La classe deve essere pubblica, ma né finale né astratta.

Per ulteriori informazioni sull'utilizzo dei bean di sessione per implementare i servizi web, leggere le specifiche EJB 2.1 e JSR 109.