Web Service Deployment

 CD-ROM    The business tier is where XML-based Web Services are deployed. Typically, the deployment of a Web Service involves copying the .asmx file and any other assemblies that the XML Web Service uses to the IIS directory. (You can see the Setup file in \Code\Chapter 10\Candidate\WebService Submit\Web Service\Setup.exe on the companion CD-ROM.)

For example, if we take the Help Desk Web Service that we created in Chapter 6 and deployed this to an IIS server, the directory structure would contain the files shown in Figure 10.2. (You can see this in \Code\Chapter 6\Help Desk\HelpDesk  Setup.exe on the companion CD-ROM.)

Figure 10.2: The files and directory structure of a deployed Web Service.

Once the Web Service is deployed to a server, it contains the items shown in Table 10.1.

Table 10.1: Components of a deployed Web Service.

Item	Description
Web Application Directory	The root directory for an XML Web Service. This directory is marked as an IIS Web application.
[Web Service].asmx file	The base URL for clients calling the XML Web Service.
[Web Service].disco file	An optional component that enables Web Service discovery.
Web.config file	An XML configuration file created by Visual Studio.NET that overrides the default system configuration.
\bin directory	A default directory that contains the binary files for the XML Web Service. If the XML Web Service class is not contained in the same assembly, then the .asmx assembly class must be located in this directory.

Configuring Web Services

XML Web Services use the same configuration options as any other ASP.NET Web application. The ASP.NET configuration is based on an XML text file configuration designed to provide extensibility. These configuration files are a simple set of XML elements that represent the configuration options for a specific feature of the .NET Framework. In the case of Web Services, the configuration options are stored in the < webServices > XML element of the configuration file.

The root configuration file named machine.config provides the ASP.NET configuration setting for the entire Web server. This configuration file defines the default < webServices > element and provides the top-level configuration file. By default, this contains the information shown in Listing 10.1.

Listing 10.1: Default machine configuration file.

 <webServices>   <protocols>     <add name="HttpSoap1.2" />     <add name="HttpSoap" />     <!-- <add name="HttpPost"/> -->      <!-- <add name="HttpGet"/> -->     <add name="HttpPostLocalhost" />     <add name="Documentation" />   </protocols>   <soapExtensionTypes>   </soapExtensionTypes>   <soapExtensionReflectorTypes>   </soapExtensionReflectorTypes>   <soapExtensionImporterTypes>   </soapExtensionImporterTypes>   <wsdlHelpGenerator href="DefaultWsdlHelpGenerator.aspx" />   <serviceDescriptionFormatExtensionTypes>   </serviceDescriptionFormatExtensionTypes> </webServices> 

 

Each application directory in an ASP.NET Web application server can contain a file named web.config. Each individual web.config file applies configuration settings to its own application directory and any child directories below it. The child configuration file supplies other configuration information in addition to the default settings inherited from any parent directories. By default, each child directory configuration setting can override or modify the settings defined in the parent directories. The < webServices > element contains a set of XML tags, shown in Table 10.2, that configure the options.

Table 10.2: Configuration options for XML Web Services.

XML Tag	Description
< protocols >	Defines the transmission protocols used by an ASP.NET application to decrypt the data being sent from a client browser in an HTTP request. This data contains both method calls and parameters.
< serviceDescription FormatExtensionTypes >	Specifies the service description format that should be used within the configuration file.
< soapExtensionTypes >	Specifies the set of SOAP extensions used with XML Web Services.
< soapExtensionReflectorTypes >	Defines the SOAP extensions run when a service description is generated for an XML Web Service.
< soapExtensionImporterTypes >	Defines the SOAP extensions that are used when a service description is accessed to create a proxy class.
< wsdlHelpGenerator >	Is the default XML Web Services help page displayed when a browser navigates directly to an .asmx page.

At runtime, ASP.NET uses the configuration information contained in the machine.config and web.config files to create a hierarchical virtual directory structure that computes a collection of configuration settings for each unique URL resource. The resulting configuration settings are then cached and reused for all subsequent requests to the resource.

Note  

Inheritance is defined by the incoming URL request, not the physical paths to disk-based resources.

ASP.NET can detect changes to the configuration files and automatically applies new configuration settings to each Web resource affected by the changes. The edit and run feature of the .NET Framework doesn t require a server reboot in order for the changes to be applied. Hierarchical changes are automatically recalculated and cached whenever a configuration file anywhere in the chain is changed.

Note  

The < processmodel > tag is an exception to this rule. It is actually read by the aspnet_isapi unmanaged.dll and not the managed code configuration system. This section is responsible for defining many of the performance-tuning details. Any changes to this element may require a system reboot.

The ASP.NET configuration system is also extensible. You can define new configuration parameters and write configuration section handlers to process them. For example, you can extend the web.config file to store a connection setting to a SQL database that is then used as part of the Web Service. The web.config settings are shown here:

 <appSettings> <!--GLOBAL Connection string--> <add key="constring" value="server=localhost;database=Candidate;uid=sa;password=pass123" /> </appSettings> 

As a security restriction, ASP.NET protects HTTP access to these configuration files by configuring IIS to prevent direct browser access. IIS will return an HTTP access error, as shown in Figure 10.3.

Figure 10.3: The error returned when you re trying to browse a web.config file.

Security Recommendation

Before enabling either the HTTP Get or HTTP Post protocols for an XML Web Service, always ensure that you haven t inadvertently created any possible side effects or security vulnerabilities. For example, an unsuspecting user could receive an e-mail with a link in it that invokes the XML Web Service on behalf of the user, using parameters supplied in the e-mail. You should always consider whether such unintentional invocations could be harmful .

For application servers that don t need to have either the HTTP Post or Get protocols enabled, you can disable these protocols by performing the following steps:

1. Edit the machine.config file.

2. Comment out the lines in the webServices section that add the support for these protocols, as shown below:

    <webServices>       <protocols>         <add name="HttpSoap"/>           <!-- <add name="HttpPost"/> -->           <!-- <add name="HttpGet"/>  -->         <add name="Documentation"/>         <add name="HttpPostLocalhost"/>       </protocols>     </webServices> 

3. Save and exit the machine.config file.

Once the new configuration file is saved, this automatically causes the configuration hierarchy to be recalculated and the new changes to be implemented. The next HTTP request to the server is then rejected based on the configuration change.

The same type of edit can be done for each of the individual Web applications. The difference between editing the system configuration and individual directories is that based on the inheritance of the XML configuration system, the actual system-wide protocols are not physically contained in the local web.config files. Using the < remove > XML tag, you can disable these individual protocols. Just follow these steps:

1. Open the web.config file in the root directory of the Web application.

2. Modify the webServices section of the web.config file to explicitly remove the HTTP Post and Get protocols, as shown below:

    <webServices>       <protocols>         <remove name="HttpPost" />         <remove name="HttpGet" />       </protocols>     </webServices> 

3. Save and exit the web.config file.

This change causes the local configuration hierarchy to be recalculated and the next request to the application to be denied .

Service Help Page

By default, navigating to the URL of an XML Web Service application without any parameters allows clients to view the services help page. This page contains the default human-readable information about how to communicate with the XML Web Service as well as the supported methods and parameters. This page is an ASP.NET Web form that you can replace or even modify to include additional elements like a company logo.

The file name for this page is specified in the < wsdlHelpGenerator > XML element of the machine.config file. This page is displayed only for XML Web Services that have the documentation protocol specified within the < protocol > XML element. You can disable this for an individual Web application using the following steps:

1. Edit the web.config file in the root directory of the Web application.

2. Modify the webServices section of the web.config file to remove the documentation protocol, as shown below:

    <webServices>       <protocols>         <remove name="Documentation" />       </protocols>     </webServices> 

3. Save and exit the local web.config file.

This configuration change immediately takes effect on the next request to the XML Web Service. It is important to remember that removing the documentation protocol also disables the WSDL file generation for the Web application. This prevents clients from generating a proxy class unless a custom WSDL file is created. When designing an InfoPath form, you can prevent design mode access to the Web Service.

Building Web Service Deployment Solutions Using Visual Studio

Once the application development is completed, Visual Studio.NET provides a set of deployment projects that assist with the distribution of Web Services, as shown in Figure 10.4.

Four setup and deployment projects are available within Visual Studio.NET. Each project type, shown in Table 10.3, provides a wizard that helps you step through the creation of a deployment project.

Table 10.3: Setup and deployment project types.

Project	Purpose
Merge Module Type	Packages shared components.
Setup Project	Is the installer project for Windows-based applications.
Web Setup Project	Is the installer project for a Web-based application. This includes Web Services and ASP.NET applications.
Cab Project	Creates a cabinet file for downloading to a legacy Web Browser.

Note  

Merge Module Projects allow you to package multiple files or components into a single module to facilitate sharing. The resulting .msi file can be included in any other deployment project.

It is important to keep in mind that the distinction between Setup and Web Setup Projects is based on the location where the installer is deployed. For Setup Projects, the installer will deploy files into a Program Files directory on a target computer. For Web Setup Projects, the installer will deploy files into a Virtual Root directory on a Web server.

Figure 10.4: The Setup and Deployment projects available within Visual Studio.NET.

Note  

Once a Setup Project is created, the project type cannot be changed between Web and Standard. If you decide later that you want to change the deployment mechanism, you need to create a new project.

Deploying Web Services

The Candidate Questionnaire Web Service provides a business tier component for an InfoPath form. This Web Service can be deployed using the .MSI install file created using Visual Studio.NET.

Once coding is completed on the Web Service, as shown in Figure 10.5, it is ready for packing and then deployment to a production Web server.

Figure 10.5: The completed Web Service.

To package and then deploy a Web Service to a production Web server, follow these steps:

1. Add a Web Setup Project to the existing solution, as shown in Figure 10.6.

   
   Figure 10.6: Adding a Web Setup Project.

2. Add the compiled project output to the project, as shown in Figure 10.7.

   
   Figure 10.7: Adding the compiled output to the installer.

3. Rebuild the project to generate the output for the installer project, as shown in Figure 10.8.

   
   Figure 10.8: Rebuilding the project.

4. When the rebuild is complete, the MSI file is stored in the Application directory of the installer project, as shown in Figure 10.9.

   
   Figure 10.9: The newly created MSI file.

Modifying the InfoPath Form

Development and production environments always have different naming conventions. Once the Web Service has been deployed, you need to modify the associated InfoPath forms so that they point to the right servers. Follow these steps to change the location of the InfoPath form and point it to a production server:

1. On the InfoPath File menu, select Extract Form Files.

2. Close InfoPath.

3. In Windows Explorer, locate the folder where you placed the extracted form files.

4. Edit the  manifest.xsf file using Notepad.

5. Locate the < xsf:webServiceAdapter > tag and change the wsdlUrl attribute to point to the production server, as shown below:

    http://productionserver/contact/contactservice.asmx?WSDL 

6. Locate the < xsf:operation > tag and change the serviceUrl attribute to point to the production server, as shown below:

    http://productionserver/contact/contactservice.asmx to 

7. Save the changes and exit the  manifest.xsf file.