Operazione: Assegnazione componenti del servizio agli strati
Questa attività specifica i dettagli dei componenti di servizio che realizzano un sottosistema di progettazione.
Scopo

Per elaborare su  uno o più Artefatto: Sottosistema di progettazione descritti durante laOperazione: Progettazione del sottosistema (SOA) e per fornire progetti dettagliati di Artefatto: Componente servizio designs.

Relazioni
RuoliPrincipale: Aggiuntivo: Assistenza:
InputObbligatorio: Facoltativo: Esterno:
  • Nessuno
Output
Descrizione principale

I servizi utilizzati in una soluzione basata su SOA sono realizzati tramite Artefatto: Componente servizio che appartengono ad un sistema secondatio allineato della funzione di business specifica. Ogni componente del servizio avrà la responsabilità di assicurare il QoS dei servizi che realizza. Come asset su scala d'impresa, ogni Componente del servizio qualifica il finanziamento, la gestione e la manutenzione associata a questa. La gestione delle infrastrutture deve essere al proprio posto per assicurare la disponibilità, il bilanciamento del carico, la sicurezza, la prestazione, la versione e la salute generale del componente di servizio che sarà responsabile per l'implementazione della funzionalità di un insieme di servizi e l'assicurazione della qualità del servizio. I componenti funzionali e tecnici possono essere utilizzati in molti componenti di servizio.

Passi
Assegnazione componenti ai livelli

La strutturazione a livelli offre i seguentu vantaggi:

  • I livelli aiutano a portare attributi di qualità di modificabilità e portabilità in un sistema IT. Una modifica ad un livello inferiore che non ne influenza l'interfaccia non richiede nessuna modifica ad un livello superiore. Ad esempio, tutti i server di applicazione conformi a J2EE™ che rispettano lo standar J2EE™ potrebbero essere liberamente sostituiti con la modifica al software di livello di applicazione. Una modifica ad un livello inferiore che non influenza le funzioni che richiede dagi livelli inferiori non influenzerà nessun livello inferiore. In generale, le modifiche ad un sistema software strutturato in livelli che non influenza nessuna interfaccia sono confinate ad un livello singolo.
  • I livelli sono parte di un ruolo blueprint che l'architettura interpreta per costruire il sistema. Conoscendo i livelli nei quali il software risiede, gli sviluppatori consocono su quali servizi si possono affidare nell'ambiente di codifica. I livelli potrebbero definire le assegnazioni del lavoro per i team di sviluppo (sebbene non sempre).
  • I livelli sono parte di un ruolo di comunicazione giocato dall'architettura. In un sistema ampio, il numero di dipendenze tra i moduli si espande in modo rapido. L'organizzazione del software in livelli con le interfacce è uno strumento importante per gestire la complessità e comunicare la struttura agli sviluppatori.
  • I livelli aiutano con il ruolo di analisi interpretato dall'architettura. Questi possono essere utilizzati per l'analisi dell'impatto delle modifiche al progetto.

La strutturazione in livelli può essere streatta e non stretta. Uno schema di strutturazione in livelli stretto significa che i componenti possono solo utilizzare i componente nello stesso livello o livelli immediatamente al di sotto di questi. Uno schema di suddivisione in livelli significa che i componenti possono utilizzare i componenti nello stetto o in qualsiasi livello inferiore. Notare che come regola generale, tuttavia, ai componenti non dovrebbe essere consentito utilizzare i componenti nei livelli superiori. Se i componenti hanno dipendenze sui componenti nei livelli superiori, allora diventa difficile sostituire i componenti del livello superiore senza dover modificare i componenti del livello inferiore. Per ulteriori informazioni, incluse le tecniche per il modellamento dei livelli, consultare Concetto: Partizionamento della soluzione.

Un punto importante è notare che i livelli software non sono uguali ai livelli. L'assegnazione alle macchine in un ambiente distribuito, il flusso di dati tra gli elementi e la presenza e l'utilizzo di canali di comunicazione, tutto tende ad essere espresso in immagini in file che possono essere incomprensibili per i diagrammi di livello. I diagrammi a file tendono a mostrare freccie a due punte che indicano una certa comunicazione bidirezionale. La comunicazione bidirezionale (simmetrica) è una cattiva notizia in un diagramma a strati. Inoltre, l'assegnazione di un componente ad una file si basa sul posizionamento delle regole considerate durante la definizione dell'architettura operativa ed è definita dalle caratteristiche del livello di servizio richiesto del sistema. La differenza principale tra i diagrammi di livello e le immagini in fila è che il primo non ha alcuna nozione del posizionamento mentre le altre ovviamente ce l'hanno.

Regola pratica a livelli

  • Tutti i componenti che forniscono una funzionalità del business indipendente dall'applicazione può andare in un livello. Le funzioni del business indiepndenti dall'applicazione sono la "gestione del cliente" e la "gestione del prodotto" che si applica ad un intervallo di diverse applicazioni.
  • Tutti i componenti che forniscono funzioni tecniche, come la gestione dell'errore, l'autenticazione, la registrazione ed il controllo possono andare in un altro livello. Questi componenti sono indipendenti dal business e dall'applicazione. In alcuni casi, la prossimità di componenti tecnici e funzionali può richiedere che vengano posti in un livello comune. Queste sono decisioni strutturali e devono essere documentate come tali.
  • I componenti middleware come l'accodamento dei messaggi ed il software DBMS relazionale possono andare in un altro livello. Questi vengono denominati "Fabrica".

Esempio

La seguente è una vista a livelli di una SOA che mostra i livelli tipici (e soprattutto consigliati) per gli elementi diversi presenti in una soluzione.

Ora, in questo schema a livelli, è consigliabile semplicemente relizzare come i componenti risiedono, i componenti importanti vengono posti per l'esempio Noleggi auto nel livello dei componenti del servizio, come di seguito illustrato. Notare che si desidera  impiegare i livelli stretti nel modello e così viene utilizzata la composizione UML per contenere i componenti nel livello del componente del servizio ed esporre solo la funzione dei componenti del servizio utilizzando porte delegate dove la porta fornisce la stessa interfaccia del componente del servizio stesso.

Proprietà
Ricorrenze multiple
Attivato da evento
In corso
Facoltativo
Pianificato
Ripetibile
Ulteriori informazioni