觀點與展望，第 4 部分: 如果剛剛開始采用 SOA，最好將哪些軟件作為服務實現？

IBM 專家將提供各自的個人觀點，以推動 IT 體系結構實踐方面的發展，從而幫助您更好地擔當架構師這一職責。

引言：將 SOA 理論付諸實踐

注意：有關觀點與展望 專欄的全面的信息，請參閱以前的部分：

• “第 1 部分：選擇 SOA 的原因和時機”
• “第 2 部分：如何將業務需求轉轉換為 IT 要求？”
• “第 3 部分：什么是最有價值的 IT體系結構技能，如何學習？”

您可能已經認識到面向服務的體系結構（Service-Oriented Architecture，SOA）適合您的 IT 系統——或者您尚未認識到這一點。但為了討論方便，讓我們假定您已經決定開始設計和實現您自己的 SOA 系統了。您將問自己的第一個問題是“我該從哪里開始？”

IBM 等企業提出的 SOA 方法定義了四個采用 SOA 的階段，其中第一個階段是：

• 實現各個 Web 服務

您需要創建各個基于軟件的服務——任務或任務集，以軟件組件的形式編寫，可通過發布和可發現接口在網絡上為其他應用程序提供服務。這些服務可以是從頭創建的基于軟件的任務，也可以是需要從現有非 SOA 應用程序轉換為服務的任務。（我建議您閱讀關于面向服務的體系結構的采用的所有四個層次部分，以確保按照正確的方向進行相關工作。）

理論上很簡單，是吧？您所需要做的就是編寫包含這些服務的組件，或直接根據已定義的 SOA 接口將現有大型應用程序“組件化”。您可能會想：“說起來容易，做起來難。”正如我在 Rational® 軟件組的一位同事說的，“從理論上說，理論和實踐是完全相同的，但在實踐中，它們卻并不相同。”

SOA 采用的第一個層次雖然很簡單，但您仍然可能會詢問與以下類似的問題：

• 就實踐而言，我如何知道怎么開始實施 SOA？
• 我如何知道哪些可作為一個好的服務？
• 是否可以使用已經編寫的代碼，或者，我是否需要完全重新編碼？
• 應該如何處理現有代碼，以將其變成服務？

為了幫助您回答這些重要的 SOA 采用方面的問題，我們邀請我們的 IBM 體系結構專家組回答以下問題：

如果我剛剛開始采用 SOA，哪些類型的軟件特征是作為服務實現的最佳候選對象，開始實現過程的第一步是什么？

和以往一樣，專家們給出了很多意見和建議，我們希望他們的這些觀點和看法能幫助您將 SOA 理論付諸實踐。如果您有其他問題或對本主題有任何看法，請告知我們，可以通過 pdreyfus@us.ibm.com 給我發送電子郵件，或在IT 體系結構討論論壇發表您的問題或看法。我們將盡力為您提供幫助。

Paul Dreyfus
developerWorks SOA and Web services
pdreyfus@us.ibm.com

另，developerWorks SOA 專區 (www.ibm.com/developerworks/cn/webservices) 提供了關于此主題和 SOA 采用過程中的其他主題的詳細指南。除了參考我們專家組的意見外，還請參閱 SOA 新手入門 和 SOA 技術文檔庫。

回頁首

面向服務的建模和架構

確定在 SOA 中公開哪些服務的過程稱為服務標識?？蓮?developerWorks 文章“基于服務的建模和架構”了解關于此過程的更多信息（該過程包含三個相互補充的技術，均在這篇文章中進行了說明）。

首先，您需要清楚而全面地定義轉換的范圍：最首要的問題是，為什么要啟用服務？定義了這個范圍后，將應用目標服務建模、流程分解和現有資產分析，以獲得候選服務組合。這些經過歸類的候選服務集屬于您的服務模型的一部分。

在您工作的下一個階段，將確定和設計每個服務。需要進行服務公開決策：在數量相當多的服務中，我要實際公開哪些服務？以一系列選擇標準為“石蕊試紙”，對最初候選的所有服務執行一個“PH值測試”，就可以得到這個問題的答案。這包括基于各種標準（如其與業務需求的一致性）測試服務的“良好度”或相稱度。

這將篩選出一個列表，其中包含應該開始進行設計且在 SOMA 的規范化階段發生的服務。在此步驟期間，將詳細指定服務的很多詳細特征，以供實現過程中使用。

實現是在 SOMA 過程的實現階段完成的，在此階段，將通過一組體系結構和來源確定決策對服務進行準備、來源確定或實現。該過程的這個部分的成功是類似于以下所示的聲明：

• 我將使用此包來實現提供此服務的組件。
• 我將從頭構建此服務。
• 我將對這兩個遺留事務進行包裝。
• 我將使用這些事務實現第三個服務或它的一些操作。

回頁首

插入點

一個標識服務（無論是純 Web 服務還是其他更一般的服務類型）的反模式是，了解現有系統，并使用已經獲得的主要接口對服務進行包裝。

之所以認為這個做法非常不好的原因是，這些接口——用于表示系統的錯誤邊界——通?？赡芎茉愀?，是經過多年使用而逐漸從原始狀態發展而來的，其表現具有偶然性，行為并不是最開始就確定的。這也是技術第一的解決方案的一個例子。

標識良好服務的一個更好的模式涉及到定義簡潔的抽象。根據您的系統提出一些基本的使用場景。將重點放在交叉點上（即多個方案的成功均依賴于一個較小的軟件集的位置）。在這些交叉位置之間的巨大間隙中，您將找到使用服務的位置，其相關粒度可由這些方案本身的特性確定。不過，是否將這些服務包裝為純 Web 服務還是別的什么，這需要進行進一步決策。

回頁首

各種入口點

SOA 策略不應是大規模替換現有 IT 環境；相反，這應該是一個循序漸進、不斷發展的過程。因為各個企業通常具有復雜的操作環境，因此不可能進行完全替換。因此，整個路線圖應體現為一個迭代重復的過程。

根據我參與多個客戶的相關工作的經驗，并沒有用于構建 SOA 解決方案的“萬能”完美方法。不過，存在各種入口點，可用于幫助采用 SOA?？梢詫⑦@些入口點大致歸類為以下數個類別：

初始采用。這通常適合那些希望進入這個領域但又擔心有風險的用戶。體系結構方面的工作通常限制在一個臨時環境中，相關的活動包括從概念驗證到早期的試驗性部署等活動。初期工作體現出業務和技術價值后，會在更大范圍內開始采用 SOA。

業務線采用。具有技術眼光的進步的業務線（line-of-business，LOB）執行人員可能會認識到 SOA 的價值。在這個過程中，將首先標識一組業務流程和功能的靈活性要求，定義具有關鍵成功因素和結果指標的解決方案概要，最后實現解決方案體系結構。有時候會使用服務建模和分析技術來對服務標識、規范化和實現步驟進行正式化。IBM 咨詢師喜歡使用 SOMA 方法來進行此過程。

企業采用。這是開明的 CIO 決定開始以增量方式逐步對整個企業的應用程序進行轉換時的情況。通常會涉及到業務分析和建模，以便創建一個區分了優先級的企業組件圖。為了獲得這個組件圖，IBM 顧問通常使用組件業務建模（Component Business Modeling，CBM）方法。該圖中每個需要進行重構的業務組件都會使用服務建模技術（如 SOMA）進行分解，從而最終實現可重用的、價值驅動的服務：

企業采用的是開明的 CIO 決定開始以增量方式逐步對整個企業的應用程序進行轉換時的情況。

我與人合著的《SOA Compass, Business Value, Planning, and Enterprise Roadmap》一書可幫助您了解 SOA 采用過程中的各個基本組成部分——工具、技術和方法。“SOA Project Planning Aspects”（WebSphere® Journal，2006 年 1 月）對該書的內容進行了簡要介紹。

回頁首

將各個組織連接起來：尋找粗粒度服務

這是一個不錯的問題。其他人標識了很多類型的服務。我將僅回答有關“最佳候選服務”和“第一步”的問題。同時，我對這些問題也進行了一點改動。因為，SOA 首先 是一個具有很多好處的體系結構模型。很多其他文章已經對其優點進行了說明，我將不在此處進行重復了。

Web 服務是一組為 SOA 啟用互操作性的標準。WS-Interop 提供運行時互操作性，而 WSDL/WS-Policy 提供工具之間的互操作性。例如，WS-Interop 支持 .NET 和 WebSphere 運行時通信。程序員在 Rational Application Developer/WebSphere Integration Developer 和 Visual Studio 之間交換 WSDL/WS-Policy，以開發協作應用程序。各個供應商均支持優化，例如 JMS/MQ 上的 SOAP（一種基于 XML 的消息傳遞協議）和 SCA 的 Java™ 接口。

從粗粒度服務著手，可以確保首次嘗試 Web 服務不會遇到性能或可靠性問題。

既然這樣說，我認為最佳的候選服務應該是：

1. 由一個組織發布而由另一個組織使用的服務。即，首先使用 SOA 跨越組織邊界。
2. 非常粗粒度的服務。程序員應該尋找在發送方和調用方要進行大量處理的文檔交換一類的服務（即使使用遠程調用）。

實現第一種類型的服務通常是為了解決迫切的業務需求；例如，企業間的集成或企業內 LOB 間的集成。實現 SOA 的 Web 服務提供了一個用于集成異類基礎設施和應用程序接口的公共模型。這是 Web 服務的一種很好的用法，通?？山鉀Q迫切的業務問題，并同時允許不同組織內保持自主權。

從粗粒度服務開始，可以確保首次嘗試 Web 服務不會遇到性能或可靠性問題。此方法還允許實現 SOA 的一些好處，如松散耦合、消息路由和消息審計。

回頁首

您可能已經在使用 SOA 了

如果您剛剛開始采用 SOA，或許要做的第一件事情就是使用 IBM SOA Self Assessment 工具（該工具是免費提供的）。根據評估的結果，可以確定當前的成熟度水平，并更好地為了實現 SOA 解決方案所需要進行后續步驟。也可以參閱“SOA compliance”白皮書，該白皮書描述了在這一漫長的過程中的可以采取的初始步驟。

閱讀了所有相關材料后，您可能會驚喜地發現您已經在使用 SOA 了。例如，Rational Application Developer 從 V4（當前產品為 V6）開始就提供 Web 服務支持了。您可能已經使用過其提供的向導來將簡單 Java 對象、存儲過程、SQL 命令和無狀態會話 Bean 轉換為具有 Web 服務描述語言（Web Services Description Language，WSDL）接口的服務。WebSphere Integration Developer 之類的新外接程序允許使用各種標準（如業務流程執行語言——Business Process Execution Language，BPEL）來將這些服務裝配為業務流程。

回頁首

結合使用各種方法

服務標識顯然出現在 SOA 生命周期的開始位置，在很多情況下都會為整個項目的成功打下基礎。服務標識通常采用域分解、現有資產分析和目標服務建模的自頂向下、自底向上和折衷技術的組合。自頂向下通?？商峁I務用例所定義的業務服務的規范。這包括使用業務用例將現有域分解為功能區域和子系統。

在自底向上方法中，會將現有系統作為實現的可行候選者進行分析和選擇。例如，可能會分析 IBM CICS® 遺留環境的現有功能，以確定可能的 SOA 轉換。通過確定表示組件和業務組件是否緊密耦合，可確定是否可以方便地為應用程序啟用服務。

服務標識通常采用域分解、現有資產分析和目標服務建模的自頂向下、自底向上和折衷技術的組合。

這種方法包括使用目標服務建模來發掘在用例（自頂向下）和現有系統（自底向上）方法中沒有真正捕獲的服務。由細粒度組件和其他服務組織的服務是作為服務實現的最佳候選者。標識了服務后，就可以開始服務的分類分級階段了。此步驟無疑將幫助減少部署數千細粒度組件時的服務增殖問題（這些細粒度組件可能在未應用正確的控制時導致性能、可伸縮性和管理問題）。

回頁首

常用服務

“中間相遇”方法可非常好地確保減少連接斷開的情況。進行自頂向下業務流程分析，以標識最高級別的業務流程，然后將其劃分為更為細粒度的服務。同時，對組織中已經存在的應用程序和基礎設施采用自底向上的方法進行分析，以盡可能對現有資產進行重用。

因此，首先要考慮的服務是那些多個應用程序間最常用的內容——您可能會在不同的應用程序中發現對這些內容進行了多次實現！這可以很快降低成本，并立即體現出其價值。要考慮的主要方面之一就是，為了能有效地對服務進行重用，需對接口進行良好的設計。另外，您可能需要將實現新應用程序所帶來的成本和好處與通過包裝在相應的接口中來重用現有應用程序進行比較。

回頁首

首先實現基礎設施服務

有三種類型的服務可在整個企業內作為共享或可重用服務公開，如下所述：

• 公共基礎設施服務：在操作級別對所有應用程序和系統都必要的服務。我所說的“操作”是指支持系統和應用程序本身的運行時環境所必要的任務——如目錄/LDAP 服務、安全性服務、發現服務和服務管理。
• 公共企業服務：可以在整個企業范圍內作為構建塊提供的服務，可用于組合成新的服務和應用程序，如協作服務、消息傳遞服務和內容服務。
• 域特定的服務：提供特定業務功能的服務。域服務通常是企業內現有業務應用程序的擴展，如 addCustomer、getEmployee 或 submitOrder。我建議企業就公共基礎設施和企業服務支持的初始域服務集達成一致。

知道了這些區別后，要實現的第一種服務類型應該為基礎設施服務，然后是支持初始域服務所需的那些公共企業服務。然后應使用基礎設施和公共企業服務作為構建塊來開發域服務，以擴展現有業務應用程序。選擇正確的域服務進行組合實際上是對整個 IT 投資組合的潛在重用和可組合性進行評估的過程。

回頁首

數據封裝、遺留系統

您很可能從我們這里得到一個答案是，使用 IBM SOA Self Assessment 工具，該工具實際上更多的是確定您的組織對 SOA 的準備情況?？焖倭私夥崭拍畹牧硪粋€標準答案的參閱白皮書“Five SOA projects that can pay for themselves in six months”。雖然這樣說，但還是讓我們了解一下可能需要使用服務的技術場景類型：數據和遺留功能的封裝。

服務是一種訪問高度依賴數據的行為的好方法。服務可對數據進行封裝，簡化客戶機交互，并可在必要時從遠程位置訪問數據和行為——當數據快速變化或高度敏感而很難復制數據時，這將尤為有用。信用卡驗證信息就是一個很好的例子；服務可以對支付操作進行驗證，并同時保證信用卡數據庫的安全。另一個不錯的例子是股票報價服務，其中的當前數據在頻繁發生變化，而歷史數據又非常多。

服務也是包裝遺留系統的好方法，可以更方便地訪問和重用其功能。不必在新應用程序中重復相同的功能，而可以委托給已經具有此功能的現有應用程序。如果現有應用程序并不允許通過這種方式方便地調用此功能，可以使用代碼對其進行包裝，以將該功能作為服務公開。假定您的大型機訂單處理系統已經知道訂單的狀態；要在網站上公開這個信息，請將相應查詢作為使用大型機的服務實現。與此類似，如果該系統提供了創建、修改或取消訂單的方法，請將這些任務作為您的網站也能使用的服務公開。

假定您的大型機訂單處理系統已經知道訂單的狀態；要在網站上公開這個信息，請將相應查詢作為使用大型機的服務實現。

包裝數據庫或大型機的服務應是什么樣呢？它們應該與用例類似。我所說的用例是對“客戶計劃如何使用數據或功能？”這一問題的回答。將重點放在客戶希望服務做什么，而不是如何使用數據庫或大型機將其實現。將重點放在用例上，可以確保服務不僅從技術上可行，還能確保服務在實際中有用。