|
?
通過用例和模擬對象簡化 SOA 開發——特別在您的項目涉及多個團隊時——并提高 SOA 應用程序質量。
借助于可重用服務和需要很少的新代碼的應用程序（因為可以依賴這些可重用服務），面向服務的體系結構 (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 開發流程
下面給出用于對協調程序和提供程序團隊進行同步的簡單流程，以幫助確保可重用服務以及使用這些服務的應用程序能夠成功地進行開發：
- 使用服務用例描述服務。
- 開發體現服務用例的服務測試。
- 開發通過服務測試的服務模擬。
- 提供程序團隊采用服務模擬作為原型，并將服務測試作為要求，從而實現服務。
- 協調程序團隊將服務測試作為服務使用者可以進行的工作的示例，并在實際的服務仍然處于開發過程的同時使用服務模擬對其代碼進行測試。
這個簡單的流程處理了以下問題：如何確定服務的范圍以及如何保持團隊的一致性和高效率，從而避免發生意外。公正地說，還有許多其他問題仍然沒有通過此流程得到解決。該流程并沒有涉及服務自身如何開發或協調應用程序如何開發的問題。它并不涉及服務的質量問題（即服務的可靠性問題），而是只定義服務如何提供必要的行為。該流程總體上也不處理傳統獨立應用程序如何使用 SOA 重新進行體系結構設計，以及如何發現或設計服務。所有這些問題都是必要的，但其并不在此流程的范圍之內。
此流程使協調應用程序和服務實現協同工作，并允許團隊以相當獨立的方式同時對這兩個部分進行開發。這并非 SOA 項目所需的全部內容，但卻是一個不錯的起點。
為了說明此流程，我將討論如何實現一個簡單服務。它就是大家都喜歡用的服務示例，即股票報價服務。為了讓內容更豐富一些，我提供了以下三種類型的信息：
- 簡單的當前價格報價
- 包含當前價格、當日最高價和最低價以及當天交易量的復雜報價
- 包含過去某天的復雜報價的歷史報價
此示例應該足以闡釋該流程的工作過程。
服務用例
此 SOA 開發流程中的第一步是開發描述服務的服務用例。
Alistair Cockburn 將用例 定義為“系統涉眾之間有關系統的行為的協定”（請參閱參考資料部分列出的 Writing Effective Use Cases）。用例必須適合所定義的系統范圍，能夠代表此情況下使用系統的主要參與者的觀點，且能夠在一致的抽象層次上表示參與者的系統使用情況。
Alistair 給出的一個例子是網上的股票購買服務，其中，購買者使用與股票代理的網站協同工作的個人金融應用程序來購買股票。系統范圍既包含金融應用程序，又包含代理的網站。購買者是主要的參與者。抽象級別為應用程序和網站之間的交互，而不是應用程序或網站內的詳細信息。用例將描述主要成功方案（購買者根據這些方案購買股票）和一些可能出現錯誤的擴展。
因此，用例是關于以下內容的文本描述：希望系統如何工作、將涉及到哪些人以及他們之間如何交互、系統在正常運行時如何工作，以及出現錯誤時應該如何處理。它關心的是系統將做什么，而不考慮將如何 實現。
現在，假定所討論的不是系統或應用程序，而是一個 SOA 服務。用例技術仍然適用。可以采用此技術來描述服務使用者與服務提供程序如何進行交互，說明服務做什么 而不用描述其如何 實現。服務用例 的最初草稿應將重點放在服務的行為上。由于這是必須調用的服務，因此后面的用例草稿還應該指定調用協議——將用于調用服務的技術、傳輸和數據格式。（用例純粹主義者甚至可能說協議不屬于用例的實現細節，他們是對的。但服務用例不僅描述服務，而且還要描述如何調用該服務，因此協議是使用者和提供程序參與者之間的協定的一部分，必須在某個地方加以指定。）
因此，開發用例的第一步是對服務完成的操作進行充分的描述。此描述代表了使用者對提供程序必須提供的行為的要求，主要由協調程序開發團隊創建，但同樣以提供程序開發團隊提供的輸出為基礎。這兩種類型的開發團隊必須對用例滿意才行，因為這些用例是對所有團隊開發其負責的應用程序部分的要求。
服務不僅要在條件良好的情況下正常工作，而且還要能夠恰當地處理出現錯誤的情況，這非常重要。因此，您的服務用例應該對錯誤情況和服務無法成功處理的錯誤輸入加以處理。其中很多錯誤路徑最終都表現為用例的備用路徑。其他錯誤場景也可能非常極端，因而需要各自的錯誤用例。在這兩種方法中，用例都必須記錄服務如何像成功路徑一樣全面地處理錯誤。
示例用例
例如，讓我們看看股票報價示例的服務用例。它需要做三件事，因此需要以下三個服務用例：
-
簡單報價：使用者傳入股票代碼；提供程序返回指定的股票的當前價格。
-
復雜報價：使用者傳入股票代碼；提供程序返回指定股票的當前價格，當前的最高價格、最低價格以及交易量。
-
歷史報價：使用者傳入股票代碼和日期；提供程序返回指定股票和日期的復雜報價。
即便對于這樣的簡單示例，仍然需要確定很多問題并將其添加到用例中，如下所示：
- 如果股票代碼無效，或者提供程序所屬的交易所不支持該股票，該如何處理？
- 應該為價格使用何種格式？浮點數可能存在舍入誤差。小數更為準確，但不標準。字符串效率較低，但更為明確。
- 應該為復雜報價使用何種格式？逗號分隔值？數組？對象？XML 文檔？SOAP 響應？
- 如果所請求的日期是當日或將來的時間，該如何處理？如果日期是過去的某個市場不開放的日期，該如何處理？對于交易所尚未開始進行股票交易的日期該如何處理？如果日期過早，而不存在相關記錄了，該如何處理？如果股票代碼或交易從那以后發生了變化，又該如何處理？
即使開發本文中的簡單用例也不簡單。用例非常麻煩，必須考慮周全才能圓滿地完成開發工作。此時的細心工作是非常不錯的一項投資；利用好的服務用例可以開發良好的服務測試和服務模擬，從而幫助開發團隊正常進行開發工作。
服務測試
此 SOA 開發流程的第二步是開發服務測試，以將用例系統編寫為可執行格式。僅當服務恰當地實現了用例時，測試才能通過。
Kent Beck 指出，測試 應該是自動而獨立的，而且應該對可能出現問題的部分進行檢查（請參閱參考資料部分，以獲得有關他的書籍 Extreme Programming Explained 和 Test Driven Development 的信息）。測試——通過測試開發工作軟件——是 Beck 稱為極限編程 (XP) 的方法所包含的十二項實踐之一。它是測試驅動的開發 (TDD) 的核心——如果您只能遵循一個實踐，該如何執行 XP 呢？當采用 XP 和 TDD 時，將首先開發測試，然后開發軟件以通過測試，接著重復這些步驟，直到軟件足夠完善為止。
應該測試什么？測試的概念源于許多地方，但用例是測試的最佳來源。用例文本和關系圖描述用戶對需求的理解。測試以更明確的方式表述這種理解，并以可靠和重復執行的代碼加以表示。用例和測試是面向不同的受眾（人和計算機）以不同形式表示相同內容的對等項。
服務用例的服務測試 沒有什么不同，不過更多地將其看作功能測試，而不是單元測試。服務測試不會驗證服務如何實現；提供程序開發團隊可以自行實現此用途的單元測試。服務測試驗證服務是否提供了服務用例認為其應該提供的行為。這些測試還需要對錯誤路徑進行測試。
測試將最終定義服務的期望接口。此接口通常為 Web 服務的 Web 服務描述語言（Web Services Description Language，WSDL）文件、Java 接口或 Java 組件的 EJB 遠程接口等等。如果首先開發接口，然后根據接口實現測試，可能會看起來更簡單，不過更直接的方法是首先開發測試，然后開發接口，以使測試能夠成功編譯。
示例服務測試
可以使用簡單的單元測試框架（JUnit 或 Cactus）來開發測試。該框架將充當服務的使用者，并進行使用者將進行的操作。下面是一些可能的測試：
- 使用 IBM 調用
simple quote ，以驗證獲得的結果是“$100.00”。
- 使用 MSFT 調用
simple quote，以驗證獲得的結果是“$30.00”。
- 使用 BOGUS 調用
simple quote，以驗證獲得的結果是 invalid stock symbol 錯誤。
對復雜報價和歷史報價的測試將與此類似。另外，還有針對可能的基礎結構錯誤的測試，如遠程異常和 HTTP 400 錯誤。最后，測試應該對服務用例中指定的所有內容進行驗證；如果在用例中指定了操作，但卻不在一個或多個測試中進行檢查，則意味著使用者不能期望提供程序將實際執行該操作。
服務模擬
此 SOA 開發流程的第三步是開發服務模擬——通過服務測試的模擬對象。這些服務模擬是實際服務提供程序的簡單原型。
Kent Beck 將模擬對象 描述為測試對象，該對象可以使用常量進行響應，從而實現開銷大或復雜的資源的模仿版本。例如，模擬數據庫是一個簡單對象，但具有數據庫的 API，可以接受一些已知的 SQL 字符串，并為每個字符串返回一組固定的結果。模擬對象允許您對組件進行測試，而不必依賴于外部資源。
現在假定此外部資源是一個 SOA 服務。如果您的組件使用該服務，則測試此組件時也在測試該服務。如果服務工作不正常，或者不可用，則即使組件工作正常，測試也會失敗。如果服務很慢（通過網絡遠程調用服務時就是這樣），您的測試也會運行得很慢——這樣就不能如您所愿頻繁地運行測試了。而且，如果服務尚未實現，則根本就不能對您的組件進行測試。
因此，一個不錯的方法就是開發服務模擬，模擬對象是實際服務的簡單仿真程序。服務具有與實際服務相同的 API；它會實現針對服務測試而開發的接口。服務模擬應該如何工作？它應該通過您已經開發的服務測試，這表明模擬真的和實際服務的工作方式一樣。
在某些情況下，服務模擬實際上比實際服務更適合用于進行測試工作。假定您的組件使用返回股票報價的服務。如果傳入代碼 IBM，您將獲得什么樣的結果呢？$50？$100？$150？具體取決于當前的股票價格，但這是測試的一個“雞與蛋”問題。通過使用服務模擬，已硬編碼的模擬將始終返回 $100，然后據此進行測試，與測試實際服務相比，這實際上更加可靠。
誰開發服務模擬？提供程序團隊（而非協調程序團隊）應該開發服務模擬。服務模擬表示提供程序團隊計劃實際實現的內容的簡單實現。如果相同的服務有多個提供程序團隊，則他們必須進行協調，以產生一個他們都認可的模擬服務。
示例服務模擬
此示例服務模擬需要通過我前面編寫的示例服務測試。因此，它的簡單報價實現是一個 case 語句。如果服務只是一個傳統 Java 對象（plain old Java object，POJO），則對應的模擬將為通用接口的特殊實現，如下所示：
清單 1：作為通用接口的特殊實現的服務模擬
public class StockQuoteMock implements StockQuoteService
|
簡單報價則將為 StockQuoteService 中聲明的一個方法，并在 StockQuoteMock 實現如下方法：
清單 2：在 StockQuoteService 中聲明并在 StockQuoteMock 中實現的簡單報價方法
public String getSimpleQuote(String symbol) throws InvalidSymbolException {
if (symbol == null) throw new InvalidSymbolException(symbol);
if (symbol.equals("IBM")) return "$100.00";
if (symbol.equals("MSFT")) return "$30.00";
if (symbol.equals("BOGUS")) throw new InvalidSymbolException(symbol);
throw new InvalidSymbolException(symbol);
}
|
如果服務更復雜（如無狀態會話 Bean 或 SOAP Web 服務），此 POJO 代碼仍然可以作為更復雜的模擬實現的基礎。在任何情況下，模擬實現肯定都不應該試圖處理每個可能的股票代碼或訪問具有實時數據的數據庫。模擬實現應該足以通過服務測試即可。
提供程序開發
此 SOA 開發流程的第四步是由提供程序開發團隊實現通過服務測試的服務。
此時，提供程序團隊已經準備好，可以進行服務開發了。既然他們還沒有開始實現服務，怎么可能進行服務開發呢？幸運的是，他們已經開發了描述服務應如何工作的服務用例，開發人員就是開發人員，他們已經開始考慮如何實現服務了。開發人員已經創建了服務測試，這些測試可說明服務的 API 是什么，并幫助演示服務的行為。他們已經開發了服務模擬，這些模擬是表示實際服務將如何工作的快速原型。
因此，開發人員已經非常明確如何實現服務，只是尚未實現其相關的任何代碼而已。
這幾乎是毫無疑問的，但開發人員實現的服務必須通過服務測試。他們如何知道自己已經完成服務實現工作了呢？當服務通過了所有測試后，服務就已完全實現了。在開發期間，團隊的開發活動可能會讓他們添加要測試的其他功能。訓練有素的團隊不會放棄這些想法，而將對其進行捕獲并添加到服務的測試集中。服務實現也必須通過這些測試。提供程序團隊還應該向其他提供程序團隊和協調程序團隊通報這些添加的測試，以便所有團隊的測試集保持同步。
理想的情況下，提供程序團隊將可以成功地實現通過測試的服務，而不必修改已達成一致的測試。不過，這經常被證明是不切實際的。當開發人員實現服務時，他們有時會發現需要更改服務的接口或行為。如果服務測試的質量良好，而開發人員更改了服務的工作方式，則測試就不能再通過了。為了使測試仍然有效，開發人員必須修改測試，使其可以驗證新的設計。更改測試意味著服務模擬現在將不能通過測試，因此也必須對其進行更改，以實際模擬服務現在的工作方式。
如果提供程序開發人員更改了服務測試或服務模擬，他們需要盡快通知協調程序開發人員和該服務的任何其他提供程序的開發人員。任何使用舊測試和模擬的人員都在根據一個現在已經過時的協議進行開發，因此各個團隊需要根據新測試和模擬進行同步。如果其他團隊拒絕接受新測試和模擬，則重新同步的工作就變成了團隊之間的重新協商點。他們仍然有希望就服務用例達成一致，以從此處繼續開展工作，從而開發一組一致認可的測試和模擬。
示例提供程序實現
提供程序開發團隊將開發實現 StockQuoteService 的類或組件，其工作方式與 StockQuoteMock 類似，并使股票報價測試能夠通過。模擬是一個包含硬編碼響應的簡單對象，而此提供程序是提供實際行為的組件。該實現應該執行以下操作：
- 支持所有有效股票代碼（至少支持提供程序的股票交易中涉及到的所有股票）。
- 確保使用包含所支持股票的實時價格的數據庫。
- 將數據庫使用的價格格式轉換為服務返回的格式。
- 將數據庫針對無效代碼的輸入結果（如空查詢結果）轉換為服務希望的錯誤。
- 實現服務的協議，如 EJB 遠程接口、HTTP Web 服務或 JMS 請求和答復消息。
由于模擬和實際提供程序實現相同的接口——在此例中為 Java 接口 StockQuoteService，因此服務測試可以使用兩個實現中的任何一個；只要使用要實例化的正確類對測試進行配置即可。為了運行測試，您還需要使用測試期望的股票價格對數據庫進行配置。
協調程序開發
此 SOA 開發流程的第五步是由協調程序開發團隊實現使用服務的應用程序。在實際服務實現就緒之前，應用程序都將使用服務模擬。
此時，由于具有大量的服務模擬，因此協調程序團隊可以繼續進行其相關工作，就像已經實現并提供了服務提供程序一樣。而且，協調程序團隊不僅具有一組可以使用的服務（也就是模擬），而且也有了可以演示服務如何工作的和客戶機如何使用服務的一組測試。該團隊可以將這些測試作為可以如何實現其協調程序的簡單原型使用。和提供程序團隊一樣，盡管尚未實現任何代碼，但協調程序開發團隊已經早就在進行協調程序的工作了。
理想情況下，協調程序團隊將可以使用達成一致的服務模擬來成功地實現他們的協調程序。不過有時候這樣做有些困難。模擬并不提供某些需要的行為或希望的接口。協調程序客戶還需要比模擬提供的服務更細粒度的服務。如果服務協調程序需要其他功能，則可以嘗試自行實現此功能。如果協調程序需要不同的接口，則可以嘗試實現一個適配器，來將其所希望的接口轉換為模擬實現的接口。如果協調程序希望更細粒度的功能，則該團隊需要對模擬及其測試進行修改。
這些更改會使得有必要重新與提供程序團隊進行同步。讓我們假定協調程序團隊實現了額外的功能或不同的接口來提高服務的可用性。如果添加的行為不是特定于協調程序，而是會涉及到服務，則添加的行為可以潛在地由其他服務使用者重用。因此應將其內置到提供程序中。提供程序所需的更改可以也應該建模為對模擬及其測試的更改。當協調程序團隊必須修改模擬及其測試時——既可能是為了增強其他功能也可能是為了對功能進行進一步細化——必須將這些更改應用到提供程序和其他所有的工作內容。已更改的模擬和測試成為協調程序團隊、提供程序團隊以及其他協調程序提供團隊之間的重新協商點。他們必須針對達成一致的一組新模擬和測試重新進行同步。
示例協調程序實現
協調程序開發團隊將實現一個委托給 StockQuoteService 的實現的客戶端組件。它的行為將與服務測試相似，不同的是，它將使用服務類為 GUI 或客戶端應用程序提供真正的功能。協調程序實現只能使用 StockQuoteService 中經服務測試證明可用的功能。Java 編譯器將確保協調程序代碼只能調用服務接口聲明的方法；保持協調程序實現與測試實現的一致可以確保服務按預期的要求工作。
將流程組合起來
那么，該流程在實踐中是如何工作的呢？
第一步，開發服務用例。服務用例團隊可以包括來自提供程序團隊和協調程序團隊的代表。或者，這個團隊可以僅由那些專門進行需求收集和用例開發的分析人員組成。傳統用例開發主要關注人們如何使用應用程序，而這個團隊必須將重點放在組件如何集成上。他們不應關心提供程序將如何實現，也不用考慮協調程序可以如何實現。相反，他們應將重點放在服務是什么、它們完成什么工作以及如何對其進行調用上。
第二步，將服務用例編寫為服務測試。用例是人可讀的，而服務測試表示相同的需求，但采用的卻是計算機可執行的方式。這些測試必須由開發人員實現，而不是由開發用例的分析人員實現。測試開發人員可以是提供程序團隊和協調程序團隊的成員，也可以是可用且有能力實現測試的人員。在最終確定測試之前，每個團隊的代表都必須對其進行認可，從而表示所有團隊已就其達成了一致，而不考慮誰開發了哪個測試。
第三步，開發通過測試的服務模擬。開發測試的團體通常也實現模擬。模擬證明測試可以通過，作為原型供提供程序團隊使用，并支持協調程序團隊繼續進行開發。與測試一樣，除非所有團隊都認可模擬并表示同意，否則就不能認為已最終確定了模擬。換句話說，任何團隊都不能強制別的團隊接受一組測試和模擬，大家必須一致認可，否則遲早會出現混亂。
第四步，提供程序團隊部署提供程序，這些提供程序的行為與模擬相似，且均已通過了測試。如果將這些提供程序添加到測試和模擬，尤其是在更改了測試和模擬的情況下，則他們必須分發這些更改，以便其他團隊重新進行同步。他們不能強制讓其他團隊接受這些修改；所有團隊必須就此達成一致。
第五步，協調程序團隊必須使用模擬開發可以正常工作的協調程序。如果需要更改模擬，他們還需要對測試進行更新。他們需要隨后將其更改分發給其他組，所有的團隊必須找到一個大家都認可的點——一組共同的測試和模擬，并據此重新進行同步。
這些步驟一起的確可以形成一個簡單的開發流程。
解決 SOA 問題
那么，這個流程是否解決了我在本文開始時提出的問題？
1. 如果某些提供程序尚未開發，則協調程序團隊如何開發其負責的應用程序部分？
模擬解決了此問題。模擬可以快速地進行開發。雖然實際提供程序的開發需要更長的時間，但協調程序團隊可以使用模擬同步開發協調程序。只要滿足了以下條件，此工作就可以順利地進行：
- 模擬的功能全面，即意味著其編寫的測試和用例也全面。
- 沒有團隊必須更改模擬。只要某個團隊必須對模擬進行更改，他們就應該在進一步脫離同步之前盡可能快地重新進行同步。
2. 協調程序團隊和提供程序團隊如何較早而可靠地就服務如何工作達成一致？
因為測試和模擬可以快速進行開發，而且它們是真正可以運行的實際代碼，所以提供了早期驗證，從而可以確保用例有意義，并且團隊真的達成了一致。有了經驗后，可以在前期投入更多的精力，以確保測試和模擬的全面性，這些構件需要更改的幾率越小，剩下的開發過程中需要重新進行同步的幾率也就越小。
3. 實現相同服務的多個提供程序團隊如何能確保他們的實現是兼容的？
一組公共測試以及通過這些測試的模擬可以作為公共參考框架使用，以確保獨立的提供程序實現始終兼容且可互換。早期的測試越前面，需要更改的幾率就越小，從而團隊需要重新同步的情況也就越少。
這樣一來，該流程就解決了多個團隊實現 SOA 的不同部分時所面臨的主要問題。
結束語
本文討論了以下內容：
- 在嘗試使用 SOA 開發應用程序時，并行的獨立團隊可能遇到的常見開發問題。
- 一個簡單的五步開發流程，該流程通過使用服務用例、服務測試和服務模擬解決了這些問題。
您可以將此流程應用到您的組織中，從而大幅度提高使用 SOA 進行開發的成功幾率。
?
|