This post originated from an RSS feed registered with .NET Buzz
by Christian Weyer.
Original Post: The Web services empire strikes back - Inner Workings
Feed Title: Christian Weyer: Web Services & .NET
Feed URL: http://www.asp.net/err404.htm?aspxerrorpath=/cweyer/Rss.aspx
Feed Description: Philosophizing about and criticizing the brave new world ...
Let's now take a look at how ASMX Web services work inside. An important point here is how and where our Web services live. Which is the responsible entity to execute, control and shutdown all actions related to Web services lifetime. This leads us to the notion of an application home, a host where our Web services get executed in. And this is the first new piece in ASMX v2.
'WebHost' Think about a feature that all web applications (including usual web apps such as ASP.NET pages) and services have in common. If we abstract unnecessary details away, they both are communicating via messages (HTML vs. XML) and the applications usually get activated by messages. So a logical step into the right direction would be to rely on an activation model that relies itself on messages. This is where the new codename 'WebHost' model comes around. WebHost is a unified model for hosting Web applications and services. It is a joint project of the ASP.NET and Indigo teams. Additionally, IIS is providing the operating system infrastructure to activate, monitor and manage worker processes within which ASP.NET applications and Web services and Indigo services run. Future version of WebHost will be able to receive messages on other protocols than the standard HTTP. But the first release will run hand in hand with IIS 5.x and IIS 6 and will therefore just support HTTP. As you can see in Figure 1, WebHost sits right behind the ISAPI DLL in IIS that implements the redirection of ASP.NET related HTTP messages to the actual ASP.NET runtime. This runtime either is hosted in the aspnet_wp.exe process for IIS 5.x or in a separate w3wp.exe worker process in the case of IIS 6. WebHost delivers a so called message dispatcher functionality that is able to dispatch the message to the correct message processor. In our case this is the ASP.NET HTTP runtime, but in future this can be Indigo or any other 'runtime' that plugs into this architecture.
Figure 1: Basic 'WebHost' architecture overview
WebHost is an ongoing project. Bits and pieces of its functionality will be released with every major release to come. So some bits of it will come with the upcoming Whidbey version, other bits with Longhorn.
Pipeline Architecture Once a message has gone through WebHost's message dispatcher it will arrive at the HTTP runtime. The ASP.NET runtime consists of a pipeline that has several Http handlers that ultimately handle the message they were designed and implemented for. An example are SOAP messages that get transported to an implementation located in a .asmx file. The responsible HTTP handler is registered in the machine.config file and knows how to handle SOAP messages and how to send SOAP messages back. This is the actual heart of ASMX. Figure 2 depicts this situation while also showing a bunch of HTTP modules that can get in to the way of a SOAP message over HTTP until it receives its final destination, the .asmx endpoint.
Figure 2: ASP.NET pipeline with HttpHandler for handling Web services requests
HTTP handlers can process a HTTP packet transparently for the HTTP handler and are available for any handler configured in the HTTP pipeline. Typical scenarios are the handling of authentication or session management on HTTP level. On the other side, SoapExtensions are an extensibility mechanism for the ASMX engine. With the help of a SoapExtension you can work with the raw SOAP message in any way you want. E.g., a SoapExtension can be used to de- and encrypt messages, to compress and decompress SOAP Envelopes or just to take the message stream and log it to a file or database. The possibilities are open to your fantasy and potential. So to sum up, once a SOAP message, delivered via HTTP and traveling through the ASP.NET pipeline, reaches the final .asmx endpoint implementation, the ASMX engine can handle all the necessary XML to object and vice versa processing in order to provide the powerful features mentioned in the first part of this series.
Previous Topic
