3 About the Oracle SOA Suite Enterprise Deployment Topology
- 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. - Diagrams of the Primary Oracle SOA Suite Enterprise 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. - 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. - 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. - 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. - 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 that you want to include in the topology. - 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.
Parent topic: Understanding an Enterprise Deployment
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.
Diagrams of the Primary Oracle SOA Suite Enterprise 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.
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. 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 follows](img/edg-topology-soa-and-osb.png)
Description of "Figure 3-1 Oracle SOA Suite and Oracle Service Bus Enterprise Deployment Reference Topology Diagram"
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 follows](img/edg-topology-soa-and-bpm.png)
Description of "Figure 3-2 Oracle SOA Suite and Oracle Business Activity Monitoring Enterprise Topology Diagram"
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 that 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:
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 Service Bus sometimes have differing patching requirements. If the two products are in separate domains, it can be easier to patch one without affecting the other.
Parent topic: About the Primary Oracle SOA Suite Topology Diagrams
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 by 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 by 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 by 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. 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.
Parent topic: About the Primary Oracle SOA Suite Topology Diagrams
About the Routing of SOA Composite Requests
The following topics provide additional information on configuring the enterprise deployment for Oracle SOA Suite composite applications.
- More About the soainternal Virtual Server Name
- About Web Services Optimizations for SOA Composite Applications
- About Accessing SOA Composite Applications through Oracle HTTP Server
- About Accessing Oracle SOA Suite Composite Applications Through the Load Balancer
Parent topic: About the Primary Oracle SOA Suite Topology Diagrams
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 create the cluster in the Configuration Wizard. You can also modify it later, by using the WebLogic Server Administration Console. See Configure HTTP Protocol in Oracle WebLogic Server Administration Console Online Help.
For more information about setting the ServerURL
and HTTPServerURL
properties, see Configuring SOA Infrastructure Properties.
Parent topic: About the Routing of SOA Composite Requests
About Web Services Optimizations for SOA Composite Applications
When you configure 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 of 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 of 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 URLs and 443 for HTTPS URLs.
-
Parent topic: About the Routing of SOA Composite Requests
About Accessing SOA Composite Applications through Oracle HTTP Server
When you route 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, if a request to Oracle SOA Suite composite application was received by the Managed Server and the composite application was not yet loaded, Oracle HTTP Server generated an HTTP 503 (Service Unavailable) message.
-
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 act similar to composites that are yet loaded.
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 you configure 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. 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.
Parent topic: About the Routing of SOA Composite Requests
About Accessing Oracle SOA Suite Composite Applications Through 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 you use 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).
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 fails. Therefore, you should always verify that the soa-infra
application is active after you start, restart, or migrate a 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 crosses two firewalls without any proxy or interception. This might a security issue, depending on the network security policies in your organization.
Parent topic: About the Routing of SOA Composite Requests
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 | Dynamic Cluster Support |
---|---|---|
Oracle SOA Suite, Oracle Business Process Management, and Oracle B2B Cluster |
WLS_SOA1, WLS_SOA2 |
Yes |
Oracle Web Services Manager Cluster |
WLS_WSM1, WLS_WSM2 |
Yes |
Oracle Service Bus Cluster |
WLS_OSB1, WLS_OSB2 |
Yes |
Oracle Enterprise Scheduler |
WLS_ESS1, WLS_ESS2 |
Yes |
Oracle Business Activity Monitoring Cluster |
WLS_BAM1, WLS_BAM2 |
No |
There are some clusters that run in their own domains, such as MFT and HealthCare Integration. The clusters for these components are shown in Table 3-2
Table 3-2 Summary of the Clusters in the Oracle SOA Suite Enterprise Deployment Topology with Their Own Domains
Cluster | Managed Servers | Dynamic Cluster Support |
---|---|---|
Oracle Managed File Transfer |
WLS_MFT1, WLS_MFT2 |
Yes |
Oracle SOA Suite for Healthcare Integration |
WLS_SOA1, WLS_SOA2 |
Yes |
Parent topic: About the Primary Oracle SOA Suite Topology Diagrams
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 that you must perform to install and configure the enterprise topology that is described in this chapter.
- Flow Chart of the Steps to Install and Configure the Primary Oracle SOA Suite Enterprise Topologies
- Roadmap Table for Planning and Preparing for an Enterprise Deployment
- Roadmap Table for Configuring the Oracle SOA Suite and Oracle Service Bus Enterprise Topology
- Roadmap Table for Configuring the Oracle SOA Suite and Oracle Business Activity Monitoring Enterprise Topology
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 that is 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 similar to 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 follows](img/soedg-main-flowchart-standard-topologies.png)
Description of "Figure 3-3 Flow Chart of the Enterprise Topology Configuration Steps"
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 |
|
Understand the specific reference topology for the products that 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 |
|
Procure the hardware, IP addresses, and software downloads |
|
Prepare the hardware load balancer and firewalls |
Preparing the Load Balancer and Firewalls for an Enterprise Deployment |
Prepare the file system |
|
Verify system requirements, mount shared storage, and enable virtual IPs |
|
Identify or install a supported Oracle RAC Database |
Roadmap Table for Configuring the Oracle SOA Suite and Oracle Service Bus Enterprise Topology
Table 3-3 describes each of the configuration steps that are required when you configure 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. See About the Topology Options for Oracle Service Bus.
Table 3-3 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 |
|
Extend the domain with Oracle SOA Suite |
|
Extend 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 procedure 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. |
Create a domain for Oracle Managed File Transfer |
Configuring Oracle Managed File Transfer in an Enterprise Deployment Note that extending the domain with Oracle Managed File Transfer is optional; perform the procedures in this chapter only if you want to configure Oracle Managed File Transfer. |
Roadmap Table for Configuring the Oracle SOA Suite and Oracle Business Activity Monitoring Enterprise Topology
Table 3-4 describes each of the configuration steps that are 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-4 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 |
|
Extend the domain with Oracle SOA Suite |
|
Extend the domain with Business Process Management |
|
Extend the domain with Oracle Business Activity Monitoring |
|
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. |
Extend the domain with Oracle Insight |
Extending the SOA Domain to Include Oracle Real-Time Integration Business Insight Note that extending the domain with Oracle Insight is optional; perform the procedures in this chapter only if you want to configure Oracle Insight. |
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 to configure 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 that you deploy.
Note:
All managed servers of a component type in the domain must belong to that cluster. For example, Oracle Service Bus domains support only a single Service Bus cluster inside each domain.
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 that are 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 follows](img/soa-edg-build-your-own-topo-flow-chart.png)
Description of "Figure 3-4 Flow Chart of the Oracle SOA Suite Build-Your-Own Topologies"
Parent topic: Building Your Own Oracle SOA Suite Enterprise Topology
Description of the Supported Build Your Own Topologies
Table 3-5 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 need to consider when you use the existing instructions in this guide to build each topology.
Table 3-5 Roadmap Table for Building Your Own Enterprise Topology
Topology | After You Configure the Web Tier, Refer to the Following Chapters | Considerations and Dependencies |
---|---|---|
SOA Suite and Business Process Management only |
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 |
No special instructions required. |
|
SOA Suite and Enterprise Scheduler only |
No special instructions required. |
|
Oracle Service Bus and Enterprise Scheduler only |
See |
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 |
The instructions in Extending the Domain with Business Activity Monitoring assume that 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 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 |
No special instructions required. |
|
Oracle SOA Suite for MFT Integration |
Oracle Managed File Transfer requires Oracle Traffic Director as the web server in the web tier. |
Parent topic: Building Your Own Oracle SOA Suite Enterprise Topology
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 that 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 install and configure the components that you need, or you can install and configure a standard installation topology by using the Oracle Fusion Middleware 12c installation guides and use the Start Small and Scale Out approach to configure your environment.
For more information about planning your installation, see Planning for a Production Environment in Planning an Installation of Oracle Fusion Middleware.
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 static clusters, you can configure Automatic Service Migration by using the Configuration Wizard HA Options screen. If you select the Enable Automatic Service Migration option, it configures migratable target definitions that are required for automatic service migration. In the same screen, you can use JTA Transaction Log Persistence and JMS Server Persistence options to configure them with JDBC stores automatically. Oracle recommends that you enable these options when you configure static clusters in the SOA enterprise deployment.
For dynamic clusters, migratable targets are not required because some functionalities of the automatic service migration are provided inherently by the dynamic cluster. The Configuration Wizard High Availability Options screen is not used for dynamic clusters but some additional steps are required to configure the leasing and the persistent stores migration policies. Oracle recommends that you perform these post-steps when you configure dynamic clusters in the SOA enterprise deployment.
For more information about service migration, see Using Whole Server Migration and Service Migration in an Enterprise Deployment.