In questa e nelle seguenti lezioni affronteremo quella che probabilmente è la parte più importante della guida, gli Entity Beans.
L'importanza risiede nel fatto che tutte le applicazioni (in particolar modo quelle aziendali) fanno un costante uso di dati ed informazioni residenti in forma persistente. Gli Entity Beans consentono la gestione automatizzata di alcuni aspetti relativi all'accesso ed in generale alla gestione dei dati. Anche se la tecnologia astrae la politica di salvataggio (database relazionali, ad oggetti, xml, file system, ecc) noi faremo quasi esclusivamente riferimento alle basi di dati relazionali.
Un modo molto interessante di portare un dato da un database ad un oggetto java è quello di vederne le proprietà come variabili di istanza di tale oggetto. Questa tecnica, nota come mapping object-relazionale, è alla base dello sviluppo di questi componenti, che rappresentano le informazioni persistenti del nostro sistema. Possiamo dire che un entity bean rappresenta la riga di una tabella in un particolare istante temporale. Infatti, l'idea che sta dietro gli entity beans è quella di poter avere a disposizione in maniera veloce l'accesso a dati e a mantenerli persistenti in base alle operazioni di logica che su di essi verranno effettuati.
Ad esempio, un conto corrente bancario potrebbe essere un entity bean. Anche le informazioni di un utente di un sito di e-commerce potrebbe essere un entity bean e conseguentemente le fatture che vengono registrate a seguito dei suoi acquisti.
In ambito di sistemi informativi risulta particolarmente importante avere a disposizione strumenti che consentano una veloce automatizzazione delle procedure di lettura e scrittura. Gli entity bean permettono questo grazie al loro modello di sviluppo.
Vedremo che un entity bean non è altro che un oggetto distribuito le cui variabili di istanza rappresentano le informazioni attualmente presenti nel sistema. La più importante operazione di middleware è quella della sincronizzazione: l'ejb container mantiene sincronizzati i dati con il database in maniera costante. Queste operazioni sono realizzate da due metodi callback, ejbLoad() ed ejbStore() che si occupano della logica di sincronizzazione (in lettura e scrittura). Tali metodi sono richiamati dall'application server, che avrà il compito di mantenere consistenti i dati: non dovremo quindi preoccuparci di gestire la concorrenza per l'accesso ai dati.
Anche le performance traggono un grossissimo vantaggio dall'adozione di questa tecnologia. Il ciclo di vita del componente è molto simile a quello degli stateless session bean. Possiamo infatti vedere l'entity bean come un contenitore di dati (ad esempio il nome del correntista ed il saldo), quindi, utilizzare lo stesso oggetto con l'opportuna modifica dei dati personali, consente a diversi client di riutilizzare l'oggetto, evitando in tal modo le operazioni di creazione e cancellazione (che consumano risorse). Questo permette una strategia di pooling molto simile a quella degli stateless session bean, con l'unica differenza che i dati presenti dovranno essere modificati per ogni nuovo utente che ne farà uso (operazione appannaggio dell'application server).
Come per i session bean, anche degli entity bean ne vedremo due tipi. Gli entity Bean Managed Persistence (in seguito BMP) e gli entity Container Managed Persistence (in seguito CMP).
La differenza sta nel modo in cui la persistenza vera e propria viene gestita. Intendiamo quindi le query SQL nel caso in cui la sorgente dati sia un database.
Nel primo caso dovremo preoccuparci noi di scrivere tale logica. Si tratterà quindi di gestire le operazioni previste per le funzioni dell'applicazione che stiamo scrivendo (inserimento, cancellazione, modifica).
Nel secondo caso noi non dovremo scrivere tale logica, o meglio, noi dovremo guidare dei tool di sviluppo alla creazione automatica di tale logica (con delle semplici operazioni di associazione object-relazionale). Il secondo caso è evidentemente più allettante: scrivere meno codice non è soltanto meno faticoso, la nostra applicazione sarà soggetta a meno errori e i tempi di sviluppo diminuiranno drasticamente indipendentemente dalla complessità del database.
