企業中高度分散的數據接口和數據模型早就該進行有效的集成了。在實施SOA的過程中,這是無法跨越的必要環節。為了享受SOA的諸多效益,企業數據需要時刻準備著!
Carlson Hotels Worldwide公司的IT經理John Kolodziejczyk指出:“首先需要解決的問題是:‘我們將使用什么樣的數據庫作為客戶的信息來源?’”為此,這家餐飲企業為其所有的應用設計了一種通用數據架構和一個管理該架構的平臺。同樣,軸承制造商GGB公司的IT經理Matthias Kenngott認為,GGB需要一個中央集線器確保Oracle電子商務套件與3個老的ERP系統之間一致的數據映射。
如今,大量的企業數據要么深鎖在數據庫中,要么就被封閉在應用中。通常情況下,應用“知道”數據的含意和處理結果的含意,因此企業至少要在本地創建一個一致性的數據模型。然而,隨著企業跨應用組合不同的功能,這些數據模型也被混合在一起,而且常常是在IT開發人員不知道的情況下被混合的。
Starwood Hotels的技術經理Song Park說:“你分發越多的數據,就越可能出現問題?!比藗兺鶗岩煞蘸蛻卯a生結果的準確性。ZapThink高級分析師Ron Schmelzer指出:“對數據而言,始終存在一種上下文關系。甚至當一個字段為空白時,不同應用會對它的含意做出不同的假設?!?br>
而這些問題數據會讓集成的應用集合或大量的服務變得不可靠和難于修復。而解決的辦法就是以服務的形式提供多種應用需要的數據,即在需要的地方加入上下文元數據,以及調和分散的數據源之間存在的不一致關系。
SOA的訓誡
SOA的雙重優勢是開發執行常用功能的服務以減少多余的開發工作,以及通過利用標準化接口或外殼使應用功能可以跨系統使用,從而增加應用的靈活性。而SOA松耦合的、抽象的本質對于服務使用、處理和生成的數據具有深遠意義。
Song Park在Starwood Hotels開始部署SOA時曾發問:“到底是把它分散開還是提供一種中央服務?”這個問題引導這家公司沿著很多企業走向SOA時的必由之路走下去:即用一種基于對數據含意的了解(無論數據來自何方)來處理數據的服務方式。Schmelzer強調:“SOA凸顯了數據不一致這一事實?!?br>
當服務交換數據時,發生誤搭配和非對應轉換的可能性大大增加。Common Sense的DePalma說:“SOA把這個問題推升到了最高層面?!彼f,“當你嘗試建立第一個3路或4路數據服務,你會很快發覺數據管理之痛?!盚urwitz Group總裁Judith Hurwitz說,沒有最初的數據架構努力,SOA就無法擴展到整個企業。
專家稱,最佳的解決辦法是開發一個數據服務層,它會對將要使用的數據進行分類,將其上下文關系展示給其他服務。這種方法把數據邏輯與業務邏輯分離開來,把數據訪問和處理作為由業務流程調用的獨立服務集合對待。
新需求催生MDM
這種解決辦法不同于傳統的數據集成。ZapThink的Schmelzer回憶說:“我們過去一直通過在關鍵堵點上實施控制來解決數據集成問題。而SOA消除了這些堵點。這意味著每個數據訪問點都必須能轉換和管理數據?!?br>
IDC集成系統集團的副總裁Henry Morris說:“數據集成和流程集成是緊密連接的?!彼ㄗh企業必須考慮利用服務來管理數據,以及影響主數據的流程。
Kanbay國際咨詢公司主設計師Nikhil Shah指出,SOA還提出了并行性問題。例如,當舊數據通過流程傳播,或者當多個服務在不同時間訪問數據時,流程過程中數據的變化就會影響到結果,尤其是在復合型應用中。
Shah建議,IT要部署監測服務,至少部署在發生變更時通知其他服務的服務,以使它們可以決定是重新啟動流程,還是調整對它們的計算。
此外,Shah說,數據服務的顆粒度越細,編排(orchestration)的開銷對流程的影響就越大,因為它會增加響應時間,導致同步問題。他建議IT在服務能夠消費數據前,就建立數據管理需求模型。
為SOA環境中的數據管理提供緩存技術的Progress 軟件公司數據管理副總裁Ken Rugg說,另一個問題是SOA的“雪犁效應”,這種效應發生在服務把有關數據處理的上下文關系傳遞給復合應用中后續服務的時候。
IDC的Morris說,公布這些轉換可以幫助以后的服務了解它們正在使用數據的上下文關系。不過,這也可能使系統被非常龐大的數據文件所淹沒,降低每個服務的速度。
SOA的興起使廠商有理由重新利用他們的工具為SOA和非SOA環境簡化數據管理。很多廠商正在推廣MDM(主數據管理)工具,來確保應用或服務在正確的上下文關系中使用正確的、當前的數據?!爸鲾祿辈粌H包含數據本身,而且還包含了供不同系統使用所需要的屬性、語義及上下文關系(即元數據)。一些廠商把這類系統稱為企業信息集成(EII)工具。
下一步是數據集線器
AMR Research公司研究主管Bill Swanton指出,MDM雖然不是新概念,但它基本上屬于事后數據系統,例如數據倉庫和業務智能。在SOA出現前,企業基本不用擔心主數據問題,因為大多數信息保存在應用套件中,而在應用套件中,廠商至少部署了隱含的、內部的數據架構。所以,IT可以只關注在應用套件之間傳送的或原始的數據,通過連接器的建立使應用能夠處理大多數的上下文關系。
SOA的多對多架構讓IT不能繼續把這個問題留給應用廠商和集成渠道。不過Swanton說,現在連非SOA環境也將放棄開發連接器的方法,轉而向更易于集成的數據架構遷移。
IBM、Informatica、Oracle和Siperian等公司開始從數據倉庫著手解決這一問題,它們提供一個或更多的數據集線器當作可信賴代理,服務從凈化的數據存儲或由其他應用生成有效數據的服務訪問數據集線器。數據集線器類似于傳統企業環境中常用的中心輻射架構。
專家警告說,目前這些技術還很不成熟,最多只能對特定的數據管理流程起作用。
很多數據集線器含有一個適用的數據主題,比如客戶或產品信息。i2公司MDM業務高級經理Satish Krishnaswamy說,MDM作為一個初始構件還是不錯的;但在以后,IT必須普及數據集線器或使用特定的數據集線器聯盟。IDC的Morris說,“我們不會總局限在一個數據集線器上,因此IT應當向一個標準、規范、分級、跨不同來源的數據視圖的方向努力?!?br>
為使這個系統易于管理,IT部門通常為一個主題領域定義規則和上下文關系,然后逐步擴展到其他領域。決定是從一個特定主題系統,例如SCM中的產品信息入手,還是從一個一般化的系統入手,這取決于對具體應用套件集成工作的關注力度。如果你的關注焦點放在與ERP或SCM的互動上,那么從特定主題的數據中心入手可能是更為合理的選擇。反之,假如你的焦點放在服務與不同應用互動的SOA上,那么從一個一般的數據中心入手則更合理。
數據架構的構建
MDM工具的確能夠幫上忙,但如果企業不了解自己的數據,那么這類工具就無法發揮作用。EDS公司的Fred Cummins說,由于集中式數據存儲一般涉及事后結果,而不涉及狀態和交易,因此,MDM系統越來越像傳統的數據倉庫或主數據庫,那么無論是在傳統環境還是SOA環境中,它就越不可能滿足交易系統的需要。
Cummins說,對SOA來說,單純重新打包EAI工具的MDM工具沒什么太大幫助。這是因為SOA應當受到業務流程的驅動,而EAI一般將重點放在把應用連接在一起,而不關注每種應用基礎數據的上下文關系。
從根本上講,這是個設計問題。正確地設計架構和具體服務需要開發人員了解他們與之互動的服務,以及應用所使用和產生的所有數據,而這是個需要投入大量勞動的過程。這正是為什么IT需要方便地訪問數據服務集合或是數據映射的原因。Common Sense的 DePalma說:“到了一定階段,就必須建立信息庫。這不僅對SOA至關重要,在傳統環境中也是如此?!?br>
映射建立后,IT就可以將注意力放在開發執行它們的連接或服務上。IT必須了解哪些映射應當提供給多個服務和應用,因此要被當作獨立的流程來實現;還有哪些映射是特定業務邏輯所特有的,應當與這個業務邏輯封裝在一起。
而由于沒有清晰的ROI,許多企業并沒有開展數據架構的建設。不過,IT部門可以循序漸進地參與進去,圍繞用于滿足特定應用或服務需要的信息開發規則和元數據。
BEA總設計師Paul Patrick說,數據架構通常包括多個數據模型,每個模型面向特定的主題或流程類型。IT部門可以采取分段開發的方式,同時需要精確定義數據模型之間所需的映射。
IT部門還要集中精力來應付異常數據。例如,IT應當開發查找異常數據的服務,而不是去嘗試開發映射每一種可能的狀態或關系企業范圍的本體。最后,專家建議,企業應當構建分發主數據的數據服務層,盡管實現這一目標的基礎設施和工具目前尚不成熟。
準備行動
在企業中以服務的形式提供數據源是一項宏大的工程。對傳統的集成工作而言,這意味著了解每個應用中的上下文關系,以及數據在交付給其他應用時該如何轉換。對SOA來說,這需要了解數據與不同的業務流程間的多種關系和依存性。
專家認為解決這種環境的復雜性,需要在建立數據架構模型前進行IT投入,要求企業系統地考慮數據的依存性和上下文關系。IDC的Morris說,發現數據模型和建立映射的工作量占到SOA數據架構開發工作量的70%左右。GGB的Kenngott說,建模與發現的工作量占其ERP整合項目中數據集成工作量的30%左右。
Starwood的Park說,這是非常值得做的準備工作?!胺駝t,你會在實施項目很長時間后才發現有10個不需要的字段、10個需要但在設計服務時不知道的字段,以及5個與設想不一致的字段。當你擁有一個具有數百個服務的復雜系統時,這些接口必須被明確下來?!彼f。
(責任編輯:銘銘)