Request-Response 傳訊
在要求/回應傳訊模式中，一個合作對象會傳送要求訊息，而接收的合作對象則會回傳回應訊息。 要求/回應處理的兩個典型範例，是瀏覽器與使用 HTTP 配接器的 Web 伺服器之間的互動，以及使用「簡單物件存取通訊協定」(SOAP) 配接器的 Web 服務處理之間的互動。 在BizTalk Server中，要求和回應訊息都會以一般發佈/訂閱的方式處理。 在您微調 BizTalk 應用程式效能時，這是一個需要瞭解的重要考量，因為對於個別訊息，需要高輸送量的系統與需要低延遲的系統兩者在設定上有所不同。
要求/回應模式的接收配接器收到訊息時，BizTalk Server 會先發佈要求訊息到 MessageBox 資料庫。 接著，適當的訂閱者會收到此訊息，該訂閱者可能是與接收埠繫結的協調流程。 此訂閱者會編寫回應訊息，連同屬性發佈到 MessageBox，這個屬性可讓訊息傳回到送來要求的接收埠。 最後，要求的發佈者 (即提交要求的接收配接器) 會拾取回應訊息，並將此訊息傳回到呼叫應用程式。 下圖提供這些步驟的詳細圖解。
SOAP 配接器接收的要求/回應訊息流程
SOAP 配接器提交訊息到結束點管理員。
結束點管理員將訊息發佈到 MessageBox。
與接收埠繫結而因此訂閱訊息的協調流程，會接收訊息並進行處理。
協調流程傳送發佈到 MessageBox 的回應訊息。
結束點管理員接收回應訊息。
結束點管理員將回應傳回到 SOAP 配接器
如果不瞭解內部實作方式，可能會忽略這類行為對效能的影響。 BizTalk Server 最初是針對高輸送量進行微調，但是它也可以設定給具有較低輸送量且較低延遲的環境使用，特別是要求/回應實例中。 在此實例中的微調需要考量幾項因素。 首先，訂閱者是透過輪詢機制發現有發佈的訊息。 若是輪詢間隔設定得太長，可能會造成要求/回應模式的互動延遲比預期還要大。
請注意，在此實例中需要滿足兩個訂閱：初始訊息的訂閱以及回應訊息的訂閱，而這樣會增加對此輪詢間隔的影響。 第二，接收配接器的設定是以不同大小的批次方式將訊息插入到 MessageBox。 大部分的配接器可讓您透過一般配接器組態介面或是 BizTalk Server 或登錄中的參數來設定批次大小。 若是批次大小設定得太大，可能會增加個別訊息的延遲。 如需BizTalk Server效能特性的詳細資訊，請參閱規劃持續效能。