JBoss EAP 7 and ActiveMQ Artemis as connector between temperature and humidity and the application architecture

Most IoT-Applications face similar challenges on its way from sensor to final aggregation in terms of usage and, where applicable relaying of data. In this article, we introduce an architecture based on the new Red Hat JBoss Enterprise Application Platform (JBoss EAP) in Version 7 to outline a IoT application as a showcase.

MQTT has certainly become a standard protocol for IoT and in this context the Internet of Things is integrated via MQTT.

One new major update of JBoss EAP 7 is ActiveMQ Artemis as Messaging Broker with support for MQTT as transport protocol. JBoss EAP 7 is our preferred technology, i.a. for IoT architectures because of its outstanding technological capabilities thus facilitating efficient development of scalable and secure applications.

A combined temperature and humidity sensor, the Bosch XDK, and Harting’s Mica Box are used to supply data. It is the MQTT and the JBoss EAP 7 Middleware that connect and build a bridge between this sensor setup and the rest of the world.

“Internet of Things” (IoT)

“Internet of Things” (IoT) and industry 4.0 are currently well known and frequently talked about topics. However, a standardization for applications or mature platforms are not available at present. Especially in the area of IoT, such platforms have not been established yet. In general, a key advantage of technologies in the field of IoT is the fast implementation of presentable prototypes or “nearly production ready” systems which integrate the hardware and software and which can be expanded and scaled at a later stage. These easily realized prototypes allow to obtain fast approval for new projects at management level or on customer site. This has shown to be a common issue at present.

In this article we present an architecture and technology stack by means of a sample application that can cope with the challenges of IoT applications. The chosen architecture enables both, the easy realization of presentable prototypes and the implementation of critical IoT applications which meet scaling requirements of larger systems.

The application

The sample application is built to monitor the continuous cooling perishable groceries using the Mica Box by Harting and Bosch XDK sensors. In addition, to remote monitoring of the controlled cooling and enabling remote maintenance through parametrisation, service processes are supported and optimized using this application.

Figure 1: Service application for freezer monitoring

Once the cooling chain is disrupted and/or a configurable threshold is exceeded, an alarm is triggered and a service process is initiated which generates a maintenance order. Depending on urgency, the availability of maintenance engineers, and their traveling route the maintenance order is scheduled (see figure 1).

Traditional application architectures and how IoT sneaks into the architecture

In common application architectures for classical data-centric business applications, business logic is encapsulated in a central application server. The main demand originates from the processing of data and queries, as well as change requests.

However, machine and sensor integration have a few special characteristics. For example, machines send data constantly. Machines often have low computing power and storage resources (often in the MB range or less) and communication is conducted with lower priority than the controlling of the machine. The machine and its data must not be compromised if connection is lost, load peaks occur or an application failure happens.

A tight integration and direct connection of machines or sensors with classic application architectures is therefore not appropriate and these application architectures are not suitable for IoT applications. Instead, the use of traditional pipeline / farm patterns is recommended to meet the architectural requirements in terms of scalability, throughput and reliability. The individual application components can be operated independently and are decoupled via the use of messaging services. Such a distributed approach should be used from the start, even if the application is not yet operated in a distributed manner and the load is low to begin with.

The architecture shown in Figure 2 integrates the Internet of Things, in our example, Bosch XDK temperature and humidity sensors with the MICA Box by Harting via MQTT as messaging protocol. The sensor packages publish their data via MQTT wirelessly and send them to the MICA Box, which provides a MQTT Broker. The provided sensor data are buffered by the local MQTT broker on the MICA Box and forwarded through a bridge to a cloud based MQTT broker running on a JBoss EAP 7.

Figure 2: Sensor integration via MICA Box and MQTT

Figure 3: Integration of the MICA Box

The architecture described and illustrated in Figures 2 and 3 enables the data messages on MQTT to be transmitted efficiently from the machine to the server-based application. At peak loads or server failures, data is cached locally on the broker . The integration of the sensors via connection to the MICA Box allows for higher scalability. The data is being aggregated locally on the MICA MQTT broker, and thus, the server application is relieved of certain load.

The use of MQTT ensures stable communication even in environments with unstable connectivity. The MQTT bridge between the local MQTT broker on the MICA box and the server-side broker decouples the components. With regard to the server, the JBoss Enterprise Application Platform and Java EE is applied as a standardized programming model.

MQTT protocol as a link

Message Queue Telemetry Transport (MQTT) is an open messaging protocol for machine-to-machine communication (M2M). The protocol has established itself as one of the standards for the Internet of Things. Since 2013, the standard is being specified by the Organization for the Advancement of Structured Information Standards (OASIS).

The MQTT protocol is a so-called PUBSUB protocol. Data sources publish their data to a broker, the broker publishes these data and interested audience subscribes to the broker. The broker collects data from various data sources via MQTT. The data sources, usually sensors which connect wirelessly or e.g. via USB, publish their data to the broker. This broker usually runs locally, like in the previously described scenario on a MICA Harting Box which forms a fog cloud, quasi a local cloud server.

XDK by Bosch

The XDK (Cross Domain Development Kit) is prototyping platform in a small package for the Internet of things by Bosch. The XDK consists, among other things of an ARM Cortex M3 board with Bluetooth LE, WiFi, USB, powered by a Li-Ion battery. As key features, the system has eight sensors, such as temperature, humidity, light, and acceleration, which can be read by means of an SDK. The integrated battery can be charged via USB and its duration depends on the used connection interface. The sensor package is designed to be very robust with an IP30 certification.

Built on the XDK SDK, a MQTT client was implemented, which is sending the sensor data to the broker once a second.

The Mica Box

The Harting IIC MICA (Modular Industry Computing Architecture) is a modular platform of open hardware and software that enables the caching, evaluating and processing of data obtained from machines and equipment. The MICA system is designed for harsh environments in the industry and in the rail sector – it has no fan, is resistant to dust, moisture and temperature fluctuations (certified to IP67) and is maintenance-free. Thus, it is unlikely that the box will fail in difficult IoT applications such as construction sites.

The MICA offers a Virtual Computing Industry Technology based on LXC Linux containers, so that the applications in virtual containers can run in parallel side by side. There are containers for MQTT Broker, OPC UA, Hadoop, Java and others. Even a JBOSS EAP Container can be run on the Box

A Mosquitto MQTT Broker is started as a container on the MICA Box serving as a local data aggregator and collecting data from the sensors, in particular the data of the XDKs. Mosquitto is an open source messaging broker which implements MQTT in version 3.1 and 3.1.1.

This broker automatically sends all the data it receives to all devices that subscribe to the data, among others. A second broker, running in JBoss Broker, subscribes to the data of MICA Brokers so that all sensor data which end up locally on the MICA are routed via MQTT to the server system. This pattern of two MQTT brokers, one local and one in the cloud, has a distinct advantage: In case the connection between local and cloud brokers is interrupted, the local broker will collect the data until the connection is established again (queuing), and then, sends all data to the cloud. So no data is lost, even though no permanent connection is required. This is a real advantage in some IoT application scenarios such as rural areas.

JBoss EAP 7 and ActiveMQ Artemis

The central server application is run on the JBoss Enterprise Application Platform (JBoss EAP) in version 7. JBoss EAP is the supported and quality controlled version of the popular Wildfly application server of the JBoss Community. The application server includes ActiveMQ Artemis as messaging service. Besides other protocols ActiveMQ Artemis also supports MQTT. Therefore, the communication between the two messaging services  ActiveMQ Artemis and Mosquitto is possible. The application server is fully compliant with Java EE 7. The MQTT messages can therefore be seamlessly integrated into the Java EE programming model, and can be processed using Message Driven Beans.

Summary

The Internet of Things and industry 4.0 sneak into the application architecture. The integration of machines and sensors are increasingly becoming a requirement. Insofar, some special features have to be considered in terms of architecture. Moreover, we recommend the use of standard-based middleware instead of individual implementations and proprietary solutions. Suitable open source technologies are available, particularly standardized protocols, messaging services and integration middleware.

Feel free to contact us for any questions or feedback.

miron.kropp (at) akquinet.de
heinz.wilming (at) akquinet.de