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 ( 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

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

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

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

Scenari di Deployment i. Scenari di Deployment

Scenari di Deployment i. Scenari di Deployment i Scenari di Deployment ii Copyright 2005-2011 Link.it srl iii Indice 1 Introduzione 1 2 La configurazione minima 1 3 La gestione totalmente centralizzata 3 4 Porte di Dominio Locali con Registro Centrale

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

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

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

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

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

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

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

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

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

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

MANUALE DI UTILIZZO: INTRANET PROVINCIA DI POTENZA

MANUALE DI UTILIZZO: INTRANET PROVINCIA DI POTENZA MANUALE DI UTILIZZO: INTRANET PROVINCIA DI POTENZA Fornitore: Publisys Prodotto: Intranet Provincia di Potenza http://www.provincia.potenza.it/intranet Indice 1. Introduzione... 3 2. I servizi dell Intranet...

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

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

Firewall applicativo per la protezione di portali intranet/extranet

Firewall applicativo per la protezione di portali intranet/extranet Firewall applicativo per la protezione di portali intranet/extranet Descrizione Soluzione Milano Hacking Team S.r.l. http://www.hackingteam.it Via della Moscova, 13 info@hackingteam.it 20121 MILANO (MI)

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

Prodotto <ADAM DASHBOARD> Release <1.0> Gennaio 2015

Prodotto <ADAM DASHBOARD> Release <1.0> Gennaio 2015 Prodotto Release Gennaio 2015 Il presente documento e' stato redatto in coerenza con il Codice Etico e i Principi Generali del Controllo Interno Sommario Sommario... 2 Introduzione...

Dettagli

Versione 1. (marzo 2010)

Versione 1. (marzo 2010) ST 763-27 - Soluzione tecnica di interconnessione per i servizi SMS e MMS a sovrapprezzo Allegato 1 - Linee guida per l interfaccia di accesso tra operatore telefonico ed il CSP Versione 1 (marzo 2010)

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

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

Progettaz. e sviluppo Data Base

Progettaz. e sviluppo Data Base Progettaz. e sviluppo Data Base! Progettazione Basi Dati: Metodologie e modelli!modello Entita -Relazione Progettazione Base Dati Introduzione alla Progettazione: Il ciclo di vita di un Sist. Informativo

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

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

Reti di Telecomunicazione Lezione 8

Reti di Telecomunicazione Lezione 8 Reti di Telecomunicazione Lezione 8 Marco Benini Corso di Laurea in Informatica marco.benini@uninsubria.it Livello di trasporto Programma della lezione relazione tra lo strato di trasporto e lo strato

Dettagli

La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati

La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati Affidabilità nel servizio precisione negli strumenti Chanda LPR Chanda LPR è una piattaforma

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

Specifiche Tecnico-Funzionali

Specifiche Tecnico-Funzionali AuthSIAR - Modulo di Autenticazione e Autorizzazione Sardegna IT S.r.l. Analisi Tecnico-Funzionale Assessorato all Agricoltura della Regione Sardegna SIAR Sistema Informativo Agricolo Regionale AuthSIAR

Dettagli

Le comunicazioni telematiche in Toscana

Le comunicazioni telematiche in Toscana Le comunicazioni telematiche in Toscana Stampa Centro stampa Giunta Regione Toscana I N D I C E Le comunicazioni telematiche I canali di comunicazioni InterPRO e le Amministrazioni Pubbliche Come attivare

Dettagli

E.S.B. Enterprise Service Bus ALLEGATO C11

E.S.B. Enterprise Service Bus ALLEGATO C11 E.S.B. Enterprise Service Bus ALLEGATO C11 REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA REGIONALE UFFICIO SISTEMA INFORMATIVO REGIONALE E STATISTICA Via V. Verrastro, n. 4 85100 Potenza tel

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

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

SUAP. Per gli operatori SUAP/amministratori. Per il richiedente

SUAP. Per gli operatori SUAP/amministratori. Per il richiedente Procedura guidata per l inserimento della domanda Consultazione diretta, da parte dell utente, dello stato delle sue richieste Ricezione PEC, protocollazione automatica in entrata e avviamento del procedimento

Dettagli

Organizzazione degli archivi

Organizzazione degli archivi COSA E UN DATA-BASE (DB)? è l insieme di dati relativo ad un sistema informativo COSA CARATTERIZZA UN DB? la struttura dei dati le relazioni fra i dati I REQUISITI DI UN DB SONO: la ridondanza minima i

Dettagli

Sistemi informativi secondo prospettive combinate

Sistemi informativi secondo prospettive combinate Sistemi informativi secondo prospettive combinate direz acquisti direz produz. direz vendite processo acquisti produzione vendite INTEGRAZIONE TRA PROSPETTIVE Informazioni e attività sono condivise da

Dettagli

lem logic enterprise manager

lem logic enterprise manager logic enterprise manager lem lem Logic Enterprise Manager Grazie all esperienza decennale in sistemi gestionali, Logic offre una soluzione modulare altamente configurabile pensata per la gestione delle

Dettagli

SOFTWARE A SUPPORTO DELLA GESTIONE AMMINISTRATIVA DELLO SPORTELLO UNICO SPECIFICA DEI REQUISITI UTENTE

SOFTWARE A SUPPORTO DELLA GESTIONE AMMINISTRATIVA DELLO SPORTELLO UNICO SPECIFICA DEI REQUISITI UTENTE Pag. 1 di 16 SOFTWARE A SUPPORTO DELLA (VERS. 3.1) Specifica dei Requisiti Utente Funzionalità di associazione di più Richiedenti ad un procedimento Codice Identificativo VERIFICHE ED APPROVAZIONI CONTROLLO

Dettagli

Dematerializzare per Semplificare

Dematerializzare per Semplificare 1 Dematerializzare per Semplificare Dematerializzare non significa solamente il passaggio dalla carta al digitale. La semplificazione si ottiene solo con una profonda comprensione della complessità dei

Dettagli

3. Introduzione all'internetworking

3. Introduzione all'internetworking 3. Introduzione all'internetworking Abbiamo visto i dettagli di due reti di comunicazione: ma ce ne sono decine di tipo diverso! Occorre poter far comunicare calcolatori che si trovano su reti di tecnologia

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

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

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 Amministratore Legalmail Enterprise. Manuale ad uso degli Amministratori del Servizio Legalmail Enterprise

Manuale Amministratore Legalmail Enterprise. Manuale ad uso degli Amministratori del Servizio Legalmail Enterprise Manuale Amministratore Legalmail Enterprise Manuale ad uso degli Amministratori del Servizio Legalmail Enterprise Pagina 2 di 16 Manuale Amministratore Legalmail Enterprise Introduzione a Legalmail Enterprise...3

Dettagli

Software Servizi Web UOGA

Software Servizi Web UOGA Manuale Operativo Utente Software Servizi Web UOGA S.p.A. Informatica e Servizi Interbancari Sammarinesi Strada Caiese, 3 47891 Dogana Tel. 0549 979611 Fax 0549 979699 e-mail: info@isis.sm Identificatore

Dettagli

Università Politecnica delle Marche. Progetto Didattico

Università Politecnica delle Marche. Progetto Didattico Università Politecnica delle Marche Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica e dell Automazione Sede di Ancona Anno Accademico 2011-2012 Corso di Tecnologie WEB Docente prof. Alessandro

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

Finalità della soluzione... 3. Schema generale e modalità d integrazione... 4. Gestione centralizzata in TeamPortal... 6

Finalità della soluzione... 3. Schema generale e modalità d integrazione... 4. Gestione centralizzata in TeamPortal... 6 Finalità della soluzione... 3 Schema generale e modalità d integrazione... 4 Gestione centralizzata in TeamPortal... 6 Dati gestiti dall Anagrafica Unica... 8 Gestione anagrafica... 9 Storicizzazione...

Dettagli

Gestione in qualità degli strumenti di misura

Gestione in qualità degli strumenti di misura Gestione in qualità degli strumenti di misura Problematiche Aziendali La piattaforma e-calibratione Il servizio e-calibratione e-calibration in action Domande & Risposte Problematiche Aziendali incertezza

Dettagli

Sistemi Informativi e Sistemi ERP

Sistemi Informativi e Sistemi ERP Sistemi Informativi e Sistemi Trasformare i dati in conoscenza per supportare le decisioni CAPODAGLIO E ASSOCIATI 1 I SISTEMI INFORMATIVI LI - E IMPRESA SISTEMA DI OPERAZIONI ECONOMICHE SVOLTE DA UN DATO

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

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

Nuovi Flussi Informativi Cooperazione Applicativa Youth Guarantee

Nuovi Flussi Informativi Cooperazione Applicativa Youth Guarantee Nuovi Flussi Informativi Cooperazione Applicativa Youth Guarantee Sommario 1 Introduzione... 2 2 Garanzia Giovani... 2 3 La Cooperazione Applicativa... 2 3.1 Presa in carico del cittadino... 3 3.1.1 Adesione

Dettagli

ALICE AMMINISTRAZIONE UTENTI WEB

ALICE AMMINISTRAZIONE UTENTI WEB AMMINISTRAZIONE UTENTI WEB REL. 1.2 edizione luglio 2008 INDICE 1. AMMINISTRAZIONE DI UTENTI E PROFILI... 2 2. DEFINIZIONE UTENTI... 2 2.1. Definizione Utenti interna all applicativo... 2 2.1.1. Creazione

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

Lezione 1. Introduzione e Modellazione Concettuale

Lezione 1. Introduzione e Modellazione Concettuale Lezione 1 Introduzione e Modellazione Concettuale 1 Tipi di Database ed Applicazioni Database Numerici e Testuali Database Multimediali Geographic Information Systems (GIS) Data Warehouses Real-time and

Dettagli

Introduzione alle basi di dati. Gestione delle informazioni. Gestione delle informazioni. Sistema informatico

Introduzione alle basi di dati. Gestione delle informazioni. Gestione delle informazioni. Sistema informatico Introduzione alle basi di dati Introduzione alle basi di dati Gestione delle informazioni Base di dati Modello dei dati Indipendenza dei dati Accesso ai dati Vantaggi e svantaggi dei DBMS Gestione delle

Dettagli

LOG VIEWER. Versione 1.0

LOG VIEWER. Versione 1.0 LOG VIEWER Versione 1.0 25/09/2008 Indice dei Contenuti 1. Scopo del documento... 3 2. Introduzione... 3 3. Tracking... 5 4. Search... 7 1. Scopo del documento Il presente manuale descrive il servizio

Dettagli

CORSO ACCESS PARTE II. Esistono diversi tipi di aiuto forniti con Access, generalmente accessibili tramite la barra dei menu (?)

CORSO ACCESS PARTE II. Esistono diversi tipi di aiuto forniti con Access, generalmente accessibili tramite la barra dei menu (?) Ambiente Access La Guida di Access Esistono diversi tipi di aiuto forniti con Access, generalmente accessibili tramite la barra dei menu (?) Guida in linea Guida rapida Assistente di Office indicazioni

Dettagli

Fattura elettronica e conservazione

Fattura elettronica e conservazione Fattura elettronica e conservazione Maria Pia Giovannini Responsabile Area Regole, standard e guide tecniche Agenzia per l Italia Digitale Torino, 22 novembre 2013 1 Il contesto di riferimento Agenda digitale

Dettagli

SOMMARIO... 3 INTRODUZIONE...

SOMMARIO... 3 INTRODUZIONE... Sommario SOMMARIO... 3 INTRODUZIONE... 4 INTRODUZIONE ALLE FUNZIONALITÀ DEL PROGRAMMA INTRAWEB... 4 STRUTTURA DEL MANUALE... 4 INSTALLAZIONE INRAWEB VER. 11.0.0.0... 5 1 GESTIONE INTRAWEB VER 11.0.0.0...

Dettagli

Il modello veneto di Bilancio Sociale Avis

Il modello veneto di Bilancio Sociale Avis Il modello veneto di Bilancio Sociale Avis Le organizzazioni di volontariato ritengono essenziale la legalità e la trasparenza in tutta la loro attività e particolarmente nella raccolta e nell uso corretto

Dettagli

Introduzione Ai Data Bases. Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni

Introduzione Ai Data Bases. Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni Introduzione Ai Data Bases Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni I Limiti Degli Archivi E Il Loro Superamento Le tecniche di gestione delle basi di dati nascono

Dettagli

1.2.1 - REALIZZAZIONE LAN

1.2.1 - REALIZZAZIONE LAN 1 - CODICE PROGETTO 1.2.1 - REALIZZAZIONE LAN 2 - TIPOLOGIA DI INTERVENTO/AREA FUNZIONALE DEL PPL Il progetto è riconducibile a quella che il Piano Provinciale del Lavoro definisce quale Area 1: organizzazione

Dettagli

La Posta Certificata per la trasmissione dei documenti informatici. renzo ullucci

La Posta Certificata per la trasmissione dei documenti informatici. renzo ullucci La Posta Certificata per la trasmissione dei documenti informatici renzo ullucci Contesto Il completamento dell apparato normativo e la concreta implementazione delle nuove tecnologie rendono più reale

Dettagli

Piattaforma per la realizzazione e distribuzione di corsi formativi in modalità e-learning

Piattaforma per la realizzazione e distribuzione di corsi formativi in modalità e-learning Piattaforma per la realizzazione e distribuzione di corsi formativi in modalità e-learning CNA FORMERETE COSA È L E-LEARNING è l'insieme delle attività didattiche svolte all'interno di un progetto educativo

Dettagli

Protocollo Informatico (D.p.r. 445/2000)

Protocollo Informatico (D.p.r. 445/2000) Protocollo Informatico (D.p.r. 445/2000) Ricerca veloce degli atti, archiviazione, fascicolazione ed inventario Inserimento semplice e funzionale Collegamento tra protocolli tramite la gestione dei fascicoli

Dettagli

MANUALE DELLA QUALITA Revisione: Sezione 4 SISTEMA DI GESTIONE PER LA QUALITA

MANUALE DELLA QUALITA Revisione: Sezione 4 SISTEMA DI GESTIONE PER LA QUALITA Pagina: 1 di 5 SISTEMA DI GESTIONE PER LA QUALITA 4.0 SCOPO DELLA SEZIONE Illustrare la struttura del Sistema di Gestione Qualità SGQ dell Istituto. Per gli aspetti di dettaglio, la Procedura di riferimento

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

MetaMAG METAMAG 1 IL PRODOTTO

MetaMAG METAMAG 1 IL PRODOTTO METAMAG 1 IL PRODOTTO Metamag è un prodotto che permette l acquisizione, l importazione, l analisi e la catalogazione di oggetti digitali per materiale documentale (quali immagini oppure file di testo

Dettagli

IL SERVIZIO DI POSTA ELETTRONICA

IL SERVIZIO DI POSTA ELETTRONICA IL SERVIZIO DI POSTA ELETTRONICA Premessa Il servizio di posta elettronica della RUN, entrato in esercizio nel novembre del 1999, si è, in questi anni, notevolmente incrementato a causa di: aumento nell

Dettagli

Creare una Rete Locale Lezione n. 1

Creare una Rete Locale Lezione n. 1 Le Reti Locali Introduzione Le Reti Locali indicate anche come LAN (Local Area Network), sono il punto d appoggio su cui si fonda la collaborazione nel lavoro in qualunque realtà, sia essa un azienda,

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

Dematerializzare per Semplificare

Dematerializzare per Semplificare 1 Dematerializzare per Semplificare Dematerializzare non significa solamente il passaggio dalla carta al digitale. La semplificazione si ottiene solo con una profonda comprensione della complessità dei

Dettagli

PROXYMA Contrà San Silvestro, 14 36100 Vicenza Tel. 0444 544522 Fax 0444 234400 Email: proxyma@proxyma.it

PROXYMA Contrà San Silvestro, 14 36100 Vicenza Tel. 0444 544522 Fax 0444 234400 Email: proxyma@proxyma.it PROXYMA Contrà San Silvestro, 14 36100 Vicenza Tel. 0444 544522 Fax 0444 234400 Email: proxyma@proxyma.it igrafx Process Central è una soluzione che aiuta le organizzazioni a gestire, sviluppare, documentare

Dettagli

5.1.1 Politica per la sicurezza delle informazioni

5.1.1 Politica per la sicurezza delle informazioni Norma di riferimento: ISO/IEC 27001:2014 5.1.1 Politica per la sicurezza delle informazioni pag. 1 di 5 Motivazione Real Comm è una società che opera nel campo dell Information and Communication Technology.

Dettagli

IT Cloud Service. Semplice - accessibile - sicuro - economico

IT Cloud Service. Semplice - accessibile - sicuro - economico IT Cloud Service Semplice - accessibile - sicuro - economico IT Cloud Service - Cos è IT Cloud Service è una soluzione flessibile per la sincronizzazione dei file e la loro condivisione. Sia che si utilizzi

Dettagli

Integrazione del progetto CART regione Toscana nel software di CCE K2

Integrazione del progetto CART regione Toscana nel software di CCE K2 Integrazione del progetto CART regione Toscana nel software di CCE K2 Data Creazione 04/12/2012 Versione 1.0 Autore Alberto Bruno Stato documento Revisioni 1 Sommario 1 - Introduzione... 3 2 - Attivazione

Dettagli

Brochure Internet. Versione 2010.1 The Keyrules Company s.r.l. Pagina 2 di 8

Brochure Internet. Versione 2010.1 The Keyrules Company s.r.l. Pagina 2 di 8 Ogni organizzazione possiede un sistema di regole che la caratterizzano e che ne assicurano il funzionamento. Le regole sono l insieme coordinato delle norme che stabiliscono come deve o dovrebbe funzionare

Dettagli

E-MAIL INTEGRATA OTTIMIZZAZIONE DEI PROCESSI AZIENDALI

E-MAIL INTEGRATA OTTIMIZZAZIONE DEI PROCESSI AZIENDALI E-MAIL INTEGRATA OTTIMIZZAZIONE DEI PROCESSI AZIENDALI E-MAIL INTEGRATA Ottimizzazione dei processi aziendali Con il modulo E-mail Integrata, NTS Informatica ha realizzato uno strumento di posta elettronica

Dettagli

R E G I O N E U M B R I A GIUNTA REGIONALE. Direzione Affari Generali della Presidenza e della Giunta regionale. Servizio Segreteria della Giunta

R E G I O N E U M B R I A GIUNTA REGIONALE. Direzione Affari Generali della Presidenza e della Giunta regionale. Servizio Segreteria della Giunta R E G I O N E U M B R I A GIUNTA REGIONALE Direzione Affari Generali della Presidenza e della Giunta regionale Servizio Segreteria della Giunta Disciplinare sull utilizzo della posta elettronica certificata

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

Airone Gestione Rifiuti Funzioni di Esportazione e Importazione

Airone Gestione Rifiuti Funzioni di Esportazione e Importazione Airone Gestione Rifiuti Funzioni di Esportazione e Importazione Airone Funzioni di Esportazione Importazione 1 Indice AIRONE GESTIONE RIFIUTI... 1 FUNZIONI DI ESPORTAZIONE E IMPORTAZIONE... 1 INDICE...

Dettagli

Integrazione InfiniteCRM - MailUp

Integrazione InfiniteCRM - MailUp Integrazione InfiniteCRM - MailUp La funzionalità della gestione delle campagne marketing di icrm è stata arricchita con la spedizione di email attraverso l integrazione con la piattaforma MailUp. Creando

Dettagli

La Fatturazione Elettronica

La Fatturazione Elettronica Informazioni Generali : La trasmissione di una fattura elettronica in formato Xml alla PA, obbligatoria a partire dal prossimo giugno (a scaglioni) avviene attraverso il Sistema di Interscambio (SdI),

Dettagli

Servizi Remoti. Servizi Remoti. TeamPortal Servizi Remoti

Servizi Remoti. Servizi Remoti. TeamPortal Servizi Remoti 20120300 INDICE 1. Introduzione... 3 2. Consultazione... 4 2.1 Consultazione Server Fidati... 4 2.2 Consultazione Servizi Client... 5 2.3 Consultazione Stato richieste... 5 3. Amministrazione... 6 3.1

Dettagli

I MODULI Q.A.T. PANORAMICA. La soluzione modulare di gestione del Sistema Qualità Aziendale

I MODULI Q.A.T. PANORAMICA. La soluzione modulare di gestione del Sistema Qualità Aziendale La soluzione modulare di gestione del Sistema Qualità Aziendale I MODULI Q.A.T. - Gestione clienti / fornitori - Gestione strumenti di misura - Gestione verifiche ispettive - Gestione documentazione del

Dettagli

SISTEMA DI GESTIONE PER LA QUALITA Capitolo 4

SISTEMA DI GESTIONE PER LA QUALITA Capitolo 4 1. REQUISITI GENERALI L Azienda DSU Toscana si è dotata di un Sistema di gestione per la qualità disegnato in accordo con la normativa UNI EN ISO 9001:2008. Tutto il personale del DSU Toscana è impegnato

Dettagli

OmniAccessSuite. Plug-Ins. Ver. 1.3

OmniAccessSuite. Plug-Ins. Ver. 1.3 OmniAccessSuite Plug-Ins Ver. 1.3 Descrizione Prodotto e Plug-Ins OmniAccessSuite OmniAccessSuite rappresenta la soluzione innovativa e modulare per il controllo degli accessi. Il prodotto, sviluppato

Dettagli

Ministero della Giustizia

Ministero della Giustizia Ministero della Giustizia DIPARTIMENTO DELL ORGANIZZAZIONE GIUDIZIARIA, DEL PERSONALE E DEI SERVIZI PROCESSO CIVILE TELEMATICO Modalità per l esecuzione dei test di interoperabilità da parte di enti o

Dettagli

Light CRM. Documento Tecnico. Descrizione delle funzionalità del servizio

Light CRM. Documento Tecnico. Descrizione delle funzionalità del servizio Documento Tecnico Light CRM Descrizione delle funzionalità del servizio Prosa S.r.l. - www.prosa.com Versione documento: 1, del 11 Luglio 2006. Redatto da: Michela Michielan, michielan@prosa.com Revisionato

Dettagli

Protocollo Informatico (D.p.r. 445/2000)

Protocollo Informatico (D.p.r. 445/2000) Protocollo Informatico (D.p.r. 445/2000) Ricerca veloce degli atti, archiviazione, fascicolazione ed inventario semplice e funzionale Collegamento tra protocolli tramite la gestione dei fascicoli e visualizzazione

Dettagli

MANUALE MOODLE STUDENTI. Accesso al Materiale Didattico

MANUALE MOODLE STUDENTI. Accesso al Materiale Didattico MANUALE MOODLE STUDENTI Accesso al Materiale Didattico 1 INDICE 1. INTRODUZIONE ALLA PIATTAFORMA MOODLE... 3 1.1. Corso Moodle... 4 2. ACCESSO ALLA PIATTAFORMA... 7 2.1. Accesso diretto alla piattaforma...

Dettagli

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali CL AS SE INFORMATICA 6(3) 6(4) - 6(4) SISTEMI E RETI 4(2) 4(2) 4(2) TECNOLOGIE E PROGETTAZIONE DI SISTEMI INFORMATICI E DI TELECOMUNICAZIONI COMPETENZE 3 Essere in grado di sviluppare semplici applicazioni

Dettagli

INFORMATIVA SUL DIRITTO ALLA PRIVACY PER LA CONSULTAZIONE DEL SITO WEB www.arlatighislandi.it

INFORMATIVA SUL DIRITTO ALLA PRIVACY PER LA CONSULTAZIONE DEL SITO WEB www.arlatighislandi.it INFORMATIVA SUL DIRITTO ALLA PRIVACY PER LA CONSULTAZIONE DEL SITO WEB www.arlatighislandi.it redatto ai sensi del decreto legislativo n 196/2003 2 GENNAIO 2014 documento pubblico 1 PREMESSA 3 SEZIONE

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

Regione Piemonte Portale Rilevazioni Crediti EELL Manuale Utente

Regione Piemonte Portale Rilevazioni Crediti EELL Manuale Utente Pag. 1 di 15 VERS V01 REDAZIONE VERIFICHE E APPROVAZIONI CONTROLLO APPROVAZIONE AUTORIZZAZIONE EMISSIONE NOME DATA NOME DATA NOME DATA A. Marchisio C. Pernumian 29/12/2014 M. Molino 27/02/2015 M. Molino

Dettagli

EXPLOit Content Management Data Base per documenti SGML/XML

EXPLOit Content Management Data Base per documenti SGML/XML EXPLOit Content Management Data Base per documenti SGML/XML Introduzione L applicazione EXPLOit gestisce i contenuti dei documenti strutturati in SGML o XML, utilizzando il prodotto Adobe FrameMaker per

Dettagli

Base di dati e sistemi informativi

Base di dati e sistemi informativi Base di dati e sistemi informativi Una base di dati è un insieme organizzato di dati opportunamente strutturato per lo svolgimento di determinate attività La base di dati è un elemento fondamentale per

Dettagli