Questo mese il corso affronta gli Entity Bean di tipo container managed, analizzando nel dettaglio i vari aspetti legati alla gestione della persistenza ed al ciclo di vita.

Introduzione

Un entity bean è un particolare tipo di EJB il cui scopo è rappresentare un oggetto, un elemento o un soggetto sul server. Per sua natura questo genere di componente è delegato a memorizzare informazioni e a offrire una serie di metodi per la gestione remota da parte del client.

In questa ottica è possibile suddividere le funzionalità di un bean in due categorie:

• tutto ciò che è relativo alla sua manipolazione da remoto direttamente tramite il client, cioè la business logic
• tutto ciò che è relativo alla gestione del ciclo di vita del componente, del suo mantenimento dello stato e della gestione della sicurezza

Uno degli aspetti più importanti degli entity bean è il modo in cui implementano la persistenza dei dati all'interno del database.

Le possibilità sono due:

• l'intero processo di sincronizzazione viene gestito dal container in modo trasparente, container managed persistence
• tutte le informazioni sono salvate su disco direttamente tramite operazioni effettuate dal bean, bean managed

L'articolo si sofferma sul primo caso, rimandando il secondo alla puntata successiva.

Container Managed Persistence

Nel caso container managed il server si preoccupa in modo del tutto trasparente di allineare le informazioni contenute nel bean al variare dello stato e soprattutto in funzione dello stato assunto all'interno del ciclo di vita del componente.

Il database di appoggio può essere relazionale o a oggetti.

Tranne che per le variabili definite transient, tutti gli oggetti serializzabili o le variabili primitive possono essere salvati. Nella maggior parte dei casi si tende però ad utilizzare variabili primitive a causa del loro più semplice adattamento alla struttura relazionale del database.

La specifica EJB 1.1 permette di rendere persistenti anche campi di un bean che contengano riferimenti ad altri bean: in questo caso il costruttore del server deve implementare tecniche piuttosto complesse per effettuare un mapping il più sensato possibile.

Normalmente questo si traduce nella memorizzazione della chiave primaria, Primary Key, degli oggetti Handle o HomeHandle, o di altri riferimenti che identifichino univocamente il bean contenuto.

La gestione della persistenza a carico del container semplifica molto il lavoro di implementazione del bean, ma complica non poco la fase di progettazione del server, perché in questo caso le tecniche di persistenza devono essere il più possibile generiche e automatiche.

Identificazione di un bean: la Primary Key

Quando un client effettua una operazione di lookup su un oggetto remoto, si deve poterlo identificare in maniera univoca fra tutti quelli messi a disposizione dal server.

Per questo motivo ad ogni bean è associata una chiave detta Primary Key, che può essere costituita da una classe apposita oppure identificata da un campo del bean stesso.

Nel primo caso la classe segue uno schema del tipo NomeBeanPK e contiene al suo interno tutte le informazioni necessarie per individuare il bean. L'articolo mostra un esempio simile al seguente:

public void MyBeanPK{
    public int beanId;
    public MyBeanPK(){}
    public MyBeanPK(int id){
    beanId=id;

    public boolean equals(Object obj){
        if (obj == null || !(obj instanceof MyBeanPK))
            return false;

Conclusioni

Questa parte del corso mette a fuoco uno dei punti centrali del modello EJB: la separazione tra la logica del componente e la gestione della sua persistenza.

Nel modello container managed il vantaggio per lo sviluppatore è evidente, perché il container solleva il bean da gran parte del lavoro infrastrutturale. Il prezzo di questa comodità sta nella maggiore complessità del server e nella necessità di definire con chiarezza chiavi, mapping e ciclo di vita del componente.