The HTTP Pipeline Model


The programming model for Web Services defines applications that communicate through messages. This isn t a new concept for Web-based applications. The majority of Internet-based applications communicate through three basic HTTP message types: PUT, POST, and GET. Web Services are an extension to this model and are designed to enable the Internet to provide not only information but also application services. Within the .NET Framework, the set of types defined within the System.Web namespace is designed to support all server-side HTTP programming using a pipeline model of message processing. This is a general-purpose framework that defines a set of processing types to receive and send HTTP requests through IIS.

Each of these processing types is mapped against a set of file extensions stored in the IIS metabase. The metabase is a hierarchical store of configuration information and schema that are used to configure IIS. During the installation of the .NET Framework, a set of known file extensions ”including ASP.NET pages (.aspx) and Web Services (.asmx) ”is registered with IIS. The metabase is organized into a hierarchy of nodes, keys, and sub-keys in a structure that mirrors that of the physical IIS sites. Nodes are the top level and represent a specific Web site or virtual directory within IIS. Underneath a node are one or more keys that contain a specific IIS configuration value for the site defined within the node. As new sites or directories are created, each of these properties inherits its initial values from a similar property stored at a higher level in the hierarchy. Using Windows Server 2000 or Windows XP, you can configure each of these settings and properties through the Internet Services Manager Snap In for the Microsoft Management Console, as shown in Figure 4.1.

click to expand
Figure 4.1: The IIS Management Console.

Windows Server 2003 provides a new feature called edit-while-running, which enables you to export the metabase into an editable XML file that uses an XSD based on IIS. To turn on this feature, select the Enable Direct Metabase Edit checkbox on the Properties tab of the IIS Properties window, as shown in Figure 4.2.

click to expand
Figure 4.2: Enabling edit-while-running within IIS 6.

 CD-ROM     Enabling this feature exports the entire binary metabase structure to an XML file stored in the c:\windows\system\inetsvr directory. By default, this file is named  metabase.xml . Any changes to this XML configuration file are automatically applied to IIS. In order to edit this file, system administrators can use a standard XML editor or notepad. Due to schema restrictions, InfoPath can only read and report from the file, as shown in Figure 4.3, but this can make a handy tool for system administrators. Consult the CD-ROM in the Chapter 4 samples directory for the InfoPath application (\Code\Chapter 4\IISMetaEdit\IISMetaRead.xsn).

click to expand
Figure 4.3: Using InfoPath to read the IIS metabase.

When IIS receives a processing request, it matches the file extension of the target URL to determine the type of executable to run. The .aspx or .asmx requests are associated with the aspnet_isapi.dll, as shown in the IIS Properties window in Figure 4.4.

click to expand
Figure 4.4: An executable file association as seen in IIS.

The aspinet_isapi.dll is an ISAPI (Internet Server API) DLL extension that maps to the address space of the inetinfo.exe process. The inetinfo.exe process acts as a forwarding agent that passes the incoming message to the ASP.NET application worker process, aspnet_wp.exe, which performs the actual request processing. This process then instantiates an instance of the HTTPRuntime class as an entry point into the HTTP pipeline. The redesign of the IIS 6.0 kernel mode HTTP listener within Windows Server 2003 enables you to directly pass requests to the worker process without involving the inetinfo.exe. The major advantage is that this offers better performance and security over both IIS 5.0 and Windows Server 2000.

In the pipeline, the HTTP handlers match the request to a compiled assembly. The association of both ASP.NET pages and Web Services is in the < httphandlers > section of the .NET Framework global machine configuration file and by default contains the code in Listing 4.1.

Listing 4.1:
start example
 <httpHandlers>     <add verb="*" path="*.aspx" type="System.Web.UI.PageHandlerFactory"/>   <add verb="*" path="*.ashx" type="System.Web.UI.SimpleHandlerFactory"/>     <add verb="*" path="*.asmx"      type="System.Web.Services.Protocols.WebServiceHandlerFactory,      System.Web.Services, Version=1.0.5000.0, Culture=neutral,      PublicKeyToken=b03f5f7f11d50a3a" validate="false"/> </httpHandlers> 
end example
 

Once the request is in the pipeline, the Framework maps it to the WebServiceHandlerFactory , which compiles the associated source code into a class, instantiates it, and then using reflection translates the incoming SOAP messages into a method invocation. The use of reflection allows you to programmatically inspect the assembly or class to determine the proper data types and method calls. This is what enables the direct mapping of a SOAP message to a method invocation.

Note  

Reflection is part of the System.Reflection namespace and contains classes and interfaces that provide a managed view of the currently loaded types, methods , and fields that can dynamically create and invoke types.

The .NET Framework provides two ways to develop XML Web Services. First is using the low-level custom IHTTPHandlers , which plug directly into the HTTP pipeline. This is the more code- intensive approach of the two and requires programmatic control of the system XML APIs to process the SOAP envelopes in the HTTP body and custom WSDL to describe the entire implementation. The preferred method of development and the one used here is the WebMethods Framework. When this is installed, the .NET Framework implements a custom IHTTPHandler class for Web Services called the WebServiceHandle . This handler provides a customizable XML, XSD, SOAP, and WSDL template that we used in the first chapter to develop the reporting Web Service.

The WebMethods Framework

Web Services are implemented using classes. Within a class, the developer can control the XML namespaces for the Web Service along with an optional string that describes the class. When the Web Service is deployed within a production environment, it is important to match the namespace to those used with the enterprise. The following is the default namespace used by Visual Studio in a default project:

 <System.Web.Services.WebService(Namespace:="http:// tempuri.org/InterviewFeedback/Service1")> _Public Class Feedback 
Note  

Visual Studio.NET uses a default namespace of http://tempuri.org . It is important to remember to change this name before you move applications into your production environment.

Methods of a class implemented within an XML Web Service project can t automatically communicate over the Web. The WebMethods Framework uses the < WebMethod() > attribute to identify and map an incoming SOAP message to a specific .NET class method. This attribute is derived from the System.Web.Services namespace and marks public methods that you can call from a remote Web client. Once the attribute is added to a public method, the component becomes part of the service architecture.




Programming Microsoft Infopath. A Developers Guide
Programming Microsoft Infopath: A Developers Guide
ISBN: 1584504536
EAN: 2147483647
Year: 2006
Pages: 111
Authors: Thom Robbins

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