Tecnologia e innovazione al servizio delle aziende

Service Oriented Architecture

Con “Service Oriented Architecture” (SOA) si indica un’architettura software distribuita dove le applicazioni e i sistemi informativi comunicano fra loro tramite l’esposizione di servizi riusabili. Navigando sulla rete, o leggendo i tomi scritti dai grandi nomi dell’informatica (personalmente ne ho letti più di 60), si possono trovare molte definizioni di SOA, spesso discordanti fra loro. Inoltre, la necessità, da parte dei vendor, di distribuire nuove versioni dei propri framework per lo sviluppo di applicazioni, ha portato molte aziende a credere che l’implementazione di una SOA consista nell’esporre le funzioni distribuite  dei propri applicativi tramite la tecnologia dei Web Services SOAP, spesso, in congiuzione con un middleware di comunicazione chiamato Enterprise Service Bus (ESB). In realtà questo non è vero: negli stessi tomi, nascosto fra le righe, viene spiegato che SOA può essere implementata anche con altre tecnologie che, spesso, si rivelano più efficienti di quelle attualmente in voga. Tecnologie più “vecchie” come CORBA, Message & Queuing, etc…, possono essere utilizzate con profitto per l’implementazione dei servizi SOA. L’evoluzione delle architetture aziendali verso il Web 2.0 e il Cloud Computing sta, inoltre, riducendo l’utilizzo dei web services basati su XML e SOAP con la loro graduale sostituzione con servizi REST.
soa03
Altra cosa di cui bisogna tenere conto è che, in azienda, non si ha una SOA solo perchè si hanno applicazioni che espongono interfacce remote. Durante la mia attività di consulenza e di formazione mi è spesso capitato di sentire frasi del tipo “Noi facciamo SOA da alcuni anni in quanto abbiamo implementato delle applicazioni con i Web Services”; oppure “Noi abbiamo SOA perchè abbiamo un Enterprise Service Bus”. Nulla di più errato: SOA è una meta-architettura che consente alle aziende di implementare e governare applicazioni distribuite altamente interoperanti. Quello che normalmente viene dimenticato è tutto il processo di governance dei servizi e dell’infrastruttura. Non è sufficiente esporre i servizi; questi devono essere gestiti in ogni fase del loro ciclo di vita (governance). E’ quindi necessario approntare un processo per censire e catalogare i servizi esistenti in modo da diffondere nell’azienda la conoscenza della loro esistenza. L’accesso ai servizi deve poi essere controllato tramite l’utilizzo di apposite policy che possono essere gestite tramite un “contratto di servizio” che deve essere stipulato fra il fornitore e il fruitore dello stesso. Il contratto, ovviamente, deve essere fatto rispettare tramite la verifica (preferibilmente runtime) dello stesso. La mia opinione, condivisa anche dai grandi nomi dell’informatica mondiale, è che, in azienda, non si ha una SOA se non esiste un processo di governace per la gestione dei servizi e del loro ciclo di vita.
soa01
Altro errore che, comunemente, viene fatto, è quello di lasciare ai gruppi IT la gestione di tutte le fasi di introduzione della SOA in azienda. Normalmente, questi, “ragionano” sulle tecnologie con la conseguenza che prima vengono scelti gli strumenti per fare SOA e su questi vengono costruite le applicazioni. Spesso questo porta alla scelta di strumenti non adatti alle necessità aziendali che poi devono essere utilizzati solo “perchè li si è comprati”. In realtà, SOA non deve essere costruita sulle tecnologie ma sul business dell’azienda. Si devono quindi analizzare le necessità di business e su queste devono essere progettate le applicazioni. La tecnologia deve poi essere scelta in base ai requisiti raccolti (non è il business che deve essere adattato alle tecnologie). Per tale motivo, la creazione, all’interno dell’azienda, di un “centro di competenza SOA“, formato da persone provenienti da aree eterogenee (IT, Analisi, Progettazione, Management,…) consente, normalmente, di fare le scelte giuste e di introdurre SOA in modo adeguato alle esigenze aziendali.
Dal punto di vista tecnologico, l’azienda deve cercare di riutilizzate il più possibile gli strumenti e le tecnologie di cui già dispone, valutando se è necessario introdurne di nuove (es. è necessario un ESB?). Nella scelta delle tecnologie è molto importante valutare bene le necessità di sicurezza e di protezione dell’infrastruttura tenendo conto che le tecnologie basate sui web services (es. WS-Security) sono incomplete, non pienamente supportate all’interno dei framework SOA e non sempre adattabili ad infrastrutture eterogenee (es. infrastruttura con web services, CORBA, JMS,..).Per concludere, si tenga presente che un’infrastruttura SOA ben progettata è virtualmente pronta per il porting verso il Cloud Computing.

soa02

Durante la mia attività lavorativa ho maturato una notevole esperienza in abito SOA e ho collaborato alla realizzazione dell’infrastruttura SOA di diverse aziende italiane. Sono, inoltre, autore di diversi seminari sull’argomento e ho partecipato, come relatore, ad alcune conferenze internazionali sulle Service Oriented Architecture.