<!--[endif]-->
<!--[if !vml]-->
<!--[endif]-->
圖1：共享服務生命周期的設計和運行時階段
SSLC中的設計時注意事項
現在我們來看看共享服務周期的設計時方面。提到設計時，我主要關注服務投入生產和使用之前的生命周期。本文不涉及設計時建模的許多需求，如開發服務建模方法學，但如有興趣，我將在未來的文章中闡述這一主題。
確定業務流程
SOA的一個核心原則是業務和IT保持一致以及建立競技場(playing field)。通過識別企業通過服務定位提供價值的業務流程，服務工程團隊(通常是業務、分析師和IT人員的組合)可能在討論的出發點方面達成一致。
許多企業發覺很難理解從何處開始SOA以及哪些是最合適的業務流程。一種好的方法是首先在白板上定義需求目錄。將白板劃分為3條泳道，分別代表短期需求(3到6個月——通常本質上更有戰術性)，中期需求(6到18個月)和長期需求(超過18個月——通常為戰略需求，可能隨業務需求的變化而變化)。劃分泳道之后，開始為每個區域添加需求。盡量避免按應用系統(如，電子商務網站)思考;看得越遠，越有可能達到您要求的高度(例如，我需要完善自己的清單系統)。在生命周期的這一階段，主要著眼于可能成為業務組成部分的業務流程，如電子商務站點。
完成初步分析之后，服務工程團隊可能開始尋找依賴性，試圖決定優先級、揭示重用可能性或確定需求之間的依賴性。觀察下面的需求目錄示例，可以看到對于該企業來說，最初集中在用戶注冊流程上是再合理不過了，因為許多其他流程依賴于該流程，而且它可以在整個電子商務功能和企業內部網中重用。
<!--[if !vml]-->
<!--[endif]-->
圖2：需求目錄示例，它向服務工程團隊提供了實現公司未來狀態的路線圖
根據公司在服務設計和開發方面的成熟度，選擇首先開發哪種服務可能很自然地導致構建沒有很多依賴性的服務，同時積累經驗。盡管這些想法是對的，但是在企業成熟度中，熟悉增強重用的服務建模技術是很重要的，如強大的契約和策略定義。服務工程團隊必須意識到重用概念以前曾在業務中提到過多次，但沒有多大成效。由于相對于傳統應用程序生命周期來說，服務開發周期較短，服務工程團隊有能力從短期目錄創建一系列可以跨計劃快速利用的基礎服務，從而實現早期的成功。
無論如何，對初始服務（特別是依賴服務）的選擇應與服務工程團隊的能力相一致。這是很重要的。新的團隊需要時間才能在SSLC的設計階段具有更多經驗。在服務目錄中確定的依賴服務可能由于具有較高的重用水平，看似是一個好的侯選服務，但是不適合于尚未成熟的團隊。若一個服務已涉及到跨業務線、提供企業級功能或遵守嚴格的服務質量規章的依賴性，則它可能不是一個理想的初始侯選服務。
另一方面，對于一個具有已定義流程和已知端點的服務，如果這些端點是受控的、成熟的并且范圍很小，在必要的情況下，服務本身的離散程度足以構建或重構，那么在很短的時間內，這種服務是初始開發的主要侯選服務。這樣的初始服務應該可以很快地驗證假設、方法學和流程。正確的設計需要經驗和實踐。反復進行試驗并糾正錯誤，尤其在SOA計劃的成型階段，這種方法是判斷在您的企業內哪些SOA實踐可以發揮作用的重要機制。早期選擇沒有依賴性的孤立服務可能會限制服務工程團隊在成型階段獲取更多的學習機會。
服務設計和建模
服務設計和建模階段的目標是，基于需求目錄中確定的業務流程建立一種定義侯選服務的一致方法。真到開始做的時候，服務工程團隊通常用白板描繪業務流程、分解步驟以及討論當前和未來的需求。為此，一致的設計方法學應該使用業務和IT均可理解的常用語言來建立。
服務設計方法學為服務工程團隊提供了一系列用于分解業務流程的步驟或活動，基于面向服務的設計原則確定服務中開發哪些方面是合理的。對于這種設計方法學，許多企業最初有一些爭執，尤其是服務粒度。過細的粒度可能產生不可重用的服務增殖；過粗的粒度，又很難著手。在團隊對建模流程滿意之前，它應該將其活動集中在定義良好的業務流程中，這些業務流程可能并沒有較大企業需求（如高生產量、長期事務）。
盡管從技術上來說不是建模階段的一部分（但可能是建模方法學的一部分），但我的經驗表明：在定義服務分類原則方面投入時間對企業來說是很重要的。這些指導方針應該定義服務的哪些方面決定了服務是業務線（LOB）或應用程序級服務，還是具有特殊需求的企業服務。這些指導方針可能包括生產量、服務質量（QoS）、正常運行時間、服務關鍵程度以及多少客戶將使用該服務。另外，開始定義與建立和管理服務相關的企業治理控制時，這些指導方針至關重要。開發指導方針可能本身是貫穿始終的工作，但開頭很簡單，只定義當前需求所要求的部分就可以。而且，服務分類可能有助于將相似功能分組并確認這些功能的業務所有者。記住，后續出現新的需求時可以重新調整指導方針。
<!--[if !vml]-->
<!--[endif]-->
圖3：服務分類及其與SOA治理的關系；此分類可能有助于定義SOA資產的企業治理控制。
根據服務目錄示例，企業可能已經建立了企業服務和業務線服務類別。以下進行詳細描述。
企業服務
企業服務具有水平影響，可能包括：
- 無論在是周邊或核心部門，安全性都需要符合行業規范。
- 活動審計。記住審計可能是某一特定功能的一個方面，如外匯交易，而不是進行交易的流程。
- 一般異常處理。
- 服務要求24x7可靠性，并且必須據此進行治理。
- 服務要求大容量和（或）低延遲吞吐量。
- 根據使用環境，服務可能要求更高級別的客戶服務或響應時間。例如，客戶個人信息表明他們是貴賓客戶，則服務契約會要求不同的SLA。
- 若服務要求跨業務線進行交互，則可能具有必須滿足的企業基礎架構需求。
- 服務與企業數據進行交互。這方面可能意味著企業擁有通用模型，而具體用戶數據存儲的實現則由業務線控制。經驗和實踐表明，大量的用戶數據存儲存在于企業中。SOA目標的一部分就是為了長期鞏固這些方面，但在定義未來計劃時，不應脫離現實，而是要充分利用現有資源。
業務線服務
這些服務具有垂直影響，可能包括：
- 特定業務功能，如采購單（PO）或新的租賃處理。
- 具有特定UI和外觀的表示服務，或者通常用于提供某一特定業務功能的可視化表示的向導。
- 支持業務線的CRUD（創建、讀取、更新、刪除）活動的信息和訪問服務。
- 應用服務，如基于特定業務線數據的銷售跟蹤或預測。
此分類并不完整，但應該可以提供企業如何開始分類工作的概念。
通過檢查以上類別，可將以前定義的需求目錄中的某些侯選服務放至治理組中，并識別出以前并不明顯的許多典型結構：
|
企業服務
|
業務線服務
|
|
登錄企業內部網（內部網基礎架構主要由IT或特殊的LOB管理）
|
|
更新個人信息（個人信息范例）
|
更新個人信息（服務）
|
|
登錄電子商務網站
|
|
銷售人員個人信息范例
|
創建銷售人員個人信息
|
|
清單項范例
|
購買電影
|
|
清單項范例
|
購買書籍
|
|
查看我的訂單狀態
|
|
支付范例
|
提供支付信息
|
|
清單項范例
|
出售書籍
|
|
查看企業新聞
|
|
清單范例
|
檢查電影清單
|
|
清單范例
|
檢查書籍清單
|
|
檢查所有清單
|
|
|
整合清單系統（通常按實際服務進行長期計劃）
|
|
服務生命周期主要是為了解決業務需求問題，而不是過度陷于具體的分類練習。SSLC評估階段是為了支持基于實際應用和環境的再評估。我想到電影《夢幻之地》中凱文·科斯特納聽到的聲音重復說：“你蓋好了，他們就會來”。這與在企業中公開服務沒有什么區別。在某一時間點上以某一使用級別定義的內容實際上可能會以完全不同的方式使用，也就是通常在最初設計時并未考慮到的方式。指導方針在重分類階段應該有所幫助。
在流程的這一階段，我主要談論侯選服務與服務實現的概念。Erl（2004）建議侯選服務是潛在的服務，這些服務可能在最后的設計中實現，也可能不實現。設計流程是為了確定設計和開發的未來階段的輸入。理解企業中哪些服務已存在以及哪些需要開發對服務工程團隊來說特別重要。支持服務發現的工具（如兼容UDDI的注冊庫）是促進服務重用和了解現有可用資源的重要組件。
最后，在建模階段，隨著逐漸理解了團隊正在定義侯選服務，服務工程團隊應通過獨立于技術架構和物理環境約束的已確定方法學繼續進行設計。服務設計和建模階段的目的就是定義期望的未來狀態。SSLC的構建和組合階段將使侯選服務遵守組織約束以定義最后的服務實現。
構建和組合
為更加快速經濟地開發新的功能，服務生命周期的構建和組合重點集中在開發新服務以及利用企業中現有資源所要求的任務上。這一方法可以縮短上市時間，從而實現SOA的一項關鍵財務收益。
在本階段，服務建模和設計階段確定的侯選服務被具體化成服務操作，并將基礎架構和環境實體映射到它們。正如在建模階段提到的，確定SOA計劃的目標是很重要的。由于當前環境的限制，實現這些目標可能比較困難，但是可能會促進某些良性討論以及某種成本利潤分析，從而確定如何實現期望的未來狀態。但是，現在的企業需要繼續發展，所以您的侯選服務在企業環境中必須具有現實意義。
理解了哪些服務操作和實現比較現實之后，就可以著眼于重用的可能性以及在上一階段確定的組合。要充分利用SOA，組合的概念對業務敏捷性來說非常重要。開發環境和服務基礎架構工具必須推動設計時發現服務，并可組合這些服務，完成整個業務流程。
沒有這些工具，SOA計劃的成功可能會受到阻礙。隨著初始服務對業務線團隊和其他工程團隊可用，組合的機會可能得以實現。在這種情況下，在分類的同時已確定了初始依賴性。這些依賴性應描述為構建組合服務的直接可能性，并應提供重用的切實收益。本文中只稍微提到了組合，但這些活動的重要性與SSLC的構建和組合階段直接相關。
考慮需求目錄示例：一個稱為整合清單系統的計劃已在長期目標中確定。在第一次瀏覽時，該任務可能被描述為物理上廢棄舊清單系統，并將存儲庫整合到一個主數據源中。盡管可能真的會是這樣（如果成本利潤分析表明廢棄舊系統更加經濟有效的話），活動也可能表述為一種沒這么具體的形式。服務工程團隊可能產生一系列邏輯數據服務，對客戶隱藏物理端點。構建普適數據訪問層的這一方法將通過組合直接利用在中期需求目錄中開發的現有檢查清單X服務。整合清單系統計劃可能要求根據清單文檔的典型表示來決定哪些端點需要修改。這種分散式CRUD邏輯應在“服務基礎架構工具”中提供，這樣的一個示例是BEA AquaLogic Data Services Platform。
通常，服務起源于業務線級別而不是通過企業計劃，因為一般情況下這是驅動項目建立和需求的地方。結果，“你蓋好了，他們就來了”方案可能導致設計時發現的服務不是良好的重用侯選服務。它們可能不提供足夠的性能或一致模式。盡管它們在企業中可用，但仍為應用程序級服務。最后，企業必須開始創建管理流程以控制服務的企業可見性。在通常情況下，服務注冊提供確保服務質量的管理機制和流程。這些問題必須在服務生命周期的發布和準備階段予以解決。
最后，要進行快速的開發，經驗表明，工具標準化可使企業充分利用現有知識并在整個SOA計劃中重用。這不是說每個人都必須使用相同的IDE或某個特定工具，而是說使用的任何工具必須以類似的模式工作，必須支持標準；若開發人員需要使用不同的工具支持其他項目，則必須降低學習的難度。另外，這些工具必須能夠輕松地度量服務的重用性和控制上市時間。通過服務生命周期獲得度量可以為企業提供價值巨大的信息，幫助SOA計劃獲得成功。
BEA域模型
正如許多方法學所述，需要建立一種底層模式來統一所有其他活動。在BEA和SOA環境中，就是BEA的域模型（需要注冊）。Dev2Dev中有許多文章描述理解SOA各個方面的重要性（詳見David Groves撰寫的Successfully Planning for SOA）。共享服務生命周期使用該模型并按此方式提供切實的控制點。在本文定義的設計時階段中，域模型的影響通過定義項目和應用程序的需求以及架構方法的需求目錄來表述。
該方法通常開始于遠景，最初通過基礎服務或構造塊實現。盡管治理在設計階段沒有在SSLC的運行時那么關鍵，但是治理已開始在流程中產生了一定的影響，特別是在決定初始服務實現時。
本系列文章的第二部分將揭示評估部署服務成本和收益的重要性，并繼續關注在運行時如何對服務進行治理。另外，SSLC的設計時和運行時階段都要求緊密結合業務策略和流程。這就要求確定和設計可能成為侯選服務的業務流程，并將它們組合成可重用服務，以實現業務的靈活性。
結束語
通過進一步理解與共享服務生命周期相關的設計時需求，正在尋求使用SOA促進重用和增加業務靈活性的企業可能認識到及早建立基礎架構（如方法學、分類指導方針以及開發工具）是實現早期及后續成功的重要因素。通過突破傳統應用程序開發范型以及關注作為發展藍圖的業務流程，服務工程團隊可以及時有效地緊密結合業務需求。
本文的第二部分將關注共享服務生命周期的運行時。