反向Ajax通信技术Word文档格式.docx
《反向Ajax通信技术Word文档格式.docx》由会员分享，可在线阅读，更多相关《反向Ajax通信技术Word文档格式.docx（26页珍藏版）》请在冰豆网上搜索。
//www.geonames.org/postalCodeLookupJSON?
postalcode='
+$（'
#postalCode'
）.val（）+'
&
country='
#country'
callback=?
'
;
$.getJSON（url,function（data）{
$（'
#placeName'
）.val（data.postalcodes[0].placeName）;
}）;
在本文可下载的源代码中，你可在listing1.html中看到这一例子的作用。
反向Ajax（ReverseAjax）本质上则是这样的一种概念：
能够从服务器端向客户端发送数据。
在一个标准的HTTPAjax请求中，数据是发送给服务器端的，反向Ajax可以某些特定的方式来模拟发出一个Ajax请求，这些方式本文都会论及，这样的话，服务器就可以尽可能快地向客户端发送事件（低延迟通信）。
WebSocket技术来自HTML5，是一种最近才出现的技术，许多浏览器已经支持它（Firefox、GoogleChrome、Safari等等）。
WebSocket启用双向的、全双工的通信信道，其通过某种被称为WebSocket握手的HTTP请求来打开连接，并用到了一些特殊的报头。
连接保持在活动状态，你可以用JavaScript来写和接收数据，就像是正在用一个原始的TCP套接口一样。
WebSocket会在这一文章系列的第二部分中谈及。
反向Ajax技术
反向Ajax的目的是允许服务器端向客户端推送信息。
Ajax请求在缺省情况下是无状态的，且只能从客户端向服务器端发出请求。
你可以通过使用技术模拟服务器端和客户端之间的响应式通信来绕过这一限制。
HTTP轮询和JSONP轮询
轮询（polling）涉及了从客户端向服务器端发出请求以获取一些数据，这显然就是一个纯粹的AjaxHTTP请求。
为了尽快地获得服务器端事件，轮询的间隔（两次请求相隔的时间）必须尽可能地小。
但有这样的一个缺点存在：
如果间隔减小的话，客户端浏览器就会发出更多的请求，这些请求中的许多都不会返回任何有用的数据，而这将会白白地浪费掉带宽和处理资源。
图1中的时间线说明了客户端发出了某些轮询请求，但没有信息返回这种情况，客户端必须要等到下一个轮询来获取两个服务器端接收到的事件。
图1.使用HTTP轮询的反向Ajax
JSONP轮询基本上与HTTP轮询一样，不同之处则是JSONP可以发出跨域请求（不是在你的域内的请求）。
清单1使用JSONP来通过邮政编码获取地名，JSONP请求通常可通过它的回调参数和返回内容识别出来，这些内容是可执行的JavaScript代码。
要在JavaScript中实现轮询的话，你可以使用setInterval来定期地发出Ajax请求，如清单2所示：
清单2.JavaScript轮询
setInterval（function（）{
$.getJSON（'
events'
function（events）{
console.log（events）;
}）;
},2000）;
文章源代码中的轮询演示给出了轮询方法所消耗的带宽，间隔很小，但可以看到有些请求并未返回事件，清单3给出了这一轮询示例的输出。
清单3.轮询演示例子的输出
[client]checkingforevents...
[client]noevent
[client]2events
[event]AtSunJun0515:
17:
14EDT2011
[client]1events
16EDT2011
用JavaScript实现的轮询的优点和缺点：
1.优点：
很容易实现，不需要任何服务器端的特定功能，且在所有的浏览器上都能工作。
2.缺点：
这种方法很少被用到，因为它是完全不具伸缩性的。
试想一下，在100个客户端每个都发出2秒钟的轮询请求的情况下，所损失的带宽和资源数量，在这种情况下30%的请求没有返回数据。
Piggyback
捎带轮询（piggybackpolling）是一种比轮询更加聪明的做法，因为它会删除掉所有非必需的请求（没有返回数据的那些）。
不存在时间间隔，客户端在需要的时候向服务器端发送请求。
不同之处在于响应的那部分上，响应被分成两个部分：
对请求数据的响应和对服务器事件的响应，如果任何一部分有发生的话。
图2给出了一个例子。
图2.使用了piggyback轮询的反向Ajax
在实现piggyback技术时，通常针对服务器端的所有Ajax请求可能会返回一个混合的响应，文章的下载中有一个实现示例，如下面的清单4所示。
清单4.piggyback代码示例
$（'
#submit'
）.click（function（）{
$.post（'
ajax'
function（data）{
varvalid=data.formValid;
//处理验证结果
//然后处理响应的其他部分（事件）
processEvents（data.events）;
清单5给出了一些piggyback输出。
清单5.piggyback输出示例
[server]formvalid?
true
[client]4events
[event]AtSunJun0516:
08:
32EDT2011
34EDT2011
37EDT2011
你可以看到表单验证的结果和附加到响应上的事件，同样，这种方法也有着一些优点和缺点：
没有不返回数据的请求，因为客户端对何时发送请求做了控制，对资源的消耗较少。
该方法也是可用在所有的浏览器上，不需要服务器端的特殊功能。
当累积在服务器端的事件需要传送给客户端时，你却一点都不知道，因为这需要一个客户端行为来请求它们。
Comet
使用了轮询或是捎带的反向Ajax非常受限：
其不具伸缩性，不提供低延迟通信（只要事件一到达服务器端，它们就以尽可能快的速度到达浏览器端）。
Comet是一个web应用模型，在该模型中，请求被发送到服务器端并保持一个很长的存活期，直到超时或是有服务器端事件发生。
在该请求完成后，另一个长生存期的Ajax请求就被送去等待另一个服务器端事件。
使用Comet的话，web服务器就可以在无需显式请求的情况下向客户端发送数据。
Comet的一大优点是，每个客户端始终都有一个向服务器端打开的通信链路。
服务器端可以通过在事件到来时立即提交（完成）响应来把事件推给客户端，或者它甚至可以累积再连续发送。
因为请求长时间保持打开的状态，故服务器端需要特别的功能来处理所有的这些长生存期请求。
图3给出了一个例子。
（这一文章系列的第2部分会更加详细地解释服务器端的约束条件）。
图3.使用Comet的反向Ajax
Comet的实现可以分成两类：
使用流（streaming）的那些和使用长轮询（longpolling）的那些。
使用HTTP流的Comet
在流（streaming）模式中，有一个持久连接会被打开。
只会存在一个长生存期请求（图3中的#1），因为每个到达服务器端的事件都会通过这同一连接来发送。
因此，客户端需要有一种方法来把通过这同一连接发送过来的不同响应分隔开来。
从技术上来讲，两种常见的流技术包括ForeverIframe（隐藏的IFrame），或是被用来在JavaScript中创建Ajax请求的XMLHttpRequest对象的多部分（multi-part）特性。
ForeverIframe
ForeverIframe（永存的Iframe）技术涉及了一个置于页面中的隐藏Iframe标签，该标签的src属性指向返回服务器端事件的servlet路径。
每次在事件到达时，servlet写入并刷新一个新的script标签，该标签内部带有JavaScript代码，iframe的内容被附加上这一script标签，标签中的内容就会得到执行。
实现简单，在所有支持iframe的浏览器上都可用。
没有方法可用来实现可靠的错误处理或是跟踪连接的状态，因为所有的连接和数据都是由浏览器通过HTML标签来处理的，因此你没有办法知道连接何时在哪一端已被断开了。
Multi-partXMLHttpRequest
第二种技术，更可靠一些，是XMLHttpRequest对象上使用某些浏览器（比如说Firefox）支持的multi-part标志。
Ajax请求被发送给服务器端并保持打开状态，每次有事件到来时，一个多部分的响应就会通过这同一连接来写入，清单6给出了一个例子。
清单6.设置Multi-partXMLHttpRequest的JavaScript代码示例
varxhr=$.ajaxSettings.xhr（）;
xhr.multipart=true;
xhr.open（'
GET'
'
true）;
xhr.onreadystatechange=function（）{
if（xhr.readyState==4）{
processEvents（$.parseJSON（xhr.responseText））;
}
};
xhr.send（null）;
在服务器端，事情要稍加复杂一些。
首先你必须要设置多部分请求，然后挂起连接。
清单7展示了如何挂起一个HTTP流请求。
（这一系列的第3部分会更加详细地谈及这些API。
）
清单7.使用Servlet3API来在servlet中挂起一个HTTP流请求
protectedvoiddoGet（HttpServletRequestreq,HttpServletResponseresp）
throwsServletException,IOException{
//开始请求的挂起
AsyncContextasyncContext=req.startAsync（）;
asyncContext.setTimeout（0）;
//给客户端发回多部分的分隔符
resp.setContentType（"
multipart/x-mixed-replace;
boundary=\"
"
+boundary+"
\"
）;
resp.setHeader（"
Connection"
"
keep-alive"
resp.getOutputStream（）.print（"
--"
+boundary）;
resp.flushBuffer（）;
//把异步上下文放在列表中以被将来只用
asyncContexts.offer（asyncContext）;
}
现在，每次有事件发生时你都可以遍历所有的挂起连接并向它们写入数据，如清单8所示：
清单8.使用Servlet3API来向挂起的多部分请求发送事件
for（AsyncContextasyncContext:
asyncContexts）{
HttpServletResponsepeer=（HttpServletResponse）
asyncContext.getResponse（）;
peer.getOutputStream（）.println（"
Content-Type:
application/json"
peer.getOutputStream（）.println（）;
peer.getOutputStream（）.println（newJSONArray（）
.put（"
At"
+newDate（））.toString（））;
peer.flushBuffer（）;
本文可下载文件的Comet-straming文件夹中的部分说明了HTTP流，在运行例子并打开主页时，你会看到只要事件一到达服务器端，虽然不同步但它们几乎立刻会出现在页面上。
而且，如果打开Firebug控制台的话，你就能看到只有一个Ajax请求是打开的。
如果再往下看一些，你会看到JSON响应被附在Response选项卡中，如图4所示：
图4.HTTP流请求的FireBug视图
照例，做法存在着一些优点和缺点：
只打开了一个持久连接，这就是节省了大部分带宽使用率的Comet技术。
并非所有的浏览器都支持multi-part标志。
某些被广泛使用的库，比如说用Java实现的CometD，被报告在缓冲方面有问题。
例如，一些数据块（多个部分）可能被缓冲，然后只有在连接完成或是缓冲区已满时才被发送，而这有可能会带来比预期要高的延迟。
使用HTTP长轮询的Comet
长轮询（longpolling）模式涉及了打开连接的技术。
连接由服务器端保持着打开的状态，只要一有事件发生，响应就会被提交，然后连接关闭。
接下来。
一个新的长轮询连接就会被正在等待新事件到达的客户端重新打开。
你可以使用script标签或是单纯的XMLHttpRequest对象来实现HTTP长轮询。
script标签
正如iframe一样，其目标是把script标签附加到页面上以让脚本执行。
服务器端则会：
挂起连接直到有事件发生，接着把脚本内容发送回浏览器，然后重新打开另一个script标签来获取下一个事件。
因为是基于HTML标签的，所有这一技术非常容易实现，且可跨域工作（缺省情况下，XMLHttpRequest不允许向其他域或是子域发送请求）。
类似于iframe技术，错误处理缺失，你不能获得连接的状态或是有干涉连接的能力。
XMLHttpRequest长轮询
第二种，也是一种推荐的实现Comet的做法是打开一个到服务器端的Ajax请求然后等待响应。
服务器端需要一些特定的功能来允许请求被挂起，只要一有事件发生，服务器端就会在挂起的请求中送回响应并关闭该请求，完全就像是你关闭了servlet响应的输出流。
然后客户端就会使用这一响应并打开一个新的到服务器端的长生存期的Ajax请求，如清单9所示：
清单9.设置长轮询请求的JavaScript代码示例
functionlong_polling（）{
processEvents（events）;
long_polling（）;
long_polling（）;
在后端，代码也是使用Servlet3API来挂起请求，正如HTTP流的做法一样，但你不需要所有的多部分处理代码，清单10给出了一个例子。
清单10.挂起一个长轮询Ajax请求
在接收到事件时，只是取出所有的挂起请求并完成它们，如清单11所示：
清单11.在有事件发生时完成长轮询Ajax请求
while（!
asyncContexts.isEmpty（））{
AsyncContextasyncContext=asyncContexts.poll（）;
peer.getWriter（）.write（
newJSONArray（）.put（"
+newDate（））.toString（））;
peer.setStatus（HttpServletResponse.SC_OK）;
peer.setContentType（"
application/json"
asyncCplete（）;
在附带的下载源文件中，comet-long-polling文件夹包含了一个长轮询示例web应用，你可以使用mvnjetty:
run命令来运行它。
客户端很容易实现良好的错误处理系统和超时管理。
这一可靠的技术还允许在与服务器端的连接之间有一个往返，即使连接是非持久的（当你的应用有许多的客户端时，这是一件好事）。
它可用在所有的浏览器上；
你只需要确保所用的XMLHttpRequest对象发送到的简单的Ajax请求就可以了。
相比于其他技术来说，不存在什么重要的缺点，像所有我们已经讨论过的技术一样，该方法依然依赖于无状态的HTTP连接，其要求服务器端有特殊的功能来临时挂起连接。
建议
因为所有现代的浏览器都支持跨域资源共享（Cross-OriginResourceShare，CORS）规范，该规范允许XHR执行跨域请求，因此基于脚本的和基于iframe的技术已成为了一种过时的需要。
把Comet做为反向Ajax的实现和使用的最好方式是通过XMLHttpRequest对象，该做法提供了一个真正的连接句柄和错误处理。
考虑到不是所有的浏览器都支持multi-part标志，且多部分流可能会遇到缓冲问题，因此建议你选择经由HTTP长轮询使用XMLHttpRequest对象（在服务器端挂起的一个简单的Ajax请求）的Comet模式，所有支持Ajax的浏览器也都支持该种做法。
结论
本文提供的是反向Ajax技术的一个入门级介绍，文章探索了实现反向Ajax通信的不同方法，并说明了每种实现的优势和弊端。
你的具体情况和应用需求将会影响到你对最合适方法的选择。
不过一般来说，如果你想要在低延迟通信、超时和错误检测、简易性，以及所有浏览器和平台的良好支持这几方面有一个最好的折中的话，那就选择使用了Ajax长轮询请求的Comet。
请继续阅读这一系列的第2部分：
该部分将会探讨第三种反向Ajax技术：
WebSocket。
尽管还不是所有的浏览器都支持该技术，但WebSocket肯定是一种非常好的反向Ajax通信媒介，WebSocket消除了所有与HTTP连接的无状态特性相关的限制。
第2部分还会谈及由Comet和WebSocket技术带来的服务器端约束。
代码下载
reverse_ajaxpt1_source.zip
反向Ajax，第2部分：
WebSocket
来源:
yeeyan发布时间:
2011-10-1718:
56阅读:
4949次推荐:
1原文链接[收藏]
ReverseAjax,Part2:
WebSockets
这一文章系列探讨了如何使用反向Ajax（ReverseAjax）技术来开发事件驱动的web应用，第1部分内容介绍了实现反向Ajax通信的几种不同方式：
轮询（polling）、捎带（piggyback）以及使用了长轮询（long-polling）和流（streaming）的Comet。
在本文中，我们学习一种新的实现反向Ajax的技术：
使用WebSocket，一个新的HTML5API。
WebSocket可由浏览器厂商来做本地化实现，或是通过把调用委托给隐藏的被称为FlashSocket的Flash组件这种桥接手段来实现。
本文还讨论了反向Ajax技术带来的一些服务器端约束。
时至今日，用户期待的是可通过web访问快速、动态的应用。
这一文章系列展示了如何使用反向Ajax（ReverseAjax）技术来开发事件驱动的web应用。
该系列的第1部分介绍了反向Ajax、轮询（polling）、流（streaming）、Comet和长轮询（longpolling）。
你已经了解了Comet是如何使用HTTP长轮询的，这是可靠地实现反向Aja
升级会员 