This part presents different uses of vert.x in various contexts.
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.
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.
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)
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.
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
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.
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.
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
- Golo : dynamic language for the JVM, project hosted by the Eclipse Foundation
- PI4J: I / O Library for Rasberry Pi
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.
2nd case of use: Gateway of sensors simulation
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
- 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
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.
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.