1、基于XML和工作流的消息代理設計與實現(xiàn)        摘  要  文章提出了一種在消息的路由、轉換、聚合和分拆以及消息的標識和關聯(lián)中采用XML技術和工作流技術相結合的消息代理結構，并詳細討論了其技術細節(jié)和實現(xiàn)方案，最后給出了該消息代理在口岸商務平臺的一個應用案例。     關鍵詞  XML 工作流 消息代理 消息路由 聚合和分拆      1 引言    消息代理 是一種以消息

2、為載體、以獨立的第三方軟件體系為消息處理平臺，在數(shù)據(jù)源與目的地之間移動數(shù)據(jù)使信息處理流暢的軟件技術，數(shù)據(jù)源和目的地包括已有的應用、文件、數(shù)據(jù)庫、對象（如CORBA、COM）、硬拷貝輸出以及Web客戶端等。消息代理主要提供數(shù)據(jù)的遞送、收集、過濾、聚合或分拆、翻譯、映射、轉換和路由等功能，屏蔽不同的軟硬件平臺、數(shù)據(jù)庫、消息格式、通信協(xié)議，提供應用到應用之間的高效、便捷、準確的互操作能力。     基于工作流和XML的消息代理技術則是指，在消息通過相關的通信途徑如FTP、HTTP、POP3等到達消息代理后，消息代理首先將它們XML化，即把平面文件、HTML文件或者數(shù)據(jù)庫

3、的原始數(shù)據(jù)等規(guī)范化成XML格式的數(shù)據(jù)。這樣在隨后的消息翻譯和映射轉換，消息的聚合和分拆，消息的標志和關聯(lián)等消息代理的相關功能實現(xiàn)過程中可以方便的借助XML技術來完成。然后根據(jù)預定義的工作流程來協(xié)調需要一系列復雜處理過程的交易處理。 2  消息代理體系結構    通常，消息代理都是基于消息隊列技術。消息隊列可駐留在內存或磁盤上，隊列存儲消息直到它們被應用程序讀走。通過消息隊列，應用程序可獨立的執(zhí)行，它們只需要知道雙方所在系統(tǒng)環(huán)境下的消息隊列位置而不需要知道彼此確切的位置或在繼續(xù)執(zhí)行前不需要等待接收程序接收此消息等，這不僅減少了資源共享問題，也為應用間的通信

4、提供了便利。     而消息代理則是對消息隊列的一種擴展。它一般采用發(fā)布/訂閱式或點到點式或二者相結合的消息交換模式，它具有以下特點：         提供對數(shù)據(jù)庫的支持。消息代理使用數(shù)據(jù)庫來存儲與之相關的數(shù)據(jù)，例如持久性控制數(shù)據(jù)，從而使消息代理具有長事務處理能力。         提供與各種資源的接口、數(shù)據(jù)轉換能力和消息處理能力，高效的實現(xiàn)應用之間的消息傳遞。         提供商務

5、邏輯層開發(fā)能力。消息代理提供一種支持流管理、處理智能化開發(fā)工具，使用戶可以根據(jù)需要開發(fā)出合適的工作流和商務智能構件。         基于消息的代理骨干，其基于API的適配器以及包裝程序完全能適應在不改變已有應用的基礎上適應業(yè)務邏輯和組織機構的變化。     一個典型的、基于發(fā)布/訂閱和點到點模式的多引擎消息代理結構如下圖所示：圖1  多引擎的消息代理體系結構     該消息代理體系結構分通信、存儲、消息引擎和控制邏輯四層。最底層是通信層，支持的接口通信協(xié)議包括HT

6、TP，F(xiàn)TP，SMTP，TCP/IP等，適配器/包裝程序負責將通過上述協(xié)議獲得的包含應用數(shù)據(jù)的消息在各種格式間進行轉換，完成應用與代理的通信。     通信層的上層是存儲層，該層負責應用的注冊以及日志記錄。對于從通信層獲得的消息，通過匹配控制邏輯層創(chuàng)建和存儲的商務策略來決定是否需要事務處理，對于需要長事務處理的消息可以存儲在數(shù)據(jù)庫中，反之則存儲在消息隊列中供消息引擎實時處理。     存儲層的上層是消息引擎層，該層有兩個核心功能：消息的映射轉換和消息的路由。消息的映射轉換負責把存儲在隊列或數(shù)據(jù)庫中的消息通過預定義的轉換程序轉換成規(guī)范的

7、XML格式，該XML格式稱之為中間格式。之后再由其他轉換程序轉換成應用可以識別的其他格式如平面文件，EDIFACT文件等格式文件。消息路由程序接收和分發(fā)消息并基于預先定義好的消息處理流程確保轉發(fā)給正確的應用。消息的路由程序通常能執(zhí)行多段的路由（“基于HUB的路由”），對于一個單個的消息，可以根據(jù)消息的源、目的地、類型、格式等定義多個處理段或對象。對象可以包括消息的轉換、數(shù)據(jù)的格式轉換、查詢數(shù)據(jù)庫、記錄日志和定時傳送等。應用間的互通可以是一對一、一對多或多向的。     消息代理的最上層是控制邏輯層，提供基于第四代的開發(fā)語言和工具讓開發(fā)者對消息的類型、消息的路由邏輯

8、、例外處理、工作流等進行定義，并作為組件、模塊或數(shù)據(jù)存儲在相應庫中，從而實現(xiàn)對數(shù)據(jù)的靈活控制。 3  消息代理系統(tǒng)的實現(xiàn)3.1  消息的路由和可靠傳輸    消息的路由分為消息匹配和消息投遞兩個主要部分。     消息匹配是一種邏輯路由，它可以根據(jù)預先定義的邏輯規(guī)則，確定消息從哪里獲取，發(fā)給誰，有些什么要求，而不用關心消息的獲取和發(fā)送是如何實現(xiàn)的。消息代理用隊列接收并存儲生產者發(fā)送的消息，同時用數(shù)據(jù)庫來存儲生產者和消費者的一些控制信息。當消息經由XML規(guī)范化后，消息所包含的源目的地址、消息類型等信息保存為元素、屬性

9、或記錄等元數(shù)據(jù)值。消息引擎根據(jù)這些元素和屬性再查詢匹配數(shù)據(jù)庫中存儲的注冊信息來確定消息的去向。對于消息的消費者屬于SP的情況，路由程序可以根據(jù)登記的路由表來循環(huán)遞歸找到消息的最終消費者或者把消息交給SP來進行進一步的分發(fā)。     消息的投遞則是一種物理路由。每個應用在建立與消息代理的通信連接前都要登記自己的通信連接信息，相關參數(shù)數(shù)據(jù)將保存在數(shù)據(jù)庫中。消息匹配完成后，消息引擎通過查找消息接收者的通信連接信息后，選擇合理的路徑，通過通信層來完成消息的投遞。     消息的可靠性要求消息投遞一次而且僅僅一次，消息代理在消息的處理過程中會對

10、該消息當前處理的一個狀態(tài)作一個快照，即在日志記錄里保存現(xiàn)場，一旦消息處理失敗，則可以從該現(xiàn)場開始繼續(xù)接著處理而不必從頭開始，直到消息被正確投遞到正確位置。 3.2  消息的映射和轉換    在消息投遞之前，消息引擎要檢查消息的接收者所能夠接收的消息格式，如果當前消息格式不能匹配接收的格式，那么消息代理要對消息進行相關的映射和轉換。     消息的映射和轉換模塊就是負責這種轉換。消息的生產者提供的消息具有不同的格式，在經過消息引擎后將規(guī)范化成XML格式，這樣有一個好處是，使消息統(tǒng)一化后以便于保證消息的一致性和減少轉換關系，還能

11、便于利用XML的技術來處理復雜的。     例如若消息接收者接收非XML格式的文檔，轉換模塊負責根據(jù)轉換程序來將XML格式轉換成對應的格式。在消息代理內部會為每種消息格式定義一個數(shù)據(jù)結構，在進行轉換的時候將按照此數(shù)據(jù)結構讀入文檔，如果文檔不符合數(shù)據(jù)機構，那么將認為是非法文檔，這可以用來校驗文檔的有效性。其中可以利用DTD和XML Schema兩種方式來定義XML文檔結構，這可以充分發(fā)揮XML技術的優(yōu)勢。 3.3 消息的聚合和分拆    有一種情況，當消費者同時接收到來自幾個不同的生產者或同一生產者的不同消息時，消費者并不需要幾個獨立的

12、消息，消息代理提供這樣一種機制，將關聯(lián)的消息按照某種順序放到隊列或數(shù)據(jù)庫中，然后經由某種聚合算法將這幾個消息聚合成消費者可以接受的消息，再路由給消費者，其示意圖1         如下：      圖2 消息的聚合和分拆        該圖中，聚合算法包括以下三個方面：消息分組、消息抽取、消息合并合合圖需要A時候將按照此數(shù)據(jù)結構讀入數(shù)據(jù)。消息分組決定選擇哪些消息，然后將這些分組。消息抽取是將要聚合

13、的內容從每個消息中抽取出來，以便于聚合。消息合并是將這些抽取的內容按照一定的規(guī)則進行合并成一個獨立的消息實體。     同樣的道理，當消費者只對消息的某一部分感興趣，那么消息代理將從中抽取出來并進行一定的包裝，然后作為一個新的消息交給消費者。 3.4 消息的關聯(lián)和工作流的制定    以上討論的都是簡單的消息應用處理，當要進行復雜的消息交互的時候，消息代理必須提供一種機制，讓消息引擎能將相互獨立的消息進行關聯(lián)，這需要為每個消息分配一個獨一無二的標識，在消息代理內部將為每個消息產生一個標識號，在消息的整個生命周期內該標識是唯一的。如生產者

14、在發(fā)送一個消息時同時訂閱了該消息的回執(zhí)，那么在消息進入消息代理后，消息代理為該消息分配一個唯一的標識，在經過處理、路由給消費者時，消費者將收到包含該標識的消息，消費者同時生產一個包含該標識的回執(zhí)交給消息代理，消息代理根據(jù)此標識來確認該消息的去向，從而實現(xiàn)了消息的關聯(lián)。     消息的處理都是按照一定的商務規(guī)則來進行，消息代理提供工具以便開發(fā)者可以根據(jù)實際的商業(yè)處理流程來靈活定義工作流，一個簡單的通用工作流定義如：消息通過通信模塊進入消息代理，消息代理首先將消息進行分類，再進行下一步的操作，包括格式轉換、加密解密、校驗、應用商業(yè)規(guī)則、封裝、路由等，最后通過通信模塊送

15、往目的地。以上工作流模塊均是以模塊化形式存在，用戶可以開發(fā)定制，然后注冊由系統(tǒng)自動調用。 3.5 事務和回滾    上面的情況中，如果沒有與生產者消息相匹配的消費者消息，即消費者沒有響應，由于關聯(lián)性，代理必須取消生產者該次的消息發(fā)布，直到消費者的回執(zhí)消息到達。這就需要消息代理支持事務和回滾。例如應用A向應用B轉賬，當A上的賬款已劃出在沒有收到應用B的收款確認的回復消息時，該次交易將被取消。     消息代理與數(shù)據(jù)庫的結合能很好的解決這一問題。當消息引擎接收到消息后將一份拷貝持久化到數(shù)據(jù)庫中，并將該過程的控制信息保存，當消息超時或者超過

16、一定限度仍沒有回應，代理將認為該次交易不成功，反之數(shù)據(jù)庫中的消息將被激活。 4  在口岸商務平臺的應用    在口岸電子商務平臺上的一個典型應用如下：某類出口A中貨運系統(tǒng)需要向另外一類船公司企業(yè)B中訂艙系統(tǒng)訂艙，在得到對方訂艙確認后確定出口貨物事宜。企業(yè)A和企業(yè)B分別處于不同的操作系統(tǒng)，且數(shù)據(jù)分別由SQL Server和ORACLE兩種不同的數(shù)據(jù)庫管理系統(tǒng)管理，同時企業(yè)A在發(fā)出訂艙請求后必須得到訂艙確認，這就需要一個中間平臺來屏蔽雙方不同系統(tǒng)之間的差異，從而實現(xiàn)兩者之間的商務溝通，采用上述的基于XML和工作流的消息代理系統(tǒng)可以方便快捷的實現(xiàn)，其應用場景如

17、下圖所示：    圖3 消息代理在口岸商務應用場景    該應用場景采用事件驅動機制來觸發(fā)整個系統(tǒng)，具體工作機制如下：     （1）消息發(fā)送：企業(yè)A通過自己的貨運系統(tǒng)制作訂艙消息（如平面文件），通過FTP、HTTP等通信協(xié)議與消息代理提供的通信接口建立連接，并向消息代理提交訂艙消息，該消息包括消息頭和消息體兩部分，消息頭中攜帶了源目的地址、通信協(xié)議、事務標記、消息號等，消息體中是消息的內容，也就是具體的訂艙信息。消息代理接收到企業(yè)A的訂艙信息后首先從頭部獲得要發(fā)送的目的地址，并根據(jù)事務標記判斷

18、是否需要持久化，然后消息引擎會根據(jù)預定義的工作流來觸發(fā)下一步的動作，如轉換格式、轉換代碼等。     （2）消息接收：消息代理中的消息引擎按照工作流程處理完源消息后將產生一個中間格式的消息，此時消息引擎會從企業(yè)B的配置里面找到所定義的一些配置信息，如消息格式、通信協(xié)議、是否接收該類消息等豐富的選項，消息引擎將匹配這些規(guī)則后將消息做進一步處理成企業(yè)B可接收的目標消息，最后消息將由通信模塊根據(jù)路由表的一些信息將消息送達企業(yè)B并等待對方的訂艙確認信息。     （3）消息的事務處理：消息代理在接收源消息后自動產生一個消息標識以跟源消息參考號進行關聯(lián)，同時將時間戳標記等一并寫入數(shù)據(jù)庫中，在消息處理后送達企業(yè)B時，也會將該信息連同時間戳再次寫入數(shù)據(jù)庫，并等待對方確認。理想情況下，企業(yè)B將會發(fā)送一個帶有消息標識的訂艙確認消息給消息代理，消息代理會再根據(jù)此消息標識找到對應的源消息，并將此消息回傳給企業(yè)A，那么交易成功。最壞情況下，如果代理在規(guī)定時限內沒得到企業(yè)B的確認或超時，代理會取消該次交易，并發(fā)送一個系統(tǒng)回執(zhí)給企業(yè)A，告訴其事務取消及其原因，從而實現(xiàn)了交易的事務回滾。 5 結束語