Previous | Table of Contents | Next

Page 401

CHAPTER 17

Web Application Server Components

In this chapter :

Page 402

Examining the Web Listener

Oracle Web Application Server uses Web Listener to wait for incoming requests for services. Typically, such a listener would set up an address that serves as an electronic signpost to tell all wayfaring packets of data, "I'm open for business." Of course, the listener must tell Oracle Web Application Server its address before opening for business. When Oracle Web Application Server has this address registered, it can build a road to Web Listener. This way, when a client issues a request, Oracle Web Application Server can route the message on to Web Listener, which then can execute the appropriate service.

Getting Into More Details

Web Listener processes one or many simultaneous client or remote server requests, in which case the remote server is acting as a client. For remote requests to be issued, you must make sure that the Web Request Broker object has been instantiated first. Otherwise, the remote listener won't exist and client requests can't be issued remotely.

After these communication channeling objects are in place, a client issues a request to Web Listener. Web Listener first checks to see whether this incoming message is a request for a static document or a dynamic document. If it's a static document, Web Listener returns to the client a "packet" that contains the file and the associated type information. If the client requests a dynamic document, Web Listener invokes a method (program) to create the document.

Web Listener executes its task so that it's compatible with the Common Gateway Interface (CGI). Web Listener uses CGI to invoke a method on the Web Agent object when a client requests a remote or local database procedure. All logging activities are automatic unless you started the listener through the Listener Administration page or the Boot page. In this case, you can manually start the logging service by updating the Log Info section in Web Listener administration forms.

Finally, regarding the HTTPD listener process, Oracle has decided that root ownership of this process violates overall system security. It doesn't disappear—it just gets bumped down the listener hierarchy, replaced at the top of the hill by the admin listener. In Oracle Web Application Server 3.0, you have to start the admin listener at the root level. This particularly helps companies that have advanced workgroup models with various security levels per workgroup and per role within each workgroup. So now you create, modify, or start each listener by group, user (or by role), or as running at port 1024.

To create, modify, or start a listener, enter the following command at the prompt:

owsctl start/stop admin 2

Based on the needs of the request, your admin listener becomes a virtual DBA, in a sense, as it issues database requests that require DBA permissions. Such requests could be to create new

Page 403

users. For this implementation to work properly, you or your database administrator will need to include the admin listener owner in your Oracle database's DBA group.

Understanding Web Listener's Architecture

Although multithreaded processing is a must in today's mission-critical client/server environment, some IS technicians have overused and abused this technology. What they neglect to understand—and it's easy to do so—is that each process needs memory and resources allocated to it. Without the appropriate memory and resource allocation, system performance can slow as more threads are opened, especially where processes handle requests synchronously. Therefore, you need to put a lot of thought into implementing multithreaded architectures.

Oracle designed Web Listener with this in mind. Web Listener's only task is to accept incoming client requests and route them to the Web Request Broker. Therefore, only one process on one thread is needed. Web Listener also handles requests asynchronously, meaning that when it receives a request, Web Listener doesn't need the client for further processing.

Memory Mapping of Files

If a file won't be permanently cached in memory, Web Listener uses a dynamic memory address mapping scheme in which more than one client connection can access common files. As a result, file access is speeded up as duplicate disk reads are avoided. And because a file is mapped in memory, the operating system can retrieve the next memory segment of such a file while another file is being sent to a client. This performance-enhancing strategy works well even where there is only one connection.

Directory Mapping

An important concept in the object-oriented circles is the idea of encapsulation or data hiding. Here, you don't care what an object does—you simply want it to perform what you expect. Likewise, Web Listener, in a sense, encapsulates how it stores URL path names. That is, you might see the same URL every time you go to a Web site, but Web Listener may have different names over time. Oracle Web Application Server administrators are responsible for correctly mapping the URL directories that users see to the actual physical directory in the machine's file system.

Resolving the Domain Name

Domain name server resolution ensures that the client user's request is sent to the proper network address/URL. When this is happening, the IP address of the client machine is recorded by the HTTP server, through which the request for an HTML form is being routed.

The Domain Name Service (DNS) serves as a reference for the conversion of a client's IP address into an ASCII host name. More than one machine may be involved in this resolution process, meaning that you might consider listening to your favorite CD while waiting for the address to be resolved.

Page 404

Web Listener offers you, as the Oracle Web Application Server administrator, three ways for handling DNS tasks:

Oracle Web Application Server includes an Administration Utility that allows you to edit the system configuration file for one of these three DNS resolution options. With DNS resolution, the results of this process are cached in memory as many connections may occur within the same time window, possibly from the same client. For performance reasons, the default configuration for DNS resolution is to never resolve IP addresses.

Web Listener Configuration Parameters

The configuration parameters for Web Listener are stored in a configuration file, which is read when Web Listener is initially started and when a `1' signal is received on UNIX implementations. After Web Listener is started, you specify its configuration file on the command line with the -c option, thus allowing multiple Web Listeners with different configuration files to be started on the same Web Listener machine.

Oracle Web Application Server provides an HTML-based Administration Utility, which you can access with any forms-capable Web browser. This utility eliminates the need for you to edit the Web Listener configuration file manually, in most cases, and provides explanatory help text on the individual parameters. This section documents the parameters in the configuration file for completeness, in the event an administrator wants to edit the file manually.

The Web Listener configuration file is divided into sections that start with a section name in brackets—for example, [NetInfo]. You set individual configuration parameters by name = value pairs, with the configuration parameter to the left (the lvalue) of the equal sign and the value to the right (the rvalue). For example, look at the following section of a typical configuration file:

;
; www.samsona.com configuration file
;
[NetInfo]
HostName = www.samsona.com
HostAddress = SomeHostAddress
PortNumber = 80

This portion of the file sets HostName to www.samsona.com, HostAddress to SomeHostAddress, and PortNumber to 80.

Examining the Web Request Broker

After Web Listener successfully receives incoming messages from clients, it passes the baton to Web Request Broker (WRB). Of all the Oracle Web Application Server components, WRB is

Previous | Table of Contents | Next