Spesso il primo passo nello sviluppo di applicazioni enterprise consiste nella creazione del domain model ovvero dell’insieme di entità del dominio e delle relazioni fra esse.
Il domain model è l’immagine concettuale del problema che il sistema deve risolvere, esso descrive oggetti e relazioni ma non si occupa di definire come il sistema agisce su tali oggetti.
L’ obiettivo è quello di identificare le entità che devono essere persistenti e quindi memorizzate nel database.
Gli aspetti sui quali occorre prestare attenzione sono gli oggetti, le relazioni, le molteplicità delle relazioni e l’opzionalità delle relazioni.
Dal punto di vista dello sviluppatore gli oggetti sono oggetti java con stati e comportamenti.
Una relazione è rappresentata dal fatto...

Le tecnologie più comuni nella creazione di web application sono le JSP e le servlets che vivono all’interno di web container dei quali il più popolare è Apache Tomcat.
JBoss AS 5 fa uso di un nuovo prodotto Red Hat chiamato JBoss Web Server che combina la velocità di Apache HTTP Server con la versatilità di Apache Tomcat.
Le web application Java EE sono impacchettate in una struttura WAR definita dalle specifiche servlet.
Nel caso di directory esplose, la cartella a livello più alto definisce il nome del package e deve avere suffisso .war, nel caso di web archive il nome del package è dato dal nome dell’archivio che deve terminare con il suffisso .war.
La directory top-level contiene file statici o specifici del livello presentazione ...

Enterprise JavaBeans è basato sull’idea di oggetti gestiti che non sono altro che Plain Old Java Object (POJO) annotati.
Quando un client invoca un EJB utilizzando l’interfaccia che questo espone, non dialoga direttamente con l’istanza ma con il container che fa da proxy fra le due parti.
In particolare per ogni istanza di un EJB, il container genera un proxy chiamato EJB object che ha accesso a tutte le funzionalità del container e ai servizi che questo offre a supporto.
Dal momento che tutte le richieste rivolte all’EJB passano attraverso il proxy, questo può aggiungere i servizi del container necessari.
Tutto ciò avviene in maniera del tutto trasparente al client e allo sviluppatore...

Di solito le comunicazioni fra i componenti di un’applicazione sono sincrone il che significa che l’oggetto che effettua la chiamata e l’oggetto che viene invocato devono essere entrambi presenti affinchè la comunicazione possa avvenire. La comunicazione sincrona comporta anche il fatto che il client deve attendere che l’oggetto invocato completi l’elaborazione della richiesta prima di poter procedere oltre.
I Message-Oriented Middleware (MOM) permettono a due oggetti di comunicare in maniera asincrona facendo da ponte fra l’uno e l’altro: in questo caso non è più necessaria la presenza contemporanea dei due oggetti in quanto il messaggio verrà trattenuto dal MOM e consegnato solo quando il destinatario potrà riceverlo.

I session bean stateful garantisco il mantenimento dello stato della comunicazione.
Il container EJB infatti fa in modo che l’invocazione di metodi da parte dello stesso client sia gestita sempre dalla stessa istanza del session bean.
Ciò naturalmente ha un costo, dal momento che ogni istanza deve infatti essere mantenuta in memoria fino alla successiva richiesta si ha infatti una notevole occupazione di memoria.
Per ovviare a questo problema EJB fa uso di una tecnica nota come passivazione che consiste nel trasferire in memoria secondaria quei session bean stateful che sono in attesa di una richiesta da parte del client da diverso tempo.
Una volta che il session bean ...

I session bean stateless non mantengono alcuno stato della conversazione con il client.
Essi sono tipicamente organizzati dal conteiner in un pool: ad ogni richiesta da parte del client un’istanza del session bean di tipo stateless viene recuperata dal pool e assegnata al client, quando la richiesta si conclude, l’istanza torna al pool per un successivo riutilizzo.
Questo significa che un numero relativamente piccolo di istanze di session bean di tipo stateless può essere usato per servire un grande numero di client.
Supponiamo di voler creare un semplice session bean stateless la cui interfaccia espone un metodo che restituisce la data corrente.
Supponendo di voler accedere...

In JavaServer Faces la navigazione è un insieme di regole per scegliere la successiva pagina che deve essere visualizzata dopo un'azione (es. click su un link).
La navigazione può essere di due tipi: statica se cliccando su un determinato bottone la pagina successiva da visualizzare è fissata, dinamica se la successiva pagina che viene visualizzata dipende dal risultato dell’elaborazione sull’input utente.
Per implementare la navigazione statica è sufficiente indicare nell'attributo action del componente (ad esempio un commandButton) il valore logico che identifica univocamente la regola di navigazione definita nel file di configurazione da applicare.
Una regola di navigazione è definita dall’elemento navigation-rule ed ha la seguente forma...

In accordo con le specifiche JavaBeans, un Java Bean è un componente software riusabile.
Nel contesto di JavaServer Faces, i beans sono spesso utilizzati per contenere alcuni dei componenti dell’interfaccia utente, pertanto prendono il nome di backing bean.
Una tipica applicazione JSF include uno o più backing bean associati a UIComponent usati all'interno di una pagina.
Tutti i bean, oltre a definire un costruttore senza argomenti, devono definire un insieme di proprietà dell'UIComponent e possibilmente un insieme di metodi di utilità.
Ogni proprietà di un bean può fare riferimento a un valore di un componente, un'istanza di un componente, un'istanza di un convertitore...