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.
Per ulteriori informazioni consultare l'Attività: Analisi asset esistente che presenta un insieme di tecniche dettagliate
che supportano questi approcci.
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).
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.
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.
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.
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.
|
|