三年前，客户端与服务器端的全双工双向通信作为一个很重要的功能被纳入到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模式的消息驱动的架构来说，我们也查看了许多现有的方法，我们喜欢这种真正的消息代理的处理能力，也同样喜欢一个网页应用使用 中心处理模块的方式。毕竟，我们必须采用一个消息驱动的架构，但同时我们也是网络开发者，更习惯建立网页应用，所以结果不能和我们已知的相差太大。