Chiamate Asincrone con EJB3

Il web è sempre più veloce, o per lo meno deve dare questa percezione a chi lo usa: creare interfacce responsive al pari di quelle desktop è la sfida vinta col massiccio uso di chiamate ajax che introducono i concetti di “render parziale” della pagina e “chiamate asincrone” rispetto al caricamento dell’intera pagina. Il concetto di asincrono lato server invece non è mai stato nuovo: riuscire ad inviare una richiesta che verrà soddisfatta in un secondo momento permette di distribuire il carico computazione sul server nel tempo e soprattutto generare risposte veloci verso il client anche quando si richiedono operazioni onerose. La piattaforma Java Enterprise fornisce da tempo soluzioni architetturali o meno che permettono di raggiungere questo scopo. Dalla versione EJB 3.1 poi, è stato introdotto il concetto di EJB Asincrono che semplifica notevolmente le cose.

EJB 3.1 Timer Services: cosa bolle di nuovo in pentola?

Se EJB 3 è stata una rivoluzione, si può dire che EJB 3.1 è una ben accetta evoluzione. Anche se ancora non abbiamo mai affrontato l’argomento in modo analitico, in altre occasioni avevamo già sottolineato che la nuova specifica EJB 3.1 tende ad una ulteriore semplificazione della piattaforma enterprise, introducendo miglioramenti che vengono incontro alla già difficile vita di noi sviluppatori…

Tra le varie cose, anche i Timer Services hanno subito qualche miglioramento atteso rispetto alla versione 3.0, di cui avevamo già avuto modo di imparare in un post precedente. Vediamo di che si tratta.

EJB3 Timer Services: il senso del tempo per gli EJB

Vi siete mai chiesti come facciano Ryanair o Expedia a mandarvi dei reminder via mail una volta che avete acquistato un biglietto? Beh, chi conosce gli scheduler, come per esempio il cron di Linux, non ha grossi dubbi. Chi conosce la piattaforma Java Enterprise neanche! Dalla specifica EJB 2.1 infatti sono presenti dei Timer Services messi a disposizione da qualsiasi Application Server (AS) J2EE 1.4 compliant. Con la specifica EJB3 l’utilizzo dei servizi di timing si è notevolmente semplificato, come del resto l’utilizzo stesso di tutta la piattaforma Enterprise.

WebSphere 7.0 e Cache Distribuita: l'alter ego di EJB 3.1 @Singleton ?

La piattaforma Java EE 6 ha introdotto notevoli salti di qualità per quanto riguarda lo strato di persistenza e quello web. Siamo passati infatti da JPA 1.0 e JSF 1.2 direttamente a JPA 2.0 e JSF 2.0. Per quanto riguarda lo strato di logica di business invece abbiamo avuto un piccolo incremento di sottoversione (3.0 -> 3.1), d’altro canto il grande salto era già stato fatto dalla Java EE 5 in questo senso. EJB 3.1 ci riserva però una piacevole sorpresa, ovvero un nuovo tipo di EJB chiamato Singleton, di cui abbiamo già parlato in un post precedente. Per chi però lavora con WebSphere 7.0 (WAS) ancora non può accedere ad un bean di questo tipo, ma può girare intorno al problema sfruttando in modo opportuno la Cache Distribuita che l’Application Server mette a disposizione. Vediamo di che si tratta.

EJB3 Message Driven Bean con JMS: Request/Reply Pattern con JBoss – Parte II

Riprendiamo e concludiamo il filone dei Message Driven Bean (MDB) che avevamo iniziato in due post precedenti: in uno più teorico, avevamo descritto la struttra asincrona dei MDB che ricevono e inviano messaggi JMS, con riferimento a qualche pattern architetturale; nel secondo avevamo invece messo mano al codice, in particolare su come implementare il Request/Reply pattern basato sul Correlation ID. Come promesso, vediamo adesso cosa bisogna fare per implementare invece il pattern basato su Message ID.

EJB3 Stateless vs Stateful, quale è la differenza?

La risposta alla domanda “quale è la differenza fra ejb stateful e stateless?” sembra evidente: gli stateful mantengono lo stato e possono essere usati per il classico carrello della spesa mentre gli stateless non avendo uno stato possono essere usati per implementare dei servizi. Ma siamo sicuri che la risposta è così semplice? Per quanto viene mantenuto lo stato di un ejb stateful? Per la durata della sessione web? Proviamo a fare un po’ di chiarezza in questo post.