Message Driven Beans consume messages from predefined JMS Topics or Queues. Applications that may need to utilize several Message Driven Beans to handle various messages are faced with a problem of defining a number of JMS destinations and implementing different MDBs to listen to them. This may cause the Application Server to be cluttered with a variety of JMS resources and MDB deployments that perform potentially similar operations.
A solution to this issue can be the Message Driven Bean Proxy pattern. It should be applied to the situations where multiple message types need to be processed by an application and MDBs consuming them may or may not access shared business logic components to complete their work. MDBs performing highly specialized tasks, processing large amounts of data, or desiring to meet very high performance criteria should be excluded. The solution establishes a single application-wide MDB listening to a JMS Topic or Queue as a proxy for the specific operations that need to be performed in response to the message arrival. In this scenario, a single MDB will be responsible for handling all the messages for an application. The decision what functionality to execute will be based on the message properties assigned to it by the sender.
A factory pattern can be utilized to encapsulate the decision making process. When a message is received by the MDB, a factory mechanism is called to create a specific class that will perform all the necessary message handling. The factory class -- Message Handling Factory -- is responsible for instantiating the correct processing class -- Message Handling Class. Each message type should have a corresponding Message Handling Class that performs necessary operations.
When implementing the MDB Proxy pattern, the client sending a JMS message needs to set message properties with specific data uniquely identifying the message. The Message Handling Factory can decide which Message Handling Class to create based on these properties. Message properties are set and extracted through methods exposed in the JMS Message interface. Each Message Handling Class should contain the logic specific to the particular message type that it is processing. They, however, should not implement any business logic but instead call appropriate methods of business logic components. See Message Driven Bean Strategy pattern for more information. This approach limits the proxy MDB’s job to creating a Message Handling Factory, instantiating a new Message Handling Class through it and passing the received message to the class for processing.
This pattern eliminates the need for creating multiple JMS destinations and MDB implementations for an application and establishes a common message handling framework. When a new message type is created, the only thing that needs to be done is develop a new instance of the Message Handling Class and update Message Handling Factory logic. This, however, introduces a need to re-deploy and re-test the proxy Bean but this operation should be more efficient than deploying and testing a new Message Driven Bean. A single JMS destination and MDB per application concept may create performance issues but a good load balancing or clustering technique can remedy the situation.
