Service Oriented Architecture: analisi dell‘architettura orientata ai servizi da un punto di vista architetturale, metodologico e pratico.

Introduzione

Nei precedenti numeri apparsi su Mokabyte nella sezione Integrazione si è parlato di SOA in termini architetturali (vedere [MOKA_SOA_INTRO]) dando un‘introduzione generale all‘argomento.
E‘ stato poi affrontato l‘argomento dal punto di vista dell‘integrazione (vedere [MOKA_SOA_VIEW]).
Ora vediamo con questa serie di articoli di affrontare questo nuovo (!?) modo di costruire sistemi complessi da un punto di vista metodologico (oltre che architetturale) dando anche esempi concreti. Questa serie di articoli riprende e ordina quindi concetti già  in parte presentati cercando di fornire un quadro ampio ed il più possibile completo, cercando allo stesso tempo di dare un taglio pratico che solitamente latita nella trattazione di questi argomenti.

SOA: Architettura a servizi

Una architettura SOA è una architettura software che definisce una modalità  di descrivere i componenti (servizi) con caratteristiche ben specifiche orientate al riutilizzo e all‘integrazione.
SOA è uno stile architetturale basato sul concetto di servizio, che rappresenta quindi l‘elemento strutturale su cui le applicazioni vengono sviluppate. Occorre quindi definire cosa si intende per servizio.

Cos‘è un servizio ?

Un servizio è, in prima analisi, una funzionalità  di business realizzata tramite un componente che rispetta un‘interfaccia.

SOA è costituito da principi, linee guida, best practices architetturali indipendenti da qualsiasi tecnologia e definisce una serie di proprietà  che i servizi devono soddisfare per essere realmente riusabili e facilmente integrabili in ambiente eterogeneo:

• I Servizi devono essere ricercabili e recuperabili dinamicamente
• I Servizi devono essere autocontenuti e modulari
• I Servizi devono definire delle interfacce esplicite e indipendenti dall‘implementazione
• I Servizi devono essere debolmente accoppiati (loosely coupled). In questo caso il disaccoppiamento si intende sia tecnologico che funzionale
• I Servizi devono avere un‘interfaccia distribuita e devono essere accessibili in maniera trasparente rispetto all‘allocazione
• I Servizi devono avere preferibilmente un‘interfaccia a “grana grossa” (coarse-grained)
• I Servizi devono essere componibili, ovvero orchestrabili in processi di business ampi che rompano le tradizionali pile applicative verticali (silos)

Un servizio deve quindi definire un‘interfaccia pubblicabile sulla rete, ricercabile e invocabile in maniera indipendente dal linguaggio e dalla piattaforma.
Per ottenere questi requisiti, le applicazioni SOA definiscono dei ruoli (in realtà  non tutti obbligatori):

• Service Consumer: l‘entità  che richiede il servizio; può essere un modulo di un‘applicazione o un altro servizio.
• Service Provider: l‘entità  che fornisce il servizio e che ne espone l‘interfaccia.
• Service Contract: definisce il formato per la richiesta di un servizio e della relativa risposta.
• Service Registry: Direttorio in rete dei servizi consultabili.

Poichè i servizi devono essere ricercabili e recuperabili dinamicamente, il Service Contract deve essere pubblicato su un Service Registry dal Service Provider. Il Service Consumer deve richiedere al Service Registry il Contract relativo al servizio richiesto, che utilizzerà  per eseguire il servizio tramite un protocollo di trasporto.

Rispettando questi concetti, è possibile pensare alla definizione di un‘applicazione come aggregazione di servizi.

Spostandosi su un punto di vista più ampio è chiaro che l‘adozione di un‘architettura SOA investe tutti gli aspetti associati alla definizione di un Information System (metodologici, di processo, organizzativi ed anche tecnologici). L‘obiettivo centrale è comunque quello di guidare la definizione di un‘Architettura Enterprise ispirata e modellata in funzione dei driver di Business.

Possiamo quindi aggiungere che i servizi devono essere business-driven, quindi dovranno essere definiti definiti assieme agli esperti funzionali e di dominio.
I requisiti già  espressi di essere autocontenuti, stateless e coarse-grained orientano comunque il disegno in questa direzione e definire il servizio come componente che abbia realmente un significato per gli esperti funzionali (cioè non sia un componente architetturale fine a se stesso) è importantissimo ai fini del riuso del servizio stesso. Il concetto di servizi e di composizione degli stessi è un concetto che può essere quindi compreso in maniera “semplice” anche da chi tradizionalmente è al di fuori delle problematiche architetturali.

I servizi devono essere essenzialmente modellati in funzione del valore aggiunto che essi portano al core Business dell‘azienda: non tutto deve essere necessariamente modellato in stile SOA.
D‘altra parte le problematiche trasversali (es. Sicurezza, Manageability) dovrebbero essere viste dall‘infrastruttura applicativa come servizi.

E‘ bene notare come, a differenza di CORBA e J2EE, SOA non specifichi un‘architettura in senso stretto, ma si ponga obiettivi molto più ampi:

• definire pratiche e Roadmap di adozione che guidino l‘evoluzione tecnologica ed organizzativa dei Sistemi Enterprise
• specificare un insieme di regole per il disegno dei servizi con la definizione delle relative interfacce e delle modalità  di interazione tra essi (sia per i nuovi servizi, sia per l‘evoluzione delle piattaforme applicative esistenti)
• definire pratiche per guidare gli impatti organizzativi e culturali indotti
• migliorare il livello di condivisione/comunicazione/coordinamento tra i ruoli che tradizionalmente si occupano di Business e gli Architect (es. attraverso la centralità  del concetto di “Processo” di Business)
• contribuire al soddisfacimento delle strategie IT di Business

SOA di fatto non propone concetti architetturali nuovi, quanto una visione integrata ed ampliata di principi architetturali già  adottati nel passato (es: CORBA e J2EE) e di problematiche affrontate in altri ambiti (es. EAI e BPM).

SOA indirizza quindi in maniera corretta (anche se non rivoluzionaria) il design in termini di riutilizzo e di integrazione, di fatto producendo servizi con un maggiore valore aggiunto.

Riassumendo, quali sono quindi i vantaggio reale di architetture SOA?

1. Indirizza in maniera corretta il design di servizi in termini di riutilizzo e di integrazione
2. Non è legato a nessuna tecnologia in particolare

E‘ importante infatti notare che a livello implementativo la tecnologia utilizzata per lo sviluppo dei servizi SOA non è determinante finchà© vengono rispettate queste caratteristiche.

Questo sicuramente è un passo avanti rispetto, ad esempio, a J2EE… non si è nemmeno obbligato ad utilizzare java!

Come si presenta un sistema SOA?
A layer!

I layer SOA

1. Bottom layer: Contiene i sistemi operazionali (applicazioni e sistemi esistenti: ERP, CRM, Applicazioni legacy.
2. Component layer: basato su tecnologie a container e componenti
3. Service Layer: fornisce io servizi basandosi sui componenti e attori degli strati sottostanti. Agli strati superiori vengono forniti i servizi.
4. Business Process Choreography: E‘ lo strato che compone i servizi per implementare gli use case ed i processi di business.
5. Presentation: E‘ lo strato che permette l‘esposizione dei processi ottenuti dallo strato precedente tramite componenti di presentazione.
6. Integration Architecture: è l‘Infrastruttura che permette l‘accesso e la composizione dei servizi fornendo meccanismi di integrazione. Gli ESB (Enterprise Service Bus) sono definiti a questo livello, che deve quindi gestire per ogni servizio i ruoli definiti (service consumer, provider, contract, registry).
7. QoS, Security, Management, Monitoring: Tools di controllo e gestione dell‘infrastruttu-ra.

Costruire un‘applicazione SOA significa quindi identificare, disegnare, orchestrare servizi all‘interno dei layers definiti in maniera il più possibile indipendente dalla tecnologia utilizzata.

Metodologie

Che impatto ha SOA sul processo di sviluppo delle applicazioni complesse nella sua completezza? Per rispondere a questa domanda occorre affrontare anche il problema delle metodologie di analisi e design. Introduciamo alcune pratiche emergenti.

Metodologie di analisi e design: SOAD

SOA si pone come obiettivo lo sviluppo di applicazioni sulla base di servizi, disegnati seguendo regole che ne garantiscono riuso e ne facilitano l‘integrazione. Per fare questo stanno emergendo nuove metodologie di analisi e design che, partendo dai concetti “classici” di OOAD e dai concetti di architetture a servizi definiscono pratiche orientate all‘analisi e al design a cui si riferisce spesso con il termine “Service Oriented Analysis and Design” (SOAD).

Metodologie di integrazione: SOI e SOMA

Uno degli aspetti veramenti interessanti di SOA è l‘integrazione di applicazioni legacy (o comunque già  sviluppate) in sistemi a servizi. Questo permette infatti di non dovere riscrivere codice che funzionante e che si vuole conservare. Inoltre, ponendosi come obiettivo la “rottura” dei Silos applicativi verticali, implicitamente SOA si occupa di integrazione. Si parla in questo caso di SOI (Service Oriented Integration), ovvero l‘applicazione dei principi Service Oriented alle problematiche d‘integrazione

Inoltre è essenziale definire una metodologia di trasformazione di funzionalità  “vecchie” in servizi nel senso definito da SOA. SOMA è un interessante approccio a questo tipo di problema, e può essere utile per indirizzare una Roadmap per la trasformazione/integrazione di applicazioni preesistenti in architetture SOA.

Roadmap e maturity model

Abbiamo parlato di SOA sia dal punto di vista architetturale che delle metodologie di analisi e di design…ma questo non basta! Infatti è fondamentale occuparsi del problema anche dal punto di vista “culturale”.
Occorre arrivare a definire una serie di passi per arrivare a sviluppare e integrare applicazioni secondo i layer che sono stati definiti, cioè una roadmap che ci “traghetti” verso il nostro obiettivo.
Diventa quindi indispensabile capire quanto l‘organizzazione che vuole utilizzare architetture a servizi sia matura per l‘effettiva adozione di queste. Implicitamente ciò significa confrontare il grado di maturità  tecnologica di un‘azienda con un “maturity model”, quindi in pratica effettuare un‘operazione di assessment.
Una volta determinato il grado di maturità  rispetto al modello, verrà  naturale capire quali passi effettuare per raggiungere il livello superiore.
Diventa quindi importante definire un modello di maturità  delle architetture rispetto a SOA e, parallelamente, capire quali passi effettuare per evolversi all‘interno di questo modello.

SOA & il Service Bus

Come si è visto, i servizi devono essere in grado di comunicare tra di loro attraverso un canale di comunicazione: il SOA Service bus.
Da un punto di vista architetturale il SOA bus è un layer che deve mettere a disposizione uno strato di comunicazione tra i servizi.
Scopo dell‘Enterprise Service Bus (ESB) è fornire un‘infrastruttura che centralizzi funzionalità  quali supporto alla comunicazione sincrona ed asincrona basata su messaggi, intelligent routing, supporto alla trasformazione dei dati, supporto alla connettività  verso EIS eterogenei, …
Di fatto, oggi, sono percorribili due strade: sviluppandolo sfruttando le tecnologie esistenti o rivolgersi al mercato acquistando un prodotto ESB.

Conclusioni

Partiti! In questo articolo abbiamo introdotto i concetti salienti di SOA dando una panoramica globale ed introducendo brevemente gli argomenti su cui entreremo poi più in dettaglio.
Nel prossimo numero approfondiremo le implicazioni metodologiche legate all‘adozione di una architettura SOA.

Riferimenti bibliografici
[MOKA_SOA_INTRO]
M. Piraccini “Service Oriented Architecture-Introduzione” MokaByte 88, settembre 2004

[MOKA_SOA_VIEW]
R. Spazzoli “Uno sguardo su SOA” MokaByte 95, Aprile 2005