Hello, ATL Server: A Modern C++ Web Platform
- The Microsoft Web Platform (Internet Information Services)
- The Simplest ISAPI Extension That Could Possibly Work
- Wrapping ISAPI
- ATL Server
- Web Services in ATL Server
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Throughout the previous 12 chapters, we've focused on ATL as a framework for building both COM components and user interfaces (via ATL's windowing classes and ActiveX control support). Now we look at ATL as a modern platform for building web applications. That framework is a set of classes known collectively as ATL Server.
Although most of the discussion thus far has involved ATL's COM support, ATL Server actually has very little to do with COM. Because its purpose is to handle Hypertext Transfer Protocol (HTTP) requests, the crux of ATL Server is built around Microsoft's Internet Service API (ISAPI). The library just happens to use COM inside. We start by briefly reviewing Microsoft's web platform. Then, we examine how ATL Server leverages that platform to provide a viable means of creating web applications and web services. There's much more to ATL Server than can be covered in this book, so we just hit the high points in this chapter.
The Microsoft Web Platform (Internet Information Services)
When the World Wide Web began taking root in the early 1990s, many sites were little more than collections of Hypertext Markup Language (HTML) files and perhaps some image files. Clients with Internet browsers surfed to various sites using Universal Resource Locators (URLs) that took a form like this: http://www.example.com.
After typing the URL and sending the request through a maze of routers, the request finally ended up at a server somewhere. In the earliest days of the Web, the server was probably a UNIX box. Web technologies soon evolved to handle more elaborate requests (not just file requests). Through the development of the Common Gateway Interface and the inclusion of HTML tags representing standard GUI controls (such as combo boxes, push buttons, and text boxes), the Web became capable of handling interactive traffic. That is, a client could carry on a two-way conversation with web servers that extended beyond simple file requests. Of course, this capability led to the great upsurge in web sites during the late 1990s, giving rise to such enterprises as Amazon.com and Google.
The earliest means of supporting interactive capabilities over the Web were made available through the Common Gateway Interface (CGI). CGI worked by handling separate incoming requests with a new process for each request. Although the Microsoft platform supports the CGI, it doesn't work quite as well as on a UNIX box. Starting new processes on a UNIX box is not as expensive as starting new processes on a Windows box. To compensate, Microsoft introduced the Internet Services API and its own new Internet server: Internet Information Services (IIS). The IIS strategy is that it's much faster to load a DLL to respond to an HTTP request than it is to start a whole new process.
IIS and ISAPI
The IIS component is the heart of Microsoft's web platform. Most modern web sites built around the Microsoft platform involve IIS and ISAPI DLLs. All the modern Microsoft web-based programming frameworks are extensions of the IIS/ISAPI architecture. Even classic ASP and the more modern ASP.NET rely on IIS and ISAPI at their core. And as you'll soon see, ATL Server depends upon IIS and ISAPI as well.
Regardless of the programming framework used (raw sockets programming, ASP, ASP.NET, or ATL Server), processing web requests is similar from framework to framework. A component listens to port 80 for HTTP requests. When a request, comes in, the component parses the request and figures out what to do with it. The request might vary from sending back some specific HTML, to returning a graphics file, or perhaps even to invoking a method of some sort.
When programming to the modern Microsoft web-based frameworks, IIS is the component that listens to port 80. IIS handles some requests directly and delegates others to specific ISAPI extension DLLs to execute the request. By default, IIS handles requests for standard HTML files directly. As an alternative, a custom file extension might be mapped to a handwritten ISAPI DLL that executes the request.
Classic ASP and ASP.NET integrate into IIS as ISAPI DLLs. IIS handles requests ASP files (*.asp) by mapping them to an ISAPI DLL named ASP.DLL, which handles the request by parsing the request string, loading the ASP file, parsing the contents of the file, and servicing the request according to the instructions given in the ASP file. ASP.NET files (*.aspx) are handled by an ISAPI DLL named ASPNET_ISAPI.DLL, which brings in the Common Language Runtime to help it process requests.
To set the stage for understanding ATL Server, let's take a look at how ISAPI extension DLLs work.
ISAPI Extension DLLs
Although IIS does a perfectly fine job responding to requests for standard web file types (such as HTML and JPG), its real power lies in the capability to extend your server by writing custom DLLs to respond to requests.
The core ISAPI infrastructure is actually fairly simple. ISAPI extension DLLs implement three entry points:
BOOL WINAPI GetExtensionVersion(HSE_VERSION_INFO* pVer);
DWORD WINAPI HttpExtensionProc(LPEXTENSION_CONTROL_BLOCK lpECB);
BOOL WINAPI TerminateExtension(DWORD dwFlags);
These three methods are the hooks for writing your web site using custom DLLs. GetExtensionVersion is called when IIS invokes the application for the first time. GetExtensionVersion must set the version number in the HSE_VERSION_INFO structure passed in and then return TRUE for IIS to be capable of using your ISAPI DLL.
IIS calls the TerminateExtension entry point when IIS is ready to unload the DLL from its process. If you don't need to do any cleanup, the TerminateExtension entry point is optional.
The heart of the extension is the HttpExtensionProc function. Notice that HttpExtensionProc takes a single parameter: an EXTENSION_CONTROL_BLOCK structure. The structure includes everything you'd ever want to know about a request, including the kind of request made, the content of the request, the type of content, a method for getting the server variables (for example, information about the connection), a method for writing output to the client, and a method for reading data from the body of the HTTP request. Here's the EXTENSION_CONTROL_BLOCK:
typedef struct _EXTENSION_CONTROL_BLOCK {
DWORD cbSize; // size of this struct.
DWORD dwVersion; // version info of this spec
HCONN ConnID; // Context number not to be modified!
DWORD dwHttpStatusCode; // HTTP Status code
CHAR lpszLogData[HSE_LOG_BUFFER_LEN]; // null terminated log
// info specific to this Extension DLL
LPSTR lpszMethod; // REQUEST_METHOD
LPSTR lpszQueryString; // QUERY_STRING
LPSTR lpszPathInfo; // PATH_INFO
LPSTR lpszPathTranslated; // PATH_TRANSLATED
DWORD cbTotalBytes; // Total bytes indicated from client
DWORD cbAvailable; // Available number of bytes
LPBYTE lpbData; // pointer to cbAvailable bytes
LPSTR lpszContentType; // Content type of client data
BOOL (WINAPI * GetServerVariable)(
HCONN hConn, LPSTR lpszVariableName,
LPVOID lpvBuffer, LPDWORD lpdwSize);
BOOL (WINAPI * WriteClient)(HCONN ConnID, LPVOID Buffer,
LPDWORD lpdwBytes, DWORD dwReserved);
BOOL (WINAPI * ReadClient)(HCONN ConnID, LPVOID lpvBuffer,
LPDWORD lpdwSize);
BOOL (WINAPI * ServerSupportFunction)(HCONN hConn,
DWORD dwHSERequest, LPVOID lpvBuffer, LPDWORD lpdwSize,
LPDWORD lpdwDataType);
} EXTENSION_CONTROL_BLOCK, *LPEXTENSION_CONTROL_BLOCK;
When IIS receives a request, it packages the information into the EXTENSION_CONTROL_BLOCK and passes a pointer to the structure into the ISAPI DLL via the HttpExtensionProc entry point. The ISAPI extension's job is to parse the incoming request into a useable form. After that, it's completely up to the ISAPI DLL to do whatever it wants to with the request. For example, if the client makes some sort of request using query parameters (perhaps a product lookup), the ISAPI DLL might use those parameters to create a database query. The ISAPI DLL passes any results back to the client using the pointer to the WriteClient method passed in through the extension block.
If you've had any experience working with frameworks such as classic ASP or ASP.NET, most of this structure will appear familiar to you. For example, when you call Write through ASP's intrinsic Response object, execution eventually ends up passing through the method pointed to by WriteClient.