Una piattaforma che aggrega i dati turistici di un territorio deve far parlare fonti nate per non parlarsi: anagrafiche di beni culturali, orari del trasporto pubblico, sensori ambientali, cartografia comunale, contenuti redazionali. Esporre un’API è la parte facile; la parte difficile è decidere su quali protocolli far passare flussi che differiscono per cadenza, volume e modello di consistenza. Sto raccogliendo materiale per un’analisi di questo tipo dentro il progetto SMARTOUR (PON “Smart Cities and Communities”, filone dei beni culturali, con sperimentazioni in preparazione nel salernitano), e quel che segue è una ricognizione dei protocolli disponibili a gennaio 2017.

Contesto

Il primo vincolo di un sistema territoriale è che le fonti sono date. Una sovrintendenza pubblica i suoi dataset in un formato; un’azienda di trasporto ne espone un altro; i sensori ambientali parlano già un loro protocollo prima ancora che il progetto cominci. L’integrazione adatta le sorgenti invece di riscriverle. Il problema non è più disegnare un’unica API monolitica, ma mappare un insieme di protocolli, ciascuno con la propria semantica.

Conviene tenere separati due assi. Il primo è il pattern di interazione: richiesta/risposta sincrona contro pubblicazione/sottoscrizione asincrona. Il secondo è la natura del dato: anagrafico e a bassa frequenza di aggiornamento (un monumento, un orario) contro telemetrico e ad alta frequenza (una misura ambientale, un conteggio di presenze). I due assi non coincidono, e forzarli su un solo protocollo costa caro sull’uno o sull’altro.

I protocolli sincroni

Per i dati anagrafici e di consultazione, REST su HTTP resta la scelta con il minor costo di integrazione: cacheabile, ispezionabile, parlato da qualunque client. Il limite noto è il fan-out delle richieste quando una vista compone molte risorse — la classica scheda di un punto di interesse che tira giù anagrafica, orari, eventi e fotografie.

C’erano due alternative disponibili e abbastanza mature da meritare una valutazione. gRPC ha toccato la 1.0 il 23 agosto 2016, con binding stabili per C++, Java, Go, Python, Ruby, Node e C#; gira su HTTP/2 e Protocol Buffers, e ha senso sui collegamenti interni server-server, dove il contratto è fisso e la latenza pesa. Lo svantaggio, a gennaio 2017, è il supporto dal browser: serve un proxy, perché lo stream HTTP/2 a frame non è raggiungibile direttamente dal codice del client. GraphQL prende di petto proprio il fan-out: lascia al client dichiarare i campi che gli servono. La specifica è in sviluppo pubblico dal 2015, e l’edizione di riferimento è quella di ottobre 2016. Il prezzo lo paga il server: il caching HTTP non funziona più per URL, e una singola query può tradursi in un carico di backend difficile da limitare.

Nessuno dei tre rimpiazza gli altri. REST per l’esposizione pubblica e cacheabile, gRPC per i percorsi interni, GraphQL dove la composizione lato client è il vincolo che domina.

I protocolli asincroni e la telemetria

I dati sensoriali rovesciano il pattern. La sorgente produce quando ha un valore, non quando un client chiede, e i consumatori possono essere molti e intermittenti. Qui il modello pubblicazione/sottoscrizione viene da sé.

MQTT è il candidato di riferimento per la telemetria a banda limitata. La versione 3.1.1 è uno standard OASIS da ottobre 2014, e nel luglio 2016 ISO/IEC JTC1 l’ha approvata come ISO/IEC 20922:2016 — non un dettaglio formale, perché in un consorzio con partner pubblici uno standard ISO accorcia la discussione sulla scelta. MQTT ha un overhead di frame minimo e tre livelli di qualità del servizio; il rovescio è che lascia allo strato applicativo gran parte della semantica (schema dei payload, instradamento per topic), che va quindi disciplinata a monte.

Dove il requisito è di messaging tra sistemi più che di telemetria embedded, AMQP 1.0 offre un modello più ricco di routing e affidabilità; è standard OASIS dal 2012 e ISO/IEC 19464 dal 2014. A decidere è il requisito più stringente: frame piccoli e dispositivi vincolati spingono verso MQTT, garanzie di consegna e topologie di scambio articolate verso AMQP.

Il punto critico: la cartografia non è un dato come gli altri

La componente geospaziale è quella dove un’integrazione ingenua costa di più. Un territorio ha già i suoi servizi cartografici, e gli standard dell’Open Geospatial Consortium (OGC) sono il terreno comune: WMS per le mappe rasterizzate al volo, WMTS per i tasselli pregenerati e cacheabili, WFS per le geometrie vettoriali interrogabili. Trattare questi flussi come generici endpoint REST e reinventarne le convenzioni significa rinunciare all’interoperabilità con gli strumenti GIS che già li parlano.

Sul versante dei sensori geolocalizzati, l’OGC SensorThings API Part 1 (Sensing) è stata approvata come standard OGC a febbraio 2016. È rilevante qui perché tiene insieme i due assi visti sopra: espone i dati di osservazione via REST con encoding JSON e convenzioni di query OData, e prevede MQTT per la sottoscrizione agli aggiornamenti. È l’unico punto in cui consultazione sincrona e telemetria asincrona convivono dentro un solo modello dati standardizzato, e per questo va valutato esplicitamente prima di mettersi a costruire un’astrazione su misura.

Deploy e orchestrazione

Anche il modo in cui si eroga il servizio condiziona la scelta dei protocolli. A gennaio 2017 la direzione consolidata è la containerizzazione: Docker ha portato la modalità swarm nel core con la 1.12 (annunciata a giugno 2016, GA il 28 luglio), e Kubernetes è arrivato alla 1.5 a dicembre 2016. Per un consorzio con partner che gestiscono infrastrutture diverse — chi on-premise, chi su cloud pubblico — un container come unità di deploy riduce l’attrito di portabilità più di qualunque accordo sui formati.

L’orientamento all’open source qui risponde a un criterio pratico. Ogni componente che entra in una piattaforma pubblica con una vita pluriennale va pesato per maturità, licenza, vitalità della community e sostenibilità della manutenzione oltre la durata del finanziamento. Un protocollo proprietario o un broker senza una comunità attiva diventa un costo differito che ricade sull’ente che eredita il sistema.

Limiti

Questa è una mappa di opzioni, non una scelta architetturale. La selezione vera dipende da misure che a gennaio 2017 non ho ancora: volumi reali dei flussi, frequenze di aggiornamento delle sorgenti pubbliche, vincoli di banda sul campo, competenze dei partner che dovranno mantenere il sistema. La regola che applico mentre raccolgo il materiale è di non introdurre un protocollo finché un flusso non lo richiede per una proprietà che gli altri non danno — un livello di servizio, una garanzia di consegna, una convenzione geospaziale. Ogni protocollo in più è una superficie in più da documentare, monitorare e tenere viva.

Il lavoro di scouting tecnologico da cui esce questa ricognizione confluisce nel deliverable D1.3 dell’obiettivo OR 1.3 di SMARTOUR, coordinato da noze con 01 Sistemi: l’avvio operativo è descritto nell’insight noze https://www.noze.it/insights/smartour-avvio/.

https://grpc.io/blog/ga-announcement/ https://spec.graphql.org/October2016/ https://www.oasis-open.org/2016/07/19/oasis-mqtt-internet-of-things-standard-now-approved-by-iso-iec-jtc1/ https://www.iso.org/standard/69466.html https://www.oasis-open.org/standard/amqp/ https://www.ogc.org/standards/wms/ https://docs.ogc.org/is/15-078r6/15-078r6.html

Immagine di copertina: I templi dorici greci di Paestum visti dal sito archeologico: due grandi templi in pietra calcarea color ocra con colonne intatte,… — foto di Miguel Hermoso Cuesta, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:Templos_Paestum._01.JPG