Programmazione Distribuita - Java EE

JNDI

A partire da EJB 3.1, i nomi JNDI sono stati specificati in modo che il codice potesse essere portabile. Quindi ora ogni volta che un bean di sessione con le sue interfacce viene distribuito nel container, ogni bean/interfaccia viene automaticamente associato a un nome JNDI portatile. La specifica Java EE definisce i nomi JNDI portatili con la seguente sintassi:

java:<scope>/<app-name>/<module-name>/<bean-name>[!<fully-qualified-interface-name>]

Ogni parte del nome JNDI ha il seguente significato:

• <scope> definisce una serie di spazi dei nomi standard che mappano i vari ambiti di un'applicazione Java EE:
  • il prefisso java:global consente a un componente global: in esecuzione all'esterno di un'applicazione Java EE di accedere a uno spazio dei nomi globale.
  • il prefisso java:app consente a un componente in app: esecuzione all'interno di un'applicazione Java EE di accedere a uno spazio dei nomi specifico.

dell'applicazione. Il prefisso java:module consente a un componente in esecuzione all'interno di un'applicazione JavaEE di accedere a uno spazio dei nomi specifico del modulo. Il prefisso java:comp è uno spazio dei nomi privato specifico del componente e non è accessibile da altri componenti.

<app-name> è richiesto solo se il bean di sessione è impacchettato all'interno di un file ear o war. In questo caso, il valore predefinito di <app-name> è il nome del file ear o war (senza l'estensione del file .ear o .war).

<module-name> è il nome del modulo in cui è impacchettato il bean di sessione. Può essere un modulo EJB in un file jar autonomo o un modulo web in un file war. Il <nome-modulo> per impostazione predefinita è il nome di base dell'archivio senza estensione di file.

<bean-name> è il nome del bean di sessione.

<fully-qualified-interface-name> è il nome completo di ciascuna interfaccia business definita. Nel caso sia senza interfaccia, il nome può essere il nome completo della classe bean.

Esempi:

• Stateless bean

I bean di sessione stateless possono essere raggruppati e condivisi da più client. Ciò significa che, per ogni bean stateless, il container mantiene un certo numero di istanze in memoria (cioè un pool) e le condivide tra i client. Poiché i bean stateless non hanno uno stato client, tutte le istanze sono equivalenti. Quando un client richiama un metodo su un bean stateless, il container preleva un'istanza dal pool e la assegna al client. Al termine della richiesta del client, l'istanza torna al pool per essere riutilizzata. Ciò significa che è necessario solo un piccolo numero di bean per gestire diversi client.

Il contenitore non garantisce la stessa istanza per lo stesso client.

@Stateless
public class ItemEJB

{@PersistenceContext(unitName = "chapter07PU")}
private EntityManager em;

public List<Book> findBooks() {
    TypedQuery<Book> query = em.createNamedQuery(Book.FIND_ALL, Book.class);
    return query.getResultList();
}

public List<CD> findCDs() {
    TypedQuery<CD> query = em.createNamedQuery(CD.FIND_ALL, CD.class);
    return query.getResultList();
}

public Book createBook(Book book) {
    em.persist(book);
    return book;
}

public CD createCD(CD cd) {
    em.persist(cd);
    return cd;
}

@Target({TYPE})
@Retention(RUNTIME)
public @interface Stateless {
    String name() default "";
    String mappedName() default "";
    String description() default "";
}

Stateful bean- Quando un client richiama un bean di sessione stateful nel server, il contenitore EJB deve fornire la stessa istanza per ogni successiva chiamata al metodo. I bean stateful non possono essere riutilizzati da altri client.- La correlazione uno a uno ha un prezzo perché, come avrai intuito, se hai un milione di client,

otterrai un milione di bean stateful in memoria. Per evitare un consumo di memoria così grande, il contenitore cancella temporaneamente i bean stateful dalla memoria prima che la successiva richiesta del client li riporti indietro. Questa tecnica è chiamata passivazione.

La passivazione è il processo di rimozione di un'istanza dalla memoria e di salvataggio in una posizione persistente (un file su un disco, un database, ecc.). Ti aiuta a liberare memoria e a liberare risorse (un database o connessioni JMS, ecc.). L'attivazione è il processo inverso, il ripristino dello stato e dell'applicazione a un'istanza. La passivazione e l'attivazione sono fatte automaticamente dal container. Quello di cui dovresti preoccuparti è liberare qualsiasi risorsa (ad esempio, connessione al database, connessione JMS factory, ecc.) prima che il bean sia passivato. Da EJB 3.2, puoi anche disabilitare la passivazione.

@Stateful
@StatefulTimeout(value = 20,

unit =TimeUnit.SECONDS)
public class ShoppingCartEJB {
    private List<Item> cartItems = new ArrayList<>();

    public void addItem(Item item) {
        if (!cartItems.contains(item))
            cartItems.add(item);
    }

    public void removeItem(Item item) {
        if (cartItems.contains(item))
            cartItems.remove(item);
    }

    public Integer getNumberOfItems() {
        if (cartItems == null || cartItems.isEmpty())
            return 0;
        return cartItems.size();
    }

    public Float getTotal() {
        if (cartItems == null || cartItems.isEmpty())
            return 0f;
        Float total = 0f;
        for (Item cartItem : cartItems) {
            total += (cartItem.getPrice());
        }
        return total;
    }

    public void empty() {
        cartItems.clear();
    }

    @Remove
    public void checkout() {
        // Do some business logic
        cartItems.clear();
    }
}

public class Cache {
    private static Cache instance = new Cache();
    private Map<Long, Object> cache = new HashMap<>();
    
    private Cache() {}
    
    public static synchronized Cache getInstance() {
        return instance;
    }
    
    public void addToCache(Long id, Object object) {
        if (!cache.containsKey(id))
            cache.put(id, object);
    }
    
    public void removeFromCache(Long id) {
        if (cache.containsKey(id))
            cache.remove(id);
    }
    
    public Object getFromCache(Long id) {
        if (cache.containsKey(id))
            return cache.get(id);
        else
            return null;
    }
}

@javax.ejb.Singleton ha la stessa API dell'annotazione @Stateless descritta in precedenza.
@Singleton
public class CacheEJB {
    private Map<Long, Object> cache = new HashMap<>();
    public void addToCache(Long id, Object object) {
        if (!cache.containsKey(id))
            cache.put(id, object);
    }
    public void removeFromCache(Long id) {
        if (cache.containsKey(id))
            cache.remove(id);
    }
    public Object getFromCache(Long id) {
        if (cache.containsKey(id))
            return cache.get(id);
        else
            return null;
    }
}
- @Startup: inizializza il singleton all'avvio dell'applicazione, e non alla prima chiamata
@Singleton
@Startup
public class CacheEJB {
    ...
}
- @DependsOn: nel caso l'inizializzazione di un singleton dipenda da altri singleton, permettere di specificare le dipendenze e quindi definire un ordine di inizializzazione
@Singleton
public class CountryCodeEJB {
    ...
}
@Singleton
public class ZipCodeEJB {
    ...
}
@DependsOn("CountryCodeEJB", "ZipCodeEJB")
@Startup
@Singleton
public class CacheEJB {
    ...
}
Dependency

Injection

I container possono inserire vari tipi di risorse nei bean di sessione utilizzando diverse annotazioni (o descrittori di distribuzione).

• inserisce un riferimento della vista locale, remota o senza interfaccia di un EJB nella variabile annotata.