了解 IBM 有洞察力的專家和領先技術開拓者對 IT 架構師在目前及將來面臨的問題的評述，了解他們的觀點與展望。本月，他們將對以下問題進行討論：為什么應該考慮 SOA？何時應當選擇 SOA，何時又不應該選擇 SOA？
歡迎閱讀觀點與展望專欄
歡迎閱讀第一期觀點與展望，IBM 技術專家將在此 developerWorks 專欄中就 IT 架構師需要及時解決以完成其工作的問題提供指導。每個月，我們都將拜訪 IBM 內部架構師社區（包括最知名的有洞察力的人、標準組織的投稿人、我們產品團隊的架構師和每天與客戶接觸的顧問），邀請他們與大家分享他們對目前 IT 和軟件架構師面臨的最重要問題的看法。
無論您是跨越全球的大型團隊的架構師，還是剛剛開始學習 IT 體系結構技術與實踐的新手，他們的回答都將給您提供幫助，為您帶來靈感并促進您的積極參與。這些觀點和看法并不一定十分全面。有關此處涉及的主題的更多指導信息，可以參考 developerWorks Architecture area 的另一部分：IT Architecture resource round-up。另外，如果您有具體問題需要詢問專家，或希望發表討論，則請訪問 developerWorks IT 體系結構討論論壇。
引言
面向服務的體系結構 (SOA) 已成為了一項事實標準，用于開發基于組件的應用程序，可使用標準接口通過網絡（Internet 或其他網絡）訪問這些應用程序。至少 IBM 高級管理人員和很多其他供應商、分析師、顧問和軟件開發人員都這么說。他們還將告訴您，整個行業都在逐步采用 SOA，如果您尚未開始 SOA 開發，將很快跟不上時代的步伐了。
贊譽之詞。但這些看法是否真的很有吸引力，能讓您開始著手您自己的 SOA 嗎？讓我們來看看一位參加 Open Group 主辦的 SOA 大會的架構師的問題。在 IBM Global Services 副總裁 Michael Liebow 的主題發言后的提問期間，這位架構師問道：“SOA 是不是我們需要知道的唯一體系結構？（順便提一下，Liebow 先生的回答是“是的”）在稍后，另一位架構師大聲問道：“SOA 和我們多年前就知道的組件體系結構很相似。如果我們采用了它，是否意味著我們又多添了一個技術豎井（另一個開發死胡同），從而需要進行更多的集成？”（而這次，會議參加者——包括平臺供應商、企業 IT 架構師、顧問、系統集成商和其他人員——回答的是“不是。”）
這就提出了我們本月要向我們的專家詢問的問題。如果您和 IBM 最近接觸的很多架構師一樣，那么您可能正在評估甚至采用 SOA 的過程中。但您可能仍在懷疑這是否是體系結構樣式的必由之路，新東西很快由更為流行的東西取代，或者，這個體系結構是否真的適用。
我們的專家對此問題的回答包含了很多您之前聽到的說法：SOA 促進了可重用性，提供了接口和實現之間的抽象級別以最小化依賴關系，將業務需求與 IT 功能結合，從而可以為您提供用于將業務需求轉換為編程服務來實現流程自動化的機制，以及當前競爭激烈且快速變化的業務環境中所必需的靈活性，等等。另外，這些專家還根據他們與 IBM 內外開發先驅合作的實踐經驗提供了一些新穎的看法，將幫助您了解 SOA 在何時如何（甚至為什么）適合在您的 IT 體系結構和開發計劃中使用。
在此對本月的專欄供稿編輯 Holt Adams 表示感謝。Holt 是 IBM Software Group 團隊一位經驗豐富的 IT 架構師，就您將要讀到的內容為內部 IBM 社區提供了指導。他還提供了他自己對這個問題的回答“何時采用 SOA，何時不采用 SOA。”
好了，不再多說，下面就請了解一下我們的專家的觀點吧。（有關回答問題的專家的更多信息，請參閱本專欄最后的關于專家。）我們邀請您就 SOA 提出您的看法。您可以訪問我們的 IT 體系結構討論論壇，或通過以下地址給我發電子郵件：pdreyfus@us.ibm.com。
Paul Dreyfus，編輯
developerWorks SOA and Web services
何時采用 SOA，何時不采用 SOA
IBM 的目標之一是在其產品內開發和采用開放標準。通過這樣做，就能在您公司的 IT 基礎結構中實現 SOA 的價值主張。SOA 能夠優化業務需求與 IT 的一致性，能夠將業務流程活動從服務實現中分離出來，還能夠降低操作成本。只有在不固定供應商的情況下才能真正實現這些功能，此時面向 SOA 實現的技術可以無縫集成（考慮：“開放標準”），以構造全面的端到端解決方案。
|
不可輕易決定實現 SOA。這與改變生活方式有些類似，因為開發和操作團隊遵循的 IT 控制模式將完全不同。
——Holt Adams |
|
當考慮了策略業務目標和活動時，理論上的 SOA 概念非常具有吸引力，更加容易得到支持。不過，不可輕易決定要實現 SOA。這與改變生活方式有些類似，因為開發和操作團隊遵循的 IT 控制模式將完全不同。我提倡進行業務驅動開發。此過程涉及到將業務需求細化為 IT 要求，然后將 IT 要求細化為 IT 功能，以確定滿足這些需求所需的技術。根據我過去四年開發基于 Web 服務的解決方案和更為成熟的基于 SOA 的解決方案的經驗，以下這些相關因素通常會讓我建議采用面向服務的體系結構：
- 集成成本持續增長，而并未因為可提供真正投資回報 (ROI) 的新業務機會而得到緩解。
- 兼并和收購是您公司擴大市場份額和獲得新發展機會的業務模式的核心。
- 解決方案要求對來自異構系統和編程模型的業務功能進行集成。
- 業務的生存依賴于根據市場變化快速調整或即時響應競爭威脅的能力。
- 全球經濟的影響要求您的公司事半功倍地開展業務，而且有必要依賴業務合作伙伴提供非核心業務功能。
- 就提高收益而言，與業務合作伙伴協作的效率對您的公司十分關鍵。
- 您公司業務資產的價值在減少，因為不能對其進行評估，以在最初用途之外的其他地方使用。
- 您公司員工的效率出現了問題，因為他們的大部分時間并沒有花在提供公司業務模型的核心功能和服務上。
- 您公司的業務充滿了機會型的業務工作。
- 您公司從頭開始開發新應用程序。（我認為 SOA 應當作為定位將來的新應用程序的缺省體系結構樣式，業務條件有其他限制時除外。）
在理想情況下，您和您的業務合作伙伴間沒有預算限制、計劃期限、技能差距和優先級差異，我想，此時完全可以說每個人都會采用 SOA，或者至少會考慮采用 SOA。不過，我們的選擇實際上經常受到過去的決策的影響和限制（例如，技術投資、編程模型采用、服務的合同協定等）。因此，我們并不能總是自由地采用看起來能滿足某個業務需求或技術要求的最佳選項。以下的注意事項會讓我不建議采用面向服務的體系結構或說明現在實現 SOA 的邊際收益：
- 您公司只將小部分 IT 預算用于集成活動。
- 您公司的大部分流程都是手動的或以文檔為中心的，自動化的機會幾乎為零。
- 您公司的大部分應用程序開發都使用相同的編程模型。
- 您公司的操作由一個或兩個客戶關系管理 (CRM) 和企業資源規劃 (ERP) 應用程序管理，幾乎沒有集成要求。
- 您公司的現有技能庫與實現支持 SOA 的基礎結構所需的技能庫之間存在重大差異。
- 未發現可從 SOA 提供的功能受益的業務需求或機會。
- 新業務服務的可用性將對現有的收益流帶來負面影響。
- 您公司依賴的業務合作伙伴對公司間流程的自動化采用了不同的優先級。
- 您公司的主要業務的開展涉及到海量且同步性和實時性要求非常高的事務。
前面的列表只是一個示例，用以說明 SOA 是否是您公司最佳選擇的原因。當然，每個合同或項目都具有唯一的要求，因此關于何時采用 SOA 的決策取決于您公司的業務狀況。SOA 的價值主張十分誘人，但選擇何時讓您的公司采用 SOA 必須考慮業務環境的實際情況。采用 SOA 不一定要跨一大步，而通常是采用循序漸進的方式進行的。首先找到可以利用 SOA 概念和原則的項目，然后使用主要性能指標測定其價值，這是一種讓大家受益的好方法。
將業務與 IT 結合起來
SOA 不僅是一個開發范例。該體系結構用于在業務和 IT 之間構建中間地段，其中包含雙方都同意的一組與業務一致的 IT 服務，這些服務結合在一起，以實現組織的業務流程和目標。此范例提供了前所未有的靈活性：它允許將業務流程的結構化組成從為流中每個活動提供功能的服務中分離出來。它還允許將業務實現與其描述分離開來。進行了此分離后，公司能以增量的方式更改其后端遺留系統，并添加新功能來支持新需求，而不用受到供應商選擇的限制。因此，可以在最小化對業務流程和 IT 系統的影響的前提下對軟件包和自定義應用程序進行替換。
將訪問功能從其實現分離的下一步工作就是 SOA。而且，除了此功能方面外，我們還可以將非功能方面外部化。例如，我們可以根據建立的業務策略確定哪些人應該可以訪問特定的功能。我們還可以定義如何管理希望以靈活的、可重構的方式訪問的技術資源。
|
|
使用 SOA 技術時，實時或被動系統通常不是進行實現的最佳選擇，因為當前的技術不支持將 SOA 用于有大量并發使用情況的實時系統。不過，這些系統的建模也可以從 SOA 提供的分離和獨立概念獲益。
——Ali Arsanjani |
|
軟件工程發展的下一步就是此體系結構。它使我們從結構化對象轉向分布式對象和組件，然后以一組公共服務為中心來將業務和 IT 加以結合（這些服務結合在一起，可以實現組織的流程和目標）。SOA 還允許將公司的部分業務流程向生態系統中的合作伙伴公開。
當需要支持業務靈活性的 IT 靈活性時，就可以使用 SOA。因此，對于兩個程序需要進行通信并訪問組合業務流程的行業應用程序而言，就非常適合選擇 SOA。
使用 SOA 技術時，實時或被動系統通常不是進行實現的最佳選擇，因為當前的技術不支持將 SOA 用于有大量并發使用情況的實時系統。不過，這些系統的建模也可以從 SOA 提供的分離和獨立概念獲益。
SOA 非常適合用于消除冗余及將業務與未緊密耦合到特定服務實現的 IT 功能相結合。它可以允許服務使用者選擇后備服務提供者（不僅基于功能進行選擇——我需要類似的功能，但不要此版本的服務中的額外依賴項，還可以基于設計及運行時策略和 Web 服務管理功能進行選擇）。
企業體系結構基于 SOA 的公司具有穩定的基礎，能從現有系統概念地抽象業務功能。它們還具有允許隨著新軟件包、系統和資產的提供和新需求的出現以增量的方式進行業務驅動的 IT 轉換的基礎。
一個重要但略顯不足的機制
在企業范圍中，大量的創新都出現在以下兩個方面：企業邊緣和企業之間。在邊緣上，我們可以看到在中間件之上的框架投入了很多精力（獨立于領域的框架，如 Ajax，以及特定于領域的框架，以特定行業為中心進行結合），也投入了很多精力進行與設備相關的工作 [ 典型的移動設備和具有無線頻率識別（Radio Frequency Identification，RFID）標記的設備 ]。而在企業之間，我們可以看到系統（遺留系統和新系統）的系統的形成。
|
|
在邊緣，服務提供超越基礎技術的行為。而在企業之間，服務提供了各種系統間語義豐富的強大通信方式。
——Grady Booch |
|
在此類以 Web 為中心的系統中，服務已被證實為這兩個方面的重要機制。在邊緣，服務提供超越基礎技術的行為。而在企業之間，服務提供了各種系統間語義豐富的強大通信方式。
雖然這樣說，但在系統的構造中，服務是一個重要卻略顯不足的機制。這樣說有些過于簡單化，但總的說來，服務對于高頻率或非常小粒度的連接而言，并不非常適合。而且，服務當然不是唯一適合各個系統的體系結構的分解機制。
SOA、Web 服務與優勢保持
SOA 是一個使用得有些過量的首字母縮寫，被從高級管理人員到開人員等各方面的人用（濫用）來傳達多種（有時候是不一致的）語義。在我看來，面向服務的體系結構是一個框架，用于將業務流程和支持技術基礎結構作為標準化且管理良好的組件——服務——進行集成，可以對服務進行組合、重用和調整以滿足不斷變化的業務優先級。
SOA 新手認為 SOA 和 Web 服務是等效的。可能存在不使用任何 Web 服務，而使用現有 IT 資產（從大型機事務到基于對象的系統）的基于 SOA 的有效解決方案。而且，我曾經看到過幾個從部門級別發展出來的不是有效 SOA 應用程序的 Web 服務實現。這些 Web 服務島通常并不完全遵循所有的核心 SOA 原則和特征——它們可能不是松散耦合、未抽象、不可重用、未組件化或不是獨立于平臺和協議的，最重要的是，它們可能不提供真正的業務價值。
由于 Web 服務提供了一個 Level 字段，供基礎結構和應用程序供應商進行創新和互操作，很多規范、概要、術語都使得這一混淆擴大化了。Web 服務僅是一個標準和技術的集合（還有很多其他技術支持選項），用以實現基于 SOA 的解決方案。
在快速發展的全球經濟環境中，企業要保持競爭優勢，必須保持足夠的靈活性。通過使用 SOA 原則將 IT 基礎結構與核心企業流程結合，可以提供和保持這個優勢。因此，理解和采用 SOA 所面臨的問題不是如何或為什么，而是什么時候？基于 SOA 的企業解決方案已被證實能簡化業務操作、提高效率、降低成本及消除冗余。
|
|
我們正處在對解決方案生命周期的每個方面進行改革的浪尖上，而 SOA 則是關鍵的催化劑。不過，從長遠來看，如果我們不謹慎的話，這個抽象和易用性可能會使 IT 架構師或開發人員和計算機科學與技術的根本基礎脫離聯系。
——Sanjay Bose |
|
不過，為了獲得這些好處，必須正確地應用 SOA。必須具有相應企業范圍內的遠景和轉換路線圖，必須有業務執行人員的財務支持和承諾，并由有經驗的架構師以增量迭代的方式進行部署。這些增量步驟應該首先針對關鍵業務問題進行，最終的解決方案應該能提供業務價值。這樣可以幫助保持和促進使用 SOA 進行端到端企業轉換。在采用 SOA 的過程中，SOA 將不斷遇到各種重大的挑戰，其中包括政治和文化的多樣性。
從純技術角度而言，SOA 平臺（包括工具和運行時）也在經歷著巨大的轉變。開發工具環境包含大量的建模工具、行業根深蒂固的場景、重用模式、方案和豐富的可視表示和控件以及模擬技術。運行時也同樣在不斷發展，從而提供增強的服務質量、聲明性的和基于策略的管理和吸引人的管理和監視 Dashboard（針對 IT 事件和業務事件），并使用具有自我修復功能的自動工具進行檢測。我們正處在對解決方案生命周期的每個方面進行改革的浪尖上，而 SOA 則是關鍵的催化劑。不過，從長遠來看，如果我們不謹慎的話，這個抽象和易用性可能會使 IT 架構師或開發人員和計算機科學與技術的根本基礎脫離聯系。
[ 編者注：有關此主題的更多觀點，可以參考 Sanjay Bose 最近與人合著的新書 SOA Compass:Business Value, Planning, and Enterprise Roadmap（此書是 IBM Press 和 Prentice-Hall 聯合出版的 developerWorks 系列叢書之一）。
模型驅動的開發和虛擬企業
您可能已經選擇使用 SOA 了。大部分中型和大型企業都在其應用程序設計中應用了 SOA 元素。結構良好的 CICS? 和 IMS? 程序通常符合 SOA 的要求。很多公司已構建了由消息驅動的應用程序組成的分布式系統。會話 Enterprise JavaBean 就是“類 SOA 的”。很多 ISV 系統都采用類似于服務的構造；例如 SAP IDocs。SOA 將結構良好的分布式系統的指南系統化，是結構化編程、模型對象 (OO) 的概念的子集和消息驅動的處理的自然發展。
|
|
在很短的時間內，我們行業的運行時互操作性和開發工具間的互操作性就達到了前所未有的水平。這個互操作性降低了遷移到 SOA 的成本，從而更容易獲得其帶來的好處。
——Don Ferguson |
|
Web 服務是一組用于構建 SOA 解決方案的標準。基礎結構供應商 (IBM、BEA、Microsoft) 和應用程序供應商 (SAP、Oracle) 正像采用任何軟件技術一樣迅速地采用 Web 服務。在很短的時間內，我們行業的運行時互操作性 [簡單對象訪問協議（Simple Object Access Protocol，SOAP）、HTTP、WS-Security、WS-ReliableMessaging] 和開發工具間的互操作性 [Web 服務描述語言（Services Description Language，WSDL）、WS-Policy、Business Process Execution Language for Web Services (BPEL4WS) ] 就達到了前所未有的水平。這個互操作性降低了遷移到 SOA 的成本，從而更容易獲得其帶來的好處。
都有什么好處呢？此處將不詳細討論全部或任何單個好處。我將簡要地提一下兩個好處：
- SOA 支持模型驅動的開發和從業務透視圖進行解決方案監視。我們通過使用 WebSphere? Business Modeler 產生一個允許分析人員和業務專業人員進行推斷和設計他們的業務流程的工具，從而有了很大進步。SOA 操作是流程中的任務或步驟的自然呈現，而組合服務的實現（BPEL4WS，業務狀態機）則是流程的自然表示。根據簡單業務規則（使用 WebSphere Process Server 啟用），WS-Policy 和服務實現這兩種方法都是業務策略的自然表示。
- Web 服務支持“虛擬企業”。MQ 和 Common Object Request Broker Architecture (CORBA) 等以前的技術主要針對企業內計算進行了優化。Web 服務協議和 WSDL 在 Internet 和內部網絡中均可工作。這樣就能使用以前用于企業內部應用程集成的相同模型來在 Internet 上實現簡單的、快速開發的機會型 B2B 了。
控制問題
SOA 與已在 IT 行業存在了 30 年甚至更長時間的其他軟件模塊化流程相似。SOA 所不同的硬件和網絡已足夠成熟，可以支持這項基于標準的技術。從任何方面而言，SOA 都不是過去行業內的風行的熱潮技術，但包含了廣泛的行業標準和支持。
SOA 為企業提供了一個機會，以標識其核心能力和決定是否將這些核心能力作為服務向其行業和業務合作伙伴提供。另一方面的事實是；企業可以對作為其核心基礎結構（不是核心能力）一部分的流程和應用程序進行標識，然后確定進行購買。請注意，其中一些服務（提供的或購買的）可能僅為業務流程。企業架構師可以牽頭開展相應的工作，以發現企業中具有公共功能集的業務流程和 IT 流程。可以將執行功能打包為外部依賴性很小的組件，并作為服務提供。這就使得業務流程創建者或應用程序開發人員的工作得到簡化，以將精力放在能滿足股東的業務動力的唯一功能上。
|
|
讓 SOA 正常工作在很大程度上不是技術問題。讓 SOA 正常工作是一個業務控制和 IT 控制問題。
——David K. Jackson |
|
讓 SOA 正常工作在很大程度上不是技術問題。讓 SOA 正常工作是一個業務控制和 IT 控制問題。技術專家可以根據很多存在的成功模式構造一個 SOA 實現。然后讓企業使用這些服務，而不再自己進行創建，這是另一個問題。恰當的體系結構控制將對其服務可供新應用程序使用的項目進行標識。要使得 SOA 投資最終能物有所值，唯一的辦法就是讓高級管理人員承諾控制預算，或采取某種方式保證業務線能不受干擾。IT 架構師還需要向執行股東報告業務從其 SOA 投資和投入方面獲得的價值。
為了讓 SOA 與業務合作伙伴協作，需要涉及企業已經建立的關系。現在，很少（如果有）客戶在其建立的合同關系之外為合作伙伴提供或購買服務。服務級別協議和爭議解決的相關事項要求配備封閉的協作系統。有關信任和安全的結構化信息系統發展組織（Organization for the Advancement of Structured Information Systems，OASIS）標準在過去兩年中取得了長足的發展，但在等式的法律和業務一邊，仍然更傾向于和企業已經了解的伙伴開展此類業務。
這里沒有神話
關于為什么應該考慮 SOA 有三個簡單的理由：
1. 這是目前最熱門的領域之一；不要落后于時代的步伐。
2. 工具、基礎結構和標準經過組合，可為整個 SOA 生命周期提供全面支持。了解我們的端到端編程模型。按照其中提供的詳細步驟開展工作，親身體驗成功。
3. 如果您和我們一樣不斷地追求事半功倍，那么 SOA 可以為您提供幫助。尋找您可以再次利用的東西；不要所有東西都自己從頭做起。尋找現有服務，對其進行調整，并加以使用。然后對其中一些服務進行共享。幫助創建一個生態系統，以便在將來能更快地裝配更多有意義的解決方案。
|
|
可以通過常識來看這個問題。如果您的項目處于十分關鍵的位置，而您的團隊必須投入大量精力學習工具和 API，SOA 就有可能是錯誤的選擇。如果可以在小項目中試用 SOA，則是不錯的選擇。
——Christina Lau |
|
開始采用 SOA 與采用任何其他技術或體系結構沒有什么區別。可以通過常識來看這個問題。如果您的項目處于十分關鍵的位置，而您的團隊必須投入大量精力學習工具和 API，它就有可能是錯誤的選擇。如果可以在小項目中試用 SOA，則是不錯的選擇；利用這個經驗，可以幫助您定義和擴展到下一個更大的項目。循序漸進，這里沒有神話。
只是業務而已
SOA 的支持者不斷不畏余力地宣傳 SOA 的主要技術優勢：松散綁定，能夠通過組件封裝可重用業務功能，最后（但沒有像通常那樣刻意強調）還能提供更好的集成。
包括我自己也是 SOA 的支持者之一，但我不斷在問自己一個問題：客戶真的對這種技術推論感興趣嗎？
在過去兩年，我一直在與希望獲得 SOA 產生的價值主張的客戶全面合作。在與客戶溝通時，我經常發現客戶認為，有很多其他體系結構能提供比我所提到的更多的技術價值。有些客戶可能一廂情愿地得出結論，認為非常有經驗的架構師和開發團隊可以通過使用傳統企業應用程序集成 (EAI) 體系結構獲得很大價值。很多客戶會爭辯說，這些方法經過驗證，實現風險并沒有直接采用 SOA 進行設計的風險大。
|
|
雖然我們不知道其解決方案到底是什么樣的，但應當客觀地看待每一個問題。請同時根據技術指標和業務指標來確定是否采用 SOA。
——Calvin Lawrence |
|
這個觀點可能會讓架構師認識到在有些情況下，SOA 是錯誤的選擇，或者，至少不是最好的選擇。SOA 的技術可行性是否是選擇其作為解決一系列業務問題的體系結構方法的原因？我會說不是：很多業務及 IT 相關的問題（例如缺乏有力的企業控制模型和策略）將減慢或阻礙任何構思良好的技術 SOA 活動的實現。
在最近一次為期三天的 SOA 研討會上，一位汽車行業的首席技術官 (CTO) 告訴我下面的話：“我對 SOA 看法是‘只是業務而已’。”他告訴我他采用 SOA 的原因在于：
- 提高他和他的團隊實現新產品和流程或更改現有項目的速度
- 降低實現和擁有成本
- 通過外包業務元素或從固定定價改為可變定價（根據業務量），從而支持靈活的定價模型
- 簡化合并和收購所需的集成工作
- 實現更好的 IT 使用率和投資回報
這位 CTO 和他的團隊僅關心如何使用其現有的技能（而不必放棄其現有的基礎結構）在預算內按時達成這些目標。他們已經在其現有 EAI 基礎結構中進行了大量投資。
這位特別的 CTO 的話與很多其他人的說法都不一樣。他們只關心關鍵之處：我如何為股東提供回報？
當然，作為一個有經驗的架構師（微笑），我知道一些解決此問題的體系結構備選方案：
- 擴展其現有的 EAI 基礎結構
- 計劃采用更多的事件驅動體系結構（完全分離的、發布/訂閱，等等）
- 或許可采用 SOA
由于這是一個 SOA 研討會，而客戶為此付費，因此我最初準備選擇第三個選項。實際上，對于這個情況，我使用了一點 EAI，一點事件驅動和很多 SOA 方面的東西。SOA 允許在必要時包含 EAI 和事件驅動方法。
對于高速發展的汽車行業，為了保持競爭優勢和按時在預算內提供產品，企業必須具有靈活性。這個客戶的難點集中在對其業務流程進行管理和合并。正如我的同事在此討論中指出的，將 IT 基礎結構與核心業務流程結合，對于達成目標十分關鍵。SOA 相關的原則已被證明可以簡化業務操作，能減少與實際代碼關系很小而集中在人機交互和人員活動上的冗余項。在資金有限的業務環境中，幾乎沒有客戶能為解決特定的業務問題無限制地投入資金，而有時間并愿意對其控制流程進行修整的客戶則更少了。這樣做聽起來不錯，但卻不會實際這樣做。
關鍵在于對現有基礎結構、流程和現有控制模型加以利用和擴展。通過恰當地使用現有 SOA 原則，可以對整個設計和實現流程進行管理，如：
- 標識問題。
- 標識組成業務并是難點所在的流程。
- 對這些流程進行建模，以對其進行簡化。
- 標識現有服務，并編寫表示這些流程的其他服務。
- 將這些服務部署到可提供運行時功能且操作效率高的環境中。
- 監視這些服務和流程，以獲得更高的效率。
那么，網絡呢？雖然我們不知道其解決方案到底是什么樣的，但應當客觀地看待每一個問題。請同時根據技術指標和業務指標來確定是否采用 SOA。如果合適，就使用它。如果不合適，就不用它。SOA 概念和原則將始終可以通過某種方式應用到您的體系結構中。
康莊大道
我們現在都應該知道了整個行業對 SOA 的 ROI 和采用的贊頌之詞——松散耦合、重用更好、推向市場的時間更短、易于集成以及互操作性更好。不過，務必了解，我們目前對 SOA 的關注只是實現即插即用企業（或者說是按需企業）的歷程中重要的一步而已。
隨著我們進入下一個十年，我們將開始著手大幅度減少將來自不同 IT 供應商的產品或組件組合成可行的有價值的端到端解決方案所需的工作量。供應商提供的業務組件將不依賴于基礎結構，可以在各種平臺上執行。因此，軟件開發人員會將更多的精力放在有效集成供應商組件和確保有效的互操作性上。
|
|
IT 業務操作部門所屬的人員將是業務和企業體系結構專業人士。無論您是如何定義業務或企業架構師的：為了實現這個遠景，整個行業將需要更多的具有 IT 和企業體系結構背景的人士。
——Andras Szakal |
|
客戶的 IT 操作部門將主要負責選擇最適合業務需求的運行時平臺；即提供恰當部署和管理業務組件所需的必要服務質量和運行時支持的平臺。
相反，IT 業務操作部門將主要關注如何通過定義業務組件（將由其對應的操作人員部署和管理）中包含業務規則實現組織的業務策略。這將通過 WebSphere Business Process Server 之類的業務流程管理系統完成。
IT 業務操作部門所屬的人員將是業務和企業體系結構專業人士。無論您是如何定義業務或企業架構師的：為了實現這個遠景，整個行業將需要更多的具有 IT 和企業體系結構背景的人士。
雖然這個遠景可能十分誘人，仍然存在很大的風險，在進入組件天堂之前，我們必須小心地減小這些風險。在開始進行實現模型服務的體系結構的任務時，最重要的減小風險方法可能就是要求有強有力的管理良好的控制流程和策略。只有通過強有力的企業服務控制策略才能夠避免更改管理問題、服務間的語義不匹配和系統功能結合方面出現的難于調試的問題。IT 部門可以通過制定的控制策略來減少風險，這些控制策略由執行監督團隊（其中包括 CIO、CTO 和業務線執行官）提出并加以支持。
改善信息
當然，您已經對 SOA 有所了解了。您也知道 Web 服務、業務流程的重要性、模型驅動的體系結構和所有這些讓人誠惶誠恐的 WS-* 標準。
但或許您是一名信息人員。您需要負責組織的信息的完整性和對其進行分析。您關心表示業務狀態的數據庫的性能和穩定性。正如您所知的，真正重要的部分。因此，您可能會問：“為什么我應該關心 SOA？”
|
|
SOA 表示的不僅是服務提供者和使用者的協定，而且也是信息提供者和使用者間的協定
——Dan Wolfson |
|
作為信息人員，我很關心 SOA。我之所以關心 SOA，是因為 SOA 具有直接和間接影響信息管理系統的能力——事實上可以影響信息本身。為了獲得成功，我們需要在業務服務所涉及的信息的上下文中對其進行考慮。我們需要知道檢索到的信息是準確的。被更新的信息經過了驗證。交換的信息的意義對于服務提供者和使用者都是一樣的。如果忽略了這些事情，服務的價值和可重用性就會減少。
直接來說，使用 SOA 時，我們需要在提供者和使用者之間形成一個信息協定，以便讓各方知曉信息意義的內涵，并且仍然支持異構系統——換句話說，我們必須假定世界是雜亂無章的，必須對其進行整理，以提高信息的價值，了解不同的結構和意義之間的關系，并在可能的情況下就公共對象達成一致。
將信息作為服務公開還將讓我們配備額外的信息服務器拓撲來容納增加的信息負載。它還會要求我們建立可以對信息訪問進行虛擬的點（這樣用戶就無需知道信息的真正位置以及其組織方式）。它還引入了一些方法，允許我們有效地對這些信息進行組合——通過集合或聯合。如果沒有建立更多的公共機制或引入經過改進的清除機制，則我們稍后很可能被迫投入巨額的額外資金和資源進行清除，從而導致將來的靈活性下降。
可以采用很多辦法實現信息協定。其中一個變得越來越重要的就是主數據管理 (MDM) 領域。MDM 系統可為業務應用程序或服務提供經過清除、整合且特定于域的信息。最常見的 MDM 系統是作為客戶和產品信息的信息集線器使用的系統。每個集線器都作為中心點使用，可以在此對信息進行添加、更新、審核、清除、搜索和查詢。集線器放置于可以將更改傳播到相關數據庫或可以生產相關服務的事件的位置。MDM 系統可以是事務型的（在操作業務流程的主線中更新），也可以是引用型的（提供業務流程所引用的信息的一致來源）。但最重要的是，我們可以將 MDM 系統看作其本身提供了一個一致的服務集，以供在各種業務流程內使用和進行重用。
通過 MDM 等方法顯式地實現信息提供者和使用者之間的協定，可以幫助我們實現 SOA 所承諾的靈活業務流程和服務可重用性，并同時為我們提供提高所管理信息的質量的機會。
適合與不適合的場合，以及需要注意的地方
SOA 是一種組織化的方法，用于應用到由面向服務和分布式對象計算組合而成的應用程序體系結構中。讓我們來將這個定義分為幾部分進行分析。應用程序體系結構 是應用程序各部分的寬泛組織，通常作為層實現。體系結構指定包含哪些部分以及它們如何一起工作。面向服務將功能封裝為服務——寬泛的可重用任務，可以在沒有任何前一上下文（除承載服務的系統的當前域狀態外）的情況下運行。服務的上下文是作為從調用方傳遞的參數提供的，和函數調用的參數非常相似。分布式對象 以特定方式運行在獨立進程中，通過這種方式，一個進程中的對象可以調用另一個進程中的對象上的方法。
|
|
服務支持對訪問通過寬泛任務的經過良好定義的 API 公開的已良好封裝的功能，從而可以通過低頻率的調用實現功能的高重用性。SOA 或許是所有方法中最好的一個。
——Bobby Woolf |
|
SOA 向分布式對象添加面向服務，從而可以在進程之間調用服務。它是一種用于設計應用程序體系結構的方法，以便應用程序的各個部分可以在不同的進程中運行，而且還允許不同的應用程序共享和重用正在運行的部分。它是分布式對象計算的演變，用以在多個對立方之間獲得更好的平衡：需要訪問彼此功能的應用程序；需要封裝自己功能的應用程序；需要限制在其應用程序編程接口 (API) 中描述的對外公開的功能的應用程序；需要限制分布式調用的交互應用程序。服務支持訪問通過各種任務定義良好的 API 公開的封裝良好的功能，從而可以通過低頻率的調用實現功能的高重用性。SOA 或許是所有方法中最好的一個。
以下給出了一些簡單的技巧，用以確定何時采用 SOA 和何時不應采用 SOA 以及需要提高警惕的情況。
首先，適合采用 SOA 的情況：
- 當數據分布程度非常高時，使用 SOA。將操作數據的代碼放置在與數據較近的位置，然后將其包裝為服務，以供在任何地方進行訪問。
- 希望功能具有高可用性時，使用 SOA。將功能作為服務部署在多個冗余的提供程序中，以在其中一些不可使用時，可以使用其他的對等服務。
- 當應用程序的各個部分需要獨立開發、維護和更新時，使用 SOA。只要保持各個部分之間的接口，每個團隊（如兩個不同的 B2B 公司）就可以使用其喜愛的技術按照自己的計劃實現各自的部分。
- 當多個應用程序需要重用功能和數據時，使用 SOA。共享的代碼僅重用功能；服務則允許各個獨立應用程序重用一組共享的企業數據，而無需將數據分發給所有應用程序。
以下是不適合使用 SOA 的情況：
- 當希望開發盡可能簡單時，不要使用 SOA。使用一種語言實現，在單個線程中運行，且沒有遠程訪問問題的應用程序復雜性較低一些，因此構建和調試更為方便。
- 當希望操作環境盡可能簡單時，不要使用 SOA。要對松散耦合、事件驅動的分布式應用程序進行故障排除要困難得多，要求對應用程序實現細節和操作環境配置細節及其當前狀態有全面的了解。
- 當網絡不可靠或網速慢時，不要使用 SOA。服務組件運行于獨立的計算機上，通過網絡進行通信，因此，其速度和可靠性依賴于這些計算機及連接這些計算機的網絡。
（注：分布式冗余服務可以幫助減少硬件不可靠和網絡延遲的影響。）
- 進行原型設計時，不要使用 SOA。原型開發應該簡單，而 SOA 并不簡單。
對于何時需要提高警惕的問題，坦白地說，隨時都要提高警惕才行。以下是一些需要謹慎行事的具體情況：
- 當服務接口不確定時，使用 SOA 需小心。服務接口允許使用者和提供者獨立地進行更改，但接口本身必須穩定。SOA 中的接口變化比在單個應用程序（特別是非分布式應用程序）中復雜得多，因為有很多在其他情況下不相關的開發團隊必須就接口的更改進行合作。
- 當安全性極為重要時，使用 SOA 需小心。每個服務都是一個新的易受攻擊的點，必須保證其安全性。可以輕易訪問服務的人越多（如在公共 Internet 上的服務），可以嘗試攻擊該服務的人就越多。
- 當性能極為重要時，使用 SOA 需小心。進程之間的每個服務調用都比進程內的方法慢得多。
- 希望功能具有高可用性時，使用 SOA 需小心。正如所指出的，冗余服務可以提高可靠性；但同時，活動部分越多出現故障的可能性就大。SOA 應用程序只與其服務一樣可靠。
這些列表根本不足以包含所有方面，但我希望這能讓您更好地了解什么是 SOA 以及適合使用 SOA 的情況。如果您需要這方面的專業幫助，請訪問 IBM Software Services for WebSphere，在其中可以找到各種參考資料。
祝您好運！