Il mondo SOA ha raggiunto oramai con gli anni un certo grado di maturità, provato dal supporto dei principi di design. Come tale, anche in ambito SOA esistono pattern specifici per la risoluzione di problematiche tipiche nella messa in atto di quest’architettura. Si va da patterns che forniscono tecniche per validare il contratto di un servizio a strategie di design che aiutano a strutturare un insieme di servizi per una enterprise. Una enterprise orientata ai servizi ha un insieme specifico di obiettivi strategici e per realizzarli occorre fare in modo che il design delle soluzioni verta spesso ai servizi. Quando si realizza una SOA si definisce non solo un ambiente che è favorevole all’individuazione di soluzioni effettivamente service-oriented, ma anche una governante che supporta l’evoluzione dei servizi all’interno della stessa enterprise.

Design pattern SOA e tipologie di architettura

Definiamo “pattern” un modello, un motivo ricorrente che rappresenta una soluzione architetturale a problemi tipici di design. Quando ci approcciamo all’argomento SOA, con il nome “design pattern SOA” si vuole fornire una soluzione alle possibili problematiche riscontrabili nella realizzazione di un’architettura service-oriented.

I pattern SOA che verranno introdotti in questo articolo e sviluppati nel corso della serie faranno da supporto nel momento in cui si vuole definire una delle seguenti architetture possibili in ambito SOA:

• architettura del servizio: architettura del singolo servizio;
• architettura della composizione di servizi: architettura di un set di servizi assemblati in una service composition;
• architettura dell’inventario dei servizi: architettura per  una collezione di servizi correlati per una certa enterprise;
• architettura enterprise service-oriented:  architettura della stessa enterprise orientata ai servizi.

Dal momento che, nella realizzazione di una delle suddette architetture, saranno riscontrabili problematiche tipiche di design, a supporto di queste verranno introdotte le rispettive famiglie di pattern per proporre soluzioni standard.

Come illustra la figura 1, una enterprise service-oriented si basa sui seguenti concetti base:

• il servizio;
• l’inventario di servizi;
• la composizione di servizi.

Figura 1 – Elementi base di una service-oriented enterprise.

Dal momento che l’obiettivo è quello di arrivare a una enterprise service-oriented con un’architettura a supporto, occorrerà pensare anche all’architettura dei rispettivi elementi che la costituiscono, come precedentemente indicati. Dunque, a supporto della realizzazione di ciascun tipo di architettura (di servizio, di inventario e di composizione di servizi) ci sarà la rispettiva famiglia di pattern SOA. 

Prima di entrare nello specifico delle famiglie di pattern, chiariamo cosa prevede ciascuna architettura in ambito SOA.

Architettura del servizio

Col termine architettura del servizio ci si riferisce alla progettazione di un servizio in ambito SOA.

Questo tipo di architettura è paragonabile a quella per la definizione di un componente generico, con la differenza che quella relativa a un servizio si pone anche gli obiettivi di aumentarne l’affidabilità, la scalabilità e soprattutto l’autonomia.

La definizione di questo tipo di architettura precede di tenere in considerazione i seguenti aspetti:

• funzionalità del servizio ed esposizione;
• interazioni.

Per rispondere all’esposizione delle funzionalità e alla loro realizzazione, occorre definire il contratto del servizio e le rispettive operations.

La definizione del contratto è uno dei primi step previsti per la realizzazione dell’architettura del servizio: gli conferisce una identità pubblica e definisce il set delle funzionalità previste per un determinato scope. Ovviamente la definizione del contratto deve rispondere ai requisiti dettati dalle specifiche esigenze di quel dominio.

Le funzionalità offerte dal servizio sono implementate mediante le operations. Ciascuna operation incapsula parte di logica del servizio, e la scelta di implementarla in maniera custom per lo specifico servizio o renderla modulare dipende dal grado di “generalizzazione” della stessa operation. Cioè, se all’interno della stessa enterprise esistono più servizi che possono sfruttare la stessa operation, quest’ultima può essere candidata a essere esposta come servizio.

Molto spesso le operation che hanno della logica di accesso alle risorse di back-end tendono a diventare un servizio usato e invocato da altri.

Un altro aspetto del design del servizio, correlato all’infrastruttura, sono le dipendenze che il servizio può avere su degli “agenti” del servizio stesso. Questi ultimi sono degli intermediari, capaci di intercettare in maniera trasparente i messaggi che arrivano verso il servizio.

Figura 2 – Agenti di un servizio.

Come illustra la figura 2, possono esserci molti agenti del servizio che si occupano di processare i dati che arrivano verso il servizio, come il decription, l’encription, etc.; altri invece sono specifici del flusso dei dati appena all’ingresso e all’uscita del servizio, come l’header processing.

Esempi di questi agenti sono alla base del pattern Service Agent: si tratta di quei servizi che si basano sulla logica event-driven e che come tali non devono essere invocati esplicitamente. Ma essi vengono realizzati di modo da rispondere automaticamente a predefinite condizioni, senza invocazioni possibili con esposizione di contratto.

Architettura della composizione di servizi

L’architettura di una composizione di servizi supporta la possibilità di avere una serie di servizi indipendenti che possono essere combinati per formarne una composizione, soluzione funzionale che permette di automatizzare molti task più complessi.

Nella maggior parte dei casi, l’architettura dell’ applicazione per un sistema distribuito include le definizioni architetturali di ciascun suo componente, di modo che questa architettura comprenda quelle di tutti i suoi servizi che vi partecipano.

È da precisare che all’interno di una composizione, i servizi possono assumere il ruolo di:

• Controller della composizione
• Membri della composizione

Il controller della composizione rappresenta un servizio in cui una delle sue operation è definita come la composizione della logica di operazioni degli altri servizi.

Figura 3 – Controller e membri di una composizione di servizi.

I membri di una composizione sono invece i servizi che partecipano alla composizione e sono coordinati da un altro servizio, il controller.

Una composizione di servizi sarà inoltre dipendente dalle caratteristiche di gestione dell’ambiente che lo ospita. Tra queste caratteristiche vi sono la sicurezza, la gestione delle transazioni, l’affidabilità dei messaggi e altre estensioni di infrastruttura, come il supporto per il routing dei messaggi.

Architettura dell’inventario dei servizi

Vediamo da dove deriva il termine “inventario di servizi”. Quando si realizzano servizi facenti parte di un progetto SOA, c’è la tendenza a svilupparli come programmi flessibili e robusti, di modo che possano essere riusabili e componibili. Il design dei servizi SOA è stato spesso influenzato dalle tecniche di design dei prodotti commerciali, portando un servizio a essere come una black-box e dunque riconducibile a un prodotto software.

Ispirati dalla terminologia commerciale, una collezione di servizi per un dato segmento di una enterprise è definito come inventario di servizi. E in maniera analoga, l’architettura tecnologica che la supporta viene definita come architettura dell’inventario dei servizi.

Quando un’organizzazione invece possiede più di un inventario di servizi, significa che possiede un inventario di servizi di dominio. Gli inventari sono spesso realizzati tramite processi top-down e l’applicazione dei principi di design service-oriented porta a definire un alto grado di interoperabilità tra i servizi. Questo supporta le combinazioni di composizioni di servizi in risposta ai cambiamenti di requisiti business.

Ci possiamo anche chiedere qual è la differenza tra un inventario e un catalogo di servizi. Nello stesso modo in cui un inventario di prodotti viene illustrato e documentato mediante il catalogo dei prodotti, così anche l’inventario dei servizi viene documentato col rispettivo catalogo.

Vediamo quali sono i vantaggi nell’avere un inventario di servizi definiti per una certa enterprise. Molto spesso i servizi vengono pensati e realizzati per ogni singolo processo business, col rischio di creare delle ridondanze di servizi perche’ magari la stessa funzionalità verrà usata da un secondo processo business. Il risultato è quello di avere una serie di applicazioni silos, costitute dal processo business e dal proprio insieme di servizi:

Figura 4 – Applicazioni silos.

Con un inventario di servizi, si avrà una collezione di servizi standardizzati e governati in maniera indipendente, il cui scope va oltre la realizzazione del singolo processo business e si estende a più processi business:

Figura 5 – Inventario di servizi.

In questo modo, se più processi business devono far uso dello stesso servizio, non si avranno più le possibili ridondanze tipiche delle applicazioni silos.

Da un punto di vista di design dell’enterprise, l’inventario può rappresentare il confine per l’implementazione di un architettura. Questo significa che, poiche’ i servizi all’interno di un inventario sono standardizzati, così sono allora le tecnologie e le estensioni utilizzate a supporto dall’architettura.

Architettura enterprise service-oriented

Questa forma di architettura mette insieme le architetture dei servizi, della composizione di servizi, e dell’inventario che risiedono dentro una specifica IT enterprise. Questo tipo di architettura può essere paragonata a uno stile architetturale tradizionale, solo che gli enviroments dell’enterprise sono service-oriented.

Negli environments dove gli sforzi di standardizzazione non sono stati soddisfacenti, un’architettura service-oriented servirà a sopperire i difetti di design che possono esistere. In aggiunta, questo tipo di architettura può definire degli standard di design e delle convenzioni per tutti i servizi, le composizioni e le implementazioni necessarie a soddisfarli.

Famiglie di Pattern SOA

Una volta che sono stati introdotti e chiariti quali sono i possibili stili architetturali SOA, vediamo le relative famiglie di pattern, per iniziare a sostenere la standardizzazione di soluzioni a tipiche problematiche riscontrabili nella definizione di ciascuna di queste quattro tipologie di architetture.

Pattern di design del servizio

Questa famiglia di patterns sarà utile nel momento in cui occorre definire l’architettura di un servizio. Alla base del design di un servizio, la teoria della “separazione delle problematiche ” necessita di essere applicata come parte di un processo dove un problema più grande viene scomposto in altri più piccoli, di modo che si possa identificare meglio la soluzione.

Per fare ciò, sono emersi una serie di pattern alla base di un processo di design. Si individueranno per questa famiglia le tipologie principali di pattern come la scomposizione funzionale e l’incapsulamento del servizio, utili per definire quale tipo di logica deve appartenere in un servizio. Un pattern chiave frequentemente applicato nelle fasi iniziali del design è il Service Facade che consente di separare il contratto del servizio dalla rispettiva logica d’implementazione.

Pattern dell’inventario dei servizi

In questa famiglia rientrano tutti quei pattern per la definizione di un’architettura dell’inventario. Per esempio, l’obiettivo del pattern dell’Enterprise è quello di definire un insieme di servizi a livello enterprise, col risultato finale di consentire la realizzazione di servizi consistenti e compatibili.

Esso si dovrebbe inoltre basare sul fatto che tutti i servizi vengano realizzati dallo stesso gruppo di lavoro, obiettivo centralizzato dalla governance. Tutto ciò è un po’ idealistico, specialmente se si tratta di grandi organizzazioni, il che porterebbe ad avere problemi sui vincoli temporali e sul budget, evitabili con l’applicazione di questo pattern.

Vi sono pattern dedicati su come deve essere strutturato l’inventario dei servizi; questi sono applicati per assicurare una struttura consistente e a supporto della soa-oriented. Per esempio, i servizi riusabili che centralizzano la logica sono supportati dal pattern di Normalizzazione del servizio, che riduce la sovrapposizione funzionale possibile tra più servizi.

A supporto della struttura dell’inventario ci sono anche alcuni pattern che aiutano a standardizzare il servizio all’interno dei limiti dell’inventario, per far sì che lo stesso sia interoperabile e componibile, mentre altri (come la Centralizzazione del processo e delle regole) possono essere usati per far leva sulle piattaforme che supportano la gestione della logica dei processi e delle regole business.

Patterns per la composizione di servizi

Una composizione di servizi stabilisce la sua architettura sulla base di quelle dei singoli servizi che ne fanno parte, introducendo pattern addizionali che si focalizzano soprattutto sulla comunicazione inter-service e la gestione a runtime delle attività. Dal momento che i servizi vengono, per la maggior parte dei casi, realizzati come dei web services, molti design pattern si basano sul messagging asincrono.

Per esempio, nel corso della serie, verranno trattati i pattern come l’Asynchronous Queuing che stabilisce una coda centrale per consentire ai servizi di superare problemi di disponibilità e aumentare lo scambio asincrono dei dati.

Il pattern Event-Driven Messaging consente la funzionalità publish e subscribe tra i servizi su periodi di tempo più lunghi, l’Intermediate Routing consente invece un routing dei messaggi più intelligente basato sugli agenti, e può aiutare ad incrementare la scalabilità dei servizi e la loro componibilità. Il pattern che più consente e supporta l’hosting di servizi, il messaging e l’esecuzione di composizioni di servizi è l’Enterprise Service Bus e si vedrà che questo pattern è in realtà la fusione di diversi pattern.

Conclusioni

Questo primo articolo ha messo in evidenza le principali famiglie di pattern SOA a supporto di una delle tipologie di architetture che si intende affrontare. Ovviamente la realizzazione di un’architettura non esclude l’altra, anzi sono indispensabili per arrivare alla piena realizzazione di una enterprise service-oriented.

Gli articoli successivi tratteranno nello specifico ogni famiglia, mettendo in evidenza e spiegando i principali pattern che le costituiscono, indicando la problematica per la quale vengono applicati e come riescono a risolverla.