Oracle9iAS Architectural Overview Oracle Application Server Tips by Burleson Consulting

Beginning with the Oracle Web server product in the 1990s, Oracle has continuously improved and streamlined its products into a comprehensive solution for Web based applications.

Oracle9iAS is the latest incarnation in a long evolution of Oracle application products.  Starting in the mid 1990?s with Oracle WebServer and Oracle Application Server (OAS), Oracle9iAS has evolved into an extremely sophisticated system of inter-related modules, all of which can be configured according to your specifications.  There are two ways to view Oracle9iAS, one from a functional level and another from an architectural level.  Let?s begin with an architectural overview of Oracle9iAS.

The Oracle9iAS Multi-tiered Model

As Oracle products evolved into a multi-tiered architecture, we started to see Oracle products reside at several ?tiers? or hardware levels.  These tiers are layers that represent hardware layers, with each tier being comprised of one or more servers. (Figure 1.1).  Because of the flexibility of Oracle9iAS, Oracle shops can adopt a two-tiered, three-tiered, or four-tiered model.  As a general rule, the larger system will have more levels and more servers at each level.

Figure 1: Oracle application tiers and Oracle component products

At each one of these layers we see important Oracle9iAS components. 

• The Client tier ? This is comprised of the web browsers for the end-users.

• The Web Tier - The web-tier comprises the Oracle HTTP Server and the web cache.

• The App Server tier ? This comprises the core Oracle9iAS, plus ancillary products such as Oracle Portal, Oracle Developer, Oracle Reports and Oracle Forms Server.

• The Database Tier ? This is the layer that is the core Oracle database.  It may be a single instance, or many instances defined to a RAC cluster.

It?s important to note that not all shops will use all four tiers.  For smaller shops, it is common to combine multi tiers into the same level.  The choice of the number of tiers is directly related to the size of the Oracle9i implementation and the number of servers that are dedicated to the system.

For small shops, it is common to see a two-tier to data model (Figure 1.2).  Here we see the client tier consisting of all of the external PC clients and a combination of the Web server tier, the App Server tier, and the database tier, all running on a large single server, usually with lots of RAM and multiple CPUs.  The benefit of this approach is the shared server resources because the single server will be able to supply additional CPU and RAM processing according to the specific demands of each of the Oracle9iAS components.  The downside of the two-tiered architecture is the limited flexibility.  This is because it is not easy to add additional hardware resources on as-needed basis.

Figure 2: The Oracle9iAS architecture for a two-tiered system

In medium-sized shops, the three tier data model predominates (figure 1.2)  In the three tier model, we see the client tier, followed by the separation of the Web Server tier and App Server on separate server.  The database tier is also separated onto a different server, thereby providing isolated data resources for the Oracle database.  The benefits of the three tier data model are that increases in processing demands either at the database or the App Server level will not affect the performance of the other components within the Oracle9iAS architecture.  Another benefit is that additional Oracle9iAS instances can be created, and additional Oracle SGA regions can be easily added when processing demands warrant an increase.

Figure 3: The Oracle9iAS architecture for a three-tiered system

Now that we see the components of each tier, let?s examine how these tiers look when used in a large eCommerce system.

The hardware architecture of Oracle9iAS

In Figure 1.4 we see that we can have multiple instances of the components at each tier.  In this example we see that we have two sets of Oracle HTTP Servers (OHS), each listening on a different port for incoming database requests. As requests enter the system OHS passes the request to the least-loaded Oracle9iAS instance on the app server tier.

Figure 4: Oracle9iAS tiers and instances

At the app server tier we see multiple instances of Oracle9iAS, and we may also see multiple instances of the Oracle Forms server, Oracle Developer and Oracle Reports.  These multiple instances are normally on separate servers, and this provides the Oracle9iAS administrator with the ability to create an infinitely scalable architecture.  Whenever any components at any tier becomes overwhelmed, and Oracle9iAS administrator can create a new instance on a new server, and add the instance into the Oracle9iAS architecture using Oracle Universal Installer and maintained using the Enterprise Manager.

The Oracle9iAS instances will connect to the database tier.  For very large systems, Oracle9i Real Application Clusters (RAC) provides the ability to have multiple instances of the database, all mapping to a single database.  Using the same technique as the other tiers, whenever the existing instances become overloaded, another Oracle9iAS instance can be created on a new server, and the server can be added into the architecture.

This ability to scale by adding new instances and server is a critical aspect of Oracle9iAS administration because it is the single most important tool for ensuring that the system always has adequate hardware resources.

The Functional Architecture of Oracle9iAS

Now let?s look at the same architecture from a functional perspective (Figure 1.5).  Here we wee the functions of the instances at each level, and this should give you an idea about how the multi-tiered architecture is used to isolate the logical components of the application.

Figure 5: Oracle9iAS functional tiers

At the web tier we see that the main functions are the listener, which listens on a specific port for incoming requests, and web cache components that stores web page components, and the load balancing mechanism for ensuring optimal allocation of computing resources to the app server tier.  The web tier is managed by the Oracle HTTP Server which is based on the Apache web server. 

The app server tier controls all of the business logic and content assembly.  Components such as Oracle Portal are used to define web page components, Oracle reports defines content specifications, and Oracle single-sign-on (SSO) controls security for the app server layer.  At the database tier we see the standard Oracle data management functions for the storage and retrieval of application data.  All the components running on the application tier have the ability to connect to and retrieve data from the database using any of the available J2EE database connection methods.  These are discussed in detail in later chapters.  However, Oracle9iAS may have its own database if you install the Oracle9iAS infrastructure.  With infrastructure an Oracle database instance called iasdb manages Oracle9iAS components, security and preserves Oracle9iAS usage data.

Now that we understand the Oracle9iAS architecture at a high level, let?s take a closer look at each of these tiers and see how they interact with each other.

This is an excerpt from "Oracle 10g Application Server Administration Handbook" by Don Burleson and John Garmany.