Prodotto di lavoro: Modello del servizio
Il modello del servizio è un modello degli elementi principali di una SOA (Service Oriented Architecture). Il modello del servizio viene utilizzato come input essenziale per le attività nell'implementazione e nei test.
Scopo

Il modello del servizio è un'astrazione dei servizi IT implementati all'interno di un'impresa e che supporta lo sviluppo di una o più soluzioni orientate al servizio. Viene utilizzato per concepire e documentare la progettazione dei servizi software. E' un prodotto di lavoro completo, composito che comprende tutti i servizi, i provider, le specifiche, le partizioni, i messaggi, le collaborazioni e le relazioni tra di essi. È necessario:

  • Identificare i servizi candidati e riportare le decisioni relative a quali servizi verranno effettivamente esposti
  • Specificare il contratto tra il provider del servizio ed il consumatore dei servizi
  • Associare i servizi con i componenti necessari per realizzare questi servizi
Relazioni
RuoliResponsabile: Modificato da:
Input inObbligatorio: Facoltativo:
  • Nessuno
Esterno:
  • Nessuno
Output di
Descrizione
Breve profilo

Il modello del servizio è spesso una raccolta eterogenea di asset fisici, inclusi i modelli UML, i documenti e possibilmente le voci in uno strumento di gestione dei requisiti. Tuttavia, il modello del servizio deve contenere i seguenti elementi logici (consultare la descrizione principale).

  • Portafoglio servizi
  • Gerarchia del servizio
  • Esposizione del servizio
  • Dipendenze del servizio
  • Composizione e flusso del servizio
  • Requisiti non fondamentali del servizio
  • Messaggi del servizio
  • Decisioni di gestione dello stato
  • Decisioni di realizzazione
Descrizione principale

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.

Proprietà
Facoltativo
PianificatoYes
Illustrazioni
Personalizzazione
Impatto della non disponibilitàSenza questo prodotto sarebbe difficile definire correttamente i servizi e specificare i componenti necessari per realizzarli.  Questo potrebbe portare a delle interruzioni nel portafoglio del servizio, nella proliferazione di servizi non necessari, in incoerenze su come i servizi sono esposti e in incoerenze nella progettazione di componenti necessari per realizzare i servizi.
Motivo della non necessitàQuesto prodotto non è necessario se non bisogna esternalizzare le descrizioni del servizio al limite del margine organizzativo significativo (ad esempio al limite della principale linea di business all'interno dell'impresa, o al limite dell'impresa).
Opzioni di rappresentazione

Il Modello del servizio ha un prodotto di lavoro ampio e di solito è sviluppato utilizzando un numero di tecniche; ad esempio i modelli UML sono utilizzati per descrivere gli elementi del servizio, tuttavia la presentazione del prodotto di lavoro potrebbe essere un documento che contiene i diagrammi dal modello UML. Il livello al quale qualsiasi particolare progetto si affida ai modelli UML dipende dalle abilità e il background dello staff interessato e anche dalle aspettative degli stakeholder del progetto. In generale si consiglia di sviluppare quanta più parte del modello è possibile utilizzando la rappresentazione UML ed integrandola con un ulteriore contenuto (specialmente il testo descrittivo) e presentandone la forma finale come un documento.

Per la rappresentazione UML consultare Esempio: Modello del servizio in UML.

Per la rappresentazione della documentazione consultare Esempio: Modello del servizio in Word.

Ulteriori informazioni