This section describes various approaches for deploying MDBs and the JMS destination to which the MDBs listen.
You can deploy an MDB on the same server instance as the JMS destination to which it listens, or on a separate server instance. These alternatives are referred to as collocation or non-collocation, respectively.
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-3 illustrates an architecture in which an MDB runs on a separate server instance than the JMS Destination to which the MDB listens.
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.
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
If you deploy an MDB and the associated distributed destination to the same cluster, WebLogic Server automatically enumerates the distributed destination members and ensures that there is an MDB listening on each member.
The MDBs are homogeneously deployed to each clustered server instance. Messages are distributed across the physical destinations on the multiple server instances, and are processed in parallel. If one server instance goes down, other nodes in the cluster can continue to process messages. This architecture is a good choice if:
Your application has high availability requirements.
You prefer to deploy applications homogeneously so that each server runs the same set of applications.
Your application processes a high volume of messages, or requires massively parallel processing.
The machines in your cluster have identical or similar processing power, disk space, and memory.