SOA, Web Service, interoperabilità: tre ingredienti di supporto per la costruzione di infrastrutture ad elementi eterogenei in grado di comunicare. In questo articolo (primo di una serie) si cercherà di trovare una soluzione ai problemi di integrazione e interoperabilità, ricorrendo a un approccio basato su modelli architetturali a servizi e Web Service. Come può un‘architettura a servizi rendere più semplice il lavoro di integrazione e interoperabilità tra sistemi eterogenei? Questo il punto di partenza.
Pochi sono stati risparmiati dal bombardamento informativo che ha fatto leva, da fine anni Novanta ad oggi, sui concetti di SOA (Service Oriented Architecture) e Web Service. Tanti, di contro, hanno adottato il paradigma del servizio, sperimentando un modello architetturale nuovo con la speranza di riuscire a colmare vecchie lacune e risolvere problemi che prima di allora erano stati parzialmente affrontati con tecniche complesse, costose e non sempre efficienti. Alcuni progetti si sono rivelati dei flop, altri hanno raccolto considerazioni particolarmente entusiastiche da parte degli addetti ai lavori, come spesso accade quando qualcosa di nuovo si affaccia sul mercato e qualcuno, altrettanto nuovo, crede che quel giocattolo, a prima vista così potente, sia la soluzione a tutto o a quasi tutto.
Anche questo articolo contribuirà, suo malgrado, al bombardamento mediatico sulle architetture a servizi e sulle tecnologie che le supportano, spostando il punto di vista sul concetto di interoperabilità e integrazione, cercando di chiarire se e come una struttura di tipo SOA sia realmente in grado di agevolare la cooperazione tra applicazioni più o meno eterogenee.
Nei prossimi articoli della serie, affronteremo in particolare le tematiche connesse all’integrazione di due applicazioni scritte in linguaggi diversi, Java e PHP.
SOA
Non è possibile introdurre SOA con poche righe: ci sono molti testi di riferimento e anche su MokaByte sono stati pubblicati molti articoli al riguardo (si veda, per esempio, [5] e seguenti). Possiamo però ribadire alcuni concetti base, fosse solo per rinfrescare la memoria di chi ci ha già lavorato o per stuzzicare l’appetito di chi ne ha sentito parlare poco e vorrebbe proseguire la lettura dell’articolo senza necessariamente utilizzare altre fonti in maniera intensiva. Iniziamo quindi con un paio di definizioni.
Un’architettura a servizi può essere definita come un modello architetturale che poggia sul concetto di servizio, implementazione di un processo di business (reso disponibile attraverso un’interfaccia) da una parte e mattoncino costruttivo per la progettazione di applicazioni dall’altra. In realtà stiamo indentificando il servizio come il cuore di un’architettura di tipo SOA e come un oggetto che possiede fondamentalmente un’interfaccia attraverso la quale vengono pubblicate le operazioni (cosa) e una parte implementativa (come). Chi accede al servizio (il consumatore), infatti, vede soltanto quello che il servizio fa, mentre chi produce il servizio (il produttore) può cambiarne l’implementazione a suo piacimento in modo da andare incontro a qualsiasi tipo di necessità (tecnologica, integrativa) senza che l’utilizzatore se ne accorga: la parte visibile resta immutata così come la modalità di utilizzo del servizio (Figura 1). Il consumatore, quindi, può continuare ad utilizzare un servizio come prima nonostante ne sia stata cambiata l’implementazione da parte del produttore.
Ora, la separazione tra interfaccia e implementazione non è altro che una delle caratteristiche che un servizio deve possedere per definirsi tale: è una caratteristica necessaria, ma non sufficiente Perche’ un servizio assolva appieno al proprio compito.
Ma allora, quando possiamo iniziare a parlare di servizio? In realtà un buon servizio, oltre a possedere un’implementazione e un’interfaccia di accesso, deve essere una sorta di mattoncino Lego facilmente aggregabile ad altri suoi simili, in grado (tra le altre cose) di:
- formare servizi più grandi e complessi (modularità)
- lasciare poco spazio a dipendenze tra produttore e consumatore e relegarle al solo uso delle interfacce (lasco accoppiamento)
- essere utilizzato per compiti specifici e isolati (isolamento)
- evitare di avere memoria dopo avere eseguito l’operazione per la quale è stato progettato in modo aumentare la scalabilità del sistema di cui fa parte (assenza di memoria)
- essere indipendente da piattaforme, linguaggi e protocolli (indipendenza)
Per dirla in breve, utilizzare un’architettura a servizi vuol dire costruire servizi (e quindi funzionalità) che possano essere utilizzati, riutilizzati e combinati per creare processi di business flessibili e leggeri. E vuol dire seguire particolari pattern architetturali in grado di promuovere riuso, accoppiamento lasco, velocità, efficienza intesa come costi di sviluppo e tempistica di immissione sul mercato, interoperabilità, integrazione, flessibilità.
Web Service
Un’architettura deve essere supportata da tecnologie in grado di offrire gli strumenti che la implementino in maniera corretta. Nella parte progettuale è possible utilizzare concetti astratti, ma poi, arrivati al nodo del “come”, si entra spesso nella giungla delle tecnologie di supporto.
I Web Service non sono altro che una di tali tecnologie (ad onor del vero la più utilizzata) per l’implementazione di soluzioni orientate ai servizi. Per dirla alla W3C, un web service è un sistema software progettato per supportare interoperabilità tra sistemi eterogenei che comunicano in rete.
In sostanza il primo elemento che lo caratterizza non è altro che un’interfaccia, descritta in un linguaggio comprensibile sia da un umano che da una macchina e accessibile dal mondo esterno. Sistemi esterni non necessariamente della stessa natura, infatti, possono accedervi utilizzando la descrizione dell’interfaccia e comunicando attraverso un set di messaggi che viaggiano grazie ad un livello di trasporto. Il tutto condito da un modello che descriva il ciclo di vita del servizio stesso.
È naturale, infatti, iniziare a pensare ad un Web Service come a un’entità con un vero e proprio ciclo di vita e, quindi, con qualcuno che tale servizio lo fornisca (il provider) e che si occupi della creazione, della pubblicazione e della manutenzione del servizio; con qualcuno che tale servizio possa utilizzarlo (il requester) e che acceda al servizio per soddisfare le proprie esigenze; con qualcuno che fornisca un modo di immagazzinare le descrizioni dei servizi (attraverso il linguaggio di descrizione a cui si è accennato in precedenza) e che possa essere consultato per conoscere quello che il servizio fornisce e dove fisicamente risiede (il broker). In Figura 1 la rappresentazione del ciclo di vita di un Web Service.
Perche’ questo paradigma funzioni correttamente, è necessario iniziare a preoccuparsi di standard condivisi che descrivano tutte le parti dell’oggetto servizio e dell’infrastruttura che lo andrà a ospitare, dalla messaggistica alla qualità del servizio alla sicurezza. In questo senso è possibile guardare il Web Service anche come collezione di standard, come mostra la Figura 2 illustrando i principali meccanismi di cui un Web Service si serve, descritti sinteticamente di seguito.
I dati scambiati sono codificati attraverso tag XML e utilizzano diversi metodi di impacchettamento. Uno dei più diffusi è SOAP (Simple Object Access Protocol), un protocollo di comunicazione che descrive appunto lo scambio messaggi XML su reti di calcolatori in maniera indipendente dal livello di trasporto, anche se all’atto pratico HTTP è il livello di trasporto d’elezione. Un messaggio SOAP contiene un header per informazioni quali sicurezza e routing e un body per il contenuto informativo vero e proprio. WSDL (Web Service Description Language) è un linguaggio, anch’esso basato su XML, per la descrizione del servizio. Non è altro che la descrizione dell’interfaccia del servizio e maschera la parte implementativa. Il requester, ad esempio, può accedere a tale descrizione e ottenere informazioni su quali funzioni il servizio è in grado di fornire. UDDI (Universal Description, Discovery and Integration) è uno standard, pure questo basato su XML, per descrivere, pubblicizzare e trovare Web Service.
Esistono poi standard quali WS-Security e WS-Reliability per i processi di autenticazione, confidenzialità e affidabilità.
Problematiche di interoperabilità e integrazione
Il problema dell’integrazione e dell’interoperabilità tra applicazioni all’interno di un contesto aziendale non è certo un problema nuovo, e non è certo un problema affrontabile con una soluzione semplicistica e meramente tecnologica. Affonda le radici nei processi costruttivi del sistema informativo e soprattutto nella natura dei singoli applicativi che vanno via via adagiandosi durante il processo di informatizzazione incrementale dell’impresa. In azienda, infatti, vanno spesso accumulandosi applicazioni così diverse sotto tanti e tali aspetti che il progetto di integrazione è soggetto ad un rapido fallimento se non gestito in maniera organica e corretta. Ma quali sono le problematiche che rendono di non così immediata soluzione tale processo?
Innanzitutto il problema è di natura architetturale e non tecnologica. Troppo spesso ci si trova di fronte ad applicazioni letteralmente accumulatesi nel substrato tecnologico dell’impresa, mai progettate per lavorare insieme. Di conseguenza l’approccio all’integrazione non rappresenta certo una scienza esatta, ma piuttosto una raccolta di analisi, best practice e modelli architetturali. Quale approccio scegliere? È necessario lavorare solo a livello di database oppure utilizzare un’architettura SOA? Gli oggetti dell’impresa hanno lo stesso significato all’interno di ogni applicativo da integrare? Se esistono, quali sono le funzionalità duplicate? Esistono già politiche di autenticazione e sicurezza integrate?
Queste sono alcune delle domande che si pone l’analista di fronte a problematiche di integrazione e rendono l’idea di quanto un sistema informativo aziendale possa essere articolato e complesso, tanto più complesso quanto più grandi sono le dimensioni dell’impresa. Ora, utilizzando la carrellata di informazioni su SOA e Web Service appena esposta, cercheremo di affrontare il problema dell’integrazione (che per quello che si è appena visto appare un problema trasversale) attraverso l’utilizzo di un modello architetturale a servizi con un approccio orientato ai Web Service.
SOA per l’integrazione e l’interoperabilità, quindi. Ma Perche’ proprio SOA?
Gran parte dei vantaggi possono essere facilmente individuati sbirciando tra le righe precedenti. Sembra quasi naturale, infatti, rileggendo le caratteristiche di un servizio, considerare tale entità come un oggetto facilmente propenso ad aggregazione e integrazione. Pensiamo innanzitutto all’interfaccia, una delle caratteristiche fondamentali del servizio, standardizzata, descritta da un linguaggio quale WSDL e quindi comprensible e da umano e da un calcolatore. Pensiamo poi alla capacità dell’intefaccia di nascondere tutta la parte implementativa che il servizio offre. A parte la descrizione del servizio, quindi, tutto il resto può cambiare in maniera trasparente.
SOA e Web Service: un approccio al problema
Un approccio interessante in ambiente Enterprise è stato proposto da Mike Rosen et al in [2]. Tale approccio considera l’integrazione una particolare tipologia di servizio (servizio di integrazione) e quindi una sorta di middleware di accesso a quello (programmi e dati) che di esistente è già presente all’interno dell’infrastruttura dell’impresa.
Utilizzando tale meccanismo il sistema informativo si presenta fondamentalmente come un insieme di servizi, ciascuno dei quali è composto da uno o più componenti di business, a loro volta paradigma programmativo del servizio e livello di astrazione per l’accesso alle applicazioni e ai dati esistenti. I componenti di business, elementi costruttivi del servizio, possono essere implementati direttamente oppure accedere alle applicazioni legacy attraverso i servizi di integrazione (Figura 3). Attraverso il paradigma servizio – componente di business – servizio di integrazione, quindi, il sistema ricicla l’informazione che già esiste, estende le funzionalità delle vecchie applicazioni creando nuovi componenti di business e combina le funzionalità già esistenti per crearne delle nuove.
Ma la parte forse più interessante dell’intero approccio è il disaccoppiamento tra quelli che sono i servizi di business e quelli che sono i servizi di integrazione. I primi rendono accessibili funzionalità allineate con il modello di business dell’impresa, mentre i secondi sono, trovandosi a dover colloquiare con l’infrastruttura preesistente, fortemente accoppiati a tale infrastruttura. Tale separazione risulta particolarmente importante in sistemi di grosse dimensione quando la flessibilità e la scalabilità del sistema complessivo rappresentano fattori da non trascurare. Stiamo parlando di applicazioni a livelli: integrazione, componenti di business, servizi di business.
Resta da vedere come la parte garante dell’accesso a dati e applicativi debba essere realizzata all’interno dello strato di integrazione. Anche qui la risposta non può essere certo univoca, ma dipende da quello che esiste già e da quello che occorre progettare e implementare.
Il panorama è abbastanza ampio, tanto da spaziare dall’uso di Web Service se già presenti nelle applicazioni da integrare, a Web Service costruiti come Web Service Wrapper attorno a componenti già esistenti in caso da tali componenti sia relativamente semplice generare Web Service, da tecnologie di accesso ai dati quali JDBC qualora l’integrazione coinvolga dati conservati in database relazionali, ad adattatori quali JCA/J2C qualora le applicazioni da integrare siano implementate su J2EE application server. Diverse tecnologie per un unico fine, quindi: implementare politiche di accesso al preesistente da esporre attraverso interfacce di servizi di integrazione. La Figura 3 offre una sintesi globale del modello appena descritto.
Fin qui il problema dell’interoperabilità e dell’integrazione all’interno di un panorama Enterprise. L’impresa presenta un modello informativo sempre diverso: un’attenta analisi dell’infrastruttura esistente è il primo requisito per una corretta integrazione. Un approccio orientato ai servizi, poi, consente di avere risultati che presentano notevoli vantaggi soprattutto in termini di lasco accoppiamento e scalabilità del sistema. È, in pratica, un collante di qualità per applicazioni eterogenee.
Adesso proviamo a spostare il punto di vista e proviamo ad analizzare un contesto leggermente diverso pensando, per un attimo, di non avere di fronte la complessità di applicazioni e problemi che un contesto Enterprise presenta. Una piccola software house, ad esempio, si trova spesso nella necessità di far comunicare tra loro applicazioni eterogenee scritte in linguaggi diversi, spesso ingegnandosi in soluzioni arcaiche che risolvono il problema soltanto in parte. Ora, qui non si sta assolutamente affermando che l’approccio SOA sia l’unico possibile o che l’approccio SOA sia il più proficuo in ogni situazione e che le altre soluzioni siano da demonizzare. Come detto in precedenza il problema è analitico prima che architetturale e implementativo. Si sta semplicemente dicendo che spesso il concetto di servizio offre caratteristiche peculiari che lo rendono utilizzabile per la risoluzione di parecchie problematiche a carattere integrativo.
Esistono infiniti motivi per cui una software house decide di scrivere due applicativi in linguaggi diversi e vanno dalla produttività del gruppo di sviluppo in quel linguaggio alla capacità del linguaggio di sfruttare meglio determinate risorse. Quale linguaggio sia universalmente il migliore è un dilemma irrisolvibile e sterile. Di quale linguaggio sia più produttivo in un particolare contesto è invece argomento di cui si può agevolmente discutere.
Supponiamo, ad esempio, che tale software house stia progettando due applicativi in due linguaggi diversi per i motivi sopra menzionati e che abbia bisogno di farli parlare affinche si scambino delle informazioni. Lo scenario non è certo così complicato come quello descritto precedentemente, appare tuttavia comodo l’utilizzo di un’architettura a servizi che ne gestisca l’interoperabilità.
Nei prossimi articoli abbandoneremo gran parte della teoria che ci ha accompagnato in questa introduzione e cercheremo di osservare, codice alla mano, come due applicativi eterogenei possano parlarsi attraverso l’utilizzo di Web Service. Inutile dire che il linguaggio di uno degli applicativi sarà Java, l’altro sarà un linguaggio molto diffuso in ambiente Web… appunto PHP. Ma ne parlermo diffusamente nel prossimo articolo.
Conclusioni
In questo articolo è stato affrontato il problema dell’integrazione e dell’interoperabilità tra applicativi eterogenei. Il punto di partenza è stata la domanda “Come può, un’architettura a servizi, rendere più semplice il lavoro di integrazione e interoperabilità tra sistemi eterogenei?”. Per rispondere a tale quesito si è partiti da una carrellata descrittiva sulle architetture SOA e sui Web Service. La natura stessa del concetto di servizio ci ha portati a comprendere le ragioni più profonde per cui una architettura così fatta possa essere produttiva quando ci si trova ad affrontare problemi di integrazione. Abbiamo poi affrontato il problema dell’integrazione all’interno di un contesto Enterprise dove applicativi eterogeni tendono ad accumularsi nel substrato informativo dell’impresa e spesso risulta estremamente complesso farli dialogare. Si è passati, quindi, all’introduzione di un modello architetturale a servizi in modo da illustrare come il concetto stesso di servizio possa essere di aiuto nella gestione dei processi comunicativi tra elementi eterogenei. Infine si è visto come un’architettura a servizi possa essere utilizzata anche in constesti meno complessi e sono state poste le basi per la costruzione di due micro applicativi che mostreranno come due programmi scritti in linguaggi diversi siano in grado di comunicare utilizzando dei Web Service.
Compito di questo articolo è semplicemente introdurre i concetti di SOA e Web Service come incipit per l’esame, nei prossimi articoli, dell’interazione tra due applicativi scritti in linguaggi diversi. In ogni caso, nelle prossime puntate, dal taglio sicuramente più pratico, molti dei concetti qui esposti prenderanno una forma più definita.
Per concludere, in questo articolo abbiamo parlato di applicazioni eterogenee, ma attenzione… l’approccio a servizi non è certo solo appannaggio di tali sistemi. Applicativi non eterogenei, infatti, possono giovare comunque di infrastrutture SOA e implementarle sfruttando le peculiarità che esse offrono. Ma questa sarebbe un’altra storia.
Riferimenti
[1] Thomas Erl, “SOA. Principles of Service Design”, Prentice Hall, 2008
[2] Michael Rosen – Boris Lublinsky – Kevin T.Smith – Marc J. Balcer, “Applied SOA”, Wiley Publishing, 2008
[3] Deepal Jayasinghe, “Quickstart Apache Axis2”, Packt Publishing, 2008
[4] W3C, Web Service Activity
http://www.w3.org/2002/ws/
[5] S. Rossini – M. Piraccini, “Service Oriented Architecture: dalla teoria alla pratica – I parte: introduzione a SOA”, MokaByte 100, Ottobre 2005