Architettura CART Versione /09/2010

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Architettura CART Versione 3.6 14/09/2010"

Transcript

1 Versione /09/2010

2 Indice dei Contenuti 1. PREFAZIONE INTRODUZIONE ARCHITETTURA GENERALE DEL CART COMPONENTI DELL ARCHITETTURA E INTERFACCE Il Registro SICA Secondario La Porta di Dominio del CentroServiziCART e La Componente di Validazione delle Buste egov Il Gestore Eventi Il Broker JMS Il TSB NICA gateway ICAR La Porta di Dominio dei La Componente di Integrazione della PdD dei e L Emulatore SOLE FCA IL SISTEMA DI CONFIGURAZIONE IL SISTEMA DI GESTIONE DEL CICLO DI VITA DEI SERVIZI CART (SLC) IL SISTEMA DI TRACCIAMENTO DEI MESSAGGI IL MONITORAGGIO APPLICATIVO IL SISTEMA DI MONITORAGGIO DEI SERVIZI PMC IL MONITORAGGIO DI DOMINIO CARATTERISTICHE DELL ARCHITETTURA INFRASTRUTTURA DI COOPERAZIONE IL PORTALE DELLA COMMUNITY CART RIEPILOGO DEI SERVIZI ARCHITETTURA SOFTWARE di 43

3 1. PREFAZIONE INFORMAZIONI CONTENUTE IN QUESTO DOCUMENTO Questo documento contiene una descrizione dal punto di vista generale e completa dell'infrastruttura CART. BIBLIOGRAFIA 1) Sistema pubblico di cooperazione: Servizi di Registro, SPCoop- ServiziRegistro_v1.0_ ServiziRegistro_v1.0_ pdf 2) Sistema pubblico di cooperazione: Accordo di Servizio, SPCoop- AccordoServizio_v1.0_ AccordoServizio_v1.0_ pdf 2. INTRODUZIONE L obiettivo di Regione Toscana è di creare, tramite il CART, una comunità di Soggetti capaci di esporre e integrare le loro applicazioni nell ottica di servizio, al fine di creare uno spazio comune di informazioni dove i sistemi informativi sono in grado di essere sia fornitori che fruitori di tali informazioni. L'infrastruttura CART è lo strumento utilizzato dalle applicazioni interoperanti dei soggetti appartenenti alla comunità (Comunità e.toscana) per scambiarsi informazioni. I punti fondamentali dell architettura realizzata sono: L aderenza a un insieme di standard L uso dei servizi infrastrutturali L'infrastruttura CART è pienamente compatibile con le specifiche SPCoop emesse dal CNIPA e ne seguirà le evoluzioni. Inoltre il CART è fondato su uno stack di moduli software e framework standard e in maggior parte di tipo Open Source. 3 di 43

4 Nella specifica SPCoop tutto ruota attorno al concetto di servizio: il servizio è l insieme dei risultati prodotti dai trattamenti effettuati da un Sistema Erogatore e utilizzati da un Sistema Fruitore. Ogni Soggetto che utilizza la l infrastruttura CART è in grado di recuperare le informazioni necessarie a fruire i servizi messi a disposizione. Per realizzare questo obiettivo l'infrastruttura è capace di: Descrivere i servizi tramite i loro Accordi di Servizio Pubblicare gli Accordi di Servizio su un Repository condiviso Permettere la ricerca e recupero dinamico gli Accordi di Servizio Garantire la sicurezza dell accesso ai servizi Permettere la fruizione dei servizi con una architettura in grado di adattarsi al carico Gestire i servizi Coordinare servizi al fine di implementare il concetto di Accordo di Cooperazione Quindi, dal punto di vista concettuale, l'infrastruttura CART può essere scomposto in Servizi, Catalogo dei Servizi e componenti per lo scambio dei Servizi. L'infrastruttura CART è infine caratterizzata da un insieme di strumenti per il supporto del monitoraggio, la gestione e la manutenzione dell infrastruttura. 3. ARCHITETTURA GENERALE DEL CART Le componenti fondamentali dell architettura CART sono: Il CRIC, Centro Regionale per l Interoperabilità e la Cooperazione applicativa è realizzato presso il TIX (Tuscany Internet Exchange) e ospita applicazioni e servizi infrastrutturali. I SIL (Sistemi Informativi Locali). sono i sistemi informativi delle singole amministrazioni che partecipano alla cooperazione. I (Nodo Applicativo Locale), costituiscono il punto di interfacciamento tra i SIL e il CRIC. La VPN del CART che garantisce la sicurezza di tutte le comunicazioni che intercorrono fra il CRIC ed i. 4 di 43

5 Internet CRIC NICA Gateway ICAR Gestore Eventi Portale CART Gestione e Monitoraggio Registro SICA secondario (UDDI) Porta di Dominio CART SPC VPN CART Porta di Dominio Dominio dell Ente Porta di Dominio Componente di Integrazione Agente di gestione e monitoraggio SIL Dominio dell Ente Figura 1 Il CRIC è la componente centralizzata che permette la comunicazione e la catalogazione dei servizi. Contiene inoltre strumenti per la configurazione, l amministrazione e il monitoraggio dei servizi erogati dai Soggetti regionali aderenti al CART. Tutte le informazioni di configurazione infrastrutturale sono gestite centralmente dal CRIC e propagate verso la periferia dei. Tutte le 5 di 43

6 informazioni riguardanti l esercizio sono propagate dalla periferia dei verso il CRIC. I principali componenti del CRIC sono: Catalogo dei servizi: il Registro SICA Secondario Infrastruttura per la fruizione ed erogazione dei Servizi basata su: o o o o La Porta di Dominio del soggetto SPCoop Centro Servizi CART; il Gestore Eventi; il Toscana Service Bus (TSB); NICA come gateway ICAR; Strumenti di supporto: il Sistema di Gestione, il sistema di Monitoraggio delle PdD, il sistema di Monitoraggio dei servizi (PMC) Le componenti di cooperazione del CRIC sono estese in accordo alle specifiche rilasciate dal task INF-1 del progetto ICAR (PdD SPCoop-ICAR, Gestore Eventi SPCoop-ICAR, registro SICA secondario SPCoop-ICAR) per consentire l interoperabilità tra i soggetti aderenti al CART e il resto dell universo SPCoop. Da un punto di vista logico tale funzione è assolta da un unico componente di interconnessione denominato NICA (Nodo di Interconnessione di Cooperazione Applicativa). 6 di 43

7 3.1. COMPONENTI DELL ARCHITETTURA E INTERFACCE Andiamo di seguito a riassumere lo scopo e le principali funzionalità di ciascuna componente, le interfacce esposte e gli scenari di cooperazione in cui entra in gioco. Per una discussione più dettagliata dell architettura logica del sistema e delle scelte effettuate si rimanda al documento di linee progettuali [TOSCART-GEST-LP] IL REGISTRO SICA SECONDARIO Questa componente svolge il ruolo di Registro SICA secondario per la Intranet SPCoop di Regione Toscana, così come previsto dalle specifiche standard. Il registro gestisce le informazioni sullo stato delle seguenti risorse: soggetti organizzativi della comunità SPCoop; servizi di cui i soggetti sono titolari, con i relativi accordi di servizio ed i relativi punti di accesso. Nell ambito della rete nazionale SPCoop, i Servizi di Registro SICA sono organizzati in modo distribuito attraverso un architettura master-slave con replicazione dell informazione. Esiste infatti un Registro SICA Generale, che contiene la totalità delle informazioni necessarie all erogazione delle funzionalità su tutta la rete SPCoop ed una serie di Registri SICA secondari, che contengono delle viste di tali informazioni, definite secondo differenti criteri (e.g., localizzazione geografica, per affinità funzionale, per affinità rispetto all erogatore, etc.). Il Registro SICA secondario del CART è quindi il registro dei Soggetti e degli Accordi di Servizio della Intranet SPCoop di Regione Toscana che, grazie alle funzionalità di registrazione e ricerca da esso implementate, consente di eseguire interrogazioni sull informazione mantenuta nel registro ed effettuare gli opportuni aggiornamenti (ad es. quando viene offerto un nuovo soggetto, un nuovo servizio, etc.). Un servizio è una funzionalità che risiede in un dominio applicativo specifico e che viene messa a disposizione di altri Soggetti. Per fare questo, a parte la necessaria infrastruttura di comunicazione e sicurezza, è necessario che chi usufruisce del servizio sappia esattamente quali sono le funzionalità che eroga. Un servizio viene quindi specificato da un Accordo di Servizio (AS) contenente informazioni sia di tipo formale che informale. Mentre il primo tipo è usato dalle applicazioni che ne usufruiscono per accedere al servizio e usarlo, il secondo tipo ha finalità descrittive destinate alle persone. L accordo di servizio contiene informazioni riguardanti le funzionalità e le interfacce di scambio messaggi che l erogatore mette a disposizione. L accordo di servizio descrive una comunicazione/collaborazione 2-party in cui un soggetto offre un servizio applicativo SPCoop e un altro soggetto fruisce di tale 7 di 43

8 servizio; l accordo è stipulato tra il fornitore e il fruitore prima dell erogazione del servizio stesso. L accordo di servizio è composto da una parte comune (ASPC), che formalizza gli aspetti riusabili in differenti contesti, e da una parte specifica, che precisa e dettaglia la parte comune per una particolare coppia <erogatore, fruitore> (ASPC). La parte comune di un AS contiene i seguenti documenti: - Specifica dell Interfaccia, si compone di tre specifiche WSDL astratte: - WSDL Concettuale (livello di scenario di coordinamento) - WSDL logico lato Erogatore (scambio elementare di messaggi) - WSDL logico lato Fruitore (scambio elementare di messaggi) - Specifica della Semantica dell informazione veicolata dal servizio tramite un riferimento ad una ontologia/schema concettuale. La parte specifica dell AS riguarda le seguenti informazioni : - La specifica degli aspetti implementativi dei Web Service ovvero l URI dei punti d accesso dei Web Service dell erogatore e fruitore ed i binding (basati sulla Busta egov) delle varie operazioni. - La specifica dei Livelli di Servizio e le obbligazioni che legano la specifica coppia <erogatore, fruitore>. - La Specifica delle caratteristiche di sicurezza supportate e richieste dal servizio. Infine, sia nella parte comune che nella parte specifica è possibile trovare una specifica semiformale, a livello concettuale e logico, espressa in UML, HTML, o anche in linguaggio naturale. In particolare nella parte comune dell'accordo di servizio saranno presenti riferimenti ad RFC e.toscana (http://web.rete.toscana.it/ecompliance). Implementazione del Registro Servizi nel CART Il Registro Servizi del CART è realizzato tramite un registro in tecnologia UDDI e un repository HTTP degli accordi di servizio, tipicamente espressi in XML, e riferiti dal registro UDDI. Sostanzialmente esistono un insieme di file XML diversi, tanti quanti sono i soggetti in gioco e i servizi erogati, ognuno dei quali descrive uno specifico Ente o Servizio. I file XML, memorizzati in un server web e reperibili quindi via HTTP, sono riferiti a partire da oggetti registrati in un registro UDDI. 8 di 43

9 Nella figura che segue viene mostrata la struttura del registro dei Servizi, istanziata sulla definizione del servizio SPC/ComunicazioneVariazione erogato dal soggetto SPC/MinisteroErogatore Registro Servizi nel CART Registrazione Soggetti SPCoop Per la registrazione di un soggetto nel registro UDDI viene utilizzata una chiave di tassonomia appositamente definita. La registrazione del soggetto comporta la creazione di una 'Business Entity' che possiede: 9 di 43

10 - un Identifier Bag che memorizza una KeyedReference a cui è associata l identificativo del dominio nel campo KeyName e l identificatore del soggetto nel campo KeyValue; - una Category Bag che memorizza una KeyedReference a cui è associata nel campo KeyValue la url che indirizza il file XML che descrive il soggetto. Registrazione Servizi La registrazione di un servizio richiede la precedente registrazione del Soggetto che lo eroga. Viene creato un Business Service con il campo nome contenente l identificatore del servizio. Associato al Business Service viene creato un Binding Template contenente nel campo Access Point il riferimento al file XML che descrive le funzionalità SPCoop del servizio. Inoltre, associata al Binding Template esiste una TModel specifica per il servizio nella quale, nel campo OverviewURL, è presente il riferimento al file WSDL che descrive il servizio. Il registro viene aggiornato per mezzo della console di configurazione, non espone delle interfacce applicative ma può essere interrogato via http/s. Il Registro SICA secondario non entra direttamente in gioco in alcuno scenario di cooperazione LA PORTA DI DOMINIO DEL CENTROSERVIZICART E LA COMPONENTE DI VALIDAZIONE DELLE BUSTE EGOV L architettura del sistema CART è caratterizzata da una tipica topologia a stella di cui la Porta di Dominio del Centro Servizi rappresenta il nodo centrale e svolge il ruolo di relay per tutto il traffico egov da e verso i. Essa, infatti si occupa di: effettuare il routing (agendo come relay per i singoli ) delle buste e.gov provenienti da un e dirette ad qualsiasi soggetto SPCoop interno o esterno al dominio di cooperazione del CART, e viceversa; tracciare centralmente tutte le comunicazioni che avvengono tra le Porte di Dominio dei ; implementare un controllo di sicurezza delle buste SPCoop, che verifica centralmente l aderenza delle richieste in arrivo rispetto alle politiche previste negli accordi di servizio; è da notare che il firewall xml, previsto come componente opzionale dalla specifica SPCoop, non è implementato nel CART, essendo stati considerati gli apparati firewall installati a protezione della Rete del CART e i controlli di sicurezza sulle buste, funzionalità sufficienti a gestire la sicurezza delle comunicazioni SPCoop. 10 di 43

11 Una tale topologia di rete ha significativi vantaggi dal punto di vista della sicurezza, permettendo di abilitare le Porte di Dominio sui al dialogo (e quindi a una relazione di trust) con la sola PdD del Centro Servizi CART e forzando nel centro servizi una serie di controlli di sicurezza che altrimenti sarebbero a carico esclusivamente dei singoli. Essa, inoltre, non modifica in alcun modo la logica punto-punto della comunicazione tra la PdD mittente e quella destinataria. La PdD del Centro Servizi CART si interfaccia con: Le PdD dei che costituiscono la Intranet SPCoop di Regione Toscana (http/s) Le PdD degli Enti esterni al CART che intendono comunicare con gli Enti della Intranet SPCoop di Regione Toscana (http/s) Il database delle tracce SPCoop (jdbc) Il Repository della Configurazione dove sono definite le policy di accesso dei SIL ai servizi (ovvero agli eventi in caso di interazione con il broker JMS), tramite la propria componente di validazione delle buste di egov. Il Gestore Eventi, integrato come servizio SPCoop (http/s) Il Toscana Service Bus (TSB) con funzionalità di mediatore dei messaggi, integrato come servizio SPCoop (http/s) Il NICA in quanto gateway verso ICAR. La PdD del Centro Servizi CART entra in gioco in tutti gli scenari di cooperazione eccetto quelli che prevedono la comunicazione diretta fra i tramite broker JMS. 11 di 43

12 Repository Config Tracce SPCoop Autorizzazione Buste egov SPC Porta di Dominio CentroServiziCART NICA Gestore Eventi TSB VPN CART Porta di Dominio Porta di Dominio La PdD OpenSPCoop effettua una verifica sintattica e semantica delle richieste in arrivo rispetto alle politiche previste negli accordi di servizio. La PdD del CentroServiziCART integra inoltre un modulo specifico che provvede ad effettuare un ulteriore controllo di autorizzazione, interagendo con il Repository centrale della configurazione, depositario delle informazioni sui ruoli e sulle politiche di accesso. Il Repository della configurazione ospita infatti tutte le informazioni relative alle policy di accesso dei Sistemi Informativi Locali ai Servizi (o Eventi) erogati in Cooperazione Applicativa. Una policy lega un fruitore a un servizio e definisce una regola che indica in che modo il fruitore deve accedere al servizio. Tali informazioni, gestite su un database relazionale, vengono inoltre replicate su server LDAP. La verifica avviene a partire dal nome del fruitore e del servizio di cui vuole usufruire (sono noti al momento della richiesta) in due fasi: si verifica che le entry che rappresentano il SIL ed il servizio richiesto posseggano il medesimo ruolo: se il ruolo è lo stesso significa che il fruitore ha richiesto un servizio che gli può essere erogato; si verifica se le modalità indicate dalla regola coincidono con quelle che il fruitore ha intrapreso/richiesto; la corrispondenza tra queste consente al fruitore di ottenere l'autorizzazione a procedere, il caso contrario implica delle limitazioni sul servizio, dunque revoca dell'autorizzazione. 12 di 43

13 L architettura interna della PdD del Centro Servizi CART è analoga a quella delle PdD dei. Nella figura seguente sono evidenziati i principali moduli interni e le loro interazioni. Si noti che il broker JMS è un componente applicativo centrale che si interfaccia con la PdD tramite i moduli di ricezione e consegna dei contenuti applicativi. In figura sono rappresentati anche gli altri eventuali componenti centrali di coordinamento per le applicazioni erogate dal Centro Servizi CART. Il Modulo di Ricezione delle Buste egov si occupa di prendere in carico le buste egov in arrivo dalle altre Porte di Dominio (interne o esterne al CART). Il sistema effettua la validazione di ogni messaggio egov ricevuto (lo standard SPC impone che il destinatario del messaggio non è autorizzato a intraprendere alcuna operazione di trattamento di qualsiasi messaggio ricevuto, prima di aver completato la verifica di formato, sintattica e semantica del messaggio stesso ) e, interagendo con il Server LDAP Centrale depositario delle informazioni sui ruoli e sulle politiche di accesso, verifica che il mittente sia autorizzato a trattarlo. Le richieste ricevute vengono immagazzinate nella coda delle buste egov in arrivo per la successiva gestione da parte del Modulo di Routing. 13 di 43

14 Il Modulo di Routing si occupa di ispezionare la busta egov in transito, al fine di poterla recapitare al destinatario corretto. Gli indirizzi delle porte di dominio destinatarie sono ricavati da una tabella di routing e dal registro UDDI dei Servizi ospitato dal CART. Il Modulo di Inoltro ha il compito di inviare le buste di egov ai destinatari (che possono essere interni o esterni al dominio del CART). Il componente preleva le buste dalla coda Buste Soap in Uscita, assieme alle ulteriori informazioni necessarie alla consegna (come ad esempio il tipo di protocollo da usare e la URL dell Applicativo da utilizzare) ed utilizza queste informazioni per invocare il servizio. Il Modulo di Consegna dei Contenuti Applicativi identifica a quale servizio interno (Porta Applicativa) sia relativa la richiesta egov in arrivo: viene verificata l eventuale presenza di un handler, associato in registrazione alla porta applicativa, ed eventualmente questo viene eseguito, passandogli come parametro i dati XML della richiesta in transito. Nella PdD del Centro Servizi CART, questo modulo entra in gioco ad es. nel caso del servizio di Gestione Eventi, per interagire con il Broker JMS. Infine, la funzione del Modulo di Ricezione dei Contenuti Applicativi è di identificare a quale porta delegata sia relativa la richiesta in arrivo da parte dei componenti applicativi centrali che si interfacciano con la PdD. La figura seguente schematizza il routing delle buste di egov per le varie tipologie di interazione fra soggetti cooperanti. Il ruolo giocato dalle diverse componenti della PdD del Centro Servizi CART nel caso di una interazione SOA è esemplificato nelle figure successive. L interazione EDA è descritta nel paragrafo in cui si descrive il Gestore Eventi. 14 di 43

15 Routing delle comunicazioni da parte della PdD del Centro Servizi CART 15 di 43

16 Interazione SOA fra Interazione SOA con soggetti SPCoop Esterni 16 di 43

17 IL GESTORE EVENTI Il Gestore Eventi è un servizio a valore aggiunto, previsto dalla specifica SPCoop, per permettere lo scambio di buste egov secondo l architettura EDA (Event Driven Architecture), così come specificato nel documento CNIPA Sistema pubblico di cooperazione: STANDARD E TECNOLOGIE, Versione 1.0, sezioni 7.3 e da cui è tratto il seguente schema. In questo modello cooperano domini che pubblicano eventi e domini che sottoscrivono eventi. Gli attori del sistema sono: i domini pubblicanti, quelli sottoscrittori ed il servizio di Gestione degli Eventi (residente nel CRIC). Il sistema permette ai sistemi applicativi sottoscrittori di ricevere le buste inviate da sistemi applicativi pubblicanti secondo il paradigma di interazione P&S (Publish-and-Subscribe). 17 di 43

18 Il Gestore Eventi è un normale servizio SPCoop, ospitato dal soggetto SPC/CentroServiziCART, integrato tramite i classici meccanismi di cooperazione standard delle PdD (http/s). 18 di 43

19 Interazione EDA: invio di una busta egov al Gestore Eventi Interazione EDA: ricezione di una busta egov dal Gestore Eventi 19 di 43

20 IL BROKER JMS Il broker JMS è un componente applicativo centrale preesistente e specifico dell infrastruttura CART che viene utilizzato per supportare un paradigma di interazione fra i di tipo P&S (Publish-and-Subscribe) secondo il quale i sistemi applicativi sottoscrittori di un determinato topic ricevono le buste inviate da sistemi applicativi pubblicatori. Nel caso in cui sia necessaria una maggiore efficienza, si può supportare la comunicazione diretta tra i tramite l'uso dello standard JMS su piattaforma J2EE. Il tal caso, la pubblicazione/sottoscrizione di eventi avviene direttamente sul broker di messaggistica ospitato dal CRIC, come mostrato in figura. Va tuttavia notato che, qualora venga utilizzata questa ottimizzazione, la specifica SPCoop non è più rispettata, infatti questa richiede che: il protocollo di trasporto sia HTTP/s; le buste di egov abbiano l indicazione del soggetto destinatario, cosa possibile in uno scenario di tipo P&S; non i soggetti SPCoop scartino le buste che non siano espressamente indirizzate a loro, requisito anche questo non compatibile con lo scenario P&S Per aggirare questi problemi la PdD OpenSPCoop è stata estesa realizzando uno specifico adattatore che da una parte svolga la funzione di listener, gestendo la sottoscrizione ai topic JMS e la lettura dei messaggi dal broker, dall altra assegni on-thefly il corretto indirizzo di destinazione alle buste di egov prima di consegnarle alla PdD. Broker JMS VPN CART Porta di Dominio CART JMS Adapter Porta di Dominio CART JMS Adapter 20 di 43

21 IL TSB Il Toscana Service Bus è un componente applicativo centrale preesistente e specifico dell infrastruttura CART che viene impiegato per effettuare operazioni di mediazione di messaggi. Nello specifico le funzionalità implementate dal TSB sono: Trasformazione dei messaggi xml in transito tramite fogli di trasformazione XSLT. Invio dei messaggi per conoscenza a soggetti terzi; Trasformazioni dei profili oneway SPCoop in profili più complessi, in modo da poter mappare comunicazioni ad eventi nell ambito del CART in comunicazioni più articolate con il mondo esterno. Saranno supportate le seguenti trasformazioni: o o o Oneway to Sincrono Oneway/Sincrono to Asincrono Asimmetrico Oneway/Sincrono to Asincrono Simmetrico Il TSB è basato su un'istanza di Apache Synapse, un Enterprise Service BUS integrato nel CART, che ospita i proxy che effetteranno l'effettiva gestione del messaggio (trasformazione, invii per conoscenza, etc.). Tali proxy sono descritti tramite un semplice linguaggio xml, utilizzando una ricca libreria di tag (mediatori) disponibile in Apache Synapse. In aggiunta ai mediatori predefiniti, sono definiti dei mediatori a valore aggiunto per il progetto CART che realizzano le funzionalità specifiche previste nel TSB. 21 di 43

22 Come evidenziato in figura, il TSB agisce come un normale servizio applicativo, accessibile come Servizio SPCoop tramite la Porta di Dominio. Naturalmente sarà possibile utilizzare diverse configurazioni (proxy) del TSB per ogni servizio SPCoop, semplicemente configurando la porta applicativa corrispondente al servizio SPCoop per accedere allo specifico proxy del TSB di interesse NICA GATEWAY ICAR Il componente NICA che è stato aggiunto all architettura CART è una vera e propria porta di dominio Regionale con funzionalità di routing delle buste egov, finalizzata a permettere alla Porta di Dominio del Centro Servizi Regionale di agire da router per le comunicazioni tra le Porte di Dominio interne della rete SPCoop regionale e le Porte di Dominio esterne alla rete regionale. Inoltre mette a disposizione le funzionalità di accesso al registro SICA: o o o un web service per la consultazione del Registro SICA Secondario; una serie web service per la sincronizzazione del Registro SICA Secondario con il Registro SICA generale; un web service per la sincronizzazione del Registro SICA Secondario con gli altri registri SICA secondari; Ed è proprio la funzionalità di sincronizzazione fra i vari registri SICA secondari che consente al CART di poter cooperare con le PdD ICAR dispiegate nelle varie regioni. 22 di 43

23 Quindi è possibile consentire ad un fruitore esterno alla regione Toscana, mediante l utilizzo di una PdD ICAR, di invocare un servizio erogato in ambito CART e viceversa, consentire ad un fruitore in ambito CART di fruire di un servizio erogato da un soggetto esterno alla regione Toscana mediante l invocazione della PdD ICAR di tale soggetto erogatore LA PORTA DI DOMINIO DEI Sui è installata una Porta di Dominio compatibile con la specifica SPCoop 1.1 implementata estendendo il prodotto Open Source OpenSPCoop con due importanti componenti specifici per il CART: - un adapter JMS per consentire ai la pubblicazione/sottoscrizione di eventi direttamente sul broker di messaggistica (si veda ). - un emulatore SOLE FCA al fine di consentire il corretto utilizzo anche nel nuovo ambiente dei proxy applicativi già sviluppati, senza bisogno di alcuna modifica del codice. Uno dei compiti più importanti del è quello di realizzare l integrazione con i Servizi Applicativi dell Ente per il quale funge da PdD, sia per i servizi applicativi fruitori di Servizi SPCoop (porta delegata), sia per quelli Erogatori (porta applicativa). Il processo di integrazione viene realizzato attraverso due fasi distinte: 1. registrazione sul delle porte delegate e applicative necessarie per l operatività dell Ente; la registrazione avviene ad opera dei gestori del CART, per mezzo della console di gestione centralizzata del CRIC; 2. aggancio dei servizi applicativi interni al dominio dell Ente alle porte delegate e/o applicative registrate sul ; come vedremo nel seguito questa fase può essere realizzata utilizzando una delle seguenti modalità: uso del proxy trasparente, uso del servizio generico di integrazione, uso di proxy applicativi specifici. Le caratteristiche della PdD OpenSPCoop sono tali che l abilitazione di un nuovo servizio non richiede la programmazione di componenti applicativi ad hoc. La PdD, infatti, mette a disposizione dei servizi generici, utilizzabili da qualunque applicazione, che interagiscono con dei repository XML che descrivono le specifiche porte delegate e applicative per decidere come gestire le richieste in arrivo. In funzione di queste descrizioni e dello stato delle transazioni egov in corso, le richieste ricevute attraversano una pipeline di moduli specifici, arricchendosi di informazioni utili al loro trattamento mantenute negli header dei messaggi, fino ad essere recapitate al destinatario o girate (routing) alla PdD competente. La necessità di utilizzare la busta egovernment per la comunicazione tra i due Server tramite SPCoop pone il problema di come costruire le buste a partire dai dati forniti o attesi dagli applicativi. Infatti, poiché il formato della busta non è parlato nativamente 23 di 43

24 (e non è previsto che lo sia) dalle applicazioni, la PdD deve anche occuparsi di convertire le richieste applicative in formato proprietario nel formato busta egov. Facendo riferimento a questa problematica, i compiti della PdD vengono solitamente divisi in due componenti: il componente di cooperazione e quello di integrazione. Mentre la specifica SPCoop copre completamente gli aspetti relativi al componente di cooperazione, si limita a presentare un esempio di massima di una possibile realizzazione per quanto attiene al componente di integrazione. Per questo motivo, i vari prodotti finora realizzati si differenziano significativamente per quanto attiene alla componente di integrazione. Nel caso del CART, l integrazione dei servizi applicativi interni al dominio dell Ente alle porte delegate e/o applicative registrate sul può essere realizzata utilizzando una delle seguenti modalità: - uso del proxy trasparente, - uso del servizio generico di integrazione, - uso di proxy applicativi specifici. Nel caso in cui i due servizi applicativi (interni ai rispettivi domini) che si intende far comunicare, già condividano tramite opportune descrizioni WSDL, l'uso di interfacce Web Services su HTTP, sarà possibile abilitare la loro comunicazione tramite l uso della modalità di proxy trasparente. In questo caso, le applicazioni non avranno bisogno di alcuna modifica, tranne la URL del servizio da invocare da parte del fruitore, che dovrà essere quella della porta delegata registrata sul anziché quella del servizio reale. Questa soluzione, ha il grande vantaggio di non richiedere l installazione di un proxy (componente di integrazione) per ogni servizio da utilizzare (porta delegata) o da fornire (porta applicativa), assicurando gli stessi livelli di servizio e lasciando immutata l interfaccia d uso del Servizio, in maniera quindi del tutto trasparente rispetto ai Server Applicativi preesistenti. Un altro vantaggio di tale deriva dall evitare che il codice applicativo del proxy venga eseguito direttamente sul server applicativo che funge da PdD, prevenendo così significative controindicazioni dal punto di vista dell affidabilità e della sicurezza di un componente critico dell infrastruttura SPCoop. Non sempre però quella del proxy trasparente è una soluzione praticabile, anche in presenza di applicazioni già pronte (o facilmente adattabili) a dialogare tramite Web Services. Ad esempio per le interazioni asincrone, è necessario che i servizi applicativi scambino con la PdD anche gli identificatori dei messaggi, necessari per correlare correttamente le richieste con le relative risposte asincrone. Per gestire queste situazioni, il espone un apposito servizio di integrazione applicativa, chiamato Integration Manager, realizzato tramite interfacce standard di tipo Web Services su protocollo HTTP. Il servizio espone tutti i metodi necessari per invocare porte delegate e scambiare dati con le porte applicative in maniera sia sincrona che asincrona. Una soluzione di questo tipo ha il vantaggio di semplificare la realizzazione dei proxy, ma richiede che i proxy conoscano i metadati relativi alla comunicazione, 24 di 43

25 come il profilo di collaborazione (sincrono, oneway, asincrono simmetrico, asincrono asimmetrico). Anche basandosi sull uso dei Web Services, sarà quindi ancora necessario realizzare ed installare sulle PdD una coppia di proxy per ogni servizio da raggiungere. Esistono infine alcuni casi in cui nessuna delle due soluzioni viste in precedenza (proxy trasparente e servizio generico di integrazione) risultano sufficienti: qualora i sistemi applicativi usino protocolli di trasporto diversi da HTTP (JMS, FTP, CORBA, etc.); utilizzano un diverso formato dei dati applicativi che si devono scambiare ed è quindi necessaria una preventiva fase di normalizzazione; i due sistemi usino modalità di collaborazione diverse tra loro (oneway, sincrona, asincrona simmetrica o asimmetrica, SOA o EDA). La PdD del CART supporta, come estensione proprietaria, ulteriori modalità di integrazione, come ad esempio la gestione di consegna e di accettazione dei contenuti applicativi su jms. Nei casi più semplici, queste funzionalità possono essere sufficienti a gestire le problematiche che emergono in fase di integrazione. Nei casi più complessi sarà invece necessario realizzare ed installare sui dei componenti di integrazione ad-hoc che si occupino di gestire sulla PdD le trasformazioni necessarie per l effettiva cooperazione, che siano esse di formato dei dati, di protocolli di trasporto, di modalità di collaborazione, o altro. Infatti, come abbiamo visto nell'architettura generale, il è un application server J2EE, che può quindi ospitare applicazioni java complete finalizzate all'offerta di servizi a valore aggiunto e verticalizzati sugli specifici domini applicativi (Protocollo, Anagrafe, Sanità, etc.) agli Enti afferenti al CART. Queste applicazioni (dette proxy applicativi) espongono interfacce applicative ad-hoc verso il dominio interno dell'ente e dialogano con gli altri soggetti tramite i servizi di cooperazione applicativa del CRIC, offerti loro dalla PdD presente sul. L architettura del, che sviluppa il dettaglio del componente di integrazione è mostrata nella figura seguente. 25 di 43

26 LA COMPONENTE DI INTEGRAZIONE DELLA PDD DEI E L EMULATORE SOLE FCA L integrazione dei servizi applicativi interni al dominio dell Ente (SIL) alle porte delegate e/o applicative registrate sul si realizza utilizzando una delle seguenti modalità: uso del proxy trasparente, uso del servizio generico di integrazione, uso di proxy applicativi specifici. Le prime due modalità di integrazione sono supportate dalla cosiddetta componente di integrazione della PdD OpenSPCoop che si interfaccia con i servizi applicativi per mezzo di Web Service (http). 26 di 43

27 Emulatore FCA Porta di Dominio Componente di Integrazione Proxy Applicativi Proxy SunOne Applicativi Proxy Applicativi Proxy Applicativi Proxy Applicativi J2EE Proxy Applicativi SIL SIL SIL La nuova architettura del prevede la presenza di tre application server del tutto separati, il primo finalizzato ad ospitare la Porta di Dominio, il secondo finalizzato ad ospitare i proxy applicativi di nuova generazione dispiegati in ambiente J2EE e il terzo atto ad ospitare i proxy applicativi di vecchia generazione (in questo modo si previene il rischio di compromettere l infrastruttura dal punto di vista dell affidabilità e della sicurezza). L emulatore SOLE FCA è una libreria che viene installata sull application server SunOne al fine di consentire ai proxy applicativi già sviluppati di funzionare anche sulla nuova infrastruttura senza bisogno di alcuna modifica del codice. CART JMS Adapter SunONE Emulatore FCA Proxy Applicativi Porta di Dominio JBoss AS 27 di 43

28 La componente di integrazione della PdD abilita le interazioni tra i servizi applicativi e le porte delegate e applicative delle Porte di Dominio che li ospitano: queste devono avvenire tramite richieste SOAP 1.1 su protocollo http/https. Vediamo sinteticamente quali sono le interfacce esposte dalle Porte di Dominio verso i Servizi Applicativi (maggiori dettagli sono presenti nel documento Linee guida per lo sviluppo dei servizi applicativi in ambiente CARTe ). In generale, come visto precedentemente, le interazioni tra i servizi applicativi e la porta di dominio possono avvenire in due modi: modalità trasparente: prevede che il servizio applicativo utilizzi (in caso di porta delegata) o esponga (in caso di porta applicativa) le interfacce applicative native dei servizi, esattamente come registrate negli accordi di servizio; in tal caso la Porta di Dominio agisce come un proxy trasparente con funzionalità di imbustamento e sbustamento egov dei messaggi applicativi; utilizzando questa modalità, gli applicativi potranno continuare ad operare esattamente come se stessero interagendo direttamente con il servizio applicativo dell'altro Ente; uso del Servizio Integration Manager della PdD: prevede di utilizzare le interfacce di un apposito web service di Integrazione, messo a disposizione dalla Porta di Dominio per la spedizione e/o la ricezione di messaggi applicativi da parte dei servizi applicativi del proprio Dominio di Servizi. Alcune delle informazioni parte dell header SPCoop della busta egov possono essere scambiate tra il SIL e la PdD al momento dell invocazione di una porta delegata o tra la PdD ed il SIL al momento dell invocazione di una porta applicativa. In particolare le informazioni in questione variano in funzione delle specificità degli Accordi di Servizio a cui la busta si riferisce e sono identificate tramite i seguenti attributi: SpCoopID SPCoopTipoMittente SPCoopMittente SPCoopTipoDestinatario SPCoopDestinatario SPCoopTipoServizio SPCoopServizio SPCoopAzione SPCoopRiferimentoMessaggio SPCoopIdCollaborazione SPCoopIDApplicativo SPCoopServizioApplicativo 28 di 43

29 SPCoopServizioApplicativoDestinatario Nel caso di uso dell IntegrationManager, tali informazioni sono accessibili tramite le interfacce apposite esposte dal servizio stesso. Nel caso di uso della modalità trasparente, tali informazioni sono invece accessibili tramite tre diverse modalità: come header del trasporto http: in questo caso i nomi degli header saranno uguali alle informazioni sopra elencate; come proprietà della QUERY_STRING della URL http invocata: in questo caso il nome della proprietà saranno uguali alle informazioni sopra elencate; come informazioni interne all header SOAP etoscana, appositamente definito per l interscambio di tali informazioni nel CART; E' importante evidenziare una funzionalità della PdD associata all'utilizzo dell'attributo SPCoopServizioApplicativoDestinatario : infatti mediante l'utilizzo di questo attributo è possibile istruire la Porta di Dominio CART in modo tale che sia possibile indirizzare un messaggio ad uno specifico SIL di destinazione associato ad un determinato Ente erogatore. Questo meccanismo consente di poter gestire invii di messaggi verso un Ente destinatario al quale sono associati, per quel servizio, più SIL erogatori, selezionando un solo SIL destinatario fra quelli possibili: la PdD consegnerà il messaggio solo al SIL indicato escludendo dalla consegna i restanti SIL. Infatti tramite l'uso dell'header etoscana, il mittente ha la possibilità di impostare, mediante i meccanismi esposti nel seguito, l'attributo SPCoopServizioApplicativoDestinatario, per far si che un determinato messaggio per il quale risulta valorizzato tale attributo, venga consegnato esclusivamente al SIL (se esistente e associato all'ente destinatario) indicato nell'attributo. Se il SIL indicato non figura fra i SIL associati al soggetto erogatore, verrà generato dalla PdD un messaggio di errore CART verso la PdD mittente. In generale se l'attributo non risulta valorizzato, la PdD procede alla consegna a tutti i SIL registrati per quella porta applicativa. 29 di 43

30 3.2. IL SISTEMA DI CONFIGURAZIONE La gestione del CART avviene tramite una console che permette all operatore di configurare tutti i componenti infrastrutturali del CART, sia centrali che periferici, da un unico punto di gestione. Le configurazioni vengono salvate su un database e da lì, tramite un sistema di code, distribuite a tutte le componenti dell infrastruttura (ndr. a tale scopo la control station di OpenSPCoop viene estesa per effettuare la configurazione dei componenti infrastrutturali specifici del CART). Repository Configurazione (RDBMS e LDAP): dati relativi ai Soggetti, ai Servizi, ai, ai SIL, alle Policy di Sicurezza Database configurazione emulatore FCA sul : mapping tra servizi e porte delegate e applicative, credenziali per l'accesso alle porte delegate da parte dell'emulatore Database configurazione Adapter JMS sul : riferimenti ai topic per cui il funge da subscriber Repository UDDI: dati relativi agli Accordi di Servizio e a tutti gli oggetti riferiti dagli Accordi Database configurazione PDD : dati relativi ai Soggetti e ai SIL per cui il funge da Porta di Dominio, Porte Applicative e Porte Delegate per la configurazione della PdD del, credenziali per l'autenticazione dei SIL Mentre i componenti centrali (uddi, ldap, e DBMS) sono indirizzati direttamente tramite API java di gestione, i componenti periferici () sono indirizzati tramite degli appositi Web Services. 30 di 43

31 Gestore Infrastruttura Directory Server Registro SICA secondario Front-End di Configurazione Config SPCoop Demone di Configurazione Componenti SPCoop Broker JMS VPN CART WS di configur azione CART JMS Adapter Porta di Dominio Emulatore FCA 3.3. IL SISTEMA DI GESTIONE DEL CICLO DI VITA DEI SERVIZI CART (SLC) Per la gestione delle richieste di attivazione di servizi in ambito CART è stata sviluppata un applicazione Web, integrata all'interno del portale CART (vedi paragrafo 3.10), il cui scopo è quello di guidare il processo di gestione dei servizi, al fine di garantire il rispetto delle procedure definite dalla Comunità etoscana Compliance e consentire di uniformare il trattamento di tutte le interazioni fra utenti dell'infrastruttura e gestore CART. All'interno del portale CART è stato predisposto un ambiente ad accesso riservato per la gestione delle richieste di fruizione e di erogazione dei servizi e per la gestione del processo di dispiegamento dei proxy applicativi in ambiente CART. L'applicazione consente agli utenti di richiedere le configurazioni dei servizi erogatori e/o fruitori: il gestore CART, in seguito alla ricezione di una richiesta, effettua le configurazioni necessarie e se necessario richiede l approvazione da parte del referente di progetto. Inoltre consente agli utenti associati alla piattaforma OSCAT di effettuare richieste di Verifica di un proxy in ambiente CART di staging: il gestore di OSCAT in seguito alla installazione del proxy effettuata dal gestore CART, effettua le operazioni di verifica del 31 di 43

32 proxy lanciando la test suite e certifica, mediante il sistema SLC, il corretto funzionamento del proxy. Inoltre l'applicazione consente agli Sviluppatore dei Servizi di effettuare richieste di Attivazione del Proxy in ambiente di Staging del CART. Infine consente ai Referenti del progetto in collaborazione con i Referenti di progetto pressi gli Enti, di effettuare richieste di Attivazione del Proxy in ambiente di Produzione del CART. In entrambi i casi possono essere accettate solo richieste di attivazione relativamente a proxy che sono stati precedentemente verificati e certificati. Riepilogando, quindi, le richieste gestite dall'applicazione sono: Richieste di fruizione di servizi CART; Richeste di erogazione di servizi CART; Richieste di deploy di proxy in ambiente CART; Richieste di attivazione di proxy, ovvero di servizi che prevedono l'uso di proxy in ambiente CART. Al termine delle configurazioni il sistema presenta per ogni richiesta la scheda riassuntiva con tutte le informazioni necessarie all utilizzo dell infrastruttura CART IL SISTEMA DI TRACCIAMENTO DEI MESSAGGI E stato realizzato all interno dell infrastruttura CART un sistema di tracciamento dei messaggi consultabile dall amministratore del sistema ed accessibile tramite un opportuna interfaccia web. Mediante tale sistema di tracciamento è possibile eseguire ricerche, secondo opportuni criteri, per identificare uno o più messaggi presi in carico dal sistema ed analizzare il percorso che tali messaggi hanno seguito durante la loro permanenza all interno dell infrastruttura: è possibile effettuare ricerche per singolo IdEgov, nel caso sia noto, oppure mediante impostazione di opportuni campi di ricerca, fra cui il servizio, il soggetto mittente/destinatario, l azione, il servizio applicativo, la data, l ID di correlazione applicativa, ecc. Inoltre, per ogni Porta di Dominio attraversata, è possibile analizzare in dettaglio il log delle operazioni effettuate dalla PdD per gestire l inoltro del messaggio, andando così a scoprire eventuali problemi o anomalie avvenute durante l elaborazione. 32 di 43

33 3.5. IL MONITORAGGIO APPLICATIVO Il monitoraggio applicativo è implementato per mezzo di una serie di Web Service, installati sia sulle componenti centrali (CRIC) che su quelle periferiche () dell intera infrastruttura, che effettuano delle query sulle code delle PdD, per ricavare informazioni sul numero di richieste pendenti ed i relativi tempi di attesa. I Web Service vengono interrogati in modo periodico da NAGIOS, che provvede ad inviare degli allarmi nel caso in cui si superino le soglie prefissate, e possono essere interrogati anche per via diretta da un operatore collegato ad una specifica console di controllo. La comunicazione fra tutte le componenti del sistema di monitoraggio applicativo avviene via http/s. Le funzioni della console di monitoraggio applicativo sono integrate nella stessa applicazione Web che ospita la console di configurazione. Gestore dell Infrastruttura NAGIOS Front-End di monitoraggio applicativo Code PdD WS di monitoraggio applicativo WS di monitoraggio applicativo Porta di Dominio CentroServiziCART CRIC VPN CART WS di monitoraggio applicativo Porta di Dominio Code PdD 3.6. IL SISTEMA DI MONITORAGGIO DEI SERVIZI PMC Il sistema di monitoraggio denominato PMC è un sistema che consente di monitorare servizi in ambito CART attraverso l'utilizzo di proxy applicativi. E' basato sulla raccolta di notifiche generate dai proxy dispiegati presso i e su un sistema di memorizzazione e gestione dati ospitato presso il Centro Servizi CART. 33 di 43

34 E' composto dai seguenti moduli: Un modulo applicativo locale al che espone un web service per la ricezione di notifiche di monitoraggio inviate dai proxy applicativi. Un modulo applicativo locale al che si occupa di inviare le notifiche di monitoraggio al servizio centrale in modalità asincrona. Un modulo applicativo centrale che espone un interfaccia web service per la ricezione e memorizzazione su database di notifiche di monitoraggio. Interfaccia web per le operazioni di reportistica, analisi e definizione di regole basate su RFC, Accordi di Servizio e Servizi per l attivazione di meccanismi di alert che permettono di monitorare il transito dei messaggi applicativi attraverso tutte le componenti interessate. Un motore di validazione delle regole attive e di alert. 34 di 43

35 Gestore dell Infrastruttura Motore di validazione Regole DB PMC Interfaccia Web PMC Definizione Regole PMC Server CRIC VPN CART Porta di Dominio Porta di Dominio WS di monitoraggio PMC Locale Proxy Applicativo WS di monitoraggio PMC Locale Proxy Applicativo SIL Fruitore SIL Erogatore 3.7. IL MONITORAGGIO DI DOMINIO Il monitoraggio di dominio, implementato da un sistema di log compatibile con le specifiche di tracciamento SPCoop, è finalizzato alla raccolta di misure che, opportunamente elaborate, consentiranno di produrre una reportistica su più livelli di astrazione e su diverse forme di aggregazione territoriale, utile per orientare le future strategie di evoluzione dell infrastruttura ed i relativi investimenti. Il CRIC ospita i componenti centrali del sistema di log, che consistono in: - database per contenere i dati relativi al tracciamento; - front-end web (interfaccia utente) per la produzione di report; 35 di 43

36 - front-end web service (interfaccia applicativa) per l'accesso ai dati da parte dei componenti di monitoraggio degli SLA (che non sono parte del progetto), per la verifica degli SLA stipulati negli accordi di servizio. - Il monitoraggio di dominio viene effettuato a livello centrale sulla PdD del Centro Servizi CART in quanto essa consente di tracciare tutte le comunicazioni che avvengono tra le Porte di Dominio dei. Direzione, Amministratori, Capi Progetto Monitoraggio di Dominio Tracce SPCoop 3.8. CARATTERISTICHE DELL ARCHITETTURA L infrastruttura CART ha l ambizione di garantire il soddisfacimento di tutti i requisiti, non solo in termini funzionali, ma anche sotto i profili delle prestazioni, dell affidabilità e ridondanza, della scalabilità al crescere delle esigenze e dell utilizzo. Per questo il CART intervenire a vari livelli: Potenziando la piattaforma hardware, per garantire performance e affidabilità adeguati alle esigenze del progetto; Potenziando l infrastruttura software, prevedendo l uso di una suite di prodotti Open Source, tutti con caratteristiche di eccellenza. Utilizzando un framework di cooperazione applicativa di nuova generazione, OpenSPCoop, progettato da Link.it e Università di Pisa proprio sulla base delle esperienze maturate nel progetto CART. Dal punto di vista generale, l intera soluzione è impostata secondo i principi di modularità, affidabilità, flessibilità e scalabilità. L affidabilità e la sicurezza sono garantite dalla chiara separazione fra le componenti infrastrutturali e quelle applicative. A livello centrale, l adozione di una porta di dominio IntraRegionale permette di assicurare un maggior controllo dal punto di vista della sicurezza e del tracciamento dei messaggi; essa infatti funge da relay per tutti i, avendo così la possibilità, prima di ridirigere il messaggio Egov al destinatario reale, di procedere con la validazione del pacchetto, l autorizzazione, la gestione dei duplicati (affidabilità), la gestione dei riscontri (alla ricezione dei messaggi e alla spedizione della conferma con o senza Piggy Backing), la gestione del 36 di 43

37 tracciamento del messaggio e la gestione delle eccezioni. A livello periferico gli handler associati alle porte delegate sono applicazioni J2EE eseguite in un istanza separata dell Application Server con una policy di sicurezza restrittiva che limita fortemente le possibilità di abusi o anche di danni involontari al sistema (si noti che questo non poteva essere realizzato nella soluzione attuale, dove i proxy applicativi ricevono le connessioni esterne e gestiscono, sia pure tramite la libreria FCA, anche gli accessi al CRIC). La flessibilità è garantita da un architettura aperta in cui le responsabilità e le interfacce di ciascun componente sono chiaramente identificate, e dove, nel rispetto di tali responsabilità ed interfacce, i componenti possono essere sostituiti singolarmente con soluzioni equivalenti in base alle esigenze di gestione e manutenzione evolutiva che nel corso del tempo potranno maturare. La flessibilità è supportata anche a livello dei servizi, grazie dalla possibilità di modificare la configurazione dell infrastruttura, variando i protocolli e le politiche di gestione dei messaggi, senza che ciò abbia un impatto sulle applicazioni rilasciate che continueranno a funzionare in modo del tutto trasparente. Infine, il sistema realizzato è in grado di scalare all aumentare del carico sia in termini di traffico, che di numero di servizi e di soggetti cooperanti. Poiché l architettura della soluzione applicativa è disegnata a 3 livelli (3 tier) la soluzione può scalare orizzontalmente, facendo uso anche di meccanismi e apparecchiature di load balancing, e verticalmente espandendo o comprimendo i livelli architetturali hardware. Si noti infine che il fatto di aver usato soluzioni Open Source per tutti i componenti progettati, da poi la possibilità non solo di poter scalare l infrastruttura a costi estremamente ridotti, ma soprattutto la certezza che le soluzioni adottate evolveranno nel tempo INFRASTRUTTURA DI COOPERAZIONE La piattaforma di cooperazione applicativa descritta in questo documento ha nella flessibilità e nell'affidabilità i suoi punti di forza principali. Questo risultato viene raggiunto disaccoppiando completamente la parte applicativa da quella infrastrutturale, grazie alla completa rivisitazione dei concetti di porta applicativa e delegata, deputati nella specifica SPCoop all'integrazione della Porta di Dominio con gli applicativi interni ai Domini degli Enti. Al contrario dei sistemi di cooperazione applicativa finora realizzati, infatti, le porte delegate e applicative non sono implementate come componenti applicativi ad-hoc (quindi come parte dei proxy applicativi), ma piuttosto come configurazioni della Porta di Dominio e quindi della stessa infrastruttura. Questo comporta importanti vantaggi sia dal punto di vista dell'affidabilità che della flessibilità: 37 di 43

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

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

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

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

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

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

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

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

Release Notes di OpenSPCoop i. Release Notes di OpenSPCoop

Release Notes di OpenSPCoop i. Release Notes di OpenSPCoop i Release Notes di OpenSPCoop ii Copyright 2005-2011 Link.it srl iii Indice 1 Versione 1.4 1 1.1 Adeguamento al nuovo sistema di qualificazione di DigitPA............................. 1 1.2 Nuova modalità

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

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

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

Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni.

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

Visione Generale. Versione 1.0 del 25/08/2009

Visione Generale. Versione 1.0 del 25/08/2009 Visione Generale Versione 1.0 del 25/08/2009 Sommario 1 Premessa... 4 2 Le componenti applicative... 6 2.1 Porta di dominio... 7 2.2 Infrastrutture per la cooperazione... 9 2.2.1 Registro degli Accordi

Dettagli

Architettura e componenti per la cooperazione applicativa nella Pubblica Amministrazione. White Paper Oracle Novembre 2002

Architettura e componenti per la cooperazione applicativa nella Pubblica Amministrazione. White Paper Oracle Novembre 2002 Architettura e componenti per la cooperazione applicativa nella Pubblica Amministrazione White Paper Oracle Novembre 2002 Architettura e componenti Oracle per la cooperazione applicativa nella Pubblica

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

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

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

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

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

Soluzioni Infrastrutturali Open Source per il Sistema Pubblico di Cooperazione Applicativa

Soluzioni Infrastrutturali Open Source per il Sistema Pubblico di Cooperazione Applicativa Soluzioni Infrastrutturali Open Source per il Sistema Pubblico di Cooperazione Applicativa Giansalvatore Mecca Alessandro Pappalardo Salvatore Raunich Il Gruppo di Sviluppo ICAR 1 Dipartimento di Matematica

Dettagli

OpenSPCoop: un Progetto Open Source per la Cooperazione Applicativa nella Pubblica Amministrazione

OpenSPCoop: un Progetto Open Source per la Cooperazione Applicativa nella Pubblica Amministrazione OpenSPCoop: un Progetto Open Source per la Cooperazione Applicativa nella Pubblica Amministrazione Andrea Corradini Dipartimento di Informatica, Pisa andrea@di.unipi.it http://www.di.unipi.it Tito Flagella

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

Consolidamento e sviluppo CART

Consolidamento e sviluppo CART Nome del progetto Consolidamento e sviluppo CART Acronimo del progetto TOSCART Documento Manuale interfaccia monitoraggio Acronimo del documento TOSCART-TEC-INTWEB-PMC Stato del documento Definitivo Versione

Dettagli

INF-1: Specifiche Tecniche di Interfaccia

INF-1: Specifiche Tecniche di Interfaccia INF-1: Specifiche tecniche di Interfaccia INF-1: Specifiche Tecniche di Interfaccia Versione 1.1 Nome doc.: INF-1 Specifiche Interfaccia v1.0.doc Edizione: 1.0 Data emissione: 12/1/2007 INDICE Modifiche

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

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

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

Proposta di un architettura modulare per lo sviluppo della Porta di Dominio SPCoop

Proposta di un architettura modulare per lo sviluppo della Porta di Dominio SPCoop Università degli studi di Roma Tor Vergata Facoltà di Ingegneria Laurea specialistica in Ingegneria Informatica Proposta di un architettura modulare per lo sviluppo della Porta di Dominio SPCoop Relatore:

Dettagli

Interoperabilità e cooperazione applicativa tra sistemi informativi

Interoperabilità e cooperazione applicativa tra sistemi informativi Interoperabilità e cooperazione applicativa tra sistemi informativi Michele Ruta Dipartimento di Ingegneria Elettrica e dell Informazione Politecnico di Bari 1di 29 Indice Introduzione ai Port Community

Dettagli

Progettazione: Tecnologie e ambienti di sviluppo

Progettazione: Tecnologie e ambienti di sviluppo Contratto per l acquisizione di servizi di Assistenza specialistica per la gestione e l evoluzione del patrimonio software della Regione Basilicata. Repertorio n. 11016 del 25/09/2009 Progettazione: Tecnologie

Dettagli

CeBAS. Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009)

CeBAS. Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009) CeBAS Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009) Introduzione Il progetto CEBAS: la finalità è di migliorare l efficienza operativa interna dell Ente rispondere alle aspettative

Dettagli

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace:

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace: Overview tecnica Introduzione E un sistema EAI molto flessibile, semplice ed efficace: Introduce un architettura ESB nella realtà del cliente Si basa su standard aperti Utilizza un qualsiasi Application

Dettagli

La «Community Network dell Umbria» (CN-Umbria)

La «Community Network dell Umbria» (CN-Umbria) La «Community Network dell Umbria» (CN-Umbria) Un opportunità per gli Enti territoriali della Regione Umbria 1 La riforma della Pubblica Amministrazione La trasformazione dei processi della PA: Le riforme

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

Registro SPICCA Architettura del Software

Registro SPICCA Architettura del Software Registro SPICCA Architettura del Software Versione 1.0 del 25/08/2009 Sommario 1 Introduzione... 4 1.1 Scopo... 4 1.2 Obiettivo... 4 1.3 Riferimenti... 4 1.4 Panoramica del documento... 4 2 Rappresentazione

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

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

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

1. Caratteristiche generali

1. Caratteristiche generali Allegato 1 (articolo 1, comma 1) ISTRUZIONI TECNICHE DI CUI AL DECRETO N. 108 DEL 11 MAGGIO 2015 1. Caratteristiche generali Premessa Il nucleo informativo dell AIA è costituito dalla Banca Dati Sinistri

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

Manuale d'uso. e.compliance. Versione 0.5

Manuale d'uso. e.compliance. Versione 0.5 Manuale d'uso e.compliance Versione 0.5 31/12/2007 1 Indice generale Scopo del manuale...5 e.toscana Compliance...6 Introduzione...7 I documenti Request For Comments (RFC) e.toscana...7 Tipologie di RFC...7

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

SPECIFICHE TECNICHE INTEGRAZIONE SERVIZI MUDE

SPECIFICHE TECNICHE INTEGRAZIONE SERVIZI MUDE Pag. 1 di 11 VERIFICHE E APPROVAZIONI VERSIONE REDAZIONE CONTROLLO AUTORIZZAZIONE APPROVAZIONE EMISSIONE NOME DATA NOME DATA NOME DATA V01 Mauro Pavese 17/05/12 Mauro Pavese 29/11/2012 STATO DELLE VARIAZIONI

Dettagli

Guida alla programmazione e integrazione di servizi in OpenSPCoop. Guida alla programmazione e integrazione di servizi in OpenSPCoop

Guida alla programmazione e integrazione di servizi in OpenSPCoop. Guida alla programmazione e integrazione di servizi in OpenSPCoop i Guida alla programmazione e integrazione di servizi in OpenSPCoop ii Copyright 2005-2008 Link.it s.r.l. iii COLLABORATORI TITOLO : Guida alla programmazione e integrazione di servizi in OpenSPCoop AZIONE

Dettagli

Monitoraggio della Rete di Assistenza

Monitoraggio della Rete di Assistenza Studio di fattibilità Allegato al Deliverable A Monitoraggio della Rete di Assistenza Fase 1 Anagrafica ASL Comuni assistibili () ESTRATTO Indice del documento A.20 SCOPO DELL APPLICAZIONE...3 A.20.20

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

Definizione delle interfacce di colloquio fra le componenti

Definizione delle interfacce di colloquio fra le componenti Definizione delle interfacce di colloquio fra le componenti (integrazione documento) 1 DOCUMENTO:. 1.2 Emesso da: EMISSIONE VERIFICA APPROVAZIONE Nome firma Verificato da: Approvato da: Area ISIC LISTA

Dettagli

egovernment Stefano Bucci Un infrastruttura aperta per l integrazione e la cooperazione tra amministrazioni Sales Consultant Manager

egovernment Stefano Bucci Un infrastruttura aperta per l integrazione e la cooperazione tra amministrazioni Sales Consultant Manager egovernment Un infrastruttura aperta per l integrazione e la cooperazione tra amministrazioni Stefano Bucci Sales Consultant Manager Catania, 5 Dicembre 2002 Open e-government Un infrastruttura aperta

Dettagli

Descrizione generale. Architettura del sistema

Descrizione generale. Architettura del sistema Descrizione generale Sister.Net nasce dall esigenza di avere un sistema generale di Cooperazione Applicativa tra Enti nel settore dell Informazione Geografica che consenta la realizzazione progressiva

Dettagli

Standard Tecnologici Regione Basilicata ALLEGATO C03

Standard Tecnologici Regione Basilicata ALLEGATO C03 Standard Tecnologici Regione Basilicata ALLEGATO C03 UFFICIO S. I. R. S. Standard Tecnologici ver. 2.1 ultimo agg.: 06/06/2012 CONTROLLO DEL DOCUMENTO Data APPROVAZIONI Autore Redatto da: 27/05/2012 Dott.

Dettagli

Manuale SDK di OpenSPCoop2 i. Manuale SDK di OpenSPCoop2

Manuale SDK di OpenSPCoop2 i. Manuale SDK di OpenSPCoop2 i Manuale SDK di OpenSPCoop2 ii Copyright 2005-2013 Link.it srl iii Indice 1 Introduzione 1 2 La Personalizzazione del Protocollo di Cooperazione 1 3 Il Software Development Kit 2 3.1 Gestione dei payload.................................................

Dettagli

Titolo Perché scegliere Alfresco. Titolo1 ECM Alfresco

Titolo Perché scegliere Alfresco. Titolo1 ECM Alfresco Titolo Perché scegliere Alfresco Titolo1 ECM Alfresco 1 «1» Agenda Presentazione ECM Alfresco; Gli Strumenti di Alfresco; Le funzionalità messe a disposizione; Le caratteristiche Tecniche. 2 «2» ECM Alfresco

Dettagli

Manuale d'uso. Sistema di gestione delle richieste di configurazione dei servizi CART. Versione 1.4

Manuale d'uso. Sistema di gestione delle richieste di configurazione dei servizi CART. Versione 1.4 Manuale d'uso Sistema di gestione delle richieste di configurazione dei servizi CART Versione 1.4 21/05/2013 1 Scopo del manuale... 3 2 Il Sistema di gestione delle richieste...4 2.1 Sottoscrizione utenti...6

Dettagli

Guida alla configurazione freesbee-sla e freesbweb-sla

Guida alla configurazione freesbee-sla e freesbweb-sla Guida alla configurazione freesbee-sla e freesbweb-sla freesbee SLA freesbweb SLA Pagina 1 di 23 Sommario Guida alla configurazione freesbee-sla e freesbweb-sla... 1 Introduzione... 4 Installazione...

Dettagli

Concetti base. Impianti Informatici. Web application

Concetti base. Impianti Informatici. Web application Concetti base Web application La diffusione del World Wide Web 2 Supporto ai ricercatori Organizzazione documentazione Condivisione informazioni Scambio di informazioni di qualsiasi natura Chat Forum Intranet

Dettagli

Applicazione: OIL Online Interactive helpdesk

Applicazione: OIL Online Interactive helpdesk Riusabilità del software - Catalogo delle applicazioni: Gestione ICT Applicazione: OIL Online Interactive helpdesk Amministrazione: Consiglio Nazionale delle Ricerche (CNR) Responsabile dei sistemi informativi

Dettagli

NAL DI STAGING. Versione 1.0

NAL DI STAGING. Versione 1.0 NAL DI STAGING Versione 1.0 14/10/2008 Indice dei Contenuti 1. Introduzione... 3 2. Installazione NAL di staging... 3 VMWare Server... 3 Preistallazione su server linux... 6 Preinstallazione su server

Dettagli

Guida alla programmazione e integrazione di servizi in OpenSPCoop. Guida alla programmazione e integrazione di servizi in OpenSPCoop

Guida alla programmazione e integrazione di servizi in OpenSPCoop. Guida alla programmazione e integrazione di servizi in OpenSPCoop i Guida alla programmazione e integrazione di servizi in OpenSPCoop ii Copyright 2005-2011 Link.it s.r.l. iii Indice 1 Introduzione 1 2 Modalità d integrazione trasparente 1 3 Modalità d integrazione tramite

Dettagli

RRF Reply Reporting Framework

RRF Reply Reporting Framework RRF Reply Reporting Framework Introduzione L incremento dei servizi erogati nel campo delle telecomunicazioni implica la necessità di effettuare analisi short-term e long-term finalizzate a tenere sotto

Dettagli

Integrazione di Sistemi Informativi Sanitari attraverso l uso di Middleware Web Services

Integrazione di Sistemi Informativi Sanitari attraverso l uso di Middleware Web Services Consiglio Nazionale delle Ricerche Istituto di Calcolo e Reti ad Alte Prestazioni Integrazione di Sistemi Informativi Sanitari attraverso l uso di Middleware Web Services I. Marra M. Ciampi RT-ICAR-NA-06-04

Dettagli

SCHEDA TECNICA. Caratteristiche generali di prodotto. Denominazione S.A.T.T.- Sant Arpino Tributi e Territorio. Amministrazione Comune di Sant Arpino

SCHEDA TECNICA. Caratteristiche generali di prodotto. Denominazione S.A.T.T.- Sant Arpino Tributi e Territorio. Amministrazione Comune di Sant Arpino SCHEDA TECNICA Denominazione S.A.T.T.- Sant Arpino Tributi e Territorio Amministrazione Comune di Sant Arpino Note e considerazioni sul riuso Il Sistema proposto viene reso disponibile in open source per

Dettagli

CONVENZIONI DI NOMENCLATURA E SEMANTICA

CONVENZIONI DI NOMENCLATURA E SEMANTICA Sistema pubblico di cooperazione: CONVENZIONI DI NOMENCLATURA E SEMANTICA Versione 1.1 INDICE 1. MODIFICHE DOCUMENTO...3 2. OBIETTIVI E CONTESTO DI RIFERIMENTO... 4 2.1. Scopi del documento... 5 2.2. Note

Dettagli

Accordo di servizio. Uno stralcio di Accordo di Servizio ad evidenziare l utilizzo di XML:

Accordo di servizio. Uno stralcio di Accordo di Servizio ad evidenziare l utilizzo di XML: Accordo di servizio Insieme delle definizioni, delle funzionalità, delle interfacce, dei requisiti di sicurezza e di qualità di uno o più servizi applicativi che vengono scambiati tra due amministrazioni

Dettagli

l identità digitale federata nel progetto ICAR

l identità digitale federata nel progetto ICAR l identità digitale federata nel progetto ICAR Francesco Meschia Roma, 16 febbraio 2006 agenda generalità sul progetto ICAR e sul task INF-3 situazione e problemi dell identità digitale in Italia l approccio

Dettagli

Servizi di hosting offerti dall'area Servizi ICT Integrazione con l'anagrafica Unica di Ateneo. Area Servizi ICT

Servizi di hosting offerti dall'area Servizi ICT Integrazione con l'anagrafica Unica di Ateneo. Area Servizi ICT Area Servizi ICT Servizi hosting di Ateneo - Integrazione con l'anagrafica Unica di Ateneo Versione 1.1 http://hosting.polimi.it Servizi di hosting offerti dall'area Servizi ICT Integrazione con l'anagrafica

Dettagli

Eclipse Day 2010 in Rome

Eclipse Day 2010 in Rome Le infrastrutture open source per la cooperazione applicativa nella pubblica amministrazione: l'esperienza in Regione del Veneto Dirigente del Servizio Progettazione e Sviluppo Direzione Sistema Informatico

Dettagli

MINISTERO DEL LAVORO E DELLE POLITICHE SOCIALI

MINISTERO DEL LAVORO E DELLE POLITICHE SOCIALI MINISTERO DEL LAVORO E DELLE POLITICHE SOCIALI DECRETO 13 ottobre 2004 «Borsa nazionale continua del lavoro», di cui agli articoli 15 e 16 del decreto legislativo 10 settembre 2003, n. 276, di attuazione

Dettagli

IL MINISTRO DEL LAVORO E DELLE POLITICHE SOCIALI di concerto con IL MINISTRO PER L'INNOVAZIONE E LE TECNOLOGIE

IL MINISTRO DEL LAVORO E DELLE POLITICHE SOCIALI di concerto con IL MINISTRO PER L'INNOVAZIONE E LE TECNOLOGIE DECRETO 13 ottobre 2004: «Borsa nazionale continua del lavoro», di cui agli articoli 15 e 16 del decreto legislativo 10 settembre 2003, n. 276, di attuazione della legge 14 febbraio 2003, n. 30. IL MINISTRO

Dettagli

Release Notes di OpenSPCoop2. Release Notes di OpenSPCoop2

Release Notes di OpenSPCoop2. Release Notes di OpenSPCoop2 i Release Notes di OpenSPCoop2 ii Copyright 2005-2014 Link.it srl iii Indice 1 Novità di OpenSPCoop-v2 rispetto ad OpenSPCoop 1 1.1 Protocollo di Cooperazione personalizzabile tramite plugin.............................

Dettagli

più del mercato applicazioni dei processi modificato. Reply www.reply.eu

più del mercato applicazioni dei processi modificato. Reply www.reply.eu SOA IN AMBITO TELCO Al fine di ottimizzare i costi e di migliorare la gestione dell'it, le aziende guardano, sempre più con maggiore interesse, alle problematiche di gestionee ed ottimizzazione dei processi

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

La Fatturazione Elettronica con la PdD OpenSPCoop

La Fatturazione Elettronica con la PdD OpenSPCoop La Fatturazione Elettronica con la PdD OpenSPCoop del Proxy FatturaPA Link.it v1.0 del 7/11/2014 Indice 1 Premessa...3 2 Il contesto di riferimento...3 3 La Fatturazione Passiva...5 3.1 Scenari di utilizzo...6

Dettagli

OGGETTO: Adesione al progetto ANA-CNER Sistema interoperabile di accesso ai dati della popolazione residente dell Emilia Romagna

OGGETTO: Adesione al progetto ANA-CNER Sistema interoperabile di accesso ai dati della popolazione residente dell Emilia Romagna COMUNE DI OGGETTO: Adesione al progetto ANA-CNER Sistema interoperabile di accesso ai dati della popolazione residente dell Emilia Romagna PROPOSTA DI DELIBERAZIONE PER LA GIUNTA MUNICIPALE LA GIUNTA MUNICIPALE

Dettagli

Una soluzione per il Provisioning e la Software Distribution

Una soluzione per il Provisioning e la Software Distribution Una soluzione per il Provisioning e la Software Distribution Scenario Svariati server, con funzione in base all'area di competenza, dislocati nel territorio su Nodi Periferici collegati in rete (VPN) Un

Dettagli

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013 e di e di Candidato: Luca Russo Docente: Corso di laurea in Informatica Applicata Facoltá di Scienze e Tecnologie Programmazione su Reti 27 Marzo 2013 Traccia d esame Sviluppare multitier con disaccoppiamento

Dettagli

BLU CRM Srl - Via Piave, 26 20016 Pero (MI) Blu.Energy Suite Sistema Distribuzione Gas

BLU CRM Srl - Via Piave, 26 20016 Pero (MI) Blu.Energy Suite Sistema Distribuzione Gas Blu.Energy Suite Sistema Distribuzione Gas Suite distribuzione Gas Sistema informativo per la gestione di attività inerenti alla gestione del servizio di distribuzione del Gas Letture Contatori Contratti

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

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

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 SISTEMA FEDERATO DI AUTENTICAZIONE Informatizzazione dell iter procedurale e dei controlli relativi

Dettagli

La cooperazione applicativa nei sistemi distribuiti della Pubblica Amministrazione italiana. Il caso del SIL.

La cooperazione applicativa nei sistemi distribuiti della Pubblica Amministrazione italiana. Il caso del SIL. La cooperazione applicativa nei sistemi distribuiti della Pubblica Amministrazione italiana. Il caso del SIL. Gianluigi Raiss Giancarlo Palma Seminario Labsita - Roma 27 febbraio 2004 Indice Sistemi distribuiti

Dettagli

Il Provvedimento del Garante

Il Provvedimento del Garante Il Provvedimento del Garante Il provvedimento del Garante per la Protezione dei dati personali relativo agli Amministratori di Sistema (AdS) Misure e accorgimenti prescritti ai titolari dei trattamenti

Dettagli

Costruire il futuro il valore delle scelte tecnologiche

Costruire il futuro il valore delle scelte tecnologiche Franco Lenzi Costruire il futuro il valore delle scelte tecnologiche 7 e 8 maggio 2010, Venezia, Hotel Hilton Molino Stucky 1 La strategia tecnologica Gli obiettivi espressi dalle scelta di strategia e

Dettagli

Single Sign On sul web

Single Sign On sul web Single Sign On sul web Abstract Un Sigle Sign On (SSO) è un sistema di autenticazione centralizzata che consente a un utente di fornire le proprie credenziali una sola volta e di accedere a molteplici

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

SERVIZI DI REGISTRO. Sistema pubblico di cooperazione: Versione 1.1

SERVIZI DI REGISTRO. Sistema pubblico di cooperazione: Versione 1.1 Sistema pubblico di cooperazione: SERVIZI DI REGISTRO Versione. INDICE. MODIFICHE DOCUMENTO...3 2. OBIETTIVI E CONTESTO DI RIFERIMENTO... 4 2.. Scopo del documento... 5 2.2. Note di lettura del documento...

Dettagli

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Riusabilità del software - Catalogo delle applicazioni: Applicativo verticale Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Amministrazione: Regione Piemonte - Direzione Innovazione,

Dettagli

JSIS JSIS L architettura JSIS

JSIS JSIS L architettura JSIS JSIS JSIS L architettura JSIS La piattaforma JSIS Java Solution Integrated Suites, interamente realizzata dai nostri laboratori di sviluppo software, è una soluzione che integra la gestione di diverse

Dettagli

La sicurezza nel Sistema Pubblico di Connettività Prima parte

La sicurezza nel Sistema Pubblico di Connettività Prima parte La sicurezza nel Sistema Pubblico di Connettività Prima parte Ing. Gianfranco Pontevolpe Responsabile Ufficio Tecnologie per la sicurezza Centro Nazionale per l Informatica nella Pubblica Amministrazione

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

IL MINISTRO DEL LAVORO E DELLE POLITICHE SOCIALI di concerto con IL MINISTRO PER L'INNOVAZIONE E LE TECNOLOGIE

IL MINISTRO DEL LAVORO E DELLE POLITICHE SOCIALI di concerto con IL MINISTRO PER L'INNOVAZIONE E LE TECNOLOGIE Borsa nazionale continua del lavoro: approvate le norme attuative Decreto Ministero Welfare 13.10.2004, G.U. 08.11.2004 Definiti gli standard tecnici e dei flussi informativi di scambio tra i sistemi,

Dettagli

REGIONE BASILICATA UFFICIO S. I. R. Standard Tecnologici dei Sistemi Informativi

REGIONE BASILICATA UFFICIO S. I. R. Standard Tecnologici dei Sistemi Informativi UFFICIO S. I. R. Standard Tecnologici dei Sistemi Informativi Autori: Dott.ssa Domenica Nardelli (P.O.C. Area Applicativa Ufficio SIR) Data di creazione: 03 Ottobre 2005 Ultimo aggiornamento: 03 Ottobre

Dettagli

:: RNDT. repertorio nazionale dei dati territoriali. 22 maggio 2007 FORUM PA 2007 1

:: RNDT. repertorio nazionale dei dati territoriali. 22 maggio 2007 FORUM PA 2007 1 :: RNDT repertorio nazionale dei dati territoriali 22 maggio 2007 FORUM PA 2007 1 I dati territoriali della Pubblica Amministrazione 22 maggio 2007 FORUM PA 2007 2 Codice dell Amministrazione Digitale

Dettagli

@CCEDO: Accessibilità, Sicurezza, Architettura

@CCEDO: Accessibilità, Sicurezza, Architettura Rev. 8, agg. Settembre 2014 @CCEDO: Accessibilità, Sicurezza, Architettura 1.1 Il Sistema di Gestione della Sicurezza Per quanto riguarda la gestione della Sicurezza, @ccedo è dotato di un sistema di autenticazione

Dettagli

Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1)

Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1) Pagina 1 di 10 Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1) Nel corso della lezione precedente abbiamo analizzato le caratteristiche dell'architettura CGI.

Dettagli

Cluster per architetture a componenti

Cluster per architetture a componenti Luca Cabibbo Architetture Software Cluster per architetture a componenti Dispensa ASW 442 ottobre 2014 Un buon progetto produce benefici in più aree. Trudy Benjamin 1 -Fonti [IBM] Clustering Solutions

Dettagli

Applicazione: GAS - Gestione AcceSsi

Applicazione: GAS - Gestione AcceSsi Riusabilità del software - Catalogo delle applicazioni Gestione ICT Applicazione: GAS - Gestione AcceSsi Amministrazione: Consiglio Nazionale delle Ricerche (CNR) Responsabile dei sistemi informativi Nome

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

MANUALE Freight Taxi

MANUALE Freight Taxi MANUALE Freight Taxi UIRNet_USG_FT_REV_B Codice Revisione Data UEJ4DDS10007_LJ4A686DDS11 1 21-02-2013 UIRNet S.p.A. Via F. Crispi 115, 00187 - Roma (IT) contactcenter@uirnet.it www.uirnet.it INDICE 1 Introduzione...

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