Architettura Tecnicai

Architettura Tecnica

Architettura Tecnicaii

Copyright © 2005-2011 Link.it s.r.l.

Architettura Tecnicaiii

Indice

1 Scopo del documento 1

1.1 Abbreviazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Overview 1

2.1 La PdD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.2 Funzionalità di Cooperazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.3 Funzionalità di Integrazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Architettura PdD 3

3.1 Strumenti software utilizzati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.1.1 Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.1.2 Database Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.2 Architettura dell’applicazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.2.1 Backend Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2.2 Data Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2.3 Business Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2.4 Frontend Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2.5 Schema Architetturale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Architettura Tecnicaiv

Elenco delle tabelle

1 Abbreviazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Architettura Tecnica1 / 9

1 Scopo del documento

Il presente documento definisce l’architettura tecnica di OpenSPCoop

1.1 Abbreviazioni

Questo paragrafo contiene le abbreviazioni utilizzate all’interno del documento

Abbreviazione SignificatoAS Application ServerDBMS Database Management SystemEJB Enterprise Java BeanJ2EE Java 2 Enterprise EditionJMS Java Message ServiceJMX Java Management eXtensionJNDI Java Naming and Directory InterfaceMDB Message Driven BeanPdD PdDPD porta DelegataPA porta ApplicativaSOAP Simple Object Access ProtocolSPCoop Sistema Pubblico di CooperazioneWS Web ServiceWSI Web Service Interoperability

Tabella 1: Abbreviazioni

2 Overview

2.1 La PdD

La PdD OpenSPCoop è una soluzione completa per l’erogazione e la fruizione di Servizi da parte delle Pubbliche Amministra-zioni, in maniera aderente alle più recenti specifiche del Sistema Pubblico di Cooperazione (SPCoop 1.1).

Il Software OpenSPCoop è il risultato di un progetto open source attivo da oltre due anni, la cui qualità è costantemente validatadalla più ampia comunità d’utenza per la cooperazione applicativa esistente in Italia. La porta è stata adottata nei principaliprogetti italiani di cooperazione applicativa, tra cui il progetto CART di Regione Toscana ed il progetto ICAR per la cooperazioneapplicativa interregionale. Anche l’interoperabilità è uno degli obiettivi principali del progetto OpenSPCoop. Il problema è statoaffrontato sia dal punto di vista teorico che da quello sperimentale, portando ad un’implementazione altamente interoperabilecon le altre implementazioni oggi disponibili di SPCoop.

Basata sugli standard dei Web Services, la PdD OpenSPCoop gestisce l’instradamento delle richieste applicative di un Entesull’infrastruttura SPCoop, anche in maniera del tutto trasparente alle applicazioni. È suddivisibile logicamente in un componentedi cooperazione verso l’infrastruttura SPC e in un componente di integrazione verso applicazioni interne al dominio di gestione.

Il componente di cooperazione utilizza un registro dei servizi dove sono registrati gli attori di una cooperazione applicativa (Sog-getti,Accordi di Servizio) per l’esportazione/fruizione dei servizi sull’infrastruttura SPC. L’elenco delle principali funzionalità dicooperazione offerte da OpenSPCoop vengono illustrate nella Sezione 2.2.

Il componente di integrazione si occupa invece dell’integrazione dei sistemi informativi locali interni al dominio di gestione dellaporta:

• Un sistema informativo locale che eroga uno specifico servizio applicativo, può essere contattato dall’esterno tramite la portaApplicativa presente sulla propria PdD.

Architettura Tecnica2 / 9

• Un sistema informativo locale che intende fruire di un servizio può farlo tramite la porta Delegata, presente sulla propria PdD.

L’elenco delle principali funzionalità di integrazione offerte da OpenSPCoop vengono illustrate nella Sezione 2.3.

La figura seguente evidenzia i componenti in gioco durante una cooperazione applicativa:

2.2 Funzionalità di Cooperazione

Le funzionalità di cooperazione della porta riguardano l’implementazione del protocollo SPCoop e quindi le modalità con cui laporta dialoga con altre PdD tramite busta e-Gov.

• Specifica SPCoop 1.1: pieno supporto del formato dell’Header della busta e-Gov SPCoop 1.1, così come specificata neldocumento SPCoop-Busta e-Gov_v1.1_20051014.

• Gestione Profili di Collaborazione: pieno supporto dei quattro profili previsti nell’Header e-Gov: Oneway, Sincrono, Asincro-no Simmetrico ed Asincrono Asimmetrico previsti.

• Gestione modalità consegna affidabile: implementazione del meccanismo di consegna affidabile mediante la gestione del-l’elemento opzionale Profilo Trasmissione della busta utilizzando l’algoritmo a finestra di trasmissione previsto dalla bustae-Gov.

• Tracciatura delle Comunicazioni: tutte le attività della porta vengono tracciate mediante dei log persistenti su file o su database,in accordo ai formati xml di tracciatura previsti dalla specifica SPCoop 1.1, in modo da poter ricostruire in caso di necessità gliandamenti dei flussi in ingresso o in uscita dal Dominio dell’Ente.

• Tracciatura Diagnostica: tutte le anomalie riscontrate nella gestione dei messaggi sono riportate mediante messaggi diagnosticipersistenti su file o su database, in accordo ai formati di diagnostica previsti dalla specifica SPCoop 1.1.

• PdD Multiente: una sola PdD può essere configurata per la gestione di più Soggetti SPCoop, in modo da realizzare un’infra-struttura multiente.

• Sicurezza a livello trasporto: gestione della modalità di comunicazione mediante il protocollo HTTPS. Assicura la garanzia ela confidenzialità dello scambio nell’ambito della connessione tra PdD.

• Sicurezza a livello messaggio: conformità con le raccomandazioni WSI Basic Security Profile v1.0 e supporto dello standardWS-Security, per la gestione della sicurezza a livello messaggio, laddove non siano applicabili i meccanismi di sicurezzapunto-punto forniti da https.

Architettura Tecnica3 / 9

• Verifica dei contenuti applicativi: possibilità di attivare la verifica del formato dei messaggi trasportati nelle buste e-Govrispetto agli schemi xml esposti dai WSDL degli Accordi di Servizio SPCoop.

• Politiche di Routing: possibilità di definire politiche di routing delle buste e-Gov per supportare topologie articolate di reteSPCoop, come ad esempio le comunicazioni interregionali.

2.3 Funzionalità di Integrazione

Le funzionalità di integrazione della porta riguardano le modalità con cui i servizi appicativi interni al Dominio dell’Ente possanoscambiare i contenuti applicativi con la PdD.

• Configurabilità di Porte Delegate e Applicative: l’abilitazione di nuove porte delegate e/o applicative non richiede l’instal-lazione sulla PdD di componenti applicativi ad-hoc, ma soltanto la registrazione dei dati identificativi relativi ad ogni nuovaporta delegata ed applicativa, riducendo così drasticamente la complessità di attivazione di nuovi servizi SPCoop.

• Integrazione Trasparente: in questa modalità di integrazione la PdD espone le stesse interfacce applicative native dei serviziregistrati negli accordi di servizio; in tal modo la PdD agisce come un proxy SOAP trasparente con funzionalità di imbustamen-to e sbustamento e-Gov dei messaggi in transito e gli applicativi possono continuare ad operare esattamente come se stesserointeragendo direttamente con il servizio applicativo dell’altro Ente.

• IntegrationManager: in questa modalità di integrazione i servizi applicativi usano un apposito web service di Integrazioneesposto dalla PdD; rispetto alla modalità trasparente l’Integration Manager assicura una maggiore flessibilità d’uso, ad esempionella gestione dei profili asincroni.

• Autenticazione dei Servizi Applicativi: la PdD può essere configurata per autenticare i servizi applicativi tramite protocollo diautenticazione http basic o https.

• Autorizzazione delle richieste: la PdD può essere configurata per regolare i diritti di accesso dei servizi applicativi nell’invio dimessaggi su una porta delegata e nella ricezione di messaggi su una porta applicativa.

• Applicazioni Legacy: la PdD può essere configurata per il tunnelling su SOAP dei contenuti applicativi. In questo modo èpossibile far comunicare su SPCoop anche applicazioni non aderenti allo standard dei Web Services.

• Correlazione Applicativa: questa funzionalità risolve uno dei principali limiti della specifica SPCoop, permettendo di corre-lare l’identificatore della busta e-Gov con un identificatore applicativo unico. In questo modo diventa possibile ricondurre iltracciamento di una busta e-Gov all’effettiva richiesta applicativa scambiata tra gli Enti.

3 Architettura PdD

3.1 Strumenti software utilizzati

La PdD di OpenSPCoop richiede la seguente infrastruttura software:

• Application Server

• Database Management System.

3.1.1 Application Server

La PdD richiede un application server che supporta le specifiche J2EE. J2EE aggiunge numerosi livelli di funzionalità al disopra della piattaforma J2SE, la quale è invece orientata allo sviluppo e al deployment di applicazioni desktop tradizionali. Lapiattaforma J2EE gestisce l’infrastruttura software e supporta i servizi Web che consentono di creare applicazioni enterprisesicure, distribuite e interoperabili. J2EE, tramite la sua architettura multilivello distribuita e basata sulle componenti, facilita losviluppo di applicazioni particolarmente scalabili, costituite da elementi fisicamente distribuiti nelle reti.

Architettura Tecnica4 / 9

Sull’Application Server verranno istanziati applicazioni in formato EAR e WAR. Le applicazioni registrano/consultano sia l’al-bero JNDI che la console JMX dell’AS. L’applicazione PdD è composta da EJB timers e MDB. Gli MDB necessitano di unbroker JMS su cui creare code utilizzate come buffers di comunicazione tra i moduli funzionali che compongono la porta.

L’application server di riferimento è JBoss mentre il broker JMS di riferimento è JBossMQ.

La PdD essendo realizzata tramite tecnologie J2EE è scalabile e distribuibile su cluster di AS in modo da aumentarne il sistemadi affidabilità e le performance.

3.1.2 Database Management System

La PdD supporta attualmente i database PostgreSQL, MySQL e Oracle. L’integrazione con altri database è facilmente realizzabilevisto che il core library della porta utilizza un’interfaccia comune di accesso al database (vedi Sezione 3.2.2).

Il DBMS di riferimento è PostgreSQL.

3.2 Architettura dell’applicazione

L’architettura della PdD è stata progettata da zero sulla base dell’esperienze fatte nell’uso dei prodotti e dei progetti per la coope-razione applicativa di prima generazione. Per le sue caratteristiche innovative, OpenSPCoop è stato oggetto di varie pubblicazioniscientifiche.

Basato sull’architettura J2EE, il software OpenSPCoop è facilmente portabile su qualunque Application Server J2EE. Il prodottoviene estesamente testato sulla piattaforma di riferimento di JBoss Application Server.

Il DBMS per la persistenza dei dati puo’ essere scelto attualmente tra i database PostgreSQL,MySQL,Oracle ma sono in costanteaumento i database supportati, visto la facile realizzazione di adapter dedicati a nuovi DB (vedi Sezione 3.2.2).

L’architettura si puo’ suddividere logicamente in quattro livelli così identificati:

• Backend Layer, storage richiesto dall’applicazione

• Data Layer, accesso allo storage

• Business Logic Layer, funzioni di cooperazione/integrazione della porta

• Frontend Layer, interfacce grafiche e web services

Di seguito lo schema architetturale di massima dell’applicazione, dove si evidenziano i livelli.

Architettura Tecnica5 / 9

3.2.1 Backend Layer

In questo livello si trovano le risorse di backend necessarie al corretto funzionamento della PdD. Le risorse sono logicamentesuddivisibili:

• Repository dei messaggi e delle buste e-Gov in gestione sulla porta

• Configurazione della PdD

• Sistema di logging dei msg diagnostici e delle tracce e-Gov emessi dalla PdD

Il repository dei messaggi e delle buste e-Gov viene realizzato tramite un database relazionale dove vengono memorizzati imessaggi in transito sulla porta. In particolare in campi appositi per la memorizzazione di byte (es. BLOB per Oracle/MySQL,ByteA per PostgreSLQ) vengono memorizzati i contenuti dei messaggi ottenendo due principali vantaggi:

• Il contenuto dei messaggi viene salvato dai servizi di ricezione, e letto dai moduli di uscita, modificato nell’header per lagestione della busta e-Gov. Non viaggiando nell’infrastruttura che collega i moduli funzionali è possibile avere performancemaggiori.

• Poichè il contenuto dei messaggi, le buste e-Gov e anche le informazioni di servizio vengono registrate su database, è possibileavere meccanismi di recovery dei messaggi in presenza di crash del sistema

La configurazione della PdD contiene le definizioni di PD, PA, servizi applicativi fruitori/erogatori e aspetti di configurazionepura della porta. Vengono attualmente gestite due tipi di configurazioni:

• Un file XML in cui gli elementi sono definiti attraverso uno schema xsd.

• Un database che puo’ essere gestito attraverso interfacce grafiche e ws (vedi Sezione 3.2.4)

Architettura Tecnica6 / 9

Il sistema di logging gestisce sia i messaggi diagnostici che le tracce e-Gov emesse dalla PdD. Le tracce hanno un valore legale,e devono obbligatoriamente essere mantenute attraverso uno storage. E’ possibile registrare tali informazioni su diverse risorse:

• Database che possono essere poi consultati attraverso interfacce grafiche (vedi Sezione 3.2.4). Le informazioni che vengonoregistrate su database, non sono in una forma xml, ma già strutturate in apposite tabelle e colonne e quindi di più facileconsultazione.

• Log emessi su File System attraverso la tecnologia Log4j. La struttura dei log, è formata da xml descritti dalle specificheCNIPA (vedi documento Sistema Pubblico di Cooperazione: Porta di Dominio)

• Qualsiasi altra risorsa gestibile attraverso Log4j.

La figura seguente mostra i componenti che fanno parte di questo layer:

3.2.2 Data Layer

In questo livello si trova la componente dell’applicazione che si occupa del reperimento e della persistenza dei dati presenti nelbackend layer. Esaminiamone la struttura software attraverso la classificazione già utilizzata nella Sezione 3.2.1.

Il repository dei messaggi e delle buste e-Gov viene gestito rispettivamente dai package org.openspcoop.pdd.core e org.openspcoop.egov.I package contengono sia i JavaBean che mappano in oggetti java le entità gestite su database, sia i driver per la loro gestione.Il repository viene acceduto anche da un’altro driver presente nel package org.openspcoop.pdd.monitor, che permette il moni-toraggio dei messaggi in transito sulla PdD. Le informazioni raccolte dal driver sono strutturate in Bean definiti nel packageorg.openspcoop.pdd.monitor.dto.

La configurazione della PdD è strutturata in oggetti java attraverso il package org.openspcoop.dao.config che contiene il mappingin JavaBean degli oggetti definiti nello schema xsd della configurazione. Il package org.openspcoop.dao.config.driver contieneinvece due driver per la gestione delle due tipologie di configurazioni possibili:

• DriverXML, permette la lettura della configurazione da un file xml.

• DriverDB, permette sia la lettura che la gestione CRUD della configurazione mantenuta attraverso un database.

Il sistema di logging viene gestito dal package org.openspcoop.pdd.logger che contiene sia i JavaBean che mappano i messaggidiagnostici e le tracce attraverso oggetti java, sia i driver per la loro gestione. All’interno del package sono presenti quattro driverper la gestione delle due tipologie di logging possibili:

• DriverMsgDiagnosticiDB,DriverTracciamentoDB, permettono la lettura e la registrazione su database. Le informazioni ven-gono strutturate su opportune colonne e tabelle.

• DriverMsgDiagnosticiLog4J,DriverTracciamentoLog4J, permettono la registrazione attraverso la tecnologia Log4J, e quindisu molteplici tipi di storage. Le informazioni registrate sono strutture XML dei messaggi diagnostici e delle tracce comedefinito dalla specifica CNIPA (vedi documento Sistema Pubblico di Cooperazione: Porta di Dominio)

L’accesso al database da parte dei driver non avviene direttamente tramite JDBC, ma attraverso un’interfaccia org.openspcoop.utils.SQLObjectche permette di astrarre dal tipo di database. Attualmente vengono fornite tre implementazioni dell’interfaccia SQLObject per iDatabase PostgreSQL, MySQL e Oracle. Le implementazioni utilizzano poi i driver JDBC per l’accesso al database.

La figura seguente evidenzia i collegamenti tra il Data Layer e il Backend Layer.

Architettura Tecnica7 / 9

3.2.3 Business Layer

La PdD di OpenSPCoop si basa sulla eGov Library di OpenSPCoop per implementare le funzionalità di PdD dell’architetturaSPCoop.

Il Business Layer OpenSPCoop implementa due moduli di ingresso (org.openspcoop.pdd.services):

• Ricezione Contenuti Applicativi, utilizzato per ricevere richieste (in forma di buste SOAP) dai Sistemi Informativi interni aldominio di cooperazione servito;

• Ricezione Buste e-Gov, utilizzato per ricevere richieste (in forma di buste e-Gov) da altre PdD, indirizzate a servizi ospitati neldominio di cooperazione servito.

Questi moduli interagiscono con il backend per reperire le informazioni che descrivono le specifiche porte delegate e applicativeresidenti sulla PdD per decidere come gestire le richieste in arrivo. In funzione di queste descrizioni e dello stato delle transazionieGov in corso, le richieste attraversano quindi una pipeline di moduli specifici (Message Driven Beans in terminologia J2EE,implementati nel package org.openspcoop.pdd.mdb), arricchendosi di informazioni utili al loro trattamento mantenute negliheader dei messaggi JMS.

I moduli di ingresso e gli MDB costituiscono il nucleo centrale del sistema, che si occupa dell’autorizzazione (org.openspcoop.pdd.autenticazione/autorizzazione),della validazione, del tracciamento, delle politiche di sicurezza (org.openspcoop.pdd.wssecurity), e soprattutto del trattamentodelle buste in transito, che può richiedere un semplice imbustamento/sbustamento, nei casi più semplici, fino all’implementazionedi sofisticate politiche di gestione dei riscontri, nei casi più complessi.

Per effettuare la consegna viene utilizzato il package org.openspcoop.pdd.connettori che si occupa di astrarre il livello ditrasporto. In questo modo possono essere supportati più protocolli per l’invio e dei messaggi, dall’HTTP al JMS.

In alcune situazioni, i Servizi Applicativi devono avere una precisa visibilità dei messaggi SPCoop scambiati tra le PdD. Unasituazione del genere si verifica, ad esempio, quando diversi messaggi SPCoop sono correlati tra loro, come nel caso del profilodi collaborazione Asincrona. Per questo, alcune delle informazioni contenute nell’header eGov possono essere scambiate tra ilServizio Applicativo e la PdD al momento dell’invocazione di un PD o PA grazie al componente di Integrazione, implementatoin org.openspcoop.pdd.Integrazione.

La PdD fornisce un web service di Integrazione per la spedizione e/o la ricezione di messaggi, alternativo alla modalità traspa-rente:

• Fruizione di servizi, attraverso l’invocazione della PD.

• Erogazione asincrona dei servizi, che consente alla porta applicativa di conservare il messaggio in un message box in attesache venga prelevato dal servizio applicativo attraverso l’Integration Manager.

Di seguito viene mostrato lo schema software del Business Logic Layer:

Architettura Tecnica8 / 9

3.2.4 Frontend Layer

Il livello di Frontend espone le interfacce necessarie agli utenti per gestire e fruire delle funzionalità fornite dalla PdD.

Per le funzionalità di gestione sono forniti il web service Management (org.openspcoop.management.ws), l’interfaccia web PdDGUI (org.openspcoop.web.pdd) e la Console JMX (org.openspcoop.pdd.jmx) che forniscono la possibilità di configurare ogniaspetto della PdD.

L’interfaccia web PdD GUI, il web service Monitor (org.openspcoop.monitor.ws) ed il Monitor CLI (Command Line Interfaceimplementato in org.openspcoop.monitor.cli) consentono il monitoraggio della PdD attraverso la visualizzazione dei messaggiin transito sulla porta. Le stesse interfacce, con l’esclusione del Monitor CLI, consentono la visualizzazione dei messaggidiagnostici e delle tracce e-Gov emesse dalla PdD.

Per i Soggetti Fruitori ed Erogatori la PdD espone tre servizi web, PD, PA e Integration Manager, per l’invio e la ricezionedei messaggi. Il primi due sono utilizzati per la modalità d’integrazione trasparente, qualora il servizio applicativo utilizzi (incaso di porta delegata) o esponga (in caso di porta applicativa) le interfacce applicative native dei servizi, così come registratenegli accordi di servizio. In tal caso la PdD agisce come un proxy SOAP trasparente con funzionalità di imbustamento e sbusta-mento eGov dei messaggi applicativi e gli applicativi potranno continuare ad operare esattamente come se stessero interagendodirettamente con il servizio applicativo dell’altro Ente.

Il Servizio di Integration Manager espone le funzionalità per la spedizione e/o la ricezione di messaggi ai servizi applicativinell’eventualità che non fosse possibile l’utilizzo della modalità d’integrazione trasparente.

Di seguito viene mostrato lo schema software del Frontend Layer:

3.2.5 Schema Architetturale

Di seguito viene mostrato il quadro completo dell’architettura software della PdD, con le relazioni tra i layer descritti nei prece-denti paragrafi. Si nota quindi che il layer di frontend interascisce con quello di business solo attraverso i web service PD, PAe Integration Manager, mentre per quanto riguarda le funzionalità di monitoraggio e gestione si interfaccia direttamente con ilbackend layer.

Architettura Tecnica9 / 9