If you're about to make the move from OAS to Oracle9iAS, let these expert tips make the process as painless as possible.

Don't let the similar names fool you. Oracle9i Application Server (Oracle9iAS) is not Oracle Application Server (OAS) with a facelift. Oracle9iAS is a whole new product, based on the Apache HTTP Server instead of Oracle's Spyglass server. This major change brings significant performance and reliability improvements and doesn't affect most OAS application code in major ways—but it does make the migration process a bit more challenging than a typical upgrade.

To help smooth your own migration process, this article describes relevant OAS/Oracle9iAS differences and provides tips to prevent snags, based on my experience migrating systems to Oracle9iAS.

Installing oracle9iAS

Overall, installing Oracle9iAS is easier than installing OAS. For example, you don't need a network card, and you don't need to install Oracle Portal (formerly WebDB) separately, since it's now included with Oracle9iAS. Do keep in mind these tips:

Choose UNIX over NT for your platform, if possible. If you have a choice of platforms to host Oracle9iAS, choose UNIX over NT. Apache, on which Oracle9iAS is based, runs faster and more efficiently on UNIX than it does on NT. The reasons for this difference have to do with the use of separate processes or forks in UNIX, compared to the use of threads in NT.

Shut down the database's Oracle9iAS HTTP listener before installing the full-blown Oracle9iAS. If you install Oracle9iAS with Oracle Portal included—after installing Oracle9i or Oracle8i Release 3—shut down the Oracle9iAS HTTP listener first. Both versions listen on port 80 by default. If you don't shut down the Oracle9iAS database listener before installing Oracle Portal, the database HTTP server starts first and consumes port 80, so the Oracle9iAS HTTP server can't start.

Configuring and Administering Oracle9iAS

Configuration and administration are considerably different for Oracle9iAS than for OAS. Much of this difference occurs because Oracle9iAS is based on Apache's HTTP server, not on Oracle's Spyglass HTTP server.

Oracle based Oracle9iAS on Apache, rather than Spyglass, because Apache offers many significant advantages. It's an extremely fast, extensible, open-source product with a huge developer base and a majority of the Web server market. Although OAS was already able to integrate with Apache, most customers used Spyglass because it came with the product and was the easiest option, though not the fastest (I found OAS to be at least two to four times faster with Apache, compared to Spyglass—and eight times faster with Apache and SSL encryption). Now, everything you need for Apache is on a CD provided with Oracle9iAS.

While the advantages of the move to Apache are many, there is a disadvantage: the lack of an administration or node-manager port for administering the Apache server. Oracle9iAS does provide browser-based administration for add-ons, such as the mod_plsql module that supports PL/SQL language development, but not for the server itself. For now, general Apache administration requires editing operating system files (primarily the httpd.conf file).

Although Oracle will be adding a GUI browser administrator in a future release, the current best bet for GUI editing of the httpd.conf file in Oracle9iAS is to download one of the GUI tools recommended at gui.apache.org. The most highly recommended of these tools appears to be Comanche—which, surprisingly, is a client/server tool, rather than a browser-based tool.

If you opt for Comanche, you'll need to get used to a couple of not-so-intuitive aspects of working with objects. To select an object, you must click on the text describing the object, not on the graphic for the object. Also, to configure an object, you must right-click on the object's text, and then select the Configure option.

Installing the Toolkit

If you'll be uisng Oracle9iAS with a newly installed database release earlier than Oracle8i Release 3 and migrating PL/SQL applications, part of your migration process will be installing the Oracle9iAS PL/SQL Web Toolkit, which is used for writing the code to produce the HTML that is sent to the browser. (If you're developing in a language other than PL/SQL, you won't have a prebuilt toolkit for this purpose; instead, you'll need to use other resources, such as the relevant classes in Java.)

Conveniently, this toolkit is included with Oracle9i Database and Oracle8i Release 3. However, if you don't have the OAS version of the PL/SQL Web Toolkit installed into the OAS_PUBLIC schema, you may have difficulty figuring out how to add the toolkit to your database. Basically, you'll need to find the owaload.sql script and run it—taking the precautions noted in the tips that follow.

Create an OAS_PUBLIC schema and install the toolkit into it. By default, the owaload.sql script loads the PL/SQL Web Toolkit packages into the SYS schema. If you're running on a database version prior to Oracle8i Release 3, I recommend installing the PL/SQL Web Toolkit into an OAS_PUBLIC schema instead. Doing so will provide a nice, clean separation between your database and system objects.

Don't let the owaload.sql script grant ALL privileges to PUBLIC for all toolkit packages. Another default of the owaload.sql script is that it grants ALL privileges to PUBLIC for all the PL/SQL Toolkit packages. I recommend granting EXECUTE privileges, rather than ALL privileges, to minimize security risks.

Migrating the Application

There are important architectural differences between OAS and Oracle9iAS, but the good news is that these differences generally won't affect the code in your PL/SQL applications. The PL/SQL Web Toolkit is exactly the same as it was in OAS. Only some very minor OAS features not within the toolkit have been changed in ways that may require code modifications. These changed areas include path names for running PL/SQL program units, methods for uploading and downloading files, the meaning of the SERVER_NAME parameter (see related tip that follows), the ability to run PL/SQL from an operating system file (now lost), and parameter-passing methods (positional parameter passing is no longer available, and flexible parameter passing now requires a pipe in the URL).

Migrating applications developed in languages other than PL/SQL can involve more effort than for PL/SQL applications. Instead of supporting development by using language-specific cartridges, Oracle9iAS uses third-party modules, or mods, that conform to the Apache Module API. Oracle9iAS mods include mod_plsql, mod_perl, mod_jserv, and mod_php; these provide migration paths for (respectively) the PL/SQL, Perl, JWeb, and LiveHTML cartridges (note that there is no migration path for C). Although PL/SQL migration is generally effortless, and Perl is fairly easy, the LiveHTML and Java paths are more challenging (see related Java tip that follows). Since the vast majority of OAS developers use PL/SQL, I have focused on the mod_plsql migration in this article.

Before I move on to migration tips, I should mention one of the major advantages offered for PL/SQL applications in Oracle9iAS: you can now embed PL/SQL in HTML code through PL/SQL Server Pages (PSPs). In OAS, using WebDB you could embed PL/SQL in HTML by using dynamic pages, but these pages were stored in the database in uncompiled format—to the detriment of performance. In Oracle9iAS, you can use PL/SQL Server Pages to achieve the same goal, but with much better performance, since PSPs are stored in a compiled format (a mod_plsql routine—basically a stored procedure) in the database.

The following tips may prove useful in your migration process:

Change SERVER_NAME to HTTP_HOST in calling for virtual domain name. The only code change we had to make in our applications was in using the command OWA_UTIL.get_cgi_ env('SERVER_NAME'). Under OAS, this command would return the virtual domain entered by the user (for example, partnerlink.myserver.com). Under Oracle9iAS, this call returns the actual server name (for example, mysite.myserver.com), regardless of the entered URL. To fix this problem, I changed the command to OWA_UTIL.get_cgi_env ('HTTP_HOST'). Note that HTTP_HOST also returns the port (for example, partnerlink.myserver. com: 1550) if the port is not port 80.

For Java, migrate to JSPs instead of JServ. Migrating from the JWeb cartridge to mod_jserv is a major effort, because it involves rewriting all of your code to follow the JServ specification. For an easier migration, I'd suggest migrating any Java components to Java Server Pages (JSPs). JSPs offer the same advantages as PSPs, with the added benefit of Java's power, openness, and other capabilities.

Creating DADs

The process of creating and configuring Database Access Descriptors (DADs) in Oracle9iAS is fairly painless, because it is part of the browser-based aspect of mod_plsql configuration (accessible at http://myhost/pls/simpledad/admin_/ gateway.htm). You simply fill in a few main fields (DAD name, schema name, Oracle User Name, Oracle Password, and Oracle Connect String), leaving the default values for the remaining fields in most cases (note that the flag called "Client Sessions" in OAS is now called "Session State").

Once you've set up your DADs, use the following tips to help out in a tricky areas:

Protect the path to your DADs. Currently, after you install Oracle9iAS, anyone who knows the URL to your server (for example, http://myhost/pls/admin_/gateway.htm) can go straight to the administration page for your DADs. To protect this virtual path, you must create a DAD that uses database authentication—prompting the user for a valid database schema, rather than storing the username and password in the DAD. After creating this DAD, add customized versions of the following lines to the wdbsrv.app file, right after the WVGATEWAY statement:

administrators = brownb ; set this to the      	
username that can administer DADs 
adminPath = /myadmin_/  ; change for extra 		
security
admindad = tuscadmin    ; DAD using DB 			
authentication

Once these changes are made, you must restart the Oracle9iAS HTTP server. Then, customize the basic URL to access the DAD administration page: http://myhost/pls/tuscadmin/myadmin_/gateway.htm.

Since the tuscadmin data does not have a password, and I set the administrators directive equal to "brownb," I would have to log on as brownb, but you can set this to any valid database schema/account. The database would have to have a user called "brownb" (or whatever username you use instead of "brownb"), since I am using database authentication with the tuscadmin DAD (or whatever DAD name you use) against the database.

Use Apache's URL-rewriting capability to remap the URL for calling DADs. In Oracle9iAS, the syntax for calling a DAD is different than in OAS. For example, say you used this URL in OAS: http://myhost/examples/assist.main_menu.

In Oracle9iAS, you would use the following URL instead: http://myhost/pls/examples/assist.main_menu.

If you have an OAS application with URLs that need to be rewritten to work with Oracle9iAS, you can use Apache's URL-rewriting capabilities to rewrite the URLs for you. To do so, you must first turn these capabilities on by uncommenting the following line in the httpd.conf file:

LoadModule      rewrite_module
	Modules/ApacheModuleRewrite.dll

Then, after the line AddModule mod_ssl.c, you add this statement:

AddModule mod_rewrite.c

Then, add code to rewrite the URLs to the configuration file (for example, after the line DefaultType text/plain), as in this example:

RewriteEngine on
	RewriteRule ^/plsql/(.*)
            $/pls/examples/$1 [R]

This code says to search for the virtual path that begins with "/examples/" and replace "examples/" with "pls/examples/".

Tipped Off, Not Tripped Up

Once you've migrated from OAS to Oracle9iAS, you'll discover more capabilities than I've had time to cover in this article (see the "Differences at a Glance" sidebar for a more complete list). Fortunately, you'll have saved some time during the migration process by following the tips provided here—so you can explore the wonders of Oracle9iAS application development in relative leisure.

Bradley D. Brown (brownb@tusc.com) is chairman and chief architect of TUSC (The Ultimate Software Consultants), a full-service consulting company specializing in Oracle with offices in Chicago, London, and Atlanta. Brown has been working with management information systems for more than 19 years, the last 14 years with a focus on Oracle, and he is currently working on Oracle9i Web development. His books include Oracle Application Server Web Toolkit Reference (Osborne/McGraw-Hill, 1998) and Oracle8i Web Development (1999).