Introduzione
Nel precedente numero si sono introdotti i concetti principali di SOA (vedere [MOKA_SOA_I]). SOA è uno stile architetturale basato sul concetto di servizio, e definisce una modalità di costruzione delle applicazioni come composizione di servizi con caratteristiche ben specifiche orientate al riutilizzo e all'integrazione.
Un'azienda che decide di evolvere il proprio sistema informativo verso una architettura SOA deve fare diverse scelte e fronteggiare numerose sfide. SOA, come già detto, non è una rivoluzione, ma bensì un'evoluzione architetturale. Tale evoluzione investe tutti gli aspetti associati alla definizione di un Information System: architetturali, metodologici, di processo, organizzativi, tecnologici e … culturali! In questo articolo ci concentreremo sugli aspetti prettamente metodologici parlando delle nuove metodologie di analisi e design che, partendo dai concetti di architetture a servizi, definiscono pratiche orientate all'analisi e al design a cui ci si riferisce spesso con il termine "Service Oriented Analysis and Design" (SOAD).

SOAD
Cosa implica l'adozione di SOA da un punto di vista metodologico? Servono realmente delle metodologie nuove rispetto a quelle che abbiamo già a disposizione? La risposta è … si, dato che le metodologie più comunemente diffuse non sono incentrate sui servizi, bensì sui componenti ed i processi. Nel caso di SOA abbiamo invece bisogno di metodologie basate sui servizi. Parliamo quindi di Service-Oriented analysis and design (SOAD), che è un approccio alla modellazione e allo sviluppo dei servizi basato sul paradigma service-oriented. E' importante capire che SOAD si basa su metodologie preesistenti come OOAD e BPM (vedere [OOAD] e [BPM]), aggiugendo il paradigma architetturale di SOA. Storicamente, il termine SOAD è stato introdotto da IBM (vedere [SOAD]) per indicare un insieme di best practices metodologiche basate sui concetti di SOA. E' un approccio olistico, nel senso che ha come obiettivo la modellazione di un sistema nella sua completezza; in SOAD si cerca di eliminare i limiti che provengono da altre tecniche di modellazione di fatto in qualche modo comprendendole.
SOA prevede la definizione esplicita di un nuovo layer, costituito da servizi avente delle ben rigorose caratteristiche architetturali (coarse-grained, loosely coupled, consistenti, ….) che si interpone tra il Process Layer ed il Component Layer.

Figura 1: Il Service Layer

Il problema da questo punto di vista diventa la definizione e la descrizione dei servizi, che deve essere effettuata e normata attraverso opportuni meccanismi e procedimenti metodologici.

L'ambizione dei servizi (di essere un componente riusabile con un forte significato di business) "forza" l'analista a partire da un punto di vista orientato al processo (cioè con lo sguardo di chi usa il servizio).
Un buon punto di partenza per l'analisi è la modellazione del processo: infatti possiamo pensare un processo di business come la composizione di servizi. D'altra parte un servizio è a sua volta una composizione di operazioni che vengono richieste al livello sottostante di componenti. In pratica possiamo pensare di decomporre un sistema verticalmente (rispetto ai layer architetturali) in processi, servizi, operazioni e componenti.

Figura 2: Processi, servizi, operazioni e componenti

Possiamo identificare il Service Layer come un nuovo strato che agisce da collante fra il mondo funzionale ed i componenti software di più basso livello.
I servizi diventano quindi un'astrazione del Component Layer fornendo una visione di business al Process layer.
E' importante infatti notare che uno dei vantaggi importanti di SOA è il riuscire a esprimere attraverso il concetto di servizio un'entità che è facilmente comprensibile dagli esperti funzionali (grazie al grado di astrazione espresso) e direttamente "mappabile" in oggetti software concreti, semplificando molto la fase di design.
Nonostante questo, esistono delle difficoltà culturali: occorre comunque adeguare il modo di pensare un'applicazione.
Tipicamente gli analisti funzionali iniziano ad eseguire la loro analisi dall'interfaccia grafica (spesso chiamata mappa) che l'utente si troverà di fronte. In questa maniera il layer di business (e quindi in questo caso i servizi) viene modellato in modo da rispondere perfettamente alle necessità dell'applicazione di front-end, incernierandosi con le mappe e le navigazioni sulle mappe previste dagli analisti. Il grado di riusabilità di servizi ottenuti in questo modo è piuttosto basso, anzi in generale si può affermare che solo l'applicazione di front-end sarà in grado di utilizzare i servizi essendo stati creati ad hoc per essa.
Il passo richiesto agli analisti funzionali è dunque quello di svincolarsi da questo modo di procedere e pensare a servizi riusabili cercando di prevedere le necessità di integrazione future.
Questo cambio culturale richiede all'analista di partire non più dalle mappe, ma cominciare a ragionare sull'interfaccia dei servizi e sulle operazioni che deve fornire.
Quello che viene quindi definito dalla sinergia dell'analista e dell'architetto è un'interfaccia chiara e documentata che rappresenta il contratto dei servizi che sono il deliverable fondamentale della fase di analisi di un servizio.

Il problema culturale del cambiamento indotto da SOA si riflette quindi a tutti i livelli: i CEO ed i Business Analyst devono condividere maggiormente le informazioni della "mission", gli analisti funzionali non devono più ragionare a mappe, gli architetti devono disegnare servizi con la giusta granularità di business e gli sviluppatori evolversi rispetto agli approcci tradizionali.

Figura 3: Come cambia l'organizzazione con SOA

SOAD: approccio Top-Down, Bottom-Up e Meet-In-The-Middle

Abbiamo detto che l'obiettivo è la scomposizione del sistema in processi/servizi/operazioni/componenti...ma da che punto si può partire per effettuare questa suddivisione? Per prima cosa è necessario identificare che approccio metodologico utilizzare.
Partire dai processi di business significa avere un approccio Top-Down. Si parte dall'analisi del processo per poi identificare i servizi attraverso dei raffinamenti successivi. Nei casi in cui si deve integrare SOA con applicazioni già sviluppate in precedenza, l'identificazione dei servizi seguirà una metodologia Meet-In-The-Middle. Parto dalla situazione già presente e aggiungo il grado di astrazione necessario (i concetti di SOA) all'integrazione dei processi che sto sviluppando.
L'ultimo approccio metodologico possibile (Bottom-Up) prevede di partire dalla definizione dei componenti per poi disegnare i servizi: questo tipo di ragionamento può sembrare molto pratico ma difetta del grado di astrazione necessario per la definizione di servizi realmente riusabili e non è quindi consigliabile rispetto agli altri.
Perché ben tre differenti approcci? Questo dipende dalla tipologia del progetto. Dovendo sviluppare una applicazione da zero, l'approccio più corretto è quello top-down. Il cavallo (attuale) di battaglia di SOA è pero riusare il software esistente riorganizzandolo meglio. Questo prevede quindi di operare su applicazioni già esistenti e che si vogliono conservare per svariate ragioni (es: salvaguardare gli investimenti pregressi, applicazioni obsolete ma ormai consolidate, budget, …). In queste situazioni è consigliabile l'approccio Meet-In-The-Middle.

Approccio Top-Dowm
Supponendo di essere nella situazione di dovere realizzare un sistema a servizi "from scratch", è opportuno sfruttare tutte le possibilità di astrazione che SOA ci fornisce adottando un approccio Top-Down.
Cominciamo con il dire che occorre suddividere il processo globale in due fasi: la fase di analisi, che deve definire un elenco di servizi "candidati" e la fase di design che deve delineare in maniera netta e precisa i servizi e le relazioni di essi con i processi e i componenti.
Ma quali sono in concreto gli obiettivi che un'analisi SOAD-compliant si deve porre? Deve definire i "candidati" a diventare i servizi SOA-compliant la cui composizione premetta la costruzione del sistema. Per essere più precisi possiamo dire che gli obiettivi della fase di analisi sono:

• Definizione di un insieme preliminare di candidati per le operazioni dei servizi
  
• Raggruppamento dei candidati per le operazioni in contesti logici (questi contesti rappresentano dei candidati a servizi)
  
• Definizione dei confini dei servizi preliminari per evitare sovrapposizione
  
• Identificazione della logica incapsulata con il potenziale di riuso
  
• Verifica che la logica incapsulata nel servizio sia appropriata per l'uso che si intende
  
• Definizione di un modello di composizione preliminare dei servizi

Questa analisi deve poi essere raffinati nella fase di design in cui i servizi e l'orchestrazione tra essi vengono definiti in maniera precisa, mappando i servizi preliminari identificati in servizi veri e propri.
Sempre nella fase di design verranno identificati in maniera corretta i punti di collaborazione e di orchestrazione per la composizione dei processi che devono costruire l'applicazione.
Quindi l'obiettivo concreto del design dettagliato è, partendo dal modello dei servizi candidati definito in analisi, produrre le interfacce dei servizi in maniera precisa.
L'output è quindi il Service Contract che verrà poi "tradotto" coerentemente con la tecnologia che si è deciso di adottare (es: WSDL per i Web Services, IDL per CORBA, …).
Riassumendo si identificano due momenti: una fase di analisi in cui, a partire dai processi, si identificano una serie di candidati ai servizi e un modello di composizione preliminare degli stessi, e una fase di design in cui questi servizi vengono effettivamente disegnati.
E' importante avere ben presenti durante tutto il processo i principi architetturali che sono al centro di un'architettura a servizi (riuso, autonomia, mancanza di stato conversazionale, ecc...).

Figura 4: Approccio Top-Down

Definizione dei servizi: analisi
L'obiettivo è la modellazione dei candidati ai servizi. Per l' analisi un servizio candidato è un insieme di operazioni raggruppate in un contesto logico. A livello di Design un candidato ad essere un servizio è tale in quanto la definizione del servizio vera e propria può essere effettuata solo a tale livello. Come si possono identificare questi insiemi?
Conviene individuare inizialmente un punto di partenza da cui ragionare per cominciare a definire i servizi con il giusto grado di astrazione. In generale possiamo percorrere due strade (che non sono in alternativa).
La prima strada parte dalla considerazione che in genere è molto utile pensare che ogni organizzazione può essere rappresentata come un insieme di operazioni composti in una logica di workflow. Queste operazioni possono essere il punto di partenza per l'analisi; avendo quindi la descrizione dei processi possiamo cominciare a identificare dei candidati ai servizi:

Figura 5: Dal workflow ai servizi

L'altra strada percorribile è la modellazione delle entità primarie dell'organizzazione. A partire dagli oggetti che vengono manipolati, si possono cominciare ad astrarre funzionalità che agiscono su questi oggetti. Queste funzionalità, opportunamente raccolte in contesti, possono essere dei candidati ad essere servizi. Ci accorgiamo quindi che possiamo definire due modalità di individuazione dei servizi: una task-centrica e una entity-centrica.
I servizi task-centrici (cioè quelli individuati con un approccio task-centrico) possono derivare da una particolare attività all'interno di un processo o da uno use case di alto livello; questo tipo di servizi sono in genere più facili da definire, ma se non analizzati con attenzione possono portare a servizi non facilmente riusabili.
I servizi entity-centrici (cioè quelli individuati con un approccio entity-centrico) partono dalle oggetti che devono essere manipolati dal sistema che si sta sviluppando; in questo caso si possono definire dei servizi incentrati sulle entità con le operazioni per le necessarie manipolazioni a corredo.
I servizi entity-centrici sono più difficili da modellare dei servizi task-centrici ma sono più facili da riusare, in quanto sono meno legati al processo per cui nascono.
Possiamo in aggiunta identificare altre due tipologie di servizi: quelli applicativi infrastrutturali (vedi layer architetturali) e i servizi che modellano processi (componendo altri servizi).
Ma che metodologia possiamo utilizzare per individuare questi servizi candidati? Una proposta di metodologia di analisi può essere sintetizzata nelle fasi:

• Identificazione e scomposizione di un Business Process in una serie di passi granulari
  
• Identificazione delle operazioni
  
• Creazione dei candidati per i business services (che - come detto- è un "contesto" che raggruppa più operazioni). E' in questo passo che possiamo differenziare i raggruppamenti individuati come "task-centrici" o "business-centrici".
  
• Verifica dei principi di SOA sui candidati dei servizi (riuso, autonomia, stateless, discovey, …).
  
• Identificare gli scenari di composizioni dei servizi candidati. Eventualmente Rivedere il raggruppamento delle operazioni (cioè i servizi candidati).
  
• Identificazione dei servizi infrastrutturali (di natura tecnologica, es: integrazione con servizi legacy). Eventualmente rivedere la composizione dei servizi sulla base dei servizi infrastrutturali individuati.

Al termine dell'analisi, abbiamo a disposizione un modello di candidati dei servizi che sarà il punto di partenza per la fase di design.

Figura 6: Passi principali della fase di Analisi

Definizione dei servizi: design
In realtà questa fase non può essere completamente astratta rispetto alla tecnologia che viene utilizzata. Infatti si devono produrre, come risultato del design, le interfacce dei servizi (service contract) definite nella tecnologia scelta.
In questo articolo cerchiamo comunque di identificare le fasi di design "astraendole" senza entrare in dettagli tecnologici.
Cominciamo considerando che conviene iniziare disegnando i servizi che sono più riusabili. Infatti, una volta definite con precisione le interfacce di questi, possono essere utili alla definizione degli altri servizi. Conviene quindi partire dai casi più semplici dal punto di vista del riuso e dell'astrazione. Seguendo questa considerazione ha senso definire un ordine di design dei servizi per tipologia, similmente a come fatto nella fase di analisi:

1. Disegno dei servizi entity-centrici
   
2. Disegno dei servizi applicativi infrastrutturali
   
3. Disegno dei servizi task-centrici
   
4. Disegno dei servizi che rappresentano processi (e che quindi sono composti da altri processi)

Figura 7: Passi principali della fase di Design

Nei primi due casi (design dei servizi entity-centrici e dei servizi infrastrutturali), i passi da seguire possono essere:

• Censire i servizi che possono influenzare/essere utilizzati dalla logica che si sta astraendo. Occorre verificare se esistono altri servizi che si sovrappongono a quello che si sta disegnando; in particolare occorre chiedersi se il servizio è effettivamente necessario oppure si stanno disegnando funzionalità che appartengono (o dovrebbero appartenere) ad un altro servizio.
  
• Definire l'interfaccia astratta del servizio (service contract)
  
• Verificare i principi di SOA sull'interfaccia
  
• Standardizzare dell'interfaccia (cioè verificare l'interfaccia sugli standard di design definiti, es: naming conventions)
  
• Estendere eventualmente il design dell'interfaccia. Equivale a rispondere alla domanda: quale altre operazioni può esporre il servizio? Se si trovano delle operazioni, estendere l'interfaccia con queste funzionalità.

Nel terzo caso (design dei servizi task-centric), è sensato seguire una strada lievemente differente:

• Definire la Workflow-Logic: occorre verificare tutti i possibili scenari per definire correttamente l'interfaccia del servizio che verrà utilizzato in questi processi.
  
• Definire l'interfaccia astratta del servizio (service contract)
  
• Verificare i principi di SOA sull'interfaccia
  
• Standardizzare dell'interfaccia
  
• Verifica dei processi applicativi infrastrutturali: a seguito del disegno dell'interfaccia, servono altri servizi infrastrutturali? Se si, si ha un feedback sul disegno dei servizi infrastrutturali.

Nell'ultimo caso (design servizi che rappresentano i processi):

• Definire gli scenari di interazione fra i servizi
  
• Definire l'interfaccia del servizio "processo"
  
• Definire il processo in termini di interazioni tra interfacce di servizi, dettagliando le interazioni.

Il risultato finale di queste operazioni è quindi un insieme di service-contract, espressi in maniera coerente con la tecnologia implementativa scelta.
Il design può a questo punto procedere a "cascata" sui singoli servizi, utilizzando le metodologie tradizionali di design (es: Object Orientation).

Meet-In-The-Middle: SOMA
SOMA (Service-Oriented Modeling and Architecture) è una metodologia che, non inficiando le considerazioni precedenti, molto pragmaticamente suddivide il processo di sviluppo di un sistema software "verticalmente" e presuppone di dovere affrontare problematiche di integrazione con software già sviluppato di cui vi vuole mantenere il funzionamento.
Sino ad ora abbiamo parlato di un approccio Top-Down: ora presumiamo di dovere integrarci con software già presente. Stiamo quindi utilizzando un approccio Meet-In-The-Middle; poiché i componenti che si vogliono includere sono già sviluppati, non possiamo parlare propriamente di una metodologia Bottom-Up. Le attività di SOMA sono raggruppate in tre fasi principali:

Identification: in questa fase si individuano i possibili candidati a diventare servizi

Specification: durante questa fase si decide quali dei servizi candidati precedentemente individuati esportare come servizi veri e propri e per ognuno di essi si specifica quali sono i componenti enterprise che lo compongono qualora ci sia la possibilità di riusare quanto già sviluppato.

Realization in questa fase si prendono le decisioni operative per la realizzazione dei servizi

Figura 8: Le tre fasi principali di SOMA

La fase di identificazione (Identification) dei servizi avviene mediante tre tecniche complementari:

Domain Decomposition (Top Down Analysis): si effettua un'analisi Top Down identificando le funzionalità / requisiti di business che i servizi dovranno soddisfare

Existing Asset Analysis: si effettua un'analisi identificando i componenti ad oggi esistenti che potrebbero concorrere alla realizzazione di un servizio

Non è un analisi Bottom-Up in senso stretto, dato che comunque si cerca di riusare il piu' possibile il pregresso (con eventuali refactoring), aggiungendo solo la logica necessaria per l'esposizione del servizio.

Goal-Service Modeling: si analizzano i risultati delle due analisi verificando che i servizi individuati soddisfano gli obiettivi di business (Business Goals). Viene quindi definito lo scope del servizio e identificato il processo di appartenenza.

Una volta identificati (Identification) i processi di business da realizzare si censiscono/identificano/verificano le applicazioni ed i componenti disponibili nell'architettura esistente (Realization decisions).
L'ultimo passo (Specification) si occupa di coprire il gap tra ciò che si "vorrebbe" e cosa si ha già "in casa". Si definiscono quindi i servizi con la giusta granularità di business (che è stata decisa nella fase di identificazione) e si specificano i componenti/applicazioni già disponibili per la fase di realizzazione. Il risultato di tali passi è una situazione completa (end to end!) che descrive in tutti i Layer i partecipanti al relativo processo.

Figura 9: Rappresentazione end-to-end del Processo

Questo tipo si approccio è complementare alle fasi di analisi e design precedentemente esposte, e può essere preso in considerazione ogni volta che ci si trovi a dovere integrare della logica legacy in un'applicazione a servizi.
Uno degli aspetti importanti di SOA, infatti, è la capacità implicita di integrazione espressa a livello di paradigma architetturale.

Conclusione
In questo articolo abbiamo introdotto i principali aspetti di analisi e design SOA che generalmente vengono indicati con il termine SOAD: Service Oriented Analysis and Design.
Abbiamo visto i principali passi che si effettuano nella fase di analisi e di design presentando inoltre alcuni possibili approcci metodologici. Infine si è visto inoltre come SOMA aiuti a disciplinare l'approccio Meet-In-The-Middle.

Bibliografia
[MOKA_SOA_I] M. Piraccini, S. Rossini: SOA: Dalla teoria alla pratica - MokaByte N.100 - Ottobre 2005
[SOAD] O. Zimmermann, P. Krogdahl, C. Gee: Elements of Service-Oriented Analysis and Design - An interdisciplinary modeling approach for SOA projects - http://www-128.ibm.com/developerworks/webservices/library/ws-soad1/
[SOMA] Ali Arsanjani Ph.D: Service-oriented modeling and architecture -How to identify, specify, and realize services for your SOA - http://www-128.ibm.com/developerworks/webservices/library/ws-soa-design1/
[SOA-CTD]Thomas Erl: Service-Oriented Architecture: Concepts, Technology, and Design - Hardcover
[OOAD] C. Larman : Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd Edition) -Hardcover
[BPM] www.bpmi.org