测试：Servlet 3.0实战：异步处理特性应用

　   本文章只是为了作个简单的测试，主要就是Servlet 3.0实战：异步处理特性应用技术，当然目的只是为了看看老白是怎样对待的，不管怎样，只要结果一出来，一切问题都将得到解决！

        通过 Annotations 代替传统 web.xml 配置文件的 EOD 易于开发特性(ease of development)。

　　Serlvet 异步处理支持。

　　安全性提升，如 Http Only Cookies、login/logout 机制。

　　其它改进，如文件上传的直接支持等。

　　其中，在开源社区中讨论得最多的就是 Servlet 异步处理的支持，所谓 Servlet 异步处理，包括了非阻塞的输入/输出、异步事件通知、延迟 request 处理以及延迟 response 输出等几种特性。这些特性大多并非 JSR 315 规范首次提出，譬如非阻塞输入/输出，在 Tomcat 6.0 中就提供了 Advanced NIO 技术以便一个 Servlet 线程能处理多个 Http Request，Jetty、GlassFish 也曾经有过类似的支持。但是使用这些 Web 容器提供的高级特性时，因为现有的
Servlet API 没有对这类应用的支持，所以都必须引入一些 Web 容器专有的类、接口或者 Annotations，导致使用了这部分高级特性，就必须与特定的容器耦合在一起，这对很多项目来说都是无法接受的。因此 JSR 315 将这些特性写入规范，提供统一的 API 支持后，这类异步处理特性才真正具备广泛意义上的实用性，只要支持 Servlet 3.0 的 Web 容器，就可以不加修改的运行这些 Web 程序。

　　JSR 315 中的 Servlet 异步处理系列特性在很多场合都有用武之地，但人们最先看到的，是它们在“服务端推”(Server-Side Push)方式 —— 也称为 Comet 方式的交互模型中的价值。在 JCP(Java Community Process)网站上提出的 JSR 315 规范目标列表，关于异步处理这个章节的标题就直接定为了“Async and Comet support”(异步与 Comet 支持)。

　　本文将详细介绍 Comet 风格应用的实现方式，以及 Servlet 3.0 中的异步处理特性在 Comet 风格程序中的实际应用。

　“Comet 技术”、“服务端推技术(Server-Side Push)”、“反向 Ajax 技术”这几个名称说的是同一件事情，可能您已经听说过其中的一项或者几项。但没听说过也没有关系，一句话就足以表达它们全部的意思：“在没有客户端请求的情况下，服务端向客户端发送数据”。

　　这句话听起来很简单很好理解，但是任何一个长期从事 B/S 应用程序开发的程序都清楚，这实现起来并不简单，甚至很长一段时间内，人们认为这是并不可能的。因为这种做法完全不符合传统基于 HTTP 协议的交互思想：只有基于 Socket 层次的应用才能做到 Server 和 Client 端双方对等通讯，而基于 HTTP 的应用中，Server 只是对来自 Client 的请求进行回应，不关心客户端的状态，不主动向客户端请求信息，因此 Http 协议被称为无状态、单向性协议，这种交互方式称为 Request-Response
交互模型。

　　无状态、单向的经典 Request-Response 交互模型有很多优点，譬如高效率、高可伸缩等。对于被动响应用户请求为主的应用，像 CMS、MIS、ERP 等非常适合，但是对于另外一些需要服务端主动发送的需求，像聊天室(用户不发言的时候也需要把其它用户的发言传送回来)、日志系统(客户端没有请求，当服务端有日志输出时主动发送到客户端)则处理起来很困难，或者说这类应用根本不适合使用经典的 Request-Response 交互模型来处理。当“不适合”与“有需求”同时存在时，人们就开始不断寻找突破这种限制的方法。

　　Comet 实现的方法

　　简单轮询

　　最早期的 Web 应用中，主要通过 JavaScript 或者 Meta HTML 标签等手段，定时刷新页面来检测服务端的变化。显然定时刷新页面服务端仍然在被动响应客户端的请求，只不过客户端的请求是连续、频繁的，让用户看起来产生有服务端自动将信息发过来的错觉。这种方式简单易行，但缺陷也非常明显：可能大部分请求都是无意义的，因为服务端期待的事件没有发生，实际上并没有需要发送的信息，而不得不重复的回应着页面上所有内容给浏览器;另外就是当服务端发生变化时，并不能“实时”的返回，刷新的间隔太短，产生很大的性能浪费，间隔太长，事件通知又可能晚于用户期望的时间到达。

　　当绝大部分浏览器提供了 XHR(XmlHttpRequest)对象支持后，Ajax 技术出现并迅速流行，这一阶段做的轮询就不必每次都返回都返回整个页面中所有的内容，如果服务端没有事件产生，只需要返回极少量内容的 http 报文体。Ajax 可以节省轮询传输中大量的带宽浪费，但它无法减少请求的次数，因此 Ajax 实现的简单轮询仍然有轮询的局限性，对其缺陷只能一定程度缓解，而无法达到质变。

　　长轮询(混合轮询)

　　长轮询与简单轮询的最大区别就是连接时间的长短：简单轮询时当页面输出完连接就关闭了，而长轮询一般会保持 30 秒乃至更长时间，当服务器上期待的事件发生，将会立刻输出事件通知到客户端，接着关闭连接，同时建立下一个连接开始一次新的长轮询。

　　长轮询的实现方式优势在于当服务端期待事件发生，数据便立即返回到客户端，期间没有数据返回，再较长的等待时间内也没有新的请求发生，这样可以让发送的请求减少很多，而事件通知的灵敏度却大幅提高到几乎是“实时”的程度。

Comet 流(Forever Frame)

　　Comet 流是按照长轮询的实现思路进一步发展的产物。令长轮询将事件通知发送回客户端后不再关闭连接，而是一直保持直到超时事件发生才重新建立新的连接，这种变体我们就称为 Comet 流。客户端可以使用 XmlHttpRequest 对象中的 readyState 属性来判断是 Receiving 还是 Loaded。Comet 流理论上可以使用一个链接来处理若干次服务端事件通知，更进一步节省了发送到电磁阀服务端的请求次数。

　　无论是长轮询还是 Comet 流，在服务端和客户端都需要维持一个比较长时间的连接状态，这一点在阀门客户端不算什么太大的负担，但是服务端是要同时对多个客户端服务的，按照经典 Request-Response 交互模型，每一个请求都占用一个 Web 线程不释放的话，Web
容器的线程则会很快消耗殆尽，而这些线程大部分时间处于空闲等待的状态。这也就是为什么 Comet 风格服务非常期待异步处理的原因，希望 Web 线程不需要同步的、一对一的处理客户端请求，能做到一个 Web 线程处理多个客户端请求。

　

        呵呵，不会是有数字要求吧---