Rebus の app.config XML は、プロセスごとにバス インスタンスが 1 つのシナリオ向けに最適化されているため、XML で複数のバスを完全に構成することはできませんが、同じプロセス内で複数のバス インスタンスを開始することを妨げるものは何もありません。
たとえば、物理的に個別の展開のコストを負担することなく複数の論理エンドポイントをホストしたい Azure ワーカー ロールなどで、これを頻繁に行いました。
通常、私の app.config は次の XML で終わります。
<rebus workers="1">
<add messages="SomeAssembly.Messages" endpoint="someEndpoint.input"/>
<add messages="AnotherAssembly.Messages" endpoint="anotherEndpoint.input"/>
</rebus>
したがって、バスごとのデフォルトのワーカー数とエンドポイント マッピングを一度だけ構成できます。次に、アプリケーションが起動すると、アプリケーションの存続期間中、バスごとに IoC コンテナーが保持されます。Windsor を使用すると、通常、Windsor を構成できるキュー名のパラメーターを持つ一般的なバス インストーラーになります。このような:
var containers = new List<IWindsorContainer> {
new WindsorContainer()
// always handlers first
.Install(FromAssembly.Containing<SomeEndpoint.SomeHandler>())
// and then the bus, which gets started at this point
.Install(new RebusInstaller("someEndpoint.input", "error"))
// and then e.g. background timers and other "living things"
.Install(new PeriodicTimersInstannce()),
new WindsorContainer()
.Install(FromAssembly.Containing<AnotherEndpoint.AnotherHandler>())
.Install(new RebusInstaller("anotherEndpoint.input", "error"))
};
// and then remember to dispose each container when shutting down the process
ここでRebusInstaller
(Windsor メカニズム) は、基本的に、次のように、正しいキュー名を持つバスをコンテナーに入れるだけです。
Configure.With(new WindsorContainerAdapter(container))
.Transport(t => t.UseMsmq(_inputQueueName, _errorQueueName))
.(...) etc
.CreateBus().Start();
各 IoC コンテナー インスタンスが、論理的に独立したアプリケーションとして機能するという考え方が気に入っています。このようにして、エンドポイントを個別に展開できるようにしたい場合などに、将来、簡単に分割することができます。
これがあなたに少しのインスピレーションを与えることを願っています:)さらにポインタが必要な場合は、遠慮なく尋ねてください.