Daily Archives: August 20, 2013

Post-Redirect-Get Pattern in Spring MVC

Do you have back button issues? Duplicate form submissions when you click back button? I think you have landed in right blog. With respect to Spring MVC, the blog even tries to give the complete solution by which to handle it.

One of the easiest way by which you can handle these issues is by implementing Post-Redirect-Get (PRG) pattern.

What is Post-Redirect-Get Pattern?

Post/Redirect/Get (PRG) is a web development design pattern that prevents duplicate form submission. When a web form is submitted to a server through an HTTP POST request, a web user that attempts to refresh the server response in certain user agents can cause the contents of the original HTTP POST request to be resubmitted, possibly causing undesired results, such as a duplicate web purchase.

To avoid this problem, PRG pattern is used, instead of returning a web page directly, the POST operation returns a redirection command. The HTTP 1.1 specification introduced the HTTP 303 response code to ensure that in this situation, the web user’s browser can safely refresh the server response without causing the initial HTTP POST request to be resubmitted.

I don’t want to re-invent the wheel, so i would just let the reader go through the Wikipedia which has explained it beautifully. Please follow the following URL:


Beautiful well constructed figures in Wikipedia will make you understand this pattern in minutes.

I hope you would now have a clear picture of PRG pattern after going through the above URL and are ready to see this implemented in your Spring MVC application as detailed below in this blog post.

I really don’t know whether this is the best approach by which Post-Redirect-Get pattern can be achieved in Spring MVC. Nevertheless i am sharing an approach below by which PRG pattern can be achieved. If this is not at all right approach, or there is another good way by which to do it, please let me know through your comments to this blog post and i promise to correct it accordingly.

In Spring MVC PRG is implemented by having two request-mappings for each page one for GET and the other for POST. The page should always be rendered using GET method and the form should always use POST method for submitting data to controller. To achieve PRG after submitting the form in the POST method of the request should send the response with redirect to the page, by doing this the page will be rendered using GET request. The following a sample code.

The flow of the above example is {GET(prgTest.html} –> {POST(prgTest.html)} –> {REDIRECT(prgTest.html)} –> {GET(prgTest.html)}

I thank my dear friend Karthikeyan Vaithilingam, for allowing me to print his R&D on this in my blog. Please follow the following link to his other blog entries:


I would also suggest reader to go through another approach as given in the below blog post and implement whichever is the best approach in your web application.


If you are using JSF or one its implementations like RichFaces as your choice of web application, to implement PRG, please blog my blog in here.

Page Visitors: 17075

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.


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: 13484