Concetto: Composizione e coreografia del servizio
Questo concetto descrive le modalità con cui è possibile combinare i servizi per produrre strutture composte e collaborative che forniscano servizi di livello superiore orientati al business.
Relazioni
Descrizione principale

Introduzione

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.

Servizi come strutture composte

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.

Il diagramma viene descritto nel contenuto testuale.

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.

Collaborazioni del servizio

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.

Il diagramma viene descritto nel contenuto testuale.

Questa non è la struttura del provider di convalida stesso, ma la struttura della collaborazione del servizio, come mostrato nel diagramma sottostante.

Il diagramma viene descritto nel contenuto testuale.

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.

Il diagramma viene descritto nel contenuto testuale.

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.

Il diagramma viene descritto nel contenuto testuale.

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.