Oracle User Messaging Service Protection from Failures and Expected Behavior

Configuring High Availability for Oracle Fusion Middleware SOA Suite 5-59 WebLogic Server Administration Console or WLST. For more information, see UMS administration topics in Oracle Fusion Middleware Administrator’s Guide for Oracle SOA Suite. If you are using Oracle SOA Suite in a clustered environment, any configuration property changes you make in Oracle Enterprise Manager on one node must be made on all nodes. Configuration properties are set in Oracle Enterprise Manager through the following options of the SOA Infrastructure menu: Administration System MBean Browser SOA Administration any property selections.

5.9.2 Oracle User Messaging Service High Availability Architecture and Failover Considerations

See Section 5.2.2, Oracle SOA Service Infrastructure High Availability Architecture and Failover Considerations for a description of the Oracle SOA Service Infrastructure two-node high availability characteristics. Figure 5–6 illustrates an Oracle SOA Service Infrastructure cluster running on two WebLogic Servers. Oracle User Messaging Service is deployed as part of the Oracle SOA Service infrastructure composite application. The following high availability characteristics are specific to an Oracle User Messaging Service high availability deployment: ■ All UMS components are deployed to Oracle WebLogic Service Infrastructure managed servers that are part of an Oracle WebLogic Server cluster. An Oracle WebLogic Server cluster synchronizes configuration for common artifacts of Oracle WebLogic Server used by UMS, such as JDBC data sources. ■ All Oracle UMS components are stateless. ■ UMS Server and Client stateless EJBs leverage clustering and high availability capabilities of Oracle WebLogic Server cluster ■ UMS Server relies on a shared database repository for persistent storage. ■ UMS relies on JMS distributed destinations for load balancing and availability across cluster nodes. It also relies on the JMS connection factorys capability to failover to a different JMS server if a failure occurs. ■ The user messaging preferences user interface does not require session stickiness. It remains available through the use of a basic load balancing. There are no sticky session routing requirements, as all session state is persisted in the database and shared across the clustered instances. ■ UMS does not participate in any global transactions. ■ UMS uses Oracle WebLogic Server multi data source to connect to the back-end Oracle RAC database.

5.9.2.1 Oracle User Messaging Service Protection from Failures and Expected Behavior

Oracle UMS is typically deployed on the same managed server as the Oracle SOA Service Infrastructure. The Oracle SOA Service Infrastructure is protected from process and node failures using Oracle WebLogic Server whole server migration. Whole server migration also provides failover capabilities for JMS usage. For information about Oracle UMS protection from failures and expected behavior, see Section 5.2.2.1, Oracle SOA Service Infrastructure Protection from Failures and Expected Behavior . 5-60 Oracle Fusion Middleware High Availability Guide Process Failure This section describes specific considerations for process failure in an Oracle User Messaging Service high availability configuration: ■ Node Manager attempts to restart the managed servers locally if a crash occurs. ■ If whole server migration is configured for the Oracle WebLogic Server managed server to which Oracle UMS components are deployed, and the restart count threshold is exceeded, Oracle WebLogic Server infrastructure attempts to perform a server migration of the managed server to another node in the cluster. After the server migration completes successfully, at the startup time, UMS Server and Drivers go through the startup cycle as previously described, including driver registration. Driver registration is an independent operation and does not have any affect on other available instances. See Chapter 3, High Availability for WebLogic Server for more information about server migration. ■ At restart on the same or different node, the UMS JMS server in the managed server starts producing and consuming messages from its JMS store. ■ If a managed server running UMS Server and Drivers is restarted or migrated, the failover is transparent to the connected UMS Clients. The failover is transparent because UMS components are stateless. Once the servers restart is finished, the Web server starts routing requests to it for Web service clients. Similarly, EJB clients become aware of the server availability and start routing requests to it. This is made possible by Oracle WebLogic clustering infrastructure. Node Failure For information about Oracle UMS node failure, see Section 5.2.2.1, Oracle SOA Service Infrastructure Protection from Failures and Expected Behavior Database Failure For information about Oracle UMS database failure, see Section 5.2.2.1, Oracle SOA Service Infrastructure Protection from Failures and Expected Behavior Protection From External Messaging Gateway Failures Before attempting a message delivery, UMS first persists the message to the database. If an external Messaging Gateway becomes unavailable, the corresponding UMS driver periodically attempts to reconnect to the gateway and deliver any undelivered messages persisted in the database. Alternatively, if the messages are not delivered, administrators can manually resend the messages using the UMS servers Message Status Page in Oracle Fusion Middleware Enterprise Manager.

5.9.2.2 Oracle User Messaging Service Cluster-Wide Configuration Changes