WebLogic Messaging High Availability Features

13 Developing Advanced PubSub Applications 13-1 13 Developing Advanced PubSub Applications The following sections describe advanced WebLogic JMS publish and subscribe pubsub concepts and functionality of Uniform Distributed Topics UDTs necessary to design high availability applications: ■ Section 13.1, Overview of Advanced High Availability Concepts ■ Section 13.2, Advanced Messaging Features for High Availability ■ Section 13.3, Design Strategies when using Topics ■ Section 13.4, Best Practices for Distributed Topics

13.1 Overview of Advanced High Availability Concepts

The following sections provide information on WebLogic Server high availability features and concepts: ■ Section 13.1.1, WebLogic Messaging High Availability Features. ■ Section 13.1.2, Application Design Limitations When using Replicated Distributed Topics ■ Section 13.1.3, Advanced Topic Features

13.1.1 WebLogic Messaging High Availability Features

Oracle’s WebLogic messaging offer high availability HA and scalability using the following features: ■ Chapter 9, Using Distributed Destinations ■ Migration of JMS-related Services in Configuring and Managing JMS for Oracle WebLogic Server ■ Whole Server Migration in Using Clusters for Oracle WebLogic Server Distributed Destinations make a group of JMS physical destinations accessible as a single, logical destination to a client. Applications that use distributed destinations usually have higher availability and better scalability because WebLogic JMS provides load balancing and failover among member destinations of a distributed destination within a cluster. Automatic Service Migration ASM and Whole Server Migration WSM enable restarting either a set of services including JMS servers and Note: Oracle recommends designing applications that utilize WebLogic Server MDBs or the Oracle SOA JMS Adapter rather than explicitly handling all potential topology changes. 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