- What is the .NET Framework?
- Fundamental Concepts
- Configuring Your Environment
- Internet Applications and Request Processing
- Creating a Web Service
- Running the Code Listings
- Summary
- Q&A
- Workshop
This chapter is from the book
This chapter is from the book
This chapter is from the book
Internet Applications and Request Processing
Before running any of the code listings in this book, you need a good understanding of how the Web server executes your Web page or Web Service. Internet applications such as dynamic Web sites or custom Web Services are concerned with one task—processing user requests. These requests come as HTTP requests from a client Web browser or as SOAP requests from a Web Service client program. Web Services can also be called from a Web browser, in addition to being called by custom client programs. In most cases, a custom client is needed to do anything useful with the data that a Web Service returns.
HTTP stands for Hypertext Transfer Protocol. A protocol is simply an agreed-on method for transmitting data—in this case, for transmitting and receiving data to Web servers. HTTP requests are streams of text characters sent over the Internet, each containing a request to download a Web page's contents. A typical HTTP request looks like this:
GET http://www.mycompany.com/index.htm HTTP 1.1
This request asks the Web server residing on the machine named http://www.mycompany.com to send back the page called index.htm.
SOAP stands for Simple Object Access Protocol. Just like HTTP, it's another standard for sending and receiving data from a server computer. In fact, SOAP relies on HTTP and adds additional levels of sophistication to permit more complex interactions. In most cases, SOAP requests are sent to a Web server to handle the request. SOAP requests and responses are customized for calling functions instead of returning Web pages. Day 13 will explore SOAP requests and responses in detail.
Dynamic Pages Process Overview
So what happens when a user points a Web browser to one of your pages? The Web browser generates an HTTP request for the specific page the user wants to view. The Web server, which is listening at all times for HTTP requests, takes the request and looks up the file for that specific page. If the page ends in an .htm or .html extension, the Web browser simply returns the contents for the file exactly.
Of course, Web servers can do more than just display files ending in an .htm extension. Currently, you can find Web sites that do all sorts of complicated tasks, such as a bank's online check writing service, which will let you pay all your bills using just a Web browser. How do such "dynamic" Web sites work?
The trick to the process is that dynamic pages that contain complex program logic use a different file extension. For instance, the next few chapters will detail ASP.NET pages, which end in an .aspx extension. When the Web server sees a request for such a page, it doesn't read the file. Instead, it knows to hand off the HTTP request to .NET (specifically, to the ASP.NET process), and let ASP.NET take over the task of processing the page and sending the response. The result is that ASP.NET executes your code, which performs whatever tasks it was designed for. Figure 1.1 illustrates how the process works.
){kind=link}
Figure 1.1. Dynamic page processing and Web servers.
Web Services Processing Overview
Web Services perform a similar task to dynamic Web sites because Web Services simply respond to client requests from the Internet and return data. As we mentioned in the preceding section, rather than receive HTTP requests, Web Services receive SOAP requests. Each SOAP request contains the name of a particular function, such as GetMyAppointments, and a parameter for the function, such as today's date. Each SOAP response contains data that the function returns. For example, the GetMyAppointment method might return a data structure that lists all of a user's scheduled appointments for a certain day.
SOAP allows client programs to pass in almost any kind of data structure to the Web Service; that's why Web Services use SOAP. Similarly, Web Services can return almost any kind of data structure to a client program using SOAP.
Most Web Services still use a Web server to communicate with the outside world. After all, Web servers are good at listening for requests and spitting back data. .NET Web Services use ASP.NET to handle the SOAP requests and translate them into a data structure that they can use. This process works the same way as dynamic Web pages. All .NET Web Services end in the file extension .asmx. Internet Information Services knows that it should hand off all requests ending in .asmx to ASP.NET, which then takes over and processes the SOAP request and hands it to your custom Web Service code. Figure 1.2 shows a diagram of how the process works.
){kind=link}
Figure 1.2. Web Services and Web servers.
If this whole process sounds a little complicated, you can take comfort in the fact that all the ugly details around SOAP requests and responses are taken care of by the .NET Framework and ASP.NET. You don't have to worry about how to send data structures to Web Services or how to decipher a SOAP request in your Web Service code. You therefore can concentrate on getting your own project done quickly.