Il modello del servizio cattura i dettagli di un insieme di servizi su iterazioni multiple, progressivamente elaborando
in dettaglio. Il modello del servizio potrebbe essere utilizzato per diversi livelli di ambito:
-
Lo sviluppo per ambito del servizio dove l'ambito del progetto è sviluppare il servizio
indipendentemente (quanto possibile) da altri servizi. Il modellamento comprenderebbe pertanto i casi di uso,
l'architettura, i modelli di implementazione e progettazione come una suddivisione verticale in base al servizio.
-
Lo sviluppo per ambito del progetto dove un progetto coinvolge la specifica di alcuni servizi in
supporto di un insieme di requisiti dell'applicazione, in questo caso l'ambito si espande al livello
dell'applicazione e potrebbe coinvolgere alcuni servizi. Vi è un insieme di modelli di livello di applicazione per
i casi di uso e l'architettura, quindi un insieme di modelli di implementazione e progettazione specifici del
servizio.
-
Lo sviluppo per ambito dell'impresa oppure la gestione del portafoglio servizi, dove l'ambito è
solo di riportare le specifiche di servizio e la partizione logica ma in un ambito generale dell'impresa. Ciò
consente ai progettisti ed agli architetti di prendere decisioni ad ampio raggio sull'intero portafoglio, ma si
richiedono progetti separati per sviluppare i modelli di implementazione e progettazione per i servizi identificati
(e le applicazioni client).
Il seguente diagramma dimostra gli aspetti chiave del modello del servizio, in modo astratto e la relazione tra loro e
le attività di identificazione, specifica e realizzazione.
Elementi di identificazione
La prima elaborazione inizia con un elenco di servizi candidati nel Portafoglio del servizio creati
durante l'Attività: Analisi dell'asset esistente, utilizzando tecniche come la decomposizione
del processo (consultare Concetto: Decomposizione del processo di business). Questi servizi sono suddivisi in
categorie in base alla loro area funzionale e alla tecnica utilizzata per identificarli. È importante notare che il
portafoglio del servizio descritto è un portafoglio specifico del progetto e contiene i servizi candidati identificati
utilizzando le diverse tecniche di analisi descritte in Attività: Analisi asset esistente. I servizi identificati in questa fase sono spesso
solo forniti con nome e descrizione funzionale possibile. Un documento semplice che contiene questo elenco di servizi
potrebbe spesso essere sufficiente, tuttavia, se l'approccio UML viene utilizzato, allora il portafoglio viene
conservato come raccolta di Risorsa: Specifica del servizio e potrebbe essere prodotto
utilizzando Report:
Portafoglio del servizio.
Appena possibile i servizi nell'elenco sono organizzati in una Gerarchia utilizzando uno schema di
classificazione funzionale (in genere basato su aree funzionali identificate durante la decomposizione del dominio).
Tale gerarchia dimostra uno schema di classificazione principale per i servizi - quella di una dipendenza di un
richiamo del processo e come tale è importante nel comprendere i rapporti tra i servizi identificati durante le
attività di decomposizione. Di nuovo, la rappresentazione della gerarchia può essere in un documento, un foglio di
lavoro, o un modello UML (nel qual caso si tende a utilizzare Risorsa: Partizione del servizio per modellare le aree
funzionali).
Notare che è inoltre possibile che il termine Portafoglio del servizio rappresenti il portafoglio del servizio
aziendale (come espresso in Concetto: Portafoglio del servizio) che ha un ciclo di vita oltre quello del
portafoglio specifico del progetto. Esiste piuttosto una relazione tra l'azienda ed il portafoglio del progetto come
illustrato nella figura di seguito riportata.
Elementi di specifica
Una delle prime fasi in Attività: Esecuzione specifica del servizio è di decidere su, e documentare
l'Esposizione dei servizio - cioè documentare quei servizi candidati che devono essere sviluppati ed
esposti come servizi true. Una tecnica chiave è Attività:
Applica test Litmus dei servizi che fornisce una guida specifica su come valutare i servizi per l'esposizione. In
termini della rappresentazione UML del modello del servizio, le specifiche del servizio sviluppate durante
l'identificazione sono segnate, utilizzando la proprietà di stato, per essere esposte e quindi dettagliate
ulteriormente nel modello. Durante l'analisi dei servizi è possibile iniziare a raggruppare i servizi in offerte
logiche e queste possono essere modellate in UML utilizzando Risorsa: Provider del servizio.
Nel documentare le specifiche del servizio è importante riportare tutte le dipendenze del servizio per diversi scopi -
per esempio i servizi con un alto numero di dipendenze sono più difficili da riutilizzare in diversi ambienti, mentre i
servizi con molti dipendenti indicano le funzioni principali. Le dipendenze del servizio possono essere riportate
testualmente, spesso in una forma tabulare (consultare Report: Dipendenze del servizio) o possono essere modellate utilizzando la
rappresentazione UML del modello del servizio. È inoltre importante realizzare che alcune dipendenze sono dovute ad una
comunicazione nel servizio e ci sono quindi dettagli specifici associati a questa dipendenza (protocolli di
comunicazione obbligatori, sicurezza, ecc) che possono essere documentati utilizzando il modello UML e in modo
specifico utilizzando Risorsa: Canale del servizio nei modelli di collaborazione.
Nel definire i servizi è comune riconoscere i servizi composti che esistono solo per fare la coreografia di un insieme
di più servizi a granularità semplice, questa Composizione e flusso dovrebbe descrivere il rapporto
tra i servizi compositi e composti e le dipendenze tra i servizi espressi dal flusso attraverso questi. Nella
rappresentazione UML questa composizione può essere ben descritta (Classi composte) e come il flusso (Attività,
Interazioni) e le tecniche sono descritte in Concetto: Composizione del servizio e coreografia.
È importante riportare i Requisiti non funzionali per i servizi (dove molti argomenti su riportati
incentrano l'attenzione sui requisiti più funzionali) e riportano quanti più dettagli è possibile sulla QoS, la
Politica e così via. In questa area è possibile esprimere i requisiti in un documento di testo più difficile che
esprimerli direttamente in UML, ma potrebbe essere più semplicemente espresso utilizzando un prodotto di gestione dei
requisiti. Quando si utilizza la rappresentazione UML del modello del servizio si consiglia di utilizzare il RUP
esistenteRisorsa: Documento architettura software e Risorsa: Specifiche supplementari per riportare i requisiti non
funzionali. Un aspetto dell'architettura della soluzione non funzionale riguarda laDistribuzione e la
disponibilità dei servizi che può essere documentata utilizzando il modello UML ed in particolare la Risorsa: Partizione del servizio eRisorsa: Gateway del servizio.
Ovviamente il dettaglio dei Messaggi del servizio è importante per lo sviluppo delle specifiche di
servizio utilizzabili. Questi messaggi possono essere derivati da modelli ad alto livello o possono essere direttamente
espressi in alcune forme specifiche della tecnologia (come ad esempio lo schema XML). Sia che i messaggi siano
descritti in un linguaggio di schema o nel modello UML queste definizioni di messaggio dovrebbero essere consapevoli
delle considerazioni chiave documentate in Attività:
Progetto del messaggio e nella corrispondenteLinea guida: Allegati del messaggio.
Mentre è vero che in una SOA ci si sforza per rendere i servizi senza stato, non è sempre possibile o anche preferibile
rendere questo un obiettivo fisso; l'argomento delle Decisioni di gestione dello stato viene fornito
per dare tempo al progettista per riflettere sui trade-off, il costo ed i ed i vantaggi della gestione dello stato nei
servizi. In supporto a queste decisioni l'argomento Linea guida: Gestione dello stato per i servizi fornisce esempi dei tipi di
stato che spesso devono essere conservati da un servizio.
Elementi di realizzazione
La realizzazione dei servizi riguarda principalmente sé stessa con tre aree, le decisioni che riguardano la
realizzazione effettiva dei servizi, l'identificazione dei sottosistemi e dei componenti per realizzare le specifiche
del servizio ed infine lo sviluppo di questi componenti.
Nel documentare le Decisioni di realizzazione è importante avere un base dettagliata e ragionevole per
la scelta dell'approccio di origine e sviluppo come descritto in Attività:
Decisioni di realizzazione del servizio del documento. Ancora, in un modo simile ai requisiti non funzionali è
spesso difficile esprimere queste decisioni (certamente in dettaglio) nella rappresentazione UML e così ci si aspetta
che le scelte eseguite per ogni servizio siano documentate separatamente.
|