Architettura CART Versione /09/2010
|
|
- Evangelista Ferraro
- 8 anni fa
- Visualizzazioni
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 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:
DettagliMinistero 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
DettagliSPCOOP 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
DettagliScenari 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
DettagliIl 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
DettagliManuale 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
DettagliPresentazione 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
DettagliOpenSPCoop 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à
DettagliGuida 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
DettagliManuale 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
DettagliAllegato 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...
DettagliIl 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
DettagliB.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
DettagliPOR 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
DettagliMANUALE 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...
DettagliArchitettura 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........................................................
DettagliPortale 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
DettagliFirewall 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)
DettagliALLEGATO 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
DettagliProdotto <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...
DettagliVersione 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)
DettagliProgetto 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
DettagliIl 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
DettagliProgettaz. 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
DettagliGuida 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
DettagliGuida 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
DettagliReti 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
DettagliLa 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
DettagliRelease 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.............................
DettagliSpecifiche 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
DettagliLe 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
DettagliE.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
DettagliCentro 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
DettagliStrategie 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
DettagliSUAP. 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
DettagliOrganizzazione 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
DettagliSistemi 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
Dettaglilem 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
DettagliSOFTWARE 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
DettagliDematerializzare 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
Dettagli3. 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
DettagliREGOLE 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
DettagliGovernance 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
DettagliMONITORAGGIO 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
DettagliManuale 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
DettagliSoftware 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
DettagliUniversità 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
DettagliGuida 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...
DettagliFinalità 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...
DettagliGestione 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
DettagliSistemi 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
DettagliIntroduzione 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
DettagliREGIONE 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
DettagliNuovi 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
DettagliALICE 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
DettagliSicurezza 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
DettagliLezione 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
DettagliIntroduzione 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
DettagliLOG 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
DettagliCORSO 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
DettagliFattura 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
DettagliSOMMARIO... 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...
DettagliIl 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
DettagliIntroduzione 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
Dettagli1.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
DettagliLa 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
DettagliPiattaforma 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
DettagliProtocollo 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
DettagliMANUALE 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
DettagliPROGETTO 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
DettagliMetaMAG 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
DettagliIL 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
DettagliCreare 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,
DettagliManuale 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
DettagliDematerializzare 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
DettagliPROXYMA 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
Dettagli5.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.
DettagliIT 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
DettagliIntegrazione 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
DettagliBrochure 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
DettagliE-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
DettagliR 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
DettagliTitolo 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
DettagliAirone 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...
DettagliIntegrazione 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
DettagliLa 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),
DettagliServizi 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
DettagliI 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
DettagliSISTEMA 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
DettagliOmniAccessSuite. 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
DettagliMinistero 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
DettagliLight 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
DettagliProtocollo 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
DettagliMANUALE 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...
DettagliSISTEMI 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
DettagliINFORMATIVA 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
DettagliDigitPA. 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
DettagliRegione 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
DettagliEXPLOit 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
DettagliBase 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