Over a million developers have joined DZone.

Robo4j: Reactive Microservices-Based IoT Development

DZone 's Guide to

Robo4j: Reactive Microservices-Based IoT Development

Take a look at Robo4j, a new ecosystem specifically built for the Internet of Things to work with microservices and reactive elements of your systems in a non-blocking way.

· IoT Zone ·
Free Resource

Today, we're going to discuss the high-level perspective of the upcoming Robo4j.io framework and Internet Of Things (IoT) system design. Without further ado, let’s move forward.

Over the last few years, we've seen one the rise of microservices and the reactive manifesto, which explains how to design non-blocking, highly responsive, resilient, elastic, and message-driven parts of the application. From my perspective, all those articles have been focused on mid-size and large web applications. And most of those articles have described the best practices of splitting monolithic systems or how to employ the new trends in microservices and non-blocking design patterns.

Only a few of them have been touching on other emerging technologies focused on the Internet of Things (IoT) in the way I’ve been searching for.

Over the years, reading many of them, I got a strong feeling that the way we intend to develop IoT systems is that we take already-developed robust technologies and make them smaller. These days, we have successes. We use Spring-boot, Netty, Vert.x, or other frameworks. Those basically allow us to connect the developed system with different types of databases or analyze and react to events or data obtained from data stores.

The question remains, "Is this really enough ?"

Is this abstraction good enough that it could allow us to develop robust IoT systems? IoT systems that can react to incoming events, sort them properly, and, in special cases, forward them to the proper system parts, which could process and execute such events ?

I don’t think so, or at least, I haven't found anything like this on the market.

We can go further in questioning ourselves about the IoT possibilities, which can quite quickly turn into a discussion about artificial intelligence. In my opinion, the AI question is not relevant for this article because most of the currently available IoT systems can’t exhibit their abilities in the manner of intelligent (independent) decisions. This question is reserved for another IoT-focused article.

Let’s go back to the main topic: advanced Internet of Things system development and design. Before we start here, a small review of the definition taken from Wikipedia:

“The Internet of Things (IoT) is the internetworking of physical devices, vehicles, buildings and other items — embedded with electronics, software, sensors, actuators, and network connectivity that enable these objects to collect and exchange data.”

In other words, IoT is the term we use for objects that are connected to the Internet or other networks and can receive and process data.

The definition looks pretty cool and good so far, at least until you try to use some of those connected “smart” objects together. When that happens, you might find that your IoT system is a collection of independent units, and whether it's due to connection instability, communication protocols' message ordering, or any number of other factors, nothing works how you want it.

Although such a system has been assembled from cutting edge parts, together, they simply don’t work due to the previously touched on issues — or maybe other ones we aren't even aware of. The whole development process might turn FUZZY fast.

I normally call that type of development try, push, deploy development (TPDD), but that style might not fully satisfy the expectations or needs. There's a chance that I'm wrong, but I don't think it works in the long term.

The described situation can become really frustrating and stressful, especially when there are not a lot of possibilities on the market. You may use a Robot Operating System (ROS), but let's go back.

The lack of proper tools on the market was my main motivation to develop the Robo4j.io framework, which satisfies the following needs:

  1. Capable of synchronizing incoming asynchronous events/messages under dynamically changing conditions at “real-time.” 
  2. Allows and enforces rapid microsevices-based system development.
  3. Lightweight framework capable of running on any hardware supported by JVM. It should provide full performance on any Java-powered device.
  4. Independent, not hardware specific, and extensible.
  5. Offers control over all running units inside the Robo4j ecosystem.
  6. Enforces communication with external systems.
  7. Easy to use.

Those seven points are really challenging, and none of them are as trivial as they might seem at first. I specifically developed Robo4jo to meet those challenges.

Robo4j testing system : camera unit, ultra-sonic, gyro, color and touch sensors. Whole system contains also one  Raspberry Pi, Lego Brick and CuBox i4Pro (4-core CPU) with 500GB hard-drive as re-usable data-storage. Whole system is powered by 2x2500mAh and one 25000mAh unit.Robo4j testing system: camera unit, ultrasonic gyro, and color and touch sensors. The whole system also contains one Raspberry Pi, LEGO Brick, and CuBox i4Pro (4-core CPU) with a 500GB hard drive as reusable data storage. The whole system is powered by 2x2500mAh and one 25000mAh unit.

The framework allows you to connect and control any device that is accessible over your specific type of network (Ethernet, Wi-Fi, Bluetooth, etc.) or, of course, wired connections. And moreover, Robo4j enforces the usage of any of technology running on JVM with its natural language (Scala, Groovy, etc.).

The Architecture

Robo4j framework high-perspective architecture

Now it’s time to take a look at the basic framework architecture from a high-level perspective. The image above shows reactions among the different parts inside the Robo4j ecosystem. It’s important to see the differences between the inputs to the system.

Such input could be provided by sensors, motors (engines), or RoboSockets. The incoming messages are then processed by the system itself and serialized in the manner that the result can be executed on the connected hardware.

Inside the message process stage, the system may use different types of data stores available to a specific RoboUnit. This means that each RoboUnit may have it's own specific data resource, or they may them with others in a reactive, non-blocking manner.

The Robo4j Message Bus is not dependent on the order of how any specific message is processed. The bus consumes the messages in the order of their arrival, and the bus may dynamically change the conditions in real time. The pre-results are then moved into the MessageReactors, which, in turn, have connections to the data stores, where their results can be stored. The final result can be executed on the hardware or can involve the whole system state inside a predefined cloud.

The future of IoT (and IT as a whole) includes communication, security, different kinds of message processing, and the reactions to them. The Robo4j framework is my attempt to be part of this future.

Stay tuned.

framework ,iot ,microservices ,reactive architecture

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}