標籤: 暫無標籤

 


 

1 服務模式 -數據聯合模式

可對來自多個異類信息源的數據進行虛擬化。該模式為分散式信息創建了集成視圖,且在聯合結構化和非結構化的信息時不會造成數據冗餘。本文描述 SOA 上下文中的結構化信息(數據)聯合。此模式規範可幫助數據和應用程序架構師明智地確定數據體系結構和文檔決策指導原則。

2 服務模式 -引言

信息的不一致和分散讓很多組織十分煩惱。在很多情況下,用戶花費了大量的時間搜索並手動聚合、關聯和更正相關信息,而不能直接根據從信息獲得的要點採取行動。

這個被廣泛認識的挑戰也出現在實現面向服務的體系結構(Service-Oriented Architecture,SOA)時。通常,核心服務需要使用來自多個不同源的已聚合的高質量信息。

現有多個概念和技術專門用於滿足這種集成需求。數據聯合就是其中的一個。數據聯合的目標是有效地聯接來自多個異類源的數據,合理利用現有的數據——不會造成數據冗餘。數據聯合模式支持在集成的臨時(虛擬)視圖上進行數據操作;在此類視圖中,實際數據存儲在多個不同的源上。源數據仍然在源系統的控制之下,會根據需要進行提取,以進行聯合訪問。

本文重點強調了數據聯合方法的價值。描述了應用數據聯合的上下文後,我們將討論此模式所針對的問題及其解決方案。我們根據非功能需求對此模式的適用性特點進行了說明(請參見注意事項部分)。此模式的一些已知用法源自我們應用此模式的經驗。最後,我們將總結此模式的重點、風險以及限制。

3 服務模式 -數據聯合方法的價值主張

4 服務模式 -基礎異類系統透明性

通過使用數據聯合,使用者將看到的是單個統一介面。位置透明性意味著使用此模式的應用程序不需要注意數據存儲的位置。得益於調用透明性,它也不需要知道源資料庫所支持的語言或編程介面。例如,如果使用了 SQL,應用程序則不必知道源支持的是哪種 SQL 分支。由於具有物理數據獨立性、碎片和複製透明性,因此應用程序不需要知道數據的物理存儲方式;而源於其網路透明性,應用程序也不需要知道所使用的是什麼網路協議。

5 服務模式 -上市時間優勢

作為數據聯合伺服器使用者的應用程序可以與單個虛擬數據源通過介面進行通信。如果不使用聯合模式,應用程序必須通過不同的介面和不同的協議與多個源分別交互。研究表明,當必須集成多個源時,使用數據聯合模式可幫助大幅度減少開發時間。有關更多信息,請參見參考資料部分。

6 服務模式 -減少開發和維護成本

很多使用者可能會使用相同(或非常相似)的集成信息。可以採用這樣的方法處理此問題:每個使用者採用自己的實現來聚合來自不同源的信息。或者,可以一次性開發集成視圖,然後在單個位置對其重複利用和維護,從而實現單點更改。此方法可減少開發和維護成本。

7 服務模式 -性能優勢

與內部開發的信息聚合方法相比,特別關注高級數據處理技術的數據聯合模式實現在很多情況下都已證明具有卓越的性能特徵(有關更多信息,請參見參考資料部分)。通過利用高級查詢處理功能,聯合伺服器可以在聯合伺服器本身和各個源之間最優地分佈工作負載。它將確定工作負載的哪個部分由哪個伺服器執行最高效,以實現響應時間最優化。

8 服務模式 -可重用性優勢

將數據聯合模式應用到特定集成場景后,此特定聯合訪問的結果可作為服務向多個服務使用者提供。例如,某個集成場景可能要求從各種源檢索結構化和非結構化保險索賠數據。在此示例中,數據聯合模式可以提供集成索賠數據的解決方案,以便隨後將集成索賠數據通過門戶提供給索賠代理人。可以隨後將相同的聯合訪問作為服務提供給其他使用者,如標準索賠應用程序的自動流程或面向 Web 應用程序的客戶機等。

9 服務模式 -改善控制

控制是 SOA 生命周期的關鍵基本要素。通過執行具有可預測結果的最佳實踐,控制流程可通過使用模式得到增強。在系統的開發和創建過程中重用經過驗證的靈活模式可同時確保一致性和高質量,並同時通過使用單個源來更新更改,從而減少維護成本。

10 服務模式 -上下文

公司和組織間的合併和收購通常要求數據和應用程序架構師將異類數據源集成到數據的統一視圖中。此類集成信息的使用者是直接與資料庫交互的傳統應用程序,需要能夠訪問經過擴展的數據源集。有關如何最好地提供此統一視圖的決策通常是根據組織中的工具可用性、經驗、專業知識以及企業文化做出的。使用傳統遺留體系結構時,與集成關聯的時間、工作量以及成本可能會超過所帶來的業務好處。在基於服務的環境中實現了基於模式的信息服務方法后,可以增強系統長期的可重用性特徵。

11 服務模式 -信息服務是 SOA 的核心中樞的一部分

。這些信息服務提供了對域信息的創建、讀取、更新和刪除 (crud) 訪問。它們還可提供各種信息處理功能,如通過分析和評分演算法、數據清理規則等進行處理。對於本文,我們將重點討論可提供統一數據視圖的信息集成服務,而這通常會涉及到對各種異類後端源和服務進行集成。

應用數據聯合模式時,我們需要對兩個上下文進行區分:傳統的非 SOA 上下文(由很多以前的應用程序加以處理)和 SOA 上下文(本文的重點)。務必記住,SOA 是一種體系結構方法,可通過其得到可重用服務,能在很多情況下擴展現有非 SOA 實現的功能。

12 服務模式 -傳統上下文

在我們稱為傳統上下文的環境中,銀行的報表應用程序可能需要分析信用卡事務。考慮到此數據的量(每天數百萬事務),將所有這些信息存儲在分析數據倉庫中並不是有效的辦法。會頻繁訪問很多舊數據,將其作為特定的上下文信息,如旅行路線等。將所有信用卡事務數據——當前的和過期的、核心的和相關的——存儲在數據倉庫中會對性能造成負面影響。一種更好的解決方案是將兩種類型的數據加以分離:例如,可將常用、最近使用的信息庫事務存儲在數據倉庫中,而將舊信息存儲在磁帶上。不過,報表應用程序應該不需要知道這種可通過聯合方法提供的數據分佈。

服務模式(圖)傳統數據聯合模式

 
圖1
傳統數據聯合模式

 

在此傳統上下文中,應用程序通常使用標準關係介面和協議來與聯合伺服器(如 SQL 和 JDBS/ODBC)交互。聯合伺服器將隨後通過各種適配器或包裝連接到各種數據源,如關係資料庫、XML 文檔、已打包的應用程序和內容管理及協作系統。聯合伺服器是一個虛擬資料庫,具有關係資料庫的所有功能。請求應用程序或用戶可以在其訪問許可權內執行任何查詢請求。查詢完成後,將返回一個結果集,其中包含滿足選擇條件的所有記錄。此過程如圖 1 中所示。此圖旨在演示可以基於使用 SQL (JDBC/ODBC) 或 XQuery 的關係應用程序編程介面的傳統實現。

SOA 上下文

在 SOA 上下文中,服務 getCustomerCreditCardData 可能需要檢索有關客戶及其信用卡事務的全面信息。此信息可能並不是駐留在單個系統中。客戶信息可能存儲在客戶主數據管理系統或多個存儲庫中,而信用卡事務則可能存儲在另一個數據源中。數據聯合將對來自多個源的信息進行聯接,以便能作為服務向使用者提供。

在此 SOA 上下文中,聯合伺服器充當使用 SOA 一致介面的服務提供者和/或服務使用者。請注意,這並不排除伺服器還會提供對傳統關係介面的支持。支持的深度是一項實現決策,這超出了本文所討論的範圍。當數據聯合伺服器將集成信息作為服務提供者公開時,服務使用者可以通過服務介面(如 WSDL 和 HTTP/SOAP 或其他事前確定的綁定)來訪問此集成信息。數據聯合伺服器可以使用(為了集成)多個信息源提供的服務。

在 SOA 上下文中使用數據集成模式的基本想法是利用和重用集成信息,即,信息集成服務能以可擴展的方式供各種使用者使用。服務的建模和定義是 SOA 的關鍵方面。一個受到廣泛認可的最佳實踐是,將服務設計為能提供信息或功能的重用和/或跨企業互操作性和/或業務流程支持。很多(如果不是大多數)成功的 SOA 項目都將重點放在作為服務公開的最重要、最廣泛使用的業務功能上。由於這些服務扮演著關鍵的角色,因此經常會涉及多個後端系統。因此,從多個異類源收集信息是 SOA 依賴的一項重要需求和功能。服務並不是傳統數據訪問上下文中的查詢,而是對業務實體的請求,可以由聯合服務通過一系列查詢和其他服務加以滿足。

服務模式(圖)SOA 上下文中的數據聯合模式

 
圖 2.
SOA 上下文中的數據聯合模式

 

在 SOA 內啟用信息集成服務需要使用額外功能,以在面向服務的介面中封裝聯合訪問。這是通過 Information Service Enablement 實現的。此組件用於在面向服務的介面中提供一些聯合查詢。例如,可以使用 SQL 編寫聯合查詢,並可以指定對產品信息的訪問。通過 Information Service Enablement 組件,此聯合查詢可以作為使用特定機制(如 SCA 或 WSDL)定義的服務提供。實現對產品數據的訪問的服務可以隨後在整個企業內和企業外進行共享。

在傳統上下文中應用數據聯合模式的解決方案可以利用 SQL 的聲明性和靈活性特徵。通過使用恰當的安全憑據,使用者可以訪問源中的任何數據,而此過程可能涉及的不同 SQL 查詢的數目幾乎沒有限制。使用者在訪問的內容及結果返回的格式方面具有極大的靈活性。儘管在很多情況下,這個靈活性是一個很大的優勢,但也增加了使用者所面臨的複雜性。使用者必須了解源數據模型以及如何從這個基礎源數據模型構造結果。源數據模型越大,此任務就會變得越複雜。

SOA 方法的重點是首先將數量相對有限的最關鍵業務功能定義為服務,並在整個企業內和企業外進行共享。因此,面向服務的介面更多的是關注數量有限的需向外提供的特定信息請求。這個清楚而集中的重點可為開發人員帶來好處,因為這樣可以減少他們設計信息請求的時間。他們可以直接從數量相對有限的選項中選擇恰當的服務。


 

 

問題說明

在當今業務驅動的環境中,架構師和開發人員要實現數據聯合解決方案的情況非常普遍。他們所面臨的挑戰通常受到一系列體系結構決策的影響,而後者實際上又受到技術、業務或合同方面約束的影響。此場景中包含多個此類常見約束。首先,支持項目的信息訪問要求所必需的數據駐留在多個源中,必須對其進行集成,並作為單個結果向用戶提供。其次,無法對目標數據源進行複製來滿足訪問需求。最後,解決方案必須在現有 SOA 內集成,並仍然支持傳統的非 SOA 應用程序,如圖 3 中所示。

服務模式(圖)異類介面訪問

 
圖 3.
異類介面訪問

 解決方案目標

正如問題說明中所述,此方法的目標是避免提供異類源的集成視圖時出現數據冗餘。數據聯合伺服器——即實現數據聯合模式的組件——必須針對傳統非 SOA 上下文提供標準查詢介面。這可確保各種各樣的傳統資料庫應用程序能夠使用聯合數據。聯合伺服器還必須提供查詢優化功能,以最高效地響應請求。此上下文中數據的分發和異類性特徵決定了必須重點強調如何最好地轉換對集成視圖的訪問,以及如何分解和分佈工作負載。支持對此集成視圖的寫訪問時,聯合伺服器必須將各個源中的數據操作同步到邏輯工作單元中。這可確保滿足事務的原子性、一致性、隔離和持久性 (ACID) 標準,且保證引用完整性。

除了針對傳統上下文的這些目標外,此方法還必須適合在 SOA 中使用。這將允許企業內外的各個用戶能夠有效地重用集成視圖。SOA 中的聯合訪問的潛在使用者是需要訪問分散式信息的應用程序、門戶和業務流程中的活動。例如,製造商可能定義從異類源檢索實時庫存信息的服務。內部應用程序和外包業務合作夥伴可以訪問相同的服務,從而利用此聯合訪問的一致且最高效的實現。

 

 

 

解決方案描述

在傳統上下文和 SOA 上下文中,數據聯合伺服器提供了有效聯接和處理來自異類源的信息的解決方案。此模式實現了處理分散式數據的同步實時集成方法。數據聯合伺服器負責接收定向到各種源的集成視圖的查詢。它會使用複雜的優化演算法對其進行轉換,從而將查詢拆分為一系列子操作(稱為查詢劃分與重寫),然後對相應的源應用子操作,從每個源收集結果,組裝集成結果,並最後將集成結果返回到原始查詢。此處理序列將以同步的方式實時完成。

設計時特徵

數據聯合模式要求對集成視圖範圍內來自各個數據源的數據元素進行映射。例如,上面示例中提到的保單持有人姓名和地址等客戶信息可以存儲在一個資料庫內的單個表中,也可以存儲在另一個資料庫內的多個表中。為了構建集成視圖,需要將這些不同類型的表示形式映射到公共視圖中。映射可以由相關人員手動執行,也可以採用基於各種映射演算法(還會捕獲任何必要的轉換需求)的最新工具輔助完成。這就允許數據聯合伺服器接收對集成視圖的查詢和計算要執行的最優子操作數量和類型。

在 SOA 上下文中應用數據聯合模式時,需要在 SOA 內將一組聯合查詢作為服務啟用並註冊。例如,用於檢索保單持有人的關鍵結構化和非結構化信息(如姓名、地址、狀態、索賠文檔、維修費用預估和風險評級等)的集成視圖可以作為服務啟用,並在多個用戶間共享。設計時的映射結果通常為聯合視圖,與關係資料庫視圖類似,可以隨後在聯合伺服器上進行部署或創建。

運行時

數據聯合伺服器接收對集成視圖的請求。根據映射定義,聯合伺服器將聯合查詢拆分為多個子操作。多個因素會對此步驟造成影響:

響應聯合查詢所必需的數據駐留在何處?
為了將異類源表示形式(如不同的數據類型、規範化模型與非規範化模型)轉換為公共集成視圖,必須執行哪些操作?
聯合伺服器使用映射信息來解決這些問題。還有很多其他因素會影響聯合查詢處理,這將要求使用映射規範之外的其他信息,如:

系統管理數據源支持哪些操作,哪些操作必須由聯合伺服器提供補償機制?
在源中執行一系列操作與在聯合伺服器上執行這些操作的性能影響如何?聯合伺服器應將哪些操作委派給源,以便更好地利用源的功能、減少數據傳輸以及優化總體性能?
回答這些問題需要使用源系統及其查詢處理功能方面的知識。為了處理后一個問題,聯合伺服器還必須使用一系列關於操作環境的信息以及源數據的統計數據。

聯合伺服器確定了所有子操作的最佳執行策略后,將連接到數據源——包括結構化和非結構化信息的數據源——以檢索相關數據(可能會使用源特定的介面)。根據總體查詢執行計劃,將隨後對數據源執行各個子操作。將接收結果並聚合為集成視圖的結果。然後會將此結果返回給使用者。

在 SOA 上下文中,使用者通過預定義的請求格式向聯合伺服器提交請求。聯合伺服器將請求轉換為對應的 SQL 查詢或視圖定義,以支持服務。從此時開始,將執行與以上所述相同的查詢分解、優化和執行步驟。SOA 中唯一的區別在於最後一步。聯合伺服器會將傳統數據聯合方法的結果轉換為服務響應,並隨後通過預定義的服務介面將其返回給服務使用者。

服務模式(圖)數據聯合的序列圖

圖 4.
數據聯合的序列圖
 

數據聯合模式的功能可以通過使用數據相關的技術(如優化器或補償)或自己開發的應用程序來實現。由於異類源上的查詢優化的複雜性,行業最佳實踐是使用數據聯合實現來利用大多數資料庫管理系統提供的查詢優化技術。

13 服務模式 -注意事項

應用數據聯合模式時,務必理解其特徵以及其受以下所述的非功能要求的影響情況。一定要注意,我們列出的功能要求並不考慮緩存和數據複製模式。我們認為,當採用以基本模式(本例中為數據聯合)為基礎模式時,可以隨後通過其他模式對其進行擴展,以便滿足服務的額外非功能要求和功能要求。可以使用緩存和數據複製模式來補充數據聯合或形成組合模式。應小心使用這些模式以及可以在總體實現中使用的其他模式,因為它們可能會妨礙最初選擇數據聯合來解決的一些非功能要求的實現。例如,它們可能會增加數據延遲和導致數據冗餘。需要了解非功能要求和體系結構決策之間的得失。

非功能要求的所有特徵既適用於傳統的非 SOA 上下文,也適用於 SOA 上下文。其包括:

14 服務模式 -數據安全性

只有具有所集成源中的恰當憑據的用戶和應用程序才允許訪問集成視圖。可以對此進行進一步的限制。應用此模式的一個主要原因是要利用現有源系統的數據和功能。因此,架構師經常還希望利用現有的安全機制,如源系統的身份驗證和授權。由於此環境具有異構和分散式的特點,可能會出現數據聯合模式外的有關單點登錄和全局訪問控制的挑戰。為了應對這些挑戰,架構師將需要把數據聯合模式與其他安全相關的模式結合使用。

15 服務模式 -數據延遲

數據聯合模式允許以實時集成的方式訪問源,具有最高的數據併發級別。

16 服務模式 -源數據易變性

由於能在接收到集成視圖請求時實時地訪問源數據,因此數據聯合將始終返回最新的源信息。由於數據聯合模式並不會創建源數據的副本,因此源更改並不一定要採用這種方法進行傳播或處理。

17 服務模式 -數據一致性和質量

由於需要執行的複雜數據清理、標準化和轉換操作的頻率增加,因此對總體響應時間造成負面影響的概率也會增加。這是由於數據聯合模式中的請求對應的響應的實時同步特徵造成的。任何額外的轉換都將意味著響應集成查詢時會存在額外的工作負載。最好的做法是儘可能減少所需的欄位轉換的複雜性和數量。

18 服務模式 -數據可用性

集成數據的可用性依賴於數據聯合伺服器和集成源伺服器在請求時的可用性。如果某個伺服器或聯合與源伺服器間的任何連接失敗,集成視圖就不可用。

19 服務模式 -模型更改對集成模型的影響

數據聯合模式的一個非常重要的好處是,能夠屏蔽在源系統中實現的很多模型更改。如果能夠將更改限制在聯合伺服器中,就可以減少將這些更改向服務的發起方或使用者公開的可能性。此外,還能夠在無需將更改傳播給數據源模型的情況下在集成視圖中進行更改。

20 服務模式 -事務執行的頻率

對聯合伺服器的請求是採用同步方式執行的。只要接收到響應,請求者就可以調用後續請求了。聯合伺服器應支持由多個請求者發起的併發請求。頻繁的後續請求應該與單個請求具有相同的性能特徵。如果源——或聯合伺服器和源之間的連接器——具有特定特徵,在訪問頻繁時會導致響應性能下降,則可能會出現異常。聯合伺服器高速執行事務的能力是由聯合伺服器訪問源系統的速度以及這些源系統響應的能力決定的。

21 服務模式 -事務併發性

在很多情況下,數據聯合伺服器都具有與資料庫或內容伺服器很類似的特徵。有效管理併發訪問的能力由數據聯合伺服器和所集成的源伺服器的性能特徵決定。

22 服務模式 -性能和事務響應時間

事務響應時間由很多因素決定,包括:

聯合查詢的複雜性:為了執行查詢,聯合伺服器需要執行多少篩選、聯接、排序之類的子操作
數據聯合伺服器的查詢優化和處理功能:聯合伺服器的設計用於處理以下方面的成熟程度——接收聯合查詢,將其拆分為子操作並進行優化(例如,首先應用篩選器等一些子操作來減少數據集大小,然後執行排序等子操作)
數據量:數據量越高,每個子操作執行的時間越長,因此查詢的完成時間也就越長
網路帶寬:聯合伺服器和源之間的網路連接的吞吐量將影響聯合伺服器訪問源的速度,因此也會影響聯合查詢的總體響應時間
CPU 使用率:聯合伺服器和數據源所在的計算機上的資源使用率的差異需要影響總體聯合查詢的哪些子操作在聯合伺服器上執行、哪些在源上執行(如果可能)
源伺服器的查詢處理能力:有些源伺服器在其處理和優化影響總體性能的查詢方面具有特定的特徵和限制
聯合伺服器標識每個數據源的最後查詢策略的能力:如果聯合伺服器能了解源伺服器的查詢處理能力,則可以確定可委派何種類型的子操作以及何種子操作要在聯合伺服器層執行
數據聯合模式(從分佈源獲取數據)實現的虛擬資料庫的查詢響應時間可能比在具有相同功能的單個物理資料庫上執行相同的查詢長。響應時間的差異將根據上面列出的各個元素的不同而有所變化。因此,在單個物理資料庫中提供集成數據集的替代模式的響應時間會有所改善。數據聯合模式的有些實現可以將部分或全部子操作(子查詢)以并行方式發送到集成源系統。子操作的并行處理能夠大幅度改進響應時間。

23 服務模式 -創建、讀取、更新、刪除 (CRUD) 概要

大部分聯合實現都支持不同程度的讀寫訪問。有些實現會對寫入操作的邏輯工作單元進行協調,這被稱為兩階段提交。在大多數情況下,由於寫訪問非常複雜,因此數據聯合模式主要用於進行讀訪問。如果沒有兩階段提交支持,請求者需在更新數據時負責確保源中的一致性。由於兩階段提交通常要求使用事務管理器,寫訪問的支持程度可能會根據事務管理器實現的不同以及源伺服器在應用和提交更改方面的功能的差異而有所不同。

24 服務模式 -每個事務的數據量

響應時間受到每個事務需要從遠程源傳輸到聯合伺服器的數據量的影響:數據量越大,響應時間越長。優化聯合查詢對聯合伺服器非常重要,能儘可能減少必須在聯合伺服器和源之間傳輸的數據量,特別在聯合數據量很大時更要如此。另外,務必還要了解網路基礎設施所支持的功能和帶寬以及可能對所傳輸的數據的數量和頻率的影響。

25 服務模式 -解決方案交付時間

正如價值主張中提到的,數據聯合可以大幅度改進集成各種源時的交付時間。

26 服務模式 -技能和經驗

數據聯合模式的重點是數據源的集成和通過面向數據的介面提供單個系統映像。當將集成信息作為服務提供時,開發人員還將需要理解各個 SOA 概念、標準和技術。

27 服務模式 -可重用性

有關定義數據訪問和聚合的邏輯可以在不同的項目中加以重用。

28 服務模式 -維護多個數據源的成本

數據聯合併不會減少維護多個數據源的成本,但由於對現有數據源進行了集成和重用,可以獲得更大的好處。

29 服務模式 -開發成本

假定已經配備了聯合伺服器基礎設施,則使用最好的聯合引擎會相對較為廉價。

30 服務模式 -目標模型的類型

本文的重點是結構化數據的聯合。目前,最常見的模型是採用 SQL 標準的關係模型。XML 和 XQuery 則是兩項新興標準,正越來越多地在信息管理中採用。數據聯合模式的實現通常至少支持其中一種模型,有時候會同時支持這兩類模型。數據聯合模式的大部分實現都比較強調一個(或數量很有限的)目標模型,以最有效地處理請求。

31 服務模式 -有保證的交付和邏輯工作單元

在 IBM SOA 參考體系結構中,企業服務匯流排(Enterprise Service Bus,ESB)是基礎設施中的一個關鍵組件。ESB 的責任之一是提供有保證的交付。由於協調邏輯工作單元(如在聯合環境中通過兩階段提交協議進行協調)的複雜性,並非數據聯合模式的所有實現都支持此功能。當使用支持此功能的聯合伺服器時,需要對其資料庫鎖定策略進行仔細分析,以避免對源系統的性能造成負面影響。

32 服務模式 -資源使用率

聯合伺服器僅在處理從使用者接收到的請求時才會使用資源。聯合伺服器的資源使用率水平是由請求的複雜性決定的:請求越複雜,查找將此聯合請求分解為子操作的最優計劃的任務就越複雜。資源使用率的另一個影響因素是需要在聯合伺服器上執行的子操作(如補償源系統所缺少的功能)與可以下推到源系統的子操作的百分率比值。另外,從源系統接收到的數據量和需要通過聯合伺服器的數據量也影響資源使用率。

33 服務模式 -轉換功能

聯合模式的重點是讓數據保持在原來的位置,並提供實時的虛擬集成視圖。此模式中的解決方案對可以應用何種轉換並沒有限制。可以在很多實現中使用基本轉換來將異類源格式轉換為聯合層的公共視圖。不過,複雜轉換對聯合模式的性能有負面影響,從而會降低此模式對此類場景的適用性。因此,大部分數據聯合模式的實現對複雜

34 服務模式 -轉換功能的關注相對較少,而更強調查詢優化技術。源模型、介面、協議的類型

數據聯合處理有關集成來自異類源模型的數據的問題,包括將這些不同的源模型映射到聯合層的公共模型的概念。數據聯合模式的實現在其可以集成的具體源模型的能力方面各有不同。

源模型的範圍和大小

當在運行時期間將基礎源映射到集成視圖時,源模型的大小、屬性的數量和類型可能對映射任務造成負面影響。範圍越大(例如要訪問的屬性數量越多),標識對應元素的時間可能越長。

聯合伺服器工作負載(事務量)對源系統的影響

聯合伺服器會將其接收到的每個請求的子操作轉發到源系統。這將對源系統的資源使用率造成負面影響,因為需要對來自聯合伺服器的子操作做出響應。聯合伺服器接收到的請求越多,發送到所集成的源系統的子操作越多。


 

35 服務模式 -結束語

我們在本文中對數據聯合模式進行了說明,此模式是一種處理對集成臨時(虛擬)視圖的數據操作的方法,而此類視圖中的實際數據都存儲在多個不同源系統中。我們在本文中主要討論的是 SOA 上下文中的情況。我們最後將總結何時應用數據聯合模式及何時不應用此模式,並將列出重要的約束。

36 服務模式 -應用數據聯合模式的重點領域

上市時間是具有頂級優先順序的開發目標之一,數據聯合可快速提供對信息源的訪問,而不需要進行長時間的信息管理基礎設施變更。
數據聯合通過允許按照數據駐留在源上的方式訪問數據,從而支持與數據複製和重複相關的要求。這些要求可能是為了響應法律法規或規則對數據移動或複製的限制,如訂閱數據或來自不同國家的個人信息混合存在的情況。
像訪問單個源的數據一樣實時訪問分散式信息。信息可以為結構化和非結構化數據。
用於動態更改環境(特別是模式更改的情況)的靈活的可擴展信息集成方法:由於沒有數據冗餘,聯合模式中的更改會減少更改對所集成系統的影響。
當接收到的請求數量適中,而來自多個異類互補數據源的結果大小有限時,可最佳地利用數據聯合的優勢。
不應該應用數據聯合模式的領域

需要複雜轉換來構建集成視圖的場景將對響應時間造成負面影響,尤其是採用這種方法時。
源伺服器可能在必須返回聯合查詢中請求的數據時受到工作負載增加的負面影響。為了將請求處理到集成視圖中,聯合伺服器將向所集成的源發送子操作。這些子操作越複雜,其發送到源系統的頻率越高,源伺服器需要管理的額外工作負載也就越多。
導致大量過渡結果集從目標數據源移到聯合伺服器的情況可能帶來很大的性能影響。
應用程序要求相對較高的集成數據可用性的情況可能不適合應用這種模式。集成數據的可用性完全依賴於過程中涉及的所有聯合伺服器和源伺服器的可用性以及網路的可用性、容量和響應能力。
應用數據聯合模式時的約束

數據聯合的很多實現具有受限的數據操作功能。很多將 SQL 作為編程語言使用,且僅支持 SQL 轉換。
性能很大程度上依賴於供應商特定的實現在緩存功能、理解異類數據源和確定最佳聯合查詢和執行路徑方面所表現出來的成熟度。
不同信息源的讀寫訪問(特別在對邏輯工作單元進行協調時)將受到供應商特定的支持的約束。


 

37 服務模式 -產品映射

以下 IBM 產品實現了此模式:

IBM® WEBSPHERE® Information Integrator Standard Edition、Advanced Edition、Advanced Edition Unlimited 允許應用程序對來自分散式平台上 (LINUX / UNIX / WINDOWS) 的源的數據進行聯合。用戶可以通過 SQL 介面訪問來自各種數據源的聯合信息,如 Informix、Cloudscape、Oracle、SQL Server、Microsoft Excel、XML 文件等。此產品還可以與以下兩個產品組合使用,以聚合結構化、非結構化數據以及來自大型機平台的寶貴資產。
WebSphere Information Integrator Classic Federation 提供了一個 SQL 介面,可在大型機上的各種數據源上使用,如 DB2®、IMS、VSAM、IDMS、Adabas 等。此產品的主要功能之一是在無需編碼的情況下將大型機數據結構映射到關係模型,以便具有非常有限大型機知識的開發人員可以靈活而高效地訪問大型機數據。
WebSphere Information Services Director 可將信息管理功能作為服務提供。它可將信息集成邏輯、清理規則、信息訪問等打包為服務。這樣就使得開發人員無需費神考慮此功能的基礎提供者了。其中與本文最為相關的就是將通過面向服務的介面(如 EJB、JMS 或 Web 服務)提供聯合訪問的功能。此產品為 Information Services 提供了基本的基礎設施,包括負載平衡和容錯功能。它實現了圖 2 中所示的 Information Service Enablement 組件。
WebSphere Information Integrator Content Edition 提供了聯合內容管理系統上的統一介面。提供了各種內容源上的典型內容訪問操作,其中包括 IBM DB2™ Content Manager。


 
 

相關評論

同義詞:暫無同義詞