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
close—UNIX 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-ActiveX–enabled 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 task—to 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 program—the 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.