Un aspetto chiave della SOA (Service-Oriented Architecture) è che i servizi siano componibili, il che significa che
verrà spesso composto un servizio nuovo come collaborazione tra un insieme di servizi esistenti. Per molti aspetti ciò
è vero per tecniche esistenti basate sul componente ed orientate all'oggetto, eccetto che per determinate capacità nel
middleware utilizzate per sviluppare soluzioni orientate al servizio, e consente l'esecuzione diretta di questa
collaborazioni mediante standard quali WS-BPEL (Business Process Execution Language for Web Services) (BPEL4WS,
WS-BPEL o semplicemente BPEL). E' l'abilità di comporre i servizi strutturalmente, cioè di definire le dipendenze
dell'utilizzo tra i servizi ed anche di comporre i servizi in modo comportamentale che rende un'architettura basata sul
servizio e la sua strategia IT attraenti per tante organizzazioni.
Sempre più organizzazioni stanno realizzando la necessità di aumentare l'agilità nell'abilità di rispondere ai
cambiamenti degli ambienti del business, alla pressione della globalizzazione, dei nuovi mercati e dei nuovi canali o
semplicemente della nuova concorrenza utilizzando una tecnologia più efficace. Queste organizzazioni guardano verso lo
sviluppo orientato al servizio e a soluzioni orientate al servizio come ad un modo per organizzare le proprie risorse
IT per indirizzare i requisiti correnti e fornire un'infrastruttura di funzioni allineate al business che è possibile
riutilizzare, riconfigurare e ricombinare efficacemente ed effettivamente per indirizzare i requisiti futuri.
Un'altro aspetto dell'abilità di comporre i servizi in questo modo è che fornisce un modo flessibile per incorporare le
risorse IT esistenti in nuove soluzioni allo stesso modo delle risorse più nuove. Ad esempio, le risorse esistenti,
anche quelle sviluppate per piattaforme mainframe e simili, possono essere composte come servizi con alcuni prodotti
del middleware ed integrate allo stesso modo come servizi nuovi sviluppati utilizzando J2EE, IBM WebSphere o Microsoft
.NET. Sfortunatamente, la maggior parte delle risorse esistenti non tende ad essere sviluppata con interfacce che
aderiscono a molte delle guide che si desidererebbe utilizzare per i servizi nuovi. Pertanto, è utile creare servizi
composti che non eseguono il wrapping di questi servizi esistenti, ma piuttosto forniscano interfacce diverse, più
allineate al business che bilancino le funzioni esistenti aggregando e creando una coreografia per fornire una capacità
di livello superiore.
Coreografia del servizio
Si ponga brevemente l'attenzione sul termine Coreografia. Questo termine viene utilizzato in molti prodotti del
middleware per indicare l'esecuzione gestita di alcuni script che indicano un flusso del processo in cui i partecipanti
sono servizi e le attività sono scambi di messaggi. In alcuni prodotti, viene utilizzato il termine
Orchestrazione. Mentre alcuni analisti e tecnici dell'industria descrivono le differenze nel significato delle
parole ed il modo in cui questi termini vengono utilizzati negli standard, per la maggior parte degli utenti le
differenze sono molto meno interessanti delle somiglianze.
In termini di standard, un modo comune di rappresentare la coreografia dei servizi web è di là da venire, dopo che la
maggior parte dei fornitori leader di middleware ha introdotto soluzioni esclusive. Lo standard dell'industria corrente
è WS-BPEL (Business Process Execution Language for Web Services) (BPEL4WS o BPEL). Per ulteriori informazioni su
BPEL4WS, consultare il sito OASIS
WSBPEL oppure il sito IBM
BPEL.
E' possibile sviluppare facilmente i servizi sulle funzioni fornite da altri servizi in una maniera ricorsiva, come
mostrato nel diagramma sottostante, dove i servizi sono in grado di identificare i servizi che utilizzano. In questo
caso, il servizio composto sta utilizzando la voce dell'ordine ed i servizi del gateway EDI (Electronic Data
Interchange). I servizi composti vengono spesso utilizzati dove la produzione solita delle capacità del servizio
identifica funzioni comuni che potrebbero essere fornite in più di una circostanza. Per alcuni servizi, dove il ruolo è
più che fornire capacità d'infrastruttura(come il servizio EDI sottostante), ciò è relativamente facile da
identificare. In altri casi, le collaborazioni dei servizio dettagliate identificheranno la necessità di suddividere un
servizio candidato in più di un servizio reale.
Un utilizzo importante dei servizi composti è nella fornitura di funzioni realizzate dalle risorse (legacy) esistenti.
Nella maggior parte dei casi, a tali capacità si accederà mediante i connettori o le API forniti dalla stessa risorsa e
verrà sviluppato un servizio nuovo che si basa su queste risorse per la logica. D'altra parte, per consentire al
componente aggregato di sviluppare più flessibilità e per consentire che la risorsa esistente possa essere estratta in
swapping in futuro per un'implementazione diversa, è possibile utilizzare una strategia alternativa. In questo caso,
ogni funzione esistente viene esposta come servizio indipendente, questi servizi vengono quindi utilizzati dal servizio
composto che consente sia alla risorsa esistente che ai servizi composti di evolvere indipendentemente.
Un altro utilizzo dei servizi composti si verifica dove l'insieme dei servizi reali bilanciati da un servizio composto
non vengono conosciuti in anticipo, Ad esempio, nel caso di un servizio di gestione ordini si potrebbe identificare la
necessità di separare la convalida ordini come insieme separato di servizi indipendenti delle regole del business in
modo che sia possibile aggiungere nuove regole in una data futura. Ciò è relativo all'argomento di mediazione del
servizio (consultare Linea guida: Mediazione del servizio).
Ovviamente un tale approccio ha dei vantaggi ma anche svantaggi. Se il servizio di basso livello può essere esposto
solo mediante i protocolli Internet come SOAP/HTTP, è probabilmente meno affidabile e le prestazioni sono inferiori se
vi si accede mediante un'API nativa o un connettore. Questi compromessi devono essere parte dell'insieme generale delle
decisioni strutturali prese e documentati come parte di ciascuna progettazione del servizio.
Per ulteriori informazioni sull'accesso alle risorse esistenti e sulla relazione tra i servizi candidati e quelli
reali, consultare l'Attività: Analisi asset esistente.
Nel modellamento del funzionamento dei servizi composti, si utilizza la nozione di Risorsa:Contratto del servizio durante le fasi di identificazione e
progettazione.
-
Durante l' Attività: Analisi asset esistente, la collaborazione viene utilizzata come tool
per descrivere i ruoli e le responsabilità dei servizi candidati. Ad esempio, potrebbe essere identificata la
necessità di una convalida ordini e di servizi di gestione ordini separati, ma come possono comunicare e di quali
informazioni sono responsabili? Una collaborazione del servizio viene utilizzata come un tool per descrivere questa
comunicazione ed è possibile identificare gli scambi di messaggi richiesti dal modello risultante.
-
Durante la Attività: Specifica del servizio, la collaborazione viene
utilizzata per definire il funzionamento concreto di un dato servizio o di un'operazione su di un servizio. Ad
esempio,l'esempio di convalida ordini precedente potrebbe essere descritto in modo concreto come un insieme di
messaggi inviati ad un insieme di servizi di regole di convalida.
In questo modo, si può vedere che una collaborazione del servizio nell'attività di progettazione del servizio è
direttamente correlata alla nozione di coreografia in termini di servizi web. Rappresenta una descrizione di flusso
esterna, configurabile che mette in sequenza un insieme di scambi di messaggi tra servizi. Nella maggior parte dei
middleware che implementano la coreografia, il flusso viene descritto in un linguaggio XML come BPEL. E' possibile
generare questo linguaggio dalla collaborazione del servizio descritta in Risorsa: Modello del servizio quando lo stesso flusso viene descritto
con le attività o le interazioni UML 2.0.
La collaborazione comprende una struttura composta che fornisce la vista dei collaboratori e le loro connessioni oltre
ad un funzionamento che indica i messaggi scambiati e la relativa sequenza. Il diagramma precedente che mostra un
Composite Provider ha illustrato una struttura composta, come la figura della convalida ordini sottostante.
Questa non è la struttura del provider di convalida stesso, ma la struttura della collaborazione del servizio, come
mostrato nel diagramma sottostante.
Specifica del funzionamento del servizio
Come su menzionato, è molto comune utilizzare le attività o le interazioni UML 2.0, in modo specifico diagrammi di
sequenza, per descrivere il flusso dei messaggi tra i servizi in una collaborazione. Il diagramma sottostante è un
diagramma di attività UML 2.0 che illustra il funzionamento del servizio di convalida ordini. Per un ordine fornito, il
servizio del registro di convalida fornisce un elenco di operazioni reali da richiamare.
E' bene notare che è possibile identificare questo funzionamento per un servizio completo oppure operazione per
operazione a seconda delle necessità del servizio. In questo caso, l'attività all'interno della collaborazione è
correlata all'operazione di convalida operazione (tramite l'associazione specifica/metodo in UML 2.0).
Specifica binding del servizio
Come precedentemente illustrato, i binding (protocolli fisici reale e codifiche messaggi) utilizzati per comunicare tra
i servizi vengono identificati come proprietà di Risorsa:Canale del servizio nella vista composizioni. I binding reali
utilizzato tra i servizi hanno un impatto significativo sui requisiti non funzionali come le prestazioni,
l'affidabilità e la sicurezza. Così, le scelte disponibili dovrebbero essere documentata con le conseguenze di ciascuna
identificata all'interno dell'architettura del sistema. Ad esempio, è possibile che un utilizzo di Risorsa: Partizione del servizio sia quello di rappresentare binding
disponibili o richiesti tra i servizi all'interno della partizione - essendo un requisito comune che i servizi
all'interno di alcune zone logiche comunichino utilizzando prestazioni elevate, ma non i binding di proprietà
mentre la comunicazioni con i servizi al di fuori della zona utilizzano prestazioni inferiori ma binding
standard.
Spesso si ci chiede se le capacità richieste per le prestazioni, l'affidabilità e la scalabilità dei servizi web
possano essere forniti da un'architettura basata su HTTP e SOAP, che sono inerentemente lenti ed inaffidabili. Prima di
tutto, è necessario definire "lento ed inaffidabile" quindi è necessario realizzare che anche i trasporti affidabili
utilizzano significati inaffidabili. Ad esempio, quando si utilizza SOAP su HTTP, è sempre possibile creare protocolli
a livello di applicazione ed operazioni che forniscono ulteriori capacità per le ricevute dei messaggi e la sicurezza.
Tuttavia, se si considera che determinati servizi comunicano all'interno dello stesso contesto di sicurezza o
applicazione, si potrebbe considerare di utilizzare significati diversi da HTTP.
E' molto importante realizzare che anche se i servizi web presentano un modello semplice ed un insieme di protocolli
semplici, flessibili, non si è costretti a queste scelte.Poiché WSDL dispone già di binding sia per SOAP che per HTTP
GET/PUT, è importante fornire ai richiedenti scelte supplementari. Ad esempio, un servizio singolo potrebbe esporre un
messaggio utilizzando un binding della coda messaggi ed un binding SOAP in modo che il richiedente possa scegliere il
binding più appropriato da utilizzare. In questo caso, il provider potrebbe anche fornire incentivi come un livello di
servizio garantito se viene utilizzata la coda messaggi ma nessun servizio garantisce per una conversazione HTTP.
Considerando l'esempio di convalida ordini precedente, è possibile vedere come vengono associati i binding a Risorsa: Canale del servizio e visualizzati sul diagramma
sottostante.
Quando si strutturano e progettano soluzioni su scala d'impresa, è necessario sempre ricordare i requisiti funzionali e
non funzionali ed accertarsi che siano fatti i giusti compromessi e prese le decisioni corrette per supportare gli
obiettivi del business.
|