Spring Book – Chapter 17 – Messaging with Spring

Messaging is a method of communication between software components or applications. Messaging enables distributed communication that is “loosely coupled” (decoupled). A component sends a message to a destination, and the recipient can retrieve the message from the destination. The important thing here is that, the sender and the receiver do not have to be available at the same time in order to communicate with each other.

Java Message Service (JMS) defines a standard way for Java applications to create and exchange messages through a Message Oriented Middleware (MOM).

Messaging is one of the key components in any modern day application development. In this Chapter we will initially cover messaging concepts in some detail. Later on we will cover JMS and its components in detail. We will then deep-dive into the support provided by Spring in applying messaging to your application. We will then go through the transaction support by JMS and again what Spring has to offer in this space. Finally, the Chapter concludes with a discussion of Spring’s support in achieving global transactions in your application.

Messaging in General

Messaging systems are used to build highly reliable, scalable, and flexible distributed applications. A messaging system allows separate, uncoupled applications to reliably do the communication asynchronously. The messaging system architecture generally replaces the client/server model with a peer-to-peer relationship between individual components, where each peer can send and receive messages to and from other peers.

Messaging systems provide a host of powerful advantages over other, more conventional distributed computing models. Primarily, they encourage “loose coupling” between message consumers and message producers. Other advantages of messaging systems include high scalability, easy integration with other heterogeneous networks, and reliability due to lack of a single point of failure.

Messaging is another integration style as detailed in Chapter 6.  Systems exchange messages within each other using a component known  as a broker, which provides the necessary guarantee and services while using messaging along with capability of interfacing with other interfaces like JMS driver, AMQP (Advanced Message Queuing Protocol), Stomp (Simple Text Oriented Message Protocol), XMPP (Extensible Messaging and Presence Protocol) etc. These interfaces are often referred to as Message Oriented Middleware (MOM) and are available as commercial and open source products in the market. Figure 18-1 shows a diagram of a MOM-based messaging system.

fig18-01

Figure 18-1. Messaging using MOM

Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems. MOM allows application modules to be distributed over heterogeneous platforms and reduces the complexity of developing applications that span multiple operating systems and network protocols, such as the following:

  • Simple (or Streaming) Text Orientated Messaging Protocol (STOMP) provides an interoperable wire format so that STOMP clients can communicate with any STOMP message broker to provide easy and widespread messaging interoperability among many languages, platforms and brokers.
  • Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for message-oriented middleware. It’s a binary, application layer protocol, designed to efficiently support a wide variety of messaging applications and communication patterns.
  • Extensible Messaging and Presence Protocol (XMPP) is an open-standard communications protocol for message-oriented middleware based on XML (Extensible Markup Language). The protocol was originally named Jabber, and was developed by the Jabber open-source community.

Advantages of Messaging

The main advantages of using messaging as an integration technology in your application can be summarized as below:

  • Platform Independence – one of the biggest advantages which messaging integration style brings onto table is communication and integration of heterogeneous platforms. Using messaging it is possible to integrate applications and systems which are implemented in completely different platforms. Even though we have many ways of integrating heterogeneous platforms like RPC-based, common database etc., only messaging truly provides a decoupled way of interaction between such disparate systems.
  • Network location Independence -messaging also provides capability of connections applications and systems in completely different networks with ease.
  • Architecture Flexibility and Agility – this very important advantage of messaging is achieved through level of abstraction and decoupling capabilities. Because of decoupled components, these can be replaced with a more capable component at a later stage with ease giving application flexibility and agility to changing business scenarios. In a typical messaging environment, the various components like producers, consumers and client components doesn’t need to know which programming language or platform these are written for, where they are located and even the protocol they used to communicate. These details are all abstracted away, making it more flexible from the architecture point of view.
  • Reduce system bottleneck – asynchronous nature of messaging is the key in avoiding system bottlenecks. Since messaging architecture gives your application asynchronous nature, your receivers need not keep up with the rate of requests coming in reducing the system bottlenecks. In a synchronous environment, your application would have resulted in system bottlenecks if the number of requests exceeds a particular amount which the consumer can consume and process.

Using traditional RPC-based technologies, there is a synchronous communication between a client and a server component. Also, communication between many to many can over a period of time turn into a mesh of one to one communication between various components as shown in Figure 18-2 below. This meshing can be troublesome from the application maintainability point of view.

Figure 18-2. Traditional RPC-based application component interaction

Figure 18-2. Traditional RPC-based application component interaction

On the other hand using a messaging style of integration allows adding a mediation layer between one or more consumers and one or more producers. This result in clear communication between various components which has a clear interface with other components interacts, making it easy to swap the various components according to application requirement. Figure 18-3 shows message-based component interaction.

Figure 18-3. Using messaging-based application component interaction

Figure 18-3. Using messaging-based application component interaction

Page Visitors: 6419

The following two tabs change content below.

Tomcy John

Blogger & Author at javacodebook
He is an Enterprise Java Specialist holding a degree in Engineering (B-Tech) with over 10 years of experience in several industries. He's currently the Senior Technical Engineer at Emirates Group IT since 2005. Prior to this he has worked with Oracle Corporation and Ernst & Young. His main specialization is on various web technologies and acts as chief mentor and Principal Architect to facilitate incorporating Spring as Corporate Standard in the organization.

Latest posts by Tomcy John (see all)

One thought on “Spring Book – Chapter 17 – Messaging with Spring

  1. First of all I would like to say fantastic blog! I had a quick question which I’d like to ask if you don’t mind. I was interested to know how you center yourself and clear your head before writing. I have had difficulty clearing my mind in getting my ideas out there. I do enjoy writing but it just seems like the first 10 to 15 minutes are usually wasted just trying to figure out how to begin. Any recommendations or tips? Thank you!|

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">