Java Reference
In-Depth Information
Adding message-driven beans to your application
Once we do the configuration, we can start coding a JMS message consumer, such as a
message-driven bean.
Message-driven beans ( MDBs ) are stateless, server-side, and transaction-aware compon-
ents that process asynchronous JMS messages.
One of the most important aspects of message-driven beans is that they can consume and
process messages concurrently. This capability provides a significant advantage over tradi-
tional JMS clients, which must be custom built to manage resources, transactions, and se-
curity in a multithreaded environment. MDB containers manage concurrency automatically
so the bean developer can focus on the business logic of processing the messages. An MDB
can receive hundreds of JMS messages from various applications and process them all at
the same time because numerous instances of it can be executed concurrently in the con-
tainer.
From the semantic point of view, an MDB is classified as an enterprise bean, just like a ses-
sion or entity bean, but there are some important differences. At first, the message-driven
bean does not have component interfaces. These are absent because the message-driven
bean is not accessible via the Java RMI API; it responds only to asynchronous messages.
Just as the entity and session beans have well-defined life cycles, so does the MDB bean.
The MDB instance's life cycle has two states, Does not Exist and Method ready Pool , as
shown in the following image:
When a message is received, the EJB container checks to see whether any MDB instance is
available in the pool. If a bean is available in the free pool, JBoss uses that instance. Once
an MDB instance's onMessage() method is returned, the request is complete and the in-
stance is placed back in the free pool. This results in the best response time, as the request
is served without waiting for a new instance to be created.
Search WWH ::




Custom Search