Gara d Appalto Procedura aperta per la realizzazione dell Intervento SZ -04" Regione Abruzzo Riuso R.A.Ri Servizi E- Government agli Enti Locali in cooperazione applicativa (CIG 45595324D5) (CUP E99C07000030001) ALLEGATO 2 Uso Confidenziale Tutti i diritti riservati
ALLEGATO 2 Premessa 3 1 Architettura 4 1.1 Architettura Generale del Sistema 4 1.1.1 Architettura 4 1.2 Architettura Sottosistema Portale 6 1.2.1 Architettura Logica 6 1.2.2 Architettura Software 9 1.3 Architettura Sottosistema Tributi Minori 10 1.3.1 Software gestionale Tinn 12 1.3.2 Software gestionale Maggioli 13 1.3.3 Software gestionale Halley 15 1.3.4 Software gestionale Marv 16 1.4 Integrazione & Interazione tra i sottosistemi 19 1.4.1 Il DBProxy 19 1.4.2 Il Single Sign On 21 1.4.3 Sistemi Bank Pass Web 21 1.4.4 Integrazione con SOGET 22 Pagina 2 di 23
ALLEGATO 2 Premessa Lo scopo di questo documento è quello di descrivere l architettutura hardware e software del sistema Provincia Unica all interno del quale sono stati sviluppati i servizi dei Tributi Minori selezionati a riuso. Sono descritti nei dettagli i servizi esposti dal sistema e le modalità di integrazione ed interazione delle componenti atte ad erogarli. Pagina 3 di 23
ALLEGATO 2 1 Architettura 1.1 Architettura Generale del Sistema 1.1.1 Architettura Lo schema del sistema Provincia Unica - SIMIP all interno del quale è stato realizzato il servizio Tributi Minori, come illustrato nella figura seguente, prevede due macro entità: la server farm centrale e gli apparati periferici presso le sedi dei Comuni che permettono l interazione con i sistemi di Back Office presenti nei Comuni stessi. Figura 1 Schema logico Generale Cittadini, imprese ed enti possono usufruire dei servizi offerti dal portale accedendo, in base al loro ruolo, al Portale Pubblico o al Portale Privato. Pagina 4 di 23
ALLEGATO 2 Il Portale Pubblico ed il Portale Privato condividono la stessa infrastruttura tecnologica ed applicativa e rappresentano quindi due particolari declinazioni della stessa piattaforma di contenuti e servizi che di seguito sarà identificata con il generico termine di Piattaforma Portale. Figura 2 - Portale di accesso ai servizi Una sezione di Content Management permette di fornire un interfaccia web ad accesso controllato per consentire la gestione dei contenuti erogati sulla Piattaforma Portale, questa sezione viene denominata CMA: Content Management Application. Pagina 5 di 23
ALLEGATO 2 L utilizzo della CMA permette, inoltre, di poter effettuare le configurazioni specifiche per i singoli Enti (tipologia di backoffice tributi, tipologia di pagamenti abilititati, modalità di consultazione dei dati ecc.) 1.2 Architettura Sottosistema Portale 1.2.1 Architettura Logica Il sottosistema portale è costituito dai portali pubblico e privato, dal sistema editoriale e dal database di supporto. Il portale pubblico contiene informazioni e servizi rivolti a cittadini ed imprese: comunicati istituzionali, news locali, servizi di community, servizi anagrafici, servizi di pagamento semplici quali, ad esempio, il pagamento delle multe, del servizio mensa, ecc. Il portale privato invece contiene i dati ed i servizi rivolti agli operatori degli Enti: informazioni e documenti ufficiali, statistiche sul sito, report sui pagamenti effettuati, posta elettronica certificata, ecc. Tutti i contenuti che vengono pubblicati sui 2 portali risiedono nel DB portale e sono gestiti attraverso il sistema editoriale (Content Management System). Il portale, quindi, rappresenta il punto di aggregazione di tutte le funzionalità erogate dal sistema. La gestione dei contenuti è affidata a un insieme di redazioni distribuite sul territorio: centro servizi, operatori dei comuni che aderiscono al progetto. La piattaforma tecnlogica utilizzata per la realizzazione del portale è il K* sviluppato da Ksolutions. La piattaforma K* è un sistema per la gestione e il delivery delle informazioni e dei servizi, siano essi strutturati o in formato documentale, e per la loro pubblicazione su canali quali Web, SMS, WAP, MMS, Voice, TV, SAT, ecc. K* è basato su piattaforma J2EE (Java 2 Enterprise Edition) e database MySQL, ha funzionalità estremamente avanzate ed un interfaccia utente user-friendly. Pagina 6 di 23
ALLEGATO 2 Sul Figura 3 - La piattaforma K* sistema di gestione delle informazioni si poggiano applicazioni specifiche. La separazione architetturale tra i servizi di base e le applicazioni che le utilizzano consente la massima flessibilità nella distribuzione dell informazione per usi diversi e nella presentazione grafica. Le tecnologie utilizzate, in particolare la piattaforma J2EE, sono state scelte in quanto consentono una facile integrazione con prodotti di mercato che possono risultare necessari per verticalizzazioni spinte. Tramite l applicazione di content management (CMA) le redazioni sono in grado di avere accesso all amministrazione del portale in tutti i suoi aspetti. Il sistema K* con il quale è stato sviluppato il Portale è costituito da due componenti principali distinte ma operanti sui medesimi server: il sistema di Content Management Application (CMA) ed il sistema di Content Delivery Application (CDA). Il primo sovrintende l inserimento e la manutenzione dei contenuti del portale. Tramite l applicazione di content management (CMA) le redazioni sono in grado di avere accesso all amministrazione del portale in tutti i suoi aspetti. Il secondo costituisce il sito pubblico da cui vengono erogati i contenuti/servizi, via Internet/Intranet, verso gli utenti finali. Entrambi i sistemi utilizzano il repository dei dati (RDBMS) per la memorizzazione ed il recupero dei contenuti. Da un punto di vista logico quindi è possibile individuare tre distinti livelli: il repository dei contenuti (MySQL). un nodo costituito dall insieme dei servizi che implementano la CMA e su cui sono in esecuzione processi che complessivamente si occupano di gestire i contenuti del sito e tutti i dati di servizio. Pagina 7 di 23
ALLEGATO 2 uno o più nodi di front-office su cui risiedono le CDA, ovvero le pagine Web (statiche e dinamiche) consultabili dagli utenti finali che costituiscono la parte visibile del Portale Entrambe le componenti CMA e CDA si basano su una architettura applicativa a tre livelli costituita da uno strato di presentazione (Presentation Layer), uno di pura logica di elaborazione (Business Logic) ed, infine, uno strato che ospita i dati effettivi (Data Layer). Figura 4 - CMS Tanto l applicazione di CMA che le applicazioni di CDA, in termini di Business Logic, sono sviluppate con tecnologia Java Servlet e Java Server Pages (JSP). Queste componenti risiedono su un Servlet Container Tomcat comunicando via JDBC con il Data Layer rappresentato dal Database Server MySQL. La Business Logic genera le pagine dinamiche Pagina 8 di 23
ALLEGATO 2 che sono poi erogate via http da un Web server Apache. La figura successiva rappresenta in dettaglio le architetture tecnologiche e funzionale di quanto presentato. Figura 5 - Architettura tecnologica 1.2.2 Architettura Software Le richieste indirizzate al portale sono inoltrate ai server applicativi sulle quali sono installati gli applicativi di base (apache/tomcat) e le webapps relative alla cda e cma del portale. La realizzazione del portale mediante la piattaforma K* prevede l utilizzo delle seguenti componenti software: Web Server Installazione della versione di Apache 2.0.54 Per alcuni servizi del portale è richiesto l accesso web in modalità sicura mediante il protocollo https. Servlet Container Le Java Servlet e le Java Server Pages (JSP) sono servite dal Servlet Container Pagina 9 di 23
ALLEGATO 2 Jakarta Tomcat versione 4.0.6. Connettori Apache Tomcat Per la connessione tra Webserver e Servlet Container si utilizzano i jakarta-tomcatconnectors v.1.2.14 Java Virtual Machine La JVM utilizzata dal Tomcat è stata utilizzata la seguente versione: java version "1.4.2_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode) Repository Per il sistema RDBMS del K* (ma è usato anche per i database del sottosistema tributi) è stata utilizzata la distribuzione Open Source MySql v. 4.1.15. 1.3 Architettura Sottosistema Tributi Minori Il sottosistema Tributi Minori ha lo scopo di erogare, attraverso il portale, i servizi di pagamento e consultazione dei principali tributi e realizzare l integrazione di tali servizi con gli archivi residenti all interno dei Comuni. Il sistema è costituito da un modulo centrale che contiene il portale con tutti i servizi erogati al cittadino, alle imprese ed agli Enti e da una serie di moduli periferici dislocati presso i Comuni periferici. I moduli periferici contengono, oltre agli applicativi gestionali di back office per la gestione dei tributi e dell anagrafe del Comune, anche un applicativo di sincronizzazione tra il DB periferico con il DB centrale. Il sistema centrale invece contiene il sottosistema Portale il sottosistema Tributi Pagina 10 di 23
ALLEGATO 2 Il sottosistema Portale, come descritto nei paragrafi precedenti, è realizzato attraverso la piattaforma K*, è unico per tutti i Comuni ed è il contenitore di tutto quanto messo a disposizione dallo sportello unico per i cittadini, le imprese e gli Enti. Il sottosistema Tributi consente: a cittadini ed imprese di fruire dei servizi informativi e di pagamento relativi ai tributi semplici (servizi scolastici, multe, trasporti scolastici, ecc) e complessi ICI e TARSU agli operatori dei Comuni che non sono provvisti di software tributi di utilizzare gli applicativi gestionali in modalità ASP. I software gestionali e di pagamento dei tributi semplici sono realizzati attraverso applicazioni costruite ad hoc direttamente sul portale attraverso la piattaforma K*, mentre i servizi complessi sono implementati attraverso gli strumenti Tinn/Golem, Maggioli ed Halley. Di seguito sono illustrate tali soluzioni. Software gestionale Tinn. Per i Comuni che usano software gestionale Tinn è presente un applicazione tributi online Tinn. Software gestionale Maggioli. Per i Comuni che usano software gestionale Maggioli è presente un applicazione tributi online Maggioli Software gestionale Halley. Pagina 11 di 23
ALLEGATO 2 Per i Comuni che usano software gestionale Halley è presente un applicazione tributi online Halley Software gestionale mancante. Per i Comuni che non hanno software gestionale è presente, in modalità ASP centralizzata, il gestionale di back office di Maggioli. Software gestionale di terze parti. Per i Comuni che non hanno né software gestionale Maggioli né Tinn né Halley è disponibile l applicazione di front-end di Maggioli. 1.3.1 Software gestionale Tinn In questo caso il sistema è costituito da una componente centrale che implementa i servizi veri e propri attraverso i moduli Tinn ICI online e TARSU online ed una componente periferica che ha il compito di sincronizzare i DB utilizzati dagli applicativi gestionali Tinn/Golem dei singoli Comuni con il DB Tributi centrale. La sincronizzazione avviene in 2 sensi dal DB periferico al DB centrale e, viceversa, dal DB centrale verso il DB gestionale periferico attraverso applicazioni ad hoc ed invio di file XML. II sottosistema tributi viene realizzato interamente con i seguenti moduli Tinn/Golem ICI online: applicazione jsp TARSU online: applicazione jsp Pagina 12 di 23
ALLEGATO 2 1.3.2 Software gestionale Maggioli In questo caso il sistema è costituito da una componente centrale che implementa i servizi on-line di front end e di back office ed una componente periferica che ha il compito di sincronizzare i DB dei sistemi gestionali utilizzati nei singoli comuni con il DB Tributi centrale. La sincronizzazione avviene in 2 sensi: dal DB periferico al DB centrale e, viceversa, dal DB centrale verso il DB gestionale periferico attraverso applicazioni ad hoc ed invio di file XML. Per i Comuni sprovvisti di software gestionale la sincronizzazione avviene direttamente tra il DB di Back Office ed il DB di Front End entrambi centralizzati. 1.3.2.1 Architettura Logica Pagina 13 di 23
ALLEGATO 2 Figura 6 - Architettura logica Maggioli Il sottosistema tributi è realizzato interamente con i seguenti moduli Maggioli: e-city friends (ICI e TARSU online): applicazione web php DB Tributi centrale: Mysql Moduli di sincronizzazione: applicazioni Windows DB Tributi (RDBMS Oracle) Pagina 14 di 23
ALLEGATO 2 La soluzione Maggioli consente di avere anche un applicazione di Back Office centralizzata ospitata a cui i Comuni possono accedere in modalità ASP. La componente web del Back Office è ospitata sul server ed le richieste sono gestite da un webserver Microsoft IIS. Il repository associato all applicazione è un database Oracle versione 9i. 1.3.3 Software gestionale Halley In questo caso il sistema è costituito da una componente centrale che implementa i servizi veri e propri mediante il Front-End Halley. Una componente periferica proprietaria del fornitore ha il compito di sincronizzare i DB utilizzati dagli applicativi gestionali Halley dei singoli Comuni con il DB Tributi centrale. L aggiornamento è monodirezionale. 1.3.3.1 Architettura Logica Pagina 15 di 23
ALLEGATO 2 Figura 7 - Architettura logica Halley Il sottosistema tributi viene realizzato interamente con i seguenti moduli Halley (ICI e TARSU online): applicazione web php DB Tributi Front End: Mysql Moduli di sincronizzazione: proprietari di Halley 1.3.4 Software gestionale Marv In questo caso il sistema è costituito da una componente centrale che implementa i servizi on line di front end ed una componente periferica che ha il compito di Pagina 16 di 23
ALLEGATO 2 sincronizzare i DB dei sistemi gestionali utilizzati nei singoli comuni con il DB Tributi centrale. La sincronizzazione avviene in 2 sensi: dal DB periferico al DB centrale e, viceversa, dal DB centrale verso il DB gestionale periferico attraverso applicazioni ad hoc ed invio di file XML. 1.3.4.1 Architettura Logica Figura 8 - Architettura logica MARV Il sottosistema tributi viene realizzato interamente con i seguenti moduli Maggioli: e-city friends (ICI e TARSU online): applicazione web php DB Tributi Front-End: Mysql Moduli di sincronizzazione: DBProxy XmlBlaster Pagina 17 di 23
ALLEGATO 2 Pagina 18 di 23
ALLEGATO 2 1.4 Integrazione & Interazione tra i sottosistemi 1.4.1 Il DBProxy DBProxy è un componente che permettere di mantenere aggiornato l'applicativo di BO di un Comune con il sottosistema Tributi locato nella server Farm centrale. E utilizzato quando l'applicazione di BO del Comune è diversa da TINN o Maggioli e l'aggiornamento è di tipo asincrono implementato attraverso la gestione di code. Il cuore di DBProxy è senz'altro xmlblaster. XmlBlaster è un Message oriented Middleware (MOM), ossia un broker di messaggi utilizzato, in questo caso, via XMLRPC; quindi è in grado di ricevere e inviare messaggi (file XML) secondo la logica FIFO tramite protocollo standard XMLRPC sulla porta 8080. I componenti K-Client e K-Server scambiano messaggi con questo utilizzando le sue librerie (xmlblaster.jar), quindi tramite XMLRPC. 1.4.1.1 Architettura Logica DBProxy è costituito da tre moduli fisicamente distinti: 1. K-Client Prende un file XML che soddisfa un particolare DTD e lo invia al componente middleware XMLBlaster. Contemporaneamente recupera file XML destinati al Comune locale. 2. XMLBlaster E' il componente che gestisce le code quindi agisce da broker: mantiente i messaggi a lui inviati e li restituisce ai sottoscrittori quando gli vengono richiesti. 3. K-Server E' il componente che implementa il sottoscrittore: recupera i messaggi (o file XML) dal broker e li converte in formato ASCII (length delimited) compatibile con la Pagina 19 di 23
ALLEGATO 2 componente di sincronizzazione di Maggioli. Realizza inoltre il flusso inverso ossia prende in ingresso un file ASCII come sopra, lo converte in XML e lo invia al broker. Il flusso di sincronizzazione dei dati tra un Comune ed il sistema centrale può essere schematizzato come nella figura riportata di seguito: dal Comune al sistema centrale viaggiano le informazioni degli utenti e le modifiche fatte sui sistemi di back office, dal sistema centrale ai Comuni viaggiano le informazioni relative ai pagamenti online effettuati. Figura 9 - Flusso di sincronizzazione Nella figura è evidenziata anche la componente denominata Publisher Maggioli il cui duplice scopo è quello di: prendere in ingresso i file ascii generati K-Server (DBP-Server) come elaborazione dei file xml, tramutarli in statement sql e aggiornare il DB Mysql del Comune corrispondente, generare file ascii corrispondenti alle informazioni non ancora trasferite al DB Tributi presso il Comune e posizionarli nel folder che verrà letto dal K-Server (DBP-Server) per la generazione dei file xml 1.4.1.2 Architettura Software Il sistema DBProxy è composto dalle seguenti componenti: xmlblaster Middleware DBP-Client DBP-Server Pagina 20 di 23
ALLEGATO 2 Per ogni Comune è necessario avere a disposizione una coppia di client e server opportunamente configurati in modo da non interferire con gli altri Comuni eventualmente in produzione. 1.4.2 Il Single Sign On Le funzionalità di single sign on sono realizzate con: Web service di registrazione, modifica e cancellazione. Quando un utente si registra al portale centrale di erogazione dei servizi e richiederà di poter utilizzare i servizi tributi, tutte le informazioni necessarie (login, password, codice fiscale, ecc) verranno passate ad un web service che si incaricherà di registrare il cittadino anche sul DB Servizi. Lo stesso web service è utilizzato per la modifica e la cancellazione dell utente sul DB Servizi. Quando un utente richiederà di modificare le proprie credenziali sul portale o di essere eliminato dal database, le operazioni verranno effettuate anche sul DB Servizi attraverso la chiamata del Web service con gli opportuni parametri. Il trasferimento delle informazioni tra i 2 sistemi avviene in forma criptata attraverso algoritmi di cifratura. Autenticazione. Quando dal portale centrale l utente richiede di accedere ai servizi tributi online, ha la possibilità di accedere direttamente al sistema senza autenticarsi nuovamente. In altre parole l utente si autenticherà sempre sul portale centrale e, al momento di accedere ai servizi tributi, invierà le proprie credenziali (in POST) all applicazione di Front End. 1.4.3 Sistemi Bank Pass Web La gestione on line dei pagamenti relativi ai Tributi Minori nel portale di SIMIP viene espletata attraverso le funzionalità del sistema KECF che può gestire diverse tipologie di pagamento tra cui BPW (BankPassWeb). Pagina 21 di 23
ALLEGATO 2 Tale sistema di pagamento incentra le sue funzionalità sui server di SSB per la gestione di carte di credito. KECF provvede a comunicare a BPW gli estremi del pagamento da effettuare e ne riceve i dati riguardanti l esito. Il pagamento vero e proprio viene espletato dall utente direttamente sui server di BPW che in questo modo è l unico custode dei dati più sensibili della transazione come il numero di carta di credito. Le comunicazioni tra KECF e BPW avvengono su doppio canale con firma digitale sia in fase di avvio della transazione (da KECF a BPW) che in fase di comunicazione di esito (da BPW a KECF) e sono da ritenersi estremamente sicure. La gestione di tale sistema di pagamento avviene attraverso il backoffice di KECF e il bakoffice di BPW. L accesso controllato a questi due sistemi è riservato solo a persone autorizzate in possesso di opportune Login e Password. Una volta effettuato l accesso al back office di KECF è possibile accedere alle pagine di gestione dei pagamenti dal menu di sinistra. Da tali sezioni è possibile abilitare o disabilitare i vari metodi di pagamento per il merchant o ente che usufruisce del servizio e configurarne i parametri di interfacciamento. Nello specifico di BPW è possibile impostare le url di comunicazione e la chiave di firma dei parametri utilizzati nelle comunicazioni tra i due sistemi nelle due direzioni. Ad ogni Comune che utilizza il sistema Kecf per il pagamento online dei tributi minori è associato uno store kecf. 1.4.4 Integrazione con SOGET L'integrazione con SOGET è implementata in due contesti. Nel primo caso si basa sul programma ExportSoget che gestisce l'esportazione automatica dei dati di pagamento on-line realizzati sui sistemi tributi presenti. L'uso è rivolto a quei Comuni che gestiscono i pagamenti mediante concessionaria SOGET. In questi casi i front-end web non sono configurati per gestire il pagamento on-line. La seconda implementazione (SSOSoget) riguarda l'integrazione, in modalità Single Sign On con il sistema web di pagamento di SOGET. L'implementazione di SSOSoget si basa su servlet, in un tipico sviluppo J2EE (basato su Pagina 22 di 23
ALLEGATO 2 JDK 1.4.x). PER ACCETTAZIONE (firma leggibile e per esteso) Pagina 23 di 23