< Resolving .NET System.Web Namespace Manually | Main | Chap 12 TOC: .NET Remoting >

---

 

 

Chapter 11 Part 15:

XML Web Services and the Network

 

 

What do we have in this chapter 11 Part 15?

58. Editing the Web.config File

59. The DLL Module and bin Folder

60. Running the Whole Project

61. The ASP .NET Development Server Configuration

62. Load Balancing Back-End Web Service Calls

63. Avoiding Common Pitfalls

64. Consuming an External Web Service

65. Using Certificates from the Middle Tier

66. Handling Network Failures

67. Transferring Large Amounts of Data

68. The Future: WCF

 

 

 

 

 

In the meantime, you can also have details of the assembly by clicking the Assembly Information button.

 

 

Then, add the following HttpModules element name and type for the asynchronous DLL class.

<add name="AsyncAuthorizationVB" type="AsyncModuleVB.AsyncModule, AsyncModuleVB" />

 

 

Then, add the authorization element which will deny access for certain user.

 

 

 

Next, set the redirect page for denied access user.

 

 

 

Now, we are ready to build and run the project. Build and run without debugging the project

 

 

 

The DLL Module and bin Folder

 

Well, there is another error. The asynchronous DLL class cannot be found.

 

 

 

 

 

We need to tell IIS where to find the .DLL file for the asynchronous DLL class and the default folder is /bin. Copy the .DLL and .PDB or all the files under the bin/Debug folder of the AsyncModuleVB folder. We copy all the files because this is a Debug instead of Release version. The Release version only needs the .DLL file.

 

 

Paste those copied files into the bin folder of the AuthServiceASPVB\bin folder.

 

 

Running the Whole Project

 

Re-run the project. The following empty page should be expected. We are not concern about the page but the Visual Studio Output window. Stop the browser, close the page and stop the ASP .NET development server (use the icon tray).

 

 

 

 

Then, re-run the project in debug mode. Notice the messages in the Visual Studio’s Output window.

 

 

If you have been greeted by the following windows form, select the first radio button. By default the debug is disabled (value set to false) in the Web.config file. Take note the warning message which said the debug should set to false for the real deployment or production, else any user accessing the web site can see the error(s) displayed in the web browser, if any and can use the error for hacking.

 

 

Then, the debug value in compilation element of the ASP schema in the Web.config should be set to true.

 

 

Open as many browsers as you want by using the following same URL displayed in the previous browser. In this case http://localhost:1707/. Monitor the Output window. The following is the re-produced messages from the Output window for three web accesses. Notice the loaded AsyncModuleVB.DLL and the same ThreadId for all the access.

...

'WebDev.WebServer.EXE' (Managed): Loaded 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\9e70464d\c2c5a307\assembly\dl3\c604b9dd\10faad35_be7ec901\AsyncModuleVB.DLL', Symbols loaded.

'WebDev.WebServer.EXE' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_MSIL\SMDiagnostics\3.0.0.0__b77a5c561934e089\SMDiagnostics.dll'

'WebDev.WebServer.EXE' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_MSIL\System.Web.Services\2.0.0.0__b03f5f7f11d50a3a\System.Web.Services.dll'

'WebDev.WebServer.EXE' (Managed): Loaded 'lkqm3-j7'

'WebDev.WebServer.EXE' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_MSIL\Microsoft.VisualBasic\8.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualBasic.dll'

'WebDev.WebServer.EXE' (Managed): Loaded 'vdyr5z7h'

TraceHelper.WriteLine: ThreadId: 4 Counter: 28 Msg: AsyncModule.Init: Initializing the module instance...

TraceHelper.WriteLine: ThreadId: 4 Counter: 28 Msg: AsyncModule.AsyncBeginHandler: Beginning the authorization...

The thread 0xa70 has exited with code 0 (0x0).

TraceHelper.WriteLine: ThreadId: 4 Counter: 29 Msg: AsyncModule.Init: Initializing the module instance...

TraceHelper.WriteLine: ThreadId: 4 Counter: 29 Msg: AsyncModule.AsyncBeginHandler: Beginning the authorization...

TraceHelper.WriteLine: ThreadId: 4 Counter: 30 Msg: AsyncModule.Init: Initializing the module instance...

TraceHelper.WriteLine: ThreadId: 4 Counter: 30 Msg: AsyncModule.AsyncBeginHandler: Beginning the authorization...

The ASP .NET Development Server Configuration

 

If you are curious about the port number used by the ASP .NET development server, the information and setting can be found in the project property page in the Web page as shown below. You can make the port fix to specific port number if you want.

 

 

 

In the Web page for the project property also we have several options on how to start the web service (also apply to web application). In our case, we already created the default.aspx page which is a normal default web page (if the first page was not set). This setting can be enabled from the Solution explorer by selecting any page, right-click mouse and select Set As Start Page menu.

 

 

We can also convert the web service application into web application from the Visual Studio IDE through the Convert to Web Application menu and publish the web service directly to the IIS web server using the Publish menu shown below.

 

 

 

 

When you open any ASP or HTML or any recognized web page extension, the ASP .NET Configuration short cut will be visible as shown below.

 

 

And also through the Project menu.

 

 

 

 

 

 

If you want to access the web service through the browser please refer to the MSDN’s Accessing XML Web Services from a Browser reference. However you have to make sure your IIS web server and the ASP settings are configured properly, running and your web service or application was deployed or published successfully. These tasks have been demonstrated in the previous exercise using C#.

In the newer release of the .NET Framework, significantly simplify the model for dealing with asynchronous execution calls associated with a page and the related Web service call. You may want to have a peek on the following articles and references:

 

1. An Event-Driven Asynchronous Web Service Client Using ASP.NET 2.0.
2. Asynchronous Web Service Calls over HTTP with the .NET Framework (client-side).
3. Server-Side Asynchronous Web Methods (server-side).
4. The ASP.NET AJAX.

 

Load Balancing Back-End Web Service Calls

 

Let’s begin by reviewing how network load balancers work. Network load balancers are used to balance the load of Web service calls between a Web server and a number of back-end machines. The load balancer represents a virtual address that Web service calls go to from the Web server to the back-end machines. The load balancer attempts to distribute the Web service calls based on a hash of the caller’s IP address and the client wildcard port used to connect to the virtual address.

Now we’ll look at problems with Web services that can occur in this environment. As we’ve said throughout this chapter, Web services in the .NET Framework use the System.Net HTTP implementation. To trim the significant overhead associated with creating a new connection, the HTTP stack keeps TCP connections to the server open for as long as possible through use of the HTTP keepalive behavior. However, a problem can occur when you want the connections torn down in order to force the client to make requests over a different client port and enable load balancing to occur. But because System.Net doesn’t want to close the connections, you might see a situation where the load between two servers behind a network load balancer is not balancing evenly. Two options can be helpful in this situation—both options involve closing the connections periodically so that the load balancer can balance the requests across the back-end machines:

 

1. Close the connection from the client: One option is to set HttpWebRequest.KeepAlive to false on every request or with enough frequency that load balancing can occur. This is the easiest solution, but it has a couple of drawbacks. The first drawback is that turning off keepalive can cause the authentication to fail when you are using a connection-oriented authentication scheme, such as NTLM, to authenticate to the back-end machines. The second drawback is that you have to write the logic to close the connection, rather than having it provided by the stack, if you only want the closing behavior to kick in every so often.
2. Close the connection from the server: A second option is to have a Web service on the back end that sets the connection close header on every request or at a predetermined interval. Like the previous option, this one requires you to implement your own logic for when to close the connection; however, there is no restriction against using NTLM because the request will never be closed in the middle of an NTLM handshake.

 

The next major release of the .NET Framework is expected to improve support for load balancing by allowing the System.Net HTTP stack to forcefully tear down the connections at specified intervals.

 

Avoiding Common Pitfalls

 

As with any technology, it is possible to make assumptions about how an API should work that are incorrect and potentially problematic. In this section, we’ll present a list of the most common issues we’ve heard from developers using production Web services in the .NET Framework.

 

Consuming an External Web Service

 

Visual Studio .NET includes an Add Web Reference dialog box that makes it easy to consume a Web service from within a code project. In the dialog box, you simply type in the service URI, and the dialog box displays the contents of the Web service. You then click the Add Web Reference button, which causes Visual Studio .NET to build a client class that calls the service when you call its methods. In versions 1 and 1.1 of the .NET Framework, a feature known as “automatic proxy detection“ is supported by Microsoft Internet Explorer, but not by System.Net. This feature is accessible through the Control Panel, Internet Options, Connections tab, LAN Settings button. If you are attempting to build a client that consumes a Web service that is external to your network, and the Automatically Detect Settings check box enabled, it is possible that you’ll be able to see the service with Internet Explorer, but not be able to use Visual Studio .NET to build the client class that consumes the service. The fix for this situation is to clear the Automatically Detect Settings check box and specify your proxy settings directly. The next major release of the .NET Framework is likely to include support for automatic proxy detection.

 

Using Certificates from the Middle Tier

 

The .NET Framework supports the ability to call a Web service over the Secure Socket Layer (SSL) protocol. When SSL is used over an HTTP connection it is known as Secure HTTP or HTTPS. In some scenarios, it’s desirable to send a client certificate as part of the handshake that occurs when an HTTPS session is established. In versions 1 and 1.1 of the Framework, this is done by installing a certificate in the My User account certificate store, then exporting the public key for that certificate, and then using the exported file when you construct an X509Certificate class, which is then set on the Web services client instance.

The problem with using this approach on the middle tier is that the My User account is associated with the current user, and there is no current user when running under a service such as ASP.NET. As a result, the certificate is not found when System.Net tries to use it at execution time. To improve this situation, an update is available for the version 1 platform at ASP.NET Web application cannot deliver a client certificate to a security-enhanced Web site. The update also will be included in Service Pack 3 for version 1 and Service Pack 1 for version 1.1. The fix for this issue enables System.Net to look in the Computer account, also known as the Machine store, in addition to the My User account. This way, if you want to use a client certificate to authenticate from the middle tier, you can install the certificate in the Machine store and System.Net will find it there at execution time.

 

 

 

 

Handling Network Failures

 

Occasionally, network failures occur in the middle of a Web service call. The cause of the failures can range from a faulty driver in a network device, to a power outage on the server, to someone simply tripping over a cable. The fact is, the network connection might fail. This problem presents Web service developers with a difficult situation. Because Web services use HTTP POST, the System.Net stack cannot simply retry the request - a client calling, say, the pizza ordering Web service might end up with two orders rather than one. This network failure problem will be solved over time as Web-service specifications for reliable messaging evolve and are implemented in the stack. Until that time, however, developers must continue to be aware of this issue and factor it into their application design. Here are some tips that can help:

 

1. Because the network call can fail, client applications should always include Web service calls in a try/catch block so that failure cases are handled accordingly.
2. When failures occur, client applications should be programmed to either retry the call or alert the user or system administrator of the failure. You should use caution when retrying the call to avoid the “two pizzas ordered instead of one” effect.
3. Services might have retry logic built in so that duplicate detection logic is included on the server. This logic enables clients to retry in cases where a minor network glitch caused the failure as opposed to a catastrophic event such as a power outage.

 

Transferring Large Amounts of Data

 

Sending attachments or other large amounts of data within a single Web services call can have a negative effect on performance and network utilization. There are two primary reasons for this. The first reason for diminished performance is that a Web service encodes the message within a “SOAP envelope” that is included in the HTTP request or response, depending on whether the data is being sent or being received. This encoding can increase the data size, which is not desirable with an already large block of data. The second reason for suboptimal performance is that in version 1.1 of the Framework a Web services call is an all-or-nothing proposition. This means that, if a particular Web service method is designed to return a 10-MB file and it fails after sending 9 MB of the response, the application cannot simply request the remaining 1 MB. Contrast this to the HTTP GET verb that enables client applications to specify which portion of the response is desired. There are a few options to consider when programming a Web services solution that needs to work with large amounts of data.

 

1. Don’t send or receive the data in a Web service, use a URI instead. If the data being sent or received is extremely large, it might be best to pass a URI within the Web services call and use a more suitable protocol for the file transfer, such as FTP or HTTP.
2. You can use different forms of compression to reduce the content size and minimize the impact of large data elements. A SOAP extension enables you to compress various parts of the Web service message. The HTTP protocol also supports compression on downloads, so HTTP transport compression is an option if the large data is being downloaded.
3. When designing the application, you should consider including caching logic that avoids costly calls whenever possible.
4. Efforts were made to better address this issue within the context of a Web service call. Check out more information on Direct Internet Message Encapsulation (DIME), Message Transmission Optimization Mechanism (MTOM) and WS-Attachments.
5. Don’t forget to have a peek on Web Services Enhancements (WSE) and WSE Ver3 which is part of the Windows Communication Foundation (WCF).

 

The Future: WCF

 

Web Services Enhancements for Microsoft .NET (WSE) releases provide a glimpse of where Microsoft is heading with Web services. WSE is an ideal way to become familiar with the evolving standards in Web services while getting solutions to some of the challenges present in Web services today. However WSE just part of the Windows Communication Foundation (WCF) which already has become a complex 'framework'. The WSE based application should 'migrate' to WCF eventually. If you just start learning the Windows web services, it is a better option to learn WCF directly. As stated in the documentation, although there are many similar aspects between the WCF and ASP.NET or WSE 3.0 programming models, they are different.

Web services are moving from implementation that is bound to the HTTP protocol to Web services that are protocol-independent. Independence from the underlying network transport protocol will broaden the possible solutions that can be built using Web services. It will also enable programmers to move beyond HTTP-related challenges with Web services discussed in this chapter, such as the 100 Continue behavior. One of the best things you can do to help your applications evolve along with this trend toward protocol independence is to keep business logic in your service separate from transport protocol logic. For example, code that modifies HTTP headers or changes other properties described in this chapter should be separated from logic that could be applied to the message independent of the protocol being used.

 

 

---

< Resolving .NET System.Web Namespace Manually | Main | Chap 12 TOC: .NET Remoting >