Configuring Distributed Notifications for the MDS Repository

5-54 Oracle Fusion Middleware High Availability Guide Node Failure If node failure occurs and whole server migration is not configured, the Oracle WSM Agent fails over transparently to the other Policy Manager instance. If whole server migration is configured, server migration is triggered after the available server verifies the time stamp in the database leasing system. After the time stamp for leasing is verified, the Node Manager in the node that still remains available attempts to migrate the VIP used by the failed managed server, and restarts it locally. This effectively results in the Oracle WSM Policy Manager application having two instances running in the same node. Refer to the Section 3.9, Whole Server Migration for more details on the failover process. In this situation, the Oracle WSM Agents load balance against both Policy Manager instances running on the same node.

5.8.2.2 Oracle WSM Cluster-Wide Configuration Changes

The standard Java EE artifacts that Policy Manager uses are configured as part of the Oracle WebLogic domain in which the Oracle SOA Service Infrastructure is installed. Oracle WebLogic Clusters provide automatic configuration synchronization for artifacts, such as data sources, across the WebLogic Server domain. At the same time, the WebLogic Server cluster controls synchronizing the deployments and libraries used by different Oracle WSM components. As explained in the single-instance section, Oracle WSM instance specific aspects are configured individually per WebLogic Server domain directory typically one per node through the policy-accessor-config.xml file. This file is included in the .jar file that is created when using the Oracle WebLogic Server Pack utility, therefore it is propagated to other nodes when you run packunpack to set up high availability for the Oracle SOA Service Infrastructure. However, ongoing changes to policy-accessor-config.xml are not replicated automatically to the other nodes. This implies that for updates, you must modify each node individually, for example, if you updated the Policy Manager URL or Cache Refresh Interval. These modifications must be manually performed in all the domain directories across a high availability topology. You can edit the policy-accessor -config.xml file directly, or use Oracle Enterprise Manager Fusion Middleware Control to make the configuration change on each managed server. Oracle WSM Agents are capable of automatically discovering the deployed Oracle WSM Policy Manager deployments. If you want to override the behavior and some point to a specific Policy Manager instance, you can do so by editing the policy-accessor-config.xml file.

5.8.2.3 Configuring the Java Object Cache for Oracle WSM

The Java Object Cache JOC should be configured among all the servers running Oracle WSM. This local cache is provided to increase the performance of Oracle WSM. For instructions on configuring the Java Object Cache among all the servers running Oracle WSM, see Section F.1, Configuring the Java Object Cache.

5.8.2.4 Configuring Distributed Notifications for the MDS Repository

In high availability environments, Oracle recommends that you configure distributed notifications for the MDS repository. For instructions on configuring distributed notifications for the MDS repository, see Appendix G, Configuring Distributed Notifications for MDS. Configuring High Availability for Oracle Fusion Middleware SOA Suite 5-55

5.9 Oracle User Messaging Service and High Availability Concepts

The information in this section guides you through the issues and considerations necessary for configuring Oracle User Messaging Service for high availability.

5.9.1 Oracle User Messaging Service Single-Instance Characteristics

Oracle User Messaging Service Oracle UMS enables two way communication between users and deployed applications. It has support for a variety of channels, such as email, IM, SMS, and text-to-voice messages. Oracle UMS is integrated with Oracle Fusion Middleware components, such as Oracle BPEL PM, Oracle Human Workflow, Oracle BAM and Oracle WebCenter. It is typically deployed along with the Oracle SOA Service Infrastructure. Oracle UMS is made up of the following components: ■ UMS Server is a Java EE application that runs on Oracle WebLogic Server. The UMS Server orchestrates message flows between applications and users. The server routes outbound messages from a client application to the appropriate driver, and routes inbound messages to the correct client application. The server also maintains a repository of previously sent messages in a persistent store, and correlates delivery status information with previously sent messages. ■ UMS Drivers connect UMS to the messaging gateways, adapting content to the various protocols supported by UMS. Drivers can be deployed or undeployed independently of one another depending on the messaging channels available in a given installation. UMS Drivers adapt sent and received content to and from external protocols, such as email, XMPP, and SMPP. UMS Drivers are also Java EE applications deployed to an Oracle WebLogic Server. ■ UMS Client applications implement the business logic of sending and receiving messages. Examples of a UMS client application include an Oracle SOA application that sends messages as one step of an Oracle BPEL PM workflow, or an Oracle WebCenter Spaces application that can send messages from a Web interface. UMS client applications have either a UMS-specific EJB module embedded in them, or interact as standard Web service clients. Figure 5–28 illustrates the services and dependencies of an Oracle UMS single-instance architecture.