通過服務模擬來簡化SOA開發(1)

通過用例和模擬對象簡化 SOA 開發——特別在您的項目涉及多個團隊時——并提高 SOA 應用程序質量。借助于可重用服務和需要很少的新代碼的應用程序(因為可以依賴這些可重用服務)，面向服務的體系結構 (SOA) 可以大幅度提高應用程序開發的速度。

但是 SOA 還可能大大增加應用程序開發的復雜性，因為團隊需要同時進行應用程序的不同部分的工作，而且要在最后成功地將各個部分組合起來。

SOA 開發問題

使用 SOA 開發應用程序可提供更多的應用程序部署選項，但也使得開發工作變得越發困難。這是因為 SOA 將應用程序開發拆分為兩個截然不同的部分:

• SOA 服務提供程序(SOA Service Provider，SOA-SP) ——該層的代碼實現服務。它具有服務 API，以對服務進行聲明和為客戶機提供調用服務的方法。
• SOA 服務協調程序(SOA Service Coordinator，SOA-SC)——該層的代碼通過一個或多個 SOA-SP 中的服務提供用戶功能。它可能具有 UI 或 GUI，以便同傳統應用程序一樣與 SOA-SC 進行交互。

例如，某個金融應用程序的 SOA 可能如圖 1 中所示。

圖 1 個人金融應用程序和服務

通常由獨立的團隊分別負責同時開發這兩個獨立的部分。一個團隊負責開發 SOA-SC——對用戶而言的應用程序。另一個團隊負責開發 SOA-SP，或許存在多個負責此項任務的團隊，而每個團隊負責開發若干服務。雖然可能已經實現了一些提供程序，但可能仍然需要專門為此應用程序實現其他的提供程序。

而這給我們提出了第一個問題:如果某些提供程序尚未實現，協調程序開發團隊如何開發其負責的應用程序部分呢?

這兩個團隊——開發服務的團隊和開發協調程序的團隊——需要使其活動同步。他們必須就服務 API 達成一致;服務 API 可以是簡單的 Java™ 接口或 Java Message Service (JMS) 消息格式和隊列名稱，但必須就此達成一致。但僅就接口達成一致是不夠的;服務具有行為，因此團隊必須就服務的行為達成一致。服務并不會始終成功地工作，因此團隊還必須就錯誤情況和相應的響應達成一致。

在理想的情況下，多個團隊可以非常容易地協調工作，最初的決策可以稍后進行修改，而所造成的影響卻非常小，并且評估工作非常靈活，此外還會不斷地進行改進。在現實世界中，團隊之間經常存在協作問題，往往較早地(甚至不成熟地)做出不可更改的決策，而且評估方法是固定的。

這樣就帶來了第二個問題:協調程序和提供程序團隊如何較早而可靠地就服務如何工作達成一致?

經常通過多個提供程序來實現服務冗余。這樣就可以在提供程序之間提供負載平衡和故障轉移功能，從而使得協調程序的服務體驗更為一致和可靠。冗余可以通過多次部署同一服務實現來實現。不過，當不同的供應商部署了不同的提供程序時，服務幾乎肯定具有不同的實現。盡管如此，對于協調程序，所有提供程序的全部實現的工作方式都必須一致，以便協調程序可以采用可交換的方式來調用提供程序。服務的不同實現(特別是來自不同供應商的不同實現)是由不同的團隊開發的，而這些團隊必須加以協調，以確保開發的是相同的服務。

因此，第三個問題就是:多個提供程序團隊如何實現相同的服務，以確保他們的實現具有兼容性?

以上是使用 SOA 進行開發的主要問題。必須實現尚未開發的服務來開發協調程序，協調程序團隊和提供程序團隊必須就服務如何工作達成一致，而且，多個提供程序團隊也必須就服務如何工作達成一致。如果沒有良好的流程，這就會導致一片混亂，如果不對其進行檢查，將會導致 SOA 項目失敗。

SOA 開發流程

下面給出用于對協調程序和提供程序團隊進行同步的簡單流程，以幫助確?？芍赜梅找约笆褂眠@些服務的應用程序能夠成功地進行開發:

1. 使用服務用例描述服務。
2. 開發體現服務用例的服務測試。
3. 開發通過服務測試的服務模擬。
4. 提供程序團隊采用服務模擬作為原型，并將服務測試作為要求，從而實現服務。
5. 協調程序團隊將服務測試作為服務使用者可以進行的工作的示例，并在實際的服務仍然處于開發過程的同時使用服務模擬對其代碼進行測試。

這個簡單的流程處理了以下問題:如何確定服務的范圍以及如何保持團隊的一致性和高效率，從而避免發生意外。公正地說，還有許多其他問題仍然沒有通過此流程得到解決。該流程并沒有涉及服務自身如何開發或協調應用程序如何開發的問題。它并不涉及服務的質量問題(即服務的可靠性問題)，而是只定義服務如何提供必要的行為。該流程總體上也不處理傳統獨立應用程序如何使用 SOA 重新進行體系結構設計，以及如何發現或設計服務。所有這些問題都是必要的，但其并不在此流程的范圍之內。

此流程使協調應用程序和服務實現協同工作，并允許團隊以相當獨立的方式同時對這兩個部分進行開發。這并非 SOA 項目所需的全部內容，但卻是一個不錯的起點。

為了說明此流程，我將討論如何實現一個簡單服務。它就是大家都喜歡用的服務示例，即股票報價服務。為了讓內容更豐富一些，我提供了以下三種類型的信息:

1. 簡單的當前價格報價
2. 包含當前價格、當日最高價和最低價以及當天交易量的復雜報價
3. 包含過去某天的復雜報價的歷史報價

此示例應該足以闡釋該流程的工作過程。

服務用例

此 SOA 開發流程中的第一步是開發描述服務的服務用例。

Alistair Cockburn 將用例 定義為“系統涉眾之間有關系統的行為的協定”(請參閱參考資料部分列出的 Writing Effective Use Cases)。用例必須適合所定義的系統范圍，能夠代表此情況下使用系統的主要參與者的觀點，且能夠在一致的抽象層次上表示參與者的系統使用情況。

Alistair 給出的一個例子是網上的股票購買服務，其中，購買者使用與股票代理的網站協同工作的個人金融應用程序來購買股票。系統范圍既包含金融應用程序，又包含代理的網站。購買者是主要的參與者。抽象級別為應用程序和網站之間的交互，而不是應用程序或網站內的詳細信息。用例將描述主要成功方案(購買者根據這些方案購買股票)和一些可能出現錯誤的擴展。

因此，用例是關于以下內容的文本描述:希望系統如何工作、將涉及到哪些人以及他們之間如何交互、系統在正常運行時如何工作，以及出現錯誤時應該如何處理。它關心的是系統將做什么，而不考慮將如何 實現。

現在，假定所討論的不是系統或應用程序，而是一個 SOA 服務。用例技術仍然適用?？梢圆捎么思夹g來描述服務使用者與服務提供程序如何進行交互，說明服務做什么 而不用描述其如何 實現。服務用例 的最初草稿應將重點放在服務的行為上。由于這是必須調用的服務，因此后面的用例草稿還應該指定調用協議——將用于調用服務的技術、傳輸和數據格式。(用例純粹主義者甚至可能說協議不屬于用例的實現細節，他們是對的。但服務用例不僅描述服務，而且還要描述如何調用該服務，因此協議是使用者和提供程序參與者之間的協定的一部分，必須在某個地方加以指定。)

因此，開發用例的第一步是對服務完成的操作進行充分的描述。此描述代表了使用者對提供程序必須提供的行為的要求，主要由協調程序開發團隊創建，但同樣以提供程序開發團隊提供的輸出為基礎。這兩種類型的開發團隊必須對用例滿意才行，因為這些用例是對所有團隊開發其負責的應用程序部分的要求。

服務不僅要在條件良好的情況下正常工作，而且還要能夠恰當地處理出現錯誤的情況，這非常重要。因此，您的服務用例應該對錯誤情況和服務無法成功處理的錯誤輸入加以處理。其中很多錯誤路徑最終都表現為用例的備用路徑。其他錯誤場景也可能非常極端，因而需要各自的錯誤用例。在這兩種方法中，用例都必須記錄服務如何像成功路徑一樣全面地處理錯誤。

示例用例

例如，讓我們看看股票報價示例的服務用例。它需要做三件事，因此需要以下三個服務用例:

1. 簡單報價:使用者傳入股票代碼;提供程序返回指定的股票的當前價格。

2. 復雜報價:使用者傳入股票代碼;提供程序返回指定股票的當前價格，當前的最高價格、最低價格以及交易量。

3. 歷史報價:使用者傳入股票代碼和日期;提供程序返回指定股票和日期的復雜報價。

即便對于這樣的簡單示例，仍然需要確定很多問題并將其添加到用例中，如下所示:

• 如果股票代碼無效，或者提供程序所屬的交易所不支持該股票，該如何處理?
• 應該為價格使用何種格式?浮點數可能存在舍入誤差。小數更為準確，但不標準。字符串效率較低，但更為明確。
• 應該為復雜報價使用何種格式?逗號分隔值?數組?對象?XML 文檔?SOAP 響應?
• 如果所請求的日期是當日或將來的時間，該如何處理?如果日期是過去的某個市場不開放的日期，該如何處理?對于交易所尚未開始進行股票交易的日期該如何處理?如果日期過早，而不存在相關記錄了，該如何處理?如果股票代碼或交易從那以后發生了變化，又該如何處理?

即使開發本文中的簡單用例也不簡單。用例非常麻煩，必須考慮周全才能圓滿地完成開發工作。此時的細心工作是非常不錯的一項投資;利用好的服務用例可以開發良好的服務測試和服務模擬，從而幫助開發團隊正常進行開發工作。