Nel maggio 2006, nasceva Java EE 5 (EJB 3.0 e JPA 1.0), scompariva l'acronimo J2EE ed il cambiamento
ha rappresentato una rinascita per la piattaforma enterprise di Java. Con
JEE 5 sono state introdotte le annotazioni e lo sviluppo degli EJB è stato enormemente
semplificato rispetto al passato.
Java EE 6 (EJB 3.1 e JPA 2.0) veniva rilasciata nel 2009 rendendo la piattaforma
ancora più potente e semplice da utilizzare. L'ultima release, JEE 7 ( EJB 3.2 e JPA 2.1),
continua l'evoluzione introducendo, inoltre, il supporto a WebSockets, Web Services Rest e JSON-P. Queste ultime
non sono però oggetto di questa guida, ci concentreremo invece su EJB 3.2 e JPA 2.1 comprendendo caratteristiche nuove
ed ereditate dalle versioni precedenti.
JEE 7 con EJB 3.2
Gli Enterprise Javabeans rappresentano una tecnologia in grado di risolvere
quelle problematiche tipiche di applicazioni complesse o enterprise come ad esempio quelle bancarie, e-commerce ad alto traffico,
e sistemi di integrazione. Le caratteristiche offerte dalla tecnologia si riassumono in:
- Sicurezza.
- Scalabilità.
- Distribuzione.
- Transazionalità.
- Persistenza dei dati.
Il ciclo di vita degli EJB è gestito da un particolare ambiente noto con il nome di EJB Container presente
all'interno di un application server; il Container è in grado di fornire ai componenti EJB i servizi elencati
precedentemente. JEE 7 con EJB 3.2 introduce nuove caratteristiche rispetto alla versione JEE 6 a partire dal supporto alla vecchia versione
EJB 2.0 che è stato reso opzionale; questo significa che un application server
Java EE 7 compliant non ha più bisogno di fornire il supporto agli entity beans nel vecchio stile EJB 2.
Il linguaggio
EJB QL è opzionale cosi come JAX-RPC. Da citare anche i miglioramenti sui message-driven beans e un message-driven bean adesso è in grado
di implementare un'interfaccia listener senza metodi. Con un'interfaccia di questo tipo tutti i metodi non statici
della classe del bean, e tutti i metodi di eventuali superclassi eccetto Object, sono esposti come metodi pubblici.
Miglioramenti anche sui session bean stateful. Possibilità di disattivare la passivazione, ovvero di salvare lo stato
del session bean su disco per essere recuperato successivamente. Prima della versione EJB 3.2 tutti gli oggetti gestiti da un session bean
di tipo stateful dovevano implementare l'interfaccia Serializable affinchè il loro stato potesse
essere serializzato su disco dal container. Se anche un solo oggetto non fosse stato serializzabile
la passivazione falliva.
Sebbene questa caratteristica sia desiderabile per
consentire ad un EJB container di fornire servizi di
passivazione e clustered failover, alcune volte purtroppo non è possibile. Con EJB 3.2
possiamo disattivare la passivazione; in precedenza negli stateful session beans i metodi di callback del ciclo di vita
avevano un non definito supporto alle transazioni. Adesso la nuova API aggiunge il supporto transazionale ai metodi
di callback.
Vi è poi la semplificazione dell'interfaccia local per i session beans stateless, in precedenza infatti se le interfacce dei session beans
stateless non venivano marcate con l'annotation @Local o @Remote
il bean di implementazione era costretto a specificare quale delle due annotazioni utilizzare. Con EJB 3.2 abbiamo
un comportamento più intelligente, se un'interfaccia non è marcata con @Local o @Remote si assume di default
che l'annotation applicata sia tipo @Local, evitando definizioni all'interno dell'implementazione del bean.
Ad esempio
prima di EJB 3.2 avremmo scritto qualcosa del tipo:
public interface InterfaceA {...}
public interface InterfaceB {...}
@Stateless
@Local({InterfaceA.class, InterfaceB.class}}
public class ServicesBean implements InterfaceA, InterfaceB {...}Adesso con EJB 3.2 lo stesso codice può essere scritto come:
@Stateless
public class ServicesBean implements A, B {}
Da non ignorare i miglioramenti nella TimerService API. In precedenza, gli oggetti Timer e TimerHandler potevano essere acceduti solo
dal bean proprietario del timer. Questa restrizione è stata superata,
un nuovo metodo chiamato getAllTimers() restituisce una lista di tutti
i timer attivi nel modulo EJB. Questo consente a qualsiasi codice di accedere ai timer
avendo la possibilità di agire su di essi.
JPA 2.1
Anche JPA con la versione 2.1 subisce importanti miglioramenti, sono state per esempio introdotte le Named Stored Procedure Query. Prima di JPA 2.1, l'unico modo
di invocare una stored procedure era quello di utilizzare una query nativa, con l'annotation
@NamedStoredProcedureQuery possiamo definire una query che invoca una stored procedure astraendo
dal database sottostante.
L'EntityManager è stato dotato di un metodo createStoredProcedureQuery per
l'invocazione di stored procedure. Sono stati inoltre introdotti gli Attribute Converter e
si può comprendere la loro utilità nel momento in cui si deve persistere sul database
un tipo custom non supportato dal database stesso, come ad esempio il nuovo tipo Date di Java.
Tutto ciò che dobbiamo fare è realizzare una classe che implementi l'interfaccia AttributeConverter
ed applicarle l'annotation @Converter; prima di JPA 2.1 l'annotation @NamedQuery era l'unico modo
di definire delle named query, con JPA 2.1 l'EntityManager fornisce il metodo addNamedQuery(String name, Query query)
come alternativa.
Il lazy loading, ovvero la capacità di caricare entity dal database quando necessario,
è stato potenziato con le annotazioni
@NamedEntityGraph, @NamedAttributeNode e @NamedSubGraph
che consentono di specificare un grafo di entity da caricare dalla base dati.
Quanto detto si associa ad un potenziamento del linguaggio JPQL grazie al quale ora
possiamo utilizzare la parola chiave ON per definire parametri di join,
invocare funzioni di database con FUNCTION e fare il downcast di entities con TREAT.
Vi è infine la possibilità
di avere un Persistence Context non sincronizzato;
un Persistence Context sincronizzato propaga ogni cambiamento sul modello ai record associati sulla base dati e rappresenta
il comportamento di default in JPA. Se si vuole avere maggior controllo abbiamo adesso la possibilità di una versione
non sincronizzata.
