Skip Headers
Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite
11g Release 1 (11.1.1)

Part Number E12036-07
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

1 Enterprise Deployment Overview

This chapter provides an overview of the enterprise topology for Oracle SOA Suite. It contains the following sections:

1.1 What is an Enterprise Deployment?

An enterprise deployment is an Oracle best practices blueprint based on proven Oracle high-availability and security technologies and recommendations for Oracle Fusion Middleware. The best practices described in these blueprints span many Oracle products across the entire technology stack: Oracle Database, Oracle Fusion Middleware, and Enterprise Manager Fusion Middleware Control.

An Oracle Fusion Middleware enterprise deployment:

For more information on high availability practices, go to http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm.

Note:

This document focuses on enterprise deployments in Linux environments, but enterprise deployments can also be implemented in UNIX and Windows environments.

1.2 Terminology

This section identifies terms used to describe components in prior releases, and the terms to which they correlate in 11g Release 1 (11.1.1).

1.3 Benefits of Oracle Recommendations

The Oracle Fusion Middleware configurations discussed in this guide are designed to ensure security of all invocations, maximize hardware resources, and provide a reliable, standards-compliant system for enterprise computing with a variety of applications.

The security and high availability benefits of the Oracle Fusion Middleware configurations are realized through isolation in firewall zones and replication of software components.

1.3.1 Built-in Security

The Enterprise Deployment architectures are secure because every functional group of software components is isolated in its own DMZ, and all traffic is restricted by protocol and port. The following characteristics ensure security at all needed levels, as well as a high level of standards compliance:

  • Configure external load balancers to redirect all external communication received on port 80 to port 443.

    Note:

    The Oracle Technology Network (http://www.oracle.com/technology/index.html) provides a list of validated load balancers and their configuration at http://www.oracle.com/technetwork/middleware/ias/tested-lbr-fw-sslaccel-100648.html.
  • Communication from external clients does not go beyond the Load Balancing Router level.

  • No direct communication from the Load Balancing Router to the data tier is allowed.

  • Components are separated in different protection zones: the Web tier, application tier, and the data tier.

  • Direct communication across two firewalls at any one time is prohibited.

  • If a communication begins in one firewall zone, it must end in the next firewall zone.

  • Oracle Internet Directory is isolated in the data tier.

  • Identity Management components are in a separate subnet.

  • All communication between components across protection zones is restricted by port and protocol, according to firewall rules.

1.3.2 High Availability

The enterprise deployment architectures are highly available, because each component or functional group of software components is replicated on a different computer, and configured for component-level high availability.

1.4 Hardware Requirements

Typical hardware requirements for the Enterprise Deployment on Linux operating systems are listed in Table 1-1. 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.

For detailed requirements, or for requirements for other platforms, see the Oracle Fusion Middleware Installation Guide for that platform.

Table 1-1 Typical Hardware Requirements

Server Processor Disk Memory TMP Directory Swap

Database

4 or more X Pentium, 1.5 GHz or greater

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

2 or more X Pentium, 1.5 GHz or greater

10 GB

4 GB

Default

Default

SOAHOSTn

2 or more X Pentium, 1.5 GHz or greater

10 GBFoot 1 

4 GB

Default

Default

BAMHOSTn

2 or more X Pentium, 1.5 GHz or greater

10 GBFoot 2 

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 BAM can reuse Middleware home binaries from the SOA installation in shared storage.

Note:

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.

1.5 Enterprise Deployment Reference Topology

The instructions and diagrams in this guide describe a reference topology, to which variations may be applied.

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

Figure 1-1 MySOACompany Topology with Oracle Access Manager

MySOACompany Topology with OAM

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

MySOACompany Topology with Oracle BAM

Figure 1-3 MySOACompany Topology with Oracle Access Manager and BPM

MySOACompany Topology with Oracle BAM

This section covers these topics:

1.5.1 Oracle Identity Management

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, authentication for the WebLogic domain, and so on. 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.

1.5.2 Web Tier

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.

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.

1.5.2.1 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 acceleration and it is required for this Enterprise Deployment.

1.5.3 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. You can fail over the Administration Server manually (see Section 4.22, "Manually Failing Over the Administration Server to SOAHOST2"); 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.)

1.5.4 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 and BAM components. The BAM and SOA 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.

1.5.5 What to Install

Table 1-2 identifies the source for installation of each software component. For more information, see Oracle Fusion Middleware Installation Guide for Oracle SOA Suite and Oracle Fusion Middleware Installation Guide for Oracle WebCenter.

Table 1-2 Components and Installation Sources

Component Distribution Medium

Oracle Database 10g or 11g

Oracle Database CD (in 10g series, 10.2.0.4 or higher; in 11g series, 11.1.0.7 or higher)

Repository Creation Utility (RCU)

Oracle Fusion Middleware Repository Creation Utility 11g (11.1.1.4.0) DVD

Oracle WebLogic Server (WLS)

Oracle Weblogic Server 11g R1 (10.3.4) DVD

Oracle HTTP Server

Oracle Fusion Middleware WebTier and Utilities 11g (11.1.1.4.0) DVD

Oracle SOA Suite

Oracle SOA Suite 11g (11.1.1.4.0) DVD

Oracle Business Activity Monitor (BAM)

Oracle Fusion Middleware 11g (11.1.1.4.0) DVD

Oracle Access Manager 10g Webgate

Oracle Access Manager 10g Webgates (10.1.4.3.0) DVD ; OAM OHS 11g webgates per platform

Oracle Virtual Directory (OVD)

Oracle Identity Management 11g (11.1.1.4.0) DVD


1.5.6 Unicast Requirement

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.

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 muticast-enabled network to access multicast topics.)

Notes:

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.

1.6 How to Use This Guide

This section covers the following topics:

1.6.1 Installation and Configuration Procedure

Table 1-3 summarizes the process by which you install and configure SOA Enterprise Deployment. Follow the procedures indicated in the first column, in the order shown, for the chosen configuration.

Note:

This document focuses on enterprise deployments in Linux environments, but enterprise deployments can also be implemented in UNIX and Windows environments.

Table 1-3 SOA Installation Procedures

Perform the steps in... To configure a domain with only Admin Server and WSM-PM To configure a domain with Admin Server, WSM-PM, and extend it with a SOA cluster To Configure a domain with Admin Server, WSM-PM, and extend it with a SOA/BPM cluster To Configure a domain with Admin Server, WSM-PM, SOA and extend it to a BPM cluster To configure a domain with Admin Server, WSM-PM, and BAM cluster (without SOA) To configure a domain with Admin Server, WSM-PM, SOA/BPM cluster, and BAM cluster

Chapter 2, "Database and Environment Preconfiguration"

Yes

Yes

Yes

Yes

Yes

Yes

Chapter 3, "Installing Oracle HTTP Server"

Yes

Yes

Yes

Yes

Yes

Yes

Chapter 4, "Creating a Domain"

Yes

Yes

Yes

Yes

Yes

Yes

Chapter 5, "Extending the Domain for SOA Components"

No

Yes

No

Yes

No

Yes

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

No

No

Yes (Use option 1)

Yes (Use option 2)

No

Yes (if BPM is used with BAM)

Chapter 7, "Extending the Domain to Include BAM"

No

No

No

No)

Yes)

Yes

Chapter 8, "Setting Up Node Manager"

Recommended (optional depending on the type of security required for the application tier)

Recommended (optional depending on the type of security required for the application tier)

Recommended (optional depending on the type of security required for the application tier)

Recommended (optional depending on the type of security required for the application tier)

Recommended (optional depending on the type of security required for the application tier)

Recommended (optional depending on the type of security required for the application tier)

Chapter 9, "Server Migration"

No

Yes (for production environments)

Yes (for production environments)

Yes (for production environments)

Yes

Yes


1.6.2 Overview of Installation Strategies

The Configuration Wizard enables you to extend the Oracle WebLogic domain by adding only the needed components; rather than using the Configuration Wizard to create SOA components and the Oracle Business Monitoring (BAM) components along with the domain that includes the Administration Server, Enterprise Manager, and WSM-PM in a single pass, you can instead create the domain and its Administration Server, Enterprise Manager, and WSM-PM in one pass of the Configuration Wizard and then extend the domain by adding only the SOA components (or if needed, only the BAM components) in a subsequent pass. Using this incremental approach, you can verify the installation of the servers and perform specific validations after each pass of the Configuration Wizard. In general, Oracle recommends the following approach:

  1. Run a first pass of the Configuration Wizard to install the Administration Server, Enterprise Manager, and WSM-PM (described in Chapter 4, "Creating a Domain").

  2. Run a second pass of the Configuration Wizard to install the SOA components (described in Chapter 5, "Extending the Domain for SOA Components").

  3. Optionally, run a third pass to install the BAM components (described in Chapter 7, "Extending the Domain to Include BAM").

Oracle recommends this modular approach in order to facilitate the verification of individual components one by one. This building block approach simplifies the troubleshooting during the setup process and facilitates the configuration in smaller steps.

Some variation from the above topology is possible. For example, if a deployment chooses to install BAM alone, then only sections applicable extend with BAM need to be followed. Also, in this case, it is expected that the Adminserver will exist on BAMHOST1 instead and the instructions on creating the domain should be modified appropriately.

Additionally, Oracle Fusion Middleware 11g R1 11.1.1.3 (PS2) introduces Oracle BPM as a superset of the service engines that existed in previous Oracle Fusion Middleware 11g SOA Suite releases. You can enable Oracle BPM Suite in their systems in different ways. Using the Configuration Wizard to extend an exiting SOA domain, or using the Configuration Wizard to extend an Admin+WSM domain with both SOA and BPM components. Both options are explained in Chapter 6, "Extending the Domain to Include Oracle BPM."