Operazione: Specifica del servizio
Questa attività definisce e specifica il servizio e la struttura di una soluzione orientata al servizio in termini di collaborazioni degli elementi di progettazione contenuti e di sottosistemi/interfacce esterni.
Scopo
  • Definire i servizi e la struttura di una soluzione orientata al servizio in termini di collaborazioni di elementi di progettazione contenuti e sottosistemi/interfacce esterni.
  • Per analizzare il servizio per l'associazione e la variabilità (consultare Linea guida: Analisi delle variabilità).
  • Documentare la specifica dei servizi.
  • Determinare le dipendenze e la comunicazione tra i servizi.
Relazioni
Descrizione principale
Questa attività raffina l'insieme di Artefatto: Specifica del servizio identificate e qualificate durante l'Attività: Analisi asset esistente e fornisce un'altra struttura ed il dettaglio. Questo dettaglio a livello del progetto include l'interfaccia, il messaggio e la composizione dei servizi e l'assegnazione dei servizi ai provider.
Passi
Riutilizzare il portafoglio del servizio dell'impresa

Uno dei vantaggi spesso menzionati dell'utilizzo di una SOA (Service-Oriented Architecture) è l'abilità per i servizi di rappresentare le risorse riutilizzabili attraverso l'impresa, piuttosto che lo sviluppo di componenti solo all'interno dell'ambito di un'applicazione singola. Questa vista è importante poiché incarna la nozione che una SOA per IT davvero fornisce tutte le capacità dell'infrastruttura e del business come i servizi e che le applicazioni sviluppate dall'impresa riutilizzano le capacità dal portafoglio dei servizi.

Così, durante l'inizio di un progetto è importante sapere se si stanno sviluppando i servizi come parte del portafoglio o se si sta sviluppando la funzionalità dell'applicazione che utilizza questi servizi. Ad esempio, lo sviluppo di un sito del portale per gli utenti che accedono alle informazioni sul proprio conto è un progetto di sviluppo dell'applicazione che utilizza i servizi del portafoglio per le informazioni sull'utente, le informazioni sull'account, le offerte ed altro. In ogni caso, l'utilizzo del portafoglio ha diverse implicazioni; il progettista del servizio descrive la specifica del servizio e la pubblica come parte del portafoglio. Questa specifica consente agli sviluppatori dell'applicazione di comprendere i requisiti di interazione per il servizio. L'implementatore del servizio potrebbe ora utilizzare alcune specifiche di servizio per sviluppare una o più implementazioni del servizio, accertandosi che l'implementazione sia conforme alla specifica.   Il seguente diagramma dimostra la relazione tra il portafoglio del servizio aziendale e il portafoglio del progetto.

Per ulteriori informazioni, consultare il concetto Portafoglio servizi.

Utilizzo di meccanismi e modelli di progettazione

Utilizzare i modelli ed i meccanismi di progettazione adatti al servizio che si sta progettando e in accordo con le linee guida di progettazione del progetto. L'integrazione di un modello o meccanismo significa effettivamente eseguire molte delle successive fasi in questa attività, ma con il rispetto delle regole definite dal modello o meccanismo.

Si noti che i modelli ed i meccanismi vengono tipicamente integrati mentre evolve la progettazione e non solo durante la prima fase di questa attività. Inoltre, vengono frequentemente applicati a una serie di elementi del modello, piuttosto che soltanto ad un elemento singolo.

La trasformazione di un servizio nella sua realizzazione spesso riguarda un insieme di modelli, alcuni dei quali sono descritti nei Linea guida: Modelli del componente di servizio.

Descrizione dell'organizzazione logica della soluzione

E' frequentemente utile organizzare il pensiero in termini di viste diverse in un sistema e come i servizi in fase di sviluppo si inseriscono in tali viste. Nella definizione delle viste logiche dell'organizzazione, è importante che l'assegnazione di un servizio ad una vista non implichi la proprietà in un UML (Unified Modeling Language) senso o contenuto UML; cioè, che lo stesso servizio sarà in grado di partecipare a più viste logiche. Le viste dell'organizzazione sono valide al di fuori del modello davanti allo sviluppo del servizio o almeno della prima iterazione di queste viste, in modo che sia possibile assegnare i servizi alle viste come identificati. Nel modello del servizio, viene utilizzato una Partizione del servizio dell'elemento del modello per rappresentare un aspetto in una vista. E' possibile utilizzare tali partizioni per rappresentare qualsiasi prospettiva diversa della soluzione, ma non implicano la proprietà dei servizi ad esse assegnate. Per ulteriori informazioni consultare il concetto Partizionamento della soluzione.

E' inoltre possibile che queste partizioni, almeno quelle che rappresentano punti di vista chiave, risiedano in modelli separato dagli stessi servizi, consentendo ai modelli delle partizioni di evolvere indipendentemente.

Descrizione degli elementi del servizio

Come sempre accade quando si guarda al modellamento dei sistemi software, esiste una pluralità di punti di ingresso a qualsiasi modello, ad ogni rappresentazione che è possibile utilizzare e naturalmente molte metodologie che è possibile applicare. Nella maggior parte dei casi, tali punti di ingresso sono dovuti a questioni specifiche nei domini sia della tecnologia che del business che è necessario indirizzare. Tali questioni sono abbastanza importanti da agire come punti di inizio poiché il comprenderle ed il comprendere l'interazione tra di esse è critico per raggiungere il successo.

E' stato osservato che esiste un numero basso di tali questioni nello sviluppo delle soluzioni orientate al servizio; il diagramma seguente rappresenta queste questioni principali come attività specifiche di progettazione. Mentre è possibile che ciascuna di queste questioni agisca come punto di inizio per la progettazione del servizio e che ogni approccio tende ad essere ottimizzato per una determinata classi di servizi, è molto probabile che i progetti grandi utilizzeranno una combinazione di approcci nell'identificazione e nella progettazione dei servizi.

Il diagramma viene descritto nel contenuto testuale.

Per ulteriori informazioni consultare  l'Attività: Analisi asset esistente che presenta un insieme di tecniche dettagliate che supportano questi approcci.

Progettazione del messaggio

In questo approccio, l'attenzione di focalizza molto sul dominio del servizio. Tecniche come l'ingegneria del dominio o l'analisi e la progettazione orientate all'oggetto forniscono una vista interna all'sviluppo dei modelli astratti di dominio. Ciò produce in generale modelli altamente riutilizzabili per lo schema del messaggio. La progettazione del servizio è di solito un'attività secondaria sebbene alcune volte svolta in parallelo. Nell'EDI (Electronic Data Interchange), ad esempio, non c'è alcuna nozione reale di interfaccia del servizio poiché i sistemi EDI di solito dispongono di una casella di posta in arrivo e di una casella di posta in uscita singola, globale.

Un esempio di approccio simile potrebbe essere nell'arena business-to-business tradizionale, simboleggiata dalla standardizzazione EDI. In questo caso, il punto focale dell'attività di progettazione è lo sviluppo dello schema del messaggio concordato in alcune industrie o in un altro ambito e ritenuto rappresentativo dello schema di una classi di messaggi, ad esempio, e standard di industria come ACORD, SWIFT e RosettaNet (consultare Operazione: Progettazione del messaggio).

Progettazione del servizio

In questo approccio, il progettista si è preoccupato di esporre, come servizio o insieme di servizi, la funzionalità prevista del business o dell'applicazione. In questo caso, non è necessario conoscere come il client dei servizi sceglierà di agire con il servizio, ma è invece necessario conoscere il tipo di interazioni che questi client si aspetteranno. Pertanto, i messaggi tendono ad essere secondari e vengono sviluppato in risposta ai requisiti di un'operazione.

Un esempio di questo approccio potrebbero essere le API dei servizi Web presentate per impresa Amazon e eBay. Queste interfacce del servizio non impongono un processo business al client. Nella maggior parte dei casi non impongono le interfacce richieste al client, ma espongono le operazioni dei provider rispettivi del servizio in un modo chiaro ed intuitivo a sviluppatori di terza parte.

Come precedentemente menzionato, il modellamento centrale del servizio spesso si presta bene ad un approccio guidato ai casi d'uso comprendendo le necessità degli attori, i client esterni del servizio e fornendo operazioni come lo sfogliare i cataloghi, l'aggiunta di elementi al carrello degli acquisti, la verifica e così via.

Progettazione della collaborazione

In una progettazione di collaborazione, il punto focale è sulla collaborazione di due o più servizi; questa è una vista del processo dei servizi ed è relativa al modellamento del business tradizionale più di quanto non lo sia un'attività di sviluppo del software. In questo approccio, i servizi sono visti come ruoli di esecuzione nella collaborazione e la specifica di servizio è perciò l'insieme di responsabilità definite per il ruolo attraverso una o più collaborazioni.

E' possibile che un tale approccio venga riconosciuto da chi è coinvolto nello s viluppo dei PIP (Partner Interchange Processes) di RosettaNet oppure nello sviluppo degli standard OAGIS, sebbene le collaborazioni siano meno che complete in questi casi. E' possibile che un approccio simile sia comune all'interno di un business in termini di progettazione del processo business o di attività di integrazione del business in cui i componenti di un sistema IT vengono esposti come servizi.

In questo caso, si verifica di solito che sia possibile derivare la specifica di servizio direttamente dalla collaborazione, ma questo approccio tende a focalizzare l'attenzione meno sul contenuto del messaggio portando ad un requisito per un approccio ibrido per completezza.

Identificazione e cattura della politica

Politica è un termine ampio che viene qui utilizzato per coprire istruzioni o vincoli che è possibile considerare requisiti non funzionali. A livello di questo modello, è necessario realizzare che non si desidera che il modello venga popolato con istruzioni dettagliate sulle informazioni tecniche ma più realisticamente, si cattura l'intento del sistema riguardo a questi requisiti. Ad esempio, è necessario che un determinato messaggio venga trasmesso e rimanga privato e i dettagli personali dell'utente siano inclusi; si desidera catturare l'intento che il messaggio sia privato, non che si richiede una codifica dei dati utilizzando la codifica AES a 128 bit su un insieme di dati XML canonici con certificati X.509 per la codifica della chiave pubblica, principalmente perché pochissime persone sapranno cosa significa o saranno capaci di specificarlo in un modello a questo livello di astrazione (consultare Operazione: Identificazione dei modelli di sicurezza).

Il diagramma seguente mostra l'associazione della politica con gli elementi delModello del servizio. Si noti che è possibile che le informazioni sulla politica potrebbero essere allegate a informazioni diverse dai componenti della specifica di seguito identificati, sebbene questa sia l'area di interesse principale.

Il diagramma viene descritto nel contenuto testuale.

Per ulteriori informazioni sul modellamento della politica di sicurezza, consultare la white paper Modellamento obiettivi di sicurezza in SOA (Service-Oriented Architecture).

Dipendenze del servizio del modello

Un altro aspetto chiave di Artefatto: Modello del servizio che deve essere sviluppato durante la specifica è la cattura delle dipendenze tra i servizi. Come parte del modello del servizio, vengono catturate naturalmente alcune dipendenze. Tali dipendenze possono essere tanto ovvie quanto la relazione tra un servizio e la relativa specifica o più complesse, come la relazione logica tra due servizi indipendenti poiché entrambi implementano la stessa specifica. Queste dipendenze (descritte in Artefatto: Modello del servizio eProspetto: Dipendenze del servizio) sono importanti per comprendere la capacità di distribuire un servizio come unità autonoma e ne influenza l'evoluzione poiché le dipendenze che diventano limiti alla capacità del servizio di cambiare.

Le dipendenze del servizio descrivono i rapporti tra i servizi che si presentano nel contesto più ampio di come verranno utilizzati. Quando un servizio viene formato da una composizione di altri servizi, il servizio che lo compone dipende dai servizi composti. Quando i servizi vengono utilizzati nel contesto di un processo di business, esiste una dipendenza relativa al processo che si presenta dalla sequenza di fasi inerenti al processo di business che indica l'ordine nel quale i servizi verranno utilizzati.

  • Dipendenze funzionali/composte che derivano dalla composizione di più servizi.
    • Esempio: La prenotazione del veicolo dipende sulla verifica delle tariffe e dall'esecuzione della prenotazione per la sua funzionalità
  • Dipendenza temporale dove esiste una condizione pre- o post- o un requisiti di elaborazione che deve essere contato nelle composizioni o nelle coreografie.
    • Dipendenza di precondizione - ad esempio un altro richiamo del servizio deve essere eseguito correttamente prima che il richiamo corrente possono iniziare l'esecuzione.
    • Elaborazione dipendenza - ad esempio un altro richiamo del servizio viene richiesto per completare l'esecuzione del servizio corrente in modo corretto.
    • Dipendenza di postcondizione - questa viene visualizzata nei casi in cui un servizio richiede un altro richiamo del servizio dopo la sua esecuzione.

E' possibile che queste dipendenze spesso siano una parte di un processo che il client di un servizio deve affrontare nella scelta di riutilizzare un servizio, particolarmente se esistono più implementazioni tra cui scegliere.

I tipi di dipendenze/associazioni importanti nel modello del servizio, come elencate di seguito.

  • La relazione tra un servizio ed i provider del servizio che lo implementano.
  • La relazione tra un servizio e la specifica di servizio che implementa.
  • La relazione tra un servizio e tutte le specifiche di servizio che richiede.
  • La relazione tra un servizio e tutti i canali del servizio che lo collegano ad altri servizi e perciò al servizio all'altra parte del canale.
  • La relazione tra un servizio e tutte le partizioni del servizio in cui viene visualizzato il servizio.

E' perciò importante che tutte le specifiche di servizio siano complete, ma non solo rispetto alle operazioni ed ai messaggi che forniscono, ma anche alle dipendenze come le interfacce richieste per le operazioni di callback. Il prospetto Dipendenze del servizio fornisce una sintesi delle dipendenze importanti per il modello del servizio.

Composizione e flussi del servizio del modello

I servizi sono spesso compositi di altri servizi esistenti ed in alcuni casi la tecnologia come la coreografia può consentire ad un servizio di essere sviluppata senza codificare in modo esplicito come semplicemente una composizione di servizi esistenti. Durante la specifica, i servizi che riutilizzano gli elementi già nel portafoglio aziendale ed hanno documentato le proprie dipendenze su questi servizi, possono essere considerati come servizi misti la loro funzionalità si basa sulla funzione di un servizio misto e se non è possibile distribuire il servizio composto senza accedere ai servizi composti.

In alcuni framework SOA, un Livello di elaborazione business deve gestire solo i servizi misti coreografici dove i processi complessi vengono forniti come coreografie gestite di servizi a granularità più complessa. In questo caso il linguaggio di esecuzione del processo di business per i servizi Web (BPEL4WS) può essere utilizzato come strumento per lo sviluppo dei servizi misti, i flussi dei servizi e i livelli di processo del business.

Quindi, è possibile identificare due tipi di servizi misti:

  • Servizi composti cablati solidamente - questi sono caratterizzati da una bassa flessibilità, possiedono un flusso predefinito e un controllo di servizi dove il flusso ed il controllo non è esternalizzato. Questi tipi di servizi anno attributi QoS attrattivi come la prestazione.
  • Servizi composti cablati debolmente - questi sono caratterizzati da un'alta flessibilità, dove la composizione dei servizi nei processi di business viene compiuta da un flusso ed un controllo esternalizzato. La descrizione del flusso della composizione viene esternalizzata. Questo tipo composizione sfrutta gli strumenti di modellamento, la variabilità dinamica tramite le regole e la variabilità statica tramite il modellamento. La composizione utilizzando BPEL è un esempio.

Per ulteriori informazioni consultareConcetto: Composizione e coreografia del servizio eLinea guida: Realizzazione del servizio - I servizi BPEL in un'applicazione SOA per un esempio specifico del progetto.

Requisiti non funzionali del documento

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)
Requisiti di gestione dello stato del documento

Sebbene i servizi singoli siano considerati senza stato, le composizioni spesso hanno requisiti per conservare le informazioni di stato nel richiamo dei servizi composti. Il coreografo dei servizi è spesso responsabile della gestione dello stato. In alternativa, un componente che implementa e realizza più servizi correlati o operazioni sui servizi potrebbe aver bisogno di conservare lo stato tra i richiami per motivi di prestazione.

La gestione dello stato in un ambiente SOA può essere considerata divisa in tre categorie principali:

  • Stato transazione - dove un servizio ha una transazione aperta durante una conversazione con un client.
  • Stato sicurezza - dove un contesto di sicurezza viene conservato durante una conversazione con un client.
  • Stato funzionale - dove la conversazione con un client riguarda un numero di operazioni correlate.

Per ulteriori informazioni fare riferimento a Linea guida: Gestione dello stato per i servizi.

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