Entity Bean

Introduzione lezione 12

Sorgente di questa pagina viene da html.it. Delle pagine della guida su j2ee. Il link comincia dalla lezione 12 della guida continuando fino alla 20.

Possiamo dire che un entity bean rappresenta la riga di una tabella in un particolare istante temporale.

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.

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.

  1. Gli entity Bean Managed Persistence (in seguito BMP)
  2. Gli entity Container Managed Persistence (in seguito CMP).

La differenza è il modo di gestire la persistenza:

  1. BPM lo sviluppatore deve gestire le operazioni previste cancellazione, inserimento, modifica.
  2. CMP lo sviluppatore guida il tool di sviluppo in modo che gestisca lui tale logica, compiendo delle operazioni di associazione object-relazionale. In questo modo si scrive meno codice e si è meno soggetti ad errori.

Architettura del componente lezione 13

Come per i session bean, anche gli entity hanno una particolare gerarchia da seguire:

  1. un interfaccia remota e/o locale
  2. una home remota e/o locale
  3. la classe bean
  4. uno o più descrittori di deployment
  5. una classe primary key che identifichi univocamente le istanze del bean

Estensioni:

  1. interfacce, la remota estende javax.ejb.EJBObject, quella locale javax.ejb.EJBLocalObject
  2. home dovranno estendere; javax.ejb.EJBHome (remota) e javax.EJBLocalHome (locale)
  3. il bean vero e proprio deve estendere l'interfaccia javax.ejb.EntityBean. Che è definita nel seguente modo.
package javax.ejb;
 
import java.rmi.RemoteException;
 
public interface EntityBean extends EnterpriseBean {
  public void setEntityContext(EntityContext ctx) throws EJBException, RemoteException;
  public void unsetEntityContext() throws EJBException, RemoteException;
  public void ejbRemove() throws RemoveException, EJBException, RemoteException;
  public void ejbActivate() throws EJBException, RemoteException;
  public void ejbPassivate() throws EJBException, RemoteException;
  public void ejbLoad() throws EJBException, RemoteException;
  public void ejbStore() throws EJBException, RemoteException;
}

I metodi visti sopra sono di callback cioè vengono chiamati dal container.
I metodi activate a passivate servono per operazioni di swapping , load e store per la sincronizzazione hanno codice sql se usano un db. Il metodo remove serve per eliminare l'istanza dallo strato di persistenza. I metodi set e unset vengono richiamati al momento della creazione dell'istanza in modo che il componente possa richiamare (tramite la classe Context) i servizi dell'AS.
Quando si crea una classe viene anche creata una nuova istanza sullo strato di persistenza , perchè gli entity bean vengono gestiti con il meccanismo del polling.
Per recuperare una particolare istanza di bean bisognerà creare dei metodi finder, che si occuperanno di ricercare le istanze (sul database) e restituire le chiavi associate a quelle istanze. I metodi finder si trovano sulle interfacce home (sia remote che locali) ed hanno come tipo di ritorno una classe chiave dell'oggetto (in basso i dettagli sulla classe primary key) oppure una Collection di primary key (se il risultato di ricerca non è univoco).
Ogni interfaccia home deve avere almeno un metodo finder (findByPrimaryKey()) che definisce la logica per il recupero di un istanza sulla base della primary key passata in riferimento. Ad ogni metodo finder sarà associato sul bean di logica il corrispettivo metodo ejbFind.
E' presente una classe che definisce la chiave primaria, questa racchiuderà quei valori che sono chiave. Può essere quindi un solo valore numeri o più variabili, l'importanza è che tali classi estendano l'interfaccia Serializable e che abbiano i metodi equals(). Per rendere possibile il polling dei componenti l'identità che identifica la chiave deve rimanere esterna al componente stesso e recuperata al bisogno.

Salvo diversa indicazione, il contenuto di questa pagina è sotto licenza Creative Commons Attribution-ShareAlike 3.0 License