< ASP .NET, C# Web Service & C++ Program Example | Main | Configuring IIS for Web Service Hosting >

 


 

 

Chapter 11 Part 6:

XML Web Services and the Network

 

 

What do we have in this chapter 11 Part 6?

 

  1. Performance

  2. 100 Continue and POST

  3. Preauthentication

  4. Connection Pooling

  5. Nagle Algorithm

  6. Scalability

  7. Calling a Web Service from Within ASP.NET

  8. C#/ASP .NET Asynchronous Web Service Access Program Example

  9. Creating C# ASP .NET Web Service Application

  10. Build, Run and Test the Web Service Application

 

 

Performance

 

The Web services platform in the .NET Framework is built with high performance in mind on IIS and System.Net; therefore, it can be quite fast. A number of common “gotchas” can arise, however, as you deploy Web services in a production environment that requires high performance. The performance tips given here will be discussed in detail in Chapter 14. The purpose of this section is to call out common elements that often apply to applications using Web services, so that they can be avoided.

 

100 Continue and POST

 

Because Web services are usually sent via an HTTP POST, they are subject to the 100 Continue logic, which will be described in Chapter 14. While 100 Continue is often the ideal semantic because it can save the client from sending data that doesn’t have to be sent, 100 Continue does cause an extra roundtrip between the client and the server for each Web-service call. If the data is small enough, it might be faster to simply turn off the 100 Continue feature for Web services. The 100 Continue feature is controlled via the System.Net.ServicePointManager.Expect100Continue property.

 

Preauthentication

 

Preauthentication can save time in cases in which the application repeatedly calls the same set of services. At least one major Web services client product sends basic authentication credentials with every request if pre-authentication is turned on in the client API. We know this because we occasionally get requests to do this for Web services calls. System.Net does not send the basic credentials on the first request when pre-authentication is enabled. This is because the client doesn’t know which authentication scheme is desired by the server until it has made at least one request to the server. Basic authentication alone provides little defense in terms of protection from credential theft. It would be unfortunate if the client sent basic credentials across the network when the server wanted some stronger form of authentication, such as Kerberos. In general, we recommend that basic authentication be used only if it is done in concert with some other encryption mechanism, such as HTTPS (Secure HTTP) or encryption at the network’s IP layer or lower. In cases where the environment is controlled, however, and the benefits of using basic authentication are deemed to outweigh the risks, you can add your own basic header to the Web service request using the custom header logic described earlier in this chapter.

 

Connection Pooling

 

In Visual Studio .NET the UnsafeAuthenticatedConnectionSharing property is exposed on each of the automatically generated client proxies. UnsafeAuthenticatedConnectionSharing is used in conjunction with the ConnectionGroupName property, which is also exposed on the Web services proxy. If the service is using authentication, these two properties can have a significant impact on the performance of your Web service, as they enable connection pooling for the authenticated connections. Be sure to use them carefully according to the description in Chapter 14.

Also notice that the System.Net connection semantics apply to Web service requests made with the .NET Framework. For example, setting the System.Net.ServicePointManager.DefaultConnectionLimit to 20 when the application domain is starting will cause all Web service requests to use a connection limit of 20 rather than the default of 2.

 

Nagle Algorithm

 

The Nagle algorithm increases network efficiency by decreasing the number of packets sent across the network. It accomplishes this by instituting a delay on the client of up to 200 milliseconds when small amounts of data are written to the network. The delay is a wait period for additional data that might be written. New data is added to the same packet. The practice of compiling data is not always ideal for Web services, however, because a POST request often contains a small amount of data in the HTTP headers without the body (because of 100 Continue, as described earlier). The Nagle algorithm can be turned off for Web services calls via the System.Net.ServicePointManager.UseNagleAlgorithm property. Yet disabling the Nagle algorithm might not provide the best performance either, you’ll need to experiment with disabling the algorithm to fine- tune your application. Whether you should disable the algorithm in this case depends on several factors, including the size of the Web services call, the latency of the network, and whether HTTP authentication is involved.

 

Scalability

 

Certain decisions can significantly increase system scalability when using Web services. The following tips are related to managing the use of threads and connections within the system.

 

Calling a Web Service from Within ASP.NET

 

Developers who use the .NET Framework frequently call Web services from within ASP.NET. This practice is known as a “middle-tier” scenario. Because ASP.NET and System.Net share the same thread pool, however, the threads must be well managed when used together. When threads are not well managed, a middle-tier ASP.NET application that calls a Web service can run in an underutilized state while the server waits for available threads. An even worse outcome is a deadlocked application caused by ASP.NET worker threads waiting for back-end requests to complete. Back-end requests require additional threads to complete, so nothing can happen until the requests start to time out. An obvious way to guard against such thread starvation is to always move the methods being called into a local dynamic link library (DLL) and call them directly from code whenever possible.

However, an off-machine, Web services call is often necessary as part of processing an ASP.NET page. In this case, there are a number of concepts to keep in mind.

 

  1. By default, System.Net limits the number of connections to two connections per application domain and host pair. The number of available connections can be increased either programmatically or through configuration in the System.Net section. In middle-tier scenarios, the connection limit should be bumped higher than two to better utilize the server.
  2. Back-end calls that involve redirection or authentication can exacerbate the thread problem. It is possible for System.Net to require two threads to complete in cases where redirection or authentication is required.
  3. A number of parameters in the machine.config file can help to further fine-tune application scalability in middle-tier scenarios. These values include maxWorkerThreads, maxIoThreads, minFreeThreads, minLocalRequestFreeThreads, maxconnection, and executionTimeout. The best use of these values can be found in Microsoft Knowledge Base article 821268 at Contention, poor performance, and deadlocks when you make Web service requests from ASP.NET applications.

 

Another option available to middle-tier applications that need to call a Web service as a result of an ASP.NET page request is to use the asynchronous framework provided in ASP.NET to include a module that issues the request asynchronously before the page starts to load. This way, the server will have no threads blocking while I/O completes and pages will have the necessary data when they load. This option is fairly complex, but it can enable applications to get the most out of the available resources on the server. The following sample projects demonstrates a page that uses an asynchronous module to call a Web service and process a request with ASP.NET support for asynchronous modules. The samples are given in C# and VB .NET.

 

C#/ASP .NET Asynchronous Web Service Access Program Example

 

In this exercise we will create an ASP web service application and then we will try to create an asynchronous module. Later we will load our own asynchronous module when an asp page is accessed. Take note that we will create the C# solution which contains both projects (ASP web service and asynchronous module) directly under the IIS web server root directory by assuming the IIS already configured and running.

 

Creating C# ASP .NET Web Service Application

 

Create a new C# ASP .NET Web Service Application.

 

The C# Asynchronous Web Service Access with ASP .NET WEB Service application development Program Example: Invoking the new Visual studio project page

 

You can use the AuthServiceCS as the solution and project name if you want. Make sure the project is put under the C:\Inetpub\wwwroot folder. The C:\Inetpub\wwwroot is the default IIS physical web root folder.

 

The C# Asynchronous Web Service Access with ASP .NET WEB Service application development Program Example: selecting the asp .NET web service application project template

 

The ASP web service project template was given for us to customize it as shown in the following screenshot.

 

The C# Asynchronous Web Service Access with ASP .NET WEB Service application development Program Example: the C# web service project template seen in Visual Studio IDE

 

Add the following using directive and delete other un-use using directive.

 

using System.Text.RegularExpressions;

 

Change the tempuri.org Namespace:

 

[WebService(Namespace = "http://tempuri.org/")]

 

To localhost URI. In real development, this should be your real URI.

 

[WebService(Namespace = "http://localhost/")]

 

Add/edit the code as shown below.

 

using System;

using System.Text.RegularExpressions;

using System.Web;

using System.Web.Services;

 

namespace AuthServiceCS

{

    /// <summary>

    /// Summary description for Service1

    /// </summary>

    [WebService(Namespace = "http://localhost/")]

    [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

    [System.ComponentModel.ToolboxItem(false)]

    // To allow this Web Service to be called from script, using ASP.NET AJAX, uncomment the following line.

    // [System.Web.Script.Services.ScriptService]

    public class Service1 : WebService

    {

        [WebMethod]

        public int Sum(int lhs, int rhs)

        {

            return lhs + rhs;

        }

 

        [WebMethod]

        public bool IsAuthorized(string userName)

        {

            // shun John, let everyone else in

            Regex r = new Regex("john", RegexOptions.IgnoreCase);

            Match m = r.Match(userName);

 

            if (m.Success)

                return false;

            else

                return true;

        }

    }

}

 

Build, Run and Test the Web Service Application

 

Next, build the project. Make sure there is no error.

 

The C# Asynchronous Web Service Access with ASP .NET WEB Service application development Program Example: building the web service project solution

 

Then debug (run in Debug mode) the project. Make sure there is no error.

 

The C# Asynchronous Web Service Access with ASP .NET WEB Service application development Program Example: debugging the web service project

 

Select the first radio button. Visual Studio will enable the debugging setting in the Web.config file. This setting must be disabled in the real deployment. Most of the web activities for a web application can be controlled through Web.config settings and can also be overrided by the ASP codes programmatically.

 

The C# Asynchronous Web Service Access with ASP .NET WEB Service application development Program Example: enabling the compilation debug setting in the web.config

 

When you double-click the Web.config file, the debug setting will be changed to "true" value as shown below.

 

The C# Asynchronous Web Service Access with ASP .NET WEB Service application development Program Example: the web.config compilation debug setting

 

The following is the web service test page run in the ASP .NET development server.

 

The C# Asynchronous Web Service Access with ASP .NET WEB Service application development Program Example: the C# web service test page exposing the methods

 

Let do some testing. Click the IsAuthorized link (web method). Type in any name (value) other than John in the userName (parameter) text box and click the Invoke button.

 

The C# Asynchronous Web Service Access with ASP .NET WEB Service application development Program Example: testing the web service method in the browser

 

The result is displayed in XML format. In the real application development and deployment we need to create a page for the value input and the result. Notice also the URL in the browser address bar.

 

The C# Asynchronous Web Service Access with ASP .NET WEB Service application development Program Example: the result of the web service method returned in the XML page

 

 

 


< ASP .NET, C# Web Service & C++ Program Example | Main | Configuring IIS for Web Service Hosting >