Beginning Java EE 6 with GlassFish 3, Second Edition

CHAPTER 13 ■ SENDING MESSAGESIn general, MDBs listen to a destination (queue or topic) and, when a message arrives, theyconsume and process it. They can also delegate business logic to other stateless session beans in a safe,transactional manner. Because they are stateless, MDBs do not maintain state across separateinvocations from one message received to the next. MDBs respond to JMS messages received from thecontainer, whereas stateless session beans respond to client requests through an appropriate interface(local, remote, or no-interface).Messaging Specification OverviewMessaging in Java is mostly represented by JMS, which can be used in applications running in a standard(Java SE) or an enterprise (Java EE) environment. MDBs simply represent a way for stateless session EJBsto be message consumers and is bound to the EJB specification.A Brief History of MessagingUp until the late 1980s, companies did not have any easy way to link different applications. Developershad to write separate software adapters for systems to translate data from source applications into aformat that the destination system could understand (and vice versa). Because of the disparity of servers’processing capabilities and availabilities, buffers were created to de-couple the processing so that theoverall time wouldn’t be prolonged. A lack of homogeneous transport protocols created low-levelprotocol adapters. Toward the end of the 1980s, middleware began to emerge, which solved theseintegration issues. The first MOMs were created as separate pieces of software that could sit in themiddle of applications and manage the “plumbing” between systems. They were able to managedifferent platforms, different programming languages, various network protocols, and diverse hardware.JMS 1.1The JMS specification was first published in August 1998. It was created by the major middlewarevendors to bring messaging capabilities to Java. JSR 914 went through minor changes (JMS 1.0.1, 1.0.2,and 1.0.2b) to finally reach the 1.1 version in April 2002. Since then, the specification hasn’t changed.JMS 1.1 was integrated into J2EE 1.2 and has been a part of Java EE since. However, JMS and MDBs arenot part of the Web Profile specification I described in the first chapter. This means they will only beavailable on application servers implementing the full Java EE 6 platform.Although JMS is a verbose and low-level API compared to JPA or EJB, it does a very good job.Unfortunately, it has not been changed or improved in Java EE 5, nor in Java EE 6.EJB 3.1MDBs were introduced in EJB 2.0 and were improved with EJB 3.0 and the general Java EE 5 paradigm of“ease of use.” They were not internally modified as they continued to be message consumers, but theintroduction of annotations and configuration by exception made them much easier to write. The newEJB 3.1 specification (JSR 318) has no notable changes to MDBs.As you’ve seen in Chapter 7, asynchronous calls are now possible within stateless session beans(using the @Asynchronous annotation). In previous versions of Java EE, it was impossible to haveasynchronous calls between EJBs. Therefore, the only possible solution was to use JMS and MDBs—expensive, as many resources had to be used (JMS destinations, connections, factories, etc.) just to call a379