I web services e il mondo SOA (Service Oriented Architecture)

L’acronimo SOA (service oriented architecture) è da poco tempo entrato a far parte del gergo degli addetti ai lavori. E tuttavia dietro ad esso ci sono concetti piuttosto semplici e non nuovi. Alcuni tra i principi caratteristici delle SOA – separazione tra logica applicativa e di presentazione, applicazioni realizzate come collezione di servizi, ovvero pezzi di software tra loro indipendenti e con un’interfaccia prestabilita – riportano a concetti sviluppati con il client/server e l’object oriented computing. In effetti abbiano già visto con CORBA, COM, DCOM, Java e.Net dei modi per realizzare qualcosa di simile alle SOA.

L’idea fondamentale è che nelle architetture “a servizi” il patrimonio informativo di un’azienda non è più un insieme di applicazioni tra loro isolate e che comunicano attraverso tecnologie di application integration. Questo patrimonio è invece organizzato in una collezione di servizi pubblicati su un’infrastruttura di comunicazione (quella che Gartner chiama “enterprise service bus”) e che, quando ce n’è bisogno, possono essere utilizzati da più applicazioni. I web service sono un fattore chiave per la pubblicazione dei servizi in modo standard.

In generale, il concetto di Web Services consiste nell’eseguire un software su Internet o nel far comunicare le applicazioni automaticamente tra loro. In pratica, i Web Services possono essere descritti come componenti software modulari, incapsulate all’interno di una serie di protocolli di comunicazione Internet, e possono essere eseguiti tramite la Rete.

La forza del modello dei web services è di utilizzare un set base di protocolli disponibili ovunque, permettendo l’interoperabilità tra piattaforme molto diverse e

34 Cfr. A. Biffi (a cura di), Net Economy. Tecnologie e nuovi paradigmi manageriali,cit., pag. 95.

mantenendo comunque la possibilità di utilizzare protocolli più avanzati e specializzati per effettuare compiti specifici³⁵.

Le principali caratteristiche dei web services sono rappresentate da³⁶:

• poter essere alla base di applicazioni che girano su Internet;

• poter comunicare con altri programmi automaticamente senza intervento umano;

• essere distribuibili per un loro utilizzo su Internet o una intranet all’interno di un firewall aziendale. Infatti, la straordinaria espansione di Internet ha favorito lo sviluppo di centinaia di applicazioni distribuite basate su TCP/IP e ciò ha reso conveniente l’uso di tale protocollo anche in ambito locale per la realizzazione di reti di computer interne ad un ente o ad un’azienda (intranet), ma con la caratteristica peculiare di essere chiuse al pubblico. Qualora una intranet abbia un gateway verso Internet, questo è protetto da firewalls, cioè speciali precauzioni di sicurezza, che impediscono l’intrusione di persone non autorizzate;

• poter operare in un ambiente protetto impostato dai business partner;

• poter essere scritti utilizzando un’ampia gamma di strumenti di sviluppo.

La logica di funzionamento alla base dei web services è che questi possono essere utilizzati da chiunque, ovunque, in qualunque momento, usando un qualsiasi client d’accesso, purchè siano stati realizzati seguendo uno specifico insieme di standard.

I protocolli specifici alla base dei web services hanno iniziato a prendere forma sostanzialmente dal 1998, quando nacque l’idea di realizzare uno standard di comunicazione per i servizi web.

I protocolli su cui si basa il modello dei web services sono³⁷:

• XML (eXtensible Markup Language): è lo standard usato per rappresentare i dati trasportati, cioè per strutturare le informazioni in modo che i dati possono essere estratti facilmente e usati da altre applicazioni. Un documento XML descrive un web services e comprende informazioni che specificano esattamente come quel web services debba operare. Quando si lancia un web

35 Cfr. D. Busso, L’economia degli Application Service Provider, cit., pag. 28.

36 Cfr. M. Cane, Il sistema informatico nell’impresa: evoluzione ed influsso sul sistema informativo, cit., pagg. 175 e 176.

37 Cfr. D. Busso, L’economia degli Application Service Provider, cit., pag. 28.

services, per prima cosa viene ricercato il documento XML che lo descrive, il quale poi dettaglia come eseguire il servizio;

• WSDL (Web Service Description Language): è il linguaggio utilizzato per creare i documenti XML che descrivono un web services. Attraverso il suo impiego è possibile dettagliare informazioni quali, ad esempio, la posizione del servizio, il modo con cui eseguirlo, l’azienda che lo sta ospitando e le parole chiave ad esso associate;

• UDDI (Universal Description, Discovery and Integration): è lo standard promosso dall’omonimo consorzio e consente la creazione di elenchi ricercabili per rintracciare i web services sulla Rete³⁸;

• protocollo di comunicazione, il SOAP (Simple Object Access Protocol): è il protocollo di comunicazione che gestisce l’interazione tra i vari attori di un’architettura basata sui web services³⁹.

Secondo una definizione comune, Web Services sono dei componenti software che interagiscono dinamicamente con tutti gli altri usando una tecnologia standard in Internet (XML), rendendo possibile costruire dei ponti fra sistemi che altrimenti richiederebbero un enorme sforzo di sviluppo. D'altra parte i Web Services permettono la connessione fra sistemi per le funzioni di business di ogni giorno (es:

ordini, fatture, pagamenti,...). E queste funzioni di business possono essere usate come blocchi per costruire qualsiasi cosa; una applicazione può essere costruita da differenti Web Services assemblati dinamicamente da diverse fonti nel Web.

Ciò che permette ai Web Services di lavorare - e ciò che li rende unici nel mondo del business di oggi - è che i Web Services sono costruiti completamente su standard aperti basati su XML. In altre parole, i Web Services offrono delle interfacce

38 UDDI è un consorzio a cui partecipano quasi 300 aziende, che ha come scopo quello di favorire lo sviluppo, la scoperta e l’interoperabilità dei servizi web. I registri UDDI rappresentano le “Pagine Gialle” dei web services, cioè un database distribuito su cui si possono registrare le aziende ed i web services da loro esposti e attraverso il quale è possibile ricercare un certo servizio ed eseguirlo, sulla base del documento XML che lo descrive. I registri UDDI possono essere privati (dedicati a una sola tipologia di azienda) oppure pubblici (accessibili da chiunque via Internet).

Cfr. M. Cane, Il sistema informatico nell’impresa: evoluzione ed influsso sul sistema informativo, cit., pag. 177.

39 La modalità di esecuzione dei web services implica il coinvolgimento di tre soggetti:

• service provider: il server che ospita il web services;

• service registry: un database ricercabile che ospita le descrizioni del servizio;

• service requestor: la persona, il computer o il servizio che vogliono eseguire quel determinato web services.

Cfr. AA.VV., “Scendono in campo i web services”, in Computerworld Italia, n. 24, giugno 2002.

standard dentro e fuori le applicazioni, che rendono facile l'integrazione di sistemi diversi⁴⁰.

Il risultato è uno sviluppo e una integrazione più facile; infatti, oltre che a cambiare il modo in cui le applicazioni sono distribuite, i Web Services stanno re-inventando il modo in cui le applicazioni sono sviluppate ed integrate. In verità i Web Services sono delle componenti riusabili, e quindi promettono una drammatica riduzione del costo totale di creazione di una applicazione. E ciò significa che il costo e lo sforzo oggi occorrente nello sviluppo delle applicazioni calerà sensibilmente. Ma, più importante, i Web Services rappresentano delle interfacce standard fra le applicazioni, rendendo obsoleto il modo odierno di connettere le applicazioni fra loro attraverso rigide soluzioni punto-a-punto⁴¹.

Nella situazione odierna, i sistemi informativi (ERP) richiedono delle complesse personalizzazioni per riuscire a supportare in modo adeguato le specifiche esigenze di business delle aziende utenti. Inoltre le integrazioni con altre applicazioni presenti in azienda sono generalmente implementate attraverso la programmazione di API (Application Programming Interface) apposite che realizzano dei collegamenti punto-a-punto tra le due applicazioni interessate⁴². In un’azienda minimamente strutturata e complessa sono presenti alcune decine di queste API, così come un certo numero di personalizzazioni. Un insieme di programmi che bisogna manutenere e aggiornare, e che generalmente bisognerà riscrivere, parzialmente o integralmente,

40 Cfr. www.rds-software.com.

41 I web services sono stati concepiti per la comunicazione e l’integrazione tra sistemi, consentendo lo scambio di informazioni e il lancio di elaborazioni senza costose attività di codifica e manutenzione, che invece sarebbero necessarie se si ricorresse a una piena integrazione punto a punto tra sistemi differenti.

Cfr. M. Cane, Il sistema informatico nell’impresa: evoluzione ed influsso sul sistema informativo, cit., pag. 175.

42 Già durante la prima fase di espansione dei sistemi ERP all’interno delle aziende, si era presentato il problema dell’integrazione tra i moduli utilizzati dai singoli reparti con il resto del sistema informativo aziendale. Problemi che molto spesso sono stati risolti adottando soluzioni proprietarie, mirate a favorire il “dialogo” diretto di ogni componente applicativa con le altre in uso presso la stessa organizzazione. Dopo anni di questa politica, oggi le aziende si ritrovano con un miscuglio di sistemi diversi, non interoperabili tra loro se non al prezzo di costose integrazioni. Nel tentativo di risolvere anche questo problema, negli anni recenti molte aziende hanno investito enormi risorse nell'implementazione di suite ERP basate su database centralizzati. Sebbene queste applicazioni risolvano il problema dell'integrazione, lo fanno al prezzo di imbrigliare i processi di business all'interno di regole modificabili con difficoltà. Ciò mal si concilia con l'esigenza di flessibilità che è propria, per esempio, in scenari di acquisizione o fusione di aziende e con la necessità sempre maggiore di interagire con partner secondo modalità di volta in volta diverse.

Cfr. G. Goglio, SOA e web services nel mercato ERP italiano, in Computerworld Italia, n. 19, giugno 2005, pag. 24.

nel caso in cui per esempio l’azienda utente decida di far migrare la piattaforma applicativa “standard” alla nuova release rilasciata dal vendor.

Un processo questo che oggi, proprio a causa di decine di API d’integrazione e di personalizzazioni, può richiedere anche diversi mesi, coinvolgendo alcune decine di risorse esperte sia interne che esterne all’azienda, prima di essere completato con successo. Non è un caso che in questi anni di taglio dei budget, molti responsabili IT abbiano dismesso gran parte delle personalizzazioni, mantenendo solo quelle che nel tempo si sono rilevate strettamente necessarie. In questo modo si torna a lavorare su piattaforme standard, e la differenziazione rispetto ai concorrenti si focalizza solo sui processi core⁴³.

Prendendo come punto di riferimento il modello internet, l’architettura dei web services ha permesso di introdurre un tipo di approccio diametralmente opposto:

basata su Internet, essa è un’architettura aperta e non proprietaria. Grazie all’adozione di standard ormai condivisi da tutti - XML, SOAP, WSDL... - essa non è legata a una specifica piattaforma hardware o software o a un singolo linguaggio di programmazione. Anzichè acquistare o costruirsi i propri sistemi, le aziende possono prendere in affitto solo i servizi che a loro interessano, quando vogliono e per il tempo che a loro serve. I benefici di questo approccio sono diversi. Il primo è dato dalla possibilità di realizzare integrazioni in modo “lasco” (si parla di “loose coupling” in contrapposizione a “tight coupling”), cioè dinamico e non predefinito. Il secondo beneficio è dato dalla facilità di realizzare una migrazione da un’architettura tradizionale a una basata sui servizi - SOA, Service Oriented Architecture - in modo incrementale e a basso costo. SOA è un sistema per collegare risorse a richiesta. In una SOA, le risorse sono rese disponibili agli altri partecipanti all'interno della rete come servizi indipendenti accessibili in modo standardizzato. Ciò fornisce un accoppiamento lasco delle risorse più flessibile rispetto a un’architettura tradizionale dei sistemi⁴⁴. Dopo il paradigma di programmazione orientato agli oggetti, gli informatici parleranno di architettura di applicazioni basate sui servizi, Service Oriented Architecture (SOA). I web services e le applicazioni SOA sono il

“necessario futuro” delle applicazioni gestionali, specie per il modello on demand in cui l’applicazione diventa sempre più una commodity, come l’energia elettrica.

43 Cfr. R. Vota (a cura di), Gli ERP fanno rotta su SOA, in Computerworld Italia, n. 19, 6 giugno, 2005, pag. 22.

44 Cfr. www.rds-software.com.

Secondo quanto affermato dai fornitori del settore, la strada sembra definitivamente tracciata, ma questo non significa che sarà necessariamente un percorso breve e lineare. Se da una parte alcuni si dicono pronti a convertire nel giro di poco tempo l’intero patrimonio applicativo in ottica SOA e web services, altri hanno invece predisposto percorsi più tranquilli.