Enterprise JavaBeans, Fourth Edition

Connector-Based Message-Driven Beans

Although the JMS-based MDB has proven very useful, it has limitations. Perhaps the most glaring limitation is that EJB vendors are only able to support a small number of JMS providers (usually only one). In fact, most EJB 2.0 vendors only support their own JMS provider, no others. Obviously, this limits your choices: if your company or a partner company uses a JMS provider that is not supported by your EJB vendor, you will not be able to process messages from that JMS provider.^[43]

The root of the problem is complex and requires a fairly deep understanding of transaction management. In a nutshell, the delivery of the message by the JMS provider to the MDB, and all the work performed by the MDB (e.g., using JDBC, invoking methods on other beans, etc.), must be part of the same transaction, which is initiated by the EJB container. This requires that the EJB container have prior knowledge that message delivery is imminent, so that it can initiate a transaction before the message is actually delivered. Unfortunately, the JMS API doesn’t support this kind of functionality. So an EJB 2.0 container requires special code to coordinate transactions with each JMS provider. Custom integration is expensive, so EJB 2.0 vendors generally choose to integrate with very few JMS providers.

Another limitation of MDBs in EJB 2.0 is that they only support the JMS programming model; no other messaging systems are supported. While JMS is very useful, it’s not ...