Table of Contents
- Contents
- Preface
- Acknowledgments
- Part I: Server Basics
- Part II: Windows 2000 as a Server Platform
- Part III: Building Windows 2000 Server Applications
- Appendix A: Setting Up Virtual Directories in IIS
- Appendix B: Reacting to Service Failures
- Bibliography
- Index
Read an Excerpt
Chapter 1: Server-Based Development
Michael J. Fox appears in a movie called The Secret of My Success, in which he has just arrived in New York City from Kansas. He calls home from a phone booth and assures his mother things are fine. He tells her that it is "just like Kansas." Gunfire erupts, causing him to duck for a second, and then he continues, "Yes, it is just like Kansas, only intensified." Server-based development reminds me of that quote-it is just like regular programming, only intensified.
What Is A Server?
Before we proceed much further, some definitions are in order. Defining exactly what constitutes a server is a lot like defining what beauty is-you know it when you see it. Most programmers know what a server program is when they see it, but coming up with a definition is a little tough. Most server systems exist on a local area network (LAN) or wide area network (WAN) and communicate with clients on the same network, but not always. Even the operating system in use is no longer the marker for what a server program is. Microsoft Windows 2000 is the first generally available system in which the client operating system and the server operating system are the same (ignoring for a moment the difference between Windows 2000 Professional and Windows 2000 Server-more on that later).
Network attachment is also not a requirement for a server program. Most server programs are constructed to interact with the network environment or client workstations, but this interaction is not a requirement. As I just mentioned, Windows 2000 is constructed in a client/server fashion, with the client and the server contained in the same machine. Take a look at Figure 1-1,which shows the Windows 2000 Services applet. Looking down the list of services, we see some that are clearly network related (DHCP Client and FTP Publishing Service) as well as some that are clearly not (Event Log). Speaking of Event Log, the local machine uses this service to record informational messages, warnings, and errors. OK, the Event Log service creates a log that can also be read from another machine on the network, but that functionality is not an essential part of the service, and the service functions just fine on stand-alone machines. (How Microsoft Windows NT came to be constructed in such a way is a subject for an entirely different book-see the descriptions of ShowStopper and Inside Windows Alf, Second Edition, in the annotated bibliographybut it is important to realize that the client and the server need not be on different computers.)
Since we cannot rely on these criteria to define a server program-what operating system is in use, whether there is communication between a client and a server, or even whether the program is running on a network-we need another criterion. My criterion is this: a server program is a program in which the user interface (UI) does not exist or is separate from or incidental to the function of the program.
Let's consider two server programs and see how they fit this criterion. The first example is a networked MS-DOS program that monitors a virtual drive on an AS/400 midrange computer, copies and processes the files on a LAN drive, and then waits for the next file to appear. The only real user interface is a text-based display that tells the operator what the system is doing. This user interface is incidental to the main task of the server program-since there are no user options-and the messages exist solely for the operator to know whether the system is running.
The second example of a server program is Microsoft SQL Server. If you could scroll further down the list shown in Figure 1-1, you would see two entries in the services list related to SQL Server: MSSQLServer, which is the actual server program that manages the database operations, and SQLExecutive, which is a program that handles timed operations on the SQL Server database. Figure 1-2 shows the opening screen of the program that starts when you run SQL Enterprise Manager.
This program functions as a user interface for the MSSQLServer and SQLExecutive services. Many of the operations you can perform with SQL Enterprise Manager can also be performed (albeit with greater difficulty) with command-line tools that provide essentially no user interface. Thus, SQL Server meets our test of being a server program.
The Growth Of Server-Based Development
Several factors have come together to make this the ideal time to study and understand the nuances of server-based development. Perhaps the most important factor is the emergence of Windows 2000 as the server of choice within many organizations. Windows 2000 provides many features that previous server operating systems did not.
Windows 2000 allows developers to write server-based systems by using the tools that they are already familiar with, such as Microsoft Visual C++, Borland C++, Microsoft Visual Basic, and Borland's Delphi. I will argue that in many cases, the tools based on Visual C++ are the most appropriate for production server systems, but for many applications Visual Basic will suffice. Visual Basic programmers out there are legion, and their work will lead to an onslaught of Visual Basic 'Server solutions in addition to the C and C++ solutions already becoming available.
NetWare
Novell NetWare was previously the server of choice and is still a strong force in the network operating arena. At its inception, NetWare did exactly what was needed: file and print sharing with what now seems like minimal hardware. NetWare networks frequently supported dozens of users for file and print services using Intel 486-based servers with 32 MB of RAM. However, writing a NetWare Loadable Module (NLM) was a daunting process, and NetWare never emerged as an application server for the masses.
Why was it difficult to write an NLM? Consider the environment. NLMs generally run in ring 0 of the CPU, a ring that provides no memory protection. In the early days of NetWare, running code in ring 0 was a feature rather than a bug because the Intel 80286 and 80386 processors were the most powerful microprocessors available for servers, and code executed faster when running in ring 0. As CPU speed increased, running NLMs in ring 0 became less of a benefit. NetWare 4 and later versions could run NLMs in either ring 0 or ring 3, which was slower but safer. Code running in ring 3 is less likely to bring down the entire server but can still bring down an individual application by performing tasks that in other operating systems might simply cause a resource leak.
The second problem with NetWare as an application server was the limited selection of tools available for NLM development. For a long time, only the Watcom. C/C++ compiler was able to create NLMs. The Watcom C/C++ is a perfectly capable compiler, but it is not the preferred compiler for the majority of developers. Other compilers can be used for NLM development, but they still require use of the Watcom linker, making the use of any other compiler more complex. The importance of limited tool selection cannot be understated. Programmers often have near-religious attachment to their compilers and need compelling reasons to switch.
Cracks in the Fat Client Model
The most common client/server model before the Internet explosion was the "fat client" model, in which most of the processing took place on the client computer, with only the database and some modest amount of business logic on the server. The client took care of not just the presentation of information but also decisions about what information was shown-as well as when and how information would be saved. The popular tools used for client/server development included PowerSoft, PowerBuilder, and Visual Basic. These tools left significant portions of a system's logic on the client computer.
The fat client model seemed more entrenched than ever, with ever more powerful client workstations absorbing the increasing amount of code that allowed client/server systems to function...
loading...