1 Overview

This chapter introduces Enterprise Deployment concepts, and summarizes the benefits provided by the Oracle Application Server Enterprise Deployment configurations described in other chapters of this guide. It contains the following topics:

Section 1.1, "What is an Enterprise Deployment?"

Section 1.2, "Benefits of the Oracle Application Server Enterprise Deployment Configurations"

1.1 What is an Enterprise Deployment?

An enterprise deployment is one of the Oracle Application Server configurations described in this guide, designed to support large-scale, mission-critical business software applications. The hardware and software in an Enterprise Deployment configuration delivers:

High quality service

• The system workload is managed and balanced effectively

• Applications continue to operate when resources are added or removed

• System maintenance and unexpected failures cause zero downtime

Built-in Security

• All incoming network traffic is received by the load balancing router on a single, secure port and directed to internal IP addresses within the firewall; inside the firewall, functional components are grouped within DMZs

• User accounts are provisioned and managed centrally

• Delegation of administration is performed consistently

• Security systems are integrated

Efficient software provisioning and management

• Application distribution is simple

• Systems are managed and monitored as one logical unit in a central console

• Death detection and restart mechanisms ensure availability

1.2 Benefits of the Oracle Application Server Enterprise Deployment Configurations

The Oracle Application Server configurations shown in this guide are designed to ensure security of all transactions, maximize hardware resources, and provide a reliable, standards-compliant system for enterprise computing with a variety of applications. This section describes in detail the security and high availability benefits of the Oracle Application Server configurations and how they are achieved.

1.2.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 compliance with standards:

• All external communication received on port 80 is redirected to port 443.

• 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 DMZ is allowed.

• Components are separated between DMZs on the Web Tier, Application Tier, and the Data Tier.

• Direct communication between 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 DMZ.

• Identity Management components such as Oracle HTTP Server, OracleAS Single Sign-On, and Oracle Delegated Administration Services are in the DMZ.

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

1.2.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.

In the Web Server and Application Tiers, communication between components proceeds as follows:

1. The external Load Balancing Router does the following:

   • Receives end user requests on port 443, at the URL portal.mycompany.com, and balances the requests to one of the OracleAS Web Cache listeners on port 7777.

   • Receives invalidation messages from the Application Metadata Repository on port 9401, and balances the requests to one of the OracleAS Web Cache listeners on port 9401. In these cases, the Load Balancing Router functions as a proxy to receive internal requests on port 9401, but this port is not visible to external traffic.

   • Receives web provider design time messages (and the init_session call, for session based providers) on port 7777 from the Application Metadata Repository, and balances the requests to one of the OracleAS Web Cache listeners on port 7777. In these cases, the Load Balancing Router functions as a proxy to receive internal requests on port 7777, but this port is not visible to external traffic.

     
     

     Note: Although OracleAS Web Cache is clustered, invalidation and web provider messages cannot be sent directly to a OracleAS Web Cache server, because if that particular OracleAS Web Cache is not functioning, then there is no way for the Metadata Repository to communicate with the other OracleAS Web Cache instance. The Load Balancing Router's management of the invalidation and web provider messages provides component level high availability.

     
     

2. The Load Balancing Router balances the requests to one of the two OracleAS Web Cache servers on port 7777.

3. Each OracleAS Web Cache server receives the requests from the Load Balancing Router and passes them to one of the two OracleAS Portal Oracle HTTP Servers on port 7778.

   
   

   Note: Since all of the OracleAS Portal sessions are stateless, these requests can be routed from any OracleAS Web Cache server to any OracleAS Portal Oracle HTTP Server, and vice versa. However, if you are using Web Clipping functionality in OracleAS Portal, then you will need to enable stateful binding (as described in Section 7.3.8, "Enabling Session Binding on OracleAS Web Cache Clusters".)

   
   

4. The OracleAS Portal Parallel Page Engine also loops back to the Load Balancing Router (through the internal Network Address Translation port) to reach Portal Services to get the metadata information to construct the page. The Load Balancing Router is configured to handle Parallel Page Engine loop back calls, and load balances them to one of the Webcache listeners on port 7777.

   
   

   Note: The Parallel Page Engine constructs OracleAS Portal pages based on metadata in the Metadata Repository. To read the metadata, it loops back to Portal Services through the local OracleAS Web Cache instance. However, if that OracleAS Web Cache instance is down, there is no way for the Parallel Page Engine to reach Portal Services or the other OracleAS Web Cache instance. If Parallel Page Engine loops back to the Load Balancing Router, the Load Balancing Router can balance requests to Portal Services through the surviving OracleAS Web Cache instance, which can still balance the requests to the Oracle HTTP Server on the first middle tier. This exemplifies component level high availability and intelligent routing for efficient resource utilization.

   
   

5. When the request goes to portal.mycompany.com, OracleAS Portal determines whether the request is authenticated with OracleAS Single Sign-On; if not, it will redirect the request to the OracleAS Single Sign-On URL, login.mycompany.com.

In the Identity Management Tier, communication proceeds as follows:

1. OracleAS Single Sign-On receives a user request at login.mycompany.com.

2. OracleAS Single Sign-On authenticates the credentials with one of two Oracle Internet Directory instances, through the internal Load Balancing Router that is configured to manage Oracle Internet Directory traffic.

   
   

   Note: Two Oracle Internet Directory instances on different computers are using the same Metadata Repository. If the Identity Management components (OracleAS Single Sign-On, Oracle Delegated Administration Services) directly communicate with an Oracle Internet Directory instance, and that instance stops working, then there would be no way for the Identity Management components to redirect the traffic to the surviving Oracle Internet Directory instance. Thus the Load Balancing Router ensures high availability in re-routing traffic from a failed Oracle Internet Directory instance to a surviving instance.