The Java Message Service (JMS) provides the means for asynchronous communications via Message-Oriented Middleware (MOM). In a J2EE environment, with Enterprise JavaBeans, JMS can be used to produce messages asynchronously. However, EJBs aren't suitable for consuming messages asynchronously. The MDB provides an infrastructure for consuming JMS messages within a J2EE environment. This new EJB type (EJB 2.0) presents the same robust component-based infrastructure that session and entity beans benefit from.
WebSphere Application Server 4.0 supports the latest JMS Specification (1.02b) and is often used in combination with MQSeries 5.2.1 as its MOM. The fact that WAS 4.0 supports JMS doesn't necessarily imply that it also supports MDBs, since MDBs are part of the EJB 2.0 specification and not part of JMS.
WebSphere 4.0 does support more functionality than specified in EJB 1.1, but it lacks several important features of EJB 2.0; for example, the MDB container is not implemented in WAS 4.0. Although MDBs will be available in WAS 5.0, this shortcoming in WAS 4.0 is a nuisance.
Recently, many companies have migrated from WAS 3.5 to 4.0, IBM's mature J2EE platform. Most have invested in the development of mission-critical applications or the migration of their legacy applications to this platform. Due to these investments, the application server market is not as flexible as the desktop market, where new versions are accepted every few months. IBM realized this and came up with an intermediate solution to cope with this deficiency in WAS 4.0. This article provides a brief outline; for a thorough description of the solution, see the IBM Redbook SG24-6283-00.
The proposed solution consists of two parts: a so-called JmsMonitor, which is a queue-monitoring process outside the WebSphere Application Server, and a MessageReader, which is implemented by an ordinary stateless session bean (see Figure 1). Note that the monitor only browses the queue; it doesn't actually read the message. When a message is available on the queue, the monitor invokes the readMessage method of the MessageReader, which reads the message from the queue and invokes its onMessage. The apparent reason for this complicated method is to enable scalability by pooling and container-managed transactions.
What's wrong with this solution? Well, the system administration's having external processes isn't contributing to the maintainability of the system. IBM's solution comes from a Redbook that targets z/OS and OS/390. A solution like this is very natural in these mainframe environments because of the way processes are treated. On other platforms (AIX, Linux, NT, etc.), however, a pure WebSphere solution that can be distributed, deployed, and administered with a single EAR file is preferable. The JmsMonitor doesn't use an event-driven mechanism, it uses a one-time scan through the queue. This "batch" behavior could be extended to some sort of pooling method, but it certainly doesn't fit into an object-oriented J2EE design.
