Introduction to JMS and its usage in EJB 2.0

MessageDrivenBean in EJB 2.0, a fundamental change to the specification is the addition of a brand new enterprise-level bean type, namely MessageDrivenBean. MessageDrivenBean is specially designed to process incoming JMS messages. For many developers, JMS is a new example, so this article will take some time to explain their understanding of JMS and their usage in EJB 2.0.
　　
What is JMS? JMS is a vendor-independent API used to access the message sending and receiving system. It is similar to JDBC (Java Database Connectivity): Here, JDBC is an API that can be used to access many different relational databases, while JMS provides access methods that are also independent of vendors, to access the message sending and receiving service. Many vendors currently support JMS, including IBM MQSeries, BEA's Weblogic JMS service, and Progress's SonicMQ. These are just a few examples.
　　
JMS enables you to send messages from one JMS client to another JML client through the message sending and receiving service (sometimes called a message broker or router. A message is a type object in JMS. It consists of a header and a message body. The header consists of route information and metadata about the message. The message body carries the data or load of the application. Based on the type of the payload, messages can be divided into several types, including TextMessage, ObjectMessage, and MapMessage), BytesMessage, StreamMessage, and Message without a payload ).
　　
The message sending and receiving system is asynchronous, that is, the JMS client can send messages without waiting for a response. We can see that this is completely different from RPC-based (remote process-based) systems, such as the reference implementation of EJB 1.1, CORBA, and Java RMI. In RPC, the client calls a method of a distributed object on the server. The client is blocked before a method call is returned. The client must wait until the method call ends before executing the next command. In JMS, the client sends messages to a virtual channel (topic or Queue), while other JMS clients subscribe or listen to this virtual channel. When the JMS client sends a message, it does not wait for a response. It executes the sending operation and then continues to execute the next command. Messages may eventually be forwarded to one or more clients, which do not need to respond.
　　
Jms ejb 2.0 in EJB 2.0 supports JMS integration in two ways: as a bean available resource, and as a MessageDrivenBean. When using JMS as a resource, the bean using the jms api is the producer or sender of the message. In this case, bean sends messages to a virtual channel called a topic or queue. MessageDrivenBean is the user or receiver of the message. It listens to a specific virtual channel (topic or Queue) and sends a haircut to the channel. To better understand the roles of message senders and consumers, use SessionBean to send a message using JMS, and then use a new MessageDrivenBean to use the same message.
　　
As resources of EJB 2.0, the JMS Session bean and the Entity bean are both RPC-based components. To assemble various transactional components together, this is an outstanding architecture. However, in some cases, the synchronous nature of RPC may become an obstacle, which is why access to the jms api is included as a resource in EJB 1.1. Using the context named in the JNDI environment, bean can obtain a JMS factory and send an asynchronous message to the topic or Queue (also obtained from JNDI) without waiting for a response. The following is an example of ShoppingCart bean. It uses JMS to send the Order details to the message receiving and receiving topic.