Design Decisions from Consolidation - universAAL/middleware GitHub Wiki
The development of the middleware building blocks is based on one existing implementation of middleware functionality in the input projects. Decisions regarding the input project to be used are grounded on the description and desired functionality of the middleware, according to the middleware expert group description. Additionally, the selected project should have a modular structure, as this makes the exchange of middleware components easier in case some special middleware functionality has been implemented with more advantages in another input project. To be able to extend the range of devices that can be integrated into uAAL, different protocols for Discovery & Peering needed to be used. A Bridging mechanism over specific protocols will give the ability to some of the nodes to support multiple communication protocols with several separated ensembles of nodes into one integrated ensemble.
In this section, a going through the input projects from the Middleware point of view is presented. The Middleware in each one of the input projects have been developed in the following way:
Amigo, The Base Middleware contains the functionality that is needed to facilitate a networked environment. It provides the semantics to communicate and discover available services and devices in the network, including the ones that are based on existing communication and discovery standards, such as UPNP, WS, or SLP. This implies that independence is accomplished for existing hardware- and software, and new services can be discovered and composed. In addition, security mechanisms for authentication, authorisation, and encryption are provided. Amigo project develops middleware that dynamically integrates heterogeneous systems to achieve interoperability between services and devices. The role of the interoperable service discovery & interaction (SD&I) middleware is to identify the discovery and interaction middleware protocols that execute on the network and to translate the incoming/outgoing messages of one protocol into messages of another, target protocol. The system parses the incoming/outgoing message and, after having interpreted the semantics of the message, it generates a list of semantic events and uses this list to reconstruct a message for the target protocol, matching the semantics of the original message. The interoperable SD&I middleware acts in a transparent way with regard to discovery and interaction middleware protocols and with regard to services running on top of them. The supported service discovery protocols are UPnP, SLP and WS-Discovery, while the supported service interaction protocols are SOAP and RMI.
The MPOWER middleware consists of five categories of services: Sensor services, Contextual services, Information (Medical and Social) services, Security services, and Interoperability services. QoS layer includes security. The objective of the MPOWER security middleware is to ensure sufficient protection for any of the MPOWER enabled services when they are used. This implies that security middleware is orthogonal to the other services in a way that it is an implicit part of each service, ensuring a satisfactory security level of any combination of services in the MPOWER platform. The MPOWER Middleware holds reusable and compiled (runnable) services and components that can be easily utilized by application developers.
OASIS includes all following middleware elements and components:
- AMI Framework. The Ambient intelligence framework that provides seamless interactivity between OASIS services, applications and the hyper-ontology. It is comprised of the multi-agent platform (Middleware Layer).
- Common Ontological Framework (COF). The COF defines a formal specification of ontology modules, and how they relate. The COF defines a methodology and best practice for ontology construction. It makes possible to define a hyper-ontology and also facilitates the integration of new emerging ontologies (Middleware Layer).
- Content Anchoring and Alignment Tool (CAAT). This tool aligns the functionality of the provided WS to the ontologies stored in the Ontology Repository. The concepts of the same or different application areas, after being aligned with other ontological concepts, will be able to anchor in the hyper ontology framework, thus being ready to be used seamlessly through the CCM (Support Application Layer).
- Content Connector Module (CCM). The role of the CCM is twofold: it supports automatic integration of WS and devices, which takes place when new service providers or hardware developers are willing to register their assets in OASIS, and it receives a request for service by the end-user (client) application via the AmI and invokes the appropriate service that returns the required content to the client (Middleware Layer).
SOPRANO Middleware main feature is that it provides decoupling, enables independent contribution and provides central platform services. SAM collects incoming sensor information, analyses them (in the Context Manager), decides with the help of a procedure database which actions in form of workflows to be taken (in the Procedural Manager) and executes them through different actuators in the house (in the Composer). An OSGi service middleware provides the technical basis for this system part. All local services in the house as well as external services are registered in its central service registry
It is possible to obtain a middleware which incorporates the best solutions among all input projects. The following figure illustrate the notion of the Middleware in PERSONA.
The integration of components from all the other layers into the system is done through the visible interfaces of the middleware that are the PERSONA buses. In PERSONA, middleware also provides a level of security mechanisms that ensure that components are allowed to call other components’ services. PERSONA middleware also ensures that communications between nodes are encrypted.
The following table provides a list of the concepts taken from PERSONA Middleware:
| Concept | Description |
|---|---|
| Distributed realization of the middleware | In self-organizing systems, the realization of the middleware in a distributed way simplifies the physical architecture of the system just as an ensemble of networked nodes in which each instance of the middleware represents a node in the system. Seamless connectivity will become an issue to be solved at the level of middleware instances, i.e. it will be sufficient when middleware instances are able to discover each other and form the ensemble in this way. |
| Sodapop Model | SODAPOP (Self-Organizing Data-flow Architectures suPporting Onotology-based problem decomPosition) is a conceptual model based on which the distributed middleware solution of PERSONA has been realized. It facilitates the secure communication between the peers and providing a modular view on connecting to an ensemble based on the concept of a Bus hence supporting a coars-grained level of self-organization |
| Abstract Connection Layer | the PERSONA ACL is supposed to hide the details of discovering instances of the PERSONA middleware as peers and handle the low-levels of exchanging messages between the peers. Only middleware instances that share the same ACL implementation can discover each other and communicate, but an instance that uses two ACL implementations can make the peers from one technology visible to the others and vice versa if it also runs this bundle |
| Input bus | An event-based bus for sharing explicit input provided by a human user. |
| Output bus | An event-based bus for handing over info prepared for being presented to (a) certain human user(s). This brokerage is supposed to be done in a personalized and context-aware way so that the info is eventually presented to the user using output channels that are most appropriate for the current situation of the addressed user and are the best match for his / her possible impairments, capabilities and preferences. |
| Context bus | An event-based bus providing a general-purpose push mechanism that can be used if the info to be shared is neither addressing a human user nor the representation of captured user input. It is called the context bus, because it is used for the exchange of sharable info about changes in the system and its environment, and for an interested subscriber the event has happened in the context of its run-time environment. |
| Service bus | A call-based bus providing a general-purpose pull mechanism that can be used for utilizing accessible functionality. As explained earlier, “service” can be used as a general abstract term for talking about accessible functionality that can be utilized in the virtual realm using pull mechanisms. The bus API, communication protocol, and strategy altogether realize a brokering mechanism that is providing for goal-based interoperability. Obviously, the most important of message types exchanged on the service bus correspond to service requests, service calls (forwarding a request to matching callees), and service responses. |
After considering the description of middleware and the design decisions, the middleware expert group concluded that the PERSONA project will best fit as the starting point for the development of the middleware for the universAAL reference implementation. This means, that the software components corresponding to the middleware in PERSONA are taken and improved by solutions coming from other input projects. The result is a new middleware that exploits the PERSONA features. There are 2 main improvements with respect to the PERSONA architecture:
- The AAL-aware nodes join to a distributed environment named uSpace
- tHE middleware is a modular architecture designed in order to add or remove functionalities.
The middleware implements the concept of uSpace. An uSpace is a Smart Environment composed by a set of AAL-aware nodes that share a data structure named uSpace Card. The Space Card is a collection of meta-infos about:
- uSpace unique ID
- uSpace human descritpion
- uSpace communication channels
The peers of an uSpace play a role. The middleware defines the following key-roles:
- Coordinator: peer responsible for creating and managing the uSpace. The Coordinator browses the network in order to detect already existing uSpaces, if no other uSpace with the same uSpace Card are found, than the Coordinator creates and announces a new uSpace. The Coordinator is also responsible for authorizing or denying the peers that aim at joining an uSpace.
- Deploy Manager: peer responsible for orchestrating the installation or un-installation of AAL Service inside the uSpace (See Container Building Block). An AAL Service can be composed by multiple parts that can be installed in different peers of the uSpace, Deploy Coordinator sends a deploy message to every peer that must install an application part.
- Peer: a regular AAL-aware node that joins to an uSpace.
The previous figure shows 2 uSpaces that are built on top of Ethernet-based LAN. Some peers join to the Airport Check-in uSpace, other ones join to the Entertainement uSpace.
The Peers that are part of the same uSpace can interact and provide the AAL Services installed by the end-users or by a deployer.
An AAL-aware node (or Peer) is a network-enabled host equipped with the middleware. The next figure shows the middleware stack.
The middleware is composed by different layers implemented as a set of OSGi bundle. The middleware has been designed with Apache Karaf http://karaf.apache.org/ (an enhanced version of Apache Felix) in mind, this because Karaf provides some advanced features that can exploited in order to improve the use-cases planned in the universAAL project. However it is possible to run the middleware also with a regular OSGi environment such as Apache Felix. The architecture of middleware is shown in the next figure.
The architecture is split in different layers.
Connector Layer
This layer provides a plugable mechanism in order to enable the following features:
- Discovery: this connector allows to announce and discover resources required by the peers
- Communication: this connector provides communication capabilities among peers
- Deploy: this connector allows to install or un-install components in the peers
- SLP for the Discovery Connector
- jGroups for Communication Connector
- Karaf Provisioning System for the Deploy Connector.
The Module Layer is designed in order to detach the connectors from the rest of the architecture by providing a connector-independent set of APIs. The middleware implements a specific module for the discovery, deploy and communication capabilities.
Bus Layer
The Bus Layer is inherit from the PERSONA architecture. The middleware adds the Control Broker (a special bus) for interacting the upper layer (Manager Layer). The rest of the busses have been integrated into this new version of the MW.
Manager Layer
The Manager Layer is composed by specific managers that control the MW.20 behavior. Currently the middleware implements 2 managers:
- uSpace Manager: this component manages the interaction with the uSpace. The uSpace Manager of the COORDINATOR will create and advertise the uSpace, while the uSpace Manager of a Peer will discover and join to an existing uSpace. The uSpace Manager provides some useful information about the uSpace to the upper later (application layer) such as:
- The uSpace Card
- The Peers that have been discovered
- The ID of the COORDINATOR or the ID of the Deploy COORDINATOR
- Useful events about the uSpace (new Peer found, Peer lost, etc)
- Deploy Manager: this component implement the business logic for installing, un-installing or delegating the installation of an AAL Service into the uSpace.
The Application Layer exploits the Manager and Module Layers in order to get information about the uSpaces and to communicate with other peers of the same uSpace.
Using a top-down modelling approach, the middleware in the concrete architecture was separated into four building blocks. These sections provides a mapping from those building blocks to the middleware stack:
- Communication
- Control Broker
- Data representation
- data is represented as RDF/OWL
- Discovery & Peering
- discovery: uSpaceManager, uSpaceModule, DiscoveryConnector
- peering: CommunicationModule, CommunicationConnector
- Container
- DeployManager, DeployModule, DeployConnector
Security in terms of encryption of network messages is the responsibility of the indiviual communication connector.