Developing ASP Components
Click to purchase

By Shelley Powers

Chapter 1: Developing ASP Components

Writing ASP Components

When Microsoft first released Active Server Pages (ASP) with the company's web server, Internet Information Server (IIS), the functionality included with this early release amounted to little more than an ability to handle server-side scripting. If you haven't worked with server-side scripting, it is the inclusion of script, such as VBScript or JScript, in web pages so that the script is processed on the server rather than on the client. This early ASP release soon gave way to the ASP we have now, a sophisticated server-side application-building environment that still supports server-side scripting, but also includes integration with other Microsoft server products, such as Microsoft Transaction Server, and also allows ASP pages to access COM objects.

This book is about writing COM objects to work within this specialized ASP environment. Since they are COM-based, you know that whatever functionality you can perform with COM components, you can also perform with ASP components. This means that you can create an instance of an ASP component and use that component instance to do things such as query a database, open a file, or print a file to a printer. However, ASP components are created for a specialized environment, and there are certain things you might consider doing with COM objects that you probably wouldn't consider doing with ASP components. For instance, because an ASP component resides on the server, you aren't going to use any message windows to communicate with the user; all communication is handled through IIS.

In addition, as part of the ASP environment, ASP components have access to built-in objects that contain information not normally available to a "standard" COM object--information such as form field values submitted from an HTML form, the type of browser being used to access the page, or even the language, such as English, preferred by the client.

The information available to an ASP component is also available to ASP scripting blocks, so why use components when you can use scripting? Especially since scripting is fairly simple to use and can be learned relatively quickly?

The first and foremost reason to use ASP components over in-page ASP scripting blocks is reusability. It's difficult to package an ASP script in such a way that it can be used over and over again in many different pages. Additionally, if you or your company is considering packaging some ASP functionality for resale or distribution, the use of ASP scripting becomes insupportable. You probably won't be in business long if people can not only see the source code for your packaged functionality, but can modify it for themselves.

Another reason to use ASP components is that the components themselves can reside virtually anywhere, even on different machines. You can create an ASP application that may update a customer database and that uses one component to update the person's address and another component to update the person's preferences. One or both of these components can reside on the same machine as the web server, but one or both of these components can as easily reside on other machines, with DCOM being used to access the component. While you can distribute web pages containing script on various machines, the maintenance and access issues become much more complicated and usually require hardcoding the physical addresses of the pages within the application. With COM-based functionality, only the operating system COM manager needs to know where the ASP components reside. Moving components is a matter of changing the location of a component once on the client machine; all accesses to the component now occur at its new location.

An additional reason to use ASP components is that they can incorporate the fullest range of functionality on the server, including database access, file access, archiving, messaging, and other functionality difficult or impossible to do with script. You can even transcend object systems and access CORBA-based components with the support of products such as Iona's COM-CORBA Bridge.

NOTE:

Though ASP can be used with a web server such as the Personal Web Server from Microsoft, this chapter and this book focus on ASP as it is implemented within IIS. If behavior differs based on the web server used, I'll try to add a note to that effect.

Now that I've battered you with some of the reasons to use ASP components, let's take a little look at the history of web development, and see where ASP and ASP components enter the picture.

In the sections ahead, this chapter provides a little more of the history leading up to ASP and an overview of the technologies used when writing ASP components.

A Little History

It wasn't long after the first web browser was released for public use that organizations began to consider how they could use the web for applications beyond downloading single, static pages. Application development proceeded in two different directions: on the client with client-side scripting using JavaScript, and on the server with server-side applications. The earliest server-side web applications used a specification called CGI, or Common Gateway Interface, to create applications that would be executed when they were accessed, and which generated web pages to be returned to the viewer.

The earliest forms of web server development used CGI to perform some functions on the server. CGI is relatively simple in operation. A URL contains a reference to an application rather than a web page. With the application request usually comes data, such as the data from an HTML form being submitted by the web page reader. A separate instance of the CGI application is started to process the request, and the output generated by the application is returned as an HTML page to the viewer. CGI applications can perform simple tasks, such as redirecting the browser to another site or to another web page based on certain factors such as browser type. Or CGI applications can be complex, such as processing an order for an online store. Any programming language can be used for building a CGI application, with the Perl scripting language the popular favorite because of its powerful, if cryptic, capabilities.

To quickly demonstrate CGI, Example 1-1 shows a simple Perl script written for a web site using the Apache web server for Unix. In this example, the host actually has two domains pointing to the same IP address. The script checks to see which domain was used by accessing one of the standard HTTP web server environment variables, HTTP_HOST, and redirecting the browser to the page appropriate for the domain. This Perl script is a small, quick, and efficient little application that performs one specific task.

Example 1-1: A Simple CGI Script That Performs Redirection Based on Domain
#!/usr/local/bin/perl

#

# index.cgi

#

# Application will check for the existence of certain

# key terms to determine which browser the web page reader

# is using.

#

# The CGI environment variable HTTP_HOST is accessed

# and certain substrings are matched against it. If

# a match occurs, the browser is redirected to the

# document that matches the browser.

#

# If no match is found, the browser is directed to a text-

# only web page.

#

# Access environment variable

$browser = $ENV{'HTTP_HOST'};

#

# check for Internet Explorer

if (index($browser,"dynamicearth") >= 0) {

print "Location: http://www.yasd.com/dynamicearth/dynaearth.htm\n\n";

} else {

print "Location: http://www.yasd.com/plus.htm\n\n";

}

Even without knowing Perl, it is relatively easy to determine what is happening with this script. After the host variable is accessed and loaded into a local variable, $browser, it is matched against a specific domain request, in this case a domain containing the word "dynamicearth." If found, redirection is used to point the browser location to one page; otherwise, redirection is used to point the reader to another web page.

Though still the most widely used server-side development technology, CGI is not necessarily the most efficient. Its major problem is that a new instance of the CGI application needs to be loaded for each server request. Several people making several requests at the same time impact the performance of both the CGI application request itself as well as the overall performance of the web server.

Returning to Example 1-1, each person who invokes the index.cgi application at the web site must wait for the CGI application to be loaded and run before receiving a response back. While the performance of this approach is acceptable, especially for simple uses such as this, starting up a new server application for every page, form access, or bit of functionality will soon disrupt overall server performance, and can actually lead to server failure or server page request timeouts.

NOTE:

Security issues about CGI arose fairly early on, particularly concerning where CGI applications reside and what operations they allow. Read more on security and CGI at http://hoohoo.ncsa.uiuc.edu/cgi/security.html.

The real key to improving the performance of server-side applications is to provide a technique that loads a server-side application into memory only when the application is not already loaded, and which can allow multiple accesses to the same application from different sources. Among the approaches taken to do this were those that included creating web server extensions that exist as part of the web server itself, rather than as separate applications. With this approach, add-ins to the server could be created using an exposed API, and these add-ins would become integrated with the server rather than existing outside the server. Most web server manufacturers, such as Netscape and Microsoft, soon created proprietary methods for extending their servers.

Microsoft's first web server extension was the Internet Server Applications Programming Interface (ISAPI). ISAPI is quick, in that the ISAPI application runs within the same process as the web server, and communication between the server and the application is very fast. Additionally, once the ISAPI extension application is loaded into memory, it stays in memory, and all client accesses to the extension are made to the same ISAPI process. The only time the ISAPI application is unloaded from memory is if IIS is shut down or regular memory management removes it.

Though fast and efficient, ISAPI does have its limitations. First, it is easy to begin building an extension, but difficult to finish. By this I mean that it is relatively easy to use Visual C++ to start an ISAPI component, since Microsoft has provided a built-in ISAPI wizard to create the framework for the ISAPI DLL. However, building on the framework the wizard provides is not so simple. And ISAPI is limited to C++ programming, leaving the Visual Basic and Java folks out in the cold.

Microsoft was aware of the disadvantages of using ISAPI and fairly quickly provided another approach to creating web-server-based applications: Active Server Pages (ASP). ASP provides for simple and easy server-side scripting that allows web developers to use a combination of HTML, along with JavaScript, VBScript, or any other popular scripting language, to create server applications. A key feature of ASP, though, is that in addition to scripting, it also provides for component-based development by allowing the inclusion of COM-based server components.

About the same time Microsoft rolled out ASP, it also rolled out a combination tool/API service to provide for component and transaction management, the Microsoft Transaction Server (MTS). MTS provides for transaction management for COM-based components, ASP or otherwise. In addition, MTS is an effective component management tool, providing not only component registration services, but also server and client migration. With the release of MTS 2.0 and IIS 4.0, Microsoft also provided for an optional integration of the two servers, with IIS providing the web interface and MTS providing component and transaction management.

The use of ASP and MTS is further enriched with the release of OLE DB, which provides for generic data access regardless of data structure, and which also provides for cross-process transaction management with database engines that support MTS. To assist developers wanting to use OLE DB, Microsoft provided the OLE DB Templates for Visual C++ developers and ActiveX Data Objects (ADO) for all developers.

ASP: What It Is and How It Works>

To Purchase: Click Here>>>>