POLITECNICO DI MILANOCorso di Laurea Magistrale in Ingegneria Informatica

Scuola di Ingegneria Industriale e dell’Informazione

Prototipo di applicazione basata su un

ambiente di API Economy per la fruizione

innovativa del patrimonio culturale

attraverso la valorizzazione delle

infrastrutture di trasporto esistenti

CEFRIEL - Digital Innovation

Relatore: Prof. Alfonso Fuggetta

Tesi di Laurea di:

Alex Casalboni, matricola 782696

Anno Accademico 2014-2015

“People are entirely too disbelieving of coincidence.“

Isaac Asimov

Sommario

Il lavoro svolto fa perno sull’esigenza del territorio di riscoprire e promuovere

i propri beni culturali e di assegnare agli enti responsabili del patrimonio

culturale il ruolo chiave per la valorizzazione territoriale, in contrasto agli

approcci tradizionalmente adottati in ambito turistico.

Il tema proposto si concentra sulla percezione del territorio, seguendo la

stessa linea di valorizzazione culturale. La soluzione oggetto di questa tesi

evidenzia in particolare i benefici di un ecosistema cooperativo orientato

alle API e di un approccio basato su dati ed servizi messi a disposizione dal

territorio stesso, identificando il ruolo chiave dell’infrastruttura autostradale

che permea il territorio come agente abilitante.

Allo scopo di dimostrare la validita di tale approccio e confermare le

potenzialita offerte da una API Economy, si e proceduto con la progettazione

e lo sviluppo di un’applicazione web, facendo uso di API messe a disposizione

dall’ecosistema digitale aperto E015.

I

Ringraziamenti

Ringrazio tutti coloro che contribuiscono, assecondano e incentivano quoti-

dianamente l’ambizione altrui.

III

Indice

Sommario I

Ringraziamenti III

1 Introduzione 1

1.1 Inquadramento generale . . . . . . . . . . . . . . . . . . . . . 1

1.2 Breve descrizione del lavoro . . . . . . . . . . . . . . . . . . . 2

1.3 Struttura della tesi . . . . . . . . . . . . . . . . . . . . . . . . 2

2 API Economy 5

2.1 Le API nel mondo moderno . . . . . . . . . . . . . . . . . . . 5

2.2 Come nasce una API Economy? . . . . . . . . . . . . . . . . . 5

2.3 Benefici, problematiche e casi di successo . . . . . . . . . . . 6

2.3.1 Casi di successo . . . . . . . . . . . . . . . . . . . . . . 7

2.3.2 Ostacoli e controversie . . . . . . . . . . . . . . . . . . 8

2.4 Aspetti tecnologici e implementativi . . . . . . . . . . . . . . 8

3 E015 Digital Ecosystem 11

3.1 Gli obiettivi di E015 . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 Open Digital Ecosystem . . . . . . . . . . . . . . . . . . . . . 12

3.3 Processo di pubblicazione API . . . . . . . . . . . . . . . . . 12

3.3.1 Descrittore del servizio . . . . . . . . . . . . . . . . . . 13

3.4 Processo di pubblicazione applicazioni . . . . . . . . . . . . . 14

3.4.1 Requisiti di accettazione . . . . . . . . . . . . . . . . . 16

3.5 I registri di E015 . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.5.1 MaMi - Schermi in aeroporto . . . . . . . . . . . . . . 17

3.5.2 3cixty - ExplorMI 360 . . . . . . . . . . . . . . . . . . 18

3.5.3 L15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

V

4 Obbiettivi 21

4.1 Stato dell’arte in materia di valorizzazione del territorio . . . 21

4.2 E015 e la percezione del territorio . . . . . . . . . . . . . . . . 22

4.3 Opportunita offerte dall’infrastruttura di trasporto . . . . . . 23

5 Concept 25

5.1 Concept e target . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.2 Mockups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.3 SIRBeC (Regione Lombardia) . . . . . . . . . . . . . . . . . . 28

5.3.1 SIRBeC API in E015 . . . . . . . . . . . . . . . . . . 28

5.4 Museimpresa . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.4.1 Museimpresa API in E015 . . . . . . . . . . . . . . . . 29

5.5 Architettura logica ed esperienza utente . . . . . . . . . . . . 30

6 Il Progetto 33

6.1 Analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . 33

6.1.1 Requisiti funzionali . . . . . . . . . . . . . . . . . . . . 34

6.1.2 Requisiti non funzionali . . . . . . . . . . . . . . . . . 35

6.2 Modello dei dati . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.2.1 Model transformations e strutture dati . . . . . . . . . 38

6.3 Infrastruttura Web e Componenti Software . . . . . . . . . . 43

6.4 Dettagli implementativi e tecnologie utilizzate . . . . . . . . . 45

6.4.1 Frontend Layer, UI e UX . . . . . . . . . . . . . . . . 46

6.4.2 Backend Layer . . . . . . . . . . . . . . . . . . . . . . 49

6.4.3 Geolocalizzazione e simulazioni . . . . . . . . . . . . . 51

6.4.4 Data, API e Caching Layers . . . . . . . . . . . . . . . 53

6.4.5 Funzionalita aggiuntive . . . . . . . . . . . . . . . . . 57

7 Conclusioni 59

Bibliografia 61

VI

Capitolo 1

Introduzione

Questa sezione illustra i concetti generali alla base dell’elaborato, espone le

motivazioni portanti a sostegno del lavoro svolto e riassume i contenuti e la

struttura delle altre sezioni.

1.1 Inquadramento generale

Il contesto in cui si svolge il lavoro e focalizzato sull’esigenza del territorio

nazionale e regionale di riscoprire, curare e promuovere i propri beni culturali

- troppo spesso trascurati o poco incentivati - e di trasferire il ruolo primario

nella valorizzazione degli stessi ai soggetti direttamente interessati e respon-

sabili del patrimonio culturale, in contrasto agli approcci tradizionalmente

adottati dallo stato dell’arte in materia di valorizzazione del territorio.

In particolare, il tema proposto si affianca alla stessa linea di valorizza-

zione territoriale, concentrandosi sull’elemento di percezione del territorio in

ambito turistico. La soluzione analizzata e messa in pratica vuole evidenzia-

re i benefici di un ecosistema aperto che abiliti meccanismi di cooperazione

e competizione, e di un approccio basato su dati ed API messi a disposizione

dal territorio stesso.

In questo scenario, e stato scelto come elemento chiave ed abilitante

il ruolo dell’infrastruttura autostradale, che permea il territorio nella sua

interezza assumendo una posizione mediatrice, in quanto soggetto in grado

di agevolare la fruizione e la percezione del territorio.

1.2 Breve descrizione del lavoro

Lo scopo della tesi e dimostrare la validita di tale approccio, confermando

le potenzialita tecniche ed economiche offerte da una API Economy locale

e proponendo una soluzione in ambito di valorizzazione del territorio. Tale

soluzione include la progettazione e lo sviluppo di un’applicazione web, che

faccia uso di API messe a disposizione dai soggetti del territorio, in quanto

aderenti all’ecosistema digitale E015.

A seguito di un’analisi dello stato dell’arte allo scopo di identificare i

limiti degli approcci tradizionali, il lavoro e consistito nel design di un’appli-

cazione per tablet, a partire dal concept fino all’effettiva implementazione e

pubblicazione nei registri di E015, attraversando tutte le fasi del processo di

pubblicazione con il supporto e la collaborazione del Technical Management

Board di E015.

Dopo una breve fase di prototipazione web a seguito della definizione

del concept iniziale, le fasi di progettazione e sviluppo si sono succedute in

cascata seguendo il flusso tradizionale di progettazione software. Il risultato

di tale processo ha portato allo sviluppo di una applicazione in grado di

valorizzare il patrimonio culturale, sfruttando al meglio le potenzialita dei

nuovi dispositivi mobile e rispettando le linee guida fornite dall’ecosistema

digitale.

1.3 Struttura della tesi

La tesi e strutturata nel modo seguente.

Nella sezione due si analizza il ruolo delle Abstract Programming In-

terfaces e la relativa evoluzione nel contesto dell’API Economy, passando

da utile paradigma di programmazione a vero e proprio prodotto e model-

lo di business. L’analisi si concentra sui benefici ed i casi di successo nel

mercato globale, sulle problematiche introdotte dall’innovazione e sui trend

tecnologici piu rilevanti.

Nella sezione tre si illustrano gli obiettivi, le linee guida e le potenziali

soluzioni offerte da E015, in quanto esempio di una API Economy locale.

Nel dettaglio, vengono esposti i concetti principali alla base dell’ecosiste-

ma digitale, la struttura interna del sistema ed i processi di pubblicazione

adottati, per concludere con un’analisi del lavoro svolto fino ad oggi dai sog-

getti aderenti, soffermandosi su alcune applicazioni gia pubblicate e legate

al contesto applicativo di questa tesi.

Nella sezione quattro si descrivono gli obiettivi del progetto, partendo

dall’opportunita di valorizzare il territorio ed il relativo patrimonio cultura-

2

le, ed esponendo la necessita di individuare un approccio diverso da quello

tradizionalmente adottato in ambito di valorizzazione turistica e territoria-

le. In particolare, si espongono le opportunita offerte dall’infrastruttura di

trasporto autostradale, elencando alcune iniziative gia intraprese nel settore

e analizzando il ruolo strategico dei gestori delle infrastrutture rispetto al

tema della Social Responsibility.

Nella sezione cinque viene delineato il concept dell’applicazione, incentra-

to sul concetto di mobilita in ambito turistico, e definito il target applicativo

sia dal punto di vista tecnologico che dello scenario. La sezione include det-

tagli e rappresentazioni grafiche per descrivere le fasi di mockup, la selezione

delle API utili allo scopo, uno schema preliminare di architettura logica ed

il successivo design dell’esperienza utente desiderata.

Nella sezione sei vengono approfonditi gli aspetti tecnici relativi alle fa-

si di prototipazione ed analisi dei requisiti, riportanto una lista di requisiti

funzionali e non funzionali basati sul concept e nel rispetto delle linee guida

dell’ecosistema. La fase di modellazione ha preso in considerazione il modello

dei dati fornito dalle API scelte allo scopo di uniformare il dominio e model-

lare i concetti chiave dell’applicazione. Le successive fasi di progettazione

ed implementazione sono state ripercorse fornendo dettagli relativi al codice

ed alle problematiche di integrazione affrontate. In linea generale, vengo-

no riportate le principali decisioni progettuali ed esposte le problematiche

tecniche e le rispettive soluzioni proposte.

Nelle conclusioni si riassumono gli scopi, le scelte strategiche, le possibi-

lita di miglioramento dell’ecosistema digitale e alcune possibili integrazioni

future per l’applicazione.

3

4

Capitolo 2

API Economy

Il concetto generico di API - Application Programming Interface - ha avuto

un ruolo chiave nello sviluppo dell’ingegneria del software e nella storia della

programmazione, a partire dalle funzioni/subroutines nei linguaggi proce-

durali, per poi evolversi nel contesto dei linguaggi ad oggetti (OOP), fino a

diventare pervasivo nel core di ogni libreria, framework, protocollo, sistema

operativo e applicazione.

2.1 Le API nel mondo moderno

Nell’accezione piu moderna del termine - e nel contesto dell’API Economy

trattato in questa tesi - ci si riferisce piu comunemente alle Web API, ovvero

un insieme di funzionalita o risorse messe a disposizione da un API provider,

accessibili tipicamente con approccio RESTfull o SOAP, e con lo scopo ben

definito di accedere a determinati servizi o basi di dati.

La potenza e flessibilita di questo approccio sono identificabili nella fa-

cilita di utilizzo e di accesso messe a disposizione dalle recenti tecnologie,

specialmente in ambito web, parallelamente agli sforzi compiuti negli ambiti

del Semantic Web e del Cloud Computing per risolvere le problematiche di

usabilita, privacy, scalabilita, ecc.

2.2 Come nasce una API Economy?

Per favorire la nascita di una API Economy globale, il concetto stesso di API

e stato migrato ed elevato dal semplice ruolo di tecnica di sviluppo software

verso un ruolo abilitante per nuovi modelli di business veri e propri.

L’idea portante e che i beni e le funzionalita di una determinata organiz-

zazione possano essere riusati, condivisi e monetizzati attraverso l’utilizzo di

API globali in grado di estendere notevolmente la portata dei mezzi tradi-

zionali e quindi di introdurre nuovi canali di crescita e nuovi flussi monetari.

In questo scenario, le API vanno rivisitate, considerate e gestite come un

vero e proprio prodotto in grado di offrire valore all’azienda e a tutti gli

stakeholders.

“The API Economy is the commercial exchange of business functions, ca-

pabilities, or competencies as services using web application programming

interfaces (APIs). APIs drive the digital economy and companies that do

not embrace the API economy will be left behind.

Kerrie Holley - IBM Redbooks [1]

2.3 Benefici, problematiche e casi di successo

Trascurando i benefici derivanti dalle potenzialita economiche per un’azien-

da gia in possesso di API riutilizzabili e condivisibili, la presenza di una API

Economy globale sottintende l’estensione di questi benefici a tutto il siste-

ma e ai potenziali utilizzatori, in quanto fattore abilitante per lo sviluppo

e l’interoperabilita di nuovi servizi ed ”API layers”, sfruttando servizi quali

Integration as a service, Cloud orchestration e API management.

“The API revolution is upon us. Public APIs have doubled in the past 18

months, and more than 10,000 have been published to date.

David Sisk - Director of Deloitte Consulting LLP [4]

Figura 2.1: Crescita globale della disponibilita di API (Source: ProgrammableWeb -

2013)

6

2.3.1 Casi di successo

Considerando la rivoluzione tecnologica e l’esplosione di nuove API mes-

se a disposizione di sviluppatori, startups e imprenditori negli ultimi anni,

l’ecosistema globale e in veloce espansione ed emergono rapidamente casi

ed esempi di successo, tra cui Amazon, Salesforce.com, Google, Facebook,

Twitter, PayPal, Netflix, Heroku, iForce.com, ecc.

Ognuno di questi API provider - seppur non tutti siano cresciuti grazie

all’utilizzo di API fin dall’inizio - riceve quotidianamente miliardi di richieste

da tutto il mondo e contribuisce alla crescita di nuovi servizi API-driven in

tutti i settori del mercato, inclusi quello finanziario, turistico ed immobiliare,

tipicamente meno inclini all’innovazione e alla condivisione dei dati.

Un esempio emblematico dell’importanza crescente del ruolo delle API e

l’introduzione di Amazon API Gateway [2] nella vasta suite di servizi gestiti

di AWS - Amazon Web Services, uno dei principali players nell’ambito dei

servizi web e Cloud. Questo servizio, reso pubblico a partire da luglio 2015,

si propone di semplificare e automatizzare gran parte delle procedure rela-

tive alla creazione, pubblicazione, manutenzione, monitoraggio, protezione

e scalabilita di qualsiasi tipo di API, incluse le problematiche inerenti la

gestione del carico, il controllo di accessi e autorizzazioni, il versionamento,

ecc. Rispetto ad una parte considerevole dei servizi AWS - tipicamente IaaS,

Infrastructure as a Service - questo servizio esplicita la sensibilita dell’azien-

da verso un mercato orientato anche a PaaS (Platform as a Service), con lo

scopo di semplificare all’estremo la vita degli sviluppatori in tutte le fasi di

sviluppo di una nuova API.

Un altro esempio di business completamente fondato sulle API, e con

particolare focus sul concetto di ecosistema, e Mashape.com [3]. La piatta-

forma si offre come marketplace di API gia esistenti, non solo in qualita di

aggregatore e vetrina, ma anche con servizi avanzati di API Transformations,

controllo degli accessi, monitoring e reportistica, che permettono a qualsiasi

sviluppatore di iniziare ad utilizzare le API esposte in pochi secondi.

Inoltre, un ecosistema fondato sulle API rappresenta anche un passo

importante verso il cosiddetto ”Internet of Things”, che inevitabilmente

richiede la presenza di web services ed API, non solo per delegare la ca-

pacita computazionale dai sistemi embedded (smartphones, tablets, weara-

bles, sensori, ecc) ai data center, ma anche per favorire l’interconnessione ed

interoperabilita tra dispositivi e sistemi eterogenei.

“APIs are one of the fundamental building blocks on which the Internet of

Things will succeed. APIs are the backbone of the opportunity.

George Collins - CTO of Deloitte Digital US [4]

7

2.3.2 Ostacoli e controversie

Ovviamente l’innovazione tecnologica - specie quando cosı rapida e virale

- pone nuove problematiche, dubbi e contrasti che vanno regolamentati e

gestiti al meglio dai vari paesi ed istituzioni competenti.

Per esempio, l’utilizzo di tecnologie open-source ed API e attualmente

soggetto di controversie in molti paesi, specialmente negli Stati Uniti. In

particolare, i verdetti di molte sentenze legali riguardanti la protezione di

indirizzi IP, diritti di copyright e sulle modalita di utilizzo giuste e legittime

avranno un impatto considerevole sull’evoluzione dell’API Economy.

Le sfide principali da affrontare riguardano indubbiamente problematiche

di sicurezza e privacy, incentivate dal bisogno di aprire l’accesso e condividere

una parte consistente dei dati, sia da parte del provider che degli utilizzatori.

In questo contesto, nuove tecnologie e soluzioni per migliorare e garantire

livelli di sicurezza adeguati stanno velocemente introducendo nuove tipologie

di autenticazione, autorizzazione e identity management.

Un altro punto cruciale riguarda la fiducia necessaria tra provider e con-

sumer, sia verso l’effettiva affidabilita ed efficacia delle API esposte, che verso

la conformita e retro-compatibilita delle stesse durante la loro evoluzione nel

tempo.

2.4 Aspetti tecnologici e implementativi

Dal punto di vista tecnologico, la quasi totalita delle Web API fa perno

su HTTP come livello di trasporto. Questo protocollo - ufficialmente parte

del livello applicativo - e addirittura un requisito nel caso di API di tipo

RESTful, mentre altri livelli di trasporto alternativi sono disponibili per

API di tipo SOAP, la cui influenza e presenza nel panorama delle API a

livello globale e pero drasticamente in calo.

Il trend in maggiore crescita - considerando l’elevata facilita di utilizzo,

la facile integrazione con i piu moderni framework client-side e la possibilita

di automatizzare gran parte del processo di sviluppo - e la combinazione

tra RESTful e JSON, spesso con supporto opzionale del formato XML. Una

scelta ancora preferita in ambito enterprise (in particolare Java e .NET) e

quella di SOAP ed XML, scelta che offre maggiore controllo a livello di sicu-

rezza, validazione dei dati ed espressivita, seppur a discapito della semplicita

e con un overhead (di rete e di sviluppo) spesso non trascurabili.

REST (Representational State Transfer) rappresenta l’architettura soft-

ware alla base del Web stesso, definendo cosa sono e come vanno indirizzate

8

Figura 2.2: Protocolli API piu utilizzati (Source: ProgrammableWeb - 2013)

e manipolate le risorse attraverso il semplice uso di HTTP. La principale

differenza da SOAP e la totale assenza di livelli intermedi di trasmissione

o rappresentazione dei dati, l’assenza di ”stato” (spesso emulata attraverso

l’uso di cookies tra una richiesta e l’altra), l’uniformita dell’interfaccia tra

client e server e la possibilita di cachare le risorse.

SOAP (Simple Object Access Protocol) definisce invece un vero e proprio

protocollo (i.e. un livello intermedio di rappresentazione che si appoggia su

HTTP) per lo scambio di messaggi tra componenti software, tipicamente

per realizzare un Web Service. L’utilizzo del formato XML e un requisito

del protocollo, presente nel body sia delle richieste che delle risposte, fattore

che rende SOAP particolarmente inadeguato per l’invocazione diretta da un

client web (browser).

Figura 2.3: API che supportano solo il formato XML, solo JSON o entrambi.

(Source: ProgrammableWeb - 2013)

9

Infatti, uno dei principali vantaggi e fattori di successo dell’approccio

RESTful risiede nella possibilita di evitare livelli intermedi di comunicazio-

ne tra il browser e le API, alleggerendo notevolmente il carico tipicamente

richiesto al componente server-side dell’applicazione e delegando gran parte

della computazione e della logica di caching ed autenticazione. Un nume-

ro sempre piu elevato di framework per lo sviluppo di applicazioni web sta

adottando la logica secondo cui l’applicazione e composta da un’unica pa-

gina, i cui componenti interagiscono con un set di API (interne o esterne)

al fine di fornire le funzionalita richieste, senza mai ricorrere al page-load.

L’avvento del Cloud Computing ha incredibilmente ridotto le problematiche

relative a scalabilita, load balancing e compartimentazione delle componen-

ti software in servizi web, in particolare grazie alla diffusione di tecnologie

quali la virtualizzazione, i containers e le Platform as a Service (es. Docker,

Heroku, ecc).

Nell’ambito di questa tesi, entrambi gli approcci sono stati utilizzati ed

integrati e nel capitolo 6 verranno affrontate piu nel dettaglio i benefici e le

limitazioni incontrate in fase di sviluppo.

10

Capitolo 3

E015 Digital Ecosystem

E015 [5] si inserisce nel contesto delle API Economy, in quanto esempio di

ecosistema digitale mirato a favorire l’incontro, la cooperazione e l’integra-

zione di beni e servizi a favore dei cittadini.

e015.expo2015.org

3.1 Gli obiettivi di E015

L’iniziativa nasce nel 2012 all’interno del Progetto Strategico ICT per Expo

Milano 2015, ed e basata su un modello coopetitivo in cui le imprese lo-

cali possano collaborare e competere allo stesso tempo sia in preparazione

dell’evento Expo 2015 che per gli anni successivi, grazie ad una coordina-

ta collaborazione tra la societa Expo 2015 SpA e Confindustria, CCIAA di

Milano, Confcommercio, Assolombarda e Unione del Commercio, e grazie

alla regia ed il contributo tecnico-scientifico di CEFRIEL [6] (Politecnico di

Milano).

E015 si propone di mettere a disposizione un insieme di standard tec-

nologici, linee guida, processi, regole ed elementi infrastrutturali abilitanti

a tutti i soggetti aderenti, che si impegnano ad esporre le proprie API (o

applicazioni) a tutti gli altri operatori dell’ecosistema.

3.2 Open Digital Ecosystem

E015 e soprattutto un ambiente digitale aperto: la procedura di adesione

all’ecosistema - disponibile online da settembre 2013 - inizia dalla domanda

di adesione, che verra presa in carico e valutata dal Technical Management

Board (TMB), punto di riferimento tecnico e di supporto dell’ecosistema.

Una volta approvata la richiesta di adesione ed ottenuto accesso all’area

riservata, il partecipante acquisisce la possibilita di contribuire al progetto

e ricoprire i seguenti ruoli.

• Service Provider: esponendo i propri dati e funzionalita sotto forma

di API (REST, WS SOAP o RSS).

• End User Application Provider: progettando, realizzando o arric-

chendo applicazioni, grazie alle API messe a disposizione dall’ecosiste-

ma.

3.3 Processo di pubblicazione API

Il processo di pubblicazione richiede un’interazione controllata da parte del

Service Provider e dell’ecosistema stesso, attraverso 8 fasi distinte, illustrate

di seguito (ed in figura 3.2).

Figura 3.2: Processo di pubblicazione API in E015.

12

1. Selezione funzionalita di interesse da esporre

Il Service Provider identifica quali funzionalita esporre in forma di API

in accordo con le proprie strategie aziendali o ruolo istituzionale.

2. Sviluppo e configurazione servizio

Le API devono essere realizzate o configurate rispettando i criteri

e gli standard tecnologici riportati nelle Linee Guida ufficiali, senza

eccezioni.

3. Elaborazione descrittore del servizio

Ogni API deve essere accompagnata da un documento che descriva

ogni servizio offerto, chiamato ”Descrittore del servizio”. Tale do-

cumento consentira agli End User Application Providers di valutare

ed utilizzare il servizio, valutandone eventuali dettagli tecnici ai fini

all’integrazione.

4. Invio descrittore del servizio e Richiesta di esposizione

Il descrittore, compilato in ogni sua parte, viene inviato all’ecosiste-

ma unitamente alla richiesta di pubblicazione del servizio, al fine di

effettuare le opportune verifiche da parte del TMB.

5. Verifica servizio

Il TMB elabora la richiesta di pubblicazione e mette in atto le verifiche

necessarie alla pubblicazione.

6. Accettazione richiesta di pubblicazione

In caso di esito positivo, il TMB registra ed archivia il descrittore,

che diventa pubblicamente accessibile nell’area riservata di E015. In

caso di esito negativo, il TMB indirizzera il Service Provider verso la

risoluzione di eventuali problematiche o incompatibilita.

7. Notifica pubblicazione servizio

E015 notifica al Service Provider l’avvenuta accettazione della richiesta

di pubblicazione, che e tenuto a riportare l’avvenuta pubblicazione sul

proprio sito web.

8. Esercizio servizio

Il Service Provider eroga normalmente il servizio, come previsto dalle

Linee Guida e secondo gli impegni presi verso l’ecosistema.

3.3.1 Descrittore del servizio

I descrittori dei servizii E015 rappresentano il cardine della procedura di

pubblicazione e dell’interoperabilita, garantendo un’interfaccia uniforme a

13

tutti gli interessati e fornendo informazioni di tipo tecnologico, organizzativo

e sulle policies specifiche del servizio.

Nel dettaglio, ogni descrittore documenta aspetti di operabilita e sicurez-

za, una lista dei glossari utilizzati, dettagli sul monitoraggio, il ciclo di vita,

le policies e l’erogazione dei servizi offerti. Per esempio, un descrittore deve

riportare in modo chiaro l’endpoint per accedere alle API, la tipologia di

interazione (client-server o publish-subscribe) i formati supportati (XML o

JSON), il modello dati utilizzato e le modalita di accesso sicuro (community

o restricted).

3.4 Processo di pubblicazione applicazioni

Anche il processo di pubblicazione di applicazioni E015 si svolge in modo

controllato e coinvolgendo anche i Service Provider interessati, attraverso 12

fasi illustrate di seguito (ed in Figura 3.3).

Figura 3.3: Processo di pubblicazione applicazioni in E015.

1. Consultazione Registry Servizi

In questa fase preliminare e possibile navigare e prendere visione dei

servizi messi a disposizione dall’ecosistema che potranno quindi essere

utilizzati per l’applicazione.

2. Elaborazione Concept applicazione

L’End User Application Provider individua le funzionalita applicative

14

che intendera fornire, valutando le opportunita strategiche dell’appli-

cazione proposta.

3. Richiesta utilizzo servizi

Il concept definito nella fase precedente viene inoltrato al TMB, accom-

pagnato da una descrizione sintetica dall’applicativo e delle rispettive

modalita (web, mobile app, ecc).

4. Notifica Richieste d’uso dei servizi

I Service Provider interessati vengono notificati della richiesta di uti-

lizzo.

5. Valutazione richieste d’uso da parte dei service provider

I Service Provider che offrono API ad accesso protetto (modalita ”re-

stricted”) verificano ed accettano la richiesta di utilizzo.

6. Notifiche accettazione richieste d’uso

Il TMB e l’End User Application Provider vengono notificato dell’av-

venuta accettazione della richiesta d’utilizzo.

7. Sviluppo applicazione

Durante questa fase, E015 fornisce tutte le informazioni necessarie

all’effettivo utilizzo dei servizi selezionati. L’End User Application

Provider puo quindi procedere con l’implementazione dell’applicazione

proposta.

8. Invio Richiesta di pubblicazione e scheda applicazione

L’End User Application Provider procede ad inviare all’ecosistema la

Scheda Applicazione, fornendo tutti gli elementi necessari alla verifica e

validazione da parte del TMB prima della vera e propria pubblicazione

in E015.

9. Verifica Applicazione

Il TMB verifica che l’applicazione rispetti le Linee Guida di E015 e

sia conforme a quando concordato in precedenza, avendo pieno acces-

so all’applicazione. In caso di anomalie o problemi, il TMB fornira

all’End User Application Provider le raccomandazioni necessari alla

risoluzione delle stesse.

10. Accettazione richiesta di pubblicazione applicazione

Il TMB procede all’accettazione della richiesta di pubblicazione, che

viene inserita nel Registro delle applicazioni ufficiali.

15

11. Notifica pubblicazione applicazione

E015 notifica all’End User Application Provider l’accettazione della

pubblicazione, e notifica il Service Provider dell’avvenuta integrazione

delle relative API.

12. Esercizio Applicazione

L’End User Application Provider rimane responsabile dell’erogazione

dell’applicativo, secondo le modalita descritte.

3.4.1 Requisiti di accettazione

Per poter essere accettata e pubblicata in E015, un’applicazione deve posse-

dere una serie di caratteristiche portatrici di qualita, sia dal punto di vista

tecnologico che organizzativo, valutate dal Technical Management Board

durante il processo di pubblicazione.

L’aspetto tecnologico ricopre tematiche relative alla corretta integrazio-

ne con i servizi di E015, oltre all’effettiva qualita del codice, la stabilita degli

aspetti infrastrutturali e gli standard minimi di sicurezza. Particolare im-

portanza viene attribuita alle politiche di caching delle applicazioni: le API

devono essere interrogate compatibilmente alla frequenza di aggiornamento

dei dati restituiti.

Per quanto riguarda gli aspetti non tecnici, il TMB focalizza l’attenzione

su tematiche collegate al rispetto delle procedure e all’interazione con l’u-

tente finale, quali usabilita, accessibilita, grafica, user experience, ecc, con

particolare attenzione sulla linea guida denominata ”Smooth degradation of

Quality of User Experience”, riguardante la presa in carico di problemati-

che durante l’interazione con i servizi utilizzati per evitare di renderli visibili

all’utente finale.

Ovviamente, per garantire che la richiesta di pubblicazione sia appro-

vata dal TMB con successo, l’applicazione presentata dovra essere coerente

con il mockup proposto in fase di richiesta di utilizzo dei servizi. Questo

vincolo non restringe categoricamente la possibilita di aggiungere, adattare

o rimuovere le funzionalita inizialmente proposte, ma assicura ai soggetti

dell’ecosistema che gli accessi alle API garantiti nelle fasi precedenti non

vengano utilizzati per finalita completamente diverse da quelle gia valutate

ed accettate.

Nel caso in cui il risultato finale non corrisponda alla proposta iniziale,

o per qualsiasi motivo non rispetti le Linee Guida di E015, il TMB for-

nira all’End User Application Provider le raccomandazioni necessarie alla

risoluzione delle incompatibilita.

16

3.5 I registri di E015

L’ecosistema E015 mette a disposizione tre registri consultabili pubblica-

mente, allo scopo di elencare una lista completa di aderenti, servizi offerti e

applicazioni pubblicate.

Ad oggi, quasi 100 API sono disponibili a tutti gli aderenti dell’ecosiste-

ma, che ammontano a circa 500 soggetti, includendo associazioni culturali,

aziende turistiche e dei trasporti, camere di commercio, enti locali, agen-

zie di comunicazione e design, consorzi, fondazioni, istituti scolastici e di

ricerca, musei, teatri e universita.

Le prime sei applicazioni realizzate durante la fase di sperimentazione

di E015 si sono concentrate sull’ambito di infomobilita e trasporti, sia at-

traverso installazioni fisse in prossimita di aeroporti e metropolitane, che

attraverso lo sviluppo di portali a applicazioni web e mobile. Allo stato

odierno, piu di 30 applicazioni sono state pubblicate su E015, per ognuna

delle quali e possibile trovare informazioni e documentazione sul sito ufficiale

dell’ecosistema.

A titolo esemplificativo, alcune delle applicazioni tutt’ora operative so-

no elencate di seguito, correlate di esempi grafici e degli elenchi di API

utilizzate.

3.5.1 MaMi - Schermi in aeroporto

L’applicazione, sviluppata da SEA (Societa Esercizi Aeroportuali), e rivolta

ai passeggeri in arrivo agli aeroporti di Linate [11] e Malpensa [12], e for-

nisce informazioni di carattere generale relative alla mobilita dell’area mi-

lanese (traffico, metropolitana e linea 73, orario treni e autobus, telecamere

tangenziali, ecc).

L’applicazione utilizza 8 API messe a disposizione dall’ecosistema: Around

me, AutService arrivi e partenze, Mappe del traffico, Stato del servizio ferro-

viario, Stato del traffico, Stato linee metropolitane, Telecamere tangenziali

e Tempi di attesa mezzi di superficie.

I monitor sono installati nelle aree arrivi e riconsegna bagagli e si stima

che verranno consultati da circa piu di 7 milioni di viaggiatori complessiva-

mente. Altre tre applicazioni sono disponibili per essere consultate da web

e su dispositivi mobile (Android ed iOS).

In particolare, le applicazioni mobile sono scaricabili gratuitamente dai

relativi app store, e la versione Android e disponibile anche in lingua Cinese.

17

Figura 3.4: MaMi - Visualizzazione viabilita

3.5.2 3cixty - ExplorMI 360

ExplorMI 360 [14] e sia una web application che una mobile application,

sviluppata al Dipartimento di Elettronica, Informazione e Bioingegneria del

Politecnico di Milano utilizzando la piattaforma 3cixty allo scopo di offrire

informazioni integrate su diversi aspetti della vita a Milano.

L’applicazione, in tutte le sue forme, permette agli utenti di eseguire

richieste complesse utilizzando una semantica ad alto livello (es. ”un buon

ristorante francese che si trovi a 20 minuti di tragitto in metropolitana dal

sito di Expo 2015”), utilizzando 9 API dell’ecosistema: BikeMe, Calenda-

rio Manifestazioni Fieristiche di Fiera Milano, Fondazione Arnaldo Pomo-

doro, Leonardo in mostra, Trova e prenota la sistemazione, Muoversi in

Lombardia, Ospitalita Italiana, Palinsesto eventi Expo in Citta, Teatri a

Milano.

18

Figura 3.5: ExplorMI 360 - Esempio di ricerca avanzata

19

3.5.3 L15

L15 [13] e una web application sviluppata da Regione Lombardia e si propone

come strumento per scoprire le ricchezze del territorio lombardo, facendo da

vetrina per i principali contenuti disponibili nell’ecosistema.

La mission principale e quella di proporre al cittadino una visione sempre

piu integrata e in continuo ampliamento del territorio in cui vive e dei servizi

in esso presenti. Nell’offrirsi come punto di partenza per un nuovo modo di

operare nel digitale, L15 segue con costanza i continui sviluppi di E15 proprio

per offrire un’esperienza dinamica e sempre aggiornata.

L’applicazione utilizza non solo i dati propri di Regione Lombardia, ma

integra ben 13 API messe a disposizione dall’ecosistema: Arrivi e partenze

”Il caravaggio International Airport”, Arrivi e partenze aeroporti, BikeMi,

Disponibilita parcheggi Aeroporti di Linate e Malpensa, Eventi del Tea-

tro Ponchielli di Cremona, Eventi Reggia di Monza, Fondazione Arnaldo

Pomodoro, Palinsesto eventi Expo in Citta, Parcheggi Fiera Milano, Stato

direttrici, Stato linee metropolitane, Stato parcheggi, Teatri a Milano.

Figura 3.6: L15 - Homepage

20

Capitolo 4

Obbiettivi

Questa tesi nasce dall’idea di creare una applicazione dimostrativa delle

funzionalita di E015, in quanto ecosistema digitale aperto, facendo uso dei

servizi esposti da API Providers locali e percorrendo il normale processo di

pubblicazione applicazioni.

L’obiettivo dell’applicazione si accentra sulla necessita di valorizzare il

territorio regionale e si inserisce quindi nello scopo piu ampio della visione

di E015, non solo nel periodo di svolgimento di Expo 2015, ma anche per

gli anni successivi.

4.1 Stato dell’arte in materia di valorizzazione del

territorio

Nella quasi totalita dei casi, gli sforzi compiuti ad oggi in ambito di valoriz-

zazione del territorio possono essere catalogati in due grandi categorie che

difficilmente centrano l’obiettivo prefissato dal punto di vista dei vantaggi

per il territorio stesso:

• Approcci molto verticali e targetizzati, tipicamente orientati all’uso di

applicazioni o siti monotematici, o comunque focalizzati unicamente

su relazioni di tipo commerciale con l’utente finale (es. Expedia).

Alle applicazioni rientranti in questa categoria manca la vera voce del

territorio, che rimane solo attore indiretto e strumento di business.

• Soluzioni di stampo piu redazionale, spesso nella forma di grandi por-

tali privati che comportano ingenti costi e sforzi dal punto di vista

organizzativo, strategico e per la stesura di contenuto originale di qua-

lita. Anche in questo tipo di soluzione il ruolo del territorio non e

primario ed i contenuti sono riproposti ripetitivamente da autori sem-

pre diversi, spesso senza alcun contatto o interazione con i soggetti

interessati. A titolo di esempio, e possibile citare portali redazionali

quali italia.it, o l’approccio piu commerciale dei Club di Prodotto

promossi da exploratourism.it.

Entrambe le categorie di applicazioni e servizi cercano in qualche modo di

risolvere le problematiche relative al mondo del turismo aggirando le lacune

del settore - spesso puramente tecnologiche - e finendo per non sfruttare le

vere potenzialita del territorio e della sua capacita di auto-valorizzarsi.

Un approccio basato sull’API Economy mira proprio a rendere primari

il ruolo e la voce del territorio, riuscendo nel contempo a delegare e distri-

buire le problematiche relative a costi, qualita, quantita e manutenibilita dei

contenuti ai veri protagonisti del territorio.

In contrasto alle categorie appena menzionate, le applicazioni realizzate

durante la fase di sperimentazione del progetto E015 si sono concentra-

te principalmente sull’ambito mobilita e trasporti, in collaborazione con le

principali aziende ed infrastrutture operanti in regione, quali ATM, Infoblu,

SEA, Milano Serravalle, Trenitalia e TRENORD.

Queste applicazioni includono meccanismi di aggregazione e visualizza-

zione di dati quali lo stato dei voli in tempo reale degli aeroporti milanesi,

l’intensita del traffico in tangenziali e autostrade, i tempi di attesa dei mez-

zi pubblici, le disponibilita dei parcheggi di corrispondenza, lo stato dei

servizi ferroviari, ecc. Tutti questi dati sono esposti su E015 come ”matton-

cini” (building blocks) di facile accesso ed utili per la costruzione di nuove

applicazioni multi-mediali.

4.2 E015 e la percezione del territorio

L’applicazione oggetto di questa tesi procede su questa stessa linea di va-

lorizzazione, proponendo il tema correlato della percezione del territorio,

considerato da tutti un ricco insieme di realta culturali troppo spesso poco

conosciute, se non trascurate.

L’obiettivo diventa quindi amplificare la percezione del territorio lom-

bardo, facendo perno su beni e servizi di stampo architettonico e culturale,

ma senza trascurare la possibilita di integrare dati relativi a novita ed eventi.

Curando un’esperienza utente specifica - per esempio il viaggiatore pen-

dolare su tratta ferroviaria o il turista locale su percorso autostradale - l’ap-

plicazione si pone lo scopo di arricchire l’esperienza del viaggio (quotidiano

o sporadico), aumentando la visibilita e la rilevanza dei Punti di Interesse

22

(POI) che difficilmente vengono valorizzati dall’infrastruttura di trasporto,

per ovvii motivi logistico-tecnici.

4.3 Opportunita offerte dall’infrastruttura di tra-

sporto

Nell’ambito della valorizzazione e percezione aumentata del territorio, le

iniziative non mancano - sia tecnologiche che tradizionali - anche da parte

dei gestori delle infrastrutture di trasporto stesse, che hanno a disposizione

un evidente vantaggio logistico e organizzativo, sia nella promozione che

nella conoscenza diretta del contesto locale.

Per esempio, il progetto ”Sei in un Paese meraviglioso. Scoprilo con

noi.” [7] di Autostrade per l’Italia ha come missione primaria quella di in-

centivare esperienze di viaggio originali a chi viaggia lungo le tratte autostra-

dali italiane, promuovendo il turismo di qualita e valorizzando il patrimonio

artistico, culturale, ambientale ed enogastronomico lungo la Penisola. La

comunicazione di questi obiettivi avviene grazie al posizionamento, lungo le

tratte autostradali e all’interno della aree di servizio, di cartelloni, segnaleti-

che ed installazioni multimediali interattive, attraverso le quali i viaggiatori

possano scoprire e consultare dinamicamente gli scenari e gli itinerari propo-

sti, arricchendo il proprio piano di viaggio, quello in corso o eventuali viaggi

futuri.

Gli itinerari ed i punti di interesse proposti sono ovviamente consultabili

anche online, cosı da permettere una vera e propria pianificazione, a seguito

della scoperta durante il viaggio. Questo aspetto rende l’obiettivo di sen-

sibilizzazione e valorizzazione piu efficace anche sul medio-lungo termine,

considerando la grande visibilita del progetto anche a soggetti non neces-

sariamente in situazioni adatte a cambiamenti di piani o svago durante la

fruizione delle informazioni (es. pendolari, turisti occasionali, ecc).

Iniziative di questo tipo si inseriscono sia nel contesto di cooperazione

locale, che nel quadro piu ampio della ”Social Responsibility”, come sti-

molo ulteriore alla valorizzazione e alla cura dello spazio comune anche da

un punto di vista etico e comunitario. Il ruolo dell’infrastruttura e infatti

strategico, oltre che fungere da mezzo per l’esplorazione del territorio, al

fine di incentivare e portare i viaggiatori a conoscenza delle nuove soluzioni

tecnologiche che E015 permette di realizzare.

23

24

Capitolo 5

Concept

Come da linee guida, il progetto ha seguito le fasi del processo di pubbli-

cazione applicazioni E015. Questo capitolo descrivera lo svolgimento delle

prime due fasi di Consultazione Registry Servizi ed Elaborazione Concept

applicazione, entrambe messe in opera con la supervisione del team tecnico

di CEFRIEL.

Nel dettaglio, verranno esposti i punti chiave dei requisiti applicativi,

l’analisi del target di utenza ed i vari step di prototipazione e mockup al

termine delle prime sessioni di brainstorming, durante le quali sono state

anche selezionate le API di E015 da utilizzare (SIRBeC e Museimpresa),

restringendo quindi lo scope ed il data model dell’applicazione.

5.1 Concept e target

Durante la prima fase della definizione del concept sono state prese in con-

siderazione le potenziali API da utilizzare all’interno dell’applicazione ed il

target di utenza che meglio si prestavano a raggiungere gli obiettivi sopra

esposti.

Il contesto selezionato per la valorizzazione del territorio e la mobilita,

con lo scopo di raggiungere turisti - locali e non - in viaggio lungo un tratto

autostradale all’interno di Regione Lombardia. Questa scelta ha poi indi-

rizzato il target applicativo verso dispositivi mobili (es. tablet), considerati

il mezzo piu flessibile e di piu facile fruizione durante un itinerario di viag-

gio turistico in autostrada. Per massimizzare la flessibilita e non vincolare

la fruizione ad un singolo sottoinsieme di dispositivi, una mobile-first web

application e risultata essere la scelta migliore.

Una volta stabilito il contesto ed il target applicativo, sono state vagliate

possibilita ed alternative di esperienza utente interattive, arrivando alla con-

clusione che un’applicazione con scopo informativo avrebbe raggiunto lo sco-

po di valorizzazione del territorio con piu efficacia, sfruttando direttamente

i dati messi a disposizione dall’ecosistema digitale.

Il razionale si basa sul fatto che, nello scenario tipico di un turista in

viaggio lungo una tratta autostradale locale, l’itinerario di viaggio e nella

maggior parte dei casi gia ben delineato e le finalita di arricchimento do-

vranno adattarsi al piano prestabilito, fornendo informazioni, funzionalita e

suggerimenti in grado di migliorare l’esperienza di viaggio senza imporre un

piano a se stante.

In questo scenario, una famiglia in viaggio potrebbe utilizzare l’appli-

cazione durante la navigazione e venire a conoscenza di Punti di Interesse

(POI) o eventi lungo la strada. L’applicazione potrebbe quindi suggerire

deviazioni interessanti, tra un casello o una sosta e l’altro, eventualmente

fornendo meccanismi di filtering per meglio targetizzare tipologie di POI

(castelli, ville, chiese, musei, ecc) in base alle preferenze del singolo utente.

Le due API selezionate per avere accesso ai punti di interesse interessanti

nel contesto applicativo sono le seguenti.

• SIRBeC[8]: API offerta da Regione Lombardia (Sistema Informa-

tivo dei Beni Culturali), che rappresenta l’intera catalogazione del

patrimonio culturale lombardo, includendo svariate tipologie di beni.

• Museimpresa[9]: API offerta dall’Associazione Italiana Archivi e

Musei d’Impresa, che fornisce una lista completa di archivi e musei

aziendali in tutta Italia.

5.2 Mockups

Al termine del primo brainstorming, sia concettuale che di design, si e pro-

ceduto a disegnare il primo wireframe applicativo (Figura 5.1) allo scopo di

presentare la richiesta di accesso alle API selezionate ed illustrare il concept

al TMB.

In seguito e stato realizzato un vero e proprio mockup grafico (Figura

5.2) per delineare l’esperienza utente desiderata ed i vincoli imposti dalle

linee guida di E015.

Queste rappresentazioni grafiche del concept, accompagnate da una de-

scrizione sintetica dall’applicativo e delle rispettive modalita di fruizione e

distribuzione, sono state inviate al TMB per la fase di approvazione della

richiesta di accesso alle API.

26

Figura 5.1: Wireframe applicativo

Figura 5.2: Mockup grafico

27

5.3 SIRBeC (Regione Lombardia)

Regione Lombardia [10] ha istituito il SIRBeC (Sistema Informativo dei

Beni Culturali) nel 1992 come strumento di conoscenza, documentazione e

supporto alle decisioni in materia di tutela, conservazione e valorizzazione

del patrimonio culturale della regione.

Le campagne di catalogazione sono state realizzate per 13 anni - qua-

si 350 progetti - durante i quali il sistema e stato allineato agli standard

catalografici nazionali.

I dati presenti nel sistema sono dunque aggiornati a dicembre 2005 e

forniscono un’enorme base dati composta da molte categorie di punti di in-

teresse architetturali (piu di 12’000 immobili), tra cui complessi monumen-

tali, edifici pubblici e di culto, edilizia rurale di interesse storico, architetture

fortificate, residenze private, fabbricati di archeologia industriale, ecc.

In particolare, nel contesto di questa applicazione risultano avere parti-

colare rilevanza - in base alle tratte autostradali considerate e alla tipologia

di fruizione - i beni architetturali quali chiese, ville e castelli.

5.3.1 SIRBeC API in E015

Come documentato nel descrittore del servizio, le API SIRBeC esposte al-

l’interno dell’ecosistema E015 rispettano una metodologia di accesso di tipo

request-response ed una interfaccia WS SOAP (Web Service - Simple Object

Access Protocol), in formato XML e con autenticazione SSL.

I punti di interesse disponibili vengono rappresentati con una struttura

dati uniforme e facile da manipolare via software. Per ogni bene vengono

forniti dati utili quali la denominazione ufficiale, le coordinate GPS (Lat-

Long), il gruppo di appartenenza e la tipologia, l’indirizzo del bene, l’URL

della scheda disponibile online e una lista di immagini, oltre a dati riferiti a

frazione, comune e provincia di appartenenza.

Trascurando gli aspetti tecnici, trattati nel prossimo capitolo, le API

SIRBeC forniscono tutti i dati previsti in fase di mockup. In particolare, la

possibilita di avere piu di una immagine da mostrare all’utente e la disponi-

bilita di POI geolocalizzati sul territorio hanno reso questa API ideale per il

contesto applicativo. Inoltre, le API mettono a disposizione metodi appositi

per effettuare query geolocalizzate e mirate a specifiche categorie di beni.

L’efficienza di poter interrogare il database a partire da un determinato pun-

to nello spazio (es. un casello autostradale) indicando un raggio d’azione e

stata particolarmente utile allo scopo di ridurre la complessita computa-

zionale del progetto, considerata la mole di dati a disposizione, seppur le

28

modalita di interrogazione richiedano la definizione manuale di un perime-

tro di ricerca rettangolare, procedura leggermente piu complessa rispetto

alla semplice ed intuitiva combinazione di centro e raggio.

5.4 Museimpresa

Nata a Milano nel 2001 ad opera di Assolombarda e Confindustria, Museim-

presa si propone di identificare e promuovere le imprese che hanno scelto di

esporre al pubblico il proprio patrimonio culturale.

Attraverso la creazione di un insieme di archivi e musei aziendali e la pro-

mozione del concetto di responsabilita culturale dell’impresa, la mission prin-

cipale e quella di ricordare ed evidenziare le eccellenze nei principali settori

del Made in Italy (design, food, moda, motori, economia e ricerca) e quindi

impedire la dispersione ciclica di importanti patrimoni imprenditoriali.

L’associazione raccoglie al momento piu di 170 associati - tra musei,

archivi e fondi archivistici - di cui piu di 50 localizzati entro i confini di

Regione Lombardia.

5.4.1 Museimpresa API in E015

L’API di Museimpresa e risultata nel complesso di piu facile fruizione, in

quanto rispetta un’interfaccia REST in formato JSON, senza particolari

meccanismi di autenticazione.

La struttura dati e coerente e di facile accesso e le API offrono anch’esse

funzionalita di query avanzate, che includono non solo la possibilita di filtrare

per categoria di appartenenza (non funzionale per gli scopi applicativi), ma

anche meccanismi di ricerca geolocalizzata, utilizzando solo la combinazione

di un punto e del raggio di ricerca. Questa modalita e particolarmente

comoda per lo scenario autostradale, in quanto le ricerche geolocalizzate

avranno come punto di partenza la posizione dei caselli autostradali lungo

il percorso ed un raggio prefissato (es. 15km).

Per ogni punto di interesse vengono forniti dati utili riguardo il nomi-

nativo, una descrizione completa dell’associato, un set di parole chiave, una

categoria, una lista di contatti (email, telefono, sito, ecc), l’indirizzo comple-

to, le coordinate GPS (Lat-Long), una lista di servizi offerti dall’associato, il

nome del proprietario ed una lista opzionale di immagini. Sfortunatamente,

nessuno dei POI di interesse per questa applicazione dispone attualmente di

immagine correlata, quindi si e provveduto ad associare ai POI selezionati

un’immagine rappresentativa in modo semi-manuale.

29

5.5 Architettura logica ed esperienza utente

Figura 5.3: Architettura logica e caso d’uso

L’esperienza utente prevista per l’applicazione ha come target di utenza

principale i dispositivi mobili ed in particolare il tablet, in quanto dotato di

sistema integrato di localizzazione, connessione Internet e schermo sufficien-

temente grand per la fruizione di contenuti sia testuali che grafici. Come

da architettura logica (Figura 5.3), l’applicazione web fornira un’interfaccia

uniforme sui POI e si occupera di ottenere i dati dalle API selezionate in

background. In particolare, avra ruolo di aggregazione dei dati, in quanto

non tutte le API selezionate sono facilmente interrogabili direttamente dal

dispositivo target. Inoltre, considerata la natura eterogenea dei data model,

si pone la necessita di effettuare operazioni di trasformazione, filtro e caching

dei dati. Nel prossimo capitolo verra trattata piu nel dettaglio l’architettura

software interna all’applicazione e l’organizzazione dei componenti.

Essendo la mobilita un punto cardine dell’esperienza di viaggio - sottin-

tendendo la possibilita di soste, deviazioni e cambi di piano imprevisti - il

design dell’interfaccia e incentrato sulla posizione in tempo reale dell’utente

lungo il tratto autostradale di riferimento. L’idea e quella di sfruttare la

posizione attuale del dispositivo per mostrare all’utente eventuali punti di

interesse o itinerari disponibili uscendo al prossimo casello autostradale. In

questo modo l’utente - o il navigatore nel caso in cui il tablet venga usato

durante la guida - avra modo di vagliare eventuali deviazioni, alla scoperta

del territorio circostante, che difficilmente sarebbe stato esplorato per caso

da parte di un turista occasionale.

Parallelamente all’esperienza principale, l’applicazione fornira gli stru-

menti necessari a selezionare le tipologie di POI a cui l’utente e piu interes-

sato, navigare una lista di POI raggiungibili nelle circostanze, salvare uno o

piu POI nella lista personale dei preferiti (per esempio, in vista di un viag-

gio futuro) e visualizzare i dettagli di ogni singolo POI, completo di nome,

descrizione, indirizzo, posizione sulla mappa, contatti, immagini, ecc.

30

Altre funzionalita utili al miglioramento dell’esperienza utente potrebbe-

ro essere una ricerca testuale (o vocale) per velocizzare la fruizione o cercare

un bene architettonico di cui si conosca gia il nome, la possibilita di con-

dividere deviazioni o itinerari, oppure un sistema di votazione (o raccolta

feedback) per stabilire quali POI siano piu interessanti da visitare e per

condividere le proprie esperienze.

Per quanto riguarda l’aspetto tecnologico, l’applicazione si concentrera

sul target principale (tablet) adottando un approccio mobile-first, ma il de-

sign previsto si prestera a rimanere funzionale anche in ambito desktop, per

agevolare la fruizione a priori o posteriori del viaggio.

31

32

Capitolo 6

Il Progetto

A seguito dell’analisi concettuale e della definizione del target applicativo, le

fasi di progettazione ed implementazione si sono svolte seguendo il classico

workflow a cascata (top-down), preceduto da una breve fase di prototipa-

zione a partire dal mockup concordato inizialmente, allo scopo di delineare

piu nel dettaglio l’esperienza utente.

Il prototipo e consistito in una semplice versione statica del sito composta

da un’unica pagina, compilata manualmente utilizzando dati coerenti con

quelli forniti dalle API scelte. A seguito di poche iterazioni e miglioramenti

incrementali, il prototipo ha raggiunto la maturita necessaria a delineare e

risolvere i dubbi riguardanti l’esperienza utente e le linee guida di E015 (sia

in ambiente web che su tablet), fornendo una base stabile per procedere con

le fasi progettuali e l’effettiva integrazione delle API.

6.1 Analisi dei requisiti

La definizione del concept e la preventiva fase di prototipazione hanno stabi-

lizzato l’insieme di funzionalita da includere nell’applicazione web e ridimen-

sionato la quantita di informazioni utili ai fini applicativi. A tale proposito,

va menzionato che le API selezionate mettono a disposizione strutture dati

eterogenee, alcune delle quali non sono funzionali allo scopo di questa te-

si, mentre altre necessitano di operazioni di trasformazione, aggregazione o

pre-elaborazione al fine di uniformare la rappresentazione per l’utente fina-

le. Tale struttura uniforme verra descritta nella prossima sezione, in quanto

parte del data model applicativo.

Per quanto riguarda i requisiti tecnici, l’utilizzo di API semplifica note-

volmente la gestione del dato e permette di delegare le operazioni di ma-

nutenzione e memorizzazione dei dati. Avendo la possibilita di recuperare

gran parte dei dati attraverso l’invocazione di API, la necessita di progettare,

ottimizzare e manutenere i componenti tipici di un’applicazione web vengo-

no notevolmente semplificati, per esempio i componenti relativi a database,

backend, autenticazione e autorizzazione amministratori, ecc.

6.1.1 Requisiti funzionali

I requisiti funzionali possono essere brevemente riassunti nei seguenti punti

chiave.

• L’utente deve poter accedere al sito - preferibilmente tramite dispo-

sitivo tablet - senza meccanismi di autenticazione. Non sono dunque

necessarie sezioni protette del sito o meccanismi di login.

• L’utente deve poter indicare/selezionare il tratto autostradale che in-

tende percorrere (o che sta percorrendo), specificando la direzione e la

tratta.

• Il sistema deve essere in grado di geolocalizzare il dispositivo (in caso di

tablet) ed aggiornare la visualizzazione dei punti di interesse, focaliz-

zandosi sul prossimo casello autostradale (nota: non necessariamente

il piu vicino).

• I punti di interesse rilevanti per un dato casello devono poter essere

visualizzati e navigati agevolmente, ed ordinati in base alla distanza

relativa dal casello in questione. Per distanza relativa si intende la

distanza effettiva, trascurando la strada percorsa dalla posizione at-

tuale fino al prossimo casello. In particolare, la distanza deve essere

indicativa ai fini pratici (i.e. non in linea d’aria), cosı da poter fornire

un’idea riguardo la durata di un’eventuale deviazione.

• La lista di POI deve includere le informazioni essenziali alla fruizio-

ne dei contenuti: nome, tipologia di bene, distanza dal casello ed

immagine rappresentativa. Come da mockup, la tipologia puo esse-

re schematizzata graficamente per lasciare piu visibilita a nome ed

immagine.

• Per ogni punto di interesse, deve essere possibile visualizzare una

scheda di dettaglio contenente dati aggiuntivi, quali indirizzo, con-

tatti, sito web, API di provenienza, eventuale descrizione ed immagini

aggiuntive.

34

• Durante la navigazione dei contenuti l’applicazione deve continuare a

monitorare la posizione del dispositivo ed aggiornare la lista dei POI

di riferimento, indicando anche il nome e la distanza dalla prossima

uscita.

• L’utente deve poter selezionare - in ogni momento, possibilmente an-

che in uno step di pre-configurazione - le categorie di beni culturali a

cui e interessato. Deselezionare una categoria comporta la scomparsa

dei relativi POI, mostrando eventualmente una lista vuota che inviti

l’utente a rivedere le proprie preferenze.

• L’utente deve poter effettuare semplici ricerche testuali, per identifica-

re piu velocemente un particolare bene gia di sua conoscenza. In caso

di ricerca con esito positivo, la relativa scheda di dettaglio deve essere

visualizzata.

• Dalla scheda di dettaglio, l’utente deve poter ”salvare” il bene visualiz-

zato in una lista personale di POI preferiti e visualizzabili in qualsiasi

momento tramite il menu laterale.

Per quanto riguarda la funzionalita di ”salvataggio” dei POI preferiti, o

a cui l’utente pensa di prestare attenzione in futuro, l’assenza di qualsiasi

tipo di autenticazione comporta la natura volatile di tali dati. In particolare,

la lista personale di POI potrebbe essere salvata sfruttando meccanismi di

storage locali, disponibili in gran parte dei dispositivi moderni.

A seguito di un’analisi dettagliata dei dati forniti dalle API seleziona-

te, sono emerse alcune incongruenze che hanno portato ad optare per una

visualizzazione solo parzialmente uniforme della scheda di dettaglio. Per

esempio, i dati forniti da SIRBeC non contengono alcuna descrizione te-

stuale, in quanto quelle disponibili nel sistema sono di taglio prettamente

tecnico-architettonico e poco adatte ad un pubblico turistico. In compenso,

e a contrario delle API di Museimpresa, le API di Regione Lombardia met-

tono a disposizione una collezione di immagini per ogni POI, anche piu di 5,

che possono essere utilizzate per mostrare una gallery di foto, in sostituzione

della descrizione mancante.

6.1.2 Requisiti non funzionali

Allo scopo di rispettare le Linee Guida di E015, i termini di utilizzo delle

API ed alti requisiti non esplicitamente legati alle funzionalita applicative

visibili all’utente, i seguenti punti riassumono le principali condizioni da

rispettare.

35

• Le risorse API, ove possibile, devono essere memorizzate in un livello

intermedio di cache, per evitare di sovraccaricare l’infrastruttura del-

l’API Provider e per garantire all’utente un’esperienza piu reattiva e

senza attese prolungate.

Considerando la necessita di recuperare piccoli sottoinsiemi di POI in

base alla posizione dell’utente e alla disponibilita di query geolocalizza-

te gia ottimizzate allo scopo, il livello di cache potra usare la posizione

dei caselli come cache-key, ed eventualmente memorizzare anche una

versione globale di tutti i POI nel caso fosse necessario eseguire query

piu complesse e non nativamente offerte dalle API.

• Seppur il target principale siano i dispositivi tablet, l’applicazione do-

vrebbe garantire un’esperienza accettabile anche su dispositivi desk-

top, ed eventualmente anche smartphone.

• Le tratte autostradali disponibili all’utente finale dovrebbero essere

dinamiche, possibilmente configurabili attraverso una semplice inter-

faccia di backend.

• Come da linee guida ufficiali, il logo dell’ecosistema deve essere visibile

e riconoscibile all’interno dell’applicazione, cosı come deve essere pos-

sibile ricondurre i POI alla relativa API, identificata dal logo ufficiale

dell’API Provider.

• L’applicazione deve rispettare la filosofia di ”Smooth degradation of

Quality of User Experience”, secondo cui l’esperienza utente non de-

ve degradarsi eccessivamente, o bruscamente, a causa di eventuali

problemi tecnici o ”downtime” delle API utilizzate, evitando in par-

ticolar modo di mostrare messaggi di errore provenienti dalle API

direttamente all’utente finale.

• A puro scopo simulativo, l’applicazione deve prevedere la possibilita di

navigare i caselli visualizzati, forzando il passaggio al casello successivo

e/o simulando la geolocalizzazione del dispositivo.

6.2 Modello dei dati

In base ai requisiti sopra elencati, il modello logico dei dati risultante (Figura

6.1) e relativamente semplice, in quanto la modellazione dei dati principali

usati dall’applicazione deve necessariamente adattarsi allo schema dei dati

fornito dalle API, seppur sia necessaria una fase di riduzione e trasformazione

per garantire l’uniformita del modello (sezione 6.2.1).

36

Figura 6.1: Data Model

I concetti e le relazioni modellati sono i seguenti.

• POI: rappresenta l’entita generica dei punti di interesse, anche se in

parte semplificata rispetto a quelle fornite dalle API. Alcuni attributi

(es. ”API”) sono in realta campi fittizi, o astratti, valorizzati nelle

sotto-classi. Altri attributi (es. ”images” o ”category”) potrebbero

essere modellati come classi/entita esterne, ma si e preferito modellare

un’unica classe POI con semplici attributi per rendere piu esplicita la

dipendenza degli attributi dal data model delle API, gia definito e non

modificabile.

• SIRBeC-POI e Museimpresa-POI: pur essendo specializzazioni

del POI generico, queste due sotto-classi non definiscono nuovi at-

tributi o relazioni, ma riducono lo scope e precisano il contesto di

alcuni attributi. Per esempio, l’attributo ”category” puo assumere

solo valore ”museum” per i POI di Museimpresa. Allo stesso modo,

l’attributo API diventa una costante. Inoltre, vale la pena ricordare

che i SIRBeC-POI non hanno descrizione, mentre i Museimpresa-POI

non hanno alcuna immagine.

• Highway: rappresenta il concetto di tratta autostradale. A questo

livello di modellazione non sono previsti ulteriori attributi, oltre al no-

me della tratta, seppur si possa ipotizzare che campi aggiuntivi relativi

37

all’esperienza web saranno utili (per esempio, un attributo ”slug” per

la navigazione delle pagine).

• Exit: rappresenta il concetto di uscita autostradale (o casello au-

tostradale). Molto intuitivamente, un’autostrada e composta da piu

uscite, anch’esse fornite di un nome testuale (es. ”Saronno”). Inol-

tre, ad ogni uscita autostradale e associata una posizione nello spazio

(latitudine-longitudine), che verra utilizzata per le query geolocalizzate

e per definire meglio la relazione di prossimita tra ”Exit” e ”POI”.

Nota: l’utilizzo della lingua inglese in grafici, modelli e codice e stato

adottato sia per questioni di uniformita con le API, che per mantenere un

livello accettabile di generalita e manutenibilita.

6.2.1 Model transformations e strutture dati

La modellazione dei beni culturali (POI) ha richiesto un’analisi delle in-

terfacce eterogenee esposte dalle API selezionate ed un successivo step di

mapping per garantire una sorta uniformita e coerenza all’interno del codi-

ce e della documentazione, sia per utilizzare una nomenclatura omogenea

che per fornire un livello di astrazione e flessibilita agli step successivi del-

la progettazione, per esempio di caso di introduzione di API aggiuntive in

iterazioni future dell’applicazione.

A tale scopo, sono stati identificati gli attributi in comune ad entrambe le

API e ri-mappati attraverso operazioni di manipolazione ed aggregazione (es.

l’attributo ”indirizzo” e suddiviso in quattro sotto-attributi ben strutturati

nelle API di Museimpresa ed in cinque attributi indipendenti nelle API

SIRBeC).

Oltre alla struttura del modello, anche l’uniformita a livello di formato

necessita una trasformazione, per esempio la conversione da formato XML

a formato JSON nel caso dei POI forniti da SIRBeC. In entrambi i casi, le

trasformazioni e conversioni avvengono tramite l’utilizzo di strutture dati

ad alto livello (es. classi, oggetti, ecc.) e la relativa serializzazione verso

il formato JSON non introduce maggiore complessita al sistema, in quanto

numerose librerie sono disponibili in qualsiasi linguaggio e framework. Lo

stesso vale per le procedure di parsing delle strutture JSON o XML fornite

dalle API.

SIRBeC Data Model

Il modello dei dati adottato da SIRBeC e risultato particolarmente flessi-

bile e di facile rappresentazione, in quanto la maggior parte degli attributi

38

Figura 6.2: SIRBeC Data Model

disponibili viene restituito all’interno di un ”hash”, ovvero come una li-

sta di KeyValueItem (Figura 6.2), seppur questa scelta di design nasconda

parzialmente la vera struttura dei dati.

Gli attributi esplicitamente dichiarati come Nome, Lat e Long non neces-

sitano di alcuna trasformazione particolare per adattarsi al modello generico

di POI, trascurando il nome del campo.

I valori disponibili per KeyValueItem.Key sono i seguenti.

• OBJECTID, ID, TIDK, IDK, DSK, GERARCHIA, DESCR GERARCHIA,

ID OGTP, ID OGTT, PVCI, OGTD: valori non utilizzati.

• DESCR OGTP: rappresenta la macro-tipologia di bene (es. ”archi-

tettura fortificata”).

• DESCR OGTT: rappresenta la tipologia di bene (es. ”castello”).

• PVCP: rappresenta la sigla della Provincia in cui si trova il bene.

• PVCN: rappresenta il nome della Provincia in cui si trova il bene.

• PVCF: rappresenta la frazione in cui si trova il bene (opzionale).

• PVCL: rappresenta la localita in cui si trova il bene (opzionale).

• UBVD: rappresenta l’indirizzo del bene.

• URL e URL1: link alla scheda HTML e al sito geografico del bene.

• IMMAGINI ROOT: percorso di base per le immagini del bene.

• IMMAGINI: lista di files da concatenare a IMMAGINI ROOT per

ottenere le immagini del bene (es. ”file1.jpg|file2.jpg|....”).

Come e possibile notare, l’indirizzo completo del bene e ripartito all’in-

terno di cinque KeyValueItem autonomi. Allo stesso modo, gli URL delle

immagini sono stati razionalizzati per motivi di efficienza e flessibilita.

39

Da un punto di vista puramente tecnico, la struttura XML fornita da

SIRBeC rappresenta un modo molto flessibile di modellare gli attributi,

spesso opzionali, dei beni culturali, seppur introduca un overhead notevole

sia per quanto riguarda la trasmissione dei dati che per le modalita di accesso

agli stessi. In particolare, non risulta possibile un accesso in tempo costante

ad un attributo arbitrario, in quanto gran parte dei dati utili e incapsulata in

una lista di key-value objects. Ovviamente l’ostacolo e facilmente superabile

con semplici tecniche di mapping o query XML avanzate. Nel nostro caso

la conversione a JSON ed il mapping ad attributi espliciti garantira migliori

prestazioni di trasporto ed accesso.

Un esempio della struttura XML fornita da SIRBeC, per la rappresen-

tazione di un POI:

<POI>

<Id>156</Id>

<Nome>Castello di Teodolinda</Nome>

<Lat>45.155005276888524</Lat>

<Lon>9.3707987844857179</Lon>

<IdCategoria>1</IdCategoria>

<InfoList>

<KeyValueItem>

<Key>PVCN</Key>

<Value>Pavia</Value>

</KeyValueItem>

<KeyValueItem>

<Key>IMMAGINI_ROOT</Key>

<Value>http://www.lombardiabeniculturali.it/...</Value>

</KeyValueItem>

<KeyValueItem>

<Key>IMMAGINI</Key>

<Value>542_pv045001.jpg|542_pv045003.jpg</Value>

</KeyValueItem>

.....

</InfoList>

</POI>

Museimpresa Data Model

Il modello dei dati adottato da Museimpresa e molto piu esplicito e la strut-

tura risulta di piu immediata comprensione, anche dal punto di vista delle

40

Figura 6.3: Museimpresa Data Model

trasformazioni necessarie a raggiungere l’uniformita proposta, grazie all’ado-

zione del glossario ”Punti di Interesse del Territorio” [15] condiviso e messo

a disposizione da E015.

Gli attributi con mapping diretto alla nuova struttura sono Name e

Description. Per quanto riguarda gli altri attributi che definiscono un POI

(o una Venue, nella terminologia di Museimpresa) sono i seguenti.

• Abstract, MoreInfo, OpeningTimes, Owner, Tag, Available-

Service: valori non utilizzati.

• Address: questo attributo strutturato verra ”appiattito” verso il

nuovo attributo address, come semplice valore testuale.

• Geolocation: anche in questo caso la trasformazione comportera solo

un ”appiattimento” dell’oggetto strutturato, incluso un semplice par-

sing da stringa a valore decimale dei campi XCoord e YCoord, verso i

nuovi attributi lat e long.

• MediaResource: questa lista di attributi strutturati contiene sia ri-

ferimenti ad immagini (isLogo: true) che al sito web, anche se al mo-

mento nessun URL e disponibile per le immagini (il campo Uri risulta

essere sempre vuoto).

• Contact: questa lista di campi strutturati contiene informazioni utili

per contattare i responsabili del bene. Il campo Type puo assumere i

valori ”e-mail” e ”phone”.

Le API di Museimpresa restituiscono dati in formato JSON e le trasfor-

mazioni necessarie saranno relativamente semplici ed intuitive. Un esempio

della struttura JSON fornita da Museimpresa per rappresentare un POI:

41

{

"Id": 7925,

"Name": "Archivio Storico del Gruppo Sisal",

"Description": "...",

"Category": "Economia e societa",

"Contact":[

{

"String":"meic@sisal.it",

"Type":"e-mail"

},

...

],

"Address": {

"Street": "Via IV Novembre 11",

"City": "Peschiera Borromeo (MI)",

"ZipCode": "20068",

"Country": "Italy"

},

"Geolocation": {

"Geocoordinates": {

"XCoord": "9.3034935",

"YCoord":"45.4358139",

"SRSCode":"Coordinate system"

}

},

"AvailableService":[

"Disponibilita fotocopie e riproduzioni",

"assistenza tesi di laurea", "accesso disabili"

],

"Owner": "Cristiana Schiopu",

"MediaResource": [

{

"Name": "Link sito web",

"Uri": "www.sisal.com"

},

...

],

"OpeningTimes": "Attualmente in fase di riordino",

"MoreInfo": "..."

}

42

6.3 Infrastruttura Web e Componenti Software

Dal punto di vista infrastrutturale, entrando nei dettagli dello schema logico

proposto in Figura 5.3, l’applicazione fara uso di due componenti aggiuntivi

- un web server ed un database - tipicamente utilizzati come base d’appoggio

in ambito web. Entrambe le tecnologie scelte - nginx e SQLite - sono open-

source e facilitano l’interfacciamento con l’utente e con i dati.

Nnginx e un web-server focalizzato sulle problematiche di concorren-

za, performance ed utilizzo della memoria, con funzionalita aggiuntive di

reverse-proxy, load balancing e HTTP caching.

SQLite e un DBMS ACID conforme alle specifiche SQL e particolarmente

flessibile grazie alla possibilita di essere incorporato in qualsiasi applicazione,

di solito utilizzato in ambiti in cui la mole di dati ed il carico di lavoro

previsto non richiedono gran parte delle funzionalita offerte da DBMS piu

complessi come MySQL, PostgreSQL, ecc. Inoltre, SQLite e presente come

libreria nativa in alcuni dei linguaggi web piu popolari, tra cui Python e

PHP.

In Figura 6.4 viene descritta graficamente l’infrastruttura web, rappre-

sentata all’interno di un semplice container che potra essere un qualsiasi ser-

ver in ambiente Linux (o una macchine virtuale). Per semplificare lo scena-

rio, considerati i bassi carichi previsti, non sono stati introdotti componenti

per gestire problematiche di replicazione o scaling.

Nota: il componente Database e stato rappresentato a se stante, in quan-

to non parte integrante dell’applicazione, seppur a livello infrastrutturale

SQLite sia incorporato nell’applicazione, dato che non supporta interazioni

client-server.

Figura 6.4: Infrastruttura Web

43

Entrando nei dettagli dell’applicazione web e dell’organizzazione dei suoi

componenti software, in Figura 6.5 vengono rappresentati tutti i componenti

applicativi identificati ed i relativi flussi di dati, sia interni (layers e database)

che esterni (API, utenti e amministratori).

Figura 6.5: Infrastruttura Applicazione

Si procede nella descrizione dettagliata dei singoli componenti ed attori.

• Frontend Layer: questo livello e responsabile di tutto cio che riguar-

da la presentazione dei dati a la loro fruizione da parte dell’Utente. In

ambito web, questo comporta la gestione di routing, template HTML,

codice client-side (JavaScript), stili, ecc.

• Backend Layer: il livello di backend e necessario per fornire agli

Amministratori una interfaccia minimale per l’aggiunta e manuten-

zione di dati dinamici, per esempio le informazioni relative ai tratti

autostradali disponibili nell’applicazione.

• Data Layer: questo componente svolge una funzione di intermedia-

zione (o middleware) tra gli utilizzatori dei dati e le sorgenti degli stes-

si. In particolare, le sorgenti dei dati considerate sono tre: il Database,

44

le API di SIRBeC e le API di Museimpresa. Queste sorgenti vengono

quindi mascherate dal Data Layer, che offre un accesso alle informa-

zioni piu ad alto livello, con particolare riferimento all’aggregazione

dei POI provenienti da sorgenti multiple.

• API e Caching Layer: questo livello si interfaccia direttamente con

le API selezionate ed e responsabile di tutte le operazioni di trasfor-

mazione dei dati e delle relative logiche di caching. Ogni API im-

plementa infatti diverse logiche di caching, riferite alle tempistiche di

aggiornamento dei dati in questione.

• User: il normale utente target dell’applicazione, come descritto alla

sezione 5.1.

• Admin: questa tipologia di super-utente ha la possibilita di accedere

al backend e modificare/aggiornare alcuni dati sensibili per la logi-

ca dell’applicazione, attraverso un’interfaccia web per la gestione del

dato.

• Database: nel database verranno memorizzate informazioni relative

alle tratte e ai caselli autostradali. Tali dati avrebbero potuto essere

caricati dall’applicazione da un semplice file di configurazione o utiliz-

zando altre API, ma si e preferito optare per una soluzione piu flessibile

e che garantisce maggiore controllo sui dati da qualsiasi soggetto (es.

non solo allo sviluppatore). Nota: nessun dato relativo ai POI viene

salvato su questo database.

6.4 Dettagli implementativi e tecnologie utilizzate

Durante la fase di prototipazione sono state impiegate solamente tecnologie

client-side, facendo uso di un semplice web-server in grado di servire file

statici. Il prototipo risultante e consistito in pochi file HTML per descri-

vere la struttura delle pagine, stili CSS per definire l’interfaccia utente e

codice JavaScript per definire i comportamenti e le interazioni con l’utente.

Gran parte del codice implementato durante questa fase e ovviamente sta-

to riutilizzato, e reso dinamico, per le successive fasi descritte nella sezione

6.4.1.

Per quanto riguarda l’implementazione dei componenti server-side e stato

scelto uno dei linguaggi piu utilizzato negli ultimi anni in ambiente web ed

anche in crescita nella ricerca scientifica: Python. L’ampia disponibilita di

librerie e framework, oltre all’approccio ad alto livello messo a disposizione

45

dal core del linguaggio - anche grazie all’utilizzo di Python da parte di

aziende come Google, es. YouTube, Google App Engine, ecc - rende Python

un ambiente di sviluppo web stabile e facile da estendere e manutenere.

Il web framework scelto per velocizzare notevolmente la fase di imple-

mentazione e Django [16]. Django e un full-stack framework, open-source

e scritto in Python, che segue il pattern MVC e fornisce utilita fondamen-

tali per implementare velocemente applicazioni web database-driven. Nota:

Django e attualmente utilizzato per progetti della dimensione e rilevanza di

Pinterest, Instagram, Mozilla, Disqus e Bitbucket. Nell’ambito di questa te-

si, Django fornisce una solida base di partenza, sia per la gestione del routing

applicativo, che per la disponibilita di una robusta interfaccia di backend e

di un ORM, entrambi flessibili e configurabili.

6.4.1 Frontend Layer, UI e UX

Considerando l’ampio target applicativo - che si concentra soprattutto su

dispositivi tablet, ma che mira ad una buona compatibilita desktop e mobile

- le tecnologie scelte favoriscono sia la compatibilita cross-browser che la

facilita d’uso nel disegnare interfacce multi-dispositivo.

In particolare, e stato scelto il framework client-side Bootstrap3 [17] (reso

open-source da Twitter e manutenuto da una community di sviluppatori),

come base per lo sviluppo dell’interfaccia e dei comportamenti progetta-

ti. Bootstrap3 abilita anche lo sviluppo di interfacce mobile-first, ovvero

il processo di sviluppo di un’interfaccia web secondo cui si inizia definendo

l’interfaccia per i dispositivi mobile e si procede successivamente a disegnare

le altre versioni in logica scale-up (tablet, desktop, HD, ecc). Questo proces-

so e letteralmente opposto all’approccio precedentemente utilizzato, secondo

cui le web app venivano progettate e disegnate partendo dal focus sui di-

spositivi desktop (e HQ) e definendo successivamente la versione mobile (o

responsive), come un semplice sottoinsieme di elementi grafici e funzionalita.

In quanto requisito per gran parte dei comportamenti offerti da Boo-

tstrap3, anche la libreria JavaScript jQuery e stata scelta come dipendenza

per il progetto. jQuery offre un supporto stabile e cross-browser per l’accesso

e la manipolazione del DOM, utility per la gestione di logiche AJAX ed al-

tre funzionalita non disponibili nativamente in tutte le versioni di JavaScript

(specialmente su vecchi browser e su mobile).

L’interfaccia utente e stata implementata seguendo le specifiche del moc-

kup e le linee guida di E015. Gli elementi grafici sono stati strutturati per

avere dimensioni relative (in percentuale) ed adattarsi quindi a qualsiasi di-

mensione della finestra web. Gli elementi animati ed interattivi sono stati

46

implementati utilizzando le tecnologie piu avanzate ed ormai molto suppor-

tate messe a disposizione dalle specifiche CSS3 (in particolare, transizioni

ed animazioni). Gli altri elementi interattivi, per esempio la finestra modale

a comparsa che contiene la scheda dei singoli POI, sono stati implementati

utilizzando i componenti dinamici di Bootstrap, con qualche ritocco esteti-

co e sempre forzando una visualizzazione adattativa in base alle dimensioni

dello schermo.

Figura 6.6: Interfaccia Utente - Lista uscite autostradali e POI

Per quanto riguarda il rendering dei vari elementi dinamici - in par-

ticolare la lista delle uscite autostradali, la lista dei POI nelle vicinanze

(Figura 6.6) e la scheda di dettaglio (Figura 6.7) - sono state utilizzate tec-

niche AJAX (chiamate HTTP asincrone, scollegate dal flusso della chiamata

principale) unitamente ad uno approccio basato sul rendering client-side.

Questo approccio consente di alleggerire il carico dal server, fruttando

la crescente capacita computazionale dei dispositivi forniti di browser, e

consente di aggiornare gli elementi della pagina senza ricaricare tutta l’in-

terfaccia. In questo caso, la parte piu dinamica dell’applicazione riguarda la

lista dei POI, che deve aggiornarsi periodicamente ogni volta che si supera

la prossima uscita autostradale.

Allo stesso modo, la scheda di dettaglio di ogni singolo POI contiene dati

47

che potrebbero essere ricavati in modo asincrono ma, allo scopo di ridurre la

complessita e la latenza dell’interfaccia, si e preferito evitare chiamate secon-

darie e tutti i dati relativi ad un POI vengono ricevuti attraverso un’unica

chiamata HTTP.

Figura 6.7: Scheda di dettaglio del singolo POI

Figura 6.8: Maschera iniziale di selezione autostrada

48

6.4.2 Backend Layer

Il componente di backend e responsabile dell’interfaccia per modificare i da-

ti memorizzati nel database, disponibile solo ad utenti Amministratori. La

struttura dati modellata (Figura 6.1) e relativamente semplice ed e stata im-

plementata utilizzando il modulo di Django che consente di configurare in

modo molto flessibile sia i modelli che i form di amministrazione per la mo-

difica e l’inserimento dei dati. Nel dettaglio, il modulo di Django chiamato

django.contrib.admin puo essere esteso con la definizione dei propri modelli,

e mette a disposizione tutte le utility e gli hook necessari a personalizzare

l’area amministrativa, la disposizione dei dati, la visibilita degli attributi,

ecc. Questo modulo si integra perfettamente con la gestione degli utenti

e delle autorizzazioni di Django, chiamato django.contrib.auth, e permette

quindi di creare e gestire gli utenti amministratori.

Per configurare l’ORM ed auto-generare il mapping verso il database,

sono stati definiti i seguenti modelli:

from django.db import models

class Highway(models.Model):

name = models.CharField()

class Exit(models.Model):

name = models.CharField()

highway = models.ForeignKey(Highway)

lat = models.FloatField()

long = models.FloatField()

Inoltre, il modulo di amministrazione e stato configurato, a partire dai

modelli, creando le seguenti classi python:

from django.contrib import admin

from .models import Highway, Exit

class ExitInline(admin.TabularInline):

model = Exit

class HighwayAdmin(admin.ModelAdmin):

inlines = [ExitInline]

admin.site.register(Highway, HighwayAdmin)

49

Figura 6.9: Pannello di amministrazione

Come risultato di questa configurazione, il pannello di amministrazione

risultante e visualizzato in Figura 6.9, mentre in Figura 6.10 e visualizzata

la maschera di modifica dei dati.

Figura 6.10: Maschera di modifica (django-admin)

50

6.4.3 Geolocalizzazione e simulazioni

Le operazioni di geolocalizzazione di basano sulla possibilita di avere accesso

alla posizione corrente del dispositivo utilizzato dall’utente.

Dal punto di vista tecnologico, questo requisito non pone troppi osta-

coli ne per applicazion native, ne per applicazioni web. Il valore aggiunto

offerto dall’approccio web e l’uniformita d’accesso, garantita dai browser

piu moderni e dagli standard HTML5. La tecnologia di geolocalizzazione

del browser e disponibile a partire da Chrome 5.0, Firefox 3.5, Safari 5.0,

Internet Explorer 9.0 e Opera 16.0.

Nel dettaglio tecnico, l’accesso alla posizione dell’utente e asincrona e

necessita di un’esplicita conferma da parte dell’utente stesso.

Il seguente codice JavaScript dimostra come sia possibile recuperare

le coordinate GPS del browser con poche linee di codice, assumendo che

l’utente confermera la richiesta d’accesso:

if (window.navigator && navigator.geolocation) {

navigator.geolocation.getCurrentPosition(function(position){

console.log("Lat:", position.coords.latitude);

console.log("Long:", position.coords.longitude);

});

}

L’oggetto position.coords mette a disposizione anche informazioni utili ri-

guardanti velocita, direzione e altitudine del dispositivo, qualora disponibili,

con cui sarebbe possibile un’esperienza utente piu intelligente e consapevole.

In modo analogo, e possibile registrare una callback che esponga la stessa

firma, per ricevere notifiche dell’evento di aggiornamento della posizione,

utilizzando il metodo navigator.geolocation.watchPosition.

Query geolocalizzate

Entrambe le API selezionate offrono query avanzate con cui poter recuperare

i POI nei dintorni di una determinata area geografica.

Ovviamente i meccanismi e le logiche interne utilizzati per effettuare

le query sono mascherati dall’interfaccia delle API, ma e possibile nota-

re come i due meccanismi siano diversi tra loro anche dal punto di vista

dell’utilizzatore.

Infatti, le API di Museimpresa richiedono la specifica di un punto ed un

raggio di ricerca, mentre le API di Regione Lombardia vanno interrogate

51

fornendo quattro valori numerici che identificano un box rettangolare di

ricerca.

Questa differenza, dal punto di vista dell’utilizzatore, potrebbe impattare

negativamente sul meccanismo di aggregazione e va quindi gestita nella ma-

niera piu opportuna. In Figura 6.11 viene mostrato il problema graficamente

e indicando le variabili che lo influenzano.

Figura 6.11: Area di ricerca delle query geolocalizzate

Considerando l’impossibilita pratica di coprire la stessa identica regione

nello spazio, si e deciso di uniformare le query utilizzando perlomeno la

stessa area di ricerca a livello quantitativo. Come e possibile ricavare dalle

semplici forme geometriche in figura (ancora piu semplici considerando un

box di ricerca quadrato) le due aree di ricerca coincidono a livello numerico

solo quando vale l’equazione

L = r · 2√

Π

.

Per esempio, effettuando una ricerca su un raggio r = 10km con le API

di museimpresa, si dovra effettuare una ricerca su box di lato L = 17.72km e

centrato nello stesso punto con le API di SIRBeC. In questo modo, entrambe

le API effettueranno una ricerca geolocalizzata su un area di circa 314km2.

Strategie alternative potrebbero essere prese in considerazione, analiz-

zando la conformazione del territorio o di aree specifiche. La soluzione

preposta e la piu semplice ed intuitiva tra quelle vagliate.

Simulazione della geolocalizzazione

Considerando il contesto dimostrativo dell’applicazione e la necessita tecnico-

pratica di utilizzare la stessa fuori dal contesto reale (es. su dispositivo de-

sktop non in movimento e non lungo un percorso stradale), il componente

di simulazione deve prendersi carico di due aspetti:

52

• Offrire un livello di astrazione durante la fase di accesso ai dati geolo-

calizzati (comunque presenti anche in dispositivi desktop) e restituire

dati fittizi con cui poter visualizzare e testare il sistema.

• Offrire, solo in determinati casi ben definiti, la possibilita di forzare

l’esperienza utente a localizzarsi su determinate posizioni, per esempio

muovendosi da un’uscita autostradale a quella successiva, cosı da poter

a tutti gli effetti simulare cosa succederebbe nella realta durante il

percorso di guida.

Dato lo stretto legame con la componente di geolocalizzazione, gli aspetti

di simulazione fanno parte del codice client-side dell’applicazione. In par-

ticolare - quando il sistema nativo di geolocalizzazione non e disponibile,

o quando il sistema rileva un determinato parametro di configurazione - il

componente di simulazione provvede ad eseguire un override completo del-

la geolocalizzazione nativa e abilita le funzionalita di movimento simulato

(semplicemente facendo click/tap sull’uscita in cui si intende posizionarsi).

Questa soluzione non comporta l’aggiunta o la complicazione di nuovi

elementi nell’interfaccia utente e garantira la fruizione dei contenuti in fase

di presentazione, ma soprattutto ai dispositivi privi dei meccanismi moderni

di geolocalizzazione.

6.4.4 Data, API e Caching Layers

Dal punto di vista tecnico, il livello API ed il livello di caching sono ridu-

cibili ad un unico componente, sfruttando l’espressivita e le utilita messe a

disposizione da Django.

Come esposto in Figura 6.5, l’API layer deve mettere a disposizione del

layer superiore un’interfaccia per recuperare i POI dalle API scelte, rendendo

trasparente ogni problematica relativa a connettivita, HTTP, caching ed

eventuali altri dettagli relativi alle singole API (per esempio la conversione

dei parametri geolocalizzati, come esposto nella sezione precedente).

Una volta implementata l’effettiva chiamata API, assumendo che le pro-

cedure di autenticazione vadano a buon fine e sorvolando sui dettagli tecnici

delle chiamate HTTP specifiche dei vari servizi ed altri dettagli relativi al-

l’integrazione con Django stesso, l’interfaccia di programmazione Python

per accedere al POI di SIRBeC e di Museimpresa e riassunta dalle seguenti

classi Python:

53

from cache_utils.decorators import cached

CACHE_DURATION = 60*60*24 #1 day

class API_SIRBeC(object):

@classmethod

@cached(CACHE_DURATION, ’SIRBeC_all’)

def query_all(cls):

""" Actual API Call: return a raw list """

@classmethod

@cached(CACHE_DURATION, ’SIRBeC_geo’)

def query_by_location(cls, lat, long):

""" Actual API Call: return a raw list """

class API_Museimpresa(object):

@classmethod

@cached(CACHE_DURATION, ’Museimpresa_all’)

def query_all(cls):

""" Actual API Call: return a raw list """

@classmethod

@cached(CACHE_DURATION, ’Museimpresa_geo’)

def query_by_location(cls, lat, long):

""" Actual API Call: return a raw list """

Utilizzando i decoratori Python, e possibile associare a qualsiasi meto-

do o funzione la funzionalita di caching, specificando la durata per singolo

metodo e una cache-key apposita come prefisso. Nota: i parametri dei me-

todi in questione vengono automaticamente utilizzati come chiave di cache,

quindi ogni singola chiamata geolocalizzata verra cachata separatamente.

La scelta del ”backend” di cache piu adatto all’applicazione e comple-

tamente configurabile. In questo caso, per garantire che la cache non vada

persa durante il riavvio dell’applicazione e per evitare l’utilizzo di ulteriori

servizi o software esterni, un semplice meccanismo basato su file system e

piu che appropriato.

54

Per istruire Django su quale cache debba essere utilizzata, e stato ag-

giunto alla configurazione principale il seguente codice:

CACHES = {

’default’: {

’BACKEND’: ’django.core.cache.backends.filebased.FileBasedCache’,

’LOCATION’: ’/var/tmp/E015_cache’,

}

}

Per evitare di fornire questa interfaccia alle API direttamente ai compo-

nenti superiori (in particolare al frontend), un Data layer intermedio offre il

livello di astrazione necessario ad evitare chiamate multiple e rendere il fron-

tend completamente autonomo dall’aggiunta di nuove API o dalla variazione

di dettagli implementativi.

Le seguenti classi Python, semplificate a scopo illustrativo, implementa-

no la logica alla base del Data layer. La logica di cache, come si puo vedere,

non influisce sull’interfaccia delle API ed il Data layer risulta essere semplice

ed intuitivo.

class POI(object):

@classmethod

def all(cls):

return POI_SIRBeC.all() + POI_Museimpresa.all()

@classmethod

def geo(cls, lat, long):

return POI_SIRBeC.geo(lat, long) + POI_Museimpresa.geo(lat, long)

@classmethod

def serialize(cls, poi_raw):

raise NotImplementedError("Abstract method.")

55

class POI_SIRBeC(POI):

@classmethod

def all(cls):

pois = API_SIRBeC.query_all()

return cls.serialize_all(pois)

@classmethod

def geo(cls, lat, long):

pois = API_SIRBeC.query_by_location(lat, long)

return cls.serialize_all(pois)

@classmethod

def serialize_all(cls, pois):

return [cls.serialize(poi) for poi in pois]

@classmethod

def serialize(cls, poi_raw):

""" Actual Implementation: return a POI object """

class POI_Museimpresa(POI):

@classmethod

def all(cls):

pois = API_Museimpresa.query_all()

return cls.serialize_all(pois)

@classmethod

def geo(cls, lat, long):

pois = API_Museimpresa.query_by_location(lat, long)

return cls.serialize_all(pois)

@classmethod

def serialize_all(cls, pois):

return [cls.serialize(poi) for poi in pois]

@classmethod

def serialize(cls, poi_raw):

""" Actual Implementation: return a POI object """

56

Utilizzando l’interfaccia del Data layer, il componente Frontend puo for-

nire all’utente una lista di poi geolocalizzati - per esempio, tramite una

chiamata AJAX invocata al superamento del casello - implementando il

controller seguente:

from django.core import serializers

def pois_list(request):

lat = float(request.GET.get(’lat’))

long = float(request.GET.get(’long’))

POIs = POI.geo(lat, long)

return serializers.serialize("json", POIs)

6.4.5 Funzionalita aggiuntive

Le funzionalita secondarie, considerata la natura ”volatile” dello stato degli

utente non autenticati, non hanno aggiunto complessita al sistema server-

side, dato che si prestavano ad una piu semplice implementazione client-side.

Piu nel dettaglio, le funzionalita aggiuntive e relativa implementazione

sono riportate di seguito:

POI preferiti

La lista di punti di interesse preferiti, o salvati per una consultazione futura,

e stata implementata con un meccanismo di storage locale.

Tecnicamente, l’interfaccia di localStorage e disponibile nella maggioran-

za dei browser moderni e consente di salvare sul browser dell’utente qualsiasi

tipo di informazione, legata all’origine corrente (i.e. la combinazione di pro-

tocollo, dominio e porta) ma svincolata dal concetto di sessione, quindi i

dati continueranno ad essere disponibili sul client anche dopo aver chiu-

so e riaperto il browser, e addirittura dopo aver pulito eventuali cookie di

sessione.

Scendendo piu nel dettaglio, e attualmente possibile salvare nello storage

locale solo variabili di tipo stringa - utilizzando l’interfaccia nativa localSto-

rage.getItem(key) e localStorage.setItem(key, value) - ma questa limitazione

e facilmente risolvibile utilizzando una serializzazione JSON, attraverso l’in-

terfaccia nativa JSON.stringify e JSON.parse disponibili anch’esse su ogni

browser moderno.

57

Filtering categorie

La possibilita di filtrare/selezionare solo alcune categorie di POI non in-

fluenza le interazioni client-server, dato che e possibile memorizzare anche

questa informazione sul client e limitarsi a non visualizzare i POI relativi

alle categorie non selezionate.

Questa soluzione riduce notevolmente la complessita delle interazioni con

il server e massimizza la possibilita di cachare le risorse, e si e rivelata la

soluzione migliore anche per offrire l’esperienza utente migliore possibile nel

momento in cui una categoria precedentemente de-selezionata venga sele-

zionata: in questo scenario, la visualizzazione dei nuovi POI e immediata e

senza alcuna latenza. Considerando la ridotta mole di dati che viene carica-

ta dal client per ogni singola uscita autostradale, l’over-head introdotto dai

POI da nascondere e trascurabile anche nel caso in cui solo una categoria

sia selezionata.

Ricerca POI

La stessa logica vale per la funzionalita di ricerca: una volta caricati dal

server tutti i POI associati ad un’uscita autostradale, la possibilita di tro-

vare uno specifico POI attraverso una ricerca testuale e stata implementata

direttamente sul client.

Ovviamente la ricerca dell’utente potrebbe non limitarsi ai soli POI di-

sponibili sul dispositivo per una data uscita, quindi la funzionalita di ricerca

potrebbe essere generalizzata ed implementata server-side per offrire una

maggiore copertura, includendo nella ricerca sia i POI di tutta la tratta

autostradale in corso, che tutti i POI disponibili dalle API dell’ecosistema.

58

Capitolo 7

Conclusioni

La necessita di valorizzare il territorio locale e le opportunita identificate

nell’infrastruttura di trasporto stradale gia esistente hanno fatto da fonda-

menta per le linee guida di questo progetto. Rilevando il bisogno di un

cambiamento nell’approccio adottato tradizionalmente in ambito di valo-

rizzazione turistica e territoriale, i vantaggi e le possibilita tecniche offerti

dall’API Economy hanno aperto la strada ad un nuovo approccio, focalizza-

to sul ruolo del territorio e degli enti direttamente interessati e responsabili

della valorizzazione del patrimonio culturale. In quest’ottica, la soluzione

proposta dell’ecosistema digitale E015 ha fornito le basi, tecniche e prati-

che, per approfondire il tema della percezione del territorio e progettare

un’applicazione web per dimostrare l’efficacia di questo approccio.

L’applicazione progettata e sviluppata nell’ambito di questa tesi ha su-

perato la validazione del Technical Management Board in merito al rispetto

delle linee guida ed e stata pubblicata [18] sul sito di E015.

La presente applicazione ha voluto rappresentare un primo dimostratore

dell’approccio proposto, ma l’ecosistema abilita e favorisce evoluzioni future

dell’applicazione. Ripercorrendo le necessita di valorizzazione del territorio,

l’estensione del contesto applicativo a beni di diversa natura - per esempio

teatri, centri storici, parchi naturali, ecc. - o l’integrazione di informazioni

complementari all’esperienza del viaggio - per esempio eventi culturali, stato

del traffico, manifestazioni, scioperi, ecc. - potrebbero arricchire l’esperienza

utente ed amplificare ulteriormente la percezione del territorio durante il

viaggio.

Altre funzionalita di aggregazione a piu alto livello potrebbero integrare

i POI provenienti di API multiple e creare veri e propri itinerari, che il

sistema potrebbe suggerire all’utente durante la consultazione delle schede

di dettaglio.

Inoltre, sarebbe possibile aumentare l’engagement dell’interfaccia ed in-

tegrare con il concetto di percezione del territorio anche quello di comunita

locale propensa a valorizzare il territorio attivamente, inserendo elementi di

interattivita, quali la possibilita di aggiungere commenti o revisioni ai POI,

oppure monitorando automaticamente la navigazione dei singoli dispositivi

allo scopo di tracciare i POI piu visitati grazie all’applicazione. Queste so-

luzioni introducono nel sistema grandi moli di user-generated content, il cui

trattamento digitale ed integrazione con i dati provenienti da E015 andreb-

bero in parte normati, includendo meccanismi di autenticazione e privacy

policy, e rendendo esplicita l’attribuzione di provenienza dei contenuti.

Dal punto di vista dell’End User Application Provider, questa tesi vuole

anche cogliere l’occasione per offrire spunti di miglioramento all’ecosistema

nel suo complesso, con particolare riferimento all’utilizzo da parte di svilup-

patori esterni, vissuto in prima persona. A titolo di esempio, l’aggiunta di

indicazioni ad alto livello nel descrittore delle API riguardanti la presenza o

meno di informazioni geolocalizzate, immagini (e relativa quantita), descri-

zioni testuali ed altri attributi utili, potrebbe velocizzare e migliorare la fase

di selezione delle API da utilizzare, specialmente considerando il crescente

numero di API a disposizione.

Un secondo potenziale miglioramento, sempre dal punto di vista degli

sviluppatori di applicazioni, potrebbe riguardare la disponibilita di uno o piu

wrapper per le principali API dell’ecosistema e per i linguaggi di program-

mazione web piu utilizzati. Per esempio, l’ecosistema potrebbe richiedere

agli API Provider stessi di mettere a disposizione il proprio API wrapper

e/o richiedere ad ogni End User Application Provider di rendere open-source

i wrapper sviluppati per la propria applicazione, cosı da garantire un set di

librerie software pronte all’uso - eventualmente approvate o manutenute dai

Provider stessi - e facilitare notevolmente lo sviluppo di nuove applicazioni.

In questo modo, sarebbe possibile mantenere un ulteriore livello di astrazio-

ne rispetto all’interfaccia (RESTful o SOAP) e garantire, almeno in parte, la

continuita dei servizi offerti dalle applicazioni sviluppate a fronte di modifi-

che alle logiche delle API, assumendo che i wrapper e le dipendenze vengano

aggiornati di conseguenza.

60

Bibliografia

[1] ”The Power of the API Economy” - Kerrie Holley (BM Redbooks)

http://www.redbooks.ibm.com/redpapers/pdfs/redp5096.pdf

[2] Amazon API Gateway

https://aws.amazon.com/api-gateway/

[3] Mashape

https://mashape.com

[4] ”API economy, from systems to business services” - George Collins and

David Sisk (Deloitte)

http://dupress.com/articles/tech-trends-2015-what-is-api-economy/

[5] E015 Digital Ecosystem

http://www.e015.expo2015.org

[6] CEFRIEL

http://www.cefriel.com

[7] ”Sei in un Paese meraviglioso” - Autostrade per l’Italia

https://www.autostrade.it/sei-in-un-paese-meraviglioso/

[8] SIRBeC

http://www.lombardiabeniculturali.it/sirbec/

[9] Museimpresa

http://www.museimpresa.com/museimpresa/

[10] Regione Lombardia

http://www.regione.lombardia.it

[11] MaMi (Linate)

http://www.milanolinate-airport.com

[12] MaMi (Malpensa)

http://www.milanomalpensa-airport.com

61

[13] L15 (web application)

http://l15.regione.lombardia.it

[14] 3cixty (web application)

https://www.3cixty.com

[15] Punti di interesse del territorio - Glossario E015

http://www.e015.expo2015.org/esplora-i-contenuti/

i-glossari/punti-di-interesse-del-territorio

[16] Django Web Framework

https://www.djangoproject.com

[17] Bootstrap Framework

http://getbootstrap.com

[18] ”Le bellezze del territorio alla prossima uscita”

http://www.e015.expo2015.org/esplora-i-contenuti/

le-applicazioni/le-bellezze-del-territorio-alla-prossima-uscita/

62