Editing the Web.config File
The next step we need to think how register the asynchronous DLL class for the IIS web server so that when user access the site the DLL will be loaded and run. With ASP .NET we can use the <httpModules> tag (more reference of the httpModules element from MSDN). Open the Web.config file.
Find the HttpModules tag. Before that we need to know the class and assembly name for the asynchronous DLL class. We can find it in the project property page in the Application page shown below.
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.
<deny users="?" />
Next, set the redirect page for denied access user.
<!-- let everyone get to access denied -->
<allow users="*" />
Now, we are ready to build and run the project. Build and run without debugging the project
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.
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\126.96.36.199__b77a5c561934e089\SMDiagnostics.dll'
'WebDev.WebServer.EXE' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_MSIL\System.Web.Services\188.8.131.52__b03f5f7f11d50a3a\System.Web.Services.dll'
'WebDev.WebServer.EXE' (Managed): Loaded 'lkqm3-j7'
'WebDev.WebServer.EXE' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_MSIL\Microsoft.VisualBasic\184.108.40.206__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...
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:
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:
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.
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.
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.
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.
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:
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.
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.