In the previous chapter, I made reference to the fact that users interact with web applications through a series of carefully crafted form objects exposed to the user in the browser window. The user interacts with the form objects and then typically clicks a button, expecting to see results. What we haven't discussed however, is how those results are returned to the user. In general, servers rely on a piece of software that is crucial in the HTTP request/response process. This piece of software, the web server, is primarily responsible for managing various websites, FTP sites, a mail client, and more on our server. Working in conjunction with the server-side technology, the web server is also responsible for facilitating the handoff between the client's request, the server-side technology used to handle the request, the collection of the response from the server-side technology, and the subsequent handoff of the response back to the client browser. Internet Information Services (IIS) is Microsoft's web server solution and is the primary focus of examples throughout the rest of the book. IIS comes bundled with most Microsoft server-based operating systems, including Windows NT 4, Windows 2000 Pro, 2000 Server and Advanced Server, Window 2003 Server, and Windows XP Pro. NOTE Obviously, IIS isn't the only web server on the market. Because I'm assuming that the majority of readers will be using Windows-based operating systems, it's the one discussed in this book. However, other web servers existsuch as the open source Apache, Sun's iPlanet, IBM's WebSphere, and morethat can run just as well on Mac and Unix environments as they can on Windows machines. In some cases, IIS installs when the OS is installed, but in other cases, you must manually walk through the process of setting it up on your own. More on this later. CAUTION If you have Windows 95, Windows 98, Windows ME, or Windows XP Home, you're limited to using ColdFusion. If you'd like to use ASP, ASP.NET, or PHP, you must first upgrade to one of the operating systems mentioned previously to complete the lessons in the rest of this book. Table 22.1 outlines the major Windows operating systems and shows whether the web server comes preinstalled with the specific operating system.
If you're not sure whether IIS is pre-installed on your computer, you can use one of these three methods to find out:
If IIS is there, you've got the web server installed. If not, follow the steps in the next section. Installing IISOne of the questions in application development is whether or not IIS has to be installed even if you are not hosting your own web applications. The answer is yes. Even if you are uploading your web applications using FTP to your web host provider, installing IIS allows you to view and configure your applications locally before they are ready for production. NOTE As you've seen, Macromedia allows you to define a testing server when you define a site. The site that you define within IIS (covered later) will become the site you define in the testing server category in the Site Definition dialog. For the most part, IIS comes with most versions of server-based Windows operating systems but it's not installed automatically in all versions, which is why it might not be present on your computer. If you've come to the conclusion that IIS isn't installed on your computer and you have a compatible operating system similar to the ones listed Table 22.1, follow these steps to install it:
You can check to see whether IIS installed correctly by performing one or all three check points highlighted in the previous section. You are now ready to begin hosting web applications. Although we won't cover how to configure IIS for external use, I will show you how to configure IIS to support local development of ASP, ASP.NET, ColdFusion, and PHP applications so that you can upload them to your external Web host provider later. Configuring IISAlthough little configuration needs to be done to begin working with IIS, I will use this section to introduce some basic features and functionality within IIS. Reading this section will help you better troubleshoot problems that may arise later in development. This section explains the following topics:
Where to Keep File on the Web ServerNow that you have IIS up and running, let's take a closer look at where the files for your Web applications are kept on the computer. Up to this point, we've been saving our projects in the C:\Dorknozzle\<chapterfolder> directory. This works fine for static web pages because we're merely testing the functionality of the pages in the browser. IIS however, works a bit differently. By default, IIS reads and process the code in the file from the C:\Inetpub\wwwroot\ folder. If you open this folder and compare it to the folder tree in IIS, you'll notice some similarities. Although it is not a requirement to keep applications in this folder, it is generally considered a good repository for storing and managing your server-side applications. NOTE Technically, your files don't have to be in C:\Inetpub\wwwroot\. You can also create what's called a virtual directory. A virtual directory is essentially an alias within IIS that points to a folder somewhere else on your computer. To make things easier, however, we'll work with C:\Inetpub\wwwroot\ for the rest of the book. So that we can test how our web server works, let's create a new folder within C:\Inetpub\wwwroot and add a simple HTML page to the new folder. You can do this on your own by following these steps:
That's it! You've just created your first basic page within the context of the web server. In the next section, we'll browse to the page using the default name of the web server. Using LocalhostNow that you have a new file in C:\Inetpub\wwwroot\Dorknozzle, your web server has access to it. If you've been developing static HTML web pages for a long time, habit may drive you to open files directly in your browser. Dynamic pages can't be opened directly from the browser because your Web server needs to have a crack at the file before it is sent to your browser for display. If the application server doesn't get the chance to interpret the request coded into a dynamic page, the code behind the dynamic page is never converted into HTML that your browser can understand. To repeat: dynamic pages can't be opened directly from the browser. Instead, you'll have to open the browser and navigate to the web directory using the local web address for your computer, also known as http://localhost (or by the IP address http://127.0.0.1). More specifically, because the Dorknozzle folder is located in C:\Inetpub\wwwroot\Dorknozzle on your computer, you can access it directly from the browser by typing in the URL http://localhost/Dorknozzle. Figure 22.1 shows IIS and the browser side by side so that you can visualize the point I'm trying to make. Figure 22.1. http://localhost/Dorknozzle is the URL that points to the folder C:\Inetpub\wwwroot\Dorknozzle.In this case, the process was simple. Because our default page is essentially an HTML file, nothing is really required of the web server. Most of the work in this case is handled by the browser. The browser parses the literal text out of the HTML tags and presents the text Hello World to the user. Because our page contained only HTML, we could've just as easily opened the page directly in the browser, displaying the same results. Remember though, that the Web server (IIS) is the only piece of software that can access your server-side code (such as ASP, ASP.NET, PHP, or ColdFusion) directly. For this reason, it's a good idea that you get into the habit of accessing your dynamic pages directly from http://localhost/<yourfoldername>. This is how it will be done throughout the rest of the book. Stopping and Starting IISWith IIS now up and running, let's now look at how you can start, stop, and restart IIS if the need arises. For the most part, you'll always want to have IIS running except when you're using certain programs locally that open ports allowing intruders to compromise the security of your computer. Some programs, such as peer-to-peer (P2P) file-sharing programs, automatically stop IIS when it launches because of potential security vulnerabilities. Furthermore, server-side technologies such as PHP require modifications within the php.ini file (more on this later in the chapter). When changes are made to this file, IIS must be restarted for the changes to take effect. If you want to stop IIS when it's not being used, follow these steps:
If you want to restart IIS, you can perform the steps just listed or you can make life easier on yourself by entering a simple command in the Run dialog. To do this, follow these steps:
|