Bean Managed Persistence Entity Bean

In questa lezione vedremo, con un esempio pratico, come realizzare un Entity BMP. Immaginiamo un contesto che ci è familiare e che potremo riutilizzare in futuro per delle applicazioni sempre più complesse: la gestione di conti correnti bancari.

Come si può immaginare la gestione della persistenza in situazioni analoghe è di fondamentale importanza, in quanto, dati così sensibili devono sopravvivere a tutte le evenienze (crash del sistema, interruzioni di servizio, ecc). Gli application server, come abbiamo visto, ci garantiscono l'affidabilità. Per le operazioni di persistenza faremo uso degli EBMP.

Per questo primo esempio vedremo un componente che esporta due semplici operazioni di logica, deposito e prelievo. Vediamo la rappresentazione dei dati sul database.

Come vediamo si tratta di una semplice tabella in cui vengono mantenute le informazioni sul nome utente e, chiaramente, sul saldo del conto corrente bancario. La chiave è un identificativo alfanumerico.

Per prima cosa creiamo l'interfaccia remota (e quindi anche locale) del componente (BankAccount.java e BankAccountLocal.java).

Accanto alle due operazioni di logica (deposito e prelievo) aggiungiamo le operazioni get e set di base, che ci servono per interrogare i singoli campi del componente. Volontà nostra è di non esporre il metodo setSaldo(), in modo che in nessun modo (se non tramite deposito e prelievo) venga modificato il saldo dell'utente.

Creiamo quindi l'interfacce home remota e locale (BankAccountHome.java e BankAccountLocalHome.java).

Il metodo create si aspetta come input un identificativo ed il nome dell'utente. Ricordiamo come possano essere presenti più metodi create (sulla base delle esigenze di business). Accanto ad essi vediamo il metodo findByPrimaryKey() e getNumeroContiAperti().

Il primo è un metodo finder, che serve per interrogare il database sulla presenza del conto passato come riferimento. Il valore di ritorno sarà un istanza dell'EBMP, e su di esso potranno essere effettuate le operazioni. Avremmo potuto inserire altri metodi finder, ad esempio findBigAccount(), che restituisse una collezione di EBMP con saldo maggiore di un certo valore.

Interessante è la presenza del metodo getNumeroContiAperti(), nel senso che non avevamo ancora parlato della possibile presenza di metodi di logica nelle interfacce home. Finora avevamo detto che esse erano pensate solo ed esclusivamente per le operazioni di recupero degli EJB. Dalla specifica 2.0 è possibile inserire dei metodi di logica (in questo caso il metodo che recupera il numero di conti sul nostro database). Ad ogni metodo home è associato un relativo metodo sulla classe del bean nominato come ejbHome<>. Nel nostro caso avremo quindi ejbHomeGetNumeroContiAperti(), che farà un'operazione di selezione sul database.

Prima di vedere nel dettaglio la logica applicativa del componente, vediamo la classe primary key (AccountPK.java).

Non c'è molto da sottolineare, se non il fatto che essa deve implementare Serializable (marker interface) e, possibilmente, ridefinire i metodi equals ed hashCode (vengono utilizzati dal container per una migliore gestione). Nel nostro caso la classe presenta semplicemente una variabile String che rappresenta il codice identificativo del conto corrente.

La parte più importante è quella presente nel listato della classe bean BankAccountBean.java.

I commenti presenti illustrano ogni metodo, ma è bene soffermarci su alcuni aspetti del bean.

• Variabili di istanza: rappresentano i campi della tabella. Di fatto contengono le informazioni di cui abbiamo bisogno e a cui accediamo mediante i metodi getter e setter (dove presenti).
• Metodi di business: rappresentano le operazioni a disposizione del componente. In generale vedremo che è preferibile prevedere dei session bean come strato software in cui codificarle, lasciando al componente entity il solo compito di persistenza.
• Metodi getter/setter: rappresentano le informazioni per il client. L'accesso alle informazioni è mediato dalla presenza di questi metodi. Nel caso non vogliamo esporli (come nel caso di setSaldo()), possiamo non inserirli. Di fatto, anche questi sono metodi di business esposti nella remote (o local) interface.
• Metodi finder/ejbHome: sono i metodi per interrogare il database. Qui codifichiamo il modo in cui accedere alle informazioni. Il metodo finder recupera i dati attraverso la query SELECT e restituisce la chiave associata. Il metodo home fa una query recuperando un valore numerico e restituendolo come valore di ritorno.
• Metodi callback: sono i metodi in cui è codificata la logica SQL. Questo è lo strato di persistenza vero e proprio. È qui che ci occupiamo di codificare le operazioni sul database. La ejbCreate prevederà la query di INSERT. La ejbRemove la query di DELETE. La ejbLoad la query di SELECT e la ejbStore la query di UPDATE sulla base della primary key associata al componente.

Dando un'occhiata al container potrete vedere che le operazioni che più si intervallano sono proprio le operazioni di load e store, cioè le operazioni effettuare per mantenere sincronizzazione tra strato di persistenza e logica applicativa.

Ultima cosa che dobbiamo aggiungere è la necessità di utilizzare i driver JDBC e di codificarne la logica per il recupero della connessione. Nel nostro semplice caso abbiamo inserito un metodo che restituisca la connessione al database, getConnection(). È comunque preferibile utilizzare i servizi dell'application server (vedremo come fare in seguito) per settare opportunamente le connessioni alle sorgenti dati. In questo caso, infatti, dobbiamo ricordarci di portare le librerie del driver (ad esempio mysql) sotto le librerie dell'application server.

Ultimo sorgente che vediamo è il descrittore di deploy (ejb-jar.xml)

Come per gli altri bean vediamo che viene utilizzato per associare correttamente le classi all'architettura del componente. Ora non ci rimane che creare un jar ed effettuare il deploy sull'application server: nel prossimo capitolo vediamo il client utilizzato per testare questo componente.