Introduzione
Questa linea guida si focalizza sull'identificazione di EJB. Un'ulteriore guida agli EJB viene fornita dalla Linea guida: EJB (Enterprise JavaBean)
Identificazione di EJB
Tipicamente gli EJB sono utilizzati per implementare un oggetto business dal lato server che richiede supporto per
transazioni e accesso remoto o che opera su dati condivisi (come l'aggiornamento di informazioni sul conto).
Gli EJB sono spesso identificati quando vengono descritte classi di progettazione dal Prodotto di lavoro: Classe di analisi. Le classi di controllo sono
potenziali candidate ai bean di sessione, che hanno lo scopo di fornire una logica di controllo. Le classi di entità
sono potenziali candidate ai bean di entità, che sono predisposti ai dati permanenti.
Fare anche riferimento alle seguenti linee guida, che sono più specifiche:
Confonto tra bean di sessione, bean basati sui messaggi e
bean di entità
Riassumendo alcune delle linee guida precedentemente menzionate, questa tabella identifica i ruoli svolti dai vari EJB,
i metodi di accesso e la natura del loro stato.
|
Di sessione
|
Basati sui messaggi
|
Entità
|
Ruolo
|
Implementano la logica di business specifica ai client
|
Implementano la logica di business specifica all'elaborazione dei messaggi
|
Implementano la logica di business specifica all'entità di business
|
Metodo di accesso
|
Singolo client attraverso interfacce locali o remote
|
Contenitore attraverso l'interfaccia JMS MessageListener; non direttamente accessibile dai client
|
Vari clienti simultaneamente attraverso interfacce locali e remote
|
Stato
|
È possibile mantenere uno stato conversazionale transitorio tra client e contenitore
|
Stateless, ma può mantenere collegamenti alle risorse
|
Stato persistente salvato nel database
|
Modellazione di EJB
Gli EJB sono modellati come una serie di classi stereotipate. In modo specifico, la classe di bean e tutte le classi di
interfaccia EJB. Le interfacce EJB sono modellate come classi stereotipate, e non interfacce UML, per i motivi
descritti nella Linea guida: Interfacce per applicazioni J2EE.
Le relazioni tra la classe di bean e le interfacce EJB sono modellate come dipendenze dalla classe di bean alle
interfacce e non come autentiche relazioni. Tipicamente, il costrutto di implementazione Java è rappresentato come
realizzazione tra un'interfaccia e una classe. Tuttavia, le classi EJB non implementano le relative classi di
interfaccia, cosicché è più appropriata una dipendenza. Il diagramma sottostante illustra tale concetto. Per
approfondire questo esempio specifico, consultare la Linea guida: Progettazione di sottosistemi per applicazioni J2EE.
Descrizione di EJB e di classi
Di seguito vengono illustrati gli stereotipi UML applicabili alla modellazione di EJB.
Stereotipo
|
Applicabile a
|
Definizione
|
<<EJBSessionHomeInterface>>
<<EJBEntityHomeInterface>>
|
Classe
|
Indica un'interfaccia home di entità o di sessione rispettivamente
|
<<EJBRemoteInterface>>
|
Classe
|
Indica un'interfaccia remota EJB.
|
<<EJBLocalInterface>>
|
Classe
|
Indica un'interfaccia locale EJB.
|
|
|
|
<<EJBSession>>
|
Classe
|
Indica una classe di bean di sessione EJB.
|
<<EJBEntity>>
|
Classe
|
Indica una classe di bean di entità EJB.
|
<<EJBMessageDriven>>
|
Classe
|
Indica che la classe è un bean basato sui messaggi.
|
Un EJB è solitamente raggruppato in un sottosistema, con classi strettamente collegate ed EJB. Ciò consente al
progettista di fornire una vista di specifica degli EJB indipendente dall'implementazione e di aggregarli ad
altri elementi di progettazione per ottenere un livello di astrazione più alto. Vedere la Linea guida: Progettazione di sottosistemi per applicazioni J2EE per ulteriori
dettagli.
Fare anche riferimento alla Specifica di mappatura UML/EJB (RSC01) che contiene un elenco completo degli stereotipi per rappresentare i
costrutti EJB.
Modellare le dipendenze agli argomenti o alle code a cui il bean basato sui messaggi sottoscrive. Leggere la Linea guida: Descrizione dell'architettura runtime delle applicazioni J2EE per
informazioni aggiuntive sulla modellazione di elementi simultanei in un'applicazione J2EE.
Meccanismi come la persistenza gestita dal contenitore, le transazioni, l'autorizzazione e così via può essere
utilizzati e modellati come proprietà aggiuntive della classe di bean o semplicemente inclusi in una descrizione
testuale associata alla classe di bean.
Utilizzare diagrammi di sequenza per considerare scenari che contengono questi meccanismi.
I diagrammi di interazione (di collaborazione e di sequenza) possono essere impiegati per mostrare il comportamento
dinamico di EJB e l'interazione di non EJB (inclusi i componenti Web e le applicazioni di client esterni) con EJB.
Tali diagrammi di interazione sono essenzialmente gli stessi descritti nel Compito:
Progettazione del caso d'uso. Le interazioni possono essere mostrate da un bean scatola nera che interagisce
soltanto con le interfacce EJB. Le interazioni mostrano inoltre l'implementazione del bean attraverso le interazioni
fra le interfacce EJB e la classe di implementazione del bean. Notare che l'interazione che si verifica con il
contenitore non viene quasi mai visualizzata.
I bean basati sui messaggi consumano messaggi che arrivano in modo asincrono da altre fonti. È possibile mostrare un
messaggio asincrono che va direttamente dall'autore all'utente o fare in modo che la modellazione sia più specifica e
che interessi soltanto gli argomenti e le code.
La figura 2 rappresenta un esempio di diagramma di sequenza che mostra l'interazione tra una classe client ed
interfacce EJB.
Figura 2: Interazione tra una
classe client ed interfacce EJB
La figura 3 è un diagramma di sequenza simile alla figura 2, ma mostra interazioni con l'implementazione di bean.
Figura 3: Esempio di interazione con implementazione di EJB
EJB, costituito da una classe di implementazione di bean più interfacce EJB, può anche essere modellato come
sottosistema o componente.
Alcuni progettisti scelgono di modellare un EJB come una classe e di stereotipare le operazioni per indicare se
appartengono ad interfacce "locali", "remote" o "principali". Ciò fornisce una notazione più compatta rispetto ad altre
alternative.
|