コンポーネント オブジェクト モデル

コンポーネント オブジェクト モデル( COM ) は、Microsoftのソフトウェア コンポーネント用のバイナリ インターフェイステクノロジであり、異なるプログラミング言語、プログラミング コンテキスト、プロセス、マシン間で言語に依存しない方法でオブジェクトを使用できるようにします。

COM は、 OLE、OLE オートメーション、ActiveX、 COM+ 、DCOMなどの他の Microsoft ドメイン固有のコンポーネント テクノロジ、およびDirectX、Windows シェル、UMDF、Windows ランタイム、ブラウザー ヘルパー オブジェクトなどの実装の基礎となります。

COM を使用すると、オブジェクトの内部実装ではなく、インターフェイスのみを知っていればオブジェクトを使用できます。コンポーネント実装者は、実装とは別に インターフェイスを定義します。

複数のプログラミング コンテキストのサポートは、機能として実装するのが難しい側面についてはオブジェクトに依存することによって処理されます。オブジェクトの複数の使用をサポートするには、各オブジェクトが参照カウントによって自身を破棄する必要があります。オブジェクトのインターフェイスへのアクセス (型変換と同様) も各オブジェクトによって提供されます。

COMは、Microsoft WindowsとAppleのCore Foundation 1.3以降のプラグインアプリケーションプログラミングインターフェイス（API）でのみ利用可能です。^[1]後者は、COMインターフェイス全体のサブセットのみを実装しています。^[2]

時間の経過とともに、COM はMicrosoft .NETやWeb サービス(つまりWCF経由)などの他のテクノロジに置き換えられつつあります。ただし、COM オブジェクトはCOM Interop を介して .NET 言語で使用できます。

COM は、 SOM、CORBA、Enterprise JavaBeansなどの他のコンポーネント テクノロジと似ていますが、それぞれに長所と短所があります。

C++とは異なり、COMはコンパイラの違いに影響されない安定したアプリケーションバイナリインターフェイス（ABI）を提供します。 ^[3]これにより、異なるコンパイラでコンパイルされたクライアントが使用するオブジェクト指向のC++ライブラリにとってCOMの使用が有利になります。

1987年に導入されたダイナミックデータエクスチェンジ（DDE）は、 Windowsにおける最初のプロセス間通信技術の1つでした。^{[4] [5]}これにより、アプリケーション間のいわゆる会話でメッセージの送受信が可能になりました。

COM の設計に携わった Antony Williams は、ソフトウェア コンポーネントの概念を取り入れた 2 つの論文を Microsoft 内で発表しました。1988 年の「Object Architecture: Dealing With the Unknown – or – Type Safety in a Dynamically Extensible Class Library」と1990 年の「On Inheritance: What It Means and How To Use It」です。これらは、COM の背後にある多くのアイデアの基礎となりました。

Microsoft の最初のオブジェクト ベースのフレームワークである OLE ( Object Linking and Embedding ) は、DDE 上に構築され、複合ドキュメント専用に設計されました。1991 年にWordとExcelで導入され、その後、1992 年のバージョン 3.1 から Windows に組み込まれました。複合ドキュメントの例としては、Word 文書に埋め込まれたスプレッドシートがあります。Excel でスプレッドシートに変更を加えると、その変更は Word 文書に自動的に反映されます。

1991 年、Microsoft はVisual Basic 1.0でVisual Basic Extension (VBX) テクノロジを導入しました。VBX はダイナミック リンク ライブラリ(DLL) の形式でパッケージ化された拡張機能であり、オブジェクトをフォームにグラフィカルに配置し、プロパティとメソッドで操作できます。これらは後にVisual C++などの他の言語でも使用できるように適応されました。

1992 年、 Microsoft はWindows 3.1で、新しい基盤オブジェクト モデルである COM を搭載した OLE 2 をリリースしました。COMアプリケーション バイナリ インターフェイス(ABI) は MAPI ABI (1992 年リリース) と同じで、MAPI ABI と同様にMSRPCをベースとしており、最終的にはOpen GroupのDCE/RPC をベースとしていました。COM は DDE のテキスト ベースの会話と Windows メッセージング設計が堅牢かつ拡張可能な方法でアプリケーション機能を共有できるほど柔軟ではなかったため、DDE を置き換えるために作成されました。

1994 年、 COM に基づくOLE カスタム コントロール(OCX) テクノロジが VBX の後継として導入されました。同時に、Microsoft は OLE 2 を単に「OLE」と呼ぶことを発表していました。

1996 年の初めに、Microsoft は OCX の新しい用途、つまり Web ブラウザーの機能を拡張することを発見しました。Microsoft は、インターネットに関連する OLE の一部をActiveXに改名し、 Microsoft Officeで使用されていた複合ドキュメント テクノロジを除くすべての OLE テクノロジを徐々に ActiveX に改名しました。

1996年後半、マイクロソフトはDCOMを使用してCOMをネットワーク経由で動作するように拡張しました。^[6]

COM IDL は、オブジェクト指向の拡張機能を備えた、機能豊富な DCE/RPC IDL に基づいています。Microsoft の DCE/RPC 実装であるMSRPC は、Windows NT サービスおよび内部コンポーネントの主要なプロセス間通信メカニズムとして使用されており、基盤として当然の選択となっています。

DCOM は、Windows デスクトップ上で通信する個別のアプリケーションを持つ単一のユーザーをサポートするだけの COM から、ネットワーク上の異なるマシンで異なるセキュリティ コンテキストで実行されるオブジェクトをアクティブ化するように拡張します。これにより、オブジェクトを作成、アクティブ化、および呼び出す権限を持つユーザーを構成する機能、呼び出し元ユーザーを識別する機能、および呼び出しのセキュリティに必要な暗号化を指定する機能が追加されました。

Microsoft は、開発者に分散トランザクション、リソース プーリング、切断されたアプリケーション、イベントの発行とサブスクリプション、より優れたメモリとプロセッサ (スレッド) の管理のサポートを提供し、Windows を他のエンタープライズレベルのオペレーティング システムの代替として位置付けるために、Windows NT 4 で Microsoft Transaction Server (MTS) を導入しました。

Windows 2000 でCOM+に名前が変更され、MTS によって提供される一連の外部ツールとは対照的に、機能セットがオペレーティング システムに組み込まれました。同時に、Microsoft はDCOM を独立したエンティティとして重視しなくなりました。COM+ を使用するコンポーネントは、COM+ の追加レイヤー、特にインターセプションのオペレーティング システム サポートによって、より直接的に処理されました。MTS の最初のリリースでは、インターセプションが追加されました。MTS コンポーネントをインストールすると、Windows レジストリが変更され、コンポーネントを直接呼び出すのではなく、MTS ソフトウェアが呼び出されるようになりました。

Windows 2000 には、COM+ コンポーネントを構成するためのコンポーネント サービス コントロール パネルの更新プログラムが含まれていました。

COM+ の利点は、"コンポーネント ファーム" で実行できることです。コンポーネントのインスタンスは、適切にコード化されていれば、プールしておき、メモリからアンロードすることなく、その初期化ルーチンへの新しい呼び出しで再利用できます。コンポーネントは分散 (別のマシンから呼び出す) することもできます。COM+ とMicrosoft Visual Studio には、クライアント側プロキシを簡単に生成できるツールが用意されていたため、リモート呼び出しには DCOM が使用されていましたが、開発者にとっては簡単に実行できました。COM+ では、COM+ イベントと呼ばれるサブスクライバ/パブリッシャー イベント メカニズムも導入され、キュー コンポーネントと呼ばれるコンポーネントでMSMQ (アプリケーション間の非同期メッセージングを提供するテクノロジ) を活用する新しい方法も提供されました。COM+ イベントは、COM+ プログラミング モデルを拡張して、パブリッシャーまたはサブスクライバとイベント システム間の 遅延バインディング (遅延バインディングを参照) イベントまたはメソッド呼び出しをサポートします。

.NETは、COM に代わる Microsoft のコンポーネント テクノロジです。.NET では、コンポーネント作成の多くの詳細が隠されるため、開発が容易になります。

.NET は、一般的に使用される COM コントロールへのラッパーを提供します。

.NET は名前空間を介して COM+ を活用できSystem.EnterpriseServices、COM+ が提供するサービスのいくつかは .NET で複製されています。たとえば、System.Transactions名前空間はクラスを提供しTransactionScope、COM+ に頼ることなくトランザクション管理を提供します。同様に、キューに入れられたコンポーネントは、MSMQトランスポートを備えたWindows Communication Foundation (WCF)に置き換えることができます。

下位互換性のサポートは限定的です。COM オブジェクトは、ランタイム呼び出し可能ラッパー(RCW) を実装することで .NET で使用できます。^{[7]特定のインターフェイス制限に準拠する .NET オブジェクトは、} COM 呼び出し可能ラッパー(CCW)を呼び出すことで COM オブジェクトで使用できます。 ^[8] COM 側と .NET 側の両方から、もう一方のテクノロジを使用するオブジェクトはネイティブ オブジェクトとして表示されます。COM相互運用性を参照してください。

WCF は、COM のリモート実行の課題のいくつかを軽減します。たとえば、プロセスまたはマシンの境界を越えて、オブジェクトを値によって透過的にマーシャリングすることがより簡単になります。

Windows ランタイム( WinRT ) は COM ベースの API ですが、拡張された COM バリアントです。COM に似た基盤を持つため、WinRT は複数のプログラミング コンテキストからのインターフェイスをサポートしますが、管理されていないネイティブ API です。API 定義は、ECMA 335 メタデータ形式でエンコードされた ".winmd" ファイルに保存されます。これは、いくつかの変更を加えた .NET で使用されるのと同じCLI メタデータ形式です。このメタデータ形式により、WinRT が .NET アプリケーションから呼び出されるときに、P/Invoke よりも大幅にオーバーヘッドが少なくなります。

Nano-COMは COM のサブセットであり、 COM のアプリケーション バイナリ インターフェイス(ABI) の側面に重点を置き、独立してコンパイルされたモジュール/コンポーネント間で関数およびメソッドの呼び出しを可能にします。Nano-COM は、移植可能な C++ ヘッダー ファイルで表現できます。Nano-COM は、基礎となる命令アーキテクチャと OS のネイティブ ABI を拡張して、型指定されたオブジェクト参照をサポートします。一方、一般的な ABI は、アトミック タイプ、構造体、配列、および関数呼び出し規則に重点を置いています。

Nano-COM ヘッダー ファイルでは、少なくとも 3 つの型を定義または指定します。

• GUID – インターフェースの種類を識別する

• HRESULT – S_OK、E_FAIL、E_OUTOFMEMORY などのメソッド結果コード

• dynamic_cast<T>IUnknown – オブジェクト参照の基本型。新しいインターフェース型の取得と参照カウントをサポートする抽象仮想関数。shared_ptr<T>

Nano-COM の多くの用途では、結果として呼び出し先が割り当てたメモリ バッファーをアドレス指定する 2 つの関数が定義されています。

• <NanoCom>Alloc – メソッド実装によって呼び出され、呼び出し元に返される生のバッファ（オブジェクトではない）を割り当てます。

• <NanoCom>Free – メソッド呼び出し元によって呼び出され、使用されなくなった呼び出し先が割り当てたバッファを解放します。

Direct3D などの Nano-COM の一部の実装では、アロケータ関数を使用せず、呼び出し元が割り当てたバッファのみを使用するように制限しています。

Nano-COM には、クラス、アパートメント、マーシャリング、登録などの概念はありません。むしろ、オブジェクト参照は単に関数の境界を越えて渡され、標準言語構造 (C++new演算子など) を介して割り当てられます。

Nano-COM の基礎は、Mozilla が Firefox をブートストラップするために使用されました ( XPCOMと呼ばれます)。現在は、 DirectX / Direct3D / DirectMLの基礎 ABI テクノロジとして使用されています。

ActiveX コントロール (任意の COM コンポーネント) は、サンドボックス保護のないネイティブ コードとして実行されるため、実行できる内容に制限はほとんどありません。Internet Explorer がサポートしている ActiveX コンポーネントを Web ページで使用すると、マルウェア感染の問題が発生します。Microsoft は、1996 年に Charles Fitzgerald が「ActiveX が本質的に安全であると最初から主張したことはありません」と述べた時点で、この問題を認識していました。^[9] Internet Explorer のそれ以降のバージョンでは、ActiveX コントロールをインストールする前にユーザーにプロンプ​​トを表示し、インストールをブロックできます。

保護レベルとして、ActiveX コントロールは信頼性を保証するためにデジタル署名で署名されます。

ActiveX コントロールを完全に無効にしたり、選択したコントロールのみを許可したりすることも可能です。

プロセス外 COM サーバーの透過的なサポートにより、プロセス分離の点でソフトウェアの安全性が促進されます。これは、大規模なアプリケーションのサブシステムを個別のプロセスに分離する場合に役立ちます。プロセス分離により、厳密に定義されたインターフェイスを介してのみ通信するため、1 つのプロセスの状態破損が他のプロセスの整合性に悪影響を及ぼすことが制限されます。したがって、有効な状態を回復するには、影響を受けたサブシステムのみを再起動する必要があります。これは、同じプロセス内のサブシステムには当てはまりません。1つのサブシステム内の不正なポインターが他のサブシステムをランダムに破損する可能性があります。

COMは、 C、C++、Visual Basic、Delphi、Python ^{[10] [11]}、およびいくつかのWindowsスクリプトコンテキストなど、いくつかの言語のバインディングを介してサポートされています。コンポーネントへのアクセスは、インターフェイスメソッドを介して行われます。これにより、プロセス内での直接呼び出しと、プロセスとコンピューター間のCOM/DCOMサブシステムアクセスを介したアクセスが可能になります。

COM クラスであるコクラスは、1 つ以上のインターフェイスを実装します。これは、 CLSID ( GUID)と呼ばれるクラス ID と、ProgIDと呼ばれる人間が判読できるプログラム識別子によって識別されます。コクラスは、これらの識別子の 1 つを使用して作成されます。

各 COMインターフェイスはインターフェイスを拡張し、参照カウントとオブジェクトの他のインターフェイスへのアクセスのためのIUnknownメソッドを公開します。これは、型変換、つまり型キャスト に似ています。

インターフェースは、インターフェース ID (IID)、GUID によって識別されます。

カスタムインターフェイス(から派生したもの) は、インターフェイスで宣言された関数を宣言順に実装する関数へのポインターのリストを含む仮想メソッド テーブルへのポインターIUnknownを介して、早期バインド アクセスを提供します。したがって、インプロセス呼び出しのオーバーヘッドは、C++ の仮想メソッド呼び出しに匹敵します。

ディスパッチ (遅延バインディングアクセスとも呼ばれます) は、 を実装することによって提供されますIDispatch。ディスパッチにより、カスタム インターフェイスよりも広範囲のプログラミング コンテキストからのアクセスが可能になります。

多くのオブジェクト指向言語と同様に、COM はインターフェイスと実装を分離します。この区別は、オブジェクトに既定のインターフェイスがない COM では特に顕著です。クライアントは、アクセスするためにインターフェイスを要求する必要があります。COM は同じインターフェイスの複数の実装をサポートしているため、クライアントは使用するインターフェイスの実装を選択できます。

COMタイプ ライブラリは、コクラスやインターフェイスなどの COM メタデータを定義します。ライブラリは、プログラミング言語に依存しない構文であるインターフェイス定義言語(IDL) として定義できます。IDL は、インターフェイスとコクラスを定義するための追加の構文を持つ C++ に似ています。IDL は、識別子やパラメーター間の関係などのメタデータを定義するために、宣言の前に括弧で囲まれた属性もサポートしています。

IDL ファイルは、MIDL コンパイラによってコンパイルされます。C/C++ で使用するために、MIDL コンパイラは、宣言されたインターフェイスのvtbl にstruct一致する定義を含むヘッダー ファイルと、インターフェイスGUIDの宣言を含む C ファイルを生成します。プロキシ モジュールの C++ ソース コードも、MIDL コンパイラによって生成できます。このプロキシには、COM 呼び出しをリモート プロシージャ コールに変換して、アウトオブプロセス通信用に DCOM を有効にする メソッド スタブが含まれています。

MIDL は、他のコンテキストからのアクセスをサポートするために他のツールで使用できるバイナリ タイプ ライブラリ (TLB) を生成できます。

SomeClass次の IDL コードは、 という名前のインターフェースを実装する という名前のコクラスを宣言しますISomeInterface。

コクラス SomeClass  {
   [デフォルト] インターフェース ISomeInterface;
};

これは概念的には、ISomeInterface が純粋仮想クラス、つまり抽象基本クラス である次の C++ コードと同等です。

クラスISomeInterface {};クラスSomeClass :パブリックISomeInterface { };  
     

CoCreateInstanceC++ では、COM オブジェクトは、CLSID と IID を受け取るCOM サブシステム関数を介してインスタンス化されます。SomeClass次のように作成できます。

ISomeInterface * interface_ptr = NULL ; HRESULT hr = CoCreateInstance ( CLSID_SomeClass , NULL , CLSCTX_ALL , IID_ISomeInterface , ( void ** ) & interface_ptr );   
       

COM オブジェクトは、参照カウントを使用してオブジェクトの有効期間を管理します。オブジェクトの参照カウントは、IUnknown AddRefおよびReleaseメソッドを通じてクライアントによって制御されます。参照カウントがゼロになった場合、COM オブジェクトは自身のメモリを解放する役割を担います。一部のプログラミング コンテキスト ( Visual Basicなど) では、オブジェクトの使用を簡素化するために自動参照カウントが提供されます。C++ では、スマート ポインターを使用して参照カウントの管理を自動化できます。

AddRefとRelease をいつ呼び出すべきかについてのガイドラインは次のとおりです。

• インターフェース参照を返す関数（戻り値または「out」パラメータ経由）は、返されたオブジェクトのカウントを増分します。

• インターフェースポインタが上書きされるかスコープ外になる前にリリースが呼び出されます

• インターフェース参照ポインタにコピーが作成されると、AddRefが呼び出されます。

• AddRefとReleaseは、参照されているインターフェース（同じオブジェクトの異なるインターフェースではない）で呼び出されます。これは、オブジェクトがインターフェースごとの参照カウントを実装して、参照されているインターフェースにのみ内部リソースを割り当てることができるためです。

リモート オブジェクトの場合、すべての参照カウント呼び出しがネットワーク経由で送信されるわけではありません。プロキシはリモート オブジェクト上の参照を 1 つだけ保持し、独自のローカル参照カウントを維持します。

C++ 開発者の COM 開発を簡素化するために、Microsoft はATL (Active Template Library)を導入しました。ATL は比較的高水準の COM 開発パラダイムを提供します。また、スマート ポインター型を提供することで、COM クライアント アプリケーション開発者が参照カウントを直接管理する必要がなくなります。COM 対応の他のライブラリと言語には、Microsoft Foundation Classes、VCコンパイラ COM サポート、^[12] VBScript、Visual Basic、ECMAScript ( JavaScript )、Borland Delphiなどがあります。

COM は言語に依存しないバイナリ標準であり、バイナリ インターフェイスにアクセスできる任意のプログラミング コンテキストでオブジェクトを使用できるようにします。

COM クライアント ソフトウェアは、COM サブシステムの有効化、COM オブジェクトのインスタンス化と参照カウント、およびサポートされているインターフェイスのオブジェクトのクエリを担当します。

Microsoft Visual C++コンパイラは、C++言語の拡張機能であるC++属性^[13]をサポートしています。これは、COM開発を簡素化し、 C++でCOMサーバーを実装するために必要な定型コードを最小限に抑えるように設計されています。^[14]

元々、タイプ ライブラリ メタデータはシステム レジストリに保存する必要がありました。COM クライアントは、オブジェクトの作成にレジストリ情報を使用します。

登録不要 (RegFree) COM は、Windows XPで導入され、実行可能ファイル内のリソースとして、またはコンポーネントと共にインストールされる別のファイルとして、タイプ ライブラリ メタデータをアセンブリ マニフェストとして保存できるようになりました。 ^[15]これにより、同じコンポーネントの複数のバージョンを同じコンピューターの異なるディレクトリにインストールできます。また、XCOPY 展開も可能になります。^[16]このテクノロジは、EXE COM サーバーのサポートが制限されており^[17]、MDAC、MSXML、DirectX、Internet Explorerなどのシステム全体のコンポーネントには使用できません。

アプリケーションのロード中に、Windows ローダーはマニフェストを検索します。^[18]マニフェストが存在する場合、ローダーはそこからアクティベーション コンテキストに情報を追加します。^[16] COM クラス ファクトリがクラスのインスタンスを作成しようとすると、まずアクティベーション コンテキストがチェックされ、CLSID の実装が見つかるかどうかが確認されます。検索が失敗した場合にのみ、レジストリがスキャンされます。^[16]

COM オブジェクトは、タイプ ライブラリ情報なしで、 DLLファイルへのパスと CLSID のみを使用して作成できます。クライアントは、CLSID と IID_IClassFactory を指定した COM DLL 関数を使用して、ファクトリ オブジェクトDllGetClassObjectのインスタンスを作成できます。その後、クライアントはファクトリ オブジェクトのを使用してインスタンスを作成できます。^[19]これは、COM サブシステムが使用するのと同じプロセスです。^[20]この方法で作成されたオブジェクトが別のオブジェクトを作成する場合は、通常の方法 (レジストリまたはマニフェストを使用) で作成されます。ただし、内部オブジェクト (まったく登録されていない場合もあります) を作成し、独自のプライベートな知識を使用して、それらのオブジェクトにインターフェイスへの参照を渡すこともできます。 CreateInstance

COM オブジェクトは、同じプロセス内 (インプロセス)、プロセス境界を越えた (アウトプロセス)、またはネットワーク経由でリモート (DCOM) で透過的に作成および使用できます。アウトプロセス オブジェクトとリモート オブジェクトは、マーシャリングを使用してメソッド呼び出しをシリアル化し、プロセスまたはネットワーク境界を越えて値を返します。このマーシャリングはクライアントには見えず、クライアントはローカルのインプロセス オブジェクトであるかのようにオブジェクトにアクセスします。

COMでは、スレッドはアパートメントと呼ばれる概念を通じて扱われる。^[21]個々のCOMオブジェクトは、シングルスレッドまたはマルチスレッドのいずれかである、正確に1つのアパートメント内に存在する。COMには、シングルスレッドアパートメント(STA)、マルチスレッドアパートメント(MTA)、およびスレッドニュートラルアパートメント(NA)の3種類のアパートメントがある。各アパートメントは、オブジェクトの内部状態を複数のスレッド間で同期できる1つのメカニズムを表す。プロセスは複数のCOMオブジェクトで構成することができ、そのうちのいくつかはSTAを使用し、他のいくつかはMTAを使用する。COMオブジェクトにアクセスするすべてのスレッドも同様に1つのアパートメント内に存在する。COMオブジェクトとスレッドのアパートメントの選択は実行時に決定され、変更できない。

同じアパートメントに属するスレッドとオブジェクトは、同じスレッド アクセス ルールに従います。したがって、同じアパートメント内で行われるメソッド呼び出しは、COM の支援なしで直接実行されます。アパートメント間で行われるメソッド呼び出しは、マーシャリングによって実現されます。これには、プロキシとスタブを使用する必要があります。

COM は、特に .NET などの最新のコンポーネント テクノロジと比較すると、比較的複雑です。

STA が初期化されると、アパートメント間およびプロセス間のメッセージ ルーティングに使用される非表示のウィンドウが作成されます。このウィンドウのメッセージ キューは定期的に「ポンプ」される必要があります。この構造は「メッセージ ポンプ」と呼ばれます。以前のバージョンの Windows では、これを行わないとシステム全体のデッドロックが発生する可能性がありました。この問題は、実装の一部として COM を初期化する一部の Windows API によって複雑化しており、実装の詳細が「リーク」します。

COM 内の参照カウントは、2 つ以上のオブジェクトが循環参照されている場合に問題を引き起こす可能性があります。アプリケーションを設計する際には、オブジェクトが孤立しないように、この点を考慮する必要があります。COM の「イベント シンク」モデルが使用されている場合、オブジェクトにアクティブな参照カウントが残ることもあります。イベントを発生させるオブジェクトには、イベントに反応するオブジェクトへの参照が必要なので、後者の参照カウントがゼロになることはありません。参照サイクルは、通常、帯域外終了または分割 ID を使用して解除されます。帯域外終了手法では、オブジェクトは、呼び出されると他のオブジェクトへの参照を強制的に削除するメソッドを公開し、それによってサイクルを解除します。分割 ID 手法では、単一の実装で 2 つの個別の COM オブジェクト (ID とも呼ばれます) を公開します。これにより、 COM オブジェクト間に弱い参照が作成され、参照サイクルが防止されます。

インプロセス COM コンポーネントは DLL ファイルに実装されており、登録では CLSID ごとに 1 つのバージョンのみが許可されるため、状況によっては「DLL ヘル」効果の影響を受ける可能性があります。登録不要の COM 機能により、インプロセス コンポーネントのこの問題は解消されますが、登録不要の COM はアウトプロセス サーバーでは使用できません。

• 呼び出し規約 – コンピュータ内でサブルーチンが呼び出される方法
• 共通言語基盤 – 技術標準
• D-Bus  – Linux ミドルウェア
• 外部関数インターフェース – 他のプログラミング言語から関数を呼び出すためのインターフェース
• インターネット通信エンジン – オープンソースソフトウェア
• Java リモート メソッド呼び出し – プログラミング インターフェイス
• KDE フレームワーク – Qt フレームワーク用のライブラリとソフトウェア フレームワークのコレクション
• 名前マングリング – コンパイラ構築のテクニック
• ポータブルオブジェクト（コンピューティング）  – 分散プログラミングにおけるオブジェクト
• SWIG  – プログラミング言語バインディングを生成するオープンソースツールフォールバックとしてウィキデータの説明を表示するページ

• 「COM: 簡単な紹介 (パワーポイント)」(PowerPoint (PPT) ファイルへの直接リンク) 。2006 年3 月 7 日に取得。
• ボックス、ドン(1998)。エッセンシャル COM。アディソン・ウェスレー。ISBN 978-0-201-63446-4。
• Chappell, David (1996)。ActiveX と OLE の理解。Microsoft Press。ISBN 978-1-57231-216-6。
• 「COM+ サービスの WCF への統合と移行」 。2010年4 月 15 日閲覧。

• MSDN のコンポーネント オブジェクト モデル
• COM の共同発明者、トニー・ウィリアムズ氏へのインタビュー (ビデオ ウェブキャスト、2006 年 8 月)
• 情報: Microsoft の OLE コントロールと ActiveX コントロールの違い
• オープンソースのダンパー ユーティリティを使用した TypeLib データ形式仕様 (非公式)。
• COM / DCOM 用語集 (archive.org)