EJB, JPA, eccezioni, JTA e Resource Local: facciamo un po' di chiarezza – Parte 2
Nel post precedente abbiamo affrontato EJB, JPA e JTA nel loro utilizzo più frequente (e più semplice). Vediamo adesso di […]
Nel post precedente abbiamo affrontato EJB, JPA e JTA nel loro utilizzo più frequente (e più semplice). Vediamo adesso di […]
Mi è capitato di leggere nei forum: “chi ha più bisogno degli EJB? Ormai è roba vecchia”. Posizione opinabile a […]
Nell’era delle App dove tutto è smart e veloce, parlare di Message Driven Bean (MDB) e Java Message Service (JMS) […]
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.
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.
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.
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.
Un piccolo passo per EJB3, un grande passo per l’uomo: EJB ha incrementato leggermente la sua versione con la specifica Java EE 6, passando alla 3.1 e introducendo qualche lieve ma importante modifica. Che ne dite di vedere insieme le novità della nuova versione?
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.