Come esempio pratico ci occuperemo della gestione di un'anagrafica di utenti. Vogliamo creare un componente che ci dia la possibilità di interrogare il database, di inserire nuove voci.
Il nostro bean ha il compito di gestire la persistenza di informazioni su utenti, quindi: login, nome, cognome, niente di particolarmente complicato. L'anagrafica degli utenti è rappresentata dalla tabella di database di seguito:
Listato 1. Creazione tabella user
CREATE TABLE 'user' (
'login' varchar(16) NOT NULL default '',
'nome' varchar(255) NOT NULL default '',
'cognome' varchar(255) NOT NULL default '',
'email' varchar(255) NOT NULL default '',
'telefono' varchar(255) NOT NULL default '',
PRIMARY KEY ('login')
)
Sviluppare un entity bean CMP vuol dire definire le proprietà del bean (quindi le colonne della tabella) ed i relativi metodi get e set. Il codice sorgente delle interfacce remote e locali ci mostra come siano presenti esclusivamente i metodi get e set, in quanto, in questo esempio, non faremo uso di alcun metodo di logica (è sempre bene prevedere la logica nei session bean).
Vediamo quindi le interfacce, prima quella remota (User.java) e poi quella locale (UserLocal.java).
Per quanto riguarda le interfacce home (remota e locale) non c'è alcuna differenza con gli EBMP, quindi vediamo la presenza di un metodo create (con tutti i parametri) e due metodi finder.
La classe bean, quella in cui è definita la logica vera e propria (UserBean.java), dovrà avere i metodi accessori relativi alle proprietà astratte.
Cerchiamo di capire, con l'aiuto della teoria del capitolo precedente, come funziona il componente. Per prima cosa abbiamo detto che le proprietà devono essere astratte. Questo serve per poter utilizzare tali proprietà nascondendo (è il container che se ne occupa) i meccanismi di persistenza. Vediamo quindi l'assenza di variabili di istanza, e la presenza dei metodi astratti get e set di tutte le proprietà. Altra cosa che notiamo è che l'unico metodo che ha un corpo di logica è il metodo ejbCreate(). In realtà si tratta di settare le proprietà del nuovo utente attraverso i metodi setter.
L'assenza dei metodi finder è giustificata dal fatto che la loro creazione è delegata alla subclass creata dal container al momento del deploy del componente.
Come avviene per tutti gli ejb è bene mantenere il riferimento al contesto, utilizzando una variabile di istanza (settata dal container attraverso setEntityContext()).
Per i metodi ejbActivate() ed ejbPassivate() valgono le regole dei BMP entity bean, mentre load e store non sono di utilità concreta in quanto il meccanismo di sincronizzazione col database è gestito dalla sottoclasse.
Più interessante è comprendere i descrittori di deploy. Quello generico (ejb-jar.xml), oltre alla definizione del componente (identica rispetto agli altri bean), presenta l'abstract persistence schema, cioè, la definizione dei campi persistenti.
Altra cosa interessante è la presenza della query EJB-QL associata al metodo findAll. Come vediamo si tratta di un linguaggio molto simile a SQL, che serve per effettuare delle ricerche (anche complesse) sulle tabelle. L'eventuale presenza di parametri (ricerca sulla base di una chiave di testo, o di un particolare valore numerico) è segnalata dal punto interrogativo nella query e dalla definizione del tipo di parametro nel descrittore <method-params>.
Arrivati a questo punto si deve scendere nel dettaglio implementativo di singole soluzioni, in quanto per poter essere associato ad un database, è necessario definire dei descrittori che sono fortemente container-dependent. Quello che segue è la soluzione per application server JBoss, quindi, la sua validità è esclusiva di questo application server.
Come database abbiamo usato MySQL, quindi è necessario creare una sorgente dati per questo database.
Il descrittore di container (jboss.xml) definisce il nome JNDI dell'interfaccia locale e di quella remota.
Quello che realmente si occupa di effettuare le operazioni di mapping tra il componente e la tabella del database è il descrittore cmp-jdbc (jbosscmp-jdbc.xml).
Innanzitutto, in testa è definita esplicitamente la connessione al datasource (nella quale a sua volta sono definiti i parametri di connessione e il database da utilizzare). Dopodiché è definita l'associazione tra bean (User) e tabella (user), e per ogni proprietà persistente l'associazione tra proprietà e colonna.
Al momento del deploy, il container si occuperà di creare la sottoclasse concreta e di definire il ciclo di vita del bean e le operazioni per il caricamento (get) e salvataggio dei dati (set). La cosa più interessante di tutto questo è che la creazione del componente (e della persistenza) passa per semplici operazioni di definizione: cioè definiamo le proprietà e l'associazione con la sorgente dati dove risiedono.
