Application Design Limitations When using Replicated Distributed Topics Advanced Topic Features

13-2 Programming JMS for Oracle WebLogic Server destinations or an entire WebLogic Server instance in a new location. These migration features provide high availability for the individual members of a distributed destination. The nature of these technologies means that the topology of a JMS system can be unknown to a client application as: ■ The scaling of a cluster, along with the scaling of a distributed destination may exceed the number of consumers defined by the application. ■ The topology may dynamically change in the event of a server or service failure. Typically, topology changes are handled transparently using MDBs either locally or on a remote WebLogic Server instance. However, when using other client types, these topology changes must be explicitly handled by the application, especially if the application is remote to the servers hosting the JMS destinations.

13.1.2 Application Design Limitations When using Replicated Distributed Topics

Applications implementing Uniform Distributed Topics prior to WebLogic Server 10.3.4.0 were constrained by the following limitations: ■ Messages are always forwarded and duplicated across a distributed topic, which means that either parallel processing, andor ensuring that a clustered application gets exactly one copy of each message, may requires significant additional configuration, coding, and message hops. ■ Only one consumer at a time can process the messages in a given subscription except for the limited case of Non-XA MDBs where all processing of the subscription has to occur on the same server with a thread pool. This prevents most customers from designing application architectures that intend to have round-robin distributed or parallel processing of a single subscriptions topic messages, instead of single-threaded processing. ■ MDBs only directly support durable subscriptions on distributed topics that are located in the same cluster. ■ For applications other than MDBs, a durable subscriber created for a distributed topic can only be created on a distributed topic DT member, and the durable subscription will only exist on that member. If the member hosting the subscription is down, the subscription will not be available to any subscriber and is therefore not highly available by definition. ■ Pinning subscribers to a distributed topic member prevents automatic adjustment to changes in topology in the same way that adjustments are made for distributed queues.

13.1.3 Advanced Topic Features

Starting in WebLogic Server 10.3.4.0, partitioned distributed topics, combined with the ability to share subscriptions and allow multiple connections to use the same Client ID, provide the following application design patterns that provide parallel processing and HA capabilities similar to distributed queues: ■ One-copy-per-instance: Each instance of an application gets one copy of each message that is published to the Topic. ■ One-copy-per-application: Each application as a whole that is all instances of the application together receives one copy of each message that is published to the Topic. That is each instance only receives a subset of the messages that are sent to the Topic. Developing Advanced PubSub Applications 13-3

13.2 Advanced Messaging Features for High Availability