java messaging service

INTRODUCTION

The Java Messaging Service (JMS) is used for creating, receiving, reading and sending messages in an enterprise's messaging system. An enterprise's messaging service is a standard middleware product that is essential for intra-company communication and operations. The JMS provides access to the messaging system to various Java programs. The term messaging should not be confused with that of emails and faxes. The messages that are exchanged by the JMS are not used by humans; instead, they are created in predefined formats so that they can be used by various programs to improve their performance. The messages that are generated by the JMS are used by the enterprise applications to enhance the coordination between programs that is essential for them to keep the operations of an organisation running. It is crucial that a JMS have the required functionality to address the requirements of complex enterprise applications.

JAVA MESSAGING SERVICE

The JMS is a sophisticated enterprise product that offers various services. In general, the JMS is used for sending messages in an asynchronous manner to one or many recipients. Since, the messaging system is a peer-to-peer system each node that is connected to the network is called a client. In contrast to the synchronous messaging system, a JMS can send or receive messages without any requirements from another node. The JMS is also capable of transmitting to one or many nodes at the same time. The JMS can also decide upon the requirement for a response, the priority or the effort that needs to be taken to deliver the message. Any JMS system may use any one of two messaging styles, the point-to-point (PTP) system or the publish/subscribe system. The two styles can have two types of interfaces.

Table 1: Types of interfaces for different messaging styles

(Source: [1])

The standard interfaces are used by client programs to create different types of client programs. The object relationships that are present in a JMS system is shown in the figure below.

Fig. 1: JMS object relationships 

(Source: [1])

The connection factory is the object that is parent object that is created by the client when there is a need to create a new connection. The connection object contains any active link that will be used by the client for communicating with applications. The destination is the object to which the message will be sent, and the session represents a single thread that will be used to receive or send messages. The Message Producer or MessageConsumer are the two objects that perform the two functions that are sending or receiving messages.

ARCHITECTURES

Researcher [2] states that the service architecture is a ubiquitous platform that is used by many enterprises to ensure communication between different enterprise applications. The Enterprise Service Bus (ESB) can be used as a channel for interaction between the various applications running within an organisation. The use of JMS as opposed to other mechanisms like web services that offer interoperability advantages is that it can support a variety of infrastructure, and it can also be modified to be adapted to the standard form of communication. Information requirements in enterprises have evolved from the need to access real information in a continuous manner. Researchers [2] developed a service-oriented architecture (SOA) that they can use for a real-time JMS system for providing continuous data to clients. The latency of the system is the crucial determinant of the design. The scheduling can be done using various mechanisms like Earliest Deadline First (EDF) and the Weighted Fair Share (WFS). The use of JMS is justifiable from the point of view that JMS can be used for many J2EE applications. Thus, JMS can be used in real-time-middleware without any changes to the program code. Due to the real-time needs of the messages, two functions, namely the persisted messages and the transactions, are disabled. This enables the system to become more resource-efficient and dedicated to the task of real-time message delivery. 

Fig. 2: Real-time middleware architecture

(Source: [2])

The use of the JMS in the industry is needed for the Internet of Things architecture. TheThe researchers [3] who conducted analysis into the development of a JMS system for use in IoT application stresses the need for near real-time communication and interaction. The researchers also state that there is a need to filter information before sending it to destination nodes to protect the privacy of data. The publisher/subscriber model is used by researchers [3] to design the JMS system. The publisher/subscriber model works in a certain way; the publisher sends a message to the JMS Server, whereas the JMS Server shares the messages to one or many subscribers. 

Fig. 3: Classes of JSUtil Library

(Source: [3])

The JSUtils class is helpful for adding the function of filtering and encryption to the program. The researchers noted a significant improvement in the performance of the system is achievable by using Java rather than JavaScript.

Researchers [4] try to establish the Service Oriented Architecture (SOA) for online trading systems that require real-time data for operating. The authors propose to use gateway components to communicate via web sockets with a JavaScript web application and an API extension that mainly handles the exposure of the publisher/subscriber model of the JMS.

Fig. 4: Architecture for JS to Java gateway

(Source: [4])

The architecture shown above is necessary to expose the server-side JMS messages via an application that supports JS. The initial solution developed by researchers [4] used Java Applet. However, subsequently, the Java Web Start Technology and JS web application were deemed to be a suitable replacement to the Java Applet. 

PERFORMANCE

The performance of the JMS system is crucial for their operations in various environments. Researchers [5] were concerned with the throughput of the JMS system in large scale systems. The throughput of a JMS system is measured in terms of the number of messages that are dispatched or received by a node. In their experiment, researchers [5] visualised the architecture as a publisher-subscriber model. The publisher node publishes messages that get sent to the server where it is stored. The subscribers can access those messages or any subset of those messages from the server. 

Fig. 5: Decoupling of the subscribers and the publishers through the JMS server

(Source: [5])

The test conducted by researchers [5] was to connect 100 to 400 subscribers to the JMS server, and each subscriber /publisher was given a single thread through which the connection was established with the JMS server. The measurements were carried out with a different number of publishers, subscribers and filters. The results show that for three publishers, the maximum throughput is 14000 messages per second. For subsequent additions of publishers, the throughput remains constant at 13000 messages per second. The throughput of the system reached the maximum value of 23000 messages per second when there were forty subscribers connected to the system. 

Fig. 6: Change in throughput with the number of publishers

(Source: [5])

Fig. 7: Change in throughput with the number of subscribers

(Source: [5])

Researchers [6] use a JMS to support the requirement for exchanging messages between applications of two brokers. The two brokers use Apache ActiveMQ and Apache Apollo, respectively and the tests conducted revealed that the Apache Active MQ outperformed the Apache Apollo [6]. However, the researchers [6] also noted that there might be a change in the results of the properties of the messages being varied or the protocols for sending or receiving messages being changed. 

The researchers [7] established that the Simple Object Access Protocol (SOAP) Web Services could be used with a JMS system. In the works of the previous researcher [6], it was found that the use of web services and JMS systems can have applications in trading systems. The researchers concluded that compared to HTTP, integrating SOAP with JMS has a better influence on the performance as compared with HTTP. The reason for this was expressed by the researchers [7] to be the stateful nature of the JMS, which allows a connection to remain open once it has been established. Thus, there is less overhead when operating through a SOAP/JMS system.

Fig. 8: Response time comparison between SOAP/HTTP and SOAP/JMS system

(Source: [7])

The spikes that can be seen on the performance curves of serialised SOAP/JMS and normalised SOAP/HTTP connections can be caused by the increased CPU time for the operation of the Garbage Collection (GC).

CONCLUSION

The study reveals that the JMS is an essential component of enterprise communication. The JMS is integrable with legacy architecture and can be programmed with many different protocols. The JMS offers flexibility with multiple messaging services. The application of JMS is in asynchronous messaging, and it forms an essential component of the architecture of IoT and real-time information or data distribution systems. The two models of JMS operation that is the peer-to-peer model and the publisher-subscriber model can be sued together, although the publisher-subscriber model has better performance. Several functions can be used for modifying the messages produced by the publisher before they are sent to the JMS server. To ensure good performance, it is necessary to ensure that headers and data are trimmed as per the needs of the receiver or consumer.

REFERENCE LIST

1. M. Hapner, R. Burridge, R. Sharma, J. Finelli, and K. Stout, “Java message service,” (2002). [Accessed 06 February 2022].
2. L. Garces-Erice, “Building an enterprise service bus for real-time SOA: a messaging middleware stack,” In 2009 33rd Annual IEEE International Computer Software and Applications Conference, pp. 79-84, (2009, July).
3. C. Today, “A New Message Processing Mechanism for Internet of Things,” Journal of The Faculty of Engineering, 23(2), pp.55-66, (2018).
4. C. Vințe, TOMA Andrei, and A. Bărbulescu, “Exposing JMS-Based Trading Soa Messaging API to JS web clients,” In Proceedings of the IE 2019 International Conference, pp.67-72, (2019).
5. R. Henjes, M. Month, and C. Zepfel, “Throughput performance of java messaging services using sun java system message queue,” In Proceedings 20th European Conference on Modelling and Simulation, Bonn, Germany, pp. 684-691, (2006, May).
6. I. Kocher, “Java Message Service Based Performance Comparison of Apache ActiveMQ and Apache Apollo Brokers,” Science Journal of University of Zakho, 5(4), pp.307-312, (2017, December).

A.B. Dauda, M.S. Adam, MA Mustapha, A.M. Mabu, and S. Mustafa, “Soap serialisation effect on communication nodes and protocols,” arXiv preprint arXiv:2012.12578, pp.1-13, (2020).