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.
|