MDB (Message Driven Beans) Vs. SpringJMS - Point by Point Comparison

EJB’s Message Driven Beans (MDB) Vs. SpringJMS

MDB and SpringJMS can be compared with multiple features:

1.       Learning Curve

Most important feature of SpringJMS is, object can be easily configured in XML format making is extra easy to manage.  Some features like concurrentConsumer can be managed with XML without touching Java code.

MDB on the other hand involves expert level understanding of EJB and has more LOC to write for same operation.  So Overall learning Curve for SpringJMS is less.

2.       Development Time

Spring implementation uses the JmsTemplate helper class to simplify working with the JMS API to send the message. Also, auto starting consumers with application context and ease of handling properties with xml configuration, reduces development time, in turn production cost of application.

MDB though robust, needs good amount of efforts in comparison.

3.       Container Dependency

MDB requires EJB container. Container is mainly responsible for instantiation and handling other life cycle events for MDB. EJB 3.0 also has additional packaging and deployment requirements that
Spring does not. Also message listeners must be EJB components.

Spring is container of its own. SpringJMS do not require any external container to execute. Any POJO can potentially be activated in response to incoming messages

4.       Multi-Queue Configuration:

MDBs are static for one queue. One MDB cannot be used for consuming from two or multiple queues. On the contrary, Spring provides the flexibility to customize the number of queues to listen to and dynamically configure the destinations as well.

5.       Security

For MDB, security is managed by the EJB container by configuring a security identity for the MBM

Spring UserCredentialsConnectionFactoryAdapter provides a mechanism to specify user credentials for every JMS connection to secure the JMS connection.

6.       Dependency management/configurability/intermediation

Spring offers much more mature and configurable support for dependency management than EJB 3.0 with its dependency injection and IOC framework

7.       Availability

The Enterprise server controls JMS connection pooling and failover and reconnecting to the message broker when the connection is lost has to be supported and configured at the enterprise server level .

Individual applications and modules cannot control or override JMS availability

Spring DMLC automatically re-establishes connections if the message broker becomes unavailable

8.       Performance

The EJB MDB container manages the JMS Connection Pool and needs to be configured to optimize the concurrent processing of messages

Spring DMLC allows you to scale the number message consumers using the concurrentConsumers property and the maxConcurrentConsumers property. It provides various levels of caching of the JMS resources (connections and sessions) and JMS consumers for increased performance

9.       Transaction

Can use the default container managed transaction to allow the EJB container to handle transaction demarcation or specify local transactions to group message sends and receives

Spring DMLC provides support for local JMS transactions as well as an external transaction manager around message reception and listener execution

10.   Message Convertors

Spring provides message converters which can automate the conversion of Java objects to message content

MDB provides no such features.

11.   Future Orientation

Spring has vibrant open source community and considered as very stable but futuristic design. Many newer MOMs and EIPs (Enterprise Integration Pattern) like Camel directly uses Spring for messaging implementation.

EJBs on the contrary and seen lesser in market.

Summary:

                Considering current era of IT development, adopting SpringJMS over MDB is always a better choice.