Chapter 7. Java Message Service (JMS) and Message-Driven Beans

If you've worked through all the previous chapters, you have a fully functional vertical slice of the JAW Motors application that allows you to view, add, edit (update), delete, and buy cars. JAW Motors now wants to run a credit check on potential customers to pre-qualify them for car loans as part of the auto buying process. Like many other businesses, JAW Motors doesn't do its own credit verification and uses an external online service to run a credit check. Once we add a form to the JAW Motors web site to verify someone's credit, what happens when they enter their credit information and press the submit button? Should we make them wait until the external service finishes? This process could take several minutes, hours, or even days. Making the user wait around for the final result is unacceptable. After pressing the submit button, the user should be free to go back to what they were doingviewing, adding, editing, and deleting cars. We need a way to defer the credit verification process to the background so the user can continue using the web site.

J2EE provides the following mechanisms for deferring work to the background:

• JMS (Java Message Service)

• Message-Driven Beans (MDBs)

The JMS API provides a vendor-neutral standard programming interface for creating, sending, and receiving messages. JMS enables Java applications to asynchronously exchange messages containing data and events. JMS 1.1 is part of the J2EE 1.4 standard.

Message-Driven Beans (MDBs) are EJBs that receive and process JMS messages. MDBs don't maintain state between invocations, so they resemble Stateless Session Beans. But MDBs differ from Stateless Session Beans in that:

• A client is completely decoupled from an MDBthe client sends a JMS message and the MDB picks up the message.

• After sending a JMS asynchronously, the client doesn't wait for the MDB to receive the message. The client continues executing other business logic.

Enterprise-class applications usually defer processing slow, expensive operations to run in the background so clients don't have to wait for completion. A UI sends an asynchronous JMS message, and an MDB receives the message and process it while the client can do other things in the foreground, such as interact with your application's web pages. On completion, the MDB could notify the client with a confirmation email, send another message, or update the database.

This chapter covers JMS and Message-Driven Beans. We'll upgrade the JAW Motors application by adding the ability to run a credit check on a customer by using JMS messaging and an MDB. To set realistic expectations, we won't invoke a real credit verification service, but instead will emulate the credit check as a long-running process. Along the way, we'll show how to deploy these technologies on JBoss.

Let's start by working down through the architecture.