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 the only messaging system available. SOAP, email, CORBA Messaging, proprietary messaging systems used in ERP systems (SAP, PeopleSoft, etc.), and legacy messaging systems are examples of other non-JMS messaging systems.

EJB 2.1 supports an expanded, more open definition of message-driven beans that allows them to service any kind of messaging system from any vendor. The only requirement is that new types of message-driven beans implement the javax.ejb.MessageDrivenBean interface and adhere to the message-driven bean life cycle. While EJB 2.1 vendors can build custom code to support a new messaging system (something other than JMS), they must also support any message-driven bean type that’s based on the J2EE Connector Architecture 1.5.

The J2EE Connector Architecture provides a standard Service Provider Interface (SPI) that allows any Enterprise Information System (EIS) to plug into any J2EE container system. Version 1.0 of the connector architecture applies only to request/reply resources in which the J2EE component (EJB or Servlet/JSP) initiates the request. The current version of the connector architecture (1.5), which is required by J2EE 1.4, is much more general, and can work with asynchronous messaging systems. In such systems, the J2EE component waits for messages to arrive, instead of initiating an interaction with an EIS; the EIS initiates the interaction by delivering a message.

J2EE Connectors 1.5 defines a messaging contract specifically tailored to message-driven beans. It defines the contracts between an EJB container and an asynchronous Connector so that message-driven beans automatically process incoming messages from the EIS. MDBs based on an asynchronous Connector implement the standard javax.ejb.MessageDrivenBean interface, as well as a specific messaging interface defined by the Connector itself. Instead of implementing the javax.jms.MessageListener interface, the MDB implements some other type of interface that is specific to the EIS.

For example, Chapter 3 introduced a hypothetical Email Connector that allows MDBs to process email—similar to how JMS-based MDBs process JMS messages. The Email Connector is purchased from Vendor X and delivered in a JAR file called a RAR (Resource ARchive). The RAR contains all the Connector code and deployment descriptors necessary to plug into the EJB container system. It also defines a messaging interface that the developer uses to create an Email MDB. Here is the hypothetical Email messaging interface that must be implemented by an Email MDB.

package com.vendorx.email;

public interface EmailListener {
    public void onMessage(javax.mail.Message message);
}

The bean class that implements this interface also implements the javax.ejb.MessageDrivenBean interface and is responsible for processing email messages delivered by the Email Connector. The following code shows a MDB that implements the EmailListener interface and processes email:

package com.titan.email;
public class EmailBean 
               implements javax.ejb.MessageDrivenBean, com.vendorx.email.EmailListener {
    MessageDrivenContext ejbContext;
    public void setMessageDrivenContext(MessgeDrivenContext mdc){
        ejbContext = mdc;
    }
    public void ejbCreate( ){}
    public void onMessage(javax.mail.Message message){
               javax.mail.internet.MimeMessage msg = 
               (javax.mail.internet.MimeMessage) message;
               Address [] addresses = msg.getFrom( );
               //  continue processing Email message
               }
    public void ejbRemove( ){}
}

In this example, the container calls onMessage( ) to deliver a JavaMail Message object, which represents an email message including MIME attachments. However, the messaging interfaces used by a Connector-based MDB don’t have to use onMessage( ). The method name and method signature can be whatever is appropriate to the EIS; it can even have a return types. For example, a Connector might be developed to handle request/reply style messaging for SOAP. This connector might use the ReqRespListener defined by the JAXM (Java API for XML Messaging), which is a SOAP messaging API defined by Sun Microsystems that is not a part of the J2EE platform:

package javax.xml.messaging;
import javax.xml.soap.SOAPMessage;

public interface ReqRespListener {
    public SOAPMessage onMessage(SOAPMessage message);
}

In this interface, onMessage( ) has a return type of SOAPMessage. This means the EJB container and Connector are responsible for coordinating the reply message back to the sender (or some destination defined in the deployment descriptor). In addition to supporting different method signatures, the messaging interface may have several methods for processing different kinds of messages using the same MDB.

There’s no limit to the new kinds of message-driven beans that EJB 2.1 containers systems can support. The real beauty of all this is that Connector-based MDBs are completely portable across EJB 2.1 vendors—because all vendors must support them. If you use a Connector-based MDB with EJB 2.1 vendor A, and later change to EJB 2.1 vendor B, you can continue to use the same Connector-based MDB with no portability problems.

The activation configuration properties used with non-JMS-based MDBs depend on the type of Connector and its requirements. For example, the <message-driven> element of the deployment descriptor for the Email MDB might look something like this:

 <enterprise-beans>
    ...
    <message-driven>
        <ejb-name>EmailEJB</ejb-name>
        <ejb-class>
            com.titan.email.EmailBean
        </ejb-class>
        <messaging-type>com.vendorx.email.EmailListener</messaging-type>
        <transaction-type>Bean</transaction-type>  
        <activation-config>
               <activation-property>
               <activation-config-property-name>mailServer
               </activation-config-property-name>
               <activation-config-property-value>mail.ispx.com
               </activation-config-property-value> 
               </activation-property> 
               <activation-property>
               <activation-config-property-name>serverType
               </activation-config-property-name>
               <activation-config-property-value>POP3
               </activation-config-property-value> 
               </activation-property> 
               <activation-property>
               <activation-config-property-name>messageFilter
               </activation-config-property-name>
               <activation-config-property-value>to='[email protected]'
               </activation-config-property-value> 
               </activation-property>        
               </activation-config>                                  
        <security-identity>
            <run-as>
                <role-name>Admin</role-name>
            </run-as>
        </security-identity>
    </message-driven>
    ...
</enterprise-beans>

Unfortunately, as of this writing there are no Connector-based MDBs commercially available, which is why all examples (like the Email EJB) are hypothetical. It’s likely that new Connector-based MDBs will start popping up after EJB 2.1 servers have been around for a short while.