CERCA SITEMAP FEED RSS 1280
Ultimo aggiornamento: 30 Agosto 2009

Introduzione a Enterprise JavaBeans (EJB)

L’architettura predominante nello sviluppo di applicazioni server-side è quella a livelli, in tale architettura i componenti sono raggruppati in livelli separati, ciascuno dei quali svolge un compito ben definito:
  • presentation layer: è responsabile della visualizzazione della Graphical User Interface (GUI) e della gestione dell’input utente (passando le richieste al business logic layer)
  • business logic layer: contiene tutta la logica dell’applicazione ovvero i processi che l’applicazione può eseguire, recupera e salva dati interagendo con il persistence layer
  • persistence layer: fornisce un’astrazione ad alto livello e object-oriented del database layer
  • database layer: consiste di un relational database management system.

Enterprise JavaBeans(EJB)

Enterprise JavaBeans è una piattaforma per la creazione di applicazioni business portabili, riusabili e scalabili mediante il linguaggio java.
Un’applicazione è costituita da componenti che vivono all’interno di un EJB container che fornisce a tali componenti un certo numero di servizi quali la gestione della sicurezza, delle transazioni, i supporto per i web-services…
I componenti EJB sono simili a un qualsiasi altro POJO (Plain Old Java Object) e sono suddivisi in tre tipi: session bean, message-driven bean e entity bean.
I primi due sono utilizzati per implementare la logica di business mentre gli entity bean sono utilizzati per la persistenza.
In particolare, un session bean viene invocato da un client allo scopo di effettuare una specifica elaborazione: il termine "session" fa riferimento al fatto che l’istanza di un bean di questo tipo non sopravvive a crash o shutdown del server.
Esistono due tipi di session bean:
  • stateful: sono quei bean il cui stato viene salvato fra una richiesta e l’altra del client
  • stateless: sono quei bean che non mantengono alcun stato e vengono utilizzati per modellare quelle elaborazioni che si completano con una sola richiesta
I session bean possono essere invocati o localmente o da remoto mediante Java RMI.
Container EJB I Message-driven Bean si differenziano dai session bean per il fatto che non vengono mai invocati direttamente dai client.
Piuttosto i MDB sono attivati da messaggi inviati a un messaging server.
Infine gli entity bean sono oggetti java che costituiscono la rappresentazione dei dati dell’applicazione e che vengono memorizzati in maniera persistente in un database.
In EJB 3 al persistenza è gestita da Java Persistence API mediante object-relational mapping (ORM): questo termine essenzialmente denota il processo di mapping dei dati fra gli oggetti e le tabelle di un database.
Mentre l’esecuzione di un session bean o di un message-driven bean richiede un EJB container, per assicurare la persistenza degli entity bean è necessario ricorrere ad un persistence provider.
Un persistence provider è essenzialmente un framework ORM (come Hibernate o TopLink) che supporta le Java Persistence API.
Dal momento che un EJB container offre ai componenti EJB dei servizi, deve essere possibile configurare l’accesso a tali servizi, ciò può essere fatto in due modi:
  • mediante annotazioni
  • mediante file di configurazione XML (Deployment Descriptor)

Annotazioni

Le annotazioni sono particolari tipi di interfacce che consentono di aggiungere informazioni addizionali, dette attributi, a classi, interfacce, metodi e variabili.
Queste informazioni possono essere utilizzate da un ambiente di sviluppo, dal compilatore java, da un tool di deployment da un persistence provider o altro ancora.
Ad esempio si potrebbe definire un’annotazione autore e poi usarla per indicare l’autore di una classe come nel seguente metodo:
  @Autore("Giuseppe Sicari")
  public class MiaClasse implements MiaInterfaccia
Nonostante gli indubbi vantaggi che derivano dall’utilizzo delle annotazioni, esistono anche degli svantaggi.
Basti pensare ad esempio che ogni cambiamento della configurazione dell’applicazione comporta delle modifiche al codice sorgente delle stessa.
EJB 3 risolve questo problema sovrascrivendo le annotazioni con le informazioni contenute nel deployment descriptor.

Deployment Descriptor

Un deployment descriptor è un file XML che contiene le informazioni di configurazione dell’applicazione: in EJB 3 il deployment descriptor è opzionale (grazie all’uso delle annotazioni) ma costituisce un buon meccanismo per separare il codice dalla configurazione.
E’ buona abitudine ricorrere alle annotazioni per definire le caratteristiche di configurazione generali e al deployment descriptor per sovrascrivere quelle informazioni che sono specifiche dell’ambiente nel quale l’applicazione viene eseguita.
Se ad esempio si volesse sovrascrivere nel Deployment Descriptor l’annotazione @Autore precedentemente usata si potrebbe aggiungere l’elemento:
  <Autore>Nuovo autore</Autore>
EJB definisce il proprio insieme di annotazioni standard, alcune di queste costituiscono le cosiddette common metadata annotation al centro delle quali ci stanno le cosiddette annotazioni di dependency injection come @Resource, @EJB ed altre ancora.

Servizi offerti

Alcuni dei principali servizi offerti da un EJB 3 container sono:
  • messaging: consente lo scambio di messaggi fra componenti nell’ottica di una comunicazione asincrona senza conoscere i dettagli implementativi di Java Messaging API
  • transazioni: consente di trasformare facilmente i metodi di un componente in metodi transazionali i cui cambiamenti hanno effetto solo se si concludono positivamente (altrimenti si effettua il roll back).
  • sicurezza: mediante Java Authentication and Authorization Service (JAAS) è possibile proteggere le risorse dell’applicazione senza modificare il codice ma con semplici opzioni di configurazione.
  • accesso remoto: è possibile accedere ad un EJB da remoto senza scrivere alcun codice.
  • web services: è possibile esporre i metodi di un EJB all’esterno come web services.
  • persistenza: mediante Java Persistence API è possibile rendere persistenti le entità sincronizzandone i cambiamenti con un database mediante object relational mapping (ORM).

Java Persistence API

Le Java Persistence API non sono rivolte esclusivamente ad applicazioni server-side.
Il problema della persistenza caratterizza infatti anche le applicazioni desktop Swing-based.
Per tale ragione, le Java Persistence API sono state separate dal container EJB 3 per fornire una soluzione di persistenza general-purpose per qualsiasi tipo di applicazione java.
Dal momento che JPA standardizza i framework ORM per la piattaforma java, è possibile utilizzare come persistence provider prodotti come Hibernate o TopLink

Java Persistence API consente di:
  • configurare il mapping ORM mediante annotazioni o attraverso deployment descriptor
  • effettuare operazioni CRUD (Create, Read, Update, Delete) sulle entità
  • cercare e recuperare entità persistenti mediante JPQL (Java Persistence Query Language)

Dependency Injection

La maggior parte dei componenti utilizza altri componenti o risorse per implementare le proprie funzionalità.
In EJB 3, le operazioni di lookup JNDI sono state affiancate in una forma più semplice basata su metadati che prende il nome di dependency injection.
L’obiettivo primario della dependency injection è quello di rendere l’interdipendenza fra componenti più disaccoppiata possibile, consentendo ad un componente di poter referenziare un altro componente o una risorsa attraverso un interfaccia.
Attraverso la dependency injection il conteiner EJB legge le informazioni di configurazione dal bean che necessita della risorsa e ne effettua il collegamento a runtime.
Se ad esempio si vuole accedere ad un EJB si può usare l’annotazione @EJB per effettuarne l’injection in una variabile dello stesso tipo:
  ...

  @EJB
  private ClassBean miobean;

  ...