Java EE Component Development

I. Overview

Message service is a kind of software that provides messaging services between distributed applications, which is reliable, asynchronous, loosely coupled, language neutral, platform neutral, and usually configurable. It is implemented by encapsulating the messages passed between the sender and receiver and adding a software processing layer to the location where the distributed messaging client is combined. The messaging service provides an interface for the client of the message, which isolates the underlying messaging service, enabling various client programs to communicate conveniently through a friendly programming interface.

The Java Messaging Service (Java message SERVICE,JMS) is a Java API that defines how a message's client program interacts with the underlying messaging service provider in a standardized form. JMS provides an interface through which the underlying messaging service provider provides a JMS messaging service to a client program. JMS provides point-to-point message mode (point-to-point) and publish-Subscribe message mode (PUBLISH-SUBSCRIBE). The point-to-point message mode is implemented by a message queue, the producer of the message writes a message to the queue, and the message is extracted by the consumer from the queue. The Publish-Subscribe message mode is implemented through a hierarchy of topic (Topic) nodes, where the producer of the message publishes the message to the hierarchy, and the consumer of the message subscribes to the structure.

The point-to-point message mode has the following characteristics:

Every message has only one consumer.

There is no time dependency between the recipient of the message and the sender. The recipient can extract information, regardless of whether the sender is running when the message is sent. The recipient gives a receipt for the message that was successfully processed.

Publish-Subscribe message mode has the following characteristics:

Each message can have multiple consumers.

A client that subscribes to a topic can only receive messages that are published after it has subscribed. In order to receive the message, the Subscriber must remain active. Therefore, there is a time dependency between the Publisher and the Subscriber.

The JMS API somewhat relaxes the requirements for this dependency, allowing the creation of persistent subscriptions (durable Subscription). With persistent subscriptions, messages sent when the Subscriber is inactive are also received.

The EJB 2.0 specification defines a new type of EJB, the message-driven EJB (Message-driven EJB, or MDB), that can implement the recipient of the JMS message as an EJB. Message-driven EJB implements a new set of interfaces that enable an EJB to receive and process messages from a JMS message producer asynchronously to a queue or topic. The EJB client is constructed in exactly the same way as the ordinary JMS message producer, that is, the JMS message producer does not have to know that the consumer of the message is an EJB.

The biggest feature of message-driven beans, relative to session beans and entity beans, is that the client does not access the bean through the interface. Unlike the session bean and entity bean, the message-driven bean has only one bean class. In some ways, message-driven beans are similar to stateless session beans: message-driven beans do not retain data or dialog state for a particular customer.

All instances of a message-driven bean are equivalent, allowing the container to assign the message to an instance of any message-driven bean. The container can establish a buffer pool for message-driven beans and implement concurrent processing of messages. A message-driven bean can handle messages from multiple client programs.

Instance variables of a message-driven bean can contain state information during processing of a customer message, such as a JMS connection, an open database connection, or a reference to an EJB object. When a message arrives, the container invokes the message-driven Bean's onmessage () method to process the message. The OnMessage () method typically makes message stereotypes (cast) One of five JMS message types, and then processes the message as required by the business logic applied.

Messages passed to a message-driven bean may be within a transaction, at which point all operations within the OnMessage () method are part of the transaction. If the message processing results are rolled back, the message will be posted again by the system.

When should I use a message-driven bean? Session beans and entity beans can send JMS messages, can receive messages synchronously, but cannot receive them asynchronously. Sometimes, in order to prevent excessive use of server resources, we want to avoid blocking in server-side components, at which point we can asynchronously receive messages with message-driven beans.