Oracle® Application Server 10g Advanced Topologies for Enterprise Deployments
10g (9.0.4) Part No. B12115-01 |
|
![]() |
![]() |
This chapter contains the following:
An enterprise topology is an advanced installation and configuration of Oracle Application Server, usually in a large setting such as a data center.
In an enterprise deployment topology, there are three main application server deployment goals:
Ensuring that quality of service exists in the software and hardware configurations in any given topology:
The enterprise systems efficiently managed and balanced workloads;
Applications run efficiently when resources such as hardware, network tools, etc., are added or removed in a deployment topology;
Planned and unplanned activities such as system management tasks have zero downtime in the topology.
Provide a secure application server platform;
Security and Identity Management:
Ensure that users can be provisioned and managed centrally;
Ensure that delegation of administration is possible and done consistently;
Provide the ability to integrate with other security and identity management systems in an enterprise topology.
Software Provisioning and Management:
Simplify and automate application distribution and accessibility;
Ensure that systems can be self managed;
Monitor and manage many systems as one logical unit;
Introduce Oracle Enterprise Manager as a one-stop management tool for managing an enterprise.
To learn more about Oracle Application Server concepts, see Oracle Application Server 10g Concepts.
For requirements and installation information for each of the topologies, see Chapter 11 of the Oracle Application Server 10g Installation Guide.
The following sections describe several configurations in an enterprise topology:
This deployment topology is optimized to support J2EE applications. It contains the components required to run J2EE applications in a secure, high availability environment.
If you have applications that use components from the Portal and Wireless or the Business Intelligence and Forms middle tier types, see Section 1.4, "Enterprise Data Center Topology: Portal, Wireless, and Business Intelligence Applications".
This topology is intended for enterprises who have users internal as well as external to the organization. Requests from external users go through firewalls.
This topology (Figure 1-1) distributes Oracle Application Server components over multiple computers and tiers. Access to the computers in each tier is guarded by firewalls. Generally, you do not want Web servers, which are high risk components for Internet attacks, to have direct access to other computers in the enterprise. You want the requests to go through firewalls.
The distributed topology enables you to scale the number of computers in each tier (to increase performance and availability) without affecting computers in other tiers. For example, if you discover a bottleneck in the computers running OracleAS Web Cache and Oracle HTTP Server, you can add more computers to run those components.
Figure 1-1 Enterprise Data Center Topology: J2EE Applications
This tier is located just inside the outermost firewall. The load balancer gets requests from external users and forwards them to the two sets of computers in this tier. For each set of computers, you should have at least two computers, to serve as a backup and also to improve performance. You can add more computers to each set as necessary.
Internal users also access the Web servers running in this tier.
The computers in this tier run the following components:
One set of computers runs OracleAS Web Cache and Oracle HTTP Server.
This tier runs all the Web servers. Oracle HTTP Server and OracleAS Web Cache handle requests for static objects and J2EE applications. They send the requests to computers in the J2EE Business Logic DMZ tier. To increase performance and availability, the mod_oc4j
module in Oracle HTTP Server performs load balancing and failover.
Another set of computers runs Oracle Application Server Single Sign-On and Oracle Delegated Administration Services.
Oracle Application Server Single Sign-On authenticates internal and external users, and Oracle Delegated Administration Services enable users to edit their profiles in the Oracle Internet Directory.
mod_plsql: If you need the Web servers to invoke mod_plsql applications stored in the customer database, you do not need the J2EE firewall (compare Figure 1-1 and Figure 1-2). The main purpose of the J2EE firewall is to block SQL*Net access from Web servers to the intranet. If you are using mod_plsql, which uses SQL*Net, then you do not want the messages blocked.
Figure 1-2 Enterprise Data Center Topology: J2EE Applications that need to access mod_plsql
In this tier, you run all components of OracleAS Infrastructure 10g, except for Oracle Application Server Single Sign-On and Oracle Delegated Administration Services, which run in the Web Server Tier DMZ.
You install the OracleAS Infrastructure 10g behind another firewall so that Web servers do not have direct access to other computers in the enterprise. Oracle Application Server Metadata Repository and Oracle Internet Directory contain critical data used by Oracle Application Server instances.
OracleAS Metadata Repository contains security metadata, management metadata, and product metadata. J2EE and Web Cache instances and the infrastructure components such as Oracle Application Server Single Sign-On use this repository.
The Oracle Internet Directory contains data for external and internal users. Oracle Application Server Single Sign-On authenticates users based on the data in Oracle Internet Directory.
You can install the OracleAS Metadata Repository and the Oracle Internet Directory in a Real Application Clusters or Oracle Application Server Cold Failover Clusters environment.
In this tier, you deploy and run your applications on J2EE and Web Cache instances. The applications can access the business data in the customer database.
The number of J2EE and Web Cache instances and computers depend on the number of applications that you are running and the number of users. You should have at least two instances so that you can cluster them using OracleAS Clusters. Clustered instances provide greater availability and scalability, and improve performance.
The J2EE firewall prevents Web servers (in the Web Server Tier DMZ) from directly accessing the computers in this tier.
This tier contains the computers that run enterprise processes, including databases that contain the business data. The databases can be in a high availability environment such as Real Application Clusters or Oracle Application Server Cold Failover Clusters. Applications running in the J2EE Business Logic tier can access the databases. If Web servers in the Web Server Tier DMZ become compromised, the intranet firewall prevents the Web servers from accessing the entire corporate intranet.
This deployment topology supports J2EE applications as well as applications that use components in the Portal and Wireless, and the Business Intelligence and Forms middle tiers. If you do not need these components, see Section 1.3, "Enterprise Data Center Topology: J2EE Applications", which describes a topology that uses only the components in the J2EE and Web Cache middle tier.
This topology is intended for enterprises who have users internal as well as external to the organization. Requests from external users go through firewalls.
This topology (Figure 1-3) distributes Oracle Application Server components over multiple computers and tiers. Access to the computers in each tier is guarded by firewalls. This distributed topology enables you to scale the number of computers in each tier (to increase performance and availability) without affecting computers in other tiers. For example, if you discover a bottleneck in the computers running your applications, you can add computers to the Web Server Tier DMZ and run Business Intelligence and Forms middle tiers on them.
Figure 1-3 Enterprise Data Center Topology: Portal, Wireless, and Business Intelligence Applications
A departmental configuration topology is a subset of considerations and requirements that overlap the enterprise data center configuration.
This topology is a smaller scale version of the topology described in Section 1.3, "Enterprise Data Center Topology: J2EE Applications". It consists of an OracleAS Infrastructure 10g with two metadata repositories, and multiple middle tiers. This topology can be used by individual departments within an organization. Users who access this topology are internal to the organization. As such, this topology does not consider security requirements that involve external users.
This topology (Figure 1-4) consists of an OracleAS Infrastructure, plus several middle tiers, including at least one Portal and Wireless middle tier. This topology uses two metadata repositories:
one for product metadata (installed on computer 2). The Portal and Wireless middle tier uses this metadata repository.
one for Identity Management services (installed on computer 1). All the middle tiers use this metadata repository for Identity Management services.
You can install Oracle Application Server middle tiers on additional computers, as needed. You would associate these middle tiers with either metadata repository. For more information, see Oracle Application Server 10g Administrator's Guide.
You can install the infrastructure in a Real Application Clusters or Oracle Application Server Cold Failover Clusters environment. See Chapter 9, "Installing in High Availability Environments" in the Oracle Application Server 10g Installation Guide for specific steps.
This topology makes the following assumption:
When you install the OracleAS Infrastructure 10g, you create a new Oracle Internet Directory.
Install the items in the following order. The computers are listed in Figure 1-4.
Computer 1: Install an OracleAS Infrastructure 10g with Identity Management services and OracleAS Metadata Repository. See Section 6.14, "Installing OracleAS Infrastructure 10g" in the Oracle Application Server 10g Installation Guide for specific steps.This creates a database to contain the OracleAS Metadata Repository. It also creates an Oracle Internet Directory.
Computer 2: Install a second OracleAS Metadata Repository. See Section 6.16, "Installing OracleAS Metadata Repository in a New Database" in the Oracle Application Server 10g Installation Guide for specific steps.When the installer prompts you to register the OracleAS Metadata Repository, enter the connect information for the Oracle Internet Directory created in step 1.The Portal and Wireless middle tier will use this second metadata repository for its product metadata. See Section 6.10, "Can I Use Multiple Metadata Repositories?" in the Oracle Application Server 10g Installation Guide for specific steps.
Computer 3: Install a Portal and Wireless middle tier. See Section 7.10, "Installing Portal and Wireless or Business Intelligence and Forms" in the Oracle Application Server 10g Installation Guide for specific steps.When the installer prompts for Oracle Internet Directory, enter the connect information for the Oracle Internet Directory created in step 1. This Oracle Internet Directory contains the registration for the OracleAS Metadata Repository installed in steps 1 and 2.When the installer prompts for the OracleAS Metadata Repository, select the OracleAS Metadata Repository installed in step 2.
Computer 4: Install a J2EE and Web Cache middle tier. See Section 7.8, "Installing J2EE and Web Cache with OracleAS Cluster and Identity Management Access" in the Oracle Application Server 10g Installation Guide for specific steps.When the installer prompts for Oracle Internet Directory, enter the connect information for the Oracle Internet Directory created in step 1.When the installer prompts for the OracleAS Metadata Repository, select the OracleAS Metadata Repository installed in step 1.
This topology is a combination of other topologies to support moving applications from test to stage to production environments:
Test environment: Application developers test their applications in their own environments. Examples of testing environments can be found in the Oracle Application Server 10g Installation Guide:
Section 10.1, "Java Developer Topology"
Section 10.2, "Portal and Wireless Developer Topology"
Section 10.3, "Forms, Reports, and Discoverer Developer Topology"
Stage environment: Quality assurance personnel test all applications before deploying them to the production environment. In this environment, you can use the topology described in Section 1.5, "Departmental Topology". This topology in a stage environment runs applications from all departments, not just from a single one.
Production environment: Applications are ready for use by users internal and external to the enterprise. See Section 1.3, "Enterprise Data Center Topology: J2EE Applications"
To move applications from a test to a stage environment, you deploy them on middle tiers in the stage environment. The applications use the Identity Management and Oracle Application Server Metadata Repository of the stage environment.
If an application uses custom data in a database, you need to move that data from that database to a database in the stage environment.
You can move applications from a stage environment to a production by deploying the applications and moving any application-specific data from the stage environment to the production environment.
Another method is to use the rejoin feature, which enables you to unjoin a middle tier from its infrastructure and associate it with a different infrastructure. You can use this feature to move middle tiers (and their applications) from stage to production.
You still need to move application-specific data stored in a stage database to a database in the production environment.
Rejoining middle tiers is convenient if you need additional computers and application server resources for the production environment. In one step, you can add a computer that already has a middle tier and deployed applications.
See the Oracle Application Server 10g Administrator's Guide for details on rejoining middle tiers.