Cos'è EJB? L'evoluzione di Enterprise JavaBeans

Enterprise JavaBeans (EJB) è una specifica per lo sviluppo di applicazioni aziendali distribuite su larga scala sulla piattaforma Java. EJB 1.0 è stato rilasciato nel 1998. La versione più recente, EJB 3.2.3, è stata adottata per essere inclusa in Jakarta EE, dove verrà rinominata Jakarta Enterprise Beans.

Architettura EJB

L'architettura EJB è costituita da tre componenti principali: bean enterprise (EJB), il contenitore EJB e il server delle applicazioni Java. Gli EJB vengono eseguiti all'interno di un contenitore EJB e il contenitore EJB viene eseguito all'interno di un server delle applicazioni Java.

Esistono due tipi di EJB: bean di sessione e bean a messaggi:

  • I bean di sessione vengono richiamati dal client e rendono disponibili al client in modo programmatico funzionalità aziendali quali transazioni e gestione delle risorse.
  • I bean basati sui messaggi incapsulano e forniscono anche funzionalità aziendali, ma sono asincroni e guidati dagli eventi. I bean basati sui messaggi ascoltano e rispondono agli eventi e non possono essere richiamati dal client.

Una volta utilizzati per fornire la persistenza nel sistema EJB, i bean di entità sono stati soppiantati dall'API Java Persistence. Continua a leggere per saperne di più sui bean di sessione e sui bean a messaggi.

EJB vs JavaBeans

Enterprise JavaBeans è stato il primo modello di sviluppo basato su componenti per Java EE. EJB è simile a JavaBeans in quanto basato su componenti, ma è qui che finisce la somiglianza:

  • Un JavaBean è una classe Java che incapsula più oggetti e si conforma a determinate convenzioni. I JavaBeans vengono utilizzati principalmente per lo sviluppo lato client.
  • Un bean enterprise (EJB) è una classe Java impregnata di funzionalità lato server specifiche. I bean enterprise vengono utilizzati in applicazioni e sistemi aziendali su larga scala.

Fagioli di sessione

Un bean di sessione è il tipo più generico di bean enterprise e rappresenta una parte della funzionalità aziendale che può essere richiamata da un client. Il client in questo caso potrebbe essere un'altra classe nella JVM locale o una chiamata remota.

Il contenitore EJB gestisce il ciclo di vita del bean di sessione, che è determinato dallo stato del bean:

  • I bean di sessione senza stato sono simili all'ambito della richiesta nell'API del servlet Java. I bean di sessione senza stato contengono una parte di funzionalità richiamabili ma per il resto sono senza stato.
  • I bean di sessione con stato sono associati a un solo client e si collegano alla sessione in corso di quel client. I bean di sessione con stato funzionano in modo simile all'ambito della sessione nell'API servlet.
  • I bean singleton sono simili all'ambito dell'applicazione nell'API servlet. Un bean di sessione singleton esiste solo una volta per ogni client.

Sicurezza dei thread con i bean di sessione

Un bean di sessione con stato è accessibile solo da un client alla volta, quindi la sicurezza del thread è garantita quando si lavora con questo tipo di bean. I bean di sessione senza stato e i bean singleton sono più flessibili, consentendo connessioni simultanee, che devono essere gestite dallo sviluppatore. Sei responsabile della sicurezza dei thread quando lavori con questi tipi di bean.

Fagioli basati sui messaggi

I bean a messaggi (MDB) vengono richiamati tramite messaggi JMS (Java Message Service). JMS funziona come un modello di comando distribuito, in cui il bean basato sui messaggi funge da listener per il comando. Quando un messaggio arriva su un argomento o una coda, viene richiamato il bean basato sui messaggi in ascolto su quell'argomento.

I bean a messaggi non sono comunemente usati come i bean di sessione, ma sono potenti. Essendo asincroni e guidati dagli eventi, sono particolarmente utili per i lavori di lunga durata in cui è importante conservare le risorse.

L'architettura più semplice sarebbe costituita dall'applicazione EJB e dal suo contenitore e server, che si coordinano con il servizio di messaggi che elabora gli MDB. Nella produzione, la tua architettura probabilmente includerebbe un terzo componente dedicato al consumo dei fagioli. In fase di sviluppo, tutti questi componenti potrebbero essere eseguiti sulla stessa macchina locale.

La Figura 1 mostra una tipica architettura basata su eventi con bean basati su messaggi.

Matthew Tyson

Lavorare con i bean a messaggi è più complicato che usare i bean di sessione. In un ambiente basato sugli eventi, in genere avrai bisogno di un broker di messaggi come ActiveMQ.

Mentre i bean di sessione sono più semplici e quindi più comunemente utilizzati in EJB, le architetture guidate dagli eventi sono diventate popolari, soprattutto con l'esplosione dei microservizi. 

Annotazioni EJB

La definizione e il consumo di bean enterprise era un punto critico per molti sviluppatori fino a EJB 3.0, che ha introdotto le annotazioni nella specifica EJB. Le annotazioni semplificano la configurazione dei bean enterprise per un'ampia gamma di funzionalità disponibili in Java EE. Continua a leggere per iniziare con le annotazioni EJB.

@Stateless: definisce un bean di sessione senza stato

Per designare una classe come bean di sessione senza stato, si utilizza l' javax.ejb.Statelessannotazione, come mostrato nel Listato 1.

Listato 1. Esempio di annotazione @Stateless

 import javax.ejb.Stateless; @Stateless public class MyStatelessBean { public String getGreeting() { return "Hello JavaWorld."; } } 

Questo bean senza stato contiene una semplice firma che non accetta argomenti e restituisce una stringa. Non lasciarti ingannare dalla semplicità: questo bean può fare tutto ciò di cui hai bisogno, inclusa l'interazione con altri bean, servizi o il livello dati della tua applicazione.

@ EJB: consuma un bean di sessione senza stato

Una volta definito un bean di sessione, utilizzarlo è molto semplice:

Listato 2. Esempio di annotazione @EJB

 public class MyServlet extends HttpServlet { @EJB MyStatelessBean myEjb; public void doGet(HttpServletRequest request, HttpServletResponse response) { response.getWriter().write("EJB Says " + testStatelessEjb.getGreeting()); } } 

Qui, iniettiamo il bean senza stato in un servlet e quindi è disponibile per l'uso. Notare come il bean viene identificato sotto l' @EJBannotazione. La designazione "stateless" ci dice che questo bean non terrà traccia del client. Poiché è senza stato, sappiamo anche che questo bean è soggetto a threading se funziona al di fuori del metodo invocato.

@Remote: definisce un'interfaccia EJB remota

Negli esempi precedenti, ho presupposto che il client EJB e EJB fossero in esecuzione nella stessa JVM. Se il bean enterprise e il relativo client sono in esecuzione in JVM separate, il bean deve definire @Remoteun'interfaccia. In questo caso, sta a te definire e implementare l'interfaccia, come mostrato nel Listato 3.

Listato 3. Esempio di annotazione @Remote

 @Remote public interface MyStatelessEjbRemote { String sayHello(String name); } 

L'interfaccia remota viene inviata al client per essere richiamata. Le chiamate ad esso verranno quindi soddisfatte dall'implementazione lato server di EJB. L' MyStatelessBeanesempio nel listato 4 implementa l'interfaccia remota.

Listato 4. Implementazione di un'interfaccia remota

 public class MyStatelessBean implements MyStatelessEjbRemote{ ... } 

Un'interfaccia remota è implementata proprio come una normale classe che implementa un'interfaccia. In qualità di consumatore di un bean remoto, l'applicazione client deve essere in grado di accedere alla definizione della classe per l'interfaccia remota. È possibile creare un pacchetto della definizione della classe per l'interfaccia remota come JAR di dipendenza.

Interfaccia locale vs remota

While it's important to know how to implement a remote interface, in practice it's more common to use a local interface. The local interface is used by default and works whenever the EJB is invoked within the same JVM context. Using the remote interface comes into play when the application is distributed across multiple JVMs.

Stateful sessions beans and singleton beans

The process for defining and consuming stateful @Session beans and @Singleton beans is the same as what you've seen for @Stateless beans. Remember the semantics:

  • Multiple session beans can be instantiated and used for the same client.
  • A singleton bean will exist only once for the entire application.

Thread safety and scheduling with singletons

Thread safety is built in when you're working with session beans, but both stateless and singleton beans can be accessed concurrently by multiple clients. Developers are responsible for thread safety when implementing these types of beans.

Singleton beans offer some support for thread safety via the @Lock annotation. You can use the @Lock annotation on singleton bean methods to set read/write privileges for each method. The two options are @Lock(LockType.READ) or @Lock(LockType.WRITE), which is the default.

Another useful feature of singleton beans is the ability to schedule tasks in a simple way, using the @Schedule annotation. Listing 5 shows how to schedule a task daily at noon.

Listing 5. @Schedule annotation example

 @Singleton public class MySchedulerBean { @Schedule(hour = "12") void doIt() { System.out.println("Hello at Noon!"); } } 

CDI vs EJB

CDI, or Context and Dependency Injection is a newer enterprise specification that some developers have proposed could replace EJB.

At a high level, CDI offers a general-purpose component framework, while EJB stands out for its richly featured, individual components. Whereas CDI uses dependency injection to define and reference any software component, EJB components are more formally defined, with each offering a specific set of capabilities out of the box. Both specs are planned for future development as part of Jakarta EE, where the question of whether CDI should replace EJB will eventually be resolved.

Conclusion

Enterprise JavaBeans è stata la prima specifica a offrire un modo semplice per incapsulare e riutilizzare la logica aziendale nelle applicazioni Java aziendali. Lontano dal colosso pesante del passato, EJB oggi è un framework snello e basato su annotazioni che ti consente di accedere a un'ampia gamma di funzionalità aziendali, immediatamente. Considera EJB la prossima volta che ti verrà chiesto di sviluppare rapidamente un'applicazione aziendale distribuita e scalabile. Potresti essere piacevolmente sorpreso.

Questa storia, "Che cos'è EJB? L'evoluzione di Enterprise JavaBeans" è stata originariamente pubblicata da JavaWorld.