建立 Service Broker 訊息類型
「訊息類型」(Message Type) 會定義訊息特定種類的名稱，以及 Service Broker 在該種類的訊息上執行的驗證。若要決定您的應用程式將使用的訊息類型，您必須計劃應用程式必須執行的工作，以及執行每項工作所需的資料。
應用程式最常使用的方法是建立訊息的結構，這樣每個訊息都會包括一個步驟的工作所需的資訊。當每個訊息都包含一個步驟的工作資訊時，應用程式可以輕易地接收訊息、完成步驟以及在單一交易中傳送回應。因此，對於許多應用程式而言，判斷訊息類型以及訊息內容最簡單的方式，是為應用程式執行的工作決定交易界限。每個不同的步驟是一個交易，而且每個交易都會對應到在服務之間交換的訊息類型。狀態資訊、結果或是輸入也是訊息類型。
Service Broker 通訊協定是針對與此訊息樣式搭配使用所設計。「對話通訊協定」會將較大的訊息分段以利傳輸，並確保較大的訊息不會防礙傳輸較小的訊息。
選擇驗證類型
為訊息指定的驗證須視訊息的內容而定。最常見的作法是在測試期間使用最嚴格的可用驗證，然後選擇最不嚴格的驗證來改善部署應用程式時的效能。例如，可以交換具類型的 XML 文件，以做為將驗證指定為 NONE 的訊息本文。在此情況下，您的應用程式會在處理 XML 時驗證訊息。
訊息的網路格式包括訊息類型的名稱。因此，通常會選擇訊息類型名稱來避免定序問題與命名衝突。如需有關命名的詳細資訊，請參閱＜命名 Service Broker 物件＞。
指出成功和失敗
應用程式通常不會定義新訊息類型以指出成功或失敗。請改用 END CONVERSATION 陳述式來指出交談已完成，而且工作已成功。如果工作已失敗，請包括 WITH ERROR 選項以傳回有關交談的錯誤訊息。
一般而言，當工作完成時，交談中只有一個參與者應該結束交談。其他參與者只會發出 END CONVERSATION，以回應「結束對話」或是「錯誤」訊息。如果交談成功完成，服務的文件集通常會指定哪個參與者可以結束交談。提供此文件集可協助避免兩個參與者都未結束交談的問題，或是其中一個參與者結束交談，而另一個參與者仍然在執行工作的問題。兩個端點都必須能夠處理錯誤訊息，因為會將內部 Service Broker 訊息同時傳遞給兩個端點。例如，如果在對話關閉之前，對話存留期間過期，兩個端點都會收到 Service Broker 錯誤訊息。
任一個參與者都可以隨時結束含有錯誤的交談。如需有關處理 Service Broker 錯誤訊息的討論，請參閱＜處理 Service Broker 錯誤訊息＞。