ESB(Enterprise Service Bus，企業服務總線)，提供了消息交互的基礎結構，使得消息可以傳輸到對應的服務中去。目前大多數的ESB系統都是采用基于內容的路由算法，即根據消息的內容把消息路由到正確的服務單元。當有較多服務單元接收消息時，此種算法的工作效率將大幅下降，ESB也會承擔較大的負載，使得整個系統集成的效率降低。常規的解決方案是把判斷服務單元是否應該接收消息的邏輯分布到各個服務單元上，但此方法增加了維護的負擔。為了保持集中控制，可以在每條消息附帶的列表中指定這個消息所面向的接收者。這樣，當消息被廣播給所有可能的接收者時，不在接收者列表中的各個接收者可以丟掉該消息。

但采用這種方法的缺點是效率低，每個潛在的接收者必須處理每一條消息。并且，如果要求消息不希望被某些接收者看到，采用這種解決方案是不適合的。例如在發送某些機密消息時，是不希望無關接收者收到消息的。

為了解決上述問題，文中提出了基于接收表的ESB路由算法，可以提高消息交互的效率和消息的保密性。

1 接收表路由算法的分析與設計

在基于接收表的路由算法中，應為每個接收者定義一個通道，可以定義一個規則庫來檢驗輸入的消息，確定需要該消息的接受者列表，并把消息轉發給與列表中接收者關聯的所有通道。

1．1 路由設計

在接收表的算法中，接收表路由器主要由接收者計算邏輯和消息分配器兩個部分組成，消息的傳遞過程，如圖1所示。

接收者計算邏輯首先對消息進行處理，確定此消息應該發送到哪些服務中去，計算出接收者列表，進而分配器將消息轉發到服務所對應的通道中去，最后服務接收到此消息。在接收者計算邏輯中，要對消息的內容進行分析，并且要結合服務接收消息的規則來計算接收者的列表。

接收者計算邏輯應將服務者與其服務地址及服務規則進行關聯，可以進行如下表示。

Routing：=

(1)ser_id表示服務單元的編號；

(2)ser_name表示服務的名稱；

(3)uri表示服務的地址；

(4){ser_rule}表示該服務單元的規則集。

ser_rule應將規則的名稱和該規則要求的值進行關聯，可以進行如下表示：

ser_rule：=

(1)rule_name表示規則的名稱；

(2)value表示規則的對應值。

接收者計算邏輯映射為xml文件的形式，并且將服務的地址和服務單元要求的規則進行了描述。

在上述xml形式的接收者計算邏輯中，以服務單元B為例對規則庫進行說明。“<／rule>”定義了服務地域的規則，即只服務北京的客戶，“<／rule>”定義了服務客戶類型的規則，即只服務于企業，“<／rule>”定義了服務項貸款的最大金額，其值為5 000萬元。

獲取接收者列表的算法，可以進行如下描述：S為服務單元的集合，Si為的某個服務單元。ri為服務單元i的規則集，rij為服務單元i的某條規則，servicerList為接受者列表，在初始化時加載所有的服務單元(1≤i≤n，1≤j≤m，n為節點的個數，m為某個服務節點的規則的個數)。

／／如果不能滿足此服務單元的路由規則，則接收者列表中刪除此服務單元。

1．2 動態化

為了使服務能夠動態的調整自己的服務對象，提高整個系統集成的靈活性。將路由規則分布到各個服務來控制，是一種理想的解決方案。通過接收表的動態化，整個系統的實時性也有進一步的提高。例如，服務單元N以前只能處理貸款金額<1 000萬元的服務請求，而服務單元N進行系統升級后，可以處理貸款金額<1億元的服務請求，此時應該對接收表中規則庫做相應的調整。為了實現這種功能，應在服務節點和接收表之間建立控制信息傳輸通道，使得服務節點能把自己處理消息的要求發送給接收表，并存儲到其規則庫中，其流程如圖2所示。

接口程序是由ESB路由器提供，服務單元只需調用ESB的(修改xml路由文件)服務接口，實現對接收表計算邏輯的修改。

接口設計：

class ServiceOperation

{

CreateServicer(Servicel s)；／／創建服務

UpdateServicer(Serricer s)；／／更新服務包括服務名，路徑的修改

RemoveServicer(String ServicerID)；／／根據服務的ID刪除對應服務在路由器中的信息

CreateServicerRule(String ServicerID，StringruleName，String rule Value)；

／／根據服務的ID，創建該服務新的規則

UpdateServicerRule(String ServicerID，StringruleName，String ruleValue)；

／／根據服務的ID和規則的名稱，更新規則的值

RemoveServicerRule(String ServicerID，StringruleName)；

／／根據服務的ID和規則的名稱，刪除該規則

}

此接口應以Web服務的方式暴露給與ESB集成的服務單元，使其可以調用接口中的方法來實時改變服務單元的服務。

1．3 事務處理

接收表在進行消息傳遞時，應使用事務性通道，把消息放置到輸出通道中屬于同一個事務的一部分。

為了保證事務，接收表路由器在發送消息m到服務單元后，服務單元應向接收表路由器發送ack消息。當接收表接收到所有應接收到消息m的服務單元返回的ack消息后，接收表路由器向服務單元發送commit消息，服務單元接收到commit消息后，才真正接收消息m。這樣就保證所有消息要么全部發送，要么都不發送，從而避免了有的服務單元得到消息而有的服務單元沒有得到消息的情況的發生，保證了整個系統的一致性。

1. 4 服務單元失效處理策略

以在應用ESB集成的系統環境中，服務單元可能會發生故障。為提高系統的可用性，采用以下服務單元失效處理策略。

每個服務單元定時向ESB的接受表路由器發送消息available告知服務處于活動狀態。每個服務單元保存ESB所集成的所有服務單元的信息表。該列表同時記錄最后一次收到各個節點available消息的時間。

當ESB的接受表路由器長時間收不到服務單元Ⅳ的available消息，則認為服務單元Ⅳ失效，接受表路由器刪除本地全局路由表中有關該服務單元的路由信息及其規則庫。

2 接收表的工作效率

與ESB集成的服務單元中，如果只有較少數量的服務單元接收消息，則基于內容的路由算法，有一定的速度優勢，但當有大多數服務單元接收消息的情況下，由于接收表同時向多個服務單元發送消息，則接收表路由算法的效率會更高。

在基于內容的路由算法中，消息傳遞到服務單元的期望時間與接收此消息的服務單元的數理呈現線性增長(t=kn，t為從發送消息到所有消息都被服務單元接收所用的時間，n為服務單元的個數，k為系數)的關系。而應用接收表的算法中，消息傳遞到服務單元的期望時間與接收此消息的服務單元的數理呈現近似二次曲線(t2=kn)的關系。兩種路由算法的效率比較情況，如圖3所示。

3 結束語

文中研究并設計了基于接收表的ESB路由算法，并對路由算法的效率、動態化、事務處理和失效處理等關鍵問題進行了分析。基于接收表的路由算法提高了消息交互的效率，并且保證了消息的安全性和實時性，是利用ESB進行系統集成的解決方案之一。