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

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, 2010). 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 FASEM – an 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. Smirnov, Levashova & Shilov (2011), with several authors (Smirnov & Levashova, 2009; Smirnov et al., 2010, 2011), 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 component – context broker – integrates 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.

Fysarakis et al. (2018) presented XSACd—a smart environment framework for policy-based sharing and device services access. It adopts the eXtensible Access control Markup Language (XACML) to represent policies and the Device Profile for WS (DPWS) to specify resources as services. The architecture comprises five entities: Policy Enforcement Point (PEP), Policy Decision Point (PDP), Policy Administration Point (PAP) and Policy Information Point (PIP), Cross-domain Proxy (CP), and Broker. 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 (context-aware), 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 (Familiar et al., 2012)), 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 SYLPH – the 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 multi-agent 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 (Abdulrazak et al., 2011; Roy, Abdulrazak & Belala, 2011) 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.

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 (Abdulrazak et al., 2011) 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., 2010b, 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⁴ . 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.