In the still-brief history of the World Wide Web, there have been numerous attempts by software vendors to simplify the methods used to deliver dynamic, interactive content. Few of these forays have become accepted standards or have received much approval from within the Web development community. One method gaining increasing popularity as of late, however, is Microsoft’s Active Server Pages (ASP).

Information consumers are now demanding that the Internet live up to its promise to be a medium for conducting essential business transactions. At the same time, information producers want an efficient way to provide up-to-date information and to collect online user information. To most efficiently conceive and develop such functions, a Web server application framework is critical. ASP is the key development component of a growing realm of Microsoft server-side technologies, technologies intended to help Web developers integrate HTML, data, and transactions into powerful Web applications. This article examines how ASP and ActiveX components are used to develop Web sites employing reusable business programming objects. This article also presents an approach to ASP programming that allows separation between static elements of a Web page and the dynamic, data-driven, functional content.

ASP and the Internet Information Server

The URLs for many Web pages on the Internet these days end with the .asp extension, which implies the content derives from an ASP script. The ASP server-side script interpreter is integrated into the Microsoft Internet Information Server (IIS). IIS is the OEM Web server product for Microsoft Windows NT Server. If you have a recent distribution of NT 4.0 Server installed, you can start serving ASP Web pages right out of the box. Scaled- down versions of IIS with ASP support are also available for Windows 9x and NT Workstation.

IIS 4.0 has come a long way from its humble beginnings. Many published benchmarks have placed its performance for certain tasks at the top of the list of current commercial Web servers. In addition to offering ASP, IIS 4.0 is fully integrated with Microsoft Transaction Server (MTS), a distributed, component-based transaction

processing system. The IIS/MTS duo is a compelling alternative to similarly enabled “application servers.”

ASP is a server-side, dynamic-content-generating solution. Creating dynamic content on the server has a number of benefits over client-driven dynamic content. Server- side dynamic content may be targeted for a well-known, widely accepted Internet content standard: HTML. Client-side dynamic content is often generated using proprietary features of information consumer software (browsers), third-party “plug-ins,” a Java Virtual Machine (JVM), and other inconsistently implemented standards. The goal of server-side dynamic content generation is to produce content that can be rendered on the widest possible range of client browsers.

Most browsers in use today consistently implement the mainstream features of the HTML 3.0 standard. Therefore, developers of server-side content generators can make the assumption that browsers will be able to render standard HTML—something that browser- driven content generation schemes cannot easily do. Of course, there are penalties to pay for server-driven dynamic content. For example, the server will consume more resources generating and delivering dynamic content, as opposed to simply delivering static content. But many high-profile Web sites have been willing to pay these prices for more easily managed content distribution. Additionally, low-profile sites may not require additional server horsepower to provide server-driven dynamic content.

ASP is generally regarded as superior to traditional server-side solutions such as Common Gateway Interface (CGI) in terms of scalability and integration with HTML. Performancewise, ASP scripts run “in process” with the Web server, meaning that no external program activation is required to run the script; in essence, the Web server is also the script interpreter. This dual role preserves the server’s operating system resources, enhancing response time and reducing the overall load.

Developmentwise, ASP scripts can reside in the same file with standard HTML, allowing a configurable coupling of the static and dynamic content in a way that is hard to duplicate with CGI scripts. ASP scripts can be seen as the glue between the development perspectives of the HTML-oriented Webmaster and the business programmer.

What About ActiveX and MTS?

The Component Object Model (COM) is the conceptual link between ASP and MTS. COM, the Microsoft-backed object paradigm for Windows often held in comparison with the JVM, is a binary standard for creating extendible, reusable programming objects. Many of Microsoft’s operating system functions and applications programs have become increasingly component-based over the last few years, leading the charge in what Microsoft sees as an ActiveX revolution. An ActiveX component is a particular kind of COM object (or object set) and is designed to work well in ASP, Visual Basic, and other Windows- based development environments. The scriptwriter may use ASP’s built-in ActiveX COM interfaces for various Web server support tasks. ASP scripts may also access homegrown or third-party ActiveX components (for example, to access an AS/400 database). Most Windows development environments support the use of ActiveX components, and many support their creation. Creating specialized ActiveX components is often necessary because of the limitations of ASP’s script languages. As you will see, this is how your own business objects can access AS/400 data.

To isolate multipurpose business logic in a central location, Microsoft factors MTS into middle-tier ActiveX component development. MTS was designed to manage the runtime behaviors of server-based COM objects. It supports the three-tiered application model by providing transaction-processing features for component-based business logic. MTS offers the ASP developer script transactions and “crash protection.” Crash protection and, more specifically, process isolation allow Web applications to be run in a concurrent but separate process from the Web server; the application can potentially run on a different server altogether. This capability protects the Web server from the program faults of the

application and vice versa. Process isolation can also provide a site administrator with the flexibility to distribute the load of an application over multiple servers. Additionally, an administrator can use MTS to assign certain components to run, for instance, on a particular machine or under a particular user profile.

To get to know the basics of ASP, however, it isn’t really necessary to understand the gory details of MTS. Because of its seamless integration with IIS, it is entirely possible to create useful ASP applications without directly dealing with MTS. By knowing the general mechanics, though, a developer can effectively design scalable, manageable components that can grow along with the user base. Both ASP and MTS administer COM components. The simple difference is that ASP provides a Web-based application framework for using the logic of components, while MTS provides a centrally managed framework for controlling components.

Simple ASP Scripts

ASP applications are composed of one or more scripts and various ActiveX objects. ASP scripts are embedded directly into otherwise normal HTML code. Figure 1 shows the difference between a simple static page and a simple ASP page. The top row shows the static HTML code on the left, the HTML received by the browser in the middle, and an example of how the typical browser will render the HTML code on the right. Notice that, in the first row, there is no difference between the server’s HTML page and the HTML sent to the browser. The second row shows an ASP page in the same stages of delivery. In the left column is the ASP script, which contains special tags used by the ASP interpreter. These tags generate the “pure HTML” content seen in the middle column of the second row. From the browser’s view, an ASP-generated page appears to be a simple HTML page. From the user’s view (in the right column of the second row), the ASP-generated page contains “live” data (the current time).

Examining the ASP script in the left column of the second row of Figure 1, you can see there’s not much difference between it and the static HTML page above it. Two lines of script code have been added, and the

heading has been changed. The first script line, <%@LANGUAGE="VBSCRIPT"%>, tells the ASP interpreter which language the scripts within this file are written in (in this case, VBScript). Scripts may also be authored using JScript, Microsoft’s version of JavaScript. The line added to the section contains a simple one-line script to print the current time. Note that the ASP interpreter processes only the text contained between matching pairs of “<%” and “%>” sequences in the file. Everything else within the file is garden-variety HTML.

Code and HTML: A Line in the Sand

Before looking at ASP pages that use ActiveX objects, take another look at the script in the previous example used to retrieve and output the current time: <%Response.Write Now%>. “Response” is one of the six built-in ASP objects providing access to Web server facilities, application contexts, and HTTP session contexts. “Response” represents an object allowing you to send output to the Web browser in various ways in response to a request for an ASP page. The “Write” identifier refers to one method of the “Response” object. “Write” outputs variable data in the current position of the output stream. In this case, the variable data is the current time returned by the VBScript built-in function “Now.” The effect is that the time is placed “inline” in the HTML sent to the browser, so even in the simplest ASP scripts, COM components have an essential role.

The built-in ASP objects are useful for taking the drudgery out of dealing with HTML templates and the Web communication protocol (HTTP). The ability to use other types of objects is the really interesting part of ASP. The intended role of ASP scripts is as a medium for embedding more complex system and business-oriented objects. Obviously, scripting languages are not the place for high-performance database access code. When complex functionality is placed directly in an ASP page, the result can be complicated and

frightening for Web site maintainers who may understand only HTML. In some cases, it may also present a security hazard.

Placing hard logic into ActiveX components reduces the complexity of ASP scripts and allows the developer to use a more powerful and, hopefully, more familiar language for the actual implementation. The ActiveX developer can choose from any number of conventional or special-purpose language environments to implement ActiveX components, such as Visual Basic or C++. And, with the advent of ASNA’s Visual RPG (AVR) Version 3.0, it is also now possible to create ActiveX components using the RPG language and record-level AS/400 database access.

Developing ASP Applications with AVR

The steps required to implement an ASP application are the same no matter what ActiveX generating tool is used. The HTML designer creates a set of HTML pages, forms, and templates comprising the user interface of the application. The ActiveX developer writes the business logic that dynamically accesses the “online data,” or collects user data entries. The roles of ActiveX developer and HTML designer meet when implementing the ASP script, which will contain the HTML designer's template and some simple script code invoking methods on the developer's business objects. In the previous sections, you've seen how HTML templates can be used to house ActiveX components; now, take a look at how ActiveX components are generated using AVR.

This example Web application consists of an initial HTML form (Figure 2) to allow the user to form a simple query, the response to which is shown in Figure 3. The submission of the form causes an ASP script to call the AVR subroutine, which reads the database file using the query parameters. The information from the retrieved database record is then placed in the Web page (Figure 3).

The machine code for ActiveX components used in ASP scripts is generally contained in a Windows Dynamic Link Library (DLL) file. Setting up the ASNA AVR IDE to generate an ActiveX DLL is a simple matter of clicking the New Project option from the File menu and then clicking on the Project tab and selecting ActiveX DLL as the Project Type (Figure 4). The AVR IDE then creates a project and an “empty” ActiveX component. After renaming the DLL's default ActiveX component, you must tell AVR which external ActiveX components your ActiveX component will use. This example required the ASP and MTS ActiveX libraries that are a standard part of IIS.

Once the setup of this AVR project is complete, all that is left to do is to code a simple ActiveX subroutine to access some AS/400 data and place the data in a Web page with an ASP script. AVR and the ActiveX component framework are both designed around the “event-driven” model, so writing ActiveX components in AVR is very simple. Subroutines defined using the *PUBLIC “scope” keyword in ActiveX DLL projects become ActiveX methods when compiled. Recall that it is ActiveX methods that are invoked from ASP scripts. The code used in this example Web application is given in Figure 5. The ByCustNo subroutine searches for a record in a physical database file and then calls an ASP built-in component to put selected fields of the record in a Web page. Note that ByCustNo is the only public subroutine in the listing; this is the single ActiveX method defined in the class. The “DclFld” statements prior to the subroutine are component variables that are used to reference the ASP built-in objects. In the code, some of these, such as ObjectContext, are used in an odd-looking array syntax. These are simply ActiveX “collections,” which may be thought of as arrays with string subscripts.

With the code complete, you are then able to compile the ActiveX DLL by selecting the Make option from AVR's File menu. This single step compiles the code, creates the ActiveX DLL, and registers the component it contains with the system. The registration step allows the ASP interpreter to find the component among the other COM components installed on the PC.

After implementing the ActiveX component, HTML form, and ASP script, tying it all together is a matter of a few mouse clicks using Microsoft's Internet Service Manager (another tool bundled with IIS and the Windows NT 4.0 Option Pack). With this tool, you create a new “virtual directory” that tells IIS where the HTML and ASP script are. I placed the HTML source for the form shown in Figure 2 and the ASP script shown in Figure 6 (which generates the response page shown in Figure 3) in the same directory on my IIS server machine, C:Webapp. I named my virtual directory SimpleASP and linked it to my real directory, C:Webapp.

A Tour of Duty Just Begun

This article has only scratched the surface of ASP and ActiveX programming. Several other ASP built-in objects help you to create highly sophisticated Web applications. Additionally, MTS may be used to enhance the control and security of Web applications. One approach to ASP application development has been shown whereby areas of technical specialization may be isolated. HTML authors can live comfortably in their domain, and likewise, the business programmer can produce useful functions not tied to a specific Web page layout scheme. Furthermore, with AVR, AS/400 business programmers no longer have to learn a new language to develop powerful Internet applications.

The best place to find out more information about IIS, ASP, and the Microsoft three-tiered Web strategy is the Microsoft Web site at www.microsoft.com/iis and msdn.microsoft.com/workshop/server/. You can find COM, ActiveX, and MTS information resources at www.microsoft.com/com. More information about AVR and other ASP example applications is available from ASNAs Web site at www.asna.com
.

HTML or ASP Script on the Server HTML Delivered to Browser Browser-displayed Page

S
t
a
t
i
c

H
T
M
L

A
S
P

S
c
r
i
p
t





This is a dull,
static page.

<%@LANGUAGE="VBSCRIPT" %>






This is a dull,
but DYNAMIC page.

Current time:
<%Response.Write Now%>





This is a dull,
static page.

This is a dull static page. This is a dull but DYNAMIC page.





This is a dull, but
DYNAMIC page.

Current time: 3/23/99
4:11:12 PM



Current time: 3/23/99 4:11:12 PM

Figure 1: Microsoft’s ASP delivers the dynamic content that e-commerce applications require.

Figure 2: HTML input forms may specify an ASP to handle the HTTP post operations.

Figure 3: ASP delivers dynamic content using standard HTML.

Figure 4: AVR’s Project Settings dialog is used to set the name of the default ActiveX component.

FCMMASTERL1 IF E K DISK
F KDBDESC '*PUBLIC/ASH'

// Always declare "static" MTS variable to get ASP objects

DclFld AppServer Type(MTxAS.AppServer)

DclFld ObjectContext Type(MTxAS.ObjectContext)

DclFld Response Type(AspTypeLibrary.Response)

DclFld Request Type(AspTypeLibrary.Request)

// Beginning of ActiveX method call
C ByCustNo BEGSR P
C MOVE AppServer.GetObjectContext() ObjectContext
C MOVE ObjectContext,"Response" Response
C MOVE ObjectContext,"Request" Request
C MOVE Request.Form,"CustNo" CMCUSTNO
C CMCUSTNO CHAIN RCMMASTL1 99
C *IN99 IFEQ '1'

C EXSR DspRecNF
C RETRN
C ENDIF
C EXSR DspRecord
C ENDSR

// Show detail of record found in the HTML stream
C DspRecord BEGSR

Response.write ( "

Name : " )

Response.write ( CMNAME )

Response.write ( "

City : " )

Response.write ( CMCITY )

Response.write ( "

State : " )

Response.write ( CMSTATE )

Response.write ( "

Tel: " )

Response.write ( CMPHONE )
C ENDSR

// Show record not found error
C DspRecNF BEGSR

Response.write ( "

Customer not found." )
C ENDSR

Figure 5: ASP ActiveX components can be created using a variety of languages, including AVR.

<
%@LANGUAGE=vbscript%
>
Figure 6: ASP scripts remain on the server and use ActiveX components to generate dynamic HTML content.