4

できればSystem.AddinsまたはMEFを使用して、（動的にロードされたサービスを使用して）拡張可能なWCFサーバーを構築する方法についての提案を探しています。

サーバーは、最小限の「プラグイン」API（StartService / StopService / GetStatus？/ etc）を実装するWCFサービス（DLLアセンブリに含まれ、実行時にロードされる）をホストする必要があります。

この投稿は良いスタートです。議論するいくつかの目的とポイント：

  • サービスごとに分離されたAppDomainを使用する/使用しない？
  • 各サービス（エンドポイント、トランスポートプロトコル）を構成する方法は？XML-configファイルまたはより良い代替手段？
  • アセンブリの遅延/遅延ロード（サービスリクエストが到着したとき）？可能？使える？方法？
  • ディスク上のファイルが変更されたときにアセンブリをリロードします（開発環境に役立ちます）。
  • ディスクの構成が変更されると、サービスが再起動します。

そしてもちろん、他のアイデアはいつでも歓迎です;）

4

1 に答える 1

6

  • AppDomainはい、サービスごとに分離して使用します。AppDomain1つがダウンした場合に実行されている他のサービスをダウンさせないように、分離が必要です。

  • プログラミングまたは構成を通じて、WCFが現在行っているすべての方法を提供します。インスタンスはシリアル化できないため、プログラムによるアクセスは困難ですServiceHost。そのため、アプリのドメイン境界を越えて情報を取得するのは面倒です。

  • できると思います。ただし、これは基本的にWindows Process Activation Serviceを複製しているため、機能を探し始めることをお勧めします。

  • 開発には役立ちますが、正直なところ、持つ機能はそれほど重要ではないと思います。それは、あまり測定できない（IMO）ゲインのためにコードを複雑にします。コードベースを複雑にしすぎて常にアセンブリを監視するのではなく、サービスを停止し、ファイルをコピーして再起動するスクリプトを作成したいと思います。

  • 今、あなたはIISについて話している。基本的にIISにサービスをホストさせることができ、構成ファイルが変更されたときにサービスをリサイクルします。

そうは言っても、WASとIISは必要なもののほとんど（高度に利用可能な、分離されたアプリドメイン、構成など）を提供しているように思われるので、なぜこれを自分で行うのかを尋ねたいと思うかもしれません。

于 2009-01-09T05:26:56.707 に答える