1.1 Contesto di riferimento¶

Il Piano Nazionale di Ripresa e Resilienza (PNRR) ha posto tra i propri obiettivi il rilancio del settore economico del Turismo. Il Turismo in Italia, infatti, costituisce un’importante fonte di vantaggio competitivo per l’intero paese, rappresentando il 13% del PIL nel 2017 (Banca d’Italia) e contando oltre 500 mila imprese di filiera nel 2019 con oltre 1.9 milioni di addetti (ISTAT). I consumi connessi al turismo nel 2018 sono stati circa 84 miliardi di euro (ISNART). I dati ISTAT hanno registrato, pre-pandemia, arrivi - nazionali ed internazionali - pari a circa 131 milioni e presenze intorno ai 436 milioni (ISTAT).

In particolare, nell’ambito della Misura 4. “Turismo 4.0”, l’Investimento 4.1 – “Tourism Digital Hub” (TDH) è finalizzato a realizzare una piattaforma web dedicata, che consenta il collegamento dell’intero ecosistema turistico al fine di valorizzare, integrare e favorire la propria offerta.

Gli obiettivi che si intende raggiungere tramite il TDH sono:

• Incrementare i flussi, le destinazioni e la spesa, aumentando la qualità dell’offerta e relativa visibilità dei punti di interesse turistici in Italia (POI);
• Valorizzare l’esistente framework di asset digitali - ad esempio i portali regionali - senza sovrapporsi, offrendo in aggiunta soluzioni per l’ottimizzazione dei costi;
• Rafforzare il ruolo degli asset digitali del TDH, definendoli come veri e propri punti di riferimento istituzionali per la ricerca di informazioni inerenti ai POI rispetto ad una platea di turisti nazionali ed internazionali;
• Coinvolgere l’intero sistema turistico italiano mediante un approccio open-source che raccolga input e generi output per tutti gli stakeholder;
• Fidelizzare gli utenti (e quindi, potenziali turisti) attraverso proposte personalizzate rispetto alle loro esigenze e preferenze, offrendo un’esperienza sul portale personalizzata;
• Favorire la nascita di una piattaforma che offra informazioni puntuali e corrette sui POI in Italia, e il cui dato vada a popolare piattaforme esterne per la localizzazione come Google My Business, Bing Places, Apple Maps e così via – andando quindi a portare un ulteriore beneficio in termini di visibilità sui più comuni motori di ricerca.

Il Ministero del Turismo, coadiuvato da ENIT - Agenzia nazionale per il turismo, ha il compito di coordinare l’intero ecosistema turistico italiano, promuovendo, in maniera unitaria, il rilancio del settore turistico mediante un’offerta informativa e di servizi coesa ed eterogenea, a fronte dei continui cambiamenti della domanda, nazionale ed internazionale.

Obiettivo dell’iniziativa TDH è il rilancio di Italia.it, arricchito con nuovi contenuti prodotti internamente e in collaborazione con le Regioni e Province Autonome, ma anche attraverso integrazioni con partner in ambito Turistico. Nel dettaglio, per ogni argomento trattato, il portale presenterà contenuti dalla triplice valenza:

• Contenuto di Interesse: contenuto editoriale, la cui lettura consente al TDH di desumere l’interesse della Persona. Consente di descrivere una o più destination, una o più offerte e/o qualsiasi tipo di evento riguardante l’esperienza turistica sul nostro territorio (es: un articolo editoriale che parla del Palio di Siena, se letto dal turista, fa desumere l’interesse per la città di Siena e per le rievocazioni storiche);
• Destinazione/Destination: attrazione sul territorio correlabile ad un punto di interesse (coordinate x,y) oppure ad un’area geografica («geometria») che permane nel medio-lungo termine (es. Il Colosseo, la Fontana di Trevi, la città di Roma, ecc.);
• Offerta: un oggetto turistico che può essere consumato/prenotato/visitato a pagamento (es: una camera d’albergo, un ingresso al museo).

Il TDH, inoltre, si pone l’obiettivo di far incontrare profittevolmente la domanda turistica verso l’Italia con la relativa offerta italiana (erogata da diversi attori), mettendo in relazione tra loro gli interessi della persona (turista), le destinazioni e l’offerta prima, durante e dopo l’esperienza turistica, creando valore per tutti gli attori coinvolti.

All’interno del TDH è prevista la progettazione e implementazione di un Piattaforma di Integrazione – Full Life Cycle API Manager che ha l’obiettivo di supportare l’interoperabilità tra applicazioni e servizi sia esterni che interni al TDH:

• servizi esterni: dati di seconda parte (es. Regioni), dati di terza parte (es Enti Privati e Pubblici integrativi rispetto al sistema nazionale), dati geografici;
• servizi interni: integrazione con applicazioni interne al TDH che coprono moduli specifici (es. CRM).

In un’ottica di raggiungimento dell’obiettivo di coinvolgimento dell’intero sistema turistico italiano, la Piattaforma di Integrazione e Api Manager garantisce il coordinamento informatico e informativo dei dati tra le Amministrazioni (centrali, regionali e locali), gli Enti e Società Terze con l’Ecosistema Digitale del TDH. Viene altresì identificato un protocollo di comunicazione standard tra il TDH e il mondo esterno, definito TDH022.

In tal senso, il TDH022 si pone come Standard Digitale a livello Nazionale, preposto allo scambio di dati e contenuti sia “aperti” (open data) che “chiusi” (private data) tra i partecipanti, svolgendo altresì ruolo di interfaccia di integrazione tra il TDH e gli Operatori di Settore che desiderano far parte dell’Ecosistema e che sono operativi sul territorio nazionale italiano.

In Figura 1 - Ecosistema TDH e connessione al mondo esterno mediante TDH022 viene schematizzata la strategia del Tourism Digital Hub e di interconnessione.

Figura 1 - Ecosistema TDH e connessione al mondo esterno mediante TDH022

Le modalità di interazione con l’Ecosistema TDH permettono sia di fruire di servizi digitali disponibili al suo interno sia di svilupparne/erogarne di nuovi (open o closed) mettendoli a disposizione dei soggetti aderenti all’Ecosistema. In tal senso, le interazioni prevedono che gli operatori (pubblici e privati) aderenti al TDH022 possano svolgere a seconda dei casi funzioni di:

• erogatore di servizi, nel caso in cui mettano a disposizione del TDH servizi e funzionalità;
• fruitore dei servizi, nel caso in cui utilizzino servizi digitali messi a disposizione da soggetti terzi all’interno dell’Ecosistema.

1.2 Obiettivo del documento¶

Questo documento si pone come base di riferimento per l’Interoperabilità che il Ministero del Turismo intende adottare con Operatori Istituzionali e Privati, per lo scambio di informazioni, dati e servizi con il TDH.

Tale documento definisce le Linee Guida che vengono dettagliate nei Documenti Operativi ad esso collegati.

Le Linee Guida individuano standard e tecnologie che le Pubbliche Amministrazioni dovranno tenere in considerazione per rendere i propri sistemi informatici interoperabili, al fine di permettere il coordinamento informativo e informatico dei dati tra le Amministrazioni (centrali, regionali e locali), gli Enti e Società Terze con l’Ecosistema Digitale TDH, d’ora in avanti “Ecosistema” o “TDH”, tramite il TDH022.

Le Linee Guida del presente documento assicurano coerenza rispetto a:

• evoluzione della tecnologia;
• aderenza alle indicazioni dell’European Interoperability Framework (EIF);
• adeguatezza alle esigenze informativo/tecniche delle amministrazioni e dei suoi utenti;
• adozione da parte degli Enti pubblici e dei partner privati interessati;
• ontologie e tassonomie uniformi per la classificazione e l’organizzazione dei contenuti;
• adeguatezza ai necessari livelli di sicurezza.

L’aggiornamento del presente documento verrà curato costantemente da parte del Ministero del Turismo, sulla base delle evoluzioni tecnologiche e/o normative che dovessero emergere.

Le Linee Guida si pongono altresì in linea con le indicazioni emanate da AgID, rif. documento “Linee Guida sull’interoperabilità tecnica delle Pubbliche Amministrazioni” [lettera b) comma 3-bis articolo 73 del Decreto Legislativo 7 marzo 2005, n. 82] contribuendo alla definizione di un modello di interoperabilità tra gli operatori turistici, focalizzandosi sui processi, le tecnologie e le loro modalità di utilizzo, al fine di assicurare lo scambio di dati e contenuti con il TDH per mezzo dello standard TDH022. Sono inoltre definiti i contesti di interazione all’interno dell’Ecosistema.

Infine, le Linee Guida indirizzano il livello di interoperabilità tecnica e sostengono le iniziative di standardizzazione avallate dalla Commissione Europea (rif. Doc. European Interoperability Framework – EIF).

2.1 Struttura del documento¶

Le Linee Guida forniscono una visione di insieme generale e ad esse sono collegati Documenti Operativi (DO) Figura 2 - Struttura delle Linee Guida e dei Documenti Operativi - ai quali si rimanda per dettagli relativi a standard tecnologici e loro modalità di utilizzo al fine di fruire e/o erogare dati e/o servizi digitali per il tramite di sistemi terzi verso e dal TDH:

Al fine di assicurare il costante allineamento alle evoluzioni tecnologiche, l’aggiornamento dei DO è realizzato dagli operatori preposti nelle more delle tempistiche e delle modalità da attuare.

Figura 2 - Struttura delle Linee Guida e dei Documenti Operativi

2.2 Riferimenti Normativi [1]¶

Sono riportati di seguito gli atti normativi di riferimento del presente documento:

2.3 Termini e definizioni [1]¶

3.1 Interazioni [1]¶

L’ambito di applicazione delle presenti Linee Guida, in coerenza con il Modello di Interoperabilità delle Pubbliche Amministrazioni Italiane (ModI: Modello realizzato da AgID che rende possibile la collaborazione tra Pubbliche amministrazioni e tra queste e soggetti terzi per mezzo di soluzioni tecnologiche che assicurano l’interazione e lo scambio di informazioni senza vincoli sulle implementazioni, evitando integrazioni ad hoc), comprende i tre tipi di interazioni previste nell’EIF che vedono coinvolte Pubbliche Amministrazioni, Cittadini e Imprese.

Le modalità di interazione con l’Ecosistema TDH permetteranno sia di fruire di servizi digitali (open) disponibili al suo interno sia di svilupparne/erogarne di nuovi (open o closed) mettendoli a disposizione dei soggetti aderenti all’Ecosistema. In tal senso, le interazioni prevedono che gli operatori (pubblici e privati) aderenti al TDH022 possano svolgere la funzione di erogatore di servizi e fruitore dei servizi, come precedentemente descritto. In tal senso è possibile da parte di un operatore turistico svolgere alternativamente o entrambe le funzioni.

I soggetti fruitori possono utilizzare i servizi digitali messi a disposizione dagli erogatori di servizi, che hanno evidenza del loro utilizzo tramite appositi meccanismi di controllo quali:

• una soluzione software che preveda un meccanismo di controllo azionato da specifico operatore nel back-end della Piattaforma (user agent/human);
• un sistema applicativo automatico (server/machine), anche allo scopo di definire nuovi servizi a valore aggiunto (connessione via API).

3.2 Application Programming Interface (API)¶

Nell’ambito della comunicazione tra sistemi esterni e TDH vengono definite due modalità di interscambio:

• API web RESTful (consigliata),
• Web Services su standard SOAP, qualora i sistemi non prevedano l’utilizzo di API web RESTful.

Per API (Application Programming Interface) si intende “un insieme di protocolli/ funzionalità/ definizioni attraverso le quali è possibile realizzare sistemi applicativi integrati; in tal senso, l’API è concepita come una «black box», ossia una funzionalità richiamabile per la quale è necessario solo conoscerne l’interfaccia, senza la necessità di conoscere eventuali dettagli implementativi” [1].

Le Web API sono delle API richiamabili da Web (principalmente basate su protocollo HTTP), il cui obiettivo è di ottenere un alto livello di astrazione che si interpone tra lo strato di logica e i client che ne richiedono il servizio. Le Web API sono principalmente di tipo REST o di tipo SOAP.

Il formato dati per le Web API SOAP (o Web Service SOAP) è di tipo XML, mentre per le API web RESTful è possibile sfruttare i formati previsti dal protocollo HTTP come definito dalla W3C.

In ambito API web RESTful, si fa riferimento all’architettura REST, secondo il modello di maturità di Richardson [2]; in tal senso, il modello RESTful è compliant con il livello 3 di maturità - Hypermedia Controls.

Le Linee Guida individuano le modalità con cui gli sviluppatori/aderenti al TDH022 implementano le proprie API, quali elementi tecnologici di base attraverso i quali è possibile stabilire l’interconnessione con il TDH e la fruizione di servizi e/o contenuti da parte degli utenti finali.

3.3 Qualità dei Servizi (QoS) [1]¶

Qualità dei Servizi, comunemente chiamata Quality of Service (QoS), fa riferimento alla descrizione non funzionale di API, ovvero alla capacità di quest’ultima di soddisfare le aspettative dei fruitori.

Assicurare la QoS in ambito Internet ai fini dell’interoperabilità è una sfida critica a causa della natura dinamica e in costante evoluzione del contesto tecnologico. Cambiamenti negli schemi di traffico, la presenza di transazioni critiche, gli effetti dei problemi di rete, le performance dei protocolli e degli standard di rete richiedono una definizione accurata e precisa della QoS offerta da una API.

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

I soggetti (pubblici o privati) aderenti al TDH che rendono disponibili dati e contenuti, devono intraprendere tutte le iniziative necessarie a garantire i requisiti di QoS richiesti dal caso d’uso. Questo include anche l’utilizzo di buone pratiche, ad esempio, per assicurare prestazioni e scalabilità, nonché l’implementazione di meccanismi che assicurino il maggior risparmio di banda possibile.

3.4 Service Level Agreement (SLA) [1]¶

L’integrazione può coinvolgere numerosi aderenti al TDH che espongono le proprie API. Al fine di allinearsi sulla QoS, gli erogatori e i fruitori di API utilizzano quelli che vengono definiti Service Level Agreement (SLA), ovvero accordi sul livello di servizio. Uno SLA è costituito dai seguenti elementi:

Gli SLA possono essere statici o dinamici. Negli SLA dinamici, gli SLO (con associati SLI) variano nel tempo e i periodi di validità definiscono gli intervalli di validità di questi ultimi (ad es. in orario lavorativo gli SLO possono essere differenti da quelli imposti durante la notte). La misurazione dei livelli di QoS all’interno di uno SLA richiede il tracciamento delle operazioni effettuate in un contesto infrastrutturale multi-dominio (geografico, tecnologico e applicativo).

3.5 Dominio di interoperabilità [1]¶

Nell’ambito delle presenti Linee Guida, per dominio di interoperabilità si intende uno specifico contesto in cui più Amministrazioni e/o soggetti Privati hanno l’esigenza di scambiare dati e/o integrare i propri processi per dare seguito al disposto normativo.

Ogni dominio di interoperabilità è caratterizzato da:

• i soggetti partecipanti, le Amministrazioni e gli Enti (inclusi Ministero del Turismo ed ENIT) e gli eventuali soggetti Privati (cittadini e imprese);
• i sistemi informatici dei soggetti partecipanti che scambiano dati e/o integrano i propri processi;
• l’insieme di API implementate per garantire le interazioni tra i sistemi informatici dei soggetti partecipanti;
• i criteri di sicurezza che le singole API forniscono per assicurare transazioni tra i soggetti partecipanti conformi alla norma.

3.6 Logging [1]¶

Il logging riveste un ruolo fondamentale nella progettazione e nello sviluppo di API. Le moderne piattaforme middleware, oltre ad integrare meccanismi di logging interni, possono connettersi ad API esterne che permettono la raccolta (log collection), la ricerca e la produzione di analytics, utili 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 delle API, ma anche quelli di eventuali altri servizi digitali e componenti di rete (ad es. proxy e application-gateway). Ai fini di non ripudio, i messaggi applicativi possono essere memorizzati insieme alla firma digitale, ed archiviati nel rispetto della normativa sulla conservazione e sulla privacy. L’erogatore deve documentare in dettaglio il formato e le modalità di tracciatura, consultazione e reperimento delle informazioni.

Figura 3 - Schema esplicativo del processo di logging TDH

Nell’ambito dell’interoperabilità TDH022, l’erogatore non traccerà nei log informazioni riservate quali password, chiavi private o token di autenticazione; inoltre dovrà tracciare un evento per ogni richiesta contenente almeno i seguenti parametri minimi:

• Timestamp della richiesta;
• identificativo del fruitore e dell’operazione richiesta;
• tipologia di chiamata;
• esito della chiamata;
• ove applicabile, identificativo del Consumatore del Servizio API o altro soggetto operante la richiesta comunicato dal Fruitore - che provvederà alla codifica e all’anonimizzazione, ove necessario;
• un identificativo univoco della richiesta, utile a eventuali correlazioni.

3.7 Pattern e profili di interoperabilità [1]¶

Le Linee Guida individuano:

I pattern di interoperabilità si dividono in:

I Pattern e Profili di interoperabilità individuati nei Documenti Operativi delle Linee Guida TDH022 sono utilizzati dalle Amministrazioni nell’implementazione delle proprie API; le Amministrazioni, inoltre, selezionano i Pattern e/o i Profili di interoperabilità sulla base delle specifiche esigenze del dominio di interoperabilità a cui partecipano.

3.8 Catalogo delle API [1]¶

Le Linee Guida definiscono il Catalogo delle API TDH022 (in breve, Catalogo) quale componente unica e centralizzata, che assicura alle parti coinvolte nel rapporto di erogazione e fruizione la conoscenza delle API disponibili, e per esse, i livelli di servizio dichiarati.

La presenza del Catalogo è funzionale a:

• facilitare l’interoperabilità tra le Amministrazioni e i soggetti Privati interessati;
• contenere la spesa delle Amministrazioni, riducendo la replicazione di API;
• assicurare la dichiarazione degli SLO da parte dell’Erogatore sulle singole API pubblicate;
• manifestare, ove presenti, gli impegni tra Erogatori e Fruitori relativi all’utilizzo delle API (SLA).

Il Catalogo, fatti salvi i principi comuni che saranno emanati dal Ministero del Turismo, al fine di normalizzare le tecnologie utilizzate a livello nazionale, tiene conto della:

• Specificità dei diversi ambiti all’interno dei quali opera il Ministero del Turismo attraverso la determinazione di classi tematiche dei contenuti in Catalogo, prevedendo quindi aggregazioni di API sulla base di diverse tassonomie. Tale scelta è ulteriormente giustificata dall’opportunità di condividere metodologie comuni ai fini della progettazione e dello sviluppo all’interno di un Ecosistema comune (TDH).
• Esigenza di assicurare la governance del Catalogo, quale presupposto per garantire una semantica univoca e condivisa, per evitare ridondanze e/o sovrapposizioni in termini di competenze e contenuti (de-duplicazione).
• Esigenza di assicurare una descrizione formale delle API che, attraverso l’utilizzo degli Interface Description Language (IDL) indicati, permetta di descrivere le API indipendentemente dal linguaggio di programmazione adottato dall’Erogatore e dai Fruitori.

3.9 Governance del Modello [1]¶

Il Ministero del Turismo è responsabile delle attività di governance con l’obiettivo di definire, condividere e assicurare l’aggiornamento continuo dei seguenti aspetti:

• l’insieme delle tecnologie che abilitano l’interoperabilità tra gli aderenti all’Ecosistema;
• i Pattern di interoperabilità (interazione e sicurezza);
• i Profili di interoperabilità;
• l’insieme delle Tassonomie e Ontologie.

Il rapporto tra Fruitori ed Erogatori è reso esplicito tramite il Catalogo.

L’Adesione al TDH avviene a mezzo della sottoscrizione del relativo Accordo, che disciplina i ruoli, le responsabilità e gli obblighi delle Parti. Fermi restando gli utilizzi consentiti al MiTur nell’ambito delle finalità del TDH, l’utilizzo delle API di un Erogatore da parte di un Fruitore in contesti e per finalità estranee al TDH è soggetto ad una Autorizzazione ulteriore da parte dell’Erogatore stesso, che sarà gestita digitalmente con apposita procedura sul TDH.

Gli Erogatori devono descrivere i propri e-service classificando le informazioni scambiate (ove possibile collegandole ai vocabolari controllati e a concetti semantici definiti a livello nazionale e/o internazionale) e applicare etichette che ne identifichino la categoria.

Un Erogatore può delegare la registrazione degli e-service all’interno del Catalogo ad un altro soggetto (Amministrazioni Regionali e/o Locali, Enti o Terze Parti) relativamente a specifici contesti territoriali e/o ambiti tematici.

Il Catalogo delle API permette ai soggetti Pubblici e Privati di conoscere gli e-service disponibili e le loro modalità di erogazione e fruizione all’interno dell’Ecosistema.

Il Ministero del Turismo ha il ruolo di:

• recepire le esigenze di interoperabilità delle Amministrazioni Regionali e/o Locali, Enti o Terze Parti, astrarle ed eventualmente formalizzare nuovi pattern e/o profili di interoperabilità;
• coordinare il processo di definizione dei Profili e Pattern di interoperabilità;
• rendere disponibile il Catalogo, attraverso un’interfaccia di accesso unica per permettere a tutti i soggetti interessati, pubblici e privati, di conoscere gli e-service disponibili;
• richiedere l’adozione dei Pattern e Profili di interoperabilità per l’implementazione delle API quale condizione per l’iscrizione al Catalogo, nonché controllare con continuità il rispetto dei requisiti per l’iscrizione al Catalogo stesso.

4.1 Piattaforma applicativa¶

Ai fini dell’interoperabilità con il Tourism Digital Hub agli Operatori (ed es. Enti, Regioni) si raccomanda l’utilizzo di un applicativo che permetta di gestire le API (invocare/esporre) e dia la possibilità di consultarle e monitorarle garantendone la gestione operativa; tale piattaforma, pertanto, dovrà essere dotata di:

• API Manager: utile alla definizione di regole di accesso alle proprie API e alla gestione delle stesse;
• API Gateway: strumento che gestisce le API, interponendosi tra un client e una serie di servizi di back-end; in sostanza un API Gateway funge da proxy inverso, accettando tutte le chiamate API, e laddove previste autorizzazioni e autenticazioni, ha il compito di accettare solo le chiamate autorizzate/autenticate. Si occupa inoltre di aggregare i vari servizi richiesti, restituendo un risultato appropriato;
• Integration Platform: strumento che si occupa della mediazione tra i servizi per realizzare modelli “loose-coupled” [1] (a bassa dipendenza) tra provider e fruitori di servizi, grazie all’introduzione di un broker middleware che si occupi di fornire:
  • conversioni di protocollo e di formato dei dati;
  • policy nell’interazione provider-fruitori (es.: auditing, logging e security monitoring);
  • logiche di invocazione e inoltro delle chiamate ai servizi (dispatching).

Si consiglia inoltre di prevedere la componente di Orchestrazione, intesa come la composizione ed esecuzione coordinata di API che possono essere organizzate in tre macrocategorie:

• Interface layer: livello di pertinenza specifica del Gateway, dove sono realizzate le interfacce verso i client che consumano il servizio;
• Application & Orchestration Services: livello dei servizi focalizzati sul dominio della service logic, orchestrazione dei processi di business e astratti dalle tematiche di enterprise integration a livello di back-end;
• System services: servizi che operano a livello di integrazione delle singole applicazioni di back-end (ad es. Database, Host, Cloud SaaS).

In aggiunta a ciò, è necessario prevedere le funzioni di Monitoraggio e Alerting “end to end” dei flussi di integrazione delle API sviluppate ai fini dell’interoperabilità TDH022.

Figura 4 – Schema esplicativo della piattaforma applicativa di API Gateway

4.2 Requisiti minimi per l’interconnessione al TDH lato Operatori (Regioni, Enti, Soggetti Terzi)¶

A fronte della necessità di stabilire una connessione tra Operatori e TDH si consiglia, ai soggetti che volessero interconnettersi ad esso, di dotarsi di un’infrastruttura tecnologica che permetta loro di scambiare/ricevere informazioni e contenuti, utilizzando una modalità criptata, autenticata e autorizzata.

In particolare, per le Regioni si prevede la condivisione e/o trasmissione di contenuti digitali (articoli, immagini, video ecc…) e di informazioni riferiti a POI (Punti di Interesse), Destinazioni, Interessi ed Offerte. Pertanto, si raccomanda alle Regioni, qualora già non lo fossero, di dotarsi di strumenti specifici in grado di gestire la memorizzazione e, quando necessario, la trasmissione dei suddetti contenuti (es. CMS).

In generale è auspicabile che gli Operatori interessati all’interconnessione con il TDH abbiano gli strumenti applicativi adeguati all’interscambio bidirezionale delle informazioni con relativo aggiornamento real time ove possibile.

Si rende dunque possibile effettuare la connessione bidirezionale TDH/Operatore a mezzo API mediante:

• API con link al contenuto: ai fini della fruizione di contenuti digitali condivisi dagli operatori quali immagini, video, articoli, ecc… verranno esposte API con link per richiamare la risorsa (contenuto) presente all’interno del CMS dell’Operatore e che viene presentata dal TDH;
• API con contenuto: ai fini della fruizione diretta di contenuti digitali condivisi dagli operatori sopra riportati che vengono trasmessi direttamente all’utente finale dal DMS;
• API di trasmissione e/o ricezione informazioni: ai fini dell’interscambio di informazioni tra TDH e Regioni/Operatori.

Figura 5 – Schema esplicativo dell’interconnessione TDH/Regioni a mezzo differenti API

5.1 Web Service SOAP (simple object access protocol)¶

SOAP è un protocollo utilizzato per l’interscambio di messaggi che, sebbene possa poggiarsi su diversi protocolli di rete (es. JMS), è standardizzato per il solo protocollo http (W3C).

SOAP, che ha visto il suo successo con l’affermarsi delle architetture a servizi si basa su XML con una struttura di tipo “header-body”, suddivisa nelle seguenti sezioni:

• Soap-Header (opzionale): in questa sezione sono presenti dati non legati al contenuto dell’informazione da scambiare, bensì ai metadati relativi ai processi di logging, instradamento, sicurezza e orchestrazione;
• Soap-Body (obbligatoria): in questa sezione sono presenti i dati legati all’informazione da trasmettere.

Il descrittore delle interfacce è basato sul metalinguaggio WSDL (Web Service Description Language) e, in tal senso, per poter permettere ai sistemi di comunicare tra loro a mezzo SOAP, è necessario che gli stessi sistemi possano scambiare il WSDL.

La chiamata SOAP, in ultimo, utilizza esclusivamente il metodo POST di http, con possibilità di inviare degli allegati alla richiesta.

5.2 API web RESTful (Representational State Transfer)¶

Prima di presentare nello specifico le API Web RESTful, si rende necessario un approfondimento preliminare in merito a “REST”; nello specifico, REST non è un protocollo, ma uno stile architetturale, ossia rappresenta un’astrazione dei componenti di un’architettura all’interno di un sistema hypermedia distribuito. I principi fondamentali di questo stile architetturale sono:

• Client-Server (viene usato il paradigma separation of concerns (SoC)): a livello di progettazione ogni sistema deve essere concepito come un modulo avente un compito determinato; in sostanza, un Client può solo invocare un’API messa a disposizione da un Server che si occupa di eseguire l’attività richiesta, o di respingerla, restituendo un messaggio di risposta al Client. La gestione di eccezioni/ripubblicazioni è delegata al client;
• Stateless: la comunicazione tra un Client ed un Server deve essere senza stato tra le richieste; ciò significa che ogni richiesta che parte dal Client dovrà avere il set di informazioni necessarie per consentire al Server di comprendere la richiesta. Per cui tutti i dati necessari vengono restituiti al client alla fine di ciascuna richiesta;
• Chacheable: in questo tipo di architettura esiste il concetto di “vincolo di cache” ossia l’obbligo di etichettare le risposte come “cacheable” o meno. Questo permette ad uno degli attori che si interpongono tra Client (compreso) e Server di memorizzare la risposta nella cache, e migliorare così le performance di rete;
• Uniform Interface: al fine di avere una strategia di caching efficiente in una rete, esiste il concetto di “vincolo di uniformità dell’interfaccia di accesso ai dati” ossia l’obbligo che i componenti coinvolti nella comunicazione utilizzino un’interfaccia uniforme; tale vincolo ha alcune declinazioni, quali il concetto di “risorsa”: ogni informazione è rappresentata, pertanto, come «risorsa». Per quanto una risorsa possa cambiare nel tempo, la semantica della sua mappatura deve restare costante: in sostanza una risorsa deve essere identificata univocamente (URI) nel tempo. Altra caratteristica è come la risorsa può essere rappresentata in modi diversi (JSON, GeoJSON, XML, JPG) e ciò è reso possibile attraverso la definizione di dati, metadati e dati di controllo. I dati di controllo possono definire lo scopo di un messaggio, ad esempio come gestire la cache di una risposta. Ultima declinazione è quello relativo al collegamento tra risorse secondo il principio HATEOS (hypermedia As The Engine Of Application State);
• Layered System: Il principio in questione prevede che un’architettura REST sia rappresentata attraverso più livelli architetturali, indipendenti l’uno dall’altro, con degli scopi specifici (Es. sicurezza, balancing, …);
• Code on demand (opzionale): Un’implementazione basata su REST può estendere le funzionalità del client, eseguendo il codice (es. script o applet).

Le API web RESTful ricalcano i principi esposti e sono basate su protocollo HTTP, da cui ne ereditano tutte le proprietà, come ad esempio il formato del dato trasportato, definito dal “content-type”, o i codici di errore restituiti dal server (es. 400, 500), e dai metodi (es. Get per recuperare dati, Post per creare risorse, Delete per cancellare risorse, …).

Figura 6 - REST e SOAP a confronto

6.1 Ontologie: Introduzione¶

Un’ontologia è una rappresentazione formale della conoscenza di un determinato dominio, in grado di organizzare, modellare e gestire informazioni e conoscenze, per poi condividerle e riutilizzarle in uno o più domini. L’ontologia, inoltre, consente di definire un vocabolario comune, definendo il significato e la correlazione tra i termini e il modo in cui questi sono in relazione tra loro, permettendo infine di combinare la modellazione semantica con la conoscenza del dominio.

La costruzione di un’ontologia all’interno di un’organizzazione consente di stabilire standard a livello organizzativo, creando e migliorando i collegamenti tra i diversi domini, portando così ad una maggior trasparenza e ad una migliore interpretazione del dato.

6.2 Il ruolo delle Ontologie nell’ecosistema organizzativo e i razionali alla base della definizione¶

Il ruolo dell’ontologia è quello di ricoprire il «comune denominatore» tra fonti di dati esistenti e potenziali presenti all’interno dell’Ecosistema, e in particolare nel TDH. L’obiettivo principale dello sviluppo di un’ontologia è quello di identificare il minor numero di entità necessarie a garantire un alto grado di l’interoperabilità del dato.

La costruzione di un’ontologia porta principalmente due vantaggi:

• Gli stakeholder concordano su una terminologia comune per la descrizione degli elementi,
• Sistemi diversi, database e applicazioni, possono comunicare senza doversi connettere tra loro.

Questi due aspetti consentono lo sviluppo di nuovi sistemi informativi all’interno del TDH022 attraverso uno scambio di dati più rapido ed efficiente, agevolando l’integrazione tra dati provenienti da sorgenti diverse.

6.3 Il processo di sviluppo delle ontologie¶

7.1 Adesione all’Ecosistema TDH – Il modello contrattuale¶

Le modalità di adesione all’Ecosistema Digitale TDH comportano la sottoscrizione di convenzioni e contratti che disciplinano l’operatività delle Seconde e Terze Parti, nelle more dell’interscambio di dati e contenuti sia con i soggetti all’interno del suddetto Ecosistema che all’esterno quali, ad esempio, i turisti che fruiranno dei contenuti esposti sul Tourism Digital Hub.

Date la continua evoluzione del mondo digitale e l’esigenza di tutelare al meglio tutti le categorie di dati, nel rispetto degli adempimenti previsti dal Legislatore europeo e nazionale, ai fini della definizione del modello contrattuale di adesione all’Ecosistema TDH si è proceduto ad utilizzare un approccio metodologico imperniato sugli elementi di seguito riportati:

7.2 Adesione all’Ecosistema TDH – L’approccio metodologico del modello contrattuale¶

L’approccio metodologico per l’adesione all’Ecosistema prende in considerazione gli elementi peculiari che riguardano le singole categorie di attori, istituzionali e non, di dati e di flussi informativi che rientreranno nel modello operativo dell’Ecosistema stesso. L’approccio è pertanto modulare e mira a minimizzare gli oneri amministrativi gravanti sulle parti coinvolte, in considerazione del ruolo da esse effettivamente ricoperto nell’ambito dell’Ecosistema. Al crescere della complessità e della varietà di dati e flussi scambiati, il modello risponde con la definizione di ulteriori allegati di carattere tecnico al modello contrattuale principale, che disciplinino le casistiche più complesse di interazione, segnatamente quelle abilitano la progettazione e implementazione di nuovi servizi ad opera di Seconde e Terze parti. L’approccio metodologico ricomprende anche un supporto alle parti aderenti di natura procedurale, funzionale e tecnica.

7.3 Il processo di adesione all’Ecosistema TDH¶

L’adesione all’Ecosistema avviene mediante apposito processo digitalizzato che vede la compartecipazione delle parti coinvolte. In particolare, l’aderente dovrà procedere alla sottoscrizione del modello contrattuale e, se applicabili al caso specifico, dei relativi allegati. La sottoscrizione presuppone, come già ricordato, il riconoscimento dell’identità digitale dei sottoscrittori, nelle forme disciplinate dalle norme vigenti. Il processo di adesione avrà validità di 24 mesi, trascorsi i quali il sistema segnalerà agli aderenti l’esigenza di sottoscrivere nuovamente il modello contrattuale. Eventuali adeguamenti del modello e/o dei relativi allegati, ad esempio derivanti da modifiche al quadro normativo di riferimento, saranno oggetto di comunicazione alle Parti.