一種用于融合通信系統(tǒng)的消息引擎的制作方法
【專利摘要】本發(fā)明涉及一種用于融合通信系統(tǒng)的消息引擎。包括：消息隊(duì)列與MQTT代理服務(wù)器，用于實(shí)現(xiàn)基于物聯(lián)網(wǎng)標(biāo)準(zhǔn)協(xié)議的消息通信功能，根據(jù)消息的發(fā)布/訂閱機(jī)制設(shè)計(jì)消息路由規(guī)則，實(shí)現(xiàn)消息的多終端同步機(jī)制；業(yè)務(wù)模塊層，用于實(shí)現(xiàn)消息引擎的各個(gè)業(yè)務(wù)功能；數(shù)據(jù)存儲(chǔ)層，用于為業(yè)務(wù)模塊層提供數(shù)據(jù)支持。本發(fā)明的消息引擎服務(wù)器具有很好的抗壓性和健壯性，能夠處理多種異常情況，具有最高的魯棒性；同時(shí)能夠很好運(yùn)用于移動(dòng)互聯(lián)網(wǎng)絡(luò)，并且有很好的并發(fā)處理能力。
【專利說明】
-種用于融合通信系統(tǒng)的消息引擎
技術(shù)領(lǐng)域
[0001] 本發(fā)明設(shè)及移動(dòng)互聯(lián)網(wǎng)絡(luò)和物聯(lián)網(wǎng)通信協(xié)議，是一種用于融合通信系統(tǒng)的消息引 擎。
【背景技術(shù)】
[0002] 在繼萬維網(wǎng)、E-mail之后發(fā)展最為迅猛的互聯(lián)網(wǎng)應(yīng)用是即時(shí)消息通信，它是指互 聯(lián)網(wǎng)上用W進(jìn)行實(shí)時(shí)通信的系統(tǒng)服務(wù)，其允許多人使用即時(shí)通訊通信軟件實(shí)時(shí)的傳遞文 本、圖片、文檔、語音及視頻等信息流。近年來，隨著即時(shí)消息通信技術(shù)不斷發(fā)展和即時(shí)通信 工具的廣泛應(yīng)用，越來越多的企業(yè)部署了即時(shí)消息通信系統(tǒng)，旨在提高工作效率，降低溝通 成本。特別是近年來，隨著移動(dòng)互聯(lián)網(wǎng)的興起，無論是個(gè)人用戶還是企業(yè)用戶都將IM (insurant messaging,即時(shí)通信）作為有效的溝通途徑，使得IM軟件在個(gè)人消息通信與企 業(yè)消息通信市場(chǎng)上得到了廣泛的應(yīng)用，同時(shí)也顯示了它的巨大市場(chǎng)潛力。當(dāng)前主流的消息 通信軟件有ICQ、Tencent QQ、WeChat、Weibo等，但運(yùn)些消息通信軟件的提供商出于各自利 益的考慮，大部分即時(shí)消息通信系統(tǒng)采用了私有通信協(xié)議，在一定程度上阻礙了使用不同 即時(shí)消息通信系統(tǒng)的個(gè)人或企業(yè)之間的溝通交流，也不利于企業(yè)即時(shí)通信系統(tǒng)與公司內(nèi)部 重要系統(tǒng)的互聯(lián)互通。
[0003] 本發(fā)明正是在此背景下，并在分析了 SIMPLE、XMPP和MQTT協(xié)議的基礎(chǔ)上，提出了一 套面向企業(yè)的、基于物聯(lián)網(wǎng)標(biāo)準(zhǔn)協(xié)議的消息引擎服務(wù)器的設(shè)計(jì)，并實(shí)現(xiàn)了消息引擎服務(wù)器 的用戶身份認(rèn)證、消息接收和發(fā)送、狀態(tài)信息監(jiān)控和消息預(yù)訂閱等功能。其中MQTT(Message Queuing Teleme化y化ansport)協(xié)議是IBM開發(fā)的一個(gè)開放的即時(shí)通訊協(xié)議，并于2014年 11 月，MQTT v3.1.1 成為0ASIS(0rganization for the Advancement of Structures Information Standard)標(biāo)準(zhǔn)協(xié)議。

【發(fā)明內(nèi)容】

[0004] 針對(duì)現(xiàn)有即時(shí)消息通信應(yīng)用主要采用私有協(xié)議進(jìn)行開發(fā)的弊端，本發(fā)明基于物聯(lián) 網(wǎng)標(biāo)準(zhǔn)協(xié)議(MQTT協(xié)議)提出了一種用于融合通信系統(tǒng)的消息引擎。
[0005] 本發(fā)明為實(shí)現(xiàn)上述目的所采用的技術(shù)方案是：一種用于融合通信系統(tǒng)的消息引 擎，
[0006] (定稿后拷貝權(quán)利要求）
[0007] 本發(fā)明具有W下優(yōu)點(diǎn)及有益效果：
[000引1.本發(fā)明設(shè)計(jì)了一種用于融合通信系統(tǒng)的消息引擎，本消息引擎服務(wù)器具有很好 的抗壓性和健壯性。
[0009] 2.本發(fā)明設(shè)計(jì)了一種用于融合通信系統(tǒng)的消息引擎，能夠處理多種異常情況，具 有最高的魯棒性。
[0010] 3.本發(fā)明設(shè)計(jì)了一種用于融合通信系統(tǒng)的消息引擎，能夠很好運(yùn)用于移動(dòng)互聯(lián)網(wǎng) 絡(luò)，并且有很好的并發(fā)處理能力。
【附圖說明】
[0011] 圖1是消息引擎系統(tǒng)結(jié)構(gòu)圖；
[0012] 圖2是消息路由規(guī)則過程示例圖；
[0013] 圖3是用戶多終端IM模型圖；
[0014] 圖4是Presence模塊流程圖；
[0015] 圖5是用戶身份認(rèn)證過程圖；
[0016] 圖6是預(yù)訂閱模塊流程圖；
[0017]圖 7是 sub/unsub 流程圖；
[001引圖8是統(tǒng)一消息中屯、模塊流程圖；
[0019] 圖9是用戶連接通信過程圖。
【具體實(shí)施方式】
[0020] 下面結(jié)合附圖及實(shí)施例對(duì)本發(fā)明做進(jìn)一步的詳細(xì)說明。
[0021] 如圖1所示，給出了融合通信消息引擎服務(wù)器的結(jié)構(gòu)設(shè)計(jì)，采用Ξ層結(jié)構(gòu)，主要包 括MQTT broker,業(yè)務(wù)邏輯層和數(shù)據(jù)存儲(chǔ)層。其中MQTT broker采用Mosquitto進(jìn)行開發(fā)，并 在其上運(yùn)用插件的方式實(shí)現(xiàn)消息引擎所要實(shí)現(xiàn)完成的業(yè)務(wù)邏輯;業(yè)務(wù)邏輯層主要包括IM消 息傳輸、presence消息傳輸、話題預(yù)訂閱W及用戶登錄身份認(rèn)證等;數(shù)據(jù)存儲(chǔ)層主要是實(shí)現(xiàn) 消息W及用戶信息的存儲(chǔ)。
[0022] 消息引擎對(duì)消息路由規(guī)則的設(shè)計(jì)。一條消息路由規(guī)則的基本組成包括4部分，即消 息路由方向（Defection )，源地址（srcTopic )，消息路由動(dòng)作（Act ion)，目的地址 (destTopic)。
[0023] 如圖2所示，給出了消息傳輸?shù)南⒙酚蛇^程，WTom與Jhone通信過程為例來詳細(xì) 描述消息路由的過程：
[0024] 步驟l)Tom PC端向Jlione的IM topic發(fā)送一條消息；
[002引步驟2)broker在收到該消息時(shí)，通過查詢消息路由規(guī)則，判斷是否有匹配的路由 規(guī)則，若有則繼續(xù)進(jìn)行，否則跳過步驟3和5過程；
[0026] 步驟3)按照消息路由規(guī)則中的Action進(jìn)行消息路由，找到轉(zhuǎn)發(fā)的目的topic,此處 為Tom的IM topic;
[0027] 步驟4)把消息pub給Jhone;
[002引步驟5)Tom的手機(jī)端收到PC端發(fā)送的消息，并且在手機(jī)端呈現(xiàn)；
[0029] 步驟6)Jhone的所有終端收到Tom發(fā)來的消息。
[0030] 如圖3所示，給出了多終端IM機(jī)制的模型，用戶的IM功能主要有好友之間進(jìn)行IM通 信、用戶多終端之間IM消息同步，離線終端IM消息同步W及IM消息支持多種類型。IM消息的 類型包括文字、圖片、文件、音頻等多種媒體。本發(fā)明的IM模型與W前的IM模型比較，本模型 支持用戶的多終端，采用基于話題的發(fā)布/訂閱，消息的交互通過MQTT代理完成。IM消息接 收可根據(jù)用戶在線狀態(tài)來判斷是實(shí)時(shí)發(fā)送還是在服務(wù)器端存儲(chǔ)，在用戶上線時(shí)再將消息推 送到用戶客戶端，同時(shí)消息引擎服務(wù)器支持同一用戶在多個(gè)不同終端上同時(shí)在線。根據(jù)所 述消息路由規(guī)則實(shí)現(xiàn)多終端的消息同步功能。
[0031] 每一個(gè)用戶擁有一個(gè)IM的主題，每一個(gè)用戶的每個(gè)終端都訂閱運(yùn)個(gè)IM主題，每個(gè) 用戶的每個(gè)終端都對(duì)應(yīng)一個(gè)IM主題，對(duì)于每一個(gè)終端都要訂閱與之相對(duì)應(yīng)的主題。在進(jìn)行 IM的時(shí)候，如圖2所示進(jìn)行消息路由，發(fā)送方向接收方的IM主題上發(fā)送消息，運(yùn)樣就可W實(shí) 現(xiàn)消息的收發(fā)，但是要實(shí)現(xiàn)消息的同步，還需要基于消息路由規(guī)則的消息同步策略。該消息 路由規(guī)則是通過話題的模糊匹配，對(duì)于匹配成功的話題，將消息復(fù)制到目標(biāo)主題上去。
[0032] 消息路由規(guī)則是通過話題的模糊匹配，對(duì)于匹配成功的話題，將消息復(fù)制到目標(biāo) 主題上去。消息路由規(guī)則的一般格式為：
[0033] <direction>,<SourceTopic>,<action>,<DestinationTopic>
[0034] 其中direction決定消息路由方向，SourceTopic決定收到的消息是否需要路由， 曰。1：；[0]1決定路由的動(dòng)作，〇631：；[]1曰1：；[0]11'(沖；[(3決定消息的去向，且只有在曰(31：；[0]1為復(fù)制或轉(zhuǎn) 發(fā)時(shí)才有效。
[0035] 對(duì)于一條IM消息，需要包含消息的發(fā)送時(shí)間，類型，內(nèi)容類型，消息內(nèi)容，發(fā)送者信 息等，IM消息的消息格式如表1所示。
[0036] 表1
[0037]
[0038] 服務(wù)器中還定義了一些系統(tǒng)的通知，其消息格式類似于IM消息的消息格式，包括 通知時(shí)間，通知類型，W及通知的內(nèi)容。通知的類型主要包括系統(tǒng)通知、企業(yè)系統(tǒng)通知、個(gè)人 系統(tǒng)通知、群組通知、群管理員通知，如表2所示。
[0039] 表 2
[0040]
[0041]
[0042] 系統(tǒng)通知是指本系統(tǒng)中系統(tǒng)消息，用W推送到所有的用戶；企業(yè)系統(tǒng)通知是指單 個(gè)企業(yè)的系統(tǒng)消息，用W推送到某個(gè)企業(yè)的所有用戶；個(gè)人系統(tǒng)通知是指單個(gè)用戶的通知 消息，主要包括好友離線文件提醒、業(yè)務(wù)通知、日程提醒通知、郵件更新通知，被邀請(qǐng)加入 群，群轉(zhuǎn)讓給自己等;群組通知是指對(duì)群組內(nèi)成員的通知，主要包括群組公告更新、群組的 基本信息修改、群組高級(jí)信息修改、群組解散通知、群組轉(zhuǎn)讓通知等;群管理員通知是指專 口針對(duì)群組的管理員的一些通知。
[0043] 在消息引擎服務(wù)器中，運(yùn)用Presence模塊來實(shí)現(xiàn)用戶基本在線狀態(tài)信息的發(fā)布。 Presence消息包括呈現(xiàn)狀態(tài)和可選的自定義狀態(tài)兩部分;通知消息包括通知的時(shí)間戳，通 知類型和通知的消息內(nèi)容。Presence消息主要包括兩個(gè)字節(jié)，如表3所示，第一個(gè)字節(jié)表示 詳細(xì)呈現(xiàn)狀態(tài)的代碼，其中定義了6種Status，0x01表示在線，0x02表示離線，0x03表示隱 身，0x04表示忙碌，0x05表示請(qǐng)勿打擾，0x06表示自定義，剩余的保留；第二個(gè)字節(jié)為可選部 分，只有詳細(xì)狀態(tài)為0x06時(shí)，其中存儲(chǔ)自定義的呈現(xiàn)狀態(tài)。用戶在線狀態(tài)信息的發(fā)布主要分 為兩步，第一，MQTT代理接收到用戶的connect和disconnect信息時(shí)，判斷用戶的基本在線 信息，將信息封裝交付給Presence模塊;第二，Presence模塊接收到封裝信息，解封消息，構(gòu) 造話題，正式發(fā)布用戶的狀態(tài)信息。
[0044] 表 3
[0045]
[0046] 每一個(gè)用戶均需要訂閱自己用戶名下的狀態(tài)主題，同時(shí)還需要訂閱好友的狀態(tài)主 題，該部分的訂閱操作由預(yù)訂閱功能模塊來完成。由于Presence不會(huì)向離線的用戶發(fā)送狀 態(tài)信息，而且在離線用戶上線時(shí)，可W獲取用戶們的狀態(tài)信息，可W通過標(biāo)記RETAIN來實(shí)現(xiàn) 對(duì)該狀態(tài)消息的推送。規(guī)定終端的主題均是按照Q〇S = 0的方式訂閱，對(duì)于狀態(tài)消息的發(fā)布， QoS = 0，retain=l，運(yùn)樣就保證了在新的狀態(tài)消息到達(dá)代理服務(wù)器W后，所有舊的re化in =1的狀態(tài)消息被代理服務(wù)器丟棄，只保留最新的狀態(tài)消息。
[0047] presence模塊的操作過程如圖4所示：
[004引步驟1)解析消息，得到clienticUuid和當(dāng)前要發(fā)布的狀態(tài)。
[0049] 步驟2)遍歷鏈表，查詢是否存在節(jié)點(diǎn)數(shù)據(jù)為該clientid的節(jié)點(diǎn)，如果存在運(yùn)樣的 節(jié)點(diǎn)且用戶的狀態(tài)為離線，則刪除節(jié)點(diǎn)信息;如果不存在運(yùn)樣的節(jié)點(diǎn)且用戶的狀態(tài)為在線， 則添加節(jié)點(diǎn)信息。其余情況不做處理。
[0050] 步驟3)由前述機(jī)制設(shè)計(jì)可知，對(duì)于一個(gè)Presence話題由一個(gè)eid和一個(gè)uid就可W 唯一確認(rèn)。eid的獲取可W通過webservice查詢。
[0051 ]步驟4)記錄用戶的狀態(tài)信息到數(shù)據(jù)庫中。
[0052] 步驟5)根據(jù)uid和獲取的eid構(gòu)造話題及對(duì)應(yīng)的消息，發(fā)布用戶的基本狀態(tài)。
[0053] 本發(fā)明的消息引擎服務(wù)器采用了基于發(fā)布/訂閱模型的MQTT協(xié)議作為基礎(chǔ)，其數(shù) 據(jù)模型為話題，對(duì)于任何消息的推送都是通過話題的形式來組織完成。每個(gè)用戶有很多好 友，而每個(gè)好友關(guān)系都需要幾個(gè)話題，所W為提高消息引擎服務(wù)器的用戶體驗(yàn)，提出了預(yù)訂 閱模塊，預(yù)訂閱模塊的基本過程如圖6所示。通過對(duì)系統(tǒng)的分析，預(yù)訂閱的處理過程主要包 括W下巧巾情況：
[0054] 情況1)增加用戶、刪除用戶或修改用戶角色時(shí)，該用戶的好友訂閱關(guān)系會(huì)有變化；
[0055] 情況2)用戶在群創(chuàng)建、群成員加入、群成員刪除時(shí)，該用戶的訂閱關(guān)系發(fā)生變化；
[0056] 情況3)用戶首次登錄時(shí)，包括開戶后首次登錄和在系統(tǒng)最大時(shí)間間隔沒登錄之后 又登錄兩種情況，此時(shí)用戶的訂閱關(guān)系為空，需要為其預(yù)訂閱相關(guān)話題。
[0化7] 對(duì)于所述情況1、情況2發(fā)生后，LDAP service根據(jù)情況發(fā)生所影響的用戶，生成話 題更新的列表，通過消息總線發(fā)送給預(yù)訂閱模塊。消息格式為：
[0058] <clientid〉-<subIunsub〉-Qos-<topic_count〉-<topicl〉[,toipic2]
[0化9] 第一項(xiàng)clientid表示為該clientid進(jìn)行預(yù)訂閱；第二項(xiàng)為sub或unsub表示預(yù)訂閱 的動(dòng)作是訂閱還是取消訂閱；topic_count決定了后面有幾個(gè)話題。若情況3發(fā)生，代理會(huì)將 用戶登錄的clientid通知預(yù)訂閱模塊為用戶添加訂閱關(guān)系，預(yù)訂閱模塊收到clientid后， 通過webservice告知LDAP service，由LDAP service整理該用戶需要訂閱的話題，通過總 線的再回傳到預(yù)訂閱模塊。其中sub與unsub過程如圖7所示。
[0060]預(yù)訂閱功能是用于用戶終端第一次連接MQTT代理服務(wù)器時(shí)幫助用戶訂閱話題。首 先設(shè)計(jì)一個(gè)話題，服務(wù)器代理判斷用戶終端是否是第一次連接，如果是，則將該用戶的 clientid推送到設(shè)計(jì)好的話題上，再利用預(yù)訂閱模塊訂閱話題，然后根據(jù)收到的clientid 幫助用戶整理訂閱話題列表，再將話題列表提交到服務(wù)器代理完成話題訂閱。
[0061 ]對(duì)于預(yù)訂閱功能模塊的實(shí)現(xiàn)主要分為兩部分：
[0062] (l)MQTT broker檢測(cè)到用戶第一次連接，將用戶終端的clientid推送到話題/e/ presub/connection/newJl 〇iS：Mosquitt〇i=|=i^_^mqtt3_connect_state^'^5|t^JJ)iX^3i^ 狀態(tài)的檢測(cè)；
[0063] (2)預(yù)訂閱模塊在接收到代理服務(wù)器發(fā)送到話題/e/presub/connection/new上的 消息時(shí)，獲取clientid,通過LDAP service從LDAP數(shù)據(jù)庫中獲取該client id需要訂閱的話 題列表，然后將話題列表發(fā)送給代理服務(wù)器進(jìn)行訂閱。
[0064] sub與unsub的過程為：最上層傳輸?shù)臄?shù)據(jù)化是mosquitto的內(nèi)部數(shù)據(jù)庫，context 是發(fā)送sub/unsub消息的mosquitto實(shí)體。因此，當(dāng)預(yù)訂閱模塊向mosquitto發(fā)起subsc;r;Lbe/ unsubscribe時(shí)，context指的是預(yù)訂閱模塊，此時(shí)，是給預(yù)訂閱模型進(jìn)行了話題的訂閱和取 消訂閱而不是給用戶訂閱。因此，為了完成預(yù)訂閱，運(yùn)部分要做相應(yīng)的邏輯處理，即要獲取 訂閱用戶的context,并進(jìn)行替換。用戶的context可W根據(jù)用戶的clientid進(jìn)行hash查找。 將clientid的值通過subscribe消息的消息內(nèi)容傳遞給mosquitto 〇subsc;r;Lbe的消息內(nèi)容 中本來存儲(chǔ)的是topic/qos對(duì)，對(duì)于預(yù)訂閱發(fā)送給mosquitto的subsc;r;Lbe消息，為了攜帶訂 閱用戶的C1 i ent id，對(duì)消息的內(nèi)容進(jìn)行一定的修改，對(duì)于消息中的第一個(gè)topi c/qos對(duì)，話 題中存儲(chǔ)用戶的clientid，qos設(shè)置為5(合法的qos是0,1，2) Dmosquitto解析消息，可W根 據(jù)第一個(gè)qos的值來判別運(yùn)個(gè)subscribe消息時(shí)一個(gè)普通的訂閱消息，還是預(yù)訂閱消息。如 果是普通的subscribe消息，不做其他特殊處理。按原流程進(jìn)行訂閱操作。如果是預(yù)訂閱的 subscribe消息，根據(jù)用戶的client id,進(jìn)行hash,查找到該client id對(duì)應(yīng)的context，然后 利用該context進(jìn)行訂閱操作。最后的suback要回給預(yù)訂閱模塊。
[0065] 業(yè)務(wù)模塊層還包括統(tǒng)一消息中屯、模塊。如圖8所示，給出了統(tǒng)一消息中屯、模塊的流 程，該部分主要用于處理離線消息的轉(zhuǎn)移。根據(jù)Mosquitto中對(duì)離線消息的處理，統(tǒng)一消息 中屯、模塊設(shè)及的話題有W下Ξ種：
[0066] 1.點(diǎn)對(duì)點(diǎn)的 IM:/e/+/imtran/u/+
[0067] 2.群組的 IM: /e/+/imtran/g/+/+
[0068] 3.公共賬號(hào)的 IM: /e/+/imtran/p/+/+
[0069] 通過通配符的方式，囊括了所有的情況。統(tǒng)一消息中屯、模塊需要對(duì)運(yùn)Ξ類話題進(jìn) 行訂閱。訂閱成功后，每當(dāng)離線用戶收到消息后，代理將離線消息推送給本模塊。本模接收 到消息后，首先對(duì)話題進(jìn)行初步解析，判斷消息的類型，含有7u/"的為點(diǎn)對(duì)點(diǎn)IM，含有7 g/"為群組IM，含有7ρΓ的為公共賬號(hào)IM。其次，進(jìn)一步解析話題，獲取消息發(fā)送者uid、 gicUpid。然后根據(jù)解析到的uid調(diào)用webservice去查詢LDAP獲取用戶通信地址及用戶配 置。最后按照格式構(gòu)造短信或郵件內(nèi)容，將其送到消息總線中。
[0070] 如圖5所示，給出了用戶的認(rèn)證流程。對(duì)于用戶認(rèn)證，Mosquitto中提供了插件的方 式來擴(kuò)展用戶認(rèn)證。插件可W通過配置文件、數(shù)據(jù)庫等方式來完成校驗(yàn)。對(duì)于配合代理的核 屯、模塊采用配置文件的方式進(jìn)行認(rèn)證，普通終端用戶通過校驗(yàn)存放在redis數(shù)據(jù)庫中的認(rèn) 證信息完成。
[0071] 如圖9所示，給出了兩個(gè)用戶進(jìn)行通信的過程，首先userl與user2對(duì)服務(wù)器發(fā)起連 接請(qǐng)求，服務(wù)器給client返回ACK，建立連接;然后userl向服務(wù)器user2的話題上發(fā)布消息， 服務(wù)器收到消息后返回puback;服務(wù)器將消息推送到user2，user2收到消息后返回puback。
【主權(quán)項(xiàng)】
1. 一種用于融合通信系統(tǒng)的消息引擎，其特征在于，包括： 消息隊(duì)列與MQTT代理服務(wù)器，用于實(shí)現(xiàn)MQTT協(xié)議功能，基于MQTT協(xié)議的發(fā)布/訂閱機(jī)制 實(shí)現(xiàn)消息路由規(guī)則； 業(yè)務(wù)模塊層，用于實(shí)現(xiàn)消息引擎的各個(gè)業(yè)務(wù)功能； 數(shù)據(jù)存儲(chǔ)層，用于為業(yè)務(wù)模塊層提供數(shù)據(jù)支持。2. 根據(jù)權(quán)利要求1所述的一種用于融合通信系統(tǒng)的消息引擎，其特征在于，所述業(yè)務(wù)模 塊層包括： presence模塊，用于呈現(xiàn)用戶的各個(gè)終端的狀態(tài)信息； IM模塊，用于用戶好友之間的頂消息傳遞，在MQTT代理服務(wù)器的控制下，根據(jù)用戶在線 狀態(tài)判斷將頂消息實(shí)時(shí)發(fā)送還是存儲(chǔ)在數(shù)據(jù)存儲(chǔ)層中，在用戶上線時(shí)再將頂消息推送到用 戶的客戶端； presub模塊，用于在用戶終端第一次連接MQTT代理服務(wù)器時(shí)，為用戶預(yù)訂閱話題； 用戶身份認(rèn)證模塊，用于用戶登錄時(shí)的身份驗(yàn)證。3. 根據(jù)權(quán)利要求1所述的一種用于融合通信系統(tǒng)的消息引擎，其特征在于，所述消息引 擎采用MQTT協(xié)議，其消息格式包括消息頭部和承載消息的payload部分； 如果該消息為頂消息，則payload部分包括消息的發(fā)送時(shí)間、消息類型、消息內(nèi)容類型、 消息內(nèi)容和發(fā)送者信息； 如果該消息為presence消息，則payload部分包括呈現(xiàn)狀態(tài)和可選的自定義狀態(tài)信息； 如果該消息為通知消息，則payload部分包括通知的時(shí)間戳、通知類型和通知的內(nèi)容消 息。4. 根據(jù)權(quán)利要求1所述的一種用于融合通信系統(tǒng)的消息引擎，其特征在于，所述消息路 由規(guī)則的基本組成包括4部分：消息路由方向、源地址、消息路由動(dòng)作、目的地址，其路由過 程為： 步驟1)用戶A的一個(gè)終端向用戶B的IM話題發(fā)送一條消息； 步驟2)MQTT代理服務(wù)器在收到該消息時(shí)，通過查詢消息路由規(guī)則，判斷是否有匹配的 路由規(guī)則，若有則繼續(xù)進(jìn)行，否則跳過步驟3和步驟5; 步驟3)按照消息路由規(guī)則中的消息路由動(dòng)作進(jìn)行消息路由，找到轉(zhuǎn)發(fā)的目的地址，即 用戶A的IM話題； 步驟4)MQTT代理服務(wù)器把消息發(fā)布給用戶B; 步驟5)用戶A的其他在線終端收到由發(fā)送消息的終端發(fā)送的該消息，并且呈現(xiàn)； 步驟6)用戶B的所有在線終端收到該消息。5. 根據(jù)權(quán)利要求2所述的一種用于融合通信系統(tǒng)的消息引擎，其特征在于，所述presub 模塊通過以下方式為用戶預(yù)訂閱話題： 首先設(shè)計(jì)一個(gè)話題，MQTT代理服務(wù)器判斷用戶終端是否是第一次連接，如果是，則將該 用戶的用戶終端ID推送到所述話題上，再訂閱該話題;根據(jù)收到的用戶終端ID為用戶整理 訂閱話題列表，再將話題列表提交到MQTT代理服務(wù)器完成話題訂閱。6. 根據(jù)權(quán)利要求1所述的一種用于融合通信系統(tǒng)的消息引擎，其特征在于，所述頂模塊 采用頂話題的訂閱/發(fā)布機(jī)制，通過MQTT代理服務(wù)器進(jìn)行消息的推送，具體為： 每一個(gè)用戶擁有一個(gè)IM話題，每一個(gè)用戶的每個(gè)終端都訂閱這個(gè)IM話題，每個(gè)用戶的 每個(gè)終端都對(duì)應(yīng)一個(gè)頂話題，對(duì)于每一個(gè)終端都訂閱與之相對(duì)應(yīng)的話題;在進(jìn)行頂通信時(shí)， 發(fā)送方向接收方的頂話題上發(fā)送消息，然后MQTT代理服務(wù)器根據(jù)消息路由規(guī)則進(jìn)行消息推 送，以實(shí)現(xiàn)消息的收發(fā)。7. 根據(jù)權(quán)利要求1所述的一種用于融合通信系統(tǒng)的消息引擎，其特征在于，所述 presence模塊通過標(biāo)記MQTT協(xié)議中的RETAIN來實(shí)現(xiàn)對(duì)用戶狀態(tài)消息的推送，具體為：規(guī)定 用戶所有終端的主題均是按照QoS = 0的方式訂閱，對(duì)于狀態(tài)消息的發(fā)布，QoS = 0，retain = 1，以保證在新的用戶狀態(tài)消息到達(dá)MQTT代理服務(wù)器以后，所有舊的retain = l的狀態(tài)消息 被MQTT代理服務(wù)器丟棄，只保留最新的狀態(tài)消息。數(shù)據(jù)存儲(chǔ)層8. 根據(jù)權(quán)利要求1所述的一種用于融合通信系統(tǒng)的消息引擎，其特征在于，所述用戶身 份認(rèn)證模塊通過校驗(yàn)存放在MQTT代理服務(wù)器中的Redis數(shù)據(jù)庫中的認(rèn)證信息完成用戶身份 認(rèn)證。9. 根據(jù)權(quán)利要求1所述的一種用于融合通信系統(tǒng)的消息引擎，其特征在于，所述MQTT代 理服務(wù)器通過插件的方式配合用戶身份認(rèn)證模塊完成用戶身份認(rèn)證;所述插件能夠通過配 置文件、數(shù)據(jù)庫的方式完成用戶身份認(rèn)證。10. 根據(jù)權(quán)利要求1所述的一種用于融合通信系統(tǒng)的消息引擎，其特征在于，所述數(shù)據(jù) 存儲(chǔ)層包括MySQL數(shù)據(jù)庫、LDAP數(shù)據(jù)庫和Redis數(shù)據(jù)庫;所述MySQL數(shù)據(jù)庫用于存儲(chǔ)頂消息、 presence消息;所述LDAP數(shù)據(jù)庫用于存儲(chǔ)用戶信息;所述Redis數(shù)據(jù)庫用于調(diào)取LDAP數(shù)據(jù)庫 中的用戶信息以完成用戶身份認(rèn)證模塊對(duì)用戶身份的認(rèn)證。
【文檔編號(hào)】H04L12/58GK106059892SQ201610327831
【公開日】2016年10月26日
【申請(qǐng)日】2016年5月17日
【發(fā)明人】于金剛, 耿云飛, 楊海波, 賈正鋒
【申請(qǐng)人】中國(guó)科學(xué)院沈陽計(jì)算技術(shù)研究所有限公司