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

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

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

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 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:. 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. Fonte: “Why is the Web Loosely Coopled? A Multi-Faceted Metric for Service Design” (Pautasso, Wilde – 2009) Riferimento online: http://www2009.eprints.org/92/1/p911.pdf ...

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:. L’adesione all’Ecosistema Digitale TDH avviene in modalità digitalizzata, con identificazione a norma a mezzo:. SPID – obbligatorio. eIDAS – obbligatorio. Carta d’Identità Elettronica (CIE). Tessera Sanitaria – Carta Nazionale dei Servizi (TS – CNS). E sottoscrizione a norma dei documenti informatici formati (accordo di adesione e suoi allegati) a mezzo:. Firma digitale SPID [1]. Firma digitale ai sensi del regolamento eIDAS [2]. FEQ (Firma Elettronica Qualificata). Viene altresì garantita la corretta gestione delle deleghe al momento della sottoscrizione del contratto di adesione (in tal senso, per gli Enti e le aziende è necessario gestire il tema delle deleghe alla firma, ossia la verifica che un determinato soggetto possa impegnare l’organizzazione di appartenenza mediante la firma). Semplicità. Viene agevolato l’iter di adesione e sottoscrizione del contratto, ponendo in capo ai soggetti istituzionali solo gli oneri contrattuali realmente necessari e garantendo un modello contrattuale snello. Standardizzazione. Viene garantita la standardizzazione dei modelli contrattuali, demandando agli allegati l’inserimento di eventuali clausole accessorie. Protezione dati personali. L’approccio utilizzato appartiene alla tipologia “Privacy by Design”, ovvero nel rispetto dei principi fondamentali della tutela dei dati personali, declinando al contempo opportunamente le modalità di trattamento dei dati personali al momento della sottoscrizione del contratto. Tipologia dati. Vengono individuate le categorie / tipologie dei dati oggetto di trasferimento nelle varie fasi di implementazione, proponendo al contempo un modello contrattuale che preveda ragionevoli meccanismi di controllo circa la titolarità dei diritti di utilizzo, correttezza, attendibilità ed aggiornamento dei dati oggetto di trasferimento al Ministero del Turismo, con l’esplicitazione di obblighi di trattamento, conservazione e distruzione a norma di legge a carico delle parti e sufficienti garanzie e manleve a favore del Ministero stesso nonché dei partecipanti all’Ecosistema. Sicurezza dei dati. Deve essere previsto un adeguato livello di controllo sugli standard minimi di sicurezza dei dati e dei sistemi di trasmissione, in linea con gli standard di best practice in materia di data & cyber security atti a minimizzare i rischi di sistema. Gestione API. Sono chiaramente esplicitati i seguenti aspetti di gestione API:. standard tecnologici e di sicurezza vincolanti e non derogabili;. processo di validazione e controllo per mezzo di una struttura competente (Technical Management Board e team) che valida, certifica e monitora le API e i contenuti all’avvio e a regime;. processi di revisione periodica delle API e dei contenuti. Con l’adozione della Determinazione n.157/2020 del 23 marzo 2020, Emanazione delle Linee Guida per la sottoscrizione elettronica di documenti ai sensi dell’art. 20 del CAD, l’AgID ha introdotto una nuova modalità di sottoscrizione dei documenti informatici: la Firma tramite il Servizio Pubblico di Identità Digitale. L’architettura del processo di firma con SPID poggia i propri presupposti giuridici sull’art. 20 del CAD, ove si afferma che il soddisfacimento del requisito della forma scritta e l’efficacia prevista dall’articolo 2702 del Codice Civile del documento informatico formato avviene, previa identificazione informatica del suo autore, attraverso un processo avente i requisiti fissati dall’AgID ai sensi dell’art. 71 con modalità tali da garantire la sicurezza, integrità e immodificabilità del documento e, in maniera manifesta e inequivoca, la sua riconducibilità all’autore. Il Regolamento eIDAS (Electronic identification and trust services), efficace dal 1° luglio 2016, stabilisce le condizioni per il riconoscimento reciproco in ambito di identificazione elettronica e le regole comuni per le firme elettroniche, l’autenticazione web ed i relativi servizi fiduciari per le transazioni elettroniche. Il provvedimento permette di adottare a livello europeo un quadro tecnico-giuridico unico, omogeneo ed interoperabile in ambito di firme elettroniche, sigilli elettronici, validazioni temporali elettroniche, documenti elettronici, nonché per i servizi di raccomandata elettronica ed i servizi di certificazione per Autenticazione web. Di conseguenza ai sensi dell’art. 20 del CAD, analogamente alla Firma Digitale SPID, anche la firma digitale eIDAS apposta sui documenti informatici soddisfa il requisito della forma scritta e ha l’efficacia prevista dall’articolo 2702 del Codice civile quando è formato, previa identificazione informatica del suo autore, attraverso un processo avente i requisiti fissati dall’AgID ai sensi dell’art. 71 con modalità tali da garantire la sicurezza, integrità e immodificabilità del documento e, in maniera manifesta e inequivoca, la sua riconducibilità all’autore ...

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

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

Application Programming Interface. [API-First]. Approccio in cui le PA considerano le API come mezzo principale per perseguire i propri obiettivi, interagendo con i propri stakeholder sin dalla fase di progettazione. Seguendo quanto stabilito dal CAD art. 64-bis, comma 1-bis, le interfacce applicative (API appunto) devono essere progettate e/o evolute in maniera interoperabile, a prescindere dai canali di erogazione del servizio che sono individuati logicamente e cronologicamente dopo la progettazione dell’API. [BP]. WS-I Basic Profile - (Web Services Interoperability Specification). [CMS]. Content Management System, strumento software installato su server, il cui compito è supportare la gestione di contenuti digitali, es per siti web. [Contract-First]. Contract-first è un approccio che prevede di dare seguito all’interazione di più sistemi informatici definendo le API condivise attraverso un Interface Description Language (IDL). [DAM]. Digital Asset Management, sistema integrato per la gestione centralizzata dei contenuti; consente di creare, organizzare e distribuire i contenuti su più canali come, ad esempio, siti web e applicazioni. [DMS]. Destination Management System, sistemi che consolidano e distribuiscono una gamma di prodotti turistici attraverso una varietà di canali e piattaforme (generalmente per una Regione), supportando le attività di organizzazione e di gestione delle destinazioni all’interno della Regione, ove implementati. [Enti Capofila]. Pubbliche Amministrazioni, soggetti responsabili delle attività di gestione sul Catalogo degli e-service, delle API e degli accordi di interoperabilità nelle veci di altre Pubbliche Amministrazioni. [Erogatore]. Uno dei soggetti di cui all’articolo 2, comma 2 del CAD che rende disponibile e-service ad altre organizzazioni, per la fruizione di dati in suo possesso o l’integrazione dei processi da esso realizzati. [e-service]. I servizi digitali realizzati ai sensi del CAD art. 1, comma 1, lettera n-quater) da un erogatore per assicurare l’accesso ai propri dati e/o l’integrazione dei propri processi attraverso l’interazione dei suoi sistemi informatici con quelli dei fruitori, trovano attuazione nell’implementazione di API. [Fruitore]. Organizzazione che utilizza gli e-service messi a disposizione da un dei soggetti di cui all’articolo 2, comma 2 del CAD. [HTTP]. Hypertext Transfer Protocol. [IDPS]. Interoperable Digital Public Services. [JWT]. JSON (JavaScript Object Notation) Web Tokens. [ModI]. Modello di Interoperabilità delle Pubbliche Amministrazioni Italiane. [PA]. Pubblica Amministrazione Italiana. [QoS]. Quality of Service. [REST]. Representational State Transfer. [RPC]. Remote Procedure Call. [SLA]. Service Level Agreement. [SLI]. Service Level Indicator. [SLO]. Service Level Objective. [SOAP]. Simple Object Access Protocol. [TDH]. Tourism Digital Hub. [TDH022]. TDH022 - Interfaccia di interoperabilità del Tourism Digital Hub. [UML]. Linguaggio di modellazione unificato (Unified Modeling Language). [W3C]. World Wide Web Consortium. [WS-*]. Stack degli standard emanati dal W3C relativi alle tecnologie SOAP, tra cui SOAP, WSDL, WS-Security, WS-Addressing e WS-Interoperability. [WSDL]. Web Services Description Language. [XML]. eXtensible Markup Language. [XML-RPC]. XML-Remote Procedure Call. . Alcuni termini e definizioni esplicitati all’interno di questo paragrafo sono presenti anche all’interno del documento di “Linee Guida sull’interoperabilità tecnica delle Pubbliche Amministrazioni” emanate da AgID (si rimanda alla sezione “Bibliografia e Sitografia di riferimento” a fine documento per link con redirect al documento) ...

Sono riportati di seguito gli atti normativi di riferimento del presente documento:. Decreto Legislativo 7 marzo 2005, n. 82 - «Codice dell’Amministrazione Digitale» (noto anche come “CAD”), aggiornato con modifiche dal D.L. 16 luglio 2020 n.76 e convertito in legge con la L. 11 settembre 2020 n.120. [EIF]. European Interoperability Framework. [CE 2008/1205]. Regolamento (CE) n. 1205/2008 della Commissione del 3 dicembre 2008 recante attuazione della direttiva 2007/2/CE del Parlamento europeo e del Consiglio per quanto riguarda i metadati. [D. lgs 196/2003]. Codice in materia di protezione dei dati personali. [UE 679/2016]. Regolamento (UE) 2016/679 del 27 aprile 2016 relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali (GDPR). [UE 910/2014]. Regolamento (UE) n. 910/2014 del 23 luglio 2014 in materia di identificazione elettronica e servizi fiduciari per le transazioni elettroniche nel mercato interno (eIDAS). [DUE 2019/1024]. Direttiva (UE) 2019/1024 del Parlamento Europeo e del Consiglio del 20 giugno 2019 relativa all’apertura dei dati e al riutilizzo dell’informazione del settore pubblico. Alcuni riferimenti normativi esplicitati all’interno di questo paragrafo sono presenti anche all’interno del documento di “Linee Guida sull’interoperabilità tecnica delle Pubbliche Amministrazioni” emanato da AgID (si rimanda alla sezione “Bibliografia e Sitografia di riferimento” a fine documento per link con redirect al 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:. Pattern di interazione. Documento Operativo 2. Pattern di sicurezza. Documento Operativo 3. Profili di interoperabilità. Documento Operativo 4. Raccomandazioni di implementazione. Documento Operativo 5. Ontologie. Documento Operativo 6. Contrattualistica e adesione all’Ecosistema Digitale. 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 ...

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:. 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:. 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 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:. fruitore dei servizi, nel caso in cui utilizzino servizi digitali messi a disposizione da soggetti terzi all’interno dell’Ecosistema ...

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