Message-driven EJB (i) JMS and EJB

This article mainly from two aspects to tell:

1. Why Use MDB

2. Design principles for using MDB

Let's take a look at how the messages are communicated.

One component of the application sends a JMS message for the specified message purpose, and another component of the application reads the message from the message destination and resolves the contents of the message. This enables communication between the two components.

1. The party sending the message, called the message producer

2, the party receiving the message, called the message consumer

The result of the JMS specification is that the message producer and the message consumer do not need to be directly coupled or even know the other person's presence.

(i) JMS and EJB

1. Message Producers

To achieve a single function, simply obtain a JMS session for the purpose of the message, and then send the message to the specified message destination through a JMS session. By any Java EE component, both Web Components and EJB components are available.

2. Message Consumers

If the consumer is synchronized , the message consumer cannot read the message from the message's destination, causing the current thread to be blocked and cannot be executed down. So the use of asynchronous consumers is mostly.

asynchronous consumers (mostly), you need to listen to the message for the purpose, when the JMS message is served the purpose of the message, the message asynchronous consumer is triggered to read the message destination message, and processing the message.

3. Contrast

message producers: The message sent is ' discontinuous '. The developer simply defines the steps to send the message as a method, which is called when the program needs to send a message.  

Message Consumers: as the app launches (requires additional developer), it listens to all messages at the destination of the message.

4, the origin of the MDB

To better implement the asynchronous consumer, Java EE developed a message-driven bean (MDB) specification,an MDB is essentially an asynchronous consumer , the MDB runs in the EJB container, and the client program is generally unable to call the MDB directly. The role of an MDB is to listen for the specified message purpose.

The role of the MDB is simple: to simplify development, when a developer needs to communicate through a JMS messaging mechanism, the JMS message producer sends the message in its original way, while the MDB specification simplifies the development of the JMS asynchronous consumer.

You only need to implement a onmessage (Message msg) method "Without acquiring a JMS connection, without having to get a JMS Session, and of course, regardless of when the MDB starts." The EJB container automatically launches the MDB for the purpose of listening for messages, and when the JMS message is delivered to the specified JMS message purpose, the MDB's method is triggered, which reads the message, reads the message, gets the message, and processes it. Developers only need to use annotation to specify the JMS message purpose, the type of message purpose.

(ii) Design principles for the use of MDBs

The message-driven bean, the messages driven bean, is an integrated product of EJB and JMS, and it is changed by stateless Sessionbean.

1, compared with the stateless Sessionbean

(1) The same point:

exist in the EJB container, and can take advantage of the system services provided by the EJB, such as transaction, security and concurrency control.

None of them will save the client's call state, can be shared by multiple clients, and so on.

Functionally, it is used as a business logic component of the program, so the MDB typically does not access the database directly, but relies on the underlying EAO component to access the database.

(2) different points:

However, the MDB does not interact directly with the client

2, the difference between the means of communication

the communication mode of client and stateless Sessionbean is called directly , and is a kind of synchronous communication mode. before the business method returns, the client thread is blocked and cannot continue execution.

the way the client and the MDB communicate is indirect , and is an asynchronous way of communicating. because the message producer simply sends a message to the specified message purpose, when the MDB is triggered, the message is processed after the trigger, and the message producer does not have to listen. Because the execution thread of the message producer is not blocked. It's just a message listener.

In comparison, the MDB communicates more efficiently! But stateless Sessionbean will be more reliable.

When the client calls the stateless Sessionbean method to throw an exception, the client can immediately obtain the exception and the exception information;

This is not the case when the client calls the MDB indirectly, and the client does not get information about the exception and the exception.

3. Applicable scenarios  

In general, stateless Sessionbean are used to define business logic, which is the facade of the entire application, and the application's controller component calls its business methods for processing.

If some business methods meet the following characteristics, consider using an MDB

1, the processing time of the business is longer, and the processing time may have some uncertainty.

2, the client calls the method after processing does not need to get the return result immediately.

And the MDB is essentially a message listener. Functionally, it should belong to the controller role, so it is not recommended to complete a complex business in the MDB's Conmessage () method.

If a business method is more time-consuming to process, and the client calls the method, it does not need to get the results back immediately. We still define the method in a Sessionbean, but the client does not call the method directly. The client simply sends the parameter that needs to invoke the method to the specified destination as a JMS message, at which point the OnMessage () method of the MDB that listens to the destination of the message is punished, and the method defined in the Sessionbean is called by the MDB's OnMessage () method.

This makes it clear that the MDB functions as a special controller and should not be defined as a business logic component.

  

Summarize:

This article presents the following information as a starting point for communication between messages:

components in the JMS messaging system are divided into:  

JMS message producer: Send Message, discontinuous

JMS Message Consumer: Receiving messages, listening to messages all the time

Synchronization: Easy to block, inefficient, and reliable (instant access to exception information)

Asynchronous: Not easy to block, high efficiency, unreliable

"MDB" belongs to the asynchronous message consumer. Simplifies development and is seen as a special controller.

Message-driven EJB (i) JMS and EJB