好公司中的SOA

團隊協(xié)作

SOA 切實地發(fā)生著。采用 SOA 時，將影響整個企業(yè)，而不僅是 IT 部門。

企業(yè)內不同的組織(可能到目前為止都采用相當獨立的方式運作)突然被要求重用其他人的服務，并為創(chuàng)建共享服務提供支持。企業(yè)內可能會對這個新的"共享"安排有所顧慮。例如，組織 A 創(chuàng)建了關鍵型服務 X 來支持他們的某個解決方案。他們并不希望將服務向其他組織的應用程序公開，因為他們并不控制其他應用程序，擔心這些應用程序可能會使得此服務崩潰。此外，如果組織 B 的應用程序使此服務崩潰，則可能會導致組織 A 的解決方案也停機?？梢赃@樣說，就像將所有人都將雞蛋放入同一籃子一樣。

這個顧慮非常有道理，事實上必須對所需的需要與給定共享服務關聯(lián)的服務質量進行積極評估，從而對其加以處理。不同的組織可能會依賴于相同共享服務的不同服務質量，如果差異足夠大，從財務角度(不是管理角度)來看，認為應該部署該服務兩次。

現(xiàn)在，在組織開始對共享服務的最優(yōu)服務質量吹毛求疵前，可能會希望對共享服務接口的情況達成一致。如果組織 A 和組織 B 均在過去創(chuàng)建了類似的服務，無疑將會就 A 的服務和 B 的服務如何進行組合以形成共享服務的接口進行討論。此類討論總是會相當激烈，兩個組織都會非常在意其一直依賴的服務的接口中采用所需更改而需要進行的工作。通過部署在之前已經存在的服務與新共享服務間進行轉換的 facade 服務，可以簡化此轉換工作。

很可能在服務調用者和提供者之間存在某個業(yè)務實體。誰應該定義實體的表示方式?間接來說，"業(yè)務部門"應該負責此工作。應該制訂業(yè)務術語表，以文字的方式描述"供應商"和"項"之類的業(yè)務概念。還應該捕獲每個概念的動態(tài)方面的信息，類似于如何在業(yè)務內對其創(chuàng)建和使用之類。將由"業(yè)務部門"在數(shù)據(jù)架構師的幫助下從術語表中派生出邏輯業(yè)務信息模型?？梢詮倪壿嫎I(yè)務信息模型派生出持久性模型(可以采用 DDL 表示)和服務信息模型(可以采用 XSD 表示)。

正如您所看到的，不僅不同組織的 IT 人員必須開始彼此交流，而且其對應的業(yè)務人員也將進行類似的溝通。和 IT 一樣，這些人員很忙，可能需要讓他們確信他們在定義服務接口的過程中扮演著一定的角色(雖然是間接的)，但在業(yè)務級別達成此一致前，IT 僅僅是對需求進行猜測而已。

耦合和分離處理新關系

好，現(xiàn)在每個人都在彼此進行交流，而且我們都在扮演著自己的角色，那就可以創(chuàng)建該死的共享服務了，對吧?是的，從技術角度而言的確如此，但由于每個組織目前都負責自己的 IT 支出，那誰將為共享服務提供資金投入呢?共享服務是否可以承載于某個依賴組織的 IT 部門，或者是否將創(chuàng)建某個共享服務組織以某種方式為其提供資金投入呢?如果由現(xiàn)有組織承載，其他組織是否要為服務實現(xiàn)的擴展做出一定的貢獻，以便此實現(xiàn)能夠支持所有依賴組織的需求?如果服務由共享服務組織承載，該組織是否將采用集中方式提供資金支持，或者從依賴于共享服務的各個組織的預算中提供資金支持?談到資金投入，共享服務的成本模型是什么樣的?如果給定服務需要 IBM? WebSphere? Process Server 之類的新技術，且該服務是驅動對此新技術的需求的第一個服務，則此新技術的全部成本(人員、培訓、輔助監(jiān)視、管理、維護成本等)都歸于此新服務，還是采用攤銷方式分攤到使用此新技術的后續(xù)服務?

可以采用很多方式處理這些事實，雖然"正確"解決方案將會根據(jù)組織不同而有所不同，但重要的是要認識到解決此方面問題的需求并加以計劃。此組織耦合是由于希望重用服務和更好地保持 IT 與業(yè)務的一致性而引起的，可能會從組織變更方面的專家的幫助獲益，例如通過 IBM 全球業(yè)務服務部提供的專業(yè)指導等。

我們已經討論了 SOA 技術增加耦合的領域，接下來我們將注意力轉向組織之間耦合減少的領域。在這種情況下，兩個組織都是 IT 部門的下屬部門。我將以應用程序開發(fā)團隊和數(shù)據(jù)(或信息)管理團隊為例。

在我看來，可能沒有受到足夠重視的一項技術是"信息作為服務"或 IaaS。其原理非常簡單：從技術和組織的角度將應用程序同信息分離，在應用程序與其使用的信息之間引入代理服務。應用程序領域屬于應用程序開發(fā)組織，而數(shù)據(jù)管理(或信息)則屬于數(shù)據(jù)團隊。應用程序團隊通過從接口規(guī)范派生的項訪問規(guī)范形式(還記得服務信息模型嗎?)的信息，對信息如何產生并不關心。數(shù)據(jù)管理團隊決定信息如何存儲及其存儲位置。

在這二者中進行更改時，并不會對彼此造成影響。例如，在現(xiàn)有企業(yè)中一種常見的情況是，信息存在于數(shù)據(jù)中心中的多個位置。財務與采購部門可能具有自己的半自動數(shù)據(jù)庫，并具有自己的"供應商"定義的變體，所表示的供應商信息大量重復，但并不完全相同。業(yè)務部門可能會在某一點就"供應商"的規(guī)范定義達成一致。將通過信息服務訪問供應商(創(chuàng)建 (Creat)、讀取 (Read)、更新 (Update)、刪除 (Delete) 和搜索 (Search);簡稱 CRUDS);此信息服務使用從業(yè)務信息模型派生的服務信息模型。所有新應用程序應該使用規(guī)范形式，而且在可能的情況下，所有更新的應用程序也應該采用此形式。為了盡可能減小"對象模型阻抗"(對象模型間轉換的運行時與維護開銷)，應用程序應該將供應商服務信息模型內部化。此工具可通過使用工具來方便地完成，此類工具可方便地生成服務接口中使用的元素的應用程序技術表示形式。例如，如果 IaaS 服務接口以 WSDL 表示，而應用程序技術是 Java?，大量工具都支持從 WSDL 接口定義生成 Java 類。無疑，應用程序可能需要根據(jù)其用途通過派生或封裝對生成的類進行擴展。

現(xiàn)在讓我們回到供應商服務。數(shù)據(jù)團隊具有生成供應商服務的責任，而在 IBM Information Server 之類的產品中提供了支持此工作的工具。服務可能是熟悉的數(shù)據(jù)訪問技術上的 thin Facade，如嵌入式 SQL 或 SQL，或者最好是提供聯(lián)合、清理和轉換功能的現(xiàn)成軟件包。后一種方法將更好地促進對整個企業(yè)內的供應商不同表示形式的收集，并能幫助采用規(guī)范形式將其重新公開。此外，可以切實地通過工具的集成來優(yōu)化數(shù)據(jù)治理的某些方面，以捕獲業(yè)務術語表、派生業(yè)務信息模型、管理信息服務和創(chuàng)建清理與轉換規(guī)則。

順便提一句，我某天遇到過一個公司，他們的應用程序開發(fā)團隊非常關心對象到關系映射(Object to Relational Mapping，ORM)技術。讓應用程序開發(fā)團隊關心 ORM 是與封裝及分離對立的。ORM 可能(我并不推薦這種方法)在服務實現(xiàn)中會起到作用，而這是我們認為屬于數(shù)據(jù)團隊領域內的內容(您也這樣認為，對吧?)。我強烈建議使用框架或工具來避免這種有問題的數(shù)據(jù)管理方式。

業(yè)務與 IT 的一致性

讓我們把注意力轉到 SOA 引入耦合需求的另一個方面，營銷材料中將其稱為"一致性"。我將其目標視為業(yè)務與 IT 中的可變點的一致性。業(yè)務領域中的變量不應作為 IT 領域中的變量實現(xiàn)。我之所以在討論 SOA 時提到這個問題，是因為我們有時候會在討論服務接口定義(這對 IT 人員而言是變量)時遇到這個問題。

以下是我最近看到的一個例子：某公司希望在整個企業(yè)和渠道內進行一致業(yè)務決策。他們明智地將業(yè)務邏輯提取到業(yè)務規(guī)則引擎中，并通過 Web 服務提供對業(yè)務邏輯的訪問。假定該服務為"getEligibleProducts"服務，業(yè)務規(guī)則使用關于客戶的已知事實來向客戶提供其可能感興趣的公司產品列表。第一天，當 IT 部門與業(yè)務部門一起決定服務的接口情況時，業(yè)務部門表示出了對在業(yè)務規(guī)則中使用客戶體重、身高和郵政編碼來計算合適的產品的興趣。創(chuàng)建、部署服務并至少由一個解決方案使用后，業(yè)務團隊提出他們希望添加規(guī)則，以將客戶年齡考慮進來。服務接口接受體重、身高和郵政編碼，但不接受年齡。IT 團隊估計至少需要一個月(有可能需要兩個月)來對服務提供者和使用者進行更改和執(zhí)行必要的測試?？上攵?，業(yè)務團隊非常失望，因為"這個 SOA 原本應該讓 IT 更為靈活，但它卻使其變得更糟糕"。

在我看到的這個特定示例中，IT 通過將關于客戶的每個已知事實(約 800 個元素)傳遞給服務，然后服務將使用其中很少的一部分(約 5 個元素)。其基于的想法是，無論業(yè)務部門希望在規(guī)則中包含任何事實，這些事實都對服務可用。由于 XML 具有非零處理開銷，而這增加了元素的復雜性和基數(shù)性(具體取決于服務的使用模式)，因而此解決方案可能會帶來性能問題。從學術角度而言，它僅僅延遲了遲早需要解決的問題，因為在將來某個時間收集更多的事實時，將需要對接口進行更改。有很多替代解決方案的變體，但都歸結為，不要在 IT 領域的不可變概念中實現(xiàn)可變業(yè)務概念。一個建議的解決方案是，提高客戶機的復雜程度，從而在所需的變量中包含變量。服務接口將公開屬性容器，其中可以隨意包含與業(yè)務設想一致的屬性數(shù)量。客戶機將在服務注冊中心查找相關信息來確定服務需要哪些事實，并將其包含在容器中。顯然，這種方法缺少在服務接口中準確制定參數(shù)所帶來的開發(fā)類型安全，從而引入了對服務中進行更為安全的錯誤處理的需求，但您得做必須做的事。

這些僅是眾多示例中的一部分而已，說明了 SOA 可能會如何影響組織間的耦合、關系以及交互(這些組織以前沒有交互，或者沒有很正式地進行此工作)。推出 SOA 可能是個挑戰(zhàn)，但其中充滿了樂趣，因此可以讓我知道您的 SOA 工作情況。(天極網)