13 Extending the Domain with Oracle Service Bus

This chapter describes the procedures for extending the domain to include Oracle Service Bus (OSB).

This chapter contains the following sections.

13.1 Variables Used in This Chapter

As you perform the tasks in this chapter, you will be asked to enter the following values for several directory variables defined in Section 7.4, "File System and Directory Variables Used in This Guide".

  • ORACLE_HOME

  • ASERVER_HOME

  • MSERVER_HOME

  • JAVA_HOME

In addition, you'll be referencing the following virtual IP (VIP) addresses defined in Section 5.2.3, "Physical and Virtual IP Addresses Required by the Enterprise Topology":

  • ADMINVHN

  • SOAHOST1VHN1

  • SOAHOST1VHN2

  • SOAHOST2VHN1

  • SOAHOST2VHN2

Actions in this chapter will be performed on the following host computers:

  • SOAHOST1

  • SOAHOST2

  • WEBHOST1

  • WEBHOST2

13.2 Overview of Adding Oracle Service Bus to a SOA Domain

This section provides an overview of adding Oracle Service Bus to a SOA domain. Table 13-1 lists and describes to high-level steps for extending a SOA domain for Oracle Service Bus.

Table 13-1 Steps for Extending a SOA Domain to Include Oracle Service Bus

Step Description More Information

Install Oracle Service Bus software

Install OSB software on the target system.

Section 13.5, "Installing Oracle Service Bus Software"

Enable VIP4 on SOAHOST1 and VIP5 on SOAHOST2

Enable a virtual IP mapping for each of these hostnames on the two SOA Machines.

Section 13.4, "Preparing to Extend the Domain with Oracle Service Bus"

Run the Configuration Wizard to Extend the Domain

Extend the SOA domain to contain Oracle Service Bus components

Section 13.6, "Extending the SOA Domain to Include Oracle Service Bus"

Configure a Default Persistence Store for Transaction Recovery

To leverage the migration capability of the Transaction Recovery Service for the servers within a cluster, store the transaction log in a location accessible to a server and its backup servers.

Section 13.7, "Configuring a Default Persistence Store for Transaction Recovery"

Propagate the Domain Configuration to the Managed Server Directory in SOAHOST1 and to SOAHOST2

Oracle Service Bus requires some updates to the WebLogic Server start scripts. Propagate these changes using the pack and unpack commands.

Section 13.8, "Propagating the Extended Domain to the Domain Directories and Machines"

Start the Oracle Service Bus Servers

Oracle Service Bus servers extend an already existing domain. As a result, the Administration Server and respective Node Managers are already running in SOAHOST1 and SOAHOST2.

Section 13.8.2, "Starting and Validating the WLS_OSB1 Managed Server"

Validate the WLS_OSB Managed Servers

Verify that the server status is reported as Running in the Admin Console and access URLs to verify status of servers.

Section 13.8.3, "Starting and Validating the WLS_OSB2 Managed Server"

Configuring Oracle HTTP Server for the WLS_OSBn Managed Servers

To enable Oracle HTTP Server to route to Oracle Service Bus console and Oracle Service Bus service, set the WebLogicCluster parameter to the list of nodes in the cluster.

Section 13.9, "Configuring Oracle HTTP Server for the Oracle Service Bus"

Validating Access Through Oracle HTTP Server

Verify that the server status is reported as Running.

Section 13.11, "Validating the Oracle Service Bus URLs Through the Load Balancer"

Enable High Availability for Oracle File and FTP Adapters

Make Oracle File and FTP Adapters highly available for outbound operations using the database mutex locking operation.

Section 13.12.1, "Enabling High Availability for Oracle DB, File and FTP Adapters"

Backing up the Oracle Service Bus Configuration

To back up the domain configuration for immediate restoration in case of failures in future procedures.

Section 13.12.4, "Backing Up the Oracle Service Bus Configuration"

13.3 Prerequisites for Extending the SOA Domain to Include Oracle Service Bus

Before extending the current domain, ensure that your existing deployment meets the following prerequisites:

  • Back up the installation - If you have not yet backed up the existing Fusion Middleware Home and domain, Oracle recommends backing it up now.

    To back up the existing Fusion Middleware Home and domain, see Section 18.2.6, "Performing Backups and Recoveries in the SOA Enterprise Deployments."

  • You have installed the software binaries in an Oracle home on shared storage and they are available from SOAHOST1 and SOAHOST2.

  • If Oracle Service Bus is installed after SOA, the appropriate SOAINFRA schema (used by the wlsbjmsrpDataSource) will be already available. If OSB is installed without SOA, RCU needs to be executed to seed the SOAINFRA schema.

  • You have already configured Node Manager, Administration Server, (optionally SOA Servers) and WSM Servers as described in previous chapters to run a SOA system. Optionally, you may have already configured Server migration, transaction logs, coherence, and all other configuration steps for the SOA System.

13.4 Preparing to Extend the Domain with Oracle Service Bus

Before you extend the domain to include Oracle SOA Suite, be sure to perform the following tasks:

13.4.1 Verifying the IP Addresses and Virtual Host Names for Oracle Service Bus on SOAHOST1 and SOAHOST2

Verify that the required SOAHOST1VHN2 and SOAHOST2VHN2 virtual IP addresses are procured and available. You can do this by performing a network ping of each virtual host name and verifying the ping is successful.

If the virtual IPs are not available, contact your network administrator and make sure the virtual IPs are available before you begin the steps in this chapter.

13.4.2 Synchronizing the System Clocks

If you haven't done so already, verify that the system clocks on each host computer are synchronized. You can this by running the date command as simultaneously as possible on the hosts in each cluster.

Alternatively, there are third-party and open-source utilities you can use for this purpose.

13.5 Installing Oracle Service Bus Software

To start the installation program, perform the following steps.

  1. Log in to the target system, SOAHOST1.

  2. Go to the directory in which you downloaded the installation program.

  3. Set the path for the java executable:

    export JAVA_HOME=JAVA_HOME
export PATH=$JAVA_HOME/bin:$PATH

    In this example, replace JAVA_HOME with the value this variable listed in Section 7.4, "File System and Directory Variables Used in This Guide" and entered in the Enterprise Deployment Workbook.

  4. Launch the installation program by entering the following command:

    java -d64 -jar fmw_12.1.3.0.0_osb.jar

    When the installation program appears, you are ready to begin the installation.

13.5.1 Navigating the OSB Installation Screens

Table 13-2 provides description of each installation program screen.

Table 13-2 SOA Installation Screens

Screen Description

Welcome

This screen introduces you to the product installer.

Installation Location

Use this screen to specify the location of your Oracle home directory. For the Oracle Home specify /u01/oracle/products/fmwnnnn

Installation Type

Use this screen to select the type of installation and consequently, the products and feature sets you want to install.

For this topology, select Service Bus.

Prerequisite Checks

This screen verifies that your system meets the minimum necessary requirements.

If there are any warning or error messages, you can refer to one of the following documents in Section 1.4.

Installation Progress

This screen allows you to see the progress of the installation.

Installation Complete

This screen appears when the installation is complete. Review the information on this screen, then click Finish to dismiss the installer.

13.5.2 Installing Oracle SOA Suite on the Other Host Computers

If you have configured a separate shared storage volume or partition for SOAHOST2, then you must also install the software on SOAHOST2. For more information, see Section 7.2, "Shared Storage Recommendations When Installing and Configuring an Enterprise Deployment".

Note that the location where you install the Oracle home (which contains the software binaries) will vary, depending upon the host. To identify the proper location for you Oracle home directories, refer to the guidelines in Section 7.4, "File System and Directory Variables Used in This Guide".

13.5.3 Verifying the Installation

After you complete the installation, you can verify it by successfully completing the following tasks:

13.5.3.1 Reviewing the Installation Log Files

Review the contents of the installation log files to make sure that no problems were encountered. For a description of the log files and where to find them, see "Understanding Installation Log Files" in Installing Software with the Oracle Universal Installer.

13.5.3.2 Checking the Directory Structure

The contents of your installation vary based on the options you selected during the installation.

The addition of Oracle Service Bus adds the following directory and sub-directories:

ORACLE_HOME/osb/

bin
common
config
doc
financial
L10N
lib
osb
plugins
tools

For more information about the directory structure you should see after installation, see "What are the Key Oracle Fusion Middleware Directories?" in Understanding Oracle Fusion Middleware.

13.5.3.3 Viewing the Contents of Your Oracle Home

You can also view the contents of your Oracle home using the viewInventory script. For more information, see "Viewing the contents of an Oracle home" in Installing Software with the Oracle Universal Installer.

13.6 Extending the SOA Domain to Include Oracle Service Bus

This section provides instructions for extending the existing enterprise deployment SOA domain with the Oracle Service Bus.

Extending the domain involves the following:

13.6.1 Starting the Configuration Wizard

Note:

If you added any customizations directly to the start scripts in the domain, those will be overwritten by the configuration wizard. To customize server startup parameters that apply to all servers in a domain, you can create a file called setUserOverrides.sh and configure it, for example, add custom libraries to the WebLogic Server classpath, specify additional java command line options for running the servers, or specify additional environment variables. Any customizations you add to this file are preserved during domain upgrade operations, and are carried over to remote servers when using the pack and unpack commands.

To begin domain configuration:

  1. Shut down the Administration Server to prevent any configuration locks, saves, or activations from occurring during the configuration of the domain.

    For more information, see the instructions for shutting down the Administration Server with Node Manager in Section 11.3.1.

  2. Navigate to the following directory and start the WebLogic Server Configuration Wizard.

    ORACLE_HOME/oracle_common/common/bin
./config.sh

13.6.2 Navigating the Configuration Wizard Screens to Create the Domain

In this step, you extend the domain created in Chapter 12, "Extending the Domain with Oracle SOA Suite," to contain Oracle Service Bus components. The steps reflected in this section would be very similar if Oracle Service Bus was extending a domain containing only an Administration Server and a WSM-PM Cluster, but some of the options, libraries and components shown in the screens could vary.

Domain creation and configuration includes the following tasks:

Task 1   Selecting the Domain Type and Domain Home Location

On the Configuration Type screen, select Update an existing domain.

In the Domain Location field, select the value of the ASERVER_HOME variable, which represents the complete path to the Administration Server domain home you created in Chapter 10.

For more information about the directory location variables, see Section 7.4, "File System and Directory Variables Used in This Guide"

Tip:

More information about the other options on this screen can be found in Configuration Type in Creating WebLogic Domains Using the Configuration Wizard.
Task 2   Selecting the Configuration Template

On the Templates screen, make sure Update Domain Using Product Templates is selected, then select the following template:

Oracle Service Bus - 12.1.3.0 [osb]

This automatically selects the Weblogic Advanced Web Services for JAX-RPC Extension 12.1.3 oracle_common and ODSI XQuery 2004 Components - 12.1.3.0 [oracle_common].

Click Next.

Task 3   Specifying the Datasource Configuration Type

Note:

Any custom datasources that were created before the extension (like LEASING datasources) will show up before this screen. Check the Datasources row and click Next. The test datasource screen will verify its validity. Click Next.

All fields are pre-populated, because you already configured the domain to reference the Fusion Middleware schemas that are required for the Infrastructure domain. Verify and ensure that credentials in all the fields are the same that you have provided while configuring Oracle Fusion Middleware Infrastructure.

Click Get RCU Configuration after you finish verifying the database connection information. The following output in the Connection Result Log indicates that the operation succeeded:

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK
Successfully Done.

Tip:

More information about the RCU Data option can be found in "Understanding the Service Table Schema" in Creating Schemas with the Repository Creation Utility.

More information about the other options on this screen can be found in "Datasource Defaults" in Creating WebLogic Domains Using the Configuration Wizard.

Task 4   Specifying JDBC Component Schema Information

Select the OSB JMS Reporting component schema, click the Convert to Gridlink option and click Next.

Click Next.

Task 5   Providing the GridLink Oracle RAC Database Connection Details

On the GridLink Oracle RAC Component Schema screen, provide the information required to connect to the RAC database and component schemas, as shown in Table 10-3 and in Figure 10-2.

Remember to use the SCAN address for the database for the Service Listener and ONS Host fields.

Task 6   Testing the JDBC Connections

On the Test JDBC Data Sources screen, confirm that all connections were successful.

The connections are tested automatically. The Status column displays the results. If all connections are not successful, click Previous to return to the previous screen and correct your entries.

Click Next when all the connections are successful.

Task 7   Selecting Advanced Configuration

On the Select Advanced Configuration screen, select the following:

  • Managed Servers, Clusters, and Coherence

  • JMS File Store

Click Next.

Task 8   Configuring Managed Servers

On the Managed Servers screen, add the required managed servers for Oracle Service Bus.

  • Select the automatically created server and click Rename to change the name to WLS_OSB1.

  • Click Add to add another new server and enter WLS_OSB2 as the server name.

  • Give servers WLS_OSB1 and WLS_OSB2 the attributes listed in Table 13-3.

  • Select OSB-MGD-SVRS-ONLY as the server group for the OSB Servers. Deselect OSB-MGD-SVRS-COMBINED that is selected by default.

In the end, the configuration for the added servers should match Table 13-3.

Click Next.

Table 13-3 Configuring the Oracle Service Bus Managed Servers in the Configuration Wizard

Name Listen Address Listen Port SSL Listen Port SSL Enabled Server Groups

WLS_SOA1Foot 1 

SOAHOST1VHN1

8001

n/a

No

SOA-MGD-SVRS-ONLY

WLS_SOA2

SOAHOST2VHN1

8001

n/a

No

SOA-MGD-SVRS-ONLY

WLS_WSM1

SOAHOST1

7010

n/a

No

JRF-MAN-SVR

WSMPM-MAN-SVR

WSM-CACHE-SVR

WLS_WSM2

SOAHOST2

7010

n/a

No

JRF-MAN-SVR

WSMPM-MAN-SVR

WSM-CACHE-SVR

WLS_OSB1

SOAHOST1VHN2

8011

n/a

No

OSB-MGD-SVRS-ONLY

WLS_OSB2

SOAHOST2VHN2

8011

n/a

No

OSB-MGD-SVRS-ONLY

Footnote 1 The WLS_SOA Managed Servers will appear if you are extending an existing Oracle SOA Suite domain with Oracle Service Bus.

Task 9   Configuring a Cluster

In this task, you create a cluster of Managed Servers to which you can target the Oracle SOA Suite software.

You will also set the Frontend Host property for the cluster, which ensures that, when necessary, WebLogic Server will redirect Web services callbacks and other redirects to osb.example.com on the load balancer rather than the address in the HOST header of each request.

For more information about the osb.example.com virtual server address, see Section 6.1, "Configuring Virtual Hosts on the Hardware Load Balancer".

Use the Clusters screen to create a new cluster:

  1. Click the Add button.

  2. Specify OSB_Cluster in the Cluster Name field.

  3. Specify osb.example.com in the Frontend Host field.

  4. Specify 80 as the Frontend HTTP Port and 443 as the Frontend HTTPS port.

Description of config_osb_cluster.gif follows
Description of the illustration ''config_osb_cluster.gif''

A Note About Unicast Versus Multicast:

By default, server instances in a cluster communicate with one another using unicast. If you want to change your cluster communications to use multicast, refer to "Considerations for Choosing Unicast or Multicast" in Administering Clusters for Oracle WebLogic Server.

Tip:

More information about the options on this screen can be found in Clusters in Creating WebLogic Domains Using the Configuration Wizard.
Task 10   Assigning Managed Servers to the Cluster

On the Assign Servers to Clusters screen, assign servers to clusters as follows:

  • SOA_Cluster - If you are extending a SOA domain.

  • WSM-PM_Cluster:

    • WLS_WSM1

    • WLS_WSM2

  • OSB_Cluster:

    • WLS_OSB1

    • WLS_OSB2

Click Next.

Task 11   Configuring Coherence Clusters

Use the Coherence Clusters screen to configure the Coherence cluster that is automatically added to the domain. Leave the port number value at 9991, as it was defined during the initial Infrastructure domain creation.

Task 12   Verifying the Existing Machines

Confirm that the following entries appear:

Table 13-4 Machines

Name Node Manager Listen Address

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

ADMINHOST

ADMINVHN

WEBHOST1

WEBHOST1

WEBHOST2

WEBHOST2

Leave all other fields to their default values.

Click Next.

Task 13   Assigning Servers to Machines

On the Assign Servers to Machines screen, assign servers to machines as follows:

  • ADMINHOST:

    • AdminServer

  • SOAHOST1

    • WLS_SOA1 (if extending a SOA domain)

    • WLS_WSM1

    • WLS_OSB1

  • SOAHOST2:

    • WLS_SOA2 (if extending a SOA domain)

    • WLS_WSM2

    • WLS_OSB2

Click Next.

Task 14   Configuring the JMS File Store

Configure the JMS File Stores that were just created during the configuration session (Wsee FileStore, UMS FileStore, JMS FileStore, and FileStore).

On the JMS File Stores screen, assign the following directory for each of the OSB Persistence stores:

ASERVER_HOME/OSB_Cluster/jms

In this example, replace ASERVER_HOME with the value of the variable for you environment. Replace OSB_Cluster with the name you assigned to the OSB cluster.

Ignore the JMS configuration warning that appears.

Task 15   Reviewing Your Configuration Specifications and Configuring the Domain

The Configuration Summary screen contains the detailed configuration information for the domain you are about to create. Review the details of each item on the screen and verify that the information is correct.

Click Update.

In the Extending Domain screen, click Done.

Task 16   Start the Administration Server

Start the Administration Server to ensure the changes you have made to the domain have been applied.

13.7 Configuring a Default Persistence Store for Transaction Recovery

Each server has a transaction log that stores information about committed transactions that are coordinated by the server that may not have been completed. The WebLogic Server uses this transaction log for recovery from system crashes or network failures. To leverage the migration capability of the Transaction Recovery Service for the servers within a cluster, store the transaction log in a location accessible to a server and its backup servers.

Note:

To enable migration of the Transaction Recovery Service, specify a location on a persistent storage solution that is available to other servers in the cluster. Both WLS_OSB1 and WLS_OSB2 must be able to access this directory. This directory must also exist before you restart the servers.

The recommended location is a dual-ported SCSI disk or on a Storage Area Network (SAN).

To set the location for the default persistence stores:

  1. Log in to the Oracle WebLogic Server Administration Console.

  2. In the Change Center section, click Lock & Edit.

  3. For each of the WLS_OSB Managed Servers:

    1. In the Domain Structure window, expand the Environment node, and then click the Servers node.

      The Summary of Servers page appears.

    2. Click the name of the server (represented as a hyperlink) in Name column of the table.

      The settings page for the selected server appears and defaults to the Configuration tab.

    3. On the Configuration tab, click the Services tab.

    4. In the Default Store section of the page, enter the path to the folder where the default persistent stores will store its data files.

      For the enterprise deployment, Oracle recommends creating a new subdirectory in the Administration Server domain home called OSB_Cluster. This subdirectory can server as the central, shared location for transaction logs.

      For example:

      ASERVER_HOME/OSB_Cluster/tlogs

    5. Click Save.

  4. Shut down WLS_WSM (and optionally, the WLS_SOA) Managed Servers in the domain:

    1. On the Summary of Servers page, select the WLS_SOA and WLS_WSM Managed Servers; do not select the Administration Server (AdminServer).

    2. Click Shutdown and then select When Work Completes or Force Shutdown, depending on whether or not you believe the affected Managed Servers are actively processing requests.

  5. Click Save and Activate Changes.

  6. Start the Managed Servers that you shut down.

Note:

You will validate the location and the creation of the transaction logs in Section 13.8.4.

13.8 Propagating the Extended Domain to the Domain Directories and Machines

After you have extended the domain with the OSB instances, and you have restarted the Administration Server on SOAHOST1, you must then propagate the domain changes to the domain directories and machines.

Note that there is no need to propagate the updated domain to the WEBHOST1 and WEBHOST2 machines, because there are no changes to the Oracle HTTP Server instances on those host computers.

Refer to the following sections for more information:

13.8.1 Summary of the Tasks Required to Propagate the Changes to the Other Domain Directories and Machines

Table 13-5 summarizes the steps required to propagate the changes to all the domain directories and machines.

Table 13-5 Summary of Tasks Required to Propagate the Domain Chanegs to Domain Directories and Machines

Task Description More Information

Pack up the Extended Domain on SOAHOST1

Use the Pack command to create a new template jar file that contains the new OSB Servers configuration.

When you pack up the domain, create a template jar file called soadomaintemplateExtOSB.jar.

Section 11.4.1, "Packing Up the Extended Domain on SOAHOST1"

Unpack the Domain in the Managed Servers Directory on SOAHOST1

Unpack the template jar file in the Managed Servers directory on SOAHOST1 local storage.

Section 12.7.1, "Unpacking the Domain in the Managed Servers Domain Directory on SOAHOST1"

Unpack the Domain on SOAHOST2

Unpack the template jar file in the Managed Servers directory on the SOAHOST2 local storage.

Section 12.7.2, "Unpacking the Domain on SOAHOST2"

13.8.2 Starting and Validating the WLS_OSB1 Managed Server

After extending the domain, restarting the Administration Server, and propagating the domain to the other hosts, use the following procedure to start the WLS_OSB1 server and validate that it's configured successfully:

13.8.2.1 Starting the WLS_OSB1 Managed Server

  1. Enter the following URL into a browser to display the Fusion Middleware Control login screen:

    http://ADMINVHN:7001/em

  2. Log in to Fusion Middleware Control using the Administration Server credentials.

  3. In the Target Navigation pane, expand the domain to view the Managed Servers in the domain.

    Description of edg_em_select_wls_osb1.gif follows
    Description of the illustration ''edg_em_select_wls_osb1.gif''

  4. Select only the WLS_OSB1 Managed Server and click Start Up on the Oracle WebLogic Server toolbar.

    Note:

    OSB Servers depend on the policy access service to be functional. This implies that the WSM-PM Managed Servers in the domain need to be up and running and reachable before the OSB servers are started.

  5. When the startup operation is complete, navigate to the Domain home page and verify that the WLS_SOA1 Managed Server is up and running.

13.8.2.2 Adding the MiddlewareAdministrators Role to the Enterprise Deployment Administration Group

Before you validate the Oracle Service Bus configuration on the WLS_OSB1 Managed Server, add the Oracle Service Bus MiddlewareAdministrators administration role to the enterprise deployment administration group (SOA Administrators).

To perform this task, refer to Section 18.2.1, "Configuring Roles for Administration of Oracle SOA Suite Products".

13.8.2.3 Validating the Managed Server by Logging in to the SOA Infrastructure

After you add the SOAAdmin role to the SOA Administrators group, you can then validate the configuration of the Oracle SOA Suite software on the WLS_SOA1 Managed Server as follows.

  1. Use your Web browser to navigate to the following URL:

    http://SOAHOST1VHN2:8011/sbinspection.wsil

    Replace SOAHOST1VHN2 with the value of this variable in the Enterprise Deployment Workbook. For more information, see Section 5.2.3, "Physical and Virtual IP Addresses Required by the Enterprise Topology".

  2. Log in using the enterprise deployment administration user (SOA Administrators).

    With the default installation, this should result in the following HTTP response to the Web services call:

    <ins:inspection/>

13.8.3 Starting and Validating the WLS_OSB2 Managed Server

Follow similar steps as in the previous section for WLS_OSB2:

  1. Log in to Fusion Middleware Control using the Administration Server credentials.

  2. In the Target Navigation pane, expand the domain to view the Managed Servers in the domain.

  3. Select only the WLS_OSB2 Managed Server and click Start Up on the Oracle WebLogic Server tool bar.

  4. When the startup operation is complete, navigate to the Domain home page and verify that the WLS_OSB2 Managed Server is up and running. Access the equivalent URLs for the WLS_OSB2:

    http://SOAHOST2VHN2:8011/sbinspection.wsil

  5. Verify the correct deployment of the Oracle Service Bus console to the Administration Server by accessing the following URL:

    http://ADMINVHN:7001/servicebus/

13.8.4 Validating the Location and Creation of the Transaction Logs

After the WLS_OSB1 and WLS_OSB2 Managed Servers are up and running, verify that the transaction log directory and transaction logs were created as expected, based on the steps you performed in Section 13.7, "Configuring a Default Persistence Store for Transaction Recovery":

ASERVER_HOME/OSB_Cluster/tlogs

  • _WLS_WLS_OSB1000000.DAT

  • _WLS_WLS_OSB2000000.DAT

13.8.5 Verifying the Appropriate Targeting for OSB Singleton Services

Oracle Service Bus uses some services that are singletons and that should run only in one of the WLS servers in the OSB_Cluster.

Verify that the appropriate targeting exists and that the following applications are only targeted to WLS_OSB1:

  • Service Bus Cluster Singleton Marker Application

  • Service Bus Domain Singleton Marker Application

To do this follow these steps:

  1. In a browser, go to the following URL:

    http://ADMINVHN:7001/console

  2. Log in as the administrator.

  3. In the Domain Structure tree on the left, click Deployments.

  4. Find the Service Bus Cluster Singleton Marker Application and Service Bus Domain Singleton Marker Application. Verify that in the Targets column in the table, only WLS_OSB1 appears as target.

13.9 Configuring Oracle HTTP Server for the Oracle Service Bus

To configure the Oracle HTTP Server instances in the Web tier so they route requests correctly to the Oracle Service Bus cluster, use the following procedure to create an additional Oracle HTTP Server configuration file that creates and defines the parameters of the soa.example.com virtual server.

This procedure assumes you performed the Oracle HTTP Server configuration tasks described in Section 11.7, "Configuring Oracle HTTP Server for Administration and Oracle Web Services Manager".

Note:

If you configure any HTTP proxy services, you can start the context paths for the proxy services with a common name to facilitate the routing for all the proxy services. For example: 
/osb/project-name/folder-name/proxy-service-name

To set the parameter:

  1. Log into SOAHOST1, and change directory to the following location:

    cd ASERVER_HOME/config/fmwconfig/components/OHS/OHS_1/

  2. Create a new configuration file, called osb_vh.conf file, and add the following <VirtualHost> directive to the file:

    <VirtualHost WEBHOST1:7777>
    ServerName https://osb.example.com:443
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit
</VirtualHost>

  3. Add the following directives inside the <VirtualHost> tags:

    <Location /sbinspection.wsil>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /sbresource>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /osb>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /alsb>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

    The osb_vh.conf file will appear as it does in Example 13-1.

  4. Add the following entry to the admin_vh.conf file within the <VirtualHost> tags:

    <Location /sbconsole >
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /servicebus>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /lwpfconsole >
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

    The admin_vh.conf file will appear as it does in Example 13-2.

  5. Copy the soa_vh.conf file and the admin_vh.conf file to the configuration directory for the second Oracle HTTP Server instance (OHS_2):

    ASERVER_HOME/config/fmwconfig/components/OHS_2/

  6. Edit the osb_vh.conf file and change any references to WEBHOST1 to WEBHOST2 in the <VirtualHost> directives.

  7. Restart the Administration Server.

  8. After the Administration Server is running, review the files in the following directories on both WEBHOST1 and WEBHOST2 to be sure they contain the modifications made in the Administration Server domain directory:

    MSERVER_HOME/config/fmwconfig/components/OHS/instances/OHS_1/

    MSERVER_HOME/config/fmwconfig/components/OHS/instances/OHS_2/

  9. Restart Oracle HTTP Servers on WEBHOST1 and WEBHOST2.

Example 13-1 osb_vh.conf file

<VirtualHost WEBHOST1:7777>
ServerName https://osb.example.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

<Location /sbinspection.wsil >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /sbresource >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /osb >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /alsb >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /lwpfconsole >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>
</VirtualHost>

Example 13-2 admin_vh.conf file

# The admin URLs should only be accessible via the admin virtual host 

<VirtualHost WEBHOST1:7777>
    ServerName admin.example.com:80
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit

# Admin Server and EM
<Location /console>
    SetHandler weblogic-handler
    WebLogicHost ADMINVHN
    WeblogicPort 7001
</Location>

<Location /consolehelp>
    SetHandler weblogic-handler
    WebLogicHost ADMINVHN
    WeblogicPort 7001
</Location>

<Location /em>
    SetHandler weblogic-handler
    WebLogicHost ADMINVHN
    WeblogicPort 7001
</Location>

<Location /sbconsole >
    SetHandler weblogic-handler
    WebLogicHost ADMINVHN
    WeblogicPort 7001
</Location>

<Location /servicebus>
    SetHandler weblogic-handler
    WebLogicHost ADMINVHN
    WeblogicPort 7001
   </Location>
</VirtualHost>

13.10 Configuring the WebLogic Proxy Plug-In

Set the WebLogic Plug-In Enabled parameter for the OSB cluster.

  1. Log in to the Oracle WebLogic Server Administration Console.

  2. In the Domain Structure pane, expand the Environment node.

  3. Click on Clusters.

  4. Select the OSB_Cluster cluster to which you want to proxy requests from Oracle HTTP Server.

    The Configuration: General tab is displayed.

  5. Scroll down to the Advanced section and expand it.

  6. Click Lock and Edit.

  7. Set the WebLogic Plug-In Enabled to yes.

  8. Click Save and Activate the changes.Restart the OSB servers for the changes to be effective.

13.11 Validating the Oracle Service Bus URLs Through the Load Balancer

Verify the Oracle Service Bus URLs to ensure that appropriate routing and failover is working from the hardware load balancer to the HTTP Server instances to the Oracle Service Bus components.

To verify the URLs:

  1. While WLS_OSB1 is running, stop WLS_OSB2 using the Oracle WebLogic Server Administration Console.

  2. Access the following URL and verify the HTTP response as indicated in Section 13.8.3, "Starting and Validating the WLS_OSB2 Managed Server":

    https://osb.example.com/

  3. Start WLS_OSB2 from the Oracle WebLogic Server Administration Console.

  4. Stop WLS_OSB1 from the Oracle WebLogic Server Administration Console.

  5. Access the same URL and verify the HTTP response as indicated in section Section 13.8.3, "Starting and Validating the WLS_OSB2 Managed Server".

    Note:

    Since a front end URL has been set for the OSB_Cluster, the requests to the urls result in a re-route to the LBR, but in all cases it should suffice to verify the appropriate mount points and correct failover in Oracle HTTP Server.

  6. Verify this URL using your load balancer address:

    http://osb.example.com:80/sbinspection.wsil

    Verify http://osb.example.com:80/sbconsole which will direct to http://osb.example.com:80/servicebus.

13.12 Post-Configuration Tasks for Oracle Service Bus

After you install and configure Oracle Service Bus in the domain, consider the following post-configuration tasks:

13.12.1 Enabling High Availability for Oracle DB, File and FTP Adapters

Oracle SOA Suite and Oracle Service Bus use the same database, File, and FTP JCA adapters.

You create the required database schemas for these adapters when you use the Oracle Repository Creation Utility before configuring Oracle SOA Suite. The database adapter does not require any configuration at the WebLogic Server resource level.

The required configuration for the other adapters is described in section Section 12.11.1.1, "Enabling High Availability for Oracle File and FTP Adapters".

If you are configuring Oracle Service Bus as an extension of a SOA domain, you do not need to add to the configuration already performed for the adapters.

If you are deploying Oracle Service Bus as an extension to an Oracle Fusion Middleware Infrastructure domain (without Oracle SOA Suite), then you must do the following:

13.12.2 Configuring Specific Oracle Service Bus Services for an Enterprise Deployment

To use IBM WebSphere MQ Connection resources and the MQ Transport in Oracle Service Bus, you must add the MQ client libraries to the classpath.

One option is to copy the required MQ libraries to the following location in the domain home directory:

DOMAIN_HOME/lib

This is also the case for custom assertions and JBoss integration services:

  • When using JBoss initial context factory classes, make sure to include the class and any dependent classes in the DOMAIN_HOME/lib directory.

  • Similarly, for custom assertions, create the required jar file with the assertion and add the jar to the DOMAIN_HOME/lib directory.

Further, to use these services in an enterprise deployment, you must add the required libraries to the Administration Server domain home (ASERVER_HOME/lib) and the Managed Server domain home (MSERVER_HOME/lib).

For more information about configuring and developing services for Oracle Service Bus, see Developing Services with Oracle Service Bus.

13.12.3 Enabling SSL Communication Between the Oracle Service Bus Servers and the Hardware Load Balancer

After you extend the domain with Oracle Service Bus, you should also ensure that the Administration Server and Managed Servers can access the front-end, SSL URL of the hardware load balancer.

This will allow Oracle Service Bus Web services and other services to invoke callbacks and other communications with the front-end, secure URL.

For more information, see Section 18.1.2, "Enabling SSL Communication Between the Middle Tier and the Hardware Load Balancer".

13.12.4 Backing Up the Oracle Service Bus Configuration

It is an Oracle best practices recommendation to create a backup after successfully extending a domain or at another logical point. Create a backup after verifying that the installation so far is successful. This is a quick backup for the express purpose of immediate restoration in case of problems in later steps.

The backup destination is the local disk. You can discard this backup when the enterprise deployment setup is complete. After the enterprise deployment setup is complete, you can initiate the regular deployment-specific Backup and Recovery process.

For information about backing up your configuration, see Section 18.2.6, "Performing Backups and Recoveries in the SOA Enterprise Deployments."

13.13 Enabling Whole Server Migration for Oracle Service Bus

To ensure that Oracle Service Bus is configured for high availability, configure the Oracle Service Bus Managed Servers with Whole Server Migration for failover and zero data loss.

For more information on enabling server migration, see Chapter 19, "Using Whole Server Migration and Service Migration in an Enterprise Deployment".


Footnote Legend

Footnote 1: The WLS_SOA Managed Servers will appear only if you are extending an existing Oracle SOA Suite domain with Oracle Service Bus.