Architecture

There are potentially a lot of complex components within a 10g AS installation. To facilitate the implementation of this product, the software is broken into two basic types of installations: Infrastructure and middle-tier (mid-tier). Clients connect to the mid- tier installation, as you would typically expect. This is where the web and application server activities of processing requests and returning content occur. The Oracle Infrastructure installation works behind the scenes and handles OID, SSO, security, and metadata about all mid-tier installations. We'll cover details of both types of installations, but first it's necessary to understand Oracle's terminology for these products.

Terminology

Oracle DBAs are familiar with the term instance in relation to a database's memory structures and processes vs. a physical database. Although some people may use these terms interchangeably, it's technically incorrect to do so. Worse yet, when reading documentation or discussing problems with other administrators, this misuse of terms can lead to confusion, misunderstanding, and possibly incorrect action by an administrator. Therefore, we'll begin the discussion of architecture with a description of terms specific to Oracle and 10g Application Server.

Hierarchy

The hierarchy of the 10g AS stack, from the largest to the smallest organizational unit, is shown in Figure 15-3.

image from book
Figure 15-3: Component hierarchy

The hierarchical components can be described as follows :

  1. Node. This is the physical hardware, or server, running the software. In future examples throughout this text, the node name is mike.wessler.name , which is the server name (a name that Michael registered).

  2. Installation. The Oracle software as installed in an ORACLE_HOME directory on a node. There can be multiple, separate software installations on a single node as long as they're in separate ORACLE_HOME directories. As you'll see later, the ORACLE_HOME directory in our example is /u01/app/oracle/product/9.0.4mt1/OraHome1 .

  3. Instance. An instance is the running OHS, OC4J, and background processes associated with one installation. An instance would have a name, such as 904mt1 and is something you would start . This is different than an installation, which is the software files that are installed . There can only be one distinct instance per distinct software installation.

  4. Instance components. Within an instance, there are different subcomponents running. One example would be the OHS server or Web Cache server. There can also be multiple subtypes of a component within an instance. An example would be OC4J. There are often multiple OC4J containers running within an instance. One OC4J container would be OC4J home , which is the default OC4J container. Another OC4J container often found is the BI container, which is responsible for Forms, Reports, and Discoverer. Each time a custom J2EE application is created and deployed, it can run in its own OC4J container. Therefore, there can be multiple separate OC4J containers running simultaneously within an instance.

Each OC4J container running within the application server instance is referred to as an OC4J instance. This is somewhat confusing because you have OC4J instances running within a 10gAS instance. In the preceding example you would have an OC4J home instance, OC4J BI instance, and possibly a J2EE OC4J application called Payroll. Each of these is referred to as an OC4J instance that resides within the application server instance 904mt1. Finally, within each OC4J instance, multiple OC4J processes may be running with multiple threads. These are covered later in the OC4J chapters.

Instances, Farms, and Clusters

10g AS installations come in two basic configurations: Infrastructure and middle tier. Within the middle tier (mid-tier) type, there are further classifications depending entirely on the relationship with any Infrastructure installation: farms and clusters.

Every installation has one and only one instance. If it exists without being associated with an Infrastructure installation (either local or remote), it's a standalone instance . These types of basic standalone installations are easy to install (as we covered in Chapter 3), but they cannot fully take advantage of the advanced features of 10g AS.

When a mid-tier instance is associated with an Infrastructure instance, it becomes part of a 10g AS farm . The Infrastructure instance may be on the same machine as the mid-tier or it may be remote, even on a different platform (for example, Solaris or HP-UX). It's necessary that the farm members should be the same base version (such as 9.0.4) and have connectivity to the infrastructure. A mid-tier installation may join a farm at installation time or after it has been installed. A mid-tier installation can be a member of only one farm. The Oracle Infrastructure installation can support only one farm as well, but that farm may have multiple mid-tier installations as members (farm instances). Each mid-tier farm instance can be started, stopped , and configured separately from each other. There's no inherent dependency between mid-tier farm instances; there's just a dependency on the single Oracle Infrastructure installation.

In Figure 15-4 you see a diagram showing the relation between mid-tier installations and the Oracle Infrastructure.

image from book
Figure 15-4: Mid-tier integration with the Oracle Infrastructure

An application server cluster isn't the same as a hardware cluster, and an application server cluster doesn't need a hardware cluster. A hardware cluster is two or more nodes (physical servers) joined together; typically, they share a disk resource. An application server cluster is when two or more mid-tier farm instances are attached to the same infrastructure and share an identical application configuration.

The idea behind application server clusters is that when a browser sends a request to a website, it's transparently routed to one member of the cluster for processing. Typically, whichever member of the cluster is least busy will get the request. This is done so that a pool of dedicated servers can process a very large number of requests. These servers can support more work than any one server, no matter how big it is. Because each cluster has an identical configuration, any member can process any request. The additional benefit is that if one member of the cluster dies, crashes, or is otherwise unable to process requests, the workload is shifted to the other surviving members of the cluster.

From an architectural standpoint, members of a cluster are members of the same farm. These members can exist on the same physical node or on separate nodes. Furthermore, they're identically configured to handle requests. Changes to one member are automatically propagated to other members and the infrastructure via the Distributed Configuration Management (DCM) process. Each member is dependent on the infrastructure and is updated with each other's status. In the event one member of the cluster fails, the others can pick up the processing. Clustering is a major benefit of using 10g AS and Chapter 21 covers it in detail.

Infrastructure

Every 10g AS mid-tier installation, except for a standalone J2EE and Web Cache, requires a 10g AS Infrastructure prior to installation. The 10g AS Infrastructure installation contains a fully functioning J2EE and OHS web server and Oracle 9i Enterprise Edition database, yet the web server and database don't directly support any customer applications or data. The single responsibility of the Oracle Infrastructure is to support the 10g AS middle-tier installations, which are the ones that support browser requests. The key functions of the Oracle Infrastructure are

  • Managing metadata about mid-tier installations

  • Maintaining state and coordination between clustered mid-tier instances

  • Implementing Oracle's security and user management polices via OID and Single Sign-On

To support these activities, the Oracle Infrastructure is broken into different components. In Figure 15-5 you can see a diagram identifying these components.

image from book
Figure 15-5: 10g AS Infrastructure components

In this diagram you can see that the Oracle Infrastructure has the basic components of any 10g AS installation: OHS server, OC4J, and the background processes OPMN and DCM. It also contains a Metadata Repository database and Identity Management components.

Oracle HTTP Server and J2EE Components

To be accessible for the Identity Management features as well as normal administration duties , the infrastructure does have the standard OHS and J2EE components found in any installation. Oracle Corporation doesn't recommend using Web Cache with an infrastructure. As stated previously, the OHS and J2EE are fully functional, but they aren't intended to support customer applications directly.

The OHS server acts as an Apache web server. Any incoming web requests are received and the URL is parsed to determine which module plug-in should process it. Given that this is the infrastructure, mod_plsql for Portal and OID or mod_oc4j will parse most requests. The requests are passed off to the appropriate module for processing and the results are later returned to the client browser.

The OC4J containers within the infrastructure are the OC4J home, OC4J_SECURITY , and oca . Although an OC4J instance can be used to run J2EE applications written by developers, OC4J is also used internally within the instance to support many Oracle components that are implemented within 10g AS. Inside the infrastructure, OC4J is used to support internal operations. Therefore, OC4J is used directly to implement J2EE applications and indirectly to support internal components within the instance. The role and operation of OC4J support with regards to developer written J2EE applications is covered in detail in Chapter 17.

Oracle Process Management Notification and Distributed Configuration Management

The OPMN and DCM processes are key background processes within 10g AS. They're found within both infrastructure and mid-tier installations. Their primary jobs are to make sure all components within the instance are running and to communicate configuration and status updates with the infrastructure and any members of a cluster.

OPMN

OPMN system is the background process that manages all the individual components for a given 10g AS instance. Every component within 10g AS, except for the web-based Application Server Control utility and the Oracle Metadata Repository database is managed by OPMN.

When an installation is set up, specific components are configured and expected to be running. For example, a J2EE installation would have at a minimum OHS and the single OC4J home instance. Each of these interrelated processes is managed by OPMN. If a process dies, OPMN restarts it, if possible. OPMN continually polls the processes it manages and expects them to be up and restarts them if they die or become unreachable. OPMN acts as the managing process for component processes within an individual 10g AS instance.

Synchronization information between related components within the instance is exchanged by OPMN. Automatic collection of performance statistics for both the server node and 10g AS components is another responsibility of OPMN. Since OPMN manages all the instance components, it must be running before starting any OPMN processes such as OHS or OC4J.

OPMN is composed of two subprocesses: Process Manager (PM) and Oracle Notification System (ONS). They exist within OPMN but cannot be separately identified on the system with a ps ef command.

Note 

Together PM and ONS form OPMN, which is a key controlling process. We cover command-line utilities that manage and monitor the OPMN process in Chapter 16.

PM is the managing subprocess that actually starts, stops, and restarts processes. It uses the ONS system to communicate startup and shutdown information to components.

ONS notifies other processes of any kind of failures or restarts of processes. These can be other instances on remote machines or subprocesses within the same instance. To determine which nodes are on the notification list, review the contents of the ons.conf file located in $ORACLE_HOME/opmn/conf , as shown here:

 $ cd $ORACLE_HOME/opmn/conf $ more ons.conf nodes=mike.wessler.name:6200 $ 

Here you see that only the mike.wessler.name node is listening on port 6200 for ONS notifications.

Note 

OPMN forces you to use the OPMN and DCM utilities to manage OHS, instead of operating system tools. When Michael was first working with 9iAS 9.0.2, he didn't fully appreciate the role of OPMN. One day he wanted to restart OHS, but OEM had timed out and failed to start so he couldn't use it to manage OHS. There were lingering operating system processes, so he started killing them with the UNIX kill command because he knew apachectl / httpdsctl were depreciated. Every time he killed these processes, they got restarted. Then he realized that his manual efforts were fighting against the OPMN process. Ultimately, the OPMN process "won," as it should, and he gained confidence in the restart processes. He retested this under 9.0.4. A minute or two after manually killing all the Apache processes, he found them to be restarted by OPMN.

Configuration for OPMN is done within the opmn.xml configuration file located in $ORACLE_HOME/opmn/conf . Within this file you can modify ports, logging levels, number of processes, and flags for automatic restart for each OPMN-managed component. Individual components such as OHS, OC4J, OID, Web Cache, Wireless, LogLoader, Reports, and Discoverer can be configured.

Logs for OPMN are found in $ORACLE_HOME/opmn/logs . These are especially useful when experiencing errors during startup or after a configuration change.

For performance monitoring of OPMN managed processes, Oracle provides the graphical High Availability Tool (Hi-AV or iHAT). It can be downloaded from Oracle Technology Network (OTN) at http://otn.oracle.com/products/ias/ias_utilities.html . This tool uses the Dynamic Monitoring Service (DMS) to take snapshots of all the OPMN managed processes and performance statistics for each. The real-time output can be displayed to a web browser for easy monitoring.

Distributed Configuration Management

DCM works in conjunction with OPMN and has the primary responsibility of synchronizing the instance components (such as OC4J and OHS) with the Metadata Repository. Though OPMN works internally within the instance, DCM communicates instance updates externally to other instances and the Metadata Repository. This is especially important when the midtier instance is part of a cluster; however, synchronization also takes place when it's part of a farm as a nonclustered instance. DCM makes sure that the configuration files of the installation $ORACLE_HOME file system are in sync with the repository. Furthermore, any updates to any clustered instance are logged in the repository and propagated to all other members of that cluster. Even if the mid-tier installation isn't associated with an infrastructure instance as part of a farm, configuration updates are stored in a file-based repository just for that standalone instance.

DCM manages the configuration of each component within the instance and its synchronization with the repository. It manages the configuration for OHS, OC4J and OC4J applications, OPMN, and the Java Authentication and Authorization Service (JAZN), which is covered in Chapter 17. If it's part of a cluster, DCM will automatically propagate the configuration changes to other members of the cluster once they've been applied successfully to the local instance. In cases in which these changes fail locally, they will be rolled back and not propagated. Remote instances that cannot, for whatever reason, have the changes successfully applied, will have their synchronization status labeled false by the DCM and the administrator will need to resolve the problem.

Each configuration set for an installation can be saved as an archived snapshot so that you can restore an installation to a previous configuration. This is a way to recover from problems resulting from a deployment or configuration change. Configurations can also be exported from one instance and imported into another instance as a way to effectively clone a configuration (DCM automatically updates node-specific information). A backup of the configuration can occur automatically or can be performed on an ad hoc basis by the administrator. This DCM activity is detailed in Chapter 16.

There are three types of repositories that DCM will maintain, depending on the software installation topology:

  • File-based repository for standalone instances is used for J2EE and Web Cache installations in which the instance isn't associated with a farm or cluster. This is located locally and just contains information specific to the local installation. Regardless of installation type, all installations will have a local file-based repository.

  • File-based repository with repository hosts is a shared repository for members of a farm or cluster. It exists on disk as a set of files and contains configuration and software metadata for each mid-tier installation. Use this method if you don't want the overhead of managing a full Oracle database instance that contains repository information. However, Oracle doesn't recommend this for large installations with more than four mid-tier instances.

  • Database repository, which is used for large environments where there are many mid-tier instances as part of the farm. Specifically, it's an Oracle 9i Enterprise Edition database that's dedicated to supporting the infrastructure. It can be installed with the infrastructure installation or an existing database may be configured for this use. Though more cumbersome than a simple file-based repository, it provides all the performance, security, and backup and recovery benefits of the Oracle database instance. This is named the asdb database instance by default.

All installations will contain a local file-based repository. When installing software that will be part of a farm, the installer will prompt you to choose either a shared file-based repository, or the database repository.

Logs for DCM are located in component-specific subdirectories beneath $ORACLE_HOME/dcm/logs .

DCM has a command-line utility ( dcmctl ) that's covered in Chapter 16. Examples of DCM in the clustered environment are shown in Chapter 21.

Metadata Repository

The Metadata Repository most commonly used with infrastructure installations is the database repository instance asdb . This database can either be created at installation time as asdb as a preseeded instance, or it can be installed in a preexisting instance (as long as it meets the installation requirements) using the Repository Creation Assistant.

The Metadata Repository contains the following information:

  • Product metadata. Information related to the software topology of the mid-tier installations it supports. Specifically, it knows who the members of the farms are, where they're located, what type of mid-tier installations they are, and what, if any, clusters exist.

  • Identity Management metadata. Information used to support Oracle's advanced security and user management products. Essentially , this is OID and SSO. These components can be installed in a separate database if needed.

  • Management metadata. DCM data is stored in the repository as management metadata.

The Metadata Repository is essentially just an Oracle database that's used to store information about the mid-tier instances and their configurations. It must be configured to listen on a 9i listener on port 1521.

Prior to starting the infrastructure instance's web processes, you must make sure the Metadata Repository database is running and accessible. OPMN and DCM command utilities do not start up the database or its listener process. A simple test is to make sure you can connect via SQL*Plus to the database using the listener process. Since this is a critical piece of the infrastructure, either the Oracle DBA should be managing it or the web administrator should be savvy enough with Oracle to know how to start the database and listener. The steps to start the infrastructure database are as follows:

  1. Set your environment variables. The most important variables are ORACLE_HOME and ORACLE_SID .

  2. Start the database listener process, as follows:

     lsnrctl start 
  3. Log in as follows to SQL*Plus as sysdba , which has the ability to start a database:

     sqlplus "/ as sysdba" 
  4. Issue the startup command and exit, as follows:

     startup exit 

Once the database is running, issue the opmnctl startall command to start the OHS and OC4J processes. We cover the startup for OHS and OC4J in greater detail in Chapter 16. All of these processes should be scripted for automatic startup after server reboot. Work with your DBA to make sure the database and listener are started prior to the OHS and OC4J processes.

Identity Management Components

Large organizations typically have a variety of applications that meet the business needs of the company or agency. For example, a company may have Human Resources (HR), Payroll, and Sales departments. Each department may have one or more applications, many of which are web based and use a database. Oftentimes these applications share data, support the same groups of users, and have similar security requirements, yet each user account is distinct and maintained redundantly. The result can be hundreds or even thousands of overlapping users being maintained in multiple databases. Each user is distinctly maintained within each application. This can become cumbersome to manage, especially as job descriptions and employment statuses change. Oracle attempts to improve this process through its Identity Management infrastructure.

Oracle Identity Management is covered in greater detail in Chapter 20, but it's composed of these elements:

  • Oracle Internet Directory (OID)

  • Oracle Single Sign-On (SSO)

  • Oracle Delegated Administration Services (DAS)

  • Oracle Directory Integration and Provisioning (DIP)

  • Oracle Certificate Authority

The key elements of Oracle Identity Management are OID and SSO, and the other elements DAS, DIP, and Certificate Authority play a supporting role. OID provides a method of consolidating all the separate user accounts stored in each application or database into one user account stored in an LDAP directory service. Instead of the same user account being stored redundantly in multiple database applications, it's stored once in OID (which is Oracle's LDAP).

SSO is used when the user attempts to access one of her applications such as Human Resources (HR). The user enters the URL for the HR application and is prompted for a username and password. The user enters that username and password and she's authenticated against the OID database. If successful, the user is able to access that application. However, the user's authentication has now been established so if she attempts to access another application such as Payroll or Sales she isn't prompted again for a username or password. The SSO server uses the authentication that already occurred and grants access into the new application transparently without a login prompt.

This centralized method of managing users, security, and single logins is intended to reduce administrative overhead, improve security, and provide a streamlined user experience. These features are attractive particularly for large organizations and ones with multiple web applications.

The infrastructure for this resides within the OID, which, although it's an LDAP ( not a database), is physically stored in an Oracle database. Since this contains all the user accounts, passwords, and security roles necessary to access all the applications in the organization, it's clearly very important. Therefore, it makes sense to store it in a high performance, highly available Oracle database. This data and the corresponding schemas don't have to be in the same database instance as the Metadata Repository infrastructure. The Identity Management components can be installed into a separate database and accessed by the infrastructure processes when needed. This would be done to improve performance by having OID on a dedicated database server. It also could be on an Oracle Real Application Cluster (RAC) or clustered with failover to improve fault tolerance, which is important given the important nature of the OID data.

Using OID and SSO is optional in 10g AS. Previous versions of 9iAS had additional infrastructure startup steps just for OID such as starting oidmon . 10g AS improves this by consolidating startup of the OID components with the startup of the normal infrastructure instance.

Middle Tier

Infrastructure installations do nothing more than provide back-end support for the middle-tier instances, which do the "real work" of supporting client requests. These are generally installed on separate machines from the infrastructure and are where the client processing occurs. Middle-tier (or mid-tier) instances contain, at a minimum, an OHS as well as OC4J processes that handle Apache and J2EE requests. Additionally, mid-tier instances may be front-ended by Web Cache (detailed in Chapter 19), may be part of a farm or cluster, and may contain additional products such as Oracle Portal, Forms, Reports, Discoverer, and Wireless components.

There are three types of mid-tier installations available. They come with different suites of components, with the idea being that you select the installation type that matches the applications types you support. The types available (from small to large) are

  • J2EE and Web Cache

  • Portal and Wireless

  • Business Intelligence and Forms

Each type comes with the basic OHS, OC4J, and Web Cache components. Additionally, each type contains all the products for the installation type that precedes it plus its own distinct components. For example, Portal and Wireless installations have all the components of the J2EE and Web Cache type. The BI and Forms installation contains the distinct products plus everything included in a Portal and Wireless installation.

Any mid-tier installation type can be clustered or part of an infrastructure farm as long as it's attached to an infrastructure installation. Furthermore, only the J2EE and Web Cache installation can occur without being attached to a preexisting infrastructure. Membership in an infrastructure farm is optional for J2EE and Web Cache, but it's mandatory for Portal, Wireless, BI, and Forms.

Note 

There does exist a lightweight Forms and Reports services installation for those projects that just want basic Forms and Reports. This installation only includes Web Cache, OHS Forms, and Reports. It's a standalone installation and doesn't provide OID or Identity Management.

The following sections contain detailed descriptions of each mid-tier installation type.

J2EE and Web Cache

The smallest and easiest installation type is called J2EE and Web Cache. It's actually one installation type composed of the OC4J, OHS, and Web Cache. It's primarily intended for J2EE applications. Since it contains OHS, it can also host standard Apache applications using PHP, Perl, and CGI. It also contains the module mod_plsql so that it can be used for PL/SQL Web Toolkit applications. The product also comes with Web Cache, which can optionally be configured. As we previously stated, use of an Oracle Infrastructure installation is optional here, unless you want to take advantage of clustering.

Key characteristics of the J2EE and Web Cache install are as follows:

  • Smallest installation at 500 MB

  • Contains Web Cache, OHS, and OC4J components

  • Membership in an infrastructure farm is optional

  • Is the easiest installation type to install, configure, and manage

  • Used for J2EE, generic Apache, and PL/SQL Web Toolkit applications

In Chapter 16, you'll step through a complete J2EE installation.

Portal and Wireless

The next largest installation contains Portal and Wireless. The installation is typically used for Oracle Portal applications. It also has Wireless components and can host any application managed by a J2EE and Web Cache installation because it contains those components. Membership in an Oracle Infrastructure installation is mandatory.

Key characteristics of the Portal and Wireless installation are

  • Mid- sized installation at 900 MB

  • Contains Web Cache, OHS, and OC4J components

  • Contains Oracle Portal and Wireless components

  • Membership in an infrastructure farm is mandatory

  • Used for Oracle Portal and Wireless applications

Portal and Wireless installations aren't common unless they're supporting a strictly Portal application. Generally, if administrators need more than the basic J2EE and Web Cache installation, they go with the most complete installation available, which is the Business Intelligence and Forms installation.

Business Intelligence and Forms

The most complete mid-tier installation type is Business Intelligence and Forms. It contains all the products available in 10g AS except for the Infrastructure. As a result it's a large installation, but it covers the needs of J2EE, Apache, and Oracle Developer Suite applications. Membership in an Oracle Infrastructure installation is mandatory.

Key characteristics of the Business Intelligence and Forms installation are as follows:

  • Largest installation at 1.3 GB

  • Contains Web Cache, OHS, and OC4J components

  • Contains Oracle Portal and Wireless components

  • Contains Oracle Forms, Reports, and Discoverer

  • Membership in an infrastructure farm is mandatory

  • Used for any type of J2EE or a generic Apache application, but is geared towards traditional Oracle applications such as Portal, Forms, Reports, and Discoverer

Administrators that are upgrading Forms applications to 10g AS will use this install type. Customers wishing to gain BI from their data will find the drill-down and ad hoc querying capabilities of Reports and Discoverer useful. Although Oracle Portal is installed with the Portal and Wireless installation, people wishing to use that product typically install this installation just so they have the complete Oracle toolset at their disposal.

Tip 

Although the focus of this text is J2EE development, and Oracle is aggressively pushing its Java products, you shouldn't discount the amount of PL/SQL-driven applications in existence. There are a large number of Forms, Reports, and PL/SQL Web Toolkit applications that, for various reasons, will never be converted to Java. However, from an administrative and architectural standpoint, it's interesting that since 9iAS 9.0.2 these products are managed from within the OC4J_BI_Forms container.

Unless you know for a fact that you'll only support Java J2EE applications, go with the Business Intelligence and Forms installation as long as you're licensed for it. Although it's large and you can always upgrade from a smaller installation, the BI and Forms installation gives you the greatest flexibility.



Oracle Application Server 10g. J2EE Deployment and Administration
Oracle Application Server 10g: J2EE Deployment and Administration
ISBN: 1590592352
EAN: 2147483647
Year: 2004
Pages: 150

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net