Re: web server 1.0 vs 2.0

From: Timothy Taylor <ttaylor_at_us.oracle.com>
Date: 1997/08/15
Message-ID: <33F4BD3E.4A75577E_at_us.oracle.com>


Tom Mettling wrote:

> Does anyone out there know where I can find a whitepaper detailing the
>
> advances from webserver 1.* to 2.*? We have a client that has version
>
> 1.0 and I need to justify moving them to 2.1 or 3.0.
>
> Thanks,
>
> Tom Mettling
> W.T. Chen & Company, Inc.
> mettlingt_at_wtchen.com

Tom,

Here's a paper I wrote for a customer a few months back. These folks were fairly new to the web, hence the discussions of CGI and other mundane topics.

Hope this is helpful,

Tim

Oracle WebServer 1.0 (OWS1) is part of the Oracle7 RDBMS distribution. There
are no extra charges asscociated with OWS1. The main differentiator for OWS1
versus similar offerings from Netscape, Microsoft and other vendors is the
inclusion of the Oracle Web Agent (OWA). The OWA is a Common Gateway Interface
(CGI) program that allows for the development of data driven web pages using
Oracle's database programming langauge, PL/SQL. There are two topics in the
previous sentence that merit further discussion: CGI and OWA. Let's talk about
OWA first.

In a typical database driven web application the developer will need to use
multiple languages: HTML for the user interface, Perl or a similar scripting
language to process user input, and SQL to get data into and out of the database. Let's not forget that there has to be some middleware to make Perl
talk to Oracle. That's at least three, and maybe four languages to deal with.
With Oracle's approach, you can do this all in PL/SQL. We have encapsualted
HTML into a set of PL/SQL libraries so you use one language for user interface, procedural logic and database access.

CGI programs are server-side executables that are used primarily to process
user input from an HTML form. Each invocation of a CGI script results in a new
Unix shell process being spawned to run the script. The script then must spawn
anothet Unix process in order to connect to the database. These shell processes only exists for one invocation of the CGI script. Further, when the
script terminates, Unix must clean up after it. This is an inherently inefficient protocol. It stands to reason that if your server is expending
resources starting new processes and cleaning up after them that it will have
less resources to process http requests or database queries. CGI was sufficient for early generation web sites but it is not suitable for high
volume web applications.

Oracle WebServer 2.X (OWS2) addresses these limitations by introducing a new
architecture called the Web Request Broker (WRB). The WRB is a multi-threaded
dispatching and execution engine that replaces CGI. The WRB dispatches URLs to
Web Request Broker Execution Engines (WRBX), which are also called cartridges.
These cartridges are persistent processes that do not terminate after each
invocation. In OWS2 the Oracle Web Agent is replaced by the PL/SQL cartridge.
Each instance of a PL/SQL cartridge (there can be many), remains running after
processing a request. Furthermore, each PL/SQL cartridge maintains a connection to the database. Therefore the overhead of spawining a new process
to handle the database connection is eliminated. So in OWS2 we have a multi-tiered approach of Web Listener (http daemon), WRB which dispatches
requests and performs load balaning, and cartridges for actually processing
URLs and generating HTML. There are three cartridges that ship with OWS2:
PL/SQL, Java, and LiveHTML. As I stated previously, the PL/SQL cartridge

provides similar functionality as the Oracle Web Agent did for OWS1. In fact,
any web pages that you develop in OWS1 will work just fine in OWS2. The Java
cartridge provides a server side Java virtual machine. Oracle ships a set of
Java class libraries that encapsulate HTML and a utility to encapsulate SQL
and PL/SQL. This allows you write web pages in an object oriented language.
The LiveHTML cartridge provides server side includes (SSI) processing. This is
the ability to have special HTML tags processed on the server. SSI is commonly
used for inserting timestamps and similar information onto web pages. Additional functionality in OWS2 includes:

  • an enhanced PL/SQL web toolkit
  • support for all commonly accepted web security standards (basic and digest authentication, Secure Sockets Layer, digital signatures)
  • the ability to host the WRB behind http daemons from other vendors including Netscape, Microsoft and Apache
  • the WRB API which allows for the development of custom cartridges. This allows the developer to extend the functionality of OWS2. Our approach to this extensibility is fundamentally different from other vendors. The common way to extend the capabilities of a web server is to link your changes directly into the web server kernel. This has several negative side effects: if your changes crash the system, the whole web site comes down. In addition, by linking your changes into one monolithic executable, you lose the ability to scale and distribute your load. OWS2 cartridges developed using the WRB API run in their own process space, which provides isolation from other processes and

allows for flexible,

        scalable deployment.

Oracle WebServer 3.0 (OWS3), which is offically called Oracle Web Application
Server extends the functionality of OWS2 by incorporating Common Object Request Broker Architecture (CORBA) object technology. At the heart of OWS3 is
a CORBA compliant Object Request Broker. This provides the ability to distribute your web applications across the network and have a unifying communications mechanism. Other important features of OWS3 include the Oracle
Security Server and XA compliant transaction services. Detailed information on
OWS3 can be found at www.olab.com. Received on Fri Aug 15 1997 - 00:00:00 CEST

Original text of this message