Creating and Consuming Web Services, Part IV

We studied the underlying technology of Web Services, and provided advice on developing and finding Web Services in prior segments. Now it's time to actually deploy our Web Service. In fact, the end goal of any application development project is deployment. We'll discuss here how to deploy a Web Service application either to a test server or to a production server. First, let's make an important note about deploying Web Services. Unlike a Web site, you can't just change your Web Service when you feel like it. If there are others consuming your Web Service, you must make sure you keep the interfaces to the Web Service the same. That is, you can change your implementation without anyone knowing, but changing a Web Service interface such as adding, deleting, or modifying the parameters of a WebMethod will break consuming applications. As Mike Amundsen of Eraserver.net says, "Once you publish, you're committed." So make sure you have an upgrade and migration approach in mind before you put your Web Service out there for all to consume. For example, you might choose to maintain multiple versions of your Web Services for backward compatibility.

Anyone who has deployed Web or client-server applications knows that deployment is always problematic. You take a perfectly good application that runs oh so nicely in the development environment and move it over to a test or production environment and seemingly, everything breaks. The issues are endless--different hardware, configuration issues such as new host addresses and directory pointers, database migrations, new networking equipment to deal with, firewall and proxy issues, and more. The worst part is that no two deployment scenarios are the same.

In this section, we'll discuss those issues that arise when you want to deploy an application to a test or production server. We won't cover all of the issues that arise when deploying in a multi-person team, as those issues are often very dependent on the specific source code control system or other project management and control processes in use. We'll keep our discussion centered around basic deployment steps that will be useful in single developer or team scenarios.

Specifically, we will discuss …

Platform considerations Moving a project from one computer to another, e.g. from development machine to test server Deploying Web Services using Web Deployment projects and the Microsoft Installer Publishing Web Services using One Click Hosting (a publishing technique that works inside Visual Studio .NET with Microsoft hosting providers) Copying or uploading projects the old-fashioned way

One of the attractions of generic Web Services is that theoretically you can deploy and consume Web Services on any conceivable platform with applications written in any conceivable language, just so long as the language implements the SOAP and WSDL specifications. As you might suspect, Microsoft focuses on the Windows operating system for its tools and frameworks and leaves other platforms to partners and other software companies. Here is a summary of the platforms supported by Microsoft for developing, deploying, and consuming Web Services.

Development - Visual Studio.NET runs on Windows 2000 and Windows XP Professional and above. The development machine needs IIS v5. Deployment - You can deploy .NET Web Services on Windows 2000 and Windows XP Professional and above. Consumption - You can consume .NET Web Services on Windows 98 and above. The consuming machine needs the .NET framework, which can be installed as part of an application installation.

Summary of Windows Platform Requirements Development Deployment Consumption Windows 95 & Windows 3.X N/A N/A N/A Windows 98/ME N/A N/A Yes Windows 2000 Pro and above Yes Yes Yes Windows XP Pro Yes Yes Yes

For other platforms such as Windows 95, Macintosh, or Linux, you'll need to choose a different route to develop client applications. There are several possibilities out there, many of which are still in development. You'll need to find a SOAP and WSDL software development kit (SDK). You'll need to assess the quality of the implementation along with the community support available. Creating a Viable .NET server from a standard Windows 2000 Server

Microsoft will release their Windows .NET Server family to manufacturing sometime later in 2002, though customers may not be able to acquire the products until sometime in 2003 per Jim Allchin's speech at the recent WinHEC show. Until then, Web Services will be deployed mostly on Windows 2000 Server and Advanced Server.

Here are specific instructions on preparing a Windows 2000 Server box to host Web Services applications. The server will need Internet Information Server 5.0, the .NET framework, and for many applications, the Microsoft Data Access Components for ADO connectivity to databases. Adding and enabling IIS on the server requires that a few patches be installed to protect from the many security and virus threats out there today.

Install Internet Information Server v5.0 From the Add/Remove Programs Control Panel, click on Add/Remove Windows Components and then click the checkbox for Internet Information Services (IIS) Install Windows 2000 Service Pack 2 Download from Microsoft Windows 2000 Download page Obtain critical updates for Windows 2000 and IIS Download from http://windowsupdate.microsoft.com Install .NET framework - A Web Service deployed with the Microsoft installer will include the .NET framework, otherwise … Install from d:\dotNetFramework\dotnetfx.exe on Visual Studio .NET Windows Component Update CD Install Microsoft Data Access Components v2.7 if your services require data access Download from http://www.microsoft.com/data/download_270RTM.htm

So now let's assume that the application is ready to move to a test environment--it has been debugged by the developer(s) and it builds on a developer workstation. The logical next step is to move the Web Services to a test server and run QA tests.

Let's discuss exactly how to move the Web Services from development workstation to a test server. We'll use the "Copy Project" option in Visual Studio .NET, a very easy way to move a Web Service project around. This technique is also useful for setting up a fellow developer's environment.

Web Services are deployed into virtual roots in your default Web directory, typically c:\inetpub\wwwroot. Copying a project will ensure that the appropriate files are copied and that the new folder will be made into a virtual root capable of running applications. Note that a generic folder in the default directory with the appropriate Web Service files will not work because IIS doesn't know it's an application. The "Copy Project" option automatically handles creating the virtual root fully ready to run applications.

1. Ensure that the test server is ready to house Web Services - see our earlier discussion on Platform Considerations 2. Select the project in Solution Explorer 3. From the Project menu, choose Copy Project to reveal the "Copy Project" dialog box

4. Select destination project folder - it must be an URL 5. Choose Web access method (FrontPage or File Share) 6. Choose "Only files needed to run this application " 7. Click OK (you will be prompted for a FrontPage username and password or Windows username and password)

The FrontPage Web access method is useful if you are working with a team of developers over the Internet. So long as you have access to the other Web Server (Front Page author permissions), this is a simple way to copy a project when filesystem access is not available.

The copy options are as follows:

Only files needed to run the application - includes the bin folder with compiled dll file and pdb file if you included remote debugging information; includes global.asax, Web.config, and asmx files (note: the DLL file includes the compiled Web Services and compiled versions of any other required classes--e.g. business logic or implementation details you decided to place in a separate class from your Web Service) All project files - includes all project files used by Visual Studio .NET All files in the source project folder - includes all project files used by Visual Studio .NET and any other files and folders in the source directory--e.g. database files, config files, etc.

Although the "Copy Project" method of deploying projects is easiest, sometimes it is not possible. In the following cases, you'll need to use a deployment package:

The .NET framework is not installed on the destination server The destination server is not accessible through FrontPage extensions or a file share You wish to distribute the application for someone else to install

In these cases, it makes sense to create a Microsoft installer file by using a Web Deployment project. Here is how that works.

1. Add a Web Setup Project

2. Right-click on the Web Setup Project just created 3. Click Add and then click on Project Output 4. Select the Web Service project and the output files required (Primary, Debug, and Content will handle most needs)

5. Right-click on the Web Deployment project and select "Build" (creates the setup.exe, MSI and other files)

This process will place the Microsoft installer files in the project folder.

If you are sure that the destination server already has the .NET framework, you can remove the .NET framework from the installer by choosing "dotnetfxredist_x86_enu.msm" from the Detected Dependencies folder in the deployment project, and setting its Exclude property to True.

Also note that in this version you can't include the Microsoft Data Access Component (MDAC) installation in the installer because the installer can't shell out to a separate executable. You'll need to have a separate installer for this if using Microsoft's installer.

Microsoft has included a very simple way to upload Web Services to partner hosting providers, called One Click Hosting. The process takes place from within Visual Studio .NET and is in fact the only way to publish to some of these hosting providers.

1. From the Start Page in Visual Studio .NET, click on "Web Hosting" 2. Click on the "Hosting Services" tab 3. Make sure you have your Web Services project open within Visual Studio .NET

We'll assume you already have an account with one of these hosting providers. If you don't, there is a link to sign-up in the "Hosting Services" tab.

4. Click on "Upload directly to your [hosting service] account" (We used ProTier) 5. Enter username & password 6. Highlight a project and click on "Upload" button

.NET applications including Web Services are really easy to deploy. You can actually just copy, FTP, or unzip all the necessary files to the destination. The only thing to remember is that the destination folder needs to be a virtual root. This is easy to do using the Microsoft Internet Services Manager. So, for example, if you copy or FTP a Web Service project to a folder called c:\inetpub\wwwroot\Thing7_GrayMarketWS, it will look like this within the Internet Information Services utility (Control Panel | Administrative Tools) - notice the folder icon as compared to the virtual root icon just above it.

Right-click on the folder and select properties. In the Directory tab, notice that there is no application name.

That's it. Now the folder is a virtual root and ready to run. And that wraps our four-part tutorial on creating and consuming Web Services using Visual Studio.NET. We look forward to your questions and comments in our discussion forum.

BEA BEA will support Java Web Services. Borland Borland supports Web Services on Java and Delphi environment. Eraserver.net Mike Amundsen's company, a web hosting provider for .NET and .NET Web Services applications. GotDotNet Another Microsoft site with great information on Web Services and the .NET framework. IBM IBM is deep into Web Services. Microsoft UDDI Directory Directory for UDDI entries describing Web Services. MSDN Microsoft's online library of knowledge, get to know it well. ProTier Web hosting provider for .NET and .NET Web Services applications. VBWS Yasser Shohoud's site about Web Services offering education, training, and consulting. World Wide Web Consortium Organization that handles many Internet standards including SOAP and WSDL. Xmethods A listing of Web Services with descriptions and server type along with other resources about Web Services.

Copyright © 2002 Ziff Davis Media Inc. All Rights Reserved. Originally appearing in ExtremeTech.