在過去幾年間，面向服務的體系結構(service-oriented architecture，soa)受到了極大的關注，帶來了軟件開發和業務敏捷性的新時代。不過，僅僅 soa 本身并不能解決世界的 it 問題。我們仍然需要可靠而有效的軟件工程實踐，因為管理落后的 soa 實現和其他體系結構方法一樣會出錯(如果不是更糟糕的話)。本文將從實際的角度看待 soa(技術和業務兩方面)，并將提供一個實際的案例研究，說明通過成功的 soa 實現帶來的好處。

　　撩開神秘面紗

　　關于 soa，目前并沒有統一的定義，但為了實現靈活性和業務敏捷性的體系結構目標，確定了以下這個得到廣泛認可的抽象定義：

　　定義 soa 的體系結構風格描述一組模式和指導原則，以創建松散耦合的基于標準且與業務相結合的服務，由于描述、實現和綁定之間實現了關注分離，這些服務能夠提供更高級別的靈活性，以響應業務威脅和機會。

　　按照達爾文的優勝劣汰觀點，soa 是之前的分布式體系結構風格(如分布式組件對象模型(component object model，dcom)、common object request broker architecture (corba) 和 enterprise javabeans (ejb))的自然進化，但其中又融合了各種標準(特別是基于 xml 的標準)，以提供更好的互操作能力。另外還特別明確地強調業務一致性，而這在之前的體系結構中并沒有占到主流地位。soa 通過這一點為業務流程驅動的開發提供了理想的平臺，可讓業務分析人員完全參與到軟件開發生命周期中來，而這就是它的一個重要優勢。

　　不過，直接采用 soa 并不能保證項目成功(esb 并不是企業的尚方寶劍!)，有些項目根本就不應該采用 soa 方法。我們都聽到過人們談論各種不好的體系結構和失敗項目，然后說“soa 應該能夠解決這個問題”。但是，就像我們很可能會創建笨拙龐大的基于 java™ 2 platform enterprise edition (j2ee) 的體系結構一樣，我們也很容易用錯 soa。如果 ejb 的早期實現失敗了，其原因應是有些架構師并沒有真正地了解技術的限制(親歷過由于某種數據庫搜索而導致應用程序將數百個在容器管理的持久性 [cmp] 實體 bean 加載到內存中的情況的人應該清楚我所指的是什么)。但就 soa 而言，這并不簡單。對服務采用類似的全權委托理論已導致了對每個應用程序功能調用都內部使用 web 服務的應用程序的出現——不再是完全的性能解決方案!

　　謝天謝地，我們似乎從過去這些沉痛的教訓中吸取了經驗。例如，創建通過 j2ee 經驗總結的模式和關聯的反模式過程中獲得的知識已經被用于構造有關 soa 的類似最佳實踐。ibm® 已經成功地開發了 soa 應用程序方面可重用的模式和藍圖，并制定了行業特定的模型，可幫助進行體系結構決策和提供服務標識方法。

　　通過使用此類構件，可以對引入 soa 的成本造成極大的影響。對于任何新技術，都會存在相關的啟動成本，而 soa 會讓人覺得初期投資特別大。對重用和靈活性的強調是有代價的，而這很難在項目級別為 soa 推行提供支持，因為并不一定會給項目帶來好處?；谀Ｊ降募铀倨骱同F成資產能夠幫助縮短交貨時間，但最終需要對初始 soa 項目進行一定的投資。不過，有證據表明，隨著整個企業的后續 soa 項目擴展和重用服務目錄中的服務，將會降低開發成本，從而讓開始 soa 之旅的組織在中期收回這些成本。

　　soa 視角

　　嘗試回答問題“什么是 soa 時?”，務必考慮您的目標受眾的觀點，他們的看法通?？蓺w為兩類：it 或業務。根據其出發點不同，他們可能會出于不同的原因而支持采用面向服務的概念，而且所認識的潛在的好處和缺點也不盡相同。

　　每種觀點都會從不同的角度描述方法和對采用此技術進行評價。并沒有關于如何開始引入 soa 的非常明確的方法;soa 并不是規定性的東西，所注重的是靈活性，不僅體現在最終結果上，也體現在實現結果的過程中。

　　下面讓我們進一步對這兩個方面進行討論。

　　it 方面

　　從 it 角度而言，soa 定義一個軟件體系結構，此體系結構由松散耦合的分布式組件組成，而這些組件通過通信通道進行合作，從而形成了組合應用程序。soa 的目標是實現組件重用，而不受實現語言或主機平臺的影響，可以將此視為好的軟件工程實踐的外推法，讓我們從類重用上升到服務重用的級別——真正的組件體系結構。

　　如果服務是基于組件的體系結構的開發的自然發展步驟，用于對其進行鏈接的企業服務總線(enterprise service bus，esb)則可以視為輪輻式集成樣式的發展。esb 消除了輪軸作為單一錯誤點的角色，帶來了可伸縮性、智能路由、安全性和中介，而這些均基于 soap 和 ws* 開放標準。

　　那么這項新技術給 it 專業人士帶來了什么呢?

• 組件體系結構：這提供了用于構建可伸縮和可重用的軟件組件的獨立于平臺和語言的靈活方法。
• 松散耦合：esb 的使用提供了理想的機制來對服務使用者和提供者進行松散綁定，完全消除了點對點接口。
• 實用工具服務：通過這些可構建可重用 it 服務庫，提供電子郵件服務、信用卡服務等等，其通過 soa 成為企業資產的一部分。
• 遺留支持：雖然通常使用 soap/http，但服務并不一定為 web 服務。本機應用程序和遺留系統都完全可以加入到 soa 中來，例如，可以使用 java message service (jms) 掛鉤到 ibm iseries® 平臺上的 mq 集群中，從而給遺留 rpg 應用程序帶來新生。
• 平臺獨立性：標準的采用已成為了 soa 中的關鍵，從而讓之前不兼容的技術跨一系列平臺進行協作。

　　這些特性可帶來直接的技術優勢，通常可為引入 soa 思維方式鋪平道路，特別是在中小型企業 (smb) 領域中，it 通常推動 soa 的引入。可以在單個項目級別實現此方法(雖然有些 soa 方面可能不會帶來短期好處)，單個 soa 項目的成功可能會導致此技術在整個企業內大幅度推廣開來。

　　事實上，通過這種方式采用 soa 不僅為給 it 帶來好處，而且會間接地為業務提供幫助。隨著部署的 soa 項目越來越多，此方法的好處將變得越來越明顯：

• 組件重用度的提高應該會減少開發工作量，并在 it 項目交付方面表現出較大改善。
• 由于使用了接口分離特定的運營系統，因此應該在業務規劃方面具有更大的靈活性。
• 點對點連接的消除應該可以簡化引入新業務系統的工作。

　　這些因素減少了風險和成本，可提高業務敏捷性;不過，這些最終都是 it 帶頭開展的活動，業務沒有控制權。

　　業務方面

　　2006 年度 ibm 全球 ceo 調查(全球有超過 750 位 ceo 參與了此項調查)，發現 87% 的 ceo 認為接下來兩年所需的最基本更改就是要推動創新。gartner 的著名分析師 roy schulte 捕捉到了這些想法，認為“以前構建應用程序是為了長久使用，現在構建應用程序需要考慮進行變更”。

　　那么 soa 為業務提供了什么來對此加以管理呢?回頭看看本文前面的 soa 定義，可能很難發現如何引起業務部門對其的興趣;松散耦合、關注分離 和體系結構風格 都是以 it 為中心的術語。不過，從業務角度而言，定義中的關鍵詞是靈活性。

　　與之前相比，業務必須比以往任何時候都需要能夠快速地適應不斷變化的業務條件。it 體系結構開始向集成模式發展，要構建跨多個操作系統的業務流程，并將現成產品與遺留系統連接起來。soa 提供了支持該模型的靈活性，特別是提供了理想的平臺來采用一項關鍵性技術：業務流程建模(business process modeling，bpm)。

　　通過 ibm websphere® business modeler 之類的工具，業務分析人員能以圖形方式定義和建模業務流程。但這不僅是文檔工作;websphere business modeler 可以使用業務流程執行語言(business process execution language，bpel)表示生成的構建;bpel 是一種 xml 語言，可以導入到 ibm websphere integration developer 之類的各種工具中。此時可以通過將業務服務(或者更準確地說，其接口)連接到業務流程中的任務，以組成解決方案。流程并不會考慮基礎服務的實現或接口的技術細節，只要滿足其需求即可。

　　用于構建軟件解決方案的此方法可為業務帶來明顯的好處，這可以通過以下方面得到證實：

• 業務驅動的開發：業務分析人員為軟件開發工作打下基礎，但不用考慮技術細節。
• 企業級解決方案：解決方案明確設計為跨多個業務部門，而不是由特定 it 系統的可用性決定。
• 可重用業務組件：您將最終構建可重用現有業務服務的投資組合(試著詢問典型的保險公司的 it 部門，他們有多少個創建保單 功能的不同實現)。
• 績效指標：盡管本文中沒有提到，但通過使用 bpel 可在流程中嵌入關鍵績效指標(key performance indicator，kpi)?？梢詫⑵溆糜谙驑I務部門提供有關系統狀態的智能反饋。
• 業務敏捷性：it 的重點在提供業務價值和敏捷性?？梢酝ㄟ^重新編寫業務組件(而非完全更改整個應用程序代碼)來最小化和專注于業務需求變化的影響。

　　最終的結果是，業務分析人員有效地定義與其業務單位的需求一致的軟件流程，并以靈活的環境為基礎，從而能夠專注于更改的影響。業務擁有控制權。

　　行業模型

　　隨著業務流程模型的開發，還出現了一系列對其提供支持的行業標準，以簡化互操作性和促進 it 系統與業務合作伙伴間的流程和服務重用。金融、保險和醫療保健部門在這方面都有發展，但本文將討論一些電信相關的標準，因為這些標準與本文稍后討論的案例研究密切相關。這些活動(在以下部分中列出了其中一些活動)提供有關行業最佳實踐的詳細指南(業務和技術級別)，讓軟件工具與行業模型保持一致。

　　增強電信運營圖

　　增強電信運營圖(enhanced telecom operations map，etom)隸屬下一代運營系統和軟件(next generation operation systems and software，ngoss)計劃，正在迅速成為被電信行業廣泛接受的業務流程標準。etom 可作為領域分析參考圖，正在逐漸成為電信行業的通用業務語言。

　　etom 使用層次結構模型，對業務組件進行多次分解，直到能夠使用適當級別的細節對其進行表述為止。在最高的概念級別，etom 定義了三個寬泛的功能領域：

• 操作
• 企業管理
• 戰略、基礎設施和產品

　　通過接下來三次迭代對這些實體進行分解，就可以得到企業的組件圖，在其中標識服務提供者所需的基本構建塊，最終標識各個流程。在上面的每個功能區域中，etom 都提供了以下三個級別的分解：

• 第 1 級 將第 0 級的實體(如運營)細化為更為具體的功能領域，如客戶關系管理(customer relationship management，crm)、服務管理和資源管理。
• 第 2 級 提供進一步的分解級別，分解為具體的處理區域，如訂單處理或老客戶關系鞏固。
• 第 3 級 開始定義在第 2 級的實體中可能進行的典型業務活動，如發出客戶訂單、信用卡授權以及跟蹤訂單處理等。

　　此層次結構方法如圖 1 中所示，其中給出了運營模型的第 2 級分解，重點突出了客戶關系管理 (customer relationship management) 第 1 級實體中的訂單處理組件。

　　圖 1. etom 運營第 2 級分解

　　etom v6.0 第 1 級到第 3 級已經在 websphere business modeler 中完全實現，如圖 2 中所示。同樣可以在其中看到運營領域的層次結構分解，其重點同樣是圖 1 中突出顯示的客戶關系管理第 1 級實體。

　　圖 2. etom 運營第 2 級分解

　　websphere business modeler 項目層次結構視圖顯示了四個第 1 級的組件，并將客戶關系管理展開，最終顯示確定客戶訂單可行性 (determine customer order feasibility) 第 3 級流程。所建模的每個構建都與一個遵循標準 tmf 命名約定的標識符關聯。

　　由于這些流程在 websphere business modeler 中建模，因此可以對其進行組裝，并最終作為 soa 的一部分進行部署。而且，這些流程均已經進行了擴展，包括第 4 級，以便定義滿足關聯的第 3 級流程的需求所必需的服務接口，如圖 2 中突出顯示的部分所示。另外，還提供了整個電信運營的框架實現，并提供了快速 soa 開發工作的藍圖。

　　共享信息/數據

　　如果說 etom 可幫助進行電信運營內的流程的標準化工作，那么共享信息/數據(shared information/data，sid)模型(也隸屬 ngoss 計劃)就提供了一個公用術語庫，定義了超過 1,000 個行業標準業務實體。這些定義最初是使用統一建模語言(unified modeling language，uml)定義的，后來又改用 xml 模式定義(xml schema definition，xsd)對其進行定義，現在都作為業務項在 ibm soa 工具中提供，以供在流程模型中使用，提供了定義服務接口的基礎。

　　使用 ngoss sid 及其通用信息語言的好處在于，可通過其實現與企業運營的成本、質量、時間和自適應性相關的業務好處，讓您的企業將重點放在為其客戶創造價值方面。

　　電信應用圖

　　電信應用圖(telecom application map，tam)有效地充當了 ngoss 框架構建塊(etom 和 sid)與實際的可部署且能得到的運營系統之間的橋梁，將流程功能和信息分組為得到認可的運營支撐系統(operation support systems，oss)和業務支撐系統(business support systems，bss)應用程序或服務。

　　雖然此領域可能沒有絕對完美的解決方案，但 tam 提供了一個通用參考框架，允許供應商、客戶和在此領域進行運營的業務合作伙伴了解彼此的觀點。tam 基于對當前固話網絡、移動網絡和線纜通信領域可用的典型系統的觀察，并會隨著這些系統的發展而發展。

　　從集成的角度而言，tam 提供了基礎運營系統的規范模型，并為在 etom 中定義的業務功能和流程提供了通用端點。它充當了 facade，將業務服務從與基礎運營系統相關的技術實現細節分離出來，從而進一步減少了此領域變更的影響，實現了基于 soa 的解決方案的一個主要目標。

　　ibm websphere business services fabric

　　ibm websphere business services fabric 提供了一個端到端 soa 平臺，用于建模、組裝、部署、管理和治理組合業務服務。它提供了設計時工具、運行時環境、行業參考模型和預構建的 soa 資產，以支持快速開發針對行業的組合業務服務。

　　websphere business services fabric 還提供了可選的電信軟件包，此軟件包構建于上述 ngoss 標準和 websphere business modeler 擴展之上，提供了專門針對電信行業定制的、可配置的預構建參考業務服務模板集合。通過這種方式使用預構建資產，可通過重用、標準化和跨 it 資產的一致性支持來幫助減少電信運營服務的維護成本。

　　治理

　　盡管治理在分布式體系結構的構造和管理中并不是新概念，但從失敗到成功實現或遵循治理的經驗使其在 soa 中的重要性得到越來越多的重視。

　　早期一些使用共享庫(如 microsoft® windows® 動態鏈接庫)造成的混亂局面就是此領域缺乏治理的結果的一個例子。windows 構建于大量 dll 之上，dll 是系統級別的公用功能庫，在運行時供很多使用者動態地訪問。桌面應用程序也可以使用這些 dll，而且根據操作系統的當前路徑級別等因素，可以在安裝應用程序時引入這些系統 dll 的新版本。

　　您需要仔細分析更新共享 dll 的版本的影響，因為所造成的錯誤的影響將非常廣，而且難于定量。您需要保留接口，棄用所建議的退役 api，向相關受眾發布關于功能更改的信息，并在發布前使用新版本測試依賴于庫的當前版本的應用程序和 dll。

　　如果沒有進行這些必要的工作，則很容易發現陷入循環依賴關系的網中，發布一個 dll 可能會修復一個問題，但最終會帶來兩個新問題。

　　soa 嘗試通過將培訓與管理技術結合來處理治理共享服務的類似問題，通過 soa 卓越中心(centre of excellence，coe)概念提供流程、模板和最佳實踐。coe 提供治理中央機制，控制 soa 生命周期的所有方面，包括以下內容：

• 開發過程
• 運營問題
• 服務所有權

　　這以傳統的基于項目的設計權威角色為基礎，但將其提升到了企業級別，提倡跨所有 soa 項目的重用、一致性和標準化。

　　客戶案例研究

　　雖然 soa 肯定可以應用于新項目開發，但可能在再工程領域才是它發揮自己最大效力的地方。下面的案例研究給出了很多現有 ibm 客戶面臨的一個業務問題，這同時也是迅速發展的組織所經歷的典型問題。這通常會導致業務需求通過涉及調配具體系統的戰術 it 活動實現，而非戰略企業級的計劃。soa 的引入提供了在經歷了這樣的發展之后將 it 與業務相結合的機會。

　　問題

　　客戶的業務非常依賴于自定義的現成產品來進行電信運營?？蛻舻幕A設施中的每個應用程序在彼此獨立的情況下都能正常工作，但由于缺乏企業視角而導致這些產品之間集成情況糟糕，從而出現豎井 (silo) 情況極為嚴重的局面。從 it 角度而言，這并不一定是個大問題;每個系統都正常工作，似乎都在管理著一個業務流程。不過，這些流程實際上只是子流程，均參與到跨多個業務部門的較大事務中。

　　由于這樣，會給用戶帶來以下影響：

• 多次身份驗證：用戶需要維護多個運營系統的多個登錄憑據。
• 集成情況不理想：相關處理系統之間沒有或僅有很少的自動化;在存在集成的情況下，也是使用不靈活的專用 api，而這意味著要進行更改非常困難。
• 手工處理：由于缺乏集成，因此存在大量的手工活動，導致出現數據重復，而且需要手動進行協調。
• 數據不一致：手動干預不可避免地會導致生產系統間出現不準確的數據表示形式。
• 可見性差：缺乏整套業務流程，意味著很難生成準確的 mis 信息。

　　此案例研究的重點在于上面問題中重點涉及的以下三個運營系統間的集成：

• 訂單管理系統：用于記錄和管理客戶訂單
• crm：作為客戶信息的主要來源
• 供應系統：用于激活客戶所需的網絡服務(即漫游、3g 等)

　　每個系統都包含應用程序特定的業務邏輯，這些業務邏輯均以相對獨立的方式運行，如圖 3 中所示。此邏輯經常與表示信息交織在一起，即體系結構內沒有清楚的關注分離，從而進一步限制了靈活性。在系統彼此通信的情況下，由于使用了專用 api，因而存在緊密依賴關系，這種方式不可靠，而且會降低可見性。

　　圖 3. 業務子流程

　　這些系統的用戶群實際上有重疊，有些用戶最終需要按順序訪問所有三個系統，以收集必要的信息。這就要求他們進行多次登錄，以不同的表示樣式進行交互、進行重復任務并手動對每個系統的信息進行協調。

　　解決方案

　　引入 soa，以在分層參考體系結構中統一這些異類系統，如圖 4 中所示。

　　圖 4. soa 分層體系結構

　　每個層次提供不同的好處(如下所示)，這些層次一起提供了一個靈活的可自定義的業務驅動體系結構。接下來讓我們詳細討論一下這些層次：

• 表示層：引入了門戶，為用戶提供跨業務活動范圍的統一用戶體驗。通過其個性化功能，可以針對用戶的角色對界面進行定制，從而通過基于瀏覽器的單點登錄環境為用戶提供相關內容。
• 業務流程層：盡管現有業務邏輯主要部分仍然駐留在運營系統中，但業務流程層將對這些系統限制如何協作進行編排。它可提供以業務為中心的視圖，記錄端到端流程，但是不考慮細節。
• esb：可以將總線視為此方案中的粘合劑。它為服務提供者和使用者(可以為業務流程或 portlet)提供一定程度的隔離。雖然總線中沒有業務邏輯，但它可以進行動態路由(例如，基于某個服務級別協議選擇一系列激活服務中的某個服務)，并進行接口映射，有效地將異類基礎數據對象統一起來。
• 服務：提供了基于標準的接口，允許使用者以獨立于平臺的方式訪問服務包含的功能，而不用考慮其實現。
• 服務組件：這包括實現服務指定的功能的軟件組件。服務組件遵循服務層中定義的契約，并保證 it 實現與服務描述的一致。
• 運營系統：運營系統大部分都沒有變化。不過，其間的任何依賴關系限制都完全在業務流程層內進行了處理。其目標不是將業務邏輯從這些應用程序遷移出來，而是要保留其經過生產驗證的功能，并以標準方式在整個企業內對其進行公開，從而提高其可見性。假如服務接口不變化，則基礎運營系統可能會在不影響服務使用者的情況下進行變更。通過這樣，就可以使用獨立的實現完全替換一個運營系統(例如，使用 siebel 替換 peoplesoft)，讓業務需求推動系統的選擇，而不是讓 it 主導供應商的選擇。

　　服務投資組合

　　標識服務時，可以使用一系列建模技術，如 ibm 內使用的面向服務的建模與體系結構(service-oriented modeling and architecture，soma)方法，本文對此將不予討論。但抽象一點來說，所標識的服務歸為兩大類：

• it 服務：這些服務通常不包括實質的業務邏輯，而用于提供對現有運營系統的基于服務的訪問。通常稱為原子服務(因為這些服務通常并不依賴于任何其他服務)，且由基礎運營系統直接提供——不過也可以使用可用的任意接口機制自行構建。所公開的方法通常都是通用型的細粒度方法(例如，crm 服務可能會提供 getcustomerrecord 端點)，因為這些服務主要設計為供其他服務進行重用。雖然此接口可以由 esb 訪問，但最好僅在服務接口足夠通用，而且不會在使用者和提供者之間引入緊密耦合的情況下才使用。
• 業務服務：這些服務包含業務流程使用的業務邏輯，通常稱為組合服務，因為這些服務可能會將處理委托給一系列其他業務服務或 it 服務。與 it 服務不同，所公開的方法通常是粗粒度的，且通常與特定業務活動相關(如 provisionnetworkservice)。

　　經常還有第三類服務，信息服務，用于提供對數據源(通常為聯合數據源)中包含的數據的直接訪問。不過，在這種情況下，所有數據訪問都是通過相關運營系統執行的。

　　行業遵從性

　　使用行業特定的業務流程模板和數據模型不僅可以加速在 websphere business modeler 中進行的開發工作，而且還能夠提供對業務本身的結構、確定的差距和重疊區域的驗證。不過，可能更為重要的是其帶來的前瞻性品質認證，特別是在應用程序集成方面更是如此。

　　由于其多樣化且十分復雜的技術需求，很多電信運營商都非常依賴于現成的系統，將其用于控制從開單到網絡的物理運營的各個方面的事務。這些系統必須有效地進行通信才能保證企業的成功，而遵循行業標準是實現此目標的最好方法。

　　目前需要使用 esb 來執行中介操作，在相關運營系統使用的不同數據表示形式之間進行轉換。但隨著整個行業對標準遵循的不斷增加，這將變得越來越沒有必要。采用通用數據術語是此領域的一個關鍵，可幫助對產品接口進行標準化，提高性能、消除特定的產品依賴性，讓我們回到 soa 的主要目標之一，即業務敏捷性。

　　解決方案堆棧

　　此解決方案基于以下運行時堆棧和開發環境：

• ibm websphere process server (including websphere enterprise service bus) v6.0.2
• ibm websphere portal server v6.0.1
• ibm rational® software architect v7.0
• ibm websphere business modeler v6.0.2
• ibm websphere integration developer v6.0.2
• ibm websphere business services fabric v6.0

　　除了每個體系結構層提供的具體功能外，堆棧還帶來了一系列非功能優勢，包括固有的可伸縮性(通過作為 soa 基礎的 ibm websphere application server 提供的功能)和在堆棧所支持的操作平臺內一定程度的平臺獨立性。

　　盡管我們在此解決方案中使用了一系列 websphere 品牌產品，但此方案最終代表的是一種體系結構范式，并有一定的供應商獨立性。ibm 參加了各種標準組織(如 w3c、oasis 及其 tmf、bpel、xml 和 ws* 標準的后續實現工作)，可確保此解決方案不會成為另一個定制解決方案。

　　總結

　　本文從技術和業務的角度討論了如何通過引入 soa 來處理現實的業務問題。bpm 之類的補充技術的出現帶來了更多的 soa 好處，支持您的業務積極地參與到軟件生命周期中來。

　　我們還了解了 soa 一個將來的發展方向，說明了 it 模式如何發展為行業模板，從而為整個企業提供技術和流程藍圖。任何 soa 的一個主要目標都是將 it 與業務需求相結合，但 soa 現在有了進一步的發展;通過采用新興的行業模型，我們可以看到 soa 理念將如何幫助業務保持自身與行業的一致，通過采用標準和最佳實踐來提供可靠的互操作性和未來敏捷性。