Enterprise JavaBeans

In informatica gli Enterprise JavaBean (EJB) sono i componenti software che implementano, lato server, la logica di business di un'applicazione web all'interno dell'architettura/piattaforma Java EE espletando servizi a favore della parte di front-end ovvero per la logica di presentazione di un'applicazione web. Rappresentano dunque uno strato software residente su un application server all'interno di un'architettura software di tipo multi-tier.

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. Lo standard attuale, EJB 3.2, completato nella primavera del 2013, differisce notevolmente dalla versione 2.1 delle specifiche, in quanto introduce la possibilità di effettuare dependency injection e di effettuare mediante annotations le configurazioni che precedentemente avvenivano mediante XML. Gli EJB necessitano di un EJB container tipicamente implementato all'interno degli application server assieme al servlet container per la parte di front-end.

Motivazioni

Le specifiche Enterprise JavaBean intendono fornire una metodologia standard per implementare la logica di funzionamento delle applicazioni di tipo enterprise, applicazioni cioè che forniscono servizi via Internet su larga scala. Per realizzare applicazioni di questo tipo è necessario affrontare una serie di problematiche tecniche che possono rivelarsi molto complesse e laboriose da risolvere. Gli Enterprise JavaBean intendono fornire una soluzione a questi problemi in modo da semplificare lo sviluppo di questo tipo di applicazioni.

Le specifiche Enterprise JavaBean descrivono in dettaglio come realizzare un application server che fornisca le seguenti funzionalità:

• Persistenza;
• Elaborazione delle transazioni;
• Controllo della concorrenza;
• Programmazione ad eventi tramite il Java Message Service;
• Servizio di directory per elencare e nominare gli EJB (JNDI);
• Sicurezza (JCE e Java Authentication and Authorization Service);
• Installazione di componenti software in un application server;
• Invocazione di procedure remote tramite l'utilizzo di RMI-IIOP o CORBA;
• Fornire servizi web.

Inoltre le specifiche definiscono il ruolo del contenitore di Enterprise JavaBean e di come far comunicare il contenitore con gli EJB.

Tipologie

Fino alla versione 2.1 della specifica esistevano tre tipi di Enterprise JavaBeans, dalla versione 3.0 in poi ne esistono soltanto due, in quanto gli Entity Bean sono stati deprecati. Per completezza vengono riportati tutti i tipi di EJB.

EJB di sessione

Detti anche 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 e senza stato.

Dalla versione 3.2 dello standard EJB possono essere invocati in modo asincrono. L'invocazione asincrona avrà come valore di ritorno una variabile di tipo Future<V>, che permetterà al chiamante di conoscere l'effettivo valore di ritorno, verificare l'eventuale presenza di eccezioni ed annullare una chiamata in corso.

Con stato

Vengono anche detti stateful. I bean di sessione con stato sono oggetti distribuiti che possiedono uno stato. Lo stato non è persistente, però l'accesso al bean è limitato ad un unico client.

Un esempio di bean con stato è:

@Stateful
public class Contatore {
   private int totale = 0;
   public int totale() {
       return totale;
   }
   public void incrementa() {
       totale = totale + 1;
   }
   public void azzera() {
       totale = 0;
   }
}

Senza stato

Detti anche stateless. I bean di sessione senza stato sono oggetti distribuiti senza uno stato associato, questa caratteristica 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.

Un esempio di bean senza stato è:

@Stateless
public class SalutoBean {

 public String salutaUtente() {
    return "Benvenuto!";
 }

}

EJB guidati da messaggi

Detti anche Message driven EJBs. Erano gli unici bean con funzionamento asincrono (dalla versione 3.2 dello standard anche EJB di sessione possono essere invocati in modo 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.

EJB di Entità

Vengono detti anche Entity EJB. Non sono più supportati, in quanto con la versione 2.0 e 2.1 dello standard EJB avevano delle prestazioni molto basse ed i programmatori preferivano utilizzare chiamate JDBC dirette o framework di persistenza come Hibernate o MyBatis. Per ovviare a questo problema, è stato introdotto Java Persistence API.

Il loro scopo era di inglobare gli oggetti sul lato server che memorizzano i dati. Gli entity bean fornivano 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.

Versioni

• JSR 19: Enterprise JavaBeans 2.0, su jcp.org.
• JSR 153: Enterprise JavaBeans 2.1, su jcp.org.
• JSR 220: Enterprise JavaBeans 3.0 introduce la possibilità di dichiarare e configurare gli Enteprise JavaBeans mediante il meccanismo delle annotations. Da questa versione in poi, un EJB non deve più estendere alcuna classe specifica. Tale modifica viene spesso citata come Plain Old Java Object (POJO). Vengono introdotti i primi meccanismi di dependency injection. Per la persistenza vengono abbandonati gli Entity Bean e c'è Java Persistence API (JPA).
• JSR 318: Enterprise JavaBeans 3.1 va nella direzione della semplificazione. Tale direzione è obbligata dalla fortissima diffusione dello Spring Framework. Introduce il cosiddetto Lite EJB, ovvero la possibilità di inserire degli Enterprise JavaBeans all'interno di un Web Archive, che finora poteva contenere unicamente servlet, ma non EJB. Ora è possibile invocare gli EJB da una applicazione Java SE, senza dover usare servlet container o application server. I session bean possono essere invocati in modo asincrono e c'è la possibilità di creare degli EJB Timer.
• JSR 345: Enterprise JavaBeans 3.2 introduce la possibilità di invocare i bean di sessione in modo asincrono.

Enterprise JavaBeans e microservices

Riguardo allo sviluppo di microservice attraverso l'utilizzo di Enterprise JavaBeans, Antonio Goncalves, Expert Member di CDI 2, Java EE 8 ed autore di numerosi libri su Java EE, scrive:

«Java EE needs a simple Java SE Container API that we could easily bootstrap. Most of EE specs are already "embeddable" anyway and the ones you mentioned are or will be (CDI 2.0 with have a Java SE bootstrap API in Java EE 8). But I'm less confident about EJBs. EJBs are not "that micro", they are a bit fat (and I'm just talking about the number of services they bundle). I would prefer to see the Java EE Concurrency updated (to have asynchronous invocation out of EJBs), and focus on CDI, JTA, Concurrency, JPA and JAX-RS (but again, why not adding Bean Validation and servlets, if we have JAX-RS ?).»

(Antonio Goncalves, One container to rule them all)

Ciò che intende sottolineare è che il numero di servizi che la specifica Enterprise JavaBeans porta con sé è elevato, quindi non è consigliabile quando si vogliano creare dei microservice.

Voci correlate

• Java Persistence API
• Java EE
• Application server
• Spring framework