The last item is added to provide the previously mentioned single EAR.

Message Monitor and Collector
Since the number of J2EE component types is rather limited, there are only a few possible solutions for building a pseudo MDB. The only thing that will start in WebSphere 4.0 at application server startup is a servlet, and the closest you can get to an MDB is a stateless session bean. A servlet that is started by the application server and implements a MessageListener in combination with a stateless session bean, which receives the message from the servlet, would do the trick (see Figure 2). However, pooling and container-managed transactions aren't supported by this straightforward solution - this was actually a prototype to see whether this works at all. I've included the source code for this prototype servlet/EJB solution for educational purposes, but I won't elaborate on it here (source code for this article is available at www.sys-con.com/websphere/sourcec.cfm).

The golden rule in computer science is, "A layer of indirection can solve every problem." In the final solution, the purpose of the StartMonitor servlet is solely to start a QueueMonitor stateless session bean, which contains the monitor functionality. In turn, this QueueMonitor EJB invokes another stateless session bean (QueueCollector), which serves as the pseudo MDB (see Figure 3). The code is nearly identical to that of the servlet/EJB solution; the only difference is that the monitor functionality is separated from the bootstrap mechanism.

Only one StartMonitor servlet is necessary within WebSphere, which can bootstrap all QueueMonitor EJBs at server startup. The initialization parameters of the servlet determine which QueueMonitors should be activated (see Figure 4). Although the QueueMonitor EJBs are different beans (classes) with different home and remote interfaces, there's an EJB polymorphism technique to create different EJBs in a generic way.

This can be done by extending all the remote interfaces of the QueueMonitor EJBs from both EJBObject and IQueueMonitor and the home interfaces from EJBHome and IQueueMonitorHome (see Figure 5). Since these are interfaces, use of multiple inheritance is allowed. The home interface looks like the following:

public interface MyQueueMonitorHome extends EJBHome,
IQueueMonitorHome {
public IQueueMonitor create() throws
CreateException,
RemoteException;
}

The IQueueMonitor return type of the create() (which is not the regular remote interface, but its super interface) is crucial. This allows the StartMonitor servlet to create different QueueMonitor EJBs like this:

IQueueMonitorHome queueMonitorHome = (IQueueMonitorHome)
PortableRemoteObject.narrow(obj, IQueueMonitorHome.class);
IQueueMonitor queueMonitor = (IQueueMonitor)
queueMonitorHome.create();

(More details on polymorphism and EJBs can be found in the August 2002 issue of Java Developer's Journal [Vol. 7, issue 8].)

After the StartMonitor server is started and all QueueMonitors are activated, this servlet is done.

The QueueMonitor does most of the work. This stateless session bean handles all communication with the JMS provider (e.g., MQSeries). It connects to the JMS provider, maintains the session, creates the receiver, and implements the message listener and the exception listener. The exception listener provides the means to recover from connection failure with the MOM.

Your QueueMonitor EJB needs to be derived from the class QueueMonitor. To let the QueueMonitor do its work, it must be initialized in the ejbCreate() and destroyed in the ejbRemove(). The combination of the StartMonitor and the QueueMonitor provides functionality similar to that of the JmsMonitor in the IBM solution (and, of course, the real MDB container). The QueueCollector is merely an empty base class that provides the pseudo-MDB characteristics. It runs in the StartMonitor/QueueMonitor environment, just like real MDBs run in the MDB container.

The configuration of a real MDB includes a destination, which is JMS terminology for a queue. Since the deployment descriptor of a stateless session bean is very different from that of the new MDB, there is a certain limit to how well it can mimic the real thing. In order to let the QueueCollector resemble the real MDB, it will store the JMS destination in its deployment descriptor. During startup the QueueMonitor retrieves the JMS destination information from the QueueCollector by calling the startCollector() method. The QueueMonitor initializes its JMS resources with the configuration information that this method returns.

The QueueMonitor uses the same EJB polymorphism described earlier to create the QueueCollector. Similar to the StartMonitor, the QueueMonitor stores the name of the QueueCollector in the deployment descriptor. The "queueCollector" environment variable of the QueueMonitor EJB holds the reference name of the QueueCollector EJB. The result is a rather long chain of names, references, and JNDI names, which is somewhat error-prone (see Figure 6).

Another difference between the pseudo MDB and the real MDB is that there's no way to protect the remote interface of the session bean QueueCollector from being invoked by some other component. A real MDB doesn't have a home or remote interface. There is no adequate solution to this problem - just tell developers not to alter the remote interface of the pseudo MDB.

The only function of the QueueMonitor is reading messages from the queue and calling the QueueCollector to process them. If there are multiple messages on the Queue and the processing in the QueueCollector takes longer than just reading from the Queue, then the QueueMonitor will create multiple QueueCollectors (depending on the configuration, of course). This also indicates that every QueueCollector (EJB) type needs its own QueueMonitor (EJB) type.

If applicable, both stateless session beans need to take part in the same transaction. If you need some form of transactional processing in the QueueCollector, involving the QueueMonitor in the same transaction is mandatory. Otherwise, a rollback would result in loss of the message.

Run on Server
The environment in which MOM operates is often quite complex. The included EAR files need some configuration before they'll run on WebSphere 4.0. I use IBM MQSeries as the underlying JMS provider, which is very common in combination with WebSphere. To enable MQSeries to work with JMS, you must download the JMS Support Pac from the IBM Web site (MA88 Support Pac).

My implementation uses LDAP for the storage of the JMS destinations. I've included the LDIF and the LDAP configuration file for OpenLDAP. More information on the administration of JMS resources (JMSadmin) can be found in the documentation that comes with the MA88 Support Pac and IBM MQSeries. I've also included a WebSphere Studio Application Developer (WSAD) server project that I used during development. The following configurations must be made to the supporting software to run the enclosed solution:

You can change the settings, but remember that there's a relationship between the deployment descriptor of the QueueCollector, the LDAP entries, the MQSeries resources, and the application server settings.

If you experience problems while running the solution on WebSphere, check your configuration. I found that problems are usually caused by small typos in EJB references, JNDI names, or LDAP entries. Moreover, make sure that your supporting middleware is running (e.g., MQSeries QueueManager and Listener service, slapd, etc.).

Conclusion
The solution described here complies with the requirements stated earlier. It simulates a real MDB to the available J2EE components in WebSphere 4.0 as closely as possible. It's very easy to use by simply inheriting from the QueueMonitor and QueueCollector class (the pseudo MDB) and configuring the beans with the deployment descriptor. The servlet bootstrap mechanism works at server startup and is a pure WebSphere solution. The combination of QueueMonitor and QueueCollector provides the means to comply with both the pooling and container-managed transaction requirements.

The QueueMonitor and QueueCollector solution operates in the point-to-point communication domain. This means that there's a one-on-one relationship between sender and receiver. A real MDB can be configured by its deployment descriptor to operate in either the point-to-point domain or the publish-and-subscribe domain. The publish-and-subscribe domain allows multiple subscribers to receive messages by subscribing to a topic. It's easy to develop a topic-based pseudo MDB along the lines of the solution described above. Just replace queue with topic, sender with publisher, and receiver with subscriber, and you're as good as finished. A combination solution that supports both point to point and publish and subscribe like a real MDB is also possible, but it overcomplicates things and there's no substantial gain.

Resources