12 Recommended Topologies

This chapter provides an overview of Oracle Application Server recommended topologies. The topics include:

• Introduction to Oracle Application Server Recommended Topologies

• Recommended General Development Topologies

• Recommended General Deployment Topologies

• Special Topologies

Introduction to Oracle Application Server Recommended Topologies

Oracle Application Server, a single integrated platform for any application deployment, offers a variety of topology options. This chapter identifies the most commonly used topologies and discusses some of the major considerations involved with deploying such topologies. The Oracle Application Server recommended topologies fall into three categories:

• General Development Topologies

• General Deployment Topologies

• Special Topologies

Note: Each real-world deployment will have unique characteristics that may vary the optimal topology for that site. The topologies described here are intended to provide high availability, manageability, security, and performance requirements for a broad range of users.

General Development Topologies

General Development Topologies consist of configuration topologies used by the following types of developers:

• Java developers

• Portal and Wireless developers

• Forms and Reports developers

• Integration architects and process modelers

General Deployment Topologies

General deployment topologies are determined based on the following types of usage:

• Enterprise Data Center topologies

• Departmental topology

• Development Life Cycle Support topology

Special Topologies

Oracle Application Server has some special topologies that are consumed as part of the general deployments identified in the previous sections. In order to meet your specific needs, a recommended deployment topology that includes some of the following topologies may be necessary:

• High Availability (HA) topologies

Key Considerations

The following perspectives are presented to best evaluate and recommend appropriate deployment options to satisfy your enterprise’s individual needs. Detailed information on each of these perspectives is available in additional documents, as listed.

Installation

Installation considerations include which install model is best suited for the topology, what types of machines are typically used, and what type of user will be performing the installation. See the Oracle Application Server 10g Installation Guide for your platform for detailed steps to achieve each of these configurations.

Application Deployment and Performance

Deployment and performance considerations include performance goals, component distribution across hardware, application development strategies, and parameter tuning. See the Oracle Application Server 10g Performance Guide for your platform for more information.

Security

Security considerations include what level of security is required, whether components or applications should be isolated to individual hardware nodes, and what third-party security providers will be involved. See the Oracle Application Server 10g Security Guide for more information.

Management

Management considerations include what facilities are required for management, component and application distribution across hardware nodes, and what sorts of backup and recovery methods will be used. See the Oracle Application Server 10g Administrator's Guide for more information.

High Availability Deployment

High Availability (HA) considerations include which HA methodology will be used. See the Oracle Application Server 10g High Availability Guide for more information.

Third Party Products

Third Party Products considerations include which special third party products will be used, and how they will impact the high availability, security, and performance of the topology.

Recommended General Development Topologies

This section describes the following recommended general development topologies:

• Java Developer Topology: Low-end Machines with Java IDE Tools

• Portal and Wireless Developer Topology: Medium-sized Machines

• Forms, Reports, and Discoverer Developer Topology: Medium-sized Machines

• Integration Architect and Process Modeler Topology: Medium-sized Machines

Java Developer Topology: Low-end Machines with Java IDE Tools

The development requirements for Java developers are mainly related to ease of development and deployment. Table 12-1 outlines the key considerations for Java developers.

Table 12-1 Key Considerations for Java Developers

Consideration	Developer Assumptions
Install	O/S patch releases applied quickly Single host installation Latest versions downloaded from OTN, making download size very important Infrastructure Services not heavily used Limited knowledge of Oracle database IDEs such as JDeveloper used for development
Management	Oracle Enterprise Manager Application Server Control installed automatically with each installation Use Application Server Control for: Starting and stopping components as needed Enabling/disabling components to minimize system resource consumption Setting or changing configuration parameters for the J2EE container, Oracle HTTP Server, or OracleAS Web Cache Deploying and configuring applications Managing J2EE application security Monitoring application and component performance and resource consumption in real time Viewing and setting ports Browsing and searching log files Managing application server and J2EE clusters Command line utilities are available for scripting and automation or if you are using standalone components File backup and restore mechanisms are typically used If using Infrastructure Services, use OracleDBA Studio for management
Security	Some interest in file-based JAAS-XML
Application Deployment and Performance	Development occurs on a single node Important that components not being utilized do not impact development compiles, deployment, and start/stop times on limited hardware resources J2EE applications deployed on standalone J2EE and Web Cache installs J2EE applications deployed on Oracle Application Server clusters with or without Web Cache Actual cluster testing likely to happen on a separate test system, not in the development environment Web Cache testing desirable in the development cycle on the development machine Load balancing is important when testing the deployment of applications
High Availability	Not concerned with Infrastructure HA solutions
Third Party Products	None

Figure 12-1 illustrates the recommended topology for the Java developer environment. Note that "O_H" in the figure denotes an Oracle home directory.

Figure 12-1 Java Developer Topology

Description of the illustration j2ee_standalone.gif

Portal and Wireless Developer Topology: Medium-sized Machines

Both Oracle Application Server Portal and Oracle Application Server Wireless developers have similar application deployment requirements. They both need Infrastructure to deploy and test their applications. Table 12-2 outlines the key considerations of Portal and Wireless developers.

Table 12-2 Key Considerations for Portal and Wireless Developers

Considerations	Developer Assumptions
Install	Single host installations Portal and Wireless middle tier install type used Infrastructure install type also required Fair knowledge of Oracle database
Management	Oracle Enterprise Manager Application Server Control installed automatically with each installation Use Application Server Control for: Starting and stopping components as needed Enabling/disabling components to minimize system resource consumption Setting or changing configuration parameters for any of the application server components Deploying and configuring applications Managing application security Monitoring application and component performance and resource consumption in real time Viewing and setting ports Browsing and searching log files Managing infrastructure schemas Use Oracle DBA Studio for managing the infrastructure database Command line utilities are available for scripting and automation File backup and restore mechanisms are typically used
Security	Oracle Application Server Single Sign-On (SSO) Oracle Internet Directory (OID)
Application Deployment and Performance	Wireless applications can be built and tested with only Wireless installed and configured Portlets can be built and tested if both Portal and Wireless are installed and configured JPDK and the Wireless SDK that ship with Oracle Application Server used for development/deployment
High Availability	Not concerned with Infrastructure HA solutions
Third Party Products	Wireless adapters, wireless network gateways (for example, WAP gateway, voice gateway, SMS gateway)

Figure 12-2 illustrates the recommended topology for the Portal and Wireless developer environment.

Figure 12-2 Portal and Wireless Developer Topology

Description of the illustration ascon038.gif

Forms, Reports, and Discoverer Developer Topology: Medium-sized Machines

Oracle Application Server Forms, Oracle Application Server Reports, and Oracle Application Server Discoverer developers have similar application deployment requirements. They need Infrastructure and Oracle Developer Suite to deploy and test their applications. Table 12-3 outlines the key considerations of Forms, Reports, and Discoverer developers.

Table 12-3 Key Considerations for Forms and Reports Developers

Considerations	Developer Assumptions
Install	Single host installations Business Intelligence and Forms middle tier install type Fair knowledge of Oracle database
Management	Oracle Enterprise Manager Application Server Control installed automatically with each installation Use Application Server Control for: Starting and stopping components as needed Enabling/disabling components to minimize system resource consumption Setting or changing configuration parameters for any of the application server components Deploying and configuring applications Managing application security Monitoring application and component performance and resource consumption in real time Viewing and setting ports Browsing and searching log files Managing infrastructure schemas Use Oracle DBA Studio for managing the infrastructure database Command line utilities are available for scripting and automation File backup and restore mechanisms are typically used
Security	Existing Forms developers do not use Single Sign-On (SSO) SSO for some Forms applications SSO for some Reports applications
Application Deployment and Performance	Forms Builder and Reports Builder are part of Oracle Developer Suite. During the development of these applications, the developers can test the applications on the Oracle Application Server instance that comes with Oracle Developer Suite For real deployments, developers need Forms Services and Reports Services
High Availability	Not concerned with Infrastructure HA solutions
Third Party Products	Reports uses Data Direct Adapters and Oracle gateways to access non-Oracle data sources

Figure 12-3 illustrates the recommended topology for the Forms and Reports developer environment.

Figure 12-3 Forms, Reports, and Discoverer Topology

Description of the illustration ascon039.gif

Integration Architect and Process Modeler Topology: Medium-sized Machines

Integration architects and process modelers need the Oracle Application Server ProcessConnect middle tier install. They need appropriate adapters and also Infrastructure to deploy and test their integration applications. Table 12-4 outlines the key considerations of integration architects and process modelers.

Table 12-4 Key Considerations for Integration Architects and Process Modelers

Considerations	Architect/Modeler Assumptions
Install	Single host installations J2EE and Web Cache middle tier install type and Oracle Application Server ProcessConnect Install Infrastructure used for Product Metadata Services (Hub Database) Fair knowledge of Oracle database Good knowledge of applications for which they are building the integration
Management	Oracle Enterprise Manager Application Server Control installed automatically with each installation Use Application Server Control for: Starting and stopping components as needed Enabling/disabling components to minimize system resource consumption Setting or changing configuration parameters for any of the application server components Deploying and configuring applications Managing application security Monitoring application and component performance and resource consumption in real time Viewing and setting ports Browsing and searching log files Managing infrastructure schemas Use Oracle DBA Studio for managing the infrastructure database Command line utilities are available for scripting and automation File backup and restore mechanisms are typically used
Security	Oracle Application Server Single Sign-On (SSO) Oracle Internet Directory (OID)
Application Deployment and Performance	Deployment tool to deploy the model in the Oracle Application Server integration repository that resides in the infrastructure Oracle Enterprise Manager to modify some performance-related properties. Use Enterprise Manager to monitor throughput and latency for Oracle Application Server integration components
High Availability	Not concerned with Infrastructure HA solutions
Third Party Products	Application adapters

Figure 12-4 illustrates the recommended topology for the integration architect and process modeler environment.

Figure 12-4 Integration Architect and Process Modeler Topology

Description of the illustration ascon040.gif

Recommended General Deployment Topologies

This section describes the following recommended general deployment topologies:

• Enterprise Data Center Topology: Multiple Departments Sharing the Same Data Center

• Departmental Topology: Departments Hosting Their Applications

• Development Life Cycle Support Topology: Test to Stage to Production Support

Enterprise Data Center Topology: Multiple Departments Sharing the Same Data Center

There are two Enterprise Data Center topologies, one best suited for Java applications, and one for other applications such as Portal, Wireless, Forms, Reports, and Discoverer. Table 12-5 outlines the key considerations for using the Enterprise Data Center topologies.

Table 12-5 Key Considerations for the Enterprise Data Center Topology

Considerations	Deployment Assumptions
Install	Multiple host installations on hardware clusters, NFS machines Multiple middle tier instances Dedicated Product Metadata Services for Portal applications Shared Product Metadata Services for some applications Shared Security Services throughout the enterprise Support for test to stage to production cycles Oracle Application Server should withstand hard disk replacement, CPU change, or RAM upgrades
Management	Oracle Enterprise Manager Application Server Control installed automatically with each installation Use Application Server Control for: Starting and stopping components as needed Enabling/disabling components to minimize system resource consumption Setting or changing configuration parameters for any of the application server components Deploying and configuring applications Managing application security Monitoring application and component performance and resource consumption in real time Viewing and setting ports Browsing and searching log files Managing infrastructure schemas Command line utilities are available for scripting and automation Backup and recovery: complete cold backup of the entire distributed environment
Security	Global OID/SSO or logical SSO (one or more SSO) sharing the same logical OID (one or more OID) Both SSO and OID behind the external firewall for internal users When hosting applications for both internal and external users (such as MOC), security considerations will need to make sure that some security services can be shared by both types of users Integrating with departmental third party directories such as iPlanet, ActiveDirectory, or eDirectory Provisioning and de-provisioning users
Application Deployment and Performance	J2EE applications deployed on Oracle Application Server clusters with or without Web Cache Portal application using Web Cache, even on a single node environment Forms applications working against an OLTP system with no SSO BI applications working against a data warehouse with tighter security All applications accessible by Portal and Wireless devices Self Service Applications using IP and Workflow
High Availability	Infrastructure HA: Multiple types of HA solutions for different Infrastructure Services Optional: OPMN-based cluster management for middle tier applications
Third Party Products	Firewall, load balancers, hardware clusters, hardware accelerators

Enterprise Data Center Topology for Java Applications

The following recommendation assumes that you want to create new databases for Product, Management, and Security services. If you choose to use an existing database, the product metadata will inherit the high availability solution already deployed for that database.

Figure 12-5 illustrates the recommended topology for the enterprise data center environment when deploying Java applications.

Figure 12-5 Enterprise Data Center Topology for Java Applications

Description of the illustration ascon047java.gif

Enterprise Data Center Topology for Portal, Wireless, Business Intelligence, and Forms Applications

The following recommendation assumes that you want to create new databases for Product, Management, and Security services. If you choose to use an existing database, the product metadata will inherit the high availability solution already deployed for that database.

Figure 12-6 illustrates the recommended topology for the enterprise data center environment when deploying Portal, Wireless, Business Intelligence, and Forms applications.

Figure 12-6 Enterprise Data Center Topology for Portal, Wireless, Business Intelligence, and Forms Applications

Description of the illustration ascon047pwbi.gif

Departmental Topology: Departments Hosting Their Applications

The Departmental topology consists of a subset of considerations and requirements from the Enterprise Data Center topology. Table 12-6 outlines the key considerations for using the Departmental topology.

Table 12-6 Key Considerations for the Departmental Topology

Considerations	Deployment Assumptions
Install	Multiple host installations on cluster machines, NFS machines Multiple middle tier instances used No Infrastructure used if deploying only Java or J2EE applications Dedicated Product Metadata Services for Portal applications Shared Product Metadata Services for some applications Shared Security Services to secure subset of enterprise-level users Management Services Oracle Application Server should withstand hard disk replacement, CPU change, RAM upgrades, or Network interfaces
Management	Oracle Enterprise Manager Application Server Control installed automatically with each installation Use Application Server Control for: Starting and stopping components as needed Enabling/disabling components to minimize system resource consumption Setting or changing configuration parameters for any of the application server components Deploying and configuring applications Managing application security Monitoring application and component performance and resource consumption in real time Viewing and setting ports Browsing and searching log files Managing infrastructure schemas Command line utilities are available for scripting and automation Backup and recovery: complete cold backup of the entire distributed environment
Security	Single install that would contain both Infrastructure Software and OID/SSO data Contains subset of users as compared to the enterprise OID
Application Deployment and Performance	Important not to pay overhead for enterprise topology services OHS used as load balancer for multiple OC4J instances J2EE applications deployed on Oracle Application Server clusters with or without Web Cache Portal applications using Web Cache
High Availability	HA requirement for departmental deployment depends on the nature of the application If there is a requirement, recommendation is to use Local Data Guard of Cold Failover Cluster If there is no requirement, complete cold backup and recovery methodology is used
Third Party Products	Depending on the load on the application, load balancers might be needed

Figure 12-7 illustrates the recommended topology for the Departmental topology.

Figure 12-7 Departmental Topology

Description of the illustration ascon041.gif

Development Life Cycle Support Topology: Test to Stage to Production Support

There might be a situation using either the Enterprise Data Center and Departmental topologies that would require complete support for the development life cycle. This consists of seamless support to move an application from the test environment to the staging environment, and from there to the production environment. Table 12-7 outlines the key considerations for supporting the entire development life cycle.

Table 12-7 Key Considerations for the Development Life Cycle Support Topology

Considerations	Deployment Assumptions
Install	Test Environment: Single host for middle tier and Infrastructure (all services from one database) Staging Environment: Multiple middle tiers on one single large machine or on multiple machines, with either dedicated or shared Product Metadata Services, but always shared Security Services Production Environment: Very similar to the staging environment, except now using enterprise-wide Security Services Oracle Application Server should withstand hard disk replacement, CPU change, or RAM upgrades
Management	Test Environment: For application server installations use Application Server Control. For standalone components use command line tools. Staging Environment: Application Server Control Production Environment: Application Server Control
Security	Moving security requirements Re-association of Security Services is required
Application Deployment and Performance	Shutdown, startup, and deploy times are priorities Frequent reconfiguration of tunable parameters needs to be fast May have multiple versions installed and running Load balancing and application combinations will be tested on one machine
High Availability	Test Environment: Not a concern for the test environment itself, applications and specific configuration files will be backed up; however, HA solutions may need to be tested Staging Environment: Cold Failover Cluster or Local Data Guard, complete cold backup Production Environment: RAC or Cold Failover Cluster and Remote Data Guard for disaster recovery, complete cold backup
Third Party Products	Depending on the load on the application, DMZ, firewalls, load balancers, and routers might be needed

The Development Life Cycle Support topology is a combination of other topologies which supports moving applications from test to stage to production environments.

• Test environment: Application developers test their applications in their own environments: Examples of testing environments:

  • Java Developer Topology: Low-end Machines with Java IDE Tools

  • Portal and Wireless Developer Topology: Medium-sized Machines

  • Forms, Reports, and Discoverer Developer Topology: Medium-sized Machines

• Stage environment: QA personnel test all applications before deploying them to the production environment. In this environment, you can use the Departmental Topology: Departments Hosting Their Applications. This topology in a stage environment runs applications from all departments, not just from a single department.

• Production environment: Applications are ready for user by both internal and external users. See Enterprise Data Center Topology: Multiple Departments Sharing the Same Data Center.

Special Topologies

This section describes the following special topologies:

• High Availability Deployments

High Availability Deployments

In Oracle Application Server 10g (9.0.4), all Oracle High Availability (HA) solutions, including Cold Failover Cluster, Data Guard, and RAC, are supported for the Infrastructure.

The topologies described in this section can be combined with any of the general deployment topologies discussed in the previous sections. For example, the following recommended topologies assume that all Infrastructure services are in the same ORACLE_HOME. However, HA deployments can fit into any Infrastructure distributed topology that has been presented in this chapter.

Cold Failover Cluster

Highlights of Cold Failover Cluster include the following:

• Support for all cluster vendors that the database supports, including Sun Clusters, HP Service Guard, and Veritas

• There can be any number of file systems making up a shared file location

• ORACLE_HOME and Oracle Application Server configuration files are on the shared system

• The virtual IP address and virtual hostname are enabled on the active node of the cluster; the ORACLE_HOME should also be in the shared disks

Figure 12-8 illustrates the recommended topology for the HA deployment using Cold Failover Cluster.

Figure 12-8 Cold Failover Cluster

Description of the illustration cfc.gif

Active Failover Clusters

In the initial release of Oracle Application Server 10g (9.0.4), Active Failover Cluster is a Limited Release feature. Please check OracleMetaLink (http://metalink.oracle.com) for the most current certification status of this feature or consult your Sales Representative, before deploying this feature in a production environment.

Highlights of Active Failover Clusters include the following:

• Support for Active/Active Mode

• Infrastructure software on both nodes

• Configuration files are present at both nodes

Figure 12-9 illustrates the recommended topology for the high availability deployment using Active Failover Clusters.

Figure 12-9 Active Failover Clusters

Description of the illustration rac.gif