數(shù)據(jù)集成：讓SOA實現(xiàn)穩(wěn)著陸

申請免費試用、咨詢電話：400-8352-114

企業(yè)中高度分散的數(shù)據(jù)接口和數(shù)據(jù)模型早就該進行有效的集成了。在實施SOA的過程中，這是無法跨越的必要環(huán)節(jié)。為了享受SOA的諸多效益，企業(yè)數(shù)據(jù)需要時刻準備著！

Carlson Hotels Worldwide公司的IT經理John Kolodziejczyk指出：“首先需要解決的問題是：”我們將使用什么樣的數(shù)據(jù)庫作為客戶的信息來源？‘“為此，這家餐飲企業(yè)為其所有的應用設計了一種通用數(shù)據(jù)架構和一個管理該架構的平臺。同樣，軸承制造商GGB公司的IT經理Matthias Kenngott認為，GGB需要一個中央集線器確保Oracle電子商務套件與3個老的erp系統(tǒng)之間一致的數(shù)據(jù)映射。

如今，大量的企業(yè)數(shù)據(jù)要么深鎖在數(shù)據(jù)庫中，要么就被封閉在應用中。通常情況下，應用“知道”數(shù)據(jù)的含意和處理結果的含意，因此企業(yè)至少要在本地創(chuàng)建一個一致性的數(shù)據(jù)模型。然而，隨著企業(yè)跨應用組合不同的功能，這些數(shù)據(jù)模型也被混合在一起，而且常常是在IT開發(fā)人員不知道的情況下被混合的。

Starwood Hotels的技術經理Song Park說：“你分發(fā)越多的數(shù)據(jù)，就越可能出現(xiàn)問題?！比藗兺鶗岩煞蘸蛻卯a生結果的準確性。ZapThink高級分析師Ron Schmelzer指出：“對數(shù)據(jù)而言，始終存在一種上下文關系。甚至當一個字段為空白時，不同應用會對它的含意做出不同的假設?！?/P>

而這些問題數(shù)據(jù)會讓集成的應用集合或大量的服務變得不可靠和難于修復。而解決的辦法就是以服務的形式提供多種應用需要的數(shù)據(jù)，即在需要的地方加入上下文元數(shù)據(jù)，以及調和分散的數(shù)據(jù)源之間存在的不一致關系。

SOA的訓誡

SOA的雙重優(yōu)勢是開發(fā)執(zhí)行常用功能的服務以減少多余的開發(fā)工作，以及通過利用標準化接口或外殼使應用功能可以跨系統(tǒng)使用，從而增加應用的靈活性。而SOA松耦合的、抽象的本質對于服務使用、處理和生成的數(shù)據(jù)具有深遠意義。

Song Park在Starwood Hotels開始部署SOA時曾發(fā)問：“到底是把它分散開還是提供一種中央服務？”這個問題引導這家公司沿著很多企業(yè)走向SOA時的必由之路走下去：即用一種基于對數(shù)據(jù)含意的了解（無論數(shù)據(jù)來自何方）來處理數(shù)據(jù)的服務方式。Schmelzer強調：“SOA凸顯了數(shù)據(jù)不一致這一事實。”

當服務交換數(shù)據(jù)時，發(fā)生誤搭配和非對應轉換的可能性大大增加。Common Sense的DePalma說：“SOA把這個問題推升到了最高層面。”他說，“當你嘗試建立第一個3路或4路數(shù)據(jù)服務，你會很快發(fā)覺數(shù)據(jù)管理之痛?！盚urwitz Group總裁Judith Hurwitz說，沒有最初的數(shù)據(jù)架構努力，SOA就無法擴展到整個企業(yè)。

專家稱，最佳的解決辦法是開發(fā)一個數(shù)據(jù)服務層，它會對將要使用的數(shù)據(jù)進行分類，將其上下文關系展示給其他服務。這種方法把數(shù)據(jù)邏輯與業(yè)務邏輯分離開來，把數(shù)據(jù)訪問和處理作為由業(yè)務流程調用的獨立服務集合對待。

新需求催生MDM

這種解決辦法不同于傳統(tǒng)的數(shù)據(jù)集成。ZapThink的Schmelzer回憶說：“我們過去一直通過在關鍵堵點上實施控制來解決數(shù)據(jù)集成問題。而SOA消除了這些堵點。這意味著每個數(shù)據(jù)訪問點都必須能轉換和管理數(shù)據(jù)?！?/P>

IDC集成系統(tǒng)集團的副總裁Henry Morris說：“數(shù)據(jù)集成和流程集成是緊密連接的?！彼ㄗh企業(yè)必須考慮利用服務來管理數(shù)據(jù)，以及影響主數(shù)據(jù)的流程。

Kanbay國際咨詢公司主設計師Nikhil Shah指出，SOA還提出了并行性問題。例如，當舊數(shù)據(jù)通過流程傳播，或者當多個服務在不同時間訪問數(shù)據(jù)時，流程過程中數(shù)據(jù)的變化就會影響到結果，尤其是在復合型應用中。Shah建議，IT要部署監(jiān)測服務，至少部署在發(fā)生變更時通知其他服務的服務，以使它們可以決定是重新啟動流程，還是調整對它們的計算。

此外，Shah說，數(shù)據(jù)服務的顆粒度越細，編排（orchestration）的開銷對流程的影響就越大，因為它會增加響應時間，導致同步問題。他建議IT在服務能夠消費數(shù)據(jù)前，就建立數(shù)據(jù)管理需求模型。

為SOA環(huán)境中的數(shù)據(jù)管理提供緩存技術的Progress 軟件公司數(shù)據(jù)管理副總裁Ken Rugg說，另一個問題是SOA的“雪犁效應”，這種效應發(fā)生在服務把有關數(shù)據(jù)處理的上下文關系傳遞給復合應用中后續(xù)服務的時候。

IDC的Morris說，公布這些轉換可以幫助以后的服務了解它們正在使用數(shù)據(jù)的上下文關系。不過，這也可能使系統(tǒng)被非常龐大的數(shù)據(jù)文件所淹沒，降低每個服務的速度。

SOA的興起使廠商有理由重新利用他們的工具為SOA和非SOA環(huán)境簡化數(shù)據(jù)管理。很多廠商正在推廣MDM（主數(shù)據(jù)管理）工具，來確保應用或服務在正確的上下文關系中使用正確的、當前的數(shù)據(jù)。“主數(shù)據(jù)”不僅包含數(shù)據(jù)本身，而且還包含了供不同系統(tǒng)使用所需要的屬性、語義及上下文關系（即元數(shù)據(jù)）。一些廠商把這類系統(tǒng)稱為企業(yè)信息集成（EII）工具。

下一步是數(shù)據(jù)集線器

AMR Research公司研究主管Bill Swanton指出，MDM雖然不是新概念，但它基本上屬于事后數(shù)據(jù)系統(tǒng)，例如數(shù)據(jù)倉庫和業(yè)務智能。在SOA出現(xiàn)前，企業(yè)基本不用擔心主數(shù)據(jù)問題，因為大多數(shù)信息保存在應用套件中，而在應用套件中，廠商至少部署了隱含的、內部的數(shù)據(jù)架構。所以，IT可以只關注在應用套件之間傳送的或原始的數(shù)據(jù)，通過連接器的建立使應用能夠處理大多數(shù)的上下文關系。

SOA的多對多架構讓IT不能繼續(xù)把這個問題留給應用廠商和集成渠道。不過Swanton說，現(xiàn)在連非SOA環(huán)境也將放棄開發(fā)連接器的方法，轉而向更易于集成的數(shù)據(jù)架構遷移。

IBM、Informatica、Oracle和Siperian等公司開始從數(shù)據(jù)倉庫著手解決這一問題，它們提供一個或更多的數(shù)據(jù)集線器當作可信賴代理，服務從凈化的數(shù)據(jù)存儲或由其他應用生成有效數(shù)據(jù)的服務訪問數(shù)據(jù)集線器。數(shù)據(jù)集線器類似于傳統(tǒng)企業(yè)環(huán)境中常用的中心輻射架構。

專家警告說，目前這些技術還很不成熟，最多只能對特定的數(shù)據(jù)管理流程起作用。

很多數(shù)據(jù)集線器含有一個適用的數(shù)據(jù)主題，比如客戶或產品信息。i2公司MDM業(yè)務高級經理Satish Krishnaswamy說，MDM作為一個初始構件還是不錯的；但在以后，IT必須普及數(shù)據(jù)集線器或使用特定的數(shù)據(jù)集線器聯(lián)盟。IDC的Morris說，“我們不會總局限在一個數(shù)據(jù)集線器上，因此IT應當向一個標準、規(guī)范、分級、跨不同來源的數(shù)據(jù)視圖的方向努力。”

為使這個系統(tǒng)易于管理，IT部門通常為一個主題領域定義規(guī)則和上下文關系，然后逐步擴展到其他領域。決定是從一個特定主題系統(tǒng)，例如SCM中的產品信息入手，還是從一個一般化的系統(tǒng)入手，這取決于對具體應用套件集成工作的關注力度。如果你的關注焦點放在與ERP或SCM的互動上，那么從特定主題的數(shù)據(jù)中心入手可能是更為合理的選擇。反之，假如你的焦點放在服務與不同應用互動的SOA上，那么從一個一般的數(shù)據(jù)中心入手則更合理。

數(shù)據(jù)架構的構建

MDM工具的確能夠幫上忙，但如果企業(yè)不了解自己的數(shù)據(jù)，那么這類工具就無法發(fā)揮作用。EDS公司的Fred Cummins說，由于集中式數(shù)據(jù)存儲一般涉及事后結果，而不涉及狀態(tài)和交易，因此，MDM系統(tǒng)越來越像傳統(tǒng)的數(shù)據(jù)倉庫或主數(shù)據(jù)庫，那么無論是在傳統(tǒng)環(huán)境還是SOA環(huán)境中，它就越不可能滿足交易系統(tǒng)的需要。

Cummins說，對SOA來說，單純重新打包EAI工具的MDM工具沒什么太大幫助。這是因為SOA應當受到業(yè)務流程的驅動，而EAI一般將重點放在把應用連接在一起，而不關注每種應用基礎數(shù)據(jù)的上下文關系。

從根本上講，這是個設計問題。正確地設計架構和具體服務需要開發(fā)人員了解他們與之互動的服務，以及應用所使用和產生的所有數(shù)據(jù)，而這是個需要投入大量勞動的過程。這正是為什么IT需要方便地訪問數(shù)據(jù)服務集合或是數(shù)據(jù)映射的原因。Common Sense的 DePalma說：“到了一定階段，就必須建立信息庫。這不僅對SOA至關重要，在傳統(tǒng)環(huán)境中也是如此?！?/P>

映射建立后，IT就可以將注意力放在開發(fā)執(zhí)行它們的連接或服務上。IT必須了解哪些映射應當提供給多個服務和應用，因此要被當作獨立的流程來實現(xiàn)；還有哪些映射是特定業(yè)務邏輯所特有的，應當與這個業(yè)務邏輯封裝在一起。

而由于沒有清晰的ROI，許多企業(yè)并沒有開展數(shù)據(jù)架構的建設。不過，IT部門可以循序漸進地參與進去，圍繞用于滿足特定應用或服務需要的信息開發(fā)規(guī)則和元數(shù)據(jù)。

BEA總設計師Paul Patrick說，數(shù)據(jù)架構通常包括多個數(shù)據(jù)模型，每個模型面向特定的主題或流程類型。IT部門可以采取分段開發(fā)的方式，同時需要精確定義數(shù)據(jù)模型之間所需的映射。

IT部門還要集中精力來應付異常數(shù)據(jù)。例如，IT應當開發(fā)查找異常數(shù)據(jù)的服務，而不是去嘗試開發(fā)映射每一種可能的狀態(tài)或關系企業(yè)范圍的本體。最后，專家建議，企業(yè)應當構建分發(fā)主數(shù)據(jù)的數(shù)據(jù)服務層，盡管實現(xiàn)這一目標的基礎設施和工具目前尚不成熟。

準備行動

在企業(yè)中以服務的形式提供數(shù)據(jù)源是一項宏大的工程。對傳統(tǒng)的集成工作而言，這意味著了解每個應用中的上下文關系，以及數(shù)據(jù)在交付給其他應用時該如何轉換。對SOA來說，這需要了解數(shù)據(jù)與不同的業(yè)務流程間的多種關系和依存性。

專家認為解決這種環(huán)境的復雜性，需要在建立數(shù)據(jù)架構模型前進行IT投入，要求企業(yè)系統(tǒng)地考慮數(shù)據(jù)的依存性和上下文關系。IDC的Morris說，發(fā)現(xiàn)數(shù)據(jù)模型和建立映射的工作量占到SOA數(shù)據(jù)架構開發(fā)工作量的70%左右。GGB的Kenngott說，建模與發(fā)現(xiàn)的工作量占其ERP整合項目中數(shù)據(jù)集成工作量的30%左右。

Starwood的Park說，這是非常值得做的準備工作?！胺駝t，你會在實施項目很長時間后才發(fā)現(xiàn)有10個不需要的字段、10個需要但在設計服務時不知道的字段，以及5個與設想不一致的字段。當你擁有一個具有數(shù)百個服務的復雜系統(tǒng)時，這些接口必須被明確下來?！彼f。（網界網）