服務導向解決方案提供設計成一項服務的餘額報告應用。 接著，應用程式會使用公開為服務本身的三個後端應用程式，以取得信用餘額所需的資訊。
服務導向架構 （SOA） 是部分重疊建置分散式系統的方法。 服務導向方法有數個特性：
鬆散結合。 應用程式的商業規則與處理服務的邏輯不同。
可探索。 應用程式應該有一個機制來尋找服務。
合同。 服務的介面會實作使用者與服務之間的合約。
雖然文獻通常會將服務導向方法視為 Web 服務的同義字，但它們不一定是同義字。 Web 服務呈現實作服務導向解決方案的誘人方式，但您可以使用其他技術，例如 .NET 遠端處理來建立服務。
讀者指引
此解決方案的文件假設您已熟悉 BizTalk Server 和 Microsoft Visual Studio。 它也假設您了解企業應用程式整合和 Web 服務的基本概念。
此外，若要閱讀並遵循開發人員檔，您應該熟悉如何使用 Visual Studio 和執行下列工作來建置應用程式：建立專案、設定參考，以及偵錯和測試 BizTalk 解決方案。
伍德格羅夫銀行的信用卡報告
服務導向架構解決方案是 Woodgrove Bank 的信用卡餘額報告服務。 雖然銀行是虛構的，但案例不是—此案例是以實際部署的客戶應用程式為基礎。
在此案例中，信用卡餘額的要求來自兩個來源：
互動式語音回應 （IVR） 應用程式。
互動式用戶端，例如網頁或自定義用戶端應用程式。
解決方案會透過 MQSeries 從 IVR 應用程式接收要求。 它會使用 HTTP 和 SOAP，透過 Web 服務處理來自互動式用戶端的要求。
新的服務導向架構應用程式通常需要與使用舊版技術的傳統應用程式合作運作，並與現代的應用程式一起功能，例如使用網路服務的網站。 此案例會建立此真實世界需求的模型：IVR 應用程式代表舊版應用程式，而客戶服務用戶端應用程式則是新式應用程式。
Woodgrove Bank 應用程式會使用來自三個後端、舊版系統的數據來回應要求：
提供整體信用額度限制的應用程式。 這是大型主機電腦上的SAP系統。
報告待處理交易總金額的系統，用於記錄帳戶上待處理的交易。 此系統是大型主機或 AS/400 系統。 解決方案會使用 Web 服務和Microsoft主機整合伺服器 （HIS） 與大型主機或 AS/400 系統通訊。
付款追蹤系統，可提供最後一次進行的付款資訊。 您可以使用 MQSeries 連線到付款追蹤系統。
從舊版系統收集及編譯資訊之後，解決方案會將回應傳回原始應用程式，進而將回應傳送給客戶。
商務需求
由於信用報告應用程式會即時回應客戶要求，因此必須有低延遲，才能快速處理要求。 此外，它也必須能夠處理大量的同時要求。 解決方案使用敏感資訊和公用介面，因此安全性是主要關注的議題。 最後，服務必須可靠。
如需解決方案如何符合這些需求的資訊，請參閱 開發服務導向解決方案。
效能特性
為了符合商務需求，案例具有下列效能特性：
每秒 40 個請求的持續輸送量。
每秒 100 個傳入要求的最大吞吐量。
90% 的要求在進出 BizTalk Server 時，都需要在 1000 毫秒內完成處理。
95% 的服務請求需要在 2000 毫秒內完成（包括進出 BizTalk Server）。
100% 的請求在 5000 毫秒內應得到處理（進出 BizTalk Server 以外的服務）。
備註
這些時間不包含後端系統的延遲時間。
解決方案的三個版本
解決方案有三個版本：
存根版本將所有後端系統取代為軟體存根。 存根會模擬後端系統。 此版本提供在單一計算機上部署及執行解決方案的快速方式。
配接器版本會使用 BizTalk 配接器連線到後端系統。 此版本是人們第一次考慮實作解決方案的方式。 不過，使用配接器將訊息傳送至後端系統，會在取得回應時造成顯著的延遲。 雖然配接器本身可能會提供非常低的延遲，但 BizTalk Server 的分散式架構需要使用消息框來與協調流程主機實例通訊。 這會引入與資料庫的往返操作，並造成延遲。
內嵌版本會將適配器取代為直接與後端系統通訊的嵌入程式碼。 解決方案的內嵌版本具有最低的延遲和最高的輸送量。
部署指南提供了建置和部署所有三個解決方案版本的指引，並且在每個版本中提供一種方法，透過 HIS 模擬連接到擱置的交易系統。 如需建置和部署解決方案的相關信息，請參閱 部署服務導向解決方案。