📄 ch25.htm
字号:
<HTML>
<HEAD>
<TITLE>Chapter 25 -- ISAPI</TITLE>
<META>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#CE2910">
<H1><FONT COLOR=#FF0000>Chapter 25</FONT></H1>
<H1><B><FONT SIZE=5 COLOR=#FF0000>ISAPI</FONT></B>
</H1>
<P>
<HR WIDTH="100%"></P>
<P>
<H3 ALIGN=CENTER><FONT COLOR="#000000"><FONT SIZE=+2>CONTENTS<A NAME="CONTENTS"></A>
</FONT></FONT></H3>
<UL>
<LI><A HREF="#WhatIsISAPIAllAbout" >What Is ISAPI All About?</A>
<LI><A HREF="#ISAPIBackgroundandFunctionality" >ISAPI Background and Functionality</A>
<UL>
<LI><A HREF="#InternetServerApplicationsISAs" >Internet Server Applications (ISAs)</A>
<LI><A HREF="#InternetServerAPIFilter" >Internet Server API Filter</A>
<LI><A HREF="#ImplementationComplications" >Implementation Complications</A>
</UL>
<LI><A HREF="#Summary" >Summary</A>
</UL>
<HR>
<P>
Web servers need the capability to expand their horizons. They
occupy a unique niche in technology, allowing people to view information
you want them to see. As such, each situation is unique, and it
would be near impossible to pick any one set of functions or methods
and say, "This is it. This is how everyone will deal with
information." That would be like making cars in only one
color. People might try to sell you on the idea that generic is
good, but individuality (on either a personal or a corporate level)
needs to find a way to express itself.
<P>
CGI programs are great at what they do-gather information, process
it, and generate output. But they also have disadvantages, such
as needing to create a new instance of themselves every time someone
runs the script. If five people are using the function, there
are five copies of that process in memory. If your site gets thousands
of hits, and most of them are going to be starting CGI processes…
you get the picture. Lots of wasted memory space and processing
time, all to do some simple (or maybe not so simple) functions.
<P>
The Internet Server API (ISAPI) is a different method of dealing
with informational functions. It applies high-level programming
to give you the most efficient combination of power and flexibility,
including information that is almost impossible to get through
CGI. By developing a program in a certain manner, and by meeting
certain requirements, you gain access to this hidden world of
additional power, information, and speed. Be warned, however,
that prog-ramming ISAPI functions is not something to be approached
lightly, or by the faint of programming-heart. It can be a jungle
out there.
<P>
This chapter does not assume much background in the realm of C
or C++ programming. The primary focus here is not the actual writing
of ISAPI code, but understanding the concepts behind it. Among
these concepts are
<UL>
<LI>What ISAPI is all about
<LI>ISAPI's two schools-Applications and Filters
<LI>How does it all work?
<LI>Implementation Complications
<LI>Future directions for ISAPI
</UL>
<P>
With these concepts firmly in hand, and some examples of code
sneaked in here and there, you'll have a place to start planning
your own functions.
<H2><A NAME="WhatIsISAPIAllAbout"><FONT SIZE=5 COLOR=#FF0000>What
Is ISAPI All About?</FONT></A></H2>
<P>
When you're working with a Web server, it is useful to gain more
information and be able to deal with it faster. You want ways
of getting at details that normal CGI can't give you, as well
as ways to modify those bits of information. You want a method
of doing it faster and more efficiently, so that the only lag
time that exists is the user sorting through the cool stuff you
can do for them in an almost instantaneous manner. You want an
API, and you want it now.
<P>
An Application Programming Interface (API) exists so that you
can do fun things with it. You gain access to the inner workings
of the program itself, giving you more freedom and power to do
things with that information. In the case of a Web server, there
are all sorts of hidden things you might want to get hold of,
such as user authorization information, the ability to manipulate
how errors are handled, and how information is logged on the system.
In addition, APIs are faster than normal CGI programs during execution,
and take up less resources while running. This means more power,
more users and fewer problems.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Note</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
In theory, API functions are supposed to be faster, and thus better in general for use. Some people even say that CGI will become obsolete. Later in the chapter we'll cover some of the problems that API functions can present later on in this chapter during
"Implementation Complications," and you'll get a sense of why API programming isn't for everyone, no matter what benefits it may have.</BLOCKQUOTE>
</TD></TR>
</TABLE></CENTER>
<P>
<P>
To take advantage of all this freedom and power, Microsoft and
Process Software teamed up to create an API standard for their
Web servers (and for anyone who wants to adopt it). The aptly-named
Internet Server API (ISAPI) is a whole collection of functions
that allow you to extend the capability of your web server in
a nearly unlimited number of ways. There are actually two very
distinct components present in the ISAPI standard that will be
discussed separately in the next section, "ISAPI Background
and Functionality." I will later discuss ISAPI as a whole
in the "Implementation Complications" section later
in the chapter.
<H2><A NAME="ISAPIBackgroundandFunctionality"><FONT SIZE=5 COLOR=#FF0000>ISAPI
Background and Functionality</FONT></A></H2>
<P>
The ISAPI standard is a very recent, but natural, invention. Microsoft
has long been providing Windows developers with access to Windows'
inner workings through the Windows Software Development Kit (SDK),
while Process software has been providing people with Web servers.
When Microsoft began development of its new Internet Information
Server (IIS), it was expected that they would allow developers
the opportunity to get down and dirty with IIS' functionality:
they didn't disappoint anyone with the release of the ISAPI.
<P>
The two branches of the ISAPI, Internet Server Applications (ISAs)
and ISAPI Filters, comprise two different schools of thought on
how programmers can approach additional functionality. ISAs are
the more traditional of the two, leading programmers to develop
something that's more of an external component with special links
back into the server's workings. ISAPI Filters are closer to building
blocks, which can be attached directly to the server, providing
a seamless component that carefully monitors the HTTP requests
being directed at the server. Since each has its own particular
way of being dealt with by the server, I'll look at them as separate
entities, and tie together the common points where they conveniently
overlap.
<H3><A NAME="InternetServerApplicationsISAs">Internet Server Applications
(ISAs)</A></H3>
<P>
Internet Server Applications (ISAs), which can also be called
ISAPI DLLs, are the first step in extending a server's functionality.
Much like a traditional CGI program, an ISA might find itself
referenced in a form entry like the following:
<BLOCKQUOTE>
<TT><FONT FACE="Courier"><form method=POST action=/scripts/function.dll>
<BR>
</FONT></TT>
</BLOCKQUOTE>
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Note</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
<A HREF="ch8.htm" >See Chapter 8</A>, "Forms and How to Handle Them," for more details on CGI used with form elements.
</BLOCKQUOTE>
</TD></TR>
</TABLE></CENTER>
<P>
<P>
An ISA performs the same task of gathering the POSTed form data,
parsing it out, and doing something with it, but there the similarities
stop. Although the surface elements look exactly the same, what
occurs once the form in question gets submitted (or whatever other
action triggers the ISA to execute) is a completely different
matter. Figure 25.1 shows the typical path of processes in ISAPI
and CGI requests.
<P>
<A HREF="f25-1.gif" ><B>Figure 25.1 : </B><I>Request processes for ISAPI in CGI.</I></A>
<P>
Figure 25.1 shows an example of how communication works between
various entities in the land of the server. Requests are routed
to the main HTTP server. When the server receives instructions
to start a typical CGI program, it needs to make a separate process
for that request. It sends the data out to the CGI program through
the environment variables and Standard Input (STDIN). The CGI
program, in turn, processes that information from the environment
variables and STDIN, then sends output (normally through Standard
Output (STDOUT)) back to the server, which responds to the request.
This action takes place far from home so there's going to be some
delay. In addition, there's some information that the server can't
export past its own boundaries.
<P>
Requests that go to an ISA, on the other hand, stay within the
boundaries of the server's process territory. The data is handled
using Extension Control Blocks (ECBs). There's much less work
involved in getting the data to the ISAs. Also, because it's closer
to home, it also allows for more detailed exchanges of information,
even changes to the server based on that information. There's
a lot more going on than might meet the eye.
<P>
What happens when an ISA function is called? There are a number
of internal steps:
<UL>
<LI>Server receives call
<LI>Server checks function and loads it, if not already in memory
<LI>Function reads data from Extension Control Blocks
<LI>Data gets processed
<LI>Function sends output back to client
<LI>Server terminates function and unloads it, if desired
</UL>
<P>
When the server receives a request to start the ISA, one of the
first things it does is check to see if the ISA is already in
the memory. This is called Run-Time Dynamic Linking. While the
program is running, it hooks up with other components that it
needs and recognizes that it already has them onboard when other
requests come in for those components' functions. These components
are commonly referred to as Dynamic Linked Libraries, or DLLs.
Just as the name might imply, DLLs are libraries of functions
that an application can dynamically link to and use during its
normal execution. Anyone who uses the Windows operating system,
in any version, has encountered DLLs before-Windows is a whole
compilation of mutually cooperative DLL functions. Each function
can call out to another to do whatever needs to be done. When
the server needs to load the DLL, it calls into a special entry
point that defines an ISAPI function, as opposed to some other
DLL that might not be safe to use.
<P>
The primary entry point that the server looks for in an ISA is
the <TT><FONT FACE="Courier">GetExtensionVersion()</FONT></TT>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -