2

安全でない可能性のあるモジュールを分離し、スレッドセーフでないコードを一定レベルで分離するために、複数のアプリドメインが必要なアプリケーションがあります。各モジュールは共通のインターフェースを実装しますが、長生きのメソッド呼び出し(分)も含まれます。

遠い昔、私が似たようなことをしたとき、私は使用MarshalByRefObjectしましたが、それ以来、WCFがAppDomainの境界を越えて通信するための好ましいメカニズムであることを読みました。

複数のアプリドメインが必要であり、各リクエストは長続きする可能性があるため、いくつかの問題が発生します。

  • 特定の時間に「作業」コードを実行するために明示的に必要なスレッドは1つだけです(したがって、リクエストごとに新しいホストクラスをインスタンス化するWCFのデフォルトのアプローチが問題になります)
  • アプリドメインのリストを管理する方法/呼び出しを行う適切なエンドポイント(各ADに使用するエンドポイントを通知する方法/ランダムに選択したエンドポイントをレポートする方法)

私は当初、AppDomainへの呼び出しを非同期にし、結果を監視/取得できる何らかの形式のキューイングシステムを内部に持つことを計画していましたが、WCFの使用と、サービスホストオブジェクトのインスタンス化を制御するのに十分なオーバーライドの煩わしさを考慮しました(後続の呼び出しを同じオブジェクトに対して行うことができるようにするために)、すべての呼び出しをブロックし、親プロセスがすべてのスレッドの問題を処理できるようにする必要があるかどうか疑問に思い始めています。もちろん、特定のアプリドメインに対して保留中の呼び出しが複数ないことを確認し、親プロセスでキューイングを実行する必要もあります。

誰かが同様のシナリオ/優れたアーキテクチャに関するアドバイス/まともな記事へのリンクの経験がありますか?

4

1 に答える 1

2

WCF フレームワークは、リモート プロシージャ コール メカニズムによるメッセージ交換パターンを使用するサービス指向アプリケーションの作成に最適です。netNamedPipesBinding を使用して、同じ物理メモリ空間内の個別の AppDomains の "管理" を実現できますが、そのレベルの制御は WCF が意図したものではありません。

おそらく、Jeffery Richter のこのブログ投稿に沿った何かが、あなたがしようとしていることにより適しているでしょう。

于 2012-08-21T13:32:00.573 に答える