UNIVERISTA DEGLI STUDI DELLA BASILICATA Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea Specialistica in Informatica

Save this PDF as:
 WORD  PNG  TXT  JPG

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "UNIVERISTA DEGLI STUDI DELLA BASILICATA Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea Specialistica in Informatica"

Transcript

1 UNIVERISTA DEGLI STUDI DELLA BASILICATA Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea Specialistica in Informatica TESI DI LAUREA SPECIALISTICA CONFRONTO TRA PIATTAFORME OPEN-SOURCE PER IL SISTEMA PUBBLICO DI COOPERAZIONE APPLICATIVA Relatore prof. Giansalvatore MECCA Candidato Nunzia LAGUARDIA matr ANNO ACCADEMICO

2

3 Riassunto Nel 2005 il CNIPA ha terminato la stesura della specifica SPCoop per la Cooperazione Applicativa nella Pubblica Amministrazione. L Università degli Studi della Basilicata ha realizzato una propria implementazione dell infrastruttura necessaria per la cooperazione applicativa dando vita a diversi componenti software come la Porta di Dominio freesbee, il Gestore Eventi freesbeege ed il Sistema di Gestione dei Livelli di Servizio freesbeesla oltre ad un Sistema di Autenticazione Federato che utilizza il componente freesbeesp. Questa tesi presenta i vari componenti del progetto freesbee e li confronta con un altra implementazione open-source della specifica SPCoop realizzata nell ambito del progetto ICAR. Il confronto fra le due infrastrutture mostra in che modo sono stati implementati quegli aspetti della specifica che risultano meno chiari e standardizzati che riguardano il Gestore degli Eventi ed il Sistema di Gestione degli SLA.

4

5 Sommario Introduzione Storia dell informatizzazione della P.A. Italiana Riforma della Pubblica Amministrazione: dagli anni 80 al Riforma della Pubblica Amministrazione: dal 2000 ad oggi SPCoop Un esempio di cooperazione applicativa L architettura SPCoop Tecnologie e Standard SOA Web Services XML SOAP WSDL UDDI LDAP Porta di Dominio Busta e- Gov Accordo di Servizio Servizi di Registro SICA Sicurezza Gestione dei Livelli di Servizio Gestore degli Eventi ESB ICAR Il progetto Tecnologie Impiegate INF Porta di Dominio e NICA Integrazione con altri moduli Installazione e Configurazione Registro Servizi Gestore Eventi Considerazioni INF

6 Formalismo Sistema di Tracciatura Sistemi di Monitoraggio Considerazioni INF Modellazione concettuale Rilascio INF INF- 1, INF- 2 e INF Task Applicativi freesbee Il progetto Metodologia di Sviluppo Porta di Dominio Progettazione tramite EIP freesbee Servizi SICA Installazione e Configurazione Gestore Eventi Gestione Base Filtri Gestione Federata GEControlProtocol Regole freesbeewebge Tecnologie Sistema di Monitoraggio dei Livelli di Qualità dei Servizi freesbeewebsla Regole Tecnologie Sistema di Autenticazione federato Confronto fra le architetture Porta di Dominio Specifiche poco chiare Sistema di Monitoraggio dei Livelli di Servizio Gestore degli Eventi Conclusioni

7

8

9 Introduzione 1 Introduzione Le azioni di informatizzazione intraprese dalla Pubblica Amministrazione fino al 2000 sono state dirette a migliorare l efficienza operativa delle singole amministrazioni. A partire dal 2001 gli sforzi delle amministrazioni pubbliche si sono invece concentrati sull informatizzare l erogazione dei servizi ai cittadini e alle imprese che richiedono l integrazione dei procedimenti di diverse amministrazioni. Nasce così nel 2003 il Centro Nazionale per l Informatica nella Pubblica Amministrazione (CNIPA) con lo scopo di definire: un infrastruttura di rete che consenta l interoperabilità tra tutte le reti delle amministrazioni pubbliche esistenti, denominata Sistema Pubblico di Connettività (SPC); ed un insieme di standard tecnologici e di servizi infrastrutturali che consentano alle applicazioni di un sistema informativo l accesso sicuro e automatico ai servizi applicativi erogati direttamente da altri sistemi informativi denominato Sistema Pubblico di Cooperazione (SPCoop). Nel 2005 Il CNIPA rilascia dieci documenti che definiscono i componenti di base, il modello architetturale, gli standard tecnologici e di sicurezza che costituiscono SPCoop. SPCoop si delinea a tutti gli effetti come un framework per l interoperabilità fra servizi applicativi basato su di una architettura di tipo SOA per la Pubblica Amministrazione. Dai documenti redatti dal CNIPA si evince che i componenti su cui si basa la cooperazione applicativa nella Pubblica Amministrazione sono: Porta di Dominio Servizi di Registro e Accordo di Servizio Busta di e-gov.

10 2 Introduzione La specifica SPCoop è completata dalla definizione di ulteriori componenti per il Monitoraggio dei Livelli di Servizio (SLA), la comunicazione event-driven (Gestore Eventi) e dalle regole tecniche e di sicurezza. Nel 2006 sedici Regioni e una Provincia autonoma, coordinate dal CISIS 1, hanno aderito al progetto ICAR Interoperabilità e Cooperazione Applicativa in rete tra le Regioni, traducendo in realtà le direttive del CNIPA con lo sviluppo di: una Porta di Dominio ICAR; un Nodo di Interconnessione per la Cooperazione Applicativa (NICA) che ospita un istanza dei Registro Servizi; un Gestore Eventi Federato che offre a tutti gli enti del territorio la possibilità di implementare servizi di cooperazione, anche interregionali, in architettura orientata agli eventi (EDA); un Sistema di Gestione dei Livelli di Servizio. L insieme di questi componenti costituisce la prima infrastruttura per la Cooperazione Applicativa della Pubblica Amministrazione Italiana. Una delle prime regioni ad aderire al progetto ICAR è stata la Regione Basilicata che, per dare un contributo attivo al progetto, nel 2007 stipula una convenzione con l Università degli Studi della Basilicata dal titolo Studio, definizione, realizzazione prototipale, sperimentazione e valutazione di soluzioni innovative per la cooperazione applicativa in ambiente di e-government, nell ambito del progetto nazionale denominato ICAR. La collaborazione tra l Università e la Regione Basilicata si concretizza nel 2009 in una nuova implementazione open-source della specifica SPCoop e ICAR che prende il nome di freesbee. La nuova piattaforma per la cooperazione si basa su una concettualizzazione originale dello standard SPCoop in termini di Enterprise Integration Patterns (EIP). 1 Il Centro Interregionale per i Sistemi informatici, geografici e statistici è una associazione tra le Regioni e le Province autonome costituita al fine di garantire un efficace coordinamento di strumenti informativi e geografici e di informazione statistica

11 Introduzione 3 Scopo della Tesi Questa tesi documenta il lavoro svolto presso l Università degli Studi della Basilicata che mi ha visto impegnata nello studio delle specifiche SPCoop e del sistema ICAR, e nella progettazione e realizzazione di una nuova piattaforma per la cooperazione applicativa, freesbee. Il suo scopo è quindi duplice: presentare l architettura SPCoop e due delle sue istanze open source, ed evidenziare le innovazioni che freesbee ha introdotto nella interpretazione ed implementazione delle specifiche del CNIPA riguardanti il Gestore degli Eventi ed il Sistema di Gestione dei Livelli di Servizio. Contenuto della Tesi. La tesi si suddivide in cinque capitoli ognuno dei quali affronta un aspetto diverso della cooperazione applicativa. Nel primo capitolo si riporta il processo di rinnovamento a cui è stata sottoposta la P.A. per l introduzione dell ICT ed il diffondersi di Internet che ha portato alla nascita della cooperazione applicativa. Nel secondo capitolo, dopo un esempio che illustra il comportamento di un sistema interoperabile, sono riportate le specifiche definite nei dieci documenti tecnici redatti dal CNIPA che definiscono i componenti dell architettura SPCoop. Il capitolo tre e il capitolo quattro trattano, in modo individuale e nella loro interezza, rispettivamente la piattaforma ICAR e quella freesbee. Considerazioni, punti di forza e di criticità delle piattaforme sono invece riportati nel quinto capitolo.

12 4 Introduzione

13 Storia dell informatizzazione della P.A. Italiana 5 1. Storia dell informatizzazione della P.A. Italiana La Cooperazione Applicativa è il risultato di un processo di ammodernamento iniziato negli anni 80 che ha investito la Pubblica Amministrazione trasformandola in modo radicale. Questo capitolo ripercorre le tappe fondamentali di questo processo introducendo le istituzioni, le norme e le tecnologie che hanno reso possibile questo cambiamento Riforma della Pubblica Amministrazione: dagli anni 80 al 2000 Negli anni 80 la Pubblica Amministrazione Italiana inizia ad adottare le emergenti tecnologie informatiche con lo scopo di automatizzare le proprie procedure ed il trattamento dei dati. Il processo di informatizzazione avviato si scontra però con la mancanza di un piano nazionale ben organizzato ed un assetto centralizzato e autoritario della Pubblica Amministrazione che vede nell informatica un mero strumento per la riproduzione dei procedimenti amministrativi tradizionali. Negli anni 90, quando la P. A. passa da un modello organizzativo gerarchico poco propenso allo scambio e alla condivisione delle informazioni ad uno decentrato permeato sul cittadino e sulla qualità dei servizi offerti, l ICT inizia ad essere vista come uno strumento fondamentale per la realizzazione della riforma amministrativa i cui obiettivi principali sono di seguito sintetizzati. Centralità del cittadino e delle imprese: Migliorare le relazioni tra Pubblica Amministrazione ed utenti per poter soddisfare la richiesta di servizi da parte dei cittadini e delle imprese in modo rapido e trasparente. Decentramento:Sostituzione dell attuale modello a piramide, con una struttura orizzontale, a rete, che assegna un ruolo fondamentale agli enti locali, senza rinunciare a perseguire livelli di uniformità nella qualità ed efficienza dei servizi offerti.

14 6 Storia dell informatizzazione della P.A. Italiana Efficienza: Semplificazione delle procedure e introduzione dei meccanismi tipici del mercato, per garantire efficacia, flessibilità ed aderenza alle esigenze reali dei cittadini e delle imprese. Innovazione: Creazione di una tele-amministrazione che crea, elabora e produce documenti digitali, e dialoga per via telematica con cittadini e imprese. Il raggiungimento di tali obiettivi passa attraverso diverse azioni tra cui l emanazione di nuove leggi, riportiamo di seguito le più importanti. Legge n. 141/1990 che pone l accento sul diritto dei cittadini ad avere servizi trasparenti, efficienti e rapidi e sul principio fondamentale che la pubblica amministrazione è retta da criteri di economicità, efficacia, pubblicità. Legge n. 142/1990 che dà maggiore autonomia e autorità ai Comuni e alle Province e stabilisce che tutti gli atti degli enti locali sono pubblici ad eccezione di alcuni atti espressamente indicati dalla legge o legati alla tutela della privacy. Decreto Legislativo n. 29/1993 che mira, fra le altre cose, ad accrescere l'efficienza delle amministrazioni in relazione a quella dei corrispondenti uffici e servizi dei Paesi della Comunità Europea, anche mediante il coordinato sviluppo di sistemi informativi pubblici individuando per la prima volta nei sistemi informativi uno strumento essenziale per accrescere l efficienza, razionalizzare i costi delle pubbliche amministrazioni. Decreto Legislativo n. 39/1993 che istituisce l Autorità per l Informatica nella Pubblica amministrazione (AIPA), con il compito di introdurre le nuove tecnologie e riorganizzare la P.A. coordinandone gli interventi. Direttiva del Consiglio dei Ministri 5 settembre 1995 che stabilisce la creazione della Rete Unitaria della Pubblica Amministrazione (RUPA) con il contributo dell AIPA. Leggi Bassanini (n. 59/1997, n. 127/1997, n. 191/1998, n. 50/1999) che mirano a modernizzare le amministrazioni tramite la semplificazione dei

15 Storia dell informatizzazione della P.A. Italiana 7 procedimenti, il decentramento amministrativo in base al principio di sussidiarietà e la validità legale del documento informatico Riforma della Pubblica Amministrazione: dal 2000 ad oggi L importanza dell ICT nella società moderna è sancita dal Piano d'azione per la Società dell'informazione varato dal Governo nel 2000 in coerenza con l iniziativa eeurope2002 che ha come obiettivo quello di Estendere le connessioni Internet in Europa, aprire alla concorrenza tutte le reti di comunicazione e stimolare l'impiego di Internet mettendo l'accento sulla formazione e la tutela dei consumatori. Tratta invece esclusivamente quegli aspetti, sintetizzati nel termine e_government, che si riferiscono all'utilizzo delle moderne tecnologie ICT nel processo di ammodernamento della Amministrazione il Piano d azione per l e-government emanato nello stesso anno. La Pubblica Amministrazione immaginata in questo documento si basa su di un Sistema di Cooperazione Applicativa che può essere cosi sintetizzato: Il cittadino potrà ottenere ogni servizio pubblico, cui ha titolo, rivolgendosi ad una qualsiasi amministrazione di front-office, presentando esclusivamente gli strumenti di identificazione personale (senza fornire quindi alcuna informazione che sia già in possesso di una qualsiasi amministrazione dello Stato). Una volta identificato, il sistema informativo di front-office reperirà presso ogni amministrazione che le possiede, tutte le informazioni necessarie ad autorizzare l erogazione del servizio richiesto. In questo nuovo sistema pubblico il cittadino non è tenuto a conoscere come lo Stato è organizzato e dovrà comunicare solo una volta all'amministrazione, nel momento in cui si verificano, le variazioni che corrispondono ad eventi della propria vita. Questa comunicazione verrà automaticamente notificata a tutti gli enti interessati attuando i conseguenti servizi. Per realizzare quanto immaginato è necessario che:

16 8 Storia dell informatizzazione della P.A. Italiana tutte le amministrazioni siano connesse tramite una rete tra pari e siano dotate di un sistema informativo che eroghi i propri servizi non solo ai cittadini, ma anche direttamente ai sistemi informatici delle altre amministrazioni; le amministrazioni che svolgono un ruolo di back-office, rendano accessibili senza oneri i propri servizi sulla rete a tutte le amministrazioni che svolgono un ruolo di front-office, le amministrazioni di front-office realizzino una integrazione dei servizi delle amministrazioni di back-office per fornire servizi integrati secondo le esigenze del cittadino e non secondo l'organizzazione delle amministrazioni eroganti; l'identificazione (autenticazione) del richiedente il servizio, cittadino o impresa, e la verifica delle sue autorizzazioni, avvengano secondo una modalità uniforme su tutto il territorio nazionale utilizzando mezzi di identificazione indipendenti dal servizio richiesto. Quello che si vuole realizzare è quindi un governo connettivo che vede tutte le amministrazioni centrali e locali abilitate per una cooperazione informatica paritetica dove le amministrazioni locali assumono sempre più il ruolo operativo di front-office del servizio pubblico, mentre le amministrazioni centrali svolgono un ruolo di back-office. L attuazione del piano di ammodernamento della P.A. Italiana portato avanti dall AIPA 2 passa nel 2003 nelle mani del CNIPA "che opera presso la Presidenza del Consiglio dei Ministri per l'attuazione delle politiche del Ministro per l'innovazione e le Tecnologie, con autonomia tecnica, funzionale, amministrativa, contabile e finanziaria e con indipendenza di giudizio". Un grande impulso alla realizzazione del sistema previsto dal Piano per l e- Government è dato dal Decreto legislativo n. 82 del 2005: Codice dell Amministrazione Digitale che individua nel CNIPA l organo di consulenza per l innovazione tecnologica della P.A. ed istituisce il Sistema Pubblico di Connettività che viene definito come: l insieme di infrastrutture tecnologiche e 2 Autorità per l'informatica nella Pubblica Amministrazione

17 Storia dell informatizzazione della P.A. Italiana 9 di regole tecniche, per lo sviluppo, la condivisione, l integrazione e la diffusione del patrimonio informativo e dei dati della pubblica amministrazione, necessarie per assicurare l interoperabilità di base ed evoluta e la cooperazione applicativa dei sistemi informatici e dei flussi informativi, garantendo la sicurezza, la riservatezza delle informazioni, nonché la salvaguardia e l autonomia del patrimonio informativo di ciascuna pubblica amministrazione. La realizzazione di SPC è il primo passo concreto verso la realizzazione del Sistema Pubblico di Cooperazione (SPCoop), che ad oggi non è ancora completo.

18 10 SPCoop 2. SPCoop Il CNIPA ha individuato l insieme di strutture organizzative, infrastrutture tecnologiche e regole tecniche necessarie ad implementare il paradigma della cooperazione applicativa nella Pubblica Amministrazione Italiana. In questo capitolo viene riportata una panoramica dell architettura SPCoop cosi come delineata nei documenti pubblicati dal Centro Nazionale per l Informatica nella Pubblica Amministrazione fra il 2005 ed il Un esempio di cooperazione applicativa Ogni evento della vita di un cittadino innesca un processo di cooperazione fra le amministrazioni per lo scambio o l aggiornamento delle informazioni distribuite nella rete. Immaginiamo che un cittadino effettui delle visite sanitarie presso la propria ASL di appartenenza, i cui risultati gli saranno recapitati per posta, e che subito dopo cambi residenza. In un contesto dove i sistemi informativi non consentono l accesso telematico ai propri servizi o non sono in grado di comunicare fra di loro, per la mancanza di tecnologie o protocolli, la situazione immaginata si svolge come mostrato in Figura 2.1.

19 SPCoop 11 Figura 2.1 Scenario classico di cooperazione fra le Amministrazioni. Il cittadino richiede l aggiornamento dei propri dati alla P. A. Locale (1) del Dominio A che per portare a termine il procedimento amministrativo necessita di alcune informazioni registrate presso un altro ente. La P.A. Locale effettua perciò una richiesta di informazioni alla Pubblica Amministrazione Centrale (1.a), operazione che può avvenire con i mezzi più disparati che vanno dall invocazione di un servizio offerto in rete fino alla telefonata di un operatore. La P.A. Centrale del Dominio B risolve la richiesta di informazioni ricevuta senza interagire con altre amministrazioni comunicando in modo opportuno la risposta. Nel momento in cui la P.A. Locale ottiene le informazioni necessarie aggiorna i dati in suo possesso. A questo punto il cittadino si deve recare presso la ASL (2) per comunicare i suoi nuovi dati. La ASL procede ad aggiornare i propri archivi dopo aver richiesto anch essa ulteriori informazioni alla Pubblica Amministrazione Centrale (2.b). Nonostante i sistemi delle varie amministrazioni siano informatizzati, per portare a termine la procedura amministrativa avviata dal nostro ipotetico cittadino sono necessarie alcune ore se non alcuni giorni. Inoltre, fino a quando la ASL non porta a termine l aggiornamento dei propri archivi le informazioni relative al medesimo soggetto, che si trovano distribuite nella rete, sono disallineate.

20 12 SPCoop L adozione del nuovo modello illustrato nel Codice di Amministrazione Digitale semplifica e velocizza tutte le operazioni svolte presso le amministrazioni. Figura 2.2 Scenario di cooperazione applicativa fra i sistemi informativi delle P.A.. In uno scenario di Cooperazione Applicativa, come mostrato in Figura 2.2, la richiesta effettua dal cittadino presso l Amministrazione Locale del Dominio A innesca l invocazione di un servizio offerto dal sistema informativo appartenente al Dominio B che consente di portare a termine la procedura amministrativa in un lasso di tempo che può andare da pochi secondi a pochi minuti. Una volta operato l aggiornamento lo stesso sistema informativo della P.A. Locale, senza l ausilio ulteriore dell operatore, invoca un servizio esposto dall ASL del Dominio C che consente di comunicare la modifica dei dati appena effettuata. La comunicazione di aggiornamento dei dati che viene trasmessa alla ASL innesca automaticamente la richiesta di informazioni all Amministrazione Centrale che consente alla ASL un aggiornamento tempestivo dei propri archivi. Naturalmente questo è uno dei tanti scenari che si possono attuare in ambito cooperativo, l aggiornamento automatico dei dati o ogni altra forma di comunicazione ed invocazione di servizi viene stabilita dalle amministrazioni in base ad accordi stipulati in precedenza. È da notare che il cittadino si reca presso solo l Amministrazione che funge da front-office per aggiornare tutti i dati che lo riguardano, questo consente un notevole vantaggio per il cittadino e una maggiore efficienza per la Pubblica

21 SPCoop 13 Amministrazione che vede mantenuta sempre consistente la propria banca dati diffusa nella rete L architettura SPCoop Il CNIPA pubblica nel 2005 dieci documenti tecnici, che insieme alle specifiche della busta e-gov, delineano il quadro tecnico-implementativo del Sistema Pubblico di Cooperazione. In tale sistema i soggetti cooperano attraverso l erogazione e la fruizione di servizi applicativi 3 grazie ad una infrastruttura i cui elementi di base sono individuati dal CNIPA in: Porta di Dominio Registro SICA e Accordi di Servizio Busta E-Gov. Il Registro SICA e la Porta di Dominio costituiscono i servizi infrastrutturali per la cooperazione applicativa denominati anche Servizi di Interoperabilità, Cooperazione ed Accesso (servizi SICA). La Figura 2.3 mostra un architettura di cooperazione, così come definita nel Sistema Pubblico di Connettività, che coinvolge tre soggetti, due P.A. ed una ASL, che generano altrettanti domini. 3 Procedura/Applicazione rivolta ad una determinata tipologia di utenza (cittadini, imprese, associazioni di categoria, ecc..) che ha l obiettivo di soddisfare specifiche esigenze di carattere conoscitivo o procedurale.

22 14 SPCoop Figura 2.3 Architettura SPCoop. Le amministrazioni centrali, enti pubblici, regioni, provincie e comuni costituiscono i soggetti pubblici mentre imprese e associazioni accreditate sono i soggetti privati della cooperazione. L insieme dei soggetti pubblici e privati operanti in SPCoop costituiscono la comunità dei soggetti di SPCoop. L insieme delle risorse (procedure, dati e servizi) di ogni sistema informativo locale (SIL) rappresenta un dominio, che definisce il confine di responsabilità di quel sistema. Ogni dominio offre i servizi del proprio sistema informativo attraverso una interfaccia pubblica, denominata Porta di Dominio (PdD), che gli consente inoltre di comunicare con gli altri domini mediante lo scambio di messaggi in un formato standard, denominato busta e-gov. I messaggi scambiati sfruttano i canali e i meccanismi di trasporto forniti dal Sistema Pubblico di Connettività per viaggiare sulla rete. L erogazione e la fruizione dei servizi applicativi viene regolamentata mediante la stipulazione tra i soggetti di contratti, redatti in formato xml, denominati Accordi di Servizio. L insieme degli Accordi di Servizio stipulati sono raccolti presso il Registro SICA, un componente infrastrutturale che non fa riferimento a nessun dominio ed è gestito direttamente dal CNIPA. Più soggetti che cooperano per offrire un particolare servizio stipulano un Accordo di Cooperazione anche esso conservato presso il Registro SICA.

23 SPCoop 15 La specifica SPCoop prevede inoltre un ulteriore elemento infrastrutturale: il Gestore degli Eventi che consente uno scambio di messaggi fra le porte di dominio secondo una architettura di tipo event-driven (EDA). Definire e sviluppare tutti gli elementi dell architettura non è sufficiente a rendere efficace ed efficiente il sistema, infatti, per far si che il sistema, una volta reso operativo, possa essere realmente utile è necessario garantirne la sicurezza e monitorare la qualità dei servizi in esso offerti Tecnologie e Standard L integrazione dei Sistemi Informativi Locali per la condivisione di funzionalità e informazioni richiede che venga definito un formato comune per lo scambio dei dati, uno standard indipendente dalle piattaforme applicative ed un protocollo di dialogo indipendente dal trasporto, dal punto di vista semantico completo, e sicuro. Il modello di cooperazione applicativa SPCoop soddisfa queste necessità grazie alla definizione di un architettura organizzata come una SOA da realizzarsi mediante l uso di Web Services e di tutte le tecnologie ad essi collegate che ora illustreremo SOA Una SOA (Service Oriented Architecture) è un architetturale focalizza sul concetto di servizio: una funzionalità messa a disposizione da un applicazione che risiede su di un computer collegato ad una rete. Lo scopo di una SOA è quello di consentire a sistemi eterogenei di cooperare mediante la fruizione di servizi che soddisfano le proprietà riportate di seguito. Essere ricercabili e recuperabili dinamicamente. Un servizio deve poter essere ricercato in base alla sua interfaccia e richiamato a tempo di esecuzione. In tal modo si realizza un forte disaccoppiamento fra chi

24 16 SPCoop richiede il servizio e chi lo fornisce, infatti quest ultimo può essere sostituito in modo del tutto trasparente rispetto al chiamante. Autocontenuti e modulari. I servizi non devono essere legati al contesto o allo stato di altri servizi, devono essere quindi privi di stato (stateless). Interfacce esplicite e indipendenti dall'implementazione. Una volta nota l interfaccia deve essere possibile invocare un servizio indipendentemente dalla piattaforma che lo implementa. Loosely coupled. Le dipendenze fra i componenti, che implementano i vari servizi, devono essere limitate in modo da rendere il sistema flessibile e facilmente modificabile. Interfaccia distribuita accessibilità trasparente rispetto alla loro allocazione. Un richiedente deve poter accedere ad un servizio ovunque esso sia allocato attraverso la rete di cui fanno entrambi parte. Coarse-grained. I metodi dei servizi devono essere progettati in modo da ritornare grosse quantità di dati non raffinate limitando così le chiamate remote che rendono poco efficiente il sistema. I servizi piccoli andrebbero progettati se destinati ad essere richiamati in più servizi per realizzare diverse funzionalità. Componibili. Ogni servizio deve essere indipendente da qualsiasi altro, in modo da poter creare servizi più complessi attraverso la composizione dei quelli di base, operazione che viene definita ServiceOrchestration (Orchestrazione). Gli elementi di base di un architettura SOA consistono in: Service Consumer Service Provider Service Registry Service Contract Service Lease Figura 2.4 Esempio di architettura SOA.

25 SPCoop 17 Il Service Provider è un entità che mette a disposizione un qualche servizio pubblicandolo, ovvero comunicandone l interfaccia (Service Contract) al Service Registry che la memorizza e la rende disponibili a chi cerca un servizio. Il Service Lease specifica il tempo per cui il contratto è valido. Il Service Registry possiede quindi le informazioni, come l URL e la modalità di accesso, di tutti i servizi disponibili sulla rete. Il Service Consumer è invece l entità che richiede un servizio al Service Provider dopo aver recuperato le informazioni necessarie chiedendole al Service Registry. L interazione fra le entità avviene interamente mediante una rete di comunicazione che può essere internet o una intranet. Un ulteriore elemento che può arricchire il modello appena mostrato è il Service Proxy, un'implementazione del pattern proxy. In tal caso, il Service Consumer esegue la richiesta del servizio mediante il Service Proxy che si fa carico di tutte le operazioni di ricerca del servizio e creazione ed inoltro del messaggio di invocazione. La comunicazione è quindi tutta a carico del proxy che può essere utilizzato anche per implementare dei meccanismi di failover-recovery o mantenere una cache dei risultati delle ricerche già effettuate. Figura 2.5 Esempio di architettura SOA con proxy Web Services I Web Services sono una tecnologia basata su diversi standard che si presta particolarmente alla realizzazione di architetture SOA e su di essi si basa l intero sistema SPCoop. Un servizio web è un sistema software, identificato da un URI (Uniform Resource Identifier), la cui interfaccia è pubblica. Tali sistemi comunicano fra di loro mediante lo scambio di messaggi in formato XML trasportati attraverso la rete.

26 18 SPCoop In questo tipo di implementazione dell architettura SOA le interfacce dei servizi sono definite tramite WSDL e pubblicate tramite UDDI. La comunicazione fra le entità avviene normalmente tramite messaggi SOAP scambiati mediante protocollo HTTP (Hypertext Transfer Protocol). Ognuno degli standard menzionati implementa quindi un entità SOA, le corrispondenze sono: o Service Provider Web Service o Service Consumer Client Web Service o Service Contract WSDL o Service Registry UDDI o Comunication Protocol SOAP/HTTP Figura 2.6 Standard di un'architettura Web Services. Il CNIPA utilizza questi ed altri standard, di seguito illustrati, per definire gli elementi dell architettura SPCoop XML Molte delle tecnologie impiegate per le realizzazione di un Web Service si basano sull XML (extensible Markup Language) un metalinguaggio 4 indipendente dalla piattaforma e da qualsiasi implementazione specifica. Un documento XML è un file di testo, interpretabile dall uomo, basato su codifica ASCII a 7 bit, gestibile secondo lo standard Unicode a 32 bit per esigenze di internazionalizzazione, facilmente scambiabile fra due applicazioni attraverso la rete. 4 Un linguaggio per definire altri linguaggi.

27 SPCoop 19 L XML è un linguaggio di markup mediante il quale è possibile associare ad un testo un particolare significato mediante l attribuzione di un marcatore tag elemento delimitato da due parentesi angolari < marcatore > che può avere degli attributi. Un elemento XML è costituito dal testo delimitato da due marcatori, uno di apertura (<marcatore>) e uno di chiusura (</marcatore>). Figura 2.7 Elemento XML con attributo id. Un documento XML ben formato memorizza i dati in una struttura gerarchica che rispetta le regole sintattiche dettate dallo standard. Un particolare marcatore posto all inizio del documento ne definisce la natura ed il set di caratteri utilizzato per la codifica (encoding). Figura 2.8. Documento xml. Lo standard XML non pone vincoli sulla definizione dei tag per questo motivo ogni documento ben formato può essere ritenuto valido. È però possibile, mediante la definizione di uno schema, stabilire la struttura logica che un documento XML deve rispettare per essere considerato valido. A tale scopo si utilizza un ulteriore documento, che può essere uno schema xml (XML Schema) o un documento di dichiarazione di tipo (DTD Document Type Declaretion). Nel contesto dei Web Services sono maggiormente impiegati gli XML Schema che permettono di specificare dichiarazioni di tipo vincolando il range dei valori assumibili e sono compatibili con il protocollo SOAP versione 1.2. Un XML Schema è sostanzialmente un insieme di tipi predefiniti ed un modo per definirne dei nuovi mediante il linguaggio XML Schema Defintion Language (abbreviato in XSD).

28 20 SPCoop SOAP SOAP (Simple Object Access Protocol) è un protocollo leggero per lo scambio di informazioni, mediante messaggi XML, in un ambiente decentralizzato e distribuito. SOAP non è legato ad un particolare protocollo di rete anche se HTTP (Hypertext Transfer Protocol) è il protocollo più comunemente utilizzato e l unico ad essere stato standardizzato dal W3C. La specifica SOAP si compone di tre parti: 1. SOAP Envelope: che definisce un framework per la descrizione del contenuto del messaggio e della sua elaborazione. 2. SOAP Encoding Rules: che determina una serie di regole di codifica per rappresentare i tipi di dato definiti per l'applicazione. 3. SOAP RPC: che riporta la convenzione per rappresentare chiamate a procedure remote e le relative risposte. Un istanza del protocollo è costituita da un messaggio XML, denominato SOAP Message, per cui non è definita nessuna specifica semantica. Gli autori dei messaggi mediante l uso dei Namespaces XML 5 possono dichiararne una usando grammatiche XML definite per lo scopo in particolari namespaces. Un messaggio SOAP è costituito da un contenitore, chiamato Envelope, all interno del quale vengono distinte due sezioni principali denominate Header e Body, che contengono rispettivamente l intestazione ed il corpo del messaggio. L elemento radice obbligatorio Envelope contiene informazioni necessarie ad identificare la versione del protocollo mentre nell Header, se presente, vengono specificate le informazioni destinate ai nodi che il messaggio attraversa e riguardanti l instradamento la sicurezza o le azioni che i nodi stessi devono compiere. Il Body invece ingloba l informazione principale che il mittente invia al destinatario. Il suo contenuto dipende dallo stile del messaggio che può essere: 5 Insieme di nomi, utilizzato per definire gli elementi e gli attributi di un linguaggio XML, a cui viene associato un URI (Universal Resource Identifier) di riferimento tramite il quale identificare in maniera assoluta il namespace.

29 SPCoop 21 document o rpc. A seconda del formato il body può contenere uno o più sottoelementi xml che codificano dati generici o un unico elemento che rappresenta una chiamata a procedura (RPC). Il Fault Message è invece un particolare messaggio in cui l unico figlio di Body è l elemento predefinito di SOAP: Fault. Tale messaggio viene inviato come risposta al mittente se il destinatario, o un nodo intermedio, non riesce ad elaborare in modo corretto il messaggio di richiesta del servizio. Figura 2.9 Messaggio SAOP. SOAP prevede anche due formati di serializzazione che definiscono come i tipi base (interi, stringhe, ecc) e i tipi complessi (array e tipi composti) possono essere serializzati in XML. Encoded: il contenuto del messaggio è serializzato in xml usando le codifiche di serializzazione per oggetti, strutture, array, etc. previste nelle specifiche SOAP. Literal: il contenuto del messaggio è serializzato in XML usando le stesse specifiche XML del file WSDL e degli schemi XML utilizzati. Un SOAP Message è un documento XML che può trasportare essenzialmente caratteri Unicode, ma a volte è necessario spedire dati binari come ad esempio foto, file audio o documenti che usano un formato proprietario (es. PDF). Un SOAP Message with Attachments (SwA) fornisce un meccanismo per allegare dati binari a un SOAP Message, senza convertirli in caratteri ASCII mediante la codifica Base64, utilizzando il protocollo MIME Multipart/Related Content Type.

30 22 SPCoop I messaggi SOAP con allegati sono inseriti all interno di un MIME Envelope, una sorta di contenitore suddiviso in più parti che riporta nella sua parte principale il messaggio SOAP e nelle altre gli allegati in binario. Figura 2.10 Messaggio SOAP con Attachment. Le diverse parti del messaggio sono separate da una particolare stringa, indicata nell esempio con --MIME_boundary--, che viene definita nella parte MIME iniziale del messaggio insieme alle intestazioni che specificano: la MIME-Version; il Content-Type, unico campo obbligatorio che secondo la specifica è Multipart/Related; il Type del messaggio (es.: text/xml); e l identificativo del punto d inizio, start (es. <starting point id>). Subito dopo il primo boundary si trova, preceduta da alcuni campi di intestazione come il Content-ID, la parte principale del messaggio SOAP, di cui abbiamo già visto la struttura. La parte relativa all allegato, separata da quella principale da un secondo boundary, è anch essa costituita da campi di intestazione seguiti dal codice che

31 SPCoop 23 costituisce il file allegato. Il campo identificativo Content-ID può essere usato come riferimento dal testo nella sezione Body del messaggio SOAP WSDL WSDL (Web Services Description Language) è un linguaggio, basato su XML, usato per descrivere, in modo completo, le interfacce dei Web Services che prevede una separazione degli aspetti astratti della descrizione del servizio, da quelli concreti che lo legano a particolari protocolli di rete o di RPC. Un documento WSDL è un file XML costituito da un insieme di definizioni la cui radice definitions contiene i seguenti elementi: types, message, porttype, binding e service. Figura 2.11 Documento WSDL. Nell elemento types sono indicati i tipi di dato astratti usati per codificare le informazioni coinvolte nello scambio dei messaggi. WSDL non definisce un proprio sistema di definizione dei tipi ma si appoggia a linguaggi esistenti, tra cui il più usato è l XML Schema.

32 24 SPCoop Figura 2.12 types. L elemento message descrive il formato dei dati scambiati durante lo svolgimento di un servizio. Ogni elemento, identificato in maniera univoca dall attributo name, rappresenta quindi un messaggio che il servizio invia o riceve. Gli elementi part, che compongono un message, hanno un attributo obbligatorio name ed un tipo che può essere standard o composto. Figura 2.13 message. La sezione porttype indica le operazioni supportate da un servizio web mediante uno o più operation. Ogni elemento operation specifica, se previsto, il tipo del messaggio di input e di output identificati rispettivamente dagli elementi input e output. Per specificare il formato di un messaggio di errore, che può essere restituito in output, si usa invece l elemento opzionale fault di cui è possibile avere più istanze. Figura 2.14 porttype. La presenza e l ordine degli elementi input e output all interno di un operation ne definisce il modello di trasmissione, ne esitono quattro: Request-response, Solicit-response, One-way, Notification. Request-response. È il modello utilizzato per le chiamate RPC. In questo caso sono presenti gli elementi input ed output, in questo ordine. Il servizio riceve il

33 SPCoop 25 messaggio Request dal client e, dopo aver eseguito l elaborazione relativa alla richiesta, manda indietro un messaggio Response. Solicit-response. Anche in questo modello vi sono entrambi gli elementi ma nell ordine output ed input. È il servizio ad iniziare la comunicazione inviando un messaggio al client ed attendendo poi una sua risposta. One-way. Prevede un solo messaggio di input. Un client invia un messaggio al servizio, e continua la sua elaborazione senza attendere una risposta. Notification. Il servizio spedisce un messaggio al client senza attendere una sua risposta. È quindi presente solo l elemento di output. Nella sezione binding viene associato ad ogni porttype un protocollo per lo scambio dei messaggi. Assumendo SOAP come tale protocollo, si può specificare attraverso l elemento wsdlsoap:binding, lo stile del messaggio SOAP (rpc o document) ed il protocollo di trasporto utilizzato. Per ogni operazione definita nel porttype, mediante l uso dell elemento wsdlsoap:body, è possibile definire l encoding (encoded o literal), per i messaggi di input, output e fault. Per ogni operation è possibile specificare quale azione SOAP eseguire mediante l attributo soapaction dell elemento wsdlsoap:operation. Figura 2.15 binding. L ultima sezione, identificata dall elemento service, è relativa alla localizzazione del Web Service. Per ogni servizio vengono definiti uno o più punti di accesso fisici. Ogni elemento port è collegato mediante un attributo ad un elemento binding precedentemente dichiarato. Nel caso si utilizzino i protocolli SOAP e

34 26 SPCoop HTTP l elemento wsdlsoap:address viene utilizzato per indicare l indirizzo URL (Uniform Resource Locator), chiamato anche endpoint, al quale può essere trovato il Web Service. Figura 2.16 service UDDI UDDI (Universal Description, Discovery and Integration) definisce un registro denominato UBR (UDDI Business Registry), ed un protocollo per pubblicare e ricercare informazioni sui Web Services, in base alle loro interfacce. Le operazioni che si possono svolgere su di un registro UDDI sono: pubblicare i servizi che un azienda rende disponibili; cercare aziende che mettono a disposizione un certo tipo di servizio; avere informazioni in un formato comprensibile all utente umano, circa indirizzi, contatti o altro relative ad una azienda; avere informazioni tecniche, cioè interpretabili ed utilizzabili da un sistema informatico, relative ad un servizio in modo tale da potervisi connettere. L UBR è un costituito da molti registri distribuiti sulla rete connessi fra loro. L informazione viene registrata su uno dei nodi (registri) del sistema e viene propagata e resa disponibile su tutti gli altri tramite una operazione di sincronizzazione. Questo contribuisce alla protezione del sistema contro possibili situazioni di failure del database, grazie alla ridondanza dei dati. Le informazioni contenute nell UBR sono organizzate in modo tale da poter effettuare diversi tipi di ricerche che si basano sulla consultazione di tre cataloghi così definiti:

35 SPCoop 27 White Pages (Pagine Bianche): che comprendono le informazioni di base sui contatti dell'azienda: la ragione sociale, l'indirizzo, ed il codice DUNS (Data Universal Numbering System) che identifica in modo univoco l azienda. Yellow Pages (Pagine Gialle): classificazione dei servizi web fatta rispetto ad una tassonomia (standardizzata o definita dall utente) che consente di effettuare delle ricerche in base alla categoria a cui appartiene un servizio. Green Pages (Pagine Verdi): che comprendono informazioni tecniche delle funzioni supportate dal servizio web ospitato dall'azienda. Tra di esse vi sono i puntatori alle descrizioni dei servizi web e la loro localizzazione. Un registro UDDI organizza le informazioni in quattro strutture di dati. Le specifiche descrivono queste strutture come istanze di uno schema XML e le definiscono entità. Una businessentity possiede informazioni come nome, indirizzo e contatti di una azienda che ha pubblicato dei servizi web. Ogni businessentity non si riferisce necessariamente ad una organizzazione ma il fornitore di un servizio può essere un dipartimento o un gruppo di organizzazioni. Una businessservice memorizza dati di tipo descrittivo, come nome e categoria di appartenenza, circa un servizio web offerto da una azienda. Ogni businessentity contiene una businessservice per ogni servizio pubblicato. L entità bindingtemplate contiene i dettagli tecnici, come l entry point, circa le istanze di un servizio web. Ogni bindingtemplate si riferisce ad un unico businessservices e può far riferimento all interfaccia che il servizio rispetta mediante l elemento tmodel il quale memorizza l URL di un documento WSDL. Le strutture tmodel definiscono inoltre le classi secondo cui catalogare i servizi.

36 28 SPCoop Figura 2.17 Strutture dei dati UDDI. Per interegire con i dati archiviati nei registri, UDDI mette a disposizione delle specifiche API (Application Programming Interface) che consentono di effettuare tre operazioni fondamentali: Inquiry, Publishing e Replication. L inquiry permette agli utenti di effettuare le ricerche nel registro. Il publishing gestisce le informazioni sui fornitori e sui loro servizi ed il replication permette la comunicazione tra server per la gestione e la sincronizzazione dei registri LDAP Nel sistema SPCoop vengono messe a disposizione, in modo distribuito, una notevole quantità di informazioni per cui è necessario gestire l accesso da parte di migliaia di utenti differenti. A tale scopo viene impiegato lo standard Lightweight Directory Access Protocol (LDAP) che definisce un metodo standard di comunicazione di tipo client server per l'accesso e l'aggiornamento delle informazioni in una directory mediante Internet o una intranet. Una directory è un elenco ordinato di informazioni su degli oggetti, viene spesso descritta anche come un database ottimizzato per le operazioni di lettura e ricerca che sono molto più frequenti rispetto a quelle di aggiornamento. In LDAP i dati riguardanti gli oggetti sono organizzati in modo gerarchico secondo uno schema ad albero, detto Directory Information Tree (DIT), in cui le foglie sono dette entry. Ogni entry è univocamente identificata da un

37 SPCoop 29 Distinguished Name (DN) e caratterizzata da una serie di coppie attributo/valore. I Relative Distinguished Name (DNR), che costituiscono un DN, corrispondono ad un ramo del DIT che dalla sua radice porta ad una directory entry. La Figura 2.18 mostra una rappresentazione di un DIT. Un esempio di DN è cn = kalus, ou = Marketing, o = IBM dove ogni coppia separata da virgole è un DNR. La foglia (entry) con attributo cn = kalus rappresenta tutte le informazioni di un oggetto memorizzato nella directory. Figura 2.18 DIT Porta di Dominio Nell architettura SPCoop la fruizione di un servizio applicativo fa instaurare tra due SIL una relazione di servizio in cui uno dei due sistemi, che riveste il ruolo di fruitore, utilizza i risultati di trattamenti informatici effettuati dall altro sistema, che riveste il ruolo di erogatore. Un servizio applicativo SPCoop è una funzionalità messa a disposizione da un sistema informativo locale mediante un web service. Tutte le comunicazione per la fruizione di un servizio applicativo fra due SIL avvengono mediante una Porta di Dominio (PdD). Ogni dominio ne ha una che funge da proxy per l accesso alle risorse applicative di tutte le amministrazioni pubbliche o soggetti privati che appartengono al dominio stesso.

38 30 SPCoop Figura 2.19 Scenario di comunicazione fra Porte di Dominio. La PdD, che è l unico punto di accesso al dominio, espone due servizi web: la Porta Delegata (PD) che viene invocata dai SIL del dominio per generare il messaggio di richiesta di un servizio destinato ad una PdD e la Porta Applicativa (PA) a cui le PdD inviano le richieste di servizi destinate ai sistemi informativi del dominio. La PD e la PA sono quindi coinvolte in diverso modo nel processo di invocazione di un servizio che si articola nelle seguenti fasi: Acquisizione - La PD riceve i Messaggi Applicativi 6 inviati dai Servizi Applicativi presenti all interno del Dominio e li imbusta trasformandoli in una busta e-gov;. Inoltro - La PdD inoltra la busta e-gov al dominio destinatario. Ricezione - La PA riceve le buste e-gov provenienti dalle altre PdD e le sbusta estrapolando il Messaggio Applicativo in esso contenuto. Smistamento - La PdD inoltra i Messaggi Applicativi ai servizi applicativi destinatari presenti all interno del dominio. Una Porta di Dominio non ha logica applicativa ed è totalmente disaccoppiata dal servizio applicativo con cui si interfaccia. Il modulo di integrazione messo a disposizione dalle PdD deve consentire ai servizi applicativi, che usano particolari tecnologie, di comunicare con i Web Services offerti dalle porte di dominio. I compiti fondamentali che la PdD deve svolgere, individuati dal CNIPA sono: 6 Contenuto informativo per erogazione di un servizio applicativo, che viene scambiato tramite Busta di e- Gov tra le Porte di Dominio dei due attori dell interazione (Erogatore e Fruitore).

39 SPCoop 31 Gestione Busta e-gov. Si tratta della gestione di tutti i messaggi, anche quelli conformi alla alle specifiche SOAP 1.1 Attachment, scambiati nella normale comunicazione fra fruitore ed erogatore di un servizio Gestione dei messaggi di errore. In caso problemi durante la fase di sbustamento o smistamento la PdD deve generare i Messaggi di Errore SPCoop da inoltrare ai servizi applicativi. La porta si deve occupare anche della consegna dei Messaggi di Fault che i sistemi applicativi generano a seguito di una richiesta. Gestione della sicurezza sia a livello di connessione (SSL3 o TLS) che di messaggio SOAP (WS-Security). Sincronizzazione del tempo di sistema. Tracciatura in modo persistente di tutte le attività della porta come la ricezione l inoltro o lo smistamento dei messaggi applicativi in modo da poter ricostruire l andamento dei flussi in ingresso e in uscita. Gestione dei messaggi Diagnostici. Tutte le anomalie riscontrate durante il trattamento dei messaggi devono essere riportate mediante dei messaggi diagnostici, che devono opportunamente essere gestiti. Gestione modalità consegna affidabile. Implementazione del meccanismo di consegna affidabile, mediante la gestione dell elemento opzionale ProfiloTrasmissione della busta e-gov, utilizzando un algoritmo a finestra di trasmissione. Le specifiche prevedono anche la realizzazione di una console di comando e configurazione per la Porta di Dominio Busta e-gov La busta e-gov è il protocollo applicativo, specificatamente progettato per SPCoop, con cui i servizi applicativi sono invocabili remotamente. Una busta e- Gov concretamente è 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.

40 32 SPCoop Figura 2.20 Struttura busta e- Gov con e senza attachments. Il Messaggio SPCoop, definito busta e-gov, rispecchia la struttura di un messaggio SOAP, prevede quindi un elemento definito busta, envelope, che contiene gli elementi header e body. In presenza di attachment la busta e-gov viene inclusa in una struttura MIME, che come prevede lo standard, può contenere sia dati xml che binari. Nell elemento body è possibile inserire un qualsiasi file xml o dato binario, codificato in Base64, che rappresenta il messaggio applicativo creato da un SIL. A differenza di quando specificato nel protocollo SOAP, nella busta e-gov l elemento header è obbligatorio e riporta le informazioni necessarie all instradamento, al tracciamento, all affidabilità e alla sicurezza del messaggio. Uno degli elementi opzionali dell header è l elemento Ws-Security che contiene le informazioni necessarie per la gestione della sicurezza, è obbligatorio invece l elemento Intestazione che contiene a sua volta l elemento IntestazioneMessaggio e altri elementi opzionali che mantengono informazioni utili per il tracciamento, il riscontro dei messaggi e le eventuali eccezioni occorse durante il trattamento dell intestazione.

Ministero del Lavoro e delle Politiche Sociali

Ministero del Lavoro e delle Politiche Sociali Ministero del Lavoro e delle Politiche Sociali Prospetto Informativo on-line Standard tecnici del sistema informativo per l invio telematico del Prospetto Informativo Documento: UNIPI.StandardTecnici Revisione

Dettagli

Architettura SPC e porta di dominio per le PA

Architettura SPC e porta di dominio per le PA Libro bianco sulla SOA v.1.0 Allegato 2_1 Architettura SPC e porta di dominio per le PA vs 02 marzo 2008 Gruppo di Lavoro SOA del ClubTI di Milano Premessa L architettura SPC e la relativa porta di dominio

Dettagli

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO Standard tecnici Gli standard tecnici di riferimento adottati sono conformi alle specifiche e alle raccomandazioni emanate dai principali

Dettagli

COME FARE PER. ARMONIZZARE IL SITO COL SISTEMA DI GESTIONE DOCUMENTALE DELL ENTE

COME FARE PER. ARMONIZZARE IL SITO COL SISTEMA DI GESTIONE DOCUMENTALE DELL ENTE COME FARE PER. ARMONIZZARE IL SITO COL SISTEMA DI GESTIONE DOCUMENTALE DELL ENTE Flavia Marzano marzano@cibernet.it 10/05/2004 ARPA Club Forum PA 2004 Contenuti Cenni normativi Sistema di gestione documentale:

Dettagli

B.P.S. Business Process Server ALLEGATO C10

B.P.S. Business Process Server ALLEGATO C10 B.P.S. Business Process Server ALLEGATO C10 REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA REGIONALE UFFICIO SISTEMA INFORMATIVO REGIONALE E STATISTICA Via V. Verrastro, n. 4 85100 Potenza tel

Dettagli

SPCOOP E I PROGETTI DI COOPERAZIONE INTERREGIONALE

SPCOOP E I PROGETTI DI COOPERAZIONE INTERREGIONALE SPCOOP E I PROGETTI DI COOPERAZIONE INTERREGIONALE EGIDIO PICERNO POTENZA 9 LUGLIO 2010 Interoperabiltà è la capacità di due o più sistemi informativi di scambiarsi informazioni e di attivare, a suddetto

Dettagli

DigitPA. VISTI gli articoli 16 e 16 bis del decreto Legge 29 novembre 2008, n. 185 convertito con modificazioni dalla Legge 28 gennaio 2009 n.

DigitPA. VISTI gli articoli 16 e 16 bis del decreto Legge 29 novembre 2008, n. 185 convertito con modificazioni dalla Legge 28 gennaio 2009 n. DigitPA VISTO l art. 6, comma 1 bis, del decreto legislativo 7 marzo 2005 n. 82 (indicato in seguito con l acronimo CAD), come modificato dal decreto legislativo 30 dicembre 2010 n. 235; VISTI gli articoli

Dettagli

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security

Dettagli

Introduzione ai Web Services Alberto Polzonetti

Introduzione ai Web Services Alberto Polzonetti PROGRAMMAZIONE di RETE A.A. 2003-2004 Corso di laurea in INFORMATICA Introduzione ai Web Services alberto.polzonetti@unicam.it Introduzione al problema della comunicazione fra applicazioni 2 1 Il Problema

Dettagli

Portale regionale della Salute. Servizi di prenotazione prestazione e pagamento ticket.

Portale regionale della Salute. Servizi di prenotazione prestazione e pagamento ticket. Portale regionale della Salute Servizi di prenotazione prestazione e pagamento ticket. Specifiche di integrazione dei servizi di cooperazione applicativa e dei web services. Versione 1.10 16 Ottobre 2013

Dettagli

REGIONE BASILICATA DIPARTIMENTO INFRASTRUTTURE, OO.PP. E MOBILITA

REGIONE BASILICATA DIPARTIMENTO INFRASTRUTTURE, OO.PP. E MOBILITA REGIONE BASILICATA DIPARTIMENTO INFRASTRUTTURE, OO.PP. E MOBILITA Ufficio Difesa del Suolo di Potenza INTEROPERABILITÀ E COOPERAZIONE APPLICATIVA Informatizzazione dell iter procedurale e dei controlli

Dettagli

POR Calabria FSE 2007/2013 Asse II Occupabilità Obiettivo operativo D1

POR Calabria FSE 2007/2013 Asse II Occupabilità Obiettivo operativo D1 Allegato n. 2 al Capitolato speciale d appalto. ENTE PUBBLICO ECONOMICO STRUMENTALE DELLA REGIONE CALABRIA POR Calabria FSE 2007/2013 Asse II Occupabilità Obiettivo operativo D1 Procedura aperta sotto

Dettagli

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale 1. Livello infrastrutturale Il Cloud, inteso come un ampio insieme di risorse e servizi fruibili da Internet che possono essere dinamicamente

Dettagli

Il modello di gestione delle identità digitali in SPCoop

Il modello di gestione delle identità digitali in SPCoop Il modello di gestione delle identità digitali in SPCoop Francesco Tortorelli Il quadro normativo e regolatorio di riferimento 2 Il codice dell amministrazione digitale (CAD) CAD Servizi Access di services

Dettagli

Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni. <Task AP3>

Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni. <Task AP3> Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni AP3-Documento Descrittivo degli Accordi di Servizio Versione AP3-specificaADSv1.2.1.doc Pag. 1

Dettagli

Modello dell Infrastruttura per il Fascicolo Sanitario Elettronico (InfFSE) Progetto: Infrastruttura tecnologica del Fascicolo Sanitario Elettronico

Modello dell Infrastruttura per il Fascicolo Sanitario Elettronico (InfFSE) Progetto: Infrastruttura tecnologica del Fascicolo Sanitario Elettronico Dipartimento per la digitalizzazione della PA e l innovazione Consiglio Nazionale delle Ricerche Dipartimento delle Tecnologie dell Informazione e delle Comunicazioni Modello dell Infrastruttura per il

Dettagli

Release Notes di OpenSPCoop2. Release Notes di OpenSPCoop2

Release Notes di OpenSPCoop2. Release Notes di OpenSPCoop2 Release Notes di OpenSPCoop2 i Release Notes di OpenSPCoop2 Release Notes di OpenSPCoop2 ii Copyright 2005-2015 Link.it srl Release Notes di OpenSPCoop2 iii Indice 1 Versione 2.1 1 1.1 Gestione del protocollo

Dettagli

Guida Utente della PddConsole. Guida Utente della PddConsole

Guida Utente della PddConsole. Guida Utente della PddConsole Guida Utente della PddConsole i Guida Utente della PddConsole Guida Utente della PddConsole ii Copyright 2005-2014 Link.it srl Guida Utente della PddConsole iii Indice 1 Introduzione 1 2 Prerequisiti per

Dettagli

Guida Utente della PddConsole. Guida Utente della PddConsole

Guida Utente della PddConsole. Guida Utente della PddConsole Guida Utente della PddConsole i Guida Utente della PddConsole Guida Utente della PddConsole ii Copyright 2005-2015 Link.it srl Guida Utente della PddConsole iii Indice 1 Introduzione 1 2 I protocolli di

Dettagli

Seminario di Sistemi Distribuiti: RPC su SOAP

Seminario di Sistemi Distribuiti: RPC su SOAP Corso di Sistemi Distribuiti Prof. S. Balsamo Seminario di Sistemi Distribuiti: RPC su SOAP [ 777775] 1 INTRODUZIONE 3 2 RPC 3 3 SOAP (SIMPLE OBJECT ACCESS PROTOCOL) 3 4 UTILIZZO DI SOAP COME PROTOCOLLO

Dettagli

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014 Processi di business sovra-regionali relativi ai sistemi regionali di FSE Versione 1.0 24 Giugno 2014 1 Indice Indice... 2 Indice delle figure... 3 Indice delle tabelle... 4 Obiettivi del documento...

Dettagli

Manuale di Integrazione IdM-RAS

Manuale di Integrazione IdM-RAS IdM-RAS Data: 30/11/09 File: Manuale di integrazione IdM-RAS.doc Versione: Redazione: Sardegna IT IdM-RAS Sommario 1 Introduzione... 3 2 Architettura del sistema... 4 2.1 Service Provider... 4 2.2 Local

Dettagli

REGOLE PROCEDURALI DI CARATTERE TECNICO OPERATIVO PER L ACCESSO AI SERVIZI DISPONIBILI TRAMITE LA POSTA ELETTRONICA CERTIFICATA

REGOLE PROCEDURALI DI CARATTERE TECNICO OPERATIVO PER L ACCESSO AI SERVIZI DISPONIBILI TRAMITE LA POSTA ELETTRONICA CERTIFICATA Dipartimento per gli Affari di Giustizia Direzione Generale della Giustizia Penale Decreto Dirigenziale Articolo 39 D.P.R. 14 Novembre 2002, N. 313 Decreto Dirigenziale del 5 dicembre 2012 recante le regole

Dettagli

Manuale Gestione di OpenSPCoop 1.4 i. Manuale Gestione di OpenSPCoop 1.4

Manuale Gestione di OpenSPCoop 1.4 i. Manuale Gestione di OpenSPCoop 1.4 i Manuale Gestione di OpenSPCoop 1.4 ii Copyright 2005-2011 Link.it srl iii Indice 1 Introduzione 1 2 Prerequisiti per la Configurazione della Porta di Dominio 1 2.1 Verifica dell applicazione di gestione

Dettagli

Governance e linee guida tecnicoorganizzative

Governance e linee guida tecnicoorganizzative Allegato 1 Servizio Governance e linee guida tecnicoorganizzative del sistema ICAR-ER INDICE 1. Introduzione 3 1.1 Definizione e Acronimi 3 1.2 Scopo del documento 4 1.3 Destinatari 4 2. Il Sistema ICAR-ER

Dettagli

automation using workflow technology and web services Vassilacopoulos Med. Inform. (September 2003) vol. 28, no. 3,

automation using workflow technology and web services Vassilacopoulos Med. Inform. (September 2003) vol. 28, no. 3, Emergency healthcare process automation using workflow technology and web services M. Poulymenopoulou, F. Malamateniou, G. Vassilacopoulos Med. Inform. (September 2003) vol. 28, no. 3, 195 207 Processo

Dettagli

Progettaz. e sviluppo Data Base

Progettaz. e sviluppo Data Base Progettaz. e sviluppo Data Base! Introduzione ai Database! Tipologie di DB (gerarchici, reticolari, relazionali, oodb) Introduzione ai database Cos è un Database Cos e un Data Base Management System (DBMS)

Dettagli

Architettura Tecnica i. Architettura Tecnica

Architettura Tecnica i. Architettura Tecnica i Architettura Tecnica ii Copyright 2005-2011 Link.it s.r.l. iii Indice 1 Scopo del documento 1 1.1 Abbreviazioni..................................................... 1 2 Overview 1 2.1 La PdD........................................................

Dettagli

Presentazione di Cedac Software

Presentazione di Cedac Software Agenda Presentazione di Cedac Software SOA ed ESB Analisi di un caso studio Esempi Q&A Presentazione di Cedac Software 1 2 Presentazione di Cedac Software S.r.l. Divisione Software Azienda nata nel 1994

Dettagli

Guida Utente della PddConsole. Guida Utente della PddConsole

Guida Utente della PddConsole. Guida Utente della PddConsole Guida Utente della PddConsole i Guida Utente della PddConsole Guida Utente della PddConsole ii Copyright 2005-2014 Link.it srl Guida Utente della PddConsole iii Indice 1 Introduzione 1 2 I protocolli di

Dettagli

Seminario di Sistemi Distribuiti RPC su SOAP

Seminario di Sistemi Distribuiti RPC su SOAP Seminario di Sistemi Distribuiti RPC su SOAP Massimiliano Vivian [777775] Massimiliano Vivian 1 Introduzione La comunicazione delle informazioni è l elemento fondamentale per lo sviluppo dei sistemi. SOAP

Dettagli

Architettura del sistema

Architettura del sistema 18/06/15 I N D I C E 1 INTRODUZIONE... 2 2 DEFINIZIONE DEGLI OBIETTIVI... 2 3 PROGETTO DI MASSIMA... 3 3.1 REQUISITI DELLA SOLUZIONE... 4 4 LA SOLUZIONE... 4 4.1 IL NUCLEO CENTRALE... 5 4.1.1 La gestione

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

Dettagli

MONITORAGGIO UNITARIO PROGETTI 2007/2013 PROTOCOLLO DI COLLOQUI ANALISI ATTIVAZIONE SERVIZIO IGRUE IN SPCOOP. Link.it srl - Analisi Servizio IGRUE 1

MONITORAGGIO UNITARIO PROGETTI 2007/2013 PROTOCOLLO DI COLLOQUI ANALISI ATTIVAZIONE SERVIZIO IGRUE IN SPCOOP. Link.it srl - Analisi Servizio IGRUE 1 MONITORAGGIO UNITARIO PROGETTI 2007/2013 PROTOCOLLO DI COLLOQUI ANALISI ATTIVAZIONE SERVIZIO IGRUE IN SPCOOP Link.it srl - Analisi Servizio IGRUE 1 Panoramica L'attuale sistema IGRUE è composto da: Il

Dettagli

SERVICE BROWSER. Versione 1.0

SERVICE BROWSER. Versione 1.0 SERVICE BROWSER Versione 1.0 25/09/2008 Indice dei Contenuti 1. Scopo del documento... 3 2. Introduzione... 3 3. Accordi di Servizio... 4 4. Servizi... 5 5. Servizio: Schede Erogatori... 8 6. Servizio:

Dettagli

GESTIONE DELLA POSTA ELETTRONICA CERTIFICATA - PEC GEPROT v 3.1

GESTIONE DELLA POSTA ELETTRONICA CERTIFICATA - PEC GEPROT v 3.1 GESTIONE DELLA POSTA ELETTRONICA CERTIFICATA - PEC GEPROT v 3.1 ESPLETAMENTO DI ATTIVITÀ PER L IMPLEMENTAZIONE DELLE COMPONENTI PREVISTE NELLA FASE 3 DEL PROGETTO DI E-GOVERNMENT INTEROPERABILITÀ DEI SISTEMI

Dettagli

Web Service Architecture

Web Service Architecture Giuseppe Della Penna Università degli Studi di L Aquila dellapenna@di.univaq.it http://dellapenna.univaq.it Engineering IgTechnology Info92 Maggioli Informatica Micron Technology Neta Nous Informatica

Dettagli

OpenSPCoop: un implementazione della Specifica di Cooperazione Applicativa per la Pubblica Amministrazione Italiana

OpenSPCoop: un implementazione della Specifica di Cooperazione Applicativa per la Pubblica Amministrazione Italiana UNIVERSITÀ DI PISA Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea Specialistica in Tecnologie Informatiche Tesi di Laurea Specialistica OpenSPCoop: un implementazione della Specifica

Dettagli

Manuale gestione Porta di Dominio OpenSPCoop 1.1

Manuale gestione Porta di Dominio OpenSPCoop 1.1 i Manuale gestione Porta di Dominio ii Copyright 2005-2008 Link.it srl Questo documento contiene informazioni di proprietà riservata, protette da copyright. Tutti i diritti sono riservati. Non è permesso

Dettagli

Strategie di system integration per l interoperabilità di sistemi eterogenei di Fascicolo Sanitario Elettronico

Strategie di system integration per l interoperabilità di sistemi eterogenei di Fascicolo Sanitario Elettronico Consiglio Nazionale delle Ricerche Istituto di Calcolo e Reti ad Alte Prestazioni Strategie di system integration per l interoperabilità di sistemi eterogenei di Fascicolo Sanitario Elettronico Mario Ciampi

Dettagli

Laboratorio di RETI DI CALCOLATORI

Laboratorio di RETI DI CALCOLATORI Laboratorio di RETI DI CALCOLATORI A.A. 2009-2010 I WEB SERVICES Carlo Mastroianni Laboratorio di Reti di Calcolatori - Orario lunedì, 11:30-13:30, aula 40B mercoledì, 10:00-11:30, laboratorio settimo

Dettagli

CdL MAGISTRALE in INFORMATICA

CdL MAGISTRALE in INFORMATICA 05/11/14 CdL MAGISTRALE in INFORMATICA A.A. 2014-2015 corso di SISTEMI DISTRIBUITI 7. I processi : il naming Prof. S.Pizzutilo Il naming dei processi Nome = stringa di bit o di caratteri utilizzata per

Dettagli

Sistemi avanzati di gestione dei Sistemi Informativi

Sistemi avanzati di gestione dei Sistemi Informativi Esperti nella gestione dei sistemi informativi e tecnologie informatiche Sistemi avanzati di gestione dei Sistemi Informativi Docente: Email: Sito: Eduard Roccatello eduard@roccatello.it http://www.roccatello.it/teaching/gsi/

Dettagli

Il Registro dei Servizi di OpenSPCoop i. Il Registro dei Servizi di OpenSPCoop

Il Registro dei Servizi di OpenSPCoop i. Il Registro dei Servizi di OpenSPCoop i Il Registro dei Servizi di OpenSPCoop ii Copyright 2005-2011 Link.it srl iii Indice 1 Introduzione 1 2 Visualizzazione del registro dei servizi HTTP 1 3 Visualizzazione del registro dei servizi UDDI

Dettagli

PROTOCOLLO INFORMATICO E GESTIONE ELETTRONICA DEI DOCUMENTI: PRESENTAZIONE BASE

PROTOCOLLO INFORMATICO E GESTIONE ELETTRONICA DEI DOCUMENTI: PRESENTAZIONE BASE PROTOCOLLO INFORMATICO E GESTIONE ELETTRONICA DEI DOCUMENTI: PRESENTAZIONE BASE Guglielmo LONGOBARDI Centro di Competenza Trasparenza e gestione elettronica dei documenti ALL ORIGINE DEI SISTEMI DOCUMENTARI

Dettagli

Gestione XML della Porta di Dominio OpenSPCoop

Gestione XML della Porta di Dominio OpenSPCoop i Gestione XML della Porta di Dominio ii Copyright 2005-2011 Link.it srl iii Indice 1 Introduzione 1 2 Hello World! 2 3 Configurazione XML della Porta di Dominio 5 3.1 Soggetto SPCoop...................................................

Dettagli

COLOGNO MONZESE INDICE ART. 1 DEFINIZIONE E PRINCIPI GENERALI ART. 2 FINALITA E FUNZIONI DELL UFFICIO RELAZIONI CON IL PUBBLICO

COLOGNO MONZESE INDICE ART. 1 DEFINIZIONE E PRINCIPI GENERALI ART. 2 FINALITA E FUNZIONI DELL UFFICIO RELAZIONI CON IL PUBBLICO CRITERI PER L ORGANIZZAZIONE E IL FUNZIONAMENTO DELL UFFICIO RELAZIONI CON IL PUBBLICO U.R.P. (art. 8 c. 2 della Legge n. 150/2000) Disciplina delle attività di informazione e di comunicazione delle pubbliche

Dettagli

Mattone 9 Realizzazione del Patient File

Mattone 9 Realizzazione del Patient File Mattone 9 Realizzazione del Patient File Architettura di Cooperazione Roma 19 Giugno 2007 Nolan, Norton Italia Definizione del Fascicolo Sanitario Personale (FaSP) Non qualsiasi raccolta strutturata di

Dettagli

Web Services. Scoperta del servizio UDDI. Descrizione del servizio WSDL. Accesso al servizio SOAP XML. Starto di comunicazione HTTP

Web Services. Scoperta del servizio UDDI. Descrizione del servizio WSDL. Accesso al servizio SOAP XML. Starto di comunicazione HTTP Web Services I web services servono a rendere interoperabili le applicazioni e favoriscono la loro integrazione. I servizi web sono applicazioni software che possono essere scoperte, descritte e usate

Dettagli

Accordi. Tecnologie di cooperazione. Cooperazione fra Amministrazioni

Accordi. Tecnologie di cooperazione. Cooperazione fra Amministrazioni Alcune considerazioni nell ambito di un sistema di cooperazione informatico che preveda lo scambio di dati tra due o più organizzazioni. Quando parliamo di un sistema di cooperazione informatico ci riferiamo

Dettagli

JBoss ESB Un caso d'uso italiano: La Porta di Dominio per la Cooperazione Applicativa

JBoss ESB Un caso d'uso italiano: La Porta di Dominio per la Cooperazione Applicativa JBoss ESB Un caso d'uso italiano: La Porta di Dominio per la Cooperazione Applicativa Andrea Leoncini JBoss Stefano Linguerri - Pro-netics Agenda JBoss ESB le SOA e la Porta di Dominio Le specifiche CNIPA

Dettagli

LE TECNOLOGIE PER IL CAMBIAMENTO 2

LE TECNOLOGIE PER IL CAMBIAMENTO 2 LE TECNOLOGIE PER IL CAMBIAMENTO 2 CITTADINANZA DIGITALE: GLI STRUMENTI La cooperazione applicativa - ICAR Andrea Nicolini PM ICAR - CISIS Roma, 1 ottobre 2010 Agenda E-gov in Italia negli ultimi 10 anni

Dettagli

Indirizzi Internet e. I livelli di trasporto delle informazioni. Comunicazione e naming in Internet

Indirizzi Internet e. I livelli di trasporto delle informazioni. Comunicazione e naming in Internet Indirizzi Internet e Protocolli I livelli di trasporto delle informazioni Comunicazione e naming in Internet Tre nuovi standard Sistema di indirizzamento delle risorse (URL) Linguaggio HTML Protocollo

Dettagli

Specifiche di notifica delle variazioni anagrafiche dei Medici dei Servizi Territoriali

Specifiche di notifica delle variazioni anagrafiche dei Medici dei Servizi Territoriali Regione Puglia Specifiche di notifica delle variazioni anagrafiche dei Medici dei Servizi Territoriali Versione 1.02 13 Maggio 2013 DIRITTI DI AUTORE E CLAUSOLE DI RISERVATEZZA La proprietà del presente

Dettagli

S.I.L.P SISTEMA INFORMATIVO LAVORO PIEMONTE

S.I.L.P SISTEMA INFORMATIVO LAVORO PIEMONTE S.I.L.P SISTEMA INFORMATIVO LAVORO PIEMONTE SERVIZI DI INFRASTRUTTURA Vista d'insieme Questo documento definisce la visione d insieme del nuovo Sistema Informativo Lavoro ed è teso ad illustrare le caratteristiche

Dettagli

MANUALE UTENTE FORMULA PEC

MANUALE UTENTE FORMULA PEC MANUALE UTENTE FORMULA PEC Stampato il 03/12/10 16.22 Pagina 1 di 22 REVISIONI Revisione n : 00 Data Revisione: 01/04/2010 Descrizione modifiche: Nessuna modifica Motivazioni: Prima stesura Stampato il

Dettagli

Allegato 3 Sistema per l interscambio dei dati (SID)

Allegato 3 Sistema per l interscambio dei dati (SID) Sistema per l interscambio dei dati (SID) Specifiche dell infrastruttura per la trasmissione delle Comunicazioni previste dall art. 11 comma 2 del decreto legge 6 dicembre 2011 n.201 Sommario Introduzione...

Dettagli

QUALIFICAZIONE DELLA PORTA DI DOMINIO

QUALIFICAZIONE DELLA PORTA DI DOMINIO QUALIFICAZIONE DELLA PORTA DI DOMINIO IN MODALITÀ PROVVISORIA Versione 1.0 Qualificazione della Porta di INDICE 1. PROCESSO DI QUALIFICAZIONE DELLA PORTA DI DOMINIO IN MODALITÀ PROVVISORIA 3 2. DESCRIZIONE

Dettagli

Allegato Tecnico IcarER

Allegato Tecnico IcarER Allegato Tecnico IcarER Nota di lettura 1 Descrizione del Servizio 1.1 Definizioni e Acronimi 1.2 Descrizione generale 1.2.1 Accordo di servizio 1.3 Descrizione dei servizi offerti 1.3.1 Gestione in service

Dettagli

Il Gestore Eventi di OpenSPCoop i. Il Gestore Eventi di OpenSPCoop

Il Gestore Eventi di OpenSPCoop i. Il Gestore Eventi di OpenSPCoop i Il Gestore Eventi di OpenSPCoop ii Copyright 2005-2011 Link.it srl iii Indice 1 Introduzione 1 2 Configurazione di un Servizio SPCoop come Evento gestito dal GE 2 3 Configurazione di un Pubblicatore

Dettagli

Il DNS e la gestione degli indirizzi IP. Appunti a cura del prof. ing. Mario Catalano

Il DNS e la gestione degli indirizzi IP. Appunti a cura del prof. ing. Mario Catalano Il DNS e la gestione degli indirizzi IP Appunti a cura del prof. ing. Mario Catalano Indirizzi fisici e indirizzi astratti Ogni macchina all interno di una rete è identificata da un indirizzo hardware

Dettagli

Gestione remota archivi cartelle sanitarie e di rischio informatizzate

Gestione remota archivi cartelle sanitarie e di rischio informatizzate Gestione remota archivi cartelle sanitarie e di rischio informatizzate L odierna realtà economica impone alle aziende di differenziarsi sempre più dai concorrenti, investendo in tecnologie che possano

Dettagli

OpenSPCoop Un Implementazione Open Source della specifica SPCoop di Cooperazione Applicativa

OpenSPCoop Un Implementazione Open Source della specifica SPCoop di Cooperazione Applicativa OpenSPCoop Un Implementazione Open Source della specifica SPCoop di Cooperazione Applicativa Tito Flagella tito@link.it http://openspcoop.org La Cooperazione Applicativa Regolamentazione delle modalità

Dettagli

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Relatore Chiarissimo

Dettagli

Centro Nazionale per l Informatica nella Pubblica Amministrazione

Centro Nazionale per l Informatica nella Pubblica Amministrazione Centro Nazionale per l Informatica nella Pubblica Amministrazione Procedura ristretta n. 2/2006 per l affidamento della progettazione, realizzazione e gestione di componenti di cooperazione applicativa,

Dettagli

Introduzione alla Cooperazione applicativa in Campania

Introduzione alla Cooperazione applicativa in Campania Introduzione alla Cooperazione applicativa in Campania Cos è SPICCA è una infrastruttura costituita dall insieme di risorse hardware e componenti applicative, rappresenta la piattaforma per la realizzazione

Dettagli

PIANO DI INFORMATIZZAZIONE

PIANO DI INFORMATIZZAZIONE Comune di Rocca San Giovanni PIANO DI INFORMATIZZAZIONE delle procedure per la presentazione e compilazione on-line da parte di cittadini ed imprese delle istanze, dichiarazioni e segnalazioni al comune

Dettagli

Allegato 1 CIG 58703795FF PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO

Allegato 1 CIG 58703795FF PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO SOMMARIO 1 Oggetto della Fornitura... 3 2 Composizione della Fornitura... 3 2.1 Piattaforma

Dettagli

La Fatturazione Elettronica verso la PA

La Fatturazione Elettronica verso la PA La Fatturazione Elettronica verso la PA Il 6 giugno 2014 sarà una data importante in quanto entra in vigore il D.M. 55/2013 che ha stabilito le modalità attuative per fatturazione elettronica nei confronti

Dettagli

SISTEMI OPERATIVI DISTRIBUITI

SISTEMI OPERATIVI DISTRIBUITI SISTEMI OPERATIVI DISTRIBUITI E FILE SYSTEM DISTRIBUITI 12.1 Sistemi Distribuiti Sistemi operativi di rete Sistemi operativi distribuiti Robustezza File system distribuiti Naming e Trasparenza Caching

Dettagli

POSTA ELETTRONICA (TRADIZIONALE e CERTIFICATA) FIRMA DIGITALE PROTOCOLLO INFORMATICO. Maurizio Gaffuri 11 ottobre 2007

POSTA ELETTRONICA (TRADIZIONALE e CERTIFICATA) FIRMA DIGITALE PROTOCOLLO INFORMATICO. Maurizio Gaffuri 11 ottobre 2007 POSTA ELETTRONICA (TRADIZIONALE e CERTIFICATA) FIRMA DIGITALE PROTOCOLLO INFORMATICO Maurizio Gaffuri 11 ottobre 2007 1 POSTA ELETTRONICA TRADIZIONALE e POSTA ELETTRONICA CERTIFICATA 2 POSTA ELETTRONICA

Dettagli

Un caso concreto di dematerializzazione e semplificazione dei processi inter -amministrazioni: la gestione dei contratti dei docenti

Un caso concreto di dematerializzazione e semplificazione dei processi inter -amministrazioni: la gestione dei contratti dei docenti FORUMPA 2008 13 maggio 2008 Un caso concreto di dematerializzazione e semplificazione dei processi inter -amministrazioni: la gestione dei contratti dei docenti Modello applicativo e tecnologico dott.ssa

Dettagli

La Gestione degli Accordi di Cooperazione nel progetto OpenSPCoop

La Gestione degli Accordi di Cooperazione nel progetto OpenSPCoop Università degli Studi di Pisa Facoltà di Scienze Matematiche Fisiche e Naturali Dipartimento di Informatica TESI DI LAUREA La Gestione degli Accordi di Cooperazione nel progetto OpenSPCoop Relatori prof.

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T2 B1 - Progettazione dei DB 1 Prerequisiti Ciclo di vita del software file system Metodologia di progettazione razionale del software 2 1 Introduzione Per la realizzazione

Dettagli

Parte II: Reti di calcolatori Lezione 9

Parte II: Reti di calcolatori Lezione 9 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Parte II: Reti di calcolatori Lezione 9 Martedì 1-04-2014 1 Applicazioni P2P

Dettagli

PRIVACY E SICUREZZA http://www.moviwork.com http://www.moviwork.com de.co dsign&communication di Celestina Sgroi

PRIVACY E SICUREZZA http://www.moviwork.com http://www.moviwork.com de.co dsign&communication di Celestina Sgroi PRIVACY E SICUREZZA LA PRIVACY DI QUESTO SITO In questa pagina si descrivono le modalità di gestione del sito in riferimento al trattamento dei dati personali degli utenti che lo consultano. Tale politica

Dettagli

Gestione Richieste Patenti Web

Gestione Richieste Patenti Web >> Specifiche Integrazione Web Services RTI Gestione Richieste Patenti Web Servizio di Sviluppo SVI Versione 1.0-07 Dicembre 2009 Indice dei contenuti 1 GENERALITA... 6 1.1 Lista di distribuzione...6 1.2

Dettagli

Oreste Signore, <oreste@w3.org> Responsabile Ufficio Italiano W3C Area della Ricerca CNR - via Moruzzi, 1-56124 Pisa

Oreste Signore, <oreste@w3.org> Responsabile Ufficio Italiano W3C Area della Ricerca CNR - via Moruzzi, 1-56124 Pisa http://www.w3c.it/education/2012/upra/basicinternet/#(1) 1 of 16 Oreste Signore, Responsabile Ufficio Italiano W3C Area della Ricerca CNR - via Moruzzi, 1-56124 Pisa Master in Comunicazione

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

Introduzione all elaborazione di database nel Web

Introduzione all elaborazione di database nel Web Introduzione all elaborazione di database nel Web Prof.ssa M. Cesa 1 Concetti base del Web Il Web è formato da computer nella rete Internet connessi fra loro in una modalità particolare che consente un

Dettagli

Corso Sviluppatore servizi per il Web (WCF) Lezione 01

Corso Sviluppatore servizi per il Web (WCF) Lezione 01 01 Introduzione Introduzione alla tecnologia WCF Premessa Il corso su WCF di cui state leggendo la prima lezione, vi guiderà alla scoperta di questa nuova tecnologia introdotta da Microsoft per venire

Dettagli

Interoperabilità dei Protocolli Informatici delle pubbliche amministrazioni lucane

Interoperabilità dei Protocolli Informatici delle pubbliche amministrazioni lucane Interoperabilità dei Protocolli Informatici delle pubbliche amministrazioni lucane Incontro fornitori terze parti Potenza, 30 giugno 2011 Consorzio Integra e Centro Servizi Basilicata Regione Basilicata

Dettagli

Introduzione a Internet e al World Wide Web

Introduzione a Internet e al World Wide Web Introduzione a Internet e al World Wide Web Una rete è costituita da due o più computer, o altri dispositivi, collegati tra loro per comunicare l uno con l altro. La più grande rete esistente al mondo,

Dettagli

LA FATTURAZIONE ELETTRONICA

LA FATTURAZIONE ELETTRONICA Roma, 24 luglio 2014 LA FATTURAZIONE ELETTRONICA Pubblichiamo di seguito un documento dell Agenzia per l Italia Digitale (AGID) che illustra le principali caratteristiche del passaggio alla fatturazione

Dettagli

MAGO CRESCO - SPI.2. Relazione finale sul Progetto MAGO. Consorzio Campano di Ricerca per l Informatica e l Automazione Industriale S.c.a.r.l.

MAGO CRESCO - SPI.2. Relazione finale sul Progetto MAGO. Consorzio Campano di Ricerca per l Informatica e l Automazione Industriale S.c.a.r.l. CRESCO - SPI.2 MAGO Relazione finale sul Progetto MAGO Relativo al contratto tra ENEA e CRIAI avente per oggetto: Analisi e Realizzazione di tool innovativi a supporto delle funzionalità GRID stipulato

Dettagli

Enterprise @pplication Integration Software S.r.l.

Enterprise @pplication Integration Software S.r.l. SAP rel.1.0 : SAP State: Final Date: 03-27-200 Enterprise @pplication Integration Software S.r.l. Sede legale: Via Cola di Rienzo 212-00192 Rome - Italy Tel. +39.06.6864226 Sede operativa: viale Regina

Dettagli

Ministero della Giustizia

Ministero della Giustizia Ministero della Giustizia DIPARTIMENTO DELL ORGANIZZAZIONE GIUDIZIARIA, DEL PERSONALE E DEI SERVIZI DIREZIONE GENERALE PER I SISTEMI INFORMATIVI AUTOMATIZZATI AREA CIVILE POLISWEB Piano delle verifiche

Dettagli

Appendice D. D. Web Services

Appendice D. D. Web Services D. D.1 : cosa sono I cosiddetti sono diventati uno degli argomenti più attuali nel panorama dello sviluppo in ambiente Internet. Posti al centro delle più recenti strategie di aziende del calibro di IBM,

Dettagli

Programmazione Web. Introduzione

Programmazione Web. Introduzione Programmazione Web Introduzione 2014/2015 1 Un'applicazione Web (I) 2014/2015 Programmazione Web - Introduzione 2 Un'applicazione Web (II) 2014/2015 Programmazione Web - Introduzione 3 Un'applicazione

Dettagli

GESTIONE delle richieste di HELPDESK GEPROT v 3.1

GESTIONE delle richieste di HELPDESK GEPROT v 3.1 GESTIONE delle richieste di HELPDESK GEPROT v 3.1 ESPLETAMENTO DI ATTIVITÀ PER L IMPLEMENTAZIONE DELLE COMPONENTI PREVISTE NELLA FASE 3 DEL PROGETTO DI E-GOVERNMENT INTEROPERABILITÀ DEI SISTEMI DI PROTOCOLLO

Dettagli

fornitore di servizi utente all interazione tra utenti e sistemi

fornitore di servizi utente all interazione tra utenti e sistemi WEB SERVICES Successo del Web Negli anni passati il Web ha avuto un enorme successo principalmente per due motivi: Semplicità: Ubiquità Per un fornitore di servizi è semplice raggiungere un numero molto

Dettagli

Centro Tecnico per la Rete Unitaria della Pubblica Amministrazione

Centro Tecnico per la Rete Unitaria della Pubblica Amministrazione Centro Tecnico per la Rete Unitaria della Pubblica Amministrazione Area Rete Unitaria - Sezione Interoperabilità Linee guida del servizio di trasmissione di documenti informatici mediante posta elettronica

Dettagli

Formato per la rappresentazione elettronica dei provvedimenti normativi tramite il linguaggio di marcatura XML.

Formato per la rappresentazione elettronica dei provvedimenti normativi tramite il linguaggio di marcatura XML. Circolare 22 aprile 2002 n. AIPA/CR/40 Formato per la rappresentazione elettronica dei provvedimenti normativi tramite il linguaggio di marcatura XML. A tutte le Amministrazioni pubbliche 1. Premessa L

Dettagli

Tra cartaceo e digitale: gestione e conservazione degli archivi degli enti pubblici

Tra cartaceo e digitale: gestione e conservazione degli archivi degli enti pubblici Regione Toscana Direzione generale Organizzazione Tra cartaceo e digitale: gestione e conservazione degli archivi degli enti pubblici ANAI Marche Fermo, 28 novembre 2012 Ilaria Pescini PO Archivi e sistema

Dettagli

L impatto del d. CAD e dell innovazione l innovazione tecnologica sull organizzazione dei procedimenti amministrativi. Bari, 3 luglio 2012

L impatto del d. CAD e dell innovazione l innovazione tecnologica sull organizzazione dei procedimenti amministrativi. Bari, 3 luglio 2012 L impatto del d CAD e dell innovazione l innovazione tecnologica sull organizzazione dei procedimenti amministrativi. Bari, 3 luglio 2012 Giovanni Damiano Agenda LA PA VISTA DALL UTENTE LE LEVE DEL CAMBIAMENTO

Dettagli

Una piattaforma per la negoziazione di servizi business to business attraverso la rete Internet

Una piattaforma per la negoziazione di servizi business to business attraverso la rete Internet Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea in Ingegneria Gestionale della Logistica e della Produzione Una piattaforma per la negoziazione di servizi business to

Dettagli

Lezione 8. Motori di Ricerca

Lezione 8. Motori di Ricerca Lezione 8 Motori di Ricerca Basi di dati Un campo prevalente dell applicazione informatica è quello costituito dall archiviazione e dalla gestione dei dati (basi di dati). Sistema Informativo. Un sistema

Dettagli

PROGETTO WEB SERVICES DOGANE SERVIZI PER RICEZIONE ED ELABORAZIONE MESSAGGI AMBIENTE REALE

PROGETTO WEB SERVICES DOGANE SERVIZI PER RICEZIONE ED ELABORAZIONE MESSAGGI AMBIENTE REALE Pag. 1 di 12 PROGETTO WEB SERVICES DOGANE SERVIZI PER RICEZIONE ED ELABORAZIONE MESSAGGI AMBIENTE REALE Pag. 1 di 12 Pag. 2 di 12 1 GENERALITÀ... 3 1.1 CANALI DI COMUNICAZIONE DEI SISTEMI... 3 2 SOA DOMINIO

Dettagli

Il glossario della Posta Elettronica Certificata (PEC) Diamo una definizione ai termini tecnici relativi al mondo della PEC.

Il glossario della Posta Elettronica Certificata (PEC) Diamo una definizione ai termini tecnici relativi al mondo della PEC. Il glossario della Posta Elettronica Certificata (PEC) Diamo una definizione ai termini tecnici relativi al mondo della PEC. Avviso di mancata consegna L avviso, emesso dal sistema, per indicare l anomalia

Dettagli