Chapter 10 - Migrating Web Sites and Applications

On This Page

	Migrating CGI Applications to IIS
	Migrating from Netscape Enterprise Server
	Migrating from Lotus Domino
	Resources

Migrating from one Web server to another involves two main tasks: migrating configuration settings and migrating applications.

Of these two tasks, migrating applications is certainly the most potentially complex and difficult. Many applications are written to the CGI specification; quite often it makes sense to migrate these applications to an IIS technology such as the Internet Server API (ISAPI) or Active Server Pages (ASP).

As for migrating configuration settings, the IIS Resource Kit CD includes the IIS Migration Wizard to help with this task. The current version of the IIS Migration Wizard migrates settings from Netscape Enterprise Server versions 2.0 and 3.0.

The chapter begins with a discussion on how to migrate CGI applications. The next section describes migrating from Netscape Enterprise Server; it documents the configuration settings migrated by the IIS Migration Wizard and compares a sample ASP application to an application written in Netscape LiveWire script. The final section of the chapter examines issues involved in migrating from Lotus Domino to IIS.

Migrating CGI Applications to IIS

As organizations move to deploy Web-based applications on Windows NT and IIS, they are naturally concerned about whether and how to migrate existing Web applications to IIS. Often, these applications have been built to the Common Gateway Interface (CGI) specification and take the form of scripts written in interpreted languages like Perl or Tcl, or monolithic executables written in C or C++. IIS fully supports both scripts and executables written to the CGI specification.

But IIS offers far more than just a hospitable environment for CGI applications. IIS provides both the Active Server Pages (ASP) scripting environment and the Internet Server API (ISAPI), which allow developers to write applications that are faster and more scalable than CGI applications on Windows NT. In addition, IIS provides some compelling application development features, such as script debugging and built-in database connectivity.

This section assumes the reader is familiar with Web-based applications and CGI. While several migration strategies are discussed, the focus is on migrating CGI applications to Active Server Pages.

Note This chapter is not a general-purpose guide to porting applications from other environments (such as UNIX systems) to Win32, nor is it a tutorial on all the development features within the Active Server Pages environment. For more information on developing with ASP, see Chapter 5, "Developing Web Applications."

Comparing CGI Applications to IIS Applications

As CGI developers are aware, a server responds to a CGI execution request from a client browser by creating a new process. That is, a new, separate process is created for every client request handled by a CGI application, even if a single client submits more than one request. At any given time, the server is supporting a separate process for every ongoing request. When a request is complete, the server must perform a series of steps to delete the process.

CGI was created for a UNIX environment where processes are the basic unit of operation and have less overhead than processes in Windows NT. In Windows NT, where threads are the basic unit of operation, processes have substantial overhead. Each process receives a private physical memory allocation, is granted space in the paged and nonpaged memory pools, and is protected by the Windows NT security model. In fact, every attribute that makes processes in Windows NT robust also makes them costly. Because each CGI request generates a new process, CGI applications have much higher overhead than ASP or ISAPI applications.

As a result, CGI performance is considerably reduced under Windows NT. Some benchmarks show that CGI applications run anywhere from three to five times slower than ISAPI applications and two to three times slower than ASP applications. For more information, see the "Web Application Performance" section in Chapter 3, "Capacity Planning."

CGI applications also scale poorly on Windows NT. Adding additional processing power or RAM typically does not allow a CGI application to support many more concurrent users. Therefore, if an application will be heavily used, there are strong reasons to move to a solution that uses ISAPI or ASP and components. ISAPI applications offer some performance advantages over ASP applications, but ASP applications can be developed much more quickly. The difference is comparable to the difference between developing in C or C++ and developing in Visual Basic.

Active Server Pages is an open, server-application environment in which you can combine HTML, server-side scripts, and reusable ActiveX server components to create dynamic and powerful Web-based business solutions. ASP enables server-side scripting for IIS with native support for both Visual Basic Scripting Edition (VBScript) and JScript. In addition to these native languages, the ASP environment supports any scripting language that conforms to the Active Scripting requirements. For example, there are Win32 implementations of the Perl, Tcl, and Python languages.

Unlike CGI applications, which cause a new process to be created with each execution request, ASP applications run on lighter-weight Win32 threads. IIS transparently and efficiently manages pools of such threads and allocates resources appropriately to service incoming requests.

ASP applications can be configured to run either in process, that is, within the IIS Web server process (for fastest execution speed), or out of process, isolated from the server process and running in their own processes (for maximum safety). Even when they are run as out-of-process applications, ASP and ISAPI applications typically execute much faster than CGI applications.

Developers are free to choose the level of process isolation appropriate for their needs. For example, while an application is under development, the developer may choose to run an application in its own memory space; when the application is in production, it can be run in process with the Web server.

Note Some developers are concerned that Active Server Pages requires them to support only one type of browser. But ASP pages contain server-side scripts that send HTML to the browser. The HTML they generate is completely under the developer's control. In no way does ASP tie the developer into supporting a particular browser.

Migration Strategies

There are several approaches to migrating an existing CGI application to the IIS environment.

Port the CGI Application to Win32

Although CGI applications are inherently inefficient under Windows NT, it is possible simply to port an application to Win32, leaving it as a straight CGI application. IIS supports CGI applications that expect to receive input via environment variables and the standard input stream, and expect to write output via the standard output stream. If your application can port to Win32, this may be all that is required.

If you port your CGI application, you should examine the code to see just how much of it is needed in the ASP environment—you may find that within the ASP environment, much of the application's code is unnecessary. This topic is further discussed in "Migrating to Active Server Pages" later in this chapter.

Because CGI applications do not scale well on Windows NT, simply porting an application to the Win32 environment is not a good idea if the application needs to support many concurrent users (or "hits"). The best way to build a scalable application is to use Active Server Pages and components.

If your current application is a script make sure you have a Win32-compatible version of the script interpreter available. The following Web sites provide Win32 implementations of Perl, Tcl, and Python:

Migrating Perl Scripts

The ActiveState Tool Corporation provides three options for running Perl scripts on Windows NT: Scripts can be run as CGI executables (Perl for Win32), as DLLs within the IIS process (Perl for ISAPI), or within the ASP environment (PerlScript). The ASP environment provides the best performance, but you may need to modify your scripts to run within it (for more information, see "Migrating to Active Server Pages" later in this chapter). If you want to migrate a script with minimal or no modification, Perl for ISAPI offers the best performance. The advantage of Perl for ISAPI is that a separate process is not created for every request, as is the case for CGI executables on Windows NT. For more information, see http://www.activestate.com/ .

Port the CGI Application to an ISAPI DLL

If a CGI application has been written in C or C++, it may be feasible to convert it into an Internet Sever API (ISAPI) dynamic-link library (DLL). This would help the application's performance, and would begin to take advantage of some of the IIS application development features.

Usually, ISAPI application DLLs no longer read input from the standard input stream or write to the standard output stream but rather communicate through a data structure called the Extension Control Block (ECB).

IIS typically loads an ISAPI DLL the first time a request that calls the DLL is received; the DLL then stays in memory, ready to service other requests until the server decides it is no longer needed. IIS can also load ISAPI DLLs on startup and cache them for future use, thus enhancing performance.

Under IIS 4.0, an ISAPI DLL can be deployed by the developer or system administrator to run either within the IIS process or in its own process.

For more details on developing ISAPI applications, see the documentation in the Microsoft Platform Software Development Kit (SDK). The Platform SDK can be obtained at http://msdn.microsoft.com/.

Creating ISAPI DLLs also requires a thorough understanding of the Win32 programming environment, including thread management. For some useful information sources on Win32 programming, see the "Resources" section at the end of this chapter.

Port the CGI Application to Active Server Pages

When you port your application to Active Server Pages, you may be able to:

You can choose the scripting language used within an ASP page. If the CGI application is written in C or Java, it may be easiest to use JScript because of its syntactical similarity. If the CGI application you're porting is written in Perl, it may be convenient to use PerlScript.

In any case, consider using Visual Basic Scripting Edition (VBScript) for building ASP pages. Millions of developers use the Visual Basic language. Organizations that move to VBScript can take advantage of this synergy and may find they have many more resources available to support them.

Script interpreters for JScript and VBScript are included with IIS. Interpreters for PerlScript and other languages are available from third parties.

The following sections outline some of the tasks you may need to perform when moving CGI applications to the ASP environment.

Migrating to Active Server Pages

The first step in planning a migration is to examine the CGI application. Many developers find they can divide their existing applications into five major types of logic:

A general discussion on how to handle each of these kinds of logic follows.

Input Processing

A great deal of CGI processing revolves around capturing the contents of HTML forms as presented to the standard input stream, then reformatting them, decoding the HTML, reading environment variables, and so on. Because this is one of the most tedious aspects of developing CGI applications, many developers have used third-party libraries and tools, such as the Perl utilities Cgi.pm or Cgi-lib.pl. In most cases, these utilities are unnecessary in ASP applications; the ASP environment takes care of most of these housekeeping tasks for you.

Accessing Form Input and Decoding HTML

One of the major differences between CGI applications and ASP applications is how form input is handled. Accessing form data from an ASP page is much simpler than from a CGI application.

A CGI application written in Perl receives form input from a POST request on the standard input stream using code such as:

$form_size = $ENV('CONTENT_LENGTH');
read( STDIN, $form_data, $form_size );

Note that this form data is encoded and must be translated. Using Perl, the translation code might look like this:

$value =~ s/%([0-9a-fA-F]{2})/pack("c",hex($1))/ge;

Once the form data is decoded, the developer can search for a form variable. Here is a typical Perl routine to parse form data and place it in a list:

sub get_form
{
local (*FORM) = @_;
local ( $env_string, @collection, $key_value,
$key, $value );
read (STDIN, $env_string, $ENV{'CONTENT_LENGTH'});
@collection = split( /&/, $env_string );
foreach $key_value (@collection) {
($key, $value) = split( /=/, $key_value);
$value =~ tr/+/ /;
$value =~ s/%([0-9a-fA-F]{2})/pack("c",hex($1))/ge;
if (defined($FORM{$key})) {
$FORM{$key} = join("\0",, $FORM{$key}, $value);
} else {
$FORM{$key} = $value;
}
}
}

Once the routine is in place, it can be called to parse the form. The following code calls the get_form routine and references a variable called home_address:

&get_form(*my_form);
print $my_form('home_address');

Fortunately, the ASP environment takes care of these form processing and decoding chores for you. In ASP, the content of an HTML form is made available as a collection. For developers familiar with languages like Perl or Awk, collections are analogous to "hashes" or "associative arrays." They are named lists of key/value pairs.

Form variables are included in the Form collection of the Request object.

Instead of referring to a form variable with a Perl construction like:

print $my_form('home_address');

you can refer to a form variable as shown in the following VBScript example:

MyAddress = Request.Form("home_address")

Here's the same instruction written in PerlScript:

$MyAddress = $Request->Form('home_address')

Remember, there is no need to parse the input, as was required in the CGI example, because the ASP environment takes care of it.

Although ASP applications do an excellent job of eliminating form processing drudgery, developers sometimes need access to the unprocessed input stream. The following VBScript fragment writes the unprocessed input stream back to the output stream:

Response.Write Request.Form

In addition to the Form collection, the Request object includes a collection called QueryString. This collection contains form elements sent in response to the GET method of the HTML <FORM> tag. The elements of the QueryString collection are accessed in the same way elements of the Form collection are accessed.

Often, quite a bit of CGI code is devoted to determining whether a given form variable exists within the QUERY_STRING environment variable or in the standard input stream. However, within the Active Server Pages environment, you can avoid testing many of these conditions simply by referring to a variable by name:

MyVariable = Request("home_address")

In this case the Web server will search the QUERY_STRING first, then the form, in order to find the correct variable. This feature may eliminate the need to rewrite code to search both the query string and the form.

If an application needs to encode URLs or HTML, you can take advantage of the built-in HTMLEncode and URLEncode methods of the Server object.

In many cases, developers migrating CGI applications find they can remove most of the third-party form decoding and processing utilities, as well as any homegrown generic form processing modules.

Environment Variables

CGI applications that inspect environment variables can continue to do so when converted to ASP. Environment variables are provided as part of the Request object's ServerVariables collection.

Whereas in a CGI application, you might access the SERVER_NAME environment variable with something like the following line of C code:

serverName = getenv("SERVER_NAME");

or the following line, written in Perl:

serverName = $ENV{'SERVER_NAME'};

in ASP, you can use the following instruction, written in VBScript:

serverName = Request.ServerVariables("SERVER_NAME")

You can iterate through collections such as ServerVariables in order to examine all the values they contain. The following ASP page written in VBScript generates an HTML table containing all the variables contained in the ServerVariables collection with their values:

<%@ LANGUAGE=VBSCRIPT %>
<html><body>
<table border=1>
<% for each name in request.ServerVariables %>
<tr>
<td><%= name %></td>
<td><%= request.ServerVariables( name )%></td>
</tr>
<% next %>
</table>
</body></html>

Business Logic

Once much of the "plumbing" is removed from a CGI application, some business logic that needs to be ported usually remains. There are at least two approaches to migrating business logic:

Components can be written in any language that supports the Common Object Model (COM), including C, C++, Java, Visual Basic, Delphi, and even some implementations of COBOL.

Note Server-side components run completely within the server environment. Their use has no effect on whether an application can support a particular browser on a specific platform.

It is important to consider overall application architecture. Building a successful and scalable distributed application, where application logic can reside on a Web client, a Web server, and on other back-end servers (such as databases) requires a careful separation of the application's functionality into logical groups of services, or "tiers."

For more information on designing and building Web applications using components, see Chapter 5, "Web Application Development." For references to additional information, see the "Resources" section at the end of this chapter.

External Gateway and Database Logic

CGI applications were originally created to allow Web clients access to applications outside the Web itself. Although the majority of existing CGI applications interface with databases of some sort, many CGI applications are used to provide services such as page counters, or to access services such as electronic mail servers. This section describes techniques for accessing databases and other external services through ASP.

Databases

ActiveX Data Objects (ADO) is a highly efficient database access method that can be used within the Active Server Pages environment. ADO is included with IIS on the Windows NT 4.0 Option Pack.

ADO exposes an object model to abstract the ideas of connecting to and executing commands against a remote database. The database need not support Structured Query Language (SQL), but a database-specific piece of software called an OLE DB Provider is required. If your database vendor supplies an Open Database Connectivity (ODBC) driver for your database, you can use a provider for ODBC data sources supplied with IIS.

Perl developers commonly access a database using a package like dbperl or the more current DBI package. No special package is required within the ASP environment. For example, the following simple ASP page written in PerlScript dumps the contents of a table called Orders using the ODBC datasource ADOSamples:

<%@ LANGUAGE=PerlScript %>
<html>
<body><p>
<%
$Conn = $Server->CreateObject("ADODB.Connection");
$Conn->Open( "ADOSamples" );
$RS = $Conn->Execute( "SELECT * FROM Orders" );
%>
<TABLE BORDER=1>
<TR>
<%
$count = $RS->Fields->Count;
for ( $i = 0; $i < $count; $i++ ){
%><TD><B><%= $RS->Fields($i)->Name %></B></TD><%
}; %> </TR> <%
while ( ! $RS->EOF ) {
%> <TR> <%
for ( $i = 0; $i < $count; $i++ ) {
%><TD VALIGN=TOP>
<%= $RS->Fields($i)->value %></TD><%
};
%> </TR> <%
$RS->MoveNext;
};
$RS->Close;
$Conn->Close;
%>
</TABLE>
</BODY>
</HTML>

ADO is designed to be highly efficient in a multithreaded environment, where many concurrent instances of the ADO code execute simultaneously. Thus, ADO is ideal for Web server environments, particularly when they need to scale up to many concurrent users.

An additional benefit to working within the ASP environment is the ability to take advantage of the services of Microsoft Transaction Server (MTS). MTS is an integral part of the ASP environment. MTS not only provides support for process isolation, as discussed above, but also provides a simple way for developers to build scalable Web applications based on components. MTS takes care of all the plumbing issues, including transactions, connection management, and thread management, thus freeing the developer to concentrate primarily on building business logic.

For more information on ADO and MTS, see Chapter 6, "Data Access and Transactions," as well as the Transaction Server Web site at http://msdn.microsoft.com/library/en-us/mts/mtsportal_1lwl.asp.

More general information on ADO, ODBC, as well as Microsoft's overall data access strategies can be found at http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28001860.

The Perl-based DBI package and documentation, including ideas for porting existing DBI code to the Win32 platform.

Electronic Mail

Many CGI applications exist just to format RFC-822 e-mail messages for delivery to a mail server such as sendmail. This functionality can be reproduced easily within the ASP environment.

Note that IIS includes an SMTP Service and exposes all of its functionality through the Collaboration Data Objects (CDO) object model. Once the SMTP Service is properly installed and configured, an e-mail message can be scripted as simply as shown in the following ASP script, written in JScript:

<% @language=JScript %>
<%
var msg;
msg = Server.CreateObject("CDONTS.NewMail");
msg.From = "someone@microsoft.com";
msg.To = "someone@microsoft.com";
msg.Subject = "Test message";
msg.Body = "This is a sample message.";
msg.Send();
%>

Page Counters

Many of the CGI applications available on the Internet are page counters. Although many of these counters can continue to be used, the IIS Resource Kit CD supplies a PageCounter object that efficiently records hits into a disk-based hit-count data file. The developer can easily query the component in order to display the hit count or build a more elaborate display.

The following ASP page, written in PerlScript, demonstrates the use of the page counter component supplied with IIS 4.0:

<% @language=PerlScript %>
<html>
<body>
<%
$counter = $Server->CreateObject("MSWC.PageCounter");
$hits = $counter->Hits;
%>
You are visitor number <%= $hits %> to this page.
</body>
</html>

The File System

Quite a few CGI applications need to interact with the file system. There are several approaches to accessing the file system from within the ASP environment.

The easiest method is to use the FileSystemObject and TextStream objects. These objects provide high level access to the file system. For example, the following ASP page, written in VBScript, creates a text file, and writes the contents of the environment variable SERVER_NAME to its own line:

<% @language=VBScript %>
<html>
<body>
<%
dim objFS, objFile, append
append = 8
set objFS = Server.CreateObject("Scripting.FileSystemObject")
set objFile = objFs.OpenTextFile("c:\servlist.txt", append, True )
objFile.WriteLine Request.ServerVariables("SERVER_NAME")
objFile.Close
%>
Done
</body>
</html>

If the supplied FileSystemObject and TextStream objects do not meet your needs, file system access can be encapsulated with an ActiveX component.

Maintaining State

There are several schemes commonly used in CGI applications for maintaining state information about the client session on the Web server. Some of these involve scripts that save and restore data from server-side text files. Some involve embedding state in the client side HTML (in, say, hidden form fields). Some CGI applications even maintain state by setting themselves up as "mini Web servers" for the duration of the session, intercepting incoming HTTP requests.

Many Web developers have moved to using browser-based cookies for storing state information.

Active Server Pages provides built-in state management using session variables. When a client first connects to the application, a "session cookie" can be sent which identifies the new session. As the browser accesses other pages in the application, the cookie is retrieved by the system and is used to manage state.

All this is transparent to the Web developer. The developer has access to the Session collection of variables. For example, consider an ASP page in which the user's login name is retrieved and assigned to a session variable:

Session("login_name") = Request.Form("login_name")

The value of login_name will be available to all other pages within the application, until the session times out (the default is 20 minutes, but is configurable) or is explicitly abandoned.

Output Handling

A key difference between ASP applications and CGI applications is that in an ASP page, the developer can weave industry-standard HTML with scripting code to deliver the appropriate HTML to the client.

Many CGI applications emit HTML using the output facilities of the language they're written in. For example, a simple Perl-based CGI application might look like this:

#!/usr/local/bin/perl
print "Content-type: text/html", "\n\n";
$server_name = $ENV('SERVER_NAME');
print "<html><body>Your server name is ", $server_name;
print "</body></html>";
exit(0);

Note that the HTML is embedded within the print function. Here is the corresponding ASP page, with code written in VBScript:

<html>
<body>
Your server name is <%= Request.ServerVariables("SERVER_NAME") %>
</body>
</html>

Note that the entire page is just simple HTML, except for the construct

<%= Request.ServerVariables("SERVER_NAME") %>

which is a VBScript expression.

You can use both HTML and server-side script code within the same page to combine the most powerful elements of both environments.

Some applications need to specify HTTP header information, rather than using the default MIME type of text/html. In the ASP environment, this can be accomplished by using the ContentType property of the Response object. For example, the following instruction sets the content type to "text/plain":

<% Response.ContentType = "text/plain" %>

Many Perl-based CGI applications use the freely available Cgi.pm or Cgi-lib.pl modules. These tools assist the CGI developer tremendously in formatting HTML output, as well as performing other tasks.

For example, the following script uses Cgi.pm to generate a form that collects the user's address; once the form is submitted, the script redisplays the form with the address beneath it:

use CGI qw(:all);
print header;
print start_html('Enter your address'),
h1('Enter your address'),
hr,
p,
start_form,
table(
Tr(td("Street"),td(textfield('street'))),
Tr(td("City"), td(textfield('city'))),
Tr(td("State"), td(textfield('state'))),
Tr(td("Zip"), td(textfield('zip')))
),
submit,
end_form,
hr;
if (param())
{
print
"Street is: ", param('street'), p, 
"City is: ", param('city'), p,
"State is: ", param('state'), p,
"Zip is: ", param('zip'), p,
hr;
}

This script provides a convenient way to lay out a form if you aren't able to generate the HTML as part of the source code. The drawback to these sorts of utilities is that they require the developer to master a "pseudo-HTML" dialect in order to generate the page.

The corresponding ASP page (with script written in VBScript) looks almost exactly like the actual HTML page that will be sent to the browser.

<html>
<head><title>Enter your address</title></head>
<body>
<h1>Enter your address</h1>
<hr>
<p>
<form method=post>
<table>
<tr><td>Street</td><td><input name="street"></td></tr>
<tr><td>City</td><td><input name="city"></td></tr>
<tr><td>State</td><td><input name="state"></td></tr>
<tr><td>Zip</td><td><input name="zip"></td></tr>
</table>
<input type=submit>
</form>
<hr>
<% if Request.Form.Count > 0 %>
Street is: <%= Request.Form("street") %> <p>
City is: <%= Request.Form("city") %> <p>
State is: <%= Request.Form("state") %> <p>
Zip is: <%= Request.Form("zip") %> <p>
<hr>
<% end if %>
</body>
</html>

The freedom to use authentic HTML as part of the application code is a benefit that cannot be overemphasized. This feature allows the developer to emit any HTML that the client browser supports, whereas utilities like Cgi.pm are necessarily limited by the tags they have chosen to implement. As new developments such as Dynamic HTML (DHTML) come along, tools like Cgi.pm have to be modified, perhaps heavily, to support new tags or other new client-side features.

In addition, Web designers and staff other than programmers can author in pure HTML. Using a special HTML dialect prevents these users from being able to modify the generated HTML.

Summary

Developers often find, after examining their CGI application and removing code that is not required within the ASP environment—form processing, environment variable processing, e-mail manipulation, database handling, state management, and most importantly, output processing—that they are left with much smaller applications to migrate. Migration is usually very manageable. As a result, developers are free to concentrate on business logic, rather than building software infrastructure.

Top of page

Migrating from Netscape Enterprise Server

The IIS Migration Wizard, included on the IIS Resource Kit CD, migrates Web server settings, the virtual directory structure, and user accounts from Netscape Enterprise Server (NES) version 2.0 or 3.0 to IIS. This section describes which settings the IIS Migration Wizard migrates and which ones it does not. The section also provides information on how settings are migrated and on the differences between configuring NES and IIS. The last part of this section walks through a sample Active Server Pages application and compares it to a Netscape LiveWire application.

Note For instructions on using the IIS Migration Wizard, see the online Readme file included on the IIS Resource Kit CD.

Definition of Terms

Here are some essential terms used in Netscape Enterprise Server with explanations of their equivalents in IIS.

Netscape Enterprise Server Administration Settings

This section lists Netscape Enterprise Server (NES) administrative settings as they are displayed in the NES Server Manager user interface and indicates whether, and how, the IIS Migration Wizard migrates those settings. Each heading within this section corresponds to a settings tab within the NES Server Manager.

Server Preferences

In IIS, administrative settings are called properties and can be set on the server, site, directory, or even file level. Most of the NES settings listed in this section apply to the site level. In IIS, you can view and change properties in the Internet Service Manager. To view site properties, right-click a Web site in the Internet Service Manager and select Properties from the menu. For more information, see "Server Administration" in the Windows NT 4.0 Option Pack online documentation.

Table 10.1 NES Server Preferences 

Programs

The settings in this section deal with Web applications. IIS supports CGI applications, but since CGI applications don't run efficiently in the Windows NT environment, you should consider converting them into Active Server Pages (ASP) or ISAPI applications. For more information, see "Migrating CGI Applications to IIS," earlier in this chapter.

For information on configuring CGI applications to run on IIS, see the topics under "Configuring Applications" in the "Server Administration" section of the IIS online documentation.

IIS supports VBScript and JScript within the ASP environment.

Table 10.2 NES Programs Settings 

Server Status

The settings in this section primarily have to do with server logging. For more information on logging, see "Logging Web Site Activity" in the Windows NT 4.0 Option Pack online documentation.

Table 10.3 NES Server Status Settings 

Configuration Styles

The settings under this heading are not migrated to IIS. IIS includes support for property inheritance, which achieves much the same result as configuration styles. Within the Internet Service Manager, you can right-click the server and set global properties for the WWW Service. Every new Web site created on the server inherits the server's global properties. Similarly, when you set properties for a Web site, directories created for the site inherit the site's properties.

Content Management

The IIS Migration Wizard migrates most of the NES settings listed in this section.

Table 10.4 NES Content Management Settings 

Web Publishing

Web publishing settings are not migrated. These features can be supported with client-side development and management tools such as Microsoft FrontPage (a member of the Microsoft Office family), Visual InterDev^™, and Microsoft Content Analyzer (included in the Windows NT 4.0 Option Pack; a more full-featured version is available as a component of Microsoft Site Server).

Agents and Search

Agents and Search settings are not migrated. Microsoft Index Server is the tool used to index and search Web sites maintained on IIS. This tool, included in the Windows NT 4.0 Option Pack, is easy to install and configure. For information on Microsoft Index Server, see the Windows NT 4.0 Option Pack online documentation.

Auto Catalog

Auto Catalog settings are not migrated. As with Agents and Search settings, IIS uses Microsoft Index Server to build a searchable catalog of information about the content of the Web site.

Moving User Accounts to IIS

You can port your user account database from Netscape Enterprise Server (NES) 3.0 to the Windows NT user account database. You begin the process by exporting your users from NES 3.0 to an LDIF-formatted file. The IIS Migration Wizard uses that file to create another intermediary file. Next, copy this file to the Windows NT server and use it as input to the AddUsers utility, which is included on the IIS Resource Kit CD. AddUsers, as its name promises, adds users to the Windows NT user account database. It will still be necessary to set users' attributes and groups. The passwords for the imported users will default to blank with an immediate expiration. When a user first logs on, the user will be required to enter a new password.

For more information on using the IIS Migration Wizard to import users to Windows NT, see the IIS Migration Wizard documentation on the IIS Resource Kit CD.

Note The IIS Migration Wizard cannot migrate users from Netscape Enterprise Server 2.0.

Migrating to Active Server Pages

Active Server Pages (ASP) is the recommended choice for writing applications to run on IIS. This section describes a sample ASP application that accesses a database, and compares aspects of its code to the VideoApp sample LiveWire application included with Netscape Enterprise Server 3.0. For more information on developing applications in IIS, see Chapter 5, "Developing Web Applications."

Development Tools

Microsoft Visual InterDev is recommended for creating IIS Web applications. A major advantage to using Visual InterDev is that it handles a lot of database programming chores for you. When you want to add a database connection to your project, a couple of mouse clicks do the job. If you want to build an ASP application that lists records from a database and provides buttons to navigate through the database, Visual InterDev provides design-time ActiveX Controls that make this a trivial effort. It also provides access to database design tools and SQL query building tools that make working with a database much easier.

For more information on Visual InterDev, visit http://msdn.microsoft.com/vinterdev/.

IIS also includes Microsoft Script Debugger. This tool, included in the Windows NT 4.0 Option Pack, supports the usual debugging activities, including the setting of break points, discovery of variable values, setting variables, and so on.

A number of third-party tools, such as HomeSite, are available for Active Server Pages development. For information on HomeSite, visit http://www.macromedia.com/.

Dagwood: A Sample Application

The Dagwood sample application keeps track of items neighbors might borrow from you. The application allows the user to display a list of available items and borrow an item. The application works with a SQL Server database to retrieve lists of items, to record items being borrowed, and to record items being returned. The Dagwood application is available on the IIS Resource Kit CD, along with a Readme file with instructions on how to set up the application and try it out for yourself.

The first thing the Dagwood application does when it starts up is establish database connectivity via an ODBC Data Source Name (DSN). For information on using DSNs, see Chapter 6, "Data Access and Transactions" or the Windows NT 4.0 Option Pack online documentation.

Next, Dagwood sets a few essential session variables so that the rest of the Web pages in the application can access the database. In the following code sample, taken from the application's Global.asa file, several session variables are set. The ASPsample_ConnectionString value represents the string used to connect through the DSN defined for the database. The other variables represent other relevant database settings that can be used throughout the application. Global.asa is an excellent place to initialize useful application-wide variables. The variable neighbor holds the key to the Neighbor table, which stores information about the person logged on; the variable item holds the key to the Item table, where information about items that can be borrowed is stored.

<SCRIPT LANGUAGE=JScript RUNAT=Server>
function Session_OnStart() {
//--Project Data Connection
Session("ASPsample_ConnectionString") =
"DSN=Dagwood;Description=Database for sample Dagwood
application;APP=Microsoft (R) Developer Studio"
Session("ASPsample_ConnectionTimeout") = 15
Session("ASPsample_CommandTimeout") = 30
Session("ASPsample_RuntimeUserName") = "sa"
Session("ASPsample_RuntimePassword") = ""
Session("neighbor") = 0
Session("item") = 0
}
</SCRIPT>

Compare this sample with the code that would be needed to establish database connections in a LiveWire application. In sample LiveWire applications such as Netscape's VideoApp, a substantial amount of code is needed to create and manage connection pools. This code is not needed when using ODBC, because connection pooling is handled automatically. It's recommended that you avoid using connection-pooling code in your application and allow the ODBC driver to handle it for you. It is more efficient and easier to code as well.

As you plan the architecture of your Web applications, consider taking advantage of Microsoft Transaction Server (MTS), included with the Windows NT 4.0 Option Pack. This is the preferred method of managing the commitment of successful transactions and the rollback of failed ones. It allows you to avoid writing application-specific code for this purpose. In the simplest case, you need only include the instruction <%@ TRANSACTION = Required %> as the first line of an ASP page to take advantage of MTS.

MTS is used in the Dagwood application in Borrow.asp and in Return.asp, which update two separate tables as part of each transaction to borrow or return an item. Once you have assigned an MTS transaction to a page, all database activity on that page is transacted. If the script completes with no errors, updates are automatically committed to the database. If you abort the transaction using conditional code by calling the SetAbort method, the entire transaction is failed and all database activity is rolled back. In contrast, the VideoApp LiveWire application uses extensive code to manage transaction commitment and rollback. Custom transaction code is more complex, more difficult to maintain, more likely to fail, and less scalable than MTS.

The home page for the Dagwood application is Default.htm, shown in the following figure. This page is the central point from which the user can access all other Web pages in the application.

Figure 10.1 The Dagwood application's home page 

The first thing a Dagwood user will likely want to do is borrow an item. To begin the process, the user clicks the I want to borrow something hyperlink on the Dagwood home page, which displays Type.asp, shown in the following figure.

Figure 10.2 Type.asp 

The Type.asp code is shown in the following listing. The code is heavily commented to explain what each instruction does.

<%@ LANGUAGE="JSCRIPT" %>
<HTML>
<HEAD>
<TITLE> Select your item type</TITLE>
</HEAD>
<BODY>
<CENTER>
<H2>Please select the type of item you want to borrow.</H2>
<%
// create database connection object
Conn = Server.CreateObject("ADODB.Connection");
// open the database connection
Conn.Open(Session("ASPsample_ConnectionString"));
// select records from the database
rsTypes= Conn.Execute("Select * FROM types Order by type");
// if there aren't any records
if (rsTypes.EOF)
{
// tell them the table is empty
Response.Write('<b>Database contains no item types!</b>');
}
else
{
// There is at least one record, so build an HTML table for it
Response.Write('<TABLE CELLSPACING=3 BORDER>');
Response.Write('<CAPTION><B>Item Types</B></CAPTION>');
// while we are not at end of file
while (!(rsTypes.EOF))
{
// Write out each item from the database into the table
Response.Write('<TR><TD><A HREF="Item.asp?type=');
Response.Write(rsTypes("type").Value + '">');
Response.Write(rsTypes("type").Value + ' </A> </TD> </TR>');
// move to the next row in the database
rsTypes.MoveNext();
// go back to the top of the while loop
}
// we have reached EOF, so finish off the table
Response.Write('</TABLE>');
}
%>
<P><A HREF="default.htm">HOME</A></P>
</CENTER>
</BODY>
</HTML>

Type.asp accesses a sample database and retrieves a list of the types of items that can be borrowed. In contrast to the LiveWire code in the VideoApp application, the use of session variables makes it possible to avoid building any constructs that require locking access to those variables. Also, because no code is used to support pooled connections, the database connection code is quite straightforward. A connection to the database is established, a session is opened, and records are retrieved from it. A new connection is created by the server only when needed. Where possible, the connection is drawn from a pool of connections managed by the driver. Once the execution of the page terminates, the database connection is automatically returned to the pool.

The user then sees the list of types of items available to be borrowed, and can select one of those types to see the list of items of that particular type available. Each type is formatted as a hyperlink to Item.asp. When the user clicks on a type, Item.asp is called and the type selected is passed to it. In the following figure, the user has chosen the "cameras" type, so the page displays a list of cameras available for borrowing.

Figure 10.3 Item.asp 

The source code for Item.asp is shown in the following listing. The script checks first to see whether the type variable has been passed to it. The type variable might not be passed if the user typed the page's URL for some reason and bypassed the Type.asp page that normally calls it.

<%@ LANGUAGE="JSCRIPT" %>
<html>
<head>
<title>List of items in Dagwood's garage.</title>
</head>
<body>
<CENTER>
<H1>Dagwood wants to know what you want to borrow!</H1>
<%
// If they got to this page without passing an item type
if (Request.QueryString().Count == 0)
{
// tell them to pick an item and send them back
Response.Write('<CENTER><A HREF="item.asp">');
Response.Write('Please select an item type</A></CENTER>');
}
else
{
// create database connection object
Conn = Server.CreateObject("ADODB.Connection");
// open the database connection
Conn.Open(Session("ASPsample_ConnectionString"));
// select records from the database
rsItems = Conn.Execute("Select * FROM items WHERE qoh > 0 AND type = '"+Request("type")()+"' Order by i_name");
// If there aren't any rows in the table
if (rsItems.EOF)
{
// then tell them the table is empty
Response.Write('<b>There are no items of this type.</b>');
}
else
{
// There is at least one row, so build an HTML table for it
Response.Write('<TABLE CELLSPACING=3 BORDER>');
Response.Write('<CAPTION><B><FONT SIZE=+1>Items in stock for ');
Response.Write(Request("type")() + '</FONT></B></CAPTION>');
Response.Write('<TR><TH>Name</TH><TH>Description</TH></TR>');
// while we are not at end of file
while (!(rsItems.EOF))
{
// Write out each row from the database into the table
Response.Write('<TR><TH><A HREF="borrow.asp?item=');
Response.Write(rsItems("id").Value + '">');
Response.Write(rsItems("i_name").Value + '</A></TH>');
Response.Write('<TD>' + rsItems("description").Value);
Response.Write('</TD></TR>');
// move to the next row in the database
rsItems.MoveNext();
// go back to the top of the while loop
}
// we have reached EOF, so finish off the table
Response.Write('</TABLE>');
}
}
%>
<P><A HREF="default.htm">HOME</A></P>'
</CENTER>
</body>
</html>

When the user selects an item from the list displayed, Borrow.asp is called and two variables passed to it, item and neighbor. Borrow.asp checks to see that these variables were in fact passed. If so, they are assigned to the appropriate session variables. The script uses these two values to assign a borrowed item to the user by recording that action in the Borrowed table. In addition, the script updates the quantity on hand (qoh) in the Items table to indicate that an item as been borrowed. Once the database tables have been updated, the script redirects the browser to Borrowed_confirm.asp, which displays the list of items currently on loan to the user, as shown in the following figure:

Figure 10.4 Borrowed_confirm.asp 

The code for Borrow.asp is shown in the following listing:

<%@ LANGUAGE="JSCRIPT" TRANSACTION = Required %>
<%
// Server-side include gives us variables we can use for db access
// The include above can be found in the SDK that ships with the Option Pack
// Create a string variable with the contents of the request string
mystring = new String(Request.ServerVariables("QUERY_STRING"));
// check to see whether "item" is part of the request string
foundit=mystring.indexOf("item");
// if it is, then "foundit" will have a value greater than -1
if (foundit > -1)
{
// because we found it, assign the request item to the session variable
Session("item") = Request("item")();
}
// now look for "neighbor" in the request string
foundit=mystring.indexOf("neighbor");
// if it is, then "foundit" will have a value greater than -1
if(foundit > -1)
{
// we found it, so assign Request("neighbor") to the session variable
Session("neighbor") = Request("neighbor")();
}
// if we didn't get a neighbor value, send the user to log on.
if(Session("neighbor") == 0)
{
// redirect the browser to a logon page.
Response.Redirect("logon.asp");
}
else
{
// if we didn't get an item key, redirect the neighbor
// to the list of item types so he can pick one.
if(Session("item") == 0)
{
Response.Redirect("type.asp");
}
else
{
// we know both the neighbor and the item so
// let's put them down as borrowing an item
// create the database object
Conn = Server.CreateObject("ADODB.Connection");
// create the recordset object
RS = Server.CreateObject("ADODB.Recordset");
// open the database
Conn.Open(Session("ASPsample_ConnectionString"));
// open the recordset to add a row to the "borrowed" table
RS.Open("borrowed", Conn, adOpenKeyset, adLockOptimistic);
// tell the database we are going to add a row
RS.Addnew();
// assign values to the columns in the row
RS("neighbor") = Session("neighbor");
RS("item") = Session("item");
// some date logic so we can record the date
// they borrwed the item (borroweddate)
// and the date we would like to have it back (returnby)
CurrDate = new Date();
// the getVarDate method below puts the date into a format
// that can be stuffed into a SQL Server date variable
RS("borroweddate") = CurrDate.getVarDate();
var ReturnDate = new Date();
ReturnDate.setDate(CurrDate.getDate() + 7);
RS("returnby") = ReturnDate.getVarDate();
// assign a null value to the date returned
RS("backdate") = null;
// update the database
RS.Update();
// close our connection to the database
RS.Close();
// Now it's time to update the quantity on hand (qoh)
// Get empty recordset
RS.ActiveConnection = Conn;
RS.Source = "SELECT * FROM items where items.id = " + Session("item");
RS.CursorType = adOpenStatic; // use a cursor other than Forward Only
RS.LockType = adLockOptimistic; // use a locktype permitting insertions
RS.Open();
var return_qoh = 0;
return_qoh = RS("qoh").Value;
return_qoh = return_qoh - 1;
RS("qoh").Value = return_qoh;
RS.Update();
// close our connection to the database
RS.Close();
// point the browser to a page that will confirm that
// he has borrowed an item
Response.Redirect("borrowed_confirm.asp");
}
}
%>

The Dagwood application can also list items borrowed by various neighbors. Users are able to return items and check them out again. When you are comfortable with this example, you should be ready to begin the migration of your LiveWire applications.

Top of page

Migrating from Lotus Domino

This section describes how to migrate Lotus Domino Web sites and applications to IIS. It also describes different strategies for migration depending upon the given scenario.

This section doesn't cover migrating a Lotus Notes e-mail system to Microsoft Exchange Server. Nor does it cover migrating Lotus Notes applications to Microsoft Exchange Server, Microsoft Exchange Client, and Microsoft Outlook. For assistance in these scenarios, please consult the Lotus Notes to Microsoft Exchange Migration blueprint provided by Microsoft Consulting Services.

Migration Overview

The difficulty of migrating a Domino application depends on the complexity of the groupware facilities, application logic, and underlying services provided by the application. Domino is not only a Web server but also an integrated platform for workgroup applications. After migrating, Domino may still be required to provide services such as e-mail to Lotus Notes clients, unless the customer is also considering the migration of non-Web applications. Even in this case, a period of coexistence between Domino and IIS is still likely to be required during the migration.

Typical Migration Scenarios

The following are some scenarios that can prompt an organization to migrate Domino Web applications:

Migration Strategies

A Domino Web site is defined by one or more Lotus Notes databases that store the content and design of the site. Migration is typically done on an application-by-application basis.

Types of Applications

Typically, Domino Web applications fall into one of the following application categories:

You should analyze the business logic of each application and evaluate which components of the application can be reused. You can then redesign and develop the application using an architecture such as the three-tier model.

Elements of a Domino Web Site

Each Domino Web site includes at least one database that contains the following elements:

Domino offers a completely different architecture from that of IIS. Every element of a Domino Web site is contained in a Domino database. Generally a Domino Web site migration involves:

Application migration is the most time-consuming task, and is made more difficult because of the differences between the Domino and IIS application development environments.

Document Migration

Domino documents can be migrated to HTML and Active Server Pages files if their content is static and similar to a Web page. If their content is rich and unstructured, they can be migrated to items in Microsoft Exchange folders. If their content is structured and text oriented, they can be migrated to SQL Server records. Many documents in a Domino Web site hold static content, which can be migrated to HTML and Active Server Pages rather than to Microsoft Exchange Server or Microsoft SQL Server.

HTML Pages

Some Domino documents include include HTML code and Internet components like Java applets, but are still saved to the Lotus Notes database proprietary format rather than as native HTML files.

There are no automation tools that can help the migration of Lotus Notes documents to standard HTML files, so the conversion must be done manually on a document-by-document basis.

Web Site Home Page

The Domino Web site home page is a good starting point for migrating Domino documents to HTML and Active Server pages. This page can be stored in the file system as an HTML file, or it can be stored in the Lotus Notes database as an About document, Notes document or Navigator.

The server document contains the Home URL field that stores the URL used as the site's home page.

HTML

Domino supports most HTML 3.2 tags. Lotus Notes documents are not pure HTML files, and there are several ways to incorporate HTML code into a Notes document. You need to be aware of where the HTML code comes from for every document.

In particular, check for:

Many Domino Web sites are created using a single form for Web pages, in which case the HTML code for every document is likely to be almost the same.

Java Applets

Java applets are supported in Notes applications. A Java applet can be included in a form to include the applet in each document created by the form, or it can be inserted into a document's rich text field to include it only in that document.

Applets usually reside in the file system; they can also reside on a Web server and be linked to it.

Using Microsoft Visual Interdev, Java applets can be added by using the FrontPage editor or by using the <APPLET> tag. The attributes of CODE, WIDTH, and HEIGHT are required.

The following example shows the syntax for setting attributes in the <APPLET> tag:

<APPLET
ALIGN=LEFT|CENTER|RIGHT|TOP|MIDDLE|BOTTOM
CODE=appletFile
CODEBASE=codebaseURL
HEIGHT=pixels
HSPACE=pixels
NAME=appletInstanceName
VSPACE=pixels
WIDTH=pixels>
<PARAM NAME=AttributeName VALUE=value...>
alternate HTML
</APPLET>

Object Store Migration

For documents that are more database-like, you need to decide whether the data contained in the Lotus Notes database should:

One of the main factors that will influence this decision is whether the data will still need to be accessed by Lotus Notes clients and whether the application is linked to other business processes that are not going to be migrated.

The Domino object store is a flexible container whose basic object is the document. A document can contain a wide variety of data types that range from simple text fields to rich text fields containing objects like documents and images. A Domino database often contains documents created by different forms.

The Domino object store is best suited for applications that handle unstructured data, and most Domino applications manage information of this type.

Maintaining Data in Lotus Notes Databases

The most common scenario for maintaining data in a Lotus Notes database is when an organization is building a Web site based on IIS and needs to integrate data contained in one or more Lotus Notes databases. The data is left in the Lotus Notes database so that Lotus Notes clients can access it, and there are no plans to migrate the application itself to Exchange and Outlook. In this case, the orgainization is not planning to migrate the actual application, but needs Web applications based on IIS to access the data contained on Lotus Notes databases.

Note that this configuration is suited only for certain types of applications. It works for applications that only need to retrieve public data or for applications where the identity of the user is not an issue. Security may be compromised because all the information will be stored in the Notes databases with permissions granted to the Notes user installed on the server running IIS.

Maintaining Data Both in Lotus Notes and in MS Exchange Server or MS SQL Server

You may want to choose to maintain data both in Notes and in Exchange or SQL Server when the Web application to be migrated will still need to be accessed by Lotus Notes clients. Synchronization between systems can be maintained for a period of time while the migration is taking place or it could be permanent. You need to decide what kind of database or object store best fits your needs. You can choose a relational database system like SQL Server or a more unstructured object store like Microsoft Exchange Server. The following table can serve as a guide to decide which system to use. Most Lotus Notes databases can be migrated smoothly to Exchange Server. Also, data contained in a Lotus Notes database can be separated—part of it can be migrated to SQL Server, and part of it to Exchange Server.

Table 10.5 Microsoft SQL Server and Microsoft Exchange Server Comparison 

There are several third-party tools that can either help synchronize Notes and other databases, or help to migrate from Notes to other databases.

Migrating Data to MS Exchange Server or MS SQL Server

If the Domino Web application to be migrated will be accessed only by Web browsers, then there is no need to maintain both the Lotus Notes application and a SQL server database or Exchange public folder. As soon as the Web application is migrated, users can point their browsers to the new Web site where the application is hosted. The third-party tools described in the previous section can be used to migrate data from one database to another. These tools are also helpful for migrating Domino applications that are not Web applications.

Not Migrating Data

For some types of applications, such as discussion databases, it isn't necessary to migrate information from the Lotus Notes database to another database engine. It's up to you to decide whether the information contained in the database is worth preserving on the other system.

Application Migration

Migrating applications is the most difficult migration task, partly because of the proprietary Domino scripting environment and the lack of tools to help automate the process of migration. Most of the time, a complete application redesign is needed. Some organizations use this redesign as an opportunity to reengineer their applications and implement architectures such as the three-tier model.

Database Access

Once a decision has been made about which databases or object stores are to be used by the new Web application and the data has been migrated or synchronized, you need to decide which database access method is going to be used by the Web application to access the information.

Visual Interdev provides an easy way to create data-aware Web pages with which you can perform standard database functions such as queries and updates. There are three key technologies that can be used to access databases from Active Server Pages:

ADO is the recommended access method, because it is a newer technology that incorporates the functionality of the other two. For more information on database access techniques, see Chapter 5, "Data Access and Transactions."

These access methods apply to SQL Server, Lotus Notes databases, or any other ODBC-compliant database system. Exchange requires a different access method, using a technology called Collaborative Data Objects (CDO).

Lotus Notes Database

An ODBC driver is available for Lotus Notes (NotesSQL ODBC driver) with which you can open, query, and modify Lotus Notes databases. Any ODBC-compliant application can access a Notes database with this ODBC driver.

An ASP page can use ADO and the NotesSQL ODBC driver to access a Lotus Notes Database.

You must install the Lotus Notes client and the ODBC driver on the server that will be running Active Server Pages for this configuration to work. The Notes ID should not be password protected.

MS SQL Server

Microsoft SQL Server also provides an ODBC driver that enables a Web application to access the databases. The following is an example of code generated by Visual Interdev in the Global.asa file to connect to a SQL Server database named PUBS. The Global.asa file holds event procedures that run when a Web application starts or ends or when a new session starts or ends.

</SCRIPT>
<SCRIPT LANGUAGE=VBScript RUNAT=Server>
Sub Session_OnStart
'==Visual InterDev Generated - DataConnection startspan==
'--Project Data Connection
Session("PUBS_ConnectionString") = "DSN=SQL Server
database;Description=SQL Server PUBS
database;SERVER=myserver;UID=sa;PWD=;APP=Microsoft (R) Developer
Studio;WSID=WORKSTATION;DATABASE=PUBS"
Session("PUBS_ConnectionTimeout") = 15
Session("PUBS_CommandTimeout") = 30
Session("PUBS_RuntimeUserName") = "sa"
Session("PUBS_RuntimePassword") = ""
'==Visual InterDev Generated - DataConnection endspan==
End Sub
</SCRIPT>

MS Exchange Server

You can use Collaborative Data Objects (CDO) to create Web-based business applications that include Exchange Server technologies, such as messaging, scheduling, and groupware. CDO was known formerly as Active Messaging or OLE Messaging. It is designed to simplify the creation of applications that use messaging functionality.

CDO is made available through libraries that expose programmable messaging objects including folders, messages, recipient addresses, attachments, and other messaging components. By understanding the hierarchical structure of the object model, you can easily retrieve data from and add data to Microsoft Exchange Server.

CDO allows you to write server-side messaging applications based on Active Server Pages.

To access the Exchange information store, it's necessary to start a MAPI session. The Session object is at the top of the hierarchy of the CDO Model. The main children of the Session object are the InfoStores and AddressList collections, which contain objects like mailboxes, folders, and messages.

The following is an example of how to initiate a connection to a Microsoft Exchange Server using VBScript. This example creates a new session with the Exchange Server myserver and logs on as user administrator.

Set objOMSession = Server.CreateObject("MAPI.Session")
bstrProfileInfo = "myserver" & chr(10) & "administrator"'
objOMSession.Logon "", "", False, True, 0, True, bstrProfileInfo

The CDO rendering library makes it possible to call CDO objects from Active Server Pages and send the output to Web browsers in HTML format, easing the development of Web applications that access the Exchange information store.

Any Web application that needs to access the Exchange information store must call the CDO libraries from Active Server Pages. The CDO libraries are included on the IIS Resource Kit CD.

Forms and Fields

In Domino, a form is a framework for entering and viewing information in a database. A Domino form can contain:

Not all forms components are available to Web applications. Domino forms are translated to HTML forms by the HTTP server task when Web users access it.

HTML forms package the names and values of each control, and then send them to the location specified by the ACTION attribute. The location can be a CGI application, an ISAPI application, or an ASP page.

In the following example code, the form sends information to the file Events.asp.

<FORM ACTION=events.asp METHOD=POST>

CDO Web Forms

It is also possible to create Web forms by using CDO. With CDO, each page can contain a set of controls that provide nearly all the functionality offered by a form created with the Electronic Forms Designer (a tool for developing electronic forms for Exchange Server).

ASP pages are used to render messages and forms. These pages contain not only the CDO code that handles information received from users, but also the HTML code that interacts with users. This code can include input boxes, option buttons, and list controls that a standard message does not include.

Views

Views are the entry point for data stored in a Domino database. Users open a view to see a list of documents in the database and then open documents from there. Every Domino database must have at least one view.

Microsoft Exchange Server folders can also have views defined. Each view selects the items to be displayed to the user and the fields to be included in each column.

Folder views are stored as hidden messages in the folder and are accessible by anyone having Read access to the folder. All views must have the message class IPM.Microsoft.FolderDesign.NamedView.

The View collection object is used by the CDO rendering library to render a container object such as a public folder.

Navigators

Domino Navigators are roadmaps that direct users to a particular part of an application. Domino converts Navigators to HTML imagemaps. Some Domino documents may contain views and Navigators embedded into them.

Frames can provide the same functionality provided by Navigators. Frames divide the Web page into multiple scrollable areas, with each area defined by its own HTML file.

Programming

Domino offers the following ways to incorporate programming into a Web application:

@functions and @commands

The @functions and @commands are intrinsic to the Domino architecture and application development environment. Any application logic provided by these features must be replaced by Active Server Pages scripting in languages such as VBScript or JavaScript, or by component objects called by an ASP page.

CGI programs

Because CGI programs are not stored in a Lotus Notes database, access permissions are handled by the operating system. Each CGI program used by a Domino Web application must be moved to IIS and tested. It is strongly recommended that CGI programs be migrated to Active Server Pages or ISAPI. Because CGI programs create a new process with every request, they are resource intensive and do not scale well. For information on migrating CGI applications, see "Migrating CGI Applications to IIS," earlier in this chapter.

It's a good idea to create a separate directory to install and configure CGI applications. The directory doesn't need to be named Cgi-bin. If the CGI programs are .exe files, the directory must have Execute permission. If the CGI programs are scripts, then the appropriate script interpreter must be installed.

Domino captures CGI variables by using fields in Notes documents with the same name as the CGI variable or by using the document context property in agent scripts.

Perl Scripts

Domino supports programs written in Perl. Perl programs are normally placed in the Cgi-bin subdirectory under the Domino directory. The environment variable PERLBIN stores the path of the Perl interpreter.

A Perl interpreter is available from ActiveState. For more information, visit http://www.activestate.com/.

Lotus Script

Lotus Script for form actions and buttons is not supported by Domino for Web users. Lotus Script is mainly used in agents for Web applications. Agents are stand-alone programs that perform specific tasks in a Lotus Notes database. Internet Information Server does not support Lotus Script.

Microsoft Exchange Server 5.5 includes a new feature called Microsoft Exchange Scripting Agent. This feature allows server-side scripting for the creation of event-driven agents. The scripts can be written in VBScript or JavaScript. It is also possible to create custom agents that are not programmed using scripting languages, but instead are compiled objects created in Visual Basic, Visual C++, Java, or any other programming language that supports COM (Component Object Model).

Top of page

Resources

Web site information is current as of the date of publication, but is, of course, subject to change.

Tools and Applications

http://www.macromedia.com/ Provides information on Allaire's HomeSite Web application development tool. http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28001860 Microsoft's Universal Data Access Web site. Explains data access strategies. http://www.microsoft.com/business/productivity/processes/selectportal/default.mspx The Microsoft Intranet Solutions Center site. Provides many Web applications that can be customized or used immediately. http://msdn.microsoft.com/library/en-us/mts/mtsportal_1lwl.asp The Microsoft Transaction Server Web site. http://msdn.microsoft.com/vinterdev/ The Microsoft Visual InterDev site.

Component Development

http://www.microsoft.com/com/ The Microsoft Component Object Model site. http://www.microsoft.com/net/ The Windows Distributed interNet Applications Architecture (DNA) site. Provides information on Component Object Model (COM) development and Microsoft's distributed applications development model. http://msdn.microsoft.com/ The Microsoft Developer Network site. Provides many useful resources for component developers.

Scripting Languages

http://www.activestate.com/ ActiveState provides three Perl engines of interest to IIS developers: Perl for Win32, Perl for ISAPI, and PerlScript, an ActiveX scripting engine that allows the use of PerlScript code in an ASP page. http://cgi-lib.berkeley.edu/ Provides information on the Cgi-lib.pl library. http://stein.cshl.org/ Provides information on the Cgi.pm utility. Provides a Perl-based DBI package and documentation, including ideas for porting existing DBI code to the Win32 platform. http://www.python.org/windows/ Provides Python language products. http://sunscript.sun.com/ Provides Tcl scripting language products.

UNIX Migration

http://www.cygnus.com/ Provides GNU development tools for Windows. http://www.mks.com/ Mortice Kern Systems makes the MKS Toolkit, which provides many utilities, such as htdiff, htsplit, url, and web, to help you automate Web development and maintenance tasks. The Toolkit includes a version of Perl, as well as Pscript, an ActiveX scripting engine that allows you to use PerlScript code in an ASP page.

Lotus Domino Migration

http://www.casahl.com/home/home.html Provides information on Casahl Technology's Replic-Action for Microsoft Exchange 5.0, with which you can replicate data between more than 40 databases, including Lotus Notes databases. http://www.mesa.com/ Provides information on the Mesa Group's Lotus Notes and Microsoft Exchange conversion and coexistence tools.

Top of page