解析在SOA中實現語義互操作性(1)

引言

語義學 關注的是含義的研究。語義互操作性 表示數據的含義可以明確地被人類和計算機程序理解，而且可以通過有意義的方式來處理該信息。語義集成 是指實現語義互操作性的方式，它可以被認為是信息集成的子集，其中包括數據訪問、聚合、關聯和轉換等。

在面向服務的體系結構 (SOA) 中，語義互操作性可確保服務使用者和提供者可以通過一致、靈活的方式交換數據，這種方式能滿足許多非功能性的要求 (Non-Functional Requirement，NFR)，如性能和伸縮性等，而不受所涉及的各種信息的限制。例如，帳單編制應用服務請求者需要獲知客戶余額“BALANCE”。同時，會計應用服務提供者提供名為“REMAINDER”的客戶余額。實現語義互操作性的方法是，將帳單編制應用中的“BALANCE”映射到會計應用中的“REMAINDER”。

語義互操作性是 SOA 中的一個重要體系結構特性，因為它使服務的使用者和提供者能夠交換有意義的信息，然后遵照這些信息進行操作。它是 SOA 的基礎。沒有了語義，數據只是一串串沒有任何意義的二進制字節。如果沒有語義互操作性，服務使用者和提供者可能誤解和破壞數據，最終給 SOA 和業務帶來負面影響。

廣而言之，大多數信息集成都是對語義互操作性進行處理。問題在于，人們認為語義互操作性是理所當然的，并且很少在語義互操作性方面進行理性而明智的體系結構決策，因為語義解釋、映射和轉換通常與自主開發應用程序、企業應用程序集成 (Enterprise Application Integration，EAI) 和企業信息集成 (Enterprise Information Integration，EII) 聯系在一起。因此，語義互操作性通常會在 SOA 的開發過程中被忽略。

本文的目標是使應用程序架構師和數據架構師認識到語義和語義互操作性的重要性，以便在構建新的基于 SOA 的解決方案或者將現有系統遷移到 SOA 時能夠進行合理的決策。要想理解語義互操作性，我們首先必須了解其背后的各種技術和方法，這些技術和方法統稱為語義譜。此外，反模式可提醒我們避免犯錯。模式和最佳實踐則為我們指明了正確的方向。.我們將首先討論語義譜，然后討論語義互操作性的模式、反模式和最佳實踐。

語義譜

語義譜 描述了用于創建越來越精確的數據定義的一系列技術和方法。需要在精確度與模糊度之間求得平衡——并非總是精確度越高越好——還需要考慮很多因素，如時間、成本和工作量等。

為了定義數據元素，我們不僅需要考慮事物本身(數據實例)，還需要考慮事物的定義和描述(元數據)。因此，語義譜同時覆蓋了數據和元數據。它包括詞匯表、控制詞匯、數據詞典、數據模型、分類法和維基百科中的本體。例如，“數據詞典”和“數據模型”與元數據相關;而詞匯表、控制詞匯和分類法則與數據實例相關。本體描述則同時覆蓋了這兩方面。不過，有些人認為詞匯表和分類法也屬于元數據的范疇。本文將不討論數據與元數據的具體區分。

詞匯表 是帶有定義的術語列表。許多文檔和書籍都在末尾列出了詞匯表，以方便讀者閱讀相關內容?？刂圃~匯 是特定方面的組織和團體人遵守的標準化術語列表?？刂圃~匯的遵守可能是自愿的，也可能是強制性的。地區代碼列表就是控制詞匯。詞匯表和控制詞匯從開始出現書面語言就有了，通常被用作大眾傳播和語言框架的組成部分。

20 世紀實現數據數字化后，關系數據庫被用作主要的數據持久性機制。數據詞典 用于捕獲不同數據元素的含義和表示形式，并就此進行交流，最常用于關系數據庫。數據詞典是一個重要的構件，它支持業務和 IT 社區之間進行有意義的交流。

數據模型 描述數據元素的結構。從 20 世紀 70 年代開始，早在發明統一建模語言(Universal Modeling Language，UML)之前，關系數據庫社區就已經使用實體關系(Entity-Relationship，ER)圖表來改進交流和簡化開發工作。

為了應對日益復雜的異類數據庫環境，人們意識到需要創建企業數據模型(Enterprise Data Model，EDM)。流行的觀點認為 EDM 需要海量數據庫來存儲組織所處理的所有數據，但是事實上并非如此，EDM 僅僅是一個公共邏輯數據模型。它通常位于第二或第三范式。其他邏輯或物理數據模型(如 ESB、應用和數據倉庫)都可以映射到這個公共邏輯數據模型。EDM 通常用作信息集成的參考模型，或者用作持久性數據庫和數據倉庫的基礎。例如，IBM Insurance Information Warehouse (IIW) 中的企業模型就是一個 EDM 實現。EDM 允許支持數據企業視圖，用以幫助降低數據冗余、提高數據質量以及加速項目的集成和新項目的開發。它還可以簡化業務需求與數據模型之間的映射。

企業分類法 用于組織一套標準化的術語、概念、目錄和關鍵詞。它被組織成一個層次結構，以表示術語和概念的隸屬關系，通常與內容管理、知識管理和搜索技術關聯。

最后，根據 World Wide Web Consortium (W3C) 的說明，本體 定義用于描述和表示知識領域的術語。它指定有關領域的類(一般事物)的說明以及事物與屬性(或特性)之間的關系。IEEE 下屬的 Standard Upper Ontology Working Group 正在進行制定上層本體方面的工作，以支持數據互操作性、信息搜索和檢索、自動推理和自然語言處理等計算機應用。

反模式

反模式一:無控制語義混亂

由于各種原因，語義互操作性很難實現。之所以出現此情況的原因示例如下:

• 我們不能簡單地“拆除”和更換遺留資產。無論任何時候，組織在創建新的應用或者集成現有應用時，都不可避免地需要對遺留資產進行集成。許多企業的關鍵業務應用仍然運行的是 COBOL 或 CICS。通過查看 COBOL Copybook 來確定語義不是一項簡單的任務。
• 由于合并、收購、法律法規、市場競爭和客戶需求等各種原因，業務在不斷發生變化。信息和應用集成永遠不會百分之百的完整。
• 由于職務、經驗和知識基礎等方面的差異，人們不可避免地發現很難達成一致。 參與者數量越多，就越難達成一致。EDM 涉及各種業務單位和開發團隊。人們發現采用豎井 (Silo) 方式構建應用和數據比較容易，而在多個團隊參加的情況下則很難達成一致。
• 有些情況下，人們似乎表面上對某件事達成了一致，但是解釋方法卻各不相同。以采用行業標準的數據模型為例，很多模型十分模糊，而且可以套用不同的語義解釋。人們可能將它們用于不同的目的，以此來維護行業標準的作用，而實際上則是違背了標準的初衷。
• 直接來自于開發人員的普及 XML 和 XSD 沒有經過協調，因而只會導致語義混亂。

到目前為止，我們可能顯得比較悲觀，但是我們真正的主張是對語義混亂加以控制。語義混亂意味著所有人都定義自己的方案和詞匯，而不遵守任何信息標準，也不考慮與系統的其他部分之間的語義互操作性。人們使用自己的術語，相互之間難以理解。系統是在豎井中構建的。

反模式二:目標過大

無控制語義混亂的另一個反面極端是目標過大。項目涉及許多參與者，而參與者之間很難達成一致。范圍過于擴大，時間安排過長。由于計劃過于雄心勃勃，強制應用和數據庫僅遵從一個數據模型，這在過去造成了很多 EDM 失敗。

反模式三:缺乏信息集成邏輯重用

有三種主要的信息集成模式可用于實現語義互操作性:數據聯合、數據整合和企業應用集成(EAI)。

在實際中，企業內不同的部門通常擅長使用其中一種模式。例如，數據倉庫和業務智能(Business Intelligence，BI)部門通常擅于使用數據整合模式，而業務應用部門則擅長使用 EAI 模式。如果沒有跨團隊協調和企業級長期戰略，將很容易產生一個新的集成豎井集——業務應用程序組為了實現跨越異類數據源的語義互操作性而進行重復工作，而 BI 部門卻早已經解決了這個數據倉庫難題。由于采用了豎井工作方法，每個組的語義集成和數據處理邏輯可能略有不同。

反模式四:業務術語和定義混亂

通常情況下，業務用戶將請求信息技術專業人員提供數據，以幫助他們利用業務術語和定義對業務進行分析，而這些業務術語和定義在不同的部門可能差別很大。例如，一個部門定義的“客戶”可能與另一個部門的定義存在很大的差異。IT 專業人員必須將這些業務術語逐一轉換成為已知的 ER 或 UML 用語。在會計系統中，“客戶”可能被定義為組織已經向其銷售了產品的對象，而在市場營銷系統中，可能被定義為組織想要向其銷售產品的對象。這種混亂的核心在于確定使用哪一種“客戶”定義。