0

古いレガシー Web アプリケーションがあります。アーキテクチャは次のもので構成されています。

  1. (クラシック) クライアントのブラウザーにサービスを提供する ASP ページ。数千の VB スクリプト
  2. ASP (IIS) によって呼び出されるアウトプロセス DCOM サーバー。MFC、シングルトン、exe
  3. データベース; 1 つ以上のスキーマ
  4. DCOM サーバーを呼び出す補足 ASP.NET アプリケーション

サーバーの役割は次のとおりです。

  • ユーザーのログイン、ログアウト、ライセンスの処理
  • ユーザーセッション情報を保持する
  • UIを生成する
  • ユーザーアクションを保護/承認する
  • データを取得してデータベースに保存する

サーバーのこれらの多くの役割のため、ASP (IIS) と DCOM サーバー間の呼び出しインターフェイスはかなり広く、これらの多くのページで頻繁に使用されます。
主な問題は、DCOM サーバーを呼び出す IIS にあり、新しい Windows サーバーではさらに大きくなります。Windows Server 2008 以降では、この組み合わせはほとんど維持できません。UAC を配置すると、単一のアウトプロセス DCOM サーバーでさえ機能しなくなります (異なるセキュリティ コンテキストで異なるプロセスが開始されます)。

サーバーの MFC/C++ コードを保持し、シングルトンとして実行したいと思います (すべての短所にもかかわらず)。これらの多くの ASP ページは、アプリケーションの中で最も動的で常に変化している部分です。補助的な ASP.NET アプリケーションを犠牲にするかもしれません。

サーバーのシングルトン アウトプロセス DCOM インターフェイスを置き換えるのに最適なものは何ですか? パフォーマンスと将来のメンテナンスが最も重要だと考えています。

(同じ .Net インターフェースを COM の代替として見ることができますが、私の主な関心事は、最初の反復でそれを 1 プロセスのシングルトンに保つことでした。)

4

1 に答える 1

2

この質問はSOにとっては少し自由です...しかし、私はかなり前に次の手法を使用して、JavaからCOMへのブリッジを行いました。HTH...

コードの大部分を保持する意思があるため、コードが機能することを理解しています。シングルトン パターンのスケーリングに問題があります。

したがって、シングルトンを 2 つの部分に分割します。

まず、シングルトンをサービスとして (または COM+ で) 実行します。そのプロセスに、HTTP 要求を受信して​​インプロセス COM 呼び出しに変換する小さな shim (独自のスレッドで実行される) を追加します。すでにプロセス外で作業しているため、スレッド間のマーシャリングは問題になりません。HTTP 部分については、Mongooseを参照してください。これは、概念実証をすぐに実行できる単一の C ファイルです。

次に、サーバーと同じインターフェイスを実装する通常の非シングルトン インプロセス COM オブジェクトを (ゼロから) 作成します。そのスタブは、受信した COM 呼び出しを、HTTP ポストへの呼び出しに実際のシングルトンに変換するだけです。

+シムが公開インターフェースでリッスンしないことを確認してください!

于 2013-03-23T01:57:02.190 に答える