IDLとは
IDLとはどういう意味ですか？私はそれをグーグルで調べ、それがコンポーネントのインターフェース定義に使用されるインターフェース定義言語の略であることを発見しました。しかし、実際には、IDLの目的は何ですか？マイクロソフトはそれを使用していますか？
インターフェイス定義言語（IDL）は、リモートプロシージャコール（RPC）でクライアントとサーバー間の通信を設定するために使用されます。 Sun RPC、ONC RPC、DCE RPCなど、これには多くのバリエーションがあります。
基本的に、IDLを使用してクライアントとサーバー間のインターフェイスを指定し、RPCメカニズムがネットワーク全体で関数を呼び出すために必要なコードスタブを作成できるようにします。
RPCは、IDL情報を使用して、クライアントとサーバーのスタブ関数を作成する必要があります。これはCの関数プロトタイプに非常に似ていますが、最終結果は次のように少し異なります。
+----------------+
| Client |
| +----------+ | +---------------+
| | main | | | Server |
| |----------| | | +----------+ |
| | stub_cli |------->| stub_svr | |
| +----------+ | | |----------| |
+----------------+ | | function | |
| +----------+ |
+---------------+
この例では、同じプログラムでfunctionを呼び出す代わりに、mainが（functionと同じプロトタイプを使用して）情報をパッケージ化するクライアントスタブ関数を呼び出します。そして、それをネットワーク経由で別のプロセスに送ります。これは同じマシンでも別のマシンでもかまいませんが、実際には問題になりません。RPCの利点の1つは、サーバーを自由に移動できることです。
サーバーには、その情報を受信してサーバーに渡す「リスナー」プロセスがあります。サーバーのスタブは情報を受け取り、アンパックして、実際の関数に渡します。
次に、実際の関数は必要なことを行い、戻り情報（戻りコードと[out]または[in,out]変数の両方）をパッケージ化してサーバースタブに返し、それをクライアントスタブに返します。
次に、クライアントスタブがそれをアンパックし、mainに返します。
実際の詳細は少し異なる場合がありますが、その説明は概念的な概要としては十分です。
実際のIDLは次のようになります。
[uuid(f9f6be21-fd32-5577-8f2d-0800132bd567),
version(0),
endpoint("ncadg_ip_udp:[1234]", "dds:[19]")]
interface function_iface {
[idempotent] void function(
[in] int handle,
[out] int *status
);
}
上部にあるものはすべて基本的にネットワーク情報であり、その主要部分はプロトタイプが表示されるインターフェイスセクション内にあります。これにより、IDLコンパイラは、RPCを機能させるためにクライアントおよびサーバーコードをコンパイルおよびリンクするためのxスタブおよびxサーバー関数を構築できます。
MicrosoftはCOMにIDLを使用しています（MIDLコンパイラーがあると思います）。また、DCEとONC RPCの両方のMSオペレーティングシステムでサードパーティ製品を使用しました。
インタラクティブデータ言語 もあります。これは、科学データ分析に使用していた仕事ですが、おそらくこのIDLが意味するものではないことは、コンテキストから明らかです。
IDLは Interface Definition Language の頭字語で、言語を定義したベンダーまたは標準グループに応じていくつかのバリエーションがあります。 IDLの目的は、サービスを使用するクライアントが、サービスが提供するメソッドとプロパティ、インターフェースを認識できるように、いくつかのサービスのインターフェースを記述することです。 IDLは通常バイナリインターフェイスで使用され、IDL言語ファイルはバイナリインターフェイスで使用されるデータ型を記述します。
バイナリコンポーネントにはいくつかの異なる標準があり、通常 COTSまたは商用オフザシェルフ であり、クライアントがバイナリコンポーネントと通信する方法は、従来の一部のバージョンでは異なります。 のリモートプロシージャコールまたはRPC が使用されます。そのような2つの標準は、 Microsoft Common Object ModelまたはCOM標準 と Common Object Request BrokerまたはCORBA標準 。 Firefoxプラグイン などのコンポーネントや、Visual Studio自体などの他のアプリケーション用のプラグインには他の標準がありますが、これらは必ずしも何らかの形式のインターフェイス記述言語を使用するわけではありません代わりに、APIへの標準化された既知のインターフェイスを備えた、ある種のソフトウェア開発キットまたはSDKを使用します。
IDLが可能にするのは、バイナリの性質により、さまざまなプログラミング言語やさまざまな環境で使用できるさまざまな種類のサービスを提供するコンポーネントを作成できる柔軟性の向上です。
MicrosoftはCOMオブジェクトでIDLの方言を使用し、Microsoft IDLはCORBA IDLと同じではありませんが、共通言語のルーツを共有しているため類似点があります。 IDLファイルには、COMオブジェクトでサポートされているインターフェイスの説明が含まれています。 COMは、インプロセスサービス（RPC、または直接DLL呼び出し）を使用できます）またはアウトプロセスサービス（RPCを使用）の作成を許可します。COMの背後にある考え方は、クライアントが知る必要があるのは、コンポーネントの識別子とそれを使用できるようにするインターフェースクライアントはCOMオブジェクトを要求し、次にクライアントが使用したいインターフェースをサポートするCOMオブジェクトのファクトリからクラスオブジェクトを要求し、そのインターフェースを通じてCOMオブジェクトを使用します。 。
Microsoftは、IDLファイルを処理してタイプライブラリを生成するMIDLコンパイラを提供し、COMオブジェクトのユーザーにインターフェイスに関する情報を提供し、クライアントとサービス間のインターフェイス全体でデータをマーシャリングするために必要なスタブを提供します。
データのマーシャリングとは、基本的に、スタブがクライアントから提供されたデータを取得してパッケージ化し、何らかのアクションを実行してデータを送り返すサービスに送信することを意味します。このデータの送受信は、一部のRPCサービスまたは直接のDLL関数呼び出しを介して行われます。サービスからの応答は、クライアントに適した形式に変換されてからクライアントに提供されます。したがって、基本的にマーシャリング機能は アダプター（アダプターの設計パターンを参照） または ブリッジ（ブリッジの設計パターンを参照） クライアントとサービスの間。
Visual Studio（私の経験はC++を使用しています）には、サンプルを生成するために使用できるいくつかのウィザードが含まれているため、これを試すことができます。興味がある場合は、ワークスペースを作成してから、そのワークスペースでATLプロジェクトを作成してコントロールを生成し、次に簡単なMFCダイアログプロジェクトを作成してテストできます。 COMコントロールにATLを使用すると、後で調査できるかなりの詳細が非表示になり、シンプルなMFCダイアログプロジェクトにより、コンテナーを簡単に作成できます。 Visual Studioで利用可能なActiveXコントロールテストコンテナーツールを使用して、予備的なテストを行い、メソッドとプロパティがどのように機能するかを確認することもできます。
Codeproject.comなどのWebサイトには、多数のサンプルプロジェクトもあります。たとえば、ここでは COMの背後にあるすべての醜い配管を公開するために（== --- ==）を使用しています とここでは ATLなしでC++を使用しています 。
IDLは2つのケースで不可欠です。 1. exeサーバー用のプロキシ/スタブdllを作成します。 2.オートメーションサーバーのタイプライブラリを作成します。
IDLの基礎に関する非常に優れた記事が link にあります
IDLを研究するには、VC++パッケージのサブディレクトリが含まれているコンパイラー独自のIDLヘッダーファイルを読むことをお勧めします。
別のアプリケーションで公開されているサービスとの通信に使用されるインターフェースを定義します。
SOAP=を使用すると、WSDLについて理解できます。WSDLはIDLの別の形式です。IDLは通常、Microsoft COMまたはCORBA IDLを指します。
これは、COM時代に（おそらく）言語に依存しない方法でインターフェイスを定義するために使用されてきた言語です。