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:

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.

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.

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

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

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

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.

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