by Warren Ernst
Isn't it strange that the most popular computer platform for Web browsers is not the most popular computer platform for
Web servers? In fact, it isn't even closeUNIX and the Macintosh operating systems outnumber Windows-based Web servers by something like 5 to 1, even though there could be eight times as many Windows-based Web browsers than both Mac and UNIX
versions combined at any given time. To be sure, UNIX computers are what the Internet was based on, but now that practically any computer type can be hooked up permanently to the Internet to act as a Web server, you'd think there would be a lot more
Windows-based Web servers than there are today.
Given the right tools, there should be, since there are more Windows programmers than ever right now, and it only makes sense that informational files made on one computer platform be served by the same platform. Well, it might not make too much
sense now, since the majority of the files you get from Web pages are platform-independent HTML and GIF files. But with more and more Windows-based desktop programs generating new file formats, and with users simply wanting information created with desktop
applications in their native formats, it's beginning to make sense to just leave them where they are and let a Windows-based Web server serve them.
This is the philosophy behind ActiveX-based Internet Information Servers using ActiveX technology and ISAPI filters. ISAPI, which stands for Internet Server Application Programming Interface, is a
new way to add functionality to Web servers in separate modules. ISAPI can be thought of as the successor to CGI (the Common Gateway Interface), as a means for outside programs on the serving computer
to communicate with Web servers to affect input and output; ISAPI filters can be thought of as the equivalent to CGI scripts. With an ActiveX Web server, however, you can use both, depending on what you're comfortable with and what you hope to accomplish.
This chapter explains why using Windows ActiveX-based Web servers has advantages over other platforms and servers, how ISAPI filters are different from CGI scripts, what are the general guidelines for writing ISAPI filters, and how existing desktop applications can be used to serve Web pages.
It's hard to imagine a new Internet technology making life easier for the Webmaster and the Web surfer, but that is Microsoft's goal in designing the ISAPI for Windows-based Web servers. With ISAPI, Webmasters and surfers will find increased computing
power and simplicity when getting "wired up."
The increased potential and power of an ActiveX Web server comes from a couple of trends. First, the Web is being used more and more by business people to transmit business information, in addition
to the traditional "computer hobbyist;" Since most business information is created with desktop computer applications, like Microsoft Word, PowerPoint, and Excel with Windows-based PCs, Webmasters are beginning to ask "Why are we always
converting this stuff?"
Of course, this is a rhetorical question, because most Web servers are set up to deal only with sending out HTML files, and most browsers are capable of only displaying HTML files. But ActiveX controls and documents are changing the types of files a
Web browser can use, and viewing a PowerPoint presentation, Word document, or Excel spreadsheet is starting to be something an ActiveX-enabled browser can do.
But even for non-ActiveXenabled browsers that can read these files, a person (such as the Webmaster) manually converting existing business documents introduces the
possibility that files might not get updated properly; the resulting files for online users won't be the same as the files that local users see, which defeats the purpose of having them online anyway. The fact is that most Microsoft business applications
can export their native files into HTML files themselves and are OLE-enabled just as ActiveX components are. As such, an ActiveX-enabled server could then call on one of these business applications to convert a requested file into HTML on-the-fly, then
send it out as an online user requests it, guaranteeing that any HTML file derived from a business application file is always synchronized.
On top of the obvious benefits of having a Web server communicating with business applications that produce the information Web surfers want, there are many side benefits.
First, most Windows-based Web servers are far easier to install and configure than most UNIX servers. Most Windows servers use simple installation programs and dialog boxes that you can point and click your way through, but most UNIX servers still use the
UNIX command line to set things up. Of course, if that's all you're used to, this isn't a great concern, but as more and more people become Webmasters who have never used a UNIX box, this becomes a consideration. Additionally, if you're like most
Webmasters writing HTML files from scratch, chances are you use a Windows-based PC to write them. With a Windows-based server, there's no need to transfer files from computer to computer, because you can write them on the very same computer that serves
them.
On top of this, the Windows 95 and NT operating systems run on computers that cost far less to buy and operate than most UNIX boxes and Macintoshes, so there's less initial investment selecting a Windows-based Web server with ActiveX Technology.
ActiveX-enabled Web servers also benefit from existing technologies based on Microsoft's wide range of products and the OLE standard. Microsoft
already has a very advanced, high-performance SQL server product, so it's only logical that the SQL services offered by the Internet Information Server are built on the expertise Microsoft gained while developing their standalone SQL server.
This ability to leverage a wide range of existing, stable technologies is a crucial piece of the Microsoft Web server puzzle. The bottom line is that the Internet Information Server can't entirely be judged on its own accord because tangential
technologies can add significant value to it. This advantage is unique to Microsoft and has long been their hold card in grabbing wide support for new products and technologies. I wouldn't expect the Internet server market to be much different in this regard.
Up to this point, I've been discussing conventional server technology, such as CGI scripts, and ActiveX technology, such as ISAPI, as if they
were mutually exclusive, and that's not the case. Nor is it the case that ISAPI works only with a particular Windows-based Web server written by Microsoft. In fact, ISAPI is a fairly generic method to increase the functionality of Web servers and
will happily coexist with traditional CGI scripts. This section compares and contrasts the fundamentals of CGI and ISAPI environments and highlights the differences in the way CGI scripts and ISAPI filters work.
The Common Gateway Interface (CGI) and the Internet Server Application Programming Interface (ISAPI) both perform the same taskto extend
the capabilities of a Web server. They just provide a different framework for the actual computing module to do the job.
CGI programs (normally called scripts) run in an environment created especially by a Web server programthe server creates special information for the CGI program in the form of environmental
variables and expects special responses back from the CGI program upon its execution. The point here is that the programs, which can be written in any language and communicate with the server only through more variables, only execute once the Web server
interprets the request from the browser client program, then returns the results back to the server. In other words, the CGI program exists only to take information from the server and return it back to the server. It's up to the Web server program to send
that information back to the browser client.
The ISAPI specification is not nearly so limited in its ability to communicate. The ISAPI program (normally called a filter) can interact with information coming directly from the browsing client before the server has even "seen" it or can
take information coming from the server to the client, intercept it, alter it in some way, then redirect it back to the client browser. It can also perform actions at the request of a server, just as CGI can.
It might not seem like an important distinction between the two, but it allows Web servers to serve out very different information, for example. Currently, Web servers send conventional HTTP response headers to browsing clients, but with ISAPI, the
programs created to help the server could do it themselves, leaving the server to process other requests, or could modify the response headers to support a different kind of information.
Additionally, ISAPI programs are loaded in the same address space of the Web server. Contrast this with CGI, which creates a separate process on the server for every individual request. The end result is that the ISAPI approach gives you a higher level
of performance than CGI and consumes far less RAM.
I've always been a little uncomfortable with the CGI "script" moniker for the bona fide programs that operate in the CGI environment,
but perhaps the term "script" has stuck because it's relatively easy to write short programs that perform small, repetitive tasks for Web servers. At any rate, CGI scripts can be written in almost any language, as long as that language supports the reading and writing of an operating system's environment variables. This means that, for a UNIX box, scripts can easily be written in Perl, C, Forth, or almost any of
the major languages. For a Windows-based PC, you could use DOS batch files, Visual Basic, Visual C++, Delphi, or even NT Perl (with some limitations).
The scope of the computational task will probably dictate what language is selected (I wouldn't want to perform complex calculations in Perl), but when all the computing is done, the results would have to be sent back to the server through more
variables, and the server would have to construct the response and send it on its way.
ISAPI filters are normally written with Visual C++, both because filters are stored and executed as Dynamic Link Libraries (DLLs) and are fluent in OLE. A filter can take
its cues directly from the stream of information heading into or out of the Web server, decide whether it's programmed to act on it, and then perform the action. It can also tell the server to do some processing of the information stream, then pass it
along by using OLE or other means. "When something like this happens, let me handle it," the filter tells the server, and the server lets the filter handle it.
As it starts performing its task, the filter can make OLE calls to other business applications installed on the system or make use of existing ActiveX controls, when required. It can then send the information back to the
server for further processing and even filter it further before it finally goes out. (Or better still, let another filter handle the post-processing, and keep the tasks separate.) The qualities that differentiate ISAPI filters from CGI scripts allow you to
do the following:
Chapter 12 discusses the nitty-gritty details of writing ISAPI filters on a technical level, but this section describes the requirements and processes from a slightly less technical point of view.
Even more details are available on the ActiveX SDK CD-ROM available from Microsoft, along with sample filters.
Filters are generally custom-made for whatever application you have, unlike the plethora of ready-made ActiveX controls that are available. This is because, unlike the huge market for browser-side computing modules, the market for server-side computing
modules is really very small, and filters are usually required to perform a very specialized task. As such, filters are probably the first ActiveX modules you will write.
ISAPI filters are generally created with Microsoft's Visual C++ and compiled into dynamic linked libraries. These DLLs export two functions to the ISAPI-compatible Web server: GetFilterVersion() and
HttpFilterProc(), though for the purposes of discussion, the names aren't terribly important. The first function essentially registers the filter
with the Web server when the server starts up. It first supplies version information to the server, next sets the filter's priority, then registers events that would activate the filter. The second function is actually called by the server and is used to
send the filter the type of event occurring in the connection and the data associated with the event.
Once this information is passed between the filter and server, the filter can start doing its preprogrammed task and generate output.
In this chapter, which concludes Part II, you've seen how ActiveX technology is available to a new generation of Windows-based Web servers and what it can accomplish. Part III, "Developing ActiveX Controls," contains chapters that deal with
the more technical aspects of creating ActiveX controls yourself. Chapter 12, "Controlling the Internet Information Server Through ActiveX ISAPI Filters," builds extensively on the material found in this chapter.