為了為下游服務（downstream service）的使用快速提供標準應用程序結構，而且幾乎不需編寫新功能，該客戶配置文件服務描述了在整個需求目錄中復合服務的能力。
應用服務
最后，服務工程團隊可能會開發許多應用服務，旨在供應用程序以獨立于業務線的方式直接使用。需求目錄中，有兩種特頂的受眾可能對客戶配置文件服務感興趣：想要更新信息、核對訂單等等的實際客戶；可能有興趣在所有訂購了某本書籍（舉例來說）的客戶上運行報告的內部網用戶。結果是，服務工程團隊可能會生產兩種特定于應用程序的服務。正如SOA Domain Whitepaper（PDF）中定義的那樣，這些服務可能通過像portlet這樣的表示服務而公開。
SSLC的運行時階段
更深入地理解了SOA中分層服務的重要性之后，現在讓我們來集中探討SSLC的運行時階段。如果管理得當，這些階段可能會提供一種關鍵因素，實現由SOA計劃驅策的企業靈活性和敏捷性。以下部分就這些方面進行詳細討論。
發布和供應
SSLC的發布和供應階段集中關注：為發布服務需要做些什么，并建立服務使用邊界。特別地，這個階段應建立SOA管理的控制點，并通過定義諸如服務接口和契約等方面促進服務重用。
考慮發布和供應服務時，充分理解正在處理服務的哪些“片段”是非常重要的。在這個階段，服務實現被視為設計時的靜態工件，而不是供應團隊的責任。供給團隊應集中關注以下方面：
服務接口
服務接口為客戶提供了一種基于標準的機制，使客戶能夠根據它所提供的契約訪問此實現所提供的功能性。服務接口將發布服務以便使用。
服務契約
此契約應包含功能元數據（表示如何與服務交互）和非功能元數據（表示哪些條件和限制適用于希望使用該服務的用戶）。通過確保該服務實現中未出現某些邏輯，比如使用的條件和限制，服務也就更可能通過多種方式復合，服務工程團隊或企業尚未考慮到這些方式中的大多數。服務契約在運行時可作更改，而無需在實現中重新編譯代碼，認識到這一點很重要，訣竅就在于有效地利用這種靈活性。
元數據和策略
我的經驗顯示出，要支持一種切實啟用了服務重用和復合的服務，就要定義元數據和策略。建立真正靈活的SOA環境時，元數據的管理就是求竅門所在。通過定義一系列策略，即可輕松在實現外部管理單個服務或一類服務的運行時控制。這些策略不僅定義了哪些規則適用于哪些客戶，而且還在誰可在何時供應哪些內容的方面定義了服務本身。元數據驅動策略的額外優點是，它們可在動態條件下強制實施，比如用戶會話上下文和消息有效載荷。
通過集中關注SSLC的運行時需求，控制和管理開始在成功管理SOA計劃中發揮越來越重要的作用。結果，應將服務發布為某種形式的注冊庫，使其能夠支持一個服務生命周期的配置和變更管理方面。此注冊庫也可與一個企業存儲庫集成，而該存儲庫又可能存儲了另外的一些相關信息。需要特別注意的是，控制點應該通過工具來建立，應該向現有客戶通知一項服務的更改，如有需要，應建立潛在的管理策略為用戶提供時間窗口，以便他們能遷移到一個新版本的服務。所有這些信息都可存放在存儲庫里面，并且可通過注冊庫向服務用戶展示。
集成和部署
SSLC和SOA以提高靈活性和敏捷性為成功的中心原則。服務重用是達成這些目標的一種方法。如SSLC的構建和復合階段所提到那樣，服務可作為部分新服務的實現使用。這聽起來似乎是顯而易見的，但做出以下聲明很重要：確保設計時，復合服務不會影響SSLC的集成和部署階段的靈活性。依靠對動態裝配服務的服務的服務實現來支持業務需求可能導致以下問題：在后續階段引入更改時存在依賴項和版本不一致。因而，建議您利用動態工具，比如Business Process Modeling（BPM），來促進服務聯接的往返，而不要將其嵌入服務實現。另一種方法是在服務實現中利用代理服務，而不使用真實的業務服務終端。通過利用Enterprise Service Bus公開代理服務，物理服務就可能獨立于消費服務而更改。（當然，如果服務接口做出了逆向更改，用戶將通過一個已建立的管理流程得到通知。）
文章來源于領測軟件測試網 http://www.kjueaiud.com/
