( 2012/12/06 からの 2 回目の更新-- 新しいプロトコル、少し異なるビュー)
問題は、以下の解決策があなたにとって妥当と思われるかどうか、または私が気付かなかった欠陥があるかどうかです (SQL Server Service Broker にはまったく新しいものです)...
SQL Service Broker: Collecting data from distributed sourcesで提示された問題の分析を続けたいと思います。サテライト SQL サーバーからデータを収集する際に使用するプロトコルの問題に焦点を当てたいと思います。SQL Server Service Broker の使用は必須です。これは、ここに記載されていない他の理由によっても決定されます。したがって、完全に代替ソリューションを提案しないでください。
正確な問題に対して、何をすべきか、サービス ブローカを自然に (最善の方法で) 使用する方法の詳細に焦点を当てたいと思います。全体的な目標は、上記の質問で提示されました。最初の写真:
今、検討すべき詳細...
プラグイン アーキテクチャが必要
サテライト マシンは、実際の物理的な生産ラインに関連しています。一部のマシンがテクノロジ プロセスに追加されたり、一部のマシンが消滅したり、一部のマシンが同じ生産ライン ID を使用するという意味で交換されたりする可能性がありますが、物理的には異なります。つまり、その SQL サーバーは別のものです。実例。
中央サーバーは、サテライトから最初のメッセージを受け取るまで、サテライトについて何も知りません。サテライト サーバーの集中型データベースはありません。システムに含まれるサテライト SQL サーバーの種類と数に関する知識がありません。いつもサテライトサイトで決めています。
データの収集に関連するすべてのアクティビティは、サテライト マシンによって生成されたイベントによって開始される必要があります。
重要:目標は、(センサーから) 新しく作成されたすべてのデータを継続的に転送し、ドロップアウトを発見して修正することです。
具体例を挙げると：
行番号 3 (黄色) で識別されるマシンは、最近環境に追加されました。その SQL Server Express が起動され、センサー データの収集が開始されました (サード パーティ ソリューション、特殊構造の専用テーブル)。マシンはまだ中央サーバーに接続されていませんでした。
唯一の構成は、確実に割り当てられた生産ラインの固定 ID (ここでは 3) と、中央の SQL サーバーに接続するために必要なすべての詳細です。しかし、中央の SQL サーバーはその情報を知りません。セントラルは、新しいソースからのデータを受け入れる準備ができていますが、それがいつになるかはわかりません。(SQL Service Brokerという質問に対する Remus Rusanu の回答で提案されたアプローチを使用して、 1 台のマシンで既にテストされています。1 つの中央 SQL と複数のサテライト SQL…</a>)
少し後に、SQL ソフトウェアの一部がマシン 3 にデプロイされます。中央と話し始めます。サテライト部分はダムではありませんが、独自のアクティビティは、センサー データ テーブルに新しいレコードが挿入されるたびにセンサー データを送信することです (上記のポイント 1 を参照)。レコードから UTC 時間が計算され (独自の形式から)、1 つのレコードからの複数のセンサー データが同じ数の正規化されたレコードに変換され (1 つの XML メッセージとしてフォーマットされます)、中央の SQL サーバーに送信されます。
セントラルは、サテライト マシンから送信されたセンサー データを含むメッセージによってアクティブ化されます。物理接続の障害は、Service Broker キューによってマスクされます。
妥当な間隔 (ここでは 1 時間) の後、中央サーバーは、これまでに収集されたデータを処理する必要があるかどうかを確認します。生産に時間がかかる作業ユニットがあり、データを処理してユニットのドキュメントに追加する必要があります。処理は、ユニットが終了したときにのみ発生する必要があります。
セントラルは、ユニットのすべてのデータがあるかどうかもチェックします。センサーのサンプリングは既知の定期的な間隔 (ここでは約 1 分) で行われるため、セントラルはドロップアウトがあるかどうかを確認できます。また、衛星が SSB 経由でセントラルに接続されていない時間間隔の初期「ドロップアウト」もあります。メカニズムは、どのような状況からでも回復する必要があります。また、センサーが故障したり、データが収集されなかったりすることもあります。セントラルでドロップアウトが検出されたということは、実際にはセントラルが次のように尋ねていることを意味している可能性があります。
衛星は、サンプリング時間の間に送信できる量のデータのみを送信する必要があります。ドロップアウトからの回復はかなり遅くなる可能性があります。中央サーバーでのデータ処理の遅延は重要ではありません。ただし、セントラルは、データの準備ができたとき (または検出された時間間隔でデータが存在しないとき) を認識している必要があります。
写真とソリューションの詳細
衛星と中央の間の通信の基本フレームワークとして、Remus Rusanu による「Recycling conversations」を選択しました。EndOfStream会話ハンドルを破棄し、新しいものを使用する必要があることを通知するメッセージ タイプを定義します。有効期間は、Service Broker タイマーによって生成される上記の 1 時間間隔によって制限されます。
メッセージは、データ処理のアクティブ化にも中央サーバーで (誤) 使用されます。ほぼ同時に、中央はドロップアウトをチェックします。セントラルは、すでにチェックされているドロップアウトよりも低い時間を維持します。このようにして、どのデータを処理する準備ができているかを認識します。
シナリオは合理的だと思いますか？問題はありますか？
（あなたの提案を反映するために質問を改良します。）
あなたの時間と経験に感謝し、良い一日を。
ペトル