两年前，客户端与服务器端的全双工双向通信作为一个很重要的功能被纳入到WebSocket RFC 6455协议中。在HTML5中，WebSocket已经成为一个流行词，大家对这个功能赋予很多构想，很多时候甚至是不切实际的期望。在这篇文章中，我们将重点介绍下如何通过Spring Framework 4.0来构建一个基于 STMOP协议的WebSocket形式的应用。该应用通过 Message Broker向用户广播消息，并使用SockJS作为浏览器前端通信代码库。

传统的Socket交互需要很多项技术的支持，包括Java applet，XMLHttpRequest，Adobe Flash, ActiveXObject, 各种 Comet和服务端发送事件等等。相较于通过如此繁杂的技术来实现Socket交互，WebSockt就显得简洁易用得多了。但是别高兴得太 早，无论看起来如何诱人，WebSocket现在都还只不过是一个基础而已。即便它确实为WEB的双向通信设定了一些重要的标准，但也还只是第一步。要成 为一个成熟的Socket交互方案，WebSocket还需要解决网络代理设置和浏览器支持等一系列的问题。

WebSocket和REST对比

当你开始接触WebSocket应用时，为了找寻你可能会遇到的问题的答案,你就要快速地浏览一下这篇文章,基于不同的应用类型其中包含了关于 WebSocket是否会替代REST的有趣而不可思议的讨论。该类型(WebSocket)应用相对于偶尔工作的应用(web邮件,新闻更新等)拥有更 强大的能力来面对全天候,实时交互(比如游戏、金融、协作化、可视化等)的复杂情况,无论哪种方式,他都是通常人们所熟悉的,而且REST是我们目前通用 的web应用构建风格.在此并非想通过这样的对比来抵制这些创新,还是让我们看看能从中学到什么吧,而这2个要点还是需要我们去观察才能发现的.

首先，与其他相比，REST是一种在使用无状态和超媒体（链接）时，支持许多URL和少量的HTTP方法的架构方式。与之对应的，WebSocket是一个完全不同的消息模式的架构方式。它不仅仅是一个现有AJAX技术的替代品，更是一个事件驱动的、被动的方法。

第二，REST是基于HTTP的，是在TCP之上建立的一个应用协议，能够提供给我们用于建立应用逻辑的URLs，HTTP方法，请求或者响应头，状态码，和一些其他的关键件。相比之下，WebSocket是一个TCP之上的一个简单层。它就是一个没有被定义内容的可以被分解成消息的字节流。在不对一个消息内容做出假设的情况下，一个框架能够做的很少。当应用做出那样的假定之后，他们就会围绕这些假定来创建自己的框架。

WebSocket协议定义了sub-protocols的使用（即更高级别的协议）但没有引用它。无论哪种方式，应用都需要决定使用什么消息格式——自定义的、特定框架的或标准的。

总之，一个WebSocket式的应用意味着一个事件驱动型的、响应式的消息传递架构。此外工作在WebSocket层次对于大多数应用程序都比较底层，就像现在的大多数Web应用不直接在套接字上编程。

通向实时网络之路

我们可以从现有的各种框架里看到好多使用高等消息API，也在底层使用WebSocket，并在必要时依赖一些其他的备选项（比如HTTP流，长轮询 等）。即便是在今天，也需要依赖于WebSocket和非WebSocket的混合技术。关键区别就在于框架是否提供一个单独的API允许在必要时透明的 回退到非WebSocket传输。

一些框架，比如Socket.io和Vert.x提供轻量级的应用组件为事件和消息指定处理者。另一部分，像CometD，通过内部建立一个消息代理来为绑定和接收消息提供通道。像RabbitMQ或者ActiveMQ也提供了直接从浏览器获取消息代理的选项。当遇到通信架构时，消息代理模式适合用于构造规模应用的。

Spring4.0的方法

Spring4.0 ——也就是当前的候选版本，预计GA于2013年12月发布——一个目标就是为Websocket类型的应用提供支持。它不仅在基于JSR-356容器之 上提供Websocket API 表现良好，而且也为那些不支持或者不允许使用Websocket的浏览器和网络提供了一些候选项。更重要的是，它为在网络应用中构建Websocket形 式的消息架构提供了基础。

我们决定使用SockJS protocol作为候选项。它能为这些候选项，提供着最好和最广泛的传输方式。

对于基于WebSocket模式的消息驱动的架构来说，我们也查看了许多现有的方法，我们喜欢这种真正的消息代理的处理能力，也同样喜欢一个网页应用使用 中心处理模块的方式。毕竟，我们必须采用一个消息驱动的架构，但同时我们也是网络开发者，更习惯建立网页应用，所以结果不能和我们已知的相差太大。

第一步就是选择一个消息的格式。有许多简单消息协议诸如STOMP，MQTT和WAMP。这些都适合应用于网页客户端，并为基本的消息模式提供支持。我们 选择了STOMP，因为它的消息格式是基于HTTP模块化的，同时它也能被广泛的支持。然而，我们的处理模块并没有过分依赖于STOMP，这个处理模块也 能被扩展成支持其他简单协议。

使用STOMP协议能够让我们站在WebSocket的肩膀上。它能够提供一种方法来解析一个消息应该传递给谁，我们又对接收什么样的消息感兴趣。它允许我们像是使用广播消息代理的插件一样使用可用的客户端库文件，比如stomp.js和msg.js。这就是明显的优势。

Spring4提供了STOMP支持。通过两三行的配置，你就可以在网络客户端中把它当做一个轻量级的消息代理。它能够不需要任何服务器代码就自动处理绑 定的事件，并允许控制器方法处理进来的消息和绑定事件。这与如何通过Spring MVC映射HTTP请求到控制器方法是相似的。实际上，一个spring MVC控制器能够被扩展成基于WebSocket的接收STOMP消息的形式。

@Controller public class GreetingController {  @RequestMapping(value=”/greeting”, method=POST) public void httpGreet(String text) { // … }  @MessageMapping(“/greeting”) public void stompGreet(String text) { // … }  }

使用一个全功能的消息代理

在一个全功能的的消息代理中做一个插件也是很容易的。举个例子，RabbitMQ（或者其他STOMP消息代理），能够被用来处理客户端广播消息的绑定。 在这个场景中，Spring仍然是处于网络客户端连接和交换数据的网络应用层。同时，它也当做一个网关来为RabbitMQ服务，允许消息从应用流向 RabbitMQ，接着转发给绑定此消息的客户端。下面的流程图就是描述这种路径的：

Full-Featured-Message-Broker

这个路径阐述了运行在多服务器和云环境中的大量应用实例能够通过RabbitMQ服务广播到达所有连接的客户端，而不论此时客户端连接的是哪一个应用实例。此外，也很容易从HTTP请求处理方法广播消息到连接的客户端或者应用的其他部分。

如需更详尽的技术概览说明，请移步spring.io上的M2 blog post，运行股票投资组合样例，或者浏览spring开发频道的在线论坛。我们最近发布了RC1候选版。如果你有一个应用的想法，现在是努力去实现和提供反馈绝佳时机。

如果你恰好在伦敦区域或者很容易到达这里，在11月的14、15日两天，这里有一个spring 交流会。届时会有spring关键工程师代表出席，并会发布最伟大的spring4.0框架和我们支持WebSocket的STOMP协议。