VIEWS: 170 PAGES: 16

                 TO APACHE

Netscape Web servers have been used in enterprise Web applications for several years. With the changes in
ownership of the Netscape (now iPlanet) Web servers, and recent changes in support policies, many sites
are now seriously considering moving to alternative Web servers, primarily those based on the Apache
Open Source Web server. This document is designed to help Netscape administrators and technical
architects who would like to migrate to the Apache Web Server.

"The 3.6 version of Enterprise Server will be moved into "end of life" status in September 2000 - users of
Netscape Enterprise server 3.6 should migrate to the iPlanet Web Server before that date as customers
requesting support for Netscape Enterprise Server 3.6 after September 2000 will need to upgrade to the
iPlanet Web Server (Enterprise Edition) in order to receive support." Reference:

Any application migration has substantial costs and risks. Because Netscape 3.x customers are being forced to
undertake a migration, it is an appropriate time to consider other alternatives. Many customers feel that the
future development path for iPlanet Web servers is unclear, and don’t wished to be forced into another
expensive and difficult migration in just a couple of years because support has been dropped for their
production sites.

Because Apache has been developed using the Open Source model, a number of benefits are evident when
comparing the Apache solution to Netscape/iPlanet offerings:
  • Open Source Flexibility: Apache frees users from being dependent on particular software vendor for their
    web server platform technology. Access to Apache source code ensures that mandatory upgrades will not
    be an issue.

   • Cross Platform Support:  Apache supports the widest variety of platforms available. This provides almost
     limitless migration opportunities, since your choice of available supported operating systems is enlarged.

   • Increased Performance: Apache consistently performs more reliably and with better throughput than
     Netscape 3.6

   • Access to Large Development Community: Apache supports the largest development community of any
     web server technology. This ensures not only a robust code base, but also a wide pool of available
     developer talent with which to draw upon.

   • Interoperability: Apache can be deployed in conjunction with a wide range of application servers or web
     to host infrastructure. Because iPlanet is tied to the iPlanet line of products, it is less flexible when
     integrating with other technologies such as BEA WebLogic, IBM WebSphere, etc. Apache is also fully
     compliant with all Open Standards as well, such as LDAP, SOAP, and XML.

Covalent Technologies, Inc. Proprietary & Confidential Information                                                1
   • Open API: Netscape uses a proprietary API for the development of extensions to the server. Apache's
     open source API ensures you will have an easy migration path for future application development.

   • Better Security: Because of the Open Source nature of the Apache code, security holes are discovered and
     closed very quickly, before they have the opportunity to manifest themselves in operational environments.

   • Lower Cost: Adopting Apache will result in lower licensing cost and lower total cost of ownership
     throughout your enterprise.

Apache allows the administrator to pick and fine-tune the right request processing method to balance
robustness and scalability. iPlanet is a fully threaded server, which means that a serious error in one request
thread, could take down the entire server, and all web sites and requests being handled by that server. Apache
provides multiple techniques to reduce the impact of a crashing request, while at the same time allowing for
the scalability needs of today’s enterprise.

Apache’s open source license means that source code for the Web server itself is freely available for download
over the Web, without licensing fees. However, installing the compiled Apache server is only a small part of the
overall requirements for migrating to an Apache based environment that will support the high volumes and
high values of Web based applications today. Covalent Technologies, Inc. provides the rest of the components
required for a complete solution.

Apache Expertise
From its inception, Covalent has been focused on providing value-added components, expertise, and support
for Apache Web servers. Founded by one of the original Apache development team members, Covalent today
has a greater concentration of expertise related to Apache then any other company. We’ve translated that
expertise into a set of products and services that supply the complete solution to your Web-based application

Ent erprise Application Ready
Covalent provides a full suite of plug-in products to the Apache Web server, as well as an easy-to-install, pre-
configured version of Apache. We bundle these plug-ins and Apache into different configurations appropriate
for a wide variety of application needs. From the Fast Start server for single-server installations serving static
and dynamic content from Tomcat, Perl, and PHP, to the Enterprise Ready Server with a full set of features for
deployment, management, monitoring and logging complex Web server farms, Covalent leverages the proven
strengths of Apache and makes it ready for your enterprise.

Comprehensive Sup port, Traini ng, and Servi ces
Simply having the right products available isn’t sufficient to for customers who must provide their users with
reliable, high-performance, secure Web applications. Covalent Technologies, Inc. provides a range of
professional services and technical support to insure that your application is designed with the best practices
for Apache Web applications, and that operational support for the application is available from a staff of
highly trained Apache experts. The Netscape migration service described is just one one example of the services
available today from Covalent. We also will provide customized on-site training as part of our engagement
with you.

Since the advent of the World Wide Web, Web-based applications have become steadily more complex, and
have placed dramatically greater demands on hardware, Web server software, operating systems, and
operations. Today’s Web applications range from the ‘simple’ static content sites that still may encompass
thousands of individual Web pages with hierarchical security structures, to multi-tiered enterprise

Covalent Technologies, Inc. Proprietary & Confidential Information                                                2
applications supporting thousands of simultaneous users and millions or billions of dollars of yearly
transactions. Even given this wide range of application types, we can classify the key components of these
applications into four areas: Static Content, Authentication and Authorization, Server-side Application
components, and Application Server and Database Integration. We’ll look at each in turn before turning to
Covalent’s comprehensive methodology to migrate your current applications to Covalent’s solutions.

‘Classic’ Web sites are built on HTML files that are the same for each Web visitor, generally referred to as static
Web sites. Even these ‘static’ sites may change daily, or even hourly, as content is refreshed through a variety
of manual and automated processes. The directory structure that stores these pages on the Web server may be
very complex, and is often associated with the ability of different users or groups of users to access confidential
or specialized information. Many static Web sites are also very high volume, supporting many ten’s of
thousands of users simultaneously. Migrating these types of Web sites to a new Web server architecture
demands a thorough understanding of both the overall information architecture of the site, as well as
understanding the implications of the volume demands placed on the site.

Today many ISPs, Web hosting facilities, and IT departments of corporations and other institutions have
moved towards a ‘utility’ model of Web hosting, where a single physical machine with appropriate redundancy
may host dozens or even thousands of distinct Web sites, each with its own content and configuration
environment. In keeping with utility metaphor, these servers must maintain constant availability, and be
designed to eliminate single points of failure in the hardware, software, and networking environments. Not
only is the configuration of these sites complex in itself, but the migration team must thoroughly understand
the networking and securing environments necessary for supporting the site.

While more complex Web-based applications server at least some of their pages through a process that
dynamically creates the content of each page, nearly all sites maintain at least a portion of their content in a
static format. When creating a migration plan, it’s important to consider the structure and access of both the
dynamic and static content within a site.

While some Web sites still make all of their content available to all site visitors, many sites require that site
visitors be authenticated through one of variety of security mechanisms before being allowed to access content
on the site. Even after authentication, the user may be authorized to view only a subset of the content, either
because of confidentiality concerns, or because the Web site design dictates a degree of personalization of the
content. This process of authentication and authorization demands both integration into existing security
systems, as well as architecting the Web site content to assure that only authorized users view the restricted

Web applications implementing these security models typically are integrated with one of a variety of user
authentication and identification mechanisms. These mechanisms range from integration into industry
standard directory systems such as LDAP-based directories, to various proprietary solutions from a variety of
vendors, to systems developed internally that depend on existing enterprise applications for user
identification. In some cases this integration is accomplished through available application toolkits from
commercial vendors, through the use of standard protocols, or through the development of specific modules
communicating with enterprise applications. Migrating these interfaces requires an understanding of the
underlying capabilities of the Web server platform, as well as a deep knowledge of integration alternatives,
both commercially available and custom-developed.

In the progress from static to dynamic Web applications, a number of technologies and techniques have been
developed that depend on code modules executing on the same system as the Web server, often referred to as
‘server-side’ applications. The term server-side is intended to differentiate these applications modules from

Covalent Technologies, Inc. Proprietary & Confidential Information                                                 3
those that execute in the client (Web browser); client application modules typically use such technologies as
Client-side Java, JavaScript, and animation-based technologies such as Flash.

 A wide variety of languages and techniques have been developed for server-side applications that typical result
in the dynamic generation of at least some Web pages. These server-side applications, written in such
languages as Java, Perl, PHP, JavaScript and others, often communicate with other systems such as relational
databases to create their dynamic content. Developers are also able to write plug-in modules that work with
the specific Web server API, such as the Apache API, iPlanet NSAPI or Microsoft ISAPI; these modules are
typical written in C or C++, although Apache also allows them to be in Perl as well. Migration of these
applications demand a thorough knowledge of the development and execution environments, as well as the
ability to determine the best alternatives for moving these application components to the new platform.

Today’s Web applications often are architected in a ‘three-tier’ fashion, where an ‘application server’ and one
or more data source (typically including a relational database) are used in addition to the Web server
components. Application servers have a wide variety of capabilities; typically including the generation of at
least some of the site pages dynamically, the development of business logic modules, session and security
management, and connections to existing systems and relational databases. Although there are a large number
of application servers available today, the market leaders are BEA with their WebLogic application server, and
IBM with their WebSphere products. It should be noted that Application Servers do not imply required
support or compliance with Enterprise Java Beans. Enviroments such as Apache Tomcat, which provides a JSP
and Java Servlet engine, are also classified as Application Servers.

All application servers must communicate with the Web server to present the HTML page to the site visitor. To
accomplish this, Web server vendors normally supply a ‘plug-in’ module that uses the Web server’s API to
provide the communications channel between the Web server and the application server. These modules are
specific to the particular Web server (Apache, iPlanet, or Microsoft IIS), and are often specific to a particular
release of an application server as well. At a minimum, the appropriate plug-in must be available for Apache.

The first step in planning your migration to the Covalent Apache platform is to inventory and document all
components of the target application(s). Many current Web applications have grown over time, and may use a
variety of development techniques and integration points. While it may be correct to keep the existing design,
this also in an opportunity to consider if different technical approaches may be appropriate. For example, it
might make sense to consider using an Apache Tomcat based Java implementation for some business logic
components rather then existing CGI Perl scripts.

It’s also important to consider the wider context of a set of applications. Many organizations today have
dedicated servers to a single Web application because of time-to-market considerations or organizational
factors. Because Apache support multiple Web applications residing on a single server through its Virtual Host
facilities, the assessment process should include considering whether multiple applications, each with their
own URL, can effectively be hosted on a single server.

The Appendix contains a typical checklist for assessing your application environment, and calls out many of
the critical factors. Once this assessment has been completed, the different techniques for migration described
next can be employed.

Both Netscape and Apache use configuration files to control the operation of the Web server, and use various
directives within these files to set server options. In most cases, Netscape server directives have a direct
analogue in Apache; Apache also offers options not available in Netscape. When analyzing Netscape

Covalent Technologies, Inc. Proprietary & Confidential Information                                              4
configuration files and creating equivalent Apache configurations, the following summary of translations will
be useful.

Configuration F iles
Netscape directives are enabled at server start from the configuration file
Apache directives are found in the conf/httpd.conf file. The default location of this file is determined at
compile time: a typical location is
The location may be overridden by a command line option at server start-up.

Net scape Ser ver - Ini t Dire ctives
Init directives are used to initialize server subsystems such as access logging, file typing, and loading of custom
Server Applications Functions (SAFs). These functions are called upon server start or restart.
Netscape has a number of Init directives, for example, cache-init, init-cgi, init-clf, etc. An Init directive is
implemented as in the following example:
          Init fn=cache-init cache-size=512 mmap-max=10000

Apache Se rver - Configuration Dir ective s
Apache directives are used for the same purposes as in the Netscape Server. Typically, they are implemented as
modules and are loaded in and called by the server during start or restart as in the following example:
          LoadModule cgi_module modules/mod_cgi.so
          AddModule mod_cgi.c

Net scape Ser ver - Aut hentication Direct ives
Netscape uses the AuthTrans directive to protect server resources. To access these resources requires the client
to provide authorization information from the user. The AuthTrans directive is implemented as in the
following example:
          Init fn=load-modules shlib=/lib/msqlath.so funcs=msql_auth
          AuthTrans fn=basic-auth auth-type=basic userfn=sql_auth

Apache Se rver - Aut hentication Direct ives
Apache uses Authentication modules and their directives to enforce authorization:
          LoadModule auth_module
          LoadModule anon_auth_module
          LoadModule db_auth_module
          AddModule mod_auth.c
          AddModule mod_anon_auth.c
          AddModule mod_db_auth.c
          AuthType Basic
          AuthDBUserFile /etc/httpd/auth/user.file

Net scape Ser ver - Name Translation Dir ective s
Netscape uses the NameTrans directive to translate virtual URLs to physical directories on the server. root is
the filesystem path to the server's document root directory:
          NameTrans fn=document-root root=/usr/netscape/suitespot/docs

Covalent Technologies, Inc. Proprietary & Confidential Information                                                 5
The PathCheck directive is used to tell the server to search for an index file in the target directory. If an index
file can't be found, the server generates its own directory listing:
          PathCheck fn=find-index index-names=index.html,home.html

Apache Se rver - Name Translation Dir ective s
Apache uses the Alias directive to perform the URL translation to the physical filesystem namespace:
          Alias /www /usr/local/docs/www
Apache uses the DocumentRoot directive to define the server's document root directory:
          DocumentRoot /var/www/html
The DirectoryIndex directive to translate a URL to a directory. The server searches for an index file in the target
directory. If an index file can't be found, the server generates its own directory listing:
          DirectoryIndex index.html index.htm index.shtml index.cgi

Net scape Ser ver - Err or Dir ective s
Netscape uses the Error directive to customize its errors handlers:
          Error fn=send-error code=401

Apache Se rver - Err or Dir ective s
Apache uses the ErrorDocument directive to customize its error handlers:
          ErrorDocument 401 /var/www/errors/401.html
          ErrorDocument 404 http://www.example.com/404.html

Net scape Ser ver - Logging Dir ective s
Netscape uses the AddLog directive to log a transaction after the request is completed:
          AddLog fn=record-useragent name=browsers-used

Apache Se rver - Logging Dir ective s
Apache uses the CustomLog directive to customize its logging process:
          LogFormat "%h %l %u %t \"%r\" %>s %b" common
          CustomLog logs/access_log common

The LogFormat directive determines what is logged: %h is remote host (IP address), %l is remote logname,
%u is remote user, %t is the time (in common log format), %r is the first line of the request, %>s is the status
of the final request, and %b is the number of bytes sent to the client. Logging can additionally be made
conditional via the use of environment variables.
For example:
          CustomLog logs/image_log common env=image

In addition, Covalent’s Logging Services, part of ERS, provides in-depth centralized logging capability to all
configured Apache servers, and allows for both runtime and “after the fact” creation of various logfile formats.

Net scape Ser ver - Ser vice Directi ve
Netscape uses the Service directive to generate a response to send to the client. It sets the HTTP result status,
sets up response headers (such as content-type), and generates and sends the response data:
          Service method=GET type="text/html" fn=append-trailer
          trailer="<hr><img src=/logo.gif> Copyright &copy; 2001"

The Service directive relies on the parse-html component to perform many of its tasks.

Apache Se rver - Ser vice Directi ve

Covalent Technologies, Inc. Proprietary & Confidential Information                                                    6
Apache does not have a direct correspondence to the Service directive. Some of this capability can be
performed with the mod_include module. Covalent’s ERS product includes a robust http header
manipulation module, which also provides much of the same functionality at the HTTP level.
Part of the Web server configuration process is the setting of access controls, assuring that each directory
accessible by the Web server has appropriate permissions set for site visitors. As in any security process, you
should always start with the stance of denying all permissions, and then explicitly enable those permissions
required for proper operation at each stage in the directory hierarchy. This prevents unintentional security
holes caused by allowing site visitors to write into directories, for example.

Sites with only static content are relatively easy to migrate from Netscape to Covalent Apache. In most cases,
after the appropriate Apache configuration has been built, the directory structure of the existing Web site can
be copied directly to the corresponding directories for the Apache server. Note that you may want to establish a
different document root for the Apache server, particularly if you are taking advantage of the Apache Virtual
Host facilities and combining several static sites onto a single physical server.

Of course, with migrating static sites as well as any migration process, a comprehensive test plan is a
requirement. While the process of migrating static web sites is straightforward, only by running regressions
tests against the complete site can you be assured that a detail wasn’t overlooked.

As we mentioned previously, Apache’s robust Virtual Host facility enables you to combine a number of Web
sites onto a single physical host. Virtual Hosts allow you to direct an incoming request to a specific URL or IP
address to a unique document root. Because each Virtual Host can have its own document root, you can
effectively segregate content between each site. Since each Virtual Host also provides its own access controls,
security can also be maintained.

While the configuration process through the Apache configuration files for Virtual Hosts is not complex, other
factors must be taken into account before implementing this server aggregation process. First and foremost,
the volume characteristics and bandwidth requirements for each site must be understood, and the aggregate
performance metrics for all sites on a single server calculated. Depending on the usage characteristics of each
site, even sites with relatively low numbers of visitors may demand a relatively high bandwidth, if users are
downloading large files through HTTP, for example. Some useful tools for estimating bandwidth requirements
and CPU utilization are described in the Appendix.

Once an appropriate mix of Virtual Hosts has been determined for each physical server, and the configuration
files created, the process of creating each Virtual Host site is essentially identical to creating single sites. Each
site can be created, tested, and brought to deployment individually, which promotes a realistic incremental
approach to the process of migrating a number of Netscape sites.

While this document is concerned largely with the Web server configuration and deployment process, creating
new sites involves many components beyond the Web server. In particular, DNS, network routing, load
balancers, and firewall will all have to be properly configured to correctly route requests to the correct system,
whether that system has a single site or multiple Virtual Hosts residing on it. As in all migration activities,
careful planning and the creation of repeatable operational procedures is vital.

Part of the Web server configuration process is the setting of access controls, assuring that each directory
accessible by the Web server has appropriate permissions set for site visitors. As in any security process, you
should always start with the stance of denying all permissions, and then explicitly enable those permissions
required for proper operation at each stage in the directory hierarchy. This prevents unintentional security
holes caused by allowing site visitors to write into directories, for example.

Covalent Technologies, Inc. Proprietary & Confidential Information                                                      7
Apache provides a three phase authentication and authorization process that allows good control over
verifying users identities and controlling access to specific directories and files. At the top level, Apache can
perform basic access control based on values found in the HTTP header, using the standard mod_access
module. The most common usage is to allow or deny access based on a user’s domain; for example an intranet
site at Covalent might use a directive a sequence of directives such as:
          <Directory />
          order deny, allow
          deny from all
          Allow from .covalent.net

This would have the effect of allow only users coming from the covalent.net domain to access any content on
the Apache server.

The second level of control requires a user to be authenticated before being granted access to a resource on the
Web server. Using standard modules such as mod_auth, a user can be prompted for a username and
password when she attempts to access a protected directory. Depending on the module, user names and
passwords may be stored in plain text files, DBM files, relational databases, or LDAP directories. Users may
also be associated with groups through this mechanisms.

The third level of control specifies individual users or groups of users that are allowed access to a specific
directory or file on the server. The directives that control this can be placed in the Web server configuration
file, or in .htaccess files, which are text files that are placed in the directory of the Web pages they control. Note
that many sites forbid the use of .htaccess files for access control because of their placement in ‘public’
directories that might make them more susceptible to being revealed or modified accidentally. Similar
mechanisms can require that access to a directory or file be done using SSL encryption.

Beyond the process of determining access abilities on the granular level provided by access control directives
and .htaccess files, many sites require a much more robust security mechanism. Most applications use the
concepts of authentication and authorization. Authentication means asking ‘Am I the person I purport to be,
based on something I know, like a user name password, and/or something I possess, like a security token.
Authorization means the process of deciding whether a specific user is entitled to view (or perhaps alter) a
particular piece of content.

Web applications today use a wide variety of authentication mechanisms, from relatively simple user names in
passwords stored in a relational database to complex electronic tokens that generate new passcodes every few
seconds. In many cases, the implementation requires access to data sources outside of the Web server itself.
These sources include LDAP compatible directories, relational databases, and external processes such as
enterprise systems or single-sign on infrastructures. Regardless of the mechanism, the result of all of these
processes is to allow or deny users access to an application.

Once a user has been granted access to an application, many security systems then determine the users
authorization to access system resources. In the context of Web servers, these system resources are generally
mapped to specific URLs within the Web site. This allows secure applications to permit access to general
content to all authenticated users, while restricting access to sensitive content to only authorized users.
Because access to many Web application processes are based on URLs and accompanying query strings, the
same authorization process can be applied to the execution of script based applications.

The main requirement for migrating applications with these security features is the availability of appropriate
Apache modules to integrate with the chosen security system. A wide variety of commercial security systems
provide Apache-specific modules as a standard offering. Security integration mechanisms that were developed

Covalent Technologies, Inc. Proprietary & Confidential Information                                                   8
through custom programming efforts using Netscape APIs or scripting based methods will need to be
migrated using the facilities described in the following section.

Testing of security systems is by its nature complex, and must be carefully planned. Because multiple
authentication and authorization mechanisms may exist in a single application, the interaction of those
mechanisms must be explicitly tested. Both positive (does the system behave correctly for an authenticated
and authorized user?) and negative (can an unauthenticated or unauthorized users gain access to content or
applications?) testing is vital to verifying the correct migration.

In general, CGI-based applications refer to applications using the Common Gateway Interface that allows the
web server to communicate to processes running in the operating system environment. Through the evolution
of Web sites, languages such as Perl, C, and even shell scripts, have been used to create complex, high-
performance sites that integrate with a myriad of data sources and other applications. In general, the
languages are used for both generating dynamic Web pages that change according to user profiles or external
events such as news flashes, and for implementing business logic within the Web application, such as
shopping carts in Ecommerce applications.

For current Netscape applications written using the CGI standard, the migration process is likely to be fairly
straightforward. Apache supports the CGI standard, and most applications should work with out
modifications. If your application is currently written in Perl, Covalent Apache offers the mod_perl plug-in
module that offers a full Perl interpreter integrated with the Apache environment. Mod_perl provides a faster
execution environment then classic CGI Perl programs, and allows Apache modules to be authored in Perl.

Microsoft has promoted Active Server Pages, which provide simple scripting-based dynamic HTML pages.
Covalent offers mod_php, using the PHP4 language to provide a simple yet powerful scripting environment
to create dynamic pages. PHP is particularly strong in database connectivity, supporting many common
relational databases as well as ODBC natively. PHP is itself a popular Open Source project, and is thus much
more ubiquitous than ASP.

Beyond the scripts themselves, other configuration adjustments will be required for the Apache server. The
Covalent installation processes helps to automate many of these, by inserting the appropriate
LoadModule/AddModule directives into the Apache configuration files for example, and by installing the
correct shared libraries with the Apache installation tree. Other changes will need to be made to the
configuration files to enable execution of files within specific directories.

One of the challenges that many Web developers have faced is the lack of strong portability across platforms
when developing applications. Many development shops will use less expensive desktop systems, such as
Windows NT boxes for development tasks, and then move the application to UNIX based systems for final
testing and deployment. Because Covalent has created a consistent API and execution environment across all
supported platforms, developers are able to use any mixture of supported platforms for development and
deployment, without the requirement to make changes in the application to adapt to a specific platform.

Because scripting-based applications are far more dynamic, often accessing external databases and processes,
the testing regime for these applications must be very comprehensive. A prerequisite for this testing is a
through understanding of the application itself, and a documented test plan with both positive and negative
test cases. During your migration planning, guard against short changing the testing process by not allowing
sufficient time for this important task.

Netscape provides an API to its Web servers, commonly referred to as the Netscape API (NSAPI). NSAPI
applications are used to extend the functionality of the Netscape server, and are generally written in C/C++.

Covalent Technologies, Inc. Proprietary & Confidential Information                                              9
The complexity of these applications vary greatly, from simple communications modules that talk to processes
external to the Web server, to complete application frameworks. Covalent Apache offers an API that parallels
NSAPI in functionality, and provides the framework for building Apache plug-in modules. The Apache API
supports development not only in C, but in Java and Perl as well.

Planning for NSAPI application migration should take into account not only the comparison of capabilities of
the NSAPI and Apache APIs, but also a consideration of the overall application architecture to determine if
reproducing the current programming environment is the best long-term choice. With the availability of
application excution environments such as mod_perl or Tomcat, other alternatives may be more appropriate.

Following is a comparison between the NSAPI and Apache API facilities:

You can write custom server application functions for Netscape using the C programming language. Apache
allows you to extend the server with C, Perl, or Java. Netscape extensions are written as plug-ins whereas
Apache extensions are implemented as modules.

Net scape Ser ver - Par ameter Blocks
Netscape uses the parameter block to contain the parameters from the directive that invokes the SAF in the
obj.conf file. The pb parameter is a pointer to a pblock data structure. The pblock structure contains a series
of name/value pairs. For example, a directive that invokes the basic-ncsa function might look like:
          AuthTrans fn=basic-ncsa auth-type=basic dbm=/netscape/server4/userdb/rs

In this case, auth-type and dbm are the names and basic and:

are the corresponding values that are passed in the pblock data structure.

Apache Se rver - Par ameter Blocks
Apache modules do not use the parameter block paradigm for their call structure. Apache modules can, and do,
extend the list of available directives to control not only the operation of Apache, but the module as well.

Net scape Ser ver - Sessions
Netscape defines a session parameter that contains information relating to a single TCP/IP session. It passes
pointers containing information about the client such as its IP address or DNS.

Apache Se rver - Sessions
Apache does not have a direct correspondence to the session information interface. Some of this information,
however, is available at the HTTP layer in the form of standard environment variables. Covalent’s ERS
package, however, does come with a User State And Session Tracking module, which provides detailed state
and session management at a click-through level. This is done via Cookies and on-the-fly URL rewriting, with
the state and session data available to other Apache modules as well.

Net scape Ser ver - Requests
Netscape uses a request parameter that contains information relating to the current request. The rq parameter
is a pointer to pblock data structures containing the HTTP method (GET, POST, etc.), the URI, the protocol
(normally HTTP/1.0), the query string, the request headers (such as User-Agent, If-Modified-Since, etc.)
received from the client in the HTTP request, the response headers (such as Server, Date, Content-type,
Content-length, etc.) to be sent to the client in the HTTP response, and any “working” variables required by
the plug-in.

Covalent Technologies, Inc. Proprietary & Confidential Information                                                10
Net scape Ser ver - Requests
Apache has a request_rec parameter that contains pointers to a resource pool, which will be cleared when the
server is finished handling the request, to structures containing per-server and per-connection information,
and most importantly, information on the request itself. The request_rec data structure is the sole parameter
passed between your module and the server.

Result Codes
Both Netscape and Apache return result codes to server application functions. These codes are very similar in
function. The code may be accompanied by an HTTP response status code.

Net scape Ser ver - Memory Manageme nt
Netscape provides a number of memory management routines that provide fast, platform-independent
versions of the standard memory management routines. They also prevent memory leaks by allocating from a
temporary memory (called "pooled" memory) for each request and then disposing the entire pool after each

Apache Se rver - Memory Manageme nt
Apache provides a very robust memory allocation and management system known as “pools.” Apache provides
the ap_palloc function to allocate memory from a shared pool of memory. This function allocates memory,
which is freed only when the associated resource pool is cleared. Pools are available on a per server, per
connection and per request basis.

Net scape Ser ver - Imp lement ation
Netscape plug-in functions map to a specific directive in the obj.conf file. Once you have written, compiled,
and linked your plug-in, you need to edit the obj.conf file to enable the SAF and then restart the server.

Apache Se rver - Imp lement ation
Apache modules have a set of directives and separate handlers. You write, compile, and link your module, then
edit the httpd.conf file to enable the module. You would then restart the server.

Netscape supports two methods of using Java for dynamic content applications: Java servlets and Java Server
Pages (JSP). Java servlets can best be thought of as Java applets that run on the Web server system, and don’t
have a user interface. Java servlets can be used as replacements for CGI-based processes, and invoked through
a URL with an appropriate query-string.

JSPs are pages, much like an HTML page, that can be viewed in a browser. They contain both standard HTML
as well as special JSP tags that allow the developer to include dynamic content with the HTML page. JSP tags
include scriptlets, which are segments of Java code embedded within the page, and by references to Java Beans,
which are Java classes compiled independently of the JSP.

Unlike Java servlets and JavaBeans, JSPs are interpreted at the time that they are accessed by the Web server.
This means that the developer of a JSP does not have to understand or work with the Java development
environment; she can embed small pieces of Java code within the JSP and make references to externally
developed JavaBeans and have the page executed automatically by the Web server.

Both Java servlets and JSPs are part of the Java standards effort, and are designed to be portable across
operating system and application environments. For applications that make use of these technologies,
Covalent Apache provides a ready to use, supported environment for your migration effort. Covalent supplies
two JSP/Servlet execution environments: Apache JServe and Tomcat.

Covalent Technologies, Inc. Proprietary & Confidential Information                                               11
JServe is the original Java servlet and JSP execution environment for Apache Web servers. JServe is current in
maintenance only mode, and has been supplanted by the Tomcat engine for new projects.

Tomcat is the official reference implementation for Java servlets and Java Server Pages. Tomcat 4.0 implements
the official Servlet 2.3 and JSP 1.2 API specifications. It provides a scalable, secure environment for execution,
and is appropriate for many applications that don’t need the involved business logic or EJB support provided
by application servers such as WebLogic. Tomcat 4.0 is an integral part of Covalent’s ERS package.

Sup porting Application Servers
Many modern Web applications use a multi-tiered architecture, as described earlier in this document. A key
component of this architecture is the application server, distributed by vendors such as BEA (WebLogic) and
IBM (WebSphere). Application servers are used to implement business logic, transactions, and integration
with legacy data sources. For Web based applications, the application server must communicate with the Web
server that communicates with the end user. In the Apache environment, this communication is most often
accomplished either through an Apache module, or through a pass-through proxy configuration.

Vendors such as BEA and IBM supply Apache plug-in modules for their application servers. Covalent has
developed expertise in several of these application servers, and can work with you to determine the best
approach for interfacing Apache with the servers. Whether a plug-in module or proxy server is chosen for your
environment, using Covalent Apache allows you to separate the Web services component physically from the
application server, providing both increased security and greater flexibility in configuring your environment.

As pervasive the argument for migrating from Netscape iPlanet to Apache is, the availability of Covalent’s
Enterprise Ready Server (ERS), based on Apache 2.0, makes the decision even easier and more logical. With
ERS, not only do you get the power and flexibility of Apache, but significant value-added components which
increase the usability of Apache to even higher levels.

Being based on Apache 2.0, ERS not only supports the standard HTTP/HTTPS protocols, but can also support
FTP and other protocols in the same framework. This allows for a common configuration, logging and
authentication scheme for all your client and user protocols. Covalent’s ERS also provides hooks for various
authentication and authorization technologies, such as LDAP, with connection pooling capability if required.
We also mentioned above ERS’s advanced state-and-session management and centralized logging capabilities
which simply aren’t available from Netscape. And ERS provides a true control portal that allows for remote
creation, configuration, monitoring and alerting of your Apache web server. Full details concerning Covalent’s
Enterprise Ready Server can be found at : http://www.covalent.net/enterprise_ready

Covalent Professional Services works closely with your organization to create and execute a comprehensive
migration plan to move your current Web applications to the Covalent Apache platform. Covalent has not only
the most comprehensive knowledge of the Apache application platform in the industry, but has direct
experience in migration of enterprise Web applications. We have developed a comprehensive methodology to
assure the successful, timely migration of your applications, while providing a comprehensive support plan for
your operations after the migration is complete.

The most essential component of the application migration is the development of a comprehensive migration
plan. Covalent professional services consultants will work closely with your technical and development staff to
create this plan.

Covalent Technologies, Inc. Proprietary & Confidential Information                                               12
This plan takes into account all aspects of the application, including development technologies used, site
volumes and bandwidth requirements, integration with data sources and application servers, and availability
and maintenance requirements. Once the application and its environment is thoroughly understood and
documented, our experts will build an overall technical architecture and high-level design for the application
migration. The technical architecture will identify the current application architecture, and present the new
Apache-based architecture. The high-level design will describe how each application component, such as
scripts, NSAPI plug-ins, and Java components will be migrated to the new architecture. It will also describe the
recommended process for integrating into application servers and security modules.

The final component of the plan is the project plan, which includes both the specific tasks required for
successful implementation and deployment as well as a description of the resource requirements. We will work
with you to determine which migration and development tasks are best undertaken by your staff, and which
tasks can be most effectively performed by Covalent professional services consultants.

Det ailed Design
After completion of the high-level design and technical architecture, a detailed design is completed for those
applications that will require re-implementation, for example to move from NSAPI to the Apache API. The
detailed design documents the current application to the code module level, and presents the recommended
implementation for each module. A detailed design is also created for integration with existing security
systems and application servers, including designs for any required extensions to standard Apache modules.
A preliminary test plan is also developed at this stage in the engagement. By combining test plan development
with detailed design, we can assure that critical functionality is tested thoroughly. Development of test cases
and configuration of testing tools can also proceed in parallel with development efforts when the testing plan
is created early in the process.

Developer Training
Covalent believes that empowering our customers to build on the robust platform that we’ve created presents
the best value and long term growth potential. We can work with your developer community to create
customized, on-site training to transfer some of the expertise that we’ve developed around Apache products to
your implementers. This training will allow your development staff to build on the detailed designs created
during the engagement and implement the new applications quickly and effectively.

Bui lding the Ap plicat ions
For applications that require customized code development, Covalent recommends that your trained staff take
the lead in the implementation. Covalent experts will be available to assist during the development process to
help you make sure that the project stays on time and on-budget. If your development staff needs to be
supplemented, Covalent will be happy to recommend an appropriately qualified Covalent partners to allow you
to outsource some or all of the developments tasks.
If you desire, Covalent consultants can also provide hands-on assistance for installation and configuration of
the Covalent components, and assist with integrating Covalent products in your network and security
infrastructure. We will create a comprehensive knowledge transfer process during these engagements assure
that your architecture and operations staff can support and extend the new environments.

Testing a nd Dep loyment
Testing of the newly migrated application starts during the development process with the creation and use of
unit testing tools. When the complete application is integrated, more comprehensive testing begins,
concentrating on end-to-end functions, as well as test cases designed to provide negative testing functions.
The use of automated testing tools can be of tremendous assistance in this process, particularly for performing
robust regression testing.

Covalent can assist in the development of the testing plan, as well as provide expertise on testing tools and
methodologies. Your quality assurance staff will take the lead in the testing process.

Covalent Technologies, Inc. Proprietary & Confidential Information                                              13
Monitoring and Operat ions
Covalent can provide a wealth of expertise and assistance in establishing a comprehensive monitoring regime
for your newly established Web infrastructure. The Covalent Managed Server features a comprehensive SNMP
management agent that provides not only vital performance information in real-time, but also allows you to
control the Covalent Apache server operations and configuration from your management console, using
SNMP Version 3 which provides for encrypted communications and user security control.

Covalent professional services can work with operation in-house or out-sources operations staff to provide
focused consulting in integrating the Covalent products within your operations framework. By providing
training and best practices for monitoring and operating the Covalent products in a production environment,
we can help assure that your site meets its availability, reliability, and performance goals.

Risk Management
Of course, all projects have some amount of risk associated with them, but a robust planning and analysis can
help reduce and quantify that risk. In helping plan your migration project, Covalent will identify those
components that create the most risk, either from a schedule perspective because the scope of effort is not
clear, or from a technology perspective. In many cases, a prototyping/proof of concept effort can be useful to
obtain more detailed information that reduces the risk. In planning project phasing, it can also be useful to
plan the implementation of some high risk items for subsequent phases, to avoid impacting the initial project
rollout schedule. Covalent will work with you to determine the best methods of controlling risk during the
project in your environment.

Covalent Technologies, Inc. provides enterprise class support for your Covalent Apache production
environments. With options including 24 x 7 support, we can help make sure that any issues experienced with
Covalent Apache Web servers or supported modules are rectified quickly and professionally. Because Covalent
has deep Apache expertise, we can help to quickly isolate the problem, create work-arounds, and get you back
into production.

Our support goes beyond the Apache Web server itself. All modules supplied with standard Covalent products,
such as mod_perl, Tomcat, mod_php, and many others, are also supported with the same high level of
service. We can also provide support for other modules after a review by our engineering and support staff for

Current Netscape Web sites can be moved to a Covalent Apache-based solution, often with minimal effort.
Any successful migration requires detailed, careful planning; Covalent can provide the services and support
you need to make your move to Apache successful.

Covalent Technologies, Inc. Proprietary & Confidential Information                                            14
This appendix provides example checklists for assessing applications, and some risk factors to consider when
evaluating projects.

Che cklist for App licati on Assessment

           Number of physical servers

           Locations of physical servers

           Types of platforms for all servers

           Virtual hosting requirements

           Netscape versions

           Inventory of dynamic content

           Inventory of dynamic content enabling technology (scripts, number of scripts, languages, etc.)

           Inventory of third party integration (database, authentication mechanisms, load balancing
           software/hardware, app server technology, web to host, etc.)
           Inventory of any applications written with NSAPI

           List of web administrators

           List of web developers and content creators and affected software

           Type of SSL configuration and inventory of certificates and keys to be migrated to new system

           Hardware and networking inventory

           Inventory of training materials

           Necessary level of support (24x7, 8-5, etc)

           GUI requirements

           Site traffic levels

           Use of content distribution networks (Akamai, Inktomi)

Covalent Technologies, Inc. Proprietary & Confidential Information                                             15
Risk Fact ors to Consi der

  Service downtime                    Upgrade of migration platform on a different physical server, make sure all
                                      servers pass all tests prior to full deployment, and test and debug all
                                      applications prior to deployment.
  Applications not                    Make sure skilled resources are available to perform migration work,
  functioning properly after          especially for mission critical applications. Test and debug all applications
  migration                           prior to deployment, perform stress testing that simulates actual usage of the
                                      applications in order to uncover any performance problems.
  Project not completed on            During the planning process, estimates need to make sure the necessary time
  schedule                            is available to complete all work. Backup resources will be available in the
                                      event it takes longer than anticipated.
  Expenditures exceed                 Allowance for unexpected expenses such as hardware malfunctions, software
  budget                              upgrades, will need to be build into the estimate.

  Resistance to change by             Individuals who will be using the new system should be involved in the
  system users                        migration process.  Information will be provided in advance of the project
                                      outlining all the scope and goals of the project. Regular progress reports and
                                      adequate training will ensure support for the new technologies.

                                                                     Covalent Technologies, Inc.
                                                                     303 Second Street, Suite 375 South
                                                                     San Francisco, CA 94107

                                                                     Sales 415/856-4245 or 800/444-
Covalent Technologies, Inc. Proprietary & Confidential Information                                                 16

To top