Cloud SIA V anno

Reti per la pubblica amministrazione

Service-Oriented Architecture Un Service-Oriented Architecture (SOA) è un modello architetturale che supporta l’uso di servizi che soddisfano le richieste degli utenti, rendendo possibile l’utilizzo delle singole applicazioni come componenti dei processi applicativi. Si tratta di un modello architetturale per la creazione di sistemi residenti su una rete che focalizza l’attenzione sul concetto di servizio. 3

I servizi del SOA Un sistema costruito seguendo la filosofia SOA è costituito da applicazioni, chiamate servizi, ben definite e indipendenti l’una dall’altra, che risiedono su più computer all’interno di una rete. Ogni servizio mette a disposizione una certa funzionalità e può utilizzare quelle che gli altri servizi hanno reso disponibili, realizzando in questo modo applicazioni di maggiore complessità. Quindi, utilizzando modelli architetturali di tipo service oriented, si possono modificare sia le modalità secondo le quali interagiscono i servizi, sia le combinazioni dei servizi stessi che vengono fruiti per realizzare un processo; allo stesso modo risultano semplificate le operazioni di aggiunta di servizi e la modifica di processi per rispondere alle specifiche esigenze di business: il servizio NON è più vincolato a una specifica piattaforma o a un’applicazione, ma può essere considerato come un componente riutilizzabile nell’ambito di processi di business differenti. 4

Campi di applicazione del SOA Il modello architetturale orientato ai servizi si applica preferibilmente ai sistemi che si mostrano particolarmente complessi sia nei processi che nelle applicazioni; questo deriva dal fatto che le interazioni tra diverse realtà vengono facilitate, permettendo contemporaneamente che le attività applicative sviluppino processi efficienti sia all’interno che all’esterno dei sistemi stessi, aumentandone l’adattabilità e la flessibilità. 5

Campi di applicazione del SOA Il modello architetturale orientato ai servizi si applica preferibilmente ai sistemi che si mostrano particolarmente complessi sia nei processi che nelle applicazioni; questo deriva dal fatto che le interazioni tra diverse realtà vengono facilitate, permettendo contemporaneamente che le attività applicative sviluppino processi efficienti sia all’interno che all’esterno dei sistemi stessi, aumentandone l’adattabilità e la flessibilità. 6

Possibili elementi di una SOA Nella figura sono mostrati i possibili elementi di una SOA. Come si può facilmente notare, i servizi sono solo una parte della struttura, anche se sono il fulcro delle SOA. In un servizio non è importante come vengano realizzate le funzionalità stesse (Business Logic e Data), è invece fondamentale che la parte di Contratto (Contract) e quella di Interface seguano le specifiche definite. Anche il Service Repository è una parte fondamentale, è infatti su questa che i servizi della SOA sono registrati per poi essere erogati tramite l’Application front-end, utilizzando il Service Bus. 7

Caratteristiche delle SOA L’astrazione delle SOA NON è legata ad alcuna specifica tecnologica, ma semplicemente definisce alcune proprietà, orientate al riutilizzo e all’integrazione in un ambiente eterogeneo, che devono essere rispettate dai servizi che compongono il sistema. In particolare un servizio dovrà avere le seguenti caratteristiche: Ricercabile e recuperabile dinamicamente Autocontenuto e modulare Definito da un’interfaccia e indipendente dall’implementazione Debolmente accoppiato con altri servizi (loosely coupled) Reso disponibile sulla rete Corredato da un’interfaccia possibilmente a “grana grossa” (coursed-grained) Realizzato in modo tale da permetterne la composizione con altri 8

Web Service Una tecnologia applicabile per implementare un’architettura SOA è quella dei Web Services, un sistema software web progettato per supportare l’interoperabilità tra diversi sistemi che cooperano su una stesa rete. Una delle caratteristiche fondamentali di un Web Service è quella di esporre un’interfaccia software descritta secondo formati che possano essere gestiti automaticamente. Tramite tale interfaccia, i sistemi possono fruire delle prestazioni erogate dal Web Service effettuando chiamate alle operazioni descritte nell’interfaccia tramite messaggi ad-hoc. Tali messaggi sono trasportati tramite il protocollo HTTP e formattati secondo lo standard XML. 9

Pila protocollare Web Service La pila protocollare dei Web Service è principalmente basata sui seguenti elementi: SOAP UDDI WSDL WS-Security WS-Reliability 10

Caratteristiche delle SOA I Web Services sono applicabili sia a piccole reti locali sia al caso generico di Internet. La funzionalità più innovativa dei Web Services e delle SOA è la possibilità di creare sistemi che cooperino in maniera completamente disaccoppiata, infatti l’interfaccia standard esposta dal Web Service consente al sistema utente di fruire dei servizi senza conoscere le procedure che vengono svolte nel lato del sistema erogante. 11

Caratteristiche delle SOA Altra innovazione introdotta dai Web Services è quella di permettere di modificare le applicazioni che erogano i servizi in maniera del tutto “trasparente” all’interfaccia esposta; questo significa che mantenendo stabile l’interfaccia, il programma, o più in generale il sistema erogatore, può cambiare senza creare problemi all’interoperabilità tra i sistemi che cooperano. La flessibilità, data dalla possibilità di disaccoppiare il Web Service dalla logica applicativa che effettivamente fornisce la prestazione, consente la creazione di sistemi software complessi costituiti da componenti svincolati l’uno dall’altro e un alto livello di riusabilità del codice e di applicazioni già sviluppate. 12

Paradigma find-bind-execute L’interazione fra i Web Services avviene sulla base del paradigma find-bind-execute: find: dove il servizio viene ricercato sui sistemi di registro, tipicamente i registri UDDI nel caso dei Web Services bind: dove il client si collega al sistema server del servizio che vuole eseguire execute: dove il client accede al Web Service eseguendo le procedure fornite dal sistema server 13

Attori di un sistema SOA Gli attori di un sistema SOA sono tre: Service Provider Service Consumer Service Registry 0. Il Service Provider è un’entità che mette a disposizione un servizio. Tale servizio, per poter essere trovato da altre entità che vogliono utilizzarlo, deve essere reso visibile sulla rete, in termine tecnico deve essere pubblicato. 1. Per fare ciò, il Service Provider comunica al Service Registry le informazioni relative al servizio, in modo che vengano memorizzate. Il Service Registry possiede quindi le informazioni, come URL e modalità d’accesso, di tutti i servizi disponibili. 2. Nel momento in cui un Service Consumer dovrà utilizzare un servizio, farà richiesta delle informazioni relative al Service Registry. 3. Tramite queste informazioni il Service Consumer potrà comunicare direttamente con il Service Provider e utilizzare il servizio. 14

Architettura a oggetti distribuiti Tutte queste interazioni passano attraverso quella che in figura è indicata genericamente come rete di comunicazione, la quale in un’implementazione reale di una SOA può essere costituita sia da Internet sia da una intranet. SOA definisce, dunque, le caratteristiche che i componenti facenti parte di un sistema devono avere al fine di poter definire quest’ultimo un’architettura orientata ai servizi. Il concetto di Web Service implica quindi un modello di architettura a oggetti distribuiti (oggetti intesi come applicazioni), che si trovano localizzati in punti diversi della rete e su piattaforme di tipo differente. Il legame con l’architettura SOA sta nel fatto che, sfruttando al meglio tutte le caratteristiche della tecnologia dei Web Service, il sistema che si ottiene implementa proprio un’architettura orientata ai servizi. A oggi i Web Service rappresentano la soluzione migliore per la realizzazione di una SOA su larga scala, ovvero su Internet. 15

UDDI La presenza del Service Registry è ciò che rende il sistema un’architettura Service-Oriented (SOA). Per implementare il Service Registry, i Web Services fanno uso di UDDI (Universal Decription, Discovery and Integration) , un servizio di registro pubblico in cui le aziende possono pubblicare e ricercare Web Services. L’UDDI mantiene le informazioni relative ai servizi, come l’URL e le modalità d’accesso. Anche UDDI è un Web Service che mette a disposizione due operazioni: Publish, per la registrazione Inquiry, per la ricerca Si ottiene, così, quella che molti considerano la migliore soluzione per implementare un sistema Service Oriented. 16

Schema SOA Nella figura è riportata la schematizzazione del funzionamento di un sistema con architettura SOA, realizzato attraverso l’uso dei Web Services. 17

Simple Object Access Protocol SOAP (Simple Object Access Protocol) è un protocollo di trasmissione di messaggi in formato XML che permette a un’applicazione di inviare un messaggio XML a un’altra applicazione. Un messaggio è costituito da una trasmissione in un senso, dal mittente al ricevente, ma si possono avere uno o più messaggi, che definiscono il tipo di comunicazione che stiamo stabilendo come segue: - one-way; - request-response; - solicit-response; - notification. 18

SOAP, protocollo ad alto livello SOAP è un protocollo ad alto livello, indipendente dal protocollo di trasmissione sottostante. Un messaggio SOAP è costituito da un contenitore, chiamato Envelope, all’interno del quale vengono distinte due sezioni principali denominate: Header, intestazione del messaggio Body, corpo del messaggio 19

Funzionalità UDDI Due Web Services possono comunicare tra loro solo se l’uno conosce locazione e modalità di accesso dell’altro. L’UDDI è il sistema che si occupa di far conoscere quali Web Services mettono a disposizione una certa funzionalità e facilitare la ricerca di Web Services secondo certi criteri come la tipologia del servizio. Ciò che il database distribuito UDDI mette a disposizione è un registro nel quale si può accedere per: permettere all’azienda di pubblicare/ricercare servizi avere informazioni comprensibili all’utente, circa l’azienda avere informazioni tecniche, comprensibili e utilizzabili dalla macchina, relative a un servizio, in modo da potersi connettere. 20

Interoperabilità A livello software, per interoperabilità si intende la capacità di differenti programmi o sistemi informatici di scambiare dati tramite gli stessi protocolli o le stesse procedure o leggere e scrive file dello stesso formato. Spesso il software realizzato senza una progettazione che tenga in considerazione la standardizzazione delle procedure effettuate dal prodotto manca di interoperabilità. 21

Interoperabilità e SOA Esistono diverse modalità per garantire l’interoperabilità dei sistemi informatici: una di queste è utilizzare modelli architetturali di tipo orientato ai servizi. 22

Interoperabilità e PA Nel nostro paese il modello per l’interoperabilità fra i sistemi informatici della Pubblica Amministrazione è definito dal SPCoop (Sistema Pubblico di Cooperazione), parte del progetto SPC (Sistema Pubblico di Connettività e Cooperazione). Il Sistema Pubblico di Cooperazione si caratterizza per l’approccio a 360 gradi che ha riguardato sia gli aspetti normativi che quelli tecnici e organizzativi, curando particolarmente la condivisione del metodo e dei risultati fra tutti gli interlocutori coinvolti, amministrazioni centrali e locali e operatori del settore ICT. 23

Sistema Pubblico di Connettività e Cooperazione All’interno del SPC le amministrazioni pubbliche italiane interagiscono in rete attraverso il Sistema Pubblico di Connettività e Cooperazione, costituito da due livelli di servizi infrastrutturali: - il Sistema Pubblico di Connettività, che ha come obbiettivo quello di fornire una infrastruttura di rete affidabile e sicura; il Sistema Pubblico di Cooperazione, il cui scopo è quello di fornire un framework per l’interoperabilità fra servizi applicativi. Nella seguente figura viene mostrata l’architettura del Sistema Pubblico di Connettività e Cooperazione; si può vedere come il SPCoop si appoggi sui servizi offerti dallo strato di connettività. 24

Il modello comune della PA Il Sistema Pubblico di Connettività e Cooperazione permetterà di vedere tutti i servizi di ogni amministrazione pubblica, centrale o locale, in maniera integrata e indipendente dal canale di erogazione. Per questo è stato necessario definire un modello comune di interazione online tale da valorizzare la specificità di ogni erogatore di servizi così che possa assicurare allo stesso tempo uniformità di interazione e certezza nell’identificazione dell’erogatore e del fruitore, o allo stesso modo degli attori dell’interazione. 25

SPC della PA SPC, quindi, da una parte definisce le regole (indicazioni, linee guida e così via) e dall’altra deve occuparsi di gestire tutta una serie di servizi condivisi attraverso diverse tecnologie. 26

Fasi di realizzazione SPC Nella prima fase di realizzazione di SPC, i contratti-quadro stipulati da DigitPA sono stati lo strumento che ha consentito alle amministrazioni di usufruire di un insieme di funzioni relative alla connettività, alla interoperabilità e cooperazione applicativa e alla gestione di sistemi informativi. Nell’evoluzione di SPC, i contratti-quadro continueranno a essere lo strumento di riferimento per le amministrazioni, ma renderanno disponibili una suite di macro-funzionalità che consentirà alle amministrazioni di erogare prestazioni che declinano le proprie missioni istituzionali, anche al fine di realizzare servizi finali per cittadini e imprese, in linea con le iniziative europee per la digitalizzazione delle amministrazioni pubbliche. 27

Prima dell’SPC La legge n. 59 del 15 marzo 1997 ha provveduto a colmare la lacuna di un’unica rete, omogenea per qualità sicurezza e costi che aveva caratterizzato le pubbliche amministrazioni fino agli anni Novanta. Questa rete unitaria ha rappresentato per le amministrazioni centrali la piattaforma di sviluppo delle applicazioni; le precedenti reti delle amministrazioni si sono evolute in reti IP, favorendo l’utilizzo della posta elettronica e del Web. 28

Il Sistema Pubblico di Connettività Attualmente si sta convertendo in un sistema più moderno, denominato Sistema Pubblico di Connettività, la Rete unitaria della Pubblica Amministrazione (RUPA), che collegava la quasi totalità delle sedi delle pubbliche amministrazioni centrali. Poichè il Sistema Pubblico di Connettività costituisce l’ossatura di rete del sistema di interconnessione italiana, il suo sviluppo risulta prioritario rispetto a quello dei servizi tra i soggetti interoperanti. 29

Usi SPC Il Sistema Pubblico di Connettività permette di attivare lo scambio di servizi fra soggetti pubblici in una logica Government to Government (G2G), mentre la contemporanea interconnessione a Internet garantisce la fruibilità dei servizi stessi da parte dei cittadini e delle imprese in una logica di G2C (Government to Citizen). Il Sistema Pubblico di Connettività è da intendersi anche come una infrastruttura abilitante per lo sviluppo di applicazioni cooperative fra PA centrali, fra PA locali, fra PA centrali e locali, fra PA e imprese/cittadini. La seguente figura illustra l’architettura schematizzata della Qualified Exchange Network (QXN) del Sistema Pubblico di Connettività. 30

Intranet e Community Network Ciascuna amministrazione (PA) ha dunque una propria intranet servita da un unico fornitore (Q-ISP) che costituisce il dominio interno alla singola amministrazione e ne connette tutte le sue sedi distribuite sul territorio. La connessione con amministrazioni servite da altri fornitori è assicurata dalla QXN, a cui possono collegarsi direttamente anche le Community Network pubbliche che si qualificano allo scopo (QCN, Qualified Community Network). 31

SPCoop La progettazione e lo sviluppo del Sistema Pubblico di Cooperazione in CNIPA prendono il nome di SPCoop. Il progetto SPCoop (Sistema Pubblico di Cooperazione), che si occupa di curare lo sviluppo della cooperazione applicativa, è l’altra parte del SPC. 32

Obiettivi SPCoop L’obiettivo dell’architettura di cooperazione applicativa è quello di permettere l’integrazione dei processi e dei dati di amministrazioni diverse basati su sistemi informatici estremamente eterogenei. La cooperazione tra differenti amministrazioni, e in generale tra soggetti pubblici, richiede la definizione di un modello di cooperazione che sia: - indipendente dagli assetti organizzativi dei soggetti cooperanti; - indipendente dai sistemi informatici interni dei soggetti cooperanti; - progettato in maniera rigorosa e sostenibile, tale che la sua evoluzione sul medio termine sia già pensata sin dall’inizio, con passi ben delineati. 33

Rappresentazione SPCoop 34

Principi base del SPCoop I principi su cui si basa il SPCoop sono: Cooperazione tra amministrazioni Ambito di responsabilità Accordi Tecnologie di cooperazione 35

Cooperazione tra amministrazioni Per mezzo dell’erogazione e della fruizione di Servizi Applicativi le amministrazioni cooperano; ogni amministrazione offre questi servizi tramite un unico elemento del proprio sistema informativo denominato Porta di Dominio (PDD). L’amministrazione gode di completa autonomia grazie a questo principio, in fase di progettazione, realizzazione e gestione dei Servizi Applicativi. I servizi applicativi vengono fruiti attraverso lo scambio di messaggi applicativi, secondo il formato definito nel documento di specifica della busta di e-Gov. 36

Ambito di responsabilità La responsabilità dei servizi erogati e dei dati forniti attraverso questi è attribuita alla singola amministrazione cooperante, che apparirà come un singolo dominio con responsabilità del singolo elemento e non del dominio stesso. 37

Tecnologie di cooperazione I servizi applicativi vengono erogati/fruiti attraverso tecnologie e standard indicati genericamente come Web Service, in questo modo qualsiasi funzionalità diventa esportabile e utilizzabile in remoto. Tali caratteristiche rendono SPCoop un modello con molte attinenze alle SOA descritte precedentemente e hanno portato a vedere l’architettura del SPCoop come la declinazione di una SOA adattata alle necessità della PA con: necessità di disaccoppiamento tra le applicazioni eterogenee che attualmente vengono utilizzate nelle differenti amministrazioni e i servizi erogati in rete, necessità di avere una interfaccia che permetta di interagire a un livello superiore di quello della logica applicativa, unita alla necessità di rendere utilizzabili i sistemi già presenti nelle amministrazioni locali e centrali. 38

SICA Un altro componente di rilevante importanza nel modello sono i Servizi di Interoperabilità, Cooperazione ed Accesso (SICA), che offrono una serie di servizi e componenti software infrastrutturali non riconducibili a nessuna amministrazione specifica, il cui obiettivo è mediare e supportare la cooperazione tra le amministrazioni. 39

Funzionalità del SICA Le varie funzionalità svolte dai SICA sono: - la specifica di come un Accordo di Servizio e di Cooperazione deve essere costruito, formalizzato e composto; - la specifica di come tutti gli elementi “nominabili” nella cooperazione devono essere identificati, secondo uno specifico schema di nomenclatura; - la specifica di un modello di sicurezza, che definisce i requisiti di sicurezza che devono essere garantiti da tutti gli elementi del sistema; - i Servizi di Registro SICA; - il Catalogo degli Schemi SICA; - i Servizi di Indice dei Soggetti; - i Servizi di Sicurezza SICA; - i Servizi di Supporto al Controllo e Gestione. 40

SICA, elemento neutro di mediazione È importante notare, infine, che TUTTE le architetture a servizi/SOA richiedono la presenza di un elemento “logicamente” neutro, con il compito di mediare tra i differenti soggetti che cooperano attraverso l’erogazione/fruizione di servizi. Il SICA costituisce di fatto tale elemento mediatore, dotato di funzionalità evolute in virtù del fatto che il modello di cooperazione proposto prevede la gestione non solo degli aspetti di base, ma anche e soprattutto di alcuni aspetti avanzati dei Web Services. 41

Architettura del SPCoop Come detto, gli elementi fondamentali dell’architettura del SPCoop sono: l’Accordo di Servizio, i Servizi SICA, la busta di e-Government e la Porta di Dominio. 42

Accordo di Servizio L’Accordo di Servizio è la descrizione formale dei servizi applicativi, cioè dell’applicazione software che può essere invocata in remoto da un soggetto interessato. Gli aspetti del servizio che sono descritti nell’Accordo di Servizio sono: 1. interfaccia del servizio, intesa come insieme di operazioni offerte; 2. protocollo conversazionale del servizio; 3. punti d’accesso presso cui effettivamente il servizio è dispiegato; 4. livelli di qualità del servizio garantiti (SLA); 5. requisiti e caratteristiche di sicurezza del servizio; 6. descrizione della semantica del servizio e della semantica dell’informazione veicolata dal servizio. 43

Servizio di registro SICA Un componente nevralgico del SPCoop è il Servizio di Registro SICA che, semplificando, ha il compito di garantire la gestione di tutti gli aspetti dell’Accordo di Servizio, mettendo a disposizione tutte le funzioni necessarie allo scopo. 44

Porta di Dominio e Busta di e-Gov La Porta di Dominio (PDD) e la Busta di e-Gov rappresentano rispettivamente l’interfaccia tramite la quale interoperano le amministrazioni e il protocollo con il quale le PDD comunicano tra loro. Nel descrivere in modo più specifico che cos’è una PDD, si può dire che tutti i servizi applicativi sono erogati/fruiti attraverso questo unico elemento logico. Di fatto la PDD è la piattaforma presso cui sono disponibili le interfacce applicative dei servizi, non necessariamente i componenti software che realizzano tali servizi sono poi ospitati sulla stessa piattaforma della PDD. 45

Porta di Dominio PPD Nel descrivere in modo più specifico che cos’è una PDD, si può dire che tutti i servizi applicativi sono erogati/fruiti attraverso questo unico elemento logico. Di fatto la PDD è la piattaforma presso cui sono disponibili le interfacce applicative dei servizi, non necessariamente i componenti software che realizzano tali servizi sono poi ospitati sulla stessa piattaforma della PDD. 46

Busta di e-Gov La Busta di e-Gov è il protocollo applicativo con cui i servizi applicativi sono invocabili in maniera remota ed è una estensione dello standard SOAP, necessaria al fine di supportare la sicurezza point-to-point, l’affidabilità della trasmissione e la tracciatura di tutte le comunicazioni (aspetti avanzati non ancora standardizzati a livello SOAP). La Busta di e-Gov è un’estensione di SOAP specificatamente progettata per SPCoop. Prevede l’utilizzo di un header appositamente predisposto, elaborato dalle Porte di Dominio, in grado di veicolare tutte le informazioni necessarie per implementare le suddette funzionalità, tutto questo in maniera trasparente alle applicazioni che fanno uso delle porte. 47

Struttura Busta di e-Gov La Busta di e-Gov è logicamente suddivisa in due parti: una contiene tipicamente informazioni infrastrutturali, l’altra veicola il contenuto applicativo del servizio oggetto della interazione. Per riassumere… Una Porta di Dominio è una piattaforma in grado di offrire servizi applicativi in maniera tale da poter essere invocati da remoto secondo le specifiche della Busta di e-Gov. 48

Comunicazione tra porte La figura mostra un esempio di comunicazione tra porte: 49

Accordo di servizio L’Accordo di Servizio è il cardine del ciclo di vita del servizio. I servizi SPCoop sono obbligatoriamente gestiti per versioni dell’Accordo di Servizio. Più versioni di uno stesso servizio (corrispondenti a versioni diverse dell’Accordo di Servizio) possono essere erogate nello stesso momento. Ogni versione segue UN ciclo di vita autonomo, che è definito dal soggetto responsabile dell’Accordo di Servizio stesso. 50

Ciclo di vita del servizio Per ogni versione del servizio applicativo, il ciclo di vita è composto da 6 fasi: 1. Definizione accordo di servizio. 2. Registrazione accordo di servizio sul registro SICA nazionale generale. 3. Implementazione del servizio. 4. Presentazione del servizio sul SPCoop. 5. Erogazione/fruizione del servizio sul SPCoop. 6. Dismissione dell’accordo di servizio e del servizio dal SPCoop. 51

Rappresentazione ciclo di vita del servizio Come mostra la figura, l’erogazione di un servizio ha bisogno di un’infrastruttura contente tutte le operazioni che ne costituiscono il ciclo di vita: 52