引言
雖然 SOA 可以帶來許多好處，但同時也可能受到以下一個或多個問題的困擾：
- 高復(fù)雜性和短上市時間，這樣會增加失敗的風險
- 由于高成本和量化投資回報 (ROI) 困難而導(dǎo)致較難容忍出現(xiàn)錯誤
- 需要恰當管理的動態(tài)要求和業(yè)務(wù)需求
如果您使用了軟件方法——軟件開發(fā)的系統(tǒng)方法——來在初始 SOA 推出期間提供所需的嚴格控制和過程，并在優(yōu)化 SOA 的過程中進行調(diào)整，就可以避免這些問題。在考慮此處給出的軟件方法之前，請閱讀本系列的第二篇文章，該文指出，在面向服務(wù)的體系結(jié)構(gòu)成熟度模型的第 3 級或第 4 級的“面向服務(wù)的體系結(jié)構(gòu)成熟度模型”組織應(yīng)使用 RUP 等正式的軟件方法進行開發(fā)工作。只要達到了第 5 級，他們就應(yīng)該使用 XP 之類的靈活方法了。
您的企業(yè)如何在保持開發(fā)過程一致的前提下過渡到較高的成熟度級別呢？本文將介紹一種最佳組合的方法，面向服務(wù)的統(tǒng)一過程 或 SOUP，用于開展構(gòu)建工作并隨后進行持續(xù)優(yōu)化。在繼續(xù)閱讀本文之前，您應(yīng)當對 RUP 和 XP 的工作方式有基本的了解。請參閱參考資料，以獲得可幫助您了解相關(guān)知識的鏈接。
什么是 SOUP？
SOUP （Service-Oriented Unified Process）是一種使用 RUP 和 XP 中的最佳部分來構(gòu)建和管理 SOA 項目的軟件方法。它的目標是任何組織中正在進行的 SOA 項目。
典型的軟件開發(fā)項目包含應(yīng)用程序開發(fā)過程、項目管理以及所使用的技術(shù)。此外，軟件開發(fā)項目通常具有四個變量：時間、預(yù)算、范圍 和質(zhì)量。任何一個變量的變化對整個項目都有影響。不斷變化的業(yè)務(wù)需求使得范圍和質(zhì)量成為兩個最難管理的因素。技術(shù)復(fù)雜性可能導(dǎo)致時間和預(yù)算管理方面出現(xiàn)問題。
SOA 項目比通常的軟件項目復(fù)雜得多，因為它們要求配備更大的跨功能的團隊，并且還有因此而帶來更復(fù)雜的團隊間溝通和日常管理工作。
雖然 SOA 可以為組織帶來許多好處，但同時也可能帶來很大的成本支出和時間消耗。如果項目沒有經(jīng)過良好定義，并且在項目啟動時沒有關(guān)于最終結(jié)果的遠景，則失敗的可能性就非常大。
可以幫助 SOA 成功完成的關(guān)鍵因素有：
- 明確定義的開發(fā)過程
- 與業(yè)務(wù)相關(guān)的項目團隊之間增強的溝通渠道
- 明確的支持和控制策略
在初始開發(fā)過程中，采用正式軟件方法是盡可能地減少已確定的風險的最好辦法。成功建立了 SOA 項目后，可利用正式的維護和增量開發(fā)方法來增加項目的 ROI。然而，XP 之類的靈活方法可能不夠正式，不適合在初始階段使用。SOUP 方法可幫助減少 SOA 推出階段的風險，并能讓您隨后進行持續(xù) SOA 優(yōu)化工作。
SOUP 是一個由六個階段組成的軟件開發(fā)方法。每個階段代表對于 SOA 成功推出非常關(guān)鍵的一組特有的活動。當然，和在任何項目中一樣，您將需要根據(jù)所在組織的情況對相關(guān)過程進行調(diào)整。
圖 1 顯示了 SOUP 過程。此方法也沒有非常特別的地方：所有軟件或 SOA 項目都是采用類似的方式定義的。
圖 1. SOUP 過程模型
我將 SOUP 過程分為兩類：
用于初始 SOA 部署的 SOUP
圖 2 顯示了用于初始 SOA 部署的 SOUP 的各個階段。
圖 2. SOUP 與 RUP 模型
每個階段都包含主要交付內(nèi)容和活動：
初始
在此階段，將確定組織對 SOA 項目的需求。您可以通過應(yīng)用 SOA 成熟度模型來確定組織的體系結(jié)構(gòu)成熟度水平并確定 SOA 的驅(qū)動因素。此時，您將需要向為業(yè)務(wù)服務(wù)的所有項目團隊說明 SOA 的基本概念，并擬訂與反饋和建議流程有關(guān)的策略計劃。
此階段的主要交付內(nèi)容有：
-
SOA 遠景和范圍：給出項目的整體遠景。它還提供了確定項目范圍的邊界，該范圍至少應(yīng)包含兩個業(yè)務(wù)線或項目。
-
SOA 策略：說明項目將如何執(zhí)行的概略計劃。
-
ROI 分析：給出此項目將帶來的成本支出和節(jié)省情況。
-
溝通計劃：說明 SOA 團隊將如何與其他項目團隊和業(yè)務(wù)用戶進行溝通。
客戶（即業(yè)務(wù)干系人）通常并不能完全了解新軟件產(chǎn)品可以帶來的好處。定義 SOA 策略的企業(yè)團隊需要利用項目團隊的專業(yè)知識來幫助確定業(yè)務(wù)問題以及簡化操作的方法。
跨功能分析人員和項目管理人員將對客戶的業(yè)務(wù)進行分析，以確定基于 SOA 的解決方案的優(yōu)勢。分析人員將對客戶的內(nèi)部操作進行研究，此外還要分析其與合作伙伴、供應(yīng)商以及他們的客戶的交互情況，而且也會研究其總體業(yè)務(wù)模型。這些因素有助于分析人員制定 SOA 策略并向客戶推薦。
在此階段，您還需要對推薦的 SOA 策略進行全面的 ROI 分析。此分析應(yīng)當清楚地表明短期、中期和長期的成本優(yōu)勢。
此階段最重要的交付內(nèi)容是溝通計劃。項目 IT 團隊和業(yè)務(wù)干系人比體系結(jié)構(gòu)團隊和分析人員更了解業(yè)務(wù)。溝通計劃可以確保這些內(nèi)部干系人能夠理解并參與到開發(fā)過程中來。
定義
到目前為止，定義階段是 SOA 項目中最為關(guān)鍵的階段。此階段業(yè)務(wù)和項目團隊的參與將最終決定項目的成功。團隊成員需要積極地參與到作為初始 SOA 推出的一部分開發(fā)的需求定義和用例方面的工作中來。
項目生命周期的此階段的活動包括：
- 收集需求
- 分析需求
- 定義非功能需求
- 制定項目計劃，其中包含時間安排和項目估算
- 定義技術(shù)基礎(chǔ)設(shè)施
- 定義和實現(xiàn)用例
- 定義和記錄總的體系結(jié)構(gòu)
此階段的主要交付內(nèi)容有：
-
功能需求文檔：詳細描述 SOA 將作為業(yè)務(wù)服務(wù)提供的所有業(yè)務(wù)流程。
-
非功能需求文檔：包括性能注意事項、服務(wù)水平協(xié)議 (SLA) 和基礎(chǔ)設(shè)施要求。
-
用例和用例實現(xiàn)：詳細說明將構(gòu)建的所有業(yè)務(wù)服務(wù)的用例。
-
SOA 體系結(jié)構(gòu)文檔：描述項目總的體系結(jié)構(gòu)，包括硬件和軟件組件。
-
SOA 適用性文檔：說明哪些項目將在 SOA 項目的范圍內(nèi)以及如何在 SOA 的基礎(chǔ)上構(gòu)建后續(xù)項目。
-
基礎(chǔ)設(shè)施定義文檔：包括詳細的基礎(chǔ)設(shè)施部署圖，其中列出相關(guān)服務(wù)器以及實現(xiàn) SOA 所需的服務(wù)器的連接和連接位置。
-
項目計劃：整個項目的詳細計劃，包括里程碑和依賴關(guān)系。
-
支持和控制模型：描述將如何支持和控制 SOA。其中包括各種注意事項，如 SLA 監(jiān)視和管理。
研究（請參閱參考資料）表明，與需求相關(guān)的問題是軟件項目失敗的首要原因；SOA 項目也不例外。軟件質(zhì)量 有時定義為軟件對其需求的滿足情況。但是，測定軟件質(zhì)量的更好辦法可能是通過其滿足的需求的質(zhì)量 測定，而不是通過其滿足的需求的數(shù)量 測定。
在明確說明了交付內(nèi)容后，SOUP 方法將建議一個用于進行需求收集和管理的正式流程。XP 并不定義用于收集和記錄需求的正式流程；而 XP 開發(fā)人員將創(chuàng)建一些用戶案例（請參閱參考資料）并按邏輯順序?qū)@些案例進行排列，以提供一個需求序列。在此開發(fā)階段，這樣的流程并不夠用。在 RUP 中，相應(yīng)的流程更為詳細，并使用更多的正式技術(shù)來確保舉行相關(guān)的需求收集會議、對需求進行記錄并加以驗證。我建議使用需求存儲庫，該存儲庫將與用例、設(shè)計和代碼緊密結(jié)合，以在項目進行的整個過程中提供可跟蹤性。該存儲庫可以為 IBM Rational? RequisitePro? 工具或您組織選用的任何其他需求管理工具。更改管理流程也很重要。
此階段最重要的交付內(nèi)容是支持和控制模型。組織將如何支持 SOA？控制指導(dǎo)方針有哪些？如果推出了一個 SOA，但沒有人使用，則項目就失敗了。支持和控制模型文檔可以防止發(fā)生這種情況。
企業(yè)應(yīng)當在制定了真實可行的計劃和目標的情況下啟動項目。其他需求應(yīng)留待以后解決。如果在預(yù)期的時間和預(yù)算內(nèi)，可以完成有關(guān)需求的有效業(yè)務(wù)-IT (B2IT) 協(xié)作，則可以幫助確保項目的成功。
請在項目早期定義支持整個 SOA 所需的技術(shù)基礎(chǔ)設(shè)施。這包括服務(wù)器、網(wǎng)絡(luò)基礎(chǔ)設(shè)施和培訓要求方面的詳細評估。
設(shè)計
在設(shè)計階段，您將對定義階段確定的設(shè)計構(gòu)件進行細化。用例實現(xiàn)和軟件體系結(jié)構(gòu)文檔將轉(zhuǎn)化為詳細的設(shè)計文檔。
此時，SOA 架構(gòu)師（通常為企業(yè)架構(gòu)師中的一部分）需要與項目架構(gòu)師合作，以確保 SOA 團隊給出的設(shè)計可以供具體的項目使用。SOA 架構(gòu)師甚至可能選擇完成一些概念驗證 (proof-of-concept) 項目，以證明 SOA 遠景。此階段的主要交付內(nèi)容有：
-
詳細設(shè)計文檔：描述如何設(shè)計和構(gòu)建服務(wù)。
-
應(yīng)用程序編程模型：提供有關(guān)設(shè)計開發(fā)項目的結(jié)構(gòu)的指南。涉及的主題包括使用的流程和技術(shù)、編碼標準以及部署過程。
-
數(shù)據(jù)庫模型：包括 SOA 使用的數(shù)據(jù)庫的實體關(guān)系圖。
-
測試和 QA 計劃：詳細說明測試和 QA 計劃，并在其中包括測試用例。
構(gòu)造
在構(gòu)造階段，將使用您選擇的迭代構(gòu)建方法來構(gòu)建 SOA。此階段中包括新的開發(fā)和集成活動。您的活動不僅限于軟件方面，還涉及到與基礎(chǔ)設(shè)施相關(guān)的子項目，如硬件整合項目或服務(wù)器承載集中化工作。雖然整個工作是在單個 SOA 項目中進行管理的，但仍然很有可能將由各種小型子團隊進行不同的構(gòu)造活動。
項目生命周期的此階段將涉及到各種活動，如：
此階段的主要交付內(nèi)容有：
-
基本代碼：該代碼應(yīng)存儲在某類源代碼管理存儲庫中。
-
測試結(jié)果：執(zhí)行測試用例和 QA 計劃的結(jié)果應(yīng)可供進行檢查分析。
-
文檔：文檔中應(yīng)包含關(guān)于代碼以及對設(shè)計文檔的任何更新的詳細信息。
部署
在部署階段，您將向各個項目團隊推出 SOA，這些項目團隊將開始在其生產(chǎn)環(huán)境中的項目上使用此 SOA。此階段最明顯的主要交付內(nèi)容或許就是投入生產(chǎn)環(huán)境中使用的應(yīng)用程序。然而，SOA 試驗項目的計劃卻是更為重要的交付內(nèi)容。這將導(dǎo)致進入 SOUP 方法的下一個步驟，該步驟將確定后續(xù)項目如何使用新體系結(jié)構(gòu)。此階段的其他主要交付內(nèi)容有：
-
部署模型：給出總的 SOA 部署結(jié)構(gòu)。
-
用況模型：提供有關(guān)如何使用 SOA 的指南。隨著各個項目團隊和業(yè)務(wù)線開始使用新體系結(jié)構(gòu)，此模型會變得非常重要。
-
后續(xù)支持級別模型：將對定義階段開發(fā)的支持和控制模型的任何更新進行系統(tǒng)化。
支持
軟件開發(fā)周期的這最后一個步驟非常重要。在支持階段，您將確保提供后續(xù) SOA 支持、錯誤修正和進行新功能開發(fā)。項目生命周期的此階段將涉及到各種活動，如：
您的 SOA 現(xiàn)在已經(jīng)投入生產(chǎn)了。但項目團隊如何從該體系結(jié)構(gòu)受益呢？為了構(gòu)建使用現(xiàn)有服務(wù)的應(yīng)用程序，或設(shè)計使用現(xiàn)有 SOA 的新服務(wù)，他們是否需要遵循上面詳細列出的所有步驟？正如您將在下面的部分中看到的，實際上，他們可以從一個更為輕量級的方法中獲益。
用于后續(xù) SOA 管理的 SOUP
SOUP 方法可以用于那些使用已經(jīng)推出的 SOA 的項目。在這種情況下，SOUP 對 XP 進行了大量的參考。圖 3 表明了 SOUP 和 XP 過程彼此重疊。
圖 3. 重疊的 SOUP 和 XP 過程
這種方法主要帶來什么樣的好處呢？SOA 項目的價值在于，它可提供良好定義的體系結(jié)構(gòu)和嚴格的技術(shù)指南。您獲得了一個框架，可以在其中以服務(wù)的形式構(gòu)建應(yīng)用程序。項目團隊的主要任務(wù)是構(gòu)建和使用服務(wù)。他們最適合執(zhí)行這些任務(wù)，因為他們具有必要的業(yè)務(wù)領(lǐng)域知識。但是，他們并不需要考慮技術(shù)體系結(jié)構(gòu)或技術(shù)的創(chuàng)新，因為這些任務(wù)將由 SOA 團隊完成。
此類項目將遵循上一部分中列出的相同 SOUP 指南；不過，您將發(fā)現(xiàn)，每個階段的工作量都大幅度地減少了。這一部分的許多交付內(nèi)容都和前面描述的一樣；必要時，我會說明它們與從頭構(gòu)建 SOA 時的項目中的對等項之間的差異。
初始
啟動 SOA 并運行后，仍然需要進行一些開發(fā)工作。您無疑將希望構(gòu)建使用現(xiàn)有服務(wù)或公開新服務(wù)的項目。初始階段的主要交付內(nèi)容有：
-
項目遠景和范圍：這僅包含單個項目的范圍，而不包含更大的 SOA 計劃的范圍。
-
項目策略：描述此具體項目的策略和流程，并說明其如何利用 SOA。
-
ROI 分析：項目的詳細成本優(yōu)勢分析，這對于幫助進行與實現(xiàn)有關(guān)的決策非常關(guān)鍵。
定義
在定義階段，您將構(gòu)建與 SOA 項目有關(guān)的各項內(nèi)容，并了解如何利用 SOA。您需要標識 SOA 可以提供的服務(wù)和仍然需要構(gòu)建以滿足您的項目目標的服務(wù)。
項目生命周期的此階段的活動包括：
- 收集需求
- 標識服務(wù)
- 制定項目計劃，其中包括時間安排和項目評估
- 開發(fā)測試用例
此階段的主要交付內(nèi)容有：
-
功能需求文檔：軟件項目的典型需求文檔。
-
用例和用例實現(xiàn)：涵蓋所有正在構(gòu)建的新業(yè)務(wù)流程。
-
SOA 適用性文檔：說明現(xiàn)有 SOA 框架如何應(yīng)用到此項目。
-
項目計劃：詳細說明整個項目，包括里程碑和依賴關(guān)系。
-
服務(wù)策略：標識已經(jīng)存在并能夠使用的服務(wù)以及可以公開的新服務(wù)。
-
測試計劃：其中包括項目的測試用例。
在此階段，您不需要嚴格遵循在 SOA 推出期間遵循的正式需求收集標準。相反，可以通過用戶案例或類-責任-協(xié)作者（Class, Responsibilities, Collaborator，CRC）卡（請參閱參考資料）來簡化需求收集。根據(jù) XP 的思想，測試案例是在這種類型的項目的早期構(gòu)建的。
設(shè)計
此階段可以迅速完成，因為大部分服務(wù)都在初始 SOA 推出時已經(jīng)完成。在設(shè)計階段，只需要關(guān)心如何使用這些服務(wù)，需要在現(xiàn)有服務(wù)的基礎(chǔ)上構(gòu)建什么功能，以及需要構(gòu)建哪些新服務(wù)。
此階段的主要交付內(nèi)容有：
-
詳細設(shè)計文檔：說明您的設(shè)計如何利用總體 SOA，并建立設(shè)計與應(yīng)用程序編程模型。
-
數(shù)據(jù)庫模型：封裝供此特定項目使用的邏輯和物理數(shù)據(jù)設(shè)計。
構(gòu)造
構(gòu)造階段涉及更多的是裝配，而不是新部署。隨著提供的服務(wù)越來越多，每個項目都將有越來越多的可重用服務(wù)，而需要構(gòu)建的新服務(wù)也就越來越少。XP 的迭代開發(fā)技術(shù)是此開發(fā)階段的最佳選擇。在 XP 中，理論上的迭代周期設(shè)置為兩周，當在 SOA 環(huán)境中構(gòu)建小型服務(wù)和使用一組服務(wù)時，這一時間對于一個開發(fā) Development-QA 周期來說絕對足夠了。使用此迭代方法，SOA 可以通過快速軟件發(fā)布提供有價值的業(yè)務(wù)靈活性。
項目生命周期的構(gòu)造階段的活動包括：
此階段的主要交付內(nèi)容有：
-
新服務(wù)：在本階段結(jié)束時，任何將要公開的新服務(wù)都會準備就緒。
-
測試結(jié)果：執(zhí)行測試用例所得到的結(jié)果應(yīng)提供給所有相關(guān)方。
-
文檔：此開發(fā)階段應(yīng)產(chǎn)生詳細的代碼文檔以及對以前創(chuàng)建的其他文檔的所有必要更新。
部署
在此階段，將啟動使用多個服務(wù)的應(yīng)用程序，或啟動新服務(wù)。由于基礎(chǔ)設(shè)施是由 SOA 團隊進行管理的，因此該流程相對比較簡單。
支持
在此階段，將僅為您的新服務(wù)提供支持。在進行此項工作的過程中，請遵循在原始 SOA 項目期間制定的支持指南。單個項目不需要花很多時間制定新的支持指南。
管理 SOA 生命周期
本文向您介紹了 SOUP，這種新的軟件方法可用于構(gòu)建 SOA 并將此體系結(jié)構(gòu)的好處帶給各個項目。文中說明了可以如何使用類似于 RUP 的正式方法來對 SOA 進行初始構(gòu)建，然后轉(zhuǎn)向 XP 樣式的靈活流程，以進行后續(xù)服務(wù)推出工作。通過實現(xiàn)這兩個過程的最佳組合，您可以依靠一個統(tǒng)一的開發(fā)模式來進行相關(guān)工作，此模式可提供足夠的靈活性，以便對 SOA 生命周期的不同階段進行管理。