Business Tier esempio

Il Business Tier contiene la logica applicativa dell’ambiente Java Enterprise. La logica di Java EE è organizzata per interazione fra componenti, gli Enterpirsie Java Bean. Un EJB è una classe java che, una volta programmata, viene “pubblicata” su un Application Server e da questo sarà gestita. I client di un EJB possono essere altri EJB, classi java, applet e sistemi esterni.

La logica degli EJB e di Java EE in sè è quella di disaccoppiare Business Tier e Web Tier lasciando all’Application Server (in particolare all’EJB Container) il compito di gestire la comunicazione fra i due livelli. Esistono tre tipi di EJB: Session Bean, Entity Bean e Message-Driven Bean.

I Session Bean (Statefull e Stateless) sono EJB dedicati alle operazioni logiche, come eseguire ricerche, confrontare valori, aggiornare dati. Queste operazioni sono accissibili all’esterno mediante Java RMI.

Gli Entity Bean sono EJB dedicati alla rappresentazione dei dati dell’applicazione che vengono memorizzati in maniera persistente in un database, nel nostro caso MySql. La persistenza è realizzata mediante object-relational mapping (ORM) definito dalla JPA (Java Persistence API), e il persistence provaider di JBoss è Hibernate.

I Message-Driven Bean sono EJB dedicati allo sviluppo di applicazioni asincrone e non sono pertanto stati utilizzati per lo sviluppo di RubricaWeb.

L’accesso ai servizi offerti dall’EJB container può avvenire in due modi:

  • Mediante annotazioni nel codice delle classi;
  • Mediante file di configurazione XML (Deployment Descriptor).

  Session Bean

I due session bean (GestoreUtentiBean e GestoreContattiBean) utilizzati in RubricaWeb sono di tipo stateless. Vediamo il codice di GestoreUtentiBean.java:

L’annotazione @Stateless definisce uno stateless session bean. L’annotazione @Clustered permette di comunicare a JBoss di clusterizzare l’applicazione se sono presenti altri nodi.

Tramite le annotazioni @Remote e @WebService si comunica all’EJB container che le applicazioni client del Business Tier possono accedere tramite RMI (sfruttando l’interfaccia remota GestoreUtenti.class) e WebService.

Con la notazione @PersistenceContext(unitName = “Rubrica”) si comunica all’oggetto EntityManger (che si occupa di eseguire l’object-relational mapping) su quale raggruppamento di entità stiamo lavorando. Nel nostro caso GestoreUtentiBean e GestoreContattiBean lavorano con la unit rubrica, che contiene oggetti di tipo Utente e Contatto e i riferimenti alle rispettive tabelle del database.

Il metodo cercaPerNomeUtente(String nomeUtente) mostra come funziona la JPA: viene richiamata la namedQuery definita dalla annotazione @NamedQuery nell’entity bean Utente per ottenere un oggetto di tipo Query. Quest’oggetto viene utilizzato dal session bean per effettuare un’interrogazione sul database. Non è però il session bean che interviene direttamente sulle tabelle del database, ma il persistence provider Hibernate tramite gli entity bean.

Questo è un aspetto estremamente importante: tramite la separazione tra Business Tier e EIS e la JPA la sicurezza delle Web Application è notevolmente migliorata.

  Entity Bean

I due Entity Bean sono invece Contatto.java e Utente.java. Ecco la struttura di Utente.java:

L’annotazione @NamedQueries permette di specificare le NamedQueries inserendo il codice di interrogazione (il linguaggio di interrogazione utilizzato è EJBQL) per il database. @Id Permette di definire la chiave primaria della tabella nel database. Come giá detto, l’archivio nel jar contenete gli EJB deve contenere il file persistence.xml. Eccone il contenuto:

In questo file è possibile selezionare il già discusso datasource da utilizzare e definire il nome della persistence unit utilizzata dagli entity bean.

Leave a Comment

Your email address will not be published.

*