マーシャリングの詳細

標準マーシャリングを使用する場合、ここで説明する詳細はすべて COM によって処理されます。 ただし、これらの詳細を必要とするプログラマーや、基礎となる情報に興味があるプログラマーは少数です。 マーシャリングは、リモート プロシージャ コールを実行できるように、パラメーターをパッケージ化およびアンパッケージ化するプロセスです。

パラメーターのタイプが異なると、異なる方法でマーシャリングされます。 たとえば、整数パラメーターをマーシャリングするには、値をメッセージ バッファにコピーするだけです。 (ただし、この単純なケースでも、コンピューター間の呼び出しで処理するバイト順序などの問題があります。) ただし、配列のマーシャリングはより複雑なプロセスです。 配列メンバーは特定の順序でコピーされるため、相手側は配列を正確に再構築できます。 ポインターがマーシャリングされると、ポインターが指しているデータは、構造内のネストされたポインターを処理するための規則と規則に従ってコピーされます。 各パラメータ タイプのマーシャリングを処理するための独自の関数が存在します。

標準マーシャリングでは、プロキシとスタブはインターフェイスのシステム全体のリソースであり、標準プロトコルを通じてチャネルと対話します。 標準マーシャリングは、次のように、標準の COM 定義インターフェイスとカスタム インターフェイスの両方で使用できます。

• ほとんどの COM インターフェイスの場合、標準マーシャリングのプロキシとスタブは、Ole32.dll 内の COM によって提供されるシステム全体の DLL からロードされるインプロセス コンポーネント オブジェクトです。
• カスタム インターフェイスの場合、標準マーシャリング用のプロキシとスタブはインターフェイス設計者によって、通常は MIDL を使用して生成されます。 これらのプロキシとスタブはレジストリ内で静的に構成されているため、潜在的なクライアントはプロセス境界を越えてカスタム インターフェイスを使用できます。 これらのプロキシとスタブは、マーシャリングするカスタム インターフェイスのインターフェイス ID (IID) を使用して、システム レジストリを介して配置された DLL から読み込まれます。
• MIDL を使用してカスタム インターフェイスのプロキシとスタブを生成する代わりに、タイプ ライブラリを生成し、システムが提供するタイプ ライブラリ駆動のマーシャリング エンジンがインターフェイスをマーシャリングすることもできます。

標準マーシャリングの代わりに、インターフェイス (標準またはカスタム) でカスタム マーシャリングを使用できます。 カスタム マーシャリングを使用すると、オブジェクトは、サポートするインターフェイスごとに実行時にプロキシを動的に実装します。 任意のインターフェイスに対して、オブジェクトは COM が提供する標準マーシャリングまたはカスタム マーシャリングを選択できます。 この選択は、オブジェクトによってインターフェイスごとに行われます。 特定のインターフェイスを選択すると、その選択はオブジェクトの有効期間中有効になります。 ただし、オブジェクト上の 1 つのインターフェイスではカスタム マーシャリングを使用し、別のインターフェイスでは標準マーシャリングを使用できます。

カスタム マーシャリングは本質的に、それを実装するオブジェクトに固有です。 オブジェクトによって実装され、実行時のリクエストに応じてシステムに提供されるプロキシを使用します。 カスタム マーシャリングを実装するオブジェクトは IMarshal インターフェイスを実装する必要がありますが、標準マーシャリングをサポートするオブジェクトは AA インターフェイスを実装しません。

カスタム インターフェイスを作成する場合は、そのインターフェイスに対するマーシャリング サポートを提供する必要があります。 通常は、設計するインターフェイスに標準のマーシャリング DLL を提供します。 プロキシ/スタブ コードとプロキシ/スタブ DLL を作成することも、COM が (タイプ ライブラリ内のデータを使用して) データ駆動型マーシャリングを実行するために使用するタイプ ライブラリを作成することもできます。

クライアントが別のプロセスのオブジェクトのインターフェイス メソッドを呼び出すには、いくつかのコンポーネントの連携が必要です。 標準プロキシは、クライアントのプロセス空間に常駐し、送信用のインターフェイス パラメーターを準備するインターフェイス固有のコードの一部です。 受信プロセスで再作成および理解できるような方法で、それらをパッケージ化またはマーシャリングします。 標準スタブもインターフェイス固有のコードの一部であり、サーバーのプロセス空間に常駐し、プロキシの動作を逆転させます。 スタブは、送信されたパラメーターをアンパッケージ化またはアンマーシャリングし、オブジェクト アプリケーションに転送します。 また、クライアントに送り返すための応答情報もパッケージ化します。

Note

COM よりも RPC に詳しい読者は、クライアント スタブとサーバー スタブという用語に慣れているかもしれません。 これらの用語はプロキシとスタブに似ています。

 

プロセス間通信のコンポーネント

次の図は、関連するコンポーネント間の通信の流れを示しています。 プロセス境界のクライアント側では、クライアントのメソッド呼び出しはプロキシを経由して、COM ライブラリの一部であるチャネルに到達します。 チャネルは、マーシャリングされたパラメーターを含むバッファを RPC ランタイム ライブラリに送信し、RPC ランタイム ライブラリはそれをプロセス境界を越えて送信します。 RPC ランタイムと COM ライブラリはプロセスの両側に存在します。 チャネルと RPC ランタイムの区別は、この実装の特徴であり、COM クライアント/サーバー オブジェクトのプログラミング モデルや概念モデルの一部ではありません。 COM サーバーは、プロキシまたはスタブ、および間接的にチャネルのみを認識します。 将来の実装では、チャネルの下に異なるレイヤーを使用するか、レイヤーを使用しない可能性があります。

関連トピック

Channel

オブジェクト間通信

Microsoft RPC

Proxy

Stub