J2EE Message-Driven EJB Development
A messaging service is software that provides support for passing messages between distributed applications in a reliable, asynchronous, loosely coupled, language-independent, platform-independent, and often configurable fashion. Messaging services accomplish this task by encapsulating messages that are sent between a sender and a receiver, and by providing a software layer that sits between distributed messaging clients. A messaging service also provides an interface for messaging clients to use that isolates the underlying message service implementation so that heterogeneous clients can communicate using a programmer-friendly interface.
The Java Message Service (JMS) is a Java API that defines how messaging clients can interface with underlying messaging service providers in a standard fashion. JMS also provides an interface that underlying messaging service providers implement to provide JMS services to clients. JMS provides both a point-to-point and a publish-subscribe model of messaging. Point-to-point messaging is accomplished by implementing message queues to which a producer writes a message to be received by a consumer. Publish-subscribe messaging is accomplished by implementing a hierarchy of topical nodes to which producers publish messages and to which consumers can subscribe.
In the EJB 2.0 specification, a new type of EJB is defined that allows JMS message receivers to be implemented as EJBs. This new type of EJB is referred to as a message-driven EJB. A message-driven EJB simply implements a new set of interfaces that allow the EJB to receive and process JMS messages sent to a queue or a topic asynchronously by message producers. Clients to the EJB are constructed in the exact same fashion as JMS message producers are. Such JMS message producers do not know that the consumer of the message is implemented as an EJB. With this new style of EJB implementation, EJB developers have a new means for EJBs to asynchronously receive messages. This can come in handy for a whole class of applications when you want to create business logic that must scale within an EJB container but yet is loosely coupled to the client applications by a message-oriented middleware service.