Keywords

1 Overview of MOM

1.1 Definition

The traditional communication mode is remote procedure call mode (RPC). In this mode (see Fig. 1), applications are highly dependent and synchronous [1]. What are the disadvantages of such a model? For example, in transaction, the order system will send messages to the logistics system and the notification system. If notification system is broken, messages to be sent to it will pile up all the time in the order system and the whole system will crash. Message-oriented middleware (MOM) can solve this problem, which is a kind of technology that uses message delivery mechanism or message queue mode for data exchange and multi system integration [2, 3].

Fig. 1.
figure 1

RPC vs MOM.

Full size image

1.2 Main Feature and Applying Patterns

The main features of MOM include the following seven aspects, asynchronous transmission, defense communication, concurrent execution, log communication, multiple communication modes, application isolation from network complexity, and flow elasticity control [4]. These typical characteristics can be seen from its two applying modes (see Fig. 2). Mode 1 can reflect the first six characteristics of middleware technology, and mode 2 can help us understand the seventh, flow elastic control. In the first two times of message flow, the time delay is relatively large, 30 ms and 300 ms. Later, middleware technology is used, and the time delay is reduced to 1 ms, which is because it is used to control network traffic.

Fig. 2.
figure 2

Applying models of MOM.

Full size image

1.3 Developments in MOM

The concept of middleware technology has a long history, but it has been widely used in the last decade. The first middleware technology is CICS developed by IBM [5], and the first distributed middleware is tuxedo [6], developed by Bell Labs in 1984. Subsequently, Some MOM products, Microsoft’ MSMQ, Apache’ ActiveMQ, appear in 2003 [7]. In 2007, RabbitMQ 1.0 [8], developed by rabbit technologies based on AMQP standard, was released. In 2010, LinkedIn developed its own messaging system Kafka [9]. The domestic middleware started later. The first product was TongLNK/Q developed by Dongfang Tong Technology Co., Ltd. in 1995. Then, some other excellent products came out successively, such as BusinessMQ in 2016, RocketMQ in 2017 [10], etc.

With the development of Internet of things, cloud computing, block-chain and other technologies [11, 12], the global MOM market has grown rapidly in recent years. According to Gartner, in 2018, the global middleware market exceeded 32 billion yuan, with a growth rate of more than 12.5%. China’s market also continues to grow, with the needs of building new infrastructure. In 2018, the domestic MOM market reached 6.5 billion, and in 2019, it reached 7.24 billion, with a growth of more than 10%. In the next few years, MOM will continue to maintain a steady growth momentum.

2 Core Technology

2.1 Communication Mode in MOM

Message middleware can store and forward messages. How does it work internally? It has three working modes: point-to-point mode, publish/subscribe mode and message queue mode [13].

Differences between the first two are obvious (see Table 1). (1) Point to Point is to maintain a logical link for two applications. After a message is consumed, it is no longer stored in the queue. (2) Publish/Subscribe is that messages are published to a specified topic, and multiple consumers can subscribe to the same messages in that topic [14]. This mode has advantages of dynamic routing, asynchronous transmission and fault tolerance, and thus become an informal standard of MOM. (3) Message queue mode is the combination of the first two. Publish/Subscribe is adopted between queues, but the queues and consumers are point-to-point corresponding. That is, messages are broadcast to multiple queues in the topic, and a subscription group consumes messages in a queue point-to-point. Message queue mode can support multiple requirements more flexibly.

Table 1. Comparison of communication modes.
Full size table

2.2 MOM Based on Message Queue

Architecture of MOM.

The MOM based on message queue mode consists of four parts (see Fig. 3), interface processing module, queue manager, message channel agent and security management [15]. Among them, the interface processing module is used to process service requests from various applications, to separate or combine data streams according to the types of requests. Queue manager is the core of MOM, which is responsible for creating and deleting queues, controlling its mode and priority. The message channel agent uses the network to provide the communication mechanism, which is responsible for delivering messages to the responsible queue, monitoring the channel failure and dealing with the failure in time. Security management mainly completes the encryption/decryption of data and provides users with secure messages.

Fig. 3.
figure 3

MOM architecture and trigger mechanism.

Full size image

Trigger Mechanism of Message.

When the application accessing middleware is in continuous running state, any arriving message can be read immediately, but this is only applicable when the message flow is stable. In most cases, the application is not active before the message arrives. In this case, the trigger mechanism of message queue needs to be set to activate the dormant application. Queue manager and Channel agent are combined to perform message triggering (see Fig. 3). (1) A message arrives at the message queue. (2) The queue manager references the environment information to determine whether the arrival of this message constitutes a trigger event. (3) The queue manager creates a trigger message and sends it to the start queue. (4) The trigger monitor reads the trigger message from the start queue and issues an activation command. (5) After the application is activated, the message is taken from the trigger queue and the corresponding operation is performed.

In order to achieve a higher level of response speed, MOM often needs to combine Redis or other caching technologies to meet specific business needs, such as the commodity Seckill system. The following is the applicable scenario analysis of various MOMs.

3 Popular MOM and Performance Comparison

At present, popular MOM products are mainly Kafka, RabbitMQ, RocketMQ, ActiveMQ. Their throughput, delay of forwarding messages and suitable application scenarios are shown in the table. Users can select appropriate middleware according to their own scenario requirements (see Table 2).

Table 2. Product features comparison.
Full size table

These MOMs basically implement models of “point-to-point” and “publish/subscribe” mentioned above, and their important differences are mainly reflected in the way consumers consume messages. Kafka is a pull model, and RabbitMQ is a push model, while RocketMQ and ActiveMQ both implement the combination of push and pull. These two consumption models have their own advantages. The push model highlights the real-time nature of messages, while the pull model is convenient for the control of consumption rhythm.

4 Existing Issues

Message middleware has become a key part of modern data-driven architecture, but under the requirements of new environment and complex scenarios, there are still some problems to be solved in the field of message communication.

  1. (1)

    There is not a set of industry standards that have nothing to do with suppliers and development languages. The internal implementation of various message middleware is not uniform and compatible with each other. In order to ensure the normal communication between message engines, users have to invest a lot of energy to deal with compatibility issues, which will cause higher access costs and maintenance costs. Therefore, the establishment of factual standards in the field of information communication has become the common appeal of developers and relevant partners.

  2. (2)

    A large number of messages are piled up in the queue, resulting in serious delay of the client. In the industrial Internet, the real-time requirement of device-level messages is very high [14,15,16]. When one device fails and can’t accept messages, the queue will pile up a large number of messages, and other devices can’t get response in time.

5 Application of MOM in IoT

As mentioned in Sect. 4, an existing issue is that if MOM is piled up with large number of messages, serious time delay may occurs in IoT device. This section designed a IoT message system to this problem.

5.1 Architecture of IoT Message System

The Internet of things (IoT) message system is composed of IoT device nodes and message gateways. Distributed deployment is adopted in the local area network, and data communication is carried out between nodes through messages. The system architecture is shown in Fig. 4. After the IoT node collects the environment data, it encapsulates the data into message format and sends the message to the gateway through the client program. The core of the gateway is the ActiveMQ server. With it, the gateway can accept data from nodes. After cleaning, analyzing and filtering the data format, it transmits the data to the cloud server through MQTT protocol. In theory, a device node can publish messages to multiple topics of the middleware server, and multiple nodes can also publish messages to the same topic. In order to avoid the problem of mutual influence between devices caused by message accumulation in gateways, this system adopts the design of device-level topics.

Fig. 4.
figure 4

Architecture of IoT system.

Full size image

5.2 Main System Functions

Device Connection.

The IoT device consists of mini PC Raspberry Pi and intelligent temperature sensor DS18B20. Using the metal pins on the development board, the sensor can be plugged into the mini PC. After the hardware is connected, run the Linux operating system on the PC, and then install the software stomp.py. This software provides functions based on simple text protocol, which can encapsulate the data collected by the sensor into formatted messages. The hardware used for the gateway can also be the Raspberry Pi, which also runs the Linux, on which the message server ActiveMQ is installed. Sensor nodes establish network connection with gateway through WiFi, and gateway connects with remote cloud computing platform through Internet service.

Function Design.

This architecture uses ActiveMQ to design device-level message queue to store and forward device related messages (see Fig. 5). Several topics are set in the gateway server. One topic receives the temperature data of a sensor node. The data acquisition program on the device is developed in Python to obtain the temperature data of the environment. Then methods of the STOMP library are called to perform format conversion, encapsulate the data into message format and send it to the message queue of the gateway. As the client of ActiveMQ server, the remote cloud computing service center obtains data from multiple gateways. After data aggregation, the cloud center obtains some decisions by analyzing these data. According to the decision, the center sends backs messages to manage the devices, and in turn adjusts the operation status of those IoT devices.

Fig. 5.
figure 5

Functional flows.

Full size image

6 Conclusion

This paper introduces technology of MOM and its application in the IoT. Users can have a comprehensive understanding of it according to these introductions, and select appropriate middleware products to build their own message system. The future research direction mainly includes three aspects. (1) How to combine the new distributed communication standard with MOM? In distributed service architecture, there are many application-level protocols. MOM should support the function of multi-protocol communication, and need to improve this function module constantly. (2) How to be compatible with multiple middleware solutions of different communication modes? The compatibility of multiple middleware can make them give full play to their maximum performance in 5G big data, IoT and other new environments. (3) How to combine middleware with block-chain? In the collaborative process of multi system, a lot of data needs to be saved in several systems. This is in line with the idea of decentralization in block-chain. So, applying block-chain to secure middleware system is bound to become a trend.