Architecting the Internet of Things
Learn about a new open solution for IoT that includes components and development tools for all layers of IoT Architecture.
Join the DZone community and get the full member experience.Join For Free
We would like to introduce you to a few projects that allow you to architect and master the Internet of Things completely.
Few weeks ago we presented our vision of the IoT Architecture based on microservices at a Czech based Linux conference, OpenAlt. Our goal was to cover all the implementation layers and put the puzzle together. In other words, to demonstrate the complete solution for IoT, starting with the very data inputs gathered by edge devices through data integration up to analytics.
The following architecture diagram depicts the high level overview of our vision. You can surely identify so-called edge devices connected to an IoT Gateway.
Typically, the Gateway translates any possible hardware and vendor specific protocols from the devices to something unified and easier usable at the integration level. Like TCP and any standardized messaging protocol on top of it.
Is there always only a single Gateway? And does the Gateway just consume hardware specific protocols? The answer to both of these questions is no. There might be multiple Gateways of various type, at different locations, some even consuming TCP protocols if you have really smart edge devices. The more important thing is the logical function of the Gateway as a data aggregator, possibly a simple router and a message translator.
Then you can see the Integration component. This is where the core business logic is located. The architecture resembles good old SOA (Service Oriented Architecture). And SOA principles can and should be used here!
Later the Integration component can communicate with a complex system like JBoss Business Process Management System. Decision making and advanced data analysis is done here.
Well, what is the difference between the Gateway and the Integration component precisely? We have mentioned the difference in its philosophy. But is there actually any other difference in how they are implemented?
There are multiple dimensions of abstraction that can differentiate the meaning of particular microservice.
Among these dimensions are data protocols (low level hardware protocols, simple messaging, TCP...), service layers (as known from good old SOA architectures) and computing power needed for particular service.
And this is it. The purpose of a microservice and its specification is specified by developers during the creation of the system. We could say that microservices are an analogy to stem cells. The microservices (as well as stem cells) specialize depending on where and how they are used.
What makes us believe that our solution is "the right" one?
First, we hope to cover all levels of abstraction. We have components and development tools for all layers of IoT Architecture. Connecting some sensors with an Arduino is fun but what is next? How do you put it together to be able to store big data and perform analytics? We can do that.
Second, we are open and we rely on existing standards. We just help to integrate existing solutions. There is no need to learn something completely new. Anybody understanding the individual building blocks can immediately start developing a complex system. As a part of that, we try to avoid vendor lock-in. All related components, systems, devices, anything, can be easily switched for another implementation.
Third, we aim to be minimalistic, the complex system can be built from simple services that are easy to understand. These services can run on ARM based devices and small virtual machines in a cloud. More power can be added by starting more service instances, so we can scale easily.
Our solution consists of three ingredients.
The Bulldog library to control and communicate with edge devices. This library provides a level of abstraction to allow the developers change the edge devices and ARM boards without the need to rewrite their code.
To transform the data to a meaningful protocols, we provide Silverspoon which is a set of Apache Camel components. These provide the Gateway between the device specific protols and the outer world. We believe that Apache Camel is a perfect fit for IoT gateways due to it's routing, extensibility and integration and messaging capabilities. For this reason we implemented a Bulldog component for Apache Camel
To develop the gateway, integration and business logic, we created SilverWare - a minimalistic microservices platform. The microservices can be created as Apache Camel routes, CDI components, messaging queues/topics, Vert.x verticles and many more (some of these yet to be implemented). So any of these building blocks that might already exist in your organization can easily be transformed or directly deployed as microservices. We also benefit from simple Maven project dependencies, a few easily understandable annotations, small executable jar file, and the ability to create Docker images with your deployments.
Also, a complete system definitely deserves advanced business logic in the form of business processes and rules. For this purpose an integration with JBoss Business Process Management System is possible. In the next article, we will show you all of this on a real example.
For now, we can just show you the application structure and provide a link to the preliminary source code ;-)
We are really curious about your input and opinions on our vision, so your comments are highly appreciated.
Opinions expressed by DZone contributors are their own.