Chapter 11: XML Web Services and the Network


This chapter won t dwell on what Web services are in the .NET Framework. Instead, we ll look at how Web services interact with the lower-level network aspects of the stack. If you are unfamiliar with the basics of Web services, you might want to check out Building XML Web Services for the Microsoft .NET Platform , by Scott Short (Microsoft Press, 2002).

We ll start this chapter by examining the components that make up a Web service in the .NET Framework. Then we ll dive into the details of controlling how Web services interact with the Hypertext Transfer Protocol (HTTP) and how to override a Web service request to change the protocol. Next we ll talk about how to get the best performance and scalability out of your Web service applications while avoiding some of the common pitfalls. Finally, we ll talk about the future of Web services and how to design your applications such that they will continue to work well as Web services evolve .

Web Services

In version 1.1 of the Microsoft Windows .NET Framework, Web services are exposed in the form of matching client and server technologies that map to the HTTP request-response model. Figure 11-1 illustrates the flow of a message as it travels from client to server and back.

click to expand
Figure 11-1: Web service message flow over HTTP in the .NET Framework

A client application issues a request by calling a method on a class that represents a client proxy for the server. The .NET Framework takes care of serializing that call into a SOAP message and sending it in an HTTP POST command to the server. On the server side, Internet Information Server (IIS) receives the request and passes it up through ASP.NET, where it gets deserialized and exposed to the server application code in the form of a method call. The method is then called. When the method completes, the server responds, and the response data gets serialized and sent back to the client application.

Interacting with the Network

There are two critical points to bear in mind as you consider how Web services interact with the network. First, it s important to understand the relationship between a Web service call and the underlying transport used to flow that call from one location to another. It s also necessary to understand the APIs available to help control the flow of a message as it originates from the client, gets transported and processed on the server, and is received back in the form of a response.

Web Services and HTTP

From a network perspective, it s important to understand that Web services in version 1.1 of the .NET Framework use the HTTP protocol. Most production Web services use HTTP, but because SOAP is transport-protocol independent, you can expect more services to use SOAP in the future. The Web services implementation in the framework allows an application to call a Web service, using either the HTTP POST verb or the HTTP GET verb. In practice, most applications use HTTP POST because it passes a SOAP envelope to the server within a request body, as opposed to including it as part of the query string parameters. This approach is more in line with the design of the HTTP protocol and, therefore, is better understood by the HTTP infrastructure that handles the message, which makes it more efficient and reliable.

HTTP protocol bindings for a Web service are specified in two locations: in the machine.config file stored in the config subdirectory within the .NET Framework version directory on the machine, or in a Web.config file associated with a particular application on the server. The following code sample demonstrates using the configuration settings in the System.Web section of the configuration system to control these bindings:

 <configuration> <system.Web> <WebServices> <protocols> <addname="HttpSoap1.2"/><!-reservedforfutureuse--> <addname="HttpSoap"/> <!--<addname="HttpPost"/>--> <!--<addname="HttpGet"/>--> <addname="HttpPostLocalhost /> <addname="Documentation"/> </protocols> </WebServices> </system.Web> </configuration> 

Notice that HttpPost and HttpGet are disabled by default. This is because they are intended for certain interoperability scenarios and do not offer the same level of control or efficiency as the HttpSoap binding. Although the HttpSoap binding uses an HTTP POST to send the data, it s different from the HttpPost binding because HttpSoap sends a SOAP message in the HTTP payload, whereas HttpPost simply sends form-encoded XML data in the HTTP payload. The original intent of HttpPost was for interoperability with XML and RPC (Remote Procedure Call) services that didn t understand SOAP. The SOAP protocol is now common, however, and HttpPost is rarely needed. Documentation provides the documentation page that comes up when you hit the service URL with a browser. POST on the local host enables you to locally test a service with basic types such as int or string by typing values into an auto-generated HTML page in the browser and hitting a button.

Understanding the dependency that exists between Web services and the HTTP infrastructure is important as it will help you to realize that Web services can be managed, monitored , debugged , and so on using the same or similar models as those used for Web sites in general. A critical difference, however, is the role that the client plays in the conversation. In the world of static or dynamically generated HTML and the browser, most of the control over network- related elements in an application is given to the developer and administrators on the server only. In the world of Web services decisions made by the application developer, both the client and the server can have a significant influence over the end- user experience in terms of performance, scalability, and security.

Extending Your Service

Web services in the .NET Framework include an extensibility model that enables an application to gain access to a message before and after it gets serialized or deserialized by the framework. This model is known as a SOAP extension. SOAP extensions make it possible for an application to modify the stream used to represent the message body to add support for features such as encryption, custom logging, and compression.

Note  

Good examples of SOAP extensions are available online at http://msdn.microsoft.com/Webservices and www.gotdotnet.com .

Controlling the HTTP Request-Response Pair

In addition to extending a SOAP message, the framework provides a way for an application to control the actual HTTP protocol being emitted by the client request. This functionality is when you want to add custom HTTP headers. This is often done in cases in which infrastructure, or other parts of the system, rely on certain patterns or values in the HTTP message, and these values must be added to the Web service call so that it can interoperate with these systems. The following code demonstrates how you can use access to the HTTP headers to send custom HTTP information to the server:

C#
 usingSystem; usingSystem.Net; ///<summary> ///SampleclassthatdemonstratescallingaWebservice ///withacustomHTTPheader. ///</summary> classWebServicesMathClient { [STAThread] staticvoidMain(string[]args) { //Getx,yfromtheconsole Console.Write("X:"); intx=int.Parse(Console.ReadLine()); Console.Write("Y:"); inty=int.Parse(Console.ReadLine()); //Instantiatethederivedmathservice MyMathServicemathService=newMyMathService(); //Calltheaddmethodandprinttheresult floatresult=mathService.Add(x,y); Console.WriteLine(x+ " + " +y+ " = " +result); } } ///<summary> ///MyMathServicegetsaWebRequestandsetsthedefaultcredentials ///andacustomheaderontherequest.Ifyouneedcontroloverthe ///HTTPsemanticsofaWebservicerequestitismuchbettertooverride ///theautogeneratedproxyclasssothatyoudontlosethechangeswhen ///theproxygetsregenerated. ///</summary> classMyMathService:WebServicesClient.localhost.MathService { //GetWebRequestiscalledbeforetheSOAPrequestissent protectedoverrideWebRequestGetWebRequest(Uriurl) { //CreatearequestbasedonthesuppliedURI WebRequestrequest=WebRequest.Create(url); //Setdefaultcredentials request.Credentials=CredentialCache.DefaultCredentials; //Setacustomheadervalueontherequest request.Headers["custom-header"]= "caleb"; returnrequest; } } 
Visual Basic .NET
 ImportsSystem ImportsSystem.Net 


Network Programming for the Microsoft. NET Framework
Network Programming for the MicrosoftВ® .NET Framework (Pro-Developer)
ISBN: 073561959X
EAN: 2147483647
Year: 2003
Pages: 121

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net