logo le blog invivoo blanc

4 concrete examples of Vert.x

27 August 2019 | Java | 0 comments

This part presents different uses of vert.x in various contexts.

Boiler Vroom

This demo presented by Julien Ponge is a Vert.x application designed around the Traktor audio mixing software. This application uses Vert.x to allow users to interact with the Traktor software through a web interface allowing them to send mix signals to Traktor and stream audio mixed on Traktor. This is a good illustration of Vert.x’s routing capability through the event bus.

The code of the application is available on GitHub: https://github.com/jponge/boiler-vroom

Tools and components

The system based on the tools and components of Figure 5.1.

vert.x 1
Figure 5.1 : Boiler Vroom Tools and Components
vert.x
Figure 5.2 : Traktor Interface
Figure 5.3 : Boiler Vroom Interface

Streaming functions

The Boiler Vroom interface allows the user to stream the result of the mix sent by Traktor. This shipment is however not done directly, as can be seen in Figure 5.4.

Figure 5.4 : Streaming Process

Tracktor is configured to broadcast an Ogg Vorbis encoded sound (Traktor’s only output format) to an IceCast server in a first hand (Figure 5.5). Ogg Vorbis format support is not widespread; we wanted to convert it to MP3, which is a widely supported format.

The VLC application is used to convert the IceCast output stream to an exposed stream on an HTTP server. Boiler Vroom then listens to the stream broadcast through VLC and publishes it continuously on the Vert.x event bus. When a Boiler Vroom client (web) activates the streaming button, the Boiler Vroom server sends the streaming switch to the client through HTTP and retrieves it from the Vert.x event bus. (Figure 4.4)

Figure 5.5 : Streaming the Traktor Stream to an IceCast Server

Interactive mixing operation

Boiler Vroom also allows users to interact with the application-related instance of Traktor by mixing through the sending of MIDI audio signals. Again, this is through the event bus Vert.x where customers (web) send typed messages depending on the type of MIDI signal needing to be transmitted to Traktor.

A Boiler Vroom component with access to the input and output traktor MIDI interfaces will consume client messages by interpreting them correctly and sending them as MIDI signals to Traktor through the Web MIDI protocol (Figure 5.6).

Traktor then integrates MIDI signals as they are received and applies them to the current mix. The resulting sound is broadcast continuously to IceCast. Converted to MP3 with VLC and broadcast on the event bus to be sent to users who have activated streaming, as we have just seen.

But Boiler Vroom does not just send MIDI signals to Traktor. It also listens on Traktor’s MIDI port for the signals it sends (figure 4.6). These received signals are also interpreted and broadcast on the event bus Vert.x in a message format which customers will understand (web). Boiler Vroom customers who listen on the event bus will interpret these messages. Therefore updating the positions of their mixing graphics controls to sync and reflect the current mix status on Traktor.

Figure 5.6 : Mixing interactive

Boiler Vroom source code

The source code of Boiler Vroom is available on GitHub: https://github.com/jponge/boiler-vroom

Socks and sockjs event bus bridge

We have not specified it, but it is interesting to know that it is thanks to the SockJS bridge based on the SockJs library that the event bus can be extended to web clients. SockJS is a JavaScript library that adapts accordingly to it’s environment to provide a WebSocket type of communication interface. In addition to the JavaScript client library, there are several server implementations that are compatible with this client, such as the one provided in Vert.x., or for Node.js, Erlang, etc.

Demo 2. The vert.x TCP event bus bridge

The second demo presented by Sébastien Blanc deals with the TCP bridge of the event bus in Java, which, like the SockJS bridge, makes it possible to extend the event bus to nodes outside the Vert.x cluster. Sébastien’s effort was to build an API similar to the event bus above the TCP bridge protocol. His work is available on his GitHub: https://github.com/sebastienblanc/vertx-java-tcp-eventbus-bridge.

Otherwise functionally, the demo consists of interacting with a robot running Linux, through the TCP bridge, from a classic Java program or an Android client. He also added to this system a raspberrypi through the TCP bridge to turn on an LED.

Figure 5.7 : TCP bridge architectural build-up

Demo 3. “Enterprise” context

This use case is presented by Raphaël Luta who discusses the use of Vert.x as part of one of his projects to expose through REST services or broadcast with SSE data produced at the end of a chain of data transformation. Their choice is Vert.x for two or three reasons:

  • Used in a streaming channel, Vert.x has practical APIs to manage the problems inherent to this exchange mode (essentially back-pressure) ;
  • The possibility of developing Distributed services through the event bus ;
  • The ability to deploy them in the same JVM when there are no specific constraints.
Figure 5.8 : Vert.x usage for streaming and API REST

Demo 4. Green.x, polyglot + IOT

In this last demo, Philippe Charrière presents three usage cases of Vert.x in an IOT context with the Golo and Scala implementations of the library.

1st Usage case: Led flashing

Demo Tools

  • Golo : dynamic language for the JVM, project hosted by the Eclipse Foundation
  • PI4J: I / O Library for Rasberry Pi
  • Vert.x

This demo consists of flashing LEDs connected to a Raspberry Pi from a web client. The web server written with the Golo implementation of Vert.x is deployed on the Raspberry Pi. And it interprets requests to blink LEDs through the PI4J library.

vert.x
Figure 5.9 : LED Flashing

2nd case of use: Gateway of sensors simulation

Demo Tools

  • Scala
  • Vert.x

The demo consists of simulating an IoT gateway for a set of domestic temperature sensors. Written in Scala with its Vert.x implementation, the demo consists of simulating sensors with functions that randomly generate temperatures, and exposing these functions in REST services written in Vert.x.

3rd case of use: simulation of a Gateway of sensors with use of MQTT

Demo Tools

  • Scala
  • Vert.x
  • Message Queuing Telemetry Transport (MQTT) is a publish/subscribe type of communication protocol adapted to the world of IoT. The implementations used for this demo are:
    • Vert.x MQTT: as MQTT broker
    • Eclipse Paho: as MQTT client in Java
    • MQTT.js: MQTT client for JavaScriptMessage Queuing Telemetry Transport (MQTT) is a publish/subscribe type of communication protocol adapted to the world of IoT. The implementations used for this demo are:

The demo again consists of simulating a temperature sensor gateway. But this time by connecting the sensors to an MQTT broker, to which they will publish the temperatures.

vert.x
Figure 5.10 : MQTT Clients communication through the MQTT broker

In this demo, the sensors are once again simulated by Scala objects, producing random temperature values. MQTT customers using Paho continually publish these random temperatures to the Vert.X MQTT -based MQTT broker.

Figure 5.11 : Publication and consumption of data through the MQTT broker

MQTT.js is an MQTT client in JavaScript that can be used in Node.js or in the browser. Even if the speaker will admit that he has not managed to make it work in a browser. He used it instead in server-side Node.js. This is to recover the temperatures published by the sensors, making them available to the web client, which illustrates their evolutions with curves.