**1. Introduction**

The rapid and pervasive evolution of digitalization covering all aspects of life has drastically changed the field of tourism [1] so as to propose a new pervasive experience, more and more based on online services and information; moreover, that trend is expected to further grow in acceptance and offerings. In fact, we already see a wide variety of services, datasets, and platforms concerning and supporting tourism in many of these new different forms. In the past decades, tourism acquired a key role in the development and economic growth of many countries, and so it is in Italy. As stated by Eurostat [2], in the EU (European Union) area tourism is EU's third largest socio-economic activity, representing around 10% of the EU's GDP (gross domestic product). Moreover, five EU Member States are among the world's top ten tourist destinations worldwide.

In Italy, more significantly than in other countries, tourism is in continuous growth and represents a vital contribution to the wealth of the nation. In fact, the total contribution of tourism to the Italian economy in 2017 was 223.2 billion euros, equal to 13% of Italian GDP and Italy was ranked the second destination for outbound trips made by EU residents within the EU, in terms of nights spent [2].

The fast increase of the tourism market is raising the need for a "Smarter" Tourism (Smart Tourism, or ST for short) more able to personalize and adapt customer experiences while creating a more culturally rich and even more sustainable offer.

**Citation:** Sabbioni, A.; Villano, T.; Corradi, A. An Architecture for Service Integration to Fully Support Novel Personalized Smart Tourism Offerings. *Sensors* **2022**, *22*, 1619. https://doi.org/10.3390/s22041619

Academic Editors: Suparna De and Klaus Moessner

Received: 24 December 2021 Accepted: 15 February 2022 Published: 18 February 2022

**Publisher's Note:** MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

**Copyright:** © 2022 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https:// creativecommons.org/licenses/by/ 4.0/).

To highlight the importance of ST in the sustainable development of a country, the European Commission launched the European Capital of Smart Tourism to stimulate the development and sharing of ST good practices. The European Capital of ST is an initiative to promote the integrated offers of innovative, inclusive, culturally diverse, and sustainable practices to tourism development by European cities [3]. Within that project, the European Commission has defined the concept of Smart Tourism as the combination of properties:


The always-enlarging availability of information accessible through the network has modified the approach of visitors to the experience from an even structured and wellplanned tourism offering to more dynamic and by-need ones. The development of ST will require not only a more *personalized experience* for tourists but also a more *dynamic service* proposal as key factors of the whole experience. Examples of dynamicity are modern apps that exploit geo-localization to retrieve more suitable local services in the locality of tourists and in a by need fashion [5]. That dynamicity further promotes a more personalized experience by using intelligent system recommenders: today the whole information about previous historical data and profiling plays a key role in ST decision-making processes [6]. Moreover, in the last years, the recent global pandemic has stressed further the importance of smart and dynamic tourism services based on geographic positions [7].

The pervasive diffusion of IoT and smart devices, connected with social sensing, represents an important accelerator to drive information retrieval toward service quality. In Social Sensing, the final customer can be actively and deeply involved in many ways, from contributing with her knowledge and sharing data gathered with smartphone and personal wearables, up to asking him to complete simple tasks while moving with her phones. Social sensing extends an already widespread and well-established series of techniques called crowdsensing [8] and has already been proposed to involve users in the process of data gathering [9]. Since initiatives of social sensing, crowdsensing, and crowdsourcing can play an essential role in the development of smarter tourism services, those initiatives are also coupled with incentivizing user participation via some forms of competition among users and via strategies of gamification. Tourism gamification extends strategies from game design and involvement strategies in non-game contexts [10], so to influence consumer engagement, customer loyalty, brand awareness, and user experience in tourism areas [11]. Examples of these initiatives include the usage of a scoring system related to customer action undertaken also rewarded with forms digital or material incentives and rewards.

As an example, in recent years many studies have proposed the use of social sensing to collect geo-tagged information and exploit them to identify tourism areas of interest [12], map tourist behaviors [13,14], compare and differentiate clusters of tourists [15], and discover and propose again noteworthy new places [16].

From the user perspective, the employment of ST combined with social sensing can provide better tailored information to tourists, about the quality and accessibility of a place, suited to their peculiar interests, either long-term or defined on the spot [17]. Examples are many, from the presence of barriers to the support of different languages in the service, from the current weather situation to the current mood of the entire group. In the city of Bologna, for example, there is an application to cancel barriers both in access to services and in mobility as demonstrated by projects like mPASS [18] or Kimap [19].

Additionally, we add that the tourism area itself asks for deep integration with many other fields, such as smart cities [20], smart transport, smart wealth, and relative services and data sources [21] as a few examples of connected areas.

To summarize, the integration and combination of ST information and services are expected to create grea<sup>t</sup> business value [22] and to enable the development of smarter tourism services and experiences, but the heterogeneity of formats and interactions protocols slows down the integration of multiple platforms, making impossible the acceptance of a unique and comprehensive standard, because of the different stakeholders and organizations proposing ST services and the lack of cogen<sup>t</sup> regulation [23].

To solve these problems, the authors propose APERTO5.0, a reference Architecture for Personalization and Elaboration of services and data to Reshape Tourism Offerings 5.0, based on human-centric interactions and data gathering favoring a strong personalization with interested tourists (either single, in groups of interests, or in other aggregation forms). The aim of APERTO5.0 is not only to exploit better existing resources for a greater business value but also to stimulate the creation of novel tourist services toward the whole potential of aggregation and augmentation of the platform. APERTO5.0 can present local services per se, but also present new offerings, composing together local services chosen depending on specific tourist profiles and current needs. In fact, the APERTO5.0 aims both to enable the creation of a platform that can present a unified view of services and information to tourists and to offer a single access point for advanced and augmented information and facilities composition to third parties private and public organizations, so to encourage and enhance the development of positive and sustainable tourism offerings.

In collaboration with some local companies, the authors have implemented the first prototype of APERTO5.0 to handle a specific scenario of tourism paths ("cammini" in Italian or ways in English). "Tourism paths", also called pilgrim ways, are recognized routes connecting some historically relevant sites, and traditionally followed by pilgrims in the past: examples can be the "way of Saint James" to reach Santiago de Compostela, or the "Francigena way", an itinerary going to Rome by foot, both started since the Middle Age. Those tourism experiences are gaining more and more attraction as able to offer a healthy traditional and sustainable experience, in line with tradition and connected with the territories traversed by the path.

To validate the capabilities of APERTO5.0 architecture, the authors have extensively tested the proposed solution under different loading conditions, simulating the "Francigena way" behavior in the Italian final part, by testing the possible occurrences in the different conditions of service request typically experienced in tourism real scenarios. The paper compares the results for the presented solution in gathering and requesting information with the solutions that represent the de facto standard of the market. APERTO5.0 showed a very good capacity of distributing and requesting information under different loading conditions and diverse network and infrastructural topologies complexity.

In summary, this paper significantly advances the state-of-the-art literature in the field with the original contributions listed below:


### **2. The Proposal**

APERTO5.0 is based on an organization that put together on the one hand all possible information sources, and services toward a better integration, on the other hand, the best proposition possible for the differentiated needs of all tourists, either single or in different

composition groups in number and interests. The proposed architecture has been designed driven in the middle of existing tourism services and information providers and the possible requests and needs of customers (Figure 1). APERTO5.0 aims at becoming the reference for the development of new smarter tourism services and platforms while adding value for both producers and consumers based on its integration and augmentation capacity.

**Figure 1.** High-level vision of the APERTO5.0 architecture in terms of the layers connecting providers to customers.

The architecture considers a producer every entity that provides information or services potentially appealing for the tourism field and its development, by including partners belonging to the public and private sector, open data, and any connected things spread in the interested region, like connected transports, sensors, and user wearable devices. The absence of a common agreemen<sup>t</sup> and regulatory organs leads to a wide specter of interaction modes and formats, as well to many heterogeneous types of agreemen<sup>t</sup> and relationships proposed by different producers. On the other side, customers are users of the platform that can consume services and data resulting from the processes of augmentation, elaboration, and orchestration of information and services coming from Providers. The authors target does not consider only tourists as customers of the platform, but also municipalities, destination managers, third parties tourism services, and all the other actors possibly present in the territory and interested in participating in the formation of a smart tourism offer. Such heterogeneity in customers leads to the requirement of a high level of modularity and adaptability to suit the different needs of customers.

We must stress that a provider can also play the role of customer and vice-versa, by creating a circular Prod-Cons pattern, where providers can interact with the proposed platform as customers to grow their services, and customers can improve their experience through personal contributions to APERTO5.0. This positive evolution can be opportunistically encouraged through initiatives, such as crowdsourcing campaigns and the creation of local relationship networks. Authors claim that the introduction of the proposed digital platform can encourage the creation of a network of partners that can also increase, monitor, and guarantee the value of data and services. These types of relationships can also enable the development of opportunities by creating a mutual value, in the sense of social results in the tourism field, such as the creation of an agreemen<sup>t</sup> of multiple municipalities crossed by a path of cycle tourism. The network constituted with the different partners in the territory supported by the proposed digital platform constitutes the target supply chain for customers.

The architecture of APERTO5.0 is based on three well-defined layers called planes: the higher-layer business plane is responsible for the interaction with customers; the other two lower-layer planes are responsible for all possible services (service plane) and information (data plane) arriving from interested providers. It is important to stress that APERTO5.0 can expose new services based on the available existing ones; another lower layer component is the crosscutting one, in charge of all managing and monitoring functions of the entire architecture.

We are now expanding the details for the above planes. The business plane is the functional plane that addresses the complexity derived from interactions with customers with the main goal of providing a unique point of interaction, and, at the same time, of hiding from the customers the complexity of distributed datasets and services. The business plane has the main goal of uniform access to the heterogeneity of services, protocols, and interactions arriving from the underline planes to compose a solution offer. This plane drives the composition, coordination, orchestration, and exposition of services and information coming from the data plane and the service plane. This plane is capable of creating new synthetic tourism proposals, starting from existing services and information, such as in the creation of new packet experience, by booking public transportation, and by creating a path across most visited places. These features demand a high level of modularity and composability to adapt to the continuously evolving needs and interaction methods of customers, via tools like Dashboards, Apps, and APIs.

The data plane is the component of APERTO5.0 responsible for collecting, managing, and analyzing all the datasets and information collected from third parties providers, realizing the augmentation and conformation of data. This process is an essential step in the creation of new services and platforms, so that uniformity and standardization can reduce considerably the effort related to the managemen<sup>t</sup> of different formats. The data plan can handle and process both data in motion and at rest (very static and very dynamic data, as extremes), enabling the exploitation of both historical data and fresh real-time information. To achieve a good value from data both stored and processed, it is necessary both the use blending techniques, over the data coming from multiple and diverse sources to merge them and the consolidation of a network of partnerships in the territory that can provide feedback and support, so as to specifically verify the information. The data plane supports multiple types of representation and analytics, in order to handle the different needs of customers, including geographical and time-based queries, up to computationally intensive processing like graph algorithms and machine learning techniques.

These planes, part of the proposed architecture, enable the representation, integration, and orchestration of provider services. Since the proposed solution does not replace or force migration of existing services but, on the contrary, focuses on empowering existing ones, the service plane has the goal of matching to each existing service one or more *synthetic* services representing it internally to the platform. Each *synthetic service* handles all the specificity of the target producer service like protocol, billings, and authentications taking charge of all the necessary coordination with other planes present in the proposed solution, specifically the *cross cutting concern plane*. Moreover, the services can be further composed or decomposed to create new *synthesis* services, so to create offerings at different granularities, e.g., a transportation service can be composed starting from a sharing mobility service and a public transport one. To enable these advanced techniques, the service plane also introduces a series of composing categories applicable to services that can not only enable a simpler composition of services but also simplify the suggestion of alternatives to the final customer, e.g., to sugges<sup>t</sup> alternative places to visit, transportation to reach a point, or nearby hosting structures. Furthermore, these types of abstractions can enable smarter behaviors exploited by customers, leading them to a better tourism experience capable of reacting dynamically to events and information received, e.g., a signal of breakdown of a bus can trigger the automatic call of an alternative transportation partner or the proposal of remediation proposing like free hosting structures.

Finally, APERTO5.0 defines a *cross cutting concern plane* (CCCP) consisting of a series of components to implement all cross-cutting concerns and support other planes, in the whole managemen<sup>t</sup> and interaction with internal and external services. Authors expect a continuous evolution of the CCCP while dealing with new challenges and new scenarios, especially distributed across a heterogeneous territory like the one covered by a pervasive platform of tourism. The CCCP supports the resolution of problems not only addressed internally to proposed infrastructure but also directly in relation with customers or providers, e.g., health checks of provider services and endpoints. Some services belongings to the CCCP can not only support other services but can become themselves part of the offer of other planes, e.g., the authentication services that can be provided as a service directly to customers behaving as part of the business plane. The components realized in the CCCP layer aim at operating transparently to the other component of the infrastructure. In this way, the evolution and introduction of new features in the CCCP plane can benefit, with little effort, multiple components belonging to other planes of the proposed solution.

### **3. APERTO5.0 Architecture Full Component Description**

Going deeper into a more detailed description of APERTO5.0, we magnify the presented solution that is fully partitioned into detailed layers, each one corresponding to a single business process (Figure 2). We describe here: the presentation layer that implements and proposes a unique view of all services within the business plane; the blending and the data layers inside the data plane that allow the input of all information needed by ST by polishing and presenting, and also storing within the second component; the analytic and processing layer together with the *integration* layer constitute the service plane, where the former is capable of extracting any possible interesting service from the proposed available ones, while the latter is capable of getting to all available services available for ST. In addition, the *auditing, authentication, and authorization* (AAA) and the *monitoring* layers constitute the first two proposed modules that realize the cross cutting concerns plane.

**Figure 2.** APERTO5.0 layers more detailed view. All components are put together for a more comprehensive effort of integration and synergic coordination.

The presentation layer constitutes the main component of the business plane to create and provide a unified view for tourism and third actors, by combining information and services coming from data plane and service plane to provide new smarter tourism services, typically the creation of a travel experience blending information on events and places in the destination with services of ticket purchase for transport. Supported customer

interaction can employ heterogeneous technical protocols, e.g., pub-sub, client/server, fire and forget, and advanced query languages.

The data plane is subdivided into two horizontal layers: the blending layer and the analytics and processing layer (AP Layer) and one vertical layer: the data one.

The *blending layer* is responsible for gathering, cleaning, and adapting to a convenient format the information coming from third-party services, open data, and custom ad-hoc services. These data sets are then stored, according to predefined or dynamic policies on the different storage services composing the data layer. This lower layer implements the integration logic with the different forms of interactions and queries exposed by external data sources. The interaction methods are managed and adapted to require no changes on the provider side and can support reactive interaction, such as event-based traffic information systems and scheduled/polling-based ones like information about shows, fairs, and festivals periodically published on a site. The blending layer widely exploits principles of modularity and composability, and any introduction of new data sources or data manipulations follows the plug-in logic with a minimum effort of development and instantiation, enabling in such a way a sustainable growth of handled producers. This component implements a gathering approach direct from producer sources, in this way enhancing diversity and customized experience. This approach differs significantly from more traditional ones such as in booking.com [24], where the hosting infrastructure must register and constantly update its own data in a third-party portal, so requiring a standard format a-priori.

As part of the data plane, the *analytics and processing layer* aggregates and analyzes the different data sources stored in the data layer and exposed by the integration layer. This layer realizes the process of adding value to the information coming from local tourism offerings, via an internal creation of new aggregate datasets and the discovery of new insights through advanced elaboration techniques, such as big data processing, data mining, and AI (artificial intelligence) algorithms. This layer can also support real-time event-based and continuous-stream processing to enable advanced real-time queries and subscription mechanisms, as well batch operations for heavier time-consuming analytics.

The *data layer* is a vertical layer inside its plane, since it cooperates with all other layers, by storing elaborated data, schemes, and metadata and by exposing them through advanced indexing and query languages. The data layer handles the storing of fresh and past collected datasets and metadata, by enabling fast and advanced analytics and interactions through the exploitation of the data locality principle and advanced indexing, and by proposing customer-adapted viewing techniques. To support an effective memorization and query system the data layer exploits the most convenient storage strategy, so supporting any different data format and memorization technology.

The *integration layer* cooperates with the *analytics and processing layer* inside the service plane. The integration layer, in particular, is responsible for re-exposing in a convenient and optimized way the external services provided by third parties. The exploitation of many different categories enables the possibility to combine properly and substitute service calls to create smarter and reactive services, e.g., buy theater, cinemas, or public transportation tickets. This wrapping mechanism enables to hide and abstract from the peculiarities of each service, such as internal protocol, service call sequence, or rate-limiting, and facilitates the coordination and combination realized in a analytics and processing layer. Moreover, this layer interacts with all external services and datasets to obtain data not directly available, since they are filtered away, such as real-time number of available tickets or current position and updated time of arrival of a transport. The integration layer to support integration with different heterogeneous providers implements many types of interaction including periodically and reactively.

The *auditing, authentication, and authorization* (AAA) and the *monitoring* layers constitute the core of the cross cutting concerns plane, available to all other components, to operate in conjunction with all layers in the proposed architecture. These two layers also form an important part of the business plane as they provide important services to the final customer e.g., authentication service or metric.

In fact, the AAA layer is not only responsible for guaranteeing a proficient level of security to the infrastructure layer but also to provide a unique point of access, for final users, to the services covered and integrated into the platform. This allows to preventing registration and policy adaptation to any tourism service provider and enables a unique view for tourists and third-party organizations.

The *monitoring layer* provides useful insights on the service usage and the overall state of the platform to enable both elastic managemen<sup>t</sup> of the infrastructure and significant added business value. In fact, from the monitoring layer it is possible to extract and underline trends in services usage with a geographical and temporal connotation and exploit them internally at the platform or supply "as they are" to external organizations, think to the trends in ticket buyout of a public transport localized in a determined time or region. Moreover, this layer can control malfunctions and unavailability of services and information provided by producers, by generating alerts by need to request automatic execution of recovery action.

The complexity and stratification of the proposed architecture derives from the exigence of addressing heterogeneity in tourism information and services as well as in customer needs. Moreover, this complexity is expected to further increase with many additional layers and components while increasingly addressing more and more ST use cases with their intrinsic exigences. Authors claim, however, the validity of the proposed architecture as a base for the structuration of a solution able to satisfy and integrate many ST vertical scenarios.

### **4. The Case Study of Tourism Paths**

One of the most challenging scenarios in the context of smart tourism is the business of tourism paths (or ways or itineraries, sometimes pilgrim's ways), typically established very long ago to sugges<sup>t</sup> routes to religious pilgrims in the middle age and to give advice in their ways toward their final destination. This paper takes the "Francigena way" as a use case, in particular, the Italian part passing through territory. This novel and more requested type of tourism offers are characterized by the requirement of extreme personalization and dynamicity of target user experience; tourists can choose via the information given by their smart devices how to continue the experience, which is always driven by current information derived from their connection on demand. Of course, the same alwaysconnected feature can apply to many other areas apart from ST, so presented architecture can be crucial in those too.

In tourism paths, users intend to use ICT as an essential part of the experience and tend both to be driven by information they need to ge<sup>t</sup> either personally or as part of a group, and to feed information over the community depending on their current experience. We consider that tourists can become prosumers (consumers and producers at the same time) of the experience of tourism paths. As an example, via ICT tools, the user can interact more dynamically and satisfactorily, by choosing to read personalized paths and calibrating languages and contents based on specific levels of learning [25]. It becomes essential to gather as much information as possible, so as to provide customers with the necessary details and to provide the customers with the best experience possible. That high dynamicity constitutes a challenge for providers of smart tourism services characterized by huge distances covered, with a multitude of information gathered, with a high fluctuation in number of users requesting those services, and with an important level of heterogeneity in partners to be involved.

In collaboration with Imola Informatica, authors then decided to create a first prototype of APERTO 5.0 to support the creation of a platform of smart tourism for tourism paths. This platform aims to support customers in all the phases of the experience: from the *planning of the trip*, also *during the experience*, and finally in the *post-experience phase*.

From the user point of view, a basic service example should make it possible to (1) plan the trip in any plan details, such as choosing also where to sleep and eat; (2) contacting local shops and realities for the discovery and purchase of typical products; (3) explore the path you want to take, discovering what to visit. That is normal in the planning phase, but those services should be available also during the experience itself, and at the same time, must occur in the post experience, both to document the events and compare with possible different expectations for future planning.

Particular attention is devoted to the process of information gathering from partners, sensors, and user contributions. Users are continually encouraged to contribute during the whole experience with images, gathering data from sensors, expressing opinions, and sharing their GPS tracks.

This process of social sensing opens the APERTO5.0 platform to a continuous enrichment of the experience introducing in the ST offerings new variations to the route, points of interest, and information about places acquired by other users during similar experiences. Moreover, the entire information allows the platform to dynamically adapt customer experiences, to make the offer more accessible and enjoyable. In the scenario of tourism path, a parameter to be continuously monitored is the *difficulty* associated with a stretch of the route that depends on many environmental current factors, such as humidity in the air and the soil, condition of the track, and wind force.

To stimulate user contribution, the platform exploits a gamification approach, where each user contribution assigns some score points according to the relevance of the intervention. As an example, the signaling of a critical problem during the tourist path (particularly important for other users) can be estimated as a relevant contribution, while the review of a restaurant can be associated with fewer points. At the overpassing of some predefined thresholds, the user is rewarded with some prizes of many diverse types and values, such as showing the user status and coupons offering discounts on partners related to the experience.

### **5. Materials and Methods**

To evaluate the potentiality of the presented architecture proposal the authors have developed a first implementation prototype based on some widely open source affirmed platforms, with the goal of not only helping us to evaluate the effectiveness of the proposal in some real use case scenarios but also discovering whether current technological solutions can fulfill the use case needs. As shown in Figure 3 we base the first prototype on 5 main technologies: (1) Eclipse Zenoh [26], (2) OpenFaaS [27], (3) Apache Kafka [28], (4) Apache Spark [29], (5) Elastic Stack (Elasticsearch and Kibana) [30], necessary to satisfy the needs of the "Francigena way" use case and presented from a bottom-up perspective from the data gathering to the final service and data representation to customers.

Potential technological gaps discovered during the execution of the testbed will constitute further directions of research to address and solve the problems of a general architecture and infrastructure to support the development of smart tourism.

One of the most challenging tasks demanded of the proposed infrastructure and demanded to the blending layer is the gathering and dynamic querying of information from different sensors, customers, and providers present in the territory. The difficulty of this task is further exacerbated by the use case scenarios that must cover a large territory with very heterogeneous characteristics, like connection quality, coverage, and density of devices. To overcome these challenges, we have introduced Eclipse Zenoh as the preferred interaction medium between the infrastructure and data sources present along pilgrim's paths. Zenoh is an open project developed by Eclipse Foundation born to fulfill the need for an efficient adaptation of fog-centric business. In the past decades, the cloud-centric model has taken hold in several fields and has been applied pervasively to countless business cases. Nevertheless, the cloud-centric model has shown some limitations under some application conditions and fields (e.g., limited connection bandwidth, low latency, negligible connection cost, etc.). Zenoh tries to fulfill those needs, by implementing a distributed pub/sub model

with a limited footprint and overhead to reduce to the minimum the impact over the business resources. At the same time, Zenoh aims to keep as low as possible the latency and to increase to the maximum throughput.

**Figure 3.** First prototype of APERTO 5.0 realized to satisfy pilgrims path needs.

Each node that uses the Zenoh APIs is declared to belong to one unit type: peer, client, and router, since these three units are the building blocks for any application. In fact, the application unit declared as *peer node* could connect to another node in the network allowing a complete graph topology or could select the nodes to connect to, to form a connected graph topology. The role of the *client node* is to connect to a single router or peer to communicate to the rest of the system. The *router node* is a software process able to perform level 7 routing (OSI model) and connect to different nodes to connect different topologies to each other to form any kind of topology.

Zenoh also provides and implements a configurable discovery mechanism that employs a gossip protocol over multicast, to auto-connect to the other nodes with the aim of using a so-called "path" to perform a request. The "path" is a string that works as a key thus acting as a symbolic location that expresses the logical function rather than IP addresses so that this organization allows the application to hide the exact position of the data enabling a geo-distributed storage implementation. To enable the gathering and dynamic querying of data across the distributed infrastructure, Zenoh provides a set of high-level APIs that hides the underline infrastructure complexity, while enabling advanced and well-established communication patterns, like publish/subscribe or request/reply. Those APIs together with the advanced infrastructure of Zenoh make possible for APERTO 5.0 the collecting of information from the action of user sensing and the contributions of partners, as well as the dynamic querying of data at rest present in the wide territory covered.

To address the grea<sup>t</sup> variability of sources in a Prosumer context, the authors introduced a layer of adaptation and abstraction at the forefront of the proposed architecture

and realized by OpenFaaS an Open-Source Function as a Service (FaaS) platform. FaaS computing is a novel model of cloud computing that promotes the absence of customer control over the infrastructure by specifying only the creation and upload of the desired business logic. This model can enable an unprecedented speedup in the development of new components, such as the creation of ad-hoc components to manage and adapt data coming from various sources.

Moreover, the FaaS model is characterized by a fine-grained scaling of resources associated with each service. In fact, in FaaS platforms, the code representing the business logic is not always active and in execution but is dynamically executed by the platform only at the arrival of the user-associated events. That enables a good consolidation of different services deployed on the same hardware, potentially achieving an important cost-saving.

Finally, recent developments in FaaS, such as function chaining or map reduction, aim to introduce even more capabilities and paradigms support that can promise the standing of FaaS platforms as a crucial component to forefront complexity of tourism cases. The FaaS model paves its interaction model and scalability on asynchronous communication and stateless computation, while modern FaaS platforms, such as OpenFaaS, still lack mechanisms of synchronization and aggregation. Therefore, we had to recur to one well-spread message-oriented middleware, Apache Kafka, as a layer of interaction between functions and other functions or integrated platforms. Apache Kafka is a highly scalable, open-source streaming platform that provides the *Pub/Sub protocols*. We opted for Apache Kafka, among many open-source MoM present on the market, for its capacity of excellent scaling in handling a massive number of concurrent messages with multiple configurable qualities.

In fact, the FaaS layer can potentially create a large amount of information and as the importance of information can significantly vary, so a differentiation of QoS support in the service is essential. Data coming from the integration and blending layers are then convoyed as a stream in specific Kafka topics each one characterized not only by a business means but also by a specific QoS. The continuous stream of differentiated information can be either kept in persistent storage or streamed to the analytics and processing layer for further processing. Kafka enables not only to handle a huge amount of concurrent information coming from different providers but also to handle diverse sources with diverse levels of QoS, spanning all common policies, from best effort to atomic delivery [31].

To address the continuously evolving needs of customers we introduce in the processing layer Apache Spark, an open-source distributed analytics engine memory computation large-scale data processing that provides multiple modules like MLlib, GraphX, Structured Streaming to enable the parallel and in-memory computation of data at rest and streamed from Kafka with advanced techniques, including graph processing, machine learning, incremental computation, and stream processing [32]. Inside the proposed solutions, Spark is the essential component in charge of processing and interpolating data coming from sensors, social networks, and social sensing. For specific partner requirements, we can opportunistically open the possibility to directly exploit the advanced processing capabilities of Spark. The process of submitting a task to Spark, however, is not trivial and highly depends on the characteristics of the deployed environment. For this reason, we decided to provide a layer of abstraction through Apache Livy [33] to enable the direct submission of Spark Jobs via REST API. Furthermore, Livy also takes care of implementing politics and mechanisms to guarantee fault-tolerant submissions and concurrent request support in a multi-tenant environment.

All the information elaborated by Spark and the FaaS platform are eventually stored in Elasticsearch, a persistent, distributed, and fault-tolerant NoSQL database. Elasticsearch is a distributed and scalable open-source project part of the ELK Stack. Through its REST APIs Elasticsearch enables the store and advanced analytics and query of big volume of data in near-real time fashion.

In the data layer, in fact, two main needs to handle are the managemen<sup>t</sup> of a huge amount of data and the creation of a query engine service with advanced capabilities to support visualizations and customer queries.

The introduction of Elasticsearch in proposed technological stack enables us to maintain relevant historical information while creating efficient and practical indexes and views to facilitate the retrieval of data. Data so memorized can be queried by customer through API or presented as advanced graphs, dashboards, dynamic maps in Kibana an open frontend service part of the elastic stack providing search and data visualization capabilities for data indexed in Elasticsearch.

The proposed architecture paves its strength on the modularity of the solutions composing the different layers. The different components proposed, in fact, while suiting the needs of the "Francigena way" cannot match the requirements of other ST use cases or result in overkilling and can be replaced accordingly. We expect, indeed, a grea<sup>t</sup> and continuous evolution in components of the single layers of the architecture presented, according to the increasing number of addressed use cases.
