Oracle Service Bus Cluster-Wide Deployment Online Redeployment of Oracle Service Bus in a Cluster Oracle Service Bus Cluster-Wide Configuration Changes

5-92 Oracle Fusion Middleware High Availability Guide they are inserted into the database. If the database fails in the middle of LLR transaction processing, transaction recovery is performed as described in the chapter on Logging Last Resource Transaction Optimization in Oracle Fusion Middleware Programming JTA for Oracle WebLogic Server.

5.12.2.2 Oracle Service Bus Cluster-Wide Deployment

Oracle Service Bus resources are updateddeployed onto the WebLogic Administration Server. The Administration Server uses the WebLogic deployment service to propagate the Oracle Service Bus resources to all the managed servers in the cluster.

5.12.2.3 Online Redeployment of Oracle Service Bus in a Cluster

Oracle Service Bus resources do not have the notion of versions. When a resource is updated, it is as if a new version is deployed and the older version is overwritten. The configuration framework makes changes to resources in a session, which is a copy of the core that all managed servers are currently using when the session is created. When the session is committed, the core is updated with the changes. The changes are then propagated in a transactional manner to the managed servers in the cluster. In-flight requests requests already executing the Proxy Service Message flow continue to use the old copy of the resources when the update is in progress. Requests after the changes are added to the core use the updated resources.

5.12.2.4 Oracle Service Bus Cluster-Wide Configuration Changes

Oracle Service Bus resources are updated at the cluster level. The WebLogic Administration Server propagates these changes to all the managed servers in the cluster. You can make configuration changes using the Oracle Service Bus web console, the WebLogic Server Administration Console, and public MBeans. The following files are excluded from the automatic propagation to the managed servers in the cluster: ■ Files in the DOMAIN_HOMEconfigosbcoherence directory ■ DOMAIN_HOMEconfigosbtransportssftpknown_hosts Each managed server must have access to the DOMAIN_HOME to access files in these directories. 5.13 Configuring High Availability for Oracle SOA Service Infrastructure and Component Service Engines The procedures described in this section include setting up the Service engines contained in the Oracle SOA Service Infrastructure system, such as Oracle BPELOracle PM, Oracle Mediator, Oracle Human Workflow and Oracle Decision Services, as well as Oracle B2B and Oracle User Messaging Service. This section includes these topics: ■ Section 5.13.1, Preparing the Environment: Prerequisite Steps Before Setting up a SOA High Availability Configuration Note: For detailed instructions on installing and configuring Oracle Service Bus in a high availability configuration, see Section 5.14, Configuring High Availability for Oracle Service Bus, with SOA Service Infrastructure and Component Service Engines. Configuring High Availability for Oracle Fusion Middleware SOA Suite 5-93 ■ Section 5.13.2, Installing Oracle Fusion Middleware Home ■ Section 5.13.3, Enabling VIP1 in SOAHOST1 and VIP2 in SOAHOST2 ■ Section 5.13.4, Running Oracle Fusion Middleware Configuration Wizard on SOAHOST1 to Create the SOA Domain ■ Section 5.13.5, Creating boot.properties for the Administration Server on SOAHOST1 ■ Section 5.13.6, Starting and Validating the Administration Server in SOAHOST1 ■ Section 5.13.7, Disabling Host Name Verification for the Administration Server and the WLS_SOAn Managed Servers ■ Section 5.13.8, Configuring Oracle Coherence for Deploying Composites ■ Section 5.13.9, Setting Connection Destination Identifiers for B2B Queues ■ Section 5.13.10, Starting the System in SOAHOST1 ■ Section 5.13.11, Propagating the Domain Configuration to SOAHOST2 with packunpack Utilities ■ Section 5.13.12, Extracting XEngine Files in the Second Node ■ Section 5.13.13, Starting the System in SOAHOST2 ■ Section 5.13.14, Configuring Oracle HTTP Servers for the Administration Server and the WLS_SOAn Managed Servers ■ Section 5.13.15, Validating Access Through Oracle HTTP Server ■ Section 5.13.16, Configuring JMS Persistence Store as Shared Across the Servers ■ Section 5.13.17, Configuring a Default Persistent Store for Transaction Recovery ■ Section 5.13.18, Setting the Front End HTTP Host and Port ■ Section 5.13.19, Setting the WLS Cluster Address for Direct BindingRMI Invocations to Composites ■ Section 5.13.20, Deploying Applications ■ Section 5.13.21, Configuring Server Migration for the WLS_SOA Servers ■ Section 5.13.22, Scaling the Topology Note: Oracle strongly recommends reading the release notes for any additional installation and deployment considerations prior to starting the setup process. Note: The architectures and deployment procedures defined in this guide enable simple clustered deployments. The procedures described in these chapters can be used as a building block to enable this and other similar high availability topologies for these Fusion Middleware components. It is also expected that production deployments will use other required procedures, such as associating security policies with a centralized LDAP server. For complete details of secured, multi-tiered architectures, and deployment procedures, please refer to the Enterprise Deployment Guide for the component you are configuring. 5-94 Oracle Fusion Middleware High Availability Guide Figure 5–42 represents the example architecture that the configuration steps in this section create. Figure 5–42 Oracle SOA Service Infrastructure High Availability Architecture Figure 5–42 describes a two-node SOA cluster running on two Oracle WebLogic Servers. The Oracle WebLogic Servers are frontended by Oracle HTTP Servers, which load balance incoming requests. A load balancer front ends the system and distributes incoming requests from clients to the two Oracle HTTP Servers. A separate Oracle WebLogic Server not shown in the figure is typically used for custom logic and application deployment. This configuration uses an Oracle RAC database for storing metadata and SOA schemas, and shared storage for transaction and JMS stores. Virtual IP addresses VIPs provide manual failover for the Administration Server and for Oracle SOA Servers for Server Migration. For more details about the components contained in this architecture, see the individual component sections in this chapter. Internet Load Balancer SOAHOST1 SOAHOST2 Coherence Cluster Firewall 1 Firewall 2 WLS Cluster WLS_SOA1 SOA-infra Admin Server VIP0 WLS_SOA2 SOA-infra Admin Server VIP1 VIP2 VIP WEBHOST2 OHS WEBHOST1 OHS RAC TLogs JMS - MDS - SOA Configuring High Availability for Oracle Fusion Middleware SOA Suite 5-95 For information about configuring virtual IPs for the Administration Server and configuring the Administration Server for high availability, see Section 12.2.2.3, Transforming the Administration Server for Cold Failover Cluster. 5.13.1 Preparing the Environment: Prerequisite Steps Before Setting up a SOA High Availability Configuration The following sections provide prerequisite steps before setting up an Oracle SOA Service Infrastructure high availability configuration. For information about platform-specific commands, see the Oracle Fusion Middleware Installation Guide for Oracle SOA Suite and Oracle Business Process Management Suite. ■ Section 5.13.1.1, Database Prerequisites