Web services have been touted as a really "big thing" in the software industry the last couple of years, and for good reason: they promise technical interoperability between platforms from different vendors, an hitherto unheard-of thing in an industry plagued by proprietary non-compatible solutions.

Packaging Web services seems so straightforward until the phone begins to ring. Here is the usual scenario: you proceed through the development process, copying new versions and files to the development servers. Once everything is tested, debugged, and ready to deploy, you hand it over to the production server administrators. They deploy the new service, and almost immediately your phone rings. It doesn't work.

You spend the rest of your day (or week) running between your desk and the server tweaking and testing until you finally get things running successfully.

What happened? Everything was working perfectly on the development servers. How did months of development and testing lead to a point where everything failed in production? It could be differences in configuration between the development and production servers, but those situations can be easily corrected by keeping the two servers in sync. The fundamental problem behind this common situation isn't technical at all, it's a communications problem.

In the development environment, most developers administer their own servers. But in production, those servers are managed by the server administrators. Moving a new application or service from development to production requires successful communications of the configuration, database, and security steps necessary for a functioning application. It is in the communications process that the errors occur. Some steps are not properly documented, and some are missed by the administrator. The problem is big enough with one server. Deploy to a server farm and the problem compounds.

In this article, I will examine the essential configuration steps and how to address them with existing deployment tools, and look at some new tools that eliminate the communication errors and improve deployment reliability for one server or an entire server farm. (Note: the concepts in this article can pertain to any server platform, but the procedures and tools discussed apply only to Microsoft Windows-based servers.)

Configuring the Server
For most Web applications and services, there are three major areas that must be configured: a virtual directory, user account security, and databases.

Virtual Directory
A virtual directory is a directory on a Web server that can contain the application code or act as a pointer to the directory containing the code for the Web service. The virtual directory tells the Web server that the code in the directory is executable, how to manage resources for the application, and whether anonymous access to the code is permissible, or if the user must be authenticated first. For Microsoft Internet Information Server (IIS) the relevant portions are executable permissions, application protection, and directory security. The actual settings depend on the requirements of your application, but they must be configured for your application to operate at all.

Program Security
Managing overall server security is the subject of entire books and well beyond the scope of this article. Server security is also properly the role of the server administrator. Web services developers preparing to deploy applications must be concerned with vulnerabilities that do not threaten the entire server if a hacker finds a weakness in their application code. The easiest way to ensure this is by running the code not as administrator or system, but as a user with very limited privileges. If the application is breached, the hacker has no access to the server itself. Configuring the application to run as a limited user can be handled in two ways. If the application is running as a service, you set the username and password in the services control panel under Windows 2000 Server. If it is running as an application, you control access to it by setting the account to that which operates as anonymous access. With this setting, anyone accessing your service is doing so as that limited user. This setting is controlled in the IIS Directory Security tab.

Database Setup and Configuration
Any nontrivial Web service will likely have a database operating as the back-end storage and retrieval system. Deploying a new service will require setting up a new database or changing an existing one. To do this, the administrator must connect to a database server like Microsoft SQL Server and execute a series of SQL statements against it to configure the database. Database configuration is one of the most error-prone parts of this process since many services can have multiple SQL scripts to execute in a specific order. Miss a script, or get them out of order, and you're in for a lot of troubleshooting.

Deployment Options
There are three common deployment methods for Web applications. The most common one is what I call "copy and configure." The second approach is to use the free Setup and Deployment Projects that are included with Microsoft Visual Studio .NET, which allows the developer to automate some of the configuration steps. The third approach is to use a third-party installation tool, such as Wise for Windows Installer, which allows developers to manage all configuration options automatically.

Copy and Configure
Copy and configure is the most common and most error-prone method of deploying Web applications and Web services. With copy and configure, the developer provides the administrator with a set of files, SQL scripts, and instructions. The administrator then copies the files to the right location on the Web server and uses the instructions to set up the server properly. Looking at a list of requirements the administrator must perform in this process makes it easy to see why it is so error prone.

The administrator begins by using the IIS control panel to set up the virtual directory, and set execute permissions and application protection levels. If the application is going to manage security by managing anonymous access, the administrator sets this on the Directory Security tab in IIS. He then copies the files into the appropriate directory of the server. If the application will run as a system process, the administrator must enter the services control panel and set the username and password for the account the main executable will use. The next step is to connect to Microsoft SQL Server and execute the SQL scripts in the proper order. Finally, he will often have to restart the IIS service, or even reboot the machine.

Using copy and configure requires the developer to accurately and completely document every configuration step, and the administrator to accurately follow every step. If the application is being deployed to a server farm, this process must be repeated on every server. With all of these manual steps, it is very easy to see how copy and configure is the most error prone of the three deployment methods. Any step the developer can take to automate these tasks significantly increases the reliability.

Setup and Deployment Projects
The setup and deployment projects in Microsoft Visual Studio .NET and third-party tools use Microsoft Windows Installer technology to manage many deployment processes.

Windows Installer is a relatively new installation technology that made its debut with the release of Microsoft Office 2000. There are two portions to a Windows Installer installation: the package (called an MSI package) and the Windows Installer service (msiexec.exe). The Windows Installer service became a standard part of the operating system beginning with Windows 2000 and Windows ME. The MSI package contains all of the program resources and the instructions for installing them. Unlike traditional install scripts, the MSI package is a relational database with resources and installation actions contained in database tables. Standard actions consist of the common installation tasks: checking for available space, updating the registry, and copying files for example. Custom actions are developer-defined tasks that can manage custom events such as downloading information from the Web, configuring a database, or checking the version number of critical files. Windows Installer allows the use of special variables, called properties, to enable the developer to make use of information gathered from the machine or the installing user. For example, the MSI package can be set up to use a property for the server name. The user can be prompted during installation to enter the server name, that value is stored in the property, and the MSI uses that value to set the server name in the application.

For setup and deployment projects, most Windows Installer tools insulate developers from the actual database tables by providing an easier way to enter the information. The setup and deployment projects use a series of editors for adding files, registry keys, file associations, launch conditions, dialogs, and custom actions.

To deploy a Web application, use the Web Setup Project. This project enables the developer to create and configure a virtual directory during the installation. This allows the developer to automate the first of the three tasks necessary for a successful deployment. Configuring the database can be done by writing a custom DLL that executes the SQL scripts and then calling that DLL with the Custom Actions editor. This leaves the administrator with only the task of configuring the security settings. Automating the two most complex processes can eliminate the majority of deployment errors. The biggest drawbacks for developers using the setup and deployment projects are that they are not particularly easy to use, and they require the developer to write custom DLLs for many tasks.

Third Party Approach
Third-party tools make it easy for developers to automate every aspect of Web services deployment and significantly improve reliability. While assessing these tools, it is important to ensure that the tool provides a simple GUI editor that allows developers to easily create virtual directories, manage security, configure SQL server databases, and customize every machine in a server farm environment.

Microsoft has recently announced it will release a new deployment technology called ClickOnce, which will simplify deployment by allowing developers to specify all the requirements in an XML manifest file. This will be available in the next major release of Windows, codename Longhorn, expected to be released in late 2005 or early 2006. For more information go to: Click Here!.

About the Author
Bob Crosley is a technical product manager for Wise Solutions, Inc. He approaches the challenges of improving Web services deployment reliability with a 10-year background as a project manager, support specialist, software developer, program manager, and software product manager. This broad base of experience lets him see software from the perspective of those who design it, write it, and support it. For the past year Bob has been working with companies designing and deploying Web applications and Web services, focusing on improving the deployment of these new services. Robert.Crosley@wise.com