3 About the Oracle SOA Suite Enterprise Deployment Topology

The Oracle SOA Suite enterprise deployment topologies represent specific reference implementations of the concepts that are described in Understanding a Typical Enterprise Deployment.

3.1 About the Primary and Build-Your-Own Enterprise Deployment Topologies

This guide focuses on one or more primary reference topologies for a selected product. In addition, this guide provides high-level information about how to design and build your own enterprise deployment topology.

The exact topology you install and configure for your organization might vary, but for the primary topologies, this guide provides step-by-step instructions for installing and configuring those topologies.

For the build-your-own topologies, the guide also provides information about how to add specific components or products required for your specific environment.

3.2 Diagrams of the Primary Oracle SOA SuiteEnterprise Topologies

The two primary Oracle SOA Suite enterprise deployment topologies are: Oracle SOA Suite and Oracle Service Bus Topology and Oracle SOA Suite and Oracle Business Activity Monitoring Topology

3.2.1 Diagram of the Oracle SOA Suite and Oracle Service Bus Topology

Figure 3-1 shows a diagram of the Oracle SOA and Oracle Service Bus enterprise deployment topology.

Note:

You can configure Oracle Service Bus in the same domain as Oracle SOA Suite or in its own domain. For more information, see About the Topology Options for Oracle Service Bus.

For a description of the standard elements shown in the diagram, see Understanding the Typical Enterprise Deployment Topology Diagram.

For a description of the elements shown in the diagram, see Understanding the Primary Oracle SOA Suite Topology Diagrams.

Figure 3-1 Oracle SOA Suite and Oracle Service Bus Enterprise Deployment Reference Topology Diagram

Description of Figure 3-1 follows
Description of "Figure 3-1 Oracle SOA Suite and Oracle Service Bus Enterprise Deployment Reference Topology Diagram"

3.2.2 Diagram of the Oracle SOA Suite and Oracle Business Activity Monitoring Topology

Figure 3-2 shows a diagram of the Oracle SOA Suite and Oracle Business Activity Monitoring enterprise topology.

For a description of the standard elements shown in the diagram, see Understanding the Typical Enterprise Deployment Topology Diagram.

For a description of the elements that are specific to the Oracle SOA Suite topologies, see Understanding the Primary Oracle SOA Suite Topology Diagrams.

Figure 3-2 Oracle SOA Suite and Oracle Business Activity Monitoring Enterprise Topology Diagram

Description of Figure 3-2 follows
Description of "Figure 3-2 Oracle SOA Suite and Oracle Business Activity Monitoring Enterprise Topology Diagram"

3.3 About the Primary Oracle SOA Suite Topology Diagrams

Most of the elements of Oracle SOA Suite topologies represent standard features of any enterprise topology that follows the Oracle-recommended best practices. These elements are unique to the primary topology.

These elements are described in detail in Understanding a Typical Enterprise Deployment.

Before you review the information here, it is assumed you have reviewed the information in Understanding a Typical Enterprise Deployment and that you are familiar with the general concepts of an enterprise deployment topology.

See the following sections for information about the elements that are unique to the topology described in this chapter:

3.3.1 About the Topology Options for Oracle Service Bus

The Oracle SOA Suite and Oracle Service Bus topology diagram in this guide assumes a single domain that contains both SOA Suite and Oracle Service Bus. However, it is often advantageous to configure Oracle Service Bus in its own domain.

For example, consider separate domains when you are using Oracle Service Bus on an enterprise scale. In this scenario, you can then use Oracle Service Bus to route to multiple SOA domains and other services.

On the other hand, if you are using Oracle Service Bus primarily for mediating and providing routing for SOA Suite composite applications, configure Oracle Service Bus in the same domain, but in separate clusters for optimum performance and scalability.

When considering these options, take into account patching and other life cycle maintenance operations. For example, Oracle SOA Suite and Oracle SOA Suite sometimes have differing patching requirements. If the two products are in separate domains, it can be easier to patch one without affecting the other.

3.3.2 Summary of Oracle SOA Suite Load Balancer Virtual Server Names

In order to balance the load on servers and to provide high availability, the hardware load balancer is configured to recognize a set of virtual server names.

For information about the purpose of each of these server names, see Summary of the Typical Load Balancer Virtual Server Names.

The following virtual server names are recognized by the hardware load balancer in Oracle SOA Suite topologies:

  • soa.example.com - This virtual server name is used for all incoming traffic. It acts as the access point for all HTTP traffic to the runtime SOA components. The load balancer routes all requests to this virtual server name over SSL. As a result, clients access this service using the following secure address:

    soa.example.com:443
    
  • osb.example.com - This virtual server name that acts as the access point for all HTTP traffic to the runtime Oracle Service Bus resources and proxy services. The load balancer routes all requests to this virtual server name over SSL. As a result, clients access this service using the following secure address:

    osb.example.com:443
    
  • soainternal.example.com - This virtual server name is for internal communications between the application tier components only and is not exposed to the Internet.

    Specifically, for the Oracle SOA Suite enterprise topology, this URL is used for both Oracle SOA Suite and Oracle Service Bus internal communications.

    The traffic from clients to this URL is not SSL-enabled. Clients access this service using the following address and the requests are forwarded to port 7777 on WEBHOST1 and WEBHOST2:

    soainternal.example.com:80
    

    Note that this URL can also be set as the URL to be used for internal service invocations while modeling composites or at runtime with the appropriate Enterprise Manager MBeans. For more information, see More About the soainternal Virtual Server Name.

  • admin.example.com - This virtual server name is for administrators who need to access the Oracle Enterprise Manager Fusion Middleware Control and Oracle WebLogic Server Administration Console interfaces.

    Note:

    There are some components that use specific TCP Virtual Servers in the front end LBR for non- HTTP access to the system. This is the case of MLLP for Oracle SOA HC Integration and Oracle MFT. These virtual servers may use the same host name and different port or may use a different host name. Using a different host name may be a likely option when network tools are used for controlling traffic (for example, prioritizing the type of traffic based on the destination addresses). However, you will require an additional host name address in the required DNS systems.

Instructions later in this guide explain how to:

  • Configure the hardware load balancer to recognize and route requests to the virtual host names.

  • Configure the Oracle HTTP Server instances on the Web Tier to recognize and properly route requests to the virtual host names and the correct host computers.

3.3.3 About the Routing of SOA Composite Requests

The following topics provide additional information on configuring the enterprise deployment for Oracle SOA Suite composite applications.

3.3.3.1 More About the soainternal Virtual Server Name

The sointernal.example.com virtual server name functions exactly the same as the soa.example.com, except that it invoked by intranet clients and callbacks only. This topic provides additional details.

The soainternal.example.com virtual server name is not used explicitly during the installation and configuration of the enterprise deployment, but custom systems often expose services that should be consumed by internal-only clients. In those cases, for efficiency and security reasons, you should avoid using an external URL such as soa.example.com. Instead, you should use an address that cannot be invoked by Internet clients. SOA Composite applications, in particular, can use this internal URL in their end points, either directly or through deployment plans.

When you use the soainternal.example.com address, there are implications for the front end address specified for the system. Web Services optimizations (for example, direct RMI invocation instead of invocations that involve a full loopback to the load balancer endpoint) are triggered when the Front End address for the cluster matches the invocation endpoint. For this reason, depending on the number and relevance of the expected internal invocations, consider setting the front end URL for the cluster and the ServerURL and HTTPServerURL properties to either the external or internal.

You can set the front end URL for a cluster when you are creating the cluster in the Configuration Wizard. You can also modify it later, using the WebLogic Server Administration Console. For more information, see Configure HTTP Protocol in the Administration Console Online Help.

For more information about setting the ServerURL and HTTPServerURL properties, see Configuring SOA Infrastructure Properties.

3.3.3.2 About Web Services Optimizations for SOA Composite Applications

When configuring internal callbacks so that SOA composite applications can communicate efficiently within the enterprise deployment, you should be aware of how the system checks for the proper end-point address for each request.

For webservice local optimization, the basic requirement is to make sure that the two SOA composites are colocated on the same Managed Server or process. To determine if the composites are colocated on the same server, Oracle SOA Suite compares the server on which the target service composite is deployed (host and port configuration) with those specified in the reference service endpoint URI.

  • For target service host value, here is the sequence of checks in order precedence:

    • Checks the Server URL configuration property value on SOA Infrastructure Common Properties page.

    • If not specified, checks the FrontendHost and FrontendHTTPPort (or FrontendHTTPSPort if SSL is enabled) configuration property values from the cluster MBeans.

    • If not specified, checks the FrontendHost and FrontendHTTPPort (or FrontendHTTPSPort if SSL is enabled) configuration property values from the Oracle WebLogic Server MBeans.

    • If not specified, uses the DNS-resolved Inet address of localhost.

  • For target service port value, here is the sequence of checks in order precedence:

    • Checks the port configured in HttpServerURL on SOA Infrastructure Common Properties page.

    • If not specified, checks the port configured in Server URL on SOA Infrastructure Common Properties page.

    • If not specified, checks the FrontendHost and FrontendHTTPPort (or FrontendHTTPSPort if SSL is enabled) configuration property values from the cluster MBeans.

    • If not specified, checks the FrontendHost and FrontendHTTPPort (or FrontendHTTPSPort if SSL is enabled) configuration property values from the Oracle WebLogic Server MBean.

    • If not specified, SOA Suite assumes 80 for HTTP and 443 for HTTPS URLs.

3.3.3.3 About Accessing SOA Composite Applications via Oracle HTTP Server

When routing requests from the Oracle HTTP Server instances on the Web tier to specific Oracle SOA Suite composite application URLs on the application, consider the following:

  • In previous releases of Oracle Fusion Middleware, Oracle HTTP Server generated an HTTP 503 (Service Unavailable) message if a request to Oracle SOA Suite composite application was received by the Managed Server and the composite application was not yet loaded.

  • In Oracle Fusion Middleware 12c, this behavior has changed. If requests for a composite arrives before the composite is active, then the HTTP requests are put on hold until the required artifacts are available and the composite reaches the active state.

    Note:

    Composites that include JCA bindings, EJB, and ADF binding cannot be lazy loaded and will behave like not-loaded-yet composites.

This change in behavior allows you to route requests to composite applications that are not yet loaded during the startup of an Oracle SOA Suite Managed Server. However, the communication channel between the Oracle HTTP Server and Oracle WebLogic Server needs to account for the possibility of long delays in getting replies.

To address this issue, while configuring firewalls between Oracle HTTP Server and Oracle WebLogic Server, set the appropriate timeout to avoid shutting down of connections that are waiting for a composite to be loaded.

For more information, see Configuring the Firewalls and Ports for an Enterprise Deployment.

Note that the Oracle HTTP Server instances route requests based on the availability of the Oracle WebLogic Server servers and not on the availability of any specific application. The instances continue to route the requests as long as the Oracle WebLogic Server is up and running.

3.3.3.4 About Accessing Oracle SOA Suite Composite Applications Via the Load Balancer

In the default configuration, the hardware load balancer routes all requests to the Web tier, which then routes the requests to the appropriate resource in the application tier.

However, you can configure the hardware load balancer to route directly to Managed Servers on the application tier. This configuration has some benefits, especially in an Oracle SOA Suite enterprise deployment:

  • Configuration and processing overhead is lower than when using Oracle HTTP Server.

  • It enables monitoring at the application level, because the load balancer can be configured to monitor specific URLS in each WLS server (something that is not possible with Oracle HTTP Server).

There is at least one disadvantage to this approach. If requests are routed directly from the load balancer to the Managed Servers, then each request will cross two firewalls without any proxy or interception. This might a security issue, depending on the network security policies in your organization.

If Oracle HTTP server directs an HTTP request for a composite to a Oracle SOA Suite Managed Server and the soa-infra application is not yet active, then the request will fail. Therefore, you should always verify that the soa-infra application is active after you start, restart, or migrate a server.

3.3.4 Summary of the Managed Servers and Clusters on SOA Application Tier

The Application tier hosts the Administration Server and Managed Servers in the Oracle WebLogic Server domain.

Depending upon the topology you select, the Oracle WebLogic Server domain for the Oracle SOA Suite domain consists of the clusters shown in Table 3-1. These clusters function as active-active high availability configurations.

Table 3-1 Summary of the Clusters in the Oracle SOA Suite Enterprise Deployment Topology

Cluster Managed Servers

Oracle SOA Suite, Oracle Business Process Management, and Oracle B2B Cluster

WLS_SOA1, WLS_SOA2

Oracle Web Services Manager Cluster

WLS_WSM1, WLS_WSM2

Oracle Service Bus Cluster

WLS_OSB1, WLS_OSB2

Oracle Oracle Enterprise Scheduler

WLS_ESS1, WLS_ESS2

Oracle Business Activity Monitoring Cluster

WLS_BAM1, WLS_BAM2

3.4 Flow Charts and Road Maps for Implementing the Primary Oracle SOA Suite Enterprise Topologies

Instructions in the form of flow charts and road maps help you to install and configure the enterprise deployment topology with ease.

The following sections summarize the high-level steps you must perform to install and configure the enterprise topology that is described in this chapter.

3.4.1 Flow Chart of the Steps to Install and Configure the Primary Oracle SOA Suite Enterprise Topologies

Figure 3-3 shows a flow chart of the steps required to install and configure the primary enterprise deployment topologies described in this chapter. The sections following the flow chart explain each step in the flow chart.

This guide is designed so you can start with a working Oracle SOA Suite domain and then later extend the domain to add additional capabilities.

This modular approach to building the topology allows you to make strategic decisions, based on your hardware and software resources, as well as the Oracle SOA Suite features that are most important to your organization.

It also allows you to validate and troubleshoot each individual product or component as they are configured.

This does not imply that configuring multiple products in one Configuration Wizard session is not supported; it is possible to group various extensions like the ones presented in this guide in one Configuration Wizard execution. However, the instructions in this guide focus primarily on the modular approach to building an enterprise deployment.

Figure 3-3 Flow Chart of the Enterprise Topology Configuration Steps

Description of Figure 3-3 follows
Description of "Figure 3-3 Flow Chart of the Enterprise Topology Configuration Steps"

3.4.2 Roadmap Table for Planning and Preparing for an Enterprise Deployment

The following table describes each of the planning and preparing steps shown in the enterprise topology flow chart.

Flow Chart Step More Information

Understand the basics of a Typical Enterprise Deployment

Understanding a Typical Enterprise Deployment

Understand the specific reference topology for the products you plan to deploy.

Review the product-specific topologies and the description of the topologies, including the virtual servers required and the summary of clusters and Managed Servers recommended for the product-specific deployment.

Review the Oracle SOA Suite EDG Workbook

Using the Enterprise Deployment Workbook

Procure the hardware, IP addresses and software downloads

Procuring Resources for an Enterprise Deployment

Prepare the hardware load balancer and firewalls

Preparing the Load Balancer and Firewalls for an Enterprise Deployment

Prepare the file system

Preparing the File System for an Enterprise Deployment

Verify system requirements, mount shared storage, and enable virtual IPs

Preparing the Host Computers for an Enterprise Deployment

Identify or install a supported Oracle RAC Database

Preparing the Database for an Enterprise Deployment

3.4.3 Roadmap Table for Configuring the Oracle SOA Suite and Oracle Service Bus Enterprise Topology

Table 3-2 describes each of the configuration steps required when configuring the Oracle SOA Suite and Oracle Service Bus topology shown in Figure 3-1.

These steps correspond to the Oracle SOA Suite and Oracle Service Bus Topology steps shown in the flow chart in Figure 3-3.

Note:

You can configure Oracle Service Bus in the same domain as Oracle SOA Suite or in its own domain. For more information, see About the Topology Options for Oracle Service Bus.

Table 3-2 Roadmap Table for Configuring the Oracle SOA Suite and Oracle Service Bus Enterprise Topology

Flow Chart Step More Information

Create the initial Infrastructure domain

Creating the Initial Infrastructure Domain for an Enterprise Deployment

Extend the domain to Include the Web Tier

Configuring the Web Tier for an Enterprise Deployment

Extend the domain with Oracle SOA Suite

Extending the Domain with Oracle SOA Suite

Extend the Domain with Oracle Service Bus

Extending the Domain with Oracle Service Bus

Extend the domain with Enterprise Scheduler

Extending the Domain with Oracle Enterprise Scheduler

Note that extending the domain with Enterprise Scheduler is optional; perform the procedurs in this chapter only if you want to configure Enterprise Scheduler.

Extend the domain with Oracle B2B

Extending the Domain with Oracle B2B

Note that extending the domain with Oracle B2B is optional; perform the procedures in this chapter only if you want to configure Oracle B2B.

3.4.4 Roadmap Table for Configuring the Oracle SOA Suite and Oracle Business Activity Monitoring Enterprise Topology

Table 3-3 describes each of the configuration steps required to configure the Oracle SOA Suite and Oracle Business Activity Monitoring topology shown in Figure 3-2.

These steps correspond to the configuration steps shown for the Oracle SOA Suite Oracle Business Activity Monitoring topology in the flow chart in Figure 3-3.

Table 3-3 Roadmap Table for Configuring the Oracle SOA Suite and Oracle Business Activity Monitoring Enterprise Topology

Flow Chart Step More Information

Create the initial Infrastructure domain

Creating the Initial Infrastructure Domain for an Enterprise Deployment

Extend the domain to Include the Web Tier

Configuring the Web Tier for an Enterprise Deployment

Extend the domain with Oracle SOA Suite

Extending the Domain with Oracle SOA Suite

Extend the domain with Business Process Management

Extending the Domain with Business Process Management

Extend the domain with Oracle Business Activity Monitoring

Extending the Domain with Business Activity Monitoring

Extend the domain with Oracle B2B

Extending the Domain with Oracle B2B

Extend the domain with Oracle Healthcare

Extending the Domain with Oracle SOA Suite for Healthcare Integration

Extend the domain with Oracle Managed File Transfer

Configuring Oracle Managed File Transfer in an Enterprise Deployment

3.5 Building Your Own Oracle SOA Suite Enterprise Topology

You can implement alternative topologies depending on the requirements of your organization, by using some variations of the instructions provided in this guide.

This document provides step-by-step instructions for configuring the two primary enterprise topologies for Oracle SOA Suite, which are described in Diagrams of the Primary Oracle SOA Suite Enterprise Topologies.

However, Oracle recognizes that the requirements of your organization may vary, depending on the specific set of Oracle Fusion Middleware products that you purchase and the specific types of applications you deploy.

In many cases, you can install and configure an alternative topology — one that includes additional components, or one that does not include all the Oracle SOA Suite products shown in the primary topology diagrams.

3.5.1 Flow Chart of the "Build Your Own" Enterprise Topologies

Building your own enterprise topology involves picking and choosing which Oracle Fusion Middleware products and which configuration steps you want to use to build your topology.

Figure 3-4 shows the high-level configuration steps required to build some typical alternative Oracle SOA Suite enterprise topologies. Each of the configuration steps corresponds to a chapter in this guide.

Note that modifications of the steps in this guide are necessary in order to implement the "Build Your Own" topologies. Refer to Description of the Supported "Build Your Own" Topologies for more information.

Figure 3-4 Flow Chart of the Oracle SOA Suite Build-Your-Own Topologies

Description of Figure 3-4 follows
Description of "Figure 3-4 Flow Chart of the Oracle SOA Suite Build-Your-Own Topologies"

3.5.2 Description of the Supported "Build Your Own" Topologies

Table 3-4 describes the configuration steps to follow if you want to use the instructions in this guide to build the enterprise topologies listed in Figure 3-4.

It also identifies some differences you will need to consider when you use the existing instructions in this guide to build each topology.

Table 3-4 Roadmap Table for Building Your Own Enterprise Topology

Topology After configuring the Web Tier, refer to the following chapters... Considerations and Dependencies

SOA Suite and Business Process Management only

  1. Extending the Domain with Oracle SOA Suite

  2. Extending the Domain with Business Process Management

These instructions assume you will run the Oracle SOA Suite and Business Process Management installer twice--once to install Oracle SOA Suite and once to install Oracle Business Process Management.

Alternatively, you can install both Oracle SOA Suite and Oracle Business Process Management at the same time by selecting the BPM install type during the installation.

Similarly, you can configure this topology by running the Configuration Wizard only once by selecting both the SOA and Oracle Business Process Management templates during the Configuration Wizard session.

Oracle SOA Suite and Oracle B2B only

  1. Extending the Domain with Oracle SOA Suite

  2. Extending the Domain with Oracle B2B

No special instructions required.

SOA Suite and Enterprise Scheduler only

  1. Extending the Domain with Oracle SOA Suite

  2. Extending the Domain with Oracle Enterprise Scheduler

No special instructions required.

Oracle Service Bus and Enterprise Scheduler only

See

  1. Extending the Domain with Oracle Service Bus

  2. Extending the Domain with Oracle Enterprise Scheduler

This topology does not require Oracle SOA Suite. However, the instructions in Extending the Domain with Oracle Service Bus assume you have already created a cluster of two SOA Managed Servers.

As a result, when you create this topology, ignore any references to the SOA Managed Servers or the SOA Cluster.

In addition, you must run the Repository Creation Utility (RCU) to create the SOAINFRA schema, which is also required by Oracle Service Bus.

Oracle Business Activity Monitoring only

Extending the Domain with Business Activity Monitoring

The instructions in Extending the Domain with Business Activity Monitoring assume you are extending an existing Oracle SOA Suite domain and that the Oracle SOA Suite software (which includes Oracle BAM) has already been installed in an Oracle home on shared storage.

For this Oracle BAM-only topology, you will need to install Oracle SOA Suite into the Oracle Fusion Middleware Infrastructure Oracle home before you can configure the domain to include an Oracle BAM cluster.

In addition, you must run the Repository Creation Utility (RCU) to create the required SOA schemas.

Oracle SOA Suite for healthcare integration

  1. Extending the Domain with Oracle SOA Suite

  2. Extending the Domain with Oracle SOA Suite for Healthcare Integration

No special instructions required.

Oracle SOA Suite for MFT Integration

  1. Extending the Domain with Oracle SOA Suite

  2. Configuring Oracle Managed File Transfer in an Enterprise Deployment

Oracle Managed File Transfer requires Oracle Traffic Director as the Web server in the Web tier.

3.6 About Installing and Configuring a Custom Enterprise Topology

If you choose to implement a topology that is not described in this guide, be sure to review the certification information, system requirements, and interoperability requirements for the products you want to include in the topology.

After you verify that the topology is supported, then you can either use the instructions in this guide as a guide to installing and configuring the components you need, or you can install and configure a standard installation topology using the Oracle Fusion Middleware 12c installation guides and use the "Start Small and Scale Out" approach to configuring your environment.

For more information, see Planning for a Production Environment in Planning an Installation of Oracle Fusion Middleware.

3.7 About Using Automatic Service Migration for the Oracle SOA Suite Enterprise Topology

To ensure high availability of the Oracle SOA Suite products and components, this guide recommends that you enable Oracle WebLogic Server Automatic Service Migration for the clusters that you create as part of the reference topology.

For more information, see Using Whole Server Migration and Service Migration in an Enterprise Deployment.