Server-Based Applications

Current server-based applications can be broken up into two broad classes: traditional server-based applications (often the server part of traditional client/server applications) and Web-based server applications. While they share many features, they are distinct, especially within the Win32 world. Explicit Win32 API support for traditional server-based applications is limited, although many APIs assist in developing these types of applications. Conversely, the Win32 API explicitly supports Web-based server development with the Internet Server API (ISAPI, covered briefly here and extensively in Chapter 10).

Traditional Server-Based Systems

Traditional server-based systems are best examined by use of example. Microsoft SQL Server is a good example of a traditional server-based application. When SQL Server is used, there is most often a specialized client application that interacts with the server-side program by using one of several possible communications protocols. SQL Server supports named pipes, Windows Sockets, IPX/SPX, Banyan VINES, and Multi protocol communications. The two most popular communications protocols for client/server development, named pipes and Windows Sockets, are covered in Chapter  12. The client communicates a request to the server ( generally in the form of a string of SQL language commands), and the server processes the request and sends back a result set or an error code indicating that the request could not be processed .

Continuing with our SQL Server example, the client program could use either an Open Database Connectivity (ODBC) driver, an OLE DB driver, or the DB-Library API (dbLib) to deliver the request. The details of this communication are of little concern to the server program proper. Requests can come in simultaneously from clients using ODBC and dbLib, through named pipes and Windows Sockets. In any case, the core server application behaves the same way no matter what driver is used, delivering the result set to the client.

SQL Server is designed to use the Win32 API to allow multiple threads of execution to handle requests at the same time. In the case of SQL Server, the number of threads can be configured, as shown in Figure 1-4. A client configuration program allows each client to select any supported communications protocol on a per-client basis.

Figure 1-4 Microsoft SQL Server configuration dialog box, showing the configurable number of worker threads.

The Web-Based Server

In traditional server-based systems, the methods used to communicate between client and server are almost incidental to the server. In fact, if the developer of the system so desires, the communications component can be completely isolated for other operations, allowing the protocol used to be switched dynamically at run time. An example of a protocol-independent API can be found in my book Win32 Client-Server Developer's Guide (Addison-Wesley, 1996).

In Web-based servers, the protocol used is not at all incidental. A number of Internet/intranet-specific protocols are used exclusively for Web-based servers. As TCP/IP becomes the networking protocol of choice, programmers regard the exclusive use of protocols as a strength. The limited protocol choice brings us to another strength of Web-based systems.

In contrast to the huge array of client software available for traditional server-based systems, Web-based systems use a single type of universal client, the Web browser. The exclusive use of the browser as client software does limit some user interface choices. Imagine what the configuration dialog box from Figure 1-4 would look like if the client were a browser; it would be different, perhaps in some ways even inferior, but it would reveal several distinct advantages compared with using a traditional fat client application:

• Simpler installation. No special client-side installation is required.
• Smaller installation. "Universal" client software commonly takes up less space than a single traditional client software installation.
• Accessibility of resources. The use of the configuration utility is not limited by network location in the same way traditional client software might be. Because protocols are used by the browser, resources on the Internet are just as accessible as resources on a local network.
• Familiar user interface. Users are becoming more familiar with the browser user-interface model. Like it or not, this may be the user interface of the twenty-first century (or at least the first few years of the twenty-first century).

Different APIs and system structures can be used exclusively for Web-based systems. The distinction between Web-based and traditional server-based systems is much clearer when discussing Win32 servers. UNIX systems commonly use software that is much more like traditional server-based systems for interactions with Web clients.

One of the problems with using a traditional server-based system for a Web application is the nature of the interactions with Web clients: Web pages are requested by and sent to clients via a connectionless protocol, HTTP. So each transaction (a single page requested and received) is atomic, with a new "session" started when the next page is requested. This model is quite appropriate for most of the activity that takes place on the World Wide Web. The traditional way to create Web-based server applications is to call individual executable or script files when needed (for instance, when a form is filled out on the browser client). This model initiates processes each time a user selects a given control on the screen, with the process living just long enough to execute the user's request.

Unfortunately, creating a process and destroying it after handling a single request is expensive in terms of system resources. Using this model on a Web site that contains only a single infrequently used server-based application might not be a problem. Sites such as www.microsoft.com or more interactive intranet sites are another matter entirely. These sites might receive thousands or even tens of thousands of client requests that require more than the server simply returning a static HTML page.

ISAPI is Microsoft's solution to this problem. Netscape offers a similar API (the Netscape Server API, or NSAPI). The goal of both APIs is to allow existence of a process that can service multiple client requests and not require constant creation and destruction of processes. ISAPI solves the problem by specifying a predefined set of entry points in a DLL. For this method to work, the actual Web server must be told about the DLL (generally through the registry) and must load the DLL once. This single instance of the DLL is responsible for handling the requests of many clients.

An example of what can be done using ISAPI is the ASP.DLL ISAPI program that comes standard with IIS. This DLL handles the conversion of Active Server Pages (ASP) documents. When you request a page with the ASP extension (either explicitly or because an ASP file is the default page), the ASP.DLL is called and the scripting in the ASP file is executed. The result is a standard HTML document that is returned to the browser for display. The browser client knows nothing of all the activity that has gone on to return the HTML document. Active Server Pages will be covered in detail in Chapter 9.