MarshalByRefObject の創造的な使用

Question

いくつかのことを理解しようとして頭をぶつけてきました。そこで、アドバイスと研究資料を探しています（リンク経由）。シナリオは次のとおりです。

他のいくつかのアプリケーション (AppA、AppB、AppC など) に必要なリソースを含むライブラリ (CommonLib など) があります。現在、これが動作しているのは AppA インスタンスであり、特定のポートが利用可能かどうかを確認します。そうでない場合は、CommonLib がキックされ (「おい、起きろ」)、サービスが開始されます。その後、AppA は満足し、出発します。

現在、Remoting.Channels について多くの調査を行った結果、「レガシー」と考えられているテクノロジーに基づいて構築されたアプリケーションを開始しようとしているという結論に達しました。そうですね...それは好きではありません。正直に言うと、WCF は必要以上にオーバーヘッドが大きく、Mono では完全に実装されていません。私たちはマルチプラットフォーム互換性 (Windows、Mono、Linux) をターゲットとしているため、すべてのオプションを研究しています。

そもそも、リモート処理のアイデアが始まったのは、CommonLib を保証された単一インスタンスにしたいからでした (私が理解しているところによると、シングルトンは特定の AppDomain 内でのみシングルトンであることが保証されています。間違っている場合は遠慮なく訂正してください)間違ってるよ）。とにかく、私はリモート処理の威力を認識し、実験的な実装を開始することにしました。MarshalByRefObject の最初の使用に成功しました。しかし、私はこのレガシーテクノロジーが継続的に実装されることを懸念しています。

それで、これらすべてを踏まえて...CommonLibを(ホストアプリケーションとして)実装し、リモート処理せずにStream、標準TCPソケット、またはその他の方法でMarshalByRefObjectを実装する方法を検討しています。私が考えているのは、CommonLib を実行するために AppA をインスタンス化する代わりに、CommonLib をベース アプリとして実装するだけです。次に、CommonLib 内でインスタンス化するアプリ (実際には単なる「ホストされた」.dll) を選択します。次に、CommonLib は、ホストされたアプリが使用するカスタム コントロールとともに、その .dll を CommonLib フレームワークに読み込みます。この考えに加えて、私は CommonLib が本物のシングルトンでなければならないという要件を (今のところ) 見送ります。

...これがシナリオの詳細です。繰り返しますが、私の質問は実際には 2 つの部分から構成されています。(a) どのようなテクノロジを調査する必要がありますか? (b) リモート テクノロジのレガシー ステータスを考慮する必要がありますか?

その他のアドバイス、コメント、質問は大歓迎です。

更新 1:私はから始めています このスニペット. 。これにより、インストールされているアプリ (またはプラグイン) のリストを含むファイル (またはスクリプト) を読み込むことができます。このファイルは XML またはバイナリ形式で作成できます。新しいアプリをインストールするときに、ファイルとパスを追加できます。うーん...必ずしも MarshalByRefObject を使用する必要はありません。

Answer 1

WCF はそうではないかもしれませんが、 完全なものとして Mono では、Mono 2.6 は Silverlight / Moonlight に必要なすべてを提供するため、WCF ベースの実装は完全に実現可能です。何か変わったもの (異なるトランスポート、インスペクターなど) を試さない限り、Windows / Mono / などの間で信頼性の高い RPC スタックを提供するだけで十分です。

WCF とリモート処理の主な違いは次のとおりです。 使用法 - リモート処理は、別の端にあるふりをする多数のオブジェクトに基づいていますが、WCF はサービスに基づいています。重要なのは、(プロパティなどにアクセスするのではなく) 個別のメソッドを中心に対話を行う必要があるということです。これには、境界を越える場合にそれを明示するのに役立つという利点もあります。

もう 1 つのオプションは、非常に基本的なソケット サーバーを作成することです。非常に軽量で、protobuf-net のようなものを使用して、ポータブル (クロスプラットフォーム) シリアライザー実装を提供できます (実際には信頼しないでください) BinaryFormatter 二人の間には――それは……フレーク状）。

要するに、私はそれを中心に構築しません MarshalByRefObject まったく;サービス層は次のように書きます。

interface IMyService {
    void Method1();
    int Method2(string s);
}

これらの詳細を呼び出し元から抽象化します。最終的に WCF を使用することになる場合は、 全て 必要です;既存のリモートサポートについては、次のように書きます。 IMyService その実装 カプセル化する （個人的に）全体 MarshalByRefObject 話。ソケットサーバーを書いた場合も同様です。

Answer 2

.NET Remoting が WCF によって廃止されるかどうかはわかりません。それぞれのユースケースは多少異なると思います。WCF には (意図的に) "参照によるマーシャル" の概念がありません。これは、遅延などによりチャットの多いプロトコルを回避する必要がある分散アプリや (比較的) 疎結合なアプリ向けに設計されているためです。コンポーネントが自然に緊密に結合されている場合、レイテンシーは低くなりますが、パフォーマンスは高くする必要があり、豊富な .NET 型を保持することが重要などです。その場合は、リモート処理が依然として適している可能性があります。いずれにせよ、私は「レガシー」であることについて心配する必要はありません。少なくとも Windows/.NET 上の「レガシー」テクノロジは、ある程度の量の使用が得られれば、かなり長期間存続する方法を持っています。リモート処理は .NET の最新 (4.0) バージョンにもまだ存在します。

これはいずれも、リモーティングが必ず必要であるという主張を意味するものではありません。 は あなたの状況に最適な...