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相關的資料