Docs Italia beta

Documenti pubblici, digitali.

2.1. Introduzione alle interfacce di servizio

2.1.1. 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:

Obiettivo del servizio Agenzia 1 Agenzia 2
Necessità di un visto per andare in India nella nostra agenzia rilasciamo il visto in 7 giorni, al costo di € 30, e la penalità per un giorno di ritardo è di € 2 nella nostra agenzia facciamo il possibile per rilasciare il visto in 2 settimane, il costo è di € 20

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:

Tipo di proprietà Agenzia 1 Agenzia 2
funzionale rilascio del visto rilascio del visto
qualità del servizio in 7 giorni il possibile in 2 settimane (best effort)
altra non funzionale

prezzo : € 30

penale : € 2 / giorno ritardo

prezzo : € 20

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, altrimenti è 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 si (servizio figlio/specifico) e un servizio sj (servizio padre/generale) quando si è una specializzazione (caso specifico) di sj. Secondo la proprietà di ereditarietà dell”is-a, si eredita tutte le proprietà (funzionali e non funzionali) di sj. Inoltre, si eredita tutte le relazioni tra sj e le sue componenti. si può avere proprietà aggiuntive, non in sj. 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.

2.1.2. 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.

Ogni qualvolta c’è un servizio, si può immaginare che nella moderna spinta all’innovazione, si giunga prima o poi ad una controparte digitale.

Un servizio digitale, se sviluppato seguendo i più moderni approcci di ingegneria del software, deve essere organizzato separando la logica di presentazione da quella applicativa, dove quest’ultima deve esporre le proprie operazioni tramite una interfaccia di servizio. Una interfaccia di servizio è l’esposizione delle funzionalità applicative che sono necessarie per realizzare un servizio digitale; tale esposizione deve essere operata con un approccio/tecnologia/standard che ne permetta l’invocazione da un modulo software client.

Emerge in ultima analisi che ogni qualvolta c’è un servizio digitale, ci può essere una interfaccia di servizio equivalente, e viceversa ogni qualvolta c’è una interfaccia di servizio, è immediato ipotizzare il servizio digitale equivalente.

Una interfaccia di servizio può offrire più operazioni (almeno una). Una interfaccia di servizio può essere realizzata utilizzando approcci/tecnologie/standard web service, API, Web API, REST API, ecc.

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

2.1.3. 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 stessa 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à.

2.1.4. 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.

2.1.4.1. Service Level Agreement - SLA

L’integrazione può coinvolgere numerose organizzazioni e erogatori esterni di interfacce di servizio. Al fine di accordarsi sulla QoS, erogatori di interfacce di servizio e fruitori utilizzano quelli che vengono definiti Service Level Agreement - SLA, ovvero accordi sul livello di servizio. Uno SLA può contenere le parti seguenti:

  • Scopo. Le ragioni che hanno portato alla definizione dello SLA.
  • Parti. I soggetti interessati nello SLA con i loro rispettivi ruoli (ad es., l’erogatore dell’interfaccia di servizio e il fruitore).
  • Periodo di validità. L’intervallo di tempo, espresso mediante data e ora di inizio e data e ora di fine, per il quale si ritiene valido un particolare termine di accordo all’interno dello SLA.
  • Perimetro. Quali sono operazioni interessate dallo specifico SLA.
  • Service Level Objectives - SLO, ovvero obiettivi sul livello di servizio. I singoli termini di accordo all’interno di uno SLA. Di solito vengono definiti utilizzando dei Service Level Indicators - SLI, ovvero indicatori sul livello di servizio, che quantificano i singoli aspetti di QoS come indicato in questa sezione (ad es., disponibilità).
  • Penalità. Le sanzioni che si applicano nel caso che l’erogatore dell’interfaccia di servizio non riesca ad assicurare gli obiettivi specificati nello SLA.
  • Esclusioni. Gli aspetti della QoS non coperti dallo SLA.
  • Amministrazione. I processi mediante i quali le parti possono monitorare la QoS.

Gli SLA possono essere statici o dinamici. Negli SLA dinamici, gli SLO (con associati SLI) variano nel tempo ed i periodi di validità definiscono gli intervalli di validità di questi ultimi (ad es., in orario lavorativo gli SLO possono essere differenti di quelli imposti durante la notte). La misurazione dei livelli di QoS all’interno di uno SLA richiedono il tracciamento delle operazioni effettuate in un contesto infrastrutturale multi-dominio (geografico, tecnologico e applicativo). In uno scenario tipico, ogni interfaccia di servizio può interagire con molteplici altre interfacce di servizio, cambiando il suo ruolo da erogatore a fruitore in alcune interazioni, ognuna governata da un differente SLA.

Recentemente, gli SLA hanno iniziato ad includere non soltanto vincoli relativi all’erogatore, ma anche vincoli che impongono ai singoli fruitori delle interfacce di servizio dei limiti relativi al ritmo ed alla quantità delle richieste. A tal fine gli erogatori devono definire ed esporre ai fruitori politiche di throttling [10] (anche noto come rate limiting) segnalando eventuali limiti raggiunti. Gli erogatori dovrebbero far rispettare le quote anche se se il sistema non è in sovraccarico, incentivando i fruitori a rispettarle.

Esempi di SLI sono i seguenti:

  • dimensione massima di ogni richiesta accettata. Le richieste più grandi possono essere rifiutate;
  • latenza al 90º percentile. Utilizzata per calcolare la responsività;
  • percentuale di minuti negli ultimi 30 gg in cui l’interfaccia di servizio è stata disponibile;
  • valori a 1 giorno e 30 giorni del success rate (ad es., il numero di chiamate terminate con successo rispetto al numero totale di chiamate);
  • percentuale di minuti negli ultimi 30 gg in cui l’interfaccia di servizio è stata responsiva (ad es., il numero di chiamate con latenza inferiore ad un certo limite);
  • tempo di risposta medio delle richieste totali (includendo le richieste rifiutate causa throttling) nell’ultimo giorno e negli ultimi 30 giorni;
  • throughput misurato in bytes/s.

Gli SLI calcolati devono includere la latenza aggiuntiva dovuta ad eventuali componenti infrastrutturali e di rete (ad es., proxy-gateway).

Essi inoltre devono:

  • utilizzare unità di misura del sistema internazionale (ad es., secondi, bytes);
  • indicare nel nome identificativo l’eventuale periodo di aggregazione coi soli suffissi s (secondi), m (minuti), d (giorni) e y (anni) utilizzando al posto dei mesi il numero di giorni.

Ove possibile, gli SLO e gli SLA dovrebbero essere in relazione diretta con i valori associati (ad es., indicare success rate anziché l’error rate), in modo che a valori più alti corrispondano risultati positivi.

2.1.5. 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 delle basi di dati, ma più comunemente includono altre interfacce di servizio (che a loro volta possono essere implementate 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.

2.1.5.1. API Management

Gli API Management System sono dei middleware che concentrano tutte le funzionalità necessarie ad una organizzazione per gestire le loro interfacce di servizio su infrastrutture on-premises e cloud pubblici e privati. Essi si concentrano sullo sviluppo delle interfacce di servizio, la gestione del ciclo di vita delle stesse, il controllo degli accessi (tramite meccanismi di autorizzazione ed autenticazione), il throttling, il caching e le analitiche (utili al controllo degli SLA).

Un API management system può essere utilizzato ad esempio come strato di accesso alle API interne ad una amministrazione, rilasciando solo una parte delle stesse e con politiche personalizzate verso l’esterno e verso l’intranet.

Oltre alle funzionalità richieste nelle sezioni precedenti, alcuni API management system permettono di definire processi di automazione ed orchestrazione di breve durata (dette soft-orchestration). Si tratta di orchestrazioni molto semplici in cui non ci si aspetta intervento umano nel processo, la durata è brevissima e le regole definite sono molto semplici.

2.1.5.2. Logging

Il logging riveste un ruolo fondamentale nella progettazione e sviluppo di interfacce di servizio. Le moderne piattaforme middleware, oltre ad integrare meccanismi di logging interni, possono connettersi ad interfacce di servizio esterne che permettono la raccolta (log collection), la ricerca e la produzione di analitiche utili tra l’altro all’identificazione di problemi e al monitoraggio del sistema e della QoS. L’utilizzo di log collector permette di centralizzare non solo i log relativi all’utilizzo dell’interfaccia di servizio, ma anche quelli di eventuali digital service e componenti di rete (ad es., proxy e application-gateway). I messaggi applicativi possono, ai fini di non ripudio (vedi Sezione 2.1.4) essere memorizzati assieme alla firma digitale e quindi archiviati periodicamente nel rispetto delle direttive sulla privacy.

L’erogatore deve documentare il dettaglio del formato della tracciatura e le modalità di consultazione e reperimento delle informazioni.

L’erogatore deve inoltre tracciare un evento per ogni richiesta, contenente almeno i seguenti parametri minimi:

  • data e ora della richiesta in formato RFC3339 [11] in UTC e con i separatori Z e T maiuscolo. Questa specifica è fondamentale per l’interoperabilità dei sistemi di logging ed auditing, evitando i problemi di transizione all’ora legale e la complessità nella gestione delle timezone nell’ottica dell’interoperabilità con altre PA europee;
  • URI che identifica erogatore ed operazione richiesta;
  • tipologia di chiamata (ad es., HTTP method per i protocolli basati su HTTP, basic.publish per AMQP);
  • esito della chiamata (ad es., HTTP status per i protocolli basati su HTTP, SOAP fault nel caso di web services SOAP, OK/KO in assenza di specifici requisiti, eventuali messaggi di errore);
  • identificativo del fruitore;
  • ove applicabile, identificativo del consumatore o altro soggetto operante la richiesta comunicato dal fruitore - è cura del fruitore procedere a codifica e anonimizzazione ove necessario;
  • ove applicabile, l’Indirizzo IP del client;
  • ove applicabile, un identificativo univoco della richiesta, utile ad eventuali correlazioni tra chiamate diverse.

2.1.6. 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 modulo 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 fiscali.

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.

Interazione servizio digitale interfaccia di servizio richiede logica di presentazione composizione di più servizi [12]
A2A human-to-machine   -
A2A machine-to-machine     +
A2B human-to-machine   -
A2B machine-to-machine     +
A2C   -

2.1.7. 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.

Tipo di interfaccia Granularità [14]
Elementare fine-grained
Composta coarse-grained
Informativa fine-grained
Transazionale coarse-grained

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).
[1]La trattazione si basa in parte su C. Batini, M. Castelli, M. Comerio, M. Cremaschi, L. Iaquinta, A. Torsello, G. Viscusi (2015): The Smart methodology for the life cycle of services. Cf. https://boa.unimib.it/retrieve/handle/10281/98632/144883/SmartBook-0315.pdf
[2]Cf. Wikipedia, https://en.wikipedia.org/wiki/E-services] Rowley (Rowley J. (2006): An analysis of the e-service literature: towards a research agenda. Internet Research, 16 (3), 339-359) defines e-services as » […] deeds, efforts or performances whose delivery is mediated by information technology. Such e-service includes the service element of e-tailing, customer support, and service delivery». This definition reflect three main components - service provider, service receiver and the channels of service delivery (i.e., technology). For example, as concerned to public e-service, public agencies are the service provider and citizens as well as businesses are the service receiver. The channel of service delivery is the third requirement of e-service. Internet is the main channel of e-service delivery while other classic channels (e.g. telephone, call center, public kiosk, mobile phone, television) are also considered. […] The provision of services via the Internet (the prefix “e” standing for “electronic”, as it does in many other usages), thus e-service may also include e-commerce, although it may also include non-commercial services (online), which is usually provided by the government».
[3]Un sistema legacy (letteralmente «ereditato», che è un lascito del passato) è un sistema informatico, un’applicazione o un componente obsoleto, che continua ad essere usato poiché l’utente (di solito un’organizzazione) non intende o non può rimpiazzarlo. Legacy equivale a versione «retrodatata» (rispetto ai sistemi/tecnologie correnti).
[4]Cf. https://www.w3.org/TR/ws-arch/#whatis
[5]Con il termine endpoint si indica l’identificativo unico da utilizzare per richiamare un’interfaccia di servizio. Ad esempio, nel caso della tecnologia SOAP è l’URL del web service, nel caso di REST le URL (che hanno tutte un suffisso comune) delle risorse offerte, nel caso dei Message Broker il nome univoco della coda di messaggi o un topic nella stessa.
[6]In ambito cloud, si utilizzano i termini di scale-up/scale-down per indicare la scalabilità ottenuta incrementando o riducendo le risorse di singoli sistemi (ad es., memoria RAM), di scale-out/scale-in per indicare la scalabilità ottenuta mediante distribuzione, aggiungendo o diminuendo il numero dei sistemi utilizzati.
[7]Il payload è il contenuto informativo di un messaggio di rete (eliminando la parte relativa al protocollo). Per compressione del payload si intende applicare un algoritmo di compressione (molto spesso gzip) al payload in modo da ridurre il traffico di rete.
[8]Per paginazione si intende la capacità di una operazione nell’interfaccia di servizio di fornire un risultato composto da molte voci per singole pagine sfruttando un qualche criterio di ordinamento.
[9]Cf. https://tools.ietf.org/html/rfc7234
[10]Con il termine throttling (o rate limiting) si intendono le politiche intraprese dalle interfacce di servizio al fine di limitare la frequenza con cui i fruitori possono chiamare l’interfaccia o specifiche operazioni all’interno della stessa.
[11]Cf. https://tools.ietf.org/html/rfc3339#section-5.6
[12]L’uso del +/- nell’ultima colonna dà un’indicazione qualitativa di quanto sia agevole comporre elementi nella specifica interazione. Come discusso, nel caso di servizi digitali la composizione è a cura dell’utente finale, che agisce da human-ware (ovvero deve farsi carico di realizzare, attraverso l’interazione stessa, la logica di composizione ed il passaggio di dati), mentre la composizione di interfacce di servizio è più semplice da automatizzare, e soprattutto può poi essere riusata più volte esponendo a sua volta come interfaccia di servizio composta. In quest’ultimo caso va però realizzata una logica di presentazione per il servizio digitale composta, se si vuole offrirlo agli utenti umani.
[13]

Cf.

Meyer, Bertrand: Design by Contract, Technical Report TR-EI-12/CO, Interactive Software Engineering Inc., 1986

Meyer, Bertrand: Design by Contract, in Advances in Object-Oriented Software Engineering, eds. D. Mandrioli and B. Meyer, Prentice Hall, 1991, pp. 1–50

Meyer, Bertrand: Applying «Design by Contract», in Computer (IEEE), 25, 10, October 1992

Meyer, Bertrand (1997). Object-Oriented Software Construction, second edition. Prentice Hall. ISBN 0-13-629155-4.

[14]La granularità è il livello di dettaglio con cui i dati sono esposti e scambiati. Coarse-grained significa un livello di dettaglio «basso», in quanto molti dettagli possono o devono rimanere interni all’implementazione dell’interfaccia di servizio. Fine-grained significa invece che il dato deve essere specificato ad un dettaglio massimo, poiché il fruitore ha bisogno di una visione puntuale del dato stesso.
[15]Come anticipato in “Presentazione del Modello di Interoperabilità 2018” ed approfondito in “Governance del Modello di Interoperabilità”, la modellazione e specifica dei dati avviene nei Gruppi di Lavoro interni agli Ecosistemi, che indirizzano il lavoro di standardizzazione.
[16]Ad esempio, la serializzazione in JSON di un dato dovrebbe essere la medesima sia se viene esposto esternamente tramite REST API sia se transita da un messaging system interno all’amministrazione. Una rappresentazione opportuna permette quindi la fruizione del dato da sistemi diversi limitando il ricorso alle conversioni.
[17]Cf. https://joinup.ec.europa.eu/page/core-vocabularies e http://eur-lex.europa.eu/legal-content/IT/ALL/?uri=CELEX:32007L0002
[18]Vedi Linee Guida Patrimonio Pubblico. Architettura dell’Informazione del Settore Pubblico, http://lg-patrimonio-pubblico.readthedocs.io/it/latest/arch.html#formati-aperti-per-i-dati-e-documenti
[19]Gli URI vengono utilizzati anche dal gruppo DAF-Semantic per la nomenclatura delle ontologie e dei dataset
[20]Si noti che questi standard sono già usati nelle specifiche AgID sulle firme elettroniche e sul formato della fattura PA.
[21]Cf. https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2
[22]Cf. https://en.wikipedia.org/wiki/ISO_4217
[23]Cf. https://tools.ietf.org/html/rfc3339#section-5.6
[24]Cf. https://it.wikipedia.org/wiki/Nomenclatura_delle_unit%C3%A0_territoriali_statistiche