L'utilizzo di una SOA (Service-Oriented Architecture) fornisce l'opportunità di scegliere Artefatto: Provider del servizio non solo in base alla funzionalità
che fornisce, ma anche sulle QoS (Qualities of Service) che può garantire. Uno dei motivi per cambiare un
provider del servizio potrebbe essere spesso il risultato di una modifica nei requisiti non funzionali che necessitano
di un nuovo livello di QoS non al momento supportato da un provider esistente. Potrebbe inoltre risultare dalla
degradazione nella QoS prevista dal consumatore del servizio. Una SOA (Service-Oriented Architecture) consente questa
agilità ad un costo più basso, in generale, rispetto agli stili strutturali.
QoS può essere visualizzato da due prospettive: quella del Provider e quella del Consumatore. Il Provider del
servizio garantisce di fornire e mantenere una qualità di servizi per ogni servizio o gruppo dei servizi. Il
consumatore del servizio, d'altro lato, acquista la QoS desiderata e scegli un provider in base alla QoS. È inoltre
importante notare che nelle impostazioni commerciali dove il consumatore ed il provider entrano in un contratto legale
sull'utilizzo del servizio, queste garanzie della qualità del servizio sono raffinate negli Accordi del livello di
servizio, frequentemente con multe associate a mancanze da parte del provider nel rispettare tale accordi.
Quindi, è molto importante specificare chiaramente i requisiti non funzionali richiesti dal consumatore (ad esempio, il
costo della transazione, la prestazione, la disponibilità, la sicurezza, ecc...) per un servizio o un insieme di
servizi. In questa attività della specifica del servizio, vengono identificati i requisiti non funzionali per la QoS
desiderata. I requisiti non funzionali verranno utilizzati per eseguire il commit delle risorse per i componenti del
servizio che offrono i servizi e per fondare la realizzazione e la manutenzione dei componenti del servizio che
assicurano la distribuzione della QoS nel tempo. Le decisioni strutturali chiave devono essere eseguite per assicurare
che sia raggiunta la qualità promessa del servizio basato sui requisiti non funzionali.
Il modo in cui sono collegati i requisiti non funzionali alla Artefatto: Specifica del servizio non è definito in questa
guida. Non ci sono limiti impostati su cosa costituisce tale requisiti, ovviamente QoS, la protezione è stata già
menzionata, e gli esempi potrebbero includere:
-
La disponibilità (ad esempio il tempo che passa tra un errore e l'altro)
-
Finestra operativa (esiste un momento in cui non si prevede che il servizio venga utilizzato?)
-
Tempo di risposta (quanto velocemente il servizio deve rispondere ad una richiesta)
-
Velocità di immissione picco (quante richieste per il servizio possono arrivare per unità di
tempo come per secondo, minuto, per ora)
|