2 Introduction to the Enterprise Deployment Reference Topology

This chapter describes and illustrates the enterprise deployment reference topologies described in this guide. The road map for installation and configuration directs you to the appropriate chapters for the tasks you need to perform. Use this chapter to help you plan your Oracle SOA enterprise deployment.

This chapter includes the following topics:

2.1 Overview of Enterprise Deployment Reference Topologies

This diagrams in this section illustrate the three possible enterprise deployment topologies described in this guide. Use this section to plan your enterprise deployment topology.

This section covers these topics:

2.1.1 Reference Topologies Documented in the Guide

This guide provides configuration instructions for a reference enterprise topology that uses service-oriented architecture (SOA) with Oracle Access Manager, as shown in Figure 2-1, with Oracle Access Manager and Oracle Business Activity Monitoring (BAM), as shown in Figure 2-2, with Oracle Access Manager and BAM, as shown in Figure 2-3 or with Oracle Service Bus, as shown in Figure 2-4.

Note:

Your actual enterprise deployment topology may require variations on the topologies described in this guide.

2.1.1.1 MySOACompany Topology with Oracle Access Manager

Figure 2-1 illustrates a MySOACompnay topology that includes Oracle Access Manager.

Figure 2-1 MySOACompany Topology with Oracle Access Manager

MySOACompany Topology with OAM
Description of "Figure 2-1 MySOACompany Topology with Oracle Access Manager"

2.1.1.2 MySOACompany Topology with Oracle Access Manager and Business Activity Monitoring

Figure 2-2 illustrates a MySOACompany topology that includes Oracle Access Manager and Business Activity Monitoring.

Figure 2-2 MySOACompany Topology with Oracle Access Manager and Business Activity Monitoring

MySOACompany Topology with Oracle BAM
Description of "Figure 2-2 MySOACompany Topology with Oracle Access Manager and Business Activity Monitoring"

2.1.1.3 MySOACompany Topology with Oracle Access Manager and Oracle BPM

Figure 2-3 illustrates a MySOACompany Topology that includes Oracle Access Manager and Oracle BPM.

Figure 2-3 MySOACompany Topology with Oracle Access Manager and BAM

MySOACompany Topology with Oracle BAM
Description of "Figure 2-3 MySOACompany Topology with Oracle Access Manager and BAM"

2.1.1.4 MySOACompany Topology with Oracle Service Bus

Figure 2-4 illustrates a MySOACompany Topology that includes Oracle Service Bus.

Figure 2-4 MySOACompany Topology with Oracle Service Bus

MySOACompany Topology with Oracle BAM
Description of "Figure 2-4 MySOACompany Topology with Oracle Service Bus"

2.1.2 About Oracle Identity Management Integration

Integration with the Oracle Identity Management system is an important aspect of the enterprise deployment architecture. This integration provides features such as single sign-on, integration with Oracle Platform Security Services, centralized identity and credential store, and authentication for the WebLogic domain. The IDM Enterprise Deployment is separate from this enterprise deployment and exists in a separate domain by itself. For more information on Oracle Identity Management in an enterprise deployment context, see Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management.

The primary interface to the Oracle Identity Management enterprise deployment is the LDAP traffic to the LDAP servers, the OAP (Oracle Access Protocol) to the OAM Access Servers, and the HTTP redirection of authentication requests.

2.1.3 About the Web Tier Nodes

Nodes in the web tier are located in the DMZ public zone.

In this tier, two nodes WEBHOST1 and WEBHOST2 run Oracle HTTP Server configured with WebGate and mod_wl_ohs.

The following is a list of benefits provided by using Oracle HTTP Server as an intermediate point between the load balancer and the different WebLogic Servers:

  • It provides a sacrificial area/DMZ. This is a common requirement in security audits and is a major problem with load balancer/WebLogic systems. If a load balancer routes directly to the WebLogic Server, request move from the load balancer to the application tier in one single HTTP jump, causing security concerns.

  • It allows the WebLogic Server cluster membership to be reconfigured (new servers added, others removed) without having to change the Web server configuration (as long as at least some of the servers in the configured list remain alive). The plug-in learns about the cluster membership and directs work accordingly.

  • Faster fail-over in the event of WebLogic Server instance failure. The plug-in actively learns about the failed WebLogic Server instance using information supplied by its peers, It avoids the failed server until the peers notify the plug-in that it is again available. Load balancers are typically more limited.

  • Oracle HTTP Server delivers static content more efficiently and faster than WebLogic Server.

  • HTTP redirection over and above what WebLogic Server provides. You can use Oracle HTTP Server as a front end against many different WebLogic Server clusters, and perhaps do content based routing.

  • If SSO is required, only Oracle HTTP Server (not WebLogic Server) supports Oracle Identity Management.

Through mod_wl_ohs, which allows requests to be proxied from Oracle HTTP Server to WebLogic Server, Oracle HTTP Server forwards the requests to WebLogic Server running in the application tier.

WebGate (which is an Oracle Access Manager component) in Oracle HTTP Server uses Oracle Access Protocol (OAP) to communicate with Oracle Access Manager running on OAMHOST2, in the Identity Management DMZ. WebGate and Oracle Access Manager are used to perform operations such as user authentication.

The web tier also includes a load balancer router to handle external requests. External requests are sent to the virtual host names configured on the load balancer. The load balancer then forwards the requests to Oracle HTTP Server.

The WebGate module in Oracle HTTP Server uses Oracle Access Protocol (OAP) to communicate with Oracle Access Manager to perform operations such as querying user groups.

On the firewall protecting the web tier, only the HTTP ports are open: 443 for HTTPS and 80 for HTTP.

2.1.4 Load Balancer Requirements

This enterprise topology uses an external load balancer. This external load balancer should have the following features:

  • Ability to load-balance traffic to a pool of real servers through a virtual host name: Clients access services using the virtual host name (instead of using actual host names). The load balancer can then load balance requests to the servers in the pool.

  • Port translation configuration should be possible so that incoming requests on the virtual host name and port are directed to a different port on the backend servers.

  • Monitoring of ports on the servers in the pool to determine availability of a service.

  • Virtual servers and port configuration: Ability to configure virtual server names and ports on your external load balancer, and the virtual server names and ports must meet the following requirements:

    • The load balancer should allow configuration of multiple virtual servers. For each virtual server, the load balancer should allow configuration of traffic management on more than one port. For example, for Oracle HTTP Server in the web tier, the load balancer needs to be configured with a virtual server and ports for HTTP and HTTPS traffic.

    • The virtual server names must be associated with IP addresses and be part of your DNS. Clients must be able to access the external load balancer through the virtual server names.

  • Ability to detect node failures and immediately stop routing traffic to the failed node.

  • Fault-tolerant mode: It is highly recommended that you configure the load balancer to be in fault-tolerant mode.

  • It is highly recommended that you configure the load balancer virtual server to return immediately to the calling client when the backend services to which it forwards traffic are unavailable. This is preferred over the client disconnecting on its own after a timeout based on the TCP/IP settings on the client machine.

  • Sticky routing capability: Ability to maintain sticky connections to components. Examples of this include cookie-based persistence, IP-based persistence, and so on.

  • The load balancer should be able to terminate SSL requests at the load balancer and forward traffic to the backend real servers using the equivalent non-SSL protocol (for example, HTTPS to HTTP). Typically, this feature is called SSL termination and it is required for this Enterprise Deployment.

  • SSL acceleration, which refers to off loading the public-key encryption algorithms involved in SSL transactions to a hardware accelerator. This feature is recommended, but not required.

2.1.5 About the Application Tier

Nodes in the application tier are located in the DMZ secure zone.

In this tier, two nodes SOAHOST1 and SOAHOST2 run Oracle WebLogic Server configured with managed servers for running SOA components such as BPEL Process Manager and B2B. The managed servers are configured in an active-active manner.

BAMHOST1 and BAMHOST2 run the BAM Server and BAM Web Applications.

SOAHOST1 and SOAHOST2 also run the Oracle WebLogic Server Administration Console and Oracle Enterprise Manager Fusion Middleware Control, but in an active-passive configuration. The active-passive configuration of the Administration Server is necessary because only one Administration Server can be running within a domain. In the illustration, the Administration Server on SOAHOST1 is currently in the active state, but you can failover manually to the Administration Server on SOAHOST2.

For information, see Section 8.8, "Verifying Manual Failover of the Administration Server." Alternatively you can configure the Oracle WebLogic Server Administration Console with CFC/CRS to fail over automatically on a separate hardware cluster (not shown in this architecture).

Oracle Web Services Manager (Oracle WSM) provides a policy framework to manage and secure Web services in the Enterprise Deployment topology. WSM Policy Manager also runs in active-active configuration in two additional WebLogic Servers.

On the firewall protecting the application tier, the HTTP ports, OAP port, and proxy port are open. The OAP port is for the WebGate module running in Oracle HTTP Server in the web tier to communicate with Oracle Access Manager. Applications requiring external HTTP access use Oracle HTTP Server as the proxy. (The proxy on the Oracle HTTP Server must be enabled to allow this access.)

2.1.6 About the Data Tier

Nodes in the data tier are located in the most secured network zone (the intranet).

In this tier, an Oracle RAC database runs on the nodes CUSTDBHOST1 and CUSTDBHOST2. The database contains the schemas needed by the SOA, BAM, and Oracle Service Bus components. The SOA, BAM and Oracle Service Bus components running in the application tier access this database.

On the firewall protecting the data tier, the database listener port (typically, 1521) is required to be open. The LDAP ports (typically, 389 and 636) are also required to be open for the traffic accessing the LDAP storage in the IDM Enterprise Deployment.

2.1.7 About the Unicast Requirement for Communication

Oracle recommends that the nodes in the mySOACompany topology communicate using unicast. Unlike multicast communication, unicast does not require cross-network configuration and it reduces potential network errors that can occur from multicast address conflicts as well.

In unicast messaging mode, the default listening port of the server is used if no channel is configured.

Cluster members communicate to the group leader when they need to send a broadcast message which is usually the heartbeat message. When the cluster members detect the failure of a group leader, the next oldest member becomes the group leader.

The frequency of communication in unicast mode is similar to the frequency of sending messages on multicast port.

The following considerations apply when using unicast to handle cluster communications:

  • All members of a WebLogic cluster must use the same message type. Mixing between multicast and unicast messaging is not allowed.

  • Individual cluster members cannot override the cluster messaging type.

  • The entire cluster must be shut down and restarted to change the message modes (from unicast to multicast or from multicast to unicast).

  • JMS topics configured for multicasting can access WebLogic clusters configured for unicast because a JMS topic publishes messages on its own multicast address that is independent of the cluster address. However, the following considerations apply:

    • The router hardware configurations that allow unicast clusters may not allow JMS multicast subscribers to work.

    • JMS multicast subscribers need to be in a network hardware configuration that allows multicast accessibility. (That is, JMS subscribers must be in a multicast-enabled network to access multicast topics.)

2.2 Hardware Requirements for an Enterprise Deployment on Linux

Read the Oracle Fusion Middleware System Requirements and Specifications document to ensure that your environment meets the minimum installation requirements for the products you are installing. This document contains information related to hardware and software requirements, minimum disk space and memory requirements, database schema requirements, and required system libraries, packages, or patches.

Table 2-1 lists the typical hardware requirements for the enterprise deployment described in this guide on Linux operating systems. The memory figures represent the memory required to install and run an Oracle Fusion Middleware server; however, for most production sites, you should configure at least 4 GB of physical memory.

You must perform the appropriate capacity planning to determine the number of nodes, CPU, and memory requirements for each node depending on the specific system's load as well as the throughput and response requirements. These will vary for each application or custom SOA system being used.

Table 2-1 Typical Hardware Requirements

Server Disk Memory TMP Directory Swap

Database

nXm

n = number of disks, at least 4 (striped as one disk)

m = size of the disk (minimum of 30 GB)

6-8 GB

Default

Default

WEBHOSTn

10 GB

4 GB

Default

Default

SOAHOSTn (SOA only)

10 GBFoot 1 

4 GB

Default

Default

SOAHOSTn (SOA and OSB)

11 GBFoot 2 

6 GB

Default

Default

BAMHOSTn

10 GBFoot 3 

4 GB

Default

Default

Footnote 1 For a shared storage Middleware home configuration, two installations suffice by making a total of 20 GB independently of the number of slots.

Footnote 2 For a shared storage Middleware home configuration, two installations suffice by making a total of 20 GB independently of the number of slots.

Footnote 3 BAM can reuse Middleware home binaries from the SOA installation in shared storage.

2.3 Identifying the Software Components to Install

Table 2-2 lists the Oracle software you will need to obtain before starting the procedures in this guide.

For complete information about downloading Oracle Fusion Middleware software, see the Oracle Fusion Middleware Download, Installation, and Configuration Readme Files on the Oracle Technology Network (OTN).

Table 2-2 Components and Installation Sources

Component Details

Oracle Database 10g or 11g

Oracle Database 10g distribution (10.2.0.4 or later SE or EE version of the database) using the AL32UTF8 character set.

Oracle Database Server 11g distribution (11.1.0.7 or later SE or EE version of the database), using the AL32UTF8 character set.

Repository Creation Utility (RCU)

(The RCU is generic and not platform specific on different Linux variations. The same bits are installed for Linux on 32 and 64 bit installations.)

Oracle Fusion Middleware Repository Creation Utility 11g (11.1.1.7) distribution

Oracle WebLogic Server (WLS)

Oracle WebLogic Server (10.3.6) distribution

Oracle HTTP Server (OHS)

Oracle Fusion Middleware WebTier and Utilities 11g (11.1.1.7) distribution

Oracle SOA Suite

Oracle SOA Suite 11g (11.1.1.7) distribution

Oracle Access Manager (OAM) WebGate

WebGate 10g (10.1.4.3) for OAM 10g or WebGate 11g (11.1.1.2 or later) for OAM 11g.

Oracle Virtual Directory (OVD)

Oracle Identity and Access Management 11g (11.1.1.5 or later) distribution

Oracle Internet Directory (OID)

Oracle Identity and Access Management 11g (11.1.1.5 or later) distribution

Oracle Service Bus (OSB)

Oracle Service Bus 11g (11.1.1.7) distribution

2.4 About LDAP as Credential and Policy Store

With Oracle Fusion Middleware, you can use different types of credential and policy stores in a WebLogic domain. Domains can use stores based on XML files or on different types of LDAP providers. When a domain uses an LDAP store, all policy and credential data is kept and maintained in a centralized store. However, when using XML policy stores, the changes made on managed servers are not propagated to the Administration Server unless they use the same domain home.

An Oracle Fusion Middleware SOA Suite Enterprise Deployment Topology uses different domain homes for the Administration Server and the managed servers as described in Section 4.3, "About Recommended Locations for the Different Directories." Derived from this, and for integrity and consistency purposes, Oracle requires the use of an LDAP as policy and credential store in the context of Oracle Fusion Middleware SOA Suite Enterprise Deployment Topology. To configure the Oracle Fusion Middleware SOA Suite enterprise deployment topology with an LDAP as credential and policy store, follow the steps in Section 15.3, "Configuring the Policy Store."

2.5 Clock Synchronization

The clocks of all servers participating in the cluster must be synchronized to within one second difference to enable proper functioning of jobs, adapters, and Oracle B2B. To accomplish this, use a single network time server and then point each server to that network time server.

The procedure for pointing to the network time server is different on different operating systems. Refer to your operating system documentation for more information.

2.6 Road Map for the Reference Topology Installation and Configuration

Before beginning your Oracle SOA enterprise deployment, review the flow chart in Figure 2-5. This flow chart illustrates the high-level process for completing the enterprise deployment documented in this guide. Table 2-3 describes the steps in the flow chart and directs you to the appropriate section or chapter for each step.

This section covers the following topics:

2.6.1 Flow Chart of the Oracle SOA Enterprise Deployment Process

Figure 2-5 provides a flow chart of the Oracle SOA enterprise deployment process. Review this chart to become familiar with the steps that you must follow, based on the existing environment.

Figure 2-5 Flow Chart of the Oracle SOA Enterprise Deployment Process

Description of Figure 2-5 follows
Description of "Figure 2-5 Flow Chart of the Oracle SOA Enterprise Deployment Process"

2.6.2 Steps in the Oracle SOA Enterprise Deployment Process

Table 2-3 describes each of the steps in the enterprise deployment process flow chart for Oracle SOA, shown in Figure 2-5. The table also provides information on where to obtain more information on each step in the process.

Table 2-3 Steps in the Oracle SOA Enterprise Deployment Process

Step Description More Information

Prepare your Network for Enterprise Deployment

To prepare your network for an enterprise deployment, understand concepts, such as virtual server names and IPs and virtual IPS, and configure your load balancer by defining virtual host names.

Chapter 3, "Preparing the Network for an Enterprise Deployment"

Prepare your File System for Enterprise Deployment

To prepare your file system for an enterprise deployment, review the terminology for directories and directory environment variables, and configure shared storage.

Chapter 4, "Preparing the File System for an Enterprise Deployment"

Prepare your Database for Enterprise Deployment

To prepare your database for an enterprise deployment, review database requirements, create database services, load the metadata repository, in the Oracle RAC database, configure SOA schemas for transactional recovery privileges, and back up the database.

Chapter 5, "Preparing the Database for an Enterprise Deployment"

Install the Software

Install Oracle HTTP Server, Oracle WebLogic Server, Oracle Fusion Middleware, and apply patchsets to Oracle Fusion Middleware components.

Chapter 6, "Installing the Software for an Enterprise Deployment"

Configure the Web Tier

Configuring Oracle HTTP Server with the load balancer, and configuring virtual host names.

Chapter 7, "Configuring the Web Tier for an Enterprise Deployment"

Create a Domain

Run the Configuration Wizard to create a domain.

Chapter 8, "Creating a Domain for an Enterprise Deployment"

Extend the Domain for SOA

Extend the existing WebLogic domain by running the Configuration Wizard to configure Oracle SOA components.

Chapter 9, "Extending the Domain for SOA Components"

Extend the Domain for BAM?

You have two options for extending the domain to include Oracle BAM components:

  • If you have not yet extended the domain for Oracle SOA, you can run the configuration Wizard and configure Oracle SOA and Oracle BAM at the same time.

  • If you have already extended the domain to include Oracle SOA, you can run the Configuration Wizard again and extend the domain to include Oracle BAM.

Chapter 10, "Extending the Domain to Include Oracle BPM"

Extend the Domain for BAM?

You have two options for extending the domain to include Oracle BAM components:

  • If you have not yet extended the domain for Oracle SOA, you can run the configuration Wizard and configure Oracle SOA and Oracle BAM at the same time.

  • If you have already extended the domain to include Oracle SOA, you can run the Configuration Wizard again and extend the domain to include Oracle BAM.

Chapter 12, "Extending the Domain to Include BAM"

Extend the Domain for OSB?

Run the Configuration Wizard again and extend the domain to include Oracle Service Bus.

Chapter 11, "Extending a SOA Domain to Oracle Service Bus"

Set up Node Manager

Set up Node manager by enabling host name verification, starting Node Manager, and configuring WebLogic Servers to use custom keystores.

Chapter 13, "Setting Up Node Manager for an Enterprise Deployment"

Configure Server Migration

Configure server migration for the WLS_SOA1 and WLS_SOA2 managed servers. The WLS_SOA1 managed server is configured to restart on SOAHOST2 should a failure occur. The WLS_SOA2 managed server is configured to restart on SOAHOST1 should a failure occur.

Chapter 14, "Configuring Server Migration for an Enterprise Deployment"

Integrate with Identity Management

You can integrate your Oracle SOA enterprise deployment with Oracle Identity Management 10g or 11g.

Chapter 15, "Integrating an Enterprise Deployment with Oracle Identity Management"

2.6.3 Understanding the Incremental, Modular Approach to Enterprise Deployment

By design, this document describes an incremental and modular approach to setting up an enterprise deployment.

The instructions for setting up the storage, database, networking, and Web Tier infrastructure are similar to the instructions provided in the other Oracle Fusion Middleware Enterprise Deployment Guides. These elements of the topology provide the foundation for the Oracle WebLogic Server domain you later configure to support the enterprise deployment.

When you create the domain, the instructions vary from guide to guide. However, all the Enterprise Deployment Guides provide separate, modular instructions for creating and extending an Oracle WebLogic Server domain, as follows:

  1. Install the Oracle Fusion Middleware software on disk and create the necessary binary directories.

  2. Run the Oracle Fusion Middleware Configuration Wizard to create the domain and configure only the administration components.

    The administration components include the Administration Server, Oracle WebLogic Server Administration Console, Oracle Enterprise Manager Fusion Middleware Control, and Oracle Web Services Manager.

  3. Run the Configuration Wizard again to extend the domain to include the primary Oracle Fusion Middleware product you want to use.

  4. Optionally, run the Configuration Wizard again to extend the domain to include other supporting components and products.

This incremental approach allows you to verify the environment after each pass of the Configuration Wizard. It also simplifies troubleshooting during the setup process.

In addition, this modular approach allows you to consider alternative topologies. Specifically, after you configure the Administration components, the domain you create does not need to contain all the components described in this guide. Instead, you can use the domain extension chapters independently and selectively, to configure individual components that are required for your specific organization.