基于JMS2.0規(guī)范的消息總線研究與應用
發(fā)布時間:2020-05-29 07:45
【摘要】:隨著信息技術的快速發(fā)展,各行業(yè)開發(fā)建設了大量信息系統(tǒng)。很多系統(tǒng)是在不同需求階段采用不同技術實現的,運行在異構的平臺上,形成很多信息孤島。這使得企業(yè)內系統(tǒng)間發(fā)生數據交互時存在一定的難度,有時還需要專門開發(fā)相應的交互模塊。為了使企業(yè)內部的數據能夠集成和共享,本文采用消息總線這種中間件技術,來屏蔽各應用在技術實現和運行環(huán)境方面的異構性,實現數據共享。在對面向消息的中間件(MOM)技術進行充分研究的基礎上,本文以較新的Java消息服務(JMS)2.0版本規(guī)范展開消息總線的研究工作。JMS2.0規(guī)范主要定義了一款消息服務應具有的公共接口、管理對象和消息傳遞模型等公共特性。論文以具體項目運行現狀為出發(fā)點,較全面地分析了消息總線的功能和性能需求,整合當前主流且高性能的Kafka消息服務進行了二次開發(fā),完成了消息總線的概要設計、消息存儲、詳細設計和實現、測試等工作。在論文工作過程中,著重研究消息傳遞的路由機制,以基于內容的路由方式結合圖搜索算法設計了消息路由;并封裝Kafka的API實現了兩種消息傳遞模型。另一方面是以Kafka消息服務為基礎,設計了消息總線服務在負載均衡、流量管理方面的高可用性,使總線服務保持穩(wěn)定性和可靠性。最后,根據個人參與開發(fā)的電能質量數據監(jiān)測分析系統(tǒng)中的數據接口運行現狀,將本文實現的消息總線應用到項目,替代項目中目前存在的復雜多樣的數據交互方案。在消息總線的應用研究過程中,完成了消息總線服務的功能和性能的測試,證明總線是可用的。
【圖文】:
邐j逡逑圖2-1】MS經典API結構逡逑圖2-1中各個類的功能見表2-1。逡逑邐表2-1經典API中各類的功能邐逡逑ConnectionFactory邐創(chuàng)建客戶端連接到服務端的管理對象逡逑Connection邐創(chuàng)建客戶端到總線服務端之間的對話迮接逡逑Session邐客戶端消息請求的單線程上下文逡逑MessageProducer邐創(chuàng)建生產者對象,發(fā)送消息到服務端隊列成主題逡逑MessageConsumer邐創(chuàng)建消費者對象,向服務端請求消息逡逑2.0版本中簡化API在功能上和經典API是相似的,但更具易用性。簡化API逡逑中主要包含三部分:JMSContext、JMSProducer邋和邋JMSConsumer,結構如圖邋2-2[22]逡逑所示。逡逑7逡逑
逑圖2-2邋JMS簡化API結構逡逑圖2-2中各個類的主要功能見表2-2。逡逑邐表2-2邋JMS2.邋0規(guī)范中主耍API邐逡逑類名邐主耍功能逡逑JMSContext邐一個JMSContext對象可以封裝原來Connection和Session邋兩個逡逑對象的行為,減少發(fā)送和接收消息耍創(chuàng)建的對象數。逡逑JMSProducer邐代替MessageProducer,可以使)4j構建者模式配置消息屬性,逡逑易陽性更強。逡逑JMSConsumer邐代代替邋MessageConsumer逡逑2.0規(guī)范的API在使用時省去了部分參數,保持和經典API相似的使用風格和逡逑完全一致的功能特性,為保證向后的兼容性經典API依然被保留。逡逑2.3JMS消息模型逡逑JMS消息模型主要包括消息和消息傳遞。消息可以被視為一個實體,,它擁有自逡逑己的數據結構和屬性;而消息傳遞模型是消息總線區(qū)別于其他類型中間件的特征。逡逑2.邋3.邋1邋JMS邋消息逡逑JMS消息主要是為提供統(tǒng)一的消息API而設計,可以提供統(tǒng)一的消息格式,逡逑如XML格式的消息。逡逑JMS規(guī)范定義由消息頭、消息屬性、消息體三部分構成消息[22】。逡逑(1)
【學位授予單位】:華北電力大學(北京)
【學位級別】:碩士
【學位授予年份】:2018
【分類號】:TP311.52
本文編號:2686626
【圖文】:
邐j逡逑圖2-1】MS經典API結構逡逑圖2-1中各個類的功能見表2-1。逡逑邐表2-1經典API中各類的功能邐逡逑ConnectionFactory邐創(chuàng)建客戶端連接到服務端的管理對象逡逑Connection邐創(chuàng)建客戶端到總線服務端之間的對話迮接逡逑Session邐客戶端消息請求的單線程上下文逡逑MessageProducer邐創(chuàng)建生產者對象,發(fā)送消息到服務端隊列成主題逡逑MessageConsumer邐創(chuàng)建消費者對象,向服務端請求消息逡逑2.0版本中簡化API在功能上和經典API是相似的,但更具易用性。簡化API逡逑中主要包含三部分:JMSContext、JMSProducer邋和邋JMSConsumer,結構如圖邋2-2[22]逡逑所示。逡逑7逡逑
逑圖2-2邋JMS簡化API結構逡逑圖2-2中各個類的主要功能見表2-2。逡逑邐表2-2邋JMS2.邋0規(guī)范中主耍API邐逡逑類名邐主耍功能逡逑JMSContext邐一個JMSContext對象可以封裝原來Connection和Session邋兩個逡逑對象的行為,減少發(fā)送和接收消息耍創(chuàng)建的對象數。逡逑JMSProducer邐代替MessageProducer,可以使)4j構建者模式配置消息屬性,逡逑易陽性更強。逡逑JMSConsumer邐代代替邋MessageConsumer逡逑2.0規(guī)范的API在使用時省去了部分參數,保持和經典API相似的使用風格和逡逑完全一致的功能特性,為保證向后的兼容性經典API依然被保留。逡逑2.3JMS消息模型逡逑JMS消息模型主要包括消息和消息傳遞。消息可以被視為一個實體,,它擁有自逡逑己的數據結構和屬性;而消息傳遞模型是消息總線區(qū)別于其他類型中間件的特征。逡逑2.邋3.邋1邋JMS邋消息逡逑JMS消息主要是為提供統(tǒng)一的消息API而設計,可以提供統(tǒng)一的消息格式,逡逑如XML格式的消息。逡逑JMS規(guī)范定義由消息頭、消息屬性、消息體三部分構成消息[22】。逡逑(1)
【學位授予單位】:華北電力大學(北京)
【學位級別】:碩士
【學位授予年份】:2018
【分類號】:TP311.52
【參考文獻】
中國期刊全文數據庫 前7條
1 葉晨;支海邦;;物聯網中一種基于內容的消息路由算法[J];小型微型計算機系統(tǒng);2015年09期
2 王新偉;;異步消息處理機制在總分數據傳輸應用中的研究[J];電子技術與軟件工程;2015年09期
3 李艷春;李新;焦文彬;;分布式信息系統(tǒng)中數據交換平臺設計與實現[J];計算機工程與設計;2012年07期
4 孫琳;王春喜;;支持中小企業(yè)應用集成的JMS消息中間件設計[J];電腦知識與技術;2012年19期
5 胡志輝;牛德雄;許國慶;;消息隊列管理在信息交換中的研究[J];計算機與現代化;2009年01期
6 薛濤;馮博琴;李波;董劍;;基于內容的發(fā)布訂閱系統(tǒng)中快速匹配算法的研究[J];小型微型計算機系統(tǒng);2006年03期
7 徐晶,許煒;消息中間件綜述[J];計算機工程;2005年16期
本文編號:2686626
本文鏈接:http://sikaile.net/kejilunwen/ruanjiangongchenglunwen/2686626.html