不管怎樣，數(shù)據(jù)還是重要。 有效地應(yīng)用SOA需要在物理和邏輯層有一個設(shè)計良好的數(shù)據(jù)模型。許多機構(gòu)甚至要開發(fā)一種的域模型。主數(shù)據(jù)管理和SOA的交叉越來越頻繁地出現(xiàn)，這種趨勢在未來幾年將繼續(xù)下去。

業(yè)內(nèi)人士Kyle Gabhart稱，他近在一項大的SOA應(yīng)用計劃中實施了兩個主數(shù)據(jù)管理計劃。在這兩個案例中，客戶發(fā)現(xiàn)他們在如何解決主數(shù)據(jù)模型與一個或者更多的SOA組件(如業(yè)務(wù)流程、服務(wù)接口等)之間的沖突方面陷入了僵局。每一個客戶都從不同的角度接觸了這個問題。但是，沖突實際上都是一樣的。誰取得了勝利并且按照自己對于企業(yè)數(shù)據(jù)的觀點順利運行？是主數(shù)據(jù)管理團隊，還是SOA團隊？另外，企業(yè)架構(gòu)團隊也許感到疑惑是主數(shù)據(jù)管理團隊的觀點向SOA團隊的觀點妥協(xié)了，還是相反。

狀況1：客戶A決定建立一個的數(shù)據(jù)模型，不依賴于現(xiàn)有的應(yīng)用程序或者業(yè)務(wù)流程。這個客戶執(zhí)行一個簡單的流程：

·建立一個概念的數(shù)據(jù)模型

·識別邏輯子域(數(shù)據(jù)的邏輯組合)

·為這個子域建立一個邏輯數(shù)據(jù)模型

現(xiàn)在，如果出現(xiàn)一個業(yè)務(wù)流程(如向提供商提出漲工資要求)，這個流程就包括訪問提供商的數(shù)據(jù)和這個要求的數(shù)據(jù)域?？蛻羧绾谓⑦@個方案，如何不打破在邏輯的模式中建立的關(guān)系？替代的方法是，這個客戶如何能夠把這個方案與基本的模型聯(lián)系起來。為了企業(yè)面向服務(wù)的觀點，主數(shù)據(jù)模型必須要妥協(xié)，或者面向服務(wù)的觀點必須要修改以便與主數(shù)據(jù)計劃相一致。

分析：因此，這里真正的問題是我們已經(jīng)在真空中創(chuàng)建了一個模型。我們現(xiàn)在面臨一個具體的數(shù)據(jù)應(yīng)用。這可能會讓我們對于數(shù)據(jù)在企業(yè)中如何應(yīng)用的實際情況有一個新的了解。這里有兩個觀點：

1.我們把這看作是一個修改這個模型并且使這個模型符合真正業(yè)務(wù)應(yīng)用的機會。

2.我們不理會需要管理的用戶/客戶的莫名其妙的東西。

如果我們根據(jù)這個新的信息更新這個模型，我們就會有被一個流程曲解的風險。但是，我們也許會認識到這個流程提出的更廣泛的事實。如果我們不改變這個的模型，那么，我們或者說服用戶接受這個“標準的”模型，或者提出一些數(shù)據(jù)鏡像，這樣，業(yè)務(wù)流程就能夠按照他們自己的數(shù)據(jù)模型執(zhí)行這些服務(wù)。

無論采用哪一種方法，面向服務(wù)的設(shè)計的方法都是規(guī)定這個業(yè)務(wù)流程只能看到一種數(shù)據(jù)模型。這可以是來自業(yè)務(wù)應(yīng)用實例中的一個獨特的模型，也