Deploying MDBs

Destination and MDBs: Collocation vs. non-Collocation

You can deploy an MDB on the same server instance as the JMS destination on which it listens or on separate server instance. When you deploy an MDB on the same server instance as the JMS destination on which it listens it is referred to as collocation and when you deploy and MDB on a separate server instance it is referred as non-collocation.

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 Oracle 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 Oracle 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 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

Examine the non-colloacated destination/MDBs in which an MDB runs on a different server instance from the JMS Destination. It is best suited for applications that use a third-party JMS provider or if you want to isolate application code (the MDBs) from the JMS infrastructure.

Figure 4-3 illustrates an architecture in which an MDB runs on a different server instance from 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 different server instance from the JMS Destination to which the MDB listens is suitable if:

Your application uses a third-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.

Note:

WebLogic Server does not support non-collocated Destination/MDBs in a cluster when you deploy the destination on a target that can be migrated.

JMS Distributed Destinations

When an MDB application runs on an Oracle 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 Oracle 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 Configuring and Deploying MDBs Using JMS Topics, and Topic Deployment Scenarios.

If you deploy an MDB and the associated distributed queue to the same cluster, Oracle 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 Oracle 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, Oracle 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 Configuring and Deploying MDBs Using JMS Topics.

Best Practice

WebLogic clustering and WebLogic JMS distributed destinations increase scalability and high availability. Examine some of the best practices to 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 Oracle 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 Developing JMS Applications for Oracle WebLogic Server.