好公司中的SOA

團(tuán)隊(duì)協(xié)作

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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