基于 WebSocket 的 MQTT 移动推送方案
WebSphere MQ Telemetry Transport 簡(jiǎn)介
WebSphere MQ Telemetry Transport (MQTT) 是一項(xiàng)異步消息傳輸協(xié)議，是 IBM 在分析了他們的客戶(hù)在其業(yè)務(wù)中使用 WebSphere MQ 消息傳遞的情況（包括通過(guò)它傳遞數(shù)據(jù)）之后專(zhuān)門(mén)為物聯(lián)網(wǎng)所定制的重要的輕量級(jí)消息傳輸協(xié)議。IBM 發(fā)現(xiàn)，數(shù)據(jù)經(jīng)常是在企業(yè)外部的遠(yuǎn)程位置生成的，而且數(shù)據(jù)在從遠(yuǎn)程位置到達(dá)企業(yè)之前通常要經(jīng)歷一個(gè)復(fù)雜的過(guò)程。這時(shí)往往將數(shù)據(jù)人工輸入計(jì)算機(jī)，然后只能通過(guò) WebSphere MQ Enterprise 消息傳遞系統(tǒng)傳輸。而 MQTT 的開(kāi)發(fā)將 WebSphere MQ 消息傳遞的應(yīng)用范圍延伸到這些遠(yuǎn)程位置。
WebSphere MQ 遙測(cè)傳輸 (MQTT) 是輕量級(jí)基于代理的發(fā)布 / 訂閱的消息傳輸協(xié)議，設(shè)計(jì)思想是開(kāi)放、簡(jiǎn)單、輕量、易于實(shí)現(xiàn)。這些特點(diǎn)使它適用于受限環(huán)境。例如，但不僅限于此：
- 網(wǎng)絡(luò)代價(jià)昂貴，帶寬低、不可靠。
- 在嵌入設(shè)備中運(yùn)行，處理器和內(nèi)存資源有限。
該協(xié)議的特點(diǎn)有：
- 使用發(fā)布 / 訂閱消息模式，提供一對(duì)多的消息發(fā)布，解除應(yīng)用程序耦合。
- 對(duì)負(fù)載內(nèi)容屏蔽的消息傳輸。
- 使用 TCP/IP 提供網(wǎng)絡(luò)連接。
- 有三種消息發(fā)布服務(wù)質(zhì)量：
- "至多一次"，消息發(fā)布完全依賴(lài)底層 TCP/IP 網(wǎng)絡(luò)。會(huì)發(fā)生消息丟失或重復(fù)。這一級(jí)別可用于如下情況，環(huán)境傳感器數(shù)據(jù)，丟失一次讀記錄無(wú)所謂，因?yàn)椴痪煤筮€會(huì)有第二次發(fā)送。
- "至少一次"，確保消息到達(dá)，但消息重復(fù)可能會(huì)發(fā)生。
- "只有一次"，確保消息到達(dá)一次。這一級(jí)別可用于如下情況，在計(jì)費(fèi)系統(tǒng)中，消息重復(fù)或丟失會(huì)導(dǎo)致不正確的結(jié)果。
- 小型傳輸，開(kāi)銷(xiāo)很小（固定長(zhǎng)度的頭部是 2 字節(jié)），協(xié)議交換最小化，以降低網(wǎng)絡(luò)流量。
- 使用 Last Will 和 Testament 特性通知有關(guān)各方客戶(hù)端異常中斷的機(jī)制。
推送服務(wù)
推送服務(wù)表現(xiàn)為客戶(hù)端能自動(dòng)收到服務(wù)器發(fā)送過(guò)來(lái)的數(shù)據(jù)和信息。其目的都是為了給最終客戶(hù)方便有效地發(fā)送最新消息或者數(shù)據(jù)。而且推送的模式對(duì)以前的數(shù)據(jù)訪問(wèn)方式提供很好的補(bǔ)充和發(fā)展。首先，給最終用戶(hù)帶來(lái)了很好的使用體驗(yàn)，可以實(shí)時(shí)的獲取自己感興趣的信息，與此同時(shí)，給服務(wù)器端的應(yīng)用商，也提供了更為便捷和主動(dòng)的數(shù)據(jù)，服務(wù)發(fā)布方式，使得應(yīng)用商能夠控制信息發(fā)布的頻率和時(shí)間，從而能更精準(zhǔn)的投送的最終用戶(hù)。
推送服務(wù)本質(zhì)上是服務(wù)器主動(dòng)將消息，數(shù)據(jù)發(fā)送到客戶(hù)端，而不是客戶(hù)端主動(dòng)去服務(wù)器請(qǐng)求數(shù)據(jù)。這種推送只需要客戶(hù)端與服務(wù)器連接后，在有數(shù)據(jù)的情況下，服務(wù)器端馬上將數(shù)據(jù)發(fā)送到客戶(hù)端。這里的客戶(hù)端可以是多種類(lèi)型的，比如比較常見(jiàn)的瀏覽器，移動(dòng)應(yīng)用等等。
推送服務(wù)的實(shí)現(xiàn)方式大致可分為 Poll 和 Push 模式。
- Poll 模式
Poll 模式，本質(zhì)上是"偽推送"模式，或者叫短輪詢(xún)模式。是客戶(hù)端通過(guò)設(shè)定固定的時(shí)間間隔，然后在時(shí)間間隔到達(dá)后，客戶(hù)端主動(dòng)向服務(wù)器發(fā)送請(qǐng)求，去更新是否有新數(shù)據(jù)。這種模式的特點(diǎn)是，客戶(hù)端需要不停的輪詢(xún)?cè)L問(wèn)服務(wù)器獲取信息，其時(shí)間間隔設(shè)定無(wú)法真正體現(xiàn)實(shí)時(shí)推送，間隔太長(zhǎng)容易導(dǎo)致信息不能實(shí)時(shí)的更新，間隔太短，客戶(hù)端需要發(fā)送很多不必要的連接請(qǐng)求，耗費(fèi)很多網(wǎng)絡(luò)流量和服務(wù)器開(kāi)銷(xiāo)。比如在移動(dòng)終端上，此類(lèi)模式會(huì)在設(shè)備電能消耗，網(wǎng)絡(luò)流量使用方面存在很多瓶頸。
- Push 模式
Push 模式，一般意義上使用長(zhǎng)連接去建立一個(gè)客戶(hù)端到服務(wù)器的雙向數(shù)據(jù)通道，只要在連接建立后，一旦一方有數(shù)據(jù)更新，就可以馬上通過(guò)雙向的數(shù)據(jù)通道向?qū)Ψ桨l(fā)送數(shù)據(jù)，平時(shí)在沒(méi)有數(shù)據(jù)時(shí)，通過(guò)一些心跳等機(jī)制維持通道連接。Push 模式的特點(diǎn)，簡(jiǎn)化的客戶(hù)端的開(kāi)發(fā)，數(shù)據(jù)能近乎實(shí)時(shí)的發(fā)送到對(duì)方。但其在設(shè)備資源消耗和網(wǎng)絡(luò)流量控制方面，根據(jù)其使用的不同協(xié)議會(huì)有很大不同，特別是在移動(dòng)推送領(lǐng)域，長(zhǎng)連接對(duì)移動(dòng)設(shè)備電量和網(wǎng)絡(luò)流量的消耗要求較高。同時(shí)，由于需要維護(hù)長(zhǎng)連接，對(duì)服務(wù)器在高并發(fā)連接的處理能力和性能也有很高要求。
移動(dòng)推送服務(wù)
推送服務(wù)在很多領(lǐng)域都有發(fā)展，但特別在移動(dòng)領(lǐng)域，由于其飛速發(fā)展，給推送服務(wù)帶來(lái)了很多新的機(jī)遇和挑戰(zhàn)。首先，移動(dòng)市場(chǎng)規(guī)模越來(lái)越大，終端種類(lèi)和數(shù)量越來(lái)越多，使得推送服務(wù)的的重要性越來(lái)越凸顯；其次，傳統(tǒng)的"偽推送"模式已越來(lái)越不能滿足其需要，需要發(fā)展新的推送的技術(shù)，這促使了很多新的協(xié)議和框架的出現(xiàn)；但是，由于移動(dòng)領(lǐng)域的終端設(shè)備和網(wǎng)絡(luò)情況的特點(diǎn)，對(duì)推送的協(xié)議和框架又提出了新的挑戰(zhàn)，比如：移動(dòng)終端的計(jì)算和存儲(chǔ)資源的限制，移動(dòng)終端的電量消耗的限制，移動(dòng)網(wǎng)絡(luò)流量和成本的控制等等。主流的移動(dòng)推送解決方案如下：
- SMS 短信
作為傳統(tǒng)的消息通訊，在新型移動(dòng)環(huán)境下，在網(wǎng)絡(luò)成本方面的考量使其地位有逐漸邊緣化的趨勢(shì)。
- HTTP 輪詢(xún)
使用定時(shí)的 HTTP 輪詢(xún)方式，及客戶(hù)端在一定的時(shí)間間隔里去重復(fù)向服務(wù)器請(qǐng)求數(shù)據(jù)更新，屬于"偽推送"，由于其協(xié)議復(fù)雜冗余，輪詢(xún)間隔的不準(zhǔn)確，耗費(fèi)了不必要的流量，增加了終端用戶(hù)網(wǎng)絡(luò)成本等因素，現(xiàn)有的這種方式已經(jīng)不適合做移動(dòng)推送服務(wù)。
- XMPP
XMPP 是基于 XML 的通訊協(xié)議，此協(xié)議已基本上完成了標(biāo)準(zhǔn)化，成熟，強(qiáng)大，可擴(kuò)展性強(qiáng)。但正是由于其協(xié)議復(fù)雜，冗余的設(shè)計(jì)，成為其在移動(dòng)設(shè)備上短板，比如協(xié)議的復(fù)雜帶來(lái)其協(xié)議棧的耗電增加，冗余的設(shè)計(jì)使得網(wǎng)絡(luò)流量偏大，用戶(hù)成本增加。
- 私有廠商協(xié)議和平臺(tái)
私有廠商推出的推送服務(wù)，由于其協(xié)議私有，其傳輸效率和質(zhì)量上無(wú)法量化和考證，而且還往往無(wú)法實(shí)現(xiàn)跨平臺(tái)推送。同時(shí)，有些廠商提供的消息服務(wù)器不具備公開(kāi)性，導(dǎo)致在用戶(hù)數(shù)據(jù)安全性特別是服務(wù)器掌控方面存在擔(dān)心。
IBM 基于 WebSocket 的 MQTT 跨平臺(tái)推送服務(wù)方案
IBM 通過(guò)對(duì)現(xiàn)有移動(dòng)推送平臺(tái)比較之后，對(duì)其中存在的問(wèn)題和缺陷做了很好的分析。這些問(wèn)題集中體現(xiàn)在如下方面：
- 在網(wǎng)絡(luò)方面
如何適應(yīng)現(xiàn)有網(wǎng)絡(luò)的不可靠，很好的保障數(shù)據(jù)發(fā)送可靠性
如何降低網(wǎng)絡(luò)流量，從而節(jié)省網(wǎng)絡(luò)成本
- 在移動(dòng)設(shè)備方面
如何降低對(duì)設(shè)備能力的要求，特別是適應(yīng)計(jì)算和存儲(chǔ)弱的設(shè)備
如何降低對(duì)設(shè)備電量的消耗，滿足設(shè)備電源能力的不足
如何降低平臺(tái)依賴(lài)性，真正實(shí)現(xiàn)跨移動(dòng)設(shè)備平臺(tái)
- 在數(shù)據(jù)方面
缺少對(duì)數(shù)據(jù)安全性的保障，特別是對(duì)服務(wù)器的掌控
缺少對(duì)大量數(shù)據(jù)的監(jiān)測(cè)，優(yōu)化
IBM 針對(duì)上面問(wèn)題，結(jié)合 MQTT 和 WebSocket，提出了更智慧的移動(dòng)推送服務(wù)解決方案。
圖 1. IBM 移動(dòng)推送服務(wù)解決方案
方案中，服務(wù)器端使用 WebSphere MQ 作為 MQTT 的 Server，在移動(dòng)設(shè)備中嵌入 MQTT 的客戶(hù)端，并通過(guò)客戶(hù)端建立到服務(wù)器的雙向數(shù)據(jù)通道，然后在后臺(tái)來(lái)自不同應(yīng)用的數(shù)據(jù)通過(guò) WebSphere MQ 推送到移動(dòng)終端。那么，這樣的解決方案，會(huì)有什么特點(diǎn)能夠很好的解決和優(yōu)化上面關(guān)于業(yè)界移動(dòng)推送服務(wù)解決方案中存在的普遍問(wèn)題，或者說(shuō)此方案有什么自身的優(yōu)勢(shì)。
- 移動(dòng)設(shè)備
能在 8bit 位處理器上很好的運(yùn)行 C /JavaScript/Java 的 client 庫(kù)分別只有 30/75/100KB
在移動(dòng)設(shè)備上耗電率低，大約只需要 HTTP 的一半
通過(guò)使用基于 WebSocket 的 MQTT 客戶(hù)端 JavaScript API，符合 Hybrid 開(kāi)發(fā)潮流，只要設(shè)備的瀏覽器支持 WebSocket，就能很輕松實(shí)現(xiàn)多移動(dòng)平臺(tái)的跨越
- 很好的適應(yīng)各種復(fù)雜網(wǎng)絡(luò)，特別是受限網(wǎng)絡(luò)
預(yù)期并適應(yīng)頻繁的網(wǎng)絡(luò)中斷，能應(yīng)對(duì)低速、低質(zhì)量的網(wǎng)絡(luò)
壓縮優(yōu)化過(guò)后的協(xié)議，可以有效降低網(wǎng)絡(luò)流量，從而節(jié)約網(wǎng)絡(luò)成本
完成同樣的數(shù)據(jù)通信，MQTT 只需要 HTTP 約 1/4 得數(shù)據(jù)流量
- 發(fā)布 - 訂閱的消息通信協(xié)議，允許一條消息只發(fā)布一次，便可被多個(gè)消費(fèi)端（應(yīng)用程序 / 設(shè)備）所接收
實(shí)現(xiàn)系統(tǒng)間松耦合，簡(jiǎn)化開(kāi)發(fā)，方便擴(kuò)展，整合。
- 提供靈活便捷的系統(tǒng)整合能力
使用 MQ，MB 提供可靠系統(tǒng)內(nèi)系統(tǒng)整合和通信
Cast Iron 強(qiáng)大的系統(tǒng)間整合帶來(lái)巨大的靈活性
- 提供豐富的安全性
使用 SSL 提供的認(rèn)證和加密來(lái)保證傳輸安全性
通過(guò) JAAS 接口提供的身份認(rèn)證
OAM 用于資源層面的授權(quán)
- 強(qiáng)大的性能提高系統(tǒng)的高可靠性
高連接數(shù)下系統(tǒng)低計(jì)算資源使用
高連接數(shù)下系統(tǒng)高信息處理速度
- 提供多種消息服務(wù)質(zhì)量，滿足不同場(chǎng)景需求
0 ：消息最多被傳遞一次，比如一般類(lèi)廣告，通知
1 ：消息會(huì)被傳遞但可能會(huì)重復(fù)傳遞，比如賬戶(hù)余額通知
2 ：消息保證傳遞且僅有一次傳遞，比如交易支付批復(fù)通知
應(yīng)用場(chǎng)景
本文是通過(guò)介紹使用 WebSphere MQ Telemetry 以及其 SDK 組件中自帶的 MQTT 基本客戶(hù)端（WebSocket API）實(shí)現(xiàn)一個(gè) iOS 設(shè)備的推送應(yīng)用場(chǎng)景，來(lái)使讀者對(duì)使用基于 MQTT 協(xié)議的 WebSphere MQ Telemetry 來(lái)構(gòu)建物移動(dòng)推送服務(wù)解決方案有進(jìn)一步的理解，并能夠自己動(dòng)手開(kāi)發(fā)相應(yīng)的解決方案。
該方案通過(guò) WebSphere MQ Telemetry 自帶的 MQTT 基本客戶(hù)機(jī) WebSocket JavaScript API 來(lái)實(shí)現(xiàn)客戶(hù)端到服務(wù)器的連通。實(shí)現(xiàn)的場(chǎng)景如下：
- Mobile 用戶(hù)相互通訊（文本，語(yǔ)音，圖片）
- 后臺(tái)應(yīng)用向 Mobile 用戶(hù)推送相關(guān)信息（廣告，通知等等）
圖 2. 移動(dòng)推送服務(wù)場(chǎng)景
開(kāi)發(fā)步驟及流程
整個(gè)開(kāi)發(fā)會(huì)涉及到移動(dòng)端開(kāi)發(fā)和服務(wù)器端配置，以下將會(huì)分別介紹。
Note：開(kāi)發(fā)工具使用 Worklight，Xcode，WebSphere MQ Explorer。
客戶(hù)端開(kāi)發(fā)
Worklight 平臺(tái)為開(kāi)發(fā)基于 Web 技術(shù)的手機(jī)客戶(hù)端 App 提供了一套完整的解決方案，從開(kāi)發(fā)、部署、測(cè)試到發(fā)布均可在這個(gè)平臺(tái)上完成。App 用 HTML，CSS 和 Javascript 寫(xiě)成，之后被擴(kuò)展成桌面的（Windows，Mac，Linux），互聯(lián)網(wǎng)的（Facebook 等），本地移動(dòng)設(shè)備上的（iOS，Android，RIM 和 Windows Phone）應(yīng)用程序。開(kāi)發(fā)者還能把一些流行的 Javascript 構(gòu)架如 jQuery Mobile，Sencha 和 Dojo 整合到 Worklight 中。而且 App 的本地運(yùn)行時(shí)也能用本地代碼來(lái)編寫(xiě)和修改。
MQTT WebSocket JavaScript API 的功能描述如下：
- Connect 連接
MQTT 客戶(hù)端負(fù)責(zé)向 MQTT 服務(wù)器發(fā)起連接操作，并開(kāi)始計(jì)時(shí)，在超時(shí)期里接收到正確連接響應(yīng)，則連接成功，負(fù)責(zé)連接超時(shí)。任何數(shù)據(jù)的發(fā)送或者收到，都將啟動(dòng)新的超時(shí)計(jì)時(shí)，在整個(gè)超時(shí)完成后沒(méi)有數(shù)據(jù)的發(fā)送或者接收時(shí)，發(fā)送心跳以維持連接狀態(tài)。
- DisConnect 斷開(kāi)連接
MQTT 客戶(hù)端或者服務(wù)器發(fā)起連接斷開(kāi)命令。在發(fā)出連接斷開(kāi)命令后，開(kāi)始超時(shí)計(jì)時(shí)，在超時(shí)內(nèi)成功收到斷開(kāi)響應(yīng)，雙方設(shè)置其相應(yīng)連接狀態(tài)為斷開(kāi)；超時(shí)后尚未成功接收響應(yīng)，則開(kāi)始重發(fā)連接命令，直到重發(fā)次數(shù)到達(dá)系統(tǒng)設(shè)置上限。否則，設(shè)置對(duì)應(yīng)原因。
- Subscribe 訂購(gòu)
在雙方連接建立后，MQTT 客戶(hù)端發(fā)送訂購(gòu)消息，來(lái)訂購(gòu)主題，并設(shè)置相應(yīng)質(zhì)量服務(wù)級(jí)別，在接收到訂購(gòu)確認(rèn)后，自動(dòng)接收在此主題上的任何消息。
- UnSubscribe 取消訂購(gòu)
在雙方連接建立后，MQTT 客戶(hù)端發(fā)送取消訂購(gòu)消息，來(lái)取消訂購(gòu)主題，在接收到取消訂購(gòu)確認(rèn)后，在原來(lái)主題上的任何消息將不再推送到此客戶(hù)端。
- Publish 發(fā)布
在雙方連接建立后，MQTT 客戶(hù)端將業(yè)務(wù)數(shù)據(jù)放入發(fā)布消息的消息體中，通過(guò)發(fā)布消息，發(fā)布在某主題上，此消息按照不同的消息服務(wù)質(zhì)量級(jí)別，發(fā)布到不同的訂購(gòu)者客戶(hù)端。
- Will 主題和消息
在 MQTT 客戶(hù)端連接時(shí)設(shè)置，設(shè)定在自己連接中斷后，自動(dòng)往 Will 主題上發(fā)送的通知消息。
圖 3. WorkLight 工程
圖 4. 新建 Worklight Environment
然后在工程中就生成的為 iPad 開(kāi)發(fā)的模板。
圖 5. iPad 開(kāi)發(fā)模板
圖 6. 拷貝 MQTT Client 的 JS 庫(kù)文件
圖 7. 替換原有展現(xiàn)頁(yè)面
然后在 application：WebSocketMQTTApp 上右鍵，選擇 Run As -> Build All and Deploy
圖 8. 打開(kāi) Xcode Project
在 Xcode 里，在 Build 成功后，選擇配置過(guò)的 iOS 設(shè)備安裝。
服務(wù)器開(kāi)發(fā)和配置
安裝 WebSphere MQ 7.5.0.1 版本，在安裝過(guò)程中選擇 Telemetry 組件，安裝完后打開(kāi) WebSphere MQ 管理界面 WebSphere MQ Explorer。
圖 9. WebSphere MQ Explorer
展開(kāi)新創(chuàng)建的 Queue Manager，點(diǎn)擊 Telemetry 并在右邊的窗口中，選擇 Define sample configuration...
圖 10. 定義 Telemetry 服務(wù)
圖 11. 配置 Telemetry
圖 12. 支持 MQTT 連接的通道
圖 13. MQTT Client Utility 工具
服務(wù)器端的配置就完成了。
部署和驗(yàn)證
本文將通過(guò)模擬移動(dòng)推送服務(wù)中的 2 個(gè)基本場(chǎng)景來(lái)驗(yàn)證。
- 兩個(gè) iPad 設(shè)備通訊模擬 Mobile 用戶(hù)相互通訊
- MQTT Client Utility 向 iPad 發(fā)送消息模擬后臺(tái)應(yīng)用向 Mobile 用戶(hù)推送相關(guān)信息
- Server：WebSphere MQ 的安裝機(jī)器的 IP
- Port：在 WebSphere MQ 里配置的 MQTT 的通道的端口號(hào)，默認(rèn)是 1883
- Client ID：頁(yè)面會(huì)生成一個(gè)默認(rèn)的，也可以自定義
- Topic Name：用于發(fā)布或者訂購(gòu)的主題，模擬通訊時(shí)，每個(gè)客戶(hù)端有固定的主題，比如：iPad A 主題為 iPadA，iPad B 的主題為 iPadB。在通訊時(shí)每個(gè)客戶(hù)端訂購(gòu)自己的主題接收別的客戶(hù)端發(fā)送來(lái)的消息，同時(shí)給別的客戶(hù)端的主題發(fā)送消息。
- QoS：質(zhì)量服務(wù)等級(jí)
啟動(dòng) App 后，在填寫(xiě) Server，port 和 Client Id 后，點(diǎn)擊連接（Connect），然后分別在訂閱的 Topic Name 中填寫(xiě)自己要監(jiān)聽(tīng)的主題：iPadA 或者 iPadB。最后，在發(fā)布 Publish 的 Topic 中填入要對(duì)話的對(duì)方的主題：iPadB 或者 iPadA，輸入想發(fā)送的信息后，點(diǎn)擊發(fā)送就可以開(kāi)始兩個(gè) iPad 之間的通訊了。這里只是簡(jiǎn)單展現(xiàn)，除了文本通訊還可以實(shí)現(xiàn)語(yǔ)音，文件，照片通訊分享等。
圖 14. iPadA
圖 15. iPadB
通過(guò)以上兩個(gè)截圖，驗(yàn)證了兩個(gè) iPad 通過(guò)基于 WebSocket 的 MQTT 協(xié)議，實(shí)現(xiàn)了通訊，相互給對(duì)方發(fā)送了消息。
Note: 在 App 部署到 iPad 上后，如果 WorkLight 的服務(wù)器更換了，修改應(yīng)用的 WorkLight Server 地址如下
圖 16. 應(yīng)用的 WorkLight 服務(wù)器地址
- Topic Name：iPadPush
- Message：This is message from backend system application.
后端采用 JMS 方式發(fā)送數(shù)據(jù)
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 | import javax.jms.Connection; import javax.jms.JMSException; import javax.jms.Message; import javax.jms.MessageProducer; import javax.jms.Session; import com.ibm.mq.jms.MQConnectionFactory; public class JMSSender { ????private Connection conn; ????private Session sess; ????private MessageProducer sender; ????public static void main(String[] args) { ????????JMSSender jmsSender = new JMSSender(); ????????jmsSender.createSender(); ????????jmsSender.closeSender(); ????} ????private void closeSender() { ????????try { sender.close(); sess.close(); conn.close(); System.out.println("JMS Sender closed"); ????????} catch (JMSException e) { e.printStackTrace(); if (e.getLinkedException() != null) { ????e.getLinkedException().printStackTrace(); } ????????} ????} ????private void createSender() { ????????MQConnectionFactory connFact = new MQConnectionFactory(); ????????try { // We are connecting to queue manager using client mode connFact.setQueueManager("XRNEW"); connFact.setHostName("localhost"); connFact.setPort(1414); System.out.println("Model"+connFact.getTransportType()); //connFact.setTransportType(1); System.out.println("Model"+connFact.getTransportType()); conn = connFact.createConnection(); sess = conn.createSession(false, Session.AUTO_ACKNOWLEDGE); sender = sess.createProducer(sess ????????.createQueue("queue://iPadA/iPadPush")); Message msg = sess.createTextMessage( ???????"This is message from backend system application."); msg.setJMSExpiration(10000); sender.setTimeToLive(10000); sender.send(msg); System.out ????????.println("JMS Sender started and published message to topic iPadPush"); ????????} catch (JMSException e) { e.printStackTrace(); if (e.getLinkedException() != null) { ????e.getLinkedException().printStackTrace(); } ????????} ????} } |
圖 17. 終端接收后端推送的消息
結(jié)束語(yǔ)
本文通過(guò)介紹使用 WebSphere MQ Telemetry 以及其 SDK 組件中自帶的 MQTT 基本客戶(hù)機(jī)的 WebSocket JavaScript API 開(kāi)發(fā)一個(gè) App，并通過(guò)實(shí)現(xiàn)通用的移動(dòng)推送服務(wù)應(yīng)用場(chǎng)景來(lái)使讀者對(duì)使用基于 MQTT 協(xié)議的 WebSocket JavaScript API 來(lái)構(gòu)建移動(dòng)推送服務(wù)解決方案有進(jìn)一步的理解，并能夠自己動(dòng)手開(kāi)發(fā)相應(yīng)的推送解決方案。
總結(jié)
以上是生活随笔為你收集整理的基于 WebSocket 的 MQTT 移动推送方案的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： SSM框架之MyBatis3专题5：My
- 下一篇： Java基础-面向对象第二特征之继承（I