デプロイの設計
COM+ アプリケーションのスコープの計画は、早い段階で考慮すべき重要な設計タスクです。 COM+ を使用して実行することを目的とした分散システムは、個々の構成の量が最小限のデプロイ用に設計され、各プロセスを最も効率的に使用するように設計する必要があります。 また、COM+ アプリケーションをデプロイするときに最適なパフォーマンスを実現するために使用できる手法もあります。 (詳細については、 迅速な通信のためのデプロイ。)
コンポーネント サービス管理ツールを使用して表示すると、各 COM+ アプリケーションは、コンポーネントのセットが論理的にグループ化されたフォルダーとして表示されます。 COM+ アプリケーション コンポーネント フォルダー間で個々のコンポーネントを移動できますが (つまり、あるアプリケーションから別のアプリケーションに)、セキュリティなど、COM+ アプリケーション レベルで設定された複数のサービスが異なる場合があります。 これらのサービス設定は、移植性に影響する可能性があります。
COM+ サーバー アプリケーションでプロセス境界を定義する
新しい COM+ サーバー アプリケーションを作成すると、実際には新しいプロセス境界が定義されます。 (以下で説明するライブラリ アプリケーションの例外に注意してください)。このプロセスは、COM+ アプリケーションに含まれるコンポーネントの制御アプリケーション インスタンスになります。 これらのコンポーネントはすべて、プログラムが初めて COM+ アプリケーションを呼び出すたびに、COM+ 実行可能プログラムの新しいインスタンスでインプロセスで実行されます。 つまり、特定の COM+ アプリケーションの Components フォルダー内のすべてのコンポーネントは、DCOM サーバーとして機能する単一のプロセス空間で実行されます。 COM+ アプリケーション内では、COM+ はメモリ、分散トランザクション コーディネーター (DTC) との連携、Just-In-Time コンポーネント インスタンスのアクティブ化、クラッシュ検出と回復、ロールベースのセキュリティを管理します。
COM+ アプリケーション境界を越えた呼び出し
通常、各 COM+ アプリケーションは個別の実行可能ファイルとして実装されるため、分散アプリケーションを複数の COM+ アプリケーションに分割すると、ある COM+ アプリケーションのコンポーネントが別の COM+ アプリケーションのコンポーネントを呼び出すと、プロセス外の COM 呼び出しが発生します。 これにより、プロセス間で COM パラメーターをマーシャリングする負荷が大きいため、パフォーマンスが低下します。
Note
このパフォーマンスの低下に本質的に問題はありません。発生することを認識する必要があります。 必要な応答時間、ビジネス サービスを同時に要求するユーザーの数、および各コンポーネントが各 COM+ アプリケーションに追加するスタートアップの負担に応じて、アプリケーション間の呼び出しに起因するパフォーマンスヒットが許容される場合があります。
COM+ アプリケーションの境界を越えて呼び出すことによるパフォーマンスの低下を排除する可能性の 1 つは、特定の COM+ アプリケーションをライブラリ アプリケーションとしてマークすることです。 COM+ ライブラリ アプリケーションは、それを作成するクライアントのプロセスで実行されます。 もちろん、パフォーマンスの向上にはコストはかからなくなります。 この場合、トレードオフには COM+ ライブラリ アプリケーションの制限が含まれます。 ライブラリ アプリケーションはロールベースのセキュリティを使用できますが、キューに置かれたコンポーネントやリモート アクセスをサポートすることはできません。
関連トピック
-
可用性の観点でのパーティション分割の設計
-
セキュリティ向けの設計