La Porta Di Dominio (PDD) ha lo scopo di assicurare che lo scambio elettronico di informazioni tra le Pubbliche Amministrazioni abbia le stesse caratteristiche di quello tradizionale (carta, firma, protocollo, fax...)[1]. Il concetto di PDD è stato deprecato[2] dal Piano Triennale per l'Informatica nella Pubblica Amministrazione 2017-2019, approvato dal Presidente del Consiglio in data 31 maggio 2017, introduce un nuovo Modello di interoperabilità che supera il modello precedente (SPCoop).
Si definisce il dominio come l'insieme delle risorse - tra cui procedure, dati e servizi - e delle politiche di una determinata organizzazione. Il dominio è anche il confine di responsabilità di un'organizzazione, in particolar modo per quanto riguarda le politiche relative al suo sistema informativo.
Scopo dell'architettura cooperativa è di abilitare l'integrazione degli oggetti informativi (procedure e dati) e delle politiche di diversi domini, favorendo la comunicazione tra entità omogenee garantendo autonomia alle singole amministrazioni e lasciando inalterato il loro patrimonio informativo.
L'interoperabilità fra amministrazioni deve svilupparsi attraverso le porte di dominio, sulla base di standard definiti a livello nazionale in modo tale che:
L'amministrazione che invia le informazioni in modo elettronico ad un'altra, sarà garantita del fatto che la destinataria (e non altri) le abbia ricevute, così come la ricevente potrà trattare le informazioni elettroniche ricevute con pari dignità di quelle che oggi riceve con i metodi tradizionali, considerati fino ad ora gli unici probanti ai fini del procedimento amministrativo. Questo dovrà essere possibile indipendentemente da come viene realizzata la porta di dominio (fornitore, linguaggi, tecnologia…) in quanto la sua interfaccia è stata definita.
L'allegato n.2 (Rete Nazionale: caratteristiche e principi di cooperazione applicativa) emesso dal Dipartimento per l'Innovazione e le Tecnologie definisce le principali linee guida per le amministrazioni che vogliano realizzare servizi on-line interagendo con i sistemi informativi di altre amministrazioni. In tali indicazioni la porta di dominio costituisce l'elemento tecnologico che realizza la cooperazione. Ogni porta di dominio a livello concettuale funge da proxy per l'accesso alle risorse applicative che si trovano all'interno dello stesso dominio.
La porta di dominio fa parte del modello organizzativo del Sistema Pubblico di Connettività e Cooperazione (SPC) e come tale trova naturalmente posto nella progettazione concettuale piuttosto che in quella logica o fisica[3]. In particolare, a livello concettuale esiste una sola porta per ogni dominio, che rappresenta la somma di tutti gli apparati preposti all'accesso delle risorse del dominio.
I sistemi informatici che, attraverso la porta di dominio, si affacciano al SPC possono appartenere a diverse categorie:
La Porta di Dominio consente a ciascuna PA che espone i propri servizi ad altre PA di comunicare facilmente con loro condividendo e adottando gli stessi protocolli (dove "protocolli" è usato in senso lato). Ogni ente è in grado di fungere sia da fornitore sia da consumatore di un dato servizio. È quindi facile comprendere che la PDD è un componente a due facce: quella esterna deve aderire ad un set di standard per consentire l'interoperabilità con le PDD di altre PA, mentre quella interna è dipendente dalle risorse interne dell'ente. La "Cooperazione Applicativa" (la logica che abilita applicazioni e infrastrutture diverse ad interagire) prevede che ogni Porta di Dominio sia logicamente suddivisa in una componente di Cooperazione ed una di Integrazione: la prima, rivolta verso l'esterno della PDD, è incaricata delle comunicazioni fra Porte di Dominio, mentre la seconda interagisce con la logica e l'architettura dell'infrastruttura che deve servire. A seconda che una data PDD svolga il ruolo di fornitore o di consumatore è chiamata, rispettivamente Porta Applicativa o Porta Delegata. Le comunicazioni avvengono sempre fra Porte Delegate e Porte Applicative.
I paradigmi di cooperazione applicativa che devono essere supportati dalle porte di dominio sono riconducibili a due tipologie principali: la richiesta di servizio e la comunicazione di evento.
La richiesta di servizio consiste nella richiesta da parte di un dominio di un servizio erogato da un dominio servente e si suddivide a sua volta in 'Interrogazione' (se la richiesta non comporta modifiche di alcun oggetto del dominio servente) e 'Transazione', nel caso in cui la richiesta produca una variazione permanente di qualche oggetto dell'applicativo del dominio servente.
Un Evento, invece è il cambiamento di valore di un oggetto applicativo in un dominio sorgente che ha significato anche per altri domini detti destinatari. La notifica dell'evento non prevede la risposta da parte dei destinatari.
In base al tipo di richiesta, si profilano i seguenti due scenari di cooperazione:
La richiesta di servizio consiste in un messaggio prodotto da una applicazione di un dominio cliente e diretto ad una applicazione di un dominio servente. Il messaggio determina l'esecuzione di una applicazione del dominio servente che, in base alle informazioni contenute nel messaggio, esegue una procedura ed invia una risposta destinata all'applicazione cliente. La risposta è un'indicazione certa che l'applicazione servente ha attuato la richiesta e che abbia avuto esito positivo/negativo. Dal punto di vista dell'interazione amministrativa, la richiesta di servizio è sempre sincrona. La richiesta di servizio può essere di due tipi:
Ogni ente è in grado di fungere sia da "fornitore" che da "consumatore" di un dato servizio. La porta di dominio che invoca la richiesta di servizio deve dapprima contattare il Catalogo Servizi per ricavarne i dettagli tecnici e le interfacce necessarie alla comunicazione. Vediamo quindi una schematizzazione della sequenza degli scambi dal punto di vista di un'amministrazione che desideri utilizzare un certo servizio informativo esposto da un altro ente:
La comunicazione di un evento consiste nell'invio di un messaggio da parte di un'applicazione allo scopo di informare altre applicazioni di uno o più domini destinatari dell'avvenuto cambiamento delle informazioni relative ad un oggetto applicativo o della creazione di un nuovo oggetto applicativo. Il messaggio inviato contiene anche le informazioni, nuove o modificate, che descrivono l'evento stesso. L'interazione tra gli interlocutori avviene in modo indiretto, intermediata da una infrastruttura di servizio (detta di Publish and Subscribe) che fornisce servizi per la pubblicazione di un evento e di sottoscrizione agli eventi stessi. In questo scenario ad esempio un Comune, a fronte della richiesta di cambio residenza da parte di un cittadino, pubblica l'evento Cambio Residenza, insieme a tutti i dati ad esso relativi, sul sistema di Publish and Subscribe. Quest'ultimo si occupa di notificarlo poi, in modo opportuno, a tutte le amministrazioni che avevano preventivamente sottoscritto quell'evento specifico.
In termini generali, si assume che ciascuna collaborazione applicativa preveda lo scambio di una coppia di messaggi: una richiesta inviata da una porta di dominio a cui fa seguito una risposta da parte di un'altra porta di dominio. Si prevedono collaborazioni realizzate tramite lo scambio di messaggi in modalità sincrona e asincrona. Per convenzione, il sincronismo viene visto dal punto di vista della porta presso la quale ha inizio ogni episodio di collaborazione:
La scelta della modalità sincrona o asincrona può dipendere da aspetti legati alla latenza delle procedure amministrative (ad esempio la necessità di intervento umano per l'apposizione della firma digitale di un pubblico ufficiale). Tuttavia, in linea di principio, tale scelta può dipendere anche da scelte di carattere esclusivamente tecnologico.
Per scambiare messaggi applicativi fra porte di dominio viene utilizzata la busta di eGovernment (e-Gov)[4] che è la definizione del formato di codifica e del contenuto dei messaggi SOAP, utilizzati per implementare, sotto forma di Web services, i servizi esposti dalle Porte Applicative delle amministrazioni. Il formato della busta di eGovernement è stata definita dal Centro Tecnico della Rete Unitaria della PA (attualmente DigitPA) nei documenti di linee guida a supporto dell'implementazione dei progetti di eGovernment. Ogni messaggio scambiato tra porte di dominio si compone di due parti principali:
Lo strumento utilizzato per definire un formato dei dati condiviso tra tutte le amministrazioni, a prescindere dai sistemi "legacy" e dalle basi dati, è XML. SOAP è invece utilizzato come standard per veicolare le informazioni codificate con XML sulla rete Internet, mediante il protocollo HTTP. In generale, il tipo di struttura da utilizzarsi per busta e contenuto dipende dal tipo di messaggio e dalle esigenze di carattere normativo. In questo senso, in base alla normativa vigente possono essere definiti tre tipi di messaggi:
Si noti che i messaggi di tipo 1) e 2) si prestano ad un trattamento interamente automatizzato, mentre i messaggi di tipo 3) richiedono, tipicamente, un intervento manuale di firma da parte di un pubblico ufficiale. I documenti a valore legale possono essere firmati digitalmente come allegati binari PKCS #7 (in base alla circolare AIPA CR/24); gli altri contenuti XML possono essere firmati digitalmente per fornire una prova della loro provenienza. Una firma opzionale può essere inclusa nell'intestazione utilizzando gli standard XML SOAP Security e XML Signature e potrebbe, ad esempio, essere usata per garantire la fonte di provenienza delle informazioni (art. 43 del D.P.R. 445/2000). La scelta delle strutture specifiche per la busta di e-government da utilizzare nello scambio dei messaggi costituisce una parte integrante della definizione preliminare dei servizi e non può costituire una variante da negoziarsi per ciascuno scambio. Dal punto di vista amministrativo, la struttura XML SOAP incorpora anche il ruolo della segnatura informatica in formato XML del messaggio in quanto riporta i dati minimi della registrazione di protocollo. La struttura XML SOAP può inoltre essere inclusa in una struttura MIME allo scopo di allegare al messaggio uno o più documenti applicativi, in base allo standard XML SOAP with attachments.
Viene riportato qui di seguito un elenco di documenti di riferimento relazionati con il componente di porta di dominio: