專利名稱：企業(yè)服務(wù)總線及企業(yè)服務(wù)總線的消息處理方法
技術(shù)領(lǐng)域：
本發(fā)明涉及電子商務(wù)交易技術(shù)領(lǐng)域，尤其涉及一種應(yīng)用于電子商務(wù)交易平臺的 一種企業(yè)服務(wù)總線及企業(yè)服務(wù)總線的消息處理方法。
背景技術(shù)：
目前，大型企業(yè)網(wǎng)之間的應(yīng)用集成服務(wù)日益復(fù)雜，傳統(tǒng)的點對點式的系統(tǒng)集成 顯得捉襟見肘。為了解決這一問題，人們提出了企業(yè)服務(wù)總線(enterprise service bus，簡 稱ESB)的概念，即組成企業(yè)網(wǎng)的各個子系統(tǒng)以類似于接插件的方式接入一個公共的信息 平臺，彼此之間相對獨立，由調(diào)度引擎進行統(tǒng)一的數(shù)據(jù)調(diào)度，以高效整合數(shù)據(jù)和業(yè)務(wù)流 程。按照著名的IT研究與顧問咨詢機構(gòu)Gartner公司所給的定義，企業(yè)服務(wù)總線是一種 體系結(jié)構(gòu)，利用企業(yè)的Web服務(wù)、消息中間件、智能路由和轉(zhuǎn)換技術(shù)實現(xiàn)，是傳統(tǒng)中間 技術(shù)與XML、Web服務(wù)等技術(shù)結(jié)合的產(chǎn)物，ESB提供了網(wǎng)絡(luò)中最基本的連接中樞。企 業(yè)服務(wù)總線技術(shù)的目標是以標準化的方式實現(xiàn)企業(yè)應(yīng)用集成，完成企業(yè)間應(yīng)用系統(tǒng)的互 聯(lián)、互通和互操作，其中的標準化工作包括連接器標準化、管理標準化、業(yè)務(wù)消息標準 化和消息標準化等。
ESB的出現(xiàn)改變了傳統(tǒng)的軟件架構(gòu)，可以提供比傳統(tǒng)中間軟件產(chǎn)品更為廉價的 解決方案，同時它還可以消除不同應(yīng)用服務(wù)之間的技術(shù)差異，讓不同的應(yīng)用服務(wù)協(xié)調(diào)運 作，實現(xiàn)了不同服務(wù)之間的通信與整合。從功能上看，ESB提供了事件驅(qū)動和文檔導(dǎo)向 的處理模式，以及分布式的管理機制，它支持基于內(nèi)容的路由和過濾，具備了復(fù)雜數(shù)據(jù) 的傳輸能力，并提供一系列的標準接口。例如，申請?zhí)枮椤?00810227316.9”的中國專 利申請公開了 一種企業(yè)服務(wù)總線的實現(xiàn)方法。
現(xiàn)有的電子商務(wù)交易平臺，服務(wù)使用者直接調(diào)用服務(wù)提供者是多對多的，雜亂 無序的，很難對行內(nèi)的服務(wù)進行維護管理；服務(wù)調(diào)用者與后臺服務(wù)的實現(xiàn)間耦合度過 高，往往牽一發(fā)而動全身，后臺服務(wù)究竟有多少調(diào)用者，應(yīng)用調(diào)用了哪些服務(wù)不清導(dǎo) 致維護困難，服務(wù)使用者和服務(wù)提供者之間的可靠性、事務(wù)處理、同步/異步通信、 安全認證管理都需要兩者之間單獨實現(xiàn)，缺少一個公共的基礎(chǔ)架構(gòu)；并且，缺少對 后臺服務(wù)進行監(jiān)控、統(tǒng)計并提供分析數(shù)據(jù)的統(tǒng)一途徑，不便于對面向服務(wù)的體系結(jié)構(gòu) (Service-Oriented Architecture, J 簡稱 SOA)的應(yīng)用進行維護管理。發(fā)明內(nèi)容
本發(fā)明解決的問題是提供一種企業(yè)服務(wù)總線，將其應(yīng)用于企業(yè)電子交易平臺 時，可以實現(xiàn)不同的應(yīng)用程序之間整合，服務(wù)使用者不必進行復(fù)雜的異步調(diào)用，由服務(wù) 總線來完成同步到異步模式的轉(zhuǎn)換。
為解決上述問題，本發(fā)明提供一種企業(yè)服務(wù)總線，包括
消息接收單元，包括多個消息接收通道，每一消息接收通道用于接收包括至少 一個服務(wù)請求的消息；
消息隊列單元，用于從所述多個消息接收通道接收消息，并按預(yù)定規(guī)則進行排 序；
處理線程組，用于從所述消息隊列單元接收預(yù)定數(shù)量的已排序的消息；
請求處理單元，用于從所述處理線程組中獲取所述消息中的服務(wù)請求，并處理 該服務(wù)請求。
可選的，所述按預(yù)定規(guī)則進行排序是指按消息發(fā)送或接收的時間順序進行排序。
可選的，所述消息包括至少兩個服務(wù)請求；
所述企業(yè)服務(wù)總線還包括請求拆分單元，用于將所述消息拆分成服務(wù)請求后 發(fā)送給所述消息接收單元。
可選的，所述消息包括至少兩個服務(wù)請求；
所述企業(yè)服務(wù)總線還包括請求拆分單元，用于將所述消息接收單元接收的消 息拆分成服務(wù)請求后發(fā)送給所述消息隊列單元。
可選的，所述消息包括至少兩個服務(wù)請求；
所述企業(yè)服務(wù)總線還包括請求拆分單元，用于將所述消息隊列單元接收的消 息拆分成服務(wù)請求后發(fā)送給所述處理線程組。
可選的，所述請求處理單元包括多種請求處理管道，每一種請求處理管道對應(yīng) 處理一種服務(wù)請求。
可選的，所述請求處理單元處理服務(wù)請求包括按預(yù)定的流程生成至少一個訪問 請求，并基于所述訪問請求調(diào)用對應(yīng)的應(yīng)用服務(wù)。
可選的，還包括請求傳送通道，用于將從所述請求處理單元生成的訪問請求 發(fā)送給對應(yīng)的應(yīng)用服務(wù)。
可選的，所述包括至少一個服務(wù)請求的消息被加密，所述企業(yè)服務(wù)總線還包括 解密單元，用于在所述請求處理單元按預(yù)定的流程處理服務(wù)請求前對所述消息進行解r t [ ο
為解決上述技術(shù)問題，本發(fā)明還提供一種企業(yè)服務(wù)總線的消息處理方法，包 括
接收消息，每一消息包括至少一個服務(wù)請求；
按預(yù)定規(guī)則對所述接收的消息進行排序；
處理預(yù)定數(shù)量的已排序的消息中的服務(wù)請求。
可選的，所述消息包括至少兩個服務(wù)請求；
所述消息處理方法還包括將所述消息拆分成服務(wù)請求。
可選的，所述處理服務(wù)請求包括按預(yù)定的流程生成至少一個訪問請求，并基 于所述訪問請求調(diào)用對應(yīng)的應(yīng)用服務(wù)。
可選的，所述包括至少一個服務(wù)請求的消息被加密；
在所述處理服務(wù)請求前還包括對所述消息進行解密。
與現(xiàn)有技術(shù)相比，本發(fā)明具有以下優(yōu)點
本發(fā)明提供的企業(yè)服務(wù)總線應(yīng)用于電子交易平臺時，服務(wù)使用者不必直接調(diào)用 服務(wù)提供者提供的服務(wù)，服務(wù)使用者和服務(wù)提供者通過標準接口與電子交易平臺連接，將各種應(yīng)用程序整合于電子交易平臺，并通過本發(fā)明的企業(yè)服務(wù)總線實現(xiàn)各個應(yīng)用程序 之間的調(diào)用，服務(wù)使用者不必進行復(fù)雜的異步調(diào)用，由企業(yè)服務(wù)總線來進行同步到異步 模式的轉(zhuǎn)換。
并且本發(fā)明的企業(yè)服務(wù)總線通過處理線程組限定電子交易平臺可以處理的消息 的數(shù)量，對超過該數(shù)量的消息不響應(yīng)，避免對某個服務(wù)的調(diào)用的壓力過大，造成電子交 易平臺當機。


圖1是本發(fā)明具體實施例的企業(yè)服務(wù)總線的內(nèi)部架構(gòu)示意圖2是請求處理單元的架構(gòu)示意圖3是具體實施例的訪問請求的處理流程框圖4是本發(fā)明具體實施例的企業(yè)服務(wù)總線應(yīng)用于電子交易平臺的示意圖。
具體實施方式
本發(fā)明具體實施方式
的企業(yè)服務(wù)總線應(yīng)用于電子交易平臺時，服務(wù)使用者不必 直接調(diào)用服務(wù)提供者，服務(wù)使用者和服務(wù)提供者通過標準接口與電子交易平臺連接，將 各種應(yīng)用服務(wù)整合于電子交易平臺，并通過本發(fā)明的企業(yè)服務(wù)總線實現(xiàn)對各個應(yīng)用服務(wù) 的調(diào)用，服務(wù)使用者不必進行復(fù)雜的異步調(diào)用，由企業(yè)服務(wù)總線來進行同步到異步模式 的轉(zhuǎn)換；并且本發(fā)明的企業(yè)服務(wù)總線通過處理線程組限定電子交易平臺可以處理的消息 的數(shù)量，對超過該數(shù)量的消息不響應(yīng)，避免對某個服務(wù)(應(yīng)用服務(wù))的調(diào)用的壓力過大， 造成電子交易平臺當機。
參考圖1，本發(fā)明具體實施方式
的企業(yè)服務(wù)總線100，包括消息接收單元 110，用于接收多個服務(wù)使用者發(fā)送的消息，包括多個消息接收通道，分別為消息接收通 道1、消息接收通道2……消息接收通道n，每一消息接收通道接收包括至少一個服務(wù)請 求的消息；為了減少服務(wù)使用者對不同的服務(wù)請求分別進行操作，在一個消息接收通道 里包括至少一個服務(wù)請求，服務(wù)使用者可以一次提出多個服務(wù)請求；在服務(wù)使用者一次 提出多個服務(wù)請求時，通過請求打包單元將用戶進行的多個服務(wù)請求打包后以消息的形 式發(fā)送，在本發(fā)明的該具體實施例中，所述消息包括至少兩個服務(wù)請求，所述企業(yè)服務(wù) 總線還包括請求拆分單元(圖中未示)，用于將所述消息拆分成服務(wù)請求后發(fā)送給所述消 息接收單元110;在本發(fā)明的具體實施例中，消息接收通道還通過調(diào)用加密單元，將消 息接收通道接收的消息加密。
消息隊列單元120，用于從消息接收單元110中接收消息，并且將來自于多個消 息接收通道的多個消息，根據(jù)時間順序進行排隊，時間在前的消息比時間在后的消息優(yōu) 先處理，在此的時間順序?qū)?yīng)于服務(wù)使用者提出請求操作的先后順序，也可以是消息隊 列單元120接收消息的先后順序，參考圖1，排隊后的消息隊列分別為消息隊列10、消 息隊列20……消息隊列nO ；且在消息進入消息隊列單元120前，消息隊列單元120調(diào)用 請求拆分單元(圖中未示)，由請求拆分單元將打包的消息拆分成服務(wù)請求，此服務(wù)請求 的數(shù)量對應(yīng)于服務(wù)使用者提出的服務(wù)請求數(shù)量，參考附圖1，消息隊列10中的消息被拆 分成服務(wù)請求11，服務(wù)請求12，服務(wù)請求13，消息隊列20中的消息被拆分成服務(wù)請求21，服務(wù)請求22，服務(wù)請求23，……消息隊列nO中的消息被拆分成服務(wù)請求nl，服務(wù) 請求n2，服務(wù)請求n3，需要說明的是，此例中每一消息被拆分成三個服務(wù)請求，只是起 示例性，在具體的實施例中，每一消息中包括的服務(wù)請求數(shù)量根據(jù)具體情況(即服務(wù)端 用戶的操作)而定；需要說明的是，在本發(fā)明的該具體實施例中根據(jù)時間順序?qū)ο㈥?列單元中的消息進行排隊，在本發(fā)明的其他實施例中也可以根據(jù)其他預(yù)定規(guī)則對消息隊 列單元中的消息進行排隊，例如根據(jù)消息的優(yōu)先級(重要性)對消息隊列單元中的消息進 行排隊。
在本發(fā)明的另一實施例中，將打包的消息進行拆分也可以在消息接收通道接收 消息前，所述消息包括至少兩個服務(wù)請求；所述企業(yè)服務(wù)總線還包括請求拆分單元， 用于將所述包括至少一個服務(wù)請求的消息拆分成服務(wù)請求后發(fā)送給所述消息隊列接收單 元。在本發(fā)明的其他實施例中，將打包的消息進行拆分也可以在處理線程組接收消息 前，所述消息包括至少兩個服務(wù)請求；所述企業(yè)服務(wù)總線還包括請求拆分單元，用于 從所述消息隊列單元接收消息，并將所述消息隊列單元接收的包括至少一個服務(wù)請求的 消息拆分成服務(wù)請求后發(fā)送給所述處理線程組。
處理線程組130，包括預(yù)定數(shù)量的處理線程，分別為處理線程1、處理線程 2……處理線程n，用于從所述消息隊列單元120接收預(yù)定數(shù)量的已排序的消息；處理 線程組130中的處理線程的數(shù)量為預(yù)定的數(shù)量，此數(shù)量根據(jù)電子交易平臺的處理能力設(shè) 定，例如，處理線程組130中的處理線程的數(shù)量為200個，則同一時間電子交易平臺只能 響應(yīng)200個消息，對于第200個以后的消息，電子交易平臺不響應(yīng)，避免服務(wù)使用者過多 造成電子交易平臺當機的現(xiàn)象，從而可以確保電子交易平臺的正常運行。其中，處理線 程1儲存消息隊列10中的服務(wù)請求11、服務(wù)請求12、服務(wù)請求13，處理線程2儲存消息 隊列20中的服務(wù)請求21、服務(wù)請求22、服務(wù)請求23，……處理線程η儲存消息隊列nO 中的服務(wù)請求nl、服務(wù)請求n2、服務(wù)請求n3。
請求處理單元140，用于從所述處理線程組130中獲取所述消息中的服務(wù)請求， 并處理該服務(wù)請求；在該具體實施例中，請求處理單元140包括多種請求處理管道， 每一種請求處理管道包括多個請求處理管道，每一種請求處理管道對應(yīng)處理一種服務(wù)請 求；參考圖2，請求處理單元140包括多種請求處理管道，分別為第一種請求處理管道10、第二種請求處理管道20……第N種請求處理管道nO，每一種請求處理管道包括多個 請求處理管道，每種請求處理管道可以處理多個相同類型的服務(wù)請求，以第一種請求處 理管道10為例，該第一種請求處理管道10包括多個請求處理管道分別為請求處理管道11、請求處理管道12……請求處理管道In;所述處理線程130從所述消息隊列單元110 獲取消息，并將獲取的已拆分成服務(wù)請求的消息處理后發(fā)送給對應(yīng)的請求處理管道；需 要說明的是，所述請求處理管道的種類與服務(wù)的種類請求存在對應(yīng)的關(guān)系，每一種服務(wù) 請求對應(yīng)相同種類的請求處理管道，每一消息中包括的服務(wù)請求將會進入對應(yīng)種類的請 求處理管道中，由請求處理管道處理服務(wù)請求。其中，在該具體實施例中，每一種請求 處理管道包括解密階段(stage)，處理階段(stage)，此解密階段對應(yīng)消息接收通道接收消 息時，調(diào)用加密單元對消息加密，將加密的消息通過調(diào)用解密單元解密，在其他實施例 中，每一種請求處理管道可以包括不同的階段，例如也可以包括解壓階段。在本發(fā)明的 該具體實施例中，所述處理階段處理服務(wù)請求包括按預(yù)定的流程生成至少一個訪問請求，并基于所述訪問請求調(diào)用對應(yīng)的應(yīng)用服務(wù)。其中，應(yīng)用服務(wù)由服務(wù)提供者提供，通 過訪問請求調(diào)用應(yīng)用服務(wù)，在請求處理管道的處理階段為根據(jù)預(yù)定的預(yù)定的流程生成訪 問請求，由訪問請求調(diào)用應(yīng)用服務(wù)，應(yīng)用服務(wù)根據(jù)訪問請求進行處理，生成訪問請求的處理結(jié)果。
在本發(fā)明的具體實施例中，企業(yè)服務(wù)總線還包括請求傳送通道，用于尋址， 將從所述請求處理單元生成的訪問請求發(fā)送給對應(yīng)的應(yīng)用服務(wù)。
以上所述為服務(wù)使用者發(fā)送消息至應(yīng)用服務(wù)的處理過程，應(yīng)用服務(wù)根據(jù)訪問請 求生成訪問請求的處理結(jié)果要返回給服務(wù)使用者。在本發(fā)明的該具體實施例中，應(yīng)用服 務(wù)根據(jù)訪問請求生成訪問請求的處理結(jié)果返回給服務(wù)使用者的過程和服務(wù)使用者發(fā)送消 息至應(yīng)用服務(wù)的處理過程相反，首先通過請求傳送通道將調(diào)用應(yīng)用服務(wù)后的信息發(fā)送給 對應(yīng)的請求處理管道，由請求處理管道將信息加密后發(fā)送給對應(yīng)的處理線程，請求處理 線程將接收到的服務(wù)請求的結(jié)果發(fā)送給對應(yīng)的消息隊列，之后發(fā)送給對應(yīng)的消息接收通 道，當一個消息中包括的所有的服務(wù)請求結(jié)果都返回其對應(yīng)的消息接收通道時，消息接 收通道調(diào)用請求打包單元，將一個消息中包括的所有消息打包后發(fā)送給相應(yīng)的服務(wù)使用 者，此時用戶可以得到所發(fā)送的消息的處理結(jié)果。需要說明的是，在此使用“對應(yīng)” 一 詞的意思為，返回的消息、請求經(jīng)由來時的路徑返回。
本發(fā)明中的所述消息可以為各種商品的交易消息，以鋼材的電子商務(wù)交易為 例，商品為鋼材，交易消息包括發(fā)布鋼材現(xiàn)貨的交易消息(對應(yīng)于鋼材的出庫、入庫)， 合約的交易信息(對應(yīng)于采購、銷售的意向)，還包括注冊消息(對應(yīng)于注冊成為電子交 易平臺的會員)，更新商品消息，注銷消息(對應(yīng)于注銷電子交易平臺的會員)，更新注 冊消息(對應(yīng)于更新會員信息)，積分查詢、信用查詢等。
以服務(wù)使用者需要查詢積分和信用等與用戶信息有關(guān)的信息為例說明，服務(wù)使 用者發(fā)送查詢用戶信息，消息接收單元中消息接收通道接收查詢用戶信息的消息，由于 用戶信息包括積分、信用等信息，查詢用戶信息的消息包括積分服務(wù)請求，信用服務(wù)請 求等，將查詢用戶信息對應(yīng)的積分服務(wù)請求、信用服務(wù)請求等打包，之后發(fā)送給消息接 收單元的消息接收通道；消息接收通道接收到查詢用戶信息的消息后，調(diào)用加密模塊， 對該查詢用戶消息加密，之后將該查詢用戶信息的消息發(fā)送給消息隊列單元，也可以由 消息隊列單元從消息接收通道中獲取查詢用戶信息的消息，在消息隊列單元接收消息時 調(diào)用請求拆分單元，將查詢用戶信息拆分成對應(yīng)的積分服務(wù)請求、信用服務(wù)請求等，因 此進入消息隊列單元中的查詢用戶消息為拆分后的服務(wù)請求，參考圖1，如果查詢用戶 消息對應(yīng)于消息10，則積分服務(wù)請求對應(yīng)于服務(wù)請求11，信用服務(wù)請求對應(yīng)于服務(wù)請求 12；之后積分服務(wù)請求、信用服務(wù)請求等經(jīng)由處理線程后進入服務(wù)請求對應(yīng)的請求處理 管道，積分服務(wù)請求進入積分服務(wù)請求對應(yīng)的請求處理管道，信用服務(wù)請求進入信用服 務(wù)請求對應(yīng)的請求處理管道，例如，積分服務(wù)請求進入第一種請求處理管道10中的請求 處理管道11、信用服務(wù)請求進入第二種請求處理管道20中的請求處理管道，由各自對應(yīng) 的請求處理管道對積分服務(wù)請求、信用服務(wù)請求進行處理后生成訪問請求，以積分服務(wù) 請求為例，積分服務(wù)請求對應(yīng)的請求處理管道首先經(jīng)解密階段將加密的積分服務(wù)請求解 密，解密后進入積分服務(wù)請求的處理階段生成調(diào)用積分數(shù)據(jù)庫的訪問請求，從數(shù)據(jù)庫中 查詢積分。
以上所述的具體實施例的積分服務(wù)請求的處理階段，沒有涉及具體的業(yè)務(wù)，只 是簡單的積分的查詢，因此并沒有涉及業(yè)務(wù)流程。電子交易平臺涉及具體的交易業(yè)務(wù)， 必然會有業(yè)務(wù)流程，根據(jù)預(yù)定的業(yè)務(wù)流程才可以使業(yè)務(wù)順利的進行，而且預(yù)定的流程將 決定完成一個交易需要的消息的種類。
利用本發(fā)明的企業(yè)服務(wù)總線的電子交易平臺的具體實施必須依靠具體的業(yè)務(wù)流 程，以確保電子交易的順利進行，根據(jù)具體的交易可以設(shè)定不同的業(yè)務(wù)流程，該業(yè)務(wù)流 程對應(yīng)于預(yù)定流程，并且該業(yè)務(wù)流程存儲于流程單元中，在具體執(zhí)行服務(wù)請求時，根據(jù) 服務(wù)請求的處理階段的需求調(diào)用業(yè)務(wù)流程。
以電子商務(wù)交易中的合約交易為例說明業(yè)務(wù)流程在處理階段的作用。圖3為完 成一次合約交易的具體實施例的業(yè)務(wù)流程，根據(jù)圖3所示的具體實施例的業(yè)務(wù)流程，將 合約交易分成四種消息分別為標準合約發(fā)布200，對應(yīng)于第一種消息；申請結(jié)算單位 關(guān)聯(lián)300，對應(yīng)于第二種消息；合約執(zhí)行400，對應(yīng)于第三種消息；合約履約申請500， 對應(yīng)于第四種消息；首先會員發(fā)布標準合約，然后申請綁定結(jié)算單位，公司審核通過 后，合約才開始生效，進入生效合約，然后可以執(zhí)行合約，進入執(zhí)行中合約階段，合約 執(zhí)行完畢或者執(zhí)行到一定程度后，會員可以申請履約，進入履約中合約，合約履行完畢 后，進入已履約合約，此時合約執(zhí)行完畢。在此，以發(fā)布合約為例進行說明，對于其他 種類的交易，根據(jù)交易的種類，可以根據(jù)預(yù)定的流程分為不同的種類的消息。
參考圖3詳細說明根據(jù)該預(yù)定的流程執(zhí)行合約交易的實施過程。
當服務(wù)使用者執(zhí)行標準合約發(fā)布200，此消息即為一個服務(wù)請求，無需再對其 進行拆分，在請求處理管道中執(zhí)行標準合約發(fā)布消息的處理階段時，請求處理管道從流 程單元中調(diào)用圖3所示的業(yè)務(wù)流程，請求處理管道根據(jù)與標準合約發(fā)布有關(guān)的業(yè)務(wù)流程 中的預(yù)定的規(guī)則將該服務(wù)請求分成多個步驟，具體為步驟201，檢查合約價格是否通 過，此時請求處理管道調(diào)用數(shù)據(jù)庫中的合約價格，如果合約價格通過，進行步驟202，檢 查發(fā)布人會員信用是否夠用，此時請求處理管道調(diào)用信用模塊，如果會員信用不夠用不 能發(fā)布合約，如果會員信用夠用，可以發(fā)布合約，并產(chǎn)生標準合約會員信用占用，通過 信用模塊修改標準合約會員的信用，之后進行步驟203，生成標準合約，并將生成標準合 約的結(jié)果反饋給服務(wù)使用者，完成標準合約發(fā)布的服務(wù)請求。
繼續(xù)參考圖3，電子交易平臺的管理者看到發(fā)布的標準合約，想要購買該發(fā)布的 標準合約，使之成為生效合約時，執(zhí)行申請結(jié)算單位(對應(yīng)于真實的客戶)關(guān)聯(lián)300， 此為第二種消息，此消息即為一個服務(wù)請求，無需再對其進行拆分，請求處理管道根據(jù) 業(yè)務(wù)流程中的預(yù)定的規(guī)則將該服務(wù)請求分成多個步驟，具體為步驟301，業(yè)務(wù)管理人 員審核，其中審核的內(nèi)容根據(jù)實際的需要進行規(guī)定，如果審核未通過，合約不能關(guān)聯(lián)結(jié) 算單位，并將該不能關(guān)聯(lián)結(jié)算單位的結(jié)果發(fā)送給服務(wù)使用者；如果審核通過，進行步驟 302，業(yè)務(wù)管理人員手工輸入合約預(yù)計虧損占用，并產(chǎn)生關(guān)聯(lián)合約風(fēng)險信用占用(對應(yīng)會 員信用)，此時同時調(diào)用信用模塊，通過信用模塊更改會員信用，之后進入步驟303，業(yè) 務(wù)管理人員上傳合約文本掃描件，建立真實的客戶合約，并同時把真實客戶合約掃描件 作為關(guān)聯(lián)合約附件，接下來進入步驟304，產(chǎn)生關(guān)聯(lián)合約信用占用(對應(yīng)交易信用)，同 時釋放標準合約信用占用(對應(yīng)于會員信用)，此時通過調(diào)用信用模塊完成對交易信用的 占用和會員信用的釋放，進入步驟305，關(guān)聯(lián)合約生成成功，產(chǎn)生生效合約的結(jié)果，并將該結(jié)果返回。
繼續(xù)參考圖3，在進行合約執(zhí)行400時，對應(yīng)第三種消息，此消息即為一個服務(wù) 請求，無需再對其進行拆分，請求處理管道根據(jù)預(yù)定流程的預(yù)定的規(guī)則將執(zhí)行生效合約 具體分為步驟401，發(fā)現(xiàn)貨，發(fā)現(xiàn)貨后，合約由生效合約進入執(zhí)行中合約，此時可以 調(diào)用信用模塊，按照執(zhí)行量和合約量的比例釋放部分或全部的關(guān)聯(lián)合約信用，并將結(jié)果 通過消息接收通道發(fā)送給服務(wù)使用者。
當服務(wù)使用者將現(xiàn)貨發(fā)貨，收貨人收到貨物后，將進行合約履約申請500，對 應(yīng)于第四種消息，此消息即為一個服務(wù)請求，無需再對其進行拆分，請求處理管道根據(jù) 預(yù)定流程的預(yù)定規(guī)則將該服務(wù)請求分成多個步驟具體為步驟501，公司審核，如果審 核未通過，輸出結(jié)果不能履約，如果審核通過，釋放合約未履約占用信用，調(diào)用信用模 塊，完成釋放合約未履約占用信用，完成合約的履行后，進入步驟502，履約中合約轉(zhuǎn)化 為已履約合約；此時可以調(diào)用積分模塊，進行合約積分考核分配。
以上所述的本發(fā)明提供的企業(yè)服務(wù)總線應(yīng)用于電子交易平臺時，服務(wù)使用者不 必直接調(diào)用服務(wù)提供者提供的服務(wù)，服務(wù)使用者和服務(wù)提供者通過標準接口與電子交易 平臺連接，將各種應(yīng)用程序整合于電子交易平臺，并通過本發(fā)明的企業(yè)服務(wù)總線實現(xiàn)各 個應(yīng)用程序(在該具體實施例中以信用模塊為例進行說明)之間的調(diào)用，服務(wù)使用者不必 進行復(fù)雜的異步調(diào)用，由企業(yè)服務(wù)總線來進行同步到異步模式的轉(zhuǎn)換。
以上所述的具體實施例，僅以一個單獨的合約信息為例進行說明，在具體實例 中，會同時有多個不同的客戶端發(fā)送信息，通過設(shè)置處理線程組中線程的數(shù)量，使線程 組一次只能處理一定數(shù)量線程的消息，避免對某個服務(wù)的調(diào)用的壓力過大，造成電子交 易平臺當機。
本發(fā)明的企業(yè)服務(wù)總線存在于JVM (Java Virtual Machine，Java虛擬機)中。企業(yè)服務(wù)總線外部的節(jié)點是外部服務(wù)使用者和服務(wù)提供者，代表了企業(yè)服務(wù)總線要集成的外 部實體，這些外部實體可以通過各種各樣的技術(shù)與企業(yè)服務(wù)總線綁定的服務(wù)模塊交互。
圖4為企業(yè)服務(wù)總線應(yīng)用于電子交易平臺的框架示意圖，
企業(yè)服務(wù)總線100與流程單元600連接，所述流程單元600，用于向服務(wù)總線提 供與所述服務(wù)請求對應(yīng)的處理流程。并且，在該電子交易平臺上，設(shè)有用戶端接口 801， 可以供用戶1、用戶2……用戶η接入電子交易平臺，需要注冊成為電子交易平臺的用戶 由用戶管理單元803管理注冊，要注冊成為電子交易平臺的用戶必須通過用戶管理單元 803的身份驗證后才可以成為電子交易平臺的用戶；且企業(yè)服務(wù)總線設(shè)有服務(wù)端接口， 供應(yīng)用服務(wù)1、應(yīng)用服務(wù)2……應(yīng)用服務(wù)η接入電子交易平臺，服務(wù)提供者向電子交易平 臺提供應(yīng)用服務(wù)時，首先必須經(jīng)過服務(wù)管理單元804的驗證，經(jīng)服務(wù)管理單元804驗證的 應(yīng)用服務(wù)才可以通過企業(yè)服務(wù)總線發(fā)布到電子交易平臺。
與以上所述的企業(yè)服務(wù)總線對應(yīng)，本發(fā)明還提供一種企業(yè)服務(wù)總線的消息處理 方法，包括接收消息，每一消息包括至少一個服務(wù)請求；
按預(yù)定規(guī)則對所述接收的消息進行排序；
處理預(yù)定數(shù)量的已排序的消息中的服務(wù)請求。
其中，所述消息包括至少兩個服務(wù)請求；所述消息處理方法還包括將所述消 息拆分成服務(wù)請求。
所述處理服務(wù)請求包括按預(yù)定的流程生成至少一個訪問請求，并基于所述訪 問請求調(diào)用對應(yīng)的應(yīng)用服務(wù)。
所述包括至少一個服務(wù)請求的消息被加密；在所述處理服務(wù)請求前還包括對所 述消息進行解密。
本發(fā)明雖然已以較佳實施例公開如上，但其并不是用來限定本發(fā)明，任何本領(lǐng) 域技術(shù)人員在不脫離本發(fā)明的精神和范圍內(nèi)，都可以利用上述揭示的方法和技術(shù)內(nèi)容對 本發(fā)明技術(shù)方案做出可能的變動和修改，因此，凡是未脫離本發(fā)明技術(shù)方案的內(nèi)容，依 據(jù)本發(fā)明的技術(shù)實質(zhì)對以上實施例所作的任何簡單修改、等同變化及修飾，均屬于本發(fā) 明技術(shù)方案的保護范圍。
權(quán)利要求
1.一種企業(yè)服務(wù)總線，其特征在于包括消息接收單元，包括多個消息接收通道，每一消息接收通道用于接收包括至少一個 服務(wù)請求的消息；消息隊列單元，用于從所述多個消息接收通道接收消息，并按預(yù)定規(guī)則進行排序； 處理線程組，用于從所述消息隊列單元接收預(yù)定數(shù)量的已排序的消息； 請求處理單元，用于從所述處理線程組中獲取所述消息中的服務(wù)請求，并處理該服 務(wù)請求。
2.如權(quán)利要求1所述的企業(yè)服務(wù)總線，其特征在于，所述按預(yù)定規(guī)則進行排序是指按 消息發(fā)送或接收的時間順序進行排序。
3.如權(quán)利要求1所述的企業(yè)服務(wù)總線，其特征在于，所述消息包括至少兩個服務(wù)請求；所述企業(yè)服務(wù)總線還包括請求拆分單元，用于將所述消息拆分成服務(wù)請求后發(fā)送 給所述消息接收單元。
4.如權(quán)利要求1所述的企業(yè)服務(wù)總線，其特征在于，所述消息包括至少兩個服務(wù)請求；所述企業(yè)服務(wù)總線還包括請求拆分單元，用于將所述消息接收單元接收的消息拆 分成服務(wù)請求后發(fā)送給所述消息隊列單元。
5.如權(quán)利要求1所述的企業(yè)服務(wù)總線，其特征在于，所述消息包括至少兩個服務(wù)請求；所述企業(yè)服務(wù)總線還包括請求拆分單元，用于將所述消息隊列單元接收的消息拆 分成服務(wù)請求后發(fā)送給所述處理線程組。
6.如權(quán)利要求1所述的企業(yè)服務(wù)總線，其特征在于，所述請求處理單元包括多種請求 處理管道，每一種請求處理管道對應(yīng)處理一種服務(wù)請求。
7.如權(quán)利要求1所述的企業(yè)服務(wù)總線，其特征在于，所述請求處理單元處理服務(wù)請求 包括按預(yù)定的流程生成至少一個訪問請求，并基于所述訪問請求調(diào)用對應(yīng)的應(yīng)用服務(wù)。
8.如權(quán)利要求7所述的企業(yè)服務(wù)總線，其特征在于還包括請求傳送通道，用于將 從所述請求處理單元生成的訪問請求發(fā)送給對應(yīng)的應(yīng)用服務(wù)。
9.如權(quán)利要求1所述的企業(yè)服務(wù)總線，其特征在于，所述包括至少一個服務(wù)請求的消 息被加密，所述企業(yè)服務(wù)總線還包括解密單元，用于在所述請求處理單元按預(yù)定的流程 處理服務(wù)請求前對所述消息進行解密。
10.一種企業(yè)服務(wù)總線的消息處理方法，其特征在于包括 接收消息，每一消息包括至少一個服務(wù)請求；按預(yù)定規(guī)則對所述接收的消息進行排序； 處理預(yù)定數(shù)量的已排序的消息中的服務(wù)請求。
11.如權(quán)利要求10所述的企業(yè)服務(wù)總線的消息處理方法，其特征在于，所述消息包括 至少兩個服務(wù)請求；所述消息處理方法還包括將所述消息拆分成服務(wù)請求。
12.如權(quán)利要求10所述的企業(yè)服務(wù)總線的消息處理方法，其特征在于，所述處理服務(wù) 請求包括按預(yù)定的流程生成至少一個訪問請求，并基于所述訪問請求調(diào)用對應(yīng)的應(yīng)用服務(wù)。
13.如權(quán)利要求10所述的企業(yè)服務(wù)總線的消息處理方法，其特征在于，所述包括至少 一個服務(wù)請求的消息被加密；在所述處理服務(wù)請求前還包括對所述消息進行解密。
全文摘要
一種企業(yè)服務(wù)總線及企業(yè)服務(wù)總線的消息處理方法，企業(yè)服務(wù)總線包括消息接收單元，包括多個消息接收通道，每一消息接收通道用于接收包括至少一個服務(wù)請求的消息；消息隊列單元，用于從所述多個消息接收通道接收消息，并按預(yù)定規(guī)則進行排序；處理線程組，用于從所述消息隊列單元接收預(yù)定數(shù)量的已排序的消息；請求處理單元，用于從所述處理線程組中獲取所述消息中的服務(wù)請求，并處理該服務(wù)請求。將各種應(yīng)用程序整合于電子交易平臺，并通過本發(fā)明的企業(yè)服務(wù)總線實現(xiàn)各個應(yīng)用程序之間的調(diào)用，服務(wù)使用者不必進行復(fù)雜的異步調(diào)用，由企業(yè)服務(wù)總線來進行同步到異步模式的轉(zhuǎn)換。
文檔編號H04L29/06GK102025653SQ201010197480
公開日2011年4月20日 申請日期2010年6月4日 優(yōu)先權(quán)日2010年6月4日
發(fā)明者虞鋼 申請人:西本新干線股份有限公司