EJB-message-driven bean of EJB components

The session bean is deployed in the JBoss of the server. Then, the client program Java or JSP calls the JNDI service of the server to call the Session Bean. It can be said that Session Bean implements distributed service calls. However, this call uses the synchronous method, that is, the client and the server are synchronized during the call. As shown in:

Why is it synchronized during remote method calls? Generally, the server remains in the waiting (blocking) status until it completes the customer request. The customer can accept the execution result and continue the execution only after the server completes processing the request.Synchronous execution.

However, this situation is obviously extremely bad for the user experience. The user does not need to worry about how long it takes for the server to process his request. He just needs to be able to complete the work he wants conveniently and quickly. What do we think of here? Yes, it is Ajax. It is used to solve the inconvenience caused to users due to synchronization. So how does one solve this problem in EJB? That's right. It's the main content of this blog post ---Message-driven Bean.

As shown in,MessageReplacedRemote method callYou can think of a message as a "man-in-the-middle" between the customer and the server ". A man-in-the-middle accepts messages from several message producers and then broadcasts them to several message consumers. BecauseIntermediarySo that the message producer can continue to execute the message after sending the message. In this way, the entire process isAsynchronous programming.

The basic framework supporting such message processing is calledMom (message-oriented Middleware: Message-oriented middleware). However, all mom systems are proprietary, and they all have their own APIs, which makes it difficult for end users to be locked on specific vendors for transplantation and learning. This occurs.JMS (Java Message Service: JavaMessage Service)It is a message standard, so that developers only need to learn the jms api, and message code that complies with the JMS specifications can be flexibly transplanted between different moms.

We will not detail how to create, send, or accept a message in JMS. We only provide a picture for you to understand.

 

After learning about JMS, how does JMS work with EJB? The MDB we introduce in this article isBased onEJB components of JMS--Message-driven Bean. However, we need to note that the MDB component can not only accept JMS messages, but also accept other types of messages. No matter what type of message, once it comes, the EJB container will call the MDB instance to process it.

 

As we can see, MDB is loosely coupled with the customers who send messages. Customers cannot access MDB through service interfaces, that is, they cannot reference MDB, and cannot directly interact with it. The customer needs to send a message using the API provided by the message provider (such as JMS), and then receives the message MDB to process it.

 

If you know what MDB is, let's talk about the specific characteristics of MDB.

(1) There is no remote or local service interface;

In Session Bean, business interfaces are divided into remote and local business interfaces for the client to call. But it does not exist in MDB. Because MDB is onlyProcessingSent from a message customerMessageDevelopers do not need to call mdb, so MDB does not need to have business interfaces.

(2) stateless;

MDB and stateless Session Bean are similar in the session state, and both have no session state. All MDB instances are anonymous, and the EJB container applies to all MDB instances.Equal Treatment.

(3) Single-threaded;

At the same time, a single MDB instance can only processSingle message. So how does it implement concurrent operations? The EJB container maintains multiple MDB instances in the pool, queues messages, and distributes messages to MDB instances for processing. This allows you to consume messages concurrently.

(4) Support various listener methods for message distribution;

MDB only accepts messages from the destination or resource adapter.The specific content is unknown. So how does one determine to use the correct MDB component? Is completed by the EJB container. The EJB container callsSome methods in the listener InterfaceThese methods will receive messages (such as JMS messages ). Then, when developers implement these methods (such as the onmessage () method of the jms api message listening Interface), they will use the if statement to determine the Message Type and then process it.

 

The above are some of my theoretical knowledge about MDB. Do you understand some of them?

EJB-message-driven bean of EJB components