Deployment Topologies

Oracle 10g AS is designed to be deployed across multiple servers that support large, enterprisesized applications. Under these configurations, there are typically multiple servers that provide for clustering, load balancing, failover, and segmentation of components . At the other end of the spectrum, you can simply install 10g AS on a single server to support basic J2EE applications. In this section, you'll learn both extremes so you can determine which is best for your application.

Standalone J2EE with Web Cache

The simplest implementation for a J2EE application is a J2EE and Web Cache standalone instance. However, just because it's simple doesn't necessarily mean that it's not high performance or cannot sustain a large number of users. One product that's often used to improve performance is Web Cache.

Web Cache is a caching server that sits in front of the OHS server and initially receives the client requests in the form of a URL. It stores content that has previously been requested by other users and will provide that stored content for subsequent requests, thus eliminating the need to go to the OHS. The user still enters her normal URL, but the traffic is transparently sent to the Web Cache server instead of the OHS. If the content requested by the client resides in the Web Cache, it's served up to the client without the need for processing by OHS. If the content isn't found, has changed, is too old, or is otherwise invalidated, the request passes through to OHS for normal processing.

By placing a Web Cache server in front of the OHS, the following benefits occur:

• Cached content is served up faster because processing within OHS and the database is eliminated. It's inside the Web Cache rather than inside the OHS file system or application's database.

• Because redundant processing by the OHS and the application's database is eliminated, a mid- tier instance can service a larger number of users simultaneously . Rather than processing the requests for the same content again and again, it can process more requests that are unique.

• Network traffic between the OHS and database is reduced because the client request terminates at the Web Cache server rather than generating work for these components.

By allowing Web Cache to serve content in front of OHS you can improve access performance for users and reduce the load on the rest of the system. This allows more users to be serviced faster than without Web Cache.

To make Web Cache useful, Oracle provides an extensive set of rules and tools to manage what content is being cached and how often it's refreshed. Both static and dynamic content can be cached. A commonly accessed page can be broken down into cacheable and noncacheable pieces so at least some of it is cached via Edge Side Includes (ESI). Events can be written within the database or application so that specific pieces of content are invalidated and the updated content is provided when data changes.

The location of the Web Cache server is always in front of the OHS. It can be on the same physical node as OHS, but it's preferable to have it on its own server. It can be either inside the firewall or outside the firewall depending on your network topology. Web Cache can also be configured in front of multiple OHS servers to act as a load-balancing device.

In Figure 15-6, you can see how Web Cache can be used with a standalone J2EE server.

Figure 15-6: Web Cache supporting a J2EE standalone server

In Figure 15-6, you can see how Web Cache is used to support a single J2EE server. The following steps show you how to process a request via Web Cache:

1. Clients send their requests, which are directed to the Web Cache server.

2. The Web Cache server examines the URL and determines if it has any of the content being requested.

3. If the requested content exists in the Web Cache and is still marked as valid, it's provided to the client. The request ends at the Web Cache server and isn't sent on to the OHS server for processing.

4. If the content isn't present or it's invalid, the request is sent on to the OHS server for processing as normal.

5. Once processing is complete, the content is returned to the client through Web Cache. Along the way, if the content is something Web Cache is set up to cache, it will keep a copy for the next time it's requested.

Web Cache can be a useful way to accelerate the performance of your application while reducing the load on your servers and network. Details on its setup and utilization are in Chapter 19.

Business Intelligence and Forms

Not all applications are exclusively J2EE. There are a large number of applications that are PL/SQL-based, such as PL/SQL Web Toolkit, Forms, and Reports. One Oracle product that uses both PL/SQL and OC4J is Oracle Portal. This tool allows for the rapid creation of a portal application with links to applications, reports , and personalized dynamic content, all supported by Oracle's Identity Management tools SSO and OID. Many corporate intranets and commercial applications are portals that can be customized for use by its users.

Note 

Oracle Portal is an example of a portal development product, so the word "portal" is both a type of web application as well as the Oracle product for developing portals. www.Oracle.com is an example of a site that uses Oracle Portal. Other vendors for portal products such as Plumtree also exist. Excellent examples of what a portal can do are the Yahoo! or Netscape home page. From within these pages, you can access different applications, receive dynamic content, and have it personalized.

Many IT shops have numerous applications that run a mix of Oracle products. These can be PL/SQL Web Toolkit and Oracle Forms and Reports for older applications and Java for newer applications. Most IT shops also don't have unlimited funds for server hardware to separate these applications. Since enterprise-class web servers can be expensive, it's not uncommon to attempt to host all these applications on one dedicated web server. In cases like this, it makes sense to have a BI instance servicing all the application types rather than having multiple different installations on the same server (all consuming resources).

These production applications might also run against a single dedicated database server. The same shop might have a smaller server that's used for development and testing for both the web server and database. But perhaps the shop is fortunate enough to have separate development web and database servers. Figure 15-7 shows an example of how a smaller organization could architect a solution if it didn't have the luxury of separate servers for data-base and web and development, testing, and production.

Figure 15-7: Business Intelligence in a small environment

In the diagram you can see that this organization has split its servers into production and development and testing. It has separate web and database servers for both production and development and testing. However, it has partially mixed environments (not recommended in an ideal world) by having the production infrastructure instance on a development database server. Though this isn't often a good practice, it can be excused in small environments especially if placing it on the production database server would overload the node.

Notice that the customers are outside the firewall and developers and testers are inside the firewall. This is common within many environments. As an additional security option, an additional firewall could (and should, if possible) be placed to further isolate the production web server from the rest of the nodes. If desired, yet another firewall could be placed to separate the production servers from the development servers. Depending on the sensitivity of the data, all traffic could be made more secure by using Secure Sockets Layer (SSL) as implemented by the Oracle SSL module. Security issues like these are further covered in Chapter 20.

In the preceding example, you can see how a small shop can make the best of having a few servers to host a mix of different applications. The shop certainly lacks fault tolerance and will take a performance hit by not separating all its servers, but in small-to medium- sized shops, this is often sufficient. In the next section, you'll examine the other end of the spectrum in which servers are plentiful and performance and fault tolerance are addressed with clustering.

Tip 

When discussing performance and scalability, it's common to discuss system architecture, server size , and so on, but the largest determining factor in performance usually is application code. Specifically, the quality and efficiency of the application code often determines the success or failure of the project. Bad code and program logic can bring even the largest server to its knees. Oracle DBAs are often all too familiar with how a poorly written SQL statement can cause major problems. The same concept is true in the J2EE world. Write good code and have efficient data-access methods or no server or architecture will be able to support your application!

J2EE Clusters with Web Cache

Oracle 10g AS is designed to have the capability of hosting the largest web applications with the highest available requirements imaginable. Combined with Oracle databases that are configured for high availability, 10g AS can be a truly large enterprise solution. The idea behind clustering and fault tolerance is to eliminate any one single point of failure in the system. With Oracle 10g AS, this can be achieved if enough servers and network infrastructure is purchased and configured correctly. Figure 15-8 shows an example of how a large system could be configured.

Figure 15-8: Large, fault-tolerant clustered environment

Under this scenario you'll have built-in fault tolerance at every level. There are two network load balancers to redirect the initial connections to any of four Web Cache servers. If the client URL request cannot be satisfied at the Web Cache level, the request is sent on to one of eight OHS servers. The OHS server will then route the request to one of eight OC4J instances to process the request. The customer application databases for Payroll and Sales are in an Oracle RAC configuration so that if one node fails, the database instance on the other can still be accessed. The infrastructure is located on a high-availability cluster with automatic failover. If one node fails, processes are started on the backup node. Once the client's request has been processed , it's passed back through each of these layers to the client.

DCM and OPMN play a critical part in this configuration. Each server has its own DCM and OPMN processes. DCM keeps the instance components synchronized with the infrastructure. The OPMN process detects any process that's no longer available or responding and attempts to restart it. The ONS subprocess of OPMN notifies other instances of components that are down so that requests can be properly rerouted. With application server clustering, if any component fails, requests are rerouted to surviving instances for processing.

There's more to setting up fast, high-profile, high-availability applications than just buying hardware and installing Oracle. Careful planning, configuration, and testing play a critical part, especially as systems become heterogeneous and increasingly complex. Once these types of systems are set up, just managing them can be a full-time job. However, Oracle 10g AS does provide valuable application-clustering technology that can make this possible. Oracle databases have numerous high-availability and fault-tolerance features available as well. Application server clustering is covered in greater detail in Chapter 21.