Oracle Application Server 10g Architecture and Administration

This text is intended to serve as a definitive handbook for the installation, administration, and maintenance of Oracle Application Server 10g. It is important to note from the outset that this is not a how-to book on using the program, and there are many other great books on how to apply this powerful software suite. This book is tightly focused on the administrative responsibilities and maintenance techniques for database administrators using Oracle Application Server 10g.

Because Oracle has consolidated many software products under the umbrella of Application Server 10g, there has been widespread confusion about its scope and functionality. To a web developer, Application Server 10g is Oracle Portal and Oracle Web Cache, while to a developer, it is J2EE and OC4J. However, most users agree that the core functionality of the program is the support for Java development.

In order to properly administer Application Server 10g, you must first understand all of its components and how they fit together. Like any enterprise-wide solution, the components of the program are the result of an evolutionary process, with new subproducts being added as the software evolves. Because Application Server 10g is a broad offering of many tools, your particular functionality may be vastly different depending upon the way you have installed and configured the software. This chapter covers the following topics:

• Overview of the architecture
• Functional components
• Introduction to administration

Let’s begin with a review of the Application Server 10g architecture and a look at each functional component.

Architectural Overview

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

Application Server 10g is the latest incarnation in a long evolution of application products. Starting in the mid-1990s with Oracle WebServer and Oracle Application Server, Oracle Application Server has evolved into an extremely sophisticated system of interrelated modules, all of which can be configured according to your specifications. There are two ways to view the architecture of Application Server 10g—from a design level and from a functional level. Both are based on a multitiered model.

The Multitiered Model

As Oracle products evolved into a multitiered architecture, we started to see Oracle products reside at several tiers, or layers, that represent hardware layers, with each tier made up of one or more servers (Figure 1-1). Because of the flexibility of Application Server 10g, Oracle shops can adopt a two-tiered, three-tiered, or four-tiered model. As a general rule, the larger the system, the more levels and more servers there will be at each level. Application Server 10g components reside at each of these layers in a four-tiered architecture.

Application Server 10g components reside at each of these layers:

• Client tier -- Contains the web browsers for end users

• Web tier -- Contains the Oracle HTTP Server and the Web Cache

• Application server (app server) tier -- Contains the core Application Server 10g, plus ancillary products such as Oracle Application Server Portal 10g, Oracle Developer, Oracle Reports, and Oracle Forms Server

• Database tier -- Contains the core Oracle Database, which may be a single instance or many instances defined to a Real Application Cluster (RAC)

Not all shops will use all four tiers. Smaller shops commonly combine tiers into the same level. For example, in a three-tiered architecture, the web tier and app server tiers can be combined. Remember, most large four-tiered systems will have many servers at the web tier, dozens of application servers, and many Oracle instances (using Real Application Clusters) at each node. Also, one or many components may run on any number of servers, and small Oracle shops (or those with huge 16 CPU servers) may combine all three tiers onto a single server. The choice of the number of tiers is directly related to the size of the Oracle 10g implementation and the number of servers that are dedicated to the system.

For small shops, it is common to see a two-tiered data model. Figure 1-2 shows an example of the client tier consisting of all 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. The single server can supply additional CPU and RAM processing according to the specific demands of each of the Application Server 10g components. The downside of the two-tiered architecture is the limited flexibility. It is not easy to add hardware resources when you need them.

In medium-sized shops, the three-tiered data model predominates. In this model, shown in Figure 1-3, the client tier is followed by the web server tier and app server on separate servers.

The database tier is also separated onto a different server, thereby providing isolated data resources for the Oracle Database. The three-tiered data model has a few benefits over the two-tiered model. First, increases in processing demands either at the database or the app server level will not affect the performance of the other components within the Application Server 10g architecture. Another benefit is that additional Application Server 10ginstances can be created, and additional Oracle System Global Area (SGA) regions can be easily added when processing demands warrant an increase.

Now that you’ve seen the components of each tier, let’s examine how these tiers look when used in a large e-commerce system.

This chapter is from Oracle Application Server 10g Administration Handbook, by Garmany and Burleson. (McGraw-Hill/Osborne, 2004, ISBN: 0072229586). Check it out at your favorite bookstore today. Buy this book now.

>>> More Oracle Articles          >>> More By McGraw-Hill/Osborne

blog comments powered by Disqus