Session Bean Stateless in EJB 3.0

I Session Bean Stateless vengono utilizzati in tutte le circostanze in cui non è necessario tener conto dello stato della conversazione: il client invia cioè una richiesta all'application server e quest'ultimo reindirizza la richiesta al Session Bean Stateless che risponde.

Per questa ragione i Session Bean Stateless vengono impiegati per fornire servizi secondo un paradigma che prevede un solo scambio richiesta-risposta (non sono previsti quindi scambi richiesta-risposta multipli come accade invece nel caso dei session bean stateful).
Dal momento che non occorre tener conto dello stato della conversazione, uno stesso Stateless Session Bean può essere impiegato per servire richieste provenienti da client differenti.

Per tale ragione al fine di ottimizzare la gestione delle risorse e la concorrenza fra le richieste, i bean di tipo stateless vengono organizzati in pool così che un'eventuale richiesta proveniente da un client possa essere “servita” dal primo bean disponibile nel pool (solo nel caso in cui non ci siano bean disponibili la richiesta del client viene accodata alle altre in attesa che un bean si liberi).

Il fatto che un bean di tipo stateless possa servire una sola richiesta per volta non vuol dire che esso debba necessariamente contenere un solo metodo, uno stesso bean può esporre servizi differenti attraverso metodi differenti (ad esempio un metodo che codifica una messaggio e un altro che lo decodifica).

Creazione di un Session Bean Stateless in EJB 3.0

La creazione di un Session Bean Stateless, secondo le specifiche EJB 3.0, prevede:

• la definizione di un'interfaccia business
• l'implementazione dell'interfaccia attraverso un POJO (Plain Old Java Object)

L'interfaccia contiene la definizione dei metodi esposti dall'EJB e può essere di tre tipi:

• Local: quando l'EJB è accessibile localmente (all'interno dell'EJB container o del WEB container)
• Remote: quando l'EJB può essere invocato tramite RMI (Remote Method Invocation)
• Web Service: quando si vogliono rendere accessibili i metodi dell'EJB tramite web-service.

Nel primo caso l'interfaccia va annotata con @Local, nel secondo con @Remote, nel terzo con @WebService.

Supponendo ad esempio di voler definire un EJB Stateless che calcoli l'MD5 di un array di byte, l'interfaccia di tale EJB potrebbe essere costituita da un solo metodo:

package webpackage;
import javax.ejb.Local;
@Local
public interface MD5LocalInterface {
	public byte[] calcolaMD5(byte[] contenuto);
}

L'implementazione dell'interfaccia è costituita da un semplice POJO e deve tener conto di poche semplici regole:

• va annotata con @Stateless (indicando opzionalmente un attributo name)
• i metodi che l'EJB container dovrebbe invocare dopo la costruzione e prima della distruzione dell'EJB devono essere annotati con @PostConstruct e @PreDestroy

Inoltre dal momento che quando si utilizza un Session Bean Stateless non si vuole mantenere uno stato della conversazione client/server, non è possibile utilizzare l'annotazione @Remove per annotare il metodo che chiude la conversazione.

A differenza degli EJB Stateful, gli EJB Stateless non prevedono un meccanismo di passivazione/attivazione per cui non è possibile far uso delle annotazioni @PrePassivate e @PostActivate.

Ecco una possibile implementazione dell'interfaccia definita in precedenza:

package webpackage;
import javax.ejb.Stateless;
@Stateless (name=”MD5Stateless”)
public class MD5Local implements MD5LocalInterface {
  public byte[] calcolaMD5(byte[] contenuto) {
	MessageDigest md = MessageDigest.getInstance(“MD5”);
	return md.digest(contenuto);
  }
  @PostConstruct
  public void inizializza() {
	//... alloca eventuali risorse necessarie all'EJB
  }
  @PreDestroy
  public void distruggi() {
	//... dealloca risorse allocate
  }
}

Configurazione mediante deployment descriptor (ejb-jar.xml)

Alternativamente all'utilizzo delle annotazioni è possibile configurare gli EJB Stateless attraverso il deployment descriptor ejb-jar.xml, così come visto per gli EJB Stateful anche se con qualche opzione in meno.

Ricordiamo che il deployment descriptor consente di realizzare una completa separazione fra codice e configurazione e il suo utilizzo non è necessariamente alternativo all'utilizzo delle annotation: è buona norma infatti definire la configurazione di base nel file ejb-jar.xml ed eventualmente sovrascrivere le opzioni di configurazione mediante annotation.

All'interno del deployment descriptor tutti gli ejb vanno definiti all'interno dell'elemento <enterprise-beans>.

I Session Bean Stateless utilizzati dall'applicazione vanno quindi definiti all'interno di tale elemento mediante degli elementi <session> i cui sotto-elementi principali sono:

• ejb-name: il nome dell'EJB
• remote: l'interfaccia remota per l'EJB
• local: l'interfaccia locale per l'EJB
• ejb-class: il nome della classe che implementa il bean
• session-type: il tipo di session bean (nel nostro caso stateless)

La configurazione dei metodi che gestiscono le operazioni di costruzione/distruzione avviene attraverso gli elementi: <post-construct>, <pre-destroy> ciascuno dei quali deve indicare:

• lifecycle-callback-class: la classe che contiene la definizione del metodo di callback
• lifecycle-callback-method: il nome del metodo che implementa la gestione dell'operazione corrispondente.

Non essendo disponibile per gli EJB Stateless il meccanismo di passivazione/attivazione, non è possibile fare uso dei tag <pre-passivate> e <post-activate> così come non è possibile utilizzare il tag <remove> per indicare la fine della conversazione client/server e la rimozione del bean (ricordiamo che non esiste una conversazione con stato client/server ma un semplice paradigma richiesta/risposta).

Il deployment descriptor ejb-jar.xml per il bean MD5Stateless potrebbe essere il seguente:

<enterprise-beans>
...
<session>
	<ejb-name>MD5Stateless</ejb-name>
	<local>MD5LocalInterface</local>
	<ejb-class>MD5Local</ejb-class>
	<session-type>Stateless</session-type>
	...
		<post-construct>
			<lifecycle-callback-class>webpackage.MD5Local</lifecycle-callback-class>
			<lifecycle-callback-method>inizializza</lifecycle-callback-method>
		</post-construct>
		<pre-destroy>
			<lifecycle-callback-class>webpackage.MD5Local</lifecycle-callback-class>
			<lifecycle-callback-method>distruggi</lifecycle-callback-method>
		</pre-destroy>
	...
	</session>
...
</enterprise-beans>

Utilizzo di un Session Bean Stateless e Dependency Injection (DI)

L'utilizzo di un EJB Stateless all'interno di un componente deployato all'interno del web container (servlet o backing bean), o dell'ejb container (altro EJB) può avvenire mediante dependency injection: attraverso la dependency injection l'application server provvede ad inizializzare le risorse di cui un componente ha bisogno per svolgere il suo lavoro.
Per raggiungere tale proposito si fa uso (nel caso di un contesto locale) dell'annotation @EJB, la quale può definire opzionalmente i seguenti attributi:

• name: il nome attraverso il quale viene fatto il look up dell'EJB nell'ambiente
• beanInterface: il tipo di interfaccia implementata dall'EJB referenziato
• beanName: il nome indicato come attributo name dell'annotation @Stateless
• mappedName: specifica il jndi name globale dell'EJB referenziato.
• description: una descrizione dell'EJB referenziato

Supponendo di far uso di Java Server Faces (JSF) nel View Layer, il nostro Session Bean Stateless verrà da un backing-bean così definito:

package webpackage;
import webpackage.MD5LocalInterface;
public class JSFBean {
  private static final long serialVersionUID = 1L;
  ...
  @EJB (beanName=”MD5Stateless”)
  private MD5LocalInterfate md5Local;
  public byte[] codifica(byte[] messaggio) {
	return md5Local.calcolaMD5(messaggio);
  }
}