Introduzione
Nelle ultime quatto decadi i sistemi informativi sono cresciuti in maniera esponenziale, obbligando le aziende a gestire architetture software sempre più complesse. Le architetture "tradizionali" non riescono più a soddisfare tutte le richieste di flessibilità e riduzione dei costi imposte dal mercato. L'industria del software si è evoluta attraverso soluzioni diverse atte principalmente ad ottenere architetture distribuite, linguaggi di programmazione multipiattaforma, ridurre i tempi di sviluppo ed attraverso miriade di prodotti progettati per una migliore e più veloce integrazione delle applicazioni. Nonostante gli enormi passi avanti, la soluzione completa continua a "sfuggire".
Al momento il mondo dei sistemi distribuiti è in una fase di intensa transizione che vede come motore trainante il business e l'avanzamento di una nuova visione dove le funzionalità offerte dai vari asset software, sono viste come servizi distribuiti sulla rete ( SOA -- Service Oriented Architecture ). SOA promette di essere la risposta alla richiesta di flessibilità per ambienti eterogenei ed altamente dinamici.
Essenzialmente SOA ha lo scopo di fornire agli utenti servizi di alto livello e di facile comprensione, che possono essere integrati nei processi aziendali secondo le necessità. Il passaggio ad una visione architetturale orientata ai servizi, prevede la costituzione di un layer di astrazione che nasconde la complessità ed eterogeneità degli odierni sistemi informativi.
La strada verso la Business Agility
Nonostante il concetto di architetture distribuite ed orientate ai servizi non sia nuovo, basti ricordare DCOM (Distributed Component Object Mode) e CORBA (Common Object Request Broker Architecture), la novità introdotta da SOA è l'utilizzo di standards, in particolare Web Services. I Web Services forniscono interfacce standard alle funzionalità software. I fornitori di Servizi possono pubblicare le informazioni utili all'utilizzo di questi ultimi in un registro, mentre chi necessità di nuove funzionalità (Consumer) può semplicemente ottenere le informazioni necessarie per l'utilizzo consultando il registro dei servizi. Le già citate tecnologie CORBA e DCOM, nonostante forniscano funzionalità simili a SOA, soffrono di alcune mancanze. Prima fra tutte la "stretta dipendenza implementativa", ossia ogni nodo dell'architettura distribuita deve conoscere i dettagli di funzionamento degli altri partecipanti: una modifica al codice di un' oggetto distribuito richiede una successiva modifica al codice che accede all'oggetto. In secondo luogo le attuali implementazioni sono strettamente proprietarie e quindi legate ad un prodotto. Il connubio Web Services - SOA risolve le problematiche riscontrate nell'utilizzo di CORBA e DCOM basandosi su tre proprietà fondamentali:
Indipendenza dei componenti: il problema fondamentale delle tradizionali architetture distribuite è la mancanza di indipendenza dei componenti, questo significa che la progettazione di ogni componente di sistema deve essere condotta avendo bene in mente il funzionamento degli altri componenti. Risulta evidente, quindi, che , effettuare una modifica ad un componente spesso richiede una revisione completa dell'architettura.
Minor granularità: tra i metodi più adottati per lo scambio di informazioni/richieste tra applicazioni si annovera l'utilizzo di API..Un' API non è altro che una serie di chiamate scritte in un particolare linguaggio ed utilizzate per lo scambio di informazioni con un' applicazione. Questo approccio richiede un forte livello di granularità dei messaggi, in quanto prevede, per sistemi che necessitano di cooperare tra di loro, lo scambio di numerosi e dettagliati messaggi per effettuare un'azione complessa. L'utilizzo di Web Services permette l'accorpamento di molte chiamate in unico messaggio realizzando "chiamate di business".La definizione del corretto livello di granularità è uno dei punti chiave di SOA. Questo è un argomento abbastanza soggettivo, ma parlando più in generale i servizi esposti all'esterno devono fornire operazioni che corrispondono a funzioni di business. Questo non significa che tutti i componenti siano obbligati ad esporre solo funzionalità complesse. I componenti di basso livello possono essere utilizzati dai servizi di business, ma non devono essere esposti all'esterno. Come si vede in figura 1 il livello di granularità diminuisce risalendo la piramide. All'utente finale viene fornita visibilità sui servizi di business attraverso l'utilizzo di un'applicazione che "nasconde" un motore di Workflow.
Asincronismo: la comunicazione sincrona consiste in uno scambio di messaggi in cui il mittente attende risposta sospendendo ogni sua attività. La visione di una pagina web è un tipico esempio di comunicazione sincrona. Al contrario una richiesta asincrona permette al mittente di non sospendere a propria attività in attesa di risposta dal destinatario, come per esempio l'invio di una e-mail. I Web Services basati su SOA permettono l'invio e la ricezione di messaggi sincroni ed asincroni.
Le tre proprietà sopra descritte forniscono un livello di astrazione che nasconde la complessità dei dettagli implementativi agli utenti, i quali si limitano ad utilizzare i servizi esposti.
Le funzionalità e flessibilità che SOA può offrire sono considerevoli. Se un'organizzazione astrae la sua infrastruttura presentando le proprie funzionalità come servizi esposti, l'utente che deve utilizzare tali servizi può accedervi in modo indipendente dalla tecnologia sottostante. La differenza tra l'utilizzo di SOA e gli altri approcci architetturali è "l'agilità" (Business Agility) che SOA offre, intesa come la capacità di rispondere velocemente ed efficacemente ai cambiamenti.
Piuttosto che promuovere un massiccio rifacimento delle architetture, l'approccio orientato ai servizi abbraccia il concetto di eterogeneità dei sistemi rivalutando fortemente le esistenti tecnologie legacy, riducendo l'investimento necessario per proporre nuove funzionalità.
Il metamodello di SOA
Il punto di partenza per la realizzazione di SOA è rendersi conto che SOA è prima di tutto un'architettura applicativa in cui tutte le funzioni sono definite come servizi indipendenti ed accessibili attraverso interfacce predefinite, che possono essere interrogati in una sequenza prestabilita per formare un flusso di business.
Il modo migliore per visualizzare il concetto è attraverso l'uso di modelli che sono una rappresentazione concettuale del sistema. La struttura del modello che sta alla base delle architetture SOA è definita tramite il metamodello riportato in figura 2.
Il cuore del metamodello è il Service Model che rappresenta i servizi offerti. L'ovale a sinistra chiamato Business Model rappresenta gli utenti e le funzionalità richieste. Sulla destra sono presenti gli Implementation Model che rappresentano le tecnologie a supporto dei servizi.
E' importante notare che non esiste collegamento diretto tra i Business Model e Implementation Model -- questo legame passa sempre attraverso il Service Model. Il Service Model diviene il punto di contatto tra la visione di business e tecnologica, ed agisce come link di comunicazione. Gli utenti business possono lavorare con servizi di granularità maggiore orchestrandoli in processi complessi sulla base delle necessità imposte dal mercato. Gli utenti tecnici, al contrario, lavorano per costruire e mantenere il livello di astrazione che suddivide i servizi e le tecnologie.
Attraverso l'incapsulamento dei componenti software, delle applicazioni, ed dei sistemi sottostanti con le interfacce dei Web Services e virtualizzando le funzionalità di basso livello in servizi business di più alto livello, le aziende otterranno così un' infrastruttura IT più flessibile e più Agile.
Service Oriented Management: la tecnologia che porta a SOA
Nonostante il livello di astrazione fornito da SOA nasconda l'architettura, i sistemi e le applicazioni sottostanti, questi ultimi continuano ad essere presenti. I responsabili dei sistemi informativi devono dunque continuare a gestire l'infrastruttura sottostante ed inoltre sono vincolati alla necessità di amministrazione introdotte dall'utilizzo dei Web Services. Il management dei Web Services è una combinazione delle attuali tecniche di gestione con le nuove tecniche di gestione orientate ai servizi.
Le basi del Service Oriented Management
Colmare il gap tra sistemi e servizi è logicamente più complesso di gestire i singoli sistemi sottostanti. Come risultato sono introdotte nuove funzionalità che possono essere raggruppate in cinque categorie: system management, Web Services lifecycle management, business-oriented management, security management e "SOA Enablement", come mostrato nella tabella 1.
Web Services System Management
Poiché i Web Services sono componenti software che necessitano di sistemi hardware per funzionare, tutti i prodotti di Web Services management devono prendere in considerazione il problema di gestione dei sistemi. Le funzioni incluse nella categoria di System Management sono:
Monitoring - controllo dello stato dei sistemi;
Alerts -- sistemi di notifica in caso di problemi;
Auditing & Reporting - tenere traccia dell'utilizzo dei WebServices e rendere disponibili queste informazioni al servizio di reporting;
Service Level Agreement (SLA) e Quality of Service (QoS) management - tenere traccia della qualità dei servizi offerti (uptime, latenza, etc. ..) ed eventualmente adattare i criteri di performance per assicurare ad ogni cliente il servizio che ha richiesto;
Gestione delle eccezioni - gestione dei problemi insorti seguendo le politiche precedentemente definite per affrontare le possibili eccezioni;
Analisi delle problematiche - scavare attraverso vari livelli di funzionalità (Web Service, applicazione , application server, rete, sistema operativo, hardware) per individuare la vera causa del problema.
Lifecycle Management
Oltre a controllare che il sistema sottostante funzioni correttamente, le piattaforme di gestione dei WebServices spesso si occupano anche di gestire il processo di inserimento di nuovi servizi in produzione, e amministrarne le modifiche successive. Le funzionalità che cadono all'interno della categoria di lifecycle management sono:
Provisioning -- inserimento di nuovi WebService in produzione e rendere disponibili al consumer le informazioni necessarie all'utilizzo;
Versionamento -- gestione e manutenzione di differenti versioni dello stesso prodotto che possono trovarsi in produzione nello stesso momento;
Dismissione -- ritirare dalla produzione servizi oramai datati, senza creare indisponibilità agli utenti;
Dipendenze -- occuparsi delle modifiche effettuate ad un servizio verso cui sono in atto dipendenze funzionali di altri WebServices;
Gestione delle configurazioni -- gestione di configurazioni diverse di uno o più WebServices ad ogni modifica o upgrade del servizio;
Emulazione di WebService -- simulazione di gruppi di WebServices per test.
Business Management
Solitamente le piattaforme di Web Services Management oltre a fornire strumenti di amministrazione e di controllo del ciclo di vita dei sistemi, forniscono anche visibilità e controllo a supporto del il business management. Le funzionalità di questa categoria sono:
Collaboration management -- permettere ai business manager di comprendere il modo di utilizzo dei WebServices;
Gestione dei processi di business -- gestione dei processi di business abilitati dai WebServices;
Supporto alle decisioni -- permettere l'accesso alle informazioni di business necessarie per prendere le decisioni;
Gestione delle transazioni -- controllo e monitoring delle transazioni di business;
Prioritizzazione dei messaggi -- controllo degli utenti che hanno ottenuto l'accesso a particolari WebServices, specialmente quando questi servizi non sono in grado di gestire equamente tutte le richieste;
Controllo delle attività di business;
Amministrazione e fatturazione -- determinare l'utilizzo di ogni servizio ed il passaggio di queste informazioni ad un sistema di controllo e/o fatturazione;
Revenue Management - controllo del flusso di revenue ottenuto attraverso i vari WebServices.
Security Management
Le funzionalità incluse in questa categoria sono:
Autenticazione e controllo accessi -- assicurarsi di autorizzare l'accesso ai WebServices solo a utenti ed applicazioni autorizzate;
Confidenzialità -- Cifratura dei messaggi;
Malicious attack -- prevenzione di accesso non autorizzati ai servizi, incluso attacchi diretti a penetrare il servizio;
Non ripudio -- fornire gli strumenti per il controllo di invio e ricezione dei messaggi.
Service Oriented Architecture Enablement
La più importante delle categorie di funzionalità evidenziate può andare sotto il nome di SOA Enablement: attività che si concentra sul controllo di disponibilità ed affidabilità dei servizi di business e dei processi che li connettono. Fondamentalmente, questa categoria di funzionalità si compone:
Virtual Web Service -- creazione di cluster di web service per gestire alta affidabilità.
Conversione sincrono/asincrono -- se uno dei sistemi sottostanti non è in grado di rispondere alla richiesta in real time, la piattaforma di gestione deve rispondere con un messaggio automatico "la vostra richiesta è in fase di elaborazione" , e poi inviare il risultato desiderato quando disponibile;
Gestione dei servizi -- prendere ogni servizio di basso livello (tipicamente wrapper per ogni applicazione esistente) e combinarli in servizi business;
Gestione delle istanze -- preservare le proprietà di indipendenza dalla locazione di SOA permettendo a sistemi differenti presenti in luoghi diversi di fornire particolari WebServices;
Routing dinamico -- invio delle richieste a sistemi differenti in base alla disponibilità, per preservare l'indipendenza dalla locazione e migliorare le performance del sistema;
Traduzione di protocollo -- traduzione di protocolli e messaggi di diversi formati incluso SOAP, Java messagging, middleware orientati ai messaggi come IBM WebSphere MQ (MQSeries), DCOM, ed altri così che sistemi non esposti come WebServices possano partecipare nell'architettura SOA.
L'azienda che intenda passare a SOA dovrà quindi implementare un'infrastruttura di gestione che possa supportare , senza modifiche sostanziali, le necessità di performance e controllo imposte dai nuovi servizi messi in produzione.
I criteri di sicurezza per la realizzazione di un'architettura SOA
Per capire pienamente come la sicurezza deve essere implementata e gestita in un'architettura orientata ai servizi, è necessario in primo luogo capire i principi della sicurezza applicativa. La sicurezza, nel suo significato più ampio, viene intesa come capacità di mitigare i rischi; la sicurezza applicativa, in particolare, è volta a ridurre l'esposizione ai seguenti attacchi:
Eavesdropping: questo attacco si concretizza nella compromissione della riservatezza del messaggio senza però modificarne la forma.
Tampering: una persona non autorizzata, modifica o sostituisce un messaggio in transito.
Impersonation: l'informazione giunge a una persona che non è il destinatario prefissato. Questo tipo di attacco può presentarsi in una duplice forma attraverso l'impersonificazione del destinatario (spoofing), attraverso l'esposizione di credenziali fasulle (Mispresenation).
Ognuno di questi attacchi lede i cinque requisisti che devono essere propri di ogni sistema di sicurezza. In un'applicazione "lo strato" che implementa la sicurezza deve garantire:
Auteniticazione: il destinatario deve essere sempre in grado di verificare l'identità del mittente.
Autorizzazione: l'accesso ai dati deve sempre essere vincolato da criteri che ne definiscono, previa autenticazione, le azioni (lettura, scrittura) che possono essere intraprese dai differenti utenti.
Confidenzialità: il contenuto di un messaggio deve essere disponibile solamente per gli utenti autorizzati.
Integrità: il messaggio durante il transito non deve subire modifiche.
Non ripudio: Il "non ripudio" permette di provare l'identità di tutte le parti che hanno partecipato ad una transazione anche successivamente allo scambio del messaggio.
Autenticazione e Autorizzazione sul meta-level
Il fine dell'autorizzazione e' controllare l'accesso ad alcune risorse (lettura di dati, scrittura, esecuzione di un programma, utilizzo di una struttra hardware ...) mediante la definizione di privilegi. Il metodo più semplice di gestire l'autorizzazione è attraverso l'utilizzo di ACL (Access Control LIst) che definiscono quali sono, le azioni che possono essere condotte su ogni risorsa da un utente. Solitamente l'utilizzo di ACL non è sufficiente per garantire il livello di protezione necessario per ambienti enterprise dove sistemi eterogenei vengono chiamati in causa, sia all'interno della stessa azienda, sia attraverso più aziende. Ogni azienda possiede policy di sicurezza proprie spesso supportate da tecnologie differenti. La gestione dei diritti di autorizzazione estesa su più sistemi e tecnologie, è un problema che viene chiarito da specifiche che prendono il nome di WS-Security. WS-Security definisce un layer di astrazione che permette a infrastrutture differenti di "cooperare in piena fiducia".
Confidenzialità, integrità e non ripudio
Garantire confidenzialità significa assicurare che solo il destinatario possa conoscere i contenuti del messaggio. Il problema di garantire confidenzialità diviene importante, in una realtà orientata ai servizi, in quanto l'utilizzo dei Web Services comporta la gestione del routing del messaggio tra gateway intermedi, utilizzando esclusivamente le informazioni contenute sull'Header SOAP o http: deve esistere un sistema che permetta ad ogni intermediario di leggere, nonostante i metodi di crittazione, le parti del messaggio che gli indicano come gestirlo (routing dinamico), senza però comprometterne la confidenzialità del contenuto. Allo stesso modo la garanzia dell'integrità del messaggio e del non ripudio presentano problematiche, per un ambiente orientato ai servizi, molto simili a quelle appena esposte. Le specifiche WS-security e quelle del linguaggio Security Assertion Markup Language sono volte alla gestione di tale problematiche.
Approcci architetturali a SOM (Service Oriented Management)
I principi fondamentali per la gestione di un sistema IT sono visibilità e controllo. In genere, un prodotto di gestione IT deve fornire visibilità e controllo sullo stato di funzionamento delle tecnologie e dei servizi. Vi sono due approcci architetturali che le soluzioni SOM posso prendere per fornire visibilità e controllo: un'approccio proxy ed un' approccio distribuito.
Un proxy XML è una soluzione hardware o software che accetta in ingresso traffico XML e lo passa avanti con o senza modifiche a seconda delle necessità. Può operare in modalità trasparente o come applicazione ausiliaria sulla rete. Questo componente può essere utilizzato come singolo gateway per tutti i Services interni che l'azienda intende rendere disponibili oppure effettuare attività di proxy verso servizi esterni alla rete locale. Il proxy intercetta i messaggi SOAP per implementare alcune delle funzionalità chiave del management incluso autenticazione, firma digitale, cifratura, affidabilità, compressione, streaming e gestione dello stato.
La soluzione proxy solitamente sottende ad un' approccio centralizzato al problema: il core della soluzione è presente su un unico server (o un cluster di server), ed eventualmente alcune componenti distribuite sulla rete, ma mantenendo comunque la maggior parte delle funzionalità centralizzate in un unico punto. Il punto di forza di questa soluzione si individua nelle possibilità e semplicità di controllo che offre, questo però a scapito di maggior latenza aggiunta ai messaggi XML. Latenza che può non essere tollerate in ambienti che richiedono performance particolari. Come risultato alle problematiche insorte, alcune soluzioni SOM mantengono un approccio decentralizzato e distribuito al management. Al posto di avere un' unico punto centrale di controllo, viene proposta una soluzione di gestione punto-punto distribuita sulla rete. Un' approccio distribuito è infinitamente scalabile, e non introduce latenza nei messaggi XML , ma al costo di un minor livello di controllo rispetto alla soluzione centralizzata.
Conclusione
SOA richiede un'infrastruttura che fornisca funzionalità di managment e Sicurezza per poter mantenere un buon livello di indipendenza tra i Fornitori e i Consumatori dei servizi. Tali funzionalità rappresentano due requisisti fondamentali per implementare efficacemente un'architettura SOA.