Diamo un'occhiata agli EJB

Gli Enterprise JavaBean (EJB) sono i componenti che implementano, lato server, la logica di business all’interno dell’architettura J2EE. Le specifiche per gli EJB definiscono diverse proprietà che questi devono rispettare, tra cui la persistenza, il supporto alle transazioni, la gestione della concorrenza e della sicurezza e l’integrazione con altre tecnologie, come JMS, JNDI, e CORBA.
Gli EJB sono uno strumento molto potente e sono di solito utilizzati in applicazioni distribuite, in cui la necessità di ripartire il carico e le funzionalità, sono di sostanziale importanza.

Un EJB è una classe Java che segue determinate regole imposte dalla specifica che, una volta programmato, viene posto in un application server e da esso verrà gestito secondo le regole definite.

In un contesto Java puro, generalmente, i client di questi oggetti sono le pagine JSP e le servlet, che si poggiano agli EJB per definire il contenuto dinamico da mostrare all’utente (una ricerca, un carrello della spesa, ecc). In realtà, l’idea di questi componenti è nata per permettere a diverse tecnologie di usare lo stesso strato di logica, residente in un contesto distribuito.

Esistono tre tipi di EJB:

• EJB di Entità (Entity EJB): il suo scopo è di inglobare gli oggetti sul lato server che memorizzano i dati. Gli EJB di entità forniscono la caratteristica della persistenza dei dati:
  • Persistenza gestita dal contenitore (CMP): il contenitore si incarica della memorizzazione e del recupero dei dati relativi a un oggetto utilizzando una tabella di una base di dati.
  • Persistenza gestita dal bean (BMP): in questo caso è il bean a occuparsi del salvataggio e recupero dei dati a cui fa riferimento, il salvataggio può avvenire in una base di dati o con qualsiasi altro meccanismo perché è il programmatore che si incarica di realizzare il meccanismo della persistenza dei dati.
• EJB di sessione (Session EJB): gestiscono l’elaborazione delle informazioni sul server. Generalmente sono una interfaccia tra i client e i servizi offerti dai componenti disponibili sul server. Ne esistono di due tipi:
  • con stato (stateful). I bean di sessione con stato sono oggetti distribuiti che posseggono uno stato. Lo stato non è persistente, però l’accesso al bean è limitato ad un unico client.
  • senza stato (stateless). I bean di sessione senza stato sono oggetti distribuiti senza uno stato associato, questa carattestistica permette un accesso concorrente alle funzionalità offerte dal bean. Non è garantito che il contenuto delle variabili di istanza si conservi tra diverse chiamate ai metodi del bean.
• EJB guidati da messaggi (Message driven EJBs): sono gli unici bean con funzionamento asincrono. Tramite il Java Message Service (JMS), si iscrivono a un argomento (topic) o a una coda (queue) e si attivano alla ricezione di un messaggio inviato all’argomento o alla coda a cui sono iscritti. Non richiedono una istanziazione da parte dei client.

Notevoli passi in avanti sono stati fatti dalla versione 2 alla 3.0

La grossa differenza nel passaggio da una versione ad un'altra è stata l'eliminazione delle classi utilizzate come Factory per istanziare concretamente il bean. Ciò significa che nella versione 3 non dovremo più creare una classe Home per ogni bean creato, né dovremo preoccuparci di estendere altre classi o interfacce.

Gli EJB 3.0 hanno in pratica modificato radicalmente l'architettura, lasciando molta più libertà alla costruzione dell'application server che ospiterà i componenti. Sarà infatti il container e la maniera in cui esso è implementato a gestire il ciclo di vita del componente. Non importa come questo avvenga: importante è rispettare la specifica e garantire il corretto ciclo di vita dei componenti. Fondamentalmente nella versione 3 sarà sufficiente scrivere una classe POJO (Plain Old Java Object) che implementa l'interfaccia di business.

Questa cosa potrebbe non essere positiva, in quanto in questo modo perderemmo la possibilità di intervenire in particolari momenti del ciclo di vita dell'oggetto (ad esempio durante le operazioni di passivazione ed attivazione). Ciò viene risolto dalla possibilità di creare delle apposite classi callback oppure di scrivere i metodi per gestire gli eventi ed annotarli con le annotazioni.

A questo punto risulta piuttosto evidente che il descrittore di deploy è inutile. Attraverso le annotazioni, infatti, riusciamo a definire in maniera precisa il componente e le sue diverse funzionalità, il ciclo di vita (anche le transazioni o altre funzioni di middleware da implementare). Di tutti i componenti, probabilmente questo è stato quello meno amato per un semplice motivo: è XML. Difficile da scrivere, da leggere e da capire, attraverso le annotazioni, fortunatamente questo componente viene meno. Inoltre, la sua redazione avviene in una seconda fase rispetto allo sviluppo del componente, quindi, l'insidia può essere rappresentata dalle dimenticanze. La possibilità di definire già all'interno della classe il suo comportamento del componente (transazioni, sicurezza, riferimenti ad altri ejb, ecc) facilita (e non poco) il lavoro.

Come application server per gli EJB consigliamo certamente JBOSS.

Maggiori informazioni su JBoss: www.jboss.com
Comunità degli sviluppatori: www.jboss.org