HTTP协议简介

HTTP协议简介

在TCP/IP体系结构中，HTTP属于应用层协议，位于TCP/IP协议的顶层。浏览Web时，浏览器通过HTTP协议与Web服务器交换信息。这些信息（文档）类型的格式由MIME定义。

HTTP协议具有以下的特点：

1. HTTP按客户/服务器模式工作
   HTTP支持客户（一般情况是浏览器）与服务器的通讯，相互传输数据。
   HTTP定义的事务处理由以下四步组成：
   • 客户与服务器建立连接；
   • 客户向服务器提出请求；
   • 如果请求被接受，则服务器送回响应，在响应中包括状态码和所需的文件；
   • 客户与服务器断开连接

   一次HTTP操作称为一次事务（transaction）。

2. HTTP是无状态的
   也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。
3. HTTP使用元信息作为头标
   HTTP对所有事务都加了头标（header）。也就是说，在主要数据前加上一块信息，称为元信息（metainformation）。它使服务器能够提供正在传送数据的有关信息。例如，传送对象是哪种类型，是用哪种语言书写的等。
   从功能上讲，HTTP支持四类元信息：一般信息头标、请求头标、响应头标和实体头标。
4. HTTP支持两种请求和响应格式
   HTTP由不同的两部分组成，一是从浏览器发往服务器的请求，二是服务器对客户的响应。
   HTTP支持两种请求和响应，即简单请求与完全请求和简单响应与完全响应。
5. HTTP是基于文本的简单协议

HTTP的请求

HTTP的常用请求方法：

HTTP请求的格式如下所示：

＜request-line＞
＜headers＞
＜blank line＞
[＜request-body＞]

在HTTP请求中，第一行必须是一个请求行（request line），用来说明请求类型、要访问的资源以及使用的HTTP版本。紧接着是一个首部（header）小节，用来说明服务器要使用的附加信息。在首部之后是一个空行，再此之后可以添加任意的其他数据[称之为主体（body）]。
在HTTP中，定义了大量的请求类型，不过Ajax开发人员关心的只有GET请求和POST请求。只要在Web浏览器上输入一个URL，浏览器就将基于该URL向服务器发送一个GET请求，以告诉服务器获取并返回什么资源。对于www.wzu.edu.cn的GET请求如下所示：

GET / HTTP/1.1
Host: www.wzu.edu.cn 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Connection: Keep-Alive 

请求行的第一部分说明了该请求是GET请求。该行的第二部分是一个斜杠（/），用来说明请求的是该域名的根目录。该行的最后一部分说明使用的是HTTP 1.1版本（另一个可选项是1.0）。那么请求发到哪里去呢？这就是第二行的内容。
第2行是请求的第一个首部，HOST。首部HOST将指出请求的目的地。结合HOST和上一行中的斜杠（/），可以通知服务器请求的是www.wzu.edu.cn/（HTTP 1.1才需要使用首部HOST，而原来的1.0版本则不需要使用）。第三行中包含的是首部User-Agent，服务器端和客户端脚本都能够访问它，它是浏览器类型检测逻辑的重要基础。该信息由你使用的浏览器来定义（在本例中是Firefox 1.0.1），并且在每个请求中将自动发送。最后一行是首部Connection，通常将浏览器操作设置为Keep-Alive（当然也可以设置为其他值，但这已经超出了本书讨论的范围）。注意，在最后一个首部之后有一个空行。即使不存在请求主体，这个空行也是必需的。

如果要获取一个诸如http://www.wzu.edu.cn/books的www.wzu.edu.cn域内的页面，那么该请求可能类似于：

GET /books/ HTTP/1.1
Host: www.wzu.edu.cn
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Connection: Keep-Alive

注意只有第一行的内容发生了变化，它只包含URL中www.wzu.edu.cn后面的部分。

要发送GET请求的参数，则必须将这些额外的信息附在URL本身的后面。其格式类似于：

GET /books/?name=Professional%20Ajax HTTP/1.1
Host: www.wzu.edu.cn
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Connection: Keep-Alive

另一方面，POST请求在请求主体中为服务器提供了一些附加的信息。通常，当填写一个在线表单并提交它时，这些填入的数据将以POST请求的方式发送给服务器。

以下就是一个典型的POST请求：

POST / HTTP/1.1
Host: www.wzu.edu.cn
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Connection: Keep-Alive
name=Professional%20Ajax&publisher=Wiley

从上面可以发现， POST请求和GET请求之间有一些区别。首先，请求行开始处的GET改为了POST，以表示不同的请求类型。你会发现首部Host和User-Agent仍然存在，在后面有两个新行。其中首部Content-Type说明了请求主体的内容是如何编码的。浏览器始终以application/ x-www-form- urlencoded的格式编码来传送数据，这是针对简单URL编码的MIME类型。首部Content-Length说明了请求主体的字节数。在首部Connection后是一个空行，再后面就是请求主体。与大多数浏览器的POST请求一样，这是以简单的“名称—值”对的形式给出的，其中name是Professional Ajax，publisher是Wiley。你可以以同样的格式来组织URL的查询字符串参数。

正如前面所提到的，还有其他的HTTP请求类型，它们遵从的基本格式与GET请求和POST请求相同。下一步我们来看看服务器将对HTTP请求发送什么响应。

HTTP响应

如下所示，HTTP响应的格式与请求的格式十分类似：

＜status-line＞
＜headers＞
＜blank line＞
[＜response-body＞]

正如你所见，在响应中唯一真正的区别在于第一行中用状态信息代替了请求信息。状态行（status line）通过提供一个状态码来说明所请求的资源情况。以下就是一个HTTP响应的例子：

HTTP/1.1 200 OK
Date: Sat, 31 Dec 2005 23:59:59 GMT
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 122

＜html＞
＜head＞
＜title＞Wrox Homepage＜/title＞
＜/head＞
＜body＞
＜!-- body goes here --＞
＜/body＞
＜/html＞

在本例中，状态行给出的HTTP状态代码是200，以及消息OK。状态行始终包含的是状态码和相应的简短消息，以避免混乱。最常用的状态码有：

• 200 (OK): 找到了该资源，并且一切正常。
• 304 (NOT MODIFIED): 该资源在上次请求之后没有任何修改。这通常用于浏览器的缓存机制。
• 401 (UNAUTHORIZED):客户端无权访问该资源。这通常会使得浏览器要求用户输入用户名和密码，以登录到服务器。
• 403 (FORBIDDEN):客户端未能获得授权。这通常是在401之后输入了不正确的用户名或密码。
• 404 (NOT FOUND):在指定的位置不存在所申请的资源。

在状态行之后是一些首部。通常，服务器会返回一个名为Date的首部，用来说明响应生成的日期和时间（服务器通常还会返回一些关于其自身的信息，尽管并非是必需的）。接下来的两个首部大家应该熟悉，就是与POST请求中一样的Content-Type和Content-Length。在本例中，首部Content-Type指定了MIME类型HTML（text/html），其编码类型是ISO-8859-1（这是针对美国英语资源的编码标准）。响应主体所包含的就是所请求资源的HTML源文件（尽管还可能包含纯文本或其他资源类型的二进制数据）。浏览器将把这些数据显示给用户。
注意，这里并没有指明针对该响应的请求类型，不过这对于服务器并不重要。客户端知道每种类型的请求将返回什么类型的数据，并决定如何使用这些数据。

与HTTP相关类的简介

WebRequest类

WebRequest 是 .NET Framework 的用于访问 Internet 数据的请求/响应模型的抽象基类。使用该请求/响应模型的应用程序可以用协议不可知的方式从 Internet 请求数据。在这种方式下，应用程序处理 WebRequest 类的实例，而协议特定的子类则执行请求的具体细节。

请求从应用程序发送到某个特定的 URI，如服务器上的 Web 页。URI 从一个为应用程序注册的 WebRequest 子代列表中确定要创建的适当子类。注册 WebRequest 子代通常是为了处理某个特定的协议（如 HTTP 或 FTP），但是也可以注册它以处理对特定服务器或服务器上的路径的请求。

由于 WebRequest 类是一个抽象类，所以 WebRequest 实例在运行时的实际行为由 WebRequest.Create 方法所返回的子类确定。

注意 使用 Create 方法初始化新的 WebRequest 实例。不要使用 WebRequest 构造函数。

下面的示例说明如何创建 WebRequest 实例并返回响应。

// Initialize the WebRequest.
WebRequest myRequest = WebRequest.Create("http://www.contoso.com");
// Return the response. 
WebResponse myResponse = myRequest.GetResponse();
// Code to use the WebResponse goes here.
// Close the response to free resources.
myResponse.Close();

WebResponse类

WebResponse 类是抽象（在 Visual Basic 中为 MustInherit）基类，协议特定的响应类从该抽象基类派生。应用程序可以使用 WebResponse 类的实例以协议不可知的方式参与请求和响应事务，而从 WebResponse 派生的协议特定的类携带请求的详细信息。

客户端应用程序不直接创建 WebResponse 对象，而是通过调用 WebRequest 实例上的 GetResponse 方法来创建它。

下面的示例从 WebRequest 创建 WebResponse 实例。

// Initialize the WebRequest.
WebRequest myRequest = WebRequest.Create("http://www.contoso.com");
// Return the response. 
WebResponse myResponse = myRequest.GetResponse();
// Code to use the WebResponse goes here.
// Close the response to free resources.
myResponse.Close();

HttpWebRequest类

HttpWebRequest 类对 WebRequest 中定义的属性和方法提供支持，也对使用户能够直接与使用 HTTP 的服务器交互的附加属性和方法提供支持。

不要使用 HttpWebRequest 构造函数。使用 WebRequest.Create 方法初始化 HttpWebRequest 的一个新实例。如果 URI 的方案是 http:// 或 https://，则 Create 将返回 HttpWebRequest 实例。

GetResponse 方法向 RequestUri 属性中指定的 Internet 资源发出同步请求并返回包含该响应的 HttpWebResponse 实例。可以使用 BeginGetResponse 和 EndGetResponse 方法对 Internet 资源发出异步请求。

当要向 Internet 资源发送数据时，GetRequestStream 方法返回用于发送数据的Stream实例。BeginGetRequestStream 和 EndGetRequestStream 方法提供对发送数据流的异步访问。

下面的示例为 URI http://www.contoso.com/ 创建 HttpWebRequest。

HttpWebRequest myReq = (HttpWebRequest)WebRequest.Create("http://www.contoso.com/");

HttpWebResponse类

此类包含对 WebResponse 类中的属性和方法的 HTTP 特定用法的支持。HttpWebResponse 类用于生成发送 HTTP 请求和接收 HTTP 响应的 HTTP 独立客户端应用程序。

注意：不要混淆 HttpWebResponse 和 HttpResponse；后者用于 ASP.NET 应用程序，而且它的方法和属性是通过 ASP.NET 的内部 HttpResponse 对象公开的。

决不要直接创建 HttpWebResponse 类的实例。而应当使用通过调用 HttpWebRequest.GetResponse 所返回的实例。

从 Internet 资源返回的公共标头信息公开为该类的属性。有关完整的列表，请参见下表。可以从 Headers 属性以名称/值对的形式读取其他标头。

下表显示可以通过 HttpWebResponse 类的属性使用的公共 HTTP 标头。

通过调用 GetResponseStream 方法，以 Stream 的形式返回来自 Internet 资源的响应的内容。

下面的示例返回 HttpWebRequest 的 HttpWebResponse：

HttpWebRequest HttpWReq = (HttpWebRequest)WebRequest.Create("http://www.contoso.com");
HttpWebResponse HttpWResp = (HttpWebResponse)HttpWReq.GetResponse();
// Insert code that uses the response object.
HttpWResp.Close()

Uri类

URI 是 Internet 上可由应用程序使用的资源的简洁表示形式。Uri 类定义了属性和方法来处理 URI，包括分析、比较和组合。Uri 类属性是只读的，修改 Uri 实例需使用 UriBuilder 类。

Uri 类只存储绝对 URI（例如“http://www.contoso.com/index.htm”）。相对 URI（例如“/new/index.htm”）必须相对于基 URI 展开，这样才是绝对的。提供了 MakeRelative 方法在必要时将绝对 URI 转换为相对 URI。

URI 由转义编码存储为规范化 URI，所有 ASCII 值大于 127 的字符都被替换为它们的等效十六进制数。为使 URI 具有规范化格式，Uri 构造函数执行以下步骤。

• 将 URI 方案转换为小写。
• 将主机名转换为小写。
• 移除默认端口号和空端口号。
• 移除多余的段（如“/”和“/test”段）以简化 URI。

使用 ToString 方法，可以将 Uri 类的内容从转义编码的 URI 引用转换为可读的 URI 引用。

一些 URI 包括段标识符或查询。段标识符是 URI 中跟在数字符号 (#) 后的任何文本，存储在 Fragment 属性中。查询信息是 URI 中跟在问号 (?) 后的任何文本，存储在 Query 属性中。

注意：URI 类支持使用以下格式的 IP 地址：四组表示法的 IPv4 协议和冒号分隔的十六进制 IPv6 协议。请记住在 IPv6 地址两边括上方括号，如 http://[::1]。

下面的示例创建 Uri 类的实例，并用它来创建 WebRequest。

Uri siteUri = new Uri("http://www.contoso.com/");
WebRequest wr = WebRequest.Create(siteUri);

虽然有越来越多的网站在应用AJAX技术进行开发，但是构建一个复杂的AJAX应用仍然是一个难题。造成这些困难的主要原因是什么呢？是与服务器的异步通信问题？还是GUI程序设计问题呢？通常这两项工作都是由桌面程序来完成的，那究竟为何开发一个可以实现同样功能的AJAX应用就这么困难呢？

AJAX 开发中的难题

让我们通过一个简单的例子来认识这个问题。假设你要建立一个树形结构的公告栏系统(BBS)，它可以根据用户请求与服务器进行交互，动态加载每篇文章的信息，而不是一次性从服务器载入所有文章信息。每篇文章有四个相关属性：系统中可以作为唯一标识的ID、发贴人姓名、文章内容以及包含其所有子文章ID的数组信息。首先假定有一个名为getArticle()的函数可以加载一篇文章信息。该函数接收的参数是要加载文章的ID，通过它可从服务器获取文章信息。它返回的对象包含与文章相关的四条属性：id，name，content和children。例程如下：

function ( id ) {
     var a = getArticle(id);
     document.writeln(a.name + "
" + a.content);
 } 

然而你也许会注意到，重复用同一个文章ID调用此函数，需要与服务器之间进行反复且无益的通信。想要解决这个问题，可以考虑使用函数 getArticleWithCache()，它相当于一个带有缓存能力的getArticle()。在这个例子中，getArticle()返回的数据只是作为一个全局变量被保存下来：

var cache = {};
 function getArticleWithCache ( id ) {
     if ( !cache[id] ) {
         cache[id] = getArticle(id);
     }
     return cache[id];
 } 

现在已将读入的文章缓存起来，让我们再来考虑一下函数backgroundLoad()，它应用我们上面提到的缓存机制加载所有文章信息。其用途是，当读者在阅读某篇文章时，从后台预加载它所有子文章。因为文章数据是树状结构的，所以很容易写一个递归的算法来遍历树并且加载所有的文章：

function backgroundLoad ( ids ) {
     for ( var i=0; i < ids.length; i++ ) {
         var a = getArticleWithCache(ids[i]);
         backgroundLoad(a.children);
     }
 } 

backgroundLoad ()函数接收一个ID数组作为参数，然后通过每个ID调用前面定义过的getArticldWithCache()方法，这样就把每个ID对应的文章缓存起来。之后再通过已加载文章的子文章ID数组递归调用backgroundLoad()方法，如此整个文章树就被缓存起来。

到目前为止，一切似乎看起来都很完美。然而，只要你有过开发AJAX应用的经验，你就应该知晓这种幼稚的实现方法根本不会成功，这个例子成立的基础是默认 getArticle()用的是同步通信。可是，作为一条基本原则，JavaScript要求在与服务器进行交互时要用异步通信，因为它是单线程的。就简单性而言，把每一件事情（包括GUI事件和渲染）都放在一个线程里来处理是一个很好的程序模型，因为这样就无需再考虑线程同步这些复杂问题。另一方面，他也暴露了应用开发中的一个严重问题，单线程环境看起来对用户请求响应迅速，但是当线程忙于处理其它事情时(比如说调用getArticle())，就不能对用户的鼠标点击和键盘操作做出响应。

如果在这个单线程环境里进行同步通信会发生什么事情呢？同步通信会中断浏览器的执行直至获得通信结果。在等待通信结果的过程中，由于服务器的调用还没有完成，线程会停止响应用户并保持锁定状态直到调用返回。因为这个原因，当浏览器在等待服务器响应时它不能对用户行为作出响应，所以看起来像是冻结了。当执行 getArticleWithCache()和backgroundLoad()会有同样的问题，因为它们都是基于getArticle()函数的。由于下载所有的文章可能会耗费很可观的一段时间，因此对于backgroundLoad()函数来说，浏览器在此段时间内的冻结就是一个很严重的问题——既然浏览器都已经冻结，当用户正在阅读文章时就不可能首先去执行后台预加载数据，如果这样做连当前的文章都没办法读。

如上所述，既然同步通信在使用中会造成如此严重的问题，JavaScript就把异步通信作为一条基本原则。因此，我们可以基于异步通信改写上面的程序。 JavaScript要求以一种事件驱动的程序设计方式来写异步通信程序。在很多场合中，你都必须指定一个回调程序，一旦收到通信响应，这个函数就会被调用。例如，上面定义的getArticleWithCache()可以写成这样：

var cache = {};
 function getArticleWithCache ( id, callback ) {
     if ( !cache[id] ) {
         callback(cache[id]);
     } else {
         getArticle(id, function( a ){
             cache[id] = a;
             callback(a);
         });
     }
 } 

这个程序也在内部调用了getArticle()函数。然而需要注意的是，为异步通信设计的这版getArticle()函数要接收一个函数作为第二个参数。当调用这个getArticle()函数时，与从前一样要给服务器发送一个请求，不同的是，现在函数会迅速返回而非等待服务器的响应。这意味着，当执行权交回给调用程序时，还没有得到服务器的响应。如此一来，线程就可以去执行其它任务直至获得服务器响应，并在此时调用回调函数。一旦得到服务器响应， getArticle()的第二个参数作为预先定义的回调函数就要被调用，服务器的返回值即为其参数。同样的，getArticleWithCache ()也要做些改变，定义一个回调参数作为其第二个参数。这个回调函数将在被传给getArticle()的回调函数中调用，因而它可以在服务器通信结束后被执行。

单是上面这些改动你可能已经认为相当复杂了，但是对backgroundLoad()函数做得改动将会更复杂，它也要被改写成可以处理回调函数的形式：

function backgroundLoad ( ids, callback ) {
     var i = 0;
     function l ( ) {
         if ( i < ids.length ) {
             getArticleWithCache(ids[i++], function( a ){
                 backgroundLoad(a.children, l);
             });
         } else {
             callback();
         }
     }
     l();
 } 

改动后的backgroundLoad()函数看上去和我们以前的那个函数已经相去甚远，不过他们所实现的功能并无二致。这意味着这两个函数都接受ID数组作为参数，对于数组里的每个元素都要调用getArticleWithCache()，再应用已经获得子文章ID递归调用backgroundLoad ()。不过同样是对数组的循环访问，新函数中的就不太好辨认了，以前的程序中是用一个for循环语句完成的。为什么实现同样功能的两套函数是如此的大相径庭呢？

这个差异源于一个事实：任何函数在遇到有需要同服务器进行通信情况后，都必须立刻返回，例如getArticleWithCache()。除非原来的函数不在执行当中，否则应当接受服务器响应的回调函数都不能被调用。对于JavaScript，在循环过程中中断程序并在稍后从这个断点继续开始执行程序是不可能的，例如一个for语句。因此，本例利用递归传递回调函数实现循环结构而非一个传统循环语句。对那些熟悉连续传送风格(CPS)的人来说，这就是一个 CPS的手动实现，因为不能使用循环语法，所以即便如前面提到的遍历树那么简单的程序也得写得很复杂。与事件驱动程序设计相关的问题是控制流问题：循环和其它控制流表达式可能比较难理解。

这里还有另外一个问题：如果你把一个没有应用异步通信的函数转换为一个使用异步通信的函数，那么重写的函数将需要一个回调函数作为新增参数，这为已经存在的APIs造成了很大问题，因为内在的改变没有把影响限于内部，而是导致整体混乱的APIs以及API的其它使用者的改变。

造成这些问题目的根本原因是什么呢？没错，正是JavaScript单线程机制导致了这些问题。在单线程里执行异步通信需要事件驱动程序设计和复杂的语句。如果当程序在等待服务器的响应时，有另外一个线程可以来处理用户请求，那么上述复杂技术就不需要了。

试试多线程编程

让我来介绍一下Concurrent.Thread，它是一个允许JavaScript进行多线程编程的库，应用它可以大大缓解上文提及的在AJAX开发中与异步通信相关的困难。这是一个用JavaScript写成的免费的软件库，使用它的前提是遵守Mozilla Public License和GNU General Public License这两个协议。你可以从他们的网站 下载源代码。

马上来下载和使用源码吧！假定你已经将下载的源码保存到一个名为Concurrent.Thread.js的文件夹里，在进行任何操作之前，先运行如下程序，这是一个很简单的功能实现：

<script type="text/javascript" src="Concurrent.Thread.js"></script>
 <script type="text/javascript">
     Concurrent.Thread.create(function(){
         var i = 0;
         while ( 1 ) {
             document.body.innerHTML += i++ + "<br>";
         }
     });
 </script>

执行这个程序将会顺序显示从0开始的数字，它们一个接一个出现，你可以滚屏来看它。现在让我们来仔细研究一下代码，他应用while(1)条件制造了一个不会中止的循环，通常情况下，象这样不断使用一个并且是唯一一个线程的JavaScript程序会导致浏览器看起来象冻结了一样，自然也就不会允许你滚屏。那么为什么上面的这段程序允许你这么做呢？关键之处在于while(1)上面的那条Concurrent.Thread.create()语句，这是这个库提供的一个方法，它可以创建一个新线程。被当做参数传入的函数在这个新线程里执行，让我们对程序做如下微调：

<script type="text/javascript" src="Concurrent.Thread.js"></script>
 <script type="text/javascript">
     function f ( i ){
         while ( 1 ) {
             document.body.innerHTML += i++ + "<br>";
         }
     }
     Concurrent.Thread.create(f, 0);
     Concurrent.Thread.create(f, 100000);
 </script> 

在这个程序里有个新函数f()可以重复显示数字，它是在程序段起始定义的，接着以f()为参数调用了两次create()方法，传给create()方法的第二个参数将会不加修改地传给f()。执行这个程序，先会看到一些从0开始的小数，接着是一些从100,000开始的大数，然后又是接着前面小数顺序的数字。你可以观察到程序在交替显示小数和大数，这说明两个线程在同时运行。

让我来展示Concurrent.Thread的另外一个用法。上面的例子调用create()方法来创建新线程。不调用库里的任何APIs也有可能实现这个目的。例如，前面那个例子可以这样写：

<script type="text/javascript" src="Concurrent.Thread.js"></script>
 <script type="text/x-script.multithreaded-js">
     var i = 1;
     while ( 1 ) {
         document.body.innerHTML += i++ + "<br>";
     }
 </script> 

在script 标签内，很简单地用JavaScript写了一个无穷循环。你应该注意到标签内的type属性，那里是一个很陌生的值(text/x- script.multithreaded-js)，如果这个属性被放在script标签内，那么Concurrent.Thread就会在一个新的线程内执行标签之间的程序。你应当记住一点，在本例一样，必须将Concurrent.Thread库包含进来。

有了Concurrent.Thread，就有可能自如的将执行环境在线程之间进行切换，即使你的程序很长、连续性很强。我们可以简要地讨论下如何执行这种操作。简言之，需要进行代码转换。粗略地讲，首先要把传递给create()的函数转换成一个字符串，接着改写直至它可以被分批分次执行。然后这些程序可以依照调度程序逐步执行。调度程序负责协调多线程，换句话说，它可以在适当的时候做出调整以便每一个修改后的函数都会得到同等机会运行。 Concurrent.Thread实际上并没有创建新的线程，仅仅是在原本单线程的基础上模拟了一个多线程环境。

虽然转换后的函数看起来是运行在不同的线程内，但是实际上只有一个线程在做这所有的事情。在转换后的函数内执行同步通信仍然会造成浏览器冻结，你也许会认为以前的那些问题根本就没有解决。不过你不必耽心，Concurrent.Thread提供了一个应用JavaScript 的异步通信方式实现的定制通信库，它被设计成当一个线程在等待服务器的响应时允许其它线程运行。这个通信库存于 Concurrent.Thread.Http下。它的用法如下所示：

<script type="text/javascript" src="Concurrent.Thread.js"></script>
 <script type="text/x-script.multithreaded-js">
     var req = Concurrent.Thread.Http.get(url, ["Accept", "*"]);
     if (req.status == 200) {
         alert(req.responseText);
     } else {
         alert(req.statusText);
     }
 </script> 

get()方法，就像它的名字暗示的那样，可以通过HTTP的GET方法获得指定URL的内容，它将目标URL作为第一个参数，将一个代表HTTP请求头的数组作为可选的第二个参数。get()方法与服务器交互，当得到服务器的响应后就返回一个XMLHttpRequest对象作为返回值。当get()方法返回时，已经收到了服务器响应，所以就没必要再用回调函数接收结果。自然，也不必再耽心当程序等待服务器的响应时浏览器冻结的情况了。另外，还有一个 post()方法可以用来发送数据到服务器：

<script type="text/javascript" src="Concurrent.Thread.js"></script>
 <script type="text/x-script.multithreaded-js">
     var req = Concurrent.Thread.Http.post(url, "key1=val1&key2=val2");
     alert(req.statusText);
 </script> 

post()方法将目的URL作为第一个参数，要发送的内容作为第二个参数。像get()方法那样，你也可以将请求头作为可选的第三个参数。

如果你用这个通信库实现了第一个例子当中的getArticle()方法，那么你很快就能应用文章开头示例的那种简单的方法写出getArticleWithCache(),backgroundLoad ()以及其它调用了getArticle()方法的函数了。即使是那版backgroundLoad()正在读文章数据，照例还有另外一个线程可以对用户请求做出响应，浏览器因此也不会冻结。现在，你能理解在JavaScript中应用多线程有多实用了？

想了解更多

我向你介绍了一个可以在JavaScript中应用多线程的库：Concurrent.Thread。这篇文章的内容只是很初级的东西，如果你想更深入的了解，我推荐您去看the tutorial。它提供有关Concurrent.Thread用法的更多内容，并列出了可供高级用户使用的文档，是最适合起步的材料。访问他们的网站也不错，那里提供更多信息。

有关作者

Daisuke Maki：从International Christian大学文科学院自然科学分部毕业后（取得文学学士学位），又在Electro-Communications大学的研究生院信息专业攻读硕士学位。擅长Web开发和应用JavaScript的AJAX。他开发了Concurrent.Thread。2006财政年度在日本信息技术促进机构（IPA）指导的项目Explatory Software Project中应用了这个设计。

目前已经拥有一个工学硕士学位的他正在Electro-Communications大学的研究生院注册攻读博士学位。

Part 1: Introduction

Chapter 1. Introducing Silverlight 2


Silverlight is Microsoft's new browser-based plug-in for delivering richer interactive applications to users over the web. Silverlight 2 is Microsoft's second release of the Silverlight platform. Silverlight 2's biggest change from Silverlight 1.0 is the inclusion of a compact version of the .NET Framework, complete with the .NET Framework 3.0 Common Language Runtime. By adding .NET to Silverlight, Microsoft makes it easy for .NET developers to reuse their existing programming skills, collaborate with designers, and quickly create rich applications for the Web.

And even though Silverlight 2 brings .NET to the client, it can be integrated easily with many existing Web technologies and backend Web platforms. That means Silverlight will integrate with your existing infrastructure and applications, from IIS and .NET to Apache and PHP to simple JavaScript and XHTML on the client. Silverlight is not a tool meant for exclusive use on ASP.NET web sites, which should result in broader adoption of the new technology.

Still, one of the key benefits of Silverlight 2 is that it can execute any .NET language, including C# and VB.NET. Unlike the CLR included with the "normal" .NET Framework, multiple instances of the core "Silverlight CLR" can be hosted in a single process. With this, the layout markup in the Silverlight XAML file (.xaml file) can be augmented by code-behind code with all programming logic written in any .NET language.

Silverlight 2 ships with a "lightweight" version of the full .NET Framework, which features, among other classes, extensible controls, XML Web Services, networking components, and LINQ APIs. This class library is a subset of (and is considerably smaller than) the .NET Framework's Base Class Library, which enables the Silverlight plug-in to be a fast and small download. For security, all Silverlight code runs in a sandbox environment that prevents invoking platform APIs, protecting user computers from malicious code. Silverlight 2 also adds support for DRM in media files, a fact that will make some people happy and others cringe.

In addition to the .NET Framework classes, Silverlight 2 also ships with a subset of the WPF UI programming model, including support for shapes, documents, media, and WPF animation objects. The Silverlight 2 December CTP did not ship with many WPF UI controls, though, so out-of-the-box controls will remain limited until beta 1. The Silverlight 2 beta 1 release promises to deliver more controls as well as the ability to bind to data. Microsoft says that the data binding limitations are strictly temporary and that future builds of Silverlight 2 will eliminate the problem. Count on future Silverlight releases to add more UI controls, data binding support, and a much needed automated layout manager to the Silverlight mix (see Figure 1-1).

The architecture of Silverlight 1.0 is quite complex (see http://msdn2.microsoft.com/en-us/library/bb404713.aspx for an overview), but it can be broken down into big chunks. The presentation system takes care of everything UI, including animation, text rendering, and audio/video playback. The plug-in itself integrates into the browser so that the content can be shown, as well as accessed using the JavaScript DOM. Finally, using some JavaScript code (or, optimally, the ASP.NET AJAX framework), Silverlight applications can be enriched to access server APIs such as web services. The browser plug-in then parses the markup and runs the code, even if no .NET Framework Redistributable is installed on the client. Silverlight 2 further extends this and offers a partial .NET Framework integration right into Silverlight. So you can write code in languages such as C#; this code will be compiled prior to deployment.

Figure 1-1. Silverlight framework model
 

1.1. Rich Internet Applications
What exactly is a "RIA" web application? And why would you want to adopt the RIA model for your own web development?

Rich Internet Applications, or RIAs, are web applications that have the features and functionality of traditional desktop applications. RIAs typically transfer the processing necessary for the user interface to the web client but keep the bulk of the data processing (such as maintaining the state of the program, the data, etc.) on the application server.

Traditional web applications implement a client/server architecture, in which a thin client (the web browser) interacts with a powerful server. Typically, all processing is done on the server and the client is used only to display static HTML content. The biggest drawback to thin-client implementations is that all interaction with the application must pass through the server. That means data must be sent to the server, the server must respond, and then the page must be reloaded on the client with the server's response. By moving more of this processing to client-side technology that can execute instructions on the client's computer, RIAs can circumvent this slow, synchronous loop for many user interactions.

1.1.1. Benefits of Rich Internet Applications
One of the primary benefits of RIAs is that they can offer user-interface behaviors not possible with only the HTML controls available in standard browser-based web applications. With a RIA platform, web applications are no longer limited by what the browser can do. Rather, they can implement any user interaction that the new RIA platform support, such as drag-and-drop behaviors, smooth animations, and client-side calculations. While some of these interactions are possible without a RIA platform (using Ajax, for example), the RIA approach is typically much more responsive and consistent across platforms.

The benefits of RIAs, however, go beyond their looks. Using a client engine can also produce other performance benefits:

Client-server balance

RIAs shift the balance of computing resources for web applications from the server to the client. This frees up resources on the web server, enabling the same server hardware to handle more concurrent user sessions. On the flip side, the approval it requires that your users have computers that are powerful enough to execute complex client-side code, which is generally not a problem in this day and age.

Asynchronous communication

The RIA client engine can interact with the server asynchronously—that is, without waiting for the user to perform an action such as clicking on a button or link. This feature enables RIA designers to move data between the user's PC and the server without making the user wait for the transfer to finish, similar to what Ajax provides today.

Network efficiency

Network traffic may also be significantly reduced in a RIA because an application-specific client engine can be more intelligent than a standard web browser when deciding what data needs to be exchanged with servers. Transferring less data for each interaction can speed up individual requests and responses, in turn reducing overall network load. Use of asynchronous prefetching techniques, however, can neutralize or even reverse this potential benefit. Because code cannot anticipate exactly what every user will do next, prefetching extra data is common, not all of which is actually needed by many users.

1.1.2. Shortcomings of Rich Internet Applications
While RIAs offer some compelling advantages over current approaches to web development, there are a number of drawbacks that plague the technology—not the least of which are requirements of the browser plug-in itself (in most cases). Among the more serious drawbacks of RIAs are:

Sandbox

Because RIAs run within a sandbox, they have restricted access to system resources. If users modify their systems or have reduced permissions that alter a RIA's ability to access system resources, RIAs may fail to operate correctly.

Disabled scripting

RIAs usually require JavaScript or another scripting language to operate on the client. If the user has disabled active scripting in his browser, the RIA may not function properly, if at all.

Script download time

Although it does not always have to be installed, the additional client-side intelligence (or client engine) of RIA applications needs to be delivered by the server to the client. While much of this is usually automatically cached, it needs to be transferred at least once. Depending on the size and type of delivery, client engine download time may be unpleasantly long, especially for users with slower Internet connections. Some RIA developers can lessen the impact of this delay by compressing scripts and by staging delivery over multiple pages of an application. For client engine s that require a plug-in to be installed, this is not an option.

Loss of visibility to search engines

Search engines may not be able to index the text content of RIA applications. This can be a major problem for web applications that depend on search engine visibility for their success.

Dependence on an Internet connection

While the ideal network-enabled replacement for a desktop application would allow users to be "occasionally connected," wandering in and out of hotspots or from office to office, today (in 2008) the typical RIA requires network connectivity.

问题：当一个正在执行中的ASPX页面执行到一半的时候，浏览器中你关闭了这个页面，服务器端对应的这个页面的代码仍然在执行么？

答案：除非你代码里面做了特殊判断，否则仍然正在执行。

注意点：

1、客户端显示页面的时候，后台已经执行完了的页面对象早已经不存在了。当然这时候谈不上服务器段执行不执行的问题了。

2、页面还没有返回，处于等待状态的时候。关闭ASPX页面，才会涉及到上面提到的服务器端仍然在执行的情况。

3、客户端关闭的时候根本不向服务器发送指令。

4、除非你代码里面做了特殊判断，这里的特殊判断指用 if(!Response.IsClientConnected) 来检测状态而用代码终止运行。

下面的简单代码就是演示关闭页面后，看是否仍然在执行？

你可以在这个页面打开后， 还没有返回任何信息的时候把这个页面关闭，然后看指定目录下是否有对应文件被创建并填写内容。

        protected void Page_Load(object sender, EventArgs e)
{
StringBuilder txt = new StringBuilder();
txt.AppendLine();
txt.AppendLine(DateTime.Now.ToString("u"));
txt.AppendLine("asvd");
Response.Write(DateTime.Now.ToString("u"));
Response.Write("<br />\r\n");
Thread.Sleep(50000);
txt.AppendLine(DateTime.Now.ToString("u"));
Response.Write(DateTime.Now.ToString("u"));
Response.Write("<br />\r\n");
// 把一些信息写到另外一个文件,借此察看是否正在运行
string dir = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "logs");
if (!Directory.Exists(dir))
Directory.CreateDirectory(dir);
DateTime dt = DateTime.Now;
string shortfileName = string.Format("errors_{0:0000}{1:00}{2:00}.log", dt.Year, dt.Month, dt.Day);
string fileName = Path.Combine(dir, shortfileName);
StreamWriter sw;
if (File.Exists(fileName))
sw = File.AppendText(fileName);
else
sw = File.CreateText(fileName);
sw.Write(txt.ToString());
sw.Close();
sw = null;
}

作了特殊判断的情况简单例子：

注意： IsClientConnected 的判断在 VS.net 开发工具自带的开发站点 ASP.NET Development Server  是不支持的。 ASP.NET Development Server 永远返回 true 。

IIS 才是支持的。

        protected void Page_Load(object sender, EventArgs e)
{
StringBuilder txt = new StringBuilder();
for (int i = 0; i < 100; i++)
{
if (this.Response.IsClientConnected)
{
txt.AppendLine();
txt.AppendLine(DateTime.Now.ToString("u"));
txt.AppendLine(i.ToString());
Response.Write(DateTime.Now.ToString("u"));
Response.Write("<br />\r\n");
Thread.Sleep(500);
}
else
{
Response.End();
return;
}
}
txt.AppendLine(DateTime.Now.ToString("u"));
Response.Write(DateTime.Now.ToString("u"));
Response.Write("<br />\r\n");
// 把一些信息写到另外一个文件,借此察看是否正在运行
string dir = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "logs");
if (!Directory.Exists(dir))
Directory.CreateDirectory(dir);
DateTime dt = DateTime.Now;
string shortfileName = string.Format("errors_{0:0000}{1:00}{2:00}.log", dt.Year, dt.Month, dt.Day);
string fileName = Path.Combine(dir, shortfileName);
StreamWriter sw;
if (File.Exists(fileName))
sw = File.AppendText(fileName);
else
sw = File.CreateText(fileName);
sw.Write(txt.ToString());
sw.Close();
sw = null;
}

这个例子中是发现中断，就抛弃之前做的任何东西。

当然我们也可以简单的修改上述代码，让把已经处理完成的东西记录下来，类似下面的代码

        protected void Page_Load(object sender, EventArgs e)
{
StringBuilder txt = new StringBuilder();
for (int i = 0; i < 100; i++)
{
if (this.Response.IsClientConnected)
{
txt.AppendLine();
txt.AppendLine(DateTime.Now.ToString("u"));
txt.Append("**********  ");
txt.AppendLine(i.ToString());
Response.Write(DateTime.Now.ToString("u"));
Response.Write("<br />\r\n");
Thread.Sleep(500);
}
else
{
break;
}
}
txt.AppendLine(DateTime.Now.ToString("u"));
Response.Write(DateTime.Now.ToString("u"));
Response.Write("<br />\r\n");
// 把一些信息写到另外一个文件,借此察看是否正在运行
string dir = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "logs");
if (!Directory.Exists(dir))
Directory.CreateDirectory(dir);
DateTime dt = DateTime.Now;
string shortfileName = string.Format("errors_{0:0000}{1:00}{2:00}.log", dt.Year, dt.Month, dt.Day);
string fileName = Path.Combine(dir, shortfileName);
StreamWriter sw;
if (File.Exists(fileName))
sw = File.AppendText(fileName);
else
sw = File.CreateText(fileName);
sw.Write(txt.ToString());
sw.Close();
sw = null;
}

需要注意的是， 使用 isClientConnected   是要占用一定的系统资源的。

isClientConnected   实际上需要向客户端输出一点东西，然后才知道客户端是否仍然在线。

这样，除非你的应用非常耗时，否则建议你不要用 isClientConnected   。 免得判断 isClientConnected   使用的资源比你实际业务逻辑使用的资源还要多。

在任何情况下， Response.IsClientConnected 都要有些开销，所以，只有在执行至少要用 500 毫秒（如果想维持每秒几十页的吞吐量，这是一个很长的时间了）的操作前才使用它。作为通常的规则，不要在紧密循环的每次迭代中调用它，例如当绘制表中的行，可能每  20 行或每 50 行调用一次。

参考资料：

how to increase timeout on aspx page?
http://p2p.wrox.com/topic.asp?TOPIC_ID=7504

asp.net能不能在客户端关闭后在后台继续将页面执行完毕？
http://topic.csdn.net/u/20070202/14/85ea5576-907a-4960-9c53-b206a05228e4.html

在 ASP.NET 中使用计时器（Timer）
http://blog.joycode.com/percyboy/articles/3595.aspx

ASP.NET 2.0 中的异步页
http://www.microsoft.com/china/msdn/library/webservices/asp.net/issuesWickedCodetoc.mspx?mfr=true

IsClientConnected的问题
http://topic.csdn.net/u/20080712/19/74fa4070-84bd-4fda-a99b-ac361f874738.html

Response.IsClientConnected 原理和用法
http://blog.51ait.cn/article.asp?id=357    第一个地址比较慢，可以看下一个地址
http://blog.joycode.com/ghj/archive/2008/07/23/115198.aspx

ASP.NET是一个非常强大的构建Web应用的平台，它提供了极大的灵活性和能力以致于可以用它来构建所有类型的Web应用。
绝大多数的人只熟悉高层的框架如： WebForms 和 WebServices --这些都在ASP.NET层次结构在最高层。

这篇文章的资料收集整理自各种微软公开的文档，通过比较 IIS5、IIS6、IIS7 这三代 IIS 对请求的处理过程， 让我们熟悉 ASP.NET的底层机制 并对请求(request)是怎么从Web服务器传送到ASP.NET运行时有所了解。通过对底层机制的了解，可以让我们对 ASP.net 有更深的理解。

IIS 5 的 ASP.net 请求处理过程

对图的解释：

IIS 5.x 一个显著的特征就是 Web Server 和真正的 ASP.NET Application 的分离。作为 Web Server 的IIS运行在一个名为 InetInfo.exe 的进程上，InetInfo.exe 是一个Native Executive，并不是一个托管的程序，而我们真正的 ASP.NET Application 则是运行在一个叫做 aspnet_wp 的 Worker Process 上面，在该进程初始化的时候会加载CLR，所以这是一个托管的环境。

ISAPI：  指能够处理各种后缀名的应用程序。 ISAPI 是下面单词的简写 ：Internet Server Application Programe Interface，互联网服务器应用程序接口。

IIS 5 模式的特点：

1、首先，同一台主机上在同一时间只能运行一个 aspnet_wp 进程，每个基于虚拟目录的 ASP.NET Application 对应一个 Application Domain ，也就是说每个 Application 都运行在同一个 Worker Process 中，Application之间的隔离是基于 Application Domain 的，而不是基于Process的。

2、其次，ASP.NET  ISAPI 不但负责创建 aspnet_wp Worker Process，而且负责监控该进程，如果检测到 aspnet_wp 的 Performance 降低到某个设定的下限，ASP.NET  ISAPI 会负责结束掉该进程。当 aspnet_wp 结束掉之后，后续的 Request 会导致ASP.NET ISAPI 重新创建新的 aspnet_wp Worker Process。

3、最后，由于 IIS 和 Application 运行在他们各自的进程中，他们之间的通信必须采用特定的通信机制。本质上 IIS 所在的 InetInfo 进程和 Worker Process 之间的通信是同一台机器不同进程的通信（local interprocess communications），处于Performance的考虑，他们之间采用基于Named pipe的通信机制。ASP.NET ISAPI和Worker Process之间的通信通过他们之间的一组Pipe实现。同样处于Performance的原因，ASP.NET ISAPI 通过异步的方式将Request 传到Worker Process 并获得 Response，但是 Worker Process 则是通过同步的方式向 ASP.NET ISAPI 获得一些基于 Server 的变量。

IIS6 的 ASP.net 请求处理过程

对图的解释：

IIS 5.x 是通过 InetInfo.exe 监听 Request 并把Request分发到Work Process。换句话说，在IIS 5.x中对Request的监听和分发是在User Mode中进行，在IIS 6中，这种工作被移植到kernel Mode中进行，所有的这一切都是通过一个新的组件：http.sys 来负责。

注：为了避免用户应用程序访问或者修改关键的操作系统数据，windows提供了两种处理器访问模式：用户模式（User Mode）和内核模式（Kernel Mode）。一般地，用户程序运行在User mode下，而操作系统代码运行在Kernel Mode下。Kernel Mode的代码允许访问所有系统内存和所有CPU指令。

在User Mode下，http.sys接收到一个基于 aspx 的http request，然后它会根据IIS中的 Metabase 查看该基于该 Request 的 Application 属于哪个Application Pool， 如果该Application Pool不存在，则创建之。否则直接将 request 发到对应Application Pool 的 Queue中。

每个 Application Pool 对应着一个Worker Process：w3wp.exe，毫无疑问他是运行在User Mode下的。在IIS Metabase 中维护着 Application Pool 和worker process的Mapping。WAS（Web Administrative service）根据这样一个mapping，将存在于某个Application Pool Queue的request 传递到对应的worker process(如果没有，就创建这样一个进程)。在 worker process 初始化的时候，加载ASP.NET ISAPI，ASP.NET ISAPI 进而加载CLR。最后的流程就和IIS 5.x一样了：通过AppManagerAppDomainFactory 的 Create方法为 Application 创建一个Application Domain；通过 ISAPIRuntime 的 ProcessRequest处理Request，进而将流程进入到ASP.NET Http Runtime Pipeline。

IIS 7  的 ASP.net 请求处理过程

IIS7 站点启动并处理请求的步骤如下图：

步骤 1 到 6 ，是处理应用启动，启动好后，以后就不需要再走这个步骤了。

上图的8个步骤分别如下：

1、当客户端浏览器开始HTTP 请求一个WEB 服务器的资源时，HTTP.sys 拦截到这个请求。
2、HTTP.sys contacts WAS to obtain information from the configuration store.

3、WAS 向配置存储中心请求配置信息。applicationHost.config。
4、WWW 服务接受到配置信息，配置信息指类似应用程序池配置信息，站点配置信息等等。
5、WWW 服务使用配置信息去配置 HTTP.sys 处理策略。
6、WAS starts a worker process for the application pool to which the request was made.

7、The worker process processes the request and returns a response to HTTP.sys.

8、客户端接受到处理结果信息。

W3WP.exe 进程中又是如果处理得呢？？ IIS 7 的应用程序池的托管管道模式分两种： 经典和集成。 这两种模式下处理策略各不相通。

本文作者：郭红俊 http://blog.joycode.com/ghj

IIS 6 以及 IIS7 经典模式的托管管道的架构

       在IIS7之前，ASP.NET 是以 IIS ISAPI extension 的方式外加到 IIS，其实包括 ASP 以及 PHP，也都以相同的方式配置（PHP 在 IIS 采用了两种配置方式，除了 IIS ISAPI extension 的方式，也包括了 CGI 的方式，系统管理者能选择 PHP 程序的执行方式），因此客户端对 IIS 的 HTTP 请求会先经由 IIS 处理，然后 IIS 根据要求的内容类型，如果是 HTML 静态网页就由 IIS 自行处理，如果不是，就根据要求的内容类型，分派给各自的 IIS ISAPI extension；如果要求的内容类型是 ASP.NET，就分派给负责处理 ASP.NET 的 IIS ISAPI extension，也就是 aspnet_isapi.dll。下图是这个架构的示意图。

IIS  7 应用程序池的 托管管道模式  经典  模式也是这样的工作原理。 这种模式是兼容IIS 6 的方式， 以减少升级的成本。

IIS6 的执行架构图，以及 IIS7  应用程序池配置成经典模式的执行架构图

IIS  7 应用程序池的 托管管道模式  集成模式

       而 IIS 7 完全整合 .NET 之后，架构的处理顺序有了很大的不同（如下图），最主要的原因就是 ASP.NET 从 IIS 插件（ISAPI extension）的角色，进入了 IIS 核心，而且也能以 ASP.NET 模块负责处理 IIS 7 的诸多类型要求。这些 ASP.NET 模块不只能处理 ASP.NET 网页程序，也能处理其他如 ASP 程序、PHP 程序或静态 HTML 网页，也因为 ASP.NET 的诸多功能已经成为 IIS 7 的一部份，因此 ASP 程序、PHP 程序或静态 HTML 网页等类型的要求，也能使用像是Forms认证（Forms Authentication）或输出缓存（Output Cache）等 ASP.NET 2.0 的功能（但须修改 IIS 7 的设定值）。也因为 IIS 7 允许自行以 ASP.NET API 开发并加入模块，因此 ASP.NET 网页开发人员将更容易扩充 IIS 7 和网站应用程序的功能，甚至能自行以 .NET 编写管理 IIS 7 的程序（例如以程控 IIS 7 以建置网站或虚拟目录）。

IIS 7 的执行架构图（集成托管信道模式下的架构）

小结

IIS5 到 IIS6 的改进，主要是 HTTP.sys 的改进。

IIS6 到 IIS7 的改进，主要是 ISAPI 的改进。

参考资料：

ASP.NET Process Model之一：IIS 和 ASP.NET ISAPI
http://www.cnblogs.com/artech/archive/2007/09/09/887528.html

ASP.NET Internals – IIS and the Process Model
http://dotnetslackers.com/articles/iis/ASPNETInternalsIISAndTheProcessModel.aspx

模组化的IIS 7 与.NET 能力整合
http://www.microsoft.com/taiwan/technet/columns/profwin/33-iis7-componentization-integration.mspx

Introduction to IIS 7.0 Architecture
http://learn.iis.net/page.aspx/101/introduction-to-iis7-architecture/

Microsoft .Net Remoting系列专题之三：Remoting事件处理全接触

大坏蛋

.NET Remoting中的事件处理(.NET Framework 2.0)

.NET Remoting的新特性-IpcChannel(.NET Framework 2.0)

iBATIS DataMapper is a Java/.NET framework that will help you design and implement better persistence layers for your Java/.NET applications. iBATIS couples objects with stored procedures or SQL statements using a XML descriptor. Simplicity is the biggest advantage of the iBATIS Data Mapper over object relational mapping tools.

To use iBATIS Data Mapper you rely on your own objects, XML, and SQL. There is little to learn that you don't already know. With iBATIS Data Mapper you have the full power of both SQL and stored procedures at your fingertips.

Our sample project

This sample takes an "over-the-shoulder" Cookbook approach. We'll define a simple data access problem and use iBATIS to solve it for us. Let's say our client has a database and one of the tables in the database is a list of people. The client tells us:

"We would like to use a web application to display the people in this table and to add, edit, and delete individual records."

Not a complicated story, but it will cover the CRUD most developers want to learn first.

Step 1 : The SQL

Let's start with the people table client mentioned. Since we're keeping it simple, we'll say it's a table in an Access database. The table definition is shown as

Step 2 :The.NET Class

using System;
namespace iBatisTutorial.Model
{
public class Person
{
private int _id;
private string _firstName;
private string _lastName;
private DateTime _birthDate;
private double _weightInKilograms;
private double _heightInMeters;
public int Id
{
get{ return _id; }
set{ _id = value; }
}
// Other public properties for the private fields ...

}
}

Step 3 :The Nunit test

The first thing our story says is that client would like to display a list of people.

using System.Collections;
using IBatisNet.DataMapper;
using NUnit.Framework;
namespace iBatisTutorial.Model
{
[TestFixture]
public class PersonTest
{
[Test]
public void PersonList ()
{
// try it
    IList people = Mapper.Instance().QueryForList("SelectAll",null);
// test it
    Assert.IsNotNull(people,"Person list not returned");
Assert.IsTrue(people.Count>0,"Person list is empty");
Person person = (Person) people[0];
Assert.IsNotNull(person,"Person not returned");
}
}
}

OK, that was fun! The Assert class is built into NUnit, so to compile, we just need the Mapper object and QueryForList method. The Mapper is built into the iBATIS framework, so we don't need to write that either. The iBATIS QueryForList method executes our SQL statement (or stored procedure) and returns the result as a list.
Each row in the result becomes an entry in the list. Along with QueryForList, there is also Delete, Insert, Select, QueryForObject, and a couple of other methods in the iBATIS API. (See the Developers Guide for details.)

Looking at PersonTest class, we see that the QueryForList method takes the name of the statement we want to run and any runtime values the statement may need. Since a "SelectAll" statement wouldn't need any runtime values, we pass null in our test.

OK. Easy enough. But where does iBATIS get the "SelectAll" statement?

Some systems try to generate SQL statements for you, but iBATIS specializes in data mapping, not code generation. It's our job (or the job of our database administrator) to craft the SQL or provide a stored procedure. We then describe the statement in an XML element, like the one shown below.

Step 4 :The mapping file

<alias>
<typeAlias alias="Person" type="iBatisTutorial.Model.Person, iBatisTutorial.Model" />
</alias>
<resultMap id="SelectAllResult" class="Person">
<result property="Id" column="PER_ID" />
<result property="FirstName" column="PER_FIRST_NAME" />
<result property="LastName" column="PER_LAST_NAME" />
<result property="BirthDate" column="PER_BIRTH_DATE" />
<result property="WeightInKilograms" column="PER_WEIGHT_KG" />
<result property="HeightInMeters" column="PER_HEIGHT_M" />
</resultMap>
<select id="SelectAll" resultMap="SelectAllResult">
select
PER_ID,
PER_FIRST_NAME,
PER_LAST_NAME,
PER_BIRTH_DATE,
PER_WEIGHT_KG,
PER_HEIGHT_M
from PERSON
</select>

The iBATIS mapping documents can hold several sets of related elements, like those shown. We can also have as many mapping documents as we need. Having multiple mapping documents is handy when several developers are working on the project at once.

So, the framework gets the SQL code for the query from the mapping, and plugs it into a prepared statement. But, how does iBATIS know where to find the table's datasource?

Surprise! More XML! You can define a configuration file for each datasource your application uses. The example below shows a configuration file for our Access database.

Step 5 :The configuration file

<?xml version="1.0" encoding="UTF-8" ?>
<sqlMapConfig
xmlns="http://ibatis.apache.org/dataMapper"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
<database>
<provider name="OleDb1.1"/>
<dataSource name="iBatisTutorial"
connectionString="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=./Resources/iBatisTutorial.mdb"/>
</database>
<sqlMaps>
<sqlMap resource="Resources/Person.xml" />
</sqlMaps>
</sqlMapConfig>

Of course, besides Access, other ADO.NET providers are supported, including SqlServer, Oracle, MySQL, PostgreSQL, DB2 and generic OLEDB, ODBC providers. (See the Developers Guide for details.)

The last part of the configuration file ("sqlMaps") is where we list our mapping documents, like the one shown back in Step 4. We can list as many documents as we need here, and they will all be read when the configuration is parsed.

OK, so how does the configuration get parsed?

Look back at PersonTest class in step 3. The heart of the code is the call to the "Mapper" object (under the remark "try it"). The Mapper object is a singleton. The first time it's called, it reads in the configuration documents to create the Mapper object. On subsequent calls, it reuses the Mapper object, so that the configuration is re-read only if the file changes.

The framework comes bundled with a default Mapper class. If you want to use a different name for the configuration file, or need to use more than one database, you can also use your own class, by copying and modifying the standard version.

The following example shows the code for the standard Mapper class that comes with the framework.

using IBatisNet.Common.Utilities;
using IBatisNet.DataMapper;
namespace IBatisNet.DataMapper
{
public class Mapper
{
private static volatile SqlMapper _mapper = null;
protected static void Configure (object obj)
{
_mapper = (SqlMapper) obj;
}
protected static void InitMapper()
{
ConfigureHandler handler = new ConfigureHandler (Configure);
_mapper = SqlMapper.ConfigureAndWatch (handler);
}
public static SqlMapper Instance()
{
if (_mapper == null)
{
lock (typeof (SqlMapper))
{
if (_mapper == null) // double-check
      InitMapper();
}
}
return _mapper;
}
public static SqlMapper Get()
{
return Instance();
}
}
}

You can access as many different