一種面向消息的中間件的設(shè)計(jì)與實(shí)現(xiàn)

孫弋 溫迅

摘 要：中間件是位于硬件操作系統(tǒng)和應(yīng)用之間的通用服務(wù)。基于遠(yuǎn)程調(diào)用的中間件技術(shù)已廣泛應(yīng)用于各個(gè)領(lǐng)域。但介于其同步通信、客戶端/服務(wù)器強(qiáng)耦合且只能進(jìn)行點(diǎn)對(duì)點(diǎn)通信的問題，其應(yīng)用始終有相應(yīng)局限。面向消息的中間件因其忽略平臺(tái)異構(gòu)性、異步通信等良好特點(diǎn)恰好可以解決以上問題。利用SUN公司提出的JMS規(guī)范，設(shè)計(jì)消息模型用于通信，通過Java NIO事件驅(qū)動(dòng)的編程模型實(shí)現(xiàn)異步通信，最后實(shí)現(xiàn)一種面向消息的中間件系統(tǒng)，并給出了該消息中間件在某高校選課系統(tǒng)中的良好應(yīng)用。

關(guān)鍵詞：消息中間件;消息服務(wù);消息隊(duì)列;異步通信;JMS規(guī)范;Java

中圖分類號(hào)：TP311.1文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：2095-1302（2019）03-00-04

0 引 言

隨著企業(yè)系統(tǒng)中分布式架構(gòu)的普及和系統(tǒng)的不斷擴(kuò)大，在異構(gòu)和分布環(huán)境下完成企業(yè)的業(yè)務(wù)管理、數(shù)據(jù)共享和數(shù)據(jù)傳輸已成為行業(yè)的焦點(diǎn)，這種環(huán)境下，中間件技術(shù)應(yīng)運(yùn)而生。CORBA（公共對(duì)象請(qǐng)求代理體系結(jié)構(gòu)），DCOM（分布式組件對(duì)象模型），RMI（遠(yuǎn)程方法調(diào)用）等以遠(yuǎn)程調(diào)用為主的RPC（遠(yuǎn)程過程調(diào)用）中間件技術(shù)已廣泛應(yīng)用于各個(gè)領(lǐng)域[1]，但是面對(duì)愈加復(fù)雜的分布式系統(tǒng)，這些技術(shù)的局限性也愈加明顯：

（1）同步通信，客戶端發(fā)出請(qǐng)求后，須等待接收服務(wù)器的響應(yīng)結(jié)果才能繼續(xù)執(zhí)行;

（2）客戶端與服務(wù)器強(qiáng)耦合，客戶端和服務(wù)器必須同時(shí)正常運(yùn)行;

（3）點(diǎn)對(duì)點(diǎn)通信，只有一組客戶端和服務(wù)器的通信。

面向消息的中間件（Message-Oriented Middleware， MOM）較好地解決了以上問題[2]。在消息中間件中，區(qū)別于傳統(tǒng)的遠(yuǎn)程通信客戶端和服務(wù)器的概念，通信的兩端分別為Producer（生產(chǎn)者，發(fā)送消息的一方）和Consumer（消費(fèi)者，接受消息的一方）。生產(chǎn)者將消息發(fā)送到中間件服務(wù)器中，中間件將消息通過消息隊(duì)列進(jìn)行管理[3]，在合適的時(shí)候再轉(zhuǎn)發(fā)給消費(fèi)者。這種模式下發(fā)送者和接收者之間是異步的，二者生命周期未必相同。同時(shí)，一條消息的接收者也不一定唯一，對(duì)于一個(gè)消息可以有多個(gè)接收者。

面向消息的中間件系統(tǒng)為企業(yè)提供數(shù)據(jù)傳輸服務(wù)已經(jīng)多年，但始終沒有統(tǒng)一的標(biāo)準(zhǔn)[4]。這使得各中間件廠商產(chǎn)品的實(shí)現(xiàn)和接口各異，不同廠商中間件系統(tǒng)之間難以實(shí)現(xiàn)互操作和無縫連接。在SUN公司提出Java消息服務(wù)（Java Message Service，JMS）規(guī)范后有所改觀。

本文深入研究了SUN公司的JMS規(guī)范，同時(shí)在此基礎(chǔ)上，基于JMS規(guī)范設(shè)計(jì)實(shí)現(xiàn)了中間件系統(tǒng)，并給出一個(gè)在高校選課系統(tǒng)中消息中間件的應(yīng)用實(shí)例。

1 Java消息服務(wù)

Java消息服務(wù)（JMS）是由SUN公司提出的消息中間件規(guī)范。因此JMS規(guī)范只是一系列統(tǒng)一的接口，并沒有具體實(shí)現(xiàn)。用戶可根據(jù)自己的需求對(duì)JMS接口進(jìn)行實(shí)現(xiàn)，因?yàn)樵摻涌谂c消息提供者無關(guān)，因此客戶端的應(yīng)用程序可在不同機(jī)器和系統(tǒng)中移植[5]。同時(shí)還可結(jié)合用戶實(shí)際業(yè)務(wù)而不同實(shí)現(xiàn)，以達(dá)到滿意的效果。

1.1 JMS通信方式

JMS提供客戶端與服務(wù)器的同步和異步連接，并在任何時(shí)候可對(duì)消息進(jìn)行傳送和儲(chǔ)存轉(zhuǎn)發(fā)。消息傳輸中支持兩種截然不同的通信模型：點(diǎn)對(duì)點(diǎn)模型和發(fā)布/訂閱模型[6]。

（1）點(diǎn)對(duì)點(diǎn)模型：使用Queue（即隊(duì)列）。消息從一個(gè)生產(chǎn)者傳送到一個(gè)消費(fèi)者。在此傳送模型中，消息目的地是一個(gè)隊(duì)列。消息首先傳遞給隊(duì)列目標(biāo)，再將消息從隊(duì)列發(fā)送給注冊(cè)到此隊(duì)列的消費(fèi)者。向隊(duì)列發(fā)送消息的生產(chǎn)者數(shù)量是沒有限制的，但每個(gè)消息只能由一個(gè)消費(fèi)者消費(fèi)。如果沒有已注冊(cè)到隊(duì)列目標(biāo)的消費(fèi)者，隊(duì)列將保存接收到的消息，當(dāng)消費(fèi)者注冊(cè)到隊(duì)列時(shí)再傳遞給該消費(fèi)者。點(diǎn)對(duì)點(diǎn)模型如圖1所示。

（2）發(fā)布/訂閱模型：使用Topic（即主題）。消息從一個(gè)生產(chǎn)者傳送到任何數(shù)量的消費(fèi)者。在此傳送模型中，消息目的地是一個(gè)主題。消息首先傳遞給主題目標(biāo)，再傳遞給訂閱此主題的所有活動(dòng)消費(fèi)者。向主題對(duì)象發(fā)送消息的生產(chǎn)者的數(shù)量沒有限制，并且每條消息都可發(fā)送給任意數(shù)量的訂閱者[7]。主題目標(biāo)也支持持久訂閱的概念。持久訂閱意味著消費(fèi)者已注冊(cè)了主題目標(biāo)，但該消費(fèi)者在消息傳遞時(shí)可能處于非活動(dòng)狀態(tài)。當(dāng)這位消費(fèi)者再次進(jìn)入活躍狀態(tài)時(shí)，會(huì)收到此信息。發(fā)布/訂閱模型如圖2所示。

1.2 JMS消息數(shù)據(jù)結(jié)構(gòu)

在消息中間件中，通信的兩端通過消息傳遞信息。JMS消息對(duì)象是應(yīng)用程序之間通信的基本單元。JMS消息由消息頭、消息屬性和消息體組成。消息頭描述了消息的創(chuàng)建者、創(chuàng)建時(shí)間、數(shù)據(jù)的有效長度、消息的目標(biāo)隊(duì)列或主題的路由信息。屬性由客戶端定義和設(shè)置，消息體是消息的主要部分，它描述消息的內(nèi)容。JMS消息模型如圖3所示。

（1）消息頭：所有JMS消息都支持統(tǒng)一的消息頭域，消息頭包含標(biāo)識(shí)信息和路由信息。一個(gè)完整的消息頭將會(huì)傳送給所有接收消息的JMS客戶端，但不會(huì)傳送給非JMS客戶端。

（2）消息屬性：可認(rèn)為消息屬性是附加的消息頭，用來支持JMS消息構(gòu)建工具需要的屬性值。為消息提供了一種附加可選擇的消息頭機(jī)制。附帶應(yīng)用獲其他數(shù)據(jù)，用于消息選擇器。

（3）消息體：JMS根據(jù)要攜帶的消息類型，規(guī)定消息中間件必須支持6種消息接口類型，但JMS并未定義這幾種消息接口的實(shí)現(xiàn)方式。因此允許消息提供者以自己的方式實(shí)現(xiàn)和傳送消息。這幾個(gè)接口分別是Message及該接口的5個(gè)子接口TextMessage，MapMessage，StreamMessage，ByteMessage和ObjectMessage[8]。

1.3 JMS編程模型

在JMS編程模型中，JMS客戶端通過消息服務(wù)進(jìn)行消息通信。消息生產(chǎn)者向消息服務(wù)發(fā)送信息，同時(shí)消費(fèi)者從消息服務(wù)中接受這些信息。整個(gè)通信過程使用一組JMS接口的對(duì)象來執(zhí)行。

在JMS編程模型中，JMS客戶端使用ConnectionFactory對(duì)象創(chuàng)建一個(gè)連接對(duì)象Connection，該對(duì)象用來向消息服務(wù)發(fā)送消息或接收消息。創(chuàng)建連接時(shí)，將分配通信資源。大多數(shù)的客戶端均使用同一個(gè)連接對(duì)象來進(jìn)行所有的消息通信。

接下來通過連接對(duì)象創(chuàng)建Session會(huì)話對(duì)象。Session是一個(gè)用于生成和使用消息的單線程上下文對(duì)象。用于創(chuàng)建通信的MessageProducer（生產(chǎn)者），MessageConsumer（消費(fèi)者）和Destination（消息目的地），并為發(fā)送的消息定義順序。該對(duì)象通過大量的確認(rèn)選項(xiàng)或事務(wù)來支持可靠傳輸。

發(fā)送消息時(shí)，客戶端使用MessageProducer指定Destination對(duì)象。消息生產(chǎn)者可設(shè)置默認(rèn)傳送模式（是否持久化）、優(yōu)先級(jí)和有效期值，對(duì)發(fā)往消息服務(wù)的信息進(jìn)行控制。

接收消息時(shí)，客戶端使用MessageConsumer對(duì)象從指定的Destination對(duì)象接收消息。接收過程中可使用消息選擇器來接收消息客戶端感興趣的消息。

消費(fèi)者支持同步或異步消息接收。異步接收時(shí)可向消費(fèi)者注冊(cè)MessageListener（消息監(jiān)聽器）。當(dāng)會(huì)話線程調(diào)用MessageListener對(duì)象的onMessage（）方法時(shí)，客戶端將接收該消息。JMS編程模型如圖4所示。

2 消息隊(duì)列中間件的實(shí)現(xiàn)

2.1 消息隊(duì)列技術(shù)

消息中間件采用消息隊(duì)列技術(shù)和基于消息傳遞的異步通信機(jī)制。在分布式和異構(gòu)環(huán)境中，傳統(tǒng)應(yīng)用程序之間的相互通信需要雙方同步執(zhí)行。 各系統(tǒng)應(yīng)用間耦合性過強(qiáng)，在消息中間件中使用消息隊(duì)列技術(shù)，可大大減少程序之間的耦合度，應(yīng)用程序只需發(fā)送一條消息后可繼續(xù)操作。接收方應(yīng)用程序也無需監(jiān)視整個(gè)接收過程，只需從隊(duì)列中讀取消息并對(duì)其進(jìn)行處理即可。

2.2 基于JMS的消息中間件的體系結(jié)構(gòu)

消息中間件在結(jié)構(gòu)上分為兩個(gè)部分，客戶端和服務(wù)端。其中包含了一個(gè)JMS應(yīng)用必備的4個(gè)模塊，分別是JMS客戶端、JMS提供者、消息和JNDI服務(wù)。JMS消息中間件體系結(jié)構(gòu)如圖5所示。

其中消息中間件服務(wù)包含JMS服務(wù)（消息服務(wù)）和JNDI服務(wù)（命名對(duì)象服務(wù)）。JMS規(guī)范中提供兩種受管對(duì)象，ConnectionFactory和Destinatio，即前文提到的連接工廠和消息目的地需要由JNDI命名空間進(jìn)行管理。JMS受管對(duì)象如圖6所示。

2.3 JMS消息中間件的實(shí)現(xiàn)

2.3.1 服務(wù)器端的實(shí)現(xiàn)

（1）服務(wù)器的實(shí)現(xiàn)

JMS服務(wù)器是消息中間件服務(wù)的核心。服務(wù)器啟動(dòng)時(shí)，初始化服務(wù)器，讀取主機(jī)地址、監(jiān)聽端口、服務(wù)類型等相關(guān)參數(shù)，并啟動(dòng)相應(yīng)的組件。JMS Server結(jié)構(gòu)如圖7所示。

通過讀取到的相關(guān)參數(shù)，創(chuàng)建ServerBroker組件。同時(shí)監(jiān)聽相關(guān)端口中來自客戶端的請(qǐng)求。ServerBroker組件用來處理與客戶端的消息通信;JMS Server的具體實(shí)現(xiàn)的主要API見表1所列。

最后，將啟動(dòng)的ServerBroker組件保存在列表當(dāng)中，該列表保存所有當(dāng)前活動(dòng)的客戶端連接。

消息服務(wù)可通過多種方式實(shí)現(xiàn)消息通信，如TCP，UDP，RMI，HTTP等，通過定義ServerBroker接口，規(guī)范連接過程并將具體通信方式做不同實(shí)現(xiàn)。

（2）ServerBroker接口

該消息服務(wù)的ServerBroker采用TCP方式進(jìn)行通信，調(diào)用start（）方法后，創(chuàng)建一個(gè)ServerSocket監(jiān)聽客戶端請(qǐng)求。收到連接請(qǐng)求后，ServerBroker會(huì)創(chuàng)建一個(gè)新線程，并通過ServerSocket的accep（）方法獲取客戶端socket與之通信。ServerBroker API見表2所列。

（3）Transport類的實(shí)現(xiàn)

ServerBroker組件通過Transport類實(shí)現(xiàn)消息傳遞，該類在一個(gè)新的線程當(dāng)中，通過其send（）方法輪詢的發(fā)送隊(duì)列中的消息。該線程將一直處于輪詢狀態(tài)直到調(diào)用了stopTransport（）方法。Transport API見表3所列。

（4）JNDIServer類的實(shí)現(xiàn)

JNDI服務(wù)主要用于管理受管對(duì)象ConnectionFactory和Destination。初始化JNDI服務(wù)后，TCPConnection方法創(chuàng)建ServerSocket用來監(jiān)聽客戶端的請(qǐng)求并與之建立連接。最后通過管理器通過bind（）方法綁定JNDI受管對(duì)象和消息目的地。同時(shí)客戶端可通過lookup（）方法獲取已注冊(cè)的受管對(duì)象。JNDI Server見表4所列。

2.3.2 客戶端API的實(shí)現(xiàn)

客戶端實(shí)現(xiàn)由JMS API定義的標(biāo)準(zhǔn)接口。 本系統(tǒng)的JMS客戶接口的主要實(shí)現(xiàn)如下：

（1）Connection對(duì)象

Connection是JMS客戶端和JMS消息服務(wù)之間處于活動(dòng)狀態(tài)的套接字。Connection在創(chuàng)建客戶端時(shí)對(duì)其可指定唯一的客戶端標(biāo)識(shí)符。連接創(chuàng)建后，它處于掛起模式，此時(shí)不提供任何消息。直到客戶調(diào)用 start（）方法開始消息傳遞。JMS針對(duì)兩種消息模型定義了兩種連接對(duì)象。我們?cè)诖藢?shí)現(xiàn)QueueConnectionImpl和TopicConnectionImpl。主要功能為獲取Session對(duì)象和啟動(dòng)關(guān)閉連接。

（2）Session對(duì)象

Session對(duì)象是通信中消息的創(chuàng)建者、生產(chǎn)者、消費(fèi)者、主題和隊(duì)列的生產(chǎn)工廠。針對(duì)JMS規(guī)范，創(chuàng)建實(shí)現(xiàn)類SessionImpl，用于創(chuàng)建不同類型的消息，并返回相應(yīng)Message對(duì)象;用于創(chuàng)建通信的客戶端、生產(chǎn)者、消費(fèi)者;用于創(chuàng)建消息目的地和消息模型。

（3）MessageProducer對(duì)象

MessageProducer對(duì)象由Session對(duì)象創(chuàng)建，主要用于向?qū)?yīng)Destination發(fā)送消息。其中主要實(shí)現(xiàn)其send（）方法。通過設(shè)定目的地、傳送方式、優(yōu)先級(jí)等發(fā)送消息。

（4）MessageComsumer對(duì)象

MessageConsumer是Session對(duì)象所創(chuàng)建，用于接收來自Destination 的消息。主要實(shí)現(xiàn)receive（）方法用來接收消息。receive（）方法中可配置消息選擇器用于配置接收期望的消息。同時(shí)可選擇通過或異步的接收消息。對(duì)于同步接收，采用輪詢的辦法;對(duì)于異步接收，將會(huì)注冊(cè)一個(gè)消息監(jiān)聽器MessageListener對(duì)象，并通過其OnMessage方法來處理異步消息。

2.3.3 消息模型的實(shí)現(xiàn)

消息模型按照J(rèn)MS規(guī)范中消息結(jié)構(gòu)的定義對(duì)其進(jìn)行實(shí)現(xiàn)。消息頭中，Messageheader類中包含了Destination，MessageID，Priority等消息識(shí)別信息和路由信息。JMSMessageID唯一標(biāo)識(shí)了隊(duì)列或主題中的每一個(gè)消息。

2.3.4 消息隊(duì)列中間件在高校選課系統(tǒng)中的應(yīng)用

高校選課系統(tǒng)中的主要需求是選課時(shí)對(duì)課程余量的并發(fā)爭搶。有限的課程數(shù)量面對(duì)瞬時(shí)的高并發(fā)請(qǐng)求，此時(shí)就可利用消息中間件良好的異步通信特性來實(shí)現(xiàn)。當(dāng)用戶點(diǎn)擊選課按鈕后，將請(qǐng)求發(fā)送至中間件服務(wù)器。隊(duì)列管理器開始將請(qǐng)求加入課程選課隊(duì)列，成功則告知正在選課，否則客戶端響應(yīng)選課結(jié)束。對(duì)于隊(duì)列中的選課請(qǐng)求則進(jìn)行課程余量減庫存處理，并記錄結(jié)果。選課過程完成后標(biāo)記選課結(jié)束，并清空選課隊(duì)列，避免重復(fù)判斷和處理[9-10]。

用戶輪詢結(jié)果，如果選課結(jié)束且該用戶選課失敗，則跳轉(zhuǎn)到選課結(jié)束頁面，否則繼續(xù)等待直到成功。后面選課結(jié)果的持久化，則是選課邏輯中需要操作的業(yè)務(wù)。消息中間件在高校選課系統(tǒng)中的應(yīng)用實(shí)例如圖8所示。

4 結(jié) 語

消息中間件在大型企業(yè)分布式應(yīng)用中具有豐富的應(yīng)用。相較于通過遠(yuǎn)程調(diào)用實(shí)現(xiàn)服務(wù)傳遞的系統(tǒng)，面向消息的中間件提出了一種靈活、擴(kuò)展性好且使用簡單的通信模式?？蔀楦卟l(fā)需求提供緩沖，也可忽略平臺(tái)異構(gòu)性，為分布式應(yīng)用提供簡單的中間橋梁。極大地增強(qiáng)了系統(tǒng)集成的簡易程度和擴(kuò)展性，降低了系統(tǒng)更新維護(hù)成本和難度，使系統(tǒng)更加高效運(yùn)行。目前，面向消息的中間件系統(tǒng)已成為中間件系統(tǒng)中發(fā)展最快體系，有著非常廣闊的前景。

參 考 文 獻(xiàn)

[1]陳旭東. 基于CORBA技術(shù)的綜合電信網(wǎng)管系統(tǒng)的構(gòu)建[D].北京：華北電力大學(xué)，2005.

[2]張靖，邱云.JMS信息發(fā)布異構(gòu)平臺(tái)應(yīng)用研究[J].煤炭技術(shù)，2010，29（1）：209-211.

[3]何雙元. 高并發(fā)下消息隊(duì)列模型的研究與應(yīng)用[D].武漢：武漢理工大學(xué)，2015.

[4]朱方娥，曹寶香.基于JMS的消息隊(duì)列中間件的研究與實(shí)現(xiàn)[J].計(jì)算機(jī)技術(shù)與發(fā)展，2008（5）：172-175.

[5]汪濤. 基于SOA架構(gòu)的中間件應(yīng)用集成研究[D].西安：西安電子科技大學(xué)，2011.

[6] 佚名.Java Message Service API Rev[EB/OL].[2002-04-08].http： //java.sun. com/products/jms/.

[7]李艷春，李新，焦文彬.分布式信息系統(tǒng)中數(shù)據(jù)交換平臺(tái)設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)工程與設(shè)計(jì)，2012（7）：2640-2645.

[8]珍兆科.Java EE 6開發(fā)手冊(cè)·高級(jí)篇[M].北京：電子工業(yè)出版社，2014.

[9]王迎.自動(dòng)化測試平臺(tái)的設(shè)計(jì)與實(shí)現(xiàn)[D]北京：北京交通大學(xué)，2015.

[10]邵作鎮(zhèn)，萬曉冬.基于STAF的軟件自動(dòng)化測試研究與應(yīng)用[J].電子科技，2010（7）：9-11.