Event Bus
Please note that the application and development of backend services using Vert.x in Telestion are deprecated. In the future, Telestion backend services will be developed using TypeScript and Deno, or through custom integrations with other languages.
While there may be a compatibility layer for Vert.x services in the future, its availability is not guaranteed.
For developing backend services, please refer to the (Work-in-Progress) documentation available here: https://pklaschka.github.io/telestion-docs-new/. Once the documentation is complete, it will be moved to the main Telestion documentation.
Additional Information:
- NATS will be used as the distributed message bus/message broker for Telestion.
- NATS' integrated authentication and authorization features will handle authentication and authorization for Ground Station operators, providing a single source of truth.
- The event bus bridge will no longer be featured, and clients will be directly connected to the NATS server.
To establish a more technology-independent terminology, the Telestion project will modify the naming conventions as follows:
- The NATS server will be referred to as the message broker, message bus, or NATS server interchangeably.
- Components that act as services without an attached user interface, will be referred to as services or backend services collectively.
- Components that provide a user interface, formerly known as "clients," will be referred to as frontends. In most cases, the frontend will authenticate to the message broker as the user, while backend services will act on their own behalf.
These changes aim to provide clearer and more consistent terminology, accounting for the possibility of components having both service and frontend functionalities. Additionally, the use of "client" for frontends will be replaced to avoid potential confusion.
We recommend using the NATS client libraries recommended by NATS itself, unless there are no suitable options available for the targeted language/environment. We will not develop our own client libraries unless there is a lack of suitable options or significant advantages justify the effort.
While Deno/TypeScript is the recommended choice for backend services, its use is not mandatory. Developers will be encouraged to use Deno/TypeScript where appropriate, but other options will still be supported for specific services. Comprehensive documentation and resources will be provided for writing and deploying Deno-based backend services in TypeScript.
Please consider these changes and updates as you continue with Telestion development.
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=X92A77OdEg0Messages
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.
The address typically describes the channel's content (e.g., raw-telemetry,
telecommand-out, etc.).
As a mental model, you can compare the event bus to radio communication, e.g., in Air Traffic Control:
| Concept in Radio Communication | Corresponding concept in the Event Bus |
|---|---|
| Radio Transmission | Message |
| Frequency | Address |
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):
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:
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.
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.
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:
{
"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.