Dopo aver analizzato in maniera molto approfondita i diversi aspetti teorici e i principi delle Service Oriented Architecture, passiamo con questo articolo a un esempio pratico che ci permetterà di ‘ripassare‘ quanto spiegato in questa serie di articoli dedicati a SOA.

Introduzione

Nei precedenti articoli abbiamo parlato di SOA sia dal punto di vista architetturale (vedere [MOKA_SOA_I]) che delle metodologie di analisi e di design (vedere [MOKA_SOA_II]) .

Un‘azienda che decide di evolvere il proprio sistema informativo verso una architettura SOA deve fare diverse scelte e fronteggiare numerose sfide.

In [MOKA_SOA_III] e [MOKA_SOA_IV] abbiamo visto come sia indispensabile capire il livello di maturità  dell‘organizzazione e definire in base a questa una roadmap che definisca i passi aziendali (organizzativi, tecnici, metodologici e culturali) per definire un processo evolutivo ed incrementale con l‘obiettivo di una architettura SOA matura.

In [MOKA_SOA_V] abbiamo parlato di Service Oriented Integration (SOI): i principi Service Oriented applicati alle problematiche d‘integrazione.

In [MOKA_SOA_VI] si sono introdotte le caratteristiche principali di un Enterprise service BUS (ESB). I servizi SOA devono essere in grado di comunicare tra di loro attraverso un canale di comunicazione: il SOA bus. Da un punto di vista architetturale il SOA bus è un layer che deve mettere a disposizione uno strato di comunicazione tra i servizi: in [MOKA_SOA_VII] si sono presentati alcuni ESB open-source.

In [MOKA_VIII] si sono introdotte alcune possibili strategie d‘adozione di SOA ed in particolare si è parlato dell‘importanza di un SOA Pilot.

In questo articolo vedremo un esempio pratico che ci permetterà  di ‘ripassare‘ quanto spiegato in questa serie di articoli dedicati a SOA.

Analisi dei servizi

Il processo di business che si vuole costruire è un processo semplificato di validazione di un ordine.

Procediamo quindi nell‘identificazione e scomposizione di un Business Process in una serie di passi granulari.

Tale processo riguarda la verifica per l‘accettazione di un ordine inserito. Semplifichiamo lo use case ipotizzando che sia sufficiente un controllo sulla validità  della carta di credito dell‘acquirente e della sua email: dobbiamo quindi considerare valido un ordine che sia relativo ad una email valida e ad una carta di credito valida.
A partire da questo, iniziamo a disegnare il flusso del processo:

Dal processo identifichiamo le operazioni che devono essere modellate che nel semplice esempio proposto sono:

• controllo Email
• controllo Carta di Credito

Procediamo quindi a definire i contesti logici in cui raggruppare le operazioni; in questo semplice esempio ci troviamo davanti ad un caso in cui ad un contesto logico corrisponde una operazione.

Questi due contesti ci aiutano a identificare i candidati per i servizi (un candidato ad un servizio è un contesto che raggruppa una o più operazioni). E‘ in questo passo che possiamo differenziare i raggruppamenti individuati come ‘task-centrici‘ o ‘entity-centrici‘. In questo caso non stiamo considerando servizi che gestiscono entità  dell‘organizzazione; se avessimo considerato anche ad esempio il controllo della disponibilità  degli oggetti in magazzino, questo avrebbe portato alla definizione di un nuovo contesto logico e del conseguente design di servizi entità -centric.

Nel nostro esempio definiamo una prima analisi raggruppando le operazioni in due contesti logici, ognuno con una operazione:

Nome: CheckEmail
Goal: verifica che l‘email dell‘acquirente sia valida ed esistente

Nome: CheckCdC
Goal: verifica che la carta di credito dell‘acquirente si valida

Inoltre il processo stesso è un servizio che espone l‘operazione di verifica dell‘ordine, che però verrà  composto utilizzando le operazioni definite dagli altri.

Nome: CheckOrder
Goal: verifica che l‘ordine sia valido, effettuando verifiche sull‘email e la carta di credito dell‘acquirente.

Al termine dell‘analisi, abbiamo a disposizione un modello di candidati dei servizi che sarà  il punto di partenza per la fase di design. E‘ evidente che in questo esempio semplificato non vengono considerati molti passi di analisi che nella realtà  sarebbero fondamentali. Ad esempio occorrerebbe considerare se fra quelle identificate, si identificano operazioni che possono appartenere a servizi infrastrutturali.

Disegno dei servizi

L‘ analisi deve essere raffinata 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. Nel nostro caso dobbiamo disegnare i service contract dei servizi definiti e esprimere il processo di verifica dell‘ordine come orchestrazione dei servizi di verifica email e carta di credito.

Passiamo quindi a dettagliare il disegno dei servizi candidati: occorre identificare la logica di business incapsulata nel servizio e verificare che questa sia appropriata per l‘uso che si intende e che il servizio candidato rispetti i principi architetturali di SOA come riuso, granularità  e statelessness.

Nel nostro semplice esempio, il servizio controllo email, deve effettuare la validazione sintattica (correttezza formale) dell‘email e possiamo definirlo nel seguente modo:

Nome: CheckEmail
Goal: verifica che l‘email dell‘acquirente sia valida ed esistente
Input: email da controllare
Output:

• true (email valida ed esistente)
• false (email non valida o inesistente)

Descrizione: il servizio deve effettuare inzialmente la verifica sintattica (correttezza formale) della email seguita dalla verifica semantica (esistenza del dominio ed esistenza della email) Deve restituire ‘true‘ nel caso entrambi i controlli vengano effettuati con esito positivo e restituire false nel caso in cui uno dei due fallisca.
Riusabilità : il servizio può essere utilizzato da tutti i servizi di tutti i canali che necessitano di un controllo della mail.

Un disegno analogo si può effettuare anche per il servizio di verifica della carta di credito.

A questo punto bisogna ricontrollare gli scenari di composizione dei servizi progettati ed, eventualmente, rivedere il raggruppamento delle operazioni (cioè i servizi candidati) o del flusso del processo stesso.

Il passo successivo è la definizione dei service contract dei servizi, che vanno espressi coerentemente con la tecnologia che si è deciso di adottare: nel nostro caso utilizziamo i Web Services e, di conseguenza, disegniamo i service contract tramite WSDL.

Il Web Service Definition Language (vedere [WSDL]) ricopre un ruolo importante nell‘architettura dei web service perché descrive il contratto tra il Service Consumer (l‘entità  che richiede il servizio) ed il Service Provider (l‘entità  che fornisce il serviziio) in modalità  indipendente dal linguaggio di sviluppo e dalla piattaforma utilizzata (‘platform and language-neutral‘).

In pratica, WSDL è una grammatica che descrive (integrando XML Schema) come interagire con il servizio, definendo le operazioni e i messaggi relativi e specificando i ‘binding‘ delle operazioni sui protocollo esposti.

Possiamo suddividere il service contract WSDL in due parti: una astratta, che rappresenta la parte del contratto che non varia al variare della modalità  di esposizione, ed una concreta, che specifica su quale protocollo è accessibile il servizio e come le informazioni vengono trasmesse.

Gli elementi della parte astratta sono:

• types: descrive la definizione dei tipi di dati scambiati tra client e server usando un XML Schema (facoltativo per la descrizione dei tipi primitivi, obbligatorio nel caso di tipi di dato complessi).
• message: descrive la definizione dei messaggi (sia request che response) astratti che possono contenere zero o piu‘ elementi (message parameters o message return values) ognuno di un possibile tipo diverso
• portType: descrive un insieme astratto di operazioni supportato da uno o più endpoint (interfaccia); le operazioni sono definite dallo scambio di piu‘ messaggi. Per esempio l‘elemento portType può combinare un messaggio request ed un messaggio response in un‘unica operazione request/repsonse. Un portType generalmente definisce piu‘ di una operazione.

La parte concreta specifica su quale protocollo è accessibile il servizio e come le informazioni vengono trasmesse.
Gli elementi della parte concreta sono:

• Binding: specifica il protocollo e il formato dei dati di un particolare port type. Il

binding influenza il modo in cui i messaggi astratti sono codificati specificando lo stile del servizio (RPC vs. Document) e i meccanismi di encoding (literal vs. encoded).

• Service: definisce l‘indirizzo del Web Service. E‘ un‘associazione di un URL (localizzazione) e di un binding

Nel nostro esempio, la fase di design si conclude definendo nel WSDL del servizio di controllo email (CheckEmailService) un‘operazione di business di nome checkMail, che prevede una stringa in ingresso e restituisce un boolean in uscita.

Nel caso del servizio di controllo validità  della Carta di Credito si definisce un‘operazione di business di nome checkCdC, che prevede un oggetto di tipo creditCard in ingresso e restituisce un tipo creditCardResponse in uscita.

Definiti i Service Contract passiamo a dettagliare il processo di orchestrazione.

Per orchestrare i Web services utilizziamo WSBPEL (Web Services Business Process Execution Language).

BPEL presuppone che i servizi che dovrà  orchestrare siano descritti secondo WSDL (ed eventualmente memorizzati in un registry UDDI).
Dal punto di vista prettamente tecnico, BPEL esprime la logica di funzionamento del processo attraverso una grammatica basata su XML interpretabile da un orchestration engine opportunamente progettato per supportare questo linguaggio e il cui compito è quello di coordinare i vari servizi che compongono il processo.

Una delle particolarità  di BPEL è la sua visione ‘ricorsiva‘ di composizione di Web Service. Infatti, il processo definito come insiemedi Web Service collaboranti, può essere esso stesso un Web Service. Questo nuovo servizio ‘a valore aggiunto‘, così creato, sarà  visibile all‘esterno come un servizio semplice di cui è definita l‘interfaccia WSDL.
Ciò che avviene è, quindi, una divisione del processo secondo due punti di vista:
quello dell‘utente del processo che può supporre di interagire con un singolo servizio, e quello dei servizi cooperanti all‘interno del processo, che, descrivendo le proprie funzionalità  attraverso WSDL, verranno invocati dall‘orchestration engine nei tempi e nei modi definiti all‘interno del processo.

Entrando più in dettaglio, il processo è composto da attività  che possono gestire richieste da parte del client del processo (attività  di receive), eseguire altri servizi (attività  di invoke) oppure inviare messaggi di risposta al client medesimo (attività  di reply).
I tre tipi attività  descritti rappresentano le attività  fondamentali che il processo può svolgere per interagire con l‘esterno. Tali attività  dovranno essere svolte secondo uno schema ben preciso che rappresenta appunto il processo vero e proprio. Con WSBPEL possono essere utilizzati i principali costrutti, definiti per i modelli di workflow e cui corrispondono i costrutti sequence per la sequenza, flow per l‘esecuzione di attività  in parallelo, switch e pick per le alternative e while come costrutto iterativo.
A supporto del mantenimento dello stato tra le diverse chiamate, il processo può, inoltre, contemplare la definizione di variabili che consentono di memorizzare i dati corrispondenti alle richieste ricevute o alle risposte di invocazioni di servizi. È anche possibile effettuare manipolazioni di tali variabili all‘interno del processo, attraverso l‘attività  di assign, il che rende il linguaggio di descrizione del processo simile a un linguaggio di programmazione.

Nel nostro caso lo scenario che si prospetta è il seguente:

• : Ricezione di un messaggio che contiene i dati dell‘ordine da verificare (email e carta di credito).
• : Lettura dei valori con cui chiuamare i servizi CheckCdC e CheckEmail dal messaggio (copiati su variabili BPEL che devono essere coerenti con i tipi definiti dal WSDL dei servizi)
• e : Chiamata parallela ai due servizi
• : Verifica dei valori ritornati dai servizi e decisione del risultato da ritornare
• : Risposta del processo

Alla fine, poiché il processo BPEL viene esposto a sua volta come Web Service, occorre esprimerlo tramite un service contract WSDL in maniera analoga agli altri servizi.

Conclusioni

In questo articolo abbiamo effettuato, a partire da un semplice caso d‘uso, un analisi che ci ha permesso di identificare i servizi da implementare. Questi servizi e il processo di business che viene composto da essi sono stati disegnati definendo i service contract in WSDL e l‘orchestrazione con BPEL.
Nel prossimo articolo implementeremo lo scenario proposto avvalendoci di software open source.

Riferimenti

[MOKA_SOA_I]
M. Piraccini, S. Rossini, “SOA: Introduzione” MokaByte 100 Ottobre 2005

[MOKA_SOA_II]
M. Piraccini, S. Rossini, “SOA: Metodologia” MokaByte 101 Novembre 2005

[MOKA_SOA_III]
M. Piraccini, S. Rossini, “SOA (III): Il Maturity Model” MokaByte 102 Dicembre 2005

[MOKA_SOA_IV]
M. Piraccini, S. Rossini, “SOA (IV) Roadmap” MokaByte 103 Gennaio 2006

[MOKA_SOA_V]
M. Piraccini, S. Rossini, “SOA (V) SOI” MokaByte 104 Febbraio 2006

[MOKA_SOA_VI]
M. Piraccini, S. Rossini, “SOA (VI) ESB (I)” MokaByte 105 Marzo 2006

[MOKA_SOA_VII]
M. Piraccini, S. Rossini, “SOA (VII) ESB (II)” MokaByte 106 Aprile 2006

[MOKA_SOA_VIII]
M. Piraccini, S. Rossini, “SOA (VIII) Strategie di adozione” MokaByte 107 Maggio 2006

[MOKA_WSS_1]
S. Rossini, R. Spazzoli, “Web Services: il punto sulla standardizzazione (I)” MokaByte 96, Maggio 2005

[MOKA_WSS_2]
S. Rossini, R. Spazzoli, “Web Services: il punto sulla standardizzazione (II)” MokaByte 96, Giugno 2005

[SOAP]
www.w3.org/TR/SOAP

[WSDL]
www.w3c.org/TR/wsdl

[WS-I]
WS-I Specifications: http://www.ws-i.org

[WSBPEL]
http://www.oasis-open.org/committees/tc_home.php‘wg_abbrev=wsbpel