Introduzione
L'architettura runtime di un'applicazione è descritta nella vista Processo, una vista strutturale che descrive gli
elementi simultanei di un sistema. Queste linee guida forniscono una guida specifica su come modellare la vista
Processo per un'applicazione J2EE.
Consultare anche Concetto: Vista Processo.
Modellazione della vista Processo
I componenti J2EE (vedere Concetto: Panoramica di J2EE: Componenti di J2EE) sono distribuiti in ambienti
definiti contenitori. Vedere Concetto: Panoramica di J2EE: Contenitori di J2EE per una descrizione di ogni tipo
di contenitore definito da J2EE.
Ogni contenitore è un elemento simultaneo e come tale dovrebbe apparire nella vista del processo dell'architettura.
Altri importanti elementi simultanei che appaiono in genere nella vista del processo ad alto livello sono sistemi
esterni.
Il diagramma seguente è un tipico diagramma della vista del processo ad alto livello per un'applicazione J2EE.
In un vero esempio si potrebbe vedere rappresentato un MOM (Message Oriented Middleware) specifico del vendor, così
come sistemi precedenti specifici e client dell'applicazione. Tuttavia i contenitori Web ed EJB sono contenitori
standard che dovrebbero apparire in tutte le viste Processo J2EE.
Notare che questo diagramma non mostra la distribuzione fisica di questi sistemi in nodi hardware specifici. Ciò viene
mostrato nel modello di distribuzione (vedere Tecnica: Descrizione della distribuzione per le applicazioni J2EE).
In questo esempio si possono vedere i meccanismi di comunicazione dei processi selezionati utilizzati per i
contenitori. J2EE fornisce meccanismi di comunicazione dei processi specifici. Tra queste, si segnalano:
-
RMI (Remote Method Invocation) di Java per comunicazioni sincrone tra classi Java
-
RMI-IIOP per operazioni con client CORBA (in particolare applicazioni precedenti)
-
HTTP/HTTPS per la comunicazione con client basati sul Web (sebbene possano essere supportati anche altri
protocolli, come quando si interagisce con servizi Web XML)
-
JMS (Java Message Service) per messaggistica e interazioni con MOM (Message Oriented Middleware)
Nel definire la vista del processo, una decisione importante riguarda quando utilizzare JMS diretti verso RMI o
RMI-IIOP. Ad esempio, il client di applicazione, il contenitore EJB ed un altro sistema precedente utilizzano messaggi
per comunicare. Tuttavia, non è chiaro quali elementi comunichino con quali. Per sciogliere quest'ambiguità, è
possibile trascinare il sistema MOM dal diagramma e mostrare JMS come associazione tra gli elementi che comunicano
tramite messaggi.
Un'altra ambiguità riguarda la possibilità che gli EJB comunichino tra loro mediante messaggi. Ciò può essere chiarito
mostrando un'associazione JMS dal contenitore EJB verso se stesso. Il diagramma finale diventa dunque:
La vista del processo è tuttavia qualcosa di più di semplici contenitori e sistemi ad alto livello, indicaanche la
simultaneità tra questi sistemi e contenitori.
La vista del processo dovrebbe identificare e modellare i seguenti tipi di classi attive.
-
Thread di Java
-
Destinazioni di messaggio
-
Bean basati sui messaggi (poiché questi vengono richiamati in modo asincrono mediante messaggi). Vedere Tecnica: Identificazione di JavaBean Enterprise per stereotipi specifici
utilizzati per modellare bean basati sui messaggi.
-
Ulteriori processi che sono parte della progettazione generale del sistema. Un processo timer potrebbe essere un
esempio di questo tipo di elaborazione.
Quando si utilizza JMS, è possibile scegliere di collegare direttamente gli autori e gli utenti del messaggio o
modellare le relazioni in modo più preciso definendo argomenti e code.
I diagrammi di interazione sono utilizzati per mostrare la comunicazione sincrona e asincrona tra gli elementi di
progettazione. Possono anche essere utili per analizzare i comportamenti simultanei relativi ai problemi di logica e di
prestazione. In particolare, l'architetto software può rilevare messaggi frequenti o grandi quantità di trasferimento
di dati nella rete. Ciò potrebbe portare l'architetto a progettare nuovamente le interfacce o a riassegnare gli
elementi tra i thread di controllo, tra i server o tra client e server.
Notare che all'interno di un contenitore EJB, i thread e i processi sono gestiti dal contenitore EJB, gli EJB non
possono creare nè gestire thread. Logicamente ogni EJB dovrebbe essere considerato una classe attiva, tuttavia, poiché
le chiamate ai bean di sessione e di entità sono chiamate asincrone e bloccanti, non vengono in genere modellati come
classi. La vista del processo relativa al contenitore EJB è generalmente limitata ad un meccanismo di simultaneità
disponibile, JMS con bean basati sui messaggi JMS.
Sebbene i bean di sessione e di entità non siano generalmente modellati come classi attive, vi sono problemi di
simultaneità, come un EJB che legge il database mentre un altro scrive. Tali questioni sono gestite con l'utilizzo di
transazioni. Quest'approccio dovrebbe essere documentato nelle linee guida specifiche del progetto.
Ubicazione degli elementi di progettazione in classi attive
Compito: Descrivere l'architettura runtime descrive l'esigenza di
posizionare elementi di progettazione in processi e thread. In un'applicazione J2EE tutti i componenti Web sono ubicati
nel contenitore Web e tutti gli EJB nel contenitore EJB. Per via di questa semplice relazione, non è necessario
modellare questa ubicazione.
Se tuttavia la progettazione include ulteriori processi simultanei (come due diversi client di applicazione) potrebbe
essere utile specificare quali elementi di progettazione vengono eseguiti su ciascuna applicazione.
Per i thread Java, i bean basati sui messaggi e gli argomenti e le code JMS le questioni riguardano il modo in cui
questi comunicano, al fine di evitare deadlock, dati incongruenti e così via. Ciò viene analizzato meglio esaminando
realizzazioni del caso d'uso che includono questi elementi.
Altre alternative di modellazione
Per via dell'affinità tra le viste Processo e Distribuzione, i diagrammi ad alti livello per queste viste spesso sono
unificati.
Inoltre, poiché ogni contenitore J2EE non è solo un processo ma anche un ambiente di esecuzione, può essere modellato
come un "nodo logico" invece che come classe attiva.
|