分布式企業服務數據研究范文

本站小編為你精心準備了分布式企業服務數據研究參考范文，愿這些范文能點燃您思維的火花，激發您的寫作靈感。歡迎深入閱讀并收藏。

1國內外研究現狀

在數據集成中異構數據源之間往往存在著語法和語義方面的數據沖突問題。XML技術能夠較好地解決語法層面的數據沖突，而對于語義層的異構問題，一般采用知識庫和本體技術，通過描述不同數據源的概念信息，并構建語義映射關系加以解決。已有的數據集成工作主要采用聯邦數據庫系統、數據倉庫技術和基于中間件的信息集成技術來實現。聯邦數據庫系統（FDS）是多數據庫系統數據集成方法，在已存在的局部數據庫（LocalDatabaseSystem，LDS）之上為用戶提供統一的存取數據環境。FDS由一組獨立的LDS組成，實現數據庫系統間部分數據的共享。以數據倉庫（DataWarehouse，DW）為主的數據集成方法，通過對相關數據庫的鏈接，抽取數據記錄，復制需要的字段，將異構或同構數據源相關數據復制到特定數據源上，從而解決數據的分布和異構的問題，達到集成的目的。上述兩種方法對異構數據大都采取先把數據轉換為統一、靜態的格式，再將數據轉換和整合規則融合在定制代碼中。由于應用系統代碼與數據庫模式緊密耦合，不能適應數據動態變化，這兩種數據集成方案較脆弱。目前主流的數據集成方式是基于中間件的數據集成方案。傳統的中間件解決方案是用DCOM、CORBA及RMI等分布式對象模型來構建信息集成系統。這種方法可以有效地避免聯邦數據庫系統開發代價大、代碼重用難的問題，但分布式對象模型要求服務客戶端與服務之間必須進行緊密耦合。隨著SOA框架和WebService技術的發展，傳統應用中間件向企業服務總線（EnterpriseServiceBus，ESB）過渡。ESB成為企業數據集成采用的主流技術，它將基于事件驅動架構（Event－DrivenArchitecture，EDA）的思想與面向服務體系架構（Service－OrientedArchitecture，SOA）的思想相結合，簡化業務單元的集成，在異構平臺和環境之間建立了聯系。ESB系統的消息轉換和消息路由功能為數據異構性問題提供了解決方案。集成大量的異構數據源需要建立高效、可靠的數據傳輸機制，集中式的ESB實現架構難以滿足集成的需求。IBM提出了聯邦式的ESB模式以及中介式的ESB模式，將多個服務總線通過JMS相聯接，以支持大規模的跨組織應用集成。國內外對ESB的實現架構進行了大量研究，并建立了多個基于JBI（JavaBusinessIntegration）規范的分布式ESB平臺，如MuleESB、ApacheServiceMix、OpenESB等。目前的一些分布式ESB系統已經可以支持應用整合、復雜業務集成以及消息的可靠傳輸。在負載均衡方面，動態負載均衡策略考慮的關鍵問題是及時、準確地把握節點的負載狀況，并根據各節點當前的負載狀態來動態調整和分配任務。動態負載均衡策略一般可分為兩類，一類是求最優解問題，即集群系統的節點提供系統負載、流量及其他一些資源信息，并通過高效通信機制傳給負載均衡器，負載均衡器監視所有節點的狀態，以便將下一個任務分配給負載最輕的節點。在進行負載最輕的決策時，由于系統處于不斷變化中，從更新負載信息到做出決策之間存在時間差，有可能出現負載信息過時的狀況。為了解決這一問題，有些研究人員提出先從全集中隨機選取包含K個元素的子集，再從子集中選擇負載最低的一個。這種基于反饋的動態選取方式雖然存在一些局限性，但是對于節點數相對較少的分布式系統來說仍然是一種行之有效的方式。另一類動態負載均衡策略主要是通過負載遷移的方式來保持節點之間的負載均衡，這種策略的關鍵是確定過載和輕載的對象，以及需要遷移的負載數。負載遷移雖然可以較好地處理系統的過載現象，但是頻繁的負載遷移會增加系統的額外開銷，而且還會造成“負載抖動”問題。在基于企業服務總線系統的負載均衡機制方面，目前主流的開源ESB項目如Mule和ServiceMix都在一定程度上加入了一些負載均衡的實現，但是MuleESB的集群比較弱，只能配置一個主實例和一個從實例，因此它的負載均衡機制主要是為了解決服務路由的問題，即根據集成到總線上的服務負載狀況，選擇負載最輕的一個作為目標服務，以此確定路由路徑［22］。目前，國內外針對基于分布式企業服務總線實現架構下的負載均衡機制的研究還比較少，尤其是面向數據集成場景時，多個集群節點中大量數據消息的負載平衡仍是需要解決的問題。本文主要研究分布式ESB系統中的數據集成模型及方法，以解決異構數據的集成問題，并通過設計負載均衡策略來保證系統在大規模數據集成時的效率。

2分布式企業服務總線

D－ESB服務總線系統通過實現多種中介模式來生成特定的中介組件。中介組件的主要工作就是消息表現層的轉換和消息內容的轉換，消息表現層轉換是指改變消息格式，而消息內容的轉換主要是為了解決數據集成中的語法及語義異構性問題。在企業服務總線系統中，可以通過實現特定的組件來完成傳輸協議的轉化，這類組件也通常被稱為適配組件，例如數據庫適配器、HTTP適配器等。此外，在ESB中，可以通過服務端點來實現服務提供者的地址透明性，因為每一個接入的服務都會暴露成一個服務端點，而服務端點又與特定的適配器相綁定。本文研究的分布式企業服務總線結構如圖1所示。整個框架由ESB主節點、ESB從節點、監控管理平臺以及流程建模工具4部分組成。ESB主節點主要負責分布式環境管理，監控和統計各個客戶端的資源信息，并且通過加載中介組件來提供消息轉換和消息路由的功能。ESB從節點主要負責異構系統及外部應用的接入。監控管理平臺是ESB服務端與平臺管理員的可視化接口，管理員可以通過Console完成對各個客戶端的資源管理以及消息流監控。流程建模工具給用戶提供了圖形化工具來完成集成場景的建模和部署。

3分布式ESB系統的數據集成模型

3．1基于消息的數據集成方法分布式ESB系統采用基于消息的數據集成方法。在這種基于消息的數據集成方法中，適配器作為企業服務總線的一種消息處理組件，主要充當外部異構數據源與總線之間交互的，異構數據源通過適配器接入ESB總線。適配器和ESB總線，以及ESB總線內部通過消息進行通信。分布式ESB系統的數據集成基本思路如下：1）企業服務總線平臺在系統／異構數據源的數據傳遞與互操作上采用XML作為數據描述與交換的語言。2）將異構數據源抽象成統一的XML格式數據。將XML數據封裝成JMS消息，將異構數據源數據的轉換和傳輸問題轉換成ESB環境下的消息轉換和路由問題。3）通過XSLT轉換引擎實現對不同的XML消息格式的轉換。面向數據集成的ESB消息轉換工作流程如圖2所示。消息轉換的整個流程可分為應用接入和數據轉換兩個過程。作為應用接入部分的適配器邏輯完成對具體數據源的包裝、連接及各種讀寫操作。一方面它將從數據源獲取的結構化、半結構化數據轉換為公共的基于XML的數據格式，并以消息流的方式發送到下一個消息組件（轉換中介）的消息通道中；另一方面，適配器從消息轉換中介的消息通道中取出消息，并將消息體中經過轉換的數據格式轉換成需要的結構化或半結構化數據，輸送到目的數據源。而ESB的中介模塊的作用是接收消息發送者所定義格式的消息，經過轉換或者路由以后以消息接收者所預期的格式傳遞到接收方。這個過程中涉及到多方面的消息處理，可以是對消息的格式、內容進行轉化，也可以是加密、解密等自定義操作。在數據集成中，適配器既可以作為服務提供者，也可以作為服務的消費者。以數據庫適配器為例，作為服務提供者的數據庫適配器提供了4個接口，即CRUD這4種數據庫操作，這些操作可以通過標準的服務描述規范配置成具體的某一個服務到注冊中心。外部系統可以通過服務注冊中心查找特定種類的服務，在獲得服務的描述信息以后去調用服務進行具體操作。而在ESB環境內部中，適配器可以接收到消息通道中的ESB消息，并對消息內容進行解析和提取，之后調用數據庫適配器內部接口進行具體的數據庫操作。處理完成后通過適配器把回復內容轉化為ESB消息，消息目標為服務消費者的回復端點。作為服務消費者的數據庫適配器可以定時地檢測本地數據庫表是否有記錄更新，發現有新的記錄則將更新的內容封裝成ESB消息以后進行輸出。適配器只需要知道要負責監聽的數據庫表的地址就可以完成如上的操作。對于如何提供這個地址給適配器，具體的適配器解決的方式也可以不同。比如，可以將監聽地址配置在流程中，當適配器框架部署某個適配器的流程時將地址信息部署到該適配器上，之后適配器就能夠啟動監聽；另一種方式也可以將監聽地址的信息配置在服務配置文件中，在部署服務的時候將地址信息部署到某個具體適配器上，之后在部署服務端點的時候適配器啟動監聽。本文的數據庫適配器在開發的時候選擇了后者的處理方式。

3．2基于WSDL的消息模型企業服務總線平臺內部的適配模塊要在異構系統與ESB之間提供的功能，特定的適配器可以抽象出接入到總線上的數據源的具體實現，通過協調不同系統間的傳輸協議（例如FILE、JMS、SOAP、JDBC等）來完成消息轉換過程中的傳輸層轉換。為了實現上述功能以及組件間的交互通信，在面向數據集成的企業服務總線平臺中定義了基于WSDL的消息模型。JBI規范中使用WSDL1．1和2．0規范描述組件所提供的和消費的服務模型。WSDL在以下兩個層面上定義了基于消息的服務模型：1）抽象服務模型：使用抽象消息模型定義的、未限制到特定消息交換協議的服務。WSDL服務描述中抽象服務模型需要定義以下幾個元素：抽象消息類型（MessageType）、抽象操作（Operation）以及抽象服務類型（ServiceType）。2）具體服務模型：建立在抽象服務模型之上，為抽象服務同特定通信協議及通信端點的映射提供描述信息。WSDL具體服務模型需要定義以下幾個元素：綁定類型（BindingType）、端點（Endpoint）以及服務（Service）。以外部應用為數據庫系統為例，在面向數據集成的企業服務總線平臺中定義了如下的基于WSDL的消息模型：type元素中通過import引入的XSD文件（XMLSchemaDefinition）即XML結構定義，描述了XML文檔的存放結構，因此可以通過該文件來生成JMS消息體中的XML文檔格式。例如，當外部應用為數據庫系統時，數據接入服務需要在XML文檔結構和數據庫結構之間建立映射，把數據從數據庫轉換成XML文檔，或者把一個XML文檔轉換到數據庫中。本文將關系模式映射到XML模式，圖4表示了將數據庫表person結構映射成XMLSchema的person．xsd文件。

3．3基于XSLT的消息轉換企業服務總線平臺內部所涉及的消息轉換按層次角度區分，可以分為3類：傳輸層轉換、消息表現層轉換和消息內容轉換層。其中傳輸層轉換主要是為了協調不同系統間傳輸協議的區別，主要由適配模塊完成；消息中介模塊則負責消息表現層轉換與消息內容轉換層，圖2中所示即為將應用A格式的數據轉換為應用B格式數據的過程。為了解決異構數據間的映射問題，在ESB平臺內部采用XML來描述和存儲數據，再通過映射規則進行數據轉換。常用轉換規則表示有XSLT（eXtensibleStylesheetLanguageTransformations）和用戶自定義規則等。XSLT的主要功就是轉換，它將一個沒有形式表現的XML內容文檔作為源樹，將其轉換為一個可顯示的有樣式信息的結果樹。同時，在XSLT文檔中定義與XML文檔中各個邏輯成分相匹配的轉換模板，以及匹配轉換方式。圖2中的Transformer是將源消息格式轉換為目的消息格式的主要模塊，它可以根據配置信息來選擇合適的消息轉換器，并按照規則庫中存儲的XSLT規則把消息轉化成合適的格式，圖7所示為根據XSLT語法規則定義的樣式文件。該樣式中包含了xsl：stylesheet元素，該元素是XSLT文件的根元素，它包含了XSLT名字空間、函數名字空間、變量名字空間以及版本信息。在XSLT中使用xsl：template表示模板元素，它也是XSLT中最重要的一個屬性元素，每個xsl：template有一個節點匹配屬性，由“match＝”指定。在對模板進行匹配時使用“xsl：apply－templates”選擇要匹配的模板。

4基于消息流程的ESB數據集成

4．1基于分布式ESB平臺的數據集成框架基于分布式ESB平臺的數據集成框架如圖8所示。在數據集成框架中，用戶視圖代表的是外部應用層，對于特定的數據集成場景，一般都由用戶來進行指定。流程編排的主要過程是用戶根據具體的集成場景，使用特定的描述語言來完成對信息集成的建模。流程部署主要在系統的后臺執行，主要過程是將流程中的單個服務部署到位于不同ESB節點上的執行組件中。而系統的負載均衡機制主要負責將流程中的單個服務與合適的執行組件進行綁定。結合分布式ESB平臺的集成方法，本文可以通過ESB流程建模工具對數據集成場景建模，然后將生成的流程文件部署到后臺系統執行以實現數據集成。

4．2數據集成流程數據集成流程是對數據集成場景的邏輯表示，由許多個相關的流程節點組合而成。為了更好地描述流程這個邏輯概念，以及將相關的流程節點部署到對應的執行組件上，本文引入XML描述語言以便很好地表述消息中介的邏輯符號與實際的消息中介之間的對應關系，并且能夠表示流程節點中的參數信息以及相關節點之間的鏈接關系。通過構造流程配置文件來描述相關的中介規則信息以及服務描述信息。下面給出相關概念和數據集成流程的相關定義。1）Component：表示了分布式企業服務總線平臺中的服務執行組件，也稱為消息組件。它主要負責接收請求消息，處理消息的內容，并且將處理后的消息進行轉發。系統中主要存在兩種類型的組件：適配組件（adaptor）和中介組件（mediator）。2）WebService：表示所請求的外部服務，它可以是數據源、Web服務（WebService）或者應用程序等。3）Application：表示服務的請求者，它也可以是數據源或者Web服務。4）AtomicService：表示了應用流程中的單個節點，可以將它看成是原子服務。流程中的所有節點可以分為兩類：中介規則（mediation）和端點（endpoint）。中介規則描述了消息中介的規則（例如消息驗證、消息路由以及消息轉換）。對應數據集成場景，中介規則為消息轉換。它被部署到對應的中介組件以后，中介組件才能執行具體的中介操作；端點又可分為兩類，一類描述了所請求的服務的相關信息，比如服務名稱以及服務地址等信息，另一類描述了客戶端通過怎樣的方式將請求發送給ESB，比如暴露HTTP端口等等。與中介規則類似，端點被部署到對應的適配組件以后，適配組件才能執行具體的適配操作。定義1esbprocess表示基于ESB平臺的數據集成流程，它主要由中介規則序列和服務端點集合組成，因此，它的主要屬性包括processid，inendpoints，mediations，outend－points。其中：①processid表示ESB流程的名稱，全局唯一；②inendpoints表示請求者端點集合，流程中可能存在多個服務請求者的相關信息；③mediations表示中介規則的集合；④outendpoints表示服務端點的集合，流程中有可能存在多個服務端點。定義2requesterendpoint表示請求者端點，它描述了接入到總線上的服務請求者的相關信息。它的主要屬性有：consumer，type，adaptor，description，nexthop。其中：①con－sumer表示服務請求者的名稱，它在一條流程中是唯一的；②type表示用于執行該流程節點的組件類型信息；③adaptor表示用于執行該流程節點的組件名稱以及位置信息；④de－scription表示服務請求者的描述信息；⑤nexthop表示與該流程節點有邏輯關系的下一個節點的名稱信息。定義3mediation表示中介規則，描述了中介服務信息，主要包括mediation，type，mediator，rule，inbounds，outbounds等屬性。其中：①mediation表示該中介服務的名稱，它在一條流程中也是唯一的；②type表示用于執行該流程節點的組件的類型；③mediator表示用于執行該流程節點的組件名稱以及位置信息；④rule表示具體規則的內容，包括一些參數信息；⑤inbounds表示與該流程節點邏輯相關的前一（或前幾個）流程節點的名稱；⑥outbounds表示與該流程節點有邏輯關系的下一個（或幾個）節點的名稱信息。定義4serviceendpoint表示服務端點，它描述了服務提供者的相關信息，包含的屬性有：service，type，adaptor，de－scription，replyto。其中：①service表示服務提供者的名稱，它在一條流程中是唯一的；②type表示用于執行該流程節點的組件類型信息；③adaptor表示用于執行該流程節點的組件名稱以及位置信息；④description表示服務提供者的描述信息；⑤replyto表示請求是否需要返回結果。圖9是一個基于XML的流程片段描述。

4．3數據集成的流程部署在流程部署視圖中，當一條數據集成流程被部署到分布式ESB平臺的主容器時，容器中的流程管理器會將流程分割成n個流程節點。每個流程節點中的type屬性是在流程編排時由用戶事先配置的，主容器的負載均衡模塊會首先獲取該節點的組件類型信息，之后找出合適的執行組件，并將信息添加到該流程節點中，這一過程被稱為流程的重配置過程。最后，流程管理器會根據重配置后的結果，將流程節點分配到相應ESB節點上的相應執行組件中。本文在分布式ESB系統JTangSynergy上展開研究，在目前的Synergy系統的實現機制中，處理消息流的消息處理器只有一個，它需要負責各種消息流的處理；其次，所有的消息都存放在唯一的一個消息接收通道中，消息組件在取出消息以后還需要匹配相關的配置信息，才能決定采用哪種處理方式來處理特定種類的消息。這種處理方式相對效率較低。在本文的方案中，考慮在D－ESB主節點中增加負載均衡器，其負責將中介規則以及服務端點等信息分配到合適的消息中介上。同時，通過設計消息中介的消息隊列模型，來提高中介的消息處理和傳遞效率。本文第5節將介紹負載均衡方案。

5分布式ESB數據集成中基于流程的負載均衡策略設計

5．1消息多隊列模型為了提高執行組件的消息處理性能，在實現流程部署的過程中，我們設計了如圖10所示的執行組件的多消息隊列模型。其中，每個組件內部有可能存在多個實例，而每個實例主要由3部分組成：處理器（Processor）、消息隊列（Queue）和中介單元（MediationUnit）。消息隊列是消息系統中的基本數據結構，主要用于存儲消息，隊列的創建和銷毀都是基于JMS技術，每當一個流程節點部署到某個執行組件時，組件就會初始化一個具體的處理實例，并由該實例負責對應的消息接收隊列的創建，該隊列只負責接收與部署的流程節點相關的請求消息；MediationUnit是流程中的中介（mediation）被部署到執行組件的時候創建的，它實際上是一個內存中的片段，描述了路由規則或者轉換規則等信息；Processor負責從消息通道中獲取消息，處理消息體中的內容，最后根據中介單元的信息將處理后的消息轉發給下一個目的地。該模型具有以下的一些優勢：1）與特定流程相關的消息都會被發送到指定的消息隊列中，使得各個消息流可以并行傳輸而不會相互影響，從而提高了消息傳遞的可靠性；2）組件中的每個實例都會從自己的消息隊列中獲取和處理同一類型的請求消息，從而提高了消息中介處理和傳遞消息的能力。

5．2服務執行組件的負載評價傳統的負載均衡策略多數是基于網絡的負載平衡和基于操作系統的負載平衡，這些策略的算法和實現都比較復雜，動態參數很多而且難以控制。例如：基于操作系統的負載均衡策略常常通過計算系統資源來評價服務器的負載，比如CPU利用率、內存使用率等等。中間件技術提供的異構環境下的通信和互操作功能，為解決分布式企業服務總線平臺的負載均衡問題提供了有效的工具。分布式企業服務總線平臺中負載調度的對象是執行組件，因此，本文提出將組件的消息隊列數以及各個消息隊列中的剩余消息總數作為組件負載評價的標準。結合之前提出的組件的多隊列模型，對于分布式ESB系統中的任意一個執行組件，通過一個五元組來定義它的負載度量模型：

5．3基于流程的負載均衡策略首先定義以下幾個數據結構：1）組件負載信息表（ComponentId，Load等）；2）定時器H；3）組件列表list｛｝，初始為空，記錄屬于同一服務類型的組件ComponentId。基于流程的動態負載均衡策略主要由以下3個階段組成：主節點負載信息的維護、基于負載統計的信息更新以及基于反饋的流程節點分配。具體步驟如下：1）負載信息維護①ESB主節點成功啟動后，主容器初始化組件負載信息表（ComponentId，Load等）；②當任意一個ESB節點中有新的執行組件需要動態加載時，該節點的容器會將該組件的ContainerId、Component－Id、ComponentType以及State等信息以事件消息的方式通過消息通道發送給主節點容器，此時，組件的Qnum以及Load的初始值都為0；③主容器接收該組件初始化的事件消息，并將消息中的內容寫入負載信息表中；④當某個ESB節點需要動態卸載某個執行組件時，節點的本地容器會將ContainerId信息以及組件的ComponentId信息通過消息通道發送給主節點，主節點根據收到的信息將負載信息表中對應的組件刪除。2）負載信息更新①主容器的資源監控模塊使用定時器H，當更新時刻到時，向各ESB節點中的組件發起當前負載查詢請求；②組件接收到查詢請求，將當前的實時負載信息通過本地容器以事件消息的方式發送給主容器；③主容器接收各節點反饋的負載信息，其中包括組件的Qnum和Load這兩個參數的值，并將它們更新到負載信息表；④主容器會根據組件類型（Type）創建多個組件列表list，并將負載信息表中屬于同一類型的組件加入到相同的list中。3）流程節點分配①解析流程：流程第一次部署到主容器時，主容器會首先解析流程配置文件，將中介規則和服務端點分割成n份，并且獲取中介規則和服務端點中的組件類型信息type；②定位組件：根據上一步獲取的type值，負載均衡器會根據5．2節中的評價策略在對應組件列表中查找其中負載最輕的組件；③重組流程：根據上一步得到的組件，負載均衡器會獲取組件的ContainerId和ComponentId值，并以“ContainerId∪ComponentId”表示該流程節點的執行組件名稱，該信息會被添加到流程節點中的“adaptor”屬性或者“mediator”屬性中；④分配流程節點：流程管理器獲取重組后的流程文件并再次解析，對于其中每個節點，獲取“adaptor”屬性或者“me－diator”屬性的值，之后，主容器根據ContainerId信息將該流程節點的完整內容發送給對應的ESB節點，并且由ESB節點根據ComponentId信息將流程節點最終交給本地的執行組件。

6仿真實驗

基于以上的研究，本文在分布式ESB系統JTangSynergy上采用本文的數據集成模型和負載均衡方法，對醫療系統進行數據集成。JTangSynergy主要采用了Master／Slave的容器集群架構，主節點實現了分布式環境管理以及資源監控和負載均衡，從節點完成外部應用及異構數據源的接入。此外，用戶可以通過系統提供的圖形化流程開發工具完成應用場景的流程建模，并且通過監控管理平臺Console實現對系統的資源管理和消息流監控。下面以模擬醫院內部各個信息系統之間的數據集成為例對基于分布式ESB平臺的應用步驟進行說明。（1）服務封裝。在基于ESB應用的角色分配中，服務一般是由第三方負責提供，而ESB平臺主要完成服務集成的工作。但是，用于應用集成的服務也可由ESB系統的提供商負責統一封裝。在這個仿真實驗中，所涉及到的服務都是針對數據庫訪問操作，目的是實現對數據庫數據集成操作的復用。針對這個應用案例，共封裝了（2）啟動系統各個節點，安裝組件。分別在需要進行集成的HIS系統、NIS系統、EMR系統以及LIS系統所在的服務器上部署一個ESB的從節點，并在數據中心的服務器上也部署一個ESB的從節點，另外，還需要一個高性能的服務器來部署ESB的主節點。這樣一來，就確定了一個ESB主節點和5個標準節點的集成環境。此外，還需要在各個ESB節點上安裝由系統提供的執行組件。圖11和圖12是通過監控管理平臺的界面顯示的ESB各個節點（客戶端）以及執行組件的信息。（3）數據集成流程的建模和部署。針對當前的應用案例，共設計了4條數據集成的應用流程，分別是病人信息同步流程、醫囑信息同步流程、收費信息同步流程以及病人信息匯總流程，在這些流程中應用了廣播路由、聚合路由以及消息轉換等服務。圖13所示的是對病人信息同步流程的建模界面。在圖13所示的病人信息HIS系統原始數據源采用MySql數據庫，NIS系統的數據源采用SqlServer數據庫，以符合數據源異構性的特征。在Mysql數據庫中創建一張存儲病人信息的表Patient，表結構如表3所列；在SqlServer數據庫中創建一張以HL7標準格式存儲病人信息的表Patient＿HL7，表結構如表4所列。該場景下需要完成的轉換操作主要有ID－PID、Sex－Gen－der、Birthday－Age這3組對象名稱的轉換以及Birthday－Age的值轉換操作，通過流程定義器的配置界面定義生成轉換規則集（命名規則和計算日期的運算函數規則），將上述規則作為參數進行輸入，并根據定義的轉換算法生成針對該具體實例的轉換節點，從而實現了數據集成中的數據兼容問題。流程設計器中創建抽取原始數據源以及寫入目的數據源的節點，這兩個節點是通過適配器組件經過配置后生成。將生成的流程導出成為配置文件包，并將它部署到已運行的ESB環境中，至此，實現了對病人信息轉換和信息同步的流程。（4）系統運行及消息流監控。對于每條應用流程，可以通過監控平臺來查看實時的消息流狀況。圖14顯示了病人信息匯總流程的實時消息運行狀況，對于流程中的每個節點，監控管理平臺中都會顯示該節點的消息發送和接收數據量。在該醫療信息集成測試用例下，需要同時運行的消息流程有4條。為了獲取系統目前的消息吞吐量的變化情況，選擇進行寬泛的測試方案，對于每條消息流程，保持每秒鐘發送330條消息的數據量。當所有流程同時運行時，系統的總體消息傳輸率會達到900條／秒左右。對于每條消息流程的運行情況，可以通過“監控”來查看實時的消息流狀況，圖14顯示了病人信息匯總流程在傳輸了130萬條消息時的運行狀況，對于流程中的每一個節點，監控管理平臺都會顯示出該節點的消息發送和接收數據量，可以看到圖中的病人消息聚合路由的消息接收數是前面3個節點的消息發送數之和，而發送出去的消息數是已經處理完的消息。圖15顯示了ESB主節點的實時負載監控情況，從中反映出了節點所在服務器的CPU使用率、內存使用率以及JVM的使用率等信息。從圖上結果可以看到，基于本文的數據集成方法以及負載均衡策略實現的分布式企業服務總線平臺可以有效解決異構分布式環境下的數據集成問題，并且可以充分利用各個ESB節點的系統資源，完成百萬級數據量下的消息流調度，能夠較好地滿足實際應用集成的需求。（本文來自于《計算機科學》雜志。《計算機科學》雜志簡介詳見）

7結束語

本文在基于分布式企業服務總線的系統框架之上，為了解決系統在面向大規模數據集成時碰到的數據源異構性問題，定義了一種基于WSDL和XML的數據集成模型；此外，為了解決系統的數據傳輸效率問題，提出了一種基于流程的負載均衡算法，以實現對分布式ESB各個節點中消息資源的有效分配，從而提高應用集成時的運行效率。下一步工作將對大規模應用集成下的數據安全性以及消息傳輸的可靠性進行深入研究，通過在分布式ESB平臺內部實現有效的安全機制來提高系統的安全性。

作者：范菁熊麗榮徐聰單位：浙江工業大學計算機學院