email article
	printer friendly

Design for EJB Message-Driven Beans with UML Use Cases
J2EE's MDB specification offers an elegant approach for implementing distributed enterprise applications
by Frank Teti

Posted December 2, 2003

Since the Message-Driven Bean (MDB) specification was introduced to the Java platform as part of Enterprise JavaBeans (EJB) 2.0, a complete application construct for guaranteed message delivery on a truly enterprise-wide scale is now attainable within J2EE applications. Together with Java Message Service (JMS), first introduced in 1998, MDB provides J2EE with all the functions of a complete distributed computing environment.

MDB is a useful application construct that should be part of any well-designed J2EE Internet or extranet application. For organizations that are considering migrating legacy CICS/Cobol applications that integrate with queuing services such as MQSeries or TIBCO, application reengineering using MDBs provides a comparable modern alternative. However, elegant technologies come with a cost. J2EE application servers are highly functional, but run-time performance may not meet current Service Level Agreement (SLA) requirements. Considerable application and code refactoring may be required to meet those SLAs.

Whether you view MDB as an extension to EJB or as a natural progression of JMS, it is truly an important technological advance within the J2EE platform. From an object behavior standpoint, an MDB has the functionality of an EJB session bean in conjunction with a JMS client. More specifically, MDBs allow J2EE applications to receive JMS messages asynchronously. However, to appreciate the use of MDB and understand how to incorporate this functionality into an enterprise-wide application, it is important to have a basic understanding of the JMS design paradigm.

The introduction of JMS enabled Java to compete in functionality with CORBA in the distributed object marketplace. The initial JMS specification allowed for the two dominant messaging approaches: point-to-point and publish-and-subscribe. More importantly, Java through JMS could handle asynchronous distributed messages, which represented an alternative to Remote Method Invocation (RMI), a synchronous protocol. CORBA, at this point in time, already provided asynchronous processing through the IDL keyword oneway—that is, oneway void mymessage(in string text). If you precede a method operation with the keyword oneway, a client that calls the operation will not block while the object processes the call.

From a design perspective, there is a subtle difference between asynchronous processing and enterprise messaging. Messaging implies that there is a transaction handoff of information to another process or subsystem. On the other hand, asynchronous processing implies that a process needs to be executed, but that the calling client does not want to wait for the process to complete or does not even care if it does complete.

JMS, as the name implies, did not really satisfy the need for asynchronous processing. Rather, it provided a Java API for already existing enterprise-wide Message-Oriented Middleware (MOM) applications. JMS provides enterprise-wide software behavior by interfacing with messaging applications, such as TIBCO or MQSeries, in the same way that JDB interfaces with the Oracle SQLNet to achieve connectivity to the Oracle DBMS. Essentially, JMS represented fundamental software marketing strategy; if you control the API you can you can control the market. For example, instead of using a single API that can run anywhere, MQSeries provides various APIs for different programming languages: a proprietary Java API, a JMS API, and its own C-based API.

With the introduction of the MDB specification combining EJB session bean behavior with JMS, the application construct is more analogous to the CORBA oneway call and lends itself to building true asynchronous behavior into Java applications, not just messaging. For J2EE-based e-commerce applications, with complex transaction processing or CPU-intensive requirements, asynchronous processing using MDB is strongly recommended. In projects where Unified Modeling Language (UML) is used, use cases can identify the need for processing that does not need to be executed synchronously. From an end-user perspective, either on the Internet or intranet, this results in applications with superior performance, which other than reliability and scalability are the most important features of any software application.