Linea guida: Descrizione dell'architettura runtime delle applicazioni J2EE
Questa linea guida descrive come modellare l'architettura runtime di un'applicazione J2EE.
Relazioni
Descrizione principale

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.

Diagramma descritto nel testo di accompagnamento.

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:

Diagramma descritto nel testo di accompagnamento.

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.