（第二更新從2012年12月6日 - 新的協議，一個sligtly不同視圖）SQL服務代理：收集數據 - 插件情景分析
問題是能否解決下面似乎是合理的或者是否有任何我沒有注意到的缺陷（對於SQL Server Service Broker來說是相當新的）...
我想繼續分析SQL Service Broker: Collecting data from distributed sources中提出的問題。我想關注從衛星SQL服務器收集數據時使用的協議問題。 SQL Server Service Broker的使用是必須的 - 它也是由其他未在此處介紹的原因決定的。所以，請不要提出完全不同的解決方案。
我想專注於應該做什麼以及如何自然地（最好的方式）使用Service Broker來解決確切問題的細節。總體目標was presented in the above mentioned question。圖片第一：
現在更多的細節要考慮...
插件架構，希望
衛星機都與真實的物理生產線。可能會發生某些機器被添加到技術過程中，某些機器可能會消失，某些機器可能會被替換，因爲它將使用相同的生產線標識，但它在物理上是不同的 - 即它的SQL服務器是不同的實例。
中央服務器對衛星一無所知，直到獲得第一條消息爲止。沒有衛星服務器的集中數據庫。對系統中包含什麼和有多少衛星SQL服務器不瞭解。它總是由衛星站點決定。
與收集數據相關的任何活動應由衛星機器生成的事件啓動。
重要提示：目標是不斷傳輸所有新創建的數據（從傳感器），並發現並修復丟失 - 獨立於任何可能導致它們的原因。
爲了給你具體的例子：
由3號線（黃色）標識的機器最近添加到環境中。它的SQL Server Express啓動並開始收集傳感器數據（第三方解決方案，具有特殊結構的專用表）。該機器尚未連接到中央服務器。
唯一的配置是生產線的可靠分配的固定標識（這裏是3）以及連接到中央SQL服務器的所有必要細節。但中央SQL服務器不知道這些信息。中央準備接受任何新的資料，但永遠不知道什麼時候。 （已經通過一臺機器using the approach suggested by Remus Rusanu answer對SQL Service Broker — one central SQL and more satelite SQL…進行了測試。）
SQL軟件的一部分稍後部署在機器3上。它開始與中央談話。衛星部分並不笨拙，但是每當將新記錄插入傳感器數據表時（參見上面的第1點），其自身的活動就是發送傳感器數據。從記錄中，UTC時間計算（從專有格式），一個記錄中的幾個傳感器數據轉換爲相同數量的規範化記錄（格式化爲一條XML消息），併發送到中央SQL服務器。
該中心由具有從衛星機器發送的傳感器數據的消息激活。 Service Broker隊列屏蔽了物理連接的故障。
經過合理的時間間隔（此處爲一小時）後，中央服務器會檢查是否應該處理迄今收集的數據。有一個工作單元需要一定的生產時間，數據應該被處理並添加到單元的文檔中。只有在單元完成後才能進行處理。
中央也檢查它是否有單位的所有數據。由於傳感器採樣是以已知的定期間隔（這裏大約1分鐘）完成的，中心可以檢查是否存在一些輟學。當衛星未通過SSB連接到中心時，時間間隔也有一個初始「退出」。該機制應該從任何情況下恢復。也可能發生傳感器故障或數據未收集的情況。檢測到的中央退出實際上可能意味着中央要求：「我在這段時間內沒有來自您的數據，如果存在，請發送給我，或者告訴我他們不存在。」
衛星應該只發送可以在採樣時間之間發送的那麼多數據。從輟學恢復可能相當緩慢。在中央服務器處理數據的延遲並不重要。但是，中央應該知道數據何時準備就緒（或者在檢測到的時間間隔內不存在）。
的一些圖像，更溶液細節
我所選擇的"Recycling conversations" by Remus Rusanu作爲用於衛星和中心之間的通信的基本框架。它定義了EndOfStream消息類型來表明對話句柄應該被丟棄，並且應該使用新句柄。生存期受Service Broker計時器生成的上述一小時間隔限制。
該消息在中央服務器上也用於激活數據處理。大約在同一時間，中央檢查輟學。中央保持低於已經檢查過的輟學時間。這樣它就知道哪些數據可以處理了。
你認爲這種情況是否合理？你能看到它的任何問題嗎？
（我要細化問題，以反映您的建議。）
感謝您的時間和經驗，並有一個愉快的一天。
切赫