Ambient intelligence governance review: from service-oriented to self-service

The current generation of connected devices and the Internet of Things augment people’s capabilities through ambient intelligence. Ambient Intelligence (AmI) support systems contain applications consuming available services in the environment to serve users. A well-known design of these applications follows a service architecture style and implement artificial intelligence mechanisms to maintain an awareness of the context: The service architecture style enables the distribution of capabilities and facilitates interoperability. Intelligence and context-awareness provide an adaptation of the environment to improve the interaction. Smart objects in distributed deployments and the increasing machine awareness of devices and people context also lead us to architectures, including self-governed policies providing self-service. We have systematically reviewed and analyzed ambient system governance considering service-oriented architecture (SOA) as a reference model. We applied a systematic mapping process obtaining 198 papers for screening (out of 712 obtained after conducting searches in research databases). We then reviewed and categorized 68 papers related to 48 research projects selected by fulfilling ambient intelligence and SOA principles and concepts. This paper presents the result of our analysis, including the existing governance designs, the distribution of adopted characteristics, and the trend to incorporate service in the context-aware process. We also discuss the identified challenges and analyze research directions.


INTRODUCTION
Ambient intelligence (AmI) support systems are a suitable element in the augmentation of people's capabilities (Sadri, 2011;Acampora et al., 2013). These systems perform a smart use of the context in our environment by taking advantage of the technology-enriched surroundings to support users (Augusto & Mccullagh, 2007) in a context-aware manner. When systems require the interaction and integration of internal and external entities, ambient systems tightly adopt Service-Oriented Computing (SOC) (Stavropoulos, Vrakas & Vlahavas, 2011). SOC is a computing paradigm that considers services the principal concern when modeling and implementing applications (Papazoglou, 2003;Papazoglou et al., 2008). SOC includes a Service-Oriented Architecture (SOA) style, which defines a set of principles and design patterns. SOA is the reference model in SOC, introducing an abstraction of the solution logic: services invoked by consumers in a platform. SOC and

Intended audience and organization
This review focuses on the services dimension with a global overview of architectures to orchestrate ambient intelligent services, including cloud and intelligent agents providing ubiquitous services. We target this review for researchers and developers who require a conceptualization for new IoT application modeling and implementation. This review also explores the distributed service architectures evolving with 5G and new distributed computation models.
The following Section "AmI and SOA: Definitions and Related Technologies," introduces the conceptual schema to analyze with characteristics of AmI and SOA styles. This schema considers existing implementations, discarding futuristic aspects. Based on our conceptual schema, Section "Review Methodology," defines the review structure and details the method adopted for the study, including criteria for inclusion/exclusion. Section "Data Analysis: Systematic Map," presents our analysis per se with the classification and mapping. Section "Results and Discussion," presents the overall results and introduces the identified challenges. Finally, Section "Conclusions," finishes the review with conclusions.

AMI AND SOA: DEFINITIONS AND RELATED TECHNOLOGIES
Ambient Intelligence (AmI) systems integrate everyday objects and automate tasks in a transparent and pervasive multi-environment service provider. Nowadays, AmI systems adopt SOA to integrate/distribute computational services for a diversity of applications. AmI applications cover the intelligent management of context in houses and buildings, public and private places and businesses, leisure and tourism, digital spaces and assistants, and the Internet and Web of Things (Sadri, 2011). Also, AmI systems target e-health and personal health applications. Health systems include smart bio-signals sensing that feeds monitoring applications and affective and responsive systems aware of the body and environment, triggering actions to improve health conditions (Acampora et al., 2013;Sadek et al., 2018). This section describes AmI and SOA concepts to introduce an aggregate view for the survey, associating AmI and SOA approaches.

Ambient intelligence (AmI)
Ambient intelligence is sensitive and sensible surroundings. AmI applications gather context using wireless or wired 1 technologies. For example, in ad-hoc/wireless sensor networks, distributed sensor nodes use Wi-Fi, ZigBee, Bluetooth, or Z-wave protocols to gather information from the environment or a monitored field (Rawat et al., 2013). Afterward, AmI applications apply artificial intelligence algorithms to adapt and provide support through interaction with the environment (Augusto, 2007;Cook, Augusto & Jakkula, 2009).
Augusto & Mccullagh (2007) define AmI as "A digital environment that proactively, but sensibly, supports people in their daily lives". Sensible means a rational/reasonable system settled according to reason. Simultaneously, the system is sensitive to the needs, allowing interaction in a proactive and context-aware manner (Sadri, 2011). Being sensible entails recognizing the user (e.g., through learning and awareness of user's preferences) and the capability of exhibiting empathy for their needs, desires, moods, the current situation, and social aspects (Augusto & Mccullagh, 2007). Nowadays, advances in technology provide the means for AmI systems to understand natural human interaction. They are responsive to commands (e.g., voice) and act based on user needs through pattern recognition (e.g., face, gesture) and behavior prediction (Dunne, Morris & Harper, 2021).
The fundamental element in AmI is context. Context is a digital representation of real conditions, considering the internal and external aspects of the system. Relevant to user and application interaction, context is any information used to characterize the situation of an entity (entity is a person, a place, an object, an application) (Dey, 2001), including the characteristics of the entity and application's domain (Ponce,Roy & 1 Wired gathering includes electrical, oil/gas control systems (e.g., SCADA (Supervisory Control and Data Acquisition) and DCS (Distributed Control Systems) facilitate and automatize sensing and human decision making) (Galloway & Hancke, 2013) Abdulrazak, 2016). In autonomic computing, entities also represent the self as context, working with locally accessible information that includes their settings, operations, and semantics (Abdulrazak et al., 2010b). In an environment, the sensors allow gathering context, and the actuators enable the interaction. When the context is available, the system represents it through context management processes. The system then applies different data processing and reasoning techniques, providing ambient adaptation and digital support ( Table 1). The general structure of an AmI system considers the following (Augusto & Mccullagh, 2007): Environmentthe source and final supported entities (e.g., user, robot, another system).
Sensors and actuatorspeople, systems, and devices producing context, gathered through sensors and receiving commands through actuators.
Middleware -API, virtual machines, network devices, etc., for system distribution, gathering, processing, and actuating. Decision-making enginereasoning with a knowledge repository for a proactive or reactive adaptation. Discovery and learning -To update the decision-making engine with experience over the whole system.
Context-awareness characterizes AmI systems. Schilit & Theimer (1994) introduced context-aware computing as-a capability of the applications to discover and react based on variation in the environment (Schilit & Theimer, 1994). Abowd, Dey & Brown (1999) extended the scope of awareness, highlighting the context's significance, where information and services are relevant to the user's task. Roy (2019) considered the scope of context-aware agents' mission performing their micro assessments.

Reasoning
Based on AI reasoning and learning techniques, e.g., description logic, situation calculus, dynamic belief networks Adaptation (contextawareness) Context-based (Knappmeyer et al., 2013): query context on demand (synchronously) and adapt based on current context parameters, e.g., a mobile application that query GPS coordinates at lunchtime to notify nearby restaurants Context-aware (Knappmeyer et al., 2013): event-based (asynchronous) context diffusion and adapt based on events of interest, e.g., a mobile application registered to a restaurant, and receive a notification when the user is nearby and at lunchtime Situation-aware (Knappmeyer et al., 2013): higher-level aggregation of context. The adaptation considers historical context, current user activity, a selected plan, e.g., an application recommending a restaurant regarding past taken meals (time/place), and previous accompanying people Social-aware (Lukowicz, Pentland & Ferscha, 2012): a special case of situation-aware. The adaptation considers the synergy of entities, communities, and social dynamics, e.g., an application recommending a route based on traffic congestion and commuting patterns.

Security
Based on information security principles, e.g., context-based access control Dissemination Based on the ubiquity and middleware distribution approaches Intelligence Represent, reason, learn User model, spatial & temporal reasoning, activity recognition, planning & decision-making. Multiple algorithms and models, e.g., probabilistic, propositional logic, fuzzy logic, AI Planning, natural language processing, deep learning.

Reasoning
Based on intelligence and context awareness, e.g., semantic interoperability, smart-spaces Intelligence, involving algorithmic support for decision-making and learning; the algorithms complement different aspects of the system. Ubiquity, distributing/integrating information from spread entities for providing an everywhere and an every-time provision; the entities extend the perception and interaction to the ambient, enabling the use of available devices, objects, and other entities.
Context-awareness is part of a context lifecycle where we find approaches to model, represent, process, and disseminate the context (Zhang et al., 2011). Ubiquity involves interaction design and distributed computing (e.g., ubiquitous or ambient computing). AmI relates human-computer interaction (HCI), smart sensor and actuator technologies, participatory sensing, embedded and machine-to-machine technologies, wired and wireless sensor networks, mobile networks, pervasive computing, cloud computing, and the IoT (Poslad, 2009;Zhou, 2012;Christin et al., 2013;Acampora et al., 2013) ( Table 1).
Applications in AmI systems demand an architecture style, considering multidimensional design principles (e.g., interaction design, sensor/actuator management). We examine one dimension in this survey: the provision of service.

Service-oriented architecture
Service-based systems have achieved a significant level of formalization and promote the strengthening of software design (Bianco et al., 2011;Nacer & Aissani, 2014) and have reached a broad deployment in business ( Van-der-Aalst, 2013). Emerging technologies such as cloud computing (Rahimi et al., 2013) and the IoT (Xu, He & Li, 2014) also adopt service designs. SOA is the reference model for service-based systems. The SOA model applies the separation of concerns design paradigm and defines the service as the solution logic. A service abstracts functionality, hiding underlying details, executing actions as autonomous entities. SOA establishes a set of interrelated design principles 2 for the architecture (Erl, 2005;Bianco et al., 2011) and associates the following aspects: Interoperability, based on the standardization of interfaces, components' inputs/format, and a formal definition of elements for sharing services (service contract). The formal definition includes an implicit or explicit semantic description. This aspect facilitates integration, adaptation, validation, federation; and supports security. Loose coupling, by designing self-contained services (i.e., with independent technologies and capabilities) with communication through messages, ideally agreed with a service interface description. This aspect facilitates the integration, adaptation, and it is the basis for building scalable architectures. Composability, by using reusable and compatible services to compose or aggregate functionality. This aspect augments the reactive or proactive capabilities for diverse scenarios.

Services provided by ambient intelligence systems
Access to efficient services characterizes SOA systems. Efficiency is a salient attribute for the service consumer who requires a quality of service from the provider. Following, we identified the SOA features applied to AmI (Sheth, 1999;Kephart & Chess, 2003;Bianco et al., 2011;Stavropoulos, Vrakas & Vlahavas, 2011;Knappmeyer et al., 2013;Raychoudhury et al., 2013) which are the main aspects adopted for the survey (Table 3): In communication and integration, attributes to exchange context between entities and services, involving distribution and interoperability. In application logic, approaches for the composition and the aggregation of services, including algorithms to the couple, reuse, and organization of services.
In monitoring and management, mechanisms for governance: managing, monitoring, and maintaining available and efficient services. In registry and repository, attributes for building visible services and approaches to use services before and after deployment.
Ambient intelligence applications demand service governance, i.e., capacity to control components for providing efficient services. AmI applications also require autonomy in environments, such as in smart cities, independent living, and e-health. Service-based AmI systems provide governance following SOA principles and patterns. We define three types of architectural styles for AmI service systems: SOA-based, selfservice, and hybrid: (1) SOA-based are when governance is mainly on a server (even though having distributed components), enabling a controlled environment, e.g., a central server, cloud, (2) Self-service are when agents provide self-governance, enabling an autonomic provision, and (3) hybrid when the governance involves both, e.g., with agents, fog computing (Fig. 1).
We have presented in this section a conceptual schema that characterizes AmI (Table 1) and service-based AmI systems (Table 3). In this survey, we intend to find the synergy between AmI systems and SOA. Therefore, we selected applications to assess interrelated Table 2 Structure of SOA, WS, and self-service.
SOA (Papazoglou & Heuvel, 2007;Merson et al., 2011) XML Web-Services (WS), Semantic WS (Nacer & Aissani, 2014) and REST WS (Pautasso, 2014) Self-Service (White, Hanson & Whalley, 2004) Communication and integration: With a broker or enterprise serial bus (ESB) as an intermediary between provider and consumer, that allows for a normalization of the interaction. It is not necessary for homogeneous environments.
Two ways: (1) Developing an interface; (2) using a communication/integration layer which either (    AmI-SOA characteristics. In the following section, we describe our method for the analysis.

REVIEW METHODOLOGY
We adopted the systematic mapping process-a literature review methodology to build a categorization scheme that structures the types of research reports and results in published papers (Petersen et al., 2008). The adopted process relies on the definition of research questions to search relevant papers to extract data. The outcome of the process is a systematic map with the frequencies of publications based on a classification scheme. Our method (Fig. 2) begins with determining research questions and continues searching for published papers in research databases. After, we screened the papers based on our inclusion criteria, selecting 68 relevant research projects for analysis (see Table 4 for details). Then, we defined the classification scheme, which also refined our conceptualization (Section "AmI and SOA: Definitions and Related Technologies"). Finally, we evaluated the selected papers, extracting data and creating a mapping of studies.

Research questions
The following are our research questions (RQ) and their aim (

Search strategy
We searched using the title, abstract, and keywords with different syntax is depending on the target research database. The generic search string is the following: (ubiquitous OR pervasive OR context-aware* OR "Internet of Things" OR IoT) AND ("ambient intelligence" OR "smart environment" OR "smart space" OR "smart habitat" OR "smart city") AND ("service-oriented" OR SOA OR "web service" OR (autonomic AND service) OR "microservice").
We conducted searches on the following research databases: IEEE Xplore, ACM Digital Library, Scopus, and Web of Science.

Inclusion/exclusion criteria
After conducting searches in research databases, we obtained 712 papers. Subsequently, we examined and selected suitable papers based on the following criteria ( Table 4): The year of publication, the relationship with the subject, research type, comprehensibility, and the type of document (i.e., proceedings and journal papers). The range of the year of publication started in 2001, based on the growth of research in ubiquitous and pervasive computing (Zhao & Wang, 2010). The relation with the subject depends on the fulfillment of the conceptualization. The type of research characterizes the contribution of the paper (Wieringa et al., 2005). The survey only considers papers that propose a solution with proof-of-concept and philosophical papers that propose a model/framework. We discarded papers that evaluate a system, opinion papers, and papers describing personal experiences. We evaluated papers with understandable information, complementing the analysis with their related works and references.

Data extraction and classification
After a first screening, we selected 198 papers for a detailed screening. After a second screening of the papers, we analyzed the information of 68 papers corresponding to 48 research projects. Nine projects include progressive works with two or more papers (e.g., Abdulrazak et al. with two papers: Abdulrazak et al., 2011;. Subsequently, we defined the final classification scheme using the selected papers and the conceptualization (Section "AmI and SOA: Definition and Related Technologies"). Table 5 lists the classification facets and their contribution to the research questions of the survey. In general, the papers focus on service architecture, and we could match most of the service-based characteristics (Table 3) in the Service facet. Conversely, related to the AmI characteristics (Table 1), the papers describe mostly the awareness (for adaptation) and ubiquity (i.e., distribution, mobility, autonomy) included in the AmI facet. We also include aspects in the AmI facet regarding the research questions: We include the target domain to identify a variety of uses. It follows Sadri (2011), where the author studied AmI projects by domain. The domains include, among others, applications for smart home, assisted living, healthcare, business and commerce, leisure and tourism, human-inspired (integrating emotional user data), as well as projects for general data management (e.g., sensor networks) and AI techniques (e.g., self-organized robot control). We include whether the service is considered part of the context (service-as-a-context) and its inclusion in context-awareness (e.g., improving the quality of service). We consider whether the projects include agent technology due to the agent-based software approach's contribution to AmI systems (Cook, Augusto & Jakkula, 2009).
We also introduce the research/global facet that comprises the publication year, whether the project considers security aspects and the research type. The research type follows the classification of the systematic mapping process presented in Petersen et al. (2008). Each project's category derives from screening papers and identifying whether the project is a solution proposal (i.e., application for a particular domain) or a framework/ model (i.e., general design).
The final step is creating a systematic map, being the basis for further analysis. In the following sections, we present the systematic map and discuss key findings.

DATA ANALYSIS: SYSTEMATIC MAP
We have analyzed each research effort based on the classification scheme (presented in the Section "Definition and Related Technologies"). We used different tools to group information during the analysis, build mind maps, and create lists and graphs for each facet (i.e., service, AmI, research/global). In the mapping process, we extracted detailed data to the extent that the information exists in the papers, including information from tables and figures when necessary. Tables 6 and 7 list the final categorization of the data extracted from the projects.
In this section, we start with a description of each selected research project. Then, we present the overall results and illustrate the relevant aspects of each facet.

Service governance in ambient intelligence systems
We classify the projects into five groups related to the governance design within the architecture style (i.e., SOA-based, self-service and hybrid): a) centralized governance, a broadly implemented approach with a controlled architecture; b) centralized governance with distribution, centralized but adding components for the distribution of governance; c) distributed governance, with service aggregators such as gateways (or proxies), bringing capacities/governance near the devices; d) governance including agents, i.e., components to spread the governance; and e) self-governance: Governance in autonomic/autonomous architectures.
In this section, we present our classification with a summary of the main aspects of the selected projects, describing the research's objective, the architecture components, how they integrate into the context, and the relationship between context and the provided service. The description avoids technologies or specific implementations (unless essential to the description) to maintain a technology-independent mapping. As a rule, we identify each research effort with a "first author et al." format. For the projects that include more than one research effort, we identify them using the latest paper.

Centralized governance
Service governance with centralized components is the traditional design strategy. Diverse software architects use an SOA-based framework to implement SOA compliance. Others apply SOA characteristics as needed, use Web Services and other technologies such as ontologies to provide service or interoperability meaning.

Centralized governance with a SOA-based suit/framework
Using SOA suits is an approach to include service orientation because they apply SOA compliance in their design. In addition, SOA-based suits provide centralized components to manage more services and many service compositions, use various communication protocols, and process multiple accesses/messages. Baresi, Guinea & Pasquale (2007) have introduced the Dynamo framework to manage self-healing services. The framework is an aspect-oriented extended version of the  ActiveBPEL process orchestration engine, including business rules (with the JBoss Rule Engine). In addition to business process management (BPM), the framework includes a monitor and a recovery manager. Based on rules, the engine performs monitoring with data collection and data analysis, considering internal and external variables and historical context such as performance deterioration in the past. This information is combined with a self-healing rule-based recovery strategy. Yin et al. (2007) have presented an SOA and tool for service composition in smart spaces. The architecture comprises development and runtime environments. The development environment includes a GUI for the design of services and applications. The runtime environment contains three layers: the OSGi platform, middleware, and application layers. The OSGi platform provides SOA capabilities. The middleware enables OSGi service registration and discovery regarding user behavior and service capability attributes (e.g., QoS, context information). Finally, the application layer contains a category-based division of applications, composite services, and atomic services to facilitate reaction in need for alternative actions. Gouin-Vallerand et al. (2010) have presented a context-aware SOA framework for smart spaces. Context-aware reasoning infers a device capability quotient (DCQ) to determine the quality of context produced by the devices and, as a result, the most suitable environment device to use. The framework adopts the OSGi platform SOA capabilities (Gouin-Vallerand et al., 2009. In addition, it implements communication and security protocols, an administration tool (UI), an environment manager (coordinator for deployment, discovery, gathering, and reasoning), and a device request manager. The framework also includes an ontology handler. Finally, it manages a smart space meta-ontology representing the being, environment, and dynamic tasks (Abdulrazak et al., 2010a).
Using SOA-based frameworks introduces components with non-required characteristics. Thus, diverse solutions implement SOA characteristics as needed. For example, Yachir et al. (2015) have presented FASEMan event-aware framework for ambient intelligence. It introduces a Bayesian learning mechanism for QoS estimation, services invocation, and other processes. The architecture comprises five modules: Service discovery, service classification, user task specification, events handling, and service selection. The service discovery that is subscribed to service providers (i.e., directories) receives and registers services. The service classification creates classes of services based on a global ontology. The task specification enables users to create an ontology-based specification of tasks and requirements, e.g., event rules. The event handling subscribes to the events (defined in event rules) and triggers ambient services. Finally, the service selection invokes the triggered events from service providers.

Centralized governance with web services
Web Services (WS) is a well-known implementation approach because of its SOA compliance, standardization, and interoperability support. Athanasopoulos et al. (2008) presented an SOA framework for context management in AmI systems. The framework enhances the capabilities of a base middleware for mobile WS (Issarny, Sacchetti & Tartanoglu, 2005), facilitating the dynamic integration of context through additional services for context sources discovery, context aggregators, and context interpreters. The context discovery supports presence in the environment, as well as discovers and registers available WS interfaces. The context aggregator allows for defining relations, using custom rules for context gathering and processing, and producing relevant context information. The context interpreter is a context SQL assembler.
Silva, Mouttham & Saddik (2009) have handled the medicine prescription management problem for aging people in AmI. Implementation includes a centralized server supporting the scheduling and history of intakes. The server implements WS accessed by mobile clients. The architecture consists of an event manager and a personal health record (PHR) interface. The event manager handles intake feedback events and proactive alerts sent to physicians and relatives when the intake interrupts. The PHR service interface acts as a loose coupling proxy to external PHR information and prescription information.
Prehofer & van Gurp (2010) have presented a REST-based framework for smart spaces, including functionalities for finding and securing relevant local resources based on context information from devices and users. The framework consists of a web platform, middleware services, and web portal-based applications. The framework includes service registration and discovery through a search engine to support resource localization. The framework also provides security services and context services. Security services guarantee access to resources using authentication and authorization. Context services interface relevant resources to users. Yusro et al. (2013) have presented the smart environment explorer stick (SEES)-a smart cane for people with visual impairment. SEES integrates data from a camera, GPS, wheel encoder, ultrasound, compass, and accelerometer, producing context to analyze aspects such as color, obstacles, route, surface roughness. SEES includes algorithms for image processing of traffic lights, tracking, location, alerts, etc. SEES consists of a global server (iSEE) and two subsystems: SEE-stick and SEE-phone. iSEE provides WS, such as localization and remote monitoring. The SEE-stick and SEE-phone are interconnected through WiFi, increasing the phone's sensing/actuating capabilities with an augmented perception provided by the stick.

Centralized governance with ontologies
Nowadays, SOA frameworks also regard knowledge representation to improve governance because it enables maintaining exact service/context meaning. Diverse projects have considered ontologies to represent system components, to facilitate interoperability or both.
Ahn & Nah (2010) have presented a WS context-aware framework to allow users to use services anytime and anywhere. Registration and matching algorithms utilize a service category ontology that classifies service types (e.g., shopping, transport). The framework includes three components: service provider, service requester, and service broker. The service provider handles context integration from sensors (processing location data) and the service registry. The service requester manages the context-aware client. The service broker implements a service finder based on a matchmaking pattern, matching the requested category of service, location, and available communication protocols (e.g., ZigBee).
Paganelli & Giuli (2011) presented a context-aware SOA platform for home and continuous care support. The platform adopts the Web and semantic services, including three components: a multichannel healthcare services manager, a central and patient context manager, and a wireless sensor system. The multichannel service manager maintains an ontology-based assistance model and services, including patient records, profiles, and alerts. Both the central and patient context managers provide back-end services for processing context changes and deliver continuous patient support at a central care center or patient's home. Finally, the wireless sensor system collects the patient's biomedical data (e.g., heart rate) and environmental data. Albreshne, Lahcen & Pasquier (2013) have presented an approach for modeling, discovering, orchestrating, and executing services for smart residential environments (SRE). It incorporates an ontology to describe the SRE and capabilities of devices and a domain-specific language (DSL) to design and control the environment. The framework comprises templates' repository, process generator, execution environment, client user interface (CUI), and execution engine. The templates' repository stores the templates defined by a process template tool using both the ontology and DSL. The process generator interprets a template and generates an executable. The execution environment handles SRE services. The CUI allows the definition of user preferences. The execution engine is the process runtime environment. Hasswa & Hassanein (2013, 2011 have presented a smart social space framework to enhance users' experience by providing adaptable multimedia services. It implements an ontology representation of the user's profile, preferences, and services. The framework includes services to manage feeds and geo-feeds, location and presence, and user profiles from social networks. The architecture comprises communication services, an application server (interact and coordinate processes), presence and a policy server (propagates changes to subscribed users), a location awareness server (manages geographical information), a home subscriber server (provides persistence), client-user agent (mobile application), a social network manager, and a system manager.
Triboan, Chen & Chen (2016) have presented a REST-based solution for AAL. The architecture includes three components: WS platform, triplestore, and Android application. WS platform consists of the following layers: (a) smart WS API (exposes services), (b) façade (abstraction of complex and CRUD operations), (c) repository (knowledge base), (d) domain (data mapping among layers), and (e) utility (low-level processes, e.g., communication, ontology management). The triplestore layer includes a database to store triple datasets for semantic interoperability. The Android application provides the primary system interface.
Gonzalez-Usach et al. (2017) have presented SAFE-ECH -an IoT SOA system to monitor and control AAL residences. The system includes functionalities for the management of multiple residences, accessing globally and locally through an HMI. Diverse WSs enable communication to the HMI and a sensor observation service (SOS), complex event processor (CEP), and other services. The HMI allows authorized users to visualize information, configure system rules and services. The SOS manages sensor data, storing data observation based on the Open Geospatial Consortium semantics. The CEP includes rules to process SOS events and execute actions. Other services include an alarm manager to handle high-priority events and a broker to handle communication between system elements.

Centralized governance with distribution
Diverse projects maintain the governance in centralized components and use remote components (e.g., agents) to gather context, distribute services, or deploy processes. , with several authors (Smirnov & Levashova, 2009;Smirnov et al., 2010, proposed a WS context-aware decision support system for situation responses in emergency scenarios. It incorporates an ontological description of the resource network and situation management domain. The system includes profile management (i.e., capabilities of each operation member) for providing a role-based response. The system also comprises support services and agent-based services. The support services include core services (to manage context, registry, and monitoring) and operational services (to manage resources and decision-making), and wrap services for external sources. Agent-based services are intelligent agents collecting information, negotiating with other agents, and calling associated supporting services to execute action plans.
Amoretti (2012) have introduced an SOA framework based on autonomic hosts for AmI. The architecture consists of networked autonomic machines (NAMs) with ontologies to describe a smart environment. NAMs comprise resources and functional modules. The resources are fixed or changeable (e.g., battery level). The functional modules play the role (based on their definition) of context/service provider or consumer. Functional modules can also execute missions, functional policies, and self-management policies. The functional policies are mission-based processes (such as rules, algorithms, evolutionary plans). They enable a reactive service execution or call and publish context based on incoming events. Pan et al. (2014) presented an SOA framework for AmI applications. It connects pervasive services through a bus capable of linking sensors and devices, software components, and distributed services (e.g., cloud, WS). The framework uses an ontology to represent heterogeneous services as uniform pervasive services. It includes a service bus that manages a group of sub-buses for effective peer-to-peer communication. A sub-bus operates services with similar protocols or frequently required. Sub-buses discover known protocols and register services (publish-subscribe pattern) on the main bus. The services are orchestrated with a planning-based approach based on (1) a task's goal, (2) flow of services, and (3) context and quality requirements.
Nosović, Peters & Bruegge (2014) presented a framework for controlling smart environments, which abstracts device protocols providing consistent communication through an ESB which integrates: Device controller, device repository, client adapter, decision-maker, security controller, and environment tracker. The device controller provides the protocol abstraction. The device repository stores properties (e.g., protocol type, location). The client adapter provides a uniform request (e.g., get location) and set (e.g., set state). The decision-maker process rules (trigger events) and machine-learning (inhabitant recognition). The security controller provides authentication, access control, and priority-based requests. The environment tracker registers automatic state changes (e.g., temperature variation) or caused by users (e.g., turn on a light).
Prado, Ortiz & Boubeta-Puig (2017) presented CARED-SOA-an event-driven SOA for the IoT. It integrates a complex event processing (CEP) engine to provide a short-time data stream processing. CARED-SOA includes three components: ESB, alert manager, and context broker. The ESB facilitates communication. The Alert manager receives/retrieves data, adapts and stores it, and sends it to the CEP engine. Afterward, the CEP engine evaluates alert patterns and sends the IoT context (i.e., CEP matching data) to the context broker. The Context broker keeps a knowledge database of users' context (e.g., age, location). Then, a context reasoner analyzes the context and sends notifications. Finally, a context adviser processes the notifications and sends them to the user. The authors improved the architecture to integrate client-side context (via a mobile app) and security functionalities (Caballero et al., 2021).
We presented in this section projects with remote components supporting service governance. They perform assigned tasks, but they maintain centralized governance in a central component, e.g., a complex event processing (CEP). Furthermore, remote components can also incorporate governance (e.g., collaborative policies), producing implementations that distribute governance. We present these implementations in the following section.

Distributed governance
Several approaches take advantage of remote components (e.g., proxies, gateways) close to sensors/actuators and locally manage resources and processes. In general, distributed governance optimizes the architecture by improving the performance for gathering context, integrating services, and providing remote user interaction. Kawashima et al. (2009) have worked on a ubiquitous SOA platform for smart spaces, using distributed gateways to reduce overload over resource-constrained devices. The platform includes a server, smart space gateways, and smart applications. The server provides discovery, storage, service interface and management, communication, and sensing/actuation services. The smart space gateways connect heterogeneous devices for discovery and sensing. They support communication protocols and services to interact with devices or another gateway. Smart applications are both embedded applications in the server or web-based applications.
Bernardos, Tarrío & Casar (2009) have presented an SOA middleware to support AmI applications. It includes acquisition, fusion, presentation, and control layers. The acquisition layer gathers context from physical and virtual sensors. It implements software modules in gateways (on mobile devices) and signal adequacy and preprocessing in a server. The fusion layer implements services for feature extraction (through APIs) and an upper-level context inference. The presentation layer includes event notification services (context changes) to consumer applications. The control layer maintains persistence and enables a multi-layer registry, query, and subscription of services. Reetz, Tonjes & Baker (2010) have presented an SOA solution to increase the performance of WSNs. It is based on the C-Cast middleware, where a central componentcontext brokerintegrates different context providers connected to environmental, virtual, and logical sensors. The solution focuses on the environmental context provider, integrating wireless sensor gateways, and communicating with the context broker. The environmental context provider incorporates services. It also implements data management and sensor gateway interfaces for connecting the context broker, consumers, and other sensor gateways. Services include context detection and adaptation, sensor discovery and synchronization, data aggregation and fusion, and monitoring. Roggen et al. (2011) presented Titan -an SOA framework for discovering resources based on user activity recognition. Titan consists of three components: a mobile device, Internet application repositories, and Titan nodes. The mobile device allows discovering resources from the personal area network, downloading code (if necessary), and executing services from pervasive applications. Internet application repositories store application references and application templates. It contains composite service graphs according to available resources. Titan nodes perform activity recognition; then, they instantiate, reconfigure, and execute sensor nodes' services. They also provide communication, synchronization, management, and governance. Degeler et al. (2013) presented an energy-aware SOA architecture for smart buildings. The architecture consists of three layers: physical, ubiquitous, and composition. The physical layer connects smart grid services (for pricing and local/external energy availability) and integrates devices using hardware gateways. The ubiquitous layer includes a context manager (for producing high-level context and activity recognition), repository manager (for maintaining data), and orchestration manager (for executing and scheduling actions). The composition layer includes control services (system interface, e.g., dashboards) and composition services (rule matching, AI planning, and computational fluid dynamics for heating conditions). Stavropoulos et al. (2013) have introduced an SOA middleware for AmI. The architecture defines hardware, integration, and service and application layers. The hardware layer corresponds to physical devices such as ZigBee smart plugs, sensor boards, smart clampers, or Z-Wave devices. The integration layer consists of individual physical hardware drivers, including their interface, communication, and operation protocols. The service and application layers adopt a WSDL wrapping of device functions and complementary services, e.g., service to query IT context (e.g., ping, find MAC address, get CPU usage). Buzeto et al. (2013) have presented uOS -a middleware for sharing resources in ubiquitous environments. Using proxies, uOS integrates different networks endpoints with diverse protocols (e.g., Bluetooth, WiFi) and resources (through a resource ontology). The architecture follows the Device Service Oriented Architecture (DSOA) and ubiquitous protocols (uP)-a lightweight set of protocols designed to facilitate communication in DSOA (Buzeto, Castanho & Jacobi, 2011). The middleware includes an abstraction of the software, hardware, and communication platforms using uP, removing constraints for integration. uOS combines network plugins, resource drivers, and applications. In addition, it includes a network layer (manages input/output and discovery), a connectivity layer (provides a message engine to manage uP protocols), and adaptability layers (integrates resources and applications).
Forkan, Khalil & Tari (2014) presented a solution for unifying context generation for AAL. It includes five cloud-oriented components: AAL systems, context aggregator and providers (CAP), service providers (SP), context-aware middleware (CaM), and context data visualization (VIS). The AAL systems comprise AAL cloud sensor data providers and service customers. The CAP abstracts context representation through context fusion and reasoning. The SP links applications or external services. The CaM processes, stores, and retrieves context and performs computational tasks such as management of services, context-to-service mapping, access control, and service delivery. The VIS provides a GUI for data (e.g., medical records). The solution includes an ontological context model, but the interoperability is through XML. The PEP is on devices providing resources, allowing requests/authorizations. The PDP, which is on controlling nodes, evaluates requests/authorization. The PAP and PIP (on controlling nodes) create/manage policies and store attribute values. The CP enables routing discovery messages. The Broker distributes messages to subscribed proxies. Dar et al. (2015) presented a resource-oriented architecture to integrate IoT devices into business process (BP) applications. It includes a registry of IoT services described with standard languages (e.g., WSDL) and an API to invoke IoT services. Then, a BP developer uses the API to compose IoT-aware processes. The architecture also includes an event manager for interaction (service subscription), a service replacement manager to query the registry, matching and selecting an appropriate candidate (or randomly selecting if multiple matches), and a device status monitor to register possible IoT device failures. A BP or the service replacement manager subscribes to update the failures. Multiple BP engines enable a distributed execution of processes in both a central server and smartphones. Lee et al. (2017) have presented SoPIoT-an SOA IoT platform that abstracts as a service the functionalities of IoT devices and cloud. It allows registration of IoT device services using TCP/IP, lightweight protocols (e.g., Bluetooth) using gateways, and cloud functionalities as virtual devices. SoPIoT includes a script editor to compose services and middleware to store, monitor, and mediate service transactions. The middleware consists of three managers: (1) Device manager, for handling and monitoring devices; (2) Composite service manager, for translating scripts, monitoring, restarting (contextaware), and notifying service status; and (3) Data manager for sending data and checkpointing to perform recovery.
Malik & Kim (2019) presented a framework for sensor networks with geographical data management. It includes a virtual sensor platform to provide context (gateways connected to sensor networks) and a composite toolbox to create service profiles. The toolbox manages sensor networks with geospatial context, environment context, and physical sensor context. Service profiles are registered into a service registry, keeping available services at running time. The service profiles are then deployed to service platforms for service provision, querying the registry, and interacting through the gateways. Pitatzis et al. (2020) presented a microservices-based platform for IoT devices available in AmI environments. The platform includes a gateway to provide service registration and discovery. The gateway connects IoT devices (physical or virtual things) microservices, i.e., independent building blocks/services handling its processes. It includes a rule engine to evaluate device rules with priorities. The platform handles policies to enforce proper device operation (e.g., can switch off only one minute after switching on) and provides a state maintenance mechanism to persist snapshots of devices during a shutdown to ensure service continuity. Javed et al. (2020) presented a framework for smart cities to achieve cross-domain/ cross-application service integration. The framework adopts open communication and data standards. It includes a service marketplace for data and service capability distribution and the corresponding functionalities and API to govern the services. The framework also proposes IoT gateways to integrate IoT systems/smart objects and external cloud-based solutions. The framework also adopts security functionalities (authentication, authorization). Gooder et al. (2021) proposed a microservice-oriented middleware for service composition, matching device capabilities in smart environments. The middleware integrates IoT device functionalities to create on-demand services based on a service request. The middleware connects a service publisher and a service subscriber. The publisher gathers IoT device data/capabilities and make them available to the middleware. The subscriber interacts with the environment, e.g., to manage user service requests. The middleware matches the capabilities and requests, assembling and delivering a composite service. The middleware also includes security/auditing functions and QoS monitoring.
Architectures with distributed governance involve similar technologies/languages/ protocols as centralized governance (e.g., WS, ontologies). The difference lies in the resources, capacities, and policies of the distributed components (e.g., mobile devices, brokers). However, still exist a centralized component (e.g., WS server) that provides the governance. Conversely, when this centralized component is indistinguishable among distributed components, the governance depends on the behavior of all components (i.e., intelligent agents).

Governance including intelligent agents
Diverse approaches implement agents with rules to represent complex behavior. Even though the following projects also include non-agent components, this section focuses on the governance implementation in agents, e.g., agents performing discovery/composition of services. Soldatos et al. (2006) built a framework for integrating perceptual components and the context of space, creating a model of the situation, thus enabling intelligent resource discovery and management. It includes an ontology knowledge base (KB) and three layers: sensory, perceptual, and agent layers. Sensor proxies manage the dynamism of sensing the environment. The perceptual layer is implemented using IBM's CHILIX library, enabling person localization/tracking, body detection/recognition/tracking, speech/acoustic/emotion/activity recognition, and lips observation. The agent layer includes agents for discovering and registering services in the KB. It also manages device integration, user profile, and service requests and performs system management and monitoring.
Miyata, Morikawa & Ishida (2009) have worked in a service-oriented smart space learning system. The architecture (Suo et al., 2008;Miyata, Morikawa & Ishida, 2009) is based on WS and includes three components: WS wrapper agent (WSWA), smart platform agent web service (SPAW), and open smart platform gateway (OSPG). WSWA is an intermediary to external services (e.g., language services), invoking them as required by other agents. SPAW is the WS server, providing interaction inside and outside the platform and creating agents to manage requests. The OSPG is a proxy for mobile devices, allowing interaction with platform services using a web browser.
Bhuvaneshwari & Sujatha (2012) have worked on VAISTC4 -an agent-based SOA system for traffic congestion control. It consists of a backbone of agents merging information from different sensors (e.g., cameras), preprocessing the data, and putting relevant information in a database. VAISTC4 is based on the ATRACO framework (Goumopoulos et al., 2008;Seremeti, Goumopoulos & Kameas, 2009;Bidot, Goumopoulos & Calemis, 2011), i.e., an SOA middleware for AmI systems. ATRACO includes an ontology model for the user and environment profiles (Seremeti, Goumopoulos & Kameas, 2009) and allows service composition through AI planning and workflow (Bidot, Goumopoulos & Calemis, 2011). In addition, VAISTC4 provides event channels for registering sensor and effector agents. Sensor agents are attached to devices and can command events (e.g., change the timing of a traffic light), and effector agents are scattered in the environment close to users (e.g., mobile). Familiar, Martínez & López (2012) have presented an architecture for wireless ad hoc and sensor networks that includes three platforms: physical device, pervasive, and SOA. The physical device platform abstracts the hardware and provides software capabilities for integrating devices. The pervasive service platform uses the separation of concern paradigm to identify and encapsulate properties into different services. The SOA platform constitutes the backbone of the integration. It includes a control service layer (based on a publish-subscribe approach ), cross-layer services (providing security and resource-available-service reasoning), low-level service layers (agent-based components and context discovery), high-level service layers (service control and QoS), and internetworking service layers (agent-based service composition). Tapia et al. (2013), together with several authors (Corchado, Tapia & Bajo, 2012;Tapia, Fraile & Rodríguez, 2009;Tapia & Alonso, 2010;Tapia, Alonso & Corchado, 2011), have worked on a solution for an agent and SOA integration of heterogeneous WSN. It includes a multi-agent layer (called FUSION@) and remote service-based agents (called HERA). FUSION@ implements agents and communication capabilities to facilitate the distribution and management of resources and services, allowing for moving functions to where actions are required. HERA is directly embedded in WSN to manage sensing data and is the evolution of SYLPHthe first SOA platform with an application layer and a message layer (Tapia & Alonso, 2010;Tapia, Alonso & Corchado, 2011). The platform includes an admin, an interface, a supervisor, and security agents with explicit policies to support the execution. Ferilli et al. (2015) presented a smart environment MAS architecture to execute services for actions in user workflows. It comprises a knowledge base (KB) and three layers: environment, reasoning, and learning. The environment represents sensors, actuators, and services. Reasoning and learning layers are agent-based with the following modules: (a) AmI coordinator (applies the KB), (b) incremental theory learner from examples (refines the KB), (c) workflow manager (controls executions), and (d) service planning identifier and composer (provides service composition based on semantic Web). A composite service interoperates with the workflow manager to achieve goals based on constraints, preferences, or requirements. Then, the workflow manager can act (through agents) or refine a process (learning). Fysarakis et al. (2015) have presented a framework for real-time security, privacy, and dependability of AmI systems based on pre-defined metrics. It includes four layers: node (embedded devices), network (connected nodes), middleware (network management), and overlay (control agents). The framework uses the OSGi platform for SOA compliance and management of embedded devices. Different agents are deployed into OSGi, implementing two core components: reasoning and ambient/system manager. The reasoning evaluates the metrics and composes elements (i.e., operations, attributes) from the different layers. Afterward, in real-time, the ambient/system manager controls the resulting composition, e.g., change the configuration to increase the security level. Mohamed et al. (2017) have presented SmartCityWare-a middleware to integrate cloud and fog computing for smart city services. It includes a service layer and a multiagent runtime environment. The service layer provides core services and environmental services (e.g., cloud, fog, IoT services). The core services enable a secure and location-based invocation of services. It includes a broker that is responsible for environmental services advertisement, discovery, and registration. The multi-agent runtime environment includes agents to deploy, schedule, and support the execution of distributed services and provide governance of available fog resources.
Architectures that include agents provide a level of "intelligence" because they act based on their policies/rules. However, the agents cannot control unknown situations (i.e., situations not contemplated in their rules). Some projects propose autonomic computing/autonomous agents with a self-governance of services for governance in unknown situations.
Self-governance: governance in autonomic/autonomous architectures Self-governance is a challenging aspect of SOA projects. It involves a higher level of adaptation in service processes (e.g., discovery, composition) for adjusting them to the situations. They include a knowledge base that provides feedback on the situations and learning processes and improves adaptation through changeable policies/rules. Kim et al. (2006) introduced an SOA ubiquitous function (UF) model for the smart control of robots in AmI. UFs represent the environment and its capabilities, allowing operations through functions. The architecture includes three main services: smart object, discovery, and logic. The smart object manages physical objects, mapping them to UFs. The smart discovery finds and integrates UFs. The smart logic controls robots' mission, combining objects with sensors and actuators. It is based on a self-adaptive discovery, registry, and combination of UFs, using a robust internal-loop compensator (RIC)a multiple feedback logic controller with an internal-loop to find and compensate for disturbances (i.e., obstacles for the robot's mission). Penserini et al. (2010) have described a model for service-oriented organizations (SOO) of autonomous agents. The SOO combines service-oriented computing matchmaker and broker agent patterns (Fuxman & Giorgini, 2001;Bresciani et al., 2004a) with Tropos-an agent-oriented software engineering methodology for organizational modeling (Bresciani et al., 2004b;Penserini & Bresciani, 2005). The model includes three SOO architectures: matchmaker, broker, and implicit. The matchmaker and broker SOO extend matchmaker and broker agent patterns, respectively. Both support the provider organizer role with either a consumer initiator (matchmaker) for a direct execution provider-consumer or through an intermediary (broker). The implicit SOO discards the pre-defined provider organizer role. At runtime, a winner provider assumes the organizer's role. It coordinates services, enabling faster environment support. Chun et al. (2011) have presented a self-adaptive scheme for smart space services, using context history as an additional soft-feedback adaptation. It includes an adaptation agent and adaptable software. The adaptation agent gathers context data from sensors. The adaptable software handles internal adaptation using collected data such as sound, seismic, light, video, audio, temperature, and system data such as processes, CPUs, and memory use. The adaptation process follows adaptation plans, including policies and rules. When the system detects the need for a strategy, it executes an adaptation plan-using learning algorithms, the system stores both performance and the executed plan in a knowledge base. Acampora, Loia & Vitiello (2011) have presented an SOA autonomous multi-agent framework for being aware of a user's emotional condition for providing comfort services in AmI. It includes three layers: sensor network, cognitive multi-agent system (MAS), and SOA platform. The sensor network captures users and surrounding contexts. The cognitive MAS manages the distribution of emotional services in the environment. The SOA platform provides service interaction, improving the user's comfort, e.g., soft or hard music services, volume control service. The system adapts its conditions based on the human mood's representation, including variation in emotional, environmental, and temporal situations. Abdulrazak et al. (2011) presented ContextAA-a self-organized service architecture for micro context-awareness of distributed agents, perceiving their local environment, and acting based on their roles. Micro context-awareness represents the usual categories of context (e.g., activity, identity, location, time) and operations and entities such as publishing, requesting, and obtaining an ontologically meaningful subset of contexts for performing a service in a given agent. The architecture  includes host components, agents, context, and context space. Host components serve as middleware, interacting with others and integrating external services. Agents are context-dependent entities responsible for executing actions, differentiating between standard (host services) and user (or domain-specific) agents. Context and context space are organized knowledge repositories at both the agent and host levels. Ruta et al. (2018) presented a semantic-based framework for home and building. It defines autonomous device agents that interoperate to share and orchestrate resources. First, an agent describes its basic features (device type, location, hardware) and its services, such as the device configuration. Next, agents can interact and "post" context, exploited by other agents for sensing (context/events) or actuating (e.g., request for changing a configuration). Agents then actuate or start a discovery process to find potential agents providing suitable services. The semantics follows the Linked Data Platform W3C recommendation, defining devices, services, posts, and other semantic descriptions.
The previous architectures involve the use of context as a key aspect of improving governance. For example, context history and cognitive agents can enhance the governance of services and, as a result, service delivery. On the other hand, an advantage of autonomic/autonomous architectures is that computers can reach desired entity capabilities by self-governed policies/rules, providing self-service.

Mapping and classification
Following the analysis, we classified the papers (Tables 6 and 7). Figure 3 summarizes the research efforts considering each quantifiable characteristic of the classification scheme. In the figure, the contribution axis represents orthogonal aspects analyzed in this survey, inter-relating service-oriented, AmI, and research/global facets. We also considered the quality of service (QoS) in the contribution axis to analyze QoS to AmI elements, e.g., the context history in Chun et al. (2011) and the quality of space in Gouin-Vallerand et al. (2010).
The registry is the service feature most considered among the research efforts with 39 projects (31 are service-oriented, four are self-service, and four are hybrids). Semantic interoperability, which refers to explicit semantics, is the least applied to 16 projects. However, some projects' interoperability use implicit semantics inherited from SOA, e.g., Pitatzis et al. (2020) adopts REST semantics. We classify projects with implicit SOA semantics as syntactic interoperability (i.e., no semantics at the project level). The research efforts adopt other characteristics on different levels. In the AmI facet, 13 projects are agent-based, 18 incorporate architecture components on mobile devices, and 19 propose a higher-level adaptation (situation-aware), introducing state, history, relevant context (e.g., Acampora, Loia & Vitiello (2011) consider human emotions for context awareness). The reviewed solution proposals (Table 6) are domain-specific projects, and thus, they mainly consider the required features for implementation. For example, Paganelli & Giuli (2011) propose a healthcare support system at home that integrates the situation of the patient (e.g., actual activity) and heterogeneous sources (e.g., bio-signals and environmental context) for a situation-aware adaptation, regarding semantic interoperability, in a centralized WS with static access to the services.

RESULTS AND DISCUSSION
According to the systematic map process, we detail in this section the analysis, summary of information per facet, and comparison of characteristics using tables and graphs to answer the research questions. Following, we highlight the relevant aspects of the selected projects.

Ambient intelligence facet
Research efforts provide solutions for various application domains, including, among others, smart home/building, assisted living, healthcare, wireless sensor networks, IoT, and applications targeting business and the city (Table 6). Furthermore, several projects target a framework/model general applicable to smart space or AmI fields. We found a few projects applying security to distributed agents or mobile components inside the domain or field. For example, 18 projects propose mobility (e.g., components in mobile devices), but only three propose a security mechanism in their design. Similarly, 14 projects consider agents (seven agent-based and seven with agents as part of the architecture), but only four propose security.
Also, several projects incorporate the service provided in the context-awareness process to improve adaptation (Fig. 4). Eight projects out of 19 consider service-as-a-context when the application demands a higher adaptation (situation-aware). This ratio is lower in context-aware adaptation, seven out of 18, and for context-based adaptation, it is three out of 11 (Fig. 4). Service facet Figure 5 shows the distribution of service-oriented aspects. Figure 5B compares the distribution where the aspects are either not considered or undefined. The prevalent architecture is SOA-based, with 37 projects following the SOA model, implementing diverse governance (Table 7). Five projects extend the SOA model to the autonomic computing paradigm proposing self-service architectures, and six projects present hybrid architecture. The projects apply different techniques for each aspect of SOA, e.g., lookup, subscribe, direct access, and querying the registry for discoverability (Table 7).

Research and global facets
The demand for ambient service support systems is present in both domain-specific applications and general designs. Therefore, we analyzed the target of the research, finding 18 projects proposing a solution in an application domain (e.g., assisted living); 28 projects proposing a framework (domain-specific or general); and two projects proposing a general-purpose model (Fig. 6A). On the other hand, few projects considered security mechanisms (e.g., access control): Two in 2010, 2012, 2013, and 2017, and one in 2014, 2015, 2016, 2020, and 2021 (Fig. 6B).

Limitations of the study
The central focus of the survey is to analyze the SOA model in AmI implementations. Therefore, we refined the research queries with explicit exclusion of either the AmI or the SOA concepts. The survey also disregards specific aspects such as representing the context, AI algorithms for reasoning, or interaction styles between entities (Table 1 lists other aspects). We also discarded general adoption research efforts with no details of SOA/AmI applied characteristics. As an example of the general case of the discarded papers, we can find WS applications such as regulating the temperature for healthcare support without a registry of services, monitoring, QoS. The limitation is that these discarded projects could contribute to new approaches such as augmented adaptation (e.g., socialaware).

Open challenges and research directions
Distributed computing, mobile systems, and the Internet of Things (IoT) marked the last two decade's development of ambient intelligence (Zhao & Wang, 2010;Lin et al., 2017).
New technologies, such as cloud/edge computing and 5G, provide connectivity to massive IoT surrounding devices in multiple settings (Pham et al., 2020). As a result, ubiquitous technologies are available to interact with users who exploit resources through context-aware applications. Our analysis enabled us to highlight the research challenges and trends of ambient intelligence systems. A couple of traditional challenges have been presented in diverse reviews, e.g., constraints in resources for running services, scalable IoT discovery, protocol interoperability, and security (Perera & Zaslavsky, 2014;Issarny et al., 2016). Following, we present our identified challenges and research directions.

Intelligent ubiquitous services
Computer support is becoming indistinguishable (Weiser, 1991). Researchers are proposing systems for decreasing the cognitive load on users (Weiser & Brown, 1996), systems for pushing technology in moments of cognitive rest (Hallnäs & Redström, 2001), and context-aware systems (Schilit & Theimer, 1994;Abowd, Dey & Brown, 1999). In addition, advances in artificial intelligence and hardware technology contribute to services that appear when necessary.
However, it is still necessary to provide services that vanish in everyday activities and objects. Therefore, different technologies and mechanisms direct the research for providing intelligent ubiquitous services, e.g., body sensors gathering vital signs inputs to the AI algorithm in health care systems (Acampora et al., 2013), sensing-as-a-service QoS model for managing billions of sensors in the IoT (Perera & Zaslavsky, 2014), distributed sensing and big data for an accurate mobile context-awareness in cloud computing (Rahimi et al., 2013). In particular, these research directions have to involve learning and further mechanisms to understand the person (psychological-aware) (Bao et al., 2013), provide individual (in-person) augmentation (Xia & Maes, 2013), anticipate the intentions (anticipatory adaptation) (Pejovic & Musolesi, 2015;Pejovic & Musolesi, 2014) and strengthen the service architecture, e.g., implementing recovery services.

Self-governance: autonomic service providers
The concept of autonomic computing (Kephart & Chess, 2003) continues materializing, bringing self-service and hybrid architectures to AmI. An emerging framework is the open smart environment  which extends the support system to the person's space, providing personal assistance in mobile, distributed, and dynamic scenarios. Open smart environments release the controlled architecture by implementing agent-based support and enabling the use of the context as a pervasive self-governing service provider (Gouin-Vallerand et al., 2008;Abdulrazak et al., 2010bAbdulrazak et al., , 2011. Agents as service providers describe the user and the system's situation in their context, containing self-descriptions of their capabilities and existence. Service interoperability and distribution are complex aspects of governing autonomic architectures for enabling inter-system interoperability 4 . Self-governed service providers maintain knowledge of the self, being aware of their capabilities but restricted, conscious of the global situation among entities. Specifically, the autonomic architecture has to manage conflicts between entities, integrate legacy systems, the federation of services, and implement community-based service conflict resolution. Maintaining a global quality of service (QoS) in autonomic service architectures is challenging. It requires QoS definitions into learning and artificial intelligence techniques to achieve self-adaptation (Razzaque et al., 2016).

Empowering people
Non-[ICT]-technical people use applications in AmI, e.g., solution proposals in the survey (Table 6). Even though SOA contracts can be human readable, e.g., using plain text or XML, non-technical people encounter difficulties managing services. Still, AmI systems use different technologies and data formats, bringing on the necessity of technological support. Nowadays, domain experts use tools for their activities (e.g., using a business process management engine (Baresi, Guinea & Pasquale, 2007;Albreshne, Lahcen & Pasquier, 2013)). These tools require technical support, preventing users from creating their services, allowing only pre-existing components and services.
Other approaches facilitate the integration of context from service providers to support users. For example, IFTTT (https://ifttt.com, last accessed 2021-06-30) allows for the creation of condition/action rules (called recipes) from pre-defined services available as building blocks (called channels). Other platforms simplify building complete applications. E.g., Apache Cordova (http://cordova.apache.org, last accessed 2021-06-30) allows building mobile applications for different mobile platforms based on web standards, integrating the device's sensors and external services through plugins. However, when providing this service, these approaches only consider device context, disregarding user profile. A service can produce a different significance for various users or multiple significances for a user, e.g., a service for a comfortable temperature in a room for a healthy user and a user with the flu.
An emerging approach is end-user as application builders, using cognitive-aid metaphors and software engineering techniques (Paternò, 2013;Burnett & Myers, 2014). End-user software engineering introduces techniques into users' existing workflow, managing the unplanned, implicit, opportunistic, instinctive, and self-priority intents over their applications regarding quality concerns (Ko et al., 2011). These techniques combine artificial intelligence, cooperative work, and human-computer interaction (HCI) patterns to facilitate application development by end-users (i.e., non-technical people) (Lieberman et al., 2006).

Security
Security and safety are constant research topics. Most surveys describe security and privacy issues as challenges. Safety and ethical issues are also identified, especially for healthcare systems. Our study found 13 out of 48 projects considering security aspects regarding (a) context security (e.g., encryption) and (b) security functionalities such as authentication and authorization for using services. In general, a primary aspect is to provide an appropriate integration of heterogeneous resources and maintain adequate security in communication mechanisms and protocols such as Wi-Fi and Bluetooth. Similarly, available services on the Internet increase the context for AmI/IoT applications, e.g., Amazon Alexa skills (i.e., services to integrate) have grown to more than 40.000 in 2018 (Kim & Kim, 2018). These services, often implemented by third-party developers, are a potential security risk.
In a controlled SOA infrastructure (e.g., centralized servers, cloud), it is feasible to deploy security algorithms and mechanisms. Autonomic self-service also defines policies for self-protection, but security is challenging. The emerging paradigm Fog computing enables the distribution of services but introduces diverse challenges such as access control and encryption key management (Alrawais et al., 2017). Blockchain technology, capable of achieving decentralized/autonomous security, is an open research topic in fog/edge computing (Omoniwa et al., 2019). Also, a security challenge is in society, particularly in integrating legacy and external systems and implementing federated services.

CONCLUSIONS
Enabling technologies, resources, and services for Ambient Intelligence applications is diverse-all physical or virtual things could be regarded as context. With ubiquitous technologies and IoT, ambient capabilities increase, making available even more resources and services. Due to the diversity of resources in environments, effective governance of these resources is required for supporting users. A common approach to govern resources in ambient intelligence systems is service-oriented computing. In this approach, services represent the capabilities of entities, and a service platform provides the governance of the services. We presented in this paper the Ambient Intelligence Perspective and the Results of our review and analysis of Ambient Intelligence system implementations considering service-oriented architecture (SOA) as a reference model for the distribution and delivery of AmI services.

Ambient intelligence perspective
Ambient Intelligence is one of the paradigms of computer science targeting automating the interaction with surrounding resources. New computation technologies, such as cloud computing and edge/fog computing, make available computational services and control everyday objects and devices. These technologies augment ambient intelligence systems through context-awareness. They sense and actuate via physical artifacts such as IoT devices (e.g., lights) in a dynamic and distributed setup (e.g., street lights). Applications in diverse domains adopt ambient intelligence to provide ubiquitous services involving context-aware development.
Ambient Intelligence extends the boundaries of controlled architectures for supporting users, maintaining an efficient response to end-users based on available resources and services everywhere. The new generation of AmI applications is augmented with artificial intelligence, combining resources in the ambient, covering possible situations, and strengthening human interactions. A complete ambient intelligence achievement is still a research challenge; however, AmI is further considered for different domains and indoor/outdoor settings. Thus, the AmI governance is becoming an essential aspect of managing changes and system components such as available resources/services, user dynamicity, and diverse situations.
Large-scale Ambient Intelligence deployment is a continuous industrial and research effort. It can be achieved when computing systems can provide all services for continuous support, matching available resources by extracting functional characteristics from deployed applications, and running situation-aware processes in ambient components (e.g., self-governed agents) that provide and adapt environments for user support.

Review overview
This paper presents a systemic situation in AmI systems to identify common service-based features, including what type of contexts are used and whether the applications consider the service itself as a context. We also reviewed different architectures and how they manage the quality of service, governance, and security. We applied a systematic mapping process in our study by defining a categorization schema for analyzing existing research projects. The categorization supplies characteristics for an objective classification based on concepts and existing surveys. We also defined three types of service architecture styles for AmI (following the SOA model): (i) SOA-based with a central server or cloud, (ii) self-service with autonomic computing, and (iii) hybrid. Furthermore, we defined five groups related to the governance design within the architecture style (i.e., SOA-based, self-service and hybrid): (a) centralized governance, (b) centralized governance with distribution, (c) distributed governance, (d) governance including agents, and (e) governance in autonomous architectures with self-governing policies.
In this study, we have highlighted the diversity of the projects adopting SOA in AmI, from a smart house to a smart city, including the several projects that extended QoS by including the situation and user-profile to improve the service provisioning. We have also identified the challenges of AmI service systems: (a) For the service provider, it is necessary to enhance the learning and proactive support as well as delivery mechanisms to guarantee the continuity of the service provided by autonomic services; (b) For the client, it is essential to empower non-technical people to use the available pervasive services.
Furthermore, emerging technologies, such as the IoT, are enabling pervasive services. Therefore, it is necessary to correlate the categorization scheme and the characteristics of emerging technologies (e.g., self-organization of IoT devices) to produce an aggregation of attributes to evaluate the AmI systems' evolution.

ADDITIONAL INFORMATION AND DECLARATIONS Funding
This work was supported by SENESCYT, Ecuador and Université de Sherbrooke, Canada

Grant Disclosures
The following grant information was disclosed by the authors: SENESCYT, Ecuador and Université de Sherbrooke, Canada.