Session bean

I session bean costituiscono la parte più importante delle specifiche EJB perché incorporano la logica di business e, utilizzando dati e risorse, implementano le funzionalità offerte dall’applicazione.
I session bean sono gli unici EJB che possono essere invocati direttamente dai client (web component, applicationi desktop…): ogni richiesta effettuata da parte di un client va inquadrata all’interno di una sessione.
Le applicazioni server-side devono essere in grado di poter servire un grande numero di richieste nello stesso tempo e dal momento che i session bean sono nati per gestire tali richieste, essi devono supportare un alto grado di concorrenza.
Il container EJB fornisce diverse tecniche per raggiungere tale scopo senza richiedere alcun intervento da parte dello sviluppatore.
Oltre all’accesso locale i session bean supportano l’accesso mediante Java Remote Method Invocation o SOAP: a parte alcune piccole modifiche in fase di configurazione, non è richiesto alcun lavoro aggiuntivo per rendere accessibile da remoto la logica di business che i session bean implementano.

Implementazione di un session bean

Ogni implementazione di un session bean consta di due distinte parti: una o più interfacce e una classe che implementa tali interfacce.
Il vantaggio di della programmazione basata su interfacce è rappresentato dal fatto che è possibile modificare l’implementazione dell’interfaccia senza dover modificare il modo in cui i client accedono alla stessa.
L’interfaccia attraverso la quale un client invoca un EJB è detta business interface.
Questa definisce essenzialmente i metodi dei bean accessibili secondo una determinata modalità (locale, remoto, web-service).

Ad esempio il codice:

  
  public interface MiaIntSLSBLocal 
  {
    String data();
  }

definisce un’interfaccia POJI (Plain Old Java Interface) locale (annotazione ) che espone il metodo data().
Un’interfaccia business come detto può anche essere resa accessibile da remoto mediante RMI o Web services .

Come tutti gli EJB 3 i session beans sono POJO e seguono un piccolo insieme di regole:

• devono avere almeno un’interfaccia business
• devono costituire delle implementazioni concrete dell’interfaccia
• devono avere un costruttore senza argomenti (perché questo viene invocato dal container quando viene creata un’istanza del bean richiesto dal client)

Un session bean può essere una sottoclasse di un altro session bean o un altro POJO

    public NuovoBean extends VecchioBean implements InterfacciaBean 
  {
    ...
  }

In ogni caso i metodi business devono essere definiti o nel bean o nella superclasse dalla quale deriva, devono essere metodi pubblici e i loro nomi non devono iniziare con “ejb”.
Inoltre nel caso di interfacce remote gli argomenti ed il tipo restituito devono essere oggetti che implementano l’interfaccia java.io.Serializable.

Classificazione dei session bean

Un determinato processo business potrebbe invocare più di un metodo di un session bean e richiedere che il bean mantenga lo stato della comunicazione fra una richiesta e l’altra.
Un session bean di tipo stateful mantiene lo stato della comunicazione ed ha memoria di tutti gli scambi precedenti pertanto può essere utilizzato per implementare processi multi-step.
Di contro i session bean di tipo stateless non mantengono alcuno stato e sono tipicamente utilizzati per modellare servizi di utilità che si concludono in una sola richiesta.

Ciclo di vita di un session bean

Un session bean ha un ciclo di vita, ovvero passa attraverso un insieme di fasi predefinite: le due più ovvie sono la fase di creazione e quella di distruzione.
I session bean di tipo stateful hanno due ulteriori fasi note come passivazione e attivazione.
Dal momento che i session bean stateful devono mantenere uno stato, il container può decidere di disattivarli (passivazione) quando non sono usati per molto tempo e riattivarli (attivazione) quando invece vengono invocati.

Il ciclo di vita di un session bean inizia con la creazione dell’istanza e consta dei seguenti passi:

• il container invoca il metodo newInstance sull’oggetto bean
• se il bean usa Dependency Injection allora tutte le dipendenze su risorse e altri bean sono injected nella nuova istanza creata
• se il container stabilisce che una data istanza non è più necessaria la distrugge.

E’ possibile fare in modo che venga invocato un metodo quando il session bean passa da una fase alla successiva del suo ciclo di vita.
Per fare ciò è possibile annotare con , , e i metodi che il container EJB deve invocare dopo ogni transizione di stato.
In parlicolare i metodi marcati con le annotazioni e sono invocati rispettivamente alla creazione e alla distruzione del session bean e possono essere utilizzati sia per session bean di tipo stateless che per session bean di tipo stateful.
Le annotazioni e invece vengono utilizzate per denotare i metodi che devono essere invocati dal container prima della passivazione e dopo l’attivazione di session bean di tipo stateful.
I metodi annotati con , , e non devono essere esposti nell’interfaccia di business del session bean.
Tipicamente i metodi annotati con e sono usati per allocare risorse mentre i metodi annotati con e sono usati per rilasciare le risorse allocate.