深入Atlas系列：客户端网络访问基础结构（上） - WebRequest的工作流程与生命周期
2006-10-27 00:50 Jeffrey Zhao 阅读(3985) 评论(16) 编辑 收藏 举报
ASP.NET AJAX的许多功能会要求异步地访问服务器端，例如访问Web Services，Authentication/Profile Services（事实上和访问Web Services是相同的机制）和Partial Rendering。在ASP.NET AJAX中，所有的这些访问都是通过一个网络访问的基础结构来完成的，无一例外。
我们话不多说，直接切入正题。先来看一下官方网站上Client Architecture的图示：
可以在图的左边中间部分可以看到ASP.NET AJAX客户端进行网络访问的基础结构和相关的类。事实上，除了Browser Compatibility Laryer外，WebRequestManager，WebRequest和WebRequestExecutor的子类（在默认情况下则是XMLHttpExecutor，封装了XMLHttpRequest对象）组成了客户端的Network Communication Layer。无论是Web Services Proxy，还是Role/Authentication/Profile Services都是通过它们访问的。
一般来说，ASP.NET AJAX提供的类已经足够大多数应用的需求，但是在某些特殊情况，可能需要做一些改变。因此，Network Communication Layer提供了一定程度上的扩展能力——通过提供自定义的WebRequestExecutor子类来替换默认设置：XMLHttpExecutor。这种改变能够应用于一个单独的WebRequest，也可以对全局进行一个设置。这个我们就能对于客户端的行为做一些简单的修改和补充。这样可以说是Network Communication Layer唯一的“官方”扩展点，其实能力有限。至于使用一些灵活的办法从JavaScript语言特性能上进行的修改，在这里就忽略不计了。
这样我们就能对于客户端的行为做一些简单的修改和补充。那么如果对其进行大量的修改会怎么样？如果这种修改的确能够满足您的需要，当然可以。可是这样的话，Partial Rendering就很可能无法实现了。Partial Rendering的作法是在客户端和服务器端产生一个严谨的协议，用来传递和处理大量的数据。如果有任何改变被加诸于这些数据上，协议就被破坏了，这个可以说是ASP.NET AJAX的最重要的功能之一的控件也就失效了。
当然，在自定义WebRequestExecutor时，我们可以在实现内部检查WebRequest是否正准备进行Partial Rendering的操作，如果是，则将功能委托给XMLHttpExecutor，否则就使用自己的扩展。事实上，ASP.NET AJAX的服务器端为了提供客户端访问Web Services的能力，也是使用了类似的方法扩展ASP.NET 2.0对于Web Services请求的处理（详情请见《深入Atlas系列：Web Sevices Access in Atlas（2） - 服务器端支持（上）》。虽然部分内容已经过期，但是其基本原理并没有改变，我会在“深入Atlas系列”的后续文章中进行CTP与RTM之间的比对）。
我们先来看一幅顺序图，大致了解一下三个对象在工作时的协作方式，再来具体分析一下从一个Request被建立到获得回复的详细过程。另外，对于Network Communication Layer的扩展点以及其默认实现——WebRequestExecutor和XMLHttpExecutor，我们在下一篇文章里将看一下它们的代码，以获得开发一个自定义WebRequestExecutor的具体认识。
上面是从User建立一个WebRequest开始，到得到Response的整个过程（身边只有Visio可用，却不知道怎么画SD，就随便画了一下，很有问题，但是大家可以先理解它的意思，以后我会重新画的）。这个就是客户端发起异步调用的最常见过程（当然，隐藏了几乎所有的事件，这些事件会在稍后进行描述）。因此，我想可以通过这幅图来大概了解一下客户端和服务器端是如何交互的。
接下来，我们详细了解一下这整个流程的每个步骤。
一、创建Sys.Net.WebRequest
这是发起一个服务器请求的第一步。首先建立一个Sys.Net.WebRequest对象，然后通过addHeader，set_url等方法设置这个请求的各个信息，然后调用add_complete方法来注册complete事件。请注意，这和CTP版本的Sys.Net.WebRequest不同。在CTP版本的Sys.Net.WebRequest中，存在着三个事件：complete，timeout和aborted，用户可以有选择地注册这些事件。在RTM的Sys.Net.WebRequest中，三个事件被合成了一个complete事件。不管这个Request的结果如何，都会在这个触发这个事件，用户需要在响应这个事件的方法里自行根据得到的Response的信息来分辨这个请求的状况。具体的判断方式稍后再进行说明。在创建完WebRequest对象后，将调用它的invoke方法执行这个请求。一个WebRequest对象只能被invoke一次。
二、将WebRequest对象交给WebRequestManager执行
在WebRequest对象的invoke方法被调用以后，它会调用“Sys.Net.WebRequestManager.executeRequest(this)”将自身交给全局的WebRequestManager执行。这里的WebRequestManager其实是Sys.Net._WebRequestManager类的实例。在初始化环境的时候，就会将这个类实例化一个对象，赋值到Sys.Net.WebRequestManager变量中，以一个Singleton的形象供别的方法调用。它会在处理Request的过程中在特定的时刻触发一些事件，用户可以依靠响应这些事件来改变Request的行为，例如阻止特定的Request，或者改变Request的一些属性等等。
乍看下来，RTM版本中的WebRequestManager和CTP中的WebRequestManager没有很大的区别嘛（引入了几个事件除外）。事实上，个人认为在这个方面Atlas打了自己一个耳光。在CTP版本的WebRequestManager中，对于管理WebRequest有一套比较复杂的方法，其理由是能够更好地利用好浏览器的资源，以提高WebRequest的效率。这就是Atlas对外一直声称的“Client Request Stack”，这一点被当作Atlas的重要特点来看待。不过这一点在RTM版本中被取消了，新的WebRequestManager在处理一个WebRequest对象的时候仅仅是触发事件，然后简单地使用Executor来调用这个WebRequest对象。
下面列举了调用了executeRequest方法后的关键逻辑：
三、WebRequestExecutor执行Request
在这里，以ASP.NET AJAX的默认WebRequestExecutor类：XMLHttpExecutor为例进行说明。在XMLHttpExecutor的executeRequest方法被调用后，XMLHttpExecutor会构造一个XMLHttpRequest对象，并根据WebRequest的各项属性设定XMLHttpRequest的对象，并指定XMLHttpRequest对象的onreadystatechange为自身的私有方法_onReadyStateChange。调用了executeRequest方法后的关键逻辑如下：
四、用户响应WebRequest的complete事件
在响应WebRequest的complete事件时，需要对于所获得的结果进行判断，以确定这个Request的结果到底如何，是成功了，还是出错了，亦或是过期了？需要注意的是，我们虽然监听的是WebRequest对象的事件，但是回调函数的第一个参数是WebRequestExecutor对象！executor对象在这里事实上应该被看作是一个response。我们就来简单看一下应该如何根据executor对象的属性来判断Request的结果吧。为了对于这部分逻辑有简单而清晰的描述，我就使用代码片断来说明吧。代码框架如下：
这就是判断一个Request结果的逻辑框架了，非常清晰。阅读过ASP.NET AJAX客户端代码的朋友们可以发现，在RTM版本中这段逻辑不只一次出现过。我们如果需要直接使用WebRequest对象时，也应该使用这个逻辑进行判断。
到这里，我们应该已经搞清楚了从一个WebRequest对象被构造出来以后，是如何通过WebRequestManager和WebRequestExecutor而执行的，之间会触发哪些事件，而最后又是如何通过Response（WebRequestExecutor）对象来获得Request的结果。在下一篇文章中，我们将通过分析WebRequestExecutor、XMLHttpExecutor以及相关类的实现，来了解应该如何自定义和使用一个WebRequestExecutor。
我们话不多说，直接切入正题。先来看一下官方网站上Client Architecture的图示：
可以在图的左边中间部分可以看到ASP.NET AJAX客户端进行网络访问的基础结构和相关的类。事实上，除了Browser Compatibility Laryer外，WebRequestManager，WebRequest和WebRequestExecutor的子类（在默认情况下则是XMLHttpExecutor，封装了XMLHttpRequest对象）组成了客户端的Network Communication Layer。无论是Web Services Proxy，还是Role/Authentication/Profile Services都是通过它们访问的。
一般来说，ASP.NET AJAX提供的类已经足够大多数应用的需求，但是在某些特殊情况，可能需要做一些改变。因此，Network Communication Layer提供了一定程度上的扩展能力——通过提供自定义的WebRequestExecutor子类来替换默认设置：XMLHttpExecutor。这种改变能够应用于一个单独的WebRequest，也可以对全局进行一个设置。这个我们就能对于客户端的行为做一些简单的修改和补充。这样可以说是Network Communication Layer唯一的“官方”扩展点，其实能力有限。至于使用一些灵活的办法从JavaScript语言特性能上进行的修改，在这里就忽略不计了。
这样我们就能对于客户端的行为做一些简单的修改和补充。那么如果对其进行大量的修改会怎么样？如果这种修改的确能够满足您的需要，当然可以。可是这样的话，Partial Rendering就很可能无法实现了。Partial Rendering的作法是在客户端和服务器端产生一个严谨的协议，用来传递和处理大量的数据。如果有任何改变被加诸于这些数据上，协议就被破坏了，这个可以说是ASP.NET AJAX的最重要的功能之一的控件也就失效了。
当然，在自定义WebRequestExecutor时，我们可以在实现内部检查WebRequest是否正准备进行Partial Rendering的操作，如果是，则将功能委托给XMLHttpExecutor，否则就使用自己的扩展。事实上，ASP.NET AJAX的服务器端为了提供客户端访问Web Services的能力，也是使用了类似的方法扩展ASP.NET 2.0对于Web Services请求的处理（详情请见《深入Atlas系列：Web Sevices Access in Atlas（2） - 服务器端支持（上）》。虽然部分内容已经过期，但是其基本原理并没有改变，我会在“深入Atlas系列”的后续文章中进行CTP与RTM之间的比对）。
我们先来看一幅顺序图，大致了解一下三个对象在工作时的协作方式，再来具体分析一下从一个Request被建立到获得回复的详细过程。另外，对于Network Communication Layer的扩展点以及其默认实现——WebRequestExecutor和XMLHttpExecutor，我们在下一篇文章里将看一下它们的代码，以获得开发一个自定义WebRequestExecutor的具体认识。
上面是从User建立一个WebRequest开始，到得到Response的整个过程（身边只有Visio可用，却不知道怎么画SD，就随便画了一下，很有问题，但是大家可以先理解它的意思，以后我会重新画的）。这个就是客户端发起异步调用的最常见过程（当然，隐藏了几乎所有的事件，这些事件会在稍后进行描述）。因此，我想可以通过这幅图来大概了解一下客户端和服务器端是如何交互的。
接下来，我们详细了解一下这整个流程的每个步骤。
一、创建Sys.Net.WebRequest
这是发起一个服务器请求的第一步。首先建立一个Sys.Net.WebRequest对象，然后通过addHeader，set_url等方法设置这个请求的各个信息，然后调用add_complete方法来注册complete事件。请注意，这和CTP版本的Sys.Net.WebRequest不同。在CTP版本的Sys.Net.WebRequest中，存在着三个事件：complete，timeout和aborted，用户可以有选择地注册这些事件。在RTM的Sys.Net.WebRequest中，三个事件被合成了一个complete事件。不管这个Request的结果如何，都会在这个触发这个事件，用户需要在响应这个事件的方法里自行根据得到的Response的信息来分辨这个请求的状况。具体的判断方式稍后再进行说明。在创建完WebRequest对象后，将调用它的invoke方法执行这个请求。一个WebRequest对象只能被invoke一次。
二、将WebRequest对象交给WebRequestManager执行
在WebRequest对象的invoke方法被调用以后，它会调用“Sys.Net.WebRequestManager.executeRequest(this)”将自身交给全局的WebRequestManager执行。这里的WebRequestManager其实是Sys.Net._WebRequestManager类的实例。在初始化环境的时候，就会将这个类实例化一个对象，赋值到Sys.Net.WebRequestManager变量中，以一个Singleton的形象供别的方法调用。它会在处理Request的过程中在特定的时刻触发一些事件，用户可以依靠响应这些事件来改变Request的行为，例如阻止特定的Request，或者改变Request的一些属性等等。
乍看下来，RTM版本中的WebRequestManager和CTP中的WebRequestManager没有很大的区别嘛（引入了几个事件除外）。事实上，个人认为在这个方面Atlas打了自己一个耳光。在CTP版本的WebRequestManager中，对于管理WebRequest有一套比较复杂的方法，其理由是能够更好地利用好浏览器的资源，以提高WebRequest的效率。这就是Atlas对外一直声称的“Client Request Stack”，这一点被当作Atlas的重要特点来看待。不过这一点在RTM版本中被取消了，新的WebRequestManager在处理一个WebRequest对象的时候仅仅是触发事件，然后简单地使用Executor来调用这个WebRequest对象。
下面列举了调用了executeRequest方法后的关键逻辑：
- 检查WebRequest是否指定了WebRequestExecutor（这可以在构造WebRequest的时候指定）。
- 如果WebRequest没有指定WebRequestExecutor，则使用set_executor方法分配默认的WebRequestExecutor
- 构造Sys.Net.NetworkRequestEventArgs参数对象，触发WebRequestManager的invokingRequest事件。
- 如果Sys.Net.NetworkRequestEventArgs对象的cancel属性为true，取消执行Request。
- 调用executor对象的executeRequest方法，以执行Request。
三、WebRequestExecutor执行Request
在这里，以ASP.NET AJAX的默认WebRequestExecutor类：XMLHttpExecutor为例进行说明。在XMLHttpExecutor的executeRequest方法被调用后，XMLHttpExecutor会构造一个XMLHttpRequest对象，并根据WebRequest的各项属性设定XMLHttpRequest的对象，并指定XMLHttpRequest对象的onreadystatechange为自身的私有方法_onReadyStateChange。调用了executeRequest方法后的关键逻辑如下：
- 构造XMLHttpRequest对象，并根据WebRequest对象的属性设定它的各项属性。
- 使用window.setTimeout用于监听超时发生。
- 调用XMLHttpRequest的send方法。
- 触发WebRequestManager的completedRequest事件。
- 触发WebRequest的complete事件。
四、用户响应WebRequest的complete事件
在响应WebRequest的complete事件时，需要对于所获得的结果进行判断，以确定这个Request的结果到底如何，是成功了，还是出错了，亦或是过期了？需要注意的是，我们虽然监听的是WebRequest对象的事件，但是回调函数的第一个参数是WebRequestExecutor对象！executor对象在这里事实上应该被看作是一个response。我们就来简单看一下应该如何根据executor对象的属性来判断Request的结果吧。为了对于这部分逻辑有简单而清晰的描述，我就使用代码片断来说明吧。代码框架如下：
function onComplete(response, eventArgs)
{
if (response.get_aborted())
{
// Abort
}
else if (response.get_responseAvailable())
{
var statusCode = response.get_statusCode();
if (((statusCode < 200) || (statusCode >= 300)))
{
// Error
}
else
{
// Success
}
}
else
{
if (response.get_timedOut())
{
// Timeout
}
else
{
// Error
}
}
}
{
if (response.get_aborted())
{
// Abort
}
else if (response.get_responseAvailable())
{
var statusCode = response.get_statusCode();
if (((statusCode < 200) || (statusCode >= 300)))
{
// Error
}
else
{
// Success
}
}
else
{
if (response.get_timedOut())
{
// Timeout
}
else
{
// Error
}
}
}
这就是判断一个Request结果的逻辑框架了，非常清晰。阅读过ASP.NET AJAX客户端代码的朋友们可以发现，在RTM版本中这段逻辑不只一次出现过。我们如果需要直接使用WebRequest对象时，也应该使用这个逻辑进行判断。
到这里，我们应该已经搞清楚了从一个WebRequest对象被构造出来以后，是如何通过WebRequestManager和WebRequestExecutor而执行的，之间会触发哪些事件，而最后又是如何通过Response（WebRequestExecutor）对象来获得Request的结果。在下一篇文章中，我们将通过分析WebRequestExecutor、XMLHttpExecutor以及相关类的实现，来了解应该如何自定义和使用一个WebRequestExecutor。
