Service Broker を設計したとき、設計時 (コードを記述するとき) と展開時 (コードが実際に運用環境で使用されるとき) を明確に区別しようとしました。アプリケーション コードの 1 行も変更せずにデプロイメントを完全に再構成できるように、非常に明確な手段を講じました。設計時に使用するメッセージ タイプ、コントラクト、サービス名などを考慮しました。アクティブ化されたプロシージャと RECEIVE (BEGIN DIALOG/SEND 動詞を発行するコード) をどのように記述するかは、すべて設計時と見なされます。
展開時間とは、ルーティング情報 (ネットワークの物理トポロジが変更されると変更される)、セキュリティに使用される証明書 (有効期限が切れて交換が必要になる)、アクセス許可、エンドポイント ポートなどです。
特殊なケースとして、ダイアログ セキュリティとリモート サービス バインディングがあります。これは、設計時 (アプリケーション コードで が指定されているWITH ENCRYPTION = ON) と展開時 (リモート サービス バインディングが存在する) が混在しています。アプリケーションでダイアログ セキュリティが必要なENCRYPTION = ON場合は、指定する必要があり(指定されていない場合はこれがデフォルト)、管理者は展開時にダイアログ セキュリティを構成する必要があります。または、アプリケーションがダイアログ セキュリティを明示的に必要としない場合は、指定することができENCRYPTION = OFF、管理者が選択した場合は、展開時にダイアログ セキュリティを構成する必要があります。
エンドポイント セキュリティ (トランスポート セキュリティ)に関連するものはすべて、展開時間と見なされます。
最後に、プログラミング エクスペリエンスと使用可能な API が同じように動作するように、細心の注意が払われました。これは、サービスのペアがデータベース内、同じインスタンス上の 2 つのデータベース、または 2 つの別々のインスタンス上にある場合でも同じです (つまり、カップリングを確認してください)。入り込まない）。
この説明が光を当て、物事の見通しを良くすることを願って、この説明を提供しました. あなたの質問に答えるために:名前、場所、リッスン ポート、関与するホストの数など、展開の実際の物理レイアウトに完全に依存しないアプリケーションを作成することは確かに可能です。基本的に、アプリケーション コードはサービスと対話するサービスに関するものであり、ルート、証明書、エンドポイントなどに関する知識はありません。しかし、それはアプリケーション開発の観点からのすべてです。実際には、展開は多くの場合自動化されており、それ自体がアプリケーションです。よくあることですが、コードを書いているのが同じ人物またはチームである場合でも、両方のアプリケーション (または同じアプリケーションの両側) は、完全に別個の 2 つのタスク (またはアプリケーション) と考えるのが健全です。この分離を行い、コードをクリーンに保つことができれば、ほぼ完了です。「アプリ」コードは、それが通信するサービスがどこにあるのか、または処理するメッセージがどこから送信されたのかについてまったく知りません。構成コード (またはアプリ) は、サービスが存在する場所、ルートを構成する方法、どのエンドポイントがどのポートでリッスンしているかなどを正確に知ることに関するものです。
補足として、 Service Broker Dynamic Routingと呼ばれるものがあります。これにより、SSB 自体を使用して大規模な展開サイトを構成する構成が可能になります (つまり、SSB は中央リポジトリに接続してルーティング情報を見つけることができます) が、お勧めしません。 .