好公司中的SOA

團隊協(xié)作

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

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

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

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

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

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

耦合和分離處理新關(guān)系

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

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

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

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

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

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

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

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

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

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

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

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