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[1], 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.
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à:
Inoltre le specifiche definiscono il ruolo del contenitore di Enterprise JavaBean e di come far comunicare il contenitore con gli EJB.
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.
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.
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; } }
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!"; } }
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.
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:
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 ?).»
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.