Skip to main content

Event Bus

The Event Bus is, basically, the nervous system of the Telestion Ecosystem. The ecosystem uses the Event Bus for the communication between its various components.

Video version

You can find a video version of this concept's explanation here:

Event Bus | Telestion Concepts (Video) »https://www.youtube.com/watch?v=X92A77OdEg0

Messages

At the core of the Event Bus, there are so-called Messages. Messages are data packets that you can send to a specific channel. Then, all components monitoring that channel receive you message.

Channels and Addresses

A Channel is defined by its Address (or Channel Address), which is a string (text) and essentially serves as the channel's name.

Link to

The address typically describes the channel's content (e.g., raw-telemetry, telecommand-out, etc.).

Mental model

As a mental model, you can compare the event bus to radio communication, e.g., in Air Traffic Control:

Concept in Radio CommunicationCorresponding concept in the Event Bus
Radio TransmissionMessage
FrequencyAddress

Data Pipeline

Through the combination of more than one component (Verticles on the Application side) sending each other messages and performing small, atomic tasks, you can create a sort of data pipeline that's both easier to think about (as individual components only need to perform smaller tasks) and more adjustable (since you can just plug components together in different ways):

Link to

Requests

The event bus also allows for so-called Requests.

This enables Request Messages which another component can then respond to. This is most useful when dealing with data that you don't need constantly, but only on specific occasions:

Link to

In more technical terms: Requests enable a polling-based system. This works by providing a dedicated (auto-generated) response address in the requesting message and then listening for a response on that channel.

Request Handling

In contrast to the system described in the previous sections (publish/subscribe, meaning every component monitoring a channel gets notified about every message), requests are point-to-point based. This means that of all handlers registered for the request's address, only one of them (determined by a round-robin algorithm) gets used.

Event Bus Bridge

The Event Bus Bridge enables communication between the Application and Client without the need for an extra API.

Link to

It achieves this by sharing the event bus (or at least the parts of it that you configure) via a web socket, meaning the Client can interact with the event bus as if it were a part of the Application itself.

Setting up the Event Bus Bridge in the Application

Thankfully, the Vert.x framework already provides an implementation of the Bridge, meaning all you need to do to enable it in your Application is to add the corresponding Verticle to your configuration:

conf/config.json
{
"name": "Eventbus Tcp Bridge",
"verticle": "de.wuespace.telestion.services.connection.EventbusTcpBridge",
"magnitude": 1,
"config": {
"host": "0.0.0.0",
"port": 9870,
"inboundPermitted": ["request-time"],
"outboundPermitted": ["parsed-tm"]
}
}

With that configuration, every client connecting to the Bridge on port 9870 could now send messages to request-time (and receive responses to request messages) and receive any message published to parsed-tm.

See also

Vert.x Event Bus Documentation »https://vertx.io/docs/vertx-core/java/#event_busVert.x TCP Event Bus Bridge Documentation »https://vertx.io/docs/vertx-tcp-eventbus-bridge/java/Telestion Event Bus Bridge Client API Reference »https://wuespace.github.io/telestion-client/@wuespace/vertx-event-bus/