2 Introduction and Planning

This chapter describes and illustrates the Exalogic enterprise deployment reference topology described in this guide and helps you plan your deployment.

The key to a successful Exalogic enterprise deployment is planning and preparation. The road map for installation and configuration in this chapter directs you to the appropriate chapters for the tasks you need to perform. Use this chapter to help you plan your Oracle SOA Exalogic enterprise deployment on an Exalogic platform.

You can use Appendix B, "Worksheet for Oracle SOA Enterprise Deployment on Exalogic Topology" to help you keep track of information.

This chapter contains the following topics:

• Planning Your Deployment

• Viewing the Oracle SOA Deployment Topology on Exalogic

• Understanding the Topology Components

• Hardware Requirements for the Oracle SOA on Exalogic

• Software Components for an Exalogic Enterprise Deployment

• Road Map for the Reference Topology Installation and Configuration

2.1 Planning Your Deployment

This section provides information to help you plan the deployment of Oracle SOA on Exalogic:

• Section 2.1.1, "Why the Deployment Topology in This Guide?"

• Section 2.1.2, "Alternative Deployment Topologies"

• Section 2.1.3, "Using a Worksheet to Plan for the Deployment Topology"

2.1.1 Why the Deployment Topology in This Guide?

When planning your deployment, you should be aware that this guide provides detailed instructions for implementing the specific reference topology described in this chapter.

This topology takes advantage of key features of the Exalogic platform, including:

• The high bandwidth and performance of the Exalogic internal Infiniband (IPoIB) network fabric

• The software load balancing capabilities of Oracle Traffic Director.

This topology also takes advantage of the several optimizations specific to the Oracle SOA Suite for the Exalogic platform. For example:

• XML Parsing and transformation optimizations

• XDK optimization

• Usage of Coherence as a read-cache for BPEL process state and audit data

• Scattered reads and gathered writes optimizations

• Self-tuning Thread optimization

In this specific topology, Oracle Traffic Director is used as both a Web Listener and as a client-side load balancer between Oracle Traffic Director instances and the SOA managed servers, as well as communication between the SOA managed servers.

In this configuration, you can take advantage of the Exalogic default IPoIB network for all internal communications between the Traffic Director instances and the SOA Suite compute nodes.

Only external traffic between the Traffic Director instances and external users is on the Exalogic Ethernet over IB (EoIB) network.

2.1.2 Alternative Deployment Topologies

Besides the topologies discussed in this guide, you can consider alternative Oracle SOA topologies on Exalogic.

This guide does not provide specific instructions for implementing these alternative topologies, but consider the following when you are preparing your environment for an Oracle SOA deployment on Exalogic:

• Using an External Oracle HTTP Server Web Tier Instead of Oracle Traffic Director

• Using Oracle Exadata Instead of an Oracle Real Application Clusters (RAC) Database

2.1.2.1 Using an External Oracle HTTP Server Web Tier Instead of Oracle Traffic Director

As described in Section 2.2, the topology in this guide uses Oracle Traffic Director as both a Web server and an internal load balancer. This configuration requires that you dedicate two compute nodes to hosting the Oracle Traffic Director instances.

An alternative topology is to use Oracle HTTP Server Web Tier as the web server and Oracle Traffic Director.as the internal load balance.This topology can be used if you have Oracle HTTP Server Web Tier already running outside Exalogic. Oracle Traffic Director will be installed on the Exalogic rack.

Refer to Appendix C, "SOA Exalogic Enterprise Topology with Oracle HTTP Server" for a diagram of a typical Oracle SOA topology on Exalogic with an external Oracle HTTP Server Web tier.

2.1.2.2 Using Oracle Exadata Instead of an Oracle Real Application Clusters (RAC) Database

The reference topology in this guide provides information on using an external Real Application Clusters (RAC) database on commodity hardware as the repository for product schemas and security stores.

You can also connect to a Real Application Clusters (RAC) database on an Oracle Exadata Database Machine using the Infiniband fabric. For more information, see "Connecting Exalogic and Exadata Machines" in the Oracle Exalogic Elastic Cloud Multi-Rack Cabling Guide.

2.1.3 Using a Worksheet to Plan for the Deployment Topology

The key to a successful Exalogic enterprise deployment is planning and preparation. The road map for installation and configuration in this chapter directs you to the appropriate chapters for the tasks you need to perform.

Use this chapter to help you plan your Oracle SOA Suite Exalogic enterprise deployment on an Exalogic platform.

You can also use Appendix B, "Worksheet for Oracle SOA Enterprise Deployment on Exalogic Topology" to help you keep track of information, such as host names, IP addresses, and other important information as you procure and identify the machines and resources required for this deployment.

2.2 Viewing the Oracle SOA Deployment Topology on Exalogic

Figure 2-1 provides a diagram of a standard, reference topology for Oracle SOA on Exalogic.

In this specific topology, the Web tier consists of Oracle Traffic Director instances, and the Exalogic machine is connected to a remote Oracle RAC database over a 10 Gb Ethernet connection.

For a detailed description of the elements of the topology, see Section 2.3, "Understanding the Topology Components".

Figure 2-1 Oracle SOA on Exalogic, Deployed with Oracle Traffic Director and an Oracle RAC Database

2.3 Understanding the Topology Components

The topologies consist of three tiers, which are described in the following sections:

• Section 2.3.1, "About EoIB and IPoIB Communication"

• Section 2.3.2, "About the Load Balancer"

• Section 2.3.3, "About the Web Tier"

• Section 2.3.4, "About the DMZ"

• Section 2.3.5, "About the Application Tier"

• Section 2.3.6, "About the Identity and Policy Stores"

2.3.1 About EoIB and IPoIB Communication

When you initially set up your Exalogic machine, the default network is running IP over Infiniband (IPoIB). For the different purposes of the topology described in this guide, you must configure Ethernet over Infiniband (EoIB) network access in addition to the IPoIB network. For more information, see "Configuring Ethernet Over InfiniBand" in the Oracle Exalogic Elastic Cloud Machine Owner's Guide.

The following four types of communication must be configured for the Oracle SOA enterprise deployment on Exalogic:

• For the Oracle Traffic Director hosts, the IP addresses must be EoIB addresses accessible from the load balancer. The Oracle Traffic Director IP addresses are the only addresses accessible from the DMZ network.

• For the application tier, the SOAHOST machines IP addresses must be EoIB addresses that can access the Oracle RAC database SCAN and VIP addresses, Additionally, SOA servers use IPoIB address as main listen addresses for internal invocations and for RMI interactions inside the Exalogic rack.

• Communication and routing between Oracle Traffic Director hosts and the application tier must be only over IPoIB.

• For communication between the application tier components, for example, Oracle Mediator and internal JMS destinations routing must be on IPoIB. Any front end address that is exposed ONLY for internal consumption, will use and IPoIB virtual IP on Oracle Traffic Director hosts.

• SOA Servers can also be accessed externally for RMI/JMS/T3 invocations and HTTP invocations. These take place for remote deployments, for external JMS producers and consumers and for other operations that use a listen address of the SOA servers that is available outside the Exalogic rack (EoIB).

For more information about IPoIB and EoIB network configuration, see Section 3.2, "About the Exalogic Network Configuration for the SOA Enterprise Topology."

2.3.2 About the Load Balancer

The hardware load balancer routes HTTP requests from users to the Oracle Traffic Director instances in the Web tier. The requests come in on a secure port (443) and are then routed to the Oracle Traffic Director instances via a non-secure port (7777).

The communication from the hardware load balancer to the Web tier (WEBHOST1 and WEBHOST2, in this case) is entirely over EoIB.

In addition to user traffic, the load balancer also routes Administrator requests to the administration server in the Oracle WebLogic Server domain on the application tier. This traffic is routed via a dedicated virtual server address called admin.mycompany.com.

2.3.3 About the Web Tier

With Exalogic, you can take advantage of Oracle Traffic Director capabilities.

In this topology, the Oracle Traffic Director instances serve two purposes:

• They receive HTTP requests coming in from the hardware load balancer (over the EoIB network) and then route those requests (over the IPoIB network) to the SOAHOSTs compute nodes on the application tier.

• They route requests from the application tier components (over the IPoIB network) including JMS (RMI) traffic, to other application tier components, such as callbacks and internal Web services invocations.

  The internal application to application requests, which are routed only over the internal IPoIB network, are routed via a virtual IP address that is depicted as VIP1 in the topology diagram (Figure 2-1).

  The Oracle Traffic Director instances are configured as part of a failover group. In this configuration, Oracle Traffic Director uses an implementation of the Virtual Routing Redundancy Protocol (VRRP) to provide failover capabilities. If an Oracle Traffic Director instance fails, IP addresses enabled on it are migrated to surviving instances, using VRRP. For information about configuring failover groups, see Section 7.9, "Creating a Failover Group for Virtual Hosts."

Consider these additional characteristics of the Web tier:

• WEBHOST1 and WEBHOST2 host Oracle Traffic Director. URI conditions and Host Server configuration enables requests to be proxied from the Oracle Traffic Director servers to a WebLogic Server running in the application tier.

• Oracle Traffic Director distributes the requests that it receives from clients to servers in the back end based on the specified load-balancing method, routes the requests based on specified rules, caches frequently accessed data, prioritizes traffic, and controls the quality of service.

• The Oracle Traffic Director Servers process requests received using the URLs soa.mycompany.com, osb.mycompany.com and soainternal.mycompany.com, and admin.mycompany.com. The name admin.mycompany.com is only resolvable inside the firewall. This prevents access to sensitive resources such as the Oracle WebLogic Server console and Oracle Enterprise Manager Fusion Middleware Control console from the public domain.

2.3.4 About the DMZ

A DMZ is a means of restricting access to components of your infrastructure to those that actually need it. In the examples in this guide, there is a public DMZ. This is where the outside world gains access to your systems. You place into this zone only those components that the outside world must access, such as the Load Balancers and Web Tiers. If users from the outside world attempts to access any servers or services below this zone, they are prevented from doing so by firewalls. The public zone is configured so that the servers in this zone can interact with the application servers in the private zone.

• The public zone–This is where the outside world gains access to your systems. You place into this zone only those components that the outside world must access, such as the Load Balancers and Web Tiers. If users from the outside world attempts to access any servers or services below this zone, they are prevented from doing so by firewalls.

  The public zone is configured so that the servers in this zone can interact with the application servers in the private zone.

• The intranet zone–This is where you place servers that contain core services, such as databases. These services are very tightly controlled by the organization as they contain the most sensitive data.

By using this approach, you restrict access to information to only those components that require it. This approach is useful where you have users coming in from outside of your organization. If, instead of an extranet, you are setting up an intranet, where all communication is from trusted sources, then you might reasonably decide to do away with the public DMZ.

2.3.5 About the Application Tier

The application tier is the tier where Oracle SOA and Java EE applications are deployed. Products such as Oracle WSM, Oracle SOA Service Engines, Oracle BPEL Caches and Oracle Service Bus are deployed in this tier. Applications in this tier benefit from the High Availability support of Oracle WebLogic Server and Oracle Fusion Middleware.

In this tier, two compute nodes named SOAHOST1 and SOAHOST2 run Oracle WebLogic managed servers for running SOA components, such as BPEL Process Manager. The managed servers are configured for active-active mode.

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.

Oracle Web Services Manager (Oracle WSM) provides a policy framework to manage and secure Web services in the Exalogic enterprise deployment topology.

Applications requiring external HTTP access use Oracle Traffic Director as proxy.

Oracle WebLogic Server Console, Oracle Enterprise Manager Fusion Middleware Control console, and Oracle Fusion Middleware SOA Consoles are only accessible through a virtual host configured on the load balancer, which is only available inside the firewall.

2.3.5.1 Architecture Notes

• The Oracle WebLogic Server Administration Console and Oracle Enterprise Manager Fusion Middleware Control are always bound to the listen address of the Administration Server.

• The WebLogic Administration Server, (running both Oracle Enterprise Manager Fusion Middleware Control and Oracle WebLogic Server Administration Console), is a singleton service. It runs on only one node at a time. In the event of failure, it is restarted on a surviving node that can mount the exact same path and contents that the Admin Server used in its original node.

• The managed servers WLS_SOA1 and WLS_SOA2 are deployed in a cluster, and Oracle SOA Infrastructure, Service Engines, and Adapters are deployed to this cluster.

• The managed servers WLS_WSM1 and WLS_WSM2 are deployed in a cluster and run Oracle Web Service Policy Manager.

• The managed servers WLS_OSB1 and WLS_OSB2 are deployed in a cluster and run Oracle Service Bus.

• Additional JVMs are created and started in each of the available compute nodes (SOAHOST1 and SOAHOST2) to run Coherence Caches for BPEL Dehydration.

2.3.6 About the Identity and Policy Stores

Authorization policies are stored in Oracle Database and either Oracle Internet Directory or Oracle Unified Directory are used for authentication. For more information, see the Oracle Exalogic Elastic Cloud Enterprise Deployment Guide for Oracle Identity Management.

2.4 Hardware Requirements for the Oracle SOA on Exalogic

The following sections describe the hardware requirements for the SOA enterprise topologies on Exalogic:

• Hardware Load Balancer Requirements

• Exalogic Machine Requirements

2.4.1 Hardware Load Balancer Requirements

The Oracle Fusion Middleware Exalogic enterprise deployment requires a hardware load balancer to route requests to the Web tier. For information about the minimum set of features required for the load balancer in this topology, see Section 3.7.1, "Load Balancer Requirements."

2.4.2 Exalogic Machine Requirements

Oracle Exalogic is an integrated hardware and software system designed to provide a complete platform for a wide range of application types and widely varied workloads. Exalogic is designed to fully leverage an internal InfiniBand fabric that connects all of the processing, storage, memory and external network interfaces within an Exalogic machine to form a single, large computing device.

For complete information about the hardware options available for Exalogic machines, see "Exalogic Hardware Configurations" in the Oracle Exalogic Elastic Cloud Machine Owner's Guide.

For any of the topologies described in this guide, an Exalogic machine eighth rack can be used. For more information, see Section 2.2, "Viewing the Oracle SOA Deployment Topology on Exalogic."

You can assign the compute nodes on the Exalogic rack as follows:

• Assign two compute nodes to the Application Tier. These will be referred to as SOAHOST1 and SOAHOST2.

• For Oracle Traffic Director, assign two additional compute nodes to the Oracle Traffic Director instances. These will be referred to as WEBHOST1 and WEBHOST2.

2.5 Software Components for an Exalogic Enterprise Deployment

This section describes the software required for an Oracle SOA Exalogic enterprise deployment.

This section contains the following topics:

• Section 2.5.1, "Software Required for the Oracle SOA Deployment Topology on Exalogic"

• Section 2.5.2, "About Obtaining Software"

• Section 2.5.3, "Applying Patches and Workarounds"

2.5.1 Software Required for the Oracle SOA Deployment Topology on Exalogic

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

Table 2-1 Software Versions Used

Product	Version
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.
Oracle Traffic Director	11.1.1.7.0
Oracle JRockit	jrockit-jdk1.6.0_29-R28.2.0-4.0.1 or newer
Oracle WebLogic Server	10.3.6.0
Oracle SOA Suite	11.1.1.7.0
Repository Creation Assistant	11.1.1.7.0
Oracle Service Bus	11.1.1.7.0

2.5.2 About Obtaining Software

For complete information about downloading Oracle Fusion Middleware software, see the Oracle Fusion Middleware 11g Release 1 Download, Installation, and Configuration Readme for this release, at: http://docs.oracle.com/cd/E23104_01/download_readme.htm

2.5.3 Applying Patches and Workarounds

See the Oracle Fusion Middleware Release Notes for your platform and operating system for a list of patches to apply. You must apply the patches to ensure that your software operates as expected.

Patches are available for download from http://support.oracle.com. You can find instructions for deploying each patch in the enclosed README.html file in each patch archive.

2.6 Road Map for the Reference Topology Installation and Configuration

Before beginning your Oracle SOA Exalogic enterprise deployment on Exalogic, review the flow chart in Figure 2-2, "Flow Chart of the Oracle SOA Exalogic Enterprise Deployment Process". This flow chart illustrates the high-level process for completing the Exalogic enterprise deployment documented in this guide. Table 2-2 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:

• Section 2.6.1, "Flow Chart of the Oracle SOA Exalogic Enterprise Deployment Process"

• Section 2.6.2, "Steps in the Oracle SOA Exalogic Enterprise Deployment Process"

2.6.1 Flow Chart of the Oracle SOA Exalogic Enterprise Deployment Process

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

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

2.6.2 Steps in the Oracle SOA Exalogic Enterprise Deployment Process

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

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

Step	Description	More Information
Review the Exalogic Enterprise Deployment Topology	Review the recommended topology and plan the topology best suited for your organization and applications.	Section 2.1, "Planning Your Deployment"
Prepare the Network for an Exalogic Enterprise Deployment	To prepare your network for an Exalogic 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, "Configuring the Network for an Exalogic Enterprise Deployment"
Prepare your File Storage Appliance for an Exalogic Enterprise Deployment	To prepare your file system for an Exalogic enterprise deployment, review the terminology for directories and directory environment variables, and configure shared storage.	Chapter 4, "Configuring Storage for an Exalogic Enterprise Deployment"
Prepare the Compute Nodes for an Exalogic Enterprise Deployment	To prepare your servers for an Exalogic enterprise deployment, ensure that your compute nodes meet hardware and software requirements, enable Unicode support and Virtual IP Addresses, mount shared storage, configure users and groups, and, if necessary, install software onto multi-homed systems.	Chapter 5, "Configuring the Compute Nodes for an Exalogic Enterprise Deployment"
Prepare the Oracle RAC Database for an Exalogic Enterprise Deployment	To prepare an Oracle RAC database for an Exalogic 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 6, "Configuring a Database for an Exalogic Enterprise Deployment"
Install and Configure Oracle Traffic Director on Exalogic Compute Nodes	Install and configure Oracle Traffic Director.	Chapter 7, "Installing and Configuring Oracle Traffic Director for an Exalogic Enterprise Deployment"
Create the Initial WebLogic Server Domain	Run the Configuration Wizard to create the initial WebLogic Server domain.	Chapter 8, "Creating a Domain for an Exalogic Enterprise Deployment"
Extend the Domain for Oracle SOA	Use the Configuration Wizard to extend the domain to include Oracle SOA components.	Chapter 9, "Extending the Domain for SOA Components"
Extend the Domain for BPM Components	Use the Configuration Wizard to extend the domain to include Oracle BPM.	Chapter 10, "Extending the Domain to Include Oracle BPM"
Extend the Domain for Oracle Service Bus	Use the Configuration Wizard to extend the domain to include Oracle Service Bus.	Chapter 11, "Extending a SOA Domain to Oracle Service Bus"
Configure Node Manager	Set up Node manager by enabling host name verification, starting Node Manager, and configuring WebLogic Servers to use custom keystores.	Chapter 12, "Setting Up Node Manager for an Exalogic Enterprise Deployment"
Configure Server Migration	Configure server migration for the WLS_OSBIM1, WLS_SOA1, WLS_OSB2, and WLS_SOA2 Managed Servers. The WLS_OSB1 and WLS_SOA1 Managed Server are configured to restart on SOAHOST2 should a failure occur. The WLS_OSB2 and WLS_SOA2 Managed Servers are configured to restart on SOAHOST1 should a failure occur.	Chapter 13, "Configure Server Migration for an Exalogic Enterprise Deployment"