英語で読む

次の方法で共有


リモート可能なインターフェイスの設計

分散コンポーネント オブジェクト モデルの登場により、インプロセスでのみ使用する場合でも、カスタム インターフェイスをリモート処理可能にすることが重要です。

MIDL は、インターフェイスのヘッダー ファイルを生成するだけの方法ではありません。 リモート処理用のプログラミング言語であり、コンピューター、プロセス、スレッドの境界を越えてインターフェイスを使用できます。 つまり、プログラムを顧客にリリースする前に、それらの条件下で MIDL で定義されたインターフェイスの動作を確認する必要があります。 IDL で間違いを犯し、インターフェイスが正しくリモート接続されていない場合、その間違いを解決することは困難な場合があります。 新しい IID を使用してインターフェイスを変更し、旧バージョンの IID を下位互換性のために残しておくか、すべてのクライアントとすべてのサーバー マシンを同時に変換する必要があります。

インターフェイスがアウトプロセスで使用されることがない場合でも、クロススレッドで使用される可能性があります。 チェックされていない IDL ファイルの最悪の問題は、複数の シングル スレッド アパートメント) をサポートしていないインプロセス サーバーで発生する可能性があります。 スレッド モデルを指定しないサーバーは、暗黙的にシングル スレッドです。 シングル スレッドとしてマークされたすべての要素は、最初に CoInitialize または CoInitializeExを呼び出したスレッドに強制的に移されます。 他のスレッドがオブジェクトをアクティブ化したスレッドである場合は、そのシングルスレッド サーバー上のすべてのインターフェイスをアクティブ化スレッドにリモートで戻す必要があります。その結果、queryInterfaceの呼び出しに応答してREGDB_E_IIDNOTREG返される可能性があります。 インターフェイスがインプロセスであり、常に同じスレッドで呼び出されることを絶対にアサートできない限り、しばらくするとリモートになります。

最後に、インターフェイス デザイナーとして、クライアント アプリケーションでインターフェイスを使用する方法を検討する必要があります。 インターフェイスがプロセスとマシンの境界を越えて効率的かどうかを判断するには、インターフェイス境界を越えたメソッド呼び出しの頻度と、特定のメソッド呼び出しで転送されるデータの量の 2 つがあります。 COM はプログラムに対してプロセス間およびクロスネットワーク呼び出しを透過的にしますが、アドレス空間間で高頻度および高帯域幅の呼び出しを効率的に行うことはできません。 場合によっては、通常はインプロセス サーバーとしてのみ実装されるインターフェイスを設計する方が適切ですが、他のインターフェイスはリモート使用に適しています。