A Topic Deployment Scenarios

This appendix describes MDB deployment actions for various topic MDB configurations. The actions include where and how many MDB free pools are created, where and how many subscriptions are created, and how the subscribers work together to achieve a given messaging consumption pattern.

These sections do not cover details about legacy behavior which occurs when the topicMessagesDistributionMode is set to Compatibility, when the topics are foreign (non-WebLogic) topics, or when the topics are WebLogic JMS topics from WebLogic Server releases prior to 10.3.4.

For help determining the right scenario (permutation) for your application, including suggested settings, see Chapter 10, "Configuring and Deploying MDBs Using JMS Topics."

This appendix includes the following sections:

How Configuration Permutations Determine Deployment Actions
Typical Scenarios

How Configuration Permutations Determine Deployment Actions

The following settings determine how WebLogic MDBs that consume from WebLogic JMS topics (from WebLogic Server 10.3.4 or later) create instances of MDB free pools, subscription naming, subscription locations, and how messages are distributed to those MDB pool instances:

The topic location (in the same cluster or server as the MDB deployment or on a remote cluster or server).
The topic type (singleton WebLogic topic, Replicated or Partitioned distributed topic).
The subscriptionDurability setting.
The topicMessagesDistributionMode and distributedDestinationConnection settings.

Table A-1 describes possible configuration permutations and corresponding deployment actions. The first two columns describe the configuration permutations, and the last two columns describe the resulting deployment. The columns are as follows:

topicMessagesDistributionMode -- The value of the topicMessagesDistribution configuration option, that is, One-Copy-Per-Server or One-Copy-Per-Application. The legacy Compatibility mode is not covered in this table.
Topic Type Permutation -- Options include the following:
- Local or Remote -- Whether the topic is deployed to the same cluster or server as the MDB (Local) or to a different cluster or server (Remote).
- PDT, RDT, or Singleton WebLogic JMS topic -- The type of topic: partitioned distributed topic (PDT), replicated distributed topic (RDT), or singleton WebLogic JMS topic.
- EveryMember or LocalOnly -- The value of distributedDestinationConnection. Specifies whether the MDB that accesses a Local distributed topic in the same cluster consumes from all distributed topic members or only from those local to the current server. If neither EveryMember nor LocalOnly is specified, the permutation applies regardless of how distributedDestinationConnection is set.
For example, the topic type permutation "Local RDT LocalOnly" means "An MDB is deployed to the same cluster (Local) as the replicated topic (RDT), and the MDB is configured to consume only from members of the topic on the same WebLogic Server as the MDB (LocalOnly)."
Each Server Subscribes to... -- The number of MDB pools a WebLogic Server instance creates, and the members of the distributed topic to which the MDB instances subscribe. For example,
- "Each server subscribes to ... All members" means "the container creates one local MDB pool for each member of the distributed topic."
- "Each server subscribes to ... All local members" means "the container creates one MDB pool for each of the members that are running on the same server, and each MDB pool subscribes to one of those members."
MDB Pools Per Server -- The number of MDB deployment instances on each server in the cluster (and thereby the number of connections to the distributed topic members). M = the number of distributed topic members (M=1 for standalone topics).

Table A-1 Configuration Permutations and Their Resulting Deployment Actions

MDB Configuration		Deployment Actions
topicMessagesDistributionMode	Topic Type Permutation	Each Server Subscribes to...	MDB Pools per Server
`One-Copy-Per-Server`	RDT Local LocalOnly^Foot 1	One of the local members	One
`One-Copy-Per-Server`	RDT Remote (Non-durable only)^Foot 2	One of the remote members	One
`One-Copy-Per-Server`	PDT Local EveryMember^Foot 3 PDT Remote^Footref 2 RDT Local EveryMember RDT Remote (durable subscriptions only)^Footref 2 Singleton WebLogic JMS (`M`=`1`)	All members	M
`One-Copy-Per-Application`	PDT Local LocalOnly RDT Local LocalOnly	All local members	One per local member
`One-Copy-Per-Application`	PDT Local EveryMember PDT Remote^Footref 2 RDT Local EveryMember RDT Remote^Footref 2 Singleton WebLogic JMS (M=1)	All members	M

^Footnote 1The "One-Copy-Per-Server, RDT, Local, LocalOnly" permutation is not supported for durable subscription cases in some configuration topologies (See details in Scenario 1: Replicated DT, One Copy Per Server, Local Deployment, Local Only Consumption.)

^Footnote 2For remote distributed topics, WebLogic Server always creates subscriptions to every topic member except for non-durable subscriptions in the "One-Copy-Per-Server, Replicated Distributed Topic, Remote" permutation. In that case, only one subscription to one of the remote members is created. (See Scenario 3: Replicated DT, One Copy Per Server, Remote Deployment.)

^Footnote 3The LocalOnly setting is always automatically replaced with EveryMember in the "One-Copy-Per-Server, Partitioned Distributed Topic, Local" permutation. (See Scenario 7: Partitioned DT, One Copy Per Server, Local Deployment, Local Only Consumption.)

Typical Scenarios

The following sections show possible deployment scenarios of an MDB application:

Standalone (Non-distributed) Topic Scenarios
Replicated Distributed Topic Scenarios
Partitioned Distributed Topic Scenarios

Images and labels used in the figures presented in the scenarios are explained in Table A-2:

Table A-2 Explanation of Images and Text Used in Scenarios

Image or Text	Explanation
	Messages published to a distributed topic.
	Messages are duplicated, and copies are forwarded to other members of the topic. This indicates that the topics are replicated distributed topics.
DT Member n	Member of a distributed topic.
MDB Pool	An MDB free bean pool.
	A subscription. The MDB on one end of the arrow listens for and consumes messages from the topic on the other end of the arrow.
	Shared subscription.
	Non-shared subscription. S1 is Managed Server 1's subscription, S2 is Managed Server 2's subscription, etc.

Standalone (Non-distributed) Topic Scenarios

Standalone topic scenarios are as follows.

One-Copy-Per-Server

On each WebLogic Server instance that hosts the MDB application, an MDB pool is created for the topic, whether the topic is running in the same cluster or in a different cluster. For an MDB cluster of N nodes, N MDB pools are created. Each MDB pool creates an individual subscription on the topic, and subscribers from different MDB pools do not share the same subscription.

One-Copy-Per-Application

On each WebLogic Server instance that hosts the MDB application, an MDB pool is created for the topic, whether the topic is running in the same cluster or in a different cluster. For an MDB cluster of N nodes, N MDB pools are created. All subscribers created by the MDB pools of the same MDB application share the same subscription.

Replicated Distributed Topic Scenarios

With replicated distributed topics, all physical topic members receive each message sent. When a message arrives at one of the physical topic members, a copy of the message is automatically internally forwarded to the other members of the topic.

The following are the possible deployment scenarios for a replicated distributed topic:

Scenario 1: Replicated DT, One Copy Per Server, Local Deployment, Local Only Consumption
Scenario 2: Replicated DT, One Copy Per Server, Local Deployment, Every Member Consumption,
Scenario 3: Replicated DT, One Copy Per Server, Remote Deployment
Scenario 4: Replicated DT, One Copy Per Application, Local Deployment, Local Only Consumption
Scenario 5: Replicated DT, One Copy Per Application, Local Deployment, Every Member Consumption
Scenario 6: Replicated DT One Copy Per Application, Remote Deployment

Scenario 1: Replicated DT, One Copy Per Server, Local Deployment, Local Only Consumption

Figure A-1 shows the following configuration:

Replicated distributed topic
topicMessagesDistributionMode = One-Copy-Per-Server.
The MDB and the topic are deployed in the same (local) cluster.
distributedDestinationConnection = LocalOnly.

Figure A-1 Scenario 1: Replicated DT, One Copy Per Server, Local Deployment, Local Only Consumption

Description of ''Figure A-1 Scenario 1: Replicated DT, One Copy Per Server, Local Deployment, Local Only Consumption''

In this scenario:

Copies of messages are forwarded to other servers in the cluster by the RDT.
One MDB pool is created on each server in the local cluster.
Each MDB pool listens to one of the distributed topic member on the same server.

This approach can yield higher performance than "RDT, One Copy Per Server, Local Deployment, EveryMember," because all messaging is local (it avoids transferring messages over network calls) and still ensures that all distributed topic members are serviced by MDB consumers. However for some use cases, the EveryMember alternative may work better, based on the trade-offs discussed in Handling Uneven Message Loads and/or Message Processing Delays.

This scenario does not work correctly for durable subscriptions when there are multiple members on the same server, when there are no members on any of the local servers that host the MDB application, or when JMS service migration (auto or manual) is involved.

Scenario 2: Replicated DT, One Copy Per Server, Local Deployment, Every Member Consumption,

Figure A-2 shows the following configuration:

Replicated distributed topic
topicMessagesDistributionMode = One-Copy-Per-Server.
The MDB and the topic are deployed in the same (local) cluster.
distributedDestinationConnection = EveryMember.

Figure A-2 Scenario 2: Replicated DT, One Copy Per Server, Local Deployment, Every Member Consumption

Description of ''Figure A-2 Scenario 2: Replicated DT, One Copy Per Server, Local Deployment, Every Member Consumption''

In this scenario:

Copies of messages are forwarded to other servers in the cluster by the RDT, but these copies are filtered out (ignored) by the MDB subscriptions.
An MDB pool is created for each distributed topic member on each server in the local cluster.
Each MDB pool listens to one of the distributed topic members in the cluster.
Each WebLogic Server instance that hosts the MDB application listens to all members of the distributed topic.
Each server's subscribers on the same member of the DT have their own independent subscriptions. In other words, subscribers from different servers to the same member do not share any subscriptions.

This configuration yields high flexibility and is good for an application where an RDT is required, but it cannot be guaranteed that there will be exactly one member per server, for example due to migration.

This configuration does not give the best performance in comparison to Scenario 1: Replicated DT, One Copy Per Server, Local Deployment, Local Only Consumption, especially for a static environment where no migration is involved and there is one and only one member of the distributed topic on each managed server. Applications where no migration is involved and where there is one and only one member of the distributed topic on each managed server can use Scenario 1.

Scenario 3: Replicated DT, One Copy Per Server, Remote Deployment

Figure A-3 shows the following configuration:

Replicated distributed topic
Durable subscription
topicMessagesDistributionMode = One-Copy-Per-Server.
The MDB and the topic are deployed in different (remote) clusters.
distributedDestinationConnection ignored for remote deployments.

Figure A-3 Scenario 3: Replicated DT, One Copy Per Server, Remote Deployment

Description of ''Figure A-3 Scenario 3: Replicated DT, One Copy Per Server, Remote Deployment''

In this scenario:

Copies of messages are forwarded to other servers in the cluster by the RDT, but these copies are filtered out (ignored) by the MDB subscriptions.
An MDB pool for each distributed topic member is created on each server in the remote cluster.
Each WebLogic Server instance that hosts the MDB application listens to all members of the distributed topic (one local pool for each remote member).
Each server's subscribers on the same member of the DT have their own independent subscription. In other words, subscribers from different servers to the same member do not share any subscriptions.

Note that this is the behavior for durable cases. For non-durable cases, each WebLogic Server instance creates a single MDB pool which connects to one of the members (any member) as an optimization.

Scenario 4: Replicated DT, One Copy Per Application, Local Deployment, Local Only Consumption

Figure A-4 shows the following configuration:

Replicated distributed topic
topicMessagesDistributionMode = One-Copy-Per-Application.
The MDB and the topic are deployed in the same (local) cluster.
distributedDestinationConnection = LocalOnly.

Figure A-4 Scenario 4: Replicated DT, One Copy Per Application, Local Deployment, Local Only Consumption

Description of ''Figure A-4 Scenario 4: Replicated DT, One Copy Per Application, Local Deployment, Local Only Consumption''

In this scenario:

Copies of messages are forwarded to other servers in the cluster by the RDT, but these copies are filtered out (ignored) by the MDB subscriptions.
One MDB pool is created on each server in the local cluster for each local member (Figure A-5 shows a configuration where each WebLogic Server instance hosts only one member. When there are multiple members on the same local WebLogic Server instance, multiple MDB pools are created on the server).
A message is given to only one MDB pool.
All subscribers on the same member share the same subscription.

Scenario 5: Replicated DT, One Copy Per Application, Local Deployment, Every Member Consumption

Figure A-5 shows the following configuration:

Replicated distributed topic
topicMessagesDistributionMode = One-Copy-Per-Application.
The MDB and the topic are deployed in the same (local) cluster.
distributedDestinationConnection = EveryMember.

Figure A-5 Scenario 5: Replicated DT, One Copy Per Application, Local Deployment, Every Member Consumption

Description of ''Figure A-5 Scenario 5: Replicated DT, One Copy Per Application, Local Deployment, Every Member Consumption''

In this scenario:

Copies of messages are forwarded to other servers in the cluster by the RDT, but these copies are filtered out (ignored) by the MDB subscriptions.
One MDB pool is created on each server in the local cluster for each member.
A message is given to only one MDB pool.
All subscribers on the same member share the same subscription.

Scenario 6: Replicated DT One Copy Per Application, Remote Deployment

Figure A-6 shows the following configuration:

Replicated distributed topic
topicMessagesDistributionMode = One-Copy-Per-Application.
The MDB and the topic are deployed in different (remote) clusters.
distributedDestinationConnection ignored for remote deployments.

Figure A-6 Scenario 6: Replicated DT, One Copy Per Application, Remote Deployment

Description of ''Figure A-6 Scenario 6: Replicated DT, One Copy Per Application, Remote Deployment''

In this scenario:

Copies of messages are forwarded to other servers in the cluster by the RDT, but these copies are filtered out (ignored) by the MDB subscriptions.
One MDB pool is created on each server in the local cluster for each member in the remote cluster.
A message is given to only one MDB pool.
All subscribers on the same member share the same subscription.

Partitioned Distributed Topic Scenarios

With partitioned topics:

The distributed topic member receiving the message is the only member that is aware of the message. The message is not forwarded to other members, and subscribers on other members do not get a copy of the message.
Incoming messages can be load balanced among the distributed topic members using the JMS Affinity and Load Balance attributes. See "Load Balancing Partitioned Distributed Topics" in Administering JMS Resources for Oracle WebLogic Server.

The following are the possible deployment scenarios for a partitioned distributed topic:

Scenario 7: Partitioned DT, One Copy Per Server, Local Deployment, Local Only Consumption
Scenario 8: Partitioned DT, One Copy Per Server, Local Deployment, Every Member Consumption
Scenario 9: Partitioned DT, One Copy Per Server, Remote Deployment
Scenario 9: Partitioned DT, One Copy Per Application, Local Deployment, Local Only Consumption
Scenario 11: Partitioned DT, One Copy Per Application, Local Deployment, Every Member Consumption
Scenario 12: Partitioned DT, One Copy Per Application, Remote Deployment

Scenario 7: Partitioned DT, One Copy Per Server, Local Deployment, Local Only Consumption

The setting of distributedDestinationConnection is ignored for this scenario and a warning message is logged. The setting is forced to EveryMember instead. The behavior becomes the same as the "EveryMember" case (see "Scenario 8: Partitioned DT, One Copy Per Server, Local Deployment, Every Member Consumption").

Scenario 8: Partitioned DT, One Copy Per Server, Local Deployment, Every Member Consumption

Figure A-7 shows the following configuration:

Partitioned distributed topic
topicMessagesDistributionMode = One-Copy-Per-Server.
The MDB and the topic are deployed in the same (local) cluster.
distributedDestinationConnection = EveryMember.

Figure A-7 Scenario 8: Partitioned DT, One Copy Per Server, Local Deployment, Every Member Consumption

Description of ''Figure A-7 Scenario 8: Partitioned DT, One Copy Per Server, Local Deployment, Every Member Consumption''

In this scenario:

Messages are distributed individually to the distributed topic members. Messages are not duplicated or copied to other members in the cluster.
An MDB pool is created for each distributed topic member on each server in the local cluster.
Each server's subscribers on the same member of the DT have their own independent subscription. In other words, subscribers from a particular server to the same member do not share any subscriptions with subscribers from another server.

Scenario 9: Partitioned DT, One Copy Per Server, Remote Deployment

The details of this scenario are the same as the previous one except that the MDB deployment and the PDT are in different clusters.

Scenario 9: Partitioned DT, One Copy Per Application, Local Deployment, Local Only Consumption

Figure A-8 shows the following configuration:

Partitioned distributed topic
topicMessagesDistributionMode = One-Copy-Per-Application.
The MDB and the topic are deployed in the same (local) cluster.
distributedDestinationConnection = LocalOnly.

Figure A-8 Scenario 9: Partitioned DT, One Copy Per Application, Local Deployment, LocalOnly Consumption

Description of ''Figure A-8 Scenario 9: Partitioned DT, One Copy Per Application, Local Deployment, LocalOnly Consumption''

In this scenario:

Messages are distributed individually to the distributed topic members. Messages are not duplicated or copied to other members in the cluster.
One MDB pool is created on each server in the local cluster for each local member (Figure A-9 shows a configuration where each WebLogic Server hosts only one member. When there are multiple members on the same local WebLogic Server, multiple MDB pools are created on each WebLogic Server instance).

This scenario is the recommended configuration for One-Copy-Per-Application and Local PT for high performance. However for some use cases, the EveryMember alternative may work better, based on the trade-offs discussed in Handling Uneven Message Loads and/or Message Processing Delays.

Scenario 11: Partitioned DT, One Copy Per Application, Local Deployment, Every Member Consumption

Figure A-10 shows the following configuration:

Partitioned distributed topic
topicMessagesDistributionMode = One-Copy-Per-Application.
The MDB and the topic are deployed in the same (local) cluster.
distributedDestinationConnection = EveryMember.

Figure A-9 Scenario 11: Partitioned DT, One Copy Per Application, Local Deployment, Every Member Consumption

Description of ''Figure A-9 Scenario 11: Partitioned DT, One Copy Per Application, Local Deployment, Every Member Consumption''

For a partitioned distributed topic, one copy per application, local deployment, it is better to use LocalOnly consumption for most use cases, as shown in Scenario 9: Partitioned DT, One Copy Per Application, Local Deployment, Local Only Consumption. However the trade-offs discussed in Handling Uneven Message Loads and/or Message Processing Delays, apply here.

Scenario 12: Partitioned DT, One Copy Per Application, Remote Deployment

Figure A-10 shows the following configuration:

Partitioned distributed topic
topicMessagesDistributionMode = One-Copy-Per-Application.
The MDB and the topic are deployed in different (remote) cluster.
distributedDestinationConnection ignored for remote deployments.

Figure A-10 Scenario 12: Partitioned DT, One Copy Per Application, Remote Deployment

Description of ''Figure A-10 Scenario 12: Partitioned DT, One Copy Per Application, Remote Deployment''

In this scenario:

Messages are distributed individually to the distributed topic members. Messages are not duplicated or copied to other members in the cluster.
Subscriptions are created on all the distributed topic members automatically and dynamically.
A message is given to only one MDB pool.
All subscribers from the same MDB application on the same member share the same subscription.