4 Deploying MDBs
This section describes various approaches for deploying MDBs and the JMS destination to which the MDBs listen.
Destination and MDBs: Collocation vs. non-Collocation
You can deploy an MDB on the same server instance(s) as the JMS destination on which it listens or on separate server instance(s). These alternatives are referred to as collocation or non-collocation, respectively.
Collocated Destination/MDBs
Collocating an MDB with the destination to which it listens keeps message traffic local and avoids network round trips. Collocation is the best choice if you use WebLogic Server JMS and want to minimize message processing latency and network traffic.
You cannot collocate the MDB and the JMS destination if you use a third-party JMS provider that cannot run on WebLogic Server, such as MQ Series.
Figure 4-1 and Figure 4-2 illustrate architectures in which the MDB application is deployed to the server instance that hosts the associated JMS destination. These architectures vary in that the first has a distributed destination and the second does not. In an application that uses distributed destinations, the MDB is deployed to each server instance that hosts a member of the distributed destination set. For more information about distributed destinations, see JMS Distributed Destinations. As illustrated in Figure 4-1 the message "M1" is delivered to an instance of MDB_A on each server instance where a distributed destination and MDB_A are deployed. Figure 4-1 illustrates a One-Copy-Per-Server topic message distribution mode pattern. Topic patterns are discussed in more detail in Chapter 10, "Setting topicMessagesDistributionMode."
Figure 4-1 Collocated Destination/MDBs, Distributed Topic, One-Copy-Per-Server Pattern
Description of "Figure 4-1 Collocated Destination/MDBs, Distributed Topic, One-Copy-Per-Server Pattern"
Figure 4-2 Collocated Destination/MDBs, Non-Distributed Destination
Description of "Figure 4-2 Collocated Destination/MDBs, Non-Distributed Destination"
Non-Collocated Destination/MDBs
Figure 4-3 illustrates an architecture in which an MDB runs on a separate server instance than the JMS Destination to which the MDB listens.
Figure 4-3 Non-Collocated Application, Non-Distributed Destination
Description of "Figure 4-3 Non-Collocated Application, Non-Distributed Destination"
Running your MDBs on a separate server instance from the JMS Destination to which the MDB listens is suitable if:
-
Your application uses a 3rd-party JMS provider, such as MQ Series.
-
You want to isolate application code (the MDBs) from the JMS infrastructure. By placing JMS destinations and MDBs on separate server instances, you prevent application problems—for example, MDBs consuming all of your virtual machine's memory—from interrupting the operation of the JMS infrastructure.
-
Your MDB application is very CPU-intensive. On a separate machine, your application can use 100 percent of the CPU without affecting the operation of the JMS infrastructure.
-
One machine in your configuration has more processing power, disk space, and memory than other machines in the configuration.
The JMS destination and MDBs could also be deployed on non-clustered servers, servers within the same cluster, or to servers in separate clusters.
JMS Distributed Destinations
If your MDB application runs on a WebLogic Server cluster, you can configure multiple physical destinations (queues or topics) as a distributed destination, which appears to message producers and consumers to be a single destination.
If you configure a distributed destination, WebLogic JMS distributes the messaging load across available members of the distributed destination. If a member of the destination becomes unavailable due to a server failure, message traffic is re-directed to the other available physical destinations in the distributed destination set. You control whether an MDB that accesses a WebLogic distributed queue in the same cluster consumes from all distributed destination members or only those members local to the current WebLogic Server, using the distributed-destination-connection element in the weblogic-ejb-jar.xml file or the distributedDestinationConnection annotation. Similarly, this setting controls behavior for some topic MDB scenarios, as described in Chapter 10, "Configuring and Deploying MDBs Using JMS Topics," and Appendix A, "Topic Deployment Scenarios."
If you deploy an MDB and the associated distributed queue to the same cluster, WebLogic Server automatically enumerates the distributed queue members and ensures that each member is serviced by at least one MDB pool. For distributed queues, there will be one MDB pool for each local member when distributedDestinationConnection is LocalOnly (the default); otherwise, for queues, when distributedDestinationConnection is set to EveryMember, each WebLogic Server instance creates multiple local MDB pools - one for each local member plus one for each remote member.
If you deploy an MDB and its associated queue to different clusters, WebLogic Server automatically enumerates the distributed queue members and ensures that each member is serviced by an MDB pool on each server in the MDB cluster. For example, if the distributed queue has three members, each JVM in the MDB cluster will create three MDB pools.
For more information about distributed topics, see Chapter 10, "Configuring and Deploying MDBs Using JMS Topics."
Best Practice
WebLogic clustering, and WebLogic JMS distributed destinations increase scalability and high availability. Oracle recommends that the machines that host a cluster have identical or similar processing power, disk space, and memory to ensure well-load-balanced message processing. Similarly, it is recommended that the WebLogic Server instances in a particular WebLogic cluster have homogenous JMS configuration and MDB deployments.
For an example, see Figure 4-1. For additional information about distributed destinations, see "Using Distributed Destinations" in Programming JMS for Oracle WebLogic Server.