規劃 Service Broker 開發
設計 Service Broker 應用程式時，請檢閱下列事項：
關於預期來自您應用程式之輸入和輸出類型與數量的標準。
建議之應用程式的需求。
如果您瞭解這些要素，您就可以開發符合商務目標的系統。
計劃檢查清單
規劃應用程式時，請考慮下列問題：
Service Broker 在您的應用程式在您的應用程式扮演什麼角色？
這個問題的答案可協助您規劃應用程式所使用之訊息類型、應用程式的結構，以及應用程式的儲存和處理需求。
例如，您的應用程式可以使用 Service Broker，以訊息抵達率來處理特殊圖文集，方法是，將訊息儲存在佇列中，直到有資源來處理這些佇列。在這個情況下，您應用程式所使用的訊息類型應該相當符合現有應用程式的輸入和輸出。您可以根據現有的工作負載，估計您應用程式的儲存和處理需求。
相較之下，如果您要設計一個新的應用程式，請仔細考慮哪些作業可以讓 Service Broker 發揮最大作用。當傳統應用程式完全失敗時，使用 Service Broker 通常會取捨最佳狀況下的預測處理時間以獲得可靠性。
例如，線上訂單輸入應用程式不需要在提交訂單時，完整處理訂單並提供最終的確認。不過，應用程式會透過電子郵件，將訂單提交到處理訂單的服務，然後提供最終的確認。使用這個設計時，即使網路問題讓應用程式無法確認訂單，訂單應用程式也可以繼續接受訂單。解決網路問題時，應用程式就會處理這些訂單。在這個情況下，應用程式的儲存和處理需求取決於預期的訂單數目、每個訂單訊息的大小，以及處理每個訂單所需的時間。
在交談中需要哪些資訊才能完成所需的工作？端點將交換訊息的哪些結構描述以便彼此提供此資訊？
大多數服務都會交換半結構化資訊。因此，XML 編碼是一種不錯的選擇。二進位編碼適用於交換影像之類的二進位檔。當訊息僅與所出現的訊息進行通訊時，請使用空白訊息。
藉由選取正確的訊息類型，您稍後可能比較不需要更新您的應用程式。根據訊息類型編碼，這些更新可以包含的項目從更新 XML 結構描述檔案，到在應用程式中進行明顯的編碼變更。如果有您目前不需要但期望未來需要的資料項目，就有必要加入這些項目。如果您在結構描述中定義開頭的這些元素，當您支援這些元素時，您就不必變更結構描述。
您的訊息處理邏輯會在哪裡執行？
您可以將您的應用程式設計成由 Service Broker 啟動的預存程序、背景服務、排程的事件，或外部應用程式。最後的決定取決於 Service Broker 在您應用程式中所扮演的角色。例如，如果您的應用程式處理以可預測之速率出現的持續性訊息資料流，您可以使用背景服務。如果您的應用程式必須根據所出現之訊息數目動態延展，您可以使用由佇列所啟動的預存程序。如果您的應用程式將訊息保存在佇列中，並在設定的時間處理所有訊息，您可以使用排程的事件來啟動應用程式。
如果您的程式需要存取資料庫外部的資源 (例如，網頁或檔案)，您可以使用外部應用程式。使用外部應用程式可以提升應用程式的延展性，因為處理會發生在中層伺服器，而非資料庫伺服器。向外延展使用 Service Broker 的應用程式相當容易，因為 Service Broker 提供佇列的遠端交易存取。可以將 Transact-SQL 命令傳送到資料庫並處理結果的任何應用程式都可以使用 Service Broker。
每個外部程式都會與使用佇列的其他程式隔離。因此，外部程式不需要特殊的動作，就可以管理佇列的存取。此外，如果應用程式正在處理訊息時連接失敗，交易會會回復，而且 Service Broker 會將訊息傳回佇列中。網路問題不會造成應用程式遺失任何訊息。
您計畫使用何種技術來實作您的應用程式？
您可以實作外部應用程式，方法是，使用可以連接到資料庫，並在 SQL Server 中執行 Transact-SQL 陳述式的任何技術。不過，應用程式通常是使用與 .NET Framework 相容的語言和 ADO.NET 進行開發。您可以使用 Transact-SQL 或其中一個與 .NET Framework 相容的語言實作預存程序。Transact-SQL 對於 Database Engine 可以提供更好的效能。與 CLR 相容的語言可以提供較佳的彈性、較緊密的程式流程控制、較佳的處理器密集應用程式效能，以及 .NET Framework 的直接存取。
您的應用程式最常使用哪些伺服器元件？
與您的系統管理員一起工作，確保您擁有足夠的資源，可以達到最佳的應用程式效能。瞭解您最常使用哪些元件。例如，如果您的應用程式使用佇列公平處理工作負載，或開啟訊息保留，請確認佇列有足夠的磁碟空間可以成長。相反地，具有大量訊息但是較少佇列等待時間的應用程式可能會使用更多的網路頻寬，但是只需要較少的磁碟空間。
您的郵件擁有不同的優先順序嗎？
在負載繁重的系統中，Service Broker 交談的優先順序有助於確保重要的工作不會遭到大量重要性較低之工作的阻擋。交談的優先順序也會啟用支援不同服務層級的設計。