Ejb mdb (Message-driven bean) 2-MDB Implementation Technology

5. Associate the message-driven bean with the destination or terminal

 

When a message-driven bean is deployed in a container, it is associated with the destination or terminal. It is the responsibility of the deployer to associate the message-driven bean with the destination or terminal.

JMS message-driven Bean

When the bean is deployed to a container, the JMS message-driven bean is associated with the JMS destination (queue or topic. It is the responsibility of the deployer to associate the message-driven bean with the queue or topic.

The bean provider can use the activationconfig element of the messagedriven annotation or the activation-config-property deployment element to tell the deployer whether the message-driven bean is associated with the queue or topic. The attribute name used to specify the destination type associated with the bean is destinationtype. The value of this attribute must be javax. JMS. queue or javax. JMS. Topic.

 

1. queue: point-to-point message transmission

Through the point-to-point (PTP) message transmission model, one application can send messages to another application. In this transfer model, the target type is queue. The message is first sent to the queue target, and then the message is sent from the queue to a consumer listening to the queue, such:

A queue can be associated with multiple queue senders and receivers, but only one message is delivered to one receiver. If multiple receivers are listening for messages in the queue, the JMS provider determines which receiver receives the next message based on the "first-to-First" principle. If no receiver is in the listening queue, the message is retained in the queue until the receiver is connected to the queue. This type of message transmission model is a pull model in the traditional sense. In this model, messages are not automatically pushed to the client, but are requested by the client from the queue.

2. Topic: publish/subscribe message transmission

Through the pub/sub message transmission model, an application can send a message to multiple receivers. In this transfer model, the target type is topic. The message is first sent to the topic target and then to all active consumers who have subscribed to the topic. For example:

The pub/sub message transmission model allows multiple topic subscribers to receive the same message. JMS keeps the message until all topic subscribers receive the message. The pub/sub message transmission model is basically a push model. In this model, messages are automatically broadcast, and consumers do not need to obtain new messages through active requests.

 

Vi. mdb Implementation Technology

MDB is implemented by pooling technology because the client of MDB does not communicate with the specific MDB instance. On the contrary, MDB is implemented by loose coupling. First, the customer sends a message to the Message destination of the EJB container, and then the EJB container sends the message to the MDB instance subscribed to this destination.

The EJB container also maintains an instance pool for each mdbclass. When a message is sent to the destination of the MDB subscription, the EJB container selects an MDB class instance to accept and process the message.

Pooling technology: clients do not communicate directly with Bean class instances, but communicate through remote or local interfaces exposed by Bean class, further, we will use the Bean class proxy stub to communicate with the EJB container. In this way, you can maintain an instance pool for each Bean class and then use these instances to serve a large number of customers.

MDB uses an activation mechanism to reduce server resource consumption. When the EJB container resources are insufficient, it selects some instances that can be deactivated and serializes them to the disk, when necessary, restore it from the disk to the memory.