dev2dev 首頁 > 資源中心 > 技術文章
數據和數據管理是幾乎所有企業(yè)軟件解決方案的關鍵因素。SOA也不例外。有效的數據建模和管理是成功實現SOA的基礎。要將數據提高一個層次，需要把數據轉換成信息；要將信息提高一個層次，需要把信息轉換成知識。 本文是關于“SOA中的數據：將數據轉換成知識”的兩篇系列文章的第一篇。本文通過SOA參考架構（SOA RA）的定義介紹了在SOA中從數據到信息的轉換方法，它構成了完整SOA轉換方案的一部分，并且還講述了一個企業(yè)SOA的實現。這個系列的第二部分描述了在SOA中從信息到知識的轉換方法，這是對完整SOA轉換方案的一個擴展，并且還描述了一個企業(yè)SOA RA的很有價值的擴充。 為什么使用數據？數據是普遍存在的（data是復數；datum是單數，盡管“data”能夠同時使用單數和復數）。大部分 IT工作的核心就是收集、分發(fā)和管理數據，并且當需要數據的時候、在需要數據的地方、以要求的方式為需要數據的人（擁有正確的權限）提供數據。有些人可能會想起在IT（“信息技術”）這一術語出現之前，多數的企業(yè)把他們的“計算機部門”及其工作稱為DP或“數據處理”。 在過去、現在和可預見的將來，數據是所有技術浪潮中一個不變的常量。同樣的數據，過去由（很可能仍然是）大型機處理，現在也很可能已經由一個或多個的客戶機-服務器、CORBA/DCOM、 Java EE、.NET、 Web services、SOA和Web 2.0來完成。隨著時間的流逝，數據的存儲、格式和傳輸可能已經改變，數據的處理方式可能已經改變，但是“數據”依然保留（而且還在增加）。其實，所有工業(yè)技術浪潮有著一個相同點：它們都是新的或者改良的數據處理方法。數據就是基礎。如果您您也認為數據是企業(yè)解決方案的基礎，則由此得出結論：數據（以及數據建模/管理）也是SOA（與Web 2.0）的企業(yè)架構需要優(yōu)先考慮的事情。 數據是什么？讓我們先看一下字典中“數據”的定義，然后對其進行補充。就本文而言，數據是基本的、最小的，或者擁有一些結構、關系和狀態(tài)的“信息”片斷的底層集合，但不包括行為。例如，一個包含街道地址、城市等數據列的地址表是數據。就像一個用戶表中的地址定義。數據是結構和狀態(tài)，但沒有行為。數據是構成信息的原始的構建材料。數據是信息的前提。 信息是什么？讓我們再看一下信息的定義，然后對其進行補充。就本文而言，信息是數據的集合，是提供附加的形式、基本關系、語法和語義上下文的基本邏輯——也就是說，它是狀態(tài)和核心模型行為。例如，確保ZIP碼有效并與城市一致。信息是數據的擴展，它向和域（語法和語義）上下文一致的行為模型提供映射或關聯(lián)數據、定義邏輯的能力。信息基于數據，需要數據。換句話說，信息表示封裝了狀態(tài)（數據）和行為（邏輯）的實體（主體，對象）。可以認為信息類似于面向對象編程中的模型類的實例，這個實例包含用于保持狀態(tài)的數據成員（實例變量）和提供（模型）行為的方法。 SOA中數據的價值各種組織對于定義和細化自身SOA參考架構（SOA RA）有著不同的動機、出發(fā)點和優(yōu)先次序，向SOA轉換時可能會發(fā)生變化。規(guī)劃設計SOA RA的完整方法應該包括數據服務（data services）層。本文采用數據服務層這一術語包含數據和信息訪問服務。 如果在SOA RA中沒有企業(yè)數據服務層，則其后的業(yè)務項目將被迫開發(fā)成特定于每一個應用程序的專用“點”或者一次性解決方案。幾乎沒有通用性，幾乎沒有共享的服務定義、重用和一致性，規(guī)范的數據模型的定義也會變得難懂。如果認識到SOA的優(yōu)點，則會逐漸認識到它的眾多優(yōu)勢。我們很可能都看到過這樣的統(tǒng)計信息：企業(yè)應用程序軟件開發(fā)的５０％到８０％的項目資源消耗在數據集成任務上。這一“事實”應該足以確定在任何SOA實現中數據服務層是必不可少的一部分。企業(yè)軟件解決方案的主要設計目標是數據處理，結合這一概念， SOA 中數據的價值應該非常明顯。 圖１展示了BEA的SOA參考架構較高層次上的概念，它說明了位于上面的幾個層。注意，數據服務層位于第一個區(qū)域，這表明它在SOA RA中的重要性。 圖1：SOA參考架構的層次 數據、數據模型和數據管理是SOA成功的基礎。實際上，BEA對數據服務如此高度地重視，以至于我們不僅提供 AquaLogic Data Services Platform 產品，還把數據服務當作許多 BEA Consulting 服務產品的基礎，其中包括一個Data Services Consulting Service，該服務著重于SOA數據和信息層的規(guī)劃、設計和開發(fā)。 關于數據訪問和連通性服務的注釋訪問數據資源的數據訪問服務通常被總稱為企業(yè)信息系統(tǒng)（EIS），也叫數據庫和文件系統(tǒng)。它們可以是遺留系統(tǒng)、記錄系統(tǒng)，包裝好的商業(yè)應用程序、用戶、伙伴、第三方應用程序和服務，以及Web services。它們的共同之處是向其他應用程序提供數據和/或信息（在本文中的意思是行為）。因此，這些應用程序在通過數據訪問層被訪問時就是數據的另一種形式或另一個數據源。在一個更高的抽象層上，數據服務與消費應用程序看上去一樣，這是SOA RA的數據服務層的主要目標（標準化/一致性）之一。公開的接口與一個或多個數據庫、表、后臺、遺留系統(tǒng)、快速收縮的系統(tǒng)和/或外部系統(tǒng)交互，這是數據服務層封裝的一個實現細節(jié)。 連通性服務以基于標準的方式將應用程序和數據庫公開為應用程序服務。 將數據轉換成信息假設您的組織正計劃向 SOA轉換。 SOA RA的所有層和所有方面（見圖1）的研究和規(guī)劃已經開始，您的任務是數據服務層的實現。現在該怎么辦？想想下面的幾個步驟：
圖2是SOA RA數據服務的一組可能的內部抽象層示例，這里將采用我們的9個步驟來映射這些需求和性能。 圖2：數據服務層——內部層抽象 基于現在和將來的需要，您可以為一組不同的抽象層定義需求。至少，您應該分離物理層和邏輯層，并相應地分配規(guī)則類型。 現在，讓我們更具體地看一下每一個步驟。 1）盤點現有的數據和系統(tǒng)訪問資源 第一步是確定數據內容，即您您當前的數據和信息系統(tǒng)訪問資源。您您的組織擁有哪些數據和信息資源（本文后面，簡稱為“資源”）？例如，數據庫、信息資源和應用程序（指遺留系統(tǒng)、記錄系統(tǒng)）。對于每一個資源，您需要了解支撐元數據，如文檔、歷史、技術／工具／產品／平臺、版本、所有權／管理部門、位置、安全性和訪問機制。根據資源及其元數據的數量，您可能想考慮某些元數據目錄或者儲存庫，也可能是一個或一組標準模板，能夠以一致的方式獲取元信息并允許進行檢索。 ２）確定依賴關系矩陣 一旦您已經開始創(chuàng)建資源目錄，第二步就是確定依賴關系矩陣。依賴關系矩陣也是資源元信息的一部分，它獲取關于資源的使用者、使用時間、使用頻率、使用目的（例如，CRUD）和使用地點（即，訪問類型——成批的、在線的、實時的或報告式的）的信息。了解用戶為何使用某個特殊的資源也是很重要的，這將有助于任務優(yōu)化，而且為新的數據模型提出要求。 一旦您得到了使用某個資源的每個已知用戶的情況——“使用者、使用內容、使用地點、使用時間、如何使用以及為什么使用”，您就可以開始分析和形成所有資源用戶的概括。這樣做的目的是要找到在現有資源向SOA構建塊轉換的過程中進行簡化和重用的可能。它們包括，但不限于，那些面向服務的、自描述的和可發(fā)現的資源，這些資源能夠便捷地應用于采用開放的、公共的、行業(yè)和／或企業(yè)標準的SOA生態(tài)系統(tǒng)。 在這組SOA構建塊中包含的一個定義是您的服務定義。要使用什么樣的標準、規(guī)格和版本呢？例如，可能會要求 WSDL、SOAP、UDDI、WS-Security、WS-I Basic Profile、WS-Addressing、XML和XSD之中的某一個的特定版本，而其它的則可以是可選項／推薦項。數據和信息訪問資源很可能會采用與基本SOA構建塊定義（即服務）一致的格式。（使用您喜歡的搜索引擎搜索“Service Identification”和“Service Definition”這兩個主題可以找到這方面的內容。） 建立基線度量／SLA 由于每個編目好的資源已經以某種方式存在，所以應該具有預測的或者實際的產品使用統(tǒng)計信息，包括事務規(guī)模、模式、并發(fā)用戶、可靠性、可用性、可伸縮性和性能（RASP）等方面的信息。 使用信息也很好地表明了業(yè)務和IT的價值和優(yōu)先權。這個基線信息用來定義一組度量，這組度量將構成服務級別協(xié)議（SLA）并允許目標定義和歷史跟蹤。為了支持 SOA的數據服務層，要規(guī)劃軟硬件的大小和容量，在這一過程中，度量和當前產品信息的價值是無法估量的。確定您的SLA是雙向的，即服務提供者針對每個用戶定義SLA術語、條件和處罰；用戶應該遵守這個協(xié)議。 例如，一個協(xié)議聲明用戶A每天（這里指一天24小時，從午夜GMT12:00開始計算）可以在DataServiceXYZ（資源/服務的提供者）上執(zhí)行最多100個get()請求，而每個請求的響應時間將≤2秒。如果用戶A發(fā)出了超過協(xié)議規(guī)定的最大數量的get()請求，那么服務提供者能夠根據協(xié)議規(guī)定對其處罰。對服務提供者也有相應的要求。如果用戶A的請求數量不大于規(guī)定的最大值，則服務提供者必須提供≤2秒的響應時間，否則就要面對協(xié)議規(guī)定的相應的處罰。 度量和SLA定義約定的要求和規(guī)則，這些要求和規(guī)則影響每個資源的價值、目標和規(guī)模的基礎。跟蹤并重用您的基線度量、SLA，建立一個成本和效益模型。 有了上述的一定程度的一組已獲取信息，應該可以在所有其它的編目好的資源上下文中開始評價每個資源——即，指定每個資源的優(yōu)先權。一個好的策略是擁有最少3個、最多10個優(yōu)先權級別（過多了）；小于3個不夠，多于10個難于管理。 優(yōu)先權分配的目的是幫助識別在應用上最重要的資源和所支持的業(yè)務功能的價值。您應該設計一組度量（包括第三步中的那些）和定義來根據經驗比較和評價每個資源，以確定其優(yōu)先級。分配資源優(yōu)先級將有助于確定項目的合理起點、潛在的∵業(yè)務/IT贊助和相關的業(yè)務價值。 當這些資源向SOA構建塊轉換時，使用上述的所有信息能夠建立、記錄和跟蹤每個資源的“當前使用”快照。對于剩下的幾個步驟，應該在所有編目好的資源中選擇那些被指定為最高優(yōu)先級的資源。實際數量的選擇要根據您的風險評估、優(yōu)先權評價、業(yè)務/IT目標、資源以及其它類似的因素來進行。 5）數據建模 從第一個選定的資源開始（我建議您首先端到端地制作一個資源，也許不是最高優(yōu)先級的那個，這允許您使用控制度更高并且便于管理的方式實現數據管理和數據服務層的SDLC過程），對現有的物理方面進行檢查。對于數據庫或者一組表，考慮來自用戶的各種查詢、數據庫的邏輯存儲過程及其觸發(fā)器、各種具有副作用的操作。這構成了物理數據資源定義和描述。對于信息訪問，要使用什么呢？MOM、第三方適配器、專有的集成或者點對點的定制集成？這構成了物理信息資源定義和描述。 由于數據服務層是完整的SOA參考架構的一部分，所以應該規(guī)定SOA構建塊的定義和要求。您的資源的當前狀態(tài)與SOA RA構建塊的目標狀態(tài)之間很可能存在差距。業(yè)務的第一步是引導當前的物理狀態(tài)盡可能地接近您的SOA構建塊目標狀態(tài)標準。您可能會想起前面討論的關于SOA參考架構中“服務”的定義和描述。為簡單起見，假設您的服務定義要求包含WSDL、SOAP和用XSD定義的文檔樣式。其它推薦的規(guī)范包括 WS-Addressing和XQuery/XPath。有了這個定義，我們需要考慮怎樣把關系數據庫、XML數據和／或信息訪問系統(tǒng)中的表轉換或者映射到一組滿足構建塊服務定義準則的服務上。 有許多不同的工具和技術可以映射現有的數據和信息訪問資源到圖２所示的物理數據層，定義與您的特殊要求和服務定義一致的邏輯服務模型。BEA的 AquaLogic Data Services Platform（ALDSP）是我們的從數據／信息訪問資源向SOA構建塊（數據服務）轉換的實現技術，它為您的SOA參考架構提供了基于標準的、面向服務的數據服務層。 一旦您導入了您的物理資源（不考慮它們的接口和實現），您就有了物理的數據服務層（參見圖2）。物理的數據服務層中的服務有著一致的外觀和表示——即底層的實現細節(jié)和通信協(xié)議被抽象化和封裝，并且從視圖中移除（必要時，您仍然可以訪問底層），只提供了資源定義（服務定義）和操作的信息。 既然您有了自己的“數據”，下面該定義您的邏輯模型。 6）邏輯建模 邏輯建模的目標是抽象、集成、規(guī)范和管理一個或多個物理數據服務的集合，可以將這些操作抽象到兩個層上：邏輯數據標準化層和邏輯數據集成層，如圖2所示，它們也有一組可用的規(guī)則：管理規(guī)則、數據規(guī)則、集成規(guī)則和業(yè)務規(guī)則。 在進一步討論之前，需要注意： ALDSP允許支持您的邏輯抽象設計要求所需的任何邏輯層。這些邏輯層只是面向設計時的，其作用是允許設計和開發(fā)人員有效地分離和分層邏輯模型和內容。這些邏輯層不是運行時部署的一部分——也就是說，即使設計時可以有若干邏輯層，但它們并沒有對應于運行時的一組間接層。通過平展和優(yōu)化，它們成為一個運行時層。開發(fā)和操作人員能夠察看這些運行時工件和優(yōu)化，并且在認為必要時進行調整。 您可以規(guī)定一組不同的準則和因素作為邏輯模型層的基礎，而不是我在這里所使用的。例如，可以有單獨一個層來包含所有的邏輯抽象，也可以有若干個邏輯層。經證明，邏輯層太少可能有限制作用并可能隨時間增加了復雜性。至少，您應該規(guī)定一組準則來確定邏輯抽象層和它們所包含的內容。 例如，您可以有一個邏輯抽象來執(zhí)行標準化，如圖2所示。邏輯數據標準化層允許您“清除”和簡化任何復雜的或混亂的信息。改變那些您不直接擁有或負責的現有數據庫或者其他系統(tǒng)的物理結構通常也是困難的，或者任何程度的改變都是不可行的。邏輯數據標準化層讓您可以重新構建而不必強制改變物理數據層。（如果您需要關于“數據標準化”的更多信息，我建議您用“數據標準化”進行Web搜索，會了解到更多的相關內容和要求。）這個邏輯層提供一個模型設計，當更新或退出直接使用這些數據資源的系統(tǒng)時，它可以用作未來物理數據和信息的模型。邏輯數據服務的目標是提供一個高級共享服務和消費應用程序更加易于使用的、更加易懂的和更加可重用的服務模型。 第五步和第六步可以顛倒次序。關鍵是確保邏輯模型不受當前物理資源的過度約束。換句話說，在邏輯模型將要利用物理數據服務的時候，不要讓當前那些物理資源的局限性限制它們，或者對您的整個數據服務層設計施加過度的影響。物理資源是起點，接著是建立更豐富的更多表示形式的模型。 7）信息規(guī)則 規(guī)則和規(guī)則的處理決定了數據是怎樣變成信息的。它們在數據服務層提供了關系、語義和行為。如圖2所示，規(guī)則分為幾類：
8）應用程序專門化 一旦完成了邏輯模型，您就有效地定義了一個規(guī)范的信息模型。這個模型的定義將完成您的信息模型的初始設計，就意味著您已經有效地開始將數據變成信息。還有最后一步，就是進一步改進您的信息模型：應用程序規(guī)范。 不是所有的消費應用程序將會直接使用規(guī)范的信息模型。應用程序規(guī)范為消費應用程序提供一個抽象層來定義它們自己的特定于其自身需求的邏輯模型。 應用程序規(guī)范封裝了消費應用程序需要的額外的信息模型狀態(tài)和行為，簡化了消費應用程序對規(guī)范的信息模型資源的使用。由于每個消費應用程序或者一組關聯(lián)的業(yè)務應用程序的應用程序規(guī)范都是惟一的，所以不需要在規(guī)范的信息模型中包括它們。如果應用程序規(guī)范包含更大范圍（例如，跨部門或者跨企業(yè)），那么它應該成為規(guī)范的信息模型的一部分。 結束語 為SOA參考架構創(chuàng)建數據服務層和為組織定義規(guī)范的信息模型是困難的，這些任務實現起來都非常困難，而具有挑戰(zhàn)性的任務又很少能贏得什么榮譽：實現起來非常困難，很少能夠做到最好。本文所述的方法應該能給您足夠的信息去規(guī)劃、評估和開始設計數據層的SOA轉換，并將組織的數據變成信息。在實際當中，SOA參考架構的數據服務層的規(guī)劃、設計和開發(fā)依賴于許多特殊的因素，這些因素特定于您的組織或狀況，它們已經超出了本文所討論的范圍。 既然我們已經開始在SOA系統(tǒng)中把我們的數據變成信息，那么我們可以考慮把這些信息變成知識。本系列的第二篇也是最后一篇文章“SOA中的數據，第二部分：將信息轉換成知識”將介紹這一過程。 參考資料
|
|||||||
|
|
來自： jianjun0921 > 《SOA》
