- System delineation
The HORSE Middleware enables the collaboration between the individual components, operating in the execution domains of the HORSE Framework: HORSE Exec Global and HORSE Exec Local.
Figure 1 - HORSE Middleware context and scope
The exchange of messages between the modules within a given domain is done through a broker (one per domain), while the communication beyond the domain boundaries is realized by the dispatcher (one for the entire system). A sample topology of the HORSE Middleware components is depicted on Figure 2.
Figure 2 - Topology of the HORSE Middleware
The HORSE Middleware defines a protocol for adding (registration) and removing agents. Along with the registration, the agents can provide some additional data, e.g. vendor contacts, capabilities, dependencies or constrains. The registered agents can retrieve the list of other available agents, the connection status of a given agent or its registration data.
The key functionality of the HORSE Middleware is realised by exchange of JSON-formatted payload messages. The agents send their messages to the broker. The broker forwards the registered to the recipient agents according to the value of the “recipients” field provided in the message. The usage of wildcards allows unicast, multicast and broadcast modes. The brokers can store copies of the processed messages.
In case of multiple domains, the dispatcher mediates between their brokers.
The provided release of the HORSE Middleware was intended to operate in the secure environments of HORSE labs and pilot sites. For this reason, the security aspect was left out of scope and the implementation is based on plain WebSockets protocol..
c. Operational overview
The main functions of the HORSE proposed local middleware are:
The agents establishes a WebSocket connection with the Broker, whose URL is known and stays unchanged through the entire operation time. The agent should send regular heartbeat messages in order to keep the connection alive.
- Management of the participating modules
The agent uses the established WebSocket-connection to send a registration request to the broker. The JSON-formatted control message contains the obligatory parameters (e.g. identifier of the agent) and optional data, provided by the vendor.
- Messages with payload
The HORSE Middleware provides WebSocket-based interfaces for exchange of messages bearing the desired payload. These messages have a specific structure. They bear the identifier of the sender and of the message itself. These could be used for sending responses to specific senders and (request) messages.
- External gateway functions
The HORSE Middleware can be configured to forward selected message topics to external modules and converts incoming external messages to internal ones.
- Requirements and functions
The components of the HORSE Middleware (dispatcher, broker and sample agent) are available as OSGi applications running on the OSGi Framework implementation, provided by Bosch.IO.
The broker and the dispatcher implementations can be used out of the box.
The implementations of the agent are available for all HORSE target platforms and can be easily integrated in the individual HORSE modules.
The broker offers the following console commands (“horseserver” group):
- list - Lists all current websocket IDs.
- reset - Resets the looping thread for message sending.
- change-scope - Changes the scope of the message bus.
- stop-client - Stops a client, server-side
- help – Prints the help message for the current command group or the help message of the optional parameter group name.
The dispatcher offers the following console commands (“horsedispatcher” group):
- stopexec - Stops the connection with the Local Exec server.
- restartexec - Restarts the connection with the local brokers.
- help - Prints the help message for the current command group or the help message of the optional parameter group name.
- The HORSE Middleware offers an implementation of an agent that could be used for test purposes and as example for implementation of agents for the specific HORSE modules. This sample implementation is accompanied by a set of console commands and a web UI.
- The broker offers the following console commands (“horseserver” group):
- Functional requirements
The described components of the HORSE Middleware are very small (the broker implementation is 48 kB, the other components – even smaller). The distribution is a bit bigger because it includes the libraries for the database, WebSocket server and the OSGi Framework. Hence, the system requirements for the Middleware components are basically requirements of the OSGi Framework and used libraries.
The system requirements to the target platform hosting the HORSE Broker are:
- CPU Architecture: x86, x86_64, ARM, MIPS
- CPU speed: at least 400 MH
- RAM: at least 40 M
- Storage: at least 15 MB (does not include the DB for logging the messages)
- OS: Windows, Linux, Mac OS
- Java Virtual Machines: Oracle Java SE 8,
- System description
The HORSE Middleware aims to overcome the heterogeneity in the implementations of the various HORSE components. This is realized on a messaging level. The HORSE Middleware provides an implementation of the key Middleware components (agent, broker, dispatcher) and the communication protocol.
In order a module to be part of HORSE system and collaborate with the other HORSE components, it needs to implement the agent part of the HORSE Middleware. An agent consist of business logic (realizing the specific HORSE functions) and a WebSocket client for communication with the broker as depicted on Figure 3.
The HORSE Broker implements a WebSocket Server for establishing the transport level communication with the agents (through their WebSocket clients). The business logic of the broker is responsible for parsing the incoming messaging and forwarding them according to the addressing rules. In addition, the broker manages the connections and connected agents. Upon request, it provides information on the connected agents and conducts a lookup of agents. The broker is capable of storing copies of the processed messages in a logging database.
The dispatcher is an agent of a special kind. It communicates with all brokers, dispatching the cross-domain messages. Special precautions for avoiding message loops are taken.
Figure 3 - Simplified representation of the messaging middleware components
The HORSE Middleware defines two type of messages:
- Control messages. These are used by the agents for creating or disbanding the connection with the broker.
- Payload messages. These are JSON formatted strings used for delivering the content between the agents (via the broker). The agents may make their system requests to the broker by payload messages with specific format.
- Demonstration scenarios
The HORSE Middleware is an essential part of the HORSE Framework. It is very flexible and allows various types of deployments. The simplest one features one broker and all other HORSE components on one PC. For more complex scenarios, a distributed model with several execution domains and a dispatcher as depicted on Figure 2 could be applied.
- Download information
The distribution package of the HORSE Middleware consists of the following downloadable artefacts:
- HORSE Middleware Core – OSGi Framework and generic libraries;
- HORSE Middleware Broker – An add-on to the Core, providing the Broker functionality;
- HORSE Middleware Dispatcher - An add-on to the Core, providing the Dispatcher functionality; and
- HORSE Middleware Agent - An add-on to the Core, providing the sample Agent functionality;