Interazioni¶

L’ambito di applicazione del Modello di Interoperabilità 2018 comprende i tre tipi di interazioni previsti nell’EIF. Le interazioni prevedono che i soggetti coinvolti svolgano alternativamente la funzione di erogatore di servizio, nel caso del soggetto che mette a disposizione API o servizio utilizzati da altri, e la funzione di fruitore, nel caso invece del soggetto che utilizza le API o servizi messi a disposizione da altro soggetto.

Figura 5 - Ambito di applicazione del modello di interoperabilità

I soggetti fruitori possono utilizzare le API/servizi [10] esposti dall’erogatore attraverso:

• una soluzione software attivata da un attore umano (user agent/human);
• un sistema applicativo automatico [11] (server/machine), anche allo scopo di definire nuovi servizi a valore aggiunto .

In considerazione di quanto sopra si individuano le seguenti possibili interazioni:

1. A2A in modalità human-to-machine;
2. A2A in modalità machine-to-machine;
3. A2B in modalità human-to-machine;
4. A2B in modalità machine-to-machine;
5. A2C in modalità human-to-machine.

Paradigmi di cooperazione¶

In generale, nell’integrazione dei sistemi software si individuano principalmente le seguenti tre casistiche che il modello di interoperabilità deve tener presente:

• Condivisione di dati: l’obiettivo è quello di tenere allineati i dati di uno o più sistemi; le applicazioni software che gestiscono (creano, aggiornano, leggono ed eventualmente cancellano [12]) tali dati, sono logicamente e fisicamente indipendenti. I processi che sovraintendono le applicazioni sono separati ed indipendenti. Il caso tipico è quello di un’Amministrazione, o soggetto privato, che per dare seguito ad una sua attività ha necessità di accesso ai dati posseduti dall’Amministrazione B, titolare degli stessi, senza che sia richiesto all’Amministrazione B nessuna elaborazione sui dati. Ad esempio, B è il Ministero delle Finanze che ha i dati del codice fiscale di ogni cittadino, ed A è un qualsiasi altro soggetto (pubblico o privato) che all’interno della propria applicazione ha necessità di verificare la correttezza dei codici fiscali del proprio database, per poi utilizzarli in proprie elaborazioni.

• Notifica inter-PA: in questo caso un’applicazione in un soggetto scatena un evento compie un’operazione che deve essere propagata sincronizzata con altre applicazioni di altri soggetti. Le applicazioni sono fisicamente indipendenti ma non logicamente, in quanto esiste un processo inter-organizzativo che sovraintende a tutte le organizzazioni che devono cooperare [13]. Il caso tipico è quello in cui il presentarsi di un evento all’interno di un’Amministrazione A debba essere comunicato ad altri soggetti B e C, pubblici e privati, che devono dare seguito a proprie procedure interne in relazione all’evento stesso, per vincoli normativi, ecc. Ad esempio, la registrazione di una nascita in un Comune è un evento che deve essere propagato all’Agenzia delle Entrate, per il rilascio di un nuovo codice fiscale, all’AUSL di riferimento per l’iscrizione al Servizio Sanitario Nazionale, ecc.

• Composizione inter-PA: in questo caso un insieme di applicazioni comunicano, anche in maniera bidirezionale, al fine di comporre una nuova logica applicativa ottenuta dalla loro interazione, ed erogare questa a sua volta come servizio a valore aggiunto. Talvolta questa nuova logica viene indicata come servizio/applicazione composito/a (o composto/a). Come nel caso precedente, esiste un processo inter-organizzativo che sovraintende a tutte le organizzazioni che vengono composte. Il caso tipico, nel mondo commerciale, è quello di un servizio che definite delle date ed una destinazione, propone all’utente voli aerei, hotel e noleggio auto, ecc, andando appunto a comporre servizi per la bigliettazione aerea, prenotazione alberghiera, noleggio auto, ecc. Nel caso della PA, un caso è una conferenza di servizi telematica [14] in cui diverse Amministrazioni compongono un un nuovo servizio per dare seguito ad una istanza di un cittadino o di un’impresa.

È importante analizzare le analogie e differenze con il caso precedente: nel caso della notifica inter-PA, c’è una relazione peer-to-peer tra i vari soggetti coinvolti, e si parla di coreografia tra le applicazioni coinvolte [15]. Nel caso invece della composizione, una delle applicazioni ha un ruolo di orchestrazione nei confronti delle altre, e quindi c’è una relazione uno (l’orchestratore, che fa da master) a molti (le applicazioni orchestrate, che sono slave).

In entrambe le situazioni, esiste a livello concettuale (dovuto a norme, accordi, ecc.) un processo inter-organizzativo che sovraintende alle varie applicazioni, e l’espletamento del quale è l’obiettivo del servizio composto offerto.

La differenza tra i due casi risiede quindi nel grado di autonomia che i soggetti che concorrono al processo inter-organizzativo mantengono: se si sceglie un approccio completamente decentralizzato, si è nel caso notifica inter-PA, se si opta per un approccio per cui uno dei soggetti prende in carico la fornitura del servizio finale composto a valore aggiunto, allora si è nel caso composizione inter-PA.

Incrementalità del modello¶

In base alle considerazioni precedenti, il Modello di Interoperabilità si concretizza nella definizione, lo sviluppo, il miglioramento, la resa operativa, il mantenimento e la promozione di servizi, strumenti, norme tecniche e specifiche per l’interoperabilità delle soluzioni ICT basata su un’architettura modulare che include componenti interconnessi con l’ausilio di infrastrutture comuni. Questo modello, al fine di evitare le problematiche di possibile obsolescenza, e fronteggiare la necessità di continui aggiornamenti, si estrinsecherà concretamente in rilasci successivi e cadenzati nel tempo, di una serie di 5 documenti, in particolare:

1. Presentazione del Modello di Interoperabilità 2018, che è il documento attuale, rilasciato nella prima versione a maggio 2018.
2. Tecnologie ed approcci all’Integrazione ed Interoperabilità, che nella prima versione (maggio 2018) viene rilasciato contestualmente al presente documento. Ha come oggetto l’individuazione delle possibili tecnologie ed approcci che possono essere utilizzati dalle PA.
3. Pattern e Profili di Interoperabilità, che fornirà indicazioni concrete, a livello tecnico, su differenti modalità operative per realizzare l’interoperabilità, tenendo conto delle possibili tecnologie ed approcci disponibili. La prima release di questo documento è prevista per l’estate 2018. Il Modello introduce il concetto di profilo di interoperabilità e come esso possa essere evoluto nel tempo; si introduce anche il concetto di pattern di interoperabilità. Infine questo documento si occuperà di discutere anche l’aspetto della QoS - Quality of Service e degli SLA - Service Level Agreement.
4. Governance del Modello di Interoperabilità, che presenterà compiutamente la governance dell’intero modello e le sue modalità di evoluzione, ed è previsto in una prima versione per l’estate 2018.
5. Registri e Cataloghi, che si occuperà di definire le linee guida per i registri e cataloghi necessari a supportare il modello stesso. Anche per questo documento è prevista una prima versione per l’estate 2018.

Gli interventi mirano, in coordinamento con le altre azioni presenti nel Piano Triennale per l’Informatica nella PA, a:

• definire e attuare specifiche comuni sui termini e le condizioni per gestire e accedere ai base register;
• attuare e promuovere modelli comuni per descrivere e classificare i servizi pubblici;
• individuare misure volte a creare sicurezza, tracciabilità e SLA - Service Level Agreement nell’erogazione dei servizi;
• analizzare i dati contenuti e i sistemi esistenti per l’informatizzazione delle PA;
• individuare gli ostacoli al reciproco riconoscimento, sviluppare mappature e sostenere gli sforzi di armonizzazione.

Gli standard tecnologici adottati, in particolare per i web service REST e SOAP, rispecchiano l’attuale stato di evoluzione delle tecnologie ed il loro utilizzo è consolidato nelle pratiche adottate nell’ambito dell’interoperabilità dei sistemi informativi.

Profili e pattern di interoperabilità¶

Il nuovo modello introduce i concetti di caso d’uso, pattern e profilo di interoperabilità.

Un caso d’uso di interoperabilità è la formalizzazione di una specifica esigenza di interoperabilità, che si manifesta frequentemente tra PA, o che può manifestarsi in particolari contesti applicativi. Tale necessità viene descritta mostrandone il contesto di applicazione, i problemi progettuali che ne derivano, i possibili schemi di soluzione e le implicazioni di ognuno di essi.

Ogni caso d’uso può essere risolto in vari modi, ognuno di questi schemi verrà indicato come pattern di interoperabilità. Esso fornisce una serie di linee guida per l’implementazione e l’interoperabilità che raccomandano come utilizzare una specifica tecnologia od approccio, e permette eventualmente di risolvere eventuali ambiguità/punti non adeguamente definiti in alcune tecnologie possibili con cui le PA possono interoperare.

Un profilo infine, in maniera trasversale rispetto ai casi d’uso ed ai pattern, risolve le diverse opzionalità o aspetti non adeguatamente specificati dagli standard tecnologici.

L’applicazione dei casi d’uso, pattern e profili agevola l’azione nello sviluppo e nella distribuzione di API/servizi. Il nuovo Modello proporrà un catalogo di casi d’uso, profili e pattern di interoperabilità messi a disposizione delle PA, popolato maniera incrementale sulla base di esigenze individuate dall’Agenzia per l’Italia Digitale anche a fronte dell’evidenza di nuovi bisogni per le PA.

Ogni PA che offre un’API/servizio deve, nel nuovo modello, offrire un insieme di artefatti che lo accompagnano, in particolare:

• meccanismi di controllo delle versioni;
• documentazione coordinata alla versione;
• Software Development Kit - SDK - per l’interfacciamento e un ambiente di test (in analogia a quanto avviene per alcuni servizi commerciali di largo utilizzo in applicazioni Web [16]);
• dichiarazione sulla qualità del servizio che si impegna a rispettare. In questo secondo caso, deve anche definire le modalità di misurazione e deve offrire un’opportuna modalità di monitoraggio, che i fruitori possono sfruttare per la verifica.

Nello scambio informativo tra PA mediante API/servizi, le soluzioni che verranno adottate devono assicurare: (i) autenticità, (ii) integrità e (iii) non ripudio. In questo contesto il Regolamento (UE) 2014/910 fornisce una base normativa comune per le interazioni elettroniche sicure fra cittadini, imprese e PA; le soluzioni software conformi al Modello di Interoperabilità devono applicare i principi indicati in esso.

Catalogo delle API/servizi¶

Il Modello di Interoperabilità prevede la presenza del Catalogo quale componente che assicura alle parti coinvolte nel rapporto erogazione/fruizione la consapevolezza sulle interfacce e i livelli di servizio dichiarati.

La presenza del Catalogo è funzionale a:

• facilitare l’interoperabilità tra le PA e tra queste e i soggetti privati interessati;
• contenere la spesa della PA riducendo la replicazione di API/servizi;
• manifestare gli impegni dei fornitori o erogatori di API/servizi.

La realizzazione del Catalogo deve, fatti salvi i principi comuni che saranno emanati dall’Agenzia per l’Italia Digitale al fine di permettere una normalizzazione a livello nazionale, tener conto della:

• specificità dei territori e dei diversi ambiti entro cui la PA opera che potrà determinare la specializzazione del catalogo, prevedendo contenuti con un livello di aggregazione territoriale (eg. su base regionale) e/o relativamente agli ambiti tematici entro cui opera la PA (eg. giustizia). Tale scelta è ulteriormente giustificata dalla opportunità di favorire momenti di aggregazione di soggetti omogenei.
• esigenza di assicurare la governance del Catalogo, quale presupposto per garantire una semantica univoca e condivisa, per evitare ridondanze e/o sovrapposizioni in termini di competenze e contenuti.
• esigenza di assicurare una descrizione formale delle API/servizi che, attraverso l’utilizzo di interfacce description language, permetta di descrivere le interfacce degli stessi in maniera indipendente dal linguaggio di programmazione adottato dall’erogatore e dai fruitori degli stessi. L’attuale stato di evoluzione degli standard tecnologici indicati in precedenza determina la scelta di WSDL per i web service SOAP e OpenAPI v3 per i web service REST.

Governance del modello¶

L’Agenzia per l’Italia Digitale è responsabile delle attività di governance del ModI 2018 con l’obiettivo di definire, condividere ed assicurare l’aggiornamento continuo dei seguenti aspetti:

• l”insieme delle tecnologie che abilitano l’interoperabilità tra le PA, e tra queste e cittadini ed imprese;
• i casi d’uso di interoperabilità;
• i pattern di interoperabilità;
• i profili di interoperabilità;
• il catalogo dei servizi resi disponibili dalle PA.

I progetti che realizzano gli Ecosistemi, previsti nel Piano Triennale per l’Informatica nella PA, si basano sul Modello di Interoperabilità, e possono determinare l’esigenza di nuovi casi d’uso, pattern e profili di interoperabilità che verranno definiti con un approccio collaborativo.

Nel precedente SPCoop, l’uso di servizi/API richiedeva un accordo tra amministrazioni anche tramite la firma di convenzioni bilaterali. Questo non sarà più necessario nel nuovo modello, in cui l’adesione si estrinsicherà nell’atto di registrazione da parte della PA di un’API/servizio nel catalogo. In ottemperanza al principio «once-only» definito nell”EU eGovernment Action Plan 2016-2020 [17], l’erogatore si impegna a fornire l’accesso alle proprie API/servizi a qualunque soggetto registrato ne faccia richiesta [18]. Gli erogatori devono descrivere le loro API/servizi classificando le informazioni scambiate ove possibile collegandole ai vocabolari controllati e a concetti semantici predefiniti, utili anche a determinare l’impatto rispetto ai regolamenti in tema privacy e GDPR, e applicando tag di categoria. Il Catalogo può facilitare questo processo attraverso opportune euristiche.

In virtù degli articoli 12 e 14 del Codice dell’Amministrazione Digitale, AgID è formalmente incaricata della gestione di tutto il catalogo e di garantire il rispetto delle regole suddette e per farlo si avvale della collaborazione di alcuni enti, che vengono indicati come Capofila.

Gli enti Capofila si proporranno per eseguire questo compito su porzioni del catalogo; ci saranno enti che si occupano della gestione di aree geografiche e, allo stesso tempo, enti che si occupano della gestione di particolari aree tematiche.

In prima istanza si prevede che gli enti Capofila possano essere:

• a livello territoriale, le Regioni (e.g., la Regione per conto delle ASL regionali)
• a livello di ecosistema, gli enti individuati dai GdL descritti nel Piano Triennale al capitolo 6 Ecosistemi.

A tal fine, sul fronte delle aree tematiche il Piano Triennale 2017-2019 introduce:

• gli Ecosistemi [19], settori o aree di intervento in cui si svolge l’azione delle PA, che raggruppano i vari enti per aree tematiche;
• i Gruppi di Lavoro [20] che, all’interno degli Ecosistemi, indirizzano il vero e proprio lavoro di standardizzazione coinvolgendo sia tecnici che esperti dei rispettivi domini applicativi.

I Gruppi di Lavoro devono formalizzare le specifiche di dettaglio, attraverso il meccanismo dei profili e dei pattern di interoperabilità, e revisionare periodicamente le specifiche rilasciate.

Il nuovo Modello opera in assenza di elementi centralizzati che mediano l’interazione tra le entità comunicanti (erogatore e fruitore del servizio), pur prevedendo la presenza di un catalogo dei servizi disponibili allo scopo di permettere a tutti i soggetti interessati, pubblici e privati, di acquisire conoscenza dei servizi disponibili e delle loro modalità di erogazione/fruizione.

L’Agenzia per l’Italia Digitale ha il ruolo di:

• recepire le esigenze, anche applicative, delle PA, astrarre tali esigenze ed eventualmente formalizzare i casi d’uso ed i pattern di interoperabilità;
• coordinare il processo di definizione dei profili di interoperabilità;
• rendere disponibile il catalogo, attraverso un’interfaccia di accesso unica per permettere a tutti i soggetti interessati, pubblici e privati, di assumere consapevolezza dei servizi disponibili;
• verificare il rispetto delle regole del Modello di Interoperabilità, quale condizione di accesso al catalogo, e controllare con continuità il rispetto dei requisiti per l’iscrizione al catalogo.

Il concetto di servizio¶

I servizi sono sempre più rilevanti nella nostra vita e nei paesi di tutto il mondo. Il concetto di servizio copre un ampio spettro di aspetti nelle relazioni moderne tra amministrazioni pubbliche, fornitori privati e utenti finali.

Introduciamo il concetto di servizio [1] così come intuitivamente percepito nella vita quotidiana. Interagiamo ogni giorno con le persone e le imprese per soddisfare i nostri bisogni, facendo uso di transazioni, ad esempio di tipo economico in cui, dato un pagamento, possiamo acquisire un bene, o utilizziamo un bene che non è nostro, per raggiungere un obiettivo. Nel secondo caso stiamo parlando dell’uso di un servizio. Ad esempio, quando compriamo un biglietto ferroviario Milano-Roma, stiamo utilizzando un bene non nostro (il treno) per soddisfare la nostra necessità di mobilità. Arrivati a Roma, il nostro bisogno è soddisfatto e nulla ci rimane per l’uso, in termini di possesso del bene (il treno) utilizzato.

Un servizio consiste quindi in un’attività, o in una serie di attività, di natura più o meno intangibile, che si svolgono in uno scambio tra un fornitore e un cliente, in cui l’oggetto della transazione è un bene immateriale.

I servizi sono espletati in un sistema di servizi. Un ecosistema di servizi è l’insieme delle regole, delle componenti sociali, delle organizzazioni, dei processi, delle risorse umane, dei materiali e delle tecnologie che nella società coincidono con la produzione e l’uso dei servizi. Un sistema di servizi è caratterizzato da tre tipi di utenti finali: cittadini, imprese e l’ambiente circostante. Vari tipi di produttori forniscono servizi; e per questo verranno indicati più in generale come erogatori di servizi.

Per fornire servizi, gli erogatori devono eseguire una serie di attività, indicate come processi di servizio. Un processo di servizio è un insieme di attività la cui esecuzione, in base a un determinato flusso di controllo, produce in uscita un servizio fornito a un utente che ne ha bisogno. Se, ad esempio, vogliamo prenotare e beneficiare di un viaggio in treno, la prenotazione e l’acquisizione di un biglietto sono la prima fase del processo corrispondente, che avviene presso un’agenzia di viaggi o, sempre più spesso, attraverso Internet. La seconda fase è il momento del viaggio, in cui sono coinvolte risorse quali il treno che ci trasporta, il materiale rotabile, il personale a bordo, il personale nelle stazioni. Nell’esecuzione del processo di servizio, ci sono delle interazioni tra il cliente e l’erogatore; tali interazioni, dal punto di vista del cliente, sono percepite come operazioni a sua disposizione, con cui è possibile richiedere e modificare aspetti specifici del servizio. Nell’esempio del servizio di trasporto ferroviario, le operazioni sono quelle che permettono al cliente di acquisire un biglietto, modificare la prenotazione (modifica del posto, del giorno, ecc.), accedere al treno, ecc. La granularità delle operazioni offerte al cliente dipende dall’erogatore dal processo di servizio che viene messo in atto per espletare il servizio.

La PA, in tutto il mondo, è fornitrice di una vasta gamma di servizi. Le differenze tra PA ed erogatori privati sono molteplici. Soprattutto, la fornitura di servizi è un obbligo legale per la PA.

Ad esempio, in Italia, sulla base di una legge emanata nel 1950, i Comuni sono responsabili dei registri della popolazione residente. Pertanto, se un cittadino ha bisogno di un certificato di residenza, deve andare al comune, che è responsabile per la validità e la correttezza delle informazioni che contiene il certificato. I fornitori privati forniscono servizi in base alla convenienza economica. Secondo il contesto, i prezzi dei servizi sono generalmente regolati nella PA da leggi, decreti o direttive che mantengono nella società una forma di equità sociale. A volte la PA fornisce servizi gratuitamente, mentre di fatto li finanzia attraverso le tasse. I fornitori privati forniscono servizi a pagamento e le entrate sono la ragione della loro attività come azienda. Infine, la PA nella pianificazione della produzione e della fornitura di servizi si ispira a criteri che tengono conto delle esigenze delle comunità, ed è quindi ispirata da una visione sociale, mentre le società private sono indirizzate dal mercato.

Il concetto di servizio include una grande quantità di aspetti. Di conseguenza, è necessario determinare il perimetro di osservazione del concetto di servizio nella PA, il dominio considerato nel Modello di Interoperabilità. Delineiamo nel seguito diverse classificazioni di servizi.

1. Classificazione in base alla natura del fornitore di servizi. In questo caso, abbiamo:

   1. servizi amministrativi (o abilitanti), la cui fornitura non ha carattere discrezionale da parte della PA, in quanto derivano da procedimenti amministrativi definiti dalla legge;
   2. servizi che chiamiamo orientati al mercato o facilitanti, che la PA può decidere o meno di fornire, in base alla presenza di un obbligo procedurale, e che sono più spesso erogati da fornitori privati del mercato dei servizi.

   I servizi amministrativi forniti dalla PA sono di primario interesse, ma è anche importante attirare l’attenzione su servizi orientati al mercato, che sono parte delle aspettative e dei bisogni degli utenti e potrebbero essere forniti da soggetti pubblici o privati.

2. Classificazione in base alla natura finale del servizio prodotto. In questo caso, abbiamo:

   1. servizi che rispondono alle esigenze degli utenti che modificano il loro stato. Verranno indicati come servizi che modificano lo stato (dell’utente e/o del mondo) o semplicemente servizi;
   2. servizi il cui scopo è quello di fornire informazioni e/o conoscenze che l’utente non possiede e che sono utili per un’attività operativa o un processo decisionale. Verranno indicati come servizi informativi o semplicemente informazioni.

   Un esempio della prima categoria è la fornitura di una licenza commerciale che consente a un’azienda di vendere la propria merce; questo servizio modifica lo stato dell’azienda perché consente una nuova attività commerciale. Un esempio di servizio informativo è l’informazione resa disponibile sugli orari di apertura di un laboratorio, che non cambia lo stato del soggetto che ha richiesto l’informazione, ma gli dà la possibilità di intraprendere un’azione o di prendere una decisione per andarci.

3. Classificazione in base al consumatore. In questo caso, possiamo distinguere tra:

   1. servizi esterni, quando il servizio è focalizzato al di fuori della PA, verso la comunità di cittadini e imprese;
   2. servizi interni, quando il servizio è dedicato agli utenti interni all’organizzazione erogatrice, sia essa PA che erogatore di servizi privato.

Oltre ai servizi, sappiamo che altri tipi di oggetti coinvolti nelle transazioni sono beni e informazioni; abbiamo visto che l’informazione può essere vista come un tipo specifico di servizio, quindi non c’è una chiara distinzione tra servizi e informazioni, nel senso che entrambi i tipi di concetti appartengono a un concetto di servizio più generale. Allo stesso modo, tra prodotti e servizi non è possibile distinguere una linea precisa.

Consideriamo il caso in cui dobbiamo viaggiare in India, e il nostro obiettivo immediato è ottenere un visto per l’India; contattiamo due agenzie che, quando richiesto per le condizioni che applicano per fornire il visto, rispondono come mostrato nella tabella seguente:

Guardando le due specifiche, il nostro obiettivo ora è fornire loro una struttura, distinguendo le diverse parti che hanno ruoli diversi.

Possiamo identificare i tipi di proprietà:

• proprietà funzionale, che esprime «cosa» otteniamo dal servizio;
• qualità del servizio, riferito a caratteristiche (ad es., tempo di consegna) che specificano vantaggi o utilità percepita, associati al servizio;
• proprietà non funzionali, esprimendo «come» il servizio ci viene consegnato.

La tabella seguente mostra la classificazione delle proprietà applicate all’esempio di cui sopra:

Le proprietà funzionali di un servizio descrivono cosa fa il servizio per il cliente. Una proprietà funzionale consente un cambiamento di stato del mondo reale, coerentemente con gli obiettivi espressi dal cliente. Le proprietà non funzionali di un servizio definiscono il modo in cui il servizio esegue le proprietà funzionali. Lo schema dei dati del servizio (talvolta chiamato information model) descrive i tipi di dati che rappresentano lo stato del mondo reale quando il servizio viene eseguito. I servizi possono essere visti come cambiamenti di stato del mondo reale ad un alto livello di astrazione, quindi un modo di descrivere i tipi di dati coinvolti in tali cambiamenti sono gli schemi concettuali, ad esempio diagrammi Entity Relationship o UML Class Diagram.

Quindi l’esempio mostra che i servizi possono essere descritti in termini delle seguenti caratteristiche:

1. un nome;
2. un insieme di proprietà funzionali, le operazioni appunto discusse in precedenza;
3. un insieme di proprietà non funzionali, tra cui quelle relative alla qualità del servizio;
4. uno schema di dati di servizio.

Finora abbiamo introdotto un modello che ci consente di descrivere un singolo servizio. Nei nostri eventi della vita quotidiana, per raggiungere i nostri obiettivi, abbiamo bisogno di invocare un numero elevato di servizi, facendo riferimento a un numero elevato di proprietà funzionali (operazioni). Consideriamo cosa accade in corrispondenza a un cambio di indirizzo di abitazione. Quando cambiamo il nostro indirizzo di casa, dobbiamo scegliere un nuovo medico, un nuovo fornitore di elettricità e acqua, dobbiamo cambiare il nostro indirizzo nella patente di guida, ecc. Inoltre, la procedura amministrativa è diversa nel caso in cui ci si trasferisce da un comune ad un altro comune, o se cambiamo il nostro indirizzo a causa della partenza dal nostro paese per andare a vivere all’estero.

I servizi interessati sono ovviamente concettualmente correlati. Ci concentriamo su due relazioni concettuali fondamentali, part-of e is-a. Una relazione part-of vale tra due servizi quando la specifica di uno ha come componente la specifica dell’altro. Nell’esempio, i servizi che (offrono le operazioni che) aggiornano l’indirizzo di casa nella patente di guida, scelgono il nuovo medico e scelgono il nuovo fornitore di energia elettrica, sono tutti legati al servizio «cambio di indirizzo di casa». Diciamo che «cambio di indirizzo di casa» è un servizio composito, e i quattro servizi part-of con esso sono servizi elementari. Un servizio è elementare quando non siamo interessati a rappresentarlo ulteriormente in termini di componenti più atomici.

Fondamentalmente, un servizio è elementare se e solo se non esiste un altro servizio con una relazione part-of con esso, altrimento è un servizio composito.

Il costrutto part-of, pur essendo efficace nel relazionare servizi elementari e compositi, non ci aiuta ad esprimere la relazione esistente tra i diversi tipi di servizi relativi al «cambio di indirizzo di casa» nei diversi contesti in cui si applicano. Abbiamo bisogno per questo scopo di un nuovo costrutto. Una relazione is-a vale tra un servizio s_i (servizio figlio/specifico) e un servizio s_j (servizio padre/generale) quando s_i è una specializzazione (caso specifico) di s_j. Secondo la proprietà di ereditarietà dell”is-a, s_i eredita tutte le proprietà (funzionali e non funzionali) di s_j. Inoltre, s_i eredita tutte le relazioni tra s_j e le sue componenti. s_i può avere proprietà aggiuntive, non in s_j. Ad esempio, tre servizi che cambiano indirizzo tra due comuni, cambiano indirizzo tra Italia e estero, e cambiano indirizzo tra due paesi stranieri, possono essere considerati casi specifici del servizio generico di «cambio di residenza». Le caratteristiche comuni a tutti e quattro i servizi sono la necessità di aggiornare due basi di dati, mentre i database specifici cambieranno in base ai luoghi coinvolti nel cambio di indirizzo. Inoltre, quando ci si sposta dall’Italia all’estero, possiamo immaginare che verranno attivate ulteriori procedure amministrative specifiche, ad es., per questioni relative alla cittadinanza.

Concludiamo questa breve introduzione sui servizi, rimarcando che i servizi sono erogati attuando dei processi. Un processo pubblico è un processo che definisce le interazioni tra i partecipanti (nel processo) e le attività che sono visibili al pubblico per ogni partecipante. Un processo privato è un processo che, oltre alle interazioni e alle attività definite nei processi pubblici, definisce le interazioni e le attività interne ai singoli partecipanti.

Servizio digitale, API e Interfaccia di servizio¶

Un servizio digitale (talvolta anche indicato come electronic service o e-service) è un servizio che viene erogato via Internet o in una rete, la fornitura è essenzialmente automatizzata o comporta solo un intervento umano minimo, ed è impossibile da garantire in assenza di tecnologia informatica [2]. Quanto detto per i servizi, vale anche per quelli digitali, essendo questi una specializzazione.

La trasposizione di un servizio in un servizio digitale non si riduce al solo utilizzo di tecnologie informatiche ma, per ottenere la totalità dei vantaggi conseguenti da tale possibilità, richiede la necessità di ridefinire i processi attraverso una riprogettazione degli stessi (Business Process Reengineering, in breve BPR). Il BPR deve, tra le altre, assicurare:

• la formazione degli atti amministrativi direttamente in digitale, per ridurre gli oneri legati alla gestione degli originali analogici;
• superare una visione document-oriented favorendo una visione record-oriented, al fine di agevolare la circolarità delle informazioni in possesso della PA;
• efficientare le azioni realizzate da parte della PA, per razionalizzare le proprie funzioni e compiti;
• mettere al centro dell’azione amministrativa i cittadini ed imprese, per l’attuazione della semplificazione amministrativa.

Nella progettazione di sistemi software, tipicamente si distinguono tre strati logici di funzionalità in comunicazione tra loro:

• logica di presentazione (presentation layer) o front-end (ad es., un’applicazione web, una APP mobile, ecc.), ha il compito di presentare i risultati dell’elaborazione all’utente umano ed inviare le richieste di questi verso la parte centrale/elaborativa del sistema, facendo dunque da interfaccia uomo-macchina;
• logica applicativa (application layer o business layer);
• logica di accesso ai dati (access data layer) o back-end, interroga il database o il sistema legacy [3].

Tale architettura viene poi spesso mappata a livello fisico-infrastrutturale in altrettanti strati fisici (tier) corrispondenti all’unità di computazione su cui risiede lo strato logico. Tali strati sono intesi interagire fra loro secondo le linee generali del paradigma client/server (il presentation layer è cliente della logica applicativa, e questa è cliente del modulo di gestione dei dati) e utilizzando interfacce ben definite. In questo modo, ciascuno dei tre strati può essere modificato o sostituito indipendentemente dagli altri, conferendo scalabilità e manutenibilità al sistema. Nella maggior parte dei casi, si intende anche che i diversi strati fisici (tier) siano distribuiti su diversi nodi di una rete anche eterogenea. Questa architettura di base può anche essere estesa ipotizzando che gli strati siano a loro volta «stratificati»; in questo caso si giungerebbe a una architettura multi-layer/tier.

Nello specifico dei servizi digitali, che appunto vengono erogati su Internet, il presentation layer verso l’utente può essere rappresentato da un Web server e da eventuali contenuti dinamici e statici (es. pagine di scripting che producono HTML visualizzato nel browser dell’utente), oppure da applicazioni mobili (App) che risiedono sul device mobile dell’utente (cellulare, tablet); la logica applicativa corrisponde a una serie di moduli integrati in un server applicativo, ed i dati sono depositati in maniera persistente su un DBMS o su un sistema legacy.

Con application programming interface (in acronimo API) si indica ogni insieme di procedure/funzionalità/operazioni disponibili al programmatore, di solito raggruppate a formare un set di strumenti specifici per l’espletamento di un determinato compito. Spesso con tale termine si intendono le librerie software disponibili in un certo linguaggio di programmazione. Una buona API fornisce una «scatola nera», cioè un livello di astrazione che evita al programmatore di sapere come funziona l’implementazione dell’API ad un livello più basso. Questo permette di ri-progettare o migliorare le funzioni all’interno dell’API senza cambiare il codice che si affida ad essa. Una API che non richiede il pagamento di diritti per il suo accesso ed utilizzo è detta «aperta» (open). La finalità di un’API è di ottenere un’astrazione a più alto livello, di solito tra lo strato sottostante l’API e quello che la utilizza (client).

Per realizzare un servizio digitale, come detto, è necessario progettare e realizzare i tre strati; lo strato di logica applicativa offre la sua API affinchè chi sviluppa lo strato di presentazione all’utente possa utilizzarla come se la logica applicativa fosse una libreria; estendendo, se vari sistemi esportano le proprie logiche applicative come API, la logica di presentazione può utilizzarle insieme, mischiandole (mash-up), esattamente come nello sviluppo di software moderno si programma riutilizzando le librerie offerte nel linguaggio di programmazione, sistema operativo, ecc. Quando il servizio digitale è erogato su Internet, e prevalentemente sul Web che si basa sul protocollo HTTP,) si parla di Web API. Per le Web API l’erogatore potrebbe decidere di rendere disponibile l’API non soltanto a chi sviluppa la logica di presentazione, ma «aperta» anche ad altre organizzazioni che volessero collaborare con l’erogatore, in questo caso si parla di Open API . In molti contesti, con abuso di nomenclatura, ma intuitivamente chiaro, i due termini vengono confusi e considerati sinonimi (dato che l’apertura è spesso associata al Web/Internet).

Per il W3C un web service è qualsiasi software che si rende disponibile su Internet e standardizza la sua interfaccia tramite la codifica XML [4]. Un client richiama un’operazione offerta da un web service inviando una richiesta (solitamente sotto forma di un messaggio XML) e il web service invia una risposta XML. I web service invocano la comunicazione su una rete, con HTTP come protocollo più comune. I web service si basano principalmente su standard come XML-RPC e SOAP (Simple Object Access Protocol). Quindi un web service è un possibile modo di realizzare una Web API. Il termine web service (originatosi intorno ai primi anni 2000) è nato proprio per indicare la logica applicativa, esposta sul web, sottostante ad un servizio digitale. A partire dalla seconda metà degli anni 2000, creando possibili confusioni, il termine Web API è stato utilizzato come alternativa a web service per indicare altri approcci/protocolli/tecnologie (come REST) per realizzare API senza utilizzare XML-RPC e SOAP. Ma anche una Web API indica la logica applicativa, esposta sul web, sottostante ad un servizio digitale.

Al fine di evitare ogni possibile ambiguità, spesso dovuta semplicemente all’utilizzo di termini differenti per indicare gli stessi concetti, nel seguito del documento si utilizza il termine interfaccia di servizio per indicare l’esposizione delle funzionalità applicative che sono necessarie per realizzare un servizio digitale. Tutte le classificazioni e considerazioni presentate per i servizi, valgono per i servizi digitali e quindi per le interfacce di servizio. In particolare come queste classificazioni e considerazioni si calano in specifiche tecnologie/protocolli/standard è uno degli obiettivi del presente documento. Un’interfaccia di servizio si compone in generale di varie operazioni, e può essere realizzata come un web service, un’API, una Web API, ecc.

Nel prosieguo di questo documento, ci si focalizza solamente sulle interfacce di servizio, che sono il fondamento del Modello di Interoperabilità 2018.

Caratteristiche delle interfacce di servizio¶

Interfacce semplici e complesse In prima istanza, le interfacce di servizio possono essere distinte in due categorie: semplici e complesse.

Una interfaccia di servizio semplice implementa operazioni atomiche come ad esempio:

• Fornire contenuti puri, ad esempio informazioni dettagliate riguardo una risorsa (come le informazioni fiscali riguardanti una azienda) oppure le notizie del giorno;
• Effettuare una aggregazione semplice di informazioni provenienti da diversi sistemi back-end;
• Effettuare operazioni con effetti circoscritti ad un unico sistema di back-end in maniera atomica (che non richieda supporto alle transazioni).

Le interfacce di servizio semplici eseguono unità di lavoro atomiche che lasciano i sistemi sottostanti in uno stato consistente. Le operazioni non necessitano del mantenimento di uno stato tra una chiamata e l’altra e perciò sono anche note come interfacce di servizio stateless (senza stato). Si noti come il concetto di stato sia espresso in relazione all’interazione tra i due sistemi (client ed erogatore) e non alla persistenza di informazioni circa le risorse di interesse.

Le interfacce di servizio complesse coinvolgono l’utilizzo e la composizione di altre interfacce di servizio (in alcuni casi esposte da organizzazioni diverse) richiedendo il supporto all’esecuzione di processi e funzionalità di tipo transazionale. Questo significa che, rispetto alle interfacce di servizio semplici, in quelle complesse le operazioni hanno una granularità alta (meno fine) e richiedono il mantenimento di uno stato condiviso; per questo motivo vengono anche definite interfacce di servizio stateful (con stato). Concetti potenzialmente connessi a quello di stato sono il mantenimento di una sessione o conversazione.

Interfacce sincrone ed asincrone Un altro modo di classificare le interfacce di servizio è lo stile di interazione richiesto dalle diverse operazioni disponibili: sincrono (eg. di tipo Remote Procedure Call - RPC, chiamata remota a procedura) o asincrono (eg. basato sullo scambio di messaggi o documenti). Nelle operazioni sincrone, un client esprime la sua richiesta nella forma di una chiamata ed attende una risposta prima di continuare l’esecuzione. Nelle operazioni asincrone, invece, il client invia un documento/messaggio ma non si aspetta nessuna risposta (se non in alcuni casi il fatto che la richiesta è stata presa in carico). La risposta da parte dell’interfaccia di servizio, nei casi in cui ci sia, può apparire ore o anche giorni più tardi.

Interfacce semplici e mission-critical Un modo ulteriore di classificare le interfacce di servizio è quello di distinguere quelle sostituibili da quelle mission-critical. Una interfaccia di servizio sostituibile può essere fornita da diverse organizzazioni e la produttività è impattata in maniera limitata nel caso di disservizi. Una interfaccia di servizio mission-critical è invece di solito fornita da un’unica organizzazione e la indisponibilità della stesso può provocare dei forti disservizi.

Caratteristiche funzionali e non funzionali delle interfacce Le classificazioni introdotte non sono strette poiché a seconda delle operazioni fornite, una interfaccia di servizio può essere catalogata in una posizione qualsiasi tra i due estremi delle stesse.

Le interfacce di servizio devono essere accompagnate da una descrizione delle operazioni offerte il cui linguaggio dipende dalla tecnologia con cui l’interfaccia è implementata (si veda a partire dalla Sezione 3 per maggiori dettagli). La descrizione di una interfaccia di servizio di solito include caratteristiche funzionali e non funzionali. La descrizione funzionale si concentra sulle caratteristiche operative dell’interfaccia di servizio che descrivono il funzionamento in termini di operazioni offerte, i parametri richiesti da ognuna, gli `endpoint [5] da utilizzare, il formato dei messaggi ed i protocolli di rete da utilizzare. La descrizione non funzionale si concentra invece sulla qualità del servizio (o qualità dell’interfaccia di servizio) in termini di limiti di utilizzo, costi e metriche di performance quali scalabilità, disponibilità, tempo di risposta, accuratezza, transazionalità, sicurezza e affidabilità.

Qualità del servizio¶

Il concetto di quality of service - QoS, fa riferimento alla descrizione non funzionale di una interfaccia servizio, cioè la capacità di una interfaccia di servizio di soddisfare le aspettative dei fruitori. Assicurare la QoS nell’ambito Internet e quindi ai fini dell’interoperabilità è una sfida critica a causa della natura dinamica ed impredicibile del contesto applicativo. Cambiamenti negli schemi di traffico, la presenza di transazioni business-critical, gli effetti dei problemi di rete, le performance dei protocolli e degli standard di rete richiedono una definizione precisa della QoS offerta da una interfaccia di servizio.

Gli elementi chiave a supporto della QoS possono essere riassunti come segue:

• Disponibilità. La probabilità che una interfaccia di servizio sia disponibile e funzionante in un istante casuale. Associato al concetto di disponibilità è quello di Time-To-Repair (TTR), cioè il tempo necessario a ripristinare una interfaccia di servizio una volta che questa diventa indisponibile. La disponibilità di una interfaccia di servizio dovrebbe potere essere verificata tramite l’esposizione di un’altra interfaccia di servizio di monitoraggio, dedicata ed a basso impatto (e quindi ad elevata disponibilità).
• Accessibilità. Misura la capacità di una interfaccia di servizio di essere contattabile da un elevato numero di richieste.
• Prestazioni. Le prestazioni vengono misurate solitamente rispetto a due valori: il throughput e la latenza. Il throughput rappresenta il numero di richieste soddisfatte in un dato intervallo. La latenza rappresenta la quantità di tempo che passa tra l’invio di una richiesta e la ricezione di una risposta. Una interfaccia di servizio con buone prestazioni ha un elevato throughput ed una bassa latenza.
• Affidabilità. Rappresenta la capacità di una interfaccia di servizio di funzionare correttamente e consistentemente fornendo la stessa QoS a dispetto di malfunzionamenti di diversa natura. Di solito viene espressa in termini di fallimenti in un dato lasso di tempo.
• Scalabilità. L’abilità di servire in maniera consistente le richieste a dispetto di variazioni nel numero delle richieste [6]. È strettamente connesso al concetto di accessibilità, ma qui il concetto fondamentale è il mantenimento delle prestazioni.
• Sicurezza. La sicurezza implica aspetti quali confidenzialità, integrità, autorizzazione ed autenticazione che saranno oggetto della Sezione 2.
• Transazionalità. Ci sono alcuni casi (ad es., interfacce di servizio stateful) in cui è necessario assicurare l’esecuzione transazionale di una operazione. La capacità di una operazione di rispettare questa proprietà è parte della QoS.

Gli erogatori devono prendere tutte le iniziative necessarie a mantenere i requisiti di QoS richiesti dal caso d’uso. Questo include anche l’utilizzo di buone pratiche. Ad esempio, per assicurare prestazioni e scalabilità il risparmio della banda è una condizione fondamentale. Le interfacce di servizio dovrebbero quindi implementare meccanismi di compressione del payload [7] e supportare la paginazione [8].

Quando si utilizzano meccanismi di caching, essi devono essere documentati nelle specifiche delle interfacce di servizio, ed essere conformi alle specifiche RFC-7234 [9].

Questa sezione si è concentrata sul concetto di QoS nel campo delle interfacce di servizio. Misure di QoS possono essere introdotte anche per quanto riguarda i servizi digitali utilizzando metriche introdotte nei campi della Interazione Uomo-Macchina. Queste ultime sono fuori dagli obiettivi di questo documento.

Middleware¶

Con il termine middleware si intende lo strato software che separa le risorse informative dai fruitori delle interfacce di servizio, di fatto permettendo la realizzazione delle interfacce stesse. In tal senso un middleware gestisce la complessità e l’eterogeneità tipica dei sistemi distribuiti. Le risorse informative di cui si parla in questo caso possono essere nel caso più semplice della basi di dati, ma più comunemente includono altre interfacce di servizio (che a loro volta possono essere implementati utilizzando dei middleware) e sistemi legacy a cui il middleware contribuisce a fornire interfacce moderne. A tale fine i middleware forniscono una serie di funzionalità:

• Il supporto a framework per l’esposizione di interfacce di servizio implementati in differenti tecnologie e secondo differenti schemi di interazione. In questo senso essi nascondono agli sviluppatori le complessità legate all’esposizione di interfacce di servizio secondo specifici protocolli di rete.
• Facilitano il riuso di componenti software.
• Forniscono una serie di funzionalità di supporto alla sicurezza dei sistemi informatici che includono autenticazione ed autorizzazione.
• Forniscono funzionalità di scalabilità che sfruttano la distribuzione su risorse hardware.
• Aiutano in generale a soddisfare i requisiti di QoS dichiarati negli SLA.
• Integrano funzionalità utili quali il throttling, logging e caching.

Oltre a mascherare l’eterogeneità dell’hardware, i middleware mirano anche a mascherare l’eterogeneità delle piattaforme software permettendo di sviluppare i diversi componenti del sistema distribuito secondo i linguaggi e framework più adatti.

Attori e Interazioni¶

Come anticipato in «Presentazione del Modello di Interoperabilità 2018», l’obiettivo a tendere è quello di una PA in cui le singole amministrazioni offrono interfacce di servizio, in corrispondenza ai servizi digitali che erogano, e possono a loro volta cooperare attraverso l’invocazione di interfacce di servizio offerte da altre PA.

L’EIF riprende la classificazione delle interazioni possibili in generale in Administration-to-Citizen (A2C), Administration-to-Business (A2B) e Administration-to-Administration (A2A), ulteriormente distinguendo se il fruitore del servizio è un soggetto umano od un modulo software, arrivando quindi a definire le seguenti possibili interazioni:

1. A2A in modalità human-to-machine;
2. A2A in modalità machine-to-machine;
3. A2B in modalità human-to-machine;
4. A2B in modalità machine-to-machine;
5. A2C in modalità human-to-machine.

In base al precedente confronto tra servizio digitale e interfaccia di servizio, la classificazione suddetta deve essere meglio specificata, al fine di individuare i giusti contesti di intervento.

A2A in modalità human-to-machine. In questo caso c’è una interazione tra due amministrazioni, di cui una offre un servizio digitale e l’altra, per il tramite di un suo operatore umano, ne fruisce al fine di espletare le proprie procedure. Ad es., un operatore di un Comune accede ad un servizio digitale dell’Agenzia delle Entrate per verificare la correttezza del codice fiscale. In questo caso, l’interfaccia di servizio viene sollecitata dalla logica di presentazione che l’erogatore offre agli operatori delle altre amministrazioni, ma non c’è un’invocazione diretta (si ricordi che un’interfaccia di servizio viene invocata solamente da altri moduli applicativi client, non è fruibile direttamente da utenti umani)

A2A in modalità machine-to-machine. In questo caso c’è una interazione tra due amministrazioni, in cui una offre un servizio digitale, ed espone una interfaccia di servizio, e l’altra realizza una propria applicazione/sistema/procedura digitale il cui software ha bisogno di invocare l’interfaccia offerta. Ad es., in un Comune viene realizzato un software (che utilizzano gli operatori allo sportello anagrafico) che durante la sua esecuzione invoca l’interfaccia di servizio dell’Agenzia delle Entrate per la verifica del codice fiscale. In questo caso l’interfaccia di servizio dell’erogatore è invocata direttamente dal module software del fruitore.

Va notata una differenza tra le due modalità. Nel primo caso, una esigenza operativa che richieda l’utilizzo di più servizi digitali per essere espletata, prevede l’utilizzo da parte degli operatori di più servizi digitali, e gli utenti hanno il compito di coordinare i vari servizi digitali, eventualmente muovere i dati/risultati da uno all’altro, ecc. Ovvero la composizione dei servizi digitali non può essere automatizzata, ma rimane in carico all’utente che utilizza i servizi digitali. Nel secondo caso, la composizione di servizi digitali può essere invece facilmente realizzata andando a sviluppare un nuovo servizio digitale, che compone le interfacce applicative degli erogatori e realizza la logica di coordinamento, a sua volta possibilmente offerta come interfaccia di servizio composta, al di sopra della quale offrire la logica di presentazione.

A2B in modalità human-to-machine. In questo caso c’è una interazione tra un’impresa ed un’Amministrazione che offre un servizio digitale. L’impresa sfrutta il servizio digitale per il tramite di un suo addetto umano che interagisce con il servizio. Ad es., un addetto di un’azienda accede ad un servizio digitale dell’Agenzia delle Entrate per verificare la correttezza dei codici fiscale.

A2B in modalità machine-to-machine. In questo caso c’è una interazione tra un’impresa ed un’Amministrazione a livello applicativo, ovvero una procedura software di un’impresa richiama le funzionalità offerte da un’interfaccia di servizio erogata da un’Amministrazione.

Tutte le considerazioni fatte sulle interazioni A2A human-to-machine e machine-to-machine si applicano anche a questi casi, fatta salva la trasposizione operatore di un’Amministrazione con addetto di un’azienda.

L’ultimo caso A2C in modalità human-to-machine è quello in cui un cittadino utilizza un servizio digitale erogato da un’Amministrazione.

Un cittadino non interagirà mai con l’interfaccia di servizio erogata, ma sempre con una logica di presentazione che a sua volta invoca, nel caso auspicabile di software progettato in modo stratificato, l’interfaccia di servizio.

Dal punto di vista funzionale (cf. Sezione 1.1) tutte le modalità machine-to-machine sono analoghe: per l’interfaccia di servizio, l’essere invocata da un modulo software è funzionalmente indipendente dalla natura dell’utente che siede di fronte alla logica di presentazione che si attesta su quel modulo (sia esso un operatore di un’altra Amministrazione o di un’azienda). La differenza è negli aspetti non funzionali, in particolare QoS e sicurezza, in quanto a seconda di chi è l’organizzazione fruitrice, l’erogatore potrebbe offrire differenti livelli di servizio, autorizzazioni, garanzie di sicurezza, ecc. L’utilizzo che il fruitore farà dell’interfaccia di servizio ha un impatto, soprattutto in termini di responsabilità, framework legale, ecc.; ad esempio, nel caso A2B, il caso in cui l’azienda fruitrice utilizza l’interfaccia all’interno di un proprio modulo applicativo, ovvero il caso in cui offre un servizio a valore aggiunto, devono essere differenziati; ma questo non ha impatti sugli aspetti tecnologici dell’interfaccia di servizio, bensì su quelli di governance, e verranno ripresi in «Governance del Modello di Interoperabilità». Tutti i casi human-to-machine sono analoghi: in questo caso non c’è interazione diretta con l’interfaccia di servizio, ma sempre per il tramite di una qualche logica di presentazione e la differenza è nella natura dell’utente umano che siede di fronte al modulo software che realizza tale logica di presentazione.

Emerge come la modalità di progettazione dei servizi digitali che stratifica chiaramente le interfacce di servizio separandole dalle logiche di presentazione, è la modalità corretta per supportare le possibili interazioni offerte da un’Amministrazione: a seconda della modalità diventa agevole stratificare la corretta logica di presentazione, ovvero moduli client, al di sopra della stessa interfaccia di servizio.

La tabella seguente riassume le considerazioni presentate.

Uniformità dei dati¶

Uno degli aspetti maggiormente critici quando si espongono interfacce di servizio è la modellazione dei dati. Come anticipato nella Sezione 1.1, l’information model sottostante ad un servizio (e quindi anche ad un servizio digitale e interfaccia di servizio) serve a rappresentare sia il modello dei dati relativo ai cambiamenti di stato che il servizio opera, sia i dati che «transitano» (input/output) attraverso il servizio. Nel seguito ci soffermiamo sul caso delle interfacce di servizio. Facendo un parallelo con la programmazione orientata agli oggetti, oltre a definire i metodi offerti dalle classi del programma (nel parallelo corrispondenti alle operazioni dell’interfaccia di servizio), bisogna definire correttamente il numero e soprattutto il tipo dei parametri di input ed output. Non a caso, l’aspetto metodologico cruciale su cui si soffermano tutte le metodologie di progettazione e programmazione basate sul design-by-contract [13] è la definizione della segnatura dei metodi, al giusto livello di granularità, che comprende sia il nome del metodo che i parametri.

Il livello di granularità dipende da vari aspetti dell’interfaccia di servizio, in particolare se questa è atomica o composta, se il servizio a cui corrisponde è informativo o transazionale (cf. Sezione 1.1). Nella tabella seguente si forniscono delle indicazioni qualitative, da utilizzare come linee guida nella definizione delle interfacce di servizio. In «Profili e pattern di interoperabilità», esse saranno utilizzate nella definizione di vari possibili pattern che rispondono ad esigenze specifiche.

Per quanto riguarda gli aspetti di formato dei dati delle interfacce di servizio, è importante

• omologare ove possibile i nomi delle variabili alle consuetudini europee abilitando l’interoperabilità con i servizi erogati dagli altri paesi;
• associare ai nomi dei campi dei metadati utili alla classificazione dei servizi;
• facilitare la validazione automatica delle specifiche dei vari servizi [15].

Inoltre è auspicabile che la specifica del formato sia coerente, od addirittura la stessa, tra varie tecnologie di esposizione delle interfacce di servizio [16].

Le indicazioni generali sono:

• per gli schemi dei dati, utilizzo di nomi basati su riferimenti europei (ad es., Core Vocabularies/Dizionari Controllati, Direttiva Europea INSPIRE 2007/2/CE [17]) e standard de facto e de iure eventualmente disponibili sulla specifica tematica;
• UTF-8 come codifica di default [18];
• URI come identificatore del servizio e dell’erogatore [19];
• per i formati di serializzazione, semplicità di integrazione con strumenti di validazione (ad es. parsing);
• paesi, lingue e monete [20]: ISO 3166-1-alpha2 country [21], ISO 4217 currency codes [22];
• data e ora in RFC3339 [23], un sottoinsieme dell’ISO8601 ottimizzato per il web;
• aree amministrative NUTS 1 e successive: nomenclature NUTS [24] (per il livello NUTS 0 - entità nazionali si fa riferimento ai codici ISO).

Meccanismi di base¶

Diversi sono i concetti chiave dietro al mondo della sicurezza. In origine il termine faceva riferimento al concetto di triade CIA (Confidenzialità, Integrità e Availability - Disponibilità). Nel tempo altri concetti si sono aggiunti quali l’autenticazione e il non ripudio.

Questa sezione descrive questi concetti introducendo le principali tecniche impiegate per assicurarli.

Minacce alla sicurezza dei sistemi informatici¶

Nelle sezioni precedenti alcune minacce alla sicurezza sono state accennate. In questa sezione approfondiamo le diverse tipologie di attacchi. Non ci soffermeremo sugli attacchi basati su malware, ma ci limiteremo agli attacchi basati sull’uso dei protocolli di rete. I tipi di attacchi più comuni sono i seguenti:

• Eavesdropping. E” un tipo di attacco passivo (senza modifica dei dati) in cui un attaccante riesce a rubare informazioni leggendo dati da una connessione non cifrata. I protocolli che assicurano confidenzialità difendono da questo tipo di attacco.
• Modifica dei dati. Un attaccante potrebbe riuscire a modificare i pacchetti in transito nella rete. I meccanismi di firma digitale difendono da questo tipo di attacco.
• Identity spoofing. In questo tipo di attacco, l’attaccante finge di essere un altro utente. Questo tipo di attacco è risolto mediante meccanismi di autenticazione.
• Attacchi su base password. In questo caso l’attaccante cerca di ottenere delle password, utilizzate ad esempio ai fini di autenticazione ed autorizzazione. Come già anticipato, gli attacchi basati su password si basano o su forza bruta oppure su metodi di tipo dizionario. Questo tipo di attacchi si evitano impostato politiche forti riguardo alle password utilizzate e metodi di autenticazione forte (a più fattori).
• Denial of service - DoS. In questo tipo di attacco l’attaccante mira a rendere non operativa una interfaccia di servizio inondandola di richieste e minandone quindi l’accessibilità. Difendersi da questi tipi di attacchi è in genere molto difficile (specialmente nella variante distribuita DDoS).
• Attacchi man-in-the-middle. In questo caso un attaccante si intromette come terza parte in una conversazione tra mittente e destinatario modificando i messaggi scambiati. Gli attacchi man-in-the-middle si combattono tramite tecniche di cifratura ed integrità degli scambi.

In alcuni casi, gli attaccanti possono sfruttare delle falle scoperte nei protocolli o nelle implementazioni. E” quindi di fondamentale importanza tenere aggiornati i sistemi ed utilizzare quando possibile versioni aggiornate dei protocolli.

Protocolli per autenticazione e autorizzazione¶

Nel caso di autenticazione ed autorizzazione, occorre distinguere gli approcci utilizzati nello scenario human-to-machine e quelli utilizzati nello scenario machine-to-machine. I protocolli più comuni in ambito Web per autenticazione ed autorizzazione nel caso human-to-machine sono:

• OAuth2 [26] è uno standard per l’autorizzazione;
• OpenID [27] è uno standard pensato per la sola autenticazione. L’ultima versione, denominata OpenID Connect [28], è costruita su OAuth2 in termini di scambio di messaggi;
• Security Assertion Markup Language - SAML [29] (la versione corrente è la 2) è il protocollo più vecchio in circolazione e copre l’autenticazione e in parte l’autorizzazione;
• eXtensible Access Control Markup Language - XACML [30] complementare a SAML per la gestione esaustiva degli aspetti di autorizzazione.

Nei protocolli human-to-machine, un client riceve autorizzazioni ad usare un certo tipo di risorsa per conto di un utente umano tramite le credenziali di quest’ultimo. La richiesta del token/assertion è effettuate per mezzo di uno user-agent (cioè un browser o una app mobile) che funge da intermediario.

Il ModI 2018 obbliga all’utilizzo di SPID per l’autenticazione human-to-machine o degli altri metodi indicati nell”art. 64 del Codice per l’Amministrazione Digitale [31] che includono anche la Carta d’Identità Elettronica - CIE e la Carta Nazionale dei Servizi - CNS.

SPID [32] è attualmente basato su SAML ma il supporto per OpenID Connect è in fase di definizione al fine di supportare in maniera più semplice l’autenticazione da piattaforme mobili.

In questo senso vale la pena esplorare le differenze principali tra SAML ed OpenID Connect (in breve Connect). Dal punto di vista della terminologia i due protocolli utilizzano termini differenti per gli stessi componenti:

• Identity Provider (SAML) o OpenID Provider (Connect) sono le entità che certificano l’identità dell’utente;
• Service Provider (SAML) o Relying Party (Connect) sono le interfacce di servizio, le app mobili o i siti presso cui l’utente vuole autenticarsi;
• Asserzioni (SAML) o Token (Connect) sono dei documenti firmati dall’Identity Provider (SAML) o dall’OpenID Provider (Connect) che contengono le informazioni circa l’utente identificato e le autorizzazioni che possiede.

La tabella seguente riassume le caratteristiche dei protocolli per l’interazione human-to-machine:

Uno scenario interessante nell’ambito dell’integrazione A2A e A2B è quello legato alla federazione di domini (ad es., due diverse amministrazioni) in cui alcuni utenti di un dominio devono essere autenticati ed autorizzati per accedere a risorse dell’altro dominio (una federazione può includere anche più di due domini). In ambito SOAP, gli standard più utilizzati sono WS-Federation [35] & WS-Trust [36] (vedi Sezione 3 per l’inquadramento nello stack WS-*). Soluzioni su altre tecnologie vengono sviluppate ad-hoc.

Per quanto riguarda lo scenario machine-to-machine invece, come si vedrà nella sezione 2.4, l’autenticazione può avvenire a livello di trasporto utilizzando TLS.

Per quanto riguarda l’autorizzazione machine-to-machine invece è possibile utilizzare il protocollo OAuth2 nello specifico del flusso Client Credential Grant [37]. Tale flusso a differenza di quello standard non richiede la presenza di uno user-agent. Il client possiede invece delle proprie credenziali che vengono utilizzate per richiedere il token all’authorization server.

Protocolli per integrità e confidenzialità¶

Per ragioni storiche lo stack TCP/IP non ha di base funzionalità di sicurezza. I messaggi viaggiano in chiaro sulla rete. Poiché le tecnologie per l’integrazione che verranno introdotte utilizzano HTTP come principale protocollo di trasporto o applicativo [38], è importante che il canale di comunicazione sia protetto. La IETF definisce come standard per la securizzazione di TCP il protocollo Transport Layer Security - TLS. Con il termine HTTPS si definisce l’utilizzo di HTTP su canale TLS. Tutti le interfacce di servizio esposte nel ModI 2018 devono essere basate su HTTPS. Il protocollo TLS (ed il suo predecessore deprecato Secure Sockets Layer - SSL) assicurano su TCP confidenzialità (tramite cifratura) ed integrità (tramite firma digitale e PKI). Come introdotto in Sezione 2.1.5, il meccanismo di firma digitale assicura anche autenticazione ma questa è fatta machine-to-machine.

Il protocollo TLS (versione stabile corrente 1.2, draft 1.3 presentato a Marzo 2018) si basa come detto sull’utilizzo della firma digitale per lo scambio di una chiave di sessione da utilizzare come chiave simmetrica.

Per quanto riguarda i singoli algoritmi utilizzati:

• Per lo scambio della chiave di sessione, TLS supporta numerose tecniche. Tra quelle proposte, si impone l’uso di tecniche che evitano attacchi man-in-the-middle e forniscono la cosiddetta forward security (cioè che la scoperta di una chiave privata usata nello scambio non permette di scoprire la chiave di sessione). Gli algoritmi di scambio delle chiavi permessi sono quindi ephemeral Diffie–Hellman - DHE ed ephemeral Elliptic Curve

Diffie–Hellman - ECDHE.

• Per la cifratura TLS supporta numerosi algoritmi. Si suggeriscono i protocolli attualmente supportati nello standard TLS 1.3 e che sono considerati sicuri: Advanced Encryption Standard - AES (nella versioni GCM e CCM).
• Per l’integrità si suggerisce l’uso SHA almeno a 256 bit (quindi a partire dal cosiddetto SHA-2).

Numerose sono le minacce alla sicurezza a cui è esposto TLS (in special modo con vecchie versioni del protocollo accoppiate ad algoritmi per cifratura ed integrità vulnerabili). L’IETF nel 2015 ha rilasciato a riguardo una RFC informativa [43]. Per questo motivo, in determinati scenari che richiedono elevati standard di sicurezza, si aggiunge talvolta un ulteriore strato di sicurezza a livello applicativo.

Nel modello SPCoop si richiedeva che in ogni caso HTTPS fosse utilizzato con autenticazione mutual-TLS (vedi Sezione 2.3). Nel tempo sono emersi scenari di interazione con requisiti di sicurezza inferiori (ad es., solo HTTPS non-mutual-TLS), che non giustificano la complessità di un sistema a mutua autenticazione (ad es., accessi in sola consultazione, applicazioni Web o sistemi IoT [44]) a livello di trasporto. Fermo l’obbligo di usare HTTPS, nasce l’esigenza di venire incontro a diversi scenari e definire per essi modelli di autenticazione e di trust differenziati. Questi aspetti verranno definiti in «Pattern e Profili di Interoperabilità».

Indicazioni di utilizzo¶

La specifica SOAP permette la definizione di specifici profili di interoperabilità, imponendo alcune restrizioni circa i tipi ed i formati scambiati. Il profilo di interoperabilità secondo il quale interfacce di servizio di tipo SOAP andranno implementati è la versione 2.0 del Basic Profile [48] (nel seguito BP2) definito dal WS-I (Web Services Interoperability Organization) ed ora confluito in OASIS. BP2 è basato su SOAP 1.2 e WS-Addressing (per il dispatching dei messaggi a livello applicativo, in particolare nel caso di interazioni asincrone). Tra le molte indicazioni, BP2 definisce anche la modalità di gestione degli errori. In particolare, oltre all’utilizzo dei codici di errore HTTP si richiede che il ricevente sia in grado di gestire le SOAP fault [49] che quindi devono, obbligatoriamente, essere emesse dall’erogatore a fronte di errori.

Sicurezza¶

Per quanto riguarda la sicurezza, l’ultimo profilo standard definito da OASIS è il Basic Security Profile 1.1 [50]. Il profilo è datato ma le considerazioni sono ancora valide. Per quanto riguarda le versioni dei protocolli, si devono rispettare i vincoli imposti dal Modello di Interoperabilità 2018 in questo documento.

E” importante, nel caso si richiedessero funzionalità di autorizzazione, autenticazione e non ripudio, oltre che di riservatezza (coperta dall’utilizzo obbligatorio di HTTPS [51]) fare affidamento alle tecnologie di autenticazione ed autorizzazione a livello applicativo. Il Basic Security Profile 1.1, basato sull’estensione WS-Security, suggerisce l’uso di SAML 2.0. Come detto, rispetto alle tecnologie di autenticazione ed autorizzazione, ci sono alcuni domini applicativi per i quali OAuth2 o OpenId sono più appropriati. In questi ultimi casi, fermo restando l’utilizzo della XML Signature definita in WS-Security per quanto riguarda il non ripudio, l’utilizzo di token di autorizzazione ed autenticazione non SAML richiede la definizione di request header custom [52].

Uniformità e naming¶

Non esistono standard riguardanti il naming in ambito SOAP. Le best-practice prevedono l’utilizzo di CamelCase [53] (con prima lettera maiuscola, anche noto come PascalCase) per endpoint, porte, operazioni e parametri.

Quando le risorse contengono link e riferimenti a risorse esterne, si dovrebbero usare le specifiche indicate in IANA registered link relations [54] trasformando il Kebab Case <https://it.wikipedia.org/wiki/Kebab_case> [55] utilizzato con il CamelCase.

Indicazioni di utilizzo¶

L’interfaccia di servizio REST deve utilizzare l’HTTP verb più adatto all’operazione come indicato in RFC 7231 [59]. In particolare i metodi:

• GET, HEAD, DELETE: non devono avere un payload.
• GET, HEAD: devono essere «safe», cioè devono essere essenzialmente read-only. Il client in questo caso non si aspetta e non richiede un cambiamento dello stato della risorsa.
• GET, HEAD, PUT, DELETE: devono essere idempotenti, cioè chiamate multiple con richieste identiche si comportano come singole richieste.
• POST: dovrebbe implementare un meccanismo di idempotenza per evitare di duplicare eventuali entry.

Ove necessario, specialmente ai fini del caching e l’accesso concorrente alle risorse [60], occorre fare leva sugli ETag [61] (degli identificatori univoci di versione delle risorse). Infine l’utilizzo di eventuali header HTTP non deve sostituire i parametri da passare in una GET.

Sicurezza¶

Lo standard di riferimento per la firma e la crittografia in ambito JSON/REST è Javascript Object Signing and Encryption [62] (di seguito JOSE), menzionato nelle Linee Guida AgID [63] ed in «European Telecommunications Standards Institute - Security of the mission critical service» [64]. JOSE è un framework per la sicurezza comprendente diverse componenti tra cui centrale è il JSON Web Token [65] (di seguito JWT). JWT è uno standard per la definizione di token di accesso basato su JSON Web Signature [66] (di seguito JWS)) e JSON Web Encryption [67] (si seguito JWE) di cui eredita ed estende gli header. Il token JWT è passato in REST tramite l’header HTTP Authorization utilizzando lo schema Bearer [68]. Il token in OpenID Connect è espresso per esempio direttamente come JWT.

Per ulteriori dettagli sulla sicurezza, si vedano anche:

• OWASP REST Security Cheat-Sheet [69];
• OWASP API Security Project [70];
• JWS - Security Considerations [71].

Uniformità e Naming¶

In questa sezione introduciamo le best practice da utilizzare per interfacce di servizio REST. In prima istanza, ogni endpoint deve essere univocamente associato alle componenti Scheme, Authority e Path di un URL [72].

La componente Authority dell’URL:

• dovrebbe essere associata al dominio del sito Istituzionale dell’erogatore presente su IndicePA, anche tramite il prefisso «api», ad esempio un erogatore con sito istituzionale «erogatore.gov.it», potrebbe usare come authority «api.erogatore.gov.it»;
• può essere associata al dominio di un ente che l’erogatore ha delegato (ad es., una società in-house, un consorzio di comuni).

Per quanto riguarda la componente Path, i nomi utilizzati non devono usare abbreviazioni e acronimi non universalmente riconosciuti [73]. Inoltre, il Path dovrebbe essere semplice, intuitivo e coerente [74].

Il campo Query dovrebbe:

• essere in snake_case minuscolo;
• non essere in camelCase;
• utilizzare ove possibile dei nomi comuni per le funzionalità di paginazione, ricerca ed embedding/resource-expansion (ad es., limit, offset, q, sort).

Le risposte in formato JSON [75], devono restituire sempre oggetti strutturati con attributi chiave-valore, non semplici liste. Questo permette di estendere facilmente le risposte introducendo in versioni successive ulteriori attributi (ad es., di paginazione).

In caso di errore, le risposte devono usare schemi standard come quello definito nella RFC 7807 - Problem Details for HTTP APIs - IETF Tools [76] in particolare utilizzando il content type application/problem+json nella risposta.

Quando le risorse contengono link e riferimenti a risorse esterne, si dovrebbero usare le specifiche indicate in IANA registered link relations [77].

Tutti i riferimenti dovrebbero contenere URL comprensivi di schema.

Throttling ed indisponibilità del servizio¶

Nelle API basate su REST, meccanismi di throttling vengono implementati al fine di garantire l’accessibilità delle interfacce di servizio ed evitare in alcuni casi la raccolta non autorizzata (web-harvesting_) dei dati.

Poiché l’RFC 6585 prevede per la gestione del throttling il solo status code 429, nel Modl2018 si richiede di notificare al fruitore lo stato del throttling ed eventuali limiti come segue:

• restituire in ogni risposta valida i valori globali di throttling tramite i seguenti header HTTP:

  • X-RateLimit-Limit: limite massimo di richieste per un endpoint;
  • X-RateLimit-Remaining: numero di richieste rimanenti fino al prossimo reset;
  • X-RateLimit-Reset: il numero di secondi mancanti al momento in cui il limite verrà reimpostato.

• utilizzare gli HTTP status code nelle risposte:

  • HTTP 429 (too many requests), insieme ai rate limit di cui al punto precedente, se il rate limit viene superato;
  • HTTP 503 (service unavailable) se l’infrastruttura non può erogare le operazioni offerte nei tempi attesi (definiti dalla SLA associata all’interfaccia di servizio).

• nei casi 429 e 503 gli erogatori dovrebbero notificare al client dopo quanti secondi ripresentarsi tramite l’header Retry-After [78] (pratica anche detta “circuit breaker”), anche implementando meccanismi di exponential back-off. L’RFC prevede che questo header possa essere utilizzato sia in forma di data che di secondi, ma il Modl2018 vieta l’utilizzo del formato data poiché se non implementato correttamente potrebbe aggravare lo stato dei sistemi.

I fruitori dell’interfaccia di servizio devono impegnarsi a rispettare le indicazioni provenienti dagli header ed dagli status code di cui sopra.

Datastore distribuiti¶

L’applicazione di tecnologie per datastore distribuiti è strettamente connessa, in ambito integrazione di sistemi, al mantenimento di database multi-tenant in cui, ad esempio, si richiede data locality per basi di dati di grandi dimensioni. In questo contesto, vanno considerati principalmente i file system ed i database distribuiti.

I file system distribuiti offrono interfacce basate su API per la memorizzazione di file e di oggetti e sono oggigiorno disponibili sia in soluzioni cloud pubbliche sia private. La sicurezza di queste soluzioni è soggetta agli stessi vincoli visti per l’utilizzo di interfacce di servizio nelle sezioni precedenti.

Tra i database distribuiti, grande interesse è stato suscitato da quelli basati su blockchain [93]. L’obiettivo di una blockchain è il mantenimento di un libro mastro distribuito (distributed ledger) mediante una rete peer-to-peer di nodi [94]. L’obiettivo è quello di avere un datastore capace di certificare transazioni e vincoli contrattuali, in cui il meccanismo di distribuzione certifica la validità degli stessi. In particolare, è possibile appurare la validità di smart contract (contratti intelligenti), certificando le precondizioni degli stessi. Il termine contratto spazia dal semplice scambio di denaro, ad es., la piattaforma BitCoin in cui la precondizione all’invio di denaro è il possesso del denaro stesso, a contratti complessi dove le precondizioni possono assumere una qualunque forma. L’integrità dei dati memorizzati è certificata da meccanismi basati su chiave pubblica. La maggior parte dei protocolli disponibili per la realizzazione di blockchain sono basati su scambio di messaggi su TCP/TLS o HTTPS.

In Estonia, il modello X Road [95] (equivalente al ModI 2018) ha promosso l’utilizzo di un ledger distribuito nell’ambito della Pubblica Amministrazione, anche se più a scopo di marketing [96] che per l’utilizzo degli aspetti precipui di una blockchain. Quello che è interessante è l’idea di un tracciamento distribuito delle decisioni prese da una Pubblica Amministrazione.

La tecnologia blockchain non è esente da rischi in quanto diversi tipi di attacco sono stati formulati che permettono la modifica dei contenuti e la creazione di ramificazioni della catena di transazioni alla base del libro mastro [97].

In conclusione, sebbene si tratti di una tecnologia che sta suscitando interesse, attualmente blockchain non sono considerate abbastanza mature per l’utilizzo nella Pubblica Amministrazione in settori strategici e il ModI 2018 ne sconsiglia al momento l’utilizzo. Inoltre deve ancora essere definito il modo di integrare ed interoperare tra PA utilizzando smart contract come interfacce di servizio, e le tipologie di transazioni che effettivamente hanno bisogno di requisiti tali per cui la blockchain sia la giusta soluzione.

L’utilizzo di datastore distribuiti potrebbe in futuro affiancare l’integrazione basata su altre tecnologie più consolidate. Le future linee guida dovranno tenere in considerazione per queste tecnologie:

• requisiti di latenza e consistenza (ad es., eventual consistency, autoritatività);
• le modalità di logging e auditing associate alla trasmissione dei dati;
• le modalità operative di manutenzione;
• la standardizzazione delle interfacce di accesso.

Esposizione di open data¶

Una modalità di integrazione, importante specialmente negli scenari A2B e A2C, è quella basata sull’esposizione da parte delle PA di open data. Gli open data devono essere fruibili, ed essere inseriti ove possibile nel contesto dei Base Register definiti nell”EIF [98], standardizzando gli schemi e le modalità di fruizione.

Vista la progressiva crescita dei dataset, gli open data dovrebbero essere erogati in modo da ridurre gli impatti infrastrutturali sull’erogatore.

Come indicato nelle linee guida nazionali per la valorizzazione del patrimonio informativo pubblico [99] pubblicate da AgID nel 2014, l’obiettivo è quello di mettere a disposizione i dati aperti in formato Linked Open Data - LOD ai fini dell’integrazione, il che prevede l’esposizione di dati in formato W3C RDF e SPARQL (secondo il cosiddetto modello del Semantic Web). A tal fine gli SPARQL endpoint costituiscono le interfacce di servizio. Le query in formato SPARQL vengono inviate su endpoint HTTP. Un altro approccio possibile, sempre nel rispetto dei dizionari comuni, è quello di utilizzare un approccio ROA basato su interfacce REST [100].

Un’interessante evoluzione dell’approccio REST (di cui eredita molti dei vantaggi, quali ad esempio la leggerezza e l’utilizzo dei verbi HTTP) che può risultare utile nell’esposizione di open data è quello basato su GraphQL [101]. In particolare, mentre per l’estrazione di dati complessi l’approccio basato su interfacce di servizio REST richiede diverse chiamate, GraphQL introduce un linguaggio che permette l’esecuzione di interrogazioni complesse sulle risorse.

In tutti i casi presentati, restano valide le indicazioni contenute nelle sezioni precedenti circa la sicurezza nell’esposizione delle interfacce di servizio.