システムは、1台の中央SQLサーバーと2台以上のサテライトサーバーで構成されています。衛星サーバーは測定データを収集し、中央サーバーに送信します。写真を参照してください：
（写真は、Service Broker Communication Protocolsの公式記事から取得され、変更されています。）
別のsateliteSQLを追加する作業をできるだけ簡単にする必要があります。つまり、新しく追加されたsatelite SQLの設定は、他のsateliteSQLマシンと同じである可能性があります。それは可能ですか？
すべてのSQLサーバーは同じドメインにあり、証明書ベースの暗号化は必要ありません。少なくとも今はそうではありません。現在、展開の容易さとスピードが優先事項です。セキュリティは、後のフェーズで改善できます。
言い換えると、satelite SQLは、同じメッセージタイプ、同じコントラクト作成コード、同じエンドポイント設定などを使用できますか？
ルーティングとターゲットバインディングと少し混乱しています。コメントしてもらえますか？
展開が最も簡単なものの中で最も単純なものは、次の構成です。
GRANT SEND ON SERVICE::[<servicename>] TO [public]でも。これにより、データベース証明書とリモートサービスバインディングが不要になります。GRANT CONNECT ON ENDPOINT::[<brokerendpointname>] TO [public]、2つのエンドポイントがSSL（証明書）を使用して接続できるようにします。TRANSPORTを使用してサービスに名前を付けます。[tcp://hostname:port/servicename]この設定を推奨する理由を説明しましょう。
public接続を許可するために証明書を交換する必要があるため、エンドポイントに証明書を使用することは一般に複雑と見なされますが、ブローカーエンドポイントで接続を許可するトリックにより、証明書を交換する必要がなくなります。このトリックを使用するすべてのマシンは、エンドポイントでWindows認証を使用するよりも優れた事前設定なしdomain\machine$で相互に通信できます（ roへの接続の許可が必要な場合は、特定のドメインアカウントを使用したSQL Serverインスタンスの展開が必要です）。ここでも、接続で「いいえ」と言う機能が失われ、イントラネット内の任意のSQLインスタンスからの接続を受け入れます。この構成は、「プラグアンドプレイ」に到達するのと同じくらい実際に近いものです。新しいマシンは、他の既存のマシンの構成を変更することなく、既存のSQLServerSSBサービスとの通信にすぐに参加できます。
このような展開用にマシンを構成する方法の例を次に示します。MACHINE1中央サーバーを次の場所にデプロイすることから始めたいとします。
use master;
go
create database master key...
create certificate [MACHINE1] with subject 'MACHINE1';
create endpoint BROKER as tcp (listener_port 4022) for service_broker
(authentication certificate [MACHINE1]);
grant connect on endpoint::BROKER to [public];
go
use db1;
create message type...
create contract ...
create queue ...
create service [tcp://MACHINE1:4022/CentralService]
on ...
([...]);
grant send on service::[tcp://MACHINE1:4022/CentralService] to [public];
create route transport with address = 'TRANSPORT';
go
それでおしまい。次に、ノードを広告します。たとえば、ホストMACHINE2で次のようにします。
use master;
go
create database master key...
create certificate [MACHINE2] with subject 'MACHINE2';
create endpoint BROKER as tcp (listener_port 4022) for service_broker
(authentication certificate [MACHINE2]);
grant connect on endpoint::BROKER to [public];
go
use db2;
create message type...
create contract ...
create queue ...
create service [tcp://MACHINE2:4022/Satellite]
on ...
([...]);
grant send on service::[tcp://MACHINE2:4022/Satellite] to [public];
create route transport with address = 'TRANSPORT';
go
それでおしまい。今、2つのことが起こります：
[tcp://machine:port/service]メッセージを即座に交換できます。最良の方法は、MACHINE3などの新しいノードを追加する方法です。
use master;
go
create database master key...
create certificate [MACHINE3] with subject 'MACHINE3';
create endpoint BROKER as tcp (listener_port 4022) for service_broker
(authentication certificate [MACHINE3]);
grant connect on endpoint::BROKER to [public];
go
use db2;
create message type...
create contract ...
create queue ...
create service [tcp://MACHINE3:4022/Satellite]
on ...
([...]);
grant send on service::[tcp://MACHINE3:4022/Satellite] to [public];
create route transport with address = 'TRANSPORT';
go
これで、MACHINE1またはMACHINE2への単一の変更をホワイトアウトすると、新しいノードMACHINE3は中央サービスと、実際には必要に応じてMACHINE2の衛星ともメッセージを交換できます。エンドポイントは誰でも接続を受け入れているため、MACHINE3は歓迎され、使用されるサービス名は特別なTRANSPORTルーティングメカニズムによって自動ルーティングされます。これがこの構成の美しさであり、プラグアンドプレイです。新しいノードを追加するには、他のノードで0の構成が必要です。
では、何が得られるのでしょうか。最大の問題はセキュリティです。すべての従業員は、自分のデスクトップにSQL Server Expressをダウンロードし、許可されていないサテライトノードをセットアップして、セントラルサービスとのメッセージ交換を開始できます。彼を止めるものは何もありません。あなたはすべての門を明示的に開いています。より微妙な問題は、サービスが移動するときです。サービス[tcp://MACHINE3:4022/Satellite]が（データベースのバックアップ/復元などを介して）MACHINE4サービスの名前に移動された場合でも、有効なTRANSPORTルート構文名ですが、正しくありません。[tcp://MACHINE4:4022/Satellite]既存の会話を維持することの重要性に応じて、サービスを削除し、名前とパーティという名前の新しいサービスを作成することを選択できます（サービスの名前を変更することはできません。サービスを削除して、新しいサービスを作成する必要があります）。もしもセントラルサービスデータベースに明示的なルートを追加すると、最後の手段であるTRANSPORTルートよりも優先され、メッセージが正しくリダイレクトされるため、既存の会話を維持することが重要であり、回避策があります。重要なことは解決策があるということです:)