stompjava_websocket怎样用java

㈠春季角ngstomp WebSocket控制器不执行问题，怎么解决

两年前，客户端与服务器端的全双工双向通信作为一个很重要的功能被纳入到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，接着转发给绑定此消息的客户端。下面的流程图就是描述这种路径的：

这个路径阐述了运行在多服务器和云环境中的大量应用实例能够通过RabbitMQ服务广播到达所有连接的客户端，而不论此时客户端连接的是哪一个应用实例。此外，也很容易从HTTP请求处理方法广播消息到连接的客户端或者应用的其他部分。
如需更详尽的技术概览说明，请移步spring.io上的M2 blog post，运行股票投资组合样例，或者浏览spring开发频道的在线论坛。我们最近发布了RC1候选版。如果你有一个应用的想法，现在是努力去实现和提供反馈绝佳时机。
如果你恰好在伦敦区域或者很容易到达这里，在11月的14、15日两天，这里有一个spring 交流会。届时会有spring关键工程师代表出席，并会发布最伟大的spring4.0框架和我们支持WebSocket的STOMP协议。

㈡ websocket怎样用java

java7 开始支持WebSocket，并且只是做了定义，并未实现
tomcat7及以上，jetty 9.1及以上实现了WebSocket，其他容器没有研究
spring 4.0及以上增加了WebSocket的支持
spring 支持STOMP协议的WebSocket通信
WebSocket 作为java的一个扩展，它属于javax包目录下，通常需要手工引入该jar，以tomcat为例，可以在 tomcat/lib 目录下找到 websocket-api.jar

㈢请用白话讲解ActiveMQ的用途

用途就是用来处理消息，也就是处理JMS的。消息队列在大型电子商务类网站，如京东、淘宝、去哪儿等网站有着深入的应用，队列的主要作用是消除高并发访问高峰，加快网站的响应速度。

在不使用消息队列的情况下，用户的请求数据直接写入数据库，高发的情况下，会对数据库造成巨大的压力，同时也使得系统响应延迟加剧，但使用队列后，用户的请求发给队列后立即返回。

例如：不能直接给用户提示订单提交成功，京东上提示：“您提交了订单，请等待系统确认”再由消息队列的消费者进程从消息队列中获取数据，异步写入数据库。

由于消息队列的服务处理速度远快于数据库，因此用户的响应延迟可得到有效改善。

(3)stompjava扩展阅读：

ActiveMQ主要有以下几种使用场景

1、异步调用。

2、一对多通信。

3、做多个系统的集成、同构、异构。

4、作为RPC的替代。

5、多个应用相互解耦。

6、作为事件驱动架构的幕后支撑。

7、为了提高系统的可伸缩性。

㈣《HTML5WebSocket权威指南》epub下载在线阅读，求百度网盘云资源

《HTML5 WebSocket权威指南》（Vanessa Wang）电子书网盘下载免费在线阅读

链接：https://pan..com/s/1Ebw88ohgAiNkHMQ1L0kVGg

提取码：8jxi

书名：HTML5 WebSocket权威指南

作者：Vanessa Wang

译者：姚军

豆瓣评分：7.0

出版社：机械工业出版社

出版年份：2014-3

页数：193

内容简介：

《HTML5 WebSocket权威指南》是HTML5 WebSocket领域最权威的着作之一，它系统、全面地讲解了HTML5 WebSocket的各个方面，是Web开发人员和架构师学习WebSocket的最佳选择。书中讨论了基于WebSocket的架构师如何减少不必要的网络开销和延迟层，如何通过WebSocket对广泛使用的协议（如XMPP和STOMP）进行分层，如何保护WebSocket连接和在企业部署基于 WebSocket的应用程序。主要内容包括： WebSocket API和协议、WebSocket协议通信的例子、WebSocket的安全性和企业部署、内置即时通信和聊天应用程序的WebSocket与XMPP、通过WebSocket的STOMP实现发布/订阅消息传递协议，以及用远程帧缓冲协议实现VNC。

作者简介：

vanessa wang，html5领域的布道者和实践者，热衷于html5和websocket的研究，是旧金山html5用户组的联合组织者，负责组织html5和相关技术的社区活动．vanessa目前是kaazing公司的技术出版经理，15年来一直坚持撰写技术文章。kaazing是一家软件公司，旨在使用新的websocket标准改进企业和客户通过web通信的方式。写作之余，她喜欢打跆拳道、骑自行车和拉大提琴。

frank salim，google公司资深软件工程师，拥有pomona学院的计算机科学学位。曾经是kaazing公司最早的工程师之一，协助建立了websocket网关和客户端策略。2010年，frank与人合着了《pro html5 programming》(apress)一书。编程之余，他喜欢阅读、绘画和单排轮滑。

peter moskovits，kaazing公司实时解决方案负责人。peter与架构师和开发人员社区紧密协作，构建和部署最好的web解决方案。在加入kaazing之前，peter担任过多种产品的管理工作，并曾经负责oracie的门户产品策略．peter经常在会议和业界活动上发表演讲，包括goto、yow!、javaone、oracle openworld、html5deconf、devcon5和各种用户组会议。他还是《oracle webcenter 11g handbook》的合着者。

㈤ Activemq的stomp怎么能一条一条地接收消息，而不是全部接收

ActiveMQ另问题要软件能挂掉挂掉怕怕挂掉信息给丢所本节析几种持久化式：

、持久化文件
ActiveMQ默认支持种式要发消息设置消息持久化

打安装目录配置文件：

D:\ActiveMQ\apache-activemq\conf\activemq.xml越80行发现默认配置项：

注意使用kahaDB基于文件支持事务消息存储器靠高性能扩展消息存储器

设计初衷使用简单并尽能快KahaDB索引使用transaction log并且所destination使用index测试表明：用于产环境支持1万active connection每connection独立queue该表现已经足矣应付部需求

再发送消息候改变第二参数：

MsgDeliveryMode.Persistent

Message保存式2种
PERSISTENT：保存磁盘consumer消费message删除
NON_PERSISTENT：保存内存消费message清除
注意：堆积消息太能导致内存溢

打产者端发送消息：

wps30F4.tmp

启消费者端同管理界面查看：

wps3105.tmp

发现消息等待没持久化ActiveMQ宕机重启消息丢失我现修改文件持久化重启ActiveMQ消费者仍能够收消息

wps3106.tmp

二、持久化数据库
我支持Mysql例先载mysql-connector-java-5.1.34-bin.jar包放：

D:\ActiveMQ\apache-activemq\lib目录

打并修改配置文件：

复制代码
<beans
xmlns=""
xmlns:xsi=""
xsi:schemaLocation=" /spring-beans.xsd
/activemq-core.xsd">

file:${activemq.conf}/credentials.properties

<bean id="logQuery" class="org.fusesource.insight.log.log4j.Log4jLogQuery"
lazy-init="false" scope="singleton"
init-method="start" destroy-method="stop">















-

㈥如何使用java 收发stomp协议

STOMP即Simple (or Streaming) Text Orientated Messaging Protocol，简单(流)文本定向消息协议，它提供了一个可互操作的连接格式，允许STOMP客户端与任意STOMP消息代理（Broker）进行交互。STOMP协议由于设计简单，易于开发客户端，因此在多种语言和多种平台上得到广泛地应用。
STOMP协议的前身是TTMP协议（一个简单的基于文本的协议），专为消息中间件设计。
STOMP是一个非常简单和容易实现的协议，其设计灵感源自于HTTP的简单性。尽管STOMP协议在服务器端的实现可能有一定的难度，但客户端的实现却很容易。例如，可以使用Telnet登录到任何的STOMP代理，并与STOMP代理进行交互。
STOMP协议与2012年10月22日发布了最新的STOMP 1.2规范。

㈦如何快速搭建一个微服务架构

什么是微服务？

微服务(Microservices Architecture)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

微服务的概念源于2014年3月Martin Fowler所写的文章“Microservices” martinfowler.com/articles/mi…

单体架构(Monolithic Architecture )

企业级的应用一般都会面临各种各样的业务需求，而常见的方式是把大量功能堆积到同一个单体架构中去。比如：常见的ERP、CRM等系统都以单体架构的方式运行，同时由于提供了大量的业务功能，随着功能的升级，整个研发、发布、定位问题，扩展，升级这样一个“怪物”系统会变得越来越困难。

这种架构模式就是把应用整体打包部署，具体的样式依赖本身应用采用的语言，如果采用java语言，自然你会打包成war包，部署在Tomcat或者Jetty这样的应用服务器上，如果你使用spring boot还可以打包成jar包部署。其他还有Rails和Node.js应用以目录层次的形式打包

上图：单体架构

大部分企业通过SOA来解决上述问题，SOA的思路是把应用中相近的功能聚合到一起，以服务的形式提供出去。因此基于SOA架构的应用可以理解为一批服务的组合。SOA带来的问题是，引入了大量的服务、消息格式定义和规范。

多数情况下，SOA的服务直接相互独立，但是部署在同一个运行环境中（类似于一个Tomcat实例下，运行了很多web应用）。和单体架构类似，随着业务功能的增多SOA的服务会变得越来越复杂，本质上看没有因为使用SOA而变的更好。图1，是一个包含多种服务的在线零售网站，所有的服务部署在一个运行环境中，是一个典型的单体架构。

单体架构的应用一般有以下特点：

微服务架构（Microservices Architecture）

微服务架构的核心思想是，一个应用是由多个小的、相互独立的、微服务组成，这些服务运行在自己的进程中，开发和发布都没有依赖。不同服务通过一些轻量级交互机制来通信，例如 RPC、HTTP 等，服务可独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立的团队来维护。简单的来说，一个系统的不同模块转变成不同的服务！而且服务可以使用不同的技术加以实现！

上图：微服务架构

微服务设计

那我们在微服务中应该怎样设计呢。以下是微服务的设计指南：

微服务消息

在单体架构中，不同功能之间通信通过方法调用，或者跨语言通信。SOA降低了这种语言直接的耦合度，采用基于SOAP协议的web服务。这种web服务的功能和消息体定义都十分复杂，微服务需要更轻量的机制。

同步消息 REST

同步消息就是客户端需要保持等待，直到服务器返回应答。REST是微服务中默认的同步消息方式，它提供了基于HTTP协议和资源API风格的简单消息格式，多数微服务都采用这种方式（每个功能代表了一个资源和对应的操作）

异步消息 – AMQP, STOMP, MQTT

异步消息就是客户端不需要一直等待服务应答，有应到后会得到通知。某些微服务需要用到异步消息，一般采用AMQP, STOMP, MQTT 这三种通讯协议

消息格式 – JSON, XML, Thrift, ProtoBuf, Avro

消息格式是微服务中另外一个很重要的因素。SOA的web服务一般采用文本消息，基于复杂的消息格式（SOAP）和消息定义（xsd）。微服务采用简单的文本协议JSON和XML，基于HTTP的资源API风格。如果需要二进制，通过用到Thrift, ProtoBuf, Avro。

服务约定 – 定义接口 – Swagger, RAML, Thrift IDL

如果把功能实现为服务，并发布，需要定义一套约定。单体架构中，SOA采用WSDL，WSDL过于复杂并且和SOAP紧耦合，不适合微服务。

REST设计的微服务，通常采用Swagger和RAML定义约定。

对于不是基于REST设计的微服务，比如Thrift，通常采用IDL（Interface Definition Languages），比如Thrift IDL。

微服务集成 (服务间通信)

大部分微服务基于RPC、HTTP、JSON这样的标准协议，集成不同标准和格式变的不再重要。另外一个选择是采用轻量级的消息总线或者网关，有路由功能，没有复杂的业务逻辑。下面就介绍几种常见的架构方式。

点对点方式

点对点方式中，服务之间直接用。每个微服务都开放REST API，并且调用其它微服务的接口。

上图：通过点对点方式通信

很明显，在比较简单的微服务应用场景下，这种方式还可行，随着应用复杂度的提升，会变得越来越不可维护。这点有些类似SOA的ESB，尽量不采用点对点的集成方式。

API-网关方式

API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能个。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。

上图：通过API-网关暴露微服务

所有的业务接口通过API网关暴露，是所有客户端接口的唯一入口。微服务之间的通信也通过API网关。

采用网关方式有如下优势：

目前，API网关方式应该是微服务架构中应用最广泛的设计模式。

消息代理方式

微服务也可以集成在异步的场景下，通过队列和订阅主题，实现消息的发布和订阅。一个微服务可以是消息的发布者，把消息通过异步的方式发送到队列或者订阅主题下。作为消费者的微服务可以从队列或者主题共获取消息。通过消息中间件把服务之间的直接调用解耦。

上图：异步通信方式

通常异步的生产者/消费者模式，通过AMQP, STOMP, MQTT 等异步消息通讯协议规范。

数据的去中心化

单体架构中，不同功能的服务模块都把数据存储在某个中心数据库中。

每个微服务有自己私有的数据库，其它微服务不能直接访问。单体架构，用一个数据库存储所有数据

微服务方式，多个服务之间的设计相互独立，数据也应该相互独立（比如，某个微服务的数据库结构定义方式改变，可能会中断其它服务）。因此，每个微服务都应该有自己的数据库。

每个微服务有自己私有的数据库，其它微服务不能直接访问。每个微服务有自己私有的数据库，其它微服务不能直接访问。

数据去中心话的核心要点：

数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。

微服务架构的优点：

微服务架构的缺点：

微服务的一些想法在实践上是好的，但当整体实现时也会呈现出其复杂性。

关于微服务架构的取舍

㈧ websocket可以java代码发送吗

ava7 开始支持WebSocket，并且只是做了定义，并未实现
tomcat7及以上，jetty 9.1及以上实现了WebSocket，其他容器没有研究
spring 4.0及以上增加了WebSocket的支持
spring 支持STOMP协议的WebSocket通信
WebSocket 作为java的一个扩展，它属于javax包目录下，通常需要手工引入该jar，以tomcat为例，可以在 tomcat/lib 目录下找到 websocket-api.jar

导航:首页 > 编程语言 > stompjava

stompjava

(3)stompjava扩展阅读：

与stompjava相关的资料